Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
У вас уже есть AD и DNS в нём же. Чем вас не устроил DHCP сервер на windows (на тех же серверах с теми же лицензиями)? Они могут всё, что вам нужно и без особых проблем. Встроенная репликация с отказоустойчивостью прилагаются.
Отвечу честно и по пунктам.
- Я пришел на новое место работы и DHCP нужен был очень быстро, так как раздавать IP по тетрадке было очень «некомильфо»
- Домен на тот момент был поднят на Windows 2008 (не R2) и находился в зачаточном состоянии, через 4 месяца его просто создали заново по различным причинам. К тому же я на тот момент очень плохо знал возможности windows
- У меня уже был опыт настройки isc-dhcp c failover и relay по отдельности, решил попробовать совместить эти два момента
- Репликация резервирования IP-адресов в windows происходит по нажатию клавиши (сейчас нагуглил уже)
- Хотелось показать коллегам, что линукс не страшен и позволяет очень даже многое.
- До сих пор (может за ненадобностью) не нашел быстрого и понятного способа разделить раздачу разных диапазонов в разные VLAN, хотя это конечно не аргумент и указывает больше на мою лень
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
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
Спасибо за ссылки, надо будет попробовать такую конфигурацию. На самом деле failover коллега уже тестирует, осталось с relay разобраться.
В любом случае, выбор в сторону linux'а был сделан по причине наличия опыта настройки этого ПО и срочности задачи, так что не обессудьте, если что.
В любом случае, выбор в сторону linux'а был сделан по причине наличия опыта настройки этого ПО и срочности задачи, так что не обессудьте, если что.
Сейчас коллега протестировал Вашу конфигурацию. Всё работает отлично за исключением одной тонкости: диапазон, из которого будет выдаваться IP-адрес клиенту выбирается на основе IP того интерфейса dhcp relay agent'а, на который пришел запрос от клиента первоначально, а не на основе поля в dhcp-пакете.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
Лучше бы такие сегменты разделять на отдельные, потом меньше проблем будет. Но можно и опцию 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/
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/
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса.
мне кажется это описание ситуации не с адресами в разных VLAN, а с secondary адресами на интерфейсах
мне кажется это описание ситуации не с адресами в разных VLAN, а с secondary адресами на интерфейсах
Именно так, спасибо за уточнение. Хотел написать «несколько адресов из разных диапазонов», но как обычно всё перепутал.
но тогда выходит, что хоть с учетом номера VLAN в circuit-id, что с учетом ip-адреса релея — ситуация с secondary адресом не будет адекватно обрабатываться. единственное чего омжно добиться, выдавая адреса на основе VLAN ID — это выдавать адреса из подсети одного из секондари адресов на интерфейсе. и все. а в остальном оба варианта дадут один результат — под одному пулу на VLAN
Да, конечно Вы правы, потому я и написал «ситуация является больше ненормальной и искусственно смоделированной», но есть ньюанс.
Сразу оговорюсь, чтобы были понятна ситуация — тесты других конфигураций были очень ограниченными, так как добившись рабочего и тестированного конфига, система была выпущена в продакшн без рассмотрения особых альтернатив.
В текущем варианте (ISC-DHCP с раздачей адресов на основании relay agent circuit-id) на «secondary» диапазоны можно привязывать IP по MAC, т.е. работают статические lease.
Вероятнее всего всё это реализуемо и под Windows DHCP (хотя «с наскоку» это у меня с коллегой и не получилось), и в случае ISC-DHCP с раздачей адресов на основании giaddr, но утверждать этого не стану, пока не протестирую.
Сразу оговорюсь, чтобы были понятна ситуация — тесты других конфигураций были очень ограниченными, так как добившись рабочего и тестированного конфига, система была выпущена в продакшн без рассмотрения особых альтернатив.
В текущем варианте (ISC-DHCP с раздачей адресов на основании relay agent circuit-id) на «secondary» диапазоны можно привязывать IP по MAC, т.е. работают статические lease.
Вероятнее всего всё это реализуемо и под Windows DHCP (хотя «с наскоку» это у меня с коллегой и не получилось), и в случае ISC-DHCP с раздачей адресов на основании giaddr, но утверждать этого не стану, пока не протестирую.
Хотелось показать коллегам, что линукс не страшен и позволяет очень даже многое.
Коллегам, у которых:
- >1000 хостов
- домен в зачаточном состоянии
- айпи адреса в тетрадке записаны
Стоит иметь в виду, что в некоторых случаях дополнительные лицензии всё же понадобятся. Если сетевой принтер не лезет в доменный DNS-сервер (и тем более в LDAP), то единственным сервисом на базе Windows Server для него будет DHCP.
Таким образом, если использовать DHCP-сервер на Windows, нужно каждому принтеру купить по Windows Server Device CAL, а если сторонний и не пускать принтеры к прочим Windows-сервисам, то можно сэкономить ~USD220 на каждом принтере. Для малого бизнеса может быть весьма актуально.
Таким образом, если использовать DHCP-сервер на Windows, нужно каждому принтеру купить по Windows Server Device CAL, а если сторонний и не пускать принтеры к прочим Windows-сервисам, то можно сэкономить ~USD220 на каждом принтере. Для малого бизнеса может быть весьма актуально.
Однако, если у ваших пользователей уже есть User CAL, то дополнительная лицензия на принтер не требуется.
The one caveat is, if your users who use the printer have CALs then the printer is covered by their use via their CALs.(Licensing How To: When do I need a Client Access License (CAL)?)
Очень интересный и важный момент. К сожалению, тонкости лицензирования и лицензионной политики часто ускользают от внимания руководства и тех.персонала, в т.ч. и меня, так как в серверном плане начинал с *nix систем, и некоторые привычки порой сложно преодолеть.
Тогда вам необходимо указанную статью прочесть. Лицензирование майкрософта — это безумие.
Из дополнительного безумия — если у вас работает одна виртуальная машина с windows в кластере из, например, 5 серверов (с любым гипервизором, хоть hyper-v, хоть xen/kvm/esxi), то вам нужно купить 5 лицензий. По штуке на каждый физический сервер, где эта виртуальная машина может оказаться.
Из дополнительного безумия — если у вас работает одна виртуальная машина с windows в кластере из, например, 5 серверов (с любым гипервизором, хоть hyper-v, хоть xen/kvm/esxi), то вам нужно купить 5 лицензий. По штуке на каждый физический сервер, где эта виртуальная машина может оказаться.
Согласен, но если хотя бы часть рабочих мест лицензирована с использованием Device CAL и с них могут использовать сетевые принтеры, то принтерам нужны отдельные Device CAL.
Собственно, я хотел лишь заострить внимание на этом аспекте. Другим примером может служить гостевой доступ (Wi-Fi в переговорной комнате), наверное, ещё какие-то варианты использования также потребуют CAL. Про это просто не нужно забывать и в каждом конкретном случае разбираться самостоятельно.
Собственно, я хотел лишь заострить внимание на этом аспекте. Другим примером может служить гостевой доступ (Wi-Fi в переговорной комнате), наверное, ещё какие-то варианты использования также потребуют CAL. Про это просто не нужно забывать и в каждом конкретном случае разбираться самостоятельно.
Рекомендую в оба файловер сервера добавить
auto-partner-down 86400;
иначе, если один выйдет из строя, то у второго останеца только половина пула из пула.
auto-partner-down 86400;
иначе, если один выйдет из строя, то у второго останеца только половина пула из пула.
нигде я не нашел как совместить failover, dhcp-relay и сделать это удобным для синхронизации
Жаль, а ведь это самое главное и интересное.
не описано как коммутаторы шлют запросы на второй dhcp… в dhcp helper указаны оба сервера?
я решил вопрос с конфигами и разными адресами при помощи linux ha-cluster где есть переходящий ip которому и шлют запросы коммутаторы, а так же lsyncd который синхронизирует конфиги по изменению файлов.
Остается после внесения изменений протетстить конфиг и перезапустить оба dhcpd
я решил вопрос с конфигами и разными адресами при помощи linux ha-cluster где есть переходящий ip которому и шлют запросы коммутаторы, а так же lsyncd который синхронизирует конфиги по изменению файлов.
Остается после внесения изменений протетстить конфиг и перезапустить оба dhcpd
Стоят коммутаторы HP — H3C. Там это настраивается как:
Касаемо разных адресов же — вариантов много. Я вот думаю всё про вариант с csync2, с которым тоже имел опыт работы, хотя и ваша схема очень даже ничего. Просто ещё не имел опыта работы с ha-cluster
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-cluster
Всегда расстраивало требование иметь ip адреса в клиентском пуле у коммутаторов что у HP, что Cisco.
как ни странно dlink в этом плане удобнее.
как ни странно dlink в этом плане удобнее.
Насчет IP адресов врать не буду, возможно это заработает и без IP адреса. На этом же устройстве происходит дальнейшая маршрутизация трафика с VLAN, поэтому IP там необходим именно с этой целью.
Так же прошу учесть что это не совсем HP, а скорее H3C, который был перекуплен HP впоследствии. CLI у него и у HP ProCurve (сейчас HP Aruba) различаются очень и очень сильно!
Так же прошу учесть что это не совсем HP, а скорее H3C, который был перекуплен HP впоследствии. CLI у него и у HP ProCurve (сейчас HP Aruba) различаются очень и очень сильно!
Больше тысячи компов с виланами и без DHCP? Предыдущие админы были реально экстремалами.
Во-первых, ISC DHCP поддерживает директиву include, чтобы править каждый раз не dhcpd.conf, а только отдельный файл. Во-вторых, если есть такая необходимость, то нужный файл конфига можно генерировать посредством тривиального Makefile. В моём случае применялись оба подхода.
Этой директивой и пользуюсь активно. Одна проблема — include не умеет смотреть в каталог или искать файлы по маске. В параметре ожидается только уникальное имя файла и победить это я не смог.
Один вариант решения я описал в предпоследнем абзаце в статье, так как мне он на ум пришел уже при написании статьи, Ваш вариант с Makefile и регулярная генерация конфига мне кажутся излишними, так как сегменты добавляются достаточно редко.
Один вариант решения я описал в предпоследнем абзаце в статье, так как мне он на ум пришел уже при написании статьи, Ваш вариант с Makefile и регулярная генерация конфига мне кажутся излишними, так как сегменты добавляются достаточно редко.
А можно вопрос? А зачем файловер?
Запускаем два (можно больше) dhcp серверов с идентичными конфигами и все… Никаких проблем.
Схема работает в провайдерской сети уже более 10 лет…
Запускаем два (можно больше) dhcp серверов с идентичными конфигами и все… Никаких проблем.
Схема работает в провайдерской сети уже более 10 лет…
До первого кривого dhcp client, который не проверит обычным arp запросом занятость адреса.
Проблема в том, что за годы существования без DHCP и без DNS как такового, на предприятии у некоторых сотрудников выработалась любовь к обозначению компов на основании IP. Соответственно, при падении сервера, адреса изменятся, что может вызвать отказы в сети.
Эээээ… Т.е. вы думаете что за 10 с лишним лет работы в сети провайдера на несколько десятков тысяч клиентов я видел не все dhcp клиенты? ;) Это во первых.
А во вторых — ну не проверил он. И? Ну взял он адрес, никого не уведомил о занятии адреса. Следующий проверит ;) Или у нас двое, которые не проверят? У меня динамически выдаются адреса из отдельного блока в каждой подсети, а вообще за клиентом адрес фиксируется. Пока по маку… Так что и тут ничего страшного…
А во вторых — ну не проверил он. И? Ну взял он адрес, никого не уведомил о занятии адреса. Следующий проверит ;) Или у нас двое, которые не проверят? У меня динамически выдаются адреса из отдельного блока в каждой подсети, а вообще за клиентом адрес фиксируется. Пока по маку… Так что и тут ничего страшного…
Я просто на самом деле не могу понять — зачем вообще нужен механизм dhcp failover. Какую задачу он решает?
Я пытался использовать его. А потом просто выкинул из конфига блок с его поддержкой — ничего не изменилось. Адреса выдаются обоими серверам, примерно в соотношении 60% на 40% (первый выдает 60% адресов). При аварии любого из серверов — ничего не меняется, второй так же спокойно держит клиентов…
Я пытался использовать его. А потом просто выкинул из конфига блок с его поддержкой — ничего не изменилось. Адреса выдаются обоими серверам, примерно в соотношении 60% на 40% (первый выдает 60% адресов). При аварии любого из серверов — ничего не меняется, второй так же спокойно держит клиентов…
Поясню свою мысль:
При нормальной работе есть 2 группы клиентов: динамические и динамические с привязкой конкретного IP по MAC-адресу клиента. В этом случае «привязанные» клиенты получают их IP-адреса, а «динамические» клиенты — адреса из пула. Срок резервирования IP увеличен до недели.
В случае отсутствия failover при падении primary сервера «динамические» клиенты получат новые адреса, так как secondary сервер ничего не знает о lease'ах, которые хранятся на упавшем сервере.
В случае failover же primary и secondary обмениваются информацией и lease, соответственно даже «динамические» клиенты получат тот же самый адрес.
Не исключено, что я где-то ошибаюсь, если поправите — буду признателен.
При нормальной работе есть 2 группы клиентов: динамические и динамические с привязкой конкретного IP по MAC-адресу клиента. В этом случае «привязанные» клиенты получают их IP-адреса, а «динамические» клиенты — адреса из пула. Срок резервирования IP увеличен до недели.
В случае отсутствия failover при падении primary сервера «динамические» клиенты получат новые адреса, так как secondary сервер ничего не знает о lease'ах, которые хранятся на упавшем сервере.
В случае failover же primary и secondary обмениваются информацией и lease, соответственно даже «динамические» клиенты получат тот же самый адрес.
Не исключено, что я где-то ошибаюсь, если поправите — буду признателен.
при нормальной работе ести две группы клиентов — с фиксированными адресами (всегда получают по dhcp один и тот же адрес) и временные — получают адрес из небольшого блока и неважно, какой они там получили, лишь бы заработало — всякие смарты, ноуты, новое железо… А после «постановки на баланс» (условно назовем) клиенту выделяется фиксированный адрес и все…
Я не знаю как работает dhcp ralay, но у cisco есть отличная команда helper ip которая решает данную проблему на маршрутизаторе.
Мне одному кажется, что Option 82 здесь лишняя?
ISC DHCP вполне может определить, какой IP выдавать на основании «giaddr», который вставляется релеями. Option 82 нужен, если хочется определять положение DHCP-клиента с точностью до конкретного порта конкретного коммутатора.
ISC DHCP вполне может определить, какой IP выдавать на основании «giaddr», который вставляется релеями. Option 82 нужен, если хочется определять положение DHCP-клиента с точностью до конкретного порта конкретного коммутатора.
Да, но возможна ситуация по подобию вот этого:
Сейчас коллега протестировал Вашу конфигурацию. Всё работает отлично за исключением одной тонкости: диапазон, из которого будет выдаваться IP-адрес клиенту выбирается на основе IP того интерфейса dhcp relay agent'а, на который пришел запрос от клиента первоначально, а не на основе поля в dhcp-пакете.
Если на этом интерфейсе висит несколько адресов из разных VLAN, то область выбирается на основе первичного IP-адреса. Когда первичный IP-адрес выбирался не из нужного диапазона (а в сети есть сегменты со смешанной адресацией 192.168. и 10.), то адрес клиенту в нужную область не раздавался.
Конечно эта ситуация является больше ненормальной и искусственно смоделированной, но в случае, когда диапазон выбирается на основе поля в dhcp option 82, такой ситуации не возникает.
Если на этом интерфейсе висит несколько адресов из разных VLAN
под интерфейсом здесь понимается L3 интерфейс, правильно?
Тогда остальное в предложении звучит странно. И если так и бывает то так делать точно не надо.
Или признайте, что VLAN-ы все таки тут не разные. Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Так вот option82 тут никак не поможет.
Вам кажется что Вы выдали адрес на основе option82
Но судя по приведенному конфигу, все происходит вовсе не так
запрос попадает в subnet, на основе адреса релея (того самого L3 интерфейса)
потом dhcp сервер выбирает адрес из pool
а потом на основе вашей option82 происходит тупая фильтрация — выдавать адрес или нет.
Сам option82 никак не определяет из какого диапазона будет этот адрес. Так что Вы и сами заблудились и других заблудили. Проверьте, попробуйте убрать все ваши классы и условия. Ничего не изменится
Ну а что касается репликации статических лизов, то у меня как раз есть решение.
идея очень простая:
Если статическую запись host{} вынести за subnet{}, то сервер все равно сопоставит host с subnet и аккуратно добьет статический IP адрес соответствующими опциями (маска шлюз DNS NTP итп) из subnet.
А значит всю статику можно вынести в отдельный файл и просто использовать директиву Include.
А уж отдельный файл можно легко реплицировать любыми средствами.
Хотя лично я вместо репликации генерирую его из IPAM. Очень удобно.
Или признайте, что VLAN-ы все таки тут не разные.
Признал — если интересно — посмотрите комменты выше. Но забыл в статье поправить, тут уж простите великодушно.
Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Согласен, но пока нет организационной возможности сразу выделить VLAN на группу клиентов. Поэтому переход плавный — сначала их на новую адресацию, в т.ч. и с разными диапазонами в одном VLAN, а затем уже эту группу клиентов обособлять в отдельный.
Что касается основной части Вашего комментария, попробую проверить на «полигоне» — по результатам скорее всего завтра напишу. Заинтриговали.
тут так же лишние слова про DHCP-relay
релеем выступает коммутатор
DHCP сервер парсит значения, которые relay вставил в пакет, но сам никаким боком релеем не является.
Это даже из приведенной схемы очевидно
релеем выступает коммутатор
DHCP сервер парсит значения, которые relay вставил в пакет, но сам никаким боком релеем не является.
Это даже из приведенной схемы очевидно
1. Есть (был) неофициальный патч для isc-dhcp который добавляет поддержку sub-class, посмотрите, может быть полезно, у меня после его добавления размер конфига уменьшился и метод его генерации упростился.
2. На наге была тема как пилили связку dhcp -> mysql кажется, очень удобно, не нужна генерация конфига и перезапуск dhcp сервера в принципе. Подробнее не расскажу, я реализовать это не успел, поменял работу
2. На наге была тема как пилили связку dhcp -> mysql кажется, очень удобно, не нужна генерация конфига и перезапуск dhcp сервера в принципе. Подробнее не расскажу, я реализовать это не успел, поменял работу
попробуй Puppet+hiera+r10k+git -> isc-dhcp для синхронизации конфигов
у нас кучя систем висит на этом
у нас кучя систем висит на этом
1. Был у меня на предыдущей работе развернут DHCP с «дыркой» в каждый vlan. В итоге сетевые настройки сервера превращались в что-то нечитаемое. И любой перенос этого сервера превращался в очень такую серьезную задачу.
Кроме того, это нереально, если vlan терминируются (маршрутизируются) на разных железках, объединенных через отдельную сеть и через ospf. В случае с relay — всё норм. Эта конфигурация гибче, хоть и естественно сложнее.
2. Не сталкивался с этим софтом в работе, а так как требовалось поднять быстро и надолго, то не стал уходиьт от знакомого.
3. Как средней руки *nix'оид могу сказать, что тут Вы не совсем правы.
Но мне моё решение всё равно нравится, может и статья будет полезна кому-либо.
Кроме того, это нереально, если vlan терминируются (маршрутизируются) на разных железках, объединенных через отдельную сеть и через ospf. В случае с relay — всё норм. Эта конфигурация гибче, хоть и естественно сложнее.
2. Не сталкивался с этим софтом в работе, а так как требовалось поднять быстро и надолго, то не стал уходиьт от знакомого.
3. Как средней руки *nix'оид могу сказать, что тут Вы не совсем правы.
- Момент первый: Если лягут все DC, то большая часть сети и так ляжет, так как вся авторизация идет через домен.
- Второе, на что регулярно указывают мне коллеги, когда я везде проталкиваю *nix, — найти у нас в провинции «виндового админа» всё равно проще пока что, чем человека с опытом администрирования *nix.
- Третье — надежность windows домена проверена просто огромным множеством корпоративных (очень крупных) клиентов, к тому же и инструментов по резервированию этого всего уже придумано достаточно.
- Правда DaemonGloom в том, что дополнительно поднимать 2 сервера, хоть и виртуальных, возможно не совсем целесообразно, хотя конечно isc-dhcp в плане ресурсов системы очень и очень скромен. Со своей стороны могу сказать, что на тот момент я не знал про Windows практически ничего, потому этот вариант не рассматривал
- Операционная система, в т.ч. и серверная — это всего лишь инструмент. Задачи решает ПО, которое «крутится» под конкретной операционкой. Один инструмент лучше для одного, другой — для другого, это ещё и от ситуации во многом зависит, так что огульно писать, что «Венду в топку» не стоит.
Но мне моё решение всё равно нравится, может и статья будет полезна кому-либо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Два DHCP сервера на Centos7 с failover, dhcp-relay и динамическим обновлением зон