Sie müssen Tenant-Netzwerke, die DMZ und interne Dienste verbinden — ohne sie in dieselbe Ebene zu kollabieren.
Eines der schwierigsten Probleme im Unternehmensnetzwerk ist die sichere Verwaltung verschiedener Netzwerkdomänen auf demselben Gerät ohne Adresskonflikte. In MSP-, Behörden-, Finanz-, Gesundheits- und Multi-Tenant-Umgebungen kann jeder Tenant seinen eigenen IP-Plan mitbringen. Die Wiederverwendung desselben CIDR-Blocks für verschiedene Kunden ist gängig.
Klassische Routentrennung isoliert in der Regel nur die Routing-Tabelle. Echte Isolation erfordert jedoch mehr als Routen — Interfaces, ARP, Firewall, Socket und Verbindungsverhalten müssen alle getrennt werden. Ohne das werden Tenant A's `10.0.0.5` und Tenant B's `10.0.0.5` auf demselben Gerät operativ und sicherheitstechnisch riskant.
Ein zweites Problem entsteht, wenn Dienste in verschiedenen Netzwerkdomänen bleiben müssen. Eine VIP sollte auf der DMZ-Seite lauschen, das Backend sollte im internen Netzwerk bleiben, Management-Traffic sollte auf seine eigene Route-Table beschränkt sein, oder alte und neue Netzwerke müssen während der Migration koexistieren. Das erzwungene Zusammenführen dieser Domänen bricht Sicherheitssegmentierung und Betriebsordnung.
Der richtige Ansatz ist, jede Netzwerkdomäne in ihrer eigenen Route-Table zu isolieren und kontrolliertes Crossing auf vService-Ebene bereitzustellen. Ein vService sollte über mehrere Route-Tables lauschen und Traffic zu Backends in verschiedenen Route-Tables weiterleiten können.
TR7 Cross-NS-Routing erfüllt diesen Bedarf: Es erstellt isolierte Netzwerkdomänen auf einem einzigen Gerät, trennt überlappende IP-Pläne und verwandelt den vService in eine kontrollierte Traffic-Brücke zwischen Route-Tables.
Unser Ansatz
TR7 implementiert eine Multi-Netzwerkdomänen-Architektur durch Route-Table-Isolation, Cross-Domain-Routing, pro-Table-Prozessmanagement und UI-gesteuerten Lebenszyklus.
TR7-Route-Tables liefern vollständige Netzwerk-Isolation
Jede Route-Table hat ihr eigenes Routing, Interfaces, ARP, Firewall und Socket-Namespace. Tenants, Servicezonen oder Testumgebungen können daher auf demselben Gerät betrieben werden, ohne sich gegenseitig zu beeinflussen.
Ein vService kann N-zu-M Cross-Route-Table-Flüsse etablieren
Ein einziger vService kann für VIPs auf mehreren Route-Tables lauschen und Traffic zu Backends in verschiedenen Route-Tables weiterleiten. Dies ermöglicht kontrollierten Service-Handoff ohne das Netzwerk zu flatten.
Jede Route-Table wird von einem dedizierten Prozess überwacht
TR7 kann für jede Route-Table einen separaten Netzwerküberwachungs- und Verwaltungsprozess betreiben. Link-Zustand, IP-Adressen, Routen, Statistiken und Dienststatus werden für jede Netzwerkdomäne unabhängig gesammelt.
Route-Table-Lebenszyklus wird aus der Oberfläche verwaltet
Operatoren können Route-Tables erstellen, löschen, benennen und DNS- sowie Hosts-Einstellungen konfigurieren. Welcher Route-Table ein Interface angehört, kann ebenfalls von der Verwaltungskonsole aus geändert werden.
Fähigkeiten
Multi-Namespace-Architektur macht verschiedene Netzwerkdomänen auf einem einzigen ADC verwaltbar — von der Tenant-Isolation bis zum Cross-Service-Routing.
Jede TR7-Route-Table ist ein eigenständiger Netzwerk-Arbeitsbereich
Eine TR7-Route-Table ist nicht nur eine separate Routenliste. Interface-, ARP-, Firewall-, Socket- und Verbindungsverhalten arbeiten alle unabhängig innerhalb der Domäne. Das Netzwerkverhalten eines Tenants kann nicht in das eines anderen bluten. Betriebsteams verwalten mehrere Netzwerkdomänen auf demselben Gerät sicherer und lesbarer.
Derselbe CIDR kann von verschiedenen Tenants ohne Konflikt verwendet werden
In Multi-Tenant-Umgebungen können verschiedene Kunden dieselben privaten IP-Blöcke verwenden. TR7-Route-Tables halten diese überlappenden Adresspläne in separaten Netzwerkdomänen. Tenant A's `10.0.0.5` und Tenant B's `10.0.0.5` können auf demselben Gerät mit unterschiedlichen Bedeutungen koexistieren. Dies gibt MSP- und Sovereign-Cloud-Architekturen erhebliche IP-Plan-Flexibilität.
Ein vService kann für VIPs auf mehreren Route-Tables lauschen
Das vService-Frontend ist nicht auf eine einzige Netzwerkdomäne beschränkt. Derselbe Dienst kann auf verschiedenen VIPs über Prod-, DMZ-, Management- oder Tenant-Route-Tables lauschen. Je nachdem, von welcher Route-Table der Client kommt, kann eine andere Richtlinie oder Backend-Auswahl gelten. Dieses Modell vereinfacht Multi-Netzwerk-Publishing-Szenarien ohne Dienstinstanzen zu duplizieren.
Traffic kann zu Backends in verschiedenen Route-Tables weitergeleitet werden
TR7 kann Traffic, der auf einer Route-Table eintrifft, zu einem Backend in einer anderen Route-Table weiterleiten. Die VIP kann in der DMZ bleiben, während das Backend im internen Netzwerk bleibt; das Tenant-Netzwerk kann separat bleiben, während das Shared-Service-Netzwerk in seiner eigenen Route-Table lebt. Nur erlaubte Service-Flüsse passieren TR7 — die Netzwerke werden nie zusammengeführt. Segmentierung bleibt erhalten, während der Anwendungszugriff vereinfacht wird.
Interfaces können kontrolliert zwischen Route-Tables verschoben werden
Welcher Route-Table ein physisches oder virtuelles Interface angehört, kann von TR7 aus verwaltet werden. Dies ist praktisch bei Migration, Tenant-Umzügen oder Test-zu-Produktion-Übergängen. Die Auswirkung auf Routen, IPs und Dienste beim Verschieben eines Interfaces sollte vollständig bewertet werden. Betriebsteams müssen Netzwerkdomänen nicht als statische, unbewegliche Strukturen behandeln.
V-ETH(peer) bietet eine kontrollierte Verbindung zwischen Route-Tables
Ein V-ETH(peer)-Paar kann verwendet werden, um eine kontrollierte virtuelle Verbindung zwischen zwei verschiedenen Route-Tables herzustellen. Dies ist wertvoll, wenn nur bestimmte, definierte Traffic-Pfade zwischen sonst vollständig isolierten Domänen kreuzen müssen. Anwendbar für Test, Migration, Service-Sharing und Tenant-Shared-Service-Zugriff. Die Verbindung wird weiterhin durch TR7-Richtlinien und Firewall-Regeln geregelt.
DNS- und Hosts-Einstellungen werden pro Route-Table getrennt
Jede Route-Table kann mit ihren eigenen DNS- und Hosts-Einträgen betrieben werden. Derselbe Hostname kann in verschiedenen Tenant-Route-Tables zu einer anderen IP aufgelöst werden, oder eine Testumgebung kann eine andere Namensauflösung als die Produktion verwenden. Diese Trennung reduziert Hostname-Konflikte in Multi-Tenant-Umgebungen und Migrationsszenarien. Operatoren verwalten DNS-Verhalten auf Netzwerkdomänen-Ebene, nicht global.
Dynamische Routing-Prozesse werden pro Route-Table getrennt
Jede dynamische Route-Table kann ihren eigenen Routing-Prozess betreiben. BGP, OSPF oder ähnliches dynamisches Routing-Verhalten kann pro Tenant oder Netzwerkdomäne isoliert werden. Eine Routenänderung in der Domäne eines Tenants beeinflusst nicht die Routing-Ebene eines anderen Tenants. Dies ist ein erheblicher Sicherheits- und Betriebsvorteil in MSP- und Multi-Region-Unternehmensarchitekturen.
Firewall- und ipset-Verhalten ist in jeder Route-Table unabhängig
TR7 kann für jede Route-Table separate Firewall-Verwaltung anwenden. Regeln, ipsets und Traffic-Berechtigungen arbeiten innerhalb der relevanten Netzwerkdomäne. Ein für einen Tenant geöffneter Port oder eine gewährte Berechtigung wird nicht automatisch auf die Dienste eines anderen Tenants übertragen. Sicherheitsteams können den Richtlinienumfang präziser definieren.
Pro-Route-Table-Statistiken und Zustandsüberwachung
Link-, IP-, Routen- und Traffic-Statistiken können für jede Route-Table separat gesammelt werden. Betriebsteams können sehen, welcher Link, welche IP oder welche Route in welcher Netzwerkdomäne ein Problem verursacht — isoliert voneinander. Diese Sichtbarkeit reduziert die Troubleshooting-Zeit in Multi-Domänen-Umgebungen. Auf einem einzigen Gerät betriebene Umgebungen werden in klar getrennten Ansichten überwacht.
Cross-NS-Health-Checks verifizieren den echten Zugriffspfad
Ein Health-Check kann nicht nur verifizieren, ob das Backend aktiv ist, sondern auch ob es von der relevanten Route-Table aus erreichbar ist. Ein Check, der von der Frontend-Netzwerkdomäne zu einem Backend in einer anderen Route-Table ausgestellt wird, durchläuft den echten Traffic-Pfad — Routen-, ARP- und Firewall-Traversierung, nicht nur Dienstverfügbarkeit werden validiert. Dies liefert kritisches operatives Vertrauen bei Cross-Netzwerk-Routing-Setups.
Route-Table-Modell verhält sich nicht wie ein separat lizenziertes Tenant-Produkt
Multi-Route-Table-Verhalten ist ein nativer Teil von TR7s Netzwerkarchitektur. Operatoren müssen kein separates virtuelles Gerät pro Tenant bereitstellen. Isolation, Routing und Service-Handoff auf demselben ADC bleiben alle innerhalb einer einzigen Management-Ebene. Dies reduziert sowohl den Ressourcenverbrauch als auch die Betriebskomplexität.
Operative Tiefe
Multi-Route-Table-Architektur wird mit vollständigem Lebenszyklusmanagement, Interface-Migration, Prozess-Recovery, pro-Table-DNS/Hosts und Cross-Domain-Zustandskoordination betrieben.
Route-Table-Erstellung
Wenn ein Operator eine neue Route-Table erstellt, bereitet TR7 einen separaten Ausführungskontext für diese Netzwerkdomäne vor. Diese Domäne trägt ihr eigenes Interface-, Routen- und Firewall-Verhalten. Name- und Beschreibungsfelder helfen Betriebsteams dabei, Tenants oder Servicezonen voneinander zu unterscheiden.
Sicheres Löschverhalten
Das Löschen einer Route-Table, der noch Interfaces zugewiesen sind, wird als unsicher behandelt. Das Standard-Verhalten blockiert das Löschen, bis Interfaces migriert wurden. Falls erforderlich, können Interfaces zuerst in die Standard-Domäne zurückgezogen werden, wodurch das Löschen kontrolliert und explizit wird.
Prozess-Crash-Recovery
Wenn der Überwachungs- und Verwaltungsprozess für eine Route-Table unerwartet beendet wird, kann er automatisch neu gestartet werden. Dies bewahrt die Kontinuität des Multi-Domänen-Überwachungsverhaltens. Betriebsteams verlieren die Sichtbarkeit einer Netzwerkdomäne nicht dauerhaft aufgrund eines einzelnen Prozessfehlers.
Interface-Migrations-Auswirkung
Wenn ein Interface von einer Route-Table zu einer anderen verschoben wird, müssen die Auswirkungen auf IPs, Routen, Dienste und Firewall-Regeln zusammen bewertet werden. Die Operation ist für Migrationszwecke mächtig, sollte aber in Produktionsumgebungen geplant werden. TR7 macht dieses Verhalten in der Oberfläche sichtbar und reduziert das Risiko unbeabsichtigter Verschiebungen.
Route-Table-Interprozess-Kommunikation
Ereignisbasiertes Messaging kann zwischen dem Haupt-Management-Prozess und jedem Route-Table-Prozess etabliert werden. Link-Zustand, IP-Zustand, GTM-Informationen und Dienstsignale werden separat an jede Netzwerkdomäne geliefert. Dies bietet kontrollierte Koordination zwischen globalem Management und isolierten Netzwerkdomänen.
Route-Table-Indizierung
Jedem Route-Table kann ein Indexwert zugewiesen werden. Dieser Index wird verwendet, um dynamische Routing-Ports, Virtual-Router-ID-Offsets und pro-Service-Hilfsprozess-IDs abzuleiten. Port- und Identitätskonflikte über mehrere Netzwerkdomänen werden dadurch reduziert.
Wann einsetzen
Überlappende Tenant-CIDRs in einer MSP-Umgebung trennen
Ein MSP kann mehrere Kunden, die alle den `10.0.0.0/8`-Adressblock verwenden, auf einem einzigen TR7 ADC in jeweils eigenen Route-Tables betreiben. Jeder Tenant bleibt in seiner eigenen Netzwerkdomäne isoliert — ohne IP-Konflikte.
DMZ-VIP zu internem-Netzwerk-Backend-Handoff
Organisationen können die VIP in der DMZ-Route-Table lauschen lassen, während das Backend in der internen Route-Table bleibt. TR7 trägt nur den erlaubten Service-Traffic zwischen den beiden Domänen — ohne sie zusammenzuführen.
Kontrollierte Traffic-Migration zwischen Tenant-Route-Tables
Wenn ein Dienst von einem alten Tenant-Netzwerk zu einer neuen Route-Table verschoben wird, kann vService-Traffic kontrolliert umgeleitet werden. IP-Plan und Service-Zugriff werden während der gesamten Migration gemeinsam verwaltet.
Test- und Staging-Netzwerke von der Produktion isolieren
Eine Test-Route-Table kann mit produktionsähnlichen Einstellungen betrieben werden, hat aber keinen direkten Zugriff auf Produktions-Traffic. Das Betriebsteam kann bestimmte Dienste bei Bedarf über Cross-Route-Table-Routing testen und dabei die Isolation wahren.
Häufig gestellte Fragen
Wie unterscheidet sich eine TR7-Route-Table von einem klassischen VRF?
Kann derselbe CIDR-Block wirklich in verschiedenen Tenant-Route-Tables ohne Konflikt betrieben werden?
Über wie viele Route-Tables kann ein einziger vService lauschen?
Warum wird ein separater Überwachungsprozess für jede Route-Table betrieben?
Wann sollte V-ETH(peer) verwendet werden?
Erfordert diese Fähigkeit eine zusätzliche Lizenz oder ein separates Tenant-Modul?
Tenant-Isolation und Cross-Service-Routing — ohne Netzwerke zusammenzuführen
Überlappende IP-Pläne, DMZ-zu-internes-Routing und Multi-Tenant-Route-Table-Architektur. Lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.