ovs bridge device recognition: "node <hostname> renamed interface eth0 to br0"

[Dmitrii Shcherbakov]

I am using an OVS bridge on a MAAS host instead of a Linux bridge. Like with the Linux bridge, the MAC address for eth0 is the same as the one that the ovs bridge gets (00:16:3e:d2:fc:45 in this case).

root@test:~# ovs-vsctl show
19a4f3e3-4b04-4a78-9bae-9127e156e459
    Bridge "br0"
        Port "eth0"
            Interface "eth0"
        Port "br0"
            Interface "br0"
                type: internal
        Port "vnet0"
            Interface "vnet0"
    ovs_version: "2.8.0"

root@test:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
...
2: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 32:ee:59:66:d6:08 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 00:16:3e:d2:fc:45 brd ff:ff:ff:ff:ff:ff
    inet 10.20.20.2/24 brd 10.20.20.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fd42:5ba:7605:e8af:216:3eff:fed2:fc45/64 scope global mngtmpaddr dynamic
       valid_lft 3476sec preferred_lft 3476sec
    inet6 fe80::216:3eff:fed2:fc45/64 scope link
       valid_lft forever preferred_lft forever
266: eth0@if267: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000
    link/ether 00:16:3e:d2:fc:45 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::216:3eff:fed2:fc45/64 scope link
       valid_lft forever preferred_lft forever

A lot of "node test renamed interface" messages are observed in regiond.log:

http://paste.ubuntu.com/26149429/
/var/log/maas/regiond.log: * node test renamed interface br0 to eth0

The result is that MAAS considers eth0 to be the only interface present and does not properly discover an IP address assigned to br0.

The problem with not being able to discover an IP address is alleviated to some extent by using an additional internal interface:

ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 svi0 -- set interface svi0 type=internal

root@test:~# ovs-vsctl show
19a4f3e3-4b04-4a78-9bae-9127e156e459
    Bridge "br0"
        Port "eth0"
            Interface "eth0"
        Port "br0"
            Interface "br0"
                type: internal
        Port "svi0"
            Interface "svi0"
                type: internal
        Port "vnet0"
            Interface "vnet0"
    ovs_version: "2.8.0"

In this case, if an address is assigned to svi0, then MAAS picks up the interface details.

The repeated message seems to be coming from:
https://github.com/maas/maas/blob/2.3.0/src/maasserver/triggers/system.py#L1251-L1253

An iftype in sysfs for an OVS bridge matches the one for Linux Bridge ("1"):
https://github.com/maas/maas/blob/2.3.0/src/provisioningserver/utils/ipaddr.py#L266-L269

What's different is bridged_interface detection as the same sysfs entries are not available:
https://github.com/maas/maas/blob/2.3.0/src/provisioningserver/utils/ipaddr.py#L362-L364

Another point is that regular tcpdump cannot be used to listen on ovs interfaces:
http://www.openvswitch.org/support/dist-docs/ovs-tcpdump.8.html

/var/log/maas/rackd.log:2017-12-07 16:51:13 provisioningserver.utils.services: [info] observe-beacons[br0]: tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 16384 bytes

With an additional internal interface MAAS seems to properly work with OVS used as a switch for basic use-cases.

[Dmitrii Shcherbakov (dmitriis)]

An attachment shows a successful internal interface (svi0) and address discovery. The address is configured in /e/n/i:

auto svi0
iface svi0 inet static
    address 10.20.20.2/24
    gateway 10.20.20.1

OVS interfaces can be administratively brought up via ifup and assigned addresses just like linux bridge interfaces, see also https://git.io/vbBgK

[Björn Tillenius (bjornt)]

I'm not sure what the proper fix would be, but at least there's enough information so that we can investigate further.

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

[Jerzy Husakowski (jhusakowski)]

Is this issue reproducible on MAAS 3.3? There have been changes in interface detection since this issue was submitted.

[Launchpad Janitor (janitor)]

[Expired for MAAS because there has been no activity for 60 days.]