Policy based Routing

In Theory
Policy Routing is a feature on Cisco routers that offers greater control over paths in a network.
Normal routing is done based on the routing table. The router looks up the destination address of a packet and finds out the next hop or the outgoing interface.
With Policy Routing you can override whatever the routing table says and just route packets however you like.
Isn’t this what static routing does? To some degree, yes. You can use static routes to manipulate the outcome of a route lookup, but static routes integrate in the normal routing process. The router will still base it’s routing decision on the packet’s destination address.
The true power of policy routing is that it can take routing decisions on other parameters like incoming interface, source address or even application type (http, ftp).
Configuring Polcy Routing is a 2 step process.
Define the route-map
1
R(config)# route-map ROUTE-MAP [permit|deny] [SEQ]
2
!default: permit 10
Copied!
A route-map can have multiple statements, each statement being identified by a SEQ. If you don’t set a number, the default is 10. One statement can have multiple match commands and multiple set commands.
A packet is passed sequentially through the route-map statements. At each statement, the packet is considered matched if it is matched by all the match commands in that statement. If at least one of the match statements is not matched, then the packet is passed to the next statement. If all match statements are matched, then all set commands are applied.
If a matched route-map statement is set to permit, then the packet is policy-routed. If a matched route-map statement is set to deny, then it is routed according to the routing table. In either case, once a matching statement is found, no other statements are checked. If no statements are matched the packet is also routed according to the routing table.
Inside the route-map configuration mode we have to define a matching criteria using the match command. There are a lot of options, but most of them have to do with manipulating routing updates. For the purpose of Policy Routing we can use the following commands. In one statement, there can be multiple match commands, and a packet will be considered to match if it matches all of them (AND logic). One match command can refer to multiple objects (ex: multiple ACLs). A packet will be considered to match that entry if it matches at least one of the objects (OR logic).
1
R(config-route-map)# match interface INTERFACE
2
!Matches on incoming interface:
3
R(config-route-map)# match ip address ACL
4
!Matches on destination IP:
5
R(config-route-map)# match ipv6 address ACL
6
!Matches on IPv6 destination IP:
7
R(config-route-map)# match length MIN-LEN
8
!Matchs on minimum packet length:
Copied!
When a packet is matched, all the set commands that are configure in the statement are executed:
1
R(config-route-map)# set [default] interface INTERFACE
2
! Sets the outgoing interface
3
R(config-route-map)# set ip [default] next-hop NEXT-HOP-IP [recursive NEXT-HOP-IP2]
4
! Sets the next-hop address (IPv4)
5
R(config-route-map)# set ipv6 [default] next-hop NEXT-HOP-IP
6
! Sets the next-hop address (IPv6)
Copied!
When using the default keyword we tell the router to first try to find a match using the routing table and then use our defined policy, basically overriding only the routing table’s default route.
As you can see, we can define an outgoing interface or a next-hop address. Just like with static routes, you must understand the differences between using the next-hop or the outgoing interface. If there are multiple set commands, the order in which they are resolved is:
1.set ip next-hop
2.set ip next-hop recursive
3.set interface
4.set ip default next-hop
5.set ip default interface
For IPv4 we have one more option – using EOT – Enhanced Object Tracking to see if the next hop is up or not:
1
R(config-route-map)#set ip next-hop verify-availability NEXT-HOP-IP SEQ track OBJ
Copied!
SEQ is a sequence number that is used to identify multiple options for the next hop, end OBJ is the object used to track availability. As you can imagine, this next hop will be used only if the object used for tracking is returning a positive result.
Optionally, you can also set a description for the route-map entry
1
R(config-route-map)# description STRING
Copied!
Use route maps for traffic filtering
Simply match incoming traffic and set the outgoing interface to NULL0:
1
R(config-route-map)#set interface NULL0
Copied!
Apply the Route Map
You probably realized that the policy must be set on the interface where we expect to receive the traffic that will be matched. Setting the route-map on the outgoing interface makes no sense because the packets have already went through the routing process so they will just be sent out.
1
R(config-if)# ip policy route-map ROUTE-MAP
Copied!
But what if I want to policy route traffic originated from the router. It has no incoming interface, so we have to use:
1
R(config)# ip local policy route-map ROUTE-MAP
Copied!
Force local traffic to be checked by ACLs
By default, traffic originated locally is not checked by ACLs set on interfaces. You can use route-maps to set the next-hop of locally originated traffic to a loopback interface, and force this way the traffic from being checked by the ACLs. The loopback interface is still local but the fact that is switching from one interface to another will force the router to apply the ACLs on this traffic.
Working examples
Example 1
Here’s an example:
​​
​​
PBR Example Topology
In our topology, we have 5 routers, each configured with an ip address on the Lo0 interface. On R1 we will simulate 2 hosts by using Lo1, as well. We will run EIGRP for route exchange. Here’s the starting config:
On R1:
1
interface Loopback0
2
 ip address 1.1.1.1 255.255.255.255
3
!
4
interface Loopback1
5
 ip address 11.11.11.11 255.255.255.255
6
!
7
interface FastEthernet0/0
8
 ip address 12.0.0.1 255.255.255.0
9
 duplex auto
10
 speed auto
11
!
12
router eigrp 100
13
 network 0.0.0.0
14
 no auto-summary
Copied!
On R2:
1
interface Loopback0
2
 ip address 2.2.2.2 255.255.255.255
3
!
4
interface FastEthernet0/0
5
 ip address 12.0.0.2 255.255.255.0
6
 duplex auto
7
 speed auto
8
!
9
interface FastEthernet0/1
10
 ip address 24.0.0.2 255.255.255.0
11
 duplex auto
12
 speed auto
13
!
14
interface Serial1/0
15
 ip address 23.0.0.2 255.255.255.0
16
 serial restart-delay 0
17
!
18
router eigrp 100
19
 network 0.0.0.0
20
 no auto-summary
Copied!
On R3:
1
interface Loopback0
2
 ip address 3.3.3.3 255.255.255.255
3
!
4
interface FastEthernet0/1
5
 ip address 35.0.0.3 255.255.255.0
6
 duplex auto
7
 speed auto
8
!
9
interface Serial1/0
10
 ip address 23.0.0.3 255.255.255.0
11
 serial restart-delay 0
12
!
13
router eigrp 100
14
 network 0.0.0.0
15
 no auto-summary
Copied!
On R4:
1
interface Loopback0
2
 ip address 4.4.4.4 255.255.255.255
3
!
4
interface FastEthernet0/0
5
 ip address 45.0.0.4 255.255.255.0
6
 duplex auto
7
 speed auto
8
!
9
interface FastEthernet0/1
10
 ip address 24.0.0.4 255.255.255.0
11
 duplex auto
12
 speed auto
13
!
14
router eigrp 100
15
 network 0.0.0.0
16
 no auto-summary
Copied!
On R5:
1
interface Loopback0
2
 ip address 5.5.5.5 255.255.255.255
3
!
4
interface FastEthernet0/0
5
 ip address 45.0.0.5 255.255.255.0
6
 duplex auto
7
 speed auto
8
!
9
interface FastEthernet0/1
10
 ip address 35.0.0.5 255.255.255.0
11
 duplex auto
12
 speed auto
13
!
14
router eigrp 100
15
 network 0.0.0.0
16
 no auto-summary
Copied!
Remember that by default, physical router interfaces are disabled, so you should enable them using
1
R(config-if)# no shutdown
Copied!
On R1 we can test connectivity to R5 and see how the network converged:
1
R1#traceroute 5.5.5.5 source 1.1.1.1 numeric
2
​
3
Type escape sequence to abort.
4
Tracing the route to 5.5.5.5
5
​
6
  1 12.0.0.2 8 msec 24 msec 16 msec
7
  2 24.0.0.4 28 msec 36 msec 48 msec
8
  3 45.0.0.5 44 msec *  88 msec
9
​
10
R1#traceroute 5.5.5.5 source 11.11.11.11 numeric
11
​
12
Type escape sequence to abort.
13
Tracing the route to 5.5.5.5
14
​
15
  1 12.0.0.2 12 msec 24 msec 16 msec
16
  2 24.0.0.4 36 msec 36 msec 40 msec
17
  3 45.0.0.5 72 msec *  56 msec
Copied!
Use numeric when starting a traceroute to disable the DNS lookups and get a faster response. As you can see, the route goes through R2, then R4 and then R5. The reason for this is because on R2, the interface towards R4 is Fast Ethernet, while the link towards R3 is over a HDLC serial link. Since the default EIGRP metric involves bandwidth and delay the route towards R4 will be considered the best. If we had RIP running, it would have installed 2 equal routes towards R5, as the hop count is the same.
1
R2#sh int fa0/1 | i BW
2
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
3
R2#sh int s1/0 | i BW
4
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
Copied!
Now let’s set a route map on R2 so that traffic from 11.11.11.11 would go through R3:
1
!Define an ACL to match the traffic:
2
R2(config)# access-list 99 permit 11.11.11.11
3
!Define the route map
4
R2(config)# route-map ROUTE_MAP11 permit 10
5
R2(config-route-map)# match ip address 99
6
R2(config-route-map)# set ip next-hop 23.0.0.3
7
R2(config-route-map)# exit
8
!Apply the policy on the incoming interface:
9
R2(config)# interface Fa0/0
10
R2(config-if)# ip policy route-map ROUTE_MAP11
Copied!
To verify the configuration, we will traceroute from R1 using each Loopbacks as the source:
1
R1#traceroute 5.5.5.5 source 1.1.1.1 numeric
2
​
3
Type escape sequence to abort.
4
Tracing the route to 5.5.5.5
5
​
6
  1 12.0.0.2 12 msec 16 msec 20 msec
7
  2 24.0.0.4 40 msec 40 msec 44 msec
8
  3 45.0.0.5 52 msec *  68 msec
9
​
10
R1#traceroute 5.5.5.5 source 11.11.11.11 numeric
11
​
12
Type escape sequence to abort.
13
Tracing the route to 5.5.5.5
14
​
15
  1 12.0.0.2 12 msec 20 msec 20 msec
16
  2 23.0.0.3 48 msec 64 msec 72 msec
17
  3 35.0.0.5 60 msec *  72 msec
Copied!
As you can see, when the source is 1.1.1.1, the path is R1-R2-R4-R5and when the source is 11.11.11.11, the path is R1-R2-R3-R5
To verify on R2, we can start a debug process to see how the traffic was routed.
1
R2#debug ip policy
2
Policy routing debugging is on
3
R2#
4
*Mar  1 02:44:30.919: IP: s=1.1.1.1 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy rejected(no match) - normal forwarding
5
*Mar  1 02:44:30.955: IP: s=1.1.1.1 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy rejected(no match) - normal forwarding
6
*Mar  1 02:44:30.999: IP: s=1.1.1.1 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy rejected(no match) - normal forwarding
7
*Mar  1 02:44:31.043: IP: s=1.1.1.1 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy rejected(no match) - normal forwarding
8
*Mar  1 02:44:31.095: IP: s=1.1.1.1 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy rejected(no match) - normal forwarding
9
*Mar  1 02:44:34.095: IP: s=1.1.1.1 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy rejected(no match) - normal forwarding
10
*Mar  1 02:44:44.463: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy match
11
*Mar  1 02:44:44.463: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, g=23.0.0.3, len 28, FIB policy routed
12
*Mar  1 02:44:44.523: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy match
13
*Mar  1 02:44:44.523: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, g=23.0.0.3, len 28, FIB policy routed
14
*Mar  1 02:44:44.583: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy match
15
*Mar  1 02:44:44.587: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, g=23.0.0.3, len 28, FIB policy routed
16
*Mar  1 02:44:44.647: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy match
17
*Mar  1 02:44:44.647: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, g=23.0.0.3, len 28, FIB policy routed
18
*Mar  1 02:44:44.707: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy match
19
*Mar  1 02:44:44.707: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, g=23.0.0.3, len 28, FIB policy routed
20
*Mar  1 02:44:47.679: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, len 28, FIB policy match
21
*Mar  1 02:44:47.679: IP: s=11.11.11.11 (FastEthernet0/0), d=5.5.5.5, g=23.0.0.3, len 28, FIB policy routed
Copied!
Or we can use this command to see the policies defined and how many packets were matched:
1
R2#sh route-map
2
route-map ROUTE_MAP11, permit, sequence 10
3
  Match clauses:
4
    ip address (access-lists): 99
5
  Set clauses:
6
    ip next-hop 23.0.0.3
7
  Policy routing matches: 6 packets, 360 bytes
Copied!
Notice there are 6 packets that matched, because although we sent 12 packets (check the debug output), only 6 of them matched the criteria – those sourced by 11.11.11.11. Why do we have 6 packets for just one traceroute command?
Traceroute uses the TTL field to discover the path to a destination. It first sends packets with TTL=1, then increases the TTL until it reaches the destination. Each router on the path should decrease the TTL when routing the packet and should drop it when the TTL reaches 0. Actually, if the packet is not for itself, it would be pointless to route it, then decrease TTL and drop it, So, incoming packet with TTL 1 that should be routed are dropped. When dropping, it also should send an ICMP reply with the Type 11 (time-exceeded) and Code 0 (time to live exceeded in transit) back to the source, thus helping traceroute to map each router along the path.
Cisco routers send by default 3 UDP packets for each TTL value starting from 1 upwards. This will help find multiple routes to a destination and also compute some average values for the Round Trip Time to each router along the path.
So R1 first sends 3 packets with TTL=1. They will be droped by R2, so they won’t even get to the routing part – Matches so far: 0
R1 then sends another 3 packets with TTL=2. They will pass through R2 before being dropped by R3 – Matches so far: 3
R1 then sends another 3 packets with TTL=3. They will pass through R2 and R3 before R4 responds with an ICMP Type 3 (Destination unreachable) Code 3 (Port unreachable) for each one, signaling that the packets reached the destination, but there is no one waiting this kind of traffic. Matches so far: 6
So there it is, the 6 matches that we saw, made sense.
Example 2
Let’s say I want to have an out-of-band management connection from R2 to R5, when connecting via telnet. Let’s enable telnet on R5 first:
1
R5(config)# line vty 0 4
2
R5(config-line)# password cisco
3
R5(config-line)# login
Copied!
We should be able to telnet from R2 to R5, but we are going through R4. I am using 2.2.2.2 as the source address of my telnet traffic.
1
R2#telnet 5.5.5.5 /source-interface lo0
Copied!
Let’s set this management traffic to be out-of-band, through R3:
1
! Create the ACL:
2
R2(config)# access-list 199 permit tcp any any eq telnet
3
!Create the route-map
4
R2(config)# route-map ROUTE_MAP_TELNET permit 10
5
R2(config-route-map)# match ip address 199
6
R2(config-route-map)# set ip next-hop 23.0.0.3
7
! Apply the route-map
8
R2(config)# ip local policy route-map ROUTE_MAP_TELNET
Copied!
In order to verify, let’s create an ACL on R5 just for accounting purpose:
1
! First allow telnet packets for accounting
2
R5(config)# access-list 100 permit tcp any any eq telnet log-input
3
! Then allow anything else
4
R5(config)# access-list 100 permit ip any any
5
! Apply it on Fa0/1 interface
6
R5(config)# interface Fa0/1
7
R5(config-if)# ip access-group 100 in
Copied!
Back on R2, we should be able to telnet to R5, but remember to disable debugging first, otherwise we would see a lot of messages like this:
1
*Mar  1 06:11:53.994: IP: route map ROUTE_MAP_TELNET, item 10, permit
2
*Mar  1 06:11:53.994: IP: s=2.2.2.2 (local), d=5.5.5.5 (Serial1/0), len 40, policy routed
Copied!
It’s just the debug ip policy that was previously started, telling us that there are locally generated packets that match the route-map.
Over to R5 to verify:
1
R5#sh access-lists 100
2
Extended IP access list 100
3
    10 permit tcp any any eq telnet log-input (57 matches)
4
    20 permit ip any any (265 matches)
Copied!
Yes! The telnet traffic originated by R2 arrived on Fa0/1 via R3.
The end?
We were able to send traffic from R2 to R5, via R3, using the route-map. But is it over? Well, no, because this is just one way. If we look at R5’s routing table, it will send return traffic back to R2’s Lo0 via R4:
1
R5#sh ip route 2.2.2.2
2
Routing entry for 2.2.2.2/32
3
Known via "eigrp 100", distance 90, metric 435200, type internal
4
Redistributing via eigrp 100
5
Last update from 45.0.0.4 on FastEthernet0/0, 01:06:22 ago
6
Routing Descriptor Blocks:
7
* 45.0.0.4, from 45.0.0.4, 01:06:22 ago, via FastEthernet0/0
8
Route metric is 435200, traffic share count is 1
9
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
10
Reliability 255/255, minimum MTU 1500 bytes
11
Loading 1/255, Hops 2
Copied!
The solution is to enable PBR in the other direction also. You should know how to do it by now.
ODR
How the routing table is built
Last modified 2mo ago
Copy link
Contents