** Description changed:
- Environment
-
- neutron 28.0.0, OpenStack 2026.1 "Gazpacho" on Ubuntu 24.04 LTS
- (Noble, via Ubuntu Cloud Archive); confirmed still present on master.
+ [Impact]
On an ML2/OVS deployment with tunneling disabled
- (enable_tunneling=False, type drivers flat/vlan, no br-tun), neutron-
- openvswitch-agent crashes on restart.
-
- With tunneling off, self.tun_br is None, but _restore_local_vlan_map()
- calls self.tun_br.get_flood_to_tun_ofports() with no "if self.tun_br is
- not None" guard.
-
- Call path that crashes
-
- OVSNeutronAgent.__init__()
- -> _restore_local_vlan_map()
- -> if net_uuid: # True only after the agent has
run
- tun_ofports = self.tun_br.get_flood_to_tun_ofports(...)
- ^^^^^^^^^^^
- self.tun_br is None -> AttributeError
-
- Why it only happens on restart, not first start: the call sits behind
- "if net_uuid:", and an integration-bridge port only carries net_uuid in
- its OVS other_config after the agent has written it during normal
- operation.
-
- 1st start: ports have NO net_uuid -> if net_uuid: False -> skipped
-> OK
- restart: ports HAVE net_uuid -> if net_uuid: True -> call
-> crash
-
- So the first agent start is fine; every restart after that crashes
- deterministically.
-
- Traceback
+ (enable_tunneling=False, flat/vlan type drivers, no br-tun), neutron-
+ openvswitch-agent crashes on every restart:
ERROR neutron...ovs_oskenapp Agent main thread died of an exception:
AttributeError: 'NoneType' object has no attribute 'get_flood_to_tun_ofports'
File ".../ovs_neutron_agent.py", line 342, in __init__
self._restore_local_vlan_map()
File ".../ovs_neutron_agent.py", line 520, in _restore_local_vlan_map
tun_ofports = self.tun_br.get_flood_to_tun_ofports(local_vlan)
AttributeError: 'NoneType' object has no attribute
'get_flood_to_tun_ofports'
- Because the crash is in __init__, the agent never reaches rpc_loop and
- never (re)programs OVS flows; instances on the node lose provider-
- network connectivity until manual recovery, and it recurs on every
- restart.
+ _restore_local_vlan_map(), called from OVSNeutronAgent.__init__(), calls
self.tun_br.get_flood_to_tun_ofports() for every integration-bridge port
carrying other_config:net_uuid, without checking whether tunneling is enabled.
+ With tunneling disabled self.tun_br is None, so the call raises.
- Reproduce
+ The call sits behind "if net_uuid:", and an integration-bridge port only
+ carries net_uuid in its OVS other_config after the agent has written it
+ during normal operation:
- - deploy ML2/OVS with enable_tunneling=False
- - boot an instance on a flat/VLAN provider network (so the tap ports get
other_config:net_uuid)
- - restart neutron-openvswitch-agent.
+ 1st start: ports have NO net_uuid -> skipped -> OK
+ restart: ports HAVE net_uuid -> called -> crash
- Temporary workaround (recurs on next restart)
+ Because the crash happens in __init__, the agent never reaches rpc_loop and
never reprograms OVS flows, so instances on the node lose provider-network
connectivity until manual recovery.
+ Clearing net_uuid by hand recovers the agent once, but the agent rewrites it
during operation and the next restart crashes again:
ovs-vsctl remove Port <integration-bridge-tap-port> other_config net_uuid
systemctl restart neutron-openvswitch-agent
+
+ [Test Plan]
+
+ Deploy ML2/OVS with tunneling disabled on the target release:
+
+ # /etc/neutron/plugins/ml2/ml2_conf.ini
+ [ml2]
+ type_drivers = flat,vlan
+ tenant_network_types = vlan
+ mechanism_drivers = openvswitch
+
+ # /etc/neutron/plugins/ml2/openvswitch_agent.ini
+ [ovs]
+ enable_tunneling = False
+ bridge_mappings = physnet1:br-data
+
+ Boot an instance on a flat or VLAN provider network so that the agent
+ writes net_uuid into the integration-bridge port, then confirm the ports
+ carry it:
+
+ ovs-vsctl --columns=name,other_config list Port | grep net_uuid
+
+ Before the patch (reproduce the crash):
+
+ systemctl restart neutron-openvswitch-agent
+ journalctl -u neutron-openvswitch-agent -n 50
+
+ Expected (buggy) result:
+
+ AttributeError: 'NoneType' object has no attribute
+ 'get_flood_to_tun_ofports'
+
+ and the agent stays down.
+
+ After the patch (confirm the fix):
+
+ # install neutron-openvswitch-agent from -proposed
+ systemctl restart neutron-openvswitch-agent
+ systemctl is-active neutron-openvswitch-agent
+ journalctl -u neutron-openvswitch-agent -n 50
+ openstack network agent list --agent-type open-vswitch
+
+ Expected (fixed) result:
+
+ * The agent restarts without the AttributeError and reports active.
+ * The agent shows alive/UP in "openstack network agent list".
+ * Existing instances keep provider-network connectivity across the restart.
+ * On a tunneling-enabled (VXLAN/GRE) deployment, restarting the agent still
restores the br-tun flood output ports, so east-west traffic between compute
nodes continues to work.
+
+ [Where problems could occur]
+
+ If the enable_tunneling guard is evaluated incorrectly on a tunneling-
+ enabled deployment, the br-tun flood output ports are not restored on
+ agent restart and broadcast or unknown-unicast traffic on tunnel
+ networks either stops reaching remote compute nodes or is flooded to the
+ wrong ports.
+
+ [Other Info]
+
+ Fixed upstream on master and stable/2026.1 (neutron 28.0.1) by
+
https://opendev.org/openstack/neutron/commit/0b06dc038b685f3340c8a7cf7b07128ed5c39b27
+ Guard tun_br in _restore_local_vlan_map when no br-tun
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2156566
Title:
neutron-ovs-agent crashes on restart with tunneling disabled (tun_br
is None)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2156566/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
