Why a VLAN Interface Disappears on Debian After Reboot
When a VLAN interface disappears on Debian after a reboot, the tempting move is to interrogate the 8021q module or the VLAN stanza itself. On at least one documented Debian 13 case, that instinct pointed the wrong way, and the actual failure was one layer below the VLAN entirely.
The reported mystery: an Intel X540-AT2 10Gbps adapter on Debian 13 had carried a working ens1.99 VLAN since Debian 11, until it silently stopped appearing in ip addr and ip link after a reboot.
The networking.service journal showed the real signal, and it wasn’t about VLANs at all. The first failure was logged the day of a reboot, with “Cannot find device ens1.99” recorded as a downstream symptom rather than the initiating cause.
Tempting Explanations That Don’t Hold Up
The first suspect is usually the kernel module: is 8021q loaded, is the vlan package installed, is dmesg throwing errors. In the reported case, all three checked out clean, which ruled out a missing-driver explanation.
The second suspect is the VLAN stanza syntax itself — vlan_raw_device versus the hyphenated vlan-raw-device, or switching to a bridge config. Rewriting the stanza, dropping vlan_raw_device, and moving to a bridge setup each failed to restore the interface.
Both explanations are attractive because they’re VLAN-specific and match the visible symptom: ens1.99 is the interface that’s missing. But an explanation that only accounts for the VLAN and ignores the parent interface’s own boot failure is incomplete.
The Discriminating Check: Read the Parent Interface Errors First
The netplan generator’s own model for interface configuration draws a hard line between physical devices, which can dynamically appear and disappear across boots and hot-plug events, and virtual devices, which stay fully under the renderer’s control. A VLAN sits on top of a physical parent, so if the parent never comes up, the VLAN was never eligible to be created in the first place.
The discriminating check is not “does the VLAN config parse” but “does the parent interface bring up cleanly first.” In the reported log, ifup failed for ens1 twice, each time with “Error: ipv4: Address already assigned,” before ifup ever reported it “could not bring up parent interface ens1”.
That ordering is the tell. The parent interface bring-up aborted before ifupdown reached the point in its sequence where it would create ens1.99, which is why the VLAN interface was absent from ip link rather than present but misconfigured.
The Mechanism Behind the Failure
ifupdown processes interfaces in the order defined by the interfaces file, and a VLAN’s creation is gated on its vlan_raw_device successfully coming up first. When ens1 fails with an address-already-assigned error, ifupdown does not proceed to build ens1.99 on top of it.
The most likely trigger for “Address already assigned” is a second actor claiming the same address before or during networking.service’s own attempt to configure it — for example, both an auto line and an allow-hotplug line trying to own the same interface, or a stale state file left from an earlier run. The evidence does not establish which of these applied on the reported system.
What the log excerpt establishes as observed fact is narrower than it looks: the parent interface failed before the VLAN stanza was reached, and the duplicate-address error preceded that failure. The specific source of the duplicate claim — a second daemon, a leftover /run/network/ifstate entry, or a config collision between auto and allow-hotplug — is reasonable inference, not confirmed cause, based on the available evidence.
This is a case where the visible failure, a missing VLAN interface, and the actual failure, a parent interface address conflict, are two hops apart in the boot sequence. Debugging the VLAN stanza in isolation cannot surface a problem that occurs before ifupdown ever evaluates that stanza.
Fix Options, Trade-offs, and a Verification Checklist
Choose a targeted ifupdown fix — removing allow-hotplug from a server’s static interfaces, clearing stale /run/network/ifstate entries, and standardizing on vlan-raw-device over vlan_raw_device — when the environment must stay on the classic /etc/network/interfaces model and minimizing migration risk matters more than long-term maintainability.
Choose a renderer migration to netplan instead when this class of “which service claims this interface” ambiguity has recurred more than once. netplan’s design explicitly separates interfaces it manages from interfaces it leaves untouched, removing the specific failure mode of two subsystems racing to configure the same device.
| Approach | Best when | Constraint |
|---|---|---|
| Patch ifupdown config (drop allow-hotplug, clear stale ifstate, standardize vlan-raw-device) | System must stay on /etc/network/interfaces | Does not prevent a future address collision from a different source |
| Migrate to netplan | Recurring “who owns this interface” conflicts across multiple NICs | Requires rewriting interface definitions in YAML and choosing a renderer explicitly |
Neither path is validated as a guaranteed fix for the reported case; the accepted answer frames the parent-interface failure as the likely cause but does not confirm the underlying trigger for the address conflict. The broader community backlog on VLAN-tagged interfaces shows this class of problem recurring across unrelated stacks — VLAN tagging that appears correct at the packet level while failing at the interface-management layer — which supports treating the management layer as the first place to look, not the tagging itself.
Kernel-side VLAN handling has also seen active bug-fix activity independent of any distribution’s interface-management tooling. A recent Oracle Linux kernel errata batch included fixes for VLAN filter loss on add and delete races and for PF confirmation ordering in the iavf driver. That confirms VLAN-adjacent bugs do occur at the driver level, but it involves a different Intel NIC driver family and a different failure signature than an interface that never appears at all, so it should not be assumed to explain a missing ens1.99 without separate confirmation.
Before applying either fix, verify the exact sequence in the networking.service journal on the next boot: confirm whether the parent interface’s ifup attempt fails first, and if so, capture what else is holding or duplicating its address before touching the VLAN configuration at all. If the parent interface reports success and the VLAN stanza still fails to spawn ens1.99, the root cause shifts back to the 8021q module or the stanza syntax, and the fixes above will not apply.
A useful rollback check for any renderer migration is confirming that the old /etc/network/interfaces file remains in place and re-enableable, since netplan and ifupdown are not designed to run the same interface concurrently under two owners. Keep that fallback path documented before removing the legacy configuration.