[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

581.0. "900 IP Services" by QUIVER::SLAWRENCE () Wed Dec 22 1993 10:59

   This note is presented to try to give an overview of what IP
   Services is (and is not) and the roll that it plays in DEChub 900
   management. 

   ----------------------------------------------------------------

   A central design goal of the DEChub 900 Multiswitch is that it
   should be 'technology-neutral'; that is, its design should not be
   biased toward or away from any particular physical network media.
   This guided the design of the Multiswitch backplane, which is
   equally capable of carrying Ethernet and FDDI now and Token Ring,
   ATM, and other networks in the future with no backplane changes.
   It also guided the design of the Hub Management Agent Module (MAM)
   and its firmware.

   One aspect of the technological neutrality of the MAM is that it
   does not have a MAC for any network type - to have included one
   would have created both a bias toward that medium in the minds of
   hub designers and a requirement to provide a compatible network
   interface on future hub modules, even when doing so would not
   otherwise have contributed to the product.  Instead, the management
   interface to the hub was chosen to be a simple, low cost, well
   understood technology with no built-in bias toward any network: an
   asyncronous serial line (this also made backward compatibility with
   DEChub90 modules easy - the management channel changed from an
   asyncronous bus to ansyncronous star, a change not visible to the
   90 module).

   A consequence of not having direct access to any in-band network in
   the MAM is that a indirect access mechanism must be provided for
   it.  IP Services is that mechanism; it is a facility implemented in
   a hub module that allows the module to forward IP packets on behalf
   of the MAM between the serial management channel and the network
   interface(s) of the module.  This is functionally similar to a
   terminal server acting as a SLIP router for a PC (but not identical
   - see below); the module is configured by the MAM to accept IP
   packets with the destination address of the MAM and to perform
   proxy ARP for that address.  Another way of thinking of it is that
   the module is acting as a network interface adapter card for the
   MAM (in this case the adapter just has other jobs to do as well).

   It is important to note a few things that IP Services is NOT:

      o The MAM is not an IP Router - the IP Services address is that
        of the MAM, which in IP terms is a multiple-interface end
        station.  There is no way to configure the MAM to pass IP
        packets between any of its interfaces.  

      o An IP Services module is not a Router - it does not need an
        address of its own to perform IP Services (if it has one, it
        may not be the same as that of the MAM).  The backplane is not
        an IP interface and does not need its own IP subnetwork number.

      o The module is not the hub manager - other than acting as an
        interface device for its network(s), the module is not
        performing hub management functions.  As of this writing,
        there is only one module available that provides IP Services
        (the DETMM), so it is easy to make the mistake of thinking
        that that module is required for hub management (especially
        because of the way DEChub 90s are managed through the
        DECagent90 and DECbridge90 modules).  

   Providing IP Services is an important functional requirement for
   all hub modules under development; while a few may be produced
   which do not provide it at FRS, most will, and adding the function
   to a subsequent release of firmware will be high on the follow-up
   requirements list [Field people take note - it is incumbent upon
   you to keep the product managers informed as to the importance of
   this - every module added to the list of possible IP Servers is one
   less configuration restriction you have to worry about].
T.RTitleUserPersonal
Name		DateLines
581.1open Questions...VNASWS::HONISCHGuenter Honisch NSTC AustriaWed Dec 29 1993 07:3928
    I still have some problems understanding this:
    
    Lets assume I have a DH900 with one FDDI Concentrator and one
    DECrepeater900 
    They are not connected by any LAN interconnect (Bridge or Router)
    They just share the same Backplane
    
    If I enter the hub by OBM SLIP, I assume I can manage both modules.
    
    What happens if I come with inband SNMP from the Repeater side and want to
    access SNMP Parameters in the FDDI Concentrator ??
    Is it possible ??
    What happens really inside the Hub ?? (Packetflow ???)
    What IP Address is used in this Case?? (FDDI, ENET, HUB ???)
    
    
    Is there any detailed Description about the Hub Architecture ??
    Management busses,
    whats really the ability of the flexible Channels
    (# of Wires, Bandwidth/Wire...)
    
    BTW
    Are there any plans to run UTP FDDI or ATM over the Backplane
    I assume that we run FDDI now with 5 or 6 Bits parallel @ 25MHZ
    is there a chance to get more Busses by running MLT3 Coded FDDI or ATM
    over a single Wire ???
    At least theoretical, to have more Arguments against the new Synoptic
    Hubs etc...
581.2Answers to the first few questions.QUIVER::GALLAGHERWed Dec 29 1993 09:5078
>    Lets assume I have a DH900 with one FDDI Concentrator and one
>    DECrepeater900 
>    They are not connected by any LAN interconnect (Bridge or Router)
>    They just share the same Backplane
>    
>    If I enter the hub by OBM SLIP, I assume I can manage both modules.
 
Correct.
   
>    What happens if I come with inband SNMP from the Repeater side and want to
>    access SNMP Parameters in the FDDI Concentrator ??
>    Is it possible ??

Yes.  Once the repeater is set up as an IP service provider you can address
an IP\UDP\SNMP message to that IP address.

Either way (OBM or IP services via the repeater) you would access the
concentrator's parameters using the SNMP community string which the MAM
maintains for the concentrator.  For example, if the MAM's read-only 
community string is "public" and the concentrator is installed in slot
4 then you would access the concentrator using community string "public-4".
If the MAM's read-write community string is "private" you would use
"private-4".

>    What happens really inside the Hub ?? (Packetflow ???)

In the case of the repeater acting as an IP server for the MAM.

	- The repeater receives the IP message and forwards it
	  to the MAM.

	- The MAM receives the IP message, gives the encapsulated
	  data to UDP, which gives the encapsulated data to SNMP.
          SNMP decodes the message.  Part of the SNMP message is the
          SNMP community string.  The MAM looks up the community in
          its authentication database.  If a matching community string
          is found, the slot number of the line card being accessed
	  is also determined.

	  The MAM reformats the message using an internal hub protocol
	  (which looks suspiciously like a leaner/meaner version of
	  SNMP) and sends the message over the backplane to the 
	  line-card -- which in this example is a concentrator.

	- The concentrator processes the message just as it would
	  process an SNMP message which it received via it's in-band
	  link (i.e. the fiber).  It then sends the response message
	  over the backplane, back to the MAM.  (Again, using the internal 
	  hub protocol.)

	- The MAM receives the response message, translates it from
	  the internal protocol back into SNMP, and delivers it to it's
	  UDP/IP layers.  (Without going into details about the arp cache,
	  and stuff like that....)  The MAM then sends the IP message
	  containing the SNMP response over the backplane back to the 
	  IP servers, which in this case is the repeater.
 
	- The repeater sends the IP message over its datalink, back to
	  the NMS.

Summarizing:  

	1) NMS to repeater      (IP/UDP/SNMP)
	2) Repeater to MAM      (IP/UDP/SNMP)
	3) MAM to concentrator  (Internal protocol)
	4) Concentrator to MAM  (Internal protocol)
	5) MAM to repeater      (IP/UDP/SNMP)
	6) Repeater to NMS      (IP/UDP/SNMP)

This may sound complicated, slow, etc. but in practice is quite fast.
From an NMS it's hard to tell if you're going thru an IP server or talking
to the device in-band.  (Really!)

>    What IP Address is used in this Case?? (FDDI, ENET, HUB ???)
    
Do you mean MAC address?   I'm afraid you lost me.
    
						-Shawn
581.3more...QUIVER::SLAWRENCEWed Dec 29 1993 10:1025
    To pick up where .2 left off (nicely put, Shawn)...
    
    > What IP Address is used in this Case?? (FDDI, ENET, HUB ???)
    
    I assume that you mean in the case in which you have a hub with a
    repeater acting as IP Server and a Concentrator (not bridged or
    routed), and the NMS is on the ethernet.  You would use the IP address
    of the hub (MAM).  Either the repeater or the concentrator might also
    have IP addresses of thier own, but need not.  Using the IP addresses
    of the devices themselves the NMS could manage the repeater (as a
    standalone device) but could not reach the concentrator; so just
    giving an address to the hub is enough.
    
    Re: how we run networks on the backplane:
    
    The specifics of the encoding we use on the backplane are not public;
    only the network interfaces of the line cards need to conform to the
    relevant standards.  The hub architecture allows for tremendous
    flexibility in future hardwares' use of those backplane signals, and
    there are a number of things in development that will provide more
    usefull bandwidth over the backplane.
    
    As for 'Arguments against the new Synoptic Hubs', how about 'They claim
    to be SNMP managable but have not published thier MIBs' (we have).
581.4A light in the darknessBACHUS::VANDENBERGHEThu Feb 03 1994 13:1329
        Hi,

        0. explaination is a light in the darkness of the Hub management
        vision.
        That is really the info we need even more ...

        Things I don't understand:

        - Why in a DEChub 900 is it necessary to give an IP address to a
          module having a SNMP agent (like a DECserver 900TM)?
          The MAM recognize it but is not able to manage it if no IP address is 
	  configured 

        - If a DECAgent90 is also used, is  the MAM sharing the same management
          bus and who is the master on this bus.

        - For what module can the MAM be used as proxy?
          DECrepeater 90 ?
          DECMAU 900 ?

        - Is it always necessary to have a module connected to the ThinWire
          Channel in order to be able to configure and manage it?

        Shortly, is it a technical description of the management mechanism
        available on the network?

        Thanks in advance,
	Robert
581.5QUIVER::SLAWRENCEThu Feb 03 1994 13:4948
    > 0. explaination is a light in the darkness of the Hub management
    >    vision.
         
    Thanks - we try.
    
    > - Why in a DEChub 900 is it necessary to give an IP address to a
    >   module having a SNMP agent (like a DECserver 900TM)?
    >   The MAM recognize it but is not able to manage it if no IP address
    >   is configured
     
    The DECserver modules chose not to allow the MAM to act as a manager.  
    
    > - If a DECAgent90 is also used, is the MAM sharing the same management
    >   bus and who is the master on this bus.
                       
    In the 900 the management channel is not a bus - it's a star, with the
    MAM at the center.  If the MAM is not assigned any IP address it will
    revert to '90-mode' and forward messages on the star to make it look
    like a bus, allowing a 90 bus master (DECbridge90 or V2.0 DECagent90)
    to manage the hub (of course, they don't understand 900 modules and
    can't provide access to many 900 features).
    
    > - For what module can the MAM be used as proxy?
              DECrepeater 90 ? - YES (also repeater 900's)
              DECMAU 900 ?     - YES
    
    	See 519.0
    
    > - Is it always necessary to have a module connected to the ThinWire
    >   Channel in order to be able to configure and manage it?
     
    No - the management channel is not the Thinwire.  Some modules (all
    DECservers, DECbridge90) do not support anything but in-band
    management, so they have to be on _some_ network.
                   
    > Shortly, is it a technical description of the management mechanism
    > available on the network?
      
    Actually, there is... sort of.
    
    We have set up a DEChub Engineering World Wide Web server on the
    internal network.  We are gradually populating it.  You can reach it
    at:
    
    	http://www-dechub.lkg.dec.com
    
    I'll post a new note with more details