show amount of traffic passing throw interface

Show int (example: show int f0/1).

You are looking for txload and rxload (transmit and receive), and it will be in a number from 0 to 255. You then use that to calculate your bandwidth. As an example, if its a 100 meg ethernet interface,

126/255 would be 50 megabits. If it was a 45 meg DS3, 200/255 would be about 35.3 meg. Only other way to do it easier is to get an snmp poller to get it off the router via snmp, but it still uses the same function and just does the math for you.

Or, if your traffic is fairly stable, just take the 5 minute input and output rates given by "show int ..." - these are exponentially weighted moving averages of the traffic levels so they only approximate to the traffic level at any particular time. You can also read the input and output packet and byte counts at set times and subtract them (like an SNMP poller would). Beware that on some models the interface counts are only updated at intervals (10 sec on the 6500 I've just tried it on) so either read them frequently and look for the points at which they change, or read them infrequently so the update period doesn't matter.

Sam

Interesting. That approach seems somewhat backward to me.

If you look further on the show interface display you'll see

"5 minute input rate" and "5 minute output rate".

My testing indicates that the "5 minute input rate" and "5 minute output rate" are used as the basis for computing txload and rxload.

txload = floor ( 255 * 5 minute input rate / interface bandwidth ) rxload = floor ( 255 * 5 minute output rate / interface bandwidth )

According to Cisco: "Load on the interface (in the transmit "tx" and receive "rx" directions) as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes."

However, I need to understand what 'exponential average' means. I have used show interface tx/rxload to baseline performance, and it appears to me to be highly volatile based on almost instantaneous fluctuations in usage. What I'm saying here, is if the bandwidth on a DS3 is steady 50%, then it goes to 100%, a 5 min average should only be minimally impacted and would slowly rise to 100% over a 5 minute period (till all polling intervals showed 100%). In my experience, that definitely does not occur considering I have very recently had to implement CAR statements to protect some applications, and instantly upon turning them on, my 100% usage went to 30% which matched my CARs. So while I think there is some truth to the 5 minute average thing, it is not the same as say an MRTG, etc. Unfortunately I see a bunch of posts about this on various network sites and boards, but nothing official from Cisco other than the above on the show interfaces command documentation. Still looking though...

A couple of things.

The "Time constant" for the Exponential Weighted average can be changed with the "int x y/x ; load-interval nn" command. I pretty much always set it to 30 seconds these days. Does not affect anything other than eigrp - if you are using the "load" for the metric. mppp dialers - where the load is use to compute when to bring up the next interface. I suppose if you had thousands of interfaces on a box then there could possibly be a CPU issue

The Exponential Weighted average is computed as described here.

Basically older data is considered as less important.

If the interface has been idle and the traffic is 0%, then the traffic is suddenly increased to 100% and maintaned at that level it take about 10 minutes for the displayed load to reach 100% at the default 5 min setting.

5 mins is a parameter fed into the maths. It does not mean that data older than 5 mins is not considered. Theoretically ALL data is considered but very old data has so little weight that its effects cannot be seen.

As I implied above data older than about 20 minutes cannot be seen on the /'255 scale.

Just as a guess, I would imagine it means that more recent values [within the five minute window] have an exponentially greater weighting when calculating the average. So whilst it's an average over five minutes, it reacts quicker to changes in network usage than an unweighted one.

here.http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_...>

that should read "it take about 20 minutes for the displayed load to" (not 10)

typosRus

There is one obvious implementation strategy and very few good alternatives...

Say you want a 5 minute weighted average receive rate...

You poll the interface every few seconds and compute:

newrunningaverage = oldrunningaverage * (loadinterval - pollinterval)/loadinterval + (bytesreceived - lastsavedbytesreceived) / loadinterval

And indeed, Cisco documentation indicates that this is supposed to occur.

After four polling intervals you're supposed to end up within 2% of the correct figures for an interface under steady load conditions.

2% ~= 1/e^4

1/e ~= ((loadinterval - pollinterval)/loadinterval) ** (loadinterval/pollinterval)

as long as pollinterval is small relative to loadinterval.

Sounds like Cisco might have reset the weighted average. That would be a reasonable thing to do in some circumstances. And pretty easy to implement.

Leaving implementation details undocumented is often a wise move.

...

Understanding the Definition of bits per second (bits/sec) from the show interfaces Command Output