在绝对标准的ubuntu-server linux发行版中只运行BINDcaching，有时我会在arp / nei表中看到非链接本地ip地址，并且没有办法与这些条目进行通信
早上大部分时间在Google上search后，我没有发现类似的问题，所以我认为这可能是我的设置有问题。
设置非常简单：
1个networking接口，1个vlan（ eth0.264 ），1个ip地址，1个默认网关 – 没有别的
（对于这个问题 – 我用9.9.9.9replace我的IP地址，用9.9.9.9replace我的子网，用9.9.9.0/24replace我的例子）
# uname -a Linux space 3.0.0-16-server #28-Ubuntu SMP Fri Jan 27 18:03:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # ip a li 4: eth0.264@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:30:48:d5:c2:70 brd ff:ff:ff:ff:ff:ff inet 9.9.9.13/24 brd 9.9.9.255 scope global eth0.264 inet6 fe80::230:48ff:fed5:c270/64 scope link valid_lft forever preferred_lft forever # ip rule li 0: from all lookup local 32766: from all lookup main 32767: from all lookup default # ip ro li default via 9.9.9.1 dev eth0.264 metric 100 9.9.9.0/24 dev eth0.264 proto kernel scope link src 9.9.9.13 # ip neigh show 9.17.100.131 9.17.100.131 dev eth0.264 INCOMPLETE # arp -n 9.17.100.131 9.17.100.131 (incomplete) eth0.264 # sysctl net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.accept_redirects = 0 # strange route cache stuff # ip ro show cache 9.17.100.131 9.17.100.131 dev eth0.264 src 9.9.9.13 cache <redirected> ipid 0x05cb 9.17.100.131 from 9.9.9.13 dev eth0.264 cache <redirected> ipid 0x05cb # ip ro flush cache # ip ro show cache 9.17.100.131 # ping 9.17.100.131 PING 9.17.100.131 (9.17.100.131) 56(84) bytes of data. ^C --- 9.17.100.131 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms # ip ro show cache 9.17.100.131 9.17.100.131 from 9.9.9.13 dev eth0.264 cache <redirected> ipid 0x06cb 9.17.100.131 dev eth0.264 src 9.9.9.13 cache <redirected> ipid 0x06cb # arp -d 9.17.100.131 SIOCDARP(dontpub): Network is unreachable
（当然9.17.100.131可以从下一个服务器9.9.9.14 ， 9.9.9.14的奇怪的arp条目可以从9.9.9.13等到达）
ip nei flush不删除条目，
也arp -s拒绝设置它（像它应该）：
# arp -s 9.17.100.132 00:11:22:33:44:55 SIOCSARP: Network is unreachable # arp -d 9.17.100.131 SIOCDARP(dontpub): Network is unreachable
我有3个服务器，与相同的Ubuntu版本和运行相同的进程（只有绑定），他们都经历了reboot后，全世界是链路本地症候群，它工作了几天，然后开始添加那些非链接本地条目。
一些使用情况统计
eth0.264 ~ 1000 pps udp traffic load average 0.03 processes - rsyslogd, named, snmpd, sshd
任何想法将不胜感激。
我猜你的网关对于9.9.9.0/24networking和9.17.100.131连接的networking都有单一的物理接口。 这就是为什么它发送redirect。
在我看来，你的Ubuntu服务器中有两个bug（或者“奇怪的function”）：
但是，您可以使用以下方法在Ubuntu上暂时修复此问题：
ip route flush cache
你可能会在网关上永久性地修复这个问题，使用：
sysctl -w net.ipv4.conf.all.send_redirects=0
毕竟，允许来自具有连接到相同物理接口的多个networking的网关的redirect可能是不好的主意。
为什么你find一个计算机的ARPlogging，不在同一个子网？ 这是不可能的。
如果您有networking9.9.9.0/24 ，那么您的计算机必须通过默认网关去计算机9.17.100.131 ，因为它的子网部分IP地址是9.9.9.x （networking掩码是255.255.255.0 ）。 那么你必须在你的邻居cachinglogging中只有默认网关。 您的计算机必须发送目标IP为9.17.100.131数据包，但使用默认网关的MAC地址。 你的网关将这个数据包路由到另一个networking。
arp的投诉“networking无法访问”对你说，那台计算机不是networking的一部分，地址是9.17.100.131 ，那么这个IP地址的ARPlogging是无稽之谈。
您的路由表告诉您，您的路由器试图通过ICMPredirect数据包将您redirect到9.17.100.131的目的地。 这是给你的信息，你的路由器有另一个networking掩码，比你的电脑，说/8 （ 255.0.0.0 ），并认为你在同一个networking9.17.100.131和路由器不必转发你的数据包到这台电脑。
请仔细检查您的networking上的计算机上的networking掩码，特别是针对您的“默认网关”计算机或路由器 – 它们必须与每个正确的工作相同。
net.ipv4.conf.all.secure_redirects的价值是什么？ 如果1（恰好是默认值），它将接受来自网关的redirect，而不pipeaccept_redirects 。 禁用这个。 （并且按照Arnaud Bienvenu的build议禁用你的网关上的send_redirects ）。
另外， 3.0内核有一个真正的bug，即使清除路由caching， redirect的路由也不会从内核中清除，唯一的方法是重启或者一些复杂的步骤， 包括等待很长的超时 。
这是我发现的：
我的Ubuntu 14.04服务器在断电几分钟后就失去了与远程主机150.43.127.1的连接。
检查路由caching显示使用错误的gw（150.150.100.2）的条目：
rg@buntu:~$ sudo ip route get 150.43.127.1 150.43.127.1 via 150.150.100.2 dev eth0 src 150.150.100.10 cache <redirected>
刷新caching之后，现在使用正确的gw（150.150.127.1）：
rg@buntu:~$ sudo ip route flush cache rg@buntu:~$ sudo ip route get 150.43.127.1 150.43.127.1 via 150.150.127.1 dev eth0 src 150.150.100.10 cache rg@buntu:~$
远程主机现在可以访问：
rg@buntu:~$ ping 150.43.127.1 PING 150.43.127.1 (150.43.127.1) 56(84) bytes of data. 64 bytes from 150.43.127.1: icmp_seq=1 ttl=252 time=14.9 ms 64 bytes from 150.43.127.1: icmp_seq=2 ttl=252 time=15.6 ms ^C