Conference azur::mcc

>    In the situation where a network node is running decnet IV as well as
>    tcp/ip, what is the prefered way to register this node?
 
The best approach is to register as both a node4 and as an snmp entity.
Note that you must use different fullnames.

You might then want to place both entities in a domain, to indicate
that they are running on the same hardware.

From a management point of view, you really are managing two different
entities (the phase IV software and the IP software).  However, we
recognize that people often think about boxes, not the pieces of software
inside, and are working to find a better way of representing these
multi-protocol boxes.

-- Erik

       <<< Note 2124.0 by OTOOA::DOIRON "R_Doiron@Kaofs.enet.dec.com" >>>
                   -< How to manage a multiprotocol object? >-

    In the situation where a network node is running decnet IV as well as
    tcp/ip, what is the prefered way to register this node?

MCC> REGISTER NODE4 .DNA_NODE.FOOBAR SYN FOOBAR
MCC> REGISTER SNMP FOOBAR SYN FOOBAR.LKG.DEC.COM
    
    If registered as an ip node will decnet related functions such as
    counters and alarming be available?

Sure:
MCC> SHOW NODE4 .DNA_NODE.FOOBAR ALL COUNTERS
    
    If registered as a node iv, will any ip functions be available?
    
Sure:
MCC> SHOW SNMP FOOBAR.LKG.DEC.COM ALL COUNTERS
    
    What about a router that is managed by snmp but routes decnet as well
    as other protocols?
    
    Customers ask the darndest questions.
    
    Thanks,
    Richard

    A router that routes both IP and DECnet but which is manageable by
    only SNMP is registered as an SNMP entity only. Registering somethin
    as DECnet means that you can use DECnet management protocols to
    manage it which is not true in the case you stated.
    
    Note that unless the router vendor provides MIB extensions for the
    DECnet portion of the router, you can not manage the DECnet part.
    If they do, you need to translate those MIB extensions and enroll
    them into the data dictionary.
    
    If those hypothetical boxes are the DECrouter boxes, they are managed
    either from SNMP or DEC CMIP.
    
    wally

.1> >    In the situation where a network node is running decnet IV as well as
.1> >    tcp/ip, what is the prefered way to register this node?
.1>  
.1> The best approach is to register as both a node4 and as an snmp entity.
.1> Note that you must use different fullnames.

I don't  think  this  can  be  described  as  the  "best"  approach.  It is,
unfortunately, the only approach available with DECmcc today.

.1> 
.1> You might then want to place both entities in a domain, to indicate
.1> that they are running on the same hardware.
.1> 
.1> From a management point of view, you really are managing two different
.1> entities (the phase IV software and the IP software).  

Not necessarily.   If  you  consider a product like Hastings V2, you will be
able  to manage the complete function of the box from either of SNMP or CMIP
or  both  at  the  same time.  It *is* reasonable to say that they represent
different views onto the same thing.  Have you looked into the complications
that the SNMP Views RFC introduces? I would hope that the solution in DECmcc
for  different  SNMP  Views  would  be  identical  (to the user) to that for
different protocols.

.1>However, we
.1> recognize that people often think about boxes, not the pieces of software
.1> inside, and are working to find a better way of representing these
.1> multi-protocol boxes.

That sounds very patronising -- I am sure it wasn't intended to be.  In this
type  of  thing  the customer is always right.  If the customer thinks about
the  box  then  it *is* the box that he wants to manage.  If DECmcc can't do
that but another product can then he will use the other product.

I will grant that no-one else seems to have a solution to this problem today
but  you  need to make sure you have a solution at least at the same time as
everyone  else.   This  product  is becoming important enough to people that
some  vendor  will  solve it soon.  By the way, don't forget to solve it for
RBMS at the same time.

Graham

>I don't  think  this  can  be  described  as  the  "best"  approach.  It is,
>unfortunately, the only approach available with DECmcc today.

I agree.

>That sounds very patronising -- I am sure it wasn't intended to be.  In this

Sorry, I didn't mean to patronize.  Personally, I think mostly about
boxes as well, and what counts is what the customer wants.  For V1.2, domains
will still be the best DECmcc can do, but there are people thinking
about how to do better.

-- Erik

    One box, one management strategy. Lets do it before someone eats our
    lunch.