David Freedman writes: > Also, whilst on the subject, have cisco come up with a way to detect > Idle as a result of maxprefix via SNMP yet?
None that I knew of. >From my reading of the BGP MIB (RFC 4273), this could/should be reflected in bgpLastError (1.3.6.1.2.1.15.3.1.14), at least on one end of the peering. bgpLastError, which dates back to 1994, is a two-octet string containing the BGP error code and subcode. Code 6 would correspond to "cease", and according to RFC 4486, the subcode for tripping max-prefixes is 1 (one). So if you have a peering that is down because of max-prefixes, check out whether its bgpLastError consists of the octets 0x06 0x01. Unfortunately, my tests between two Ciscos running 12.2(33)SRA/SRB seem to indicate that it doesn't work this way. When I deliberately kill a peering by configuring a too-small maximum-prefix, the session is closed and transitions to "idle" on both sides, but bgpLastError isn't updated on either end. Even if Cisco implemented this correctly according to my reading of the MIB, I'm not sure it would do what you want. Do you want to see this on the router where the "maximum-prefix" is configured, or on the other router (the "victim" of the prefix limit)? I think bgpLastError only provides the latter. Again, this would be useful input to the discussion of the next-generation BGP-4 MIB in the IDR working group of the IETF: https://www1.ietf.org/mailman/listinfo/idr http://www1.ietf.org/mail-archive/web/idr/current/threads.html#02341 -- Simon. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
