| LeNAC is currently in field test with an upcoming product, the DECagent
90. This is an SNMP agent that can be used either stand-alone or in a
DEChub. It acts as a proxy agent for the following devices (which
normally only speak MOP or RBMS):
DECserver 90L and 90L+
DECrepeater 90C and 90T
DECbridge 90
As usual with the DEChub, you need the bridge to manage repeaters in
the same hub. For more information on DEChub 90 management products
including draft SPDs and manuals see EMDS::MANAGEMENT:READ_ME.TXT.
By the way, the DECmcc SNMP AM does not implement agent support very
well. The problem is that SNMP uses community strings as
"subaddresses" for "downstream" devices, but the SNMP AM treats
community strings as passwords which have to be entered each time you
issue a directive. There is no way to put an icon on the map that
represents an entity downstream from the agent, because the SNMP AM
requires each entity instance to have a unique IP address. You really
need the ability to associate the pair {IP address, community name}
with an individual icon.
- Andy
|
| Andy,
The community name string is meant to be used for message
authentication, not as you state, for "subaddresses" for "downstream" devices.
DEChub 90 (and others) have chosen to use it for this purpose because the SNMP
protocol provides no specific mechanism for handling proxy.
I will agree however, that DECmcc (and other generic snmp managers)
dosen't handle proxy agents very well.
Dan
|
| The community name mechanism is actually intended for both
authentication and "subaddressing". The RFC defining SNMP includes an
example that illustrates exactly this. In fact, the specification
allows an even more complex application, namely, the use of community
name to identify portions of the MIB, where these portions are disjoint
subtrees. From RFC 1098, pages 7-9:
.
.
.
A pairing of an SNMP agent with some arbitrary set of SNMP
application entities is called an SNMP community. Each SNMP
community is named by a string of octets, that is called the
community name for said community.
.
.
.
For any network element, a subset of objects in the MIB that pertain
to that element is called a SNMP MIB view. Note that the names of
the object types represented in a SNMP MIB view need not belong to a
single sub-tree of the object type name space.
.
.
.
For every SNMP access policy, if the network element on which the
SNMP agent for the specified SNMP community resides is not that to
which the MIB view for the specified profile pertains, then that
policy is called a SNMP proxy access policy. The SNMP agent
associated with a proxy access policy is called a SNMP proxy agent.
While careless definition of proxy access policies can result in
management loops, prudent definition of proxy policies is useful in
at least two ways:
(1) It permits the monitoring and control of network elements
which are otherwise not addressable using the management
protocol and the transport protocol. That is, a proxy
agent may provide a protocol conversion function allowing
a management station to apply a consistent management
framework to all network elements, including devices such
as modems, multiplexors, and other devices which support
different management frameworks.
(2) It potentially shields network elements from elaborate
access control policies. For example, a proxy agent may
implement sophisticated access control whereby diverse
subsets of variables within the MIB are made accessible
to different management stations without increasing the
complexity of the network element.
By way of example, Figure 1 illustrates the relationship between
management stations, proxy agents, and management agents. In this
example, the proxy agent is envisioned to be a normal Internet
Network Operations Center (INOC) of some administrative domain which
has a standard managerial relationship with a set of management
agents.
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
| slate |
|PCommunity=pub, |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
Domain: the administrative domain of the element
PCommunity: the name of a community utilizing a proxy agent
DCommunity: the name of a direct community
Figure 1
|