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, 2024 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, 2024 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, 2024 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, 2024 von hoferanda

[hoferanda]

Update: "aktuell" gehts wieder schneller

 

[Heinous]

Wichtige Informationen zur aktuellen Infrastruktur-Situation

 

Sehr geehrte/r DDownload-Nutzer/in,

 

Wir möchten Sie über die aktuelle Situation informieren und uns aufrichtig für die entstandenen Unannehmlichkeiten, insbesondere im Hinblick auf die Geschwindigkeit, entschuldigen. Transparenz ist uns sehr wichtig, und wir hoffen, dass Sie sich einen Moment Zeit nehmen, um diese Mitteilung zu lesen.

 

Seit einigen Monaten planen wir, unsere alte Infrastruktur komplett auf eine neue, leistungsfähigere Plattform umzustellen. Dass dies ohne Komplikationen ablaufen würde, war leider nicht zu erwarten. Der Hauptgrund für diesen Wechsel liegt darin, dass Nutzer der Deutschen Telekom AG und andere Kunden häufig unter niedrigen Geschwindigkeiten litten, da uns Peeringverträge fehlten. Mit der neuen Infrastruktur möchten wir dieses Problem lösen und haben diesen Schritt mutig in Angriff genommen.

 

Aktueller Stand:

 

Abschaltung der alten Infrastruktur:

Die meisten Server der alten Infrastruktur wurden bereits gekündigt. Wir haben eine Frist akzeptiert, bevor die alte Infrastruktur vollständig abgeschaltet wird.

 

Datenmigration:

Rund 80 % der Daten wurden erfolgreich auf die neue Infrastruktur übertragen. Die restlichen 20 % verbleiben derzeit noch auf der alten Infrastruktur.

 

Probleme bei der neuen Infrastruktur:

Leider mussten wir feststellen, dass die neuen Server falsch konfiguriert wurden, was zu einer enormen Belastung der Festplatten führte. Durch fehlerhafte Prozesse – ständiges Schreiben, Abrufen und Löschen von Daten – konnten die Festplatten die erforderlichen Geschwindigkeiten nicht mehr leisten.

 

Unsere Maßnahmen:

 

Aktuell arbeiten wir daran, die Server neu zu konfigurieren. Dies gestaltet sich besonders herausfordernd, da ein Großteil der Daten bereits auf der neuen Infrastruktur liegt. Um die Server korrekt neu einrichten und optimieren zu können, müssen diese Daten zunächst wieder auf andere Server umgezogen werden. Erst danach können wir die fehlerhaften Server vollständig entlasten und so optimieren, dass sie die erforderlichen Geschwindigkeiten gewährleisten.

 

Die Geschwindigkeitsprobleme resultieren also nicht aus Bandbreiten- oder Infrastrukturengpässen, sondern aus einem menschlichen Fehler bei der Konfiguration. Wir verstehen, dass dies für Sie als Nutzer eine unangenehme Situation ist, insbesondere während der Feiertage, und entschuldigen uns aufrichtig dafür.

 

Was bedeutet das für Sie?:

 

Wir möchten Ihnen diese Informationen bereitstellen, um Transparenz zu zeigen und unser Engagement zu verdeutlichen. Sobald die Umstellung vollständig abgeschlossen ist, planen wir, unseren betroffenen Kunden eine Entschädigung anzubieten – kostenlos und in Form einer Gutschrift. Hierzu erhalten Sie zu gegebener Zeit eine separate Rundmail.

 

Unser Dank:

 

Wir danken Ihnen aufrichtig für Ihre Geduld und Ihr Verständnis während dieser herausfordernden Zeit. Wir hoffen, Ihnen mit dieser Nachricht einen Einblick in die aktuelle Situation gegeben zu haben.