In today's network environment, redundancy is one of the most important aspects, whether its on the LAN side or on the WAN side. In this topic we will be covering WAN redundancy with multiple WAN links terminating on a single router.
The best and simplest way to achieve WAN redundancy on Cisco devices is to use Reliable Static backup routes with IP SLA tracking.
IP SLAs is a feature included in the Cisco IOS Software that can allow administrators the ability to Analyze IP Service Levels for IP applications and services. IP SLA's uses active traffic-monitoring technology to monitor continuous traffic on the network. This is a reliable method in measuring over head network performance. Cisco Routers provide IP SLA Responders that give accuracy of measured data across a network.
With IP SLAs, routers and switches perform periodic measurements. The number and type of available measurements are vast and in this article we will be covering just the ICMP ECHO feature. IP SLA in itself is a very big topic to cover.
Users interested can head to our Cisco Routers section where they can find a number of articles covering IP SLA configuration on Cisco routers.
Let us take an example of a basic redundant WAN link scenario as shown below:
In the above figure the Cisco device is connected to two WAN links ISP1 and ISP2. The most common setup that we use in day to day life is to have to default routes configured on the Cisco router pointing to the respective next hop IPs as shown below:
R1(config)# ip route 0.0.0.0 0.0.0.0 188.8.131.52
R1(config)# ip route 0.0.0.0 0.0.0.0 184.108.40.206 10
If you notice the Administrative Distance for the secondary route pointing to ISP2 is increased to 10 so that it becomes the backup link.
The above configuration with just two floating static routes partially accomplishes our requirement as it will work only in the scenario where the routers interfaces connected to the WAN link are in up/down or down/down status. But in a lot of situations we see that even though the links remain up but we are not able to reach the gateway, this usually happens when the issue is at the ISP side.
In such scenarios, IP SLAs becomes an engineer's best friend. With around six additional IOS commands we can have a more reliable automatic failover environment.
Using IP SLA the Cisco IOS gets the ability to use Internet Control Message Protocol (ICMP) pings to identify when a WAN link goes down at the remote end and hence allows the initiation of a backup connection from an alternative port. The Reliable Static Routing Backup using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure.
IP SLA is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network or your next-hop IP on the ISP's router. The pings are routed from the primary interface only. Following a sample configuration of IP SLA to generate icmp ping targeted at the ISP1s next-hop IP.
R1(config)# ip sla 1
R1(config)# icmp-echo 220.127.116.11 source-interface FastEthernet0/0
R1(config)# timeout 1000
R1(config)# threshold 2
R1(config)# frequency 3
R1(config)# ip sla schedule 1 life forever start-time now
Please note that the Cisco IP SLA commands have changed from IOS to IOS to know the exact command for IOS check the Cisco documentation. The above commands are for IOS 12.4(4)T, 15.(0)1M, and later releases.
The above configuration defines and starts an IP SLA probe.
The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 18.104.22.168 every 3 seconds, as defined by the “frequency” parameter.
Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet.
Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.
After defining the IP SLA operation our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:
R1(config)# track 1 ip sla 1 reachability
The above command will track the state of the IP SLA operation. If there are no ping responses from the next-hop IP the track will go down and it will come up when the ip sla operation starts receiving ping response.
To verify the track status use the use the show track command as shown below:
R1# show track
IP SLA 1 reachability
Reachability is Down
1 change, last change 00:03:19
Latest operation return code: Unknown
The above output shows that the track status is down. Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes.
Different operations may have different return-code values, so only values common to all operation types are used. The below table shows the track states as per the IP SLA return code.
OK or over threshold
(all other return codes)
The Last step in the IP SLA Reliable Static Route configuration is to add the track statement to the default routes pointing to the ISP routers as shown below:
R1(config)# ip route 0.0.0.0 0.0.0.0 22.214.171.124 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 126.96.36.199 10
The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up. Hence if the track status is down the secondary route will be used to forward all the traffic.
If you would like to learn how to configure IP SLA Tracking with Policy-Based Routing to automatically redirect specific type of traffic to other gateways or hosts, visit our Configuring Policy-Based Routing (PBR) with IP SLA Tracking - Auto Redirecting Traffic article.