In klassischen ADC-Produkten basiert das Routen-Management typischerweise auf einer einzigen globalen Tabelle. Das ist bei kleinen Bereitstellungen ausreichend, aber es stößt schnell an seine Grenzen bei Multi-Tenant-, Multi-Abteilungs-, MSP-, Behördennetzwerk-, DMZ/intern-Trennungs- oder Rechenzentrum-Migrations-Szenarien.
Das erste Problem ist IP-Überlappung. Verschiedene Kunden, Abteilungen oder Umgebungen können dieselben privaten IP-Blöcke verwenden. Dass zwei separate Tenants beide auf 10.0.0.0/8 sind, ist in der Praxis sehr häufig. Eine einzige globale Route-Table kann diese zwei Netzwerke auf demselben Gerät nicht sauber trennen.
Das zweite Problem ist die Aufspaltung zwischen statischem und dynamischem Routing auf separate Geräte. Wenn ein Router Routen via BGP/OSPF lernt, während der ADC seine eigene statische Tabelle konsultiert, liegt die Hälfte der Traffic-Entscheidung auf einem Gerät und die andere Hälfte auf einem anderen. Das verlängert das Debugging erheblich — ob der ADC korrekt weiterleitet, ob der Router die richtige Route gelernt hat und woher der Rückgabepfad kommt, müssen alle separat untersucht werden.
Das dritte Problem ist die Default-Gateway-Abhängigkeit. Ein Gateway kann physisch aktiv erscheinen, während es nicht in der Lage ist, Upstream zu erreichen. Das klassische Setup erkennt das nicht; Traffic wird weiterhin zu einem Gateway gesendet, das gesund aussieht, aber tatsächlich unerreichbar ist.
Das vierte Problem ist der Bedarf an Source-based oder Policy-based Routing. Einiger Traffic muss über WAN1 gehen, einiger über einen VPN-Tunnel, einiger Tenant-Traffic über einen dedizierten MPLS-Link, und einige Dienste über den Internet-Ausgang. Wenn ein ADC das nur mit einer globalen Route-Table verwaltet, ist der Operator auf CLI, Skripte oder einen externen Router angewiesen.
TR7 ADC stellt das Route-Table-Modell in den Kern des ADC: Jeder Tenant und jede Netzwerkzone trifft seine eigenen Routing-Entscheidungen; statische Routen, dynamische Routen, Gateway-Überwachung und Service-Flüsse werden alle von einer einzigen Konsole verwaltet.
TR7 hebt Routing aus einer globalen Tabelle heraus — jede Netzwerkzone lebt in ihrer eigenen unabhängigen Route-Table.
In TR7 ist eine Route-Table nicht nur eine Liste von Routen. Es ist ein separater Netzwerkkontext, der bestimmt, von welchem Interface Traffic eintrifft, zu welchem Gateway er weitergeleitet wird, durch welche Sicherheitsregeln er passiert und welches Backend er erreicht. Dieses Modell ermöglicht mehreren unabhängigen Netzwerkzonen, auf demselben Gerät zu betreiben, jede mit ihrem eigenen IP-Plan, Gateway, statischen Routen und dynamischem Routing-Verhalten.
Statische Routen können über die TR7-Oberfläche definiert werden, indem das Zielnetzwerk, Gateway, Interface und Metric ausgewählt werden. In fortgeschritteneren Bereitstellungen können dynamische Routing-Protokolle wie BGP, OSPF, RIP und IS-IS ebenfalls im selben Route-Table-Kontext betrieben werden. Management-Traffic kann über statische Routen fixiert werden, während Produktions-Traffic dynamisch erlernten Pfaden folgt — beides innerhalb desselben Geräts, desselben Governance-Modells und derselben Betriebsansicht.
TR7 unterstützt das Lenken von Traffic nicht nur nach Ziel-IP, sondern auch nach Richtliniensignalen. Ein bestimmter vService-Fluss kann zu einem redundanten WAN gehen, der Traffic eines bestimmten Tenants kann zu einem dedizierten Link geleitet werden, und ein markierter Fluss kann auf eine andere Route-Table gelegt werden. Dies ist besonders wertvoll für redundante WAN-, Active/Active-Internet-Ausgang-, pro-Tenant-Link-Trennung-, pro-Service-Routenauswahl- und Inline-Transit-Szenarien.
TR7 kann verfolgen, ob ein Default-Gateway wirklich erreichbar ist. Nach einer konfigurierten Anzahl fehlgeschlagener Checks wird das Gateway als ungesund markiert und eine alternative Route oder ein alternatives Gateway kann aktiviert werden. Dies ist kritisch für das Erkennen des Szenarios, bei dem das Gateway aktiv ist, aber der Upstream ausgefallen ist. Traffic wird nie ins Leere gesendet — TR7 entscheidet auf Basis der tatsächlichen Erreichbarkeit.
Das TR7-Route-Table-Modell vereint alle Routing-Fähigkeiten, die für Multi-Tenant-Bereitstellungen und komplexe Netzwerktopologien erforderlich sind.
Jede TR7-Route-Table trifft ihre eigenen Routing-Entscheidungen. Dieselben IP-Blöcke können in verschiedenen Route-Tables ohne Konflikt verwendet werden. Dies bietet die grundlegende Isolation, die für MSP-, SaaS-, Behörden-, Finanz- und Multi-Kunden-Umgebungen erforderlich ist.
Operatoren definieren das Zielnetzwerk, Gateway, Metric und Interface direkt aus der Oberfläche. Statische Routen werden hauptsächlich für Management-Netzwerke, dedizierte Links, redundante Pfade, DMZ/intern-Trennung und spezifische Backend-Segmente verwendet.
In einigen WAN- oder Point-to-Point-Konfigurationen erscheint die Gateway-IP möglicherweise nicht im selben Subnetz. TR7 unterstützt Gateway-on-Link-Verhalten für solche Verbindungen und reduziert den Bedarf an zusätzlichen manuellen Schritten bei dedizierten WAN-, Tunnel- oder Service-Provider-Links.
TR7 bietet eine Infrastruktur, die dynamische Routing-Protokolle für fortgeschrittene Netzwerkteams betreiben kann. BGP, OSPF, RIP, IS-IS und ähnliche Protokolle können im Route-Table-Kontext verwendet werden. Dies macht den ADC zu einem aktiven Routing-Teilnehmer im Rechenzentrum oder Tenant-Netzwerk, anstatt zu einem passiven Gerät, das nur statische Routen versteht.
Eine dedizierte Konsole, die mit der Route-Table verbunden ist, steht für erweitertes Befehls- und Protokollmanagement auf der dynamischen Routing-Seite zur Verfügung. Neighbor-Definitionen, Routeninspektion, Protokollzustand und detailliertes Debugging werden von fortgeschrittenen Benutzern über diese Schnittstelle durchgeführt. Die Core-Routing-Infrastruktur und Konsolenzugriff sind vorhanden; ein vollständig formularbasierter GUI-Editor für das gesamte BGP/OSPF-Neighbor-Management ist ein separater Roadmap-Bereich.
TR7 ermöglicht es, spezifischen Traffic auf unterschiedliches Routing-Verhalten zu legen. Dies wird für pro-Service-, pro-Tenant- oder pro-markiertem-Fluss-Routenauswahl verwendet. Management-Traffic kann über ein statisches Gateway ausgehen, während Produktions-Traffic dynamischen Routen folgt; bestimmter Tenant-Traffic kann auf einen VPN-Link gelegt werden, während bestimmter VIP-Traffic zu einem redundanten WAN geleitet wird.
Das Default-Gateway wird in regelmäßigen Abständen überprüft. Wenn Fehler den konfigurierten Schwellenwert überschreiten, wird die Route als ungesund markiert. Ein alternatives Gateway oder eine alternative Route kann dann aktiviert werden. Diese Fähigkeit schaut auf tatsächliche Gateway-Erreichbarkeit, nicht nur auf den Link-Zustand.
Wenn das primäre Gateway ausfällt, kann ein Übergang zu einem sekundären Gateway erfolgen. Dies wird für Internet-Ausgang-Redundanz, WAN-Failover, MPLS-Backup, VPN-Backup und redundante Intra-Rechenzentrum-Gateway-Szenarien verwendet.
TR7 spielt nicht bei jeder Änderung die gesamte Routing-Struktur neu ab. Hinzugefügte, bearbeitete und gelöschte Routen werden differenziert und nur die geänderten Routen werden angewendet. Dieser Ansatz reduziert das Risiko auf Live-Systemen und ermöglicht es, Änderungen schneller wirksam zu machen.
TR7 kann IPv4- und IPv6-Routenstrukturen separat verwalten. In Dual-Stack-Umgebungen betreiben beide IP-Familien gemeinsam unter demselben Route-Table-Modell.
Jede Route-Table kann ihre eigenen Namensauflösungseinstellungen haben. Dies ist nützlich für pro-Tenant-DNS, private interne Resolver, isolierte Testumgebungen und verschiedene interne Domain-Szenarien.
In HA-Cluster-Szenarien ist wichtig, welches Gerät die aktive VIP hält, für die Routenanwendung. TR7 verwaltet die Routenanwendung entsprechend der Active-Device-Logik im Einklang mit der verwendeten VIP-Übergangsmethode: Only VRRP, TR7 link check, TR7 gateway check und TR7 link and gateway check.
Ein vService kann auf einer Route-Table lauschen und Traffic zu Backends in einer anderen Route-Table weiterleiten. Beispiel: Eingehender Internet-Traffic wird auf der DMZ-Route-Table empfangen und kontrolliert an das Backend in der internen Route-Table weitergeleitet. Dasselbe Gerät wird zu einem kontrollierten Transitpunkt zwischen Netzwerkzonen.
Management-Routen können fixiert bleiben, während Produktions-Traffic dynamisch erlernten Routen folgt. Metric-Werte setzen Priorität. Der Operator sichert kritische Pfade als statisch und delegiert variable Netzwerksegmente an dynamische Protokolle.
Das Route-Table-Modell geht über das Regelschreiben hinaus — es umfasst auch Apply-Reihenfolge, Gateway-Monitor-Schwellenwerte, dynamischen Routing-Lebenszyklus und Fehlerbehandlung.
Jede Route wird durch die folgenden Kernfelder definiert: Zielnetzwerk, Gateway, Interface, Metric, Gateway-on-Link-Verhalten und die zugehörige Route-Table. Diese Struktur ist sowohl für einfache statische Routen als auch für komplexe Multi-Gateway-Szenarien ausreichend.
Die Routenanwendung hängt vom Interface- und IP-Zustand ab. TR7 wendet zuerst Interface- und IP-seitige Änderungen an, dann aktiviert es Routenänderungen. Diese Reihenfolge eliminiert eine Fehlerklasse, bei der eine Route vorhanden, aber das Interface noch nicht bereit ist.
Der Gateway-Monitor überprüft in definierten Intervallen. Nach einer Anzahl aufeinanderfolgender Fehler wird das Gateway als ungesund betrachtet; nach einer Anzahl aufeinanderfolgender Erfolge wird es wieder als gesund betrachtet. Dieser Rise/Fall-Ansatz verhindert, dass vorübergehende Schwankungen Route-Flaps auslösen.
Die dynamische Routing-Infrastruktur läuft innerhalb des Route-Table-Kontexts. Die relevanten Protokolldienste werden gestartet, Konfigurationsdateien werden generiert, die Protokollkonsole wird vorbereitet und der Routenlernprozess wird an die relevante Route-Table gebunden.
Wenn eine Route nicht angewendet werden kann, bewertet TR7 den Fehler isoliert. Erfolgreich angewendete Routen bleiben erhalten und der Fehler für die problematische Route wird sichtbar gemacht. Dies verhindert, dass eine einzelne fehlerhafte Route die gesamte Routing-Struktur korrumpiert.
Route-Table-Isolation erhält volle Bedeutung in Kombination mit Firewall-Isolation. Die Routen eines Tenants vermischen sich nie mit den Firewall-Regeln eines anderen Tenants. Traffic traversiert nicht nur die korrekte Route-Table — er passiert auch die korrekte Sicherheitsrichtlinie.
Eine vService-Frontend-IP kann innerhalb einer bestimmten Route-Table lauschen. Die Backend-Seite kann über eine andere Route-Table erreicht werden. Dies transformiert den ADC von einem Gerät, das eingehenden Traffic einfach zu einem nahe gelegenen Backend weiterleitet, zu einem kontrollierten Service-Gateway zwischen Netzwerkzonen.
Die dynamische Routing-Engine und der Konsolenzugriff sind vorhanden. Das vollständige Verwalten aller Neighbors, Filter, Prefix-Lists und Route-Maps über einen formularbasierten GUI ist jedoch ein separater Roadmap-Bereich. Fortgeschrittene Netzwerkteams führen das detaillierte Management über die Protokollkonsole durch.
Ein MSP betreibt viele Kunden auf demselben TR7-Gerät. Kunde A und Kunde B verwenden dieselben IP-Blöcke. Jeder Kunde ist in seiner eigenen TR7-Route-Table isoliert; Routen, DNS, Firewall-Regeln und Service-Flüsse kollidieren nie.
Internet-Traffic wird auf der DMZ-Route-Table empfangen. Nachdem TR7 WAAP und Zugriffsrichtlinien angewendet hat, wird der Traffic zum Backend in der internen Route-Table weitergeleitet. Der Backend-IP-Plan wird nie der Außenwelt exponiert.
Einige Dienste gehen über das primäre WAN, einige Tenants über ein redundantes WAN und einige Management-Dienste über einen dedizierten Link. TR7 Policy-based Routing wählt einen anderen Pfad für jede Traffic-Klasse.
TR7 kann Routen dynamisch von Edge-Routern erlernen. Wenn neue Netzwerksegmente hinzugefügt werden, müssen statische Routen nicht mehr manuell geschrieben werden. Das Netzwerkteam kündigt die Routen an und TR7 verwendet die aktuellen Pfade in der relevanten Route-Table.
Wenn das bestehende interne Netzwerk mit OSPF betrieben wird, kann TR7 dieser Topologie innerhalb der relevanten Route-Table beitreten. Interne Service-Netzwerke werden automatisch erlernt und das Routen-Management wird zentralisiert.
Das primäre Gateway wird unerreichbar. Der Gateway-Monitor erkennt den Ausfall und der Traffic wird zum alternativen Gateway verschoben. Der Operator muss keine manuellen Routenänderungen vornehmen.
Überlappende IP-Blöcke, statisches + BGP/OSPF-dynamisches Routing und Gateway-Überwachung. Lassen Sie uns ein Live-Setup auf Ihrer eigenen Netzwerktopologie durchgehen.