次の単純なネットワークトポロジがあります。
このサーバーから送信者アドレス（192.168.1.15）とターゲット（10.10.10.252):
server:~ # tcpdump -nei eth0 host 10.10.10.252
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:56:36.152174 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:37.150442 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:38.150449 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:39.159566 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
server:~ #
緩いデフォルト値（0)arp_お知らせ設定？
ベストアンサー1
カーネルがこれらのARPを受け入れ/実行する理由についてのあなたの前提は正確ですが、説明します。なぜそんなことが起きています。
要点は、実際には2つのネットワークブロックを持つブロードキャストドメインがあることです。
定義によれば、通常、サブネットと通信すると、そのサブネットに接続されているインターフェイスに属するネットワークと通信します。一方、Linux は通常インターフェイスのデフォルト IP と通信します。
したがって、r1と通信するとき、Linuxシステムはそのインタフェース（またはテストする必要がある最初のインタフェースのデフォルトIP arp_announce）をソースとして使用するため、これらのARPも同様です。
これを受け入れた理由についての仮定に戻り、正しく指摘しました。
arp_announce - INTEGERインターフェイスから送信されたARP要求のIPパケットにローカルソースIPアドレスを通知するためのさまざまな制限レベルを定義します。 0 - (デフォルト) すべてのインターフェイスで設定されたローカルアドレスを使用する
返信の送信にも使用できます。
arp_filter - 0 - (デフォルト) カーネルは、他のインタフェースのアドレスを使用して arp 要求に応答できます。これは間違っているように見えるかもしれませんが、成功したコミュニケーションの可能性を高めるので、しばしば意味があります。 IP アドレスは、特定のインターフェイスではなく Linux のホスト全体が所有します。この動作は、ロードバランシングなどのより複雑な設定でのみ問題を引き起こします。
さらに:
arp_ignore - INTEGERローカル宛先IPアドレスを解決する受信したARP要求に応答して応答を送信するさまざまなモードを定義します。 0 - （デフォルト）：すべてのインターフェイスで設定されたすべてのローカル宛先IPアドレスに応答します。
したがって、Linux サーバーがサーバーレベルで非常に簡単な方法で ARP を処理するという結論を下すことができます。基本的に。
これは図のルータr1の場合ではなく、オペレーティングシステム/ファームウェアのローカルデフォルトと設定によって異なります。