¿Cómo saben los clientes DHCP cuál de los múltiples DHCPOFFERS aceptar?

Imagina que tenemos una red como en la imagen. Seis hosts en una red de capa 2, sin VLAN. Se supone que la red está segmentada en dos subredes, con un servidor DHCP cada una. Los servidores DHCP tienen direcciones IP fijas, por lo que obviamente saben a qué subred pertenecen.

Luego, los nuevos clientes se conectan. No saben nada sobre en qué subred se supone que deben estar y envían su DHCPDISCOVER a la transmisión Ethernet 255.255.255.255, por lo que va a ambos servidores DHCP. Ambos servidores responden con una oferta. Ahora aquí está mi pregunta: ¿Cómo sabe el cliente, qué DHCPOFFER debe aceptar?

networking dhcp

— Michael Niemand
fuente

Compare esta pregunta y sus respuestas allí.

— Kamil Maciorowski

Aquí hay otra pregunta relacionada .

— Kasperd

"la transmisión de Ethernet 255.255.255.255" - Esa es la dirección de transmisión IP para la red local, no una dirección de Ethernet. Es muy probable que los mensajes iniciales de DESCUBRIMIENTO DHCP también usen la dirección de transmisión Ethernet ff: ff: ff: ff: ff: ff, pero realmente no son lo mismo.

— ilkkachu

Respuestas:

La respuesta más simple: primero llegado, primero servido.

Si tenía varias VLAN y 10.10.10.0/24 estaba en una VLAN diferente a 10.10.20.0/24, la transmisión no cruzaría las VLAN.

Si el servidor DHCP estaba en una VLAN separada para los clientes, un iphelper en la interfaz de enrutamiento entre vlans dirigiría la transmisión a la ubicación correcta.

En su escenario en el que tiene 2 redes separadas dentro de la misma VLAN (o falta de ella) que sirven diferentes subredes, es una carrera.

DHCP se sirve utilizando las siguientes transacciones:

Descubrimiento de DHCP (DHCPDISCOVER) - Difusión del cliente - "¿Existe un servidor DHCP?"
Oferta DHCP (DHCPOFFER) - Servidor al Cliente - "Sí, estoy aquí y disponible!"
Solicitud de DHCP (DHCPREQUEST) - Cliente a servidor "Impresionante, ¿puedo tener una dirección por favor?"
Acuse de recibo de DHCP (DHCPACK): servidor a cliente "Claro, aquí hay una IP, una máscara, una puerta de enlace, algunos servidores DNS / WINS, un servidor de tiempo y todo lo demás configurado para su alcance"

Todo esto sucede en los puertos UDP 67 para el servidor y 68 para el cliente.

Tan pronto como se alcanza el paso 2, el cliente dejará de "escuchar" las respuestas de otros servidores DHCP, es feliz tratar con el primer servidor para prestarle atención.

Como nota al margen, en realidad hay una serie bien conocida de ataques DoS (denegación de servicio) que abusan de este derecho. Un atacante conecta un dispositivo que responde y envía paquetes DHCPOFFER y luego no envía DHCPACK cuando se le pregunta ... una y otra y otra vez. También hay otro ataque DoS en el que los servidores DHCP "falsos" ofrecen direcciones que no se pueden enrutar o que entran en conflicto con otras IP que se olfatea para interferir con las redes.

— Fazer87
fuente

Y, por lo tanto, la respuesta corta a "Pero entonces, ¿cómo ejecuto varias subredes en un solo segmento de Capa 2?" es " Usted no lo hace. " (Sí, hay maneras, pero no es algo que se debe generalmente Realice una capa 2 = dominio de una subred..)

— user1686

Gracias chicos, eso realmente hizo clic conmigo. Siempre me pregunté cómo sería posible, pero simplemente no lo es. Entonces, la conclusión es: tener un enrutador / capa 3 cambiar entre subredes o segmento con VLAN, ¿estoy en lo cierto?

— Michael Niemand

En general, sí, necesita VLAN o segmentación física. Compartir un dominio L2 sería factible solo si ambos servidores DHCP estuvieran restringidos a manejar clientes "conocidos" (por ejemplo, mediante una lista de 'arrendamientos estáticos' con direcciones MAC permitidas).

— usuario1686

Creo que podría dar a cada servidor DHCP una lista blanca de direcciones MAC y controlar qué cliente obtiene una dirección de qué servidor de esa manera.

— Darren

@grawity, puede ejecutar fácilmente varias subredes IP en el mismo segmento de capa 2, si las subredes son iguales y no le importa qué cliente obtiene una dirección de qué subred. Solo tiene un servidor DHCP que proporciona direcciones de ambos bloques y un enrutador que actúa como puerta de enlace para ambos bloques (con una dirección en cada uno). Hecho. Decir simplemente "no lo haces" es simplemente incorrecto.

— ilkkachu

La respuesta existente de @ Fazer87 es ampliamente correcta en la práctica y recomiendo votar y aceptarla. Esta respuesta explora un detalle menor con un poco más de precisión.

Ambos servidores DHCP pueden responder con un mensaje DHCPOffer.

Un cliente DHCP puede aceptarlos por orden de llegada. Sin embargo, no es obligatorio adoptar ese enfoque.

RFC2131 especifica:

El cliente recibe uno o más mensajes DHCPOFFER de uno o más servidores. El cliente puede elegir esperar varias respuestas. El cliente elige un servidor desde el cual solicitar los parámetros de configuración, en función de los parámetros de configuración ofrecidos en los mensajes DHCPOFFER.

Entonces, si el segundo servidor DHCP ofreció una reserva de dirección IP más larga, u ofreció un servidor de tiempo donde el otro no lo hizo, o tal vez tenía un campo personalizado que el cliente había sido programado para preferir, puede aceptar la segunda oferta.

Por lo general, un enfoque de "primer llegado, primer servido" le dará la oferta que no ha pasado por varios saltos entre dispositivos (retransmisiones BOOTP), por lo que es un buen protocolo a seguir si no tiene motivos para preocuparse.

Estaba en un proyecto donde un dispositivo personalizado preferiría un DHCPOffer que incluía un servidor TFTP donde se podía encontrar firmware actualizado.

— Pensamiento extraño
fuente

... o si un servidor ofreció una dirección que el cliente ya había usado antes y quería mantener

— ilkkachu

@ilkkachu: Sí, en teoría, pero existen mejores mecanismos para esto (tanto renovando una reserva antes de que caduque con el antiguo servidor DHCP o enviando un DHCPDiscovery solicitando la antigua dirección IP) por lo que es poco probable que sea útil en la práctica.

— Pensamiento extraño