DHCPDISCOVER / DHCPOFFER, ma nessun DHCPACK

Ho una macchina client remota che sta inviando DHCPDISCOVER. Il server risponde con DHCPOFFER, ma non c'è DHCPACK.

Questo si ripete ogni 30 secondi circa dallo stesso host. C'è qualcosa che posso fare da remoto o devo convincere qualcuno a riavviarlo? È in un data center, quindi potrei dover viaggiare lì per farlo!

Grazie per i suggerimenti Ho riavviato tutte le macchine, ma ho ancora problemi. Penso che ci sia un problema con la mia configurazione. Questo sembra corretto?

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

Va:

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

Ti manca il DHCPREQUEST prima del DHCPACK nella tua descrizione.

Se il client si trova su una sottorete diversa rispetto al server DHCP, DHCPOFFER viene inviato unicast al relè DHCP sulla porta 67 UDP. L'agente di inoltro DHCP trasmette DHCPOFFER alla sottorete sulla porta UDP 68.

Esaminerei i problemi di connettività relativi a DHCPOFFER. Tracciarlo e vedere se torna al client e, in caso affermativo, perché il client non è DHCPREQUEST: ing l'indirizzo.

Un agente di inoltro dhcp comune è l'opzione "ip helper-address" negli switch Cisco sotto un'interfaccia specifica.

Supponendo che il tuo server DHCP e il client DHCP siano entrambi collegati allo stesso segmento Ethernet e supponendo che tale segmento Ethernet si estende su più switch L2 interconnessi con vari collegamenti "trunk" ( 802.1q ), ho riscontrato problemi simili quando c'era una discrepanza tra la configurazione di almeno un collegamento trunk.

In dettaglio, il ciclo infinito di DHCP-DISCOVER / DHCP-OFFER (visto dal lato server DHCP), mi fa pensare che il client DHCP NON stia ricevendo l'OFFERTA DHCP e, quindi, continui a riemettere il DHCP -DISCOVER message. Tale DHCP-SCOPRI (visto dal lato client DHCP) viene correttamente ricevuto dal SERVER DHCP.

Considerando il seguente scenario: l'installazione errata / non corrispondente delle due porte trunk significa che:

• Il traffico VLAN X inviato da SW A a SW B lungo il trunk (o dal server DHCP al client DHCP) è DISATTIVATO;
• Il traffico VLAN X inviato da SW B a SW A lungo il trunk (o dal client DHCP al server DHCP) è TAGGED.
• a causa della configurazione VLAN nativa della porta trunk del SW B, il client DHCP non riceverà i pacchetti dal server DHCP.

Questo è molto facile da risolvere se "controlli" l'host DHCP-Client. In tal caso, supponendo che eth0 sia l'interfaccia di rete utilizzata dall'host client DHCP, un semplice:

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

mostrerà se il client riceve l'OFFERTA DHCP dal SERVER DHCP oppure no.

Le cose sono più difficili da risolvere se si può non controllare il lato client.

PS: Ovviamente i problemi sopra riportati, così come altri argomenti correlati, possono essere facilmente evitati utilizzando le tecnologie appropriate (come GVRP , VTP o altri approcci di configurazione non strettamente manuali) ma ... questo non rientra nell'ambito di questa risposta

Aveva lo stesso problema. Non vedo alcun DHCPACK. Il problema qui era:

disco pieno

dhcpd non ha potuto scrivere /var/lib/dhcp/dhcpd.leases.

L'ho visto alcune volte e finora ho visto solo due motivi:

• L'indirizzo IP fornito dal server DHCP è già in uso da un altro dispositivo. Di solito però vedresti un DHCPNAK.
• Il tuo firewall sta accettando il traffico verso il server DHCP, ma non il traffico di ritorno

Fortunatamente entrambi dovrebbero essere facili da testare. Effettua il ping dell'indirizzo IP e controlla i firewall pertinenti.

Ho imparato a conoscere i firewall utilizzando la scatola virtuale e ho avuto un problema simile non riuscendo a ottenere il DHCPACK sul server e si è scoperto che utilizzava le impostazioni di rete della scatola virtuale errate per la rete verde (interna) di prova per un firewall Ubuntu VM e un client di test Ubuntu vm. Se si utilizza la rete NAT anziché la rete interna vb, il client vm ottiene il suo ip da vb anziché dal server DHCP vm. I registri mostrano che il server riceve la richiesta dal client ma il client ottiene invece il suo IP da vb in modo da non ricevere mai un ACK rispedito al server.

Per me è stato un semplice caso di dimenticare di disattivare il server DHCP (tramite Internet Sharing) sul client. Non appena l'ho disattivato, il contratto di locazione DHCP è stato accettato:

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