[c-nsp] All multicast punting to CPU on 6500

Phil Mayers p.mayers at imperial.ac.uk
Sun Dec 16 07:38:55 EST 2012


On 12/16/2012 11:59 AM, Robert Williams wrote:
> Hi, I'll try to go into some additional detail on the traffic and
> other router config elements now.
>
> The traffic is basically made up of a randomly generated packet which
> is almost identical to the below.

Yuck.

Essentially, this is a malformed packet and I'm not surprised it's 
hitting the CPU ("it's multicast" / "it's not multicast") and causing 
problems.

Basically "don't do that".

> As such there is no multicast configuration. In fact, if anything it
> would be ideal if the box dropped all multicast traffic apart from
> the HSRP/VRRP to be honest.

You might be able to write a MAC ACL which drops all multicast frames.

>
> The reason I think this may be causing issues is because it is
> destined to a non-multicast IP, but with a multicast MAC....?

Very likely.

> The situation arose in the real world when a Windows NLB cluster went

Wait, so this isn't the "real" problem traffic? You're testing?

> offline and there was a load of traffic heading to its shared IPv4
> address ('not' a multicast IP, but 'is' a multicast MAC) - so the
> switch flooded to all ports, including the 6500 upstream, triggering
> high CPU.

Well known problem. Microsoft NLB is broken by design. Don't use it.

Not the most helpful answer I know, but honestly, any work you do 
"fixing" this is better spent on supplanting MS NLB (e.g. install a 
couple of Linux boxes using haproxy as SLB-on-the-cheap).

IIRC people who *do* use MS NLB often have to install static ARP / FDB 
entries to "stick" the output frames and get around just these sorts of 
problems.

That said - I'm sympathetic to the general problem of "device collapsed 
under external load and I want to secure it from happening again". But 
bear in mind the age of the sup720/Earl7 architecture and its 
limitations (e.g. CoPP and multicast/ipv6). You might find a sup2t can 
be made more resistant to this kind of thing - but then again, you might 
not. State of the art in control-plane resilience to unusual traffic is 
not great IME :o(

Cheers,
Phil


More information about the cisco-nsp mailing list