Conference netcad::hub_mgnt

    See topic 519 for a description of the management of older 90 modules
    in the 900.
    
    The DECbridge 90 is managable only via a DECagent 90 (which need not be
    in the same hub - the management is in-band.
    
    Much more important - putting 5 DECbridge 90s in a single hub is not a
    supported configuration unless the total number of addresses in your
    network is (and will certainly remain) less than 200.  What you have
    done is put the Workgroup ports of the bridges on the same LAN (the
    backplane); that LAN will become the backbone of your network, causing
    all addresses to appear there and overflow the address table of the
    DECbridge.
    
    IT DOES NOT DO THE RIGHT THING WHEN THIS HAPPENS.
    

    Thanks for the warning around the unsupported configuration.
    
    While the DEChub will have these DECbridge 90 modules.  The DECbridge
    90 modules will be connecting into other DECbridge 90s.  An example is
    shown below.
    
    +--------------------+				+--------+
    | DH900      | DB90FL|------------------------------| DB90FL |
    +--------------------+				+--------+
    
    Does this help us in any way, in terms of controlling the number of
    entries in the forwarding database?
    
    
    Also I am worried about management of the DEChub 900 Out-of-band (OOB).  
    It is key that I be able to manage this particular hub OOB for security
    purposes.  Are there any future plans to support management of HUB90
    modules in a DEChub 900 (using the HUB manager) when there are no HUB
    900 modules in the hub?
    
    The customer is currently using HUB 90 modules but may upgrade to HUB
    900 modules in future.  This is why they have purchased a HUB 900 - it
    gives them a smooth upgrade path.
    
    Regards,
    
    John
    

    
    > While the DEChub will have these DECbridge 90 modules.  The DECbridge 
    > 90 modules will be connecting into other DECbridge 90s.  An example 
    > is shown below.
    
        +--------------------+                              +--------+
        | DH900      | DB90FL|------------------------------| DB90FL |
        +--------------------+                              +--------+
    
    > Does this help us in any way, in terms of controlling the number of
    > entries in the forwarding database?
     
    No - because the problem is the number of _SOURCE_ addresses that the
    DB90 whose Workgroup (backplane) port sees.  All multicast and
    broadcast packets from all stations will get through and the bridges in
    the central hub will try to remember them - quickly overflowing the
    address table.
    
    The good news is that having two bridges is redundant anyway - replace
    the bridges in the central hub with DECrepeater90FA (DEFAR).  They
    provide the remote fiber link to the hubs backplane thinwire.  Exactly
    the same packets will be transmitted (the second bridge is redundant)
    at a fraction of the cost.  
    
    The better news is that the DECrepeater90FL is managable through the
    DEChub900 agent (see the note I pointed to earlier) right now.
    
    At present, there are no plans to support management of the
    DECbridge90s through the 900 manager out of band (code space problems
    in the bridge).  This would be a big job; if you really think it must
    be done (even given the upcoming bridge 900MX) then you might want to
    let product management know which functions in the bridge you could do
    without to get it.
    

    
    It would help us a lot if we could tell whether the bridge ports were
    up or down and whether it was forwarding or not.  We would not want to
    set up filtering tables or monitor traffic loading.
    
    JG
    

    Please clear up some confusion for me (and a customer).  Regarding
    management of DECbridge 90's sitting in a DEChub 900MS, I'm told
    that HUBwatch 3.0 for VMS will be able to manage the bridge WITHOUT having
    a DECagent 90 module around.  Could someone confirm this for me?
    Is there any documentation available covering this future feature? 
    When is V3.0 scheduled to be released?
    
    Thanks for the help,
    Ray Cultrera

    
    You will need a DECagent90 somewhere to manage the DECbridge90.

    OK,
    
    The customer, for security purposes, needs to manage this hub
    Out-Of-Band.
    
    I have installed a DECagent 90 in the HUB, and can connect to it OOB
    from a port on a DECserver 90TL.
    
    The DECagent 90 is running the X2_0_0 software.
    
    If I run hubwatch and ask it to connect to the DECagent 90 it does so. 
    However, it draws me a picture of a DEChub 90, rather than a DEChub
    900. 
    
    What can I do to get a picture of a DEChub 900?
    
    Regards,
    
    John
    

    You must give the dechub900 an IP address for it OBM port. You then
    use slip to connect to the 900's OBM port. There is a note here
    that describes how to do the slip set up.
    
    Bruce

    Bruce,
    
    The problem I am having is that I cannot manage DECbridge 90 or
    DECbridge 90FL, that are configured in a DEChub 900, modules 
    out-of-band(OOB).    The DEChub 900 software does not have the
    capability to do this.
    
    What I am attempting is placing a DECagent 90 in the Hub to provide the
    OOB management capability for the DECbridge modules.  I am having two
    problems in doing this.
    
    1.  When I use HUBwatch over SLIP OOB to the DECagent 90 it paints a
    picture of a DEChub 90, rather than a DEChub 900 on the screen.
    
    2.  This method still does not let me manage DECbridge modules (I
    cannot add them to the configuration).
    
    I am using version x2_0_0 of the DENMA software.
    
    Is there anyay I can get a picture of a DEChub 900 when I attempt to
    manage it via the console port of a DECagent 90?
    
    Is there anyway I can manage DECbridge 90s OOB when they are configured
    in a DEChub 900?
    
    Any help appreciated.

>    I am using version x2_0_0 of the DENMA software.

Maybe it's because of this old firmware. The current is T2.0.11.

*Robert

    Thanks to everyone for their help in getting me closer to an
    answer/solution.
    
    I have now resolved the problem...
    
    What needs to happen is...
    
    Configure the DECagent 90 so that it acts as an agent for the DECbridge
    90 and 90FL modules.  You can then access the HUB through its OOB port
    and still manage the DECbridge modules.
    
    Out-of-band (OOB) management of DECrepeater 900 and 90 modules in a 
    DEChub 900 is no problem.
    
    To manage DECbridge 90 and DECbridge 90FL modules OOB in a DEChub 900
    you will require a DECagent 90 (DA90).
    
    We configured the DECagent 90 with t2.0.11 of the DENMA software and
    set it up for OOB management via SLIP.  We will use v2.0 when it is
    available.
    
    We invoked HUBwatch and gave it the ip-address of the console port of
    the DA90. 
    
    From Manage Table option we added a community name for each DECbridge
    90 and 90FL we wanted to manage.  Each of these names was unique and
    we did not use the community name "public".
    
    For each community name, in turn, we did a "Make Current" we had a
    DEChub 90 picture displayed.  Then we added a bridge giving the
    appropriate MAC address.
    
    If we then exited HUBwatch and re-entered - this time using the
    ip-address of the DEChub 900 OBM port, we were displayed a picture of a
    DEChub 900 and were able to manage the DECbridge90 and DECbridge 90FLs.
    
    COMMENTS:
    
    Although this provides us with a very useful workaround, the mechanism
    for implementing it is not simple.  However a workaround to gain the
    functionality will always be preferrable to no functionality.
    
    Hope this helps,
    
    John