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-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Abello, Vinny Sent: Friday, January 25, 2013 4:16 PM To: p.may...@imperial.ac.uk; cisco-nsp@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-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Friday, January 25, 2013 6:10 AM To: cisco-nsp@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_abe...@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@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/ _______________________________________________ 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/
