[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.)


Reply to: