Автоматизированная настройка TCPIP BOOTP Динамическая настройка DHCP (стр. 2 из 4)
На рис.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 "Стандартные метки дополнительных данных ВООТР".
| Метка | Длина данных | Интерпретация |
| 0 | - | Используется только в целях выравнивания, чтобы следующие поля начинались с границы слова |
| 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 Host Configuration 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, обратившемуся с запросом на получение адреса.