DHCPDISCOVER / DHCPOFFER, mas nenhum DHCPACK

Eu tenho uma máquina cliente remota que está enviando DHCPDISCOVER. O servidor está respondendo com um DHCPOFFER, mas não há DHCPACK.

Isso se repete a cada 30 segundos no mesmo host. Existe algo que eu possa fazer remotamente ou preciso que alguém o reinicie? Está em um data center, então talvez eu precise viajar até lá para fazer isso!

Obrigado pelas sugestões. Todas as máquinas foram reiniciadas, mas ainda tenho problemas. Eu acho que há um problema com minha configuração. Isso parece correto?

#
# /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;
  }
}

Vai:

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

Está faltando o DHCPREQUEST antes do DHCPACK na sua descrição.

Se o cliente estiver em uma sub-rede diferente do servidor DHCP, o DHCPOFFER será enviado unicast ao DHCP-relay na porta 67 UDP. O agente de retransmissão DHCP transmite o DHCPOFFER para a sub-rede na porta UDP 68.

Eu investigaria problemas de conectividade relacionados ao DHCPOFFER. Rastreie-o e veja se ele encontra o caminho de volta para o cliente e, se encontrar, por que o cliente não está DHCPREQUEST: o endereço.

Um agente de retransmissão dhcp comum é a opção "ip helper-address" nos switches Cisco sob uma interface específica.

Supondo que o servidor DHCP e o cliente DHCP estejam ambos conectados ao mesmo segmento ethernet, e supondo que esse segmento ethernet abranja vários comutadores L2 interconectados com vários links de "tronco" ( 802.1q ), já tive problemas semelhantes quando houve uma incompatibilidade entre a configuração de pelo menos um link de tronco.

Em detalhes, o ciclo interminável de DHCP-DISCOVER / DHCP-OFFER (como visto do lado do servidor DHCP), permita-me pensar que o cliente DHCP NÃO está recebendo o DHCP-OFFER e, portanto, reemitir o DHCP Mensagem -DISCOVER. Esse DHCP-DISCOVER (como visto do lado do cliente DHCP) é recebido corretamente do DHCP-SERVER.

Considerando o seguinte cenário: a configuração incorreta / incompatível das duas portas de tronco significa que:

• O tráfego da VLAN X enviado pelo SW A para o SW B ao longo do tronco (ou do servidor DHCP para o cliente DHCP) é INDEVIDO;
• O tráfego da VLAN X enviado pelo SW B para o SW A ao longo do tronco (ou do cliente DHCP para o servidor DHCP) é marcado.
• devido à configuração nativa da VLAN da porta de tronco do SW B, o cliente DHCP não receberá pacotes do servidor DHCP.

Isso é muito fácil de solucionar, se você "controla" o host do Cliente DHCP. Nesse caso, supondo eth0 é a interface de rede usada pelo host do cliente DHCP, uma simples:

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

mostrará se o cliente recebe ou não a DHCP-OFERTA do DHCP-SERVER.

As coisas são mais difíceis de solucionar se você não pode controlar o lado do cliente.

PS: Obviamente, os problemas acima, assim como outros argumentos relacionados, podem ser facilmente evitados usando tecnologias apropriadas (como GVRP , VTP ou outra abordagem não estritamente manual de configuração), mas ... isso está fora do escopo desta resposta

Teve o mesmo problema. Não está vendo nenhum DHCPACKs. O problema aqui foi:

disco cheio

O dhcpd não pôde gravar /var/lib/dhcp/dhcpd.leases.

Eu já vi isso algumas vezes e até agora só vi duas razões:

• O endereço IP fornecido pelo servidor DHCP já está sendo usado por outro dispositivo. Normalmente você veria um DHCPNAK.
• Seu firewall está aceitando o tráfego no servidor dhcp, mas não o tráfego de volta

Felizmente, ambos devem ser fáceis de testar. Faça ping no endereço IP e verifique os firewalls relevantes.

Eu tenho aprendido sobre firewalls usando caixa virtual e tive um problema semelhante ao não obter o DHCPACK no servidor e descobrimos que estava usando as configurações de rede de caixa virtual incorretas para a rede verde (interna) de teste para um firewall ubuntu vm e um cliente ubuntu de teste vm. Se você usar a rede NAT em vez da rede interna vb, o cliente vm obterá o ip da vb em vez do servidor DHCP vm. Os logs mostram o servidor recebendo a solicitação do cliente, mas o cliente obtém seu IP da vb, para que você nunca receba um ACK enviado de volta ao servidor.

Para mim, foi simples esquecer de desligar o servidor DHCP (via Internet Sharing) no cliente. Assim que eu desliguei, a concessão do DHCP foi aceita:

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