if-post-down.d/vlan and if-pre-up.d/vlan should support predictable NIC names

Bug #1541678 reported by Haw Loeung on 2016-02-04
88
This bug affects 15 people
Affects Status Importance Assigned to Milestone
vlan (Debian)
New
Unknown
vlan (Ubuntu)
Medium
Unassigned

Bug Description

Starting with udev v197, systems now use predictable network interface names by default[1]. Unfortunately on my system running Xenial alpha2, it seems vlan doesn't support the generated interface names:

| ubuntu@lagertha:/var/log$ dmesg | grep rename
| [ 5.101700] igb 0000:01:00.0 enp1s0: renamed from eth0
| [ 5.502268] igb 0000:02:00.0 enp2s0: renamed from eth1
| [ 5.526634] igb 0000:04:00.0 enp4s0: renamed from eth3
| [ 5.550056] igb 0000:03:00.0 enp3s0: renamed from eth2

Looking at the if-pre-up and if-post-down scripts, it seems it's missing there and only has:

| eth*.0*|bond*.0*|wlan*.0*|em*.0*|p[0-9]*.0*)
| ... ;;
| eth*.*|bond*.*|wlan*.*|em*.*|p[0-9]*.*)
| ... ;;

"""
What precisely has changed in v197?

The following different naming schemes for network interfaces are now supported by udev natively:

1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5. Classic, unpredictable kernel-native ethX naming (example: eth0)
"""

Here's the package versions:

| ubuntu@lagertha:/var/log$ apt-cache policy udev
| udev:
| Installed: 228-4ubuntu2
| Candidate: 228-5ubuntu1
| Version table:
| 228-5ubuntu1 500
| 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
| *** 228-4ubuntu2 100
| 100 /var/lib/dpkg/status
| ubuntu@lagertha:/var/log$ apt-cache policy vlan
| vlan:
| Installed: 1.9-3.2ubuntu1
| Candidate: 1.9-3.2ubuntu1
| Version table:
| *** 1.9-3.2ubuntu1 500
| 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
| 100 /var/lib/dpkg/status

[1]http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Haw Loeung (hloeung) on 2016-02-04
tags: added: xenial
description: updated
description: updated
summary: - if-post-down.d/vlan and if-pre-up.d/vlan should support enpXsY
- interfaces
+ if-post-down.d/vlan and if-pre-up.d/vlan should support en* interfaces

Attached patch makes it work when interface names are enpXsY. It doesn't cover the other cases as per link to PredictableNetworkInterfaceNames.

The attachment "enp1s0.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vlan (Ubuntu):
status: New → Confirmed
Simon Déziel (sdeziel) wrote :

As mentioned in a duplicated LP, I think the vlan up/down script could be simplified.

The part extracting VLANID and IF_VLAN_RAW_DEVICE seems overly complex. The "case" statement already ensures we operate on vlan device so I think something much simpler like this would work:

  VLANID=`echo $IFACE|sed "s/[^.]\+\.\([0-9]\+\).*/\1/; s/^0//"`
  IF_VLAN_RAW_DEVICE=`echo $IFACE|sed "s/\([^.]\+\)\.[0-9]\+.*/\1/"`

This is also easier to read.

Changed in vlan (Ubuntu):
importance: Undecided → High
Simon Déziel (sdeziel) wrote :

One more data point, my 4x1Gbps NIC appears as:

enp3s0f0
enp3s0f1
enp4s0f0
enp4s0f1

Simon Déziel (sdeziel) on 2016-04-25
summary: - if-post-down.d/vlan and if-pre-up.d/vlan should support en* interfaces
+ if-post-down.d/vlan and if-pre-up.d/vlan should support predictable NIC
+ names
Haw Loeung (hloeung) wrote :

https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L29 explains it pretty well

So there's the two letter prefixes:

"""
 * en — Ethernet
 * sl — serial line IP (slip)
 * wl — wlan
 * ww — wwan
"""

Then there's the type of names:

"""
 * Type of names:
 * b<number> — BCMA bus core number
 * c<bus_id> — CCW bus group name, without leading zeros [s390]
 * o<index>[d<dev_port>] — on-board device index number
 * s<slot>[f<function>][d<dev_port>] — hotplug slot index number
 * x<MAC> — MAC address
 * [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>]
 * — PCI geographical location
 * [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
 * — USB port number chain
"""

Haw Loeung (hloeung) wrote :

Reported upstream and forwarded patch building on Simon Déziel (sdeziel)'s idea.

Changed in vlan (Debian):
status: Unknown → New

I ran into this as well. VLAN configuration is broken on Xenial unless you disable predictable network interface names, or you set up systemd .link files to rename your NICs (but, importantly, not vlan or bridge interfaces) to have a name starting with "eth".

Since the upstream bug hasn't seen any activity for seven weeks, can we have an Ubuntu-specific fix? Seems like kind of an important piece of functionality that's broken out-of-the-box in an LTS release.

Brian Candler (b-candler) wrote :

Caught by this too. I get enp3s0, and have set net.ifnames=0 as a workaround.

I agree with the suggestion that the script should be simplified to match XXXX.N, where X is any alphanumeric. More conservatively: the first X could match a-z only, and the last X could match 0-9 only.

Question is, was there a reason for originally matching only specific patterns like ethM.N, wlanM.N etc? Was it to exclude certain other valid interface names which contain a dot but are not VLAN capable? Or perhaps it was just being overly cautious?

Robie Basak (racb) on 2016-08-10
tags: added: server-next
Changed in vlan (Ubuntu):
importance: High → Wishlist
Haw Loeung (hloeung) wrote :

Matthew,

Why was this changed to "Wishlist"? Predictable network interface is the default on Xenial and above which means VLAN support is broken.

Robie Basak (racb) on 2016-09-16
Changed in vlan (Ubuntu):
importance: Wishlist → High
Robie Basak (racb) on 2016-09-19
Changed in vlan (Ubuntu):
assignee: nobody → Robie Basak (racb)
Robie Basak (racb) on 2016-10-03
tags: removed: server-next
Brian Candler (b-candler) wrote :

To avoid the patch in #7, you can set vlan-raw-device explicitly:

-----
auto eno1.100
iface eno1.100 inet manual
  vlan-raw-device eno1
-----

Note that if you link this to a bridge, then bringing up the bridge doesn't bring up the vlan bridge ports:

-----
auto eno1.100
iface eno1.100 inet manual
  vlan-raw-device eno1

auto br100
iface br100 inet manual
  bridge_ports eno1.100
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0
-----

Result:

-----
# ifup br100
interface eno1.100 does not exist!
# brctl show br100
bridge name bridge id STP enabled interfaces
br100 8000.000000000000 no
# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
#
-----

But it *does* work if you explicitly bring up the interface first: in fact, that also brings up the bridge.

-----
# ifdown br100
# ifup eno1.100
# brctl show br100
bridge name bridge id STP enabled interfaces
br100 8000.001fc69bf7eb no eno1.100
# ifup br100
ifup: interface br100 already configured
#
-----

Brian Candler (b-candler) wrote :

It has been pointed out to me that if you combine "vlan-raw-device" with "pre-up" then you have a complete workaround:

-----
auto eno1.100
iface eno1.100 inet manual
  vlan-raw-device eno1

auto br100
iface br100 inet manual
  bridge_ports eno1.100
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0
  pre-up ifup eno1.100
-----

Dear all,

We have also faced such issue while migrating some servers from Ubuntu 14.04.5 to Ubuntu 16.04.3. Are there any plans to get a correct fix so that we can properly plan our migration to Xenial?
Meanwhile, we used the workaround provided by Brian Candler - thanks! - which works well.

Thanks

Robie Basak (racb) wrote :

Seems that I haven't been able to work on this, so let's make it clear that it's available for someone to pick up.

Changed in vlan (Ubuntu):
assignee: Robie Basak (racb) → nobody
tags: added: server-next
Robie Basak (racb) wrote :

With netplan becoming the default in 18.04, it'll be either systemd-networkd or Network Manager that will be configuring the vlans, and not ifupdown. I think this means that while this bug continues to exist, it no longer affects the default VLAN case.

Changed in vlan (Ubuntu):
importance: High → Medium
tags: removed: server-next
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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