Concepts MC-LAG avancés

Avantages de la synchronisation de configuration

La synchronisation de la configuration vous permet de propager, de synchroniser et de valider les configurations d’un périphérique à un autre. Vous pouvez vous connecter à n’importe lequel de ces appareils 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’appareil local, un ou plusieurs pour les appareils distants et un pour la configuration globale, qui est essentiellement une configuration commune à tous les appareils.

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 dans la [edit system commit] hiérarchie pour synchroniser les configurations et les validations sur les appareils par défaut. NETCONF sur SSH assure une connexion sécurisée entre les appareils, tandis que 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, procédez comme suit :

1. Mappez statiquement l’appareil local aux appareils 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 de l’authentification de l’utilisateur pour la synchronisation de la configuration.

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

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’appareil local, un groupe de configuration distant est utilisé par l’appareil distant et un groupe de configuration globale est partagé entre les appareils locaux et distants.

Par exemple, vous pouvez créer un groupe de configuration local appelé Groupe A, qui inclut la configuration utilisée par l’appareil local (commutateur A), un groupe de configuration distant appelé Groupe B, qui inclut la configuration utilisée par les appareils distants (commutateur B, commutateur C et commutateur D) et un groupe de configuration globale appelé Groupe C, qui inclut la configuration commune à tous les appareils.

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

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 distant (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 la configuration des appareils pour la synchronisation de la configuration

Pour synchroniser les configurations entre les appareils, vous devez configurer le nom d’hôte ou l’adresse IP, le nom d’utilisateur et le mot de passe des appareils distants. Pour ce faire, émettez la set peers <hostname-of-remote-peer> user <name-of-user> authentication <plain-text-password-string> commande dans la [edit system commit] hiérarchie de 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 appareils distants. À cela, délivrez le 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 appareils. Pour activer NETCONF sur SSH, exécutez la set system services netconf ssh commande sur tous les appareils.

Synchronisation des configurations et des validations entre les équipements

L’équipement local (ou demandeur) sur lequel vous activez l’instruction peers-synchronize ou exécutez la commit peers-synchronize commande copie et charge sa configuration sur l’équipement distant (ou répondant). Chaque périphérique effectue ensuite une vérification syntaxique sur le 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 procédural à 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 appareils distants chargent la configuration, envoient les résultats du chargement à l’appareil local, exportent leur configuration vers l’appareil 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’appareil distant est indisponible ou b) l’appareil distant est accessible, mais des échecs surviennent pour les raisons suivantes :

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

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

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

• La vérification de la validation échoue.

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

Voici un exemple de message d’avertissement :

Si vous n’avez pas configuré l’instruction peers avec les informations du périphérique distant et que vous exécutez la commit commande, seule la configuration sur le périphérique local est validée. Si l’appareil distant est inaccessible et qu’il y a d’autres échecs, la validation échoue sur les appareils 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 l’appareil local pour synchroniser la configuration avec l’appareil distant et que l’appareil distant est accessible mais qu’il y a d’autres échecs, la validation échoue à la fois sur les appareils locaux et distants.

Avantages de l’utilisation de la vérification de cohérence MC-LAG

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

Comment fonctionnent les contrôles de cohérence MC-LAG

Les événements suivants se produisent lors du contrôle de cohérence de la configuration après l’émission d’un commit 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 envoie la configuration à 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 grave entre les deux configurations MC-LAG, l’interface MC-LAG est désactivé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 du contrôle 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 avec sa propre configuration.

  S’il y a une incohérence grave 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 des configurations

Les exigences de cohérence de configuration varient en fonction des paramètres MC-LAG. Les exigences de cohérence sont soit identiques, soit uniques, ce qui signifie que certains paramètres doivent être configurés de manière identique et d’autres doivent être configurés 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 configurez le paramètre MC-LAG de manière incorrecte, 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 émettez un commit réussi, le système active 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 indiquant que, "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 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 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 arrêtée.

Lorsque les pairs distants sont injoignables

Lorsque vous émettez une validation 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. Lorsqu’un homologue distant apparaît, 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 émettez un commit réussi, le système fait apparaître l’interface.

Activation de la vérification de la cohérence des configurations MC-LAG

La vérification de cohérence est activée par défaut. Le Tableau 1 fournit un exemple de liste des 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 des contrôles de cohérence (obligatoires ou souhaités).

Apprentissage de 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 dont les incohérences sont vérifiées, 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 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 configuration. Les résultats sont soit réussis, soit rejetés.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency global-config pour afficher l’état de vérification de la cohérence de la configuration pour toutes les configurations globales liées à 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 cohérence de la configuration. Les résultats sont soit réussis, soit échoués.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency icl-config pour afficher l’état de 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 cohérence de configuration. Les résultats sont soit réussis, soit rejetés.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency mcae-config pour afficher l’état de vérification de la cohérence de la configuration pour les 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 cohérence de configuration. Les résultats sont soit réussis, soit rejetés.

• Exécutez la commande show multi-chassis mc-lag configuration-consistency vlan-config pour afficher l’état de 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 cohérence de configuration. Les résultats sont soit réussis, soit échoués.

• 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 cohérence de configuration. Les résultats sont soit réussis, soit rejetés.

• 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 arrêtée.

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

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

Le déclencheur du lancement de ces activités d’adhésion et d’élagage est les rapports d’adhésion IGMP reçus des destinataires intéressés. Les rapports IGMP reçus sur des interfaces Ethernet agrégées multichâssis (potentiellement du hachage sur l’un ou l’autre des homologues MC-LAG) et les liaisons monohomiques 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).

Si le routeur désigné tombe en panne, le routeur non désigné doit construire l’ensemble de l’arbre de transfert (RPT et SPT), ce qui peut entraîner une perte de trafic multicast.

Fonctionnement PIM avec le mode Dual Designated Router

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

L’homologue MC-LAG principal transfère le trafic multicast aux appareils 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 de multicast. L’homologue MC-LAG de secours abandonne 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 primaire, il ajoute le VLAN récepteur à l’OIL et commence à transférer le trafic multicast.

Pour activer un routeur multicast à double désigné, 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ée si l’appairage PIM tombe en panne.

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

Surveillance IGMP dans la fonctionnalité du mode actif-actif MC-LAG

Les modes actif-actif MC-LAG (Multichassis Link Aggregation Group) et la surveillance IGMP en mode actif-veille sont pris en charge. MC-LAG permet à un périphérique de former une interface LAG logique avec deux périphériques réseau ou plus. MC-LAG offre des avantages supplémentaires, notamment la redondance au niveau des nœuds, le multihébergement et un réseau de couche 2 sans boucle sans utiliser le protocole STP (Spanning Tree Protocol). Les fonctionnalités suivantes sont prises en charge :

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

• Des formations qualifiées

• Liaisons multichâssis orientées routeur

Les améliorations suivantes sont prises en charge par rapport au pontage actif-actif et au protocole VRRP (Virtual Router Redundancy Protocol) sur IRB (Integrated Routing and Bridging) :

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

• Prise en charge par MC-LAG de la surveillance IGMP dans les domaines de pont pour un apprentissage qualifié

• Prise en charge des MC-Links en tant qu’interfaces côté routeur

Les fonctions suivantes sont not prises en charge :

• MC-LAG pour les instances VPLS

• Ports trunk MC-Links

• Mode proxy pour actif-actif

• Ajouter des liens interchâssis aux interfaces sortantes en fonction des besoins

  Les liens interchâssis peuvent être ajoutés à la liste des interfaces sortantes en tant qu’interfaces destinées au routeur.

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

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

Figure 1 : Réseau type sur lequel les réseaux actif/actif sont pris en charge

Les interfaces I3 et I4 sont des interfaces monohomées. Les liens 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 dans le routeur secondaire actif (S-A). Les interfaces I4, ae0.0 et ae0.1 se trouvent dans le même domaine de pont dans le routeur principal actif (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 des PIM-DR. Le châssis du routeur P-A est 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 ensemble devraient apparaître comme un seul périphérique avec les interfaces I4, I3, ae0.0 et ae0.1.

Aucun paquet de contrôle en double 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 des paquets reçus sur des châssis distants

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

• L’état d’appartenance au routage de 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 sont le PIM-DR. Il extrait le trafic des sources situées dans le cœur. Le trafic peut également provenir des interfaces de couche 2 dans le domaine du pont. Pour les hôtes directement connectés au châssis P-A, la manière dont les données sont transmises ne change pas.

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

Lorsque la branche 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é vers des liaisons multichâssis de la liste d’interfaces sortantes pour lesquelles la contrepartie AE dans P-A est arrêtée.

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

La figure 2 montre que le châssis se connectant 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 monohomées. Les liens 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 sont 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 VLAN1, domaine d’apprentissage LD1.

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

• Les interfaces I9 et I10 appartiennent au VLAN3, domaine d’apprentissage LD3.

Pour les haut-parleurs IGMP (hôtes et routeurs) dans le même domaine d’apprentissage ld1, P-A et S-A liés devraient 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 devraient apparaître comme un seul commutateur.

Comme il n’y a pas de liaisons multichâssis dans le domaine d’apprentissage ld3, pour les haut-parleurs IGMP (hôtes et routeurs) dans le domaine d’apprentissage ld3, P-A et S-A ne sembleront pas être un seul commutateur.

Cette discussion suppose que la liaison interchâssis ICL1 correspond au domaine d’apprentissage ld1 et 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 à 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 monohoming comme I2, I4 (appartenant à ld1), nous nous appuyons sur ICL1. Le trafic qui frappe le routeur P-A sur l’interface I1 est envoyé via la liaison interchâssis ICL1 vers le routeur S-A pour être livré aux liens qui ont signalé des intérêts pour s,g ou aux liens qui sont connectés au routeur dans le domaine d’apprentissage LD1.

Lorsque la branche ae0 du routeur P-A tombe en panne, les hôtes connectés à la liaison multichâssis reçoivent du 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é vers les liaisons multichâssis de la liste des interfaces sortantes pour lesquelles la contrepartie Ethernet agrégée dans le routeur P-A est arrêtée.

Il est en outre supposé que l’interface I9 du 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 du trafic pour s,g. L’interface I9 ne reçoit pas de données dans cette topologie car il n’y a pas de liaisons multichâssis (en mode a-a) et donc pas de liaison interchâssis dans le domaine d’apprentissage ld3.

Groupes statiques sur des interfaces monohomiques

Pour les liaisons multichâssis, la configuration de groupe statique doit exister sur les deux jambes, et la synchronisation avec l’autre châssis n’est pas nécessaire.

La synchronisation des groupes statiques sur des interfaces monohomiques 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 livraison 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 pairs, la liaison multichâssis doit être considérée comme orientée vers le routeur.

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

Le soutien MC-LAG suivant pour la surveillance IGMP dans la CISR est fourni :

• 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, apprentissage qualifié

• Interface orientée routeur MC-Links

Les fonctionnalités suivantes sont not prises en charge :

• Mode proxy pour actif-actif

• Prise en charge de MC-LAG pour les instances VPLS

• Ports trunk sous forme de liaisons multichâssis

• Ajouter des interfaces logiques aux interfaces sortantes en fonction des besoins.

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

Topologie MC-LAG prise en charge

Pour assurer 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 ayant 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 transportent 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 agissent comme des commutateurs de transit direct prennent en charge les MC-LAG pour le trafic FCoE dans une topologie de réseau en U inversé . La figure 3 montre une topologie en U inversé utilisant des 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. Les configurations Virtual Chassis et Virtual Chassis Fabric (VCF) en mode mixte ne prennent pas en charge le protocole FCoE. Seuls les VCF QFX5100 purs (constitués uniquement de commutateurs QFX5100) prennent en charge FCoE.

Les ports qui font partie d’une configuration de passerelle FCoE-FC (une fabric de passerelle virtuelle FCoE-FC) 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 (les commutateurs S1 et S2) ne peuvent pas utiliser les ports qui font partie d’une fabric de passerelle FCoE-FC. Les ports de commutation MC-LAG doivent être des ports de commutation de transit (utilisés dans le cadre d’un commutateur de transit intermédiaire qui n’est pas directement connecté à des 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 (les commutateurs de transit FCoE TS1 et TS2) utilisent des LAG standard pour se connecter aux commutateurs MC-LAG S1 et S2. Les commutateurs de transit FCoE TS1 et TS2 peuvent être des commutateurs autonomes.

• Les commutateurs de transit TS1 et TS2 doivent utiliser des ports de commutation 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 la surveillance FIP VN_Port VF_Port (VN2VF_Port) ou la surveillance FIP VN_Port VN_Port (VN2VN_Port), selon que les hôtes FCoE ont besoin d’accéder à des cibles dans le SAN FC (surveillance FIP VN2VF_Port) ou à des cibles dans le réseau Ethernet (surveillance FIP VN2VN_Port).

  La surveillance FIP doit être effectuée à la périphérie 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 la surveillance FIP sur les ports MC-LAG qui relient les commutateurs S1 et S2 aux commutateurs TS1 et TS2 ou sur les ports LAG qui relient les commutateurs S1 à S2.)

  Remarque :

  Les commutateurs QFX10000 ne prennent pas en charge la surveillance FIP ; ils ne peuvent donc pas être utilisés comme commutateurs d’accès à 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 transportent aucune information 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 les mêmes, 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 de confiance FCoE

Pour maintenir un accès sécurisé, activez la surveillance FIP VN2VF_Port ou la surveillance FIP VN2VN_Port sur les ports d’accès du commutateur 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 ne devez pas activer 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 de surveillance FIP et de vous assurer que le système effectue la surveillance FIP uniquement à la périphérie d’accès. Dans l’exemple de topologie, configurez les ports LAG TS1 et TS2 des commutateurs de transit connectés aux commutateurs MC-LAG en tant que ports de confiance FCoE, configurez les ports MC-LAG des commutateurs S1 et S2 connectés aux Commutateurs TS1 et TS2 en tant que ports de confiance FCoE, et configurez les ports du LAG qui relie les commutateurs S1 à S2 en tant que ports de confiance FCoE.

CoS et pontage de datacenters (DCB)

Les liens MC-LAG ne transportent pas d’informations de classe ou de priorité de transfert. 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 pour la fcoe classe de transfert).

• Classificateur : 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 au point 011 de code IEEE 802.1p (le point 011 de code est le mappage par défaut pour la fcoe classe de transfert).

• PFC (Priority-based Flow Control ) : le PFC doit être activé au point de code FCoE de chaque commutateur MC-LAG et appliqué à chaque interface MC-LAG à l’aide d’un profil de notification de congestion.

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, tant que suffisamment de ressources sont prévues pour prendre en charge le transport sans perte pour le 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 seul pont virtuel de couche 2.

Gestion du trafic BUM

Dans les cas d’utilisation illustrés à la figure 4 et à la figure 5, PE1, PE2 et PE3 sont des homologues EVPN, tandis que PE2 et PE3 sont des homologues MC-LAG. Les deux groupes d’homologues échangent des informations de contrôle et se transfèrent le trafic, ce qui pose des problèmes. Le Tableau 2 décrit les problèmes qui se posent et la manière dont Juniper Networks les résout en implémentant la fonctionnalité d’interopérabilité EVPN-MPLS.

Horizon divisé

Dans les cas d’utilisation illustrés aux figures 4 et 5, l’horizon fractionné empêche le transfert de plusieurs copies d’un paquet BUM vers un équipement CE (équipement satellite). Cependant, les implémentations EVPN-MPLS et MC-LAG Split Horizon se contredisent, ce qui pose problème. Le tableau 3 explique le problème et la manière dont Juniper Networks le résout en implémentant la fonctionnalité d’interopérabilité EVPN-MPLS.

Apprentissage MAC

L’EVPN et le MC-LAG utilisent la même méthode pour apprendre les adresses MAC, à savoir qu’un appareil PE apprend les adresses MAC de ses interfaces locales et synchronise les adresses avec ses pairs. Cependant, étant donné qu’EVPN et MC-LAG synchronisent les adresses, un problème survient.

Le Tableau 4 décrit le problème et la manière dont l’implémentation de l’interopérabilité EVPN-MPLS l’évite. Les cas d’utilisation illustrés aux figures 4 et 5 illustrent le problème. Dans les deux cas d’usage, PE1, PE2 et PE3 sont des homologues EVPN, tandis que PE2 et PE3 sont des homologues MC-LAG.

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

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

Pour illustrer plus en détail comment EVPN avec multihébergement actif-actif gère cette situation avec un SD1 à multihébergement, 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, avec un EVPN avec une logique de transfert multihébergement actif-actif, 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 à PE3, et l’interface non-DF sur PE3 transfère le paquet à SD1.

Prise en charge des passerelles de couche 3

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

• Interfaces de routage et de pontage intégrés (IRB) pour transférer le trafic entre les domaines de pont étendus ou les 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 d’un autre VLAN.

Comportement MC-LAG spécifique à la plate-forme