¿Qué considera un cliente DHCP como la "mejor" respuesta?

13

Tenemos salas de capacitación donde normalmente se instala Windows XP (a través de PXE). La infraestructura DNS / DHCP "normal" son los servidores de Windows. La sala de capacitación tiene su propia VLAN (diferente de los servidores de Windows), por lo que es más probable que haya un auxiliar de IP para las solicitudes de DHCP activas en el enrutador Cisco al que están conectadas todas las PC de esa sala.

Ahora queríamos convertir algunas de las PC a Linux. La idea era: colocar nuestra propia computadora portátil con un servidor DHCP en la VLAN de la sala y anular la respuesta DHCP "normal". La idea era que esto debería funcionar, ya que un servidor DHCP conectado directamente en esa VLAN debería tener un tiempo de respuesta más rápido que el servidor DHCP "normal" ubicado a unos saltos de esa VLAN.

Resultó que esto no funcionó. Tuvimos que liberar manualmente el contrato de arrendamiento en el servidor DHCP original para que funcionara.

En la computadora portátil vimos que el cliente solicitaba la IP y "nuestro" dhcp estaba enviando NACK a la solicitud de IP de Windows, antes de eso ofrecíamos nuestra propia respuesta.

Pregunta anterior: ¿Por qué esto no funcionó como se esperaba? ¿Qué está haciendo que la PC recupere su antiguo contrato de arrendamiento?

Actualización 2012-08-08:

El problema de recuperación se ha explicado en el DHCP-RFC. Ahora esto explica por qué la PC recupera su antiguo contrato de arrendamiento.

Ahora liberamos la IP del servidor Windows-DHCP antes de intentarlo de nuevo.

Nuevamente, el servidor Windows-DHCP gana.

Sospecho que hay algún algoritmo para el cliente dhcp que determina la "mejor" respuesta dhcp para el cliente. La nueva pregunta es:

¿Cómo elige el cliente la "mejor" respuesta?

Nils
fuente
¿Dónde está liberando la dirección IP? en el cliente de Windows o en el agente de arranque PXE?
Longneck
@longneck tuvimos que liberar la dirección en el servidor Windows-DHCP para que funcione.
Nils
Una forma extraña de instanciar una nueva pregunta, espero que resuelvas esto, sin embargo
Daniel Li

Respuestas:

4

Es el proveedor, incluso el firmware específico de cómo un cliente reacciona a múltiples respuestas DHCP.

Las variantes que he visto a lo largo de los años son:

1) Acepte el primero independientemente de si es un ACK o un NACK.

2) Tome el primer ACK, ignore los NACK por completo.

3) Tome el último ACK recibido dentro de un intervalo de tiempo establecido (generalmente 5-10 segundos).

Ejemplo: hace algunos años tuvimos problemas con las impresoras multifunción Ricoh.
Teníamos 2 servidores DHCP. Uno proporcionó las direcciones, el otro solo opciones adicionales de DHCP. El segundo servidor siempre respondió primero.
La variante usada de Ricoh 1) incluso si la primera oferta solo contenía opciones de DHCP. Ricoh lo cambió a la variante 2) con una actualización de firmware después de que les explicamos el problema.

Tonny
fuente
Los OFFERpaquetes son lo que el sistema cliente necesita para decidir. ACKy los NACKpaquetes solo se envían en respuesta a a REQUEST, lo que solo ocurre después de que el cliente ha "decidido" qué oferta seguir. Sin embargo, ¡ese es un error genial con las impresoras!
Shane Madden
@ShaneMadden Eso es correcto, pero he visto numerosos casos de clientes que envían una solicitud en respuesta a AMBAS ofertas y luego actúan según las respuestas que describí. Ha pasado un tiempo desde que miré esto en profundidad. Recuerdo claramente que NT4, W2K y XP son culpables de esto. Los Ricoh también lo hicieron. Corrieron un kernel de Linux 2.2 y una pila de red.
Tonny
9

Suponiendo que el enrutador sigue actuando como un retransmisor DHCP y reenviando la solicitud a su servidor original, la razón por la que lo hizo es simplemente porque ese servidor DHCP de Windows le dijo que continuara y usara la IP. En este caso, el DHCPNACK del nuevo servidor es irrelevante, ya que un cliente DHCP considerará todas las respuestas, y dado que recibió una oferta del cuadro DHCP de Windows, está perfectamente feliz de usarlo.

PC: Oh, hola mundo, ¿puedo usar 192.168.1.123?

Nuevo DHCP: digo que no.

Old-DHCP: yo digo que sí.

PC: ¡Alguien dijo que sí! ¡Dulce, lo usaré!

ThatGraemeGuy
fuente
Después del arranque en frío de la PC, la conversación comienza con "mi MAC es XYZ, por favor dame una IP". Entonces, ambos servidores DHCP ofrecen IP ... la única diferencia es que tiene una concesión activa en uno de los servidores, pero esto es solo la perspectiva del servidor.
Nils
1
no si la PC ya tenía una dirección IP. si anteriormente tenía una dirección IP asignada por un servidor DHCP, solicitará usarla primero antes de solicitar otra dirección.
cuello largo
@longneck, ¿dónde se almacenará esa IP en la PC?
Nils
fuera de mi cabeza, no lo sé. pero la forma correcta de borrarlo es usar ipconfig / release
longneck
3
@longneck: el operador está preguntando en un entorno PXE, donde asumimos que el BIOS de arranque no recuerda recuerdos de arranque o direcciones IP anteriores
Mark Henderson
3

Si nada más ayuda: RTFM (lea el excelente manual). En este caso, el primero fue el éxito.

RFC 2131 describe las operaciones DHCP.

La Sección 1.6 establece que DHCP debe :

Mantenga la configuración del cliente DHCP en todos los reinicios del servidor y, siempre que sea posible, a un cliente DHCP se le deben asignar los mismos parámetros de configuración a pesar de reiniciar el mecanismo DHCP,

Ahora la pregunta interesante es cómo se logra ese objetivo de diseño en un cliente que no tiene conocimiento de su pasado. Esquema de la sección 3.2:

3.2 Interacción cliente-servidor: reutilizar una dirección de red previamente asignada

Si un cliente recuerda y desea reutilizar una
dirección de red previamente asignada , un cliente puede optar por omitir algunos de los pasos
descritos en la sección anterior. El diagrama de línea de tiempo en la figura 4
muestra las relaciones de temporización en una interacción típica cliente-servidor para un cliente que reutiliza una dirección de red previamente asignada.

  1. El cliente difunde un mensaje DHCPREQUEST en su subred local. El mensaje incluye la dirección de red del cliente en la opción 'dirección IP solicitada'. Como el cliente no ha recibido su dirección de red, NO DEBE completar el campo 'ciaddr'. Los agentes de retransmisión BOOTP transmiten el mensaje a los servidores DHCP que no están en la misma subred. Si el cliente usó un 'identificador de cliente' para obtener su dirección, DEBE usar el mismo 'identificador de cliente' en el mensaje DHCPREQUEST.

  2. Los servidores con conocimiento de los parámetros de configuración del cliente responden con un mensaje DHCPACK al cliente. Los servidores NO DEBEN verificar que la dirección de red del cliente ya esté en uso; el cliente puede responder a los mensajes de solicitud de eco ICMP en este momento.

Por lo tanto, un servidor DHCP que tenga una concesión activa obtiene prioridad mediante el uso de un acceso directo en el protcol.

  1. Cliente: DHCREQUEST (MAC-Adress, broadcast, se transmitirá en el dominio de broadcast local, aquí la VLAN local y mediante IP-helper al servidor Windows-DHCP)
  2. Laptop-DHCP-Server: DHCPOFFER
  3. Windows-DHCP-Server: Hola, ya te conozco - DHCPACK
  4. Cliente: Oh, tengo dos respuestas. Uno que ya me conoce. Genial, tomaré eso

A partir de ese momento, el Cliente ignorará el Servidor DHCP-Laptop.

Por lo tanto, la solución en nuestro caso probablemente será (actualizaré esto cuando realmente lo probemos):

  1. Asegúrese de que el cliente esté apagado
  2. Apague el servidor DHCP en la computadora portátil, falso cliente-MAC en la computadora portátil, solicitud de DHCP
  3. Liberar IP
  4. Recupere IP y MAC originales, encienda el servidor DHCP
  5. Encienda el cliente y haga un arranque PXE ...
Nils
fuente
3

La nueva pregunta probablemente debería estar en una pregunta diferente: el título de la pregunta no encaja en absoluto con la mayor parte del cuerpo de la pregunta.

En cualquier caso, con respecto a cómo un cliente elige con qué oferta ir, en el caso de que no tenga un contrato de arrendamiento actual: depende del cliente, pero en cada implementación de cliente DHCP que conozco, es una carrera simple .

RFC 2131 cubre esto:

Los clientes DHCP son libres de usar cualquier estrategia al seleccionar un servidor DHCP entre aquellos de los cuales el cliente recibe un mensaje DHCPOFFER.

Hay un borrador de IETF que parece muerto que habría agregado capacidad de configuración al proceso de selección, y también menciona las implementaciones de clientes mediocres (de hace más de una década, pero no ha cambiado mucho):

En la práctica, la implementación de la política por parte de la mayoría de los proveedores aquí es muy básica (por ejemplo, la primera oferta recibida o la primera oferta aceptable recibida) y está "codificada" (es decir, no configurable).

Tener dos servidores DHCP que brindan servicio a la misma red con una configuración diferente solo da como resultado carreras, lo que no es deseable desde una perspectiva de confiabilidad o previsibilidad. Realmente no hay ninguna razón por la que no pueda obtener su único servidor DHCP para proporcionar lo que necesita.

Shane Madden
fuente
¿Cree que la oferta "aceptable" es específica del proveedor en el lado del cliente dhcp? Dado que en nuestro caso no es la "primera" oferta, debe ser otra cosa; sin embargo, el comportamiento es bastante determinista, por lo que todavía creo que hay un estándar común detrás de esto.
Nils
@Nils ¿Está absolutamente seguro de que el servidor de Windows no está respondiendo al cliente antes que la computadora portátil en la misma habitación? Parece intuitivamente que la computadora portátil debería ganar esa carrera, pero eso podría no ser lo que está sucediendo.
Shane Madden
Supongo que tendré que rastrear esto a nivel de red (con wireshark) para ver realmente lo que está sucediendo allí. Probablemente en un puerto espejo de ese cliente ...
Nils