Le modèle de routage ADC classique est inadéquat pour les réseaux multi-tenant.
Dans les produits ADC classiques, la gestion des routes repose généralement sur une seule table globale. C'est suffisant pour les petits déploiements, mais cela atteint rapidement ses limites dans les scénarios multi-tenant, multi-département, MSP, réseau gouvernemental, séparation DMZ/interne ou migration de data center.
Le premier problème est le chevauchement des IP. Différents clients, départements ou environnements peuvent utiliser les mêmes blocs IP privés. Avoir deux tenants distincts tous deux sur 10.0.0.0/8 est très courant dans la réalité. Une seule table de routage globale ne peut pas séparer proprement ces deux réseaux sur le même appareil.
Le deuxième problème est la séparation entre le routage statique et dynamique sur des appareils distincts. Si un routeur apprend les routes via BGP/OSPF tandis que l'ADC consulte sa propre table statique, la moitié de la décision de trafic vit sur un appareil et l'autre moitié sur un autre. Cela allonge significativement le débogage — si l'ADC transfère correctement, si le routeur a appris la bonne route, et d'où vient le chemin de retour doivent tous être investigués séparément.
Le troisième problème est la dépendance à la passerelle par défaut. Une passerelle peut sembler physiquement disponible tout en étant incapable d'atteindre le réseau en amont. La configuration classique ne détecte pas cela ; le trafic continue d'être envoyé vers une passerelle qui semble saine mais qui est en réalité injoignable.
Le quatrième problème est le besoin de routage source-based ou policy-based. Certains trafics doivent passer par WAN1, d'autres via un tunnel VPN, certains trafics tenant via un lien MPLS dédié, et certains services via la sortie internet. Si un ADC gère cela avec seulement une table de routage globale, l'opérateur est contraint de recourir au CLI, à des scripts ou à un routeur externe.
TR7 ADC place le modèle de Table de Routage au cœur de l'ADC : chaque tenant et zone réseau prend ses propres décisions de routage ; les routes statiques, les routes dynamiques, la surveillance des passerelles et les flux de service sont tous gérés depuis une console unique.
Notre approche
TR7 extrait le routage d'une table globale — chaque zone réseau vit dans sa propre Table de Routage indépendante.
Isolation des Tables de Routage TR7
Dans TR7, une Table de Routage n'est pas simplement une liste de routes. C'est un contexte réseau distinct qui détermine depuis quelle interface le trafic arrive, vers quelle passerelle il est transféré, quelles règles de sécurité il traverse, et quel backend il atteint. Ce modèle permet à plusieurs zones réseau indépendantes de fonctionner sur le même appareil, chacune avec son propre plan IP, sa passerelle, ses routes statiques et son comportement de routage dynamique.
Routage statique et dynamique ensemble
Les routes statiques peuvent être définies via l'interface TR7 en sélectionnant le réseau de destination, la passerelle, l'interface et la métrique. Dans les déploiements plus avancés, des protocoles de routage dynamique tels que BGP, OSPF, RIP et IS-IS peuvent également fonctionner dans le même contexte de Table de Routage. Le trafic de gestion peut être épinglé via des routes statiques tandis que le trafic de production suit des chemins appris dynamiquement — tous deux au sein du même appareil, le même modèle de gouvernance et la même vue opérationnelle.
Routage basé sur les politiques
TR7 prend en charge la direction du trafic non seulement par IP de destination mais aussi par signaux de politique. Un flux vService spécifique peut aller vers un WAN redondant, le trafic d'un tenant spécifique peut être dirigé vers un lien dédié, et un flux marqué peut être placé sur une table de routage différente. C'est particulièrement utile pour le WAN redondant, la sortie internet active/active, la séparation de liens par tenant, la sélection de routes par service et les scénarios de transit inline.
Surveillance de passerelle et basculement automatique
TR7 peut suivre si une passerelle par défaut est réellement joignable. Après un nombre configuré de vérifications échouées, la passerelle est marquée comme non saine et une route alternative ou une passerelle alternative peut être activée. C'est critique pour détecter le scénario passerelle-active-mais-upstream-coupé. Le trafic n'est jamais envoyé dans le vide — TR7 décide en fonction de la joignabilité réelle.
Capacités
Le modèle de Table de Routage TR7 rassemble toutes les capacités de routage requises pour les déploiements multi-tenant et les topologies réseau complexes.
Routage indépendant par Table de Routage
Chaque Table de Routage TR7 prend ses propres décisions de routage. Les mêmes blocs IP peuvent être utilisés dans différentes Tables de Routage sans conflit. Cela fournit l'isolation fondamentale requise pour les environnements MSP, SaaS, gouvernementaux, financiers et multi-clients.
Route Health Injection — l'adresse n'est annoncée que tant que le service est sain
L'adresse de service n'est annoncée en BGP ou OSPF que tant que les services derrière elle passent leurs contrôles de santé, et elle est retirée en quelques secondes sinon. Les routeurs amont cessent d'envoyer du trafic vers un site incapable de le servir, sans que personne n'ouvre de ticket. Seul le nœud qui détient réellement l'adresse l'annonce : c'est ce qui empêche un basculement de cluster de devenir un trou noir de routage. BFD ramène la détection de panne sous la seconde.
Gestion des routes statiques
Les opérateurs définissent le réseau de destination, la passerelle, la métrique et l'interface directement depuis l'interface. Les routes statiques sont utilisées principalement pour les réseaux de gestion, les liens dédiés, les chemins redondants, la séparation DMZ/interne et les segments backend spécifiques.
Prise en charge de gateway-on-link
Dans certaines configurations WAN ou point-à-point, l'IP de la passerelle peut ne pas apparaître dans le même sous-réseau. TR7 prend en charge le comportement gateway-on-link pour de telles connexions, réduisant le besoin d'étapes manuelles supplémentaires sur les liens WAN dédiés, tunnel ou fournisseur de service.
Infrastructure de protocoles de routage dynamique
TR7 fournit une infrastructure capable d'exécuter des protocoles de routage dynamique pour les équipes réseau avancées. BGP, OSPF, RIP, IS-IS et des protocoles similaires peuvent être utilisés dans le contexte de la Table de Routage. Cela fait de l'ADC un participant actif au routage dans le data center ou le réseau tenant plutôt qu'un appareil passif qui ne comprend que les routes statiques. Le routage dynamique est indiqué par famille d'adresses, car ce sont deux protocoles et non un : OSPFv2 porte IPv4 et OSPFv3 porte IPv6, si bien qu'un réseau double pile ne se retrouve pas sans routage au milieu de sa migration IPv6.
Les voisins dans des formulaires, la config brute et la console restent à vous
Les voisins BGP et les aires OSPF se définissent dans l'interface sous forme de formulaires — adresse du routeur, numéros d'AS, authentification, une case BFD qui ramène la détection de panne sous la seconde et un interrupteur « annoncer cette adresse » qui active le Route Health Injection — et TR7 en génère lui-même la configuration de routage. Le travail protocolaire avancé n'est pas fermé : un champ de configuration brute est ajouté à ce que TR7 génère et n'est jamais écrasé, et la console de protocole reste là pour lire l'état et déboguer dans le langage du protocole.
Routage basé sur les politiques
TR7 permet à un trafic spécifique d'être placé sur un comportement de routage différent. Ceci est utilisé pour la sélection de routes par service, par tenant ou par flux marqué. Le trafic de gestion peut sortir via une passerelle statique tandis que le trafic de production suit des routes dynamiques ; le trafic d'un tenant spécifique peut être placé sur un lien VPN tandis que le trafic VIP spécifique est dirigé vers un WAN redondant.
Surveillance de passerelle
La passerelle par défaut est vérifiée à intervalles réguliers. Lorsque les échecs dépassent le seuil configuré, la route est marquée comme non saine. Une passerelle alternative ou une route alternative peut alors être activée. Cette capacité examine la joignabilité réelle de la passerelle, pas seulement l'état du lien.
Basculement de passerelle par défaut
Lorsque la passerelle primaire échoue, une transition vers une passerelle secondaire peut être effectuée. Ceci est utilisé pour la redondance de sortie internet, le basculement WAN, la sauvegarde MPLS, la sauvegarde VPN et les scénarios de passerelle redondante intra-data-center.
Répartition de charge sur les sauts suivants (NHLD)
Le trafic sortant est réparti entre plusieurs passerelles amont, avec un suivi de santé par lien. Un lien défaillant est retiré en quelques secondes, et le marquage de connexion maintient un flux établi sur le lien où il a commencé : le trafic de retour reste symétrique et les équipements à état en amont ne voient jamais la moitié d'une conversation. C'est la réponse multi-WAN pour les sites disposant de deux fournisseurs d'accès ou plus.
Synchronisation delta des routes
TR7 ne rejoue pas l'ensemble de la structure de routage à chaque changement. Les routes ajoutées, modifiées et supprimées sont différenciées et seules les routes modifiées sont appliquées. Cette approche réduit les risques sur les systèmes en direct et permet aux changements de prendre effet plus rapidement.
Prise en charge des routes IPv4 et IPv6
TR7 peut gérer séparément les structures de routes IPv4 et IPv6. Dans les environnements dual-stack, les deux familles IP fonctionnent ensemble sous le même modèle de Table de Routage.
Gestion DNS et hosts par Table de Routage
Chaque Table de Routage peut avoir ses propres paramètres de résolution de noms. C'est utile pour le DNS par tenant, les résolveurs internes privés, les environnements de test isolés et les scénarios de domaine interne différents.
Comportement de route avec conscience du cluster
Dans les scénarios de cluster HA, quel appareil détient la VIP active importe pour l'application des routes. TR7 gère l'application des routes selon la logique de l'appareil actif en alignement avec la méthode de transition VIP en usage : Only VRRP, TR7 link check, TR7 gateway check et TR7 link and gateway check.
Flux de service cross-Table-de-Routage via vService
Un vService peut écouter sur une Table de Routage et transférer le trafic vers des backends résidant dans une Table de Routage différente. Exemple : le trafic internet entrant est reçu sur la Table de Routage DMZ et transféré de manière contrôlée vers le backend dans la Table de Routage interne. Le même appareil devient un point de transit contrôlé entre les zones réseau.
Routage hybride statique + dynamique
Les routes de gestion peuvent être maintenues fixes tandis que le trafic de production suit des routes apprises dynamiquement. Les valeurs de métrique définissent la priorité. L'opérateur fixe les chemins critiques en statique et délègue les segments réseau variables aux protocoles dynamiques.
Profondeur opérationnelle
Le modèle de Table de Routage va au-delà de la rédaction de règles — il couvre également l'ordre d'application, les seuils de surveillance des passerelles, le cycle de vie du routage dynamique et la gestion des pannes.
Modèle d'entrée de route
Chaque route est définie par les champs essentiels suivants : réseau de destination, passerelle, interface, métrique, comportement gateway-on-link et la Table de Routage associée. Cette structure est suffisante pour les routes statiques simples comme pour les scénarios multi-passerelles complexes.
Ordre d'application
L'application des routes dépend de l'état des interfaces et des IPs. TR7 applique d'abord les changements côté interface et IP, puis active les changements de routes. Cet ordre élimine une classe d'erreurs où une route est présente mais l'interface n'est pas encore prête.
Seuils de surveillance des passerelles
La surveillance de passerelle vérifie à des intervalles définis. Après un nombre de défaillances consécutives, la passerelle est considérée comme non saine ; après un nombre de succès consécutifs, elle est à nouveau considérée comme saine. Cette approche rise/fall empêche les fluctuations transitoires de déclencher des route flaps.
Cycle de vie du routage dynamique
L'infrastructure de routage dynamique fonctionne dans le contexte de la Table de Routage. Les services de protocole concernés sont démarrés, les fichiers de configuration sont générés, la console de protocole est préparée et le processus d'apprentissage des routes est lié à la Table de Routage concernée.
Logique de rollback lors d'échecs de routes
Si une route ne peut pas être appliquée, TR7 évalue l'échec en isolation. Les routes appliquées avec succès sont préservées et l'erreur pour la route problématique est signalée. Cela empêche une seule route défaillante de corrompre l'ensemble de la structure de routage.
Relation Table de Routage et Pare-feu
L'isolation de la Table de Routage prend tout son sens combinée avec l'isolation du pare-feu. Les routes d'un tenant ne se mélangent jamais avec les règles de pare-feu d'un autre tenant. Le trafic ne traverse pas seulement la bonne Table de Routage — il passe également par la bonne politique de sécurité.
Relation Table de Routage et vService
L'IP frontend d'un vService peut écouter dans une Table de Routage spécifique. Le côté backend peut être atteint via une Table de Routage différente. Cela transforme l'ADC d'un appareil qui transfère simplement le trafic entrant vers un backend proche en une passerelle de service contrôlée entre les zones réseau.
Définitions de voisins et d'aires sous le même contrôle des changements
Les définitions de voisins et d'aires passent par le même flux valider-puis-appliquer que le reste de la configuration, et chaque changement est inscrit au journal d'audit avec son auteur. Ce que les formulaires n'expriment pas — filtrage détaillé, route-maps, réglage fin du protocole — va dans le champ de configuration brute : il est stocké avec l'objet et préservé à chaque régénération de la configuration. Les équipes qui préfèrent la console de protocole travaillent exactement comme avant.
vDevices — des appliances virtuelles de niveau matériel dans un seul châssis
Une Route Table isole le routage. Un vDevice va plus loin et isole l'appliance entière : chacun possède ses interfaces, son pare-feu, ses tables de routage, son propre jeu de protections L4 DDoS et son propre DNS, et les vDevices sont attribués par utilisateur. Une tempête DDoS contre un vDevice est contenue par conception plutôt que par réglage, ce qui rend un châssis unique utilisable comme plusieurs équipements indépendants.
Quand l'utiliser
Routage multi-tenant MSP
Un MSP fait fonctionner de nombreux clients sur le même appareil TR7. Le Client A et le Client B utilisent les mêmes blocs IP. Chaque client est isolé dans sa propre Table de Routage TR7 ; les routes, le DNS, les règles de pare-feu et les flux de service ne sont jamais en conflit.
Transit DMZ vers backend interne
Le trafic internet est reçu sur la Table de Routage DMZ. Après que TR7 ait appliqué le WAAP et les politiques d'accès, le trafic est transféré vers le backend dans la Table de Routage interne. Le plan IP backend n'est jamais exposé au monde extérieur.
WAN redondant et routage source-based
Certains services sortent via le WAN primaire, certains tenants via un WAN redondant, et certains services de gestion via un lien dédié. Le routage basé sur les politiques TR7 sélectionne un chemin différent pour chaque classe de trafic.
Intégration BGP avec le data center
TR7 peut apprendre les routes dynamiquement depuis les routeurs de bordure. Lorsque de nouveaux segments réseau sont ajoutés, les routes statiques n'ont plus besoin d'être écrites manuellement. L'équipe réseau annonce les routes et TR7 utilise les chemins courants dans la Table de Routage concernée.
Ajout de l'ADC à une zone OSPF
Si le réseau interne existant fonctionne avec OSPF, TR7 peut rejoindre cette topologie dans la Table de Routage concernée. Les réseaux de services internes sont appris automatiquement et la gestion des routes est centralisée.
Basculement de passerelle par défaut
La passerelle primaire devient injoignable. La surveillance de passerelle détecte la défaillance et le trafic est déplacé vers la passerelle alternative. L'opérateur n'a pas besoin d'effectuer des changements de routes manuels.
Questions fréquentes
Deux tenants utilisant le même bloc IP peuvent-ils fonctionner sur le même appareil TR7 ?
Les routes statiques et dynamiques peuvent-elles coexister dans la même Table de Routage ?
La configuration BGP et OSPF se fait-elle directement depuis l'interface ?
Comment fonctionne la surveillance de passerelle et quand le basculement est-il déclenché ?
Un vService peut-il transférer du trafic vers un backend dans une Table de Routage différente de celle qu'il écoute ?
L'isolation des Tables de Routage nécessite-t-elle une licence supplémentaire ?
Le trafic sortant peut-il être réparti sur deux liens internet en même temps ?
Routage indépendant par tenant — géré depuis une console unique
Blocs IP chevauchants, routage dynamique statique + BGP/OSPF et surveillance de passerelle. Parcourons ensemble une configuration en direct sur votre propre topologie réseau.