Настройка DHCP Relay Agent в Windows Server 2012

Протокол 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-ретранслятора закончена и можно переходить к тестированию его работы.

Волчье логово / Ulvens Lair / Wolfshöhle / Wolfs Lair

Шпаргалки и заметки о сетевых технологиях, серверах, СХД, IT в принципе. И о разном другом) Чтоб самому не забывать, и другим помочь.

четверг, 20 июня 2013 г.

DHCP Relay: Теория и практика настройки DHCP-Relay

Теоретическая база

1. Хост подключается к сети. У него нет никаких сетевых настроек, поэтому он должен запросить их каким-либо образом. Но перед этим необходимо обнаружить DHCP сервер. Поэтому первое, что делает хост — отправляет сообщение типа DHCPDISCOVER. Данное сообщение является широковещательным (broadcast message). Сообщение использует L2/L3 широковещательные адреса в соответствующих полях заголовков.
2. После того, как сервер DHCP получает сообщение DHCDISCOVER, он выбирает из своей базы данных свободный адрес, и далее, создав запись в своей ARP-таблице (соответствие присланного MAC-адреса и выданного IP-адреса), отправляет хосту предложение с настройками в виде сообщения типа DHCPOFFER, которое отсылается как unicast-сообщение на L2, с использованием адреса сервера на втором уровне и MAC-адреса отправителя.
3. После того, как клиент получает DHCPOFFER от сервера, он отсылает назад сообщение типа DHCPREQUEST, с помощью которого он просит теперь уже создать аренду (закрепить её на сервере не просто в виде ARP-записи) и подтвердить правильность полученных настроек и аренды.
4. Получив DHCPREQUEST, сервер проверяет арендованный адрес и остальную информацию, которая была выслана ранее. Сервер отсылает unicast-сообщение типа DHCPACK, дублирующее DHCPOFFER. Клиент после получения DHCPACK проверяет, нет ли подобного адреса еще у кого-либо: проводится ARP опрос на выданный адрес. Если ответа не пришло, значит адрес в пределах широковещательного домена уникален.

DHCP сообщение выглядит следующим образом:

DHCP-Relay

Все очень просто: в данной схеме присутствует маршрутизатор, который, как известно, разбивает на части широковещательный домен и не передает широковещательные сообщения из одной сети в другую. Следовательно, РС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
!
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
!
!
interface GigabitEthernet2/0/24
no switchport
ip address 10.10.5.200 255.255.255.0
!

end

Коммутатор, выполняющий роль relay-агента и маршрутизатора для межсетевого взаимодействия, имеет следующую конфигурацию:
RelayAgent#sh run

!
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
!
!
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
!

Для настройки 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 остается неизменно.