Probleme mit Magenta Gigakraft 5G 500: Massiver Speedeinbruch bei DDownload!

[solo99]

Hallo,

habe Magenta gigakraftt 5g 500 noch in der Testphase.

Mir ist aufgefallen das bei DDownload ein massiver Speedeinbruch ist, von z.b. 50 mb/s auf 200 kb/s bis 700 kb/s

Wie gesagt zuerst voller Speed, danach immer weniger...

Das kann nur mit Magenta Zusammenhängen. 

Bei Drei hab ich das nicht.

Kann man das irgendwie lösen?

[traffic-opfer]

Seeed: Gerne lasse ich mir von dir deine Lösung erklären!

Poste doch bitte mal ein lokales nslookup zu einem Rapidshareserver deiner Wahl - einmal mit deiner Adguardlösung und einmal ohne.  Dass muss dann ja unterschiedliche IPs ergeben... 

[traffic-opfer]

[hoferanda]

traffic-opfer hat völlig recht, mit DNS hat das nichts zu tun... ein Test:

 

Download DESSELBEN Files https://s133.rapidgator.net/download/e0f5b237-1c49-4215-94d0-b2cf86bc9c24 vom SELBEN Server.

 

1.) direkt via Magenta: Bandbreite startet bei 500mbit und bricht gleich auf einige kb ein.

DNS selbstverständlich wird überall dieselbe IP aufgelöst:

Zitat

C:\Users\xxx>nslookup
Standardserver:  internerdns
Address:  192.168.2.1

> s133.rapidgator.net
Server:  internerdns
Address:  192.168.2.1

Nicht autorisierende Antwort:
Name:    s133.rapidgator.net
Address:  188.130.223.26

> server 9.9.9.9
Standardserver:  dns9.quad9.net
Address:  9.9.9.9

> s133.rapidgator.net
Server:  dns9.quad9.net
Address:  9.9.9.9

Nicht autorisierende Antwort:
Name:    s133.rapidgator.net
Address:  188.130.223.26

> server 1.1.1.1
Standardserver:  one.one.one.one
Address:  1.1.1.1

> s133.rapidgator.net
Server:  one.one.one.one
Address:  1.1.1.1

Nicht autorisierende Antwort:
Name:    s133.rapidgator.net
Address:  188.130.223.26
 

 

Die "lahme" Route über Magenta:

Zitat

Routenverfolgung zu s133.rapidgator.net [188.130.223.26]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1 <-- lokaler Rechner
  2    12 ms    12 ms    10 ms  195-34-148-197.static.upcbusiness.at [195.34.148.197] <-- UPC-HSD-ANCHOR, Magenta
  3     8 ms    12 ms     9 ms  80.241.21.241  <-- UPCAT-Infrastructure, Magenta
  4    19 ms    19 ms    17 ms  at-vie09c-rc01.as8412.net [217.25.122.61] <-- Magenta-Infrastructure, Bregenz
  5    18 ms    18 ms    18 ms  at-vie09c-ri01.as8412.net [217.25.123.5] <-- Magenta-Infrastructure, Bregenz
  6    19 ms    24 ms    17 ms  80-241-24-27.static.upcbusiness.at [80.241.24.27] <-- UPCAT-Infrastructure, Magenta
  7    44 ms    41 ms    45 ms  nl-ams17b-rc1-lag-10-0.aorta.net [84.116.130.54] <-- LibertyGlobal, Schiphol
  8    45 ms    45 ms    44 ms  nl-ams04a-ri3-ae-9-0.aorta.net [84.116.130.242] <-- LibertyGlobal, Schiphol
  9    38 ms    38 ms    38 ms  213.46.191.82 <-- LibertyGlobal CHELLO-BACKBONE, Amsterdam
 10     *       42 ms    41 ms  connected-by.global-layer.com [37.123.210.20] <-- Global Layer B.V., Amsterdam
 11    43 ms    42 ms    42 ms  connected-by.global-layer.com [37.123.210.35] <-- Global Layer B.V., Amsterdam
 12    39 ms    39 ms    38 ms  188.130.223.26 <-- Ultranex LTD (rapidgator.net), Holland 

 

2. den VPN eingeschaltet, Download bei knapp 400mbit, bleibt konstant

DNS wie erwartet

Zitat

Standardserver:  internerdns
Address:  192.168.2.1

> s133.rapidgator.net
Server:  internerdns
Address:  192.168.2.1

Nicht autorisierende Antwort:
Name:    s133.rapidgator.net
Address:  188.130.223.26

> server 9.9.9.9
Standardserver:  dns9.quad9.net
Address:  9.9.9.9

> s133.rapidgator.net
Server:  dns9.quad9.net
Address:  9.9.9.9

Nicht autorisierende Antwort:
Name:    s133.rapidgator.net
Address:  188.130.223.26

> server 1.1.1.1
Standardserver:  one.one.one.one
Address:  1.1.1.1

> s133.rapidgator.net
Server:  one.one.one.one
Address:  1.1.1.1

Nicht autorisierende Antwort:
Name:    s133.rapidgator.net
Address:  188.130.223.26

 

Die Route natürlich eine andere:

Zitat

Routenverfolgung zu s133.rapidgator.net [188.130.223.26]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1 <-- lokaler Rechner
  2    15 ms    15 ms    15 ms  10.5.0.1 <-- Tunnelende Wireguard
  3    15 ms    13 ms    13 ms  212.103.61.252 <-- NordVPN Server
  4    13 ms    13 ms    15 ms  vl201.vie-itx1-core-1.cdn77.com [185.156.45.132] <-- Datacamp Limited, CDN
  5    13 ms    14 ms    14 ms  ae14-415.vie10.core-backbone.com [81.95.9.66] <-- Core-backbone GmbH, Germany
  6    31 ms    30 ms    34 ms  ae5-2074.ams10.core-backbone.com [81.95.2.138] <-- Core-backbone GmbH, Holland
  7    37 ms    31 ms    31 ms  5.56.17.82 <-- Core-backbone GmbH, Holland
  8    36 ms    33 ms    32 ms  connected-by.global-layer.com [37.123.210.20] <-- Global Layer B.V., Holland
  9    34 ms    32 ms    32 ms  connected-by.global-layer.com [37.123.210.35] <-- Global Layer B.V., Holland
 10    31 ms    32 ms    32 ms  188.130.223.26 <-- Ultranex LTD (rapidgator.net), Holland 

Ablaufverfolgung beendet.

 

Fazit:

Sieht man sich beide Routen an, so ist bei der "lahmen" Magentaroute bis zum 9. Hop alles noch Magenta/exUPC/exChello. 

Danach kommen nur noch die 2 Hopser vom Provider des Zielservers bei rapidgator - die s133-Trommel steht offenbar bei Global Layer in Holland.

Da diese letzten 3 IPs sogar identisch sind mit der "VPN Route" kann man die wohl als Verursacher ausschließen.

Was bleibt, liegt komplett im Einflussbereich von Magenta.

 

 

 

 

 

Bearbeitet März 18 von hoferanda

[hoferanda]

lol das ist ja nett!

 

Da macht man sich einen Aufwand für den nüchternen Nachweis dass die Drosselung im Einflussbereich von Magenta erfolgt, postet das Ding hier und was passiert? Der Artikel verschwindet kommentarlos. 🙂

 

Auf der Hotline wird einem nicht geholfen, versprochene Rückrufe erfolgen nie und am Forum wird zensiert.

 

Vielen Dank Magenta, vielen Dank Forenmoderation!

 

[traffic-opfer]

https://pastebin.com/xpzCfmaM

 

Es befindet sich noch im Quelltext des Forums

Bearbeitet März 24 von traffic-opfer

[Georgie]

Hallo @hoferanda, dein Posting ist nach wie vor da. Leider erfolgt die Reihung der Postings seit dem Community-Update nicht mehr chronologisch nach Datum, sondern nach "Wertigkeit". Da dein Artikel als "Hilfreich" bewertet worden ist, findest du ihn jetzt nach Start des Forums auf Seite 1 dieses 4-seitigen Threads. Erst wenn man auf "Nach Datum sortieren geht", sind die Postings wieder in chronologischer Reihenfolge. Sorry für die Verwirrung.

 

 

[hoferanda]

Bemerkenswert - ihr verschiebt also Beiträge im Thread, zerstört damit die Querverweise und reißt sie zudem aus dem Kontext?

Ihr solltet wirklich bei der Telefonie bleiben...

PS: das Problem besteht noch, verbleibt offenbar unbearbeitet.

[Georgie]

Hast du meinen Kommentar nicht gelesen? Wo steht da, dass wir deinen Beitrag verschoben hätten? Die Software reiht automatisch Beiträge, die als hilfreich bewertet werden, nach vorne. Diese Software stammt übrigens nicht von Magenta, ist also extern. Ich stehe bereits mit dem Entwickler in Kontakt, um dieses "Feature" wieder rückgängig zu machen.

Bearbeitet März 26 von Georgie
Denkfehler beim Tippen ;)

[WulleWulle]

Wie wäre es mit einer Drosselung seitens Content Provider (z.B. EDGECAST) der die Downloads oder Routen anbietet. Vielleicht wurde das ganze Magenta IP Netz wegen DDoS bei den Content Providern getriggert, und somit wird der Traffic einfach von den Providern klein gehalten, zur DDoS Prevention. Das würde das Verhalten des schnellen Starts, und des weiterem Verlangsamen des Downloads erklären.

 

Ich empfehle dazu folgenden Artikel: https://de.wikipedia.org/wiki/Content_Delivery_Network um sich mit diesem Thema tiefer zu beschäftigen.

 

Auch sehen wir das dort ein Drosseln stattfindet denn, wenn ich 5x den Download am selben Computer starte, bekomme ich immer so um die 100kbit pro Download.

 

Da müsste Magenta mal bei den NOC der Content Provider nachhaken, ob die gesperrt sind. Via Telefon und E-Mail am first LVL Support hat man dafür aber kein Ohr...

[hoferanda]

Am 26.3.2024 um 16:32 schrieb WulleWulle:

Wie wäre es mit einer Drosselung seitens Content Provider (z.B. EDGECAST) der die Downloads oder Routen anbietet. Vielleicht wurde das ganze Magenta IP Netz wegen DDoS bei den Content Providern getriggert, und somit wird der Traffic einfach von den Providern klein gehalten, zur DDoS Prevention. Das würde das Verhalten des schnellen Starts, und des weiterem Verlangsamen des Downloads erklären.

 

Guter Gedanke!

Aber wie du im verschobenen, verlinkten Post siehst ist hier bei der lahmen Route kein CDN am Start - die Downloads werden direkt vom Host von rapidshare geladen. Da gibt es wohl eine floating IP wegen der Lastverteilung aber das wars auch schon.

 

(Einen potentiellen 302er siehst im traceroute natürlich nicht - aber während des Downloads hab ich sniffer und torch laufen lassen um sicher zu sein, dass die Downloadpakete auch vom Zielserver kommen. Und Flaschenhälse wie Reverseproxies werden die wohl nicht einsetzen.)

 

Auch wenn du die Routen vergleichst:

- Lahme Route ohne VPN: Magenta/UPC/Chello und dann 

 2 Hops mit dem Provider von Rapidshare "Global Layer"  und der Zielhost

- schnelle Route mit VPN: NordVPN Route und dann DIESELBEN 3 Hops am Ende

 

Daraus leite ich ab: es liegt NICHT am Zielhost oder dessen Provider. Nachweislich gehts mit denen ja schnell - und alles was dann bleibt ist die Strecke innerhalb des Magenta Einflusses, wo ausgebremst wird.

 

Und ja - die CDN Geschichte ist spannend und sollte von Magenta trotzdem untersucht werden!

PS: Beim Zielhost habe ich nachgefragt: sie melden keine Störungen und sie drosseln nicht.

 

Bearbeitet März 28 von hoferanda

[hoferanda]

Update: "aktuell" gehts wieder schneller