Tuesday, November 12, 2013

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.