Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Interfaces Ethernet agrégées

Les rubriques ci-dessous présentent les interfaces Ethernet agrégées, les détails de configuration de l’agrégation de liens et des interfaces Ethernet agrégées, le dépannage et la vérification des interfaces Ethernet agrégées.

Présentation des interfaces Ethernet agrégées et de LACP pour les commutateurs

L’agrégation de liens IEEE 802.3ad 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.

L’agrégation de plusieurs liens entre des interfaces physiques crée une liaison trunk point à point logique unique, ou LAG. Le LAG équilibre le trafic sur les liaisons membres au sein d’un faisceau Ethernet agrégé et augmente efficacement la bande passante de la liaison montante. Un autre avantage de l’agrégation de liens est sa disponibilité accrue, car le LAG est composé de plusieurs liens membres. En cas de défaillance d’une liaison membre, le LAG continue d’acheminer le trafic sur les liaisons restantes.

Note:

Sur les commutateurs autonomes QFX5100, QFX5120, EX4600 QFX10002, ainsi que sur les Virtual Chassis QFX5100 Virtual Chassis et EX4600, vous pouvez configurer un débit mixte de vitesses de liaison pour le bundle Ethernet agrégé. Les vitesses de liaison de 10G, 40G et 100G sont prises en charge. L’équilibrage de charge ne fonctionne pas si vous configurez des vitesses de liaison qui ne sont pas prises en charge.

Note:

Vous pouvez configurer le canal de port à l’aide de différents modèles SFP entre deux points de terminaison tout en conservant la même bande passante.

Par exemple :

switch 1 gig0/1 (SFP-10G-SR-S) --------- MX 1 gig0/1 (SFP-10G-SR-S)

switch 1 gig0/2 (SFP-10G-LR-S) --------- MX 1 gig0/2 (SFP-10G-LR-S)

Le protocole LACP (Link Aggregation Control Protocol) est un sous-composant de la norme IEEE 802.3ad et est utilisé comme protocole de découverte.

Note:

Pour assurer l’équilibrage de charge entre les interfaces Ethernet agrégées (AE) sur un groupe de nuds serveur redondant, les membres de l’AE doivent être répartis de manière égale sur le groupe de nuds serveur redondant.

Note:

Lors d’un basculement de groupe de nuds de réseau, le trafic peut être interrompu pendant quelques secondes.

Groupe d’agrégation de liens

Pour configurer un LAG, spécifiez le numéro de liaison en tant que périphérique physique, puis associez un ensemble d’interfaces (ports) à la liaison. Toutes les interfaces doivent avoir la même vitesse et être en mode full-duplex. Juniper Networks Système d'exploitation Junos (Junos OS) for EX Series Commutateurs Ethernet attribue un ID unique et une priorité de port à chaque interface. L’ID et la priorité ne sont pas configurables.

Le nombre d’interfaces pouvant être regroupées dans un LAG et le nombre total de LAG pris en charge sur un commutateur varient en fonction du modèle de commutateur. Le Tableau 1 répertorie les commutateurs EX Series ainsi que le nombre maximal d’interfaces par LAG ainsi que le nombre maximal de LAG qu’ils prennent en charge.

Les LAG avec des liaisons membres de types d’interfaces différents, par exemple GE et MGE, ne sont pas pris en charge sur les commutateurs multidébit.

Note:

Pour Junos OS Evolved, le logiciel n’impose pas de limite au nombre maximal d’interfaces AE dans un bundle AE à débit mixte. Étant donné que toutes les interfaces logiques enfants appartiennent à la même interface physique AE et partagent le même sélecteur, en utilisant beaucoup moins de mémoire d’équilibrage de charge, les configurations d’interface AE à débit mixte doivent être acceptées même si elles dépassent 64 interfaces logiques.

Tableau 1 : nombre maximal d’interfaces par LAG et nombre maximal de LAG par commutateur (commutateurs EX Series)

Interrupteur

Nombre maximal d’interfaces par LAG

LAG max.

L’EX2200

8

32

L’EX2300

8

128

L’EX3200

8

32

EX3300 et EX3300 Virtual Chassis

8

32

L’EX3400

16

128

EX4200 et EX4200 Virtual Chassis

8

111

EX4300 et EX4300 Virtual Chassis

16

128

EX4500, EX4500 Virtual Chassis, EX4550 et EX4550 Virtual Chassis

8

111

Réf. EX4400 16 128

L’EX4600

32

128

Réf. EX6200

8

111

Réf. EX8200

12

255

EX8200 Virtual Chassis

12

239

Réf. EX9200

64

150

Tableau 2 : Nombre maximal d’interfaces par LAG et Nombre maximal de LAG par commutateur (commutateurs QFX Series)

Interrupteur

Nombre maximal d’interfaces par LAG

LAG max.

QFX3500

64

60

QFX3600

64

60

QFX5100

64

96

QFX5110

64

96

QFX5120

64

72

QFX5200

64

128

QFX5700

128

144

QFX10002

64

150

QFX10008

64

1000

QFX10016

64

1000

Note:

Sur les commutateurs QFX Series, si vous essayez de valider une configuration contenant plus de 64 interfaces Ethernet dans un LAG, vous recevrez un message d’erreur indiquant que la limite de 64 a été dépassée et que le retrait de la configuration a échoué.

Pour créer un LAG :

  1. Créez une interface Ethernet logique agrégée.

  2. Définissez les paramètres associés à l’interface Ethernet agrégée logique, tels qu’une unité logique, des propriétés d’interface et le protocole LACP (Link Aggregation Control Protocol).

  3. Définissez les liaisons membres à contenir dans l’interface Ethernet agrégée (par exemple, deux interfaces Ethernet 10 Gigabit).

  4. Configurez LACP pour la détection des liens.

Gardez à l’esprit ces consignes matérielles et logicielles :

  • Pour Junos OS Evolved, lorsqu’une nouvelle interface est ajoutée en tant que membre au bundle Ethernet agrégé, un événement link flap est généré. Lorsque vous ajoutez une interface à l’ensemble, l’interface physique est supprimée en tant qu’interface standard, puis rajoutée en tant que membre. Pendant ce temps, les détails de l’interface physique sont perdus.

  • Jusqu’à 32 interfaces Ethernet peuvent être regroupées pour former un LAG sur un groupe de nœuds de serveur redondant, un groupe de nœuds de serveur et un groupe de nœuds de réseau sur un système QFabric. Jusqu’à 48 LAG sont pris en charge sur les groupes de nœuds de serveur et les groupes de nœuds de serveur redondants sur un système QFabric, et jusqu’à 128 LAG sont pris en charge sur les groupes de nœuds de réseau sur un système QFabric. Vous pouvez configurer des LAG sur des périphériques de nœud dans des groupes de nœuds de serveur redondants, des groupes de nœuds de serveur et des groupes de nœuds de réseau.

    Note:

    Sur un système Qfabric, si vous essayez de valider une configuration contenant plus de 32 interfaces Ethernet dans un LAG, vous recevrez un message d’erreur indiquant que la limite de groupes de 32 a été dépassée et que l’extraction de la configuration a échoué.

  • Il est possible de regrouper jusqu’à 64 interfaces Ethernet pour former un LAG et, en Junos Fusion, jusqu’à 1 000 LAG sont pris en charge sur les commutateurs QFX10002 faisant office de périphériques d’agrégation.

  • Le LAG doit être configuré des deux côtés de la liaison.

  • Les interfaces situées de part et d’autre de la liaison doivent être réglées sur la même vitesse et être en mode duplex intégral.

    Note:

    Junos OS attribue un ID unique et une priorité de port à chaque port. L’ID et la priorité ne sont pas configurables.

  • Les systèmes QFabric prennent en charge un LAG spécial appelé FCoE LAG, qui vous permet de transporter le trafic FCoE et le trafic Ethernet standard (trafic qui n’est pas du trafic FCoE) sur le même bundle d’agrégation de liens. Les LAG standard utilisent un algorithme de hachage pour déterminer quel lien physique dans le LAG est utilisé pour une transmission, de sorte que la communication entre deux périphériques peut utiliser des liens physiques différents dans le LAG pour différentes transmissions. Un LAG FCoE garantit que le trafic FCoE utilise le même lien physique dans le LAG pour les demandes et les réponses afin de préserver la liaison point à point virtuelle entre la carte réseau convergée (CNA) de périphérique FCoE et le commutateur SAN FC sur un périphérique de nœud de système QFabric. Un LAG FCoE n’assure pas l’équilibrage de charge ni la redondance des liaisons pour le trafic FCoE. Toutefois, le trafic Ethernet normal utilise l’algorithme de hachage standard et bénéficie des avantages LAG habituels de l’équilibrage de charge et de la redondance des liaisons dans un LAG FCoE. Pour plus d’informations, reportez-vous à la section Comprendre les LAG FCoE .

Protocole LACP (Link Aggregation Control Protocol)

LACP est une méthode de regroupement de plusieurs interfaces physiques pour former une interface Ethernet agrégée logique. Par défaut, les liaisons Ethernet n’échangent pas d’unités de données de protocole (PDU) LACP, qui contiennent des informations sur l’état de la liaison. Vous pouvez configurer des liaisons Ethernet pour qu’elles transmettent activement des PDU LACP ou des liaisons pour qu’elles soient transmises passivement, en envoyant des PDU LACP uniquement lorsque la liaison Ethernet les reçoit de l’extrémité distante. Le mode LACP peut être actif ou passif. Le lien émetteur est connu sous le nom d’acteur, et le lien récepteur est connu sous le nom de partenaire. Si l’acteur et le partenaire sont tous deux en mode passif, ils n’échangent pas de paquets LACP et les liens Ethernet agrégés ne sont pas activés. Si l’acteur ou le partenaire est actif, ils échangent des paquets LACP. Par défaut, LACP est en mode passif sur les interfaces Ethernet agrégées. Pour initier la transmission des paquets LACP et la réponse aux paquets LACP, vous devez activer le mode actif LACP. Vous pouvez configurer des interfaces Ethernet agrégées avec et sans balise VLAN sans que LACP soit activé. LACP est défini dans IEEE 802.3ad, Aggregation of Multiple Link Segments.

LACP a été conçu pour atteindre les objectifs suivants :

  • Ajout et suppression automatiques de liens individuels vers le LAG sans intervention de l’utilisateur.

  • Surveillance des liens pour vérifier si les deux extrémités du bundle sont connectées au bon groupe.

Dans un scénario où un serveur multihoming est déployé avec un commutateur, les cartes d’interface réseau forment un LAG avec le commutateur. Lors d’une mise à niveau du serveur, il se peut que le serveur ne soit pas en mesure d’échanger les PDU LACP. Dans une telle situation, vous pouvez configurer une interface pour qu’elle soit dans l’état même si aucune PDU n’est up échangée. Utilisez l’instruction force-up pour configurer une interface lorsque l’homologue dispose d’une capacité LACP limitée. L’interface sélectionne par défaut le LAG associé, que le commutateur et l’homologue soient tous deux en mode actif ou passif. Lorsque les PDU ne sont pas reçues, le partenaire est considéré comme travaillant en mode passif. Par conséquent, les transmissions LACP PDU sont contrôlées par la liaison d’émission.

Si l’extrémité distante de la liaison LAG est un équipement de sécurité, il est possible que LACP ne soit pas pris en charge, car les équipements de sécurité nécessitent une configuration déterministe. Dans ce cas, ne configurez pas LACP. Toutes les liaisons du LAG sont opérationnelles en permanence, sauf si le commutateur détecte une défaillance de liaison au sein de la couche physique Ethernet ou des couches de liaison de données.

Lorsque LACP est configuré, il détecte les erreurs de configuration à l’extrémité locale ou à l’extrémité distante de la liaison. Ainsi, LACP peut aider à prévenir les échecs de communication :

  • Lorsque LACP n’est pas activé, un LAG local peut tenter de transmettre des paquets à une interface unique distante, ce qui entraîne l’échec de la communication.

  • Lorsque LACP est activé, un LAG local ne peut pas transmettre de paquets à moins qu’un LAG avec LACP ne soit également configuré à l’extrémité distante de la liaison.

Configuration d’une interface Ethernet agrégée

Vous pouvez associer une interface physique à une interface Ethernet agrégée.

Pour configurer une interface Ethernet agrégée :

  1. Indiquez que vous souhaitez configurer l’interface du groupe d’agrégation de liens.
  2. Configurez l’interface Ethernet agrégée.

Vous spécifiez le numéro x d’instance de l’interface pour terminer l’association de liens ; Vous devez également inclure une instruction définissant aex au niveau de la [edit interfaces] hiérarchie. Si vous le souhaitez, vous pouvez spécifier d’autres propriétés physiques qui s’appliquent spécifiquement aux interfaces Ethernet agrégées. Pour plus de détails, reportez-vous à la section Présentation des interfaces Ethernet.

Note:

En général, les bundles Ethernet agrégés prennent en charge les fonctionnalités disponibles sur toutes les interfaces prises en charge qui peuvent devenir un lien membre au sein du bundle. Par exception, les fonctionnalités Gigabit Ethernet IQ et certaines fonctionnalités Gigabit Ethernet plus récentes ne sont pas prises en charge dans les bundles Ethernet agrégés.

Les interfaces Gigabit Ethernet IQ et SFP peuvent être des liaisons membres, mais les fonctionnalités spécifiques à IQ et SFP ne sont pas prises en charge sur le bundle Ethernet agrégé, même si toutes les liaisons membres prennent individuellement en charge ces fonctionnalités.

Vous devez configurer la vitesse de liaison correcte pour l’interface Ethernet agrégée afin d’éliminer tout message d’avertissement.

Note:

Avant de valider une configuration Ethernet agrégée, assurez-vous que le mode de liaison n’est configuré sur aucune interface membre du bundle Ethernet agrégé ; Dans le cas contraire, la vérification de validation de la configuration échoue.

Configuration des interfaces Ethernet agrégées balisées

Pour spécifier des interfaces Ethernet agrégées, incluez l’instruction au vlan-tagging niveau de la [edit interfaces aex] hiérarchie :

Vous devez également inclure l’énoncé vlan-id suivant :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit interfaces interface-name unit logical-unit-number]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Pour plus d’informations sur les vlan-tagging instructions and vlan-id , reportez-vous à la section Présentation des VLAN 802.1Q.

Configuration d’interfaces Ethernet agrégées non balisées

Lorsque vous configurez une interface Ethernet agrégée non balisée, les règles existantes pour les interfaces non balisées s’appliquent. Ces règles sont les suivantes :

  • Vous ne pouvez configurer qu’une seule interface logique (unité 0) sur le port. L’unité logique 0 est utilisée pour envoyer et recevoir des unités de données LACP ou de protocole marqueur (PDU) vers et depuis les liaisons individuelles.

  • Vous ne pouvez pas inclure l’instruction vlan-id dans la configuration de l’interface logique.

Configurez une interface Ethernet agrégée non balisée en omettant lesvlan-tagging instructions and vlan-id de la configuration :

Configuration du nombre d’interfaces Ethernet agrégées sur l’équipement (logiciel de couche 2 amélioré)

Par défaut, aucune interface Ethernet agrégée n’est créée. Vous devez définir le nombre d’interfaces Ethernet agrégées sur le périphérique de routage avant de pouvoir les configurer.

  1. Spécifiez que vous souhaitez accéder à la configuration Ethernet agrégée sur le périphérique.
  2. Définissez le nombre d’interfaces Ethernet agrégées.

Vous devez également spécifier les liens physiques constitutifs en incluant l’instruction 802.3ad au niveau de la [edit interfaces interface-name ether-options] hiérarchie.

Exemple : Configuration d’interfaces Ethernet agrégées

Les interfaces Ethernet agrégées peuvent utiliser des interfaces de différents FPC, DPC ou PIC. La configuration suivante est suffisante pour qu’une interface Gigabit Ethernet agrégée soit opérationnelle.

Suppression d’une interface Ethernet agrégée

Il existe deux approches pour supprimer une interface Ethernet agrégée :

  • Vous pouvez supprimer une interface Ethernet agrégée de la configuration de l’interface. Junos OS supprime les instructions de configuration associées à aex et met cette interface à l’état inactif.

  • Vous pouvez également supprimer définitivement l’interface Ethernet agrégée de la configuration de l’appareil en la supprimant du nombre d’appareils sur l’appareil de routage.

Pour supprimer une interface Ethernet agrégée :

  1. Supprimez la configuration Ethernet agrégée.

    Cette étape change l’état de l’interface en down et supprime les instructions de configuration liées à aex.

  2. Supprimez l’interface du nombre d’appareils.

Dépannage d’une interface Ethernet agrégée

Dépannage des problèmes liés aux interfaces Ethernet agrégées :

La commande show interfaces indique que le LAG est en panne

Problème

Description

La show interfaces terse commande indique que le LAG est en panne.

Solution

Vérifiez les points suivants :

  • Vérifiez qu’il n’y a pas d’incompatibilité de configuration.

  • Vérifiez que tous les ports membres sont opérationnels.

  • Vérifiez qu’un LAG fait partie de la famille Ethernet, c’est-à-dire de la commutation (LAG de couche 2) ou de l’inet de famille (LAG de couche 3).

  • Vérifiez que le membre LAG est connecté au bon LAG à l’autre extrémité.

  • Vérifiez que les membres LAG appartiennent au même commutateur (ou au même Virtual Chassis).

Les statistiques de l’interface logique ne reflètent pas l’ensemble du trafic

Problème

Description

Les statistiques de trafic d’une interface logique n’incluent pas l’ensemble du trafic.

Solution

Les champs de statistiques de trafic pour les interfaces logiques dans show interfaces les commandes affichent uniquement le trafic de contrôle, les statistiques de trafic n’incluent pas le trafic de données. Vous ne pouvez afficher les statistiques de l’ensemble du trafic que par interface physique.

Les statistiques de trafic de l’interface IPv6 ne sont pas prises en charge

Problème

Description

Le IPv6 transit statistics dans la show interfaces commande affiche toutes les 0 valeurs.

Solution

Les commutateurs EX Series ne prennent pas en charge la collecte et la génération de rapports sur les statistiques de transit IPv6.

Les compteurs SNMP ifHCInBroadcastPkts et ifInBroadcastPkts ont toujours la valeur 0

Problème

Description

Les valeurs des compteurs SNMP ifHCInBroadcastPkts et ifInBroadcastPkts sont toujours égales à 0.

Solution

Les compteurs SNMP ifHCInBroadcastPkts et ifInBroadcastPkts ne sont pas pris en charge pour les interfaces Ethernet agrégées sur les commutateurs EX Series.

Configuration du rééquilibrage périodique des abonnés dans une interface Ethernet agrégée

Si les abonnés se connectent et se déconnectent fréquemment de votre réseau, vous pouvez configurer le système pour qu’il rééquilibre périodiquement les liaisons en fonction d’une heure et d’un intervalle spécifiques.

Pour configurer le rééquilibrage périodique :

  1. Accédez à l’interface Ethernet agrégée pour laquelle vous souhaitez configurer un rééquilibrage périodique.
  2. Configurez les paramètres de rééquilibrage de l’interface, y compris le temps et l’intervalle entre les actions de rééquilibrage.

Configuration d’Aggregated Ethernet LACP

Pour les interfaces Ethernet agrégées, vous pouvez configurer le protocole LACP (Link Aggregation Control Protocol). LACP est une méthode qui consiste à regrouper plusieurs interfaces physiques pour former une seule interface logique. Vous pouvez configurer des réseaux Ethernet agrégés avec et sans balise VLAN, avec ou sans LACP activé.

Pour l’agrégation de liens multichâssis (MC-LAG), vous devez spécifier les valeurs et system-id admin key. Les homologues MC-LAG utilisent la même chose system-id lors de l’envoi des messages LACP. Ils system-id peuvent être configurés sur l’équipement réseau MC-LAG et synchronisés entre les homologues pour la validation.

Les échanges LACP se font entre acteurs et partenaires. Un acteur est l’interface locale dans un échange LACP. Un partenaire est l’interface distante dans un échange LACP.

LACP est défini dans la norme IEEE 802.3ad, Aggregation of Multiple Link Segments.

LACP a été conçu pour atteindre les objectifs suivants :

  • Ajout et suppression automatiques de liens individuels dans le bundle agrégé sans intervention de l’utilisateur

  • Surveillance des liens pour vérifier si les deux extrémités du bundle sont connectées au bon groupe

L’implémentation Junos OS de LACP surveille les liens, mais pas l’ajout et la suppression automatiques de liens.

Le mode LACP peut être actif ou passif. Si l’acteur et le partenaire sont tous deux en mode passif, ils n’échangent pas de paquets LACP, ce qui empêche les liaisons Ethernet agrégées d’être établies. Si l’acteur ou le partenaire est actif, ils échangent des paquets LACP. Par défaut, LACP est désactivé sur les interfaces Ethernet agrégées. Si LACP est configuré, il est en mode passif par défaut. Pour initier la transmission des paquets LACP et la réponse aux paquets LACP, vous devez configurer LACP en mode actif.

Pour activer le mode actif LACP, incluez l’instruction lacp au niveau de la [edit interfaces interface-name aggregated-ether-options] hiérarchie et spécifiez l’option active :

Note:

Le processus LACP n’existe dans le système que si vous configurez le système en mode LACP actif ou passif.

Pour restaurer le comportement par défaut, incluez l’instruction lacp au niveau de la [edit interfaces interface-name aggregated-ether-options] hiérarchie et spécifiez l’option passive :

À partir de Junos OS version 12.2, vous pouvez également configurer LACP pour remplacer la norme IEEE 802.3ad et autoriser le lien de secours à toujours recevoir du trafic. Le remplacement du comportement par défaut facilite le basculement en moins d’une seconde.

Pour remplacer la norme IEEE 802.3ad et faciliter le basculement en moins d’une seconde, incluez l’instruction fast-failover au niveau de la [edit interfaces interface-name aggregated-ether-options lacp] hiérarchie.

Pour plus d’informations, consultez les sections suivantes :

Configuration de l’intervalle LACP

Par défaut, l’acteur et le partenaire envoient des paquets LACP toutes les secondes. Vous pouvez configurer l’intervalle auquel les interfaces envoient des paquets LACP en incluant l’instruction periodic au niveau de la [edit interfaces interface-name aggregated-ether-options lacp] hiérarchie :

L’intervalle peut être rapide (toutes les secondes) ou lent (toutes les 30 secondes). Vous pouvez configurer différents taux périodiques sur les interfaces actives et passives. Lorsque vous configurez les interfaces actives et passives à des débits différents, l’émetteur respecte le débit du récepteur.

Note:

Le filtrage des adresses sources ne fonctionne pas lorsque LACP est activé.

Les mécanismes de contrôle de pourcentage ne sont pas pris en charge sur les interfaces Ethernet agrégées avec la famille de protocoles CCC configurée. Pour plus d’informations sur les mécanismes de contrôle de pourcentage, consultez le Guide de l’utilisateur des mécanismes de contrôle du trafic, des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

En règle générale, LACP est pris en charge sur toutes les interfaces Ethernet agrégées non balisées. Pour plus d’informations, reportez-vous à la section Configuration d’interfaces Ethernet agrégées non balisées.

Configuration de la protection des liens LACP

Note:

Lorsque vous utilisez la protection de liaison LACP, vous ne pouvez configurer que deux liaisons membres vers une interface Ethernet agrégée : une active et une en veille.

Pour forcer des liaisons actives et en veille au sein d’un Ethernet agrégé, vous pouvez configurer la protection de la liaison LACP et la priorité système au niveau de l’interface Ethernet agrégée à l’aide des link-protection instructions and system-priority . La configuration des valeurs à ce niveau génère uniquement les interfaces configurées à l’aide de la configuration définie. La configuration de l’interface LACP vous permet également de remplacer les paramètres LACP globaux (châssis).

La protection des liaisons LACP utilise également la priorité de port. Vous pouvez configurer la priorité des ports au niveau de la hiérarchie de l’interface [ether-options] Ethernet à l’aide de l’instruction port-priority . Si vous choisissez de ne pas configurer la priorité des ports, la protection des liens LACP utilise la valeur par défaut de la priorité des ports (127).

Note:

La protection de liaison LACP prend en charge la configuration de planification par unité sur des interfaces Ethernet agrégées.

Pour activer la protection de liaison LACP pour une interface Ethernet agrégée, utilisez l’instruction suivante link-protection au niveau de la [edit interfaces aeX aggregated-ether-options lacp] hiérarchie :

Par défaut, la protection des liens LACP revient à une liaison de priorité supérieure (numéro inférieur) lorsque cette liaison de priorité supérieure devient opérationnelle ou qu’un lien de priorité supérieure est ajouté à l’agrégateur déterminé comme étant de priorité supérieure. Toutefois, vous pouvez supprimer le calcul de liaison en ajoutant l’instruction non-revertive à la configuration de protection de liaison LACP. En mode non réversible, une fois qu’une liaison est active et qu’elle collecte et distribue des paquets, l’ajout ultérieur d’une liaison de priorité supérieure (meilleure) n’entraîne pas de commutation et la liaison actuelle reste active.

Si la protection de liaison LACP est configurée pour être non réversible au niveau global ([edit chassis] hiérarchie), vous pouvez ajouter l’instruction revertive à la configuration de protection de liaison LACP pour remplacer le paramètre non inverse de l’interface. En mode inverse, l’ajout d’un lien de priorité plus élevée à l’agrégateur entraîne l’exécution d’un nouveau calcul de priorité par LACP et le passage de la liaison active actuelle à la nouvelle liaison active.

ATTENTION:

Si la protection des liens LACP est activée aux deux extrémités d’un agrégateur, veillez à configurer les deux extrémités de l’agrégateur pour qu’elles utilisent le même mode. Une incompatibilité des modes de protection de liaison LACP peut entraîner une perte de trafic.

Nous vous recommandons vivement d’utiliser LACP aux deux extrémités de l’agrégateur lorsque vous connectez une interface Ethernet agrégée avec deux interfaces membres à un équipement d’un autre fournisseur. Dans le cas contraire, l’équipement du fournisseur (par exemple, un commutateur de couche 2 ou un routeur) ne sera pas en mesure de gérer le trafic provenant du bundle Ethernet agrégé à deux liaisons. Par conséquent, vous pouvez observer que l’appareil du fournisseur renvoie le trafic vers le lien membre de sauvegarde de l’interface Ethernet agrégée.

Actuellement, les modèles MX-MPC2-3D, MX-MPC2-3D-Q, MX-MPC2-3D-EQ, MX-MPC1-3D, MX-MPC1-3D-Q et MPC-3D-16XGE-SFPP ne suppriment pas le trafic renvoyé vers la liaison de sauvegarde, tandis que les modèles DPCE-R-Q-20GE-2XGE, DPCE-R-Q-20GE-SFP, DPCE-R-Q-40GE-SFP, DPCE-R-Q-4XGE-XFP, DPCE-X-Q-40GE-SFP et DPCE-X-Q-4XGE-XFP abandonnent le trafic arrivant sur la liaison de sauvegarde.

Configuration de la priorité du système LACP

Pour configurer la priorité système LACP pour les interfaces Ethernet agrégées sur l’interface, utilisez l’instruction suivante system-priority au niveau de la [edit interfaces aeX aggregated-ether-options lacp] hiérarchie :

La priorité système est une valeur binaire de 2 octets qui fait partie de l’ID système LACP. L’ID système LACP se compose de la priorité système comme les deux octets les plus significatifs et l’adresse MAC de l’interface comme les six octets les moins significatifs. Le système dont la valeur numérique est la plus faible pour la priorité du système a la priorité la plus élevée. Par défaut, la priorité système est 127, avec une plage comprise entre 0 et 65 535.

Configuration de l’identificateur système LACP

Pour configurer l’identificateur système LACP pour les interfaces Ethernet agrégées, utilisez l’instruction suivante system-id au niveau de la [edit interfaces aeX aggregated-ether-options lacp] hiérarchie :

L’identificateur système défini par l’utilisateur dans LACP permet à deux ports de deux périphériques distincts d’agir comme s’ils faisaient partie du même groupe d’agrégats.

L’identificateur système est un champ de 48 bits (6 octets) unique au niveau mondial. Il est utilisé en combinaison avec une valeur de priorité système de 16 bits, ce qui donne un identifiant système LACP unique.

Configuration de la clé d’administration LACP

Pour configurer une clé d’administration pour LACP, incluez l’instruction admin-key number au niveau de la edit interfaces aex aggregated-ether-options lacp] hiérarchie :

Note:

Vous devez configurer MC-LAG pour configurer l’instruction admin-key . Pour plus d’informations sur MC-LAG, reportez-vous à la section Configuration de l’agrégation de liens multichâssis sur les routeurs MX Series .

Configuration de la priorité des ports LACP

Pour configurer la priorité des ports LACP pour les interfaces Ethernet agrégées, utilisez l’instruction port-priority au niveau de la [edit interfaces interface-name ether-options 802.3ad aeX lacp] hiérarchie ou [edit interfaces interface-name ether-options 802.3ad aeX lacp] :

La priorité de port est un champ de 2 octets qui fait partie de l’ID de port LACP. L’ID de port LACP se compose de la priorité du port sous la forme des deux octets les plus significatifs et du numéro du port sous la forme des deux octets les moins significatifs. Le système avec la valeur numériquement la plus faible pour la priorité de port a la priorité la plus élevée. Par défaut, la priorité des ports est 127, avec une plage comprise entre 0 et 65 535.

Les ports sont sélectionnés par chaque système en fonction de la priorité de port la plus élevée et sont attribués par le système ayant la priorité la plus élevée. Les ports sont sélectionnés et attribués en commençant par le port de priorité la plus élevée du système de priorité la plus élevée et en descendant dans la priorité à partir de là.

Note:

La sélection de l’agrégation de ports (voir ci-dessus) est effectuée pour la liaison active lorsque la protection de liaison LACP est activée. Sans protection de liaison LACP, la priorité des ports n’est pas utilisée dans la sélection de l’agrégation de ports.

Le traçage des opérations LACP

Pour tracer les opérations du processus LACP, incluez l’instruction traceoptions au niveau de la [edit protocols lacp] hiérarchie :

Vous pouvez spécifier les indicateurs suivants dans l’instruction protocols lacp traceoptions :

  • all—Toutes les opérations de suivi LACP

  • configuration—Code de configuration

  • packet—Paquets envoyés et reçus

  • process—Événements de processus LACP

  • protocol—Machine d’état de protocole LACP

  • routing-socket—Événements de socket de routage

  • startup—Événements de démarrage de processus

Limites de LACP

LACP peut relier plusieurs interfaces physiques différentes, mais seules les fonctionnalités prises en charge sur tous les équipements liés seront prises en charge dans le bundle LAG (Link Aggregation Group) résultant. Par exemple, différents PIC peuvent prendre en charge un nombre différent de classes de transfert. Si vous utilisez l’agrégation de liens pour lier les ports d’un CIP qui prend en charge jusqu’à 16 classes de transfert avec un CIP qui prend en charge jusqu’à 8 classes de transfert, le bundle LAG résultant ne prendra en charge que 8 classes de transfert maximum. De même, la liaison d’un PIC qui prend en charge WRED avec un PIC qui ne le prend pas en charge se traduira par un bundle LAG qui ne prend pas en charge WRED.

Exemple : Configuration d’un réseau LACP Ethernet agrégé

Cet exemple montre comment configurer une interface Ethernet agrégée avec LACP actif entre deux commutateurs EX.

Topologie

Deux commutateurs EX sont connectés entre eux à l’aide de deux interfaces dans une configuration Ethernet agrégée.

Configurez le protocole LACP Ethernet agrégé sur une interface non balisée :

Note:

Dans cet exemple, nous ne montrons que la configuration pour EX1. EX2 a la même configuration, à l’exception de l’adresse IP.

LACP avec Ethernet agrégé non étiqueté

La configuration du châssis permet 1 interface Ethernet agrégée. La 802.3ad configuration associe à la fois les interfaces ge-0/0/0 et ge-0/0/1 l’interface ae0. La ae0 aggregated-ether-options configuration active LACP en mode actif.

Vérification
Vérification de l’interface Ethernet agrégée
But

Vérifiez que l’interface Ethernet agrégée a été créée et qu’elle est active.

Action

Utilisez la commande show interfaces terse | match ae à partir du mode opérationnel.

Sens

La sortie montre que ge-0/0/0 et ge-0/0/1 sont regroupés pour créer l’interface ae0 Ethernet agrégée et que l’interface est active.

Vérification de l’activation de LACP
But

Vérifiez quelles interfaces participent à LACP et l’état actuel.

Action

Utilisez la commande show lacp interfaces à partir du mode opérationnel.

Sens

La sortie indique que le mode actif LACP est activé.

Vérifier l’accessibilité
But

Vérifiez que la commande ping fonctionne entre les deux commutateurs EX.

Action

Utilisez la commande du ping 10.1.1.2 count 2 mode opérationnel sur EX1.

Sens

EX1 est capable d’envoyer une requête ping à EX2 sur l’interface Ethernet agrégée.

Vérification que LACP est correctement configuré et que les membres du bundle échangent des paquets de protocole LACP

Vérifiez que LACP a été correctement configuré et que les membres du bundle transmettent des paquets de protocole LACP.

Vérification de la configuration LACP

But

Vérifiez que le LACP a été correctement configuré.

Action

Pour vérifier que LACP a été activé comme actif à une extrémité :

Sens

Cet exemple montre que LACP a été configuré avec un côté comme actif et l’autre comme passif. Lorsque LACP est activé, un côté doit être défini comme actif pour que le lien groupé soit actif.

Vérification de l’échange des paquets LACP

But

Vérifiez que les paquets LACP sont échangés entre les interfaces.

Action

Utilisez la commande pour afficher les show lacp statistics interfaces interface-name informations d’échange LACP BPDU.

Sens

La sortie indique que la liaison est active et que des PDU sont en cours d’échange.

Comprendre les sessions Micro BFD indépendantes pour le LAG

Le protocole BFD (Bidirectional Forwarding Detection) est un protocole de détection simple qui détecte rapidement les défaillances dans les chemins de transfert. Pour activer la détection des défaillances des interfaces Ethernet agrégées dans un LAG, vous pouvez configurer une session BFD indépendante en mode asynchrone sur chaque liaison membre LAG d’un bundle LAG. Au lieu d’une seule session BFD surveillant l’état du port UDP, des sessions micro-BFD indépendantes surveillent l’état des liaisons membres individuelles.

Lorsque vous configurez des sessions micro-BFD sur chaque liaison membre d’un bundle LAG, chaque session individuelle détermine la connectivité de couche 2 et de couche 3 de chaque liaison membre dans un LAG.

Une fois la session individuelle établie sur une liaison particulière, les liaisons membres sont attachées au LAG, puis équilibrées en charge selon l’un des éléments suivants :

  • Configuration statique : le processus de contrôle de périphérique agit en tant que client de la session micro-BFD.

  • LACP (Link Aggregation Control Protocol) : le protocole LACP agit en tant que client de la session micro-BFD.

Lorsque la session micro-BFD est active, une liaison LAG est établie et les données sont transmises sur cette liaison LAG. Si la session micro-BFD sur une liaison membre est inactive, cette liaison membre particulière est supprimée de l’équilibreur de charge et les gestionnaires LAG cessent de diriger le trafic vers cette liaison. Ces sessions micro-BFD sont indépendantes les unes des autres, bien qu’elles disposent d’un seul client qui gère l’interface LAG.

Les sessions Micro-BFD s’exécutent dans les modes suivants :

  • Mode de distribution : dans ce mode, le moteur de transfert de paquets (PFE) envoie et reçoit les paquets au niveau de la couche 3. Par défaut, les sessions micro-BFD sont distribuées au niveau de la couche 3.

  • Mode de non-distribution : dans ce mode, le moteur de routage envoie et reçoit les paquets au niveau de la couche 2. Vous pouvez configurer la session BFD pour qu’elle s’exécute dans ce mode en incluant l’instruction no-delegate-processing sous la gestion périodique des paquets (PPM).

Une paire de périphériques de routage dans un LAG échange des paquets BFD à un intervalle régulier spécifié. Le périphérique de routage détecte une défaillance de voisinage lorsqu’il cesse de recevoir une réponse après un intervalle spécifié. Cela permet de vérifier rapidement la connectivité de la liaison avec ou sans LACP. Un port UDP distingue les paquets BFD sur LAG des paquets BFD sur IP à saut unique. L’Internet Assigned Numbers Authority (IANA) a attribué 6784 comme port de destination UDP pour micro-BFD.

Avantages

  • Failure detection for LAG (Détection des défaillances pour LAG) : active la détection des défaillances entre les périphériques qui se trouvent dans des connexions point à point.

  • Sessions BFD multiples : vous permet de configurer plusieurs sessions micro-BFD pour chaque liaison membre au lieu d’une seule session BFD pour l’ensemble du bundle.

Instructions de configuration pour les sessions Micro-BFD

Tenez compte des instructions suivantes lorsque vous configurez des sessions micro-BFD individuelles sur un bundle Ethernet agrégé.

  • Cette fonctionnalité ne fonctionne que lorsque les deux appareils prennent en charge BFD. Si BFD est configuré à une extrémité du LAG, cette fonctionnalité ne fonctionne pas.

  • Depuis Junos OS version 13.3, l’IANA a attribué 01-00-5E-90-00-01 comme adresse MAC dédiée pour micro BFD. Le mode MAC dédié est utilisé par défaut pour les sessions micro BFD.

  • Dans Junos OS, les paquets de contrôle micro-BFD ne sont toujours pas étiquetés par défaut. Pour les interfaces agrégées de couche 2, la configuration doit inclure vlan-tagging des options or flexible-vlan-tagging lorsque vous configurez Ethernet agrégé avec BFD. Dans le cas contraire, le système générera une erreur lors de la validation de la configuration.

  • Lorsque vous activez micro-BFD sur une interface Ethernet agrégée, l’interface agrégée peut recevoir des paquets micro-BFD. Dans Junos OS version 19.3 et ultérieure, pour les MPC MPC10E et MPC11E, vous ne pouvez pas appliquer de filtres de pare-feu sur les paquets micro-BFD reçus sur l’interface Ethernet agrégée. Pour MPC1E à MPC9E, vous pouvez appliquer des filtres de pare-feu sur les paquets micro-BFD reçus sur l’interface Ethernet agrégée uniquement si l’interface Ethernet agrégée est configurée en tant qu’interface non balisée.

  • À partir de Junos OS version 14.1, spécifiez le voisin dans une session BFD. Dans les versions antérieures à Junos OS version 16.1, vous devez configurer l’adresse de bouclage de la destination distante en tant qu’adresse voisine. À partir de Junos OS version 16.1, vous pouvez également configurer cette fonctionnalité sur les routeurs MX Series avec l’adresse d’interface Ethernet agrégée de la destination distante comme adresse voisine.

  • À partir de la version 16.1R2, Junos OS vérifie et valide le micro-BFD local-address configuré par rapport à l’interface ou à l’adresse IP de bouclage avant la validation de la configuration. Junos OS effectue cette vérification sur les configurations d’adresses micro-BFD IPv4 et IPv6, et si elles ne correspondent pas, la validation échoue. L’adresse locale micro-BFD configurée doit correspondre à l’adresse voisine micro-BFD que vous avez configurée sur le routeur homologue.

  • Pour la famille d’adresses IPv6, désactivez la détection des adresses en double avant de configurer cette fonctionnalité avec des adresses d’interface Ethernet agrégées. Pour désactiver la détection des adresses en double, incluez l’instruction dad-disable au niveau de la [edit interface aex unit y family inet6] hiérarchie.

  • À partir de Junos OS 21.4R1, la liaison minimale LACP avec réinitialisation de synchronisation et configuration microBFD est prise en charge sur les routeurs PTX10001-36MR, PTX10003, PTX10004, PTX10008 et PTX10016.

ATTENTION:

Désactivez-la bfd-liveness-detection au niveau de la [edit interfaces aex aggregated-ether-options] hiérarchie ou désactivez l’interface Ethernet agrégée avant de remplacer l’adresse de voisinage de l’adresse IP de bouclage par l’adresse IP de l’interface Ethernet agrégée. La modification de l’adresse locale et de l’adresse voisine sans d’abord désactiver bfd-liveness-detection l’interface Ethernet agrégée peut entraîner l’échec des sessions micro-BFD.

Configuration de sessions Micro BFD pour LAG

Le protocole BFD (Bidirectional Forwarding Detection) est un protocole de détection simple qui détecte rapidement les défaillances dans les chemins de transfert. Un groupe d’agrégation de liens (LAG) combine plusieurs liaisons entre des équipements qui se trouvent dans des connexions point à point, augmentant ainsi la bande passante, assurant la fiabilité et permettant l’équilibrage de charge. Pour exécuter une session BFD sur des interfaces LAG, configurez une session BFD indépendante en mode asynchrone sur chaque liaison membre LAG d’un bundle LAG. Au lieu d’une seule session BFD qui surveille l’état du port UDP, des sessions micro BFD indépendantes surveillent l’état des liaisons membres individuelles.

Note:

À compter de Junos OS Evolved version 20.1R1, les sessions BFD (Bidirectional Forwarding Detection) indépendantes sont activées par liaison membre d’un bundle LAG (Link Aggregation Group).

Pour activer la détection des défaillances des interfaces Ethernet agrégées :

  1. Incluez l’instruction suivante dans la configuration au niveau de la [edit interfaces aex aggregated-ether-options] hiérarchie :
  2. Configurez les critères d’authentification de la session BFD pour LAG.

    Pour spécifier les critères d’authentification, incluez l’instruction authentication suivante :

    • Spécifiez l’algorithme à utiliser pour authentifier la session BFD. Vous pouvez utiliser l’un des algorithmes d’authentification suivants :

      • cléed-md5

      • keyed-sha-1

      • méticuleuse-clé-md5

      • méticuleuse-clé-sha-1

      • mot de passe simple

    • Pour configurer le trousseau de clés, spécifiez le nom associé à la clé de sécurité de la session BFD. Le nom que vous spécifiez doit correspondre à l’un des trousseaux configurés dans l’instruction authentication-key-chains key-chain au niveau de la [edit security] hiérarchie.

    • Configurez la vérification de l’authentification libre sur la session BFD. À utiliser uniquement pour les périodes transitoires où l’authentification peut ne pas être configurée aux deux extrémités de la session BFD.

  3. Configurez des temporisateurs BFD pour les interfaces Ethernet agrégées.

    Pour spécifier les temporisateurs BFD, incluez l’instruction detection-time suivante :

    Spécifiez la valeur de seuil. Il s’agit de l’intervalle de temps maximal pour la détection d’un voisin BFD. Si l’intervalle de transmission est supérieur à cette valeur, l’appareil déclenche une interruption.

  4. Configurez une valeur d’intervalle de maintien pour définir la durée minimale pendant laquelle la session BFD doit rester active avant qu’une notification de changement d’état ne soit envoyée aux autres membres du réseau LAG.

    Pour spécifier l’intervalle de retenue, incluez l’instruction holddown-interval suivante :

    Vous pouvez configurer un nombre compris entre 0 et 255 000 millisecondes, et la valeur par défaut est 0. Si la session BFD s’arrête, puis revient pendant l’intervalle de maintien, le minuteur est redémarré.

    Cette valeur représente l’intervalle minimal auquel le périphérique de routage local transmet les paquets BFD, ainsi que l’intervalle minimum dans lequel le périphérique de routage s’attend à recevoir une réponse d’un voisin avec lequel il a établi une session BFD. Vous pouvez configurer un nombre compris entre 1 et 255 000 millisecondes. Vous pouvez également spécifier séparément les intervalles minimum d’émission et de réception.

  5. Configurez l’adresse source de la session BFD.

    Pour spécifier une adresse locale, incluez l’instruction local-address suivante :

    L’adresse locale BFD est l’adresse de bouclage de la source de la session BFD.

    Note:

    À partir de Junos OS version 16.1, vous pouvez également configurer cette fonctionnalité avec l’adresse de l’interface AE comme adresse locale dans une session micro BFD. Pour la famille d’adresses IPv6, désactivez la détection des adresses en double avant de configurer cette fonctionnalité avec l’adresse d’interface AE. Pour désactiver la détection des adresses en double, incluez l’instruction dad-disable au niveau de la [edit interface aex unit y family inet6] hiérarchie.

    À partir de la version 16.1R2, Junos OS vérifie et valide le micro BFD local-address configuré par rapport à l’interface ou à l’adresse IP de bouclage avant la validation de la configuration. Junos OS effectue cette vérification sur les configurations d’adresses micro BFD IPv4 et IPv6, et si elles ne correspondent pas, la validation échoue. Le micro-BFD local-address configuré doit correspondre au micro-BFD neighbour-address configuré sur le routeur homologue.

  6. Spécifiez l’intervalle minimum qui indique l’intervalle de temps pour la transmission et la réception des données.

    Cette valeur représente l’intervalle minimal auquel le périphérique de routage local transmet les paquets BFD, ainsi que l’intervalle minimum dans lequel le périphérique de routage s’attend à recevoir une réponse d’un voisin avec lequel il a établi une session BFD. Vous pouvez configurer un nombre compris entre 1 et 255 000 millisecondes. Vous pouvez également spécifier séparément les intervalles minimum d’émission et de réception.

    Pour spécifier les intervalles d’émission et de réception minimaux pour la détection des défaillances, incluez l’instruction minimum-interval suivante :

    Note:

    BFD est un protocole intensif qui consomme des ressources système. La spécification d’un intervalle minimal pour BFD inférieur à 100 ms pour les sessions basées sur le moteur de routage et à 10 ms pour les sessions BFD distribuées peut entraîner des battements intempestifs de BFD.

    En fonction de votre environnement réseau, les recommandations supplémentaires suivantes peuvent s’appliquer :

    • Pour les déploiements réseau à grande échelle avec un grand nombre de sessions BFD, spécifiez un intervalle minimal de 300 ms pour les sessions basées sur le moteur de routage et de 100 ms pour les sessions BFD distribuées.

    • Pour les déploiements réseau à très grande échelle avec un grand nombre de sessions BFD, contactez le support client Juniper Networks pour plus d’informations.

    • Pour que les sessions BFD restent actives pendant un événement de basculement du moteur de routage lorsque le routage actif ininterrompu est configuré, spécifiez un intervalle minimal de 2500 ms pour les sessions basées sur le moteur de routage. Pour les sessions BFD distribuées sur lesquelles un routage actif ininterrompu est configuré, les recommandations relatives à l’intervalle minimal restent inchangées et dépendent uniquement du déploiement de votre réseau.

  7. Spécifiez uniquement l’intervalle de réception minimal pour la détection des défaillances en incluant l’instruction minimum-receive-interval :

    Cette valeur représente l’intervalle minimal pendant lequel le périphérique de routage local s’attend à recevoir une réponse d’un voisin avec lequel il a établi une session BFD. Vous pouvez configurer un nombre compris entre 1 et 255 000 millisecondes.

  8. Spécifiez le nombre de paquets BFD qui n’ont pas été reçus par le voisin qui provoque la déclaration d’arrêt de l’interface d’origine en incluant l’instruction multiplier :

    La valeur par défaut est 3. Vous pouvez configurer un nombre compris entre 1 et 255.

  9. Configurez le voisin dans une session BFD.

    L’adresse voisine peut être une adresse IPv4 ou IPv6.

    Pour spécifier le tronçon suivant de la session BFD, incluez l’instruction neighbor suivante :

    L’adresse voisine BFD est l’adresse de bouclage de la destination distante de la session BFD.

    Note:

    À partir de Junos OS version 16.1, vous pouvez également configurer l’adresse d’interface AE de la destination distante en tant qu’adresse voisine BFD dans une session micro BFD.

  10. (Facultatif) Configurez les sessions BFD pour qu’elles ne s’adaptent pas à l’évolution des conditions du réseau.

    Pour désactiver l’adaptation BFD, incluez l’instruction no-adaptation suivante :

    Note:

    Nous vous recommandons de ne pas désactiver l’adaptation BFD, sauf s’il est préférable de ne pas l’avoir dans votre réseau.

  11. Spécifiez un seuil de détection de l’adaptation du temps de détection en incluant l’instruction threshold :

    Lorsque le temps de détection de la session BFD s’adapte à une valeur égale ou supérieure au seuil, une interruption unique et un message de journal système sont envoyés. Le temps de détection est basé sur le multiplicateur de la valeur de l’intervalle minimum ou de l’intervalle minimum de réception. Le seuil doit être une valeur supérieure au multiplicateur pour l’une ou l’autre de ces valeurs configurées. Par exemple, si l’intervalle de réception minimum est de 300 ms et que le multiplicateur est de 3, le temps total de détection est de 900 ms. Par conséquent, le seuil de temps de détection doit avoir une valeur supérieure à 900.

  12. Spécifiez uniquement l’intervalle de transmission minimal pour la détection des défaillances en incluant l’instruction transmit-interval minimum-interval suivante :

    Cette valeur représente l’intervalle minimal auquel le périphérique de routage local transmet les paquets BFD au voisin avec lequel il a établi une session BFD. Vous pouvez configurer une valeur comprise entre 1 et 255 000 millisecondes.

  13. Spécifiez le seuil d’émission pour détecter l’adaptation de l’intervalle d’émission en incluant l’instruction transmit-interval threshold suivante :

    La valeur seuil doit être supérieure à l’intervalle de transmission. Lorsque le temps de détection de la session BFD s’adapte à une valeur supérieure au seuil, une interruption unique et un message de journal système sont envoyés. Le temps de détection est basé sur le multiplicateur de la valeur de l’intervalle minimum ou de l’intervalle minimum de réception. Le seuil doit être une valeur supérieure au multiplicateur pour l’une ou l’autre de ces valeurs configurées.

  14. Spécifiez la version BFD en incluant l’instruction version :

    Par défaut, la version est détectée automatiquement.

Note:
  • L’option version n’est pas prise en charge sur le QFX Series. À partir de Junos OS version 17.2R1, un avertissement s’affiche si vous tentez d’utiliser cette commande.

  • Cette fonctionnalité fonctionne lorsque les deux appareils prennent en charge BFD. Si BFD n’est configuré qu’à une extrémité du LAG, cette fonctionnalité ne fonctionne pas.

Présentation de l’algorithme de hachage du bundle LAG et de la sortie du trafic ECMP de saut suivant

Juniper Networks EX Series et QFX Series utiliser un algorithme de hachage pour déterminer comment transférer le trafic sur un bundle de LAG (Link Aggregation Group) ou vers le périphérique de saut suivant lorsque le chemin d’accès multichemin à coût égal (ECMP) est activé.

L’algorithme de hachage prend des décisions de hachage en fonction des valeurs de divers champs de paquets, ainsi que de certaines valeurs internes telles que l’ID du port source et l’ID de l’appareil source. Vous pouvez configurer certains des champs utilisés par l’algorithme de hachage.

Note:

La prise en charge de la plate-forme dépend de la version de Junos OS dans votre installation.

Cette rubrique contient les sections suivantes :

Comprendre l’algorithme de hachage

L’algorithme de hachage permet de prendre des décisions de transfert de trafic pour le trafic entrant dans un bundle LAG ou pour le trafic sortant d’un commutateur lorsque ECMP est activé.

Pour les bundles LAG, l’algorithme de hachage détermine la manière dont le trafic entrant dans un bundle LAG est placé sur les liens membres du bundle. L’algorithme de hachage tente de gérer la bande passante en équilibrant uniformément la charge de tout le trafic entrant sur les liens membres du bundle.

Pour ECMP, l’algorithme de hachage détermine la manière dont le trafic entrant est transféré vers l’appareil de saut suivant.

L’algorithme de hachage prend des décisions de hachage en fonction des valeurs de divers champs de paquets, ainsi que de certaines valeurs internes telles que l’ID du port source et l’ID de l’appareil source. Les champs de paquet utilisés par l’algorithme de hachage varient en fonction de l’EtherType du paquet et, dans certains cas, de la configuration du commutateur. L’algorithme de hachage reconnaît les EtherTypes suivants :

  • IP (IPv4 et IPv6)

  • MPLS

  • MAC-dans-MAC

Le trafic qui n’est reconnu comme appartenant à aucun de ces EtherTypes est haché en fonction de l’en-tête de couche 2. Le trafic IP et MPLS est également haché en fonction de l’en-tête de couche 2 lorsqu’un utilisateur configure le mode de hachage en tant qu’en-tête de couche 2.

Vous pouvez configurer certains champs utilisés par l’algorithme de hachage pour prendre des décisions de transfert de trafic. Cependant, vous ne pouvez pas configurer la façon dont certaines valeurs d’un en-tête sont utilisées par l’algorithme de hachage.

Notez les points suivants concernant l’algorithme de hachage :

  • Les champs sélectionnés pour le hachage sont basés uniquement sur le type de paquet. Les champs ne sont pas basés sur d’autres paramètres, y compris la décision de transfert (ponté ou routé) ou la configuration du bundle LAG de sortie (couche 2 ou couche 3).

  • Les mêmes champs sont utilisés pour le hachage des paquets unicast et multicast. Les paquets unicast et multicast sont cependant hachés différemment.

  • Les mêmes champs sont utilisés par l’algorithme de hachage pour hacher le trafic ECMP et LAG, mais l’algorithme de hachage hache le trafic ECMP et LAG différemment. Le trafic LAG utilise un hachage de jonction, tandis qu’ECMP utilise le hachage ECMP. LAG et ECMP utilisent tous deux la même graine RTAG7, mais utilisent des décalages différents de cette graine 128B pour éviter la polarisation. La configuration initiale de la fonction HASH pour utiliser le trunk et le décalage ECMP sont définis au moment de l’initialisation PFE. Les différents hachages garantissent que le trafic n’est pas polarisé lorsqu’un bundle LAG fait partie du chemin de saut suivant ECMP.

  • Les mêmes champs sont utilisés pour le hachage, que le commutateur participe ou non à un Virtual Chassis ou un Virtual Chassis Fabric (VCF) mixte ou non.

Les champs utilisés pour le hachage par chaque EtherType ainsi que les champs utilisés par l’en-tête de couche 2 sont abordés dans les sections suivantes.

IP (IPv4 et IPv6)

Les champs de charge utile dans les paquets IPv4 et IPv6 sont utilisés par l’algorithme de hachage lorsque des paquets IPv4 ou IPv6 doivent être placés sur un lien membre d’un bundle LAG ou envoyés au périphérique de saut suivant lorsque ECMP est activé.

Par défaut, le mode de hachage est défini sur le champ de charge utile de couche 2. Les champs de charge utile IPv4 et IPv6 sont utilisés pour le hachage lorsque le mode de hachage est défini sur Charge utile de couche 2.

Si le mode de hachage est configuré sur l’en-tête de couche 2, les paquets IPv4, IPv6 et MPLS sont hachés à l’aide des champs d’en-tête de couche 2. Si vous souhaitez que les paquets entrants IPv4, IPv6 et MPLS soient hachés par l’adresse MAC source, l’adresse MAC de destination ou les champs EtherType, vous devez définir le mode de hachage sur En-tête de couche 2.

Le Tableau 5 affiche les champs de charge utile IPv4 et IPv6 qui sont utilisés par défaut par l’algorithme de hachage.

  • ✓ : le champ est utilisé par défaut par l’algorithme de hachage.

  • Χ : le champ n’est pas utilisé par l’algorithme de hachage, par défaut.

  • (configurable) : le champ peut être configuré pour être utilisé ou non utilisé par l’algorithme de hachage.

Sur les commutateurs EX2300, les champs de charge utile suivants dans les paquets IPv4 et IPv6 sont utilisés par l’algorithme de hachage lorsque des paquets IPv4 ou IPv6 doivent être placés sur une liaison membre dans un bundle LAG ou envoyés au périphérique de saut suivant lorsque ECMP est activé :

  • Pour le trafic unicast sur LAG : SIP, DIP, L4SP, L4DP

  • Pour le trafic multicast connu sur LAG : IP source, IP de destination, ID de mod d’entrée et ID de port d’entrée

  • Pour le trafic de diffusion, unicast inconnu et multicast inconnu sur LAG : MAC source, MAC de destination, ID de mod d’entrée et ID de port d’entrée

  • Équilibrage de charge ECMP : adresse IP de destination, port source de couche 4 et port de destination de couche 4

Tableau 5 : champs de hachage IPv4 et IPv6

Fields

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

 

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

Source MAC

X

Χ

X

Χ

Χ

Χ

Χ

Χ

Χ

X

Destination MAC

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Type d’éther

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

VLAN ID

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

IP source ou IPv6

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

IP ou IPv6 de destination

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Protocole (IPv4 uniquement)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

En-tête suivant (IPv6 uniquement)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Port source de couche 4

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Port de destination de couche 4

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Étiquette de flux IPv6 (IPv6 uniquement)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

ID de mod d’entrée

(configurable)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

ID de port entrant

(configurable)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

MPLS

L’algorithme de hachage hache les paquets MPLS à l’aide des champs IP source, IP de destination, MPLS label 0, MPLS label 1, MPLS label 2 et MPLS 3. Sur les commutateurs QFX5110, QFX5120 et QFX5200, les routeurs LSR prennent également en charge ECMP. ECMP utilise les champs suivants pour le hachage sur un routeur LSR :

  • VPN de couche 3 : étiquettes MPLS (3 premières étiquettes), adresse IP source, adresse IP de destination et ID de port entrant

  • Circuit de couche 2 : étiquettes MPLS (3 premières étiquettes) et ID de port d’entrée

Le Tableau 6 affiche les champs de charge utile MPLS utilisés par l’algorithme de hachage, par défaut :

  • ✓ : le champ est utilisé par défaut par l’algorithme de hachage.

  • Χ : le champ n’est pas utilisé par l’algorithme de hachage, par défaut.

Les champs utilisés par l’algorithme de hachage pour le hachage de paquets MPLS ne sont pas configurables par l’utilisateur.

Les champs IP source et IP de destination ne sont pas toujours utilisés pour le hachage. Pour les paquets MPLS non terminés, la charge utile est vérifiée si l’indicateur BoS (bottom of stack) est visible dans le paquet. Si la charge utile est IPv4 ou IPv6, les champs Adresse IP source et Adresse IP de destination sont utilisés pour le hachage avec les étiquettes MPLS. Si l’indicateur BoS n’est pas visible dans le paquet, seules les étiquettes MPLS sont utilisées pour le hachage.

Tableau 6 : champs de hachage MPLS

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

Source MAC

Χ

Χ

Χ

Χ

Χ

Destination MAC

Χ

Χ

Χ

Χ

Χ

Type d’éther

Χ

Χ

Χ

Χ

Χ

VLAN ID

Χ

Χ

Χ

Χ

Χ

Source IP

Destination IP

Protocole (pour les paquets IPv4)

Χ

Χ

Χ

Χ

Χ

En-tête suivant (pour les paquets IPv6)

Χ

Χ

Χ

Χ

Χ

Port source de couche 4

Χ

Χ

Χ

Χ

Χ

Port de destination de couche 4

Χ

Χ

Χ

Χ

Χ

Laboratoire de flux IPv6

Χ

Χ

Χ

Χ

Χ

Étiquette MPLS 0

Χ

Étiquette MPLS 1

Étiquette MPLS 2

Étiquette MPLS 3

X

X

X

X

ID de port entrant

(LSR et L2Circuit)

X

X

X

(LSR et L2Circuit)

(LSR et L2Circuit)

Hachage de paquets MAC-in-MAC

Les paquets utilisant l’EtherType MAC-in-MAC sont hachés par l’algorithme de hachage à l’aide des champs MAC source de la charge utile de couche 2, MAC de destination de la charge utile de couche 2 et EtherType de la charge utile de couche 2. Voir tableau 7.

Le hachage à l’aide des champs du paquet EtherType MAC-in-MAC est pris en charge pour la première fois sur les commutateurs EX4300 dans la version 13.2X51-D20. Le hachage à l’aide des champs de l’EtherType MAC-in-MAC n’est pas pris en charge sur les versions antérieures.

Les champs utilisés par l’algorithme de hachage pour le hachage MAC-in-MAC ne sont pas configurables par l’utilisateur.

  • ✓ : le champ est utilisé par défaut par l’algorithme de hachage.

  • Χ : le champ n’est pas utilisé par l’algorithme de hachage, par défaut.

Tableau 7 : Champs de hachage MAC-in-MAC

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

Charge utile MAC source de couche 2

MAC de destination de la charge utile de couche 2

Charge utile de couche 2 EtherType

VLAN externe de charge utile de couche 2

Χ

Χ

Χ

Χ

Hachage d’en-tête de couche 2

Les champs d’en-tête de couche 2 sont utilisés par l’algorithme de hachage lorsque l’EtherType d’un paquet n’est pas reconnu comme IP (IPv4 ou IPv6), MPLS ou MAC-in-MAC. Les champs d’en-tête de couche 2 sont également utilisés pour le hachage du trafic IPv4, IPv6 et MPLS à la place des champs de charge utile lorsque le mode de hachage est défini sur l’en-tête de couche 2.

  • ✓ : le champ est utilisé par défaut par l’algorithme de hachage.

  • Χ : le champ n’est pas utilisé par l’algorithme de hachage, par défaut.

  • (configurable) : le champ peut être configuré pour être utilisé ou non utilisé par l’algorithme de hachage.

Tableau 8 : Champs de hachage d’en-tête de couche 2

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

Source MAC

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Destination MAC

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Type d’éther

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

VLAN ID

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

(configurable)

(configurable)

Paramètres de hachage

À partir de Junos OS version 19.1R1, sur la QFX5000 gamme de commutateurs, vous pouvez modifier les paramètres de hachage pour les algorithmes existants implémentés. Vous pouvez modifier le seuil des pools de mémoires tampons partagées pour les partitions de mémoire tampon d’entrée et de sortie, et vous pouvez apporter des modifications à la sélection de la fonction de hachage, à l’algorithme de hachage et à d’autres paramètres supplémentaires. Reportez-vous à la section Configuration d’autres paramètres de hachage plus loin dans ce document.

Configuration des champs de l’algorithme de hachage du bundle LAG et du trafic ECMP (procédure CLI)

Les commutateurs Juniper Networks EX Series et QFX Series utilisent un algorithme de hachage pour déterminer comment transférer le trafic sur un bundle de groupes d’agrégation de liens (LAG) ou vers le périphérique de saut suivant lorsque le chemin d’accès multichemin à coût égal (ECMP) est activé.

L’algorithme de hachage prend des décisions de hachage en fonction des valeurs de divers champs de paquets. Vous pouvez configurer certains des champs utilisés par l’algorithme de hachage.

La configuration des champs utilisés par l’algorithme de hachage est utile dans les scénarios où la majeure partie du trafic entrant dans le bundle est similaire et que le trafic doit être géré dans le bundle LAG. Par exemple, si la seule différence entre les paquets IP pour l’ensemble du trafic entrant est l’adresse IP source et l’adresse IP de destination, vous pouvez régler l’algorithme de hachage pour prendre des décisions de hachage plus efficacement en configurant l’algorithme pour qu’il prenne des décisions de hachage en utilisant uniquement ces champs.

Note:

La configuration du mode de hachage n’est pas prise en charge sur les commutateurs QFX10002 et QFX10008.

Configuration de l’algorithme de hachage pour utiliser les champs de l’en-tête de couche 2 pour le hachage

Pour configurer l’algorithme de hachage afin d’utiliser les champs de l’en-tête de couche 2 pour le hachage :

  1. Configurez le mode de hachage sur l’en-tête de couche 2 :

    Le mode de hachage par défaut est la charge utile de couche 2. Par conséquent, cette étape doit être effectuée si vous n’avez pas préalablement configuré le mode de hachage.

  2. Configurez les champs de l’en-tête de couche 2 que l’algorithme de hachage utilise pour le hachage :

    Par défaut, l’algorithme de hachage utilise les valeurs des champs adresse MAC de destination, Ethertype et adresse MAC source de l’en-tête pour hacher le trafic sur le LAG. Vous pouvez configurer l’algorithme de hachage pour qu’il n’utilise pas les valeurs de ces champs en configurant no-destination-mac-address, no-ether-typeou no-source-mac-address.

    Vous pouvez également configurer l’algorithme de hachage pour inclure le champ ID VLAN dans l’en-tête en configurant l’option vlan-id .

    Si vous souhaitez que l’algorithme de hachage n’utilise pas le champ Ethertype pour le hachage :

Configuration de l’algorithme de hachage pour utiliser les champs de la charge utile IP pour le hachage

Pour configurer l’algorithme de hachage afin d’utiliser les champs de la charge utile IP pour le hachage :

  1. Configurez le mode de hachage sur la charge utile de couche 2 :

    La charge utile IP n’est pas vérifiée par l’algorithme de hachage, sauf si le mode de hachage est défini sur Charge utile de couche 2. Le mode de hachage par défaut est la charge utile de couche 2.

  2. Configurez les champs de la charge utile IP que l’algorithme de hachage utilise pour le hachage :

    Par exemple, si vous souhaitez que l’algorithme de hachage ignore le port de destination de la couche 4, le port source de la couche 4 et les champs de protocole, et qu’il hache le trafic en se basant uniquement sur les adresses source et de destination IPv4 :

Configuration de l’algorithme de hachage pour l’utilisation des champs de la charge utile IPv6 pour le hachage

Pour configurer l’algorithme de hachage afin d’utiliser les champs de la charge utile IPv6 pour le hachage :

  1. Configurez le mode de hachage sur la charge utile de couche 2 :

    La charge utile IPv6 n’est pas vérifiée par l’algorithme de hachage, sauf si le mode de hachage est défini sur Charge utile de couche 2. Le mode de hachage par défaut est la charge utile de couche 2.

  2. Configurez les champs de la charge utile IPv6 que l’algorithme de hachage utilise pour le hachage :

    Par exemple, si vous souhaitez que l’algorithme de hachage ignore le port de destination de couche 4, le port source de couche 4 et les champs d’en-tête suivant, et qu’à la place, il hache le trafic en se basant uniquement sur les champs d’adresse source IPv6 et de destination IPv6 uniquement :

Configuration d’autres paramètres de hachage

Pour configurer les paramètres de hachage pour le trafic ECMP ou LAG :

  1. Configurez le paramètre preprocess :
  2. Configurez le paramètre de fonction :
  3. Configurez la valeur de décalage :

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Description
19.3
À partir de Junos OS version 19.3 et ultérieure, vous ne pouvez pas appliquer de filtres de pare-feu aux paquets MicroBFD reçus sur l’interface Ethernet agrégée pour les MPC10E et MPC11E. Pour MPC1E à MPC9E, vous pouvez appliquer des filtres de pare-feu sur les paquets MicroBFD reçus sur l’interface Ethernet agrégée uniquement si l’interface Ethernet agrégée est configurée en tant qu’interface non balisée.
19.1R1
Sur la QFX5000 gamme de commutateurs, vous pouvez modifier les paramètres de hachage pour les algorithmes existants implémentés.
16.1
À partir de Junos OS version 16.1, vous pouvez également configurer cette fonctionnalité sur les routeurs MX Series avec l’adresse d’interface Ethernet agrégée de la destination distante comme adresse voisine.
16.1
À partir de la version 16.1R2, Junos OS vérifie et valide le micro BFD local-address configuré par rapport à l’interface ou à l’adresse IP de bouclage avant la validation de la configuration.
14.1X53-D25
À partir de Junos OS version 14.1X53-D25, la polarisation des liens locaux peut être activée globalement pour tous les bundles LAG dans un Virtual Chassis ou VCF, ou individuellement par bundle LAG dans un Virtual Chassis.
14.1
À partir de Junos OS version 14.1, spécifiez le voisin dans une session BFD. Dans les versions antérieures à Junos OS version 16.1, vous devez configurer l’adresse de bouclage de la destination distante en tant qu’adresse voisine.
13.3
Depuis Junos OS version 13.3, l’IANA a attribué 01-00-5E-90-00-01 comme adresse MAC dédiée pour micro BFD.