Proxmox LXC restores create duplicate MAC addresses causing ARP flaps and intermittent container network loss

Environment

Proxmox VE 7.1 cluster, vzdump-based backups of multiple LXC containers restored to same cluster. Bridge is vmbr0 on a hardware switch with static port security entries.

Symptoms

After restoring several containers from backups, several containers intermittently lose network connectivity; ping from other hosts shows intermittent responses and ARP tables on the switch show the same MAC learned on different ports in rapid succession. Some containers' network interfaces become unreachable and services inside containers show 'connection reset by peer' errors.

Observations

Inspecting /etc/pve/lxc/<id>.conf for affected containers shows identical 'hwaddr' MAC values on net0 entries for multiple containers. The switch's MAC address table (CAM) flips between ports connected to different hypervisor nodes. Reassigning a new MAC in the Proxmox GUI for one container restored its connectivity until another restore created another collision. vzdump restore options did not include a 'generate new MAC' flag in the invoked command line used by operator scripts.

Already attempted

Restarted pods and containers, restarted network on host and containers, manually edited /etc/pve/lxc/<id>.conf to change hwaddr and restarted container network; that fixed some cases. Tried using pct restore with different flags but existing restore process used a scripted path that preserved config entries. Cleared relevant switch CAM entries where possible; collisions reappeared after additional restores.

Question

What is the safest procedure to avoid MAC duplication across LXC restores in Proxmox and how to remediate duplicates already present without causing widespread downtime?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

vzdump backups preserved the hwaddr MAC and the restore process wrote identical hwaddr into multiple container configs. 95%

Operator restore scripts invoked pct restore without generating new network device identifiers. 90%

Upstream switch port-security or lack of CAM aging allows stale entries to persist, worsening collision symptoms. 45%

Summary

Proxmox stores the container network MAC (hwaddr) in the LXC config and vzdump backups may include this value. Restoring from backups that preserve hwaddr will create duplicate MACs if multiple containers keep the same hwaddr in the cluster or across hosts. Switches react to duplicate source MACs with constant relearning, causing ARP flaps and packet loss. The correct long-term solution is to ensure restore process either generates unique MACs or assigns new ones post-restore and to clear stale MAC entries on upstream switches.

Suggested Fixes

Diagnostic step 1

Before further restores, modify restore scripts to omit hwaddr from the restored config or pass a flag to pct restore that forces generation of a new MAC. For scripted restores, remove or replace any 'hwaddr:' line in the backup config before writing to /etc/pve/lxc/<id>.conf.

Diagnostic step 2

For existing duplicates, pick one container at a time during a maintenance window, set a new MAC using Proxmox GUI or by editing /etc/pve/lxc/<id>.conf net0 entry (e.g., hwaddr: 02:XX:XX:XX:XX:XX), then restart the container network. Use a pattern in locally administered MAC range (02: prefix).

Diagnostic step 3

On the physical switch, clear the CAM table entries for affected MACs or bounce the relevant switch ports to force relearning. Coordinate with network admin for managed switches—do not clear entire CAM table in production without authorization.