Previous | Table of Contents | Next |
Figure 4-12 shows an example of a TLV encoding of an SNMP PDU. Note that the entire encoding begins with a SEQUENCE OF type. The version is an INTEGER type, and the community name is an OCTET STRING type. A context-specific type then indicates the specific PDU and its length. Three INTEGER types provide the Request ID, Error Status, and Error Index. The VarBind list, consisting of multiple SEQUENCE OF encodings, completes the PDU. The following examples illustrate the details of this encoding structure.
Figure 4-12. TLV encoding of an SNMP PDU (Courtesy Network General Corp.)
To illustrate the SNMP PDUs discussed in this chapter, this section presents four examples of the protocol in use. The network analyzer captured each sample from an Ethernet backbone, which contained several other Ethernet segments connected by bridges and routers (see Figure 4-13). For these cases, the SNMP manager was a Sun workstation running SunNet Manager, and a Proteon router contained the SNMP agent. In all of these examples, the traces are filtered to show only the SNMP protocol interaction.
Figure 4-13. SNMP traps from a network analyzer
Recall from our earlier discussion that the GetRequest PDU retrieves one or more objects. Trace 4.4.1 illustrates how the UDP group (review Figure 3-8) does this.
Trace 4.4.1. Retrieving scalar data using the GetRequest PDU: The UDP Group
Sniffer Network Analyzer data 10-Nov at 11:03:08, file UDP.ENC, Pg 1 --------------------------------- Frame 61 ------------------------- SNMP: ----- Simple Network Management Protocol ----- SNMP: SNMP: Version = 0 SNMP: Community = Brutus SNMP: Command = Get request SNMP: Request ID = 0 SNMP: Error status = 0 (No error) SNMP: Error index = 0 SNMP: SNMP: Object = {1.3.6.1.2.1.1.3.0} (sysUpTime.0) SNMP: Value = NULL SNMP: SNMP: Object = {1.3.6.1.2.1.7.1.0} (udpInDatagrams.0) SNMP: Value = NULL SNMP: SNMP: Object = {1.3.6.1.2.1.7.2.0} (udpNoPorts.0) SNMP: Value = NULL SNMP: SNMP: Object = {1.3.6.1.2.1.7.3.0} (udpInErrors.0) SNMP: Value = NULL SNMP: SNMP: Object = {1.3.6.1.2.1.7.4.0} (udpOutDatagrams.0) SNMP: Value = NULL SNMP: --------------------------------- Frame 62 ------------------------ SNMP: ----- Simple Network Management Protocol ----- SNMP: SNMP: Version = 0 SNMP: Community = Brutus SNMP: Command = Get response SNMP: Request ID = 0 SNMP: Error status = 0 (No error) SNMP: Error index = 0 SNMP: SNMP: Object = {1.3.6.1.2.1.1.3.0} (sysUpTime.0) SNMP: Value = 263748621 hundredths of a second SNMP: SNMP: Object = {1.3.6.1.2.1.7.1.0} (udpInDatagrams.0) SNMP: Value = 573894 datagrams SNMP: SNMP: Object = {1.3.6.1.2.1.7.2.0} (udpNoPorts.0) SNMP: Value = 419103 datagrams SNMP: SNMP: Object = {1.3.6.1.2.1.7.3.0} (udpInErrors.0) SNMP: Value = 0 datagrams SNMP: SNMP: Object = {1.3.6.1.2.1.7.4.0} (udpOutDatagrams.0) SNMP: Value = 288892 datagrams SNMP:
Trace 4.4.1 consists of two SNMP PDUs: the GetRequest (Frame 61) and the GetResponse (Frame 62). Both frames illustrate their respective PDU structures (as described in Figures 4-6 and 4-7): Version = 0, Community = Brutus, Command (PDU Type 0 or 2), Request ID = 0, Error Status = 0, and Error Index = 0.
Next, the VarBindList indicates the variables and associated values being requested or supplied. You can observe two things here. First, the SunNet Manager always asks for the sysUpTime before requesting other objects. (Other management consoles may construct the VarBindList in another fashion.) The sysUpTime provides a time-stamp update for the Sun console, and is an input to the Sun graphical display of the network management statistics. Second, the values associated with the objects in the GetRequest have a Value = NULL. Recall that NULL is the ASN.1 type used as a placeholder in the data stream. When you look at the GetResponse in Frame 62, youll see that each NULL value has been replaced with a measured value. For example, the number of UDP datagrams that have been delivered to UDP users, udpInDatagrams {1.3.6.1.2.1.7.1.0}, has a value of 573,894 datagrams. You can interpret the rest of the VarBindList in Frame 62 in a similar manner.
The GetNextRequest PDU retrieves the lexicographical successor (or next) object, and is often used to retrieve objects from a table. Reviewing Figure 3-8, consider the UDP table, {1.3.6.1.2.7.5}. This table contains two columns, udpLocalAddress and udpLocalPort. Together, these two entries associate a local IP address with a local port number, as follows:
udpLocalAddress | udpLocalPort | ||
---|---|---|---|
0.0.0.0 | 1 | ||
a.b.c.d | 2 | ||
. | . | ||
. | . | ||
. | . | ||
Note that the address [0.0.0.0] indicates that a UDP listener is willing to accept datagrams for any interface on this node.
In Trace 4.4.2, the SunNet Manager wishes to retrieve all the values in the UDP Table. To do so, it issues the first GetNextRequest to specify OIDs that are lexicographically immediately before any udpLocalAddress objects and before udpLocalPort objects (see Frame 33). Frame 34 returns the contents of the first row, indicating a udpLocalAddress [0.0.0.0], udpLocalPort 69, the Trivial File Transfer Protocol (TFTP) port, and object {1.3.6.1.2.1.7.5.1.1.0.0.0.0.69}. [Reviewing Section 4.2.2, note that this table is indexed by the IP address (e.g. 0.0.0.0) and the local port (e.g. 69).]
The GetNextRequest in Frame 35 is identical to the one in Frame 33, except that it requests the object returned in Frame 34, that is, the next value after {1.3.6.1.2.1.7.5.1.1.0.0.0.0.69}. Frame 36 returns the response, which is the value of the second row: {1.3.6.1.2.1.7.5.1.1.0.0.0.0.161}, which identifies the SNMP port. Frames 37 continues the pattern, with the value of the third row identifying port 520 (a local routing port).
Previous | Table of Contents | Next |