ไคลเอ็นต์ DHCP พิจารณาว่าคำตอบที่ดีที่สุดคืออะไร

เรามีห้องฝึกอบรมซึ่งปกติจะติดตั้ง Windows XP (ผ่าน PXE) โครงสร้างพื้นฐาน DNS / DHCP "ปกติ" คือ Windows-Servers ห้องฝึกอบรมมี VLAN ของตัวเอง (แตกต่างจากเซิร์ฟเวอร์ Windows) ดังนั้นจึงมีตัวช่วย IP สำหรับการร้องขอ DHCP ที่ใช้งานได้บนเราเตอร์ Cisco ที่พีซีทั้งหมดจากห้องนั้นเชื่อมต่ออยู่

ตอนนี้เราต้องการแปลงพีซีบางตัวเป็น Linux แทน ความคิดคือ: ใส่แล็ปท็อปของเราเองกับเซิร์ฟเวอร์ DHCP ลงใน VLAN ของห้องและแทนที่การตอบสนอง DHCP "ปกติ" แนวคิดก็คือสิ่งนี้ควรใช้งานได้เนื่องจากเซิร์ฟเวอร์ DHCP ที่เชื่อมต่อโดยตรงใน VLAN นั้นควรมีเวลาตอบสนองที่เร็วกว่าเซิร์ฟเวอร์ DHCP ปกติที่อยู่ห่างจาก VLAN นั้น

ปรากฎว่าสิ่งนี้ไม่ได้ผล เราต้องปล่อยสัญญาเช่าด้วยตนเองบนเซิร์ฟเวอร์ DHCP ดั้งเดิมเพื่อให้ทำงานได้

บนแล็ปท็อปเราเห็นลูกค้าร้องขอ IP และ "dhcp" ของเรากำลังส่ง NACKs ไปยังคำขอ IP ของ Windows ก่อนที่เราจะตอบสนองของเราเอง

คำถามเก่า: ทำไมสิ่งนี้ถึงไม่เป็นไปตามที่คาดไว้? อะไรคือสิ่งที่ทำให้พีซีได้รับสัญญาเช่าเดิม

อัปเดต 2012-08-08:

ปัญหาการกู้คืนได้รับการอธิบายใน DHCP-RFC ตอนนี้อธิบายได้ว่าทำไมพีซีถึงได้สัญญาเช่าเดิม

ตอนนี้เราจะปล่อย IP จากเซิร์ฟเวอร์ Windows-DHCP ก่อนที่จะลองอีกครั้ง

อีกครั้ง - เซิร์ฟเวอร์ Windows-DHCP- ชนะ

ฉันสงสัยว่ามีอัลกอริทึมบางอย่างสำหรับ dhcp-client ซึ่งกำหนด "ดีที่สุด" dhcp-answer สำหรับลูกค้า คำถามใหม่คือ:

ลูกค้าเลือกคำตอบที่ "ดีที่สุด" ได้อย่างไร

มันเป็นผู้ขายแม้กระทั่งเฟิร์มแวร์ที่เฉพาะเจาะจงว่าไคลเอนต์ตอบสนองต่อหลายคำตอบ DHCP

สิ่งที่ฉันได้เห็นในช่วงหลายปีที่ผ่านมาคือ:

1) ยอมรับสิ่งแรกไม่ว่าจะเป็น ACK หรือ NACK

2) ใช้ ACK แรกไม่สนใจ NACK โดยสมบูรณ์

3) รับ ACK ล่าสุดที่ได้รับภายในช่วงเวลาที่กำหนด (ปกติ 5-10 วินาที)

ตัวอย่าง: เมื่อหลายปีก่อนเรามีปัญหากับ Ricoh MFP
เรามีเซิร์ฟเวอร์ DHCP 2 เครื่อง หนึ่งที่อยู่ที่ให้มาตัวเลือก DHCP เพิ่มเติมอื่น ๆ เท่านั้น เซิร์ฟเวอร์ตัวที่ 2 ตอบก่อนเสมอ
ตัวแปรที่ใช้ของ Ricoh 1) แม้ว่าข้อเสนอที่ 1 จะมีตัวเลือก DHCP เท่านั้น Ricoh เปลี่ยนเป็นตัวแปร 2) ด้วยการอัพเดตเฟิร์มแวร์หลังจากที่เราอธิบายปัญหาให้พวกเขาแล้ว

สมมติว่าเราเตอร์ยังคงทำหน้าที่เป็นรีเลย์ DHCP และส่งต่อคำขอไปยังเซิร์ฟเวอร์เดิมของคุณแล้วเหตุผลที่ทำเช่นนั้นก็เพราะเซิร์ฟเวอร์ Windows DHCP ของ Windows บอกให้ทำต่อไปและใช้ IP ในกรณีนี้ DHCPNACK จากเซิร์ฟเวอร์ใหม่ไม่เกี่ยวข้องเนื่องจากไคลเอนต์ DHCP จะพิจารณาคำตอบทั้งหมดและเนื่องจากได้รับข้อเสนอจากกล่อง Windows DHCP จึงมีความสุขที่จะใช้มันอย่างสมบูรณ์

PC: โอ้สวัสดีค่ะฉันจะใช้ 192.168.1.123 ได้ไหม

ใหม่ DHCP: ฉันว่าไม่

Old-DHCP: ฉันว่าใช่

พีซี: มีคนบอกว่าใช่! น่ารักฉันจะใช้มัน!

หากไม่มีสิ่งใดช่วย - RTFM (อ่านคู่มืออย่างละเอียด) ในกรณีนี้คนแรกคือการตี

RFC 2131แสดงการดำเนินงาน DHCP

ส่วนที่ 1.6 ระบุว่า DHCP ต้อง :

เก็บการกำหนดค่าไคลเอนต์ DHCP ไว้ในการรีบู๊ตเซิร์ฟเวอร์และหากเป็นไปได้ลูกค้า DHCP ควรกำหนดพารามิเตอร์การกำหนดค่าเดียวกันแม้ว่าจะรีสตาร์ทกลไก DHCP

ตอนนี้คำถามที่น่าสนใจคือเป้าหมายการออกแบบนั้นประสบความสำเร็จได้อย่างไรกับลูกค้าที่ไม่มีความรู้ในอดีต ส่วนที่ 3.2 โครงร่าง:

3.2 การโต้ตอบกับไคลเอนต์ - นำที่อยู่เครือข่ายที่จัดสรรไว้ก่อนหน้านี้กลับมาใช้ใหม่

หากลูกค้าจำและต้องการใช้ที่
อยู่เครือข่ายที่จัดสรรไว้ก่อนหน้านี้อีกครั้งลูกค้าอาจเลือกที่จะไม่ทำตามขั้นตอนที่
อธิบายไว้ในส่วนก่อนหน้านี้ ไทม์ไลน์ไดอะแกรมในรูปที่ 4
แสดงความสัมพันธ์ด้านเวลาในการโต้ตอบกับไคลเอนต์ - เซิร์ฟเวอร์ทั่วไปสำหรับลูกค้าที่ใช้ที่อยู่เครือข่ายที่จัดสรรไว้ก่อนหน้านี้อีกครั้ง

1. ไคลเอนต์ออกอากาศข้อความ DHCPREQUEST บนเครือข่ายย่อยท้องถิ่น ข้อความนี้มีที่อยู่เครือข่ายของลูกค้าในตัวเลือก 'ที่อยู่ IP ที่ร้องขอ' เนื่องจากไคลเอ็นต์ไม่ได้รับที่อยู่เครือข่ายจึงไม่ต้องกรอกข้อมูลในฟิลด์ 'ciaddr' ตัวแทนรีเลย์ BOOTP ส่งข้อความไปยังเซิร์ฟเวอร์ DHCP ที่ไม่ได้อยู่ในซับเน็ตเดียวกัน หากลูกค้าใช้ 'ตัวระบุลูกค้า' เพื่อรับที่อยู่ของลูกค้าต้องใช้ 'ตัวระบุลูกค้า' เดียวกันในข้อความ DHCPREQUEST

2. เซิร์ฟเวอร์ที่มีความรู้เกี่ยวกับพารามิเตอร์การกำหนดค่าของลูกค้าตอบสนองด้วยข้อความ DHCPACK ไปยังลูกค้า เซิร์ฟเวอร์ไม่ควรตรวจสอบว่าที่อยู่เครือข่ายของลูกค้าถูกใช้งานแล้ว ไคลเอ็นต์อาจตอบกลับข้อความร้องขอ ICMP Echo ณ จุดนี้

ดังนั้นเซิร์ฟเวอร์ DHCP ที่ถือการเช่าซื้อที่ใช้งานอยู่จึงมีความสำคัญกว่าโดยใช้ทางลัดใน Protcol

1. ไคลเอนต์: DHCREQUEST (MAC-Adress, Broadcast จะถูกส่งสัญญาณในโดเมนการแพร่สัญญาณท้องถิ่น - ที่นี่ VLAN ท้องถิ่นและผ่าน IP-helper ไปยัง Windows-DHCP-server)
2. แล็ปท็อป - DHCP- เซิร์ฟเวอร์: DHCPOFFER
3. Windows-DHCP-Server: เฮ้ - ฉันรู้จักคุณอยู่แล้ว - DHCPACK
4. ลูกค้า: โอ้ - ฉันได้รับคำตอบสองข้อ คนที่รู้จักฉันอยู่แล้ว ฉันจะทำอย่างนั้น

จากนั้นในไคลเอ็นต์ของแล็ปท็อป DHCP เซิร์ฟเวอร์จะถูกละเว้น

ดังนั้นวิธีแก้ปัญหาในกรณีของเราอาจเป็น (ฉันจะอัปเดตสิ่งนี้เมื่อเราทดสอบจริง):

1. ตรวจสอบให้แน่ใจว่าไคลเอ็นต์ปิดอยู่
2. ปิดเซิร์ฟเวอร์ DHCP บนแล็ปท็อปปลอมไคลเอ็นต์ -MAC บนแล็ปท็อปร้องขอ DHCP
3. IP ที่วางจำหน่าย
4. คืนค่า IP และ MAC ดั้งเดิมเปิด DHCP-Server
5. เปิดไคลเอ็นต์และทำการบูต PXE ...

คำถามใหม่น่าจะเป็นคำถามที่แตกต่าง - ชื่อของคำถามไม่ตรงกับเนื้อหาส่วนใหญ่ของคำถาม

ในกรณีใด ๆ เกี่ยวกับวิธีที่ลูกค้าเลือกข้อเสนอที่จะไปด้วยในกรณีที่ไม่มีสัญญาเช่าปัจจุบัน: ขึ้นอยู่กับลูกค้า แต่ในทุกการใช้งานไคลเอนต์ DHCP ที่ฉันรู้ว่ามันเป็นเรื่องง่าย .

RFC 2131ครอบคลุมสิ่งนี้:

ไคลเอ็นต์ DHCP มีอิสระในการใช้กลยุทธ์ใด ๆ ในการเลือกเซิร์ฟเวอร์ DHCP ซึ่งลูกค้าจะได้รับข้อความ DHCPOFFER

มีร่าง IETFที่ดูเหมือนว่าตายแล้วซึ่งจะเพิ่มการกำหนดค่าให้กับกระบวนการคัดเลือกและยังกล่าวถึงการปรับใช้ไคลเอนต์ที่ขาดความดแจ่มใส (กว่าทศวรรษที่ผ่านมา

ในทางปฏิบัติการดำเนินการตามนโยบายของผู้ขายส่วนใหญ่ที่นี่เป็นพื้นฐานมาก (เช่นรับข้อเสนอแรกหรือรับข้อเสนอแรกที่ได้รับ) และเป็น "รหัสตายตัว" (เช่นไม่สามารถกำหนดค่าได้)

การมีเซิร์ฟเวอร์ DHCP สองเครื่องที่ให้บริการกับเครือข่ายเดียวกันที่มีการกำหนดค่าที่แตกต่างกันนั้นส่งผลให้เกิดการแข่งขันซึ่งไม่เป็นที่ต้องการจากมุมมองด้านความน่าเชื่อถือหรือการคาดการณ์ ไม่มีเหตุผลจริงๆที่คุณไม่สามารถรับเซิร์ฟเวอร์ DHCP เดี่ยวของคุณเพื่อให้สิ่งที่คุณต้องการ