[c-nsp] ARP strangeness

Wed Jan 5 08:30:50 EST 2011

On 1/5/11 1:55 AM, Frank Bulk - iName.com wrote:
> 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.
>

Yes.

> 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.
>

Right. Idea being if no traffic is flowing the unicast arp would keep 
the entry from aging out on the L2 switches.

Rodney

> 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/
>
>
> _______________________________________________
> 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/