[OVN] adding/removing floating IPs neutron server errors about binding port

[Ryan M Belgrave]

Using Zed and Ubuntu and OVN as the ml2 driver.

Neutron Server Version 21.0.0
OVN Version 22.09.0

When adding/removing floating IPs the neutron server errors with the following

2023-02-23 03:30:05.842 25044 INFO neutron.plugins.ml2.drivers.ovn.mech_driver.mech_driver [None req-accc7595-320b-47e4-93e4-b07f6b205295 - - - - - -] Refusing to bind port 5266e0cd-1064-4baa-9679-8c5f2eb13d29 on host sora due to the OVN chassis bridge mapping physical networks [] not supporting physical network: provider

2023-02-23 03:30:05.843 25044 ERROR neutron.plugins.ml2.managers [None req-accc7595-320b-47e4-93e4-b07f6b205295 - - - - - -] Failed to bind port 5266e0cd-1064-4baa-9679-8c5f2eb13d29 on host sora for vnic_type normal using segments [{'id': '5621a693-771d-4a57-beb4-d7a6e8dfc1b9', 'network_type': 'flat', 'physical_network': 'provider', 'segmentation_id': None, 'network_id': '71cbb38e-dc91-4db4-9a3a-7e499cd3fd69'}]

The floating IPs work as expected though so I am unsure why this error is given.

The host has been setup with the following bridge and mapping

ovs-vsctl --may-exist add-br br-provider -- set bridge br-provider protocols=OpenFlow13
ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-provider
ovs-vsctl --may-exist add-port br-provider veth1-provider

Looking at the ovn driver code I can see it gets the ovn bridge mappings here https://github.com/openstack/neutron/blob/stable/zed/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/impl_idl_ovn.py#L850

and if I get the mappings by hand I can see them set as expected bellow:

# ovn-sbctl list Chassis
_uuid : ac259942-1da8-425e-aaad-40f861771353
encaps : [17ba4674-5955-4dd7-847d-37ffc94dbc38, 3bf53123-6d0b-4422-8afc-7b52530ea782]
external_ids : {}
hostname : sora
name : "b8edbb46-b62a-4ca2-be87-872a83eb03d5"
nb_cfg : 0
other_config : {ct-no-masked-label="true", datapath-type=system, iface-types="bareudp,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", mac-binding-timestamp="true", ovn-bridge-mappings="provider:br-provider", ovn-chassis-mac-mappings="", ovn-cms-options=enable-chassis-as-gw, ovn-enable-lflow-cache="true", ovn-limit-lflow-cache="", ovn-memlimit-lflow-cache-kb="", ovn-monitor-all="false", ovn-trim-limit-lflow-cache="", ovn-trim-timeout-ms="", ovn-trim-wmark-perc-lflow-cache="", port-up-notif="true"}
transport_zones : []
vtep_logical_switches: []

I believe this error is being generated here https://github.com/openstack/neutron/blob/stable/zed/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L1004

but I am unsure why since everything still seems to work?

[Brian Haley (brian-haley)]

So this is a strange one.

From the error, it's showing that ovn-bridge-mappings is not set correctly:

"... OVN chassis bridge mapping physical networks [] ..."

But your ovn-sbctl output shows otherwise.

Are there any other log messages from the mech driver? There are a number of LOG.debug() calls in there that might help figure this out.

Thanks.

[Brian Haley (brian-haley)]

Oh, and the floating IP appears to work?

[yatin (yatinkarel)]

wrt the Error and OVN version included [1] is required which is not available in 21.0.0. Recently 21.1.0 is released and that includes the required fix so that can be used.

wrt Error Refusing to bind port that doesn't seem for FIP, can be confirmed with openstack server show <server_id> and openstack port show 5266e0cd-1064-4baa-9679-8c5f2eb13d29. Anyway best is to try newer neutron version and if you still see issue can be reopened.

[1] https://github.com/openstack/neutron/commit/af8a3a7f0810dc64ee51c8db38b49723fd5d3d17

[Ryan M Belgrave (rmb1993)]

@brian-haley

Yea floating IPs work perfectly, it's just that error message shows in the log.

@yatinkarel "openstack server show" and "openstack port show" shows the expected output with the floating IP attached. I will try upgrading to 21.1.0 and reply back.

[Ryan M Belgrave (rmb1993)]

Yup updating to 21.1.0 no longer prints that error message and FIPs continue to work as expected. So we can probably mark this bug as resolved in 21.1.0.