Load balancing through two NAT connections is now partially possible with the use of some tricky configurations within Cisco IOS running on integrated services routers. I recently was tasked with configuring this scenario and found that Cisco has documented a way of doing this.
Although their guide describes this process in enough detail to fit a lot of different situations, I felt it would be useful to revisit the configuration process in hopes of helping other people facing similar requirements and for my own documentation purposes.
Everything in this article was used specifically with a Cisco 1811 router running 12.4(24)T2 Advanced IP Services software, however the majority of this guide should work with any recent integrated service router with advanced IP services.
This example describes a router that has one DHCP-configured interface to one ISP and one static address to another ISP, each on different WAN interfaces of this router. You should configure policy-based routing will be configured for specific or secure traffic (such as HTTPS, SSH, etc) to ensure that it always uses one ISP connection. Fail-over redundancy will also be configured in the event one of these connections become unavailable. This configuration also assumes the interfaces and NAT has already been configured for each connection.
Specify the desired object tracking timer for interfaces in seconds. I used 5 as did the Cisco documentation:
track timer interface 5
Next create new tracked SLA objects – one for each of the ISP connections, and add desired delay change notifications in seconds:
track 100 ip sla 1 reachability
delay down 15 up 10
track 200 ip sla 2 reachability
delay down 15 up 10
For an interface running DHCP, route tracking can be enabled with the following interface configuration command:
ip dhcp client route track 100
*Where 100 is the desired tracking object number created above
Modify the static IP default route entry for the static IP connection to be tracked:
ip route 0.0.0.0 0.0.0.0 interface FastEthernet1 [next hop] 254 track 200
The digits in orange signify the metric for this static route. Since the DHCP learned route has a metric of 254, I set this static default route with the same metric so that equal-cost load balancing could be achieved. The red digits should match the desired object track number we created earlier.
Next configure an OER tracking entry to monitor each ISP connection. The
icmp-echo line can be a difficult choice. It is important to identify an address to ping that is reachable only through that connection. With the addition of the
source-interface line referencing an outside interface with a global address, I do not believe this to be an issue in the majority of topologies as the echo reply would never make it back the device, however I have not had sufficient time to experiment with this case to see how this works in reality.
ip sla 1
icmp-echo 172.31.100.1 source-interface FastEthernet0
ip sla 2
icmp-echo 172.31.200.1 source-interface FastEthernet1
Schedule the new SLAs for start time and duration:
ip sla schedule 1 life forever start-time now
ip sla schedule 2 life forever start-time now
Tacked on to the route-maps configured to allow NAT, I added an additional permit sequence that set the next hop based on availability:
route-map NET1 permit 10
match ip address NETWORK1
set ip next-hop verify-availability [primary route] 10 track 100
set ip next-hop verify-availability [secondary route] 20 track 200
route-map NET2 permit 10
match ip address NETWORK2
set ip next-hop verify-availability [primary route] 10 track 200
set ip next-hop verify-availability [secondary route] 20 track 100
This will set specify which router should be primary for each network. In this case I set each network’s primary route to a different connection in an effort to spread the load but still ensure both networks work in the event either ISP connection were to fail.
So now that load-balancing has somewhat been configured on the device, it is time to talk about the feasibility. The one point to take away from this is that it is not true load-balancing even if there are two equal default routes to choose. This is because the nature of NAT will force the session on to one of the two connections. My suggestion is to use this but limit the subnets to use one primarily and the other for backup, alternating the networks between the two WAN connections. In the end, this is what I did and has been a wonderful solution overall.