Не все traceroute одинаковы, но мы ведь это и так знали. В iputils, так смутивший автора, сейчас одинаковые по поведению tracepath -6 и tracepath6, к которым можно добавлять опцию -p, чтобы конкретизировать порт на который отправится первый пакет и который будет увеличиваться на один с каждым новым пакетом. -p 33434 - сделает его похожим на классический traceroute, также это решит возможные проблемы с файрволлами, которые тихо фильтруют UDP порты за рамками возможных значений классического traceroute, поэтому эту опцию лучше использовать.
Для привычного traceroute, в моём CentOS Stream отдельный пакет, не стоящий по умолчанию, и в нём поведение traceroute -6 и traceroute6 тоже одинаково. Если хотите определённости - обновляйтесь и не смешивайте одинаковые утилиты из разных источников.

Cisco ClamAV, наконец-то, дозрел до версии 1, но с термином "свободный" надо что-то сделать :). В своё время, в списке рассылки для админов поддерживающих Centos репозитории меня удивило что репозитории в Иране не добавляют в общий лист, без каких-то других ущемлений - скачивай, обновляйся, держи локально, но иметь общедоступные для всех серверы в Иране нельзя, ибо юрисдикция США.
А так, я как-то раньше даже пользовался в связке с hMailServer для Windows, за неимением альтернатив.

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

На самом деле тут даже не доверие к техническим средствам, а доверие между людьми. Поэтому цепочка для пользователя выглядит не как подписанный сертификат, а как: "Я доверяю Chrome, а чему уж доверяет Chrome это его дело". Но скорее вот так: "Я доверяю Васе Пупкину, на самом деле мне просто нравится что он пишет, который на канале в Telegram написал что использует Lynx и поэтому я тоже его использую, а уж чему доверяет Lynx это его дело". Обязательно есть кто-то, кто вручную правит доверенные центры сертификации в системе и даже знает процедуры их аудита, но таких людей не много, правда же? Сообщество (с большой буквы) за всем следит, но Сообщество это и вы в том числе и Вася Пупкин из Telegram и команда аудиторов из больших и популярных бразуеров, а все вместе просто люди, которые склонны верить в теории заговоров.

Краткая история оптики от Geoff Huston с самого начала, через проблемы и технологии их решения.

Поиск проблемы с медленной загрузкой. Понять что это MTU и починить PMTUD, понять что это не помогло и починить снова, а потом ещё и причину найти. Взаимовыручка и профессиональная солидарность также присутствует, как и баги десятилетней давности. Очередной раз пройтись по граблям MTU - бесценно.

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

От проблем с 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/