The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <5.2.0.9.2.20030109104933.03e99540@bucket.cisco.com>, "Thomas D. Nad
eau" writes:
> 
> 
> >For example - It you expect a 50:50 split, its nice to poll a MIB and
> >see that the result of the hash is at least close.  It would also
> >diagnose different problems.  You may see lots of traffic on the
> >outbound interface, but if you see one of these smaller counters stop
> >incrementing then you know you have a problem.
> 
>          Yes, but this is a difficult strategy at best due to the (typically)
> large TFIBs of most production LSRs.  This is akin to watching routes
> in the IP routing database, which can be pretty big.  Scanning/polling
> this DB to look for anomalous counters is difficult performance-wise.
> 
>          --Tom


The last ISP that I worked at that *did* do fine grained consistency
checking did not use a MIB at all.  They had a Unix based router and
could access the counters more efficiently and produce consistency
checks on the router itself.

That same provider also *did* capture the routing table on all of the
routers and check it for consistency across routers.  That also was
*not* done with SNMP.  I know they did because I did it.  OTOH those
queries were run regularly only when there were under 20,000 routes.
I think we resurected it and ran it when we identified the broken MED
processing initially defined for BGP.

In case you haven't guessed that ISP was ANS and the routers were the
NSS routers that were produced as part of the NSFNET project in the
early to mid-1990s.  I think we did manage to do similar queries on
Bay and Cisco routers using show commands with infinite line counts
(using TCP instead of SNMP to gather information).  Use what works!

MIB access does create some inefficiency.  Even with a better way to
access the counters, doing the processing in a nearby pizza box
creates a bit more inefficiency due to the need to move the data.
Neither is all that hard.

Some boxes used to fall over if you do too much SNMP query.  I hope
that is no longer the case.  At least some can handle it.

Curtis