Friday 18 April 2014

IP SLA Tracking configuration with Example (Auto Failover)


One company/branch may have two connections to the internet through 2 ISPs. If we want to use one connection as primary and other as backup, we can use IP SLA to monitor the link. It detects the link failure even if the connection between modem and ISP fails. So it helps to switch over to the backup path automatically as soon as the primary path is down.


In case if you want to divert sophisticated traffic like SAP, Mail and some other traffic though ISP 1 and Internet traffic through ISP 2 based on the availability of ISP links, 

We could use IP SLA with tracking object and PBR. Also other ISP will be acting as backup link for the mentioned traffics using normal routing configurations even if the primary ISP link goes down.

For example, I have taken a location which has 2 ISP links.Follow the below steps to achieve our objective.


Configuring IP SLA for ISP 1

Step 1: Creating SLA process

ip sla 13

icmp-echo 1.1.1.1 source-ip 1.1.1.2 (here we monitor ISP 1 link neighbor’s IP)

Note: There are some optional parameters available with IP SLA configuration which can really get more specific information.

Step 2: Scheduling SLA process

ip sla schedule 13 start-time now life forever

Step 3: Create a track object to track the change

track 13 ip sla 13 reachability

Once we have IP SLA up and running the next step is to configure PBR so we can redirect http traffic.
First, we need to use Access-Control Lists to select the traffic we want to redirect. Keep in mind that PBR does not limit the type of ACL that can be used. This means you can use IP named ACLs, standard ACLs, extended ACLs, time-based ACLs and others. In our example we are going to use IP named ACLs:

ip access-list extended TOKYO-TRAFFIC-ISP1

 permit ip 10.179.80.0 0.0.0.255 host 10.2.1.1

 permit ip 10.179.80.0 0.0.0.255 host 10.2.2.3

Now we must create a route-map that will use the above defined ACLs and instruct the router to redirect the traffic to the ISP 1 link:

Step 4: Route map creation

route-map TOKYO-KAND permit 10

 match ip address TOKYO-TRAFFIC-ISP1

 set ip next-hop verify-availability 1.1.1.1 1 track 13

The last command configures the route map to verify the reachability of the tracked object (1.1.1.1). If the tracked object is reachable (IP SLA reports it is reachable), then our policy-based route will redirect the defined traffic to it. If the tracked object is not reachable, (IP SLA reports the host is not reachable - down) then our policy-based route will stop redirecting traffic.

Step 5: Applying the Policy Based Route

We are almost done. The very last step is to enable and identify the route-map to be use for policy routing. This is performed by selecting the router interface for which the policy routing will be enabled, and applying the policy-route:
In our Tokyo location, Fa0/1 is the local lan interface.

interface FastEthernet0/1

ip policy route-map TOKYO-KAND

Now the same process can be followed for ISP 2 link also,

Configuring IP SLA for ISP 2

Step 1: Creating SLA process 

ip sla 14

icmp-echo 2.1.1.1 source-ip 2.1.1.2(here we monitor ISP 2 link neighbor’s IP)

Step2: Scheduling SLA process

ip sla schedule 14 start-time now life forever

Step3: Create a track object to track the change

track 13 ip sla 13 reachability

Allow the needed traffic through an ACL,

ip access-list extended TOKYO-TRAFFIC-ISP2

permit ip 10.179.80.0 0.0.1.255 host 10.2.1.3

permit ip 10.179.80.0 0.0.1.255 host 10.2.1.21

Step 4: Route map creation

route-map TOKYO-KAND permit 20

match ip address TOKYO-TRAFFIC-ISP2

set ip next-hop verify-availability 2.1.1.1 1 track 14


Step 5: Applying the Policy Based Route

interface FastEthernet0/1

ip policy route-map TOKYO-KAND

In the above configurations we could see that MAIL server traffic is forced to travel through ISP 1 link using source and based policy routing, It does not mean that mail server traffic will not flow if ISP 1 link goes down. Since we have standard IP routing ISP 2 link will be acting as secondary as always.

Troubleshooting and Verification commands:

For troubleshooting or to do see the status we can make use of following show commands.

show track 13

show route-map

show ip sla statistics

show ip sla configuration

PBR is used to overwrite the normal routing options. IP SLA and Track objects help us to track the links lively and to do the needed changes without manual intervention.

Hope you got it! Please post your doubts in comment box.. :) 


Share:

9 comments:

  1. hi Sentil, i read your post and find it interesting. by the way, what is the model of the router you use? --Glen

    ReplyDelete
  2. could you please show the ip addresses in figure

    ReplyDelete
  3. Useful, but really it needs IPs to be shown on the diagram....

    ReplyDelete
  4. This seems to be a real-world scenario, especially when the ISP-provided SLAs are not respected.
    thanks for posting.

    ReplyDelete
  5. ip access-list extended TOKYO-TRAFFIC-ISP1

    permit ip 10.179.80.0 0.0.0.255 host 10.2.1.1

    permit ip 10.179.80.0 0.0.0.255 host 10.2.2.3

    My Ques: If i am not wrong host 10.2.1.1 and 10.2.2.3 are ISP1 and ISP2 Peer IPs ?, please brief.

    ReplyDelete