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

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?

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.

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é!

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 ...

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.