Beiträge von franzhubert

Zitat von lycra

Mit welchem Script machst du das ? Und auf einem Windows Server oder über eine Synology?!

Hi lycra. Ich nutze hier einen Ubuntu Server (Proxmox) der bei mir zuhause in der DMZ steht. Hier habe ich eine Influxdb installiert (TICK Stack).
Von dort aus lasse ich dann per telegraf zu verschiedenen Servern im "Internet" mit IPERF (https://iperf.fr/) den Download oder Upload abfragen.
Die Ergebnisse werden dann mit Grafana visualisiert.

Was ich nach gut drei Woche bestätigen kann ist das etwas gemacht wurde. Es bricht zwar immer noch die Bandbreite zu den besagten Zeiten ein, aber nicht mehr so massiv wie am Anfang. Auch "innerhalb" des Pop bricht der Upload nicht mehr so zusammen wie am Anfang.

Das es nur IPv6 betrifft kann ich nicht bestätigen. Die Probleme sind auch im IPv4 Bereich die selben.
Also immer wieder Tickets schreiben. Social Media ist die schlechteste Lösung um ein Problem zu lösen.

Hallo.
Auch mir wurde vom Support mitgeteilt das das Problem behoben sei.
Leider kann auch ich das nicht bestätigen. Auch nach dem ich einmal alle meine Endgeräte neu starten sollte.
Hab es mal gemacht im guten Glauben aber auch das bringt keine Veränderung.
Also wieder ein Ticket aufmachen.

[Offtopic]
Das mit dem Support ist eine ganz einfache Geschichte. Der 1st Level Support, sprich die Hotline bzw. die die Emails senden, sind im Prinzip der Puffer für den 2nd Support bzw. 3rd support. Das kann sein das da jemand sitz der echt Ahnung hat und Bock auf so einen Job hat oder dort sitzt jemand der einfach den Job nach gewissen Regeln erfüllt. Die sammeln erstmal alles und verarbeiten das.

Meiner Meinung nach hat hier die DG ein großes Problem. Die kommen im Service nicht hinterher. Die bauen Ihre Netze schnell auf aber im Hintergrund dauert dies alles viel Länger.
Im Prinzip gibt es da ein schönes Sprichwort. "Scheiße fällt immer nach unten" und das letzte Glied der Kette ist der Kunde .

Also immer schön freundlich aber bestimmend zum 1st Level sein.

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

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.