O IPSG sobe limpo em cada porta de acesso, e então um uplink roteado morre silenciosamente assim que você o habilita. A causa não é uma tabela de vínculo incorreta — é que o encaminhamento de camada 3 reescreve o MAC de origem do pacote antes mesmo do IPSG examiná-lo. Veja como provar isso com uma captura de pacotes, e as armadilhas relacionadas que vêm da mesma lógica de tabela de vínculo.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
A tabela de vínculo não está errada. Ela apenas responde a uma pergunta que o IPSG fez no ponto errado da jornada do pacote.
O IP Source Guard verifica o IP de origem, o MAC de origem, a VLAN e a interface de entrada de um pacote em relação a uma tabela de vínculo antes de decidir se encaminha ou descarta. Em uma porta de acesso de camada 2 simples, essa verificação é trivial — o MAC do cliente nunca muda entre o momento em que o DHCP Snooping o registra e o momento em que o IPSG examina o próximo pacote. Habilite o mesmo recurso em uma interface a jusante de um encaminhamento de camada 3, e ele pode começar a descartar tráfego que nunca foi um problema de segurança.
Esta é uma das falhas de IPSG mais contraintuitivas, porque tudo mais na configuração parece correto — a tabela de vínculo tem a entrada certa, nenhuma ACL está envolvida, e a própria interface não mostra erros. A falha está em um detalhe que a maioria dos engenheiros não pensa em verificar até já ter relido a configuração, o cabeamento e a tabela de DHCP Snooping duas vezes cada. Se a tabela de vínculo que seu dispositivo está gerando já parece errada de início, a nota de solução de problemas de DHCP Snooping é o ponto de partida — esta nota assume que a tabela de vínculo já está correta e pergunta por que o IPSG ainda assim descarta o tráfego.
O IPSG se comporta de forma idêntica nos dois caminhos abaixo. A única diferença é se algo no meio do caminho reescreveu o MAC de origem do pacote.
Colocar seu sintoma no lado correto deste diagrama indica imediatamente se você está diante de um problema de tabela de vínculo ou de encaminhamento de camada 3 — e os dois são corrigidos de formas completamente diferentes.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
O caminho A quase nunca falha, porque nada entre o cliente DHCP e o ponto de verificação do IPSG toca o MAC de origem do quadro. O caminho B vale a pena reler: tudo na tabela de vínculo pode estar perfeitamente correto e o IPSG ainda assim descartará o tráfego, porque o pacote que o IPSG realmente inspeciona não é mais o que o cliente originalmente enviou.
Quatro verificações, em ordem — cada uma descarta uma causa plausível diferente antes de chegar à captura de pacotes que realmente comprova isso.
Antes de ler os arquivos de captura, confirme que o bloqueio é realmente do IPSG e não de algo anterior no caminho.
[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 isEsta é a verificação que realmente comprova a teoria — tudo antes disso apenas restringe a busca.
// 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 itA solução não é desativar o recurso — é fornecer a ele uma entrada de vínculo que corresponda ao pacote que ele realmente verá.
[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 MACDepois de confirmar ou descartar a falha de reescrita de MAC acima, essas cinco armadilhas explicam a maior parte do restante do que dá errado em torno do IPSG e suas tabelas de vínculo.
SINTOMAO ping e o tráfego de aplicações através de um salto roteado falham no momento em que a verificação de pacotes do IPSG é habilitada nessa interface; desativar a verificação restaura o tráfego imediatamente, sem alterações de ACL, rota ou link.
CAUSADurante o encaminhamento de camada 3, o MAC de origem do quadro muda para o MAC próprio da interface de saída a cada salto. A tabela de vínculo dinâmica do dispositivo, gerada pelo DHCP Snooping, sempre registra apenas o MAC original e inalterado do cliente. O IPSG compara o MAC de origem atual do pacote ao vivo com esse registro inalterado, então um pacote perfeitamente legítimo e perfeitamente roteado falha na correspondência e é descartado.
SOLUÇÃOAdicione uma entrada de vínculo estática na interface roteada / com IPSG habilitado usando o MAC pós-encaminhamento realmente visto naquela interface, não o MAC do cliente de origem. Confiar apenas na tabela dinâmica do DHCP Snooping só é seguro em interfaces onde os quadros chegam com o MAC de origem intacto.
SINTOMAAssim que um único vínculo estático IP+MAC é adicionado em uma interface compartilhada, usuários não relacionados na mesma porta perdem conectividade — não apenas o tráfego que o vínculo deveria controlar.
CAUSAAssim que qualquer entrada de vínculo estática existe em uma interface com a verificação de pacotes do IPSG habilitada, todo pacote IP que chega a essa interface é comparado com a tabela de vínculo — não há um modo parcial em que apenas o endereço vinculado é verificado e tudo o mais passa sem ser tocado. O tráfego de usuários que nunca receberam uma entrada de vínculo não tem nada para corresponder, então é tratado como uma tentativa de falsificação e descartado.
SOLUÇÃOAdicione uma entrada de vínculo estática para cada usuário legítimo que compartilha essa interface, ou remova completamente os vínculos estáticos e confie nos vínculos dinâmicos do DHCP Snooping para uma interface de acesso compartilhada — misturar alguns usuários vinculados com o restante não vinculado na mesma porta não funciona.
SINTOMAO IPSG está configurado e aparece na configuração em execução, mas uma interface específica nunca bloqueia nada, mesmo tráfego que claramente deveria falhar na verificação da tabela de vínculo.
CAUSAUma porta configurada como porta confiável do DHCP Snooping encaminha todos os pacotes sem qualquer comparação com a tabela de vínculo — o status confiável ignora o IPSG naquela interface por completo, por design. A configuração parece idêntica à de uma interface de IPSG funcional porque não é o próprio comando ip source check que controla esse comportamento.
SOLUÇÃOVerifique a função confiável/não confiável do DHCP Snooping da porta antes de supor um problema de tabela de vínculo ou ACL — display dhcp snooping user-bind mais a configuração de confiança da interface explicam mais chamados silenciosos de «o IPSG não funciona» do que uma entrada de vínculo incorreta.
SINTOMAUm dispositivo que vinha passando tráfego normalmente por horas ou dias de repente começa a descartar pacotes de um cliente que não mudou seu IP ou MAC de forma alguma.
CAUSAOs vínculos dinâmicos gerados pelo DHCP Snooping têm o mesmo envelhecimento baseado em arrendamento que o próprio arrendamento DHCP. Se o cliente não renovar antes que a entrada expire, e não enviar uma nova solicitação DHCP que regeneraria o vínculo, a entrada simplesmente desaparece, e o IPSG então não tem mais nada com que comparar o tráfego contínuo do cliente.
SOLUÇÃOConfirme se a entrada da tabela de vínculo ainda está presente com display dhcp snooping user-bind all antes de solucionar qualquer outra coisa; se ela sumiu e o cliente não refez o DHCP, resolva a incompatibilidade com um tempo de arrendamento adequado ou adicione um vínculo estático para hosts que não podem ser confiáveis para renovar prontamente.
SINTOMADepois de adicionar um vínculo estático destinado a limitar uma porta ou VLAN específica, usuários em outras partes da rede começam a perder conectividade — ou, ao contrário, os usuários que o vínculo deveria restringir ainda passam tráfego livremente.
CAUSAUma entrada de vínculo estática pode ser definida com qualquer combinação de IP, MAC, interface e VLAN, em uma visão de interface ou visão de VLAN — e o escopo muda completamente dependendo de quais campos são incluídos. Uma entrada VLAN+IP sem interface ou MAC restringe apenas por IP e VLAN, deixando passar qualquer MAC ou interface; uma entrada Interface+MAC sem IP faz o oposto. Errar a combinação não falha ruidosamente — apenas protege, ou bloqueia, um conjunto de tráfego diferente do pretendido.
SOLUÇÃODecida primeiro o escopo pretendido — um usuário, uma porta ou uma VLAN — e inclua exatamente os campos que correspondem a esse escopo; em caso de dúvida, uma entrada Interface+IP+MAC+VLAN é a mais específica e a menos propensa a um raio de impacto não intencional.
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Os descartes do IPSG não são contados nas estatísticas de Discard comuns da interface — essas rastreiam descartes físicos e em nível de buffer, não baseados em política. Um conjunto de contadores de interface limpo é exatamente o esperado nessa falha, não evidência de que o IPSG não está envolvido. Confirme alternando a verificação de pacotes e observando se o sintoma a acompanha.
A tabela dinâmica é gerada automaticamente pelo DHCP Snooping à medida que os clientes arrendam endereços, e expira com o arrendamento DHCP. A tabela estática é inserida manualmente e nunca expira — é a ferramenta certa para hosts com IP fixo, hosts atrás de um salto roteado onde o MAC de origem muda, ou qualquer dispositivo que não seja cliente DHCP. O IPSG verifica as duas tabelas juntas; qualquer uma delas tendo uma entrada correspondente já basta para passar o tráfego.
O endereço MAC que a própria interface com IPSG habilitado verá naquele tráfego — que, em um caminho roteado, é o MAC do último dispositivo que encaminhou o quadro, não o MAC próprio do cliente de origem. Confirme com uma captura naquela interface específica em vez de supor que corresponde ao que o DHCP Snooping registrou mais a montante.
Verifique se essa porta está configurada como porta confiável do DHCP Snooping. Portas confiáveis encaminham todo pacote sem qualquer comparação com a tabela de vínculo, por design — não é um bug do IPSG, é o comportamento pretendido da configuração de confiança, e é fácil esquecer que foi configurada assim meses depois.
Sim, e são avaliados de forma independente — o IPSG verifica IP/MAC/VLAN/interface de origem contra a tabela de vínculo, enquanto uma política de tráfego baseada em ACL corresponde aos campos que suas regras especificam. Qualquer um dos dois pode descartar um pacote que o outro teria deixado passar, o que significa que um chamado de «bloqueado» em uma interface rodando ambos os recursos precisa descartar cada um separadamente em vez de presumir que é o outro.
Esse é exatamente o seu trabalho nas interfaces de acesso — um par IP/MAC de origem falsificado que não corresponde a nada na tabela de vínculo é descartado, seja a tabela aprendida dinamicamente ou configurada estaticamente. O modo de falha coberto nesta nota é o lado do falso positivo do mesmo mecanismo: tráfego legítimo que não corresponde mais à tabela porque algo a montante mudou o MAC, não uma tentativa real de falsificação.
Esta nota é construída em torno da implementação de IP Source Guard do switch Huawei da série S e suas tabelas de vínculo baseadas em DHCP Snooping, além dos casos de campo por trás delas. Se sua camada de acesso for de outro fabricante, os comandos exatos mudam, mas a lógica subjacente — uma tabela de vínculo construída na borda de acesso, e uma verificação de MAC de origem que não enxerga além de um salto de roteamento — se aplica diretamente. Ela não cobre especificamente o IPv6 Source Guard, nem projetos baseados em SAVI de outras famílias de normas.
Diga-nos se o caminho afetado é uma porta de acesso simples ou está atrás de um salto roteado, além da saída de display dhcp snooping user-bind, e ajudaremos você a interpretá-la.