I just connected a new Juniper SSG550 firewall to a new GB interface (with "T" media ) on my 3845 router, and noticed that the link would go down after 20 minutes. Oddly the link showed still up according to the status, but I couldn't get to the Juniper connected... the ARP entry was stale. Clearing the ARP cache would bring the link back up and all was fine...for another 20 minutes, then it would "de-ARP(?)" again.
I found a work around by setting the ARP timeout on the new GB interface to 30 seconds. This works, but it is the only interface that I've had to do it with. I have other GB interfaces, but they are running at 100MB and show no trouble with the default timeout of 4 hours.
So is there some weird standard that says 1000-base-T has a limit of 20 minutes for ARP reliability? Am I going crazy?
When the link's ARP goes away I cannot connect to the firewall for management...but all traffic through the firewall is fine, with exception of the VPN tunels which were built between the firewall's external interface (where the ARP is stale) and the remote data centers' firewalls.
The firewall logs didn't show the link down or anything wrong...other than the VPN tunnels being down - I was connecting to it from the inside as the address on the outside was de-ARPed. Doing some further studying, the ARP timeout on the Juniper/Netscreen firewalls is defaulted to 20 minutes, while the Cisco router is set for 4 hours. This would explain the 20 minute drop outs, and eventual 3 hour and 40 minute wait for the link to come back up on its own without the interaction of a "clear ARP" command on the router. What it doesn't explain is why it only is on this link, as there are 3 other links off of this same router that also go to Juniper/Netscreen firewalls. It is however the only truly GB link that is running with a PM-3387 universal module and a "T" form factor.
So just setting the Cisco's ARP timeout settings to be less than 20 minutes (or theoretically changing the firewall's to more than 4 hours) fixed the problem. I set the 3845 for 30 seconds, and everything is working flawlessly now with no additional strain on the almost sleeping (less than 2% CPU usage average) router. I just thought it was kind of weird since this has never happened to me before. Oh well, one for the books I guess
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...