DHCP-client coi điều gì là câu trả lời hay nhất của Wikipedia?

Chúng tôi có phòng đào tạo, nơi thường cài đặt Windows XP (thông qua PXE). Cơ sở hạ tầng DNS / DHCP "bình thường" là Máy chủ Windows. Phòng đào tạo có Vlan riêng (khác với các máy chủ Windows), do đó, có khả năng nhất là trình trợ giúp IP cho các yêu cầu DHCP hoạt động trên bộ định tuyến của Cisco nơi tất cả các PC từ phòng đó được kết nối.

Bây giờ chúng tôi muốn chuyển đổi một số PC sang Linux thay thế. Ý tưởng là: Đặt máy tính xách tay của chúng ta có máy chủ DHCP vào Vlan của phòng và ghi đè lên phản hồi DHCP "bình thường". Ý tưởng là điều này sẽ hoạt động, vì một máy chủ DHCP được gắn trực tiếp trong Vlan đó sẽ có thời gian phản hồi nhanh hơn so với máy chủ DHCP "bình thường" nằm cách một số bước nhảy từ Vlan đó.

Hóa ra điều này không hiệu quả. Chúng tôi phải tự giải phóng hợp đồng thuê trên máy chủ DHCP gốc để nó hoạt động.

Trên máy tính xách tay, chúng tôi đã thấy khách hàng yêu cầu IP và "dhcp" của chúng tôi đã gửi NACK đến yêu cầu IP của Windows, trước đó chúng tôi đã đưa ra phản hồi của riêng mình.

Câu hỏi cũ: Tại sao điều này không diễn ra như mong đợi? Điều gì đang khiến PC lấy lại hợp đồng cũ?

Cập nhật 2012-08-08:

Vấn đề lấy lại đã được giải thích trong DHCP-RFC. Bây giờ điều này giải thích tại sao PC lấy lại hợp đồng cũ.

Bây giờ chúng tôi phát hành IP từ máy chủ Windows-DHCP trước khi thử lại lần nữa.

Một lần nữa - máy chủ Windows-DHCP thắng.

Tôi nghi ngờ rằng có một số thuật toán cho dhcp-client xác định câu trả lời dhcp "tốt nhất" cho máy khách. Câu hỏi mới là:

Làm thế nào để khách hàng chọn câu trả lời "tốt nhất"?

Nó là nhà cung cấp, thậm chí phần sụn cụ thể cách khách hàng phản ứng với nhiều câu trả lời DHCP.

Các biến thể tôi đã thấy trong những năm qua là:

1) Chấp nhận cái đầu tiên bất kể đó là ACK hay NACK.

2) Lấy ACK đầu tiên, bỏ qua hoàn toàn NACK.

3) Lấy ACK cuối cùng nhận được trong khoảng thời gian đã đặt (thường là 5-10 giây).

Ví dụ: Một số năm trước, chúng tôi đã gặp sự cố với Ricoh MFP.
Chúng tôi đã có 2 máy chủ DHCP. Một cung cấp địa chỉ, còn lại chỉ có các tùy chọn DHCP bổ sung. Máy chủ thứ 2 luôn trả lời trước.
Biến thể 1 được sử dụng của Ricoh ngay cả khi ưu đãi đầu tiên chỉ chứa các tùy chọn DHCP. Ricoh đã thay đổi nó thành biến thể 2) bằng bản cập nhật firmware sau khi chúng tôi giải thích vấn đề cho họ.

Giả sử bộ định tuyến vẫn hoạt động như một chuyển tiếp DHCP và chuyển tiếp yêu cầu đến máy chủ ban đầu của bạn, thì lý do nó làm điều đó đơn giản là vì máy chủ Windows DHCP đã bảo nó đi trước và sử dụng IP. Trong trường hợp này, DHCPNACK từ máy chủ mới là không liên quan, vì máy khách DHCP sẽ xem xét tất cả các phản hồi và vì nó nhận được một lời đề nghị từ hộp Windows DHCP, nên hoàn toàn vui lòng sử dụng nó.

PC: Oh hi thế giới, tôi có thể sử dụng 192.168.1.123 không?

New-DHCP: Tôi nói không.

Old-DHCP: Tôi nói có.

PC: Có người nói có! Ngọt ngào, tôi sẽ sử dụng nó!

Nếu không có gì khác giúp - RTFM (đọc hướng dẫn sử dụng tốt). Trong trường hợp này, cái đầu tiên là hit.

RFC 2131 phác thảo các hoạt động DHCP.

Mục 1.6 nói rằng DHCP phải :

Giữ lại cấu hình máy khách DHCP trên toàn bộ máy chủ khởi động lại và, bất cứ khi nào có thể, máy khách DHCP phải được gán cùng tham số cấu hình mặc dù khởi động lại cơ chế DHCP,

Bây giờ câu hỏi thú vị là làm thế nào mục tiêu thiết kế đó đang đạt được trên một khách hàng không có kiến ​​thức về quá khứ của nó. Mục 3.2 đề cương:

3.2 Tương tác giữa máy khách và máy chủ - sử dụng lại địa chỉ mạng được phân bổ trước đó

Nếu khách hàng nhớ và muốn sử dụng lại
địa chỉ mạng được phân bổ trước đó , khách hàng có thể chọn bỏ qua một số bước
được mô tả trong phần trước. Biểu đồ dòng thời gian trong hình 4
cho thấy các mối quan hệ thời gian trong tương tác máy khách-máy chủ điển hình cho máy khách sử dụng lại địa chỉ mạng được phân bổ trước đó.

1. Máy khách phát thông báo DHCPREQUEST trên mạng con cục bộ của nó. Thông báo bao gồm địa chỉ mạng của khách hàng trong tùy chọn 'địa chỉ IP được yêu cầu'. Vì khách hàng chưa nhận được địa chỉ mạng, nên KHÔNG PHẢI điền vào trường 'ciaddr'. Các tác nhân chuyển tiếp BOOTP chuyển thông điệp đến các máy chủ DHCP không trên cùng một mạng con. Nếu khách hàng đã sử dụng 'định danh khách hàng' để lấy địa chỉ của mình, khách hàng PHẢI sử dụng cùng một 'định danh khách hàng' trong thông báo DHCPREQUEST.

2. Máy chủ có kiến ​​thức về các tham số cấu hình của máy khách phản hồi với thông báo DHCPACK cho máy khách. Máy chủ KHÔNG NÊN kiểm tra xem địa chỉ mạng của khách hàng đã được sử dụng chưa; khách hàng có thể trả lời tin nhắn Yêu cầu Echo của ICMP tại thời điểm này.

Vì vậy, một máy chủ DHCP giữ hợp đồng thuê đang hoạt động được ưu tiên bằng cách sử dụng phím tắt trong protcol.

1. Máy khách: DHCREQUEST (MAC-Adress, Broadcast, sẽ được truyền trong miền quảng bá cục bộ - ở đây là Vlan cục bộ và thông qua trình trợ giúp IP đến máy chủ Windows-DHCP)
2. Máy tính xách tay-DHCP-Server: DHCPOFFER
3. Windows-DHCP-Server: Này - Tôi đã biết bạn - DHCPACK
4. Khách hàng: Ồ - Tôi nhận được hai phản hồi. Một người đã biết tôi. Thật tuyệt, tôi sẽ lấy nó

Từ đó trở đi, Laptop-DHCP-Server bị Client bỏ qua.

Vì vậy, giải pháp trong trường hợp của chúng tôi có thể sẽ là (tôi sẽ cập nhật điều này khi chúng tôi thực sự kiểm tra nó):

1. Đảm bảo khách hàng tắt
2. Tắt DHCP-Server trên Laptop, Client-MAC giả trên Laptop, DHCP-Request
3. Phát hành IP
4. Lấy lại IP và MAC gốc, bật DHCP-Server
5. Bật ứng dụng khách và thực hiện khởi động PXE ...

Câu hỏi mới có lẽ nên ở một câu hỏi khác - tiêu đề của câu hỏi hoàn toàn không phù hợp với hầu hết nội dung của câu hỏi.

Trong mọi trường hợp, liên quan đến cách khách hàng chọn cung cấp dịch vụ nào, trong trường hợp không có hợp đồng thuê hiện tại: tùy thuộc vào khách hàng, nhưng trong mọi triển khai ứng dụng khách DHCP mà tôi biết, đó là một cuộc đua đơn giản .

RFC 2131 bao gồm điều này:

Các máy khách DHCP có thể tự do sử dụng bất kỳ chiến lược nào trong việc chọn máy chủ DHCP trong số các máy khách mà máy khách nhận được thông báo DHCPOFFER.

Có một dự thảo IETF ngoài đó dường như đã chết có thể bổ sung cấu hình cho quy trình lựa chọn và cũng đề cập đến việc triển khai ứng dụng khách mờ nhạt (của hơn một thập kỷ trước, nhưng không thay đổi nhiều):

Trong thực tế, hầu hết việc thực hiện chính sách của nhà cung cấp ở đây là rất cơ bản (ví dụ: ưu đãi đầu tiên nhận được hoặc ưu đãi chấp nhận đầu tiên nhận được) và là "mã hóa cứng" (nghĩa là không thể định cấu hình).

Có hai máy chủ DHCP cung cấp dịch vụ cho cùng một mạng với cấu hình khác nhau chỉ dẫn đến các cuộc đua, điều không mong muốn từ góc độ tin cậy hoặc dự đoán. Thực sự không có lý do gì bạn không thể có được máy chủ DHCP duy nhất của mình để cung cấp những gì bạn cần.