Являются ли сети сложными? О, да. Дело конечно не в консоли, это всего лишь интерфейс и будь у производителей воля отойти от стандартных Cisco или Juniper стилей (нет, не как это сделали в Mikrotik) то и в ней можно было бы избавиться от бесконечных повторений и накручивании связей вручную. Собственно, описанные в статье интерфейсы это и делают вываливая тысячи стандартных консольных команд скрывая их за политиками и объектами.

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

Я недавно прочитал книжку про переговоры из серии популярно и поверхностно про бизнес, но эта книга изменит ваше представление о мире. Там обычно много личных примеров вперемешку с нужными психологическими исследованиями и практиками известных компаний, которые подтверждают мысль автора. Я даже с ней согласился во многом, хотя с такой литературой в духе КО, сложно не соглашаться. Так вот одним из постулатов там был: "Не идите на компромиссы, лучше не совершать сделку чем пойти на обоюдные уступки. Обе стороны в этом случае окажутся в проигрыше". Поэтому вот вам попытка сформулировать основную теорему инженерии - всё компромисс :) и в этом случае с автором тоже сложно не согласится.

Если сравнивать в лоб чистый L2 сдобренный STP и LACP с VXLAN сдобренным EVPN, то VXLAN выглядит лучше. Конечно если вы сначала построили хорошую L2 сеть с LACP и STP, сверху хорошую IP сеть с ECMP и миллисекундной сходимостью, а потом вам опять понадобился L2, который уже можно построить с использованием VXLAN. И это всё к вопросу и желанию связывать все устройства со всеми напрямую и на любые расстояния, упрощая последний уровень абстракции для конечного потребителя (видимо программистов), но не всю конструкцию целиком.
А чтобы не быть голословным и о чём мне напомнил наш читатель, посмотрите на RFC 7980 и книгу https://www.amazon.com/Navigating-Network-Complexity-Next-generation-virtualization/dp/0133989356, то что вы возможно пропустили в предыдущем посте про сложность.

Наверное, со всей этой чехардой с RedHat и Centos, я опять вернусь к Debian, собственно на WSL у меня и так Debian, которая на фоне очень многих других выглядит незыблимо. Хороший повод отметить сегодняшний день.

Самому важному дистрибутиву современности сегодня стукает 30 лет.
По этому поводу даже пьянки в нескольких города самоорганизовываются.
https://wiki.debian.org/DebianDay/2023
P.S. Неделей ранее сусе стукнуло 18. Но кого это заботит вообще.

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

Подкаст про WPA3 в основном в сравнении с WPA2 и вторая часть WPA3 Enterprise. Для тех кто неплохо погрузился в WiFi и внезапно и удивительно пропустил всё про WPA3. Надо понимать терминологию и ориентироваться в технологии в принципе, тогда можно увидеть и дампы Wireshark с отличиями в нужных местах. Я почти всё загуглил и понял что проспал момент когда WiFi стал работать на 6ГГц. А ещё наличие поддержки совместимости с прошлыми версиями нивелирует все улучшения, поэтому если включаете WPA3 включайте WPA3 only.

Я хочу застать рейсы если и не Москва - Кассиопея, то как минимум еженедельные Москва - Луна. Даже если не в этот раз, то обязательно в следующий. Маск, тоже Твиттером занялся и про Марс говорить перестал. Не надо останавливаться никому, не останавливайтесь пожалуйста.

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

Всем инженерам и ученым от космоса во всех странах удачи, Роскосмосу не опускать руки ни в коем случае, и ставить такие миссии на поток, это была лишь первая в России, первая всегда с шишками.

Когда за дело берутся студенты математики, или не студенты, с формальными подходами к "эмпирическим" алгоритмам то может найтись что-то очень интересное. Например, что бывает что RTO (таймаут повторной передачи, рассчитываемый по RFC6289) может быть меньше RTT (времени подтверждения передачи). Как результат повторная передача, падение скорости и другие прелести приводящие к ухудшению параметров качества соединения. Конечно, как пишут авторы, это требует дальнейших исследований для выявления условий не возникновения таких ситуаций, а пока читаем оригинал статьи и смотрим на Github с реализованными моделями.

На недавно прошедшей Black Hat обратили внимание на BGP. Количество CVE последние годы с 2017 выросло, BGP везде, BGP старый, BGP не имеет встроенной безопасности, используемые реализации порой одного возраста с протоколом. Написанным BGP fuzzer, нашли ещё несколько DoS. Советуют не забывать обновляться, и это помимо всего остального о чём говорят в MANRS, RFC7454 и везде.

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

Карьера разработчика встраиваемых систем, если надоела текущая работа или если вы уже там сравнить со своими знаниями. Есть раздел про сети с ссылками на Youtube в основном, но уж очень с базовыми уровнем.

Немного практики Wireshark на примере отладки Zabbix, можно было бы сразу в настройки Zabbix посмотреть, но так не интересно же.

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

Ну что ж, инструкция как отключать IPv4 с помощью настройки DHCP опции 108 (RFC 8925) всё ещё объёмная и с большим количеством объяснений, историческими вставками и ссылкой на подкаст. Ждём когда появятся - "Нет времени объяснять, выключай IPv4".

Low Latency, Low Loss, and Scalable Throughput (L4S) RFC 9330 - наше счастливое будущее для всех, но это не точно. Описание подхода к уменьшению задержек до рамок 1-2мс в очереди и до 20-50мс из конца в конец в Интернете.

Основная предпосылка заключается в том что c очередями самими по себе всё в порядке, а всё дело в механизме определения перегрузок на стороне передатчика. Для этого нужна надёжная и объективная обратная связь, роль которой отдают старому доброму ECN, который обновили для этих целей до RFC 9331. Сеть при этом должна просто не мешать, всё работает на стороне хостов, но для этого надо выделить трафик работающий по L4S в отдельную короткую очередь, да и не забыть про тот трафик который не относится к L4S - RFC 9332. Сами протоколы очередей и контроля перегрузок существуют, их надо просто включить на хостах.

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

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

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

При этом безопасность вокруг почты, да и не только вокруг почты строится в DNS, а безопасность DNS строится на DNSSEC. И, конечно, никто не предоставляет эту опцию для твоего домена бесплатно, даже вместе с купленным доменом и хостингом DNSSEC дополнительная платная опция, я не могу утверждать что везде, но там где мне было удобно, потому что я там уже был или что-то покупаю или что-то использую - это так. Ладно думаю, не даёте DNSSEC я подниму DNS у себя, а у вас вторичные зоны подниму, но как вы догадались так тоже не сработало - DNSSEC - плати.

Порадовал только BIND, где DNSSEC включается одной строчкой конфигурации, всё остальное делается автоматически в последних версиях, настолько насколько возможно. Технически возможно всё, но для этого должна быть поддержка у вашего регистратора имен, поэтому что-то придётся понажимать руками периодически во время смены ключа подписи зоны. В любом случае я для себя этот момент закрыл в плане понимания глубины кроличьей норы точно. Я хотел привести какой-то всеобъемлющий график проникновения DNSSEC, но сходу не наткнулся на такой. Вот тут https://www.statdns.com для зоны COM выглядит всё печально, 6865629 подписанных из 159017162 всего - это 4%. С точки зрения проверки по DNSSEC всё выглядит немногим лучше, это тоже кстати одной строчкой конфигурации включается. Больше графиков вместе собирает Internet Society.

DNS, наверное, самый перехватываемый "легально" протокол и одновременно от него зависит почти всё в Интернете, а DNSSEC не нужен, как-то так.

Как-то приходилось мне копировать IOS через XMODEM, удачно но долго. Да и с D-Link тоже приходилось не раз. Через TFTP было бы быстрее. Но лучше не оставляйте флешку без нужного IOS.

У OSPF, iBGP и eBGP меняем AD, смотрим на результаты. Рассмотрено много вариантов, но не все, как минимум не понятно зачем у iBGP отдельная AD, когда всегда выигрывает eBGP. Это должно быть видно в случае когда есть IGP и iBGP маршрут без eBGP, тогда с оригинальной AD должен победить IGP. У автора такого варианта нет, IGP побеждает только eBGP с увеличенной AD.
В мире Juniper ситуация сложнее, как минимум там градаций гораздо больше.

Политики BGP для BIRD2, детальный, ооочень детальный разбор. Есть про всё, почти (про роли нет) - как фильтровать, очень много про то как фильтровать, как работать с пирами, апстримами и клиентами, IX, RPKI, комьюнити, препенды, приоритеты. И всё это с объяснением, мотивацией и ссылками на все ресурсы.
Это результат длинного пути, к этому приходишь самостоятельно рано или поздно, натыкаясь на разные косяки. Можно всё внимательно прочитать, принять к сведению и взять только то что считаете необходимым.

Сегодя и вчера все цитируют Ben Cox и его статью про проблемы с реализациями обработки атрибутов в BGP, да и вообще про подходы к обработке ошибок в BGP, когда сессия просто падает и фильтры при этом не очень помогают. Но честно, мы же про это знали, ведь такое случалось не раз и не два, и много-много ещё раз. В один год всё падало так часто, что я даже шестнадцатиричные дампы с листа читал.
Страшно на самом деле немного другое, что Ben Cox подошёл к этому прицельно со своим фаззером, в отличие от того что было представлено на Black Hat и бил знаючи и умеючи по больному месту, вскрыв проблемы в очень многих реализациях. И когда кто-то захочет сломать Интернет по-настоящему, у него это получится.
Если можете включить игнорирование ошибок в BGP, как говорится в статье - включите, но может быть от этого будет хуже, про такое в научных работах пишут: "Вопрос требует дальнейшего исследования". Остальным - удачи и обновлять свои BGP спикеры на исправленные, если можете.