Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Équilibrage de charge et haute disponibilité avec des interfaces multiservices agrégées sur MS-MPC et MS-MIC

Comprendre les interfaces multiservices agrégées

Cette rubrique 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 qui peuvent fonctionner comme une seule interface. Un tel ensemble d’interfaces est appelé aggregated multiservices interface (AMS) et est désigné par amsN dans la configuration, où N se trouve un numéro unique qui identifie une interface AMS (par exemple, ams0).

La configuration AMS offre une plus grande évolutivité, des performances améliorées et de meilleures options de basculement et d’équilibrage de charge.

La configuration AMS permet aux ensembles de services de prendre en charge plusieurs PIC de services en associant une offre groupée AMS à un ensemble de services. Un bundle AMS peut avoir jusqu’à 24 PIC de services en tant qu’interfaces membres et peut distribuer des services entre les interfaces membres.

Les interfaces membres sont identifiées comme des mams dans la configuration. Le processus chassisd dans les routeurs qui prennent en charge la configuration AMS crée une entrée mams pour chaque interface multiservice sur le routeur.

À partir de Junos OS version 16.2 (à l’exception de Junos OS version 17.3R3-S7), une interface AMS peut avoir jusqu’à 36 interfaces membres. Si vous incluez plus de 24 interfaces membres, vous devez augmenter le délai d’expiration du PIC de service à 240 ou 300 secondes pour tous les PIC de service. Dans Junos OS version 16.1 et antérieure, ainsi que dans Junos OS version 17.3R3-S7, une interface AMS peut avoir un maximum de 24 interfaces membres.

À partir de la version 17.1R1 de Junos OS, AMS prend en charge la distribution de tunnel IPSec pour les ensembles de services de type saut suivant. Toutefois, les ensembles de services IPSec de type interface ne sont pas pris en charge.

À partir de la version 19.2R1 de Junos OS, vous pouvez utiliser jusqu’à 60 PIC sur différents bundles AMS sur un routeur MX2020. La limite stricte de 36 interfaces membres maximum par bundle AMS existe toujours. Cependant, dans le châssis, il peut y avoir plusieurs bundles AMS, de sorte que 15 MS-MPC peuvent être configurés sur ces bundles.

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 à un niveau agrégé.

À partir de la version 19.3R2 de Junos OS, les interfaces AMS sont prises en charge avec le MX-SPC3. Le tableau suivant indique les détails du nombre maximal de MX-SPC3, du nombre maximal de PIC et du nombre maximal de membres AMS dans un bundle :

Plates-formes MX Nombre maximal de MX-SPC3 Nombre maximal de PIC Nombre maximal de membres AMS
MX240 2 4 4
MX480 5 10 10
MX960 7 14 14

Remarque :

Vous ne pouvez pas configurer les options de services à la fois au niveau ams (agrégat) et au niveau de l’interface membre. Si les options de services sont configurées sur ms-x/y/z ou vms-x/y/z, elles s’appliquent également aux ensembles de services sur 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 des membres individuels, configurez les options de services au niveau de l’interface des membres.

Remarque :

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 les clés de hachage arbitraires, offrant de meilleures options d’équilibrage de charge pour permettre l’exécution d’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 direct, des routes basées sur les adresses des pools sont utilisées pour diriger les paquets de flux inverse.

Remarque :

Jusqu’à la version 13.3 de Junos OS, un alias d’interface logique était créé en interne pour chaque interface logique multimédia sur laquelle des services étaient configurés (services de style d’interface). Cet alias d’interface stocke les chaînes de topologie pour les fonctionnalités qui sont exécutées sur l’interface logique après le traitement d’un service d’entrée afin d’éviter les boucles de paquets dans le système. Avec les alias d’interface, le nombre maximal d’interfaces logiques prises en charge avec les services a été réduit de moitié par rapport au nombre maximal pris en charge, car chaque interface logique consommait deux entrées, à savoir une pour l’interface elle-même et l’autre pour l’alias d’interface.

À partir de la version 14.1R4 de Junos OS, les alias d’interface d’entrée ne sont pas créés pour les MS-MPC et MS-MIC. Par conséquent, le nombre maximal d’interfaces logiques prises en charge par les PIC de services est égal au nombre maximal pris en charge sur le système. Une fois le service d’entrée traité par les MS-MPC et MS-MIC, le PIC de services envoie le paquet au moteur de transfert de paquets sur l’interface logique multiservices (ms-) où le service correspondant est configuré. Les post-services ne sont pas pris en charge sur les MS-MPC et MS-MIC dans Junos OS version 13.2 et ultérieure.

Remarque :

Vous ne pouvez pas inclure de MS-DPC ou d’autres MS-PIC dans une configuration AMS qui contient des MS-MIC ou des MS-MPC en tant qu’interfaces membres.

Remarque :

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.

Par défaut, la distribution du trafic sur les interfaces membres d’une interface AMS se fait de manière circulaire. Vous pouvez également configurer les valeurs de clé de hachage suivantes pour réguler la répartition 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 de hachage symétrique garantit que le trafic aller et arrière est acheminé via la même interface membre.

Avec le NAT44 de base, l’équilibrage de charge sur les interfaces AMS des MS-MIC et MS-MPC ne fonctionne pas correctement si la clé de hachage entrante est l’adresse IP source et la clé de hachage de sortie l’adresse IP de destination.

Si l’ensemble de services est appliqué sur l’interface Gigabit Ethernet ou 10-Gigabit Ethernet qui fonctionne comme interface interne NAT, les clés de hachage utilisées pour l’équilibrage de charge peuvent être configurées de telle sorte que la clé entrante est 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 hacher le 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é entrante de l’interface intérieure équilibre la charge et pour le trafic inverse, la clé entrante de l’interface externe équilibre la charge ou les sauts suivants par membre orientent le trafic inverse. Avec les services de type interface, la clé d’entrée équilibre la charge vers le transfert du trafic et la clé de sortie équilibre la charge vers le transfert du trafic ou les sauts suivants par membre orientent le trafic en sens inverse. Le trafic aller correspond au trafic entrant par le côté interne d’un ensemble de services et le trafic inverse est le trafic entrant par le côté externe d’un ensemble de services. La touche avant est la clé dièse utilisée pour le sens aller du trafic et la touche inverse est la clé dièse utilisée pour le sens inverse du trafic (selon qu’il s’agit de services d’interface ou de style de services de saut suivant).

Avec les pare-feu dynamiques, vous pouvez configurer les combinaisons suivantes de touches 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 touche directe, REV-KEY désigne la touche inverse, SIP signifie l’adresse IP source, DIP signifie l’adresse IP de destination et PROTO fait référence à un protocole tel que IP.

  • TOUCHE FOR : SIP, CLÉ DE ROTATION : DIP

  • FOR-KEY : SIP,PROTO REV-KEY : DIP, PROTO

  • TOUCHE FOR : DIP, CLÉ DE ROTATION : SIP

  • FOR-KEY : DIP,PROTO REV-KEY : SIP, PROTO

  • FOR-KEY : SIP,DIP REV-KEY : SIP, DIP

  • FOR-KEY : SIP,DIP,PROTO REV-KEY : SIP, DIP,PROTO

Avec le NAT statique configuré comme NAT44 de base ou NAT44 de destination, et avec le pare-feu dynamique configuré ou non, si le sens de transfert du trafic doit subir un traitement NAT, configurez les clés de hachage comme suit :

  • TOUCHE FOR : DIP, CLÉ DE ROTATION : SIP

  • FOR-KEY : 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 :

  • TOUCHE FOR : SIP, CLÉ DE ROTATION : DIP

  • FOR-KEY : SIP,PROTO REV-KEY : DIP, PROTO

Avec le NAT dynamique configuré et avec le pare-feu dynamique configuré ou non, seul le trafic aller peut subir le NAT. La clé de hachage directe peut être n’importe quelle combinaison de SIP, DIP et protocole, et la clé de hachage inverse est ignorée.

Remarque :

La configuration AMS de Junos OS prend en charge le trafic IPv4 et IPv6.

Présentation du trafic IPv6 sur les interfaces AMS

À partir de la version 14.2R1 de Junos OS, 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.

Lorsqu’une interface membre d’un bundle AMS tombe en panne, 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 d’environ 1/M du trafic (flux/sessions) est affectée, car cette quantité de trafic est déplacée du membre ayant échoué vers les membres restants. Lorsque l’interface membre défaillante est remise en ligne, seule une fraction du trafic est redistribuée au nouveau membre. Si N membres sont actuellement actifs, le résultat attendu est que seule une fraction environ 1/(N+1) du trafic (flux/sessions) est affectée, car cette quantité de trafic est déplacée vers le nouveau membre restauré. Les valeurs 1/M et 1/(N+1) supposent que les flux sont uniformément répartis 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és d’équilibrage de charge).

Comme pour le trafic IPv4, pour les paquets IPv6, un bundle AMS ne doit contenir que des membres d’un seul type de PIC de services. Des bundles AMS distincts sur le même routeur peuvent contenir des membres de différents types de PIC de services (par exemple, deux MS-MICs dans ams0 et deux PIC MS-MPC dans ams1).

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 monte ou descend. 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 sert 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 rabâchage. 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 montent et descendent.

Les définitions précédentes des flux d’origine et redistribués pour les interfaces membres s’appliquent aux observations suivantes :

  • 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 se déplacent entre les états haut et bas.

  • Les flux redistribués des membres d’un membre peuvent changer lorsque les 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é des membres peut varier considérablement en fonction de la diminution ou de la hausse des autres membres. Bien qu’il puisse sembler que lorsqu’un membre tombe, 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 conservés de manière efficace, ce comportement est uniquement dû à un rééquilibrage statique ou basé sur le hachage du trafic entre les membres actifs.

La fonctionnalité de minimisation du rabâchage gère uniquement les changements opérationnels dans le statut d’une interface membre (par exemple, membre hors ligne ou réinitialisation du membre de 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écessitent que les PIC membres soient rejetés. Le NAT ou l’épinglage à cheveux n’est pas pris en charge, comme 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 AMS offre également une prise en charge du basculement et de la haute disponibilité. Vous pouvez configurer l’une des interfaces membres en tant qu’interface de secours qui devient active en cas de défaillance de l’une des autres interfaces membres, ou configurer l’AMS de manière à ce que lorsque l’une des interfaces membres tombe en panne, le trafic affecté à cette interface soit partagé entre les interfaces actives.

L’instruction member-failure-options de configuration vous permet de configurer comment gérer le trafic en cas de défaillance d’une interface membre. Une option consiste à redistribuer le trafic immédiatement entre les autres interfaces membres. Cependant, la redistribution du trafic implique un nouveau calcul des balises de hachage et peut entraîner une certaine interruption 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 de nouveau en ligne, rejoin-timeoutaprès quoi l’AMS peut redistribuer le trafic entre les autres interfaces membres. Si l’interface membre défaillante se ractive 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 réintégration de l’interface défaillante lorsqu’elle est de nouveau 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’il est de nouveau en ligne. Dans ce cas, vous pouvez le joindre 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 sont instables.

Remarque :

Lorsqu’ils member-failure-options ne sont pas configurés, le comportement par défaut consiste à 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 sauvegarde. Lorsqu’une interface membre tombe en panne, l’interface de secours gère le trafic affecté à l’interface défaillante. Lorsque l’interface défaillante est de nouveau en ligne, elle devient la nouvelle interface de sauvegarde.

Dans une configuration plusieurs-à-un (N :1), une seule interface de sauvegarde prend en charge toutes les autres interfaces membres du groupe. Si l’une des interfaces membres tombe en panne, l’interface de secours 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.

À partir de la version 16.1 de Junos OS, une seule interface active est couplée à une seule interface de secours dans une configuration individuelle. Si l’interface active tombe en panne, l’interface de secours prend le relais. Les configurations utilisant member-failure-options ne sont pas disponibles pour les configurations à haute disponibilité individuelles (1:1).

Lorsque les deux member-failure-options et high-availability-options sont configurés pour un AMS, la high-availability-options configuration a la priorité sur la member-failure-options configuration. Si une deuxième défaillance se produit avant que l’interface défaillante ne soit de nouveau en ligne pour être la nouvelle sauvegarde, la member-failure-options configuration prend effet.

Redondance de secours à chaud

À partir de la version 17.2R1 de Junos OS, vous pouvez utiliser la même interface de services que la sauvegarde dans plusieurs interfaces AMS, ce qui offre une option de veille à chaud N :1 pour les MS-MPC et les MS-MIC.

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 en cas de défaillance de l’interface principale.

Pour configurer la veille à chaud sur une interface AMS, vous 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.

Configuration d’interfaces multiservices agrégées

La configuration d’interface multiservices agrégés (AMS) de Junos OS vous permet de combiner les interfaces de services de plusieurs PIC pour créer un ensemble d’interfaces qui peut fonctionner comme une seule interface. Vous identifiez le PIC que vous souhaitez utiliser comme sauvegarde.

  1. Créez une interface multiservices agrégée et ajoutez des interfaces membres. À partir de la version 19.3R2 de Junos OS, une interface AMS de services nouvelle génération MX-SPC3 peut avoir jusqu’à 14 interfaces membres avec un maximum de 7 cartes de services MX-SPC3 avec un maximum de 2 PIC sur chaque carte. Depuis Junos OS version 16.2, une interface MS-MPC AMS peut avoir jusqu’à 36 interfaces membres. Dans Junos OS version 16.1 et antérieure, une interface AMS peut avoir un maximum de 24 interfaces membres.
    Remarque :

    Le format de l’interface membre est mams-a/b/0, où a est le numéro d’emplacement du concentrateur PIC flexible (FPC) et b est le numéro d’emplacement du PIC.

    Par exemple, sur une MS-MPC, qui peut avoir jusqu’à quatre PIC :

    Par exemple, sur un MX-SPC3, qui peut avoir jusqu’à deux PIC :

  2. Configurez les unités logiques pour l’interface AMS.

    Par exemple :

  3. Configurez les options d’échec des membres.

    Par exemple :

  4. Configurez la sauvegarde préférée.

    Par exemple :


  5. Remarque :

    Cette étape ne s’applique pas à la carte de services MX-SPC3 des services nouvelle génération dans le châssis MX240, MX480 ou MX960.

    Si l’interface AMS compte plus de 24 interfaces membres, définissez la valeur du délai d’expiration de démarrage du PIC de service sur 240 ou 300 secondes pour chaque PIC de services sur le routeur MX Series. Nous vous recommandons d’utiliser une valeur de 240.

    Remarque :

    À partir de la version 16.2 de Junos OS, une interface AMS peut comporter jusqu’à 36 interfaces membres. Dans Junos OS version 16.1 et antérieure, une interface AMS peut avoir un maximum de 24 interfaces membres.

    Par exemple :

Configuration de l’équilibrage de charge sur l’infrastructure AMS

La configuration de l’équilibrage de charge nécessite un système multiservices agrégé (AMS). L’AMS implique le regroupement de plusieurs PIC de services. Une configuration AMS élimine le besoin de routeurs séparés au sein d’un système. Le principal avantage d’une configuration AMS est la possibilité de prendre en charge l’équilibrage de charge du trafic entre plusieurs PIC de services.

AMS est pris en charge sur les MS-MPC et MS-MIC. À partir de la version 19.3R2 de Junos OS, les interfaces AMS sont prises en charge sur le MX-SPC3.

La haute disponibilité (HA) est prise en charge sur l’infrastructure AMS sur toutes les plates-formes de routage universelles MX Series 5G. AMS présente plusieurs avantages :

  • Prise en charge de la configuration du comportement en cas d’échec d’un PIC de services faisant partie de la configuration AMS

  • Prise en charge de la spécification de clés de hachage pour chaque service défini dans les deux sens

  • Prise en charge de l’ajout de routes à des PIC individuels dans le système AMS

Configuration de l’infrastructure AMS

AMS prend en charge l’équilibrage de charge sur plusieurs ensembles de services. L’ensemble du trafic entrant ou sortant d’un ensemble de services peut être équilibré en charge entre les différents PIC de services. Pour activer l’équilibrage de charge, vous devez configurer une interface agrégée avec des interfaces de services existantes.

Pour configurer le comportement de défaillance dans AMS, incluez l’instruction member-failure-options :

En cas de défaillance d’un PIC, vous pouvez configurer le trafic vers le PIC défaillant pour qu’il soit redistribué à l’aide de l’instruction redistribute-all-traffic au niveau de la [edit interfaces interface-name load-balancing-options member-failure-options] hiérarchie. Si l’instruction drop-member-traffic est utilisée, tout le trafic vers le PIC ayant échoué est abandonné. Les deux options s’excluent mutuellement.

Remarque :

Si member-failure-options n’est pas configuré explicitement, le comportement par défaut consiste à abandonner le trafic des membres avec un délai d’expiration de 120 secondes.

Seules les interfaces mams (interfaces de services qui font partie d’AMS) peuvent être agrégées. Une fois qu’une interface AMS a été configurée, vous ne pouvez pas configurer les interfaces mams constitutives individuelles. Une interface mams- ne peut pas être utilisée comme interface ams (cela ne s’applique pas aux services nouvelle génération MX-SPC3). AMS prend en charge IPv4 (family inet) et IPv6 (family inet6). Vous ne pouvez pas configurer les adresses sur une interface AMS. La traduction d’adresses réseau (NAT) est la seule application qui s’exécute actuellement sur l’infrastructure AMS.

Remarque :

Vous ne pouvez pas configurer l’unité 0 sur une interface AMS.

Pour prendre en charge plusieurs applications et différents types de traduction, l’infrastructure AMS prend en charge la configuration du hachage pour chaque ensemble de services. Vous pouvez configurer les clés de hachage séparément pour l’entrée et la sortie. La configuration par défaut utilise l’adresse IP source, l’adresse IP de destination et le protocole de hachage ; L’interface entrante pour l’entrée et l’interface sortante pour la sortie sont également disponibles.

Remarque :

Lorsque vous utilisez AMS dans une configuration à charge équilibrée pour la solution NAT, le nombre d’adresses IP NAT doit être supérieur ou égal au nombre d’interfaces mams actives que vous avez ajoutées au bundle AMS.

Configuration de la haute disponibilité

Dans un système AMS configuré avec une haute disponibilité, un PIC de services désignés agit comme une sauvegarde pour d’autres PIC actifs qui font partie du système AMS dans une configuration de secours plusieurs-à-un (N :1). Dans une configuration de sauvegarde N :1, un PIC est disponible en tant que sauvegarde pour tous les autres PIC actifs. Si l’un des PIC actifs tombe en panne, le PIC de secours prend le relais du PIC ayant échoué. Dans une configuration de sauvegarde N :1 (sans état), les états du trafic et les structures de données ne sont pas synchronisés entre les PIC actifs et le PIC de secours.

Un système AMS prend également en charge une configuration un-à-un (1:1). Dans le cas d’une sauvegarde 1:1, une interface de sauvegarde est associée à une seule interface active. Si l’interface active tombe en panne, l’interface de secours prend le relais. Dans une configuration 1:1 (à états), les états du trafic et les structures de données sont synchronisés entre les PIC actifs et le PIC de secours. Une synchronisation à états est nécessaire pour la haute disponibilité des connexions IPsec. Pour les connexions IPsec, AMS prend en charge la configuration 1:1 uniquement.

Remarque :

Les connexions IPsec ne sont pas prises en charge sur le MX-SPC3 dans cette version.

La haute disponibilité pour l’équilibrage de charge est configurée en ajoutant l’instruction high-availability-options au niveau de la [edit interfaces interface-name load-balancing-options] hiérarchie.

Pour configurer la haute disponibilité N :1, incluez l’instruction high-availability-options avec l’option many-to-one :

À partir de la version 16.1 de Junos OS, vous pouvez configurer la haute disponibilité 1:1 dynamique sur une MS-MPC. Pour configurer une haute disponibilité 1:1 dynamique au niveau de la [edit interfaces interface-name load-balancing-options] hiérarchie, incluez l’instruction high-availability-options avec l’option one-to-one :

Remarque :

La carte de services MX-SPC3 des services de nouvelle génération ne prend pas en charge la haute disponibilité AMS 1:1.

Équilibrage de charge des flux de traduction d’adresses réseau

La traduction d’adresses réseau (NAT) a été programmée en tant que plug-in et est une fonction d’équilibrage de charge et de haute disponibilité. Le plug-in fonctionne sur l’infrastructure AMS. Tous les flux à traduire sont automatiquement distribués aux différents PIC de services qui font partie de l’infrastructure AMS. En cas de défaillance d’un PIC de services actif, le PIC de secours configuré prend en charge les ressources du pool NAT du PIC ayant échoué. La méthode de hachage choisie dépend du type de NAT. L’utilisation de NAT sur une infrastructure AMS présente quelques limites :

  • Les flux NAT vers les PIC ayant échoué ne peuvent pas être restaurés.

  • Les flux IPv6 ne sont pas pris en charge.

    Les pools d’adresses IPv6 ne sont pas pris en charge avec AMS, mais NAT64 est pris en charge avec AMS, de sorte que les flux IPv6 entrent dans AMS.

    NAT64 est pris en charge pour les services nouvelle génération sur la carte de services MX-SPC3, il n’y a pas de prise en charge de NAT66. Les flux IPv6 pour différents services NAT sont pris en charge, sauf si la conversion doit être IPv6 en IPv6 ou IPv4 en IPv6.

  • Twice NAT n’est pas pris en charge pour l’équilibrage de charge sur les cartes MS-MPC.

    Deux fois le NAT est pris en charge pour l’équilibrage de charge sur la carte de services MX-SPC3 des services de nouvelle génération.

  • Le NAT déterministe (DetNat) utilise une configuration AMS en veille chaude et peut répartir la charge à l’aide de plusieurs bundles AMS en mode veille chaude.

Configuration de la mise en veille à chaud pour les interfaces de services

Vous pouvez configurer une option de veille à chaud N :1 pour les MS-MPC, MS-MIC et MX-SPC3 en créant plusieurs interfaces multiservices agrégées (AMS), chacune contenant l’interface de service que vous souhaitez sauvegarder et l’interface de service qui sert de sauvegarde. La même interface de service de sauvegarde peut être utilisée dans toutes ces interfaces AMS. À partir de la version 19.3R2 de Junos OS, l’option de veille à chaud N :1 est prise en charge sur le MX-SPC3.

Pour configurer des interfaces de mise en veille à chaud pour les services :

  1. Créez une interface AMS.

    La variable N est un nombre unique, tel que 0 ou 1.

  2. Spécifiez l’interface de service principale que vous souhaitez sauvegarder.

    La variable a est le numéro d’emplacement FPC et b le numéro d’emplacement PIC pour l’interface de service principale.

  3. Spécifiez l’interface de service secondaire, qui sauvegarde l’interface principale.

    La variable a est le numéro d’emplacement FPC et b est le numéro d’emplacement PIC pour l’interface de service secondaire.

  4. Répétez les étapes 1 à 3 pour créer une interface AMS pour chaque interface de service que vous souhaitez sauvegarder. Vous pouvez utiliser la même interface de service secondaire dans chaque interface AMS.

Exemple : configuration d’une interface multiservices agrégée (AMS)

Exigences matérielles et logicielles

Cet exemple nécessite des routeurs MX Series qui ont des interfaces de services installées et Junos OS version 13.2 exécutée dessus.

Vue d’ensemble

La configuration d’interface multiservices agrégés (AMS) de Junos OS vous permet de combiner plusieurs interfaces de services pour créer un ensemble d’interfaces qui peut fonctionner comme une seule interface. Cet exemple vous montre comment configurer une interface AMS, les options d’équilibrage de charge, les options de défaillance des membres, les paramètres de haute disponibilité sur une interface AMS et une configuration d’ensemble de services de style interface qui utilise l’interface AMS.

Remarque :

Vous ne pouvez pas inclure de MS-DPC ou d’autres PIC multiservices dans une configuration AMS qui contient des MS-MIC ou des MS-MPC comme interfaces membres.

Un MS-PIC ne contient qu’une seule interface, tandis que le MS-MPC en contient quatre. Pour utiliser l’ensemble du MS-MPC dans un seul bundle AMS, les quatre interfaces membres doivent être affectées à ce bundle AMS.

Gardez les points suivants à l’esprit pour chaque interface membre (puce XLP) qui doit faire partie du lot d’interfaces AMS :

  • Les cartes de ligne XLP d’une même MPC peuvent faire partie de plusieurs offres groupées AMS.

  • Plusieurs puces XLP issues de plusieurs MPC peuvent également faire partie d’un seul bundle (jusqu’à huit interfaces membres dans un bundle AMS, selon les besoins de déploiement).

  • Il n’est pas nécessaire que toutes les puces XLP d’un même MS-MPC fassent partie du même bundle AMS. Certaines puces XLP peuvent faire partie d’un bundle AMS, tandis que d’autres puces XLP peuvent être des interfaces autonomes ms- ou ne pas avoir besoin d’être configurées. Cependant, la même puce XLP ne peut pas faire partie de deux interfaces AMS différentes en même temps. Par exemple, chaque puce XLP d’un même MS-MPC peut être regroupée en quatre offres groupées AMS différentes, en fonction des besoins de déploiement.

  • Un maximum de huit interfaces membres peut être attribué à un lot AMS.

Pour plus d’informations sur les interfaces AMS, consultez Présentation des interfaces multiservices agrégées.

La configuration

Procédure

Configuration rapide de la CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez-collez les commandes dans la CLI au niveau de la hiérarchie [modifier].

Ajout d’interfaces membres

Configuration des unités logiques

Configuration des options de défaillance des membres

Configuration des options de haute disponibilité

Configuration des services d’ensemble de services et d’interface

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI.

  1. Créez une interface multiservices agrégée et ajoutez des interfaces membres.

    Remarque :

    Vous ne pouvez pas configurer les mêmes mams pour qu’ils fassent partie de deux interfaces AMS différentes en même temps.

  2. Configurez les unités logiques pour l’interface AMS.

    Remarque :

    Une interface AMS et ses interfaces membres ne peuvent pas partager les mêmes unités d’interface logique. Par exemple, si les unités logiques 1 et 2 sont configurées sur l’une des interfaces membres, vous ne pouvez pas configurer les unités logiques 1 et 2 pour l’AMS. De même, si vous avez configuré les unités logiques 3 et 4 sur l’AMS, vous ne pouvez pas configurer ces unités sur aucune des interfaces membres.

  3. Configurez les options d’échec des membres.

    Remarque :

    Cet exemple montre la drop-member-traffic configuration. Toutefois, si vous souhaitez redistribuer le trafic à d’autres membres disponibles lorsque l’une des interfaces membres tombe en panne, vous pouvez inclure l’instruction à la redistribute-all-traffic place de l’instruction drop-member-traffic .

    Le comportement par défaut, lorsque la configuration n’est pas incluse, consiste à abandonner le member-failure-options trafic des membres avec un délai d’expiration de 120 secondes.

  4. Configurez les options de haute disponibilité.

  5. Configurez les services de style d’interface.

  6. Si vous avez terminé de configurer l’appareil, validez la configuration.

    Tableau 1 : instructions de configuration clés utilisées dans cet exemple

    Déclaration

    Descriptif

    member-interface

    Ajoute une interface membre (mams) à l’offre groupée AMS.

    drop-member-traffic

    Spécifie que tout le trafic vers un membre doit être abandonné en cas de défaillance de l’interface membre.

    rejoin-timeout

    Spécifie l’intervalle de temps, en secondes, pendant lequel l’AMS doit attendre avant de déclarer une interface membre inactive. Si le membre défaillant revient en ligne pendant cette période, il peut rejoindre l’AMS et reprendre le transfert de trafic.

    La plage est comprise entre 0 et 1000 secondes.

    enable-rejoin

    Spécifie si une interface défaillante doit être autorisée à rejoindre l’AMS lorsqu’elle est de nouveau en ligne.

    Si cette instruction n’est pas incluse dans la configuration, vous devez ajouter manuellement l’interface à l’AMS lorsque l’interface est de nouveau en ligne.

    preferred-backup

    Désigne une interface membre comme sauvegarde flottante.

    interface-services

    Spécifie une interface de service, une interface AMS dans cet exemple, pour gérer les services d’interface.

    hash-keys

    Spécifie les clés de hachage d’équilibrage de charge. Vous pouvez configurer les valeurs de clé de hachage suivantes : , , (interface entrante), oif (interface sortante) et protocol. iif destination-ipsource-ip

    Remarque :

    Pour les services qui nécessitent une symétrie du trafic, vous devez configurer le hachage symétrique. La configuration de hachage symétrique garantit que le trafic aller et arrière est acheminé via la même interface membre.

Résultats

Dans le mode de configuration, confirmez votre configuration en entrant la show interfaces ams0 commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de la configuration AMS

Objet

Vérifiez la configuration AMS et l’état des interfaces membres.

Mesures à prendre

À partir du mode opérationnel, entrez la show commande.

Signification

Affiche que ams0 comporte six interfaces membres avec une configuration de sauvegarde plusieurs-à-un. Sur les six interfaces membres, cinq sont en état actif et une, mams-1/0/0, est en état de secours.

Exemple : Configuration de services de style saut suivant sur une interface multiservices agrégée

La configuration

Configuration rapide de la CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez-collez les commandes dans la CLI au niveau de la hiérarchie [modifier].

Configuration d’une interface multiservices agrégée

Configuration d’instances de routage utilisant des interfaces AMS

Configuration des clés de hachage

Configurer les services de saut suivant

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, reportez-vous à la section « Utilisation de l’éditeur CLI en mode configuration » dans le Guide de l’utilisateur de la CLI.

  1. Configurez une interface multiservices agrégée et les options d’équilibrage de charge.

  2. Configurez les instances de routage qui utilisent les interfaces multiservices agrégées configurées à la première étape.

  3. Configurez les clés de hachage pour les interfaces multiservices agrégées.

    Remarque :

    Contrairement à la configuration de type interface où les clés de hachage sont définies dans la configuration d’ensemble de services, pour les services de saut suivant, les clés de hachage sont spécifiées dans la configuration AMS sous les unités logiques.

  4. Configurez les services de style saut suivant dans la configuration de l’ensemble de services.

  5. Validez la configuration.

Résultats

En mode configuration, confirmez votre configuration en entrant les show interfaces ams0commandes , show routing-instanceset show services service-set ams-test . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Exigences matérielles et logicielles

Routeurs MX Series avec interfaces de services installées et exécutant Junos OS version 13.2.

Vue d’ensemble

À partir de la version 13.2, Junos OS étend la prise en charge des services de type next-hop aux interfaces multiservices agrégés (AMS). Dans les versions antérieures à 12.3, seules les configurations de services de style d’interface étaient prises en charge sur les interfaces AMS.

La configuration des services de style de saut suivant sur les interfaces AMS est différente de la configuration des services de style d’interface. Pour les services de type saut suivant, les clés de hachage d’équilibrage de charge sont définies dans le cadre de la configuration d’unité logique de l’interface AMS. Pour les services de style d’interface, la configuration des clés de hachage relève de la configuration définie par les services.

Cet exemple explique la configuration des services de style saut suivant sur une interface AMS et montre les étapes de vérification pour vérifier que la configuration fonctionne correctement.

Exemple : configuration de la traduction de source statique sur une infrastructure AMS

Cet exemple montre une traduction de source statique configurée sur une interface AMS. Les flux seront répartis en charge entre les interfaces membres avec cet exemple.

Configurez l’interface ams0 AMS avec des options d’équilibrage de charge.

Configurez le hachage pour l’ensemble de services pour le trafic entrant et sortant.

Remarque :

Le hachage est déterminé selon que l’ensemble de services est appliqué à l’interface entrante ou sortante.

Configurez deux pools NAT, car vous avez configuré deux interfaces membres pour l’interface AMS.

Configurez la règle NAT et la traduction.

Remarque :

Une configuration similaire peut être appliquée pour les types dynamic-nat44 de traduction et napt-44. Twice NAT ne peut pas s’exécuter sur l’infrastructure AMS pour le moment.

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.

Libération
Descriptif
19.3R2
À partir de Junos OS version 19.3R2, une interface AMS de services nouvelle génération MX-SPC3 peut avoir jusqu’à 16 interfaces membres avec un maximum de 8 cartes de services MX-SPC3 avec jusqu’à 2 PIC sur chaque carte.
19.3R2
À partir de la version 19.3R2 de Junos OS, les interfaces AMS sont prises en charge avec le MX-SPC3.
19.3R2
À partir de la version 19.3R2 de Junos OS, l’option de veille à chaud N :1 est également prise en charge sur le MX-SPC3 si vous exécutez des services de nouvelle génération.
19.2R1
À partir de la version 19.2R1 de Junos OS, vous pouvez utiliser jusqu’à 60 PIC sur différents bundles AMS sur un routeur MX2020. La limite stricte de 36 interfaces membres maximum par bundle AMS existe toujours. Cependant, dans le châssis, il peut y avoir plusieurs bundles AMS, de sorte que 15 MS-MPC peuvent être configurés sur ces bundles.
17.2R1
À partir de la version 17.2R1 de Junos OS, vous pouvez utiliser la même interface de services que la sauvegarde dans plusieurs interfaces AMS, ce qui offre une option de veille à chaud N :1 pour les MS-MPC et les MS-MIC.
17.1
À partir de la version 17.1R1 de Junos OS, AMS prend en charge la distribution de tunnel IPSec pour les ensembles de services de type saut suivant. Toutefois, les ensembles de services IPSec de type interface ne sont pas pris en charge.
16.2
À partir de Junos OS version 16.2 (à l’exception de Junos OS version 17.3R3-S7), une interface AMS peut avoir jusqu’à 36 interfaces membres.
16.2
Depuis Junos OS version 16.2, une interface MS-MPC AMS peut avoir jusqu’à 36 interfaces membres.
16.1
À partir de la version 16.1 de Junos OS, une seule interface active est couplée à une seule interface de secours dans une configuration individuelle. Si l’interface active tombe en panne, l’interface de secours prend le relais.
16.1
À partir de la version 16.1 de Junos OS, vous pouvez configurer la haute disponibilité 1:1 dynamique sur une MS-MPC.
14.2
À partir de la version 14.2R1 de Junos OS, vous pouvez utiliser des interfaces AMS pour le trafic IPv6.
14.1
À partir de la version 14.1R4 de Junos OS, les alias d’interface d’entrée ne sont pas créés pour les MS-MPC et MS-MIC.