| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1332.1 | Those 3 little words... "No can do." | SLINK::HOOD | I'd rather be at the Kennebec | Mon Aug 22 1994 13:46 | 10 |
| Hmmmm. You want HUBwatch V3.0 to recognize devices that didn't exist when
we designed HUBwatch V3.0. That is a problem. :-)
As far as new variations of the device (with new sysObjectId's), they have
to be registered in the HUBwatch sources. It's too late for 3.1, but it can
be added to V4.0. Talk to me off-line about how we do this.
You cannot make HUBwatch V3.0 send RESET to the wanrouter 90.
Tom Hood
|
| 1332.2 | sysOid registration. | NACAD::GALLAGHER | | Mon Aug 22 1994 14:19 | 32 |
| The following OIDs are registered:
>dec OBJECT IDENTIFIER ::= { enterprises 36 }
>ema OBJECT IDENTIFIER ::= { dec 2 }
>sysObjectIds OBJECT IDENTIFIER ::= { ema 15 }
>
>decWanRouter90EI OBJECT IDENTIFIER ::= { routers 9 }
> wr90EIversion1 OBJECT IDENTIFIER ::= { decWanRouter90EI 1 }
>
>decWanRouter90EW OBJECT IDENTIFIER ::= { routers 10 }
>
> -- 2 port WAN Router.
> wr90EWversion1 OBJECT IDENTIFIER ::= { decWanRouter90EW 1 }
>
> -- a DECwanrouter90EW configured to run as a
> -- Single Line Leaf Router.
> wr90EWversion2 OBJECT IDENTIFIER ::= { decWanRouter90EW 2 }
>
> -- a DECwanrouter90EW configured to run as a
> -- Single Line Branch Router.
> wr90EWversion3 OBJECT IDENTIFIER ::= { decWanRouter90EW 3 }
Contact DSSR::REGISTER if you have questions about OID registration.
You'll also need to coordinate this with Tom (.1).
>Where are these sysoids defined? Are we sending the wrong numbers, or is
>HUBWATCH wrong? Should the software version number be added onto the end of the
>sysoid like this? I couldn't find anything in the spec about this.
Defined by the registrar. Probably. No. No. What spec? ;-)
-Shawn
|
| 1332.3 | Resets. | NACAD::GALLAGHER | | Mon Aug 22 1994 14:34 | 21 |
| >How do I get HUBWATCH (V3.0.0) to send the reset command?
I don't know.
>Is there any point in supporting the RESET command? SPOTS doesn't even have a
>way of indicating that it supports RESET according to the 'left hitchcock'
>specifiaction I have (revision 1.1.2.7 94/01/21), because it uses DEChub-90
>minimal identification rather than the Generalized Reply used by the EW and EI.
The DEChub900 Hub Manager (aka MAM) implements a MIB called the "Chassis MIB".
The DEChub900 Chassis MIB contains objects which allow devices to be reset.
When set to the proper value, like say "reset(1)", the Hub Manager will try
to reset the device. If the device supports CSNMP, the CSNMP protocol is
used to reset the device. If the device supports LH, an LH reset command
is sent to the device. If the device doesn't support the LH reset command,
then nothing happens, oh well. If the device does support reset then it
resets itself and everyone's happy.
This is one reason to support the LH reset command. There may be others.
-Shawn
|
| 1332.4 | Left Hitchcock - It's not Alfred's brother. | CUJO::HILL | Dan Hill-NetConsultant-Denver-553-3624 | Wed Oct 05 1994 18:44 | 15 |
| I must be living a sheltered life. I am not at all familiar with 'Left
Hitchcock'.
It is supposedly the Management protocol used to manage these:
-DECrepeater 90C
-DECrepeater 90T
-DECrepeater 90T+
-DECrepeater 90FL
-DECrepeater 90FA
What is LH?
How does the DECagent 90 use it to manage the above repeaters?
Thanks,
Dan
|
| 1332.5 | You're lucky to be sheltered from this... | NETCAD::BRAGDON | | Wed Oct 05 1994 19:10 | 7 |
| Left Hitchcock is an ASCII only, single master, request/response,
combination datalink and application protocol.
Actually, it is related to Afred, although you are correct in stating
that 'LH' is not his brother. I believe 'LH' got its name from the
Hitchcock-like profiles of the Request '{' and Response '}' symbols.
One of them would be 'LH' ?
|
| 1332.6 | It's named after Al himself. | NETCAD::GALLAGHER | | Wed Oct 05 1994 19:18 | 31 |
| Yeah, I guess you need to get out more ;-)
Briefly, the Left Hitchcock protocol was invented for the DEChub90. It's
a simple ASCII-based protocol. Commands are proceeded with the ASCII "{"
character. (If you squint at the "{" character you can see Alfred Hitchcock's
likeness in profile. ;-)
The DECagent90 uses the LH protocol to manage local devices. Typical
commands are "{ 4 <cr>" for "who's in slot 4". Additional commands set
and get repeater characteristics.
To manage remote devices, the DECagent90 uses a remote DECbridge90 to
proxy LH commands to repeaters in the same hub and the DECbridge90.
The LH protocol is still used in the DEChub900 to manage "legacy" devices
like the old repeaters. In this case the Hub Management Agent Module (MAM)
sends LH commands to the repeaters. A DECagent90 is not needed to manage
local LH devices. The MAM acts as a proxy agent in this case: receiving
SNMP messages, and possibly translating them to LH commands to manage
the LH devices.
The LH protocol was judged to be too primitive for a mid/high-end hub
like the DEChub900. The Compressed-SNMP (CSNMP) protocol was invented
to replace it. Most new hub modules, whether in the 90 or 900 form-factor,
use CSNMP. Some rudimentary LH commands are used to indicate that the
module is capable of speaking CSNMP.
That's it for the history lesson. If you'd like more detail, let me know
and I'll mail you the LH protocol specification.
-Shawn
|