DHCP istemcisi “en iyi” yanıt olarak neyi düşünür?

Normalde Windows XP'nin kurulu olduğu eğitim odalarımız vardır (PXE üzerinden). "Normal" DNS / DHCP altyapısı Windows Sunucularıdır. Eğitim odasının kendi VLAN'ı vardır (Windows sunucularından farklıdır), bu nedenle, o odadaki tüm PC'lerin bağlı olduğu Cisco yönlendiricisinde etkin olan DHCP istekleri için en uygun şekilde bir IP yardımcısı vardır.

Şimdi bunun yerine bazı bilgisayarları Linux'a dönüştürmek istedik. Fikir şuydu: Kendi Dizüstü Bilgisayarımızı bir DHCP sunucusuyla odanın VLAN'ına koyun ve "normal" DHCP yanıtını geçersiz kılın. Fikir, bunun işe yaramasıydı, çünkü o VLAN'daki doğrudan bağlı bir DHCP sunucusunun, o VLAN'dan bazı atlamaların bulunduğu "normal" DHCP sunucusundan daha hızlı bir tepki süresi olması gerekirdi.

Bunun işe yaramadığı ortaya çıktı. Çalışması için orijinal DHCP sunucusundaki kiralamayı manuel olarak serbest bırakmamız gerekiyordu.

Dizüstü bilgisayarda IP isteyen istemciyi gördük ve "bizim" dhcp Windows IP isteğine NACK'ler gönderiyor, daha önce kendi yanıtımızı sunduk.

Eski Soru: Neden beklendiği gibi sonuçlanmadı? Bilgisayarı eski kira sözleşmesine kavuşturan nedir?

2012-08-08 Güncellemesi :

Geri alma sorunu DHCP-RFC'de açıklanmıştır. Şimdi bu, PC'nin neden eski kira sözleşmesini yeniden kazandığını açıklıyor.

Şimdi IP'yi başka bir deneme yapmadan önce Windows-DHCP sunucusundan serbest bırakıyoruz.

Yine - Windows-DHCP sunucusu kazanır.

Ben dhcp-istemci için "en iyi" dhcp-cevap belirleyen bazı algoritma olduğundan şüpheleniyorum. Yeni soru:

Müşteri "en iyi" yanıtı nasıl seçer?

Bir istemcinin birden çok DHCP yanıtına nasıl tepki verdiğine dair, hatta üretici yazılımına özgüdür.

Yıllar içinde gördüğüm varyantları:

1) ACK veya NACK olsun, ilkini kabul edin.

2) İlk ACK'yı alın, NACK'leri tamamen yok sayın.

3) Alınan son ACK'yı belirli bir zaman aralığında (genellikle 5-10 saniye) alın.

Örnek: Birkaç yıl önce Ricoh MFP'lerle ilgili sorunlar yaşadık.
2 DHCP sunucumuz vardı. Biri adresleri, diğeri sadece ek DHCP seçeneklerini sağladı. 2. sunucu her zaman önce cevap verdi.
Ricoh'un kullandığı varyant 1), ilk teklifte yalnızca DHCP seçenekleri olsa bile. Ricoh bunu değişken 2 olarak değiştirdi) ve sorunu onlara açıkladıktan sonra bir ürün yazılımı güncellemesi ile.

Yönlendiricinin hala bir DHCP geçişi olarak davrandığını ve isteği orijinal sunucunuza ilettiğini varsayarsak, bunun nedeni basitçe Windows DHCP sunucusunun devam etmesini ve IP'yi kullanmasını söylemesidir. Bu örnekte, bir DHCP istemcisi tüm yanıtları dikkate alacağından ve Windows DHCP kutusundan bir teklif aldığından, yeni sunucudan gelen DHCPNACK önemsizdir.

PC: Merhaba dünya, 192.168.1.123 kullanabilir miyim?

Yeni-DHCP: Hayır diyorum.

Eski DHCP: Evet diyorum.

PC: Birisi evet dedi! Tatlı, kullanacağım!

Başka bir şey yardımcı olmazsa - RTFM (ince kılavuzu okuyun). Bu durumda birincisi hit oldu.

RFC 2131 , DHCP işlemlerini özetlemektedir.

Bölüm 1.6 devletler DHCP o must :

Sunucu yeniden başlatıldığında DHCP istemci yapılandırmasını koruyun ve mümkünse DHCP mekanizmasının yeniden başlatılmasına rağmen bir DHCP istemcisine aynı yapılandırma parametreleri atanmalıdır,

Şimdi ilginç olan soru, tasarım bilgisi geçmişine dair bilgisi olmayan bir müşteriye nasıl ulaşıldığıdır. Bölüm 3.2 ana hatları:

3.2 İstemci-sunucu etkileşimi - önceden ayrılmış bir ağ adresini yeniden kullanma

Bir istemci daha önce ayrılmış bir
ağ adresini hatırlar ve yeniden kullanmak isterse , istemci
önceki bölümde açıklanan adımların bazılarını atlamayı seçebilir . Şekil 4'teki zaman çizelgesi diyagramı,
daha önce ayrılmış bir ağ adresini yeniden kullanan bir istemci için tipik bir istemci-sunucu etkileşimindeki zamanlama ilişkilerini gösterir.

1. İstemci yerel alt ağında bir DHCPREQUEST iletisi yayınlar. İleti, istemcinin ağ adresini 'istenen IP adresi' seçeneğine ekler. İstemci ağ adresini almadığından, 'ciaddr' alanını DOLDURMAMALIDIR. BOOTP geçiş aracıları iletiyi aynı alt ağda olmayan DHCP sunucularına iletir. İstemci adresini almak için bir 'istemci tanımlayıcısı' kullandıysa, istemcinin DHCPREQUEST iletisinde aynı 'istemci tanımlayıcısını' KULLANMASI GEREKİR.

2. İstemcinin yapılandırma parametreleri hakkında bilgi sahibi olan sunucular, istemciye bir DHCPACK iletisi ile yanıt verir. Sunucular, istemcinin ağ adresinin zaten kullanımda olup olmadığını kontrol ETMEMELİDİR; istemci bu noktada ICMP Yankı İsteği iletilerine yanıt verebilir.

Dolayısıyla, aktif bir kira kontratı tutan bir DHCP sunucusu, protolde bir kısayol kullanarak öncelik kazanır.

1. İstemci: DHCREQUEST (MAC-Adress, yayın, yerel yayın alanında iletilecek - burada yerel VLAN ve IP yardımcısı aracılığıyla Windows-DHCP sunucusuna)
2. Dizüstü-DHCP Sunucusu: DHCPOFFER
3. Windows-DHCP-Sunucu: Hey - Seni zaten tanıyorum - DHCPACK
4. Müşteri: Oh - İki yanıt aldım. Beni zaten tanıyan biri. Havalı alacağım

O andan itibaren Laptop-DHCP-Server İstemci tarafından yok sayılıyor.

Yani bizim durumumuzdaki çözüm muhtemelen olacak (gerçekten test ettiğimizde bunu güncelleyeceğim):

1. İstemcinin kapalı olduğundan emin olun
2. Dizüstü Bilgisayarda DHCP Sunucusunu, Dizüstü Bilgisayarda Sahte İstemci-MAC'i, DHCP Talebini Kapatın
3. Yayın IP'si
4. Orijinal IP ve MAC'i yeniden kazanın, DHCP Sunucusunu açın
5. İstemciyi açın ve PXE önyükleme yapın ...

Yeni soru muhtemelen farklı bir soruda olmalıdır - sorunun başlığı sorunun büyük kısmına hiç uymuyor.

Her durumda, bir müşterinin hangi teklifi seçeceğini nasıl seçtiği konusunda, mevcut bir kira sözleşmesi olmadığı durumlarda: bu müşteriye bağlıdır, ancak farkında olduğum her DHCP istemci uygulamasında basit bir yarış .

RFC 2131 bunu kapsar:

DHCP istemcileri, istemciden bir DHCPOFFER iletisi alanlar arasından bir DHCP sunucusu seçerken herhangi bir stratejiyi kullanmakta serbesttir.

Seçim sürecine yapılandırılabilirlik ekleyecek ölü gibi görünen bir IETF taslağı var ve aynı zamanda (on yıldan fazla bir süre önce, ama çok fazla değişmeyen) zayıf istemci uygulamalarından bahsediyor:

Uygulamada, çoğu tedarikçinin buradaki politikayı uygulaması çok basittir (örneğin, ilk teklif alındı ​​veya ilk kabul edilebilir teklif alındı) ve "sabit kodlanmış" (yani yapılandırılamaz).

Farklı yapılandırmayla aynı ağa hizmet veren iki DHCP sunucusuna sahip olmak, yalnızca güvenilirlik veya öngörülebilirlik açısından arzu edilmeyen yarışlara neden olur. İhtiyacınız olanı sağlamak için tek DHCP sunucunuzu alamamanızın hiçbir nedeni yoktur.