Montag, 20. April 2020, 19:03 Uhr

upc kappt Peering mit Init7 / Fiber7

Ich habe vor einigen Jahren mit OpenVPN ein Site-to-Site VPN zu einem Bekannten in der Agglomeration Bern aufgebaut und betreibe dieses VPN bis heute.

Der Bekannte ist Kunde von upc cablecom (der schnellste und preiswerteste Anbieter in der Agglomerationsgemeinde) mit einem 300 MBit/s Download-Abo, ich als Städter bekanntermassen Kunde von Fiber7 mit (theoretisch) symmetrischen 1 GBit/s.

Letzte Woche (KW16 2020) waren SSH-Verbindungen zu einem Server beim Bekannten auf einmal sehr, sehr hakelig — die Latenz zwischen Tastatureingabe und erscheinen des Zeichens auf dem Bildschirm war sehr hoch. Bestätigt wurde diese durch meine Überwachung der Geschwindigkeit mit speedtest-cli und Aufzeichnung und Visualisierung der Werte mit Cacti:

Der Einbruch am Dienstag-Morgen war offensichtlich.

Eine fiebrige, verbissene Suche begann: War ein Angreifer in das Netzwerk eingedrungen und zog nun Gigabyte-weise an Daten ab? Oder war ein Rechner eines Mitbenutzers von Malware gekapert worden? Oder führte der Mitbenutzer einfach nur tonnenweise Bittorrent-Downloads durch? Oder war eine Netzwerkkomponente ausgetickt und flutete das Netzwerk und den Router mit Paketen? Oder hatte upc cablecom einfach etwas am Netzwerk geschraubt, worauf der Geschwindigkeitseinbruch manchmal nur mit einem Neustart des Modems behoben werden konnte?

Die Nachforschungen brachten nichts zu Tage, aber immerhin lernte ich folgende Netzwerkanalyse-Tools/Features meiner Infrastruktur kennen:

  • Traffic Analysis des EdgeRouters X ER-X, welcher am Kabelmodem hängt
  • iftop Zeigt in Echtzeit an, von und zu welchen IPs ein Server Daten übertragt (Homepage)
  • iptraf-ng (Homepage)

Am Dienstag-Abend ereilte mich ein Geistesblitz: speedtest-cli misst die Geschwindigkeit von einem Server am Agglomerations-Standort zum Ookla Speedtest-Server von Init7 (Server „Init 7 (Winterthur, Switzerland)“ mit ID 3026). Aus Interesse wählte ich einen anderen Server aus der Liste aus, und zwar den Speedtest-Server von Sunrise. Zuerst führte ich einen manuellen Speedtest zu Init7 durch, danach zu Sunrise. Und siehe da, hier lag die Antwort wie auf dem Präsentierteller:

$ ./speedtest-cli --server 28045
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Sunrise Communication AG (Lausanne) [6X.XX km]: 30.667 ms
Testing download speed........................................
Download: 302.88 Mbit/s
Testing upload speed..................................................
Upload: 42.32 Mbit/s

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Init 7 (Winterthur) [13X.XX km]: 165.956 ms
Testing download speed........................................
Download: 25.82 Mbit/s
Testing upload speed..................................................
Upload: 9.48 Mbit/s

Am selben Abend sendete ich eine Anfrage an Init7 raus, ob und wie sie sich diesen markanten Geschwindigkeits-Unterschied erklären können. Am Morgen hatte ich die Antwort, und wurde auf folgendes Schreiben verwiesen. Diese Meldung war bei mir im Corona-Trubel vollkommen untergegangen.

Fazit: upc cablecom, how dare you?

Nachtrag

smokeping visualisiert die Latenz von DNS-Abfragen aus dem upc cablecom-Netz gegen den DNS-Server von Init7 ebenfalls sehr schön:

Auf Wunsch Thomas‘ (siehe Kommentar unten) noch dieselbe Grafik für Test-Abfragen an einen der DNS-Server der upc cablecom (ns10.cablecom.net) …

… zu Swisscom (dns2.bluewin.ch) …

… und zu Sunrise (cache02.sunrise.ch)

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT, Schweiz

7 Kommentare Kommentare

Thomas sagt:

Daher ist die Regel Nr. 1 bei Speedtests: Immer den Server des eigenen Provider nutzen. Sonst testet man zu viele mögliche Fehlerquellen mit.

Mario Aeby sagt:

upc cablecom betreibt leider keinen eigenen Ookla Speedtest-Server :-(

Ste sagt:

Bei Interesse noch ein paar Fakten:
– Es macht es in gewissen Situationen Sinn einen Link zu shutten um quick and dirty Traffic umzurouten. Packetloss ist fast immer schlimmer für die Performance als eine höhere Latenz.
– Die Behauptung, dass Init7 die Peering Requirements von UPC erfüllt ist falsch.
– Selbst wenn dem so wäre, UPC ist absolut im Recht und kann ohne Grund jedem ISP ein Peering verweigern. Init7 als privatwirtschaftlicher Player hat kein Anrecht auf irgendwas.
– Die beste Möglichkeit für Init7 wäre den Traffic via Telia zu routen. Das können und dürfen sie.
– Telia peert mit UPC in ZH, Init7 bezieht Transit von Telia in, genau, ZH. Latenz = no prob.
– Der Traffic weicht via USA aus weil Init7 selbst via BGP Community verhindert, dass der Traffic in ZH von Telia an Init7 übergeben wird. Sie weisen Telia explizit an die Routes nicht an UPC zu übergeben und sind damit selbst für die Situation verantwortlich.Fazit: Fredy versucht wie so oft einen öffentlichen Shitstorm zu generieren um UPC dazu zu bringen ihm ein PNI zu „schenken“.Klar ist das Verhalten von UPC auch nicht wirklich gut, aber in einem kommerzialisierten Internet durchaus legitim. Freier Markt und so.Was Fredy hier macht ist aber imho noch tieferes Niveau.
Anstatt den Traffic umzurouten und seinen Kunden einen guten Service zu bieten versucht er die Situation zu instrumentalisieren.
Fredy selbst bringt jeweils das Argument ein ISP dürfe nicht auf Seite Kunde sowie Content Provider abkassieren. Dann kann ich hier auch von Init7 erwarten dass sie meinen Umsatz verwenden um mir die Leistung zu geben für die ich bezahle. Anstatt mit Absicht den Durchsatz zu limitieren um einen finanziellen Vorteil zu erwirtschaften.
Das ist nämlich genau was er Swisscom, DTAG, UPC, usw sonst immer vorwirft ;)

Thomas sagt:

Okay. Stimmt, den haben nur ein paar UPC Töchter im Ostblock am laufen… UPC Schweiz nutzt den CNLAB Speedtest. Ich weiss nicht, ob da irgendwo ein File rumliegt, das man mit wget herunterladen könnte zum messen.

Die DNS Abfrage könnte man aber gegen den UPC DNS Server machen.

Thomas sagt:

Nachtrag: Man könnte auch mehrere Tests/Graphs machen. Zu Init7 und den beiden „grossen“ Swisscom und Sunrise.

Mario Aeby sagt:

Muss mich mal umschauen, ob es auch so ein Script für Speedtests mit CNLAB gibt!

Die Latenzen für DNS-Abfragen zeichne ich an jedem Standort seit jeher für alle grossen Schweizer ISPs und den Platzhirschen (Cloudflare und Google) auf. Ich habe diese zu Anschauungszwecken nachträglich zum Post hinzugefügt.

Stephen sagt:

@Ste: Interessant! Danke für den Einblick. Ohne mehr Hintergrundwissen hätte man sich jetzt vollständig auf die Seite von Init7 gestellt.
So ganz unschuldig sind sie für den aktuell schlechteren Service also nicht.
Aber wenn ein grosser Provider derart arrogant auftritt und du nachgibst, kommst du auch nicht zur Gerechtigkeit. Leider.

Kommentar erfassen