The Simple Times (tm) is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents technical articles and featured columns, along with a standards summary and a list of Internet resources. In addition, some issues contain summaries of recent publications and upcoming events.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an "as is" basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available as an online journal in HTML, PDF and PostScript. New issues are announced via an electronic mailing list. For information on subscriptions, see the end of this issue.
Work on SNMPv3 is reaching completion as the specifications are currently progressing through the IESG approval process to become a full Internet Standard. The publication of the SNMPv3 specifications as Internet Standards is expected to happen in 2002 and it might go hand in hand with an action to classify SNMPv1 as Historic. Of course, such an IESG action does not immediately impact all the widely deployed SNMPv1 implementations. SNMPv1 implementations will stay with us for many more years. But still, classifying SNMPv1 Historic sets a clear signal that SNMPv3 has become the stable SNMP version of the future and people are safe in deploying SNMPv3 implementations in large scales.
The IETF standard for extensible agents (RFC 2741, RFC 2742) has been elevated to Draft Standard in December 2001. The AgentX specifications are some of the few documents that manage to progress in the IETF standardization process without any changes to the RFCs. This is even more impressive since the working group collected 13 implementation and interoperability reports.
The MIB module for Differentiated Services, another milestone in the set of IETF MIBs, has been approved for publication as Proposed Standard in November 2001. Work on this MIB involved the cooperation of several subject matter experts since the automated configuration of routers supporting the differentiated services architecture is frequently used to demonstrate policy-based configuration management schemes.
It is good to see that the core SNMP technology has reached stability again after a lengthy period of several competing versions in the 1990s. The SMIv2 data definition language is a full Internet Standard since 1999 and it is expected that the SNMPv3 protocol is published as a full Internet Standard in 2002. This gives the industry a stable technology to create new products and network operators a stable base for their future deployment decisions. On the other hand, every successful living technology also needs a controlled evolutionary path forward to address new requirements and to adapt to changes in the environment. It is thus not surprising that the IETF has started two new working groups:
set state machine and the overhead of lexicographic
sorting are the worst problem areas, usually much more (five to ten
times?) expensive to develop than CLI code. In order for SNMP to
succeed as a configuration management interface, development costs
must be competitive with the CLI, while offering significantly more
value to developers than the CLI. This should be possible, since the
CLI is primarily a human interface and does not provide many important
features of a programmatic interface, such as stability, detailed
command semantics, or compliance and conformance information.
The problem starts with the API definition itself -- the SMIv2 information module. CLI specifications are easier to define than MIBs because there are not nearly as many documentation requirements and modification rules. SMIv2 syntax is not straightforward, widely understood, or easy to learn. Furthermore, SNMP has no real transaction semantics, which means input and output parameters to commands are modelled as data elements (i.e. MIB objects).
So why are SNMP configuration objects so expensive to develop compared to the equivalent CLI configuration commands? Simply put, the CLI accepts input at an appropriate granularity (one command at a time) while SNMP accepts input at an inappropriate granularity (one parameter at a time). This applies to row creation as well as row modification.
SNMP set PDUs may contain an arbitrary number of
(potentially unrelated) arbitrarily partial commands, and the agent is
expected to accept individual parameters, not complete commands. The
partial ``commands-in-progress'' have to be processed ``best-effort'',
as if an entire set of parameters existed, and then saved as MIB
objects, so these parameters can be retrieved by an NMS in subsequent
read operations.
The agent cannot simply store partial commands until they are
complete, because some parameters have ``act now'' semantics and
others have ``act on activation'' semantics
(e.g. bufferControlMaxOctetsRequested from the RMON-MIB
(RFC 2819) is an ``act-now'' parameter while
bufferControlChannelIndex is an ``act-on-activation''
parameter, both defined in the same table).
The requirement to accept partial input is most complicated if some
parameters are inter-related, which is usually the case. The
set PDU logic for such MIB objects can be quite
complicated, as well as the selection of appropriate default values
for missing parameters. For example, if an agent supporting the
DISMAN-PING-MIB (RFC 2925) received a set
PDU containing only one varbind for a
pingCtlTargetAddressType object (syntax
InetAddressType) set to dns(16), then the
agent has to select an arbitrary value for the
pingCtlTargetAddress object, which is supposed to be a
DNS name.
One work-around for this problem is for the MIB designer to place as
many essential parameters as possible in the INDEX
clause. This is problematic from a MIB design perspective, since
OBJECT IDENTIFIERs are limited to 128 sub-identifiers and
the INDEX clause implies uniqueness across all its
parameters. From an agent implementation perspective, this technique
simply trades set PDU complexity for lexicographic
sorting complexity. For an management system developer, editing an
existing row becomes more complex because parameters in the
INDEX clause cannot simply be changed, but rather the
entire row must be deleted and re-created with a new index value. This
can sometimes cause disruptive behavior on the device as well.
The CLI allows only one command at a time to be input, instead of an arbitrary mix of commands. If essential parameters are missing, the entire input is rejected as a syntax error, rather than accepted as partial input. These two simple restrictions make the development and testing of CLI code relatively trivial, compared to SNMP.
CLI does not need the createAndWait state, because it
uses a reliable stream-oriented transport (e.g. TCP) and it has a
``line continuation'' mechanism. Fragments from the same command are
simply cached by the CLI parser until the final fragment is received,
and then the entire command is parsed, as if it was received all at
once. The CLI has the robust createAndGo mechanism that
SNMP needs.
Even if SNMP development costs are lowered, there is an unrelated factor which hinders any potential CLI replacement. Network operators rely on the configuration file as a concise, readable representation of all settings for a device, and therefore consider it to be the ``native language'' representation of the device itself. These files are usually formatted in plain ASCII so they can be examined and edited with even the most basic tools. In some cases, rather complex tools are used to generate and manage device configurations automatically. In many products, the non-volatile (and network) storage of device configuration data is in ``CLI representation'', which implies that only settings which are supported by the CLI interface can be restored after a reboot, or archived to an external storage device.
But the SNMP set can be ``fixed''. If the agent accepted
input in a manner that is consistent with the CLI, then agent
development costs could be dramatically lowered, and much more
instrumentation code could be shared between SNMP and CLI access
mechanisms.
First, MIB designers need to keep writable objects simple and aligned
with CLI access granularity by only defining objects with
``act-on-activation'' instead of ``act-now'' behavior. The practice
of designing SNMP command responders to accept any arbitrarily partial
input must end. It must be acceptable for an agent to reject otherwise
valid SNMP set PDUs because too many different commands
are combined in the same PDU, or not enough parameters for a
particular command are contained in the same PDU. The complex
RowStatus states (i.e. createAndWait and
notInService) need to be deprecated, and no longer used
in new standard MIBs.
Then SNMP can be aligned with the CLI with some relatively minor
enhancements to the SMI and SNMP. New standards under development in
the SMIng and EOS working groups can provide enough new features to
simplify the SNMP set implementation requirements. The
new data definition language from the SMIng WG can provide enough
machine-parseable semantics to convey the expected parameter
granularity for basic functions, such as class creation, modification,
and deletion. The new row-based (should really be class-based)
operations from the EOS WG can potentially provide a mechanism in the
protocol to allow an SNMP engine to reject partial input to the
command responder application in a generic manner. Input could also be
generically presented to the command responder in groups instead of
individual elements. This can simplify the parameter validation logic
and allow for better agent code re-use and more sophisticated
automatic code generation tools.
The complex and nested containment provided by SMIng classes, combined with class-based operations and ``RowStatus Lite'' from EOS, could allow SNMP tool and engine developers to greatly simplify the agent software development environment. Lower development costs will increase the likelihood that new devices will ship with an SNMP interface in addition to the (default) CLI interface.
Many bridge vendors provide VLAN management tools, but these tools
usually only work for their own devices since they make use of vendor
specific MIB modules. In some cases, the bridges do not even fully
implement the IETF BRIDGE-MIB (RFC 1493). In addition,
some vendor supplied tools are end-user applications that are to be
used only by human network administrators. No programming APIs or
information models and class libraries are supplied in these tools for
new application development. Even when APIs are supplied [5], these
APIs tend to be device centric and they are not based on logical
entities such as VLANs or spanning trees. Furthermore, generic
SNMP-based management platforms are not capable of discovering the
relationship between the MIB objects because that would require
customized processing of the MIB variables related to the
BRIDGE-MIB.
The main goal of our spanning tree discovery project is to create a
vendor-neutral tool to discover the bridges and spanning trees using
only SNMP and standard MIB modules, such as RFC1213-MIB
(RFC 1213), BRIDGE-MIB (RFC 1493), and
Q-BRIDGE-MIB (RFC 2674). The scope of our bridge
discovery is limited to bridges that support the
BRIDGE-MIB. As a result, our discovery excludes other
layer two devices such as hubs or bridges that do not support the
BRIDGE-MIB.
Since different vendors have different implementations of MIB modules [2], we have created a vendor-neutral information model for the bridged LAN based on the standard MIB modules, and at the same time, provide a mediation layer framework and tools for mapping between the vendor specific MIB modules and the standard MIB modules. In addition to the discovery of bridges, VLANs and the associated spanning trees (STs), we wanted to build a set of reusable Java class libraries with a well defined information model and interfaces for logical entities that span multiple devices in a bridged LAN. We need a better information model than device centric MIB modules for bridges because relationships between bridges are maintained implicitly through bridge addresses used by the spanning tree protocol (STP). Our discovery tool is the first step in our implementation of Java class libraries that will establish the relationship between bridges and provide navigation capabilities from one node of the spanning tree to another. In the future, we will extend the class libraries with capabilities for adding, changing, or removing station membership.
The key contribution of this article is a description how STP bridge addresses can be associated with IP addresses and an algorithm to build the ST by querying standard MIB modules for bridges. If the standard MIB modules related to bridges are not supported, then we provide a mapping between vendor specific MIB modules and standard MIB modules for the bridges.
A virtual LAN allows a group of stations to communicate as if they were on the same physical LAN segment. The stations could be connected to different ports of the same switch or to ports on different bridges. A VLAN allows a network manager to logically segment a LAN into different broadcast domains (see Figure 1). Since this is a logical segmentation and not a physical one, workstations do not have to be physically located together. Users on different floors of the same building, or even in different buildings can now belong to the same logical LAN. VLANs can be spanning across different physical network environments, such as ATM, Ethernet, Token Ring or FDDI networks.
There are several criteria by which VLAN membership can be defined [2, 4]:
RFC1213-MIB (RFC 1213), the BRIDGE-MIB
(RFC 1493) and the Q-BRIDGE-MIB (RFC 2674). The
discovery method has the following steps:
BRIDGE-MIB and Q-BRIDGE-MIB represent that
recommendation. In reality, many switch vendors support more than one
spanning tree. Our object model for spanning tree information
represents the most general case, one spanning tree per VLAN.
Our discovery method makes certain assumption about the target bridged
LAN and the MIB modules supported in the bridges. We have used the
SNMPv1 protocol to access MIB variables because the bridges in our
test network only support SNMPv1. We have used a single community
string for accessing all the bridges in the target LAN. We have used
the MIB variables from RFC1213-MIB because of our
familiarity with this MIB module. A concise description of mapping
between RFC1213-MIB variables and the SMIv2 counterparts
(RFC 1907, RFC 2011, RFC 2096, RFC 2863) can be found in [13].
ipRouteNextHop variable of the
ipRouteTable. If there is more than one router address,
then we pick the address that is in the same subnet as the given IP
address.
Once we have an IP address of a router, we can find the associated
interface index by examining ipAdEntIfIndex and we obtain
all the subnets associated with the router. For each entry in the
ipRouteTable, we obtain the ipRouteDest and
ipRouteMask objects that match the interface index and
compute the IP subnet address range using the combined value of
ipRouteDest and ipRouteMask. For example,
if the starting IP address is 135.8.29.11 and the next-hop router is
135.8.28.1, we check the ipRouteTable in the next-hop
router. There, we will find an entry with ipRouteDest =
135.8.12.0 and a corresponding ipRouteMask =
255.255.252.0 and the IP address range will be
135.8.12.1-135.8.16.255. Thus, the span of our bridge discovery is the
union of all the subnet ranges computed for the interface index
associated with router's IP address.
sysDescr object to determine if the device on an IP
address is running an SNMP agent. Second, we query the
dot1dBridgeAddress object to see if the device is a
bridge. The detailed operations are described as below:
get message to retrieve the sysDescr
variable for each IP address in the address range. A timeout or an
error response indicates that the IP address is either not reachable
or that SNMP access is not enabled.
get message to retrieve the scalar
dot1dBaseBridgeAddress. If the SNMP agent supports the
BRIDGE-MIB, then the returned value is the address of the
bridge. A noSuchName error or noSuchObject
exception indicates that this device is not a bridge.
BRIDGE-MIB on the specified IP range, we run
the above two steps for every IP address on the computed IP address
ranges and then compile a mapping between the bridge IP addresses and
corresponding bridge MAC addresses.
dot1dStpPortTable table of the
BRIDGE-MIB as shown below. For constructing the spanning
tree, we are only interested in a subset of the MIB variables of the
dot1dStpPortTable (marked below).
dot1dStpPortEntry OBJECT-TYPE
SYNTAX Dot1dStpPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of information maintained by every
port about the Spanning Tree Protocol
state for that port."
INDEX { dot1dStpPort }
::= { dot1dStpPortTable 1 }
Dot1dStpPortEntry ::= SEQUENCE {
dot1dStpPort INTEGER, --
dot1dStpPortPriority INTEGER,
dot1dStpPortState INTEGER, --
dot1dStpPortEnable INTEGER,
dot1dStpPortPathCost INTEGER,
dot1dStpPortDesignatedRoot BridgeId, --
dot1dStpPortDesignatedCost INTEGER,
dot1dStpPortDesignatedBridge BridgeId, --
dot1dStpPortDesignatedPort OCTET STRING, --
dot1dStpPortForwardTransitions Counter
}
For each discovered bridge, we send one SNMP getnext
message for each row of the dot1dStpPortTable to get the
values of the marked variables. As we walk through the table row by
row, we check the dot1dStpPortState variable of each row
and discard entries whose port state is broken. We
also extract the VLANs associated with the selected ports by
retrieving dot1qPvid from the associated entry of the
dot1qPortVlanTable of the
Q-BRIDGE-MIB. Given all this information, we create one
row of our internal table for each combination of VLAN identifier and
port identifier. The columns of the internal table are shown in Table
3. The knowledge of the bridge address, the port identifier, the VLAN
identifier, the designated root, the designated bridge, and the
designated port are necessary and sufficient for constructing the
per-VLAN spanning tree.
get messages can be combined into a single
message which reduces the number of required SNMP packets to n.
In the STP information collection phase, we assume that there are at
most l entries in the dot1dStpPortTable for each bridge,
and there are at most p entries in the
dot1qPortVlanTable. Since we need to collect only 5
columns of the dot1dStpPortTable, we can send one SNMP
message for each port to get the values of the variables. We have to
get only one variable from the dot1qPortVlanTable. Thus,
we have to send out at most (l + p) SNMP packets in order to collect
spanning tree information from each bridge.
Putting things together, the VLAN and spanning tree discovery process
needs to send out 2n+m(l+p) SNMP packets to the network or n+m(l+p) if
the first two messages are combined into a single message. During
these initial steps, the local processing cost of storing the data
into the table is trivial compared to the sending and receiving SNMP
messages. For example, in our test environment the values of n, m, l
and p are as follows: n=512, m=11, l=48, p=7. Thus, we have to send
about 1629 SNMP messages or 1117 messages if the first two messages
are combined. The above analysis is based on SNMPv1. If we use SNMPv2c
or SNMPv3, which support getbulk operations, we may be
able to retrieve the tables with fewer messages by packing more than
one row in SNMP responses.
As to the complexity of constructing the spanning tree, our method is
actually a scan of the table for each VLAN identifier and then it
builds the tree from bottom up, i.e., from leaf to the root. This
algorithm can be finished in linear time.
Avaya's Cajun bridges store the STP related information in their
proprietary MIB, called PROMINET-MIB. The Cajun switches
maintain one spanning tree for each VLAN. The
PROMINET-MIB is an extension of the
BRIDGE-MIB for representing MIB objects for multiple
VLANs. The PROMINET-MIB stores spanning tree information
in its promBridgePortTable. This table has all the
objects defined in dot1dStpPortTable of the
BRDIGE-MIB. The PROMINET-MIB maintains one
spanning tree for each VLAN. The promBridgePortTable is
indexed by a combination of the VLAN identifier and the port
identifier. In the BRIDGE-MIB only the port identifiers
are used to maintain the spanning tree information.
| BRIDGE-MIB/Q-BRIDGE-MIB | PROMINET-MIB |
|---|---|
| dot1dStpPort | promBridgePortIndex |
| dot1qPvid | promBridgePortIndex, promVlanID |
| dot1dStpPortState | promBridgePortState |
| dot1dStpPortDesignatedRoot | promBridgePortDesignatedRoot |
| dot1dStpPortDesignatedBridge | promBridgePortDesignatedBridge |
| dot1dStpPortDesignatedPort | promBridgePortDesignatedPort |
Table 1 describes the mapping of the variables of
promBridgePortTable to the standard
BRIDGE-MIB. The VLAN identifier of a port is extracted
based on the VLAN index encoded in the
promBridgePortIndex. The port identifier and the VLAN
identifier are combined to form the
promBridgePortIndex. The VLAN identifier is deduced in
the following way:
promBridgePortIndex. The
first half of this object is the VLAN bridge index, the second half of
this object is the bridge port identifier. We extract the first half
of promBridgePortIndex to get the VLAN bridge index
(promVlanBridgeIndex).
promVlanId
and the promVlanBridgeIndex from the
vlanTable in the PROMINET-MIB and use this
information to map the VLAN bridge index obtained in the first step to
the VLAN identifier (promVlanID) for the corresponding
bridge port.
BridgePing that,
given an IP subnet, automatically discovers all the bridges in the
target address range. Running the BridgePing program on
all IP subnets computes the mapping shown in Table 2 between IP
addresses and MAC layer addresses of the discovered bridges.
vlanTable
of the PROMINET-MIB in order to create a mapping between
VLAN identifiers and Cajun switch specific VLAN indexes for the bridge;
promBridgePortTable. All the variables of a specific row
of the table are retrieved in one message. The VLAN index is computed
from the promBridgePortIndex and mapped to the VLAN
identifier using the information collected in the first step. The port
identifier is also computed from promBridgePortIndex.
When all the entries from the promBridgePortTable have
been collected, we filter out those entries whose state is
broken or invalid and then build the
internal table (as shown in Table 3). The bridge address in the table
is obtained by mapping the IP addresses to corresponding bridge
MAC addresses (using the information in Table 2).
| IP Address | Bridge Address |
|---|---|
| 135.8.12.1 | 00306d3b8800 |
| 135.8.15.245 | 00306d67dc00 |
| 135.8.15.246 | 02e03b0529b3 |
| 135.8.15.247 | 00306d62c000 |
| 135.8.15.248 | 02e03b005e33 |
| 135.8.15.249 | 02e03bfa7800 |
| 135.8.15.250 | 00306d633800 |
| 135.8.15.251 | 02e03bdbf800 |
| 135.8.15.252 | 02e03bfa8000 |
| 135.8.15.253 | 00306d838400 |
| 135.8.15.254 | 00306d63b400 |
| Bridge Address | Vlan | Port | Port State | Designated Root | Designated Bridge | Designated Port |
| 00306d62c000 | 10 | 25 | forwarding | 00306d3b8800 | 02e03bdbf800 | 25 |
| 00306d62c000 | 12 | 25 | forwarding | 00306d3b8800 | 02e03bdbf800 | 25 |
| 00306d62c000 | 16 | 25 | forwarding | 00306d3b8800 | 02e03bdbf800 | 25 |
| 02e03b005e33 | 10 | 49 | forwarding | 00306d3b8800 | 00306d838400 | 49 |
| 02e03bfa7800 | 12 | 25 | forwarding | 00306d3b8800 | 00306d3b8800 | 217 |
| 00306d633800 | 2 | 25 | forwarding | 00306d3b8800 | 02e03bfa7800 | 49 |
| 02e03b0529b3 | 12 | 25 | forwarding | 00306d3b8800 | 00306d3b8800 | 73 |
| 00306d67dc00 | 12 | 25 | forwarding | 00306d3b8800 | 00306d838400 | 79 |
| 02e03b005e33 | 12 | 49 | forwarding | 00306d3b8800 | 00306d838400 | 49 |
| 00306d838400 | 12 | 49 | forwarding | 00306d3b8800 | 00306d3b8800 | 121 |
| 00306d633800 | 12 | 25 | forwarding | 00306d3b8800 | 02e03bfa7800 | 49 |
| 02e03bdbf800 | 12 | 49 | forwarding | 00306d3b8800 | 00306d3b8800 | 169 |
| 02e03bfa8000 | 12 | 49 | forwarding | 00306d3b8800 | 00306d63b400 | 49 |
| 00306d63b400 | 12 | 25 | forwarding | 00306d3b8800 | 00306d3b8800 | 145 |
| ... | ... | ... | ... | ... | ... | ... |
Figure 2 shows the result of a spanning tree that is constructed based on the information in Table 3 for the VLAN with identifier 12. The numbers below each bridge node are ingress port identifiers and the numbers above each bridge are egress port identifiers.
The main advantages of our approach are:
This was taken as somewhat of a challenge, and so began the SNMP stack in Java described in this article. At the same time, West were offered a chance to present at one of Sun's promotional JavaDays so the first version of the stack was used as a demo at that event. It used almost all the Java features available at the time.
The first version ran on a 16Mb 40Mhz 486 in Netscape's JVM so it needed to be lightweight and simple. West were kind enough to make the stack freeware and it was released in 1996.
The authors later moved to Westhawk Ltd in the UK. Since that time, the SNMP stack has been extended to encompass JavaBeans, SNMPv2c and SNMPv3, and the performance has been improved quite a bit.
sysUpTime. The applet environment was
too restricted for that to work.
java.util package.
The overall architecture is shown in Figure 1.
select() statement which monitored all the datagrams and
allowed a single timeout. Much of the complexity of the stack involved
trying to keep state across invocations of select() and
in trying to workout which PDU would need to retry next, meaning that
different requests needed to cooperate.
Java's multi-threading allow the handling of PDUs (requests) to be isolated from each other. A thread is allocated to each (outgoing) request. This thread is responsible for the timeouts/retries on that PDU and no other. There is also a thread that listens for incoming packets (replies) and hands them out. This results in a loop running in each PDU thread that looks like this:
answered = false;
for (int n = 0; n < retryIntervals.length; n++) {
if (! answered){
sendme(community);
}
try{
sleep(retryIntervals[n]);
} catch (java.lang.InterruptedException e) {}
}
The answered flag is set once a matching reply PDU is
received by the listening thread. Whilst this is simple and clear, it
is inefficient and caused problems on Windows. In particular, it
creates a new thread for every request and holds onto it longer than
is needed - until the sum of all the retry times has elapsed. This was
changed to use a thread pool, where threads are reused once idle. Also
a get-out clause was added, allowing the loop to finish early once a
reply arrived.
The performance of the stack has never been a problem. It can saturate an Ethernet on a 600Mhz Pentium system and there are users who poll hundreds of hosts. In fact, the only complaint in that area was about a beta version, which due to a typo, dropped exactly half the packets it received. It is a tribute to the design of SNMP that this showed up as a performance problem, not as a total failure.
As it turned out, it was not quite as simple as was hoped. First a suitable open source set of lightweight classes had to be found that implement the cryptographic algorithms used by SNMPv3 for privacy and authentication (DES, MD5 and SHA1). A couple of sources were evaluated, and the code from BouncyCastle was selected in the end.
The authors of the SNMPv3 RFCs had assumed a certain style of ASN.1 encoder and decoder, which worked in such a way as to make it possible to replace byte ranges in the message. As mentioned above, this SNMP stack represents the PDU as a tree, and not as a linear array of bytes. An attempt was made to implement SNMPv3 in that style, by replacing parts of the tree, and then encoding it. However, this caused other problems since the RFC requires the replacement of the contents of an ASNSequence, not the sequence itself. The ASN object classes had to be extended, so that they take note of their byte offsets when encoding and decoding themselves. These offsets are then used as markers in the (say) outgoing byte array, and it is rewritten just before it is sent. This goes to show that no matter how hard you try to be independent of implementation details when you write a specification, you still run the risk of favoring a specific style by assuming how things will be done.
At the same time as implementing SNMPv3, support for receiving and sending traps was also added. Both of these required quite careful thought as to how to create a tidy API. In both cases, the problem boiled down to the fact that the stack is middle-ware, not a finished product.
In the case of receiving traps, the issue is that the manager program
may not have created a context to receive the trap. If there is a
context for the trap source, a user interface can simply add a trap
listener to the existing context. An interactive management station
might only create contexts for the devices that were currently on the
screen, while wanting to accept traps from all the devices it can
monitor. This presents a specific problem for SNMPv3 with privacy,
since the context is used to store the authentication and privacy
keys, as well as the time-line info (of which more later...). It was
decided to create a DefaultTrapListener, as a last
resort. Applications can ask to be notified when an 'unclaimed' trap
message arrives. The application then has to create a suitable
context, which can be used to decode the trap.
Sending a trap represents a different problem. It is the only element of agent functionality supported so far. SNMPv3 places additional requirements on agents in terms of keeping three bits of data:
snmpEngineId - a unique identification for the agent
snmpEngineBoots - the total number of reboots of the agent
snmpEngineTime - how long the agent has been running
since the last reboot
SNMPv3 uses these to protect itself against replay attacks. An initial implementation provided reasonable values for these variables. However this code makes assumptions about the environment in which it runs. So a mechanism was added which allows programmers to supply their own class to provide these values and which can ensure the values are appropriate to the device.
Others have used the stack to provide a gateway to CORBA, to scan the Internet facing mis-configured devices as part of a routing protocol testbench, as well as the bread and butter tasks of monitoring the status of routers and connections. Sadly, at least to the author's knowledge, no-one uses it to control a UPS!
Where possible the user base is encouraged to write Java beans to
encapsulate the key aspects of the devices to be monitored. In the IVR
example above, a DialogicChannelStatusBean was
created. This provides a programmer with access to the data she needs
to provide a visual representation of the state of the device with the
minimum of exposure to SNMP. In fact the only things she needs to know
is the IP address, the port number and the community name of the
target SNMP agent. All of the MIB specific details, OIDs, tables,
etc. are managed by the bean and not exposed to the user interface
programmer.
In order to permit the user interface programmer to use multiple beans in her program, common resources need to be shared. A context pool was created, so that two beans that are talking to the same agent with the same community name will share the socket and communications threads. Java's interface mechanism was used to make the change invisible to most of the pre-existing user base.
The downside of this method is that the person who writes the beans has to understand the MIB, with little or no assistance from us. Personally I tend to use an interactive, MIB-aware, tool like Scotty to browse a new MIB, get some sample values from a real device and then capture the OIDs. Only then I start to code up a new bean. This has proved hard for some beginners, since there is quite a lot to learn all at once. Indeed, one group uses the stack as the basis of a course in SNMP, perhaps exactly because, at this level, it does not hide the detail of SNMP.
On the other hand, the team gets quite a few emails from people with thanks and bug reports -- both of which are equally welcome, if the bug report comes with a fix! It is always interesting to hear how people are using the stack since this info can be used to tune new versions. Some of the uses are unexpected and as such could be better supported if small changes were made in the stack. For example, there are users who poll hundreds of agents per minute and the stack creates and destroys many threads as a result. New I/O features in Java 1.4 may be able to reduce this churn and hence boost performance, but if the team aren't told, we can't address it.
In common with most projects of this (smallish) size, most of the code has been written by two people with many smaller contributions from others. In the 3 months since 6th of September 2001, the stack has been downloaded some 1190 times, and there are some 93 email addresses on the list of individuals who are notified whenever a new version comes out.
With its features, Java has proved an excellent language for the stack. With its current development, Java holds lots in store for the future of the stack.
In May 2001, a meeting was held in conjunction with NANOG, the North American Network Operators Group, in Scottsdale, Arizona. Similar meetings were held in October, at the RIPE/NCC meeting in Prague, and in November at the USENIX LISA conference in San Diego.
It quickly became clear that although SNMP is popular for monitoring, most network operators are not using it for device configuration. Reasons for this include lack of vendor support, difficulty in scripting and debugging, and the desire to use a common configuration method regardless of the communication mechanism (e.g. console port or network access.)
During the meeting with NANOG, some network operators volunteered to write a document describing their requirements for methods to configure devices in service provider networks. This document has been posted as an internet-draft[1], with the intention to make it an informational RFC once it is complete and consensus has been reached on the contents in the traditional IETF style. The goal is to have this done before for the next IETF meeting, in March 2002.
Some of the requirements proposed for inclusion in the document include:
comp.protocols.snmp Usenet news group
asked about the availability of software to convert ``CMIP GDMO to SNMP
ASN.1.'' Esteemed SNMP author Dave Perkins replied that, were such a task
possible, it would require a team of ``4 engineers and a trouble
maker.'' He then went one to list the roles in his proposed team.
So, by special permission of the parties involved, I am providing a transcript of the first meeting of the above team with their venture capital provider, Mr. Muncie (``Mun'') E. Baggs. You can decide for yourself who the trouble maker is.
NET-SNMP
sourceforge project started from the UCD-SNMP
sources. The latest release of NET-SNMP, version 4.2.3,
appeared at the end of November 2001. This version removes a large
number of minor errors, and improves support for the MIB-II and the
host resources MIB. Recently, work on the upcoming release 5.0 has
started.
scli) is a new open
source package which provides a command line interface to display,
modify and monitor data retrieved from SNMP agents. The scli provides
command line editing, completion and history capabilities. The
scli commands are MIB aware and organized in a logical
command tree and hide the details of the SNMP interactions and the
underlying MIB data structures.
libsmi appeared. The
libsmi is a C library that allows applications to access
SMI MIB module information through a well defined API. The
distribution contains the smilint and
smidump tools for MIB module validation and
conversion. The most significant change since the previous 0.2.x
releases is the addition of the smidiff tool which can be
used to compare two revisions of the same MIB module.
The text is very specific to Aprisma's Spectrum management system and sometimes has a touch of a marketing document. This style comes as no surprise once you realize that the author has been heavily involved in the development of Spectrum and owns several patents in this area.
The book provides useful information for readers who want to better understand the overall picture of managing networks and who like to learn how management systems can be integrated and applied in real-world networks. The third part also contains an interesting description of the gap between real-world network operations and network management research and why research results are only very slowly adopted by the industry.
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via electronic mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.