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.
No comments:
Post a Comment