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

Présentation des 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 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).

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

La configuration d’AMS permet aux ensembles de services de prendre en charge plusieurs PIC de services en associant un bundle 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 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.

À 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 démarrage du PIC de service à 240 ou 300 secondes pour tous les PIC de service. Dans Junos OS version 16.1 et antérieures, et dans Junos OS version 17.3R3-S7, une interface AMS pouvait avoir un maximum de 24 interfaces membres.

À partir de la version 17.1R1 de Junos OS, AMS prend en charge la distribution de tunnels IPSec pour les ensembles de services de type next-hop. 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. Toutefois, 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 au niveau de l’agrégat.

À 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
Le MX240 2 4 4
Réf. MX480 5 10 10
Réf. MX960 7 14 14

Note:

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 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 chaque membre, configurez les options de services au niveau de l’interface du membre.

Note:

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.

Note:

Jusqu’à la version 13.3 de Junos OS, un alias d’interface logique était créé en interne pour chaque interface logique de support sur laquelle les services étaient configurés (services de style 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 par les services a été réduit de moitié par rapport au nombre maximal pris en charge, car chaque interface logique consommait deux entrées, l’une pour l’interface elle-même et l’autre pour l’alias d’interface.

À partir de Junos OS version 14.1R4, les alias d’interface d’entrée ne sont pas créés pour les MS-MPC et les MS-MIC. Par conséquent, le nombre maximal d’interfaces logiques prises en charge avec les PIC de services est égal au nombre maximal pris en charge sur le système. Après le traitement des services d’entrée par les MS-MPC et les MS-MIC, le PIC des 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.

Note:

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.

Note:

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 répartition du trafic sur les interfaces membres d’une interface AMS s’effectue selon la méthode Round Robin. Vous pouvez également 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.

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 d’entrée est l’adresse IP source et la clé de hachage de sortie est l’adresse IP de destination.

Si l’ensemble de services est appliqué à l’interface Gigabit Ethernet ou 10 Gigabit Ethernet qui fait office d’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.

Note:

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.

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. Sur le même routeur, des bundles AMS distincts peuvent contenir des membres de différents types de PIC de services (par exemple, deux MS-MIC dans ams0 et deux MS-MPC PICs 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 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.

Note:

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.

À partir de la version 16.1 de Junos OS, dans une configuration individuelle, une seule interface active est associée à une seule interface de secours. En cas de défaillance de l’interface active, l’interface de sauvegarde prend le relais. Les configurations utilisant member-failure-options ne sont pas disponibles pour les configurations de haute disponibilité un-à-un (1:1).

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 Junos OS version 17.2R1, vous pouvez utiliser la même interface de services que la sauvegarde dans plusieurs interfaces AMS, ce qui permet d’obtenir 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 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.

configuration d’interfaces multiservices agrégées

La configuration d’interface multiservices agrégée (AMS) de Junos OS vous permet de combiner des interfaces de services à partir de plusieurs PIC pour créer un ensemble d’interfaces pouvant fonctionner comme une interface unique. 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 MX-SPC3 de nouvelle génération peut avoir jusqu’à 14 interfaces membres avec un maximum de 7 cartes de services MX-SPC3 avec jusqu’à 2 PICs sur chaque carte. À partir de la version 16.2 de Junos OS, une interface MS-MPC AMS peut avoir jusqu’à 36 interfaces membres. Sous Junos OS version 16.1 et antérieure, une interface AMS peut avoir un maximum de 24 interfaces membres.
    Note:

    Le format de l’interface membre est mams-a/b/0, où a est le numéro de slot FPC (Flexible PIC Concentrator) et b est le numéro de slot PIC.

    Par exemple, sur un 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 de défaillance des membres.

    Par exemple:

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

    Par exemple:


  5. Note:

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

    Si l’interface AMS comporte plus de 24 interfaces membres, définissez la valeur du délai d’expiration 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.

    Note:

    À 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 pouvait 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 AMS (Aggregated Multiservices). L’AMS consiste à regrouper 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 de toutes les plates-formes de routage universelles 5G MX Series. L’AMS présente plusieurs avantages :

  • Prise en charge de la configuration du comportement en cas de défaillance 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 ensemble de services dans un sens ou dans l’autre

  • Prise en charge de l’ajout d’itinéraires vers 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. Tout le trafic entrant ou sortant d’un ensemble de services peut faire l’objet d’un équilibrage de charge entre différents services PICs. Pour activer l’équilibrage de charge, vous devez configurer une interface agrégée avec les interfaces de services existantes.

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

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.

Note:

S’il 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 faisant partie d’AMS) peuvent être agrégées. Une fois qu’une interface AMS a été configurée, vous ne pouvez pas configurer les différentes interfaces mams- constitutives. Une interface mams- ne peut pas être utilisée en tant qu’interface ams (cela ne s’applique pas aux services MX-SPC3 de nouvelle génération). AMS prend en charge IPv4 (family inet) et IPv6 (family inet6). Vous ne pouvez pas configurer d’adresses sur une interface AMS. À l’heure actuelle, Network Address Translation (NAT) est la seule application qui s’exécute sur l’infrastructure AMS.

Note:

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 touches 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.

Note:

Lors de l’utilisation d’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é agit comme une sauvegarde pour les autres PIC actifs qui font partie du système AMS dans une configuration de sauvegarde 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. En cas de défaillance de l’un des PIC actifs, le PIC de sauvegarde prend le relais. 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 sauvegarde.

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. En cas de défaillance de l’interface active, l’interface de sauvegarde prend le relais. Dans une configuration 1:1 (dynamique), les états du trafic et les structures de données sont synchronisés entre les PIC actifs et le PIC de secours. Une synchronisation dynamique est requise pour assurer la haute disponibilité des connexions IPsec. Pour les connexions IPsec, AMS prend uniquement en charge la configuration 1:1.

Note:

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 avec l’option high-availability-options many-to-one :

À partir de Junos OS version 16.1, vous pouvez configurer la haute disponibilité 1:1 dynamique sur un MS-MPC. Pour configurer la 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 :

Note:

La carte de services MX-SPC3 de Next Gen Services ne prend pas en charge la haute disponibilité AMS 1:1.

Équilibrage de charge Flux de traduction d’adresses réseau

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

  • Les flux NAT vers les PIC défaillants 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 de 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 traduction doit être IPv6 vers IPv6 ou IPv4 vers IPv6.

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

    Le NAT deux fois est pris en charge pour l’équilibrage de charge sur la carte de services MX-SPC3 de Next Gen Services.

  • Le NAT déterministe utilise une configuration AMS de secours à chaud et peut répartir la charge à l’aide de plusieurs faisceaux AMS en mode veille.

configuration de la veille à chaud pour les interfaces de services

Vous pouvez configurer une option de secours à chaud N :1 pour les MS-MPC, MS-MIC et MX-SPC3 en créant plusieurs interfaces AMS (Aggregated Multiservices), chacune contenant l’interface de service que vous souhaitez sauvegarder et l’interface de service qui fait office 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 la veille à chaud pour les interfaces de 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 de slot FPC et b est le numéro de slot PIC de 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 de slot FPC et b est le numéro de slot PIC de 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 sur lesquels des interfaces de services sont installées et Junos OS version 13.2 s’exécute dessus.

Aperçu

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

Note:

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 en tant qu’interfaces membres.

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

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

  • Les cartes de ligne XLP d’une même MPC peuvent faire partie de plusieurs bundles AMS.

  • Plusieurs puces XLP de plusieurs MPC peuvent également faire partie d’un seul bundle (jusqu’à huit interfaces membres dans un bundle AMS, selon les exigences 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’une même MS-MPC peut être regroupée en quatre bundles AMS différents, en fonction des besoins de déploiement.

  • Un maximum de huit interfaces membres peuvent être affectées à un bundle AMS.

Pour plus d’informations sur les interfaces AMS, reportez-vous à la section Présentation des interfaces multiservices agrégées.

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 et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].

Ajout d’interfaces membres

Configuration des unités logiques

Configuration des options de défaillance d’un membre

Configuration des options de haute disponibilité

Configuration de l’ensemble de services et des services 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 l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

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

    Note:

    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.

    Note:

    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 les interfaces membres.

  3. Configurez les options de défaillance des membres.

    Note:

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

    Le comportement par défaut, lorsque la configuration n’est pas incluse, consiste à supprimer le member-failure-options trafic des membres avec un délai d’expiration de rejoindre 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 : principales instructions de configuration utilisées dans cet exemple

    Déclaration

    Description

    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’il est remis 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 en tant que 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

    Note:

    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.

Résultats

Depuis le mode 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 de l’AMS

But

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

Action

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

Signification

Montre qu’il ams0 a six interfaces membres avec une configuration de sauvegarde plusieurs-à-un. Sur les six interfaces membres, cinq sont à l’état actif et une, mams-1/0/0, est à l’état de sauvegarde.

Exemple : configuration de services de type saut suivant sur une interface multiservices agrégée

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 et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].

Configuration d’une interface multiservices agrégée

Configuration des instances de routage qui utilisent 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 l’interface de ligne de commande, reportez-vous à la section « Utilisation de l’éditeur CLI en mode configuration » dans le Guide de l’utilisateur de l’interface de ligne de commande.

  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 lors de la première étape.

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

    Note:

    Contrairement à la configuration de type interface où les clés de hachage sont définies dans la configuration de l’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 type saut suivant dans la configuration de l’ensemble de services.

  5. Validez la configuration.

Résultats

Dans le mode de configuration, confirmez votre configuration en entrant les show interfaces ams0commandes , show routing-instances, et 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és et exécutant Junos OS version 13.2.

Aperçu

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

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

Cet exemple explique la configuration des services de type 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. Dans cet exemple, les flux seront équilibrés en charge entre les interfaces membres.

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

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

Note:

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.

Note:

Une configuration similaire peut être appliquée pour les types dynamic-nat44 de traduction et napt-44. À deux reprises, NAT ne peut pas fonctionner 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érer
Description
19.3R2
À partir de la version 19.3R2 de Junos OS, une interface AMS MX-SPC3 de nouvelle génération peut avoir jusqu’à 16 interfaces membres avec un maximum de 8 cartes de services MX-SPC3 avec jusqu’à 2 PICs 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. Toutefois, 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 Junos OS version 17.2R1, vous pouvez utiliser la même interface de services que la sauvegarde dans plusieurs interfaces AMS, ce qui permet d’obtenir 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 tunnels IPSec pour les ensembles de services de type next-hop. 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
À partir de la version 16.2 de Junos OS, une interface MS-MPC AMS peut avoir jusqu’à 36 interfaces membres.
16.1
À partir de la version 16.1 de Junos OS, dans une configuration individuelle, une seule interface active est associée à une seule interface de secours. En cas de défaillance de l’interface active, l’interface de sauvegarde prend le relais.
16.1
À partir de Junos OS version 16.1, vous pouvez configurer la haute disponibilité 1:1 dynamique sur un 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 Junos OS version 14.1R4, les alias d’interface d’entrée ne sont pas créés pour les MS-MPC et les MS-MIC.