일부 스위치의 전화기는 DHCP 프로세스를 완료 할 수 없습니다


16

배경

여러 범위의 주소를 전달하는 Windows DHCP 서버 (Server 2008 R2)가 있습니다. 이러한 범위 중 하나는 일부 Mitel IP 폰입니다. 전화기는 dhcp 옵션 125를 사용하여 구성 정보를 가져 오도록 구성되어 있습니다. 전화가 시작되면 어떤 VLAN을 사용해야하는지 알 수 없으므로 연결된 포트의 기본 (태그 없음) VLAN 만 가져옵니다. dhcp 서버는 옵션 125 정보가 포함 된 응답을 제공하며 전화기는이 응답에서 어떤 VLAN을 사용해야하는지 읽을 수 있습니다. 그런 다음 전화기는 원래 주소를 해제하고 올바른 VLAN 태그를 사용하여 새 DHCP 임대를 요청합니다. 전화에는 일반적으로 컴퓨터가 통과 포트에 연결되어 있습니다. 컴퓨터의 패킷에는 태그가 지정되지 않으므로 PC는 포트의 원래 (태그가 지정되지 않은) VLAN에 유지됩니다. 이것은 수년간 우리를 위해 일해 왔습니다.

문제와 증상

지난 몇 주 동안 어딘가에 무언가가 바뀌었고, 나는 무엇을 확신하지 못합니다. 전화기는 다시 시작되지 않는 한 계속 작동하므로 dhcp 갱신 요청이 올바르게 처리되어야합니다. 특정 스위치에 연결된 전화는 다시 시작해도 살아남을 수 있습니다. 그러나 다른 스위치에 연결된 전화기는 재부팅 할 때 프로세스를 완료하지 못합니다. 모든 전화에서 UPS로 백업 된 PoE를 사용하고 있으므로 다시 시작한 지 오래되었습니다. 이것은 문제가 언제 처음 나타 났는지 전혀 모른다는 것을 의미합니다. 내가 아는 것은 어제 다시 시작했을 때 한 대의 전화가 고장 났으며 오늘 문제를 해결함에 따라 해당 스위치 클로짓을 재설정했습니다. 이제 해당 스위치의 전화가 작동하지 않습니다 (고맙게도 여전히 작은 수입니다). 또한 1 월 말경에 일이 진행되고 있다는 것도 알고 있습니다.

전화가 부팅되는 것을 볼 때 첫 번째 주소가 성공적으로 표시되는 것을 볼 수 있습니다. 그런 다음 옵션 125 정보를 읽은 후 올바른 VLAN 태그를 설정하고 원래 IP 임대를 해제합니다. 심지어 서버에서 올바른 VLAN에 대한 제안을 받고 수락 할 수도 있습니다 . 그러나, 여기서 멈추게됩니다. 전화기에 화면에 " DHCP: Offer 2 ACC" 라는 메시지가 있지만 Windows DHCP 서버가 임대를 기록하지 않았으며 전화기가 계속 움직이지 않습니다. DHCP REQUEST 패킷이 Windows 서버에 도달하지 않는다고 추측 할 수 있으므로 전화기는 Windows의 마지막 ACK를 계속 기다리고 있습니다.

해결 방법

나는 마침내 전화를 다시 작동시킬 수 있었다. 그러기 위해서는 먼저 컴퓨터 연결을 끊어야했습니다. 그런 다음 PC vlan에 멤버십없이 전화 vlan에서 전화기의 스위치 포트에 태그가 지정되지 않도록 설정했습니다. 이제 전화가 올바르게 재부팅됩니다. 이 시점에서 스위치 포트 구성을 원래 위치로 되돌릴 수 있으며 포트를 재설정 할 때 아무도 해당 번호로 전화를 걸지 않는 한 전화가 결코 빠지지 않습니다. 그런 다음 컴퓨터를 다시 연결할 수 있습니다. 전화가 재부팅되지 않기 때문에 근본적인 원인을 찾을 때까지 사람들이 다시 일할 수 있도록하는 것은 드물지만 이상적인 프로세스는 아닙니다. 사무실은 이제 일주일 동안 문을 닫았으므로이 문제는 실제로 주말 동안 앉아있을 수 있습니다 (전화가있는 개별 사무실의 키는 없습니다).

내가 고친이 전화는 서버 룸의 서비스 전화이며 핵심 스위치에 직접 연결되어 있습니다. 코어 스위치에서 태그를 라우팅하거나 처리하는 데 문제가있을 수 있습니다. 따라서 다른 스위치를 통해 패킷이 먼저 전달되는 (태그가 지정된) 원격 사무실에서는이 해결 방법이 효과적이지 않지만 매우 놀랄 것입니다. 그런 일이 발생하면 dhcp 갱신 및 실제 전화 대화를 올바르게 처리해야한다는 것을 알고 있습니다.

트위스트는 PC vlan에 포트에 태그를 남겨두면 " DHCP: Offer 1 ACC" 메시지와 함께 전화가 실패한다는 의미입니다 . 이 성공을 위해서는 해당 vlan을 완전히 제거해야합니다.

참고 : 이제 해결 방법이 원격 건물에 효과적임을 확인했습니다. 이로 인해 내 장치가 어떻게 든 올바른 VLAN에 할당되지 않은 것으로 의심됩니다. 핵심 스위치에서 문제가 발생했으며 네트워크의 여러 위치에서 거의 동시에 발생했다는 사실은 핵심 스위치가 문제 일 수 있음을 나타냅니다. 살펴볼 내용이 없으므로 스위치를 재부팅하기 위해 주말 근처에 유지 관리 기간을 예약합니다. 펌웨어를 업데이트 할 수도 있습니다.

환경

핵심 스위치는 HP 5406zl입니다. 이 스위치는 VLAN 간 라우팅을 처리합니다. Windows DHCP 서버가 스위치에 직접 연결되어 있습니다. 엔드 포인트 스위치는 파이버 SFP를 통해 코어 스위치에 연결되며이 포트는 양쪽 끝에있는 모든 VLAN에 대해 태그가 지정됩니다. 코어 스위치는 각 VLAN을 ip helper-addressDHCP 서버를 가리키는 설정과 dhcp relay-option 82 replacedhcp 서버가 사용할 범위를 알 수 있도록 줄을 구성합니다. 이러한 구성 및 엔드 포인트 스위치의 포트 구성은 16 개월 이상 변경되지 않았습니다. 그 당시 다른 스위치 및 전화 재설정이있었습니다.

엔드 포인트 스위치는 대부분 HP 2530 시리즈입니다. 이 스위치는 올바르게 작동하는 것 같습니다 (3 개의 다른 2530 전화가 오늘 올바르게 다시 시작되었습니다). 문제가있는 구형 스위치입니다. 오래된 3Com 4200과 작동하지 않는 4210이 있습니다. 앞에서 언급 한 핵심 스위치에 직접 연결된 서비스 전화도 작동하지 않습니다.

질문

이 시점에서 가장 좋은 추측은 dhcp 서버의 Windows 업데이트가 동작을 변경했지만 방법을 알 수 없다는 것입니다. 또는 코어 스위치가 해당 REQUEST 패킷을 올바르게 처리하지 못할 수도 있지만 변경된 것은 없다고 확신하며 특정 엔드 포인트 스위치 만 영향을받는 이유는 설명하지 않습니다. 이 문제를 어떻게 해결할 수 있습니까?

최신 정보:

다음은 실패한 전화에서 발췌 한 dhcp 로그입니다.

10,03 / 06 / 15,12 : 40 : 40, 지정, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12 : 40 : 40, 갱신, 10.1.2.158, , 08000F197844,, 3189088995,0```` 12,03 / 06 / 15,12 : 40 : 41, 릴리스, 10.1.2.158,, 08000F197844,, 3189088995,0`` 40 : 45, NACK, 10.1.2.154,, 08000F197844,, 0,6``, 15,03 / 06 / 15,12 : 40 : 45, NACK, 10.1.2.154,, 08000F197844,, 0,6,``

10.xxx 주소는 PC vlan입니다 (이 위치는 이전에 선택되었습니다). 전화는 처음에는 이런 종류의 주소를 가져와야합니다. 그러나 릴리스 메시지 후 192.168.16.x 범위의 주소에 대한 제안도 찾을 수 있습니다. 전화로 제안이 수락되었음을 알 수 있기 때문입니다 ( "ACC"를 잘못 해석하지 않는 한). 전화가 전화를 받았다고 생각하더라도 서버가 그러한 주소를 발행하려고 시도하는 것을 결코 보지 못하는 것은 흥미 롭습니다.

네트워크에 불량 DHCP 서버가 있다는 아이디어를 고려했지만 (Windows 서버보다 먼저 주소를 전달하지만 휴대 전화가 필요로하는 dhcp 옵션이없는 경우) 전화가 작동하는 이유는 설명하지 않습니다. PC vlan에 대한 경로를 완전히 제거합니다. 아침에 랩톱을 전화 VLAN에 설정된 포트에 연결하여 어쨌든 테스트 할 것입니다. 그러나 다른 사람이 그 동안 더 나은 설명을 가지고 있다면 듣고 싶습니다.

스위치 구성의 사본은 다음과 같습니다.

http://pastebin.com/veXjCRXu


DHCP REQUEST 패킷이 서버에 도달하지 않는다는 것을 잘 알고 있습니다. 이제 DHCP 서버의 로깅 수준을 높이거나 트래픽을 감지하고 직감을 확인하십시오. 막히지 마십시오. 당신은 이것을 할 수 있습니다.
Skyhawk

1
답은 없지만 잘 생각하고 테스트 한 질문에 +1하십시오.
그랜트

1
@ 스카이 호크 (Skyhawk)는 저녁 식사를 위해 멈추었지만 다음 단계였습니다. 결과가 문제입니다.
Joel Coel

ProCurve 5406zl 소프트웨어 버전을 알려주시겠습니까?
ewwhite

1
나는 6-12 개월 동안 특정 개정판에서 이러한 스위치를 실행하는 경향이 있습니다. 동일한 개념을 사용하는 Shoretel 전화와 유사한 스위치를 사용하고 있습니다. 위생 설정을 보는 것이 흥미로울 것입니다.
ewwhite

답변:


2

오늘 DHCP 서버에 연결하는 포트에서 전화 VLAN의 VLAN 태그를 제거하여 문제를 해결했습니다. 비슷한 방식을 사용하는 다른 시스템 (일명 802.1q를 사용하는 Wi-Fi SSID)이 태그를 요구하거나 클라이언트가 주소를 얻을 수 없기 때문에 이것이 효과가 있다는 것은 매우 이상합니다. 그것은 효과가 있었기 때문에 너무 어려워 보이지는 않지만 이것이 왜 그런지에 대한 이론으로 대답을 보는 데 관심 이 있습니다.


0

문제가있는 스위치의 양쪽에서 패킷 캡처를 실행 한 다음 Wireshark에서이를 검토하는 것이 좋습니다. 이것은 1) 악성 DHCP 서버가 트래픽을 가로 채고 있는지 (MAC 주소를 기반으로) 2) 무언가가 엉망이되거나 떨어지면 (예 : DHCP 릴레이가 필요할 수 있음) 알려줍니다. 포트 미러링이 필요하거나 3com이 스위치에서 직접 캡처를 지원할 수 있습니다.


0

이 문제가 다시 발생하면 DHCP 범위의 크기와 사용중인 임대 수를 확인하십시오. 오래된 DHCP 임대가 삭제되지 않으면 서버에 풀에 남아있는 주소가없고 새 주소를 할당 할 수 없다고 생각할 수 있습니다. VLAN에 응답하는 장치가없는 경우에도 마찬가지입니다. DHCP 범위가 7 일인 경우 새 임대를 얻을 수 있기까지 최대 7 일이 소요될 수 있습니다. 마찬가지로 구성을 변경하면 문제를 해결할 수있는 새로운 범위의 주소가 있거나 구성 변경에 따라 임대를 플러시 할 수 있기 때문에 문제가 해결됩니다. 이 경우 임대 기간을 해당 범위의 시간과 같이 매우 낮은 것으로 설정하는 것이 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.