Comprendre les interfaces multiservices agrégées pour les services de nouvelle génération
Cette rubrique donne un aperçu de l’utilisation de la fonctionnalité Aggregated Multiservices Interfaces avec la carte de services MX-SPC3 pour les services de nouvelle génération. Il contient les sections suivantes :
Interface multiservices agrégée
Dans Junos OS, vous pouvez combiner plusieurs interfaces de services pour créer un ensemble d’interfaces de services fonctionnant comme une interface unique. Un tel ensemble d’interfaces est appelé aggregated multiservices interface (AMS) et est désigné comme amsN dans la configuration, où N est un numéro unique qui identifie une interface AMS (par exemple, ams0). À partir de la version 19.3R2 de Junos OS, les interfaces AMS sont prises en charge sur la carte de services MX-SPC3 de Next Gen Services.
La configuration d’AMS offre une plus grande évolutivité, de meilleures performances et de meilleures options de basculement et d’équilibrage de charge.
Une configuration AMS permet aux ensembles de services de prendre en charge plusieurs PIC de services en associant un bundle AMS à un ensemble de services. Pour les services de nouvelle génération, la carte de services MX-SPC3 prend en charge jusqu’à deux PIC et vous pouvez avoir un maximum de huit cartes de services MX-SPC3 dans votre châssis. Ainsi, un bundle AMS de services nouvelle génération peut avoir jusqu’à 16 PIC de services en tant qu’interfaces membres, et vous pouvez distribuer des services entre les interfaces membres.
Les interfaces membres sont identifiées en tant que mams dans la configuration. Le processus de châssis dans les routeurs prenant en charge la configuration AMS crée une entrée mams pour chaque interface multiservices sur le routeur.
Lorsque vous configurez les options de services au niveau de l’interface ams, les options s’appliquent à toutes les interfaces membres (mams) de l’interface ams.
Les options s’appliquent également aux ensembles de services configurés sur les interfaces de services correspondant aux interfaces membres de l’interface ams. Tous les paramètres sont par PIC. Par exemple, la limite de sessions s’applique par membre et non au niveau de l’agrégat.
Vous ne pouvez pas configurer les options de service à la fois au niveau de l’ams (agrégat) et de l’interface membre. Si les options de services sont configurées le vms-x/y/z, elles s’appliquent également aux ensembles de services le mams-x/y/z.
Lorsque vous souhaitez que les paramètres des options de services s’appliquent uniformément à tous les membres, configurez les options de services au niveau de l’interface ams. Si vous avez besoin de paramètres différents pour chaque membre, configurez les options de services au niveau de l’interface du membre.
Une perte de trafic par membre et une configuration de saut suivant par membre sont requises pour NAT64. Pour NAPT44, cette spécification par membre autorise l’utilisation de clés de hachage arbitraires, ce qui offre de meilleures options d’équilibrage de charge pour permettre d’effectuer des opérations NAT dynamiques. Pour NAT64, NAPT44 et NAT44 dynamique, il n’est pas possible de déterminer quel membre alloue l’adresse NAT dynamique. Pour s’assurer que les paquets de flux inverse arrivent au même membre que les paquets de flux transversal, des routes basées sur l’adresse du pool sont utilisées pour diriger les paquets de flux inverse.
Si vous modifiez un pool NAT utilisé par un ensemble de services affecté à une interface AMS, vous devez désactiver et activer l’ensemble de services avant que les modifications du pool NAT ne prennent effet.
La distribution du trafic sur les interfaces membres d’une interface AMS peut se faire selon la méthode Round Robin ou par hachage. Vous pouvez configurer les valeurs de clé de hachage suivantes pour réguler la distribution du trafic : source-ip, destination-ip , et protocol. Pour les services qui nécessitent une symétrie du trafic, vous devez configurer le hachage symétrique. La configuration symétrique du hachage garantit que le trafic aller et arrière est acheminé via la même interface membre.
Si l’ensemble de services est appliqué à l’interface Gigabit Ethernet ou 10 Gigabit Ethernet (ensemble de services de type interface) qui fonctionne comme interface interne NAT, les clés de hachage utilisées pour l’équilibrage de charge peuvent être configurées de manière à ce que la clé d’entrée soit définie comme adresse IP de destination et la clé de sortie comme adresse IP source. Étant donné que l’adresse IP source subit un traitement NAT, elle n’est pas disponible pour le hachage du trafic dans le sens inverse. Par conséquent, l’équilibrage de charge ne se produit pas sur la même adresse IP et le trafic aller et arrière ne correspond pas au même PIC. Lorsque les touches de hachage sont inversées, l’équilibrage de charge se produit correctement.
Avec les services de saut suivant, pour le trafic transféré, la clé d’entrée de l’interface interne équilibre la charge du trafic, et pour le trafic inverse, la clé d’entrée sur l’interface externe équilibre la charge du trafic ou les sauts suivants par membre dirigent le trafic inverse. Avec les services de type interface, la clé d’entrée équilibre la charge du trafic vers l’avant et la clé de sortie équilibre la charge du trafic vers l’avant ou les sauts suivants par membre dirigent le trafic inverse. Le trafic direct est le trafic entrant par le côté intérieur d’un ensemble de services et le trafic inverse est le trafic entrant par le côté extérieur d’un ensemble de services. La clé de transfert est la clé de hachage utilisée pour le sens de transfert du trafic et la clé inverse est la clé de hachage utilisée pour le sens inverse du trafic (selon qu’elle est liée aux services d’interface ou au style de services de saut suivant).
Avec les pare-feu dynamiques, vous pouvez configurer les combinaisons suivantes de clés avant et arrière pour l’équilibrage de charge. Dans les combinaisons suivantes présentées pour les clés de hachage, FOR-KEY fait référence à la clé de transfert, REV-KEY désigne la clé inverse, SIP signifie l’adresse IP source, DIP signifie l’adresse IP de destination et PROTO fait référence au protocole tel que IP.
CLÉ FOR : SIP, TOUCHE REV-KEY : DIP
CLÉ FOR : SIP,PROTO REV-TOUCHE : DIP, PROTO
CLÉ FOR : DIP, TOUCHE REV : SIP
CLÉ FOR : DIP,PROTO REV-KEY : SIP, PROTO
CLÉ FOR : SIP,DIP REV-KEY : SIP, DIP
FOR-KEY : SIP,DIP,PROTO REV-KEY : SIP, DIP,PROTO
Lorsque le NAT statique est configuré en tant que NAT44 de base ou NAT44 de destination, et que le pare-feu dynamique est configuré ou non, si le sens de transfert du trafic doit subir un traitement NAT, configurez les clés de hachage comme suit :
CLÉ FOR : DIP, TOUCHE REV : SIP
CLÉ FOR : DIP,PROTO REV-KEY : SIP, PROTO
Si le sens inverse du trafic doit subir un traitement NAT, configurez les clés de hachage comme suit :
CLÉ FOR : SIP, TOUCHE REV-KEY : DIP
CLÉ FOR : SIP,PROTO REV-TOUCHE : DIP, PROTO
Lorsque le NAT dynamique est configuré et que le pare-feu à états est configuré ou non, seul le trafic en direction directe peut subir un NAT. La clé de hachage direct peut être n’importe quelle combinaison de SIP, DIP et protocole, et la clé de hachage inverse est ignorée.
La configuration AMS de Junos OS prend en charge le trafic IPv4 et IPv6.
Présentation du trafic IPv6 sur les interfaces AMS
Vous pouvez utiliser des interfaces AMS pour le trafic IPv6. Pour configurer la prise en charge IPv6 d’une interface AMS, incluez l’instruction family inet6 au niveau de la [edit interfaces ams-interface-name unit 1] hiérarchie. Lorsque family inet et family inet6 sont définis pour une sous-unité d’interface AMS, le est configuré au niveau de l’ensemble de services pour le style d’interface hash-keys et au niveau IFL pour le style de saut suivant.
En cas de défaillance d’une interface membre d’un bundle AMS, le trafic destiné au membre défaillant est redistribué entre les membres actifs restants. Le trafic (flux ou sessions) traversant les membres actifs existants n’est pas affecté. Si M membres sont actuellement actifs, le résultat attendu est que seule une fraction environ 1/M du trafic (flux/sessions) est affectée, car cette quantité de trafic est déplacée du membre défaillant vers les membres actifs. Lorsque l’interface du membre défaillant est remise en ligne, seule une fraction du trafic est redistribuée vers le nouveau membre. Si N membres sont actuellement actifs, le résultat attendu est que seulement environ 1/(N+1) fraction du trafic (flux/sessions) est affectée, car cette quantité de trafic se déplace vers le nouveau membre restauré. Les valeurs 1/M et 1/(N+1) supposent que les flux sont uniformément distribués entre les membres, car un hachage de paquets est utilisé pour équilibrer la charge et parce que le trafic contient généralement une combinaison aléatoire typique d’adresses IP (ou tout autre champ utilisé comme clé d’équilibrage de charge).
Comme pour le trafic IPv4, pour les paquets IPv6, un bundle AMS doit contenir des membres d’un seul type de PIC de services.
Le nombre de flux distribués, dans un environnement idéal, peut être de 1/N dans le meilleur des cas lorsque le Nième membre augmente ou diminue. Cependant, cette hypothèse considère que les clés de hachage équilibrent la charge du trafic réel ou dynamique. Prenons l’exemple d’un déploiement réel dans lequel le membre A ne dessert qu’un seul flux, tandis que le membre B en dessert 10. Si le membre B tombe en panne, le nombre de flux perturbés est de 10/11. Le comportement de fractionnement de pool NAT est conçu pour utiliser les avantages de la fonctionnalité de minimisation du rehash. Le fractionnement d’un pool NAT est effectué pour les scénarios NAT dynamiques (NAT dynamique, NAT64 et NAPT44).
Si les flux d’origine et redistribués sont définis comme suit :
Member-original-flows : trafic mappé à un membre lorsque tous les membres sont actifs.
Member-redistributed-flows : trafic supplémentaire mappé à un membre en cas de défaillance d’un autre membre. Il peut être nécessaire de rééquilibrer ces flux de trafic lorsque des interfaces membres apparaissent ou descendent.
Avec les définitions précédentes des flux d’origine et redistribués pour les interfaces membres, les observations suivantes s’appliquent :
Les flux d’origine d’un membre restent intacts tant que ce membre est actif. Ces flux ne sont pas affectés lorsque d’autres membres passent d’un état à l’autre et à l’état descendant.
Les flux redistribués d’un membre peuvent changer lorsque d’autres membres montent ou descendent. Ce changement de flux se produit parce que ces flux supplémentaires doivent être rééquilibrés entre tous les membres actifs. Par conséquent, le flux redistribué par les membres peut varier considérablement en fonction de la baisse ou de la hausse des autres membres. Bien qu’il puisse sembler que lorsqu’un membre descend, les flux sur les membres actifs sont préservés, et que lorsqu’un membre monte, les flux sur les membres actifs ne sont pas préservés de manière efficace, ce comportement n’est dû qu’au rééquilibrage statique ou basé sur le hachage du trafic entre les membres actifs.
La fonctionnalité de minimisation du hachage gère uniquement les modifications opérationnelles de l’état d’une interface membre (par exemple, un membre hors ligne ou une réinitialisation du système d’exploitation Junos OS). Il ne gère pas les changements de configuration. Par exemple, l’ajout ou la suppression, ou l’activation et la désactivation, d’interfaces membres au niveau de la [edit interfaces amsN load-balancing-options member-interface mams-a/b/0] hiérarchie nécessite le rejet des PIC membres. Le NAT ou l’épingle à cheveux deux fois ne sont pas pris en charge, de la même manière que pour IPv4 pour les interfaces AMS.
Options de défaillance des membres et paramètres de haute disponibilité
Étant donné que plusieurs interfaces de service sont configurées dans le cadre d’un bundle AMS, la configuration d’AMS prend également en charge le basculement et la haute disponibilité. Vous pouvez soit configurer l’une des interfaces membres en tant qu’interface de secours qui devient active lorsque l’une des autres interfaces membres tombe en panne, soit configurer l’AMS de manière à ce qu’en cas de panne de l’une des interfaces membres, le trafic affecté à cette interface soit partagé entre les interfaces actives.
L’instruction member-failure-options configuration vous permet de configurer la manière de gérer le trafic en cas de défaillance d’une interface membre. Une option consiste à redistribuer immédiatement le trafic entre les autres interfaces membres. Toutefois, la redistribution du trafic implique de recalculer les balises de hachage et peut entraîner une perturbation du trafic sur toutes les interfaces membres.
L’autre option consiste à configurer l’AMS pour qu’il abandonne tout le trafic affecté à l’interface membre défaillante. Avec cela, vous pouvez éventuellement configurer un intervalle, , pour que l’AMS attende que l’interface défaillante soit remise en ligne, rejoin-timeoutaprès quoi l’AMS peut redistribuer le trafic entre les autres interfaces membres. Si l’interface membre défaillante est remise en ligne avant le temps d’attente configuré, le trafic se poursuit sans être affecté sur toutes les interfaces membres, y compris l’interface qui a été remise en ligne et a repris les opérations.
Vous pouvez également contrôler la connexion de l’interface défaillante lorsqu’elle revient en ligne. Si vous n’incluez pas l’instruction enable-rejoin dans la member-failure-options configuration, l’interface défaillante ne peut pas rejoindre l’AMS lorsqu’elle est remise en ligne. Dans ce cas, vous pouvez le rejoindre manuellement à l’AMS en exécutant la commande du request interfaces revert interface-name mode opérationnel.
Les rejoin-timeout instructions et enable-rejoin vous permettent de minimiser les interruptions de trafic lorsque les interfaces membres battent des ailes.
Lorsqu’elles member-failure-options ne sont pas configurées, le comportement par défaut est d’abandonner le trafic des membres avec un délai d’expiration de 120 secondes.
La high-availability-options configuration vous permet de désigner l’une des interfaces membres comme interface de secours. L’interface de sauvegarde ne participe pas aux opérations de routage tant qu’elle reste une interface de secours. En cas de défaillance d’une interface membre, l’interface de sauvegarde gère le trafic affecté à l’interface défaillante. Lorsque l’interface défaillante est réactivée, elle devient la nouvelle interface de sauvegarde.
Dans une configuration plusieurs-à-un (N :1), une seule interface de secours prend en charge toutes les autres interfaces membres du groupe. Si l’une des interfaces membres tombe en panne, l’interface de sauvegarde prend le relais. Dans cette configuration sans état, les données ne sont pas synchronisées entre l’interface de sauvegarde et les autres interfaces membres.
Lorsque les deux member-failure-options et high-availability-options sont configurés pour un AMS, la high-availability-options configuration est prioritaire sur la member-failure-options configuration. Si une deuxième défaillance se produit avant que l’interface défaillante ne soit remise en ligne pour devenir la nouvelle sauvegarde, la member-failure-options configuration prend effet.
Redondance de veille à chaud
À partir de la version 19.3R2 de Junos OS, l’option de veille à chaud N :1 est prise en charge sur le MX-SPC3 si vous exécutez des services de nouvelle génération. Chaque interface AMS de secours à chaud contient deux membres ; Un membre est l’interface de service que vous souhaitez protéger, appelée interface principale, et un membre est l’interface secondaire (de secours). L’interface principale est l’interface active et l’interface de secours ne gère aucun trafic, sauf si l’interface principale tombe en panne.
Pour configurer la veille à chaud sur une interface AMS, utilisez l’instruction redundancy-options . Vous ne pouvez pas utiliser l’instruction load-balancing-options dans une interface AMS de secours à chaud.
Pour passer de l’interface principale à l’interface secondaire, exécutez la request interface switchover amsN commande.
Pour revenir à l’interface principale à partir de l’interface secondaire, exécutez la request interface revert amsN commande.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.