Strange ip sla source-interface issue

[adventurer]

Hi,

I have a router with 2 internet connections.

ISP1 is through e0/2/0

ISP2 is through cel0/1/0

This config is in testing I have not applied the track to any route.

ip sla 1
icmp-echo x.x.x.1 source-interface Ethernet0/2/0
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 8.8.8.8 source-interface Ethernet0/2/0
frequency 10
ip sla schedule 2 life forever start-time now

track 1 ip sla 1 reachability
delay down 30 up 30
!
track 2 ip sla 2 reachability
delay down 30 up 30
!
track 12 list boolean or
object 1
object 2

Now I have ISP1 failure recently and the track doesn't behave what i expect.

When ISP1 failed,

Ethernet0/2/0 is up, line protocol is up, no DHCP IP address from the ISP1.

So I manually do a ip route 0.0.0.0 0.0.0.0 cel0/1/0 to restore Internet via ISP2.

Then I notice the track 1, 2, 12 all came back up.

What I think is the source-interface Ethernet0/2/0 command is not working, all those icmp-echo went through ISP2.

It can't have gone via ISP1, at that stage e/0/2/0 does not even have IP address.

Either there's something weird about source-interface that I don't understand, or could this be a bug ?

Regards.

[Georg Pauwen]

Hello,

which (default) route are you tracking ? Typically, with only two external connections, you would need just one IP SLA. Your boolean 'or' logic installs...what ? when either interface is down ? 

Post the full configuration of your router...

[paul driver]

Hello

---

@adventurer wrote:

Either there's something weird about source-interface that I don't understand, or could this be a bug ?

---

I wouldn't say so, however there looks like a problem with what you are trying to track, I can see at least one destination address is google dns, which would be reachable i guess from either ISP so when the first isp goes down 8.8.8.8 would still be reachable via the other hence the ip sla will still be active, I cannot comment on the other destination but i assume the same is occurring there.

You need to track addressing local to each ISP (like its next-hop or an address only reachable via that particular isp.

[adventurer]

x.x.x.1 is ISP1 next-hop

interface Ethernet0/2/0  <--- Interface to ISP1
ip address dhcp
ip nat outside
no negotiation auto
no cdp enable
end

interface Cellular0/1/0 <---- Interface to ISP2
ip address negotiated
ip nat outside
dialer in-band
dialer idle-timeout 0
dialer-group 1
pulse-time 1
end

ip route 0.0.0.0 0.0.0.0 dhcp

(To manually switch to ISP2, no the above line and ip route 0.0.0.0 0.0.0.0 cel0/1/0)

(I'll automate this once I sort out the ip sla)

ip sla 1
icmp-echo x.x.x.1 source-interface Ethernet0/2/0 <--- x.x.x.1 ISP1 next-hop
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 8.8.8.8 source-interface Ethernet0/2/0
frequency 10
ip sla schedule 2 life forever start-time now

track 1 ip sla 1 reachability
delay down 30 up 30
!
track 2 ip sla 2 reachability
delay down 30 up 30
!
track 12 list boolean or  <--- should be and
object 1
object 2

Ok my mistake here, boolean should be and, basically object 1 which is the ISP1 next-hop has anti DoS rule, which makes it not responding 100%. It means I have to track another object because can't just rely on it.

x.x.x.1 is pingable from anywhere / any Internet.

What I think happened is ip sla 1 ping went from e0/2/0 to cel0/1/0 then all the way into Internet and hit x.x.x.1

So the source-interface doesn't mean it can only travel out from e0/2/0

If this is the case then there's no way I can make this work. ISP1 does not have a next-hop address that can only be reached within ISP1.

[Georg Pauwen]

Hello,

with the boolean 'and' you need both SLAs to be down. It should not be possible for the source interface specified in the SLA to randomly change. What router is this on (real or lab) ?

Either way, the below should be sufficient:

ip sla 1
icmp-echo 8.8.8.8 source-interface Ethernet0/2/0
frequency 10
ip sla schedule 1 life forever start-time now

!

track 1 ip sla 1 reachability
delay down 30 up 30

!

ip route 0.0.0.0 0.0.0.0 Ethernet0/2/0 dhcp track 1
ip route 0.0.0.0 0.0.0.0 Cellular0/1/0 200

[adventurer]

---

@Georg Pauwen wrote:

Hello,

with the boolean 'and' you need both SLAs to be down. It should not be possible for the source interface specified in the SLA to randomly change. What router is this on (real or lab) ?

Either way, the below should be sufficient:

ip sla 1
icmp-echo 8.8.8.8 source-interface Ethernet0/2/0
frequency 10
ip sla schedule 1 life forever start-time now

!

track 1 ip sla 1 reachability
delay down 30 up 30

!

ip route 0.0.0.0 0.0.0.0 Ethernet0/2/0 dhcp track 1
ip route 0.0.0.0 0.0.0.0 Cellular0/1/0 200

---

It's on a real 4321 router. IOS 16.8.2

I think no point to just track 8.8.8.8 itself, because it will be reachable from either ISP1 or ISP2. So the track will be forever up (assuming google didn't fail), even when ISP1 is down.

[Georg Pauwen]

Did you actually try and implement this ? What is the result ?

[adventurer]

I'm currently testing with this, will know the result in a few days time, ISP1 has a scheduled outage happening.

ip sla 2
icmp-echo 8.8.8.8 source-interface Ethernet0/2/0
frequency 10
ip sla schedule 2 life forever start-time now

track 1 interface Ethernet0/2/0 ip routing
delay down 30 up 30
track 2 ip sla 2 reachability
delay down 30 up 30
track 12 list boolean and
object 1
object 2

[paul driver]

Hello

---

@adventurer wrote:

If this is the case then there's no way I can make this work. ISP1 does not have a next-hop address that can only be reached within ISP1.

---

You could also object track various ways including the interface state, line protocol or ip routing of the interface

May i ask the reasoning you are sourcing from the same interface for both ISP's - You should be souring from each isp directed interface as below

examples:

ip route 0.0.0.0 0.0.0.0 <int isp1>.dhcp track x
ip route 0.0.0.0 0.0.0.0 <int isp2> dhcp  200
with ipsla and track

or
track x interface xx line-protocol
track x interface xx ip routing

or

int xx
ip address dhcp
ip dhcp client route track x
with ipsla and track

[adventurer]

Well I already know track line protocol won't be accurate, because when ISP1 failed, e0/2/0 interface is up and line protocol is up.

Track ip routing is worth playing around with, I'll experiment with it and feedback is it any better. Thanks.

[paul driver]

Hello

You still have not answered why with IPSLA you are sourcing from the same interface for both isp's - what is the reasoning?

[adventurer]

I have already stated above why I have to use 2 tracks in a "boolean and" track. All of these are to monitor ISP1.

source-interface is set as e0/2/0 which is facing ISP1.

[Yury Kuzminov]

You don't need to create 2 IP SLA to switch the routing between two ISPs. Just create one entry to track something in Internet and add the track to prefferable ip route to ISP1 (wired, I guess) from interface going to ISP1. Add another ip route with high AD (250 as an example) to ISP2 (cellular). When ISP1 goes down, track deletes main route, and floating one will goes to routing table.

[Deepak Kumar]

Hi,

I agree with @paul driver and you had made some fundamental mistakes in the configuration or understanding the IP SLA. as No Track applied on the default or floating default route and why both SLAs are sourced a single interface?