- Anzeige -

ipv6 Tunnel an ipv4 Anschluss - langsam

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Wichtig:
  • 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.

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Andreas1969 » 15.03.2015, 14:19

Der Eintrag scheint irgend etwas mit der Vorbereitung für das Port Control Protocol für DSlight Anschlüsse zu tun zu haben.
Andreas1969
Glasfaserstrecke
 
Beiträge: 1811
Registriert: 05.03.2015, 08:50
Wohnort: Unitymedia NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Joerg » 15.03.2015, 18: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
Joerg
Übergeordneter Verstärkerpunkt
 
Beiträge: 824
Registriert: 22.09.2007, 19:24
Wohnort: NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon SpaceRat » 15.03.2015, 18: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 / OpenATV 5.3@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2 / OpenATV 6.0@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.0
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Mega HD, Brazzers, XXL, HD-, Sky
Fon: VF Komfort-Classic (ISDN), Siemens S79H+S1+Telekom Modula+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2618
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Fabricio75 » 16.03.2015, 15: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
Fabricio75
Kabelneuling
 
Beiträge: 12
Registriert: 03.11.2014, 17:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Andreas1969 » 19.03.2015, 07:19

Und wie weiter ?

Keine Ideen mehr?
Andreas1969
Glasfaserstrecke
 
Beiträge: 1811
Registriert: 05.03.2015, 08:50
Wohnort: Unitymedia NRW

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Leseratte10 » 19.03.2015, 07: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?
Leseratte10
Glasfaserstrecke
 
Beiträge: 1275
Registriert: 07.03.2013, 16:56

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Fabricio75 » 19.03.2015, 10: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, 17:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Fabricio75 » 20.03.2015, 11: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
Fabricio75
Kabelneuling
 
Beiträge: 12
Registriert: 03.11.2014, 17:19

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon SpaceRat » 21.03.2015, 05: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.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2618
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Re: ipv6 Tunnel an ipv4 Anschluss - langsam

Beitragvon Fabricio75 » 21.03.2015, 10: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
Fabricio75
Kabelneuling
 
Beiträge: 12
Registriert: 03.11.2014, 17:19

VorherigeNächste

Zurück zu Internet und Telefon über das TV-Kabelnetz

Wer ist online?

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