Concepts MC-LAG avancés

Avantages de la synchronisation de la configuration

La synchronisation des configurations vous permet de propager, synchroniser et valider les configurations d’un équipement à un autre. Vous pouvez vous connecter à n’importe lequel de ces équipements pour gérer tous les appareils, disposant ainsi d’un point de gestion unique.

Fonctionnement de la synchronisation de la configuration

Utilisez des groupes de configuration pour simplifier le processus de configuration. Par exemple, vous pouvez créer un groupe de configuration pour l’équipement local, un ou plusieurs pour les périphériques distants et un pour la configuration globale, qui est essentiellement une configuration commune à tous les périphériques.

En outre, vous pouvez créer des groupes conditionnels pour spécifier quand une configuration est synchronisée avec un autre appareil. Vous pouvez activer l’instruction peers-synchronize au niveau de la [edit system commit] hiérarchie pour synchroniser les configurations et les validations sur les périphériques par défaut. NETCONF sur SSH fournit une connexion sécurisée entre les périphériques, et le protocole SCP (Secure Copy Protocol) copie les configurations en toute sécurité entre eux.

Comment activer la synchronisation de la configuration

Pour activer la synchronisation de la configuration, effectuez les opérations suivantes :

1. Mappez statiquement l’équipement local aux équipements distants.

2. Créez des groupes de configuration pour les configurations locales, distantes et globales.

3. Créez des groupes conditionnels.

4. Créez des groupes d’application.

5. Activez NETCONF sur SSH.

6. Configurez les détails de l’appareil et les détails d’authentification de l’utilisateur pour la synchronisation de la configuration.

7. Activez l’instruction peers-synchronize ou émettez la commit peers-synchronize commande pour synchroniser et valider les configurations entre les périphériques locaux et distants.

Prise en charge de la synchronisation de la configuration

Sur les routeurs MX Series et Junos Fusion, la prise en charge de la synchronisation de la configuration a commencé avec Junos OS version 14.2R6. Sur les commutateurs QFX Series, la prise en charge de la synchronisation de la configuration a commencé avec Junos OS version 15.1X53-D60.

Groupes de configuration pour les configurations locales, distantes et globales

Vous pouvez créer des groupes de configuration pour les configurations locales, distantes et globales. Un groupe de configuration local est utilisé par l’équipement local, un groupe de configuration distant est utilisé par l’équipement distant et un groupe de configuration global est partagé entre les équipements locaux et distants.

Par exemple, vous pouvez créer un groupe de configuration local appelé Groupe A, qui inclut la configuration utilisée par le périphérique local (commutateur A), un groupe de configuration distant appelé Groupe B, qui inclut la configuration utilisée par les périphériques distants (Commutateur B, Commutateur C et Commutateur D) et un groupe de configuration globale appelé Groupe C, qui inclut la configuration commune à tous les périphériques.

Créez des groupes de configuration au niveau hiérarchique [edit groups] .

Création de groupes conditionnels pour certains appareils

Vous pouvez créer des groupes conditionnels pour spécifier quand une configuration particulière doit être appliquée à un appareil. Si vous souhaitez appliquer la configuration globale à tous les appareils d’une configuration à quatre appareils, par exemple, activez l’instruction when peers [<name of local peer> <name of remote peer> <name of remote peer> <name of remote peer>] au niveau de la [edit groups] hiérarchie. Si, par exemple, vous souhaitez appliquer la configuration globale (groupe C) aux périphériques locaux et distants (commutateur A, commutateur B, commutateur C et commutateur D), vous pouvez exécuter la set groups Group C when peers [Switch A Switch B Switch C Switch D] commande.

Application de groupes de configuration

Pour appliquer des groupes de configuration, activez l’instruction apply-groups au niveau de la [edit] hiérarchie. Par exemple, pour appliquer le groupe de configuration local (groupe A, par exemple), le groupe de configuration distante (groupe B, par exemple) et le groupe de configuration globale (groupe C, par exemple), exécutez la set apply-groups [ GroupA GroupB GroupC ] commande.

Détails de configuration de l’appareil pour la synchronisation de la configuration

Pour synchroniser les configurations entre les périphériques, vous devez configurer le nom d’hôte ou l’adresse IP, le nom d’utilisateur et le mot de passe des périphériques distants. Pour ce faire, exécutez la set peers <hostname-of-remote-peer> user <name-of-user> authentication <plain-text-password-string> commande au niveau de la [edit system commit] hiérarchie sur l’appareil local.

Par exemple, pour synchroniser une configuration du commutateur A vers le commutateur B, exécutez la commande sur le set peers SwitchB user administrator authentication test123 commutateur A.

Vous devez également mapper statiquement l’appareil local aux périphériques distants. Pour cela, émettez la commande set system commit peers

Par exemple, pour synchroniser une configuration du commutateur A vers le commutateur B, le commutateur C et le commutateur D, configurez les éléments suivants sur le commutateur A :

Commutateur A

Si vous souhaitez uniquement synchroniser les configurations du commutateur A vers le commutateur B, le commutateur C et le commutateur D, vous n’avez pas besoin de configurer l’instruction sur le commutateur B, le commutateur C et le peers commutateur D.

Les détails de configuration des instructions peers sont également utilisés pour établir une connexion NETCONF sur SSH entre les périphériques. Pour activer NETCONF sur SSH, exécutez la set system services netconf ssh commande sur tous les périphériques.

Synchronisation des configurations et des validations entre les équipements

Le périphérique local (ou demandeur) sur lequel vous activez l’instruction peers-synchronize ou émettez la commit peers-synchronize commande copie et charge sa configuration sur le périphérique distant (ou répondant). Chaque périphérique effectue ensuite une vérification de la syntaxe du fichier de configuration en cours de validation. Si aucune erreur n’est détectée, la configuration est activée et devient la configuration opérationnelle actuelle sur tous les appareils. Les commits sont propagés à l’aide d’un appel de procédure à distance (RPC).

Les événements suivants se produisent lors de la synchronisation de la configuration :

1. L’appareil local envoie le fichier sync-peers.conf (la configuration qui sera partagée avec les appareils spécifiés dans le groupe conditionnel) aux appareils distants.

2. Les périphériques distants chargent la configuration, envoient les résultats du chargement à l’équipement local, exportent leur configuration vers l’équipement local et répondent que la validation est terminée.

3. L’appareil local lit les réponses des appareils distants.

4. En cas de succès, la configuration est validée.

La synchronisation de la configuration échoue si a) l’équipement distant n’est pas disponible ou b) si l’équipement distant est accessible, mais que des échecs sont dus aux raisons suivantes :

• La connexion SSH échoue en raison de problèmes d’utilisateur et d’authentification.

• Le RPC de Junos OS échoue car aucun verrou ne peut être obtenu sur la base de données distante.

• Le chargement de la configuration échoue en raison de problèmes de syntaxe.

• Echec de la vérification de validation.

L’instruction peers-synchronize utilise le nom d’hôte ou l’adresse IP, le nom d’utilisateur et le mot de passe des périphériques que vous avez configurés dans l’instruction peers . Lorsque l’instruction peers-synchronize est activée, il vous suffit d’exécuter la commit commande pour synchroniser la configuration d’un périphérique à un autre. Par exemple, si vous avez configuré l’instruction peers sur le périphérique local et que vous souhaitez synchroniser la configuration avec le périphérique distant, vous pouvez simplement exécuter la commit commande sur le périphérique local. Toutefois, si vous exécutez la commit commande sur le périphérique local et que le périphérique distant n’est pas accessible, vous recevrez un message d’avertissement indiquant que le périphérique distant n’est pas accessible et que seule la configuration sur le périphérique local est validée :

Voici un exemple de message d’avertissement :

Si l’instruction peers n’est pas configurée avec les informations sur l’équipement distant et que vous exécutez la commit commande, seule la configuration sur l’équipement local est validée. Si le périphérique distant est inaccessible et qu’il y a d’autres échecs, la validation échoue sur les périphériques locaux et distants.

La commit peers-synchronize commande utilise également le nom d’hôte ou l’adresse IP, le nom d’utilisateur et le mot de passe des périphériques configurés dans l’instruction peers . Si vous exécutez la commit peers-synchronize commande sur le périphérique local pour synchroniser la configuration avec le périphérique distant et que le périphérique distant est accessible mais qu’il existe d’autres échecs, la validation échoue à la fois sur les périphériques locaux et distants.

Avantages de la vérification de cohérence MC-LAG

• Cette fonctionnalité vous aide à détecter les incohérences de paramètres de configuration entre les homologues MC-LAG (MultiChassis Link Aggregation Group).

Fonctionnement des vérifications de cohérence MC-LAG

Les événements suivants se produisent lors de la vérification de la cohérence de la configuration après l’émission d’une validation sur l’homologue MC-LAG local :

1. Validez une configuration MC-LAG sur l’homologue MC-LAG local.

2. ICCP analyse la configuration MC-LAG, puis l’envoie à l’homologue MC-LAG distant.

3. L’homologue MC-LAG distant reçoit la configuration MC-LAG de l’homologue MC-LAG local et la compare à sa propre configuration MC-LAG.

   S’il y a une incohérence importante entre les deux configurations MC-LAG, l’interface MC-LAG est arrêtée et des messages syslog sont émis.

   S’il y a une incohérence modérée entre les deux configurations, des messages syslog sont émis.

Les événements suivants se produisent lors de la vérification de cohérence de la configuration après l’émission d’une validation sur l’homologue MC-LAG distant :

• Validez une configuration MC-LAG sur l’homologue MC-LAG distant.

• ICCP analyse la configuration MC-LAG, puis l’envoie à l’homologue MC-LAG local.

• L’homologue MC-LAG local reçoit la configuration de l’homologue MC-LAG distant et la compare à sa propre configuration.

  S’il y a une incohérence importante entre les deux configurations, l’interface MC-LAG est arrêtée et des messages syslog sont émis.

  S’il y a une incohérence modérée entre les deux configurations, des messages syslog sont émis.

Exigences de cohérence de la configuration

Les exigences de cohérence de la configuration varient en fonction des paramètres MC-LAG. Les exigences de cohérence sont identiques ou uniques, ce qui signifie que certains paramètres doivent être configurés de manière identique et d’autres doivent l’être de manière unique sur les homologues MC-LAG. Par exemple, l’ID de châssis doit être unique sur les deux homologues, tandis que le mode LACP doit être identique sur les deux homologues.

Le niveau d’application des exigences de cohérence (identique ou unique) est soit obligatoire, soit souhaité. Lorsque le niveau d’application est obligatoire et que vous ne configurez pas correctement le paramètre MC-LAG, le système arrête l’interface et émet un message syslog.

Par exemple, vous recevez un message syslog qui dit : “Some of the Multichassis Link Aggregation (MC-LAG) configuration parameters between the peer devices are not consistent. The concerned MC-LAG interfaces were explictly brought down to prevent unwanted behavior.” Lorsque vous corrigez l’incohérence et que vous effectuez un commit réussi, le système affichera l’interface. Lorsque l’application est souhaitée et que vous configurez le paramètre MC-LAG de manière incorrecte, vous recevez un message syslog qui dit : "Some of the Multichassis Link Aggregation(MC-LAG) configuration parameters between the peer devices are not consistent. This may lead to sub-optimal performance of the feature." Comme indiqué dans le message syslog, les performances seront sous-optimales dans cette situation. Vous pouvez également exécuter la commande show interfaces mc-ae pour afficher l’état de vérification de cohérence de la configuration de l’interface Ethernet agrégée multichâssis.

S’il y a plusieurs incohérences, seule la première incohérence est affichée. Si le niveau d’application d’un paramètre MC-LAG est obligatoire et que vous n’avez pas configuré ce paramètre correctement, la commande indique que l’interface MC-LAG est inactive.

Lorsque les pairs distants ne sont pas joignables

Lorsque vous émettez un commit sur l’homologue local et que l’homologue distant n’est pas accessible, la vérification de cohérence de la configuration passe afin que l’homologue local puisse apparaître en mode autonome. Lorsque l’homologue distant se présente, ICCP échange les configurations entre les pairs. Si la vérification de cohérence échoue, l’interface MC-LAG tombe en panne et le système vous informe du paramètre à l’origine de l’incohérence. Lorsque vous corrigez l’incohérence et que vous effectuez un commit réussi, le système fait apparaître l’interface.

Activation de la vérification de la cohérence de la configuration MC-LAG

Le contrôle de cohérence est activé par défaut. Le Tableau 1 fournit un exemple de liste de paramètres MC-LAG validés dont la cohérence est vérifiée, ainsi que leurs exigences de cohérence (identiques ou uniques), les hiérarchies dans lesquelles les paramètres sont configurés et les niveaux d’application de la vérification de cohérence (obligatoires ou souhaités).

Connaître l’état d’un contrôle de cohérence de configuration

Les commandes suivantes fournissent des informations sur l’état de la vérification de cohérence de la configuration :

• Exécutez la commande show multi-chassis mc-lag configuration-consistency list-of-parameters pour afficher la liste des paramètres MC-LAG validés qui sont vérifiés pour détecter les incohérences, l’exigence de cohérence (identique ou unique) et le niveau d’application (obligatoire ou souhaité).

• Exécutez la commande show multi-chassis mc-lag configuration-consistency pour afficher la liste des paramètres MC-LAG validés qui sont vérifiés pour détecter les incohérences, l’exigence de cohérence (identique ou unique), le niveau d’application (obligatoire ou souhaité) et le résultat de la vérification de cohérence de la configuration. Les résultats sont soit la réussite, soit l’échec.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency global-config pour afficher l’état de la vérification de la cohérence de la configuration pour toute la configuration globale liée à la fonctionnalité MC-LAG, l’exigence de cohérence (identique ou unique), le niveau d’application (obligatoire ou souhaité) et le résultat de la vérification de la cohérence de la configuration. Les résultats sont soit la réussite, soit l’échec.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency icl-config pour afficher l’état de la vérification de la cohérence de la configuration pour les paramètres liés à la liaison de contrôle interchâssis, l’exigence de cohérence (identique ou unique), le niveau d’application (obligatoire ou souhaité) et le résultat de la vérification de la cohérence de la configuration. Les résultats sont soit la réussite, soit l’échec.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency mcae-config pour afficher l’état de la vérification de la cohérence de la configuration des paramètres liés à l’interface Ethernet agrégée multichâssis, l’exigence de cohérence (identique ou unique), le niveau d’application (obligatoire ou souhaité) et le résultat de la vérification de la cohérence de la configuration. Les résultats sont soit la réussite, soit l’échec.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency vlan-config pour afficher l’état de la vérification de la cohérence de la configuration pour les paramètres liés à la configuration VLAN, l’exigence de cohérence (identique ou unique), le niveau d’application (obligatoire ou souhaité) et le résultat de la vérification de la cohérence de la configuration. Les résultats sont soit la réussite, soit l’échec.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency vrrp-config pour afficher l’état de vérification de la cohérence de la configuration pour les paramètres liés à la configuration VRRP, l’exigence de cohérence (identique ou unique), le niveau d’application (obligatoire ou souhaité) et le résultat de la vérification de la cohérence de la configuration. Les résultats sont soit la réussite, soit l’échec.

• Exécutez la commande show interfaces mc-ae pour afficher l’état de vérification de la cohérence de la configuration de l’interface Ethernet agrégée multichâssis. S’il y a plusieurs incohérences, seule la première incohérence est affichée. Si le niveau d’application du paramètre MC-LAG est obligatoire et que vous n’avez pas configuré ce paramètre correctement, la commande indique que l’interface MC-LAG est inactive.

Prise en charge de la vérification de cohérence de la configuration MC-LAG

Les commutateurs EX Series et QFX Series prennent en charge la vérification de cohérence de la configuration MC-LAG.

À partir de Junos OS version 15.1X53-D60 sur les commutateurs QFX10000, la vérification de la cohérence de la configuration utilise le protocole ICCP (Inter-Chassis Control Protocol) pour échanger les paramètres de configuration MC-LAG (ID de châssis, ID de service, etc.) et vérifier toute incohérence de configuration entre les homologues MC-LAG.

Fonctionnement PIM avec choix du routeur désigné en mode normal

En mode normal avec sélection de routeur désigné, les interfaces IRB ou RVI sur les deux homologues MC-LAG sont configurées avec PIM activé. Dans ce mode, l’un des homologues MC-LAG devient le routeur désigné par le biais du mécanisme d’élection du routeur désigné PIM. Le routeur désigné élu gère l’arbre des points de rendez-vous (RPT) et l’arbre du chemin le plus court (SPT) afin de pouvoir recevoir des données de l’appareil source. Le routeur désigné choisi participe aux activités périodiques de jointure et d’élagage PIM en direction du point de rendez-vous ou de la source.

L’élément déclencheur de ces activités d’adhésion et d’élagage est constitué par les rapports d’adhésion de l’IGMP reçus des destinataires intéressés. Les rapports IGMP reçus via des interfaces Ethernet agrégées multichâssis (éventuellement un hachage sur l’un ou l’autre des homologues MC-LAG) et des liaisons de résidence unique sont synchronisés avec l’homologue MC-LAG via ICCP.

Les deux homologues MC-LAG reçoivent du trafic sur leur interface entrante (IIF). Le routeur non désigné reçoit le trafic par le biais de l’interface ICL, qui agit comme une interface de routeur multicast (mrouter).

En cas de défaillance du routeur désigné, le routeur non désigné doit construire l’arborescence de transfert complète (RPT et SPT), ce qui peut entraîner une perte de trafic multicast.

Fonctionnement PIM avec mode de routeur à double désignation

En mode de double routeur désigné, les deux homologues MC-LAG agissent en tant que routeurs désignés (actifs et de veille) et envoient périodiquement des messages de jointure et d’élagage en amont vers le point de rendez-vous, ou la source, pour finalement rejoindre le RPT ou le SPT.

L’homologue MC-LAG principal transfère le trafic multicast vers les périphériques récepteurs, même si l’homologue MC-LAG de secours a une métrique de préférence plus petite.

L’homologue MC-LAG de secours rejoint également l’arborescence de transfert et reçoit les données multicast. L’homologue MC-LAG de secours supprime les données, car il dispose d’une liste d’interfaces sortantes (OIL) vide. Lorsque l’homologue MC-LAG de secours détecte la défaillance de l’homologue MC-LAG principal, il ajoute le VLAN récepteur à l’OIL et commence à transférer le trafic multicast.

Pour activer un routeur multicast à double désignation, exécutez la set protocols pim interface interface-name dual-dr commande sur les interfaces VLAN de chaque homologue MC-LAG.

Gestion des défaillances

Pour assurer une convergence plus rapide en cas de défaillance, configurez l’adresse IP sur l’homologue MC-LAG principal avec une adresse IP plus élevée ou avec une priorité de routeur désignée plus élevée. Ainsi, l’homologue MC-LAG principal conserve l’appartenance au routeur désigné en cas de défaillance de l’appairage PIM.

Pour garantir la convergence du trafic en cas de défaillance d’une interface MC-AE, l’interface ICL-PL est toujours ajoutée en tant que port mrouter. Le trafic de couche 3 est inondé via l’entrée par défaut ou l’entrée d’écoute sur l’interface ICL-PL, et le trafic est transféré sur l’interface MC-AE de l’homologue MC-LAG. Si l’interface ICL-PL tombe en panne, le voisinage PIM tombe en panne. Dans ce cas, les deux homologues MC-LAG deviennent le routeur désigné. L’homologue MC-LAG de sauvegarde interrompt ses liaisons et l’appairage de routage est perdu. Si la connexion ICCP tombe en panne, l’homologue MC-LAG de sauvegarde modifie l’ID système LACP et interrompt les interfaces MC-AE. L’état des voisins PIM reste opérationnel.

Surveillance IGMP en mode actif-actif MC-LAG

Le mode actif-actif du groupe d’agrégation de liens multichâssis (MC-LAG) et l’écoute IGMP en mode actif-veille sont pris en charge. MC-LAG permet à un équipement de former une interface LAG logique avec deux périphériques réseau ou plus. MC-LAG offre d’autres avantages, notamment la redondance au niveau des nœuds, le multihébergement et un réseau de couche 2 sans boucle sans exécuter le protocole STP (Spanning Tree Protocol). Les fonctionnalités suivantes sont prises en charge :

• Synchronisation d’état entre homologues pour la surveillance IGMP dans un domaine de pont avec uniquement des interfaces de couche 2

• Apprentissage qualifié

• Liaisons multichâssis côté routeur

Les améliorations suivantes sont prises en charge pour le pontage actif-actif et le protocole VRRP (Virtual Router Redundancy Protocol) sur routage et pontage intégrés (IRB) :

• Prise en charge MC-LAG de la surveillance IGMP dans un commutateur de couche 2 pur

• Prise en charge MC-LAG de l’espionnage IGMP dans les domaines de pont pour un apprentissage qualifié

• Prise en charge des MC-Links en tant qu’interfaces orientées routeur

Les fonctions suivantes sont not prises en charge :

• MC-LAG pour les instances VPLS

• Ports trunk MC-Links

• Mode proxy pour actif-actif

• Ajout de liaisons interchâssis aux interfaces sortantes selon les besoins

  Les liens entre châssis peuvent être ajoutés à la liste des interfaces sortantes en tant qu’interfaces orientées routeur.

Topologie de réseau généralement prise en charge pour la surveillance IGMP avec pontage actif-actif MC-LAG

La Figure 1 illustre une topologie de réseau typique sur laquelle la surveillance IGMP avec pontage actif-actif MC-LAG est prise en charge.

Figure 1 : réseau type sur lequel le mode actif-actif est pris en charge

Les interfaces I3 et I4 sont des interfaces de localisation unique. Les liaisons multichâssis ae0.0 et ae0.1 appartiennent au même domaine de pont dans les deux châssis. Les interfaces I3, ae0.0 et ae0.1 se trouvent dans le même domaine de pont sur le routeur actif secondaire (S-A). Les interfaces I4, ae0.0 et ae0.1 se trouvent dans le même domaine de pont sur le routeur actif principal (P-A). Les interfaces I3, I4, ae0.0 et ae0.1 se trouvent dans le même domaine d’apprentissage que la liaison interchâssis (ICL) reliant les deux châssis.

Le principal routeur actif est le châssis dans lequel le routage et le pontage intégrés sont devenus PIM-DR. Le routeur actif secondaire est le châssis dans lequel le routage et le pontage intégrés ne sont pas PIM-DR. Le routeur P-A est le châssis chargé d’extraire le trafic du cœur IP. Par conséquent, le choix PIM-DR est utilisé pour éviter la duplication du trafic de données.

Les domaines d’apprentissage sont décrits dans la section Apprentissage qualifié.

Pour les locuteurs IGMP (hôtes et routeurs) dans le domaine d’apprentissage, P-A et S-A doivent apparaître ensemble comme un seul périphérique avec les interfaces I4, I3, ae0.0 et ae0.1.

Aucun paquet de contrôle dupliqué ne doit être envoyé sur les liaisons multichâssis, ce qui signifie que le paquet de contrôle ne doit être envoyé que par une seule liaison.

Mises à jour de l’état du plan de contrôle déclenchées par les paquets reçus sur un châssis distant

Voici les mises à jour de l’état du plan de contrôle qui sont déclenchées par les paquets reçus sur le châssis distant :

• L’état d’appartenance au routage multicast de couche 3 est mis à jour à la suite des rapports appris sur les branches distantes des liaisons multichâssis et des liaisons S attachées au châssis distant.

• L’état d’appartenance et l’entrée de routage dans la surveillance sont mis à jour lorsque des rapports sont reçus sur les branches distantes d’une liaison multichâssis.

Transfert de données

Cette discussion suppose que le routage et le pontage intégrés sur le routeur P-A constituent le PIM-DR. Il extrait le trafic des sources du cœur. Le trafic peut également provenir des interfaces de couche 2 dans le domaine de pont. Pour les hôtes directement connectés au châssis P-A, il n’y a aucun changement dans la façon dont les données sont livrées.

Pour acheminer le trafic vers les hôtes connectés à S-A (qui est le non-DR) sur la liaison de résidence unique comme I3, nous nous appuyons sur la liaison interchâssis. Le trafic qui atteint P-A est envoyé via ICL à S-A pour être acheminé vers les liens qui ont signalé un intérêt pour s,g et les liens qui sont orientés routeur.

Lorsque le segment ae0 dans P-A tombe en panne, les hôtes connectés à la liaison multichâssis reçoivent le trafic via ICL. Dans S-A, le trafic reçu sur ICL est envoyé aux liaisons multichâssis de la liste des interfaces sortantes pour lesquelles l’homologue ae de P-A est en panne.

Topologie pure de couche 2 sans routage ni pontage intégrés

La Figure 2 montre que le châssis qui se connecte au PIM-DR est le routeur actif principal (P-A) et l’autre est le routeur actif secondaire (S-A).

Figure 2 : configuration de couche 2 sans routage ni pontage intégrés

Apprentissage qualifié

Dans cette topologie, les interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 et I10 sont des interfaces à hébergement unique. Les liaisons multichâssis ae0.0 et ae0.1 appartiennent au même domaine de pont dans les deux châssis. Les interfaces I10, I1, I7, I3, I5, ae0.0 et ae0.1 sont dans le même domaine de pont, bd1 dans P-A. Les interfaces I9, I2, I8, I4, I6, ae0.0 et ae0.1 se trouvent dans le même domaine de pont, bd1 dans S-A.

Cette discussion suppose la configuration suivante :

• En P-A et S-A, l’apprentissage qualifié est activé en bd1.

• Les interfaces I1, I2, I3, ae0.0 et I4 appartiennent au domaine d’apprentissage ld1 vlan1.

• Les interfaces I7, I8, I5, ae0.1 et I6 appartiennent au domaine d’apprentissage ld2 de VLAN2.

• Les interfaces I9 et I10 appartiennent au vlan3, domaine d’apprentissage ld3.

Pour les locuteurs IGMP (hôtes et routeurs) dans le même domaine d’apprentissage, ld1, P-A et S-A liés doivent apparaître comme un seul commutateur.

Pour les locuteurs IGMP (hôtes et routeurs) dans le même domaine d’apprentissage, ld2, P-A et S-A liés doivent apparaître comme un seul commutateur.

Étant donné qu’il n’y a pas de liens multichâssis dans le domaine d’apprentissage ld3, pour les locuteurs IGMP (hôtes et routeurs) dans le domaine d’apprentissage ld3, P-A et S-A n’apparaîtront pas comme un seul commutateur.

Cette discussion suppose que la liaison interchâssis ICL1 correspond au domaine d’apprentissage ld1 et que la liaison interchâssis ICL2 correspond au domaine d’apprentissage ld2.

Le contrôle du flux de paquets est pris en charge, à l’exception de la transmission d’informations à l’IRB.

Transfert de données avec apprentissage qualifié

Cette discussion suppose un domaine d’apprentissage (LD), ld1, et suppose en outre que l’interface I1 sur le routeur P-A est connectée au PIM-DR dans le domaine d’apprentissage et extrait le trafic des sources du cœur.

Pour acheminer le trafic vers les hôtes connectés au routeur S-A (qui est le non-DR) sur la liaison de résidence unique comme I2, I4 (appartenant à ld1), nous nous appuyons sur ICL1. Le trafic qui atteint le routeur P-A sur l’interface I1 est envoyé via la liaison interchâssis ICL1 au routeur S-A pour être transmis aux liaisons qui ont signalé un intérêt pour s,g ou aux liaisons qui sont orientées routeur dans le domaine d’apprentissage ld1.

Lorsque la branche ae0 de l’interface du routeur P-A tombe en panne, les hôtes connectés à la liaison multichâssis reçoivent le trafic de l’interface I1 à l’aide de la liaison interchâssis ICL1. Dans le routeur S-A, le trafic reçu sur la liaison interchâssis ICL1 est envoyé aux liaisons multichâssis dans la liste des interfaces sortantes pour lesquelles la contrepartie Ethernet agrégée dans le routeur P-A est en panne.

On suppose en outre que l’interface I9 dans le routeur S-A appartient au domaine d’apprentissage ld3 avec des intérêts dans s,g, et que l’interface I10 dans le domaine d’apprentissage ld3 dans le routeur P-A reçoit le trafic pour s,g. L’interface I9 ne reçoit pas de données dans cette topologie car il n’y a pas de liens multichâssis (en mode a-a) et donc pas de lien interchâssis dans le domaine d’apprentissage ld3.

Groupes statiques sur des interfaces de résidence unique

Pour les liaisons multichâssis, la configuration de groupe statique doit exister sur les deux branches et aucune synchronisation avec l’autre châssis n’est requise.

La synchronisation des groupes statiques sur des interfaces de résidence unique entre les châssis n’est pas prise en charge. Toutefois, l’ajout d’interfaces logiques à la liste des interfaces sortantes par défaut prend en charge la distribution du trafic à l’interface dans une configuration statique.

Interfaces orientées routeur sous forme de liaisons multichâssis

Les requêtes IGMP peuvent arriver sur l’une ou l’autre branche des liaisons multichâssis, mais dans les deux cas, la liaison multichâssis doit être considérée comme faisant face au routeur.

Les rapports ne doivent sortir qu’une seule fois de la liaison multichâssis, c’est-à-dire d’une seule étape.

La prise en charge MC-LAG suivante pour la surveillance IGMP dans IRB est fournie :

• Surveillance sans proxy

• Les interfaces logiques doivent être des interfaces sortantes pour toutes les routes, y compris la route par défaut

• Surveillance IGMP dans un commutateur de couche 2 pur

• Surveillance IGMP dans les domaines de pont pour faire de l’apprentissage qualifié

• Interface côté routeur MC-Links

Les fonctionnalités suivantes sont not prises en charge :

• Mode proxy pour actif-actif

• Prise en charge MC-LAG des instances VPLS

• Ports trunk en tant que liaisons multichâssis

• Ajout d’interfaces logiques aux interfaces sortantes en fonction des besoins.

  Toutefois, les interfaces logiques sont toujours ajoutées en tant qu’interface côté routeur à la liste des interfaces sortantes.

Topologie MC-LAG prise en charge

Pour prendre en charge le transport sans perte du trafic FCoE sur un MC-LAG, vous devez configurer la classe de service (CoS) appropriée sur les deux commutateurs avec des membres de port MC-LAG. La configuration CoS doit être la même sur les deux commutateurs MC-LAG, car les MC-LAG ne portent pas les informations de classe de transfert et de priorité IEEE 802.1p.

Les commutateurs qui ne sont pas directement connectés aux hôtes FCoE et qui font office de commutateurs de transit pass-through prennent en charge les MC-LAG pour le trafic FCoE dans une topologie de réseau en U inversé . La figure 3 illustre une topologie en U inversé à l’aide de commutateurs QFX3500.

Figure 3 : topologie prise en charge pour un MC-LAG sur un commutateur de transit FCoE

Les commutateurs autonomes prennent en charge les MC-LAG. Système QFabric Les équipements de nœud ne prennent pas en charge les MC-LAG. Les configurations Virtual Chassis et Virtual Chassis Fabric (VCF) en mode mixte ne prennent pas en charge FCoE. Seuls les VCF QFX5100 purs (composés uniquement de QFX5100 commutateurs) prennent en charge le FCoE.

Les ports faisant partie d’une configuration de passerelle FCoE-FC (structure de passerelle FCoE-FC virtuelle) ne prennent pas en charge les MC-LAG. Les ports membres d’un MC-LAG agissent comme des ports de commutation de transit pass-through.

Les règles et directives suivantes s’appliquent aux MC-LAG lorsqu’ils sont utilisés pour le trafic FCoE. Les règles et directives permettent de garantir une manipulation correcte et des caractéristiques de transport sans perte requises pour le trafic FCoE.

• Les deux commutateurs qui forment le MC-LAG (commutateurs S1 et S2) ne peuvent pas utiliser de ports faisant partie d’une structure de passerelle FCoE-FC. Les ports de commutation MC-LAG doivent être des ports de commutation de transit pass-through (utilisés dans le cadre d’un commutateur de transit intermédiaire qui n’est pas directement connecté aux hôtes FCoE).

• Les commutateurs MC-LAG S1 et S2 ne peuvent pas être connectés directement aux hôtes FCoE.

• Les deux commutateurs qui servent de périphériques d’accès aux hôtes FCoE (commutateurs de transit FCoE TS1 et TS2) utilisent des LAG standard pour se connecter aux commutateurs MC-LAG S1 et S2. Commutateurs de transit FCoE TS1 et TS2 peuvent être des commutateurs autonomes ou des périphériques de nœud dans un système QFabric.

• Les commutateurs de transit TS1 et TS2 doivent utiliser des ports de commutateur de transit pour les hôtes FCoE et pour les LAG standard vers les commutateurs MC-LAG S1 et S2.

• Activez la surveillance FIP sur le VLAN FCoE sur les commutateurs de transit TS1 et TS2. Vous pouvez configurer VN_Port pour VF_Port (VN2VF_Port) surveillance FIP ou VN_Port pour VN_Port (VN2VN_Port) surveillance FIP, selon que les hôtes FCoE ont besoin d’accéder à des cibles dans le SAN FC (VN2VF_Port surveillance FIP) ou à des cibles dans le réseau Ethernet (VN2VN_Port surveillance FIP).

  La surveillance FIP doit être effectuée au niveau du bord d’accès et n’est pas prise en charge sur les commutateurs MC-LAG. N’activez pas la surveillance FIP sur les commutateurs MC-LAG S1 et S2. (N’activez pas l’écoute FIP sur les ports MC-LAG qui connectent les commutateurs S1 et S2 aux commutateurs TS1 et TS2 ou sur les ports LAG qui relient les commutateurs S1 à S2.)

  Note:

  Juniper Networks commutateurs d’agrégation QFX10000 ne prenant pas en charge la surveillance FIP et ne peuvent donc pas être utilisés comme commutateurs d’accès avec surveillance FIP (commutateurs de transit TS1 et TS2) dans cette topologie.

• La configuration CoS doit être cohérente sur les commutateurs MC-LAG. Étant donné que les MC-LAG ne contiennent pas d’informations de classe de transfert ou de priorité, chaque commutateur MC-LAG doit avoir la même configuration CoS pour prendre en charge le transport sans perte. (Sur chaque commutateur MC-LAG, le nom, la file d’attente de sortie et le provisionnement CoS de chaque classe de transfert doivent être identiques, et la configuration du contrôle de flux basé sur la priorité (PFC) doit être la même.)

• Commutateurs de transit (accès au serveur)
• Commutateurs MC-LAG (agrégation FCoE)

Surveillance FIP et ports FCoE approuvés

Pour garantir un accès sécurisé, activez la surveillance FIP VN2VF_Port ou la surveillance FIP VN2VN_Port sur les ports d’accès des commutateurs de transit connectés directement aux hôtes FCoE. La surveillance FIP doit être effectuée à la périphérie d’accès du réseau pour empêcher tout accès non autorisé. Par exemple, dans la Figure 3, vous activez la surveillance FIP sur les VLAN FCoE sur les commutateurs de transit TS1 et TS2 qui incluent les ports d’accès connectés aux hôtes FCoE.

N’activez pas la surveillance FIP sur les commutateurs utilisés pour créer le MC-LAG. Par exemple, dans la Figure 3, vous n’activez pas la surveillance FIP sur les VLAN FCoE des commutateurs S1 et S2.

Configurez les liaisons entre les commutateurs en tant que ports de confiance FCoE afin de réduire la surcharge liée à la surveillance FIP et de vous assurer que le système effectue la surveillance FIP uniquement au niveau du bord d’accès. Dans l’exemple de topologie, configurez les ports LAG du commutateur de transit TS1 et TS2 connectés aux commutateurs MC-LAG en tant que ports approuvés FCoE, configurez les ports MC-LAG des commutateurs S1 et S2 connectés aux commutateurs TS1 et TS2 en tant que ports approuvés FCoE, et configurez les ports du LAG qui relie les commutateurs S1 à S2 en tant que ports approuvés FCoE.

CoS et pontage de centre de données (DCB)

Les liaisons MC-LAG ne contiennent pas d’informations de classe de transfert ou de priorité. Les propriétés CoS suivantes doivent avoir la même configuration sur chaque commutateur MC-LAG ou sur chaque interface MC-LAG pour prendre en charge le transport sans perte :

• Nom de la classe de transfert FCoE : par exemple, la classe de transfert du trafic FCoE peut utiliser la classe de transfert par défaut fcoe sur les deux commutateurs MC-LAG.

• File d’attente de sortie FCoE : par exemple, la classe de transfert peut être mappée à la fcoe file d’attente 3 sur les deux commutateurs MC-LAG (la file d’attente 3 est le mappage par défaut de la fcoe classe de transfert).

• Classifier (Classifier) : la classe de transfert du trafic FCoE doit être mappée au même point de code IEEE 802.1p sur chaque interface membre du MC-LAG sur les deux commutateurs MC-LAG. Par exemple, la classe fcoe de transfert FCoE peut être mappée à un point 011 de code IEEE 802.1p (le point 011 de code est le mappage par défaut de la fcoe classe de transfert).

• Contrôle de flux basé sur la priorité (PFC) : le PFC doit être activé sur le point de code FCoE de chaque commutateur MC-LAG et appliqué à chaque interface MC-LAG à l’aide d’un profil de notification d’encombrement.

Vous devez également configurer la sélection de transmission améliorée (ETS) sur les interfaces MC-LAG afin de fournir des ressources de planification suffisantes (bande passante, priorité) pour un transport sans perte. La configuration ETS peut être différente sur chaque commutateur MC-LAG, à condition que suffisamment de ressources soient planifiées pour prendre en charge le transport sans perte du trafic FCoE attendu.

Le protocole LLDP (Link Layer Discovery Protocol) et le protocole DCBX (Data Center Bridging Capability Exchange Protocol) doivent être activés sur chaque interface membre MC-LAG (LLDP et DCBX sont activés par défaut sur toutes les interfaces).

Avantages de l’utilisation d’EVPN-MPLS avec Junos Fusion Enterprise et MC-LAG

Utilisez EVPN-MPLS avec Junos Fusion Enterprise et MC-LAG pour interconnecter des campus et des centres de données dispersés afin de former un pont virtuel de couche 2 unique.

Gestion du trafic BUM

Dans les cas d’utilisation illustrés aux figures 4 et 5, PE1, PE2 et PE3 sont des homologues EVPN, et PE2 et PE3 sont des homologues MC-LAG. Les deux ensembles d’homologues échangent des informations de contrôle et transfèrent le trafic l’un à l’autre, ce qui pose des problèmes. Le Tableau 2 décrit les problèmes qui surviennent et la manière dont Juniper Networks les résout dans son implémentation de la fonctionnalité d’interopérabilité EVPN-MPLS.

Split Horizon

Dans les cas d’utilisation illustrés sur les figures 4 et 5, l’horizon fractionné empêche le transfert de plusieurs copies d’un paquet BUM vers un périphérique CE (périphérique satellite). Cependant, les implémentations EVPN-MPLS et MC-LAG à horizon fractionné se contredisent, ce qui pose problème. Le Tableau 3 explique le problème et la manière dont Juniper Networks l’a résolu en implémentant la fonctionnalité d’interconnectabilité EVPN-MPLS.

Apprentissage MAC

EVPN et MC-LAG utilisent la même méthode pour apprendre les adresses MAC, à savoir qu’un équipement PE apprend les adresses MAC de ses interfaces locales et synchronise les adresses avec ses homologues. Toutefois, étant donné qu’EVPN et MC-LAG synchronisent les adresses, un problème se pose.

Le Tableau 4 décrit le problème et la façon dont l’implémentation de l’interopérabilité EVPN-MPLS l’empêche. Les cas d’utilisation illustrés aux figures 4 et 5 illustrent le problème. Dans les deux cas d’utilisation, PE1, PE2 et PE3 sont des homologues EVPN, et PE2 et PE3 sont des homologues MC-LAG.

Gestion de la liaison descendante entre les ports en cascade et en liaison montante dans Junos Fusion Enterprise

Dans la Junos Fusion Enterprise illustrée à la Figure 4, supposons que le périphérique d’agrégation PE2 reçoit un paquet BUM de PE1 et que la liaison entre le port en cascade sur PE2 et le port de liaison montante correspondant sur le périphérique satellite SD1 est interrompue. Que le paquet BUM soit géré par MC-LAG ou par le multihébergement actif-actif EVPN, le résultat est le même : le paquet est transféré via l’interface ICL à PE3, qui le transmet à SD1 en double homing.

Pour illustrer plus en détail la façon dont EVPN avec multihébergement actif-actif gère cette situation avec SD1 à double domicile, supposons que l’interface DF réside sur PE2 et est associée à la liaison descendante et que l’interface non-DF réside sur PE3. En règle générale, par EVPN avec une logique de transfert actif-actif multihébergement, l’interface non-DF abandonne le paquet. Cependant, en raison de la liaison descendante associée à l’interface DF, PE2 transfère le paquet BUM via l’ICL vers PE3, et l’interface non-DF sur PE3 transfère le paquet à SD1.

Prise en charge de la passerelle de couche 3

La fonctionnalité d’interopérabilité EVPN-MPLS prend en charge les fonctionnalités de passerelle de couche 3 suivantes pour les domaines de pont étendus et les VLAN :

• Interfaces IRB (Integrated Routing and Bridging) pour transférer le trafic entre les domaines de pont étendus ou VLAN.

• Passerelles de couche 3 par défaut pour transférer le trafic d’un serveur physique (bare metal) d’un domaine de pont étendu ou d’un VLAN vers un serveur physique ou une machine virtuelle d’un autre domaine de pont étendu ou VLAN.