Datacenter-Switch mit modularen Apps von Nokia Der Switch wird zum Linux-Host

„Nokia SR Linux“ baut auf einem unveränderten Linux-Kernel auf und führt darüber ein Set modularer Netzwerkapplikationen aus. Ein durchgängiges „YANG“-Datenmodell, eine programmierbare Python-CLI und das „NetOps Development Kit“ (NDK) prägen die Plattform als Basis für automatisierte Datacenter-Fabrics.

Nokia positioniert SR Linux /Service Router Linux) als offenes Network Operating System für IP-Netze und Datacenter. Die Software kombiniert die Robustheit der „Service Router Operating System“ (SR OS) Protokoll-Stacks mit einer modernisierten Management- und Steuerungsebene.

Der Kernel bleibt unangetastet, so dass administrative Werkzeuge und Container-Workflows aus der Linux-Welt erhalten bleiben. Über ein Lernportal und das frei verfügbare Container-Image testen Netzbetreiber die Software ohne Lizenzschlüssel und betreiben sie in „Containerlab“-Topologien lokal.

Architektur auf Basis eines unveränderten Linux-Kernel

Der Aufbau folgt einer Microservices-Logik. Jede Netzwerkapplikation läuft in einer eigenen Failure Domain und kommuniziert über eine Pub/Sub-Logik mit der Impart Database (IDB), die als zentrale State-Sharing-Komponente fungiert. Die Anwendungen tauschen Informationen über gRPC und protobufs aus, womit die Kommunikationskanäle skalierbar und unabhängig voneinander aktualisierbar bleiben. Per-Application-Upgrades laufen ohne Unterbrechung des Forwarding-Pfads, was eine 'hitless' Wartung einzelner Komponenten ermöglicht.

Den Forwarding-Pfad bildet eXtensible Data Path (XDP), eine auf DPDK basierende Hardware-Abstraktionsschicht. XDP koppelt SR Linux an unterschiedliche Plattformen und erfordert auf dem Host eine CPU mit SSSE3-Befehlssatz.

Auf Container-Hosts ohne SSSE3 bricht Containerlab die Bereitstellung beim Start eines SR-Linux-Knotens ab. Die Steuerungsebene nutzt den Network Namespace srbase-mgmt für das Management. DNS-Auflösung und gRPC-Services laufen in dieser eigenen Routing-Domain.

Datenmodell und CLI-Modi

Jede Funktion in SR Linux besitzt ein eigenes YANG-Modell. Aus den Modellen leitet sich der gesamte Befehlsbaum der CLI ab. Container-Knoten und Leaf-Knoten der YANG-Bäume bilden die Struktur, in der Administratoren navigieren. Vier Modi prägen den Umgang:

• Der running-Modus zeigt die aktive Konfiguration.

• Der candidate-Modus erlaubt Änderungen, die erst nach einem Commit wirksam werden, und kennt eine geteilte, eine exklusive sowie eine private Variante.

• Der state-Modus liefert Konfiguration und Betriebsdaten in einer Sicht, darunter Statistiken einzelner Subinterfaces.

• Der show-Modus greift auf in Python implementierte Reports zurück.

Die CLI selbst ist als Open-Source-Anwendung in Python umgesetzt und unterstützt Plug-ins, Aliasse, Annotationen und kontextsensitive Hilfen über das Fragezeichen. Ausgaben erscheinen als Text, Tabelle, JSON, XML oder YAML und lassen sich über ein Pipe-Konstrukt direkt an Linux-Werkzeuge weitergeben.

Die Befehle "info" und "info detail" zeigen Konfiguration mit oder ohne Default-Werte, "diff" stellt Änderungen im Candidate gegen den Running-Stand dar. Ein Commit erfolgt mit "commit now" für die Rückkehr in den Running-Modus oder "commit stay" für den Verbleib im Candidate. Über "discard" verwirft der Administrator Änderungen und kehrt in den vorigen Stand zurück.

Network Instances als virtuelle Forwarding-Tabellen

Eine Network-Instanz entspricht einer VRF mit eigenem Routing- oder Switching-Stand. SR Linux unterscheidet drei Typen.

• Der Typ default markiert die globale Routing-Instanz und kommt nur einmal vor.

• Der Typ ip-vrf hält Layer-3-Tabellen vor,

• der Typ mac-vrf stellt eine Bridging-Domain mit eigener MAC-Tabelle bereit.

Die Management-Schnittstelle läuft in einer automatisch angelegten Instanz mgmt.

Anders als bei klassischen Routern existiert in der Werkseinstellung keine implizite globale Routing-Tabelle. Der Administrator:in legt die default-Instanz an, fügt Subinterfaces hinzu und aktiviert die gewünschten Address Families per "admin-state enable".

Physische Interfaces erscheinen als "ethernet-1/Y" mit logischen Subinterfaces, die als routed oder bridged konfiguriert werden. Für Layer-2-Domains koppelt ein IRB-Interface die MAC-VRF an die Layer-3-Welt der default-Instanz und übernimmt die Gateway-Funktion für angeschlossene Hosts.

Die VLAN-Tag-Verarbeitung folgt eigenen Regeln. Der Parameter "vlan-tagging false" lässt nur untagged Frames zu, "true" erlaubt zusätzlich tagged Subinterfaces mit VLAN-Encapsulation. Die Bridge-Domain ergibt sich aus der Zugehörigkeit zur MAC-VRF, die VLAN-ID an der Schnittstelle spielt für die Domain-Bildung keine Rolle.

BGP und Routing Policies im Underlay

External BGP ist im Data Center das tragende Protokoll des Underlays. SR Linux folgt RFC 8212 und verwirft per Default sämtliche Routen, die ein eBGP-Peer empfängt oder ankündigt. Erst eine explizite Routing Policy hebt das Verhalten auf.

Eine Policy setzt sich aus Statements mit Matching-Kriterien und Aktionen zusammen. Matching-Kriterien greifen auf Prefix-Sets, AS-Path-Werte oder Community-Werte zu, Aktionen erlauben Accept, Reject oder Accept mit Modifikation einzelner Attribute. Eine Default-Aktion am Ende der Policy fängt nicht passende Updates ab.

Der Administrator, eine Administratorin wendet eine Routing Policy als Import- oder Export-Policy am BGP-Prozess an. Eine Import-Policy beeinflusst die BGP-RIB-In und filtert eingehende Updates. Eine Export-Policy steuert die BGP-RIB-Out und legt fest, welche Routen Richtung Peer gehen. Die Zuweisung erfolgt global, auf Gruppenebene oder am einzelnen Neighbor.

Eine typische Underlay-Konfiguration nutzt eine Peer-Group "spine-underlay" mit gemeinsamer Remote-ASN sowie zugewiesenen Policies für direkte und BGP-Routen. Über "set network-instance default protocols bgp afi-safi ipv4-unicast admin-state enable" aktiviert der Administrator die IPv4-Unicast-AFI/SAFI. Fehlt der explizite Enable, bleibt die Session bestehen, Updates fließen aber nicht zwischen den Peers.

Plattformen, Container-Image und Containerlab

Die Nokia-Plattformfamilie umfasst „7215 IXS“ für Out-of-Band-Management-Netze, „7220 IXR“ mit Fixed-Konfigurationen für Leaf- und Spine-Rollen, „7250 IXR“ als Chassis-System für Super-Spines und „7730 SXR“ als IP-Service-Interconnect-Router mit „FPcx“-Silizium. Die Typen reichen von „ixr-d1" bis „“ixr-h5-64o" bei den 7220 IXR-Geräten, „ixr-6e" bis „ixr-x45" bei den 7250 IXR-Switches und „sxr-1x-44s", „“sxr-1d-32d" sowie „“sxr-1-32d" bei den 7730 SXR-Produkten.

Für die Chassis-Modelle und 7730 SXR ist eine Lizenz erforderlich. Die 7220 IXR-Modelle laufen lizenzfrei mit einer Begrenzung des Datapaths auf 1000 PPS und einem wöchentlichen Neustart des Prozesses sr_linux.

Das Container-Image steht öffentlich unter ghcr.io/nokia/srlinux bereit und lässt sich ohne Registrierung beziehen. Ab Release 24.10.1 liefert Nokia das Image als Manifest-List mit ARM64-Unterstützung aus, womit Tests auf Apple-Silicon-Macs und ARM64-Cloud-Instanzen praktikabel werden.

Einbindung über Container

Containerlab bindet SR Linux über den Kind nokia_srlinux ein. Der Standard-Login lautet "admin und das Passwort „NokiaSrl1!". Public-Key-Authentifizierung richtet Containerlab für die Benutzer admin, linuxadmin und root automatisch ein, sofern entsprechende Schlüssel im Verzeichnis "~/.ssh liegen.

Containerlab generiert beim Start eine Startup-Konfiguration unter "/etc/opt/srlinux/config.json" und ergänzt die Werkseinstellung um aktivierte Interfaces, LLDP, gNMI-, gNOI- und JSON-RPC-Endpunkte sowie Unix-Socket-Zugriff auf gRPC-Services. Ein zusätzlicher gRPC-Server insecure-mgmt lauscht auf Port 57401 ohne TLS und dient lokalen NDK-Anwendungen sowie Test-Clients. Mit dem Befehl "tools system configuration save" oder "containerlab save -t" sichert man den Running-Stand zurück in die Datei config.json.

Programmierbarkeit über NDK, gNMI und Streaming Telemetry

Das NetOps Development Kit öffnet die interne Pub/Sub-Struktur für eigene Anwendungen. Über das NDK schreibt ein Entwickler einen Agenten, der dieselben Schnittstellen wie eine Nokia-Applikation nutzt und State sowie Konfiguration in das IDB-Modell einklinkt. Die unterstützten Sprachen umfassen Go, Python und C++. Der Agent erscheint im YANG-Baum als nativer Service und lässt sich über gNMI oder die CLI ansprechen.

Telemetrie folgt einem Push-Modell. SR Linux exportiert Subscription-basierte Daten über gNMI mit protobufs als Wire Format. Die Quelle bilden dieselben YANG-Pfade, die auch Konfiguration und Reports liefern, womit Daten und Schema kohärent bleiben.

Zusätzlich stehen die Schnittstellen JSON-RPC, NETCONF über SSH auf Port 830, SNMP sowie gRIBI und P4RT zur Verfügung. Die gNMI- und gNOI-Endpunkte sitzen im gRPC-Server-Block mgmt, den Containerlab mit einem generierten TLS-Profil clab-profile und aktivierten Tracing-Optionen vorkonfiguriert.

Anbindung an Nokia NSP und Event-Driven Automation

Die Integration in die Automationsplattformen „Nokia Network Services Platform“ (NSP) und Event-Driven Automation (EDA) bildet die Brücke zwischen SR-Linux-Knoten und einer fabricweiten Steuerung. EDA orchestriert Data-Center-Fabrics mit deklarativen Intents und nutzt die EDA-spezifischen gRPC-Server eda-discovery, eda-mgmt und eda-insecure-mgmt, die Containerlab in die Konfiguration einsetzt. Die NSP verwaltet die IP-Service-Layer der 7730 SXR und koppelt SR Linux an ein cross-domain Service- und Resource-Modell.

Drittanbieter-Tools binden ebenfalls direkt an. „Ansible“, „Nornir“, „gnmic“ und SR-Linux-spezifische Bibliotheken sprechen die Plattform über gNMI und JSON-RPC an. Eigene Reports und Show-Befehle erweitert ein Administrator über Python-Plug-ins der CLI, womit der show-Modus zu einem Erweiterungspunkt für Operations-Teams wird.

Einordnung und Bewertung

Für die Modernisierung einer Datacenter-Fabric liefert Nokia SR Linux einen Investitionsschutz, der den bewährten SR-OS-Protokollstack mit einer programmierbaren Management-Ebene koppelt. Unternehmen profitieren von Per-Application-Upgrades ohne Unterbrechung des Forwarding-Pfads und vom container-nativen Aufbau, der CI/CD-Pipelines für die Netz-Konfiguration ermöglicht.

Die ARM64-Unterstützung des Container-Images öffnet Test- und Validierungsumgebungen auch auf Apple-Silzium-Hardware und ARM-Cloud-Instanzen und beschleunigt damit Lab-Iterationen. Über Containerlab lassen sich Fabric-Topologien reproduzierbar nachbauen und in Automationspipelines einbinden.

Aus Sicht der IT-Sicherheit und der Compliance schafft das YANG-Datenmodell eine schemabasierte Single Source of Truth für Konfiguration und State, was die Audit-Fähigkeit gegenüber klassischen CLI-zentrischen NOS verbessert. Streaming Telemetry über gNMI liefert Push-basierte Zeitreihen aus genau den YANG-Pfaden, die auch die Konfiguration definieren, sodass Beobachtung und Soll-Stand kohärent bleiben.

Die Default-Konfiguration folgt RFC 8212 und verwirft alle eBGP-Updates ohne explizite Policy, wodurch Fehlkonfigurationen seltener zu unbeabsichtigter Routen-Propagation führen. Telnet und HTTP fehlen in der Werkseinstellung der Plattform, was die Angriffsfläche auf TLS-gesicherte gRPC-Endpunkte reduziert.

Für Enterprise Architects ergibt sich aus dem NDK ein wiederholbares Muster zur Integration eigener Services in das NOS, ohne eine Vendor-Roadmap abwarten zu müssen. Must-have für eine Einführung sind Kompetenzen im Umgang mit YANG, gNMI und Containerlab sowie eine Anpassung bestehender Provisioning-Tools an die modellgetriebenen Schnittstellen. Nice-to-have sind eigene NDK-Agenten für spezifische Operations-Workflows und der Einsatz von Event-Driven Automation als deklarative Steuerschicht.

(ID:50845396)