Забрал сегодня второй том (справа), первый мне не дался, но останавливаться на полпути я не стал. Покупая в 2020 году первый том, я не подумал что он первый и всё самое интересное, включая сети, окажется во втором. Книга мне не зашла, при том что изложено всё дотаточно скурпулёзно, но на мой взгляд, перегружено деталями для неподготовленного человека. Это справочник, в котором нет движения от общего к частному, каждая глава отдельная тема. При том явно говорится, что в открытом виде архитектура Windows нигде не публиковалась и все сведения, которые вы получаете, используйте на свой страх и риск.

Второй том я захотел купить сразу же, но его не было, он вышел только в 2021 на английском. Я просматривал раз в полгода-год наличие перевода и вот, наконец, купил. В введении меня сразу обрадовали:

"Рассудив, что главы о взаимодействии с сетью и анализе аварийных дампов неактуальны для современного читателя, вместо них он (Andrea Allievi) добавил совершенно новое описание Hyper-V"

Актуальность материала книги приходится на момент Windows 10 2103, 21H1, включая Windows Server 2019 и 2022. Что неплохо для книги и достаточно для понимания идеи заложенной внутри ядра.
Ожидания у меня такие же как и от первого тома, будет тяжело и непонятно, что-то я в любом случае почерпну, но для полного понимания надо работать с Windows на системном уровне, со мной этого не случилось.

Состояние дел с RPKI за 2025 год, в сравнении с 2024 от Job Snijders. Записей больше, среднее количество префиксов на одну подпись стремится к единице, время проверки больше. ASPA, вероятно, окончательно опубликуют до конца года, вендоры тоже стараются в этом направлении.

Про IPv6 мы и сами всё знаем. Как это выглядит в цифрах для разных типов объектов в Интернете для первого миллиона доменов, включая MX и NS записи. Особенно печально выглядят IPv6 only строчки.

Истории давно забытых дней от Ивана Пепельняка, про MPLS его скорость и при чём тут ATM. Когда решение очень конкретной проблемы вылилось в то что мы видим сейчас. И да, раньше было не лучше.

Домашняя страничка-блог стилизованная под man pages. Выглядит аутентично, правда не уверен что будет практична и удобна при чтении, написано на Python.

Как Netflix переезжает с full mesh iBGP на Route Reflector'ы. Всё по учебнику - решаем проблемы масштабируемости, гибкости и управляемости для тысяч маршрутизаторов. Два момента. Да, Netflix делают это сейчас, в 2026 планируют закончить, к вопросу, что любой метод который вас устраивает является рабочим, кто бы и что не говорил.

Второе, в парадигме Network as Code, Software-Defined Networking ввод умной сущности усложняет нам задачу. RR это "умный" исполнитель, который надо отдельно учитывать и который самостоятельно принимает решения по другим алгоритмам, нежели обычный маршрутизатор. Мы должны заиметь отдельный шаблон и написать отдельную логику, синхронизировав её с рядовыми iBGP устройствами. Без RR, этого всего не надо делать, единственное наше ограничение это количество поддерживаемых iBGP сессий на конечном устройстве. Нашему программному коду всё равно, сделать их 10 или 10000, на 10 или 1000 маршрутизаторах, главное чтобы ресурсов хватило. Чем, условно, площе сеть, тем линейнее и проще наш код, не будем даже про ИИ вспоминать. Вам всё равно не надо разбираться в конфигурации устройств, одним взглядом не охватить всё, достаточно видеть массив с количеством элементов и привязанным шаблоном, или отчёт где все тысячи строк конфигураций скрыты за цифрой с их количеством и поднятыми сессиями.
Есть правда вопрос с доступностью самих устройств для внешнего управления, потому что без сети, которую мы настраиваем, мы не сможем управлять устройствами. В этом случае, конечно, выгоднее иметь как раз умное и самостоятельно поведение, заложенное в протоколах маршрутизации и их алгоритмах. С другой стороны, независимая сеть для управления вопрос бы решила.
У Netflix есть автоматизация, про неё во второй части презентации, как они её используют для миграции, но они решили что им нужен RR.

Кто, как и с кем коннектится из Tier 1, со многими авторскими допущениями и интерпретациями исходных данных. Скачиваем BGP дамп и строим табличку, примерно вот такую.

Эмулятор RISC-V RV64GCV/RVA23 на Object Pascal. Чтобы попробовать сразу идите в этот репозиторий с фронтендом. Для компиляции нужны будут актуальные версии Free Pascal и Lazarus или Delphi.

Поиск промежуточных устройств, вносящих изменения в трафик, в голландских сетях. Искали с помощью yarrpbox, сырые данные тоже приложили, и нашли в 4% случаев. Дополнительно определили тип устройств и геолокацию и это далеко не всегда Голландия. Кажется странным что так мало нашли с учётом всех характеристик, и это не потому что в России цифра стремится к 100%. Файрволы и различные системы защиты, внешние в том числе, есть у многих и это вполне легитимные устройства.

Лабы уровня CCNA/CCNP. Есть под разные платформы, в том числе Packet Tracer и EVE-NG.

Программный BNG/BRAS и GitHub, в начальной стадии разработки. Много чего нет, но с другой стороны много чего уже есть: авторизация и политики. NAT нет, да здесь он и не нужен.

В MANRS бились-бились с провайдерами, поняли что дело гиблое и надо бы подтянуть всех остальных, для чего придумали MANRS+. Аргументация железная - вы зависите от путей в Интернет и если сами не позаботитесь об этом, то никто не позаботится, не стоит ждать милости от провайдера, вы от него и так сильно зависите. Документ не длинный, но можно чуть короче почитать в обзоре APNIC.

Контроль перегрузок в сети - непростая тема. Автор не делает её легче, скорее наоборот, делает её сложнее добавляя матана, в попытке разобраться как работает контроль перегрузок NSCC в Ultra Ethernet.

Быстрый файрвол в eBPF, но простой, может только откидывать трафик. Конфигурируется из консоли и json файлика.

Опубликован RFC9848, чтобы TLS сразу шифрованным стартовать и не светить SNI, для чего добавляется параметр ech в DNS записи SVCB/HTTPS. Обязательно к прочтению секция безопасность, там сразу расписано как это можно обходить и будет обходиться.
Второй момент, DNS и Web инфраструктура и так очень разные, в разных плоскостях управления, а тут их надо очень сильно связывать и поддерживать синхронизацию. Но главное, привязка к DNS без DNSSEC не имеет смысла, а его исчезающе мало.

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

Как поживает RIPE Atlas: трафик, где и сколько пробников стоит, кто делает больше всего измерений.

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

У Лю Цысиня в "Вечная жизнь Смерти" есть момент где человечество пытается оставить о себе хоть какой-то памятник во вселенной и приходит к выводу что единственный вариант это высечь послание на камне, но человечеству это не помогло никак. У меня почему-то такие же мысли навевает список каналов в Технологическом Болте Генона, куда попал и @patchcord. Там мало каналов про сети, поэтому я покажу свой список для чтения (не реклама 😎), в порядке давности последнего поста в этом году, хотя не скажу что здесь про сети сильно больше, чуть-чуть пересекается.

https://t.me/opennet_ru
https://t.me/drussia
https://t.me/VPCBrief
https://t.me/ntwrkchnnl
https://t.me/count0_digest
https://t.me/zabbix_ru
https://t.me/theaftertimes
https://t.me/Telecomreview
https://t.me/PR_machine_Nika
https://t.me/linkmeup_podcast
https://t.me/abloud62
https://t.me/monitorim_it
https://t.me/SysadminNotes
https://t.me/alukatsky
https://t.me/jtprogru_channel
https://t.me/tech_b0lt_Genona
https://t.me/bykvaadm
https://t.me/letitkit
https://t.me/zhovner_hub
https://t.me/RUSmicro
https://t.me/rtc_dc
https://t.me/kipchat
https://t.me/sysadm_in_channel
https://t.me/troubleperf
https://t.me/ntwrkmms
https://t.me/kosdevs
https://t.me/dataix
https://t.me/aws_notes
https://t.me/ieucariot
https://t.me/like_a_bus_channel
https://t.me/life_of_network_engineer
https://t.me/netscripor
https://t.me/thirdpin
https://t.me/shitsch
https://t.me/RusTelco
https://t.me/noc_announces
https://t.me/netautomation
https://t.me/YandexNextHop
https://t.me/terrible_telco
https://t.me/piterix
https://t.me/version6ru
https://t.me/spblug
https://t.me/linstoria
https://t.me/architect_says
https://t.me/NetArchNotes
https://t.me/qrator_radar
https://t.me/netbsd
https://t.me/curatorpro
https://t.me/r9yo11yp9e
https://t.me/mtikpro
https://t.me/manandthemachine
https://t.me/hadal_project_channel

Как ни беги, никуда от инфраструктуры не убежишь. Только-только всё утрамбовали в облака, но тут приходит новая парадигма ИИ и сети надо перестраивать заново.