Патчкорд

Junos маршрутизатор собственными руками? Не вопрос! Теперь вы можете собрать его используя cRPD и LinuxKit "На момент написания этой статьи бесплатная пробная версия для cRPD отсутствует" - пишет автор статьи. "Но когда это нас останавливало?"- скорее всего подумали вы. "Тем не менее, многие из Juniper работают над тем, чтобы cRPD стал доступнее."- ответит вам автор. Что такое сRPD? cRPD берет некоторые из лучших частей Junos (RPD, MGD), дезагрегирует и упаковывает их в легкий образ контейнера. Что такое LinuxKit? Linuxkit - это "набор инструментов для сборки настраиваемых минимальных, постоянных дистрибутивов Linux". Он позволяет вам собрать свой собственный легковесный дистрибутив Linux, используя контейнеры. Пойду приготовлю себе маршрутизатор! - 🔥 Меня это не остановит! -💪 Не, не надо! - 😏 Хотите обсудить? Айда в чат - https://t.me/automate_devnet #juniper #crdp #linuxkit

Мне очень нравится организация файла конфигурации у 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 на заметку.

Сделал себе DoH сервер, на всякий случай, а потом подумал, почему только себе и решил поделиться с вами https://host-correct.ru/doh, чем мы хуже Cloudflare :) Побочным эффектом запилил munin плагин для Knot Resolver (переделал из Unbound плагина). Быстро не нашёл готового, поэтому немного поразмял мозги. Не уверен что сервер вытащит больше даже 100 запросов в секунду, поэтому надеяться на него не стоит, для надёжности и безопасности лучше свой поднимать. Логи я отключил, оставил только статистику запросов, конфигурация элементарная, места под кеш практически нет, но пользоваться можно.

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

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

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

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

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

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

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

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

Есть у Juniper добротный проект Day One+. Это на случай если ты всю жизнь примусы починял, но вдруг тебе неожиданно понадобилось стать сетевиком, а ты езернета в руках не держал. Ну то есть это просто набор пошаговых инструкций для совсем зелёных новичков, где расписано и как в стойку железку поставить, и как основные вещи настроить и куда бежать за документацией на все случаи жизни. Молодцы, одним словом. А у других вендоров есть нечто подобное? https://www.juniper.net/documentation/dayoneplus/en_US/day-one-plus

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

Интересно наблюдать за тем как меняется баланс от: "Используем протоколы и формализованное взаимодействие между частями системы на готовых реализациях, изменяя лишь дозволенные настройки" - условно, "админский" подход. В сторону "программного" подхода: "Формализуем только данные и их форматы и делаем с ними что хотим". На одном конце - я знаю какие параметры задать чтобы было так и вот так. Даже если некоторое поведение не реализовано полностью предлагаемым решением, этого иногда можно добиться комбинацией параметров, порой, совершенно не предусмотренным образом. Не обязательно чтобы с параметрами по умолчанию вообще что-то заработает, но часто работает. В проблематике сетей у нас есть протоколы взаимодействия устройств и набор того что мы можем менять оставаясь в заданных рамках. Есть задача, её решение выливается в статическую конфигурацию, а поведение определяется протоколом на основе этой конфигурации. На мой взгляд, красивая ассоциация с баллистикой: задаём параметры, стреляем и наблюдаем за тем попали в цель или нет. Чтобы изменить поведение, опять меняем начальные параметры и стреляем, на фазе полёта у нас отсутствует возможность активно вмешаться в процесс. На другом конце - я знаю о чём знает или хочет мне сказать соседняя система, я знаю какой результат хочу получить и на основе этого программирую своё поведение. Это уровень самостоятельной реализации системы в терминах действия, а не в терминах описания. Вспомним про SDN - сеть без классических протоколов взаимодействия, в которой напрямую программируется поведение устройства для каждого принятого кадра, а ещё язык P4. Многие серверные инструменты поддерживают возможность, наравне с определением параметров поведения протоколов, задавать скриптовую обработку, определять поведение непосредственно. Причём выбор того или иного варианта использования часто равнозначны, можно написать перловый скрипт для FreeRADIUS, а можно то же сделать с помощью настроек. Всё зависит что полезно в конкретном контексте: гибкость, уникальность, переносимость, унификация, удобство поддержки. Производительность CPU современных сетевых устройств давно доросла до возможности использовать универсальные языки и программные подходы для решения специфических сетевых задач, налету. В то же время, универсальные платформы доросли до производительности передачи трафика специализированных сетевых устройств. Итого в современности, мы можем используя Python получить BGP Flowspec от соседа и сформировать нужные ACL самостоятельно, даже если такая возможность не реализована на данном устройстве. Это видео с коротким описанием проблематики и подхода, кусками использованного кода и настроек, так что финальное решение всё равно придётся писать самостоятельно, главное что это можно сделать. Сейчас маятник качнулся в сторону программного подхода во всём, ждём нового витка спирали, когда выработанные алгоритмические решения закрепятся и сформируют новый стек протоколов, что позволит параметрически задавать поведения не вдаваясь в детали реализации.

sudo для Windows, привыкшим к Linux админам должно пригодиться. Можно скачать бинарники или воспользоваться скриптом установки, только надо в него заглянуть и поправить каталог назначения. З.Ы. Пока вспомнил. Как правило я ставлю и использую (как минимум пытаюсь) все инструменты которые упоминаю, некоторые приживаются - за полтора года с PopCom могу только похвалить, реально удобно.

*BSD ламповая система, там даже у root есть настоящее имя. А ещё написано про то зачем используется амперсанд в конце поля полного имени.

50 MIOPS, 1,6 Тбайт в секунду, до 10Пбайт в одной стойке. Новая хранилка ClusterStor E1000 от Cray - можно заказывать.

​Как в Google (облачные сервисы) формируют метрики доступности, обзорная статья по работе представленной на симпозиуме NSDI'20. Цель работы показать как формировать и использовать такие метрики которые были бы: - значимыми, отражали реальное поведение пользователя; - пропорциональными, адекватно выражали изменения опять же с точки зрения пользователя; - применимыми, позволяли владельцу системы понимать почему доступность в это время снижалась. Можно сказать что у них получилось создать новую метрику user-uptime. Вот такого графика как на картинке мне точно не хватает. В работе (не в статье) приводится много формул и примеров метрики на реальных данных, чего вполне должно хватить чтобы перенять опыт Google. Конференция ещё не закончилась и не все докладчики выступили, но всё уже доступно для чтения, должно быть много интересного.

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