Netplan配置文件应用顺序及fallback配置设置咨询

Hey there! Let's break down your questions step by step—Netplan's config loading logic can feel a bit opaque at first, so I'll make it clear.

First: Which config gets applied? #

Netplan loads all YAML config files in /etc/netplan/ in lexicographical (dictionary) order based on their filenames. That means your 01-config.yaml will be loaded first, followed by 99-config.yaml.

The critical detail here: if both files define conflicting settings for the same Ethernet interface (like different authentication methods), the settings from the later-loaded file (99-config.yaml) will completely override the ones from the earlier one (01-config.yaml). In your current setup, only the config from 99-config.yaml will take effect for that interface—there's no fallback happening here, just a straight override.

Second: Can you set up a fallback config if the primary fails? #

Absolutely, but you can't rely on filename order alone (since that's just an override system). Instead, you need to adjust your configs to leverage Netplan's integration with its backend renderers (systemd-networkd or NetworkManager):

• Step 1: Configure your primary config (01-config.yaml)
  Add the optional: true parameter to your Ethernet interface. This tells the renderer that even if this interface fails to connect (e.g., authentication fails, no DHCP response), it shouldn't hang system startup or block other network configs from applying. Example snippet:

  network:
    version: 2
    ethernets:
      enp0s3:
        optional: true
        dhcp4: true
        auth:
          method: eap-tls
          # ... your primary auth settings
  

• Step 2: Create your fallback config (99-fallback.yaml)
  In this file, define the same interface with your backup settings, and set a higher metric value (higher metric means lower priority—so this config only kicks in if the primary fails). Example:

  network:
    version: 2
    ethernets:
      enp0s3:
        dhcp4: true
        metric: 100
        # No auth, or a simpler auth method as your fallback
  

  When the primary config's interface connects successfully, it will use a lower metric (you can explicitly set metric: 50 in the primary to be safe) and be prioritized. If the primary fails to connect, the renderer will fall back to the higher-metric fallback config.

• Note for NetworkManager users: If you're using NetworkManager instead of systemd-networkd, the logic is similar—define two separate connection profiles for the same interface, set their connection priorities, and mark the primary as "optional" so the fallback can take over if it fails.

That should give you exactly the fallback behavior you're looking for!

备注：内容来源于stack exchange，提问作者laxebisu