DHCPDISCOVER / DHCPOFFER, mas nenhum DHCPACK

17

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;
  }
}
Matt
fonte
O DHCPRequest deve vir antes do DHCPAck. Você está vendo isso? Tente executar uma captura de pacote no servidor e procure o DHCPDiscover, DHCPOffer, DHCPRequest e DHCPAck de e para o servidor. O cliente está no mesmo segmento da LAN que o servidor? Caso contrário, o roteador está separando os dois configurados como um relé DHCP?
Joeqwerty
Acabou que o problema se devia a uma configuração incorreta. Eu tinha um intervalo estático sobreposto a um intervalo dinâmico.
Matt

Respostas:

13

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.

artifex
fonte
10

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: insira a descrição da imagem aqui 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

Damiano Verzulli
fonte
Parece que isso também pode acontecer como resultado de um erro de software no servidor DHCP, quando a interface do lado do servidor é conectada através de diferentes VLANs.
DustWolf
6

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.

1977er
fonte
Muito Obrigado. Eu estava vendo descobrir, oferecer, solicitar, solicitar, solicitar e não reconhecer, e essa foi a causa. Também não havia nada em / var / log / syslog, pelo mesmo motivo. Já era hora de aprender a verificar isso primeiro quando vejo um comportamento estranho que começa de repente.
Rob Fisher
3

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.

Dennis Kaarsemaker
fonte
Obrigado. Eu sibilei o endereço oferecido, mas nenhuma resposta. Em seguida, configurei uma entrada de host para forçá-lo a oferecer um endereço diferente, mas isso não pareceu ajudar. Irá verificar o firewall.
Matt
0

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.

Mark Simmons
fonte
0

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
Heath Raftery
fonte