[c-nsp] Cat6500 odd arp behavior

[Vinny_Abello at Dell.com]

I read through that original long thread... It seems that the "mls rate-limit unicast cef glean" might be the appropriate workaround for me in my environment to bypass CoPP. I do not have outbound acl's on the input interfaces of the switch in this role, so I don't think I'd be affected by anything negatively. My only issue is I saw one post stating there were other issues stated by Cisco using this, but there was no further elaboration on this.

-Vinny

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Abello, Vinny
Sent: Friday, January 25, 2013 4:16 PM
To: p.mayers at imperial.ac.uk; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cat6500 odd arp behavior

If I'm understanding this properly, it seems that CoPP completely breaks the arp mechanism when using the 6500 for layer 3 routing. To effectively fix this, I'd basically have to open my CoPP policy to all potential IP traffic going to destinations on any SVI that would trigger an ARP discovery for something not in the ARP table of the switch?

If that's correct, I cannot imagine modifying my CoPP access-lists every time a new SVI or subnet was added or removed from an SVI just to make ARP function properly... and the "mls rate-limit unicast cef glean" setting is just another example of the confusion on how to properly secure this platform and what works and what doesn't, and by experienced and smart people I might add. It almost seems more sane to forget about CoPP, just use the basic security features of the switch along with the hardware rate-limiters. I must be missing something... I'm dreading having to add a process for people who turn up new SVI's to modify the CoPP policies on the switch.

Is there a crafty way to author the access-lists to protect the switch while still permitting arp to function to destination SVI's? I suppose I could just add all of my aggregate networks as destinations to my CoPP policy to be permitted, so if they're ever added on an SVI, arp would function right. I'm trying to take modifying CoPP access-lists out of the equation on a constant basis if that's even possible.

Am I understanding the issue correctly?

-Vinny

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: Friday, January 25, 2013 6:10 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cat6500 odd arp behavior

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