Суть задачи в том, что в большой организации нужен был отказоустойчивый DHCP-сервер, с dhcp-relay и возможностью быстро синхронизировать конфигурацию. Основной момент, что в большинстве найденных мной руководствах рассматривается либо вариант failover, либо dhcp-relay и нигде оба варианта не рассматривались вместе да ещё и с удобным методом синхронизации конфигурации. Вдруг кому моя статья немного поможет?
Суть задачи в следующем: есть большое предприятие, сеть на >1000 компов, единственный vlan, 2 контроллера домена, в сети dhcp отсутствует(!). Предыдущие админы умели только так, но это отдельный рассказ и не для Хабра.
Понятно, что первой же задачей стала модернизация сети, а именно сегментация на vlan и внедрение dhcp. При анализе задачи были выработаны следующие требования:
- Отказоустойчивость — независимость от какого-либо железа
- Учитывая планы по сегментации сети — необходимо, чтоб сервер знал, в какой vlan какую адресацию отдавать
- «Репликация» — учитывая, что планируется широко использовать dhcp «привязки» по MAC, нужно чтоб эти «привязки» работали всегда (например, сетевые принтеры)
- Автоматическое ведение обратных DNS зон
Не буду описывать долгие размышления и чтения различных статей и мануалов, привожу итоговое рабочее решение:
- Две виртуальные машины на двух разных гипервизорах
- На машинах стоит centos7 и isc-dhcpd
- На dhcp настроены failover, динамическое обновление зон и распознавание option 82
- Option 82 меткой того VLAN, из которого пришел запрос, серверу отдают центральные коммутаторы L3+, на которых все VLAN и разруливаются
- Так как большинство админов плохо ориентируются в linux и vim, нужна автоматизация процесса добавления статических привязок и механизм репликации конфига
Схема сети:
Имеем:
- DC0 и DC1 с настроенными DNS серверами, 10.1.2.2 и 10.1.2.3
- DHCP0 и DHCP1, 10.1.2.4 и 10.1.2.14
- VLAN'ы пользователей: 10, 11, 20, 21
- Домен corp.example.ru
- Дополнительную DNS зону (для linux серверов) — example.lan
- Маршрутизаторы на базе L3 коммутаторов с поддержкой dhcp option 82. Во всех VLAN'ах они имеют 1-й IP адрес, связаны через OSPF
Так как некоторые вещи достаточно тривиальны и описаны в интернете не раз, подробно их расписывать не буду.
- Для начала в Windows DNS создаем все обратные зоны для всех VLAN'ов, разрешаем зонам небезопасные обновления.
- Устанавливаем на виртуальные машины минимальный centos 7, устанавливаем пакет dhcp.
- Настраиваем DHCP-relay на интерфейсах управляемых коммутаторов. При этом в качестве circuit-id приходит строка «VLAN10» и т.п.
- Редактируем /etc/dhcp/dhcpd.conf
# DHCP Server Configuration file. # see /usr/share/doc/dhcp*/dhcpd.conf.example # see dhcpd.conf(5) man page # # ddns-update-style interim; # Тип обновлений ddns-domainname "corp.example.ru"; # Имя нашего домена update-static-leases on; # На всякий случай local-address 10.1.2.4; # Адрес сервера # Логгинг информации, если запрос пришел от DHCP-relay if exists agent.circuit-id { log ( info, concat( " Accepted DHCP RELAY request for ", binary-to-ascii (10, 8, ".", leased-address), " Network segment: ", option agent.circuit-id, " DHCP Agent: ", option agent.remote-id)); } # this DHCP server to be declared valid authoritative; # Настройка безотказности failover peer "dhcp-failover" { primary; # Этот сервер главный address 10.1.2.4; # Его адрес port 519; # Его порт peer address 10.1.2.14; # Адрес второго DHCP peer port 520; # Порт второго DHCP # Дополнительные параметры настройки max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; mclt 1800; split 128; # эта опция позволяет оставшемуся в работе DHCP серверу # использовать ту половину пула адресов, # которая осталась от "упавшего" сервера через Х секунд. auto-partner-down 86400; #за эту опцию спасибо @baf28 } # Сообщаем этот суффикс всем клиентам option domain-name "corp.example.ru"; # DNS-сервера option domain-name-servers 10.1.2.2, 10.1.2.3; # Дополнительные DNS-суффиксы. Не работает для Windows-клиентов option domain-search "example.lan corp.example.ru"; # Настройка времени аренды default-lease-time 604800; # 7 days max-lease-time 2419200; # 4 weeks # default netmask /24 option subnet-mask 255.255.255.0; # Servers vlan - без DHCP subnet 10.1.2.0 netmask 255.255.255.0 { } # Дополнительные файлы конфигурации для VLAN'ов include "/etc/dhcp/dhcpd.d/vlan10.conf"; include "/etc/dhcp/dhcpd.d/vlan11.conf"; include "/etc/dhcp/dhcpd.d/vlan20.conf"; include "/etc/dhcp/dhcpd.d/vlan21.conf";
- Теперь добавляем файл конфигурации для каждого VLAN (на примере /etc/dhcp/dhcpd.d/vlan10.conf)
# Объявление зон для безболезненного динамического обновления zone 10.1.10.in-addr.arpa. { primary 10.1.2.2; secondary 10.1.2.3; } # Описываем класс для фильтрации запросов от DHCP-relay class "VLAN10" { match if option agent.circuit-id = "VLAN10"; } # Объявляем саму нашу сеть subnet 10.1.10.0 netmask 255.255.255.0 { option routers 10.1.10.1; pool { failover peer "dhcp-failover"; # Указание на то, какой failover использовать range 10.1.10.51 10.2.56.254; # Диапазон allow members of "VLAN10"; # Привязка к классу } # === Static hosts # Admin host admin { hardware ethernet 01:23:45:67:89:ab; fixed-address 10.1.10.20; } # Admin's printer host admin { hardware ethernet cd:ef:01:23:45:67; fixed-address 10.1.10.21; } # Строчка ниже используется самописным скриптом как маркер того, # что ниже нужно вставить текст для статической привязки очередного устройства # Insert automatic text above this }
- Для второго DHCP сервера создаем аналогичные конфиги, только исправляем в основном файле:
failover peer "dhcp-failover" { secondary; # Этот сервер запасной address 10.1.2.14; # Его адрес port 520; # Его порт peer address 10.1.2.4; # Адрес главного DHCP peer port 519; # Порт главного DHCP # Дополнительные параметры настройки max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; # эта опция позволяет оставшемуся в работе DHCP серверу # использовать ту половину пула адресов, # которая осталась от "упавшего" сервера через Х секунд. auto-partner-down 86400; #за эту опцию спасибо @baf28 }
Получились у нас 2 dhcp сервера, в случае отключения одного из них его функции подхватывает второй, при этом оба отвечают на запросы от dhcp relay agent и на основании установленной в dhcp option 82 circuit-id строки (в нашем случае имя VLAN) выдает каждому сегменту его диапазон.
Для репликации серверов достаточно написать скрипт, который синхронизирует файлы в каталоге "/etc/dhcp/dhcpd.d/" и перезапускает dhcp-демон после этого. Сам скрипт приводить не буду из-за очень «костыльного» кода, который писался на коленке и на очень скорую руку. Возможно синхронизировать конфиги с помощью утилиты типа csync2 или rsync.
Для добавления статических привязок также был написан отдельный скрипт, который мне стыдно приводить тут по тем же причинам. Каждый может порезвиться с этим сам либо добавлять статические привязки «ручками».
Единственное «но» — при добавлении нового VLAN основной файл конфигурации "/etc/dhcp/dhcpd.conf" придется править ручками, так как у меня не получилось сделать include на весь каталог, только на конкретные файлы.
Возможно это можно обойти двойным include: сначала в основном файле на вспомогательный, а во вспомогательном уже на конкретные файлы VLAN, а затем синхронизировать и вспомогательный, но я заморачиваться не стал.
Повторюсь ещё раз — большинство информации, описанной мной, в интернете навалом, но нигде я не нашел как совместить failover, dhcp-relay и сделать это удобным для синхронизации. Жду ваших замечаний и предложений
Комментарии (53)
baf28
15.03.2017 13:08+1Рекомендую в оба файловер сервера добавить
auto-partner-down 86400;
иначе, если один выйдет из строя, то у второго останеца только половина пула из пула.
a_putsev
15.03.2017 13:13Да, спасибо большое! Этот момент из-за большого выделенного диапазона адресов я как-то не заметил. Очень ценное замечание
justabaka
15.03.2017 13:40нигде я не нашел как совместить failover, dhcp-relay и сделать это удобным для синхронизации
Жаль, а ведь это самое главное и интересное.
mikes
15.03.2017 14:14не описано как коммутаторы шлют запросы на второй dhcp… в dhcp helper указаны оба сервера?
я решил вопрос с конфигами и разными адресами при помощи linux ha-cluster где есть переходящий ip которому и шлют запросы коммутаторы, а так же lsyncd который синхронизирует конфиги по изменению файлов.
Остается после внесения изменений протетстить конфиг и перезапустить оба dhcpda_putsev
15.03.2017 14:27Стоят коммутаторы HP — H3C. Там это настраивается как:
dhcp relay server-group 0 ip 10.1.2.4
dhcp relay server-group 0 ip 10.1.2.14
....
interface Vlan-interface10
description USERS10
ip address 10.1.10.1 255.255.255.0
dhcp select relay
dhcp relay server-select 0
dhcp relay information enable
dhcp relay information circuit-id string VLAN10
dhcp relay information remote-id string sysname
Касаемо разных адресов же — вариантов много. Я вот думаю всё про вариант с csync2, с которым тоже имел опыт работы, хотя и ваша схема очень даже ничего. Просто ещё не имел опыта работы с ha-clustermikes
15.03.2017 14:44Всегда расстраивало требование иметь ip адреса в клиентском пуле у коммутаторов что у HP, что Cisco.
как ни странно dlink в этом плане удобнее.a_putsev
15.03.2017 14:51Насчет IP адресов врать не буду, возможно это заработает и без IP адреса. На этом же устройстве происходит дальнейшая маршрутизация трафика с VLAN, поэтому IP там необходим именно с этой целью.
Так же прошу учесть что это не совсем HP, а скорее H3C, который был перекуплен HP впоследствии. CLI у него и у HP ProCurve (сейчас HP Aruba) различаются очень и очень сильно!
KrD
15.03.2017 15:16Во-первых, ISC DHCP поддерживает директиву include, чтобы править каждый раз не dhcpd.conf, а только отдельный файл. Во-вторых, если есть такая необходимость, то нужный файл конфига можно генерировать посредством тривиального Makefile. В моём случае применялись оба подхода.
a_putsev
15.03.2017 15:23Этой директивой и пользуюсь активно. Одна проблема — include не умеет смотреть в каталог или искать файлы по маске. В параметре ожидается только уникальное имя файла и победить это я не смог.
Один вариант решения я описал в предпоследнем абзаце в статье, так как мне он на ум пришел уже при написании статьи, Ваш вариант с Makefile и регулярная генерация конфига мне кажутся излишними, так как сегменты добавляются достаточно редко.
martin74ua
15.03.2017 16:24-4А можно вопрос? А зачем файловер?
Запускаем два (можно больше) dhcp серверов с идентичными конфигами и все… Никаких проблем.
Схема работает в провайдерской сети уже более 10 лет…
vasilevkirill
15.03.2017 19:42До первого кривого dhcp client, который не проверит обычным arp запросом занятость адреса.
a_putsev
16.03.2017 08:09Проблема в том, что за годы существования без DHCP и без DNS как такового, на предприятии у некоторых сотрудников выработалась любовь к обозначению компов на основании IP. Соответственно, при падении сервера, адреса изменятся, что может вызвать отказы в сети.
martin74ua
16.03.2017 13:19Кто изменятся???
Адреса фиксируете за компами. Например по тому же маку. Ну или все таки доделываете поддержку option 82 и выдаете по ней — т.е. выдаете адрес на основании адреса и порта коммутатора.
И два идентичных конфига раздаете на два dhcp сервера.
И ничего никуда не изменится…
martin74ua
15.03.2017 21:37Эээээ… Т.е. вы думаете что за 10 с лишним лет работы в сети провайдера на несколько десятков тысяч клиентов я видел не все dhcp клиенты? ;) Это во первых.
А во вторых — ну не проверил он. И? Ну взял он адрес, никого не уведомил о занятии адреса. Следующий проверит ;) Или у нас двое, которые не проверят? У меня динамически выдаются адреса из отдельного блока в каждой подсети, а вообще за клиентом адрес фиксируется. Пока по маку… Так что и тут ничего страшного…martin74ua
16.03.2017 13:22Я просто на самом деле не могу понять — зачем вообще нужен механизм dhcp failover. Какую задачу он решает?
Я пытался использовать его. А потом просто выкинул из конфига блок с его поддержкой — ничего не изменилось. Адреса выдаются обоими серверам, примерно в соотношении 60% на 40% (первый выдает 60% адресов). При аварии любого из серверов — ничего не меняется, второй так же спокойно держит клиентов…a_putsev
16.03.2017 13:31+1Поясню свою мысль:
При нормальной работе есть 2 группы клиентов: динамические и динамические с привязкой конкретного IP по MAC-адресу клиента. В этом случае «привязанные» клиенты получают их IP-адреса, а «динамические» клиенты — адреса из пула. Срок резервирования IP увеличен до недели.
В случае отсутствия failover при падении primary сервера «динамические» клиенты получат новые адреса, так как secondary сервер ничего не знает о lease'ах, которые хранятся на упавшем сервере.
В случае failover же primary и secondary обмениваются информацией и lease, соответственно даже «динамические» клиенты получат тот же самый адрес.
Не исключено, что я где-то ошибаюсь, если поправите — буду признателен.martin74ua
16.03.2017 15:15при нормальной работе ести две группы клиентов — с фиксированными адресами (всегда получают по dhcp один и тот же адрес) и временные — получают адрес из небольшого блока и неважно, какой они там получили, лишь бы заработало — всякие смарты, ноуты, новое железо… А после «постановки на баланс» (условно назовем) клиенту выделяется фиксированный адрес и все…
a_putsev
16.03.2017 15:48Ключевое слово — при нормальной работе. Если прочитаете преамбулу статьи, поймете, что многое идет не совсем «корректно». Опять же — нужно где-то держать базу MAC адресов, а компы постоянно переезжают, причем иной раз и без ведома IT службы и т.п. Поэтому-то и нужен failover. :(
martin74ua
16.03.2017 16:27тем самым вы поощряете дальнейший бардак ;)
Держать где то базу маков надо все равно. Если уж вы останавливаетесь на linux решениях — используйте любой IPAM который вам подойдет. IPPlan, OCS, что то подобное. Вам все равно нужна база по железу и софту ;)
Вообщем неубедительно ;)
baf28
16.03.2017 04:24-1Я не знаю как работает dhcp ralay, но у cisco есть отличная команда helper ip которая решает данную проблему на маршрутизаторе.
DaemonGloom
16.03.2017 07:05+1Команда ip helper-address для cisco — это и есть реализация dhcp relay.
Elordis
16.03.2017 06:54+1Мне одному кажется, что Option 82 здесь лишняя?
ISC DHCP вполне может определить, какой IP выдавать на основании «giaddr», который вставляется релеями. Option 82 нужен, если хочется определять положение DHCP-клиента с точностью до конкретного порта конкретного коммутатора.a_putsev
16.03.2017 08:12Да, но возможна ситуация по подобию вот этого:
Сейчас коллега протестировал Вашу конфигурацию. Всё работает отлично за исключением одной тонкости: диапазон, из которого будет выдаваться IP-адрес клиенту выбирается на основе IP того интерфейса dhcp relay agent'а, на который пришел запрос от клиента первоначально, а не на основе поля в dhcp-пакете.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
iddqda
16.03.2017 12:22+1Если на этом интерфейсе висит несколько адресов из разных VLAN
под интерфейсом здесь понимается L3 интерфейс, правильно?
Тогда остальное в предложении звучит странно. И если так и бывает то так делать точно не надо.
Или признайте, что VLAN-ы все таки тут не разные. Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Так вот option82 тут никак не поможет.
Вам кажется что Вы выдали адрес на основе option82
Но судя по приведенному конфигу, все происходит вовсе не так
запрос попадает в subnet, на основе адреса релея (того самого L3 интерфейса)
потом dhcp сервер выбирает адрес из pool
а потом на основе вашей option82 происходит тупая фильтрация — выдавать адрес или нет.
Сам option82 никак не определяет из какого диапазона будет этот адрес. Так что Вы и сами заблудились и других заблудили. Проверьте, попробуйте убрать все ваши классы и условия. Ничего не изменится
Ну а что касается репликации статических лизов, то у меня как раз есть решение.
идея очень простая:
Если статическую запись host{} вынести за subnet{}, то сервер все равно сопоставит host с subnet и аккуратно добьет статический IP адрес соответствующими опциями (маска шлюз DNS NTP итп) из subnet.
А значит всю статику можно вынести в отдельный файл и просто использовать директиву Include.
А уж отдельный файл можно легко реплицировать любыми средствами.
Хотя лично я вместо репликации генерирую его из IPAM. Очень удобно.a_putsev
16.03.2017 12:30Или признайте, что VLAN-ы все таки тут не разные.
Признал — если интересно — посмотрите комменты выше. Но забыл в статье поправить, тут уж простите великодушно.
Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Согласен, но пока нет организационной возможности сразу выделить VLAN на группу клиентов. Поэтому переход плавный — сначала их на новую адресацию, в т.ч. и с разными диапазонами в одном VLAN, а затем уже эту группу клиентов обособлять в отдельный.
Что касается основной части Вашего комментария, попробую проверить на «полигоне» — по результатам скорее всего завтра напишу. Заинтриговали.
iddqda
16.03.2017 12:26тут так же лишние слова про DHCP-relay
релеем выступает коммутатор
DHCP сервер парсит значения, которые relay вставил в пакет, но сам никаким боком релеем не является.
Это даже из приведенной схемы очевидноa_putsev
16.03.2017 12:32Полностью согласен, но, к сожалению, иначе заголовок получался слишком уж длинным, поэтому смог сформулировать только так.
Pentoxide
16.03.2017 10:101. Есть (был) неофициальный патч для isc-dhcp который добавляет поддержку sub-class, посмотрите, может быть полезно, у меня после его добавления размер конфига уменьшился и метод его генерации упростился.
2. На наге была тема как пилили связку dhcp -> mysql кажется, очень удобно, не нужна генерация конфига и перезапуск dhcp сервера в принципе. Подробнее не расскажу, я реализовать это не успел, поменял работуa_putsev
16.03.2017 10:27Спасибо за наводку, постараюсь посмотреть, как только разгребу текущие задачи
Ivan_83
23.03.2017 03:161. Можно было сделать сильно-сильно проще.
dnsmasq умеет делать ARP пинг, достаточно было посадить два и более сервера во все вланы, и никакие релей агенты и репликации были бы не нужны.
Ну разве что конфиги у них синхронизировать :)
2. Есть DHCP сервер на перле: http://netlab.dhis.org/wiki/ru:software:perl:dhcp_server
релей агенты ему обязательны, а вот вместо дописывания базы можно докарябать любую логику.
ISC слишком закостенелый и большой, как и весь софт ISC.
2 DaemonGloom
Венду в топку!
Ляжет она со своим доменом, репликацией и потом вся сеть ляжет следом.
Везде где можно обойтись без венды — лучше обходится без неё.a_putsev
23.03.2017 07:561. Был у меня на предыдущей работе развернут DHCP с «дыркой» в каждый vlan. В итоге сетевые настройки сервера превращались в что-то нечитаемое. И любой перенос этого сервера превращался в очень такую серьезную задачу.
Кроме того, это нереально, если vlan терминируются (маршрутизируются) на разных железках, объединенных через отдельную сеть и через ospf. В случае с relay — всё норм. Эта конфигурация гибче, хоть и естественно сложнее.
2. Не сталкивался с этим софтом в работе, а так как требовалось поднять быстро и надолго, то не стал уходиьт от знакомого.
3. Как средней руки *nix'оид могу сказать, что тут Вы не совсем правы.
- Момент первый: Если лягут все DC, то большая часть сети и так ляжет, так как вся авторизация идет через домен.
- Второе, на что регулярно указывают мне коллеги, когда я везде проталкиваю *nix, — найти у нас в провинции «виндового админа» всё равно проще пока что, чем человека с опытом администрирования *nix.
- Третье — надежность windows домена проверена просто огромным множеством корпоративных (очень крупных) клиентов, к тому же и инструментов по резервированию этого всего уже придумано достаточно.
- Правда DaemonGloom в том, что дополнительно поднимать 2 сервера, хоть и виртуальных, возможно не совсем целесообразно, хотя конечно isc-dhcp в плане ресурсов системы очень и очень скромен. Со своей стороны могу сказать, что на тот момент я не знал про Windows практически ничего, потому этот вариант не рассматривал
- Операционная система, в т.ч. и серверная — это всего лишь инструмент. Задачи решает ПО, которое «крутится» под конкретной операционкой. Один инструмент лучше для одного, другой — для другого, это ещё и от ситуации во многом зависит, так что огульно писать, что «Венду в топку» не стоит.
Но мне моё решение всё равно нравится, может и статья будет полезна кому-либо.
DaemonGloom
У вас уже есть AD и DNS в нём же. Чем вас не устроил DHCP сервер на windows (на тех же серверах с теми же лицензиями)? Они могут всё, что вам нужно и без особых проблем. Встроенная репликация с отказоустойчивостью прилагаются.
a_putsev
Отвечу честно и по пунктам.
DaemonGloom
1. Здесь он тоже настраивается быстро и просто.
4. Стоит просто считать это кнопкой «сохранить». Добавил устройств в резервирование — нажал кнопку. Либо можно скачать скрипт с technet.microsoft.com и всё будет автоматически: https://blogs.technet.microsoft.com/teamdhcp/2012/11/27/automatic-syncing-of-scope-configuration-changes-between-2-dhcp-failover-servers/
6. Это делается примерно так: https://community.spiceworks.com/topic/123943-multiple-vlan-s-using-a-single-dhcp-server-via-dhcp-relay-agent
a_putsev
Спасибо за ссылки, надо будет попробовать такую конфигурацию. На самом деле failover коллега уже тестирует, осталось с relay разобраться.
В любом случае, выбор в сторону linux'а был сделан по причине наличия опыта настройки этого ПО и срочности задачи, так что не обессудьте, если что.
a_putsev
Сейчас коллега протестировал Вашу конфигурацию. Всё работает отлично за исключением одной тонкости: диапазон, из которого будет выдаваться IP-адрес клиенту выбирается на основе IP того интерфейса dhcp relay agent'а, на который пришел запрос от клиента первоначально, а не на основе поля в dhcp-пакете.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
DaemonGloom
Лучше бы такие сегменты разделять на отдельные, потом меньше проблем будет. Но можно и опцию 82 использовать, это тоже не проблема:
http://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/200248-Configuring-Microsoft-Windows-Server-201.html
https://blogs.technet.microsoft.com/teamdhcp/2012/10/01/dhcp-policies-based-on-relay-agent-information-option-option-82-dhcp-snooping-and-ip-source-guard/
a_putsev
Спасибо! Будем ещё экспериментировать с такой связкой для поиска подводных камней.
bryukhanovaa
мне кажется это описание ситуации не с адресами в разных VLAN, а с secondary адресами на интерфейсах
a_putsev
Именно так, спасибо за уточнение. Хотел написать «несколько адресов из разных диапазонов», но как обычно всё перепутал.
bryukhanovaa
но тогда выходит, что хоть с учетом номера VLAN в circuit-id, что с учетом ip-адреса релея — ситуация с secondary адресом не будет адекватно обрабатываться. единственное чего омжно добиться, выдавая адреса на основе VLAN ID — это выдавать адреса из подсети одного из секондари адресов на интерфейсе. и все. а в остальном оба варианта дадут один результат — под одному пулу на VLAN
a_putsev
Да, конечно Вы правы, потому я и написал «ситуация является больше ненормальной и искусственно смоделированной», но есть ньюанс.
Сразу оговорюсь, чтобы были понятна ситуация — тесты других конфигураций были очень ограниченными, так как добившись рабочего и тестированного конфига, система была выпущена в продакшн без рассмотрения особых альтернатив.
В текущем варианте (ISC-DHCP с раздачей адресов на основании relay agent circuit-id) на «secondary» диапазоны можно привязывать IP по MAC, т.е. работают статические lease.
Вероятнее всего всё это реализуемо и под Windows DHCP (хотя «с наскоку» это у меня с коллегой и не получилось), и в случае ISC-DHCP с раздачей адресов на основании giaddr, но утверждать этого не стану, пока не протестирую.
alexrus
Коллегам, у которых:
можно палец показать, уже смешно будетне хватит начальных знаний даже понять смысл этой статьи.VitalKoshalew
Стоит иметь в виду, что в некоторых случаях дополнительные лицензии всё же понадобятся. Если сетевой принтер не лезет в доменный DNS-сервер (и тем более в LDAP), то единственным сервисом на базе Windows Server для него будет DHCP.
Таким образом, если использовать DHCP-сервер на Windows, нужно каждому принтеру купить по Windows Server Device CAL, а если сторонний и не пускать принтеры к прочим Windows-сервисам, то можно сэкономить ~USD220 на каждом принтере. Для малого бизнеса может быть весьма актуально.
DaemonGloom
Однако, если у ваших пользователей уже есть User CAL, то дополнительная лицензия на принтер не требуется.
(Licensing How To: When do I need a Client Access License (CAL)?)a_putsev
Очень интересный и важный момент. К сожалению, тонкости лицензирования и лицензионной политики часто ускользают от внимания руководства и тех.персонала, в т.ч. и меня, так как в серверном плане начинал с *nix систем, и некоторые привычки порой сложно преодолеть.
DaemonGloom
Тогда вам необходимо указанную статью прочесть. Лицензирование майкрософта — это безумие.
Из дополнительного безумия — если у вас работает одна виртуальная машина с windows в кластере из, например, 5 серверов (с любым гипервизором, хоть hyper-v, хоть xen/kvm/esxi), то вам нужно купить 5 лицензий. По штуке на каждый физический сервер, где эта виртуальная машина может оказаться.
VitalKoshalew
Согласен, но если хотя бы часть рабочих мест лицензирована с использованием Device CAL и с них могут использовать сетевые принтеры, то принтерам нужны отдельные Device CAL.
Собственно, я хотел лишь заострить внимание на этом аспекте. Другим примером может служить гостевой доступ (Wi-Fi в переговорной комнате), наверное, ещё какие-то варианты использования также потребуют CAL. Про это просто не нужно забывать и в каждом конкретном случае разбираться самостоятельно.