What does at sign (@) mean in interface name in output of "ip address" command (or the "ip link" command) on Ubuntu, for example interface name "eth0@if44" in the following output:

root@aafa1fc24a0b:/# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
    link/ipip brd
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1
    link/tunnel6 :: brd ::
43: eth0@if44: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet brd scope global eth0
       valid_lft forever preferred_lft forever

Additional relevant information:

  • This is on Ubuntu 16.04
  • Running inside a docker container
  • The container is attached to a user-defined bridge
  • The interface in question (eth0@if44) is not a VLAN

The setup was created as follows:

docker network create my-bridge
docker run --name my-container-1 --network my-bridge --detach --tty ubuntu:16.04 sleep infinity
docker run --name my-container-2 --network my-bridge --detach --tty ubuntu:16.04 sleep infinity

This represents the link's peer interface index. Although this property appears to be available for any interface, it makes sense for only a few interface types : veth, macvlan, vlan (sub-interface), ... because they have a relation to an other interface.

Any given interface has an index that can be read for example there:


Its peer link interface can be read there:


Apparently, if it doesn't make sense, the parameter still exists, but is the same as ifindex. That would be the case for usual normal or simple interfaces (real hardware eth0, wlan0, dummy0, ...)

The ip link commands just interprets the iflink value:

  • if iflink is 0 (apparently for ipip tunnels, which also behave strangely with net namespaces), it will print @NONE
  • if iflink doesn't have matching ifindex, it will display @ifXX with XX being ifindex. Not having a matching ifindex is enough to know it's related to an other net namespace, see later.
  • if iflink is itself (iflink == ifindex) It will not display any @. That's what should happen with real interfaces (eth0 ...) but can also be a bug (see later).
  • if iflink has a matching ifindex, it will display this index' name.

When wouldn't it find a matching ifindex? When that interface is in an other network namespace. This is known because of the link-netnsid appended at the end of the result. This value isn't easily available outside of ip link (see this Q/A: How to find the network namespace of a veth peer ifindex?). It reprensents the locally assigned nsid of the corresponding peer network namespace. For a container, the first (and probably only) value of 0 will almost always represent the host's net namespace. For an host, there will probably be one link-netnsid value per container, with the first container's link-netnsid being 0. Note that this value is local to the net namespace, not an absolute id, so it can't be compared directly between two net namespaces (see previous link).

So not finding an ifindex certainly means it's in an other namespace. It's confirmed by the presence of a link-netnsid property.

Sometimes the iflink, that is the index value of the peer interface, when in an other net namespace, happens to have the same id as the local interface (in the current net namespace). ip link will not display any @ in this case, with the logic that it's a common interface, but that would wrong, as in this case:

# ip -o link show dev veth1
3: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 7e:d9:ca:77:87:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0
# cat /sys/class/net/veth1/{ifindex,iflink}

(note the presence of link-netnsid 0 meaning the link is in an other net namespace.)

In other cases (that I didn't manage to reproduce, so it was perhaps corrected) it might even display a local interface name using the other net namespace index.

For your example, if you run on the host (not in the container): ip -o link |grep ^44:. You will most certainly find an interface with index 44, which is the peer's veth link. (Unless there's an intermediate invisible net namespace).

  • Thank you for a very clear answer. As you hypothesized, there was indeed a veth interface with index 44 in the host (a Moby VM on MacOS): 44: veth134a6e9@if43: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-e599a65c40f6 state UP link/ether 06:a2:00:a8:dc:93 brd ff:ff:ff:ff:ff:ff inet6 fe80::4a2:ff:fea8:dc93/64 scope link valid_lft forever preferred_lft forever – Bruno Rijsman May 20 '18 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.