Losing outside connectivity sporadically

[adamsre_cisco]

Hello All,

I have an ASA5505, running 8.4(2) that periodically (4-5 times a day) will lose WAN connectivity.  The only things I've found that reset the interface is to either unplug the uplink to the provider router (G0/0 on a 1700 series router that I have no access to), or restarting my ASA.  This is in a remote location, so we have had to resort to a Netbooter device that will essentially cycle power on the ASA when the Netbooter is unable to ping a remote IP.

The setup is a fairly straight-forward setup with an IPSEC Lan-to-Lan VPN to our corporate office, and an SSLVPN connection to our other external entities.  I have verified with the provider that their interface is set to Auto/Auto, as is my interface.  I have also moved the interface from e0/0 down to e0/5 with no change in stability.  When external connectivity is lost, it appears as though internal connectivity maintains, however, it is tough to prove as all other devices run through a 2960G switch there on premisis, and really has no need to hit the ASA for what we use the other local devices for.

Something else to think about is that when connectivity seems severed, the provider's interface that our ASA plugs into (the ASA's gateway), appears to still respond to pings, oddly enough.  Only unplugging, and plugging back into that interface revives the connection (or rebooting the ASA). 

I have seen other articles suggesting MTU size (currently the default of 1500 on inside and outside).  I do see an unusual amount of switch ingress policy drops.   I can see no real discernable change upon trying several different settings.  I've also see it mentioned that using nat (any,any) can cause issues with xlates.  The most xlates I've seen at a given time were 13 - not at all like my 5510 at the corp office, where 600-750 is not at all uncommon (lots of varying ipsec L2L connections).

I am at a loss fighting with the provider to provide proof either way that it's the ASA, or it's the provider's router.  I have attached a sanitized "sh tech" to hopefully help you gurus help me

Does anyone have any suggestions how best to debug this so that I can better troubleshoot this?

Thanks!                  

[Kevin P Sheahan]

Hi Eddie,

I know it's a long shot depending on who your provider is but ask them if you can setup EIGRP between their router and your ASA. Make sure they know that you don't want to share any routes or anything like that but there are some advantages to doing this....

-Seeing as how the ASA is NOT a busy box, the link between your ASA and the provider's router may benefit from the hello packets and other exchanges that occur as part of EIGRP's normal behavior. These may act as keepalives for the link and if lack of traffic is what is affecting your link this should resolve the issue.

-Having EIGRP running between your ASA and the provider's router will greatly increase your debug options. You will be able to better tell when the link becomes unresponsive and which device (your ASA or the provider's router) is not sending or receiving.

Kind Regards,

Kevin

*Please rate helpful posts and remember to mark the question as answered once the issue is reolved. This will help others find the solution easier.

[adamsre_cisco]

Hey Kevin,

Thanks much for the creative thinking.  If I may throw this out there - this is actually a reasonably "busy" location, and doesn't sit idle for too long of a duration.  I think the longest this site may sit idle without transferring back to corporate, or my other central archive location, is approximately an hour - maybe two, at the most.  When it does transfer, it will be transferring roughly 250-300 MB of data on a 3 E-1 bundled circuit. 

There are times that it stays up for 5-6 hours without issue, and then others when it will only stay up for 20-25 minutes.  There is no real pattern that I can discern.  It doesn't seem to happen after a larger transfer, or if there have been no events on my servers to trigger a transfer.

It might be an idea to setup EIGRP - just for the hello traffic, but I'm not thinking I would be solving the underlying issue in doing so.  I do like your thought process on the debug option to see who is the offending partner in the EIGRP neighbor process.

Thanks!