Netplan replaces /etc/network/interfaces in Ubuntu 22.04: handling leftover entries and custom ifupdown scripts after upgrade

Direct answer

Confirmed: Netplan does not read /etc/network/interfaces. It renders only /etc/netplan/*.yaml into backend configuration for systemd-networkd (or NetworkManager). However, if the legacy networking.service is still enabled, ifupdown can independently raise interfaces from the old file. When both stacks act on the same NIC, you get duplicate addresses and routes. Neither file strictly wins in isolation—the active services determine the outcome.

Likely explanation: Because Ubuntu 20.04 server already defaulted to Netplan, an active /etc/network/interfaces after an in-place upgrade usually implies a deliberately retained ifupdown setup or desktop/NetworkManager packages. Verify the host actual state rather than assuming the file is inert.

Detecting leftovers before they cause duplicate routes

1. Run netplan generate and confirm it exits 0.
2. Inspect the generated files under /run/systemd/network/ and compare them with live state using ip -br addr and ip route. An address or route visible in the kernel but absent from the generated .network files indicates a leftover ifupdown path.
3. Check systemctl is-enabled networking.service. If it returns enabled, ifupdown is still a candidate to run at boot.
4. List hook scripts with ls /etc/network/if-*.d and inspect state with ifquery --state.

Bond plus VLAN: explicit renderer

Confirmed: Netplan default renderer is chosen based on installed and running packages. If NetworkManager is present, it may be selected. The NetworkManager backend has historically not mapped every bond parameter, so leaving the default risks the wrong daemon owning the bond or parameters being silently dropped. For a server bond with a VLAN, declare renderer: networkd explicitly at the top level.

Replacing custom ifupdown hook scripts

Confirmed: Netplan has no generic pre-up/post-up hook. For the networkd renderer, install the separate networkd-dispatcher package and place scripts under /etc/networkd-dispatcher/routable.d and related directories. These react to operational state changes rather than exact ifupdown events. Alternatively, use systemd units ordered against systemd-networkd-wait-online or network-online.target. Prefer native Netplan routes: and nameservers: over scripts wherever possible.

Can netplan try be relied on for rollback?

Confirmed: netplan try applies the candidate configuration and reverts if not confirmed within a timeout.

Likely explanation / caution: It is not a guaranteed remote safety net. If the change removes the path you are using to confirm (for example, the management IP or the bond only carrier), you may be unable to answer the prompt and must wait out the timeout. Rollback of already-applied runtime state has also been imperfect across netplan.io point releases. Keep a backup YAML and use a console or out-of-band session for the cutover.

One diagnostic detail that changes the recommendation

Is your only management access (SSH) running over the same bond or VLAN interface you are about to reconfigure? If yes, obtain console or out-of-band access before applying any change, and prefer netplan generate followed by netplan apply in a controlled maintenance window rather than relying on netplan try. If management is on a separate physical NIC, netplan try is lower risk but still not a substitute for a backup.

Assumptions and verification

This guidance assumes Ubuntu 22.04 LTS with the stock netplan.io and systemd packages. Because host-specific state must be verified, confirm the actual netplan.io version and systemd/networkd state on the host before deleting anything.