- Este debate tiene 19 respuestas, 11 mensajes y ha sido actualizado por última vez el hace 4 años, 1 mes por
.
-
Entradas
-
Hola Roberto!
Como tú lo mencionas siempre hay «excepciones» a las reglas, tal vez algún cliente tuyo no soporta DHCP, o tal vez algún cliente se encuentra en una red bastante aislada y la comunicación con el servidor DHCP se complica, en fin… hay casos en los cuales no podemos utilizar DHCP y por lo tanto deberíamos realizar las configuraciones de manera manual en todos los dispositivos finales. Sin embargo, en una red en condiciones normales, TODOS los parámetros de direccionamiento IP (IP, Mascara, Gateway y servidores DNS) deberían ser entregados a través de DHCP. Es una mala práctica realizar una configuración manual ya que a medida que tu red crece tu trabajo administrativo para realizar las configuraciones manuales también va creciendo. Todas estas configuraciones de IP deberían ser centralizadas en un servidor DHCP.
Por el otro lado, para el tema del examen considera que Si o Si deberías entregar todos estos parámetros a través de un servidor DHCP.
Atento a tus comentarios.
Saludos cordiales
En la pregunta. 6. ¿Qué número de puerto de destino encontraremos en el header del protocolo UDP en un mensaje DHCP Discover?
53
21
0x0806
67
68
marco la opción de puerto 68 y a la hora de revisar el cuestionario me enmarca como si marcara el puerto 67.Hola Milquicidic!
Efectivamente el puerto de destino de un mensaje DHCP Discover es el puerto 67! =) … esto lo vemos en el minuto 10 de la clase. Si marcas 68 (respuesta errónea) el cuestionarlo te mostrara que deberías marcar la opción 67. Vemos en nuestros registros que en tus 5 intentos marcaste la opción 68 (respuesta errónea)
Intenta de nuevo y coméntanos.
Atento a tus comentarios y pruebas.
Saludos cordiales.
Hola Alvaro.
En la explicación del protocolo DHCP, comentas, que la respuesta SERVIDOR -> CLIENTE del mensaje DHCP ACK es enviada como IP destino a la IP del cliente. Pero, si hasta que el cliente no reciba el DHCP ACK del servidor no llega a tener IP válida en la red… ¿Como puede ser que le enviemos la trama como IP destino (el host que va a configurar)? Teoricamente esa IP aun no existe en la red por que el host no ha terminado de «levantar» con esa IP. ¿No sería más acertado que esa respuesta DHCP-ACK se enviase como IP destino: 255.255.255.255?
Un saludo.
Hola Jose!
Esto se explica en el RFC, te copio el texto completo respecto a este tema:
» Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
unicast delivery. The IP destination address (in the IP header) is
set to the DHCP ‘yiaddr’ address and the link-layer destination
address is set to the DHCP ‘chaddr’ address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
IP address (leading to a deadlock in which the client’s IP address
cannot be delivered until the client has been configured with an IP
address).A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the ‘flags’ field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client’s subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP
clarifications document discusses the ramifications of the use of the
BROADCAST bit
»Como puedes ver, se tienen mecanismos para ambas situaciones, hay dispositivos que aceptan que los mensajes sean enviados a la IP que se está negociando. En el caso que no tengas esos dispositivos, el mensaje debería enviarse como broadcast como tú lo sugieres.
Esto la verdad va depender mucho del sistema operativo donde se implementa el protocolo, si tu haces una captura en Wireshark en Windows 10, veras que el mensaje ACK es enviado a la IP que se ofrece al cliente. Una vez se recibe la confirmación a través del ACK, el cliente utiliza el protocolo ARP para determinar si otro dispositivo en la red está utilizando esa IP para descartarla.
Todo esto lo puedes ver acá: RFC: https://datatracker.ietf.org/doc/html/rfc2131#section-4.4
Espero que ahora quede claro.
Saludos! =)
- Debes estar registrado para responder a este debate.