айм-аут по ТЗ в ТО + ТЗВ RFC 2131 рекомендуется увеличивать Т1 и Т2 на величину случайной задержки, чтобы предотвратить одновременное наступление тайм-аута на нескольких клиентах DHCP.При истечении интервала Т1 клиент DHCP переходит из состояния ПРИВЯЗКА в состояние ВОЗОБНОВЛЕНИЕ. В этом состоянии клиент DHCP должен согласовать с сервером DHCP, выдавшим исходный IP-адрес, новый срок аренды для назначенного IP-адреса. Если исходный сервер DHCP отказывается возобновить аренду, он посылает сообщение DHCPNAK; клиент возвращается в состояние ИНИЦИАЛИЗАЦИЯ и пытается получить новый IP-адрес. Если исходный сервер DHCP отправляет сообщение DHCPACK, в этом сообщении указывается новая продолжительность аренды. Клиент DHCP снова устанавливает интервалы Tl, T2 и ТЗ и переходит в состояние ПРИВЯЗКА.Если интервал Т2 истекает в тот момент, когда клиент DHCP в состоянии ВОЗОБНОВЛЕНИЕ ожидает сообщения DHCPACK или DHCPNAK от исходного сервера DHCP, клиент переходит из состояния ВОЗОБНОВЛЕНИЕ в состояние ПОВТОРНОЕ СВЯЗЫВАНИЕ. Исходный сервер DHCP может не ответить из-за того, что он временно недоступен или из-за сбоя в сетевом канале. Из приведенных выше формул видно, что Т2 > Т1, поэтому клиент DHCP дополнительно ждет возобновления аренды в течение времени Т2-Т1.При истечении интервала Т2 в сети рассылается широковещательный запрос DHCPREQUEST для всех серверов DHCP, способных возобновить аренду; клиент DHCP находится в состояние ПОВТОРНОЕ СВЯЗЫВАНИЕ. Рассылка запроса объясняется тем, что после ожидания Т2-Т1 секунд в состоянии ВОЗОБНОВЛЕНИЕ клиент DHCP приходит к выходу, что исходный сервер DHCP недоступен, и пытается связаться с любым сервером DHCP, способным ему ответить. Если сервер DHCP отвечает сообщением DHCPACK, клиент DHCP возобновляет аренду (ТЗ), задает интервалы Т1 и Т2 и переходит в состояние ПРИВЯЗКА. Если ни один сервер DHCP не сможет возобновить аренду до истечения интервала ТЗ, аренда становится недействительной и клиент DHCP переходит в состояние ИНИЦИАЛИЗАЦИЯ. Обратите внимание: к этому моменту клиент DHCP уже дважды пытался возобновить аренду - сначала с исходного сервера DHCP, а затем с любого сервера DHCP в сети.При истечении срока аренды (ТЗ) клиент DHCP должен прекратить использование IP-адреса и все сетевые операции с этим IP-адресом.Чтобы прекратить использование IP-адреса, клиент DHCP не обязан дожидаться истечения срока аренды (ТЗ). Он может намеренно отказаться от использования IP-адреса, отменив аренду. Предположим, пользователь с портативным компьютером подключился к сети для выполнения некоторой операции. Сервер DHCP в сети предоставил ему IP-адрес сроком на один час. Пользователь закончил свою работу за 30 минут и теперь хочет отключиться от сети. В процессе корректного отключения компьютера клиент DHCP посылает серверу сообщение DHCPRELEASE, чтобы сервер отменил аренду досрочно. Возвращенный IP-адрес в дальнейшем может использоваться другим клиентом.Если клиент DHCP работает на компьютере, оснащенном жестким диском, то IP-адрес может храниться на этом диске и при запуске компьютера клиент может запросить использовавшийся ранее адрес. На рис.8.6 этой ситуации соответствует состояние "ПЕРЕЗАГРУЗКА с известным IP-адресом". 2.3 Формат сообщения DHCPСтруктура сообщения DHCP изображена на рис.7 "Формат пакета DHCP". В сообщениях DHCP все поля имеют фиксированный формат, кроме поля дополнительных данных, минимальный размер которого равен 312 октетам. Видно, что сообщения DHCP и ВООТР имеют почти одинаковый формат, не считая полей флагов и дополнительных параметров. Более того, сервер DHCP может быть настроен на обработку запросов ВООТР (процедура настройки зависит от операционной системы).Отдельные поля сообщений протокола DHCP описаны в табл.3 "Поля сообщений DHCP". В поле флагов используется только крайний левый бит (рис.8 "Формат пакета DHCP"), остальные биты должны быть равны нулю.|
Поле | Длина в октетах | Описание | | ор | 1 | Тип сообщения: 1 - запрос (BOOTREQUEST), 2 - ответ (BOOTREPLY) | | htype | 1 | Тип аппаратного адреса. Значения совпадают со значениями аналогичного поля в пакетах ARP. Например, код 1 соответствует сети Ethernet 10 Мбит/с | | hlen | 1 | Длина аппаратного адреса в октетах. Аппаратные адреса Ethernet и Token Ring имеют длину 6 байт | | hops | 1 | Поле обнуляется клиентом DHCP. Может использоваться агентом-ретранслятором, работающим на маршрутизаторе, при пересылке сообщений DHCP | | xid | 1 | Код транзакции - случайное число, задаваемое клиентом DHCP при построении сообщения. Сервер DHCP использует код транзакции в своих ответах клиенту. Наличие кода xid позволяет клиентам и серверам DHCP связать сообщение DHCP с ответом | | seсs | 1 | Заполняется клиентом DHCP. Содержит количество секунд, прошедших с начала загрузки клиента | | flags | 2 | Если крайний левый бит равен 1, сообщение является широковещательным. Все остальные биты должны быть равны 0 | | ciaddr | 4 | IP-адрес клиента DHCP. Заполняется клиентом в сообщении DHCPREQUEST, предназначенном для проверки использования ранее назначенных параметров конфигурации. Если клиент не знает свой IP-адрес, полю присваивается 0 | | yiaddr | 4 | IP-адрес клиента DHCP, возвращаемый сервером DHCP | | siaddr | 4 | IP-адрес сервера. Значение присваивается клиентом DHCP, если клиент хочет связаться с конкретным сервером DHCP. IP-адрес сервера DHCP может быть получен при помощи сообщений DHCPOFER и DHCPACK, ранее возвращенных сервером. Сервер может вернуть адрес следующего сервера, с которым следует связаться в процессе загрузки, - например, адрес сервера, на котором хранится загрузочный образ операционной системы | | giaddr | 4 | IP-адрес маршрутизатора, на котором работает агент-рретранслятор DHCP | | chaddr | 16 | Аппаратный адрес клиента DHCP.16 октетов зарезервированы для того, чтобы данное поле позволяло представлять различные типы аппаратных адресов. В архитектурах Ethernet и Token Ring используются только 6 октетов | | sname | 64 | Необязательное имя сервера (если оно известно клиенту DHCP). Хранится в формате строки, завершенной нуль-символом | | file | 128 | Имя загрузочного образа. Хранится в формате строки, завершенной нуль-символом. Если клиент DHCP хочет загрузить образ операционной системы, принятый с сетевого устройства, он может задать в DHCPDISCOVER обобщенное имя - например, "unix" для загрузки образа Unix. На сервере DHCP может храниться дополнительная информация о конкретной операционной системе, необходимой для этой рабочей станции. Ответ сервера DHCP может возвращаться в виде полностью определенного имени файла в сообщении DHCPOFFER | | options | 312 | Дополнительные параметры | | |
Большинство сообщений DHCP, передаваемых сервером DHCP клиенту, являются направленными (то есть посылаются на один конкретный IP-адрес). Это объясняется тем, что сервер DHCP узнает адрес клиента DHCP из сообщений, отправляемых клиентом серверу. Клиент DHCP может потребовать, чтобы сервер отвечал по адресу широковещательной рассылки, для чего крайний левый бит поля options устанавливается в 1. Клиент DHCP поступает подобным образом, если он еще не знает своего IP-адреса. Модуль IP на клиенте DHCP отвергает полученную дейтаграмму, если IP-адрес получателя, указанный в дейтаграмме, не совпадает с IP-адресом сетевого интерфейса клиента DHCP. Если IP-адрес сетевого интерфейса неизвестен, дейтаграмма также отвергается. С другой стороны, модуль IP принимает любые широковещательные дейтаграммы DHCP. Следовательно, чтобы модуль IP заведомо принимал ответ сервера DHCP, когда IP-адрес еще не настроен, клиент DHCP должен потребовать, чтобы сервер отправлял широковещательные сообщения вместо направленных. Поле options имеет переменную длину. Его минимальный размер увеличен до 312 октетов, чтобы общий минимальный размер сообщения DHCP составлял 576 октетов - минимальный размер дейтаграммы IP, принимаемой хостом. Если клиент DHCP должен использовать сообщения большего размера, он согласовывает максимальный размер при помощи специального параметра. Поскольку поля sname и file довольно велики, но используются не всегда, область параметров можно расширить в эти поля при помощи параметра Option Overload. Если этот параметр присутствует, обычный смысл полей sname и field игнорируется и в этих полях ищутся параметры в формате TLV (Type, Length, Value). Из рис.9 "Формат параметра в сообщениях DHCP" видно, что в DHCP параметр представляется полем типа A октет), за которым следует поле длины A октет). Значение поля длины определяет размер поля значения. Различные сообщения DHCP представляются специальным кодом типа 53. Значения параметров, определяющих сообщения DHCP, приведены на рис.10 "Значения параметров в сообщениях DHCP". 2.4 Трассировка протокола DHCPВ этом разделе описан формат сообщений DHCP для пакетов, используемых в реально существующей сети. Помимо указанных в табл.3, вам могут встретятся обозначения:Destination IP Address - IP-адрес получателя Source IP Address - IP-адрес отправителя Ethernet Header - заголовок EthernetUDP Header - заголовок UDPUDP Source Port - UDP-порт отправителя UDP Destination Port - UDP-порт получателя Ethernet type - тип EthernetРис.10 "Значения параметров в сообщениях DHCP" Протокол DHCP и формат его пакетов являются расширениями ВООТР. Клиенты и серверы DHCP используют те же номера портов, что и клиенты и серверы ВООТР, то есть клиенты DHCP использует порт UDP с номером 68, а серверы DHCP - порт UDP с номером 67. Большинство анализаторов протоколов расшифровывает сообщения DHCP и BOOT в одном формате.Заключение Протоколы ВООТР и DHCP решают важную проблему автоматической настройки параметров IP (в частности, IP-адресов и масок подсети) для отдельных сетевых устройств. Оба протокола основаны на архитектуре "клиент-сервер" и используют одинаковые номера портов UDP. Протокол DHCP проектировался в качестве замены старого протокола ВООТР, а его сообщения представляют собой расширение формата сообщений ВООТР.Главное преимущество DHCP заключается в том, что этот протокол позволяет арендовать IP-адреса на временной основе. Тем самым обеспечивается более гибкое управление IP-адресами в ситуациях, когда IP-адреса не обязаны жестко ассоциироваться с конкретным компьютером по аппаратному адресу. Механизм назначения IP-адресов в ВООТР менее гибок, поскольку IP-адрес связывается с аппаратным адресом сетевого интерфейса. Литература 1. G. Stump, R. Droms, Y. Gu, R., Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. The User Class Option for DHCP, RFC-3004, November 2000. 2. M. Patrick, DHCP Relay Agent Information Option. RFC-3046, January 2001. 3. S. Alexander, DHCP Options and BOOTP Vendor Extensions, RFC-2132 4. T. Parker, TCP/IP для профессионалов, May 2000.© 2007 http://www.script-coding. info 5. http://www.dhcp-handbook.com/dhcp_faq.html 6. http://ru. wikipedia.org/wiki/DHCP 7. http://kunegin. narod.ru/nata/tcpip_prof. pdf 8. http://www.bog. pp.ru/work/bootp.html
Страницы: 1, 2, 3
|
