[c-nsp] Cat6500 odd arp behavior

[Phil Mayers]

On 01/25/2013 06:47 AM, Christian Meutes wrote:
> On Jan 24, 2013, at 7:01 PM, <Vinny_Abello at Dell.com> wrote:
>
>> Is there something that would prevent ARP from discovering these newly
>> added devices when the switch would be soliciting the network segment
>> for the MAC address for a certain IP? I was leaning towards bug... or I have
>> some unintended consequence due to the CoPP policy or rate-limiters on
>> these switches which are also the same.
>
> Unfortunately yes. Packets hitting missing ARP adjacency need to go through
> CoPP to trigger the discovery. Test it yourself: Allow them explicitely in your
> policy and it's going to work.

I agree, this is the most likely explanation. For example, if you have a 
CoPP policy which is "permit management stations; deny tcp port 22" then 
any attempt to SSH into a host not in the ARP table will fail - the TCP 
SYN port 22 will hit the CoPP limiter and be denied.

Disable your CoPP policy and re-test.

Locally, any CoPP "deny" statements are qualified with an ACL that 
contains the boxes local IPs / subnets containing only local IPs. This 
is tedious when you have SVIs, but is about the best you can do on this 
platform :o(

>
> Configure the "mls rate-limit unicast cef glean" h/w rate-limiter. That way
> packets hitting missing ARP adjacencies will only be addressed to the
> rate-limiter and not to CoPP anymore.
>
> Don't understand why it's not kind of default.

Unfortunately, because it's buggy. This has been discussed in the 
archives, but basically activating the "glean" limiter causes glean 
packets to match egress ACLs - see this (enormous) thread for more info:

https://puck.nether.net/pipermail/cisco-nsp/2010-March/069114.html