Кратко

  • RFC 1542 требует направлять все BOOTREQUEST одного клиента к одному адресу или набору адресов назначения.
  • В документе описан ретранслятор с циклическим распределением: последовательные запросы одного клиента могли попадать на разные серверы.
  • Стабильное распределение по идентификатору клиента позволяет балансировать нагрузку, сохраняя вместе сообщения одного обмена.

Как запрос выходил за пределы локальной сети

BOOTP предназначался для устройств, которые при запуске могли не знать ни своего IP-адреса, ни сервера с параметрами загрузки. RFC 951, опубликованный в 1985 году, описывал начальный этап определения адреса и выбора файла загрузки. Клиент мог передать BOOTREQUEST широковещательно в локальном сегменте. Если сервер находился в другой сети, обычная IP-маршрутизация не переносила этот локальный широковещательный запрос к нему автоматически.

Поэтому RFC 951 допускал загрузку через взаимодействующие шлюзы. Такая функция была необязательной: она могла работать на шлюзе или на другом агенте в сети клиента. Агент принимал BOOTREQUEST, при необходимости заполнял giaddr адресом интерфейса и увеличивал hops. Поле giaddr давало серверу путь для ответа в сеть клиента. Ранний стандарт описал механизм, но оставил поведение ретранслятора определённым лишь в общих чертах.

RFC 1532 попытался уточнить BOOTP в октябре 1993 года. В том же месяце вышел RFC 1542: он обновил RFC 951 и заменил RFC 1532, поскольку при редакционной подготовке последнего появились ошибки. В аннотации RFC 1542 поведение агентов ретрансляции названо одной из областей, требующих более точной спецификации. Ретранслятор стал рассматриваться как участник обмена, чьё решение может сохранить или разделить последовательность сообщений.

Не менять сервер для каждого запроса

RFC 1542 оставил операторам пространство для настройки. Механизм включения и отключения ретрансляции обязателен, а начальное состояние должно быть отключённым. Запросы с hops выше 16 необходимо отбрасывать; администратору следует дать возможность установить меньший порог. Если giaddr равен нулю, агент должен указать адрес интерфейса, на который пришёл запрос, увеличить hops и сохранить остальные поля BOOTP. Список адресов назначения также задаётся конфигурацией.

Но для каждого отдельного клиента действует обязательное условие: все его BOOTREQUEST должны пересылаться на один и тот же адрес или набор адресов назначения. В пояснении RFC упоминается как минимум одна известная реализация с балансировкой по кругу. Получив новый запрос, она выбирала следующий сервер BOOTP из списка. Поэтому соседние запросы одного клиента могли прибыть на разные машины.

Проблема состояла не в нескольких серверах, а в выборе по каждому пакету, хотя протокол мог требовать нескольких связанных запросов и ответов. RFC 1542 объясняет, что такая схема плохо работает с DHCP и, возможно, с другими вариантами BOOTP, которым нужны повторные обмены. Если первый шаг видит один сервер, а следующий — другой, необходимый для продолжения контекст может оказаться разделённым. Документ описывает протокольный риск, но не фиксирует конкретный сбой и не оценивает распространённость подобной реализации.

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

Границы гарантии

RFC 1542 не обещает доступность серверов, синхронизацию их состояния или успешную загрузку клиента. Он ограничивает только выбор адреса ретрансляции для запросов одного клиента. Требования направлять всех клиентов на один сервер тоже нет: допускается набор назначений и стабильное распределение по клиентам.

Опубликованный в октябре 1993 года RFC 1534 описал взаимодействие BOOTP и DHCP, чьи сообщения основаны на формате BOOTP. RFC 2131 (1997 год) позднее подробнее изложил этапы DHCP: клиент обнаруживает серверы, получает предложения, выбирает сервер и отправляет дальнейшие запросы. Это помогает понять, зачем обмену могла понадобиться последовательность сообщений, но не доказывает, что пример кругового распределения из RFC 1542 привёл к реальному аварийному случаю.

RFC Editor указывает одну проверенную поправку к RFC 1542. В §3.1.1, в описании широковещательного флага, слово BOOTREPLY заменяется на BOOTREQUEST. Этот фрагмент не связан с правилом выбора назначения из §4.1.1 и не меняет его.

Историческая граница проста: распределять клиентов между серверами можно, а менять сервер для каждого пакета одного клиента рискованно, если обмен состоит из нескольких этапов. RFC 1542 закрепил это требование, оставив включение ретрансляции и способ стабильного распределения локальному оператору.

Источники