On Mon, May 02, 2022 at 03:42:05AM +0200, Gionatan Danti wrote:> Dear list, > I just discovered the hard way that if the lower lever physical interface of > a macvlan bridge is disconnected (ie: by unplugging the eth cable, resulting > in no carrier), inter-guest network traffic from all virtual machines bound > to the disconnected interface is dropped. > > This behavior surprises me, as with the classic bridges I can disconnect the > underlying physical interface without causing any harm to inter-guest > traffic. > > Am I doing something wrong, or this really is the expected behavior? If so, > can I force the macvtap interfaces to bridge traffic even when the > underlying physical interface is disconnected?Can you share the <interface> configuration for your guest NIC so we can see how it is setup. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 5/3/22 4:31 AM, Daniel P. Berrang? wrote:> On Mon, May 02, 2022 at 03:42:05AM +0200, Gionatan Danti wrote: >> Dear list, >> I just discovered the hard way that if the lower lever physical interface of >> a macvlan bridge is disconnected (ie: by unplugging the eth cable, resulting >> in no carrier), inter-guest network traffic from all virtual machines bound >> to the disconnected interface is dropped. >> >> This behavior surprises me, as with the classic bridges I can disconnect the >> underlying physical interface without causing any harm to inter-guest >> traffic. >> >> Am I doing something wrong, or this really is the expected behavior? If so, >> can I force the macvtap interfaces to bridge traffic even when the >> underlying physical interface is disconnected? > > Can you share the <interface> configuration for your guest NIC so we > can see how it is setup.I can't say that I've ever tried this, since my only reason for using macvtap is to provide the guests with direct connectivity to the physical network, and unplugging the physdev negates that. The behavior you describe doesn't surprise me all that much though, since the physical device in the case of a host bridge isn't an integral part of the bridge (it's just one more device attached to a port), while the physical device and macvlan bridge a much more closely associated. I'm Cc'ing Michael Tsirkin to see if he has more authoritative information on whether or not the macvtaps connected to a macvlan bridge can communicate amongst themselves when the physdev is disconnected. In the meantime, is there a reason you don't want to just use a standard host bridge that's not connected to any physdev? The one thing I can think of is that you might not want to allow communication between the host and guests, but as long as the bridge itself isn't given an IP address, that won't be possible (at least at the level of IP).
Il 2022-05-03 10:31 Daniel P. Berrang? ha scritto:> Can you share the <interface> configuration for your guest NIC so we > can see how it is setup.Here we go... <interface type='direct'> <mac address='xx:xx:xx:xx:xx:xx'/> <source dev='enp0s31f6' mode='bridge'/> <target dev='macvtap0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> # ifconfig Both the physical and macvtap interfaces are disconnected (note how RUNNING is missing): enp0s31f6: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xf4300000-f4320000 macvtap0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether xx:xx:xx:xx:xx:xx txqueuelen 500 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 # ip link 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 6: macvtap0 at enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 500 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff I can bring up the macvtap interface with the following command (notice the RUNNING/UP flag): # ip link set macvtap0 protodown off # ifconfig macvtap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::redacted prefixlen 64 scopeid 0x20<link> ether xx:xx:xx:xx:xx:xx txqueuelen 500 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 42 bytes 6001 (6.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 # ip link 6: macvtap0 at enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff However, at the next connection/disconnection of the physical link, the macvtap interface will go down again. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8