Frank,

Maybe you could put it in a timeline for me as i think I'm still missing what exactly is failing. Sorry, a bit slow the last few days.

The 7600 should send a *unicast* arp to every entry in it's arp cache 60 seconds prior to what you have the arp timer set to. It will then send another just at the arp timer expiring *if* it didn't get a response to the first one.

So if your arp timer on the 7600 is low enough it should keep L2 mac forwarding state alive on all transit devices out to the CPE no?

Broadcast is only sent when the L2 mapping isn't known.

Rodney




On 1/10/11 5:27 PM, Frank Bulk wrote:
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:rod...@cisco.com]
Sent: Monday, January 10, 2011 1:30 PM
To: frnk...@iname.com
Cc: cisco-nsp@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-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rodney Dunn
Sent: Wednesday, January 05, 2011 7:38 AM
To: Jeff Kell
Cc: cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
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/

Reply via email to