[Bug 2156566] Re: neutron-ovs-agent crashes on restart with tunneling disabled (tun_br is None)
Seyeong Kim
2156566 at bugs.launchpad.net
Tue Jul 28 07:08:56 UTC 2026
** Also affects: neutron (Ubuntu)
Importance: Undecided
Status: New
** Changed in: neutron (Ubuntu)
Status: New => In Progress
** Also affects: neutron (Ubuntu Resolute)
Importance: Undecided
Status: New
** Changed in: neutron (Ubuntu Resolute)
Status: New => In Progress
** Changed in: neutron (Ubuntu)
Assignee: (unassigned) => Seyeong Kim (seyeongkim)
** Changed in: neutron (Ubuntu Resolute)
Assignee: (unassigned) => Seyeong Kim (seyeongkim)
** Changed in: cloud-archive/gazpacho
Status: New => In Progress
** Changed in: cloud-archive/gazpacho
Assignee: (unassigned) => Seyeong Kim (seyeongkim)
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/2156566
Title:
neutron-ovs-agent crashes on restart with tunneling disabled (tun_br
is None)
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive gazpacho series:
In Progress
Status in neutron:
Fix Released
Status in neutron package in Ubuntu:
In Progress
Status in neutron source package in Resolute:
In Progress
Bug description:
Environment
neutron 28.0.0, OpenStack 2026.1 "Gazpacho" on Ubuntu 24.04 LTS
(Noble, via Ubuntu Cloud Archive); confirmed still present on master.
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
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.
Reproduce
- 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.
Temporary workaround (recurs on next restart)
ovs-vsctl remove Port <integration-bridge-tap-port> other_config net_uuid
systemctl restart neutron-openvswitch-agent
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2156566/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list