2.2 What SNMP Can Help You Do
| Protocol design aside, the practical power of SNMP lies in device information available to be retrieved and changed. Fortunately there is a great deal of device configuration available via SNMP. This section looks at some of the standard variables available on networked devices. 2.2.1 The System GroupThe system group is a direct child of mib-2 that contains variables related to general information about the device. RFC 1213 defines seven simple variables in this group, listed in Figure 2.4. The # column in this table designates the part of the object identifier appended to mib-2 for the given variable. The RW column indicates whether the variable can be set with an SNMP set-request . Figure 2.4. Variables in the System Group.
The function of most variables is clear. The sysObjectID variable returns an SNMP object ID that is unique to that particular kind of device. This object ID is designated by the vendor and therefore always starts with .1.3.6.1.4.1 , which is the prefix for private enterprises . The sysServices variable designates which layers of network service are provided by the device. Its use requires some explanation. From RFC 1213: [3]
The value is a sum. This sum initially takes the value zero. Then, for each layer, L, in the range 1 through 7 that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs primarily routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly : layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., IP gateways) 4 end-to-end (e.g., IP hosts ) 7 applications (e.g., mail relays) For systems including OSI protocols, layers 5 and 6 may also be counted. Example values of the system group from a real device look like this: system.sysDescr.0 = "Asante IntraSwitch 5324MT" system.sysObjectID.0 = OID: enterprises.298.2.2.15 system.sysUpTime.0 = Timeticks: (186442210) 21 days, 13:53:42.10 system.sysContact.0 = "admins@example.com" system.sysName.0 = "switch.example.com" system.sysLocation.0 = "5-125T" system.sysServices.0 = 10 The variables sysContact , sysName , and sysLocation are set by an operator using either SNMP or a separate management interface to the device. Notice that the sysObjectID variable points to an object ID under enterprises.298 , which is assigned to Asante. The sysServices value is 10, indicating that layer 2 and layer 4 services are available. On this device, an Ethernet switch, the layer 2 service is packet switching and the layer 4 service is the IP functionality the device uses for management. 2.2.2 The Interfaces GroupThe interfaces group is another direct child of mib-2 . It contains variables related to information about individual interfaces on a piece of network hardware. A workstation or other simple network device with one network connection may have only one or two interfaces. A switch or router may have many. The interfaces group has only one simple variable, ifNumber , which is the number of interfaces available on the system. An example from a router: interfaces.ifNumber.0 = 91 and from a workstation: interfaces.ifNumber.0 = 2 In this case, the workstation has two interfaces, one physical network interface, and one loopback interface. The only other variable defined for the interfaces group is the table ifTable . The columns of this table are listed in Figure 2.5. Most of these are self-explanatory. One thing worth noting is that it is not always easy to relate the interface index number to the port number on a device. Sometimes the index number will be the same as the port number, such that when ifIndex is three, it will refer to port three on the device. Sometimes this is not the case, particularly on devices that have multiple boards and number each port as a board/port pair. There is no standard mechanism for making the conversion. Cisco devices, for example, use a simple formula to convert the board/port to an ifIndex number and vice versa. Extreme products use a similar formula but with different values so that port one on board one is ifIndex 1001, port two on board one is 1002, and port one on board two is 2001. Some devices provide the ability to use a separate SNMP lookup in the private enterprises portion of the MIB to perform the conversion. Figure 2.5. Variables in IfTable .
The interfaces group does not report current interface bandwidth usage. Originally the RFC called for ifSpeed to do just that, but in practice, it is always used to report the maximum speed possible on the link. On switches capable of supporting multiple link speeds, the value is usually set to the speed of the current link, in bits per second, or zero if no link is present. In order to gather statistics on current interface bandwidth use, it is necessary to retrieve a byte count, such as ifInOctets , wait a designated period of time, retrieve a second byte count, and then subtract the difference and divide by the elapsed time. For example, we retrieve: interfaces.ifTable.ifEntry.ifInOctets.6 = 4109645530 and then exactly 10 seconds later retrieve: interfaces.ifTable.ifEntry.ifInOctets.6 = 4109669635 The average bandwidth use at this time is The ifType variable uses an integer to represent the protocol spoken by the interface. The value for Ethernet is 6, while PPP's is 23. The full table of supported values is listed in RFC 1213. 2.2.3 ip.ipNetToMediaTableThe ip.ipNetToMediaTable is used to translate IP addresses to hardware addresses. In the context of Ethernet, this means looking up the Ethernet address associated with a particular IP address in the device's Address Resolution Protocol (ARP) cache. An older method of doing this involved using the at group, which while usually still supported, is not as generic as the newer system. The ip.ipNetToMediaTable is shown in Figure 2.6. To show how this table would be used, sample data from a router follows . In order to save space, the variable names have been shortened ; each variable name would begin with the prefix ip.ipNetToMediaTable.ipNetToMediaEntry . ipNetToMediaPhysAddress.4.10.152.0.44 = 0:0:1d:dc:85:2d ipNetToMediaPhysAddress.4.10.152.0.45 = 0:e0:63:2b:c9:c0 ipNetToMediaPhysAddress.4.10.152.0.46 = 0:e0:63:2b:ca:f8 ipNetToMediaPhysAddress.4.10.152.0.53 = 8:0:20:9e:f1:80 ipNetToMediaPhysAddress.4.10.152.0.54 = 8:0:69:2:e6:ec ipNetToMediaPhysAddress.4.10.152.0.60 = 8:0:20:93:da:3f ipNetToMediaPhysAddress.4.10.152.0.61 = 0:5:2:f6:c7:b ipNetToMediaPhysAddress.4.10.152.0.62 = 0:1:e6:4f:9a:6a Figure 2.6. The ip.ipNetToMediaTable .
In reading the first line of output, we learn that the IP address 10.152.0.44 has a cached Ethernet address of 0:0:1d:dc:85:2d . There are a couple of important things to note. First is that before the IP address, there is an interface index number. In this example, every address shown is on interface four. When making a query to determine the hardware address of a particular IP address, we'll need to know the interface it's on so that we can supply that part of the variable name. In practice, there are two ways to do this. One is to determine first which is the correct interface via some other SNMP query. On a router we might look up which interface we would route the packet to and assume that is the correct interface to use in looking up the hardware address. An easier, though brute-force, solution is to simply perform the lookup for every interface number on the device. Also note that lookups can be performed only in the IP address to hardware address direction. If you wish to map a hardware address to an IP address, you must either retrieve the entire table until you find the hardware address you are looking for or hope that the vendor supplies a private MIB that allows reverse lookups, which most do not. 2.2.4 The Bridge MIBThe variable group starting with dot1dBridge is better known as the bridge MIB and is defined by RFC 1493. It is a direct child of mib-2 , though it is not defined in RFC 1213. As expected, the bridge MIB contains information relevant to switching and bridging. [4] One table from the bridge MIB that is worthy of special mention is the forwarding database table, depicted in Figure 2.7. This table is indexed by physical address. For a particular address, dot1dTpFdbPort will return the port number to which the bridge will forward packets for that address. If that port and address mapping is learned dynamically by the bridge, dot1dTpFdbStatus is set to 3. Other values for dot1dTpFdbStatus indicate the port mapping was made differently. For example, a value of 4 indicates the address belongs to the bridge itself and is therefore statically configured.
Figure 2.7. The dot1dTpFdbTable .
Sample output of dot1dTpFdbTable follows. The variable names have again been shortened; each variable name would begin with dot1dBridge.dot1dTp.dot1dTpFdbTable. dot1dTpFdbEntry.dot1dTpFdbPort.8.0.9.50.98.244 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.9.231.93.192 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.5.9.147 = 7 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.125.167.158 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.138.134.127 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.143.66.1 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.147.187.7 = 13 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.154.38.212 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.160.9.193 = 1 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.164.117.198 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.178.66.134 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.32.231.127.52 = 12 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.43.28.153.246 = 25 dot1dTpFdbEntry.dot1dTpFdbPort.8.0.105.11.122.33 = 25 Be aware that the hardware addresses are shown here in decimal notation. The first line indicates that the hardware address 08:00:09:32:62:f4 (the hexadecimal version of 8.0.9.50.98.244 ) is found behind port 25. This table is immensely useful because it allows an operator to ask a switch which port a particular host is on. This is a vital tool for diagnosing and solving network problems. Neo, a network administration tool introduced in Chapter 4, provides a simple interface to perform these lookups.  |
Bytes/s. 
EAN: 2147483647
Pages: 85