Re: Ethernet card locking up when acting as virtual bridge
Am 2017-11-08 11:54, schrieb Andrew Wood:
My configuration is below. Initially it worked fine, except that once
in a while the card would seemingly 'lock up' i.e no VMs could get
network access but unplugging and replugging the Cat 5 cable fixed it.
Recently however the issue has been occuring more and more, sometimes
some VMs can get network access and not others. Ive tried swapping the
card for an identical model but its made no difference. Im not sure if
it something to do with my config (maybe the made up MAC addresses?)
or if its a bug in the cards driver or firmware.
Config is below eth0 is the hosts Realtek port, enp3s0 is the 3Com
used for the VMs
iface br1 inet dhcp
No idea if this is the problem or not, but you are using DHCP for the
bridge interface. Maybe the DHCP client's management of the bridge
interface interferes with this? (DHCP clients like to 'take over' an
interface and may set flags that don't work properly.) I don't think
I've ever used a DHCP client on a bridge before other than for short
testing purposes.
Is is possible for you to try a static IP on this interface and see
if that solves your problem?
If that doesn't help:
- The Linux bridge interface will always use the numerically lowest
(in a Big-Endian sense) MAC address that's configured as the MAC
address for the bridge. If you're doing virtualization, you
should stick to MAC addresses that are very high for this reason,
so that the network card's own address always wins out. Many
virtualization tools ensure that the MAC addresses they generate
start with 0xfe for this reason. (This might also confuse DHCP
clients btw. if the MAC address of the interface changes behind
their back.)
- When the problem occurs: do the VMs at least see each other? If
that doesn't even work, your problem isn't your network card,
but something else.
- Anything in the kernel log?
If not, is there maybe a debug option for your specific network
driver you could enable so that something is added to the logs?
- Try running 'ip l' and 'ip a' both when the problem occurs and
when it doesn't occur and see if there's any difference in the
output of either of these.
- You said that unplugging and replugging the cable made it work
again - maybe the link sensing between your network card and the
switch / whatever you have on the other side is broken for some
reason? Could you try to force the right speed / duplex settings
via ethtool and see if that helps?
- Maybe your network card supports various offloading features
(such as TCP checksums) but when used as a switch they don't
always work properly - you could try disabling them (also via
ethtool, see the manpage).
- You said that you've tried replacing the network card - have you
tried replacing the cable? I've had some weird experiences with
broken network cables. (For example, very strange intermittent
packet loss in some instances, which cause very weird effects in
higher-level protocols.)
Regards,
Christian
Reply to: