dhcp 82 что это такое option
IPoE, а также Client-VLAN и DHCP Option 82
В этой статье я опишу что из себя представляет технология доступа в Интернет IPoE, которой на самом деле не существует. А также расскажу про схему Client-VLAN и про опцию 82 DHCP (DHCP Option 82), которые стали неотъемлемой частью этой несуществующей технологии. Все это, конечно же, с технической точки зрения и с примерами конфигов.
Существует множество технологий доступа в Интернет для конечных абонентов. В России особенно популярны две: PPTP и PPPoE. В обоих случаях создается PPP-туннель, производится аутентификация, и внутри туннеля ходит абонентский IP-трафик. Основное отличие этих протоколов – они работают на разных уровнях сетевой модели OSI. PPPoE работает на втором (канальном) уровне, добавляя специальные теги, идентифицирующие конкретный туннель, в Ethernet-фреймы. PPTP работает на третьем (сетевом) уровне, упаковывая IP-пакеты в GRE.
IPoE принципиально отличается от PPTP и PPPoE. Вообще этой технологии не существует. Нет RFC, нет никаких стандартов ее описывающих. Сам термин придуман, скорее всего, в России и является абстрактным. Означает он следующее: IP over Ethernet. Смысл именно такой, как и расшифровка – IP-трафик поверх Ethernet, грубо говоря, обычная локалка. Абоненту выдается в лучшем случае статический или динамический белый IP-адрес, в худшем случае серый IP с NAT. Контроль доступа в данном случае может осуществляется при помощи привязок IP-MAC на коммутаторах доступа или на BRAS или выделения VLAN на каждого абонента (так называемый Client-VLAN).
Client-VLAN
При использовании технологии Client-VLAN возникает проблема: как сэкономить IP-адреса? Ведь, если подумать, каждому клиенту надо выделять /30 подсеть. На самом деле проблема легко решаема. Привожу пример для маршрутизатора на базе Linux:
Подсеть 192.0.2.0/24 рекомендована IANA для использования в примерах.
Это классический Cisco’вский ip unnumbered в Linux’овой реализации. IP шлюза (192.0.2.1) вешается на loopback-интерфейс, делается unreachable для всей подсети, чтобы пакеты ходили только на хосты, для которых прописан роутинг. Далее поднимается VLAN и прописывается роутинг на конкретный хост (маска /32) с src шлюза. А можно сделать немного иначе (это лишний раз демонстрирует гибкость Linux):
Все эти варианты работают, можно выбрать тот, при котором интерфейсы отображаются наиболее удобным образом. Во всех случаях IP абонента – 192.0.2.101/24.
Proxy_arp
Еще одна проблема, с которой вы можете столкнуться – нет связи между абонентами в разных VLAN и с IP из одной подсети. Действительно, система абонента видит, что IP-адрес назначения в одной подсети с ней, и шлет ARP-запросы, чтобы определить MAC, но из этого ничего не выходит, т.к. они в разных VLAN. Для решения этой проблемы служит технология proxy_arp. Суть ее в том, что маршрутизатор при получении ARP-запросов с интерфейса будет проверять есть ли у него запрашиваемый IP на других интерфейсах. Если есть, то в ответ на ARP-запрос выдаст свой MAC. Таким образом, пакеты будут отправляться на маршрутизатор, который позаботится об их доставке. Включается proxy_arp для конкретного интерфейса следующим образом:
DHCP Option 82
192.168.0.1 – IP-адрес DHCP-сервера, доступного в управляющем VLAN.
Базовые настройки dhcp_local_relay:
И наконец приведу базовый конфиг для ISC’s 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 Option82 – это просто
В данной статье речь пойдет о построении сети с использованием технологии подключения пользователей, известной как IPoE с использованием динамической выдачи адресов по протоколу DHCP с использованием опции 82.
Итак нашей задачей является построить сеть в которой от пользователя требуется минимум действий для авторизации и работы в сети. Можно даже назвать это как: «воткнул кабель в компьютер, и заработало».
В качестве биллинговой системы мы будем использовать бесплатную (до 200 абонентов) сертифицированную АСР Felix2. В качестве DHCP сервера будем использовать ISC DHCP сервер.
Общая схема работы
Когда пользователь включает компьютер, операционная система отправляет DHCP запрос на получение IP адреса в сеть. На коммутаторе включено перенаправление DHCP запросов (DHCP Relay) и включена поддержка опции 82 протокола DHCP, поэтому он перехватывает DHCP запрос от пользователя, добавляет данные Option82 (Agent Circuit ID и Agent Remote ID) к DHCP пакету и перенаправляет запрос на DHCP сервер.
Когда DHCP запрос попадает на DHCP сервер, тот выдает IP-адрес основываясь на данных текущей конфигурации. В конфигурации задано соответствие IP-адреса, выдаваемого пользователю, IP-адресу и порту коммутатора к которому подключен пользователь. Конфигурация DHCP сервера формируется АСР Felix2 по имеющейся в базе данных информации.
АСР Felix2 периодически забирает от DHCP сервера данные о MAC адресах пользователей (которым были выданы IP-адреса) на портах коммутаторов. По IP-адресу и номеру порта коммутатора система находит пользователя в базе и отмечает, что MAC адрес принадлежит этому пользователю.
Также АСР Felix2 периодически забирает ARP таблицу с маршрутизатора (таблица соответствий IP — MAC) и, если пара IP-MAC соответствует пользователю в базе, данный пользователь считается авторизованным. Как только пара IP-MAC пропадает (пользователь выключает компьютер) система переводит пользователя в список неавторизованных (выполнив перед этим проверку, что оборудование абонента действительно выключено).
Практическая реализация
Для начала нам потребуется компьютер с двумя сетевыми картами и любой коммутатор, поддерживающий DHCP Relay (option 82). Первую (тестовую) сеть будем строить по следующей схеме:
В данной схеме система на АСР Felix2 будет выполнять дополнительно функцию маршрутизатора.
Установка
Скачаем (felix2.ru/download) и установим любым из описанных способов на сервер АСР Felix2.
В данной статье мы будем использовать «Установочный диск АСР Felix2». Подробная инструкция по установке АСР Felix2 находится здесь: felix2.ru/documentation
После установки входим в систему, используя логин root и пароль, указанный во время установки.
Сетевой интерфейс eth0 после установки сконфигурирован для работы с внутренней сетью:
IP-адрес: 10.1.1.1
Маска подсети: 255.255.255.0
Интерфейс eth1 нужно настроить для работы с вышестоящим Интернет провайдером:
Здесь 1.1.1.2 — IP-адрес выданный нам вышестоящим Интернет провайдером, 1.1.1.1 – IP-адрес шлюза провайдера.
Чтобы конфигурация сети не сбросилась после перезагрузки, ее нужно описать в файле /etc/network/interfaces
Установим ISC-DHCP сервер:
Сразу после установки DHCP сервер не запустится, так он еще не сконфигурирован:
Конфигурирование
Файл шаблона конфигурации ISC DHCP сервера (dhcp_opt82_ip-port.conf) и все остальные необходимые конфигурационные файлы можно скачать отсюда:
ftp://download.felix2.ru/config.examples/felix2_dhcp_opt82.tar.gz
Скачиваем, распаковываем, заменяем конфигурационные файлы:
Перезапускаем АСР Felix2:
Создание оборудования и тестового пользователя в АСР Felix2
Зайдем в веб-интерфейс администратора. Можно для этого использовать тестовую машину, временно поставив на ней статический IP-адрес (например 10.1.1.10/24). Веб интерфейс администратора доступен на 444 порту по протоколу HTTPS. Логин/пароль по умолчанию: su/su.
Выбираем оборудование к которому будет подключен пользователь. Система предложит выбрать оборудование из списка оборудования, установленного в данном доме.
Указываем что пользователь будет подключен к первому порту коммутатора. Отмечаем флаг «Подключение выполнено» и нажимаем «Добавить».
Проверим, что конфигурационный файл DHCP сервера обновился:
Проверим, что DHCP сервер работает:
Настройка коммутатора
Теперь нужно настроить коммутатор. Если коммутатор «из коробки», в инструкции должен быть указан IP-адрес «по умолчанию». Если оборудование «б/у», и вы не знаете какой у него IP-адрес/логин/пароль, нужно сбросить конфигурацию через консольное подключение.
В данной статье мы будем использовать коммутатор DES-3200-28 «из коробки».
Ставим на тестовой машине статический IP-адрес (например 10.90.90.1/8) Подключаемся к коммутатору по протоколу telnet:
Включаем, настраиваем DHCP Relay:
Теперь коммутатор будет перехватывать DHCP запросы, добавлять идентификационную информацию (option 82) и отправлять на DHCP сервер (10.1.1.1)
Задаем маршрут «по умолчанию» и новый IP-адрес коммутатора:
После последней команды (смена IP-адреса) соединение будет разорвано. Ставим на тестовой машине статический IP-адрес (например 10.1.1.10/24) Подключаемся к коммутатору по новому адресу, сохраняем конфигурацию:
Включаем на тестовом компьютере получение сетевых настроек по DHCP.
Подключаем тестовый компьютер в первый порт коммутатора. Проверяем что DHCP-Relay пакеты от коммутатора доходят до сервера и клиент получает IP-адрес:
Проверяем, что данные пользователя правильно отображаются в интерфейсе АСР Felix2.
Реальная схема сети
600 абонентов). Аплинк от магистрального провайдера приходит в оптический порт коммутатора. Этот порт нужно объединить в VLAN с портом, куда подключается сетевая карта eth1 от сервера с АСР Felix2.
Например, объединяем 1 и 24 порт в 1000й VLAN:
При росте сети также желательно разнести дома по отдельным VLAN.
Схема сети с выделенным маршрутизатором
При росте внутрисетевого(локального) трафика, соединение между коммутатором и сервером с АСР Felix2, выполняющим одновременно роль маршрутизатора, станет узким местом. Чтобы избежать этого, нужно установить выделенный маршрутизатор.
Также нужно указать АСР Felix2 получать ARP таблицу с внешнего маршрутизатора. Отредактируем файл /etc/felix2/felix2.xml:
Модуль arp_fetcher может получать таблицу ARP адресов с оборудования CISCO (interface=«CISCO»), D-Link (interface=«DLINK»), или с программного маршрутизатора на базе Linux (interface=«Linux»).
По просьбе хабражителей добавлен пример сгенерированного системой конфигурационного файла для ISC DHCP сервера.
В данном примере пользователям, подключенным в порты 1-3 коммутатора с адресом 10.1.1.253, выдаются адреса 10.1.1.2-10.1.1.4 соответственно.
Опция 82 DHCP
Материал из Xgu.ru
Опция 82 DHCP (DHCP option 82) — опция протокола DHCP, использующаяся для того чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Применяется при решении задачи привязки IP-адреса к порту коммутатора и для защиты от атак с использованием протокола DHCP (DHCP snooping).
Содержание
[править] Задача
Протокол динамического конфигурирования DHCP очень удобен — настройка стека TCP/IP клиентских машин не требует никакого внимания со стороны администратора, всё происходит само собой. С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост получит какой адрес. Если нужно сохранить удобство использования DHCP, но при этом сделать так, чтобы адреса были чётко закреплены за каждым компьютером, используется так называемая привязка к MAC-адресу: DHCP-сервер имеет таблицу соответствия MAC-адресов IP-адресам, и назначает IP-адреса в соответствии с этой таблицей. Минус этого решения — необходимость отслеживания MAC-адресов и сопровождения таблицы соответствия.
В некоторых случаях может помочь компромиссное решение — поставить IP-адреса в соответствие не MAC-адресам, а портам коммутатора, к которым подключен клиентский компьютер. Другой вариант — выдавать IP-адреса в зависимости от того, с какого DHCP-ретранслятора пришел запрос. В этом случае выдаются адреса из одной подсети, но с привязкой конкретных диапазонов адресов к различным коммутаторам, работающим как DHCP-ретрансляторы. Это может помочь облегчить администрирование сети в том смысле, что по IP-адресу клиентского компьютера, будет понятно к какому коммутатору он подключен.
Решить эти задачи позволяет опция 82 протокола DHCP.
Ниже описывается, каким образом настроить DHCP-сервер, чтобы он выдавал IP-адрес в зависимости от того, к какому порту коммутатора подключен клиент, сделавший запрос. Рассматривается случай, когда коммутатор, через который поступает запрос, используется в роли DHCP-ретранслятора (решение задачи для случая, когда это не так, описано на странице DHCP snooping).
[править] Протокол DHCP
DHCP (Dynamic Host Configuration Protocol) — один из важнейших протоколов в стеке протоколов TCP/IP, предназначенный для назначения хостам различных параметров необходимых для работы в сети, в частности, их IP-адресов, адреса шлюза по умолчанию, IP-адресов DNS-серверов и множества других.
Во взаимодействии по протоколу DHCP принимают участие две или три стороны:
Как правило, DHCP-сервер выделяет IP-адреса (и прочие параметры TCP/IP) одним из двух способов:
[править] Option 82
Опция 82 состоит из двух подопций:
Agent Circuit ID — содержит информацию о том, с какого порта пришел запрос на DHCP-ретранслятор.
Agent Remote ID — идентификатор самого DHCP-ретранслятора (который задается при настройке, можно например использовать MAC-адрес коммутатора или его описание, любое удобное значение).
Опция 82 в запросе DHCP:
DHCP-серверы, поддерживающие опцию 82:
Несмотря на то, что это нигде не указано явно, вероятнее всего, Microsoft Windows 2003 Server опцию 82 не поддерживает. (Однако на личном опыте проверено что работает, надо только добавить эту опцию)
[править] Инсталляция и настройка DHCP сервера ISC-DHCP
Будем использовать dhcp-сервер ISC-DHCP (v3). ISC DHCP Server — наиболее распространнённый DHCP-сервер, из использующихся в UNIX/Linux-системах. Для нас сейчас важно и то, что это один из серверов, умеющих распознавать опцию 82.
Будем предполагать, что инсталляция и настройка сервера выполняется в Debian GNU/Linux. Пользователи других систем должны учесть, что процедура инсталляции и местоположение конфигурационных файлов могут несколько отличаться.
[править] Установка DHCP-сервера с поддержкой опции 82
В обычном случае установить откомпилированный DHCP-сервер из репозитория пакетов можно было бы с помощью команды:
и можно было бы считать, что на этом инсталляция сервера закончена, и можно переходить к его настройке. Однако, в том случае, если предполагается использование DHCP-ретранслятора (что обязательно, если будет использоваться опция 82), может потребоваться сборка пакета с включённой директивой USE_SOCKETS. Подробнее эта процедура описана ниже.
[править] Сборка с включённой директивой USE_SOCKETS
По умолчанию DHCP-сервер ожидает услышать запросы клиентов на широковещательном адрес 255.255.255.255. Однако, когда запрос перенаправляет DHCP-ретранслятор, запрос приходит непосредственно на адрес DHCP-сервера. Для того чтобы DHCP-сервер корректно обрабатывал информацию от DHCP-ретранслятора, его необходимо скомпилировать с использованием директивы
и указать в конфигурационном файле local-address.
Скачиваем исходники DHCP-сервера:
Перед началом сборки исходников необходимо установить все пакеты, необходимые для успешной сборки пакета, для чего выполнить:
Теперь необходимо в файле site.h раскомментировать директиву #define USE_SOCKETS:
Перейти в каталог dhcp3-3.0.6.dfsg:
Для того чтобы собрать пакет необходимо выполнить:
или, если сборка производится root’ом:
После сборки пакеты должны быть установлены в системе (инсталлируем только common и server, так как нам не нужен DHCP-ретранслятор и DHCP-клиент):
[править] Настройка DHCP-сервера
Сразу же после инсталляции пакета, сервер не заработает — сначала необходимо отредактировать его конфигурационный файл /etc/dhcp3/dhcpd.conf.
Интерфейс, на котором будет работать DHCP-сервер, передается ему в качестве аргумента при вызове.
В Debian GNU/Linux аргументы и ключи вызова программ принято указывать в соответствующих файлах в каталоге /etc/default, в частности, конфигурационный файл, в котором находятся опции для нашего сервера, называется /etc/default/dhcp3-server.
При условии, что сервер будет слушать запросы на интерфейсе eth0, файл будет выглядеть так:
Можно указать несколько интерфейсов, запросы с которых будет обрабатывать сервер. Они должны быть разделены пробелом.
Теперь можно запускать сервер:
После сборки сервера с #define USE_SOCKETS:
[править] Написание правил для соответствия адреса порту коммутатора
[править] Используемые операторы
suffix (data-expr, length)
Оператор suffix анализирует выражение data-expr и возвращает последние байты в указанном количестве. length — это числовое значение. Если data-expr или length равны нулю, то результат также будет равен 0. Если длина указанная в length больше чем сами данные, то suffix возвращает все данные.
substring (data-expr, offset, length)
Оператор substring анализирует данные и возвращает строку данных, которая начинается от указанного значения offset и имеет длину, равную указанной в length. Offset и length — числовые выражения. Если data-expr, offset или length равны нулю, то результат также равен 0. Если значение offset больше или равно длине data-expr, то будет возвращена нулевая строка. Если длина length больше чем длина данных оставшихся после offset, тогда возвращаемая строка будет содержать все данные от значения offset до конца.
binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)
Преобразует результат вычисления data-expr2 в текстовую строку, содержащую по одному числу для каждого элемента результата вычисления data-expr2. Числа разделены между собой результатом вычисления data-expr1. Параметр numeric-expr1 указывает основание системы исчисления (от 2 до 16), в которую должны преобразовываться числа. Параметр numeric-expr2 указывает количество битов на каждое число, полученное в результате преобразования. Оно может быть равно 8, 16 или 32.
Берём адрес leased-address, инвертируем его, а потом делим на 8 битные числа, каждые из которых преобразуем в 10-чную систему счисления. Полученные числа объединяем между собой через «.» и присоединяем «.in-addr.arpa.» справа.
[править] Просмотр информации на коммутаторе
Надо знать, каким образом кодируется номер порта коммутатора, чтобы затем правильно распознавать номера в пришедших запросах.
Например, в коммутаторе ProCurve опция 82 выглядит следующим образом:
В коммутаторах других производителей она выглядит аналогично.
Для того чтобы увидеть, каким образом кодируются номера портов в коммутаторе Procurve, необходимо выполнить команду:
Информация о MAC-адресе коммутатора:
На коммутаторах D-Link DES-35xx и 3028 выглядит так.
[править] Примеры правил
Указываем, что нас интересует последний байт в circuit-id:
Делаем преобразование вырезанного байта из двоичного формата в десятичный и указываем, что запрос попадет под правило класса, если результат преобразования будет равен 5.
Правило для порта 5.
Аналогично для порта 45:
Эти правила могут отличаться при использовании как коммутаторов других производителей, так и при использовании модульных коммутаторов ProCurve. Необходимо выяснять каким образом кодируется номер порта.
Если нам необходимо учитывать от какого relay-агента пришел запрос, то можно создать соответствующее правило:
Если нужно привязать IP-адреса не к портам коммутатора, а к самим коммутаторам как таковым, учитывать порт, с которого пришел DHCP-запрос (Agent Circuit ID), не обязательно, а важно настроить совпадение MAC-адреса или IP-адреса DHCP-ретранслятора (Agent Remote ID) в пришедшей опции 82.
[править] Пример конфигурационного файла DHCP-сервера
[править] Настройка коммутатора HP ProCurve для работы DHCP-ретранслятором
Включение DHCP-ретранслятора на коммутаторе (по умолчанию включен):
Включить ip routing (на коммутаторе включается функциональность 3го уровня):
Настроить режим вставки опции 82 (drop, replace, validate):
Параметры команды dhcp-relay option 82:
При одновременной работе DHCP-ретранслятора и DHCP snooping на коммутаторе, необходимо обратить внимание на то, что настройки DHCP snooping, по обработке пакетов с опцией 82, перекрывают настройки DHCP-ретранслятора.
Настройка ip helper-address (ip helper-address задается в VLAN, в котором находится DHCP-клиент. IP-адрес в этой команде — это адрес DHCP-сервера):
[править] Просмотр настроек на коммутаторе
Посмотреть настроенные ip helper-address для VLAN 1: