46666 (571844), страница 2
Текст из файла (страница 2)
Отделение ВООТР от механизма пересылки образа операционной системы обладает тем преимуществом, что сервер ВООТР не обязан работать на том компьютере, на котором хранятся образы операционных систем (то есть сервере TFTP). Кроме того, это позволяет использовать ВООТР в ситуациях, когда с сервера принимаются только данные конфигурации, без пересылки образа операционной системы.
Возможна ситуация, в которой администратор настраивает рабочую станцию на загрузку разных операционных систем в зависимости от пользователя. В этом случае запрос ВООТР может содержать в поле имени файла обобщенное обозначение - например, "unix" для принятия образа операционной системы Unix, или "default" для загрузки образа операционной системы по умолчанию.
Столкнувшись с таким обобщенным запросом, сервер ВООТР обращается к конфигурационной базе данных, находит полностью определенное имя файла и возвращает его в ответе ВООТР. Клиент ВООТР может передать полностью определенное имя локальному клиенту TFTP для принятия образа операционной системы.
1.6 Дополнительные данные
В формате сообщения ВООТР явно заданы стандартные параметры IP. Многие поставщики оборудования передают своим устройствам дополнительные параметры. Для таких случаев в сообщения ВООТР было включено поле дополнительных данных.
В поле vendor сообщения ВООТР клиенту передаются данные, интерпретация которых определяется поставщиком оборудования. Поле не является обязательным, а его применение зависит от того, какая дополнительная информация нужна клиенту ВООТР. Первые четыре октета содержат "волшебное число" - признак формата остальных полей. Эти четыре октета задаются в десятичной записи с точечным разделением (не путайте их с IP-адресами!). Скажем, произвольно выбранная последовательность 99.130.83.99 (в шестнадцатеричной записи - 63.82.53.63) является общепринятым обозначением стандартного формата области дополнительных данных. За признаком формата перечисляются элементы, каждый из которых характеризуется следующими атрибутами:
метка (1 октет)
длина следующего поля данных (1 октет)
данные (переменная длина)
Метки элементов ВООТР описаны в RFC 1497, "ВООТР Vendor Information
Extensions". С появлением протокола DHCP дополнительные данные ВООТР и поле параметров DHCP были приведены к общему формату, описанному в RFC 2132, "DHCP Options and BOOTP Vendor Extensions". Некоторые часто используемые значения меток приведены в табл.2 "Стандартные метки дополнительных данных ВООТР".
| Метка | Длина данных | Интерпретация |
| 0 | - | Используется только в целях выравнивания, чтобы следующие поля начинались с границы слова |
| 1 | 4 | Маска подсети |
| 2 | 4 | Смещение географической зоны, в которой находится подсеть клиента, от стандартного времени UTC (Coordinated Universal Time). Смещение выражается 32-разрядным целым числом со знаком |
| 3 | N | Список IP-адресов маршрутизаторов в подсети клиента. Маршрутизаторы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 4 | N | Маска подсети |
| 5 | N | Список серверов имен (IEN 116), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 6 | N | Список серверов DNS (STD 13, EFC 1035), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 7 | N | Список журнальных серверов (MIT-LCS UDP), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 8 | N | Список серверов cookie (RFC 865), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 9 | N | Список серверов построчной печати LPR (RFC 1179), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 10 | N | Список серверов Imagen Impress, доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 11 | N | Список серверов местонахождения ресурсов (RFC 887), доступных для клиента. Серверы перечисляются в порядке предпочтительности. Минимальная длина списка равна 4 октетам, а общая длина должна быть кратна 4 |
| 12 | N | Имя хоста, соответствующее данному клиенту, с возможным уточнением имени локального домена. Допустимые символы описаны в RFC 1035. Минимальная длина поля данных равна 1 октету |
| 13 | N | Размер загрузочного файла. Определяет длину загрузочного образа, используемого клиентом по умолчанию, в 512-килобайтных блоках. Длина файла задается 16-разрядным целым числом без знака |
| 128-254 | Не определена | Интерпретация зависит от реализации |
| 255 | - | Признак конца информации в поле дополнительных параметров. Дальнейшие октеты должны быть заполнены нулями |
2. Динамическая настройка (DHCP)
Протокол DHCP (Dynamic Host Configuration Protocol) является расширением протокола ВООТР и обладает более гибкими возможностями управления IP-адресами. DHCP может использоваться для динамической настройки основных параметров TCP/IP хостов (рабочих станций и серверов), работающих в сети.
Протокол DHCP состоит из двух компонентов:
механизм назначения IP-адресов и других параметров TCP/IP
протокол согласования и передачи информации о хостах Хост, запрашивающий данные о конфигурации TCP/IP, называется клиентом DHCP, а хост TCP/IP, предоставляющий эту информацию, называется сервером DHCP. Протокол DHCP описан в RFC 2131, "Dynamic Host Configuration Protocol".
2.1 Распределение IP-адресов в DHCP
В DHCP используются три способа назначения IP-адресов:
ручное назначение автоматическое назначение динамическое назначение При ручном назначении IP-адрес клиента DHCP вводится вручную сетевым администратором на сервере DHCP, после чего передается клиенту через протокол DHCP.
При автоматическом назначении ручная настройка адресов не нужна. Клиент DHCP получает IP-адрес при первом обращении к серверу DHCP. IP-адреса, назначенные этим способом, закрепляются за клиентом DHCP и не используются другими клиентами DHCP.
При динамическом назначении клиент получает IP-адрес на временной основе или "арендует" его на определенный срок. По истечении этого срока IP-адрес отзывается, и клиент DHCP должен перестать его использовать. Если клиент DHCP по-прежнему нуждается в IP-адресе для выполнения своих функций, он должен запросить другой адрес.
Из трех описанных методов только динамическое назначение позволяет организовать автоматическое повторное использование IP-адресов. Если клиент DHCP перестает использовать IP-адрес (например, при корректном отключении компьютера), он возвращает его серверу DHCP. После этого сервер DHCP может назначить тот же IP-адрес другому клиенту DHCP, обратившемуся с запросом на получение адреса.
Метод динамического назначения адресов особенно удобен для клиентов DHCP, нуждающихся в IP-адресе для временного подключения к сети. Для примера рассмотрим сеть класса С, к которой могут подключаться до 300 мобильных пользователей с портативными компьютерами. Сеть класса С может содержать до 253 узлов B55 - 2 специальных адреса = 253). Поскольку компьютеры, подключающиеся к сети через TCP/IP, должны обладать уникальными IP-адресами, все 300 компьютеров не могут подключиться к сети одновременно. Тем не менее, если в любой момент времени в сети возможно не более 200 физических подключений, появляется возможность переназначения неиспользуемых адресов класса С за счет применения механизма динамического назначения адресов DHCP.
Динамическое назначение адресов также хорошо подходит для назначения IP-адресов новым хостам с постоянным подключением в ситуациях, когда свободных адресов не хватает. По мере отключения из сети старых хостов их IP-адреса могут немедленно назначаться новым хостам.
Какой бы из трех способов назначения IP-адресов ни был избран, вы все равно сможете один раз настроить параметры IP на центральном сервере DHCP вместо того, чтобы повторять настройку конфигурации TCP/IP для каждого компьютера по отдельности.
2.2 Назначение IP-адресов в DHCP
Обратившись с запросом к серверу DHCP, клиент DHCP проходит ряд внутренних стадий, во время которых он согласовывает с сервером срок и область использования IP-адреса. Процесс получения IP-адреса клиентом DHCP лучше всего объяснить на диаграмме переходов (то есть конечного автомата). На Рис.6 "Диаграмма переходов для протокола DHCP, поясняющая процесс взаимодействия между клиентом и сервером" изображена диаграмма, поясняющая процесс взаимодействия между клиентом и сервером DHCP.
При первом запуске клиент DHCP находится в состоянии ИНИЦИАЛИЗАЦИЯ. На этой стадии клиент DHCP еще не знает своих параметров IP, поэтому он рассылает запрос DHCPDISCOVER, инкапсулированный в пакете UDP/IP. В пакете указан приемный порт UDP 67 (десят) - такой же, как у сервера ВООТР, потому что протокол DHCP является расширением ВООТР. В пакете DHCPDISCOVER используется адрес локальной рассылки 255.255.255.255. Если серверы DHCP находятся за пределами локального сегмента, на маршрутизаторе IP должен работать агент-ретранслятор, который перешлет запрос DHCPDISCOVER в другие подсети. Поддержка агентов-ретрансляторов DHCP рассматривается в RFC 1542.
Прежде чем рассылать запрос DHCPDISCOVER, клиент DHCP выдерживает паузу случайной продолжительности от 1 до 10 секунд. Это делается для того, чтобы предотвратить одновременное начало работы клиентов DHCP при их одновременном включении (как иногда происходит после сбоя питания).
После рассылки запроса DHCPDISCOVER клиент DHCP входит в состояние ВЫБОР. В этом состоянии клиент DHCP получает сообщения DHCPOFFER от серверов DHCP, настроенных для ответа этому клиенту. Период времени, в течение которого клиент DHCP ожидает сообщения DHCPOFFER, зависит от реализации. Если клиент получает сразу несколько ответов DHCPOFFER, он должен выбрать один из них. Выбрав сообщение DHCPOFFER от одного из серверов, клиент DHCP посылает этому серверу сообщение DHCPREQUEST. Сервер DHCP отвечает сообщением DHCPACK.
Дополнительно клиент DHCP может проверить IP-адрес, переданный в сообщении DHCPACK, и убедиться в том, что этот адрес не используется. В сетях с широковещательной рассылкой клиент DHCP может отправить по указанному адресу запрос ARP и проверить наличие ответа ARP. Получение ответа ARP означает, что предложенный IP-адрес уже используется; в этом случае ответ DHCPACK от сервера игнорируется, отправляется ответ DHCPDECLINE, а клиент DHCP переходит в исходное состояние ИНИЦИАЛИЗАЦИЯ и пытается получить свободный IP-адрес. При рассылке запроса ARP в локальной сети клиент указывает в пакете ARP собственный аппаратный адрес в поле аппаратного адреса отправителя, но в поле IP-адреса отправителя заносится нулевое значение. Нулевой IP-адрес используется вместо предложенного IP-адреса, чтобы избежать возможной путаницы с кэшами ARP других хостов TCP/IP (в том случае, если предложенный IP-адрес уже используется).
Когда клиент получает от сервера DHCP сообщение DHCPACK, он определяет три временных интервала и переходит в состояние ПРИВЯЗКА. Первый интервал Т1 определяет срок возобновления аренды; второй интервал Т2 определяет срок повторной привязки; третий интервал ТЗ определяет продолжительность аренды.
С сообщением DHCPACK всегда возвращается значение ТЗ, то есть продолжительность аренды. Значения Т1 и Т2 настраиваются на сервере DHCP, а если они не были заданы, используются значения по умолчанию, основанные на продолжительности срока аренды, рассчитанные по следующим формулам:
Т1 = интервал возобновления Т2 = интервал повторной привязки ТЗ = продолжительность аренды Т1 = 0,5 х ТЗ
Т2 = 0,875 х ТЗ
Моменты времени, в которые происходит тайм-аут, вычисляются прибавлением интервала ко времени отправки сообщения DHCPREQUEST, по которому было сгенерировано подтверждение DHCPACK.
Если запрос DHCP был отправлен в момент ТО, то моменты тайм-аута по всем трем интервалам вычисляются по следующим формулам:
тайм-аут по Т1 = ТО + Т1
тайм-аут по Т2 - ТО + Т2
тайм-аут по ТЗ в ТО + ТЗ
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
