Re: [GROW] current state of BMP implementations?
https://code.google.com/p/bmpreceiver/ Tested against the JUNOS draft -01 sender implementation. Stephen On Tue, Nov 5, 2013 at 2:21 PM, John Kemp wrote: > On 11/5/13 11:07 AM, Jeffrey Haas wrote: > > On Tue, Nov 05, 2013 at 09:32:16AM -0800, John Kemp wrote: > >> Can anyone summarize the current state > >> of the Juniper or Quagga work on BMP? > > BMPv1 support has been available in JUNOS for a while now. > > BMPv3 support will be in 13.3. > > > > -- Jeff > > Anyone publish any client station code? > > John Kemp > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-bmp-06.txt
On Thu, Dec 1, 2011 at 7:55 AM, Robert Raszuk wrote: > Hello John, > > As we have previously discussed on and off list the current BMP draft does > not meet customer's requirements in the space of BMP monitoring. As discussed, it does not meet some customers' requirements. It does meet others, such as mine. > It almost adds no value in comparison with sending full BGP table without > any outbound policy by add-paths option ALL so in that light it is just a > duplication of different ways to accomplish the same. I feel that it does add value in that my receiver application in the BMP case does not need to be a BGP protocol speaker with risk of impact to the control plane. > In particular it regenerates updated as stored in Adj_RIB_In which > automatically means that any errors or even order of attributes your peer is > sending will not be seen at the management station. This is not relevant in my case. > I asked to add new optional type called "Session Monitoring" which would > allow to encapsulate and reply to management station raw PDUs however it > seems from the below -05 to -06 delta that my suggestion has been ignored. It wasn't ignored. It was discussed, and as the proposal grew to try to encompass error cases and include timestamps, and the lack of clarity around potential for duplication of the same information between the proposed optional type and existing required types, I preferred to recognize the progress we have made and address new requirements - which I recognize are reasonable for *some* use cases beyond mine - in a new draft. Stephen > I think we have a chance to deliver something much more useful and > meaningful to customers without compromising or putting at risk existing > implementations. > > Please kindly reconsider. > > Best regards, > R. > >> Folks, >> >> Changes between -05 and -06 are: >> >> - Added "Lifecycle of a BMP Session" section. It seemed as though people >> really needed a little more context as to the expected sequence. >> >> - Changed Message Length to 4 bytes. (See >> draft-ietf-idr-bgp-extended-messages-01 for some context as to why this >> seemed like a good idea.) >> >> - Changed Initiation Message string encoding from ASCII to UTF-8. >> >> - Specified that Version 0 is reserved. >> >> Regards, >> >> --John >> >> On Dec 1, 2011, at 10:14 AM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Global Routing Operations >>> Working Group of the IETF. >>> >>> Title : BGP Monitoring Protocol >>> Author(s) : John Scudder >>> Rex Fernando >>> Stephen Stuart >>> Filename : draft-ietf-grow-bmp-06.txt >>> Pages : 17 >>> Date : 2011-12-01 >>> >>> This document proposes a simple protocol, BMP, which can be used to >>> monitor BGP sessions. 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. The design goals are >>> to keep BMP simple, useful, easily implemented, and minimally >>> service-affecting. BMP is not suitable for use as a routing >>> protocol. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-06.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-bmp-06.txt >>> >>> ___ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> >> > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Fri, Dec 17, 2010 at 1:02 AM, Robert Raszuk wrote: > Hi Stephen, > > Many thx for your reply. > >>> Unfortunately version -01 and above moved away from this and >>> simplified the requirement to reply/send content of Adj_RIB_In >>> instead of those coming updates from the peers. >> >> It allowed an implementation to reconstruct updates, rather than >> replicate them. > > Update "reconstruction" to me means to take what is already in Adj_RIB_In, > place it into the bmp wrapper and send over bmp session. In fact spec is > pretty clear to say this is normal, local, update generation essentially per > peer. > > Few points: > > * What is in Adj_RIB_In is already the product or result past the BGP IO > processing therefor any issues there will not be visible, > > * The information about update format received from the peer is lost - > example you will not be able to say if MP_(UN)REACH_NLRI were first in the > update msg nor what was for example the packing ratio That level of protocol debugging was not a requirement for BMP, and isn't of interest for the family of applications that I'm trying to enable. Note that an implementation of BMP is free to replicate updates as received rather than generate them, and (arguably) it would bad from a software complexity standpoint to implement both. If you'd like to explore this further in, say, IOS, I would be happy to do the work on the receiver to bring it up to draft -04 and test with you. > * Many address families (example VPNv4) drop uninteresting routes when non > intersecting RT is found hence they will not be in Adj_RIB_In .. I would not > expect that for BMP reasons routers now will store all VPN routes > permanently > > * You loose information about update frequency, inter-update gaps, churn > > * You report only accumulated number of invalidate routes without listing > those NLRIs .. > > I think those are enough of reasons to consider adding a new option to bmp > to actually allow to wrap received TCP strems from each peer like Tony has > proposed in a bmp header and send it to the observatory linux station. In > this case non of the above drawback would occur. > > Moreover such wrapping and sending does not need to happen inline .. it is > very easy to buffer in RAM or in HDD copy of incoming streams for their push > to linux box when CPU has spare cycles to do so. > > Also it needs to be noticed that such option would not require to increase > amount of permanent resource use by the bgp speaker. While Adj_RIB_In would > need to be kept, keeping above described TCP streams is only a transient > resource usage. > > The timestamp in BMP header in this case may actually reflect the true > reception of such stream to the router allowing for much broader use case. > > And again I am not saying that current message types should be removed from > the spec. I am just proposing to add one more and let the implementer and > operator choose which one makes most sense for them. As above, that's orthogonal to the type of application that I need to enable, but if you want to prototype something I'm happy to help on the receiver side. How soon do you think you can have an implementation ready? Thanks, Stephen >>> So we are effectively loosing the most crucial part of the original >>> proposal as we no longer be able to pass to some observatory linux >>> station those prefixes which were dropped on inbound or worse any >>> potential malformed updates or attributes if they were not stored >>> in the RIB_In. >> >> I disagree. The most crucial part of the proposal is to get the >> contents of Adj_RIB_In from the router to a monitoring station, >> without the filter of best path selection that occurs when you use >> BGP peering as a means to monitor what the router sees (and >> bgp-add-paths doesn't accomplish this, either). The corner cases of >> malformed updates and filtered updates simply aren't interesting for >> the application that this protocol was designed to enable - >> centralized analysis of the whole of an autonomous system's >> Adj_RIB_In. >> >>> I think it defeats a lot of use cases. Perhaps this subtle >>> difference should be discussed more before we proceed any further >>> with this document. >> >> This was discussed before, if I recall correctly. BMP is proposed to >> do one job well, and that's to get the collected Adj_RIB_In out, >> globally, to where it can be processed by real computers. >> >> Stephen >> > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Fri, Dec 17, 2010 at 3:01 PM, john heasley wrote: > Thu, Dec 16, 2010 at 09:07:11PM -0800, Stephen Stuart: >> I'm not sure what you're advocating to be configurable. Loc_RIB isn't >> interesting, you can get that by BGP-peering with the router if you're >> content to have the data obscured by best path selection. I'm not >> interested in turning BMP into a protocol for debugging malformed BGP >> updates, syslog already does that adequately. BMP is meant to do one >> job: allow a real computer to reproduce the Adj_RIB_In of a router, in >> a way that protects the router against conditions such as a bad >> receiver implementation or congestion loss between the speaker and the >> receiver. > > I'm suggesting that BMP can do both as it is defined now; and which is > exported could be user configurable on exporting device. As noted, Loc_RIB can already be collected by peering with the device as a regular BGP peer. I would argue that introducing malformed updates runs the risk of introducing instability into a BMP receiver that may potentially cause it to lose state for a large Adj_RIB_In for no good cause, where the router will have (hopefully) just dumped the single BGP peer that sent the malformed update - and logging of the malformed update by the router using an existing mechanism like syslog is sufficient for what ought to be a rare event in the field. So, yes, BMP could do both, but there's no reason to add functionality to BMP to do jobs that are already done quite sufficiently by other mechanisms. Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Thu, Dec 16, 2010 at 6:38 PM, john heasley wrote: > Thu, Dec 16, 2010 at 06:27:54PM -0800, John Scudder: >> On Dec 16, 2010, at 8:08 PM, Stephen Stuart wrote: >> >> I think it defeats a lot of use cases. Perhaps this subtle difference >> >> should >> >> be discussed more before we proceed any further with this document. >> > >> > This was discussed before, if I recall correctly. >> >> That's correct. In fact because of the divergence between -00 and -01, I >> took pains to make this clear when presenting -01, including at NANOG and >> GROW and probably other places. Those interested in the history should be >> able to find the slides easily enough. > > why does this matter? sure, adj-rib-in is MUST, but can that not be > configurable which is (are) exported? I'm not sure what you're advocating to be configurable. Loc_RIB isn't interesting, you can get that by BGP-peering with the router if you're content to have the data obscured by best path selection. I'm not interested in turning BMP into a protocol for debugging malformed BGP updates, syslog already does that adequately. BMP is meant to do one job: allow a real computer to reproduce the Adj_RIB_In of a router, in a way that protects the router against conditions such as a bad receiver implementation or congestion loss between the speaker and the receiver. Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
On Wed, Dec 15, 2010 at 3:26 PM, Robert Raszuk wrote: > John at all, > >> Title : BGP Monitoring Protocol >> Author(s) : J. Scudder, et al. >> Filename : draft-ietf-grow-bmp-05.txt >> Pages : 16 >> Date : 2010-12-15 > > If I remember correctly the fundamental reason for bmp was to provide a very > simple mechanism for replaying content of received updates from the peers as > well as provide some form of signaling reg their state transition. That goal > was great. > > Unfortunately version -01 and above moved away from this and simplified the > requirement to reply/send content of Adj_RIB_In instead of those coming > updates from the peers. It allowed an implementation to reconstruct updates, rather than replicate them. > So we are effectively loosing the most crucial part of the original proposal > as we no longer be able to pass to some observatory linux station those > prefixes which were dropped on inbound or worse any potential malformed > updates or attributes if they were not stored in the RIB_In. I disagree. The most crucial part of the proposal is to get the contents of Adj_RIB_In from the router to a monitoring station, without the filter of best path selection that occurs when you use BGP peering as a means to monitor what the router sees (and bgp-add-paths doesn't accomplish this, either). The corner cases of malformed updates and filtered updates simply aren't interesting for the application that this protocol was designed to enable - centralized analysis of the whole of an autonomous system's Adj_RIB_In. > I think it defeats a lot of use cases. Perhaps this subtle difference should > be discussed more before we proceed any further with this document. This was discussed before, if I recall correctly. BMP is proposed to do one job well, and that's to get the collected Adj_RIB_In out, globally, to where it can be processed by real computers. Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] BMP draft -01 receiver implementation
There's a receiver implementation for BMP as specified in draft-ietf-grow-bmp-01.txt available at http://code.google.com/p/bmpreceiver/ (click on the source tab, not the downloads tab). Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-scudder-bmp-01
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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-scudder-bmp-01
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. > unfortunately, so while it may be in the MIB that does not mean that a BMP > client has a prayer of ever access that mib! > > So, yes, it would be useful to have this data inband within the BMP feed. As noted previously, SR messages can signal the existence of a peer, and the monitoring application can use that information to determine that a peer exists which has not supplied updates. Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-scudder-bmp-01
On Wed, Nov 19, 2008 at 10:19 AM, Stephen Stuart <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 18, 2008 at 9:09 PM, Shane Amante <[EMAIL PROTECTED]> wrote:
>> Hi John,
>>
>> On Nov 12, 2008, at 5:16 PM, John G. Scudder wrote:
>>>
>>> GROW folks,
>>>
>>> I'll be presenting draft-scudder-bmp-01 ("BGP Monitoring Protocol") at the
>>> meeting in Minneapolis. Long-time GROW fans may remember that the WG
>>> requested to make the -00 version a WG document way back in 2005. It turned
>>> out that there were some major implementation hurdles with the draft as
>>> written and it became moribund and never did get issued as draft-ietf-grow.
>>>
>>> Fast forward to present, there's been significant renewed interest so
>>> we've dusted off the draft and modified the mechanism to make it more
>>> implementor-friendly. I'm hoping that the WG would still, after the long
>>> hiatus, like to adopt the draft.
>>
>> I'm glad to see this draft has been resuscitated and I do support its
>> adoption.
>>
>> A few questions:
>> 1) The draft says the following in Section 2:
>> ---snip---
>> If the peer is a "Global Instance Peer", this field is zero filled. If the
>> peer is a "L3VPN Instance Peer", it is set to the route distinguisher of the
>> particular L3VPN instance that the peer belongs to.
>> ---snip---
>> I'm a little confused by the second sentence. Is that referring to the case
>> where a router is doing RFC 4364 "Option A" style eBGP with a remote peer,
>> or something else?
>>
>> 2) In Section 3, the draft talks about sources of routing information
>> (Adj-RIB-In or Loc-RIB) sent in Route Monitoring messages. Would it be
>> useful to have a bit in the BMP "Peer Flags" that indicates if the path
>> being sent in a RM message was retrieved pre- (Adj-RIB-In) or post-
>> (Loc-RIB) policies, so the receiver knows which he/she is looking at?
>
> The "L" flag described in section 2.1 conveys that information?
Sorry, I forgot that we took that out.
Stephen
>> 3) How will BMP cope with BGP flap dampening being enabled on a BMP source
>> router? In other words, a router (configured as a BMP source) receives a
>> series of WITHDRAW's & UPDATE's that it is configured to apply flap
>> dampening on, suppressing re-advertisement of these updates further into an
>> AS. If the BMP source is forwarding messages from Adj-RIB-In, would a BMP
>> receiver see all incoming WITHDRAW's & UPDATE's associated with a "flap"
>> event, (even though these updates would have been suppressed from further
>> re-advertisement after flap dampening is applied)? How would, or should, a
>> BMP receiver know that flap dampening is enabled and/or would be applied?
>>The reason I ask is perhaps this is more a question of the 'authenticity'
>> of "monitoring data" at a BMP receiver with respect to formulating what did
>> (or could) have happened with a series of Updates being propagated further
>> within an AS? Or, perhaps there's another answer?
>>
>> -shane
>>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-scudder-bmp-01
On Tue, Nov 18, 2008 at 9:09 PM, Shane Amante <[EMAIL PROTECTED]> wrote:
> Hi John,
>
> On Nov 12, 2008, at 5:16 PM, John G. Scudder wrote:
>>
>> GROW folks,
>>
>> I'll be presenting draft-scudder-bmp-01 ("BGP Monitoring Protocol") at the
>> meeting in Minneapolis. Long-time GROW fans may remember that the WG
>> requested to make the -00 version a WG document way back in 2005. It turned
>> out that there were some major implementation hurdles with the draft as
>> written and it became moribund and never did get issued as draft-ietf-grow.
>>
>> Fast forward to present, there's been significant renewed interest so
>> we've dusted off the draft and modified the mechanism to make it more
>> implementor-friendly. I'm hoping that the WG would still, after the long
>> hiatus, like to adopt the draft.
>
> I'm glad to see this draft has been resuscitated and I do support its
> adoption.
>
> A few questions:
> 1) The draft says the following in Section 2:
> ---snip---
> If the peer is a "Global Instance Peer", this field is zero filled. If the
> peer is a "L3VPN Instance Peer", it is set to the route distinguisher of the
> particular L3VPN instance that the peer belongs to.
> ---snip---
> I'm a little confused by the second sentence. Is that referring to the case
> where a router is doing RFC 4364 "Option A" style eBGP with a remote peer,
> or something else?
>
> 2) In Section 3, the draft talks about sources of routing information
> (Adj-RIB-In or Loc-RIB) sent in Route Monitoring messages. Would it be
> useful to have a bit in the BMP "Peer Flags" that indicates if the path
> being sent in a RM message was retrieved pre- (Adj-RIB-In) or post-
> (Loc-RIB) policies, so the receiver knows which he/she is looking at?
The "L" flag described in section 2.1 conveys that information?
Stephen
> 3) How will BMP cope with BGP flap dampening being enabled on a BMP source
> router? In other words, a router (configured as a BMP source) receives a
> series of WITHDRAW's & UPDATE's that it is configured to apply flap
> dampening on, suppressing re-advertisement of these updates further into an
> AS. If the BMP source is forwarding messages from Adj-RIB-In, would a BMP
> receiver see all incoming WITHDRAW's & UPDATE's associated with a "flap"
> event, (even though these updates would have been suppressed from further
> re-advertisement after flap dampening is applied)? How would, or should, a
> BMP receiver know that flap dampening is enabled and/or would be applied?
>The reason I ask is perhaps this is more a question of the 'authenticity'
> of "monitoring data" at a BMP receiver with respect to formulating what did
> (or could) have happened with a series of Updates being propagated further
> within an AS? Or, perhaps there's another answer?
>
> -shane
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-scudder-bmp-01
On Wed, Nov 19, 2008 at 8:28 AM, Erik Romijn <[EMAIL PROTECTED]> wrote: > Hi all, > > John G. Scudder wrote: >> >> Fast forward to present, there's been significant renewed interest so >> we've dusted off the draft and modified the mechanism to make it more >> implementor-friendly. I'm hoping that the WG would still, after the long >> hiatus, like to adopt the draft. > > Having been thinking myself about a similar custom system from time to time, > this looks very useful to me. > > Briefly reading through the draft, I do notice that there is no way to > detect the existence of a peer if it sends no prefixes (except when the > session goes down). An implementation could send SR messages (section 2.2) to convey such information. > 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. Stephen ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
