Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Protections des liaisons de périphérie du fournisseur dans les VPN de couche 3

Cette rubrique décrit et fournit des exemples sur la configuration du chemin de protection précalculé, qui fournit une protection de liaison et un chemin de secours entre un routeur CE et un routeur PE alternatif.

Comprendre le reroutage rapide de l’hôte

Le reroutage rapide de l’hôte (HFRR) ajoute un chemin de protection précalculé dans le moteur de transfert de paquets (PFE), de sorte que si une liaison entre un équipement de périphérie du fournisseur et une batterie de serveurs devient inutilisable pour le transfert, le PFE peut utiliser un autre chemin sans avoir à attendre que le routeur ou les protocoles fournissent des informations de transfert mises à jour. Ce chemin de protection précalculé est souvent appelé chemin de réparation ou chemin de secours.

Le HFRR est une technologie qui protège les points de terminaison IP sur des interfaces multipoints, telles qu’Ethernet. Cette technologie est importante dans les datacenters où une restauration rapide du service pour les points de terminaison des serveurs est essentielle. Après la défaillance d’une interface ou d’une liaison, la fonction HFRR permet de fixer le temps de réparation local à environ 50 millisecondes.

Considérons la topologie de réseau illustrée à la Figure 3.

Figure 3 : reroutage Network topology with MPLS L3VPN cloud, PE1 and PE2 routers connecting customer networks. rapide de l’hôte

Les périphériques de routage créent des entrées de transfert de route hôte déclenchées par le protocole ARP (Address Resolution Protocol) et le protocole NDP (Neighbor Discovery Protocol) IPv6. HFRR augmente les routes hôtes avec des sauts suivants de secours fournis par les protocoles de routage. Ces sauts suivants de sauvegarde permettent au trafic entrant de continuer à circuler pendant que le réseau converge à nouveau.

Le trafic est acheminé depuis les réseaux connectés aux équipements de périphérie du fournisseur, PE1 et PE2, vers l’hôte A et l’hôte B. Ce trafic est protégé par HFRR. Si la liaison tombe en panne entre l’équipement PE2 et les serveurs hôtes, le trafic est réacheminé via l’équipement PE1 vers les serveurs hôtes. Dans la topologie, l’hôte A et l’hôte B représentent des PC LAN, collectivement appelés batterie de serveurs. Les périphériques PE sont des routeurs séparés par un VPN de couche 3. L’équipement PE1 apprend à connaître les hôtes directement connectés par le biais d’ARP ou du NDP IPv6.

L’équipement PE2 contient également des informations sur le réseau de la batterie de serveurs et transmet ces informations à l’équipement PE1. Cette annonce est transmise via le VPN de couche 3 à l’aide d’un BGP interne (IBGP). Sur les appareils PE1 et PE2, cette route est considérée comme une route directe vers le sous-réseau de la batterie de serveurs.

L’équipement PE1 utilise les routes d’hôte apprises via ARP et NDP pour envoyer du trafic aux machines hôtes de la batterie de serveurs. Si la liaison entre l’équipement PE1 et la batterie de serveurs est interrompue et que HFRR n’est pas configuré, le périphérique de routage trouve le meilleur itinéraire suivant, qui est l’itinéraire IBGP. Cette implémentation entraîne des pertes de trafic pendant un certain temps, jusqu’à ce que la mise à jour se produise et que le réseau converge à nouveau. Le HFRR configuré sur l’équipement PE1 résout ce problème en ajoutant aux routes ARP et NDP un chemin de secours afin que le trafic puisse continuer à être transféré sans interruption.

Le chemin de secours dans cette topologie particulière est la route VPN IBGP de couche 3. Dans un déploiement réel, l’équipement PE2 peut également configurer la protection par liaison pour son réseau de batterie de serveurs directement connecté, et l’équipement PE1 peut annoncer lui-même l’accessibilité à la batterie de serveurs à l’aide des routes VPN de couche 3 vers l’équipement PE2. Par conséquent, HFRR doit être activé à la fois sur l’équipement PE1 et l’équipement PE2. En outre, l’équipement PE1 et l’appareil PE2 doivent tous deux annoncer l’accessibilité à la batterie de serveurs via BGP.

Une boucle de routage temporaire peut se développer entre les périphériques PE si, par exemple, le lien entre le périphérique PE1 vers la batterie de serveurs et le lien entre le périphérique PE2 vers la batterie de serveurs tombent en panne simultanément. La boucle peut se poursuivre jusqu’à ce que BGP aux deux extrémités apprenne que le sous-réseau de la batterie de serveurs est en panne et retire les routes BGP.

Limite de préfixe ARP et délai d’expiration supplémentaire d’interdiction

Lorsque vous configurez des profils HFRR, une limite de préfixe ARP facultative définit un nombre maximal de routes ARP et, par conséquent, de routes FRR créées pour chaque profil HFRR dans la table de routage. Cette limite empêche les attaques ARP d’épuiser la mémoire virtuelle sur les périphériques de routage. La limite de préfixe ARP ne limite pas les routes ARP dans la table de transfert. Toutefois, il limite le nombre de routes ARP lues par Junos OS pour un profil et, par conséquent, le nombre de routes HFRR créées par le processus de routage (rpd) dans la table de routage et la table de transfert.

La limite de préfixe ARP est appliquée à chaque profil HFRR. Il ne limite pas le nombre total de toutes les routes ARP/HFRR dans la table de routage. Il limite uniquement le nombre de routes ARP/HFRR pour chaque profil HFRR.

Il existe deux instructions de configuration ( global-arp-prefix-limit et arp-prefix-limit ) qui définissent la limite de préfixe ARP, l’une au niveau de la hiérarchie globale [edit routing-options host-fast-reroute] et l’autre au niveau de la [edit routing-instances instance-name routing-options interface interface-name] hiérarchie, respectivement. L’instruction globale global-arp-prefix-limit définit une limite de préfixe ARP par défaut pour tous les profils HFRR configurés sur le périphérique de routage. L’instruction arp-prefix-limit remplace le global-arp-prefix-limit profil HFRR pour cette interface protégée.

Lorsque le nombre de routes ARP dans un profil HFRR atteint 80 % de la limite de préfixe ARP configurée, un message d’avertissement est envoyé au journal système. Le message d’avertissement s’affiche pour toute route ARP ultérieure ajoutée à ce profil HFRR si les préfixes ARP restent à plus de 80 % de la valeur configurée.

Lorsque le nombre de routes ARP dans un profil HFRR atteint 100 % de la limite de préfixe ARP configurée pour un profil HFRR, un autre message d’avertissement est envoyé au journal système. Lorsque le nombre franchit le seuil de 100 %, le profil HFRR est désactivé. Lorsque cela se produit, toutes les routes ARP/FRR sont supprimées de la table de routage. Les routes FRR sont également supprimées de la table de transfert.

Une fois le profil HFRR désactivé, une minuterie d’occultation est lancée. La valeur du délai d’expiration de ce temporisateur est le délai d’expiration du cache ARP (délai d’expiration du noyau) + le délai d’expiration supplémentaire.

Il existe des instructions CLI globales et par HFRR ( global-supplementary-blackout-timer et supplementary-blackout-timer ). La valeur globale se trouve au niveau de la [edit routing-options host-fast-reroute] hiérarchie et s’applique à tous les profils HFRR sur le périphérique de routage. Le minuteur d’interdiction supplémentaire configuré pour l’interface d’instance de routage au niveau de la [edit routing-instances instance-name routing-options interface interface-name] hiérarchie remplace la valeur globale pour ce profil HFRR uniquement.

Lorsque le délai d’interdiction expire, le profil HFRR est réactivé et Junos OS réapprend les routes ARP et recrée les routes HFRR. Si la limite de préfixe ARP n’est pas dépassée à nouveau, les routes HFRR seront activées.

Si un profil HFRR est sur liste bloquée et est à l’état désactivé, une réévaluation de l’état ARP est effectuée lors de chaque opération de validation ou chaque fois que le processus de routage (rpd) est redémarré avec la restart routing commande.

Route principale et route de secours Candidats

La route principale pour le saut HFRR suivant est fournie par les routes ARP et NDP IPv6. Il s’agit de routes /32 ou /128. L’itinéraire de sauvegarde correspond exactement au préfixe de l’adresse configurée sur l’interface locale. Par exemple, si l’adresse locale configurée est 10.0.0.5/24, le périphérique de routage recherche une correspondance exacte du préfixe 10.0.0.0 avec une longueur de préfixe de 24 pour la sélection de l’itinéraire de secours.

Les contraintes pour la sélection d’itinéraires de secours sont les suivantes :

  • Il doit s’agir d’un préfixe correspondant à la même adresse de sous-réseau que celle configurée sur l’interface compatible HFRR du périphérique de routage.

  • L’agrégation de routes (également appelée synthétisation) ne doit pas être configurée à l’extrémité distante. Par exemple, si l’extrémité distante combine deux sous-réseaux /24 ou plus pour annoncer un sous-réseau dont la longueur du préfixe est inférieure à /24, Junos OS ne sélectionne pas cette route résumée comme route de secours.

  • S’il existe une autre route dans la table de routage apprise par un autre protocole avec une correspondance du préfixe le plus long pour la route /32 ou /128 (ARP ou NDP), cette route n’est pas sélectionnée comme candidate de secours. Par exemple, supposons que l’adresse de l’interface locale soit 10.0.0.5/24. Supposons également que la table de routage contienne une route IBGP avec le préfixe 10.0.0.0/24 et une route OSPF avec le préfixe 10.0.0.0/28. Même si la route /28 est une meilleure route pour certains préfixes dans le sous-réseau, Junos OS ne considère pas 10.0.0.0/28 comme un candidat de secours. La route IBGP devient la solution de secours pour toutes les routes hôtes. Cependant, après la réparation globale, la route OSPF est utilisée pour le transfert.

En bref, la solution de sauvegarde candidate doit être une route avec le même préfixe que l’interface locale du sous-réseau que vous protégez avec HFRR.

Stratégie de sélection du chemin de sauvegarde

Seules les routes VPN de couche 3 sont prises en compte pour la sélection de secours. HFRR utilise l’algorithme habituel de sélection de chemin BGP pour sélectionner le meilleur itinéraire de sauvegarde. Un seul chemin de sauvegarde est sélectionné. Dans le cas où il y a plusieurs chemins de sauvegarde candidats, l’algorithme de sélection sélectionne le meilleur chemin de sauvegarde. HFRR ne fournit que deux chemins, un principal et un de secours à tout moment. Si le chemin de sauvegarde sélectionné contient lui-même deux chemins, le premier chemin de ce saut suivant de sauvegarde est utilisé comme tronçon suivant de sauvegarde pour l’itinéraire HFRR.

Le chemin principal est installé avec un poids de un. Le chemin de sauvegarde est installé avec un poids de 0x4000. Le chemin de sauvegarde doit évidemment être un chemin à travers une interface qui n’est pas la même que l’interface principale.

L’itinéraire de sauvegarde n’est recherché que dans la table de routage à laquelle appartient l’interface. Pour IPv4, Junos OS utilise routing-instance-name.inet.0. Pour IPv6, Junos OS se penche sur routing-instance-name.inet6.0.

Caractéristiques des itinéraires HFRR

La route HFRR est une route de transfert uniquement et n’est pas utilisée pour la résolution de route. Les routes HFRR ont des adresses d’hôte, ce qui signifie qu’elles ont /32 ou /128 comme longueur de préfixe. Dans le cas des plates-formes dotées de deux moteurs de routage, le processus de routage de secours (rpd) crée également des routes HFRR. Toutefois, le processus de sortie de sauvegarde (rpd) n’installe pas de routes HFRR vers une table de routage tant que la sauvegarde ne devient pas la principale après un basculement du moteur de routage.

Notez également que si une route HFRR est présente dans la table de routage, la route HFRR est utilisée pour le calcul unicast reverse-path-forwarding (uRPF).

Suppression des routes HFRR

Les routes HFRR sont supprimées si l’interface protégée est supprimée ou désactivée dans la configuration, si HFRR est configuré sur une instance de routage et que l’instance de routage est désactivée ou supprimée, ou lorsque l’instruction qui active HFRR( link-protection (Host Fast Reroute) ) est supprimée ou désactivée. Les routes HFRR sont supprimées et rajoutées en cas d’opération catastrophique sur le routage de l’instance, par exemple lorsque le processus de routage est redémarré. Les routes HFRR sont également supprimées si toutes les routes de sauvegarde sont supprimées. par exemple lorsque BGP retire des routes ou lorsque BGP est désactivé ou supprimé.

Après la défaillance d’une interface protégée et si HFRR est supprimé ou désactivé, un minuteur démarre avec un délai d’attente de 20 secondes. La suppression de la route HFRR se produit après l’expiration du minuteur. Cela permet de s’assurer qu’en cas de fortes fluctuations de l’interface, Junos OS n’effectuera pas inutilement de suppressions et d’ajouts de routes pouvant entraîner des pertes de trafic. Ce temporisateur n’est utilisé que lorsque l’interface est en panne ou lorsque la route HFRR est supprimée ou désactivée.

Les routes HFRR sont purgées immédiatement dans les cas suivants :

  • Une route de secours tombe en panne et il n’y a pas d’autres chemins de sauvegarde potentiels.

  • Un message de suppression ARP est reçu.

  • Le processus de routage (rpd) se termine.

Interfaces prenant en charge HFRR

Le HFRR n’est autorisé que sur les interfaces Ethernet. L’opération de validation échoue si vous configurez HFRR sur des interfaces point à point.

Seules les interfaces configurées sous l’instance de routage de type VPN routing and forwarding (VRF) sont acceptées. L’opération de validation échoue si vous configurez HFRR sur d’autres types d’instances de routage.

Lorsque les conditions suivantes ne sont pas remplies, l’opération de validation n’échoue pas. Cependant, l’interface n’est pas protégée par HFRR et l’interface est marquée comme inactive dans la sortie de la show hfrr profiles commande :

  • Le HFRR n’est autorisé que sur les interfaces numérotées, ce qui signifie qu’une adresse doit être attribuée à l’interface. Vous ne pouvez pas, par exemple, configurer IPv4sur l’interface avec une adresse et IPv6 sans adresse.

  • Les interfaces configurées pour la protection HFRR doivent être configurées au niveau de la [edit interfaces] hiérarchie et doivent également être attachées à l’instance de routage.

  • L’instance de routage doit être dotée d’une interface de tunnel virtuel (VT) ou l’instruction vrf-table-label doit être incluse.

Une autre raison pour laquelle l’interface peut être marquée comme inactive dans la sortie de la show hfrr profiles commande est lorsque l’interface migre d’une instance à une autre et que la configuration HFRR se trouve dans l’instance de routage précédente.

HFRR n’est pas pris en charge sur les unités logiques qui se chevauchent si elles appartiennent à la même instance de routage, comme illustré ici :

Si vous configurez des sous-réseaux superposés comme illustré ici, et si vous activez HFRR sur les deux sous-réseaux superposés, le processus de protocole de routage (rpd) génère une erreur RPD_ASSERT.

Voir aussi