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

Bug #1737357 reported by Dmitrii Shcherbakov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Expired
Medium
Unassigned

Bug Description

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.

Tags: cpe-onsite
Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :
Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

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

Revision history for this message
Björn Tillenius (bjornt) wrote :

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

Changed in maas:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 2.4.x
Revision history for this message
Adam Collard (adam-collard) wrote :

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

Changed in maas:
status: Triaged → Invalid
Changed in maas:
status: Invalid → New
Alberto Donato (ack)
summary: - [2.3.0] ovs bridge device recognition: "node <hostname> renamed
- interface eth0 to br0"
+ ovs bridge device recognition: "node <hostname> renamed interface eth0
+ to br0"
Changed in maas:
status: New → Triaged
milestone: 2.4.x → none
Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

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

Changed in maas:
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in maas:
status: Incomplete → Expired
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.