ความเข้ากันได้ของไคลเอ็นต์ SRX DHCP กับ HP Procurve DHCP Relay


10

ฉันพยายามบู๊ตการตั้งค่าบน Juniper SRX100 บางตัวและมีปัญหา DHCP อยู่

โดยเฉพาะฉันกำลังเชื่อมต่อพอร์ต 0/0 (fe-0/0/0 ในซอฟต์แวร์) กับเครือข่ายที่มีอยู่ของฉันซึ่ง DHCP ทำงานได้อย่างน่าเชื่อถือสำหรับอุปกรณ์อื่น ๆ ที่ฉันเคยใช้ SRX100s ไม่ได้รับที่อยู่ DHCP SRX100 เป็นค่าเริ่มต้นที่ไม่อยู่ในกรอบเมื่อฉันพยายามทำสิ่งนี้

ฉันนำอุปกรณ์หนึ่งมาที่บ้านของฉันและเสียบเข้ากับเครือข่ายในบ้านของฉันและได้รับที่อยู่ IP ในเครือข่ายภายในบ้านผ่าน DHCP โดยไม่มีปัญหา

เครือข่ายสำนักงานของฉันมีสวิตช์ Procurve 1400 (เลเยอร์ 2 เท่านั้น) บนเดสก์ท็อปของฉันอัปลิงค์ไปยังโทรศัพท์ IP Polycom IP670 IP (ทำหน้าที่เป็นสวิตช์เลเยอร์ 2 ที่เรียบง่าย) อัปลิงค์ไปยังสวิตช์ Procurve 3500yl ทำหน้าที่เป็นเราเตอร์สำหรับเครือข่ายด้วย "ip ผู้ช่วยที่อยู่ 1.1.1.1 "บนอินเตอร์เฟส vlan ที่ชี้ไปยังเซิร์ฟเวอร์ DHCP สำหรับรีเลย์ DHCP

ใครบ้างมีประสบการณ์กับการรับไคลเอนต์ SRX DHCP รับที่อยู่ IP ผ่าน Procurve (รันซอฟต์แวร์ K.15.09.0012 ... แม้ว่าปัญหาจะมีอยู่ในเฟิร์มแวร์หลายรุ่นใน Procurve) SRX100 ดูเหมือนว่าจะมี 11.2 สำหรับพวกเขาเมื่อพวกเขาออกมาในกล่อง แต่ฉันคิดว่าปัญหายังคงมีอยู่เมื่ออัพเกรดเป็น 12.1X44-D10.4

ใครบ้างมีคำแนะนำสำหรับการแก้ไขปัญหานี้? Procurve 3500yl ดูเหมือนจะไม่ยอมรับว่าได้เห็นคำขอไคลเอนต์ DHCP มาจาก SRX100 แต่ข้อมูลการแก้ไขปัญหาเกี่ยวกับ Procurves ในพื้นที่นี้ดูเหมือนมีข้อ จำกัด เซิร์ฟเวอร์ DHCP ไม่เห็นแพ็คเก็ต DHCPDISCOVER ใด ๆ ที่เกี่ยวข้องกับ SRX100

วิธีแก้ปัญหาของฉันคือการกำหนดค่าที่อยู่ IP ใน SRX100 แบบคงที่เพื่อนำไปไว้ในเครือข่ายและทำการตั้งค่าที่เหลือของฉัน แต่โครงการที่ฉันกำลังทำงานอยู่นั้นเกี่ยวข้องกับการส่ง SRX100s ไปยังสถานที่ห่างไกลที่ไม่อยู่ภายใต้การควบคุมของฉัน ดังนั้นขึ้นอยู่กับพวกเขาที่เชื่อถือได้รับที่อยู่ DHCP สำหรับการเชื่อมต่อดังนั้นฉันอยากจะแก้ไขปัญหานี้และเรียกใช้สาเหตุที่เฉพาะเจาะจงเพื่อให้ฉันรู้ว่าสิ่งที่อาจมองหาหากสิ่งนี้เกิดขึ้นที่ไซต์ระยะไกล

อัปเดต: ฉันมี SRX100 (เพื่อตรวจสอบซ้ำ) จากโรงงานและเสียบเข้ากับพอร์ตบน Procurve 3500yl โดยตรงและยังคงเห็นปัญหาดังนั้นจึงลบโทรศัพท์ 1400 และ IP670 ออกจากการสนทนา ฉันได้รวมเอาท์พุท tcpdump จาก SRX100 ด้านล่าง ... อย่างที่คุณเห็นการส่งแพ็กเก็ต DHCP ที่ง่ายที่สุดเท่าที่จะเป็นไปได้เมื่อมีแนวโน้มที่จะแนะนำว่าปัญหาเกิดขึ้นกับฟังก์ชั่น dhcp-relay บน 3500yl ฉันไม่สามารถหาวิธีที่จะได้รับผลลัพธ์การแก้ปัญหาใด ๆ จาก 3500yl แสดงแพ็คเก็ตที่กดปุ่มฟังก์ชั่น dhcp-relay (สำเร็จหรืออย่างอื่น) คำแนะนำเกี่ยวกับวิธีการแก้ปัญหาฟังก์ชั่นนี้ใน 3500yl จะได้รับการชื่นชมอย่างมาก

tcpdump -n -s 0 -c 1 -vvv -r juniper.dhcp.pcap 
reading from file juniper.dhcp.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)
17:49:11.538670 
Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
  Device Media Type Extension TLV #3, length 1, value Ethernet (1)
  Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)
  Device Interface Index Extension TLV #1, length 2, value 34304
  Logical Interface Index Extension TLV #4, length 4, value 70
-----original packet-----
IP (tos 0x0, ttl 1, id 13874, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:d0:e5:1c:68:80, length 300, xid 0x643c9869, Flags [Broadcast] (0x8000)
  Client-Ethernet-Address a8:d0:e5:1c:68:80
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Discover
    END Option 255, length 0
    PAD Option 0, length 0, occurs 56

คุณได้ลองเชื่อมต่อ SRX กับ 3500yl โดยตรงเพื่อให้แน่ใจว่าไม่ใช่ 1400 หรือ Polycom กำลังกรองการออกอากาศ DHCPDISCOVER หรือไม่
David Rothera

ฉันไม่ได้และนั่นไม่ใช่ความคิดที่เลว อย่างไรก็ตามในบางครั้งฉันก็เชื่อมต่อระบบอื่นในลักษณะเดียวกันและรับที่อยู่ DHCP ในระบบอื่นรวมถึงเครื่องเดสก์ท็อปของฉันที่อยู่บนเครือข่ายตลอดเวลาในลักษณะนี้ดังนั้นจึงดูเหมือนว่าจะไม่เป็นปัญหา ฉันจะดูว่าฉันสามารถทดสอบได้ไหม
Jeff McAdams

อัปเดตด้วยข้อมูลบางส่วนในการตอบกลับของฉัน ... โดยเฉพาะกับวิธีการเปลี่ยนค่า TTL ของการร้องขอ DHCP ใน SRX รวมทั้งสังเกตว่าฉันได้เปิด RFE ด้วย HP
Jeff McAdams

คำตอบ:


9

ฉันเปิดเคสกับ HP เกี่ยวกับปัญหานี้ หลังจากที่ผ่านมาเทคโนโลยีระดับ 1 ที่ไม่มีประโยชน์แล้วเทคโนโลยีระดับ 2 ก็สังเกตเห็นสิ่งที่ฉันไม่ได้ทำ

SRX กำลังส่งแพ็กเก็ต DHCPDISCOVER ด้วย TTL เป็น 1 ดูเหมือนว่า Procurve จะลด TTL และใช้ TTL ที่เป็นผลลัพธ์ในแพ็กเก็ตรีเลย์ที่ส่งไปยังเซิร์ฟเวอร์ DHCP ในกรณีนี้การลดลงจะทำให้ TTL ที่ 0 หมายความว่าแพ็กเก็ตจะตกลงบนพื้น

นี่เป็นข้อมูลจำเพาะสำหรับรีเลย์ DHCP / BOOTP อย่างชัดเจนแม้ว่าจะทำให้การทำงานร่วมกันลดลง ฉันได้ขอให้ HPNetworking ปฏิบัติเช่นนี้เป็นข้อบกพร่อง / RFE และเปลี่ยนพฤติกรรม ไม่ตอบกลับคำขอนั้นทันทีในกรณี

SRX ที่ส่ง DHCPDISCOVER ด้วย TTL 1 นั้นอาจจะอยู่ในสเป็ค แต่อีกทางเลือกของการทำงานร่วมกันที่ลดลงดังนั้นฉันวางแผนที่จะเปิดเคสด้วย JTAC บนพื้นฐานเดียวกัน

ฉันจะเพิ่มข้อมูลเพิ่มเติมเกี่ยวกับการตอบสนองของ Juniper และ HP เมื่อพร้อมให้ใช้งาน

บังเอิญฉันได้ทดสอบพฤติกรรมการส่งสัญญาณของ Cisco 4506 (เวอร์ชั่นเฟิร์มแวร์ไม่สามารถใช้งานได้) และ FastIron Edge X (Brocade / Foundry FastIron Edge X (7.2 หรือ 7.3 เฟิร์มแวร์ฉันเชื่อว่าไม่สามารถเข้าถึงได้ทันทีเพื่อยืนยัน) ถ่ายทอดคำขอกับ TTL 1 โดยไม่มีปัญหา

การอัปเดต มีวิธีการเปลี่ยนค่า TTL ที่ SRX ใช้กับคำขอ DHCP ของมัน แต่ไม่ใช่จากภายใน JunOS cli ... ทำจาก Unix OS พื้นฐาน

root@% sysctl -w net.inet.ip.mcast_ttl=64

ฉันได้เปิด RFE กับ HP เพื่อให้ฟังก์ชั่นการถ่ายทอดของพวกเขามีความยืดหยุ่นมากขึ้น


2

มันอาจเป็นเรื่องยากที่จะแก้ไขปัญหาเมื่อคุณไม่รู้ว่าปัญหาอยู่ที่ใดและคุณมีอุปกรณ์สามเครื่องจากผู้จำหน่ายสามรายก่อนที่คุณจะมองเห็นได้ (SRX100, 1400 และ IP670) ฉันไม่สามารถพูดกับอุปกรณ์เฉพาะ แต่คุณไม่เคยผิดพลาดโดยการติดตามแพ็คเก็ต เนื่องจาก ProCurve 1400 เป็นอุปกรณ์ที่ไม่มีการจัดการคุณจะต้องใช้การแตะเครือข่าย

คุณต้องการจับภาพการรับส่งข้อมูลในตำแหน่งต่อไปนี้ (ตามข้อความของคุณว่า 3500yl ไม่ได้รับแพ็กเก็ต Discover):

  • ระหว่าง SRX100 และ 1400
  • ระหว่าง 1,400 และ IP670
  • ระหว่าง IP670 และ 3500yl

คุณสามารถทำสิ่งเหล่านี้ได้จากโต๊ะทำงานของคุณและในขณะที่การแตะถูกก่อกวนในขณะที่คุณกำลังเชื่อมต่อ / ตัดการเชื่อมต่อมันควรมีผลกับคุณและอุปกรณ์ของคุณเท่านั้น

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

คุณอาจต้องการจับ DHCP ค้นพบแพ็กเก็ตจากอุปกรณ์ที่ใช้งานได้ดีเพื่อดูว่ามีความแตกต่างจากแพคเก็ต Discover ที่ SRX100 ส่งออกไปหรือไม่

เมื่อคุณทราบว่าแพ็คเก็ตผิดพลาดคุณสามารถตรวจสอบการแก้ไขปัญหาโดยเฉพาะสาเหตุที่แพ็คเก็ตผิดพลาด


ใช่ฉันยังไม่ได้ทำตามขั้นตอนเฉพาะเหล่านั้นเนื่องจากฉันมีความมั่นใจที่ดีว่า 1400 และ ip670 เป็นเลเยอร์ 2 ที่เชื่อถือได้เท่านั้น ฉันคิดว่าปัญหาคือความไม่ลงรอยกันระหว่าง SRX และ 3500yl ฉันสงสัยว่าแพ็คเก็ตจะถึง 3500yl แต่มันไม่จัดการอย่างถูกต้อง ฉันไม่สามารถรับ 3500yl เพื่อระบุว่าได้เห็นแพ็กเก็ตที่ฉันคิดว่ามากขึ้นเนื่องจากความสามารถในการดีบักที่ จำกัด ใน 3500yl
Jeff McAdams

@JeffMcAdams ฉันมักจะเห็นด้วยกับการประเมินนั้น แต่เคยประหลาดใจกับปัญหาแปลก ๆ มาก่อน เนื่องจากคุณสามารถเลื่อนการแตะในสถานที่เหล่านั้นทั้งหมดจากโต๊ะทำงานของคุณฉันจะติดตามแพ็คเก็ตเพื่อรับประกันว่าสิ่งต่าง ๆ ทำงานได้อย่างที่คาดไว้ หากคุณต้องย้ายไปมาระหว่างตู้เน็ตเวิร์กพื้นอาคารหรือไซต์ฉันจะบอกว่าข้ามไปที่ปัญหาและเริ่มต้นจากตรงนั้น นอกจากนี้การได้รับแพ็คเก็ตค้นพบที่รู้จักกันดีจะช่วยให้คุณรู้ว่าอาจมีบางสิ่งที่ "พิเศษ" อยู่ในเซิร์ฟเวอร์ DHCP ของคุณไม่ชอบ (ตัวเลือก 82 หรืออย่างอื่น)
YLearn

1

แม้ว่าคุณจะทดสอบ SRX ที่อื่น:

  1. SRX ได้รับที่อยู่ด้วยการกำหนดค่าเดียวกันที่บ้านหรือไม่?
    • นี่ควรหมายความว่าสิ่งต่อไปนี้ไม่ใช่ปัญหา:
    • set security zones security-zone host-inbound-traffic system-services dhcp เสร็จสิ้นแล้ว
    • เสร็จสิ้นการตั้งค่าอินเตอร์เฟสพื้นฐาน (ไม่ว่าจะเป็นอินเตอร์เฟสดิบ, แท็ก vlan, ส่วนต่อประสานใน vlan ที่ถูกต้อง, vlan นั้น
  2. อินเทอร์เฟซเกิดขึ้นจริง ๆ บนด้าน Juniper หรือไม่
    • show interfaces fe-0/0/0 extensive เป็นเพื่อนของคุณ
    • (ฉันรู้ว่ามันไม่เหมาะสมสำหรับสิ่งนี้ แต่ยัง ... ) สำหรับอินเตอร์เฟซแบบออพติคอลก็ตรวจสอบระดับพลังงาน: show interfaces diagnostics optics ge-0/0/0
  3. เพิ่มการติดตามไปยังไคลเอนต์ DHCP:
กำหนดค่า
ตั้งค่าบริการระบบไฟล์การติดตาม dhcp ติดตาม dhcp_client.log ที่อ่านได้ทั่วโลก
ตั้งค่าระบบบริการ dhcp ติดตามลูกค้าธง
ตั้งค่าบริการระบบ dhcp ติดตามระดับทั้งหมด
กระทำและเลิก

monitor start dhcp_client.logจากนั้นตรวจสอบการเข้าสู่ระบบในขณะที่คุณนำมาขึ้นติดต่อกับ (อย่าลืมลบการสืบค้นกลับเมื่อคุณทำเสร็จแล้ว)


1. ใช่ฉันกำลังทำสิ่งนี้ด้วยการกำหนดค่าเริ่มต้นแบบแยกส่วนออกจากกล่องโรงงานทั้งที่บ้านและในสำนักงาน การกำหนดค่าเริ่มต้นจากโรงงานรวมถึงโฮสต์ - ทราฟฟิกระบบ - บริการ dhcp บนอินเตอร์เฟส fe-0/0 / 0.0 ที่ฉันใช้ 2. ใช่อินเทอร์เฟซนั้นหมดจดและหากฉันตั้งค่าข้อมูล IP แบบคงที่มันก็ใช้งานได้ดี 3. ฉันแก้ไขคำถามเดิมด้วย tcpdump ของแพ็คเก็ตที่ออกไป ... ฉันไม่เคยเห็นแพ็กเก็ตที่ส่งคืนเลยและไม่เคยเห็นแพ็คเก็ตตีเซิร์ฟเวอร์ DHCP
Jeff McAdams
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.