Unable to contact to IPv6 instance using ml2 ovs with ovs 2.16

Bug #1964117 reported by Liam Young
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Ubuntu Cloud Archive
New
Undecided
Unassigned
Xena
Fix Released
Undecided
Unassigned
Yoga
Fix Released
Undecided
Unassigned
neutron
Invalid
Undecided
Unassigned
openvswitch (Ubuntu)
Fix Released
High
Unassigned
Impish
Won't Fix
Undecided
Unassigned
Jammy
Fix Released
Undecided
Unassigned
Kinetic
Fix Released
High
Unassigned

Bug Description

Connectivity is fine with OVS 2.15 but after upgrading ovs, connectivity is lost to remote units over ipv6. The traffic appears to be lost while being processed by the openflow firewall associated with br-int.

The description below uses connectivity between Octavia units and amphora to illustrate the issue but I don't think this issue is related to Octavia.

OS: Ubuntu Focal
OVS: 2.16.0-0ubuntu2.1~cloud0
Kernel: 5.4.0-100-generic

With a fresh install of xena or after an upgrade of OVS from 2.15 (wallaby) to 2.16 (xena) connectivity from the octavia units to the amphora is broken.
* Wallaby works as expected
* Disabling port security on the octavia units octavia-health-manager-octavia-N-listen-port restores connectivity.
* The flows on br-int and br-tun are the same after the upgrade from 2.15 to 2.16
* Manually inserting permissive flows into the br-int flow table also restores connectivity.
* Testing environment is Openstack on top of Openstack.

Text below is reproduced here https://pastebin.ubuntu.com/p/hRWMx7d9HG/ as it maybe easier to read in a pastebin.

Below is reproduction of the issue first deploying wallaby to validate connectivity before upgrading openvswitch.

Amphora:

$ openstack loadbalancer amphora list
+--------------------------------------+--------------------------------------+-----------+--------+-----------------------------------------+-------------+
| id | loadbalancer_id | status | role | lb_network_ip | ha_ip |
+--------------------------------------+--------------------------------------+-----------+--------+-----------------------------------------+-------------+
| 30afe97a-bcd4-4537-a621-830de87568b0 | ae840c86-768d-4aae-b804-8fddf2880c78 | ALLOCATED | MASTER | fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 | 10.42.0.254 |
| 61e66eff-e83b-4a21-bc1f-1e1a0037b191 | ae840c86-768d-4aae-b804-8fddf2880c78 | ALLOCATED | BACKUP | fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b | 10.42.0.254 |
+--------------------------------------+--------------------------------------+-----------+--------+-----------------------------------------+-------------+

$ openstack router show lb-mgmt -c name -c interfaces_info
+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------+
| interfaces_info | [{"port_id": "191a2d27-9b15-4938-a818-b48fc405a27a", "ip_address": "fc00:92e3:d18a:36ed::", "subnet_id": "8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03"}] |
| name | lb-mgmt |
+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------+

Looking at ports on that subnet there is a port for each of the octavia units (named octavia-health-manager-octavia-N-listen-port ), a port on
each of the amphora listed above and a port for the lb-mgmt router.

$ openstack port list | grep 8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03
| 0943521f-2c1f-4152-8250-48d310e3918f | octavia-health-manager-octavia-1-listen-port | fa:16:3e:70:70:c9 | ip_address='fc00:92e3:d18a:36ed:f816:3eff:fe70:70c9', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |
| 160b8854-0f20-471b-9ac4-53f8891f4edb | | fa:16:3e:45:7a:a6 | ip_address='fc00:92e3:d18a:36ed:f816:3eff:fe45:7aa6', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |
| 191a2d27-9b15-4938-a818-b48fc405a27a | | fa:16:3e:3e:bd:45 | ip_address='fc00:92e3:d18a:36ed::', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |
| 2428b1d4-0cb2-420b-81a5-5e6ae34e4557 | octavia-health-manager-octavia-2-listen-port | fa:16:3e:05:f3:2a | ip_address='fc00:92e3:d18a:36ed:f816:3eff:fe05:f32a', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |
| 2ea37e19-bd60-43cb-8191-aaf179667b1a | | fa:16:3e:d2:32:e0 | ip_address='fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |
| 76742ab6-39ee-4b06-a37d-f2ecad2c892a | octavia-health-manager-octavia-0-listen-port | fa:16:3e:79:b6:46 | ip_address='fc00:92e3:d18a:36ed:f816:3eff:fe79:b646', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |
| ffb3d106-7a14-4b4e-8300-2dd9ec9bc642 | | fa:16:3e:69:c8:5b | ip_address='fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b', subnet_id='8b4307a7-08a1-4f2b-a7e0-ce45a7ad0b03' | ACTIVE |

The ports attached to the octavia units have port security enabled:

$ openstack port show octavia-health-manager-octavia-0-listen-port -c name -c device_owner -c security_group_ids -c port_security_enabled -c id
+-----------------------+----------------------------------------------+
| Field | Value |
+-----------------------+----------------------------------------------+
| device_owner | neutron:LOADBALANCERV2 |
| id | 76742ab6-39ee-4b06-a37d-f2ecad2c892a |
| name | octavia-health-manager-octavia-0-listen-port |
| port_security_enabled | True |
| security_group_ids | 04582e3a-3093-4158-b66e-dfdd32665108 |
+-----------------------+----------------------------------------------+

$ openstack security group rule list 04582e3a-3093-4158-b66e-dfdd32665108
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
| 3bde542e-6972-4f8b-898d-a773505b25eb | None | IPv4 | 0.0.0.0/0 | | egress | None | None |
| 89c4f2ed-5431-434e-bec5-343f41d28a68 | None | IPv6 | ::/0 | | egress | None | None |
| a26b3608-466a-4422-adb5-b86a6dff0c7c | ipv6-icmp | IPv6 | ::/0 | | ingress | None | None |
| bfc54f3f-8851-490e-b9a0-db48f43946ca | udp | IPv6 | ::/0 | 5555:5555 | ingress | None | None |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+

Connectivity between the octavia units and the amphora is working:

$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0
PING fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0(fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0) 56 data bytes
64 bytes from fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0: icmp_seq=1 ttl=64 time=3.82 ms

--- fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.820/3.820/3.820/0.000 ms

$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b
PING fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b(fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b) 56 data bytes
64 bytes from fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b: icmp_seq=1 ttl=64 time=4.12 ms

--- fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.123/4.123/4.123/0.000 ms

$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443
Connection to fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443 port [tcp/*] succeeded!

$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 9443
Connection to fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 9443 port [tcp/*] succeeded!

Take a dump of the flows before upgrade:

sudo ovs-ofctl dump-flows br-int --no-stats > br-int-ovs-2.15-flows.txt
sudo ovs-ofctl dump-flows br-tun --no-stats > br-tun-ovs-2.15-flows.txt

Switch apt sources to xena:
$ sudo sed -i -e 's/wallaby/xena/' /etc/apt/sources.list.d/cloud-archive.list

$ sudo apt update

$ apt-cache policy openvswitch-switch
openvswitch-switch:
  Installed: 2.15.0-0ubuntu3.1~cloud0
  Candidate: 2.16.0-0ubuntu2.1~cloud0
  Version table:
     2.16.0-0ubuntu2.1~cloud0 500
        500 http://ubuntu-cloud.archive.canonical.com/ubuntu focal-updates/xena/main amd64 Packages
 *** 2.15.0-0ubuntu3.1~cloud0 100
        100 /var/lib/dpkg/status
     2.13.5-0ubuntu1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
     2.13.3-0ubuntu0.20.04.2 500
        500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
     2.13.0-0ubuntu1 500
        500 http://nova.clouds.archive.ubuntu.com/ubuntu focal/main amd64 Packages

Upgrade openvswitch-switch and restart services:

$ sudo apt install openvswitch-switch
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  openvswitch-common python3-openvswitch
Suggested packages:
  openvswitch-doc
The following packages will be upgraded:
  openvswitch-common openvswitch-switch python3-openvswitch
3 upgraded, 0 newly installed, 0 to remove and 79 not upgraded.
Need to get 2930 kB of archives.
After this operation, 285 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ubuntu-cloud.archive.canonical.com/ubuntu focal-updates/xena/main amd64 python3-openvswitch all 2.16.0-0ubuntu2.1~cloud0 [111 kB]
Get:2 http://ubuntu-cloud.archive.canonical.com/ubuntu focal-updates/xena/main amd64 openvswitch-common amd64 2.16.0-0ubuntu2.1~cloud0 [1214 kB]
Get:3 http://ubuntu-cloud.archive.canonical.com/ubuntu focal-updates/xena/main amd64 openvswitch-switch amd64 2.16.0-0ubuntu2.1~cloud0 [1604 kB]
Fetched 2930 kB in 1s (3485 kB/s)
(Reading database ... 92182 files and directories currently installed.)
Preparing to unpack .../python3-openvswitch_2.16.0-0ubuntu2.1~cloud0_all.deb ...
Unpacking python3-openvswitch (2.16.0-0ubuntu2.1~cloud0) over (2.15.0-0ubuntu3.1~cloud0) ...
Preparing to unpack .../openvswitch-common_2.16.0-0ubuntu2.1~cloud0_amd64.deb ...
Unpacking openvswitch-common (2.16.0-0ubuntu2.1~cloud0) over (2.15.0-0ubuntu3.1~cloud0) ...
Preparing to unpack .../openvswitch-switch_2.16.0-0ubuntu2.1~cloud0_amd64.deb ...
Unpacking openvswitch-switch (2.16.0-0ubuntu2.1~cloud0) over (2.15.0-0ubuntu3.1~cloud0) ...
Setting up python3-openvswitch (2.16.0-0ubuntu2.1~cloud0) ...
Setting up openvswitch-common (2.16.0-0ubuntu2.1~cloud0) ...
Setting up openvswitch-switch (2.16.0-0ubuntu2.1~cloud0) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for systemd (245.4-4ubuntu3.15) ...

$ sudo systemctl restart ovs-vswitchd.service
$ sudo systemctl restart neutron-openvswitch-agent
$ sudo systemctl restart neutron-l3-agent.service

Retest connectivity:

$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0
PING fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0(fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0) 56 data bytes

--- fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b
PING fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b(fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b) 56 data bytes

--- fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443
nc: connect to fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b port 9443 (tcp) timed out: Operation now in progress

$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 9443
nc: connect to fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 port 9443 (tcp) timed out: Operation now in progress

Check for changes in flows:

sudo ovs-ofctl dump-flows br-int --no-stats > br-int-ovs-2.16-flows.txt
sudo ovs-ofctl dump-flows br-tun --no-stats > br-tun-ovs-2.16-flows.txt

$ diff <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-int-ovs-2.15-flows.txt) <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-int-ovs-2.16-flows.txt)
23,25d22
< cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,icmp_type=130 actions=resubmit(,94)
< cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,icmp_type=133 actions=resubmit(,94)
< cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,icmp_type=135 actions=resubmit(,94)
29c26,28
< cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fe79:b646 actions=resubmit(,94)
---
> cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,icmp_type=130 actions=resubmit(,94)
> cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,icmp_type=133 actions=resubmit(,94)
> cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,icmp_type=135 actions=resubmit(,94)
30a30
> cookie=COOKIE, table=71, priority=95,icmp6,reg5=0x3,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fe79:b646 actions=resubmit(,94)
32d31
< cookie=COOKIE, table=71, priority=80,udp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,tp_src=546,tp_dst=547 actions=resubmit(,73)
33a33
> cookie=COOKIE, table=71, priority=80,udp6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646,tp_src=546,tp_dst=547 actions=resubmit(,73)
37d36
< cookie=COOKIE, table=71, priority=65,ipv6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646 actions=ct(table=72,zone=NXM_NX_REG6[0..15])
38a38
> cookie=COOKIE, table=71, priority=65,ipv6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fe80::f816:3eff:fe79:b646 actions=ct(table=72,zone=NXM_NX_REG6[0..15])

$ diff <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-tun-ovs-2.15-flows.txt) <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-tun-ovs-2.16-flows.txt)
2d1
< cookie=COOKIE, priority=1,in_port=2 actions=resubmit(,3)
3a3
> cookie=COOKIE, priority=1,in_port=2 actions=resubmit(,3)
20,21d19
< cookie=COOKIE, table=20, priority=2,dl_vlan=1,dl_dst=fa:16:3e:45:7a:a6 actions=strip_vlan,load:0x2aa->NXM_NX_TUN_ID[],output:2
< cookie=COOKIE, table=20, priority=2,dl_vlan=1,dl_dst=fa:16:3e:3e:bd:45 actions=strip_vlan,load:0x2aa->NXM_NX_TUN_ID[],output:2
23c21,22
< cookie=COOKIE, table=20, priority=2,dl_vlan=1,dl_dst=fa:16:3e:70:70:c9 actions=strip_vlan,load:0x2aa->NXM_NX_TUN_ID[],output:4
---
> cookie=COOKIE, table=20, priority=2,dl_vlan=1,dl_dst=fa:16:3e:3e:bd:45 actions=strip_vlan,load:0x2aa->NXM_NX_TUN_ID[],output:2
> cookie=COOKIE, table=20, priority=2,dl_vlan=1,dl_dst=fa:16:3e:45:7a:a6 actions=strip_vlan,load:0x2aa->NXM_NX_TUN_ID[],output:2
25a25
> cookie=COOKIE, table=20, priority=2,dl_vlan=1,dl_dst=fa:16:3e:70:70:c9 actions=strip_vlan,load:0x2aa->NXM_NX_TUN_ID[],output:4
27,28d26
< cookie=COOKIE, table=20, hard_timeout=300, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:3e:bd:45 actions=load:0->NXM_OF_VLAN_TCI[],load:0x2aa->NXM_NX_TUN_ID[],output:2
< cookie=COOKIE, table=20, hard_timeout=300, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:70:70:c9 actions=load:0->NXM_OF_VLAN_TCI[],load:0x2aa->NXM_NX_TUN_ID[],output:4
30a29,30
> cookie=COOKIE, table=20, hard_timeout=300, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:70:70:c9 actions=load:0->NXM_OF_VLAN_TCI[],load:0x2aa->NXM_NX_TUN_ID[],output:4
> cookie=COOKIE, table=20, hard_timeout=300, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:3e:bd:45 actions=load:0->NXM_OF_VLAN_TCI[],load:0x2aa->NXM_NX_TUN_ID[],output:2

The only changes are the cookie values and the order that dumpflow has written them out, the flows are actually unchanged

$ diff <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-int-ovs-2.15-flows.txt | sort) <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-int-ovs-2.16-flows.txt | sort)
$
$ diff <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-tun-ovs-2.15-flows.txt | sort) <(sed -e 's!cookie=[^,]*!cookie=COOKIE!g' br-tun-ovs-2.16-flows.txt | sort)
$

Connectivity can be restored by disabling port security on the ocatvia ports:

$ openstack port set --no-security-group --disable-port-security octavia-health-manager-octavia-0-listen-port

$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0
PING fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0(fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0) 56 data bytes
64 bytes from fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0: icmp_seq=1 ttl=64 time=2.96 ms

--- fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.955/2.955/2.955/0.000 ms

$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b
PING fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b(fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b) 56 data bytes
64 bytes from fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b: icmp_seq=1 ttl=64 time=2.11 ms

--- fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.113/2.113/2.113/0.000 ms

$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443
Connection to fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443 port [tcp/*] succeeded!

$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 9443
Connection to fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 9443 port [tcp/*] succeeded!

Re-enable port security

$ openstack port set --security-group 04582e3a-3093-4158-b66e-dfdd32665108 --enable-port-security octavia-health-manager-octavia-0-listen-port

Connectivity can be also be restored by manually installing permissive flows into the flows associated with br-int:

$ sudo ovs-ofctl add-flow br-int table=0,priority=96,icmp6,in_port=3,icmp_type=128,actions=NORMAL
$ sudo ovs-ofctl add-flow br-int table=0,priority=96,icmp6,in_port=2,icmp_type=129,actions=NORMAL
$ ping -c1 fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0
PING fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0(fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0) 56 data bytes
64 bytes from fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0: icmp_seq=1 ttl=64 time=4.23 ms

--- fc00:92e3:d18a:36ed:f816:3eff:fed2:32e0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.230/4.230/4.230/0.000 ms

$ sudo ovs-ofctl add-flow br-int table=0,priority=96,ipv6,in_port=3,actions=NORMAL
$ sudo ovs-ofctl add-flow br-int table=0,priority=96,ipv6,in_port=2,actions=NORMAL
$ nc -zvw2 fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443
Connection to fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b 9443 port [tcp/*] succeeded!

Tags: sts
Liam Young (gnuoy)
description: updated
Revision history for this message
Liam Young (gnuoy) wrote :
Download full text (4.5 KiB)

Capturing a ping packet from the src port o-hm0 and tracing it through the flows shows that it should work (below replicated here https://pastebin.ubuntu.com/p/SjVry2dncf/):

(While running ping fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b in another window. This ping is failing)

$ sudo tcpdump -i o-hm0 dst fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b -w icmp.pcap
$ ovs-pcap icmp.pcap > icmp.hex
$ PACKET=$(head -n1 icmp.hex)
$ sudo ovs-appctl ofproto/trace br-int in_port="o-hm0" $PACKET
Flow: icmp6,in_port=3,vlan_tci=0x0000,dl_src=fa:16:3e:79:b6:46,dl_dst=fa:16:3e:69:c8:5b,ipv6_src=fc00:92e3:d18a:36ed:f816:3eff:fe79:b646,ipv6_dst=fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b,ipv6_label=0x5660d,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=128,icmp_code=0

bridge("br-int")
----------------
 0. priority 0, cookie 0x9f446960f3350392
    goto_table:60
60. in_port=3, priority 100, cookie 0x9f446960f3350392
    set_field:0x3->reg5
    set_field:0x1->reg6
    resubmit(,71)
71. ipv6,reg5=0x3,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fc00:92e3:d18a:36ed:f816:3eff:fe79:b646, priority 65, cookie 0x9f446960f3350392
    ct(table=72,zone=NXM_NX_REG6[0..15])
    drop
     -> A clone of the packet is forked to recirculate. The forked pipeline will be resumed at table 72.
     -> Sets the packet to an untracked state, and clears all the conntrack fields.

Final flow: icmp6,reg5=0x3,reg6=0x1,in_port=3,vlan_tci=0x0000,dl_src=fa:16:3e:79:b6:46,dl_dst=fa:16:3e:69:c8:5b,ipv6_src=fc00:92e3:d18a:36ed:f816:3eff:fe79:b646,ipv6_dst=fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b,ipv6_label=0x5660d,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=128,icmp_c
ode=0
Megaflow: recirc_id=0,ct_state=-trk,eth,icmp6,in_port=3,dl_src=fa:16:3e:79:b6:46,ipv6_src=fc00:92e3:d18a:36ed:f816:3eff:fe79:b646,nw_frag=no,icmp_type=0x80/0xfe,nd_target=::
Datapath actions: ct(zone=1),recirc(0x3f)

===============================================================================
recirc(0x3f) - resume conntrack with default ct_state=trk|new (use --ct-next to customize)
===============================================================================

Flow: recirc_id=0x3f,ct_state=new|trk,ct_zone=1,eth,icmp6,reg5=0x3,reg6=0x1,in_port=3,vlan_tci=0x0000,dl_src=fa:16:3e:79:b6:46,dl_dst=fa:16:3e:69:c8:5b,ipv6_src=fc00:92e3:d18a:36ed:f816:3eff:fe79:b646,ipv6_dst=fc00:92e3:d18a:36ed:f816:3eff:fe69:c85b,ipv6_label=0x5660d,nw_tos=0
,nw_ecn=0,nw_ttl=64,icmp_type=128,icmp_code=0

bridge("br-int")
----------------
    thaw
        Resuming from table 72
72. ct_state=+new-est,ipv6,reg5=0x3, priority 74, cookie 0x9f446960f3350392
    resubmit(,73)
73. ct_state=+new-est,ipv6,reg5=0x3, priority 90, cookie 0x9f446960f3350392
    ct(commit,zone=NXM_NX_REG6[0..15])
    drop
     -> Sets the packet to an untracked state, and clears all the conntrack fields.
    resubmit(,91)
91. priority 1, cookie 0x9f446960f3350392
    resubmit(,94)
94. priority 1, cookie ...

Read more...

Revision history for this message
Liam Young (gnuoy) wrote :

The issue seems to be in ovs, specifically this commit https://github.com/openvswitch/ovs/commit/355fef6f2ccbcf78797b938421cb4cef9b59af13 . I have created a ppa https://launchpad.net/~gnuoy/+archive/ubuntu/focal-xena/+packages that has a copy of the openvswitch package from the xena-proposed UCA. The only change I have made is backing out that commit (and temporarily disabling auto pkg tests).

The following pastebin shows:
1) checking connectivity with ovs 2.15
2) upgrading to 2.16 and seeing that connectivity is broken
3) upgrading to 2.16 with 355fef6f2 reverted and seeing connectivity is restored

https://paste.ubuntu.com/p/nSHjRZzbmp/

Changed in neutron:
status: New → Invalid
Revision history for this message
Liam Young (gnuoy) wrote :
Revision history for this message
Pedro Victor Lourenço Fragola (pedrovlf) wrote :

OS: Ubuntu
Openstack: Xena

Using openvswitch-switch 2.16.0-0ubuntu2.1~cloud0 with IPv4 I'm facing the same issue, the workaround of disabling port security worked.

tags: added: sts
Revision history for this message
Frode Nordahl (fnordahl) wrote :

This is fixed by https://github.com/openvswitch/ovs/commit/88e3ae5d6f7370acbf1d9d60c1a06e4132e4e532 and we'll get it into Ubuntu in the next OVS point release.

Frode Nordahl (fnordahl)
affects: openvswitch → cloud-archive
Changed in openvswitch (Ubuntu Kinetic):
status: New → Triaged
importance: Undecided → High
status: Triaged → In Progress
status: In Progress → Fix Committed
status: Fix Committed → In Progress
Frode Nordahl (fnordahl)
Changed in openvswitch (Ubuntu Kinetic):
status: In Progress → Fix Released
Changed in openvswitch (Ubuntu Jammy):
status: New → Fix Released
Changed in openvswitch (Ubuntu Impish):
status: New → Won't Fix
Revision history for this message
Felipe Reyes (freyes) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.