ipv6 Tunnel an ipv4 Anschluss - langsam

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Forumsregeln
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.
Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von SpaceRat » 14.03.2015, 16:40

JurgenS hat geschrieben:Gute Idee. Ich habe dazu beide gleichartige Export-Dateien (6490 und 6360) miteinander verglichen um einen Ansatzpunkt zu finden an welchen Punkten sie sich unterscheiden. Alles was nach Firewall oder MTU oder so aussieht ist aber gleich eingestellt.
Es geht ja durchaus auch um das, was nicht drin bzw. auf Einstellungen a la "autodetect" steht.

Wenn Du mir sagst "Jetzt links abbiegen." biege ich links ab, wenn Du das gleiche meiner Frau sagst, biegt sie rechts ab, es sei denn, es wurde vorher die Einstellung "Meine Seite = links" vorgenommen.

Das gleiche kann ja auch in der Firmware passiert sein:
Wenn Du der 6360 sagst "Erkenne die MTU selber" dann kommt sie wohl auf 1480, die 6490 womöglich nur auf 1280.
Oder es gibt Unterschiede zwischen den Profilen für 100 und 200 MBit/s, die man aber evtl. durch bestimmte feste Vorgaben in der Fritz!Box kompensieren kann ...

Irgendwas nach der Art ...
JurgenS hat geschrieben:Bliebe also nur blindes herumstochern...
Richtig.

Ich kann da nicht viel machen, ich habe keinen Zugriff auf einen Anschluß mit 200 MBit/s und IPv4.
Ich kann nur Vergleichswerte vom 100/10er Profil liefern und da kommt für IPv4 folgendes raus:

Code: Alles auswählen

root@Pi ~ # i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1480
Wenn beim 200er Profil auf der 6490 schon für IPv4 etwas anderes herauskommt, könnte es sinnvoll sein hier mal damit rumzuspielen, den Wert 1480 vorzugeben und den MTU-Test zu wiederholen.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Conan179
Übergeordneter Verstärkerpunkt
Beiträge: 584
Registriert: 25.01.2015, 22:38

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Conan179 » 14.03.2015, 23:32

Wen es von inntresse ist, hier 120mbit, DS-lite

Code: Alles auswählen

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))
1440
BildBildBild

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von SpaceRat » 14.03.2015, 23:38

Conan179 hat geschrieben:Wen es von inntresse ist, hier 120mbit, DS-lite
1440
Ne, ist es in dem Fall nicht.

DS-lite ist ja quasi genau das Umgekehrte dessen, was hier im Thread Thema ist.

Conan179
Übergeordneter Verstärkerpunkt
Beiträge: 584
Registriert: 25.01.2015, 22:38

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Conan179 » 14.03.2015, 23:39

tja war ein versuch wert.
BildBildBild

Fabricio75
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 15.03.2015, 10:06

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

Code: Alles auswählen

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
Zuletzt geändert von Fabricio75 am 15.03.2015, 10:18, insgesamt 2-mal geändert.
Bild

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von SpaceRat » 15.03.2015, 10:11

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

Code: Alles auswählen

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
Krumm ist der Wert, weil schon der Startwert zu hoch ist, d.h. die MTU liegt noch unter 1360 ...

Mach mal

Code: Alles auswählen

i=1240; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
Und damit wäre mein nächster Schritt:
1. pro-forma-Ermittlung der MTU ... so niedrig kann die aber eigentlich nicht wirklich sein ...
2. In der .export nachgucken, wo die MTU der Internet-Verbindung (IPv4) vorgegeben wird und dort 1480 einsetzen

Fabricio75
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 15.03.2015, 11:54

Ich glaube wir müssen nochmal von vorn anfangen da der Test vermutlich aufgrund des fehlenden "echten" Linux nicht korrekt funktioniert. 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:

Code: Alles auswählen

ping -f -l 1472 82.135.16.28

Ping wird ausgeführt für 82.135.16.28 mit 1472 Bytes Daten:
Antwort von 82.135.16.28: Bytes=1472 Zeit=26ms TTL=244
Antwort von 82.135.16.28: Bytes=1472 Zeit=29ms TTL=244
Antwort von 82.135.16.28: Bytes=1472 Zeit=40ms TTL=244
Antwort von 82.135.16.28: Bytes=1472 Zeit=29ms TTL=244

Ping-Statistik für 82.135.16.28:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 26ms, Maximum = 40ms, Mittelwert = 31ms
Dann habe ich mir die Export angeschaut.

Im Abschnitt ar7cfg:

Code: Alles auswählen

mtu_cutback_mode = mtumode_auto;
mtu_cutback = 1500;


und im Abschnitt IPV6 (den SIXXS Tunnel habe ich derzeit nicht aktiviert):

Code: Alles auswählen

use_fixed_mtu = yes;
fixed_mtu = 1500
Im IPV6 Abschnitt variiert der Wert entsprechend sobald ich ihn übers Webinterface ändere und wieder exportiere, im Abschnitt ar7cfg bleibt es immer auf auto und 1500 stehen.

Hilft das weiter?

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.
Bild

Fabricio75
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 15.03.2015, 13:06

Habe jetzt mal die max MTU per IPV6 (SIXXS Tunnel aktiviert) ermittelt. Die Minimum MTU bei SIXXS ist ja mit 1280 angegeben, allerdings funktioniert der IPV6 ping, ich habe heise.de genommen, erst ab 1232, sobald ich höher gehe kommt eine Zeitüberschreitung.

Per IPV4 ping auf 82.135.16.28 bin ich mit einer MTU von 1500 erfolgreich.

PS: ich kann die MTU für ipv4 in der Fritzbox eh nicht anpassen, weil ich die geändert Export nicht mehr einlesen kann. Übers Webinterface kann ich den kleinsten Wert 1280 wählen.
Bild

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 8009
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Andreas1969 » 15.03.2015, 13:11

So, habe jetzt mal ausgelesen:
Fritz 6360 mit 100/5 IPV4 Anschluß mit funktionierenden SIXXS-Tunnel und
Fritz 6490 mit 200/10 IPV4 Anschluß mit nicht funktionierenden SIXXS-Tunnel
Konnte dies tun, da ich 2 Anschlüsse bei UM an 2 Standorten mit den beiden Fritz-Boxen habe.
Die MTU usw. unterscheiden sich jedenfalls nicht.
In der Export-Config ist mir jedoch ein Unterschied in der SIXXS Einstellung aufgefallen:

Fritz 6360:
ip6_static_cfg {
prefix = ::;
prefixlen = 56;
wan_use_firstprefix = yes;
wan_prefix = ::;
wan_ifid_automatic = yes;
wan_ifid = ::;
wan_dns1 = ::;
wan_dns2 = ::;
}
he {
update_server = "ipv4.tunnelbroker.net";
tunnel {
popaddr = 0.0.0.0;
local = ::;
remote = ::;
prefix = ::;
prefixlen = 0;
}
}
firewall {
enabled = yes;
exposed_host = no;
ping6_allowed = no;
rules = "TCP 8089", "TCP 443", "TCP 21";
}
aftr = ::;
}

Fritz 6490:
ip6_static_cfg {
prefix = ::;
prefixlen = 56;
wan_use_firstprefix = yes;
wan_prefix = ::;
wan_ifid_automatic = yes;
wan_ifid = ::;
wan_dns1 = ::;
wan_dns2 = ::;
}
he {
update_server = "ipv4.tunnelbroker.net";
tunnel {
popaddr = 0.0.0.0;
local = ::;
remote = ::;
prefix = ::;
prefixlen = 0;
}
}
firewall {
enabled = yes;
exposed_host = no;
ping6_allowed = no;
rules = "TCP 443", "TCP 21";
}
aftr = ::;
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;
}

In der 6490 steht hinter aftr = ::; noch folgender Eintrag:
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;

In der 6360 gibt es diesen zusätzlichen Eintrag nicht.

Vielleicht ist dies ja der Ansatz.
Kann das ev. mal jemand gegenchecken ?
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Fabricio75
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 15.03.2015, 13:15

Andreas1969 hat geschrieben:In der 6490 steht hinter aftr = ::; noch folgender Eintrag:
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;

Vielleicht ist dies ja der Ansatz.
Kann das ev. mal jemand gegenchecken ?
Kann ich bei meiner 6490 bestätigen. Habe den Eintrag ebenfalls wie du geschrieben hast.
Bild

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 8009
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Andreas1969 » 15.03.2015, 13:19

Der Eintrag scheint irgend etwas mit der Vorbereitung für das Port Control Protocol für DSlight Anschlüsse zu tun zu haben.
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Joerg
Übergeordneter Verstärkerpunkt
Beiträge: 806
Registriert: 22.09.2007, 19:24
Wohnort: NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Joerg » 15.03.2015, 17:23

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

Code: Alles auswählen

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

Code: Alles auswählen

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

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von SpaceRat » 15.03.2015, 17:31

Fabricio75 hat geschrieben: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 ...

Fabricio75 hat geschrieben: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.

Fabricio75 hat geschrieben: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.

Code: Alles auswählen

mtu_cutback_mode = yes;
mtu_cutback = 1480;



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

Code: Alles auswählen

        dslifaces {
                ...
                name = "internet";
                ...
                mtu = 0;
                etherencapcfg {
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Fabricio75
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 16.03.2015, 14:18

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.
Bild

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 8009
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Andreas1969 » 19.03.2015, 06:19

Und wie weiter ?

Keine Ideen mehr?
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Leseratte10
Glasfaserstrecke
Beiträge: 1424
Registriert: 07.03.2013, 15:56

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Leseratte10 » 19.03.2015, 06:54

Fabricio75 hat geschrieben: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
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 19.03.2015, 09:31

Fabricio75 hat geschrieben:
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.
Bild

Fabricio75
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 20.03.2015, 10:59

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:

Code: Alles auswählen

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.":

Code: Alles auswählen

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:

Code: Alles auswählen

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):

Code: Alles auswählen

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

Code: Alles auswählen

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.
Bild

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von SpaceRat » 21.03.2015, 04:24

Fabricio75 hat geschrieben: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
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 21.03.2015, 09:55

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.
Bild

hasselholz
Kabelneuling
Beiträge: 12
Registriert: 12.02.2015, 07:05

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von hasselholz » 05.04.2015, 09:17

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 :confused: 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
Kabelneuling
Beiträge: 12
Registriert: 03.11.2014, 16:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Fabricio75 » 05.05.2015, 17:12

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?
Bild

JurgenS
erfahrener Kabelkunde
Beiträge: 76
Registriert: 28.03.2010, 12:09

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von JurgenS » 05.05.2015, 18:39

Fabricio75 hat geschrieben:@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.
Bild

hasselholz
Kabelneuling
Beiträge: 12
Registriert: 12.02.2015, 07:05

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von hasselholz » 08.05.2015, 09:35

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 :confused: - ich hab das Thema fürs erste aufgegeben, da zwecklos ... :traurig:

Benutzeravatar
Andreas1969
Network Operation Center
Beiträge: 8009
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitrag von Andreas1969 » 10.05.2015, 17:07

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.
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste