маршрутизаторы, мосты, коммутаторы и концентраторы — увеличилась до соответствующего такому расширению количества.
Обслуживающий персонал столкнулся с проблемами постоянного подключения и перемещения новых устройств, а также с необходимостью изменения сетевой конфигурации для соответствия современным требованиям к сетям. Все это привело к необходимости создания механизма для автоматизации конфигурации сетевых узлов, распределенных операционных систем и сетевого программного обеспечения. Наиболее эффективным способом реализации такого механизма может быть сохранение конфигурационных параметров и образов программного обеспечения на одном или нескольких серверах
В этой главе мы познакомимся с двумя протоколами. Первым был создан протокол Bootstrap Protocol (
11.2 Требования протокола BOOTP
Некоторым компьютерам для запуска требуется небольшое число конфигурационных параметров, другим — длинный подробный список значений множества таких параметров. Некоторым операционным системам, например настольным сетевым станциям, хостам Unix, требуется полная загрузка всего образа программного обеспечения. Системам, подобным маршрутизаторам, мостам, коммутаторам или концентраторам, требуется как получение конфигурационных параметров, так и загрузка необходимого программного обеспечения.
Протокол конфигурирования должен быть гибким и надежным. В зависимости от размера сети, топологии и выдвигаемых требований, может быть полезна централизация загрузочной информации на одном сервере, распределение ее по нескольким серверам или выполнение реплицирования такой информации.
11.3 Возможности BOOTP
BOOTP был первым стандартом по автоматизации загрузки в окружении TCP/IP. После того как протокол прошел несколько этапов улучшения, он стал способен предоставлять системам все базовые конфигурационные параметры, а также несколько специализированных. Кроме того, BOOTP разрешает системам проводить поиск размещения необходимого программного обеспечения для загрузки.
Конфигурировать клиента BOOTP или DHCP очень просто. На рис. 11.1 показан выбор протокола в меню установки параметров программы
Рис. 11.1. Конфигурирование BOOTP на настольном клиентском компьютере
11.4 Необходимость DHCP
Область использования BOOTP ограничивает действия администратора, которому необходимо
11.5 Первая версия BOOTP
Первоначально BOOTP разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ (постоянном запоминающем устройстве, которое сохраняет информацию даже после отключения компьютера от сети. —
■ Клиент отправляет в широковещательной рассылке сообщение UDP на загрузочную информацию.
■ Сервер возвращает клиенту его IP-адрес и, при необходимости, местоположение файла загрузки.
■ С помощью
Рис. 11.2. Локальное взаимодействие между сервером загрузки и клиентом
Администраторы быстро поняли, что лучше использовать BOOTP для загрузки большего объема конфигурационных данных и настраивать по этому протоколу системы с собственными жесткими дисками (которым не требуется загрузка программного обеспечения).
Системам, которым требуется TFTP для загрузки программного обеспечения, удобнее использовать один сервер для параметров BOOTP, а другой (или несколько) — для загрузки программного обеспечения (см. рис. 11.3). Например, программное обеспечение операционной системы лучше получать с сервера с тем же типом операционной системы, что и у клиента.
Рис. 11.3. Использование отдельных серверов для загрузки параметров и программного обеспечений
11.6 Эволюция BOOTP
Протокол BOOTP обеспечивает в работе достаточную гибкость:
■ Перед запуском клиент может не иметь никакой информации или быть частично сконфигурированным.
■ Клиент может получить информацию на сервере загрузки или выбрать для этого специально