Load balance and IP SLA tracking

[Mohammad Ramadan A.Hafiez]

Hello,

I have a scenario here and I hope anyone can help.

I have tow internet lines both are connected as shown in the snapshot attached.

I use tow default routes to load balance clients connections through these two internet lines "ADSL".

to detect the failed path to one of these internet lines, I use track and IP SLA ech to check the path through these default routes so that if any SLA fail the track will eliminate the route from the routing table untill it back again "as long as SLA can reach the destined echo".

the problem is that these tow default routes are the routes used by the SLA ech, hence if the connection to one of any internet line is down, the route will go down as intended but as long as the routes is not exist, the SLA keep failing and will stay down.

any ideas how to solve this...

__________Partial config____________

track 1 ip sla 1 reachability
!
track 2 ip sla 2 reachability
!
!
!
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.0
duplex half
!
interface FastEthernet1/0
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 192.168.3.1 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip dns server
ip route 0.0.0.0 0.0.0.0 192.168.2.2 track 1
ip route 0.0.0.0 0.0.0.0 192.168.3.2 track 2
!
ip sla 1
icmp-echo 1.1.1.1 source-interface FastEthernet1/0
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.2 source-interface FastEthernet1/1
ip sla schedule 2 life forever start-time now
logging esm config

___________________________________________

TIA

[balaji.bandi]

Look at the below guide to help you and understanding :

https://community.cisco.com/t5/networking-documents/dual-internet-links-nating-with-pbr-and-ip-sla/ta-p/3126275

[Georg Pauwen]

Hello,

if these are both ADSL line, there should be a syslog message being logged when one line goes down. You could have an EEM script that reacts to the syslog message and installs/removes the default route for the respective ADSL link. Below is a sample config. You need to match the syslog pattern in the EEM scripts with what you actually see in your syslog (show log):

track 1 ip sla 1 reachability
track 2 ip sla 2 reachability
!
interface Dialer0
description Link to ISP_1
!
interface Dialer1
description Link to ISP_2
!
ip route 0.0.0.0 0.0.0.0 Dialer0
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip sla 1
icmp-echo 8.8.8.8 source-interface Dialer0
frequency 5
!
ip sla 2
icmp-echo 8.8.8.8 source-interface Dialer1
frequency 5

!

ip sla schedule 1 start-time now life forever
ip sla schedule 2 start-time now life forever
!
event manager applet DIALER0_DOWN
event syslog pattern "Line protocol on interface Dialer0, changed state to down"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 Dialer0"
action 4.0 cli command "end"
action 5.0 cli command "clear ip nat translation *"
!
event manager applet DIALER0_UP
event syslog pattern "Line protocol on interface Dialer0, changed state to up"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "ip route 0.0.0.0 0.0.0.0 Dialer0"
action 4.0 cli command "end"
action 5.0 cli command "clear ip nat translation *"
!
event manager applet DIALER1_DOWN
event syslog pattern "Line protocol on interface Dialer1, changed state to down"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 Dialer1"
action 4.0 cli command "end"
action 5.0 cli command "clear ip nat translation *"
!
event manager applet DIALER1_UP
event syslog pattern "Line protocol on interface Dialer1, changed state to up"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "ip route 0.0.0.0 0.0.0.0 Dialer1"
action 4.0 cli command "end"
action 5.0 cli command "clear ip nat translation *"

[Mohammad Ramadan A.Hafiez · Accepted solution]

Solved by using using a static routes for both SLA Probs' to guarantee their availability. 

[Georg Pauwen]

Hello,

out of curiosity, what does the full configuration you have finally used look like ? I only got this to work with installing the host routes below, because without those, both SLAs would fail all the time (probably because of the load balancing).

ip route 1.1.1.1 255.255.255.255 192.168.2.2

ip route 1.1.1.1 255.255.255.255 192.168.3.2 200

ip route 4.2.2.2 255.255.255.255 192.168.3.2

ip route 4.2.2.2 255.255.255.25 192.168.2.2 200

[Mohammad Ramadan A.Hafiez]

About the full configuration and topology, check the post up, all mentioned in details.

and regarding what have accomplished my target...

plus the two default routes that are tracked, I had to add another two routes to lead to my SLA's detinations 4.2.2.2 and 4.2.2.1 that are used in the sla for checking the reachability but these routes are not attached to any tracks, ie...both routes always installed in the route table.

the purpose of these added routes is to guarantee the path to these SLA destinations, even if any default route were omitted due to track down, the path is guarantee for the SLA probe so if the reply received, this will keep the default route up of this ISP .

Thank you