[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

22.0. "WILL DEC-AGENT MANAGE MORE THEN 1 HUB" by TROOA::FARRAUTO () Thu Jan 23 1992 17:16

    I have a site which will have 6-7 Dechub-90's. Each hub will have a
    Decbridge-90 and various quantities of 10-BASE-T modules. Do I need
    a DEC-Agent90 module in "each" Dechub backplane or will one DEC-
    Agent90 installed in one of the HUBS provide management for all the
    Dechub-90's.
T.RTitleUserPersonal
Name
DateLines
22.1Depends on the capabilities of the mgmnt stationNOHOST::LEVINBryan, LENaC Engineering, MLO3-3/U39Thu Jan 23 1992 20:1842
    Well, there's different answers, depending on the management station's
    capabilities.
    
    With the 'smartest' mgt station (ie, HUBwatch under DECmcc/MSU [Ultrix])
    you'll be able to manage several DEChub 90's with one agent
    (DENMA).  It will _not_ matter whether the DENMA is clicked into a
    DEChub 90 or left standalone on the same extended LAN (a 'floater', in
    our informal parlance).  As long as the DENMA can 'reach' the DECbridge
    90, and the DECserver 90L modules, you're in business.  (This extended
    LAN restriction is due to the fact that the DENMA communicates to the
    bridge and server via LAN-based, (non-routable) protocols such as RBMS
    and MOP/console_carrier.  If, however, you have _routers_ between the
    standalone DENMA and the rest of the hub modules, you're out of
    business.
    
    With the current level of support with DECmcc/Director [VMS], (ie,
    none), you'll need one management module per hub.  This is because the
    SNMP architecture (SNMP Access Module) under MCC cannot handle proxies
    the way we need to.  It cannot, for example, access _discreet_
    manageable entities that have the _same_ IP address in common, and only
    differ by the SNMP community name.  But, when the HUBwatch application
    reaches a point of stability for MSU, we'll port the whole mess over to
    Director, and the restriction of one DENMA per DEChub 90 should be
    removed.  There should be no difference in the quality of management
    from either MCC or MSU at that point.
    
    With our joint development effort with DSI, they'll also be
    able to take advantage of using one DENMA per "many" DEChubs 90s.
    
    As for other vendors' management stations, it depends on their ability
    to offer proxy the way we need.  So far, most management stations have
    very limited flexibility (out of the box) to support our proxy method. 
    But, since the new SNMP security model is closing in on becoming a
    standard, I'd expect that more and more agents will support this.  This
    new proposal offers more than just security - it _standardizes_ the
    notion of proxy.  At that point, it's "simply" a matter of time to
    switch our method over to align with the new proposal.
    
    .bl
    
    
    
22.2Graphics to help illustrate .1NOHOST::LEVINBryan, LENaC Engineering, MLO3-3/U39Thu Jan 23 1992 20:3559
    In addition, let me provide a bit of an illustration to accompany .1 :
    
    
    
                                        D E C h u b  9 0
     network           :- - - - - - - - - - - - - - - - - - - - - - - - - -:
    management ------->: DENMA                                             :
     station           :  +-------> DECbridge 90 -------> DECrepeater 90C  :
                       :  |                                                :
                       :  +-------> DECserver 90L                          :
                       :                                                   :
                       :- - - - - - - - - - - - - - - - - - - - - - - - - -:
    
    
    This situation will work.
    
    
    
    
    
                                        D E C h u b  9 0
     network            :- - - - - - - - - - - - - - - - - - - - - - - - - -:
    management --> R -->: DENMA                                             :
     station       ^    :   +-------> DECbridge 90 -------> DECrepeater 90C :
                   |    :   |                                               :
                   |    :   +-------> DECserver 90L                         :
                   |    :                                                   :
                   |    :- - - - - - - - - - - - - - - - - - - - - - - - - -:
                   |
      (this is an IP router)
    
    This situation will also work.
    
    
    
    
    
    
     network
    management
     station                             D E C h u b  9 0
       |               :- - - - - - - - - - - - - - - - - - - - - - - - - -:
       | (IP)          :    (RBMS)               (private)                 :
       v               :  +-------> DECbridge 90 --------> DECrepeater 90C :
     DENMA ----> R -------+                                                :
                       :  +-------> DECserver 90L                          :
                       :    (MOP)                                          :
                       :- - - - - - - - - - - - - - - - - - - - - - - - - -:
    
    This will _NOT_ work.  There is a Router (R) in between the DENMA and
    both the DECbridge and DECserver.  The DENMA communicates to the bridge
    via RBMS (LAN only), and to the server via MOP (LAN only).  The Router
    will _block_ these protocols, so the management traffic will not flow
    to the hub modules.
    
    
    Hope this helps.
    
    .bl
22.3DECagent can manage 4 hubsEMDS::SEAVERLENAC Net Mgnt Mktg 223-4573Sat Jan 25 1992 01:5312
    A DECagent will manage at least 4 extended (double hubs) on the same
    extended LAN.  It may be able to manage more, but we will not know how
    many until we have run some more tests.  This means you could manage 15
    slots of repeaters per hub if you had the agent running stand alone. 
    This is definitely different than our competitors who require one
    agent per hub.  

    FUTURES: Newer terminal servers will have agents in them as the 90TL
    does.  Repeaters will probably never have agents, altho we are thinking
    of modifying the agent so it can manage the repeaters directly without
    a bridge and also using a router instead of the bridge to manage the
    repeaters (might even have its own agent in the router)
22.4HUBwatch for MSU and MCC?HGOVC::LILLIANTANGWed Feb 19 1992 06:277
Is HUBwatch for MSU going to be a separate layered product that
works together with MSU or is it going to be incorporated in a future
release of MSU?

Are there any plans to incorporate the hub graphics for MCC?

thanks
22.5YesNOHOST::LEVINBryan, LENaC Engineering, MLO3-3/U39Wed Feb 19 1992 12:064
    RE: .4:
    	Look at note # 6.8
    
    .bl
22.6HUBwatch is a separate option, not imbedded in MSUMEMIT::FORRESTThu Feb 20 1992 16:498
re 22.4

The present strategy is that HUBwatch will always be an optional add-on to 
DECmcc MSU. It will also be an option to DECmcc 1.2, although it could get 
rolled into DECmcc BMS at some point.

jack