Реферат: Автоматизированная настройка TCP/IP, BOOTP. Динамическая настройка (DHCP)

Министерство образования Российской Федерации ТольяттинскийГосударственный Университет Кафедра «Информатика и ВТ»

Индивидуальное домашнее задание «Автоматизированная настройкаTCP/IP. BOOTP.Динамическая настройка (DHCP)»

Выполнила:

Проверил:

г. о. Тольятти 2009


Содержание

1. Автоматизированная настройка TCP/IP

1.1 Динамическая настройка конфигурации с применением BOOTP

1.2 IP-адреса запросов/ответов ВООТР

1.3 Потеря сообщений ВООТР

1.4 Формат сообщения ВООТР

1.5 Фазы ВООТР

1.6 Дополнительные данные

2. Динамическая настройка (DHCP)

2.1 Распределение IP-адресов в DHCP

2.2 Назначение IP-адресов в DHCP

2.3 Формат сообщения DHCP

2.4 Трассировка протокола DHCP

Литература


1. Автоматизированная настройка TCP/IP

Настройка параметров TCP/IP длякаждой станции в большой сети обычно сопряжена с тяжелой и долгой работой,особенно когда возникает необходимость в изменении таких параметров TCP/IP, какIP-адреса и маски подсетей. Изменения могут быть обусловлены кардинальнойреструктуризацией сети или наличием в ней многочисленных мобильныхпользователей с портативными компьютерами, которые могут подключаться к любомусегменту сети. Возможны как физические, так и беспроводные подключения. Посколькупараметры конфигурации TCP/IP компьютера зависят от того, к какому сегменту онподключен, переход компьютера в другой сегмент сети должен сопровождатьсясоответствующим изменением параметров.

Только компетентный сетевойадминистратор хорошо понимает все последствия, к которым приводит изменениепараметров TCP/IP. Группа IETF разработала для объединенных сетей TCP/IPнесколько протоколов автоматической настройки, в том числе ВООТР (Boot Protocol)и DHCP (Dynamic Host Configuration Protocol).

1.1 Динамическая настройка конфигурации сприменением BOOTP

Протокол ВООТР проектировалсядля того, чтобы протоколы IP (Internet Protocol) и UDP (User Datagram Protocol)могли использоваться для передачи информации компьютерам, желающими настроитьсвою конфигурацию. Компьютер, сгенерировавший запрос, называется клиентомВООТР, а компьютер, ответивший на запрос клиента, называется сервером ВООТР(рис.1 «Клиенты и серверы ВООТР»).

Целью клиентского запроса ВООТРявляется получение значений параметров IP для компьютера, на котором работаетклиент ВООТР.

Протокол ВООТР описан в RFC 951.Обновленная информация содержится в RFC 2132, RFC 1532, RFC 1542 и RFC 1395.

/>

1.2 IP-адреса запросов/ответов ВООТР

Сообщения ВООТР инкапсулируютсяв заголовках UDP, идентифицирующих номер порта, используемого процессами ВООТР.Дейтаграмма UDP

инкапсулируется в заголовке IP. Нокакие адреса отправителя и получателя используются в заголовке IP? Интересныйвопрос, потому что при выдаче запроса клиент ВООТР должен указать эти адреса. Какправило, клиент ВООТР не знает своего IP-адреса и указывает вместо него 0.0.0.0.Если же адрес известен, он используется в клиентском запросе ВООТР.

Известен ли IP-адрес сервераклиенту ВООТР? В общем случае неизвестен.

Это особенно верно по отношениюк ситуациям, когда клиент ВООТР представляет собой бездисковую рабочую станциюи не располагает средствами для определения адреса сервера. Впрочем, если адрессервера ВООТР может настраиваться на уровне рабочей станции, он используетсяклиентом ВООР. Если клиент ВООТР не знает IP-адрес сервера ВООТР, он используетограниченную рассылку IP. В качестве адреса ограниченной рассылки используетсяследующее значение: 255.255.255.255

Пакеты, отправленные поадресу ограниченной (локальной) рассылки, принимаются всеми IP-узламилокального сегмента сети, включая серверы ВООТР.

А если сервер ВООТР находится вдругой подсети IP, за граничным маршрутизатором? Как говорилось выше,ограниченная рассылка за маршрутизатор не распространяется. Для таких случаевна маршрутизаторе работает агент-ретранслятор ВООТР (ВООТР relay agent),который проверяет, используется ли в дейтаграмме ограниченной рассылки приемныйпорт UDP с номером 67 (порт зарезервирован для BOOTP/DHCP). Если условиевыполняется, ограниченная рассылка перенаправляется в сетевые интерфейсымаршрутизатора (рис.2 «Пересылка сообщений ВООТР через граничныймаршрутизатор»).


/>

Сервер ВООТР, находящийся влокальной сети, может ответить на запрос клиента ВООТР. Будет ли в этомсообщении использоваться IP-адрес клиента?

Иначе говоря, может ли серверВООТР послать направленный ответ? Все зависит от реализации сервера ВООТР.

Сервер знает IP-адрес клиента,хранящийся в базе данных конфигурации ВООТР. Почему же он не может использоватьэтот адрес для посылки направленного ответа клиенту? Дело в том, что в моментотправки сервером запроса ARP на получение аппаратного адреса клиента ВООТРклиент ответить не может. Почему? Потому что он еще не знает своего IP-адреса. СерверВООТР получает аппаратный адрес клиента из заголовка канального уровня всообщении клиента ВООТР. Реализация сервера ВООТР может добавить запись синформацией о клиенте ВООТР в кэш ARP (рис.3 «Изменение кэша ARP серверомВООТР»). При наличии такой записи сервер ВООТР может использоватьнаправленный ответ.

Модификация кэша ARPиспользуется в реализации ВООТР для BSD Unix.

 

/>

Если сервер ВООТР не изменяетсодержимое кэша ARP, ответ рассылается в широковещательном режиме.

1.3 Потеря сообщений ВООТР

В своей работе ВООТР используетпротоколы UDP и IP, не гарантирующие доставки сообщений. В результате возможнапотеря, задержка, дублирование или нарушение последовательности сообщений ВООТР.Поскольку контрольная сумма IP обеспечивает проверку целостности толькозаголовка, но не поля данных, реализация ВООТР может потребовать активизацииконтрольной суммы UDP, защищающей от ошибок во всем сообщении ВООТР.

При отправке запросов клиентВООТР устанавливает флаг запрета фрагментации (DF), чтобы упростить обработкуответов ВООТР, а также на случай нехватки памяти для сбора фрагментированныхдейтаграмм.

Для борьбы с потерей сообщений вВООТР используется механизм тайм-аута с повторной передачей. Отправляя запрос,клиент ВООТР запускает таймер.

Если ответ ВООТР будет получендо истечения интервала тайм-аута, отсчет прекращается; в противном случае ВООТРпередает запрос заново.

Одновременный запуск несколькихклиентов ВООТР может привести к переполнению сети широковещательными запросамиВООТР. Чтобы этого не произошло, в спецификации ВООТР рекомендуетсяиспользовать случайную задержку, начальная продолжительность которой составляетот нуля до четырех секунд. При каждой последующей повторной отправке интервалудваивается до тех пор, пока он не достигнет достаточно большой величины (например,60 секунд). При достижении верхней границы продолжительность интервалаперестает удваиваться, но случайная задержка в итоговом интервале продолжаетприменяться. Внесение случайной задержки помогает предотвратить одновременноепоступление запросов со стороны клиентов ВООТР, повышающих нагрузку на сервер ипорождающих конфликты пакетов в Ethernet. Удвоение продолжительности случайногоинтервала предотвращает перегрузку сети многочисленными широковещательнымизапросами со стороны многих клиентов ВООТР.

1.4 Формат сообщения ВООТР

На рис.4 «Формат сообщенияBOOT» изображена структура сообщения ВООТР. Отдельные поля сообщенияописаны в табл.1 «Поля сообщений ВООТР».


/>

Поле Длина в октетах Описание ор 1 Тип сообщения: 1 — запрос (BOOTREQUEST), 2 — ответ (BOOTREPLY) htype 1 Тип аппаратного адреса. Значения совпадают со значениями аналогичного поля в пакетах ARP. Например, код 1 соответствует сети Ethernet 10 Мбит/с hlen 1 Длина аппаратного адреса в октетах. Аппаратные адреса Ethernet и Token Ring имеют длину 6 байт hops 1 Поле обнуляется клиентом ВООТР. Может использоваться агентом-ретранслятором, работающим на маршрутизаторе, при пересылке сообщений ВООТР xid 1 Код транзакции — случайное число, задаваемое клиентом ВООТР при построении сообщения. Сервер ВООТР использует код транзакции в своих ответах клиенту. Наличие кода xid позволяет клиентам и серверам ВООТР связать сообщение ВООТР с ответом secs 1 Заполняется клиентом ВООТР. Содержит количество секунд, прошедших с начала загрузки клиента - 2 Не используется ciaddr 4 IP-адрес клиента ВООТР. Заполняется клиентом в сообщении BOOTREQUEST, предназначенном для проверки использования ранее назначенных параметров конфигурации. Если клиент не знает свой IP-адрес, полю присваивается 0 yiaddr 4 IP-адрес клиента ВООТР, возвращаемый сервером ВООТР siaddr 4 IP-адрес сервера. Значение присваивается клиентом ВООТР, если клиент хочет связаться с конкретным сервером ВООТР. IP-адрес сервера ВООТР может храниться в конфигурационной базе данных TCP/IP на клиенте ВООТР. Сервер может вернуть адрес следующего сервера, с которым следует связаться в процессе загрузки, — например, адрес сервера, на котором хранится загрузочный образ операционной системы giaddr 4 IP-адрес маршрутизатора, на котором работает агент-ретранслятор ВООТР chaddr 16 Аппаратный адрес клиента ВООТР.16 октетов зарезервированы для того, чтобы данное поле позволяло представлять различные типы аппаратных адресов. В архитектурах Ethernet и Token Ring используются только 6 октетов sname 64 Необязательное имя сервера (если оно известно клиенту ВООТР). Хранится в формате строки, завершенной нуль-символом file 128

Имя загрузочного образа. Хранится в формате строки, завершенной нуль-символом. Если клиент ВООТР хочет загрузить образ операционной системы, принятый с сетевого устройства, он может задать обобщенное имя — например, «unix» для загрузки образа Unix

На сервере ВООТР может храниться дополнительная информация о конкретной операционной системе, необходимой для этой рабочей станции. Ответ, полученный от сервера ВООТР, содержит полностью определенное имя файла

vendor 64 Дополнительные данные, смысл которых определяется поставщиком. Например, при запросе в этом поле может передаваться тип/серийный номер устройства, а при ответе — информация о поддержке некоторых возможностей или идентификатор удаленной файловой системы. Информация может быть зарезервирована для использования ядром или загрузчиком третьей фазы 1.5 Фазы ВООТР

Несмотря на свое название,протокол ВООТР не используется для фактической пересылки образа операционнойсистемы клиенту ВООТР. Пересылка образа осуществляется отдельным протоколом TFTP (Trivial File Transfer Protocol), который использует вкачестве транспорта протокол UDP. Бездисковые рабочиестанции загружают образ операционной системы с сервера; другие станции простоиспользуют ВООТР для централизованного назначения IP-адресов,без загрузки системы.

На рис.5 «Пример работыbootstrap» изображены фазы, из которых состоит процесс загрузки образаоперационной системы. На шаге 1 клиент ВООТР выдает запрос на получение данныхконфигурации IP. На шаге 2 сервер ВООТР возвращаетданные конфигурации IP и имя загружаемого файла собразом операционной системы. На шаге 3 клиент ВООТР посылает запрос назагрузку образа операционной системы клиенту TFTP. Нашаге 4 клиент TFTP посылает серверу TFTPзапрос на загрузку образа операционной системы. На шаге 5 сервер TFTP возвращает серию пакетов данных, содержащих образоперационной системы. После принятия образа ВООТР загружает его в память иинициализируется.

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

Возможна ситуация, в которойадминистратор настраивает рабочую станцию на загрузку разных операционныхсистем в зависимости от пользователя. В этом случае запрос ВООТР можетсодержать в поле имени файла обобщенное обозначение — например, «unix» для принятия образа операционной системы Unix, или «default» длязагрузки образа операционной системы по умолчанию.

Столкнувшись с таким обобщеннымзапросом, сервер ВООТР обращается к конфигурационной базе данных, находитполностью определенное имя файла и возвращает его в ответе ВООТР. Клиент ВООТРможет передать полностью определенное имя локальному клиенту TFTPдля принятия образа операционной системы.


/>

1.6 Дополнительные данные

В формате сообщения ВООТР явнозаданы стандартные параметры IP. Многие поставщики оборудования передают своимустройствам дополнительные параметры. Для таких случаев в сообщения ВООТР быловключено поле дополнительных данных.

В поле vendor сообщения ВООТРклиенту передаются данные, интерпретация которых определяется поставщикомоборудования. Поле не является обязательным, а его применение зависит от того,какая дополнительная информация нужна клиенту ВООТР. Первые четыре октетасодержат «волшебное число» — признак формата остальных полей. Этичетыре октета задаются в десятичной записи с точечным разделением (не путайтеих с IP-адресами!). Скажем, произвольно выбранная последовательность 99.130.83.99(в шестнадцатеричной записи — 63.82.53.63) является общепринятым обозначениемстандартного формата области дополнительных данных. За признаком форматаперечисляются элементы, каждый из которых характеризуется следующими атрибутами:

метка (1 октет)

длина следующего поля данных (1октет)

данные (переменная длина)

Метки элементов ВООТР описаны вRFC 1497, «ВООТР Vendor Information

Extensions». С появлениемпротокола DHCP дополнительные данные ВООТР и поле параметров DHCP былиприведены к общему формату, описанному в RFC 2132,«DHCP Options and BOOTP Vendor Extensions». Некоторые частоиспользуемые значения меток приведены в табл.2 «Стандартные меткидополнительных данных ВООТР».

Метка Длина данных Интерпретация - Используется только в целях выравнивания, чтобы следующие поля начинались с границы слова 1 4 Маска подсети 2 4 Смещение географической зоны, в которой находится подсеть клиента, от стандартного времени UTC (Coordinated Universal Time). Смещение выражается 32-разрядным целым числом со знаком 3 N

Список IP-адресов маршрутизаторов в подсети клиента.

Маршрутизаторы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4

4 N Маска подсети 5 N Список серверов имен (IEN 116), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 6 N Список серверов DNS (STD 13, EFC 1035), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 7 N Список журнальных серверов (MIT-LCS UDP), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 8 N

Список серверов cookie (RFC 865), доступных для клиента.

Серверы перечисляются в порядке предпочтительности.

Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4

9 N Список серверов построчной печати LPR (RFC 1179), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 10 N

Список серверов Imagen Impress, доступных для клиента.

Серверы перечисляются в порядке предпочтительности.

Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4

11 N Список серверов местонахождения ресурсов (RFC 887), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 12 N Имя хоста, соответствующее данному клиенту, с возможным уточнением имени локального домена. Допустимые символы описаны в RFC 1035. Минимальная длина поля данных равна 1 октету 13 N Размер загрузочного файла. Определяет длину загрузочного образа, используемого клиентом по умолчанию, в 512-килобайтных блоках. Длина файла задается 16-разрядным целым числом без знака 128-254 Не определена Интерпретация зависит от реализации 255 - Признак конца информации в поле дополнительных параметров. Дальнейшие октеты должны быть заполнены нулями
2. Динамическая настройка (DHCP)

Протокол DHCP (Dynamic HostConfiguration Protocol) является расширением протокола ВООТР и обладает болеегибкими возможностями управления IP-адресами. DHCP может использоваться длядинамической настройки основных параметров TCP/IP хостов (рабочих станций исерверов), работающих в сети.

Протокол DHCP состоит из двухкомпонентов:

механизм назначения IP-адресов идругих параметров TCP/IP

протокол согласования и передачиинформации о хостах Хост, запрашивающий данные о конфигурации TCP/IP,называется клиентом DHCP, а хост TCP/IP, предоставляющий эту информацию,называется сервером DHCP. Протокол DHCPописан в RFC 2131, «Dynamic Host Configuration Protocol».

2.1 Распределение IP-адресов в DHCP

В DHCP используются три способаназначения IP-адресов:

ручное назначение автоматическоеназначение динамическое назначение При ручном назначении IP-адрес клиента DHCPвводится вручную сетевым администратором на сервере DHCP, после чего передаетсяклиенту через протокол DHCP.

При автоматическом назначенииручная настройка адресов не нужна. Клиент DHCP получает IP-адрес при первомобращении к серверу DHCP. IP-адреса, назначенные этим способом, закрепляются заклиентом DHCP и не используются другими клиентами DHCP.

При динамическом назначенииклиент получает IP-адрес на временной основе или «арендует» его наопределенный срок. По истечении этого срока IP-адрес отзывается, и клиент DHCPдолжен перестать его использовать. Если клиент DHCP по-прежнему нуждается вIP-адресе для выполнения своих функций, он должен запросить другой адрес.

Из трех описанных методов толькодинамическое назначение позволяет организовать автоматическое повторноеиспользование IP-адресов. Если клиент DHCP перестает использовать IP-адрес (например,при корректном отключении компьютера), он возвращает его серверу DHCP. Послеэтого сервер DHCP может назначить тот же IP-адрес другому клиенту DHCP,обратившемуся с запросом на получение адреса.

Метод динамического назначенияадресов особенно удобен для клиентов DHCP, нуждающихся в IP-адресе длявременного подключения к сети. Для примера рассмотрим сеть класса С, к котороймогут подключаться до 300 мобильных пользователей с портативными компьютерами. Сетькласса С может содержать до 253 узлов B55 — 2 специальных адреса = 253). Посколькукомпьютеры, подключающиеся к сети через TCP/IP, должны обладать уникальнымиIP-адресами, все 300 компьютеров не могут подключиться к сети одновременно. Темне менее, если в любой момент времени в сети возможно не более 200 физических подключений,появляется возможность переназначения неиспользуемых адресов класса С за счетприменения механизма динамического назначения адресов DHCP.

Динамическое назначение адресовтакже хорошо подходит для назначения IP-адресов новым хостам с постояннымподключением в ситуациях, когда свободных адресов не хватает. По мереотключения из сети старых хостов их IP-адреса могут немедленно назначатьсяновым хостам.

Какой бы из трех способовназначения IP-адресов ни был избран, вы все равно сможете один раз настроитьпараметры IP на центральном сервере DHCP вместо того, чтобы повторять настройкуконфигурации TCP/IP для каждого компьютера по отдельности.


2.2 Назначение IP-адресов в DHCP

Обратившись с запросом к серверуDHCP, клиент DHCP проходит ряд внутренних стадий, во время которых онсогласовывает с сервером срок и область использования IP-адреса. Процессполучения IP-адреса клиентом DHCP лучше всего объяснить на диаграмме переходов(то есть конечного автомата). На Рис.6 «Диаграмма переходов для протоколаDHCP, поясняющая процесс взаимодействия между клиентом и сервером» изображенадиаграмма, поясняющая процесс взаимодействия между клиентом и сервером DHCP.

При первом запуске клиент DHCPнаходится в состоянии ИНИЦИАЛИЗАЦИЯ. На этой стадии клиент DHCP еще не знаетсвоих параметров IP, поэтому он рассылает запрос DHCPDISCOVER,инкапсулированный в пакете UDP/IP. В пакете указан приемный порт UDP 67 (десят)- такой же, как у сервера ВООТР, потому что протокол DHCP является расширениемВООТР. В пакете DHCPDISCOVER используется адрес локальной рассылки 255.255.255.255.Если серверы DHCP находятся за пределами локального сегмента, на маршрутизатореIP должен работать агент-ретранслятор, который перешлет запрос DHCPDISCOVER вдругие подсети. Поддержка агентов-ретрансляторов DHCP рассматривается в RFC1542.


/>

Прежде чем рассылать запросDHCPDISCOVER, клиент DHCP выдерживает паузу случайной продолжительности от 1 до10 секунд. Это делается для того, чтобы предотвратить одновременное началоработы клиентов DHCP при их одновременном включении (как иногда происходитпосле сбоя питания).

После рассылки запросаDHCPDISCOVER клиент DHCP входит в состояние ВЫБОР. В этом состоянии клиент DHCPполучает сообщения DHCPOFFER от серверов DHCP, настроенных для ответа этомуклиенту. Период времени, в течение которого клиент DHCP ожидает сообщенияDHCPOFFER, зависит от реализации. Если клиент получает сразу несколько ответовDHCPOFFER, он должен выбрать один из них. Выбрав сообщение DHCPOFFER от одногоиз серверов, клиент DHCP посылает этому серверу сообщение DHCPREQUEST. СерверDHCP отвечает сообщением DHCPACK.

Дополнительно клиент DHCP можетпроверить IP-адрес, переданный в сообщении DHCPACK, и убедиться в том, что этотадрес не используется. В сетях с широковещательной рассылкой клиент DHCP можетотправить по указанному адресу запрос ARP и проверить наличие ответа ARP. Получениеответа ARP означает, что предложенный IP-адрес уже используется; в этом случаеответ DHCPACK от сервера игнорируется, отправляется ответ DHCPDECLINE, а клиентDHCP переходит в исходное состояние ИНИЦИАЛИЗАЦИЯ и пытается получить свободныйIP-адрес. При рассылке запроса ARP в локальной сети клиент указывает в пакетеARP собственный аппаратный адрес в поле аппаратного адреса отправителя, но вполе IP-адреса отправителя заносится нулевое значение. Нулевой IP-адресиспользуется вместо предложенного IP-адреса, чтобы избежать возможной путаницыс кэшами ARP других хостов TCP/IP (в том случае, если предложенный IP-адрес ужеиспользуется).

Когда клиент получает от сервераDHCP сообщение DHCPACK, он определяет три временных интервала и переходит всостояние ПРИВЯЗКА. Первый интервал Т1 определяет срок возобновления аренды; второйинтервал Т2 определяет срок повторной привязки; третий интервал ТЗ определяетпродолжительность аренды.

С сообщением DHCPACK всегдавозвращается значение ТЗ, то есть продолжительность аренды. Значения Т1 и Т2настраиваются на сервере DHCP, а если они не были заданы, используются значенияпо умолчанию, основанные на продолжительности срока аренды, рассчитанные последующим формулам:

Т1 = интервал возобновления Т2 =интервал повторной привязки ТЗ = продолжительность аренды Т1 = 0,5 х ТЗ

Т2 = 0,875 х ТЗ

Моменты времени, в которыепроисходит тайм-аут, вычисляются прибавлением интервала ко времени отправкисообщения DHCPREQUEST, по которому было сгенерировано подтверждение DHCPACK.

Если запрос DHCP был отправлен вмомент ТО, то моменты тайм-аута по всем трем интервалам вычисляются последующим формулам:

тайм-аут по Т1 = ТО + Т1

тайм-аут по Т2 — ТО + Т2

тайм-аут по ТЗ в ТО + ТЗ

 

В 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»),остальные биты должны быть равны нулю.

/>

еще рефераты
Еще работы по информатике, программированию