Вчера был день резервного копирования, а также "Вчера" - правильный ответ на вопрос "Когда вы сделали последний backup?". Про вчерашний день я забыл, а вот резервные копии сделал и вы тоже сделайте, а лучше несколько раз, а потом ещё и проверьте дважды.

Наконец, я добрался до починки Twitter и поэтому в моей домашней инфраструктуре появились SOCKS5 и HTTP прокси и Tor. Мне не сильно нравится такая схема, но то что у меня есть вокруг IPv6 в случае Twitter неприменимо, потому что у Twitter нет IPv6. Я ещё не заглядывал в ленту, но зато починил @BGP-TableBot, хвала requests который умеет SOCKS5 и может подтягивать данные прямо из переменных окружения, так что ничего дописывать и переписывать не пришлось.

Чтобы в принципе исключить зависимость от Twitter я вернулся к мыслям считать статистику по BGP самому, поэтому сделал ещё одного бота @FullViewBGPbot, который берёт данные из RIPE NCC RIS, своего full-view у меня к сожалению нет. По причине ограниченности ресурсов на VPS, только с одного Московского коллектора rrc13, наверное через какое-то время я вернусь к этому вопросу и допилю все остальные. Пока это черновик, мне не очень нравится в попыхах написанный код, корявые фразы и картинки, но тут я в силах это править и буду этим заниматься время от времени. Отзывы и комментарии приветствуются, поддерживаться будут оба.

А вот замены Twitter как новостной технической ленты у меня нет, и это напрямую сказалось на наполняемости канала, но больше конечно это резко возросшая необходимость много чего сделать и переделать, планировать и перепланировать. Я по прежнему получаю удовольствие от того что делюсь интересными вещами с вами, поэтому постараюсь это делать, по мере своих возможностей. Надеюсь скоро их будет побольше. Они у меня копятся и то что останется актуальным обязательно здесь окажется.

Запущен новый туннельный сервис Route48.org: https://lowendspirit.com/discussion/4059/route48-org-ipv6-bgp-enabled-tunnelbroker-service

На выбор предложено 15 локаций, в том числе довольно экзотические в Южной Америке и Юго-Восточной Азии.
Для России вероятно ближе всего окажутся Норвегия или Нидерланды.

Каждому пользователю выделяется подсеть /48, также есть поддержа анонса собственных адресов через туннель посредством BGP.

https://route48.org/

Если вы ждали знака чтобы реализовать поддержку шифрования ГОСТ в IPSec и X.509, то вот он - RFC9227 и RFC9215

Пошаговый разбор установления соединения QUIC, рядом про TLS. Для нескучного вечера пятницы.

Такой близкий, но такой далёкий SS7 и как он уживается с IP. Не вполне законченная серия из 5 статей про теорию телефонных сетей SS7 с лабами на GNS3, я думаю автор её продолжит, хотя и взял паузу. Все примеры строятся на аналогиях в IP сетях, поэтому должно быть понятно, погружение в настоящий, кондовый телеком.

Segment Routing в массы, если вы ещё не добрались до классического MPLS TE, то имеет смысл его пропустить и начать сразу с SR. Как всегда, хорошее введение от Chris Parker для Junos в двух частях. Для Cisco можно начать с этого вебинара и даже на русском, правда теперь, только через vpn/webproxy/etc.

"Простой" домашний роутер всё равно роутер и не такой простой, особенно если твой дом пытается быть умным или вообще не отличим от офиса. Термин SOHO как раз про это, хотя на рынке, всё же, присутствуют отдельные классы домашних и офисных маршрутизаторов. Поэтому не удивительно, что требуемый функционал SOHO роутера для построения домашней IPv6 сети описан не одним RFC, обзор которых приведён в блоге APNIC.

Немного очевидных и не совсем очевидных примеров использования команды show в Cisco IOS и похожих интерфейсах. Последнее время я очень привык к section, в основном из-за ACL где хочется видеть комментарии и поэтому приходится дёргать конфигурацию, благо, в современных IOS нумерация правил хранится прямо в ней. Вся мощь это, конечно, полноценные регулярные выражения, но полноценных pipe, не ограниченных одним переходом, всё же не хватает.

У нас часто появляются новости о внедрении RPKI и ROV, однако вот это мы пропустили - доля покрытых подписями прификсов в регионе RIPE превысила 50% и в IPv6 то же, и это случилось ещё в прошлом году. Оригинальный график взят из rpki-monitor.antd.nist.gov. Помимо него там ещё куча всякой статистики, по которой RIPE достаточно сильно обгоняет все другие RIR. Разбивки по странам нет, мы знаем что есть страны со 100% покрытием, зато есть TOP25 по AS куда попал Ростелеком AS12389.

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

Как всегда, наиподробнейший обзор от Geoff Huston итогов 2021 года в IPv6 Интернете. Статья начинается с самого начала, с 1992 года, на случай если вдруг читатели совсем ничего не слышали про IPv6. Для всех остальных, возможность сверить часы до момента полного перехода на "новый" протокол.

И вдогонку хороший FAQ по многим заблуждениям IPv6 от Tailscale.

Никогда не поздно заняться безопасностью, тем более имея пошаговую инструкцию от NSA для Cisco. Там, на самом деле, ничего нового, то что все знают, но от этого важность этих вещей меньше не становится. Сделайте себе SNMPv3 - это не сложно, мы используем. Включите аутентификацию на BGP, а вот с этим почему-то проблемы, например, PSK для IPSec никого не смущает согласовывать, в котором кстати не следует использовать старые протоколы шифрования, а по поводу BGP делают удивлённые глаза. Выключение неиспользуемых портов и виланов, пальцы должны автоматом набирать, как и многое другое, что надо сделать чтобы хоть немного быть уверенным в своей сети.

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

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

И ещё немного технологий из прошлого. Я вскользь коснулся нескольких, многие что перечислены не вызывают у меня чувства ностальгии, конечно, исключая семиуровневую модель OSI, которая непонятно что в этом списке делает, и Novell NetWare. Но кому-то может будет больше знакомо, это к вопросу о том как много разных вещей происходит и изобретается каждодневно и как мало может быть известно отдельному человеку. Конечно, многое что было изобретено не исчезает бесследно, а становится частью чего-то другого, в виде идеи или даже реализации.

Почему самый первый ping в Cisco IOS терпит неудачу - сначала, все базовые принципы обмена данными в Ethernet/IP сетях, которые всегда полезно освежить в памяти тем кто про них знал. А потом, попытка найти причины этому - почему сделали именно так, а не иначе, с минуткой исторического экскурса.
Интересный момент который упоминается, но не затронут сам по себе, то что вся процедура по всем уровням занимает очень много времени, больше 2 секунд. Это плата за работу центрального процессора, который должен сформировать пакеты с одной стороны, понять и сформировать ответ с другой стороны, а потом принять и понять ответ. И, в общем случае, его работа непредсказуема. Но первый запрос теряется далеко не везде.

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

Интересный открытый вопрос про современные сети: "Почему, во многом, они работают по старинке?" У нас есть относительная гибкость внутри облака, мы этим можем управлять наравне со всем остальным в едином процессе CI/CD. Но сложности возникают когда надо пропустить трафик через реальный мир и тут, на мой взгляд, мы упираемся в технологии (это вторая опция предложенная автором).

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

А что в сетях, за пределами внутриоблачных систем? У нас есть API, у нас есть верхнеуровневые гибкие архитектуры вроде SD-WAN и SD-LAN, но под этим всем лежат всем нам знакомые технологии и протоколы, в которых нет ничего такого, что нельзя было сделать руками, сложность только в объёмах абстракций чтобы создать 100500 VRF, виланов и маршрутов. По сути, всё что нам предлагают не новый подход, а вендорская оркестрация старого. И тут мы упираемся в то чего мы не имеем - кратного запаса ресурсов. Сколько угодно можно делить физическую магистраль добавляя оверлеев, но там где нужны 10 портов, нужно 10 портов и миграция не заключается в копировании настроек и данных, надо менять топологию. Мы видим запас по мощности в ДЦ с повсеместным CLOS, где мы также видим и наибольшую гибкость в сети как основу облаков и всех сетевых абстракций, пусть и не универсальную как того хочется автору. Но весь запас тут же улетучивается если вы не можете строить свои магистрали с кратным запасом между ДЦ, как раз отсюда и растут проблемы отсутствия универсального API между вендорами.

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

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

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

У Juniper и IOS-XR есть commit confirm , а у Cisco IOS есть config revert. Предварительно придётся настроить archive на локальный носитель иначе весь смысл теряется, но в любом случае это должно быть лучше чем reload in. Для меня открытие, теперь буду читать что там ещё есть кроме configure terminal.