Khả năng tương thích máy khách SRX DHCP với HP Procurve DHCP Relay


10

Tôi đang cố gắng bootstrap cấu hình trên một số Juniper SRX100 và đang gặp một số vấn đề về DHCP.

Cụ thể, tôi đang kết nối cổng 0/0 (từ 0 đến 0/0 trong phần mềm) với mạng hiện tại của mình, nơi DHCP đã hoạt động khá đáng tin cậy cho mọi thiết bị khác mà tôi đã sử dụng. Các SRX100 không nhận được địa chỉ DHCP. SRX100 là cấu hình mặc định bên ngoài khi tôi thử điều này.

Tôi đã mang một trong những thiết bị đến nhà tôi và cắm nó vào mạng gia đình của tôi và nó có một địa chỉ IP trên mạng gia đình của tôi thông qua DHCP mà không gặp vấn đề gì.

Mạng văn phòng của tôi có công tắc Procurve 1400 (chỉ lớp 2) trên máy tính để bàn của tôi, được liên kết với điện thoại IP Polycom IP670 (hoạt động như một công tắc lớp 2 đơn giản), được liên kết với công tắc Procurve 3500yl hoạt động như một bộ định tuyến cho mạng với "ip helper-address 1.1.1.1 "trên giao diện vlan trỏ đến máy chủ DHCP để chuyển tiếp DHCP.

Có ai có bất kỳ kinh nghiệm nào về việc nhận ứng dụng khách SRX DHCP nhận địa chỉ IP thông qua Procurve (chạy phần mềm K.15.09.0012 ... mặc dù vấn đề đã tồn tại trên nhiều phiên bản phần sụn trên Procurve). SRX100 dường như có 11,2 trên chúng khi chúng ra khỏi hộp, mặc dù tôi nghĩ vấn đề vẫn tiếp tục tồn tại khi được nâng cấp lên 12.1X44-D10.4.

Có ai có bất kỳ đề nghị để khắc phục sự cố này? Procurve 3500yl dường như không thừa nhận đã thấy yêu cầu máy khách DHCP đến từ SRX100, nhưng thông tin khắc phục sự cố trên Procurves trong khu vực này dường như bị hạn chế. Máy chủ DHCP chắc chắn không thấy bất kỳ gói DHCPDISCOVER nào liên quan đến SRX100.

Cách giải quyết của tôi là định cấu hình tĩnh một địa chỉ IP trên SRX100 để đưa chúng vào mạng và thực hiện phần còn lại của cấu hình của tôi, nhưng dự án tôi đang thực hiện liên quan đến việc gửi SRX100 ra các địa điểm từ xa không thuộc quyền kiểm soát của tôi và, do đó, phụ thuộc vào việc họ đáng tin cậy nhận địa chỉ DHCP để kết nối, vì vậy tôi thực sự muốn khắc phục sự cố này và xử lý một nguyên nhân cụ thể để tôi biết những gì có thể tìm kiếm nếu điều này xảy ra tại các trang web từ xa.

Cập nhật: Tôi đã (để kiểm tra kỹ) SRX100 mặc định của nhà máy và cắm trực tiếp vào cổng trên Procurve 3500yl và vẫn gặp sự cố, do đó loại bỏ điện thoại 1400 và IP670 khỏi cuộc thảo luận. Tôi đã bao gồm đầu ra tcpdump từ SRX100 bên dưới ... như bạn có thể thấy, nó gửi đi về gói DHCP đơn giản nhất có thể, khi có xu hướng đề xuất rằng vấn đề là do chức năng chuyển tiếp dhcp trên 3500yl. Tôi không thể tìm thấy bất kỳ cách nào để có được bất kỳ đầu ra gỡ lỗi nào từ 3500yl hiển thị các gói đạt chức năng chuyển tiếp dhcp (thành công hay nói cách khác). Gợi ý về cách gỡ lỗi chức năng này trên 3500yl sẽ được đánh giá rất cao.

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

Bạn đã thử kết nối SRX trực tiếp với 3500yl để đảm bảo hơn 1400 hay Polycom không lọc các chương trình phát sóng DHCPDISCOVER chưa?
David Rothera

Tôi đã không, và đó không phải là một ý tưởng tồi. Tuy nhiên, đôi khi, tôi kết nối các hệ thống khác theo cách tương tự và nhận địa chỉ DHCP trên các hệ thống khác, bao gồm cả các máy tính để bàn của tôi liên tục trên mạng theo cách này, vì vậy dường như không có vấn đề gì. Tôi sẽ xem nếu tôi có thể kiểm tra điều đó, mặc dù.
Jeff McAdams

Được cập nhật với một số thông tin trong phản hồi của tôi ... cụ thể là cách thay đổi giá trị TTL của các yêu cầu DHCP trong SRX, cũng như lưu ý rằng tôi đã mở RFE bằng HP.
Jeff McAdams

Câu trả lời:


9

Tôi đã mở một trường hợp với HP liên quan đến vấn đề này. Sau khi leo thang vượt qua công nghệ cấp 1 vô dụng, công nghệ cấp 2 rất cảnh giác phát hiện ra thứ mà tôi không có.

SRX đang gửi gói DHCPDISCOVER của mình với chỉ số TTL là 1. Rõ ràng, Procurve sẽ phân rã TTL và sử dụng kết quả TTL trong gói chuyển tiếp đến máy chủ DHCP. Trong trường hợp này, phần giảm khiến cho TTL ở mức 0 nghĩa là gói bị rơi trên sàn.

Đây thực sự là thông số kỹ thuật cho chuyển tiếp DHCP / BOOTP, mặc dù rõ ràng nó làm giảm khả năng tương tác. Tôi đã yêu cầu HPNetworking coi đây là lỗi / RFE và thay đổi hành vi. Không có phản ứng ngay lập tức với yêu cầu đó trong trường hợp.

SRX gửi DHCPDISCOVER với chỉ số TTL là 1 cũng có thể nằm trong thông số kỹ thuật, nhưng, một lần nữa, sự lựa chọn giảm khả năng tương tác, vì vậy tôi dự định mở một trường hợp với JTAC trên cơ sở tương tự.

Tôi sẽ thêm thông tin về phản hồi của Juniper và HP khi có sẵn.

Tình cờ, tôi đã kiểm tra hành vi chuyển tiếp của Cisco 4506 (phiên bản phần sụn không có sẵn ngay lập tức) và phần mềm thổ cẩm / Foundry FastIron Edge X (7.2 hoặc 7.3, tôi tin rằng, không có quyền truy cập ngay lập tức) và cả hai đều xử lý chuyển tiếp yêu cầu với TTL 1 mà không có vấn đề.

CẬP NHẬT Có một cách để thay đổi giá trị TTL mà SRX sử dụng cho các yêu cầu DHCP của nó, nhưng không phải từ bên trong JunOS ... nó được thực hiện từ hệ điều hành Unix cơ bản.

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

Tôi đã mở RFE với HP để làm cho chức năng chuyển tiếp của chúng trở nên linh hoạt hơn, nhưng chưa có phản hồi từ chúng nếu / khi điều đó sẽ được thực hiện.


2

Có thể khó khắc phục sự cố khi bạn không biết vấn đề nằm ở đâu và bạn có ba thiết bị từ ba nhà cung cấp trước khi bạn dường như có bất kỳ tầm nhìn nào (SRX100, 1400 và IP670). Tôi không thể nói chuyện với các thiết bị cụ thể, nhưng bạn không bao giờ có thể sai bằng cách truy tìm các gói. Vì ProCurve 1400 là một thiết bị không được quản lý, bạn sẽ cần sử dụng một cú chạm mạng.

Bạn sẽ muốn nắm bắt lưu lượng truy cập ở các vị trí sau (dựa trên tuyên bố của bạn rằng 3500yl không nhận được gói khám phá):

  • Giữa SRX100 và 1400.
  • Giữa 1400 và IP670
  • Giữa IP670 và 3500yl

Bạn có thể thực hiện tất cả những việc này từ bàn làm việc của mình và trong khi một cú chạm bị gián đoạn trong khi bạn đang kết nối / ngắt kết nối thì nó chỉ ảnh hưởng đến bạn và các thiết bị của bạn.

Tôi sẽ bắt đầu ở đầu danh sách này, vì nó sẽ cho phép bạn chụp gói khám phá DHCP ít nhất một lần và sau đó mọi lần chụp tiếp theo của gói khám phá DHCP có thể được so sánh với gói này để xem có sửa đổi gì không.

Bạn cũng có thể muốn chụp DHCP khám phá các gói từ các thiết bị đang hoạt động để xem liệu có bất kỳ sự khác biệt nào từ gói khám phá mà SRX100 gửi đi không.

Khi bạn biết gói bị lỗi ở đâu, bạn có thể xem xét cụ thể cách khắc phục tại sao nó bị lỗi tại thời điểm đó.


Vâng, tôi chưa đi vào các bước cụ thể đó vì tôi khá tự tin rằng 1400 và ip670 chỉ là lớp 2 đáng tin cậy và do đó không bị lẫn lộn với lưu lượng DHCP. Tôi nghĩ vấn đề là một số loại không tương thích giữa SRX và 3500yl. Tôi nghi ngờ gói tin đang đến 3500yl, nhưng nó không xử lý chính xác. Rằng tôi không thể lấy 3500yl để chỉ ra rằng nó đã thấy gói tôi nghĩ là nhiều hơn do khả năng sửa lỗi hạn chế trên 3500yl.
Jeff McAdams

@JeffMcAdams, tôi có xu hướng đồng ý với đánh giá đó, nhưng đã bị bất ngờ bởi những vấn đề lạ trước đây. Vì bạn có thể di chuyển vòi ở những nơi đó từ bàn của bạn, tôi sẽ theo dõi gói để đảm bảo mọi thứ hoạt động như mong đợi. Nếu bạn phải di chuyển giữa các tủ mạng, sàn, tòa nhà hoặc trang web, thì tôi sẽ nói nhảy đến nơi xảy ra sự cố và bắt đầu từ đó. Ngoài ra, việc có được một gói khám phá nổi tiếng sẽ cho bạn biết nếu có thể có thứ gì đó "phụ" trong đó thì máy chủ DHCP của bạn không thích (tùy chọn 82 hoặc một cái gì đó khác có lẽ).
YLearn

1

Mặc dù bạn đã thử nghiệm SRX ở nơi khác:

  1. SRX có nhận được một địa chỉ với cùng cấu hình chính xác ở nhà không?
    • Điều này có nghĩa là sau đây không phải là vấn đề:
    • set security zones security-zone host-inbound-traffic system-services dhcp đã được thực hiện
    • Cấu hình giao diện cơ bản được thực hiện (giao diện thô, thẻ vlan, giao diện trong vlan chính xác, vlan đó trong
  2. Giao diện có thực sự xuất hiện rõ ràng ở phía Juniper không?
    • show interfaces fe-0/0/0 extensive là bạn của bạn
    • (Tôi biết nó không phù hợp với điều này, nhưng vẫn ...) Đối với giao diện quang cũng kiểm tra mức năng lượng: show interfaces diagnostics optics ge-0/0/0
  3. Thêm một dấu vết cho máy khách DHCP:
cấu hình
thiết lập dịch vụ hệ thống tệp theo dõi dhcp dhcp_client.log có thể đọc được trên thế giới
thiết lập hệ thống dịch vụ cờ theo dõi dhcp client
thiết lập hệ thống theo dõi dhcp cấp độ tất cả
cam kết và bỏ

Sau đó theo dõi nhật ký khi bạn đưa giao diện lên monitor start dhcp_client.log. (Hãy nhớ xóa theo dõi sau khi bạn hoàn thành)


1. Có, tôi đang làm điều này với các cấu hình mặc định của nhà máy, cả ở nhà và trong văn phòng. Cấu hình mặc định của nhà sản xuất bao gồm dhcp lưu lượng truy cập hệ thống lưu lượng truy cập máy chủ lưu trữ trên giao diện fe-0/0 / 0.0 mà tôi đang sử dụng. 2. Có, giao diện được dọn sạch và nếu tôi cấu hình thông tin IP tĩnh trên đó, nó sẽ hoạt động tốt. 3. Tôi đã chỉnh sửa câu hỏi ban đầu với một tcpdump của gói đi ra ngoài ... Tôi chưa bao giờ thấy một gói trả về, và không bao giờ thấy gói tin trúng máy chủ DHCP.
Jeff McAdams
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.