HP Procurve DHCP 릴레이와 SRX DHCP 클라이언트 호환성


10

일부 Juniper SRX100에서 구성을 부트 스트랩하려고하며 DHCP 문제가 있습니다.

특히, 나는 0/0 포트 (소프트웨어의 fe-0 / 0 / 0)를 기존 네트워크에 연결하고 있는데, DHCP는 내가 사용한 다른 모든 장치에 대해 상당히 안정적으로 작동했습니다. SRX100에 DHCP 주소가 없습니다. 이것을 시도 할 때 SRX100은 기본 구성입니다.

장치 중 하나를 집으로 가져 와서 홈 네트워크에 꽂았으며 DHCP를 통해 홈 네트워크의 IP 주소를 문제없이 얻었습니다.

내 사무실 네트워크에는 데스크탑에 Procurve 1400 (계층 2 만) 스위치가 있고 Polycom IP670 IP 전화기 (단순한 계층 2 스위치로 작동)에 업 링크되어 있으며 "ip를 사용하여 네트워크의 라우터 역할을하는 Procurve 3500yl 스위치에 업 링크되어 있습니다. DHCP 릴레이를 위해 DHCP 서버를 가리키는 VLAN 인터페이스의 helper-address 1.1.1.1 "

누구나 Procurve를 통해 SRX DHCP 클라이언트가 IP 주소를 얻는 경험이 있습니까 (K.15.09.0012 소프트웨어 실행 중 ... Procurve의 여러 펌웨어 버전에 문제가 있었음에도 불구하고). SRX100은 상자에 나왔을 때 11.2를 사용하는 것처럼 보이지만 12.1X44-D10.4로 업그레이드해도 문제가 계속 존재한다고 생각합니다.

누구 든지이 문제를 해결하기위한 제안이 있습니까? Procurve 3500yl은 SRX100에서 DHCP 클라이언트 요청이 들어오는 것을 인정하지는 않지만이 영역의 Procurves에 대한 문제 해결 정보는 제한적입니다. DHCP 서버에는 SRX100과 관련된 DHCPDISCOVER 패킷이 도착하지 않습니다.

해결 방법은 네트워크에서 SRX100을 가져오고 나머지 구성을 수행하기 위해 SRX100에서 IP 주소를 정적으로 구성하는 것이었지만 작업중인 프로젝트는 SRX100을 제어 할 수없는 원격 위치로 전송하는 것입니다. 따라서 신뢰할 수있는 연결을 위해 DHCP 주소를 얻는 사람들에 달려 있으므로이 문제를 해결하고 특정 원인을 해결하고 싶습니다. 원격 사이트에서 발생할 경우 잠재적으로 무엇을 찾아야하는지 알고 싶습니다.

업데이트 : SRX100을 공장 기본값으로 재확인하고 Procurve 3500yl의 포트에 직접 꽂았는데 여전히 문제가 발생하여 1400과 IP670 전화가 토론에서 제거됩니다. SRX100의 tcpdump 출력을 아래에 포함 시켰습니다. 아시다시피, 가능한 가장 간단한 DHCP 패킷에 대한 전송은 3500yl의 dhcp-relay 기능에 문제가 있음을 나타내는 경향이 있습니다. 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

1400 또는 Polycom이 DHCPDISCOVER 브로드 캐스트를 필터링하지 않도록 SRX를 3500yl에 직접 연결해 보셨습니까?
David Rothera

나는하지 않았으며 그것은 나쁜 생각이 아닙니다. 그러나 때때로 같은 방식으로 다른 시스템을 연결하고 이러한 방식으로 네트워크에 지속적으로 연결된 데스크탑 컴퓨터를 포함하여 다른 시스템에서 DHCP 주소를 얻으므로 문제가되지 않는 것 같습니다. 그래도 테스트 할 수 있는지 살펴 보겠습니다.
Jeff McAdams

SRX에서 DHCP 요청의 TTL 값을 변경하는 방법과 HP에서 RFE를 열었 음을 알리는 응답으로 일부 정보가 업데이트되었습니다.
Jeff McAdams

답변:


9

이 문제와 관련하여 HP에 사례를 열었습니다. 쓸모없는 레벨 1 기술을 넘어서면서 레벨 2 기술은 내가 알지 못하는 것을 매우 경고했습니다.

SRX는 TTL이 1 인 DHCPDISCOVER 패킷을 전송하고 있습니다. Procurve는 분명히 TTL을 줄이고 릴레이 된 패킷의 결과 TTL을 DHCP 서버에 사용합니다. 이 경우 감소는 TTL을 0으로 남겨두고 패킷이 바닥에 떨어짐을 의미합니다.

이것은 실제로 DHCP / BOOTP 릴레이 사양이지만 상호 운용성을 떨어 뜨립니다. HPNetworking에이를 버그 / RFE로 취급하고 동작을 변경하도록 요청했습니다. 이 경우 해당 요청에 즉시 응답하지 않습니다.

TTL이 1 인 DHCPDISCOVER를 전송하는 SRX도 사양 내에 있지만 아마도 상호 운용성을 줄 이도록 선택했기 때문에 JTAC와 동일한 사례를 열 계획입니다.

주니퍼와 HP가 출시되면 이에 대한 정보를 추가 할 예정입니다.

또한 Cisco 4506 (펌웨어 버전을 즉시 사용할 수 없음)과 Brocade / Foundry FastIron Edge X (7.2 또는 7.3 펌웨어, 즉시 확인할 권한이 없다고 생각합니다)의 릴레이 동작을 테스트했으며 둘 다 처리합니다. 문제없이 TTL 1로 요청을 릴레이합니다.

업데이트 SRX가 DHCP 요청에 사용하는 TTL 값을 변경하는 방법이 있지만 JunOS 클리닉 내에서는 그렇지 않습니다. 기본 Unix OS에서 수행 된 값입니다.

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

나는 중계 기능을보다 탄력적으로 만들기 위해 HP와 RFE를 열었지만 아직 작동 여부에 대해서는 아직 응답하지 않았습니다.


2

SRX100, 1400 및 IP670과 같은 가시성 문제가 발생하기 전에 문제의 위치를 ​​모르고 세 공급 업체의 장치 3 개가있는 경우 문제를 해결하기가 어려울 수 있습니다. 특정 장치와 통신 할 수는 없지만 패킷을 추적하여 잘못 될 수는 없습니다. ProCurve 1400은 관리되지 않는 장치이므로 네트워크 탭을 사용해야합니다.

3500yl이 발견 패킷을 수신하지 않는다는 진술에 따라 다음 위치에서 트래픽을 캡처하려고합니다.

  • SRX100과 1400 사이
  • 1400과 IP670 사이
  • IP670과 3500yl 사이

책상에서이 모든 작업을 수행 할 수 있으며, 연결 / 연결 해제 중 탭이 중단되는 동안 사용자와 장치에만 영향을 미칩니다.

DHCP 검색 패킷을 한 번 이상 캡처 한 다음 DHCP 검색 패킷의 후속 캡처를이 패킷과 비교하여 수정 사항이 있는지 확인할 수 있기 때문에이 목록의 맨 위에서 시작하겠습니다.

SRX100이 전송하는 검색 패킷과의 차이점이 있는지 확인하기 위해 작동중인 장치에서 DHCP 검색 패킷을 캡처 할 수도 있습니다.

패킷의 위치가 잘못되면 그 시점에서 패킷이 잘못되는 이유를 구체적으로 조사 할 수 있습니다.


예, 1400과 ip670이 2 계층만으로 확실하게 DHCP 트래픽에 영향을 미치지 않는다는 확신을 가지기 때문에 아직 구체적인 단계를 거치지 않았습니다. 내가 생각하는 문제가 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 traceoptions 파일 dhcp_client.log 세계 판독 가능
시스템 서비스 설정 dhcp traceoptions 플래그 클라이언트
시스템 서비스 설정 dhcp traceoptions level all
커밋하고 종료

그런 다음로 인터페이스를 표시 할 때 로그를 모니터링하십시오 monitor start dhcp_client.log. (완료되면 traceoption을 삭제하십시오.)


1. 그렇습니다. 가정과 사무실에서 모두 공장 출하시 기본 구성을 사용하여이 작업을 수행하고 있습니다. 공장 기본 구성에는 내가 사용하는 fe-0 / 0 / 0.0 인터페이스에 host-inbound-traffic system-services dhcp가 포함되어 있습니다. 2. 그렇습니다. 인터페이스는 깨끗하게 설정되어 있으며, IP 정보를 고정 설정하면 제대로 작동합니다. 3. 패킷의 tcpdump가 나가는 원래 질문을 편집했습니다. 리턴 패킷이 전혀없고 패킷이 DHCP 서버에 도달하는 것을 보지 못했습니다.
Jeff McAdams
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.