Консорциум ISC представил (https://www.isc.org/blogs/kea-1-5/) релиз DHCP-сервера Kea 1.5.0 (http://kea.isc.org), идущего на смену классическому ISC DHCP. Исходные тексты проекта распространяются (https://github.com/isc-projects/kea) под лицензией Mozilla Public License (MPL) 2.0 (https://www.opennet.ru/opennews/art.shtml?num=32726), вместо ранее применяемой для ISC DHCP лицензии ISC License.DHCP-сервер Kea основан на технологиях BIND 10 и построен (https://www.opennet.ru/opennews/art.shtml?num=36235) с использованием модульной архитектуры, подразумевающей разбиение функциональности на разные процессы-обработчики. Продукт включает в себя полнофункциональную реализацию сервера с поддержкой протоколов DHCPv4 и DHCPv6, способную заменить собой ISC DHCP. В Kea встроены средства динамического обновления DNS-зон (Dynamic DNS), поддерживаются механизмы обнаружения серверов, назначения адресов, обновления и переподключения, обслуживания информационных запросов, резервирования адресов для хостов и PXE-загрузки. В реализации DHCPv6 дополнительно предусмотрена возможность делегирования префиксов. Для взаимодействия с внешними приложениями предоставляется специальный API. Возможно обновление конфигурации на лету без перезапуска сервера.
Информация о выделенных адресах и параметрах клиентов может храниться в разных типах хранилищ - в настоящее время предоставляются бэкенды для хранения в файлах CSV, СУБД MySQL, Apache Cassandra и PostgreSQL. Параметры резервирования хостов могут быть заданы в файле конфигурации в формате JSON или в виде таблицы в MySQL. В состав входит инструмент perfdhcp для измерения производительности сервера DHCP и компоненты для сбора статистики. Kea демонстрирует неплохую производительность, например, при использовании бэкеда MySQL сервер может выполнить 1000 присвоений адресов в секунду (около 4000 пакетов в секунду), а при использовании бэкенда memfile производительность достигает 7500 присвоений в секунду.
Ключевые улучшения (https://ftp.isc.org/isc/kea/1.5.0/Kea150ReleaseNotes.txt) в Kea 1.5:
- Добавлена поддержка централизованного управления конфигурацией DHCP-серверов.
Реализация базируется на использовании протокола управления конфигурацией NETCONF (https://en.wikipedia.org/wiki/NETCONF) (RFC-6241 (https://tools.ietf.org/html/rfc6241)) и стрктурированной модели данных YANG (Yet Another Next Generation, RFC-6020 (https://tools.ietf.org/html/rfc6020)). NETCONF предоставляет основанный на XML RPC для установки, изменения и удаления блоков конфигурации, а YANG (https://en.wikipedia.org/wiki/YANG) структурирует информацию о состоянии устройства и используемой конфигурации (можно рассматривать YANG как продолжение развития SNMP MIB).В состав Kea включены готовые модели YANG (https://gitlab.isc.org/isc-projects/kea/tree/master/src/shar... для DHCPv4 и DHCPv6, отражающие типовые элементы конфигурации DHCP-серверов, которые можно использовать в системах централизованного управления, совместно с другим сетевым оборудованием, включая коммутаторы и маршрутизаторы Juniper, Huawei и Cisco. Для хранения БД с конфигурацией Kea задействован движок Sysrepo (https://github.com/sysrepo/sysrepo), оптимизированный для модели данных YANG и предоставляющий дополнительные инструменты для управления настройками (например, можно использовать шаблоны для быстрого развёртывания серверов с типовыми настройками).
Для Kea подготовлен специальный фоновый процесс kea-netconf, который при запуске читает начальную конфигурацию из Sysrepo, а затем отслеживает все изменения и на лету отражает их во внутренней конфигурации Kea (если настройки изменены локально, например, при помощи утилиты sysrepocfg, изменения по аналогии переносятся в БД Sysrepo). Для удалённого управления DHCP-сервером предлагается использовать реализацию сервера и клиента NETCONF от проекта Netopeer2 (https://github.com/CESNET/Netopeer2);
- Добавлена поддержка глобального резервирования хостов. Ранее резервирование хостов могло осуществляться только в привязке к определённым подсетям, что, например, при необходимости привязки к клиенту определённых параметров DHCP требовало создания отдельных настроек резервирования для каждой сети, в которой разрешено работать клиенту. Сейчас для подобных клиентов можно обойтись одной глобальной настройкой;- Добавлены (https://gitlab.isc.org/isc-projects/kea/wikis/designs/conges... средства контроля перегрузки (congestion control). В прошлых версиях все поступающие запросы обрабатывались в порядке их поступления в очереди ограниченного размера. В случае перегрузки возникали заметные задержки, которые приводили к инициированию повторной отправки запросов, забиванию очереди устаревшими запросами и блокированию приёма новых запросов. Для противодействия данному эффекту в Kea 1.5 в дополнение к линейной очереди реализован кольцевой буфер, в случае переполнения которого новые запросы не отбрасываютяся, а вытесняют самые старые. Кольцевой буфер пока предложен в качестве опции и требует явного включения в настройках;
- Улучшены возможности для создания отказоустойчивых конфигураций (High Availability). Реализован новый механизм для синхронизации базы привязок IP-адресов к клиентам, передающий изменения небольшими блоками, вместо полного обновления сведений о всех привязках, что существенно ускоряет синхронизацию больших подсетей;- Предложен (https://gitlab.isc.org/isc-projects/kea/wikis/designs/config... концептуальный прототип бэкенда для хранения конфигурации, который будет доведён до рабочего состояния в следующем выпуске Kea 1.6. Новый тип бэкенда позволит использовать СУБД в качестве источника для получения информации о настройках для DHCP-сервера;
- Добавлена поддержка флага для определения является ли сервер DHCPv4 авторитетным (authoritative) или вторичным, что позволяет организовать совместную работу двух серверов на одном линке;
- В бэкендах для хранения привязок (lease) появилась возможность хранения дополнительного контекста пользователя (user context), который может включать произвольные данные в формате JSON;- Добавлена новая библиотека Class_cmds, предназначенная для отображения, добавления, обновления и удаления классов клиентов, определённых для DHCPv4 и DHCPv6;
- Инфраструктура разработки, подготовки документации и отслеживания ошибок переведена на платформу Gitlab (https://gitlab.isc.org/isc-projects/kea) (ранее использовалась (https://oldkea.isc.org) платформа Trac).
URL: https://www.isc.org/blogs/kea-1-5/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49791
DHCP не нужен, учитывая вычислительную мощность современных коммутаторов они могут просто обеспечить pbr
А если нужен Radius и учет трафика абонентских линий?
Нормальные isp давно это делают по портам, а не вот такой вот порнографией с падающими сессиями и меняющимися айпи, так что юзерье грубо выбивает из всех игорей, чятиков и требует залогиниться заново на дюжине сайтов.
dia + ip source guard
> dia + ip source guardПросто нормальные isp не выделывались и таки купили себе managed свичи с isp'шными фичами, где они таки могут рулить портами внешней автоматизацией. И если юзерь не заплатил - ему порт и тушится. И ничего юзерь с этим не сделает, соответственно. Зато это просто роутинг, просто эзернет, работает быстро, безглючно, айпишники не скачут, сессии не рвутся, да и толпы серверов и проблем с ними нет. Биллинг просто иногда раздает слонов неплательщикам, в фоне. Ну и включает заплативших обратно.
А если какие-то удила до сих пор не выкинули свои офисные свичи - слать такого прова надо, в пешее эротическое. Потому что это жлобье работать не умеет.
Нормальные ISP порт не тушат, нормальные ISP либо меняют VLAN, либо делают уровнем выше REDIRECT, чтобы юзер-таки смог хотя бы оплатить, с дивана не вставая.
что не отменяет необходимости в dhcp, поскольку юзеру надо не вставая с дивана автонастроить свой роутер.
Но, в принципе, о них уже позаботились, без всяких кривых поделок от isc.
Есть TR-069 и роутеры, его понимающие. Там можно и телефонию заодно сконфигурить.
Ещё есть GPON, в котором тоже своя автоконфигурация.
Нормалные дают беспроцентный кредит на пару дней, чтоб абонент смог оплатить через банк.
Через DHCP IPv6 давать клиентам ISP удобнее с технической точки зрения.А pbr тут вообще из другой оперы.
А, типа, если вы автоконфигурацией назначили - то вы не знаете какой айпи вы с вашего роутера выдали, чтоли? Юмористы :). DHCP как таковой - лишний источник отказов почем зря. Ну и просто костыль в случае ipv6.
Автоконфигурацией с EUI-64? Несекурно.
Теперь осталось найти клиентов, понимающих, чего такое IPv6, и не спрашивающих, "а почему оно так херово работает".
Сказать клиенту, хочешь хорошо - плати за белый IPv4.
а клиент ответит что "хочешь хоть каких-то денег - переставай выделываться".whois -r 77.79.128.0
(и рядом понабирай, если понимаешь, что это все значит)УФА, блжад, городишко в опе мира, где интернетом пользуются исключительно ручные гадилки в веб-форумы и комменты, за тридцать пять копеек килобайт (потому что жрать в этой уфе, видимо, нечего совсем и вообще - а вот интернет очень дешевый, тридцать копеек вполне хватает, и еще пять остается на хлебушек).
Это ты так радостно про свою дырявую АНБ'шную цыску?
> DHCP-сервер Kea основан на технологиях BIND 10Уносите. Вместе с BIND 10, эталоном энтерпрайзного монструоза.
какой, нахрен, энтерпрайз? Энтерпрайз давно на божественной 2016.
В которой, поверь, все просто божественно по сравнению с isc'шыми убожищами. Которое вон пришлось переписать с нуля на новых модных технологиях, потому что научить старый isc dhcpd перечитывать собственный конфиг без перезапуска - эти выпускники школы умственно-отсталых за три десятка лет нишмагли.
А глядя на их новые достижения, понимаешь, что лучше б оно и дальше только конфиг перечитать не умело...
А не энтерпрайз?
а о неэнтер-прайсе позаботились че...э,все-таки, чехи, со своим нот-днс и, вон, Ivan_сколькоеготам со своей перлоподелкой для тех, кому нужно в радиус и прочей провайдерской ерунды с сотнями лиз в секунду "патамушта свитч в многоэтажке перезагрузился".В совсем простых конфигурациях хватит совсем простых поделок или краденой винды.
> какой, нахрен, энтерпрайз?Обычный. Архитектуру BIND10 посмотри.
> Энтерпрайз давно на божественной 2016.
Кто-то таки упрлс и поставил ее на корневой DNS? И чо, даже работало? :)
> В которой, поверь, все просто божественно по сравнению с isc'шыми убожищами.
Мне 2008 и восьмеры более чем хватило чтобы навсегда развидеть маздай. И теперь мой род деятельности никак не связан с маздаем, более того - отсутствие моей нужды иметь дело с маздаем для меня mandatory требование при выборе себе проектов и задач.
И они так все круто переписали что теперь оно реально напоминает винду. Только еще пополам с пихтонрастом. Впрочем в винде эту роль успешно подхватил дотнет - так что eventvwr в виртуалке стартует столько что на горе раньше свистнет рак. Да и powershell столько же. Если там что и есть божественного - то тормозняки.
> А глядя на их новые достижения, понимаешь, что лучше б оно и дальше только конфиг перечитать не умело...
Дык если кто историю забыл, BIND10 прославился тем что такая энтерпрайзятина оказалась мало кому вообще нужна. Ну может каким-то нескольким корневым сервакам что-то такое и уместно. Остальные от него сбежали как черт от ладана. Похоже ISC выводов не сделал.
Честно - DNS-сервер в божественной 2016 гораздо лучше того, во что превратился BIND 10...
ну так хуже-то надо ж было постараться. Индус, конечно, старается, но пока этих переплюнуть ему не удалось.я бы, честно говоря-то, и девятый не назвал верхом совершенства, но его еще хоть как-то можно было терпеть в простых конфигурациях. Новое bloatware для простых ненужное ненужно, а для сложных ну его вообще такое нафиг.
P.S. это все, если что - про dns. kea отдельная матерная песня.
>какой, нахрен, энтерпрайз? Энтерпрайз давно на божественной 2016.
>В которой, поверь, все просто божественно по сравнению с isc'шыми убожищами.Молодец, хорошо отрабатываешь свою з/п менеджера по продажам Сиськи.
> Энтерпрайз давно на божественной 2016.Это которая в DNSSEC по-нормальному не умеет? Ну да, ну да.
А зачем в это ненужно уметь? И так понятно, что не взлетело.
А есть что-то толковое на данный момент не под виндой?
Надо иметь в виду, что упомянутый перловый сервер работает только через релеи. Для охфисной локалки это реальное применение микроскопа как молотка.
> Надо иметь в виду, что упомянутый перловый сервер работает только через релеи.да, это фича, в общем-то понятная и правильная для этой конструкции. Но документацию придется прочитать значительно дальше первого абзаца, где об этом явно предупредили.
> Для охфисной локалки это реальное применение микроскопа как молотка.
рассказывать это на собеседовании в нашем охвисе не советую - не возьмут даже младшим падаваном.
Потому что офис это не только твой подвал с тремя табуретками, в котором ты рискуешь так и доработать либо до пенсии, либо до прорыва трубы с кипятком, второе, учти, куда вероятней, а и вот это восьмиэтажное зданьишко где я сижу. И еще пяток по default-city. Вполне себе тут есть место релеям.Но dhcp раздает таки винда, и в серверных сегментах тоже. Потому что так удобнее, ага.
> Потому что офис это не только твой подвал с тремя табуретками, в котором
> ты рискуешь так и доработать либо до пенсии, либо до прорыва трубы с
> кипятком, второе, учти, куда вероятней, а и вот это восьмиэтажное
> зданьишко где я сижу. И еще пяток по default-city. Вполне себе тут есть место релеям.Всегда весело, когда охфисные одмины рассказывают про невмертущую круть объединения пяти охфисоф и чтобы все на релеях... Хотя... Для кого-то это может и вправду хайтех и прорыв. Операторы локалнетов это все уже прошли, разжевали и зафиксировали в копролитах-руководствах пятнадцать лет назад.
> Всегда весело, когда охфисные одмины рассказывают про невмертущую круть объединения пятиэто не я рассказываю про круть, это офисно-подвальный тут вещает что релеи для офиса это космические технологии и гвозди микроскопом.
> и вправду хайтех и прорыв. Операторы локалнетов это все уже прошли,
офисная жизнь немножко отличается от локалнетов пятнадцатилетней давности, да.
из дерьма и палок стараются не работать, как минимум.Но релеинг dhcp настроить вполне можно и там и там.
> офисная жизнь немножко отличается от локалнетов пятнадцатилетней давности, да.
> из дерьма и палок стараются не работать, как минимум.Верно говоришь, птица-говорун. Кто-то развивается, а охфисный ынтерпрайз как гнил по каморкам, так и продолжает гнить.
Идущему на смену... - бугага.Не трогать dhcpcd!
Сетевиков здесь я гляжу как юзеров нерезанных... CCNA есть? ;-)
> Сетевиков здесь я гляжу как юзеров нерезанных... CCNA есть? ;-)был один, но что-то в этой новости не отметился.
В принципе, ccna редко настраивают dhcp - это забота админов, а не сетевых падаванов, у тех и ресурсов-то нет.Варианты "на пятнадцать юзеров на той же кошке" не в счет.
> Сетевиков здесь я гляжу как юзеров нерезанных... CCNA есть? ;-)Есть подозрение, что в основном OCBA (Opennet Certified Balabol Associate) ;-)
99% пишущих здесь такие. Как коменты почитаешь, все такие умные, главное всё обгадить.