ARP 請求的發送者地址與目標地址來自不同的廣播域
我有以下簡單的網路拓撲：
我在此伺服器中看到了一種情況，其中 ARP 請求發送方地址（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_announce設置，我是否正確地認為這種行為是可能的？
您對核心為什麼接受/執行這些 ARP 的假設是正確的，但是我將解釋它們發生的原因。
關鍵是您實際上有一個帶有兩個網路塊的廣播域。
根據定義，通常在與子網通信時，您與屬於連接到該子網的介面的網路進行通信；另一方面，Linux 通常預設與介面的主 IP 通信。
因此，當與 r1 通信時，Linux 機器使用介面的主 IP（或第一個介面的主 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 並非如此，這將取決於其作業系統/韌體的本地預設值和配置。