web-dev-qa-db-ja.com

ネームスペースからではなくホストからのMacvlanベースのインターフェースping

[編集]

本番システムは現在、物理システムとESXiベースのシステムが混在しています。実稼働前の環境であっても、virtualboxを使用することはありません。これは、デスクトップで直接問題をすばやく絞り込むためにのみ使用されました。

メタの「保留中」の説明をありがとう！

[/編集]

私のセットアップ：

  1. プライベートネットワークvboxnet1 10.0.7.0/24
  2. 1ホスト、ubuntuデスクトップ
  3. 1 VM、ubuntuサーバー（VirtualBox）

住所レイアウト：

  1. ホスト：10.0.7.1
  2. VM：10.0.7.101
  3. VM MACネームスペース：10.0.7.102

VMで、次のコマンドを実行しました。

ip netns add mac                        # create a new nmespace
ip link add link eth0 mac0 type macvlan # create a new macvlan interface
ip link set mac0 netns mac

VM内のmac名前空間：

ip link set lo up
ip link set mac up
ip addr add 10.0.7.102/24 dev mac0

つまり、基本的には次のようになります：（Like Inception？）

+------------------------+
| Host: 10.0.7.1         |
|                        |
| +--------------------+ |
| | VM: 10.0.7.101     | |
| |                    | |
| | +----------------+ | |
| | | NS: 10.0.7.102 | | |
| | |                | | |
| | +----------------+ | |
| +--------------------+ |
+------------------------+

機能するもの：

  • HostとVMの間のping
  • NSとNSの間のping
  • NSのdhclient

機能しないもの：

  • NSとVMの間のping
  • NSとHostの間のping

私がナッツに行き始めたところ：

  • Host（実際のマシン）のtcpdumpは実際にARP要求と応答を表示します
  • NSのtcpdumpは、ホストに送信されたARP要求を示します
  • VMのtcpdumpは、全体の混乱を解消します（！）-> tcpdumpがVM？！？

だから、私はあなたがそれを熱望していたに違いない、私の質問は：それをどのように機能させるか？ NS内のmacvlanのARPに何か問題があると思いますが、正確に何を理解できません...

ところで、私はmac0 VM（名前空間なし）に直接インターフェースし、完璧に動作しました。

linuxnetworkingiproute2namespaces
10
yadutaf

わかりましたので、後世のために、tcpdumpが突然すべてを動作させるという事実は、私を軌道に乗せるはずです。内部的には、スイッチeth0無差別モードに。つまり、eth0は、サーバーのメインMACだけでなく、すべてのネットワークトラフィックを生成します

ただし、これがmacvlanの動作方法です。「物理」（つまりVM）ネットワークアダプターが認識しない新しいセカンダリ仮想MACアドレスが追加されます。

したがって、簡単な回避策は手動で行うことです：ifconfig eth0 promisc

それが役に立てば幸いです！

13
yadutaf