Unexpected and - probably - invalid interface in the ADD answer

[akunszt]

What happened:
We noticed that the latest version (1.18.2) includes a dummy interface in the ADD answer containing bad values.
The aws-vpc-cni received this request:

{
  "cniVersion": "0.4.0",
  "mtu": "9001",
  "name": "aws-cni",
  "pluginLogFile": "stderr",
  "pluginLogLevel": "DEBUG",
  "podSGEnforcingMode": "strict",
  "type": "aws-cni",
  "vethPrefix": "pod"
}

And sent back this answer, please note the extra dummy interface:

{
  "cniVersion": "0.4.0",
  "interfaces": [
    {
      "name": "pod7240c55beb0"
    },
    {
      "name": "eth0",
      "sandbox": "/var/run/netns/cni-92bc92ba-0c59-ee33-a6d0-88dd3a0be305"
    },
    {
      "name": "dummy7240c55beb0",
      "mac": "0",
      "sandbox": "0"
    }
  ],
  "ips": [
    {
      "version": "4",
      "interface": 1,
      "address": "10.24.136.194/32"
    }
  ],
  "dns": {}
}

The CNI spec 0.4.0 says that sandbox should be omitted for host interfaces and contain a valid path for the network namespace for container interfaces.

sandbox (string): container/namespace-based environments should return the full filesystem path to the network namespace of that sandbox. Hypervisor/VM-based plugins should return an ID unique to the virtualized sandbox the interface was created in. This item must be provided for interfaces created or moved into a sandbox like a network namespace or a hypervisor/VM.

The mac field should also contain a MAC addres or omitted if it is not relevant.

mac (string): the hardware address of the interface. If L2 addresses are not meaningful for the plugin then this field is optional.

Attach logs
I don't think this is relevant in this case as you have an actual request/answer but if you insist I can muster some logs.

What you expected to happen:
The answer should contain only valid interfaces.

How to reproduce it (as minimally and precisely as possible):
Deploy the aws-vpc-cni 1.18.2 and monitor the CNI requests and answers.

Anything else we need to know?:
I don't think this is a major bug. We noticed this by accident and it doesn't cause any issues for us, albeit we had to make small modifications in our code.

If you think this is not a bug then feel free to close this ticket.

Environment:

• Kubernetes version (use kubectl version): 1.28.9
• CNI Version: 1.18.2
• OS (e.g: cat /etc/os-release):

NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=3510.2.6
VERSION_ID=3510.2.6
BUILD_ID=2023-08-07-1638
SYSEXT_LEVEL=1.0
PRETTY_NAME="Flatcar Container Linux by Kinvolk 3510.2.6 (Oklo)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar.org/"
BUG_REPORT_URL="https://issues.flatcar.org"
FLATCAR_BOARD="amd64-usr"
CPE_NAME="cpe:2.3:o:flatcar-linux:flatcar_linux:3510.2.6:*:*:*:*:*:*:*"

• Kernel (e.g. uname -a):

Linux i-09fbb34a8edb3cff1 5.15.122-flatcar #1 SMP Mon Aug 7 16:02:38 -00 2023 x86_64 AMD EPYC 7R32 AuthenticAMD GNU/Linux

[orsenthil]

The response you are seeing is coming from this line

https://github.com/aws/amazon-vpc-cni-k8s/blob/71263b9a0af8422779291a3198732c797628ad9d/cmd/routed-eni-cni-plugin/cni.go#L231C1-L231C17

	dummyInterface = &current.Interface{Name: dummyInterfaceName, Mac: fmt.Sprint(0), Sandbox: fmt.Sprint(r.DeviceNumber)}

We have had this response since CNI 1.12 or earlier, and inclusion seems to be useful for clean up purposes

amazon-vpc-cni-k8s/cmd/routed-eni-cni-plugin/cni.go

Line 279 in 71263b9

// dummy interface is appended to PrevResult for use during cleanup

Don't think this is a recent change, and not sure there is any bug here.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.