neutron-linuxbridge-agent flat network incompatibility with systemd-networkd

Bug #2004179 reported by Jan Graichen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
New
Low
Unassigned

Bug Description

We are running an OpenStack installation from Ubuntu's Cloud Archive, and our computer hosts have their network configured with systemd-networkd. For example, a bond and several VLANs on top, including two VLANs used for OpenStack flat networks. We are using neutron-linuxbridge-agent, i.e. no OVS or OVN.

Network interface overview:

     ┌──────┐ ┌──────┐ ┌──────┐
     │ eno2 │ │ eno3 │ │ eno4 │
     └───┬──┘ └───┬──┘ └───┬──┘
         │ │ │
     ┌───┴────────┴────────┴──┐
     │ bond0 │
     └─┬───────┬─────────┬────┘
       │ │ │
   ┌───┴──┐ ┌──┴───┐ ┌───┴────┐
   │ tnet │ │ stor │ │ public │
   └──────┘ └──────┘ └────────┘

The "public" network is a flat provider network (VLAN) that shall be used by neutron-linuxbridge-agent and nova-compute to attach to virtual machines. "tnet" is used for VXLAN overlay networks, and "stor" for Ceph. The issue is with "public" only.

The systemd-networkd configuration sets up all interfaces. We previously used netplan, but missing some needed options. It does use systemd-networkd too, so no relevant change to the problem.

Since merging https://github.com/systemd/systemd/pull/17392, systemd-network will remove the master flag from the "public" interface, that neutron-linuxbridge-agent assigned to the bridge for the network, e.g. brq88363244-5f, breaking all network on the flat network.

The fix was revered in bug #1929560, but the behavior will not be reverted in newer releases. Therefore, every reload of systemd-networkd will remove the physical network interface from neutrons bridge.

Using "bridge_mappings" with nova-compute has never been finished, according to bug #1105488. nova-compute always requires the dynamic bridge, e.g. brq88363244-5f, to be present.

@ddstreet asked for a new bug and the network configuration:

    # /etc/systemd/network/10-eno1.network:
    [..]

    # /etc/systemd/network/10-eno2.network:
    [Match]
    Name=eno2

    [Network]
    LinkLocalAddressing=no
    Bond=bond0

    # /etc/systemd/network/10-eno3.network:
    [Match]
    Name=eno3

    [Network]
    LinkLocalAddressing=no
    Bond=bond0

    # /etc/systemd/network/10-eno4.network:
    [Match]
    Name=eno4

    [Network]
    LinkLocalAddressing=no
    Bond=bond0

    # /etc/systemd/network/10-bond0.netdev:
    [NetDev]
    Name=bond0
    Kind=bond
    MTUBytes=9000

    [Bond]
    Mode=802.3ad
    LACPTransmitRate=fast
    MIIMonitorSec=100ms
    TransmitHashPolicy=layer3+4

    # /etc/systemd/network/10-bond0.network:
    [Match]
    Name=bond0

    [Link]
    MTUBytes=9000

    [Network]
    LinkLocalAddressing=no
    ConfigureWithoutCarrier=yes
    VLAN=tnet
    VLAN=stor
    VLAN=pulic

    # /etc/systemd/network/10-public.netdev:
    [NetDev]
    Name=public
    Kind=vlan
    MTUBytes=1500

    [VLAN]
    Id=82

    # /etc/systemd/network/10-public.network:
    [Match]
    Name=public

    [Link]
    MTUBytes=1500

    [Network]
    LinkLocalAddressing=no
    ConfigureWithoutCarrier=yes

    # /etc/systemd/network/10-tnet.netdev:
    [..]

    # /etc/systemd/network/10-tnet.network:
    [..]

    # /etc/systemd/network/10-stor.netdev:
    [..]

    # /etc/systemd/network/10-stor.network:
    [..]

neutron-linuxbridge-agent is configured to use "public" as a flat network, e.g.:

    # /etc/neutron/plugins/ml2/linuxbridge_agent.ini
    [linux_bridge]
    physical_interface_mappings = public:public
    [..]

When everything is started and a VM needs to be connected to the flat network, neutron-linuxbridge-agent creates a dynamic bridge for nova-compute, e.g. brq88363244-5f:

    14: public@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master brqe240c66b-da state UP
    59: brqe240c66b-da: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP

When systemd-networkd is restarted, it will see that "public" is up but has a master assigned. It will be unassigned and break the flat network:

    14: public@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    59: brqe240c66b-da: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP

What would be the recommended why to configure networking on compute hosts with Ubuntu OpenStack and flat networks? Not using systemd-networkd or netplan at all, but only /etc/network/interfaces?

Is there any modern alternative?

Revision history for this message
Nick Rosbrook (enr0n) wrote :

> Since merging https://github.com/systemd/systemd/pull/17392, systemd-network will remove the master flag > from the "public" interface, that neutron-linuxbridge-agent assigned to the bridge for the network, e.g. > brq88363244-5f, breaking all network on the flat network.

> The fix was revered in bug #1929560, but the behavior will not be reverted in newer releases. Therefore, > every reload of systemd-networkd will remove the physical network interface from neutrons bridge.

It looks like the patch was backported to stable releases in that bug; not reverted. Are you saying that that patch is wrong? Or that you want that behavior still? Looking at the upstream code quickly, things have changed quite a bit so I am not sure what the current behavior is.

> What would be the recommended why to configure networking on compute hosts with Ubuntu OpenStack and flat > networks? Not using systemd-networkd or netplan at all, but only /etc/network/interfaces?
>
> Is there any modern alternative?

It sounds like a support site would be more appropriate: https://discourse.ubuntu.com/t/community-support/709.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

Also what release are you running?

Changed in systemd (Ubuntu):
status: New → Incomplete
Revision history for this message
Jan Graichen (jgraichen) wrote :

> > The fix was revered in bug #1929560, but the behavior will not be reverted in newer releases. Therefore, every reload of systemd-networkd will remove the physical network interface from neutrons bridge.
>
> It looks like the patch was backported to stable releases in that bug; not reverted. Are you saying that that patch is wrong? Or that you want that behavior still? Looking at the upstream code quickly, things have changed quite a bit so I am not sure what the current behavior is.

Please see https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1929560/comments/15.

> It sounds like a support site would be more appropriate

Dan requested these details here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1929560/comments/13

> Also what release are you running?

Since the initial report, we upgraded from 18.04 to 20.04.

--

We continued to investigate for a solution, and systemd added a KeepMaster= option in v250 (https://github.com/systemd/systemd/commit/57aef9d7373c97d04beb6c5fc268496c3fdcf0a4). Unfortunately, Ubuntu 22.04 only includes systemd v249.

Would it be possible to have https://github.com/systemd/systemd/commit/57aef9d7373c97d04beb6c5fc268496c3fdcf0a4 backported to Ubuntu 22.04?

Nick Rosbrook (enr0n)
Changed in systemd (Ubuntu):
status: Incomplete → New
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.