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.. :)
hi Sentil, i read your post and find it interesting. by the way, what is the model of the router you use? --Glen
ReplyDeleteFor this post, I used 2800 in GNS3
Deletecould you please show the ip addresses in figure
ReplyDeleteUseful, but really it needs IPs to be shown on the diagram....
ReplyDeleteThis seems to be a real-world scenario, especially when the ISP-provided SLAs are not respected.
ReplyDeletethanks for posting.
ip access-list extended TOKYO-TRAFFIC-ISP1
ReplyDeletepermit 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.
maraş
ReplyDeletebursa
tokat
uşak
samsun
F8UF
salt likit
ReplyDeletesalt likit
dr mood likit
big boss likit
dl likit
dark likit
JWWG7M
salt likit
ReplyDeletesalt likit
FNQ
مكافحة الحشرات بالاحساء kiByqNvzIi
ReplyDelete