Вот метод, которым я следовал, чтобы понять, как понять эту проблему. Доступные инструменты кажутся пригодными для использования (с некоторой сверткой )для части пространства имен, и (ОБНОВЛЕНО )с помощью /sys/ можно легко получить индекс партнера. Так что это довольно долго, потерпите меня. Он состоит из двух частей (, которые расположены не в логическом порядке, но сначала пространство имен помогает объяснить наименования индексов ), используя обычные инструменты, а не какую-либо пользовательскую программу :

.

• Сетевое пространство имен
• Индекс интерфейса

Сетевое пространство имен

Эта информация доступна со свойством link-netnsidв выводе ip linkи может быть сопоставлена ​​с идентификатором в выводе ip netns. Можно «связать» сетевое пространство имен контейнера с ip netns, используя таким образом ip netnsв качестве специализированного инструмента. Конечно, было бы лучше сделать для этого специальную программу (немного информации о системных вызовах в конце каждой части ).

Об описании нсидов вот что man ip netnsрассказывает (курсив мой):

ip netns set NAME NETNSID - assign an id to a peer network namespace

This command assigns a id to a peer network namespace. This id is valid only in the current network namespace. This id will be used by the kernel in some netlink messages. If no id is assigned when the kernel needs it, it will be automatically assigned by the kernel. Once it is assigned, it's not possible to change it.

Хотя создание пространства имен с ip netnsне приведет к немедленному созданию netnsid, оно будет создано (в текущем пространстве имен, возможно, на «хосте» ), когда veth половина настроена на другое пространство имен. Поэтому он всегда устанавливается для типичного контейнера.

Вот пример использования контейнера LXC:

# lxc-start -n stretch-amd64

Появилась новая вет ссылка veth9RPX4M(это можно отследить с помощьюip monitor link). Вот подробная информация:

# ip -o link show veth9RPX4M
44: veth9RPX4M@if43:  mtu 1500 qdisc noqueue master lxcbr0 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether fe:25:13:8a:00:f8 brd ff:ff:ff:ff:ff:ff link-netnsid 4

Эта ссылка имеет свойство link-netnsid 4, сообщающее другой стороне, что она находится в сетевом пространстве имен с nsid 4.Как проверить, что это контейнер LXC? Самый простой способ получить эту информацию — заставить ip netnsповерить в то, что он создал сетевое пространство имен контейнера, выполнив операции, указанные на справочной странице .

# mkdir -p /var/run/netns
# touch /var/run/netns/stretch-amd64
# mount -o bind /proc/$(lxc-info -H -p -n stretch-amd64)/ns/net /var/run/netns/stretch-amd64

UPDATE3:Я не понимал, что найти обратно глобальное имя было проблемой. Вот он:

# ls -l /proc/$(lxc-info -H -p -n stretch-amd64)/ns/net
lrwxrwxrwx. 1 root root 0 mai    5 20:40 /proc/17855/ns/net -> net:[4026532831]

# stat -c %i /var/run/netns/stretch-amd64 
4026532831

Теперь информация извлекается с помощью:

# ip netns | grep stretch-amd64
stretch-amd64 (id: 4)

Это подтверждает, что узел veth находится в сетевом пространстве имен с тем же nsid = 4 = link -netnsid.

Контейнер/ip netns«ассоциацию» можно удалить (без удаления пространства имен, пока контейнер работает):

# ip netns del stretch-amd64

Примечание. :Именование nsid относится к сетевому пространству имен, обычно начинается с 0 для первого контейнера, а наименьшее доступное значение используется повторно с новыми пространствами имен.

Информация об использовании системных вызовов, полученная из strace:

• для части ссылки :требуетсяAF_NETLINKсокет (, открытый с помощью socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)), запрос(sendmsg())информации о ссылке с типом сообщенияRTM_GETLINKи получение(recvmsg())ответа с типом сообщения RTM_NEWLINK.

• для части netns nsid :тот же метод, сообщение запроса имеет типRTM_GETNSIDс типом ответа RTM_NEWNSID.

Я думаю, что есть библиотеки немного более высокого уровня для обработки этого:libnl . В любом случае это тема для SO .

Индекс интерфейса

Теперь будет легче понять, почему индекс ведет себя случайным образом. Давайте проведем эксперимент:

Сначала введите новое пространство имен сети, чтобы получить чистый (индекс )список:

# ip netns add test
# ip netns exec test bash
# ip netns id
test
# ip -o link 
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Как заметил OP, lo начинается с индекса 1.

Добавим 5 сетевых пространств имен, создадим пары veth,затем наденьте на них конец:

# for i in {0..4}; do ip netns add test$i; ip link add type veth peer netns test$i ; done
# ip -o link|sed 's/^/    /'
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth0:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether e2:83:4f:60:5a:30 brd ff:ff:ff:ff:ff:ff link-netnsid 0
3: veth1@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 22:a7:75:8e:3c:95 brd ff:ff:ff:ff:ff:ff link-netnsid 1
4: veth2@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 72:94:6e:e4:2c:fc brd ff:ff:ff:ff:ff:ff link-netnsid 2
5: veth3@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether ee:b5:96:63:62:de brd ff:ff:ff:ff:ff:ff link-netnsid 3
6: veth4@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether e2:7d:e2:9a:3f:6d brd ff:ff:ff:ff:ff:ff link-netnsid 4

Когда он отображает @if2 для каждого из них, становится совершенно ясно, что индекс и индекс интерфейса пространства имен партнера не являются глобальными, а для каждого пространства имен. Когда он отображает фактическое имя интерфейса, это отношение к интерфейсу в том же пространстве имен (, будь то одноранговый узел, мост, связь... ). Так почему же у veth0 не отображается одноранговый узел? Я считаю, что это ошибка ip link, когда индекс совпадает с самим собой. Простое двукратное перемещение одноранговой ссылки «решает» проблему здесь, потому что это приводит к изменению индекса. Я также уверен, что иногда ip linkвызывает другие недоразумения и вместо отображения @ifXX отображает интерфейс в текущем пространстве имен с тем же индексом.

# ip -n test0 link set veth0 name veth0b netns test
# ip link set veth0b netns test0
# ip -o link
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth0@if7:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether e2:83:4f:60:5a:30 brd ff:ff:ff:ff:ff:ff link-netnsid 0
3: veth1@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 22:a7:75:8e:3c:95 brd ff:ff:ff:ff:ff:ff link-netnsid 1
4: veth2@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 72:94:6e:e4:2c:fc brd ff:ff:ff:ff:ff:ff link-netnsid 2
5: veth3@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether ee:b5:96:63:62:de brd ff:ff:ff:ff:ff:ff link-netnsid 3
6: veth4@if2:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether e2:7d:e2:9a:3f:6d brd ff:ff:ff:ff:ff:ff link-netnsid 4

ОБНОВЛЕНИЕ:повторное чтение информации в вопросе OP, индекс партнера (, но не nsid ), легко и однозначно доступен с помощьюcat /sys/class/net/interface/iflink.

ОБНОВЛЕНИЕ2:

Все эти iflink 2 могут показаться неоднозначными, но уникальным является сочетание nsid и iflink, а не только iflink. Для приведенного выше примера это:

interface    nsid:iflink
veth0        0:7
veth1        1:2
veth2        2:2
veth3        3:2
veth4        4:2

В этом пространстве имен (, а именно пространстве имен test), никогда не будет двух одинаковых пар nsid :.

Если посмотреть в каждой одноранговой сети противоположную информацию:

namespace    interface    nsid:iflink
test0        veth0        0:2
test1        veth0        0:3
test2        veth0        0:4
test3        veth0        0:5
test4        veth0        0:6

Но имейте в виду, что все 0:есть для каждого отдельного 0, который сопоставляется с одним и тем же одноранговым пространством имен (, а именно :пространством имен test, даже не с хостом ). Их нельзя сравнивать напрямую, потому что они привязаны к своему пространству имен. Таким образом, вся сравнимая и уникальная информация должна быть:

test0:0:2
test1:0:3
test2:0:4
test3:0:5
test4:0:6

Как только подтверждается, что "test0 :0" == "test1 :0" и т. д. (верно в этом примере, все сопоставляются с сетевым пространством имен, называемым testпо ip netns), тогда они могут реально сравнить.

О системных вызовах, все еще просматривая результаты strace, информация извлекается, как указано выше, изRTM_GETLINK.Теперь вся информация должна быть доступна:

локальный :индекс интерфейса сSIOCGIFINDEX/if_nametoindex
peer :и nsid, и индекс интерфейса сRTM_GETLINK.

Все это, вероятно, следует использовать с libnl .