| .0> about the hub where the DecAgent90 resides. How could one switch over to
.0> manage the other hubs?
Using console command "[8] Change Default Community" you can switch
between the communities which have been configured into the DECagent's
management table. Obviously, you need to configure in these
communities (hubs) before the information can be displayed. You can do
this either from HUBwatch or through the DECagent console's
"[2] Add Community" command.
.0> Moreover what criteria does the DecAgent90 used to decide 1) whether a
.0> hub is a standalone 8-slots hub or being part of a 16-slots hub? 2)
.0> whether a certain pair of hubs can be managed by this particular
.0> DecAgent90?
1) For the hub in which the DECagent resides, the DECagent can read its
backplane ID to determine if it is in a hub or is standalone. In
conjunction with a DECbridge, the DECagent can sense if the hub is an
8-slot or 16-slot (daisy-chained) hub.
2) As long as there is a DECbridge in a remote hub (8- or 16-slot), the
DECagent can manage the bridge and repeaters in that hub. All you need
do is tell the DECagent which slot the bridge is in and what its MAC
address is. Terminal servers are managed directly via MOP and do not
require the bridge to be present. Just tell the DECagent what slot
they're in and what their MAC address is.
Roger Gaudet
DECagent 90 devo
|
| Hi Roger,
Thanks for the quick reply. I read other notes in the conference and understand
that each hub would also need to assume a unique community name in order for
hubwatch to manage them. This requirement could create an administration
nightmere for network manager who need to manage hundreds of hubs in their
corporate network. The task of allocating and maintain all these community
name is enormous.
Have I mis-interpreted the situation or it is not quite as bad as that?
Why does HubWatch insist on unique community name on each hub?
How do you expect DecMcc managers to setup the SNMP AM to cope with these
vast number of community name?
Moreover, could you briefly explain the mechanism used by DecBridge and
DecAgent90 to decide whether a hub is 8 or 16 slot? From what I can gether, the
way it works is if the DecBridge see some other ethernet address on the diasy
chained thinwire port on the backplane, it will just assume that there is
another hub cascaded to it. So it is a 16 slot hub. Is this correct? If so,
then what will happen if the thinwire port is connected to a DEMPR where there
are a number of other hubs connected to it?
Regards,
Denny.
|
| Denny,
I think you're confused about communities. The way SNMP (and HUBwatch) works
is that you manage an agent/community-string pair. So, if you have 600 agents,
and they each have one community string ("public", for example), then you have
600 SNMP manageable (and HUBwatch manageable) things.
Now if we change 3 of those 600 agents such that they each have two community
strings, with the agent/community-string pairs called agent_598/"ocoee",
agent_599/"ocoee", and agent_600/"gauley", then you now have a total of 603
SNMP manageable (and HUBwatch manageable) things.
And, by the way, those things are separate, distinct, and unique SNMP
communities. 603 of them. So, the 603 unique communities are therefore:
1: agent_1/"public"
2: agent_2/"public"
[...]
600: agent_600/"public"
601: agent_598/"ocoee"
602: agent_599/"ocoee"
603: agent_600/"gauley"
OK, so what does this mean for DECagent 90s and DEChubs? Well... Let's say
you've got a total of 5 different DEChub 90's and you've got 2 DECagent 90's.
The two DECagent 90's are called chatooga and nantahala. You're not feeling
very creative the day you set-up your DECagents, so you call your hubs:
- first hub: chatooga/"hub_1"
- second hub: chatooga/"hub_2"
- third hub: chatooga/"hub_3"
- fourth hub: nantahala/"hub_1"
- fifth hub: nantahala/"hub_2"
Bingo! Five different communities (hubs) that can be managed by HUBwatch.
In summary, the community string by itself doesn't mean anything. What is
meaningful is the agent/community-string pair. It's that PAIR that must
be unique, it's that PAIR that describes a hub or a standalone device or
whatever, and it's that PAIR that gets managed.
Hope this helps,
Tom Hood
HUBwatch paddler
|
| Tom is correct. The agent/community string pair is the meaningful
entity, not just the community string. Good explanation Tom!
As for the discovery of a 16-slot hub, the thinwire connection has
nothing to do with it. You can terminate the BNCs on the side of the
hubs, connect the async management cable between the hubs and discover
the 16-slot hub configuration (although in this case you'll be limited
to having the bridge and agent in the same hub). The bridge transmits
WhoAreYou requests on the backplane transmit line, then listens on the
receive line for a period of time. This determines who's in the hub in
which the bridge resides. The bridge then tranmits on the receive line
and listens on the transmit line. If a response is heard on the
transmit line, there's an extended hub. In the configuration where
there's a DECagent 90 managing the hub, the WhoAreYou requests are
prompted by an RBMS request from the DECagent to the DECbridge to find
out what devices are in the hub. The DECbridge then forwards the
backplane WhoAreYou responses to the DECagent via an RBMS response
packet, and the DECagent figures out what devices are in what slot.
Hope this helps.
...Roger...
|