+1 Not knowing which policy is filtering which route has been the #1 reason for operators not wanting to touch existing policy configuration on the routers AFAIK. Hence the enormous size of policy configs. Not to mention not having an easy way to validate whether a new policy is filtering what it is intended to filter or not. If there is any visibility into why a route was filtered that can be relayed via BMP, it’d be super useful. I do agree that it should probably be another draft as Job suggested.
As for those routes that are dropped before even hitting the policy filters (such as due to errors in the path attributes like AS path loops), I think the operators need to step in here to indicate how valuable this information is to them and whether the vendors can provide them without harming the operation of the router or not. Serpil From: GROW <[email protected]> on behalf of Paolo Lucente <[email protected]> Date: Tuesday, March 20, 2018 at 11:20 AM To: Job Snijders <[email protected]> Cc: Grow Mailing List <[email protected]> Subject: Re: [GROW] Dropped Updates in BMP? Minor comment: my understanding is that Reudiger was interested in getting more visibility in what happens between Adj-RIB-In pre- and post- policy. I concur with Tim Evens comment “In order to determine what was "dropped/filtered/rejected/whatever" we do a simple diff between pre-policy and post-policy", which is essentially the same i replied to Reudiger as in what can be done with what we have. Speaking to pmacct users using BMP, the ability to diff pre- and post- policy was found good enough as a starting point to further research what happened to missing routes (through means external to BMP). It would be nice to get to some sort of increased visibility and have a kind of ‘exit code’, as Jeff Haas described it, when a route is filtered (‘f’ flag to be ported to Adj-RIB-In and Adj-RIB-Out?) and I reckon things may get complicated if trying to stretch the concept too much beyond this point. I’d be willing to contribute effort if it is found that there is enough interest. Paolo On 20 Mar 2018, at 14:52, Job Snijders <[email protected]<mailto:[email protected]>> wrote: Hi all, Reudiger Volk mentioned something interesting at the microphone yesterday about getting more visiblity into BGP UPDATES that are rejected/dropped somewhere in the policy chain transitioning from Adj-RIB-In to Loc-RIB. To make a crude route-map example: ip prefix-list allow-ebgp-in permit 192.0.2.0/24 ! route-map ebgp-in permit 10 match ip address prefix-list allow-ebgp-in ! route-map ebgp-in deny 20 bmp-log-code 21438 It would be great to see what UPDATEs get dropped in "route-map ebgp-in deny 20". It would perhaps be quite useful if we can get to the point where you can even attach custom policy-exit codes to the "Dropped Updates" send in this new BMP feed. I can see how this makes operational life easier. RFC 4271 Section 9.1: "The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-RIBs-In. The output of the Decision Process is the set of routes that will be advertised to peers; the selected routes will be stored in the local speaker's Adj-RIBs-Out, according to policy." Perhaps a series of BMP "PIB" drafts are in order? Is this worthy of a new BMP draft? Are there volunteers? Kind regards, Job _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
