Autor: Jan Rischmüller

6. November 2024

Warum Segment-Routing für MPLS im IONOS Backbone?

Normalerweise sollte der Betrieb eines Backbones, also des Kernnetzes eines Providers wenig Neuigkeiten produzieren. Es scheint uns vom IONOS Backbone Team aber sinnvoll unsere Erfahrungen mit der Protokollstruktur IS-IS Segment-Routing für MPLS zu beschreiben. Es handelt sich dabei um das bei großen Providern oft verwendete interne Routing-Protokoll IS-IS (Intermediate System to Intermediate System) mit den neuen, sog. Segment-Routing Erweiterungen für die MPLS-basierte Paketweiterleitung (Multi Protocol Label Switching). Clarence Filsfils von Cisco Systems ist der Erfinder dieser Architektur und er treibt die Standardisierung prominent voran. Längst haben sich alle größeren Hersteller auf diesen Weg festgelegt.

Der IONOS Backbone mit der Autonomen Systemnummer AS8560 im Border Gateway Protocol (BGP) verbindet die IONOS Rechenzentren untereinander und stellt darüber hinaus Connectivity zum Internet über Internet Exchange-Points (wie DE-CIX, AMSIX, LINX, ESPANIX etc.) sowie über direkten Datenaustausch mit Versatel, der Deutschen Telekom, Vodafone, usw. her.

Zu fast 100% kommen dabei heutzutage Ethernet-Verbindungen über Glasfaserkabel zum Einsatz, die auf der nächsten Netzwerkschicht Datenpakete der Protokolle

IPv4 (Internet Protocol Version 4)
IPv6 (Internet Protocol Version 6)
MPLS (Multi Protocol Label Switching)

transportieren. Ethernet-Verbindungen sind wie Autobahn-Teilstücke und IPv4, IPv6 und MPLS Pakete sind die Motorräder, Autos bzw. Lastwagen auf diesen Straßen.

Nun kommen noch die Routing-Protokolle hinzu. Diese sind die Mechanismen, die Wegweiser und Verkehrsleitsysteme auf diesen Autobahnen installieren und verändern. Auch Routing-Protokolle werden mittels IPv4, IPv6 und ähnlichen Paketen übertragen, sie ähneln jedoch eher den Baustellenfahrzeugen oder Polizeiwagen, die Veränderungen an den Autobahnen und Wegweisern vornehmen. Letztlich erzeugen Routing-Protokolle automatisch sog. Routing-Tabellen, die für das jeweilige Gerät die Informationen beinhalten welche Datenpakete mit welcher Zieladresse zu welchem Ausgang (Port oder Interface) herausgeschickt werden müssen. Sie reagieren auch auf ausgefallene Leitungen oder Router und rechnen dann automatisch neue Routing-Tabellen aus, die das ausgefallene Element umgehen.

Von LDP zu Segment-Routing

Ein Zoo an Netzwerk-Protokollen

Nun war es lange Zeit üblich im Internet IPv4, evtl. IPv6 vor allem aber MPLS mit verschiedenen internen Routing-Protokollen innerhalb eines Backbones zu steuern:

Für IPv4 kam OSPF v2 (Open Shortest Path First version 2) oder IS-IS (Intermediate System to Intermediate System) zum Einsatz.

Für IPv6 OSPFv3 (Open Shortest Path First version 3) oder ebenfalls IS-IS.

Für MPLS jedoch LDP (Label Distribution Protocol) oder RSVP (Resource Reservation Protocol).

Das käme der Situation gleich, dass an jedem Autobahnkreuz je ein Wegweiser für Motorräder, einer für Autos und einer für LKW aufgestellt ist und zur Verwaltung dieser Wegweiser drei verschiedene Straßenmeistereien mit unterschiedlichen Fahrzeugen bestehen, je eine für jede Art von Verkehrsmittel.

Router-Hersteller benutzen unterschiedliche Standards

Zu allem Überfluss gibt es im Internet verschiedene Router-Hersteller wie Cisco, Juniper, Nokia, etc. die vor allen Dingen das Protokoll LDP recht unterschiedlich bedienen. Wird ein Autobahndreieck in Form eines Juniper-Routers bereitgestellt nennen die Wegweiser die Städtenamen. Kommt ein Cisco Router zum Einsatz wird die Richtung für jeden Stadtteil angegeben.

Es wäre also wünschenswert, wenn:

1.) ein Routing-Protokoll IPv4, IPv6 und MPLS gleichzeitig steuern kann

2.) die verschiedenen Router-Hersteller sich in Bezug auf dieses Routing-Protokoll gleich und nach Standard verhalten.

Segment-Routing ist eine starke Vereinfachung

Dieser Zustand wird durch IS-IS mit Segment-Routing Erweiterung für MPLS (IS-IS/SR for the MPLS Dataplane) erreicht. Der IONOS Backbone basiert seit 2 Jahren auf dieser Protokollstruktur und unsere Erfahrung damit ist sehr positiv. Die Vorteile werden bei uns besonders sichtbar, da wir ein striktes Dual-Vendor Konzept verfolgen: Im Backbone müssen immer Wege über zwei verschiedene Router-Hersteller zur Verfügung stehen. Diese verstehen sich mittel IS-IS/SR nun problemlos.

Probleme mit LDP im Überblick

Technisch ausgedrückt waren die Probleme beim LDP:

Cisco benutzt Independent Label Distribution Control während Juniper Ordered Label Distribution Control voraussetzt. Das Verhalten lässt sich durch Konfiguration weitgehend angleichen, jedoch mit erheblichem Mehraufwand.

Da LDP größtenteils unabhängig von OSPF oder IS-IS operiert, jedoch die Benutzung ähnliches Verhalten erfordert, muss die Synchronisation der Protokolle sichergestellt werden, bevor Pakete nach deren Vorgaben weitergeleitet werden. Dies ist zwar ein automatischer Vorgang, er kann jedoch zur Verzögerung bei Umschaltungen führen.

Administrativ ist der Betrieb von zwei oder drei Routing-Protokollen natürlich umfangreicher und fehlerbehafteter als der eines einzigen. Jedes Routing-Protokoll benötigt Pflege in Form von Paketfiltern, Metriken und anderen Einstellungen.

Gibt es weitere Vorteile?

Zusätzlich ergeben sich aus der Umstellung von IS-IS/LDP zu IS-IS/Segment-Routing neue Möglichkeiten, die vorher nicht, oder nur über das extrem komplex zu bedienende Signalisierungs-Protokoll RSVP zur Verfügung standen:

Traffic Engineering (TE)
Topology Independent Loop Free Alternate (Ti-LFA)

Was ist Traffic Engineering?

Während OSPF, IS-IS oder LDP allein lediglich den kürzesten Weg für alle Pakete durch einen Backbone ermitteln, ist es jedoch manchmal notwendig mit einem Teil des Datenverkehrs einem nicht kürzesten, expliziten oder constrained Path zu folgen. Dies wird im allgemeinen als Traffic-Engineering (TE) bezeichnet. Hierzu benötigte man bevor es Segment-Routing gab das Resource Reservation Protocol (RSVP) das sich dadurch auszeichnet, dass extrem viel Konfiguration auf Backbone Geräten erforderlich ist.

RSVP funktioniert grob gesagt so, dass an jedem Autobahnkreuz zusätzliche Schilder für bestimmte Pakete angebracht werden: Autos von Freiburg nach Mannheim werden in Karlsruhe über Stuttgart geleitet statt direkt zu fahren, Autos von Basel nach Mannheim fahren direkt. Komplexere Aufgaben des Traffic-Engineering waren nur mit extrem viel Aufwand zu bewältigen.

IS-IS/Segment-Routing gibt im Gegensatz dazu den einzelnen Fahrzeugen (Paketen) Anweisungen in Form von MPLS-Labels mit. Die Autobahnschilder werden hier nicht verändert, sondern die Fahrer bekommen jeweils einen Zettel mit bestimmten Anweisungen (MPLS-Labels), wo sie abzubiegen haben. Möglich wird dieses Vorgehen durch die Zuordnung von festen, im ganzen Backbone bekannten Node-Labels (für ein Gerät bestimmte MPLS Labels) beim Segment Routing. Im Gegensatz dazu werden bei LDP oder RSVP MPLS-Labels dynamisch von jedem Gerät für alle Ziele erzeugt. Die einzelnen Geräte kennen aber bei LDP und RSVP nur ihre eigene Zuordnung Ziel-zu-Label und die ihrer direkten Nachbarn. Bei längeren Pfaden muss jeder Router die Labels nach seiner Tabelle austauschen.

Beim IS-IS/Segment-Routing lernt jeder Router mittels IS-IS die eindeutigen MPLS-Node-Labels und die gesamte Topologie (Landkarte) der anderen Router im Backbone und kann diese Labels ausgewählten Paketen voranstellen, um sie zu zunächst zu diesem Router zu zwingen. Auch mehrere Labels sind möglich, die nacheinander abgearbeitet werden und die Pakete so auf einen Pfad festlegen.

Wie funktioniert Ti-LFA?

Die erste und wichtigste Anwendung für IS-IS/Segment-Routing Traffic Engineering heißt Ti-LFA (Topology Independent Loop Free Alternate). Ti-LFA bedeutet, dass die Router nicht nur den kürzesten Pfad durch das Netzwerk ausrechnen, sondern auch einen zweitbesten Alternate Path. Im Falle eines Ausfalls des besten Pfades, schaltet ein Router mittels Ti-LFA sofort (in weniger als 50 Millisekunden) auf den Alternate Path um. Dieser Pfad kann mit den Traffic-Engineering Möglichkeiten von Segment-Routing auch durchgesetzt werden, obwohl die anderen Router im Netz noch nichts von dem Ausfall bemerkt haben. Mit Ti-LFA kann das Netz im Fehlerfall schneller umschalten als die Zeitspanne, die IS-IS oder OSPF benötigt um zu konvergieren. Konvergieren bedeutet, dass alle Router im Netz durch die Routing-Protokolle über den Ausfall der fehlerhaften Komponente informiert sind und einen neuen kürzesten Pfad errechnet haben – ein Vorgang, der normalerweise einige Sekunden dauert.

Wie konfiguriert man das alles?

Das hört sich alles unglaublich kompliziert an – wie wird das konfiguriert? Erstaunlich einfach: Es ist für die Basis von Segment-Routing lediglich erforderlich in unserem Fall in der IS-IS Konfiguration

jedem Router im Backbone den gleichen Segment-Routing Global-Block (SRGB) mitzuteilen, also einen MPLS Label-Bereich, welcher backboneweit gültig ist

ferner jedem teilnehmenden Router ein Node-Label für IPv4 und evtl. eines für IPv6 zuzuordnen

Die folgenden Konfigurationsbeispiele ordnen zwei Routern (einem Juniper und einem Cisco) den Segment-Routing Global-Block 16000 bis 23999 zu. Der Juniper bekommt dann das IPv4 Node-Label 20008 (16000+4008) und das IPv6 Node-Label 16008 (16000+8). Der Cisco bekommt das IPv4 Node-Label 20009 und das IPv6 Node-Label 16009.

Juniper JunosEVO:

protocols isis {
    source-packet-routing {
        srgb start-label 16000 index-range 8000;
        node-segment {
            ipv4-index 4008;
            ipv6-index 8;
        }
    }
}

Cisco IOS-XR:

segment-routing
 global-block 16000 23999

router isis 100
 interface Loopback0
  address-family ipv4 unicast
   prefix-sid index 4009
  !
  address-family ipv6 unicast
   prefix-sid index 9
  !

Möchte man nun auf einem Juniper JunosEVO Router die Verbindung über das interface ae1.0 mittels Ti-LFA absichern, benötigt man etwa diese Konfiguration:

protocols isis {
    backup-spf-options {
        use-post-convergence-lfa;
        use-source-packet-routing;
    }
    interface ae1.0 {
        level 2 {
            post-convergence-lfa;
        }
    }
}

Das gleiche für einen Cisco IOS-XR Router für das Interface Bundle-Ether1 konfiguriert sich so:

router isis 100
 interface Bundle-Ether1
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
  !
  address-family ipv6 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa

Es handelt sich also in beiden Fällen um sehr wenige, generische Einstellungen ohne auf die genauen Gegebenheiten eingehen zu müssen.

Und was ist SRv6?

Die Protokollstruktur Segment-Routing für MPLS ist nicht zu verwechseln mit Segment-Routing Version 6 (SRv6). Bei SRv6 wird auf MPLS ganz verzichtet und die Rolle der MPLS Labels übernehmen sog. IPv6 Segment Routing Extension Header (SRH). Der Vorteil ist, dass dann nur noch IPv6 weitergeleitet werden könnte und alles wird in dieses Protokoll verpackt. Etwa so als wenn auf der Autobahn nur noch LKW unterwegs sind, die Motorräder, Autos oder gar andere LKW transportieren. Eine Weiterleitung solcher Pakete ist für Router auch möglich, wenn sie an dem zusätzlichen SRv6 Routing nicht teilnehmen, also die SRH nicht auswerten und nur aufgrund ihrer IPv6 Routing Tabelle weiterleiten. Bei Segment-Routing für MPLS müssen alle Router eines Pfades Segment-Routing für MPLS unterstützen und damit automatisch eine MPLS Routing-Tabelle pflegen.

Grundsätzlich steht dem Übergang von Segment-Routing für MPLS zu SRv6 nichts im Wege. Wir beobachten die Implementierungen der Protokolle weiter. Vor 2 Jahren wurde SRv6 von uns als noch zu unreif bewertet, so erfolgte die endgültige Standardisierung von SRv6 für IS-IS oder OSPFv3 erst 2023.