Speicher: Achillesverse von IPv6 – Infrastruktur

Kommentieren Drucken
Teil 1 von 3 aus der Serie "Speicher: Achillesverse von IPv6"

Am Dienstag,12.08.14, 7:50h UTC wäre uns beinahe das Internet um die Ohren geflogen und zwar mit Version 4 seines Protokolls. Warum? Zu wenig Speicher! (Wer die ganze Geschichte lesen möchte, kann das Bei BGPMON tun: „What caused today’s Internet hiccup“) Die Kurzform: für einige Router großer Internetknoten gab es einige Minuten lang ca. 3.000 IPv4 Routen mehr, als sie speichern konnten. Man stelle sich mal vor, das wäre mit IPv6 passiert. Dann wären es nicht ein paar tausend sondern potentiell einige Milliarden Routen zu viel. Aber nicht nur im ganz Großen ist Speicher ein IP-Problem, bei Version 6 wird es auch in ganz Kleinem eines: bei Sensoren beispielsweise. Dieser erste Artikel beleuchtet einige Aspekte im Netzwerkumfeld rund um Speicher und IPv6 und wo die Probleme liegen (können).

Im ganz Großen, das Internet

Betrachten wir zunächst einmal den „Vorfall“ vom Dienstag, den 12. August 2014. Ein Provider, namentlich Verizon, hat beim BGP-Peering Mist gebaut: statt seiner aggregierten Routen wurden die internen, kleineren Subnetze an andere Provider übermittelt (bspw. statt eine Route für 72.69.0.0/16 wurden 170 Teilnetze mit /24-Masken propagiert). Auf diese Weise wurden von Verizon zeitweise rund 15.000 Routen mehr propagiert als sonst.

Zunächst einmal ist sowas „nur“ ärgerlich und nicht kritisch. Ständig fallen Routen im Internet weg und andere kommen hinzu. Router, insbesondere große, teure Kisten, die in Internetknoten so rumstehen, stecken das locker weg. Vorausgesetzt, die Gesamtzahl aller IPv4 Routen steigt nicht über die magische Grenze von 512.000 Einträgen. Genau das ist aber passiert. Kurzfristig waren es bei einigen Providern ca. 515.000 Routen, die gespeichert werden sollten aber nicht konnten, weil kein ausreichender Platz zur Verfügung stand. Das liegt daran, dass die Router mit durchschnittlich 500.000 BGP-Routen ohnehin schon nahe an ihrem 512.000er Limit agieren.

Und was passiert, wenn die Nachfrage das Angebot überschreitet? Das kann niemand vorhersagen, weil es diesen Fall gar nicht geben sollte. Einige der Systeme werden alte Routen durch neue überschreiben, andere werden die neuen nicht mehr aufnehmen. Erschwerend kommt hinzu, dass es durchaus eine Vielzahl (Mehrzahl?) von Routern gibt, die mit mehr Routen klar kommen. Und da sich alle Router unterhalten, ist das Chaos perfekt. So lange, bis der Verursacher aufhört, die überflüssigen Routen zu propagieren. Das hat Verizon auch nach wenigen Minuten getan. Trotzdem kam es für einige Zeit zu Störungen im weltweiten Internet. Welcher Provider wie arg betroffen war, hing von vielen Faktoren ab: welche Router er selbst im Einsatz hat, an welchen Knotenpunkten er angeschlossen ist und nicht zuletzt, wo er auf der Welt eigentlich agiert, also wie nah am Verursacher er dran ist.

Die Kernfrage ist jedoch: woher stammt diese merkwürdige Grenze von 512.000 Einträgen (gerne als 512k abgekürzt, was in Foren immer wieder zu Verwirrung führt, da User es als 512kb lesen). Ein Blick in die Default-Werte eines großen Herstellers von solchen Routern verschafft Aufklärung

(http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html).

Als Workaround wird nun vorgeschlagen die Anzahl der IPv4 Routen zu erhöhen. Möglich ist bei den angegebenen Geräten ein Maximum von 1.000.000 IPv4 Routen. Nun muss man aber wissen, dass das TCAM, Ternary Content Addressable Memory, sowohl die IPv4- als auch die IPv6- und IP-Multicast-Routen speichert. Per default sind es 512k IPv4 Routen und 256k IPv6- und IP Multicast-Routen. Die TCAM ist jener magische Ort, an dem Router ihre Routingtabelle in der Form ablegen, in der sie sie für die schnelle Paketweiterleitung benötigen. Dieser Speicher ist nicht erweiterbar und auch nicht mit einem 4 GByte Riegel vom Mediamarkt zu vergleichen. Aufrüsten lässt er sich nicht.

Daraus folgt: erhöht man die Anzahl der möglichen IPv4 Routen, verringert man zugleich die Anzahl der IPv6 Routen. Da IPv6 Adressen zudem länger sind als IPv4 ist es keine 1:1 Beziehung sondern eine 2:1, zwei IPv4 Routen nehmen genauso viel Platz ein wie eine IPv6. Da immer mehr Provider IPv6 einführen, kann man diesen Workaround also nicht so kritiklos übernehmen, sondern muss schon sehr genau wissen, was man da tut, sprich wie viele Routen man hat und wie viele man in den nächsten Wochen und Monaten erwartet.

Das wiederum bedeutet, dass diese Internetrouter, die ohnehin schon aus dem letzten Loch pfeifen, durch die Zunahme von IPv6 bei Providern nicht nur an, sondern über ihre Leistungsgrenzen hinaus getrieben werden. Man beachte dabei, dass BGP das weltweite Routing regelt, es reicht also nicht aus, die Router im DE-CIX aufzurüsten. Vielmehr müssen alle Router in allen Internetknoten der kommenden Routen-Flut gewachsen sein. Denn ist ein Knoten instabil sind es alle.

Was dieses Beispiel auch zeigt, ist die zwingende Notwendigkeit zur Routeaggregierung. 500.000 Einträge wären nicht notwendig, wann man bspw. Kontinente zu einer oder einigen wenigen Routen zusammenfassen könnte. Bei IPv4 hat man diese Chance verpasst. Bei IPv6 bleibt zu hoffen, dass es gelingt. Denn wenn nicht, dann reden wir nicht über 500.000 Einträge, sondern potentiell über Milliarden und Quadrillionen … kein Scherz, rechnen Sie mal nach.

Im Unternehmen
Nun ja, welches Unternehmen hat schon 512.000 Routingeinträge und mehr? Also können wir uns beruhigt zurücklehnen und sagen, das ist das Problem der Provider? – Weit gefehlt!

  1. Die Provider haben größere Router
    Das Providerproblem ist zugleich auch das Unternehmensproblem: nicht die neuen, großen Router haben ein Speicherproblem, es sind die älteren Modelle. In Unternehmen gilt das genauso: nicht die Core-Switches werden den Speichertod sterben, sondern die alten, fast vergessenen Router, die irgendwo im Regal vor sich hin stauben. Doch wenn die plötzlich ihre Routing-Tabelle nicht mehr speichern können, werden dank OSPF und Co auch die Core-Router aus den Neuberechnungen der Routing-Tabellen nicht mehr rauskommen.

    Dafür braucht man übrigens kein IPv6 dazu nehmen. Ich erinnere mich noch gut an einen Kunden, der das geschafft hat, indem er von einer Stern- auf eine vermaschte Architektur im WAN umgestellt hat. Plötzlich lernten alle Standorte die Netze der anderen Standorte kennen, statt einer default-Route zum Rechenzentrum. Gestorben sind nicht die Core-Router im RZ, sondern die VPN-Router in den Standorten.

  2. Weltweit tätige Unternehmen
    Oftmals herrscht der Wunsch bei Unternehmen mit einem (möglichst großen) IPv6-Präfix ein weltweites Design für das eigene Unternehmen zu gestalten. Als Argument wird dabei gerne angeführt, dass der Standort in Deutschland gleichzeitig die Backup-Internetverbindung für Australien ist. Fällt Downunder die Internet-Verbindung weg, will man den Breakout in Deutschland nutzen, den man über seine festen WAN-Strecken (womöglich) noch erreichen kann. Das setzt aber voraus, dass dieselben Netze sowohl vom australischen Provider als auch vom Deutschen im Internet propagiert werden.

    Genau diese Ideen sind es, die dazu führen, dass Route Aggregierung nicht funktioniert und wir ganz schnell wieder einen Haufen /64 Netze auf den Internetroutern zu sehen bekommen. Kurz gesagt, die Idee ist Mist – höflich formuliert. Australische Netze haben im EMEA Raum, also der RIPE-Region genauso wenig zu suchen wie umgekehrt.

    Aus meiner Sicht spricht auch nichts dafür, ein solches Design-Konzept umzusetzen und das angeführte Argument ist nicht stichhaltig.

    • Innerhalb seines eigenen Netzes kann man problemlos mit Präfixen aus allen RIR-Regionen routen und arbeiten.
    • Wenn Australier den deutschen Internet-Breakout benötigen, kann das über entsprechende Proxys laufen. Dort würde die australische in eine deutsche IPv6 Adresse geändert. Und nein, das ist kein NAT, ich rede von Proxys.
  3. Mobile Internet-Netze
    Anders als die in 2. geschilderten Unternehmenswünsche, sind mobile, ans Internet angeschlossene Geräte schon weit eher ein Problem. Damit sind nicht Tablets oder Smartphones gemeint: die bekommen vom jeweiligen Provider ein Prefix, das in die Region gehört, in der sie sich gerade befinden. Gemeint sind größere „Dinge“, eben solche, die nicht eine IP Adresse haben, sondern viele. Womöglich sogar IP Adressen unterverteilen, beispielsweise Schiffe. Denken Sie an ein Kreuzfahrtschiff. Hier sind nicht nur die internen Systeme zunehmend über IP vernetzt, sondern auch den Urlaubern werden IP Adressen per WLAN angeboten. Die Schiffe wechseln aber durchaus auf ihren Touren die Internet-Regionen. Dasselbe gilt natürlich auch für Flugzeuge, Autos, Busse etc.
    BTW: zu welcher Internet Region gehört eigentlich die ISS?

Fazit
Wer IPv6 einführt, sollte sich unbedingt mal die Speicher sämtlicher seiner Router anschauen, ob diese wirklich der Doppelbelastung standhalten. Im Zweifelsfall sollte man lieber ein Gerät zu viel als zu wenig austauschen. Denn ein Fehler im Routing kann schnell das gesamte Unternehmen lahm legen.

Teil 2: Speicher: Achillesverse von IPv6 – Microsysteme »


zugeordnete Kategorien: IP und IPv6, LAN
zugeordnete Tags: , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.