Description of problem: Neutron does not make sure the router attached logical ports are provider networks before enabling the send_periodic flag on the ipv6_ra_config row. This leads the RAs the ovn-controller generates for tenant networks to leak out against the DC network via the provider network. The relevant code is: https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L1021. The code confirms there's no type check happening, the only statement is making sure IPv6 is enabled and either SLAAC or DHCPv6 are being used. Version-Release number of selected component (if applicable): How reproducible: 100% of the times Steps to Reproduce: 1. Create a Neutron router which also comes with IPv6 2. ovn-nbctl show $ROUTER_ID ; ovn-nbctl get logical_router_port $PORT_ATTACHED_TO_PROVIDER_NETWORK ipv6_ra_config 3. Verify the port contains: send_periodic=true Actual results: The port contains send_periodic=true even when the port itself is the one attached to a provider network Expected results: The RAs should only ever be sent against tenant networks and should not leak against DC networks. Additional info:
Fixed in: python-networking-ovn-7.3.1-1.20210324163508.el8ost https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35802988 http://download.eng.bos.redhat.com/brewroot/vol/rhel-8/packages/python-networking-ovn/7.3.1/1.20210324163508.el8ost/
Can we please get confirmation that this issue will be fixed in 16.1.5?
(In reply to Priscila from comment #10) > Can we please get confirmation that this issue will be fixed in 16.1.5? Hi Priscila, According to the program call updates 16.1.5 was shipped already (March 31st), so I would expect this to be included in 16.1.6.
Verified manually (undercloud) [stack@undercloud-0 ~]$ cat core_puddle_version RHOS-16.1-RHEL-8-20210421.n.1 [heat-admin@controller-0 ~]$ sudo podman exec -it ovn_controller /bin/bash ()[root@controller-0 /]# rpm -qa | grep ovn ovn2.13-20.12.0-85.el8fdp.x86_64 rhosp-ovn-host-2.13-10.el8ost.noarch puppet-ovn-15.4.1-1.20201113171358.192ac4e.el8ost.noarch rhosp-ovn-2.13-10.el8ost.noarch ovn2.13-host-20.12.0-85.el8fdp.x86_64 ()[root@controller-0 /]# exit exit [heat-admin@controller-0 ~]$ sudo podman exec -it neutron_api /bin/bash ()[neutron@controller-0 /]$ rpm -qa | grep ovn puppet-ovn-15.4.1-1.20201113171358.192ac4e.el8ost.noarch python3-networking-ovn-7.3.1-1.20210409093428.4e24f4c.el8ost.noarch _uuid : 39fbfff2-b9ff-44b3-99b7-16636720f010 enabled : [] external_ids : {"neutron:network_name"=neutron-1fb936a2-4336-4cf2-8944-1d9a9c85e7c2, "neutron:revision_number"="3", "neutron:router_name"="fecdb982-d5a5-4c90-a4e6-1744220f5e1c", "neutron:subnet_ids"="1360bd92-3e46-4f80-bb66-bf1348d970db"} gateway_chassis : [] ha_chassis_group : [] ipv6_prefix : [] ipv6_ra_configs : {address_mode=slaac, mtu="1442", send_periodic="true"} mac : "fa:16:3e:35:8a:5b" name : lrp-580fb996-0729-4eb5-a78e-ef3f14427f86 networks : ["2002::1/64"] options : {} peer : [] also verified with functional test https://rhos-ci-jenkins.lab.eng.tlv2.redhat.com/view/DFG/view/network/view/networking-ovn/job/DFG-network-networking-ovn-16.1-dsvm-functional-rhos/125/testReport/networking_ovn.tests.functional.test_router/TestRouter/ according this tests the issue fixed
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.6 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:2097