Dhcp relay что такое: DHCP relay — Википедия. Что такое DHCP relay

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

Протокол DHCP является широковещательным (FAQ по протоколу DHCP) и по умолчанию его пакеты не пересылаются маршрутизаторами из одной сети в другую (маршрутизатор разбивает на части широковещательный домен). Однако это не означает, что в каждой подсети должен находиться отдельный DHCP сервер. Ведь, согласитесь, было бы нелогично в сложных и распределенных сетях со множеством подсетей размещать в каждой подсети с клиентами отдельный DHCP сервер (это неудобно с точки зрения управления и лишнего количества администрируемых единиц оборудования). Гораздо более изящнее и удобнее было бы иметь в сети один DHCP сервер, который будет можно централизованно администрировать, и кроме того, обеспечить его высокую доступность за счет кластеризации.

Что такое DHCP relay и зачем он нужен?

Выходом из подобной ситуации является размещение в сети агента-ретранслятора DHCP (relay agent). Relay agent представляет собой некое промежуточное устройство, которое может пересылать широковещательные   DHCP-запросы между клиентом и сервером DHCP, находящихся в различных широковещательных доменах. Т.е. DHCP relay agent получает от клиента (в этом же сегменте сети) широковещательный пакет на поиск и получение DHCP-адреса и пересылает  этот запрос определенному DHCP серверу (указывается в настройках ретранслятора). Далее ответы от DHCP-сервера будут направлены ретранслятору, который передаст их конечному хосту. Технология DHCP Relay Agent определена в стандарте RFC 1542 («Clarifications and Extensions for the Bootstrap Protocol.»).

В качестве DHCP Relay Agent обычно используют маршрутизаторы (большинство современных маршрутизаторов совместимы с RFC 1542 и могут работать в качестве Relay агента). В том случае, если настроить Relay на маршрутизаторе по каким-либо причинам невозможно, в качестве Relay агента можно настроить компьютер с серверной ОС Windows. Попробуем настроить DHCP Relay Agent на Windows Server 2012.

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

Несколько требований, которые необходимо учитывать при настройке агентов DHCP relay на базе Windows Server:

• Отдельный агент-ретранслятор DHCP необходимо размещать в каждой IP подсети.
• На центральном DHCP сервер нужно создать отдельную DHCP область (Scope) для каждой из обслуживаемых подсетей.
• DHCP relay agent нельзя установить на сервере Windows Server с ролью DHCP, ICS (Internet connection sharing) или c включенной в автоматическом режиме трансляции адресов NAT (Network Address Translation)

DCHP Relay Agent является одной из функций службы Routing and Remote Access (RRAS). Поэтому предварительно  необходимо установите роль RRAS (с дефолтными настройками), после чего запустить MMC оснастку  Routing and Remote Access.

В оснастке RRAS разверните ветку IPv4, щелкните правой кнопкой мыши по элементу General и в контекстном меню выберите пункт New Routing Protocol, выберите DHCP Relay Agent и нажмите ОК.

Щёлкните ПКМ по элементу DHCP Relay Agent и выберите пункт New Interface, укажите сетевой интерфейс, на котором будет слушать Relay –агент.

Затем откройте окно свойств DHCP Relay Agent и укажите ip адрес DHCP сервера, на который нужно перенаправлять все DHCP запросы от клиентов.

На этом настройка DHCP-ретранслятора закончена и можно переходить к тестированию его работы.

Настройка DHCP Relay на коммутаторах доступа SNR-S29xx

Пример настройки функционала DHCP Relay на коммутаторах доступа SNR-29xx

Функционал DHCP Relay обеспечивает ретрансляцию DHCP пакетов от клиента к серверу. Поскольку протокол DHCP основан на широковещательной рассылке, пакеты этого протокола не проходят через маршрутизаторы. Коммутатор, выступающий в роли DHCP relay, перехватывает широковещательные DHCP-пакеты в клиентском vlan, пересылает их по указанному ip-адресу на DHCP сервер и аналогично ретранслирует обратно к клиентам ответы от DHCP сервера.

В данной статье рассматривается пример настройки функционала DHCP Relay на коммутаторах серий SNR-S2940, SNR-S2950, SNR-S2960, SNR-S2980G, SNR-S2965; SNR-S2985G; SNR-S2990G;

Настройки в режиме глобальной конфигурации:

​!

service dhcp # Включаем DHCP сервис

!

ip forward-protocol udp bootps # Включаем перенаправление DHCP пакетов

ip dhcp relay information option # Включаем добавление Option 82 к DHCP пакетам

ip dhcp relay information option subscriber-id format hex # Настраиваем формат опции 82 (опционально)

ip dhcp snooping broadcast suppress # Включаем подавление DHCP бродкаст пакетов

ip dhcp relay share-vlan 300 sub-vlan 310 # Указываем клиентский vlan (310) и vlan управления (300) в который будут перенаправляться DHCP пакеты

!

ip dhcp snooping enable # Включаем DHCP Snooping

ip dhcp snooping vlan 300;310 # Включаем DHCP Snopoing в клиентском vlan и в vlan управления

ip dhcp snooping binding enable # Включаем DHCP SNOOPING binding ( опционально)

!

Настройки порта для клиента:

​!

Interface Ethernet0/0/1 

  switchport access vlan 310

  ip dhcp snooping binding user-control # Включаем привязку MAC-IP к порту на основании DHCP пакетов ( опционально)

  ip dhcp snooping binding user-control max-user 2 # Ограничиваем кол.-во привязок на порту ( опционально)

!

Настройки Uplink порта:

​!

Interface Ethernet0/0/52 # Uplink порт

  switchport mode trunk

  switchport trunk allowed vlan 300;310

  ip dhcp snooping trust  # Настраиваем порт как доверенный для DHCP пакетов

!

Настройки интерфейса управления

​!

interface Vlan300

  ip address 10.0.130.10 255.255.255.0

  ip helper-address 10.0.130.253 # Указываем ip-адрес DHCP сервера, на который необходимо ретранслировать DHCP пакеты.

!

Настройка закончена

Особенности работы и настройки DHCP на маршрутизаторах Cisco (Часть 2) / Хабр

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

1. Конфигурация

В качестве примера возьмем следующую схему:

На маршрутизаторе R3 расположен DHCP-сервер, который централизованно выдает адреса в сети LAN_1 и LAN_2. Маршрутизаторы R1 и R2 в данной схеме являются DHCP-Relay агентами

Сконфигурируем на R3 два пула адресов для каждой локальной сети:

!в режиме глобальной конфигурации определим адреса, которые будут исключены из пула (это адреса интерфейсов R1 и R2

ip dhcp excluded-address 192.168.1.1

ip dhcp excluded-address 192.168.2.1
!создадим пул адресов с именем LAN_1

ip dhcp pool LAN1

network 192.168.1.0 255.255.255.0

ip default-router 192.168.1.1
!создадим пул адресов с именем LAN_2

ip dhcp pool LAN2

network 192.168.2.0 255.255.255.0

ip default-router 192.168.2.1


Естественно, при необходимости можно добавить в пул дополнительные опции.

Следующий этап — конфигурация агентов DHCP-Relay на маршрутизаторах R1 и R2. Суть DHCP-Relay заключается в пересылке широковещательного пакета от клиента одноадресатным пакетом DHCP-серверу.

Конфигурация агентов выполняется следующей командой:

!выбираем интерфейс, на который будет приходить широковещательный запрос от клиентов, в данном случае это интерфейс f0/0 маршрутизатора, который подключен к сегменту сети

interface fa0/0

ip helper-address 10.1.1.2


аналогично конфигурируется маршрутизатор R2

interface fa0/0

ip helper-address 10.1.2.2


Нужно отметить, что команда ip helper-address x.x.x.x заставляет пересылать широковещательные UDP сообщения не только протокола DHCP, по умолчанию будут пересылаться также следующие запросы:

• Time (udp 37)
• TACACS (udp 49)
• DNS (udp 53)
• TFTP (udp 69)
• NetBIOS name service (udp 137)
• NetBIOS datagram service (udp 138)

Если мы хотим исправить ситуацию, в режиме глобальной конфигурации определяем, какие запросы пересылать, а какие — нет:

no ip forward-protocol udp 37

no ip forward-protocol udp 53


2. Как это работает?

Клиент шлет стандартный DISCOVERY:

который пересылается Relay-агентом в направлении DHCP-сервера (измененные поля отмечены красным):

Как видно из картинки, сообщение теперь пересылается одноадресным пакетом с источником 192.168.1.1 (интерфейс маршрутизатора, на который был получен широковещательный пакет) и получателем 10.1.1.2 (адрес, который указан командой ip helper-address. Кроме того, адрес 192.168.1.1 указан в поле Relay agent IP address

На основании адреса источника сообщения DHCP-сервер определяет, из какого пула выдавать адреса. Для маршрутизатора R2 запрос пойдет с адресом источника 192.168.2.1 и сервер выдаст адрес из пула LAN_2.

Предложение OFFER от R3 к R1 выглядит следующим образом:

R1 пересылает его клиенту меняя только адреса источника на 192.168.1.1 и получателя на 192.168.1.2 (ссылка на скриншот)

Вот таким образом выглядит обмен сообщениями между клиентом, агентом и сервером:

3. Заключение

Для правильной работы данного примера важно учесть следующий момент: маршрутизатор R3 получает пакеты от R1 с адресом источника 192.168.1.1, поэтому на R3 сеть 192.168.1.0 должна быть в таблице маршрутизации, я настроил EIGRP между маршрутизаторами для решения этой проблемы. Смотрим таблицу:

R3#sh ip ro

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets

C 10.1.2.0 is directly connected, FastEthernet0/0

C 10.1.1.0 is directly connected, FastEthernet0/1

D 192.168.1.0/24 [90/307200] via 10.1.1.1, 00:00:16, FastEthernet0/1

D 192.168.2.0/24 [90/307200] via 10.1.2.1, 00:02:17, FastEthernet0/0

Спасибо за внимание, обсуждение приветствуется.

Как настроить DHCP Relay на Mikrotik

Прочитано:
12 471

Итак, чтобы разобраться как настраивать DHCP Relay на Mikrotik я поднял для большего и наглядного понимания стенд под Virtualbox основной своей системы Ubuntu Trusty Desktop ноутбука Lenovo E555 (16Gb-оперативной памяти это позволяют).

Развернута VM с осью Windows Server 2016 (Version 10.0.14393) с ролями AD,DNS,DHCP и в настройках данной виртуальной системы указано, что: Машина — Настроить — Сеть — Адаптер №1 — Внутренняя сеть — Имя: intnet

Далее в сервисе DHCP создана область той сети которая будет находиться за шлюзом, в моем случае это 192.168.3.100-192.168.3.200, ниже скриншот для наглядного представления:

Затем поднята еще одна виртуальная система с развернутой операционной системой Mikrotik (см. заметку как развернуть Mikrotik под Virtualbox) с двумя интерфейсами:

• Первый (Адаптер №1) — Внутренняя сеть — Имя: innet → смотрит в сеть где расположен домен контроллер и ролью DHCP в которой он указан, как шлюз.
• Второй (Адаптер №2) — Внутренняя сеть — Имя: innet1 → смотрит в сеть которая уже находится за Mikrotik, т. к. сеть 192.168.3.0/24 собственно на которую я хочу прокинуть DHCP сервис от Windows Server 2016
  На Mikrotik (v6.41.2 on x86) обозначены статические IP адреса, где зеленым цветом обозначен интерфейс отвечающий за сеть после Mikrotik.

Далее настроены правила NAT:

После чего настраивается функция прокладывания запросов от DHCP сервиса во внутреннюю сеть за интерфейсом ether2:
winbox — ip&user&pass — IP — DHCP Relay — Add
вкладка General:

• Name: relay1
• Interface: ether2
• DHCP Server: 192.168.2.2 → это Windows система с ролями DNS,DHCP,AD
• Local Address: 192.168.3.1 → это адрес Mikrotik интерфейс ether2 который смотрит в сеть за Mikrotikом
• Add Relay Info: отмечаю галочкой
• Relay Info Remote ID: relay1
  после нажимаю Apply и Ok.
  А вот сейчас развернута еще одна VM с осью Windows 7 x64 Pro (Version 6.1.7601) где настройки сети виртуальной машины: Машина — Настройки — Сеть — Адаптер №2 — Внутренняя сеть — intnet1, полученные настройки от Mikrotik идут прямиком от DHCP сервиса за ним из второй сети:

А во вкладке DHCP на системе Windows Server 2016 вижу, какой адрес выдался и указанного диапазона данной области:
Win + R → control.exe — Администрирование — DHCP — DHCP — srv-dc.polygon.local — IPv4 — Область [192.168.3.0] relay — Адресованные адреса

Итого, я для себя уяснил, как же это все делается и уже теперь наверное смогу настроить по аналогии и D-Link DFL-860E как требует поставленная задача от моего руководителя. А все выше это было самообразование с использованием тех инструментов и систем которые я могу сымитировать в своей лаборатории. Работает, что еще можно сказать. Но не буду нагромождать данную заметку. На этом всё, с уважением автор блога Олло Александр aka ekzorchik.

Процесс получения IP-адреса по DHCP. Как взаимодействуют DHCP-клиент и DHCP-сервер.

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем разбираться с протоколом DHCP в рамках подготовки к CCNA. На этот раз мы посмотрим на процесс получения IP-адреса по DHCP, а также разберемся с тем как и при помощи каких сообщений происходит взаимодействие между DHCP-сервером и DHCP-клиентом.

9.2.1 Введение

Содержание статьи:

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

9.2.2 Упрощенный алгоритм взаимодействия DHCP-сервера и DHCP-клиента.

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

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

1. Как и в любой порядочной схеме клиент-сервер, взаимодействие по DHCP инициирует клиент. Когда клиент просыпается и осознает, что сетевые настройки нужно получить по DHCP, он формирует специальное широковещательное сообщение, называемое DHCPDISCOVER, этим сообщением он пытается найти DHCP-сервер в своей сети. Вы же помните, что широковещательные сообщения в протоколе Ethernet не выходят за пределы канальной среды?
2. Если в канальной среде с клиентом находится сервер, то он получит DHCPDISCOVER, если сервера нет, то, возможно, это сообщение получит DHCP Relay Agent и перешлет его серверу, если нет и его, то клиент обломится.
3. Но представим, что сервер есть и сообщение он получил. В ответ на DHCPDISCOVER сервер сформирует сообщение, называемое DHCP-предложением или на древнерусском DHCPOFFER. В сообщение DHCPOFFER содержится IP-адрес, который сервер хочет предложить клиенту и другая информация, которая может пригодиться. Сообщение DHCPOFFER может быть отправлено сервером как broadcast, так и unicast, ведь мак-адрес клиента сервер уже изучил. От чего это зависит мы увидим чуть позже.
4. В нашей сети может быть несколько DHCP-серверов, и они все могут получить DHCPDISCOVER от клиента и направить ему DHCPOFFER. Естественно, клиент их все получит и обычно выберет первое неконфликтное предложение от одного единственного сервера. В ответ на выбранный DHCPOFFER клиент сформирует сообщение DHCPREQUEST, из которого будет понятно, с каким сервером он станет дальше дружить. DHCPREQUEST – широковещательное сообщение, это сделано специально, чтобы все сервера в сети видели, какие параметры выбрал клиент и с кем он дальше решил работать.
5. Все серверы получают DHCPREQUEST, но только выбранный сервер продолжит взаимодействие с клиентом, на DHCPREQUEST сервер ответит сообщением DHCPACK, которое служит подтверждением или, если хотите, официальным разрешением от сервера на использование клиентом выбранного IP-адреса.
6. Как только клиент получил сообщение DHCPACK, он переходит в рабочее состояние и смело пользуется IP-адресом.

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

9.2.1 DHCP сообщения, которыми обмениваются клиент и сервер, когда клиент пытается получить IP-адрес

На этой схеме показаны DHCP пакеты, которыми будут обмениваться устройство в тот момент, когда клиент пытается получить IP-адрес от сервера в первый раз, на схеме не показаны сообщения, которые могут возникать при различного рода конфликтах. В общем, это идеальный случай, его вы будете встречать чаще всего.

9.2.3 DHCP-клиент и DHCP-сервер, базовая настройка.

Теперь нам нужно закрепить полученные знания о взаимодействие между DHCP-сервером и DHCP-клиентом на практике, для этого мы расчехлим Cisco Packet Tracer и соберем простую схему, которая показана ниже.

9.2.2 Схема сети для демонстрации взаимодействия между DHCP-клиентом и сервером

Вокруг этой схемы мы и будем плясать, в центре схемы находится обычный L2 коммутатор, в его настройки мы не лезем, поэтому можно смело утверждать, что все устройства в нашей сети находятся в одной канальной среде. К коммутатору подключен роутер, который будет выпускать наших клиентов в Интернет, его мы безбожно обозвали основной шлюз (про разницу между хабами, коммутаторами и роутерами можно почитать здесь). Также на схеме есть два DHCP-сервера, которые уже подключены к коммутатору и три клиента, из которых пока подключен только один.

Перед началом настройки схемы не забудьте переключить Cisco Packet Tracer в режим симуляции. Роутеру и двум серверам нужно будет назначить статический IP-адрес, так как здесь адреса ни при каких сбоях не должны измениться, роутер для клиентов является основным шлюзом, а DHCP-сервера источником настроек. Клиент должен получать настройки динамически.

9.2.3.1 Настройка протокола DHCP на сервере и клиенте в Cisco Packet Tracer

Покажу настройку только одного DHCP-сервера, на втором настройки должны быть идентичны, за исключением IP-адреса. Для начала назначим серверу IP-адрес вручную, сам себе сервер выдавать IP-адреса не умеет.

9.2.3 Настройки протокола IP на DHCP сервере

Серверу я не стал давать адрес шлюза по умолчанию, так как серверу не нужен доступ в Интернет, где найти IP настройки для устройств в Cisco Packet Tracer, вы уже должны знать, показывал и не один раз. Следующим пунктом нашей программы будет настройка DHCP на сервере. Для этого перейдите на вкладку Services и в левом меню выберете DHCP.

9.2.4 Настройки DHCP на сервере

Обратите внимание, здесь уже заполнены поля Start IP Address и Subnet Mask, мы же еще помним, что и клиент, и сервер должны находиться в одной канальной среде, чтобы было всё гуд. Когда мы назначили IP-адрес на интерфейс сервера, Cisco Packet Tracer сам назначил значения в эти поля за нас, если IP-адрес не назначать, то в этих полях будут унылые нули.

Предлагаю пока не трогать эти поля, а изменить значения у полей Pool Name и Default Gateway. Мои настройки показаны ниже.

9.2.5 Продолжаем настраивать DHCP сервер

Все изменения я выделил, для начала был включен DHCP при помощи чекбокса, затем я дал имя новому пулу IP-адресов, который сервер будет использовать для выдачи клиентам, а также была указана дополнительная опция в виде адреса шлюза по умолчанию. Чтобы пул был добавлен, следует нажать кнопку Add, после чего внизу у нас появится два пула IP-адресов: один – этот тот, что создали мы, второй – это тот, что был создан Cisco Packet Tracer автоматически. Чтобы не было проблем, удалите второй, для этого его нужно выделить и нажать на кнопку Remove, если не получится удалить автоматический пул, настройте его так, как я показал и удалите свой собственный. На втором сервере настройки нужно сделать аналогичными, разница будет только в IP-адресе, который вы назначите серверу.

Итак, что мы сделали, чтобы настроить DHCP-сервер, а сделали мы следующее:

1. Настроили IP-адрес на интерфейсе сервера.
2. Создали пул IP-адресов, из которого сервер будет выдавать настройки клиенту.
3. Дали этому пулу имя, так как пулов у DHCP-сервера может быть несколько.
4. Указали начальный IP-адрес пула (поле Start IP Address), это означает, что сервер будет пытаться выдавать IP-адреса, начиная с 192.168.0.1 (а не с 192.168.0.0, ведь сервер понимает, что это номер сети, а также он немного в курсе о том, что в 21 веке мы все используем маску подсети переменной длины, а про классовые сети мы все уже забыли).
5. Также мы дали указание серверу выдавать две опции: маску подсети и IP-адрес шлюза по умолчанию.

Собственно, это всё, что нам сейчас необходимо. Сейчас мы сконфигурировали DHCP-сервер в режиме автоматической выдачи динамических IP-адресов, для нас этот режим самый интересный.

9.2.3.2 Настройки DHCP на клиенте

Настройка DHCP на клиенте гораздо проще, нужно только поставить галочку напротив «Получать IP-адрес по DHCP» и забыть про утомительный ручной труд.

9.2.6 Настройка протокола DHCP на клиенте

Фразы «Гибкая настройка» и Cisco Packet Tracer плохо совместимы, в реальных операционных системах вы сможете задать: какие параметры рабочая станция должна получить по DHCP, а какие параметры вы можете ввести своими руками. Но это нам сейчас не интересно, нам важно разобраться с тем, как клиент получает IP-адрес от DHCP сервера и это мы сделаем. Настройка протокола DHCP на клиенте на этом закончена.

9.2.4 Как клиент получает IP-адрес по DHCP

Схема собрана и настроена, теперь нам надо понять, как клиент получает IP-адрес по DHCP от сервера. В тот момент, когда вы завершите настройку DHCP на клиенте, машина поймет, что она не имеет IP-адрес, а также увидеть указание о том, что она должна получить этот IP-адрес по DHCP. Поэтому первое, что сделает DHCP-клиент – это сформирует запрос DHCPDISCOVER, которым попытается найти сервер.

9.2.7 Клиент сформировал сообщение DHCPDISCOVER

На зеленый пакет, сформированный сервером, не обращайте внимание. Нас интересует желтый пакет, который сформировал клиент, это и есть DHCPDISCOVER, давайте на него посмотрим.

9.2.8 Сообщение DHCPDISCOVER в Cisco Packet Tracer

Здесь сразу видно, что пртокол DHCP работает на прикладном уровне моделей OSI 7 и TCP/IP. Также тут видно, что клиент еще не разу не получал IP-адрес от сервера и даже не знает, где этот сервер находится. На транспортном уровне протокол DHCP инкапсулируется в UDP дейтаграммы, когда клиент делает запрос серверу, то в качестве порта источника он выбирает 68 порт, а в качестве порта назначения используется 67 порт.

Клиент не знает IP-адрес сервера, да и своего у него еще нет, поэтому на сетевом уровне в качестве IP-адреса источника он использует IP-адрес 0.0.0.0, а в качестве IP-адреса назначения используется 255.255.255.255. Мы видим, что это широковещательный запрос.

На канальном уровне клиент указывает свой мак-адрес в качестве источника и широковещательный мак-адрес в качестве назначения. Ниже показана структура пакета DHCPDISCOVER, но с ней мы будем разбираться на примере дампа Wireshark.

9.2.9 Структура пакета DHCPDISCOVER в Cisco Packet Tracer

А сейчас продолжим разбираться и посмотрим, что будет, когда запрос DHCPDISCOVER дойдет до серверов.

9.2.10 Запрос DHCPDISCOVER дошел до всех участников канальной среды

Здесь мы видим, что DHCPDISCOVER, посланный клиентом, дошел до всех участников канальной среды, что и не мудрено, ведь он широковещательный, но этот запрос оказался интересным только двум нашим DHCP-серверам. Когда сервер получил DHCPDISCOVER он понял, что в сети появился клиент, которому нужно выдать IP-адрес, сервер смотрит на пул IP-адресов, который у него есть и ищет свободный адрес, обычно это процесс упорядоченный и клиенту будет выдан первый свободный адрес из пула.

Но тут всё не так просто, дело в том, что компьютерная сеть – это то место, где изменения происходят очень быстро, поэтому прежде чем сформировать DHCPOFFER, сервер должен убедиться, что в сети еще не появился какой-нибудь негодяй, который уже начал использовать IP-адрес, который сервер решил выдать этому клиенту, а может случиться так, что другой сервер выдал  выбранный адрес клиенту чуть раньше, это надо проверить.

Поскольку у нас канальная среда Ethernet, то для проверки будет идеальным протокол ARP, он позволяет опросить все устройства в канальной среде. Вы же знаете, что при помощи ARP-запроса машины узнают мак-адреса по известному IP-адресу. И дело тут в том, что серверу известен IP-адрес, который он хочет выдать клиенту, он его и использует в ARP-запросе и кричит на всю канальную среду: кто использует IP-адрес такой-то?

ARP-запрос – это зеленый пакет, на котором нет значка паузы. Наши сервера настроены одинаково, базы данных у них сейчас одинаковые, поэтому и ARP-запросы они делают одинаковые, сам запрос показан ниже.

9.2.11 DHCP-сервер делает ARP запрос, чтобы проверить занятость IP-адреса

Тут мы видим, что наш первый сервер спрашивает всех соседей по канальной среде: у кого IP-адрес 192.168.0.1, я сервер с IP-адресом 192.168.0.2? Но, как мы помним, адрес 192.168.0.1 мы настроили на роутере, он уже занят. И ничего страшного, что этот адрес занят нашим маршрутизатором, маршрутизатор получит ARP-запрос и любезно на него ответит своим ARP-ответом, получив ответ, наши сервера поймут, что адрес 192.168.0.1 занят и нужно искать следующий адрес для выдачи.

В зависимости от реализации, после ARP-запроса, сервер может еще попробовать и попинговать IP-адрес 192.168.0.1, чтобы окончательно убедиться в том, что он занят. Такие проверки будут продолжаться до тех пор, пока DHCP-сервера не доберутся до IP-адрес 192.168.0.4 в своем пуле, ведь это первый адрес, который еще не используется в нашей сети, для этого адреса будет сформирован ARP-запрос, на который никто не ответит.

9.2.13 ARP-запрос от DHCP сервера, на который никто не ответит

Тут опять же, всё зависит от конкретного DHCP-сервера, ARP-запрос может быть повторен, а после него сервер может еще и попробовать опросить адрес по ICMP, все это нужно, чтобы убедиться, что адрес еще никто не занял, а только после этого формировать сообщение DHCPOFFER.

9.2.14 Сообщение DHCPOFFER от первого DHCP-сервера клиент уже получил, а от второго сервера OFFER еще в буфере коммутатора

На рисунке показано ниже, что сообщение DHCPOFFER широковещательное, хотя это бывает и не всегда так, тут учитывается два момента:

1. Клиент может сообщить DHCP-серверу о том, как он хочет получать ответ: broadcast или unicast.
2. Выбор способа доставки сообщения DHCPOFFER может зависеть от реализации самого сервера и некоторых значений в DHCP пакете.

2.15 Сообщение DHCPOFFER в Cisco Packet Tracer

В любом случае, для доставки DHCPOFFER у сервера есть возможность использовать на канальном уровне как broadcast, так и unicast, ведь мак-адрес клиента он уже изучил, когда получил сообщение DHCPDISCOVER. На рисунке показано, что клиент получил DHCPOFFER от первого сервера. DHCPOFFER второго сервера находится еще в буфере коммутатора, оба сервера предлагают клиенту адрес 192.168.0.4.

9.2.16 Внутренности пакета DHCPOFFER

Рисунок выше показывает, что при первом получении IP-адреса по DHCP в своем пакете сервер указывает свой IP-адрес, а в качестве адреса клиента используется 0.0.0.0. Поскольку это сообщение сформировано сервером, то порт источника 68, а порт назначения 67. Если сейчас заглянуть во внутренности пакета DHCPOFFER, то без всяких пояснений можно увидеть несколько интересных моментов.

Во-первых, сервер понимает, что у клиента еще нет IP-адреса, понимает сервер это потому, что в его базе данных еще нет мак-адреса клиента и нет сопоставления этого мак-адреса с IP-адресом, который был выдан. Во-вторых, мы видим, что сервер предлагает клиенту получить IP-адрес 192.168.0.4. В-третьих, в пакете DHCPOFFER сервер указывает свой IP-адрес, чтобы клиент знал, кто ему это всё предложил.

Получив DHCPOFFER клиент не забирает себе IP-адрес, сперва он должен убедиться, что этот адрес еще никто не использует, для этого он делает ARP-запрос в сеть, в данном случае ему был предложен адрес 192.168.0.4, значит и спрашивать клиент будет: кто в сети использует адрес 192.168.0.4? Клиенты не используют ICMP для проверки, им это не надо, а вот серверам надо, в дальнейшем мы поймем – в каких ситуациях это действительно необходимо.

Если клиент не получит ARP-ответ на свой запрос, то он может смело соглашаться на предложение DHCP-сервера, при этом соглашаться он будет на предложение того сервера, от которого был получен первый DHCPOFFER. Если клиент получит ARP-ответ на свой запрос, то он отправит серверу сообщение DHCPDECLINE, в котором сообщит о том, что он отказывается от его предложения, если же ARP-ответа не будет, то клиент сформирует широковещательное сообщение DHCPREQUEST и отправит его. Таким образом все сервера поймут две вещи:

1. С каким сервером клиент захотел работать.
2. На какой IP-адрес клиент согласился.

В процессе написания я столкнулся с еще одной странностью в Cisco Packet Tracer: после ARP-запроса клиент получил IP-адрес и на этом всё закончилось. Поэтому дальше только словесное описание, а потом мы его дополним дампами из Wireshark.

DHCP сервер, с которым клиент решил сотрудничать, тоже получит DHCPREQUEST и на этот REQUEST сервер должен будет выслать подтверждение в виде DHCPACK. Так сервер сообщает клиенту: пользуйся адресом на здоровье, я внес в свою базу данных информацию о том, что IP-адрес 192.168.0.4 закреплен за тобой. Сообщение DHCPACK может быть отправлено как адресно, так и широковещательно, чаще всего оно отправляется адресно.

Если в командной строке клиента сейчас выполнить команду ipconfig, то можно будет увидеть настройки, которые клиент получил от сервера.

C:\>ipconfig

 

FastEthernet0 Connection:(default port)

 

Link-local IPv6 Address………: FE80::202:17FF:FE54:C07B

IP Address………………….: 192.168.0.4

Subnet Mask…………………: 255.255.255.0

Default Gateway……………..: 192.168.0.1

Чтобы окончательно убедиться в том, что все работает, можете попробовать пропинговать адрес шлюза по умолчанию.

C:\>ping 192.168.0.1

 

Pinging 192.168.0.1 with 32 bytes of data:

 

Reply from 192.168.0.1: bytes=32 time=1ms TTL=255

Reply from 192.168.0.1: bytes=32 time<1ms TTL=255

Reply from 192.168.0.1: bytes=32 time<1ms TTL=255

Reply from 192.168.0.1: bytes=32 time<1ms TTL=255

 

Ping statistics for 192.168.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 1ms, Average = 0ms

Итак, у нас всё хорошо, клиент получил IP-адрес и ряд опций от DHCP-сервера и стал полноценным участником нашей компьютерной сети. Мы пробежались по общему принципу получения IP-адреса по DHCP, далее мы рассмотрим этот процесс изнутри. Для детального разбора я буду использовать свой компьютер, роутер и Wireshark. Компьютер получает IP-адрес от роутера по DHCP, то есть роутер выполняет роль DHCP-сервера.

9.2.5 Выводы

Итак, мы рассмотрели базовый принцип работы протокола DHCP, разобрались с тем, как клиент получает IP-адрес по DHCP и сформировали для себя схему взаимодействия между DHCP-клиентом и DHCP-сервером. Конечно, сейчас мы не разобрали случаи с проблема, например, ситуацию, при которой во время получения IP-адреса клиент или сервер обнаруживают, что этот адрес уже занят, такие ситуации мы рассмотрим позже, когда будем превращать маршрутизатор Cisco в DHCP-сервер.

Настройка Microsoft Windows Server 2016/2019 для предоставления DHCP сервисов для VXLAN (DFA) / Хабр

Назначение этой статьи – упростить настройку DHCP сервиса для фабрики VXLAN BGP EVPN and DFA с использованием Microsoft Windows Server 2016/2019.
В официальной документации DHCP сервис на базе Microsoft Windows Server 2012 для фабрики настраивается как SuperScope, содержащий пул Loopback (в данном пуле – изюминка это исключение из пула всех IP адресов пула (excluded IP address = pool)) и пулы выдачи IP адресов для реальный сетей (здесь изюминка – настраиваются policy – в которых фильтруются DHCP Relay Circuit ID и этот DHCP relay Circuit ID содержит VNI для сети, т. е. для другого пула этот DHCP Relay Circuit ID будет чуть другим).

To configure DHCP on Windows server. 

1. Create a super scope. Within the super scope, create scope B, S1, S2, S3, …, Sn for the subnet B and the subnets for each segment. 
2. In scope B,  specify the 'Exclusion Range' to be the entire address range (so that the offered address range must not be from this scope). 
3. For every segment scope Si, specify a policy that matches on Agent Circuit ID with value of '0108000600XXXXXX', where '0108000600' is a fixed value for all segments, the 6 numbers "XXXXXX" is the segment ID value in hexadecimal. Also ensure to check the Append wildcard(*) check box. 
4. Set the policy address range to the entire range of the scope.

Данная статья содержит ответы на следующие вопросы:

Введение

В этой части кратко перечислены все исходные данные: Инструкции по настройке сетевого оборудования, RFC используемые в DHCP пакетах в фабриках eVPN, справочно приведена эволюция настроек DHCP сервера на Microsoft Windows Server 2012 в документации Cisco. А также краткие сведения о Superscope и Policy в сервисе DHCP на серверах Microsoft Windows Server.

Как настраивается DHCP Relay на фабрике VXLAN BGP EVPN, DFA

Настройка DHCP Relay на фабрике VXLAN BGP EVPN не является основной темой этой статьи, т. к. она достаточно простая. Привожу ссылки на документацию и спойлер по настройкам на сетевом оборудовании.
Пример настройки DHCP Relay на Nexus 9000V v9.2(3)

service dhcp
ip dhcp relay
ip dhcp relay information option
ip dhcp relay information option vpn
interface loopback10
  vrf member VRF1
  ip address 10.120.0.1/32 tag 1234567
interface Vlan12
  no shutdown
  vrf member VRF1
  no ip redirects
  ip address 10.120.251.1/24 tag 1234567
  no ipv6 redirects
  fabric forwarding mode anycast-gateway
  ip dhcp relay address 10.0.0.5
  ip dhcp relay source-interface loopback10

RFC которые реализованы в работе сервиса DHCP Relay в фабриках VXLAN BGP EVPN

RFC#6607: Sub-option 151(0x97) — Virtual Subnet Selection

•	Sub-option 151(0x97) - Virtual Subnet Selection (Defined in RFC#6607)
Used to convey VRF related information to the DHCP server in an MPLS-VPN and VXLAN EVPN multi-tenant environment.

Передается «имя» VRF в котором находиться клиент.

RFC#5107: Sub-option 11(0xb) — Server ID Override

•	Sub-option 11(0xb) - Server ID Override (Defined in RFC#5107.) 
The server identifier (server ID) override sub-option allows the DHCP relay agent to specify a new value for the server ID option, which is inserted by the DHCP server in the reply packet. This sub-option allows the DHCP relay agent to act as the actual DHCP server such that the renew requests will come to the relay agent rather than the DHCP server directly. The server ID override sub-option contains the incoming interface IP address, which is the IP address on the relay agent that is accessible from the client. Using this information, the DHCP client sends all renew and release request packets to the relay agent. The relay agent adds all of the appropriate sub-options and then forwards the renew and release request packets to the original DHCP server. For this function, Cisco’s proprietary implementation is sub-option 152(0x98). You can use the ip dhcp relay sub-option type cisco command to manage the function.

Опция используется для того, чтобы клиент посылал запрос о перепродлении аренды адреса на IP адрес используемый в этой опции. (В Cisco VXLAN BGP EVPN – это Anycast адрес шлюза по умолчанию для клиента.)

RFC#3527: Sub-option 5(0x5) — Link Selection

Sub-option 5(0x5) - Link Selection (Defined in RFC#3527.) 

The link selection sub-option provides a mechanism to separate the subnet/link on which the DHCP client resides from the gateway address (giaddr), which can be used to communicate with the relay agent by the DHCP server. The relay agent will set the sub-option to the correct subscriber subnet and the DHCP server will use that value to assign an IP address rather than the giaddr value. The relay agent will set the giaddr to its own IP address so that DHCP messages are able to be forwarded over the network. For this function, Cisco’s proprietary implementation is sub-option 150(0x96). You can use the ip dhcp relay sub-option type ciscocommand to manage the function.

Адрес сети, из которой клиенту необходим IP адрес.

Эволюция документации Cisco в части настройки DHCP на Microsoft Windows Server 2012

Включил этот раздел потому, что прослеживается положительная тенденция со стороны вендора:

Nexus 9000 VXLAN Configuration Guide 7.3

В документации приведена только настройка DHCP Relay на сетевом оборудовании.

Для настройки DHCP на Windows Server 2012 использовалась другая статья:

Configuring Microsoft Windows Server 2012 to provide DHCP services in an eVPN Scenario (VXLAN, Cisco One Fabric, etc)

В этой статье указывается, что для каждой сети/VNI необходима своя связка SuperScope и свой собственный набор Loopback адресов:

If multiple DHCP Scopes are required for multiple subnets, you need to create one LoopbackX per subnet/vlan on all LEAFS and create a superscope with a loopbackX range scope and actual client IP subnet scope per vlan.

Nexus 9000 VXLAN Configuration Guide 9.3

Добавили настройки Windows 2012 Server в документацию по настройке сетевого оборудования. Для всех используемых пулов адресов необходим один SuperScope на ЦОД и этот SuperScope является границей ЦОД:

Create Superscope for all scopes you want to use for Option 82-based policies.
Note
The Superscope should combine all scopes and act as the administrative boundary.

Cisco Dynamic Fabric Automation

Очень емко рассказано обо всем:

Let us assume the switch is using the address from subnet B (it can be the backbone subnet, management subnet, or any customer designated subnet for this purpose) to communicate with the Windows DHCP server. In DFA we have subnets S1, S2, S3, …, Sn for segment s1, s2, s3, …, sn. 

To configure DHCP on Windows server. 

1. Create a super scope. Within the super scope, create scope B, S1, S2, S3, …, Sn for the subnet B and the subnets for each segment. 
2. In scope B,  specify the 'Exclusion Range' to be the entire address range (so that the offered address range must not be from this scope). 
3. For every segment scope Si, specify a policy that matches on Agent Circuit ID with value of '0108000600XXXXXX', where '0108000600' is a fixed value for all segments, the 6 numbers "XXXXXX" is the segment ID value in hexadecimal. Also ensure to check the Append wildcard(*) check box. 
4. Set the policy address range to the entire range of the scope.

DHCP в Microsoft Windows Server (superscope & policy)

SuperScope

Superscope is an administrative feature of a DHCP server that can be used to group multiple scopes as a single administrative entity. Superscope allows a DHCP server to provide leases from more than one scope to clients on a single physical network. Scopes added to a superscope are called member scopes.

Что такое SuperScope – это функционал, позволяющий объединить несколько пулов IP адресов в одну административную единицу. Чтобы анонсировать пользователям в одной физической сети (в одном VLAN) ip адреса из нескольких пулов. Если запрос пришел к пулу адресов в составе SuperScope, то выдать клиенту адрес можно из другого Scope входящего в этот SuperScope.

Policy

The DHCP Server role in Windows Server 2012 introduces a new feature that allows you to create IPv4 policies that specify custom IP address and option assignments for DHCP clients based on a set of conditions.

The policy based assignment (PBA) feature allows you to group DHCP clients by specific attributes based on fields contained in the DHCP client request packet. PBA enables targeted administration and greater control of the configuration parameters delivered to network devices with DHCP.

Политики – позволяют назначать пользователям IP адреса в зависимости от типа пользователя или параметра. Инженеры Cisco используют политики в Windows Server 2012 для фильтрации по VNI (Virtual Network Identifier).

Основная часть

В данном разделены проведены результаты исследований, почему не поддерживается, как это работает (логика), что нового и как это новое нам поможет.

Почему не поддерживается Microsoft Windows Server 2000/2003/2008?

Microsoft Windows Server 2008 и более ранние версии не обрабатывают опцию 82 (Option 82) и обратный пакет отправляют без опции 82.

Win2k8 R2 DHCP problem with Option82

1. Запрос от клиента отправляется Broadcast (DHCP Discover).
2. Оборудование (Nexus) отправляет пакет к DHCP серверу (DHCP Discover + Option 82).
3. DHCP Сервер принимает пакет обрабатывает, отправляет обратно, но без опции 82. (DHCP Offer – without option 82)
4. Оборудование (Nexus) принимает пакет от DHCP сервера. (DHCP Offer) Но не отправляет этот пакет к конечному пользователю.

Данные снифера — на Windows Server 2008 и на клиенте DHCPWindows Server 2008 получает запрос от сетевого оборудования. (Option 82 присутствует в списке)
Windows Server 2008 отправляет ответ к сетевому оборудованию. (Option 82 отсутствует в списке опций в пакете)

Запрос от клиента – присутствуют DHCP Discover и отсутствуют DHCP Offer

Статистика на сетевом оборудовании:

NEXUS-9000V-SW-1# show ip dhcp relay statistics 
----------------------------------------------------------------------
Message Type             Rx              Tx           Drops  
----------------------------------------------------------------------
Discover                  8               8               0
Offer                     8               8               0
Request(*)                0               0               0
Ack                       0               0               0
Release(*)                0               0               0
Decline                   0               0               0
Inform(*)                 0               0               0
Nack                      0               0               0
----------------------------------------------------------------------
Total                    16              16               0
----------------------------------------------------------------------

DHCP L3 FWD:
Total Packets Received                           :         0
Total Packets Forwarded                          :         0
Total Packets Dropped                            :         0
Non DHCP:
Total Packets Received                           :         0
Total Packets Forwarded                          :         0
Total Packets Dropped                            :         0
DROP:
DHCP Relay not enabled                           :         0
Invalid DHCP message type                        :         0
Interface error                                  :         0
Tx failure towards server                        :         0
Tx failure towards client                        :         0
Unknown output interface                         :         0
Unknown vrf or interface for server              :         0
Max hops exceeded                                :         0
Option 82 validation failed                      :         0
Packet Malformed                                 :         0
Relay Trusted port not configured                :         0
DHCP Request dropped on MCT                      :         0
*  -  These counters will show correct value when switch 
receives DHCP request packet with destination ip as broadcast
address. If request is unicast it will be HW switched
NEXUS-9000V-SW-1#

Почему в Microsoft Windows Server 2012 настройка такая сложная?

В Microsoft Windows Server 2012 еще не поддерживается RFC#3527 (Option 82 Sub-option 5(0x5) — Link Selection)
Но уже реализован функционал Policy.

Как это работает:

• Microsoft Windows Server 2012 есть супер-пул (SuperScope) в котором есть адреса Loopback и пулы для реальных сетей.
• Выбор пула для выдачи IP адреса попадает в SuperScope, т. к. ответ пришел от DHCP Relay с Source адреса Loopback, входящего в SuperScope.
• Используя Policy запрос выбирает из Superscope тот member scope, VNI которого содержится в Option 82 Suboption 1 Agent Circuit ID. (“0108000600”+ 24 бита VNI + 24 бита значения которых мне неизвестно, но сниффер показывает значения 0 в этом поле.)

Как упрощается настройка в Microsoft Windows Server 2016/2019?

В Microsoft Windows Server 2016 реализован функционал RFC#3527. Т. е. Windows Server 2016 умеет распознавать правильную сеть из атрибута Option 82 Sub-option 5(0x5) — Link Selection

Возникают сразу 3 вопроса:

• Можем ли обойтись без Superscope?
• Можем ли обойтись без Policy и перевода VNI в 16-тиричный вид?
• Можем ли обойтись без Scope для Loopback адресов DHCP Source?

Q. Можем ли обойтись без Superscope?
A. Да, scope можно создавать сразу в области IPv4 адресов.
Q. Можем ли обойтись без Policy и перевода VNI в 16-тиричный вид?
A. Да, выбор сети происходит на основе Option 82 Suboption 0x5,
Q. Можем ли обойтись без Scope для Loopback адресов DHCP Source?
A. Нет, не можем. Т. к. в Microsoft Windows Server 2016/2019 действует защита от злонамеренных DHCP запросов. Т. е. все запросы с адресов, которых нет в пуле DHCP сервера считаются злонамеренными.

DHCP Subnet Selection Options

 Note
All relay agent IP addresses (GIADDR) must be part of an active DHCP scope IP address range. Any GIADDR outside of the DHCP scope IP address ranges is considered a rogue relay and Windows DHCP Server will not acknowledge DHCP client requests from those relay agents.

A special scope can be created to "authorize" relay agents. Create a scope with the GIADDR (or multiple if the GIADDR's are sequential IP addresses), exclude the GIADDR address(es) from distribution, and then activate the scope. This will authorize the relay agents while preventing the GIADDR addresses from being assigned.

Т.е. для настройки на Microsoft Windows Server 2016/2019 DHCP пула для VXLAN BGP EVPN фабрики необходимо только:

• Создать пул для Source адресов Relay.
• Создать пул для клиентских сетей

Что не является необходимым (но можно настроить и это будет работать, и не будет мешать работать):

• Создавать Policy
• Создавать SuperScope

ПримерПример настройки DHCP сервера (присутствуют 2 реальных клиента DHCP — клиенты подключены к VXLAN фабрике)
Пример настройки пользовательского пула:
Пример настройки пользовательского пула (выбраны политики — для доказательства что политики не использовались для корректной работы пула):
Пример настройки пула для Source адресов DHCP Relay (диапазон адресов для выдачи полностью соответствует исключению из пула адресов):
Настройка DHCP сервиса на Microsoft Windows Server 2019

Настройка пула для Loopback адресов (source) для DHCP Relay.

Создаем новый пул (Scope) в пространстве IPv4.
Мастер создания пула. «Next >»
Настраиваем имя пула и описание (Description) пула.
Задаем диапазон IP адресов для Loopback и маску для пула.
Добавляем исключения. Диапазон исключений должен полностью совпадать с диапазоном пула.
Время аренды. «Next >»
Запрос: Будете настраивать DHCP опции сейчас (DNS, WINS, Gateway, Domain) или сделаете это позже. Быстрее будет ответить нет, и после активировать пул вручную. Либо пройти до конца не заполняя ни какую информацию и в конце мастера активировать пул.
Подтверждаем, что опции не настроены, пул не активирован. «Finish»
Активируем пул вручную. — Выбираем Scope и в контекстном меню — выбираем «Activate».

Создаем пул для пользователей/серверов.

Создаем новый пул.
Мастер создания пула. «Next >»
Настраиваем имя пула и описание (Description) пула.
Задаем диапазон IP адресов для Loopback и маску для пула.
Добавляем исключения. (По умолчанию исключений не требуется) «Next >»
Время аренды. «Next >»
Запрос: Будете настраивать DHCP опции сейчас (DNS, WINS, Gateway, Domain) или сделаете это позже. Да настроим сейчас.
Настраиваем адрес шлюза по умолчанию.
Настраиваем домен и адреса DNS серверов.
Настраиваем IP адреса WINS серверов.
Активация Scope.
Пул настроен. «Finish»

Заключение

Использование Windows Server 2016/2019 уменьшает сложность настройки DHCP сервера для VXLAN фабрики (или любой другой фабрики). (Не требуется передача IT специалистам специальные связки: Network/Agent Circuit ID для прописывания фильтров.)

Будет ли работать конфигурация для Windows Server 2012 на новых серверах 2016/2019 – да будет работать.

В данном документе приведены ссылки на 2 версии: 7.X и 9.3. Это связано с тем, что версия 7.0(3)I7(7) — Cisco Suggested release, а версия 9.3 — является самой инновационной (вплоть до поддержки Multicast через VXLAN Multisite).

Список источников

1. Nexus 9000 VXLAN Configuration Guide 7.x
2. Nexus 9000 VXLAN Configuration Guide 9.3
3. DFA (Cisco Dynamic Fabric Automation)
4. Configuring Microsoft Windows Server 2012 to provide DHCP services in an eVPN Scenario (VXLAN, Cisco One Fabric, etc)
5. 3.4 DHCP Superscopes
6. Introduction to DHCP Policies
7. Win2k8 R2 DHCP problem with Option82
8. DHCP Subnet Selection Options

Формат, структура и назначение DHCP пакетов и сообщений: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем разбираться с протоколом DHCP в рамках подготовки к CCNA. В протоколе DHCP для сетевого инженера нет ничего сложного, вы в этом убедитесь сразу после того, как мы с вам разберемся со структурой DHCP-пакетов и увидим как сервер и клиент отправляют другу другу сообщения, в этой записи мы разберем четыре самых часто используемых DHCP-сообщения: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK.

Перед началом я хотел бы вам напомнить, что ознакомиться с опубликованными материалами первой части курса можно по ссылке: «Основы взаимодействия в компьютерных сетях».

9.3.1 Введение

Содержание статьи:

Здесь мы рассмотрим структуру DHCP пакета и поговорим о их назначении DHCP-сообщений. В частности будут рассмотрены такие виды DHCP сообщений как: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK. Дам небольшое пояснение по поводу того, что я буду подразумевать под словом DHCP-пакет, а что под DHCP-сообщением. Под первым я буду понимать физическую сущность со строгой структурой, а под вторым я буду понимать логический смысл, который несет в себе физическая сущность, пакет всего один, а сообщений много и они разные.

9.3.2 Общая структура DHCP пакета, назначение его полей и их размер

Мы довольно наглядно рассмотрели процесс получения IP-адреса по DHCP в Cisco Packet Tracer, но хотелось бы понимать то, как устроены пакеты DHCP, которыми обменивается клиент и сервер. Тут у меня для вас две новости:

1. Начну с хорошей. При обмене различными сообщениями и клиент, и сервер используют пакеты с одинаковой структурой, а это означает, что поля в различных DHCP-сообщениях имеют одинаковые названия и одинаковый размер, за исключением поля Options, о котором мы говорили, в записи про DHCP протокол, но в них указываются разные значения.
2. Вторая новость не то что бы плохая, но всё же. Различного рода сообщений в DHCP много и не со всеми вы будете сталкиваться и не все вам будут нужны, но если столкнетесь, то придется почитать RFC, чтобы понять, как это должно работать, а потом заглянуть в дамп, чтобы увидеть, как это работает по факту.

На рисунке ниже вы можете увидеть структуру DHCP-пакета, там показаны поля DHCP пакета и их размер.

9.3.1 Структура DHCP-пакета, поля и их размер

Сама по себе картинка нам еще ничего не дает, кроме названия полей в DHCP-пакета, также мы видим, что пакет разбивается на строки (иначе, машинные слова), каждая строка 32-а бита. Крайний левый бит в слове имеет нулевой порядковый номер, а крайний правый бит 31-ый. Размер всех полей в битах кратен числу 8.

Давайте теперь поговорим более подробно о каждом поле DHCP пакета. Для их описания я подготовил таблицу.

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

9.3.3 Сообщение DHCPDISCOVER или как клиент ищет DHCP сервер?

Начнем мы с сообщения DHCPDISCOVER, как вы помните, это сообщение использует клиент для поиска DHCP-серверов в своей канальной среде. Чтобы не быть голословными, будем смотреть на примере дампа из Wireshark. Для начала посмотрим на то, как клиент инкапсулирует сообщение DHCPDISCOVER.

9.3.2 Как инкапсулируется и передается по сети сообщение DHCPDISCOVER

Всё самое важное подсвечено красным цветом. Мы видим, что в качестве мак-адреса источника клиент подставил свой мак-адрес, а вот мак-адрес сервера он не знает, поэтому использует широковещательный мак-адрес. Даже если клиент будет знать IP-адрес DHCP-сервера, ему это не поможет, ведь для того, чтобы обратиться к серверу по протоколу IP, клиент должен сделать ARP-запрос, а как он это сделает, если у него еще нет IP-адреса?

В заголовке IP-пакета в качестве адреса источника клиент использовал 0.0.0.0, а IP-адрес назначения опять широковещательный – 255.255.255.255. DHCP упаковывается на транспортном уровне в UDP, поскольку сообщение DHSPDISCOVER генерирует клиент, он в качестве порта источника использует значение 68, а в качестве порта назначения 67. Ну и наконец мы видим, что Wireshark смог определить, что это сообщение DHCPDISCOVER. Попробуем определить и мы.

9.3.3 Формат сообщения DHCPDISCOVER

Для этого заглянем внутрь DHCP-пакета и проанализируем значения его полей. В самом верху мы видим тип сообщения Boot Request (это поле opcode), значение 1 говорит нам о том, что это клиент что-то посылает серверу. Следующих два поля сообщают нам, что на канальном уровне используется Ethernet и указана длина аппаратного адреса. Поле Hops имеет значение 0, а значит клиент считает, что он находится с сервером в одной канальной среде. Когда клиент начал общение с сервером, он сгенерировал уникальный Transaction ID, по которому можно будет отличить этот процесс получения IP-адреса от какого-нибудь другого. Поле Second Elapsed никому не интересно, тут обычно стоит 0.

Флаги – отдельная тема, сейчас мы их пропустим. У клиента еще нет и не было IP-адреса, клиент не знает IP-адрес сервера, клиент ничего не знает по DHCP Relay Agent, клиент сам себе не может выдать IP-адрес, поэтом следующих четыре поля имеют значения 0.0.0.0. В поле Client MAC Address клиент сообщает свой мак-адрес серверу. А вот поле Client Hardware Address Padding различается для машин с Windows и Linux, сейчас вы видите значение для Windows, это поле мы обсудим позже.

Далее клиент сообщает серверу о том, что ему не нужно сообщать hostname сервера и не надо давать ссылку на Boot-файл. Ну а поле Magic Cookie сообщает о том, что начались DHCP опции и нам нужно обратить внимание на следующий рисунок.

9.3.4 DHCP опции, которые передает клиент серверу в сообщение DHCPDISCOVER

Во-первых, стоит сразу отметить, что количество опции, да и сами опции, которые будут в сообщение DHCPDISCOVER зависят от настроек клиента. Первая опция имеет код 53, так клиент сообщает всем в сети, что данное сообщение является сообщением DHCPDISCOVER. Опция с кодом 61 используется клиентом, чтобы сообщить свой мак-адрес. В опции с кодом 50 клиент сообщает, что хотел бы получить от сервера IP-адрес 192.168.0.100. Опция с кодом 12 используется клиентом, чтобы сообщить свой hostname.

Опция с кодом 60 служит для того, чтобы клиент мог рассказать серверу о том, кто является разработчиком программного обеспечения DHCP-клиента, и какая версия ПО используется, опираясь на эту опцию сервер может понять с какими опциями умеет работать клиент. DHCP опция с кодом 55 служит для того, чтобы клиент мог запросить у сервера необходимые на его взгляд параметры, при этом не факт, что сервер сможет сообщить клиенту все указанные параметры.

Список опций завершает опция с кодом 255, так сервер поймет, что опций больше не будет и само DHCP-сообщение закончилось.

9.3.4 Сообщение DHCPOFFER или как сервер предлагает клиенту IP-адрес?

Перейдем к сообщение DHCPOFFER, которым сервер отвечает на запрос DHCPDISCOVER от клиента, тут самый первый вопрос, который у вас должен возникнуть: а как сервер отправляет сообщение DHCPOFFER – broadcast или unicast. Правильным будет ответ: сервер может передавать сообщение DHCPOFFER как широковещательно, так и адресно, вот что написано в RFC протокола DHCP.

Если поле giaddr в сообщении DHCP от клиента отлично от 0, сервер передает все отклики на сообщения в порт DHCP server транслятору BOOTP, адрес которого указан в поле giaddr. Если giaddr = 0, а поле ciaddr отлично от нуля, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному адресу ciaddr. Если giaddr = 0, ciaddr = 0 и установлен флаг broadcast, сервер передает сообщения DHCPOFFER и DHCPACK по широковещательному адресу 0xffffffff. Если флаг broadcast не установлен, а giaddr и ciaddr имеют значение 0, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному аппаратному адресу клиента и yiaddr. Во всех случаях, когда giaddr = 0, сервер отправляет сообщения DHCPNAK по широковещательному адресу 0xffffffff.

9.3.5 DHCPOFFER — сообщение, которое отправляет сервер в ответ на DHCPDISCOVER

Если посмотреть на дамп протокола IP, то можно будет увидеть, что сервер не просто направил клиенту DHCPOFFER юникастом, но и более того, в поле IP-адрес назначения был подставлен IP-адрес, который был запрошен клиентом в сообщение DHCPDISCOVER. Главным образом такое поведение DHCP-сервера связано с тем, какие флаги были получены им от клиента.
Обратите внимание, что в сообщение DHCPOFFER сервер еще не использует предлагаемый IP-адрес в поле Client IP Address, там еще находятся унылые нули. В поле Your IP Address сервер предлагает клиенту тот IP-адрес, который он у него запросил, естественно, перед тем как его предложить, сервер убедился в том, что этот адрес свободен. Как видим, сообщение DHCPOFFER по своему содержимому не сильно отличается от DHCPDISCOVER, теперь давайте посмотрим на опции, которые сервер предложил клиенту.

9.3.6 DHCP опции в сообщение DHCPOFFER

Во-первых, опции в сообщение DHCPOFFER, как и в любых других сообщениях, начинаются с Magic Cookie, а заканчиваются 255 опцией. Во-вторых, сервер не знал всех опций, которые у него попросил клиент, поэтому выдал то, что смог. После Magic Cookie сервер сообщает, что этот пакет несете в себе сообщение DHCPOFFER. Следующим шагом он сообщает клиенту свой идентификатор. А вот опция с кодом 51 несет в себе очень важную информацию о времени аренды IP-адреса, об этом времени у нас будет отдельный разговор.

Еще из полезного сервер предложил в качестве опций клиенту IP-адрес шлюза по умолчанию, маску подсети и адрес DNS-сервера.

9.3.5 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса?

Сервер не обязан резервировать за клиентом IP-адрес, который он предлагает в DHCPOFFER, обычно резервирование происходит сразу после или во время отправки сообщения DHCPACK. Но это будет после, сейчас клиент должен сообщить серверу о том, что он согласен на получение предложенного IP-адреса и опций, а также сообщить серверу еще немного полезной информации.

ПРИМЕЧАНИЕ: здесь мы пропускаем все проверки на занятость/свободность IP-адреса, это мы обсудили при прошлом разговоре и сейчас считаем, что они есть и в результате этих проверок IP-адрес свободен.

Давайте посмотрим, как выглядит сообщение DHCPREQUEST в дампе Wireshark.

9.3.7 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса

Сразу бросается в глаза то, что DHCPREQUEST отправляется не адресно, а широковещательно, тут дело в том, что клиент должен сообщить всем серверам о том, какой адрес он хочет получить и с каким сервером он хочет продолжать взаимодействие. Все поля сверху, за исключением поля Message Type, имеют точно такие же значения, как и в сообщение DHCPDISCOVER, а вот поля опций изменились, давайте на них и посмотрим.

Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: IntelCor_b3:71:b7 (bc:a8:a6:b3:71:b7)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 192.168.0.100
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 192.168.0.1
Option: (12) Host Name
Length: 15
Host Name: DESKTOP-B0A442D
Option: (81) Client Fully Qualified Domain Name
Length: 18
Flags: 0x00
A-RR result: 0
PTR-RR result: 0
Client name: DESKTOP-B0A442D
Option: (60) Vendor class identifier
Length: 8
Vendor class identifier: MSFT 5.0
Option: (55) Parameter Request List
Length: 14
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (31) Perform Router Discover
Parameter Request List Item: (33) Static Route
Parameter Request List Item: (43) Vendor-Specific Information
Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
Parameter Request List Item: (252) Private/Proxy autodiscovery
Option: (255) End
Option End: 255

Показываю в виде дампа, так как не удалось вывести все опции в одном скрине. Опция 53 сообщает нам о том, что это сообщение у нас DHCPREQUEST. Далее идут знакомые нам уже опции, а вот на опции с кодом 54 мы остановимся (DHCP Server Identifier), этой опцией клиент сообщает все серверам о том, с кем из них он намерен продолжать сотрудничать. Опцией 81 клиент сообщает серверу свое имя, а вдруг пригодится. А в опции 55 клиент пытается упрекнуть сервера, мол, смотри, сколько я у тебя опций запрашивал и что ты мне выдал, ты точно не сможешь дать мне все то, о чем я тебя прошу?

3.6 Сообщение DHCPACK или как сервер назначает IP-адрес клиенту?

Обычно сервер резервирует IP-адрес клиенту и начинает отсчет времени аренды после того, как отправляет сообщение DHCPACK, этим сообщением он подтверждает клиенту факт выдачи IP-адреса, всё, получите, распишитесь, обращайтесь, если что. Ничего особо нового в DHCPACK сообщение мы не увидим, сервер подтвердит адрес, который запросил клиент и вышлет все опции, которые он может выслать.

9.3.8 Сообщение DHCPACK или как сервер подтверждает выдачу IP-адреса клиенту

Обычно сообщение DHCPACK сервер старается выслать клиенту адресно, не прибегая к широковещанию, хотя иногда бывают и исключения. Главным требованием к содержимому сообщения DHCPACK должна быть непротиворечивость тому, что было отправлено в сообщение DHCPOFFER. Пожалуй, это всё, что следовало сказать про DHCPACK.

3.7 Выводы

Итак, на этот раз мы подробно разобрали структуру DHCP-пакета и разобрались с содержимым самых часто используемых сообщений в протоколе DHCP и с тем, как они отправляются, еще раз напомню: сообщение DHCPDISCOVER отправляется как broadcast клиентом, этим сообщением он ищет сервер; когда сервер получает DHCPDISCOVER, он формирует сообщение DHCPOFFER, которое может быть отправлено как unicast, так и broadcast (в большей степени это зависит от того, как будет удобно клиенту), в этом сообщение сервер предлагает клиенту IP-адрес; в ответ на DHCPOFFER клиент формирует DHCPREQUEST – сообщение, которым клиент дает согласие на получение предложенного IP-адреса, сообщение исключительно широковещательное; в завершении сервер резервирует IP-адрес и отправляет сообщение DHCPACK, это сообщение служит квитанцией о выдаче адреса.

Общие сведения об агентах ретрансляции DHCP | NETMANIAS

I. Обзор

Этот документ обеспечивает техническое понимание агента ретрансляции DHCP, который требуется в среде с несколькими подсетями, где DHCP-клиент и DHCP-сервер находятся в разных подсетях. В главе II объясняется, почему эти агенты ретрансляции DHCP необходимы в операциях DHCP. В главе III описаны основные принципы работы DHCP с использованием агента ретрансляции DHCP. Наконец, в Приложении будут представлены конкретные параметры сообщений, используемые агентами ретрансляции DHCP в каждой процедуре DHCP.

Перед чтением этого документа рекомендуется ознакомиться с сопутствующими документами «Общие сведения об основных операциях DHCP» [2] и «Общие сведения о подробных операциях DHCP» [3].

II. Зачем нужны агенты ретрансляции DHCP для операций DHCP?

Обычно рассылаются сообщения DHCP. Таким образом, для обмена сообщениями между DHCP-клиентом (ПК) и DHCP-сервером клиент и сервер должны находиться в одной подсети.Это связано с тем, что маршрутизаторы не пересылают широковещательные IP-пакеты (т.е. пакеты с MAC-адресом назначения FF: FF: FF: FF: FF: FF и IP-адресом назначения 255.255.255.255) на другие интерфейсы. Таким образом, широковещательный пакет DHCP, отправленный DHCP-клиентом, не может быть доставлен на DHCP-сервер (-ы) в другой (-е) подсети (-ах) через маршрутизатор (показан на рисунке 1 — (a)). Это ограничение требует, чтобы все отдельные подсети имели свой собственный DHCP-сервер для работы DHCP, что практически невозможно в сетях сетевых операторов или корпоративных компьютерных сетях (в сети требуется слишком много DHCP-серверов!).

Для решения этой проблемы давно принята концепция агента ретрансляции DHCP [1]. Как показано на рис. 1 — (b), включение функции агента ретрансляции DHCP в маршрутизаторе позволяет обмениваться сообщениями DHCP между клиентом DHCP и сервером DHCP, находящимся в разных подсетях. ¹ Основная функция этого агента ретрансляции DHCP заключается в преобразовании широковещательного пакета DHCP в одноадресный и пересылке его на сервер DHCP.

Рисунок 1. Сравнение операций DHCP в сетях с агентом ретрансляции DHCP и без него

III. Основные операции агентов DHCP-ретрансляции

В этой главе описывается, как ПК (например, ПК1) в подсети «1.1.1.0/24», как показано на Рисунке 1 — (b), может взаимодействовать с DHCP-сервером, используя агент ретрансляции DHCP для всех операций DHCP, таких как IP. выделение / аренда адреса, обновление IP-адреса и освобождение IP-адреса.

3.1 Процедура выделения / аренды IP-адреса

Агент DHCP-ретрансляции расположен между ПК и DHCP-сервером, как показано на рисунке 2. Агент DHCP-ретрансляции принимает сообщения DHCP Discover и Request, транслируемые ПК, и одноадресно отправляет их непосредственно на DHCP-сервер. На этом этапе агент DHCP-ретрансляции сохраняет свой IP-адрес (адрес интерфейса, по которому он получил сообщения DHCP Discover / Request) в поле «Relay Agent IP (= Gateway IP = giaddr)» сообщения DHCP, которое будет ретранслироваться.

Сервер DHCP одноадресно передает сообщение DHCP Offer / Ack с IP-адресом назначения, установленным в качестве IP-адреса агента ретрансляции, агенту ретрансляции DHCP. Агент DHCP-ретрансляции после проверки поля «Broadcast Flag» полученного сообщения заменяет IP-адрес назначения на IP-адрес ПК (Broadcast Flag = 0) или широковещательный IP-адрес (Broadcast Flag = 1) в зависимости от значение «Broadcast Flag». Он также заменяет исходный IP-адрес на IP-адрес агента ретрансляции DHCP и пересылает измененное сообщение на ПК.

Рисунок 2. Процедура выделения / аренды IP-адреса в сети с агентом ретрансляции DHCP

1. DHCP Discover

Как описано в справочных материалах [2], «Понимание основных операций DHCP» и [3], «Понимание подробных операций DHCP», DHCP-клиент передает сообщение DHCP Discover в физическую подсеть Ethernet для обнаружения всех DHCP. серверы, доступные в подсети.При получении пакетов, для которых порт назначения UDP установлен на 67 (обнаружение / запрос DHCP), агент ретрансляции DHCP заменяет значения в полях пакетов следующим образом, а затем одноадресно передает измененное сообщение на сервер DHCP:

• MAC-адрес назначения: MAC-адрес широковещательной рассылки, отправляемый компьютером, заменяется MAC-адресом DHCP-сервера (m5).
• MAC-адрес источника: MAC-адрес ПК (m1) заменяется MAC-адресом восходящего канала агента ретрансляции DHCP (m3).
• IP-адрес назначения: широковещательный IP-адрес (255.255.255.255), отправленное ПК, заменяется IP-адресом DHCP-сервера (100.1.1.1).
• IP-адрес источника: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом восходящего канала агента ретрансляции DHCP (100.1.1.254).
• IP-адрес агента ретрансляции: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254), IP-адресом интерфейса агента ретрансляции, на котором отправляется сообщение DHCP Discover. был получен.

2.Предложение DHCP

DHCP-сервер, ссылаясь на IP-адрес агента ретрансляции (giaddr) в сообщении DHCP Discover, выбирает IP-адрес для выделения DHCP-клиенту из IP-пула и отправляет сообщение DHCP Offer с IP-адресом назначения, установленным как IP-адрес агента ретрансляции ² . Агент ретрансляции DHCP при получении сообщения заменяет значения в полях пакетов следующим образом, а затем отправляет измененное сообщение клиенту DHCP (ПК):

• MAC-адрес назначения: если поле «Broadcast Flag» сообщения DHCP Offer, отправляемого DHCP-сервером, равно 0 (ноль), агент DHCP-ретрансляции заменяет значение в этом поле MAC-адресом ПК (поле Client MAC: m1 ) и одноадресная рассылка сообщения.Однако, если значение «Broadcast Flag» равно 1 (единица), агент ретрансляции заменяет его широковещательным MAC-адресом (FF: FF: FF: FF: FF: FF) и транслирует сообщение.
• MAC-адрес источника: MAC-адрес DHCP-сервера (m5) заменяется MAC-адресом нисходящего канала агента ретрансляции DHCP (m2).
• IP-адрес назначения: DHCP-сервер отправляет сообщение DHCP Offer с адресом назначения, установленным в качестве IP-адреса агента ретрансляции в сообщении DHCP Discover (1.1.1.254), агенту ретрансляции DHCP.Если значение «Broadcast Flag» в сообщении равно 0, агент ретрансляции заменяет это значение IP-адресом, назначенным ПК (поле Your IP: 1.1.1.10) для одноадресной рассылки. Однако, если значение «Broadcast Flag» равно 1, агент ретрансляции заменяет его широковещательным IP-адресом (255.255.255.255) для широковещательной передачи.
• IP-адрес источника: IP-адрес DHCP-сервера (100.1.1.1) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254).

3. Запрос DHCP

DHCP-клиент (ПК), получивший сообщение DHCP Offer, передает сообщение DHCP Request в физическую подсеть Ethernet для запроса данных сетевой информации, таких как IP-адреса.Агент ретрансляции DHCP, получив это сообщение, заменяет значения в полях (такие же, как в сообщении DHCP Discover) пакетов следующим образом, а затем одноадресно отправляет сообщение на сервер DHCP:

• MAC-адрес назначения: MAC-адрес широковещательной рассылки, отправляемый компьютером, заменяется MAC-адресом DHCP-сервера (m5).
• MAC-адрес источника: MAC-адрес ПК (m1) заменяется MAC-адресом восходящего канала агента ретрансляции DHCP (m3).
• IP-адрес назначения: широковещательный IP-адрес (255.255.255.255), отправленное ПК, заменяется IP-адресом DHCP-сервера (100.1.1.1).
• IP-адрес источника: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом восходящей линии связи агента ретрансляции DHCP (100.1.1.254)
• IP-адрес агента ретрансляции: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254), IP-адресом интерфейса агента ретрансляции, на котором отправляется сообщение DHCP Discover. был получен.

4.DHCP Ack

Сервер DHCP отправляет сообщение DHCP Ack с IP-адресом назначения, установленным в качестве IP-адреса агента ретрансляции (giaddr) ³ . Агент ретрансляции DHCP, получив это сообщение, заменяет значения в полях пакетов следующим образом, а затем одноадресно отправляет сообщение клиенту DHCP (ПК):

• MAC-адрес назначения: если поле «Broadcast Flag» сообщения DHCP Ack, отправляемого DHCP-сервером, равно 0 (ноль), агент DHCP-ретрансляции заменяет значение в этом поле MAC-адресом ПК (поле Client MAC: m1 ) и одноадресная рассылка сообщения.Однако, если значение «Broadcast Flag» равно 1 (единица), агент ретрансляции заменяет его широковещательным MAC-адресом (FF: FF: FF: FF: FF: FF) и транслирует сообщение.
• MAC-адрес источника: MAC-адрес DHCP-сервера (m5) заменяется MAC-адресом нисходящего канала агента ретрансляции DHCP (m2).
• IP-адрес назначения: DHCP-сервер отправляет сообщение DHCP Ack с адресом назначения, установленным в качестве IP-адреса агента ретрансляции в сообщении запроса DHCP (1.1.1.254), агенту ретрансляции DHCP.Если значение «Broadcast Flag» в сообщении равно 0, агент ретрансляции заменяет это значение IP-адресом, назначенным ПК (поле Your IP: 1.1.1.10) для одноадресной рассылки. Однако, если значение «Broadcast Flag» равно 1, агент ретрансляции заменяет его широковещательным IP-адресом (255.255.255.255) для широковещательной передачи.
• IP-адрес источника: IP-адрес DHCP-сервера (100.1.1.1) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254).

3.2 Процедура обновления IP-адреса

Согласно ссылке [1], DHCP-клиент (ПК) сохраняет / сохраняет IP-адрес DHCP-сервера, полученный посредством сообщения DHCP Ack (в поле идентификатора DHCP-сервера) во время процедуры распределения IP-адреса.Затем, если ему необходимо использовать IP-адрес по истечении срока аренды, он отправляет сообщение DHCP-запроса на DHCP-сервер посредством одноадресной, а не широковещательной рассылки. И сервер DHCP, в ответ на сообщение, одноадресно отправляет сообщение DHCP Ack клиенту DHCP.

Таким образом, в случае одноадресной передачи сообщений DHCP агенту ретрансляции DHCP не требуется выполнять свою роль (преобразовывать широковещательное сообщение в одноадресное) для операций DHCP. Итак, как видно на рисунке 3, агент DHCP-ретрансляции не участвует ни в каких DHCP-операциях во время процедуры обновления IP-адреса.

Рисунок 3. Процедура обновления IP-адреса в сети с помощью агента ретрансляции DHCP

1. Запрос DHCP

DHCP-клиент (ПК) отправляет одноадресное сообщение DHCP-запроса с IP-адресом назначения, установленным в качестве IP-адреса DHCP-сервера. Таким образом, агент ретрансляции DHCP не получает это сообщение. Другими словами, ни одно поле сообщения DHCP-запроса не заменяется агентом ретрансляции DHCP во время процедуры обновления IP-адреса.

2. DHCP Ack

DHCP-сервер отправляет одноадресное сообщение DHCP Ack с IP-адресом назначения, установленным как IP-адрес DHCP-клиента (ПК). Опять же, агент DHCP-ретрансляции не получает это сообщение. Другими словами, никакое поле сообщения DHCP Ack не заменяется агентом ретрансляции DHCP во время процедуры обновления IP-адреса.

3.3 Процедура освобождения IP-адреса

Согласно ссылке [1], RFC 1542, когда IP-адрес высвобождается, DHCP-клиент (ПК) напрямую отправляет сообщение DHCP Release DHCP-серверу.Таким образом, агент ретрансляции DHCP не участвует в процедуре освобождения IP-адреса, как показано на Рисунке 4.

Рисунок 4. Процедура освобождения IP-адреса в сети с помощью агента ретрансляции DHCP

1. Версия DHCP

DHCP-клиент отправляет одноадресное сообщение DHCP Release с IP-адресом назначения, установленным в качестве IP-адреса DHCP-сервера. Таким образом, агент ретрансляции DHCP не получает это сообщение. Другими словами, никакие поля сообщения DHCP Ack не заменяются агентом ретрансляции DHCP во время процедуры освобождения IP-адреса.

Список литературы

[1] В. Ваймер, «Разъяснения и расширения для протокола начальной загрузки», RFC 1542, Standard, октябрь 1993 г.

[2] Технический документ Netmanias, «Понимание основных операций DHCP», октябрь 2013 г.

[3] Технический документ Netmanias, «Подробное понимание операций DHCP», октябрь 2013 г.

Сноски

1 Обычно маршрутизаторы и коммутаторы L3 поддерживают все функции агента ретрансляции DHCP.

2 Если IP-адрес агента DHCP-ретрансляции не установлен как «0.0.0.0», DHCP-сервер всегда одноадресно рассылает сообщение DHCP Offer агенту DHCP-ретрансляции независимо от значения флага широковещательной рассылки.

3 Если IP-адрес агента DHCP-ретрансляции не установлен как «0.0.0.0», DHCP-сервер всегда отправляет сообщение DHCP Ack агенту DHCP-ретрансляции независимо от значения флага широковещательной рассылки.

Приложение – Формат сообщений DHCP в сети с агентами ретрансляции DHCP

В этом приложении приведены конкретные примеры параметров сообщения DHCP, которые заменяются агентом ретрансляции DHCP во время процедур DHCP.Однако в случае процедур обновления и освобождения IP-адреса агент ретрансляции DHCP НЕ заменяет какую-либо часть сообщений DHCP. Таким образом, все сообщения, относящиеся к этим процедурам, исключены в этом приложении.

Сообщение DHCP Discover

Рисунок 5 . Сообщение DHCP Discover в процедуре выделения / аренды IP-адреса

Заголовок Ethernet

• MAC-адрес назначения : MAC-адрес широковещательной передачи (0xFFFFFFFFFFFF) заменяется MAC-адресом DHCP-сервера (m5).
• MAC-адрес источника : MAC-адрес ПК (m1) заменяется MAC-адресом восходящего канала агента ретрансляции DHCP (m3).

IP-заголовок

• IP-адрес источника : IP-адрес (0.0.0.0) заменяется IP-адресом восходящего канала агента ретрансляции DHCP (100.1.1.254).
• IP-адрес назначения : широковещательный IP-адрес (255.255.255.255) заменяется IP-адресом DHCP-сервера (100.1.1.1).

Полезная нагрузка сообщения DHCP

• IP-адрес шлюза (giaddr): IP-адрес (0.0.0.0) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254), который получает сообщение DHCP Discover с ПК.

Сообщение о предложении DHCP

Рисунок 6 . Сообщение о предложении DHCP в процедуре выделения / аренды IP-адреса

Заголовок Ethernet

• MAC-адрес назначения : MAC-адрес восходящего канала агента ретрансляции DHCP (m3) заменяется MAC-адресом широковещательной передачи (0xFFFFFFFFFFFF).

Примечание: В этом примере, поскольку мы предположили, что значение «Broadcast Flag» установлено на 1, агент ретрансляции передает сообщение широковещательно.

• MAC-адрес источника : MAC-адрес DHCP-сервера (m5) заменяется MAC-адресом нисходящего канала агента ретрансляции DHCP (m2).

IP-заголовок

• IP-адрес источника : IP-адрес DHCP-сервера (100.1.1.1) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254).
• IP-адрес назначения : IP-адрес нисходящего канала агента ретрансляции DHCP (giaddr = 1.1.1.254) заменяется широковещательным IP-адресом (255.255.255.255).

Примечание: В этом примере, поскольку мы предположили, что значение «Broadcast Flag» установлено на 1, агент ретрансляции передает сообщение широковещательно.

Сообщение запроса DHCP

Рисунок 7 . Сообщение с запросом DHCP в процедуре выделения / аренды IP-адреса

Заголовок Ethernet

• MAC-адрес назначения : MAC-адрес широковещательной рассылки (0xFFFFFFFFFFFF) заменяется MAC-адресом DHCP-сервера (m5).
• MAC-адрес источника : MAC-адрес ПК (m1) заменяется MAC-адресом восходящего канала агента ретрансляции DHCP (m3).

IP-заголовок

• IP-адрес источника : IP-адрес (0.0.0.0) заменяется IP-адресом восходящего канала агента ретрансляции DHCP (100.1.1.254).
• IP-адрес назначения : широковещательный IP-адрес (255.255.255.255) заменяется IP-адресом DHCP-сервера (100.1.1.1).

Полезная нагрузка сообщения DHCP

• IP-адрес шлюза (giaddr): IP-адрес (0.0.0.0) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254), который получает сообщение запроса DHCP от ПК.

Сообщение DHCP Ack

Рисунок 8 . Сообщение DHCP Ack в процедуре выделения / аренды IP-адреса

Заголовок Ethernet

• MAC-адрес назначения : MAC-адрес восходящего канала агента ретрансляции DHCP заменяется широковещательным MAC-адресом (0xFFFFFFFFFFFF).
• Примечание: В этом примере, поскольку мы предположили, что «Флаг широковещательной рассылки» установлен на 1, агент ретрансляции передает сообщение широковещательно.
• MAC-адрес источника : MAC-адрес DHCP-сервера (m5) заменяется MAC-адресом нисходящего канала агента ретрансляции DHCP (m2).

IP-заголовок

• IP-адрес источника : IP-адрес DHCP-сервера (100.1.1.1) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254).
• IP-адрес назначения : IP-адрес нисходящего канала агента ретрансляции DHCP (giaddr = 1.1.1.254) заменяется широковещательным IP-адресом (255.255.255.255).

Примечание: В этом примере, поскольку мы предположили, что значение «Broadcast Flag» установлено на 1, агент ретрансляции передает сообщение широковещательно.

.

Настройка ретрансляции DHCP в Comware ⋆ Консультации по реализации проекта сети

Реле протокола динамической конфигурации хоста (DHCP) в Comware конфигурируется с использованием концепции нескольких серверов DHCP и применяется к интерфейсам. Эта конфигурация позволяет добавлять информацию для масштабирования, но это неудобно, когда у вас есть один или два DHCP-сервера. В конце концов, требования к конфигурации просты, но не ip-helper-address, который мы тоже используем.

  ПЕРЕМЕННЫЕ 
$ {GroupNumber} Определите группу серверов, для которой доступен DHCP.
$ {DHCPserverIPaddress} Определите IP-адрес (а) DHCP-сервера для этой группы.
$ {VLAN} Коммутируемый виртуальный интерфейс 

  Конфигурация 
dhcp enable
группа серверов ретрансляции dhcp $ {GroupNumber} ip $ {DHCPserverIPaddress}
int vlan $ {VLAN}
dhcp relay server-select $ {GroupNumber}
реле выбора dhcp 

Настроить ретранслятор DHCP на 5800A

 [5800A] dhcp включить
 DHCP включен успешно!
[5800A] dhcp relay server-group 1 ip 10.8.10.10
[5800A] int vlan 2
[5800A-Vlan-interface2] dhcp relay server-select 1
[5800A-Vlan-interface2] реле выбора dhcp
[5800A-Vlan-interface2] это
#
интерфейс Vlan-interface2
 IP-адрес 10.8.2.2 255.255.255.0
 vrrp vrid 2 виртуальный IP 10.8.2.1
 vrrp vrid 2 приоритет 110
 Реле выбора  dhcp
 dhcp relay server-select 1 
#
возвращение

[5800A-Vlan-interface2] Статистика реле DIS dhcp
     Получено плохих пакетов: 0
     Пакетов DHCP, полученных от клиентов: 0
         Получено пакетов DHCPDISCOVER: 0
         Получено пакетов DHCPREQUEST: 0
         Получено пакетов DHCPINFORM: 0
         Получено пакетов DHCPRELEASE: 0
         Получено пакетов DHCPDECLINE: 0
         Получено пакетов BOOTPREQUEST: 0
     Пакетов DHCP, полученных от серверов: 0
         Получено пакетов DHCPOFFER: 0
         Получено пакетов DHCPACK: 0
         Получено пакетов DHCPNAK: 0
         Получено пакетов BOOTPREPLY: 0
     Пакетов DHCP, ретранслируемых на серверы: 0
         Передано пакетов DHCPDISCOVER: 0
         Передано пакетов DHCPREQUEST: 0
         Передано пакетов DHCPINFORM: 0
         Передано пакетов DHCPRELEASE: 0
         Передано пакетов DHCPDECLINE: 0
         Передано пакетов BOOTPREQUEST: 0
     Пакетов DHCP, переданных клиентам: 0
         Передано пакетов DHCPOFFER: 0
         Передано пакетов DHCPACK: 0
         Передано пакетов DHCPNAK: 0
         Передано пакетов BOOTPREPLY: 0
     Пакетов DHCP, отправленных на серверы: 0
         Отправлено пакетов DHCPDISCOVER: 0
         Отправлено пакетов DHCPREQUEST: 0
         Отправлено пакетов DHCPINFORM: 0
         Отправлено пакетов DHCPRELEASE: 0
         Отправлено пакетов DHCPDECLINE: 0
         Отправлено пакетов BOOTPREQUEST: 0
     Пакетов DHCP, отправленных клиентам: 0
         Отправлено пакетов DHCPOFFER: 0
         Отправлено пакетов DHCPACK: 0
         Отправлено пакетов DHCPNAK: 0
         Отправлено пакетов BOOTPREPLY: 0 

Проверьте подключение к серверу DHCP.

 [5800A-Vlan-interface2] пинг 10.8.10.10
  PING 10.8.10.10: 56 байтов данных, нажмите CTRL_C, чтобы прервать
      Ответ от 10.8.10.10: байты = 56 Последовательность = 1 ttl = 128 раз 
    Ответ от 10.8.10.10: байты = 56 Последовательность = 2 ttl = 128 раз
    Ответ от 10.8.10.10: байты = 56 Последовательность = 3 ttl = 128 раз
    Ответ от 10.8.10.10: байты = 56 Последовательность = 4 ttl = 128 раз
    Ответ от 10.8.10.10: байты = 56 Последовательность = 5 ttl = 128 раз

  --- 10.8.10.10 статистика пинга ---
    5 пакетов передано
    Получено 5 пакетов
    0.00% потеря пакетов
    двусторонний мин. / сред. / макс. = 1/2/5 мс

[5800A] диск | я dhcp
   dhcp relay server-группа 1 ip 10.8.10.10 
 dhcp выберите реле
 dhcp relay server-select 1
   dhcp включить 

[5800A] реле dhcp dis dhcp все
    Название интерфейса Группа серверов
    Vlan-интерфейс2 1 
[5800A]
[5800A] DIS dhcp relay server-group 1
    № Группа IP
     1 10.8.10.10  

Подключите ПК к VLAN 2 с включенным DHCP

Статистика реле dhcp dis dhcp

 [5800A]
     Получено плохих пакетов: 0
       пакетов DHCP, полученных от клиентов: 3 
           пакетов DHCPDISCOVER получено: 1 
           Получено пакетов DHCPREQUEST: 1 
           пакетов DHCPINFORM получено: 1 
         Получено пакетов DHCPRELEASE: 0
         Получено пакетов DHCPDECLINE: 0
         Получено пакетов BOOTPREQUEST: 0
       DHCP-пакетов, полученных от серверов: 3 
           Получено пакетов DHCPOFFER: 1 
           Получено пакетов DHCPACK: 2 
         Получено пакетов DHCPNAK: 0
         Получено пакетов BOOTPREPLY: 0
       пакетов DHCP, ретранслируемых на серверы: 3 
           ретранслированных пакетов DHCPDISCOVER: 1 
           пакетов DHCPREQUEST передано: 1 
           пакетов DHCPINFORM передано: 1 
         Передано пакетов DHCPRELEASE: 0
         Передано пакетов DHCPDECLINE: 0
         Передано пакетов BOOTPREQUEST: 0
       пакетов DHCP, переданных клиентам: 3 
           ретранслированных пакетов DHCPOFFER: 1 
           ретранслированных пакетов DHCPACK: 2 
         Передано пакетов DHCPNAK: 0
         Передано пакетов BOOTPREPLY: 0
     Пакетов DHCP, отправленных на серверы: 0
         Отправлено пакетов DHCPDISCOVER: 0
         Отправлено пакетов DHCPREQUEST: 0
         Отправлено пакетов DHCPINFORM: 0
         Отправлено пакетов DHCPRELEASE: 0
         Отправлено пакетов DHCPDECLINE: 0
         Отправлено пакетов BOOTPREQUEST: 0
     Пакетов DHCP, отправленных клиентам: 0
         Отправлено пакетов DHCPOFFER: 0
         Отправлено пакетов DHCPACK: 0
         Отправлено пакетов DHCPNAK: 0
         Отправлено пакетов BOOTPREPLY: 0 

В Comware для настройки DHCP-ретранслятора требуется:

• включение dhcp
• определение сервера
• сопоставление его с группой
• на каждом интерфейсе уровня 3
  • определение группы DHCP
  • определение функции реле

.