Estamos comenzando lentamente a implementar dhcp-snooping en nuestros conmutadores HP ProCurve 2610 series, todos con el firmware R.11.72. Estoy viendo un comportamiento extraño en el que los paquetes dhcp-request o dhcp-refresh se descartan cuando se originan desde conmutadores "posteriores" debido a "información de retransmisión no confiable del cliente".
El error completo:
Received untrusted relay information from client <mac-address> on port <port-number>
Más detalladamente tenemos un HP2610 de 48 puertos (Switch A) y un HP2610 de 24 puertos (Switch B). El conmutador B está "aguas abajo" del conmutador A en virtud de una conexión DSL a uno de los puertos del conmutador A. El servidor dhcp está conectado al Switch A. Los bits relevantes son los siguientes:
Interruptor A
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1 168
interface 25
name "Server"
dhcp-snooping trust
exit
Interruptor B
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1
interface Trk1
dhcp-snooping trust
exit
Los conmutadores están configurados para confiar en AMBOS el puerto al que está conectado el servidor DHCP autorizado y su dirección IP. Todo esto está muy bien para los clientes conectados al Switch A, pero los clientes conectados al Switch B se rechazan debido al error de "información de retransmisión no confiable". Esto es extraño por algunas razones 1) dhcp-relay no está configurado en ninguno de los conmutadores, 2) la red de capa 3 aquí es plana, la misma subred. Los paquetes DHCP no deben tener un atributo de opción 82 modificado.
Sin embargo, dhcp-relay parece estar habilitado de forma predeterminada:
SWITCH A# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
0 0 0 0
SWITCH B# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
40156 0 0 0
Y curiosamente, el agente dhcp-relay parece estar muy ocupado en el Switch B, pero ¿por qué? Por lo que puedo decir, no hay ninguna razón por la cual las solicitudes dhcp necesiten un relé con esta topología. Y, además, no puedo decir por qué el conmutador ascendente está abandonando las solicitudes legítimas de dhcp de información de retransmisión no confiable cuando el agente de retransmisión en cuestión (en el Interruptor B) no está modificando los atributos de la opción 82 de todos modos.
Agregar el no dhcp-snooping option 82interruptor A activado permite que el tráfico dhcp del interruptor B sea aprobado por el interruptor A, simplemente apagando esa característica. ¿Cuáles son las repercusiones de no validar el tráfico dhcp modificado de la opción 82? Si desactivo la opción 82 en todos mis conmutadores "ascendentes", ¿pasarán el tráfico dhcp de cualquier conmutador descendente independientemente de la legitimidad de ese tráfico?
Este comportamiento es independiente del sistema operativo del cliente. Lo veo con clientes de Windows y Linux. Nuestros servidores DHCP son máquinas Windows Server 2003 o Windows Server 2008 R2. Veo este comportamiento independientemente del sistema operativo de los servidores DHCP.
¿Alguien puede arrojar algo de luz sobre lo que está sucediendo aquí y darme algunas recomendaciones sobre cómo debo proceder con la configuración de la opción 82? Siento que simplemente no he asimilado completamente los atributos de retransmisión de dhcp y la opción 82.