什么时候不会生成ARP应答？

问题摘要 ：来自client的ping不会转到rpi1 ，它的ARP呼叫在srv没有被应答。

• host0和tap0由br0桥接。
• vpnin和lan0是两个独立的接口。
• 接口之间的所有stream量都允许在srv （IP forwading已启用，并且在rpi1与其他在此处不可见的接口之间有成功的通信，其中一个是通往Internet的网关）

详细信息 ： client自己（ 10.20.1.2 ）， 10.20.1.254和10.10.10.254 。 当试图ping 10.10.10.11 ：

 root@client:~# ping 10.10.10.11 PING 10.10.10.11 (10.10.10.11) 56(84) bytes of data. From 10.20.1.1: icmp_seq=2 Redirect Host(New nexthop: 10.10.10.11) From 10.20.1.1 icmp_seq=1 Destination Host Unreachable From 10.20.1.2 icmp_seq=3 Destination Host Unreachable From 10.20.1.2 icmp_seq=4 Destination Host Unreachable From 10.20.1.2 icmp_seq=5 Destination Host Unreachable 

请注意10.20.1.1和10.20.1.2之间的From的翻盖。

• 为什么Linux在不正确的接口上应答ARP？
• 在错误的接口上响应arp的Linux桥？
• 有一种方法可以禁用sonicwall TZ 210上的wan接口上的传出ARP请求
• veth的networking级别不响应arp
• Windows上的持久静态ARP条目有可能吗？

当在srv上运行一个tcpdump （ping能力丢失）时，我看到了ARP请求，但没有回复：

 root@srv ~# tcpdump -i vpnin -nn 17:10:54.463072 ARP, Request who-has 10.10.10.11 tell 10.20.1.1, length 28 17:10:55.459489 ARP, Request who-has 10.10.10.11 tell 10.20.1.1, length 28 17:10:56.459459 ARP, Request who-has 10.10.10.11 tell 10.20.1.1, length 28 17:10:56.473683 ARP, Request who-has 10.10.10.11 tell 10.20.1.2, length 28 17:10:57.469788 ARP, Request who-has 10.10.10.11 tell 10.20.1.2, length 28 17:10:58.469608 ARP, Request who-has 10.10.10.11 tell 10.20.1.2, length 28 

同样， 10.20.1.1和10.20.1.2要求回答。

srv上的ARP表格确实有答案

 root@srv ~# arp -a (...) rpi1.10.in-addr.arpa (10.10.10.11) at f4:f2:6d:09:35:1b [ether] on lan0 

可能是什么原因

• 缺乏答复？
• 对于10.20.1.1和10.20.1.2之间的奇怪切换？