Dhcp ретранслятор что это
Практические аспекты использования DHCP relay+option82
В этой статье я хотел бы осветить практические аспекты использования DHCP relay+option82 как возможность авторизации (в дальнейшем именно эта связка будет иметься ввиду), а так же привести примеры конфигурации свитча Dlink DES-3200-10 и isc-dhcp-server. Практически во всех статьях dhcp relay трактуют так: «можно вынести dhcp-сервер за пределы широковещательного домена». Однако почему-то не упоминают или почти не упоминают, что это хорошая возможность избавиться от широковешательных запросов в пределах того же самого широковешательного домена. И самое главное, на что акцентирую внимание — мы можем быть уверены, благодаря option82, что запрос пришёл именно со свитча с заданным маком и именно с порта с указанным номером, а следовательно — таким образом можно «авторизовать» пользователя.
Я немного позанудствую и напомню, как действует DHCP relay. Он перехватит широковещательный запрос (VLAN-а, на который он настроен), обернёт его в L3 и отправит unicast-ом указанному DHCP-серверу. Ну и не лишним будет напомнить, что делаетoption82. Она добавляет в DHCP-пакет два дополнительных параметра:
DHCP-Relay-Circuit-Id — номер порта с которого пришёл запрос.
DHCP-Relay-Remote-Id — (по умолчанию) макадрес свитча с которого пришёл запрос.
Ещё хочется сказать о методах внедрения этой опции в пакет.В оборудовании Dlink есть два способа:
dhcp_relay — добавляет Option82 и как писалось выше, обернёт его в L3 и отправит unicast-ом указанному DHCP-серверу
dhcp_local_relay (DHCP Snooping) — только добавляет Option82 и пересылает широковещательный пакет дальше.
Немного отклонюсь от темы. Дело в том что конструкцию dhcp_local_relay я нашёл только в оборудовании Dlink. Мне стало интересно, почему же другие производители не внедрили такую замечательную опцию? Оказывается, внедрили, и давно. Называется она DHCP Snooping.
Возможно, у кого-то возникнет вопрос: «зачем нам избавляться от широковещательного трафика»? Дело в том, что на практике я очень часто встречался с таким явлением, что при выходе из строя коммутатора, например, в результате грозы, возникают петли, что приводит к широковещательному шторму. Конечно, как вы уже догадались, от одного широковещательного трафика в IPv4 нам все равно не избавиться — это ARP-трафик. Именно он отвечает за построение таблиц MAC-IP. Конечно, можно это запретить и заполнить таблицы вручную. Но, боюсь что возникшие при этом неудобства сведут на нет все прелести от статических ARP-таблиц.
Во всех статьях указано, что DHCP-клиент и DHCP-сервер могут (должны) находиться в разных подсетях — это неправда. Вот наша схема:
Далее я приведу пример конфигураций:
Теперь конфиг isc-dhcp-server (isc-dhcpd-4.2.4 ) на
Linux big-A75F-M2 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux:
$sudo apt-get install vlan-tools isc-dhcp-server
$sudo vconfig add eth0 7
$sudo ifconfig eth0.7 10.90.90.92/8
#Создаем VLAN7 и назначаем адрес 10.90.90.92/8 на котором у нас будет висеть сервер DHCP
Конечно, это только стендовый конфиг, но нам самое главное разобраться с принципом работы. Все же забегая в перед я могу сказать, что у меня работает биллинговая система с option82 и конструкцией dhcp_local_relay(dhcp snooping), а в качестве сервера используется freeradius2 с perl-выборкой IP-адресов из базы postgres. Но это уже выходит за рамки данной статьи.
На машине с сервером запускаем:
c0:a0:bb:48:e5:b0 > 00:15:17:db:e3:e0, ethertype IPv4 (0x0800), length 345: 10.90.90.90.68 > 10.90.90.92.67: BOOTP/DHCP, Request from 48:5b:39:43:78:e5, length 303
Listening on LPF/eth0.7/00:15:17:db:e3:e0/10.0.0.0/8
Sending on LPF/eth0.7/00:15:17:db:e3:e0/10.0.0.0/8
Должен вернуть UID процесса, если ни чего не выведет, проверяйте конфигурацию.
Для чего нужна такая проверка? Я помню случаи, когда сервер стартовал, висел в памяти несколько секунд и вылетал. А я тщетно пытался получить получить IP-адрес.
Если все прошло удачно, в логах мы обнаружим что-то типа:
Dec 2 20:36:17 big-A75F-M2 dhcpd: DHCPREQUEST for 10.0.0.155 from 48:5b:39:43:78:e5 (big-1001PX) via 10.90.90.90
Dec 2 20:36:17 big-A75F-M2 dhcpd: DHCPACK on 10.0.0.155 to 48:5b:39:43:78:e5 (big-1001PX) via 10.90.90.90
Dec 2 20:38:06 big-A75F-M2 dhcpd: Lease for 10.0.0.155 raw option-82 info is CID: 0.4.0.10.0.3 AID: 0.6.c0.a0.bb.48.e5.b0
Теперь одна очень важная вещь, про неё нигде не написано, но я дошёл до неё экспериментальным путём. IP-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам. Ни при каких других комбинациях мне не удалось заставить работать связку Dlink DES-3200 (Boot PROM Version: Build 4.00.002 Firmware Version: Build 4.04.004 Hardware Version: C1) и isc-dhcp-server 4.2.4.
И еще не большой бонус, как не погибнуть от броадкастов. Конфиг для Dlink DES-3200 С1:
Это статья не клон и не попытка переписать чужие статьи своими словами. Ниже список похожих публикаций и отличия от них. В своей статье я делал акцент на использование данной конструкции как метод авторизации, а не попытку вынести DHCP-сервер за пределы сети.
DHCP-сервер
Протокол динамической конфигурации хоста DHCP (Dynamic Host Configuration Protocol) – один из основополагающих протоколов, как в локальных сетях, так и в Интернет.
Под словом «хост» в ИТ чаще всего подразумевается компьютер, иногда сервер (тоже компьютер). Почему компьютер или сервер называется «хост» (host – англ. «хозяин»), никто не знает. Вероятно, возникновение этого термина восходит ко временам больших ЭВМ (мейнфреймов), к которым тогдашние пользователи могли подключаться удалённо, например, по телефонной линии. Только вместо собственного компьютера у них был лишь алфавитно-цифровой дисплей с клавиатурой.
Рис. 1. «Менйфрейм» со множеством дисплеев.
Таких дисплеев к главному и единственному компьютеру (хосту) можно было подключить много (в режиме разделения времени), и пользователи, работающие на них, считали, что весь «мейнфрейм» находится полностью в их распоряжении. А чтобы каждый пользователь получал только предназначенную ему информацию и не мог вторгнуться в анналы другого пользователя на хосте, были придуманы различные методы разделения доступа, результатом эволюции которых явился протокол DHCP. Он был разработан в 1993 году, когда уже существовали персональные компьютеры, а «мейнфреймы» стали отходить на второй план. Поэтому термин «host» продолжал использоваться, но уже в отношении персонального компьютера.
Таким образом, DHCP – это стандартный протокол в сети с архитектурой «клиент-сервер», который динамически назначает IP-адреса и другую необходимую информацию конфигурации для новых устройств в сети. Каждое сетевое устройство должно иметь собственный, уникальный IP-адрес, чтобы в сети не возникали конфликты. IP-адрес, конечно, можно прописать для компьютера вручную, т.е. статически, и не менять его в дальнейшем. В небольших сетях, на 2-5 компьютеров, так иногда и делается. Но если компьютеров в сети десятки и сотни, то уследить за уникальностью сетевых адресов будет весьма проблематично. Хотя и в таких сетях тоже могут использоваться статические IP-адреса, например, для принтеров.
Для автоматизации процесса назначения уникальных IP-адресов устройствам, входящим в сеть, был разработан протокол DHCP, который работает на специальном сервере, называемом, соответственно, DHCP-сервер.
Протокол DHCP широко используется в повседневной жизни, причем, совершенно незаметно для обычных пользователей. Примеры его использования:
Пользователь не замечает, как его устройство получает от DHCP-сервера IP-адрес и начинает работу в сети. Бывают и ситуации, когда сетевой адрес устройства лучше прописывать постоянно и не менять, если это, например, основной сервер или принтер. Поэтому, в протоколе DHCP используется резервирование, т.е. область IP-адресов, зарезервированная для статического назначения определённым устройствам.
DHCP-сервер автоматически распределяет и обновляет IP-адреса и другую информацию конфигурации компьютеров (DHCP-клиентов) в сети. Для DHCP-клиентов эта информация предоставляется при помощи обмена сообщениями, порядок которых определяется протоколом DHCP, и такой обмен называется DHCP-транзакцией. Если DHCP-сервер и DHCP-клиент расположены в разных подсетях (subnets), то используется агент-ретранслятор DHCP (DHCP relay agent), чтобы DHCP-транзакцию можно было провести между разными подсетями.
DHCP, как определено в документе RFC 2131, был разработан на базе протокола BOOTP (Bootstrap Protocol), с помощью которого клиент может автоматически получить IP-адрес, обычно, во время загрузки компьютера.
Как работает DHCP
Архитектура DHCP включает DHCP-клиенты, DHCP-серверы и агенты-ретрансляторы DHCP. Клиент общается с DHCP-сервером используя стандартные сообщения DHCP для получения и обновления выделяемых ему IP-адресов.
DHCP-клиент
DHCP-клиент – это любое IP-устройство, подключаемое к сети, запрашивающее IP-адрес и параметры конфигурации от DHCP-сервера. Они передаются в поле Options сообщения DHCP. Это поле используется для назначения дополнительных параметров, таких как адрес IP-шлюза, адрес DNS-сервера и доменное имя DNS.
DHCP-сервер
DHCP-сервер содержит пространство (пул) IP-адресов, которые он использует по собственному усмотрению для автоматического назначения их устройствам, по мере их появления в сети. DHCP-сервер назначает устройствам в сети следующие параметры:
Агент-ретранслятор DHCP
Агент-ретранслятор DHCP (DHCP relay agent) передаёт сообщения DHCP между сервером и клиентами, когда они не находятся в одной подсети. Таким образом, в больших сетях, состоящих из многих подсетей, один DHCP-сервер может обслуживать всю сеть при помощи агентов-ретрансляторов, которые располагаются на граничных маршрутизаторах подсетей. В сети можно сконфигурировать до 400 агентов-ретрансляторов. Их можно использовать для защиты от спуфинг-атак, когда недоверенные компьютеры пытаются получить доступ к IP-адресам сети.
DHCP-транзакция
При DHCP-транзакции выполняются обмен следующими сообщениями между портами DHCP-сервера и DHCP-клиента:
Рис. 2. Процесс DHCP-транзакции.
Возобновление назначения IP-адреса
Если клиенту нужно продлить время назначения (lease time), по истечении примерно 50% времени назначения IP-адреса, он должен выполнить процедуру возобновления назначения (lease renewal). При этом выполняется более простая процедура, чем начальное назначение IP-адреса.
Клиент посылает на DHCP-сервер запрос DHCP REQUEST, в котором указан назначенный ему ранее IP-адрес. Это сообщение отправляется только на сервер, выдавший этот адрес при назначении, а не по общей рассылке. Если сервер имеет возможность вновь назначить тот же IP-адрес, то он сразу же посылает сообщение DHCP ACK.
Освобождение IP-адреса
Если клиенту более не нужен назначенный ему IP-адрес, то он посылает сообщение об освобождении IP-адреса DHCP RELEASE на DHCP-сервер. После этого этот IP-адрес может быть назначен другому устройству при следующем запросе DHCP-сервера.
Конфигурация DHCP
При DHCP-транзакции могут конфигурироваться DHCP-серверы, DHCP-клиенты, агенты-ретрансляторы (Relay agent), а также пороги ограничения времени назначения (Short lease threshold).
Конфигурация DHCP-клиента
Интерфейс на сетевом устройстве может быть сконфигурирован либо со статическим (постоянным), либо динамическим IP-адресом, а также другими параметрами в поле Option сообщения DHCP:
Код параметра в поле Option
Описание
Маска подсети для устройства (subnet mask)
Список маршрутизаторов по умолчанию
Список серверов DNS
Имя домена, используемой для определения имён хостов в нём, либо список доменов.
Истечение заданного времени назначения (lease time)
Конфигурация DHCP-сервера
Для назначения IP-адресов клиентам, DHCP-сервер использует пул адресов. Этот пул содержит определённые параметры конфигурации, которые DHCP-сервер может назначать клиентам. Таких пулов на сервере может быть несколько для обслуживания разных сетей.
Конфигурация пула адресов предусматривает следующее:
Конфигурация агента-ретранслятора
Агент-ретранслятор DHCP передает сообщения протокола BOOTP между серверами и клиентами. Если в сети серверы DHCP и BOOTP не находятся в одной и той же подсети, то необходимы маршрутизаторы на границе подсетей, которые будут выполнять функции агента-ретранслятора адресов. Оба протокола, BOOTP и DHCP, используют сообщения BOOTP, что позволяет агенту-ретранслятору передавать все их пакеты.
Конфигурация порога короткого времени назначения (short lease threshold)
Время короткого назначения (short lease time) конфигурируется для различных ситуаций, например, для бесплатного доступа wifi в кафе. Можно назначить, например, один час бесплатного доступа, после чего пользователю будет необходимо вновь регистрироваться в сети. В условиях предприятия время назначения можно задавать в пределах дней или недель.
В некоторых сетях находится много мобильных устройств, которые многократно запрашивают IP-адрес, до того, как их время назначения истекает. Такое может случаться, если устройства покидают зону wifi на короткое время и снова возвращаются, либо связь теряется в случае нестабильности радиосигнала wifi в разных помещениях в зоне действия беспроводной сети.
Это означает, что один и тот же IP-адрес может иметь несколько времен назначения, что может занимать много места в системе резервирования файлов. Для этого установки времен назначения необходимо сохранять в постоянной памяти, чтобы, например, в случае перезагрузки DHCP-сервера или сбое питания, он не будет терять информацию о временах назначения IP-адресов для клиентов.
Можно сделать и так, что устройство будет просто запрашивать новый адрес при необходимости. В этом случае, можно установить порог кроткого времени назначения (short lease threshold), которое может составлять от 1 минуты до 24 часов. В этом случае, любое время назначения не превышающее порог short lease threshold, не будет сохраняться в резервной постоянной памяти.
Решение DDI
Основными элементами управления в IP-сетях являются DNS, DHCP и управление IP-адресами IPAM (IP address management). Эти элементы тесно связаны друг с другом. Однако, раздельное управление этими элементами создает много проблем в плане эффективности и операционными рисками, например:
Решение DDI даёт возможность интегрированного администрирования DNS-DHCP-IPAM и сетевых интерфейсов устройств в едином процессе. При этом можно достигнуть высокой доступности, эластичности в масштабировании ресурсов сети в едином процессе администрирования на основе задаваемых политик. Кроме того, такое решение может значительно повысить «видимость» управления на базе единой панели администрирования и общую «целостность» сети.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Настройка DHCP-ретранслятора с поддержкой HSRP
Всем привет! В этой статье рассказываем про настройку DHCP-ретранслятора с поддержкой HSRP.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Настройка DHCP-ретранслятора с поддержкой HSRP
Агент ретрансляции DHCP пересылает пакеты пакеты discover, offer, reply и ack DHCP между клиентами и серверами, когда они не находятся в одной физической подсети. В случае ретрансляции DHCP маршрутизатор не просто направляет пакет в соответствии с полем DEST ID в IP-пакете, но вместо этого создает новое сообщение DHCP, которое будет отправлено на настроенный сервер имен. Агент ретрансляции также устанавливает IP-адрес шлюза (поле GIADDR пакета DHCP) и, если он настроен, добавляет к пакету опцию информации агента ретрансляции (опция 82). Ответ с сервера пересылается клиенту после удаления опции 82. Таким образом, агенты ретрансляции DHCP устраняют необходимость наличия DHCP-сервера в каждой физической сети.
Эта статья описывает общее развертывание, где у нас есть маршрутизаторы, настроенные как агент ретрансляции DHCP наряду с протоколом FHRP, HSRP, используемым в сегменте клиента DHCP.
Рис. 1.1 Управляемый DHCP-ретранслятор
В топологии ниже маршрутизаторы ALT_1 и ORL являются узлами HSRP для подсети LAN 176.18.3.0/24.
На обоих маршрутизаторах настроены интерфейсы Fa5/0 с помощью DHCP Relay Agent.
Настройки на маршрутизаторах R2 и R3, показаны ниже:
Сообщение запроса Bootstrap от клиента будет поддерживаться как маршрутизаторами ALT_1, так и маршрутизаторами ORL и будет перенаправлено на DHCP-сервер, настроенный с помощью команды ip helper-address.
DHCP-сервер отправляет ответ как агентам ретрансляции 176.18.3.2, так и агентам ретрансляции 176.18.3.3, которые, в свою очередь, будут перенаправлены в дальнейшем на DHCP-клиент. Если клиент недостаточно интеллектуальный, он может запутаться с этими двумя запросами, поступающими от DHCP-сервера.
Чтобы преодолеть эту ситуацию, мы можем настроить DHCP Relay Agent с осведомленностью о HSRP, что выполняется добавлением следующих команд как к активным, так и к резервным маршрутизаторам HSRP:
При приведенной выше конфигурации сообщение запроса Bootstrap будет инициировано только активным маршрутизатором HSRP ALT_1, поскольку это активный маршрутизатор HSRP (из-за более высокого настроенного приоритета HSRP). Теперь DHCP-сервер получает только одно сообщение обнаружения DHCP только от одного маршрутизатора, и он отправляет ответное сообщение только на один из двух маршрутизаторов, откуда он его получил.
Следовательно, клиент теперь получит пакет DHCP OFFER только один раз, и то тоже от маршрутизатора ALT_1 router.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Протоколы и функции, применяемые в межсетевых экранах и интернет-маршрутизаторах
Сервисы DHCP
DHCP-клиент в межсетевых экранах D-Link NetDefend
В состав системы NetDefendOS (операционная система межсетевых экранов D-Link NetDefend) включена функция DHCP-клиент (DHCP Client), которая отвечает за динамическое получение адреса от DHCP-сервера (например, в случае подключения к Интернет-провайдеру по DHCP). Используя данную функцию, можно получить IP-адрес интерфейса, адрес локальной сети, к которой относится данный интерфейс, IP-адрес шлюза по умолчанию и IP-адреса DNS-серверов.
Опция DHCP Client может быть включена или отключена администратором в свойствах интерфейса. По умолчанию это свойство отключено на всех Ethernet-интерфейсах, за исключением WAN1-порта (или WAN-порта, в зависимости от модели).
Если функция DHCP-клиент активирована на каком-либо Ethernet-интерфейсе, то IP-адресация, относящая к данному интерфейсу (IP-адрес интерфейса/адрес сети/IP-адреса шлюза и DNS), не может быть изменена или удалена. Для изменения этих адресов необходимо отключить опцию DHCP Client.
DHCP-сервер в межсетевых экранах D-Link NetDefend
Как уже упоминалось выше, DHCP-сервер распределяет IP-адреса из определенного пула IP-адресов и управляет ими. В системе NetDefendOS DHCP-серверы не ограничены использованием одного диапазона IP-адресов, а могут применять любой диапазон IP-адресов, который определен как объект IP-адрес.
В NetDefendOS администратор имеет возможность настроить один или несколько логических DHCP-серверов. Фильтрация запросов DHCP-клиентов к разным DHCP-серверам зависит от двух параметров:
Каждый интерфейс в системе NetDefendOS может иметь, по крайней мере, один логический одиночный DHCP-сервер. Другими словами, NetDefendOS может предоставить DHCP-клиентам IP-адреса из разных диапазонов в зависимости от интерфейса клиента.
IP-адрес ретранслятора, передаваемый в IP-пакете, также используется для определения подходящего сервера. Значение по умолчанию all-nets (все сети) делает все IP-адреса допустимыми, и тогда выбор DHCP-сервера зависит только от интерфейса.
Список DHCP-серверов формируется по мере занесения в него новых строк. Когда в системе NetDefendOS выбирается DHCP-сервер для обслуживания запроса клиента, поиск по списку осуществляется сверху вниз. Выбор падает на верхний по списку сервер, соответствующий комбинации параметров (интерфейс и IP-адрес устройства, выполняющего функцию DHCP Relay). Если совпадений в списке не найдено, запрос игнорируется.
Для DHCP-серверов задаются следующие параметры ( рис. 4.5):
Name – Символьное имя сервера. Используется в последующих настройках как ссылка на интерфейс или как ссылка в сообщениях для записи в журнал событий (log).
Interface Filter – Интерфейс источника, на котором система NetDefendOS будет ожидать получения DHCP-запросов.
Relay Filter – Каждый DHCP-сервер должен иметь определенное значение фильтра по IP-адресу ретранслятора. Возможны следующие варианты:
IP Address pool – Диапазон IP-адресов (группа или сеть), который используется DHCP-сервером для распределения IP-адресов DHCP-клиентам в соответствии с DHCP-арендой.
Netmask – Маска подсети, которая будет рассылаться DHCP-клиентам.
Default GW – указывается IP-адрес устройства, выполняющего функции основного шлюза, который передается клиенту (маршрутизатор, к которому подключается клиент).
Domain – имя домена, используемое DNS для определения IP-адреса. Например, domain.com.
Lease Time – время предоставленной DHCP-аренды в секундах. По истечении данного периода DHCP-клиент должен возобновить аренду.
Primary/Secondary DNS – IP-адреса DNS-серверов.
Primary/Secondary NBNS/WINS – IP-адреса WINS-серверов среды Microsoft, которые используют NBNS-серверы для установления соответствий между IP-адресами и именами в NetBIOS.
Next Server – определяет IP-адрес сервера, с которого осуществляется загрузка операционной системы хостов, в случае загрузки по сети (например, TFTP-сервера).
Помимо описанных свойств, DHCP-сервер системы NetDefendOS может иметь два дополнительных набора объектов: Static Hosts и Custom Options.
Static Hosts. При необходимости установления фиксированной связи между клиентом и конкретным IP-адресом, система NetDefendOS позволяет назначить данный IP-адрес MAC-адресу клиента. Другими словами, позволяет создать хост со статическим IP-адресом.
Custom Options. Заполнение раздела специальных опций DHCP-сервера при его определении позволяет администратору в сообщениях, содержащих детали аренды (такие, как код и тип данных), также отправлять дополнительную информацию для DHCP-клиентов. В качестве примера могут служить те коммутаторы, которым требуется IP-адрес TFTP-сервера, для передачи дополнительной информации.
Коды вводятся в соответствии со значениями, определенными в RFC 2132 (DHCP Options and BOOTP Vendor Extensions).
RFC (Request for Comments – запрос комментариев) – это документы из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты.
Функция DHCP Relays в межсетевых экранах D-Link NetDefend
По протоколу DHCP хост-клиент отправляет запросы DHCP-серверам, чтобы классифицировать их с помощью широковещательной рассылки. Однако такие сообщения обычно распространяются только в локальных сетях. Это означает, что DHCP-сервер и клиент всегда должны находиться в одной и той же физической сети. Поскольку для сетевой топологии, подобной сети Интернет, невозможно установить свой DHCP-сервер в каждой сети, в межсетевых экранах NetDefend используется функция DHCP Relays, которая позволяет передавать запросы от DHCP-клиентов DHCP-серверу.
DHCP Relayer (DHCP-ретранслятор) занимает место DHCP-сервера в локальной сети и выполняет роль связи между клиентом и удаленным DHCP-сервером. Он перехватывает запросы от клиентов и передает их DHCP-серверу. DHCP-сервер затем отвечает ретранслятору, который переадресовывает ответ обратно клиенту. Чтобы выполнять функции ретрансляции, DHCP Relayer использует протокол TCP/IP Bootstrap Protocol (BOOTP). Поэтому DHCP Relayer иногда ассоциируют с агентом пересылки BOOTP (BOOTP relay agent).