cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
232
Views
0
Helpful
3
Replies
Highlighted

The 'AND' Logic in RPL ?

Hi,

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 (1.0.0.0/24) and destination in (2.0.0.0/24) then
pass

does the above even make sense logically, as in does the RPL examine one prefix at a time in the BGP feed ?  If so 1.0.0.0/24 can never be 2.0.0.0/24, unless the RPL says I will accept 1.0.0.0/24 since I also have 2.0.0.0/24 being advertised to me via BGP from this same peer ?

Quick test in the lab actually accepts 1.0.0.0/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

cheers

Mark

3 REPLIES 3

RPL should be parsed a route

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 1.0.0.0/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

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 !

thanks

Mark

You might look into some

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.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards