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. On Thu, Aug 13, 2009 at 1:22 PM, Stuart Kendrick<[email protected]> wrote: > Yes > > Many > > Why? > > --sk > > Jason King wrote: >> >> Do you by any chance have boxes running Windows with broadcom NICs and >> are using their teaming software? >> >> On Thu, Aug 13, 2009 at 7:58 AM, Stuart Kendrick<[email protected]> >> wrote: >>> >>> Ahh. I've been staring at a lot of ARP frames these last few days. But >>> I >>> hadn't thought through this. >>> >>> I see three classes of ARP gleaning, all of them rely on the entry >>> already >>> existing in Solaris' cache, per your point. >>> >>> (1) Remote station emits a gratuitous broadcast ARP: Solaris updates its >>> cache >>> (2) Remote station emits a gratuitous unicast ARP: Solaris updates its >>> cache >>> (3) Remote station emits an ARP Request for the Solaris box's address: >>> Solaris >>> responds *and* uses the information in the ARP Request to update its >>> cache >>> >>> #3 is where I'm encountering confused machines: the source IP address in >>> these ARP Requests is accurate, but the source MAC address is not. >>> >>> And I can see how failover schemes might use any or all of these >>> techniques >>> to propagate a change in their IP address <==> MAC address mappings. >>> Dang. >>> I don't see a way to harden against this, at the host level, not without >>> getting into static ARP mappings, which looks like a swamp to me. >>> >>> Thanx for the explanation, >>> >>> --sk >>> >>> Peter Memishian wrote: >>>> >>>> > Is there a way to disable ARP gleaning under Solaris? >>>> >>>> Solaris will not track the ARP mappings for random on-link hosts -- the >>>> IP >>>> address will need to already be in its cache for some reason. My guess >>>> would be that the Solaris box was already communicating with 10.1.2.9 >>>> and >>>> then got the bogus ARP packet from 10.1.2.3 and dutifully updated its >>>> cache with the bogus information. There's really nothing Solaris can do >>>> about this case -- it is core to many failover technologies that Solaris >>>> updates its ARP cache in this situation. >>>> >>>> > I have broken end-stations which emit confused ARP responses, mixing >>>> up >>>> their > MAC addresses with other end-stations' IP addresses. >>>> > > e.g. >>>> > Sender MAC address: 00:11:22:33:44:55 (correct) >>>> > Sender IP address: 10.1.2.9 (INCORRECT) >>>> > Target MAC address: 00:aa:bb:cc:dd:ee >>>> > Target IP address: 10.1.2.20 >>>> > > In this case, the sender's actual IP address is, say, 10.1.2.3, >>>> *NOT* 10.1.2.9. > 10.1.2.9 in fact belongs to a legitimate >>>> end-station. >>>> But not this one. > Solaris gleans the IP address / MAC address >>>> mapping >>>> from watching this traffic, > updates its ARP cache with this incorrect >>>> entry ... and then starts addressing > frames to 10.1.2.9 using MAC >>>> address >>>> 00:11:22:33:44:55 ... and this of course > doesn't work too well. >>>> > > I have a number of these confused boxes, and I am gradually >>>> hunting >>>> them down. > In the meantime, I'm wanting to harden my Solaris boxes >>>> against gleaning these > addresses. Actually, even once I've cleaned >>>> up my >>>> confused end-stations, I'd > like to harden Solaris against this kind >>>> of >>>> experience ... this smells like a > classic man-in-the-middle >>>> vulnerability >>>> to me. If Solaris wants a MAC address, > let it ARP for it ... I don't >>>> want it trying to save a little work by gleaning. >>>> >>> _______________________________________________ >>> networking-discuss mailing list >>> [email protected] >>> > _______________________________________________ networking-discuss mailing list [email protected]
