Description of problem: During the verification of the VLAN Transparency for OVN RFE described in BZ1846019, I am creating some tempest tests [1] (they are not merged yet) and running them on two environments: one for Geneve networks and one for VLAN networks. I got the following results: 1) vlan-transp + port-sec-disabled a) geneve tenant nets -> pass b) vlan tenant nets -> pass 2) vlan-transp + port-sec-enabled + sec-groups (icmp and ssh) + allowed-address-pairs a) geneve tenant nets -> pass b) vlan tenant nets -> fail -> ping request reaches destination VM, which sends ping reply, which is captured on the tap interface, but it's dropped there It seems those packets are dropped because they match this rule: cookie=0x21600bb0, duration=75241.968s, table=15, n_packets=72204, n_bytes=7364808, idle_age=0, hard_age=65534, priority=65535,ct_state=+inv+trk,metadata=0x93 actions=drop The same rule exists in the geneve environment, but no packet matches it. Untagged packets are not dropped in test 2.b. That rule does not exist in scenario 1.b (port-sec disabled) and that's the reason why the packets are not dropped, obviously. According to that rule, it seems that the packets have been marked as invalid. Maybe something related to vlan on vlan? [1] https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/765002 Version-Release number of selected component (if applicable): ovn2.13-20.09.0-17.el8fdp.x86_64 ovn2.13-host-20.09.0-17.el8fdp.x86_64 ovn2.13-central-20.09.0-17.el8fdp.x86_64 python3-networking-ovn-7.3.1-1.20201114024043.el8ost.noarch How reproducible: 100% Steps to Reproduce: Using the neutron-tempest-plugin patch [1], run: tempest run -r test_vlan_transparent_allowed_address_pairs or 1. create network with transparent-vlan enabled, create subnet 2. create two ports on that network with sec groups that allow ICMP traffic and add IPs to them using the parameter allowed-address-pairs 3. create two VMs with the previous ports and create on their NIC (eth0) a VLAN interace using the allowed-address-pairs IPs 4. try to ping from one VM the other's VLAN IP
a similar test fails too with vlan provider networks (so, this BZ affects both vlan tenant and provider networks)
It seems that it is some issue in OVN. I described all our findings in the mail https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050857.html Lets see what OVN folks will say about it.
Related patches proposed u/s https://review.opendev.org/c/openstack/puppet-ovn/+/779713 and https://review.opendev.org/c/openstack/tripleo-heat-templates/+/779714
Reguired fixes are in puppet-vswitch-11.4.1-1.20210616133305.4fc423f.el8ost and openstack-tripleo-heat-templates-11.3.2-1.20210616133305.29a02c1.el8ost
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1.7 (Train) bug fix and enhancement advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:3762