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

К сожалению, 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.

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

Наткнулся на свежую статью про завершающую точку в конце доменного имени с которой всё просто в DNS где все имена начинаются от корня, той самой точки. Если она явно не присутствует её за вас поставит локальный резолвер, предварительно пройдясь по списку доменов заданных в системе и пробуя подставить каждый из них поочередно. А вот в HTTP(S) и всё что вокруг веба про её смысл как-то забыли и фактически имя в вашей строке браузера является не тем же самым именем которое фигурирует в DNS - это две параллельные системы. И, конечно, так как браузером непосредственно пользуются куда больше людей, то чем дальше тем больше с этой точкой проблем.
Про представление IP адресов тоже все уже давно забыли, и это тоже периодически порождает проблемы.

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

Пример настройки IPSec Site-to-Site с сертификатами вместо PSK для Cisco. В качестве центра сертификации тоже Cisco.

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

Не забывайте обновлять не только BGP спикеры, но и инструменты для анализа. Каким бы стабильным и основательным это всё не казалось, изменения происходят постоянно. Речь про RFC7911 и возможность анонсировать одинаковые маршруты и связанный с ним RFC8050 описывающий формат MRT.

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

Juniper открыл бесплатный доступ к обучающим курсам по программам JNCIS-SP,ENT,SEC - на выходе 75% скидка на сдачу экзамена.

Кстати, напомню ещё про очень крутые лабы от APNIC с живым оборудованием, полностью расписаны большое количество сценариев включая например SR, но можно идти не по ним, а просто использовать для своих нужд. Оборудование Cisco, Juniper, MikroTik.

Как-то раз я делал странную штуку, клиент захотел канал между своими точками присутствия, провайдерский BGP на PE и L3VPN его не устраивал. Меня позвал подрядчик от клиента, чтобы настроить промежуточные маршрутизаторы между клиентом и провайдером на которых поднимались туннели точка-точка поверх провайдерских с OSPF внутри. При этом имея доступ только к этим промежуточным устройствам пришлось очень сильно домысливать, как это всё настроено со всех сторон и на какие подводные камни это может наткнуться когда хотя бы один из туннелей отвалится. Поэтому если вдруг придётся дружить OSPF c BGP на участке CE-PE можно почитать вот этот PDF, в первую очередь провайдерам, для клиентов всё должно быть максимально прозрачно, подводных камней в этом деле достаточно.

История и будущее IPSec, куда его уже сумели встроить, обзорная статья в блоге APNIC.

То о чём так долго говорили в Qrator, теперь стандарт. Можно поздравить.

Новый RFC 9234 по защите от утечек маршрутов в Интернет разработан благодаря россиянам. Хоть где-то нас еще не выпиливают и не изгоняют!

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

Но так было не всегда, на своих парах в колледже в эпоху модемов нами разбирались протоколы MNP. Да и на практике у всех на слуху были v.32, v.34, v.42. Чуть позже в институте в курсе "Теории информации" под это дело была подведена теоретическая основа, но на практике это уже было вытеснено надёжными линиями связи и никаких реальных опытов делать не пришлось, впрочем, я учился не на связиста.

Когда из среды передачи выжимается всё, это и приводит к тому что надо быть готовым к ошибкам и эффективно исправлять их, а не только определять. Собственно, избыточное кодирование 8b/10b в 1G Ethernet и 4b/5b в 100M Ethernet как раз про это. Что в свою очередь говорит нам о том что наши линии связи в целом ненадёжны, хотя они это эффективно скрывают.