Conference netcad::hub_mgnt

1:  Just about any and all HUBwatch documentation (since V1.1) explains that 
    the DECwanrouter 90 is displayed by not managed by HUBwatch.  The reason
    is pretty simple:  It barely supports SNMP, does not SETs, and anything
    useful is pretty much unavailable.

    Version 4.0 provides about the same support to the new Access Works
    RouteAbout 90, except that double-clicking on the bezel will produce
    a TELNET session window.  

    When the DECswitches support routing, expect to see better routing
    management through HUBwatch.

3: Left hichcock is the name of a simple backplane management protocol which
   originiated in the DEChub 90.  It does who-are-you functions and a few
   other commands and responses.  Pretty much every small module supports
   it (that's how autodiscovery is done in the DEChub 90)

If HUBwatch knows that a slot contains a DECwanrouter 90, why does it put up
a 'no agent in this slot' message?  This message

    1.  Is inaccurate (according to .-1, the box has a rudimentary agent).

    2.  Does not mention the feature limitation, leading managers to think
        that double-clicking should work and that HUBwatch is broken.


A dialog like the following would be more user-friendly.

    +----------------------------------------------------------------------+
    |                                Notice                                |
    +----------------------------------------------------------------------+
    |                                                                      |
    |  This slot contains a DECwanrouter 90.  HUBwatch cannot manage this  |
    |  type of module.  For more details, see section X.Y of the HUBwatch  |
    |  user manual.                                                        |
    |                                                                      |
    |                            +-------------+                           |
    |                            | Acknowledge |                           |
    |                            +-------------+                           |
    +----------------------------------------------------------------------+

    Looks like we're mixing DECwanrouters 90 and DECbrouter 90s here.
    
    Speaking for the DECwanrouter 90.  When the firmware is running 
    the DECwanrouter 90 will speak the left Hitchcock protocol and be
    identified by the agent.  However, when the DECwanrouter 90 is then
    downline loaded with software it no longer speaks the left Hitchcock
    protocol and is unknown to the agent.  The reason for this is the
    DECwanrouter 90 was a port of the earlier DECwanrouter 250/150 code
    and hub support was not there.  The processor had the ability to
    drive a certain number of ports (can't remember the number offhand)
    which were all used for network (DECnet, IP, etc.) communication ports.
    There wasn't a port left to talk on the backplane without some rework 
    that was considered a lower priority when shipping criteria was reviewed.
    
    So that's a bit of history for you.
    							John

    	And, speaking for the DECbrouter 90, it *does* support full SNMP 
    MIB-II, as well as the Cisco Private MIB, with extensive support for
    both GETs and SETs of router and port parameters and statistics.
    But.... Hubwatch won't talk to it, since the Cisco private MIB isn't
    compiled into hubwatch. Hubwatch (VMS, anyhow, I believe) lets you
    open a telnet session to the DECbrouter for management purposes.
    Integration of the Cisco MIB would be a nice feature for Hubwatch;
    there's a lot of them thar DECbrouters out there....
    
    Chuck Ouimette
    ESE
                  

Ahem... The Cisco MIB *is* in HUBwatch!  Just about every counter or status
you see in the HUBwatch screens for the DECbrouter is from the Cisco private
MIB.

The SETs for the DECbrouter are not implemented in HUBwatch, because there
are many, many, many, many, many, many, many, many, many, many, many routing
variables.  Simply having GUI access to the hundreds of things you can set
is not more convenient or easier to use than the console (TELNET) interface.
(Also, at the time, a lot of important SETs were not accessible through SNMP).

At some point, HUBwatch will have *real* router management capabilities, 
which will, presumably, automate the process and make router managment easier.
That's a big effort, so for the short term, what you see for the DECbrouter is
what we do.

    Hi,
    I would like to thank everybody that replied, but I still don't have a
    good explanation for the DECbrouter error when I double click on it.
    
    OK, here is what I have so far:
    1. Using hubwatch, I enter the address of the DECbrouter, and the
       brouter module appears, so I know that the brouter mib have been
       compiled for the brouter, at least the "get" (not yet that familiar
       with snmp but working at it).
    2. Using hubwatch, I now enter the address of my DEChub900 MAM and the
       certain hub90 style module are identified.
       Question: What is the protocol used to discover the 90 style
       modules, are we using left hitchcock, and if yes, is the route from
       the MAM to the 90 style module over the Thinwire (as far as I know
       the serial management bus found in the DEChub90, is not present in
       the dechub900 backplane, and the 90 style module do not connect to
       the star wired bus).
    3. Once the 90 style module has been identified by the MAM (dechub900 
       backplane mib ??), are we using the same compressed SNMP protocol as
       is used for the 900 style modules, or the MAM is smart enough to
       determine that it's a 90 style module and send the snmp packet
       unchanged to it via the thinwire.
    
    There's got to be somebody in this conference that knows this. I need
    an explanation, for myself, and for a customer for which I will teach
    them the magic of hubwatch.
    
    Thanks again,
    Paul

    	Re: .5,
    
    Thanks for the correction. I just went and tried it, and yup, the beast
    worked. And, to correct another piece of implied misinformation in my 
    earlier reply, HUBwatch for Windows does indeed provide the telnet 
    interface for the management of the DECbrouter.
    
    -chuck
    

You must have a LAN connection between your workstation and the DECbrouter 90.

The MAM is not involved at any point whatsoever in managing that DECbrouter 90,
except to tell HUBwatch, "Hey, HUBwatch!  I have a DECbrouter 90 in slot 3! 
It's IP address is 12.34.56.78 and its community is 'blotto'".  Which hidden
protocol the MAM uses to discover modules plugged into the backplane, I don't
know.  Someone else is welcome to jump in if they care.

HUBwatch then sends an SNMP message DIRECTLY to the DECbrouter 90.  The MAM
does not participate in any way at all in the management of the DECbrouter 90.
This is why if you do not have a LAN connection between your workstation and
the DECbrouter 90, you cannot manage it.  The MAM cannot perform proxy for the
DECbrouter 90.  

Tom Hood

OK Tom, I'll jump in.  The MAM uses the Left Hitchcock (fondly called LH)
protocol to get the information from the brouter and passes it on to HUBwatch
via SNMP when HUBwatch requests information about the front panel (hub) view. 
The MAM does the exact same thing for the DECagent 90, DECrepeater 90FS and
90TS, after which time, as Tom said, the MAM is not involved in any way with the
management of these devices (except to continously poll for their existence in
the hub).

...Roger...

	Re: .8, Tom,
    
>The MAM is not involved at any point whatsoever in managing that DECbrouter 90,
>except to tell HUBwatch, "Hey, HUBwatch!  I have a DECbrouter 90 in slot 3! 
>It's IP address is 12.34.56.78 and its community is 'blotto'".  Which hidden
    
>HUBwatch then sends an SNMP message DIRECTLY to the DECbrouter 90.  The MAM
    
    	What am I doing wrong? The above indicates that the MAM passes the
    IP address of the DECbrouter to HUBwatch, but the only way I have found
    (HUBwatch 3.1) to manage the DECbrouter via HUBwatch is to *manually*
    put the IP address of the DECbrouter into the Community table. If I
    just try clicking on the DECbrouter as it's in the HUB display, an
    error pops up. Does the MAM really pass the IP address of the
    DECbrouter to HUBwatch? Where can one go to see this? Is this a 4.0 
    feature?
    
    			thanks,
    
    -chuck
    

OK.  You caught me.  I lied.  This morning, while lying in bed watching the
cheerful hosts of "Good Morning America" dye Easter eggs using onion skins, I
started thinking about ways I could confuse people today.  That was the best I
could come up with today...

What actually happens is the MAM tells HUBwatch, "Hey, HUBwatch!  I have a
DECbrouter 90 in slot 3! It's MAC address is 08-00-2B-22-33-44."

HUBwatch reads its agents file to translate that mac into an ip and community.

Caught and red-faced,
Tom Hood
HUBwatch

    	Thanks for the clarification; I figger'd you were just trying to pay 
    me back for my malicious lies re: HUBwatch and the Cisco MIB in .4....
    :^). 
    
    -chuck

    Hi,
    The error that I reported in my original note only occurs if I'm 
    connected OB. When I connect Inband, it works as expected.
    Thanks to all that replied.
    
    Paul

    To add to my last note, when connecting outband, you have to use the 
    "make current" option from the community table in order to manage the
    DECbrouter, at least that's the only was that it worked for me.
    
    Paul