Load Sharing via Secondary Link - Part 2

Let's look at the routing behaviour from the reverse direction now i.e.R5 to R1

Traceroute shows

We can see that even if the outbound path from R1 for the destination 2.2.2.2 was R1-R2-R3-R4-R5, the return path is R5-R4-R2-R1 which means that it prefers the primary CPE for inbound routing. We have an asymmetric routing issue.

To resolve this problem, we can create a GRE tunnel between R3 and R5.

Both the tunnel s interfaces are up.

Now we can create a static route saying that Site A’s LAN subnet is reachable via tunnel interface.

Let’s do the traceroute again 

We can see that the return path is via the tunnel interface now.

What will happen if the WAN circuit on R3 goes down but the interface still remains up? In this instance, the track object on R2 won’t notice any failure and the traffic will still be routed to R3, creating the traffic black hole.

To overcome this issue, we can start tracking the tunnel IP instead of WAN interface IP. When the circuit goes down, the tunnel interface will stop receiving the keepalives from R5 which will cause the interface to go down. So let’s change the configuration on R2

Now let’s simulate the outage by creating a host route for 192.168.2.1/32 pointing to null 0.

We can see that the tunnel interface goes down however the WAN interface is still up/up. 

Now let’s do traceroute again

Traffic is now going through the primary link. Let’s remove the dummy static route and traffic should flow through the secondary link.

We have achieved the load-sharing via the secondary link. 

There may be other ways to achieve the same e.g. using BGP communities but it will require configuration changes on the PE. 

Before implementing this, one should keep in mind that PBR is process intensive and can increase the router's CPU load significantly. 

Again Feel free to comment/suggest.......