同じ名前空間にある veth デバイスから ICMP 応答がありません。

同じ名前空間にある veth デバイスから ICMP 応答がありません。

Ubuntu 16.04では、次のようにvethデバイスのペアを作成しました。

$ sudo ip link add veth1 type veth peer name veth2
$ sudo ip link set dev veth1 up
$ sudo ip link set dev veth2 up
$ sudo ip address add 10.0.10.50/24 dev veth1
$ sudo ip address add 10.0.10.51/24 dev veth2

veth デバイスのペアは同じ名前空間にあります。あるvethデバイスから別のデバイスへのpingをテストしようとしています。だから私は次のようにpingを試しました。

$ ping -I veth1 10.0.10.51
PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 veth1: 56(84) bytes of data.
From 10.0.10.50 icmp_seq=1 Destination Host Unreachable
From 10.0.10.50 icmp_seq=2 Destination Host Unreachable
From 10.0.10.50 icmp_seq=3 Destination Host Unreachable

veth2のwiresharkトレースを確認すると、ARP要求に応答しません(veth1についても同様のトレースが観察されます)。

 Broadcast  ARP 42  Who has 10.0.10.51? Tell 10.0.10.50

veth1と同じ名前空間のICMP要求にveth2が応答できないのはなぜですか?

修正する: 次のように ping しようとすると ICMP 応答を受け取りますが、Wireshark は veth1 および veth2 デバイスのトレース情報を表示しません。

 $ ping -I 10.0.10.50 10.0.10.51
 PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 : 56(84) bytes of data.
 64 bytes from 10.0.10.51: icmp_seq=1 ttl=64 time=0.016 ms
 64 bytes from 10.0.10.51: icmp_seq=2 ttl=64 time=0.022 ms

2つのpingテストの結果の違いを説明できる人はいますか?

ベストアンサー1

部分的な答え:

2番目のバリエーションでは、次のことを行うか、tcpdump -ni loWiresharkを使用すると、ループバックインターフェイスで通信が行われていることがわかります。これは、カーネルが両方のアドレスがローカルであることを認識し、これらのアドレスが割り当てられたインターフェイスに関係なくループバックインターフェイスを使用するためです。

最初のバリエーションでは、なぜブロードキャストに応答がないのかはよくわかりませんが、通常、カーネルはあるインターフェイスから出て、他のインターフェイスに出てくるトラフィックをルーティングエラーとして処理して抑制します。放送なので放送はおそらく通じそうです。

かなりの努力をしたら、それを調整できます。ブーメランフラットしかし、これは一般的に特に有用ではありません。

仮想ethペアは、異なるネットワーク名前空間を接続するために使用される場合にのみ意味があります。設定方法は、同じ LAN セグメントに 2 つの異なる物理イーサネット カードを持つのと同じくらい役に立ちません。

おすすめ記事