Настройка DHCP Relay Agent в Windows Server 2012
23.07.2021
itpro
Windows Server 2012
комментария 4
Протокол DHCP является широковещательным (FAQ по протоколу DHCP) и по умолчанию его пакеты не пересылаются маршрутизаторами из одной сети в другую (маршрутизатор разбивает на части широковещательный домен). Однако это не означает, что в каждой подсети должен находиться отдельный DHCP сервер. Ведь, согласитесь, было бы нелогично в сложных и распределенных сетях со множеством подсетей размещать в каждой подсети с клиентами отдельный DHCP сервер (это неудобно с точки зрения управления и лишнего количества администрируемых единиц оборудования). Гораздо более изящнее и удобнее было бы иметь в сети один DHCP сервер, который будет можно централизованно администрировать, и кроме того, обеспечить его высокую доступность за счет кластеризации.
Что такое DHCP relay и зачем он нужен?
Выходом из подобной ситуации является размещение в сети агента-ретранслятора DHCP (relay agent). Relay agent представляет собой некое промежуточное устройство, которое может пересылать широковещательные DHCP-запросы между клиентом и сервером DHCP, находящихся в различных широковещательных доменах. Т.е. DHCP relay agent получает от клиента (в этом же сегменте сети) широковещательный пакет на поиск и получение DHCP-адреса и пересылает этот запрос определенному DHCP серверу (указывается в настройках ретранслятора). Далее ответы от DHCP-сервера будут направлены ретранслятору, который передаст их конечному хосту. Технология DHCP Relay Agent определена в стандарте RFC 1542 («Clarifications and Extensions for the Bootstrap Protocol.»).
В качестве DHCP Relay Agent обычно используют маршрутизаторы (большинство современных маршрутизаторов совместимы с RFC 1542 и могут работать в качестве Relay агента). В том случае, если настроить Relay на маршрутизаторе по каким-либо причинам невозможно, в качестве Relay агента можно настроить компьютер с серверной ОС Windows. Попробуем настроить DHCP Relay Agent на Windows Server 2012.
Настройка DHCP Relay на Windows Server 2012
Несколько требований, которые необходимо учитывать при настройке агентов DHCP relay на базе Windows Server:
- Отдельный агент-ретранслятор DHCP необходимо размещать в каждой IP подсети.
- На центральном DHCP сервер нужно создать отдельную DHCP область (Scope) для каждой из обслуживаемых подсетей.
- DHCP relay agent нельзя установить на сервере Windows Server с ролью DHCP, ICS (Internet connection sharing) или c включенной в автоматическом режиме трансляции адресов NAT (Network Address Translation)
DCHP Relay Agent является одной из функций службы Routing and Remote Access (RRAS). Поэтому предварительно необходимо установите роль RRAS (с дефолтными настройками), после чего запустить MMC оснастку Routing and Remote Access.
В оснастке RRAS разверните ветку IPv4, щелкните правой кнопкой мыши по элементу General и в контекстном меню выберите пункт New Routing Protocol, выберите DHCP Relay Agent и нажмите ОК.
Щёлкните ПКМ по элементу DHCP Relay Agent и выберите пункт New Interface, укажите сетевой интерфейс, на котором будет слушать Relay –агент.
Затем откройте окно свойств DHCP Relay Agent и укажите ip адрес DHCP сервера, на который нужно перенаправлять все DHCP запросы от клиентов.
На этом настройка 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-пакет два дополнительных параметра:
Ещё хочется сказать о методах внедрения этой опции в пакет.В оборудовании Dlink есть два способа:
Немного отклонюсь от темы. Дело в том что конструкцию 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:
Конечно, это только стендовый конфиг, но нам самое главное разобраться с принципом работы. Все же забегая в перед я могу сказать, что у меня работает биллинговая система с option82 и конструкцией dhcp_local_relay(dhcp snooping), а в качестве сервера используется freeradius2 с perl-выборкой IP-адресов из базы postgres. Но это уже выходит за рамки данной статьи.
На машине с сервером запускаем:
Должен вернуть 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-сервер за пределы сети.
Name already in use
ops / docs / dhcp_relay_user_guide.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
The Dynamic Host Configuration Protocol (DHCP) is used for configuring hosts with IP addresses and other configuration parameters, without human intervention. The protocol is composed of three components: the DHCP client, the DHCP server, and the DHCP relay agent. The DHCP client sends broadcast request packets to the network. DHCP servers respond with broadcast packets that offer IP parameters, such as an IP address for the client. After the client chooses the IP parameters, communication between the client and the server is by unicast packets. The function of the DHCP relay agent is to forward the DHCP messages to other subnets so that the DHCP server does not have to be on the same subnet as the DHCP clients. The DHCP relay agent transfers DHCP messages from the DHCP clients located on a subnet without a DHCP server, to other subnets. It also relays answers from DHCP servers to DHCP clients. The DHCP relay agent on the routing switch forwards DHCP client packets to all DHCP servers (helper IP addresses) that are configured in the table administered for each interface. The helper address configuration is allowed only on data plane interfaces. The helper address should not be multicast or loopback address.
DHCP relay option 82
Option 82 is called the relay agent information option. The option 82 field is inserted/replaced or the packet with this option is dropped by the DHCP relay agent, when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the relay agent information option may use the information to implement an IP address or other parameter assignment policies. The relay agent relays the server-to-client replies to the client.
Hop count in DHCP requests
When a DHCP client broadcasts requests, the DHCP relay agent in the routing switch receives the packets and forwards them to the DHCP server (on a different subnet, if necessary.) During this process, the DHCP relay agent increments the hop count before forwarding DHCP packets to the server. The DHCP server, in turn, includes the hop count in DHCP header from the received DHCP request in the response sent back to a DHCP client. This is enabled by default.
Configuring a BOOTP/DHCP relay gateway
The DHCP relay agent selects the lowest-numbered IP address on the interface to use for DHCP messages. The DHCP server then uses this IP address when it assigns client addresses. However, this IP address may not be the same subnet as the one on which the client needs the DHCP service. This feature provides a way to configure a gateway address for the DHCP relay agent to use for relayed DHCP requests, rather than the DHCP relay agent automatically assigning the lowest-numbered IP address.
Configure DHCP relay
Helper address configuration on an interface is allowed even if routing is disabled on the interface, but DHCP relay functionality will be inactive on that interface. In case a client has received an IP address, and no routing is configured, the IP address is valid on the client until the lease time expires.
[no] dhcp-relay Enable/Disable dhcp-relay. By default, it is enabled.
[no] ip helper-address <IPv4-address> Configure the IP helper-address needed by DHCP relay on a particular interface.
Explanation of parameters
• IPv4-address — The IPv4 address of the protocol server. This is a unicast address of a destination server on another subnet. The maximum number of helper addresses that can be configured per interface is eight. DHCP relay functions on L3 interfaces that include split-interfaces and sub-interfaces.
show ip helper-address [interface <interface-name>] Displays the configured IP helper-address(es).
Explanation of parameters
• interface <interface-name> — The interface on which server addresses are configured.
Волчье логово / Ulvens Lair / Wolfshöhle / Wolfs Lair
Все очень просто: в данной схеме присутствует маршрутизатор, который, как известно, разбивает на части широковещательный домен и не передает широковещательные сообщения из одной сети в другую. Следовательно, РС0 и DHCP SERVER находятся в разных широковещательных доменах, а значит, без дополнительных настроек недостижимы. Broadcast от PC0 будет сброшен маршрутизатором, и РС0 не получит требуемого адреса из своей сети.
Тем не менее выход из данной ситуации есть: настройка DHCP-Relay. Мы можем заставить промежуточное устройство передавать широковещательные DHCP-запросы между клиентами и серверами, которые находятся в разных широковещательных доменах.
В случае настройки Relay-агента, в поле giaddr появится адрес того устройства, которое будет пересылать DHCP-запросы. В случае предлагаемой схемы, в поле будет стоять адрес интерфейса маршрутизатора GW, направленного в сторону сегмента, в котором расположен РС0. Ответы от DHCP-сервера будут направлены relay-агенту, а он уже будет отправлять их конечному хосту, запрашивающему сетевые настройки.
Практическая часть
С теорией все понятно. Теперь применим полученные знания к задачам, возникающим на практике. Попробуем начать с простых задач, и дойдем до (на мой взгляд) более-менее сложных.
Вариант № 1
УСЛОВИЕ: Имеем коммутатор L3 (Cisco 3750-X). Запустим на нем DHCP-Server и будем раздавать настройки всем устройствам, подключенным к нашему коммутатору.
Откровенно говоря, DHCP-сервер лучше всего создавать на маршрутизаторе. Но в данном случае все равно попробуем сделать это на коммутаторе L3, раз он умеет выполнять такую роль. Синтаксис может отличаться в зависимости от версии IOS.
Предлагаемая схема проста и представлена на рисунке ниже.
На схеме присутствует еще один коммутатор L2, но это не принципиально, т.к. на обработку сообщений DHCP они никак не влияет. В сети будем использовать адресное пространство 10.10.10.0/24, адрес основного шлюза 10.10.10.254, адрес коммутатора L3 — 10.10.10.253
Конфигурация коммутатора выглядит следующим образом:
Создадим SVI для возможности подключения к коммутатору с помощью Telnet/SSH
L3_Core_SW(config)#interface vlan 1
L3_Core_SW(config-if)#ip address 10.10.10.253 255.255.255.0
L3_Core_SW(config-if)#no shutdown
Использовать VLAN 1 не самое правильное решение, но для тестовой схемы будем использовать его. Далее приступим к созданию DHCP-пула. Во-первых, исключим адреса, которые мы выдали серверам, шлюзам, сетевым устройствам. Например исключим диапазон с 10.10.10.250 по 10.10.10.254:
L3_Core_SW(config)#ip dhcp excluded-address 10.10.10.250 10.10.10.254
Создадим пул адресов с именем LocalNet и укажем, какие параметры необходимо выдавать хостам:
L3_Core_SW(config)#ip dhcp pool LocalNet
L3_Core_SW(dhcp-config)#network 10.10.10.0 255.255.255.0
L3_Core_SW(dhcp-config)#default-router 10.10.10.254
L3_Core_SW(dhcp-config)#dns-server 8.8.8.8
L3_Core_SW(dhcp-config)#domain-name LovelyWork
Cisco DHCP-Server позволяет выдавать пользователям гораздо больше параметров, чем перечислено в данном отрывке конфигурации. Здесь определено только адресное пространство, маска подсети (длина префикса), адрес основного шлюза и DNS-сервера, имя домена. На этом настройка DHCP-Server’а на Cisco коммутаторе можно завершить и проверить работоспособность данного решения. Для этого запустим debug и посмотрим на приходящие от хоста сообщения.
L3_Core_SW#debug ip dhcp server packet
DHCP server packet debugging is on.
L3_Core_SW(dhcp-config)#
*Mar 2 00:12:58.908: DHCPD: Reload workspace interface Vlan1 tableid 0.
*Mar 2 00:12:58.908: DHCPD: tableid for 10.10.10.253 on Vlan1 is 0
*Mar 2 00:12:58.908: DHCPD: client’s VPN is .
*Mar 2 00:12:58.908: DHCPD: using received relay info.
*Mar 2 00:12:58.908: DHCPD: DHCPDISCOVER received from client 0100.0d60.7886.dc on interface Vlan1.
*Mar 2 00:12:58.908: DHCPD: using received relay info.
*Mar 2 00:13:00.921: DHCPD: Sending DHCPOFFER to client 0100.0d60.7886.dc (10.10.10.1).
*Mar 2 00:13:00.921: DHCPD: no option 125
*Mar 2 00:13:00.921: DHCPD: Check for IPe on Vlan1
*Mar 2 00:13:00.921: DHCPD: creating ARP entry (10.10.10.1, 000d.6078.86dc).
*Mar 2 00:13:00.921: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (10.10.10.1).
*Mar 2 00:13:00.929: DHCPD: Reload workspace interface Vlan1 tableid 0.
*Mar 2 00:13:00.929: DHCPD: tableid for 10.10.10.253 on Vlan1 is 0
*Mar 2 00:13:00.929: DHCPD: client’s VPN is .
*Mar 2 00:13:00.929: DHCPD: DHCPREQUEST received from client 0100.0d60.7886.dc.
*Mar 2 00:13:00.929: DHCPD: Sending DHCPACK to client 0100.0d60.7886.dc (10.10.10.1).
*Mar 2 00:13:00.929: DHCPD: no option 125
*Mar 2 00:13:00.929: DHCPD: Check for IPe on Vlan1
*Mar 2 00:13:00.929: DHCPD: creating ARP entry (10.10.10.1, 000d.6078.86dc).
*Mar 2 00:13:00.929: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (10.10.10.1).
Результат работы можно так же увидеть на хосте:
Вариант № 2
УСЛОВИЕ: Возьмем схему из предыдущего варианта и модифицируем её, добавив еще несколько SVI, VLAN, и создав для каждого из VLAN свой DHCP-пул.
К имеющемуся VLAN добавим еще два:
VLAN 2 — Department_A
Network:172.16.1.0/28, IP GW: 172.16.1.14, SVI IP: 172.16.1.13
VLAN 3 — Department_B
Network:172.16.1.16/28, IP GW: 172.16.1.30, SVI IP: 172.16.1.29
Конфигурация коммутатора будет схожа с предыдущем заданием. Пулы настраиваются точно так же:
L3_Core_SW(config)#vlan 2
L3_Core_SW(config-vlan)#name Department_A
L3_Core_SW(config-vlan)#vlan 3
L3_Core_SW(config-vlan)#name Department_B
L3_Core_SW(config-vlan)#exit
L3_Core_SW(config)#interface vlan 2
L3_Core_SW(config-if)#ip address 172.16.1.13 255.255.255.240
L3_Core_SW(config-if)#no shutdown
L3_Core_SW(config-if)#exit
L3_Core_SW(config)#ip dhcp excluded-address 172.16.1.13 172.16.1.14
L3_Core_SW(config)#ip dhcp pool Dep_A
L3_Core_SW(dhcp-config)#network 172.16.1.0 255.255.255.240
L3_Core_SW(dhcp-config)#default-router 172.16.1.14
L3_Core_SW(dhcp-config)#dns-server 8.8.8.8
L3_Core_SW(dhcp-config)#domain-name LovelyDepartment_A
L3_Core_SW(dhcp-config)#exit
L3_Core_SW(config)#interface vlan 3
L3_Core_SW(config-if)#ip address 172.16.1.29 255.255.255.240
L3_Core_SW(config-if)#no shutdown
L3_Core_SW(config-if)#exit
L3_Core_SW(config)#ip dhcp excluded-address 172.16.1.29 172.16.1.29
L3_Core_SW(config)#ip dhcp pool Dep_B
L3_Core_SW(dhcp-config)#network 172.16.1.16 255.255.255.240L3_Core_SW(dhcp-config)#default-router 172.16.1.30
L3_Core_SW(dhcp-config)#dns-server 8.8.8.8
L3_Core_SW(dhcp-config)#domain-name LovelyDepartment_B
Настроим на интерфейсах роли портов доступа (Access interface), и присвоим интерфейсам соответствие одному из VLAN. Порт g2/0/1 оставим без изменений, по умолчанию он будет находится в VLAN1:
L3_Core_SW(config)#int g2/0/2
L3_Core_SW(config-if)#switchport mode access
L3_Core_SW(config-if)#switchport access vlan 2
L3_Core_SW(config-if)#int g2/0/3
L3_Core_SW(config-if)#switchport mode access
L3_Core_SW(config-if)#switchport access vlan 3
Теперь запустим debug DHCP и посмотрим, каким образом будут обрабатываться сообщения от клиентов, находящихся в разных VLAN:
Клиент, подключенный к интерфейсу из VLAN 1:
L3_Core_SW#
*Mar 2 01:01:21.223: DHCPD: Reload workspace interface Vlan1 tableid 0.
*Mar 2 01:01:21.223: DHCPD: tableid for 10.10.10.253 on Vlan1 is 0
*Mar 2 01:01:21.223: DHCPD: client’s VPN is .
*Mar 2 01:01:21.223: DHCPD: using received relay info.
*Mar 2 01:01:21.223: DHCPD: DHCPDISCOVER received from client 0100.0d60.7886.dc on interface Vlan1.
*Mar 2 01:01:21.223: DHCPD: using received relay info.
*Mar 2 01:01:21.223: DHCPD: Sending DHCPOFFER to client 0100.0d60.7886.dc (10.10.10.1).
*Mar 2 01:01:21.223: DHCPD: no option 125
*Mar 2 01:01:21.223: DHCPD: Check for IPe on Vlan1
*Mar 2 01:01:21.223: DHCPD: creating ARP entry (10.10.10.1, 000d.6078.86dc).
*Mar 2 01:01:21.223: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (10.10.10.1).
*Mar 2 01:01:21.223: DHCPD: Reload workspace interface Vlan1 tableid 0.
*Mar 2 01:01:21.223: DHCPD: tableid for 10.10.10.253 on Vlan1 is 0
*Mar 2 01:01:21.223: DHCPD: client’s VPN is .
*Mar 2 01:01:21.223: DHCPD: DHCPREQUEST received from client 0100.0d60.7886.dc.
*Mar 2 01:01:21.223: DHCPD: Sending DHCPACK to client 0100.0d60.7886.dc (10.10.10.1).
*Mar 2 01:01:21.223: DHCPD: no option 125
*Mar 2 01:01:21.223: DHCPD: Check for IPe on Vlan1
*Mar 2 01:01:21.223: DHCPD: creating ARP entry (10.10.10.1, 000d.6078.86dc).
*Mar 2 01:01:21.223: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (10.10.10.1).
Далее этого же клиента подключаем в интерфейс, находящийся в VLAN 3:
*Mar 2 01:02:25.119: DHCPD: Reload workspace interface Vlan3 tableid 0.
*Mar 2 01:02:25.119: DHCPD: tableid for 172.16.1.29 on Vlan3 is 0
*Mar 2 01:02:25.119: DHCPD: client’s VPN is .
*Mar 2 01:02:25.119: DHCPD: using received relay info.
*Mar 2 01:02:25.119: DHCPD: DHCPDISCOVER received from client 0100.0d60.7886.dc on interface Vlan3.
*Mar 2 01:02:25.119: DHCPD: using received relay info.
*Mar 2 01:02:25.119: DHCPD: Sending DHCPOFFER to client 0100.0d60.7886.dc (172.16.1.17).
*Mar 2 01:02:25.119: DHCPD: no option 125
*Mar 2 01:02:25.119: DHCPD: Check for IPe on Vlan3
*Mar 2 01:02:25.119: DHCPD: creating ARP entry (172.16.1.17, 000d.6078.86dc).
*Mar 2 01:02:25.119: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.17).
*Mar 2 01:02:25.128: DHCPD: Reload workspace interface Vlan3 tableid 0.
*Mar 2 01:02:25.128: DHCPD: tableid for 172.16.1.29 on Vlan3 is 0
*Mar 2 01:02:25.128: DHCPD: client’s VPN is .
*Mar 2 01:02:25.128: DHCPD: DHCPREQUEST received from client 0100.0d60.7886.dc.
*Mar 2 01:02:25.128: DHCPD: Sending DHCPACK to client 0100.0d60.7886.dc (172.16.1.17).
*Mar 2 01:02:25.128: DHCPD: no option 125
*Mar 2 01:02:25.128: DHCPD: Check for IPe on Vlan3
*Mar 2 01:02:25.128: DHCPD: creating ARP entry (172.16.1.17, 000d.6078.86dc).
*Mar 2 01:02:25.128: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.17).
И последнее: подключаем клиента к интерфейсу, находящемуся в VLAN2:
*Mar 2 01:03:54.173: DHCPD: Reload workspace interface Vlan2 tableid 0.
*Mar 2 01:03:54.173: DHCPD: tableid for 172.16.1.13 on Vlan2 is 0
*Mar 2 01:03:54.173: DHCPD: client’s VPN is .
*Mar 2 01:03:54.173: DHCPD: using received relay info.
*Mar 2 01:03:54.173: DHCPD: DHCPDISCOVER received from client 0100.0d60.7886.dc on interface Vlan2.
*Mar 2 01:03:54.173: DHCPD: using received relay info.
*Mar 2 01:04:01.236: DHCPD: Sending DHCPOFFER to client 0100.0d60.7886.dc (172.16.1.1).
*Mar 2 01:04:01.236: DHCPD: no option 125
*Mar 2 01:04:01.236: DHCPD: Check for IPe on Vlan2
*Mar 2 01:04:01.236: DHCPD: creating ARP entry (172.16.1.1, 000d.6078.86dc).
*Mar 2 01:04:01.236: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.1).
*Mar 2 01:04:01.236: DHCPD: Reload workspace interface Vlan2 tableid 0.
*Mar 2 01:04:01.236: DHCPD: tableid for 172.16.1.13 on Vlan2 is 0
*Mar 2 01:04:01.236: DHCPD: client’s VPN is .
*Mar 2 01:04:01.236: DHCPD: DHCPREQUEST received from client 0100.0d60.7886.dc.
*Mar 2 01:04:01.236: DHCPD: Sending DHCPACK to client 0100.0d60.7886.dc (172.16.1.1).
*Mar 2 01:04:01.236: DHCPD: no option 125
*Mar 2 01:04:01.236: DHCPD: Check for IPe on Vlan2
*Mar 2 01:04:01.236: DHCPD: creating ARP entry (172.16.1.1, 000d.6078.86dc).
*Mar 2 01:04:01.236: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.1).
Каким образом коммутатор понимает, из какого пула необходимо взять адрес? Стоит обратить внимание на то, что коммутатор делает верный выбор пула, и выдает точно те адреса, которые могут существовать в соответствующем VLAN. Как видно из лога, коммутатор сравнивает пулы с адресом интерфейса, на который приходит DHCPDISCOVER. Если это сообщение приходит на интерфейс SVI VLAN 2, а этот интерфейс находится в одном сетевом сегменте с клиентом, значит нужно выбрать тот пул, который будет включать в себя адрес этого SVI. Аналогично с физическими интерфейсами на маршрутизаторе.
Таким образом, можно создавать множество пулов адресов без каких-либо проблем.
Вариант № 3
Конфигурация коммутатора-DHCP-сервера представлена ниже. Фактически, мы оставляем на нем созданные ранее DHCP-пулы, а так же создаем маршрутизируемй интерфейс, который будет находиться в VLAN 4.
Параметры VLAN 4:
VLAN 4 -Servers
Network:10.10.5.0/24, IP DHCPServer: 10.10.5.200, SVI IP: 10.10.5.253
DHCPServer#sh run
Building configuration.
*Mar 2 02:02:59.417: %SYS-5-CONFIG_I: Configured from console by console
Current configuration : 2311 bytes
!
! Last configuration change at 02:02:59 UTC Tue Mar 2 1993
!
version 12.2<omited>
!
hostname DHCPServer
!
ip dhcp excluded-address 10.10.10.253 10.10.10.254
ip dhcp excluded-address 172.16.1.13 172.16.1.14
ip dhcp excluded-address 172.16.1.29 172.16.1.30
!
ip dhcp pool LocalNet
network 10.10.10.0 255.255.255.0
default-router 10.10.10.254
dns-server 8.8.8.8
domain-name LovelyWork
!
ip dhcp pool Dep_A
network 172.16.1.0 255.255.255.240
default-router 172.16.1.14
dns-server 8.8.8.8
domain-name LovelyDepartment_A
!
ip dhcp pool Dep_B
network 172.16.1.16 255.255.255.240
default-router 172.16.1.30
dns-server 8.8.8.8
domain-name LovelyDepartment_B
!<omited>
!
interface GigabitEthernet2/0/24
no switchport
ip address 10.10.5.200 255.255.255.0
!
<omited>
end
Коммутатор, выполняющий роль relay-агента и маршрутизатора для межсетевого взаимодействия, имеет следующую конфигурацию:
RelayAgent#sh run<omited>
!
hostname RelayAgent
!
ip routing
!
interface GigabitEthernet1/0/1
!
interface GigabitEthernet1/0/2
switchport access vlan 2
switchport mode access
!
interface GigabitEthernet1/0/3
switchport access vlan 3
switchport mode access
!
interface GigabitEthernet1/0/4
switchport access vlan 4
switchport mode access
!<omited>
!
interface Vlan1
ip address 10.10.10.253 255.255.255.0
ip helper-address 10.10.5.200
!
interface Vlan2
ip address 172.16.1.13 255.255.255.240
ip helper-address 10.10.5.200
!
interface Vlan3
ip address 172.16.1.29 255.255.255.240
ip helper-address 10.10.5.200
!
interface Vlan4
ip address 10.10.5.253 255.255.255.0
!
<omited>
Для настройки relay к каждому SVI был добавлен helper-address, ссылающийся на DHCP-сервер.
Подключим клиентское устройство к порт Gi1/0/3 (VLAN 3) на коммутаторе RelayAgent и рассмотрим лог команды debug:
Сообщение от клиента приходит на интерфейс VLAN 3
RelayAgent#
*Mar 2 03:05:17.120: DHCPD: Reload workspace interface Vlan3 tableid 0.
*Mar 2 03:05:17.120: DHCPD: tableid for 172.16.1.29 on Vlan3 is 0
*Mar 2 03:05:17.120: DHCPD: client’s VPN is .
*Mar 2 03:05:17.120: DHCPD: using received relay info.
*Mar 2 03:05:17.120: DHCPD: Looking up binding using address 172.16.1.29
Для передачи сообщения далее, в другую сеть, агент устанавливает в поле giaddr адрес интерфейса, на который он получил сообщение от клиента и переправляет это сообщение в другую сеть (VLAN 4):
*Mar 2 03:05:17.120: DHCPD: setting giaddr to 172.16.1.29.
*Mar 2 03:05:17.120: DHCPD: BOOTREQUEST from 0100.0d60.7886.dc forwarded to 10.10.5.200.
Ответ от DHCP-сервера приходит соответственно на SVI, принадлежащий VLAN 4, в котором и расположен DHCP-сервер. Этот ответ обрабатывается и перенаправляется клиенту. При этом relay-агент создает ARP-запись для выдаваемого сервером адреса:
*Mar 2 03:05:19.133: DHCPD: Reload workspace interface Vlan4 tableid 0.
*Mar 2 03:05:19.133: DHCPD: tableid for 10.10.5.253 on Vlan4 is 0
*Mar 2 03:05:19.133: DHCPD: client’s VPN is .
*Mar 2 03:05:19.133: DHCPD: forwarding BOOTREPLY to client 000d.6078.86dc.
*Mar 2 03:05:19.133: DHCPD: no option 125
*Mar 2 03:05:19.133: DHCPD: Check for IPe on Vlan3
*Mar 2 03:05:19.133: DHCPD: creating ARP entry (172.16.1.18, 000d.6078.86dc).
*Mar 2 03:05:19.133: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.18).
Для сообщений типа DHCPREQUEST и DHCPACK ситуация повторяется:
*Mar 2 03:05:19.142: DHCPD: Reload workspace interface Vlan3 tableid 0.
*Mar 2 03:05:19.142: DHCPD: tableid for 172.16.1.29 on Vlan3 is 0
*Mar 2 03:05:19.142: DHCPD: client’s VPN is .
*Mar 2 03:05:19.142: DHCPD: Finding a relay for client 0100.0d60.7886.dc on interface Vlan3.
*Mar 2 03:05:19.142: DHCPD: Looking up binding using address 172.16.1.29
*Mar 2 03:05:19.142: DHCPD: setting giaddr to 172.16.1.29.
*Mar 2 03:05:19.142: DHCPD: BOOTREQUEST from 0100.0d60.7886.dc forwarded to 10.10.5.200.
*Mar 2 03:05:19.142: DHCPD: Reload workspace interface Vlan4 tableid 0.
*Mar 2 03:05:19.142: DHCPD: tableid for 10.10.5.253 on Vlan4 is 0
*Mar 2 03:05:19.142: DHCPD: client’s VPN is .
*Mar 2 03:05:19.142: DHCPD: forwarding BOOTREPLY to client 000d.6078.86dc.
*Mar 2 03:05:19.142: DHCPD: no option 125
*Mar 2 03:05:19.142: DHCPD: Check for IPe on Vlan3
*Mar 2 03:05:19.142: DHCPD: creating ARP entry (172.16.1.18, 000d.6078.86dc).
*Mar 2 03:05:19.142: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.18).
Стоит посмотреть, есть ли какие-либо интересные изменения в логе debug на самом DHCP-сервере:
DHCPServer#
*Mar 2 03:16:33.309: DHCPD: Reload workspace interface GigabitEthernet2/0/24 tableid 0.
*Mar 2 03:16:33.309: DHCPD: tableid for 10.10.5.200 on GigabitEthernet2/0/24 is 0
*Mar 2 03:16:33.309: DHCPD: client’s VPN is .
*Mar 2 03:16:33.309: DHCPD: using received relay info.
*Mar 2 03:16:33.309: DHCPD: DHCPDISCOVER received from client 0100.0d60.7886.dc through relay 172.16.1.29.*Mar 2 03:16:33.309: DHCPD: using received relay info.
*Mar 2 03:16:33.309: DHCPD: Sending DHCPOFFER to client 0100.0d60.7886.dc (172.16.1.18).
*Mar 2 03:16:33.309: DHCPD: no option 125
*Mar 2 03:16:33.309: DHCPD: unicasting BOOTREPLY for client 000d.6078.86dc to relay 172.16.1.29.*Mar 2 03:16:33.326: DHCPD: Reload workspace interface GigabitEthernet2/0/24 tableid 0.
*Mar 2 03:16:33.326: DHCPD: tableid for 10.10.5.200 on GigabitEthernet2/0/24 is 0
*Mar 2 03:16:33.326: DHCPD: client’s VPN is .
*Mar 2 03:16:33.326: DHCPD: DHCPREQUEST received from client 0100.0d60.7886.dc.
*Mar 2 03:16:33.326: DHCPD: Sending DHCPACK to client 0100.0d60.7886.dc (172.16.1.18).
*Mar 2 03:16:33.326: DHCPD: no option 125
*Mar 2 03:16:33.326: DHCPD: unicasting BOOTREPLY for client 000d.6078.86dc to relay 172.16.1.29.
Вариант №4
Коммутатор L3-Switch/DHCP-Relay Agent был настроен в предыдущем опыте. Остается только настроить DHCP-Server на Windows Server 2012.
На сервере поднимаем MS WinServ2012, настраиваем сетевой адрес вручную на интерфейсе (10.10.5.200/24), включаем соответствующую роль (DHCP Server): Server Manager—>Add roles and Features (на четвертом шаге данного мастера выбираем DHCP Server из списка ролей)—>следуя указаниям, завершаем включение роли.
На следующем шаге необходимо сделать restart сервиса: Start—>Administration Tools—>Services—>DHCP Server—>ПКМ—>В выпавшем меню Restart.
Когда сервис поднимется, приступаем к настройке пулов: Start—>Administrative Tools—>DHCP—>ПКМ на «IPv4»—>New Scope. — Далее, следуя указаниям мастера настраиваем 3 пула для наших целей.
На этом настройка заканчивается. Проверка показывает, что сообщения от клиентов преодолевают relay-агента и доходят до сервера, после чего идут обратно до пользователя без каких-либо проблем.
Можно составить еще какие-либо схемы, используя дополнительные промежуточные устройства. Но логика настройки и работы DHCP остается неизменно.