#2841  (Permalink
Alt 02.08.2020, 12:56
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 4.834
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von michael4 Beitrag anzeigen
DHCPv6 ist eine Krücke, die wegen irgendwelcher Unternehmensadmins eingeführt wurde, die ihr Netz nicht auf die Reihe gekriegt haben bzw. SLAAC nicht verstanden haben. Dummerweise hat die Telekom irgendwann angefangen auf SLAAC verzichten zu wollen.

Aber meine mit meiner Frage "Wieso DHCPv6" war gemeint, wieso die Probleme mit DHCPv6 zusammenhängen sollen. Sorry, war etwas unglücklich formuliert.
Sorry, SLAAC ist genau (bzw. genauso wenig) so eine Krücke wie DHCPv6. Das Problem war, dass die IPv6-Fraktion in der IETF versucht hat ihre Vorstellung wie man Netze zu konfigurieren habe, so ziemlich kompromisslos durchgesetzt hat ohne auf die Fraktion der System-/Netzwerk-Administratoren zu hören. (Deshalb ein Teil der Funktionalität die bei IPv4 von DHCP übernommen wird, bei IPv6 in den RAs gelandet ist).
Lustiger weise sind IMHO realere Probleme wie Path MTU discovery genau so halbherzig geloest wie bei IPv4. Hat jetzt aber nichts mehr mit Youtube, Peering, oder der Telekom zu tun...

Gruss
P.
Mit Zitat antworten
  #2842  (Permalink
Alt 02.08.2020, 16:37
almightyloaf almightyloaf ist offline
Senior Mitglied
 
Registriert seit: 06.03.2019
Beiträge: 896
Provider: WucherkomDeutschland GmbH
Bandbreite: "0.25"/0.1 Gb/s
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von Tester100 Beitrag anzeigen
Einige Zeit schien es eher ruhig, jetzt laufen plötzlich Steam Videostreams wieder ziemlich bescheiden, und Youtube auch noch. Anscheinend ist es besonders schlimm wenn es über IPv6 läuft. Datenrate ist am Anfang gut (volle 80 Mbit), dann tröpfelt es nur noch mit 3 Mbit und weniger... Über ProtonVPN sieht es natürlich wieder besser aus -_- Was habt ihr so beobachtet? *seufz*
Jo also ich habe IPv6 inzwischen aktiviert und tatsächlich ist das so dass Youtube richtig am buffern ist und dementsprechend entweder in der quali runtergeht oder halt ewig lädt. Ziemlich nervig, allerdings ist das über IPv4 nicht der Fall.
__________________
Hier ist Raum für Fehler [ -viel Raum- ] Denn ich bin auch nicht Allwissend!
Telekom - Erleben, was verbindung trennt #nichtdabei
#peeringmatters -> AS3320 meiden
Mit Zitat antworten
  #2843  (Permalink
Alt 02.08.2020, 17:08
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 4.834
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von almightyloaf Beitrag anzeigen
Jo also ich habe IPv6 inzwischen aktiviert und tatsächlich ist das so dass Youtube richtig am buffern ist und dementsprechend entweder in der quali runtergeht oder halt ewig lädt. Ziemlich nervig, allerdings ist das über IPv4 nicht der Fall.

Ich bin fast 100% sicher, dass es sich bei Deinen Problemen nicht um ein genetisches IPv4/6 Problem handelt. Für die meisten Telekomkunden dürfte YouTube via IPv6 liefern, so dass ein generelles Problem schnell auffallen sollte. Das heißt natürlich nicht, dass ich bezweifle, dass es bei Dir einen Unterschied wischen den IP Versionen bezüglich YouTube QoE gibt, aber ein Einzelfall ist nicht die belastbarer Basis für ein allgemeine Hypothese...


Gruss
P.
Mit Zitat antworten
  #2844  (Permalink
Alt 02.08.2020, 19:24
almightyloaf almightyloaf ist offline
Senior Mitglied
 
Registriert seit: 06.03.2019
Beiträge: 896
Provider: WucherkomDeutschland GmbH
Bandbreite: "0.25"/0.1 Gb/s
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Ich bin fast 100% sicher, dass es sich bei Deinen Problemen nicht um ein genetisches IPv4/6 Problem handelt. Für die meisten Telekomkunden dürfte YouTube via IPv6 liefern, so dass ein generelles Problem schnell auffallen sollte. Das heißt natürlich nicht, dass ich bezweifle, dass es bei Dir einen Unterschied wischen den IP Versionen bezüglich YouTube QoE gibt, aber ein Einzelfall ist nicht die belastbarer Basis für ein allgemeine Hypothese...


Gruss
P.
Alles gut, ich war/bin ja auch erstaunt dass es bei YouTube nicht läuft. Ich teile hier auch nur die tatsache mit, dass wenn ich IPv6 deaktiviere YouTube problemlos lädt. Warum das so ist, ist mir auch ein Rätsel. Ich bin aber ja wohl nicht ganz alleine mit dem Sachverhalt
__________________
Hier ist Raum für Fehler [ -viel Raum- ] Denn ich bin auch nicht Allwissend!
Telekom - Erleben, was verbindung trennt #nichtdabei
#peeringmatters -> AS3320 meiden
Mit Zitat antworten
  #2845  (Permalink
Alt 02.08.2020, 23:27
michael4 michael4 ist offline
Senior Mitglied
 
Registriert seit: 11.08.2012
Beiträge: 1.381
Provider: DTAG
Bandbreite: SVDSL Sync: 251/46
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Sorry, SLAAC ist genau (bzw. genauso wenig) so eine Krücke wie DHCPv6. Das Problem war, dass die IPv6-Fraktion in der IETF versucht hat ihre Vorstellung wie man Netze zu konfigurieren habe, so ziemlich kompromisslos durchgesetzt hat ohne auf die Fraktion der System-/Netzwerk-Administratoren zu hören. (Deshalb ein Teil der Funktionalität die bei IPv4 von DHCP übernommen wird, bei IPv6 in den RAs gelandet ist).
.
Ja, die Admins hatten ja schon Bauchschmerzen bekommen als sie gehört haben, dass nun jeder Client "offizelle" IPs bekommen soll. Weil NAT ja soo sicher ist. Das Geschrei war groß und man wollte unbedingt die link-local IPv6 Adressen NATen. Der einzig valide Grund gegen SLAAC war doch, dass die DNS Server nicht übermittelt werden konnte. Aber das kam ja dann mit RFC 6106 dazu. Und dank RFC 4941 hat man ja auch die Privacy Extensions bei SLAAC.
Wo ist denn dein Problem mit SLAAC? "Mein" (und damit meine ich nicht mein privates) Netz funktioniert seit Jahren problemlos und die Sicherheit ist gewährleistet. Man muss sich eben an die Regeln halten und beim Netzdesign wissen, was man tut.

Geändert von michael4 (02.08.2020 um 23:33 Uhr)
Mit Zitat antworten
  #2846  (Permalink
Alt 03.08.2020, 01:53
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 4.834
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Naja, 64 bit dafür zu reservieren, dass endhosts mit hoher Wahrscheinlichkeit bei der automatischen Addressgenerierung nicht kollidieren, ist IMHO suboptimal. Warum nominell 128 Bit Adressen erzeugen und dann die letzen 64 bit dermassen blöde zu verplempern... Ohne den Blödsinn, wäre die /64 welche ein ISP mindestens stellen muss/soll ausreichend für alle Subnetting Anwendung die ein Heimnetz nur haben kann, Dank SLAAC und Androids beharren auf nur SLAAC, sind die letzten 64 Bit der Adresse schlecht investiert. Das wird eigentlich schon klar wenn man bedenkt, dass ein Vorschlag war die 48bit MAC Addressen von Netzwerkkarten (salop formuliert) als der Grossteil der 64bit zu verwenden...


Gut, das ist alles Wasser unter der Brücke und wird sich so schnell nicht mehr ändern, aber ich bleibe dabei, IPv6 leidet zum Teil am (wahrscheinlich kaum vermeidbaren) Second-System Syndrom, und die Autoaddressgenerierung ist da ein gutes Beispiel.


Gruss
P.
Mit Zitat antworten
  #2847  (Permalink
Alt 09.08.2020, 23:56
Tester100 Tester100 ist offline
Neues Mitglied
 
Registriert seit: 16.11.2019
Beiträge: 13
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Hier ist eine kleine Speedtest-Übersicht: https://abload.de/img/2020-08-06_205958_spe5akb7.jpg
Dienste wie Windscribe haben bei M247 zum Beispiel ihre Server. Ich habe mit dem Opera Browser "VPN" und Cloudflares Warp auch Speedtests gemacht, dass war bei beiden alles wesentlich schneller. Das Thema mag sich für manche vielleicht wiederholen, aber es ist immer noch absolut relevant und man findet dieses Thema sehr weit oben bei Google.

Cloudflares Warp gibt es noch nicht offiziell für Windows, lässt sich aber über einen Umweg schon jetzt nutzen. Ist ideal um der Peering-Hölle einfach zu entgehen, und da zeigen die Traceroutes auch endlich mal ecix und decix. Eine Anleitung wie man Warp unter Windows benutzt befindet sich hier: https://www.reddit.com/r/CloudFlare/...dows_tutorial/
Das eine dort gezeigte Programm ist aber veraltet, lieber das hier zum Erstellen des Cloudflare Konto-Tokens benutzen: https://github.com/ViRb3/wgcf
Mit Zitat antworten
  #2848  (Permalink
Alt 11.08.2020, 19:22
user375 user375 ist offline
Mitglied
 
Registriert seit: 07.11.2018
Beiträge: 242
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von almightyloaf Beitrag anzeigen
Jo also ich habe IPv6 inzwischen aktiviert und tatsächlich ist das so dass Youtube richtig am buffern ist und dementsprechend entweder in der quali runtergeht oder halt ewig lädt. Ziemlich nervig, allerdings ist das über IPv4 nicht der Fall.
Ihr seid nicht die einzigen, die mit IPv6 Probleme haben. Es gibt Destinations, die via IPv6 eine Bandbreite haben, die an Frechheit grenzt (200 kByte/s oder so ähnlich statt wenigstens mehrere MByte/s). Auch passiert es immer wieder bei beliebigen unterschiedlichsten bekannten, gängigen Seiten, dass sie einfach nicht laden. Die bleiben ewig im TCP SYN hängen, bis endlich mal der 3. oder 4. oder ein manueller Reload funktioniert. Ich bin schon vor Jahren dazu übergegangen, meinen Squid auf dns_v4_first on zu stellen (alle halbes Jahr teste ich für ein paar Stunden um festzustellen, dass der Murks unverändert ist). Damit funktioniert alles immer problemlos.

Außerdem, warum sollte ich IPv6 verwenden - kostet nur völlig sinnlos unnötigen erheblichen zusätzlichen Overhead.

Konkretes Bsp. (Problem ist hier wohl außerhalb der Telekom - ist mir aber völlig egal - das schwächste Glied in der Kette entscheidet über brauchbar oder nicht):
Code:
wget -6 -O /dev/null https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
--2020-08-11 18:43:18--  https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
Auflösen des Hostnamen »downloads.asterisk.org (downloads.asterisk.org)«... 2001:470:e0d4::ee
Verbindungsaufbau zu downloads.asterisk.org (downloads.asterisk.org)|2001:470:e0d4::ee|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 43455574 (41M) [application/x-gzip]
In »»/dev/null«« speichern.

13% [===================>                                                                                                                                   ] 5.840.896    202KB/s  ETA 3m 19s
(habe ich abgebrochen - ist mir zu blöd)

wget -4 -O /dev/null https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
--2020-08-11 18:47:28--  https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
Auflösen des Hostnamen »downloads.asterisk.org (downloads.asterisk.org)«... 76.164.171.238
Verbindungsaufbau zu downloads.asterisk.org (downloads.asterisk.org)|76.164.171.238|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 43455574 (41M) [application/x-gzip]
In »»/dev/null«« speichern.

100%[======================================================================================================================================================>] 43.455.574  3,51MB/s   in 8,3s   

2020-08-11 18:47:36 (4,97 MB/s) - »»/dev/null«« gespeichert [43455574/43455574]
Hier die Traceroutes:

Code:
mtr -wezb -6 -c 50 2001:470:e0d4::ee
Start: Tue Aug 11 18:56:59 2020
HOST: myhost                                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS3320  ich          (....)                                                           0.0%    50    0.6   0.6   0.5   0.9   0.0
  2. AS3320  (Telekom)                                                                     0.0%    50    5.5   6.0   4.8  44.3   5.5
  3. AS3320  2003:0:130e:17::2                                                             0.0%    50   10.6  13.1   9.6 111.9  14.8
  4. AS6939  100ge8-1.core1.fra1.he.net (2001:470:0:512::1)                                0.0%    50   16.8   8.7   7.4  18.5   2.0
  5. AS6939  100ge11-1.core1.fra2.he.net (2001:470:0:404::2)                               0.0%    50    8.2  11.3   7.8  28.6   6.0
  6. AS6939  e0-53.core1.ams2.he.net (2001:470:0:4b7::2)                                  30.0%    50   26.4  17.1  14.9  28.1   3.4
  7. AS6939  100ge8-1.core1.lon3.he.net (2001:470:0:227::1)                                2.0%    50   21.3  23.8  20.9 140.9  17.1
  8. AS6939  100ge14-1.core1.lon2.he.net (2001:470:0:3ea::1)                               2.0%    50   40.9  22.6  19.0  40.9   6.6
  9. AS6939  100ge13-2.core1.nyc4.he.net (2001:470:0:2cf::2)                               0.0%    50   90.8  91.8  90.3 101.5   2.6
 10. AS6939  100ge16-1.core1.ash1.he.net (2001:470:0:299::1)                               0.0%    50   90.7  93.5  90.5 113.5   6.3
 11. AS6939  tserv2.ash1.he.net (2001:470:0:90::2)                                         0.0%    50   92.4  93.7  92.0 117.7   4.6
 12. AS6939  tunnel46228-pt.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:4c2::2)            0.0%    50  115.5 115.7 113.3 149.4   7.9
 13. AS6939  2001:470:e0d4::ee                                                             0.0%    50  113.5 117.1 113.3 164.5  10.8


mtr -wezb -4 -c 50 76.164.171.238
 Start: Tue Aug 11 18:49:27 2020
HOST: myhost                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. ich
  2. ich
  3. AS3320  Telekom                                                 0.0%    50    8.6   8.9   8.5  10.0   0.1
  4. AS3320  Telekom wie oben                                        0.0%    50    8.8   8.6   8.2   9.0   0.0
  5. AS3320  80.157.201.198                                          0.0%    50    8.2   8.4   8.1   8.9   0.0
  6. AS174   be3186.ccr41.fra03.atlas.cogentco.com (130.117.0.1)     0.0%    50    8.6   8.5   8.1   9.1   0.0
  7. AS174   be2799.ccr41.par01.atlas.cogentco.com (154.54.58.234)   8.0%    50   22.5  22.7  22.4  23.3   0.0
  8. AS174   be2315.ccr31.bio02.atlas.cogentco.com (154.54.61.113)   4.0%    50   29.9  30.0  29.5  30.8   0.0
  9. AS174   be2331.ccr41.dca01.atlas.cogentco.com (154.54.85.241)   0.0%    50  104.2 104.5 104.0 105.0   0.0
 10. AS174   be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158)    0.0%    50  115.3 115.7 115.1 122.5   1.0
 11. AS174   be2847.ccr41.atl04.atlas.cogentco.com (154.54.6.102)    0.0%    50  115.4 115.5 115.1 115.9   0.0
 12. AS174   38.142.129.10                                           0.0%    50  109.9 112.1 109.3 172.6   9.6
 13. AS14793 atl.hsv.net.apid.com (76.164.170.41)                    0.0%    50  120.8 120.6 120.0 127.8   1.1
 14. AS14793 76.164.170.13                                           0.0%    50  115.4 116.7 115.1 140.9   4.3
 15. AS14793 shooty.asterisk.org (76.164.171.238)                    0.0%    50  115.4 117.1 114.5 156.1   7.1
Mit Zitat antworten
  #2849  (Permalink
Alt 11.08.2020, 19:49
almightyloaf almightyloaf ist offline
Senior Mitglied
 
Registriert seit: 06.03.2019
Beiträge: 896
Provider: WucherkomDeutschland GmbH
Bandbreite: "0.25"/0.1 Gb/s
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von user375 Beitrag anzeigen
Ihr seid nicht die einzigen, die mit IPv6 Probleme haben. Es gibt Destinations, die via IPv6 eine Bandbreite haben, die an Frechheit grenzt (200 kByte/s oder so ähnlich statt wenigstens mehrere MByte/s). Auch passiert es immer wieder bei beliebigen unterschiedlichsten bekannten, gängigen Seiten, dass sie einfach nicht laden. Die bleiben ewig im TCP SYN hängen, bis endlich mal der 3. oder 4. oder ein manueller Reload funktioniert. Ich bin schon vor Jahren dazu übergegangen, meinen Squid auf dns_v4_first on zu stellen (alle halbes Jahr teste ich für ein paar Stunden um festzustellen, dass der Murks unverändert ist). Damit funktioniert alles immer problemlos.
Ich muss gestehen dass ich meine IPv6 Probleme nicht ins Detail angegangen bin, lediglich habe ich festgestellt dass die Ladezeiten teilweise extrem lang sind. Ob das jetzt ein Problem des TCP SYN ist oder was anderes habe ich nicht nachgeforscht, könnte aber auch die Ursache sein für meine Probleme. Daher habe ich wie schon hier gepostet eigentlich IPv6 deaktiviert (jetzt aber wieder aktiviert zum beobachten).

Dass Datenübertragungsraten bei der Telekom an der Frechheit grenzen ist jetzt aber nichts neues

Bin froh wenn die Telekom ihr FTTH-Netz (wie Wilhelm Tel und die DG es tun, sind aber vielleicht nicht die einzigen zwei die das tun) öffnen... je nach tageslaune ist es schon eine Strafe über FTTH ohne VPN zu surfen. o2 liefert ja hier tadelloses LTE (wovon sich hier übrigens die Telekom eine scheibe abschneiden sollte), aber das ist nicht sinn der Sache, FTTH zu haben um dann über mobilfunk zu surfen... genauso wie es eigentlich nicht sinn der Sache ist immer über ein VPN zu surfen aus dem grund dass sich der eigene ISP so verhält. Was kann man tun, die breite masse ist es entweder egal eine derart beschnitte Leistung zu erhalten oder sie wissen einfach nicht wer für den Engpass verantwortlich ist, wenn es bei (ehem.)Unitymedia usw zur gleichen zeit flutscht. Die Telekom sagt ja immer fleissig, es wäre bei denen alles i.o. und schicht sogar gleich den Techniker mit raus für mehr effekt. Ich bin wohl nicht der einzige der besuch bekam

Bedauerlich ist halt dass zu dem thema so gut wie nichts passiert, daher kaut man immer das gleiche wieder durch, von wegen "bei Telia laggt's mal wieder" und "bei cogent schon immer schei..." usw
__________________
Hier ist Raum für Fehler [ -viel Raum- ] Denn ich bin auch nicht Allwissend!
Telekom - Erleben, was verbindung trennt #nichtdabei
#peeringmatters -> AS3320 meiden

Geändert von almightyloaf (11.08.2020 um 20:01 Uhr)
Mit Zitat antworten
  #2850  (Permalink
Alt 11.08.2020, 20:01
PaIn PaIn ist offline
Senior Mitglied
 
Registriert seit: 19.11.2002
Alter: 37
Beiträge: 525
Provider: Unitymedia
Bandbreite: 200/20 Mbit/s DS
Standard AW: Telekom Peering / Youtube Geschwindigkeit

Zitat:
Zitat von user375 Beitrag anzeigen
Ihr seid nicht die einzigen, die mit IPv6 Probleme haben. Es gibt Destinations, die via IPv6 eine Bandbreite haben, die an Frechheit grenzt (200 kByte/s oder so ähnlich statt wenigstens mehrere MByte/s). Auch passiert es immer wieder bei beliebigen unterschiedlichsten bekannten, gängigen Seiten, dass sie einfach nicht laden. Die bleiben ewig im TCP SYN hängen, bis endlich mal der 3. oder 4. oder ein manueller Reload funktioniert. Ich bin schon vor Jahren dazu übergegangen, meinen Squid auf dns_v4_first on zu stellen (alle halbes Jahr teste ich für ein paar Stunden um festzustellen, dass der Murks unverändert ist). Damit funktioniert alles immer problemlos.

Außerdem, warum sollte ich IPv6 verwenden - kostet nur völlig sinnlos unnötigen erheblichen zusätzlichen Overhead.

Konkretes Bsp. (Problem ist hier wohl außerhalb der Telekom - ist mir aber völlig egal - das schwächste Glied in der Kette entscheidet über brauchbar oder nicht):
Code:
wget -6 -O /dev/null https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
--2020-08-11 18:43:18--  https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
Auflösen des Hostnamen »downloads.asterisk.org (downloads.asterisk.org)«... 2001:470:e0d4::ee
Verbindungsaufbau zu downloads.asterisk.org (downloads.asterisk.org)|2001:470:e0d4::ee|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 43455574 (41M) [application/x-gzip]
In »»/dev/null«« speichern.

13% [===================>                                                                                                                                   ] 5.840.896    202KB/s  ETA 3m 19s
(habe ich abgebrochen - ist mir zu blöd)

wget -4 -O /dev/null https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
--2020-08-11 18:47:28--  https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-17.6.0.tar.gz
Auflösen des Hostnamen »downloads.asterisk.org (downloads.asterisk.org)«... 76.164.171.238
Verbindungsaufbau zu downloads.asterisk.org (downloads.asterisk.org)|76.164.171.238|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 43455574 (41M) [application/x-gzip]
In »»/dev/null«« speichern.

100%[======================================================================================================================================================>] 43.455.574  3,51MB/s   in 8,3s   

2020-08-11 18:47:36 (4,97 MB/s) - »»/dev/null«« gespeichert [43455574/43455574]
Hier die Traceroutes:

Code:
mtr -wezb -6 -c 50 2001:470:e0d4::ee
Start: Tue Aug 11 18:56:59 2020
HOST: myhost                                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS3320  ich          (....)                                                           0.0%    50    0.6   0.6   0.5   0.9   0.0
  2. AS3320  (Telekom)                                                                     0.0%    50    5.5   6.0   4.8  44.3   5.5
  3. AS3320  2003:0:130e:17::2                                                             0.0%    50   10.6  13.1   9.6 111.9  14.8
  4. AS6939  100ge8-1.core1.fra1.he.net (2001:470:0:512::1)                                0.0%    50   16.8   8.7   7.4  18.5   2.0
  5. AS6939  100ge11-1.core1.fra2.he.net (2001:470:0:404::2)                               0.0%    50    8.2  11.3   7.8  28.6   6.0
  6. AS6939  e0-53.core1.ams2.he.net (2001:470:0:4b7::2)                                  30.0%    50   26.4  17.1  14.9  28.1   3.4
  7. AS6939  100ge8-1.core1.lon3.he.net (2001:470:0:227::1)                                2.0%    50   21.3  23.8  20.9 140.9  17.1
  8. AS6939  100ge14-1.core1.lon2.he.net (2001:470:0:3ea::1)                               2.0%    50   40.9  22.6  19.0  40.9   6.6
  9. AS6939  100ge13-2.core1.nyc4.he.net (2001:470:0:2cf::2)                               0.0%    50   90.8  91.8  90.3 101.5   2.6
 10. AS6939  100ge16-1.core1.ash1.he.net (2001:470:0:299::1)                               0.0%    50   90.7  93.5  90.5 113.5   6.3
 11. AS6939  tserv2.ash1.he.net (2001:470:0:90::2)                                         0.0%    50   92.4  93.7  92.0 117.7   4.6
 12. AS6939  tunnel46228-pt.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:4c2::2)            0.0%    50  115.5 115.7 113.3 149.4   7.9
 13. AS6939  2001:470:e0d4::ee                                                             0.0%    50  113.5 117.1 113.3 164.5  10.8


mtr -wezb -4 -c 50 76.164.171.238
 Start: Tue Aug 11 18:49:27 2020
HOST: myhost                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. ich
  2. ich
  3. AS3320  Telekom                                                 0.0%    50    8.6   8.9   8.5  10.0   0.1
  4. AS3320  Telekom wie oben                                        0.0%    50    8.8   8.6   8.2   9.0   0.0
  5. AS3320  80.157.201.198                                          0.0%    50    8.2   8.4   8.1   8.9   0.0
  6. AS174   be3186.ccr41.fra03.atlas.cogentco.com (130.117.0.1)     0.0%    50    8.6   8.5   8.1   9.1   0.0
  7. AS174   be2799.ccr41.par01.atlas.cogentco.com (154.54.58.234)   8.0%    50   22.5  22.7  22.4  23.3   0.0
  8. AS174   be2315.ccr31.bio02.atlas.cogentco.com (154.54.61.113)   4.0%    50   29.9  30.0  29.5  30.8   0.0
  9. AS174   be2331.ccr41.dca01.atlas.cogentco.com (154.54.85.241)   0.0%    50  104.2 104.5 104.0 105.0   0.0
 10. AS174   be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158)    0.0%    50  115.3 115.7 115.1 122.5   1.0
 11. AS174   be2847.ccr41.atl04.atlas.cogentco.com (154.54.6.102)    0.0%    50  115.4 115.5 115.1 115.9   0.0
 12. AS174   38.142.129.10                                           0.0%    50  109.9 112.1 109.3 172.6   9.6
 13. AS14793 atl.hsv.net.apid.com (76.164.170.41)                    0.0%    50  120.8 120.6 120.0 127.8   1.1
 14. AS14793 76.164.170.13                                           0.0%    50  115.4 116.7 115.1 140.9   4.3
 15. AS14793 shooty.asterisk.org (76.164.171.238)                    0.0%    50  115.4 117.1 114.5 156.1   7.1
Das problem hier ist, das Asterisk einen ipv6 tunnel benutzt anstelle nativem ipv6
Diese tunnel sind von der bandbreite her stark begrenzt.
Mit Zitat antworten
 
Anzeige
Antwort

Stichworte
drosselkom


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Telekom YouTube Routing CBR600RR Telekom 454 13.11.2018 09:13
Telekom Geschwindigkeit Upgrade? domigio Telekom 17 01.04.2015 14:46
Telekom mal wieder mit Youtube Problemen? Muhhh! Telekom 7 30.10.2014 20:47
Telekom & Youtube - Wird das nochmal was? Flitz Piepe Telekom 92 16.02.2013 18:59
Verfügbarkeit bei Geschwindigkeit Telekom/nicht Telekom? romeon Vodafone 0 01.01.2010 23:07


Alle Zeitangaben in WEZ +2. Es ist jetzt 15:11 Uhr.


Basiert auf vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.