Windows 2008 dhcp relay server
The following forum(s) have migrated to Microsoft Q&A: All English Windows Server forums!
Visit Microsoft Q&A to post new questions.
Answered by:
Question
Scenario.
I have a stand alone switch with two VLANs (new setup). The DHCP server is on one vlan but is to server the second vlan using DHCP relay.
Problem
The DHCP discover packets are not responded to by the server.
Equipment:
Switch: Alcatel 6850 ( AOS 6.4.2.807.R01)
DHCP client: Win XP sp3
DHCP server: 2008 Server with AD DS and DNS
Switch configuration
vlan 20: port 1/3-5 (IP interface 192.168.1.254)
vlan 60: port 1/7-9) (IP interface 10.10.60.254)
ip helper address = 192.168.1.1
Server configuration
IP: 192.168.1.1
Default set up DHCP server role
Scope: 10.10.60-10 — 10.10.60.29 (255.255.255.0)
Scope options: DNS Server: 127.0.0.1
DNS Domain Name: [our domain]
Tracking
Event log: Empty
Wireshark capture on server: http://filedb.experts-exchange.com/incoming/2011/11_w48/525408/DHCPServerCapture.txt (file extension changed)
dhcp debug: http://filedb.experts-exchange.com/incoming/2011/11_w48/525407/dhcplog.txt
dhcp log file: empty
What could be the cause of this?
Here is a similar problem, but I don’t really get what actions the proposed solution requires http://www.alcatelunleashed.com/viewtopic.php?f=191&t=16379
Answers
All replies
Without having to go through your logs or other links you provided, I can tell you that your design is typical. Most issues related to IP assignment when the DHCP server is on a remote segment has to do with a properly configured DHCP relay agent.
You can easily test your DHCP server, by creating a scope for the 192.168.1.x segment and see if when you plug another computer into that VLAN (20), it is able to obtain an IP address. If you are able to obtain an IP, this will rule out the DHCP server being the problem. Nodes on VLAN 20 will not require the use of a DHCP relay agent.
For a DHCP server to be able to assign an IP to a remote segment, the Relay Agent must update the packet information and include the source network info into the GIADDR portion of the packet so that the DHCP server can determine what scope to use.
I would start by validating whether or not your DHCP server is able to issue IPs on VLAN 20. If it can, then 100% of your focus should be on the router/vlan 60/relay agent configuration.
Установка и настройка DHCP-сервера на Windows Server 2008 R2
В данном руководстве подробно описан и продемонстрирован процесс настройки роли DHCP-сервера на Windows Server 2008 R2.
Для настройки DHCP-сервера на Windows Server 2008 R2 потребуются:
1. Компьютер, под управлением Windows Server 2008 R2 (О том как установить Windows Server 2008 R2 можно прочитать в данной статье: «Установка и активация Windows Server 2008 R2 с USB флешки» );
2. Установленная и настроенная роль Active Directory Domain Services (контроллер домена) на Windows Server 2008 R2 (О том как установить Active Directory Domain Services можно прочитать в данной статье: «Установка контроллера домена Active Directory в Windows Server 2008 R2» );
3. Настроенный DNS-сервер на Windows Server 2008 R2 (О том как настроить DNS-сервер можно прочитать в данной статье: «Настройка DNS-сервера в Windows Server 2008 R2» ).
Порядок установки и настройки DHCP-сервера на Windows Server 2008 R2
1. Откройте окно диспетчера сервера, выберите пункт Роли, затем Добавить роли (Рис.1).
2. В появившемся окне нажмите Далее (Рис.2).
3. Поставьте галочку напротив DHCP-сервер, затем нажмите Далее (Рис.3).
4. Ознакомьтесь с дополнительной информацией касательно роли DHCP-сервера, затем нажмите Далее (Рис.4).
5. Выберите подключение со статическим IP-адресом, затем нажмите Далее (Рис.5).
6. В соответствующие поля введите родительский домен и IPv4-адрес основного DNS-сервера (прим. если у Вас имеется IPv4-адрес дополнительного DNS-сервера — введите его в соответствующее поле), затем нажмите Далее (Рис.6).
7. Выберите пункт WINS не требуется для приложений в этой сети (прим. в данном руководстве WINS не рассматриваются), затем нажмите Далее (Рис.7).
8. В настройках DHCP-областей нажмите Добавить… (Рис.8).
9. Введите Имя области (прим. оно может быть любым, в данном руководстве это Local-net). Определите диапазон IP-адресов и введите в поля Начальный IP-адрес и Конечный IP-адрес (прим. в данном руководстве это 192.168.0.150 — 192.168.0.200, т.е. 50 IP-адресов). Укажите тип подсети Проводной и поставьте галочку напротив Активировать эту область. В параметрах конфигурации, распространяемых на DHCP-клиент в соответствующих полях введите маску подсети (прим. в данном руководстве она выбрана по умолчанию 255.255.255.0) и основной шлюз (прим. в данном руководстве это 192.168.1.1), затем нажмите ОК (Рис.9).
10. Выделите созданную область и нажмите Далее (Рис.10).
11. Выберите Отключить режим без отслеживания состояния DHCPv6 для этого сервера, затем нажмите Далее (Рис.11).
12. В окне авторизации DHCP-сервера выберите пункт Использовать текущие учётные данные, затем нажмите Далее (Рис.12).
13. Проверьте выбранные параметры и нажмите Установить (Рис.13).
14. После окончания установки нажмите Закрыть (Рис.14).
Установка и настройка DHCP-сервера на Windows Server 2008 R2 завершена!
Волчье логово / Ulvens Lair / Wolfshöhle / Wolfs Lair
Шпаргалки и заметки о сетевых технологиях, серверах, СХД, IT в принципе. И о разном другом) Чтоб самому не забывать, и другим помочь.
четверг, 20 июня 2013 г.
DHCP Relay: Теория и практика настройки DHCP-Relay
Теоретическая база
- Хост подключается к сети. У него нет никаких сетевых настроек, поэтому он должен запросить их каким-либо образом. Но перед этим необходимо обнаружить DHCP сервер. Поэтому первое, что делает хост — отправляет сообщение типа DHCPDISCOVER. Данное сообщение является широковещательным (broadcast message). Сообщение использует L2/L3 широковещательные адреса в соответствующих полях заголовков.
- После того, как сервер DHCP получает сообщение DHCDISCOVER, он выбирает из своей базы данных свободный адрес, и далее, создав запись в своей ARP-таблице (соответствие присланного MAC-адреса и выданного IP-адреса), отправляет хосту предложение с настройками в виде сообщения типа DHCPOFFER, которое отсылается как unicast-сообщение на L2, с использованием адреса сервера на втором уровне и MAC-адреса отправителя.
- После того, как клиент получает DHCPOFFER от сервера, он отсылает назад сообщение типа DHCPREQUEST, с помощью которого он просит теперь уже создать аренду (закрепить её на сервере не просто в виде ARP-записи) и подтвердить правильность полученных настроек и аренды.
- Получив 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 остается неизменно.