ARP weirdness ?

Unanswered Question
Dec 30th, 2009
User Badges:

Hello


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?


Can someone explain this.


Anyone?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
milan.kulik Thu, 12/31/2009 - 00:48
User Badges:
  • Red, 2250 points or more

Hi,


it looks like some IOS bug. Which IOS version are you running?


Another possibility would be some incompatibility with your Juniper.

Have you tried to look into the FW log - might be dropping something?

"I couldn't get to the Juniper connected" - what about the traffic through the FW, was it OK, or also not passing?

Or have you tried to stw the speed to 100Mbps to check if it's really a Gigabit problem only?


HTH,

Milan

a-hepworth Thu, 12/31/2009 - 16:10
User Badges:

The IOS is 12.3(11)T2.


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

Actions

This Discussion