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: [email protected]
http://www.CustodianDC.com
Robert Williams
Backline / Operations Team
Custodian DataCentre
tel: +44 (0)1622 230382
email: [email protected]
http://www.custodiandc.com/disclaimer.txt
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
