Proxmox VE 9.2 Reboot Drill to Verify SDN and VLANs

A Proxmox VE 9.2 upgrade can leave SDN zones listed in the GUI while the Linux bridge, VLAN filtering, or firewall rules fail to come back correctly after a host reboot. This 10-minute drill captures the SDN and network state before reboot, restarts the node, then proves that zones, vnets, subnets, bridge VLANs, routes, and VM reachability survived. Run it before you call the node production-ready.

Key Takeaways

• Reboot proves order: A reboot tests whether Proxmox VE 9.2 starts SDN, networking, firewall, and VM autostart in the right sequence.
• API plus bridge: The SDN API can look correct while the Linux bridge is missing VLANs, so check both layers.
• Diff is fast: Comparing saved before and after files finds regressions in seconds instead of guessing from the GUI.
• Traffic proves rules: A ping and SSH test show that firewall rules and VLAN segmentation still allow the paths you expect.
• Cold reboot wins: A warm network restart is quicker, but it does not prove boot-time behavior.

Why a reboot drill matters after the 9.2 upgrade

Proxmox VE 9.2 can change packaging, dependencies, and service interactions, but the most common production surprises are still boot-time ones. A node can run for weeks after an upgrade, then lose a VLAN or firewall rule the first time someone reboots it. That failure mode is annoying because the configuration may be present in the GUI while the running kernel state is wrong.

The SDN stack makes this more visible than the old manual bridge setup. Zones, vnets, and subnets are managed through the cluster configuration, but they still depend on Linux bridges, VLAN filtering, routes, and the Proxmox firewall service. A reboot forces all of those pieces to start from an empty state.

If you have not already completed the Proxmox VE 9.2 upgrade checklist, finish that first. This drill assumes the upgrade is installed and the node is stable enough to reboot. The Proxmox VE 9.2 SDN audit checklist is also useful if you need to confirm the expected zones and vnets before you start.

Check	Warm restart	Host reboot	What to look for
SDN zones	Usually stays loaded	Must reload from cluster storage	Same zone names and types after boot
Bridge VLANs	May stay in kernel	Must be rebuilt by networking	Required VLAN IDs appear on the bridge
Routes	Usually stay	Must be rebuilt from interface config	Default route and subnet routes match
Firewall service	May stay active	Must start after networking	Enabled firewall files match running state
VM networking	Depends on VM state	VMs must boot and get addresses	Ping and SSH succeed from the management path

How to capture the SDN baseline before reboot

Open a root shell on the upgraded node. The commands below write small files in the root home directory, so use a shell that can write there. If you run this on a cluster member, the SDN API returns cluster-wide objects, but the bridge and route state are local to that node.

pveversion -v
pvesh get /cluster/sdn/zones --output-format json > /root/sdn-zones-before.json
pvesh get /cluster/sdn/vnets --output-format json > /root/sdn-vnets-before.json
pvesh get /cluster/sdn/subnets --output-format json > /root/sdn-subnets-before.json

These captures answer the first question: what should the node be able to see after it comes back? The zone file is the top-level SDN object. The vnet file shows the networks attached to zones. The subnet file shows address pools, gateways, and DNS settings that VMs may rely on.

Record bridge VLANs and routes

The SDN API is only half of the story. VLAN segmentation ultimately depends on the bridge and the kernel forwarding state. Capture that too.

ip -br addr > /root/network-before.txt
bridge vlan show > /root/bridge-vlan-before.txt
ip route show > /root/routes-before.txt
qm list > /root/vms-before.txt
grep -r "enable: 1" /etc/pve/firewall 2>/dev/null > /root/firewall-enabled-before.txt || true

The bridge VLAN output is the one I check first. On a VLAN-aware bridge, it should show the VLANs that your vnets expect on the bridge and physical port. If the list is incomplete, the SDN GUI can still look healthy while traffic is dropped at the host.

Check the bridge config matches the SDN vnets

For a VLAN-aware bridge, the interface configuration must include the VLAN IDs that the SDN vnets will use. A mismatch is a classic reboot failure.

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10,11,12,20,30

A gotcha I have hit more than once: an SDN vnet can reference a VLAN that is missing from the bridge VLAN list. The GUI may show the vnet, but the running bridge does not allow that VLAN. After a reboot, the missing VLAN is gone from the running state, and the failure only appears when a VM on that VLAN tries to reach the gateway.

How to reboot and watch the network come back

Reboot the node from the shell, or use the GUI if you prefer. The shell path keeps the drill consistent when you repeat it.

systemctl reboot

Wait for SSH to return, then check the services that matter for SDN and firewalling. The first boot after an upgrade is where you want to see the journal, not guess from a dashboard.

journalctl -u networking.service -b --no-pager
systemctl is-active networking.service
systemctl is-active pve-firewall
systemctl is-active fail2ban

On a small homelab node with three SDN zones, eight VLANs, and 12 VMs, I budget about 80 seconds for the networking service to settle and about 10 minutes for the full drill. Larger clusters with many vnets or slow storage can take longer, but the check itself stays short.

If fail2ban is not installed, the status command still returns a harmless inactive result. If you use it for SSH hardening, this is a quick reminder that it survived the reboot and started before your first management SSH session.

How to prove the zones survived the reboot

Compare the SDN API state

Run the same SDN captures again and diff them against the baseline. A clean pass produces no diff output.

pvesh get /cluster/sdn/zones --output-format json > /root/sdn-zones-after.json
pvesh get /cluster/sdn/vnets --output-format json > /root/sdn-vnets-after.json
pvesh get /cluster/sdn/subnets --output-format json > /root/sdn-subnets-after.json

diff /root/sdn-zones-before.json /root/sdn-zones-after.json
diff /root/sdn-vnets-before.json /root/sdn-vnets-after.json
diff /root/sdn-subnets-before.json /root/sdn-subnets-after.json

If the zone list changed, do not assume the upgrade rewrote your configuration. More often, a cluster FS mount delay or a service start order issue caused the API to return an incomplete view. Re-run the capture after the services settle before editing anything.

Compare the Linux bridge and route state

The bridge and route diff is where many VLAN issues show up. It also catches interface names that changed after a kernel update or udev rename.

ip -br addr > /root/network-after.txt
bridge vlan show > /root/bridge-vlan-after.txt
ip route show > /root/routes-after.txt
qm list > /root/vms-after.txt
grep -r "enable: 1" /etc/pve/firewall 2>/dev/null > /root/firewall-enabled-after.txt || true

diff /root/network-before.txt /root/network-after.txt
diff /root/bridge-vlan-before.txt /root/bridge-vlan-after.txt
diff /root/routes-before.txt /root/routes-after.txt
diff /root/firewall-enabled-before.txt /root/firewall-enabled-after.txt

A missing VLAN in the bridge VLAN output means the bridge did not apply the expected VLAN filtering. A missing route means the interface configuration did not come up the way it did before the reboot. A firewall-enabled diff can mean the firewall files exist but the Proxmox firewall service did not load them, or it can mean you changed rules between the two captures.

For firewall rule review, see the Proxmox SDN firewall audit for VE 9.2 network zones. The reboot drill does not replace a rule audit, but it proves the rules that passed the audit are still applied after boot.

How to test VM networking and firewall rules

Configuration files can match while the data path is still broken. The last part of the drill sends real packets.

Ping the gateway and VM addresses

Adjust the example addresses to match your management gateway and a few VMs on different SDN subnets. Replace the gateway address if your host uses a different management network.

ping -c 3 -W 2 192.168.1.1
for ip in 10.20.30.10 10.20.30.11 10.20.30.12; do
  ping -c 2 -W 2 "$ip"
done

I use three VMs when possible: one on the same VLAN as the host, one on a second VLAN, and one that crosses a router or firewall boundary. That gives a quick map of whether the problem is host bridge VLAN filtering, VM routing, or a policy rule.

SSH and fail2ban checks

If your production path uses SSH hardening, test from the same jump host or management VLAN you normally use. A successful SSH connection from the Proxmox host alone does not prove that your external management path still works.

ssh -o ConnectTimeout=5 [email protected] 'hostname'
systemctl is-active pve-firewall
systemctl is-active fail2ban
journalctl -u pve-firewall.service -b --no-pager
journalctl -u fail2ban.service -b --no-pager

The SSH test proves that the VM is reachable, the route exists, and the firewall allows the management connection. The journal lines are useful when fail2ban starts but cannot bind or when the Proxmox firewall reports a rule parse problem.

What this 10-minute drill does not prove

This drill proves boot-time persistence, not full failover. It does not prove that live migration works, that a second node can take over, or that your SDN controller is redundant. It also does not prove that every VM passed its own guest networking setup; it only proves that the addresses you tested are reachable.

The honest tradeoff is time. A warm network restart can be done in a minute, but it can hide ordering bugs because the kernel already has bridges, VLANs, and routes loaded. A reboot costs downtime, but it is the only way to know that Proxmox VE 9.2 will bring the node back the way you expect after a power loss or maintenance window.

Build a 10-minute checklist

1. Confirm the node is running Proxmox VE 9.2 and the upgrade checklist is complete.
2. Capture SDN zones, vnets, subnets, bridge VLANs, routes, VM list, and enabled firewall files.
3. Reboot the node and watch the networking service after it returns.
4. Re-run the same captures and diff them against the baseline.
5. Ping a gateway and a few VM addresses, then test SSH from the management path.

Conclusion

A reboot drill turns the Proxmox VE 9.2 upgrade from a package list into a working network claim. If the SDN API, bridge VLANs, routes, firewall state, and VM reachability all match after reboot, you have solid evidence that zones and segmentation survived the upgrade. Next, run the same drill on the second node before you schedule any VM migration or firewall change.