Unitymedia ipv6 Tunnel an ipv4 Anschluss - langsam

[Andreas1969]

Der Eintrag scheint irgend etwas mit der Vorbereitung für das Port Control Protocol für DSlight Anschlüsse zu tun zu haben.

 

[Joerg]

IPV4 und 200er Leitung, frage mich warum da ein noch kleinerer und vor allem krummer Wert rauskommt:

root@Raspberry:~# i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1367

Wild guess: Du verwendest Windows (+Cygwin oder so); in dem Fall geht bereits der erste "ping" schief, weil die Commandline-Parameter nicht passen. Probier's dann doch mal mit

i=1360; while ping -l $i -f -n 1 82.135.16.28; do i=$((i+1)); done; echo $((i-1+8))

Bei 120/6 mit IPv4 kommt da übrigens auch 1480 raus.

Gruß,

Jörg

 

[SpaceRat]

Ich glaube wir müssen nochmal von vorn anfangen da der Test vermutlich aufgrund des fehlenden "echten" Linux nicht korrekt funktioniert.

Raspbian ist ein ganz normales Debian.
Es baut nur jemand Anderes ...

Ich habe jetzt mal wie folgt getestet und bin bis 1472 (soweit ich weiß muss man noch 28 Bytes addieren) und käme somit auf eine max. MTU von 1500. Sobald ich mit 1473 teste kommt die Meldung, dass das Paket fragmentiert werden müsste:

Plus 8 für das IP-Paket, nochmals plus 20 für den Ethernet-Frame.

Ich denke einen geänderten MTU Wert für IPV4 (Abschnitt ar7cfg) wird die Box nicht übernehmen, solange mtumode_auto drin steht, ich weiß aber nicht wie der Wert für manuell lautet.

z.B.

mtu_cutback_mode = yes;
mtu_cutback = 1480;

Ich habe übrigens noch einen zweiten Treffer für die MTU ins Rennen zu werfen:

 dslifaces { ... name = "internet"; ... mtu = 0; etherencapcfg {

 

[Fabricio75]

Danke zunächst mal für eurer Erläuterungen.

Also ich fasse nochmal zusammen (bei 200er Leitung mit 6490):

1. IPV4 MTU ist bei 1472 bzw. 1500 (inkl.)

2. IPV6 MTU mit SIXXS Tunnel aktiv liegt bei max. 1232, also viel zu niedrig. Das Minimum bei SIXXS ist mit 1280 angegeben. Frage ist woher kommt das. Mit der 6360 und der 100er Leitung hat es wunderbar funktioniert.

3. Ich kann die Änderungen in der Export nicht hochladen, egal ob ich es mit Notepad++ oder dem FBEditor mache.

 

[Andreas1969]

Und wie weiter ?

Keine Ideen mehr?

 

[Leseratte10]

3. Ich kann die Änderungen in der Export nicht hochladen, egal ob ich es mit Notepad++ oder dem FBEditor mache.

Du hast aber schon (mit dem FBEditor oder von Hand) die Prüfsumme am Ende der Datei korrigiert?

 

[Fabricio75]

2. IPV6 MTU mit SIXXS Tunnel aktiv liegt bei max. 1232, also viel zu niedrig. Das Minimum bei SIXXS ist mit 1280 angegeben.

Die Frage die sich mir stellt, welche MTU soll ich auf welchen Wert anpassen, weil ja die MTU für IPV4 trotz aktiviertem SIXXS Tunnel in Ordnung ist und bei 1472 bzw. +8 +20 = 1500 liegt. Nur wenn ich per IPV6 z.B. Facebook anpinge liegt die MTU bei 1232, was ja selbst die bei SIXXS einstellbare MTU immens unterschreitet.

Jemand eine Idee?

Das mit der Prüfsumme müsste ich mir dann mal ansehen.

 

[Fabricio75]

Hier mal ein traceroute zu Facebook über IPV6 (sixxs tunnel) und wie es aussieht ist der pop netcologne aus dem Problem eigentlich raus, die Probleme fangen ja später an und ich frage mich wieso so oft dieser dead beef von tfbnw.net auftaucht:

C:\users\Frank>tracert facebook.com
Routenverfolgung zu facebook.com [2a03:2880:2130:cf05:face:b00c:0:1] über maximal 30 Abschnitte: 1 7 ms 6 ms 2 ms fritz.box 2 29 ms 19 ms 19 ms gw-5689.cgn-01.de.sixxs.net 3 19 ms 18 ms 20 ms 2001:4dd0:1234:3::42 4 23 ms 26 ms 18 ms core-eup2-ge1-22.netcologne.de [2001:4dd0:1234:3:dc40::a] 5 26 ms 21 ms 18 ms core-eup1-vl501.netcologne.de [2001:4dd0:a2b:35:dc40::c] 6 39 ms 27 ms 31 ms rtamsix-te4-2.netcologne.de [2001:4dd0:a2b:6d:30::b] 7 22 ms 26 ms 29 ms br02.ams1.tfbnw.net [2001:7f8:1::a503:2934:2] 8 119 ms 118 ms 119 ms be2.bb01.ams3.tfbnw.net [2620:0:1cff:dead:beef::64] 9 39 ms 50 ms 36 ms ae10.bb02.lhr2.tfbnw.net [2620:0:1cff:dead:beef::91d] 10 127 ms 123 ms 127 ms be14.bb01.ewr2.tfbnw.net [2620:0:1cff:dead:beef::ab6] 11 127 ms 129 ms 119 ms be44.bb02.iad3.tfbnw.net [2620:0:1cff:dead:beef::9a9] 12 127 ms 121 ms 129 ms ae13.bb03.frc3.tfbnw.net [2620:0:1cff:dead:beef::12a4] 13 122 ms 124 ms 121 ms ae62.dr03.frc3.tfbnw.net [2620:0:1cff:dead:beef::607] 14 117 ms 119 ms 119 ms po1019.csw12c.frc3.tfbnw.net [2620:0:1cff:dead:beef::263] 15 * * * Zeitüberschreitung der Anforderung. 16 131 ms 121 ms 127 ms edge-star6-shv-12-frc3.facebook.com [2a03:2880:2130:cf05:face:b00c:0:1]
Ablaufverfolgung beendet.

Den Ping mit MTU 1480 (ab 1233 und höher) bricht er ab mit "Allgemeiner Fehler" oder "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.":

C:\users\Frank>ping -6 -l 1480 facebook.com
Ping wird ausgeführt für facebook.com [2a03:2880:2130:cf05:face:b00c:0:1] mit 1480 Bytes Daten:
Allgemeiner Fehler.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 2a03:2880:2130:cf05:face:b00c:0:1: Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

Mit MTU 1232 funktionierts dann so:

C:\users\Frank>ping -6 -l 1232 facebook.com
Ping wird ausgeführt für facebook.com [2a03:2880:2130:cf05:face:b00c:0:1] mit 1232 Bytes Daten:
Antwort von 2a03:2880:2130:cf05:face:b00c:0:1: Zeit=122ms
Antwort von 2a03:2880:2130:cf05:face:b00c:0:1: Zeit=122ms
Antwort von 2a03:2880:2130:cf05:face:b00c:0:1: Zeit=130ms
Antwort von 2a03:2880:2130:cf05:face:b00c:0:1: Zeit=130ms
Ping-Statistik für 2a03:2880:2130:cf05:face:b00c:0:1: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 122ms, Maximum = 130ms, Mittelwert = 126ms

Ich habe noch einen tracepath für IPV4 zum Pop und einen für IPV6 (Google und Facebook tun sich da am Endergebnis nicht viel):

TracePath IPV4 Output: 1: pera.subnetonline.com (141.138.203.105) 0.156ms pmtu 1500 1: gw-v130.xl-is.net (141.138.203.1) 33.204ms 2: rt-eu01-v2.xl-is.net (79.170.92.19) 4.314ms 3: xl-internetservices.nikhef.openpeering.nl (217.170.0.225) 7.224ms 4: nikhef-ixr.openpeering.nl (217.170.0.242) 1.021ms 5: rtamsix.netcologne.de (80.249.209.62) 1.851ms 6: core-eup1-vl31.netcologne.de (78.35.18.81) 5.417ms 7: swrt-eup2-vl501.netcologne.de (87.79.16.142) 6.116ms 8: sixxs-pop1.netcologne.net (78.35.24.124) 5.370ms reached Resume: pmtu 1500 hops 8 back 8

und

TracePath IPv6 Output: 1?: [LOCALHOST] pmtu 1500 1: 2a02:348:82::1 0.362ms 2: xl-internetservices.nl.ip6.jointtransit.nl 0.564ms 3: nikhef-ixr.ip6.openpeering.nl 1. 43ms 4: no reply 5: no reply 6: no reply 7: no reply 8: no reply 9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
31: no reply Too many hops: pmtu 1500 Resume: pmtu 1500

Ich würde ja mal eine Änderung auf Grundlage einer plausibel begründeten Aussage probieren, aber wild umherkonfigurieren möchte ich nicht und aufgrund dessen dass die IPV6 MTU so extrem niedrigen 1232 liegt (der Wert wird ja per Webinterface gar nicht erst angenommen) wüsste ich nicht was ich verändern soll.

 

[SpaceRat]

Ich würde ja mal eine Änderung auf Grundlage einer plausibel begründeten Aussage probieren, aber wild umherkonfigurieren möchte ich nicht und aufgrund dessen dass die IPV6 MTU so extrem niedrigen 1232 liegt (der Wert wird ja per Webinterface gar nicht erst angenommen) wüsste ich nicht was ich verändern soll.

Die Idee, an der .export herumzuspielen, basierte auch auf der Vermutung, daß schon an der IPv4-Verbindung etwas faul sein könnte.

Wenn die allerdings bereits mit einer MTU von 1480 bzw. 1500 läuft, dann fehlt tatsächlich der Ansatz.

 

[Fabricio75]

Jemand müsste mal ohne die Fritzbox 6490 am 200er Anschluss einen Sixxs Tunnel testen, sofern das irgendwie möglich ist (vermutlich müsste der Tunnel dann lokal eingerichtet werden, die Modems haben ja denke ich nicht die Eingabemöglichkeit). Dann könnte man die Fritze ein- oder ausschließen. Ich habe die Vermutung dass diese irgendwas ungewollt filtert bzw. verschluckt/verliert.

 

[hasselholz]

Ich hab letzte Woche noch mal ein Störungsticket aufgemacht. Mir wurde ein Rückruf eines Spezialisten versprochen. Bekommen habe ich stattdessen eine SMS mit der Aufforderung, einen Werksreset der Fritzbox zu machen Na ja, hab ich mal brav gemacht, hat natürlich auch nix gebracht. Die Probleme sind wie vorher. Also auf zum nächsten Störungsticket ...

 

[Fabricio75]

Hallo hasselholz, hast du von dem neuen Ticket oder generell mal was Neues zu dem Thema gehört?

Vielleicht sollte das mal jemand detailliert und verständlich erklärt an AVM melden.

@alle die das gleiche Problem haben: Habt ihr alle von der 6360 die Konfig geladen oder ist jemand dabei der komplett manuell neu konfiguriert hat inkl. dem Sixxs Tunel?

 

[JurgenS]

@alle die das gleiche Problem haben: Habt ihr alle von der 6360 die Konfig geladen oder ist jemand dabei der komplett manuell neu konfiguriert hat inkl. dem Sixxs Tunel?

Ich habs auch durch mit Werksreset und komplett manuellem neuanlegen. Das ändert nichts.

 

[hasselholz]

Also ich hab beides probiert, einmal Werksreset und alles von Hand neu eingestellt und einmal Werksreset mit Restore vom Backup, beides ohne Erfolg. Entweder ist das ein Problem der Fritzbox 6490 oder es liegt am 200MBt Anschluss. Der Support von UM versteht mich nicht - ich hab das Thema fürs erste aufgegeben, da zwecklos ... :traurig:

 

[Andreas1969]

Auch bei mir (Neukunde seit Februar) mit 6490 funktioniert es nicht. Bei meinem alten Anbieter (Telekom mit 7490, eigentlich baugleich zur 6490) Hat's tadellos funktioniert. Scheint doch was mit der 200 er Leitung zusammenzuhängen. Bei meiner 2ten Adresse (100 er Leitung mit 6360) funktioniert's auch tadellos. Problem liegt also eindeutig bei UM.

 

[Leseratte10]

Neukunde seit Februar? Dann hast du doch eh schon DS-Lite, was willst du da mit nem IPv6-Tunnel?

 

[Andreas1969]

Neukunde seit Februar? Dann hast du doch eh schon DS-Lite, was willst du da mit nem IPv6-Tunnel?

Nein, habe v4, War auch ein harter Kampf, daß ich das bekomme. Hat mich Viel Nerven und Zeit gekostet.

 

[GoaSkin]

Auch wenn man manchmal gute Gründe hat, einen Tunnel statt 6to4 zu nutzen, ist es doch manchmal hilfreich, einfach einmal einen Traceroute auf die 192.88.99.1 zu machen und zu schauen, wo die Pakete hinwandern. Bei Unitymedia ist der nächste Dualstack-Knoten meist bei Hurricane Electric. Und der Hostname des letzten Hops verrät welcher.

Dann macht es Sinn, sich für einen richtigen Tunnel von Hurricane Electric zu entscheiden und dafür genau diesen Knoten zu konfigurieren.

 

[terf]

Hallo,

ich bin diese Woche auf auf den neuen 200er Anschluß gewechselt und habe eine 6490 bekommen. Vorher lief meine eigene ungebrandete 7270er hinter dem UM-Cisco-Modem. 6to4 lief damals ohne Probleme. Jetzt habe ich die gleichen Symptome, die andere in diesem Thread schon beschrieben und es ist mir nicht möglich ein IPv6-Netz aufzubauen. An der Hotline meinte man nur, daß ich mich an AVM wenden soll; UM hätte damit nichts zu tun, und wozu würde ich überhaupt sowas brauchen. Ein Ticket war man nicht bereit aufzunehmen.

Hat mittlerweile jemand Lösungen für das Problem gefunden? Könnte man wenigstens auf dem Client-Rechner einen Tunnel aufbauen oder funktioniert das auch nicht? Und falls ja, welcher Anbieter wäre da zu empfehlen?

Dank und Gruß

terf

 

[Joerg]

Hast Du denn noch Deine v4 oder haben die Dich - wie üblich - "aus Versehen" auf DSLite umgestellt...?

Jörg

 

[terf]

Nein, Gottseidank habe ich noch IPv4. Das war mir auch recht wichtig bei der Bestellaufnahme, denn man las ja von derartigen Problemen...

 

[FeuerSturm91]

Hallo zusammen,

ich habe ähnliche Probleme wie bereits hier mehrfach geschildert, allerdings hatte ich keine Probleme mit
MTU > 1232 (1280 bis 1480 getestet) IPv6 server an zu pingen.

Mein Problem besteht "lediglich" darin, dass die Websites, sofern sie per IPv6 erreichbar sind,
"ewig und drei Tage" laden und dann irgendwann halb angezeigt werden oder das Zeitlimit
überschritten wird und nur die Info "Website kann nicht angezeigt werden" kommt.

Wie viele von Euch war ich bis letzte Woche stolzer Nutzer der FB 6360 und einer 150 / 5 Leitung und hatte absolut keine Probleme
mit meinem SixXs Tunnel, dann auf 200 / 20 mit FB 6490 gewechselt und schon gab es die oben beschriebenen
Probleme.

Mit Hilfe des Programms "Wireshark" (Network Protocol Analyzer) ist mir dann aufgefallen, dass ich in einer Art "reconnect loop"
lande wenn ich zu einer IPv6 Website browsen möchte (TCP resets und TCP retransmissions noch und nöcher),
irgendwie lässt die FritzBox 6490 Pakete in- und outbound im nichts verschwinden...
Ich kenne mich leider nicht genug aus um da ein "troubleshooting" zu machen, vielleicht probiert sich einer der schlaueren mal
mit dem Programm....

An der 200er Leitung an sich liegt es meiner Meinung nicht, da ich einen Tunnel von meinem Rechner aus problemlos aufbauen
und nutzen kann.....

Kennt vielleicht jemand jemanden der jemanden kennt bei dessen Onkel alles reibungslos (SixXS Tunnel) funktioniert und dieser auch eine
FB 6490 mit FOS 6.20 und 200er Leitung von UM benutzt?

 

[GoaSkin]

Hallo,

ich bin diese Woche auf auf den neuen 200er Anschluß gewechselt und habe eine 6490 bekommen. Vorher lief meine eigene ungebrandete 7270er hinter dem UM-Cisco-Modem. 6to4 lief damals ohne Probleme. Jetzt habe ich die gleichen Symptome, die andere in diesem Thread schon beschrieben und es ist mir nicht möglich ein IPv6-Netz aufzubauen. An der Hotline meinte man nur, daß ich mich an AVM wenden soll; UM hätte damit nichts zu tun, und wozu würde ich überhaupt sowas brauchen. Ein Ticket war man nicht bereit aufzunehmen.

Hat mittlerweile jemand Lösungen für das Problem gefunden? Könnte man wenigstens auf dem Client-Rechner einen Tunnel aufbauen oder funktioniert das auch nicht? Und falls ja, welcher Anbieter wäre da zu empfehlen?

6-to-4 Pakete wandern bei Unitymedia auf direktem Wege zu einem 6-to-4 Gateway von Hurricane Electric (traceroute auf 192.88.99.1). In Abhängigkeit von der Client-IPv4-Adresse tut dieses Gateway aber nicht immer seinen Dienst. Internet-Verbindung trennen und neu verbinden (bis man eine IP aus einem anderen Bereich hat) hilft. Das Kuriose: Eingehende 6-to-4-Pakete kommen immer an, ausgehende werden in Abhängigkeit von der Client IP ggf. verworfen. Das habe ich mal getestet, in dem ich auf dem 6-to-4 Host einen Traffic-Monitor laufen lassen habe und gesehen, dass Ping-Pakete von einem anderen IPv6-Host tatsächlich ankommen, die Antwort aber nicht.

Möglicherweise sperrt Hurricane Electric bestimmte IP-Bereiche für das 6-to-4 Gateway aus, evtl. wegen eines Missbrauches in der Vergangenheit. Ich vermute, dass hier schlichtweg ein Paketfilter bei HE die Ursache ist.

Ein echter Tunnel von Hurricane Electric funktioniert aber immer.

 

[Andreas1969]

Ist das denn jetzt die Lösung? Tunnel von Hurricane Electric statt von SIXXS in der FB einrichten? Läuft das?

 

[GoaSkin]

Hurricane Electric läuft wunderbar.

Dorthin hat Unity Media einfach die bessere Leitung als zu Sixxs. Zu dem kann man sich dort einen Präfix besorgen, für den man als Nutzer nicht namentlich samt Telefon-Nr. auf einem WHOIS-Server nachzulesen ist. Ferne sperrt einem Hurricane Electric nicht völlig grundlos, wie es bei Sixxs bei Vielen nach ner Weile der Fall ist. Ist auch mit ein paar Klicks eingerichtet, ohne dass das von jemandem bewilligt werden muss.

Einrichtung in der FB als 6in4. Man sollte im Netz aber Anleitungen suchen und beachten.