Original LinkIf you have ever tried to read the throughput value of an ethernet interface in and out using SNMP you may notice that it’s quite easy to get a nice trend graph using your favorite plotting tool (MRTG, zabbix,…) but when you try to get the actual throughput value the amount just never seems to be correct.
During this article I’ll try to explain how the Cisco IfInOctets and IfOutOctets work and what you need to do to get the right value.
1) What is the IfInOctets and IfOutOctets value:
The first thing you need to know is that a Cisco router holds it’s interface value in two tables IfTable and IfXTable, these are fully described in RFC1213/RFC2233.
- ifTable defines 32-bit counters for inbound and outbound octets
-ifXTable provides similar 64-bit counters, also called high capacity (HC) counters
The values we are interested in are IfInOctest, IfHCInOctest, IfOutOctest and IfHCOutOctests. For the sake of this article we will focus on the In values but know that the exact same logic also holds for the Out counters. So lets have a look at the two in Counters. Let’s have a look at what the Cisco documentation tell’s us about these two counters:
- IfInOctets: "The total number of octets received on the interface,
including framing characters. The reference OID is: 1.3.6.1.2.1.2.2.1.10
Lets query this value of interface eth0 of a CentOS Linux Server and see the result:
[root@buildbox55-64bit Perl]# snmpwalk -Os -c public -v2c 192.168.1.230 .1.3.6.1.2.1.2.2.1.10.2
ifInOctets.2 = Counter32: 77043026
- IfHCInOctets: "The total number of octets received on the interface,
including framing characters. This object is a 64-bit
version of ifInOctets. The reference OID is: 1.3.6.1.2.1.31.1.1.1.6
Lets query this value of interface eth0 of a CentOS Linux Server and see the result:
[root@buildbox55-64bit Perl]# snmpwalk -Os -c public -v2c localhost 1.3.6.1.2.1.31.1.1.1.6.2
ifHCInOctets.2 = Counter64: 78219248
As you can read, both values actually return the same data “Total number of octest received”, but we are faced with a first dilemma, you have two counters to poll, each returning a different absolute value and in some bizarre way both are giving you the Total number of octets received.
- IfInOctets 1.3.6.1.2.1.2.2.1.10
For us to understand this we need to know what the value is that is being returned. SNMP is a very basic protocol that runs on just about any network device,… The core idea behind SNMP is simplicity, generic usable and low footprint. To ensure the low footprint SNMP has very little to no intelligence built in. It just returns values you would like to monitor and relies on your toolset to harvest this data en make it usable for you.
The counter we are reading returns the amount of octets received since
- the boot of the device
- since the last rollover period
There are two concepts here that we need to explain be for the puzzle will start to fall together for you:
1) # of octets received => that means if you want to know the data throughput you will have to read the counter twice at time_slot1_value and then lets say 1 second later at time_slot2_value. To know the throughput of octets now subtract
time_slot2_value – time_slot1_value = total # of octets send
2) since the last rollover => as you can imagine the amount of octet bytes sent is just an increasing value and this number can grow really really fast. And this is where the 32bit / 64bit values come into play. In the old days with slow speed networks a 32bit value was used to store the # of octets send, once this 32bit value fill’s to it’s maximum the counter resets to Null and restarts it’s count until it reaches the maximum value again. As you can imagine on a slow speed network this 32bit value fill’s up quite gradually and rollover does not occur all that often. However on a high speed gigabit network a lot of packets are passing through the interface and a 32bit value in memory fill’s up much faster. The net problem with roll over is that at a certain point in time you will subtract time_slot1_value from time_slot2_value but time_slot2_value will be smaller than time_slot1_value thus giving you a negative net value. This is alright for trend,… analysis as long as it does not happen to often.
To give you an idea of how fast this rollover occurs:
- a 10 Mbps stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes.
- At 100 Mbps, the minimum wrap time is 5.7 minutes
- At 1 Gbps, the minimum is 34 seconds.
=> this means the 32bit value is just not good enough for modern high speed networks and you will almost always ant to resort back to the 64bit ifHCInOctets counter value.
To follow Cisco documenation: “
For interfaces that operate at 20,000,000 (20 million) bits per second or less, you must use 32-bit byte and packet counters. For interfaces that operate faster than 20 million bits per second, and slower than 650,000,000 bits per second, you must use 32-bit packet counters and 64-bit octet counters. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet and octet counters must be used.
Correspondingly, Cisco IOS® Software does not support 64-bit counters for interface speeds of less than 20 Mbps. This means that 64-bit counters are not supported on 10 Mb Ethernet ports, only 100 Mb Fast-Ethernet and other high speed ports support 64-bit counters. “
3) Converting Octets to bits is the last part we need to understand if we want to know the bits per tick that pass through our network interface. To convert the amount of transmitted octets on the Ethernet network to bits we must multiply by 8.
The ending formula to know the #of bits being transferred between two ticks would thus be:
Value2-Value1 * 8 = # bits transferred
