IPSG se activa sin problemas en cada puerto de acceso, y luego un enlace ascendente enrutado se apaga silenciosamente en cuanto lo habilita. La causa no es una tabla de enlace incorrecta — es que el reenvío de capa 3 reescribe el MAC de origen del paquete antes de que IPSG siquiera lo examine. Así se demuestra con una captura de paquetes, y los problemas relacionados que surgen de la misma lógica de tabla de enlace.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
La tabla de enlace no está mal. Simplemente responde a una pregunta que IPSG hizo en el punto equivocado del recorrido del paquete.
IP Source Guard verifica la IP de origen, el MAC de origen, la VLAN y la interfaz de entrada de un paquete contra una tabla de enlace antes de decidir si reenviarlo o descartarlo. En un simple puerto de acceso de capa 2, esa verificación es trivial — el MAC del cliente nunca cambia entre el momento en que DHCP Snooping lo registra y el momento en que IPSG examina el siguiente paquete. Habilite la misma función en una interfaz situada aguas abajo de un reenvío de capa 3, y puede empezar a descartar tráfico que nunca fue un problema de seguridad.
Esta es una de las fallas de IPSG más contraintuitivas, porque todo lo demás en la configuración parece correcto — la tabla de enlace tiene la entrada correcta, no interviene ninguna ACL, y la propia interfaz no muestra errores. La falla está en un detalle que la mayoría de los ingenieros no piensan en revisar hasta que ya releyeron la configuración, el cableado y la tabla de DHCP Snooping dos veces cada uno. Si la tabla de enlace que su equipo está generando ya parece incorrecta desde el principio, la nota de resolución de problemas de DHCP Snooping es el punto de partida — esta nota asume que la tabla de enlace ya es correcta y pregunta por qué IPSG aun así descarta el tráfico.
IPSG se comporta de forma idéntica en las dos rutas siguientes. La única diferencia es si algo intermedio reescribió el MAC de origen del paquete.
Ubicar su síntoma en el lado correcto de este diagrama le indica de inmediato si está ante un problema de tabla de enlace o de reenvío de capa 3 — y ambos se solucionan de maneras completamente distintas.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La ruta A casi nunca falla, porque nada entre el cliente DHCP y el punto de verificación de IPSG toca jamás el MAC de origen de la trama. La ruta B merece leerse dos veces: todo en la tabla de enlace puede ser perfectamente correcto y IPSG aun así descartará el tráfico, porque el paquete que IPSG realmente inspecciona ya no es el que el cliente envió originalmente.
Cuatro comprobaciones, en orden — cada una descarta una causa plausible distinta antes de llegar a la captura de paquetes que realmente lo demuestra.
Antes de leer los archivos de captura, confirme que el bloqueo realmente es de IPSG y no de algo anterior en la ruta.
[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 es la comprobación que realmente demuestra la teoría — todo lo anterior solo acota la búsqueda.
// 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 solución no es desactivar la función — es darle una entrada de enlace que coincida con el paquete que 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 MACUna vez confirmada o descartada la falla de reescritura de MAC anterior, estos cinco problemas explican la mayor parte de lo demás que falla en torno a IPSG y sus tablas de enlace.
SÍNTOMAEl ping y el tráfico de aplicaciones a través de un salto enrutado fallan en el momento en que se habilita la verificación de paquetes de IPSG en esa interfaz; desactivar la verificación restablece el tráfico de inmediato, sin cambios de ACL, ruta o enlace.
CAUSADurante el reenvío de capa 3, el MAC de origen de la trama cambia al MAC propio de la interfaz saliente en cada salto. La tabla de enlace dinámica del equipo, generada por DHCP Snooping, solo registra siempre el MAC original e inalterado del cliente. IPSG compara el MAC de origen actual del paquete en vivo contra ese registro inalterado, por lo que un paquete perfectamente legítimo y perfectamente enrutado falla la coincidencia y se descarta.
SOLUCIÓNAgregue una entrada de enlace estática en la interfaz enrutada / con IPSG habilitado usando el MAC posterior al reenvío realmente observado en esa interfaz, no el MAC del cliente originante. Confiar únicamente en la tabla dinámica de DHCP Snooping solo es seguro en interfaces donde las tramas llegan con el MAC de origen intacto.
SÍNTOMAEn cuanto se agrega un solo enlace estático IP+MAC en una interfaz compartida, usuarios no relacionados en el mismo puerto pierden conectividad — no solo el tráfico que el enlace debía controlar.
CAUSAEn cuanto existe cualquier entrada de enlace estática en una interfaz con la verificación de paquetes de IPSG habilitada, cada paquete IP que llega a esa interfaz se compara con la tabla de enlace — no hay un modo parcial donde solo se verifique la dirección enlazada y todo lo demás pase sin tocar. El tráfico de usuarios que nunca recibieron una entrada de enlace no tiene nada con qué coincidir, así que se trata igual que un intento de suplantación y se descarta.
SOLUCIÓNAgregue una entrada de enlace estática para cada usuario legítimo que comparte esa interfaz, o elimine por completo los enlaces estáticos y confíe en los enlaces dinámicos de DHCP Snooping para una interfaz de acceso compartida — mezclar algunos usuarios enlazados con el resto sin enlazar en el mismo puerto no funciona.
SÍNTOMAIPSG está configurado y aparece en la configuración en ejecución, pero una interfaz específica nunca bloquea nada, ni siquiera tráfico que claramente debería fallar la verificación de la tabla de enlace.
CAUSAUn puerto configurado como puerto de confianza de DHCP Snooping reenvía todos los paquetes sin ninguna comparación con la tabla de enlace — el estado de confianza omite IPSG en esa interfaz por completo, por diseño. La configuración parece idéntica a la de una interfaz de IPSG funcional porque no es el propio comando ip source check el que controla este comportamiento.
SOLUCIÓNVerifique el rol de confianza/no confianza de DHCP Snooping del puerto antes de asumir un problema de tabla de enlace o ACL — display dhcp snooping user-bind junto con la configuración de confianza de la interfaz explica más tickets silenciosos de «IPSG no funciona» que una entrada de enlace incorrecta.
SÍNTOMAUn equipo que ha estado pasando tráfico normalmente durante horas o días de repente empieza a descartar paquetes de un cliente que no ha cambiado su IP ni su MAC en absoluto.
CAUSALos enlaces dinámicos generados por DHCP Snooping tienen el mismo envejecimiento basado en el arrendamiento que el propio arrendamiento DHCP. Si el cliente no renueva antes de que la entrada caduque, y no envía una nueva solicitud DHCP que regeneraría el enlace, la entrada simplemente desaparece, y entonces IPSG ya no tiene nada con qué comparar el tráfico continuo del cliente.
SOLUCIÓNConfirme que la entrada de la tabla de enlace sigue presente con display dhcp snooping user-bind all antes de resolver cualquier otra cosa; si desapareció y el cliente no ha vuelto a ejecutar DHCP, resuelva la discrepancia con un tiempo de arrendamiento adecuado o agregue un enlace estático para hosts que no se puede confiar en que renueven a tiempo.
SÍNTOMADespués de agregar un enlace estático destinado a acotar un puerto o VLAN específico, usuarios en otras partes de la red empiezan a perder conectividad — o, a la inversa, los usuarios que el enlace debía restringir siguen pasando tráfico libremente.
CAUSAUna entrada de enlace estática puede definirse con cualquier combinación de IP, MAC, interfaz y VLAN, en vista de interfaz o vista de VLAN — y el alcance cambia por completo según qué campos se incluyan. Una entrada VLAN+IP sin interfaz ni MAC restringe solo por IP y VLAN, dejando pasar cualquier MAC o interfaz; una entrada Interfaz+MAC sin IP hace lo contrario. Equivocarse en la combinación no falla ruidosamente — simplemente protege, o bloquea, un conjunto de tráfico distinto del previsto.
SOLUCIÓNDecida primero el alcance previsto — un usuario, un puerto o una VLAN — e incluya exactamente los campos que corresponden a ese alcance; en caso de duda, una entrada Interfaz+IP+MAC+VLAN es la más específica y la menos propensa a tener un radio de impacto no deseado.
Extraídas directamente del campo — las que vale la pena tener una respuesta preparada.
Los descartes de IPSG no se cuentan en las estadísticas de Discard normales de la interfaz — esas rastrean descartes físicos y a nivel de búfer, no basados en políticas. Un conjunto de contadores de interfaz limpio es exactamente lo esperado en esta falla, no evidencia de que IPSG no esté involucrado. Confirme alternando la verificación de paquetes y observando si el síntoma la sigue.
La tabla dinámica es generada automáticamente por DHCP Snooping a medida que los clientes arriendan direcciones, y caduca con el arrendamiento DHCP. La tabla estática se ingresa manualmente y nunca caduca — es la herramienta adecuada para hosts con IP fija, hosts detrás de un salto enrutado donde el MAC de origen cambia, o cualquier dispositivo que no sea cliente DHCP en absoluto. IPSG verifica ambas tablas juntas; que cualquiera de las dos tenga una entrada coincidente basta para dejar pasar el tráfico.
La dirección MAC que la propia interfaz con IPSG habilitado verá en ese tráfico — que, en una ruta enrutada, es el MAC del último dispositivo que reenvió la trama, no el MAC propio del cliente originante. Confírmelo con una captura en esa interfaz específica en lugar de asumir que coincide con lo que DHCP Snooping registró más arriba.
Verifique si ese puerto está configurado como puerto de confianza de DHCP Snooping. Los puertos de confianza reenvían todos los paquetes sin ninguna comparación de tabla de enlace, por diseño — no es un error de IPSG, es el comportamiento previsto del ajuste de confianza, y es fácil olvidar que se configuró así meses después.
Sí, y se evalúan de forma independiente — IPSG verifica IP/MAC/VLAN/interfaz de origen contra la tabla de enlace, mientras que una política de tráfico basada en ACL coincide según los campos que especifiquen sus reglas. Cualquiera de las dos puede descartar un paquete que la otra habría dejado pasar, lo que significa que un ticket de «bloqueado» en una interfaz que ejecuta ambas funciones necesita descartar cada una por separado en lugar de asumir que es la otra.
Esa es exactamente su función en las interfaces de acceso — un par IP/MAC de origen suplantado que no coincide con nada en la tabla de enlace se descarta, ya sea que la tabla se aprenda dinámicamente o se configure estáticamente. El modo de falla cubierto en esta nota es el lado del falso positivo del mismo mecanismo: tráfico legítimo que ya no coincide con la tabla porque algo aguas arriba cambió el MAC, no un intento real de suplantación.
Esta nota se basa en la implementación de IP Source Guard del switch Huawei serie S y sus tablas de enlace basadas en DHCP Snooping, además de los casos de campo detrás de ellas. Si su capa de acceso es de otro fabricante, los comandos exactos cambian, pero la lógica subyacente — una tabla de enlace construida en el borde de acceso, y una verificación de MAC de origen que no puede ver más allá de un salto de enrutamiento — se traslada directamente. No cubre específicamente IPv6 Source Guard, ni diseños basados en SAVI de otras familias de estándares.
Cuéntenos si la ruta afectada es un puerto de acceso simple o está detrás de un salto enrutado, más la salida de display dhcp snooping user-bind, y le ayudaremos a interpretarla.