Reviewed: https://review.opendev.org/c/openstack/neutron/+/954570 Committed: https://opendev.org/openstack/neutron/commit/79e9b02c6567b60992e36325c292117cb647f9a6 Submitter: "Zuul (22348)" Branch: master
commit 79e9b02c6567b60992e36325c292117cb647f9a6 Author: Slawek Kaplonski <[email protected]> Date: Wed Jul 9 14:47:48 2025 +0200 [ML2/OVN] Validate allowed address pairs and distributed ports In the ML2/OVN backend, if IP address of the unbound port is added to the other port as `allowed_address_pair`, OVN treats this port as `virtual`. This could break connectivity to the metadata service as it uses "special" port with device_owner set to `network:distributed` and this port is `unbound`. So if someone would add IP address assigned to such `network:distributed` port to the allowed_address_pair of the other port, connectivity to the metadata will be broken. This patch adds new validation of the allowed_address_pairs by the OVN mech_driver. If IP address set as allowed_address_pair is used by the `network:distributed` port, such API request will return BadRequest error code and allowed_address_pair will not be set for the port. Closes-Bug: #2116249 Depends-On: https://review.opendev.org/c/openstack/tempest/+/955569 Change-Id: I9b54e12fbd9b930a79660f2be195641107a5754e Signed-off-by: Slawek Kaplonski <[email protected]> ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2116249 Title: OVN network metadata is broken if allowed-address is configured using the same IP Status in neutron: Fix Released Bug description: Bug was originally reported by Mathew Flusche at https://issues.redhat.com/browse/OSPRH-17820 for Red Hat Openstack but I confirmed it happens also on the upstream OpenStack with master branch. Original description: Setting the subnet's dhcp/metadata IP as an allowed_address for a port causes a metadata outage. To Reproduce Steps to reproduce the behavior: {{openstack network create net1 openstack subnet create --subnet-range 10.1.1.0/24 --network net1 subnet1 openstack router create router1 openstack router add subnet router1 subnet1 openstack router set --external-gateway external2 router1 openstack server create --image rhel8 --key-name default --network net1 --flavor rhel vm3 openstack floating ip create external2 openstack server add floating ip vm3 192.168.2.176 Verify metadata works fine. $ ssh [email protected] [cloud-user@vm3 ~]$ curl 169.254.169.254 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 In OVN, verify metadata port is correctly set as type: localport openstack port list --device-owner network:distributed --network net1 ---------------------------------------------------------------------------------------------------------------------------------------- ID Name MAC Address Fixed IP Addresses Status ---------------------------------------------------------------------------------------------------------------------------------------- 7103f027-0736-49c2-804d-50ecbc8329ed fa:16:3e:32:0a:81 ip_address='10.1.1.2', subnet_id='d2f5d2dc-2814-4848-b3e2-bbfadf375046' DOWN ---------------------------------------------------------------------------------------------------------------------------------------- ovn-sbctl list port_binding 7103f027-0736-49c2-804d-50ecbc8329ed |grep ^type type : localport All good, delete the test instance (so metadata proxy is removed for the net): openstack server delete vm3 Create test port and allowed-address that will break ovn metadata. openstack port create --network net1 testport openstack port set --allowed-address ip-address=10.1.1.2 testport Create VM instance and verify metadata is broken. openstack server create --image rhel8 --key-name default --network net1 --flavor rhel vm3 openstack server add floating ip vm3 192.168.2.176 [cloud-user@vm3 ~]$ curl -v 169.254.169.254 Rebuilt URL to: 169.254.169.254/ Trying 169.254.169.254... TCP_NODELAY set connect to 169.254.169.254 port 80 failed: No route to host Failed to connect to 169.254.169.254 port 80: No route to host Closing connection 0 curl: (7) Failed to connect to 169.254.169.254 port 80: No route to host Verify in OVN the metadata port is now type: virtual and has a virtual parent pointing the test port. ovn-sbctl list port_binding 7103f027-0736-49c2-804d-50ecbc8329ed |egrep '^type|^options' options : {requested-chassis="", virtual-ip="10.1.1.2", virtual-parents="429f0583-0eae-459b-b4a2-004d26c88485"} type : virtual In the metadata agent debug logs we see the following indicating the misconfigured metadata port: Jun 27 13:59:45 compute18-node2 ovn_metadata_agent[2307]: 2025-06-27 13:59:45.833 2473 INFO neutron.agent.ovn.metadata.agent [-] Port da7b948e-865a-4a12-805b-23684f 8fa208 in datapath 30eba16f-5e67-44d5-9560-7f49a60d9d85 bound to our chassis Jun 27 13:59:45 compute18-node2 ovn_metadata_agent[2307]: 2025-06-27 13:59:45.834 2473 DEBUG neutron.agent.ovn.metadata.agent [-] There is no metadata port for netw ork 30eba16f-5e67-44d5-9560-7f49a60d9d85 or it has no MAC address configured, tearing the namespace down if needed _get_provision_params /usr/lib/python3.9/site-pac kages/neutron/agent/ovn/metadata/agent.py:682 To resolve the issue, remove the allowed-address and trigger the port reconfig by removing/adding dhcp to the network. openstack port set --no-allowed-address testport openstack subnet set --no-dhcp subnet1 openstack subnet set --dhcp subnet1 Port type is fixed and curl works from VM: ovn-sbctl list port_binding 7103f027-0736-49c2-804d-50ecbc8329ed |egrep '^type|^options' options : {requested-chassis=""} type : localport [cloud-user@vm3 ~]$ curl 169.254.169.254 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 }} Expected behavior Network metadata should have priority and the allowed-address config should fail. Bug impact Metadata outage for impacted network Additional context This issue was found on an OSP 16.2 environment but reproduces on RHOSO 18 also. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2116249/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
