The Simple Times


The Quarterly Newsletter of SNMP Technology, Comment, and Events
Volume 9, Number 1
December, 2001

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.


In This Issue:

Applications, Tools, and Operations

Featured Columns

Miscellany


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.


Editorial
Aiko Pras, University of Twente
Jürgen Schönwälder, University of Osnabrück

The year 2001 has been one of the more silent years in the SNMP history. But sometimes silence is a good thing, especially if it is not caused by a lack of activity. Quite some work has been done in 2001 to progress core technology documents and to complete or revise several MIB modules.

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:

The SMIng working group has produced a document which discusses the objectives of the SMIng work. This document was published as RFC 3216 in December.


SNMP Set: Can it be saved?
Andy Bierman, Cisco Systems

There are many factors preventing the SNMP command responder application interface from displacing the command line interface (CLI) as the primary configuration mechanism for network devices. Some of the issues have been raised on the SNMP WG mailing list in the past, but were largely ignored at the time. Not all of the issues are directly related to SNMP or the SMI, and not surprisingly, the most important factor is money. SNMP agent code costs too much to develop, test, and maintain, compared to the equivalent CLI code. The complex SNMP 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.


Discovery of Spanning Trees in Virtual Bridged LANs
Meng Guo, Georgia Institute of Technology
Subrata Mazumdar, Avaya Labs

Virtual Local Area Network (VLAN) capabilities are nowadays an integral feature of switched LAN solutions provided by LAN equipment vendors [1, 2]. VLANs facilitate easy administration of logical groups of stations on different LAN segments as if they were on the same LAN segment. A virtual bridged LAN [3, 4] consists of one or more VLAN-aware bridges and allows the definition, creation and maintenance of the VLANs. All the bridges within a bridged LAN environment participate in a spanning tree over which multiple VLANs can coexist. One of the challenges of VLAN deployment is the degree to which VLAN configuration is automated. The first step towards automatic VLAN configuration is the discovery of the initial configuration of the bridges, the spanning tree operated over the bridges and the mapping from the spanning tree to the VLAN topology. There can be multiple instances of spanning trees over a set of bridges. The operation of the spanning tree is transparent to bridges as well as external management applications, and the spanning tree information is distributed over all the bridges in the bridged LAN. Reconstruction of the spanning tree and discovery of the mapping between the spanning tree and the VLAN is central to the management of bridged LANs.

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.

Virtual Bridged LANs: Concepts and Definition

A virtual bridged LAN [3, 4, 6, 7] consists of one or more VLAN-aware bridges and allows the definition, creation and maintenance of Virtual Local Area Networks (VLANs). A VLAN is a proper subset of the active topology of a bridged local area network. Each VLAN is associated with a VLAN identifier (VID). When packets from two different VLANs transit a common link, a tag is prepended to the frame that contains the VID and the priority (tagged frames). On links that have only one VLAN, tagging is optional. VLAN-aware bridges or end stations recognize and support VLAN-tagged frames. A VLAN can be implemented in any bridged LAN environment that supports IEEE 802 LAN MAC protocols [3] and over shared media LANs as well as point-to-point LANs. The bridges forward unicast, multicast, and broadcast traffic only on LAN segments that serve the VLAN to which the traffic belongs. Typically, a router is used to move traffic from one VLAN to another. All bridges within a bridged LAN environment participate in a spanning tree over which multiple VLANs can coexist [3, 4, 8]. The primary reason for running a spanning tree is to eliminate loops in a bridged infrastructure and to provide redundant paths, which can be unblocked upon failure. Although the VLAN standard [4] specifies a single spanning tree for all VLANs, there is a choice to be made as to how many spanning trees operate in a VLAN environment and how the VLANs in that environment map to those spanning trees. Vendor dependent implementations vary in whether there is one spanning tree for each VLAN or whether multiple VLANs map to a spanning tree.

Figure 1: Typical VLAN configuration.

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]:

In addition to the above criteria, VLANs may be extended beyond a single bridge through the use of trunking between bridges. A trunk is a point-to-point link carrying the traffic of several VLANs. To preserve VLAN information across the trunk, the Ethernet frames are prepended with 802.1Q tags.

Related Work

There has been extensive work done on the discovery of VLAN configuration. Most bridge vendors provide their own tools for VLAN configuration and path discovery between end points. These tools primarily depend on proprietary discovery mechanisms for bridges.

Our work is closely aligned with Aprisma's SPECTRUM VLAN Manager and the Granite API, which are based on IETF standard MIB modules for bridges. In addition, we provide a vendor neutral model based on standard MIB modules. We also provide a framework for mediating vendor specific MIB modules to standard MIB modules for bridges.

Discovery of Spanning Trees and VLANs

In this section, we propose our method of spanning tree and VLAN discovery in the virtual bridged LAN based on the IETF standard MIB modules for bridges. MIB modules that are used in this article are the RFC1213-MIB (RFC 1213), the BRIDGE-MIB (RFC 1493) and the Q-BRIDGE-MIB (RFC 2674). The discovery method has the following steps:

According to the specification of Virtual Bridged LANs [4], there is only one spanning tree for all the VLANs and the object models for the 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].

Deduction of Target Virtual Bridged LAN

In order to constrain the domain of the bridges in a LAN environment, we select a bridged LAN that is bordered by routers as the target bridged LAN. The starting point of the whole VLAN discovery process is an IP address of one of the hosts, routers or switches of the target bridged LAN. We need to determine the IP address ranges (possibly a collection of subnets) of the target bridged LANs before the bridge discovery step. If the initial IP address does not represent a router, we first need to obtain the next-hop router of the given IP address by retrieving the 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.

Auto Discovery of Bridges

The aim of automatic discovery of all the bridges is to create a one-to-one mapping between the IP address and MAC layer bridge address of a bridge in the target LAN environment. The bridge address is the lowest MAC address of the bridge used by the bridge for running the spanning tree protocol. The IP address of the bridge is needed because SNMP messages are sent to the IP address of the bridge in order to get MIB information from the bridge. On the other hand, the spanning tree protocol is a MAC layer protocol and the information about the parent nodes of the spanning tree is kept in the form of bridge addresses. The only way the information in a specific bridge can be correlated with the information in its parent bridge (in the spanning tree) is by mapping the bridge MAC address to an IP address. The discovery of the bridges is accomplished in two steps. First, we query the 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:

  1. Given the computed IP address range from the seed IP address, we send an SNMP 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.
  2. If the device on an IP address is running an SNMP agent, then we send a second SNMP 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.
If the above two steps are successful, we conclude that the device with this IP address is a bridge. To discover all the bridges which support the 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.

Collection of Spanning Tree Information

Automatic discovery of bridges generates a list of bridges that support the STP. The STP is a distributed protocol and each switch only maintains local STP information. The STP related information is stored in the 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.

Per-VLAN Spanning Tree Construction

Once the internal spanning tree information table is built, we sort it by the VLAN identifier and the bridge address columns so that spanning tree information for each VLAN is in contiguous rows and ordered by the bridge address. Then for each group of entries for each VLAN identifier, we perform the following steps to construct the per-VLAN spanning tree: Given a VLAN identifier, if the VLAN identifier of an entry in the table equals to the given value, compare the bridge address and designated bridge. If both the bridges addresses are the same, then skip this entry; if they are different, perform the following operations:

  1. Select the first entry from this VLAN’s group of entries as the current entry.
  2. If the bridge address and the designated bridge address of the current entry are the same, then go to step 3; otherwise perform the following steps:
  3. Select the next unvisited entry as the current entry and go to step 2; The spanning tree is constructed when all the entries of this VLAN identifier have been visited.

Complexity Analysis

The analysis of the complexity of our solution is composed of two aspects: traffic load and spanning tree computation. In our four-phase solution, the first three phases send SNMP packets to collect necessary information. The fourth phase is a pure local processing step which injects no traffic in the network. In the automatic bridge discovery phase, assume there are n IP addresses, and there are m bridges that support per-VLAN spanning tree in the target LAN environment. We send at most (2n) SNMP packets to the network in order to find m bridges among n IP addresses. Note that the two 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.

Experimentation and Analysis of Results

In order to test our spanning tree discovery method, we ran a set of tests in our internal corporate network. Our corporate network consists of a large number of Avaya P580 Cajun bridges [14] and routers. We have restricted the tests to a small subnet of the corporate network.

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.

Table 1. Mapping between proprietary and standard MIB variables.
BRIDGE-MIB/Q-BRIDGE-MIBPROMINET-MIB
dot1dStpPortpromBridgePortIndex
dot1qPvidpromBridgePortIndex, promVlanID
dot1dStpPortStatepromBridgePortState
dot1dStpPortDesignatedRootpromBridgePortDesignatedRoot
dot1dStpPortDesignatedBridgepromBridgePortDesignatedBridge
dot1dStpPortDesignatedPortpromBridgePortDesignatedPort

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:

We have implemented our algorithms using a set of Java based applications. The initial seed IP address we selected was 135.8.12.1 and the IP address is configured on a router. The IP address range of the selected subnet is 135.8.12.0-135.8.15.255.

Bridge Discovery

We have written an application called 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.

Collecting Spanning Tree Related Information

Once we have identified the bridges, we send SNMPv1 message to the bridges to build our internal table (as shown in Table 3) in our Java application for computing the spanning tree:

Table 2. Mapping IP Addresses to Bridge Addresses.
IP AddressBridge Address
135.8.12.100306d3b8800
135.8.15.24500306d67dc00
135.8.15.24602e03b0529b3
135.8.15.24700306d62c000
135.8.15.24802e03b005e33
135.8.15.24902e03bfa7800
135.8.15.25000306d633800
135.8.15.25102e03bdbf800
135.8.15.25202e03bfa8000
135.8.15.25300306d838400
135.8.15.25400306d63b400

Construction of Per-VLAN Spanning Tree

In Table 3, each row describes a node of the spanning tree for a specific VLAN. The root of the spanning tree for a VLAN is easily deduced from the Designated Root column. The Designated Root is the same for all nodes of a spanning tree. For a given node (bridge), the parent of the node is obtained from the Designated Bride column. The port identifier of this bridge is marked as egress port and the port identifier of the parent (Designated Bridge Port) is marked as ingress port for the parent node.

Table 3. Internal Table for VLANs and Spanning Trees.
Bridge AddressVlanPortPort StateDesignated RootDesignated BridgeDesignated Port
00306d62c0001025forwarding00306d3b880002e03bdbf80025
00306d62c0001225forwarding00306d3b880002e03bdbf80025
00306d62c0001625forwarding00306d3b880002e03bdbf80025
02e03b005e331049forwarding00306d3b880000306d83840049
02e03bfa78001225forwarding00306d3b880000306d3b8800217
00306d6338002 25forwarding00306d3b880002e03bfa780049
02e03b0529b31225forwarding00306d3b880000306d3b880073
00306d67dc001225forwarding00306d3b880000306d83840079
02e03b005e331249forwarding00306d3b880000306d83840049
00306d8384001249forwarding00306d3b880000306d3b8800121
00306d6338001225forwarding00306d3b880002e03bfa780049
02e03bdbf8001249forwarding00306d3b880000306d3b8800169
02e03bfa80001249forwarding00306d3b880000306d63b40049
00306d63b4001225forwarding00306d3b880000306d3b8800145
.....................

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.

Figure 2: Spanning Tree for VLAN 12 based on Table 3.

Conclusion

In this article, we propose an approach to discover spanning trees in Virtual Bridged LANs using SNMP MIB modules. Our work is composed of three phases. In the first phase, we discover the bridges within a target range of IP addresses and create a one to one mapping between IP and bridge MAC addresses. In the second phase, we collect the STP information from the discovered bridges using SNMP. In the third phase, we compute the spanning tree for each VLAN in a bottom-up manner. We have tested our approach in our internal networks and we verified the result.

The main advantages of our approach are:

We have completed the first step of building a vendor neutral tool for VLAN configuration. Our next step is to extend the discovery tool to implement add/change/remove capabilities for VLAN membership and the configuration of VLANs.

Acknowledgement

We would like to thank Mike MacFaden of Riverstone Networks for his comments that helped us to improve the article significantly.

References

[1] Buerger, D.J., Virtual LAN cost savings will stay virtual until networking's next era, Network World, March 1995.
[2] Passmore, D., Freeman, J., The Virtual LAN Technology Report, March, 1997.
[3] IEEE 802.1D, IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Common Specifications--Media access control (MAC) bridges, 1998.
[4] IEEE 802.1Q, IEEE Standard for Local and Metropolitan Area Networks: Virtual Bridge Local Area Networks, 1998.
[5] NMOPS, Granite: A C API/SDK to provision L2 Filter and L3 ACLs and VLANs on Riverstone Routers
[6] Hein, M., Griffiths, D., Berry, O., Switching Technology in the Local Network: From LAN to Switched LAN to Virtual LAN, Thompson Computer Press, February 1997.
[7] Subramanian, M., Network Management, Principles and Practice, Addison-Wesley, 1995.
[8] Cisco Documentation, Understanding Spanning Tree Protocol
[9] Avaya, Avaya CajunView Enterprise Network Management Systems
[10] Aprisma, SPECTRUM VLAN Manager
[11] Cisco Documentation, VlanDirector - Getting Started Guide
[12] 3COM Documentation, Transcend Management Software Enterprise VLAN Manager User Guide
[13] Riverstone, RS Platform SNMP Management
[14] Avaya, P580 MultiService Switch


Westhawk's SNMP Stack in Java
Tim Panton, Westhawk
Birgit Arkesteijn, Westhawk

In 1995, the authors were working for West Consulting BV on a SNMP agent and manager for a UPS (Uninterruptable Power Supply) maker (Victron, now part of GE Industrial Systems). It was written in 'C' and was ported to 13 different UNIX platforms. In a discussion with the customer it was mentioned that the new Java platform might make the porting/installing of the manager code simpler in the future. The customer remarked that he doubted that Java would be able to do the low level UDP networking or the detailed graphics that were needed.

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.

Design Decisions

The fundamental design goal was that it should be possible to use the stack in an applet and, other things being equal, leave it running all day. Taking that basic goal a step or two further led to the following core design decisions:

The overall architecture is shown in Figure 1.

Figure 1: Westhawk's SNMP Architecture.

Threading

To implement a SNMP manager, a timeout/retry mechanism to re-send packets is required. In the UNIX/C version, this was quite untidy, since basically all the code funneled down to a single 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.

SNMPv3 Support

In 2000, Westhawk was commissioned to extend the stack to support SNMPv3. As the authors had worked on a proof of principle implementation of SNMPv2usec in 1996, as an extension of the 'C' stack, we were delighted to accept. SNMPv3 implements many of the same mechanisms as were in the USEC draft.

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:

  1. snmpEngineId - a unique identification for the agent
  2. snmpEngineBoots - the total number of reboots of the agent
  3. 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.

MIBs and Beans

Over the years the user base has used the stack to talk to a wide variety of devices and their corresponding MIBs. Probably the most fun (and useful) was a manager application which monitored the state of an ISDN card (from Dialogic) which was running a telephone IVR (Interactive Voice Response) system. The level of detail in the Dialogic MIB was such that it could actually give a sense of what was happening on each call. It tracks the state of the DSP hardware - listening for DTMF tones, playing a recorded message, idle etc. Icons for each of these states were created and a simple dedicated manager application was produced for the operations staff to use so they could keep an eye on the system.

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.

Open source

From the outset the stack has been a collaborative project, indeed the first code came from Jordan Hargrave, not from the authors. It has been interesting to lead such a project, but somewhat disheartening at times. Since the stack is middleware, the view was taken that neither the Gnu Public License, nor the Lesser Gnu Public License were appropriate for code which might be embedded in devices, or put on web servers in the form of applets. Instead a 'BSD' style license with very few conditions is used. In retrospect it should have required that users notify the authors of their use of the stack. As it is, the stack is found in various places (not always acknowledged) and the project gets no feedback from those users about how it could be improved.

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.

Future

As mentioned above we expect to use Java 1.4 features to improve support polling of large numbers of agents. Requests have been made to add support for agent functionality. This has been investigated, but is unlikely to happen unless someone provides some encouragement, either in the form of code or money!

Summary

What started as a proof of concept not only proved its point, but has turned into more than we expected! The fact that it is lightweight, freeware and open source means that it can be used by everyone for every purpose. The way the stack is designed makes it straightforward to experiment with different protocols or to extend it in any other ways to suit your needs.

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.


Reality Check: IETF meets Network Operators
Steve Feldman, Vivace Networks

Earlier this year, the Operations and Management area directors in the IETF started a dialog between network management protocol designers and network operators to help in determining future directions for work in the IETF. As part of that effort the IETF held several interim meetings in conjunction with meetings of various network operator groups.

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:

There are quite a few more potential requirements under active discussion. Network operators are encouraged to read the draft document and join in the mailing list discussion at ops-nm@ietf.org. (Send subscription requests to ops-nm-request@ops.ietf.org.)

References

[1] Woolf S., Woodcock, B., Operator Requirements of Infrastructure Management Methods, work in progress, 2001.


Four Engineers and a Troublemaker
Tom Cikoski

A recent poster on the 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.

  1. SNMP MIB Expert (SNMP)
  2. CMIP MIB Expert (CMIP)
  3. Subject Matter Expert (Subj)
  4. Application Developer (Devel)
  5. Network Operator (User)
Since Dave did not explicitly identify the ``troublemaker'' on the team, speculation ran rife, and several news group regulars wrote me, identifying the ``obvious choice.'' The answers all differed.

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.


Standards Summary

Please consult the latest version of Internet Official Protocol Standards. As of this writing, the latest version is RFC 3000.

SMIv1 Data Definition Language

Full Standards: Informational:

SMIv2 Data Definition Language

Full Standards:

SNMPv1 Protocol

Full Standards: Proposed Standards:

SNMPv2 Protocol

Draft Standards: Experimental:

SNMPv3 Protocol

Draft Standards: Proposed Standards: Informational: Experimental:

SNMP Agent Extensibility

Draft Standards:

SMIv1 MIB Modules

Full Standards: Draft Standards: Proposed Standards:

SMIv2 MIB Modules

Full Standards: Draft Standards: Proposed Standards: Informational: Experimental:

IANA Maintained MIB Modules

The Internet Assigned Numbers Authority (IANA) maintains several MIB modules. The IANA MIB repository is located at ftp://ftp.iana.org/mib/iana.mib/.

Related Documents

Informational: Experimental:


Open Source News

NET-SNMP 4.2.3

It is now more than one year back that the 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 0.2.6

The SNMP command line interface (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 0.3.0

In November 2001, version 0.3.0 of 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.

ntop 2.0

Ntop version 2.0 was released in December 2001. It provides improved stability and performance enhancements plus some new features. The most interesting new feature is probably the ability to export traffic flows in Cisco's NetFlow format. Work has already started on ntop version 2.0.1 which will include a mirror mode where flow information is collected by ntop for traffic analysis.

ethereal 0.9

Ethereal is a free graphical protocol analyzer which allows operators to browse the captured data. Ethereal 0.9.0 has been released in December 2001 and many new protocol dissectors.


Recent Publications

Managing Business and Service Networks

This book explains the challenges involved in managing todays communication networks. The first part of the book introduces general network management concepts and the architecture of Aprisma's Spectrum management system. The second and probably the most interesting part of the book describes several case studies where management technologies have been applied to solve real-world management problems. The third part tries to draw some conclusions for future directions of network management research and development.

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.

Essential SNMP

This O'Reilly book on SNMP does not spend lots of pages to explain all the little details of the SNMP technology. The authors instead cover SNMP-based management software which is widely deployed, such as HP's OpenView, Castle Rock's SNMPc, NET-SNMP, and MRTG. They explain in practical examples how to configure agents and to setup polling and monitoring strategies.


Calendar and Announcements

IETF Meetings:

Conferences and Workshops:

Exhibitions and Trade Shows:


Publication Information

Editors:
Editorial Board:
Contact Information:

Submissions

The Simple Times solicits high-quality articles of technology and comment. Technical articles are refereed to ensure that the content is marketing-free. By definition, commentaries reflect opinion and, as such, are reviewed only to the extent required to ensure commonly-accepted publication norms.

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.

Subscriptions

The Simple Times is available in HTML, PDF and PostScript. New issues are announced via an electronic mailing list. Send electronic mail to st-request@simple-times.org with subscribe simple-times in the body if you want to subscribe to this list. Back issues are available via the SimpleTimes Web Server.