L'écho à un bras BFD ne teste rien d'autre que le retour de votre propre paquet — et si l'IP source de ce paquet correspond par défaut à son IP de destination, une liste confirmée de commutateurs Huawei le rejette simplement, sans erreur, sans journal. La règle de transfert qui en est à l'origine, les modèles de commutateurs concernés, la solution par adresse Loopback, et un cas où une fonctionnalité totalement différente a produit exactement le même symptôme.
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
L'écho à un bras ne teste pas du tout le pair — il teste si votre propre paquet d'écho peut survivre à un aller-retour à travers lui. C'est le détail que presque personne ne lit avant qu'une session refuse de monter.
L'écho à un bras BFD existe pour exactement une situation : le pair ne supporte pas le BFD, ou ne l'a pas activé. Au lieu d'un véritable échange BFD bidirectionnel, l'appareil local construit un paquet UDP adressé à l'IP de sa propre interface sortante et demande simplement au pair de le renvoyer directement — un test en boucle, pas une négociation. Si l'IP source du paquet n'est pas explicitement configurée, elle prend par défaut la même valeur que cette IP de destination, ce qui en fait un paquet à source et destination identiques. Une longue liste d'équipements réseau, commutateurs compris, traitent cette forme de paquet comme anormale et la rejettent purement et simplement — pas d'erreur, pas de journal, rien d'autre qu'une session qui reste silencieusement en panne.
Voici comment le paquet est réellement construit, trois cas de terrain réels — une interconnexion simple restée en panne dès le premier jour, la liste confirmée des modèles où ce comportement de transfert apparaît, et un cas où une fonctionnalité totalement différente (trafic de relais DHCPv6 déclenchant un limiteur de débit) a produit un battement du BFD qui ressemblait exactement à une véritable panne de lien — ainsi que les réponses de FAQ qui reviennent chaque fois que ces tickets sont discutés.
Une session d'écho à un bras qui ne monte jamais et une qui monte puis oscille sont deux pannes différentes avec deux causes racines différentes — ne cherchez pas la même solution pour les deux.
Placer d'abord le symptôme sur cet arbre indique si vous êtes face à une règle de transfert de paquets ou à une fonctionnalité sans rapport empruntant le symptôme du BFD.
Les légendes du schéma restent en anglais pour la clarté technique.
Les deux branches produisent le même symptôme final — BFD en panne — mais une seule d'entre elles est réellement un problème de BFD. La branche de droite est une fonctionnalité de protection du plan de contrôle réagissant à un trafic sans rapport, et relire la configuration BFD ne la corrigera jamais.
Trois cas de terrain réels — les champs exacts du paquet d'écho à un bras, pourquoi il est rejeté, et un cas où le BFD a oscillé pour une raison qui n'avait rien à voir avec le BFD.
Avant de traquer la panne, il vaut la peine de savoir exactement ce que l'appareil local place dans le paquet — la règle à l'origine de tout cela se trouve dans quatre champs.
#
interface Vlanif1
ip address 192.168.1.14 255.255.255.0
#
bfd atob bind peer-ip 192.168.1.2 interface Vlanif1 source-ip 192.168.1.14 one-arm-echo
discriminator local 1
min-echo-rx-interval 100
commit
#
// source-ip 192.168.1.14 is identical to the local VLANIF address -> same-source-same-destination
// the peer receives this shape of packet and drops it -> session never comes UpNE8000 et un S5720-SI interconnectés directement ; le côté NE8000 signalait la session BFD en panne, sans jamais se rétablir.
[HUAWEI-bfd-session-ato] display this
#
bfd ato bind peer-ip 10.1.1.1 interface Vlanif100 source-ip 10.1.1.2 one-arm-echo
discriminator local 1
min-echo-rx-interval 100
commit
#
[HUAWEI-bfd-session-ato] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
1 - 10.1.1.1 Down S_IP_IF Vlanif100
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 0/1
// change source-ip to a Loopback address instead of an interface-facing address:
[HUAWEI-bfd-session-ato_1] display this
#
bfd ato_1 bind peer-ip 10.1.1.1 interface Vlanif100 source-ip 1.1.1.1 one-arm-echo
discriminator local 2
min-echo-rx-interval 100
commit
#
[HUAWEI] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
2 - 10.1.1.1 Up S_IP_IF Vlanif100
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0Deux commutateurs directement connectés, l'un exécutant l'écho à un bras et l'autre transférant simplement le trafic de couche 3 normalement — la session ne s'est jamais établie du tout.
bfd session-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ]
interface interface-type interface-number [ source-ip ip-address ] one-arm-echo
// source-ip is technically optional, but leaving it unset means it defaults to the
// outbound interface's own IP -> a same-source-same-destination packet -> dropped
// on the confirmed model list above, and on any device with the anti-attack rule enabledUn S12700E exécutant DHCP Relay avait une session BFD parfaitement normale avec son pair — jusqu'à ce qu'elle commence à osciller entre panne et remise en service sans aucun événement de lien derrière.
Dec 25 2023 15:03:18 S12700-1 %%01BFD/4/STACHG_TODWN(l)[615983]:BFD session changed to
Down. (Discriminator=8235, Diagnostic=DetectDown, Applications=OSPF, BindInterfaceName=Eth-Trunk99)
Dec 25 2023 15:03:19 S12700-1 %%01BFD/4/STACHG_TOUP(l)[615986]:BFD session changed to Up.
<HUAWEI> display arp
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE
------------------------------------------------------------------------------
10.82.192.2 00e0-fc6a-1111 10 D-0/0 Eth-Trunk99
// ARP entry aged -> brief loss of L2 reachability to the BFD peer
Dec 25 2023 15:11:40 S12700-1 %%01DEFD/6/HOSTCAR_DROPPKT(l)[616002]:Rate of packets to
cpu exceeded the HOSTCAR limit. (CarID=5266, PacketInfo=The growth rate of top 3 packets
is: MAC1=00e0-fc6a-1111, Protocol1=dhcpv6-request, MAC2=00e0-fc6a-1111, Protocol2=nd,
MAC3=00e0-fc6a-1111, Protocol3=arp)
// DHCPv6 Request flood from the same MAC tripped the 10pps user-level CAR limit,
// which then dropped ARP packets from that MAC too -> BFD detect timeout -> flapUne fois que l'arbre ci-dessus vous a indiqué s'il s'agit d'une règle de transfert ou d'une fonctionnalité sans rapport, ces cinq points expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMELa session d'écho à un bras n'atteint tout simplement jamais l'état actif. Aucune erreur n'est journalisée d'un côté ou de l'autre — le paquet ne revient tout simplement pas.
CAUSESi source-ip n'est pas explicitement configuré sur la commande bfd bind, il prend par défaut la même adresse que l'IP de destination (l'IP propre de l'interface sortante locale). De nombreux appareils, en recevant un paquet dont l'IP source et de destination sont identiques, le traitent comme anormal et le rejettent — la même logique de transfert qui protège contre certains schémas d'usurpation intercepte aussi ce paquet d'écho pourtant parfaitement légitime.
SOLUTIONConfigurez toujours source-ip explicitement à une adresse différente de l'IP propre de l'interface sortante — ne le laissez jamais par défaut.
SYMPTÔMELa même configuration exacte d'écho à un bras fonctionne sur un modèle de commutateur et reste en panne sur un autre.
CAUSEÀ partir de V200R022C00, une liste spécifique de modèles rejette purement et simplement les paquets avec IP source et de destination identiques : S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S — et le S5720-SI confirmé séparément dans le Cas 1. Par ailleurs, sur n'importe quel modèle, activer ip anti-attack source-ip equals destination-ip drop produit exactement le même rejet, quel que soit le commutateur.
SOLUTIONTraitez cela comme un fait du plan de transfert à vérifier sur quel que soit le modèle situé à l'autre bout d'une session d'écho à un bras, pas comme un cas limite — et vérifiez si la commande anti-attack est activée même sur des modèles non listés ci-dessus.
undo ip anti-attack source-ip equals destination-ip drop
// stops the device from dropping same-source-same-destination packets outrightSYMPTÔMELa session est en panne ; source-ip est techniquement configuré, mais il se trouve qu'il correspond quand même à l'IP propre de l'interface sortante.
CAUSEConfigurer source-ip à la même valeur que l'interface à laquelle il est lié a exactement le même effet que de le laisser non défini — cela produit toujours un paquet à source et destination identiques. La solution n'est pas « configurer source-ip », c'est « configurer source-ip à une valeur véritablement différente ».
SOLUTIONUtilisez l'adresse d'une interface Loopback comme source-ip chaque fois qu'elle est disponible — elle est stable, non ambiguë, et garantie de ne pas entrer en collision avec l'adresse propre de l'interface sortante.
SYMPTÔMEsource-ip est correctement défini sur une adresse différente, le problème source-destination identique a disparu, mais la session est toujours en panne.
CAUSESi l'appareil pair a URPF activé, il vérifie s'il dispose d'une route valide de retour vers l'IP source du paquet avant de l'accepter. Une adresse Loopback utilisée comme source-ip vers laquelle le pair n'a aucune route est rejetée par URPF — un mode de panne complètement différent qui paraît identique de l'extérieur.
SOLUTIONAssurez-vous que le pair dispose d'une route valide et joignable vers l'adresse configurée comme source-ip avant de supposer que la seule solution Loopback suffira.
SYMPTÔMELe BFD oscille entre panne et remise en service avec Diagnostic=DetectDown, mais il n'y a aucun événement de lien physique réel, aucune oscillation d'interface, ni de changement de configuration à proximité de l'horodatage.
CAUSEUne rafale d'un protocole particulier provenant d'une seule MAC source — DHCPv6 Request dans ce cas — peut déclencher la limite de débit CAR au niveau utilisateur de l'interface (HOSTCAR), qui rejette alors aussi d'autres paquets protocolaires provenant de cette même MAC, y compris l'ARP. L'expiration ARP qui en résulte rompt la joignabilité de couche 2 vers le pair BFD juste assez longtemps pour que le propre temporisateur de détection du BFD expire.
SOLUTIONLorsque le BFD oscille sans événement de lien réel, vérifiez les entrées de journal HOSTCAR_DROPPKT autour du même horodatage avant de supposer qu'il s'agit d'un problème de BFD ou de couche physique — désactiver la limitation de débit au niveau utilisateur inutile sur les interfaces orientées réseau est la solution standard une fois ce schéma confirmé.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Le BFD normal est un véritable protocole bidirectionnel — les deux côtés exécutent le BFD, échangent des paquets de contrôle, et suivent indépendamment l'état de la session. L'écho à un bras n'est pas une négociation du tout : seul l'appareil local exécute le BFD ; il envoie un paquet UDP adressé à l'IP de sa propre interface et s'attend simplement à ce que le pair le renvoie directement, sans modification. Il existe spécifiquement pour les pairs qui ne supportent pas le BFD, ou ne l'ont pas activé.
Oui, toujours. Il n'est facultatif qu'au sens où la commande accepte de l'omettre — en pratique, l'omettre signifie que l'IP source prend par défaut la valeur de l'IP de destination, ce qui est exactement la forme source-destination identique rejetée sur une liste confirmée de modèles de commutateurs. Configurez toujours source-ip explicitement à une adresse différente, idéalement une Loopback.
Non. L'écho à un bras est une solution de contournement pour les pairs qui ne peuvent pas exécuter un véritable BFD. Si les deux côtés le supportent, configurez plutôt une session BFD bidirectionnelle standard (mode asynchrone, avec ou sans fonction d'écho) — elle offre une véritable détection bidirectionnelle plutôt qu'un test en boucle unilatéral.
Vérifiez d'abord display arp pour l'entrée du pair — si elle a expiré juste avant l'événement de panne, quelque chose a brièvement rompu la joignabilité de couche 2. Puis vérifiez les journaux autour de cet horodatage exact pour HOSTCAR_DROPPKT ou des événements de rejet de protection CPU similaires ; une rafale d'un autre protocole depuis la même MAC source déclenchant un limiteur de débit est une cause courante qui n'a rien à voir avec le BFD ou le lien physique lui-même.
Ceci est attendu, pas une panne. Lorsqu'une session BFD tombe en panne, si l'extrémité distante envoie un paquet BFD signalant un état actif avant d'avoir reçu la notification de panne du côté local, le côté local ignore délibérément ce rapport actif périmé et reste en panne plutôt que de se rétablir immédiatement dessus — cela évite l'oscillation d'état. Le délai supplémentaire est cette marge de sécurité, pas un dysfonctionnement.
Cette note s'appuie sur des déploiements BFD à écho à un bras sur commutateurs Huawei série S et routeurs série NE, en utilisant les commandes display bfd session / display arp montrées ci-dessus. La liste confirmée des modèles et le comportement de rejet reflètent des tests de l'époque V200R022C00 — vérifiez toujours directement la gestion source-destination identique sur votre propre version de firmware et modèle, car la liste de compatibilité de Huawei peut évoluer selon les versions. Elle ne couvre pas le BFD pour les scénarios underlay VXLAN/EVPN, ni le BFD multi-saut en profondeur.
Dites-nous le modèle du commutateur et votre commande bfd bind, avec la sortie de display bfd session / display arp, et nous vous aiderons à l'interpréter.