on 01-20-2012 10:47 AM
In this document I'll discuss the operation, use and some examples on RPL, or the route policy language.
Route policies are mandatory for E-BGP peers, at least a "pass-all" like RPL is required in order to import and export routes.
In IOS we used to have route-maps to control the import, export and manipulation of routes. IOS-XR doesn't have route-maps but something more powerful called route policy language. It is a very programmatic approach in route-maps.
Where as IOS route-maps operate as a series of statements which are executed sequentially, Route-policies not only operate sequentially but provide the ability to invoke other route-policies much like a ‘C’-program is able to call separately defined functions. This enables to creation of hierarchical policies. In addition, and most importantly into respect the scope of this paper, route-policies are ‘compiled’ into a run-time executable portion of code.
When you have configured a route policy that you want to edit afterwards, you need to restart from scratch or copy paste the existing RPL as entering the route-policy configuration would wipe the existing one out:
RP/0/RSP0/CPU0:A9K-BNG(config)#route-policy test
RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#if med eq 100 then
RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#set local-preference 100
RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#endif
RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#end-policy
RP/0/RSP0/CPU0:A9K-BNG(config)#commit
RP/0/RSP0/CPU0:A9K-BNG(config)#
RP/0/RSP0/CPU0:A9K-BNG(config)#route-policy test
Fri Jan 20 14:58:39.900 EDT
% WARNING: Policy object route-policy test' exists! Reconfiguring it via CLI wil
l replace current definition. Use 'abort to cancel.
RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#
RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#if local-preference eq 123 then
RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#set origin incomplete
RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#endif
RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#end-policy
RP/0/RSP0/CPU0:A9K-BNG(config)#commit
RP/0/RSP0/CPU0:A9K-BNG(config)#do sh run route-policy test
Fri Jan 20 14:59:53.705 EDT
route-policy test
if local-preference eq 123 then
set origin incomplete
endif
end-policy
!
As you can see the previous if statement is completely gone, copy pasting and offline editing are also not very easy to use! There is a solution!
RP/0/RSP0/CPU0:A9K-BNG#edit route-policy test ?
emacs to use Emacs editor
nano to use nano editor
vim to use Vim editor
<cr>
I tend to prefer VI and then you can edit your RPL in a VI like manner:
Editting screen:
route-policy test
if local-preference eq 123 then
set origin incomplete
else if med eq 100 then
set weight 44
endif
end-policy
!
~
~
I am inserting the bold italic lines and press "ZZ" to exit and save the VI editor. (Note I made a config error in RED)
~
~
"/dev/shmem/rpl_edit.115790135" 8 lines, 149 characters written
Proceed with commit (yes/no/cancel)? [cancel]:
Now the config error here by splitting "else if" and look what happens when I try to commit:
Parsing.
149 bytes parsed in 1 sec (148)bytes/sec
% Syntax/Authorization errors in one or more commands.!! SYNTAX/AUTHORIZATION ER
RORS: This configuration failed due to
!! one or more of the following reasons:
!! - the entered commands do not exist,
!! - the entered commands have errors in their syntax,
!! - the software packages containing the commands are not active,
!! - the current user is not a member of a task-group that has
!! permissions to use the commands.
else if med eq 100 then
set weight 44
endif
end-policy
Continue editing? [no]:yes
"/dev/shmem/rpl_edit.115790135" 8 lines, 145 characters written
Proceed with commit (yes/no/cancel)? [cancel]: yes
Parsing.
145 bytes parsed in 1 sec (144)bytes/sec
Committing.
Prepared commit in 0 sec
1 items committed in 1 sec (0)items/sec
Updating.RP/0/RSP0/CPU0:Jan 20 15:04:20.101 : config[65848]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'root'. Use 'show configuration commit changes 1000000522' to view the changes.
Updated Commit database in 1 sec
RP/0/RSP0/CPU0:A9K-BNG#
So from now one when you want to edit RPL's, prefix sets or as-sets or community sets, use this editor
RP/0/RSP0/CPU0:A9K-BNG#edit ?
as-path-set edit an as-path-set
community-set edit a community-set
extcommunity-set edit an extended-community-set
policy-global edit policy-global definitions
prefix-set edit a prefix-set
rd-set edit a rd-set
route-policy edit a route-policy
The route policy requires a "ticket" for the route to be accepted or dropped. These are the different operatators
pass grants a ticket to defeat default drop
Execution continues after pass
Any set at any level grants a ticket
Execution continues after set
Values can be set more than once
• Drop – prefix is discarded
Explicit drop stops policy execution
Implicit drop (if policy runs to end without getting a ticket)
One thing important to add is here that if you have a policy that is "sequential" like
if med 10 then
set med 20
endif
if med 20 then
drop
endif
the execution will NOT drop prefixes with MED10. The reason for that is, although somewhat counter intuitive, that the sequence of operation uses the ORIGINAL value during processing, hence the second if statement will not match for the what was original med of 10...
If you like to get the behavior that both 10 and 20 are dropped, you could do something like this:
if med 10 then drop
else if med 20 then drop
else pass
endif
Don't forget the final pass, as there is an implicit deny.
The ability to reference one policy in another
route-policy one
set weight 100
end-policy
route-policy two
set med 200
end-policy
route-policy three
apply two
set community (2:666) additive
end-policy
route-policy four
apply one
apply three
pass
end-policy
The ability to call one policy with a variable to be used in another policy:
route-policy one ($med)
set med $med
end-policy
route-policy two
apply one (10)
end-policy
Or with 2 variables:
route-policy three ($med,$origin)
set med $med
set origin $origin
end-policy
route-policy four
apply three (10, incomplete)
end-policy
In your RPL you can put the prefix set or as-path etc in the IF statement construction or you can reference a separate set with the AS-list.
They look like the following:
Inline:
route-policy use_inline
if as-path in (ios-regex '_42$', ios-regex '_127$') then
pass
else
drop
endif
end-policy
Named-Set:
as-path-set named_set
ios-regex '_42$',
ios-regex '_127$'
end-set
route-policy use_named
if as-path in named_set then
pass
else
drop
endif
end-policy
There is a performance difference between teh two. the Named Set is obviously slightly slower, but is easier to manage especially when the list gets long. I would personally recommend for short lists to use inline and for longer lists to use the named-set.
Each individual set element results in a separate call to the expression engine:
as-path-set as_51
ios-regex ‘_2129$’,
ios-regex ‘_2147$’,
ios-regex ‘_2856$’,
ios-regex ‘_3486$’,
ios-regex ‘_6432$’,
ios-regex ‘_6468$’,
ios-regex ‘_7310$’,
ios-regex ‘_7768$’,
ios-regex ‘_7862$’,
ios-regex ‘_8296$’
end-set
The same set can be written as follows:
as-path-set as_51
ios-regex '_(2129|2147|2856|3486|6432|6468|7310|7768|7862|8296)$'
end-set
as-path-set aset1
ios-regex ’_42$’,
ios-regex ’_127$’
end-set
prefix-set galaga
171.68.118.0/24,
192.168.0.0/16 ge 16 le 30
end-set
community-set cset1
12:34,
12:78,
internet
end-set
internet
local-AS
no-advertise
no-export
private-as
show bgp policy route-policy <name>
Only display prefixes matching policy – filter show command
RP/0/0/CPU0:XR#show rpl route-policy states
ACTIVE -- Referenced by at least one policy which is attached
INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced
Here some examples of using prefix-sets. The use of the variable masks is not easy to understand and I found the CCO documentation not very explanatory, so here a few extra words on that.
Prefix: Explanation:
10.0.1.1, match only one possible value, 10.0.1.1/32, mask omitted means 32.
10.0.2.0/24, match only one possible value, 10.0.2.0/24
10.0.3.0/24 ge 28, match a range of prefix values, from 10.0.3.0/28 to 10.0.3.255/32
10.0.4.0/24 le 28, match a range of values, from 10.0.4.0 to 10.0.4.240 (eg we can’t “reach” the last 4 bits)
10.0.5.0/24 ge 26 le 30, matches prefixes in the range from 10.0.5.0/26 to 10.0.5.252/30
10.0.6.0/24 eq 28 match any prefix of length 28 in the range from 10.0.6.0/28 through 10.0.6.240/28
10.0.7.2/32 ge 16 le 24, matches any prefix of length 32 in the range 10.0.[0..255].2/32 (from 10.0.0.2/32 to 10.0.255.2). This is a little funky given the “7” in the 3rd octet which effectively becomes don’t care.
10.0.8.0/26 ge 8 le 16 matches any prefix of length 26 in the range 10.[0..255].8.0/26 (from 10.0.8.0/26 to 10.255.8.0/26)
I am using an RPL that sets the local pref to 1234 if it matches the prefix set, and that prefix set is as per the above sample list.
10.0.3.0/24 ge 28, match a range of prefix values, from 10.0.3.0/28 to 10.0.3.255/32
=> What is excluded here ? Is 10.0.3.128 excluded from the prefix range ?
Whether the .128 is excluded or not, depends on the mask of the prefix being advertised.
Basically what this means is that if the mask of the route is larger or equal than 28 (so 29,30,31,32) then it matches:
Network Next Hop Metric LocPrf Weight Path
*>i10.0.3.0/28 8.1.1.1 100 1234 0 2 3 {4} i
*>i10.0.3.16/28 8.1.1.1 100 1234 0 2 {3,4} i
*>i10.0.3.32/28 8.1.1.1 100 1234 0 2 3 {4,5} i
*>i10.0.3.48/28 8.1.1.1 100 1234 0 2 i
*>i10.0.3.0/26 8.1.1.1 100 300 0 2 3 {4} i
*>i10.0.3.64/26 8.1.1.1 100 300 0 2 {3,4} i
*>i10.0.3.2/31 8.1.1.1 100 1234 0 2 {3,4} i
*>i10.0.3.4/31 8.1.1.1 100 1234 0 2 3 {4,5} i
*>i10.0.3.6/31 8.1.1.1 100 1234 0 2 i
*>i10.0.3.0/24 8.1.1.1 100 300 0 2 3 {4} i
10.0.4.0/24 le 28, match a range of values, from 10.0.4.0 to 10.0.4.240 (eg we can’t “reach” the last 4 bits)
=> What is excluded here ? 10.0.4.1, .2, .3, .17, .18,.19,.20, etc?
Same as before, but now where the mask is less than 28, so routes in the 10.0.4.x range that have a mask that is shorter 28 will get “hit”.
The mask on the prefix itself sets the “base”. Eg 10.0.3 would not match here as it is not part of the 10.0.4.0/24. Seems obvious but just to be clear ...
Network Next Hop Metric LocPrf Weight Path
*>i10.0.4.0/24 8.1.1.1 100 1234 0 2 3 {4} i
*>i10.0.4.0/26 8.1.1.1 100 1234 0 2 3 {4} i
*>i10.0.4.64/26 8.1.1.1 100 1234 0 2 {3,4} i
*>i10.0.4.128/26 8.1.1.1 100 1234 0 2 3 {4,5} i
*>i10.0.4.48/28 8.1.1.1 100 1234 0 2 i
*>i10.0.4.64/28 8.1.1.1 100 1234 0 2 3 {4,5} i
*>i10.0.4.24/30 8.1.1.1 100 300 0 2 3 i
*>i10.0.4.28/30 8.1.1.1 100 300 0 2 {3} i
10.0.5.0/24 ge 26 le 30, matches prefixes in the range from 10.0.5.0/26 to 10.0.5.252/30
Combining the previous two together on the .5.0 range:
*>i10.0.5.4/30 8.1.1.1 100 1234 0 2 {3,4} i
*>i10.0.5.8/30 8.1.1.1 100 1234 0 2 3 {4,5} i
*>i10.0.5.12/30 8.1.1.1 100 1234 0 2 i
*>i10.0.5.4/31 8.1.1.1 100 300 0 2 3 {4,5} i
*>i10.0.5.6/31 8.1.1.1 100 300 0 2 i
*>i10.0.5.5/32 8.1.1.1 100 300 0 2 3 {4,5,6} i
*>i10.0.5.6/32 8.1.1.1 100 300 0 2 3 i
*>i10.0.5.0/25 8.1.1.1 100 300 0 2 3 {4} i
*>i10.0.5.128/25 8.1.1.1 100 300 0 2 {3,4} i
*>i10.0.5.64/26 8.1.1.1 100 1234 0 2 {3,4} i
*>i10.0.5.128/26 8.1.1.1 100 1234 0 2 3 {4,5} i
10.0.7.2/32 ge 16 le 24, matches any prefix of length 32 in the range 10.0.[0..255].2/32 (from 10.0.0.2/32 to 10.0.255.2). This is a little funky given the “7” in the 3rd octet which effectively becomes don’t care.
*>i10.0.7.2/32 8.1.1.1 100 1234 0 2 3 {4} i
*>i10.0.7.3/32 8.1.1.1 100 300 0 2 {3,4} i
*>i10.0.0.2/32 8.1.1.1 100 1234 0 2 3 {4} i
*>i10.0.0.3/32 8.1.1.1 100 300 0 2 {3,4} i
*>i10.1.7.2/32 8.1.1.1 100 300 0 2 3 {4} I <<doesn’t match because of 2nd octet
If I slightly change the prefix statement to: 10.0.7.4/32 ge 16 le 24
*>i10.0.7.0/30 8.1.1.1 100 300 0 2 3 {4} i
*>i10.0.7.4/30 8.1.1.1 100 300 0 2 {3,4} i
*>i10.0.7.8/30 8.1.1.1 100 300 0 2 3 {4,5} i
Still no match as the base mask is not met on the prefixes received.
So the /<whatever> determines the MASK of the route I wanted to match. whereas the GE/LE provide me the variance in either that mask (if bigger) or from the other octects (if smaller then the /mask)
To determine what in your route-policy is consuming the majority of the time, you can use route profiling.
It allows some data collection in the background with minimal impact on the execution of the rpl. After the collection has been running for some time you can use show commands to find out which steps take a lot of time in the execution and make some improvements.
Once we figure out which portion of the policy is performance drag, its much easier to try out an alternative. Something like regex match always failing means we need to evaluate route using prefix match prior to validating its as-paths.
Example usage:
debug pcl profile detail
then
Policy execution profile
Protocol : bgp 10
Attachpoint : neighbor-in-dflt
AP Instance : default-IPv4-Uni-1.2.3.4
Policy Name : rpl_profile(nexthop)
Pass : 10
Drop : 5
Total : 15
Avg execution time : 110usec
Router#sh rpl route-policy rpl_profile detail
route-policy test
apply test2
done
end-policy
!
route-policy test2
end-policy
!
route-policy rpl_profile($p_nexthop)
set med 155
else
set med 77
endif
apply test
end-policy
!
Policy execution profile
Protocol : bgp 10
Attachpoint : neighbor-in-dflt
AP Instance : default-IPv4-Uni-1.2.3.4
Policy : rpl_profile(nexthop)
Pass : 15
Drop : 0
Total : 15
Avg execution time : 110usec
--------------------------------------------------------------------------------
GOTO : PXL_0_6
Router#
As you have noticed when editting RPL's you need to reconfigure the complete policy in the regular CLI. An easier method is using the "edit" option described above.
When you are changing your RPL or prefix-set or any other list that RPL is using, it will trigger a few things:
If the RPL is used for BGP and your peer is not REFRESH capable, it will restart your BGP session.
If the peer is REFRESH capable a full table refresh is executed.
The reason for that is, that the RPL change or say prefix set change could have excluded some routes before that now may need to be imported.
On the Receiving Side:
For BGP, routes that are filtered are completely discarded and are NOT kept in memory with some kind of mark that says bgp rpl filtered.
We will use route refresh to obtain the routes again from the neighbor whenever there is a change in inbound route policy.
For this the neighbor has to be refresh capable, else we have to do clear bgp.
When the BGP peer receives a route refresh request it sends the complete table again to the requesting peer. While asking for the table they ask for the relevant (AFI, SAFI) table. When the routes are received from the peer an inbound filter if any is applied and the routes are aggregated.
On the sending side:
if I apply an RPL basically removing some previously advertised route, would BGP send withdraws for these now filtered routes?
What would rpl/bgp do when the RPL is modified to:
1) do advertise some previously filtered routes
To advertise previously filtered routes it is similar to regular advertising of routes
2) stop advertising previously advertised routes
BGP will send withdraws when it stops advertising previously filtered routes.
Xander Thuijs, CCIE #6775
Sr. Tech Lead ASR9000
Hi,
I would like to achieve following:
If BGP neighbor sends a /32 route with community 1234:111 then set next hop discard.
I have created this prefix set and RPL and I would like to know if there is a better or more simple way?
prefix-set HOST_ROUTES
0.0.0.0/0
end-set
!
route-policy TEST1
if destination in HOST_ROUTES and community matches-every 1234:111 then
set next-hop discard
endif
end-policy
Is there a special command to enable this? Do I have to configure NO soft-reconfiguration inbound?
For
You need parentheses when writing an inline community set:
route-policy TEST1
if destination in (0.0.0.0/32) and community matches-every (1234:1111) then
set next-hop discard
endif
end-policy
A neighbor inbound route-policy may modify or drop routes received from the neighbor. When the local router needs the original unmodified routes from the remote router there are 3 cases for soft-reconfiguration inbound:
1: soft-reconfiguration inbound is NOT configured.
If the remote router supports route-refresh, then the local router will send it a route-refresh message. Otherwise the routes will not be refreshed and the only way to recover them is to manually reset the BGP session.
2: soft-reconfiguration inbound is configured.
If the remote router supports route-refresh, then the local router will send it a route-refresh message. Otherwise the local router stores the original routes and can retrieve them from this local storage.
3: soft-reconfiguration inbound always is configured.
The local router always stores the received routes locally and will never send a route-refresh message to the remote router.
Route refreshes are usually very fast, much faster than the receipt of the routes the first time. That is because the main bottleneck in BGP convergence is route download to the line cards, not BGP. Refreshed routes that have not changed from the original do not need to be downloaded to the line cards again.
Your logic is correct Smail1 although I would probably recommend to follow a matches-any approach because at your border the route may already have a community-set and you may reclassify/additively add the 1234:111 (so it is not the only community).
soft reconfig you dont need to configure, xr devices are capable of that and will advertise that during the session open sequence.
this is separate from the soft reconfig which allows for an unfiltered table pre RPL processing from the neighbor. a refresh capable neighbor doesnt necessarily need a soft reconfig config per-se since the refresh is rather fast between neigh's. the soft reconfig always will not ask for a refresh from the peer and always use the shadow table received.
cheers
xander
You can use 4-byte ASN in AS-path and extended communities, but not in regular communities as in RFC 1997. This is why large communities were developed in RFC 8092. This will be in 6.3.1 as EFT.
Thank
I am using a
Ok thanks, I will use match-any.
If I want to able to see all received routes from a particular BGP neighbor, the only way is to use soft reconfiguration inbound always, right?
e.g. show
Hi!
Thanks for the great post
Is there any way to set community as a variable?
For example:
route-policy BGP_IN($region)
set community (65:10048, 65:10004, $region) additive
end-policy
Hi,
I am trying to achieve this:
If I learn a prefix from my iBGP neighbor then I should redistribute it the eBGP neighbor.
If have configured this route-policy but I get always an error about neighbor-out-
route-policy T-Com_DISTRIBUTE
if
pass
endif
if destination in T-Com_DISTRIBUTE then
pass
endif
end-policy
!
!!% Policy [T-Com_DISTRIBUTE] uses the 'protocol' attribute. There is no 'protocol' attribute at the
Please note that the BGP process is 65101 but we are using public AS number for this
Both iBGP and eBGP sessions are in VRF "Internet".
I have tried to check the attach point for neighbor-out-
show
The
T-Com_DISTRIBUTE
What am I missing? Maybe I should remove the RPL from the neighbor, edit it and apply it again?
I am not using edit route-policy T-Com_DISTRIBUTE. I want to reconfigure it under config
hmm not 100% following what you're trying to do here, I mean having a pub AS number for the peering, but your process is private. If you are running multi instance BGP, you probably have to do a redistribute operation here to pull in the routes from the other instance?
the eBGP neigh needs to have a route-policy before it can advertise (or accept) routes from a peer.
so you may want to try to do the redistribute bgp <AS> route-policy <> to control the redistribution from one process to the other.
cheers
xander
Hi Xander,
we are running only one instance (65101) because this IGW is also a PE with vpnv4 and v6 (not important now).
For every
So, we are not running multi-instance BGP here. There is nothing special configured under
oh hey smail, our trusted BGP advisor Jakob H. suggested to look into the
if pathtype is ibgp
may wanna give that a try/look?
cheers!
xander
So the first thing to note, is that your RPL has two conditional matches:
Assuming that you go to one conditional match, and you only want to advertise routes from within your AS (i.e. not transit); you could use:
route-policy LOCAL
if as-path is-local then
pass
endif
end-policy
Any routes that do not have an AS-Path are then advertised to that specific peer with this policy.
As a side note, when you use the match protocol, that is used when selecting the source routing protocol to inject (redistribute) into the destination routing protocol. That is the only place that it can 'attach'.
Hi,
I will also try your suggestion, just to see that what is the better solution.
Hi,
thanks for replying.
I have tried with "if as-path
And also thank you for explained the use of "if protocol". On
If you want to match off of routes that have been redistributed, you could match on the incomplete origin attribute. But it could include external paths to; as it carries from AS to AS.
If the is-local attribute is working for you and advertising the prefixes to the peer, then its time to check things like AS loop-check, RIB failures of next-hop, etc on that peer.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: