I had to come up with a way to monitor average packet size on an
interface so I wrote the following script (cisco devices). I don't know
if anyone finds it useful, but here it is if so. Also, there is one
issue with it where if the total number of packets an interface has seen
is over 7 digits, it will not calculate it. This appears to be a
limitation of the expr command used in cisco TCL and mpexpr is not
supported. If anyone else knows a way to bypass this issue I would be
glad to hear it. For now it just tells you that the value is too high.
I am also considering creating a job that can input the value into an
OID that we can poll but not exactly sure how to do that so if anyone
has any experience or good references (other than the cisco stuff I find
on google) I would be thankful.
I save this to flash: or disk: (depending on default tcl location per
device) and assign the alias:
alias exec psize tclsh psize.tcl
Then use it like:
Router#psize psize tun1
Packet Size Information for Tunnel1
Wouldn't SNMP walk/get gives you what you need?
That is a stellar TCL script!
I generally use netflow to glean information regarding average packet size.
show ip cache-flow will provide it via the CLI, or a netflow collector will
graph it statistically over time.
Chris
That is a stellar TCL script!
I generally use netflow to glean information regarding average packet size.
Seems like a good script to me. My only criticism would be pretty
hard to do anything about... you're averaging an average over a
longer period of time than the underlying data that computes the
average. dividing 5 minute average databytes approximation by 5
minute average packets approximation is probably not a very
reliable estimate for 5 minute average packet size.
Even ignoring roundoff errors, an amount of error is introduced by
averaging less precise samples, than the device should have access to
(if it could compute that rolling average itself using 1 minute or
higher resolution data)
The less stable the packet size, the more error your approximation should have.
Example of 5 minute average over 5 60-second bps divided by
pps samples...
Versus taking the two 5 minute average rates and dividing them.
60sec average after
1min 2min 3min 4min 5min | Actual 5
minute average rate
>
bps 100000 200000 300000 400000 850000 | 370000
pps 600 300 900 1000 3620 | 1284
bps/pps 166.67 666.67 333.33 400 234.80 | 360.294
BPS / PPS that would be computed by 370000 / 1284 = 288.16 bits
When 360.294 bits should be the answer, is an error of 72.134
bits (or 9 bytes out of 45 bytes),
Representing an introduced error of ~20%
It was more of a quick and dirty project and a reason for me to learn
some TCL. I wasn't aware of any way to get the value from snmp or any
cli command so I pulled the info I did have (show int) and worked with
that. As I try to improve my TCL skills, I will probably work on this.
In fact, I have already updated it somewhat but do not have the final
r2. This was basically a random fun project for me and thought some
people may find value in the (semi) finished product. Thanks to
everyone for the input though. It gives me things to try to figure out.
And I am definitely no match major so the margin of error was really the
last thing on my mind... I was just automating what one of my team was
doing manually.
As far as the comments of using netflow, I usually agree but we have the
solarwinds netflow product which I am not a fan of at all and find it
hard to get the useful data I want. Other products I have used allow
such better ability to drill in to data but solarwinds has let me down
in the netflow arena.