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:
- IP SLA feature of Enhanced Object Tracking
- CDP
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