This is what counter rollover looks like.

A friend came to me about a performance monitoring tool he was using for his routers; he was concerned that his traffic in/out graphs for his 10G linkes weren’t matching up nicely with the values he found on the interface counters. The difference was fairly large and not equal across all interfaces (which would indicate a math problem). Without actually seeing his graphs & stats, my initial reaction [1] was “counter rollover!” and pointed him here for an explanation.

Basically, if you have a link that is 100Mb or faster, you want to use ifHCInOctets and ifHCOutOctets instead of ifInOctets and ifOutOctets [2]. (The caveat, of course, is that not all interface types support the ifHC counters, not even those that should.) With reasonably steady traffic, graphs depicting counter rollover have a characteristic jagged pattern. And of course, completely incorrect data.

Get Cisco Serial Numbers with SNMP

A friend asked me how to go about doing this, and I figured I’d post it here so he can find it again if he needs it.

You’ve already discovered that snmp-server chassis-id is a user-maintained field and therefore not reliable [1], so you can skip trying to use chassisId (1.3.6.1.4.1.9.3.6.3) from OLD-CISCO-CHASSIS-MIB. It’s supposed to be depracated anyway.

Newer equipment supports the ENTITY-MIB. (For certain definitions of “support” … it’s not pretty.)

There are a number of ways to do this. The most straightforward, if you’re starting from scratch, is to walk entPhysicalClass and look for items of type 3, chassis.

It’ll look like this:
:::-->snmpwalk -v 2c -M ~/.snmp/mibs -m ENTITY-MIB -c public -O s myswitch entPhysicalClass | grep chassis
entPhysicalClass.1001 = INTEGER: chassis(3)

Then, use entPhysicalSerialNum and the iid you just found (the 1001 in the previous example) to find the serial number:
:::-->snmpget -v 2c -M ~/.snmp/mibs -m ENTITY-MIB -c public -O s myswitch entPhysicalSerialNum.1001
entPhysicalSerialNum.1001 = STRING: FOC14475A35

In case you don’t have those mibs installed & don’t want to bother with it, here are the numerical equivalents:
entPhysicalClass .1.3.6.1.2.1.47.1.1.1.1.5
entPhysicalSerialNum .1.3.6.1.2.1.47.1.1.1.1.11

That method would look like this:
:::-->snmpwalk -v 2c -c public -O s myswitch .1.3.6.1.2.1.47.1.1.1.1.5 | grep "INTEGER: 3"
mib-2.47.1.1.1.1.5.1001 = INTEGER: 3
:::-->snmpget -v 2c -c public -O s myswitch .1.3.6.1.2.1.47.1.1.1.1.11.1001
mib-2.47.1.1.1.1.11.1001 = STRING: "FOC14475A35"

Now, if you want to get fancy and maybe find out the model number as well, you can then check any of the following (in order of how useful they’ve been to me personally):
entPhysicalModelName .1.3.6.1.2.1.47.1.1.1.1.11.13
entPhysicalDescr .1.3.6.1.2.1.47.1.1.1.1.11.2
entPhysicalName .1.3.6.1.2.1.47.1.1.1.1.11.7

…which would look like this:
:::-->snmpget -v 2c -M ~/.snmp/mibs -m ENTITY-MIB -c public -O s myswitch \
entPhysicalModelName.1001 \
entPhysicalDescr.1001 \
entPhysicalName.1001
entPhysicalModelName.1001 = STRING: SM-ES3G-16-P
entPhysicalDescr.1001 = STRING: SM-ES3G-16-P
entPhysicalName.1001 = STRING: 1

—

1 – These things tend to migrate off the equipment they were originally configured on, on to other machines, via a copy & paste vector. Pretty soon you have five or six different boxes that supposedly have the same serial number.

Friday Snark – Cisco’s VTP MIB

OK, Cisco, what.is.up. with the CISCO-VTP-MIB? Let’s look at the vtpVersion OID, for starters. One would expect that it would contain, maybe, the vtp version running on the host, right?

Check this out, from the definition for that OID in the mib (available here)

"The version of VTP in use on the local system."
…so it is the VTP version…

"A device will report its version capability and not any particular version in use on the device."

…only not really. (Yes, the documentation contradicts itself. This is one of the reasons network management is so frustrating.)

Turns out you need to read further down in the MIB and use managementDomainVersionInUse (“The current version of the VTP that is in use by the designated management domain.”) to get the VTP version currently running. Right-O.

(The rest of the definition for vtpVersion states: “If the device does not support vtp, the version is none(3).” This wasn’t my experience – most of my switches (3500 and 6500 series) reported ‘none’, and were actually running v1 or v2.)