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]
