OK, I have a little over a hundred servers equipped with Broadcom NICs plus
TEAMing (well, BASP in Broadcom-speak). I picked five, pointed my sniffer at
them, filtered for ARP queries which originated from their MAC addresses and for
which the sender IP address is *not* set to their actual IP address ...
Four of the five are incorrectly setting sender IP address to something other
than their own. In other words, four of the five are inflicting ARP cache
poisoning on their neighbors. [Intriguingly, all the 'poisoned' ARP Requests
are unicast ... thank goodness!]
I'm puzzled as to why my data center isn't flat on its face already. I suppose
the subset of end-stations being poisoned is small and not generally talking to
each other.
Have any tips for identifying pathological stations? Sniffing on every single
Broadcom box is going to be tedious ... I have 'arpwatch' running, but it only
records ARP responses; it doesn't "glean".
Any tips for engaging someone at Broadcom? [To identify which driver revisions
contain this bug?]
Thanx again for offering your insights.
--sk
Jason King wrote:
I would strongly recommend upgrading all the broadcom drivers and
teaming software as soon as you possibly can, or at minimum disable
the teaming software.
There is a nasty (understatement) bug where certain driver versions +
their teaming software causes random ARP cache poisioning on a subnet.
I ran into this at work, and others have hit it as well. I think the
profanities are still lingering in the air around here once I figured
out what's going on :) Updating to the latest drivers and and teaming
software should fix it, of course you need to do that for all of the
boxes on a given subnet before the problem goes away.
_______________________________________________
networking-discuss mailing list
[email protected]
