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

[Robert Williams]

Hi, thanks for the feedback:

> 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".

I'd love to :) but the standard is the standard for NLB unfortunately - the kit is client's kit and I can't make them change it.

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

Actually working on that now... will let you know how it goes.

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

No but it's very similar because the real problem came up when an attack was initiated against the client's NLB cluster. It was taken offline and the traffic had nowhere to go, except the whole LAN segment. Plus because it was unsolicited traffic it didn’t just 'stop' when the cluster went down.

> 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).

Again, can't really do that as it's not ours, but I'll mention it.

> 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.

Unfortunately, even if I arp-sticky it on the 6500 that doesn't help limit which ports it gets flooded to. Unless the client's switch can control that (it's a 3C 4800G, I'll do some digging).

> 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(

I'd be curious to know if anyone with a 2T can confirm if this vulnerability exists still?

Cheers as always!


Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com


Robert Williams
Backline / Operations Team
Custodian DataCentre
tel: +44 (0)1622 230382
email: Robert at CustodianDC.com
http://www.custodiandc.com/disclaimer.txt