Das klassische ADC-Routing-Modell ist für Multi-Tenant-Netzwerke unzureichend.
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.
Unser Ansatz
TR7 hebt Routing aus einer globalen Tabelle heraus — jede Netzwerkzone lebt in ihrer eigenen unabhängigen Route-Table.
TR7-Route-Table-Isolation
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.
Statisches und dynamisches Routing zusammen
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.
Policy-based Routing
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.
Gateway-Monitor und automatisches Failover
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.
Fähigkeiten
Das TR7-Route-Table-Modell vereint alle Routing-Fähigkeiten, die für Multi-Tenant-Bereitstellungen und komplexe Netzwerktopologien erforderlich sind.
Pro-Route-Table unabhängiges Routing
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.
Route Health Injection — die Adresse wird nur angekündigt, solange der Dienst gesund ist
Die Dienstadresse wird nur in BGP oder OSPF angekündigt, solange die dahinterliegenden Dienste ihre Health-Checks bestehen, und binnen Sekunden zurückgezogen, wenn nicht. Vorgelagerte Router hören auf, Verkehr an einen Standort zu senden, der ihn nicht bedienen kann — ohne dass jemand ein Ticket öffnet. Nur der Knoten, der die Adresse tatsächlich hält, kündigt sie an; genau das verhindert, dass ein Cluster-Failover zum Routing-Blackhole wird. BFD drückt die Fehlererkennung unter eine Sekunde.
Statisches Routen-Management
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.
Gateway-on-Link-Unterstützung
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.
Dynamische Routing-Protokoll-Infrastruktur
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. Dynamisches Routing wird je Adressfamilie genannt, denn es sind zwei Protokolle und nicht eines: OSPFv2 trägt IPv4, OSPFv3 trägt IPv6 — so geht einem Dual-Stack-Netz mitten in der IPv6-Migration nicht das Routing aus.
Nachbarn in Formularen, Rohkonfiguration und Konsole bleiben Ihnen
BGP-Peers und OSPF-Areas werden in der Oberfläche als Formulare definiert — Router-Adresse, AS-Nummern, Authentifizierung, eine BFD-Checkbox, die die Fehlererkennung unter eine Sekunde drückt, und ein Schalter "diese Adresse ankündigen", der Route Health Injection einschaltet — und TR7 erzeugt daraus die Routing-Konfiguration. Tiefergehende Protokollarbeit bleibt offen: Ein Rohkonfigurationsfeld wird an das Erzeugte angehängt und nie überschrieben, und die Protokollkonsole bleibt zum Lesen von Zuständen und zum Debuggen in der Sprache des Protokolls.
Policy-based Routing
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.
Gateway-Monitor
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.
Default-Gateway-Failover
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.
Next-Hop-Lastverteilung (NHLD)
Ausgehender Verkehr wird auf mehrere vorgelagerte Gateways verteilt, mit Zustandsüberwachung je Leitung. Eine ausgefallene Leitung wird binnen Sekunden zurückgezogen, und die Verbindungsmarkierung hält einen bestehenden Fluss auf der Leitung, auf der er begonnen hat. So bleibt der Rückverkehr symmetrisch und zustandsbehaftete Geräte davor sehen nie nur die Hälfte einer Verbindung. Das ist die Multi-WAN-Antwort für Standorte mit zwei oder mehr Internetanbietern.
Delta-Routen-Sync
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.
IPv4- und IPv6-Routen-Unterstützung
TR7 kann IPv4- und IPv6-Routenstrukturen separat verwalten. In Dual-Stack-Umgebungen betreiben beide IP-Familien gemeinsam unter demselben Route-Table-Modell.
Pro-Route-Table-DNS und Hosts-Management
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.
Cluster-bewusstes Routing-Verhalten
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.
Cross-Route-Table-Service-Fluss via vService
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.
Statisches + dynamisches Hybrid-Routing
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.
Operative Tiefe
Das Route-Table-Modell geht über das Regelschreiben hinaus — es umfasst auch Apply-Reihenfolge, Gateway-Monitor-Schwellenwerte, dynamischen Routing-Lebenszyklus und Fehlerbehandlung.
Routen-Eintragsmodell
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.
Apply-Reihenfolge
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.
Gateway-Monitor-Schwellenwerte
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.
Dynamischer Routing-Lebenszyklus
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.
Rollback-Logik bei Routenfehlern
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- und Firewall-Beziehung
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.
Route-Table- und vService-Beziehung
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.
Peer- und Area-Definitionen unter derselben Änderungskontrolle
Peer- und Area-Definitionen durchlaufen denselben Validieren-dann-Anwenden-Ablauf wie die übrige Konfiguration, und jede Änderung landet mit Urheber im Audit-Log. Was die Formulare nicht ausdrücken — detaillierte Filterung, Route-Maps, Protokoll-Feintuning — gehört in das Rohkonfigurationsfeld; es wird mit dem Objekt gespeichert und bei jeder Neuerzeugung der Konfiguration bewahrt. Teams, die die Protokollkonsole bevorzugen, arbeiten genau wie bisher.
vDevices — virtuelle Appliances auf Hardwareniveau in einem Chassis
Eine Route Table isoliert das Routing. Ein vDevice geht weiter und isoliert die gesamte Appliance: jedes besitzt eigene Schnittstellen, eigene Firewall, eigene Routing-Tabellen, einen eigenen L4-DDoS-Schutzsatz und eigenes DNS; vDevices werden je Benutzer zugeteilt. Ein DDoS-Sturm gegen ein vDevice wird konstruktiv eingegrenzt statt durch Feintuning — genau das macht ein einzelnes Chassis als mehrere unabhängige Geräte nutzbar.
Wann einsetzen
MSP-Multi-Tenant-Routing
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.
DMZ-zu-internem-Backend-Transit
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.
Redundantes WAN und Source-based Routing
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.
BGP-Integration mit dem Rechenzentrum
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.
Den ADC einem OSPF-Bereich hinzufügen
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.
Default-Gateway-Failover
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.
Häufig gestellte Fragen
Können zwei Tenants, die denselben IP-Block verwenden, auf demselben TR7-Gerät betrieben werden?
Können statische und dynamische Routen in derselben Route-Table koexistieren?
Wird die BGP- und OSPF-Konfiguration direkt über die Oberfläche vorgenommen?
Wie funktioniert die Gateway-Überwachung und wann wird Failover ausgelöst?
Kann ein vService Traffic zu einem Backend in einer anderen Route-Table weiterleiten als der, auf der er lauscht?
Erfordert Route-Table-Isolation eine zusätzliche Lizenz?
Lässt sich ausgehender Verkehr gleichzeitig über zwei Internetleitungen verteilen?
Pro-Tenant unabhängiges Routing — von einer Konsole verwaltet
Überlappende IP-Blöcke, statisches + BGP/OSPF-dynamisches Routing und Gateway-Überwachung. Lassen Sie uns ein Live-Setup auf Ihrer eigenen Netzwerktopologie durchgehen.