jernst
11-20-07, 02:18 PM
This is about the "dual NVIDIA Gigabit Ethernet" that's on the abit KN9 SLI motherboard. Running under Debian Etch 2.6.18-5-xen-amd64.
Summary: if the eth1 interface is not talked to for some period of time, it forgets the IP address that was assigned to it. It will only remember once a broadcast message is sent (such as an ARP lookup on that IP address). (eth0 is Firewire on this motherboard, we haven't tried with eth2)
Longer version: It was started by the following observation/problem. The box runs several XEN virtual machines. If XEN dom0 is not being talked to for some time (happens often, it is only used for XEN administration), it fails to respond to any and all network traffic that isn't originating on the local subnet. However, it does respond to local traffic, AFTER WHICH is responds to remote traffic as well and continues responding as long as it is being talked to continuously. Hours worth of packet-level debugging led to the observation that the ARP lookup wakes it back up from non-responsive mode.
The really funny thing about is that while all DOM0 and DOMU run over the same physical ethernet card, DOMUs that are active continue to work well, while the DOM0 goes silent. (And vice versa, any DOMU might go silent while DOM0 stays up) The Linux kernel never sees incoming packets. So the problem is somewhere between the card and the kernel.
Any ideas?
Summary: if the eth1 interface is not talked to for some period of time, it forgets the IP address that was assigned to it. It will only remember once a broadcast message is sent (such as an ARP lookup on that IP address). (eth0 is Firewire on this motherboard, we haven't tried with eth2)
Longer version: It was started by the following observation/problem. The box runs several XEN virtual machines. If XEN dom0 is not being talked to for some time (happens often, it is only used for XEN administration), it fails to respond to any and all network traffic that isn't originating on the local subnet. However, it does respond to local traffic, AFTER WHICH is responds to remote traffic as well and continues responding as long as it is being talked to continuously. Hours worth of packet-level debugging led to the observation that the ARP lookup wakes it back up from non-responsive mode.
The really funny thing about is that while all DOM0 and DOMU run over the same physical ethernet card, DOMUs that are active continue to work well, while the DOM0 goes silent. (And vice versa, any DOMU might go silent while DOM0 stays up) The Linux kernel never sees incoming packets. So the problem is somewhere between the card and the kernel.
Any ideas?