Интересно наблюдать за тем как меняется баланс от: "Используем протоколы и формализованное взаимодействие между частями системы на готовых реализациях, изменяя лишь дозволенные настройки" - условно, "админский" подход. В сторону "программного" подхода: "Формализуем только данные и их форматы и делаем с ними что хотим".

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

На другом конце - я знаю о чём знает или хочет мне сказать соседняя система, я знаю какой результат хочу получить и на основе этого программирую своё поведение. Это уровень самостоятельной реализации системы в терминах действия, а не в терминах описания. Вспомним про SDN - сеть без классических протоколов взаимодействия, в которой напрямую программируется поведение устройства для каждого принятого кадра, а ещё язык P4.

Многие серверные инструменты поддерживают возможность, наравне с определением параметров поведения протоколов, задавать скриптовую обработку, определять поведение непосредственно. Причём выбор того или иного варианта использования часто равнозначны, можно написать перловый скрипт для FreeRADIUS, а можно то же сделать с помощью настроек. Всё зависит что полезно в конкретном контексте: гибкость, уникальность, переносимость, унификация, удобство поддержки.

Производительность CPU современных сетевых устройств давно доросла до возможности использовать универсальные языки и программные подходы для решения специфических сетевых задач, налету. В то же время, универсальные платформы доросли до производительности передачи трафика специализированных сетевых устройств. Итого в современности, мы можем используя Python получить BGP Flowspec от соседа и сформировать нужные ACL самостоятельно, даже если такая возможность не реализована на данном устройстве. Это видео с коротким описанием проблематики и подхода, кусками использованного кода и настроек, так что финальное решение всё равно придётся писать самостоятельно, главное что это можно сделать.

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

В любой непонятной ситуации смотри дамп трафика - девиз настоящего сетевика. Наверное, стоило посмотреть логи LDAP клиента, но если проблема решена всё сделано правильно. Самый короткий путь тот который знаешь.

Есть у Juniper добротный проект Day One+. Это на случай если ты всю жизнь примусы починял, но вдруг тебе неожиданно понадобилось стать сетевиком, а ты езернета в руках не держал.
Ну то есть это просто набор пошаговых инструкций для совсем зелёных новичков, где расписано и как в стойку железку поставить, и как основные вещи настроить и куда бежать за документацией на все случаи жизни.
Молодцы, одним словом.

А у других вендоров есть нечто подобное?

https://www.juniper.net/documentation/dayoneplus/en_US/day-one-plus

​Marek Majkowski из CloudFlare ускоряет выборку уникальных значений из большого (очень большого списка) с 2 мин до 12 секунд, а потом ещё в два раза до 7 секунд. Делает он это путём реализации новой утилиты, код которой можно найти на GitHub. В статье немного математических терминов, про фильтр Блума надо будет почитать где-нибудь в другом месте, и много профилирования кода, а ещё про кеш и современные процессоры.

Но в итоге, всё уже было придумано и реализовано в привычных всем инструментах, скорость работы которых улучшалась в статье. Надо только правильно попросить. Конечно, и тут играют роль современные процессоры и более конкретная постановка задачи, чтобы переключить универсальные утилиты, подходящие большинству для большинства задач, в правильное русло.

Подробнейшее разъяснение на тему статических маршрутов у Juniper. Диаграммы, конфигурация, описание - всё присутствует. Не совсем для новичков, но тут официальная документация более чем удобная, по сравнению с многими.

В ядро Linux хотят добавить расширенную поддержку для работы с заголовками IPv6, в частности, упросить добавление новых опций в заголовки расширений. По стандарту они уже могут там быть в TLV, что наверное максимально гибко, но в ядре не было соответствующего стандартизированного механизма.

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

Про базовые подходы проектирования маршрутизации в опорной сети, в данном случае, для интернет провайдера с радиодоступом, что никак не отражается в смысле статьи. В основном про выбор способов управления трафиком и глубину этого способа - от коммутируемой сети и дальше, плюсы и минусы каждого подхода, без особых подробностей всё на понятийном уровне. Про всякие SD* и SR* не упомянули. Где-то за сценой видны ушки Микротика, но статья не про это.
При том что вендор, несомненно, влияет на расстановку акцентов в подаче материала. Читаешь, например, Cisco MPLS где всё начинается с LDP, а дальше всё остальное. А читаешь Juniper MPLS, а там LDP называют не очень полезным протоколом и вообще речь про него заходит только после того как две главы про RSVP-TE подробнейшим образом расписали. Вот и как тут выбор сделать, тем более правильный.

Ещё один клиент для многих утилит сканирования сети - GoScan. Интерактивный интерфейс, готовый набор команд, база данных с результатами работы. Работает в Linux и для Docker всё готово, куда теперь без него.
Может мне кажется, но в последнее время в поле зрения попадает много обёрток над проверенными годами инструментами, а новых оригинальных инструментов которые на слуху, не видно?

С приходом универсальных инструментов на специализированные устройства происходят интересные казусы. Например, SSH пытается разрешить обратное имя по IP и у него обычно это получается, так как DNS обычно настроен на серверах, чего нельзя сказать про коммутаторы. Поэтому либо настраиваем, либо отключаем: UseDNS no в sshd_config. Похожая, но другая классическая проблема у Cisco, решается по другому.

Самый, наверное, противный момент с DNS, что когда надо действовать быстро, что требуется во время аварии, а DNS недоступен вследствие той самой аварии, то теряются драгоценные секунды если разрешение имён не выключено, хотя в остальное время он очень даже полезен.

Большая статья про URL и историю современного Интернета в блоге CloudFlare. Много общеизвестных вещей, много отступлений не совсем по делу, но интересные детали тоже присутствуют. Повествование построено на разборе составных частей URL, для каждой из которой дано описание и какие-то исторические сведения. По сегодняшним меркам, из-за объёма, не тянет на лёгкое чтение, но в итоге получился такой исторический ликбез, без погружения, то что, предполагается, должны знать все.

​Прямо ухх статья, про Unix-way и вообще философию CLI, что мы потеряли или не потеряли за всё прошедшее время. Классический подход, одна утилита - одна функция, отсюда есть отдельно cat и tac. При этом количество аргументов стандартных утилит выросло иногда в разы. Плохо это или хорошо? Чем отличается в сложности построить конвейер из 10 элементов или применить 10 опций у одной утилиты? Автор достаточно критично проходится по "старой школе", что наверное не плохо, нельзя держаться за реалии 50 летней давности.

С другой стороны, очевидный минус который я вижу это наименование опций командной строки для разных утилит, когда "-L" всякий раз значит что-то разное. Не всегда, но полагаться на то что опции одинаковые для разных инструментов не стоит. И тут разница, запомнить 10 утилит с 5 опциями в каждой, или 5 со 100. Может быть вообще можно обойтись и одной утилитой, но чего не отнять - сложность увеличилась. Наличие конвейера всё же заставляло поставлять более менее стандартизированный поток вывода, иначе не заработает.

Но тут опять стоит согласиться с автором, мало кто запоминает ВСЕ опции. Наличие возможности быстро найти то что нужно нивелирует многие спорные моменты. Да и совместимость никуда не делась, можно писать в old school стиле и всё будет работать.

Сделал себе DoH сервер, на всякий случай, а потом подумал, почему только себе и решил поделиться с вами https://host-correct.ru/doh, чем мы хуже Cloudflare :)

Побочным эффектом запилил munin плагин для Knot Resolver (переделал из Unbound плагина). Быстро не нашёл готового, поэтому немного поразмял мозги.

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

Мне очень нравится организация файла конфигурации у Juniper: строгая, иерархическая и структурированная. Правда, как оказалось, после того как у нас появился Juniper, самый не очевидный момент для моих коллег это включение интерфейса из состояния disable. Вот такая конструкция delete interfaces xe-0/0/0 disable, вызывает минимум удивление, а максимум эмоций я описывать не стану. При этом Juniper самый логичный из всех - установить настройку всегда set, убрать настройку всегда delete.

В Нuawei используется undo, чтобы убрать настройку, но там в целом подход больше похожий на Cisco CLI - undo shutdown, включит интерфейс.

У Brocade в контексте интерфейса можно написать как no disable, так и просто enable. Где-то не далеко D-Link у которого есть пара enable/disable для сервисов и конструкция conf ... state disable/enable для интерфейсов.

А вот больше всего удивления от delete interfaces xe-0/0/0 disable. Что-то в этом delete не то для нашего брата админа, ассоциации вызывает другие, может слишком знакомое слово, Juniper на заметку.

Junos маршрутизатор собственными руками? Не вопрос!
Теперь вы можете собрать его используя cRPD и LinuxKit
"На момент написания этой статьи бесплатная пробная версия для cRPD отсутствует" - пишет автор статьи. "Но когда это нас останавливало?"- скорее всего подумали вы.
"Тем не менее, многие из Juniper работают над тем, чтобы cRPD стал доступнее."- ответит вам автор.

Что такое сRPD?
cRPD берет некоторые из лучших частей Junos (RPD, MGD), дезагрегирует и упаковывает их в легкий образ контейнера.

Что такое LinuxKit?
Linuxkit - это "набор инструментов для сборки настраиваемых минимальных, постоянных дистрибутивов Linux".
Он позволяет вам собрать свой собственный легковесный дистрибутив Linux, используя контейнеры.

Пойду приготовлю себе маршрутизатор! - 🔥
Меня это не остановит! -💪
Не, не надо! - 😏

Хотите обсудить? Айда в чат - https://t.iss.one/automate_devnet

#juniper #crdp #linuxkit

Иногда поздний старт даёт колоссальные преимущества. Основная рабочая лошадка в США для скоростного интернета это кабельные операторы, которые кабельное телевидение, и соответственно DOCSIS как способ доступа. Телеком операторы (бывшие телефонные компании) в догоняющих, скорее в отстающих, потому что из коаксиального кабеля выжать получается больше. В DOCSIS 3.1 добрались до гигабитных скоростей, xDSL сильно проигрывает.

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

Итого, инфраструктура вплоть до симметричного гигабит канала до конечного абонента у нас была построена уже лет 10-15 как. И как минимум один переход с обычного Ethernet до Fast Ethernet операторы уже пережили и многим это обошлось только в смену оборудования, не кабельной инфраструктуры (если изначально не сильно экономили), замена которой обходится дороже всего. Сейчас вялотекущий переход от Fast Ethernet к Gigabit Ethernet, найти парочку операторов с тарифами больше 100Мбит/c не проблема.

Почему у нас так, потому что у нас не было ничего, а тем у кого было строить заново очень сложно, вот коаксиал и дотянул до последнего. Но переход на 10Гбит/с легко не дастся никому. И тут мы уже можем оказаться в отстающих и использовать свою кабельную инфраструктуру до последнего, вместо того чтобы строить новую.

На этой неделе ко мне подошёл коллега, кого я обманываю, конечно, написал в чате, и говорит: "Хочу IPv6 себе домой, можно?". В такой безвыходной ситуации я ответил что можно, вот у нас туннель настраивай и подключайся, всё работает последние много лет. Но он оказался настойчивый, от туннеля отказался и потребовал себе всё нативно.

И это странно. Простому абоненту в домашних условиях не нужен IPv6. Точнее ему всё равно что там с той стороны экрана - картинки открываются, музыка играет, вот основная цель. И своё мнение я не изменил за прошедшие 6 лет. В первую очередь это надо провайдеру, по многим причинам, и как продать это абоненту, или директору, или инвестору уже его проблемы. Иногда бывает, что в IPv4 не работает и случается повышение интереса именно к IPv6 - с 0 до 10 в год ;). Но обычно в IPv4 всё быстро чинится, или в IPv6 быстро становится нерабочим. В наших реалиях это когда РКН что-то блокирует, хотя бывает и по-другому.

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

Наш проект законсервирован и уже давно, но многие другие работают и делятся опытом - видео с IETF104 2019 год и презентация в PDF:

1. Deutsche Telekom. Простая сеть без туннелей и PPPoE. "Модные" IPoE и даже термин такой звучит. IPv6 only опорная сеть.
2. DHCP Relay и PD. Описаны типичные проблемы, у нас такие же были при внедрении.
3. Несколько разных /56 абоненту в CPE, чтобы дифференцировать услуги, их провижининг. А вот это чуть необычно и вызвало вопросы в зале, в том числе. Но каждый строит так как ему удобнее, значит так было надо.
4. Про MTU, куда без этого.

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

SETI приостанавливает свою работу, новость начала марта, но стоит того чтобы к ней вернуться. 20 лет работы, невероятная цель и возможность участвовать каждому желающему. Всегда, где-то на границе моего сознания и памяти было ощущение грандиозности проекта, я не помню когда я о нём услышал, но точно не позже 3 или 4 года существования и даже поучаствовал чуть-чуть. Я знал что SETI работает, а значит есть кто-то, кто верит в мечту и ты можешь верить вместе с ними. И почему-то казалось, что это есть и будет всегда, ведь мечту нельзя остановить. Наверное, сейчас другие мечты - пишут что все данные посчитаны, надо провести анализ и написать статьи, а есть ли внеземной разум или нет, науке про это неизвестно.

​Вряд ли те кто использует Routinator 3000 никак его не мониторили, но вот тут официальный дашборд для Grafana выложили. Так что можно использовать, сначала поставить Routinator, конечно, если ещё не поставили. Его использовать важнее - от проверки RPKI уже никуда не уйти.

Статья про то, что DHCPv6 не нужен (стащил ссылку у linkmeup). И в Google так считают.

В основном, написано про то как собирать и отслеживать уже существующую информацию, про Radius accounting, логирование, про безопасность и авторизацию, которая реализуется NAC. Что правильно, но как эти данные назначить и передать хосту? За пределами назначения DNS полномочия IPv6 SLAAC кончаются, да даже DNS является дискуссионной опцией.

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

Конечно, для этого есть AD или TR-069, или если уж на то пошло SD-* решения. Поэтому, ни капли не защищая DHCP - он не обеспечит ни безопасность. ни контроль состояний, ни гарантию применения параметров - не используйте его в этих целях. Но, DHCP рабочее решение прямо сейчас, которое поддерживается подавляющим большинством устройств и позволяет как минимум попытаться определить границы и передать те начальные значения в которых устройство должно работать. А уже потом можно включиться и взрослым ребятам с аккаунтингом и мониторингом и автоматизацией и авторизацией по сертификатам, чтобы контролировать эти границы, которые для начала должны быть обозначены. И пускать этот процесс на самотёк так себе идея.

Другой вариант как передать адрес сервера начальной настройки или другого сервиса без DHCP - DNS и сказать что это лучше, никак нельзя. Сколько уже разных вариантов service discovery туда прикрутили и сколько из них хотя бы минимально совместимы между собой? DNS ещё более резиновый.
Или, размазать выдачу адресов конечным хостам на сотни разных сетевых устройств, для каждого из которых придётся менять настройки, вместо централизованного управления DHCP. Это не проблема в эпоху тотальной автоматизации можно управлять и 10 000 устройствами одновременно, но всё сразу ломается когда это будет хотя бы 100 разных версий одного вендора, не говоря о 100 разных вендорах - типичная ситуация с абонентскими подключениями в провайдере, где каждый абонент сам по себе.

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

Бесплатный доступ к онлайн-курсам вузов России

Министерство науки и высшего образования (Минобрнауки) подготовило перечень бесплатных онлайн-курсов от основных российских вузов. Перечень включает свыше 600 курсов от МГУ, СПбПУ, МИСиС, УрФУ и других университетов и институтов.

https://minobrnauki.gov.ru/ru/press-center/card/?id_4=2473

Список курсов - https://minobrnauki.gov.ru/common/upload/library/2020/03/Spisok_onlayn-kursov_20200316-03.pdf