Frage Linux-Routing-Fehler?


Ich habe seit einiger Zeit mit diesem nicht leicht reproduzierbaren Thema gekämpft. Ich benutze Linux Kernel v3.1.0, und manchmal funktioniert das Routing auf ein paar IP-Adressen nicht. Es scheint, dass der Kernel die Zieladresse als lokal behandelt und versucht, seine MAC-Adresse über ARP zu erhalten, anstatt das Paket an das Gateway zu senden.

Zum Beispiel ist jetzt meine aktuelle IP-Adresse 172.16.1.104/24, das Gateway ist 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

Ich kann ein paar Adressen pingen, aber nicht 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

Beim Versuch, 172.16.0.59 zu pingen, kann ich in tcpdump sehen, dass ein ARP req gesendet wurde:

# 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

und / proc / net / arp hat einen unvollständigen Eintrag für 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

Bitte beachten Sie, dass 172.16.0.59 ist über dieses LAN von anderen Computern aus erreichbar.

Hat jemand eine Vorstellung von dem, was vor sich geht? Vielen Dank.

aktualisieren: Antworten auf die folgenden Kommentare:

  • es gibt keine Schnittstellen neben eth0 und lo
  • Der ARP req kann am anderen Ende nicht gesehen werden, aber so sollte es funktionieren. Das Hauptproblem ist, dass ein ARP req nicht einmal an erster Stelle gesendet werden sollte
  • Das Problem bleibt bestehen, auch wenn ich eine explizite Route hinzufügen mit dem Befehl "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"

9
2017-11-16 14:29


Ursprung


Ich denke, das ist eine Art Standardverhalten, sehen wir uns auch die ARP-Tabelle an? Die Arp-Tabelle des anderen Endes kann hier nützlich sein. - SpacemanSpiff
Wie reparierst du es? Führt das Einrichten einer Host-spezifischen Route es wieder zum Laufen? Ich frage mich, ob Sie irgendwie eine ICMP-Weiterleitung bekommen, die den Host denken lässt, dass das Ziel lokal ist. - Paul
Es scheint, als ob die ARP-Antwort nicht zurückkommt. Können Sie auf dem Host 172.16.0.59 tcpdump? Ist das ein VM-Gast? Überprüfen Sie auch den Netzwerkverkehr auf dem Host. - AndreasM
Kannst du bitte die Ausgabe von ifconfig -a? Haben Sie diesem Host andere Schnittstellen / IPs zugewiesen? - Khaled
Ich habe die Frage mit den Antworten aktualisiert - Balázs Pozsár


Antworten:


Es ist in der Tat ein Linux-Kernel-Bug, wahrscheinlich seit Version 2.6.39. Ich habe die Frage in lkml und netdev Listen gepostet (siehe den Thread unter https://lkml.org/lkml/2011/11/18/191), und es wurde gerade in einem anderen netdev thread an diskutiert http://www.spinics.net/lists/netdev/msg179687.html

Die aktuelle Lösung ist jetzt entweder ein Neustart oder um alle Routen zu leeren und 10 Minuten zu warten, bis die icmp-Weiterleitungen ablaufen. Um zu verhindern, dass es wieder passiert,

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

hilft.


7
2017-11-18 14:28



Leider scheint das oben genannte nicht zu helfen. - sivann
versuchen Sie es für alle Schnittstellen: find / proc / sys / net -name accept_redirects | while read x; do echo -n 0> $ x; fertig oder vielleicht hast du einen anderen Fehler - Balázs Pozsár
Danke, ich hatte es bereits für alle Schnittstellen aktiviert. Die IPs stammen von IPSEC-Tunneln (diese Maschine hat Hunderte von ihnen) und es gibt immer 5-10 von ihnen (172.x) aufgelistet in der Arp-Tabelle in eth0-Schnittstelle aufgeführt mit (unvollständige) HW-Adresse und fehlenden HWtype. Diese scheinen abzulaufen, und neue treten an ihre Stelle, aber manchmal ist ein Neustart erforderlich. - sivann


172.16.X.X Die Standard-Subnetzmaske ist 255.255.0.0. Sie haben sie zu 255.255.255.0 neu konfiguriert. Die Hosts 172.16.0.x und 172.16.1.x befinden sich also in verschiedenen Subnetzen. So wird es versuchen und ROUTE es über das Standard-Gateway.

Wenn Sie Ihre Subnetzmaske auf 255.255.0.0 ändern, wird das Problem gelöst.

Können Sie ein Diagramm bereitstellen? Wenn du kein Netzwerk zeichnen kannst, kann es nicht repariert werden (altes Sprichwort von Netzwerkingenieuren ... von mir!).

Prost,


-1
2017-11-18 12:34



Welche Web-App oder leichte Desktop-App würden Sie für das Zeichnen von Netzwerkdiagrammen empfehlen? - Belmin Fernandez
Es hat nichts damit zu tun, was die "Standard" -Netzmaske normalerweise ist. Wie auch immer, sehe meine Antwort oben. - Balázs Pozsár
Danke für den Abschlag. Also, warum denkst du, dass der Router ICMP-Redirects erzeugt? - The Unix Janitor
Der Router erzeugt Redirects, weil der Host ein anderes Gateway verwenden sollte. Ich denke, Ihr Verständnis des Problems ist ein Fehler. Es sei denn, du möchtest mich anders unterrichten - The Unix Janitor
Bitte lesen Sie die Themen, die in der angenommenen Antwort verlinkt sind. Das Problem ist, dass diese Routinginformationen nicht verworfen werden, obwohl sie es sein sollten. Es ist kein Problem mit dem Router / Gateway. - Balázs Pozsár