Conditional Policy-Based Routing

Previously, we've seen how Policy Based Routing can divert traffic from on path to another, even though the best path is a totally different one. The problem with policy-based routing is that it only specifies one option, if that option isn’t met, packets might be dropped or it can take a path that is still not preferred.

Conditional policy-based routing introduces additional options that help policy-based routing be more flexible. Let’s check this topology

Assuming that we have a PBR on R3 that diverts traffic from R4 loopback to interface S0/0 even though the best path is through interface F0/1. What will happen if interface S0/0 went down? All traffic sources from R4 Lo0 4.4.4.4 will be dropped and a black hole will be created in the network since it is enforced to go through S0/0 which is down.

What if we can tell R3 to enforce traffic sources from 4.4.4.4 to S0/0, BUT, in case S0/0 went down, reroute the traffic to F0/0? This can be done using IP SLA tracking  in conjunction with policy routing.

 Here’s the configuration of PBR  on R3

R3#sh ip policy

Interface      Route map

Fa1/0          PBR

R3#sh run int f1/0

Building configuration...

Current configuration : 136 bytes

!

interface FastEthernet1/0

 ip address 10.3.4.3 255.255.255.0

 ip policy route-map PBR

 ip ospf 1 area 0

 duplex auto

 speed auto

end

R3#sh route-map PBR

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): PBR

  Set clauses:

    interface Serial0/0

  Policy routing matches: 15 packets, 1278 bytes

R3#sh ip access-lists

Extended IP access list PBR

    10 permit ip host 4.4.4.4 host 1.1.1.1 (21 matches)

Now let’s traceroute from 4.4.4.4 to 1.1.1.1

R4#traceroute 1.1.1.1 source 4.4.4.4

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 32 msec 24 msec 16 msec

  2 10.1.3.1 56 msec *  32 msec

Assuming a failure happened between between R1 and R3, traffic sourced from 4.4.4.4 will be dropped on R3

R3#show ip int br

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            unassigned      YES NVRAM  administratively down down   

Serial0/0                  10.1.3.3        YES NVRAM  up                    down   

FastEthernet0/1            10.2.3.3        YES NVRAM  up                    up     

FastEthernet1/0            10.3.4.3        YES NVRAM  up                    up     

Loopback0                  3.3.3.3         YES NVRAM  up                    up     

R3#

*Mar  1 00:17:34.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down

*Mar  1 00:17:34.155: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

R4#ping 1.1.1.1 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

.....

Success rate is 0 percent (0/5)

The policy-map is brainless, it matches the source IP and insists that it must forward it through S0/0 even though its down.

Now, to fix that, we can make the PBR a little bit more flexiable by setting some conditions for it to act upon.

First, let’s create a track object to track Serial0/0 and F0/1 interfaces with a delay of 2 sec for going up or down

R3(config)#track 1 interface s0/0 line-protocol

R3(config-track)#delay up 2

R3(config-track)#delay down 2

R3(config)#track 2 interface f0/1 line-protocol

R3(config-track)#delay up 2

R3(config-track)#delay down 2

now  Let’s change our route-map PBR a bit to make it more flexible based on that track

R3(config)#route-map PBR permit 10

R3(config-route-map)#set ip next-hop verify-availability 10.1.3.1 ?

  <1-65535>  Sequence to insert into next-hop list

R3(config-route-map)#set ip next-hop verify-availability 10.1.3.1 1 track 1

Basically, we’re telling the route-map to track the availability of 10.1.3.1 next-hop through object tracking 1 as step #1, Now let’s create a second step in our route-map in case the first one failed

R3(config-route-map)#set ip next-hop verify-availability 10.2.3.2 2 track 2

The moment we do that you’ll notice that the first path is down and the second is up by showing the route-map

R3#show route-map PBR  

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): PBR

  Set clauses:

    ip next-hop verify-availability 10.1.3.1 1 track 1  [down]

    ip next-hop verify-availability 10.2.3.2 2 track 2  [up]

  Policy routing matches: 62 packets, 5178 bytes

Now let’s traceroute again from R4

R4#traceroute 1.1.1.1 source 4.4.4.4

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 20 msec 36 msec 20 msec

  2 10.2.3.2 40 msec 36 msec 40 msec

  3 10.1.2.1 72 msec *  60 msec

It seems that indeed R3 is routing through the second path now. For Final test, we’ll bring the interface between R3 and R1 back on and traceroute again

R3#

*Mar  1 00:47:46.379: %TRACKING-5-STATE: 1 interface Se0/0 line-protocol Down->Up

R3#show track

Track 1

  Interface Serial0/0 line-protocol

  Line protocol is Up

    2 changes, last change 00:00:28

  Delay up 2 secs, down 2 secs

  Tracked by:

    ROUTE-MAP 0

Track 2

  Interface FastEthernet0/1 line-protocol

  Line protocol is Up

    1 change, last change 00:12:32

  Delay up 2 secs, down 2 secs

  Tracked by:

    ROUTE-MAP 0

Now both tracks are up and used by the route-map

R3#show route-map PBR

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): PBR

  Set clauses:

    ip next-hop verify-availability 10.1.3.1 1 track 1  [up]

    ip next-hop verify-availability 10.2.3.2 2 track 2  [up]

  Policy routing matches: 98 packets, 8634 bytes

A Final traceroute should prove that everything is OK now

R4#traceroute 1.1.1.1 source 4.4.4.4

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 16 msec 36 msec 20 msec

  2 10.1.3.1 40 msec *  32 msec

Now we can rest assured that in case I have a problem in my forwarding interface used by PBR, no black hole can be created in the network.