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

Использование BGP LLGR из опубликованного недавно RFC9494. Хочется назвать это костылём и очередной тонкой подстройкой за другой тонкой подстройкой, но пожалуй не буду, выглядит полезно для некоторых случаев когда сетевая связность остаётся, а BGP перестаёт работать. Запоминаем два новых well-known BGP community: 65535:6 LLGR_STALE и 65535:7 NO_LLGR.

Если прикрутить Pytest к Batfish то может получиться очень даже не плохо, но сначала надо конечно озаботится и сделать снимок своей сети в Batfish. А после этого всё просто: делаем изменения, прогоняем тесты, в случае успешности выкатываем на прод, скрещиваем пальцы и смотрим ко скольким железкам придётся ехать восстанавливать доступ.

Как быть хорошим пиринговым партнёром: будьте открытым, не забывайте про защиту RPKI/ROV и антиспуфинг, обеспечьте сервис. Вещи о которых говорят давно и много, но если говорят, значит всё не так радужно. Главный момент и в нём же ответ - взаимодействие.

Энтузиасты открыли ASCII-кинотеатр!

Все фильмы показывают в ASCII-арте. Чтобы посмотреть, надо набрать в терминале:

ssh -o StrictHostKeyChecking=no watch.ascii.theater

Каждый день новый фильм. Я зашел, сейчас показывают “Гражданин Кейн” . На мой взгляд, немного мрачновато (см скрин). Ну и нарушать американские авторские права с помощью американского стандартного кода обмена информацией (ASCII) – это особенный цинизм. Хотя, может в этом вся задумка авторов (тоже американцев).

Лучший сервис - сервис незаметный, по большому счёту я так могу сказать про своего домашнего провайдера, отсутствие проблем и возможность всем нужным управлять из личного кабинета (хотя его организация с каждым годом становится всё хуже и хуже) - это всё что нужно, лично мне. Я даже плачу раз в год по специальной опции, которая помимо того что приносит скидку, дополнительно страхует от поднятия цены на тариф за этот самый год.

Но в этом году ДОМ.RU решил сделать что-то странное, на мой взгляд, и упразднил все тарифы со скоростями меньше 100Мбит/c, я не знаю точную дату, когда-то в 2023. При том минимальный тариф 200Мбит/c, а 100Мбит/c по той же цене! что и 200 можно подключить только через общение с ТП и зачем он тогда? Мало того что тарифная линейка только такая, цены на все старые тарифы выросли выше, а порой и гораздо выше текущих, что говорит о целенаправленном выдавливании абонентов в сторону новых скоростных тарифов.
Казалось бы, если такое решение принято, то инфраструктура к этому должна быть готова, но ведь нет, столкнувшись дважды (что конечно мало значимо, но всё же) с ситуацией смены тарифа за последнюю неделю в обоих случаях пришлось менять кабель и в обоих случаях коммутатор куда подключали новый кабель был не гигабитный, выискивали свободные гигабитные порты из тех немногих что там были. Вся остальная масса подключений до сих пор оставалась на 100Мбит/c портах.

Моя стратегия домашнего Интернет подключения - минимум цены, он мне не нужен для работы, для игрушек, для стриминга. Качество это не только скорость и не столько скорость и любой провайдер имеет одинаковое качество обслуживания на дешёвых и дорогих тарифах, плохой - плохое, хороший - хорошее, разница только в скорости, а мне она не нужна. Но теперь у меня 200Мбит/c и это самое дешёвое в предлагаемой мне провайдером линейке.
Я теряюсь, чтобы объяснить хитрый план который преследовался оператором, не оставившим ни одного 100Мбит/c тарифа. Возможно, это действительно выделяет как-то провайдера на фоне других: "Минимальная скорость 200Мбит/c!", возможно это желание заработать на продажах роутеров и стоимости переключения на гигабитный кабель, которая составляет 100 рублей, может быть чисто техническая проблема для чего абонентам обязательно надо гигабитное окончание. В чём я точно уверен это сгенерирует массу визитов монтажников к абонентам, на мой взгляд совсем не нужных, для которых как и мне 50Мбит/c Интернета более чем достаточно.
Но мне этого не видно, а то что действительно видно это то что монтажники по прежнему абсолютно уверенные в себе люди, которые флюком и обжимкой решают любые проблемы, даже несуществующие.

Novell Netware - рулит:

"For its part, ICBC has told users that its US division is back online and operational, the people said. One person familiar with the hack and investigation said a reason the bank could get back online quickly was that a key part of its trading system was unaffected by the attack — a server that was more than 20 years old, made by now-defunct IT equipment maker Novell Inc.. That server contained much of the bank’s trading data and capabilities and is so old that LockBit’s ransomware didn’t work on it, the person said."

Но статья не про это, для банка кстати не удивительно, да и вообще для корпоратов, наличие систем с 20+ стажем работы.

ICANN пытается разбираться в сортах нежелательной почты (в pdf). Наверное не новость для тех кто давно занимается почтой, но основная масса нежелательной почты летит по весьма предсказуемым адресам, например <название города>@домен, или <должность>@домен, или, наверное особенность зоны .RU, на транслит sekretar, zakaz, pochta. Не используйте их или сразу заблокируйте если принимаете почту на любые адреса, и тогда SpamAssassin будет попроще.

Вспоминаем, что для локальных IPv6 адресов есть рекомендации к их образованию по RFC4193, которые как и многие другие вещи в RFC, особенно не влияющие напрямую, мало кто применяет. Но если применяете, то вот вам ещё один генератор - unique-local-ipv6.com. А сгенерированное можно даже зарегестрировать, что уже совсем не по RFC ula.ungleich.ch

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

"Заставь дурака Богу молиться, он и лоб расшибёт" - от 8% до 10% всех BGP UPDATE это изменения community после проверки ROV у крупных Интернет игроков. Проект с пылу с жару, возможно, будущего BCP, что так делать категорически нельзя, с выводами, мотивацией и примерами. Хочешь проверять префиксы по RPKI - делай это сам, не надеясь на чужой труд. А то что во всём нужна мера и понимание что мы от этого хотим, касается не только этого случая и BGP, а вообще всего. И на всякий случай проверить границу свой сети, чтобы внутренние community наружу не улетали.

DHCPv6 PD, настройки со стороны абонента и провайдера. На cisco.com про то же, но чуть более формально и без дампов.

Знаете что меня больше всего расстраивает во всей это истории с DNSSEC в RU и не только с DNSSEC - это невозможность получить объективную, технически грамотную и полную информацию о том как всё это устроено и если что-то происходит, о том что произошло. Да любую информацию: на ТЦИ нет вообще новостей про то что случилось, на ЦМУ ССОП только сам факт аварии и что всё починили.

Кто занимается расследованием, ведётся ли оно, будет ли отчёт? В РБК говорят, что он уже есть и разослан по регистраторам, но техническое сообщество, и людей которые в будущем его могут пополнить, и которые зависят от Интернета - гораздо больше, и чем больше информации доступно, надо признать не по самой популярной теме, тем больше вероятность, что это сообщество продолжит оставаться профессиональным и дальше, а для этого надо информацией делиться.

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

Из того что можно вычленить - на Пиринговом форуме регулярно поднимают тему DNS в России, в позапрошлый раз прямо можно было увидеть панели мониторинга и услышать как это устроено в докладе Павла Храмцова и видео. А на ЦМУ ССОП есть раздел с отчётами, где каждый месяц публикуют много и подробно, про национальную систему доменных имён в том числе, за Январь пока ещё не выложили.

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

240.0.0.0/4 ещё не оставляют надежды откопать, кто-то это уже сделал. Слишком поздно, будущее не только наступило, оно уже прошло для этого блока, при том что IPv6 продолжает тихо плакать в сторонке.

Презентация нового инструмента на OARC 42 для определения версии DNS сервера. Проверить насколько хорошо получается, можно скачав всё нужное с Github.

Иcтория Juniper от Pradeep Sindhu сооснователя Juniper (pdf) через изобретение пакетных процессоров и осознанного выбора IP и Интернет - ода инженерам.

На некоторые Nexus завезли возможность дампить трафик который попал под фильтры CoPP, чтобы достоверно определить что, всё-таки, вызывает проблему, не гадая только по количеству дропов.

Новый инструмент для наблюдения за инцидентами BGP - BGP Watch и презентация его возможностей в блоге APNIC.

Описание организации (подразумевается IT компания, но описание универсальное) как параллельной системы, в которой действующим элементом является сотрудник. А дальше, используя подходы к управлению параллельных систем и их ограничений, теорию очередей, выводятся принципы функционирования организации и даются советы по обеспечению эффективности этого функционирования.

Лучший результат - линейный рост производительности с линейным ростом сотрудников - недостижим, по причине необходимости взаимодействия между сотрудниками, частями системы, поэтому производительность каждого сотрудника, с ростом их числа, должна увеличиваться, чтобы организация сохраняля свою эффективность. Другие советы тоже вполне логичны: больше локальной свободы, маленькие команды, максимально независимые задачи (есть критический кивок в сторону микросервисов).

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