[c-nsp] ARP strangeness

[Rodney Dunn]

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