10-19-2013 10:13 AM - edited 03-11-2019 07:53 PM
Hi All,
We have a strange problem with a PIX 515E running 8.0 (4).
BACKGROUND
The Pix is configured with two ISP connections, primary and secondary. We use a simple SLA monitor to check for reachability of the ISP 1 gateway, if this goes down ISP 2 comes up and internet is restored. In addition there are a few site to site VPNs terminating on the Pix and some ad hoc dynamic VPN connections.
PROBLEM
When the primary ISP 1 failed the other day all was well and the Pix transferred to ISP 2 almost in a heartbeat as it is supposed to do. The site to site VPN also changed over without an issue. However, when the primary ISP came back up the secondary route did not clear down in the routing table as evidenced by the "sh route" output. Furthermore the site to site VPN remained connected to the secondary connection. We cleared this fault by doing a simple "shut" and "no shut" on the secondary interface.
Has anyone any idea why this is happening ?
Thanks.
10-25-2013 04:14 PM
I need a number to reach you, I think I need to take a look at it!!
10-25-2013 04:48 PM
I would suggest is to remove the SLA monitoring configuration and then try to reach the addresses that you are using for monitoring, if they are not reachable and you remove the line that I told you to remove then the ISP is blocking ICMP or you have some other configuration that is conflicting with the ICMP portion that we might resolve if you send me the packet-tracer that I requested.
Please check with a packet-tracer how the PIX would consider to route to that destine address from a LOCAL address (PC).
packet-tracer input inside icmp
10-28-2013 06:08 PM
Do you still need assistance?
10-29-2013 02:11 PM
Hi Jumora,
Yes we are still troubleshooting this issue but I have been tied up on a big VPN build recently.
I think this issue maybe a routing one and I need to go through the config line by line. This is assumed because for some reason the routing table is not flushing when ISP 1 comes back up, which I know is triggered by the track command but could be something unrelated as you have said. Both routes are static so it should all be fine. The AD is also correct with 1 for ISP 1 and 254 for ISP 2.
Just to clarify the ping results. The SLA monitor is sending pings to the ISP 1 gateway, if this goes down and therefore is not reachable ISP 2 comes into to play, all good so far. Then when ISP 1 comes back up and is therefore reachable by a simple ping, it should then put the ISP 1 route back in the routing table, which is not happening.
I have not had time as yet to run packet tracer as the system is in a live network.
Any more thoughts ?
10-30-2013 11:31 AM
We can progress as soon as you can get me the packet-tracer, I think it is key to resolving this issue.
10-31-2013 10:48 AM
If this persist after confirming that the SLA monitored IP address is available and packet tracer does not demonstrate anything I would suggest to upgrade to interim release as I have not found a bug but this could be an issue with the code.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide