yahoo-eng-team team mailing list archive

Thread
Date

[Bug 2048785] Re: Trunk parent port (tpt port) vlan_mode is wrong in ovs

To: yahoo-eng-team@xxxxxxxxxxxxxxxxxxx
From: Jeremy Stanley <2048785@xxxxxxxxxxxxxxxxxx>
Date: Mon, 29 Jan 2024 18:15:42 -0000
Reply-to: Bug 2048785 <2048785@xxxxxxxxxxxxxxxxxx>
Sender: noreply@xxxxxxxxxxxxx

Since the fix provided for the upcoming 2024.1 coordinated release
requires additional actions on the part of the operator to apply to
existing deployments affected by the former behavior, it won't qualify
for a security advisory (OSSA) but may still warrant a security note
(OSSN) if anyone feels strongly enough about the severity to draft one.
The closest classes in our report taxonomy are B1/B2 (or perhaps C1 or D
if the severity is deemed low enough by Neutron maintainers):
https://security.openstack.org/vmt-process.html#report-taxonomy

I'm closing out our OSSA (advisory) task as "won't fix" and adding an
"incomplete" OSSN task in case someone decides it's something they want
to work on.

** Changed in: ossa
Status: Incomplete => Won't Fix

** Also affects: ossn
Importance: Undecided
Status: New

** Changed in: ossn
Status: New => Incomplete

--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2048785

Title:
Trunk parent port (tpt port) vlan_mode is wrong in ovs

Status in neutron:
Fix Released
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Incomplete

Bug description:
... therefore a forwarding loop, packet duplication, packet loss and
double tagging is possible.

Today a trunk bridge with one parent and one subport looks like this:

# ovs-vsctl show
...
Bridge tbr-b2781877-3
datapath_type: system
Port spt-28c9689e-9e
tag: 101
Interface spt-28c9689e-9e
type: patch
options: {peer=spi-28c9689e-9e}
Port tap3709f1a1-a5
Interface tap3709f1a1-a5
Port tpt-3709f1a1-a5
Interface tpt-3709f1a1-a5
type: patch
options: {peer=tpi-3709f1a1-a5}
Port tbr-b2781877-3
Interface tbr-b2781877-3
type: internal
...

# ovs-vsctl find Port name=tpt-3709f1a1-a5 | egrep 'tag|vlan_mode|trunks'
tag : []
trunks : []
vlan_mode : []

# ovs-vsctl find Port name=spt-28c9689e-9e | egrep 'tag|vlan_mode|trunks'
tag : 101
trunks : []
vlan_mode : []

I believe the vlan_mode of the tpt port is wrong (at least when the port is not "vlan_transparent") and it should have the value "access".
Even when the port is "vlan_transparent", forwarding loops between br-int and a trunk bridge should be prevented.

According to: http://www.openvswitch.org/support/dist-docs/ovs-
vswitchd.conf.db.5.txt

"""
vlan_mode: optional string, one of access, dot1q-tunnel, native-tagged,
native-untagged, or trunk
The VLAN mode of the port, as described above. When this column
is empty, a default mode is selected as follows:

• If tag contains a value, the port is an access port. The
trunks column should be empty.

• Otherwise, the port is a trunk port. The trunks column
value is honored if it is present.
"""

"""
trunks: set of up to 4,096 integers, in range 0 to 4,095
For a trunk, native-tagged, or native-untagged port, the 802.1Q
VLAN or VLANs that this port trunks; if it is empty, then the
port trunks all VLANs. Must be empty if this is an access port.

A native-tagged or native-untagged port always trunks its native
VLAN, regardless of whether trunks includes that VLAN.
"""

The above combination of tag, trunks and vlan_mode for the tpt port
means that it is in trunk mode (in the ovs sense) and it forwards both
untagged and tagged frames with any vlan tag. But the tpt port should
only forward untagged frames.

(edit: Instead of what's below please find a complete reproduction in
comment #2:
https://bugs.launchpad.net/neutron/+bug/2048785/comments/2)

Feel free to treat this as the end of the bug report. But below I'll
add more about how we found this bug, in what conditions can it be
triggered, what consequences it may have. However please keep in mind
I don't have a full upstream reproduction at the moment. Nor have I a
full analysis of every suspicion mentioned below.

I'm aware of a full reproduction of this bug only in a downstream
environment, which looked like below. While the following was
sufficient to reproduce the problem, this was likely far from a
minimal reproduction and some/many of the below steps are unnecessary.

* [securitygroup].firewall_driver = openvswitch ((edited, originally was: noop))
* [agent].explicitly_egress_direct = True ((edited, originally was: [ovs].explicitly_egress_direct = True))
* 2 VMs started on the same compute.
* Both having a trunk port with one parent and one subport.
* The parent and the subport of each trunk have the same MAC address.
* All ports are on vlan networks belonging to the same physnet.
* All ports are created with --disable-port-security and --no-security-group.
* The subport segmentation IDs and the corresponding vlan network segmentation IDs were the same (as if they used "inherit").
* Traffic was generated from a 3rd VM on a different compute addressed to one of the VM's subport IP, for which
* the destination MAC was not yet learned by either br-int or the two trunk bridges on the host.

I believe the environment looked like this:

openstack network create net0 --provider-network-type vlan --provider-physical-network physnet0 --provider-segment 100
openstack network create net1 --provider-network-type vlan --provider-physical-network physnet0 --provider-segment 101

openstack subnet create --network net0 --subnet-range 10.0.100.0/24 subnet0
openstack subnet create --network net1 --subnet-range 10.0.101.0/24 subnet1

openstack port create --no-security-group --disable-port-security --network net0 --fixed-ip ip-address=10.0.100.10 port0a
port0a_mac="$( openstack port show port0a -f value -c mac_address )"
openstack port create --no-security-group --disable-port-security --mac-address "$port0a_mac" --network net1 --fixed-ip ip-address=10.0.101.10 port1a

openstack port create --no-security-group --disable-port-security --network net0 --fixed-ip ip-address=10.0.100.11 port0b
port0b_mac="$( openstack port show port0b -f value -c mac_address )"
openstack port create --no-security-group --disable-port-security --mac-address "$port0b_mac" --network net1 --fixed-ip ip-address=10.0.101.11 port1b

openstack network trunk create --parent-port port0a trunka
openstack network trunk set --subport port=port1a,segmentation-type=vlan,segmentation-id=101 trunka

openstack network trunk create --parent-port port0b trunkb
openstack network trunk set --subport port=port1b,segmentation-type=vlan,segmentation-id=101 trunkb

openstack server create --flavor ds1G --image u1804 --nic port-id=port0a --wait vma
openstack server create --flavor ds1G --image u1804 --nic port-id=port0b --wait vmb # booted on the same compute as vma

At the moment I don't have a reproduction independent of that
environment, that re-creates the same state of the bridges' FDBs and
the same kind of traffic.

Anyway, in this environment colleagues observed:
* Lost frames.
* Duplicated frames arriving to the vNIC of one of the VMs.
* Unexpectedly double tagged frames on the physical bridge leaving the compute host.

Local analysis showed as the traffic arrived to br-int, which did not have the dst MAC in its FDB, had to flood to all ports.
This way the frame ended up on both trunk bridges.
One of these trunk bridges was on the proper way to the destination address.
But the other trunk bridge, also not having the dst MAC in its FDB, had to flood to all ports.
And this trunk bridge also flooded the frame to its tpt port back to br-int.
But the tpt port conceptually is in a different VLAN and the frame should never have been flooded to that port.
However the tpt port has the wrong configuration and forwards the traffic from the wrong VLANs.

After the looped frame got back to br-int, it reached the intended VMs
vNIC via the trunk parent (sic!) port. Which means that the latter
trunk bridge learned the traffic generator's source MAC now on the
wrong port. I have a suspicion that this may have lead to the
unexpectedly double tagged packets in the other direction.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2048785/+subscriptions

References

[Bug 2048785] [NEW] Trunk parent port (tpt port) vlan_mode is wrong in ovs
From: Bence Romsics, 2024-01-09