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.
TR7 implementiert eine Multi-Netzwerkdomänen-Architektur durch Route-Table-Isolation, Cross-Domain-Routing, pro-Table-Prozessmanagement und UI-gesteuerten Lebenszyklus.
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 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.
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.
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.
Multi-Namespace-Architektur macht verschiedene Netzwerkdomänen auf einem einzigen ADC verwaltbar — von der Tenant-Isolation bis zum Cross-Service-Routing.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Multi-Route-Table-Architektur wird mit vollständigem Lebenszyklusmanagement, Interface-Migration, Prozess-Recovery, pro-Table-DNS/Hosts und Cross-Domain-Zustandskoordination betrieben.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ü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.