DHCPDISCOVER / DHCPOFFER, tetapi tidak ada DHCPACK

Saya memiliki mesin klien jarak jauh yang mengirimkan DHCPDISCOVER. Server merespons dengan DHCPOFFER, tetapi tidak ada DHCPACK.

Ini berulang setiap 30 detik dari host yang sama. Apakah ada sesuatu yang bisa saya lakukan dari jarak jauh atau saya perlu seseorang untuk mem-boot-ulangnya? Itu ada di pusat data jadi saya mungkin harus pergi ke sana untuk melakukannya!

Terima kasih atas sarannya. Semua mesin saya reboot, tetapi saya masih memiliki masalah. Saya pikir ada masalah dengan konfigurasi saya. Apakah ini terlihat benar?

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

Begini:

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

Anda Anda melewatkan DHCPREQUEST sebelum DHCPACK dalam uraian Anda.

Jika klien menggunakan subnet berbeda dari server DHCP, DHCPOFFER dikirim unicast ke relay-DHCP pada port 67 UDP. Agen DHCP-relay menyiarkan DHCPOFFER ke subnet pada port UDP 68.

Saya akan menyelidiki masalah konektivitas yang terkait dengan DHCPOFFER. Lacak dan lihat apakah ia menemukan jalannya kembali ke klien dan jika ya, mengapa klien tidak DHCPREQUEST: ing the address.

Agen relay dhcp yang umum adalah opsi "ip helper-address" di cisco switch di bawah antarmuka tertentu.

Andaikata server DHCP dan klien DHCP keduanya terhubung ke segmen ethernet yang sama, dan seandainya segmen ethernet tersebut mencakup beberapa L2-switch yang saling terhubung dengan berbagai tautan "trunk" ( 802.1q ), saya mengalami masalah serupa ketika ada ketidakcocokan antara konfigurasi setidaknya satu trunk link.

Secara rinci, siklus DHCP-DISCOVER / DHCP-OFFER yang tidak pernah berakhir (seperti yang terlihat dari sisi server DHCP), biarkan saya berpikir bahwa klien DHCP TIDAK menerima DHCP-PENAWARAN dan, karenanya, tetap menerbitkan kembali DHCP. Pesan -DISCOVER. DHCP-DISCOVER (seperti yang terlihat dari sisi DHCP-client) diterima dengan benar dari DHCP-SERVER.

Mempertimbangkan skenario berikut: pengaturan yang salah / tidak cocok dari dua port trunk berarti bahwa:

• Lalu lintas VLAN X yang dikirim oleh SW A ke SW B di sepanjang trunk (atau dari DHCP-Server ke DHCP-client), adalah UNTAGGED;
• Lalu lintas VLAN X yang dikirim oleh SW B ke SW A di sepanjang trunk (atau dari DHCP-Client ke DHCP-server), adalah TAGGED.
• karena pengaturan VLAN asli dari port trunk SW B, DHCP-Client tidak akan menerima paket dari DHCP-Server.

Ini sangat mudah untuk memecahkan masalah, jika Anda "mengendalikan" host DHCP-Client. Dalam kasus seperti itu, seandainya eth0 adalah antarmuka jaringan yang digunakan oleh host DHCP-client, sederhana:

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

akan menunjukkan apakah klien menerima DHCP-PENAWARAN dari DHCP-SERVER, atau tidak.

Hal-hal yang lebih sulit untuk dipecahkan jika Anda tidak dapat mengontrol sisi klien.

PS: Jelas masalah di atas, serta argumen terkait lainnya, dapat dengan mudah dihindari menggunakan teknologi yang tepat (seperti GVRP , VTP atau pendekatan tidak-manual-konfigurasi-lainnya) tetapi ... ini berada di luar cakupan jawaban ini

Punya masalah yang sama. Tidak melihat DHCPACKs. Masalahnya di sini adalah:

disk penuh

dhcpd tidak bisa menulis /var/lib/dhcp/dhcpd.leases.

Saya telah melihat ini beberapa kali dan sejauh ini saya hanya melihat dua alasan:

• Alamat IP yang diberikan server DHCP sudah digunakan oleh perangkat lain. Biasanya Anda akan melihat DHCPNAK.
• Firewall Anda menerima lalu lintas ke server dhcp, tetapi bukan lalu lintas kembali

Untungnya keduanya harus mudah diuji. Ping alamat IP dan periksa firewall yang relevan.

Saya telah belajar tentang firewall menggunakan kotak virtual dan saya memiliki masalah yang sama tidak mendapatkan DHCPACK di server dan ternyata menggunakan pengaturan jaringan kotak virtual yang salah untuk jaringan uji hijau (internal) untuk firewall ubuntu vm dan klien uji ubuntu vm. Jika Anda menggunakan jaringan NAT daripada jaringan internal vb klien vm mendapatkan ip-nya dari vb daripada server DHCP vm. Log menunjukkan server mendapatkan permintaan dari klien tetapi klien mendapatkan ip-nya dari vb sehingga Anda tidak pernah mendapatkan ACK yang dikirim kembali ke server.

Bagi saya itu adalah kasus sederhana lupa mematikan server DHCP (melalui Internet Sharing) pada klien. Segera setelah saya mematikannya, penyewaan DHCP diterima:

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