=====Austausch unserer Border-Router am 30.06.2020=====
====Unser Setup im Detail====
Wir betreiben für die Internet-Anbindung der Ruhr-Universität zwei sogenannte AS-Border-Router, als eigenständige Systeme arbeiten. Mehr zur Anbindung der Ruhr-Universität ans Internet kann man [[blog:2020:internetanbindung|hier]] nachlesen.

Unsere internen Routing-Systeme, welche die Gebäude und externen Liegenschaften versorgen, sind jeweils als VSS-System ausgelegt. Das bedeutet, dass es für jeden Router doppelte Hardware gibt, die beiden Systeme jedoch als ein und derselbe Router auftreten. Beispielsweise gibt es für die G-Reihe eine Hardware im Gebäude GB und eine weitere im Gebäude GD. Die beiden Systeme sind über Glasfaserkabel direkt miteinander verbunden und bilden ein sogenanntes VSS (Virtual Switching System), also ein großes Gerät bestehend aus den beiden einzelnen Hardware-Teilen.

Unsere AS-Border-Router sind absichtlich **NICHT** so konfiguriert. Während auf den internen Systemen die Vorteile überwiegen (geringere Anfälligkeit für Konfigurationsfehler, schnellere Konvergenzzeiten bei Ausfall einer Hardware), wollen wir auf den Border-Routern gerne auf die Nachteile verzichten (Konfigurationsfehler oder Software-Fehler können beide Systeme gleichzeitig lahm legen). Des weiteren haben wir die Leitungen zu den Internetprovidern in der Regel ohnehin nicht redundant, so dass beispielsweise beim Ausfall der Hardware, an die die TMR-Anbindung gesteckt ist, keine alternative Verbindung zu TMR besteht. Hier wäre es sinnfrei, ein VSS-System zu betreiben.

====Was passiert beim Ausfall eines AS-Border-Routers?====
Beim Ausfall oder Neustart eines AS-Border-Routers bekommt der verbliebene Router spontan mehr Arbeit. Er muss große Teile seiner Routingtabelle neu berechnen und gleichzeitig spontan in etwa doppelt so viel Traffic transportieren. Dabei ist es unerheblich ob der Ausfall unvorhergesehen (durch technischen Defekt oder Stromausfall) passiert oder absichtlich, z.B. wegen eines Software-Updates.

Die eigentliche Problematik in einer solchen Situation ist jedoch, dass nicht nur der verbleibende Router auf unserer Seite mehr Arbeit bekommt und alles mögliche neu berechnen muss, sondern dass das prinzipiell für alle autonomen Systeme des Internets gilt. Die Bekanntgabe von Routen im Internet erfolgt, indem die AS-Border-Router ihren direkt verbundenen Kommunikationspartnern (in unserem Fall den Provider-Routern von DFN-Verein und TMR) sagen, welche IP-Adressbereiche sich hinter ihnen befinden. Das sind bei uns zur Zeit: 134.147.0.0/16, 185.73.20.0/22, 192.35.72.0/24 und 2a05:3e00::/29. Unsere Router sagen also praktisch: "//Die RUB-Netze sind hier bei mir!//". Die Provider verfahren genau so und sagen weiter: "//Die Netze der RUB bekommt ihr über mich!//". Umgekehrt bekommen wir von den Provider-Routern sinngemäß für JEDES Subnetz der Welt gesagt: "//Das Netz für E erreicht ihr über mich, A, B, C und D!//". Und zwar von jeder Internet-Anbindung, also insgesamt dreimal. Das sind aktuell ca. 850.000 IPv4- und ca. 100.000 IPv6-Netze (bzw. Routen). Jedes autonome System des weltweit verzweigten Internets empfängt diese Nachrichten und gibt sie entsprechend weiter. Es gibt natürlich Verfahren zur Vermeidung von Schleifen und Fehlinformationen, die wollen wir aber an dieser Stelle ausklammern.

====Die Stille Post des Internets====
Fällt einer unserer AS-Border-Router aus, so merkt der Provider das schnell und gibt diese Information auch weiter: "//Die Netze der RUB bekommt ihr jetzt nicht mehr über mich!//". Für mindestens ein paar Sekunden (in der Regel bis zu zwei Minuten) bekommt er jedoch noch Daten für uns zugestellt, er kann dann in der Regel nichts weiter tun als diese zu verwerfen. Es kommt schlußendlich zum Abbruch empfindlicher Verbindungen wie z.B. dem RUB-VPN-Tunnel, wenn man ihn von zuhause aus gerade nutzt.

Beim ordentlichen Neustart eines unserer Router wird der Provider über das BGP-Protokoll entsprechend benachrichtigt, so dass er die Information rechtzeitig weiter geben kann (sog. "graceful shutdown"). Dann wird die Zeit, in der er Daten für uns bekommt, diese aber verwerfen muss, noch etwas kürzer. Das hängt aber auch immer davon ab, wie schnell die anderen mit dem Provider verbundenen autonomen Systeme diese Information verarbeiten.

====Speicher voll====
Die aus der "Stillen Post" entstehenden Routingtabellen des Internets wachsen unaufhörlich. Seit Anfang der 1990er Jahre wächst die IPv4-Routingtabelle unaufhörlich. Waren es im Jahr 2008 noch ca. 250.000 Einträge, so wurde im Jahr 2014 schon die 500.000er-Marke überschritten. Aktuell sind es 850.000 Routen, Tendenz steigend. Dies erfordert immer mehr teuren, speziellen Speicher in den verwendeten Routern, wenn man nicht anderweitig aggregieren kann (was wir nicht sinnvoll können).

Bisher gelang es uns immer, durch vorausschauende Planung rechtzeitig Hardware-Anpassungen vorzunehmen. Anfang des Jahres 2020 wähnten wir und noch in Sicherheit, doch da geschah es. Das Auftreten folgender unscheinbarer Fehlermeldung im Log eines unserer AS-Border-Router bedeutete weitaus schlimmes als man zunächst annahm:

''%CFIB-DFC1-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched''

Es kam zu Erreichbarkeitsproblemen vieler Webseiten, Problemen mit dem RUB-VPN-Tunnel und vielen weiteren, nicht direkt damit in Verbindung zu bringenden Kleinigkeiten. Bevorzugt betroffen waren fast immer irgendwie die Netze der Telekom (die konnten nichts dafür, es war tatsächlich Zufall, wie sich später heraus stellte).

Eine detailliertere Analyse der Systeme, zusammen mit dem Hersteller Cisco, brachte die Erkenntnis, dass unsere Maschinen zwar genug Speicher hatten, aber mehr verbrauchten als sie sagten. Der Speicher war also wieder voll, wir konnten das nur nicht sehen. Ein paar Tricks haben wir noch versucht, aber lange halfen die auch nicht weiter. Es mussten also schnell neue Router her. Doch die hatten - natürlich - Lieferzeit. Und so lange blieb uns nichts anderes übrig als zu warten und hoffen, dass das Problem nicht allzu häufig auftritt.

Ein weiteres Indiz für einen nicht ordentlich funktionierenden Router war (bzw. ist) der Status der FIB (Forwarding Information Base). Folgender Befehl zeit den Status an:

''#show platform hardware cef exception status\\
Current IPv4 FIB exception state = TRUE\\
Current IPv6 FIB exception state = FALSE\\
Current MPLS FIB exception state = FALSE\\
Current EoM/VPLS FIB TCAM exception state = FALSE''

Taucht hier irgendwo ''TRUE'' auf, so ist der Fall eingetreten, dass die Maschine aufgrund irgendeines Problems nicht mehr ordentlich arbeiten kann. Es hilft nur ein kompletter Neustart des Geräts.

====Alles neu macht der ... Juni====
Bis die neue Hardware ausgewählt, bestellt, angekommen und konfiguriert war, vergingen einige Wochen. Als besondere Herausforderung kam hinzu, dass die neuen Maschinen nicht mehr wie die alten Geräte auf IOS, dem althergebrachten Router-Betriebssystem von Cisco, basieren, sondern auf IOS-XE. Das klingt ähnlich - ist es auch - im Detail finden sich jedoch wichtige Unterschiede. Zusätzlich mussten wir die Konfiguration "blind" machen, das heißt wir konnten vor dem Austausch der Geräte nicht wirklich testen, was wir konfigurieren.

Am 30.06.2020 war es dann so weit: Wir hatten alles fertig und konnten umbauen. Das bedeutete, nach einem vorher festgelegten Plan alle Kabel nacheinander von den alten Routern abzuziehen und in die neuen Router zu stöpseln. Ein Brandmelde-Alarm im Gebäude IC hätte die Aktion zwar fast verhindert - wir konnten zunächst nicht einordnen, ob der Alarm nicht doch im Gebäude IB war - letztendlich ist jedoch alles gut gegangen.

So sah das direkt nach dem Umbau aus:

{{:blog:2020:border-router-2020.jpg|}}

Die goldenen Kisten sind unsere alten Border-Router, die silbernen sind die neuen Geräte. Wir mussten also von unten nach oben umstöpseln.
====Quintessenz====
Alles in allem sind wir mit den neuen Systemen (fast) zufrieden. Sie tun im Wesentlichen was sie sollen und verhalten sich sehr viel performanter als die alten Systeme. Die Routing-Updates werden auch nach einem Neustart wesentlich flotter verarbeitet. Sicher gibt es ein paar Kinderkrankheiten, die man von einem Hersteller wie Cisco eigentlich nicht erwarten sollte, aber Hard- und Software reift nunmal beim Kunden, so ist das leider mittlerweile. So ein Hersteller kann ja auch nicht damit rechnen, dass der Kunde ein Feature auch tatsächlich benutzen will (was dann unweigerlich zum Crash und Neustart des Routers führt). Und so ein Kunde kann offenbar auch weder erwarten, dass man beworbene Features auch benutzen kann, noch, dass der angezeigte Speicherverbrauch des Systems auch tatsächlich stimmt. Wir sind da hartnäckig bei der Nachverfolgung der Fehler und geben so schnell nicht auf.

Tja, würden nur endlich mehr Leute IPv6 benutzen, das war nämlich von den Ausfällen mit den alten Routern nie betroffen. ;-)