Bootp что это принтер

Обновлено: 06.07.2024

Содержание

История

В связи с проблемами постоянного подключения и перемещения новых устройств и с необходимостью изменения сетевой конфигурации для соответствия современным требованиям к сетям, пришлось искать решение, устраняющее данные недостатки. Появилась необходимость создать механизм для автоматизации конфигурации сетевых узлов, распределенных операционных систем и сетевого программного обеспечения. Наиболее эффективным способом реализации такого механизма могло быть сохранение конфигурационных параметров и образов программного обеспечения на одном или нескольких серверах загрузки (boot server). Во время запуска система взаимодействует с таким сервером, получает от него начальные параметры конфигурации и при необходимости загружает с него нужное программное обеспечение. Так в сентябре 1985 года BOOTP был введен в RFC 951 [1] в качестве замены устаревшему RARP. Первоначально ВООТР разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ только базовые средства для IP, UDP и TFTP. Основной мотивацией для замены RARP с BOOTP являлось то, что RARP был протоколом канального уровня. Это затрудняло внедрение на многих серверных платформах, и требовалось, чтобы сервер присутствовал на каждой отдельной IP-подсети. BOOTP ввел новшество промежуточных агентов, которые пересылали BOOTP пакеты из локальной сети, используя стандартную маршрутизацию IP, так что один центральный сервер BOOTP мог обслуживать хост по многим подсетям.

Архитектура

Поля, которые должны быть заполнены в запросе загрузки, выделены полужирным шрифтом. Поля, которые могут быть указаны клиентом, набраны курсивом.

Доставка запроса от клиента на сервер

Промежуточная пересыпка запроса загрузки на удаленный сервер

Промежуточный маршрутизатор запроса BOOTP проверяет поле. Если оно равно нулю, промежуточный агент вставляет в него IP-адрес интерфейса, по которому и был получен данный запрос. Сервер BOOTP использует этот адрес для возврата ответа загрузки клиенту через промежуточный агент.
Затем агент пересылает запрос клиента на один или несколько предварительно указанных адресов серверов.

Присваивание IP-адресов

Администратор конфигурирует сервер BOOTP для присваивания системам IP-адресов посредством ручного создания таблицы отображения на IP-адрес комбинации типа оборудования и аппаратного адреса клиента [2] . Кодирование типов оборудования определяется документом Assigned Numbers. Например, для Ethernet код типа оборудования = 1. Таблица должна выглядеть как:

Тип оборудования	Аппаратный адрес	IP-адрес
1	02 60 8С 12 14 AA	128.121.2.5
1	08 00 20 D3 20 14	128.121.2.19

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

Клиент отправляет в широковещательной рассылке запрос (на порт 67 сервера).
Сервер получает этот запрос.
По типу оборудования и аппаратному адресу клиента сервер выбирает в таблице IP-адрес.
Если клиент расположен локально, сервер отправляет ответ в широковещательной рассылке (на порт 68 клиента).
Если клиент удален от сервера, ответ посылается на порт 67 по адресу, указанному в поле IP-адреса промежуточного агента. Затем промежуточный агент пересылает его в локальной широковещательной рассылке на клиентскую систему.

Загрузка клиента, знающего собственный IP-адрес

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

Конфигурирование загрузки программного обеспечения

Область для разработчиков

Ответ безадресному клиенту

Если клиент не заполнил поле предварительно заданного IP-адреса, такой адрес присваивается сервером. Простейшим способом возврата ответа клиенту в этом случае будет такой:

Применение заголовка IP с новым IP-адресом в качестве адреса назначения
Заключение датаграммы в кадр, адресованный на физический адрес клиента

Однако некоторые старые клиенты неспособны принимать датаграммы IP с явно указанным IP-адресом, пока не будут сконфигурированы на этот адрес. Такие клиенты могут принимать датаграммы на порт назначения 68 и с широковещательным IP-адресом 255.255.255.255. Новые клиенты BOOTP предпочитают прием ответа по широковещательному IP-адресу посредством установки в 1 флага широковещательной рассылки (находится в поле флагов) при отправке своего запроса.

Счетчик секунд

Когда клиент отсылает первый запрос на загрузку данных, поле счетчика секунд имеет нулевое значение. Если на запрос не приходит ответа, по завершении тайм-аута клиент снова отправляет запрос, изменяя значение в поле счетчика секунд. Для тайм-аута клиент использует случайный интервал, увеличивающийся до значения 60 с. Данное поле не имеет специального назначения. Его содержимое может проверять сервер или сетевой монитор для определения длительности ожидания клиентом загрузки по сети. Сервер может использовать значения из поля счетчика секунд для ранжирования запросов по приоритетам, однако в настоящее время в большинстве реализаций это поле игнорируется. Протокол начальной загрузки (Bootstrap Protocol — BOOTP) является простейшим приложением для запроса/ответа по протоколу UDP.

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

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

В этой главе мы познакомимся с двумя протоколами. Первым был создан протокол Bootstrap Protocol (BOOTP), обеспечивающий присваивание IP-адресов по таблице соответствия между физическими и IP-адресами. Администратор должен вручную создать такую таблицу на сервере BOOTP. Усовершенствованная версия BOOTP названа протоколом динамической конфигурации хостов (Dynamic Host Configuration Protocol — DHCP). DHCP позволяет полностью автоматизировать присваивание IP-адресов и обладает другими полезными свойствами.

Некоторым компьютерам для запуска требуется небольшое число конфигурационных параметров, другим — длинный подробный список значений множества таких параметров. Некоторым операционным системам, например настольным сетевым станциям, хостам Unix, требуется полная загрузка всего образа программного обеспечения. Системам, подобным маршрутизаторам, мостам, коммутаторам или концентраторам, требуется как получение конфигурационных параметров, так и загрузка необходимого программного обеспечения.

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

BOOTP был первым стандартом по автоматизации загрузки в окружении TCP/IP. После того как протокол прошел несколько этапов улучшения, он стал способен предоставлять системам все базовые конфигурационные параметры, а также несколько специализированных. Кроме того, BOOTP разрешает системам проводить поиск размещения необходимого программного обеспечения для загрузки.

Конфигурировать клиента BOOTP или DHCP очень просто. На рис. 11.1 показан выбор протокола в меню установки параметров программы Chameleon. Раскрывающееся окно разрешает пользователю указать адрес сервера BOOTP (если он известен). Если же адрес не введен, запрос на загрузку будет отправлен в широковещательной рассылке.

Рис. 11.1. Конфигурирование BOOTP на настольном клиентском компьютере

Область использования BOOTP ограничивает действия администратора, которому необходимо автоматизировать конфигурирование IP-адресов и не вводить вручную длинные списки аппаратных адресов вместе с соответствующими им IP-адресами. Администратору требуется защита от случайного изменения при конфигурировании IP-адресов, чтобы пользователь мог спокойно отключить систему и, перенеся ее на другое место сети, получить для системы правильные конфигурационные данные, а следовательно, быстро и без проблем запустить систему на новом месте.

DHCP расширяет возможности BOOTP и устраняет некоторые неопределенности, возникающие при использовании BOOTP и приводящие к неоптимальному взаимодействию в сети.

Первоначально BOOTP разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ (постоянном запоминающем устройстве, которое сохраняет информацию даже после отключения компьютера от сети. — Прим. пер.) только базовые средства для IP, UDP и TFTP. Исходный сценарий загрузки (см. рис. 11.2) выглядел следующим образом:

Рис. 11.2. Локальное взаимодействие между сервером загрузки и клиентом

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

Системам, которым требуется TFTP для загрузки программного обеспечения, удобнее использовать один сервер для параметров BOOTP, а другой (или несколько) — для загрузки программного обеспечения (см. рис. 11.3). Например, программное обеспечение операционной системы лучше получать с сервера с тем же типом операционной системы, что и у клиента.

Рис. 11.3. Использование отдельных серверов для загрузки параметров и программного обеспечений

Протокол BOOTP обеспечивает в работе достаточную гибкость:

Таблица 11.1 Параметры BOOTP и DHCP

Рассмотрим более подробно протокол начальной загрузки (Bootstrap Protocol — BOOTP). Он является простейшим приложением для запроса/ответа по протоколу UDP.

Клиент не имеет сведений об адресе для направления запроса и отправляет его с IP-адресом источника 0.0.0.0 и IP-адресом приемника 255.255.255.255.

Рис. 11.5. Выбор заданного сервера

Гораздо удобнее использовать один или несколько централизованных серверов загрузки, чем размещать такие серверы в каждой из локальных сетей. Однако как широковещательный запрос от клиента может достигнуть удаленного сервера по локальной сети? Для этого используется специальная система, помогающая переслать такой запрос (см. рис. 11.6).

Рис. 11.6. Промежуточная пересыпка запроса загрузки на удаленный сервер

Администратор конфигурирует сервер BOOTP для присваивания системам IP-адресов посредством ручного создания таблицы отображения на IP-адрес комбинации типа оборудования и аппаратного адреса клиента. Кодирование типов оборудования определяется документом Assigned Numbers. Например, для Ethernet код типа оборудования = 1. Таблица должна выглядеть как:

Тип оборудования	Аппаратный адрес	IP-адрес
1	02 60 8С 12 14 AA	128.121.2.5
1	08 00 20 D3 20 14	128.121.2.19

Многие реализации включают в таблицу дополнительные столбцы, идентифицирующие имена хостов для удобочитаемости таблицы.

Простейший сценарий для клиента, не знающего своего IP-адреса:

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

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

Первоначально предполагалось размещение на одном сервере как конфигурационных данных, так и загружаемого через TFTP программного обеспечения. Однако разделить эти службы очень просто. Сервер конфигурации BOOTP может просто указать IP-адрес хоста для сервера TFTP, а также путь к загружаемому файлу.

Как же сервером BOOTP выбираются сервер TFTP и загружаемый файл, если загружаемое программное обеспечение может быть распределено по нескольким физическим серверам?

Сервер BOOTP можно сконфигурировать с таблицей отображения коротких имен систем в IP-адреса серверов TFTP, содержащих загружаемые файлы, с указанием пути для каждого файла. Например:

Короткое имя	IP-адрес сервера TFTP	Путь к файлу
SunOS	128.121.50.2	/bin/vmunix

Однако некоторые старые клиенты неспособны принимать датаграммы IP с явно указанным IP-адресом, пока не будут сконфигурированы на этот адрес. Данная проблема называется "яйцо или курица" (что было раньше? — Прим. пер.).

Такие клиенты могут принимать датаграммы на порт назначения 68 и с широковещательным IP-адресом 255.255.255.255. Новые клиенты BOOTP предпочитают прием ответа по широковещательному IP-адресу посредством установки в 1 флага широковещательной рассылки (находится в поле флагов) при отправке своего запроса.

Когда клиент отсылает первый запрос на загрузку данных, поле счетчика секунд имеет нулевое значение. Если на запрос не приходит ответа, по завершении тайм-аута клиент снова отправляет запрос, изменяя значение в поле счетчика секунд. Для тайм-аута клиент использует случайный интервал, увеличивающийся до значения 60 с.

Данное поле не имеет специального назначения. Его содержимое может проверять сервер или сетевой монитор для определения длительности ожидания клиентом загрузки по сети. Сервер может использовать значения из поля счетчика секунд для ранжирования запросов по приоритетам, однако в настоящее время в большинстве реализаций это поле игнорируется.

DHCP существенно расширяет возможности BOOTP. К наиболее значимым изменениям относятся:

Еще одним примечательным свойством является возможность клиента BOOTP получить доступ к серверу DHCP, т.е. обеспечивается обратная совместимость.

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

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

В DHCP наследуется способность BOOTP предоставлять подробные или только определенные конфигурационные данные, а также идентификация загружаемого образа программного обеспечения. Недостатком BOOTP было то, что клиент не мог управлять получаемым им набором параметров. DHCP позволяет клиенту запрашивать только заданный набор таких параметров.

Что произойдет, если пользователь переместит компьютер в другое место, подключив его к иной сети или подсети? Во время загрузки компьютер, использующий DHCP, автоматически изменит свой IP-адрес и маску подсети, а также при необходимости — маршрутизатор по умолчанию и DNS. Без DHCP все эти изменения приходилось выполнять вручную.

В DHCP поддерживаются три типа присвоения адресов:

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

Процесс выделения адресов предполагает запрос клиентом IP-адреса на определенный период времени (возможно, что и навсегда). Сервер предоставляет клиенту адрес в аренду, указывая период использования данного адреса. Клиент должен периодически обновлять свои права на аренду, иначе через заданный интервал времени он потеряет это право. Потерянный адрес можно использовать повторно (например, для другого клиента. — Прим. пер.).

Для продления аренды адреса клиент идентифицирует свои права. При первичном выделении адреса клиенту через поле идентификатора клиента DHCP присваивается определенное значение, которое и будет применяться во всех последующих взаимодействиях с сервером. Иначе аренда идентифицируется типом оборудования клиента, аппаратным адресом и присвоенным IP-адресом,

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

Самым заметным изменением стало переименование области для разработчика в поле Options (варианты). Добавлены и несколько дополнительных вторичных полей, включая следующие:

Пример успешного начального взаимодействия между клиентом и сервером:

1. Клиент посылает широковещательную рассылку (DHCPDISCOVER) для поиска одного или нескольких серверов.

Клиенты могут продлить аренду адресов посредством быстрого обмена с сервером:

Параметры таблицы 11.1 могут содержаться в ответах протоколов BOOTP или DHCP, а параметры таблицы 11.2 могут использоваться только в DHCP.

Таблица 11.2 Параметры DHCP

Допустимо включать в списки большее число параметров. Текущие требования рассмотрены в последней версии RFC Assigned Numbers.

Многие значения представляют собой списки IP-адресов, где адреса должны появляться в порядке предпочтения.

Механизм исследования ICMP-маршрутизаторов имеет некоторое преимущество, поскольку предоставляет непрерывно обновляемую информацию о доступных в сети маршрутизаторах.

Приведенный список литературы действителен на момент написания книги:

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

Настройка параметров IP

Параметры TCP/IP можно настроить вручную или при загружать автоматически с помощью DHCP
или BOOTP при каждом включении.

Если при включении нового принтера действительный IP-адрес не может быть получен из сети,
принтеру автоматически назначается IP-адрес по умолчанию. В небольшой частной сети
назначается уникальный IP-адрес из диапазона 169.254.1.0 — 169.254.254.255. IP-адрес
продукта печатается на страницы конфигурации продукта и в отчете по сети. См.

Протокол Dynamic Host Configuration Protocol (DHCP)

Служба DHCP позволяет группе устройств использовать набор адресов IP, поддерживаемых
DHCP-сервером. Устройство или узел отправляют на сервер запрос, и если имеется
доступный IP-адрес, сервер назначает его устройству.

Протокол BOOTP является загрузочным протоколом, используемым для загрузки параметров
конфигурации и информации о хосте с сетевого сервера.

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

Когда организации назначаются адреса IP из определенного класса сети, механизмы
использования более чем одной сети не предоставляются. Администраторы локальных сетей
используют маски подсетей для разделения выделенной группы адресов на подсети.
Разделение на подсети применяется для повышения производительности и оптимизации
использования ограниченного пространства адресов.

Маска подсети

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

Шлюзы (маршрутизаторы) используются для соединения сетей. Шлюзы — это устройства,
транслирующие данные между системами, использующими различные протоколы связи,
форматы данных, структуру, языки или архитектуру. Шлюзы выполняют преобразование пакетов
данных и изменяют их структуру, чтобы они соответствовали системе получателя. При делении
сетей на подсети шлюзы необходимы для соединения этих подсетей.

DHCP (Dynamic Host Configuration Protocol) - протокол динамической конфигурации хоста.

DHCP является расширением и дополнением протокола BOOTP, который предназначен для выдачи IP-адресов бездисковым машинам.

Используется транспортный протокол UDP.

DHCP построен по схеме клиент-сервер.

Сервер должен отвечать на пакеты с IP-адресом 255.255.255.255, т.к. клиент может не знать где находится (какая IP-сеть, какой IP-адрес у DHCP).

Порт сервера по умолчанию 67.

Порт клиента по умолчанию 68.

Механизмы выделения IP-адресов сервером DHCP:

Динамическое присвоение - присваивает клиенту IP-адрес на ограниченное время.

Ручное выделение - IP-адрес клиента привязывается к адресу канального уровня (MAC-адрес для Ethrnet) клиента в базе DHCP, сетевым администратором.

Основные компоненты службы:

Relay Agent (агент пересылки) BOOTP - хост (маршрутизатор), который осуществляет связь между клиентом и сервером DHCP. В 2001г принят стандарт DHCP Relay Agent - RFC3046, и в следующей версии, наверное, будет DHCP Relay Agent вместо Relay Agent BOOTP. В старой версии (RFC0951) Relay Agent назывался BOOTP forwarding agents.

Binding (сопряжение) - совокупность конфигурационных параметров, включая, как минимум, IP-адрес, присваиваемый DHCP-клиенту.

12.2 Протокол BOOTP.

Создан для загрузки бездисковых машин.

Стандарт BOOTP - RFC0951 (Bootstrap Protocol W.J. Croft, J. Gilmore Sep-01-1985).

Последняя версия дополнений для BOOTP - RFC1542 (Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993). Введено понятие Relay Agent.

Первая версия расширения разработчиков (поле vend) для BOOTP - RFC1048 (BOOTP vendor information extensions P.A. Prindeville Feb-01-1988).

Последняя версия расширения разработчиков (поле vend) для BOOTP - RFC2132 (DHCP Options and BOOTP Vendor Extensions S. Alexander, R. Droms March 1997).

BOOTP является прототипом DHCP, в DHCP есть все что было в BOOTP.

Поэтому BOOTP подробно рассматривать не будем.

12.3 Протокол DHCP.

Первый стандарт DHCP - RFC1531 (Dynamic Host Configuration Protocol R. Droms October 1993).

Последняя версия DHCP - RFC2131 (Dynamic Host Configuration Protocol R. Droms March 1997).

Последняя DHCP версия для IPv6 - RFC3315 (Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney July 2003).

Последняя версия дополнительных параметров (поле OPTIONS) для DHCP - RFC2132 (DHCP Options and BOOTP Vendor Extensions S. Alexander, R. Droms March 1997).

Формат DHCP-пакета. Слова по 32 бита.

12.4 Механизм динамического выделения адресов.

Клиент посылается широковещательный (BROADCAST-255.255.255.255) запрос DHCPDISCOVER всем серверам DHCP.

Все активные серверы посылают широковещательный ответ DHCPOFFER. Клиент принимает все ответы, инициализацию делает по адресу канального уровня (MAC-адрес для Ethrnet).

Клиент выбирает один из предложенных адресов и посылает широковещательно DHCPREQUEST, которое должно содержать параметр Server Identifier (поле OPTIONS), чтобы указать, какой сервер им выбран.

Сервер посылает широковещательно DHCPACK.

Клиент может работать.

Пример динамического выделения адреса (пошагово 1,2,3,4)

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

12.4.1 Механизм повторного использования ранее выделеного адреса (RENEWING или Rebinding).

Если клиент сохранил и желает использовать выделенный ранее IP-адрес, он может опустить некоторые шаги алгоритма.

Алгоритм повторного получения:

Клиент посылает DHCPREQUEST.

Сервер, который узнает конфигурационные параметры клиента, посылает DHCPACK.

Клиент может работать.

12.5 База записей DHCP.

Пример файла (dhcpd.leases) содержащего базу выданных IP-адресов. Приведено только две записи.

lease 194.85.241.234 // Выданный IP-адрес
starts 1 2003/11/17 11:42:13; // Время выдачи
ends 1 2003/11/17 17:42:13; // Время истечения срока аренды
binding state active; // Состояние сопряжения активно (время не истекло)
next binding state free; // Следующее состояние сопряжения свободно (после истечения времени)
hardware ethernet 00:50:22:bb:c0:0d; // etherne

Читайте также: