Примеры сетевых топологий
Протокол загрузки BOOTP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
В больших сетях некоторые рабочие станции (например, Х-терминалы) могут не иметь системного диска, а операционная система и сетевое программное обеспечение загружается через сеть. Для этого рабочая станция должна иметь стартовую программу, записанную в ПЗУ. Такое постоянное запоминающее устройство часто производится на фирме, изготовившей эту рабочую станцию, и по этой причине не содержат информации ни об адресе сервера, ни даже о своем 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 лишь снабжает клиента информацией, где лежит нужные ему данные. Далее ЭВМ-клиент использует протокол TFTP для получения искомого загружаемого файла. 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 байт.
