neutron creates wrong vlan_tci filter in flow for gateway on flat external network and drops all PCP / QOS frames

[Andreas Karis]

neutron creates wrong vlan_tci filter in flow for gateway on flat external network

How reproducible:

Before:
~~~
[root@overcloud-controller-0 ~]# ovs-ofctl dump-flows br-int
 cookie=0xe8434ff964f0cbac, duration=6774.388s, table=0, n_packets=1, n_bytes=78, priority=3,in_port="int-br-ex",dl_vlan=905 actions=mod_vlan_vid:1,resubmit(,60)
 cookie=0xe8434ff964f0cbac, duration=8311.490s, table=0, n_packets=613, n_bytes=47932, priority=2,in_port="int-br-ex" actions=drop
 cookie=0xe8434ff964f0cbac, duration=8311.755s, table=0, n_packets=1566, n_bytes=148447, priority=0 actions=resubmit(,60)
 cookie=0xe8434ff964f0cbac, duration=8311.757s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0xe8434ff964f0cbac, duration=8311.752s, table=24, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0xe8434ff964f0cbac, duration=8311.754s, table=60, n_packets=1567, n_bytes=148525, priority=3 actions=NORMAL
~~~

Create router on flat network:
~~~
openstack network create provider2 --provider-network-type flat --provider-physical-network datacentre --share --external
openstack subnet create --network provider2 --subnet-range 10.1.0.0/24 provider2-subnet
openstack router create router2
openstack router set --external-gateway provider2 router2
~~~

After:
~~~
[root@overcloud-controller-0 ~]# ovs-ofctl dump-flows br-int
 cookie=0xe8434ff964f0cbac, duration=7228.959s, table=0, n_packets=2, n_bytes=156, priority=3,in_port="int-br-ex",dl_vlan=905 actions=mod_vlan_vid:1,resubmit(,60)
 cookie=0xe8434ff964f0cbac, duration=45.778s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-ex",vlan_tci=0x0000/0x1fff actions=mod_vlan_vid:3,resubmit(,60) # <-------------------------------- issue in this rule
 cookie=0xe8434ff964f0cbac, duration=8766.061s, table=0, n_packets=645, n_bytes=50428, priority=2,in_port="int-br-ex" actions=drop
 cookie=0xe8434ff964f0cbac, duration=8766.326s, table=0, n_packets=1588, n_bytes=150603, priority=0 actions=resubmit(,60)
 cookie=0xe8434ff964f0cbac, duration=8766.328s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0xe8434ff964f0cbac, duration=8766.323s, table=24, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0xe8434ff964f0cbac, duration=8766.325s, table=60, n_packets=1590, n_bytes=150759, priority=3 actions=NORMAL
[root@overcloud-controller-0 ~]#
~~~

The problematic rule is:
~~~
 cookie=0xe8434ff964f0cbac, duration=45.778s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-ex",vlan_tci=0x0000/0x1fff actions=mod_vlan_vid:3,resubmit(,60) # <-------------------------------- issue in this rule
~~~

This filter here:
vlan_tci=0x0000/0x1fff

Needs to be:
vlan_tci=0x0000/0x0fff

The existing filter works fine for frames without a dot1q tag. The filter does not work for dot1q tagged frames on VLAN 0. E.g., it COP is modified, frames with VLAN 0 and a COP value will be dropped.

~~~
man ovs-ofctl
(...)
The value that vlan_tci matches against is 0 for a packet that has no 802.1Q header. Otherwise, it is the TCI value from the 802.1Q header with the CFI bit (with value 0x1000) forced to 1.
~~~

We should not be filtering on the DCI bit, as it can be 0 or 1.

Additional info:
See https://bugzilla.redhat.com/1635909 for further details

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/613239

[sean mooney (sean-k-mooney)]

by definition a flat network should not have a vlan tag and therefor should not have a vlan_tci bit to set. ml2/ovs does not support vlan transparency so the guest should not be allowed to send a vlan tagged packet outside of the use of vlan aware vms.

from looking at the downstream bug its not clear to me that an issue acutlly exists.
if the costomer is configuring a cos filter on the TOR for flat networks that is an invalid config
as far as i understand so i dont think this is a neutron bug.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/613239
Reason: as per Sean's comments it shouldn't be done this way

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.