SUR CETTE PAGE
Présentation des groupes d’agrégation de liens dans un cluster Chassis
Exemple : Configuration de groupes d’agrégation de liens dans un cluster de châssis
Comprendre le basculement d’un groupe d’agrégation de liens dans un cluster de châssis
Exemple : Configuration du nombre minimal de liaisons du cluster de châssis
Exemple : configuration de VRRP/VRRPv3 sur des interfaces Ethernet redondantes en cluster de châssis
Comportement des groupes d’agrégation de liens spécifiques à la plate-forme
Interfaces Ethernet agrégées dans un cluster de châssis
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Consultez la section Comportement des groupes d’agrégation de liens spécifiques à la plate-forme pour obtenir des remarques relatives à votre plate-forme.
Consultez la section Informations supplémentaires sur la plate-forme pour plus d’informations.
L’agrégation de liens IEEE 802.3ad vous permet de regrouper des interfaces Ethernet pour former une interface de couche de liaison unique, également appelée groupe d’agrégation de liens (LAG) ou bundle. Les interfaces LAG Redondant Ethernet (reth) combinent les caractéristiques des interfaces reth et des interfaces LAG. Pour plus d’informations, consultez les rubriques suivantes :
Présentation des groupes d’agrégation de liens dans un cluster Chassis
La prise en charge des groupes d’agrégation de liens Ethernet (LAG) basés sur IEEE 802.3ad permet d’agréger les interfaces physiques sur un périphérique autonome. Les LAG sur les appareils autonomes augmentent la bande passante de l’interface et la disponibilité des liaisons. L’agrégation de liens dans un cluster de châssis permet à une interface reth d’ajouter plus de deux interfaces enfants physiques, créant ainsi un LAG d’interface reth.
Les liaisons agrégées d’un LAG d’interface reth offrent les mêmes avantages en termes de bande passante et de redondance qu’un LAG sur un équipement autonome, avec en plus l’avantage de la redondance du cluster de châssis. Un LAG d’interface reth possède deux types de redondance simultanée. Les liens agrégés au sein de l’interface reth sur chaque nœud sont redondants ; Si une liaison de l’agrégat principal tombe en panne, sa charge de trafic est absorbée par les liaisons restantes. Si un nombre suffisant de liaisons enfants sur le nœud principal tombe en panne, le LAG de l’interface reth peut être configuré de manière à ce que tout le trafic de l’ensemble de l’interface reth bascule vers la liaison agrégée de l’autre nœud. Vous pouvez également configurer la surveillance d’interface pour les liens reth child de groupe de redondance compatibles LACP pour une protection accrue.
Les interfaces Ethernet agrégées, appelées LAG locaux, sont également prises en charge sur l’un ou l’autre des nœuds d’un cluster de châssis, mais ne peuvent pas être ajoutées aux interfaces reth. Les LAG locaux sont indiqués dans la liste des interfaces système à l’aide d’un préfixe ae-. De même, aucune interface enfant d’un LAG local existant ne peut être ajoutée à une interface reth et vice versa. Notez qu’il est nécessaire que le ou les commutateurs utilisés pour connecter les nœuds du cluster aient une liaison LAG configurée et 802.3ad activée pour chaque LAG sur les deux nœuds afin que les liaisons agrégées soient reconnues comme telles et transmettent correctement le trafic. Le nombre maximal total d’interfaces LAG (ae) et d’interfaces reth à nœud individuel combinées par cluster est de 128.
Les liaisons enfants LAG de l’interface reth de chaque nœud du cluster de châssis doivent être connectées à un LAG différent au niveau des équipements homologues. Si un seul commutateur homologue est utilisé pour arrêter le LAG de l’interface reth, deux LAG distincts doivent être utilisés dans le commutateur.
Il est possible d’ajouter des liaisons provenant de différents PIC ou IOC et utilisant différents types de câbles (par exemple, cuivre et fibre optique) au même LAG d’interface reth, mais la vitesse des interfaces doit être la même et toutes les interfaces doivent être en mode duplex intégral. Nous recommandons toutefois d’utiliser autant que possible des interfaces du même PIC ou IOC pour réduire les coûts de traitement du trafic. Quoi qu’il en soit, toutes les interfaces configurées dans un LAG d’interface reth partagent la même adresse MAC virtuelle.
La fonction de surveillance des interfaces des pare-feu SRX Series permet de surveiller les interfaces Reth/Ethernet agrégées.
La configuration de l’interface Ethernet redondante inclut également un paramètre de liens minimums qui vous permet de définir un nombre minimal de liens enfants physiques sur le nœud principal dans une interface reth donnée qui doit fonctionner pour que l’interface soit active. La valeur par défaut de minimum-links est 1. Notez que le paramètre minimum-links surveille uniquement les liens enfants sur le nœud principal. Les interfaces Ethernet redondantes n’utilisent pas d’interfaces physiques sur le nœud de secours pour le trafic entrant ou sortant.
Voici les détails de l’assistance :
-
La qualité de service (QoS) est prise en charge dans un LAG d’interface reth. Cependant, la bande passante garantie est dupliquée sur toutes les liaisons. Si une liaison est perdue, il y a une perte correspondante de bande passante garantie.
-
Les fonctionnalités de mode transparent de couche 2 et de sécurité de couche 2 sont prises en charge dans les LAG d’interface reth.
-
Le protocole LACP (Link Aggregation Control Protocol) est pris en charge dans les déploiements de clusters en châssis, où les interfaces Ethernet agrégées et les interfaces Reth sont prises en charge simultanément.
-
Les interfaces de gestion, de contrôle et de structure des clusters de châssis ne peuvent pas être configurées en tant que LAG d’interface reth, ni ajoutées à un LAG d’interface reth.
-
Le regroupement de processeurs réseau (NP) peut coexister avec les LAG d’interface Reth sur le même cluster. Toutefois, l’affectation simultanée d’une interface à un LAG d’interface reth et à un bundle de processeurs réseau n’est pas prise en charge.
Les cartes IOC2 n’ont pas de processeur réseau, mais les cartes IOC1 en ont.
-
Le débit à flux unique est limité à la vitesse d’une seule liaison physique, quelle que soit la vitesse de l’interface agrégée.
Pour plus d’informations sur l’agrégation de liens d’interface Ethernet et LACP, reportez-vous aux informations « Ethernet agrégé » du Guide d’utilisation des interfaces pour les équipements de sécurité.
Pour plus d’informations, reportez-vous à la section Comportement des groupes d’agrégation de liens spécifiques à la plate-forme .
Voir aussi
Exemple : Configuration de groupes d’agrégation de liens dans un cluster de châssis
Cet exemple montre comment configurer un groupe d’agrégation de liens d’interface reth pour un cluster de châssis. La configuration du cluster de châssis prend en charge plus d’une interface enfant par nœud dans une interface reth. Lorsqu’au moins deux liens d’interface enfant physiques de chaque nœud sont inclus dans une configuration d’interface reth, les interfaces sont combinées au sein de l’interface reth pour former un groupe d’agrégation de liens d’interface reth.
Exigences
Avant de commencer :
Configurez les interfaces redondantes du cluster de châssis. Reportez-vous à la section Exemple : Configuration des interfaces Ethernet redondantes du cluster de châssis.
Comprendre les groupes d’agrégation de liens d’interface de cluster de châssis. Reportez-vous à la section Présentation des groupes d’agrégation de liens dans un cluster de châssis.
Aperçu
Pour que l’agrégation ait lieu, le commutateur utilisé pour connecter les nœuds du cluster doit activer l’agrégation de liens IEEE 802.3ad pour les liens enfants physiques de l’interface reth sur chaque nœud. Étant donné que la plupart des commutateurs prennent en charge IEEE 802.3ad et sont également compatibles LACP, nous vous recommandons d’activer LACP sur les pare-feu SRX Series. Dans les cas où LACP n’est pas disponible sur le commutateur, vous ne devez pas l’activer sur les pare-feu SRX Series.
Dans cet exemple, vous affectez six interfaces Ethernet à reth1 pour former le groupe d’agrégation de liens d’interface Ethernet :
GE-1/0/1 : RETH1
GE-1/0/2 : RETH1
GE-1/0/3 : RETH1
GE-12/0/1 : Reth1
GE-12/0/2 : Reth1
GE-12/0/3 : RETH1
Un maximum de huit interfaces physiques par nœud dans un cluster, pour un total de 16 interfaces enfants, peut être affecté à une seule interface reth lorsqu’un LAG d’interface reth est en cours de configuration.
Junos OS prend en charge LACP et LAG sur une interface reth, appelée RLAG.
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
{primary:node0}[edit]
set interfaces ge-1/0/1 gigether-options redundant-parent reth1
set interfaces ge-1/0/2 gigether-options redundant-parent reth1
set interfaces ge-1/0/3 gigether-options redundant-parent reth1
set interfaces ge-12/0/1 gigether-options redundant-parent reth1
set interfaces ge-12/0/2 gigether-options redundant-parent reth1
set interfaces ge-12/0/3 gigether-options redundant-parent reth1
Procédure étape par étape
Pour configurer un groupe d’agrégation de liens d’interface reth :
Attribuez des interfaces Ethernet à reth1.
{primary:node0}[edit] user@host# set interfaces ge-1/0/1 gigether-options redundant-parent reth1 user@host# set interfaces ge-1/0/2 gigether-options redundant-parent reth1 user@host# set interfaces ge-1/0/3 gigether-options redundant-parent reth1 user@host# set interfaces ge-12/0/1 gigether-options redundant-parent reth1 user@host# set interfaces ge-12/0/2 gigether-options redundant-parent reth1 user@host# set interfaces ge-12/0/3 gigether-options redundant-parent reth1
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show interfaces reth1 commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
Par souci de concision, la sortie de cette show commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).
user@host# show interfaces reth1
...
ge-1/0/1 {
gigether-options {
redundant-parent reth1;
}
}
ge-1/0/2 {
gigether-options {
redundant-parent reth1;
}
}
ge-1/0/3 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/1 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/2 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/3 {
gigether-options {
redundant-parent reth1;
}
}
...
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérification de la configuration LAG de l’interface Ethernet redondante
But
Vérifiez la configuration LAG de l’interface reth.
Action
À partir du mode opérationnel, entrez la show interfaces terse | match reth commande.
{primary:node0}
user@host> show interfaces terse | match reth
ge-1/0/1.0 up down aenet --> reth1.0
ge-1/0/2.0 up down aenet --> reth1.0
ge-1/0/3.0 up down aenet --> reth1.0
ge-12/0/1.0 up down aenet --> reth1.0
ge-12/0/2.0 up down aenet --> reth1.0
ge-12/0/3.0 up down aenet --> reth1.0
reth0 up down
reth0.0 up down inet 10.10.37.214/24
reth1 up down
reth1.0 up down inet
Comprendre le basculement d’un groupe d’agrégation de liens dans un cluster de châssis
Vous contrôlez le basculement des interfaces reth de deux manières :
- Utilisation du
minimum-linksparamètre de configuration. Ce paramètre détermine le nombre de membres physiques d’un groupe de redondance qui doivent être actifs avant que le groupe ne soit déclaré inactif. Par défaut, ce paramètre est défini sur un, ce qui signifie que le groupe de redondance reste actif si une seule interface physique est active sur le nœud principal.La valeur par défaut pour le nombre minimal de liens est 1.
- Utilisation de l’instruction
interface-monitorde configuration accompagnée d’uneweightvaleur pour chaque membre du LAG. Le mécanisme de pondération des interfaces fonctionne en soustrayant la pondération configurée d'une interface défaillante du groupe de redondance. Le groupe commence avec une pondération de 255, et lorsque le groupe tombe à 0 ou en dessous, le groupe de redondance est déclaré inactif.Note:Il convient de noter que les
minimum-linksinstructions etinterface-monitorconfiguration fonctionnent indépendamment. Le franchissement du seuil de liaisons minimales (sur le nœud principal) ou du seuil de 0 sur le groupe de redondance déclenche un basculement.
Dans la plupart des cas, il est recommandé de configurer les pondérations de la surveillance des interfaces en fonction minimum-links du paramètre. Cette configuration exige que les pondérations soient réparties de manière égale entre les liaisons surveillées, de sorte que lorsque le nombre de liaisons d’interface physique actives tombe en dessous minimum-links du paramètre, la pondération calculée pour ce groupe de redondance tombe également à zéro ou en dessous. Cela déclenche un basculement du groupe d'agrégation de liens (LAG) des interfaces reth, car le nombre de liens physiques tombe en dessous de la minimum-links valeur et la pondération du groupe LAG tombe en dessous de 0.
Pour illustrer cette interaction, considérons un LAG d’interface reth0 avec quatre liaisons physiques sous-jacentes :
- Le LAG est configuré avec un
minimum-linksparamètre de 2. Avec ce paramètre, le basculement est déclenché lorsque le nombre de liaisons physiques actives sur le nœud principal est inférieur à 2.Note:Lorsque la liaison physique est active et que LACP est inactif, un basculement du groupe d’agrégation de liaisons (LAG) des interfaces reth est déclenché.
-
Les
Interface-monitorvaleurs de pondération sont utilisées pour surveiller l’état de la liaison LAG et calculer correctement la pondération du basculement.
Configurez l’interface sous-jacente attachée au LAG reth.
{primary:node0}[edit]
user@host# set interfaces ge-0/0/4 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/5 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/6 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/7 gigether-options redundant-parent reth0
Spécifiez que le nombre minimal de liaisons pour l’interface reth est 2.
{primary:node0}[edit]
user@host# set interfaces reth0 redundant-ether-options minimum-links 2
Configurez la surveillance des interfaces pour surveiller l’intégrité des interfaces et déclencher le basculement du groupe de redondance.
Ces scénarios fournissent des exemples du fonctionnement du basculement reth LAG :
- Scénario 1 : le poids de l’interface surveillée est de 255
- Scénario 2 : le poids de l’interface surveillée est de 75
- Scénario 3 : Le poids de l’interface surveillée est égal à 100
Scénario 1 : le poids de l’interface surveillée est de 255
Spécifiez que le poids de l’interface surveillée est 255 pour chaque interface sous-jacente.
{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight 255
Lorsque 1 des 4 interfaces tombe en panne, il reste 3 liaisons physiques actives dans le RETH LAG. Bien que ce nombre dépasse le paramètre de liaisons minimales configurées, la perte d'une interface d'une pondération de 255 fait tomber la pondération du groupe à 0, ce qui déclenche un basculement.
Scénario 2 : le poids de l’interface surveillée est de 75
Spécifiez que le poids de l’interface surveillée est 75 pour chaque interface sous-jacente.
{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight 75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight 75
Dans ce cas, lorsque trois liens physiques sont en panne, l’interface reth tombe en panne car elle tombe en dessous de la minimum-links valeur configurée. Notez que dans ce scénario, la pondération du groupe LAG reste supérieure à 0.
Scénario 3 : Le poids de l’interface surveillée est égal à 100
Spécifiez que la pondération de l’interface surveillée est 100 pour chaque interface sous-jacente.
{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight 100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight 100
Dans ce cas, lorsque 3 des 4 liaisons physiques sont inactives, l'interface reth est déclarée inactive à la fois parce que la minimum-links valeur n'est pas atteinte et parce que la pondération de surveillance de l'interface fait que la pondération du groupe LAG atteint 0.
Des trois scénarios, le scénario 3 illustre la manière la plus idéale de gérer le basculement reth LAG, avec un minimum de perte de trafic.
Comprendre LACP sur les clusters de châssis
Vous pouvez combiner plusieurs ports Ethernet physiques pour former une liaison point à point logique, appelée groupe d’agrégation de liens (LAG) ou bundle, de sorte qu’un client MAC (Media Access Control) puisse traiter le LAG comme s’il s’agissait d’une liaison unique.
Des LAG peuvent être établis sur les nœuds d’un cluster de châssis pour augmenter la bande passante de l’interface et la disponibilité des liaisons.
Le protocole LACP (Link Aggregation Control Protocol) fournit des fonctionnalités supplémentaires aux LAG. LACP est pris en charge dans les déploiements autonomes, où des interfaces Ethernet agrégées sont prises en charge, et dans les déploiements de clusters de châssis, où les interfaces Ethernet agrégées et les interfaces Ethernet redondantes sont prises en charge simultanément.
Vous configurez LACP sur une interface Ethernet redondante en définissant le mode LACP pour la liaison parent à l’aide de l’instruction lacp . Le mode LACP peut être désactivé (valeur par défaut), actif ou passif.
Cette rubrique contient les sections suivantes :
- Cluster de châssis Groupes d’agrégation de liens d’interface Ethernet redondante
- Sous-LAG
- Prise en charge du basculement sans impact
- Gestion des PDU de contrôle d’agrégation de liens
Cluster de châssis Groupes d’agrégation de liens d’interface Ethernet redondante
Une interface Ethernet redondante comporte des liaisons actives et de secours situées sur deux nœuds d’un cluster de châssis. Tous les liens actifs sont situés sur un nœud et tous les liens de secours sont situés sur l’autre nœud. Vous pouvez configurer jusqu’à huit liens actifs et huit liens de secours par nœud.
Lorsqu’au moins deux liaisons d’interface enfant physiques de chaque nœud sont incluses dans une configuration d’interface Ethernet redondante, les interfaces sont combinées au sein de l’interface Ethernet redondante pour former un LAG d’interface Ethernet redondant.
Le fait de disposer de plusieurs liaisons d’interface Ethernet actives et redondantes réduit les risques de basculement. Par exemple, lorsqu’une liaison active est hors service, tout le trafic sur cette liaison est distribué à d’autres liaisons d’interface Ethernet redondantes actives, au lieu de déclencher un basculement Ethernet actif/veille redondant.
Les interfaces Ethernet agrégées, appelées LAG locaux, sont également prises en charge sur l’un ou l’autre des nœuds d’un cluster de châssis, mais ne peuvent pas être ajoutées aux interfaces Ethernet redondantes. De même, aucune interface enfant d’un LAG local existant ne peut être ajoutée à une interface Ethernet redondante, et vice versa. Au total, le nombre maximal d’interfaces LAG (ae) et d’interfaces Ethernet redondantes (reth) combinées par cluster est de 128.
Toutefois, des interfaces Ethernet agrégées et des interfaces Ethernet redondantes peuvent coexister, car la fonctionnalité d’une interface Ethernet redondante dépend de l’infrastructure Ethernet agrégée de Junos OS.
Pour plus d’informations, reportez-vous à la section Présentation des groupes d’agrégation de liens d’interface Ethernet redondants des clusters de châssis.
Nombre minimum de liens
La configuration de l’interface Ethernet redondante inclut un minimum-links paramètre qui vous permet de définir un nombre minimal de liaisons enfants physiques dans un LAG d’interface Ethernet redondant qui doivent fonctionner sur le nœud principal pour que l’interface soit opérationnelle. La valeur par défaut minimum-links est 1. Lorsque le nombre de liens physiques sur le nœud principal d’une interface Ethernet redondante tombe en dessous de cette minimum-links valeur, l’interface peut être indisponible même si certaines liaisons fonctionnent encore. Pour plus d’informations, reportez-vous à la section Exemple : Configuration du nombre minimal de liaisons du cluster de châssis.
Sous-LAG
LACP maintient un LAG point à point. Tout port connecté au troisième point est refusé. Toutefois, une interface Ethernet redondante se connecte à deux systèmes différents ou à deux interfaces Ethernet agrégées distantes de par sa conception.
Pour prendre en charge LACP sur les liaisons actives et de veille d’interface Ethernet redondantes, une interface Ethernet redondante est créée automatiquement pour se composer de deux sous-LAG distincts, où toutes les liaisons actives forment un sous-LAG actif et toutes les liaisons de secours forment un sous-LAG de secours.
Dans ce modèle, la logique de sélection LACP est appliquée et limitée à un sous-LAG à la fois. De cette façon, deux sous-LAG d’interface Ethernet redondants sont maintenus simultanément tandis que tous les avantages LACP sont préservés pour chaque sous-LAG.
Il est nécessaire qu’une liaison LAG soit configurée et que la norme 802.3ad soit activée pour chaque LAG sur les deux nœuds des commutateurs utilisés pour connecter les nœuds du cluster, afin que les liaisons agrégées soient reconnues comme telles et transmettent correctement le trafic.
Les liaisons enfants LAG de l’interface Ethernet redondante de chaque nœud du cluster de châssis doivent être connectées à un LAG différent au niveau des équipements homologues. Si un seul commutateur homologue est utilisé pour arrêter le LAG redondant de l’interface Ethernet, deux LAG distincts doivent être utilisés dans le commutateur.
Prise en charge du basculement sans impact
Avec LACP, l’interface Ethernet redondante prend en charge le basculement sans impact entre les liaisons active et de secours en fonctionnement normal. Le terme « sans impact » signifie que l’état de l’interface Ethernet redondante reste actif pendant un basculement.
Le processus lacpd gère à la fois les liaisons actives et de veille des interfaces Ethernet redondantes. Un état d’interface Ethernet redondante reste actif lorsque le nombre de liaisons actives est égal ou supérieur au nombre minimal de liaisons configurées. Par conséquent, pour prendre en charge un basculement sans impact, l’état LACP sur les liaisons de secours redondantes de l’interface Ethernet doit être collecté et distribué avant que le basculement ne se produise.
Gestion des PDU de contrôle d’agrégation de liens
Les unités de données de protocole (PDU) contiennent des informations sur l’état de la liaison. Par défaut, les liaisons Ethernet agrégées et redondantes n’échangent pas de PDU de contrôle d’agrégation de liaisons.
Vous pouvez configurer l’échange de PDU de l’une des manières suivantes :
Configurer les liaisons Ethernet pour transmettre activement les PDU de contrôle d’agrégation de liaisons
Configurez les liaisons Ethernet pour transmettre passivement les PDU, en envoyant les PDU de contrôle d’agrégation de liens uniquement lorsqu’elles sont reçues de l’extrémité distante de la même liaison
L’extrémité locale d’une liaison enfant est appelée acteur et l’extrémité distante de la liaison est appelée partenaire. En d’autres termes, l’acteur envoie des PDU de contrôle d’agrégation de liens à son partenaire de protocole qui transmettent ce que l’acteur sait de son propre état et de celui du partenaire.
Vous configurez l’intervalle auquel les interfaces du côté distant de la liaison transmettent les PDU de contrôle d’agrégation de liaison en configurant l’instruction periodic sur les interfaces du côté local. C’est la configuration du côté local qui spécifie le comportement du côté distant. Autrement dit, le côté distant transmet les PDU de contrôle d’agrégation de liaison à l’intervalle spécifié. L’intervalle peut être fast (toutes les secondes) ou slow (toutes les 30 secondes).
Pour plus d’informations, reportez-vous à la section Exemple : configuration de LACP sur des clusters de châssis.
Par défaut, l’acteur et le partenaire transmettent les PDU de contrôle d’agrégation de liens toutes les secondes. Vous pouvez configurer différents taux périodiques sur les interfaces actives et passives. Lorsque vous configurez les interfaces active et passive à des débits différents, l’émetteur respecte le débit du récepteur.
Exemple : configuration de LACP sur des clusters de châssis
Cet exemple montre comment configurer LACP sur des clusters de châssis.
Exigences
Avant de commencer :
Effectuez les tâches telles que l’activation du cluster de châssis, la configuration des interfaces et des groupes de redondance. Pour plus d’informations, reportez-vous aux sections Présentation de la configuration du cluster de châssis SRX Series et Exemple : configuration des interfaces Ethernet redondantes du cluster de châssis .
Aperçu
Vous pouvez combiner plusieurs ports Ethernet physiques pour former une liaison logique point à point, appelée groupe d’agrégation de liens (LAG) ou bundle. Vous configurez LACP sur une interface Ethernet redondante du pare-feu SRX Series dans le cluster du châssis.
Dans cet exemple, vous définissez le mode LACP de l’interface reth1 sur Actif et définissez l’intervalle de transmission de l’unité PDU de contrôle d’agrégation de liaisons sur lent, c’est-à-dire toutes les 30 secondes.
Lorsque vous activez LACP, les côtés local et distant des liaisons Ethernet agrégées échangent des unités de données de protocole (PDU), qui contiennent des informations sur l’état de la liaison. Vous pouvez configurer les liaisons Ethernet pour qu’elles transmettent activement les PDU ou les transmettre passivement (en envoyant les PDU LACP uniquement lorsqu’elles les reçoivent d’une autre liaison). Un côté du lien doit être configuré comme actif pour que le lien soit actif.
La figure 1 illustre la topologie utilisée dans cet exemple.
EX Series
Sur la Figure 1, SRX1500 périphériques sont utilisés pour configurer les interfaces sur les nœuds 0 et 1. Pour plus d’informations sur la configuration des commutateurs EX Series, reportez-vous à la section Configuration d’Ethernet LACP agrégé (procédure CLI).
Configuration
Configuration de LACP sur un cluster de châssis
Procédure étape par étape
Pour configurer LACP sur des clusters de châssis :
-
Spécifiez le nombre d’interfaces Ethernet redondantes.
[edit chassis cluster] user@host# set reth-count 2
-
Spécifiez la priorité de primauté d'un groupe de redondance sur chaque nœud du cluster. Le nombre le plus élevé est prioritaire.
[edit chassis cluster] user@host# set redundancy-group 1 node 0 priority 200 user@host# set redundancy-group 1 node 1 priority 100
-
Créez une zone de sécurité et attribuez des interfaces à la zone.
[edit security zones] user@host# set security-zone trust host-inbound-traffic system-services all user@host# set security-zone trust interfaces reth1.0
-
Liez les interfaces physiques enfants redondantes à reth1.
[edit interfaces] user@host# set ge-0/0/4 gigether-options redundant-parent reth1 user@host# set ge-0/0/5 gigether-options redundant-parent reth1 user@host# set ge-9/0/4 gigether-options redundant-parent reth1 user@host# set ge-9/0/5 gigether-options redundant-parent reth1
-
Ajouter reth1 au groupe de redondance 1.
[edit interfaces] user@host# set reth1 redundant-ether-options redundancy-group 1
-
Réglez le LACP sur reth1.
[edit interfaces] user@host# set reth1 redundant-ether-options lacp active user@host# set reth1 redundant-ether-options lacp periodic slow
-
Attribuez une adresse IP à reth1.
[edit interfaces] user@host# set reth1 unit 0 family inet address 192.168.2.1/24
-
Configurez LACP sur des interfaces Ethernet agrégées (ae1).
-
Configurez LACP sur des interfaces Ethernet agrégées (ae2).
-
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit interfaces] user@host# commit
Résultats
À partir du mode configuration, confirmez votre configuration en saisissant les show chassiscommandes , show security zones, et show interfaces . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]user@host#show chassis cluster { reth-count 2; redundancy-group 1 { node 0 priority 200; node 1 priority 100; } } [edit]user@host#show security zones security-zone trust { host-inbound-traffic { system-services { all; } } interfaces { reth1.0; } } [edit]user@host#show interfaces reth1 { redundant-ether-options { redundancy-group 1; lacp { active; periodic slow; } } unit 0 { family inet { address 192.168.2.1/24; } } }
Configuration de LACP sur un commutateur EX Series
Procédure étape par étape
Configurez LACP sur le commutateur EX Series.
-
Définissez le nombre d’interfaces Ethernet agrégées.
[edit chassis] user@host# set aggregated-devices ethernet device-count 3
-
Associez des interfaces physiques à des interfaces Ethernet agrégées.
[edit interfaces] user@host# set ge-0/0/1 gigether-options 802.3ad ae1 user@host# set ge-0/0/2 gigether-options 802.3ad ae1 user@host# set ge-0/0/3 gigether-options 802.3ad ae2 user@host# set ge-0/0/4 gigether-options 802.3ad ae2
-
Configurez LACP sur des interfaces Ethernet agrégées (ae1).
[edit interfaces] user@host# set interfaces ae1 unit 0 family ethernet-switching interface-mode access user@host# set interfaces ae1 unit 0 family ethernet-switching vlan members RETH0_VLAN
-
Configurez LACP sur des interfaces Ethernet agrégées (ae2).
[edit interfaces] user@host# set interfaces ae2 unit 0 family ethernet-switching interface-mode access user@host# set interfaces ae2 unit 0 family ethernet-switching vlan members RETH0_VLAN
-
Configurez le VLAN.
user@host#set vlans RETH0_VLAN vlan-id 10 user@host# set vlans RETH0_VLAN l3-interface vlan.10 user@host# set interfaces vlan unit 10 family inet address 192.168.2.254/24
Résultats
En mode configuration, confirmez votre configuration en entrant les show chassis commandes and show interfaces . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]user@host#show chassis aggregated-devices { ethernet { device-count 3; } }user@host#show vlans RETH0_VLAN { vlan-id 10; l3-interface vlan.10; }user@host>show vlans RETH0_VLAN Routing instance VLAN name Tag Interfaces default-switch RETH0_VLAN 10 ae1.0* ae2.0*user@host>show ethernet-switching interface ae1 Routing Instance Name : default-switch Logical Interface flags (DL - disable learning, AD - packet action drop, LH - MAC limit hit, DN - interface down, MMAS - Mac-move action shutdown, SCTL - shutdown by Storm-control ) Logical Vlan TAG MAC STP Logical Tagging interface members limit state interface flags ae1.0 131072 untagged RETH0_VLAN 10 131072 Forwarding untaggeduser@host>show ethernet-switching interface ae2 Routing Instance Name : default-switch Logical Interface flags (DL - disable learning, AD - packet action drop, LH - MAC limit hit, DN - interface down, MMAS - Mac-move action shutdown, SCTL - shutdown by Storm-control ) Logical Vlan TAG MAC STP Logical Tagging interface members limit state interface flags ae2.0 131072 untagged RETH0_VLAN 10 131072 Forwarding untaggeduser@host#show interfaces ge-0/0/1 { ether-options { 802.3ad ae1; } } ge-0/0/2 { ether-options { 802.3ad ae1; } } ge-0/0/3 { ether-options { 802.3ad ae2; } } ge-0/0/4 { ether-options { 802.3ad ae2; } } ae1 { aggregated-ether-options { lacp { active; periodic slow; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members RETH0_VLAN; } } } } ae2 { aggregated-ether-options { lacp { active; periodic slow; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members RETH0_VLAN; } } } } vlan { unit 10 { family inet { address 192.168.2.254/24 { } } } }
Vérification
Vérification de LACP sur des interfaces Ethernet redondantes
But
Affichez les informations d’état LACP pour les interfaces Ethernet redondantes.
Action
À partir du mode opérationnel, entrez la show chassis cluster status commande.
{primary:node0}[edit]
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring RE Relinquish monitoring
IS IRQ storm
Cluster ID: 1
Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 1 primary no no None
node1 1 secondary no no None
Redundancy group: 1 , Failover count: 1
node0 200 primary no no None
node1 100 secondary no no None
{primary:node0}[edit]
user@host> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Monitored-Status Internal-SA Security
0 fxp1 Up Disabled Disabled
Fabric link status: Up
Fabric interfaces:
Name Child-interface Status Security
(Physical/Monitored)
fab0 ge-0/0/2 Up / Up Enabled
fab0
fab1 ge-9/0/2 Up / Up Enabled
fab1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Down Not configured
reth1 Up 1
Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0
À partir du mode opérationnel, entrez la show lacp interfaces reth1 commande.
{primary:node0}[edit]
user@host> show lacp interfaces reth1
Aggregated interface: reth1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/4 Actor No No Yes Yes Yes Yes Slow Active
ge-0/0/4 Partner No No Yes Yes Yes Yes Slow Active
ge-0/0/5 Actor No No Yes Yes Yes Yes Slow Active
ge-0/0/5 Partner No No Yes Yes Yes Yes Slow Active
ge-9/0/4 Actor No No Yes Yes Yes Yes Slow Active
ge-9/0/4 Partner No No Yes Yes Yes Yes Slow Active
ge-9/0/5 Actor No No Yes Yes Yes Yes Slow Active
ge-9/0/5 Partner No No Yes Yes Yes Yes Slow Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/4 Current Slow periodic Collecting distributing
ge-0/0/5 Current Slow periodic Collecting distributing
ge-9/0/4 Current Slow periodic Collecting distributing
ge-9/0/5 Current Slow periodic Collecting distributing
La sortie affiche des informations d’interface Ethernet redondantes, telles que les suivantes :
L’état LACP : indique si le lien de l’ensemble est un acteur (local ou proche de l’extrémité de la liaison) ou un partenaire (distant ou distant de la liaison).
Le mode LACP : indique si les deux extrémités de l’interface Ethernet agrégée sont activées (active ou passive) : au moins une extrémité du bundle doit être active.
Le débit de transmission PDU de contrôle d’agrégation de liaisons périodiques.
L’état du protocole LACP : indique que la liaison est active si elle collecte et distribue des paquets.
Exemple : Configuration du nombre minimal de liaisons du cluster de châssis
Cet exemple montre comment spécifier un nombre minimal de liaisons physiques affectées à une interface Ethernet redondante sur le nœud principal qui doit fonctionner pour que l’interface soit opérationnelle.
Exigences
Avant de commencer :
Configurez des interfaces Ethernet redondantes. Reportez-vous à la section Exemple : Configuration des interfaces Ethernet redondantes du cluster de châssis.
Comprendre les groupes d’agrégation de liens d’interface Ethernet redondants. Reportez-vous à la section Exemple : Configuration de groupes d’agrégation de liens dans un cluster de châssis.
Aperçu
Lorsqu’une interface Ethernet redondante comporte plus de deux liaisons enfants, vous pouvez définir un nombre minimal de liaisons physiques affectées à l’interface sur le nœud principal qui doivent fonctionner pour que l’interface soit opérationnelle. Lorsque le nombre de liens physiques sur le nœud principal tombe en dessous de la valeur minimum-links, l’interface est inactive même si certaines liaisons fonctionnent encore.
Dans cet exemple, vous spécifiez que trois liens enfants sur le noeud principal et liés à reth1 (valeur minimum-links) fonctionnent pour empêcher l’interface de tomber en panne. Par exemple, dans une configuration LAG d’interface Ethernet redondante dans laquelle six interfaces sont affectées à reth1, la définition de la valeur minimum-links à 3 signifie que toutes les liaisons enfants reth1 sur le nœud principal doivent fonctionner pour empêcher l’état de l’interface de passer à inactif.
Bien qu’il soit possible de définir une valeur de liens minimum pour une interface Ethernet redondante avec seulement deux interfaces enfants (une sur chaque nœud), nous ne le recommandons pas.
Configuration
Procédure
Procédure étape par étape
Pour spécifier le nombre minimal de liens :
Spécifiez le nombre minimal de liaisons pour l’interface Ethernet redondante.
{primary:node0}[edit] user@host# set interfaces reth1 redundant-ether-options minimum-links 3Si vous avez terminé de configurer l’appareil, validez la configuration.
{primary:node0}[edit] user@host# commit
Vérification
Vérification de la configuration du nombre minimal de liaisons du cluster de châssis
But
Pour vérifier que la configuration fonctionne correctement, entrez la show interface reth1 commande.
Action
À partir du mode opérationnel, entrez la commande show show interfaces reth1 .
{primary:node0}[edit]user@host> show interfaces reth1Physical interface: reth1, Enabled, Physical link is Down Interface index: 129, SNMP ifIndex: 548 Link-level type: Ethernet, MTU: 1514, Speed: Unspecified, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 3, Minimum bandwidth needed: 0 Device flags : Present Running Interface flags: Hardware-Down SNMP-Traps Internal: 0x0 Current address: 00:10:db:ff:10:01, Hardware address: 00:10:db:ff:10:01 Last flapped : 2010-09-15 15:54:53 UTC (1w0d 22:07 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface reth1.0 (Index 68) (SNMP ifIndex 550) Flags: Hardware-Down Device-Down SNMP-Traps 0x0 Encapsulation: ENET2 Statistics Packets pps Bytes bps Bundle: Input : 0 0 0 0 Output: 0 0 0 0 Security: Zone: untrust Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re
Exemple : Configuration de groupes d’agrégation de liaisons d’interface Ethernet redondantes sur un équipement de ligne SRX5000 avec IOC2 ou IOC3
La prise en charge des groupes d’agrégation de liens Ethernet (LAG) basés sur IEEE 802.3ad permet d’agréger les interfaces physiques sur un périphérique autonome. Les LAG sur les appareils autonomes augmentent la bande passante de l’interface et la disponibilité des liaisons. L’agrégation de liens dans un cluster de châssis permet à une interface Ethernet redondante d’ajouter plus de deux interfaces enfants physiques, créant ainsi un LAG d’interface Ethernet redondant.
Exigences
Cet exemple utilise les composants logiciels et matériels suivants :
Junos OS version 15.1X49-D40 ou ultérieure pour les pare-feu SRX Series.
SRX5800 avec IOC2 ou IOC3 avec Express Path activé sur IOC2 et IOC3. Pour plus d’informations, reportez-vous à la section Exemple : Configuration de SRX5K-MPC3-100G10G (IOC3) et SRX5K-MPC3-40G10G (IOC3) sur un périphérique de ligne SRX5000 pour prendre en charge Express Path.
Aperçu
Cet exemple montre comment configurer un groupe d’agrégation de liens d’interface Ethernet redondant et configurer LACP sur des clusters de châssis sur un pare-feu SRX Series à l’aide des ports de IOC2 ou IOC3 en mode Express Path. Notez que la configuration des interfaces enfants en mélangeant des liens d’IOC2 et d’IOC3 n’est pas prise en charge.
Une interface Ethernet redondante ou une interface Ethernet agrégée (aex) doit contenir des interfaces enfants du même type IOC pour IOC2 et IOC3. Par exemple, si une liaison enfant provient de 10 Gigabit Ethernet sur IOC2, la deuxième liaison enfant doit également provenir d’IOC2. Cette limitation ne s’applique pas aux interfaces enfants IOC3 et IOC4 si les interfaces enfants ont la même vitesse.
La combinaison suivante n’est pas prise en charge :
- Nœud 0-100GbE à partir de IOC2 et 10GbE/40GbE/100GbE à partir d’IOC3
- Nœud 1-100GbE de IOC2 et 10GbE/40GbE/100GbE de IOC3
La combinaison suivante est prise en charge (avec la même vitesse d’interface) :
- Nœud 0-100GbE à partir de IOC3 et 100GbE à partir d’IOC4
- Nœud 1-100GbE à partir de IOC3 et 100GbE à partir d’IOC4
Les liens de membre suivants sont utilisés dans cet exemple :
-
xe-1/0/0
-
xe-3/0/0
-
XE-14/0/0
-
XE-16/0/0
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, supprimez, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set chassis cluster reth-count 5 set interfaces reth0 redundant-ether-options redundancy-group 1 set interfaces reth0 redundant-ether-options lacp active set interfaces reth0 redundant-ether-options lacp periodic fast set interfaces reth0 redundant-ether-options minimum-links 1 set interfaces reth0 unit 0 family inet address 192.0.2.1/24 set interfaces xe-1/0/0 gigether-options redundant-parent reth0 set interfaces xe-3/0/0 gigether-options redundant-parent reth0 set interfaces xe-14/0/0 gigether-options redundant-parent reth0 set interfaces xe-16/0/0 gigether-options redundant-parent reth0
Procédure
Procédure étape par étape
Pour configurer les interfaces LAG :
Spécifiez le nombre d’interfaces Ethernet agrégées à créer.
[edit chassis] user@host# set chassis cluster reth-count 5
Liez les interfaces physiques enfants redondantes à reth0.
[edit interfaces] user@host# set xe-1/0/0 gigether-options redundant-parent reth0 user@host# set xe-3/0/0 gigether-options redundant-parent reth0 user@host# set xe-14/0/0 gigether-options redundant-parent reth0 user@host# set xe-16/0/0 gigether-options redundant-parent reth0
Ajouter reth0 au groupe de redondance 1.
user@host#set reth0 redundant-ether-options redundancy-group 1
Attribuez une adresse IP à reth0.
[edit interfaces] user@host# set reth0 unit 0 family inet address 192.0.2.1/24
Réglez le LACP sur reth0.
[edit interfaces] user@host# set reth0 redundant-ether-options lacp active user@host# set reth0 redundant-ether-options lacp periodic fast user@host# set reth0 redundant-ether-options minimum-links 1
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show interfaces commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show interfaces
xe-1/0/0 {
gigether-options {
redundant-parent reth0;
}
}
xe-3/0/0 {
gigether-options {
redundant-parent reth0;
}
}
xe-14/0/0 {
gigether-options {
redundant-parent reth0;
}
}
xe-16/0/0 {
gigether-options {
redundant-parent reth0;
}
}
reth0 {
redundant-ether-options {
lacp {
active;
periodic fast;
}
minimum-links 1;
}
unit 0 {
family inet {
address 192.0.2.1/24;
}
}
}
ae1 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
}
[edit]
user@host# show chassis
chassis cluster {
reth-count 5;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérification de LACP sur des interfaces Ethernet redondantes
But
Affichez les informations d’état LACP pour les interfaces Ethernet redondantes.
Action
À partir du mode opérationnel, entrez la show lacp interfaces commande pour vérifier que LACP a été activé comme actif à une extrémité.
user@host> show lacp interfaces
Aggregated interface: reth0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
xe-16/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-16/0/0 Partner No No Yes Yes Yes Yes Fast Active
xe-14/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-14/0/0 Partner No No Yes Yes Yes Yes Fast Active
xe-1/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-1/0/0 Partner No No Yes Yes Yes Yes Fast Active
xe-3/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-3/0/0 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
xe-16/0/0 Current Fast periodic Collecting distributing
xe-14/0/0 Current Fast periodic Collecting distributing
xe-1/0/0 Current Slow periodic Collecting distributing
xe-3/0/0 Current Slow periodic Collecting distributing
La sortie indique que LACP a été correctement configuré et qu’il est actif à une extrémité.
Comprendre le VRRP sur les pare-feu SRX Series
Les pare-feu SRX Series prennent en charge le protocole VRRP (Virtual Router Redundancy Protocol) et le VRRP pour IPv6. Cette rubrique aborde les sujets suivants :
- Présentation du VRRP sur les pare-feu SRX Series
- Avantages du VRRP
- Exemple de topologie VRRP
- Pare-feu SRX Series Prise en charge de VRRPv3
- Limites des fonctionnalités VRRPv3
Présentation du VRRP sur les pare-feu SRX Series
La configuration des hôtes finaux sur votre réseau avec des routes statiques par défaut minimise les efforts et la complexité de la configuration, et réduit les frais de traitement sur les hôtes finaux. Lorsque les hôtes sont configurés avec des routes statiques, la défaillance de la passerelle par défaut entraîne normalement un événement catastrophique, isolant tous les hôtes qui ne sont pas en mesure de détecter d’autres chemins disponibles vers leur passerelle. L’utilisation du protocole VRRP (Virtual Router Redundancy Protocol) vous permet de fournir dynamiquement d’autres passerelles aux hôtes finaux en cas de défaillance de la passerelle principale.
Vous pouvez configurer le protocole VRRP (Virtual Router Redundancy Protocol) ou VRRP pour IPv6 sur les interfaces Gigabit Ethernet, les interfaces 10 Gigabit Ethernet et les interfaces logiques sur les pare-feu SRX Series. VRRP permet aux hôtes d’un LAN d’utiliser des périphériques redondants sur ce LAN sans nécessiter plus que la configuration statique d’une seule route par défaut sur les hôtes. Les équipements configurés avec VRRP partagent l’adresse IP correspondant à la route par défaut configurée sur les hôtes. À tout moment, l’un des périphériques configurés VRRP est le principal (actif) et les autres sont des sauvegardes. En cas de défaillance de l’équipement principal, l’un des équipements de sauvegarde devient le nouveau périphérique principal, fournissant un équipement virtuel par défaut et permettant d’acheminer le trafic sur le LAN sans dépendre d’un seul équipement. Grâce au VRRP, un pare-feu SRX Series de secours peut prendre en charge un équipement par défaut défaillant en quelques secondes. Cela se fait avec une perte minimale de trafic VRRP et sans aucune interaction avec les hôtes. Le protocole de redondance de routeur virtuel n’est pas pris en charge sur les interfaces de gestion.
Le VRRP pour IPv6 permet de basculer beaucoup plus rapidement vers un autre périphérique par défaut que les procédures de découverte de voisinage (ND) IPv6. VRRP pour IPv6 ne prend pas en charge les authentication-type instructions or authentication-key .
Les périphériques exécutant VRRP choisissent dynamiquement les périphériques principaux et de secours. Vous pouvez également forcer l’affectation des périphériques principaux et de secours à l’aide de priorités comprises entre 1 et 255, 255 étant la priorité la plus élevée. En VRRP, l’équipement principal par défaut envoie des annonces à l’unité de sauvegarde à intervalles réguliers. L’intervalle par défaut est de 1 seconde. Si l’unité de sauvegarde ne reçoit pas d’annonce pendant une période définie, l’unité de sauvegarde ayant la priorité la plus élevée prend le relais en tant que périphérique principal et commence à transférer des paquets.
Les unités de sauvegarde ne tentent pas de préempter l’unité principale à moins qu’elle n’ait une priorité supérieure. Cela élimine les interruptions de service, à moins qu’un chemin plus privilégié ne devienne disponible. Il est possible d’interdire administrativement toutes les tentatives de préemption, à l’exception d’un appareil VRRP qui devient l’appareil principal de tout appareil associé à des adresses qu’il possède.
VRRP ne prend pas en charge la synchronisation de sessions entre les membres. En cas de défaillance de l’équipement principal, l’équipement de sauvegarde ayant la priorité la plus élevée prend le relais en tant que périphérique principal et commence à transférer les paquets. Toutes les sessions existantes seront supprimées sur le périphérique de sauvegarde en tant qu’hors état.
Il n’est pas possible de définir la priorité 255 pour les interfaces VLAN routées (RVI).
VRRP est défini dans la RFC 3768, Virtual Router Redundancy Protocol.
Avantages du VRRP
Le VRRP assure le basculement dynamique des adresses IP d’un appareil à un autre en cas de panne.
Vous pouvez implémenter VRRP pour fournir un chemin par défaut hautement disponible vers une passerelle sans avoir à configurer de protocoles de routage dynamique ou de découverte de routeur sur les hôtes finaux.
Exemple de topologie VRRP
La figure 2 illustre une topologie VRRP de base avec des pare-feu SRX Series. Dans cet exemple, les périphériques A et B exécutent VRRP et partagent l’adresse IP virtuelle 192.0.2.1. La passerelle par défaut pour chacun des clients est 192.0.2.1.
commutateurs SRX Series
La figure suivante illustre le comportement de base du VRRP à l’aide de la Figure 2 à titre de référence :
Lorsque l’un des serveurs souhaite envoyer du trafic hors du réseau local, il l’envoie à l’adresse de passerelle par défaut 192.0.2.1. Il s’agit d’une adresse IP virtuelle (VIP) appartenant au groupe VRRP 100. Étant donné que l’appareil A est le principal du groupe, l’adresse IP virtuelle est associée à l’adresse « réelle » 192.0.2.251 sur l’appareil A, et le trafic des serveurs est en fait envoyé à cette adresse. (L’appareil A est le principal, car il a été configuré avec une valeur de priorité plus élevée.)
Si une défaillance sur l’équipement A l’empêche de transférer le trafic vers ou depuis les serveurs (par exemple, si l’interface connectée au réseau local tombe en panne), l’équipement B devient le périphérique principal et devient propriétaire de l’adresse virtuelle. Les serveurs continuent d’envoyer du trafic à l’adresse VIP, mais comme l’adresse IP virtuelle est maintenant associée à l’adresse « réelle » 192.0.2.252 sur l’équipement B (en raison d’un changement de l’adresse principale), le trafic est envoyé à l’équipement B au lieu de l’équipement A.
Si le problème à l’origine de la défaillance sur l’appareil A est corrigé, l’appareil A redevient le principal appareil et réaffirme la propriété de l’adresse virtuelle. Dans ce cas, les serveurs reprennent l’envoi de trafic vers l’équipement A.
Notez qu’aucune modification de configuration n’est requise sur les serveurs pour qu’ils basculent entre l’envoi de trafic vers l’équipement A et l’équipement B. Lorsque l’adresse IP virtuelle se déplace entre 192.0.2.251 et 192.0.2.252, le changement est détecté par le comportement TCP-IP normal et aucune configuration ou intervention n’est requise sur les serveurs.
Pare-feu SRX Series Prise en charge de VRRPv3
L’avantage de VRRPv3 est que VRRPv3 prend en charge les familles d’adresses IPv4 et IPv6, alors que VRRP ne prend en charge que les adresses IPv4.
Activez VRRPv3 dans votre réseau uniquement si VRRPv3 peut être activé sur tous les équipements configurés avec VRRP dans votre réseau, car VRRPv3 (IPv4) n’interagit pas avec les versions précédentes de VRRP. Par exemple, si des paquets d’annonces IPv4 VRRP sont reçus par un équipement sur lequel VRRPv3 est activé, l’équipement passe lui-même à l’état de sauvegarde pour éviter de créer plusieurs serveurs principaux dans le réseau.
Vous pouvez activer VRRPv3 en configurant l’instruction version-3 au niveau de la hiérarchie (pour les [edit protocols vrrp] réseaux IPv4 ou IPv6). Configurez la même version de protocole sur tous les équipements VRRP du réseau local.
Limites des fonctionnalités VRRPv3
Vous trouverez ci-dessous quelques limitations des fonctionnalités de VRRPv3.
Authentification VRRPv3
Lorsque VRRPv3 (pour IPv4) est activé, il n’autorise pas l’authentification.
Les
authentication-typeinstructions etauthentication-keyne peuvent pas être configurées pour les groupes VRRP.Vous devez utiliser une authentification autre que VRRP.
Intervalles d’annonce VRRPv3
Les intervalles d’annonce VRRPv3 (pour IPv4 et IPv6) doivent être définis à l’aide de l’instruction fast-interval au niveau hiérarchique [modifier les interfaces, nom de l’interface, unité 0, famille, adresse inet, adresse ip, vrrp-group-name].
N’utilisez pas l’instruction
advertise-interval(pour IPv4).N’utilisez pas l’instruction
inet6-advertise-interval(pour IPv6).
Voir aussi
Présentation du délai de basculement VRRP
Le basculement est un mode opérationnel de secours dans lequel les fonctions d’un équipement réseau sont assumées par un équipement secondaire lorsque celui-ci devient indisponible en raison d’une panne ou d’un temps d’arrêt planifié. Le basculement fait généralement partie intégrante des systèmes critiques qui doivent être constamment disponibles sur le réseau.
VRRP ne prend pas en charge la synchronisation de sessions entre les membres. En cas de défaillance de l’équipement principal, l’équipement de sauvegarde ayant la priorité la plus élevée prend le relais en tant que périphérique principal et commence à transférer les paquets. Toutes les sessions existantes seront supprimées sur le périphérique de sauvegarde en tant qu’hors état.
Un basculement rapide nécessite un délai court. Ainsi, le délai de basculement configure le délai de basculement, en millisecondes, pour VRRP et VRRP pour les opérations IPv6. Junos OS prend en charge une plage de 50 à 100000 millisecondes pour un délai de temps de basculement.
Le processus VRRP (vrrpd) exécuté sur le moteur de routage communique une modification du rôle principal VRRP au moteur de transfert de paquets pour chaque session VRRP. Chaque groupe VRRP peut déclencher une telle communication pour mettre à jour le moteur de transfert de paquets avec son propre état ou l’état hérité d’un groupe VRRP actif. Pour éviter de surcharger le moteur de transfert de paquets avec de tels messages, vous pouvez configurer un délai de basculement pour spécifier le délai entre les communications suivantes entre le moteur de routage et le moteur de transfert de paquets.
Le moteur de routage informe le moteur de transfert de paquets d’une modification du rôle principal VRRP afin de faciliter les changements d’état nécessaires sur le moteur de transfert de paquets, par exemple la reprogrammation des filtres matériels du moteur de transfert de paquets, des sessions VRRP, etc. Les sections suivantes détaillent la communication entre le moteur de routage et le moteur de transfert de paquets dans deux scénarios :
Lorsque le délai de basculement n’est pas configuré
Sans délai de basculement configuré, la séquence d’événements pour les sessions VRRP gérées à partir du moteur de routage est la suivante :
Lorsque le premier groupe VRRP détecté par le moteur de routage change d’état et que le nouvel état est principal, le moteur de routage génère les messages d’annonce VRRP appropriés. Le moteur de transfert de paquets est informé du changement d’état, de sorte que les filtres matériels de ce groupe sont reprogrammés sans délai. Le nouveau serveur principal envoie ensuite un message ARP gratuit aux groupes VRRP.
Le délai du minuteur de basculement commence. Par défaut, le temporisateur de délai de basculement est :
500 millisecondes : lorsque l’intervalle d’annonce VRRP configuré est inférieur à 1 seconde.
2 secondes : lorsque l’intervalle d’annonce VRRP configuré est de 1 seconde ou plus et que le nombre total de groupes VRRP sur le routeur est de 255.
10 secondes : lorsque l’intervalle d’annonce VRRP configuré est de 1 seconde ou plus et que le nombre de groupes VRRP sur le routeur est supérieur à 255.
Le moteur de routage modifie l’état un par un pour les groupes VRRP suivants. Chaque fois qu’il y a un changement d’état et que le nouvel état d’un groupe VRRP particulier est principal, le moteur de routage génère des messages d’annonce VRRP appropriés. Toutefois, la communication avec le moteur de transfert de paquets est interrompue jusqu’à l’expiration du délai de basculement.
Après l’expiration du délai de basculement, le moteur de routage envoie un message au moteur de transfert de paquets concernant tous les groupes VRRP qui ont réussi à modifier l’état. En conséquence, les filtres matériels de ces groupes sont reprogrammés, et pour les groupes dont le nouvel état est primaire, des messages ARP gratuits sont envoyés.
Ce processus se répète jusqu’à ce que la transition d’état de tous les groupes VRRP soit terminée.
Ainsi, sans configurer de délai de basculement, la transition d’état complète (y compris les états du moteur de routage et du moteur de transfert de paquets) pour le premier groupe VRRP est effectuée immédiatement, tandis que la transition d’état sur le moteur de transfert de paquets pour les groupes VRRP restants est retardée d’au moins 0,5 à 10 secondes, en fonction des temporisateurs d’annonce VRRP configurés et du nombre de groupes VRRP. Au cours de cet état intermédiaire, le trafic de réception pour les groupes VRRP pour les modifications d’état qui n’ont pas encore été effectuées sur le moteur de transfert de paquets peut être abandonné au niveau du moteur de transfert de paquets en raison d’une reconfiguration différée des filtres matériels.
Lorsque le délai de basculement est configuré
Lorsque le délai de basculement est configuré, la séquence d’événements pour les sessions VRRP gérées à partir du moteur de routage est modifiée comme suit :
Le moteur de routage détecte que certains groupes VRRP nécessitent un changement d’état.
Le délai de basculement commence pour la période configurée. La plage de temporisation de basculement autorisée est comprise entre 50 et 100000 millisecondes.
Le moteur de routage effectue un par un les changements d’état pour les groupes VRRP. Chaque fois qu’il y a un changement d’état et que le nouvel état d’un groupe VRRP particulier est principal, le moteur de routage génère des messages d’annonce VRRP appropriés. Toutefois, la communication avec le moteur de transfert de paquets est interrompue jusqu’à l’expiration du délai de basculement.
Après l’expiration du délai de basculement, le moteur de routage envoie un message au moteur de transfert de paquets concernant tous les groupes VRRP qui ont réussi à modifier l’état. En conséquence, les filtres matériels de ces groupes sont reprogrammés, et pour les groupes dont le nouvel état est primaire, des messages ARP gratuits sont envoyés.
Ce processus se répète jusqu’à ce que la transition d’état de tous les groupes VRRP soit terminée.
Ainsi, lorsque le délai de basculement est configuré, même l’état du moteur de transfert de paquets pour le premier groupe VRRP est différé. Toutefois, l’opérateur réseau a l’avantage de configurer une valeur de délai de basculement qui correspond le mieux aux besoins du déploiement du réseau afin de minimiser les pannes lors du changement d’état VRRP.
Le délai de basculement n’influence que les sessions VRRP gérées par le processus VRRP (vrrpd) exécuté sur le moteur de routage. Pour les sessions VRRP distribuées au moteur de transfert de paquets, la configuration du délai de basculement n’a aucun effet.
Voir aussi
Exemple : configuration de VRRP/VRRPv3 sur des interfaces Ethernet redondantes en cluster de châssis
Lorsque le protocole VRRP (Virtual Router Redundancy Protocol) est configuré, il regroupe plusieurs périphériques dans un périphérique virtuel. À tout moment, l’un des périphériques configurés avec VRRP est le principal (actif) et les autres périphériques sont des sauvegardes. En cas de défaillance du serveur principal, l’un des périphériques de sauvegarde devient le nouveau périphérique principal.
Cet exemple décrit comment configurer VRRP sur une interface redondante :
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Junos OS version 18.1 R1 ou ultérieure pour les pare-feu SRX Series.
Deux pare-feu SRX Series connectés dans un cluster de châssis.
Un pare-feu SRX Series connecté en tant qu’appareil autonome.
Aperçu
Vous pouvez configurer VRRP en configurant des groupes VRRP sur des interfaces redondantes sur un équipement de cluster de châssis et sur une interface Gigabit Ethernet sur un équipement autonome. Une interface redondante de périphériques de cluster de châssis et l’interface Gigabit Ethernet d’un équipement autonome peuvent être membres d’un ou plusieurs groupes VRRP. Au sein d’un groupe VRRP, l’interface principale redondante des équipements de cluster du châssis et l’interface Gigabit Ethernet de secours de l’équipement autonome doivent être configurées.
Pour configurer le groupe VRRP, vous devez configurer l’identificateur de groupe et l’adresse IP virtuelle pour les interfaces redondantes et les interfaces Gigabit Ethernet membres du groupe VRRP. L’adresse IP virtuelle doit être la même pour toutes les interfaces du groupe VRRP. Vous configurez ensuite la priorité des interfaces redondantes et des interfaces Gigabit Ethernet pour qu’elles deviennent l’interface principale.
Vous pouvez forcer l’attribution des interfaces redondantes principale et de secours ainsi que des interfaces Gigabit Ethernet à l’aide d’une priorité comprise entre 1 et 255, la priorité la plus élevée étant 255.
Topologie
La figure 3 illustre la topologie utilisée dans cet exemple.
redondante
Configuration VRRP
- Configuration de VRRPv3, des groupes VRRP et de la priorité sur les interfaces Ethernet redondantes du cluster de châssis
- Configuration de groupes VRRP sur un équipement autonome
Configuration de VRRPv3, des groupes VRRP et de la priorité sur les interfaces Ethernet redondantes du cluster de châssis
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set protocols vrrp traceoptions file vrrp.logset protocols vrrp traceoptions file size 10000000set protocols vrrp traceoptions flag allset protocols vrrp version-3set protocols vrrp ignore-nonstop-routingset interfaces ge-0/0/0 gigether-options redundant-parent reth0set interfaces ge-0/0/3 gigether-options redundant-parent reth1set interfaces ge-5/0/0 gigether-options redundant-parent reth0set interfaces ge-5/0/3 gigether-options redundant-parent reth1set interfaces reth0 redundant-ether-options redundancy-group 1set interfaces reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 virtual-address 192.0.2.3set interfaces reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 priority 255set interfaces reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 accept-dataset interfaces reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3set interfaces reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 priority 255set interfaces reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 accept-dataset interfaces reth1 redundant-ether-options redundancy-group 2set interfaces reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 virtual-address 192.168.120.3set interfaces reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 priority 150set interfaces reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 accept-dataset interfaces reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4set interfaces reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 priority 150set interfaces reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 accept-data
Procédure étape par étape
Pour configurer VRRPv3, les groupes VRRP et la priorité sur les équipements de cluster du châssis :
Configurez un nom de fichier pour les traceoptions afin de tracer le trafic du protocole VRRP.
[edit protocols vrrp] user@host#
set traceoptions file vrrp.logSpécifiez la taille maximale du fichier de trace.
[edit protocols vrrp] user@host#
set traceoptions file size 10000000Activez les options de traçage vrrp.
[edit protocols vrrp] user@host#
set traceoptions flag allDéfinissez la version vrrp sur 3.
[edit protocols vrrp] user@host#
set version-3Configurez cette commande pour prendre en charge le basculement GRES (Graceful Moteur de routage Switchover) pour VRRP et pour le routage actif ininterrompu en cas de basculement VRRP reth. À l’aide de vrrp, un nœud secondaire peut prendre en charge un nœud principal défaillant en quelques secondes, et ce, avec un minimum de trafic VRRP et sans aucune interaction avec les hôtes
[edit protocols vrrp] user@host#
set ignore-nonstop-routingConfigurez les interfaces Ethernet redondantes (reth) et affectez-les à une zone.
[edit interfaces] user@host#
set ge-0/0/0 gigether-options redundant-parent reth0user@host#set ge-0/0/3 gigether-options redundant-parent reth1user@host#set ge-5/0/0 gigether-options redundant-parent reth0user@host#set ge-5/0/3 gigether-options redundant-parent reth1user@host#set reth0 redundant-ether-options redundancy-group 1user@host#set reth1 redundant-ether-options redundancy-group 2Configurez l’adresse d’inet de famille et l’adresse virtuelle pour l’unité 0 de l’interface redondante 0.
[edit interfaces] user@host#
set reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 virtual-address 192.168.110.3user@host#set reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3Configurez l’adresse d’inet familiale et l’adresse virtuelle pour l’unité 0 de l’interface redondante 1.
[edit interfaces] user@host#
set reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 virtual-address 192.168.120.3user@host#set reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4Définissez la priorité de l’unité 0 de l’interface redondante 0 sur 255.
[edit interfaces] user@host#
set reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 priority 255user@host#set reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 priority 255Définissez la priorité de l’unité 1 de l’interface redondante de 0 à 150.
[edit interfaces] user@host#
set reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 priority 150user@host#set reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 priority 150Configurez l’interface redondante 0 unité 0 pour accepter tous les paquets envoyés à l’adresse IP virtuelle.
[edit interfaces] user@host#
set reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 accept-datauser@host#set reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 accept-dataConfigurez l’unité 0 de l’interface redondante 1 pour qu’elle accepte tous les paquets envoyés à l’adresse IP virtuelle.
[edit interfaces] user@host#
set reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 accept-datauser@host#set reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 accept-data
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfaces reth0 commandes and show interfaces reth1 . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show interfaces reth0
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
address 192.0.2.2/24 {
vrrp-group 0 {
virtual-address 192.0.2.3;
priority 255;
accept-data;
}
}
}
family inet6 {
address 2001:db8::2/32 {
vrrp-inet6-group 2 {
virtual-inet6-address 2001:db8::3;
priority 255;
accept-data;
}
}
}
}
[edit]
user@host# show interfaces reth1
redundant-ether-options {
redundancy-group 2;
}
unit 0 {
family inet {
address 192.0.2.4/24 {
vrrp-group 1 {
virtual-address 192.0.2.5;
priority 150;
accept-data;
}
}
}
family inet6 {
address 2001:db8::3/32 {
vrrp-inet6-group 3 {
virtual-inet6-address 2001:db8::4;
priority 150;
accept-data;
}
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration de groupes VRRP sur un équipement autonome
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set protocols vrrp version-3set interfaces xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 virtual-address 192.0.2.3set interfaces xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 priority 50set interfaces xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 accept-dataset interfaces xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3set interfaces xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 priority 50set interfaces xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 accept-dataset interfaces xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 virtual-address 192.0.2.5set interfaces xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 priority 50set interfaces xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 accept-dataset interfaces xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4set interfaces xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 priority 50set interfaces xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 accept-data
Procédure étape par étape
Pour configurer des groupes VRRP sur un équipement autonome :
Définissez la version vrrp sur 3.
[edit protocols vrrp] user@host#
set version-3Configurez l’adresse inet famille et l’adresse virtuelle pour l’unité d’interface Gigabit Ethernet 0.
[edit interfaces] user@host#
set xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 virtual-address 192.0.2.3user@host#set xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3user@host#set xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 virtual-address 192.0.2.5user@host#set xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4Définissez la priorité de l’unité d’interface Gigabit Ethernet de 0 à 50.
[edit interfaces] user@host#
set xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 priority 50user@host#set xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 priority 50user@host#set xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 priority 50user@host#set xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 priority 50Configurez l’unité d’interface Ethernet Gigabit 0 pour qu’elle accepte tous les paquets envoyés à l’adresse IP virtuelle.
[edit interfaces] user@host#
set xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 accept-datauser@host#set xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 accept-datauser@host#set xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 accept-datauser@host#set xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 accept-data
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfaces xe-5/0/5 commandes and show interfaces xe-5/0/6 . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show interfaces xe-5/0/5
unit 0 {
family inet {
address 192.0.2.1/24 {
vrrp-group 0 {
virtual-address 192.0.2.3;
priority 50;
accept-data;
}
}
}
family inet6 {
address 2001:db8::1/32 {
vrrp-inet6-group 2 {
virtual-inet6-address 2001:db8::3;
priority 50;
accept-data;
}
}
}
}
[edit]
user@host# show interfaces xe-5/0/6
unit 0 {
family inet {
address 192.0.2.1/24 {
vrrp-group 1 {
virtual-address 192.0.2.5;
priority 50;
accept-data;
}
}
}
family inet6 {
address 2001:db8::5/32 {
vrrp-inet6-group 3 {
virtual-inet6-address 2001:db8::4;
priority 50;
accept-data;
}
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification du VRRP sur les équipements de cluster du châssis
- Vérification du VRRP sur un appareil autonome
Vérification du VRRP sur les équipements de cluster du châssis
But
Vérifiez que VRRP sur les équipements de cluster du châssis a été correctement configuré.
Action
À partir du mode opérationnel, entrez la show vrrp brief commande pour afficher l’état de VRRP sur les équipements de cluster du châssis.
user@host> show vrrp brief
Interface State Group VR state VR Mode Timer Type Address
reth0.0 up 0 master Active A 0.149 lcl 192.0.2.3
vip 192.0.2.3
reth0.0 up 2 master Active A 0.155 lcl 2001:db8::2
vip 2001:db8:5eff:fe00:202
vip 2001:db8::2
reth1.0 up 1 master Active A 0.445 lcl 192.0.2.4
vip 192.0.2.4
reth1.0 up 3 master Active A 0.414 lcl 2001:db8::4
vip 2001:db8:5eff:fe00:203
vip 2001:db8::4
Signification
L’exemple de sortie montre que les quatre groupes VRRP sont actifs et que les interfaces redondantes ont assumé les rôles principaux corrects. L’adresse lcl est l’adresse physique de l’interface et l’adresse vip est l’adresse virtuelle partagée par les interfaces redondantes. La valeur du minuteur (A 0,149, A 0,155, A 0,445 et A 0,414) indique le temps restant (en secondes) pendant lequel les interfaces redondantes s’attendent à recevoir une annonce VRRP des interfaces Ethernet Gigabit. Si une annonce pour les groupes 0, 1, 2 et 3 n’arrive pas avant l’expiration du minuteur, les périphériques du cluster Chassis s’affirment comme le principal.
Vérification du VRRP sur un appareil autonome
But
Vérifiez que VRRP a été correctement configuré sur un équipement autonome.
Action
À partir du mode opérationnel, entrez la show vrrp brief commande pour afficher l’état du VRRP sur un périphérique autonome.
user@host> show vrrp brief
Interface State Group VR state VR Mode Timer Type Address
xe-5/0/5.0 up 0 backup Active D 3.093 lcl 192.0.2.2.1
vip 192.0.2.2
mas 192.0.2.2.2
xe-5/0/5.0 up 2 backup Active D 3.502 lcl 2001:db8::2:1
vip 2001:db8:200:5eff:fe00:202
vip 2001:db8::2
mas 2001:db8:210:dbff:feff:1000
xe-5/0/6.0 up 1 backup Active D 3.499 lcl 192.0.2.5.1
vip 192.0.2.5
mas 192.0.2.5.2
xe-5/0/6.0 up 3 backup Active D 3.282 lcl 2001:db8::5
vip 2001:db8:200:5eff:fe00:203
vip 2001:db8::4
mas 2001:db8:210:dbff:feff:1001
Signification
L’exemple de sortie montre que les quatre groupes VRRP sont actifs et que les interfaces Gigabit Ethernet ont assumé les rôles de secours appropriés. L’adresse lcl est l’adresse physique de l’interface et l’adresse vip est l’adresse virtuelle partagée par les interfaces Gigabit Ethernet. La valeur du minuteur (D 3.093, D 3.502, D 3.499 et D 3.282) indique le temps restant (en secondes) pendant lequel les interfaces Gigabit Ethernet s’attendent à recevoir une annonce VRRP des interfaces redondantes. Si une annonce pour les groupes 0, 1, 2 et 3 n’arrive pas avant l’expiration du minuteur, l’appareil autonome continue d’être un périphérique de secours.
Exemple : configuration de VRRP pour IPv6
Cet exemple montre comment configurer les propriétés VRRP pour IPv6.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Trois routeurs
-
Junos OS version 11.3 ou ultérieure
- Cet exemple a été récemment mis à jour et revalidé sur Junos OS version 21.1R1.
- Pour plus d’informations sur la prise en charge de VRRP pour des combinaisons spécifiques de plates-formes et de versions de Junos OS, reportez-vous à l’Explorateur de fonctionnalités.
Aperçu
Cet exemple utilise un groupe VRRP, qui a une adresse virtuelle pour IPv6. Les équipements sur le LAN utilisent cette adresse virtuelle comme passerelle par défaut. Si le routeur principal tombe en panne, le routeur de secours prend le relais.
Configuration de VRRP
Configuration du routeur A
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 [edit] hiérarchie.
set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 priority 110 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 accept-data set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 track interface ge-0/0/2 priority-cost 20 set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:1:3::1/64 set protocols router-advertisement interface ge-0/0/1.0 virtual-router-only set protocols router-advertisement interface ge-0/0/1.0 prefix 2001:db8:1:1::/64 set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:3::2
Procédure étape par étape
Pour configurer cet exemple :
-
Configurez les interfaces.
[edit] user@routerA# set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 user@routerA# set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:1:3::1/64
-
Configurez l’identificateur de groupe VRRP IPv6 et l’adresse IP virtuelle.
[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254
-
Configurez la priorité pour que le routeurA soit supérieure au routeurB pour qu’il devienne le routeur virtuel principal. Le routeurB utilise la priorité par défaut de 100.
[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 priority 110
-
Configurez
track interfacepour savoir si l’interface connectée à Internet est active, inactive ou absente afin de modifier la priorité du groupe VRRP.[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 track interface ge-0/0/2 priority-cost 20
-
Configurez
accept-datapour permettre au routeur principal d’accepter tous les paquets destinés à l’adresse IP virtuelle.[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 accept-data
-
Configurez un itinéraire statique pour le trafic vers Internet.
[edit] user@routerA# set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:3::2
-
Pour VRRP pour iPv6, vous devez configurer l’interface sur laquelle VRRP est configuré pour envoyer des annonces de routeur IPv6 pour le groupe VRRP. Lorsqu’une interface reçoit un message de sollicitation de routeur IPv6, elle envoie une annonce de routeur IPv6 à tous les groupes VRRP configurés sur celle-ci.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerA# set prefix 2001:db8:1:1::/64
-
Configurez l’envoi d’annonces de routeur uniquement pour les groupes IPv6 VRRP configurés sur l’interface si les groupes sont à l’état principal.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerA# set virtual-router-only
Résultats
À partir du mode configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols router-advertisement et show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@routerA# show interfaces
ge-0/0/1 {
unit 0 {
family inet6 {
address 2001:db8:1:1::1/64 {
vrrp-inet6-group 1 {
virtual-inet6-address 2001:db8:1:1::254;
priority 110;
accept-data;
track {
interface ge-0/0/2 {
priority-cost 20;
}
}
}
}
}
}
}
ge-0/0/2 {
unit 0 {
family inet6 {
address 2001:db8:1:3::1/64;
}
}
}
[edit]
user@routerA# show protocols router-advertisement
interface ge-0/0/1.0 {
virtual-router-only;
prefix 2001:db8:1:1::/64;
}
[edit]
user@routerA# show routing-options
rib inet6.0 {
static {
route 0::0/0 next-hop 2001:db8:1:3::2;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration du routeur B
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 [edit] hiérarchie.
set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 vrrp-inet6-group 1 priority 110 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 vrrp-inet6-group 1 accept-data set protocols router-advertisement interface ge-0/0/1.0 virtual-router-only set protocols router-advertisement interface ge-0/0/1.0 prefix 2001:db8:1:1::/64
Procédure étape par étape
Pour configurer cet exemple :
-
Configurez les interfaces.
[edit] user@routerB# set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 user@routerB# set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:1:4::1/64
-
Configurez l’identificateur de groupe VRRP IPv6 et l’adresse IP virtuelle.
[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64] user@routerB# set vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254
-
Configurez
accept-datapour permettre au routeur de secours d’accepter tous les paquets destinés à l’adresse IP virtuelle au cas où le routeur de secours deviendrait principal.[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64] user@routerB# set vrrp-inet6-group 1 accept-data
-
Configurez un itinéraire statique pour le trafic vers Internet.
[edit] user@routerB# set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:4::2
-
Configurez l’interface sur laquelle VRRP est configuré pour envoyer des annonces de routeur IPv6 pour le groupe VRRP. Lorsqu’une interface reçoit un message de sollicitation de routeur IPv6, elle envoie une annonce de routeur IPv6 à tous les groupes VRRP configurés sur celle-ci.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerB# set prefix 2001:db8:1:1::/64
-
Configurez l’envoi d’annonces de routeur uniquement pour les groupes IPv6 VRRP configurés sur l’interface si les groupes sont à l’état principal.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerB# set virtual-router-only
Résultats
À partir du mode configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols router-advertisement et show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@routerB# show interfaces
ge-0/0/1 {
unit 0 {
family inet6 {
address 2001:db8:1:1::2/64 {
vrrp-inet6-group 1 {
virtual-inet6-address 2001:db8:1:1::254;
accept-data;
}
}
}
}
}
ge-0/0/2 {
unit 0 {
family inet6 {
address 2001:db8:1:4::1/64;
}
}
}
[edit]
user@routerB# show protocols router-advertisement
interface ge-0/0/1.0 {
virtual-router-only;
prefix 2001:db8:1:1::/64;
}
[edit]
user@routerB# show routing-options
rib inet6.0 {
static {
route 0::0/0 next-hop 2001:db8:1:4::2;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration du routeur C
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 [edit] hiérarchie.
set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:1:1::3/64 set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:1::254
Vérification
- Vérification du fonctionnement du VRRP sur le routeur A
- Vérification du fonctionnement du VRRP sur le routeur B
- Vérification que le routeur C atteint le routeur de transit Internet A
- Vérification que le routeur B devient principal pour VRRP
Vérification du fonctionnement du VRRP sur le routeur A
But
Vérifiez que VRRP est actif sur le routeur A et que son rôle dans le groupe VRRP est correct.
Action
Utilisez les commandes suivantes pour vérifier que VRRP est actif sur le routeur A, que le routeur est principal pour le groupe 1 et que l’interface connectée à Internet est suivie.
user@routerA> show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/1.0 up 1 master Active A 0.690 lcl 2001:db8:1:1::1
vip fe80::200:5eff:fe00:201
vip 2001:db8:1:1::254
user@routerA> show vrrp track Track Int State Speed VRRP Int Group VR State Current prio ge-0/0/2.0 up 1g ge-0/0/1.0 1 master 110
Signification
La show vrrp commande affiche des informations fondamentales sur la configuration VRRP. Cette sortie indique que le groupe VRRP est actif et que ce routeur a assumé le rôle principal. L’adresse lcl est l’adresse physique de l’interface et l’adresse vip est l’adresse virtuelle partagée par les deux routeurs. La Timer valeur (A 0.690) indique le temps restant (en secondes) pendant lequel ce routeur s’attend à recevoir une annonce VRRP de l’autre routeur.
Vérification du fonctionnement du VRRP sur le routeur B
But
Vérifiez que VRRP est actif sur le routeur B et que son rôle dans le groupe VRRP est correct.
Action
Utilisez la commande suivante pour vérifier que VRRP est actif sur le routeur B et qu’il s’agit d’un routeur de secours pour le groupe 1.
user@routerB> show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/1.0 up 1 backup Active D 2.947 lcl 2001:db8:1:1::2
vip fe80::200:5eff:fe00:201
vip 2001:db8:1:1::254
mas fe80::5668:a0ff:fe99:2d7d
Signification
La show vrrp commande affiche des informations fondamentales sur la configuration VRRP. Cette sortie indique que le groupe VRRP est actif et que ce routeur a assumé le rôle de secours. L’adresse lcl est l’adresse physique de l’interface et l’adresse vip est l’adresse virtuelle partagée par les deux routeurs. La Timer valeur (D 2.947) indique le temps restant (en secondes) pendant lequel ce routeur s’attend à recevoir une annonce VRRP de l’autre routeur.
Vérification que le routeur C atteint le routeur de transit Internet A
But
Vérifiez la connectivité à Internet à partir du routeur C.
Action
Utilisez les commandes suivantes pour vérifier que le routeur C peut accéder à Internet.
user@routerC> ping 2001:db8:16:255::1 count 2 PING6(56=40+8+8 bytes) 2001:db8:1:1::3 --> 2001:db8:16:255::1 16 bytes from 2001:db8:16:255::1, icmp_seq=0 hlim=63 time=12.810 ms 16 bytes from 2001:db8:16:255::1, icmp_seq=1 hlim=63 time=30.139 ms --- 2001:db8:16:255::1 ping6 statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/std-dev = 12.810/21.474/30.139/8.664 ms
user@routerC> traceroute 2001:db8:16:255::1 traceroute6 to 2001:db8:16:255::1 (2001:db8:16:255::1) from 2001:db8:1:1::3, 64 hops max, 12 byte packets 1 2001:db8:1:1::1 (2001:db8:1:1::1) 9.891 ms 32.353 ms 7.859 ms 2 2001:db8:16:255::1 (2001:db8:16:255::1) 257.483 ms 19.877 ms 7.451 ms
Signification
La ping commande indique l’accessibilité à Internet et la commande indique que le traceroute routeur A est en cours de transit.
Vérification que le routeur B devient principal pour VRRP
But
Vérifiez que le routeur B devient principal pour VRRP lorsque l’interface entre le routeur A et Internet tombe en panne.
Action
Utilisez les commandes suivantes pour vérifier que le routeur B est principal et que le routeur C peut atteindre le routeur B transitant par Internet.
user@routerA> show vrrp track detail
Tracked interface: ge-0/0/2.0
State: down, Speed: 1g
Incurred priority cost: 20
Tracking VRRP interface: ge-0/0/1.0, Group: 1
VR State: backup
Current priority: 90, Configured priority: 110
Priority hold-time: disabled
user@routerB> show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/1.0 up 1 master Active A 0.119 lcl 2001:db8:1:1::2
vip fe80::200:5eff:fe00:201
vip 2001:db8:1:1::254
user@routerC> traceroute 2001:db8:16:255::1 traceroute6 to 2001:db8:16:255::1 (2001:db8:16:255::1) from 2001:db8:1:1::3, 64 hops max, 12 byte packets 1 2001:db8:1:1::2 (2001:db8:1:1::2) 52.945 ms 344.383 ms 29.540 ms 2 2001:db8:16:255::1 (2001:db8:16:255::1) 46.168 ms 24.744 ms 23.867 ms
Signification
La show vrrp track detail commande indique que l’interface suivie est en panne sur le routeur A, que la priorité est tombée à 90 et que le routeur A est maintenant la sauvegarde. La show vrrp commande indique que le routeur B est maintenant le principal pour VRRP et la commande indique que le traceroute routeur B est en cours de transit.
Comportement des groupes d’agrégation de liens spécifiques à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.
| Plateforme |
Différence |
|---|---|
| SRX Series |
|
Informations supplémentaires sur la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
| Plateforme |
Interfaces LAG Ethernet redondantes |
|---|---|
| Séries SRX4600 et SRX5000 |
Chaque interface reth peut avoir jusqu’à huit liens par nœud, pour un total de 16 liens par interface. |
| SRX300 Series, SRX1500, SRX1600, SRX2300, SRX4100, SRX4200 et SRX4300 |
Chaque interface reth peut avoir jusqu’à quatre liens par nœud, pour un total de huit liens par interface. |