IPSG s'active proprement sur chaque port d'accès, puis une liaison montante routée s'éteint silencieusement dès que vous l'activez. La cause n'est pas une mauvaise table de liaison — c'est que le transfert de couche 3 réécrit le MAC source du paquet avant même qu'IPSG ne l'examine. Voici comment le prouver avec une capture de paquets, et les pièges connexes issus de la même logique de table de liaison.
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 table de liaison n'est pas fausse. Elle répond simplement à une question posée par IPSG au mauvais endroit du parcours du paquet.
IP Source Guard vérifie l'IP source, le MAC source, le VLAN et l'interface entrante d'un paquet par rapport à une table de liaison avant de décider de le transférer ou de le rejeter. Sur un simple port d'accès de couche 2, cette vérification est triviale — le MAC du client ne change jamais entre le moment où DHCP Snooping l'enregistre et le moment où IPSG examine le paquet suivant. Activez la même fonction sur une interface située en aval d'un transfert de couche 3, et elle peut commencer à rejeter du trafic qui n'a jamais été un problème de sécurité.
C'est l'une des pannes IPSG les plus contre-intuitives, car tout le reste du montage semble correct — la table de liaison a la bonne entrée, aucune ACL n'est impliquée, et l'interface elle-même ne montre aucune erreur. La panne se situe dans un détail que la plupart des ingénieurs ne pensent pas à vérifier avant d'avoir déjà relu la configuration, le câblage et la table DHCP Snooping deux fois chacun. Si la table de liaison que votre appareil construit semble fausse dès le départ, la note de dépannage DHCP Snooping est le point de départ à privilégier — cette note suppose que la table de liaison est déjà correcte et cherche pourquoi IPSG rejette quand même le trafic.
IPSG se comporte de manière identique sur les deux chemins ci-dessous. La seule différence est de savoir si quelque chose entre les deux a réécrit le MAC source du paquet.
Placer votre symptôme du bon côté de ce diagramme vous indique immédiatement si vous êtes face à un problème de table de liaison ou de transfert de couche 3 — et les deux se corrigent de manière totalement différente.
Les légendes du schéma restent en anglais pour la clarté technique.
Le chemin A ne tombe presque jamais en panne, car rien entre le client DHCP et le point de vérification IPSG ne touche jamais le MAC source de la trame. Le chemin B mérite d'être relu deux fois : tout, dans la table de liaison, peut être parfaitement correct et IPSG rejettera quand même le trafic, parce que le paquet réellement examiné par IPSG n'est plus celui envoyé initialement par le client.
Quatre vérifications, dans l'ordre — chacune écarte une cause plausible différente avant d'arriver à la capture de paquets qui le prouve réellement.
Avant de lire les fichiers de capture, confirmez que le blocage est bien dû à IPSG et non à quelque chose en amont.
[Switch] display inter XGigabitEthernet 0/0/1
XGigabitEthernet0/0/1 current state : UP
Discard: 0, Pause: 0
Total Error: 0
// zero drops on the interface counters -- IPSG's own drop is not counted here
<Switch> display dhcp snooping user-bind all
DHCP Dynamic Bind-table:
IP Address MAC Address VSI/VLAN(O/I/P)/(BD-VLAN) Interface Lease
192.168.10.214 5451-1b84-0a1b 10 /-- /-- XGE1/0/0 2024.07.25-21:55
// binding table entry is present and looks correct -- this is not where the fault isC'est la vérification qui prouve réellement la théorie — tout ce qui précède ne fait que restreindre la recherche.
// Capture near the client:
Frame 7: Ethernet II, Src: HuaweiTe_84:0a:18 (54:51:1b:84:0a:18), Dst: Dongguan_0b:3c:eb (3c:c7:86:0b:3c:eb)
Internet Protocol Version 4, Src: 192.168.7.81, Dst: 192.168.10.214
// Capture on the IPSG-enabled interface, same conversation:
Frame 10: Ethernet II, Src: Dongguan_0b:3c:e8 (3c:c7:86:0b:3c:e8), Dst: HuaweiTe_84:0a:18 (54:51:1b:84:0a:18)
Internet Protocol Version 4, Src: 192.168.10.214, Dst: 192.168.7.81
// same flow, but the source MAC seen at this interface is not the binding table's recorded MAC
// -- the L3 hop between the two capture points rewrote itLa solution n'est pas de désactiver la fonction — c'est de lui fournir une entrée de liaison qui correspond au paquet qu'elle verra réellement.
[Switch] user-bind static ip-address 192.168.10.214 mac-address 3cc7-860b-3ceb interface XGigabitEthernet 1/0/1
[Switch] interface XGigabitEthernet 1/0/1
[Switch-XGigabitEthernet1/0/1] ip source check user-bind enable
// the MAC used here is the post-routing MAC actually seen at *this* interface,
// confirmed by the capture -- not the client's original MACUne fois la panne de réécriture du MAC ci-dessus confirmée ou écartée, ces cinq pièges expliquent l'essentiel du reste de ce qui va mal autour d'IPSG et de ses tables de liaison.
SYMPTÔMELe ping et le trafic applicatif traversant un saut routé échouent dès que la vérification de paquets IPSG est activée sur cette interface ; la désactiver rétablit le trafic immédiatement, sans changement d'ACL, de route ou de lien.
CAUSELors du transfert de couche 3, le MAC source de la trame change pour devenir celui de l'interface sortante à chaque saut. La table de liaison dynamique de l'appareil, générée par DHCP Snooping, n'enregistre jamais que le MAC d'origine, inchangé, du client. IPSG compare le MAC source actuel du paquet en direct à cet enregistrement inchangé, de sorte qu'un paquet parfaitement légitime et parfaitement routé échoue à la correspondance et est rejeté.
SOLUTIONAjoutez une entrée de liaison statique sur l'interface routée / activée pour IPSG en utilisant le MAC post-transfert réellement observé sur cette interface, pas le MAC du client d'origine. Compter uniquement sur la table dynamique DHCP Snooping n'est sûr que sur les interfaces où les trames arrivent avec le MAC source intact.
SYMPTÔMEDès qu'une seule liaison statique IP+MAC est ajoutée sur une interface partagée, des utilisateurs sans rapport sur le même port perdent la connectivité — pas seulement le trafic que la liaison devait contrôler.
CAUSEDès qu'une entrée de liaison statique existe sur une interface avec la vérification de paquets IPSG activée, chaque paquet IP arrivant sur cette interface est comparé à la table de liaison — il n'existe pas de mode partiel où seule l'adresse liée est vérifiée et tout le reste passe sans y toucher. Le trafic des utilisateurs qui n'ont jamais reçu d'entrée de liaison n'a rien à quoi correspondre, il est donc traité comme une tentative d'usurpation et rejeté.
SOLUTIONAjoutez soit une entrée de liaison statique pour chaque utilisateur légitime partageant cette interface, soit supprimez complètement les liaisons statiques et comptez sur les liaisons dynamiques DHCP Snooping pour une interface d'accès partagée — mélanger quelques utilisateurs liés avec le reste non lié sur le même port ne fonctionne pas.
SYMPTÔMEIPSG est configuré et apparaît dans la configuration active, mais une interface spécifique ne bloque jamais rien, même un trafic qui devrait clairement échouer à la vérification de la table de liaison.
CAUSEUn port configuré comme port de confiance DHCP Snooping transfère chaque paquet sans aucune comparaison avec la table de liaison — le statut de confiance contourne totalement IPSG sur cette interface, par conception. La configuration semble identique à celle d'une interface IPSG fonctionnelle, car ce n'est pas la commande ip source check elle-même qui contrôle ce comportement.
SOLUTIONVérifiez le rôle de confiance/non-confiance DHCP Snooping du port avant de supposer un problème de table de liaison ou d'ACL — display dhcp snooping user-bind associé à la configuration de confiance de l'interface explique plus de tickets silencieux « IPSG ne fonctionne pas » qu'une mauvaise entrée de liaison.
SYMPTÔMEUn appareil qui laissait passer le trafic normalement depuis des heures ou des jours commence soudainement à rejeter les paquets d'un client dont l'IP et le MAC n'ont pourtant pas changé.
CAUSELes liaisons dynamiques générées par DHCP Snooping suivent le même vieillissement basé sur le bail que le bail DHCP lui-même. Si le client ne renouvelle pas avant l'expiration de l'entrée, et n'envoie pas de nouvelle requête DHCP qui régénérerait la liaison, l'entrée disparaît simplement, et IPSG n'a alors plus rien pour faire correspondre le trafic continu du client.
SOLUTIONConfirmez que l'entrée de la table de liaison est toujours présente avec display dhcp snooping user-bind all avant de dépanner quoi que ce soit d'autre ; si elle a disparu et que le client n'a pas relancé de DHCP, corrigez soit le décalage avec une durée de bail adaptée, soit ajoutez une liaison statique pour les hôtes qui ne peuvent pas être fiables pour renouveler rapidement.
SYMPTÔMEAprès l'ajout d'une liaison statique censée être limitée à un port ou VLAN spécifique, des utilisateurs ailleurs sur le réseau commencent à perdre la connectivité — ou inversement, les utilisateurs que la liaison était censée restreindre continuent de passer librement.
CAUSEUne entrée de liaison statique peut être définie avec n'importe quelle combinaison d'IP, MAC, interface et VLAN, en vue interface ou en vue VLAN — et la portée change complètement selon les champs inclus. Une entrée VLAN+IP sans interface ni MAC restreint uniquement par IP et VLAN, laissant passer n'importe quel MAC ou interface ; une entrée Interface+MAC sans IP fait l'inverse. Se tromper dans la combinaison n'échoue pas bruyamment — cela protège, ou bloque, simplement un ensemble de trafic différent de celui prévu.
SOLUTIONDécidez d'abord de la portée voulue — un utilisateur, un port ou un VLAN — et incluez exactement les champs correspondant à cette portée ; en cas de doute, une entrée Interface+IP+MAC+VLAN est la plus précise et la moins susceptible d'avoir un rayon d'impact non voulu.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Les rejets IPSG ne sont pas comptés dans les statistiques Discard ordinaires de l'interface — celles-ci suivent les rejets physiques et au niveau du buffer, pas ceux basés sur une politique. Un jeu de compteurs d'interface propre est exactement ce à quoi on s'attend avec cette panne, pas une preuve qu'IPSG n'est pas impliqué. Confirmez en activant/désactivant la vérification des paquets et en observant si le symptôme suit.
La table dynamique est générée automatiquement par DHCP Snooping à mesure que les clients louent des adresses, et expire avec le bail DHCP. La table statique est saisie manuellement et n'expire jamais — c'est l'outil adapté pour les hôtes à IP fixe, les hôtes derrière un saut routé où le MAC source change, ou tout appareil qui n'est pas un client DHCP. IPSG vérifie les deux tables ensemble ; il suffit que l'une des deux ait une entrée correspondante pour laisser passer le trafic.
L'adresse MAC que l'interface où IPSG est activé verra réellement sur ce trafic — qui, sur un chemin routé, est le MAC du dernier appareil ayant transféré la trame, pas celui du client d'origine. Confirmez-le avec une capture sur cette interface spécifique plutôt que de supposer qu'il correspond à ce que DHCP Snooping a enregistré en amont.
Vérifiez si ce port est configuré comme port de confiance DHCP Snooping. Les ports de confiance transfèrent tout paquet sans aucune comparaison de table de liaison, par conception — ce n'est pas un bug d'IPSG, c'est le comportement voulu du réglage de confiance, et il est facile d'oublier qu'il a été configuré ainsi des mois plus tard.
Oui, et ils sont évalués indépendamment — IPSG vérifie l'IP/MAC/VLAN/interface source par rapport à la table de liaison, tandis qu'une politique de trafic basée sur ACL correspond selon les champs spécifiés par ses règles. L'un des deux peut rejeter un paquet que l'autre aurait laissé passer, ce qui signifie qu'un ticket « bloqué » sur une interface exécutant les deux fonctions doit voir chacune écartée séparément plutôt que d'être attribué à l'autre par supposition.
C'est exactement sa fonction sur les interfaces d'accès — une paire IP/MAC source usurpée qui ne correspond à rien dans la table de liaison est rejetée, que la table soit apprise dynamiquement ou configurée statiquement. Le mode de défaillance couvert dans cette note est le côté faux positif du même mécanisme : du trafic légitime qui ne correspond plus à la table parce que quelque chose en amont a changé le MAC, pas une véritable tentative d'usurpation.
Cette note s'articule autour de l'implémentation IP Source Guard des commutateurs Huawei série S et de ses tables de liaison basées sur DHCP Snooping, ainsi que des cas de terrain sous-jacents. Si votre couche d'accès est d'un autre fournisseur, les commandes exactes changent, mais la logique sous-jacente — une table de liaison construite en bordure d'accès, et une vérification de MAC source qui ne voit pas au-delà d'un saut de routage — s'applique directement. Elle ne couvre pas spécifiquement IPv6 Source Guard, ni les conceptions basées sur SAVI d'autres familles de normes.
Dites-nous si le chemin concerné est un simple port d'accès ou se trouve derrière un saut routé, plus la sortie de display dhcp snooping user-bind, et nous vous aiderons à l'analyser.