Secondary IPv4 addresses and policy routing rules silently ignored when a lower-priority network file exists

[mjnowen]

Secondary IPv4 addresses and policy routing rules silently ignored when a lower-priority network file exists

Description

When amazon-ec2-net-utils is installed on a distribution that uses another network config generator (e.g. netplan on Ubuntu, or cloud-init), the secondary IPv4 alias addresses and policy routing rules configured by the refresh timer are silently ignored by systemd-networkd.

The root cause is that create_ipv4_aliases() and create_rules() in lib.sh write their drop-in config files to a hardcoded 70-<iface>.network.d/ directory. However, systemd-networkd only reads drop-in files for the active .network file assigned to an interface — the one with the lowest numerical prefix that matches.

If another generator creates a .network file with a lower prefix (e.g. 10-netplan-ens5.network from netplan/cloud-init), then systemd-networkd uses that file and completely ignores 70-ens5.network along with all of its drop-ins.

The result is that:

• ec2net_alias.conf (secondary IPv4 addresses) is written to disk correctly but never applied to the interface.
• ec2net_policy_*.conf (policy routing rules) is written but never applied.
• ip addr show <iface> never shows the secondary IPs.
• networkctl status <iface> shows the lower-numbered file as active with no mention of the 70- drop-ins.

Steps to reproduce

1. Launch an Ubuntu 24.04 EC2 instance (tested on c6i.2xlarge and i3en.3xlarge).

2. Install amazon-ec2-net-utils v2.7.2 from source.

3. Verify netplan generates /run/systemd/network/10-netplan-ens5.network.

4. Assign a secondary private IPv4 address via the AWS CLI:

   aws ec2 assign-private-ip-addresses \
       --network-interface-id <eni-id> \
       --secondary-private-ip-address-count 1

5. Wait for the refresh-policy-routes@ens5 timer to fire.

6. Observe ip addr show ens5 — the secondary IP does not appear.

Expected behaviour

The secondary IP should appear on the interface within one refresh cycle, as shown by both ip addr show ens5 and networkctl status ens5.

Actual behaviour

The ec2net_alias.conf drop-in file is written to /run/systemd/network/70-ens5.network.d/ec2net_alias.conf with the correct [Address] section, but systemd-networkd never reads it because the active network file for ens5 is /run/systemd/network/10-netplan-ens5.network.

# Active network file (from netplan):
Network File: /run/systemd/network/10-netplan-ens5.network

# Drop-in written to the WRONG parent (ignored):
/run/systemd/network/70-ens5.network.d/ec2net_alias.conf

Environment

• Instance types: c6i.2xlarge, i3en.3xlarge
• OS: Ubuntu 24.04 LTS (Noble Numbat) with kernel 6.19.10
• amazon-ec2-net-utils: v2.7.2 (also reproducible on v2.5.3)
• netplan.io: 1.1.2-8ubuntu1~24.04.1
• systemd: 255.4-1ubuntu8.8

Suggested fix

Add a helper function that queries systemd-networkd runtime state (/run/systemd/netif/links/<ifindex>) to discover the actual NETWORK_FILE for the interface, then write drop-in configs under that file's .d/ directory. Fall back to the existing 70-<iface>.network.d path if detection is unavailable (e.g. during early boot before networkd has initialised).

I will post a PR for this fix.

[joeysk2012]

Same, I faced this issue as well when a new experimental systemd-module creates a new drop-in file that is supposed to be applied but ec2-net-utils already created a conf that is lower in priority.

Still this fix assumes that ec2-net-utils executes second and overwrites the existing network config. If ec2-net-utils executes first and netplan executes second then we will still end up with two network configs. Do you expect that to happen?

[mjnowen]

No — during boot, netplan's systemd generator runs during the early generator phase (before any services start), so 10-netplan-*.network is always on disk before systemd-networkd.service begins and before policy-routes@.service is triggered by udev. ec2-net-utils cannot run first in this sequence.

For hot-plugged ENIs at runtime, netplan does not dynamically generate configs — it is a generator, not a runtime daemon — so 70-<iface>.network is the only file and becomes the active one. No conflict arises.

If a lower-numbered file is created at runtime after ec2-net-utils has already written drop-ins (e.g. via netplan apply or the experimental systemd-module you mentioned), the existing 70- drop-ins would be orphaned until the next refresh timer fires (≤60 s), at which point _get_active_dropin_dir() detects the new active file and writes drop-ins to the correct .d/ directory. Without this fix, they remain permanently orphaned.

The coexistence of 70-<iface>.network alongside a lower-numbered file is pre-existing — create_interface_config() unconditionally creates it regardless of this change. The inert 70- file is harmless since networkd ignores it in favour of the lower-numbered match.