Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Dépannage de l’agrégation de liens multichâssis

Utilisez les informations suivantes pour résoudre les problèmes de configuration de 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 connectés sont en panne, 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 en validant la configuration, le tableau MAC affiche toujours les adresses MAC telles qu’elles sont apprises sur les interfaces Ethernet agrégées multichâssis des deux homologues MC-LAG.

Solution

C’est un comportement normal.

L’homologue MC-LAG 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 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 passage en mode veille, assurez-vous que l’adresse IP homologue dans les configurations ICCP et l’adresse IP dans les configurations de protection multichâssis sont identiques.

L’homologue MC-LAG secondaire avec contrôle d’état défini sur Veille 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 le pair MC-LAG (multichassis link aggregation group) principal, les interfaces Ethernet agrégées multichâssis du pair MC-LAG secondaire avec contrôle d’état en veille deviennent inactives au lieu d’être actives.

Solution

C’est un comportement normal.

Les filtres de redirection ont la priorité sur les filtres définis par l’utilisateur

Problème

Description

Les filtres de redirection de basculement implicite MC-LAG (Multichassis Link Aggregation Group) sont prioritaires sur les filtres explicites configurés par l’utilisateur.

Solution

C’est un comportement normal.

Le résultat des commandes opérationnelles est erroné

Problème

Description

Après avoir désactivé le protocole ICCP (Inter-Chassis Control Protocol), la sortie de commande opérationnelle affiche toujours les show iccp démons clients enregistrés, tels que mcsnoopd, lacpd et eswd.

Par exemple:

La show iccp sortie de la commande affiche toujours les modules enregistrés, que les pairs ICCP soient configurés ou non.

Solution

C’est un comportement normal.

La connexion ICCP peut prendre jusqu’à 60 secondes pour devenir active

Problème

Description

Lorsque la configuration ICCP (Inter-Chassis Control Protocol) et la configuration RVI (Routed VLAN Interface) sont validées conjointement, la connexion ICCP peut prendre jusqu’à 60 secondes pour s’activer.

Solution

C’est un comportement normal.

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 une liaison 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 d’interface de saut suivant déclenchent des mises à jour d’adresse MAC dans le matériel, qui déclenchent ensuite des mises à jour vieillissantes dans le moteur de transfert de paquets. Par conséquent, 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.

Solution

C’est un comportement normal.

L’adresse MAC n’est pas apprise à distance dans un VLAN par défaut

Problème

Description

Solution

C’est un comportement normal.

Les entrées de surveillance 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

C’est un comportement normal.

ICCP n’apparaît 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. Cependant, l’authentification fonctionne correctement au niveau de l’homologue ICCP.

Solution

Supprimez la configuration ICCP, puis ajoutez la configuration ICCP.

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 en panne alors que la machine d’état est dans un état synchronisé, l’état local de l’homologue MC-LAG (groupe d’agrégation de liens multichâssis) est en veille. Si l’interface Ethernet agrégée multichâssis tombe en panne après que l’état de la machine est à l’état actif, l’état local reste actif et l’état local indique que l’interface est en panne.

Solution

C’est un comportement normal.

Boucle de paquets sur le serveur en cas d’échec de l’ICCP

Problème

Description

Lorsque vous activez la détection d’activité de sauvegarde pour un groupe d’agrégation de liens multichâssis (MC-LAG) et que les paquets de détection d’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

C’est un comportement normal.

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 n’est pas activée, 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

C’est un comportement normal.

Aucune vérification de validation n’est effectuée pour les interfaces ICL-PL

Problème

Description

Il n’y a pas de vérification de validation sur l’interface configurée en tant que liaison de protection de liaison interchâssis (ICL-PL). Vous devez donc fournir un nom d’interface valide pour l’ICL-PL.

Solution

C’est un comportement normal.

Scénario de double basculement

Problème

Description

Si les événements suivants se produisent dans cet ordre précis (inter-Chassis Control Protocol (ICCP) tombe en panne et 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 du MC-LAG en mode actif était active et bloque le trafic de la liaison de protection de liaison interchâssis (ICL-PL). Le trafic ICL-PL n’est pas transféré.

Solution

C’est un comportement normal.

Le trafic multicast inonde le VLAN lorsque l’interface ICL-PL tombe en panne et s’active

Problème

Description

Lorsque la liaison de protection de liaison interchâssis (ICL-PL) tombe en panne et s’allume, le trafic multicast est inondé vers toutes les interfaces du VLAN. L’indicateur 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

C’est un comportement normal.

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 en panne, le statut 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

C’est un comportement normal.

Les interfaces Ethernet agrégées tombent en panne

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 d’interface Ethernet agrégée multichâssis. Par exemple, l’interface Ethernet agrégée peut conserver la clé administrative 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 (groupe d’agrégation de liens multichâssis) hébergeant l’interface Ethernet agrégée pour activer 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 des adresses MAC homologues 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 autre adresse MAC (MAC2), l’adresse MAC2 peut ne pas être apprise par les commutateurs de la couche d’accès. L’inondation du trafic en 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 de table ARP et MAC ne sont pas synchronisées dans une configuration MC-LAG

Problème

Description

Les tables d’adresses MAC ARP et MAC d’une configuration MC-LAG restent normalement synchronisées, mais des mises à jour peuvent être perdues dans des situations extrêmes où des mises à jour de tables sont très fréquentes, par exemple lorsque des instabilités de liaison se produisent dans un groupe MC-LAG.

Solution

Pour éviter que les entrées ARP et MAC ne se désynchronisent dans une configuration MC-LAG, vous pouvez configurer l’option arp-l2-validate sur l’interface IRB du commutateur, comme suit :

Cette option n’est arp-l2-validate disponible que sur les commutateurs QFX Series.

Cette option active la validation des entrées de table ARP et MAC, en appliquant automatiquement les mises à jour si elles ne sont plus 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 en fonctionnement normal car cette option peut affecter les performances dans les configurations à grande échelle.