Configuration des itinéraires dynamiques
Lorsqu’un protocole de routage dynamique est activé, le processus de routage correspondant surveille les mises à jour des itinéraires et annonce les itinéraires. Les protocoles de routage permettent à un routeur en amont d’utiliser la technique ECMP (Equal Cost Multipath) pour équilibrer la charge du trafic vers des serveurs virtuels identiques hébergés sur deux appliances NetScaler autonomes. Le routage dynamique sur une appliance NetScaler utilise trois tables de routage. Dans une configuration haute disponibilité, les tables de routage de l’appliance secondaire reflètent celles de la solution principale.
Pour connaître les guides de référence des commandes et les commandes non prises en charge sur le protocole de routage dynamique, consultez Guides de référence des commandes du protocole de routage dynamique et commandes non prises en charge.
NetScaler prend en charge les protocoles suivants :
- Protocole d’information de routage (RIP) version 2
- Ouvrez d’abord le chemin le plus court (OSPF) version 2
- Protocole Border Gateway (BGP)
- Protocole d’information de routage de nouvelle génération (RIPng) pour IPv6
- Open Shortest Path First (OSPF) version 3 pour IPv6
- Protocole ISIS
Vous pouvez activer plusieurs protocoles simultanément.
Tables de routage dans NetScaler
Dans une appliance NetScaler, la table de routage du noyau NetScaler, la table de routage du noyau FreeBSD et la table de routage NSM FIB contiennent chacune un ensemble différent de routes et ont un objectif différent. Ils communiquent entre eux à l’aide de sockets de routage UNIX. Les mises à jour d’itinéraires ne sont pas automatiquement propagées d’une table de routage à une autre. Vous devez configurer la propagation des mises à jour d’itinéraires pour chaque table de routage.
Table de routage du noyau NS
La table de routage du noyau NS contient les routes de sous-réseau correspondant au NSIP et à chaque SNIP et MIP. En général, aucune route correspondant aux VIP n’est présente dans la table de routage du noyau NS. L’exception est un VIP ajouté à l’aide de la commande add ns ip et configuré avec un masque de sous-réseau autre que 255.255.255.255. Si plusieurs adresses IP appartiennent au même sous-réseau, elles sont extraites sous la forme d’une route de sous-réseau unique. En outre, cette table contient une route vers le réseau de bouclage (127.0.0.0) et toutes les routes statiques ajoutées via la CLI (CLI). Les entrées de ce tableau sont utilisées par NetScaler pour le transfert de paquets. À partir de l’interface de ligne de commande, ils peuvent être inspectés à l’aide de la commande show route.
Table de routage FreeBSD
Le seul but de la table de routage FreeBSD est de faciliter l’initiation et la fin du trafic de gestion (telnet, ssh, etc.). Dans une appliance NetScaler, ces applications sont étroitement liées à FreeBSD, et il est impératif que FreeBSD dispose des informations nécessaires pour gérer le trafic en provenance et à destination de ces applications. Cette table de routage contient une route vers le sous-réseau NSIP et une route par défaut. De plus, FreeBSD ajoute des routes de type WAScloned (W) lorsque NetScaler établit des connexions avec des hôtes sur des réseaux locaux. En raison de l’utilité hautement spécialisée des entrées de cette table de routage, toutes les autres mises à jour de routage provenant du noyau NS et des tables de routage NSM FIB contournent la table de routage FreeBSD. Ne le modifiez pas à l’aide de la commande route. La table de routage FreeBSD peut être inspectée à l’aide de la commande netstat depuis n’importe quel shell UNIX.
Module de services réseau (NSM) FIB
La table de routage NSM FIB contient les itinéraires publicitaires qui sont distribués par les protocoles de routage dynamique à leurs homologues du réseau. Il peut contenir :
- Itinéraires connectés. Sous-réseaux IP directement accessibles depuis NetScaler. Généralement, les routes correspondant au sous-réseau NSIP et aux sous-réseaux sur lesquels les protocoles de routage sont activés sont présentes dans NSM FIB en tant que routes connectées.
- Routes du noyau. Toutes les adresses VIP sur lesquelles l’option -hostRoute est activée sont présentes dans NSM FIB en tant que routes du noyau si elles répondent aux niveaux RHI requis. En outre, NSM FIB contient toutes les routes statiques configurées sur l’interface de ligne de commande pour lesquelles l’option - advertise est activée. Sinon, si NetScaler fonctionne en mode Static Route Advertising (SRADV), toutes les routes statiques configurées sur la CLI sont présentes dans NSM FIB. Ces routes statiques sont marquées comme routes du noyau dans NSM FIB, car elles appartiennent en fait à la table de routage du noyau NS.
- Routes statiques. Normalement, toute route statique configurée dans VTYSH est présente dans NSM FIB. Si les distances administratives des protocoles sont modifiées, ce n’est pas toujours le cas. Il est important de noter que ces routes ne peuvent jamais entrer dans la table de routage du noyau NS.
- Itinéraires appris. Si NetScaler est configuré pour apprendre les itinéraires de manière dynamique, le NSM FIB contient les itinéraires appris par les différents protocoles de routage dynamique. Les itinéraires appris par l’OSPF nécessitent toutefois un traitement spécial. Ils sont téléchargés sur FIB uniquement si l’option fib-install est activée pour le processus OSPF. Cela peut être fait à partir de la vue router-config dans VTYSH.
Routage dynamique dans une configuration à haute disponibilité
Dans une configuration à haute disponibilité, le nœud principal exécute le processus de routage et propage les mises à jour de la table de routage vers le nœud secondaire. La table de routage du nœud secondaire reflète la table de routage du nœud principal.
Expédition continue
Après le basculement, le nœud secondaire met un certain temps à démarrer le protocole, à connaître les itinéraires et à mettre à jour sa table de routage. Mais cela n’affecte pas le routage, car la table de routage du nœud secondaire est identique à la table de routage du nœud principal. Ce mode de fonctionnement est connu sous le nom de transfert continu.
Mécanisme d’évitement des trous noirs
Après le basculement, le nouveau nœud principal injecte toutes ses routes VIP dans le routeur en amont. Toutefois, ce routeur conserve les routes de l’ancien nœud principal pendant 180 secondes. Comme le routeur n’est pas au courant du basculement, il tente d’équilibrer la charge du trafic entre les deux nœuds. Pendant les 180 secondes qui précèdent l’expiration des anciennes routes, le routeur envoie la moitié du trafic à l’ancien nœud principal inactif, qui est en fait un trou noir.
Pour éviter cela, le nouveau nœud principal, lorsqu’il injecte une route, lui attribue une métrique légèrement inférieure à celle spécifiée par l’ancien nœud principal.
Interfaces pour la configuration du routage dynamique
Pour configurer le routage dynamique, vous pouvez utiliser l’interface graphique ou une interface de ligne de commande. NetScaler prend en charge deux interfaces de ligne de commande indépendantes : la CLI et le Virtual Teletype Shell (VTYSH). La CLI est l’interpréteur de commandes natif de l’appliance. Le VTYSH est exposé par ZebOS. La suite de routage NetScaler est basée sur ZebOS, la version commerciale de GNU Zebra.
Remarque :
Citrix vous recommande d’utiliser VTYSH pour toutes les commandes, à l’exception de celles qui ne peuvent être configurées que sur l’interface de ligne de commande. L’utilisation de la CLI doit généralement être limitée aux commandes permettant d’activer les protocoles de routage, de configurer la publicité des itinéraires hôtes et d’ajouter des itinéraires statiques pour le transfert de paquets.
Guides de référence des commandes du protocole de routage dynamique et commandes non prises en charge
Le tableau suivant répertorie les liens du guide de référence des commandes, pour différents protocoles de routage dynamique et les commandes non prises en charge sur l’appliance NetScaler : guides de référence du protocole de routage dynamique etcommandes non prises en charge.