DHCPDISCOVER / DHCPOFFER, nhưng không có DHCPACK


16

Tôi có một máy khách từ xa đang gửi DHCPDISCOVER. Máy chủ đang phản hồi với DHCPOFFER, nhưng không có DHCPACK.

Điều này lặp lại khoảng 30 giây từ cùng một máy chủ. Có điều gì tôi có thể làm từ xa hoặc tôi cần phải nhờ ai đó khởi động lại? Nó ở trong một trung tâm dữ liệu nên tôi có thể phải đi đến đó để làm điều đó!


Cảm ơn những lời đề nghị. Tôi đã khởi động lại tất cả các máy, nhưng tôi vẫn gặp sự cố. Tôi nghĩ rằng có một vấn đề với cấu hình của tôi. Điều này có đúng không?

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

DHCPRequest nên đến trước DHCPAck. Bạn có thấy điều đó không? Hãy thử chạy một gói chụp trên máy chủ và tìm DHCPDiscover, DHCP Offerer, DHCPRequest và DHCPAck đến và từ máy chủ. Là máy khách trên cùng phân khúc LAN với máy chủ? Nếu không, bộ định tuyến có tách hai cấu hình như một rơle DHCP không?
joeqwerty

Hóa ra vấn đề là do cấu hình sai. Tôi đã có một phạm vi tĩnh chồng lên một phạm vi năng động.
Matt

Câu trả lời:


13

Nó đi:

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

Bạn đang thiếu DHCPREQUEST trước DHCPACK trong phần mô tả của bạn.

Nếu máy khách ở trên một mạng con khác với máy chủ DHCP, DHCPOFFER sẽ được gửi unicast tới DHCP-rơle trên cổng 67 UDP. Tác nhân chuyển tiếp DHCP phát DHCPOFFER đến mạng con trên cổng UDP 68.

Tôi sẽ điều tra các vấn đề kết nối liên quan đến DHCPOFFER. Theo dõi nó và xem nếu nó tìm thấy đường trở lại máy khách và nếu có, tại sao máy khách không DHCPREQUEST: nhập địa chỉ.

Một tác nhân chuyển tiếp dhcp phổ biến là tùy chọn "ip helper-address" trong cisco switch dưới một giao diện cụ thể.


10

Giả sử máy chủ DHCP và máy khách DHCP của bạn đều được kết nối với cùng một phân đoạn ethernet và giả sử phân đoạn ethernet đó kéo dài một số công tắc L2 được kết nối với các liên kết "trung kế" ( 802.1q ) khác nhau , tôi đã gặp phải vấn đề tương tự khi có sự không phù hợp giữa cấu hình của ít nhất một liên kết trung kế.

Cụ thể, chu trình không bao giờ kết thúc của DHCP-DISCOVER / DHCP-OFFER (như được thấy từ phía máy chủ DHCP), tôi nghĩ rằng DHCP-client KHÔNG nhận được DHCP-OFFER và do đó, phát hành lại DHCP Tin nhắn -DISCOVER. DHCP-DISCOVER như vậy (nhìn từ phía máy khách DHCP) được nhận chính xác từ DHCP-SERVER.

Xem xét kịch bản sau đây: nhập mô tả hình ảnh ở đây thiết lập sai / không khớp của hai cổng trung kế có nghĩa là:

  • Lưu lượng Vlan X được gửi bởi SW A đến SW B dọc theo thân cây (hoặc từ DHCP-Server đến DHCP-client), là UNTAGGED;
  • Lưu lượng Vlan X được gửi bởi SW B đến SW A dọc theo thân cây (hoặc từ DHCP-Client đến DHCP-server), được TAGGED.
  • do thiết lập Vlan gốc của cổng trung kế của SW B, DHCP-Client sẽ không nhận được các gói từ DHCP-Server.

Điều này rất dễ khắc phục sự cố, nếu bạn "điều khiển" máy chủ DHCP-Client. Trong trường hợp như vậy, giả sử eth0 là giao diện mạng được sử dụng bởi máy chủ DHCP-client, một cách đơn giản:

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

sẽ hiển thị nếu khách hàng nhận được DHCP-OFFER từ DHCP-SERVER hay không.

Mọi thứ sẽ khó khắc phục hơn nếu bạn không thể kiểm soát phía máy khách.

PS: Rõ ràng các vấn đề ở trên, cũng như các đối số liên quan khác, có thể dễ dàng tránh được các công nghệ phù hợp đã sử dụng (như GVRP , VTP hoặc phương pháp tiếp cận không thủ công-cấu hình khác) nhưng ... đây không nằm trong phạm vi của câu trả lời này


Dường như điều này cũng có thể xảy ra do lỗi phần mềm trong máy chủ DHCP, khi giao diện phía máy chủ được bắc cầu qua các Vlan khác nhau.
DustWolf

6

Có cùng một vấn đề. Không thấy bất kỳ DHCPACK nào. Vấn đề ở đây là:

đĩa đầy

dhcpd không thể viết thư cho /var/lib/dhcp/dhcpd.leases.


Cảm ơn nhiều. Tôi đã thấy khám phá, đề nghị, yêu cầu, yêu cầu, yêu cầu và không có ack và đây là nguyên nhân. Không có gì trong / var / log / syslog, vì lý do tương tự. Đã đến lúc tôi học cách kiểm tra điều này trước tiên khi tôi thấy hành vi lạ bắt đầu đột ngột.
Rob Fisher

3

Tôi đã thấy điều này một vài lần và cho đến nay tôi chỉ thấy hai lý do:

  • Địa chỉ IP mà máy chủ DHCP cung cấp đã được sử dụng bởi một thiết bị khác. Thông thường, bạn sẽ thấy DHCPNAK.
  • Tường lửa của bạn chấp nhận lưu lượng truy cập đến máy chủ dhcp, nhưng không lưu lượng truy cập trở lại

May mắn là cả hai nên dễ dàng để kiểm tra. Ping địa chỉ IP và kiểm tra tường lửa có liên quan.


Cảm ơn. Tôi ping địa chỉ được cung cấp nhưng không có phản hồi. Sau đó tôi đã thiết lập một mục lưu trữ cho nó buộc nó phải cung cấp một địa chỉ khác nhưng điều này dường như không có ích. Sẽ kiểm tra tường lửa.
Matt

0

Tôi đã tìm hiểu về tường lửa bằng hộp ảo và tôi gặp vấn đề tương tự là không nhận được DHCPACK trên máy chủ và hóa ra đó là sử dụng sai cài đặt mạng hộp ảo cho mạng thử nghiệm (nội bộ) màu xanh lá cây cho tường lửa ub Ubuntu vm và một thử nghiệm ubfox khách hàng vm. Nếu bạn sử dụng mạng NAT chứ không phải mạng nội bộ vb, máy khách vm sẽ nhận ip của nó từ vb chứ không phải máy chủ DHCP vm. Nhật ký hiển thị máy chủ nhận yêu cầu từ máy khách nhưng máy khách nhận ip của nó từ vb thay vì vậy bạn không bao giờ nhận được ACK gửi lại máy chủ.


0

Đối với tôi, đó là một trường hợp đơn giản về việc quên tắt máy chủ DHCP (thông qua Internet Sharing) trên máy khách. Ngay sau khi tôi tắt nó, hợp đồng thuê DHCP đã được chấp nhận:

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
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.