필터링을 하여도 많은 패킷이 있다면 보기가 힘들것입니다. DHCP 패킷은 해당 패킷의 xid 가 일치하는 것이 같은 패킷이라고 보면 됩니다.
아래의 화면은 xid 즉 Transaction ID를 나타내는 그림
패킷을 분석하여 얻을 수 있는 여러가지가 있습니다. 그 중 클라이언트가 IP를 요청하였더니 그전에 고정 IP로 지정한 IP를 DHCP 서버에서 받게 되는 현상이 나오는 것입니다. 그렇다면 왜 그런 현상이 나올까요
DHCP는 랜덤하게 IP를 부여하는 것이 아니었던가요.
또한 브로드캐스트를 기반으로 하는 DHCP 서비스가 여러 개의 Scope를 가지고 있다면 어떻게 해당 Scope에 대한 IP를 클라이언트에게 부여 할 수 있을까요?
이러한 의문이 생길 수 있습니다. 아래 패킷을 통해 그러한 문제를 살펴 볼까 합니다. IP를 요청하는 그림
위의 그림을 보면 클라이언트는 브로드캐스트를 통해 Discover를 보내고 있습니다. 그런데 Requested Address 라고 기존에 사용하던 IP를 요청하는 모습을 볼 수 있죠.
즉 클라이언트가 전체 브로드캐스트를 하고 있지만 서버에 요청할 때는 기존에 사용하던 IP에 대한 요청과 해당 서브넷 정보가 표현되어 있는 것을 알 수 있습니다.
DHCP 서비스는 왜 브로드캐스트만을 통해서 패킷을 전달하나요 유니캐스트를 통해서 패킷을 부여 할 수 는 없는 것인가요?
DHCP 서비스 또한 유니캐스트와 브로드캐스트 둘 다 이용하고 있습니다. 우리가 알고 있는 네트워크는 IP나 컴퓨터이름을 알고 있으면 유니캐스트를 할 수 있다고 생각하는데 문제가 있습니다.
바로 문제는 MAC 주소 이기 때문이죠. IP를 알고 있다 하더라도 상대방의 MAC 주소를 알지 못하면 우리는 ARP_RARP 패킷을 보내어 상대방의 MAC 주소를 알아낼려고 합니다.
아래의 화면은 ARP 패킷을 모니터링 한 그림
즉 IP를 부여 받지 못한 경우에는 ARP Cache를 할 수 없으므로 결국은 브로드캐스트를 통한 요청 받게 할 수 없는 것이죠 그러나 IP를 부여 받은 클라이언트는 서버에게 일정시간 (50%) IP를 재 요청하게 됩니다. 즉 1시간의 IP를 부여 받았다면 30분 후에 IP를 부여한 서버에게 IP 갱신을 요청함으로써 원래의 IP를 계속 사용 할 수 있게 되는 것이죠.
이때 클라이언트는 DHCP 서버에게 IP Request 패킷을 보내게 되는데 이때에는 유니캐스트를 통해서 IP를 요청하게 됩니다.
멋진데요.
