web-dev-qa-db-ja.com

macvlan MACではなく物理インターフェイスMACがARP応答として送信されます

Arch Linux ARM（Raspberry Pi）Kernel 4.4.37では、macvlanを作成しました。

ip link add link eth0 mac0 type macvlan

Macvlan virtual NICがリストに表示されるので、それにIPアドレスを割り当て、リンク状態をupに設定します（ちなみに、モードbridge 、vepaおよびprivate。）

その後、WindowsクライアントからIPにpingできますが、ARPキャッシュ（arp -a）Windowsでは、新しく作成されたmacvlan MACアドレスではなく、メイン（物理）ネットワークアダプターと同じMACアドレスが表示されます。

ARPキャッシュをクリアして、クライアントが以前に見たことのないIPアドレスなどを試すようにしましたが、常に間違ったMACが表示されます。

Macvlan MACアドレスのWindowsクライアントに静的ARPエントリを作成し、関連するIPアドレスにpingを実行すると、tcpdumpはmacvlanインターフェイスで受信されたエコー要求を表示し、メイン（物理）インターフェイスには何も表示しません、そして私は私のWindowsクライアントでping応答を受け取ります（トラフィックを許可するためにiptablesルールを設定することを覚えていたら！）

クライアントのARPキャッシュをクリアして再度pingするとすぐにping応答が返されますが、今回はARPエントリがLinuxボックスのメインの物理ネットワークアダプターのエントリに戻りました。

ちょうど私が間違っているのではないかと思っただけですか？

linuxlinux-networkingmac-addressiproute2
4
bao7uo

これが機能するためには、受け入れられた回答に1つのステップを追加し、次の追加の変数を設定する必要がありました。

net.ipv4.conf.all.rp_filter=2

arp_ignoreを2に設定する必要はありませんでした。1は機能しているようです。また、ネットワークでarp_filterを1に設定する必要もありませんでした。

だから私にとっての完全な解決策は：

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.all.rp_filter=2

私の問題の解決策を見つけた ここ

2
Sean

基本的に、ここでは何も問題はありません。これは、LinuxカーネルがARP解決に関して機能する方法です。デフォルトでは、要求されたアドレスが別のインターフェース上にある場合でも、着信するインターフェースに関係なく、ローカルアドレスのいずれかに対するARP要求に応答します。

これを回避するには、2つのsysctl変数を調整する必要があります。

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

IPアドレス/サブネットのシナリオによっては、arp_ignore値を2に変更し、arp_filterを1に設定する必要がある場合があります。

これらの変数で使用可能なオプションの詳細については、 kernel.orgのドキュメント を参照してください。

5
Peter Zhabin