Товарищ в понедельник пишет: "Ты видел, видел? Сразу паре десятков LIR дали адреса в RIPE NCC". Я за этим уже давно не слежу, но ситуация там такая, что эти пару десятков никакой роли не сыграли. Свою /24 можно дождаться за полтора года, в растущей очереди из 800 страждущих. Общую картину с адресами читаем у Geoff Huston, кто что получал, куда продавал и по какой цене в 2025 году.
Переезд всегда интересное занятие, во время которого узнаёшь много нового про свою сеть и сервисы в ней. История про переезд CA в среде с Aruba ClearPass и ситуацию тупика доверия, которую смогли решить только вручную.
Если постараться, то можно инициировать бесконечные самоподдерживающиеся BGP UPDATE между автономными системами, если так сделать много раз, то ничем хорошим это не кончится. Общие слова в статье Internet Society из которых не очень понятен механизм происходящего, поэтому лучше читать работу в pdf. Основная причина возникновения, то что ваши клиенты доступны через транзитную автономную систему, а не напрямую. Решение - исключить такую ситуацию, подойдёт, например, повышенный local preference, который не может поменять клиент. Так не у всех, поэтому авторы нашли активные самоподдерживающиеся UPDATE в большом Интернет.
Новых IPv4 адресов не осталось, а старые перетекают между владельцами и между регионами часто и по многу через механизмы купли/продажи/аренды. Поэтому анализировать угрозы внутри IPv4 пространства становится всё сложнее, по причине отсутствия достоверных меток "доверенности, безопасности" из-за частой изменчивости владельцев адресных пространств.
www.shellcheck.net - проверка ваших Shell скриптов. Давно уже ничего не писал, если требуется, обычно, беру за основу какой-то из существующих скриптов, чтобы не выбиваться за рамки приличия, которые когда-то почерпнул из какой-то статьи. Напортачить, как и в любом языке, есть где, особенно когда кавычки. скобочки и пробелы являются сильно значимыми элементами. Поэтому лучше убедиться что оно, как минимум, сразу всё не сломает.
Анализ от Wikipedia, кто к ним заходил по IPv6 на протяжении 20 лет. Есть про количество, префиксы, AS и EUI-64. Можно, в принципе, увидеть изменение популярности как IPv6, так и Wikipedia в целом.
А вот и Geoff Huston со своей аналитикой за год: про размер таблиц маршрутизации и динамику их изменений. Как обычно, названы конкретные виновники событий и приведены прогнозы в рамках нескольких моделей развития. Интересно, что прогноз роста в IPv4 сильно лучше чем в IPv6, но это функция с очень большим количеством неизвестных параметров.
Хороший пятничный мем. Когда виланы и маски пройдены следующий затык это more specific маршруты и ECMP. Совершенно неожиданно для меня, встречал это непонимание у людей, которые долго и много работали с сетями. Находится где-то на границе базового понимания и уже специальных сетевых знаний.
Мой домашний Linux Mint, 22 или 23 декабря прислал последние апдейты пакетов и проснулся только 5 января с обновлением Webkit, дальше уже в обычном темпе. Кстати, без перезагрузок по каждому поводу и тогда когда я сам захочу, Windows привет. Понедельник, конечно, начинается в субботу, но ещё осталось немного времени, чтобы провести его как Linux Mint, в настоящем моменте.
Ещё итоги года, теперь нашего Интернета. Не то чтобы это что-то новое, но ситуация окончательно оформилась повсеместно о чём много и часто говорилось в кулуарах. ТСПУ сломало все диагностические сетевые инструменты. ping, traceroute, netcat, nmap, looking glass - не работают никак и нигде, у вас могут быть минимальные задержки, открыты все нужные порты, все маршруты строятся так как вы их построили и все префиксы доступны, но при этом сервис не работать. Потому что связность портится не на уровне сети, а на уровне приложений и протоколов. И вместе с поломкой диагностических инструментов ломается взаимодействие клиента и ТП провайдеров. Провайдер, в подавляющем большинстве случаев, делает теперь только одну вещь - пересылает ваш запрос в ЦМУ ССОП. В ЦМУ ССОП можно написать самостоятельно или сходить в личный кабинет РКН, хотя там всё и заточено под провайдера, но далеко не только провайдеры теперь обязаны этим всем заниматься. Скорее всего вам ответят, что надо заполнить документ, чтобы включить ваши ресурсы в белый список, если это уже было сделано, то отправят обратно к провайдеру, сказав что у нас всё по закону и никаких излишних блокировок нет. Может быть, спросят про номер ТСПУ который стоит у провайдера, для проверки.
Дальше, кому бы вы не написали, всё развивается одинаково, провайдер сам напишет в ЦМУ ССОП и получит ответ что для диагностики надо заполнить табличку, с тем какие ресурсы недоступны, трассировки туда и обратно (то что практически никогда невозможно получить) и другие ваши данные с просьбой поддерживать активный сеанс связи. Если у вас несколько провайдеров, то надо постараться чтобы трафик был симметричный, в противном случае, вас просто не смогут найти. В процессе, может быть скажут, что сняли блокировку между проблемными адресами, но это никогда не помогает. Через какое-то время уточнений и ответов что ничего так и не заработало, будет ответ - избыточных блокировок нет, трафик ходит нормально. И вот ровно после этого ответа, который вам переслал провайдер от ЦМУ ССОП, всё обычно начинает работать, "само".
До того как написать провайдерам о проблеме (лучше написать всем сразу), по характеру этой проблемы уже понятно что это не сетевая проблема, в том смысле в котором она всегда была. Эти реалии которые окончательно оформились в прошедшем году и которые превратили провайдеров в брехучий телефончик, тем самым убив необходимость держать качественных специалистов в ТП, если всё чем они занимаются это переписываются с ЦМУ ССОП.
