노트북은 네트워크에 연결되면 IP 주소를 어떻게 자동으로 받을까

아직 IP 주소가 없는 클라이언트는 DHCP 서버를 어떻게 찾아낼까↑

처음 연결한 클라이언트는 사용할 IPv4 주소가 없으므로 DHCPDISCOVER를 Broadcast로 보냅니다. DHCP는 UDP를 사용하며 서버는 포트 67, 클라이언트는 포트 68을 사용합니다.

Broadcast는 기본적으로 라우터를 넘지 않습니다. 클라이언트와 서버가 다른 Subnet에 있으면 게이트웨이의 DHCP Relay가 요청을 받아 서버로 전달하고 어느 클라이언트망에서 왔는지 알려 줍니다.

클라이언트는 초기 DHCPDISCOVER에서 Source IP로 0.0.0.0, Destination으로 255.255.255.255를 사용할 수 있습니다. Transaction ID와 클라이언트 식별 정보는 이후 Offer와 자신의 요청을 연결하는 단서가 됩니다. 아직 자신의 Subnet과 서버 위치를 모르는 상태이므로 Broadcast가 출발점입니다. 이 패킷이 Access VLAN에 나타나지 않으면 서버나 Relay보다 클라이언트, 포트와 VLAN 분류를 먼저 확인해야 합니다.

같은 Broadcast 도메인에 서버가 있다면 직접 응답할 수 있지만, 기업망에서는 보통 Gateway의 Relay가 요청을 받아 중앙 서버로 전달합니다. 이때부터 Relay와 서버 사이 트래픽은 Route 가능한 Unicast가 됩니다. 따라서 “Broadcast는 라우터를 넘지 않는다”와 “다른 Subnet의 DHCP 서버를 사용할 수 있다”는 설명은 모순이 아닙니다. Relay가 Broadcast 경계에서 새 패킷으로 중계하고 클라이언트가 속한 망의 정보를 함께 제공하기 때문입니다.

Discover가 보인다고 서버까지 도달했다는 뜻은 아닙니다. VLAN, 포트 보안, DHCP Snooping과 Relay 설정이 Broadcast 경로를 결정합니다. 첫 캡처에서는 클라이언트 인터페이스의 Discover 시각과 반복 간격을 기록하고, 같은 Transaction이 서버 또는 Relay 쪽에서 관찰되는지 연결해야 합니다. 이렇게 해야 미응답과 전달 실패를 같은 증상으로 묶지 않게 됩니다.

이 절의 근거 IETF RFC 2131

도해에서 확인할 내용 아래 도해는 앞에서 설명한 흐름을 바탕으로 BOOTP 호환 고정 헤더와 DHCP Option의 TLV 구조, xid·yiaddr·chaddr·메시지 Type 등 패킷 Field까지 한 화면에 정리했습니다. 필드 이름과 예시 값을 비교하면 본문에서 확인한 정보가 어떤 헤더 필드와 옵션에 담기는지 한눈에 대조할 수 있습니다.

여러 Offer 가운데 하나를 고른 뒤 ACK를 받아야 비로소 Lease가 확정된다↑

서버는 사용 가능한 주소와 Subnet Mask, 라우터, DNS 서버, Lease Time 같은 Option을 DHCPOFFER에 담습니다. 여러 서버가 응답할 수 있으므로 Offer는 아직 최종 설정이 아닙니다.

클라이언트는 선택한 서버와 주소를 DHCPREQUEST로 알립니다. 선택받은 서버가 DHCPACK를 보내면 클라이언트는 설정을 적용합니다. 사용할 수 없는 요청이면 DHCPNAK로 다시 시작하게 할 수 있습니다.

클라이언트는 받은 Offer 가운데 하나를 선택한 뒤 DHCPREQUEST에 요청 주소와 선택한 서버 정보를 담아 알립니다. 초기 과정에서 이 Request를 Broadcast로 보내면 다른 서버도 자신이 선택되지 않았음을 알고 제안한 주소를 Pool로 돌릴 수 있습니다. 선택된 서버는 정책과 주소 상태를 다시 확인해 ACK 또는 NAK를 보냅니다. DORA는 네 개 이름을 외우는 절차가 아니라 후보 발견, 선택 공개, 최종 승인이라는 상태 전환입니다.

ACK에는 IP만 있는 것이 아닙니다. Prefix, Default Gateway, DNS 서버, Lease Time과 여러 Option이 클라이언트의 실제 통신 환경을 결정합니다. 주소는 맞는데 DNS나 Gateway만 틀린 장애가 생길 수 있으므로 ACK를 받았다는 사실만 확인해서는 부족합니다. 서버가 기록한 Lease와 클라이언트가 적용한 Option을 나란히 비교하고, 클라이언트가 같은 주소에 대한 충돌 신호를 발견해 DHCP Decline 메시지를 보냈는지도 함께 봐야 합니다.

ACK에 주소만 있고 올바른 라우터 또는 DNS Option이 없다면 클라이언트는 “주소를 받았지만 서비스에 접근하지 못하는” 상태가 될 수 있습니다. DHCP 성공 여부를 IP 하나로 판정하지 않고 Prefix, 라우터, DNS, Lease Time과 적용 인터페이스를 함께 확인합니다.

이 절의 근거 IETF RFC 2131

도해에서 확인할 내용 아래 도해는 Discover·Offer·Request·ACK 교환의 대표적인 초기 흐름을 보여 줍니다. Broadcast/Unicast 선택은 클라이언트 상태와 구현에 따라 달라질 수 있습니다. 클라이언트·서버 사이의 DORA 메시지 번호를 따라가며 yiaddr와 요청 주소·임대 시간 옵션 예시를 비교할 수 있습니다.

Lease가 끝날 때까지 기다리지 않고 T1부터 갱신을 시작하는 이유↑

DHCP 주소는 소유권을 영구 이전하는 것이 아니라 일정 시간 사용하도록 허용하는 Lease입니다. 클라이언트는 일반적으로 Lease의 T1 시점에 기존 서버로 갱신을 시도합니다. 성공하면 같은 주소를 계속 사용할 수 있습니다.

T1에서 갱신하지 못하고 T2에 이르면 다른 서버도 응답할 수 있도록 Rebinding을 시도합니다. 만료까지 ACK를 받지 못하면 주소 사용을 중단하고 처음 절차로 돌아가야 합니다. 구체적인 T1·T2 값은 서버가 Option으로 제공할 수 있습니다.

Lease가 8시간이고 서버가 별도 값을 주지 않는 일반적인 예를 들면 클라이언트는 약 4시간인 T1부터 기존 서버에 Unicast DHCPREQUEST로 Renewal을 시도할 수 있습니다. T1에서 응답을 못 받았다고 주소를 즉시 버리지는 않습니다. 약 7시간인 T2에 이르면 Broadcast를 사용한 Rebinding으로 다른 서버의 도움을 구하고, 8시간 만료 전까지 유효한 ACK를 기다립니다. 실제 T1·T2는 Option과 구현을 확인해야 합니다.

노트북이 절전 후 다른 네트워크에 연결되는 경우처럼 링크 환경이 바뀌면 남은 Lease Time만 믿고 예전 주소를 계속 써서는 안 됩니다. 클라이언트는 INIT-REBOOT 같은 상태에서 이전 주소를 다시 사용할 수 있는지 서버에 확인할 수 있습니다. 장애 분석에서는 패킷 하나만 보지 말고 클라이언트가 Initial Binding, Renewal, Rebinding 중 어디에 있는지 구분해야 합니다. 같은 DHCPREQUEST라도 Destination과 포함 Option이 다른 이유가 여기에 있습니다.

T1과 T2 비율, 재시도 간격과 클라이언트 동작은 Option과 구현에 따라 달라질 수 있습니다. 장애를 볼 때 현재 주소만 확인하면 이전 ACK로 받은 Lease가 아직 살아 있어 문제가 숨습니다. Lease 시작·T1·T2·만료 시각과 갱신 패킷을 함께 기록해야 서버 장애가 신규 클라이언트와 기존 클라이언트에 다르게 보이는 이유를 설명할 수 있습니다.

이 절의 근거 IETF RFC 2131

도해에서 확인할 내용 아래 시간축은 Lease Time이 8시간이고 별도 T1·T2 옵션이 없을 때의 예입니다. 임대 시작, T1 갱신(4시간), T2 재바인딩(7시간), Lease Expiry(8시간)를 순서대로 보여 줍니다. 시점별 설명에서 요청 대상의 변화와 갱신하지 못한 임대 주소의 사용 중단을 확인할 수 있습니다.

다른 VLAN의 DHCP 서버까지 Broadcast가 가지 못하는데도 주소를 받는 방법↑

대규모 망은 VLAN마다 DHCP 서버를 두기보다 중앙 서버와 Relay를 사용합니다. Relay는 클라이언트의 Broadcast를 Unicast로 전달하고 giaddr 같은 정보를 이용해 요청이 들어온 Subnet을 알려 줍니다.

서버는 그 정보를 보고 알맞은 Scope에서 주소를 고릅니다. Relay 주소나 정책이 잘못되면 서버가 살아 있어도 다른 Scope를 선택하거나 응답 경로를 찾지 못할 수 있습니다. Option 82를 쓰는 환경에서는 Relay가 회선·포트 식별 정보를 추가할 수 있으며 신뢰 경계를 명확히 해야 합니다.

서버는 Relay가 채운 giaddr를 보고 어느 Subnet의 Scope에서 주소를 골라야 하는지 판단하고, 응답도 해당 Relay 방향으로 보냅니다. Relay가 여러 인터페이스를 가졌거나 VRF를 사용한다면 어느 Source와 라우팅 문맥으로 서버에 접근하는지가 중요합니다. 요청이 서버 Log에 도착했어도 잘못된 giaddr 때문에 Scope를 찾지 못하면 Offer는 만들어지지 않습니다.

Option 82의 Circuit ID와 Remote ID는 액세스 포트나 중계 장비를 식별해 정책에 사용할 수 있지만, 신뢰하지 않은 포트에서 임의로 삽입된 값을 그대로 받아서는 안 됩니다. 스위치의 DHCP Snooping과 Relay 정책이 어느 장비에서 Option을 추가·보존·제거하는지 문서화해야 합니다. Relay 이중화 환경에서는 두 Gateway가 동시에 중계할 수도 있으므로 서버가 중복 요청을 어떻게 처리하고 응답 경로가 어느 Relay로 돌아오는지도 캡처로 확인합니다.

Relay가 있다고 DHCP 서버가 로컬 Broadcast 도메인에 있는 것처럼 바뀌는 것은 아닙니다. 클라이언트 VLAN, Relay 인터페이스, 서버 Route와 Return Path가 모두 맞아야 합니다. 잘못된 giaddr, 누락된 Helper, Option 82 정책 거부 또는 서버에서 Relay 네트워크로 돌아가는 Route 부족을 각각 다른 지점의 캡처로 구분합니다.

이 절의 근거 IETF RFC 2131 · IETF RFC 3046

도해에서 확인할 내용 DHCP Relay가 giaddr와 Option 82의 Circuit ID·Remote ID를 넣어 다른 Subnet의 서버로 전달하는 L3 경로를 따라갑니다. 번호가 붙은 중계 단계의 giaddr 10.10.1.1, Circuit ID Port 5, Remote ID Switch-01 MAC을 서버의 주소 풀 선택·정책 적용 설명과 대조합니다.

주소를 못 받았다면 Discover부터 ACK까지 어느 메시지에서 끊겼는지 찾는다↑

상황: VLAN 30의 클라이언트만 169.254.0.0/16 주소를 사용하고 다른 VLAN은 정상입니다.

1. 클라이언트에서 DHCPDISCOVER가 나가는지 캡처합니다.
2. VLAN 30의 게이트웨이에 Relay 대상과 출발 인터페이스가 맞는지 확인합니다.
3. 서버 로그에서 요청이 도착했고 올바른 Scope를 선택했는지 봅니다.
4. Offer가 돌아오면 스위치 보안 기능과 UDP 67·68 경로에서 차단되는지 확인합니다.
5. 수정 뒤 DORA 전체와 받은 Mask·Gateway·DNS Option을 함께 검증합니다.

Discover가 반복될 때는 어디에서 캡처했는지부터 확인합니다. 단말에서 송신한 패킷만 보았다면 요청을 만들었다는 것까지만 알 수 있습니다. 요청이 실제 Access VLAN을 지났는지, Relay에 도착했는지, 서버가 받았는지를 각 지점에서 확인해야 합니다. Offer가 돌아왔다면 응답이 단말까지 전달되는 경로도 이어서 살펴봅니다.

양쪽 캡처와 Log의 Transaction ID, 클라이언트 Identifier, giaddr, Offered IP를 한 줄에 기록하면 여러 클라이언트의 Broadcast가 섞여도 하나의 교환을 연결할 수 있습니다. 수정 뒤에는 단순히 IP가 생겼는지만 보지 말고 Lease Time, Mask, Gateway, DNS와 Route가 모두 설계값인지 확인합니다. Renewal 시점까지 시험해야 초기 DORA는 성공하지만 갱신이 실패해 몇 시간 뒤 끊기는 문제도 발견할 수 있습니다.

메시지 이름만 나열하면 실패 위치를 찾을 수 없습니다. 클라이언트, Relay, 서버 세 지점에서 동일한 Transaction이 어디까지 보였는지 연결해야 Broadcast 전달, Pool 정책, Return Path와 클라이언트 적용 문제를 분리할 수 있습니다.

이 절의 근거 IETF RFC 2131 · IETF RFC 3046 · IETF RFC 5227

FAQ↑