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

Содержание
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. Удвоение продолжительности случайного интервала предотвращает перегрузку сети многочисленными широковещательными запросами со стороны многих клиентов ВООТР.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать полную версию