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:
/sys/class/net/<interface>/ifindex
Its peer link interface can be read there:
/sys/class/net/<interface>/iflink
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}
3
3
(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).