DHCP 클라이언트는 "최상의"답변으로 무엇을 고려합니까?


13

우리는 일반적으로 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에 대한 알고리즘이 있다고 생각합니다. 새로운 질문은 :

고객이 "최고의"답변을 어떻게 선택합니까?


어디에서 IP 주소를 공개합니까? Windows 클라이언트 또는 PXE 부트 에이전트에서
longneck

@longneck 우리는 Windows-DHCP 서버에서 주소를 공개해야 작동했습니다.
Nils

새로운 질문을하는 이상한 방법, 그래도 해결하기를 바랍니다
Daniel Li

답변:


4

클라이언트가 여러 DHCP 응답에 반응하는 방식은 펌웨어 별 공급 업체입니다.

몇 년 동안 내가 본 변형은 다음과 같습니다.

1) ACK인지 NACK인지에 관계없이 첫 번째를 수락하십시오.

2) 첫 번째 ACK를 취하고 NACK을 완전히 무시하십시오.

3) 설정된 시간 간격 (일반적으로 5-10 초) 내에 마지막으로 수신 한 ACK를 가져옵니다.

예 : 몇 년 전에 Ricoh MFP에 문제가있었습니다.
우리는 2 대의 DHCP 서버를 가지고있었습니다. 하나는 주소를 제공하고 다른 하나는 추가 DHCP 옵션을 제공했습니다. 두 번째 서버는 항상 먼저 응답했습니다.
Ricoh의 변형 1)은 첫 번째 오퍼에 DHCP 옵션 만 포함 된 경우에도 사용되었습니다. Ricoh는 문제를 설명한 후 펌웨어 업데이트를 통해 변형 2)로 변경했습니다.


OFFER패킷은 클라이언트 시스템 사이에서 결정을 필요로하는 무슨이다. ACKNACK패킷 만 응답으로 전송되어 REQUEST클라이언트가 후에 가서 제공하는 "결정"이후에만 발생합니다. 그래도 프린터의 멋진 버그입니다!
Shane Madden

@ShaneMadden 맞습니다.하지만 두 가지 제안에 대한 응답으로 요청을 보낸 다음 설명 된대로 응답을 수행하는 클라이언트의 사례가 많이 있습니다. 내가 이것을 깊이 본 이후 오랜 시간이 걸렸습니다. NT4, W2K 및 XP가 유죄임을 분명히 기억합니다. 리코도 마찬가지였다. 그들은 리눅스 2.2 커널과 네트워크 스택을 운영했다.
Tonny

9

라우터가 여전히 DHCP 릴레이로 작동하고 요청을 원래 서버로 전달한다고 가정하면 Windows DHCP 서버가 계속 진행하여 IP를 사용하도록 요청했기 때문입니다. 이 경우 새 서버의 DHCPNACK은 관련이 없습니다. DHCP 클라이언트는 모든 응답을 고려하고 Windows DHCP 상자에서 제안을 받았으므로 사용하기에 매우 만족합니다.

PC : 세상에, 192.168.1.123을 사용할 수 있습니까?

New-DHCP : 아니요.

Old-DHCP : 그렇습니다.

PC : 누군가가 그렇다고 말했습니다! Sweet, 내가 사용할 게!


PC의 콜드 부팅 후 대화는 "my MAC is XYZ-Please give a IP"로 시작됩니다. 그런 다음 두 DHCP 서버 모두 IP를 제공합니다. 유일한 차이점은 서버 중 하나에 임대가 있다는 것입니다. 그러나 이것은 서버의 관점 일뿐입니다.
Nils

1
PC에 이미 IP 주소가 있다면 아닙니다. 이전에 DHCP 서버에서 할당 한 IP 주소가있는 경우 다른 주소를 요청하기 전에 먼저 IP 주소를 사용하도록 요청합니다.
longneck

@longneck IP가 PC에서 어디에 저장됩니까?
Nils

내 머리 꼭대기에서 나는 모른다. 그러나 그것을 지우는 올바른 방법은 ipconfig / release를 사용하는 것입니다
longneck

3
@longneck-부팅 BIOS가 이전 부팅 또는 IP 주소를 기억하지 않는다고 가정하는 PXE 환경에서 op가 요청합니다.
Mark Henderson

3

아무것도 도움이되지 않으면-RTFM (좋은 매뉴얼을 읽으십시오). 이 경우 첫 번째는 히트였습니다.

RFC 2131 은 DHCP 작동에 대해 간략하게 설명합니다.

1.6 절에는 DHCP 다음 사항을 명시 해야합니다 .

서버 재부팅시 DHCP 클라이언트 구성을 유지하고 가능하면 DHCP 메커니즘을 다시 시작하더라도 DHCP 클라이언트에 동일한 구성 매개 변수를 할당해야합니다.

이제 흥미로운 질문은 과거에 대한 지식이없는 고객에게 어떻게 설계 목표를 달성하고 있는지입니다. 섹션 3.2 개요 :

3.2 클라이언트-서버 상호 작용-이전에 할당 된 네트워크 주소 재사용

클라이언트가 이전에 할당 된
네트워크 주소 를 기억하고 재사용하려는 경우 클라이언트는
이전 섹션에서 설명 된 일부 단계를 생략하도록 선택할 수 있습니다 . 그림 4의 타임 라인 다이어그램은
이전에 할당 된 네트워크 주소를 재사용하는 클라이언트에 대한 일반적인 클라이언트-서버 상호 작용의 타이밍 관계를 보여줍니다.

  1. 클라이언트는 로컬 서브넷에서 DHCPREQUEST 메시지를 브로드 캐스트합니다. 메시지는 '요청 된 IP 주소'옵션에 클라이언트의 네트워크 주소를 포함합니다. 클라이언트가 네트워크 주소를받지 못 했으므로 'ciaddr'필드를 채우지 않아야합니다. BOOTP 릴레이 에이전트는 동일한 서브넷이 아닌 DHCP 서버로 메시지를 전달합니다. 클라이언트가 '클라이언트 식별자'를 사용하여 주소를 얻은 경우 클라이언트는 DHCPREQUEST 메시지에서 동일한 '클라이언트 식별자'를 사용해야합니다.

  2. 클라이언트의 구성 매개 변수를 알고있는 서버는 클라이언트에 대한 DHCPACK 메시지로 응답합니다. 서버는 클라이언트의 네트워크 주소가 이미 사용 중인지 확인하지 않아야합니다. 이 시점에서 클라이언트는 ICMP 에코 요청 메시지에 응답 할 수 있습니다.

따라서 활성 임대를 보유한 DHCP 서버는 프로토콜의 바로 가기를 사용하여 우선합니다.

  1. 클라이언트 : DHCREQUEST (MAC- 주소, 브로드 캐스트는 로컬 브로드 캐스트 도메인에서 전송됩니다. 여기서 로컬 VLAN 및 IP 도우미를 통해 Windows-DHCP 서버로 전송됩니다)
  2. 노트북 -DHCP 서버 : DHCPOFFER
  3. Windows-DHCP-Server : Hey-이미 알고 있습니다-DHCPACK
  4. 클라이언트 : 오 – 두 가지 답변이 있습니다. 이미 나를 알고있는 사람. 멋지 겠어

그때부터 랩톱 -DHCP 서버는 클라이언트에 의해 무시됩니다.

따라서 우리의 경우 해결책은 아마도 (실제로 테스트 할 때 이것을 업데이트 할 것입니다) :

  1. 클라이언트가 꺼져 있는지 확인
  2. 랩톱에서 DHCP 서버 끄기, 랩톱에서 가짜 클라이언트 MAC, DHCP 요청
  3. IP 해제
  4. 원래 IP 및 MAC을 다시 얻으려면 DHCP 서버를 켜십시오.
  5. 클라이언트를 켜고 PXE 부팅을 수행하십시오.

3

새로운 질문은 아마도 다른 질문에 있어야합니다. 질문의 제목은 질문의 본문 대부분과 맞지 않습니다.

어쨌든, 클라이언트가 어떤 제안을 선택해야하는지에 관해, 현재 임대가없는 경우 : 그것은 클라이언트에게 달려 있지만, 내가 알고있는 모든 DHCP 클라이언트 구현에서는 단순한 경쟁입니다. .

RFC 2131 은 다음을 다루고 있습니다.

DHCP 클라이언트는 클라이언트가 DHCPOFFER 메시지를받는 서버 중에서 DHCP 서버를 선택할 때 어떤 전략이든 자유롭게 사용할 수 있습니다.

선택 프로세스에 구성 기능을 추가하고 10 년 전에는 그다지 많지 않은 변경 사항이있는 클라이언트 구현 부족에 대해 언급 한 IETF 초안이 사라졌습니다.

실제로, 여기에서 대부분의 공급 업체의 정책 구현은 매우 기본적이며 (예를 들어, 첫 번째 오퍼 수신 또는 첫 번째 허용 오퍼 수신) "하드 코딩"(즉, 구성 할 수 없음)입니다.

서로 다른 구성으로 동일한 네트워크에 서비스를 제공하는 두 개의 DHCP 서버가 있으면 경쟁이 발생하기 때문에 안정성 또는 예측 가능성 관점에서 바람직하지 않습니다. 단일 DHCP 서버가 필요한 것을 제공 할 수없는 이유는 없습니다.


"허용 가능한"오퍼는 dhcp-client 측에서 벤더마다 다르다고 생각하십니까? 우리의 경우에는 그것이 "첫 번째"제안이 아니기 때문에 그것은 다른 것이어야합니다. 행동은 꽤 결정 론적입니다. 그래서 나는 여전히 이것 뒤에 공통 표준이 있다고 생각합니다.
Nils

@Nils 같은 방에서 랩톱을 사용하기 전에 Windows 서버가 클라이언트에 대한 응답을받지 못한다고 확신하십니까? 직관적으로 랩톱이 경쟁에서이기는 것처럼 보이지만 실제로는 그렇지 않을 수 있습니다.
Shane Madden

실제로 네트워크 수준 (wireshark 사용)에서 이것을 추적하여 실제로 무슨 일이 일어나고 있는지 볼 것입니다. 아마도 그 클라이언트의 미러 포트에서 ...
Nils
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.