i came across a situation which gets me to ask about a detail of RPL logic which is deceiving me.
Im mostly running asr9k with 5.1.3 or 5.2.4 in the lab although I doubt my query is platform specific
So, If I apply RPL inbound on a BGP session upstream from where I receive a number of prefixes including default, how does XR/RPL handle the following ?
if destination in (18.104.22.168/24) and destination in (22.214.171.124/24) then
does the above even make sense logically, as in does the RPL examine one prefix at a time in the BGP feed ? If so 126.96.36.199/24 can never be 188.8.131.52/24, unless the RPL says I will accept 184.108.40.206/24 since I also have 220.127.116.11/24 being advertised to me via BGP from this same peer ?
Quick test in the lab actually accepts 18.104.22.168/24 and installs it in FIB, so Im a little bit confused about the logic, since even if the parser allowed commit for something seeming illogical, XR is also generally a normally closed, deny all approach, as opposed to IOS, so I would have expected not to see prefix in FIB, but Im clearly missing something
RPL should be parsed a route element at a time, of the 25k routes you might get from a peer, they should never interact with one another in the RPL. I think that if you have just the RPL above you have posted and the route 22.214.171.124/24 gets entered into the RIB, I think that is an error/bug. I don't see anything wrong particularly with your RPL, because there's nothing wrong with calling out different prefix-sets in different locations. I.e., RPL towards peer A, use prefix-set 1 and 2, RPL towards peer B, use prefix-set 2 and 3. Obviously using two prefix-sets that have no intersecting elements in an AND match is a little bit absurd and unlikely to appear in real life, but that's irrelevant to how it should behave.
thanks for your feedback Aaron
I was trying to build some logic around "accept prefix (1) if prefix (2) is present"
I agree that this would make no sense if the RPL is processed prefix at at time from the BGP peer, which was my suspicion, but was worth a shot, especially since prefix was accepted in the lab !
You might look into some other elements though - like 'rib-has-route' would enable the RPL to look through the entire rib as an AND condition to look for a route, but I don't know of a way to constrain that element to routes from a certain peer only.