☁️ OpenStack Error: 'agent is not alive' Neutron Agent Down (alive=XXX)

Exact Error Message

$ openstack network agent list
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host     | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
| 3f2a1c9e-...                         | Open vSwitch agent | compute3 | None              | XXX   | UP    | neutron-openvswitch-agent |
| 8b7d4e21-...                         | DHCP agent         | net1     | nova              | XXX   | UP    | neutron-dhcp-agent        |
| c4e9a0f6-...                         | L3 agent           | net1     | nova              | :-)   | UP    | neutron-l3-agent          |
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+

In the neutron-server log you will see the corresponding message:

WARNING neutron.db.agents_db [-] Agent healthcheck: found 1 dead agents out of 12:
                Type       Last heartbeat  host
    Open vSwitch agent  2026-07-17 09:14:02  compute3

The XXX in the Alive column (or alive=False in the API) is the symptom: neutron-server has stopped receiving heartbeats from that agent.

What It Means

Every Neutron agent (Open vSwitch, DHCP, L3, metadata) periodically reports a heartbeat to neutron-server over the message bus. The server marks an agent dead when the gap since the last report_interval exceeds agent_down_time (default 75 seconds). Alive = XXX (or :-() means those heartbeats stopped arriving, not necessarily that the dataplane is broken — but until the agent reports in, Neutron will not schedule new resources onto it.

The most common root causes are a genuinely crashed agent process, a broken connection to RabbitMQ, or clock skew between the agent host and the controller that makes recent heartbeats look old.

Common Causes

• The agent process (neutron-openvswitch-agent, neutron-dhcp-agent, neutron-l3-agent) has crashed or is stuck.
• RabbitMQ is unreachable or the agent’s AMQP connection dropped, so heartbeats never reach neutron-server.
• Clock skew between the agent host and the controller (NTP not running) makes heartbeats appear stale.
• report_interval on the agent is larger than agent_down_time on the server, so the agent is flagged dead between reports.
• Resource exhaustion (OOM, full disk, pegged CPU) starving the agent’s reporting loop.
• For the OVS agent specifically, ovs-vswitchd or ovsdb-server is down, blocking the agent from initializing.

Diagnostic Commands

List agents and note which host and type is dead:

openstack network agent list --long

Show the details, including the last heartbeat timestamp:

openstack network agent show 3f2a1c9e-1234-5678-9abc-def012345678

On the affected host, check whether the process is actually running:

systemctl status neutron-openvswitch-agent
journalctl -u neutron-openvswitch-agent --since "-15min" --no-pager

Verify the message-bus connection and clock:

ss -tnp | grep 5672
timedatectl status
grep -E "report_interval|agent_down_time" /etc/neutron/neutron.conf

For the OVS agent, confirm the switch daemon is healthy:

ovs-vsctl show
systemctl status openvswitch-switch

Step-by-Step Resolution

1. Confirm the process state on the dead agent’s host. If it exited, read the tail of the log to find why (traceback, OOM kill, config error):

journalctl -u neutron-openvswitch-agent -n 100 --no-pager

2. Fix clock skew first if timedatectl shows NTP is not synchronized. A host that is even 90 seconds ahead will report heartbeats the controller treats as already expired:

sudo systemctl enable --now chrony
chronyc tracking

3. Restart the affected agent and watch it re-register:

sudo systemctl restart neutron-openvswitch-agent
openstack network agent list --agent-type open-vswitch --host compute3

4. If the agent still will not report, check RabbitMQ from the agent host. A blocked or partitioned broker stops heartbeats even though the process is up:

sudo rabbitmqctl list_connections | grep <agent-host-ip>

5. Align the timers if they are misconfigured. Ensure agent_down_time is at least three times report_interval:

# /etc/neutron/neutron.conf
[agent]
report_interval = 30
[DEFAULT]
agent_down_time = 75

Restart neutron-server after changing agent_down_time.

6. Once the agent shows Alive = :-), reschedule any resources that failed over. For DHCP, confirm the networks are hosted again:

openstack network agent list --agent-type dhcp
openstack network dhcp-agent list --network <network-id>

Prevention

• Run NTP (chrony or systemd-timesyncd) on every controller and agent host and alert on skew above a few seconds.
• Monitor openstack network agent list (or the neutron Prometheus exporter) and alert when any agent flips to dead.
• Keep agent_down_time comfortably larger than report_interval (a 3:1 ratio is a safe default).
• Give agent hosts memory headroom and alert on OOM kills so the reporting loop is never starved.
• Run RabbitMQ as a healthy, monitored cluster; heartbeat delivery depends on it.

Related Errors

• AMQP server on <host>:5672 is unreachable — the broker is down, which will flip agents dead across the board.
• neutron-dhcp-agent down — instances fail to get IPs because the DHCP agent stopped hosting networks.
• ovs-vswitchd is not running — the OVS dataplane is down, which cascades into an OVS-agent-not-alive state.
• Router was not hosted by any L3 agent — L3 scheduling failure after an L3 agent goes dead.

Frequently Asked Questions

Does Alive = XXX mean my instances lost networking? Not necessarily. Existing flows on the OVS dataplane often keep working, but Neutron will not schedule new ports, routers, or DHCP leases onto a dead agent until it reports in.

Why is only one agent dead when the others are fine? That points to a host-local problem — a crashed process, clock skew, or a dropped AMQP connection on that specific node — rather than a controller-wide RabbitMQ outage.

How does Neutron decide an agent is dead? It compares now - last_heartbeat against agent_down_time (default 75s). If the gap is larger, the agent is flagged dead, which is why clock skew so often causes false positives.

Can I automate diagnosing which agents are dead and why? Yes — you can turn openstack network agent list output plus the agent logs into a triage checklist with the DevOps AI prompt library.

Where do I go for more Neutron and OpenStack fixes? See the full OpenStack guides for related networking and control-plane troubleshooting.