4

I want to set up a bridge so that guest VMs on my headless server use the LAN DHCP and not dnsmasq. I followed these instructions: https://jamielinux.com/docs/libvirt-networking-handbook/bridged-network.html#bridge-debian. Looking at the ifconfig results, it seems to give me exactly what I was looking for:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.210  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::4216:7eff:fe63:7516  prefixlen 64  scopeid 0x20<link>
        ether 40:16:7e:63:75:16  txqueuelen 1000  (Ethernet)
        RX packets 8255  bytes 653898 (653.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 633  bytes 60185 (60.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.195  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 40:16:7e:63:75:16  txqueuelen 1000  (Ethernet)
        RX packets 42190  bytes 48646124 (48.6 MB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 9808  bytes 889965 (889.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2215  bytes 510180 (510.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2215  bytes 510180 (510.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:7a:ca:5e  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

However, if I try to SSH into my server (192.168.1.195) from another machine (192.168.1.196), I can't connect. Pings from the server can't seem to reach other devices on my LAN, but pings from the server to 8.8.8.8 seem to work OK. My /etc/network/interfaces file looks like the below (the MAC is my server's NIC):

iface enp3s0 inet manual

auto br0
iface br0 inet static
    # Use the MAC address identified above.
    hwaddress ether 40:16:7e:63:75:16
    address 192.168.1.210
    netmask 255.255.255.0
    gateway 192.168.1.1

    bridge_ports enp3s0
    # If you want to turn on Spanning Tree Protocol, ask your hosting
    # provider first as it may conflict with their network.
    bridge_stp on
    # If STP is off, set to 0. If STP is on, set to 2 (or greater).
    bridge_fd 0

I've spent the last two days googling, and re-imaged my server a couple of times as well when things got too broken, and I think I'm just losing the plot... My server is Ubuntu 18.04.2, completely stock other than the libvirt and ssh packages installed. How can I get the server to be reachable by my other network machines?

Adam Mac
  • 181
  • 6
  • What happens if you try to ssh to the bridge address? 192.168.1.210 in your case. Once the enp3s0 port is bound to the bridge it shouldn't have/need its own address unless you're doing something like configuring sub-interfaces. – RobertRSeattle Apr 15 '19 at 02:12
  • did you modify your vm definitions to use the bridge? See step 2, here. – Doug Smythies Apr 15 '19 at 16:20
  • 1
    Thanks for the quick replies, guys! Yes, I can access 192.168.1.210 from my Windows machine using Putty. Sorry - I should have checked before posting. HOWEVER, I've lost access to filesharing (mapped network drive no longer works), and apps running on the server have problems getting to the internet. About ready to throw this thing out the window :) – Adam Mac Apr 16 '19 at 00:21
  • 1
    I'm still trying to get to a point where my server sits on 192.168.1.195 and my VM guest is on the same subnet, say 192.168.1.210. And where both the server and the VM are visible to my Windows machine 192.168.1.196. Have run out of hair to pull out. – Adam Mac Apr 16 '19 at 00:36

2 Answers2

4

Sometimes it pays to just leave things alone for a day or two and not look at them. Then come back to it fresh. In the end, setting up a bridge seemed to be fairly straightforward, with the following two steps:

  1. Update /etc/sysctl.conf

Uncomment the line that says ".net.ipv4.ip_forward=1"

  1. Update /etc/network/interfaces

For me, this was the entirety of the file. If you have more interfaces, you may want to adjust accordingly. enp3s0 was the ID of my physical interface.

# ifupdown has been replaced by netplan(5) on this system.  See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
#    sudo apt install ifupdown
iface enp3s0 inet manual

auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
   bridge_ports enp3s0
   bridge_stp off
   bridge_fd 0
   bridge_maxwait 0

I used an IP address reservation in my router to make sure my VM always got the same IP address. Using DHCP made configuration overall a bit easier for me.

Thanks again to RobertRSeattle and Doug Smythies for putting up with me.

Adam Mac
  • 181
  • 6
0

I had a working bridge that went down. I tried everything. Went on a witch hunt looking for docker files thinking docker had destroyed my networking. It turned out that the network interface name within the guest had a change of heart and enp1s0 became enp7s0. fixed the /etc/netplan yaml and everything is back.

Adam Felson
  • 79
  • 1
  • 3