La opción dhcp-snooping 82 elimina las solicitudes dhcp válidas en los conmutadores Procurve de la serie 2610

8

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.

networking dhcp hp-procurve
fuente
¿Están los servidores dhcp en la misma subred o los está transmitiendo un enrutador? Sé que los enrutadores Cisco / los conmutadores l3 requieren el comando trust-all de información de retransmisión ip dhcp si están haciendo el reenvío dhcp.
Bad Dos
Están en la misma subred. Todo es completamente plano desde una perspectiva de Capa 3.
¿Funciona DHCP correctamente si conecta una computadora portátil al conmutador que está conectado directamente al servidor dhcp? Tal vez uno de los enlaces ascendentes en la topología de su conmutador no sea de confianza.
Bad Dos
Si. Funciona cuando la máquina está conectada al mismo conmutador que el servidor DHCP. No confío en el puerto de enlace ascendente en el conmutador ascendente. Solo confía en los puertos de los que provienen los paquetes DHCPOFFER o DHCPACK: el puerto al que está conectado el servidor DHCP. Si confié en el puerto Trunk en el conmutador ascendente, el conmutador permitiría que un servidor dhcp responda a través de ese enlace ascendente a sus clientes. FWIW, tengo una solicitud de soporte con HP y parecen igualmente desconcertados.
No estoy familiarizado con HP, pero en Cisco confiaría en el puerto de enlace ascendente en el conmutador de acceso, pero el conmutador al que se conecta no confiará en ese puerto. Esto garantiza que las ofertas de dhcp puedan fluir hacia el conmutador de acceso, pero que no surja nada del conmutador de acceso y que tampoco se confíe en otros puertos del conmutador de acceso.
Bad Dos

Respuestas:

1

Dijiste que "el relé dhcp no está habilitado" ... pero claramente lo es, según tu salida show dhcp-relay.

Intente deshabilitarlo explícitamente; basado en los comentarios anteriores, sospecho que su problema desaparecerá :)

Dan Pritts
fuente
1

En realidad, el paquete en el conmutador A se está cayendo porque recibió un paquete de cliente DHCP con la opción 82 en un puerto no confiable. Esta opción-82 es insertada por el switchB.

Creo que a continuación debería funcionar:

Encendido, SwitchB: deshabilite la opción 82 para que esto no inserte estas opciones. marque la interfaz-25 como confianza para permitir que el paquete del servidor DHCP fluya hacia el.

Encendido, SwitchA: puede mantener la opción 82 habilitada / deshabilitada aquí. No debería importar. marque el puerto que está conectado al switchB como no confiable. marque el puerto que está conectado al servidor dhcp como confiable.

usuario256656
fuente
0

Creo que puede estar malinterpretando la idea de un puerto confiable. Estoy de acuerdo en que confiar solo en los puertos de los que provienen las ofertas es intuitivo, pero entiendo que también debe confiar en el puerto troncal en el Switch A. Usted marca puertos de confianza que están conectados a equipos que conoce y en los que confía. El hecho de que marque la troncal en el Switch A como confiable no significa que va a permitir que exista un servidor DHCP falso en el switch B. Si está configurado correctamente, el switch B no confía en ningún puerto que no sea su troncal, así que usted todavía he evitado que un servidor DHCP falso se quede en el conmutador B y envíe ofertas a los clientes en el conmutador A.

En resumen, se supone que debe confiar en los puertos conectados a sus propios servidores DHCP y en los puertos conectados a otros conmutadores que administra (por lo que puede estar seguro de que no hay otros puertos confiables).

Paul Ackerman
fuente