Hello everyone! Welcome back to the IOS XR series. In this article we will examine an advanced route-filtering technique called “route-policy” on the IOS XR platform.

In traditional IOS, route maps are used for conditional filtering with “match-set” functionalities to control and manipulate routing attributes. Instead of route maps, IOS XR supports route policy.

CCNA Training – Resources (Intense)

Route Policy is one of the best route-filtering techniques I have ever encountered in Cisco Networking. It allows users to filter routing databases as per network convenience and provides an “if-else” based command line approach for designing conditional route filtering mechanisms in an IOS XR environment. Route policy supports hierarchical designing and has the ability to invoke other policies as well.

This article assumes that you have basic access level knowledge of the Cisco IOS XR platform. If not, lplease refer to my previous posts on IOS XR. Before starting on the technical fundamentals of route policy, let’s review the following common route filtering techniques first:

  • Access Control Lists: ACLs are widely used for:
    • Packet filtering: When an ACL is applied on an interface using the “access-group” command.
    • Route filtering: When an ACL is applied under routing protocol using the “distribute-list” command.

Using access lists, you can either pass or drop the matched traffic.

  • Route Maps: Route maps are used to perform conditional filtering using “match-set” statements and are commonly used to modify metric, metric-types, next-hop, and BGP path control by changing weight, local preference, and origin attributes.
  • Prefix Lists: Prefix lists are used for CIDR based network filtering.
  • Filter Lists: Filter lists are used in both OSPF and BGP.

    For OSPF: It is used to filter type 3 LSA and is always applied on ABRs.

    For BGP: It is used for AS-Path based network filtering. An AS-path access list is required to apply filter lists in BGP.

All of the above route filtering technologies are widely used and I hope all of you are comfortable with them.

We will now do an in-depth analysis of route policy designing and the how its implementation affects EIGRP, OSPF and BGP routing deployments on the IOS XR platform. To better illustrate the fundamentals of proper implementation of route policies, I have designed some hands-on labs below.

Refer to the following set of commands as pre-configurations for given scenarios.

Router xr1:

Building configuration...
!! IOS XR Configuration 5.1.1
!
hostname xr1 
cdp
!
interface Loopback1
 ipv4 address 10.1.1.1 255.255.255.0
!
interface Loopback2
 ipv4 address 10.1.2.1 255.255.255.0
!
interface Loopback3
 ipv4 address 10.1.3.1 255.255.255.0
!
interface Loopback4
 ipv4 address 10.1.4.1 255.255.255.0
!
interface MgmtEth0/0/CPU0/0
 cdp
 ipv4 address 192.168.12.1 255.255.255.252
!
End

Router xr2:

Building configuration...
!! IOS XR Configuration 5.1.1
!
hostname xr2 
cdp
!
interface MgmtEth0/0/CPU0/0
 cdp
 ipv4 address 192.168.12.2 255.255.255.252
!
End

Designing Route Policies

Let’s look at the following examples to understand route policy configuration and capabilities.

Example 1: Designing a route policy with a prefix-set. Note: Prefix-sets are used to match desired network prefixes.

RP/0/0/CPU0:XR(config)# prefix-set A  //** prefix-set A to match 192.168.3.0/24 prefix
RP/0/0/CPU0:XR(config-pfx)#  192.168.3.0/24
RP/0/0/CPU0:XR(config-pfx)# end-set

RP/0/0/CPU0:XR(config)# prefix-set B  //** prefix-set B to match all prefixes
RP/0/0/CPU0:XR(config-pfx)#  0.0.0.0/0 le 32
RP/0/0/CPU0:XR(config-pfx)# end-set

RP/0/0/CPU0:XR(config)# route-policy infosec   //** infosec is route-policy name
RP/0/0/CPU0:XR(config-rpl)#  if destination in A then  //** defined for incoming traffic
RP/0/0/CPU0:XR(config-rpl-if)# drop
RP/0/0/CPU0:XR(config-rpl-if)#  endif
RP/0/0/CPU0:XR(config-rpl)#  if destination in B then
RP/0/0/CPU0:XR(config-rpl-if)#  pass
RP/0/0/CPU0:XR(config-rpl-if)#  endif
RP/0/0/CPU0:XR(config-rpl)#end-policy

If the above set of commands are applied on a router for incoming traffic then all packets and routes that belong to prefix 192.168.3.0/24 will be dropped and traffic other than 10.1.3.0/24 will be allowed.

Example 2: Designing a route policy without a prefix-set.

RP/0/0/CPU0:XR(config)#route-policy infosec
RP/0/0/CPU0:XR(config-rpl)#if med eq 15 then
RP/0/0/CPU0:XR(config-rpl-if)#set origin incomplete
RP/0/0/CPU0:XR(config-rpl-if)#endif
RP/0/0/CPU0:XR(config-rpl)#end-policy

These commands will match all prefixes with med 15 and will be replaced by origin code “incomplete”.

The following objectives provide a true hands-on experience of route policy with EIGRP, OSPF and BGP.

Objective 1: EIGRP route policy based filtering

Router xr1 is advertising all network prefixes of 10.X.X.X/X to its EIGRP neighbour router xr2 (refer to Fig. 1) but prefix 10.1.3.0/24 must not be seen in Router xr2‘s routing table.

Solution: In traditional Cisco IOS, route filtering can be achieved using distribute lists but in IOS XR, EIGRP does not support distribute lists or route map based route filtering, so you will have to design a route policy to meet the given objective.

Note: Before applying route policy, an EIGRP neighbour relationship must be established between router xr1 and xr2. You can refer to my article “Routing Fundamentals with IOS XR” to learn how to establish EIGRP neighbour relationship.

The following set of commands will be used to apply route policy on router xr2 to achieve the objective.

Step 1: Create Route Policy

RP/0/0/CPU0:xr2(config)# prefix-set NY3
RP/0/0/CPU0:xr2(config-pfx)# 10.1.3.0/24
RP/0/0/CPU0:xr2(config-pfx)# end-set
RP/0/0/CPU0:xr2(config)# prefix-set NY4
RP/0/0/CPU0:xr2(config-pfx)# 0.0.0.0/0 le 32
RP/0/0/CPU0:xr2(config-pfx)# end-set

RP/0/0/CPU0:xr2(config)# route-policy infosec
RP/0/0/CPU0:xr2(config-rpl)# if destination in NY3 then
RP/0/0/CPU0:xr2(config-rpl-if)# drop
RP/0/0/CPU0:xr2(config-rpl-if)# endif
RP/0/0/CPU0:xr2(config-rpl)# if destination in NY4 then
RP/0/0/CPU0:xr2(config-rpl-if)# pass
RP/0/0/CPU0:xr2(config-rpl-if)# endif
RP/0/0/CPU0:xr2(config-rpl)# end-policy

Step 2: Apply Route Policy under EIGRP

RP/0/0/CPU0:xr2(config)#router eigrp 10
RP/0/0/CPU0:xr2(config-eigrp)# address-family ipv4
RP/0/0/CPU0:xr2(config-eigrp-af)#  route-policy infosec in    /* route-policy is applied for incoming traffic
RP/0/0/CPU0:xr2(config-eigrp-af)# root
RP/0/0/CPU0:xr2(config)# commit  /* do not forget to commit

After configuring the above commands you will see the following result on router xr2:

Objective 2.1: OSPF Intra-Area route filtering

An OSPF adjacency is preconfigured between router xr1 and xr2 (refer to Fig. 3 below). Router xr1 is advertising all four subnets but you will have to define a route filtering technique on xr2 so that router xr2 can maintain all 10.X.X.X prefixes advertised by its neighbour except for 10.1.3.0/24.

Solution: Intra-area route filtering can be achieved using a distribute list.

Step 1: Create ACL

RP/0/0/CPU0:xr2(config)# ipv4 access-list infosec deny 10.1.3.0/24
RP/0/0/CPU0:xr2(config)# ipv4 access-list infosec permit any

Step 2: Apply ACL using distribute-list:

RP/0/0/CPU0:xr2(config)# router ospf 1
RP/0/0/CPU0:xr2(config-ospf)# distribute-list infosec in  /* here “infosec” is the name of ACL

After configuring the above steps, you will be able to see the following result:

Objective 2.2: OSPF Inter-Area route filtering

Area border router xr2 (refer to Fig. 5) must not advertise 10.1.3.0/24 network prefix to area 1 so that xr3 can receive all network prefixes other than 10.1.3.0/24 from area 0.

Solution: OSPF Inter-area route filtering can be configured only on ABRs and a route-policy is required to achieve the objective. The following set of commands can be used to configure OSPF Inter-area route filtering on an IOS XR router.

Step 1: Create Route Policy

RP/0/0/CPU0:xr2(config)# prefix-set NY3
RP/0/0/CPU0:xr2(config-pfx)# 10.1.3.0/24
RP/0/0/CPU0:xr2(config-pfx)# end-set
RP/0/0/CPU0:xr2(config)# prefix-set NY4
RP/0/0/CPU0:xr2(config-pfx)# 0.0.0.0/0 le 32
RP/0/0/CPU0:xr2(config-pfx)# end-set

RP/0/0/CPU0:xr2(config)# route-policy infosec
RP/0/0/CPU0:xr2(config-rpl)# if destination in NY3 then
RP/0/0/CPU0:xr2(config-rpl-if)# drop
RP/0/0/CPU0:xr2(config-rpl-if)# endif
RP/0/0/CPU0:xr2(config-rpl)# if destination in NY4 then
RP/0/0/CPU0:xr2(config-rpl-if)# pass
RP/0/0/CPU0:xr2(config-rpl-if)# endif
RP/0/0/CPU0:xr2(config-rpl)# end-policy

Step 2: Apply Policy

RP/0/0/CPU0:xr2(config)# router ospf 1
RP/0/0/CPU0:xr2(config-ospf)# area 1
RP/0/0/CPU0:xr2(config-ospf-ar)#route-policy infosec in  /* route policy always applied within areas
RP/0/0/CPU0:xr2(config-ospf-ar)# root
RP/0/0/CPU0:xr2(config)# commit                 /* to save above configuration to running-config 

I am sure you will see the same output after the implementation of the above commands as shown below:

Objective 3: BGP route filtering

Router xr2 (refer to Fig. 7) must receive all prefixes in its BGP database except for 10.1.3.0/24.

Solution: Before applying route policy in BGP, neighbour relationship must be established between xr1 and xr2. Review how to establish BGP neighbour relationship through this article: “Routing Fundamentals with IOS XR Part II“.

Step 1: Create Route Policy

Follow the same set of commands as provided in the EIGRP/OSPF Inter Area filtering section.

Step 2: Apply route policy under BGP neighbour definition on Router xr2

RP/0/0/CPU0:xr2(config)# router bgp 10
RP/0/0/CPU0:xr2(config-bgp)# neighbor 12.1.1.1
RP/0/0/CPU0:xr2(config-bgp-nbr)# remote-as 10
RP/0/0/CPU0:xr2(config-bgp-nbr)# address-family ipv4 unicast
RP/0/0/CPU0:xr2(config-bgp-nbr-af)# route-policy infosec
RP/0/0/CPU0:xr2(config-bgp-nbr-af)#exit
RP/0/0/CPU0:xr2(config-bgp-nbr)#exit
RP/0/0/CPU0:xr1(config)#commit

Figure 8 displays the output result of “show bgp ipv4 unicast” command on router xr2 (“show ip bgp” command can also be used to check BGP learned prefixes). You can see prefix 10.1.3.0/24 is missing from the BGP database in the given output below.

I hope this article brings you closer to the ocean of IOS XR based route filtering techniques and be assured that this is just the beginning. I will continue to explore more edges of technologies but I would also like to read your feedbacks and your Intenseschool.com experience at the comments section below.

And don’t forget to share this article on Facebook, Twitter and LinkedIn so that more people can find this exclusive piece of information. Keep reading @ Intenseschool.com and like our Facebook page to get updates on new posts.

References:

Apart from my work experience and knowledge, the following resources helped me a lot to write this exclusive content.