Since DHCP Discovery broadcasts initially and to avoid the need for ip-helper addresses, the L3 switch where your users or servers connect is generally the better spot for DHCP. You didn’t mention multiple VLANs, and with the size equipment you have, I assumed just one, so you just need DHCP configured for that VLAN.
You could put the DHCP scope on your router if it’s L2 adjacent to the users. If it isn’t, then you need ip-helper config in your L3 switch VLAN to get the DHCP broadcasts sent unicast to the router (DHCP server).
Edit: With your update on topology and VLANs, I would still lean toward the L3 switch for the location of your DHCP scopes. With the router failing, no DHCP discovery or renewal could take place which could impact your internal-only traffic.
Ideally, you have multiple switches or DHCP servers so you can have distinct scopes on them — not overlapping, each serving half of the addresses. On a 172.16.1.0/24 subnet, and skipping the first 4 addresses, one server could scope 172.16.1.4-127/24 and the other server 172.16.1.128-254/24. [172.16.1.1 reserved for your gateway addr with .2 and .3 reserved if you were running HSRP]
@hunter2-2
Начинающий системный администратор
Привет всем! Просвятите, пожалуйста, как правильно с точки зрения системного администратора разворачивать сетевую инфраструктуру в организации?
Чтобы было понятно о чём речь, я перечислю несколько вариантов, укажите на самый технически правильный или опишите свой.
1. Все через один сервер, в котором сетевая карта с двумя входами: доступ в интернет, прокси, AD, Exchange, раздача ip от dhcp — все на одной машине, возможно есть реплика.
2.Есть коммутатор, к нему приходит кабель провайдера. В тот же коммутатор включены хосты на том же этаже, свитчи на других этажах + сервер с AD, Exchange и прочим.
3. В отдельную сетевую «железку» (например от cisco или mikrotik) приходит кабель провайдера, она же раздает адреса по своему dhcp. В этой же сети сервер с windows server, но на нем только AD, Exchange и по необходимости другие роли.
-
Вопрос задан
-
3382 просмотра
Вариант 1 используют очень храбрые, очень …неумные либо фанаты Microsoft, непоколебимо верящие в силу файрволла от MS. Если это про Вас — Ваш выбор.
Вариант 2 используют те, кто любит постоянно лечить компы юзеров от майнеров и жаловаться на то, что почту блокируют за спам. Ну, либо тот, кому совсем уж нечего скрывать 
Если это про Вас — Ваш выбор.
Вариант 3 уже больше похож на типовую схему построения.
DHCP не стоит держать на роутере. Роутер должен делать то, для чего предназначен — роутить. Ну еще файрволл и VPN, по необходимости. DHCP относится к базовым ролям внутренней сети и держать его IMHO нужно на сервере AD — нагрузка копеечная, зато если вовремя заполнять данные оснастки — можно использовать ее в качестве таблицы распределения IP — не весь же сегмент у Вас динамика, сервера как правило имеют статические адреса.
Эксч категорически рекомендуется отделить от AD. Прокси, если есть — тоже отделить. При нынешних технологиях виртуализации это сделать куда как просто. Файлопомойку — тоже отделить.
Пригласить эксперта
Задачи бывают очень разные.
Скажем вам нужно VPN сделать на роутере или шлюзе.
Если у вас 1-2 пользователя — то это дело потянет Микротик легко.
Если у вас 50 пользователей — вам для этого нужен настоящий компьютер.
Я бы разделил роли.
DHCP довольно небольшая нагрузка.
Зачем её пихать на сервер?
Пусть будет на роутере.
DHCP нужно пихать на сервер если есть какая то веская причина.
Скажем у меня это на сервере, так как нужна интеграция с DHCP+BOOTP (или PXE — не помню уже, 100 назад настраивал)
А для серверов желаю вам изучить технологию виртуализации. ESX, Xen, KVM.
Позволяет здорово упросить оживление сервера в случае чего.
Вполне можно раздавать DHCP прямо с роутера из внешнего мира который связь дает.
Они сейчас довольно совершенны в этом плане.
Но с другой стороны, если вы заходите кого то лимитировать, отрезать от интернета,
то, возможно вам такой вариант и не подойдет.
Как уже отметили всё весьма индивидуально и зависит от имеющихся ресурсов, задач, планов на будущее и прочего.
Если мы предполагаем небольшой офис, сильную ограниченность по деньгам и другим ресурсам, то я бы сделал что-то вроде этого:
(1) Внешний роутер -> (2) Управляемый коммутатор -> (3) Компьютеры
|
(4) Сервер AD + DHCP + ...
Сервер с двумя сетевыми портами выставлять в интернет одним из портов плохо, потому что потенциальный злоумышленник получает доступ ко многим внутренним ресурсам, взломав лишь один сервер, который, судя по всему, на Windows.
Внешний маршрутизатор пусть делает то, что умеет лучше всего — маршрутизирует. То есть балансировка по двум провайдерам, например, динамическая маршрутизация и т.п. Настраиваются как минимум широкие простые правила файрвола (ACL).
На коммутаторе настраиваются несколько vlan и желательно тоже ACL. Распределение по vlan на основе выполняемых функций. Сервера отдельно, конечно.
Функции внутренних сервисов лучше разделить на несколько серверов. Например, если нужен прокси-сервер, и если есть такая возможность, то лучше использовать отдельный сервер. Засунуть его в отдельный vlan, с чёткими ACL, получится некая DMZ.
Ну а потом покупаем ещё хороший файрвол…
IMHO, что бы ни говорили крутые специалисты, но в первую очередь всё упирается в ресурсы: деньги на железо и лицензии, место для размещения всего оборудования. Если есть в наличии или возможность приобрести только один сервер + одна лицензия на ОС, то естественно всё придётся ставить на одном, если есть ресурсы, то вариантов много.
DHCP сервис малотребовательный, особенно для небольших сетей. Виндовый по соседству с AD/DNS меня ещё ни разу не подводил, но ни разу не подводил также и DHCP на базе pfSense или домашних роутеров (Zyxell/Asus).
Если почтовый сервер находится в локальной сети, то для него я бы посоветовал выделить отдельную машину (хотя бы виртуальную) и отдельный IP-адрес, чтобы зараженный клиентский компьютер или личный смартфон сотрудника в локальной сети не подставлял адрес под антиспам фильтры. Дополнительный адрес у многих провайдеров стоит копейки.
В целях экономии файл-сервер можно прикрутить на контроллере, но может возникнуть неприятная ситуация с закончившимся свободным местом, бэкапами или вредоносом из пользовательской папки. Если есть возможность: на виртуалку или на отдельную железку.
Мой вариант: провайдер приходит в слабый сервер, на котором спокойно живет линукс (точно не помешает освоить), нормально настроенный iptables и fail2ban, которые дадут представление о работе маршрутизатора, там же dhcp+dns+vpn, можно и прокси какой-нить поднять. Squid вполне себе функционален. Из него в коммутатор выходит пара аплинков для внутренней сети. Сейчас AD уже вполне неплохо дружит с линуксами, поэтому авторизацию в том же сквиде сделать не проблема. Ну и плшки типа вланов настроить тоже несложно, что опять же даст практический опыт. К слову, в микротике тот же самый embedded-linux, даже не особо embedded. Готовые сборки типа pfsense — странное решение, потому что чтобы оно нормально работало постоянно нужно патчить, установка нового пакета, как правило, вызовет необходимость обновления, опять же патчей, извращенная некрофилия в общем. Веб интерфейс вырвиглазный. Ну и для небольшой организации exchange — оверхед. имхо.
-
Показать ещё
Загружается…
09 окт. 2023, в 20:31
30000 руб./за проект
09 окт. 2023, в 19:26
1500 руб./в час
09 окт. 2023, в 18:18
1000 руб./за проект
Минуточку внимания
Мы используем Cisco 1921 / K9 с коммутатором SG300 L3. Один сервер DHCP установлен на маршрутизаторе или на SG300? Если оба способны, то в чем причина выбора одного над другим?
Примечание. На коммутаторе SG300 L3 установлено 4 VLANS.
Ответы:
Поскольку обнаружение DHCP осуществляет широковещательную передачу изначально и во избежание необходимости использования адресов ip-helper, коммутатор L3, к которому подключаются ваши пользователи или серверы, обычно является лучшим местом для DHCP. Вы не упомянули несколько VLAN, и, учитывая размер вашего оборудования, я предположил только одну, так что вам просто нужно настроить DHCP для этой VLAN.
Вы можете установить область DHCP на вашем маршрутизаторе, если он находится рядом с пользователями. Если это не так, то вам нужно настроить ip-helper в вашей VLAN-коммутаторе L3, чтобы широковещательные рассылки DHCP отправлялись одноадресной рассылкой на маршрутизатор (DHCP-сервер).
Изменить : С вашим обновлением топологии и VLAN, я все еще склонялся бы к коммутатору L3 для определения местоположения ваших областей DHCP. При сбое маршрутизатора невозможно обнаружить или обновить DHCP, что может повлиять на ваш внутренний трафик.
В идеале у вас есть несколько коммутаторов или DHCP-серверов, поэтому вы можете иметь разные области действия — не перекрывая друг друга, каждая из которых обслуживает половину адресов. В подсети 172.16.1.0/24, пропуская первые 4 адреса, один сервер может охватывать 172.16.1.4-127 / 24, а другой — 172.16.1.128-254 / 24. [172.16.1.1 зарезервировано для вашего адреса шлюза с .2 и .3 зарезервировано, если вы работали с HSRP]
Учитывая топологию, которую вы дали в своем комментарии. Коммутатор L3, вероятно, является лучшим местом для установки сервера DHCP. Это также настраивает вас на случай, если вы добавите дополнительный WAN-маршрутизатор и у вас есть два канала или соединения, входящие в офис. Это исключило бы единственную точку отказа, если бы сервер DHCP находился на одном из маршрутизаторов, которые «ушли»
В противном случае вам потребуется использовать вспомогательный IP-адрес на интерфейсе VLAN.
Это вопрос личных предпочтений. В плоской сети (один сегмент локальной сети) не имеет значения, находится ли DHCP-сервер на маршрутизаторе, коммутаторе или сервере. Все они будут видеть одни и те же широковещательные запросы. Я бы порекомендовал использовать наиболее стабильную («доступную») платформу, которая имеет приемлемые средства конфигурации.
Я запускаю DHCP на своем маршрутизаторе cisco дома — в одной локальной сети. Это центральная точка для настройки всего. И я в порядке с Cli для управления всем. (не то, что есть много, чтобы управлять в моей домашней сети.)
На работе есть DHCP-сервер (windows 2000) в локальной сети главного офиса (где проживает 99% рабочих станций), который отвечает за все 36 сегментов локальной сети через агента dhcp-relay на внутреннем маршрутизаторе. В этом случае это оптимальное место для него, поскольку там почти весь трафик DHCP существует. Это на сервере Windows, потому что люди любят заостренные интерфейсы. (читай: людям, не со мной, легче иметь дело)
Настройте DHCP на интерфейсе шлюза маршрутизатора или используйте «ip helper» для направления запросов на сервер DHCP. Чем более централизована ваша сеть, тем легче ей управлять по мере роста.
Управляемый коммутатор (англ. Managed Switch) – это сетевое устройство для управления трафиком в локальной сети (LAN). В отличие от обычного коммутатора, управляемый коммутатор обладает более расширенными функциями, которые позволяют настраивать и контролировать работу сети.
Управляемый коммутатор или роутер?
Управляемый коммутатор и роутер – это два разных устройства, хотя они имеют схожие функции. Роутер, в отличие от коммутатора, может производить маршрутизацию трафика между разными сетями, такими как LAN и WAN. Управляемые коммутаторы не обладают такой возможностью, но могут контролировать трафик внутри локальной сети.
Как управляемый коммутатор раздает IP-адреса?
Управляемый коммутатор может работать в различных режимах, в том числе в качестве DHCP-сервера. DHCP (англ. Dynamic Host Configuration Protocol) – это протокол для автоматической настройки компьютеров сети, в том числе для выдачи IP-адресов.
Для того чтобы настроить DHCP-сервер на управляемом коммутаторе, необходимо выполнить следующие действия:
- Зайти в настройки коммутатора через веб-интерфейс или консольный интерфейс.
- Настроить адреса сети, на которых будет работать DHCP-сервер.
- Настроить диапазон IP-адресов, который будет выдавать DHCP-сервер.
- Настроить настройки DNS и шлюза по умолчанию.
- Включить DHCP-сервер.
После этого управляемый коммутатор будет раздавать IP-адреса устройствам в локальной сети.
Заключение
Управляемый коммутатор – это устройство для управления трафиком в локальной сети. Он не является роутером, но может работать в качестве DHCP-сервера для выдачи IP-адресов в сети. Настройка DHCP-сервера на управляемом коммутаторе позволяет автоматически настраивать компьютеры и другие устройства в локальной сети.
В рабочей практике столкнулся с необходимостью настройки такой вещи, как DHCP-Relay. Имея небольшой практический опыт, а так же теоретическую базу, которую получил во время подготовки к CCNA и его последующем преподавании, решил, что все просто. Собственно, настроил, как помнил и… ничего не заработало. Поэтому придется разобрать данную технологию чуть подробнее, и рассмотреть различные схемы, в которых используется DHCP-Relay.
Существует три механизма назначения адресов и настроек пользовательским устройствам:
— Ручное присвоение (Manual Allocation): администратор вручную предназначает адреса пользовательским устройствам на сервере, а DHCP нужен лишь для доставки этих настроек непосредственно пользователям.
— Автоматическое назначение (Automatic Allocation): DHCP автоматически выбирает адреса из набора (пула) адресов и выдает их пользователям, но при этом присваивает их перманентно, навсегда закрепляя адрес за пользователем.
— Динамическое назначение (Dynamic Allocation): DHCP автоматически присваивает адреса устройствам из некоторого пула адресов, но адрес выдается на некоторое время (время аренды/leasing time). Если хост отключился от сети, его адрес может быть выдан кому-нибудь другому при условии, что время аренды на сервере так же истекло.
Работа устройства с DHCP-сервером выполняется в четыре шага:
- Хост подключается к сети. У него нет никаких сетевых настроек, поэтому он должен запросить их каким-либо образом. Но перед этим необходимо обнаружить 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 использует 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 остается неизменно.