SNMP IS IP S COMMON MANAGEMENT PLATFORM

SNMP IS IP'S COMMON MANAGEMENT PLATFORM

Almost all modern internetwork management suites are built atop the Simple Network Management Protocol. Thus, before discussing the Cisco management applications, a look at their underlying network management technology is in order.

What Is SNMP?

SNMP is a TCP/IP protocol purpose-built to serve as a communications channel for internetwork management operating at the application layer of the IP stack. Although SNMP can be directly operated through the command line, it's almost always used through a management application that employs the SNMP communications channel to monitor and control networks. As Figure 13-5 shows, SNMP has two basic components: a network management station and agents.

Figure 13-5: SNMP is a communications channel for network management

Agents are small software modules, residing on managed devices, which can be configured to collect specific pieces of information on device operations. Most of the information consists of totals, such as total bytes, total packets, total errors, and the like. Agents can be deployed on the panoply of devices, such as:

• Routers

• Switches

• Access servers

• Servers (Windows, UNIX, Linux, MVS, VMS, and so on)

• Workstations (Windows PCs, Macs, UNIX, and Linux desktops)

• Printers

• UPS power backup systems

The idea is to place agents on all network devices and manage things according to the status information sent back. A piece of equipment with an SNMP agent loaded onto it is referred to as a managed device (also called a network element).

The NMS is the internetwork's control center. Usually, there's just one NMS for an autonomous system, although many large internetworks use more than one NMS-usually arranged in a hierarchy. Most NMSs today run on dedicated UNIX or Microsoft servers.

SNMP Polling and Managed Objects

SNMP is a fairly simple request/response protocol. It works by having the NMS periodically poll managed devices for fresh information. The polling frequency is a matter of configuration choice, but it usually takes place once every few minutes or so. There are three types of polling:

• Monitor polling To check that devices are available and to trigger an alarm when one is not

• Threshold polling To detect when conditions deviate from a baseline number by a percentage greater than allowed (usually plus or minus 10 percent to 20 percent) and to notify the NMS for review

• Performance polling To measure ongoing network performance over longer periods and to analyze the data for long-term trends and patterns

The agent responds to the poll by returning a message to the NMS. It's able to do this by capturing and storing information on subjects that it has been configured to monitor. These subjects are usually processes associated with the flow of packets. A process about which the agent collects data is called a managed object. A managed object is a variable characteristic of the device being managed. The total number of UDP connections open on a managed device, for example, could be a managed object. One open UDP session on a specific interface is an object instance, but the total number of simultaneously open UDP sessions on the device (say, a router) is a managed object. Figure 13-6 shows our example UDP connections as managed objects and instances.

Figure 13-6: SNMP gathers information on managed devices

Managed objects are usually operating characteristics of managed devices. The managed devices can be anywhere in the topology-backbone devices, servers, or end systems. Most objects are physical pieces, such as a network interface, but a managed object isn't necessarily a physical entity. An object could also be a software application, a database, or some other logical entity.

The MIB

The agent stores the information about objects in specialized data records called MIBs ( management information bases ). An MIB is the storage part of the SNMP agent software. Information stored in MIBs is referred to as variables (also called attributes ). MIBs usually collect information in the form of totals for a variable during a time interval, such as total packets over five minutes. Figure 13-7's example shows variables being extracted from instances and processed through managed MIBs and the managed object-in this example, a count of total Ethernet packets going through a router's interface. Again, the packet count from each interface is a managed object instance; the count for all three interfaces is the managed object.

Figure 13-7: MIBs are the basic building blocks of an SNMP management system

By collating data from multiple objects, the MIB lets the agent send the NMS information concerning everything on the device that is being monitored.

Types of MIBs

MIBs are prefabricated to perform specific jobs. Basic MIBs usually come packaged inside the network device operating system. For example, IOS comes packaged with MIBs for most network management jobs.

Generally, MIBs are named using a convention that indicates the relevant category. This is known as the MIB Object ID (OID).

For example, a Cisco MIB object that deals with a specific network interface will have if in its name (from the letters i and f in interface). The ifInErrors MIB object monitors incoming packet errors on an interface; ifOutErrors monitors the outgoing errors, sysLocation reports a device's network location, and so on. Table 13-1 shows six basic MIB categories used in most SNMP systems.

Table 13-1: Basic Cisco MIB Objects Commonly Used in SNMP Implementations

Category	Description and Examples
Configuration	MIBs that report basic management information, such as device name, contact person, device location, and uptime. MIB configuration objects are sysName, sysDescr, sysContact, sysLocation, sysUpTime, ifNumber, romID, and others.
Interface error rates	MIBs that monitor specific interfaces. Packet errors are a normal condition, but watching their trends indicates device health and helps isolate faults. For Ethernet interfaces, use ifInErrors, ifOutErrors, locifCollisions, locIfInRunts, locIfInGiants, locIfCRC, and others. For serial interfaces, use locIfInFrame, locIfInAbort, locIfInIgnored, locIfResets, locIfRestarts, and others.
Bandwidth	ICMP is a layer-3 protocol that reports on IP packet processing. It's best known for its echo command, used to verify the presence of other devices by pinging them. Timed pings are used to determine how far away a device is (much like in the submarine movies). SNMP sends ping input and output messages to measure available bandwidth. Cisco's MIB objects for this are icmpInEchos and icmpInEchoReps, and icmpOutEchos and icmpOutEchoReps. Generally speaking, these are the only SNMP messages not sent as UDP messages.
Traffic flow	Performance management is largely a matter of measuring traffic flow. There are Cisco MIBs to measure traffic rates, both as bits per second and packets per second: locIfInBitsSec, locIfOutBitsSec, locIfInPktsSec, and locIfOutPktsSec.
Unreachable address	The object to measure how often a router is asked to send messages to an unreachable address is icmpOutDesUnreachs.
SNMP data	There are even objects to measure how much time the router spends handling SNMP messages. The objects include snmpInGetRequests and snmpOutGetRequests, snmpInGetResponses and snmpOutGetResponses, and others.

It is possible to gather information on a single object instance only, called a scalar object. Most managed objects, however, are composed of several related instances. This practice, called tabular objects, is the rule in most MIBs, because it's more efficient to manage as much as possible from a single data collection point. As the name implies, a tabular MIB keeps the information straight by storing it in rows and tables.

Note 

MIB lingo can be confusing. You'll hear references to the MIB as if it were a single MIB object. But that's not the case. For example, the Cisco MIB is not an MIB as such; it's actually the root of about 400 private Cisco MIB objects.

What Makes SNMP Machine-Independent

We don't want to get too technical in this book, but you should understand how the SNMP standard makes itself machine-independent. In other words, how is it able to run on different brands of equipment, each with its own proprietary operating system?

The SNMP standard requires that every MIB object have an object ID and a syntax. An object ID identifies the object to the system and tells what kind of MIB to use and what kind of data the object collects. Syntax means a precise specification a machine can understand in binary form.

To understand a field's contents, IOS must know whether the field contains a number, text, a counter, or other type of data. These are called data types. Data types specify the syntax to be used for a data field. A field is any logical piece of data, such as a model number or temperature reading. In the same way that a field has its own box on an input screen, it has its own position in a computer file. A file represents data in binary (0's and 1's), and a set of binary positions are reserved for each field within the file. All fields must be declared as some data type or another, or else the machine cannot process the data held there.

Computer hardware architectures, operating systems, programming languages, and other environmentals specify the data types they're willing to use. A data type represents the layer where software meets hardware. It tells the machine what syntax to use to interpret a field's contents. A different syntax is used for floating-point numbers, integer numbers, dates, text strings, and other data types.

SNMP makes itself independent by declaring its own data types. It does so in the form of the Structure of Management Information (SMI) standard. SMI is a standard dedicated to specifying a machine-independent syntax for every data type. These data types are independent of the data structures and representation techniques unique to particular computer architectures. SMI specifies the syntax for data types such as object IDs, counters, rows, tables, octet strings, network addresses, and other SNMP elements.

MIBs are programmed by vendors using an arcane programming language called ASN.1, created just for programming SMI data types. ASN.1 (Abstract Systems Notation One) is an OSI standard, from the same people that brought us the seven-layer reference model. Figure 13-8 shows how SMI data types universalize MIB information.

Figure 13-8: MIBs are built using machine-independent SMI data types

SMI tries to let vendors code "write-once, run-anywhere" MIB objects. In other words, someone should be able to write a single piece of MIB software-a packet counter, for example-and the counter MIB should be able to run on any device that supports the SMI syntax definition for a counter.

SMI data types are SNMP's building blocks at the lowest level. They are used to construct MIB object formats in a syntax any machine can understand. From there, object instances are measured and rolled up into managed objects, which in turn are reported by the SNMP agent to the NMS. This is how NMSs can operate across disparate device architectures.

Standard MIBs and Private MIBs

The current MIB standard is MIB-II, which has nearly 200 standard MIB objects. The standard is implemented as a hierarchy that starts from a root and continues to branch down from the source MIB to the root Internet MIB. Looking at Figure 13-9, you can see that each branch is marked both by a name and a number (the numbers are used to build object IDs).

Figure 13-9: The Internet's family lineage yields the standard Internet MIB lineage

Figure 13-9 also shows the players in the history of the Internet. ISO is the International Standards Organization, and DoD is the U.S. Department of Defense (which started it all with ARPANET). CCITT is the Consultative Committee for International Telegraph and Telephone. The CCITT is only a distant cousin of the Internet, handling telephony and other communications standards. The CCITT is now known as the ITU-T (for Telecommunication Standardization Sector of the International Telecommunications Union), but you'll still see the CCITT acronym attached to dozens of standards.

Because they're more user-friendly, text strings are usually used to describe MIB objects in directories. Object IDs are mainly used by software to create compact, encoded representations of the names.

Working from the tree structure in Figure 13-9, the Internet root's object ID is 1.3.6.1, named iso.org.dod.internet. The two main branches beyond the Internet root are the management and private MIBs. Industry-standard MIBs go through the management branch to become iso.org.dod.internet.mgmt.mib with the object ID 1.3.6.1.2.1. Private MIBs become iso.org.dod.internet.private and 1.3.6.1.4. Cisco's private MIB is represented as iso.org.dod.internet.private.enterprise.cisco, or object ID 1.3.6.1.4.1.9.

Vendors can build private MIBs by extending standard MIB branches. In this way, they can customize MIBs to better fit their particular needs. Figure 13-10-Cisco's private MIB hierarchy-shows how private MIBs extend from the standard Internet MIB.

Figure 13-10: Cisco's private hierarchy branches into four subgroups

Many of the object groups within the Cisco Management, Temporary Variables, and Local Variables subgroups measure Cisco proprietary technology. For example, the Cisco Environmental Monitor group in the Cisco Management subgroup-object ID 1.3.6.1.4.1.9.9-looks after such things as the operating temperature inside the device. This type of information is the "deep" stuff we were talking about that management applications from other manufacturers have trouble getting at.

Another important thing to see in Figure 13-10 is support for legacy desktop protocols. Novell NetWare IPX, VINES, AppleTalk, DECnet, and even Xerox XNS networks can be managed using Cisco MIBs. These are legacy in that the IP LAN specification seems to be steamrolling the market, but the others are still in use and therefore important to their customers.

Polling Groups and Data Aggregation

MIBs are frequently placed into polling groups to facilitate SNMP data collection. A polling group is a set of logically related managed objects that are reported and analyzed as a cohesive entity. For example, Figure 13-11 shows polling groups for three different classes of equipment in an internetwork: the backbone switches, routers, and application servers. Different MIB variables are likely to be collected for each type, so each gets its own polling group. In this way, logically related management information is compiled and stored into the SNMP database under group names.

Figure 13-11: Polling groups are used to help make SNMP data more manageable

Grouping simplifies the network administrator's job. In the example in Figure 13-11, thresholds can be set to fit tolerances appropriate for each group. For example, a network team is likely to set alarm variables to be more sensitive for the backbone switches because trouble with them could bring the entire internetwork down. Polling similar MIBs en masse simplifies SNMP operations and helps assure data that's consistent, trustworthy, and easier to assimilate.

Groups also make it easier to limit the amount of information stored in the NMS database. SNMP could build mountains of data on every device in a network, but doing so would be neither practical nor worthwhile. Storing information on related MIB groups facilitates the movement of raw data through a cycle of aggregation and purging. Figure 13-12 shows a typical scenario, in which MIB variables in a group are polled and stored in the NMS database every five minutes. Each midnight, the data is aggregated into minimums, maximums, and averages for each hour and stored in another database. The data points are purged from the database weekly, leaving behind only the aggregated data.

Figure 13-12: Data aggregation summarizes data while preserving its integrity

The collect-aggregate-purge cycle has several benefits. It keeps disk space open on the NMS server for storing new MIBs and maintains statistical integrity of the data record. At the same time, it also keeps a consistently fresh picture of network operations.

SNMP Commands

The simple in Simple Network Management Protocol comes from the fact that the protocol has just six root commands. They're used to set SNMP parameters within the device's config file. Here are the root SNMP commands:

• Get Used by the NMS to retrieve object instances from an agent

• GetNext Used to retrieve subsequent object instances after the first instance

• GetBulk This operation retrieves all instances in a managed object (replacing the need for iterative GetNext operations)

• Set Used to set values for object instances within an agent (such as a threshold)

• Trap Used to instruct an agent to unilaterally notify the NMS of an event (without being polled)

• Inform This command instructs one NMS to forward trap information to one or more other NMSs

Note 

Most of the time, SNMP commands are used by computer programs rather than by people directly. For example, if an administrator enters the location of a router in an inventory screen in the Essentials console, a process is launched from Essentials that changes the set snmp location in IOS inside that router, and the MIB value is updated accordingly.

SNMP's two basic commands are get and set. The set command is used to set managed parameters in managed objects. When you issue an SNMP SET command, it configures the network device with the corresponding value (as defined by the MIB). So, for example, if an administrator enters the location of a router in an inventory screen of an SNMP management station, this, in turn, uses SNMP set commands to set this location value on the router.

Conversely, the get command is used to fetch stored variables from agents and bring them back to the NMS.

SNMP needs to be simple in order to make itself supportable by disparate architectures. Doing so is a practical requirement for SNMP interoperability.

Thresholds

A threshold defines an acceptable value or value range for a particular SNMP variable. When a variable exceeds a policy, an event is said to have taken place. An event isn't necessarily an either/or situation, such as a switch going down. Events are usually operational irregularities that the network team would want to know about before service is affected. For example, a network administrator may set a policy for the number of packet errors occurring on router interfaces in order to steer traffic around emerging traffic bottlenecks. Thresholds can be set either as a ceiling or as a range with upper and lower bounds. The two types of thresholds are depicted in Figure 13-13.

Figure 13-13: Thresholds set a normal operating range for a managed object

The shaded portions of the graph in Figure 13-13 are called threshold events. In other words, an event is when something has taken place in violation of the set policy. A sampling interval is the period of time during which a statistic is compiled. For example, an MIB object can store the total number of packet errors taking place during each fiveminute period. Intervals must be long enough to gather a representative sample, yet short enough to capture events before they can substantially affect network performance.

Events and Traps

When an event occurs, the network administrator can specify how the SNMP agent should respond. The event can either be logged or an alarm message can be sent to the NMS. An SNMP alert message is called a trap, so named because it catches (or traps) the event at the device. For the sake of clarification, an alarm is a type of alert message. A trap contains information about the event. Figure 13-14 shows the course of events leading up to an alarm.

Figure 13-14: An SNMP trap proactively reports an event to the NMS

Alarms can take many forms. They're often configured to show themselves as a blinking icon on the NMS console, but you could have a noise generated. Networks that don't have administrators present at the NMS all the time have the trap dial a pager or send a priority e-mail to alert the person on response duty at the time.

Traps aren't used just to send alarms. As an internetwork grows in size, SNMP overhead traffic will increase along with it. Network managers can reduce SNMP overhead by stretching the polling frequency, but doing that makes the NMS less responsive to emerging network problems. A better way to limit SNMP overhead is to use traps. Given that they're unsolicited messages instead of SNMP poll responses, traps consume a negligible amount of bandwidth.

The following code snippet is from a Cisco router's config file. It shows the SNMP settings made for the device. RO and RW mean that this is the read-only or read-write (respectively) community strings that make the device a member of a particular management group.

 MyRouter(config)# snmp-server community yellow RO MyRouter(config)# snmp-server community blue RW MyRouter(config)# snmp-server enable traps snmp MyRouter(config)# snmp-server enable traps isdn call-information MyRouter(config)# snmp-server enable traps config MyRouter(config)# snmp-server enable traps bgp MyRouter(config)# snmp-server enable traps frame-relay MyRouter(config)# snmp-server enable traps rtr MyRouter(config)# snmp-server host 10.1.1.13 traps vpi 

A number of SNMP traps are enabled in this config file. This tells the SNMP agent on the device to send trap messages if anything changes. The last line gives the IP address of the NMS so that the agent knows where to send the trap messages.

RMON: Hardware Probes for Switched Networks

RMON (short for remote monitoring) is a separate but related management standard that complements SNMP. RMON is similar to SNMP in several ways: it is an open standard administered by the IETF; it uses SMI data types and the root MIB format; and it collects device data and reports it to an NMS. But RMON differs from normal SNMP in these fundamental ways:

• RMON is instrument-based, in that it uses specialized hardware to operate.

• RMON proactively sends data instead of waiting to be polled, making it bandwidth-efficient and more responsive to network events.

• RMON allows much more detailed data to be collected.

RMON instrumentation is more powerful, but more expensive. Consequently, RMON probes tend to be placed on critical links, such as network backbones and important servers.

RMON and Switched Networking

The movement toward RMON-based network management is closely linked to the rise of switched networking. While LAN switching is on the rise as the way to improve network performance, it poses special problems for conventional SNMP management methods. In a network formed using hubs, a LAN analyzer has full visibility because the medium is shared by all nodes. But a switched LAN isn't a shared medium, so to maintain the same level of visibility, the analyzer would have to be placed on each switched port. The solution is to incorporate the analyzer (or at least the sensor part of it) directly into the switch's hardware. That's what an RMON probe is. Figure 13-15 shows a switched network managed with and without RMON.

Figure 13-15: RMON probes provide management visibility across switched networks

RMON became a standard in 1992 with the release of RMON-1 for Ethernet. The RMON-2 standard, the current version, was completed in early 1997. While RMON-1 operated only at the physical and data-link layers (layers 1 and 2) of the seven-layer OSI reference model, RMON-2 adds the capability to collect data at higher layers, giving it more reporting capability. The ability to monitor upper-layer events has been a boon to the popularity of RMON. For example, RMON-2 can report what's happening with IPX traffic as opposed to IP on a multiprotocol LAN segment.

RMONs replace expensive network analyzer devices that must be physically attached to the approximate area of a network problem. RMON probes come in different forms, depending on the size and type of device to be monitored:

• An RMON MIB that uses the monitored device's hardware (called an embedded agent)

• A specialized card module inserted into a slot within the monitored device

• A purpose-built probe externally attached to one or more monitored devices

• A dedicated PC attached to one or more monitored devices

Having specialized hardware remotely located with a monitored device brings advantages. RMON probes can yield a much richer set of measurement data than that of an SNMP agent. The dedicated hardware is used as a real-time sensor that can gather and analyze data for possible upload to the NMS.

The Nine RMON MIB Groups

Another advantage RMON enjoys is its freedom as a separate standard. The root RMON MIB defines nine specialized MIB groups (and a Token Ring group). The nine groups let RMON collect more detailed and granular management information than can be collected using SNMP. Figure 13-16 charts the RMON MIBs.

Figure 13-16: RMON stores Ethernet management data in nine specialized groups

RMONs, at a minimum, come with the Events and Alarm groups. Most come with four groups needed for basic management: Events, Alarms, Statistics, and History. Because of hardware expense and response time concerns, resource-intensive groups, such as the Traffic Matrix group, are infrequently deployed.

The Alarm RMON MIB is a more powerful mechanism for event management than SNMP. For example, because there's a separate MIB just to keep track of events, RMON can adjust itself to avoid sending too many alarms. In addition, the Matrix MIB can monitor traffic on a "conversation" basis. In other words, it can be set up to monitor connections between pairs of MAC addresses and report on what's happening with each connection. For example, if a Matrix MIB was set up to watch an expensive link, say, between New York and London, and someone was using it to play a transatlantic game of Doom, the MIB could see that and alert the NMS that valuable bandwidth was being wasted.

The problem with RMON is that it's expensive. It takes extra hardware to store and analyze packets in real time, and that costs money. Consequently, RMON is being put to use to manage just links that are mission-critical or expensive.

Trends in Network Management Technology

SNMP compliance issues have left new versions of the standard mired in political infighting. In addition, the fast development of powerful RMON-based tools is pushing the approach to network management in a new direction. The technology underpinnings of network management applications exhibit these trends:

• More powerful data collection (more information reported faster)

• More proactive management

• Improved built-in hardware support for management

• Better security for protecting management tools themselves

The trend toward more intensive management of internetworks is coming up against the same old problem: every management message is overhead that consumes precious bandwidth. This dilemma is what's pushing the industry toward RMON, because that technology captures better information and works locally (instead of through NMS polling).

The other trends have to do with making management systems more efficient and providing SNMP itself with better security.

Advanced SNMP Commands

The evolution of SNMP can be seen in the GetBulk and Inform commands. GetBulk makes it easier for the agent to fetch MIB information from multiple object instances. Inform makes it easier to use a hierarchy of NMSs to manage complex internetworks, as shown in Figure 13-17.

Figure 13-17: SNMP version 2 emphasizes flexibility and security

SNMP's support for protocols beyond IP is a substantial change. Doing this will extend the reach of SNMP into non-IP topologies. This is an important advance for network managers overseeing multiprotocol internetworks. Don't forget that big parts of many sophisticated internetworks run legacy network architectures, such as Novell NetWare IPX, AppleTalk, and DECnet, and will continue to do so for the foreseeable future. Extended SNMP protocol support will help bring these topologies under the control of centralized NMSs.

SNMP Version 1 vs. SNMP Version 2

Keeping track of standards can be confusing because they overlap. For example, right now, the majority of all SNMP implementations are of version 2 (SNMPv2). Whatever the version, here are the components of the basic SNMP message format:

• Version The SNMP version being used.

• Community string The equivalent of a group password used by all devices in the same administrative domain. The SNMP message is ignored without the proper community string.

• Protocol Data Unit (PDU) type The instructions about what to do. The PDU specifies the operation to be performed ( GetBulk, Trap, and so on) and the object instances on which to perform the operation. The PDU is comprised of:

  • Error status This field defines an error and error type.

  • Error index This field associates the error with a particular object instance.

  • Variable bindings Don't be intimidated by the fancy name; a variable binding is the data collected on the object instance-it's the SNMP packet's payload.

SNMPv2 enhances the message format with these changes:

• Wrapper This includes destination and source party identifiers for SNMP message authentication and privacy, and also identifies context in the form of the managed objects on which the PDU is to perform its operation.

• Enhanced PDU The GetBulk and Inform operations.

• Multiple transport protocols Originally, all SNMP packets were transmitted through UDP (User Datagram Protocol). SNMPv2 supports Novell NetWare IPX, AppleTalk DDP, and OSI CLNS.

The enhancements in SNMPv2 reflect the demand for more powerful controls and better security.

Better Security for SNMP Messages

Support for SNMP has been hindered by security concerns. A smart hacker armed with a protocol analyzer would like nothing more than to intercept SNMP messages. Instead of just getting some user's file download, hacking an SNMP system could yield a virtual blueprint of the internetwork topology.

Today, most networks rely on a combination of access lists and SNMP community strings to secure their management systems. If a hacker somehow obtains the community string for an SNMP system, he might navigate around the access list controls and retrieve data on all network devices. Worse, knowing the Read-Write community strings would allow a hacker to alter config file settings on the community's network devices. This would be a devastating security breach, especially if community strings on set operations were stolen, because that would hand over control of all devices configured for remote management.

Both customers and manufacturers called for more stringent SNMP security. Keep in mind that a user here doesn't necessarily have to be a person; it could just as easily be an automated process (such as a get request) as part of an SNMP poll. In SNMPv2 format, the wrapper contains authentication information that identifies approved destination and source parties to the SNMP transaction. The authentication protocol is designed to identify the originating party reliably. Beyond authentication, SNMPv2 makes it possible to specify which managed objects can be included in a message. Figure 13-18 outlines measures taken to secure SNMPv2 messages.

Figure 13-18: SNMPv2 messages are secured by authenticating parties and control measures

SNMPv3

SNMPv1 and SNMPv2 are the big dogs on the management block. However, they are not perfect. As noted earlier, neither version offers tight enough security features. To be more precise, neither version is able to authenticate the source of a management message or provide encryption. Without authentication, it is possible for outsiders to use SNMP functions. Without encryption, it is possible for your network's management commands to be monitored.

Because of this shortcoming, many SNMPv1 and v2 implementations allow just readonly capability. This reduces their usability to serve only as a network monitor. SNMPv3 looks to correct this deficiency.

The SNMPv3 functionality has been described in its IETF drafts as "SNMPv2 plus administration and security." SNMPv3 adds three services:

• Authentication This ensures that SNMP commands are being issued by the appropriate person or application.

• Privacy Encryption enables network administrators to ensure that their SNMP commands are not being eavesdropped upon.

• Access control Different levels of access to the agent's MIB can be established for different managers. Agents can restrict access to its MIBs by either allowing read-only access or by limiting the actions that can be taken upon the MIB.

These services are delivered through a concept called a principal. This is the entity on whose behalf services are provided or processing takes place. A principal can be an individual acting in a certain role; a group of individuals, each acting in a certain role; an application or group of applications; or any combination of these.

A principal operates from a management station and issues SNMP commands to the agents. The identity of the principal and the target agent, together, determine which security features will be used. Because a principal is used, security policies can be tailored to the specific principal, agent, and information exchange, allowing flexibility to the network administrator.

Cisco ships full SNMPv3 support starting in IOS version 12.0(3)T. It is implemented for all IOS platforms that have 12.0(3)T-based images.

Cisco's SNMP and RMON Implementations

Cisco claims unparalleled SNMP and RMON capability. Virtually all the company's devices ship with SNMP agents, and most switches ship with RMON. As the internetworking industry's powerhouse, Cisco sits on the major standards-setting committees and is among the first to release products supporting new standards.

Cisco and SNMP

Cisco includes SNMP support in the form of agent software on every router and communications server it makes. According to the company, its SNMP agents can communicate successfully with OpenView and NetView. Cisco supports over 400 MIB objects. Their private MIB objects feature support for all the major LAN protocols, including IP, Novell NetWare IPX, Banyan VINES, AppleTalk, and DECnet.

Cisco uses its private MIB to enhance system monitoring and management of Cisco devices. For example, Cisco routers can be queried both by interface and by protocol. You can query for the number of runt packets on a network interface or query for the number of IPX packets sent or received from that interface. This kind of information is invaluable to baselining the traffic profile of a network. Average CPU usage statistics are sampled by five-second, one-minute, and five-minute intervals to ascertain whether a router is being properly utilized. Physical variables are also measured. Air temperature entering and leaving a device or voltage fluctuations can be monitored to assure continued device operation. Cisco's private MIB includes chassis objects to report the number of installed modules, module types, serial numbers, and so on. Figure 13-19 depicts some of Cisco's advanced SNMP features.

Figure 13-19: Cisco's SNMP implementation supports several advanced functions

To help secure SNMP messages, IOS provides the ability to prohibit them from traversing certain interfaces. SNMP is further secured by the option to designate certain community strings as read-only or read/write, thus restricting the ability to configure certain devices remotely. Also, a device can be assigned more than one community string, enabling key routers or switches to fall under multiple SNMP regimes (sometimes used in large internetworks).

Cisco has committed to making their routers "bilingual" in their simultaneous support of both SNMPv1 and SNMPv2. The coexistence strategy uses two techniques-a proxy agent that translates messages between versions, and the support of both versions in a single NMS platform.

Cisco and RMON

Cisco integrates RMON into all its platforms. The greatest RMON capabilities are packaged into the high-end Catalyst 6500, but RMON capability is built into the LightStream ATM switch line cards also.

RMONs for Catalyst Switches The Catalyst simultaneously acts as a LAN switch and a network probe because of its multiprocessor design. One CPU does the switching, and the other handles management data collection and forwarding duties. The Catalyst can be configured to collect traffic data in either of two modes:

• Standard RMON mode The RMON agent collects data for up to all nine RMON groups across all attached switch ports.

• Roving RMON mode A focused mode that collects more detailed data for just one or two RMON groups across all eight ports, and then focuses on a single LAN when an event takes place there.

In either mode, the RMON follows a structured course of action to enforce thresholds, generate events, and send alarms. Figure 13-20 depicts the structure.

Figure 13-20: This is how a standard Catalyst switch RMON works

The concurrent RMON configuration is the normal mode. Its ability to see across all connected LANs is particularly valuable for troubleshooting, especially client-server applications in which the communicating hosts are on different LANs.

Catalyst's roving RMON is as advanced as it gets. Normally, it works at collecting detailed historical information on a per-port and even per-host level. But when a trap is sent, the stripped-down, two-group RMON spawns a fully configured nine-group RMON probe that automatically begins collecting troubleshooting data just from the offending connected LAN. Figure 13-21 depicts how a roving RMON changes to handle an event.

Figure 13-21: Roving RMON marshals instrumentation to focus on an emerging problem

By the time the administrator responds to the alert, the roving RMON has already reconfigured itself and started intensive monitoring of the LAN segment in which the problem emerged.