[c-nsp] ARP strangeness

[Frank Bulk - iName.com]

Jared:

Thanks.  We're running 12.2(33)SRE2, which is pretty recent.  I could only
hope that those CEF-MFI re-writes made it in the SR code line.

As mentioned in the original post, the CAM timers are 540 seconds, and
that's because Cisco documentation says it should be longer than the ARP
time, which I have set to 480 seconds.

Frank

-----Original Message-----
From: Jared Mauch [mailto:jared at puck.nether.net]
Sent: Tuesday, January 04, 2011 9:35 PM
To: frnkblk at iname.com
Cc: 'Keegan Holley'; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

One thing to watch out for is the 6500/7600 (aka 76k) has the SUP and the
MFSC that may have independent arp/mac/cam information that can also be out
of sync.

Depending on your layer-2 topology, software version, etc.. it's also
possible that large numbers of MACs out a single interface can cause
troubles as well (we've seen TFIB tracebacks due to arp timer churn in the
SXF code creating duplicate cef events).

A lot of this is better in newer code, eg: SXI5 (post cef-mfi rewrite that
appeared in SXH).

If you are doing layer-2 vlans at all, check your cam timers, eg:

Router#sh mac-address-table aging-time
Vlan    Aging Time
----    ----------
Global  300
no vlan age other than global age configured

These may also be causing the troubles you are seeing.  You may want to
increase these timers to keep the SUP and MFSC aging closer to in-sync.

- Jared

On Jan 3, 2011, at 11:13 PM, Frank Bulk - iName.com wrote:

> The 7609 does stop ARPing after receiving a reply from the CPE, but the
7609
> ARPs again 7 minutes later.  One person told me off-list that Cisco
doesn't
> expire an ARP entry before checking its ARP entries by doing an ARP
request.
> Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP
> the host one minute before expiration.
>
> Because the FTTH product has its own smart-L2 implementation with a MAC
> address expiration time of 7 minutes, it won't forward directed or
broadcast
> ARP requests from the 7609 once the CPE's MAC address has expired from the
> FTTH's MAC table.  Once the CPE goes deaf, even a full DHCP exchange
doesn't
> "wake up" the connection.  Only power-cycling the BEFRS41 resolves the
> issue.  The difference between a power cycle and a full DHCP exchange is
> that the BEFSR41 does an ARP request for the default router (7609) after
the
> DHCP exchange.
>
> I've extended the MAC address expiration time of the FTTH link to 15
minutes
> (two times the 7 minutes plus 1 minute) and we'll see how that goes.
>
> Frank
>
> -----Original Message-----
> From: Keegan Holley [mailto:keegan.holley at sungard.com]
> Sent: Monday, January 03, 2011 7:14 PM
> To: <frnkblk at iname.com>
> Cc: <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ARP strangeness
>
> The 7600 should stop arping if it has gotten a reply.  What happens when
you
> ping your test CPE both from the router and from another node behind it?
> You can also run he command sh ip cef exact-match to see what the router
is
> doing with a specific source-destination ip pair. If nothing strange pops
up
> then it's probably a bug.
>
> Sent from my iPhone
>
> On Jan 3, 2011, at 12:58 PM, Frank Bulk <frnkblk at iname.com> wrote:
>
>> We have over a thousand FTTH customers hanging off a VLAN on our 7609-S
>> running 12.2SRE3.  Those who have Linksys BEFRS41 (wired-only routers)
are
>> complaining about lack of Internet access after many hours or days of
idle
>> time (not using their PC or other devices).  Those who have Linksys
WRT54G
>> (wireless) have no complaints (my guess is that they're sending packets
> out
>> regularly).
>>
>> We replicated this in our CO and put a hub between the ONT and the
Linksys
>> CPE so that we could capture those packets.  What we're seeing in that
>> capture are directed ARP requests every 7 minutes from the 7609 to the
>> Linksys with an ARP response from the Linksys.  After many hours, the
> 7609-S
>> stops sending the ARP requests (well, at least we're not seeing it come
> in,
>> perhaps it did try).
>>
>> We currently have our ARP timeout set to 480 seconds and MAC address
table
>> aging time to 540 seconds.  Why?  We use "mac-address-table synchronize"
>> which is set to 160 seconds by default.  The recommendation from that
>> command is to set ARP three times that, so that would be 480.  But it's
> also
>> recommended that the MAC address table aging time be greater than the ARP
>> timeout, so we added another 60 seconds on top.
>>
>> Two questions:
>> - why is the 7609 sending any directed ARP requests at all, every 7
> minutes?
>> - why does it appear to stop sending them after many hours?
>>
>> I'm all ears if we should be using different expiration values, but the
>> numbers I'm using are based on reading a lot of cisco-nsp archives and
> Cisco
>> tech articles.
>>
>> Frank
>>
>> _______________________________________________
>> 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/
>>
>
>
> _______________________________________________
> 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/