​В AWS сделали странное, но уже исправились. Всё что попадает в Интернет, там и остаётся - репозиторий в котором можно посмотреть за историей используемых AWS префиксов c 2017 года.

Возвращаясь к вчерашнему BGP Flowspec, мне подсказывают, за что огромное спасибо вам, ещё вот про эту статью из реальной практики. Она немного суховата и более сжата, без обучающего момента, надо быть готовым понимать или знать контекст, хотя бы приблизительно. Оборудование тоже Juniper.

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

Одна из тех многих вещей которые мне не даются легко. Посчитать MTU для меня - мука. Но, похоже, счастье есть - https://baturin.org/tools/encapcalc/

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

IPv4 адреса которые были перепроданы на свободном рынке, часто, чаще чем остальные, являются источниками вредоносного трафика. Статья на labs.ripe.net.

Среди автономных систем, те которые участвуют и в приобретениях и в продажах чаще являются источниками вредоносного трафика, чем те кто только покупает или только продаёт.

Кроме как на рынке много IPv4 адресов уже не найдёшь, поэтому покупайте в проверенных местах или мойте их с мылом после покупки.

Отличная статья из двух частей с разницей в 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 заботится о телекоммуникациях не меньше, чем телекоммуникационные компании. И это логичное движение от потребностей - сверху вниз, потому что телеком гиганты как-то часто стали подводить.

Важная новость. Проект OpenWifi
https://github.com/open-sdr/openwifi

Добился задержки RTT в 0.256 ms.

Ещё раз. ВАЙФАЙ С ПИНГОМ НОЛЬ ЦЕЛЫХ И ДВЕСТИ ПЯТЬДЕСЯТ ШЕСТЬ ТЫСЯЧНЫХ СЕКУНДЫ, КАРЛ!

Вот тут есть видосик с пруфом.
https://youtu.be/Notn9X482LI


Признаюсь честно, я раньше скептически относился к данному проекту. Но пересмотрел свою оценку и весьма вероятно он выстрелит (по моему мнению).
К тому же, это пока единственная возможность дать по носу вендорам, скрывающим всё что можно в firmware и ведущим себя как слон в посудной лавке (Да, я снова про Интел).

Фактически, из полигона для исследователей проект превращается в реальную альтернативу коммерческим продуктам.

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. Заранее готовится произвольный ответ и оценивается реакция на него.