Uploaded image for project: 'Funtoo Linux'
  1. Funtoo Linux
  2. FL-8295

app-emulation/lxd: messes up default route on system

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • CatPkg:
      app-emulation/lxd

      Description

      I reproduced this with the current lxd-3 in the tree as well. The reproduction steps are:

      1. On a desktop Funtoo laptop with GNOME and NetworkManager running, and you're on a WiFi network...
      2. Install lxd and configure it to set up a bridge (lxdbr0)
      3. Start /etc/init.d/lxd (this triggers the bug)

      What will then happen is that lxd will configure a default route for the bridge which will route all Internet traffic to the bridge. The NetworkManager icon will change from "WiFi" to "Ethernet connection" and network will not work, as lxdbr0 does not have a device on it with Internet access.

      Bridge configuration:

      config:
        ipv4.address: 10.132.238.1/24
        ipv4.nat: "true"
        ipv6.address: fd42:4c42:7c61:b77::1/64
        ipv6.nat: "true"
      description: ""
      name: lxdbr0
      type: bridge
      used_by:
      - /1.0/instances/bugs-upgrade
      managed: true
      status: Created
      locations:
      - none 

      Routing table:

      valkyrie /home/drobbins # route -n
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
      0.0.0.0         10.132.238.1    0.0.0.0         UG    100    0        0 vethb2c28ed3
      0.0.0.0         192.168.43.1    0.0.0.0         UG    600    0        0 wlan1
      10.132.238.0    0.0.0.0         255.255.255.0   U     0      0        0 lxdbr0
      10.132.238.0    0.0.0.0         255.255.255.0   U     100    0        0 vethb2c28ed3
      127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
      192.168.43.0    0.0.0.0         255.255.255.0   U     600    0        0 wlan1 

      I am pointing to the first route in the list – which is a default route sending all traffic to the veth interface – as the problem. It overrides the second default route that already existed on the system (and is what I am using for WiFi). 

      Workaround:

      route del -net 0.0.0.0 gw 10.132.238.1 

      I have not tested if this impacts container functionality.

       

       

       

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              drobbins drobbins
              Reporter:
              drobbins drobbins
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: