Меню

Bootp что это: Bog BOS: Протокол BOOTP/DHCP

Содержание

Настройка IP-адреса с помощью BOOTP

Протокол BOOTP является альтернативой протоколу RARP и обладает тем преимуществом, что позволяет настраивать маску подсети и шлюз. Чтобы использовать режим BOOTP для настройки IP-адреса, убедитесь, что служба BOOTP установлена и запущена на хост-компьютере (она должна быть указана в файле /etc/services на хост-компьютере в качестве реальной службы; введите man bootpd или см. информацию в документации к системе). Служба BOOTP обычно запускается с помощью файла /etc/inetd.conf, поэтому, возможно, ее потребуется включить, удалив символ «#» перед записью bootp в этом файле. Например, обычная запись bootp в файле /etc/inetd.conf выглядит следующим образом:

#bootp dgram udp wait /usr/etc/bootpd bootpd -i

В зависимости от системы эта запись может называться «bootps», а не «bootp».

Примечание

Чтобы включить службу BOOTP, воспользуйтесь текстовым редактором и просто удалите символ «#» (если символ «#» отсутствует, значит, служба BOOTP уже включена). Затем отредактируйте файл конфигурации BOOTP (обычно /etc/bootptab) и введите имя, тип сети (1 для Ethernet), адрес Ethernet и IP-адрес, маску подсети и шлюз сервера печати. К сожалению, для выполнения этой процедуры не существует единого стандартного формата, поэтому потребуется воспользоваться документацией к системе для получения информации о вводе этих данных (многие системы UNIX® также имеют примеры шаблонов в файле bootptab, которые можно использовать в справочных целях). Примеры типичных записей /etc/bootptab: (При подключении к беспроводной сети «BRN» ниже следует заменить на «BRW».)

BRN310107 1 00:80:77:31:01:07 192.168.1.2

и

BRN310107:ht=ethernet:ha=008077310107:

ip=192.168.1.2:

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

Так же, как при использовании RARP, сервер печати загрузит свой IP-адрес с сервера BOOTP при включении принтера.

4.3. Подготовка файлов для загрузки по TFTP

4.3. Подготовка файлов для загрузки по TFTP

Если ваша машина подключена к локальной сети, то вы можете загрузить её по сети с другой машины через TFTP. Для этого на удалённую машину в определённое место вам нужно поместить загрузочные файлы и настроить поддержку загрузки вашей машины.

Вам нужно настроить TFTP сервер, а если машин много, то DHCP сервер .

BOOTP — это IP протокол, который информирует компьютер о его IP-адресе и где в сети получить загрузочный образ. DHCP (Dynamic Host Configuration Protocol) более гибок и обратно совместим с BOOTP. Некоторые системы могут быть настроены только через DHCP.

В отличие от Open Firmware в машинах Sparc и PowerPC, SRM консоль не будет использовать RARP для получения IP-адреса, и поэтому вы должны использовать BOOTP для загрузки по сети вашей Alpha[]. Также вы можете выполнить IP настройку для сетевых интерфейсов в SRM консоли.

Trivial File Transfer Protocol (TFTP) используется для загрузки загрузочного образа на клиентскую машину. Теоретически, можно использовать любой сервер на любой платформе, которая реализует эти протоколы. В примерах этого раздела мы используем команды из SunOS 4.x, SunOS 5.x (так называемый Solaris) и GNU/Linux.

4.3.1. Настройка BOOTP сервера

Для GNU/Linux есть два BOOTP сервера. Первый — CMU bootpd. Второй, на самом деле являющийся сервером DHCP — ISC dhcpd. В Debian GNU/Linux они находятся в пакетах bootp и dhcp3-server соответственно.

Чтобы использовать CMU bootpd, во-первых, вы должны раскомментировать (или добавить) соответствующую строку в /etc/inetd.conf. Для этого в Debian GNU/Linux вы можете запустить update-inetd --enable bootps, затем /etc/init.

d/inetd reload. Если BOOTP сервер работает не под Debian, то строка выглядит так:

bootps  dgram  udp  wait  root  /usr/sbin/bootpd  bootpd -i -t 120

Теперь вы должны создать файл /etc/bootptab. Внутри он напоминает хорошо знакомый и загадочный формат старых добрых BSD файлов printcap, termcap и disktab. Подробности смотрите на странице руководства bootptab. Для CMU bootpd вам нужно знать аппаратный адрес (MAC) клиента. Вот пример /etc/bootptab:

client:\
  hd=/tftpboot:\
  bf=tftpboot.img:\
  ip=192.168.1.90:\
  sm=255.255.255.0:\
  sa=192.168.1.1:\
  ha=0123456789AB:

Нужно изменить по крайней мере параметр «ha», который содержит аппаратный адрес клиента. Параметр «bf» содержит файл, который клиент должен получить по TFTP; подробности смотрите в Раздел 4.3.4, «Копирование TFTP образов в каталог TFTP сервера».

Напротив, настройка BOOTP в ISC dhcpd очень проста, так как здесь BOOTP считается одним из вариантов клиента DHCP. Некоторые архитектуры требуют сложной конфигурации для загрузки клиентов по BOOTP. Если у вас один из таких случаев, прочитайте раздел Раздел 4.3.2, «Настройка DHCP сервера». Если нет, то достаточно просто добавить директиву allow bootp в конфигурационный блок подсети, содержащей клиента и перезапустить dhcpd командой /etc/init.d/dhcpd3-server restart.

4.3.2. Настройка DHCP сервера

Одним из свободных DHCP серверов является ISC dhcpd. В Debian GNU/Linux он доступен из пакета dhcp3-server. Вот пример его конфигурационного файла (обычно /etc/dhcp3/dhcpd.conf

):

option domain-name "example.com";
option domain-name-servers ns1.example.com;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
server-name "servername";

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.200 192.168.1.253;
  option routers 192.168. 1.1;
}

host clientname {
  filename "/tftpboot/tftpboot.img";
  server-name "servername";
  next-server servername;
  hardware ethernet 01:23:45:67:89:AB;
  fixed-address 192.168.1.90;
}

В этом примере определён единственный сервер servername, который работает в качестве DHCP, TFTP серверов и шлюза сети. Вам почти наверняка нужно изменить опцию domain-name, а также имя сервера и аппаратный адрес клиента. Опция filename должна содержать имя файла, который нужно получить по TFTP.

После редактирования конфигурационного файла для dhcpd

, перезагрузите сервер командой /etc/init.d/dhcpd3-server restart.

4.3.3. Включение TFTP сервера

Для запуска TFTP сервера вы должны убедиться, что tftpd включён. Обычно, это делается добавлением в /etc/inetd.conf строки вида:

tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd /tftpboot

Пакеты Debian сами создают такую строку при установке.

Замечание

Исторически, TFTP-серверы используют каталог /tftpboot для хранения образов. Однако, пакеты Debian GNU/Linux могут использовать другие каталоги, чтобы соответствовать Filesystem Hierarchy Standard. Например, tftpd-hpa по умолчанию использует /var/lib/tftpboot. Вам может потребоваться изменить примеры конфигурации для соответствия.

Загляните в файл /etc/inetd.confи запомните каталог, который используется в качестве аргумента

in.tftpd[] — он вам понадобиться позже. Если вы изменили /etc/inetd.conf, вам нужно уведомить об этом запущенный процесс inetd. На машине Debian выполните /etc/init.d/inetd reload; на других ОС определите ID процесса inetd и запустите kill -HUP inetd-pid.

4.3.4. Копирование TFTP образов в каталог TFTP сервера

Далее, поместите нужный загрузочный образ TFTP из Раздел 4. 2.1, «Где искать установочные образы» в каталог загрузочных образов tftpd. Вы можете сделать ссылку на этот файл для файла, который tftpd будет передавать для загрузки определённому клиенту. К сожалению, имя файла зависит от клиента TFTP и никак не стандартизовано.

4.3.4.1. Загрузка Alpha по TFTP

На Alpha, вы должны указать имя файла (относительно каталога загрузочных образов) с помощью аргумента -file команды SRM boot, или установив переменную среды BOOT_FILE. Или же, имя файла можно получить по BOOTP (в ISC dhcpd, используйте директиву filename). В отличие от Open Firmware, имя файла по умолчанию не задано в SRM, поэтому вы должны указать имя файла одним из этих методов.

Разница между BOOTP и DHCP

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

Основное различие между BOOTP и DHCP заключается в том, что BOOTP поддерживает статическую настройку IP-адресов, а DHCP поддерживает динамическую настройку. Это означает, что DHCP автоматически назначает и получает IP-адреса с компьютера, подключенного к Интернету, а также имеет некоторые дополнительные функции.

Сравнительная таблица

Основа для сравненияBOOTP
DHCP
Autoconfiguration
Невозможно только поддерживает ручную настройку.
Он автоматически получает и назначает IP-адреса.
Временная IP-адресация
Не предоставлен
Предоставляется в течение ограниченного периода времени.
Совместимость
Не совместим с клиентами DHCP.
Возможность взаимодействия с клиентами BOOTP.
Мобильные машины
Настройка IP и доступ к информации невозможны.
Поддерживает мобильность машин.
Возникновение ошибки
Мануальная конфигурация подвержена ошибкам.
Автоконфигурация невосприимчива к ошибкам.
использование
Предоставляет информацию на бездисковый компьютер или рабочую станцию.
Для хранения и пересылки информации требуются диски.

Определение BOOTP

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

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

RARP является предшественником BOOTP и служит для той же цели, но ограничением RARP является то, что он предоставляет только информацию об IP, а не дополнительную информацию об этом.

Как описано выше, BOOTP является протоколом, который позволяет статическую конфигурацию. Причина статической природы BOOTP заключается в том, что необходимость динамически обнаруживать маршрутизаторы или менять маршрутизатор устраняется, когда к остальному Интернету подключен только один маршрутизатор. Однако, если есть несколько маршрутизаторов, подключенных к Интернету. Хост пытается получить маршрут по умолчанию при запуске может привести к потере соединения в случае сбоя одного маршрутизатора. А также сбой может быть не обнаружен.

Сервер BOOTP использует таблицу, в которой физический адрес сопоставляется с IP-адресом, когда клиент запрашивает свой IP-адрес. BOOTP не поддерживает мобильные машины; он работает хорошо только тогда, когда привязка между физическим и IP-адресами является статической и фиксированной в таблице. Используется ограниченный широковещательный адрес (255.255.255.255).

Определение DHCP

Протокол динамической конфигурации хоста (DHCP) назначает IP-адреса динамически по сети. DHCP более универсален, чем BOOTP, и он обратно совместим, что означает, что он может взаимодействовать с клиентами BOOTP.

Динамическое назначение IP-адресов выгодно по трем причинам:

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

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

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

DHCP использует три таймера:
  1. Lease Renewal Timer — клиентский компьютер использует это для отправки запроса DHCP, чтобы запросить у сервера больше времени по истечении этого таймера.
  2. Lease Rebinding Timer — Когда истекает этот таймер, клиент не получает никаких ответов, и предполагается, что сервер не работает. Затем с помощью службы IP-широковещания запрос DHCP отправляется всем серверам.
  3. Таймер истечения срока аренды — по истечении этого таймера система начинает сбой по причине отсутствия действительного IP-адреса для хоста в сети.

Ключевые различия между BOOTP и DHCP

  1. BOOTP является статическим протоколом и поддерживает ручную настройку. С другой стороны, DHCP является динамическим протоколом и поддерживает ручную, динамическую и автоматическую настройку IP-адресов.
  2. IP-адресация по требованию предоставляется в DHCP, тогда как BOOTP не поддерживает постоянное выделение (аренду) IP-адресов.
  3. DHCP может обрабатывать мобильные машины. Напротив, BOOTP не может настраивать или получать доступ к информации с мобильных машин; и это работает только со стационарными соединениями.
  4. BOOTP подвержен ошибкам из-за использования ручной настройки, а в DHCP ошибки возникают редко.

Заключение

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

BOOTP — это… Что такое BOOTP?

  • BOOTP — (Bootstrap Protocol) Familie: TCP/IP Einsatzgebiet: Bezug einer Netzwerkkonfiguration und eines Kernelnamens für einfache (etwa plattenlose) Geräte Ports: 67/UDP (Anfrage) 68/UDP (Antwort) BOOTP im TCP/IP‑Protokollstapel: Anwendung BOOTP… …   Deutsch Wikipedia

  • BootP — (Bootstrap Protocol) Familie: TCP/IP Einsatzgebiet: Bezug einer Netzwerkkonfiguration und eines Kernelnamens für einfache (etwa plattenlose) Geräte Ports: 67/UDP (Anfrage) 68/UDP (Antwort) BOOTP im TCP/IP‑Protokollstapel: Anwendung BOOTP… …   Deutsch Wikipedia

  • BOOTP — Bootstrap Protocol (BOOTP) est un protocole réseau d amorçage, qui permet à une machine cliente sans disque dur de découvrir sa propre adresse IP, l adresse d un hôte serveur, et le nom d un fichier à charger en mémoire pour exécution. On peut… …   Wikipédia en Français

  • BOOTP — son las siglas de Bootstrap Protocol. Es un protocolo de red UDP utilizado por los clientes de red para obtener su dirección IP automáticamente. Normalmente se realiza en el proceso de arranque de los ordenadores o del sistema operativo. Los… …   Enciclopedia Universal

  • BOOTP — …   Википедия

  • Bootp — …   Википедия

  • BOOTP — Bootstrap Protocol (Governmental » Military) ** Boot Protocol (Computing » Networking) …   Abbreviations dictionary

  • BOOTP — Bootstrap Protocol (RFC951) …   Acronyms

  • bootP — ● ►en n. m. ►PROT Bootstrap Protocol. Protocole qui permet à un client d interroger un serveur pour savoir quelle est son adresse IP en fonction de son adresse matérielle sur le réseau. Souvent utilisé pour permettre à des stations sans disque de …   Dictionnaire d’informatique francophone

  • BOOTP — Bootstrap Protocol (RFC951) …   Acronyms von A bis Z

  • BOOTP —    See Bootstrap Protocol …   Dictionary of networking

  • 11.

    3 Возможности BOOTP. TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

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

    Возможности PNG

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

    Возможности IPX/SPX

    Возможности IPX/SPX Подобно TCP/IP и AppleTalk, в IPX/SPX используются 32-разрядные адреса, которые обычно представляются в шестнадцатеричном виде, например 0x23a91002. Однако каждый адрес ставится в соответствие не одному компьютеру, а сегменту сети, который либо соединяется с другими

    Возможности SSH

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

    Возможности tar

    Возможности tar Утилита tar — чрезвычайно мощный инструмент; она поддерживает большое количество опций. Опции программы tar делятся на две категории: команды и модификаторы. Команды указывают утилите tar, какие действия она должна выполнить, например, создать архив, вывести

    6.12 Возможности IP

    6.12 Возможности IP В IP существует несколько возможностей, обеспечивающих гибкость и пригодность этого протокола к различным окружениям. Среди прочих следует упомянуть адаптивную маршрутизацию (adaptive routing), а также фрагментацию и сборку датаграммы (datagram fragmentation and

    Глава 11 Конфигурация с помощью BOOTP и DHCP

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

    11.2 Требования протокола BOOTP

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

    11.5 Первая версия BOOTP

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

    11.

    6 Эволюция BOOTP

    11.6 Эволюция BOOTP Протокол BOOTP обеспечивает в работе достаточную гибкость:? Перед запуском клиент может не иметь никакой информации или быть частично сконфигурированным.? Клиент может получить информацию на сервере загрузки или выбрать для этого специально указанный

    11.7 Протокол BOOTP

    11.7 Протокол BOOTP Рассмотрим более подробно протокол начальной загрузки (Bootstrap Protocol — BOOTP). Он является простейшим приложением для запроса/ответа по протоколу UDP.? Клиент отсылает сообщение запроса на загрузку (bootrequest) из порта 68 на порт 67 сервера.? Сервер реагирует на это

    11.7.1 Формат сообщения BOOTP

    11.7.1 Формат сообщения BOOTP Для запроса и ответа загрузки используется одинаковый формат сообщения. В запросе некоторые поля имеют нулевые значения. Формат сообщения показан на рис. 11.4. Рис. 11.4. Формат запроса и ответа сообщения загрузкиПоля, которые должны быть заполнены в

    13.8 Возможности NVT

    13.8 Возможности NVT В следующих разделах мы подробно исследуем структуру telnet и изучим возможности, которые он может предоставить разработчику приложений клиент/сервер.По окончании согласования параметров сеанса отдельные варианты эмуляции терминала могут обеспечивать

    7.3.5. Дополнительные возможности

    7.3.5. Дополнительные возможности Вкладка Дополнительно основного окна Comodo (рис. 7.25) содержит кнопки вызова окна общих настроек программы (можно изменить тему, оформление, определить настройки журналов, сменить язык и т. п.), обновить компоненты всей программы (а не только

    1.3.1. Базовые возможности

    1.3.1. Базовые возможности Искать в Яндексе очень и очень просто. Вы задаете вопрос в том виде, в каком могли бы задать его приятелю, учителю, врачу, ученому. Единственное пожелание — вопрос не должен быть очень длинным и содержать множество слов. Оптимальное количество слов

    Возможности PKI

    Возможности PKI Для удовлетворения требований аутентификации в распределенной среде механизмы на базе сертификатов используют криптографию с открытыми ключами. Они созданы на основе многих свойств своих предшественников и добавляют новые возможности. Инфраструктура

    Устранение неполадок загрузки PXE с помощью анализатора сетевых…

    Обозревателе

    Эта информация не подробно рассказывает об ошибках, которые могут привести к сбою загрузки PXE. В этом документе представлена информация о требованиях к успешной загрузке PXE и о том, что происходит, когда нет доступных PXE-серверов.

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


    Служба

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

    DHCP-процесс начинается с клиента, запросившего адрес, используя сообщение DHCP для ВЫЯСНЕНия. Сообщение «исследование» — это UDP-пакет с исходным портом 68 (определяется как Бутпк, для BOOTP-клиента) и портом назначения 67 (определяется как BOOTP-BOOTP, для BOOTP-сервера). В сообщении об ОБНАРУЖЕНии представлен MAC-адрес запрашивающего узла в качестве исходного MAC-адреса и вещание (ALL a) в качестве целевого MAC-адреса. Исходный IP-адрес — 0.0.0.0, IP-адрес назначения — 255.255.255.255 (широковещательный). Как минимум, запрос включает в себя следующие варианты.

    • Параметр 55 (список запросов с параметрами)
    • Вариант 1 (маска подсети)
    • Вариант 3 (маршрутизатор)
    • Вариант 6 (сервер доменных имен)

    Один или несколько серверов DHCP должны отвечать ПРЕДЛОЖЕНИЕм DHCP. Сообщение о ПРЕДЛОЖЕНии DHCP — это пакет UDP с MAC-адресом клиента, запрашивающего обслуживание в качестве адреса назначения. Порты должны быть противоположными по отношению к исходному запросу (исходный порт должен быть 67, порт назначения должен быть 68). Исходный IP-адрес — это адрес сервера, выставляющего предложение, а IP-адрес назначения — это трансляция. Это предложение будет включать предложенный IP-адрес и ответы на запрошенные дополнительные параметры.

    Клиент отвечает на одно из предложений с ЗАПРОСом DHCP. Сообщение запроса — это UDP-пакет, аналогичный сообщению об ОБНАРУЖЕНии, который использует те же самые исходные порты и адреса назначения, а также запрашивает те же параметры.

    Сервер отвечает DHCP ACK (подтверждение) со всеми запрошенными сведениями. Сообщение ACK — это UDP-пакет, аналогичный сообщению о предложении, у которого запрошены дополнительные сведения.


    PXE-расширения для DHCP

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

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

    Сообщение о DHCP-ОБНАРУЖЕНии от клиента PXE содержит следующие необязательные параметры.

    • 60 — идентификатор класса вендора
    • 66 — имя сервера TFTP (запрос имени сервера TFTP, содержащего образ загрузки)
    • 67 — имя бутфиле (имя файла образа для загрузки)


    Проверка трассировки Есереал * или Вирешарк * для загрузки PXE

    Процесс загрузки PXE включает в себя множество обменов.

    1. PXE-клиент отправляет исследование DHCP с заданными параметрами PXE.
    2. DHCP-сервер отвечает ПРЕДЛОЖЕНИЕм DHCP с параметрами TCP/IP.
    3. PXE-клиент отвечает на запрос DHCP
    4. DHCP-сервер отвечает на запросы DHCP ACK.
    5. Если сервер DHCP также является PXE-сервером, протокол DHCP ACK обычно имеет имя сервера TFTP и имя файла для загрузки. Если PXE-сервер является другой системой, то между PXE-сервером и PXE-клиентом после начального DHCP-процесса будет установлен отдельный обмен запросами и ответов.
      Примечание
      • Если на начальном сервере DHCP не задано имя сервера TFTP и имя файла для загрузки, проанализируйте трассировку до тех пор, пока не убедитесь, что эти два варианта прошли успешное подтверждение DHCP.
      • После того как PXE-клиент получает подтверждение с именем сервера TFTP и именем файла загрузки, клиент подключается к TFTP-серверу с запросом на чтение TFTP, который включает в себя имя загрузочного файла.
      • Сеанс TFTP устанавливается и продолжается до тех пор, пока передача файла не завершится.

    Рис. 1 — снимок экрана, Есереал захват DHCP-сообщения об ОБНАРУЖЕНии DHCP от клиента PXE. Обратите внимание, что выделяется вариант 55 (список запросов с параметрами), и в нем указаны параметры, которые требуется запросить.

    Кроме того, эти параметры включают в себя запрос на имя сервера TFTP (Option 66) и имя файла загрузки (Option 67). Вариант 60, также запрашивается идентификатор класса вендора. Ответ на запрос является необязательным и используется для информирования клиента о том, что PXE-сервер находится на сервере, отличном от сервера DHCP-сервера (используется DHCP-прокси).


    Рис. 1. ПОИСК DHCP

     

    На рисунке 2 показан ответ DHCP ACK на запрос DHCP. Протокол DHCP ACK содержит те же параметры, что и в ПРЕДЛОЖЕНии DHCP. Обратите внимание, что сервер TFTP и имя файла загрузки включены в пакет при успешном выполнении транзакции DHCP.


    Рис. 2. DHCP ACK

     

    После успешного обмена данными на сервере DHCP начинается сеанс TFTP с запросом на чтение TFTP. На рисунке 3 показан запуск сеанса TFTP.


    Рис. 3. Сеанс TFTP.

     

    На рисунке 4 показана трассировка сбоев PXE-загрузки, поскольку PXE-сервер отсутствует. Несмотря на то что PXE-клиент запросил имя сервера TFTP (Option 66) и имя файла загрузки (Option 67), отображаемое предложение DHCP не включает в себя вариант 66 или 67. В этом случае PXE-клиент выполняет повторные запросы на поиск DHCP, за которыми следуют ответы на предложение DHCP, для которых не предусмотрены параметры, необходимые для выполнения операции загрузки PXE.


    Рис. 4. ПРЕДЛОЖЕНИЕ DHCP
    Где нет доступных PXE-серверов

    Запись BOOTP

    Навигация: BOOTP | Запись BOOTP

    Параметры BOOTP используются непосредственно приложением Manager. Они не являются параметрами конфигурации системы.

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

    Записи BOOTP не являются частью конфигурации системы, они являются элементами, которые сохраняется на ПК с Manager. Обычно Manager автоматически создает запись BOOTP для каждой системы, с которой ранее была установлена связь, при этом число таких записей не может превышать 50. Однако записи BOOTP могут добавляться и редактироваться вручную при необходимости.

    Поле Описание
    Расположение файлов Местоположение, из которого Manager предоставляет файлы в ответ на запросы BOOTP, — это собственный каталог двоичных файлов. Местоположение меняется при помощи или .

    Это каталог также используется приложением Manager для предоставления файлов по протоколу TFTP.

    Отключение протокола BOOTP Функция поддержки BOOTP, предоставляемой Manager, может быть отключена для всех систем. Выберите .
    Включено По умолчанию = Включено

    Если данный флажок не установлен, поддержка BOOTP | Запись BOOTP данным компьютером с приложением Manager для соответствующей системы будет отключена.

    Имя системы Это поле изменить нельзя. В нем отображается имя системы.
    Адрес MAC MAC-адрес системы. Этот адрес можно получить или проверить различными способами:
    • Если настройки конфигурации системы загружены в приложение Manager, то это отображается как параметр «Серийный номер» формы «Форма блока». В системах, находящихся в состоянии по умолчанию, он также используется в качестве имени системы.

    • Если система запрашивает программное обеспечение, то адрес MAC отображается как часть запроса на панели состояния в нижней части окна приложения Manager.

    • Если к системе можно обратиться с запросом проверки связи (ping), то адрес MAC можно получить с помощью команды arp -a <ip-адрес>.

    Адрес IP IP-адрес интерфейса ЛВС1 системы.
    Имя файла Имя файла программного обеспечения с расширением BIN, используемого устройствами управления этого типа. Для передачи системе этот файл должен существовать в Рабочем каталоге приложения Manager.
    Смещение времени : по умолчанию = 0.

    Кроме выполнения поддержки систем по протоколу BOOTP приложение Manager также выступает сервером времени (RFC868). В этом поле задается смещение между временем компьютера, на котором выполняется приложение Manager, и временем, передаваемым системе в ответ на запросы времени. Это поле не используется, если конкретный IP-адрес сервера времени задан с помощью формы Система в настройках конфигурации системы.

    Использование приложения Manager в качестве сервера времени Интернета (RFC868) может быть отключено. Выберите и снимите флажок Включить сервер времени.

    Что такое протокол начальной загрузки (BOOTP)?

    Что означает протокол начальной загрузки (BOOTP)?

    Bootstrap Protocol — это сетевой протокол, используемый клиентом для получения IP-адреса от сервера. Первоначально он был определен как спецификация RFC 951 и был разработан для замены протокола обратного разрешения адресов (RARP), также известного как RFC 903. Протокол начальной загрузки был предназначен для того, чтобы компьютеры могли найти то, что им нужно для правильной работы после загрузки. BOOTP использует агент ретрансляции, который позволяет пересылать пакеты из локальной сети с использованием стандартной IP-маршрутизации, позволяя одному серверу BOOTP обслуживать хосты в нескольких подсетях.

    BOOTP был в значительной степени заменен более эффективным протоколом динамической конфигурации хоста (DHCP), который имеет больше возможностей и гибкость. Однако обновленную утилиту он нашел и в бездисковых ПК с медиацентрами.

    Techopedia объясняет протокол начальной загрузки (BOOTP)

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

    BOOTP — это широковещательный протокол, так как он должен отправлять сообщения на все доступные хосты в сети, чтобы получать ответы или ресурсы. BOOTP используется во время процесса начальной загрузки, когда компьютер изначально запускается, отсюда и название. Изначально BOOTP требовал использования дискет для установления начального сетевого подключения, но вскоре этот процесс был интегрирован в BIOS сетевых карт и материнских плат, чтобы обеспечить прямую загрузку по сети.

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


    Bootstrap Protocol (BOOTP) — Сетевая энциклопедия

    Bootstrap Protocol (BOOTP) — это протокол и служба TCP / IP, которые позволяют бездисковым рабочим станциям получать свой IP-адрес и файл образа загрузки с сервера.

    Что такое BOOTP (протокол начальной загрузки)?

    BOOTP означает Bootstrap protocol. — это протокол и служба TCP / IP, позволяющая бездисковым рабочим станциям получать свой IP-адрес, другую информацию о конфигурации TCP / IP и файл образа загрузки с сервера протокола начальной загрузки (BOOTP).

    Сетевая карта (NIC) на этих бездисковых рабочих станциях содержит микросхему программируемой постоянной памяти (PROM), содержащую код, необходимый для инициализации клиента.

    Как работает BOOTP?

    Когда клиент BOOTP запущен, у него нет IP-адреса, поэтому он транслирует сообщение, содержащее его MAC-адрес, в сеть. Это сообщение называется «запросом BOOTP», и оно принимается сервером BOOTP, который отвечает клиенту со следующей информацией, необходимой клиенту:

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

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

    Протокол динамической конфигурации хоста (DHCP) был разработан как расширение BOOTP. BOOTP определяется в RFC 951 и 1084. Протокол начальной загрузки (BOOTP)

    Термин «протокол начальной загрузки»

    Термин «протокол начальной загрузки» (или «протокол начальной загрузки») происходит от идеи поднять себя своими собственными усилиями — то, что, очевидно, сложно сделать.Другими словами, как запускается клиентская машина, если изначально у нее нет ни IP-адреса, ни операционной системы? BOOTP делает эту трудную задачу возможной.

    Windows NT не поддерживает BOOTP

    Microsoft Windows NT поддерживает DHCP, но не BOOTP. Windows NT с пакетом обновления 3 и более поздних версий обеспечивает некоторую поддержку клиентов BOOTP, как и Microsoft Windows 2000. Дополнительные сведения см. В файле readme.txt для пакета обновления 3.

    Bootp и DHCP

    Bootp и DHCP

    Обзор

    DHCP / Bootp используется для загрузки данных конфигурации с сервера DHCP или Bootp соответственно в концентратор.

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

    DHCP : — Протокол динамической конфигурации хоста (DHCP) автоматически управляет распределением информации о конфигурации TCP / IP. присвоение IP-адресов.С помощью DHCP вы можете настроить концентратор для автоматического получения IP-адреса без настройки. требуется либо на концентраторе, либо на DHCP-сервере. В динамическом режиме адрес используется устройством в течение определенного периода времени. Срок зависит от ситуации; одному устройству может потребоваться адрес только в течение часа, в то время как другое устройство может использовать тот же адрес в течение нескольких дней. DHCP больше подходит в средах где количество необходимых IP-адресов превышает количество доступных.Это также позволяет устройству получить информация о конфигурации, такая как IP-адрес и маска подсети, в одном сообщении, что снижает нагрузку на сеть.

    Примечание: HP J3288A Hub-12 и HP J3289A Hub-24 совместимы с серверами DHCP и Bootp

    Процесс DHCP / Bootp

    Каждый раз, когда параметр IP Config в концентраторе настроен на DHCP / Bootp (по умолчанию) или при перезагрузке концентратора с такой конфигурацией:

    1. Запросы DHCP / Bootp автоматически передаются в локальную сеть.(Концентратор отправляет один тип запроса, который может обработать сервер DHCP или Bootp.)
    2. Когда сервер DHCP или Bootp получает запрос, он отвечает автоматически сгенерированным IP-адресом и маска подсети для концентратора. Концентратор также получает адрес IP-шлюза, если сервер настроен на предоставить один.

    В случае Bootp сервер сначала должен быть настроен с записью, которая имеет MAC-адрес концентратора.(Концентратор правильно обрабатывает ответы от любого типа серверов. Если возвращается несколько ответов, концентратор пытается для использования первого ответа DHCP.) Если концентратор изначально настроен для работы DHCP / Bootp (по умолчанию), или если он перезагружается с этой конфигурацией, он немедленно начинает отправку пакетов запроса по сети. Если хаб не получает отвечая на его запросы DHCP / Bootp, он продолжает периодически отправлять пакеты запросов, но с уменьшающейся частотой.Таким образом, если сервер DHCP или Bootp недоступен или недоступен для концентратора при первой настройке DHCP / Bootp, хаб может не сразу получить желаемую конфигурацию.

    Работа DHCP : — Существенная разница между конфигурацией DHCP и конфигурацией Bootp заключается в том, что IP-адрес назначается из DHCP-сервер работает автоматически и не требует настройки DHCP-сервера.Однако с помощью этой автоматической функции Адрес временно сдан в аренду. Периодически от концентратора может требоваться продление аренды конфигурации IP. Таким образом, IP-адресация, предоставляемая сервером, может отличаться каждый раз, когда концентратор перезагружается или обновляет свою конфигурацию. с сервера. Однако вы можете исправить назначение адреса для концентратора, выполнив одно из следующих действий:

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

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

    Bootp Operation : — Когда сервер Bootp получает запрос, он ищет его База данных Bootp для записи, соответствующей MAC-адресу в запросе Bootp от хаба.Если совпадение найдено, данные конфигурации в связанной записи базы данных будут вернулся в хаб. Для большинства систем Unix база данных Bootp содержится в файле / etc / bootptab. В отличие для работы DHCP, конфигурации Bootp всегда одинаковы для каждого принимающего устройства. То есть сервер Bootp отвечает на запрос с конфигурацией, ранее сохраненной на сервере и предназначенной для запрашивающего устройства.

    Вы можете настроить DHCP / Bootp либо через интерфейс веб-браузера, либо через концентратор. консольный интерфейс.

    Вернуться к конфигурации IP


    Перейти к содержанию

    Авторские права © 1998 by Hewlett-Packard Company

    rfc951

     Network Working Group Билл Крофт (Стэнфордский университет)
    Запрос комментариев: 951 Джон Гилмор (Sun Microsystems)
                                                              Сентябрь 1985 г.
    
                           ПРОТОКОЛ BOOTSTRAP (BOOTP)
    
    
    1.Статус этого меморандума
    
       Этот RFC предлагает предлагаемый протокол для ARPA-Internet.
       сообщества, и просит обсуждения и предложений по улучшению.
       Распространение этой памятки не ограничено.
    
    2. Обзор
    
       Этот RFC описывает протокол начальной загрузки IP / UDP (BOOTP), который позволяет
       бездисковая клиентская машина, чтобы обнаружить свой IP-адрес, адрес
       хоста сервера, и имя файла, который будет загружен в память и
       выполнен. Операция начальной загрузки может рассматриваться как состоящая из
       ДВЕ ФАЗЫ.В этом RFC описывается первый этап, который может быть
       помечены как «определение адреса и выбор загрузочного файла». После этого
       информация об адресе и имени файла получена, управление переходит к
       вторая фаза начальной загрузки, на которой происходит передача файла. Файл
       передача обычно будет использовать протокол TFTP [9], поскольку он
       Предполагалось, что обе фазы находятся в PROM на клиенте. тем не мение
       BOOTP также может работать с другими протоколами, такими как SFTP [3] или
       FTP [6].
    
       Мы предлагаем, чтобы программное обеспечение PROM клиента позволяло
       полная загрузка без взаимодействия с пользователем.Это тип
       загрузка, которая может произойти при автоматическом включении питания. Механизм
       должен быть предоставлен пользователю для ручного ввода необходимого
       информация об адресе и имени файла для обхода протокола BOOTP и
       сразу перейти к фазе передачи файлов. Если энергонезависимая память
       доступны, мы предлагаем оставить настройки по умолчанию и обойти
       протокол BOOTP, если эти настройки не вызывают передачу файла
       фаза, чтобы выйти из строя. Если кэшированная информация не работает, начальная загрузка должна
       вернитесь к фазе 1 и используйте BOOTP.Вот краткое описание протокола:
    
          1. Производится однократный обмен пакетами. Тайм-ауты используются для
          повторно передать, пока не будет получен ответ. То же поле пакета
          макет используется в обоих направлениях. Поля фиксированной длины максимум
          разумная длина используется для упрощения определения структуры и
          парсинг.
    
          2. Существует поле «opcode» с двумя значениями. Клиент
          передает пакет bootrequest. Затем сервер отвечает
          пакет bootreply.Загрузочный запрос содержит клиентский
          аппаратный адрес и его IP-адрес, если он известен.
    
    
    Крофт и Гилмор [Страница 1] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
          3. Запрос может дополнительно содержать имя сервера, на котором
          клиент желает ответить. Это сделано для того, чтобы клиент мог заставить
          загрузка должна происходить с определенного хоста (например, если несколько версий
          такой же загрузочный файл существует или если сервер находится на большом удалении
          net / домен).Клиенту не нужно иметь дело с именем / доменом
          Сервисы; вместо этого эта функция передается серверу BOOTP.
    
          4. Запрос может дополнительно содержать "общее" имя файла, которое будет
          загрузился. Например, unix или ethertip. Когда сервер отправляет
          bootreply, он заменяет это поле полностью определенным
          путь к соответствующему загрузочному файлу. Определяя это имя,
          сервер может обращаться к своей базе данных, коррелируя клиентские
          запрос адреса и имени файла с конкретным загрузочным файлом
          настроен для этого клиента.Если имя файла bootrequest имеет значение NULL
          строка, то сервер возвращает поле имени файла, указывающее
          файл 'default', который будет загружен для этого клиента.
    
          5. В случае клиентов, которые не знают свои IP-адреса,
          сервер также должен иметь базу данных, связывающую аппаратный адрес с IP
          адрес. Этот IP-адрес клиента затем помещается в поле в
          ответ.
    
          6. Определенные сетевые топологии (например, Стэнфордская) могут быть такими
          что данный физический кабель не имеет напрямую TFTP-сервера
          прикрепленный к нему (e.грамм. все шлюзы и хосты на определенном кабеле
          может быть бездисковым). В сотрудничестве с соседними шлюзами,
          BOOTP может позволить клиентам загружаться с серверов на расстоянии нескольких переходов,
          через эти шлюзы. См. Раздел «Загрузка через
          Шлюзы ниже. Эта часть протокола не требует особого
          действия со стороны клиента. Реализация не является обязательной и
          требует небольшого количества дополнительного кода в шлюзах и
          серверы.
    
    3. Формат пакета
    
       Все указанные числа являются десятичными, если не указано иное.BOOTP
       пакет заключен в стандартную дейтаграмму IP [8] UDP [7]. Для
       Для простоты предполагается, что пакет BOOTP никогда не фрагментируется.
       Все отображаемые числовые поля упакованы в 'стандартном сетевом порядке байтов',
       т.е. биты высокого порядка отправляются первыми.
    
       В IP-заголовке загрузочного запроса клиент заполняет свой собственный IP-адрес.
       адрес источника, если известен, в противном случае - ноль. Когда адрес сервера
       неизвестно, IP-адрес назначения будет "широковещательным адресом"
       255.255.255.255. Этот адрес означает "вещание по локальному кабелю,
       (Я не знаю свой номер сети) »[4].Крофт и Гилмор [Страница 2] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
       Заголовок UDP содержит номера портов источника и назначения. В
       Протокол BOOTP использует два зарезервированных номера порта, «клиент BOOTP» (68).
       и «сервер BOOTP» (67). Клиент отправляет запросы, используя 'BOOTP
       server 'в качестве порта назначения; обычно это трансляция. В
       сервер отправляет ответы, используя «клиент BOOTP» в качестве порта назначения;
       в зависимости от возможностей ядра или драйвера на сервере это может
       или может не быть трансляцией (это объясняется далее в разделе
       под названием «Проблемы с курицей / яйцом» ниже).Причина ДВА зарезервированных порта
       используются, чтобы избежать пробуждения и планирования сервера BOOTP.
       демоны, когда клиенту необходимо транслировать загрузочный ответ. Поскольку
       сервер и другие хосты не будут прослушивать порт 'BOOTP client',
       любые такие входящие широковещательные сообщения будут отфильтрованы ядром
       уровень. Мы не могли просто позволить клиенту выбирать «случайный» порт.
       номер для поля порта источника UDP; поскольку ответ сервера может быть
       широковещательная передача, случайно выбранный номер порта может сбить с толку другие хосты
       что случилось прослушивать этот порт.В поле длины UDP устанавливается длина UDP плюс BOOTP.
       порции пакета. Поле контрольной суммы UDP можно установить на ноль с помощью
       клиент (или сервер) при желании, чтобы избежать этих дополнительных накладных расходов в
       Внедрение PROM. В разделе «Обработка пакетов» под
       фраза "[контрольная сумма UDP.]" используется всякий раз, когда контрольная сумма может быть
       проверено / вычислено.
    
          ПОЛЕ БАЙТОВ ОПИСАНИЕ
          ----- ----- -----------
    
             op 1 код операции / тип сообщения пакета.
                             1 = ЗАПРОС ЗАГРУЗКИ, 2 = ЗАПРОС ЗАГРУЗКИ
    
             htype 1 тип аппаратного адреса,
                             см. раздел ARP в RFC «Назначенные номера».'1' = 10 МБ Ethernet
    
             длина аппаратного адреса hlen 1
                             (например, «6» для Ethernet 10 МБ).
    
             переходы 1 клиент устанавливает в ноль,
                             опционально используется шлюзами
                             при кросс-шлюзовой загрузке.
    
             xid 4 идентификатор транзакции, случайное число,
                             используется для сопоставления этого запроса загрузки с
                             ответы, которые он генерирует.
    
             сек 2 заполняется клиентом, секунды прошли с
                             клиент начал попытки загрузиться.Крофт и Гилмор [Страница 3] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
             - 2 неиспользованных
    
             IP-адрес клиента ciaddr 4;
                             заполняется клиентом в загрузочном запросе, если известно.
    
             yiaddr 4 'ваш' (клиентский) IP-адрес;
                             заполняется сервером, если клиент не
                             знать свой адрес (ciaddr был 0).IP-адрес сервера siaddr 4;
                             вернулся в bootreply сервером.
    
             IP-адрес шлюза giaddr 4,
                             используется при необязательной загрузке через шлюз.
    
             аппаратный адрес клиента chaddr 16,
                             заполняется клиентом.
    
             sname 64 необязательное имя хоста сервера,
                             Строка с завершающим нулем.
    
             файл 128 имя загрузочного файла, строка с нулевым символом в конце;
                             'generic' имя или null в bootrequest,
                             полный путь к каталогу
                             имя в ответе.vend 64 необязательная область, зависящая от поставщика,
                             например может быть аппаратного типа / серийный по запросу,
                             или дескриптор "возможности" / удаленной файловой системы
                             при ответе. Эта информация может быть отложена для использования
                             третьей фазой начальной загрузки или ядра.
    
    4. Проблемы с курицей / яйцом
    
       Как сервер может отправить IP-дейтаграмму клиенту, если клиент
       не знает свой IP-адрес (пока)? Всякий раз, когда отправляется ответ на загрузку
       отправлено, передающая машина выполняет следующие операции:
    
          1.Если клиент знает свой IP-адрес (поле 'ciaddr'
          ненулевое значение), то IP-адрес может быть отправлен «как обычно», поскольку клиент
          ответит на ARP [5].
    
          2. Если клиент еще не знает свой IP-адрес (ciaddr zero),
          тогда клиент не может отвечать на ARP, отправленные передатчиком
          ответ. Есть два варианта:
    
             а. Если в передатчике есть необходимое ядро ​​или драйверы хуков
    
    
    Крофт и Гилмор [Страница 4] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
             «вручную» создать запись кэша адресов ARP, тогда он может
             заполните запись, используя поля «chaddr» и «yiaddr».Из
             конечно, у этой записи должен быть тайм-аут, как и у любой другой
             другая запись сделана самим нормальным кодом ARP. В
             передатчик bootreply может просто отправить bootreply
             на IP-адрес клиента. UNIX (4.2 BSD) имеет это
             возможности.
    
             б. Если в передатчике отсутствуют эти перехватчики ядра, он может просто
             отправьте загрузочный ответ на широковещательный IP-адрес на
             соответствующий интерфейс. Это всего лишь одна дополнительная трансляция
             по сравнению с предыдущим случаем.5. Клиентское использование ARP
    
       Клиентский PROM должен содержать простую реализацию ARP, например в
       адресный кеш может иметь размер всего одну запись. Это позволит
       загрузка только второй фазы (TFTP), которая должна выполняться, когда клиент знает
       IP-адреса и имя загрузочного файла.
    
       Каждый раз, когда клиент ожидает ответа TFTP или BOOTP, он
       должен быть готов ответить на запрос ARP для своего IP-адреса, чтобы
       отображение аппаратных адресов (если известно).
    
       Поскольку bootreply будет содержать (в аппаратной инкапсуляции)
       аппаратный адрес источника сервера / шлюза, клиент МОЖЕТ быть в состоянии
       чтобы избежать отправки ARP-запроса для IP-адреса сервера / шлюза на
       использоваться на следующей фазе TFTP.Однако это следует лечить
       только как частный случай, так как желательно все же разрешить
       загрузка только второй фазы, как описано выше.
    
    6. Сравнение с RARP
    
       Более ранний протокол, протокол обратного разрешения адресов (RARP) [1]
       было предложено позволить клиенту определить свой IP-адрес, учитывая
       что он знает свой аппаратный адрес. Однако у RARP был недостаток
       что это был протокол уровня аппаратного канала (не основанный на IP / UDP). Этот
       означает, что RARP может быть реализован только на хостах, содержащих специальные
       модификации ядра или драйвера для доступа к этим «сырым» пакетам.С
       сейчас существует много сетевых ядер, с каждым источником
       поддерживается разными организациями, протокол загрузки, который не
       требовать модификации ядра - неоспоримое преимущество.
    
       BOOTP предоставляет это оборудование для функции поиска IP-адресов в
       в дополнение к другим полезным функциям, описанным в разделах
       выше.
    
    
    
    Крофт и Гилмор [Страница 5] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
    7.Обработка пакетов
    
       7.1. Клиентская передача
    
          Перед настройкой пакета в первый раз рекомендуется
          очистить весь буфер пакетов до нуля; это поместит
          все поля в их состоянии по умолчанию. Затем клиент создает
          пакет со следующими полями.
    
          IP-адрес назначения установлен на 255.255.255.255. (в
          широковещательный адрес) или на IP-адрес сервера (если известен). В
          IP-адрес источника и 'ciaddr' устанавливаются на IP-адрес клиента.
          если известно, иначе 0.Заголовок UDP имеет правильную длину;
          исходный порт = порт 'BOOTP client' порт назначения = 'BOOTP
          порт сервера.
    
          'op' установлен в '1', BOOTREQUEST. 'htype' установлен на оборудование
          тип адреса, назначенный в разделе ARP «Назначенного
          Числа "RFC." Hlen "устанавливается равной длине аппаратного адреса,
          например «6» для Ethernet 10 МБ.
    
          «xid» устанавливается как «случайный» идентификатор транзакции. 'secs' установлен на
          количество секунд, прошедших с момента запуска клиента
          загрузка.Это позволит серверам узнать, сколько времени у клиента
          пытался. По мере увеличения числа некоторые серверы могут почувствовать
          более «сочувствующий» клиенту, которого они обычно не обслуживают.
          Если у клиента нет подходящих часов, он может составить примерную
          оценить с помощью таймера цикла. Или он может просто отправить
          это поле как всегда фиксированное значение, скажем 100 секунд.
    
          Если клиент знает свой IP-адрес, ciaddr (и IP-адрес источника
          адрес) устанавливаются на это значение.'chaddr' заполняется
          аппаратный адрес клиента.
    
          Если клиент желает ограничить загрузку определенным сервером
          name, он может поместить строку с завершающим нулем в sname. Название
          должно быть любым из допустимых имен или псевдонимов
          желаемый хозяин.
    
          У клиента есть несколько вариантов заполнения поля имени файла.
          Если оставить значение null, это означает: «Я хочу загрузить файл по умолчанию для
          моя машина ». Нулевое имя файла также может означать "Меня интересует только
          при выяснении IP-адресов клиента / сервера / шлюза мне все равно
          насчет имен файлов ».Поле также может быть «общим» именем, например, «unix» или
    
    
    
    Крофт и Гилмор [Страница 6] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
          'шлюз'; это означает «загрузить указанную программу, настроенную для моего
          машина'. Наконец, поле может быть полностью определенным каталогом
          имя пути.
    
          Поле "vend" может быть заполнено клиентом с помощью
          строки или структуры, зависящие от поставщика.Например машина
          Здесь можно указать тип оборудования или серийный номер. Тем не менее
          работа сервера BOOTP не должна зависеть от этого
          информация существует.
    
          Если используется поле vend, рекомендуется 4 байта
          «магический номер» будет первым элементом в «vend». Это позволяет
          сервер определяет, какую информацию он видит в этом
          поле. Номера могут быть присвоены обычным «магическим числом».
          процесс - вы выбираете один, и он волшебный. Другое магическое число
          может использоваться для bootreply, чем bootrequest, чтобы разрешить
          клиент предпримет специальные действия с ответной информацией.[Контрольная сумма UDP.]
    
       7.2. Стратегия повторной передачи клиентов
    
          Если в течение определенного времени ответа не поступает, клиент
          должен повторно передать запрос. Необходимо выбрать временной интервал
          осторожно, чтобы не заливать сеть. Рассмотрим случай
          кабель, содержащий 100 машин, которые только что приближаются после
          сбой питания. Просто ретранслируйте запрос каждые четыре
          секунды затопят сеть.
    
          В качестве возможной стратегии вы можете подумать о том, чтобы отступить
          экспоненциально, подобно тому, как Ethernet отключается на
          столкновение.Так, например, если первый пакет находится в 0:00,
          второй будет в: 04, затем: 08, затем: 16, затем: 32, затем
          : 64. Вы также должны каждый раз рандомизировать; это будет сделано
          аналогично спецификации Ethernet, начиная с маски и
          'и' со случайным числом, чтобы получить первую отсрочку.
          При каждой последующей отсрочке длина маски увеличивается на единицу.
          немного. Это удваивает среднюю задержку при каждой отсрочке.
    
          После того, как «средняя» отсрочка достигнет примерно 60 секунд, она должна быть
          больше не увеличивалось, но все еще рандомизировано.Перед каждой повторной передачей клиент должен обновлять «секунды»
          поле. [Контрольная сумма UDP.]
    
    
    
    
    
    Крофт и Гилмор [Страница 7] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
       7.3. Сервер получает BOOTREQUEST
    
          [Контрольная сумма UDP.] Если порт назначения UDP не соответствует
          Порт «BOOTP server», сбросить пакет.
    
          Если поле имени сервера (sname) равно нулю (нет конкретного сервера
          указано), или имя указано и соответствует нашему имени или
          псевдоним, затем продолжите обработку пакета.Если поле sname указано, но не соответствует 'us', то
          есть несколько вариантов:
    
             1. Вы можете просто отказаться от этого пакета.
    
             2. Если поиск имени по sname показывает, что он подключен к тому же кабелю,
             отказаться от пакета.
    
             3. Если sname находится в другой сети, вы можете перенаправить
             пакет по этому адресу. Если да, проверьте 'giaddr' (шлюз
             адрес) поле. Если "giaddr" равен нулю, заполните его моими
             адрес или адрес шлюза, по которому можно добраться до
             эта сеть.Затем отправьте пакет.
    
          Если IP-адрес клиента (ciaddr) равен нулю, то клиент делает
          не знаю своего IP-адреса. Попытка найти клиента
          аппаратный адрес (chaddr, hlen, htype) в нашей базе данных. Если нет
          найдено совпадение, отбросить пакет. В противном случае теперь у нас есть IP
          адрес этого клиента; введите его в yiaddr (ваш IP
          адрес) поле.
    
          Теперь проверим поле имени загрузочного файла (файл). Поле будет
          null, если клиент не интересуется именами файлов или хочет
          загрузочный файл по умолчанию.Если поле не равно нулю, оно используется как
          ключ поиска в базе данных вместе с IP-адресом клиента. Если
          есть файл по умолчанию или общий файл (возможно, проиндексированный
          адрес клиента) или полностью указанный путь, который соответствует, тогда
          замените поле 'file' на полностью указанный путь к файлу
          выбранный загрузочный файл. Если поле не равно нулю и совпадений не было
          найдено, то клиент запрашивает файл, которого у нас нет; отказаться
          пакет, возможно, он будет у другого сервера BOOTP.Поле данных поставщика "vendor" теперь должно быть проверено, и если
          предоставляется распознанный тип данных, действия, специфичные для клиента
          должны быть приняты, и ответ помещен в поле данных "vend"
          ответный пакет. Например, клиент рабочей станции может предоставить
    
    
    
    
    Крофт и Гилмор [Страница 8] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
          ключ аутентификации и получить от сервера возможность
          удаленный доступ к файлам или набор параметров конфигурации, которые могут
          будут переданы в операционную систему, которая вскоре будет загружена.Поместите мой (серверный) IP-адрес в поле siaddr. Установите 'op'
          поле для BOOTREPLY. Порт назначения UDP установлен на 'BOOTP
          клиент ». Если адрес клиента 'ciaddr' не равен нулю, отправьте
          пакет там; иначе, если адрес шлюза 'giaddr' не равен нулю, установите
          порт назначения UDP на «сервер BOOTP» и отправить пакет на
          'giaddr'; иначе клиент подключен к одному из наших кабелей, но это не так.
          еще не знаете свой IP-адрес - воспользуйтесь методом, описанным в разделе "Яйцо"
          раздел выше, чтобы отправить его клиенту.Если используется «Яйцо», и мы
          иметь несколько интерфейсов на этом хосте, используйте yiaddr (ваш IP
          адрес), чтобы определить, какую сеть (кабель / интерфейс) отправлять
          пакет в. [Контрольная сумма UDP.]
    
       7.4. Сервер / шлюз получает BOOTREPLY
    
          [Контрольная сумма UDP.] Если 'yiaddr' (ваш [клиентский] IP-адрес)
          относится к одному из наших кабелей, воспользуйтесь одним из описанных выше методов "Яйцо", чтобы
          пересылаем клиенту. Обязательно отправьте его в 'BOOTP
          клиентский порт назначения UDP.
    
       7.5. Прием клиентов
    
          Не забывайте обрабатывать ARP-запросы для моего собственного IP-адреса (если я
          знаю это).[Контрольная сумма UDP.] Клиент должен отклонять входящие
          пакеты, которые: не являются IP / UDP, адресованными загрузочному порту; не
          BOOTREPLYs; не совпадают с моим IP-адресом (если я его знаю) или моим
          аппаратный адрес; не соответствуют моему идентификатору транзакции. В противном случае мы
          получили успешный ответ. yiaddr будет содержать мой IP
          адрес, если я не знал его раньше. "файл" - это имя
          имя файла для TFTP 'запрос на чтение'. Адрес сервера находится в
          'siaddr'. Если 'giaddr' (адрес шлюза) отличен от нуля, то
          пакеты должны быть отправлены туда в первую очередь, чтобы добраться до
          сервер.8. Загрузка через шлюзы.
    
       Эта часть протокола не является обязательной и требует дополнительных
       код в взаимодействующих шлюзах и серверах, но он позволяет кросс-шлюз
       загрузка. Это в основном полезно, когда шлюзы являются бездисковыми машинами.
       Шлюзы, содержащие диски (например, машина UNIX, выступающая в качестве шлюза),
       с таким же успехом могут запускать свои собственные серверы BOOTP / TFTP.
    
       Шлюзы, прослушивающие широковещательные запросы BOOTREQUEST, могут решить перенаправить или
       ретранслируйте эти запросы «при необходимости». Например,
    
    
    Крофт и Гилмор [Страница 9] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
       шлюз мог иметь в составе своих конфигурационных таблиц список
       другие сети или хосты для получения копии любой трансляции
       ЗАПРОСЫ.Несмотря на то, что поле «хмеля» существует, это плохая идея.
       просто глобально ретранслировать запросы, поскольку широковещательные петли
       почти наверняка произойдет.
    
       Пересылка может начаться немедленно или подождать, пока "сек"
       (в секундах, в которых клиент пытается) пройти определенный порог.
    
       Если шлюз все же решит переадресовать запрос, он должен посмотреть на
       поле giaddr (IP-адрес шлюза). Если ноль, он должен заглушить
       собственный IP-адрес (на приемном кабеле) в это поле. Это может также
       используйте поле 'hops', чтобы дополнительно контролировать, как далеко находится пакет
       перенаправлен.Число прыжков следует увеличивать при каждой пересылке. Для
       Например, если переход проходит через «3», пакет, вероятно, следует отбросить.
       [Контрольная сумма UDP.]
    
       Здесь мы рекомендовали разместить эту специальную функцию переадресации в
       шлюзы. Но это не обязательно. Так долго как
       какой-то «агент пересылки BOOTP» существует в сети с загрузкой
       клиент, агент может выполнить переадресацию, когда это необходимо. Таким образом, это
       сервис может быть совмещен со шлюзом, а может и нет.
    
       В случае если агент пересылки не находится на шлюзе,
       агент может сэкономить немного времени, подключив широковещательный адрес
       интерфейса, получающего загрузочный запрос в поле 'giaddr'.Таким образом, ответ будет пересылаться с использованием обычных шлюзов, а не
       с участием экспедитора. Конечно, недостатком здесь является
       что вы теряете возможность использовать нешироковещательный метод "Яйцо"
       отправка ответа, вызывающая дополнительные накладные расходы для каждого хоста на
       клиентский кабель.
    
    9. Пример базы данных сервера BOOTP.
    
       В качестве предложения мы показываем образец базы данных текстового файла, который BOOTP
       серверная программа может использовать. База данных состоит из двух разделов, разделенных
       строкой, содержащей процент в столбце 1.Первый раздел
       содержит «каталог по умолчанию» и сопоставления от общих имен к
       каталог / пути. Первое общее название в этом разделе - это
       'файл по умолчанию', который вы получаете, когда запрос загрузки содержит нулевой 'файл'
       нить.
    
       Во втором разделе тип / адрес оборудования сопоставляется с
       айпи адрес. При желании вы также можете переопределить общее имя по умолчанию
       путем указания универсального имени для конкретного ip-адреса. Элемент "суффикс"
       тоже вариант; если предоставлено, любые общие имена, указанные в
       клиент будет доступен, сначала добавив суффикс к имени пути
    
    
    Крофт и Гилмор [Страница 10] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
       соответствующий этому родовому названию.Если этот файл не найден, тогда
       будет использоваться простое "имя пути". Эта опция «суффикс» позволяет
       полный набор настраиваемых универсальных шаблонов, которые можно настроить без особых усилий.
       Ниже показан общий формат; поля разделены одним или
       больше пробелов или табуляции; завершающие пустые поля могут быть опущены; пустой
       строки и строки, начинающиеся с символа "#", игнорируются.
    
          # строка комментария
    
          домашний каталог
          genericname1 pathname1
          genericname2 pathname2
          ...
    
          % конец общих имен, начало сопоставления адресов
    
          hostname1 hardwaretype hardwareaddr1 ipaddr1 суффикс универсального имени
          hostname2 hardwaretype hardwareaddr2 ipaddr2 суффикс универсального имени
          ...
    
       Вот конкретный пример. Обратите внимание, что номер типа оборудования - это
       то же, что показано в разделе ARP RFC «Назначенные номера».
       Числа "hardwaretype" и "ipaddr" даны в десятичном формате;
       "hardwareaddr" - в шестнадцатеричном формате.
    
          # последнее обновление смит
    
          / usr / boot
          vmunix vmunix
          наконечник ethertip
          смотреть / usr / diag / etherwatch
          ворота ворота.
    
          % конец общих имен, начало сопоставления адресов
    
          Гамильтон 1 02.60.8c.06.34.98 36.19.0.5
          заусенец 1 02.60.8c.34.11.78 36.44.0.12
          101-шлюз 1 02.60.8c.23.ab.35 36.44.0.32 шлюз 101
          mjh-шлюз 1 02.60.8c.12.32.bc 36.42.0.64 шлюз mjh
          Welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 наконечник
          welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 наконечник
    
       В приведенном выше примере, если "mjh-gateway" выполняет загрузку по умолчанию, он будет
       получите файл '/usr/boot/gate.mjh'.
    
    
    
    
    
    Крофт и Гилмор [Страница 11] 

    RFC 951, сентябрь 1985 г.
    Протокол начальной загрузки
    
    
    10.Благодарности
    
       Росс Финлейсон (и др.) Подготовил два более ранних RFC, посвященных TFTP.
       загрузка [2] с использованием RARP [1].
    
       Мы также хотели бы поблагодарить за предыдущую работу и комментарии
       Ноэль Чиаппа, Боб Лайон, Джефф Могул, Марк Льюис и Дэвид Пламмер.
    
    РЕКОМЕНДАЦИИ
    
       1. Росс Финлейсон, Тимоти Манн, Джеффри Могул, Марвин Таймер. А
           Протокол обратного разрешения адресов. RFC 903, NIC, июнь 1984 г.
    
       2. Росс Финлейсон. Загрузка начальной загрузки с использованием TFTP. RFC 906, сетевая карта,
           Июнь 1984 г.3. Марк Лоттор. Простой протокол передачи файлов. RFC 913, сетевая карта,
           Сентябрь 1984 г.
    
       4. Джеффри Могул. Широковещательные Интернет-пакеты. RFC 919, сетевая карта,
           Октябрь 1984 г.
    
       5. Дэвид Пламмер. Протокол разрешения адресов Ethernet. RFC
           826, NIC, сентябрь 1982 г.
    
       6. Джон Постел. Протокол передачи файлов. RFC 765, NIC, июнь 1980 г.
    
       7. Джон Постел. Протокол пользовательских датаграмм. RFC 768, NIC, август 1980 г.
    
       8. Джон Постел. Протокол Интернета. RFC 791, NIC, сентябрь 1981 г.9. К. Р. Соллинз, Ноэль Чиаппа. Протокол TFTP. RFC 783, сетевая карта,
           Июнь 1981 г.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Крофт и Гилмор [Страница 12]
     

    bootix ::: FAQ ::: Сетевая загрузка

    FAQ ::: Сетевая загрузка

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

    Вопросы

    1. Что именно такое «Сетевая загрузка»?
    2. Какие протоколы обычно используются для загрузки по сети?
    3.В чем разница между PXE, DHCP, BOOTP и TFTP?
    4. Как подключить настольные, портативные и серверные компьютеры к сети? ботинок?
    5. Какие операционные системы можно загружать по сети?
    6. Какие операционные системы требуются на стороне сервера?
    7. Какие службы требуются на сервере сетевой загрузки?
    8. Какие аппаратные архитектуры поддерживаются?
    9. Какие сетевые адаптеры поддерживаются?
    10. Что я должен учитывать в маршрутизируемых сетях, VLAN, WAN и т. Д.?
    11.Могу ли я загружать по сети несколько машин одновременно?

    ответов

    1. Что такое «Сеть» Загрузочный?

    Термин «сетевая загрузка» описывает процесс загрузки компьютера (настольного компьютера, ноутбука или сервера) из сетевой сервер. Для этого компьютер должен быть оснащен кодом сетевой загрузки, например как код TCP / IP BOOT-PROM или PXE PROM. Этот метод можно использовать для предоставления бездисковые компьютеры с операционной системой, загружаемой из сети, и их в «Тонких клиентов».Также он используется для автоматической установки. целей, где «помощник операционная система «загружается по сети и служит платформой для установщика операционной системы. Более того, этот метод можно использовать в экстренных случаях. сценарии загрузки, при которых аварийная операционная система загружается через сеть для выполнения мероприятия по техническому обслуживанию, такие как автономное сканирование на вирусы, обновление прошивки, и т.д. Вернуться к обзору FAQ

    2. Какие протоколы обычно используются для сети загрузка?

    Для загрузки по сети обычно используются протоколы PXE, DHCP, BOOTP и TFTP.В современном настольные компьютеры, ноутбуки и серверы с чипсетами LAN-On-Motherboard, вы, скорее всего, обнаружите, что эти машины уже оснащены с кодом загрузки сети PXE. Вернуться к обзору часто задаваемых вопросов

    3. В чем разница между PXE, DHCP, BOOTP и TFTP?

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

    DHCP (протокол динамической конфигурации хоста) является преемником в BOOTP, добавляет динамическое назначение IP-адресов, понятие «IP аренда »и другие улучшения.

    TFTP (простой протокол передачи файлов) — это стандартизированный, независимый от производителя протокол, который позволяет загружающемуся компьютеру загружать файл сетевой загрузки с TFTP-сервера.

    PXE (Preboot eXecution Environment) является отраслевым стандартом. протокол, который построен на основе DHCP и TFTP для реализации общий метод сетевой загрузки, а также предоставляет «API сетевой загрузки», может использоваться загруженным файлом сетевой загрузки для выполнения дополнительных функции, связанные с сетевой загрузкой. Вернуться к FAQ обзор

    4. Как включить настольные, портативные и сервера для сетевой загрузки?

    Если ваши машины уже оснащены сетевой загрузкой code, активируйте этот код в настройках системы компьютера.Для машин которые не поставляются с кодом сетевой загрузки, bootix предоставляет дополнительную сеть загрузочный код, который может быть доставлен в виде физических PROM, запрограммированных в существующее устройство флэш-памяти, а также интегрированное в машины Системный BIOS. Вернуться к обзору часто задаваемых вопросов

    5. Какие операционные системы можно загружать по сети?

    Вы можете загружать разные версии DOS, Windows 98, Windows PE 2005 (x86 и x64), Windows PE 2.0 (x86 и x64), BartPE и Linux изображения по сети. Также есть возможность загрузить дополнительные кастомные операционные системы. Вернуться к обзору часто задаваемых вопросов

    6. Какие операционные системы требуются на стороне сервера?

    На стороне сервера нет конкретной операционной системы нужный. Единственное требование — сервер «говорит» TCP / IP, и размещает сервисы для соответствующих протоколов, например DHCP и сервис TFTP.Вернуться к обзору часто задаваемых вопросов

    7. Какие услуги требуются на сервер сетевой загрузки?

    Вам нужен DHCP (или BOOTP), а также служба TFTP. на сервере сетевой загрузки. Эти службы могут работать на на том же сервере или на разных серверах. Назад к обзору FAQ

    8. Что такое аппаратные архитектуры? поддерживается?

    На стороне сервера оборудование архитектура не имеет значения, если она может содержать вышеупомянутые службы сетевой загрузки.На стороне загрузочной машины по сети все Поддерживаются архитектуры, совместимые с Intel x86, в том числе 64-битные. архитектуры x64. Вернуться к обзору часто задаваемых вопросов

    9. Какие сетевые адаптеры поддерживаются?

    В основном все сетевые адаптеры могут быть включены для загрузки по сети, если у них есть средства хранения сетевой загрузочный код, то есть пустой сокет загрузочного окна, в который загружается Пром может быть вставлен, или встроенное устройство FLASH, которое может быть запрограммировано с кодом сетевой загрузки.Для машин LANOnBoard надстройка загрузочный код может быть интегрирован в системный BIOS. Посмотреть список поддерживаемых сетевых адаптеров и наборы микросхем, чтобы узнать, поддерживается ли ваш конкретный адаптер или набор микросхем пользователя bootix. Вернуться к обзору часто задаваемых вопросов

    10. Что нужно учитывать при роутинге сети, VLAN, WAN и т. д.?

    В принципе, выполнить загрузку по сети не проблема. через VLAN, маршрутизаторы и даже WAN. Протоколы DHCP, BOOTP и PXE работают на основе вещания и нуждаются в специальной поддержке (Вспомогательные IP-адреса, серверы пересылки DHCP / BOOTP и т. Д.) когда загрузка должен происходят через подсеть (широковещательная домена) границы. TFTP не основан на широковещании и может прозрачно использоваться в маршрутизируемых средах. Однако по соображениям производительности рекомендуется использовать локальные серверы TFTP. Назад к обзору FAQ

    11. Могу ли я загружать по сети несколько машин? одновременно?

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

    Как работает BOOTP

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

    Операция начальной загрузки происходит в два этапа. Во-первых происходит этап, определение адреса и выбор загрузочного файла. Этот Фаза использует сервер BOOTP, bootpd. После получения информации об адресе и имени файла, управление переходит ко второй фазе начальной загрузки, где передача файла имеет место. На этом этапе используется TFTP-сервер tftpd.

    Определение адреса и выбор загрузочного файла

    Первая фаза включает bootrequest пакет который транслируется клиентом BOOTP.Сервер BOOTP, который получает bootrequest может отправить bootreply на client, если он находит информацию о загрузке клиента в своей базе данных. Или он может ретранслировать загрузочный запрос на другие серверы BOOTP, если обнаружит ретранслировать информацию для клиента в его базе данных.

    1. Клиент BOOTP формулирует загрузочный запрос, который будет транслироваться. Перед отправляя загрузочный запрос, клиент выполняет следующие действия:

      • Устанавливает поле переходов в пакете bootrequest равным 0.Каждый раз сервер BOOTP передает загрузочный запрос клиента, поле переходов увеличивается на 1. Если значение переходов превышает настроенное максимальное значение переходов для этого клиента на сервере BOOTP запрос загрузки отбрасывается. Значение hops ограничивает количество загрузочных запросов. может быть ретранслирован.

      • Устанавливает в поле secs пакета bootrequest значение 0 для первого запроса. Если клиент не получает ответа на этот запрос, он устанавливает значение этого поля к количеству секунд с момента первого запроса было отправлено.Если значение поля секунд меньше настроенного порогового значения для этого клиента на сервере BOOTP запрос загрузки отбрасывается. В пороговое значение гарантирует, что достаточно времени для ответа загрузки должен быть получен клиентом перед последующим загрузочным запросом для ретранслируется тот же клиент.

      • Устанавливает в поле giaddr (IP-адрес шлюза) значение 0. Если сервер BOOTP обнаруживает, что это поле равно 0, он заполняет его собственным IP-адресом.

    2. Клиент передает пакет bootrequest на его первый интерфейс LAN (lan0).Загрузочный запрос также содержит клиентский аппаратный адрес и, если он известен, его IP-адрес.

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

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

      • Превышает ли значение прыжков в пакете bootrequest максимальное настроил для клиента? Если это так, запрос отбрасывается. Если нет, поле переходов в пакете bootrequest увеличивается.

      • Значение в секундах в пакете bootrequest меньше порог настраивал на сервере для клиента? Если это так, то запрос отброшен.

      Если запрос не был отброшен во время вышеуказанных проверок, затем сервер передает запрос на загрузку на сервер (ы) BOOTP, который были настроены для клиента. Если поле giaddr пакета bootrequest равно 0, сервер помещает свой IP-адрес в поле.

    Шаги 3 и 4 повторяются до тех пор, пока не будет выполнен загрузочный запрос. полученный сервером BOOTP, который находит загрузочную информацию о клиент в своей базе данных, или запрос отброшен.

    Когда сервер находит информацию клиента о конкретном клиент в своей базе данных, сервер отвечает на загрузочный запрос с пакет bootreply. IP-адрес клиента помещается в поле в bootreply. Загрузочный ответ также может содержать файл имя загрузочного файла, который клиент должен загрузить с помощью TFTP. Другой информация, которая может быть включена в загрузочный ответ, является клиентской маска подсети, адреса серверов имен и адреса шлюзы.

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

    Рисунок 5-1 «Реле запроса загрузки. Пример »показывает пример загрузочного запроса. который передается с сервера A на сервер B на сервер C. Сервер C находит загрузочную информацию клиента в своей базе данных, и отправляет загрузочный ответ обратно на сервер A.Затем сервер A отправляет загрузочный ответ клиенту.

    Рисунок 5-1 Реле запроса загрузки Пример:

    Передача файлов

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

    BOOTP (протокол BOOTstrap) (термин ссылки)

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

    BOOTP Расширен возможности RARP (протокол обратного разрешения адресов. RARP получает только IP-адрес. BOOTP получает IP-адрес, адрес шлюза и адрес сервера имен. BOOTP предназначен для локальных и мостовых сетей. Его можно использовать в маршрутизируемых сетях). межсетевые, если маршрутизаторы поддерживают пересылку BOOTP.

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

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

    Обратите внимание, что администраторы должны вручную настроить информацию на сервере BOOTP. IP-адрес должен совпадать с MAC-адресами (управление доступом к среде) компьютеров в сети.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *