CH Internet Szene

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!

von Fredy Künzler

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

In this tactic, an ISP sells very low cost transit access to the entire peering population at an exchange point. This approach is similar to peering at the exchange point without the overhead of buying and deploying additional hardware, and without establishing and maintaining many relationships at an exchange point.

Peering Taktik #7 von William B. Norton ist eigentlich kein Peering, sondern ein Service, den einige Carrier anbieten: Partial Transit, auch bekannt als "Peering Transit" oder "Euro Transit". Statt der globalen Routingtabelle (Fullfeed) mit ca. 195'000 Routen verkauft ein Carrier nur jene Routen, die für ihn günstig sind, also seine Peers und Downstreams. Das sind üblicherweise zwischen 50'000 und 90'000 Routen. TeliaSonera und Interoute haben ein solches Angebot, und auch wir verkaufen Peering Transit, also unsere an internationalen Internet Exchanges gelernte Routen. Kommerziell kann es durchaus Sinn machen, Peering Transit zu einem günstigeren Preis einzukaufen, allerdings haben sich die Preise von Global Transit und Partial Transit in letzter Zeit ziemlich nivelliert.

Eine ähnliche Variante ist das sogenannte "Swiss Peering Transit", das Sunrise vor einiger Zeit mal im Angebot hatte oder immer noch hat (wir übrigens auch). Der Schweizer Teil des Internets mag zwar klein sein, kann aber doch einen signifikannten Teil des Volumens ausmachen. Anders gesagt: Die Zahl der Prefixe ist selten proportional mit dem Trafficaufkommen. Beispiel: drei oder vier Bluewin-Prefixe machen wohl über 80% des Traffics aus vom IP-Plus (Swisscom) Backbone, der uns im Moment 268 Prefixe liefert.