web-dev-qa-db-ja.com

仮想イーサネットリンクの両側を一致させる方法は？

dockerコンテナを実行します。これらはすべて、独自のブリッジに接続されています（標準のdocker0コンテナではありません）。これは、ホストの観点からは次のようになります（仮想ブリッジとイーサネットに関連する情報のみを残しました）。

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

コンテナの1つに接続すると、

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の最初の列ラベルは何に対応していますか？

networkingvirtualizationlinux-networkingbridge
2
WoJ

ご想像のとおり、@if13は最初の列の番号を参照します。これはifindex番号です（少なくとも、「ifindex」はlibnlによって公開され、会話に使用される変数の名前です）。この種の情報を取得するためのカーネルへのネットリンク）。番号が同じ名前空間に存在する場合、ipユーティリティは番号の代わりに番号に関連付けられた名前を表示します（例：myvlan@eth0）。

また、別の整数であるフィールド 'link-netnsid'も表示されます。これは、リンクを保持している名前空間を識別します（ここにあるように、vethペアのもう一方の端、またはデバイスのもう一方の端を処理します。 IPアドレスがトンネルデバイスに使用される名前空間として）。それらはip netns list-idでリストできます（少なくとも最近のバージョンのiproute2では）。名前空間が通常の場所にマウントされている場合は、IDの横にネットワーク名前空間の名前が表示されます。

例：

$ 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ペアを作成し、両端にもう一方の端の名前が表示されていることを確認できます。次に、examplensという名前のネットを作成し、veth2をその中に移動します。これで、ipはveth1のピアの名前を認識しなくなりましたが、ifnumberを保持しているため、代わりに（if32）が移動前の状態であることがわかります。また、リンクがnetnsid（nsid）2にあることもわかります。これは、examplensという名前です。

Examplens内のリンクをリストすると、veth2が表示され、そのピアのnetnsid0にifnumber33があります。

残念ながら、ipユーティリティは、nsidがバインドされていないときにnsidがどこにあるかを見つけて、/var/run/netns（ipユーティリティバインドが作成されたnetnをマウントしてそれらに名前）。 dockerを含め、他の多くの（ほとんど？すべて？）ユーティリティはこれを行わないようです。そのため、ホストからもう一方の端を見つけて、ユーザーに他のネットワーク名前空間を手動で検索させる（たとえば、/proc/*/ns/net内のすべての一意のエントリ）。

つまり、これは、コンテナーのリンクリストがわかっている場合はホスト上のリンクを見つけるのに役立ちますが、ホストのリンクリストがある場合はコンテナーを見つけるのにそれほど役立ちません。

nsidsに関する最後の注意：それらはネットごとに一意です。たとえば、ホストのnsid 0は、私の例のexamplens名前空間のnsid 0と同じ名前空間ではありません。

3
John O'M.