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

   В рабочей практике столкнулся с необходимостью настройки такой вещи, как DHCP-Relay. Имея небольшой практический опыт, а так же теоретическую базу, которую получил во время подготовки к CCNA и его последующем преподавании, решил, что все просто. Собственно, настроил, как помнил и... ничего не заработало. Поэтому придется разобрать данную технологию чуть подробнее, и рассмотреть различные схемы, в которых используется DHCP-Relay.

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

DHCP

   Протокол DHCP (Dynamic Host Configuration Protocol) предназначен для автоматической раздачи хостам сетевых настроек. Протокол позволяет выдать пользователям необходимый IP-адрес, маску подсети, адрес основного шлюза, адрес DNS-сервера и иные настройки, необходимые пользователям. Подробно работа протокола DHCP описана в RFC 2131. Тем не менее, постараюсь дать краткое описание работы DHCP.

   Существует три механизма назначения адресов и настроек пользовательским устройствам:

- Ручное присвоение (Manual Allocation): администратор вручную предназначает адреса пользовательским устройствам на сервере, а DHCP нужен лишь для доставки этих настроек непосредственно пользователям.

- Автоматическое назначение (Automatic Allocation): DHCP автоматически выбирает адреса из набора (пула) адресов и выдает их пользователям, но при этом присваивает их перманентно, навсегда закрепляя адрес за пользователем.

- Динамическое назначение (Dynamic Allocation): DHCP автоматически присваивает адреса устройствам из некоторого пула адресов, но адрес выдается на некоторое время (время аренды/leasing time). Если хост отключился от сети, его адрес может быть выдан кому-нибудь другому при условии, что время аренды на сервере так же истекло.

   Работа устройства с DHCP-сервером выполняется в четыре шага:

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 использует UDP в качестве протокола транспортного уровня. При этом используется два порта: 67 - порт "DHCP Server" - для отправки сообщений от клиента серверу, и порт 68 - "DHCP Client" - для отправки сообщений от сервера клиенту.

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

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

   Значение полей: 

Operation Code (OP) - Определение типа сообщения: 1 - запрос, 2 - ответ;

Hardware Type (htype) - Идентификация типа технологии подключения, например:1 - Ethernet, 15 - Frame Relay, 20 - serial line;

Hardware Address length (hlen) - 8-битовое поле, значение которого указывает на длину адреса L2;

Hops - используется при работе DHCP-Relay;

Transaction Identifier (xid) - 32-битный идентификатор, который генерируется клиентом для того, чтобы сопоставить запрос с ответом от сервера;

Seconds (secs) -Заполняется клиентом и указывает на количество времени с начала процесса получения/обновления настроек;

Flags - Используется только один бит этого поля, остальные должны быть равны нулю. Клиент, не имеющий адреса устанавливает флаг Broadcast (ставит 1 в соответствующее поле). Данный флаг оповещает DHCP-сервер или агента о том, что ответ на данный запрос должен быть направлен в виде широковещательного сообщения.

                                    1 1 1 1 1 1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |B|             MBZ             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                B:  BROADCAST flag

                MBZ:  MUST BE ZERO (reserved for future use)

Client IP Address (ciaddr) - Клиент ставит в данное поле свой адрес в случае, если он правильный, а клиент находится в состоянии BOUND/RENEW/REBINDING, и может отвечать на ARP запросы;

Your IP Address (yiaddr) - Адрес, присваеваемый клиенту сервером;

Server IP Address (siaddr) - Адрес сервера, который будет использоваться клиентом во время процесса получения настроек. Адрес ставится в данное поле в сообщениях типа DHCPOFFER и DHCPACK;

Gateway IP Address (giaddr) - Адрес, используемый в случае работы с DHCP-relay.

Client Hardware Address (chaddr) - Физический адрес клиента;

Server Name (sname) - сервер в сообщениях типа DHCPOFFER и DHCPACK может поставить свое сетевое имя в данное поле

Boot Filename (file) - может опционально использоваться клиентом для запроса специфического типа загрузочного файла в сообщениях DHCPDISCOVER. Сервер в ответ (DHCPOFFER) указывает в данном поле прямую ссылку/специфическую директорию, где находится данный загрузочный файл;

Options -  Поле, позволяющее дополнять необходимыми настройками протокол DHCP. Его могут использовать разработчики в случае необходимости.

Как работает DHCP на практике можно увидеть из предложенных ниже изображений. Первое, что делает клиент - отсылает DHCPDISCOVER со своего физического интерфейса.

 

Далее сервер отвечает DHCPOFFER-сообщением, высылая настройки хосту. Видно, что адрес 10.10.10.73 - адрес, который выдается нам. Стоит так же обратить внимание на порты, с которых и на которые отсылаются данные сообщения:

 Далее следует сообщение типа DHCPREQUEST от клиента, где в опциональных полях клиент указывает настройки, полученные от сервера, и просит подтвердить их правильность :

На что сервер отвечает DHCPACK:

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-Relay. Пусть на коммутаторе L3 создано 4 VLAN, в 3х виртуальных сетях расположены пользователя, а DHCP-сервер настроен на другом коммутаторе L3, который находится в отдельном VLAN.

  
Конфигурация коммутатора-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.

 
   Из лога видно, что все общение сервера идет через агента. Еще одна заметная особенность: DHCP сервер не создает ARP записей в своей таблице, т.к. он не находится в одном и том же сегменте с клиентом.

Вариант №4

УСЛОВИЕ: Схема такая же, как и в варианте №3, но вместо DHCP-сервера на cisco-образном устройстве воспользуемся полноценным DHCP-сервером, поднятом на Windows Server 2012. Именно такая схема почему-то не заработала у заказчика.

   Коммутатор 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 остается неизменно.