DHCP Snooping falla en EtherChannel con IOSv-L2 en EVE‑NG
En un laboratorio EVE‑NG con dos switches Cisco IOSv‑L2, un router y una PC, el proceso de DHCP Release se descarta cuando la interfaz de salida es física pero la entrada de la base de datos de snooping es la de Port‑Channel.
En un laboratorio EVE‑NG con dos switches Cisco IOSv‑L2, un router y una PC, el proceso de DHCP Release se descarta cuando la interfaz de salida es física pero la entrada de la base de datos de snooping es la de Port‑Channel.
El escenario es sencillo: R1‑SW1‑SW2‑PC1, todo en VLAN 10. SW1 y SW2 están enlazados por un EtherChannel de dos enlaces, probado tanto con LACP como con PAgP. La PC recibe una dirección DHCP sin problema, pero al liberar la dirección (ip dhcp -x en VPCS) el paquete DHCPRELEASE llega a SW1 por una de las puertos físicos (por ejemplo, Gi0/1). La entrada de la tabla de DHCP Snooping, sin embargo, registra la asociación MAC‑IP‑IP con la interfaz virtual Port‑Channel1. Cuando el proceso de snooping recibe el RELEASE en Gi0/1, detecta la discrepancia de interfaces y lo descarta con el mensaje de depuración DHCP_SNOOPING_FAKE_INTERFACE: drop message with mismatched source interface.
El resultado es que el servidor DHCP en R1 nunca recibe el RELEASE y mantiene la asignación de la IP. El problema desaparece si se deshabilita DHCP Snooping o si se elimina el EtherChannel y se utiliza una única conexión troncal entre los switches.
El comportamiento se reproduce en ambas configuraciones de agregación (LACP y PAgP) y parece estar ligado a la implementación IOSv‑L2 en EVE‑NG. El usuario ha intentado desactivar Option 82 para evitar un conflicto con el servidor DHCP interno del IOS, pero la falla persiste.
Algunas consideraciones:
- En hardware real, Cisco suele documentar que los paquetes de DHCP que viajan sobre un trunk deben llegar a la interfaz física que se usa en la tabla de snooping. En el caso de un EtherChannel, la tabla debe usar el nombre del canal (Port‑Channel) y el proceso de snooping debe reconocer la llegada en cualquiera de sus miembros.
- El mensaje DHCP_SNOOPING_FAKE_INTERFACE indica que la interfaz de origen del paquete no coincide con la asociada al binding, lo que es una protección contra spoofing.
- La solución más directa es evitar el uso de DHCP Snooping sobre EtherChannels en entornos virtuales, o bien usar un switch físico donde la implementación esté completamente soportada.
Si necesitas que el RELEASE llegue al servidor DHCP, la alternativa inmediata es:
- Desactivar DHCP Snooping en los switches involucrados.
- Configurar un puerto físico de acceso en vez de un EtherChannel.
- Si el entorno virtual es imprescindible, probar con otra versión del IOSv o con un emulador que soporte mejor la integración de DHCP Snooping y EtherChannel.
Este caso resalta la importancia de probar escenarios de liberación de IP en laboratorios de emulación antes de desplegar en producción, ya que los comportamientos de la capa de control pueden diferir de los dispositivos físicos.
Para más detalles sobre el escenario y la conversación, consulta la publicación original en Reddit: Reddit: Trouble with DHCP Snooping + EtherChannel.