Link aliases cannot be used as part of commands

[astro-stan]

Bug Report

I am unable to use the Talos 1.12+ link aliases as part of commands.

Description

These are my NICs:

 $ talosctl get links
NODE        NAMESPACE   TYPE         ID                VERSION   ALIAS     TYPE       KIND     HW ADDR                                           OPER STATE   LINK STATE
...
192.1.10.2   network     LinkStatus   eth0              3         ethSel1   ether               .................                                 down         false
192.1.10.2   network     LinkStatus   eth1              4         ethSel0   ether               .................                                 up           true
...

The eth* names are not very stable, so I have added aliases which are matched by MAC address.

I wish to use these aliases in a Multus CNI config like so:

---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-network
  namespace: multus-cni-config
spec:
  config: '{
    "cniVersion": "0.3.1",
    "name": "mynet",
    "type": "macvlan",
    "master": "ethSel0",
    "mode": "bridge",
    "ipam": {
        ...
    }
  }'
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-bridge-pod
  namespace: multus-cni-config
  annotations:
    k8s.v1.cni.cncf.io/networks: |
      [{
        "name": "macvlan-network",
        ...
      }]
spec:
  containers:
  - name: busybox-container
    image: busybox:1.36
    command:
     ...

However, when I apply this, I get the following event:

1s          Warning   FailedCreatePodSandBox   Pod/busybox-bridge-pod   Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "29db43d54a15f1b1294f7c3b39d9bc1b09e69f88864109bf0ca2abfe44a075e6": plugin type="multus-shim" name="multus-cni-network" failed (add): CmdAdd (shim): CNI request failed with status 400: 'ContainerID:"29db43d54a15f1b1294f7c3b39d9bc1b09e69f88864109bf0ca2abfe44a075e6" Netns:"/var/run/netns/cni-331e6937-783c-c462-3a2e-b7fd136ae2bb" IfName:"eth0" Args:"K8S_POD_NAMESPACE=multus-cni-config;K8S_POD_NAME=busybox-bridge-pod;K8S_POD_INFRA_CONTAINER_ID=29db43d54a15f1b1294f7c3b39d9bc1b09e69f88864109bf0ca2abfe44a075e6;K8S_POD_UID=a76d7eee-68b6-48ed-bc95-bc99cd298a9d;IgnoreUnknown=1" Path:"" ERRORED: error configuring pod [multus-cni-config/busybox-bridge-pod] networking: [multus-cni-config/busybox-bridge-pod/a76d7eee-68b6-48ed-bc95-bc99cd298a9d:mynet]: error adding container to network "mynet": Link not found

Changing "master": "ethSel0" to "master": "eth1" fixes this.

Multus is even set up to chroot into the host when running CNI binaries, so there should be no reason for this not to work.

Logs

Environment

• Talos version: 1.12.1
• Kubernetes version: 1.35.0
• Platform: amd64 bare-metal

[astro-stan]

I investigated this further, and it seems that Talos only adds the name as an interface alias, not as an altname:

# ip link show eth1
9: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    alias ethSel0
    altname enp5s0
    altname enxaabbccddeeff

I suppose that is on purpose, however, aliases cannot be used as part of commands, like altnames can.

If I add the name as an altname like so:

# ip link property add dev eth1 altname ethSel0 

I can use ethSel0 in the multus config.

Can Talos add the link aliases as altnames as well? I can't think of a reason where this would be undesired.

[smira]

altnames are managed by udevd, we don't want to clash with udevd on that side of things.

Probably better to ask Multus to honor aliases?

[astro-stan]

Probably better to ask Multus to honor aliases?

I don't think this is a Multus-specific thing. Multus is basically a glorified "script" that calls other CNI binaries with specific arguments.

As I understand it, an alias is just a symbolic name for a device. These names are for reference only and cannot be used as real device names in many standard networking commands. This is why passing the alias name to any of the CNI binaries fails with "link not found".

altnames on the other hand are a newer kernel feature (introduced around 2019) that provides a different way to identify the physical device itself. They can be up to 255 characters long and unlike aliases, they are treated as "equal" to the primary kernel name.

[brightdroid]

Same Problem here, I used this until now (which worked):

machine:
    install:
        extraKernelArgs:
            - net.ifnames=0

Now as "extraKernelArgs" is removed, I tried LinkAliasConfig which does not the same (rename device) only add an alias, which is not usable by most programs like multus or even simple ip a s DEV.

[brightdroid]

Update, sorry previous comment is wrong, got it working with following config without LinkAliasConfig:

machine:
    install:
        extraKernelArgs:
            - net.ifnames=0
        grubUseUKICmdline: false