К такому всегда надо быть готовым, даже минорные изменения версии прошивки порой приводят к перемене логики работы опций конфигурации или их замещению, или прекращению поддержки и удалению. Свежий пример с send-community в IOS-XE. Читайте релизы для новой версии, историю, используйте тестовый стенд, сравните конфигурацию до и после и никогда не забывайте что ваша сеть это ваша сеть, вендору, интегратору и всем остальным до неё нет никакого дела.

Разбор сообщений ICMP Destination Unreachable в докладе на конференции SharkFest'24 - что к чему, почему это важно, и как это выглядит практически при анализе трафика на NTP сервере. Конкретные команды и фильтры для Wireshark присутствуют. Презентация в pdf.

NIST выпустил утилиту для тестирования различных технологий защиты от утечек маршрутов в Интернет: генератор BGP трафика с соответствующими наборами данных - есть ASPA, BGPSec и ROA. Доступно на Github.

Сетевики и даже в более широком смысле инженеры инфраструктуры медлительные, потому что у них нет нужных инструментов как у DevOps, которые их пилили предыдущие десять лет. Проблема только лишь в том, что для железной инфраструктуры не существует git reset, точнее это будет кто-то, кто подойдёт к конкретному устройству в конкретном месте и что-то с ним сделает.
Для DevOps, живующих в виртуальном слое, над настоящим железом, такой проблемы конечно нет. Всегда можно спуститься на уровень ниже обратившись к инженеру инфраструктуры, чтобы он что-то откатил, даже в самых невероятных случаях. А вот инженеру инфраструктуры спускаться ниже некуда.
Конечно, можно построить инфраструктуру, которая будет обеспечивать работу существующей железной инфраструкруты, но и её надо будет кому-то обслуживать. Для сетевиков, кстати, уровень ниже - это каналы связи со всеми этими DWDM и прочей физикой, там где уже не сетевики, а связисты - вот им без вариантов только ехать и чинить.
А устройства и инструменты встроенные в философию DevOps уже есть, будет больше, но уровень ниже которого уже нельзя будет спуститься так и останется на своём месте. И да, он будет очень стабильным, потому что без него всё остальное не заработает.

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

Научные учёные математики говорят что улучшили алгоритм поиска кратчайшего пути в графе, Дейкстры и других, кто его уже улучшал, до временной сложности O(m*log^(2/3)(n)) вместо O(m + n*log(n)). Я не смог продраться сквозь формальный язык формул и определений, поэтому почитал ещё обзор, где какая никакая мысль есть, а не просто обозначение события. Улучшили за счёт того, что выбирают часть вершин и считают пути до этой группы целиком, потом рекурсивно повторяют то же внутри группы, вроде как.

Ресурсов тратится больше и в целом сложнее получилось, но абстрактно быстрее. С точки зрения применимости в нашем деле предложенный алгоритм формально подходит, компьютерные сети подпадают в категорию разряженных графов. Но, подозреваю, что текущие решения так вылизали на аппаратно-программном уровне, что в абсолютных значениях выигрыша не будет. Тем более, сети где надо считать кратчайшие пути таким способом, мы научились делать совсем небольшими (внутри area OSPF, или L1 уровня IS-IS), а дальше всё сводится к дистанционно-векторным протоколам.

Сравните с темами CCNA и не смотрите на то что не все затрагиваемые технологии актуальные, их там не много упоминается и ничего в них страшного нет. Cisco написала столько учeбных материалов, что за последний год я получил несколько вопросов про ISL от желающих разобраться в сетях и начинающих что-то читать, а как мы знаем - Инетернет всё помнит, поэтому поиск до сих пор приводит к когда-то популярным изданиям. И да, на интервью поговорить за базовые принципы из тем CCNA, я считаю, полезно. Не у всех, далеко не у всех, есть стройное связанное представление как сети работают. А если есть, то дальше можно уже углубляться, оттолкнувшись от основ, которые не стоит забывать и которые актуальны, в Интернет так точно, при всём наличии современных методов и решений.

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

Доступность NS национальных доменных зон из разных стран. Автор делает выводы о принадлежности anycast/не anycast, что не совсем корректно, тут скорее о географической распределённости. Больше интересны исходные данные в CSV, по которым можно свои выводы сделать.

Проверить поддержку IPv6 на сетевых устройствах, если доверяете ИИ. Лет 10 назад это бы ещё имело смысл. Сейчас, всё что меня окружает поддерживает IPv6, может быть, за исключением каких-то очень специфических вещей. Если на современном устройстве что-то и не поддерживается, то имеет смысл говорить не о поддержке IPv6, а о поддержке конкретного функционала, но это справедливо и для IPv4. Дело, не в поддержке, дело в применении.

Посчитали локальные ноды трафик генераторов (как GGC для Google) на IPv6. IPv4 больше, но зависит от места и от трафик генератора, по качеству одинаково. Нашли, что трафик генераторы могут ставить свои ноды в сети других трафик генераторов. В самой публикации много статистики по разным плоскостям, совсем технические вещи про TLS и ROV вынесли в приложения.

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