Why does host and bridge get an IP but not the virtual machine?

Question

I'm struggling to connect my KVM virtual machine to the local network.

$ brctl show br0
bridge name    bridge id            STP enabled    interfaces
br0            8000.4c5262097e59    yes            enp0s31f6
                                                   vnet0

enp0s31f6 is the hosts' ethenet card and vnet0 that of the KVM guest.

On the host, I have full network connectivity. No problems.

On the vm, I have no network connectivity at all:

$ping 8.8.8.8
connect: Network is unreachable

So I'm trying to figure out what is worng. Already here, I'm puzzled because I thought that a bridge is the equivalent of a hardware switch and if this is so, how can one device plugged into the switch reach the network but not the other?

Let's look at their IP addresses:

$ ip a show enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 4c:52:62:09:7e:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 brd 192.168.1.255 scope global enp0s31f6
       valid_lft forever preferred_lft forever
$ ip a show vnet0
26: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:f0:0e:f8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fef0:ef8/64 scope link 
       valid_lft forever preferred_lft forever

So, the host has an IP 192.168.1.4 but the vm doesn't (except for an IPv6, no idea why).

The host received it's IP from the DHCP server on the LAN:

sudo dhclient -v enp0s31f6
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s31f6/4c:52:62:09:7e:59
Sending on   LPF/enp0s31f6/4c:52:62:09:7e:59
Sending on   Socket/fallback
DHCPREQUEST of 192.168.1.4 on enp0s31f6 to 255.255.255.255 port 67 (xid=0x64e68ab1)
DHCPACK of 192.168.1.4 from 192.168.1.1
RTNETLINK answers: File exists
bound to 192.168.1.4 -- renewal in 40526 seconds.

So let's try to get one for the vm too:

$ sudo dhclient -v vnet0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/vnet0/fe:54:00:f0:0e:f8
Sending on   LPF/vnet0/fe:54:00:f0:0e:f8
Sending on   Socket/fallback
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 3 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 3 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 7 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 13 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 14 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 18 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 10 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 15 (xid=0xf64429)
DHCPDISCOVER on vnet0 to 255.255.255.255 port 67 interval 18 (xid=0xf64429)
^C

It doesn't get one. :-(

So maybe the bridge is broken and the host still gets an IP because it is physically connected to the LAN? No, because the bridge itself does seem to talk the DHCP server too:

$ sudo dhclient -v br0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/br0/4c:52:62:09:7e:59
Sending on   LPF/br0/4c:52:62:09:7e:59
Sending on   Socket/fallback
DHCPREQUEST of 192.168.1.4 on br0 to 255.255.255.255 port 67 (xid=0x58c2333c)
DHCPACK of 192.168.1.4 from 192.168.1.1
RTNETLINK answers: File exists
bound to 192.168.1.4 -- renewal in 42819 seconds.

How do I continue from here?

(Feels like I have tried an checked just about everything, but I'm sparing you the information about that here as I'm now trying to systematically identify where I'm going wrong in the above steps.)

I read your question a few times. Read your old question a few times. I think, but am not sure, you are sometimes confusing vnet0 of your host with network stuff in your quest. i get similar to you for several of your example commands, and my VM is on my LAN fine. My problem with trying to help, is that I do not use netplan. I'll try to write an answer, but it will take awhile, and might be more "try this" than a real answer. — Doug Smythies, Mar 05 '20 at 16:11
@DougSmythies I think, in order to get to the bottom of this, netplan needs to be part of the picture: when I disabled netplan and switched back to /etc/network/interfaces everything worked. — Christoph, Mar 06 '20 at 22:12
Similar problem on fedora turned out to be the firewall, despite it not being obvious why — pmc, Jul 15 '20 at 06:16

score 0 · Answer 1 · answered Mar 06 '20 at 02:19

I am not an expert, but I think STP should be disabled in your bridge. It is disabled in mine. I don't have any ip address on my network interface list, the host ip address shows on the br0 interface:

doug@s15:~/idle/k56wtteo/idle$ ip a show enp3s0
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether f4:6d:04:65:2d:8e brd ff:ff:ff:ff:ff:ff
doug@s15:~/idle/k56wtteo/idle$ ip a show br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f4:6d:04:65:2d:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.112/24 brd 192.168.111.255 scope global dynamic br0
       valid_lft 84590sec preferred_lft 84590sec

However, by bridge stuff does look like yours:

doug@s15:~/idle/k56wtteo/idle$ brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.f46d04652d8e       no              enp3s0
                                                        vnet0

Does your VM definition specify to use the bridged interface? Example (/etc/libvirt/qemu/serv-ff.xml in this example (I think I read somewhere that you are using kvm)):

<interface type='bridge'>
  <mac address='52:54:00:27:1b:4e'/>
  <source bridge='br0'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

If I look at the arp table of the my LAN i can see the VM:

doug@DOUG-64:~$ arp | grep serv-ff
serv-ff.smythies.com     ether   52:54:00:27:1b:4e   C                     enp2s0

And if I set tcpdump on the host monitoring the bridge interface, I can observe the VM quest ask for and get an IP address from my LAN via DHCP upon quest re-boot:

doug@s15:~/idle/k56wtteo/idle$ sudo tcpdump -tttt -n -i br0 port 67 and port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2020-03-05 18:12:35.522302 IP 192.168.111.217.68 > 192.168.111.1.67: BOOTP/DHCP, Request from 52:54:00:27:1b:4e, length 265
2020-03-05 18:12:48.534782 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:27:1b:4e, length 291
2020-03-05 18:12:48.535118 IP 192.168.111.1.67 > 192.168.111.217.68: BOOTP/DHCP, Reply, length 300
2020-03-05 18:12:48.535243 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:27:1b:4e, length 303
2020-03-05 18:12:48.535460 IP 192.168.111.1.67 > 192.168.111.217.68: BOOTP/DHCP, Reply, length 300

And on the VM itself:

doug@serv-ff:~$ ip a show ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:27:1b:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.217/24 brd 192.168.111.255 scope global dynamic ens3
       valid_lft 86044sec preferred_lft 86044sec
    inet6 fe80::5054:ff:fe27:1b4e/64 scope link
       valid_lft forever preferred_lft forever

I appreciate your efforts. I cannot to any further tests as I disabled netplan and switched back to /etc/network/interfaces which solved the problem. But I would still like to understand why - under netplan - it was possible for one machine to reach the network but not the other, even though they're connected to the same bridge. So I'll answer questions as best as I can. — Christoph, Mar 06 '20 at 22:17
Regarding STP: I tried both on and off and I believe it didn't work either way. But when I switched to ifup/ifdown I also turned STP off, so you might be right that it was part of the problem. — Christoph, Mar 06 '20 at 22:21

Why does host and bridge get an IP but not the virtual machine?

1 Answers1