|
|
I am struggling with a Broadcom NetXtreme BCM5703X NIC that continues
to respond to arp requests for an IP address it no longer has (in
addition to its current address). Obviously this causes problems for
the machine that has that address.
The machine changed addresses because we swapped disks between two
machines, *not* because we reconfigured the NIC settings. After
replacing the original disks, there are *no* traces of the other
configuration.
We see that both machines are responding to arp requests:
[gordon]# tcpdump arp and host 172.16.3.232
16:31:48.787845 arp who-has 172.16.26.19 tell 172.16.3.232
16:31:48.788018 arp reply 172.16.26.19 is-at 00:09:3d:10:fb:1a
16:31:48.788141 arp reply 172.16.26.19 is-at 00:09:3d:10:89:df
The second of the above replies is the correct one. This is what
"ifconfig -a" on the offending machine reports:
eth0 Link encap:Ethernet HWaddr 00:09:3D:10:FB:1A
inet addr:172.16.26.12 Bcast:172.16.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7305 errors:0 dropped:0 overruns:0 frame:0
TX packets:240 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2673055 (2.5 MiB) TX bytes:30570 (29.8 KiB)
Interrupt:5
eth1 Link encap:Ethernet HWaddr 00:09:3D:10:FB:1B
inet addr:192.168.84.1 Bcast:192.168.84.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:1024 (1024.0 b)
Interrupt:3
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1584 errors:0 dropped:0 overruns:0 frame:0
TX packets:1584 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1773116 (1.6 MiB) TX bytes:1773116 (1.6 MiB)
I am at a loss to explain this behaviour. AFAICT it should not be
possible unless the NIC itself answers arp requests without help from
the OS, and has retained some state from the previous configuration.
We are using the tg3 driver (v3.10) that comes with Fedora Core 3.
During its short stint as 172.16.26.19 we had also tested a recent
driver from Broadcom (bcm5700-89.1.55), which I'm worried left some
state behind on the NIC.
Can someone suggest a way to get this NIC to "forget" the old address?
Unfortunately it's onboard, so pulling it out isn't really an option.
Turning off the machine only solves the problem until we turn it back
on again...
/gordon
--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
|
|