Linux的路由错误?


9

一段时间以来,我一直在努力解决这个不容易重现的问题。我使用的是Linux内核v3.1.0,有时无法路由到几个IP地址。似乎发生的是,内核没有将数据包发送到网关,而是将目标地址视为本地地址,并尝试通过ARP获取其MAC地址。

例如,现在我当前的IP地址是172.16.1.104/24,网关是172.16.1.254:

# ifconfig eth0 eth0      Link encap:Ethernet  HWaddr 00:1B:63:97:FC:DC
          inet addr:172.16.1.104  Bcast:172.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:191879370 (182.9 Mb)  TX bytes:47173253 (44.9 Mb)
          Interrupt:17

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.1.254    0.0.0.0         UG    0      0        0 eth0
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0

我可以ping几个地址,但不能172.16.0.59:

# ping -c1 172.16.1.254
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms

--- 172.16.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms

--- 172.16.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms

--- 172.16.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.59
PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
From 172.16.1.104 icmp_seq=1 Destination Host Unreachable

--- 172.16.0.59 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

尝试ping 172.16.0.59时,我在tcpdump中看到发送了ARP请求:

# tcpdump -n -i eth0|grep ARP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28

/ proc / net / arp的172.16.0.59条目不完整:

# grep 172.16.0.59 /proc/net/arp
172.16.0.59      0x1         0x0         00:00:00:00:00:00     *        eth0

请注意,172.16.0.59 从其他计算机从这个LAN访问。

有谁知道发生了什么吗?谢谢。

更新:回复以下评论:

  • 除eth0和lo外没有接口
  • ARP请求不能在另一端看到,但这就是它的工作方式。主要的问题是,甚至不应该一开始就发送ARP请求
  • 即使我使用命令“ route add -host 172.16.0.59 gw 1​​72.16.1.254 dev eth0”添加显式路由,问题仍然存在

我在想这是某种默认行为,我们也看看ARP表吗?另一端的arp表可能在这里有用。
SpacemanSpiff

您如何解决?放置主机特定的路由是否可以使其重新工作?我想知道您是否通过某种方式使ICMP重定向使主机认为目的地是本地的。
保罗,

好像arp回复没有回来。您可以在172.16.0.59主机上进行tcpdump吗?这是VM guest吗?还要检查主机上的网络流量。
AndreasM 2011年

你能发布输出ifconfig -a吗?您是否为此主机分配了其他接口/ IP?
哈立德

我已经更新的问题与答复
巴拉兹Pozsár

Answers:


7

这确实是一个Linux内核错误,可能是从2.6.39版本开始。我已将问题发布到lkml和netdev列表中(请参见https://lkml.org/lkml/2011/11/18/191上的线程),而该问题刚刚在http:// www的另一个netdev线程中进行了讨论.spinics.net / lists / netdev / msg179687.html

现在,当前的解决方案是重新启动或刷新所有路由,并等待10分钟以使icmp重定向过期。为了防止它再次发生,

echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects

帮助。


不幸的是,上面似乎并没有帮助..
sivann

尝试对所有接口执行此操作:读x时,找到/ proc / sys / net -name accept_redirects | 做echo -n 0> $ x; 做过或者你有其他的错误
巴拉兹Pozsár

谢谢,我已经为所有接口启用了它。IP来自IPSEC隧道(本机有数百个),并且eth0接口的arp表中始终列出5-10个(172.x),其中列出了(不完整的)HWaddress,并且缺少HWtype。那些似乎已过期,而新的代替了,但是有时需要重新启动。
sivann 2014年

-1

172.16.XX默认子网掩码是255.255.0.0,您已将其重新配置为255.255.255.0。因此,主机172.16.0.x和172.16.1.x位于不同的子网中。因此它将尝试通过默认网关进行路由。

将子网掩码更改为255.255.0.0将解决此问题。

你能提供一张图吗?如果您无法绘制网络,则无法修复(旧网络工程师的谚语...我!)。

干杯,


您会建议使用哪种Web应用程序或轻量级桌面应用程序来绘制网络图?
Belmin Fernandez

它与“默认”网络掩码通常无关。无论如何,请参阅上面的答案。
巴拉兹Pozsár

感谢您的评分。因此,为什么您认为路由器正在生成icmp重定向。
Unix管理员

路由器正在生成重定向,因为它使主机应该使用其他网关。我认为您对问题的理解是一个错误。除非你想教育我,否则
Unix的看门人

请阅读接受的答案中链接的主题。问题在于,即使应该将这些路由信息也不会丢弃。路由器/网关没有问题。
巴拉兹Pozsár
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.