Cisco Get Current Interface Throughput

cisco

I can graph a device interface with SNMP tools, platforms like Cacti even make pretty graphs, but these are based on polling intervals (typically, every 5 minutes).

I can use the CLI;

r1>show int gi0/0
GigabitEthernet0/0 is up, line protocol is up 
Hardware is BCM1250 Internal MAC, address is 0011.2233.4455 (bia 0011.2233.4455)
Description: link 1
MTU 1540 bytes, BW 1000000 Kbit, DLY 10 usec, 
   reliability 255/255, txload 35/255, rxload 20/255
Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/3208/72484 (size/max/drops/flushes); Total output drops: 1373910311
Queueing strategy: Class-based queueing
Output queue: 0/1000/12 (size/max total/drops)
5 minute input rate 79658000 bits/sec, 19312 packets/sec
5 minute output rate 140174000 bits/sec, 21984 packets/sec

I can see from the 5 minute output rate I'm transmitting 140Mbps of traffic, but that's averaged over the last five minutes. So not right now, and no better than Cacti et all.

I could enter the interface command load-interval 30 to bring down the sampling rate to 30 seconds, at which point the txload and rxload values become more accurate.

Again though, if I need to find out which link is maxed out right now, I find it difficult to believe that for all the amazing things Cisco routers and switches can do, they can't tell me current tx/rx rate for an interface, right now.

I understand a sampling period maybe required for such a figure to be attainable, what's wrong with 1 second? Surely the CPU demand isn't that much, just counting the number of packets that pass every second and their size?

Has someone perhaps developed their own way of working this out? I see others haunted by the same conundrum?

UPDATE: I should have given better context to this, so I will try and do so now.

A typical need for me to know an interface throughput right now, is when a customer who has a 100Mbps port rings up and says "Hey, I'm download X from your mirror server but its only transferring at 20Mbps". I want to be able to see their switch pot throughput right now, whilst they're on the phone to me, to confirm this (non-tech customers often report incorrect values in my experience).

So, in this scenario I can confirm whether the customer port is already receiving 100Mbps so they only get 20Mbps because their port is at capacity, or if they are even transferring at anything like the speed they are claiming (whether it be above or below). Also, next I will want to see the throughput of the router that switch is terminated on for all those customers, this is another potential bottleneck. Also, I can check the switch port of the mirror server whilst the transfer is in progress.

I don't want to respond to the customer with "OK, well make sure you continue to download for another 5 minutes so I can wait for $NMS_OF_CHOICE to poll the interfaces", not an acceptable answer in the customers eyes. I can give many more scenarios, but essentialy, complaining customers is top priority 🙂

Best Answer

I'm not a switch designer, so so in terms of what the cost would be to monitor at this frequency I can't say.

What I can say, is that I have run into the situation where even a second isn't always enough because you can overun the buffers in periods shorter than a second. So if you want to know if a link is maxed out, I recommend looking at the dropped packets (You can monitor this via SNMP as well). If you are dropping packets (a few here there is okay, but a lot is not good) then you are demanding more than the interface can handle. This can also happen on your servers before they even hit the switch. The precise rate of dropped packets generally isn't important, but if they keep increasing each show interface you are likely in a bad place.

In terms of Cacti, that is not a limit of the switch or SNMP. SNMP records the bits sent and received as an increasing counter, so if you poll every second, you will get per second resolution. The way it works is the time stamp of each sample is taken along with the current count. It then takes the difference and expresses it in units of "per second" but in reality is is really a per 5 minute rate converted or expressed as per second.

If you try polling SNMP every second though, you better watch your CPU.

Related Topic