я бегу docker контейнеры, которые все подключены к моему собственному мосту (не стандартный docker0 один). Вот как это выглядит с точки зрения хоста (я оставил только информацию, относящуюся к виртуальному мосту и Ethernet):
root@srv ~# ip link
(...)
8: br-7b20560b3603: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:7c:70:e1:47 brd ff:ff:ff:ff:ff:ff
9: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:f1:70:4f:a6 brd ff:ff:ff:ff:ff:ff
11: veth1fb5957@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7b20560b3603 state UP mode DEFAULT group default
link/ether 4e:38:69:b2:db:ef brd ff:ff:ff:ff:ff:ff link-netnsid 2
13: vethc225476@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7b20560b3603 state UP mode DEFAULT group default
link/ether 56:1d:d5:96:68:ac brd ff:ff:ff:ff:ff:ff link-netnsid 1
377: veth7fcee93@if376: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7b20560b3603 state UP mode DEFAULT group default
link/ether 62:06:5d:c7:31:7b brd ff:ff:ff:ff:ff:ff link-netnsid 4
431: vethd0879bb@if430: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7b20560b3603 state UP mode DEFAULT group default
link/ether 0a:f8:aa:02:a9:f4 brd ff:ff:ff:ff:ff:ff link-netnsid 3
245: veth4a8ecb1@if244: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7b20560b3603 state UP mode DEFAULT group default
link/ether d6:86:f1:8b:73:ab brd ff:ff:ff:ff:ff:ff link-netnsid 0
При подключении к одному из контейнеров вижу
root@vpnin ~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:0a:c8:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
Топология такова, что на хосте br-7b20560b3603 имеет несколько veth* как дочерние элементы, и каждый из них связан с контейнером - эта другая сторона становится контейнером eth0.
Как я могу узнать, какой veth* на хосте соответствует eth0@<something> в контейнере?
Я вижу, что в первом столбце хоста 13, что похоже на eth0@if13 в контейнере. Взаимно, eth0@if13 соответствует этикетке 12 в контейнере, который обозначается как vethc225476@if12 на хосте. Я не знаю, совпадение ли это - если нет, то что означают метки первых столбцов в ip link соответствовать?
Как вы подозреваете, @if13 относится к номеру в первом столбце, который является ifindex число (по крайней мере, «ifindex» - это имя переменной, предоставляемой libnl, используемой для передачи сетевой ссылки ядру для получения такой информации). Когда номер существует в том же пространстве имен, утилита ip показывает имя, связанное с номером, вместо номера (например, myvlan@eth0).
Вы также можете увидеть поле 'link-netnsid', которое является другим целым числом, которое идентифицирует пространство имен, содержащее ссылку (либо другой конец пары veth, как у вас здесь, либо иным образом обрабатывает другой конец устройства, например как пространство имен, IP-адрес которого используется для туннельного устройства). Вы можете перечислить тех, у кого ip netns list-id (по крайней мере, на последних версиях iproute2). Если пространство имен смонтировано в обычном месте, рядом с идентификатором будет отображаться имя пространства имен сети.
Примеры:
$ sudo ip link add name veth1 type veth peer name veth2
$ ip link show | grep veth
32: veth2@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
33: veth1@veth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group
$ sudo ip netns add examplens
$ sudo ip link setns examplens dev veth2
$ ip link show | grep -a1 veth
33: veth1@if32: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether e2:99:ce:05:64:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 2
$ ip netns list-id
nsid 0
nsid 1
nsid 2 (iproute2 netns name: examplens)
$ sudo ip -n examplens link
1: lo: <LOOPBACK> 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
32: veth2@if33: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 3a:89:30:01:4a:49 brd ff:ff:ff:ff:ff:ff link-netnsid 0
В приведенном выше примере мы создаем пару veth и видим, как на обоих концах отображается имя другого конца. Затем мы создаем netns с именем examplens и переместите в него veth2. Теперь ip больше не знает имени узла veth1, но по-прежнему имеет ifnumber, поэтому вместо этого он показывает (if32), который, как мы можем видеть, это то, что было до его перемещения. Мы также видим, что ссылка находится в netnsid (nsid) 2, который, как мы видим, называется examplens.
Перечисление ссылок в examplens показывает veth2, у его однорангового узла ifnumber 33 в netnsid 0.
К сожалению, утилита ip не поможет вам найти, где находится nsid, когда он не привязан, и запись в /var/run/netns (где ip Утилита bind монтирует свои созданные netns, чтобы дать им имя). Многие (большинство? Все?) Другие утилиты, в том числе docker, не делают этого, поэтому нет особой помощи в поиске другого конца хоста, заставляя пользователей выполнять ручной поиск других сетевых пространств имен (например, путем поиска все уникальные записи в / proc / * / ns / net).
Короче говоря, это помогает найти ссылку на хосте, когда вы знаете список ссылок контейнера, но не так много, чтобы найти контейнер, когда у вас есть список ссылок хоста.
Последнее замечание о nsids: они уникальны для каждой сети. nsid 0 хоста - это не то же пространство имен, что и nsid 0 в пространстве имен examplens в моем примере, например.