DHCPDISCOVER / DHCPOFFER, pero no DHCPACK

17

Tengo una máquina cliente remota que envía DHCPDISCOVER. El servidor responde con un DHCPOFFER, pero no hay DHCPACK.

Esto se repite aproximadamente cada 30 segundos desde el mismo host. ¿Hay algo que pueda hacer de forma remota o necesito que alguien lo reinicie? Está en un centro de datos, por lo que es posible que tenga que viajar allí para hacerlo.


Gracias por las sugerencias He reiniciado todas las máquinas, pero todavía tengo problemas. Creo que hay un problema con mi configuración. ¿Esto parece correcto?

#
# /etc/dhcpd.conf for primary DHCP server
#

authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;

# Our fixed hosts
host host2  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }

subnet x.x.x.128 netmask 255.255.255.128 {
  option subnet-mask 255.255.255.128;
  option broadcast-address x.x.x.255;
  option routers x.x.x.129;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Testing pool.
  pool {
    max-lease-time 300; # 5 minutes
    range x.x.x.250 x.x.x.254;
    deny known-clients;
  }

  # Our hosts - I didn't have this pool declaration before, do I need it if I want
  # the hosts to be running dhcp but always get the same address?
  pool {
    max-lease-time 1800;
    range x.x.x.200 x.x.x.220;
    deny unknown-clients;
  }
}
Mate
fuente
DHCPRequest debe venir antes del DHCPAck. ¿Estás viendo eso? Intente ejecutar una captura de paquetes en el servidor y busque DHCPDiscover, DHCPOffer, DHCPRequest y DHCPAck desde y hacia el servidor. ¿Está el cliente en el mismo segmento LAN que el servidor? Si no es así, ¿el enrutador que separa los dos está configurado como un relé DHCP?
joeqwerty
Resultó que el problema se debió a una configuración incorrecta. Tenía un rango estático superpuesto a un rango dinámico.
Matt

Respuestas:

14

Va:

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

Le falta el DHCPREQUEST antes del DHCPACK en su descripción.

Si el cliente está en una subred diferente al servidor DHCP, el DHCPOFFER se envía unidifusión al relé DHCP en el puerto 67 UDP. El agente de retransmisión DHCP transmite el DHCPOFFER a la subred en el puerto UDP 68.

Investigaría problemas de conectividad relacionados con el DHCPOFFER. Rastree y vea si encuentra su camino de regreso al cliente y si lo hace, ¿por qué el cliente no solicita DHCP ?: ing la dirección.

Un agente de retransmisión dhcp común es la opción "dirección de ayuda ip" en los conmutadores de Cisco bajo una interfaz específica.

artifex
fuente
10

Suponiendo que su servidor DHCP y su cliente DHCP estén conectados al mismo segmento de ethernet, y suponiendo que dicho segmento de ethernet abarque varios conmutadores L2 interconectados con varios enlaces "troncales" ( 802.1q ), me he encontrado con problemas similares cuando había Un desajuste entre la configuración de al menos un enlace troncal.

En detalle, el ciclo interminable de DHCP-DISCOVER / DHCP-OFFER (como se ve desde el lado del servidor DHCP), déjame pensar que el cliente DHCP NO está recibiendo la DHCP-OFFER y, por lo tanto, sigue emitiendo el DHCP -DESCUBRE mensaje. Dicho DHCP-DISCOVER (como se ve desde el lado del cliente DHCP) se recibe correctamente desde el servidor DHCP.

Considerando el siguiente escenario: ingrese la descripción de la imagen aquí la configuración incorrecta / no coincidente de los dos puertos troncales significa que:

  • El tráfico de VLAN X enviado por SW A a SW B a lo largo de la troncal (o desde el servidor DHCP al cliente DHCP) no está etiquetada;
  • El tráfico VLAN X enviado por SW B a SW A a lo largo de la troncal (o desde el cliente DHCP al servidor DHCP) se etiqueta.
  • Debido a la configuración VLAN nativa del puerto troncal del SW B, el Cliente DHCP no recibirá paquetes del Servidor DHCP.

Esto es muy fácil de solucionar si "controla" el host DHCP-Client. En tal caso, suponiendo que eth0 es la interfaz de red utilizada por el host del cliente DHCP, un simple:

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

mostrará si el cliente recibe la OFERTA DHCP del SERVIDOR DHCP, o no.

Las cosas son más difíciles de solucionar si se puede no controlar el lado del cliente.

PD: Obviamente, los problemas anteriores, así como otros argumentos relacionados, pueden evitarse fácilmente utilizando tecnologías adecuadas (como GVRP , VTP u otro enfoque de configuración no estrictamente manual) pero ... esto está fuera del alcance de esta respuesta

Damiano Verzulli
fuente
Parece que esto también puede suceder como resultado de un error de software en el servidor DHCP, cuando la interfaz del lado del servidor se conecta a través de diferentes VLAN.
DustWolf
6

Tuve el mismo problema. No veo ningún DHCPACK. El problema aquí fue:

disco lleno

dhcpd no pudo escribir /var/lib/dhcp/dhcpd.leases.

1977er
fuente
Muchas gracias. Estaba viendo descubrir, ofrecer, solicitar, solicitar, solicitar y no reconocer y esta fue la causa. Tampoco había nada en / var / log / syslog, por la misma razón. Ya es hora de que aprenda a comprobar esto primero cuando veo un comportamiento extraño que comienza de repente.
Rob Fisher
3

Lo he visto varias veces y hasta ahora solo he visto dos razones:

  • La dirección IP que proporcionó el servidor DHCP ya está en uso por otro dispositivo. Sin embargo, generalmente verías un DHCPNAK.
  • Su firewall está aceptando el tráfico al servidor dhcp, pero no el tráfico de regreso

Afortunadamente, ambos deberían ser fáciles de probar. Haga ping a la dirección IP y verifique los firewalls relevantes.

Dennis Kaarsemaker
fuente
Gracias. Marqué la dirección ofrecida pero no hubo respuesta. Luego configuré una entrada de host para obligarla a ofrecer una dirección diferente, pero esto no pareció ayudar. Verificará el firewall.
Matt
0

He estado aprendiendo acerca de los firewalls usando la caja virtual y tuve un problema similar al no obtener el DHCPACK en el servidor y resultó que estaba usando la configuración de red de la caja virtual incorrecta para la red verde (interna) de prueba para un firewall vm de ubuntu y una prueba de ubuntu client vm. Si usa la red NAT en lugar de la red interna vb, el cliente vm obtiene su ip de vb en lugar del servidor DHCP vm. Los registros muestran que el servidor recibe la solicitud del cliente, pero el cliente obtiene su ip de vb, por lo que nunca recibirá un ACK devuelto al servidor.

Mark Simmons
fuente
0

Para mí fue un simple caso de olvidar apagar el servidor DHCP (a través de Internet Sharing) en el cliente. Tan pronto como apagué eso, se aceptó el contrato de arrendamiento de DHCP:

Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPREQUEST(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPACK(eth0) 10.0.0.4 40:6c:8f:59:24:8e Heaths-MBP
Heath Raftery
fuente