Sunday, April 1, 2012

Reliable Policy Routing

Policy routing is not reliable and can cause traffic to be blackholed. Take for example:


R1 will be configure for Policy Routing.
When traffic from R2 wants to send traffic to R3, it will come in on R1 to R4 then to R3.
When traffic from R2 wants to send traffic to R4, it will come in on R1 to R3 then to R4.

Configs:

R1:
ip access-list extended R2toR3Lo
 permit ip host 12.12.12.2 host 3.3.3.3
ip access-list extended R2toR4Lo
 permit ip host 12.12.12.2 host 4.4.4.4
!
route-map RELIABLE_POLICY_ROUTING permit 10
 match ip address R2toR3Lo
 set ip next-hop 14.14.14.4
!
route-map RELIABLE_POLICY_ROUTING permit 20
 match ip address R2toR4Lo
 set ip next-hop 13.13.13.3

!
interface Serial0/0
  ip policy route-map RELIABLE_POLICY_ROUTING


R2:
ip route 0.0.0.0 0.0.0.0 12.12.12.1



R3:
ip route 0.0.0.0 0.0.0.0 13.13.13.1
ip route 4.4.4.0 255.255.255.0 34.34.34.4


R4:
ip route 0.0.0.0 0.0.0.0 14.14.14.1
ip route 3.3.3.0 255.255.255.0 34.34.34.3



The problem with Policy Routing:
R1 and R3 are on different physical segment. If the link to R3's Fastethernet 0/0 shutdown, R1 can will not update the line protocol status, the route to it will to 13.13.13.3 will still recurse in the routing table. Thus, R1 will not update it's policy routing to route around the failure. Traffic will be black holed. Therefore, we need some ways to track end to end connectivity for policy routing on R1.


Note: If the R1--R4 link fails, R1 will line protocol status will go down since this is a point to point link.

Ways we can track end-to-end connectivity:
  1. IP SLA feature of Enhanced Object Tracking 
  2. CDP
Here we will implement IP SLA on R1:
ip sla 1
 icmp-echo 13.13.13.3 source-interface FastEthernet0/1
 timeout 2000
 frequency 5
ip sla schedule 1 life forever start-time now

!
route-map RELIABLE_POLICY_ROUTING permit 20
 match ip address R2toR4Lo
 set ip next-hop verify-availability 13.13.13.3 1 track 1






No comments:

Post a Comment