Как согласовать обе стороны виртуального канала Ethernet?
Я запускаю docker контейнеры, которые все подключены к моему собственному мосту (не стандартному ] docker0 one) Вот так это выглядит с точки зрения хоста (я оставил только информацию, относящуюся к виртуальному мосту и 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 @ в контейнере?
Я вижу, что первый столбец на хосте имеет 13 , что похоже на eth0 @ if13 в контейнер. В свою очередь, eth0 @ if13 соответствует метке 12 в контейнере, которая обозначается как vethc225476 @ if12. на хосте. Я не знаю, совпадение ли это - если нет, то чему соответствуют первые метки столбцов в ip link ?
Как вы подозреваете, @ if13 действительно относится к числу в первом столбце, которое является числом ifindex (по крайней мере, "ifindex "- это имя переменной, предоставляемой libnl, используемой для передачи сетевой ссылки ядру для получения такой информации). Когда номер существует в том же пространстве имен, утилита ip показывает имя, связанное с номером, вместо номера (например, (скрытый) также может видеть поле 'link-netnsid', которое является другим целым числом, которое идентифицирует пространство имен, содержащее link (либо другой конец 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 связывает свои созданные netns с дайте им имя). Многие (большинство? Все?) Другие утилиты, в том числе docker, не делают этого, поэтому нет особой помощи в поиске другого конца хоста, заставляя пользователей выполнять ручной поиск других сетевых пространств имен (например, путем поиска все уникальные записи в /proc/*/ns/net).
Короче говоря, это помогает найти ссылку на хосте, когда вы знаете список ссылок контейнера, но не так много в поиске контейнера, когда у вас есть список ссылок хоста .
Последнее замечание о nsid s: они уникальны для каждой сети. nsid 0 хоста не совпадает с пространством имен nsid 0 в пространстве имен examplens в моем примере, например.