DHCPDISCOVER / DHCPOFFER, ancak DHCPACK yok

DHCPDISCOVER'ları gönderen bir uzak istemci makinem var. Sunucu bir DHCPOFFER ile yanıt veriyor, ancak DHCPACK yok.

Bu, aynı ana bilgisayardan her 30 saniyede bir tekrarlanır. Uzaktan yapabileceğim bir şey var mı veya yeniden başlatmak için birini almam gerekiyor mu? Bir veri merkezinde yani bunu yapmak için orada seyahat etmek zorunda kalabilirsiniz!

Önerileriniz için teşekkürler. Tüm makineleri yeniden başlattım, ama hala sorunum var. Konfigürasyonumla ilgili bir sorun olduğunu düşünüyorum. Bu doğru görünüyor mu?

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

Gider:

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

Açıklamanızda DHCPACK'ten önce DHCPREQUEST eksik.

İstemci DHCP sunucusundan farklı bir alt ağ üzerindeyse, DHCPOFFER 67 UDP bağlantı noktasındaki DHCP rölesine tek noktaya yayın gönderilir. DHCP geçiş aracısı, DHCPOFFER'ı UDP bağlantı noktası 68'deki alt ağa yayınlar.

DHCPOFFER ile ilgili bağlantı sorunlarını araştırırım. İzleyin ve istemciye geri dönüş yolunu bulup bulamadığını görün ve eğer yaparsa, istemci neden DHCPREQUEST değil: adresi veriyor.

Ortak bir dhcp röle aracısı, belirli bir arabirim altındaki cisco anahtarlarındaki "ip helper-address" seçeneğidir.

DHCP sunucunuzun ve DHCP istemcinizin aynı ethernet segmentine bağlı olduğunu varsayalım ve bu ethernet segmentinin çeşitli "gövde" ( 802.1q ) bağlantıları ile birbirine bağlı birkaç L2 anahtarını kapsadığını varsayarsak , benzer sorunlarla karşılaştım en az bir ana hat bağlantısının konfigürasyonu arasındaki uyumsuzluk.

Ayrıntılı olarak, (DHCP sunucu tarafında görüldüğü gibi) DHCP-KEŞFEDİN / DHCP-TEKLİF bitmeyen çevrimi, beni DHCP istemci olduğunu düşünelim DEĞİL sopa DHCP reissuing dolayısıyla DHCP-TEKLİF alınması ve -DİSKEN mesajı. Böyle bir DHCP-DISCOVER (DHCP-istemci tarafında görüldüğü gibi) DHCP-SERVER'den doğru şekilde alınır.

Aşağıdaki senaryo dikkate alındığında: iki ana bağlantı noktasının yanlış / yanlış eşleştiği kurulum şu anlama gelir:

• Bagaj boyunca (veya DHCP Sunucusundan DHCP istemcisine) SW A'dan SW B'ye gönderilen VLAN X trafiği UNTAGGED;
• Bagaj boyunca (veya DHCP-İstemciden DHCP sunucusuna) SW B'den SW A'ya gönderilen VLAN X trafiği TAGGED'dir.
• SW B'nin ana bağlantı noktasının yerel VLAN kurulumu nedeniyle, DHCP-İstemcisi DHCP-Sunucusundan paket almaz .

Bu,, arıza tespiti çok kolaydır eğer sizin "kontrol" DHCP-İstemci ana. Böyle bir durumda, supposing eth0 DHCP istemci konak, bir basit tarafından kullanılan ağ arayüzü:

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

gösterecektir eğer istemci DHCP-SERVER DHCP-TEKLİF almak, ya da değil.

Eğer eğer şeyler, arıza tespiti daha zordur değil istemci tarafı kontrol eder.

Not: Yukarıdaki problemlerin yanı sıra diğer ilgili argümanların da, uygun teknolojiler ( GVRP , VTP veya diğer kesin olarak manuel olmayan yapılandırma yaklaşımı gibi) kullanıldığında kolayca önlenebilir , ancak ... bu, bu cevabın kapsamı dışındadır

Aynı sorun vardı. Herhangi bir DHCPACK görmüyorum. Buradaki sorun şuydu:

disk dolu

dhcpd yazamadı /var/lib/dhcp/dhcpd.leases.

Bunu birkaç kez gördüm ve şimdiye kadar sadece iki neden gördüm:

• DHCP sunucusunun verdiği IP adresi zaten başka bir cihaz tarafından kullanılıyor. Genellikle bir DHCPNAK görürsünüz.
• Güvenlik duvarınız dhcp sunucusuna gelen trafiği kabul ediyor, ancak geri dönüş trafiğini kabul etmiyor

Neyse ki her ikisinin de test edilmesi kolay olmalıdır. IP adresine ping atın ve ilgili güvenlik duvarlarını kontrol edin.

Sanal kutu kullanarak güvenlik duvarları hakkında bilgi edindim ve DHCPACK'i sunucuda almamaya benzer bir sorun yaşadım ve bir ubuntu güvenlik duvarı vm için test yeşil (dahili) ağ için yanlış sanal kutu ağ ayarlarını kullandığım ortaya çıktı ve bir test ubuntu istemci vm. Vb dahili ağ yerine NAT ağını kullanırsanız, istemci vm IP'sini DHCP sunucusu vm yerine vb'den alır. Günlükler, istemciden istek alan sunucuyu gösterir, ancak istemci, sunucu yerine geri gönderilen bir ACK elde edemezsiniz, bunun yerine vb.

Benim için istemcideki DHCP sunucusunu (Internet Paylaşımı aracılığıyla) kapatmayı unutmak basit bir durumdu. Bunu kapatır kapatmaz, DHCP kirası kabul edildi:

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