1. This document is Prepared by George Micheal Gerges (CCIE-SP#44120, JNCIE-SP#2150)
1
Per vrf Tunnel selection
On cisco ios-xr

2. This document is Prepared by George Micheal Gerges (CCIE-SP#44120, JNCIE-SP#2150)
2
Introduction:
This document is about per VRF tunnel selection in IOS-XR . during this document we are going to use the following
topology
Our final goal is the following
1) CN traffic from VRT_CO_01 to NRT_CO_01 will go through Green TX path ( tunnel-te1 on VRT_CO_01)
2) IN traffic from VRT_CO_01 to NRT_CO_01 will go through Black TX path ( tunnel-te2 on VRT_CO_01)
3) CN traffic from VRT_CO_01 to XRT_CO_01 will go through Red TX path ( tunnel-te3 on VRT_CO_01)
4) IN traffic from VRT_CO_01 to XRT_CO_01 will go through both Red and Blue TX path ( tunnel-te 3 and tunnel-
te4 on VRT_CO_01)
Also during our test will use the following VRFs
VRF name RD Import/Export RT
CN 100:100 100:100
IN 200:200 200:200
Before applying any changes the current BGP configurations on VRT_CO_01 are as the following

3. This document is Prepared by George Micheal Gerges (CCIE-SP#44120, JNCIE-SP#2150)
3
RP/0/0/CPU0:VRT_CO_01#show run router bgp
Thu Sep 11 03:48:49.160 UTC
router bgp 100
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor-group IBGP
remote-as 100
update-source Loopback0
address-family ipv4 unicast
next-hop-self
!
address-family vpnv4 unicast
next-hop-self
!
!
neighbor 10.64.0.7
use neighbor-group IBGP
!
neighbor 10.64.0.11
use neighbor-group IBGP
Let’s check the forwarding table for each VRF
RP/0/0/CPU0:VRT_CO_01#show cef vrf CN 100.100.100.11
next hop 10.64.0.11/32 tt1 labels imposed {ImplNull 16}
next hop 10.64.0.11/32 tt2 labels imposed {ImplNull 16}
RP/0/0/CPU0:VRT_CO_01#show cef vrf IN 200.200.200.11
next hop 10.64.0.11/32 tt1 labels imposed {ImplNull 17}
next hop 10.64.0.11/32 tt2 labels imposed {ImplNull 17}
RP/0/0/CPU0:VRT_CO_01#show cef vrf CN 100.100.100.7
next hop 10.64.0.7/32 tt3 labels imposed {ImplNull 16}
next hop 10.64.0.7/32 tt4 labels imposed {ImplNull 16}
RP/0/0/CPU0:VRT_CO_01#show cef vrf IN 200.200.200.7
next hop 10.64.0.7/32 tt3 labels imposed {ImplNull 17}
next hop 10.64.0.7/32 tt4 labels imposed {ImplNull 17}
As seen before applying any changes , there is no separation in the traffic of the VRFs ( traffic of all the VRFs use the
same tunnels)

4. This document is Prepared by George Micheal Gerges (CCIE-SP#44120, JNCIE-SP#2150)
4
And Now let’s configure the policy to achieve our required final goal
route-policy PPLB
#Term NRT_CO_01 IN
if extcommunity rt matches-any (200:200) and next-hop in (10.64.0.11) then
set next-hop 1.1.1.1
endif
#Term NRT_CO_01 CN
if extcommunity rt matches-any (100:100) and next-hop in (10.64.0.11) then
set next-hop 2.2.2.2
endif
# Term XRT_CO_01 CN
if extcommunity rt matches-any (100:100) and next-hop in (10.64.0.7) then
set next-hop 3.3.3.3
endif
pass
end-policy
This policy will match on certain BGP next-hop ( Which represents the remote PE ) and certain BGP extended
community ( To determine the traffic of certain VRF) and then will change the BGP next-hop to a new value ( this
new value is virtual IPs not used in our network like 1.1.1.1 and 2.2.2.2 , …)
Then After changing the BGP next-hop to the new virtual IP , this policy must be applied to all the BGP neighbors
under VPNv4 unicast address family . this new virtual IP will be reachable through certain tunnel by using static
routes .
To apply this policy for all the BGP neighbors use the following
router bgp 100
neighbor-group IBGP
address-family vpnv4 unicast
route-policy PPLB in
After the policy is applied we have the following
RP/0/0/CPU0:VRT_CO_01(config)#do sho bgp vpnv4 unicast
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CN)
* i100.100.100.7/32 3.3.3.3 0 100 0 ?  to use tunnel-te 3
* i100.100.100.11/32 2.2.2.2 0 100 0 ?  to Use tunnel-te1
Route Distinguisher: 200:200 (default for vrf IN)
*>i200.200.200.7/32 10.64.0.7 0 100 0 ?  to use both tunnels te3 and te4
* i200.200.200.11/32 1.1.1.1 0 100 0 ?  to use tunnel-te2

5. This document is Prepared by George Micheal Gerges (CCIE-SP#44120, JNCIE-SP#2150)
5
As shown , all the BGP next-hops have been changed as the policy , then final step is the configuring of the static routes
to the required tunnels as following
router static
address-family ipv4 unicast
1.1.1.1/32 tunnel-te2 tag 100
2.2.2.2/32 tunnel-te1 tag 100
3.3.3.3/32 tunnel-te3 tag 100
This tag value can be added so that to avoid the redistribution of these static routes into BGP so that the same
IPs can be used in another site
Now let’s check the forwarding table again
RP/0/0/CPU0:VRT_CO_01#show cef vrf CN 100.100.100.11
next hop 2.2.2.2 via 16013/0/21
next hop 0.0.0.0/32 tt1 labels imposed {ImplNull 16}
RP/0/0/CPU0:VRT_CO_01#show cef vrf IN 200.200.200.11
next hop 1.1.1.1 via 16014/0/21
next hop 0.0.0.0/32 tt2 labels imposed {ImplNull 17}
RP/0/0/CPU0:VRT_CO_01#show cef vrf CN 100.100.100.7
next hop 3.3.3.3 via 16015/0/21
next hop 0.0.0.0/32 tt3 labels imposed {ImplNull 16}
RP/0/0/CPU0:VRT_CO_01#show cef vrf IN 200.200.200.7
next hop 10.64.0.7 via 16006/0/21
next hop 10.64.0.7/32 tt3 labels imposed {ImplNull 17}
next hop 10.64.0.7/32 tt4 labels imposed {ImplNull 17}
As Per the previous output we have achieved our goal and next is final notes on configuring the PPLB policy
1) The policy must have an explicit pass key word at it’s end as the default behavior of the policy is reject all
2) If We want to modify the policy for any reason or any future change we must change it in the following order ( This
point is under investigation)
RP/0/0/CPU0:VRT_CO_01(config)#route-policy PPLB
Thu Sep 11 04:48:42.654 UTC
% WARNING: Policy object route-policy PPLB' exists! Reconfiguring it via CLI will replace current definition. Use
'abort to cancel.
As per the previous marked warning , if any changed done in the policy it will be deleted , so we must apply same
configurations again and then add or remove the required term
3) Finally we can have some sophisticated backup mechanism for the VRFs traffic ( not recommended as tunnels
are already backup in our network and to avoid more complexity) by adding floating static routes ( with higher
admin distance) to the dynamic tunnel that is found for each side .
4) by using this technique there is no need to apply any changes in all other routers that are already up and running .

6. This document is Prepared by George Micheal Gerges (CCIE-SP#44120, JNCIE-SP#2150)
6