Ещё итоги года, теперь нашего Интернета. Не то чтобы это что-то новое, но ситуация окончательно оформилась повсеместно о чём много и часто говорилось в кулуарах. ТСПУ сломало все диагностические сетевые инструменты. ping, traceroute, netcat, nmap, looking glass - не работают никак и нигде, у вас могут быть минимальные задержки, открыты все нужные порты, все маршруты строятся так как вы их построили и все префиксы доступны, но при этом сервис не работать. Потому что связность портится не на уровне сети, а на уровне приложений и протоколов. И вместе с поломкой диагностических инструментов ломается взаимодействие клиента и ТП провайдеров. Провайдер, в подавляющем большинстве случаев, делает теперь только одну вещь - пересылает ваш запрос в ЦМУ ССОП.
В ЦМУ ССОП можно написать самостоятельно или сходить в личный кабинет РКН, хотя там всё и заточено под провайдера, но далеко не только провайдеры теперь обязаны этим всем заниматься. Скорее всего вам ответят, что надо заполнить документ, чтобы включить ваши ресурсы в белый список, если это уже было сделано, то отправят обратно к провайдеру, сказав что у нас всё по закону и никаких излишних блокировок нет. Может быть, спросят про номер ТСПУ который стоит у провайдера, для проверки.

Дальше, кому бы вы не написали, всё развивается одинаково, провайдер сам напишет в ЦМУ ССОП и получит ответ что для диагностики надо заполнить табличку, с тем какие ресурсы недоступны, трассировки туда и обратно (то что практически никогда невозможно получить) и другие ваши данные с просьбой поддерживать активный сеанс связи. Если у вас несколько провайдеров, то надо постараться чтобы трафик был симметричный, в противном случае, вас просто не смогут найти. В процессе, может быть скажут, что сняли блокировку между проблемными адресами, но это никогда не помогает.
Через какое-то время уточнений и ответов что ничего так и не заработало, будет ответ - избыточных блокировок нет, трафик ходит нормально. И вот ровно после этого ответа, который вам переслал провайдер от ЦМУ ССОП, всё обычно начинает работать, "само".

До того как написать провайдерам о проблеме (лучше написать всем сразу), по характеру этой проблемы уже понятно что это не сетевая проблема, в том смысле в котором она всегда была. Эти реалии которые окончательно оформились в прошедшем году и которые превратили провайдеров в брехучий телефончик, тем самым убив необходимость держать качественных специалистов в ТП, если всё чем они занимаются это переписываются с ЦМУ ССОП.

Мой домашний Linux Mint, 22 или 23 декабря прислал последние апдейты пакетов и проснулся только 5 января с обновлением Webkit, дальше уже в обычном темпе. Кстати, без перезагрузок по каждому поводу и тогда когда я сам захочу, Windows привет. Понедельник, конечно, начинается в субботу, но ещё осталось немного времени, чтобы провести его как Linux Mint, в настоящем моменте.

Хороший пятничный мем. Когда виланы и маски пройдены следующий затык это more specific маршруты и ECMP. Совершенно неожиданно для меня, встречал это непонимание у людей, которые долго и много работали с сетями. Находится где-то на границе базового понимания и уже специальных сетевых знаний.

А вот и Geoff Huston со своей аналитикой за год: про размер таблиц маршрутизации и динамику их изменений. Как обычно, названы конкретные виновники событий и приведены прогнозы в рамках нескольких моделей развития. Интересно, что прогноз роста в IPv4 сильно лучше чем в IPv6, но это функция с очень большим количеством неизвестных параметров.

Пинговалка, MTR, DNS и HTTP - ping6.it. Несколько локаций, IPv4/IPv6, код доступен на GitHub.

Анализ от Wikipedia, кто к ним заходил по IPv6 на протяжении 20 лет. Есть про количество, префиксы, AS и EUI-64. Можно, в принципе, увидеть изменение популярности как IPv6, так и Wikipedia в целом.

Микротика много в большом Интернет, главное чтобы использовали.

Хорошие новости,

🚀 поддержка RFC9234 (Route leak prevention and detection using roles) теперь в стабильной версии RouterOS 7.21.

Changelog

Хороший обзор вариантов синхронизации времени и почему это всегда компромисс.

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

Ещё про сложность синхронизации времени, в конкретных примерах расхождения в заголовках HTTP Date и в исторической перспективе, Git коммитах.

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

SRv6 всё ещё рекламируют, с одной стороны всё так, но с другой стороны, безоговорочно лучшее решение в рекламе бы не нуждалось.

Если постараться, то можно инициировать бесконечные самоподдерживающиеся BGP UPDATE между автономными системами, если так сделать много раз, то ничем хорошим это не кончится. Общие слова в статье Internet Society из которых не очень понятен механизм происходящего, поэтому лучше читать работу в pdf. Основная причина возникновения, то что ваши клиенты доступны через транзитную автономную систему, а не напрямую. Решение - исключить такую ситуацию, подойдёт, например, повышенный local preference, который не может поменять клиент. Так не у всех, поэтому авторы нашли активные самоподдерживающиеся UPDATE в большом Интернет.

Ещё один traceroute/mtr на стероидах Rust в псевдографическом исполнении.

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