Viele Netzwerkadministratoren nutzten in der Vergangenheit vorinstallierte und kostspielige Appliances für das Routing. Was im produktiven Einsatz lange Zeit eine verlässliche Lösung darstellte, entpuppt sich bei einer flexibleren Verwendung als nicht mehr passend. Kommen beispielsweise stark virtualisierte Serverumgebungen zum Einsatz, wie dies heutzutage selbstverständlich ist, ergeben Hardware-Appliances nur noch bedingt Sinn.

So gibt es neue Ansätze, wie zum Beispiel Network Function Virtualization (NFV) oder Software-defined Networking (SDN), die die Netzwerke von der Hardware entkoppeln. Das Routing muss sich also neben anderen Funktionen wie dem Firewalling oder der Intrusion-Detection und -Prevention in eine sogenannte Service Chain, also die Verkettung der benötigten Dienste, einreihen lassen.

Zusätzlich bedurfte es früher viel Platz sowie entsprechend Strom und Geld, um die Funktionsweise von Routing-Protokollen in einer Testumgebung mit echten Hardware-Routern zu erlernen oder spezifische Verhalten nachstellen zu können. Netzwerkadministratoren, die ihre Implementierungen auf Schwachstellen prüfen wollten, mussten aufwendig Hardware-Umgebungen aufbauen oder eigene Routing-Stacks schreiben.

Eine Alternative zu klassischen Routern kann ein Routing-Stack auf Open-Source-Basis darstellen. Im Gegensatz zu den herkömmlichen monolithischen Architekturen mit spezialisierten Application-specific Integrated Circuits (ASICs) oder Field Programmable Gate Arrays (FPGAs) zur Hardware-optimierten Paketweiterleitung bieten diese natürlich nicht direkt die gleichen Performance-Optimierungen. In einigen Konstellationen geht es jedoch gar nicht so sehr um die Forwarding-Performance, sondern eher um die Funktionen der Control Plane wie beim Validieren eines Netzdesigns. Mit Control Plane sind die Funktionen gemeint, mit denen sich Netzwerke steuern lassen. Auf Layer 2 beispielsweise Spanning-Tree und auf Layer 3 die entsprechenden Routing-Protokolle.

Technologien, wie das 2010 von Intel entwickelte und inzwischen unter Führung der Linux Foundation stehende Data Plane Development Kit (DPDK) [1] zur Performance-Optimierung, ermöglichen jedoch mittlerweile auch den direkten Zugriff auf physische Ressourcen – ohne die verbleibenden Ressourcen wie die CPU zu stark zu beanspruchen.

Single-Root-I/O-Virtualisierung (SR-IOV) kann in virtualisierten Umgebungen auch die notwendige Flexibilität schaffen, um mit mehreren virtualisierten Netzwerkfunktionen auf eine native Hardwareressource zuzugreifen. Auch in Kombination mit den aktuell stark gehypten SmartNICs könnte eine optimierte Paketweiterleitung den Weg in eine neue Netzwerkarchitektur mit einem offenen Routing-Stack einleiten. Hierbei sollen Netzwerkfunktionen vom eigentlichen Host auf spezialisierte Netzwerkkarten ausgelagert werden, wie beispielsweise Verschlüsselungsfunktionen für VPN, Deep Packet Inspection für Next Generation Firewalls, aber auch Offloading von Routing-Aufgaben. Dies macht SmartNICs interessant für Software-Router.

Einen offenen Routing-Stack bietet das Open-Source-Projekt Free Range Routing [2], meist FRRouting oder FRR genannt. FRR ging als Fork aus dem Projekt Quagga [3] hervor. Quagga selbst kennen einige Administratoren bereits seit Jahren als Bestandteil aus anderen quelloffenen Projekten wie pfSense [4], in das sich mittlerweile auch FRR integrieren lässt. Aber auch als Routing-Stack der Unified-Threat-Management-Software von Sophos kommt Quagga als Unterbau im Routing zum Einsatz. Quagga selbst entstand 2002 als Fork aus dem mittlerweile nicht mehr gepflegten Projekt Zebra.

Der Fork von Quagga hin zu FRR entstand wegen der großen Backlogs an Patches und der langsamen Weiterentwicklung von Quagga. FRRouting verfügt über einen viermonatigen Release-Zyklus. Aktuell steht das Projekt unter der Obhut der Linux Foundation, an die es im April 2017 übergeben wurde. Jedoch unterstützen auch viele Organisationen die Entwicklung sehr aktiv. Dazu zählen VMware, Orange, Internet Systems Consortium (ISC) wie auch Nvidia und Cumulus Networks. Als Lizenzierungsmodell steht es unter der GPLv2+.

Dass sich der Routing-Stack von FRR sehr flexibel an unterschiedliche Umgebungen anpassen kann, zeigen die vielen Implementierungen. Darunter das bereits erwähnte Open-Source-Firewallsystem pfSense, aber auch dessen Fork OPNsense und das komplette Network Operating System (NOS) VyOS. Weiterhin sind auch Routing-Funktionalitäten von Datacenter-Switches mit FRR realisierbar. Dies belegt die Integration des Routing-Stacks in Switches von Cumulus Networks. Zu beachten ist, dass FRR lediglich für die Control Plane zuständig ist. Die eigentliche Entscheidung über das Forwarding der IP-Pakete trifft der Kernel des zugrundeliegenden Betriebssystems.

Bevor wir auf die einzelnen Leistungsmerkmale eingehen, werfen wir zunächst einen Blick auf die Architektur. Als Programmiersprache kommt C mit einzelnen Ergänzungen in Python zum Einsatz. Ansonsten unterscheidet sich FRR grundlegend von klassischen Netzwerkbetriebssystemen. Bereits in der Einleitung haben wir auf die monolithische Natur der Software-Architektur in klassischen Routern hingewiesen. Diese kamen aufgrund der seinerzeit knappen Ressourcen zum Einsatz. Dabei sind bereits ab Werk alle Prozesse für die dynamischen Routing-Protokolle aktiviert, was zu unnötiger Last, Angriffsfläche und auch Komplexität führt. Jeder Routing-Prozess kommuniziert beispielsweise bei einer Redistributierung von einem in das andere dynamische Routing-Protokoll direkt mit dem anderen. Somit muss für jedes Routing-Protokoll eine andere Schnittstelle bekannt und dokumentiert sein. Der Programmieraufwand nimmt mit jedem zusätzlichen Protokoll zu.

Dieses Problem löst FRR eleganter als die Software-Architektur in klassischen Routern. Dazu führt es einen zentralen und protokollunabhängigen Vermittlerprozess ein (Bild 1). Dieser Daemon ist unter dem Name Zebra bekannt. Jedes dynamische Routing-Protokoll, wie zum Beispiel BGP, bindet sich an diesen Daemon über die sogenannte Zebra-API (zapi) an. Der Zebra-Daemon bildet gemeinsam mit denen der dynamischen Routing-Protokolle die Control Plane. Die Paketweiterleitung selbst erfolgt aber über den Kernel des zugrundeliegenden Betriebssystems. Nun müssen noch die Routen aus dem Zebra-Prozess an den Kernel des Betriebssystems übergeben werden. Dies erfolgt über eine Socket-basierte Schnittstelle, um vom Userspace-Prozess zum Kernel zu gelangen; den sogenannten Netlink-Bus. Er bietet zum Beispiel eine Funktion, um neue Routen hinzuzufügen (RTM_NEW-ROUTE), wie in Bild 2 zu erkennen ist, kann aber auch neue Routen im Kernel an den Zebra-Prozess signalisieren. Der BGP-Daemon (bgpd) übergibt die Route über die Zebra-API (ZEBRA_ROUTE_ADD) an den Zebra-Daemon. Dieser nutzt die "RTM_NEWROUTE"-Funktion des Netlink-Busses, um die neue Route an den Kernel zu übergeben. Im Anschluss erfolgt die Bestätigung.

Die Architektur über den Middleman-Prozess bietet eine einfachere Integration neuer Routing-Protokolle, da es eine einheitliche Schnittstelle (zapi) gibt. Bei einer Redistribution von Routing-Prozess A nach B gibt Routing-Prozess A seine Routen über die zapi an den Zebra-Prozess und die zapi an Routing-Prozess B. Fehler und Abstürze in einem Protokoll wirken sich nicht zwangsläufig auf andere Daemons aus. Dies erhöht grundsätzlich die Gesamtverfügbarkeit.

Um ein dynamisches Routing-Protokoll einzusetzen, müssen Sie es in "/etc/frr/daemons" aktivieren. Lediglich der Zebra- und der watchfrr-Daemon sind bereits nach der Installation aktiviert. Letzterer erkennt fehlerhafte Daemons und startet sie bei Bedarf neu. Bei allen anderen ist die Parametrisierung von "/etc/frr/daemons" notwendig.

Kommen wir nun zum Management-Interface. Hier gibt es gerade einen Umbruch. Es gibt das klassische Konfigurationsmodell und jenes mit Northbound-Layer, um die Flexibilität zu erhöhen und moderne API-basierte Konfigurationsschnittstellen wie RESTCONF und NETCONF unterstützen zu können. Wir möchten zunächst das klassische Konfigurationsmodell darstellen. Hiermit ist die CLI-basierte "vtysh" [5] gemeint. Die Shell ist an das klassische NOS angelehnt. Wenn Sie Cisco-IOS-basierte Betriebssysteme verwenden, sollten Sie sich also schnell zurechtfinden, da die Syntax sehr ähnlich ist. Cisco IOS kennt einen User-EXEC-Modus sowie einen privilegierten EXEC-Modus. In Letzterem können Sie über den Befehl configure terminal in den globalen Konfigurationsmodus sowie im Anschluss in die schnittstellenspezifischen Konfigurationsmodi und Routing-Protokoll-Konfigurationsmodi wechseln.

vtysh kennt ebenso den privilegierten EXEC-Modus und den globalen Konfigurationsmodus sowie die spezifischeren Modi. Auch das Speichern über den Befehl write memory dürfte einigen Administratoren bekannt vorkommen. Die Ablage der gespeicherten Startkonfiguration erfolgt jedoch unterschiedlich. Während bei IOS-basierten Systemen die sogenannte Startup-Config im NVRAM abgelegt wird, erfolgt dies bei FRR im per Default aktivierten "integrierten vtysh Konfigurationsbetrieb" in der Datei "/etc/frr/vtysh.conf". Bei dieser Art des Konfigurationsbetriebs gibt es eine zusammengefasste Konfigurationsdatei. Jeder Daemon parsed beim Start diese Konfigurationsdatei und zieht sich daraus die relevanten Bestandteile. Gesetzt den Fall, dass eine separate Konfigurationsdatei je Daemon zum Einsatz kommen soll, müssen Sie den CLI-Befehl no service integrated-vtysh-config einsetzen. Um zu prüfen, ob eine integrierte Konfigurationsdatei vorliegt, bedarf es eines Blicks in "/etc/frr/vtysh.conf". Sollte der Inhalt "service integrated-vtysh-config" entsprechen, liegt eine integrierte Konfiguration vor.

Wie auch bei kommerziellen Herstellern aktuell in Mode, strebt das Projekt jedoch nach API-basierten Konfigurationsmodellen, um eine bessere Unterstützung für Netzwerkautomatisierung zu ermöglichen. Das Ziel der Entwickler stellt ein komplett programmierbarer Routing-Stack durch die graduelle Integration des YANG-Datenmodells dar. Hierzu kommt ein Northbound-Layer zum Einsatz, an den sich die unterschiedlichen Konfigurationsschnittstellen anbinden können. Bild 3 zeigt oben ein Beispiel des alten Modells und unten das neue. Der gesamte Prozess ist jedoch noch in Arbeit, da hierfür weitreichende Änderungen im Quellcode notwendig sind.

FRR lässt sich als Routing-Stack nicht mit kompletten Netzwerkbetriebssystemen vergleichen. Es dient speziell der Bekanntgabe und Annahme von IP-basierten Routing-Informationen auf Basis der unterstützten dynamischen Routingprotokolle und parametrisierten Richtlinien. Außerdem kümmert es sich um die Übergabe dieser Informationen an den Kernel des Betriebssystems über den Netlink-Bus. Zusatzfunktionen wie Firewalling, Network Address Translation (NAT) oder Quality of Service (QoS) stellt es nicht bereit. Hierfür müssen Sie auf die Funktionalitäten des zugrundeliegenden Betriebssystems oder Drittanbietersysteme zurückgreifen.

Der Funktionsumfang von FRR enthält eine große Vielfalt an dynamischen Routing-Protokollen. Es sei angemerkt, dass BSD-basierte Betriebssysteme nicht alle Funktionen unterstützen. Auch bei Linux empfiehlt sich ein genauer Blick in die Feature-Matrix [6], da einzelne Funktionen einer gewissen Kernel-Version bedürfen. Beachten Sie jedoch die minimalen Kernel-Versionen, stehen unter Linux grundsätzlich alle Funktionen zur Verfügung.

Mithilfe von FRR lassen sich statische, richtlinienbasierte sowie dynamische Routen einrichten. Die dynamischen Routing-Protokolle enthalten sowohl Interior-Gateway- als auch Exterior-Gateway-Routing-Protokolle. Je nach gewünschtem Einsatzszenario stehen Path-Vector-, Distance-Vector- und Link-State-Protokolle zur Verfügung. Zu den Exterior-Gateway-Protokollen gehört BGP. Somit ist auch der Einsatz als Internet-Edge-Router in Unternehmensnetzen oder Providernetzen möglich. Aber nicht nur an dieser Schnittstelle macht BGP eine gute Figur. Es bildet auch die Grundlage für das "Border Gateway Protocol Ethernet Virtual Private Network" (BGP EVPN), auf dem das "Virtual Extensible Local Area Network" (VXLAN) als Data Plane läuft. Hierüber besteht die Möglichkeit von Layer-2-Kopplungen für Rechenzentren über Layer-3-Grenzen hinweg. Zudem lässt sich dies mit Equal Cost Multipathing, also der gleichzeitigen und gleichmäßigen Nutzung mehrerer zur Verfügung stehender Links, kombinieren. Die Layer-2-Kopplung ist besonders interessant, wenn auf dem entsprechenden Host virtuelle Maschinen laufen. Diese lassen sich – vorausgesetzt der Unterstützung des eingesetzten Hypervisors – zwischen Standorten ohne Re-Adressierung der IP-Adressen migrieren. Das ist ohne die vom Spanning-Tree-Verfahren bekannten Einschränkungen möglich.

Besonders bei den Interior-Gateway-Protokollen (IGP) kann sich FRR behaupten. Wer einen Blick in die unterstützten IGPs wirft, findet altbekannte Protokolle wie RIP in Version 2 und OSPFv2 für IPv4, aber auch deren IPv6-Derivate RIPng sowie OSPFv3. Zusätzlich haben das Intermediate System to Intermediate System (IS-IS) sowie das davon inspirierte, aber für Spine-Leaf-Architekturen in Rechenzentren optimierte OpenFabric Einzug in die Feature-Liste gehalten. Für die Integration in Netzwerke auf Basis des zunächst Cisco-proprietären und seit einiger Zeit im RFC7868 veröffentlichten Protokolls EIGRP haben die Entwickler ebenfalls eine Lösung gefunden. Die Unterstützung wird gemäß Anmerkung auf GitHub noch als Alpha eingeschätzt. In unseren Tests konnten wir jedoch keine Fehler feststellen. Zusätzlich gibt es noch eine Implementierung des auf Wireless-Mesh-Netze optimierten Distance-Vector-Protokolls Babel. Eine Auflistung der unterstützten Protokolle finden Sie unter [6].

Falls FRR in großen Enterprise-Netzen mit Multiprotocol Label Switching (MPLS) zum Einsatz kommen soll, lässt sich der Daemon für das Label Distribution Protocol (LDP) zum Verteilen der MPLS-Labels verwenden. Dies bedarf jedoch zusätzlicher Konfiguration und Unterstützung im Kernel. Ebenfalls für größere multi-mandantenfähige Netze oder Routing-Isolierung ist das Leistungsmerkmal Virtual Routing and Forwarding (VRF) geeignet. Hierbei bestehen mehrere Routing-Instanzen, die sich gegenseitig ohne ein bewusstes Route Leaking [7] nicht sehen können. Es besteht dabei die Möglichkeit überlappender IP-Adressblöcke in unterschiedlichen VRFs.            

Während alle vorgenannten Protokolle für Unicast Traffic geeignet sind, bietet FRR auch eine Lösung für Multicast-Traffic. Hierfür steht ein Daemon für Protocol Independent Multicast (PIM) bereit. Zusätzlich bietet FRR einige Funktionen, um die Verfügbarkeit zu erhöhen. Beispielsweise lassen sich Fehler zwischen Routern auf Basis von Bidirectional Forward Detection (BFD) schneller erkennen. Sollten mehrere Router als First Hop zum Einsatz kommen, bedarf es eines First Hop Redundancy Protocols (FHRP). Hierfür bietet FRR das Virtual Router Redundancy Protocol (VRRP). Auf Basis des Daemons für das Next Hop Resolution Protocol (NHRP) besteht auch die Möglichkeit des Aufbaus von Dynamic-Multipoint-VPN-Lösungen.

Sie können FRR von verschiedenen Quellen beziehen und installieren. Die flexibelste, aber auch aufwendigste Option besteht darin, den Code aus dem offiziellen GitHub-Repository zu klonen und anschließend selbst zu kompilieren und zu installieren. Somit haben Sie stets Zugriff auf die aktuellen Releases. Die bequemere, aber nicht immer ganz aktuelle Variante stellt die Installation aus den Betriebssystemquellen dar. Wir haben uns für letztere Methode entschieden und FRR auf einem Ubuntu-20.04-Server installiert und anschließend das Routing für IPv4 und IPv6 auf Betriebssystemebene aktiviert:

Bevor wir nun näher auf unser Konfigurationsbeispiel eingehen, sind zunächst noch einige Vorbereitungen notwendig. Unter "/etc/frr/daemons" müssen Sie das gewünschte Routing-Protokoll aktivieren. Nach einem Reload steht dieses bereit. Mittels show watchfrr auf der vtysh prüfen Sie, welche Daemons aktiv sind.

Die Konfigurationen aller unterstützten dynamischen Routingprotokolle zu zeigen, würde den Umfang des Beitrags sprengen. Daher beschränken wir uns auf ein einfaches Beispiel für eine eBGP-Kopplung zwischen zwei Routern. Jeder der beiden Router gibt die IP-Adresse des jeweiligen Loopback-Interfaces über eBGP an den gegenüberliegenden Router bekannt. Hierfür haben wir gemäß der IP-Adressen aus Bild 4 auf dem darunterliegenden Ubuntu-20.04-Server den Loopback-Interfaces IP-Adressen zugewiesen. Im Nachgang gaben wir jeweils der Schnittstelle "ens33" eine IP-Adresse aus dem Transfernetz. Hierzu erzeugten wir die in Listing 1 und Listing 2 dargestellten YAML-Dateien für Netplan, um eine bootfeste Konfiguration zu erhalten. Die Aktivierung erfolgte über sudo netplan apply.

Nachdem die Hosts sich nun innerhalb des Transfernetzes "192.0.2.0/31" erreichen können, erfolgt im Nachgang die eigentliche FRR-Konfiguration. Für die Parametrisierung haben wir vtysh eingesetzt. Listing 3 zeigt die jeweiligen Konfigurationsbestandteile für eBGP. Wir weisen darauf hin, dass es sich lediglich um ein Beispiel handelt, um die Funktionsweise zu verdeutlichen. Dieses ist nicht für den produktiven Einsatz gedacht.

Gehen wir die Konfiguration aus Listing 3 nun anhand von FRR1 durch. Im ersten Schritt benötigen wir eine BGP-Nachbarschaft. Hierzu parametrisieren wir zunächst auf FRR1 das "AS65540" über router bgp 65540. Im Nachgang legen wir die Peer-Group "LAB" über neighbor LAB peer-group an, um die Peer-Konfiguration noch für weitere BGP-Peers anwenden zu können. Als entferntes AS kommt "65541" zum Einsatz mithilfe von neighbor LAB remote-as 65541. Um das Peering abzusichern, parametrisieren wir noch ein MD5-Kennwort über neighbor LAB password t0ps3cr3t. Im Anschluss binden wir den Nachbar "192.0.2.1" (FRR2) an die Peer-Group LAB, wodurch er die entsprechenden Parameter erbt. Dies erfolgt über neighbor 192.0.2.1 peer-group LAB. Nachdem das Peering zwischen den Routern besteht, gehen wir in die Adressfamilie und konfigurieren die Host-Route "192.168.1.1/32" für eine Bekanntgabe mittels network 192.168.1.1/32.

Nachdem die entsprechend korrespondierende Konfiguration auf dem FRR2 erfolgt ist, besteht die Möglichkeit, über den aus klassischen Netzwerkbetriebssystemen bekannten CLI-Befehl show ip bgp summary den Peering-Status zu prüfen. Die über BGP erlernten Routen fragen wir entsprechend über show ip route bgp ab. Wir erhalten auf FRR1 die Host-Route "192.168.2.2/32".

FRR bietet einen flexiblen Routing-Stack für Laborumgebungen bis hin zu produktiven Rechenzentrumsnetzen. Auch in Pentest-Tools für Routing-Protokolle wie Routopsy macht FRR einen guten Eindruck. Durch die große Anzahl an unterstützten Routing-Protokollen lässt sich FRR in viele Netze integrieren. Doch wo Licht ist, ist auch Schatten. Die Parametrisierung – insbesondere in Kombination mit zusätzlichen Funktionen wie einer Network Address Translation – wirkt durch die starke Verzahnung mit dem zugrundeliegenden Kernel in einigen Fällen zersplittert.