Протоколы Internet

         

Протокол загрузки BOOTP


4.4.10 Протокол загрузки BOOTP

Семенов Ю.А. (ГНЦ ИТЭФ)

В больших сетях некоторые рабочие станции (например, Х-терминалы) могут не иметь системного диска, а операционная система и сетевое программное обеспечение загружается через сеть. Для этого рабочая станция должна иметь стартовую программу, записанную в ПЗУ. Такое постоянное запоминающее устройство часто производится на фирме, изготовившей эту рабочую станцию, и по этой причине не содержат информации ни об адресе сервера, ни даже о своем IP-адресе. Выше был описан протокол RARP, который способен решать подобные задачи для случая, когда сервер находится в пределах данной локальной сети. Ведь RARP выдает широковещательный запрос на связном уровне, а он не ретранслируется маршрутизаторами. Более мощным средством для загрузки бездисковых станций является протокол BOOTP (Bootstrap протокол, RFC-951, -1048, -1532). BOOTP пригоден и для загрузки бездисковых маршрутизаторов. BOOTP в качестве транспортного использует UDP-протокол. ЭВМ-клиент (порт=68), которая хочет воспользоваться BOOTP, посылает широковещательное сообщение (по адресу = 255.255.255.255). Сервер (порт=67) в отличии от случая RARP не обязательно должен находиться в пределах данной локальной сети. В поле IP-адрес клиента будет записано 0.0.0.0, так как клиент пока не знает своего адреса. Получив запрос через порт 67, маршрутизатор помещает свой IP-адрес в поле IP-адрес маршрутизатора (см. формат запроса на рис. 4.4.10.1) и пересылает запрос действительному BOOTP-серверу, увеличив на 1 значение поля Hop#. По пути к серверу может быть несколько маршрутизаторов (но обычно не больше 3). Сервер не знает физического адреса клиента. Воспользоваться ARP-запросом он не может, так как клиент пока не знает своего IP-адреса и на ARP-запрос не откликнется. У сервера, получившего запрос, имеется две возможности.

1. Проанализировать пакет, извлечь из него физический адрес клиента и скорректировать ARP-таблицу.

2. Послать отклик, используя широковещательный адрес.

Так как программа загрузки находится на прикладном уровне, и ей запрещено исправлять ARP-таблицы, реально доступен только второй путь. Использование разных номеров портов для сервера и клиента делает работу системы более эффективной. Когда отклик сервера является широковещательным, это позволяет не прерывать работу прикладных программ, работающих с номерами портов, отличными от 68 (порт Bootp-клиента). В Bootp ответственность за надежность связи лежит на ЭВМ-клиенте. При отсутствии отклика в отведенное время клиент повторяет Bootp-запрос. На IP-уровне, где данные не имеют контрольной суммы, целостность сообщения не гарантирована. Bootp требует, чтобы проверка контрольной суммы обязательно проводилась на UDP-уровне (следует заметить, что обычно это не является обязательным). Сервер читает UDP-дейтограммы через порт 67. Для повышения надежности обменов, как правило, блокируется фрагментация дейтограмм.


Загрузка рабочих станций часто запускается броском напряжения сетевого питания. При этом несколько Bootp-процессов стартуют одновременно. Для того чтобы снизить вероятность столкновений, величина времени тайм-аута выбирается случайно в интервале 0-4сек. После каждого повторного запроса это время удваивается. Верхнее значение тайм-аута равно 60сек. Для справок время загрузки бездискового x-терминала при благоприятных условиях может составлять около 20 сек.

bootp осуществляет загрузку в два этапа. На первом этапе bootp лишь снабжает клиента информацией, где лежит нужные ему данные. Далее ЭВМ-клиент использует протокол RFTP для получения искомого загружаемого файла. Bootp-сервер не обязательно должен работать на той же машине, где хранятся загружаемые файлы, но он должен знать их имена. Формат Bootp-сообщений представлен на рис. 4.4.10.1.



Рис. 4.4.10.1. Формат сообщений BOOTP

Поле операция=1 говорит о том, что данное сообщение запрос, а значение операция=2 указывает на то, что сообщение является откликом. Поля H-тип и Hlen определяют тип используемого оборудования и длину аппаратного адреса (для Ethernet H-тип=1, а HLen=6). ЭВМ-клиент кладет в поле Hop# (число шагов) нуль. Если BOOTP-сервер, получив запрос, решит передать его другой ЭВМ, он увеличит значение этого поля на 1, и так далее. Поле идентификатор операции

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

ЭВМ-клиент заполняет все последующие поля, если она этой информацией владеет, в противном случае поля обнуляются. Возможность указания имени BOOT(загрузочного)-файла позволяет учесть индивидуальность конфигурации конкретной ЭВМ и пожелания относительно загружаемой операционной системы. Поле специфическая информация поставщика содержит информацию, которая передается от сервера к ЭВМ-клиенту. Первые 4 октета этого поля носят название "волшебное печенье" (magic cookie) и определяют формат остальных субполей. Если в указанном поле имеется информация, субполе волшебное печенье имеет значение 99.130.83.99. Вслед за этим субполем следует последовательность субполей, содержащих один октет тип, опционный октет длина и многооктетное субполе значение. Стандарт предусматривает следующие разновидности субполей:



Таблица 4.4.10.1 Разновидности субполей и их коды (BOOTP)



Тип субполя Код субполя Длина субполя в октетах Содержимое субполя Заполнитель 0 - Нули - используются для заполнения неиспользуемых полей Маска субсети 1 4 Маска субсети в локальной сети Время дня 2 4 Время дня по универсальной шкале Маршрутизаторы 3 N Список IP-адресов N/4 маршрутизаторов Временные серверы 4 N IP-адреса N/4 временных серверов IEN116 сервер 5 N IP-адреса N/4 IEN116 серверов Домейн-сервер 6 N IP-адреса N/4 DNS-серверов Log-сервер 7 N IP-адреса N/4 log-серверов Сервер квот 8 N IP-адреса N/4 серверов квот Сервер принтера 9 N IP-адреса N/4 серверов печати Impress 10 N IP-адреса N/4 impress-серверов RLP-сервер 11 N IP-адреса N/4 RLP серверов Имя ЭВМ 12 N N байтов имени ЭВМ-клиента Размер Boot-файла 13 2 2-октетный размер boot-файла Зарезервировано 128-254 - Зарезервировано для местного применения Конец 255 - Конец списка Определены и другие субполя (RFC-1533), субполе конец (255) помечает конец поля. Хотя маска субсети может быть получена с помощью ICMP-запроса, стандарт требует, чтобы маска присылалась BOOT-сервером в ответ на каждый запрос, что исключает лишние ICMP-сообщения. Маска субсети может быть записана в поле специфическая информация поставщика, как это видно из таблицы. Время дня (тип=2) отсчитывается в секундах от 1-го января 1900 года. В новом протоколе DHCP (Dynamic Host Configuration Protocol, RFC-1531, протокол динамического конфигурирования системы) размер поля специфическая информация поставщика расширен до 312 байт.


Содержание раздела