От теории к практике - десятилетия научных и инженерных исследований, сведённых к нескольким несложным движениям.

От проблем с MTU видимо мы никогда не избавимся будь ты хоть трижды VXLAN, плата за желание строить оверлеи в оверлеях. Маршрутизаторы на концах туннеля молча уничтожат любой фрагментированный пакет.

Теперь вы знаете откуда забирать свои сертификаты и лицензии, да и вопрос про название заиграл другими красками. Фото моего товарища уже оттуда.

Мне кажется что в этом году как-то рано стартанули готовиться к Новому году - со всех сторон уже ёлки с котами, advent календари (про это первый раз услышал) и гирлянды. Поэтому я тоже не стал тянуть и запилил новогоднюю ёлочку, без IPv6, но зато из консоли. Нужна Cisco с доступом в Интернет, я думаю Cisco-like консоли тоже подойдут, возможно Looking glass с Cisco, иногда там можно подставить свои команды. Критично 70 символов в строке.

Обрабатываются только первые 1120 Echo requests начиная с seq 0 и размером IP пакета, вместе со всеми заголовками, в 36 байт, это 8 необязательных байт данных ICMP. Время ожидания ответа ставим в 1 секунду, но даже так придётся подождать. Сначала я хотел сделать по программерски, даже освежил что-то из Си, но в итоге сделал по админски, самым простым способом, из-за чего цветов всего три: Timed Out, Success, Unreachable.

Job Shijders напоминает нам всем про ASPA, реализуя подпись маршрутов для своей AS. Поэтому, раз все свои префиксы мы уже подписали (далеко не все), пора переходить к подписи AS_PATH. Это всё ещё draft и публичных инструментов для реализации этого механизма нет, в комментариях в твиттере есть небольшое обсуждение о сроках и перспективах.

Ликбез от RIPE Labs какие адреса вам могут достаться при покупке, замешанные в спаме, DDoS и вирусах. Поэтому покупая IPv4 адреса, надо на них внимательно посмотреть - риск нарваться на проблемы тут гораздо выше. Я, кстати, всё чаще и чаще натыкаюсь на раздербаненные диапазоны Legacy блоков, хотя в целом, фильтры по регионам ещё работают неплохо, но видимо до конца IPv4 далеко, адреса всё ещё можно купить.

В Cisco IOS XR есть show commit changes diff и с ним может быть не всё так хорошо. С другой стороны он там есть, пользователи IOS XE даже этому бы были рады.

В Juniper посчитали разницу в потреблении лабы из реального железа и виртуальной лабы, с ненавязчивой рекламой HP и vLabs. Но все же знают что виртуальное железо это совсем не то что реальное.

Прямая ссылка для медитации https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list. Очередь означает что адресов для выдачи нет никаких, но как только что-то вернётся от других LIR, по разным причинам, то они будут распределены. Есть ещё резерв в 0,71 миллионов адресов.

​Жесть контент с UK IPv6 Council. График листа ожидания LIR'ами /24 в RIPE регионе. Видно плохо, так что просто поверьте: 10(!!!) месяцев.
Текущая цена, если верить исследованиям, 40$ за адрес. На диком рынке все 60$. Хотя вроде ещё не так давно было 26$.
P.S. Самое интересное: не смотря на всю эту жесть, шестёрка продолжает оставаться игрушкой телекомов. Бесчисленные контент- и хостинг-провайдеры чураются её как могут. Просто посмотрите на их тарифы на минимальные, странно нарезанные, IPv6 сети.
https://ipv4marketgroup.com/ipv4-pricing/

Несколько раз за последнее время услышал что нельзя поднять site-to-site туннели IPSec в route-based режиме с одной стороны с policy-based режиме с другой. Если хочется, то конечно можно. Выбранный режим это не более чем локальный способ отправить нужный вам трафик в туннель, а на уровне IKEv2 всё равно придётся согласовать Traffic Selectors, чтобы сформировать необходимые для работы IPSec таблицы политик и состояний. И вся проблема не в протоколе, а в реализации соответствующего режима.

Для policy-based значения TS задаются в явном виде, как например в Juniper или Strongswan, или в Сisco access-list который привязывается к crypto-map. На основе этих значений формируются и политики, здесь уже неявно, которые заворачивают трафик в туннель. При этом обеспечить прохождение трафика через нужный интерфейс с политиками всё равно придётся маршрутизацией.
А для route-based нет необходимости явно задавать значения. Про таблицу маршрутизации IPSec мало что знает, поэтому на основе ваших маршрутов, которые заворачивают трафик в VTI интерфейс никакие согласования не выполняет. Вместо этого, по умолчанию используется TS 0.0.0.0/0 - 0.0.0.0/0, посмотрите свои SA в режиме route-based, чтобы в этом убедиться. Таким образом, если настроить такое же значение со стороны policy-based, то всё должно заработать между маршрутизаторами с разными режимами управлением трафика IPSec. Как минимум один такой туннель вы точно сможете построить, в ситуации когда уж совсем не удалось договориться. Второй подобный туннель с policy-based стороны уже может упереться в особенности реализации, потому что одинаковый 0.0.0.0/0 для другого туннеля может иметь неоднозначное значение в политиках, ловил такое на ASA - в двух разных IPSec, но с одинаковыми TS внутри, один из них не поднимется. Наверное, ситуация имеет типовое решение, или обновление, но тогда я просто подробил сеть в одном из туннелей на две половинки, потому что имел доступ к обоим концам туннеля.

Лучшее же решение, даже если вы используете route-based режим с обоих сторон - это явно определить traffic selectors. Это можно сделать и в Strongswan, и в Juniper, и в Cisco IOS опцией Multi-SA. Помимо возможности поднимать туннели с любой стороной хоть policy-based хоть route-based ещё и дополнительная защита если упустили лишний трафик в туннель, он туда не пролезет, только дропнуть его не забыть. Конечно, реализация этого может быть не везде, насчёт уже упоминаемой ASA совсем не уверен, да и версии софта должны быть актуальные, но способ с TS 0.0.0.0/0-0.0.0.0/0 один раз сработает всегда.

Правильное дополнение. Всегда исключайте разночтения, а в IPSec особенно, у меня сложилось чувство что его знают гораздо меньше чем даже BGP. Как минимум к BGP имеют свободный доступ гораздо меньше людей.

Сегодня много сообщений о том, что МегаФон похоже наконец-то включил IPv6 везде и для всех. Проверяйте у себя. Уточняют, что название APN должно быть просто "internet", а не "internet.iss.onegafon.ru". Режим подключения в её настройках необходимо сменить с v4 на v4v6, если эффекта нет, можно проверить появляется ли IPv6 в режиме v6 (без v4), и потом снова v4v6.

Yandex nexthop и Пиринговый форум прошли почти одновременно и это хорошая возможность сравнить впечатления по горячим следам, кроме того что они разные и Qrator на обоих представил одинаковый доклад. Пиринговый форум - лучше. Конечно, стоит смотреть и слушать оба если вы не участвовали и ещё не успели это сделать.

После просмотра Nexthop у меня сложилось ощущение второй серии - всё было, но всего больше, мы продолжаем продолжать. Я даже специально отмотал на год назад чтобы сравнить впечатления, и понял что они действительно такие. То есть, я не нашёл для себя что-то очень новое, даже подумал, что это потому что я слишком в теме. Из всего того что было, отмечу почти несостоявшееся выступление из Китая, по причине плохой связи про централизованное управление каналами связи для клиентов на своей инфраструктуре без MPLS - свои костыли, это вовсе и не костыли, а очень даже инновации, жизнь без оверлеев на сети провайдера есть, автоматизация решает. А также если вы очень большой и вендор вас очень внимательно слушает и оперативно добавляет все ваши хотелки.

Из-за этого у меня были достаточно тревожные ожидания Пирингового форума, но всё получилось вполне динамично. Может потому что темы ближе, а может потому что докладчикам давали времени в два раза меньше. В любом случае можно было услышать позицию RIPE NCC на всё происходящее вокруг включая РАНР, увидеть админку DNS инфраструктуры MSK-IX, завалить новый инструмент daspath.ru и в Телеграме тоже @daspathbot, узнать почему все теперь обсуждают IPv6 в Иви и действительно ли ТСПУ делают Интернет безопаснее. Справедливости ради, скажу что был ещё поток Медиалогистика параллельно, но это вы уже сами, если интересно.

Долгожданные, традиционные мероприятия в реале. Смотрите и слушайте.

Для BIRD настраивается опциями: local role <provider|rs_server|rs_client|customer|peer> и require roles если не хотим поднимать сессию с соседом который не поддерживает ролей

Для FRR: neighbor <PEER> local-role <provider|rs-server|rs-client|customer|peer> [strict-mode]

Для OpenBGPD: announce policy <no|provider|customer|rs|rs-client|peer> [enforce]

Осталось только пожелать чтобы это стало распространённой практикой.

Вчера в Bird появилась поддержка BGP ролей (RFC 9234). И это не может не радовать. Поздравляю всех причастных, особенно Сашу Азимова и Женю Богомазова. Вы котики :)

https://bird.network.cz/

Конечно, кот это не такса, но тоже может иногда.

Календарик на новый год, он хотя и в ASCII графике, но в PDF, поэтому можно смело забирать ценителям, печатать и вешать на стену.

К вопросу о глубинах глубин и то как решения 10-15 летней давности будут вас преследовать и всех остальных пользователей вашего продукта. И, конечно, о знании предметной области, как работает TCP и всё что вокруг него, в частности TCP_NODELAY. Про Kubernetes тоже есть ;)

Go is evil on shitty networks https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/

Ежегодные графики по размеру BGP таблиц в IPv4 и в IPv6 и детальный расклад (по другим графикам) от Geoff Huston.

Чем отличается только что закончившийся год от предыдущих? Рост BGPv4 замедляется и в этом году составил около 35000 префиксов, вместо 50000, два года назад было около 40000, а до этого стабильно по 60000. Такими темпами до миллиона в 2023 не дотянет. Общий размер сейчас 935000, если смотреть с этого места. Рост BGPv6 в этот раз не ускорился и показал плюс 30000 префиксов как два года назад, в прошлом году было плюс 40000. Общий размер около 170000.
Позапрошлый год я уже называл необычным (время карантинов). 2022 обычным тоже не назовёшь и по динамике он как раз больше похож на 2020 чем на 2021, как минимум неожиданная для меня просадка в росте IPv6 префиксов. Если в IPv4 можно говорить о насыщении, то для IPv6 до этого ещё очень далеко.

Geoff Huston обязательно ещё сделает обзор на устойчивость BGP таблиц, ссылку постараюсь не пропустить и поделиться. Из уже готовых итогов в большой череде предстоящих публикаций с итогами - RIPE Labs сделал ретроспективу своих статей и событий по месяцам 2022 года.

Смотреть за BGP в 2023 году можно в ботах @bgp_table_bot, желательно иметь доступ к Twitter, но может быть я переделаю на Mastodon и @FullViewBGPbot, пока без годовых графиков, но в следующем году всё будет.