В 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, пока без годовых графиков, но в следующем году всё будет.

Что такое и зачем нужен VXLAN, первые два поста из запланированной серии. Помимо теории есть и примеры конфигурации на заданной топологии.

Наткнулся на ttyd - утилиту которая прокидывает терминал Linux в Web. Сначала подумал зачем, а потом вспомнил что сам таким же занимался для Cisco, что называется средствами из коробки. Не знаю заработает ли моё решение сейчас, но вроде ничего серьёзно там не поменялось за это время. Для Linux, конечно, стоит выбрать ttyd или написать своё.

Файрволы работают хорошо скрывая своё присутствие, но понять что у тебя в середине именно файрвол можно, если хоть какой-то ответ возвращается. Здесь автор подаёт это как открытие, но именно так, фильтруя по TTL, вставленные системой фильтрации DNS ответы, мне удаётся в этом моменте обходить файрвол, скорее всего пока. Раньше можно было обходить гораздо больше (обратите внимание на hlim), сейчас приходится строить туннели. Технологии подтянулись, но скорее доступных мощностей выделяемых на фильтрацию стало больше. В статье, помимо момента с TTL, показывается как посылать TCP RST с помощью Palo Alto, если у вас вдруг Palo Alto и вы ещё этого не знаете.

packetvis.com - сервис для мониторинга BGP ресурсов, не только собственных. Позволяет увидеть всевозможные ошибки, включая ошибки конфигурации, ошибки распространения, попытки перехвата, неверные настройки RPKI. Есть уведомления и API, нужна регистрация.

Детальный разбор уязвимостей роутера GL.iNET начиная от поиска до эксплуатации, название мне ни о чём не говорит, первый раз слышу, но смысл не в названии. Для каждой найденной уязвимости, приводятся также шаги с временными отметками от момента обнаружения, через заведение CVE, до выпуска устраняющей проблему прошивки. Но этого мало, во второй части автор разбирает остатки до винтика, ломая аппаратную часть.