Отличная статья из двух частей с разницей в 9 месяцев про способы планирования адресного пространства IPv6. Описаны 4 метода, я бы разделил их ещё на два подхода, в которых подробно рассказано про преимущества и области применения.

Для меня не очень очевидным является последний - "случайное распределение", и не очень полезным предпоследний - "максимальное заполнение", который, как мне кажется, совсем не учитывает природу IPv6. В любом случае, в адресном пространстве будут зиять огромные дыры, но и количество адресов настолько огромно, что можно себе позволить зарезервировать префикс для каждого из 4096 виланов записывая его в десятичной нотации, а не в шестнадцатеричной. Примерно так я поступал когда планировал пространство /32, резервируя префикс под каждый порт коммутатора. После чего в какой-то момент осознал, что /32 становится тесноватым для моих планов :)

Стоит ли стремиться к поддержке непрерывности - да стоит, хотя уже сейчас в глобальной таблице маршрутизации BGP IPv6 почти 50% префиксов по /48 - максимальных из тех что рекомендуется маршрутизировать. В IPv4 количество /24 близко к 60%. Но экономить IPv6 не самый разумный вариант их действительно много и можно делать если не навсегда, то как минимум на ближайшие лет 10-15 точно. В статье приводится "разряженный" метод и пример, где под каждую задачу резервируется в 4 раза больше чем надо от самых максимальных потребностей.

И к этому очень быстро привыкаешь, потому что удобно, потому что взгляд цепляется за естественные разделители от цифры к цифре и двоеточиям. В IPv4 с этим было сложно, так-как префиксы (маски) не ложились ровно на десятичные разряды, потому что были двоичные. А изначальная задумка с классами адресов, где точка была естественным разделителем, очень быстро привела к исчерпанию адресного пространства. В IPv6 не так - проще человеку в том числе, визуально проще выделять структуры, даже не смотря на то что адреса стали длиннее, а считать приходится в шестнадцатеричных цифрах.

В продолжении темы адресации, конкретная практика: /48 на клиента, /32 на BRAS, 4-х кратный и 2-х кратный резерв.

Подробный и в хорошем смысле занудный разбор деталей обмена BPDU при изменении топологии в классическом 802.1d STP. Примечателен именно вниманием к тем деталям, которые часто опущены в OCG и недостаточно явно описаны в документации, но которые хорошо бы знать, чтоб понимать работу протокола не "для галочки".
https://www.chrisjhart.com/Deep-Dive-Spanning-Tree-Topology-Change/

И ещё большая, очень большая статья про все сложности NAT и не только - https://tailscale.com/blog/how-nat-traversal-works/, сегодняшний хит. Для тех у кого понедельник начинается в субботу.

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

Длина рулит, даже для только цифровых паролей. Если не использовать осмысленные сочетания, или тогда делать ещё длиннее.

​Сети это всегда сети и когда снимаешь всю луковую шелуху - докер превращается, превращается в iptables, бриджи и копии TCP/IP стека обёрнутые в пространства имён. Подробности в вебинаре 1 сентября на ipspace.net. Если работает, может не надо и трогать, а вот если не работает, лучше быть предупреждённым заранее.

Реализация алгоритма поиска наидлиннейшего префикса из заданных, то есть, задача поиска маршрута в таблице маршрутизации. Используется таблица маршрутизации Интернет. Статья, в основном, про программирование и конкретно про Pandas. Но выводы и результаты интересные в общем смысле для любого процесса.

Лучший результат 2 секунды, это невероятно много для любого практического применения, но цель статьи не в этом. Чтобы было быстрее, помимо аппаратной поддержки, это ещё и правильная организация данных.

Интернет это сеть или данные в нём? Если все думают что Интернет это Google, то почему бы Google не стать Интернетом? И почему только Google? Поэтому ничего удивительного что CDN, в частности, Akamai строят себе свои опорные сети. А Google заботится о телекоммуникациях не меньше, чем телекоммуникационные компании. И это логичное движение от потребностей - сверху вниз, потому что телеком гиганты как-то часто стали подводить.

DVMRP не самый часто используемый в современности протокол, интересно, что он в каком-то виде есть в XR, но удобный в том плане, что для RPF используется независимая таблица маршрутизации. PIM использует основную.

Пока нет заплатки Cisco рекомендует его фильтровать, не важно включен он или нет, атака пройдёт в любом случае если включена мультикаст маршрутизация.

Cisco нашли 0-day уязвимость высокой степени критичности в своей ОС Cisco IOS XR, которая стоит на коммутаторах операторского класса.

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

Уязвимости, которую обозначили как CVE-2020-3566, подвержены все устройства Cisco под управлением любого релиза Cisco IOS XR, если на нем включена multicast маршрутизация.

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

А пока нет обновления, Cisco выдала ряд рекомендаций по настройке своих устройств, дабы частично блокировать вектора потенциальной атаки.

Только в прошлом месяце Cisco устранила две критичные уязвимости, одна из которых могла привести к удаленному выполнению кода, и вот опять. Как говорится, что же ты, Иглесиас?

Инженерные истории про мультикаст и балансировщики нагрузки в Амазоне и в конце статьи конкретные выводы, которые можно сделать в своей работе основываясь на этом опыте.

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

Comcast рекламирует свой VinylDNS. Выглядит симпатично, обещает много, opensource, API, есть в списке инструментов у ISC. По хорошему, надо совмещать с IPAM и другими инструментами учёта, если конечно не делать сервис DNS ради DNS.

Забавная вещица, это даже, или пока, не эмулятор Cisco или чего-то ещё, это простейший эмулятор консоли Cisco, некоторых её команд. На ввод отвечает заготовленным шаблоном, конкретный шаблон для команды настраивается в текстовых файликах. Функционально - это повторитель-ответчик на пользовательский ввод. А куда кривая разработки дальше выведет, вопрос открытый.

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

Основательный разбор RPKI от ICANN, что к чему (но про это много кто пишет), а также риски и ограничения: технические, операционные - где стоит сразу подстелить соломки.

Больше документов, в том числе и на русском, с глубоким техническим анализом Интернет технологий, на самые злободневные темы от COVID-19 до 5G.

Красивый вывод - внутри bash, mtr и запросы к внешним БД.

⚙️ Asn - удобная утилита для отображения информации об IP и домене.

#будничное #tools #network

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

Мне кажется, что в сети нет более полного описания TLS на русском языке. Местами расписано до отдельных байт. И что радует отдельно - это не переводная калька с забугорных ресурсов, а самописный и поддерживаемый в актуальном виде документ. Есть даже описание режима CCM из TLS 1.3.
Без поллитры не заходить! TLS на таком уровне – это сложно.
https://tls.dxdt.ru/tls.html