Remplacer le boîtier d'un autre fournisseur par un Huawei n'est rarement qu'un exercice de câblage — les deux cas de terrain ci-dessous ont tous deux passé tous les contrôles physiques et le trafic s'est quand même rompu, car la panne se situait dans la façon dont le nouveau commutateur négocie, pas dans son câblage. Un Eth-Trunk vers un serveur ESX qui a cessé complètement de laisser passer le trafic, et un port GE qui s'est discrètement négocié à 10Mbit/s en inondant un compteur de rejets.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les deux cas ci-dessous ont passé les contrôles physiques évidents — câblage, état du port, voyants de lien — et le trafic s'est quand même rompu, car la panne se situait dans le comportement de négociation par défaut, pas dans le câblage.
Remplacer le commutateur d'un autre fournisseur par un Huawei est un projet de routine, jusqu'à ce que le trafic qui fonctionnait parfaitement sur l'ancien boîtier ne passe plus sur le nouveau, ou qu'une liaison censée fonctionner à pleine vitesse se contente discrètement d'une fraction de celle-ci. Aucun des deux cas ici n'implique un câble endommagé ou un VLAN erroné — l'un est une agrégation Eth-Trunk vers un hôte de virtualisation qui n'achève jamais réellement la négociation LACP avec son pair, et l'autre est un port gigabit dont la négociation automatique converge vers 10Mbit/s au lieu de 1000Mbit/s. La même discipline qui détecte ces pannes s'applique que la panne soit dans le comportement d'agrégation ou dans la négociation de couche liaison — voir notre note complémentaire sur
Voici l'arbre de panne dans lequel ces deux cas se divisent, les preuves exactes de display interface / display logbuffer pour chacun, les corrections lacp force-forward et négociation non automatique, et quelques réponses de FAQ tirées de cas de terrain réels.
Les deux pannes se présentent comme une liaison physiquement correcte qui ne transporte pourtant pas le trafic attendu — la différence réside dans ce que display interface montre réellement une fois qu'on regarde.
Placer d'abord le symptôme sur cet arbre évite de reterminer un câble qui n'a jamais été le problème, ou de remplacer un optique sur une liaison qui n'était qu'un désaccord de négociation.
Les légendes du schéma restent en anglais pour la clarté technique.
Les deux branches partagent la même leçon sous-jacente : le boîtier de l'ancien fournisseur avait un comportement par défaut — transfert LACP permissif, ou un résultat de négociation qui atterrissait à pleine vitesse — que le boîtier de remplacement ne reproduit pas automatiquement, et rien au niveau physique ne vous l'indiquera de lui-même.
Un S5720 a remplacé un commutateur Cisco sur un Eth-Trunk en mode LACP connecté à un serveur ESX — tous les contrôles physiques étaient propres, et le serveur restait inaccessible.
La configuration Cisco utilisait channel-group 1 mode active sur les deux interfaces membres, avec le port-channel lui-même en mode trunk — une agrégation LACP active standard. Après le remplacement, le côté S5720 a été configuré avec un Eth-Trunk équivalent en mode lacp, avec les deux mêmes ports physiques ajoutés comme membres.
! Cisco configuration before replacement
interface PORT-CHANNEL1
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active
!
interface GigabitEthernet1/0/3
description pdsesxi01 Port 2
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active
# S5720 configuration after replacement
interface Eth-Trunk1
port link-type trunk
port trunk pvid vlan 4
port trunk allow-pass vlan 2 to 4094
mode lacp
#
interface GigabitEthernet0/0/5
description vmesxi-viewR7-01 Port 1
eth-trunk 1
#
interface GigabitEthernet0/0/6
description vmesxi-viewR7-01 Port 2
eth-trunk 1
# Fix — configured under the Eth-Trunk interface view
[S5720] interface Eth-Trunk 1
[S5720-Eth-Trunk1] lacp force-forwardUn commutateur S a remplacé un équipement NE face à un équipement MSC — après le remplacement, le côté MSC a signalé une lourde perte de paquets, et le compteur de rejets a révélé la vraie histoire.
<HUAWEI> display interface GigabitEthernet 0/0/5
GigabitEthernet0/0/5 current state : DOWN
Line protocol current state : DOWN
Switch Port, PVID : 3957, TPID : 8100(Hex), The Maximum Frame Length is 9216
Port Mode: COMMON COPPER, Transceiver: 1000_BASE_T_SFP
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE // port working in auto-negotiation mode
Output: 127584698 packets, 34122796642 bytes
Unicast: 127511799, Multicast: 1632
Broadcast: 71267, Jumbo: 0
Discard: 127147932, Pause: 0 // massive output discard count
<HUAWEI> display logbuffer
Nov 1 2017 11:17:45 %%01IFNET/4/LINK_STATE(l): The line protocol IP on the
interface GigabitEthernet0/0/5 has entered the DOWN state.
Nov 1 2017 11:15:38 %%01IFNET/4/LINK_STATE(l): The line protocol IP on the
interface GigabitEthernet0/0/5 has entered the UP state.
// repeated Up/Down cycling around the fault window
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display diag-logfile buffer
...Interface GigabitEthernet0/0/5 duplex mode log. (PhyStatus=UP, PreDuplex=FULL,
CurrDuplex=FULL, Speed=10M, Function=IFPDT_ChangePortStatus, Line=909)
// confirms the port actually settled at 10M during the fault window
# Fix
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet 0/0/5
[HUAWEI-GigabitEthernet0/0/5] undo negotiation auto
[HUAWEI-GigabitEthernet0/0/5] speed 1000
// confirm the peer interface is also set to a fixed, matching speed and duplexUn port qui se négocie à la baisse au lieu d'échouer complètement est un symptôme différent d'un port simplement physiquement en panne — si ce que vous observez est un port qui refuse totalement de passer Up plutôt que de se régler à une vitesse basse, voir notre note complémentaire sur
Les deux cas ci-dessus sont des exemples spécifiques d'un schéma plus large à surveiller sur chaque projet de remplacement de fournisseur.
SYMPTÔMELes ports membres d'Eth-Trunk sont physiquement Up sur le nouveau commutateur, la configuration reflète celle de l'ancien fournisseur, et le trafic ne passe toujours pas vers l'appareil pair.
CAUSECertains pairs — le vSwitch d'un hôte de virtualisation en est l'exemple classique — présentent une liaison physiquement Up sans réellement échanger d'unités de données du protocole LACP, et par défaut un commutateur Huawei ne transfère pas sur un membre d'Eth-Trunk tant que la négociation LACP avec le pair n'est pas confirmée.
SOLUTIONConfigurez lacp force-forward sur l'interface Eth-Trunk pour que le commutateur transfère sur les membres physiquement Up même sans négociation LACP confirmée du pair.
SYMPTÔMEUne liaison classée gigabit passe Up sans aucune erreur, mais le débit est bien en dessous des attentes et le compteur de rejets en sortie grimpe régulièrement.
CAUSELa négociation automatique entre les deux extrémités a convergé vers une vitesse commune bien plus basse — 10Mbit/s au lieu de 1000Mbit/s dans ce cas — et les volumes de trafic dimensionnés pour le gigabit dépassent simplement ce qu'une liaison à 10M peut porter, donc l'excédent est rejeté plutôt que la liaison échouant carrément.
SOLUTIONConfirmez la vitesse réellement négociée avec display interface avant de présumer un problème de routage ou d'ACL ; si elle s'est réglée bas, passez les deux extrémités à une vitesse et un duplex fixes et correspondants avec undo negotiation auto plus une commande speed explicite.
SYMPTÔMEUn côté est configuré à vitesse fixe, l'autre reste en négociation automatique, et la liaison se comporte de manière incohérente — parfois Up, parfois non, jamais totalement fiable.
CAUSESi les deux extrémités d'une liaison ne s'accordent pas sur le mode de négociation, le côté configuré à vitesse fixe peut afficher Up ou Down selon les conditions, mais le côté en négociation automatique est pratiquement assuré de finir Down ou mal négocié — le mode de négociation doit correspondre des deux côtés, pas seulement la valeur numérique de vitesse.
SOLUTIONLors du passage d'une liaison en négociation non automatique, configurez les deux extrémités de la même manière, avec une vitesse et un duplex correspondants explicitement définis de chaque côté.
SYMPTÔMELa configuration du commutateur de remplacement est une traduction fidèle, ligne par ligne, de la configuration de l'ancien fournisseur, et quelque chose se comporte quand même différemment une fois que le trafic réel l'atteint.
CAUSEDifférents fournisseurs livrent des comportements par défaut différents précisément dans les situations qui n'apparaissent pas dans un diff de configuration statique — la permissivité du transfert d'un trunk avant confirmation LACP, la gestion des échecs de négociation, quels compteurs s'incrémentent silencieusement plutôt que de déclencher une alarme.
SOLUTIONTraitez chaque projet de remplacement de fournisseur comme un audit de comportement de négociation autant qu'une migration de configuration — vérifiez le comportement de transfert LACP et la vitesse d'interface négociée par rapport au comportement d'exécution réel de l'ancien appareil, pas seulement sa configuration enregistrée.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Cela indique au commutateur de continuer à transférer le trafic sur un port membre d'Eth-Trunk physiquement Up même si la négociation LACP avec le pair n'a jamais été confirmée — ce qui permet à un Eth-Trunk de continuer à fonctionner face à un pair qui n'exécute pas de vrai LACP, comme certains hôtes de virtualisation. Il est sûr de le laisser configuré tant que le comportement de ce pair ne change pas, mais cela signifie que le commutateur n'utilise plus la négociation LACP comme vérification de sécurité contre un véritable mauvais câblage sur ce trunk, donc il vaut la peine de confirmer que le pair est bien ce que vous pensez avant de s'y fier à long terme.
Vérifiez d'abord display interface — un câble ou un optique vraiment défectueux montre généralement des comptes d'erreurs CRC, Symbol ou Jabber en hausse aux côtés de la vitesse basse, tandis qu'un simple désaccord de négociation montre typiquement un compte d'erreurs propre avec le champ Speed rapportant simplement une valeur inférieure à celle attendue. Si les compteurs d'erreurs sont propres, la panne est presque certainement la négociation, pas le support physique.
Les coupables restants les plus courants sont des désaccords de mode de marquage VLAN (la gestion du VLAN natif de trunk diffère sensiblement entre fournisseurs), une règle NAT ou ACL qui se comporte différemment dans l'ordre de transfert du nouvel appareil, et des paramètres MTU ou de trames jumbo qui étaient implicites sur l'ancien appareil mais doivent être configurés explicitement sur le nouveau.
Non — un état Up d'un côté ne confirme pas que l'appairage est sain. Lorsque les deux extrémités ne s'accordent pas sur le mode de négociation, le côté à vitesse fixe peut afficher Up ou Down selon les conditions, tandis que le côté en négociation automatique est pratiquement assuré de finir Down ou mal négocié. Configurez les deux extrémités de la même manière, quel que soit le mode choisi.
mode lacp sur l'interface Eth-Trunk est la configuration LACP dynamique équivalente. L'écart qui se manifeste en pratique n'est pas le mot-clé de mode lui-même — c'est de savoir si le pair à l'autre extrémité de cet Eth-Trunk complète réellement la négociation LACP, ce qui est exactement la condition que lacp force-forward est là pour contourner.
C'est possible, mais la mise en garde plus importante pour les scénarios hyperconvergés en est une autre : les commutateurs de classe campus ne sont généralement pas recommandés pour le trafic d'infrastructure hyperconvergée en premier lieu, car leurs tampons de port sont généralement dimensionnés pour les schémas de trafic de campus plutôt que pour le trafic est-ouest plus en rafales qu'un cluster hyperconvergé génère, et ce décalage peut se manifester par des rejets liés à la congestion même une fois que la négociation LACP et de vitesse sont toutes deux correctement configurées.
Cette note s'appuie sur deux cas de terrain Huawei série S spécifiques — un S5720 remplaçant un commutateur Cisco sur un Eth-Trunk LACP vers un serveur ESX, et un commutateur série S remplaçant un équipement NE face à un équipement MSC — ainsi que sur les preuves display interface / display logbuffer / diag-logfile qui les sous-tendent. Les commandes exactes sont en syntaxe VRP Huawei ; la leçon sous-jacente (un remplacement de fournisseur change le comportement de négociation, pas seulement la syntaxe de configuration) s'applique quels que soient les deux fournisseurs concernés. Elle ne couvre pas en profondeur l'interopérabilité LACP avec des piles non-Huawei, non-Cisco, ni le comportement d'agrégation spécifique au MLAG/empilage.
Dites-nous ce qu'affichent display interface et display logbuffer sur la liaison qui se comporte mal, et s'il s'agit d'un problème d'agrégation ou de vitesse, et nous vous aiderons à l'interpréter.