Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

IP SLA icmp-echo issue on Cisco 3750

Hello All,

Have a very peculiar issue with IP SLA. Firstly, the architecture.

1) There are two sites - A & B. Both have their own internet connection.

2) Sites A & B are connected via MPLS.

3) Both sites have the below topology.

3750 CORE --> FIREWALL -->ROUTER ---> INTERNET

4) 3750 has a Default route pointing to firewall .

5) MPLS router is connected to 3750. A default information is originated via BGP to MPLS at each location. So that default route is learnt as a backup path from any location if it has to lose its local internet.

6) IP SLA has been configured at each location to track the default route using icmp-echo to hit a public IP (i.e 4.2.2.2 as an example).

Issue

-----

ICMP probes from Site-A via its local internet fails abruptly. I can reach the public IP mentioned above from my firewall pretty fine, but not from my 3750. Whenever i remove the tracking from the static default route & push in the plain default route without tracking, it works fine. Again, if i add the tracking back, it will work fine for an hour or so & then fails back again. To my bad, Site-B had recently gone offline due to some natural calamity. So, there is no other path for internet.

My config looks pretty simple

track 10 ip sla 1 reachability

!

ip sla 1

icmp-echo 4.2.2.2 source-ip 10.1.254.1

frequency 180

ip sla schedule 1 life forever start-time now

ip sla enable reaction-alerts

!

ip route 0.0.0.0 0.0.0.0 10.1.254.1 track 10

Don't know if i am doing something wrong, but feels to me like i have run into bug, may be? I am running IOS version 12.2(53)SE2 (IPservices images). Please help me.

Thanks in advance,

Vivek

1 ACCEPTED SOLUTION

Accepted Solutions

IP SLA icmp-echo issue on Cisco 3750

Vivek,

Can you just add one Host route for 4.2.2.2 towards the Firewall as permanent route so that even IP SLA tracking does not use the backup default route and creates more issue. So just add:

ip route 4.2.2.2 255.255.255.255 10.1.254.1 permanent

Also can you tell me when the Tracking goes down i.e when you are not able to ping 4.2.2.2 from the switch, what do you see in the routing table for 4.2.2.2 and for 0.0.0.0? Test this scenario with the above host specific route added, see if that makes a difference or not.

If you still see the same problem, then please post the output of the following commands:

- sh ip route

- sh ip sla stat

- sh track

- ping 10.1.254.1

- ping 4.2.2.2

- trace 4.2.2.2

- If your firewall is Cisco ASA/PIX, issue the command "sh xlate" and "sh nat" to see if NAT translation is happening properly for the traffic going towards 4.2.2.2 on the firewall or not

3 REPLIES

IP SLA icmp-echo issue on Cisco 3750

Vivek,

You have pointed your Primary default route towards the hop : 10.1.254.1

so how can you create an icmp probe with this same ip 10.1.254.1 as source in the IP SLA config. This is not owned by the Switch, I am assuming that this is Firewall's inside interface ip.

Don't use source-ip, use source-interface instead and use the vlan interface which has this 10.1.254.0 subnet.

Hope it helps.

Neeraj

IP SLA icmp-echo issue on Cisco 3750

Neeraj,

Good catch ! There was a typo. The source-ip i have configured is 10.1.254.2 on my switch. Firewall interface IP is : 10.1.254.1.

IP SLA icmp-echo issue on Cisco 3750

Vivek,

Can you just add one Host route for 4.2.2.2 towards the Firewall as permanent route so that even IP SLA tracking does not use the backup default route and creates more issue. So just add:

ip route 4.2.2.2 255.255.255.255 10.1.254.1 permanent

Also can you tell me when the Tracking goes down i.e when you are not able to ping 4.2.2.2 from the switch, what do you see in the routing table for 4.2.2.2 and for 0.0.0.0? Test this scenario with the above host specific route added, see if that makes a difference or not.

If you still see the same problem, then please post the output of the following commands:

- sh ip route

- sh ip sla stat

- sh track

- ping 10.1.254.1

- ping 4.2.2.2

- trace 4.2.2.2

- If your firewall is Cisco ASA/PIX, issue the command "sh xlate" and "sh nat" to see if NAT translation is happening properly for the traffic going towards 4.2.2.2 on the firewall or not

717
Views
0
Helpful
3
Replies
CreatePlease to create content