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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1800877

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

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Xenial:
  Fix Committed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1800877/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to