CH Internet Szene

von Fredy Künzler

Dass mit der Netzneutralität nicht zu spassen ist, habe ich hier schon früher notiert. Scheinbar gibt es immer mal wieder unbelehrbare Provider, die trotz besseren Wissens die Netzneutralität zu ritzen versuchen. Doch Userproteste nützen durchaus, wie der Fall von UPC Holland - einer Cablecom-Schwesterfirma - beweist. Der Tages-Anzeiger berichtete in seiner gestrigen Ausgabe ausführlich über den Fall und holt dankenswerterweise bei Cablecom ein Statement ab, dass man im Cablecom-Netz der Schweiz niemals selektiv (unliebsamer) Datentraffic künstlich ausbremsen wolle:

[...] Drei Wochen später ist das Thema [Tempobremsen] vom Tisch. Die offizielle, von der Europazentrale der Cablecom-Besitzer abgesegnete Stellungnahme zur Tempobremse lautet: «Drosselungen sind für die Cablecom kein Thema. Solche Massnahmen entsprechen nicht unserer Politik.»

Womit das Statement hier für die Nachwelt dokumentiert wäre.

Freilich auf einem anderen Blatt Papier geschrieben sind überlastete Peerings und Transitlinks in den Peak-Stunden - bei Privatkunden-Providern à la Cablecom üblicherweise zwischen 19 und 23 Uhr. Latenzmessungen à la nachstehender Grafik (es ist diesmal keine Cablecom-Traffic-Messung ...) sind leider an der Tagesordnung. Damit sparen sich manche Provider kostspielige Upgrades ihrer Transitlinks oder erzwingen eine für die Endkunden miserable Peeringpolicy. Anders gesagt: wo 50 oder 100mbps draufsteht, ist längst nicht überall 50 oder 100mbps drin.



Dass Cablecom früher schon wegen Overbooking gebasht wurde, sei nur am Rande noch erwähnt ...

von Fredy Künzler

Ich habe mich aufs 2. Europäische Peering Forum sehr gefreut, denn Barcelona ist natürlich eine Reise wert, wenn man warmes Wetter statt Winter lieber mag. Die Temperaturen sind zwar nicht mehr ganz Geek-T-Shirt kompatibel, trotzdem ist es ganz nett hier die vielen Leute der Community wieder mal zu treffen ... dass einige die halbe oder auch ganze Nacht durchfeierten, muss ich ja wohl nicht extra erwähnen.

Peinlich für den Veranstaltungsort Gran Marina ist neben der eher lausigen Küche vor allem der WLAN-Internet Zugang. Der funktioniert so ziemlich unter jeder Sau, anders kann man das nicht bezeichnen. Man fühlt sich in die Zeit der Akustikkoppler zurückversetzt ... Packet Loss und Latenz ohne Ende ... mal sehen, ob es gelingt, diesen Blogg-Beitrag zu posten! Auch bei WLAN Netzwerken gibt es gewisse Regeln einzuhalten, und dieses hier wurde definitiv von Dilletanten installiert:

Zeitüberschreitung der Anforderung.
Antwort von 213.144.129.2: Bytes=32 Zeit=756ms TTL=249
Antwort von 213.144.129.2: Bytes=32 Zeit=721ms TTL=249
Antwort von 213.144.129.2: Bytes=32 Zeit=463ms TTL=249
Antwort von 213.144.129.2: Bytes=32 Zeit=149ms TTL=249
Antwort von 213.144.129.2: Bytes=32 Zeit=199ms TTL=249

Ping-Statistik für 213.144.129.2:
Pakete: Gesendet = 1410, Empfangen = 1085, Verloren = 325 (23% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 35ms, Maximum = 3825ms, Mittelwert = 351ms

Vielleicht kann ich später noch einige interessante Slides der Vorträge vom Peering-Forum posten.

von Fredy Künzler

Supergau im Swisscom-Backbone (AS3303) gestern Nachmittag - die Folge: Kein Buffertainment (cooler Name für die Channel-Switch Werbung von Zattoo) mehr für Bluewin-Kunden. Ab ca. 17:00 Uhr ging so ziemlich gar nix mehr - ausser Adrenalin und Stress im Swisscom NOC.

Nein, ich bin nicht schadenfreudig, auch wenn die blogg.ch Leserschaft natürlich weiss, dass ich das Heu nicht auf der gleichen Bühne wie die Branchenkollegen von ip-plus.net habe. Einen solchen Backbone-Gau wünscht man nicht mal dem ärgsten Feind.

Was ist passiert? Das offizielle Swisscom-Troubleticket (PDF Screenshot) spricht von einer DDOS Attacke. Kann sein, ist meiner Meinung nach aber eher unwahrscheinlich, denn das Schadenbild spricht nicht für einen DDOS Angriff. Vielleicht verursachte eine DDOS Attacke respektive die missglückte Abwehrmassnahme das Problem erst. Interessant übrigens, dass Swisscom kein offizielles Statement abgibt ... doch Journalisten fragten selbstverständlich nach.

Meiner Einschätzung nach ist folgendes passiert (und dabei stütze ich mich bloss auf Beobachtungen aus dem Init7-Backbone, öffentliche Looking-Glass wie z.B. jenes von SWITCH sowie die öffentlichen Statistiken von ip-plus.net):

1. Eine Anzahl Routen (vielleicht einige Tausend) von einem Peer wurden fälschlicherweise als Swisscom-Kundenrouten getaggt (falsche Community), aufgrund eines Konfigurationsfehlers.

2. Diese Routen wurden aufgrund der falschen Markierung automatisch an hunderte von Peers mitgeteilt. Viele dieser Peering-Partner haben aus Sicherheitsüberlegungen einen sogenannten max-prefix Threshold konfiguriert (auch Init7). Statt den üblichen ~450 Routen aus dem Swisscom-AS3303 erhielten die Peers plötzlich eine um Faktoren höhere Zahl von Routen mitgeteilt, und der grosse Anstieg veranlasste die Peers, die Session automatisch auf shutdown zu schalten.

3. Durch diese Shutdowns verlor der ip-plus Backbone auf einen Schlag sehr viel von seiner Kapazität (gemäss eigenen Angaben transportiert Swisscom ca. 30 Gbps Traffic und davon 95% des via Peering). Die Folge: Rerouting auf in der Kapazität begrenzte und auch teure Transit-Links. Manche Init7-Kunden beobachten Traceroutes Richtung Swisscom-Backbone via USA oder andere lange internationale Wege. Die Transitlinks von Swisscom hatten im Gegensatz zu Peerings keinen max-Prefix Threshold.

4. Durch das Rerouting waren die Transitlinks auf einen Schlag überlastet und dadurch entstand Packetloss und Latenz ohne Ende. Möglicherweise überliefen auch Routing-Tabellen durch die vielen BGP-Updates auf Routern mit knappem Memory-Ausbau und booteten demzufolge, was noch mehr Instabilität und Rerouting hervorrief. Die Folge: der Backbone fällt wie Dominosteine.

5. Durch diese Kettenreaktion war die Kapazität des Swisscom-Backbones auf einen Schlag auf vielleicht noch 10% reduziert und damit heillos überlastet. Weil Routing derart wackelig war, gestaltete sich die Fehlersuche entsprechend schwierig. Die falsch getaggten Routen mussten eliminiert werden, möglicherweise auf einem ständig neu startenden Router. Eine Sisiphusarbeit.

6. Irgendwann, nach Stunden erst, bekamen die Techniker von Swisscom die Sache in den Griff, die Peers clearten sukzessive die BGP Sessions und der Backbone erlangte die Stabilität langsam zurück.

Wie gesagt, diese Abhandlung ist reine Hypothese, erscheint mir als mögliches Szenario aber einigermassen realistisch. Es beweist, das auch die besten IP-Gurus nur mit Wasser kochen.

Nach solchen Erfahrungen muss sich jeder Kunde mit Mission-Critical Internet-Anwendungen überlegen, ob er sich ausschliesslich auf einen einzigen Serviceprovider verlassen möchte. Die schönsten SLA's und Penalty-Vereinbarungen helfen nämlich nicht gegen die Outage ... auch wenn manche kravattierten Salesleute das Gegenteil behaupten. Deshalb, einmal mehr, zitiere ich gerne die Gartner Group: Get Multihomed!

From - Fri Oct 27 06:21:26 2006
Date: Fri, 27 Oct 2006 06:21:24 +0200
From: Fredy Kuenzler
Organization: Init Seven AG - http://www.init7.net/
To: Rudolf Fischer
Subject: Offener Brief an Cablecom-CEO Rudolf Fischer

Sehr geehrter Herr Fischer,

Gestern sind die Peering Verhandlungen zwischen Cablecom und Init7 gescheitert. Unter "Verhandlungen" verstand ich bisher immer, dass beide Seiten etwas von ihrer Position abrücken und ein Kompromiss geschlossen wird. Ihre Unternehmung ist uns aber keinen Millimeter entgegen gekommen. Und dies, nachdem Cablecom 3x ein Versprechen gegenüber Init7 gebrochen hat, wie ich bereits am 10. Oktober notierte habe.

Ich hatte in diesen Tagen mit Ihren Mitarbeitern Boller, Seiler und Köylüer mehrere Gespräche. Es waren keine netten Telefonate, im Gegenteil. Ihrer Unternehmung bedeutet offenbar Kundenzufriedenheit nichts. Ich möchte Sie daran erinnern, dass wir immerhin ca. CHF 50000 Umsatz jährlich als Wholesaleparter mit Ihrer Unternehmung machen. Im Moment bin ich auf Kundenzufriedenheit besonders sensibilisiert, weil einige unserer Lieferanten gerade entsprechende Umfragen durchführen. Von Cablecom habe ich diesbezüglich nichts gehört, nach einem Grund dafür zu suchen erübrigt sich wohl.

Ich gebe zu, dass mein Tonfall gelegentlich zur Emotionalität neigt, insbesondere dann, wenn ich oder andere ungerecht behandelt werden. Ich entschuldige mich hiermit, wenn ich nicht immer sachlich blieb.

Unser Anliegen ist, unseren IP Transit Kunden schnelle und qualitativ hochwertige Konnektivität zu einem fairen Preis zu bieten. Dafür arbeiten wir jeden Tag mit viel Herzblut. Durch ihr De-Peering des Init7 Backbone wurde unsere Bemühung empfindlich gestört. Nun möchte Ihre Unternehmung Geld für die Weiterführung des Peerings. Warum bloss? Das bisschen Geld, das Cablecom durch die neuen Paid Peerings verdient, ist derart lächerlich im Vergleich zum Imageschaden und dem Verlust an Kundenverträgen, dass ich mich ernsthaft frage, was die Verantwortlichen bei UPC und Cablecom studieren. Infoweek hat recherchiert: Ein einziger ISP hat mit ihnen einen Paid Peering Vertrag abgeschlossen. Revenue: CHF 8160.00 pro Jahr. Zu lesen in der Ausgabe vom nächsten Montag.

In der heutigen NZZ wird unser gemeinsames Issue thematisiert. Und auf dem Sunflyer-Blog von Infoweek Redaktor Andreas Ahlensdorf liest man noch mehr Interna. Gemäss diesen Informationen kriegt UPC nämlich den dringend notwendigen Ausbau des Cablecom Backbones nicht vor Ende Jahr zum laufen. Bei UPC arbeiten scheinbar nur Dilletanten in der Kapaziätsplanung. Wenn 12 Personen in einem Bus mit 8 Sitzen mitfahren wollen, dann merkt jedes Kind, dass 4 laufen müssen. Ersetzen Sie jetzt Personen durch Gigabit pro Sekunde. Diese Zahl dürfte etwa der Realität des Cablecom Backbones entsprechen.

Wie man sieht, hat Cablecom ein substanzielles Problem. Denn jeder normale Hispeed Kunde merkt inzwischen, dass es mit der Qualität des Cablecom Backbones nicht mehr weit her ist. Ihre Pressestelle gibt das inzwischen auch unumwunden zu.

Doch ihr Problem ist hausgemacht, Herr Fischer. Neben der total überlasteten UPC Datenautobahn gäbe es einige Peering-Umfahrungswege mit viel Kapazität. Man müsste bloss die Ampel wieder auf Grün schalten.

Scheinbar kriegte man bei UPC den Tier-1 Grössenwahn. Im Kündigungsschreiben an die Serviceprovider wird vollmundig behauptet, UPC sei ein "Tier-1 Carrier". Dabei wissen Sie und ich, dass dies nicht der Tatsache entspricht und nur dummes Marketing-Geschwätz ist. Die aktuell gültige Peering Policy von UPC sei "not public", wird mir aus der Zentrale in Holland beschieden. Von ihren Mitarbeitern erfahre ich, dass man etwa "1.5% des gesamten UPC Traffics" verursachen müsse, um ein Zero-Settlemen Peering zu bekommen. In der Peering-Datenbank deklariert UPC das gesamte Volumen mit 50 bis 100 Gigabit pro Sekunde. Man rechne.

Init7 macht "bloss" gut 100 Megabit pro Sekunde Verkehr zu UPC, ist also gemäss Holland eine Quantité négligable. Doch alle anderen de-peerten Serviceprovider zusammen haben wohl ein zwei Gigabit (wie man hört, wolle UPC sogar Swisscom abwürgen). Bitteschön. Das ist die beste Werbung für den Wechsel ihrer Hispeed-Kunden zu ADSL. UPC / Cablecom hat es so gewollt.

Wir werden uns vorsehen, und den Traffic Richtung UPC künftig gemäss der Peering-Taktik #9 routen. So, dass UPC als möchte-gern Tier-1 für unsere 100 Mbps zahlen muss. Ausserdem werden wir uns nach Alternativen für die laufenden Wholesale-Verträge umsehen. Damit entgehen Ihnen weitere CHF 50000 Revenue. UPC / Cablecom hat es so gewollt.

Ich könnte mir aber auch vorstellen, dass Sie sich gar nicht über die Tragweite dieses destruktiven Peering-Entscheides bewusst waren. In diesem Fall lade ich Sie gerne zu einem Mittagessen ein und erkläre die Mechanismen von IP Traffic.

Vermutlich habe ich es mit ihren Leuten Boller, Seiler und Köylüer und womöglich auch mit UPC Holland gründlich verdorben. Damit muss ich und kann ich leben. Init7 ist aber weiterhin bereit, mit UPC / Cablecom im Interesse unserer und ihrer Kunden zu peeren. Allerdings funktionieren wir auch nicht mehr "auf Zuruf", um die Worte ihres Kollegen Boller zu benutzen, obwohl dies jahrelang üblich war. Wir werden für Cablecom nicht das Trostpflaster spielen, um ihre akuten bis Ende Jahr andauernden Kapazitätsprobleme zu entschärfen. Gepeert wird bloss noch, falls Sie mit uns einen Zero-Settlement Vertrag mit mehreren Jahren Laufzeit abschliessen. Damit wäre die Sache für mich erledigt und wir können das "Kriegsbeil" begraben.

Genug der Worte. Ich wende mich lieber unserer Arbeit zu, noch-Cablecom Kunden zu Init7 zu migrieren und interessanten Content bereitzustellen, auf den Hispeed Kunden leider nur mit Latenz und Paketloss zugreifen können. Die Theorie über Peering (Taktik #8) prophezeit, dass bei aggessivem De-Peering der Schuss hintenraus geht. Der Fall UPC / Cablecom bestätigt sie nun.

Da fällt mir grad noch ein, dass ihr Verkäufer nach den gescheiterten Peering Verhandlungen mir allen ernstes IP Transit vom überbuchten UPC Backbone verkaufen wollte. Um bei der Terminologie zu bleiben: Der Autoverkäufer versucht eine verbeulte Rostlaube als Neuwagen zu verscherbeln.

Freundliche Grüsse,

Fredy Künzler
CEO Init Seven AG

von Fredy Künzler

[ Alles über Peering | Vorbemerkungen | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]

Peering Taktik #10 basiert auf der Vorspiegelung falscher Tatsachen. a) Entweder wird behauptet, der Traffic werde in naher Zukunft signifikant anwachsen, oder b) es wird behauptet, die derzeitige Performance sei schlecht und könne durch ein Peering beseitigt werden.

Ich halte beide Taktiken nicht für sonderlich nützlich. Zu a): Bekanntlich wird viel dummes Zeugs geschwatzt und einem das Blaue vom Himmel herunter versprochen. Wer viel Traffic hat, der kann auch peeren. Bei nur wenig Traffic lohnt sich ein Peering je nachdem nicht. Hauptproblem ist der Begriff "viel". Manche Carrier verlangen mehr als 1000 Megabit pro Sekunde, average! (also nicht nach der 95%-Regel). Andere denken schon 5 Mbps seien viel.

Zu b): Schlechte Performance ist längst kein Grund für Peering mehr, sondern wird von manchen Carriern und Providern bewusst in Kauf genommen, wie jüngste Beispiele zeigen. Auch die Deutsche Telekom übt sich derzeit im Armdrücken. Was ich bereits zum Thema Netzneutralität notierte, wurde mir heute von T-Systems (Deutsche Telekom in der Schweiz) bestätigt. Man macht sich dort ernsthaft Gedanken, nur noch bezahlter Content schnell auszuliefern. Ich halte solche Ideen für absolut verwerflich.

Zudem ist in der Branche bestens bekannt, dass die Deutsche Telekom (AS3320) ihre Peerings bewusst vollaufen lässt. Insbesondere jenes mit Preisdrücker Cogent AS174 ist extrem schlecht. Packet Loss von 30% auf den Interkonnektionen zwischen Cogent und der Deutschen Telekom ist derzeit nicht Ausnahme, sondern Regel. Und dies ohne temporäre technische Probleme, sondern im vollen Bewusstsein.

Cogent ihrerseits hat zum Halali auf noch-Transit Kunden der Deutschen Telekom geblasen. Wer eine einigermassen neue Rechnung für AS3320 Feed vorweisen kann, kriegt Transit zum absoluten Dumpingpreis. Gemäss Gerüchten würde man inzwischen sogar Kickback erhalten, wenn man eine signifikante Datenmenge an AS3320 via gewisse Carrier senden sollte. Für die Deutesche Telekom teure Routingwege sind nämlich immer noch vorhanden, wie man leicht in deren Looking Glass nachsehen kann. Werden solche teuren Routen von Content-Anbietern häufiger benutzt, wird es für das Target (in diesem Fall die Deutsche Telekom) teurer - siehe Peering Taktik #9.

Wie lange dieses Armdrücken noch anhält, wird sich zeigen. Wie schon bei der Peering-Taktik #8 beschrieben, verliert üblicherweise der Agressor, indem seine Kunden abwandern. Wäre ich ein normaler T-Online- oder Cablecom-Hispeed Abonnent, hätte ich meine Kündigung schon längst losgeschickt.