Der 768k-Day kommt!

Warum könnten 786.432 IPv4-Routen im Internet den einen oder anderen Router vor die Wand fahren lassen, wo kommen die Routen überhaupt her - und was kann man dagegen unternehmen?

Zu diesem Artikel gibt es ein Update am Ende des Texts. Teile des Textes wurden angepasst.

Was ist eine Fulltable?

„Das Internet” ist bekanntermaßen ein Zusammenschluss vieler kleiner, für sich autonom funktionierender Netze.
Damit diese Netze sich alle gegenseitig erreichen können, müssen sie mit allen anderen verbundenen Netzen ihre IP-Routen austauschen, damit jedes Netz einen Weg kennt um jedes andere Netz erreichen zu können.
Diese Routen werden normalerweise per BGP zwischen den einzelnen Netzen ausgetauscht, dadurch enthält die BGP-Routingtabelle aller so verbundenen Router irgendwann tatsächlich alle Routen zu allen verbundenen Netzen.

Nun gibt es eine steigende Anzahl von Netzbetreibern, zum anderen werden die vorhandenen IPv4-Netze immer stärker fragmentiert. Dadurch gibt es natürlich immer mehr Routen – Stand heute (25.04.2019) sind es 747.408 Routen. Und alleine in Deutschland ist die Anzahl der Routen insgesamt seit Anfang 2018 bis heute (25.04.2019) um knapp 5.000 Routen gestiegen.

Warum sind so viele Routen ein Problem?

Alles was gespeichert wird, belegt Speicher. Ist ja klar.
Wenn per BGP Routen empfangen werden, werden diese normalerweise erstmal in den RAM geladen. Der ist zwar vergleichsweise langsam, dafür hat so ein halbwegs moderner Router reichlich davon - in der Regel irgendwas um 2-4 GB. Da passen dann auch die Routen von mehreren BGP-Upstreams hinein.
Dann geht der Router alle diese Routen durch, errechnet die besten Pfade und schreibt diese errechneten Informationen in das (T)CAM.
Das CAM ist speziell dafür optimiert, die Routinginformationen zu speichern. Darin können superschnell die Informationen abgerufen werden, allerdings ist dieser Platz teuer und auch sehr begrenzt.
Während im RAM problemlos zig Millionen Routinginformationen Platz finden, ist im CAM häufig nur Platz für maximal 1.000.000 Routen - und das ist nur bei den wirklich leistungsfähigen Routern so. Kleine Router, die nicht dafür konzipiert sind irgendwelche Fulltables aufzunehmen, bieten meistens nur Platz für weniger als 2.000 Routen, wenn sie überhaupt ein CAM haben.

Jedenfalls muss dieser Platz sinnvoll genutzt werden, daher haben Cisco (und einige andere Hersteller) eine Zeit lang ihre Router mit der Voreinstellung ausgeliefert:
Ja, wir haben Platz im TCAM für 1.000.000 Routen - aber der wird partitioniert für 512k IPv4-Routen und 256k IPv6-Routen.
Dann kam es am 12. August 2014 zum 512k-Day: Die Routingtabelle überstieg die Anzahl von 512.000 IPv4-Routen und die so partitionierten CAMs konnten keine weiteren Routen mehr aufnehmen.
Was dann passiert hängt maßgeblich von der Firmware des Routers ab. Einige weigern sich dann, weitere Routen aufzunehmen, andere verwenden Software-Forwarding auf der normalen CPU (was gruselig langsam ist), andere haben für dieses Szenario offenbar überhaupt keine Lösung und crashen dann einfach.
Kurz: Es war an dem Tag sehr, sehr ruckelig im gesamten Internet.
Der Grund dafür liegt klar auf der Hand: Wenn der Router eines Providers nicht mehr genug Platz hat um alle Routen aufzunehmen, ist die Routingtabelle nicht vollständig – und dann gibt es keine Konnektivität mehr zu den fehlenden Routen. Und wenn der Router crashed, ist das natürlich auch ein Hindernis.

Cisco hatte 2014 dann eine Anleitung veröffentlicht, wie man erstmal kurzfristig wieder Platz für IPv4-Routen im TCAM schafft, indem man es schlicht umpartitioniert.
In der Anleitung wurde die Partitionierung dahingehend geändert, dass man statt 512k IPv4-Routen nun 768k Routen speichern kann - daher auch die neue „magische” Grenze bei 768k. Und da diese Anleitung nicht nur bei Cisco sondern auch einigen anderen Herstellern (zumindest von der Idee her) funktioniert, wurde damit diese neue Grenze nicht nur auf Cisco-Routern gezogen ;-)
Aber da man Speicher nicht einfach so erschaffen kann, nahm man es von IPv6 und gab es IPv4. Der Speicher für IPv6-Routen wurde dabei von 256k auf 120k Routen reduziert.
Das reicht momentan noch aus (aktuell ca. 88.000 IPv6-Präfixe in der Fulltable) und es wächst auch nicht so stark an wie bei IPv4, deshalb war das tatsächlich eine gute kurzfristige Lösung.
Heute hat man auf diesen Routern allerdings kaum mehr Spielraum das CAM umzupartitionieren, ohne Konnektivität auf einer Adressfamilie zu verlieren...

Es wird von einigen Leuten erwartet, dass innerhalb der nächsten 1-2 Monate die magische 786k-Grenze erreicht ist - was aber vermutlich hauptsächlich auf der Annahme basiert, dass die Anzahl der Routen so steigt wie in den letzten paar Wochen.
Allerdings kommt es immer wieder mal vor, dass ziemlich ruckartig eine große Zahl IPv4-Routen ins Internet gespült wird und es danach erstmal längere Zeit so bleibt. Meistens sind das irgendwelche Provider, die IPv4-Adressen regional anders sortieren und deshalb z.B. ein /18-Präfix nicht als eine einzige Route ins Internet advertisen sondern daraus viele kleine /24-Präfixe bilden. So werden aus einer Route dann 64 Routen.
Von daher gehe ich persönlich eher von einem Zeitrahmen von ca. 4-5 Monaten aus.

Was kann man dagegen machen?

Wie weiter oben erwähnt, werden an sich größere IPv4-Netze zunehmend als viele kleinere Netze (oft tatsächlich /24) per BGP advertised, was die Routingtabelle aufbläst.
Dies geschieht teilweise aufgrund von Vermietung von IPv4-Space in kleinen Häppchen. Da es keine neuen Provider Independet IPv4-Präfixe mehr gibt, suchen sich Unternehmen, die dringend „eigenen” IPv4-Space benötigen, vornehmlich kleinere Provider mit ausreichend Reserven und mieten dort für kleines oder großes Geld IPv4-Netze, die sie dann selbst advertisen können.
Nicht zuletzt werden aber natürlich auch die letzten IPv4-Reserven des RIPE in kleinen /22-Häppchen verteilt. Dadurch erhalten mehr Provider mehr kleine Netze und das führt dann natürlich auch zu mehr advertiseten Routen.
Im Jahr 2015 verteilte das RIPE eine große Anzahl /22-Präfixe aus der letzten Reserve – was dann auch prompt die Anzahl der advertiseten Netze nach oben trieb.

Das Advertisement von vielen kleinen Netzen anstelle eines großen wird aber teilweise auch absichtlich unternommen um sich präventiv besser gegen BGP-Hijacking zu schützen.
Die Idee hinter letzterem ist, dass ein potentieller Angreifer eine /24-Route nur schwer ersetzen kann – denn diese Präfixlänge ist im großen und ganzen die kleinste Einheit, die sich per BGP weltweit announcen lässt, längere Präfixe werden üblicherweise gefiltert.
Ohne die Möglichkeit, eine noch spezifischere Route zu platzieren, müsste der Angreifer eine bessere Route (kürzerer AS-Path z.B.) platzieren, was aufwendiger ist und eher nur regional begrenzt Auswirkungen hat.

Ein Beispiel dafür liefert möglicherweise momentan AS34788, welches ein komplettes /19-Präfix als einzelne /24-Präfixe advertised. Diese haben aus Sicht der Telekom alle einen identischen Next-Hop und könnten damit theoretisch wieder auf ein /19 aggregiert werden, ohne das Routing zu beeinflussen.
Ob Schutz vor BGP-Hijacking wirklich die Motivation dahinter ist, kann ich natürlich nur vage vermuten – es macht auf mich jedenfalls den Eindruck ;-)

Screenshot aus dem Looking-Glass der Telekom, in der eine große Anzahl /24-Präfixe zu sehen ist, die alle vom selben AS advertised werden und zu einem größeren Netz gehören

In solchen Fällen hilft es, die empfangenen Routen zu aggregieren. Dabei werden dann einfach alle Routen, die sich zusammenfassen lassen (z.B. mehrere direkt benachbarte /24-Präfixe) und die den selben Next-Hop haben, zu einer größeren Route zusammengefasst.
Daraus ergibt sich auch kein Nachteil, denn da der Next-Hop identisch ist fließen die Pakete mit Less-Specific Route ebenfalls da lang, wo sie auch mit den vielen More-Specifics her geflossen wären. Damit lässt sich die Routingtabelle tatsächlich beachtlich zusammendampfen!

Update vom 26.04.2019

Emile Aben vom RIPE NCC weist darauf hin, dass die Grenze von 768k (wenn man mit 1k = 1000) rechnet, schon einige Male überschritten wurde.
Vielmehr ist wohl 1k = 1024 gemeint, womit die tatsächlich „gefährliche” Grenze bei 786.432 Routen liegt.
Die Zahl von 768.000 Routen wurde im Text entsprechend korrigiert!

Profilbild Max Grobecker

Fragen? Anregungen? Kritik?

In Ermangelung einer öffentlichen Kommentierfunktion nehme ich Kritik, Fragen oder Anregungen gerne per E-Mail entgegen: feedback+the-daily@maxderdepp.de :-)

Zur Übersicht | Impressum
Letzte Änderung / Last change: Friday, 26-Apr-2019 18:53:53 CEST