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

Policy Routing

Policy Based Routing is a technique used to make routing and forwarding decisions based on user-defined policies set forth by access-lists, packet size or other criteria.

For Example:

• R1 has a default route pointing to the Ethernet link connecting to R3.
• R2 has a default route pointing to the Ethernet link connecting to R3.
• R4 has a default route pointing to the serial point-to-point link to R3.
• R5 has a default route pointing to R3 out the Frame-relay. 
• R4 has a static route to R5's loopback.
• R5 has a static route to R4's loopback.

Here we see that R3 does not have routing information for either Loopbacks of R5 or R4:

So R3 cannot send traffic there when it is locally generated:

Let's implement Policy Based Routing (PBR) on R3:

1. Configure the extended ACL.
2. Configure Route-Map.
3. Apply the Route-Map under the incoming interface using the ip policy command. 

Configure the ACL:

Configure the Route-Map:

Apply the Route-Map under the incoming interface using the ip policy command:

VERIFICATION:
If traffic comes in from R1 or R2's IP address attached to Ethernet network, it is routed according to the route-map attached to the incoming Fa0/0 interface.

Traceroute to R5's Loopback and R4's Loopback:

On R3, debug ip policy:

Understanding IP SLA Feature

IP SLA is a feature that allows a router to track whether or not there is a failure in the Layer 1 network along the path to the destination.  Once a failure in the Layer 1 network is discovered, the route will be removed from the routing table:

For example:

Here is the problem: 
Since R1 and R3 are on the same layer 2 segment but not on the same physical network, R1 will not remove it's route to R3's loopback network when there is a failure in the Layer 1 network segment.  In other words, R1 has no way of knowing if 13.13.13.3 is available. The result of this situation is that if R1's link to 13.13.13.3 is down, traffice between the Loopbacks of R1 and R3 will be dropped.

Configuration:

R1:                                                                                      
ip route 3.3.3.0 255.255.255.0 13.13.13.3                           

R3:
ip route 1.1.1.0 255.255.255.0 13.13.13.1

R1# show ip route
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     3.0.0.0/24 is subnetted, 1 subnets

S       3.3.3.0 [1/0] via 13.13.13.3

     13.0.0.0/24 is subnetted, 1 subnets
C       13.13.13.0 is directly connected, FastEthernet0/0




R1#show ip route 3.3.3.3
Routing entry for 3.3.3.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 13.13.13.3
      Route metric is 0, traffic share count is 1

We have connectivity from R1's Loopback to R3's Loopback:

R1#ping 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/44 ms


After Shutting down Switch FastEthernet 0/1 Interface:
Now on the Switch, I will shut down interface fastethernet 0/1 that connects to R1.
Sw(config-if)#int fa1/0
Sw(config-if)#shut

Notice that the route to R3 Loopback is still in the routing table. It didn't get removed!
R1#show ip route 3.3.3.3
Routing entry for 3.3.3.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 13.13.13.3
      Route metric is 0, traffic share count is 1

The interface is UP/UP:
R1#show ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            13.13.13.1      YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Loopback0                  1.1.1.1         YES manual up

If I ping R3's Loopback: 
R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....

Success rate is 0 percent (0/5)

Let's configure IP SLA:
R1(config)#ip sla 1
R1(config-ip-sla)#icmp-echo 13.13.13.3 source-interface fa0/0
R1(config-ip-sla-echo)#frequency 5
R1(config-ip-sla-echo)#timeout 200
R1(config)#ip sla schedule 1 life forever start-time now

Verify:
R1#show ip sla statistics 1
Round Trip Time (RTT) for       Index 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *00:17:25.351 UTC Fri Mar 1 2002
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 6
Operation time to live: Forever




Now configure tracking that watches the IP SLA instance.
R1(config)#track 1 rtr 1
R1(config)#no ip route 3.3.3.0 255.255.255.0 13.13.13.3
R1(config)#ip route 3.3.3.0 255.255.255.0 13.13.13.3 track 1

Verify:
R1#show track 1
Track 1
  Response Time Reporter 1 state
  State is Down
    1 change, last change 00:01:04

  Latest operation return code: Timeout

  Tracked by:
    STATIC-IP-ROUTING 0

Now the route to R3's Loopback has been uninstalled.
R1#show ip route 3.3.3.3

% Network not in table

Backup Interface

Configuring a backup interface is one of the ways to achieve both redundancy and traffic engineering.

Consider the following topology:

* R1 and R2 have redundant links to reach each others loopbacks (Pt-to-Pt and Frame-Relay).

* R1 will be configured with static routes to  R2 loopback to be identical out the Pt-to-Pt and Frame Relay network.

* Configure a backup interface on R1 whereby when the PVC to R2 is down, traffic should be rerouted out the Pt-to-Pt Serial Link.






Configuration:
R1:
ip route 2.2.2.0 255.255.255.0 Serial0/1
ip route 2.2.2.0 255.255.255.0 102.102.102.2
!
interface Serial0/0.1 point-to-point
 backup delay 4 30
 backup interface Serial0/1

Verification:
Interface s0/1 is in Standby Mode

 

On R2, after we shutdown interface serial 0/0 frame-relay interface and the PVC on R1 changes to INACTIVE, the line protocol state of Serial0/0.1 is down.  Four seconds later the backup interface is taken out of standby mode, and the new routing information is installed in the routing table.  Notice the backup link is activated 4 seconds after the main link fails. 

Understanding Proxy ARP and the difference between routing to an interface and routing to next-hop

When routing to an interface, the router performs layer 3 to 2 resolution on the final address.  When routing to a next-hop value, the router performs layer 3 to layer 2 resolution on the next-hop address.

In this lab, I will demonstrate the difference between routing to an interface and routing to a next-hop.

After performing a ping test to the Loopbacks, the ARP table is built.  Notice in the output of the ARP table, the 2.2.2.2 destination is in the ARP table, but the 1.1.1.1 is not in the ARP table.

This is because R3 directly ARP for the address 2.2.2.2.  Since R2 has Proxy ARP enabled by default on its interface connected to segment, it will respond to R3's ARP request with its own MAC address.


What if we disable Proxy ARP on R2's fa0/0 interface:

On R3, we will clear its ARP table ('clear arp' will not clear the table). Notice that 2.2.2.2 is cleared from the ARP table.

Now, when we try to ping 2.2.2.2, we get:

Verification:
debug arp
debug ip packet

Question now is:
1. Why is this important design-wise?
2. What are the alternate solutions?

Sometimes, we overlook the use of Proxy ARP

I was doing a lab to demonstrate proxy ARP.  I setup a topology the looks like the following:

After I have configured my static routes on R3 and verified reachability:

After running this command

I came to realize that I can't perform ARP on Point-to-Point serial links.

ARP applies to Multipoint Broadcast Interfaces.

Understanding Split-Horizon

This lab demonstrates split-horizon in effect.

Notice that R2 does not have all the routes.

Notice that R1, R2, R3, R5, R4 have all routes

R4 receives route updates from point to point serial interface.