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 I 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 I will be covering just the ICMP ECHO feature. IP SLA in itself is a very big topic to cover J
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 2.2.2.2
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 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 2.2.2.2 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
R1(config)# icmp-echo 2.2.2.2 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
The above configuration defines and starts an IP SLA probe.
The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 2.2.2.2 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
Track 1
IP SLA 1 reachability
Reachability is Down
1 change, last change 00:03:19
Latest operation return code: Unknown
Track 1
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.
Tracking | Return Code | Track State |
Reachability | OK or over threshold (all other return codes) | Up Down |
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 2.2.2.2 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 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.
No comments:
Post a Comment