ML Starkey's Weblog: Service with a smile!
Providing Technical Support to Sun's customers and other topics

Solaris 10 8/07 (a.k.a. Update 4) contains full support for RFCs 826 and 3927 meaning it will no longer ignore arp info off the wire that is incorrect. Introduce a Broadcom NIC driver on a PC configured as "teamed" that likes to send out bogus arps, and the fun begins.

See the opensolaris.org discussion here.

If you have Solaris 10 Update 4 machines experiencing intermittent hangs or inability to communicate, only to clear up and re-occur, time to rule this in or out. It's pretty easy to identify if you are running into this:

for example:

capture "netstat -p" to a file when communication is normal and then again when the communication is hung, (but not yet recovered). A diff will show you this:

# diff /tmp/netstat_p4_working /tmp/netstat_p4_notworking

< e1000g0 123.45.67.100 255.255.255.255 00:14:4f:2d:6c:86
> e1000g0 123.45.67.100 255.255.255.255 00:15:17:3d:bc:2c

If you find incorrect MACs, they will most likely start with an Intel or Dell vendor code. Those intrusive MACs will belong to a PC using a Broadcom NIC in "teamed" mode. (The opensolaris discussion link above has a snapshot of this in Ethereal.)

Solaris will conform to RFC 3927 and will "defend" it addresses. When that happens, the problem will resolve. Until the next time the teamed NIC interfaces send out bogus info. As an immediate workaround, unconfigure "nic teaming" on the affected Windows interfaces. Contact your PC vendor for an updated driver.