Суть статьи про IPv6 в Docker в этом куске конфигурации:

networks:
  ipv6_native:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.gateway_mode_ipv6: "routed"
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 2001:db8::/64
          gateway: 2001:db8::1

При этом автор подчёркивает, что как работает маршрутизация и Docker вы должны знать и разбираться. Параллельно очень сильно хвалит IPv6, но тут можно пропускать.
Я, кстати, на днях сдался и запилил NAT66 с трансляцией /64 в адрес интерфейса. Для этого тоже термин PAT используется? Не хватило мне публично маршрутизируемых префиксов, а без IPv6 уже никак не работает.

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

Пример сложности внедрения IPv6 - сеть это ещё не всё, главное это ПО которое тоже придётся обновлять, в данном случае cPanel. Давно не встречалось этого названия, но хорошо что починили.

Как в IS-IS организована работа в общем сетевом сегменте с несколькими маршрутизаторами. Очень подробно, с выводамии из консоли каждого изменения и теорией графов в начале. Сравнение с OSPF тоже присутствует, и там почти также.

Никогда такого не было и вот опять - кто-то проанонсировал в BGP то что там не должно быть, некоторые это подхватили и проанонсировали дальше, а некоторые не справились и легли. Иногда, это даже специально происходит, порой хватало и длины AS_PATH, чтобы навести шороху. Про уже банальные утечки, происходящие почти каждый день, никто уже и не вспоминает. Интернет продолжает держаться на честном слове, как в прямом так и в переносном смысле. А на всякий случай, можно освежить в памяти мою статью про анализ BGP NOTIFICATION.

А давайте теперь про Eltex, заодно и Huawei помянем. Я, кажется, уже говорил что мне нравится Eltex, но работал я только с коммутаторами, так и не пощупав до сих пор ESR хотя видел его описание ещё в самых первых анонсах.
Но вот, наконец, я добрался и до него в уже достаточно зрелом виде. Оказалось, что Eltex ESR и Huawei AR почти близнецы если смотреть на логику организации CLI и предлагаемый функционал, они похожи больше друг на друга чем каждый из них на Cisco или Juniper. Конечно, видно кто чем вдохновлялся, но на мой вкус, получился странный конфиг-гибрид, и не строгий иерархичный Juniper и не двухуровневая плоская Cisco, уж слишком много строк где всего одно действие, но все они объединяются под общей функцией и не могут существовать отдельно, и слишком много оставлено за скобками в действиях по умолчанию, чтобы уменьшить количество этих строчек для удобства чтения.
Если уж вспомнили про Cisco, то ESR, это то чем можно заменить ISR и ASR1k - корпоративный сервисный маршрутизатор всё в одном. И когда я это понял я был в полнейшем восторге о чём даже написал коллегам, что наконец-то, то чего так долго недоставало у нас есть. Причём, говоря про Eltex, у нас есть вообще все классы сетевых устройств, чтобы построить моновендорную сеть на отечественном оборудовании.
Но потом я углубился, хотя то что я пишу это всё ещё первые впечатления, и значение WTFs/m стало достаточно быстро расти, значительно опередив Huawei. Не то чтобы прямо что-то не заработало, но когда ожидаемое для тебя поведение сильно расходится с действительностью, всё время натыкаешься на то что приходится перешагивать. Оно может быть даже правильным согласно многочисленным стандартам, но вот сложившаяся практика от этого поведения отличается. В общем, я умудрился сломать ARP, запутаться в логике выбора лучшего BGP маршрута для анонсов, и файрволе, который statefull между интерфейсами a'la ASA, а не между зонами, поэтому трафик приходится укладывать в линеечку в обе стороны всегда.
Huawei в своём поведении оказался предсказуемей, но у Eltex больше привычных Cisco фич, а у Huawei в принципе больше крутилок и сразу включены умные функции защиты, у Eltex выключены - это в плюс, кроме файрвола, который включен, а у Huawei, наоборот, выключен. Документация лучше у Huawei - помимо отдельных команд, есть полный и подробный пошаговый гид по очень многим функциям, Eltex старается, но пока до такого далеко.
В любом случае, Eltex - зачёт, как я уже сказал, все классы сетевых устройств в копилке есть, можно строиться и доводить ожидаемое до действительного.

Даже Windows 98 уже может в IPv6, запускать правда нечего. Надеемся на статью от автора с пояснениями.

Пятницу мы хоть и не пропустили, но вот ещё вдогонку.

Анализ украинского Интернет сегмента от Kentik на основе анонсируемых IPv4 адресов, количество которых уменьшилось на 18,5%.

Как обстоят дела с BGPsec сегодня. Фактически никак, хотя инструменты и реализации есть, но всё это пока эксперименты. Ни один из RIR не поддерживает, а это необходимое условие.

Azure не очень аккуратно работает со временем, если для вас это важно в пределах 0,1с - используйте NTP вместо PTP. С PTP не то что микросекундной точности, никакой точности не будет.

Установка соединения HTTP по шагам с дампами Wireshark. Что и в каких случаях будет выбрано и как на это можно влиять: HTTP/1.1, HTTPS, HTTP/2, HTTP/3.

Пошаговый проход алгоритма поиска кратчайшего пути сразу с сетевой спецификой и дампами отладки IS-IS. Это скорее не объяснение, а реализация, неплохое, неформальное и наглядное объяснение есть в Википедии. Лучше эту реализацию написать самому на любом из языков программирования, так надёжнее всего усваивается. Скорее всего, вас заставят её написать в учебном учреждении, если в нём вообще проходят алгоритм Дейкстры. Я писал, недавно, кстати, на Leetcode, правда там это был не оптимальный алгоритм, но руки вспомнили именно его.
Заметьте, что мы ищем не сами маршруты, все точки перехода, а только стоимость маршрутов и ближайшую точку перехода от начала пути - next-hop, третий элемент в структуре данных применяемой автором (R2). А следующую точку перехода и стоимость, посчитает уже следующий маршрутизатор.

Результаты эксперимента в целом положительные, отъехало обновление, что естественно, обновление баз файрвола в том числе, и публичная почта Outlook, как будто бы больше ничего. Из эффектов заметно повысился отклик системы, особенно в момент пробуждения и загрузки. А в итоге, всё кончилось тем что я уехал на Linux Mint, тем что ещё оставалось.

DNS в опасности настолько, что целый лендинг для этого замутили dnsatrisk.org. Технически, наверное, ничего нового вы из него не узнаете. Из предлагаемой к прочтению публикации, скорее всего, тоже. Удобный способ фильтровать доступ к информации, простой и надёжный как сам DNS, поэтому им пользуются все. Не самый надёжный правда, но первый в ряду. Есть ещё про фрагментацию Интернета, блокировку по IP и всякое другое с примерами.

Можно же техническую ситуацию назвать милой? Syslog на удалённый сервер, логов не видно. Через какое-то время отладки логи находятся в сыром виде. Рядом точно такая же железка работает нормально. Ситуация накалаяется из-за своей внезпаной непонятности, время течёт, количество вовлечённых инженеров растёт. Когда пришёл лесник и посмотрел очень глубоко - обнаружил записи в системе логирования от Января 1970 года и не настроенные часы на железке. Железка реабилитирована, жизненный урок получен вместе с хорошим настроением от понимания собственного непонимания.

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

Самые редко используемые подсети из диапазонов 192.168.0.0/16, 172.16.0.0/12 и 10.0.0.0/8. Метод не ахти точный, показывает то что используется, в основном, в домашних сетях - 192.168.0.0 вне конкуренции. Остальное тоже далеко не свободно, даже в этом исследовании. Нарваться на что-то занятое шансов, конечно, меньше в 10.0.0.0 и 172.16.0.0, но и они применяются весьма активно. Настолько активно, что достаточно многие выбирают адреса из 100.64.0.0/10 для назначения устройствам, чтобы наверняка ни с кем не пересечься, хотя и здесь нет никаких гарантий.
Из личной практики: 10.0.0.0 хотя и сильно больше, но именно из-за этого его и используют в провайдерах и корпоратах. А вот 172.16.0.0 встречается пореже, только выбирайте случайную, не очевидную подсеть, все удобочитаемые и рядом с ними будут заняты.

NLnet Labs выкатили набор утилит на Rust для работы с DNS, на своей же библиотеке domain, как замену своим же утилитам на Си. Есть для генерации ключиков и разных записей DNSSEC, подписи зоны и посылки notify и update. Документация присутствует.

Один день из жизни BGP. Графики, статистика по префиксам, автономным системам, кто сколько анонсировал в абсолютном и относительном выражении. В финале Geoff Huston вспоминает что BGP уже 40 лет, а он всё не меняется и всё также используется, и вероятно ещё долго будет.
Время напомнить про @FullViewBGPbot где актуальную статистику можно смотреть 3 раза в день.