☰

Linux-Routing-Fehler?

tag-icon • tag-icon linux routing arp ip-routing
Linux-Routing-Fehler?

Ich kämpfe schon seit einiger Zeit mit diesem nicht leicht reproduzierbaren Problem. Ich verwende Linux-Kernel v3.1.0 und manchmal funktioniert das Routing zu einigen IP-Adressen nicht. Was anscheinend passiert, ist, dass der Kernel das Paket nicht an das Gateway sendet, sondern die Zieladresse als lokal behandelt und versucht, seine MAC-Adresse über ARP abzurufen.

Beispielsweise lautet meine aktuelle IP-Adresse 172.16.1.104/24 und 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 einige Adressen anpingen, 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 anzupingen, kann ich im TCPdump sehen, dass eine ARP-Anforderung 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.59IstVon diesem LAN aus von anderen Computern aus zugänglich.

Hat irgendjemand eine Ahnung, was los ist? Danke.

aktualisieren:Antworten auf die Kommentare unten:

  • es gibt keine Schnittstellen außer eth0 und lo
  • Die ARP-Anforderung kann am anderen Ende nicht gesehen werden, aber so sollte es funktionieren. Das Hauptproblem besteht darin, dass eine ARP-Anforderung überhaupt nicht gesendet werden sollte.
  • das Problem besteht weiterhin, auch wenn ich eine explizite Route mit dem Befehl „route add -host 172.16.0.59 gw 172.16.1.254 dev eth0“ hinzufüge.

Antwort1

Es handelt sich tatsächlich um einen Linux-Kernel-Fehler, wahrscheinlich seit Version 2.6.39. Ich habe die Frage in den lkml- und netdev-Listen gepostet (siehe den Thread unterhttps://lkml.org/lkml/2011/11/18/191), und es wurde gerade in einem anderen Netdev-Thread unterhttp://www.spinics.net/lists/netdev/msg179687.html

Die aktuelle Lösung besteht nun entweder in einem Neustart oder darin, alle Routen zu leeren und 10 Minuten zu warten, bis die ICMP-Umleitungen ablaufen. Um zu verhindern, dass dies erneut passiert,

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

hilft.

Antwort2

Die Standard-Subnetzmaske von 172.16.XX lautet 255.255.0.0, Sie haben sie auf 255.255.255.0 neu konfiguriert. Die Hosts 172.16.0.x und 172.16.1.x befinden sich also in unterschiedlichen Subnetzen. Daher wird versucht, sie über das Standard-Gateway zu routen.

Das Ändern Ihrer Subnetzmaske auf 255.255.0.0 löst das Problem.

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

Prost,

verwandte Informationen