DHCPDISCOVER / DHCPOFFER, ale brak DHCPACK

Mam zdalny komputer kliencki, który wysyła DHCPDISCOVER. Serwer odpowiada DHCPOFFER, ale nie ma DHCPACK.

Powtarza się to co 30 sekund z tego samego hosta. Czy jest coś, co mogę zrobić zdalnie, czy muszę poprosić kogoś o ponowne uruchomienie? Jest w centrum danych, więc być może będę musiał tam pojechać!

Dziękuję za sugestie. Ponownie uruchomiłem wszystkie maszyny, ale nadal mam problemy. Myślę, że jest problem z moją konfiguracją. Czy to wygląda poprawnie?

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

To idzie:

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

W opisie brakuje DHCPREQUEST przed DHCPACK.

Jeśli klient znajduje się w innej podsieci niż serwer DHCP, DHCPOFFER jest wysyłany w trybie emisji pojedynczej do przekaźnika DHCP na porcie 67 UDP. Agent przekazywania DHCP rozgłasza DHCPOFFER do podsieci na porcie UDP 68.

Zbadałbym problemy z łącznością związane z DHCPOFFER. Śledź go i zobacz, czy znajdzie drogę powrotną do klienta, a jeśli tak, dlaczego klient nie jest DHCPREQUEST: wpisanie adresu.

Typowym agentem przekaźnika dhcp jest opcja „adres pomocnika ip” w przełącznikach cisco w ramach określonego interfejsu.

Przypuśćmy, że zarówno serwer DHCP, jak i klient DHCP są podłączone do tego samego segmentu Ethernet, i przypuśćmy, że taki segment Ethernet obejmuje kilka przełączników L2 połączonych różnymi linkami „trunk” ( 802.1q ), napotkałem podobne problemy, kiedy niedopasowanie między konfiguracją co najmniej jednego łącza trunk.

Szczegółowo, niekończący się cykl DHCP-DISCOVER / DHCP-OFFER (widziany od strony serwera DHCP), pozwól mi pomyśleć, że klient DHCP NIE odbiera DHCP-OFFER, a zatem kij ponownie uruchamia DHCP Komunikat ODKRYJ. Taki DHCP-DISCOVER (widziany od strony klienta DHCP) jest poprawnie odbierany od DHCP-SERVER.

Biorąc pod uwagę następujący scenariusz: niewłaściwa / niedopasowana konfiguracja dwóch portów magistrali oznacza, że:

• Ruch VLAN X wysyłany przez SW A do SW B wzdłuż łącza (lub z serwera DHCP do klienta DHCP) jest NIEZNAKOWANY;
• Ruch VLAN X wysyłany przez SW B do SW A wzdłuż linii miejskiej (lub od klienta DHCP do serwera DHCP) jest ZNAKOWANY.
• ze względu na natywną konfigurację VLAN portu trunk SW SW, klient DHCP nie będzie odbierał pakietów z serwera DHCP.

Rozwiązanie tego problemu jest bardzo łatwe, jeśli „kontrolujesz” hosta klienta DHCP. W takim przypadku, zakładając, że eth0 jest interfejsem sieciowym używanym przez hosta klienta DHCP, proste:

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

pokaże, czy klient otrzyma DHCP-OFERĘ od SERWERA DHCP, czy nie.

Rzeczy są bardziej trudne do rozwiązania, jeśli może nie kontrolować po stronie klienta.

PS: Oczywiście powyższe problemy, a także inne pokrewne argumenty, można łatwo uniknąć przy użyciu odpowiednich technologii (takich jak GVRP , VTP lub inne niekonfiguracyjne podejście do konfiguracji), ale ... to nie wchodzi w zakres tej odpowiedzi

Miałem ten sam problem. Nie widzę żadnych DHCPACK. Problem polegał na:

Dysk jest pełny

dhcpd nie mógł pisać /var/lib/dhcp/dhcpd.leases.

Widziałem to kilka razy i do tej pory widziałem tylko dwa powody:

• Adres IP podany przez serwer DHCP jest już używany przez inne urządzenie. Zazwyczaj jednak widzisz DHCPNAK.
• Zapora akceptuje ruch do serwera dhcp, ale nie ruch z powrotem

Na szczęście oba powinny być łatwe do przetestowania. Sprawdź ping adres IP i sprawdź odpowiednie zapory ogniowe.

Dowiedziałem się o zaporach przy użyciu wirtualnego boxa i miałem podobny problem z brakiem DHCPACK na serwerze i okazało się, że używałem niewłaściwych ustawień sieciowych wirtualnego boxa dla testowej zielonej (wewnętrznej) sieci dla firewalla ubuntu vm i testowy klient Ubuntu VM. Jeśli używasz sieci NAT zamiast sieci wewnętrznej vb, klient vm otrzymuje swój adres IP z vb zamiast z serwera DHCP vm. Dzienniki pokazują, że serwer otrzymuje żądanie od klienta, ale zamiast tego klient otrzymuje swój adres IP z vb, więc nigdy nie otrzymujesz ACK odesłanego z powrotem do serwera.

Dla mnie był to prosty przypadek zapomnienia wyłączenia serwera DHCP (poprzez Udostępnianie Internetu) na kliencie. Gdy tylko to wyłączyłem, dzierżawa DHCP została zaakceptowana:

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