iproute2/xenial: Add support for the VF Trust setting (fix IPv6 multicast under SR-IOV on Mellanox adapters)

Bug #1800877 reported by Mauricio Faria de Oliveira on 2018-10-31
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
iproute2 (Ubuntu)
Undecided
Unassigned
Xenial
Medium
Mauricio Faria de Oliveira

Bug Description

[Impact]

 * An VM's VF cannot receive IPv6 multicast traffic
   from other VMs' VFs in the same Mellanox adapter
   _if_ its VF trust setting is not enabled, and on
   Xenial currently iproute2 _cannot_ enable it.

 * This breaks IPv6 NDP (Neighbor Discovery Protocol)
   in that scenario.

 * This upload adds three iproute2 upstream commits
   to enable/disable the VF setting, which resolves
   that problem/limitation.

[Test Case]

 * Check 'ip link help' for the 'trust' option:

   Before:

     # ip link help 2>&1 | grep trust
     <nothing>

   After:

     # ip link help 2>&1 | grep trust
     [ trust { on | off} ] ]

 * Check 'ip link show dev PF' for 'trust on|off' field in VFs.

   Before: (trust field _is not_ present)

     # ip link show dev ens1f0
     ...
     vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
     vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

   After: (trust field _is_ present)

     # ip link show dev ens1f0
     ...
     vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
     vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off

 * Set the VF trust on/off and check it:

     Set VF 0 trust on:

     # ip link set ens1f0 vf 0 trust on
     # ip link show dev ens1f0 | grep trust
     vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on
     vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off

     Set VF 0 trust off:

     # ip link set ens1f0 vf 0 trust off
     # ip link show dev ens1f0 | grep trust
     vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
     vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off

[Regression Potential]

 * Regression potential is low because the commits just add the
   netlink attribute for the userspace-kernel interface and the
   ways to set/clear it, and show the current value to the user.

 * Regressions could happen _if_ the user turns the setting on
   (it's disabled by default) and there's a problem/bug likely
   in _other_ component that depends on that setting (which is
   something to fix on such component).

[Other Info]

 * The users that reported this problem have verified
   the test package with these changes, and confirmed
   that it now works correctly for IPv6 NDP/multicast.

 * Upstream commits:
 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=dddf1b44126e
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=fe9322781e63
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=b6d77d9ee312

 * Only affect Xenial release :

 # rmadison iproute2
 iproute2 | 4.3.0-1ubuntu3.16.04.3 | xenial-updates
 iproute2 | 4.15.0-2ubuntu1 | bionic
 iproute2 | 4.18.0-1ubuntu2 | cosmic
 iproute2 | 4.18.0-1ubuntu2 | disco

 # iproute2 upstream vcs

 $ git describe --contains dddf1b44126e
 v4.4.0~67

 $ git describe --contains b6d77d9ee312
 v4.5.0~47

 $ git describe --contains fe9322781e63
 v4.6.0~32

Eric Desrochers (slashd) on 2018-11-01
Changed in iproute2 (Ubuntu):
status: New → Fix Released
Changed in iproute2 (Ubuntu Xenial):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Mauricio Faria de Oliveira (mfo)
Eric Desrochers (slashd) wrote :

I sent a private msg to mfo about a couple of minor nit picks I found.

tags: added: sts
Eric Desrochers (slashd) on 2018-11-01
description: updated

Hi Eric,

Thanks for reviewing.
This is the debdiff v2, addressing the points you brought up (numbered patches, bug-ubuntu dep3 tag).

cheers,
Mauricio

Hi Eric,

This is the v3 debdiff with the patches updated to apply with no offset messages per your request.

Thanks,
Mauricio

--

Applying patch debian/patches/1008-vf_trust_dddf1b44126e.patch
patching file include/linux/if_link.h

Applying patch debian/patches/1009-vf_trust_b6d77d9ee312.patch
patching file ip/iplink.c
patching file man/man8/ip-link.8.in

Applying patch debian/patches/1010-vf_trust_fe9322781e63.patch
patching file ip/ipaddress.c

Now at patch debian/patches/1010-vf_trust_fe9322781e63.patch

Eric Desrochers (slashd) wrote :

Sponsored !

It is now waiting on SRU team for approval for the package to start building and be published in xenial-proposed.

Once the package found in xenial-proposed, please keep an eye here : (to make sure everything looks good)
https://people.canonical.com/~ubuntu-archive/pending-sru.html

Thanks Mauricio !

- Eric

Hello Mauricio, or anyone else affected,

Accepted iproute2 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.3.0-1ubuntu3.16.04.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in iproute2 (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-xenial
Download full text (3.2 KiB)

Verification successful on xenial-proposed.
Updated verification tags.

Steps
=====

Setup 1) Enable xenial-proposed and install the iproute2 package:
---

$ echo 'deb http://archive.ubuntu.com/ubuntu xenial-proposed main restricted' | sudo tee /etc/apt/sources.list.d/xenial-proposed.list
deb http://archive.ubuntu.com/ubuntu xenial-proposed main restricted

$ sudo apt-get update

$ apt-cache madison iproute2 | grep xenial-proposed
  iproute2 | 4.3.0-1ubuntu3.16.04.4 | http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages

$ sudo apt-get install -y iproute2

$ dpkg -s iproute2 | grep Version
Version: 4.3.0-1ubuntu3.16.04.4

Setup 2) Configure 2 VFs in the ixgbe driver:
---

# lspci -s 08:00
08:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit TN Network Connection (rev 01)
08:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit TN Network Connection (rev 01)

# echo 2 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs

# dmesg | grep Virtual
[ 817.815245] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.12.1-k
[ 818.825923] ixgbevf 0000:08:10.0: Intel(R) 82599 Virtual Function
[ 818.837931] ixgbevf 0000:08:10.2: Intel(R) 82599 Virtual Function

# lspci -s 08:10
08:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
08:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)

Verification 1) Check for 'trust' in 'ip link help':
---

# ip link help 2>&1 | grep trust
                                   [ trust { on | off} ] ]

Verification 2) Check for 'trust' in 'ip link show'
---

# ip link show dev eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 68:05:ca:28:ff:9a brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust off

Verification 3) Set 'trust' on/off in the VFs
---

Trust setting is off by default:

# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust off

Enable trust setting on vf0:

# ip link set eth0 vf 0 trust on
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust off

Enable trust setting on vf1:

# ip link set eth0 vf 1 trust on
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust on

Disable trust setting on vf0:

# ip link set eth0 vf 0 trust off
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
    vf 1 MAC aa:fd:21:3f:93:1b, spoof checking on, link-state auto, trust on

Disable trust setting on vf1:

# ip link set eth0 vf 1 trust off
# ip link show dev eth0 | grep trust
    vf 0 MAC 00:00:00:00:00:00, spoof c...

Read more...

tags: added: verification-done verification-done-xenial
removed: verification-needed verification-needed-xenial

autopkgtests for ubuntu-fan
(triggered by this iproute2 upload)

The test failure in ubuntu-fan's lxd test (the thing
that is failing in these autopkgtests) does look flaky.

Looking at autopkgtest logs for ubuntu-fan on xenial, there's a series of retriggers
for the _same_ version of docker.io that led to different results (fail/pass), in
several architectures (and on arm64 it didn't help at all yet).

Based on that, I asked Dan (ddstreet) to retrigger autopkgtests
for ubuntu-fan on xenial for iproute2 and half of architectures
now pass (summary below).

I'll ask Dan to retrigger the pending/failing architectures a
few times more.

Thus, hopefully the autopkgtest failures in the pending/failing
architectures should not be a blocker for this SRU.

Summary:
- xenial/amd64:
  - iproute2: 1x fail, then pass.
  - docker.io: 2x fail, then pass.
- xenial/arm64:
  - iproute2: 3x fail, no pass.
  - docker.io: 5x fail, no pass.
- xenial/armhf:
  - iproute2: 1x pass.
  - docker.io: 1x pass.
- xenial/i386:
  - iproute2: 2x fail, no pass.
  - docker.io: 1x fail, then pass.
- xenial/ppc64el:
  - iproute2: 1x fail, then pass.
  - docker.io: 1x pass.
- xenial/s390x:
  - iproute2: 3x fail, no pass.
  - docker.io: 1x pass.

autopkgtests for open-vm-tools,
failures in amd64 and i386.

These are consistently failing since May 14th, 2018
for a lot of other packages, thus not a change from
this upload.

Thanks,
Mauricio

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers