Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов

Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.

Рис. .4. Временная диаграмма обмена сообщениями между DHCP-клиентов и сервером при повторном присвоении ранее использованного сетевого адреса

1. Клиент широковещательно рассылает по локальной субсети сообщение DHCPREQUEST. Сообщение включает в себя сетевой адрес клиента в опции 'requested IP-адрес'. Раз клиент не получил свой сетевой адрес, он не должен заполнять поле 'ciaddr'.

Агенты транспортировки BOOTP передают сообщение DHCP-серверам за пределами данной субсети. Если клиент использует 'client identifier' для получения своего адреса, клиент должен использовать тот же 'client identifier' в сообщении DHCPREQUEST.

2. Серверы, которые знают конфигурационные параметры клиента, откликаются сообщением DHCPACK. Серверы не должны проверять, используется ли уже сетевой адрес клиента; клиент может реагировать посылкой запроса эхо ICMP.

Если запрос клиента не корректен (например, клиент переместился в другую субсеть), серверы должны реагировать посылкой клиенту сообщения DHCPNAK. Серверы не должны откликаться, если их информация не абсолютно надежна. Например, сервер, который идентифицирует запрос для набора параметров, который принадлежит другому серверу, и имеет истекший срок действия, сервер не должен реагировать сообщением DHCPNAK, если только серверы не используют явно механизм поддержания когерентности.

Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент может не иметь правильного сетевого адреса или сетевой маски, и клиент может не отвечать на ARP-запрос. В противном случае, сервер должен послать сообщение DHCPNAK по IP-адресу транспортного агента BOOTP, записанного в 'giaddr'. Транспортный агент, в свою очередь, переадресует сообщение непосредственно по аппаратному адресу клиента, так что DHCPNAK будет доставлен, даже если клиент переместился в другую сеть.

3. Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент выполняет окончательную проверку параметров (как в разделе 3.1), и отмечает время действия конфигурации, специфицированное в сообщении DHCPACK. Значение времени действия неявно задается 'client identifier' или 'chaddr' и сетевым адресом. С этого момента клиент считается сконфигурированным.

Если клиент обнаруживает, что IP-адрес в сообщении DHCPACK уже использован, клиент должен послать сообщение DHCPDECLINE серверу и повторно запустить процесс конфигурации, послав запрос на новый сетевой адрес. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP, которая описана в разделе 4.4.

Если клиент получает сообщение DHCPNAK, он не может повторно использовать свой запомненный сетевой адрес. Он должен вместо этого запросить новый адрес путем повторного запуска конфигурационного процесса. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP.

Клиент выполняет таймаут и повторно посылает сообщение DHCPREQUEST. Если клиент не получает ни сообщения DHCPACK, ни DHCPNAK, клиент, согласно алгоритму из раздела 4.1, повторно посылает сообщение DHCPREQUEST. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго. Например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно передать сообщение DHCPREQUEST четыре раза при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент после повторной пересылки не получил ни сообщения DHCPACK, ни DHCPNAK, он может решить использовать присвоенный ранее сетевой адрес и конфигурационные параметры вплоть до истечения срока их действия. Это соответствует переходу в состояние BOUND на диаграмме состояний клиента.

4. Клиент может решить отказаться от сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью 'идентификатора клиента', или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE.

Когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE.

Поиск по сайту: