Sur un cluster de cœur de campus S7706, une commande pensée comme un recours sur site — reboot chassis 1 — a déconnecté d'un coup tous les AP en aval. Voici la chronologie médico-légale, les commandes exactes qui l'ont reconstituée, le mécanisme de basculement d'AC « rétrograder puis repromouvoir » derrière la suppression par lot, et le changement de câblage qui a arrêté la récidive.
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
La paire d'AC, les radios des AP et les tunnels CAPWAP n'ont jamais été en cause — le déclencheur était à deux sauts de là, dans un redémarrage de commutateur.
Sur un cluster S7706 V200R024C00SPC500 servant de cœur de campus, un ingénieur a exécuté reboot chassis 1 — une commande documentée de recours pour redémarrer un châssis d'un système empilé/en cluster lorsqu'un cycle d'alimentation physique sur site n'est pas envisageable. Tous les AP en aval sont tombés d'un coup, et les journaux ont enregistré une vague d'événements d'interface Down. Rien du côté Wi-Fi n'avait en réalité échoué.
Voici la suite : la chronologie médico-légale reconstituée à partir de display reset-reason et display ap offline-record, le mécanisme — un blip VRRP de rétrogradation puis repromotion qui déclenche une suppression par lot des sessions AP — et le changement de topologie validé en laboratoire qui empêche la récidive sur la même commande de redémarrage.
Trois sources de journaux distinctes, recoupées, racontent une histoire qu'aucune d'entre elles ne raconte seule.
Les légendes du schéma restent en anglais pour la clarté technique.
Lue séparément, chaque source de journal ne raconte qu'une partie de l'histoire — reset-reason montre un événement propre, les journaux d'interface montrent une séquence échelonnée, et ap offline-record montre une suppression par lot qu'aucune des deux autres n'explique à elle seule.
Aucune de ces trois sorties, seule, n'explique une déconnexion massive d'AP — les recouper le fait.
Sur le maître S7706, cela montre exactement un événement pertinent : la carte d'interface qui a redémarré, et pourquoi.
<HUAWEI> display reset-reason
... ...
Info: The LPU chassis[1] board[1] does not have reset records.
Info: The LPU chassis[1] board[2] does not have reset records.
Info: The LPU chassis[1] board[3] does not have reset records.
The LPU chassis[1] board[4]'s reset time is 1 in total. Detailed information:
-- 1. 2025/03/07 03:21:36, Reset No.: 1
Reason: Reset for reboot chassis command
Info: The LPU chassis[1] board[5] does not have reset records.
Info: The LPU chassis[1] board[6] does not have reset records.
Info: The MPU chassis[1] board[8]'s reset time is 2 in total. Detailed information:
-- 1. 2025/03/07 04:34:02, Reset No.: 2
Reason: Reset for chassis combine
-- 2. 2025/02/28 16:53:02, Reset No.: 1
Reason: Reset for chassis combineC'est l'élément facile à mal interpréter : un événement propre « Reset for reboot chassis command » donne l'impression de prouver que le basculement l'était tout autant. Cela ne prouve rien côté AC — reset-reason n'enregistre que les redémarrages de châssis et de cartes, pas les transitions d'état VRRP.
Le propre journal du châssis de secours est explicite : ses interfaces physiques n'ont jamais changé d'état — ce qu'il consignait, c'était celui du pair.
Mar 7 2025 03:21:45+08:00 TCLY-02G07-201.253 %%01IFPDT/4/IF_STATE(I)[3125]:Interface
XGigabitEthernet1/6/0/12 has turned into DOWN state.
Mar 7 2025 03:21:46+08:00 TCLY-02G07-201.253 %%01IFPDT/4/IF_STATE(I)[3128]:Interface
XGigabitEthernet1/6/0/24 has turned into DOWN state.
// recorded on the standby's log, but this is the master's interface state, propagated
// over the inter-chassis link -- the standby's own physical port state never went Down
Mar 7 2025 03:21:50+08:00 TCLY-02G07-201.253 %%01TRUNK/S/MEMBER_UP(I)[3191]:The status of the
trunk member went Up.(TrunkName=Eth-Trunk12, PortName=XGigabitEthernet2/6/0/1)
// Eth-Trunk members recorded "went Up" as an interface-state refresh once the
// standby had taken over -- not a sign the physical link had ever actually droppedC'est la commande qui explique réellement la déconnexion massive — le champ de raison indique « Batch delete », pas une panne radio ou de heartbeat.
<HUAWEI> display ap offline-record all
... ...
MAC Last offline time Reason
------------------------------------------------------------------------------
0425-c58b-ea80 2025-03-07/04:24:10 Heartbeat packet transmission for the CAPWAP control tunnel
between the AC and AP times out.
0425-c58b-ea80 2025-03-07/03:15:36 Batch delete
04bd-702b-8aa0 2025-03-07/04:24:10 Heartbeat packet transmission for the CAPWAP control tunnel
between the AC and AP times out.
... ...Deux codes de raison différents sur le même AP racontent deux parties différentes de l'histoire : « Batch delete » est la signature de l'événement de rétrogradation puis repromotion côté AC décrit ci-dessous ; les entrées de timeout de heartbeat CAPWAP sont la conséquence ordinaire de la même fenêtre d'instabilité d'interface en amont.
reboot chassis 1 est un recours de secours, pas un cycle d'alimentation propre — et c'est exactement la différence entre les deux qui a causé cela.
reboot chassis 1 est documentée comme une commande de recours, destinée spécifiquement aux situations où le châssis ne peut pas subir de cycle d'alimentation sur site, et elle comporte ses propres restrictions d'usage. À son exécution, le châssis cible notifie d'abord son pair que la pile/le cluster se scinde, puis redémarre ses cartes d'interface une par une — elle ne peut pas garantir que tout le trafic s'arrête simultanément comme le ferait un vrai cycle d'alimentation.
Dans cette topologie, le chemin des annonces VRRP passe par AC-maître — S7706-maître — S7706-secours — AC-secours. Comme les cartes d'interface du S7706 maître tombent une par une pendant le redémarrage échelonné, plutôt que d'un coup, les paquets hello VRRP continuent de fuiter par intermittence au lieu de s'arrêter proprement dès le début du redémarrage. L'AC de secours voit les hello se rompre, se promeut en Master — puis, presque immédiatement, voit les hello reprendre et rétrograde en Backup, avant de se promouvoir à nouveau en Master une fois le basculement réellement terminé. C'est précisément cette transition de rétrogradation juste après une fausse promotion qui déclenche une suppression par lot de toutes les sessions AP que l'AC de secours avait commencé à adopter.
Cette même discipline — ne pas faire confiance à un statut de haut niveau propre avant d'avoir vérifié si un processus du plan de contrôle a réellement eu un raté en dessous — est celle que nous détaillons dans notre note de dépannage sur la charge CPU élevée des commutateurs : un équipement peut sembler structurellement correct en surface pendant qu'un bref événement du plan de contrôle en dessous fait les vrais dégâts.
Sous tout cela se trouve une lacune de topologie : le réseau tel que construit n'a pas de liaison redondante entre AC-maître/S7706-secours ou AC-secours/S7706-maître, donc le chemin des hello VRRP n'a qu'une seule route par laquelle fuiter — et cette route passe directement par le châssis en cours de redémarrage.
La sortie de reset-reason semblait parfaitement normale. C'est exactement le piège.
SYMPTÔMEUn ingénieur exécute reboot chassis 1 sur un S7706 en cluster en production, s'attendant au même comportement qu'un redémarrage complet de l'équipement — au lieu de cela, tous les AP en aval tombent.
CAUSELa documentation source confirme que reboot chassis 1 est une commande de recours destinée uniquement aux situations où un cycle d'alimentation physique du châssis sur site n'est pas possible, et elle comporte ses propres restrictions d'usage — sa séquence de redémarrage échelonnée, carte par carte, n'équivaut pas à un vrai cycle d'alimentation, qui coupe tout le trafic simultanément.
CORRECTIONPrivilégiez un vrai cycle d'alimentation, ou un redémarrage complet de l'équipement plutôt qu'un redémarrage d'un seul châssis, dans une fenêtre de changement adéquate chaque fois que l'accès au site le permet. Traitez reboot chassis N comme un dernier recours avec son propre profil de risque distinct, pas comme un substitut de routine.
SYMPTÔMEdisplay reset-reason montre exactement un événement bien net — « Reset for reboot chassis command » — pourtant la paire d'AC a oscillé Backup → Master → Backup → Master pendant la même fenêtre.
CAUSEComme les cartes d'interface du S7706 principal redémarrent séquentiellement plutôt qu'ensemble, les annonces VRRP sur le chemin AC-maître—S7706-maître—S7706-secours—AC-secours continuent de fuiter par intermittence pendant le redémarrage au lieu de s'arrêter dès qu'il commence — et reset-reason n'a aucune visibilité sur l'état VRRP.
CORRECTIONNe considérez pas une entrée reset-reason propre comme la preuve que tout le basculement l'était aussi — recoupez display ap offline-record all et l'historique de transition VRRP propre à l'AC de secours pour la même fenêtre horaire avant de clore l'incident.
SYMPTÔMEdisplay ap offline-record all indique « Batch delete » comme raison de l'événement de déconnexion massive, et non un timeout de heartbeat ou une panne radio.
CAUSEL'état VRRP de la paire d'AC ne bascule pas qu'une fois — il rétrograde en Backup presque immédiatement après s'être promu en Master, à cause des hello qui fuitent décrits plus haut — et c'est précisément cette transition de rétrogradation juste après promotion qui déclenche une suppression par lot de toutes les sessions AP que l'AC de secours avait commencé à adopter.
CORRECTIONLors du dépannage d'un événement de déconnexion massive d'AP sur une paire d'AC redondante, récupérez l'historique complet des transitions VRRP, pas seulement l'état final — un basculement propre unique et un basculement qui bat en cloche se ressemblent si vous ne vérifiez que où la machine à états a fini.
SYMPTÔMELa reproduction en laboratoire confirme la panne sur la topologie documentée, et la même commande de redémarrage cesse de la reproduire une fois qu'une liaison supplémentaire est ajoutée de chaque côté.
CAUSELa topologie telle que déployée n'a pas de chemin redondant entre AC-maître/S7706-secours et AC-secours/S7706-maître — les hello VRRP n'ont qu'une seule route par laquelle fuiter pendant un redémarrage, et cette route passe directement par le châssis en cours de redémarrage.
CORRECTIONAjoutez une liaison chacune entre AC-maître—S7706-secours et AC-secours—S7706-maître, les deux AC et les deux châssis S7706 étant connectés via une agrégation Eth-Trunk de chaque côté. Vérifié en laboratoire : la même commande reboot chassis ne fait plus tomber aucun AP une fois ces liaisons en place.
Quatre changements, classés selon leur rapport direct avec ce qui s'est réellement passé ici.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Ces événements Down dans le journal du secours concernent l'état d'interface du pair (le maître), propagé au secours via la liaison inter-châssis — pas l'état de port physique propre au secours. Le cas source est explicite : l'état physique de l'interface propre du châssis de secours n'a jamais changé pendant tout l'incident.
Non. Elle est documentée comme une commande de secours spécifiquement pour quand on ne peut pas couper l'alimentation du châssis sur site, et elle se comporte différemment — redémarrant les cartes d'interface une par une plutôt que de couper tout le trafic d'un coup. La recommandation source est explicite : ce problème exact ne se produirait pas sous un vrai redémarrage par coupure d'alimentation.
Le déclencheur de suppression par lot décrit ici est spécifique au fait qu'une paire d'AC voit son état VRRP osciller Backup → Master → Backup → Master pendant le redémarrage échelonné d'un pair. Une conception à AC unique n'a pas du tout ce chemin de basculement — mais elle perd entièrement la redondance à la place, ce qui est un risque différent, pas un risque moindre.
Non. reset-reason n'enregistre que les redémarrages de châssis et de cartes, pas les transitions d'état VRRP sur la paire d'AC. Un seul événement de reset propre côté commutateur est parfaitement compatible avec un basculement qui bat en cloche côté AC — cette transition n'apparaîtra tout simplement pas du tout dans la sortie de cette commande.
La reproduction en laboratoire après l'ajout des liaisons n'a pas reproduit la chute d'AP sous la même commande de redémarrage, car les liaisons croisées suppriment l'unique chemin par lequel les hello VRRP pouvaient fuiter. Le comportement sous-jacent de redémarrage échelonné, carte par carte, de reboot chassis N reste inchangé — la correction supprime le chemin de fuite, pas le séquencement interne du redémarrage.
Ce post-mortem s'appuie sur un seul cas documenté S7706 V200R024C00SPC500 dans le propre manuel de maintenance des commutateurs de campus Huawei série S. D'autres modèles de châssis, versions logicielles, ou fournisseurs d'AC WLAN peuvent utiliser des minuteurs de détection de basculement et des déclencheurs de suppression par lot différents — considérez le mécanisme de rétrogradation puis repromotion décrit ici comme un schéma à vérifier, pas une correspondance garantie pour tout événement de déconnexion massive d'AP.
Envoyez-nous vos sorties de display reset-reason et display ap offline-record all, plus la topologie de la paire d'AC — nous vous aiderons à déterminer s'il s'agit du même mécanisme.