Mit Source Packet Routing in Networking (SPRING) standardisierte die IETF einen alternativen Ansatz für die Signalisierung von MPLS-Pfaden, der auch als Segment Routing (SR) bekannt ist. Einer der vielen Vorteile von SPRING ist die Möglichkeit, verkehrstechnisch optimierte Wege durch das Netzwerk zu definieren.

Vor ein paar Jahren gab es jedoch keine Router-basierte Implementierung zur Bereitstellung oder Definition der Traffic-Engineering-Pfade. Da bereits kommerzielle Controller, wie Juniper Networks Northstar, am Markt erhältlich waren, stellten wir uns die Frage, welche herstellerübergreifenden Traffic-Engineering-Möglichkeiten mit Open-Source-Tools zur Verfügung stehen. Die Recherchen mündeten in einem Entwicklungsprojekt, in dem wir einen eigenen Proof-of-Concept-SPRING-Controller entwickelten, der in unserem XT3Lab gegen eine Demo-Netztopologie arbeitet.

Lassen Sie uns zunächst einen Blick auf die traditionellen Label-Signalisierungsprotokolle werfen, die auch heute noch zum Einsatz kommen, nachfolgend in den neuen SPRING-Ansatz eintauchen und letztendlich zeigen, wie wir unseren selbst entwickelten SPRING-Controller mit Open-Source-Tools implementiert haben.

 

Label-Distribution mit LDP und RSVP

Traditionell werden zwei Protokolle zur Signalisierung von MPLS-Labels innerhalb eines autonomen Netzes eingesetzt:

  • Das Label Distribution Protocol (LDP) bietet eine beliebige “Any-to-Any”-Konnektivität zur Erstellung von Ende-zu-Ende Label Switched Paths (LSPs) zwischen Elementen innerhalb eines MPLS-Netzwerks – und dies bei geringem “Control-Plane-Overhead”. Mit der IP-Loop-Free-Alternate-Funktionalität (IP-LFA) bietet LDP zwar einen schnellen “Failover”-Mechanismus, die Pfade folgen jedoch aufgrund fehlender Traffic-Engineering-Fähigkeiten immer dem kürzesten Weg auf Basis des Interior Gateway Routing Protocol (IGP).
  • Soll der Traffic auf bestimmte Pfade gezwungen werden, kommt das Resource Reservation Protocol – Traffic Engineering Extension (RSVP-TE) zum Einsatz. Wie bei LDP kann auf Wunsch jede beliebige Verbindung über den kürzesten Weg entlang des IGP hergestellt werden. Im Vergleich zu LDP bietet RSVP-TE aber auch Möglichkeiten zum Traffic-Engineering, sodass spezifische LSPs entlang eines definierten Pfads innerhalb eines MPLS-Netzwerks signalisiert werden können. Das Hauptproblem bei der Nutzung von RSVP-TE ist, dass es Control-Plane-Status im gesamten Netzwerk, also bei jedem durchlaufenden Knoten, erzeugt. Dies ist besonders bei P-Routern problematisch und sorgt dafür, dass die Skalierung von RSVP-TE typischerweise begrenzt ist.

 

Die neue Hoffnung – SPRING

Die Idee hinter SPRING ist es, sich Netzwerke als eine Sammlung topologischer Teilpfade – oder Segmente – vorzustellen. Auf den ersten Blick mag SPRING in Bezug auf die TE-Fähigkeiten ähnlich wie RSVP-TE klingen, doch die Art und Weise, in welcher SPRING Labels innerhalb eines Netzwerks signalisiert, unterscheidet sich. Sie folgt dem Source-Routing-Ansatz, sprich, die Liste der Segmente, die Pakete durchqueren sollen, wird in das Datenpaket selbst kodiert. Ein weiterer Vorteil ist, dass SPRING kein zusätzliches Protokoll ist, das im Netzwerk implementiert werden muss, sondern eine Protokollergänzung, um die bestehenden Routing-Protokolle wie IS-IS, OSPF oder BGP mit den von SPRING benötigten Label-Informationen zu erweitern.

 

SPRING-Controller mit Open-Source tools

Inspiriert von Juniper Networks Fallstudie „Using BGP-Labeled Unicast for Segment Routing Traffic Engineering“, entwickelte sich Xantaros SPRING-Controller-Ansatz zu dem im Folgenden vorgestellten Projekt. Der Prototyp des SPRING-Controllers stellt, wie im folgenden Bild zu sehen, ein Web-basiertes User-Interface (UI) zur Verfügung, mit der die Netzwerktopologie in einem interaktiven Diagramm dargestellt wird.

 

 
Zusätzlich zur Darstellung der Topologie können verschiedene Zusatzinformationen über NETCONF, Aristas EOS API (eAPI) oder ähnlichen APIs direkt von den Geräten abgerufen und ausgegeben werden. Parallel zum Empfang oder aktiven Abruf dieser Informationen ist zudem das Juniper Telemetry Interface (JTI) sowie OpenConfig Telemetry Streaming in die Controller-UI integriert. Dies ermöglicht die Echtzeit-Push-basierte Visualisierung der Schnittstellenstatistiken innerhalb der Controller-Oberfläche.

 

Die Architektur des SPRING-Controllers

Die essentielle Frage, die dieses Projekt beantwortet, ist, mit welchen Open-Source-Komponenten ein vollfunktionsfähiger SPRING-Controller geformt werden kann. Eine übersichtliche Antwort auf diese Frage gibt die im Nachfolgenden abgebildete Controller-Architektur.

 

 

 

Werfen wir einen Blick auf die einzelnen Komponenten:

  • ExaBGP: ExaBGP ist eine Python-basierte Implementierung des BGP-Protokolls. Es übernimmt den gesamten Nachrichtenaustausch mit den BGP-Speakern. Die Steuerung verwendet zwei MP-BGP-Adressfamilien: BGP-LU (BGP-Labeled Unicast) und BGP-LS (BGP-Link State).
    BGP-LS wird verwendet, um die über das IGP verteilten Topologie-Informationen zu sammeln, die im Falle von SPRING mit Label-Informationen angereichert werden. Es genügt, mit nur einem BGP-LS sprechenden Netzwerkgerät zu „peeren“. BGP-LU-Sitzungen werden hingegen mit jedem SPRING-fähigen Gerät eingerichtet, das Verkehrsinformationen empfangen muss. Diese Sitzungen werden verwendet, um die Präfixe mit einem geeigneten Label-Stack anzukündigen, sodass der beabsichtigte Patch im gesamten Netzwerk in Richtung der Eingangsknoten beschrieben wird.
  • RabbitMQ: RabbitMQ ist ein Open-Source Message-Broker. Nachrichten werden über sogenannte „Exchanges“ an Warteschlangen vermittelt, wobei das Messaging-System verschiedene Arten der Nachrichtenzustellung implementiert. So ist die Nachrichtenzustellung mit Unicast, Multicast oder Broadcast zu vergleichen. Die Nutzung des Nachrichtenwarteschlangenkonzepts ermöglicht es, mehrere Teile des SPRING-Controllers lose zu koppeln und somit die Skalierbarkeit zu erhöhen.
  • Redis: Redis ist ein In-Memory Key-Value-Speicher und wird als zentraler Datenspeicher für die verschiedenen Komponenten des Controllers genutzt. Die meisten Skripte können unabhängig voneinander ausgeführt werden, benötigen jedoch eine gewisse Persistenz.
  • Python-Skripte:
    Eigenentwickelte Python-Skripte stellen den Kitt zwischen den verschiedenen Komponenten des Projekts dar:

    – ExaBGP2RabbitMQ: Dieses Skript sorgt für eine einfache Weiterleitung. Es übernimmt die JSON-Ausgabe von ExaBGP, ohne sie zu analysieren oder zu inspizieren, und schiebt diese in einen RabbitMQ-Exchange, wo die Daten schließlich in eine einzige gemeinsame Warteschlange übertragen werden. Das Skript ist so kurz und überschaubar wie möglich, da es ansonsten bei der späteren Verarbeitung großer Datenmengen zum Nadelöhr werden kann.

    – ExaBGPParser: Das ExaBBP Parser-Skript liest Nachrichten aus der Warteschlange, analysiert sie, entnimmt die enthaltenen Informationen und konvertiert diese in ein Format, das vom Controller verarbeitet werden kann. Der resultierende Datensatz wird dann im Redis K/V-Store gespeichert, der eine neue Nachricht mit den extrahierten Informationen erzeugt. Eingehende Nachrichten sind inhaltlich spezifisch (z.B. Link-, Knoten- oder Präfix-Updates) und typspezifische Python-Skripte konsumieren diese Nachrichten. Da das Parsen von Empfangs- oder Speichervorgängen entkoppelt ist, kann dieses Modul mehrfach parallel gestartet werden und ermöglicht so eine hervorragende Skalierbarkeit.

    – PyEZ / Netconf / EOS API (eAPI) Skripte: Diese Skripte abonnieren die zuvor genannten Link-, Node- und Prefix-Updates. Sobald bestimmte Nachrichten (z.B. Präfix-Updates) empfangen werden, werden alle zusätzlichen Informationen vom entsprechenden Knoten eingesammelt. Die gesammelten Informationen werden anschließend im Redis-Backend gespeichert.

  • Open-NTI: Juniper Networks‘ Open-Network-Telemetry-Interface-Projekt (Open-NTI) ist eine Sammlung von Open-Source-Komponenten, die zu einem Framework zusammengefügt sind, das Streaming-Telemetrie-Daten sammelt. Verwendete Komponenten sind InfluxDB als Zeitreihendatenbank, Telegraph als Empfängerfilter-Pipeline und Grafana als Web-UI. Es enthält weitere Komponenten wie einen Syslog-Server, der aber, da er nicht benötigt wird, für das Controller-Projekt explizit deaktiviert wurde.
    Die nativen OpenConfig-Telemetry-Komponenten interagieren direkt mit der InfluxDB, statt die zusätzlichen Funktionen von Juniper Networks Open-NTI zu nutzen.
  • Web-UI: Die Web-UI wird über einen Nginx-Webserver bereitgestellt. Ein PHP-Prozess auf dem Server greift auf den Redis-Datenspeicher zu und stellt seine Daten über eine API dem js Javascript-Grafik-Framework zur Verfügung, das über AJAX-Aufrufe ausgelöst wird. Vis.js ist ein Open-Source-Javascript-Diagramm- und Grafik-Framework, das verwendet wird, um die Knoten (SR-Knoten) und Edges (Netzwerk-Links) mit Hilfe eines Gravitationsmodells darzustellen. Außerdem greift der PHP-Prozess in die InfluxDB ein, der Teil des Open-NTI-Frameworks ist, um Informationen über die verfügbaren Telemetrie-Informationen der Interfaces abzurufen.

Das gesamte Projekt ist in mehreren Docker-Container verpackt, die wiederum über die Docker-Compose-Infrastruktur miteinander verkoppelt sind, wodurch es sehr leicht und schnell ausgerollt werden kann.

 

Demo-Topologie

Wie dem nachfolgenden Bild zu entnehmen ist, besteht die Demo-Topologie aus neun Juniper Networks vMX-Instanzen. Sechs der Instanzen bilden eine MPLS-P-Ringtopologie (dargestellt in orange) und drei sind als PEs mit dem Core-Netzwerk verbunden (dargestellt in grün). Als IGP kommt IS-IS mit aktivierter Segment-Routing-Erweiterung zum Einsatz.

 

 

Jeder der Knoten pflegt eine BGP-Session mit dem SPRING-Controller, der physisch mit den Knoten Core2 und Core3 verbunden ist. Diese Session trägt nur die BGP-LU (Labeled Unicast) Adressfamilie, mit der IP-Präfixe vom Controller an den Netzwerkknoten übermittelt werden. BGP-LU SAFI (Subsequent Address Family Identifiers) ermöglicht es an dieser Stelle, zusätzliche Informationen zu IP-Präfixen hinzuzufügen, die über das hinausgehen, was die üblichen IP SAFIs bereits bieten. Dieser Label-Stack stellt den Pfad dar, den das Paket durch das Netzwerk nehmen muss.

Der Core3-Knoten ist für ein zusätzliches AFI konfiguriert, nämlich BGP-LS (Link-State). Die Adressfamilie wird verwendet, um IGP-Link-State-Informationen, also Topologie-Informationen innerhalb einer BGP-Sitzung, an den Controller zu übertragen. Dabei muss der Controller nicht Teil des IGP sein, kann OSPF oder IS-IS sprechen, erhält aber alle über diese Protokolle verfügbaren Informationen.

 

SPRING und Controller in Action

Um einen besseren Einblick in den entwickelten SPRING-Controller und die Funktionalität von SPRING zu geben, haben wir ein Video erstellt, das den Startablauf, das Laden von Live-Daten von Netzelementen und das einfache Provisionieren von Pfaden über die grafische Weboberfläche zeigt:
 

 

  • Zu Beginn wird das Projekt über Docker-Compose initialisiert und die Weboberfläche aufgerufen. Zu sehen ist die grafische Ausgabe der Demo-Topologie und der Node-Zusatzinformationen (Router-ID, Version, Chassis, Uptime) über die Tooltip-Anzeige.
  • Über die „Nodelist“ wird nach einem spezifischen Knoten gesucht und an diesen Knoten herangezoomt. Diese Funktionalität ist besonders bei sehr großen Netzen von Vorteil.
  • Nachfolgend werden über den Tab „Telemetry“ die Echtzeitdaten der verbundenen Interfaces ausgegeben.
  • Über die Funktion „SPRING-Path“ wird exemplarisch die interaktive Provisionierung eines TE-Pfades für den Präfix 44.44.44.1/32 gezeigt. Die Aufnahme wird über den Button „Record Path“ gestartet und der Pfad wird mit Mausklicks auf die entsprechenden Icons der Knoten und Links bestimmt.
  • Über die CLI-Kommandos „show route 44.44.44.1“ und „traceroute 44.44.44.1 no-resolve“ wird auf PE1 die erfolgreiche Provisionierung des korrekten Pfades geprüft.
  • Zuletzt wird über die Ausführung von Pings die Interface-Auslastung an PE1 gezeigt.

 

Für weitere Details zu SPRING, den allgemeinen Nutzen und der Integration in ein operatives Netzwerk, nutzen Sie gerne das untenstehende Kontaktformular.

 


FrauHerr

 

Hier finden Sie alle Informationen zum Datenschutz.