Option 82 windows server 2012 r2

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

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

Немного теории и решения интересных и не очень практических задач — под катом.

В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).

Zeroconf или зачем нам вообще какой-то DHCP

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

Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.

Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP, который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.

При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и поставить ему значение 0.

Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.

DHCP и его прародители

Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.

Схема работы RARP протокола.

И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

Важным отличием от устаревших протоколов является возможность временной выдачи адреса (lease) и передачи большого количества разной информации клиенту. Достигается это за счет менее тривиальной процедуры получения адреса. Если в старых протоколах схема была простая, вида запрос-ответ, то теперь схема следующая:

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

Схема общения клиента с сервером пересылки и сервером.

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

На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».

С разными реализациями DHCP-сервера сталкивались многие, даже при настройке домашней сети. Действительно, сейчас сервер есть:

• На практически любом маршрутизаторе, особенно SOHO.
• На системах Windows Server. О сервере и его настройке можно почитать в официальной документации.
• На системах *nix. Пожалуй, самое популярное ПО — ISC DHCP Server (dhcpd) и «комбайн» Dnsmasq.

Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC, я же разберу несколько интересных примеров.

Удивительные опции DHCP

В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *—dhcp-option-force. MikroTik и Windows такого не умеют.

Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi». Настройка MikroTik под спойлером.

#Добавляем опцию 15. содержимое — сконвертированный в HEX суффикс.

/ip dhcp-server option

add code=15 name=dns-suffix value=0x57687920616c6c207468697320736869743f

#создаем набор опций

/ip dhcp-server option sets

add name=dns option=dns-suffix

#Добавляем опцию к DHCP-серверу для клиентов.

/ip dhcp-server network

set [find comment="wi-fi client dhcp"] dhcp-option-set=dns

Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.

#настройка опций, обратите внимание, что ip экранирован одинарными кавычками

/ip dhcp-server option

add code=6 name=google value="'8.8.8.8'"

add code=6 name=cloudflare value="'1.1.1.1'"

#настройка клиентов

/ip dhcp-server lease

add address=10.0.0.2 dhcp-option=google mac-address=11:11:11:11:11:11 server=dhcp

add address=10.0.0.3 dhcp-option=cloudflare mac-address=22:22:22:22:22:22 server=dhcp

Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation. Пример настройки DHCP:

/ip dhcp-server option

add name="option66" code=66 value="s'192.168.88.1'"

add name="option67" code=67 value="'pxelinux.0'"

/ip dhcp-server option sets

add name="set-pxe" options=option66,option67

Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.

/ip dhcp-server option

add code=121 name=classless value=0x0A0000c0a8580200c0a85801

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Добавим сети надежности и безопасности

Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.

Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.

В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:

#Включаем dhcp-snooping и option 82

/interface bridge

add name=bridge

set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes

#ставим настраиваем доверенный порт

/interface bridge port

add bridge=bridge interface=ether1

add bridge=bridge interface=ether2 trusted=yes

Настройка в других коммутаторах происходит аналогичным образом.

Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.

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

Красивая коммутационная — залог здоровья.

К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPSIDS.

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

Казалось бы, можно поделить область выдачи между двумя серверами, и пусть один выдает одну половину адресов, а второй — другую. Вот только парализованная половина инфраструктуры немногим лучше, чем целая.

Разберем более практичные варианты.

В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7…»

Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.

Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.

Расскажите, а вам приходилось сталкиваться с проказами DHCP?

This article provides in-depth analysis of DHCP Option 82 (DHCP Relay Agent) which is one of the +180 DHCP Options available to the DHCP protocol and used by the Bootstrap Protocol (BOOTP) used for allowing  diskless client machines to discover and obtain their IP address. We’ll show you how DHCP Option 82 is used when implementing DHCP Snooping, the structure and content of DHCP Option 82, how and where it’s injected and removed from DHCP messages plus much more. You’ll can also download our DHCP/BOOTP Options Excel file and Wireshark packet captures of DHCP packets with Option 82 used in this article to help further understand all topics covered.

Let’s take a look at the list of topics covered in this article:

• The DHCP Options field within a DHCP Packet
• DHCP Option 82 (Agent Relay) Message Format, Structure & Fields
• Detailed Analysis of DHCP Option 82 – SubOption 1 & SubOption2
• Purpose & Usage Examples of DHCP Option 82 (Agent Relay)
• DHCP Snooping & Option 82 (Agent Relay) Considerations. Switches & Trusted – Untrusted Ports
• Summary

It’s highly recommend to read through our DHCP Snooping – DHCP Attack Mitigation article which is a foundation article.

The ‘DHCP Options’ Field within a DHCP Packet

The DHCP Options field is included inside every DHCP packet and is critical for the correct operation of the DHCP/BOOTP protocol.  You’d be surprised to know that there are almost 200 different DHCP Options available and there are more added as new features are introduced in the protocol.

The material used in this article such as wireshark DHCP Options 82 packet captures and DHCP/BOOTP Options excel file are freely available to download from our Article Attachments section.

The diagram below shows the structure of a DHCP packet and highlights the position of the DHCP Options field.

It is important to understand that the above DHCP packet is the data payload within an Ethernet frame using UDP as the transport protocol.

The below screenshot was taken from a packet analyzer and shows an Ethernet frame with the DHCP data payload expanded:

We’ve highlighted sections of the DHCP protocol using the same colours as our previous diagram to help the correlation process. Every field shown in our diagram maps directly to the fields of the captured DHCP packet.

The area marked in green is the section where the DHCP Options field is located. In our captured packet there are a total of 8 DHCP Options used, among them is also Option 82 (Agent Information Option).

DHCP Option 82 (Agent Relay) Message Format, Structure & Fields

The DHCP Option 82, aka Agent Relay Information Option or Agent Information Option, was originally created by RFC 3046 to allow the DHCP relay agent (e.g switch, router, firewall or server) to identify itself and the DHCP client that sent the original DHCP message.

The DHCP Option 82 is inserted and removed by the DHCP Agent Relay (e.g switch) as shown in the diagram below:

While some DHCP servers might not support the Option 82 they are still required to copy the Option 82 value received from the DHCP client and include it in all replies back to the client. We’ll discuss the Option 82 insertion and removal process in the next section.

As we saw earlier, the DHCP Options field is positioned at the end of the DHCP packet and always contains multiple DHCP options. This of course means the DHCP Option field varies in length according to the number of options used:

Let’s now take a closer look into the DHCP Options field at the end of the packet. This can contain multiple options as shown below in our packet analyzer screenshot:

 Each option expands to include its own parameters however we will focus on Option 82 shown below:

Due to space restrictions we are only depicting the first (Message Type), second last (Option 82) and last (End) option.

Remember there are over 200 different DHCP options (Code options) available and multiple used in just a single DHCP packet so it can get very challenging analyzing only one DHCP packet!

Looking at the above diagram we can appreciate that the structure of each DHCP Option varies depending on its purpose and information contained however there is a common set of fields used by all except the last (Option 255 – End):

• Code (light green box). Identifies the DHCP Option type. Examples are Code=82 (DHCP Agent Information), Code=53 (DHCP Message Type: Discover, Offer, Request or Ack), etc.
• Length (green box). This is the DHCP option type length in bytes. For DHCP Option 82, this includes the combined the length of SubOption1 + SubOption2.
• Value (blue box). This contains value or data related to the DHCP Option type. DHCP Option 82 contains two SubOptions, each with its own unique value as shown above.

It’s probably worth mentioning at this point that RFC 3046 states that DHCP Option 82 should always be the last DHCP Option before the END option (Code 255).

The material used in this article such as wireshark DHCP Options 82 packet captures and DHCP/BOOTP Options excel file are freely available to download from our Article Attachments section.

Detailed Analysis of DHCP Option 82 – SubOption 1 & SubOption 2

Before we begin analyzing the two SubOptions we need to understand that DHCP Option 82 is inserted by the Agent Relay (switch) as the client’s DHCP packets traverse it.

In this scenario the switch has DHCP Snooping enabled and the SubOption parameters configured accordingly. In the example below, switch DC-SW1 has DHCP Snooping plus DHCP Options 82 enabled and configured:

As the client’s DHCP Discover packet enters switch DC-SW1 via port Gi0/5 the switch will automatically add the DHCP Option 82 and continue forwarding the packet to the DHCP server.

Below is the breakdown of DHCP Option 82 added inside the DHCP Options field:

The DHCP Option 82 in this example has the following configured:

• SubOption 1 (Agent Circuit ID) = Gi0/5. Used to identify the individual switchport.
• SubOption 2 (Agent Remote ID) = DC-SW1. The Hostname or description of the DHCP Relay Agent

Here is what a DHCP Option 82 packet capture looks like in network protocol analyzer:

The top section highlights the two SubOptions along with their parameters and values which are all in HEX while the lower right section shows these values in ASCII – making them easy to decipher.

Before we complete this section let’s take a closer look at the fields each SubOption consists of:

• SubOption Number. This identifies the first (Agent Circuit ID) or second (Agent Remote ID) SubOption.
• Length. The length of the specific SubOption in bytes.
• Value. The specific SubOption value.

This completed the protocol analysis of DHCP Option 82.  Next up, we’ll take a look at examples where DHCP Option 82 plays a significant role in the operation of the network infrastructure.

Purpose & Usage Examples of DHCP Option 82 (Agent Relay)

Most modern DHCP Servers, e.g Windows Server 2012 & Windows Server 2016, support DHCP Option 82 therefore allowing organizations to create DHCP policies according to the information contained inside the DHCP Option 82 field. For example DHCP Pools or IP address ranges can be reserved and assigned to DHCP clients connecting to specific switches within the network or specific ports on those switches.

Large metropolitan networks, for example ISPs or university campuses make extensive use of the DHCP Option 82 as it provides them with the capability of managing and maintaining DHCP network services from a centralized location without the need of dispersed DHCP servers at each site or campus.

DHCP client requests are directed to the main datacenter with the help of local DHCP relay agents (switches, routers, etc) configured to inject the DHCP Option 82 inside the client’s original DHCP packet. This packet is then forwarded to the DHCP Servers with all the necessary information that will allow them to identify the site, network switch and port to which the client is connected to. DHCP server policies then come into effect and ensure each site is served from the correct DHCP pool and clients are assigned the correct IP address.

The diagram above shows how a client’s DHCP Discover packet is modified by the local DHCP Relay Agent (DC-SW1) to include the DHCP Option 82 message allowing the DHCP server at the Core Network identify the campus, switch and port to which the client sending the request is connected to.

As previously noted, the DHCP server is required to maintain the DHCP Option 82 information when replying to the client. This is also shown in the diagram below:

The DHCP Relay Agent (DC-SW1) will receive the DHCP server’s reply and remove the Option 82 information before forwarding it out to the DHCP client.

Many sources on the internet incorrectly mention that the DHCP Relay Agent Option (Option 82) is automatically inserted by a DHCP Snooping enabled switch. RFC 3046 (Section 2.1 – Agent Operation) specifically notes that this function should be disabled by default.

DHCP Snooping & Option 82 (Relay Agent) Considerations. Switches & Trusted — Untrusted Ports

We already know that with DHCP Snooping enabled and Option 82 configured a Cisco Catalyst or Nexus switch, it will insert the Option 82 field into the client’s DHCP message as shown in the below diagram:

As shown in the example above, the DHCP client’s DHCP Discover packet is received by the switch on interface Gi0/5 which is by default an untrusted port. The switch, which acts as a DHCP relay agent, immediately inserts the DHCP Option 82 in the original DHCP Discover packet, updates the frame as needed (MAC addresses, destination IP, CRC) then sends it out Gi0/1, a trusted port, to the DHCP Server.

As a general rule of thumb, any switch interface expected to receive DHCP packets containing DHCP Option 82 must be configured as a Trusted interface otherwise the DHCP packet will be discarded by the switch:

In the case where there are multiple switches with involved in the path to reach the DHCP server the same rule applies to ensure DHCP packets with Option 82 can traverse each hop:

Interfaces Gi0/1 from SW1 and Gi0/4, Gi0/2 from SW2 will always receive DHCP packets with Option 82 therefore these ports must be configured as trusted ports.

Summary

This article provided in-depth analysis of the DHCP Options field and more specifically the DHCP Option 82. We examined the DHCP Option 82 message format, structure and fields while also taking a close look at SubOptions 1 & 2 and explaining their usage. Finally we talked about the purpose and real-usage examples of DHCP Option 82 and showed how switchports should be configured on DHCP Snooping enabled switches with DHCP Option 82 configured.

Related Articles

• Complete Guide to DHCP Snooping, Snooping Database & mitigating DHCP Attacks
• Basic & Advanced Catalyst Layer 3 Switch Configuration
• Understanding & Designing VLAN Networks
• Ethernet II Frame Formats
• MAC Address

Back to Cisco Switches Section

Сценарий: компьютеры подключаются к коммутаторам 3-го уровня как DHCP клиенты, коммутаторы работают как DHCP Relay Agent и отправляют запросы на DHCP серверы Windows Server 2012/R2.

Задача: предоставить обслуживающему персоналу информацию о том, на каком порту какого коммутатора подключен конкретный компьютер

Решение: настроить на коммутаторах DHCP Snooping, получить на DHCP серверах опцию 82, расшифровать

В этой статье рассмотрим только расшифровку опции 82, но не решение задачи в целом. Настройка DHCP Snooping также вне темы этой статьи. Дополнительную информацию по использованию опции на серверах Windows можно найти в статье DHCP policies based on Relay Agent Information Option (option 82), DHCP Snooping and IP Source Guard.

Сервер Windows Server 2012/R2 имеет в журналах DHCP сервиса поле RelayAgentInformation. (Журналы аудита DHCP нужно включить.) Это поле содержит информацию от устройства выполняющего функции DHCP Relay Agent. Официально это называется Relay Agent Information Option — DHCP Option 82. Внутри себя эта опция может включать несколько подопций (sub option). Официальные документы описывающие форматы опции 82 и её подопций:

1. DHCP Relay Agent (RA) Information Option [Option 82] — RFC 3046
2. Circuit ID, RA Sub-Option [Sub Option ID — 1] — RFC 3046
3. Remote ID, RA Sub-Option [Remote Option ID — 2] — RFC 3046
4. Subscriber ID, RA Sub-Option [Sub Option ID — 6] — RFC 3993
5. Server Identifier Override Option, RA Sub-Option [Sub Option ID — 11] — RFC 5107

Нам важны фактически две подопции:

Circuit ID – это описание порта подключения

Remote ID – это имя устройства, где выполняется подключение

(Остальные опции могут отправляться DHCP клиентом, но в нашей задаче они не важны.)

В поле RelayAgentInformation журнала аудита сервер пишет в шестнадцатеричном виде только сами подопции. Формат подопций:

SubOpt Len     Sub-option Value

+——+——+——+——+——+——+—…-+——+

| 1   |   N | s1 | s2 | s3 | s4 |     | sN |

+——+——+——+——+——+——+—…-+——+

SubOpt Len     Sub-option Value

+——+——+——+——+——+——+—…-+——+

| 2   |   N | i1 | i2 | i3 | i4 |     | iN |

+——+——+——+——+——+——+—…-+——+

Ниже пример разбора поля RelayAgentInformation.

# Строка значения взята из журнала аудита DHCP

$RelayAgentInformation="0x0106000400660222021401125546412D434D2D4153573130312D34353036"

#

$RelayAgentInformation=$RelayAgentInformation.Substring(2)

#$RelayAgentInformation="0106000400660222021401125546412D434D2D4153573130312D34353036"

# Suboption Num=01 Len=0x06=6

#

$AgentCircuitIDlen = [CONVERT]::toint16($RelayAgentInformation.Substring(2,2),16) *2

$AgentCircuitID = $RelayAgentInformation.Substring( 4, $AgentCircuitIDlen )

#$AgentCircuitID ="000400660222"

# SubOption Type=0 Len=0x04=4

#

$AgentCircuitIDlen00 = [CONVERT]::toint16($AgentCircuitID.Substring(2,2),16) *2

$AgentCircuitID00 = $AgentCircuitID.Substring( 4, $AgentCircuitIDlen00 )

#$AgentCircuitID00 ="00660222"

#

$AgentCircuitIDvlan = [CONVERT]::toint16($AgentCircuitID00.Substring(0,4),16)

$AgentCircuitIDslot = [CONVERT]::toint16($AgentCircuitID00.Substring(4,2),16)

$AgentCircuitIDport = [CONVERT]::toint16($AgentCircuitID00.Substring(6,2),16)

$RelayAgentInformation=$RelayAgentInformation.Substring(4 + $AgentCircuitIDlen)

#$AgentRemoteID ="021401125546412D434D2D4153573130312D34353036"

# Suboption Num=02 Len=0x14=20

#

#$AgentRemoteID=$RelayAgentInformation.Substring(4 + $AgentCircuitIDlen)

$AgentRemoteIDlen = [CONVERT]::toint16($RelayAgentInformation.Substring(2,2),16) *2

$AgentRemoteID = $RelayAgentInformation.Substring( 4, $AgentRemoteIDlen )

#$AgentRemoteID ="01125546412D434D2D4153573130312D34353036"

# SubOption Type=01 Len=0x12=18

#

$AgentRemoteIDlen01 = [CONVERT]::toint16($AgentRemoteID.Substring(2,2),16) *2

$AgentRemoteID = $AgentRemoteID.Substring( 4, $AgentRemoteIDlen01 )

#$AgentRemoteID ="5546412D434D2D4153573130312D34353036"

$AgentRemoteID =($AgentRemoteID -split "(..)" | ? {$_} | FOREACH { [CHAR]([CONVERT]::toint16($_,16)) } ) -join ""

$RelayAgentInformation=$RelayAgentInformation.Substring(4 + $AgentRemoteIDlen)

$AgentCircuitIDvlan

$AgentCircuitIDslot

$AgentCircuitIDport

$AgentRemoteID

Filed under: Powershell, Windows | Tagged: Windows, Windows Server 2012, Windows Server 2012 R2 |

Материал из Xgu.ru

Перейти к: навигация, поиск

Автор: Наташа Самойленко

Опция 82 DHCP (DHCP option 82) — опция протокола DHCP, использующаяся
для того чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Применяется при решении задачи привязки IP-адреса к порту коммутатора
и для защиты от атак с использованием протокола DHCP (DHCP snooping).

[править] Задача

Протокол динамического конфигурирования DHCP очень удобен — настройка стека TCP/IP клиентских
машин не требует никакого внимания со стороны администратора, всё происходит само собой.
С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост
получит какой адрес. Если нужно сохранить удобство использования DHCP, но при этом сделать так, чтобы адреса были
чётко закреплены за каждым компьютером, используется так называемая привязка к MAC-адресу: DHCP-сервер имеет таблицу соответствия MAC-адресов IP-адресам, и назначает IP-адреса в соответствии с этой таблицей.
Минус этого решения — необходимость отслеживания MAC-адресов и сопровождения таблицы соответствия.

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

Решить эти задачи позволяет опция 82 протокола DHCP.

Ниже описывается, каким образом настроить DHCP-сервер, чтобы он выдавал IP-адрес в зависимости от того, к какому порту коммутатора подключен клиент, сделавший запрос. Рассматривается случай, когда коммутатор,
через который поступает запрос, используется в роли DHCP-ретранслятора
(решение задачи для случая, когда это не так, описано на странице DHCP snooping).

[править] Протокол DHCP

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

Во взаимодействии по протоколу DHCP принимают участие две или три стороны:

• DHCP-клиент — тот, кто хочет получить параметры настройки TCP/IP;
• DHCP-сервер — тот, кто выдаёт эти параметры;
• DHCP-ретранслятор (relay agent) — вспомогательный участник, который может играть роль посредника между клиентом и сервером. Он используется в тех случаях, когда у клиента нет возможности обратиться к серверу напрямую, в частности, в том случае, если они находятся в разных широковещательных доменах. DHCP-ретранслятор обрабатывает стандартный широковещательный DHCP-запрос и перенаправляет его на DHCP-сервер в виде целенаправленного (unicast) пакета, а полученный от DHCP-сервера ответ, в свою очередь, перенаправляет DHCP-клиенту.

Как правило, DHCP-сервер выделяет IP-адреса (и прочие параметры TCP/IP)
одним из двух способов:

• Случайным образом из предопределённого пула (в том случае, если клиенту ранее уже выдавался какой-то адрес, он может попробовать получить его вновь);
• Жёстко зафиксированным образом, исходя из MAC-адреса клиента.

[править] Option 82

Опция 82 состоит из двух подопций:

Agent Circuit ID — содержит информацию о том, с какого порта пришел запрос на DHCP-ретранслятор.

Agent Remote ID — идентификатор самого DHCP-ретранслятора (который задается при настройке, можно например использовать MAC-адрес коммутатора или его описание, любое удобное значение).

Опция 82 в запросе DHCP:

DHCP-серверы, поддерживающие опцию 82:

• ISC DHCP Server;
• Cisco Network Registrar (CNR);
• Infoblox;
• Lucent QIP;
• Weird Solutions.

Несмотря на то, что это нигде не указано явно,
вероятнее всего, Microsoft Windows 2003 Server
опцию 82 не поддерживает. (Однако на личном опыте проверено что работает, надо только добавить эту опцию)

[править] Инсталляция и настройка DHCP сервера ISC-DHCP

Будем использовать dhcp-сервер ISC-DHCP (v3).
ISC DHCP Server — наиболее распространнённый DHCP-сервер, из использующихся в UNIX/Linux-системах.
Для нас сейчас важно и то, что это один из серверов, умеющих распознавать опцию 82.

Будем предполагать, что инсталляция и настройка сервера
выполняется в Debian GNU/Linux. Пользователи других систем
должны учесть, что процедура инсталляции
и местоположение конфигурационных файлов могут несколько отличаться.

[править] Установка DHCP-сервера с поддержкой опции 82

В обычном случае установить откомпилированный DHCP-сервер из репозитория пакетов
можно было бы с помощью команды:

%# apt-get install dhcp3-server

и можно было бы считать, что на этом инсталляция сервера закончена,
и можно переходить к его настройке. Однако, в том случае, если предполагается использование
DHCP-ретранслятора (что обязательно, если будет использоваться опция 82),
может потребоваться сборка пакета с включённой директивой USE_SOCKETS.
Подробнее эта процедура описана ниже.

[править] Сборка с включённой директивой USE_SOCKETS

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

   #define USE_SOCKETS 

и указать в конфигурационном файле local-address.

Скачиваем исходники DHCP-сервера:

%# apt-get source dhcp3-server

Перед началом сборки исходников необходимо установить все пакеты,
необходимые для успешной сборки пакета, для чего выполнить:

%# apt-get build-dep dhcp3-server

Теперь необходимо в файле site.h раскомментировать директиву #define USE_SOCKETS:

%# vi dhcp3-3.0.6.dfsg/includes/site.h

Перейти в каталог dhcp3-3.0.6.dfsg:

%# cd dhcp3-3.0.6.dfsg/

Для того чтобы собрать пакет необходимо выполнить:

%$ dpkg-buildpackage -rfakeroot -b

или, если сборка производится root’ом:

%# dpkg-buildpackage -b

После сборки пакеты должны быть установлены в системе
(инсталлируем только common и server, так как нам не нужен DHCP-ретранслятор и DHCP-клиент):

%# dpkg -i dhcp3-common_3.0.6.dfsg-1_i386.deb dhcp3-server_3.0.6.dfsg-1_i386.deb 

[править] Настройка DHCP-сервера

Сразу же после инсталляции пакета,
сервер не заработает — сначала необходимо
отредактировать его конфигурационный файл /etc/dhcp3/dhcpd.conf.

# Укажите адрес, на который DHCP-сервер ожидает получать запросы (адрес DHCP-сервера)

local-address 192.168.2.9;

# Укажите подсеть интерфейса, на котором запущен DHCP-сервер

subnet 192.168.2.0 netmask 255.255.255.0 {
}

# Если сервер получит запрос, содержащий опцию 82, он сгенерирует сообщение в системный журнал
# 

if exists agent.circuit-id
{
 log ( info, concat( " Lease for ", 
                     binary-to-ascii (10, 8, ".", leased-address),
                     " Switch port: ", 
                     binary-to-ascii (10, 8, ".", option agent.circuit-id), 
                     " Switch MAC: ",
                     binary-to-ascii(16, 8, ".", option agent.remote-id)));
}

# Запросы, пришедшие с 5го порта коммутатора: 
class "port-5"
{
 match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "5";
}

# Адрес для 5го порта: 
pool {
  range 192.168.1.55;
  allow members of "port-5";
}

Интерфейс, на котором будет работать DHCP-сервер,
передается ему в качестве аргумента при вызове.

В Debian GNU/Linux аргументы и ключи вызова программ
принято указывать в соответствующих файлах в каталоге /etc/default,
в частности, конфигурационный файл, в котором находятся опции для нашего сервера,
называется /etc/default/dhcp3-server.

При условии, что сервер будет слушать запросы на интерфейсе eth0,
файл будет выглядеть так:

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth0"

Можно указать несколько интерфейсов,
запросы с которых будет обрабатывать сервер.
Они должны быть разделены пробелом.

Теперь можно запускать сервер:

%# /etc/init.d/dhcp3-server start

После сборки сервера с #define USE_SOCKETS:

udp     0   0 192.168.2.9:67    0.0.0.0:*   863/dhcpd3
udp     0   0 192.168.2.9:67    0.0.0.0:*   863/dhcpd3

[править] Написание правил для соответствия адреса порту коммутатора

[править] Используемые операторы

suffix (data-expr, length)

Оператор suffix анализирует выражение data-expr и возвращает последние байты в указанном количестве.
length — это числовое значение.
Если data-expr или length равны нулю, то результат также будет равен 0.
Если длина указанная в length больше чем сами данные, то suffix возвращает все данные.

substring (data-expr, offset, length)

Оператор substring анализирует данные и возвращает строку данных, которая начинается от указанного значения offset и имеет длину, равную указанной в length.
Offset и length — числовые выражения.
Если data-expr, offset или length равны нулю, то результат также равен 0.
Если значение offset больше или равно длине data-expr,
то будет возвращена нулевая строка.
Если длина length больше чем длина данных оставшихся после offset, тогда возвращаемая строка будет содержать все данные от значения offset до конца.

binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)

Преобразует результат вычисления data-expr2 в текстовую строку,
содержащую по одному числу для каждого элемента результата вычисления data-expr2.
Числа разделены между собой результатом вычисления data-expr1.
Параметр numeric-expr1 указывает основание системы исчисления (от 2 до 16),
в которую должны преобразовываться числа.
Параметр numeric-expr2 указывает количество битов на каждое число, полученное
в результате преобразования. Оно может быть равно 8, 16 или 32.

Пример:

              concat (binary-to-ascii (10, 8, ".",
                              reverse (1, leased-address)),
                     ".in-addr.arpa.");

Берём адрес leased-address, инвертируем его, а потом делим на
8 битные числа, каждые из которых преобразуем в 10-чную систему счисления.
Полученные числа объединяем между собой через «.» и присоединяем
«.in-addr.arpa.» справа.

Дополнительная информация:

• man dhcp-eval — описано как создавать такие выражения и описаны другие операторы.

[править] Просмотр информации на коммутаторе

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

Например, в коммутаторе ProCurve опция 82 выглядит следующим образом:

Value: 010200030206001560792800
Agent Circuit ID: 0003
Agent Remote ID: 001560792800

В коммутаторах других производителей
она выглядит аналогично.

Для того чтобы увидеть, каким образом кодируются номера портов в коммутаторе Procurve, необходимо выполнить команду:

sw(config)# walkMIB ifname 
ifName.1 = 1
ifName.2 = 2
ifName.3 = 3
ifName.4 = 4
ifName.5 = 5
ifName.6 = 6
ifName.7 = 7
ifName.8 = 8
ifName.9 = 9
ifName.10 = 10
ifName.11 = 11
..............
ifName.47 = 47
ifName.48 = 48
ifName.102 = DEFAULT_VLAN
ifName.103 = VLAN2
ifName.4197 = lo0

Информация о MAC-адресе коммутатора:

sw#  sh system-information 

 Status and Counters - General System Information

  System Name        : sw                                              
  System Contact     :                                                 
  System Location    :                                                 

  MAC Age Time (sec) : 300    

  Time Zone          : 0    
  Daylight Time Rule : None                      


  Firmware revision  : M.10.06          Base MAC Addr      : 001560-792800
  ROM Version        : I.08.11          Serial Number      : SG602SG00C  

  Up Time            : 2 days           Memory   - Total   : 94,690,424  
  CPU Util (%)       : 6                           Free    : 80,214,320  

  IP Mgmt  - Pkts Rx : 10,267           Packet   - Total   : 1998        
             Pkts Tx : 7874             Buffers    Free    : 1483        
                                                   Lowest  : 1473        
                                                   Missed  : 0           

На коммутаторах D-Link DES-35xx и 3028 выглядит так.

DES-3526:admin#show dhcp_relay
Command: show dhcp_relay

DHCP/BOOTP Relay Status         : Enabled
DHCP/BOOTP Hops Count Limit     : 16
DHCP/BOOTP Relay Time Threshold : 0
DHCP Relay Agent Information Option 82 State  : Enabled
DHCP Relay Agent Information Option 82 Check  : Disabled
DHCP Relay Agent Information Option 82 Policy : Keep
DHCP Relay Agent Information Option 82 Remote ID : 00-15-E9-3D-A1-20 

[править] Примеры правил

Указываем, что нас интересует последний байт в circuit-id:

suffix( option agent.circuit-id, 1)

Делаем преобразование вырезанного байта из двоичного формата в десятичный и указываем, что запрос попадет под правило класса, если результат преобразования будет равен 5.

Правило для порта 5.

class "port-5"
{
 match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "5";
}

pool {
  range 192.168.1.155;
  allow members of "port-5";
}

Аналогично для порта 45:

class "port-45"
{
 match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "45";
}

pool {
  range 192.168.1.45;
  allow members of "port-45";
}

Эти правила могут отличаться при использовании как коммутаторов других производителей,
так и при использовании модульных коммутаторов ProCurve.
Необходимо выяснять каким образом кодируется номер порта.

Если нам необходимо учитывать от какого relay-агента пришел запрос, то можно создать соответствующее правило:

class "relay-1"
{
 match if binary-to-ascii (16, 8, ":", suffix ( option agent.remote-id, 6)) = "0:15:60:79:28:0"; 
 # внимание: преобразование число-текст отрезает не значащие нули слева
}

[править] Пример конфигурационного файла DHCP-сервера

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
local-address 192.168.2.9;
if exists agent.circuit-id
{

 log ( info, concat( "Lease for ", binary-to-ascii (10, 8, ".", leased-address), 
 " raw option-82 info is CID: ", binary-to-ascii (10, 8, ".", option agent.circuit-id), " AID: ",
 binary-to-ascii(16, 8, ".", option agent.remote-id)));
}
subnet 192.168.2.0 netmask 255.255.255.0 {
        range 192.168.2.20 192.168.2.40;
        allow unknown-clients;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
    class "port-5" { 
        match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "5";
    }
    class "port-3" {
        match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "3";
    }
    class "port-45" {
        match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "45";
    }

    pool {
        range 192.168.1.155;
        allow members of "port-5";
    }
    pool {
        range 192.168.1.133;
        allow members of "port-3";
    }
    pool {
        range 192.168.1.45;
        allow members of "port-45";
    }
}

[править] Настройка коммутатора HP ProCurve для работы DHCP-ретранслятором

1. Включить DHCP-ретранслятор на коммутаторе (по умолчанию включен)
2. Включить ip routing
3. Настроить режим вставки опции 82 (drop, replace, validate)
4. Настроить ip helper-address
5. Клиенты и сервер должны быть в разных подсетях

Включение DHCP-ретранслятора на коммутаторе (по умолчанию включен):

sw(config)# dhcp-relay

Включить ip routing (на коммутаторе включается функциональность 3го уровня):

sw(config)# ip routing 

Настроить режим вставки опции 82 (drop, replace, validate):

sw(config)# dhcp-relay option 82 <append [validate] | replace [validate] | drop [validate] | keep>   [ip | mac]

Параметры команды dhcp-relay option 82:

• append — коммутатор добавит опцию 82 в пришедший DHCP-пакет.
• replace — коммутатор заменит опцию 82 в пришедшем DHCP-пакете на свои значения.
• drop — коммутатор отбросит DHCP-пакет, если в нем будет опция 82. Если DHCP-пакет пришел без опции 82, то коммутатор добавит опцию и передаст пакет.
• keep — для любого полученного DHCP-пакета с существующей опцией 82 не выполнять никаких изменений и отправить пакет в таком же виде как он пришел.
• [ip | mac] — что используется в опции 82 в качестве Agent Remote ID. По умолчанию используется MAC-адрес. При использовании IP-адреса, в поле Agent Remote ID будет указан IP-адрес VLAN, в котором был получен запрос от DHCP-клиента.

Настройка ip helper-address (ip helper-address задается в VLAN, в котором находится DHCP-клиент.
IP-адрес в этой команде — это адрес DHCP-сервера):

sw(config)# vlan 1
sw(vlan-1)# ip helper-address 192.168.2.9  

[править] Просмотр настроек на коммутаторе

Посмотреть настроенные ip helper-address для VLAN 1:

sw# show ip helper-address 1

Настройки DHCP-ретранслятора:

sw# show dhcp-relay 
  DHCP Relay Agent         : Enabled 
  Option 82                : Enabled 
  Response validation      : Disabled
  Option 82 handle policy  : drop 
  Remote ID                : mac  


  Client Requests       Server Responses

  Valid      Dropped    Valid      Dropped   
  ---------- ---------- ---------- ----------
  45         0          35         0         

[править] Пример конфигурации коммутатора Procurve

hostname "sw" 
ip routing 
vlan 1 
   name "DEFAULT_VLAN" 
   untagged 1-19,41-48 
   ip address 192.168.1.1 255.255.255.0 
   ip helper-address 192.168.2.9 
   no untagged 20-40 
   exit 
vlan 2 
   name "VLAN2" 
   untagged 20-40 
   ip address 192.168.2.1 255.255.255.0 
   exit 
dhcp-relay option 82 drop 
password manager
password operator

[править] Настройка коммутатора D-LINK для работы DHCP-ретранслятором

Подробнее: FAQ по настройке dhcp relay на коммутаторах DLink серии DES-35xx

# create iproute default 192.168.1.1
# config dhcp_relay add ipif System 192.168.2.9
# config dhcp_relay option_82 state enable
# enable dhcp_relay

[править] Настройка коммутатора Huawei для работы DHCP-ретранслятором

# ip route-static 0.0.0.0 0.0.0.0 192.168.1.254
# dhcp enable
# dhcp server group dhcp-test
#  dhcp-server 172.16.1.1 0
#  dhcp-server 172.16.1.2 1

# interface Vlanif1
#  ip address 192.168.1.1 255.255.255.0
#  dhcp select relay
#  dhcp relay server-select dhcp-test

[править] Настройка коммутатора Zyxel для работы DHCP-ретранслятором

[править] Дополнительная информация

Опция 82:

• man dhcp-eval
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.networking/2005-01/1452.html
• http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftrbeo82.htm
• http://slaptijack.com/networking/what-is-dhcp-option-82/
• D-LINK DHCP Relay option 82 (рус.) — подробное описание процедуры настройки использования опции 82 для коммутаторов D-LINK
• Настройка опции 82 на ES3528M и Dhcpd (рус.) — описание настройки опции 82 на коммутаторах Edge-Core ES3528M
• http://ciscovod.blogspot.com/2009/02/cisco-isg.html

• Настройка опции 82 на Windows DHCP(проверить)
• Linux dhcp клиент с поддержкой опции 82

[править] Материалы по DHCP на Xgu.ru

• DHCP
• Опция 82 DHCP
• DHCP snooping
• Win2k3 DHCP

ProCurve
Основы	ProCurve Adaptive Edge | ProCurve ProActive Defense | ProCurve Network Access Control | ProCurve Wireless
Программы	ProCurve Manager | ProCurve Identity Driven Manager | ProCurve Network Immunity Manager | ProCurve Mobility Manager
Устройства	ProCurve Switch | ProCurve Router | ProCurve ONE Module | ProCurve TMS Module | ProCurve NAC 800 | ProCurve Access Point | ProCurve WESM
Настройка
Безопасность	ProCurve Security | Доступ к коммутатору ProCurve | DHCP snooping | Dynamic ARP Protection | IP Source Guard | Port security | Аутентификация при доступе к сети | 802.1X в ProCurve‎ | Web-аутентификация в ProCurve | MAC-аутентификация в ProCurve
Канальный уровень	CDP | LLDP | VLAN в ProCurve | GVRP | STP в ProCurve | ProCurve Mesh | Агрегирование каналов | Зеркалирование трафика | QinQ
Сетевой уровень	RIP в ProCurve | OSPF в ProCurve | VRRP в ProCurve | XRRP в ProCurve | QoS в ProCurve | Multicast в ProCurve | PIM в ProCurve
Разное	Опция 82 DHCP | SNMP в ProCurve

Cisco Systems, Inc.
Устройства	Cisco 871 • Cisco Router • Cisco Switch • Сisco Сatalyst  • Cisco IPS • Cisco ASA • PIX • Dynamips
Безопасность (коммутаторы и маршрутизаторы)	Cisco Security • Port security • DHCP snooping • Dynamic ARP Protection • IP Source Guard • Аутентификация при доступе к сети • 802.1X в Cisco • Zone-Based Policy Firewall • Cisco NAT • NAT в Cisco  • Cisco SSH
Cisco ASA	Cisco ASA/NAT • Cisco ASA/Troubleshooting • Cisco ASA/IPS • Cisco ASA failover • Cisco ASA/Transparent firewall • Cisco ASA/Site-to-Site_VPN • Cisco ASA/Easy_VPN • Cisco ASA/WebVPN • Объединение OSPF-сетей туннелем между двумя системами ASA (без GRE) • Центр сертификатов на Cisco ASA
VPN	IPsec в Cisco • Cisco IOS Site-to-Site VPN  • DMVPN  • Cisco Easy VPN • Cisco Web VPN • Cisco ipsec preshared
Канальный уровень	CDP  • VLAN в Cisco  • ISL  • VTP  • STP в Cisco  • Cisco Express Forwarding  • Агрегирование каналов  • Зеркалирование трафика  • QinQ  • Frame Relay
Сетевой уровень	Маршрутизация в Cisco  • RIP  • EIGRP  • IS-IS  • OSPF • BGP  • PIM  • Multicast  • GLBP  • VRRP  • HSRP  • DHCP  • IPv6  • IPv6 vs IPv4  • Резервирование Интернет-каналов без использования BGP • Использование BGP для резервирования Интернет-каналов
Разное	Режим ROMMON в Cisco • Опция 82 DHCP • 802.1X и RADIUS • SNMP в Cisco • QoS в Cisco  • EEM  • Troubleshooting  • Автоматизация работы устройств Cisco  • Cisco NTP  • Cisco IP SLA  • Cisco Enhanced Object Tracking

Сообщения без ответов | Активные темы

Автор	Сообщение
	Заголовок сообщения: Windows 2012 DHCP 82 option и коммутаторы Dlink Добавлено: Ср окт 23, 2013 10:41
Зарегистрирован: Сб ноя 01, 2008 10:47 Сообщений: 49	Господа, неслышен что в сервера Windows 2012 в DHCP появилась возможность использовать 82 опцию. Кто нибудь может поделится информацией ? Документации в инете внятной не нарыл. Очень хочется подружить со своими коммутаторами Dlink. _________________ DES-3552, DES—3028-3052, 3200-10, 3526,DGS-3200-10, DGS-3612G
Вернуться наверх

dawas	Заголовок сообщения: Re: Windows 2012 DHCP 82 option и коммутаторы Dlink Добавлено: Ср окт 23, 2013 11:11
Зарегистрирован: Сб апр 12, 2008 09:03 Сообщений: 88 Откуда: Московская область
Вернуться наверх

Wanderer2	Заголовок сообщения: Re: Windows 2012 DHCP 82 option и коммутаторы Dlink Добавлено: Ср окт 23, 2013 11:18
Зарегистрирован: Сб ноя 01, 2008 10:47 Сообщений: 49
Вернуться наверх

Wanderer2	Заголовок сообщения: Re: Windows 2012 DHCP 82 option и коммутаторы Dlink Добавлено: Вс янв 26, 2014 10:54
Зарегистрирован: Сб ноя 01, 2008 10:47 Сообщений: 49	Сам себе отвечу, да можно работает нормально, внятной документации так и не нашел, методом тыка победили, подружили DES 3552 и DES3200-10, кому интересно опишу туту. _________________ DES-3552, DES—3028-3052, 3200-10, 3526,DGS-3200-10, DGS-3612G
Вернуться наверх