SUR CETTE PAGE
L’homologue MC-LAG secondaire dont le contrôle d’état est défini sur Standby devient inactif
Les filtres de redirection sont prioritaires sur les filtres définis par l’utilisateur
L’activation de la connexion ICCP peut prendre jusqu’à 60 secondes
L’âge de l’adresse MAC appris sur une interface Ethernet agrégée multichâssis est remis à zéro
L’adresse MAC n’est pas apprise à distance dans un VLAN par défaut
ICCP ne s’affiche pas après l’ajout ou la suppression d’une clé d’authentification
Les paquets bouclent sur le serveur en cas d’échec de l’ICCP
Aucune vérification de validation n’est effectuée pour les interfaces ICL-PL
Le trafic multicast inonde le VLAN lorsque l’interface ICL-PL tombe en panne ou augmente
Les entrées des tables ARP et MAC ne sont plus synchronisées dans une configuration MC-LAG
Dépannage de l’agrégation de liens multichâssis
Utilisez les informations suivantes pour résoudre les problèmes de configuration liés à l’agrégation de liens multichâssis :
Les adresses MAC apprises sur les interfaces Ethernet agrégées multichâssis ne sont pas supprimées de la table des adresses MAC
Problème
Description
Lorsque les deux interfaces Ethernet agrégées multichâssis sur les deux homologues MC-LAG (MultiChassis Link Aggregation Group) connectés sont inactives, les adresses MAC apprises sur les interfaces Ethernet agrégées multichâssis ne sont pas supprimées de la table des adresses MAC.
Par exemple, si vous désactivez l’interface Ethernet agrégée multichâssis (ae0) sur les deux homologues MC-LAG en exécutant la set interfaces ae0 disable commande et validez la configuration, la table MAC indique toujours les adresses MAC comme ayant été apprises sur les interfaces Ethernet agrégées multichâssis des deux homologues MC-LAG.
user@switchA> show ethernet-switching table Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:00:5E:00:53:00 Learn(L) 3:55 ae0.0 (MCAE) v10 00:00:5E:00:53:01 Learn(R) 0 xe-0/0/9.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:03 Static - Router
user@switchB> show ethernet-switching table Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:00:5E:00:53:04 Learn(R) 0 ae0.0 (MCAE) v10 00:00:5E:00:53:05 Learn 40 xe-0/0/10.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:06 Static - Router
Solution
Il s’agit d’un comportement attendu.
MC-LAG Peer ne passe pas en mode veille
Problème
Description
Un homologue MC-LAG (MultiChassis Link Aggregation Group) ne passe pas en mode veille si l’adresse IP de l’homologue MC-LAG spécifiée dans la configuration ICCP (Inter-Chassis Control Protocol) et l’adresse IP spécifiée dans la configuration de protection multichâssis sont différentes.
Solution
Pour éviter tout échec de mise en mode veille, assurez-vous que l’adresse IP de l’homologue dans les configurations ICCP et l’adresse IP dans les configurations de protection multichâssis sont identiques.
L’homologue MC-LAG secondaire dont le contrôle d’état est défini sur Standby devient inactif
Problème
Description
Lorsque la liaison de protection de liaison de contrôle interchâssis (ICL-PL) et les interfaces Ethernet agrégées multichâssis tombent en panne sur l’homologue MC-LAG (MultiChassis Link Aggregation Group) principal, les interfaces Ethernet agrégées multichâssis de l’homologue MC-LAG secondaire avec contrôle d’état défini sur veille deviennent inactives au lieu d’être actives.
Solution
Il s’agit d’un comportement attendu.
Les filtres de redirection sont prioritaires sur les filtres définis par l’utilisateur
La sortie de la commande opérationnelle est incorrecte
Problème
Description
Une fois que vous avez désactivé l’ICCP (Inter-Chassis Control Protocol), la sortie de la show iccp commande opérationnelle affiche toujours les démons clients enregistrés, tels que mcsnoopd, lacpd et eswd.
Par exemple:
user@switch> show iccp Client Application: MCSNOOPD Redundancy Group IDs Joined: None Client Application: lacpd Redundancy Group IDs Joined: 1 Client Application: eswd Redundancy Group IDs Joined: 1
La sortie de la show iccp commande affiche toujours les modules enregistrés, que des homologues ICCP soient configurés ou non.
Solution
Il s’agit d’un comportement attendu.
L’activation de la connexion ICCP peut prendre jusqu’à 60 secondes
L’âge de l’adresse MAC appris sur une interface Ethernet agrégée multichâssis est remis à zéro
Problème
Description
Lorsque vous activez puis désactivez un lien de protection de liaison interchâssis (ICL-PL), l’âge de l’adresse MAC appris sur l’interface Ethernet agrégée multichâssis est remis à zéro. Les modifications de l’interface de saut suivant déclenchent des mises à jour de l’adresse MAC dans le matériel, qui déclenchent ensuite des mises à jour vieillissantes dans le moteur de transfert de paquets. Le résultat est que l’âge de l’adresse MAC est mis à jour à zéro.
Par exemple, l’ICL-PL a été désactivé et la sortie de la show ethernet-switching table commande indique que les adresses MAC ont un âge de 0.
user@switch> show ethernet-switching table Ethernet-switching table: 3 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v100 * Flood - All-members v100 00:10:00:00:00:01 Learn(L) 0 ae0.0 (MCAE) v100 00:10:00:00:00:02 Learn(L) 0 ae0.0 (MCAE)
Solution
Il s’agit d’un comportement attendu.
L’adresse MAC n’est pas apprise à distance dans un VLAN par défaut
Problème
Description
Sur un commutateur QFX3500 exécutant Junos OS version 12.3 ou antérieure, si un homologue MC-LAG (MultiChassis Link Aggregation Group) apprend une adresse MAC dans le VLAN par défaut, le protocole ICCP (Inter-Chassis Control Protocol) ne synchronise pas le adresse MAC avec le adresse MAC de l’autre homologue MC-LAG.
Solution
Il s’agit d’un comportement attendu.
Les entrées d’écoute apprises sur les interfaces Ethernet agrégées multichâssis ne sont pas supprimées
Problème
Description
Lorsque des interfaces Ethernet agrégées multichâssis sont configurées sur un VLAN activé pour la surveillance multicast, les entrées d’appartenance apprises sur les interfaces Ethernet agrégées multichâssis sur le VLAN ne sont pas effacées lorsque les interfaces Ethernet agrégées multichâssis tombent en panne. Ceci est fait pour accélérer le temps de convergence lorsque les interfaces apparaissent, ou montent et descendent.
Solution
Il s’agit d’un comportement attendu.
ICCP ne s’affiche pas après l’ajout ou la suppression d’une clé d’authentification
Problème
Description
La connexion ICCP (Inter-Chassis Control Protocol) n’est pas établie lorsque vous ajoutez une clé d’authentification et que vous la supprimez uniquement au niveau ICCP global. Toutefois, l’authentification fonctionne correctement au niveau de l’homologue ICCP.
Solution
Supprimez la configuration ICCP, puis ajoutez-la.
L’état local est en veille alors qu’il devrait être actif
Problème
Description
Si l’interface Ethernet agrégée multichâssis est inactive alors que la machine d’état est dans un état synchronisé, l’état local de l’homologue MC-LAG (MultiChassis Link Aggregation Group) est en veille. Si l’interface Ethernet agrégée multichâssis tombe en panne alors que la machine d’état est dans un état actif, l’état local reste actif et l’état local indique que l’interface est inactive.
Solution
Il s’agit d’un comportement attendu.
Les paquets bouclent sur le serveur en cas d’échec de l’ICCP
Problème
Description
Lorsque vous activez la détection de l’activité de sauvegarde pour un groupe d’agrégation de liens multichâssis (MC-LAG) et que les paquets de détection de l’activité de sauvegarde sont perdus en raison d’une défaillance temporaire sur le MC-LAG, les deux homologues du MC-LAG restent actifs. Si cela se produit, les deux homologues MC-LAG envoient des paquets au serveur connecté.
Solution
Il s’agit d’un comportement attendu.
Les deux homologues MC-LAG utilisent l’ID système par défaut après un redémarrage ou une modification de la configuration ICCP
Problème
Description
Après un redémarrage ou après qu’une nouvelle configuration ICCP (Inter-Chassis Control Protocol) a été validée et que la connexion ICCP ne devient pas active, les messages LACP (Link Aggregation Control Protocol) transmis sur les interfaces Ethernet agrégées multichâssis utilisent l’ID système par défaut. L’ID système configuré n’est utilisé à la place de l’ID système par défaut qu’après la synchronisation des homologues MC-LAG.
Solution
Il s’agit d’un comportement attendu.
Aucune vérification de validation n’est effectuée pour les interfaces ICL-PL
Scénario de double basculement
Problème
Description
Si les événements suivants se produisent dans cet ordre exact (ICCP (Inter-Chassis Control Protocol) tombe en panne et que l’interface Ethernet agrégée multichâssis sur l’homologue MC-LAG (MultiChassis Link Aggregation Group) en mode actif tombe en panne, un double basculement se produit. Dans ce scénario, l’homologue MC-LAG en mode veille ne détecte pas ce qui se passe sur l’homologue MC-LAG actif. L’homologue MC-LAG en mode veille fonctionne comme si l’interface Ethernet agrégée multichâssis sur le MC-LAG en mode actif était active et bloque le trafic ICL-PL (Interchassis Link Protection Link). Le trafic ICL-PL n’est pas transféré.
Solution
Il s’agit d’un comportement attendu.
Le trafic multicast inonde le VLAN lorsque l’interface ICL-PL tombe en panne ou augmente
Problème
Description
Lorsque le lien de protection de liaison interchâssis (ICL-PL) tombe en panne ou s’active, le trafic multicast est inondé vers toutes les interfaces du VLAN. L’indicateur de moteur de transfert de paquets Ip4McastFloodMode pour le VLAN est remplacé par MCAST_FLOOD_ALL. Ce problème se produit uniquement lorsqu’un groupe d’agrégation de liens multichâssis (MC-LAG) est configuré pour la couche 2.
Solution
Il s’agit d’un comportement attendu.
Le trafic de couche 3 envoyé à l’homologue MC-LAG de secours n’est pas redirigé vers l’homologue MC-LAG actif
Problème
Description
Lorsque le protocole ICCP (Inter-Chassis Control Protocol) est inactif, l’état d’un homologue MC-LAG distant est inconnu. Même si l’homologue MC-LAG est configuré en veille, le trafic n’est pas redirigé vers cet homologue, car il est supposé que cet homologue est en panne.
Solution
Il s’agit d’un comportement attendu.
Pannes des interfaces Ethernet agrégées
Problème
Description
Lorsqu’une interface Ethernet agrégée multichâssis est convertie en interface Ethernet agrégée, elle conserve certaines propriétés de l’interface Ethernet agrégée multichâssis. Par exemple, l’interface Ethernet agrégée peut conserver la clé d’administration de l’interface Ethernet agrégée multichâssis. Lorsque cela se produit, l’interface Ethernet agrégée tombe en panne.
Solution
Redémarrez le protocole LACP (Link Aggregation Control Protocol) sur l’homologue MC-LAG (MultiChassis Link Aggregation Group) hébergeant l’interface Ethernet agrégée pour afficher l’interface Ethernet agrégée. Le redémarrage de LACP supprime les propriétés Ethernet agrégées multichâssis de l’interface Ethernet agrégée.
Inondation du trafic en amont
Problème
Description
Lorsque la synchronisation MAC est activée, l’homologue MC-LAG (MultiChassis Link Aggregation Group) peut résoudre les entrées ARP (Address Resolution Protocol) pour l’interface VLAN ROUTÉE (RVI) MC-LAG avec l’une ou l’autre des adresses MAC de l’homologue MC-LAG. Si le trafic en aval est envoyé avec une adresse MAC (MAC1) mais que l’homologue a résolu l’adresse MAC avec une adresse MAC (MAC2) différente, l’adresse MAC2 peut ne pas être apprise par les commutateurs de couche d’accès. Un flooding du trafic amont pour l’adresse MAC2 peut alors se produire.
Solution
Assurez-vous que le trafic en aval est envoyé régulièrement à partir des homologues MC-LAG pour éviter que les adresses MAC ne vieillissent.
Les entrées des tables ARP et MAC ne sont plus synchronisées dans une configuration MC-LAG
Problème
Description
Les tables ARP et d’adresse MAC dans une configuration MC-LAG restent normalement synchronisées, mais les mises à jour peuvent être perdues dans des situations extrêmes où les mises à jour de table se produisent très fréquemment, par exemple lorsque des battements de liens se produisent dans un groupe MC-LAG.
Solution
Pour éviter que les entrées ARP et MAC ne soient désynchronisées dans une configuration MC-LAG, vous pouvez configurer l’option arp-l2-validate sur l’interface IRB du commutateur, comme suit :
user@switch> set interfaces irb arp-l2-validate
Cette arp-l2-validate option est disponible uniquement sur les commutateurs QFX Series et les commutateurs EX4300 à partir de Junos OS version 15.1R4 et EX9200 à partir de Junos OS version 13.2R4.
Cette option active la validation des entrées de table ARP et MAC, en appliquant automatiquement les mises à jour si elles ne sont pas synchronisées. Vous pouvez activer cette option comme solution de contournement lorsque le réseau rencontre d’autres problèmes qui entraînent également une perte de synchronisation ARP et MAC, mais désactivez-la pendant le fonctionnement normal, car cette option peut affecter les performances dans les configurations évolutives.