On 1/4/11 11:43 PM, Jeff Kell wrote:
On 1/4/2011 9:01 PM, Rodney Dunn wrote:
There were some changes to ARP at one point to provide some more
triggered capability. I don't recall exactly what that was but the
default behavior for many years was that we send a unicast arp to the
destination 60 seconds prior to the arp timer set to expire. If we
don't get a response we send it again when the timer pops and if no
response we invalidate the ARP entry.
Umm, that sort of rocks my boat with regard to network monitoring
assumptions...
We have one of those NMS systems that periodically "reads L2 devices for
mac-address/port mapping" and "reads L3 devices ARP for mac-to-IP
mapping". Ideally, there should be no missing links (if the MAC is
found, hopefully the ARP/IP is found, and vice-versa).
That still holds true as long as a timer (sam cam ager) didn't pop
sooner than your arp refresh timer.
For the default mac-address aging time of 300 seconds, I had this notion
that setting the ARP timeouts to 270 seconds would necessitate the
router ARPing the device (assuming active traffic) prior to the
mac-address aging out, keeping the mac-address table populated.
Keep the other timers 60+ seconds out to be safe.
But if the Cisco L3 behavior is to gratuitously do this for me before
the ARP timeout... that changes things a bit.
Is this default behavior across all the Cats, or just the 6500/7600? Is
it supervisor-specific?
Traditionally generic to all of IOS. There may have been some platform
specific thing that changed here that I have missed in the last couple
of years though.
Rodney
Jeff
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
