Hi Peter, MAC learning is fully hardware based on 6500 Sup720, therefore even if it's flapping it will not cause packets to be software switched, nor CPU usage to increase due to learning.
Did you rectify the MAC flapping issue? If so, did you see an improvement with those flows, i.e. did they disappear from ibc/netdr and the CPU usage went down? Any traces of warnings in the logs? Any resources exhausted? "sh pla ha ca" might reveal it. Best regards, Andras On Mon, Mar 11, 2013 at 7:18 AM, Peter Rathlev <[email protected]> wrote: > On Sat, 2013-03-09 at 04:15 -0600, William McCall wrote: > > On 03/08/2013 09:57 AM, Peter Rathlev wrote: > > > Is there a way to rate-limit this kind of punting? Standard "mls > > > rate-limit" doesn't seem to have anything useful, unless I'm just too > > > tired to see it. > > > > Looks like CoPP might do it in this case (I want to be more certain, but > > time constraints make it prohibitive to lab up right now). > > We'll try that in a test-setup. The device in question was actually > using a CoPP profile but not a very strict one. We tried disabling it > and saw no improvement, but that was of course expected. :-) > > If the punting is only for logging then discarding the packets is okay. > > But if they need to be software forwarded it's worse. The MAC flapping > was the only hint that something was wrong, and I had not expected MAC > flapping to make a Sup720 punt packets. If CoPP would discard traffic > I'd rather have the sup forward what it can until I can find a fix. > > -- > Peter > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
