Conference netcad::hub_mgnt

For clearVISN to get mib data from a VNswitch, you have to
have a network connection from your NMS to the front panel
of the VNswitch.  The VNswitch won't pass the data through
the hub.

	Dotsie

    One small correction to Dotsie's note. While you do need a network
    connection to the VNswitch in order for clearVISN to manage it, that
    network connection does not have to be via the FRONT PANEL. The network
    connection can also be made via the VNbus or backplane Ethernet, FDDI,
    etc connections.                                          

 re:-1

 why you can use serial management bus on VNSwitch family ?
 is it and hardware restriction ?
 
 thanks to clarify

 JYP

    The VNswitch can and does use the Hub's star-wired serial management
    channel to communicate with the MAM. It has to in order to do things
    like lan hopping.  
    
    The feature you are asking about is called "SNMP-Gateway" by the
    product development teams. It is this feature that allows you to send
    an SNMP request to the MAM's IP address (in-band or out-of-band) and
    have the MAM redirect that request to the module in the slot number
    specified in the request's community string.
    
    The VNswitch products to not currently support the SNMP-Gateway
    function, but this is not a hardware restriction. If you and/or your
    customers feel that the VNswitch needs to add this functionality to a
    future software release, then you should send this feedback to product
    management.
               

    
      for sure customers need that , thinking
      than VNs could take place in old configuration 
      and must be managed thru another module without Lan connection
       others than management bus...
    
       thanks to forward my reply to appropriate person
    
      JYP

    One OTHER correction to this mess....
    
    
    IF you upgrade the firmware from (mumble) to (fuzz), it's a good idea
    to do a "reset to factory defaults" and THEN try to do things.
    
    I had a VNswitch 900EX which I could NOT get to work.  One of the TAC
    Techies happened to be around and tried it too...and failed UNTIL he
    did a 'reset to factory'.  An UNDOCUMENTED quirk.
    
    It's what you DON't know that gets ya...
    j
    

    Hello,
    
    questions about .4
    
    it is not clear the difference between the "communication" between
    Vnswitch and MAM and SNMP-gateway...
    
    My question is:
    ... To modify the setting of a "just inserted" VNswitch you send, 
    through the MCM, a SNMP "set", right?  
    
    Is it done via the star-wired serial management channel? I think yes. 
    Is it done using the SNMP-gateway functions? I don't know...
    
    So, which commands use the SNMP-gateway and which simply use the
    star-wired serial management channel or both of them (star-wired and
    SNMP-gateway?)
    
    My problem is that (as written in the entry 4321), in a DEChub 900MS
    I'm able to manage a VNswitch 900EF (which has its own IP address) 
    inserted in the slot 8, (proxy agent of a DEChub 900MS) but I'm not 
    able to manage a VNswitch 900EE inserted in the slot 7 (no ip address) 
    (the error is ... No such MIB...) which is connected to the 
    VNswitch 900EF with the VNbus.
    
    I have no other modules in the HUB.
    
    Note that I manage the entire HUB using the MAM ip address.
    
    Before to assign a IP address to the VNswitch 900EF I was no able to
    manage the HUB.
    
    Plese help me.
    
    Francesco
    
    
    

>>  My question is:
>>  ... To modify the setting of a "just inserted" VNswitch you send, 
>>  through the MCM, a SNMP "set", right?  

    No, this is not correct. The issue here is that there are several
    different SNMP agents operating in this system, each of which manages
    different resources. The MAM has an SNMP agent, the VNswitch has an
    SNMP agent, and most other hub-based 900 modules have SNMP agents. The
    MAM's SNMP agent manages directly only hub-wide resources, such as
    power and backplane LAN connections. The VNswitch's SNMP agent manages
    VNswitch-specific resources.

    To discuss SNMP-Gateway, let's assume that a DECrepeater 900TM, for
    example is present in  hub slot 2, but it does not have its own IP
    address. If, via clearVISN MCM, you wanted to modify a repeater
    attribute (like disable a repeater port), MCM would send an SNMP
    request to the MAM's IP address, but with a community string that looks
    something like "public_2".  When the MAM receives this request, it will
    not process the SNMP request itself. Because the community string has a
    "_2" appended to it, the MAM will simply forward this SNMP request to
    whatever module happens to plugged into slot 2. This is called
    community string multiplexing. The repeater in slot 2 will actually
    process the SNMP request and sent the SNMP response back to the MAM.
    The MAM will then forward the SNMP response back to the original
    requester. The MAM-DECrepeater communication is accomplished via the
    star-wired management channel, and this IS the SNMP gateway function.

    The VNswitch does not support the SNMP-gateway function. It does
    however let the MAM know what its IP address is, if of course one is
    assigned to it. MCM can query the MAM to determine the IP address of a
    VNswitch in a given slot. MCM will then direct all of its future
    VNswitch-related SNMP requests directly to the VNswitch's IP address.
    This communication is not accomplished via the serial management
    channel.  

    When you modify a hub-wide resource, such as connecting a VNswitch to a
    backplane LAN segment, you are communicating directly with the MAM's
    SNMP agent. An SNMP request is sent to the MAM's IP address with a
    community string that looks something like "public". The MAM processes
    and responds to this SNMP request. It will also send a different
    command to the VNswitch to tell it connect to a given backplane LAN
    segment. This MAM-VNswitch communication is accomplished via the
    star-wired serial management channel but this is NOT SNMP gateway.

>>  My problem is that (as written in the entry 4321), in a DEChub 900MS
>>  I'm able to manage a VNswitch 900EF (which has its own IP address) 
>>  inserted in the slot 8, (proxy agent of a DEChub 900MS) but I'm not 
>>  able to manage a VNswitch 900EE inserted in the slot 7 (no IP address) 
>>  (the error is ... No such MIB...) which is connected to the 
>>  VNswitch 900EF with the VNbus.
    
    You cannot manage the VNswitch 900EE without an IP address because MCM
    needs the to know the IP address of the VNswitch in order to manage it.

    Perhaps someone on the MAM or clearVISN teams can provide a more
    succinct answer.

    -Rich    

             

I recently had to put in special code for discovering the VNswitch
in Recovery Manager, and was not able to use a similar facility
already provided in MCM for the VNswitch and other comet-based
routers, so here's my two-cents worth while it is still fresh in my mind.


VNswitch needs a module IP address defined to be managed by clearVISN
=====================================================================
Like other comet-based routers, each VNswitch in your network requires
a module IP address to be defined in order for clearVISN applications
to manage them. These devices do not support the CSNMP-gateway feature
like other 900-series modules, so they cannot be managed using the
DEChub900 MAM as proxy.

Overview: How clearVISN apps handle VNswitches when Hub IP address is chosen
============================================================================
Basically, when the user invokes MCM by specifying the Hub900's IP 
address (IP services module, etc), for each VNswitch in the hub,
the Hub900 is asked "do you have a module IP address for the device
in this slot, and is it reachable?" If not, the dialog box "MIB DATA
NOT AVAILABLE" comes up to indicate that the device is not reachable.
The error message is displayed as such because various connectivity
issues could be causing the device to be unreachable, or there is no
module IP address defined on the device. Only the latter can be determined
directly by MCM; connectivity/reachability is impossible to determine.
 
Detail
======
When MCM tries to contact a VNswitch via the MAM (e.g, via the
IP Services module's IP address for the hub), its request is initially
of the CSNMP-gateway form ("public-1", "public-2", etc). A very small
amount of the CSNMP-gateway actually is supported, for requests of
certain MIB-II info (like sysName, sysObjectId, sysDescr, etc.)

MCM gets the value of sysObjectId for the device using the original
agent info (Hub900 IP address and "slot-appended" community string). 
If the sysObjectId retrieved corresponds to a supported VNswitch, 
the original "slot-appended" community string is changed to that of the MAM in
order to read the MAM's chasEntityTable, which has a listing of all "entities"
in the hub, including all module IP addresses, community strings, etc.

The relevant entries in the chasEntityTable to this matter are:

chasEntitySlotNumber         slot number in the chassis
chasEntityIndex              entries in table indexed by (slot, index)
chasEntityIpAddress          module IP address
chasEntityCommunity          community string
chasEntityComAccessRights    comm. string access: values are readOnly,          
                                                  readWrite, other

If the chasEntityTable contains an entry for the current slot (device)
which is found to be reachable (an SNMP get to "sysName" using the 
chasEntityIpAddress and chasEntityCommunity is performed), then MCM
uses this new agent information (the module IP address/community string) 
for all subsequent communications with the device. Something similar is 
done for SNMP sets.

The clearVISN folks (myself included) would have loved the full
CSNMP-gateway feature to have been implemented, so this special-case
code (and the inherent delays caused by extra SNMP gets) would not
have been necessary. In order to ship products, we understood that
getting the VNswitch basic functionality to ship was of highest
priority, and we work as a team. 

Keep your comments and requests coming, as customer-driven requirements 
are key to delivering successful products.

John Gillis
clearVISN

>  The clearVISN folks (myself included) would have loved the full
>  CSNMP-gateway feature to have been implemented, so this special-case
>  code (and the inherent delays caused by extra SNMP gets) would not
>  have been necessary. In order to ship products, we understood that
>  getting the VNswitch basic functionality to ship was of highest
>  priority, and we work as a team.

I don't see how the lack of a CSNMP gateway function slows things down - at
least if the manager will be doing lots of management.  Remember that CSNMP
stands for "compressed SNMP", and that the compression is there because the
serial line is so slow.  If a fast IP link exists, the manager's better off
if you switch over to it as soon as possible.

That aside, I can see how full gateway support might be useful when you are
first bringing up a hub - and in cases where a customer is willing to trade
off speed for fewer module IP addresses.

>  VNswitch needs a module IP address defined to be managed by clearVISN

This is also true of the ATMswitch 900.  Internally, it has two agents:

    1. The "main" agent, which handles all SNMP/IP requests and ATM ILMI
       protocol interactions.  (This agent also runs on GIGAswitch/ATM.)

    2. The "hub citizenship" agent, which talks to the MAM via CSNMP and
       supports a minimal set of objects needed for hub citizenship.

We are looking at ways to merge them in some post-V2.5 release.  Both are
based on the Shawn Gallagher agent (although not on the same release), so
we're hoping this will go smoothly.

    
        hello All
    
      just to confirm and resume all replies ,
      we must have a lan connection to a VN to manage it in the DECHub900
      is it a true statment ?
    
      thanks
    
       JYP
    

    Jean,
    
    It is not enough...
    you have to assign an IP address to that module to be able to manage
    it...
    
    True???

    Jean/Francesco,
    
    In order to manage a VNswitch in a DEChub 900 via SNMP, the VNswitch
    must have an IP address assigned to it, AND the VNswitch must have some
    network connection (either front panel, backplane LAN segment, or
    VNbus).
                              
    -Rich

For clearVISN to manage a VNswitch in a DEChub900 (when you choose the
DEChub900's IP address when invoking MCM), you need to do the
following on each VNswitch in the hub:

1) A module IP address assigned to the VNswitch
2) A LAN connection from the VNswitch to the IP Services module
(Ethernet, FDDI, VNbus, etc)

Please send any comments or concerns to clearVISN Product Manager,
Jack Forrest (nacto::forrest)

John Gillis
clearVISN 

    
      good i'll ask Jack
    
      but how can you explain to customers
      3 VNbus totally independant but modules connected on 
      must have a lan connection to be managed ?
    
      how can we have 3 vnbus networks totally indepedant
      but manageable from clearvis ?
      
      

>>    but how can you explain to customers
>>    3 VNbus totally independent but modules connected on
>>    must have a lan connection to be managed ?

    In this case the VNbus is the LAN connection. Presumably, one of the
    ports on one of the VNswitch modules attached to a given VNbus is
    connected to the external network. This will provide the network
    connectivity to all the VNswitch modules on that VNbus.

    But what about the case of different VNswitch connected to different,
    independent VNbuses? It is probably safe to assume VNswitches connected
    to different VNbuses would have some external (perhaps routed)
    interconnection. Otherwise, end stations attached to these different
    VNswitches would not be able to communicate with each other at all.  

    All this being said, I can certainly see the value of have the VNswitch
    supporting CSNMP Gateway. But as an earlier posting said, tradeoffs had
    to be made during the development process in order to get basic
    functionality shipping as quickly as possible.

    
      in my case customer need 3 IP services modules on Eack
      VNbus to manage the entire HUB , with Gateway function
      he needed only one ...
      
      does it change really hard to do ?
    
       JYP

>>    in my case customer need 3 IP services modules on Eack
>>    VNbus to manage the entire HUB , with Gateway function
>>    he needed only one ...
    
    I don't fully understand your customer's configuration and why you 
    would need 3 IP services modules on each VNbus to manage the entire
    hub. Are the VNswitches connected to different VNbusses completely
    isolated from on another. That is, stations connected to a VNswitch on
    VNbus A never have to communicate on stations connected to a VNswitch
    on VNbus B.

>>  does it change really hard to do ?
    
    Well it certainly is not easy.
    
    I am not the person who would know the most about the implementation of
    this function. But from what I understand, there is a reasonable amount
    of complexity involved in porting this functionality from the hub
    common code base into the VNswitch code base. Again, I would recommend
    that you give feedback to product management regarding such issues.
    
    -Rich
                                                                       

    re: .10
    I throw in my 2 cents.
    >I don't see how the lack of a CSNMP gateway function slows things down
    >- at least if the manager will be doing lots of management.  ..
    > If a fast IP link exists, the manager's better off
    > if you switch over to it as soon as possible.
    
    True that direct 10 or 100Mb acces is faster, but an important issue is the
    usage of IP addresses.  If you have to assign an address to every
    module you will chew up a large amount of address space and management
    cycles.  In order to scale, it would be nice to be able to reduce the
    number of addresses needed.  
    
    A site with 1000 users might have 25 closets and, 80+ VNswitches.  
    Thats a lot of addresses to manage.  Perhaps an automatic BOOTP or 
    DHCP request might be an option for assigning the addresses.
    
    regards,
    scott
    

    
    
    Rich,
    
     few years ago customer bought our products only for this
    function,managing isolate networks,modules on the DECHUB900 from
     a center point.Yes all VNs and Vnbus are isolated may be a little
     config just 10xDechub900 with 80x Vns modules ..
    
     JYP

    Re: .19

>>  I am not the person who would know the most about the implementation of
>>  this function. But from what I understand, there is a reasonable amount
>>  of complexity involved in porting this functionality from the hub
>>  common code base into the VNswitch code base.

    That's an understatement!

    The hub common agent and the layers stacked on top of it (HANIF & MIBX)
    present a very different programming interface to MIB handlers than the
    Proteon agent does.  So all of the MIB handlers for the hub citizenship
    objects would need to be rewritten.

    Then there's the C/SNMP agent itself, which would need to be changed to
    interface to the Proteon-style handlers, or to serve as a translator in
    passing requests between the Proteon agent and the MAM.

    It's doable, but it's the sort of thing which could easily take several
    weeks of development, plus more time for testing.

Not *that* complicated.

Here's the picture:

		Comet-based brouter		 	+--- port interfaces (front
		(eg VNswitch)				|    panel or backplane)
		+--------------------------------------------------+
		|				|   SNMP 'driver'  |
		|  				+------------------+
 MAM mgmt	+---------+ 				|	   |
 including	| CSNMP	  |			+------------------+
 CSNMP gateway -| 'driver'|		        |SNMP MIB handlers |
		+---------+---------+           +------------------+	  
		|CSNMP MIB handlers |           |  public MIBS     |
		+-------------------+		+------------------+
		|    icom MIBS      |				   |
		+--------------------------------------------------+ 
			^				^
		  Hub citizen code		  Comet code

In an incoming SNMP message, there's a big long Object Identifier of
the MIB object that is being got or set.  The SNMP MIB handlers
can decode the OID and map it to the appropriate MIB object.  All this
is part of the 'Comet' code base that all 900 brouters (and 90's such
as the AW90).

In an incoming CSNMP message, there's a shortened Object Identifer.
The VNswitch "Hub citizenship" code decodes this OID and maps it to
internal MIB objects that manage backplane connections, etc.

The SNMP MIB handlers couldn't decode a CSNMP OID if they got one,
nor can the CSNMP MIB handlers map their requests to the SNMP MIB
objects.

The most efficient glue solution I've heard is to turn the CSNMP
OID's into SNMP OID's.  After all, one of the MAM's jobs is to
shorten up SNMP OIDs for CSNMP.  Adapt the code for the reverse
operation.  That's one part of the job.  The second part is to
pass the now-SNMP-like request over to the Comet SNMP handlers.

The first part was roughly implemented a while ago as an extension
to the hub citizenship code, by a clever engineer who no longer is 
available for this task.  VNswitch'ers, send us a volunteer, and 
we'll put 'em to work.  The second part is comet stuff, and you're
on your own.

	Dotsie

Well reading all that mess I think we are now far a way from a the
marketing message of 'ClearVisn'. Is it somewhere a project manager that tries
to maintain some coherancy accross all the product that are developed.
I see some difficulties to explains all this to my customers, I down know how
others are managed that but is really what we are calling now a days a
challenge.

No comments expected,
Robert Vandenberge nsis Belgium

[Posted by WWW Notes gateway]

    We PTR'd the lack of the "SNMP-Gateway" in the process of our
    testing of the VNswitch products. It remains to be seen if this
    function will ever not be implemented. The absence of this feature
    does tend to leave the products not in tune with other HUB products.
    I would think that any feedback from the field would be welcome
    on whether this feature is really needed. So make you comments
    to product manegement with the usual impact on dollars made or lost.
    
    Bob