I +1 that this is covered by post-policy, but there are some caveats. In order to determine what was "dropped/filtered/rejected/whatever" we do a simple diff between pre-policy and post-policy. Caveat is that this requires the BMP sender implementation to support both pre & post policy at the same time. Currently JunOS supports this, but others do not. For BMP senders that do not implement both pre & post for the same neighbor/peer, we have to glean the post-policy by other means.
I've run into a few support issues with folks that have been comparing Adj-RIB-In pre-policy to what the router shows via CLI (e.g. bgp sum counts). They understand the idea of post-policy but they were confused when they saw different counts on peers that had no filters/policy applied. I explained to them that it was likely rejected prefixes, not filtered. They were still unsure and wanted to have a better understanding why there are so many rejected prefixes. BMP includes stat counters, such as duplicates, invalidate due to ... I was able to show "quickly" via these counters that if you subtract the invalidated/duplicate counts from the total, you get the number of RIB entries shown in CLI. In this case, the issue for them was AS Path loops. I was able to provide them a query to show the pre-policy prefixes that were rejected by the router due to AS Path loop. In the above example, they didn't have post-policy turned on so we couldn't easily do a diff. Had they had post-policy we could do a diff instead of querying for the specific entries that were rejected (known via the stat counters). Even with pre/post diffs and bmp stat counters, we still don't have a reject/filter reason associated per route/prefix. Instead, we have to "determine" the reason based on the diff. I also had discussions with users regarding how they are only interested in the diff output of pre/post and not the post RIB itself. I believe there is value in possibly adding a new Adj-RIB-In-PostDiff table/conveyance, which would contain ONLY the NLRI's that are filtered/rejected. If we had this table, we could add flags or something similar to indicate the reason the NLRI is in the diff table, such as rejected due to AS Path loop. This might get a bit complicated though. Thanks, Tim On 3/20/18, 7:14 AM, "GROW on behalf of Jeffrey Haas" <[email protected] on behalf of [email protected]> wrote: Job, On Tue, Mar 20, 2018 at 01:52:23PM +0000, Job Snijders 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. The "exit code" is fairly reasonable. The "dropped updates" can be problematic depending on what you meant. If you meant that the routes were discarded and not kept as inactive, implementations may need mirror mode support since the route would not be stored in the RIB. Routes that are simply rejected but stored in the rib (e.g. "keep all" in JunOS) can be reported as part of post-policy monitor mode. > > 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? PIB docs were mostly left out of scope except as a general abstraction to talk about in the BGP standardization effort because no one can agree on The One True Policy Engine. See similar conversation occurring right now in the rtgwg policy yang model. > Is this worthy of a new BMP draft? Are there volunteers? I'd suggest keeping the scope to the bmp-log-code. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
