F5-Routendomains und MPLS-VRFs: die Tenant-Übergabe zuordnen
Zwei Tenants, eine Adresse, zwei Routendomains. Fixieren Sie jedes Objekt mit %ID, nutzen Sie VRF und Route-Targets des Providers und prüfen Sie jeden Tenant separat.
Zwei Tenants betreiben dieselbe Anwendung unter 10.50.0.10. Der Provider hält sie in getrennten MPLS-VPNs auseinander, und die BIG-IP hält ihren lokalen Verkehr in getrennten Routendomains. Diese Anordnung funktioniert bis zur Übergabe, wo ein fehlendes Suffix oder ein kopiertes Route-Target still das Paket des einen Tenants in den Kontext des anderen legt. Dieses Runbook verbindet beide Modelle und endet mit einem Test pro Tenant.
Arbeitsblatt: eine Zeile pro Tenant
Füllen Sie es aus, bevor Sie etwas ändern. Jeder spätere Schritt verweist auf eine Zelle darin, und eine leere Zelle ist eine Entscheidung, die noch niemand getroffen hat.
| Tenant | BIG-IP side | Provider side |
|---|---|---|
| A | VLAN or tunnel, route domain, self address, virtual server | VRF, attachment, route targets for import and export |
| B | Separate VLAN or tunnel, separate route domain, separate self address | Separate VRF, separate route targets |
Schritt 1: jedes Objekt an seine Routendomain binden
Die Routendomain-Dokumentation von F5 beschreibt isolierte Verkehrskontexte, doppelte Adressen und die address%ID-Notation für Konfigurationsobjekte. Eine Adresse in der Form 10.50.0.10%2 benennt den lokalen Routendomain-Kontext, und dieses Suffix ist kein MPLS-Label, das im IP-Paket des Kunden mitgeführt wird.
Ein VLAN oder ein unterstützter Tunnel gehört im dokumentierten Modell zu genau einer Routendomain, also müssen Interface und Adresse übereinstimmen. Prüfen Sie auch die Standard-Routendomain der administrativen Partition, denn ein weggelassenes Suffix bedeutet nicht keinen Kontext; es bedeutet den Kontext, den die Partition standardmäßig verwendet. Dieser eine Standard erklärt die meisten Vorfälle, bei denen ein neues Objekt still im falschen Tenant antwortete. Prüfen Sie ihn, bevor Sie eine eigene Adresse hinzufügen.
tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vsSchritt 2: VRF und Route-Targets des Providers nutzen
Am MPLS-Rand wird der Tenant durch die VRF des Providers und den vereinbarten Kunden-Routingdienst identifiziert. Route-Targets steuern, welche Routen der Provider zwischen VRFs importiert und exportiert, und die Wahl einer ähnlich aussehenden BIG-IP-Routendomain-Nummer erzeugt nichts von dieser Beziehung.
Die beiden Kennungen leben in verschiedenen Systemen und bedeuten verschiedene Dinge. Eine Routendomain-ID ist ein lokaler Kontext auf dem Gerät. Ein Route-Target ist ein Policy-Attribut auf der Providerseite, das die Routenverteilung entscheidet, und ein Route Distinguisher ist noch eine dritte Sache, die dazu dient, ansonsten identische Präfixe getrennt zu halten.
Schritt 3: entscheiden, ob Kontexte Erreichbarkeit teilen dürfen
Prüfen Sie die Einstellungen für Parent-Domain-Lookup und strikte Isolation bewusst, denn sie ändern, was ein Kontext erreichen kann. Der F5-Leitfaden erlaubt kontrollierte Weiterleitung über diese Beziehungen, und genau deshalb sollte eine Routendomain nicht für sich allein als vollständige Tenant-Sicherheitsrichtlinie gelten.
Wenn beide Tenants einen gemeinsamen Dienst brauchen, geben Sie den freigegebenen Pfad und die Berechtigungen an, statt einen Tenant einfach auf den Routingkontext des anderen zu zeigen. Bewahren Sie die Anwendungsidentität und jede beabsichtigte Quellübersetzung zusammen mit dem Netzwerkziel, sonst sieht der gemeinsame Dienst den einen Tenant als den anderen.
Eine gewöhnliche geroutete Übergabe verbindet die BIG-IP mit einem Provider-Edge-Router, ohne die BIG-IP zu einem MPLS-PE zu machen. Wenn eine direkte MPLS- oder VPN-Routenfamilien-Integration wirklich erforderlich ist, holen Sie sich ausdrückliche Unterstützung für die genaue Plattform und Version, denn lokale Routendomain-Isolation begründet diese Fähigkeit nicht.
Schritt 4: jeweils einen Tenant prüfen
Testen Sie Tenant A von einem Endpunkt im Kontext von A zur Anwendungsadresse von A und wiederholen Sie das dann für B. Verwenden Sie in der Diagnose die Form %ID, damit Sie belegen können, welcher Kontext geantwortet hat, und bestätigen Sie, dass eine Anfrage aus dem falschen Kontext fehlschlägt, statt irgendwo plausibel zu landen.
Prüfen Sie die Providerseite im selben Durchgang: Das Präfix ist in der richtigen VRF vorhanden, die Route-Targets stimmen mit dem Arbeitsblatt überein, und der Rückweg nutzt die vorgesehene Anbindung. Ein Ping, der vom Gerät selbst funktioniert, belegt den Kontext des Geräts, nicht den des Tenants.
Halten Sie die endgültige Zuordnung im Arbeitsblatt fest, einschließlich der Standard-Routendomain jeder Partition und jeder aktivierten Parent-Domain-Beziehung. Die nächste Änderung an dieser Umgebung wird jemand vornehmen, der diese Tabelle liest, nicht jemand, der diesen Artikel liest.