The Simple Network Management Protocol (SNMP) and the Management Information Bases (MIBs) it uses are important for troubleshooting your network. These sections provide information about:
SNMP which is one of the most widely used management protocols, allows management communication between network devices and your management workstation across TCP/IP internets.
Most management applications, including Status Watch and Address Tracker applications, require SNMP to perform their management functions.
SNMP communication requires a manager (the station that is managing network devices) and an agent (the software in the devices that communicates with the management station). SNMP provides the language and the rules that the manager and agent use to communicate.
Managers can discover agents:
For agents to discover their managers, you must provide the agents with the IP addresses of the management stations.
Managers send requests to agents (either to send information or to set a parameter), and agents provide the requested data or set the parameter. Agents can also notify the managers independently through unsolicited trap messages, which indicate that certain events have occurred.
SNMP supports queries (called messages) that allow the protocol to transmit information between the managers and the agents. Types of SNMP messages:
MIBs define what can be monitored and controlled within a device (that is, what the manager can Get and Set). An agent can implement one or more groups from one or more MIBs. See "SNMP MIBs" for more information.
Traps are unsolicited, asynchronous events that devices generate to indicate status changes. Every agent supports some trap reporting. You must configure trap reporting at the devices so that these events are reported to your management station to be used by the "Network Management Platforms" (such as HP OpenView Network Node Manager) and the "Transcend Applications".
Not all traps are important for your management tasks. To decrease the burden on the management station and on your network, you can limit the number and type of traps reported to the management station.
MIBs are not required to document traps. SNMP supports the limited number of traps defined in Table 26. More traps may be defined in vendors' private MIBs.
To minimize SNMP traffic on your network, you can implement trap-based polling. Trap-based polling allows the management station to start polling only when it receives certain traps. Your management applications must support trap-based polling for you to take advantage of this feature.
SNMP uses community strings as a form of management security. To enable management communication, the manager must use the same community strings that are configured on the agent. You can define both read and read/write community strings.
Because community strings are included unencoded in the header of a User Datagram Protocol (UDP) packet, packet capture tools can easily access this information. Similar to what you do with any password, change the community strings frequently.
See "SNMP Community Strings" for more information.
SNMP MIBs include MIB-II, other standard MIBs (such as the RMON MIB), and vendors' private MIBs (such as enterprise MIBs from 3Com). These MIBs and their objects are part of the MIB tree.
The MIB tree is a structure that groups MIB objects in a hierarchy and uses an abstract syntax notation to define manageable objects. Each item on the tree is assigned a number (shown in parentheses after each item), which creates the path to objects in the MIB. See Figure 18. This path of numbers is called the object identifier (OID). Each object is uniquely and unambiguously identified by the path of numeric values.
When you perform an SNMP Get operation, the manager sends the OID to the agent, which in turn determines whether the OID is supported. If the OID is supported, the agent returns information about the object.
For example, to retrieve an object from the RMON MIB, the software uses this OID:
1.3.6.1.2.1.16
iso(1).indent-org(3).dod(6).internet(1).mgmt(2).mib(1).RMON(16)
Figure 18 MIB Tree Showing Key SNMP MIBs
MIB-II defines various groups of manageable objects that contain device statistics as well as information about the device, device status, and the number and status of interfaces.
The MIB-II data is collected from network devices using SNMP. This data collects in its raw form. To be useful, data must be interpreted by a management application, such as Status Watch.
MIB-II, the only MIB that has reached Internet Engineering Task Force (IETF) standard status, is the one MIB that all SNMP agents are likely to support.
Table 27 lists the MIB-II object groups. The number in parentheses indicates the group's branch in the MIB subtree.
MIB-I supports groups 1 through 8; MIB-II supports groups 1 through 8, plus two additional groups.
RMON is an SNMP MIB that enables the collection of data about the network itself, rather than about devices on the network.
A typical RMON system consists of two components:
The IETF definition for the RMON MIB specifies several groups of information. These groups are described in Table 28.
RMON and RMON2 are complementary MIBs. The RMON2 MIB extends the capability of the original RMON MIB to include protocols above the MAC level. Because network-layer protocols (such as IP) are included, a probe can monitor traffic through routers attached to the local subnetwork.
Use RMON2 data to identify traffic patterns and slow applications. The RMON2 probe can monitor:
Because it includes higher-layer protocols (such as those at the application level), an RMON2 probe can provide a detailed breakdown of traffic by application.
Table 29 lists the additional MIB groups that are available with RMON2.
3Com Enterprise MIBs allow you to manage unique and advanced functionality of 3Com devices. MIB names and numbers are usually retained when organizations restructure their businesses; therefore, many of the 3Com Enterprise MIB names do not contain the word "3Com." Figure 18 shows some of the 3Com Enterprise MIB names and numbers.