IP SLA Question when target destination is a common IP

Dean Romanelli · ‎08-20-2015

Hi All,

I have a site with two WAN connections; 1 MPLS connection that is primary for VOIP traffic to the PBX at our VOIP provider's facility, and 1 Internet connection that is backup to the PBX at our VOIP provider's facility. I have a layer 3 switch between the two routers that goes out to each respective path. The PBX IP is 99.99.99.1, and I can ping it from both the MPLS cloud & the internet cloud when I initiate the ping from my core 3560 switch.

I am setting up IP SLA for automatic failover as per the config snipet in my attached drawing. My concern is as follows:

When the MPLS provider has an outage and 99.99.99.1 stops pinging through the MPLS path, the SLA will trigger to use the backup static route to reach 99.99.99.1 once more and keep the phones running. However, when that SLA failover occurs and 99.99.99.1 starts pinging again though the backup internet connection, will the SLA function see the reachability condition as being met again (since it pings now via internet) and try to fail back to the MPLS path, or does it only fail back if the target starts pinging via the route that has the track command appended to it (i.e. the primary route via the MPLS connection)?

Thanks in advance.

Martin Hruby · ‎08-21-2015

Hello Dean

I would recommend you reconfigure your IP SLA probe to ping with a specific source IP address and then configure local policy-based routing on the switch to always route these IP SLA probes out to your MPLS router. In my example below, FastEthernet0/0 is the interface on your Catalyst 3560 and it has the IP address 192.168.1.2. I create an access-list 100 to match the outgoing IP SLA probes and create a route-map PBR to offload this traffic to 192.168.1.1 (your MPLS router) regardless of routing table entry. For example:

ip sla 1
icmp-echo 99.99.99.1 source-interface FastEthernet0/0
frequency 10
ip sla schedule 100 life forever start-time now

access-list 100 permit icmp host 192.168.1.2 host 99.99.99.1

route-map PBR permit 10
match ip address 100
set ip next-hop 192.168.1.1

ip local policy route-map PBR

The above configuration will cause the router to always send the IP SLA probes to the MPLS router even if there's a route to 99.99.99.1/32 over your backup path.

Let us know if this works for you.

Best regards,
Martin

Dean Romanelli · ‎08-21-2015

Hi Martin,

I actually like that idea a lot, but unfortunately my switch does not have the source-interface command as an option. I tried to implement this last night but it kept failing over to the backup immediately and I think it is because I put the corresponding track command on multiple static routes. The example I drew up was a simplified version of what I have going on for the sake of the concept, but in actuality, there are 13 subnets belonging to our VOIP provider that I need to statically route our VOIP LAN subnet to over MPLS primary, and internet backup.

I set the SLA target to their PBX IP address, configured SLA & track statements and then I set 13 static routes and appended the corresponding track statement to all 13, which I think was the problem, as per below:

ip sla 2
icmp-echo 8.28.0.1
frequency 10

track 101 ip sla 2 reachability
delay down 10 up 20

ip sla schedule 2 life forever start-time now

ip route 8.5.248.0 255.255.255.0 192.168.1.1 track 101
ip route 8.5.249.0 255.255.255.0 192.168.1.1 track 101
ip route 8.28.0.0 255.255.255.0 192.168.1.1 track 101
ip route 8.28.1.0 255.255.255.0 192.168.1.1 track 101
ip route 8.28.2.0 255.255.255.0 192.168.1.1 track 101
ip route 8.28.3.0 255.255.255.0 192.168.1.1 track 101
ip route 63.209.12.0 255.255.255.0 192.168.1.1 track 101
ip route 162.221.236.0 255.255.254.0 192.168.1.1 track 101
ip route 162.221.238.0 255.255.254.0 192.168.1.1 track 101
ip route 192.84.16.0 255.255.255.0 192.168.1.1 track 101
ip route 192.84.17.0 255.255.255.0 192.168.1.1 track 101
ip route 192.84.18.0 255.255.255.0 192.168.1.1 track 101
ip route 192.84.19.0 255.255.255.0 192.168.1.1 track 101

ip route 8.5.248.0 255.255.255.0 192.168.2.1 251
ip route 8.5.249.0 255.255.255.0 192.168.2.1 251
ip route 8.28.0.0 255.255.255.0 192.168.2.1 251
ip route 8.28.1.0 255.255.255.0 192.168.2.1 251
ip route 8.28.2.0 255.255.255.0 192.168.2.1 251
ip route 8.28.3.0 255.255.255.0 192.168.2.1 251
ip route 63.209.12.0 255.255.255.0 192.168.2.1 251
ip route 162.221.236.0 255.255.254.0 192.168.2.1 251
ip route 162.221.238.0 255.255.254.0 192.168.2.1 251
ip route 192.84.16.0 255.255.255.0 192.168.2.1 251
ip route 192.84.17.0 255.255.255.0 192.168.2.1 251
ip route 192.84.18.0 255.255.255.0 192.168.2.1 251
ip route 192.84.19.0 255.255.255.0 192.168.2.1 251

So my theory in what went wrong, is that 8.28.0.1 is reachable via the static route "ip route 8.28.0.0 255.255.255.0 192.168.1.1 track 101" command, but those other 12 static routes cannot get to the 8.28.0.0/24 subnet because they point to different subnets which 8.28.0.1 does not live on, so the SLA failover condition is met on 12 of 13 tracked routes and that causes the fail-over.

If I am right in my theory, your solution gave me a few ideas I want to run by you if I may:

What if I did a combination of PBR & IP SLA but called the track command in the route-map instead of the static routes, like so: (NOTE: 192.168.1.0/24 is the VOIP LAN subnet)

access-list 100 permit ip 192.168.1.0 255.255.255.0 8.5.248.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 8.5.249.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 8.28.0.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 8.28.1.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 8.28.2.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 8.28.3.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 63.209.12.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 162.221.236.0 255.255.254.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 162.221.238.0 255.255.254.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 192.84.16.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 192.84.17.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 192.84.18.0 255.255.255.0
access-list 100 permit ip 192.168.1.0 255.255.255.0 192.84.19.0 255.255.255.0

ip sla 2
icmp-echo 8.28.0.1
frequency 10

track 101 ip sla 2 reachability
delay down 4 up 30

ip sla schedule 2 life forever start-time now

route-map VOIP-TRAFFIC permit 10
match ip address 100
set ip next-hop address 192.168.1.1 10 track 101
set ip next-hop address 192.168.2.1
route-map VOIP-TRAFFIC permit 20

interface range gi0/3 - 4
ip policy route-map VOIP-TRAFFIC
desc VOIP Phones

interface gi0/6
ip policy route-map VOIP-TRAFFIC
desc VOIP Phone

interface range gi0/13 - 16
ip policy route-map VOIP-TRAFFIC
desc VOIP Phones

interface gi0/18
ip policy route-map VOIP-TRAFFIC
desc VOIP Phone

int range gi0/22 - 23
ip policy route-map VOIP-TRAFFIC
desc VOIP Phone

int range gi0/25 - 28
ip policy route-map VOIP-TRAFFIC
description Access_Layer_LAN_Switches

ip local policy route-map VOIP-TRAFFIC

The only thing I am not certain of is whether or not I can apply the route-map to multiple interfaces. If I cannot, then this solution won't work either, as the traffic coming in from multiple access layer switches to the core switch needs to be PBR'd.