openvswitch: same tcp session encapsulated with different udp src port for ovs vxlan tunnel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Confirmed
|
Undecided
|
Unassigned | ||
Focal |
Confirmed
|
Undecided
|
Unassigned | ||
Groovy |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned | ||
Impish |
Fix Released
|
Undecided
|
Unassigned | ||
openvswitch (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Bionic |
Triaged
|
Low
|
Unassigned | ||
Focal |
Fix Released
|
Medium
|
Unassigned | ||
Groovy |
Fix Released
|
Medium
|
Unassigned | ||
Hirsute |
Fix Released
|
Medium
|
Unassigned | ||
Impish |
Fix Released
|
Medium
|
Unassigned |
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:/
This has been fixed in the next release openvswitch 2.13 by the following upstream commits:
- 0442bfb11d6ccb ("ofproto-
- c4d8a4e0399910 ("ofproto-dpif: Fix using uninitialized execute hash.")
- 924d94a695a6ca ("ofproto-
https:/
https:/
https:/
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: | linux (Ubuntu) → openvswitch (Ubuntu) |
Focal already has 2.13.3 which includes this fix.