[nsp] Counting bps...

[Iva Cabric]

On Mon, Mar 17, 2003 at 03:19:53PM +0100, Gert Doering wrote:
> Lucky you :-) - various IOS releases have very interesting misbehaviour
> in various parts of the whole counter mess.
> 
> One of the most spectactular ones is in early 12.0S, where you can
> have "5 minute output" values well over a Gbit/s. on a FastEthernet
> interface.

The test was on 12.2(13), probably more stable on counter issues than
12.0S.

On Tue, Mar 18, 2003 at 09:20:32AM +0100, Gert Doering wrote:
> I just want to point out that it is NOT fixed in 12.0(23).  Grrr.  They have
> just managed to make it a lot less easy to reproduce.
> 
> (I have this Cat5500 RSM that usually managed to get a hanging counter on
> one or two VLAN interfaces in a week or so.  I had a TAC case open, and
> finally we ended up with 12.0(23), which was supposed to fix it.  It
> seemed to, but now, after "30 weeks, 6 days, 11 hours, 10 minutes", 
> one of the interface counters got stuck again).

So, the real issue when choosing which counters to use is not
flexibility (32 vs 64 bits, octets vs bps (no need for averaging and
rollovers) or L2 vs IP) but their usability.

> So whatever you do with whichever counters you use - don't use them for
> anything that brings money without sanity checks.

Last week, people from Cisco were trying to convince me, that Catalyst
3550 is definitely the way to go for limiting and accounting (at least
on Fastethernet).


On Tue, Mar 18, 2003 at 01:32:46AM +0200, Volodymyr Yakovenko wrote:
> >
> > IF-MIB::ifInOctets.XXX
> > IF-MIB::ifOutOctets.XXX
> 
> .iso.org.dod.internet.mgmt.mib-2.interfaces (.1.3.6.1.2.1.2)
> 
> > IF-MIB::ifHCInOctets.XXX
> > IF-MIB::ifHCOutOctets.XXX
> 
> .iso.org.dod.internet.mgmt.mib-2.ifMIB (.1.3.6.1.2.1.31)
> 
> This output could be confused, small correction - ifInOctets (SMIv1 ifTable)
> and ifHCInOctets (SMIv2 ifXEntry) reside in different MIBs. However in net-snmp
> they are grouped in one file (IF-MIB.txt).

You are right about that, thanks for correction:)

> According to Cisco's documentation on conventional routing architectures
> byte and packet counters are updated on per packet basis.

Ok, but under heavier CPU loads, are byte and packet counters consistent
with real values (because of process priorities), or they have some lag?