Sixxs IPv6 Tunnel bricht zusammen

oxy

Staatl. gepr. Destroyer
Hallo

Seit ein paar Wochen betreibe ich mehr oder weniger glücklich einen IPv6 Tunnel samt Subnetz, so dass mein komplettes LAN IPv6 Internetzugang hat.

Anfangs, als ich nur den Tunnel hatte von meinem Hauptdesktoprechner aus lief alles Problemlos. Nachdem ich dann mein Subnetz bekommen habe ist die Tunneleinwahl auf eine frische FreeBSD 8 Installation von meinem Router umgezogen. Da läuft ein Routeradvertising Daemon der das Präfix fürs Subnetz verteilt. Das funktioniert alles wunderbar.

Der Tunnel läuft aber alles andere als stabil.
Das größere Problem ist, dass nach ein paar Tagen (jetzt waren es 9) irgendwann der Tunnel nicht mehr funktioniert. Ein ping6 auf den IPv6 Endpunkt gibt mir immer:

Code:
eric# ping6 2a01:198:200:648::2
PING6(56=40+8+8 bytes) 2a01:198:200:648::2 --> 2a01:198:200:648::2
ping6: sendmsg: No buffer space available
ping6: wrote 2a01:198:200:648::2 16 chars, ret=-1

Nach einem
Code:
/usr/local/etc/rc.d/sixxs-aiccu stop

und sobald der Prozess wirklich beendet ist "start" (restart scheint nicht zu warten/nichts zu bringen) kann ich wieder wenige MB übertragen und habe dann wieder das gleiche Problem.

Das Problem kann ich glaube ich ein wenig provozieren wenn ich über das LAN mehere hundert MB von dem Router (der gleichzeitig Fileserver ist) per NFS übertrage.

Kleineres Problem, was vermutlich damit zusammenhängt: Der 24h Disconnect läuft auch nicht sauber, gleiches Symptom. 3 Minuten vor dem Disconenct den sixxs-aiccu Prozess zu killen und 2 Minuten nach dem Connect wieder zu starten hilft auch nicht, ich muss nochmal manuell das machen. Aber das ist sekundär, kümmere ich mich drum wenn das andere läuft, wollte ich nur der Vollständigkeit halber erwähnen.

Netzwerksetup sieht wie folgt aus:
fxp0 -> ng0 (über mpd5), DSL Modem
em0 -> LAN

Nur weil ich irgendwo gelesen hatte, dass es Probleme mit dem EM Treiber gegeben hat.

Ansonsten sind die Ergebnisse bei Google eher spärlich, und alles was ich finde ist schon etwas älter und die Problemlösung ist jeweils auf aktuelle FreeBSD Version upzudaten.

Hat jemand eine Idee wo ich nun ansetzen kann?

Gruß
oxy
 
Der TCP Stack sammelt alle ausgehenden Pakete bis das Ack zurückkommt. Wenn jetzt die Verbindung hardwareseitig zusammenbricht (vor allem bei Funkverbindungen problematisch), wartet das System auf Antworten und behält alle ausgehenden Pakete im Puffer.

FreeBSD vergrößert den Puffer bei bedarf, aber es gibt eine (konfigurierbare) Maximalgrenze. Wenn dann die Verbindung wieder auftaucht, kann es (bei intelligenter Hardware) tatsächlich passieren, dass die ganzen Acks (teilweise von Minuten-alten Paketen) kommen, da das System bei ausbleibend Acks die gepufferten Pakete nochmal verschickt.

Wenn der Puffer überläuft heißt das in der Regel, dass viel zu viel Zeit vergangen ist um sich noch Hoffnungen zu machen.

Ich würde vermuten, dass da in deinem Fall entweder ein Treiber-Problem oder ein Problem oder Ärger mit der Forwarding-Software der Verursacher sind. Solche Probleme, die erst nach längerer Betriebszeit und unzuverlässig reproduzierbar sind, werden normalerweise von parallelen Vorgängen, die sich gegenseitig stören verursacht. Bei Embedded-Hardware würde ich sagen, da stimmt was mit den ISRs nicht aber das kann auch im Userland bei Threaded-Applikationen auftauchen.
 
OK, das Problem ist aber nicht, dass nur einzelne Pakete verloren gehen, sondern dass irgendwann wohl überhaupt keine Pakete mehr durch den Tunnel gehen, wenn nur ab und zu einzelne Pakete verloren würden, das wäre ja nicht so schlimm.

D.h. wenn ich etwas (über den IPv6 Tunnel) runterlade gehen irgendwo meine ACKs verschütt.

Wie kann ich denn den Netzwerkverkehr mir am Besten anschauen?
Und kann ich irgendwo schauen was für Pakete im Puffer rumliegen?
Und eigentlich müssten doch die Pakete aus dem Puffer geschmissen werden wenn die TTL abgelaufen ist, oder?

Gruß
oxy
 
Wenn die Verbindung zusammengebrochen ist, dann ist sie komplett weg. Und natürlich landen alle TCP-Pakete im Puffer..
 
OK, ich suche nun also nach den Gründen und Lösungen warum der Tunnel zusammenbricht.

Ganz simpel gesprochen:
Kein Traffic über IPv6 nach gewisser Zeit, wie behebe ich das.
 
Ah ich sehe deinen Edit aus dem 1. Post gerade erst. Dann werde ich mal im sixxs Forum mich umschauen, vielleicht weiß man da mehr.
 
Warum verwendest du nicht einen ganz normalen gif(4) Tunnel? Also hier taugt Sixxs ohne irgendwelche Software ziemlich stabil.

Code:
gif_interfaces="gif0"
gifconfig_gif0="217.20.127.X 91.184.37.98"
ipv6_network_interfaces="gif0"
ipv6_ifconfig_gif0_alias0="2a01:198:200:2a::2 prefixlen 64"  # meine TunnelIP
ipv6_ifconfig_gif0="2a01:198:X::1 prefixlen 128" #mein Subnetz
 
Ah ich sehe deinen Edit aus dem 1. Post gerade erst. Dann werde ich mal im sixxs Forum mich umschauen, vielleicht weiß man da mehr.

Hallo,
Da wirst Du auch diesen Thread finden: https://www.sixxs.net/forum/?msg=setup-1164591

Nur so zur komplettheit 32 oder 64 Bit? TIC, Heartbeat oder AYIYA?

Der Tunnel lief bei mir übrigens über ein Jahr problemlos. Nun geht es zwischen 1 Woche und 1 Monat bis zum Bufferproblem.
 
Warum verwendest du nicht einen ganz normalen gif(4) Tunnel? Also hier taugt Sixxs ohne irgendwelche Software ziemlich stabil.

Weil ich einen Ayiya Tunnel habe, weil ich halt eine dynamische IP(v4 IP) habe, und Anfangs auch durch NAT musste mit dem Tunnel.

@netsigi: 32 Bit, und wie gerade geschrieben Ayiya.

Ich meine über den Thread bin ich auch gestolpert, allerdings hatte ich anfangs direkt 8.0 RC1 draufgehabt, und zwischendurch halt nochmal geupdated.

Die Hardware ist auch schon ein paar Tage alt, ein P3 mit 512 MB Ram, aber daran sollte es ja wohl kaum liegen, oder?

Gruß
oxy
 
Wie sieht es denn mit Zeitsynchronisation aus?
Ich habe auf Grund von Problemen damit schon die verschiedensten Symptome erlebt.
 
Hm, da sagste echt was.

Der Rechner hat immer Probleme mit Zeit (geht stark nach), deshalb habe ich alle 2 Stunden per NTP die Zeit geholt (unabhängig von dem Tunnel). Und bei dem Sixxs-Tunnel gedöns steht ja immer bei, dass man drauf achten soll, dass die Zeit möglichst genau geht.

Ich habe jetzt einfach mal alle 10 Minuten einen NTP Abgleich reingemacht, viel hilft viel. Bis jetzt läuft der Tunnel noch.
 
Sinnvoller wäre es, den ntpd(8) permanent laufen zu lassen. Je nachdem, wie stark die Abweichung ist, hast du sonst alle 10 Minuten Zeitsprünge, die auch wieder problematisch werden könnten. Bedenke, daß schon 1 Sekunde für einen Rechner eine halbe Ewigkeit ist.
 
Stimmt, da hast du Recht. Ich weiß garnicht mehr warum ich früher das mit dem alle zwei Stunden ntpdate laufen lassen gemacht habe und nicht gleich mit ntpd, ich glaub da funktionierte irgendwas nicht.
Auf den ersten Blick scheint der ntpd aber nun seine Arbeit zu machen, ansonsten guck ich jetzt erst dass das zumindest mit der Zeit gefixt wird.
 
An ntpd nervt halt, dass der Rechner schon beim booten online sein muss damit -g funktioniert.
 
Ah cool, ich probier's mal aus, der Patch lässt sich zumindest auch in -STABLE anwenden. Mal schauen ob's durchkompilierten.

Eigentlich hatte ich den ganzen sixxs-Tunnel Kram schon aufgegeben…
 
So, kurzes Feedback:

Der Tunnel steht nun mehrere Tage stabil. Ich gehe davon aus, dass das Problem behoben ist, sonst hat der maximal ne Stunde durchgehalten ;)
 
Zurück
Oben