Deutsche Glasfaser - Performance bei Netzen im Aufbau

Denke im Zuge des FTTH Netzausbaus der Telekom bis 2030 und im Zuge der Partnerschaften wird sich deutlich was ändern. Wenn alle wechseln. Naja Uwe Nickel und der alte Geschäftsführer der DG gehen ende diese Jahres und der alte CEO von E-Plus kommt. Diese möchte schnelleren und besseren Support bieten.

PoP-Ort (bzw. Region reicht): Bevergern 48477 Hörstel

CGNat-Subnetz: 100.64.0.0/14

IPv4-Gateway: 100.64.0.1

CGNAT Exit: ve713.cgn2.int1-dus.dg-w.de (185.22.46.72)

IPv6-Gateway: 2a00:6020:0:b::1

Betroffen von Problemem?: Keine Probleme immer vollen Speed über Telia, ECIX, DECIX.

Zitat von layer9

Ich habe heute noch mal nachgefragt bzw. in meinem noch offenen Ticket mitgeteilt, dass die Probleme bei mir noch nicht behoben sind (auch nicht nach dem 05.12.,

so wie es mir angekündigt worden ist).

Man mir geantwortet, dass es in meiner Region derzeit Engpässe gibt und man an deren Behebung arbeitet - und mich um Geduld gebeten.

Ja, und die "Behebung" ist dann abgeschlossen wen der Lockdown aufgehoben worden ist.

Die machen nix.

Edit: 20:47 Uhr

Heute sieht es ganz gut aus. Um 19:40Uhr war es für ca. 10 min wieder down. Dachte schon "Oh, Heute früher". Aber dann ging es wieder. Ping auf Youtube ca. 10ms.

Edit: Und wieder langsam. Bäh.

Bei mir ist alles immernoch top. Eigentlich müsste die DG nur die Engpässe beheben. Die Peerings laufen Super, hatte da im Gegensatz zur Telekom oder Vodafone noch nie Probleme

Zitat von Rxyzr

Eigentlich müsste die DG nur die Engpässe beheben.

Das kostet. Nichts tun kostet nichts.

Okay, das ist jetzt merkwürdig. Ich habe einfach einen Ping laufen gehabt auf youtube. Hatte so um die 10ms gehabt. Um 21:47 Uhr ging dann plötzlich ein Packet verloren. Und exakt zu dem Zeitpunkt ist das Problem wieder da. IPv6 ist unbrauchbar. Das ist doch keine Überlastung oder? Da ist doch was kaputt.

Das mit den Engpässen am abend hält jetzt hier in PLZ 41849 schon seit ca. 8 Wochen an. Anbei Screenshots von den Antwortzeiten. Da sieht man die Ausschläge am Abend ganz deutlich. Nicht nur die Latenz ist dann hoch, auch die Downloadrate bricht dann von 400 Mbps auf unter 2 Mbps ein. Das tritt sowohl bei IPv6 als auch bei IPv4 ein.

Bin seit 4 Jahren Kunde der DG und diese Einbrüche abends kommen in regelmässigen Abständen vor. Es dauert dann einige Monate bis die DG ihr Netz skaliert. Vielleicht wird erst der Lockdown abgewartet und dann im Frühjahr/Sommer ein Upgrade gemacht und bis dahin der Kunde hingehalten.

Ich habe mittlerweile mal eine Teststellung zu einem IPerf Server innerhalb eines PoPs erstellt. Selbst dort sieht man das in den Abendsstunden die Bandbreite sinkt.

Zitat von franzhubert

Selbst dort sieht man das in den Abendsstunden die Bandbreite sinkt.

Wenn das der Pop ist, an dem der iperf3 Client selbst dranhängt, ist das aber schon sehr merkwürdig, da Dein Kabel ja direkt in den Pop führt.

Das würde ja heißen, dass der Flaschenhals schon im Pop existiert. Schwer vorstellbar.

Zitat von alfalfa

Was meinst du mit "innerhalb eines PoPs"?

Ich nutze zwei DG Anschlüsse innerhalb eines Ortes. Sprich meinen eigenen und den meines Nachbarn. Diese beiden Fasern müssten ja theoretisch in den selben PoP landen bzw. angeschlossen werden. Innerhalb des PoP nutzen diese ja dann auch die selbe Technik.

Zitat von onurbi

Wenn das der Pop ist, an dem der iperf3 Client selbst dranhängt, ist das aber schon sehr merkwürdig, da Dein Kabel ja direkt in den Pop führt.

Das würde ja heißen, dass der Flaschenhals schon im Pop existiert. Schwer vorstellbar.

Das war auch mein Empfinden. Innerhalb eines "Netzwerkes" sollte es keine Engpässe geben. Warum sollte hier die Bandbreit so zusammen brechen!?
Anbei nochmal ein Trace von den beiden Clients die ich nutze. Dies ist einmal eine OPNSense und ein Raspberry3b+ hinter einer Fritzbox.

OPNSense WAN Interface
traceroute -w 2 -n  -m '18'  '1.1.1.1'
traceroute to 1.1.1.1 (1.1.1.1), 18 hops max, 40 byte packets
 1  100.124.1.8  5.756 ms  7.269 ms  3.998 ms
 2  100.127.1.13  3.586 ms  4.147 ms  4.034 ms
 3  185.22.46.72  4.591 ms  8.221 ms  7.846 ms
 4  62.115.38.12  7.858 ms  4.165 ms  7.843 ms
 5  213.248.100.154  4.478 ms  8.103 ms  7.473 ms
 6  1.1.1.1  7.528 ms  3.819 ms  4.056 ms
 
 
Raspberry3b+ hinter Fritzbox
ubuntu@speedott:~$ sudo traceroute -w 2 -n  -m '18'  '1.1.1.1'
traceroute to 1.1.1.1 (1.1.1.1), 18 hops max, 60 byte packets
 1  192.168.199.1  1.269 ms  1.761 ms  1.894 ms
 2  100.124.1.8  14.259 ms  14.150 ms  14.076 ms
 3  100.127.1.13  13.633 ms  14.927 ms  14.130 ms
 4  185.22.46.72  14.925 ms  14.865 ms  14.667 ms
 5  62.115.38.12  14.116 ms  13.822 ms  13.564 ms
 6  213.248.100.154  13.923 ms  25.158 ms  25.009 ms
 7  1.1.1.1  24.520 ms  15.223 ms  15.786 ms
 
OPNSense WAN Interface
/usr/sbin/traceroute6 -w 2 -n  -m '18' -s '2a00:6020:xx'   'google.com'
traceroute6 to google.com (2a00:1450:4001:815::200e) from 2a00:6020:xx, 18 hops max, 20 byte packets
 1  fe80::ff:fe02:101%igb1  7.675 ms  7.764 ms  4.132 ms
 2  *
    2a00:6020:0:a::1  3.574 ms
    2a00:6020:0:b::1  4.070 ms
 3  2a00:6020::9  35.647 ms  33.058 ms  9.661 ms
 4  2001:4860:0:f8a::c  37.921 ms
    2001:4860:0:f8c::c  40.346 ms
    2001:4860:0:f8b::d  10.080 ms
 5  2607:f8b0:e000:8000::4  12.105 ms  43.911 ms *
 6  2001:4860::8:0:cb93  11.940 ms
    2001:4860::c:4000:f874  11.491 ms
    2001:4860::8:0:cb95  14.477 ms
 7  * * *
 8  2001:4860:0:1::1abd  10.289 ms  11.446 ms
    2001:4860:0:1::1abb  43.579 ms
 9  2a00:1450:4001:815::200e  42.771 ms
    2001:4860:0:1::1abd  9.701 ms
    2001:4860:0:1::1abb  38.756 ms
    
    
Raspberry3b+ hinter Fritzbox
ubuntu@speedott:~$ sudo traceroute6 -w 2 -n  -m '18' -s '2a00:6020:xx'   'google.com'
traceroute to google.com (2a00:1450:400e:807::200e) from 2a00:6020:xx, 18 hops max, 24 byte packets
 1  2a00:6020:4031:xx  1.9847 ms  0.9809 ms  0.9996 ms
 2  * * *
 3  * * *
 4  * * *
 5  2a00:6020::9  54.9469 ms  10.5784 ms  58.7379 ms
 6  2001:4860:0:f8a::1  55.4401 ms  56.9982 ms  56.9657 ms
 7  2001:4860:0:1::1c7f  53.0359 ms  56.0315 ms  56.9338 ms
 8  2a00:1450:400e:807::200e  55.8910 ms  7.0635 ms  54.9244 ms

Zitat von franzhubert

Warum sollte hier die Bandbreit so zusammen brechen!?

Richtig. Sehr merkwürdig!

Ist der Graph rechts unten aus Deinem Screenshot zwischen Dir und Deinem Nachbarn entstanden? Maximal nur 150 Mb/s, weil der Raspi 3+ damit am Anschlag ist? Welcher war der vserver? Die linken beiden hatten ja speedtest.wtnet.de als Gegenstelle.

Ja, deswegen habe ich zu meinem Kumpel im selben PoP keine 1ms. Ich gehe erst zum Gateway 100.68.0.1 nach Borken also über die Backbone und dann zurück.

Zitat von onurbi

Richtig. Sehr merkwürdig!

Ist der Graph rechts unten aus Deinem Screenshot zwischen Dir und Deinem Nachbarn entstanden? Maximal nur 150 Mb/s, weil der Raspi 3+ damit am Anschlag ist? Welcher war der vserver? Die linken beiden hatten ja speedtest.wtnet.de als Gegenstelle.

Genau, der Graph zeigt die Verbindung zwischen meinem Anschluss und den meines Nachbarn. Die beiden Anschlüsse sind jeweils ein DG 400/200. Das dort maximal 150Mbit durchgehen, sollte schon in Ordnung sein. Denke das der Raspberry und die Fritzbox dort noch ein wenig bremsen. Aber man sieht hier sehr schön das der Download relativ stabil ist, bis zu den besagten Abendstunden.
Ich nutze als Vserver einen Netcup VPS 200 G8 . Auf dem Screenshot sind das die gelben Kurven.
Da hier der Download doch sehr schwankt und nicht ganz so aussagekräftig ist, wollte ich zum Vergleich noch einen anderen IPerf Server zum Vergleich haben. Dazu nutze ich den Wilhelm Tell Iperf Server.

Meiner Meinung nach ist das Routing, was die in Ihrem Netz Implementiert haben noch nicht ausgereift. Muss aber ehrlich gestehen das ich von solch großen Provider Netzen nicht wirklich weiß wie das alles funktioniert. Da gibt es ja so viele Dinge die einen Einfluss haben (QoS, Traffishaper, Loadbalancer etc. ectc.) Aber wenn erst alles zum Backbone und zurück geschickt wird, kein Wunder das es in den Abendstunden so zusammenbricht. Irgendwann sind die besten Leitungen voll.

Zitat von franzhubert

Meiner Meinung nach ist das Routing, was die in Ihrem Netz Implementiert haben noch nicht ausgereift.

Danke für Deine Detail!

In der Regel ist die Kommunikation zwischen zwei Kunden gesperrt. Bei DG anscheinend nicht. Dein Test war aber aufschlussreich!

Heute habe ich einen Anruf aus dem 3rd-Level Support bekommen. Ich wurde gebeten, heute Abend zu testen und Feedback zu geben, weil der Fehler behoben sein müsste.

Noch ist nicht 21 Uhr mit dem Minimum.

Aber es sieht heute anders aus: Schon ab 8 Uhr werden bis jetzt gleich starke Schwankungen aufgezeichnet. Sie gehen aber nur bis 200Mb/s runter. Ich hänge den Graphen morgen über den gesamten Tag hier an.

Bei mir hat es schon angefangen. Musste wieder IPv6 ausstellen.

Welche Nachteile habe ich eigentlich wenn ich es ausstelle? Peer to Peer geht nicht oder?

Die auffällige Änderung von gestern: Die Tubulenzen fingen schon um 8 Uhr an und die Minimumzeit war vorverlegt zw. 20:33 und 22:02:

Die Technik war wohl doch zu optimistisch!

Hat von Euch auch einer einen Anruf bekommen?

Das war eine Telefonieraktion zu Kunden, die nützliche Informationen zur Lage abgegeben hatten. Ganz Bayern (und andere Bundesländer) sei betroffen hieß es). Ich hatte im Gespräch den echten Eindruck dass DG aktiv ist das Problem zu lösen.

Hoffnung macht mir, dass DG 2021 am connecttest teilnehmen wird!

Gerade eine E-Mail bekommen

Zitat

Guten Tag xxx

wir haben eine gute Nachricht für Sie: unsere zuständige Abteilung hat den Fall für Sie gelöst und abgeschlossen.

Falls die gemeldete Störung/Problematik weiterhin vorliegt, melden Sie sich gern bei uns.

Bin gespannt. Glaube aber nicht so recht dran.

Edit:

Hat sich nichts getan. DG ist ein Sch..... Provider. Lügen einen einfach an.