Hallo,
ich habe seit einiger Zeit Probleme, nach einer gewissen Inaktivität zB. mittels Webbrowser oder ping ohne Verzögerungen Pakete ins Internet zu transportieren. Beim FF dauert es zeitweise 10-15s (oder Fehlerseite), beim ping gehen mir die ersten Pakete verloren.
Ich bin dem ganzen nun mal etwas auf den Grund gegangen, v.a. da es mit einem FreeBSD auf dem gleichen PC und mit Kernel 3.5.x auf meinem Laptop nicht aufgetreten ist.
Ursache ist bei mir ein fehlerhaftes ARP-Caching, was aber nur mit 3.6.x auftritt. Ob der reale Grund, das dies nun zu einem Problem wird, in meinem Netzwerk liegt oder an Änderungen im IP-Stack des Kernels, daß weiß ich nun nicht.
Also, mitteles des ARP-Caches wird ja die Zuordnung IP<->Netzwerk-MAC-Adresse erledigt. Diese MAC-Adressen werden per ARP erfragt und sowohl in den Switches-Tabellen als auch (zeitweise) lokal im ARP-Cache zwischengespeichert.
Mir ist nun aufgefallen, daß sich mit Kernel 3.6.x zu einen:
a) der (lokale) ARP-Cache viel schneller leert, IP-MAC-Zuordnungen bei "Nichtgebrauch" also aufgrund Timeouts aus dem lokalen cache verschwinden. Was aber kein Problem an sich ist.
b) zumindest bei mir für meinen Router/Gateway zeitweise eine ganz falsche MAC-Adresse im Cache auftaucht. Und das ist bei mir die Ursache für die Nichtverbindung ins Internet.
Test:
Nach einer gewissen Zeit (teils < 1min, teils mehr) verliere ich bei einem:
ping -c10 google.de
regelmäßig und reproduzierbar die ersten 5 Pakete, d.h. erst das 6. Request-Paket wird beantwortet. (Bei Browsern und anderen Anwendungen ist der Zeitraum/Timeout aufgrund anderer Protokolle wesentlich höher, deshalb ist ping hier ein gutes Werkzeug)
Und zwar tritt dieser Verlust *nur* auf, wenn meine Router/Gateway MAC-Adresse nicht mehr im Arp-Cache ist. Was mit 3.6.x sehr schnell passieren kann.
Den Arp-cache kann man überprüfen z.B. mit:
root@ws01 ~ # watch -n1 arp -vna
(produziert momentan bei mir: )
? (192.168.166.249) at 00:a0:cc:c0:50:f0 [ether] on eth0
Entries: 1 Skipped: 0 Found: 1
Diese IP ist mein Gateway. Solange dieser Eintrag im Cache ist geht mein obiger Ping z.B. ohne Paketverlust durch.
Mit 3.6.x leert sich dieser Cache allerdings sehr schnell sobald nicht mehr auf das Gateway zugegriffen wird. Und das ist neu/anders im Gegensatz zu FreeBSD, Linux-Kernel 3.5.x und auch dem LTS-Kernel (3.0.x).
Und jetzt wird es spannend und mysteriös ;-)
Das die Gateway-IP nicht im Cache vorhanden ist, das ist kein Beinbruch. Dann wird diese über das ARP-Protokoll halt wieder "erfragt" (über Switch-MAC-Tabellen oder letztendlich vom Rechner mit den entsprechenden Device für die gewünschte IP).
Setze ich nun obigen Ping wieder ab, taucht die Gateway-IP auch sofort wieder im Cache auf. Allerdings (Obacht!) erstmal mit einer total falschen MAC-Adresse!!! Und zwar der MAC-Adresse, die auf meinem Router von eth1 kommt (das Device was zum DSL-Modem geht). eth0 (worauf eigentlich meine Gateway-IP zeigt, und die mittels Switch mit dem LAN verbunden ist) hat eine ganz andere MAC-Adresse.
So gehen erstmal die ersten 5 Pakete "ins Leere", und dann, schwupp! wechselt der Arp-Cache-Eintrag plötzlich zur richtigen MAC-Adresse. Sobald diese auftaucht funktioniert wieder jedwede Internet-Verbindung.
Ich warte also bis mein Gateway aus dem Cache verschwunden ist (oder lösche diese per: arp -d 192.168.166.249)
Dann starte ich den obigen Ping, im Arp-cache taucht auf:
? (192.168.166.249) at 00:1b:11:59:bb:b6 [ether] on eth0
(Jetzt gehen die ersten 5 Ping-Pakete verloren... Und plötzlich taucht die korrekte MAC-Adresse für 192.168.166.249 auf!)
? (192.168.166.249) at 00:a0:cc:c0:50:f0 [ether] on eth0
(ab dann geht der Ping durch)
00:1b:11:59:bb:b6 gibt es. Und zwar ist das an meinem Router das Device eth1, welches die PPPoE-Verbindung mittels eines DSL-Modems zum Provider-PtP-Gateway hält:
(Hier ein ifconfig vom Router):
eth0 Link encap:Ethernet HWaddr 00:A0:CC:C0:50:F0
inet addr:192.168.166.249 Bcast:192.168.166.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16782056 errors:0 dropped:0 overruns:0 frame:0
TX packets:23305947 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1521293914 (1450.8 MB) TX bytes:1795781251 (1712.5 MB)
Interrupt:9 Base address:0xd000
eth1 Link encap:Ethernet HWaddr 00:1B:11:59:BB:B6
inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:23494351 errors:0 dropped:0 overruns:0 frame:0
TX packets:16718717 errors:0 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1958294548 (1867.5 MB) TX bytes:1637223142 (1561.3 MB)
Interrupt:10 Base address:0xf000
Hier sieht man die MAC-Adresse die - fehelrhaft - zuerst im (LAN)-Arp-Cache auftaucht, obwohl die Verbindung ins LAN ausschließlich über eth0 erfolgt. eth1 ist (ohne IP) wie gesagt das Device, was ppp0 wird zum DSL-Modem.
Und das tritt reproduzierbar erst mit 3.6.x auf, genaue Revisionen kann ich momentan nicht sagen. Und es passiert *nicht* mit BSD oder älteren Kernel unter Linux.
Ich frage mich nun, woher bzw. wer speißt die zuerst falsche MAC-Adresse ins ARP ein? So daß es für irgendwelche Änderungen (Bugs?) im 3.6.x zum Problem wird?
Ich habe alle Switches resettet um evtl. MAC-tabellen-Fehler auszuschließen. ich habe meinen Router noch nicht neu gestartet (zum einen, weil ich meie schöne Uptime von 273 Tagen nicht ruinieren will, zum anderen weil es ja unter anderen Bedingungen funktioniert. Könnte ich aber machen, so als letzten Strohhalm).
@Greg, wenn er mitliest (hat mit 3.6.x auch ein Problem):
Beobachte wie oben mal deinen Arp-Cache. Warte, bis dein Gateway entweder verschwindet oder entferne es mittels arp -d -<IP>. Stelel sicher, daß erstmal nichts eine Internet-Verbindung aufrecht erhält (Musik,Video).
Nun setze mal obigen ping ab und schaue:
a) ob du auch die ersten Pakete verlierst
b) ob sich deine MAC-Adresse auch ändern würde bis letztendlich der Ping beantwortet werden würde.
Andere können diesen Test natürlich auch machen. (Nach dem händische Löschen der Gateway-IP aus dem Cache muß der ping ggf mehrmals "angeschoben" werden, zumindest hier, was auch eine Merkwürdigkeit ist).
Wenn irgendjemand eine Idee hat oder etwas, was die reale Ursache bei mir lokal festnageln könnte, imer ehr damit ;-)
Momentan rätsele ich etwas und würde eher auf einen TCP/IP-Bug in 3.6.x tippen. Zum Bi-Sekten habe ich momentan keine Zeit/Lust. Vielleicht ist in meinem LAN ja wirklich was unsauber und 3.6.x ist nun nicht mehr "tolerant" dem gegenüber. Aber das andere OSe kein Problem haben…