우리는 일반적으로 Windows XP가 설치된 교육 실을 가지고 있습니다 (PXE를 통해). “정상”DNS / DHCP 인프라는 Windows 서버입니다. 교육 실에는 자체 VLAN (Windows 서버와는 다름)이 있으므로 해당 회의실의 모든 PC가 연결된 Cisco 라우터에서 DHCP 요청에 대한 IP 도우미가 가장 적합합니다.
이제 일부 PC를 Linux로 변환하려고했습니다. 아이디어는 다음과 같습니다. DHCP 서버가있는 자체 랩톱을 회의실의 VLAN에 넣고 “정상적인”DHCP 응답을 무시하십시오. 해당 VLAN에 직접 연결된 DHCP 서버는 해당 VLAN에서 일부 홉 거리에있는 “일반”DHCP 서버보다 응답 시간이 더 빠르기 때문에 이것이 작동해야한다는 생각이었습니다.
이것이 효과가 없다는 것이 밝혀졌습니다. 작동하려면 원래 DHCP 서버에서 임대를 수동으로 해제해야했습니다.
랩톱에서 우리는 클라이언트가 IP를 요청하고 “우리의”dhcp가 NACK을 Windows IP 요청에 전송하는 것을 보았습니다.
오래된 질문 : 왜 이것이 예상대로 작동하지 않았습니까? PC가 기존 임대를 되찾게하는 이유는 무엇입니까?
2012-08-08 업데이트 :
회복 문제는 DHCP-RFC에 설명되어 있습니다. 이제 이것은 PC가 이전 임대를 다시 얻는 이유를 설명합니다.
이제 다른 시도를하기 전에 Windows-DHCP 서버에서 IP를 해제합니다.
다시 말하지만 Windows-DHCP 서버가 승리합니다.
클라이언트에 대한 “최상의”dhcp-answer를 결정하는 dhcp-client에 대한 알고리즘이 있다고 생각합니다. 새로운 질문은 :
고객이 “최고의”답변을 어떻게 선택합니까?
답변
클라이언트가 여러 DHCP 응답에 반응하는 방식은 펌웨어 별 공급 업체입니다.
몇 년 동안 내가 본 변형은 다음과 같습니다.
1) ACK인지 NACK인지에 관계없이 첫 번째를 수락하십시오.
2) 첫 번째 ACK를 취하고 NACK을 완전히 무시하십시오.
3) 설정된 시간 간격 (일반적으로 5-10 초) 내에 마지막으로 수신 한 ACK를 가져옵니다.
예 : 몇 년 전에 Ricoh MFP에 문제가있었습니다.
우리는 2 대의 DHCP 서버를 가지고있었습니다. 하나는 주소를 제공하고 다른 하나는 추가 DHCP 옵션을 제공했습니다. 두 번째 서버는 항상 먼저 응답했습니다.
Ricoh의 변형 1)은 첫 번째 오퍼에 DHCP 옵션 만 포함 된 경우에도 사용되었습니다. Ricoh는 문제를 설명한 후 펌웨어 업데이트를 통해 변형 2)로 변경했습니다.
답변
라우터가 여전히 DHCP 릴레이로 작동하고 요청을 원래 서버로 전달한다고 가정하면 Windows DHCP 서버가 계속 진행하여 IP를 사용하도록 요청했기 때문입니다. 이 경우 새 서버의 DHCPNACK은 관련이 없습니다. DHCP 클라이언트는 모든 응답을 고려하고 Windows DHCP 상자에서 제안을 받았으므로 사용하기에 매우 만족합니다.
PC : 세상에, 192.168.1.123을 사용할 수 있습니까?
New-DHCP : 아니요.
Old-DHCP : 그렇습니다.
PC : 누군가가 그렇다고 말했습니다! Sweet, 내가 사용할 게!
답변
아무것도 도움이되지 않으면-RTFM (좋은 매뉴얼을 읽으십시오). 이 경우 첫 번째는 히트였습니다.
RFC 2131 은 DHCP 작동에 대해 간략하게 설명합니다.
1.6 절에는 DHCP 가 다음 사항을 명시 해야합니다 .
서버 재부팅시 DHCP 클라이언트 구성을 유지하고 가능하면 DHCP 메커니즘을 다시 시작하더라도 DHCP 클라이언트에 동일한 구성 매개 변수를 할당해야합니다.
이제 흥미로운 질문은 과거에 대한 지식이없는 고객에게 어떻게 설계 목표를 달성하고 있는지입니다. 섹션 3.2 개요 :
3.2 클라이언트-서버 상호 작용-이전에 할당 된 네트워크 주소 재사용
클라이언트가 이전에 할당 된
네트워크 주소 를 기억하고 재사용하려는 경우 클라이언트는
이전 섹션에서 설명 된 일부 단계를 생략하도록 선택할 수 있습니다 . 그림 4의 타임 라인 다이어그램은
이전에 할당 된 네트워크 주소를 재사용하는 클라이언트에 대한 일반적인 클라이언트-서버 상호 작용의 타이밍 관계를 보여줍니다.
클라이언트는 로컬 서브넷에서 DHCPREQUEST 메시지를 브로드 캐스트합니다. 메시지는 ‘요청 된 IP 주소’옵션에 클라이언트의 네트워크 주소를 포함합니다. 클라이언트가 네트워크 주소를받지 못 했으므로 ‘ciaddr’필드를 채우지 않아야합니다. BOOTP 릴레이 에이전트는 동일한 서브넷이 아닌 DHCP 서버로 메시지를 전달합니다. 클라이언트가 ‘클라이언트 식별자’를 사용하여 주소를 얻은 경우 클라이언트는 DHCPREQUEST 메시지에서 동일한 ‘클라이언트 식별자’를 사용해야합니다.
클라이언트의 구성 매개 변수를 알고있는 서버는 클라이언트에 대한 DHCPACK 메시지로 응답합니다. 서버는 클라이언트의 네트워크 주소가 이미 사용 중인지 확인하지 않아야합니다. 이 시점에서 클라이언트는 ICMP 에코 요청 메시지에 응답 할 수 있습니다.
따라서 활성 임대를 보유한 DHCP 서버는 프로토콜의 바로 가기를 사용하여 우선합니다.
- 클라이언트 : DHCREQUEST (MAC- 주소, 브로드 캐스트는 로컬 브로드 캐스트 도메인에서 전송됩니다. 여기서 로컬 VLAN 및 IP 도우미를 통해 Windows-DHCP 서버로 전송됩니다)
- 노트북 -DHCP 서버 : DHCPOFFER
- Windows-DHCP-Server : Hey-이미 알고 있습니다-DHCPACK
- 클라이언트 : 오 – 두 가지 답변이 있습니다. 이미 나를 알고있는 사람. 멋지 겠어
그때부터 랩톱 -DHCP 서버는 클라이언트에 의해 무시됩니다.
따라서 우리의 경우 해결책은 아마도 (실제로 테스트 할 때 이것을 업데이트 할 것입니다) :
- 클라이언트가 꺼져 있는지 확인
- 랩톱에서 DHCP 서버 끄기, 랩톱에서 가짜 클라이언트 MAC, DHCP 요청
- IP 해제
- 원래 IP 및 MAC을 다시 얻으려면 DHCP 서버를 켜십시오.
- 클라이언트를 켜고 PXE 부팅을 수행하십시오.
답변
새로운 질문은 아마도 다른 질문에 있어야합니다. 질문의 제목은 질문의 본문 대부분과 맞지 않습니다.
어쨌든, 클라이언트가 어떤 제안을 선택해야하는지에 관해, 현재 임대가없는 경우 : 그것은 클라이언트에게 달려 있지만, 내가 알고있는 모든 DHCP 클라이언트 구현에서는 단순한 경쟁입니다. .
RFC 2131 은 다음을 다루고 있습니다.
DHCP 클라이언트는 클라이언트가 DHCPOFFER 메시지를받는 서버 중에서 DHCP 서버를 선택할 때 어떤 전략이든 자유롭게 사용할 수 있습니다.
선택 프로세스에 구성 기능을 추가하고 10 년 전에는 그다지 많지 않은 변경 사항이있는 클라이언트 구현 부족에 대해 언급 한 IETF 초안이 사라졌습니다.
실제로, 여기에서 대부분의 공급 업체의 정책 구현은 매우 기본적이며 (예를 들어, 첫 번째 오퍼 수신 또는 첫 번째 허용 오퍼 수신) “하드 코딩”(즉, 구성 할 수 없음)입니다.
서로 다른 구성으로 동일한 네트워크에 서비스를 제공하는 두 개의 DHCP 서버가 있으면 경쟁이 발생하기 때문에 안정성 또는 예측 가능성 관점에서 바람직하지 않습니다. 단일 DHCP 서버가 필요한 것을 제공 할 수없는 이유는 없습니다.