Разбор сообщений 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 уж точно не файрвол.