[c-nsp] ARP strangeness

[Frank Bulk]

Thanks for explaining.  

Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP RENEW
and DHCP DISCOVER, and because the access gear blocks all broadcast traffic,
the 7609-S will never (re-)populate its ARP entry.  

I'm going to see if the Linksys BEFRS41 has a configurable ARP expiration
timer.  If so, dropping it to 10 minutes would cause it to unicast ARP for
the default gateway, which would resolve the issue.

Another possible option, I guess, is to extend the 7609-S ARP expiration to
a longer time interval, but if the BEFRS41 is silent for even a second
longer than the ARP timer, then I'm still stuck.  

I should really look at the behavior of other CPE to see how often they
unicast ARP.

Frank

-----Original Message-----
From: Rodney Dunn [mailto:rodunn at cisco.com] 
Sent: Monday, January 10, 2011 1:30 PM
To: frnkblk at iname.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

It only gets updated on getting and ARP packet from the host.

It is not updated based on L3 data level traffic flowing to/from the host.

Rodney



On 1/10/11 11:43 AM, Frank Bulk wrote:
> Does the ARP cache get populated, or updated, if the traffic comes into an
> L3 interface, or is it only populated upon a successful ARP response?
>
> Frank
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rodney Dunn
> Sent: Wednesday, January 05, 2011 7:38 AM
> To: Jeff Kell
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ARP strangeness
>
> 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/