Патчкорд

История операторских будней, пионеров включивших фильтрацию по префиксам RPKI от нашего подписчика, за что ему огромная благодарность. Есть компания с двумя автономками, с них анонсируется один и тот же префикс, но один подписан, а второй нет. В процессе путешествия по Интернет до нашего оператора добирается только один, тот который не подписан, как лучший при выборе маршрута, без учёта RPKI, потому что такой фильтрации на транзитных операторах нет. Мы идём проверять подпись, видим что она недействительная для данной AS и маршрут никуда не добавляем. Итог, трафик дропается, без дефолта. Если бы подписи не было вообще, то состояние было бы неопределено и всё бы было хорошо.

Чтобы сэкономить на передаче больших объёмов научных данных университеты построили себе отдельный интернет, но соединённый с глобальным. Работа в которой выяснили, на мой взгляд очевидное, большинство использует именно специальный интернет, несмотря на длину AS_PATH, а остальные настроили одинаковые localpref как им виднее или неверно были интерпретированы результаты, что авторы и подтвердили опросив операторов. Длину префикса менять не пытались, в разные интернеты разные длины, это было бы поинтереснее посмотреть кто как реагирует. Да, метод можно использовать в принципе для определения обратного пути и реакцию на изменения анонсов BGP, но он тоже очевидный - подключаемся к разным интерфейсам разных операторов и смотрим входящий трафик, провайдерская рутина.

Из будней админа телеграм канала. Пару раз за месяц кто-то приходит с желанием что-то порекламировать, в основном, курсы и различные мероприятия, раньше ещё предлагали, так называемый, взаимный PR, что-то перепостить в обмен на такой же репост, но такого давно уже не было. Не что-то уникальное, ту же рекламу я встречаю в разных источниках не только в телеграме. К этому фоновому шуму привыкаешь и отвечаешь почти стандартными фразами вежливого отказа. Но тут случился внезапный всплеск - с трёх разных источников с тремя разными предложениями, почти одновременно, пришли порекламить про nexthop 2025. Это настолько необычно и выделяется среди общего шума, что наверное что-то должно означать. В прошлом году, кстати, было как и с остальными, один заход.
Для меня это тем удивительно, что Yandex своим масштабом настолько больше всего рускоязычного сетевого сообщества, что не заметить профильную, я бы даже сказал узкопрофильную, ежегодную, хорошую во многих смыслах конференцию, находясь хоть чуть-чуть в теме - невозможно, тем более их всего раз два и обчёлся. Но мне с моего места может быть что-то не видно, выглядит как погоня за цифрами, превращение профильной, в конференцию общей тематики мне бы не хотелось.
Собственно, рекламу вы наверное уже видели много где, я видел точно во всех социальных сетях где проявляю какую-то активность, поэтому от меня не реклама, а искренняя рекомендация. В этом году я собираюсь на Пиринговый форум пообщаться и послушать за свой любимый Интернет и телеком, а nexthop буду смотреть по телевизору, но в прошлом году было очень круто. Кормили хорошо, наливали от души, народ очень общительный, пожал руку @netautomation, @hadal_project_channel и завсегдатаим сетевых чатиков, всем привет, и, конечо, интересные доклады и необычные сувениры. Программа уже опубликована, в живую всё увлекательнее, поэтому регистрируйтесь, если ещё нет (хотя я сомневаюсь), бронируйте билеты если вам надо доехать (уже очень пора) и получайте удовольствие от сетей.

Прихожу домой смотрю почту, а там на виртуалке кончилось место. Странно, думаю, не должно, полез посмотреть и увидел что мой скрипт перестал удалять файлы с лицензиями скачанные с открытых данных РКН. Оказалось что теперь на сайте представлены не ZIP архивы, а просто XML, и началось это где-то с Августа, Сентября (как вы поняли меня не сильно заботил этот скрипт). Конечно, мой примитивный подход на этом сломался. Но это полбеды, так как файлы стали больше то качаться стало дольше и сайт отстреливает сессию примерно после 2 минут, если качать HTTP/2, или 5 минут если переключиться на классику HTTP/1, да и вообще не сильно любит когда там что-то делают с помощью curl. Благо в curl можно много чего подкрутить, чтобы вернуть всё к жизни. Если вдруг у вас тоже есть сайд проекты за которыми вы не следите и они что-то забирают с открытых данных РКН, то обратите внимание, там произошли изменения.

Firefly метод для синхронизации часов в ДЦ с точностью 10нс, там где время настолько важно, например, для игры на бирже. Суть заключается в том чтобы прийти к среднему общему времени для близкорасположенных систем, тут точность 10нс, связанная с точностью сетевых карт, которые и используются для синхронизации времени. Решается путём обмена данными всех со всеми через случайно построенный граф. После этого, опять же, с близкорасположенных часов с мировым временем, можно забирать его и распространять внутри сформировавшегося кластера, тут точность меньше 1мкс, потому что включается CPU и системные шины. Чем больше машин внутри роя пришедшего к среднему участвуют в заборах данных с внешних по отношению к этому рою систем, тем сходимость быстрее, что выглядит логично. Можно строить несколько таких слоёв. Все свои теоретические выкладки авторы подтвердили на тестах. Для глобальной сети из-за задержек и особенностей маршрутизации неприменимо.

Обширный отчёт Cloudflare о том что падало в 3-м квартале: природные явления, действия государств, атаки, аварии. Россия представлена Камчаткой во время землятресения.

А давайте лестную оценку о внедрении IPv6. Только помните чем и как мы оцениваем проникновение, потому что средние 50% у Google могут оказаться очень частным и специфическим в действительности. Но с этого пути уже не свернуть, поэтому стоит послушать советы автора и посмотреть на IPv6, если до сих пор не посмотрели. С другой стороны, наверное, уже поколение специалистов выросло с 2018 года, не говоря про 2012, которым не пригодилось.

RPKI это ещё не всё, даже частичное внедрение ROV не помогает, а наоборот, скрывает то что вас могло бы насторожить, потому что таблица маршрутизации это одно, а передача трафика - другое. Выход конечно есть - не доверять никому, и он гораздо лучше, чем надежда на то что все будут играть по правилам и внедрят фильтрацию у себя.

Детские проблемы, скорее всего, лечится взрослением, т.е. постоянным использованием. Поддержка RFC9234 есть, как минимум, в BIRD и Juniper.

А вот действительно, если подумать, пол-интернета работает в облаках, принадлежащих книжной лавке.

– Вот скажи мне, американец, в чем сила?
– В книгах!

Мы знаем что это всегда или DNS или BGP, но не знаем почему. Картинку утащил из X.

Cloudflare про AS-SET и как это мониторить с помощью их Radar. Вообще картина срашная открывается (введите свой или не свой номер автономной системы), десятки страниц включения ASn в какие-то AS-SET, прямые и непрямые. И всё это к вопросу о доверии данному механизму.

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

Я забыл что маски и префиксы в адресах это сложно для тех кто начинает. Не могу вспомнить этот момент в своём обучении, вроде бы Олиферов мне хватило, с виланами было хуже - им я учился по мануалам D-Link. Инструментов, чтобы посмотреть как это работает очень много, про что-то мы уже даже говорили. Ещё два - cidrip.com и subnetipv4.com, для кого английский проще масок, там и видео есть обучающие.
Знание двоичной арифметики помогает очень сильно, а после того как разобрались с основами можно и некоторые следствия выводить: как складывать два префикса и какие для этого есть ограничения, чем инверсная маска удобнее и другие. Но сначала база.

В мире IPv6 не очень нужны тесты чтобы узнать работает ли IPv6, так же как не нужны тесты работоспособности IPv4 в мире IPv4. По прежнему нужны тесты сервисов и различных аспектов качества работы протокола, но не сам факт его наличия, когда он везде. С IPv6 пока не так, но этот путь мы в любом случае пройдём до конца, сейчас можно уже не говорить про совместимость, всё совместимо - остался вопрос распространения. Кто-то помнит танцующую черепашку Kame? Теперь пришла очередь и test-ipv6.com, не важно по какой причине. Можно поднять локальную копию для своих пользователей, если не уверены что вы внедрили IPv6, а если уверены что внедрили, то используйте обычные сетевые инструменты для диагностики аспектов работы своей сети.

Little-endian vs. Big-endian - интересная и холиварная тема, которую давно не слышно по причине что большинство летают на слоёв 10 выше этого всего. Линус, конечно, в своей манере, может себе позволить про это вспомнить, пройдясь по RISC-V. Но дело не только в процессорах, которые в основном придерживаются Little-endian, когда младшие значения в младших адресах памяти. Есть ещё сетевые протоколы, а там ровно наоборот - старшие значения передаются раньше младших, и, вроде, понятно для чего это всё было сделано, и, вроде, уже не поменяешь то что есть, но с новыми можно похоливарить.
З.Ы. Почему-то вспомнилось, для ценителей стряхивать пыль с архивов.

Геолокация в Интернет сложная штука даже без спутниковых подключений. Ожидаемые сложности которые возникли у APNIC со Starlink и как они это исправили - перестали классифицировать, вообще, для ряда стран, где уж очень сильно странно было.

Библиотека на C# для оптимизации - агрегации таблицы маршрутизации относительно next-hop. В коде есть упоминание про AS_PATH, что это ещё не поддерживается. Автор пишет что из миллиона реальных BGP префиксов до 90000 ужимает, правда не пишет сколько там у него пиров, можно было бы и до одного 0.0.0.0/0 ужимать при желании. Всё быстро и эффективно на основе вот этого алгоритма.
Я не смог просто проверить, не заморачиваясь с .NET, так как оказалось что я нигде с ним не соприкасаюсь. Но когда-то, почти 10 лет назад, я тоже писал по поводу агрегации реальной таблицы маршрутизации BGP, когда в ней было 650000 префиксов IPv4. Мой подход не предусматривал рождение новых сущностей, только включение в существующие префиксы или агрегация соседних с учётом AS, в том числе. Написано плохо, даже мне с трудом вспоминается что я имел ввиду. Идеальный результат, как я его тогда себе поставил, ужать до 100000, не потеряв маршрутной информации, так не получилось, да и вообще выводы тогда были неутешительные. Хотя в некоторых местах, вполе себе сжималось до уровня выше 90%, как и у автора библиотеки.

Вчера я писал про интернет и «DDOS наоборот». Но не упомянул про сервисы вещания операторов, такие как BeeTV, TV+, AlmaTV и другие.

Принцип их работы несколько отличается от обычных ТВ-сайтов в интернете. Если включить любой канал, кроме футбольного, всё работало стабильно (локальные проблемы не в счёт). То есть сама вещательная инфраструктура операторов связи отрабатывала штатно. Значит, дело было не в перегрузе их платформ, а именно во входящем потоке, где шёл матч «Кайрат - Реал Мадрид».

Я знаю, что операторы активно локализуют кэши и CDN популярных ресурсов. И вчера это было видно: например, Кинопоиск от Яндекса через локальные сервера отдавал контент без сбоев, несмотря на нагрузку. Коллеги из крупных операторов подтвердили это статистикой. Вывод: работа по локализации сделана правильно.

В то же время, раз у всех операторов картинка ломалась одинаково, значит, на стороне BeeTV или TV+ что-то «сломаться локально» не могло. Это выглядело как некорректный входящий поток.

Параллельно очевидно, что серверные мощности вещателя не выдержали: платформа ТРК «Казахстан» не была готова к такому наплыву. Когда количество пользователей резко превысило предел, серверы начали отдавать 500-е ошибки, сайты и приложения перестали отвечать. По постам пользователей сбои наблюдались у всех локальных ОТТ-провайдеров, потому что они получали уже деградированный контент от телевизионщиков.

На этом фоне пользователи начали массово перезапускать приставки и приложения, создавая лавину повторных запросов. Это фактически перегрузило платформы ОТТ-провайдеров и усугубило ситуацию.

📌 При этом сама сетевая часть выдержала нагрузку: локальные CDN и кэши работали. Но для вещания «на весь мир» этого оказалось недостаточно. Здесь нельзя всю вину перекладывать на операторов связи. Проблема скорее в телевизионной инфраструктуре, которая, похоже, сильно устарела и до сих пор может работать на гигабитных линках, тогда как вчерашний трафик переваливал за терабиты.

Вероятнее всего, сервисы вещания операторов тоже пострадали, но не по своей вине. Их инфраструктура работала нормально, и «неспортивные» каналы это подтверждали. Главная проблема была в источнике сигнала и серверной архитектуре ТВ-компаний.

P.S. Это мой личный анализ на основе технических наблюдений и данных коллег. Дождёмся официальных новостей.