Re: BGP MIBv2 implementations
Simon Leinen <simon <at> limmat.switch.ch>
2007-04-28 11:23:56 GMT
More than a month ago, Susan Hares wrote:
> If anyone has implemented any portion of the BGP MIBv2, would you please
> send mail to the mail list
[It's a pity that no vendors responded, because obviously parts of BGP
MIB v2 have been implemented. So this is just another response from
an operator. Sorry for the late response.]
> Indicating:
> 1) What you've implemented
Our vendor has recently (for our platform) implemented a
vendor-specific BGP4 MIB that implements certain aspects of
bgp4-mibv2.
In particular, this <vendor>-BGP4-MIB.my implements peer-specific and
peer/AFI/SAFI-specific counters/gauges of accepted/denied
etc. prefixes.
What the vendor did not do is support non-IPv4 addresses in the index
part of these tables. While the agent tries to represent IPv6
peerings in some of them, this fails because it tries to index the
peerings with the first 32 bits of the peer's IPv6 address. While
this happens to disambiguate eBGP peerings in the case that all peer
addresses are from the peer ISP's address space, it collapses many
peerings into one entry for the common cases of (a) multiple peers at
an exchange point and (b) iBGP peerings, where the peer addresses are
all from our own /32.
This is what the vendor implemented; we recently (because the software
for our platform only got this feature few months ago) implemented
periodic polling and graphing of "accepted prefixes per peer"
statistics. Although this variable is marked as a "Counter32" in the
vendor MIB, in reality it seems to be a Gauge32, just like
bgpM2PrefixInPrefixesAccepted and bgpM2PrefixInPrefixesAccepted in
bgp4-mibv2.
> 2) What's useful.
Plotting the number of accepted prefixes from a peer is useful for us
because of the following:
* Long-term, we can get a (very rough) idea of how a peering evolves.
This is useful e.g. to adapt prefix-limits, or as a first indication
that a peering may have outlived its usefulness.
* Short-term, we can get a quick idea of the effects of filter
updates.
One nice thing our vendor does is that it makes prefix limits
("max-prefixes") readily available in the MIB.
I looked at using "rejected prefixes" counters as well, but couldn't
find a useful application. Those seem to be REAL counters, i.e. I
could only plot rates, not absolute numbers. And I'm not interested
in the rate of rejection, only in the (temporal evolution of) the
number of prefixes that we reject from a given peer (in a given
address family). Such a variable seems to be missing from both the
vendor's MIB and the bgp4-mibv2 proposal. Implementing it would
probably require something similar to "soft-reconfig inbound", but
it would certainly be useful where this is done anyway.
--
--
Simon.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
RSS Feed