Ein Blick hinter die Kulissen von AS204197

„Ein ISP-Netz mit MikroTik? Das kann nur schiefgehen.“

Diesen Satz habe ich in den vergangenen Jahren mehr als einmal gehört.

MikroTik sei etwas für kleine Firmennetze. Für ein echtes Providernetz brauche man zwangsläufig Cisco, Juniper oder Nokia. Spätestens bei MPLS, MP-BGP, mehreren Rechenzentren, vollständigen Internettabellen und redundanten Kundendiensten würde das Ganze auseinanderfallen.

Nun: Es läuft.

Und es läuft nicht nur irgendwie. Unsere Infrastruktur transportiert produktiv Internetzugänge, Kunden-VRFs, PPPoE- und L2TP-Sessions, VPLS-Dienste, Peering, IP-Transit und redundante Standortvernetzungen über mehrere Rechenzentren.

Stabil, nachvollziehbar und teilweise besser als Netze, die auf dem Papier mit deutlich prestigeträchtigerer Hardware aufgebaut wurden.

Nicht, weil MikroTik sämtliche Probleme automatisch löst.

Sondern weil die Stabilität eines Netzes nicht zuerst vom Logo auf der Frontplatte abhängt.

Sie hängt davon ab, ob Routingdomänen sauber getrennt sind, Redundanz tatsächlich durchgängig funktioniert, Filter restriktiv aufgebaut wurden und jemand versteht, was im Fehlerfall passiert.

Ein teurer Router korrigiert keine schlechte Architektur.

Ein günstigerer Router ersetzt aber ebenso wenig fundiertes Netzwerkdesign.

In diesem Artikel gebe ich deshalb einen Blick hinter die Kulissen von AS204197: Wie unser MPLS-Core aufgebaut ist, welche Aufgaben P-, PE-, Border- und BNG-Router übernehmen, wie wir OSPF, LDP und MP-BGP miteinander kombinieren und welche Fehler und Learnings der vergangenen Monate unsere heutige Architektur geprägt haben.

Die gezeigten Konfigurationen stammen aus unserer produktiven RouterOS-7-Infrastruktur. Kundenspezifische Daten, Zugangsinformationen und sicherheitsrelevante Details wurden selbstverständlich entfernt oder abstrahiert.

Vereinfacht besteht unser Netz aus mehreren klar getrennten Ebenen:

Das öffentliche AS204197 wird an unseren Internet-Edges verwendet. Innerhalb des MPLS-Netzes arbeiten wir mit einem privaten BGP-AS.

Die Aufgaben sind bewusst getrennt:

• OSPF kennt die Transportwege durch das Netz.
• LDP verteilt die MPLS-Labels.
• MP-BGP verteilt die eigentlichen Dienste.
• P-Router transportieren gelabelte Pakete durch den Core.
• PE-Router terminieren Kunden-VRFs und MPLS-Dienste.
• Border Router kümmern sich um Transit, Peering und Downstream-BGP.
• BNGs terminieren PPPoE-, L2TP- und Breitbanddienste.
• Route Reflectors verteilen VPNv4-, L2VPN- und teilweise EVPN-Routen.

Nicht jeder Router muss alles können.

Vor allem muss nicht jeder Router alles wissen.

Das reduziert Komplexität, begrenzt Fehlerdomänen und macht die Fehlersuche deutlich übersichtlicher.

Die Grundlage unseres gesamten MPLS-Netzes ist ein bewusst einfach gehaltenes OSPF-Underlay.

Jeder Router besitzt eine stabile Loopback-Adresse. Diese Loopback dient gleichzeitig als:

• OSPF Router ID
• LDP LSR ID
• BGP-Endpunkt
• Identität für VPLS- und andere Tunnelbeziehungen
• stabiler Management- und Monitoring-Endpunkt

Eine vereinfachte RouterOS-Konfiguration sieht beispielsweise so aus:

OSPF transportiert in diesem Bereich keine Kundennetze und keine vollständigen Internettabellen.

Es sorgt primär dafür, dass die Loopbacks und Core-Verbindungen untereinander erreichbar sind.

Das klingt unspektakulär.

Genau so soll es sein.

Je mehr Kundennetze, Default Routes, Sonderlösungen und Services in das Underlay gelangen, desto schwerer wird später die Fehlersuche. Eine Störung innerhalb einer Kunden-VRF darf nicht die Stabilität des Transportnetzes beeinflussen.

Unsere wichtigste Grundregel lautet daher:

Das Underlay transportiert Infrastruktur. Die Services werden darüber aufgebaut.

Nicht jede Verbindung in unserem Netz ist technisch oder wirtschaftlich gleichwertig.

Zwischen den Rechenzentren und Infrastrukturstandorten kommen unterschiedliche Transportwege zum Einsatz:

• native Ethernet-Verbindungen
• Carrier-Strecken
• Rechenzentrums-Cross-Connects
• GRE- und IPsec-Tunnel
• Glasfaseranschlüsse

Diese Pfade werden über OSPF-Kosten gewichtet.

Ein nativer Rechenzentrumspfad erhält eine niedrige Metrik. Ein tunnelbasierter Backup-Pfad wird bewusst deutlich schlechter bewertet:

Der Backup-Pfad ist dabei nicht abgeschaltet.

Er ist vollständig aufgebaut:

• Das Interface ist aktiv.
• OSPF ist etabliert.
• LDP läuft.
• MP-BGP ist verfügbar.
• Die Loopbacks sind erreichbar.
• Die Labels sind bereits verteilt.

Der Pfad transportiert lediglich keinen produktiven Traffic, solange ein besserer Weg existiert.

Das ist wesentlich robuster, als im Fehlerfall erst Tunnel, Routingprotokolle oder BGP-Sessions aufbauen zu müssen.

Redundanz sollte im Normalbetrieb bereits funktionieren und nicht erst dann konstruiert werden, wenn die Primärverbindung ausgefallen ist.

Auf den Core-Verbindungen läuft MPLS mit LDP.
Die Konfiguration ist bewusst überschaubar:

OSPF entscheidet, wie die Loopback eines Zielrouters erreicht wird.

LDP verteilt auf Basis dieser Erreichbarkeit die notwendigen Labels und erzeugt einen durchgehenden Label-Switched Path.

Die Zuständigkeiten bleiben damit klar:

• OSPF berechnet den Transportweg.
• LDP bildet diesen Weg als Label-Switched Path ab.
• MP-BGP verteilt die darüber verfügbaren Dienste.

Ein P-Router muss die konkreten Kundennetze nicht kennen.

Er muss lediglich wissen, über welches Label und welches Interface der nächste MPLS-Knoten erreicht wird.

Das ist einer der wesentlichen Vorteile dieser Architektur: Die Core-Router müssen nicht mit jeder neuen Kundenroute wachsen.

Eines der wichtigsten Learnings der vergangenen Monate betrifft die MTU.

Auf nativen Core-Links verwenden wir eine ausreichend große MPLS-MTU, damit Platz für mehrere Labels vorhanden ist:

Auf tunnelbasierten Transportwegen muss die MPLS-MTU dagegen reduziert werden:

Ein MPLS-Paket kann mehrere Labels gleichzeitig tragen:

• ein Transport-Label
• ein VPN-Label
• bei bestimmten Diensten zusätzliche Labels

Dazu kommen je nach Underlay weitere Header:

• GRE
• IPsec
• PPPoE
• L2TP
• VLAN-Tags
• zusätzliche Ethernet-Header

Eine falsche MTU führt dabei nicht zwangsläufig zu einem vollständigen Ausfall.

Das wäre fast noch angenehm.

Stattdessen entstehen häufig Fehlerbilder wie:

• Kleine Pings funktionieren.
• OSPF und BGP sind stabil.
• Der LDP-Nachbar ist erreichbar.
• Webseiten laden nur teilweise.
• TCP-Verbindungen bleiben bei größeren Paketen hängen.
• Bestimmte Anwendungen funktionieren, andere nicht.
• VPN-Verbindungen brechen scheinbar zufällig ab.
• Telefonie oder Terminalverbindungen zeigen sporadische Probleme.

Auf den ersten Blick sieht das dann nach Firewall, Provider, Anwendung oder Server aus.

Tatsächlich fehlt irgendwo nur Platz für einige zusätzliche Bytes.

Deshalb gehört ein End-to-End-Test mit gesetztem DF-Bit für uns inzwischen zu jeder neuen Verbindung:

Die genaue Paketgröße hängt selbstverständlich vom Transportweg ab.

Wichtig ist das Prinzip: Nicht nur prüfen, ob ein Ziel erreichbar ist, sondern welche maximale Paketgröße tatsächlich ohne Fragmentierung durch den gesamten Pfad transportiert werden kann.

Mit zunehmender Anzahl an P-, PE-, BNG- und Border-Routern wird ein vollständiges iBGP-Mesh schnell unübersichtlich.

Bei zehn Routern wären bereits 45 direkte Sessions notwendig. Bei 20 Routern wären es 190.

Deshalb bauen unsere MPLS-Knoten jeweils zwei MP-BGP-Sessions auf – eine zu jedem Route Reflector.

Die beiden Route Reflectors befinden sich in unterschiedlichen Infrastruktur- und Fehlerdomänen.

Das war nicht von Anfang an so.

In der ersten Ausbaustufe existierte lediglich ein Route Reflector. Technisch funktionierte das. Redundant war es allerdings nicht.

Ein Route Reflector transportiert keinen Kundentraffic. Sein Ausfall unterbricht daher nicht zwangsläufig sofort alle bestehenden Verbindungen.

Das macht den Fehler aber nicht harmlos.

Ohne funktionierenden Route Reflector fehlen:

• neue Routen
• Withdrawals
• geänderte Pfade
• neue VPNv4-Informationen
• Änderungen an VPLS- oder EVPN-Diensten

Der Datenpfad kann noch funktionieren, während der Control Plane bereits veraltet ist.

Auf diesen Zustand wollten wir uns nicht verlassen.

Ein häufiger Fehler in komplexeren Netzen besteht darin, innerhalb des eigenen Backbones auf Filter zu verzichten.

Die Argumentation lautet dann:

„Das ist doch nur internes BGP.“

Genau dort kann eine falsche Redistribution allerdings besonders großen Schaden anrichten.

Ein PE, der ausschließlich VPNv4-Routen an die Route Reflectors übergeben soll, erhält deshalb einen engen Filter:

Auf Routern, die zusätzlich bestimmte IPv4-, L2VPN- oder EVPN-Informationen transportieren müssen, wird die Policy gezielt erweitert.

Wir vermeiden dagegen Regeln nach dem Prinzip:

Denn eine falsche Redistribution zwischen folgenden Bereichen kann innerhalb weniger Sekunden weite Teile des Netzes beeinflussen:

• Main Routing Table
• OSPF
• Internet-VRF
• Kunden-VRFs
• VPNv4
• statische Routen
• verbundene Netze
• Default Routes

Ein funktionierender Backbone braucht nicht möglichst viele Routen.

Er braucht genau die richtigen Routen.

Jeder logisch getrennte Dienst erhält eine eigene VRF.

Das betrifft bei uns nicht nur klassische Kundennetze, sondern auch:

• Internet-Transit
• Peering
• PPPoE-Kunden
• öffentliche Internetzugänge
• CGNAT-Kunden
• interne Infrastrukturnetze
• Managementnetze
• Remote-Access-Dienste
• Notfallzugänge
• individuelle Kundenumgebungen

Eine vereinfachte Kunden-VRF sieht beispielsweise so aus:

Dabei sind zwei Begriffe besonders wichtig:

Route Target

Der Route Target steuert, welche VRF eine bestimmte Route importieren oder exportieren darf.

Vereinfacht gesagt beantwortet er die Frage:

Zu welchem Dienst oder Kundennetz gehört diese Route?

Route Distinguisher

Der Route Distinguisher macht eine IPv4-Route innerhalb von VPNv4 eindeutig.

Er beantwortet nicht, wer eine Route importieren darf. Er sorgt dafür, dass identische IPv4-Präfixe aus unterschiedlichen VRFs oder von unterschiedlichen PEs als getrennte VPNv4-Routen behandelt werden können.

Das ist insbesondere bei redundanten PEs entscheidend.

Die Route Targets einer gemeinsamen Kunden-VRF müssen auf mehreren PEs identisch sein.

Die Route Distinguisher sollten dagegen pro PE und VRF eindeutig vergeben werden.

Ein mögliches Schema wäre:

Dadurch können die Route Reflectors beide Pfade als unterschiedliche VPNv4-NLRIs behalten und an andere Systeme weitergeben.

Verwendet man dagegen auf mehreren PEs denselben Route Distinguisher, können sich redundante Pfade gegenseitig überschreiben oder bereits am Route Reflector auf einen einzigen Pfad reduziert werden.

Das Netz wirkt dann redundant, ohne dass alle erwarteten Pfade tatsächlich im Control Plane vorhanden sind.

Ein wesentlicher Vorteil dieser Architektur besteht darin, dass die Transport-Router keine vollständigen Kundentabellen in ihrer normalen Routingtabelle benötigen.

Ein P-Router muss nicht wissen, ob ein Kunde beispielsweise folgende Netze verwendet:

Er muss lediglich wissen, wie der zuständige PE über dessen Loopback erreicht wird.

Die eigentliche Kundenroute befindet sich innerhalb der VPNv4-RIB.

Beim Transport durch den MPLS-Core werden typischerweise zwei Labels verwendet:

1. Das äußere Label transportiert das Paket zum richtigen PE.
2. Das innere VPN-Label ordnet das Paket am Ziel der richtigen VRF zu.

Der P-Router verarbeitet nur das äußere Label.

Er benötigt daher weder die Kundenroute noch Kenntnis über die verwendeten privaten IP-Adressen.

Dadurch können auch mehrere Kunden dieselben RFC1918-Netze verwenden, ohne miteinander zu kollidieren.

Drei verschiedene Kunden können jeweils ein Netz 192.168.1.0/24 betreiben. Solange sie sich in unterschiedlichen VRFs befinden, handelt es sich technisch um drei voneinander unabhängige Routingdomänen.

Ein neues Kundennetz erfordert keine Änderung auf allen Core-Routern.

Der Dienst wird an den zuständigen PEs eingerichtet und über MP-BGP verteilt. Der Transport-Core bleibt unverändert.

Die Border Router betreiben Transit, Peering und Downstream-BGP innerhalb einer eigenen VRF:

In dieser VRF befinden sich:

• unsere Upstream-Provider
• Peering-Verbindungen
• Internet Exchanges
• Route Server
• Downstream-BGP-Kunden
• öffentliche Netze
• die vollständige Internet-Routingtabelle

Die Internet-Routen werden nicht automatisch in alle anderen Routingdomänen übernommen.

Nur Systeme, die den zugehörigen Route Target importieren dürfen, erhalten Zugriff auf diese Routen.

Das betrifft beispielsweise:

• BNGs
• bestimmte PE-Router
• öffentliche Kunden-VRFs
• Infrastruktur mit direktem Internetzugang

Andere Kunden-VRFs bleiben davon vollständig getrennt.

Diese Trennung verhindert, dass die vollständige Internettabelle unkontrolliert durch das gesamte Netz verteilt wird.

Sie ermöglicht außerdem, Internetzugang als separaten Dienst zu behandeln.

Ein Kundennetz kann dadurch beispielsweise:

• ausschließlich private Standortvernetzung erhalten,
• zentralen Internet-Breakout an einem Standort verwenden,
• Internet über einen unserer Border Router beziehen,
• einen eigenen Upstream verwenden,
• oder mehrere dieser Modelle kombinieren.

Besonders kritisch ist die Behandlung der Default Route.

Ein Border Router darf nicht allein deshalb eine Default Route verteilen, weil statisch eine Route 0.0.0.0/0 konfiguriert wurde.

Entscheidend ist, ob der tatsächliche Upstream-Pfad funktioniert.

Eine vereinfachte Filterregel kann deshalb die Erreichbarkeit des Gateways berücksichtigen:

Damit wird die Default Route nur dann in den Backbone exportiert, wenn der zugehörige Gateway erreichbar ist.

Das verhindert einen unangenehmen Fehlerfall:

• Der Border Router läuft.
• Das LAN-Interface funktioniert.
• OSPF funktioniert.
• LDP funktioniert.
• MP-BGP funktioniert.
• Die statische Default Route ist vorhanden.
• Der eigentliche Upstream-Pfad ist aber gestört.

Ohne zusätzliche Prüfung würde der Router weiterhin eine Default Route verteilen.

Die BNGs und PEs schicken ihren Internettraffic dann an einen Router, der ihn nicht mehr zustellen kann.

Das Ergebnis ist ein Blackhole.

Genau daran zeigt sich, warum Redundanz nicht allein anhand von Interfaces oder Routing-Sessions bewertet werden darf.

Der Status des tatsächlichen Dienstes muss in die Pfadwahl einfließen.

Neben L3VPN verwenden wir auch VPLS.

Ein vereinfachter Pseudowire sieht beispielsweise so aus:

VPLS ist sinnvoll, wenn an zwei Stellen tatsächlich dieselbe Layer-2-Domäne benötigt wird.

Das betrifft bei uns unter anderem bestimmte:

• PPPoE-Szenarien
• BNG-Anbindungen
• Carrier-Übergaben
• Layer-2-Kundendienste
• Migrationsszenarien

VPLS hat allerdings Konsequenzen:

• Broadcasts werden über Standortgrenzen transportiert.
• Layer-2-Loops können mehrere Rechenzentren betreffen.
• MAC-Learning muss berücksichtigt werden.
• Fehlerdomänen werden größer.
• MTU-Probleme werden noch unangenehmer.
• Troubleshooting wird komplexer.

Unser Grundsatz lautet daher:

L3VPN ist der Normalfall. Layer 2 wird nur dort verlängert, wo es einen konkreten technischen Grund gibt.

VPLS ist ein leistungsfähiges Werkzeug.

Es sollte aber nicht als Ersatz für sauberes Routingdesign verwendet werden.

In Präsentationen wird Redundanz häufig durch zwei nebeneinander gezeichnete Router dargestellt.

In der Realität besteht ein funktionierender MPLS-Dienst aber aus mehreren voneinander abhängigen Ebenen:

Ein zweiter Router allein löst daher noch kein Verfügbarkeitsproblem.

Wir betrachten unter anderem:

• getrennte Rechenzentren
• alternative Carrierwege
• redundante Stromversorgung
• getrennte Switchpfade
• zwei Route Reflectors
• redundante PEs
• redundante BNGs
• mehrere Border Router
• OSPF-Kosten für Primär- und Backup-Pfade
• BFD auf geeigneten Verbindungen
• reduzierte MTU auf Tunnelpfaden
• dynamische Prüfung externer Gateways
• definierte Import- und Exportfilter
• eindeutige Route Distinguisher
• kontrollierte Route Targets

Erst wenn die komplette Kette getestet wurde, existiert echte Redundanz.

Ein Interface kann „up“ sein, während der Dienst dahinter längst ausgefallen ist.

Eine BGP-Session kann „established“ sein, obwohl die benötigte Route fehlt.

Eine VPNv4-Route kann vorhanden sein, obwohl kein funktionierender LDP-Pfad zum Next Hop existiert.

Ein Backup ist erst dann ein Backup, wenn es im realen Fehlerfall den kompletten Dienst übernehmen kann.

Wir setzen nicht auf jedem Knoten das größtmögliche Routermodell ein.

Die Anforderungen der einzelnen Rollen unterscheiden sich erheblich.

P-Router

Ein reiner Transport-Router benötigt vor allem:

• ausreichende Switching & Routing-Leistung
• OSPF
• LDP
• MPLS Forwarding

Er benötigt keine vollständige Internettabelle und keine große Anzahl an Kunden-VRFs.

PE-Router

Ein PE verarbeitet dagegen:

• viele VRFs
• VPNv4-Routen
• Route Targets
• VPLS-Pseudowires
• Kundenschnittstellen
• VPN und IPSec Leistung
• teilweise OSPF oder BGP innerhalb von Kunden-VRFs

Border Router

Ein Border Router benötigt Ressourcen für:

• mehrere vollständige BGP-Tabellen
• umfangreiche Routingfilter
• RPKI-Prüfungen
• Communities
• Peering
• Transit
• Downstream-Kunden
• hohen Internettraffic

BNG

Ein BNG verarbeitet wiederum:

• PPPoE-Sessions
• L2TP-Sessions
• RADIUS-Anfragen
• dynamische Interfaces
• Queues
• öffentliche Adressen
• kundenbezogene Routinginformationen

Architektur bedeutet daher nicht, überall identische Hardware einzusetzen.

Architektur bedeutet, die jeweilige Rolle, Last und Fehlerdomäne zu verstehen und die Hardware passend dazu auszuwählen.

MikroTik funktioniert in unserem Netz nicht deshalb gut, weil jede Box alles gleichzeitig macht.

Es funktioniert gut, weil wir den Geräten klar definierte Aufgaben geben.

Die Frage „Ist die BGP-Session up?“ reicht für den Betrieb eines solchen Netzes nicht aus.

Wichtiger sind Fragen wie:

• Welche Route wurde tatsächlich gewählt?
• Über welchen PE wurde sie gelernt?
• Welcher Route Target wurde importiert?
• Welche Communities trägt die Route?
• Ist der BGP Next Hop erreichbar?
• Existiert der notwendige LDP-Pfad?
• Welches Label wird verwendet?
• Über welchen physischen Link fließt der Traffic?
• Wie lange dauerte die Konvergenz?
• Hat sich nur der Pfad geändert oder ist der Dienst ausgefallen?

Wir spiegeln deshalb relevante BGP-Informationen an einen separaten Collector und verbinden diese mit Flow- und Infrastrukturtelemetrie.

Damit lassen sich Routingentscheidungen und tatsächliche Verkehrsströme miteinander vergleichen.

Eine Route kann aus Sicht von BGP korrekt sein und trotzdem keinen Traffic transportieren.

Umgekehrt kann Traffic über einen unerwarteten Pfad fließen, obwohl alle Routing-Sessions formal stabil aussehen.

Ein produktiver Backbone braucht deshalb mehr als reines Up-/Down-Monitoring.

Er braucht Transparenz über den Control Plane und den Datenpfad.

1. Ein einzelner Route Reflector ist keine gute Architektur

Für den Start kann ein Route Reflector ausreichen.

Dauerhaft sollte der gesamte MP-BGP-Control-Plane aber nicht von einem einzelnen System abhängen.

2. Das Underlay darf keine Müllhalde werden

Kundennetze, vollständige Internettabellen, Default Routes und spontane Sonderlösungen gehören nicht unkontrolliert in OSPF.

Das Underlay muss einfach und berechenbar bleiben.

3. Redistribution benötigt immer eine explizite Policy

„Redistribute connected“ klingt harmlos.

Auf einem Router mit vielen Interfaces und VRFs kann diese Einstellung allerdings Netze verteilen, die niemals den Backbone verlassen sollten.

4. Route Targets und Route Distinguisher sind nicht dasselbe

Gemeinsame Route Targets verbinden mehrere PEs mit derselben VPN-Domäne.

Eindeutige Route Distinguisher sorgen dafür, dass redundante Pfade im Control Plane als getrennte Routen erhalten bleiben.

5. MTU muss vor der Inbetriebnahme getestet werden

Dass OSPF, LDP und BGP funktionieren, beweist nicht, dass Anwendungen größere Pakete zuverlässig übertragen können.

6. Backup-Pfade sollten bereits vollständig aufgebaut sein

Im Fehlerfall sollten keine Tunnel, Routingprotokolle oder BGP-Sessions erst neu entstehen müssen.

Der Backup-Pfad sollte bereits stehen und nur aufgrund seiner schlechteren Metrik ungenutzt bleiben.

7. Layer 2 ist keine Abkürzung für fehlendes Routingdesign

VPLS ist sinnvoll, wenn wirklich eine gemeinsame Layer-2-Domäne benötigt wird.

Ansonsten vergrößert es nur die Fehlerdomäne.

8. Redundanz muss den Dienst prüfen, nicht nur das Interface

Ein WAN-Port kann aktiv sein, obwohl der Upstream nicht funktioniert.

Der Zustand des tatsächlichen End-to-End-Pfads muss in die Routingentscheidung einfließen.

9. Interne BGP-Sessions brauchen ebenfalls Filter

„Intern“ bedeutet nicht automatisch „vertrauenswürdig“.

Eine falsche Route aus dem eigenen Netz kann mindestens genauso viel Schaden verursachen wie eine falsche Route von außen.

10. Das Logo auf dem Router ersetzt keine Architektur

Natürlich unterscheiden sich Plattformen bei:

• Featureumfang
• Skalierung
• Support
• Automatisierung
• Telemetrie
• Hardware-Redundanz
• Softwarequalität

Aber kein Hersteller nimmt einem die eigentliche Arbeit ab:

• Routingdomänen planen
• Fehlerfälle durchdenken
• Filter definieren
• MTU berechnen
• Redundanz testen
• Monitoring aufbauen
• Konfigurationen dokumentieren

Wer das nicht beherrscht, baut auch mit teurer Hardware ein instabiles Netz.

MPLS ist nicht für jedes Unternehmen und nicht für jedes Netz die richtige Technologie.

Für eine Infrastruktur, in der verschiedene Kundennetze, Rechenzentren, Internet-Edges, Breitbandzugänge und Remote-Standorte über gemeinsame Transportwege bereitgestellt werden sollen, ist es aber weiterhin ausgesprochen leistungsfähig.

Entscheidend ist nicht das Label im Paket.

Entscheidend ist, was die Architektur ermöglicht:

• klare Mandantentrennung
• kontrollierte Routingdomänen
• redundante Dienste über mehrere Rechenzentren
• zentrale und nachvollziehbare Routingpolicies
• Erweiterung des Netzes ohne Umbau aller Bestandsdienste
• Kombination aus Carrierleitungen, eigenem Backbone und verschlüsselten Internetpfaden
• Fehlerbegrenzung durch getrennte Rollen und VRFs
• nachvollziehbare Zuständigkeiten innerhalb des Netzes

MPLS ist für uns dabei kein Gegenmodell zu SD-WAN.

MPLS bildet den kontrollierten Service- und Transport-Layer im Core.

SD-WAN erweitert diesen Core flexibel bis an Standorte, an denen kein nativer MPLS-Zugang verfügbar oder wirtschaftlich sinnvoll ist.

Die Kombination aus beiden Technologien ermöglicht uns, denselben logisch getrennten Dienst über völlig unterschiedliche Zugangswege bereitzustellen.

Ja, wir betreiben ein ISP-Netz mit MikroTik.

Mit OSPF, LDP, MPLS, MP-BGP, VPNv4, VPLS, mehreren Rechenzentren, redundanten Route Reflectors, vollständigen Internettabellen, PPPoE, L2TP, Peering und IP-Transit.

Und ja: Es läuft.

Nicht, weil MikroTik magisch wäre.

Und auch nicht, weil RouterOS keine Schwächen hätte.

Es läuft, weil die Router klare Rollen haben, die Routingdomänen voneinander getrennt sind und wir Fehler nicht nur anhand grüner Interfaces bewerten.

Es läuft, weil wir Konfigurationen hinterfragen, Fehler analysieren und die Architektur kontinuierlich weiterentwickeln.

Und es läuft, weil wir akzeptiert haben, dass Redundanz, Skalierung und Stabilität nicht durch den Kauf eines bestimmten Logos entstehen.

Sie entstehen durch Design.

MPLS ist nicht tot.

Schlecht geplante, starre und intransparente Netze sind es vielleicht.

Eine sauber aufgebaute MPLS-Infrastruktur ist dagegen vor allem eines:

Ein sehr präzises Werkzeug zur Kontrolle von Routing, Diensten und Fehlerdomänen.