IPSG comes up clean on every access port, then a routed uplink goes silently dead the moment you enable it. The cause isn't a bad binding table — it's that Layer 3 forwarding rewrites the packet's source MAC before IPSG ever sees it. Here's how to prove it with a packet capture, and the related gotchas that come from the same binding-table logic.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The binding table isn't wrong. It's just answering a question IPSG asked at the wrong point in the packet's journey.
IP Source Guard checks a packet's source IP, source MAC, VLAN and inbound interface against a binding table before deciding whether to forward or drop it. On a plain Layer 2 access port, that check is trivial — the client's MAC never changes between the moment DHCP Snooping records it and the moment IPSG inspects the next packet. Enable the same feature on an interface that sits downstream of Layer 3 forwarding, and it can start dropping traffic that was never a security problem at all.
This is one of the more counterintuitive IPSG failures because everything else about the setup looks correct — the binding table has the right entry, no ACL is involved, and the interface itself shows no errors. The fault sits in a detail most engineers don't think to check until they've already re-read the configuration, the cabling and the DHCP Snooping table twice each. If the binding table your device is building looks wrong to begin with, the DHCP Snooping troubleshooting note is the place to start instead — this note assumes the binding table is already correct and asks why IPSG still drops the traffic.
IPSG behaves identically on both paths below. The only difference is whether something in between rewrote the packet's source MAC.
Placing your symptom on the correct side of this diagram tells you immediately whether you're looking at a binding-table problem or a Layer-3-forwarding problem — and the two are fixed in completely different ways.
Diagram labels are kept in English for engineering clarity.
Path A almost never breaks, because nothing between the DHCP client and the IPSG check point ever touches the frame's source MAC. Path B is the one worth reading twice: everything about the binding table can be perfectly correct and IPSG will still drop the traffic, because the packet IPSG actually inspects is no longer the packet the client originally sent.
Four checks, in order — each one rules out a different plausible cause before you get to the packet capture that actually proves it.
Before reading capture files, confirm the block really is IPSG and not something upstream of it.
[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 isThis is the check that actually proves the theory — everything before it only narrows the search.
// 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 itThe fix isn't to disable the feature — it's to give it a binding entry that matches the packet it will actually see.
[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 MACOnce the MAC-rewrite fault above is ruled in or out, these five account for most of the rest of what goes wrong around IPSG and its binding tables.
SYMPTOMPing and application traffic across a routed hop fail the moment IPSG's packet check is enabled on that interface; disabling the check restores traffic immediately, with no ACL, route or link changes involved.
CAUSEDuring Layer 3 forwarding, the frame's source MAC changes to the outgoing interface's own MAC at every hop. The device's dynamic binding table, generated by DHCP Snooping, only ever records the client's original, unchanged MAC. IPSG compares the live packet's current source MAC against that unchanged record, so a perfectly legitimate, perfectly routed packet fails the match and gets dropped.
FIXAdd a static binding entry on the routed / IPSG-enabled interface using the post-forwarding MAC actually seen at that interface, not the originating client's MAC. Relying on the dynamic DHCP Snooping table alone is only safe on interfaces where frames arrive with the source MAC untouched.
SYMPTOMAs soon as a single static IP+MAC binding is added on a shared interface, unrelated users on the same port lose connectivity — not just the traffic the binding was meant to control.
CAUSEOnce any static binding entry exists on an interface with IPSG's packet check enabled, every IP packet arriving on that interface is matched against the binding table — there's no partial mode where only the bound address is checked and everything else passes through untouched. Traffic from users who were never given a binding entry has nothing to match, so it's treated the same as a spoofing attempt and dropped.
FIXEither add a static binding entry for every legitimate user sharing that interface, or remove static bindings entirely and rely on dynamic DHCP Snooping bindings for a shared access interface — mixing a few bound users with the rest left unbound on the same port doesn't work.
SYMPTOMIPSG is configured and shows up in the running configuration, but one specific interface never blocks anything, even traffic that should clearly fail the binding table check.
CAUSEA port configured as a DHCP Snooping trusted port forwards every packet without any binding-table comparison at all — trusted status bypasses IPSG on that interface completely, by design. The configuration looks identical to a working IPSG interface because the ip source check command itself isn't what controls this behavior.
FIXCheck the port's trusted/untrusted DHCP Snooping role before assuming a binding table or ACL problem — display dhcp snooping user-bind plus the interface's trust configuration explain more silent "IPSG isn't working" tickets than a bad binding entry ever does.
SYMPTOMA device that has been passing traffic normally for hours or days suddenly starts dropping packets from a client that hasn't changed its IP or MAC address at all.
CAUSEDynamic bindings generated by DHCP Snooping carry the same lease-based aging as the DHCP lease itself. If the client doesn't renew before the entry ages out, and doesn't send a fresh DHCP request that would regenerate the binding, the entry simply disappears, and IPSG then has nothing left to match the client's continuing traffic against.
FIXConfirm the binding table entry is still present with display dhcp snooping user-bind all before troubleshooting anything else; if it's gone and the client hasn't re-run DHCP, either address the mismatch with an appropriate lease time or add a static binding for hosts that can't be relied on to renew promptly.
SYMPTOMAfter adding a static binding meant to scope one specific port or VLAN, users elsewhere on the network start losing connectivity — or conversely, users the binding was meant to restrict still pass traffic freely.
CAUSEA static binding entry can be defined with any combination of IP, MAC, interface and VLAN, in either an interface view or a VLAN view — and the scope changes completely depending on which fields are included. A VLAN+IP entry with no interface or MAC restricts by IP and VLAN alone, letting any MAC or interface through; an Interface+MAC entry with no IP does the reverse. Getting the combination wrong doesn't fail loudly — it just protects, or blocks, a different set of traffic than intended.
FIXDecide the intended scope first — one user, one port, or one VLAN — and include exactly the fields that match that scope; when in doubt, an Interface+IP+MAC+VLAN entry is the most specific and least likely to have an unintended blast radius.
Pulled straight from the field — the ones worth having an answer ready for.
IPSG drops aren't counted in the interface's ordinary Discard statistics — those track physical and buffer-level drops, not policy-based ones. A clean interface counter set is exactly what you'd expect from this fault, not evidence that IPSG isn't involved. Confirm by toggling the packet check on and off and watching whether the symptom follows it.
The dynamic table is generated automatically by DHCP Snooping as clients lease addresses, and it ages out with the DHCP lease. The static table is entered by hand and never ages — it's the right tool for hosts with fixed IP addresses, hosts behind a routed hop where the source MAC changes, or any device that isn't a DHCP client at all. IPSG checks both tables together; either one having a matching entry is enough to pass the traffic.
The MAC address the IPSG-enabled interface itself will see on that traffic — which, on a routed path, is the MAC of whatever device last forwarded the frame, not the originating client's own MAC. Confirm it with a capture at that specific interface rather than assuming it matches what DHCP Snooping recorded further upstream.
Check whether that port is configured as a DHCP Snooping trusted port. Trusted ports forward every packet without any binding-table comparison, by design — it's not a bug in IPSG, it's the intended behavior of the trust setting, and it's easy to forget it was configured that way months after the fact.
Yes, and they're evaluated independently — IPSG checks source IP/MAC/VLAN/interface against the binding table, while an ACL-based traffic policy matches on whatever fields its rules specify. Either one can drop a packet the other would have passed, which means a "blocked" ticket on an interface running both features needs each one ruled out separately rather than assumed to be the other.
That's exactly its intended job on access interfaces — a spoofed source IP/MAC pair that doesn't match anything in the binding table gets dropped, whether the table is dynamically learned or statically configured. The failure mode covered in this note is the false-positive side of the same mechanism: legitimate traffic that no longer matches the table because something upstream changed the MAC, not an actual spoofing attempt.
This note is built around the Huawei S-series switch's IP Source Guard implementation and its DHCP Snooping-based binding tables, plus the field cases behind them. If your access layer is a different vendor, the exact commands change, but the underlying logic — a binding table built at the access edge, and a source-MAC check that can't see past a routing hop — carries over directly. It doesn't cover IPv6 Source Guard specifically, or SAVI-based designs in other standards families.
Tell us whether the affected path is a plain access port or sits behind a routed hop, plus the display dhcp snooping user-bind output, and we'll help you read it.