11.4 The Mechanics of SNMP

 < Day Day Up > 



SNMP specifies a structure for formatting messages and transmitting information between reporting devices and data-collection programs on the network. The SNMP-compliant devices on the network are polled for performance-related information, which is passed to a network management console. Alarms are also passed to the console. There, the gathered information can be viewed to pinpoint problems on the network or stored for later analysis.

SNMP runs on top of TCP/IP’s datagram protocol—specifically, the UDP—a transport protocol that offers a connectionless-mode service. This means that a session need not be established before network management information can be passed to the central control point. Although SNMP messages can be exchanged across any protocol, UDP is well suited to the brief request and response message exchanges characteristic of network management communications.

As noted, SNMP is a very flexible network management protocol that can be used to manage virtually any object. An “object” refers to hardware, software, or a logical association, such as a connection or virtual circuit. An object’s definition is written by the equipment vendor and is held in a MIB. The MIB is simply a list of switch settings, hardware counters, in-memory variables, or files that are used by the NMS to determine the alarm and reporting characteristics of each device on the network, including those connected over LANs.

SNMP is basically a request and response protocol. The management system retrieves information from the agents through SNMP’s “get” and “get-next” commands. The “get” request retrieves the values of specific objects from the MIB. The MIB lists the network objects for which an agent can return values. These values may include the number of input packets, the number of input errors, and routing information. The “get-next” request permits navigation of the MIB, enabling the next MIB object to be retrieved, relative to its current position. A “set” request is used to request a logically remote agent to alter the values of variables. In addition to these message types, there are “trap” messages, which are unsolicited messages conveyed from management agent to management stations. Other commands are available that allow the network manager to take specific actions to control the network. Although these commands look like SNMP commands, they are really vendor-specific implementations. For example, some vendors use a “stat” command to determine the status of network connections.

All of the major network management platforms support SNMP. In addition, many of the third-party systems and network management applications that plug into these platforms support SNMP. The advantage of using such products is that they take advantage of SNMP’s capabilities, while providing a GUI to make SNMP easier to use. Even MIBs can be selected for display and navigation through the GUI.

Another advantage of commercial products is that they can use SNMP to provide additional functionality. For example, Hewlett-Packard’s OpenView is used to manage network devices that are IP addressable and run SNMP. The automatic discovery capability finds and identifies all IP nodes on the network, including those of other vendors that support SNMP. On the basis of discovered information, the management system automatically draws a network topology map. Nodes that cannot be discovered automatically can be represented in one of two ways: first, by manually adding custom or standard icons to the appropriate map views; second, by using SNMP-based APIs to build map applications without having to manually modify the configuration to accommodate non-SNMP devices.

SNMP has several main components, including a management station, agents and proxies, and MIBs. The relationship of these components is shown in Figure 11.2.

click to expand
Figure 11.2: Relationship of SNMP components.

11.4.1 Management Station

The manager is a program that may run on one or more hosts, with each responsible for a particular subnet. The management station provides the user interface, in the form of a CLI or a GUI, that provides the means to configure, monitor, analyze, and control the various components on the network.

SNMP communicates network management data to a single site, called a management station. Under SNMP, each network segment must have a component, called an agent, which can monitor devices (called objects) on that segment and report the information to the management station. The agent may be a passive monitoring device whose sole purpose is to read the network, or it may be an active device that performs other functions as well, such as bridging, routing, and switching. Devices that are non-SNMP compliant must be linked to the management system via a proxy agent.

The manager provides the information display, communication with agents, information filtering, and control capabilities. The agents and their appropriate information are displayed in a graphical format, often against a network map. Network technicians and administrators can query the agents and read the responses on the management console. The manager also periodically polls the agents, searching for anomalies. Detection of an anomaly results in an alarm at the management system.

11.4.2 Management Agents

SNMP provides get, set, trap, and other functions to, among other things, retrieve, set device values, and receive notification of network events. An agent that resides on a network device responds to requests from the management station and generates events (traps) based on instructions issued from the management station or programmed into the agent. To have a wireless access point (AP) send SNMP traps, for example, the network administrator enters the IP address of the target AP along with the trap that defines the event or condition to be detected by the AP’s SNMP agent. The AP might send back a notification when any of the following events occur:

  • AP is powered on (cold start trap);

  • Ethernet network connection is established (network linkup trap);

  • User tried to communicate with the AP using an incorrect SNMP community string (authentication trap).

Another type of agent is the proxy agent, which is a program used to support devices that do not have an SNMP implementation available. The proxy is an SNMP management agent that services requests from the management station on behalf of one or more non-SNMP devices.

11.4.3 Management Information Base

A MIB is a compact database for a given network component that contains the parameters that can be managed for a network device. There is a standard definition of a MIB for every device that is supported by SNMP, and there is a standard extension called MIB II. There is also a mobile MIB that includes wireless-related (e.g., wireless performance statistics) and other information, such as the type of network adapter and version of firmware. Via the agent, the management station monitors and updates the values in the MIB.

The MIB contains a list of objects necessary to manage devices on the network. As noted, an “object” refers to hardware, software, or a logical association such as a connection or virtual circuit. The attributes of an object might include such things as the number of packets sent, routing table entries, and protocol-specific variables for IP routing. A basic object of any MIB is sysDescr, which is a textual description of the entity. This value includes the full name and version identification of the system’s hardware type, software operating system, and networking software. This object should contain only printable ASCII characters.

The first MIB was primarily concerned with IP routing variables used for interconnecting different networks. There are 110 objects that form the core of the standard SNMP MIB. The latest generation MIB, known as MIB II, defines more than 160 objects. It extends SNMP capabilities to a variety of media and network devices, marking a shift from Ethernets and TCP/IP WANs to all media types used on LANs and WANs. Many vendors want to add value to their products by making them more manageable, so they create private extensions to the standard MIB, which can bring the number of objects to 200 or more.

Many vendors of SNMP-compliant products include MIB tool kits that generally-include two types of utilities. One, a MIB compiler, acts as a translator that converts ASCII text files of MIBs for use by an SNMP management station. The second type of MIB tool converts the translator’s output into a format that can be used by the management station’s applications or graphics. These output handlers, also known as MIB editors or MIB walkers (Figure 11.3), let users view the MIB and select the variables to be included in the management system. Some vendors of SNMP management stations do not offer MIB tool kits, but rather an optional service whereby they will integrate into the management system any MIB a user requires for a given network. This service includes debugging and technical support.

click to expand
Figure 11.3: MIB Walk from SolarWinds.Net is used to search the SNMP tree for a target device and dump the value of each object identifier (OID). This tool is commonly used to find out what MIBs and OIDs are supported on a particular device. MIB Walk uses a database of MIB information to determine the plain language name for each OID and the MIB to which it belongs.

There are also MIB browsers that allow network managers, technicians, and systems engineers to query a remote device for software and hardware configurations via SNMP and make changes to the remote device. The remote device could be a router, switch hub, server, firewall, or any other device that supports SNMP. Another common use for a MIB browser is to find out what MIBs and object IDs (OIDs) are supported on a particular device, per Figure 11.3.

11.4.4 Remote Network Monitor

The common platform from which to monitor multivendor networks is SNMP’s remote monitoring (RMON) MIB. Although a variety of SNMP MIBs collect performance statistics to provide a snapshot of events, RMON enhances this monitoring capability by keeping a past record of events that can be used for fault diagnosis, performance tuning, and network planning. The original remote network monitoring MIB defines a framework for the remote monitoring of Ethernet.

Subsequent RMON MIBs extend this framework to token ring and other types of networks.

An RMON probe is installed on at least one remote system for each remote LAN or segment to be monitored, whether it is wired or wireless (802.11a and 802.11b). The probe views every packet and produces summary information on various types of packets, such as undersized packets, and events, such as packet collisions. The probes can also capture packets according to predefined criteria set by the network manager or test technician. At any time, the RMON probe can be queried for this information by a network management application or an SNMP manager so that detailed analysis can be performed in an effort to pinpoint where and why an error occurred.

When it comes to monitoring wireless LANs, despite the interoperability of Wi-Fi equipment from different vendors, vendors of RMON probes or consoles support only certain types of equipment. Some vendors may only support Wi-Fi equipment from Cisco, Intel, or Nortel, for example. The reason is that the Wi-Fi vendors use different manufacturers’ chipsets, and these chipsets must support RMON. To complicate matters, a different chipset may be used for 802.11a and 802.11b products.

Implementing RMON entails having a management application that views the internetwork, for example, to gather data from RMON agents running on each segment in the network, both wired and wireless. The data is integrated and correlated to provide various internetwork views that provide end-to-end visibility of network traffic, both LAN and WAN. The operator can switch between views to monitor the performance of the network from a variety of perspectives.

The operator can switch between a MAC view (which shows traffic going through hubs and switches), a network view (which shows end-to-end routed traffic), or apply filters to see only traffic of a given protocol or suite of protocols. These traffic matrices also provide the information necessary to configure or partition the internetwork to optimize LAN and WAN performance and utilization.

Another type of application allows the network manager to consolidate and present multiple segment information and configure RMON alarms, as well as perform baseline measurements and long-term reporting. Alarms can be set on any RMON variable. Notification via traps can be sent to multiple management stations. Baseline statistics allow long-term trend analysis of network traffic patterns under normal conditions, which can then be used to plan for network growth.

The original RMON specification consists of Ethernet groups, which are sets of functions that can be carried out at the MAC layer. (The specification has been extended over the years to support other networks as well, such as legacy token ring and FDDI, but Ethernet will suffice for this discussion.) A follow-up specification called RMON2 allows probes to gather information from the network layer (Layer 3) all the way up to the application layer (Layer 7) of the OSI reference model. This allows probes to gather not only the information that RMON can, but information about network specific applications like HTTP, NFS, Apple Talk, and IPX as well. With this added data-collection capability, administrators can obtain a more complete picture of the enterprise network.

Ethernet Statistics Group

The statistics group provides segment-level statistics (see Figure 11.4) that show packets, octets (or bytes), broadcasts, multicasts, and collisions on the local segment, as well as the number of occurrences of dropped packets by the agent. Each statistic is maintained in its own 32-bit cumulative counter. Real-time packet size distribution is also provided.

click to expand
Figure 11.4: The Ethernet statistics window accessed from Enterasys Networks’ NetSight Element Manager. This window would be used to view a detailed statistical breakdown of traffic on the monitored Ethernet network segment. The data provided applies only to the interface or network segment, either wired or wireless.

History Control Group

The history control group controls the statistical sampling of data from various types of networks. This group specifies control parameters, such as the frequency of data sampling.

Ethernet History Group

With the exception of packet-size distribution, which is provided only on a real-time basis, the history group provides historical views of the statistics provided by the statistics group. The history group can respond to user-defined sampling intervals and bucket counters, allowing for some customization in trend analysis.

The RMON MIB comes with two defaults for trend analysis. The first provides for 50 buckets (or samples) of 30-second sampling intervals over a period of 25 minutes. The second provides for 50 buckets of 30-minute sampling intervals over a period of 25 hours. Users can modify either of these or add additional intervals to meet specific requirements for historical analysis. The sampling interval can range from 1 second to 1 hour.

Host Table Group

The RMON MIB specifies a host table that includes node traffic statistics: packets sent and received, octets sent and received, as well as broadcasts, multicasts, and errored packets sent. In the host table, the classification “errors sent” is the combination of undersized packets, fragments, CRC/alignment errors, collisions, and oversized packets sent by each node.

The RMON MIB also includes a host timetable that shows the relative order in which the agent discovered each host. This feature is not only useful for network management purposes but also assists in uploading those nodes to the management station of which it is not yet aware. This reduces unnecessary SNMP traffic on the network.

Host Top N Group

The host top N group extends the host table by providing sorted host statistics, such as the top 10 nodes sending packets or an ordered list of all nodes according to the errors sent over the last 24 hours. The data selected and the duration of the study are both defined at the network management station. The number of studies that can be run depends on the resources of the monitoring device.

When a set of statistics is selected for study, only the selected statistics are maintained in the host top N counters; other statistics over the same time intervals are not available for later study. This processing—performed remotely in the RMON MIB agent—reduces SNMP traffic on the network and the processing load on the management station, which would otherwise need to use SNMP to retrieve the entire host table for local processing.

Alarms Group

The alarms group provides a general mechanism for setting thresholds and sampling intervals to generate events on any counter or integer maintained by the agent, such as segment statistics, node traffic statistics defined in the host table, or any userdefined packet match counter defined in the filters group. Both rising and falling thresholds can be set, each of which can indicate network faults. Thresholds can be established for both the absolute value of a statistic or its delta value, enabling the manager to be notified of rapid spikes or drops in a monitored value.

Filter Group

This function provides a generic filtering engine that implements all packet-capture functions and events. The packet-capture buffer is filled with only those packets that match the user-specified filtering criteria. Filtering conditions can be combined using the Boolean parameters “and” or “not.” Multiple filters are combined with the Boolean “or” parameter.

Packet-Capture Group

The type of packets collected is dependent on the filter group. The packet-capture group allows the user to create multiple capture buffers and control whether the trace buffers will wrap (overwrite) when full or stop capturing. The user may expand or contract the size of the buffer to fit immediate needs for packet capturing, rather than permanently commit memory that will not always be needed.

Notification (Event) Group

In a distributed management environment, the RMON MIB agent can deliver traps to multiple management stations that share a single community name destination specified for the trap. In addition to the three traps already mentioned—rising threshold and falling threshold (see alarms group) and packet match (see packetcapture group)—the following seven additional traps that can be specified:

  • coldStart: Indicates that the sending protocol entity is reinitializing itself such that the agent’s configuration or the protocol entity implementation may be altered.

  • warmStart: Indicates that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered.

  • linkDown: Indicates that the sending protocol entity recognizes a failure in one of the communication links represented in the agent’s configuration.

  • linkUp: Indicates that the sending protocol entity recognizes that one of the communication links represented in the agent’s configuration has come up.

  • authenticationFailure: Indicates that the sending protocol entity is the addressee of a protocol message that is not properly authenticated. While implementations of the SNMP must be capable of generating this trap, they must also be capable of suppressing the emission of such traps via an implementation-specific mechanism.

  • egpNeighborLoss: Indicates that an External Gateway Protocol (EGP) neighbor for whom the sending protocol entity was an EGP peer has been marked down and the peer relationship is no longer valid.

  • enterpriseSpecific: Indicates that the sending protocol entity recognizes that some enterprise-specific event has occurred.

The notification (event) group allows users to specify the number of events that can be sent to the monitor log. From the log, any specified event can be sent to the management station. The log includes the time of day for each event and a description of the event written by the vendor of the monitor. The log overwrites when full, so events may be lost if not periodically uploaded to the management station.

Traffic Matrix Group The RMON MIB includes a traffic matrix at the MAC layer. A traffic matrix shows the amount of traffic and number of errors between pairs of nodes—one source and one destination address per pair. For each pair, theRMONMIB maintains counters for the number of packets, number of octets, and error packets between the nodes. Users can sort this information by source or destination address.

11.4.5 RMON2

As noted, the RMON MIB is basically a MAC-level standard. Its visibility does not extend to the router port, meaning that it cannot see beyond individual LAN segments. As such, it does not provide visibility into conversations across the network or connectivity between the various network segments. Given the trends toward remote access and distributed workgroups that rely on wireless as well as wired connections, both of which may generate a lot of intersegment traffic, visibility across the enterprise is an important capability to have.

RMON2 extends the packet-capture and decoding capabilities of the original RMONMIB to Layers 3 through 7 of the OSI reference model. This allows traffic to be monitored via network-layer addresses—which letRMONsee beyond the router to the internetwork—and distinguish between applications based on the protocols used. Since a bridge does not perform any IP routing or forwarding, however, certain groups of managed objects are not meaningful. For SNMP requests pertaining to such managed objects, the node simply returns a “no such name” error status in the response.

Analysis tools that support the network-layer can sort traffic by protocol rather than just report on aggregate traffic. This means that network managers will be able to determine, for example, the percent of IP versus IPX traffic traversing the network. In addition, these higher-level monitoring tools can map end-to-end traffic, giving network managers the ability to trace communications between two hosts—or nodes—even if the two are located on different LAN segments. RMON2 functions that allow this level of visibility include the following:

  • Protocol directory table: Provides a list of all the different protocols a RMON2 probe can interpret.

  • Protocol distribution table: Permits tracking of the number of bytes and packets on any given segment that have been sent from each of the protocols supported. This information is useful for displaying traffic types by percentage in graphical form.

  • Address mapping: Permits identification of traffic-generating nodes, or hosts, by Ethernet or token-ring address in addition to MAC address. It also discovers switch or hub ports to which the hosts are attached. This is helpful in node discovery and network topology applications for pinpointing the specific paths of network traffic.

  • Network-layer host table: Permits tracking of bytes, packets, and errors by host according to individual network-layer protocol.

  • Network-layer matrix table: Permits tracking, by network-layer address, of the number of packets sent between pairs of hosts.

  • Application-layer host table: Permits tracking of bytes, packets, and errors by host and according to application.

  • Application-layer matrix table: Permits tracking of conversations between pairs of hosts by application.

  • History group: Permits filtering and storing of statistics according to userdefined parameters and time intervals.

  • Configuration group: Defines standard configuration parameters for probes that include such parameters as network address, serial line information, and SNMP trap destination information.

RMON2 can help network managers understand traffic flow for the purpose of capacity planning, as well as for network troubleshooting. The capability to identify traffic levels and generate statistics by application has the potential to greatly reduce the time it takes to troubleshoot certain problems. Without tools that can pinpoint which software application is responsible for gobbling up a disproportionate share of the available bandwidth, network managers can only guess. Often it is easier just to upgrade a server or buy more bandwidth, but that inflates operating costs and shrinks IT budgets.

Applying remote-monitoring and statistics-gathering capabilities that are available through the RMON MIBs offers a number of benefits. The availability of critical networks is maximized, since remote capabilities allow for timely problem resolution. With the capability to resolve problems remotely, operations staff can avoid costly travel to troubleshoot problems on-site. With the capability to analyze data collected at specific intervals over a long period of time, intermittent problems can be tracked down that would normally go undetected and unresolved. And with RMON2, these capabilities are enhanced and extended up to the applications level across the enterprise.



 < Day Day Up > 



LANs to WANs(c) The Complete Management Guide
LANs to WANs: The Complete Management Guide
ISBN: 1580535720
EAN: 2147483647
Year: 2003
Pages: 184

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net