[Bug 1860987] [NEW] openvswitch: same tcp session encapsulated with different udp src port for ovs vxlan tunnel

[Maxime Leroy]

Public bug reported:

[SRU Justification]

[Impact]

Packets encapsulated into a vxlan tunnel with openvswitch don't have the
same udp source port for the first packet and the following ones of the
same TCP flow in a DOCKER scenario usecase.

In fact, when using the kernel datapath, the upcall don't include skb hash info relatived. As VXLAN module uses
the skb hash to select UDP src port, the source port is different for the first packet. 

More information can be found here:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html

This has been fixed in the next release openvswitch 2.13  by the following upstream commits:
- 0442bfb11d6ccb ("ofproto-dpif-upcall: Echo HASH attribute back to datapath.")
- c4d8a4e0399910 ("ofproto-dpif: Fix using uninitialized execute hash.")
- 924d94a695a6ca ("ofproto-dpif-upcall: Fix using uninitialized upcall hash.")

https://github.com/openvswitch/ovs/commit/0442bfb11d6ccbf11754ef1d6de603b970465302
https://github.com/openvswitch/ovs/commit/c4d8a4e039991030c1298dbd1335d209cb437875
https://github.com/openvswitch/ovs/commit/924d94a695a6ca54b83d4bd42ec196ba53947c6d

The bug exists since the beginning of vxlan support in openvswitch.
 
== Fix ==


Backport the requested patches to Focal (5.4), Disco (5.0), Bionic (4.15) and
Xenial (4.4).

** Affects: openvswitch (Ubuntu)
     Importance: Undecided
         Status: New

** Package changed: linux (Ubuntu) => openvswitch (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to openvswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1860987

Title:
  openvswitch: same tcp session encapsulated with different udp src port
  for ovs vxlan tunnel

Status in openvswitch package in Ubuntu:
  New

Bug description:
  [SRU Justification]

  [Impact]

  Packets encapsulated into a vxlan tunnel with openvswitch don't have
  the same udp source port for the first packet and the following ones
  of the same TCP flow in a DOCKER scenario usecase.

  In fact, when using the kernel datapath, the upcall don't include skb hash info relatived. As VXLAN module uses
  the skb hash to select UDP src port, the source port is different for the first packet. 

  More information can be found here:
  https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html

  This has been fixed in the next release openvswitch 2.13  by the following upstream commits:
  - 0442bfb11d6ccb ("ofproto-dpif-upcall: Echo HASH attribute back to datapath.")
  - c4d8a4e0399910 ("ofproto-dpif: Fix using uninitialized execute hash.")
  - 924d94a695a6ca ("ofproto-dpif-upcall: Fix using uninitialized upcall hash.")

  https://github.com/openvswitch/ovs/commit/0442bfb11d6ccbf11754ef1d6de603b970465302
  https://github.com/openvswitch/ovs/commit/c4d8a4e039991030c1298dbd1335d209cb437875
  https://github.com/openvswitch/ovs/commit/924d94a695a6ca54b83d4bd42ec196ba53947c6d

  The bug exists since the beginning of vxlan support in openvswitch.
   
  == Fix ==

  
  Backport the requested patches to Focal (5.4), Disco (5.0), Bionic (4.15) and
  Xenial (4.4).

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