I would like too see some information, commonly obtained through "show bgp summary" in SR messages: MsgRcvd/MsgSent: useful to find verbose neighbours. PfxRcd: useful to produce an alarm reaching some threshold InQ/OutQ: useful to...
-- Pedro On Wed, Nov 19, 2008 at 10:11 PM, Pedro Torres <[EMAIL PROTECTED]> wrote: > I would like too see some information, commonly obtained through > "show bgp summary" in SR messages: > MsgRcvd/MsgSent: useful to find verbose neighbours. > PfxRcd: useful to produce an alarm reaching some threshold > InQ/OutQ: useful to... > > -- > Pedro > > > > On Wed, Nov 19, 2008 at 6:04 PM, Stephen Stuart <[EMAIL PROTECTED]> wrote: >> On Wed, Nov 19, 2008 at 11:58 AM, Geoff Huston <[EMAIL PROTECTED]> wrote: >>> >>> On 20/11/2008, at 6:51 AM, Stephen Stuart wrote: >>> >>>> On Wed, Nov 19, 2008 at 11:40 AM, Geoff Huston <[EMAIL PROTECTED]> wrote: >>>>> >>>>> On 20/11/2008, at 5:16 AM, Stephen Stuart wrote: >>>>>>> >>>>>>> This should probably not be a common case, but we do see it from time >>>>>>> to >>>>>>> time. It would be useful for us to be able to have this data. >>>>>> >>>>>> Data regarding the state of configured peers are already available by >>>>>> other means (the BGP 4 MIB described in RFC1657); correlating with >>>>>> that data tells us that a peer has supplied no updates >>>>>> (BGP4-MIB::bgpPeerInUpdates.A.B.C.D). If the update count is non-zero >>>>>> and there are still no BMP messages indicating that the peer supplied >>>>>> a prefix, then it's likely attributable to "state changes in the >>>>>> interim" for that prefix. >>>>> >>>>> having access to a feed of BGP data for research purposes and SNMP access >>>>> to >>>>> the bgp speaker's MIB are invariably two entirely different concepts, >>>> >>>> On the other hand, an application built to use a feed of BGP data for >>>> decision support almost certainly has other sources of operational >>>> data, such as BGP MIB data, readily available. At least that's the >>>> case for me. >>> >>> true, but my comment is motivated by the text in the draft's abstract which >>> states: >>> >>> "BMP is intended to provide a more convenient interface for obtaining route >>> views for research purpose than the screen-scraping approach in common use >>> today". >>> And if the intent is to serve the BPG feed leeches (such as myself!) then >>> SNMP access is not a given. >> >> Agreed. >> >> Do SR messages suffice? Would you prefer to see some of the >> information from the bgpPeerTable replicated in SR messages? >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
