|
The DECagent 90 actually speaks RBMS to the DECbridge 90, which acts as the
bus master for the backplane management bus. The repeaters are polled by
the bridge over this bus. Perhaps, in a future release, the DECagent 90
can act as the bus master for the backplane bus, but it will not behave that
way in the initial release.
No doubt our competitors will jump all over this, and point out that it's
bad, and the wrong way to do things. In reality, one or more RBMS packets
are spawned for each SNMP packet. If this overly concerns your customer, it
can be dealt with by putting a DECagent in each hub with a bridge and then
filtering RBMS traffic toward the backbone.
Our reason for going with the proxy (translating SNMP to RBMS and MOP)
approach was to lower the cost of SNMP management for the customer. This
approach allows us to share the cost of the SNMP management module
(DECagent 90) across multiple hubs. It also allows us to manage standalone
DECbridge 90s and DECserver 90L's via SNMP without adding the cost of an
SNMP agent to those modules.
Furthermore, the DECagent 90 works standalone, so it doesn't have to take
up a slot in any of the hubs that it's managing.
If the customer still seems to be buying the competitor's argument, you
might try pointing out that our mangement module is not a single point of
failure for a whole hub. Some competitors combine SNMP management and
retiming on a single module. If that module fails, the customer has lost
management AND the repeating function for the whole hub. All connections
will be dropped. We don't need a retiming module (or a controller card),
so all you lose when the DECagent 90 goes down is SNMP management. You can
still manage the hub using MOP!
|