Have you ever gone into an access closet, with the intention of cabling another workstation, only to find that all of the access ports are already cabled but that a significant number of them are not lit? It can be frustrating. Is the port dark because there's nothing on the other end or is the port dark because the node on the other end is powered down. Well, this can be deteremined via SNMP (with one caveat). I've created automation for this using SNMP command line and simple batch commands. This is included as an attachment. Here's a brief description of the process. First, I'll begin with the SNMP OID that's used for this process.
The first thing you need to do is grab the time from 1.3.6.1.2.1.1.3. Here's a description from Cisco's website:
| Object | sysUpTime |
| OID | 1.3.6.1.2.1.1.3 |
| Type | TimeTicks |
| Permission | read-only |
| Status | current |
| MIB | SNMPv2-MIB ; - View Supporting Images  |
| Description | "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." |
Once you have that information, you can collect information from 1.3.6.1.2.1.2.2.1.2, 1.3.6.1.2.1.2.2.1.2.8, and 1.3.6.1.2.1.2.2.1.2.9 (ifDesc, ifOperStatus and ifLastChange respectively). ifDesc is pretty obvious and ifOperStatus is the current state of the interface:
1 : up
2 : down
3 : testing
4 : unknown
5 : dormant
6 : notPresent
7 : lowerLayerDown
The bread and butter of this process, though, is ifLastChange and this can be confusing so I'll explain this in a little more detail. The value is an unsigned 32-bit number that does NOT represent the number of time ticks that the port has been in its current state. The reason for this is that it would be a lot of unnecessary work for the device to constantly update this data as time passes. Instead, everytime the operational state of a port changes the device records the current time (1.3.6.1.2.1.1.3) in a table. Therefore, in order to make sense of the ifLastChange value you need to subtract the value from 1.3.6.1.2.1.1.3. Now for the caveat. The value stored in 1.3.6.1.2.1.1.3 will roll when it hits the top end of an unsigned 32-bit value. The exact time is 497 days, 2 hours, 27 minutes and 52 seconds. Therefore, if the switch is up for longer than that period of time you'll start getting strange results (negative values). This isn't terrible, though, because you can still make some safe assumptions about the port state. For example, suppose that the value of 1.3.6.1.2.1.1.3 has rolled and is now very low (1,000,000). Let's say that the value stored in the table for interface Fa0/23 is 3,292,111,120. The top value is 4,294,967,295. That minus 3,292,111,120 is 1,002,856,175. Then you have to add the 1,000,000 (from the 1.3.6.1.2.1.1.3) and that brings you to 1,003,856,175. Divide that by 100 (because this is all in 1/100 of seconds) and you get 10,038,561. Divide that by 86,400 and you know that the port has been in its current state for a little over 116 days (assuming that the value of 1.3.6.1.2.1.1.3 has only rolled once).
Now for a brief description of the batch process. The process requires SNMP coommand line tools from net-snmp.org (which need to be in the path), the batch file attached to this document and a simple text file with a list of switches, one per line, that you wish to interrogate. I have included logic in the script that allows you to specify a single device as a parameter at the commandline. If you run the batch job without a parameter it will use the switches.txt file otherwise it will use the parameter you pass. In my environment, I have a scheduled process which creates a CSV file containing the interface states for all access switches. That information is then converted to HTML and posted on a website where I can look at it via a browser.