Previous | Table of Contents | Next |
Returning to our example, to complete the variable name, the suffix (or y portion) is added, which consists of an IP address: a.b.c.d. The variable name for ipAdEntBcastAddr associated with IP Address a.b.c.d would therefore be {1.3.6.1.2.1.4.20.1.4.a.b.c.d}.
Figure 4-4b is a completed IP Address Table, built by retrieving all the IP Address Table variables. The column headings show the five objects, ipAdEntAddr through ipAdEntReasmMaxSize. Each row contains the values of the five variables: ipAdEntAddr [XXX.YYY.150.2], ipAdEntIfIndex (1), and so on. A different index (2) identifies the second row, and it contains different values. Additional row entries are made, as necessary, until the table is completed.
A final example (derived from RFC 1157, section 3.2.6.3) is from the TCP Connection Table, tcpConnTable. Suppose you wish to retrieve the state of the connection between port 575 on local address {a.b.c.d} and port 441 on remote address {w.x.y.z}. The OID for tcpConnState is {1.3.6.1.2.1.6.13.1.1}. The INDEX clause consists of four parts: tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, and tcpConnRemPort. The y suffix would therefore be expressed as {a.b.c.d.575.w.x.y.z.441}. Therefore, the complete variable name would be:
{1.3.6.1.2.1.6.13.1.1.a.b.c.d.575.w.x.y.z.441}
The following examples show specific variable names for both scalar and columnar object types:
sysServices ::= {1.3.6.1.2.1.1.7.0}
ifSpeed.3 ::= {1.3.6.1.2.1.2.2.1.5.3}
atPhysAddress.2.1.a.b.c.d ::= {1.3.6.1.2.1.3.1.1.2.2.1.a.b.c.d}
ipAdEntReasmMaxSize.a.b.c.d ::= {1.3.6.1.2.1.4.20.1.5.a.b.c.d}
icmpInEchos ::= {1.3.6.1.2.1.5.8.0}
tcpConnState.a.b.c.d.e.f.g.h.i.j ::= {1.3.6.1.2.1.6.13.1.1.a.b.c.d.e.f.g.h.i.j}
udpLocalAddress.a.b.c.d.e ::= {1.3.6.1.2.1.7.5.1.1.a.b.c.d.e}
egpNeighState.a.b.c.d ::= {1.3.6.1.2.1.8.5.1.1.a.b.c.d}
snmpInBadCommNames ::= {1.3.6.1.2.1.11.4.0}
RFC 1157, pages 12-15, and RFC 1212, pages 8-10 provide other examples that are worth further study.
With this background into the methods of identifying object instances, lets now discuss the SNMP protocol data units (PDUs) that carry the requests and responses for this information between manager and agent devices. The PDUs use the object instance examples shown here to identify the specific network management information that the manager is seeking.
We will begin the discussion of PDUs by describing the position of the SNMP message within a transmitted frame. The frame is the unit of information transmitted between network nodes. For example, an IEEE 802.5 frame format defines the transmission between token ring nodes, and an ANSI T1.617 format defines the transmission between Frame Relay nodes. Chapter 6 explores the various frame formats and the supporting protocols, such as IP, UDP, and ICMP, that may also require analysis.
The local network header and trailers defined by the LAN or WAN protocol delimit the frame (see Figure 4-5). The transmitted data is called an Internet Protocol (IP) datagram. The IP datagram is a self-contained unit of information sent from the source host to its intended destination via the internetwork. Inside the datagram is a destination IP address that steers the datagram to the intended recipient. Next, the User Datagram Protocol (UDP) header identifies the higher-layer protocol process (SNMP) that will process the datagram, and provides error control using a checksum. The SNMP message is the innermost part of the frame, carrying the actual data from the manager to and from the agent.
Figure 4-5. SNMP message within a transmission frame
When the IP is too long to fit inside one frame, it may be divided (or fragmented) into several frames for transmission on the LAN. For example, a datagram containing 2500 octets would require two Ethernet frames, each of which may contain a maximum of 1500 octets of higher-layer data. The general structure of each frame, as shown in Figure 4-5, would remain the same.
The SNMP message itself is divided into two sections: a version identifier plus community name, and a PDU. The version identifier and community name are sometimes referred to as the SNMP authentication header. There are five different PDU types: GetRequest, GetNextRequest, GetResponse, SetRequest, and Trap. The Get, Set, and Response PDUs have a common format (see Figure 4-6), while the Trap PDU format is unique (Figure 4-10 later in this chapter illustrates the Trap PDU format).
Figure 4-6. The SNMP GetRequest, GetNextRequest, GetResponse, and SetRequest PDU structures
The version number (an INTEGER type) assures that both manager and agent are using the same version of the SNMP protocol. Messages between manager and agent containing different version numbers are discarded without further processing. The community name (an OCTET STRING type) authenticates the manager before allowing access to the agent. The community name, along with the managers IP address, is stored in the agents community profile. If theres a difference between the manager and agent values for the community name, the agent will send an authentication failure trap message to the manager. If both the version number and community name from the manager match the ones stored in the agent, the SNMP PDU begins processing.
Previous | Table of Contents | Next |