[c-nsp] How to monitor BGP sessions

[Simon Leinen]

Gert Doering writes:
> I wonder how this looks like if you have multiple IPv6 neighbours
> starting with the same 32 bits - 32.1.21.24 is just decimal for
> 2001:1518: - so what happens if you have another neighbor,
> 2001:1518:0:3001::2 (or so)?

Does nobody here run iBGP over IPv6? Multiple IPv6 neighbors in the
same /32 are mangled into one MIB row.  An example follows.  Note that
the first row in the output corresponds to 38 iBGP peerings with
neighbor addresses from the same /32 (2001:620::/32).

: leinen at smirnov[super_opt]; snmptable -v 2c -c hctiws -Ci -Cb ce2 cbgpPeerAddrFamilyPrefixTable
SNMP table: CISCO-BGP4-MIB::cbgpPeerAddrFamilyPrefixTable

                        index [...] AdvertisedPrefixes [...]
       32.1.6.32.ipv6.unicast [...]              10140 [...]
      32.1.7.152.ipv6.unicast [...]                121 [...]
      32.1.7.248.ipv6.unicast [...]              40697 [...]
[...]

I have no idea how the counters in this row are synthesized - maybe
the counters from the last peering in the mangle-bundle overwrite all
others.

Cisco implements a variant of a subset of the draft BGP-4 "v2" MIB
that the IDR (Inter-Domain Routing) working group in the IETF has
tried to standardize for a couple of years.  The IETF proposal as it
currently stands includes decent multi-protocol support - Cisco just
did a half-assed variant of that which truncates IPv6 peer addresses
to IPv4 addresses (why didn't they at least use the BOTTOM 32 bits? :-)

If you find SNMP monitoring of BGP peerings important, please send
your input to the IETF IDR mailing list:

https://www1.ietf.org/mailman/listinfo/idr

The discussion so far can be found in the archive:

http://www1.ietf.org/mail-archive/web/idr/current/threads.html#02341

It has stalled a few weeks ago, but I would say there is latent
interest in getting the BGP-4 "v2" MIB effort off the ground again, so
your participation could have a big effort.

Tell us what you want to see in this MIB!

Otherwise we'll remain stuck with the old ("v1") MIB in RFC 4273,
which is almost unchanged from RFC 1657.  Since that MIB is from 1994,
it doesn't know about things like IPv6, multicast, or "address
families" in general.
-- 
Simon.