Патчкорд

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

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

Всех с наступишвим Новым 2026 годом, надеюсь, вы готовы к традиционному отчёту @FullViewBGPbot, по количеству префиксов в Интернет в прошедшем году. В 2025, уже по всем показателям, количество IPv4 префиксов перевалило за миллион. А общий рост составил больше 70000, даже если выкинуть резкий подъём осенью, то всё равно остаётся плюс 50000, что гораздо лучше чем несколько последних лет, когда наблюдался прирост порядка 30000. Это как в 2017 или даже лучше, когда мы фиксировали прирост 60000 префиксов. Про IPv6 можно сказать, что осталось так же, меньше 20000 прироста в год, это хуже последних лет, но всё ещё вписывается в линейный тренд. Всего, немногим меньше 250000 префиксов. С автономными системами поддерживаемся показателей предудыщего периода - плюс 1000 в IPv4 и плюс 1500 в IPv6. Количество /24 в IPv4 растёт по проценту за год, сейчас около 63%, а /48 в IPv6 держится вокруг 45%. Скоро должен быть разбор от Geoff Huston, может он расскажет, что же такое произошло в IPv4 и виноват ли в этом AI.

Пришла зима, жди беды. 😢

Настоящей классики вам, вечной.

Какой BGP демон лучший по разным показателям, подробный обзор с NANOG95. Большое спасибо за наводку нашему подписчику. Представлены: Bird, FRR, RustyBGP, holo-routing, OpenBGPD, GoBGP, ExaBGP.

Любая сфера обслуживания нацелена на среднего потребителя, типичного. Не важно что это за сфера и насколько широкий её охват, от банков и Интернет провайдеров до производства штучных лакшери вещей. 80% запросов будут однотипные, 15% вообще мимо, оставшиеся 5% сложные, цифры из личного мироощущения, не цепляйтесь к ним сильно. Под эти 80% настраиваются процессы, подбирается команда специалистов способных решать средние запросы. Индивидуальный подход, если у вас нет личного пожизненного закреплённого за вами менеджера, который больше партнёр чем менеджер - это быстро распознать те 5% нетипичных запросов и свернуть с проторенного пути в сторону их решения. Но так делают хорошие компании, подавляющее большинство компаний - средние. Они проходят весь путь типичных запросов и потом, может быть, выйдут на путь отработки уникальных, а может и нет. Как это выглядит на практике. Вы же помните что у меня ДОМ.РУ. Сломался Интернет, я этого не заметил, потому что сломался он в виде 300Мбит/c вход, 3Мбит/c выход. Для моих нужд хватает, но в случае заливки картинок, например, в мессенджер, заметно тормозит. Когда я на это обратил внимание через несколько месяцев, естественно, пролез всё что мог пролезть: смена устройств, смена роутеров, Wi-Fi, кабель, разные бразуеры, не браузеры, попробовал менять скорость подключения 10/100/1000 Full/Half, настолько мне не хотелось звонить провайдеру - везде одно и то же, на вход отлично, на выход никак. Шаг второй, пишем провайдеру в ЛК (там, по прежнему, приглашалка годичной давности). Конечно, робот, который пытается решшить 80% средних проблем, ему это не удаётся. Шаг третий, робот зовёт человека, который тоже хочет решить 80% средних проблем, и я уже в третий раз, перезагружаю роутер, тестирую скорость, меняю браузеры. ДОМ.РУ сделал программу-тестилку, которую меня попросили скачать и запустить, но она работала так долго, что оператор ничего не спрашивая сказал, что слишком долго от меня нет ответа, как будет вернитесь в чат, а я отключаюсь. Шаг четвёртый, возвращаемся в чат и попадаем на робота, что возвращает нас к первому шагу, проходим всё по кругу четвертый раз. Шаг пятый, робот не может позвать человека, потому что нет свободных операторов, повторяем Шаг четвёртый, до момента когда такой оператор таки появился. Шаг шестой, оператор, решая средние проблемы, смотрит в диагностику которую прислала программа-тестилка и мы ещё раз проходимся по настрокам сетевого стека, в частности смотрим скорость и дуплекс, которые видимо программа-тестилка собрать не смогла. После 2 часов, серьёзно, наконец, мы добираемся до ситуации что это не средняя проблема пользователя, это всё-таки проблема на стороне оператора и нужен выезд техника. Тут надо отдать должное, что выезд был назначен в тот же день, буквально через 3 часа. Шаг седьмой, конечно, теперь техник, решая среднюю проблему, проделал ровно то, что было проделано уже 5 раз до этого: менял браузеры, оборудование, роутеры, скорости, потому что средняя проблема в провайдере это проблема на стороне абонента и в среднем делать по другому выйдет дольше. В итоге, пошаманив в ящике с оборудованием, всё стало работать как надо. Вот такой средний мир, наверное через чур уж средний, выделится на фоне которого не так уж и сложно, надо иметь, действительно, чуть более индивидульный подход, который не только на словах. Ещё один момент, помните про QoE и всякие привентивные меры, когда провайдеры рекламировали, что заранее узнают о проблемах абонента и чинят до того как абонент к ним обратился. Ни намёка на эту тему, учитывая сколько диагностики пришлось собрать. А проблема, наверняка, была бы видна в таких системах, уж очень заметный перекос между направлениями трафика, скорее всего и окошки TCP поплыли, и повторыне передачи и ошибки. Но нет. Возможно, таких проблем действительгно очень много, а ресусурса чинить всем, наоборот, не много, поэтому ждут пока абонент сам прибежит, или и не прибежит. З.Ы. Я этот текст хотел написать в ЛК после разговора с оператором, но поле для ввода оценки уж очень короткое, тоже заточенное под средний ответ, наверное, матерный.

Вдогонку, тесты и статистика IPv6 - ipv6.army. Новый сайт, иногда не работает.

Ежегодный отчёт Cloudflare Radar. Общий трафик вырос на 19%, у Starlink тоже вырос, Android победил iOS, десктоп победил мобилу, боты побеждают человека и больше всего их в США, Go победил Python в качестве API backend, HTTP/2 половина, а HTTP/1.x больше HTTP/3, IPv6 есть, а в TLS1.3 победило постквантовое шифрование, DDoS растёт, 6% писем всё ещё могут быть вредоносными. Это глобальные тренды, но можно посмотреть и по странам, где всё может быть совсем не так.

Про Ansible, Open source и всё-всё-всё, главное в комментариях.

Заворачиваем исходящий трафик в XDP, через veth, токлько не забываем сделать то что должно было сделать ядро, если бы мы его не пропустили мимо.

VXLAN VXLAN'ом, а как насчёт чистой L3 маршрутизации без лишней L2 прослойки. Ловим ARP или NDP и превращаем в BGP маршрут. В статье только концепт в ручном режиме, но нужные инструменты названы.

Настройка EVPN c VXLAN для Cisco Catalyst, во второй части в режиме c резервированием. Как мы поняли из нашей весенней встречи - VXLAN интереснее чем MPLS, железок с поддержкой больше и они доступнее по цене.

Микрословарик акронимов от ARIN, помимо общеупотребимых, есть и специфические внутренние.

Балансировка по портам это ещё не всё, за ней стоит собственно аппаратное решение. На картинке то, как выглядит балансировка между процессорами на Eltex ESR. CPU0 - это контрол плейн, BGP, и вот это вот всё. Дальше трафик среди которых выделяется CPU17. Туда попал туннель GRE про который не знает маршрутизатор, для него это просто трафик между двумя хостами, в котором даже порты не меняются. Одна из неприятных особенностей туннелей. В Eltex можно посмотреть кто же самый жирный потребитель процессора по трафику командой show cpu network-load.

Как на Juniper SRX подгружать списки IP адресов в правила файрвола с веб сервера: примеры и тесты.

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

Методов сканирование IPv6 уже достаточно много и даже вполне успешных. Про сканирование адресов подсетей, вроде, уже обсуждали. Способ рабочий, потому что роутеры на эти адреса могут отвечать, получать запросы, так уж точно RFC1884:

The "subnet prefix" in an anycast address is the prefix which identifies a specific link. This anycast address is syntactically the same as a unicast address for an interface on the link with the interface identifier set to zero. Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets which they have interfaces.

Осталось только подсети подобрать, зная человеческую природу стремления к красоте и пролистывая BGP маршруты.

После того как мы построили корпоративную сеть как провайдера на границе с Интернет, можно поговорить и про защиту от DDoS. Самостоятельно, без внешней анти DDoS услуги скорее всего ничего не получится, надо было бы стать очень большим провайдером, но родные механизмы Интернет внедрёные в сети, мониторинг и постоянная готовность к атаке должны помочь пережить её с меньшими последствиями. Blackholing вещь несомненно рабочая, но разве не этого добивается атакующий?