Apa yang dianggap klien DHCP sebagai jawaban "terbaik"?

Kami memiliki ruang pelatihan di mana biasanya Windows XP diinstal (melalui PXE). Infrastruktur DNS / DHCP "normal" adalah Windows-Server. Ruang pelatihan memiliki VLAN sendiri (berbeda dari server Windows), jadi ada pembantu IP untuk permintaan DHCP yang aktif di router Cisco di mana semua PC dari ruangan itu terhubung.

Sekarang kami ingin mengubah beberapa PC ke Linux sebagai gantinya. Idenya adalah: Letakkan Laptop kita sendiri dengan server DHCP ke dalam VLAN ruangan dan ganti respon DHCP "normal". Idenya adalah bahwa ini harus bekerja, karena server DHCP yang terpasang langsung di VLAN harus memiliki waktu respons yang lebih cepat daripada server DHCP "normal" yang terletak beberapa lompatan jauh dari VLAN itu.

Ternyata ini tidak berhasil. Kami harus merilis secara manual pada server DHCP asli untuk membuatnya berfungsi.

Di Laptop kami melihat klien meminta IP dan "kami" dhcp mengirim NACK ke permintaan IP Windows, sebelum itu kami memang menawarkan respons kami sendiri.

Pertanyaan Lama: Mengapa ini tidak berhasil seperti yang diharapkan? Apa yang membuat PC mendapatkan kembali sewa lamanya?

Pembaruan 2012-08-08:

Masalah mendapatkan kembali telah dijelaskan dalam DHCP-RFC. Sekarang ini menjelaskan mengapa PC mendapatkan kembali sewa lamanya.

Sekarang kita melepaskan IP dari server Windows-DHCP sebelum mencobanya lagi.

Lagi - Windows-DHCP-server menang.

Saya menduga ada beberapa algoritma untuk dhcp-client yang menentukan "terbaik" dhcp-answer untuk klien. Pertanyaan baru adalah:

Bagaimana klien memilih jawaban "terbaik"?

Ini adalah vendor, bahkan firmware khusus bagaimana klien bereaksi terhadap beberapa jawaban DHCP.

Varian yang telah saya lihat selama ini adalah:

1) Terima dulu terlepas dari apakah itu ACK atau NACK.

2) Ambil ACK pertama, abaikan NACK sepenuhnya.

3) Ambil ACK terakhir yang diterima dalam interval waktu tertentu (biasanya 5-10 detik).

Contoh: Beberapa tahun yang lalu kami memiliki masalah dengan Ricoh MFP.
Kami memiliki 2 server DHCP. Satu memberikan alamat, yang lain hanya opsi DHCP tambahan. Server ke-2 selalu menjawab lebih dulu.
Varian Ricoh yang digunakan 1) bahkan jika penawaran pertama hanya berisi opsi DHCP. Ricoh mengubahnya menjadi varian 2) dengan pembaruan firmware setelah kami menjelaskan masalahnya kepada mereka.

Dengan asumsi router masih bertindak sebagai relay DHCP dan meneruskan permintaan ke server asli Anda, maka alasannya adalah karena server DHCP Windows memerintahkannya untuk terus maju dan menggunakan IP. Dalam hal ini DHCPNACK dari server baru tidak relevan, karena klien DHCP akan mempertimbangkan semua tanggapan, dan karena mendapat tawaran dari kotak Windows DHCP, sangat senang menggunakannya.

PC: Oh hai dunia, dapatkah saya menggunakan 192.168.1.123?

Baru-DHCP: Saya katakan tidak.

Old-DHCP: Saya katakan ya.

PC: Seseorang berkata ya! Manis, aku akan menggunakannya!

Jika tidak ada yang membantu - RTFM (baca manual bagus). Dalam hal ini yang pertama adalah hit.

RFC 2131 menguraikan operasi DHCP.

Bagian 1.6 menyatakan bahwa DHCP harus :

Mempertahankan konfigurasi klien DHCP di seluruh reboot server, dan, jika memungkinkan, klien DHCP harus diberikan parameter konfigurasi yang sama meskipun telah memulai kembali mekanisme DHCP,

Sekarang pertanyaan yang menarik adalah bagaimana tujuan desain itu dicapai pada klien yang tidak memiliki pengetahuan tentang masa lalunya. Bagian 3.2 menguraikan:

3.2 Interaksi klien-server - menggunakan kembali alamat jaringan yang sebelumnya dialokasikan

Jika klien ingat dan ingin menggunakan kembali
alamat jaringan yang dialokasikan sebelumnya , klien dapat memilih untuk menghilangkan beberapa langkah yang
dijelaskan di bagian sebelumnya. Diagram garis waktu pada gambar 4
menunjukkan hubungan waktu dalam interaksi client-server tipikal untuk klien menggunakan kembali alamat jaringan yang sebelumnya dialokasikan.

1. Klien menyiarkan pesan DHCPREQUEST di subnet lokalnya. Pesan tersebut mencakup alamat jaringan klien dalam opsi 'alamat IP yang diminta'. Karena klien belum menerima alamat jaringannya, ia TIDAK HARUS mengisi bidang 'ciaddr'. Agen relai BOOTP meneruskan pesan ke server DHCP bukan pada subnet yang sama. Jika klien menggunakan 'pengidentifikasi klien' untuk mendapatkan alamatnya, klien HARUS menggunakan 'pengidentifikasi klien' yang sama dalam pesan DHCPREQUEST.

2. Server dengan pengetahuan tentang parameter konfigurasi klien merespons dengan pesan DHCPACK ke klien. Server TIDAK HARUS memeriksa bahwa alamat jaringan klien sudah digunakan; klien dapat menanggapi pesan ICMP Echo Request pada saat ini.

Jadi DHCP-server memegang sewa aktif diutamakan dengan menggunakan cara pintas di protcol.

1. Klien: DHCREQUEST (Alamat MAC, siaran, akan ditransmisikan dalam domain siaran lokal - di sini VLAN lokal dan melalui bantuan IP ke server Windows-DHCP)
2. Laptop-DHCP-Server: DHCPOFFER
3. Windows-DHCP-Server: Hai - Saya sudah tahu Anda - DHCPACK
4. Klien: Oh - Saya mendapat dua tanggapan. Yang sudah mengenal saya. Keren aku akan mengambilnya

Sejak saat itu Laptop-DHCP-Server diabaikan oleh Klien.

Jadi solusi dalam kasus kami mungkin akan (saya akan memperbarui ini ketika kami benar-benar mengujinya):

1. Pastikan Klien tidak aktif
2. Matikan DHCP-Server di Laptop, Client-MAC palsu di Laptop, DHCP-Request
3. Rilis IP
4. Dapatkan kembali IP dan MAC asli, nyalakan DHCP-Server
5. Nyalakan klien dan lakukan PXE-boot ...

Pertanyaan baru mungkin harus dalam pertanyaan yang berbeda - judul pertanyaan tidak cocok sama sekali dengan sebagian besar isi pertanyaan.

Dalam hal apa pun, berkenaan dengan bagaimana klien memilih penawaran mana yang akan digunakan, dalam kasus di mana ia tidak memiliki sewa saat ini: terserah klien, tetapi dalam setiap implementasi klien DHCP yang saya ketahui, ini adalah perlombaan sederhana .

RFC 2131 mencakup ini:

Klien DHCP bebas menggunakan strategi apa pun dalam memilih server DHCP di antara yang darinya klien menerima pesan DHCPOFFER.

Ada rancangan IETF di luar sana yang tampaknya sudah mati yang akan menambah konfigurasi pada proses seleksi, dan juga menyebutkan implementasi klien yang kurang bersemangat (lebih dari satu dekade lalu, tetapi tidak banyak yang berubah):

Dalam praktiknya, sebagian besar implementasi kebijakan vendor di sini sangat mendasar (mis., Tawaran pertama diterima atau diterima pertama kali diterima) dan "dikodekan keras" (yaitu, tidak dapat dikonfigurasi).

Memiliki dua server DHCP yang menyediakan layanan ke jaringan yang sama dengan konfigurasi yang berbeda hanya menghasilkan balapan, yang tidak diinginkan dari perspektif keandalan atau prediktabilitas. Sebenarnya tidak ada alasan Anda tidak bisa mendapatkan server DHCP tunggal untuk memberikan apa yang Anda butuhkan.