[c-nsp] Sup720 software forwarding

Tóth András diosbejgli at gmail.com
Mon Mar 11 15:03:43 EDT 2013


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 <peter at rathlev.dk> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list