rule11.ac - сетевая академия от Russ White, что-то доступно просто, что-то после регистрации, есть видео, есть тексты. Всё ещё в самом начале и в процессе наполнения.

Про управление трафиком в Segment Routing, обзор от облака Яндекс. SR, кстати, больше 10 лет уже, можно посматривать краем глаза, пока что-то новое не придумали.

В день запуска IPv6 традиционные гадания по Гуглу по скорости внедрения. В прошлом году не дотянули до 45%, в этом году слегка перевалили за 45%, если сравнивать со стабильными 5% в год, то можно сказать что рост замедлился, в этом году должны были 50% достичь, 4 года назад было 30%. Возможно, что и в следующем году не будет 50%, но должно быть близко. Кто хотел, тот наверное нашёл, а кто не хотел, того догонит и может быть мы ещё увидим лавинообразный переход, когда поддерживать такое состояние вещей станет невозможно, но пока IPv4 в глобальном масштабе больше.

Если заходите на radar.cloudflare.com, у них тоже есть статистика по проникновению IPv6, помимо прочего. Так, например, можно видеть как резко стало расти количество запросов с использованием постквантовой криптографии. А с IPv6, по их оценке, всё хуже чем по оценке Google.

Эээх, пропустил я вспышку с Centos 8-stream, да ещё как, на целый год, и теперь с 31 мая любые обновления по базовым репозиториям превратились в тыкву:

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

На mirror.stream.centos.org, в принципе, больше нет директории 8-stream, но в системе зеркал каталог ещё остался с одним файлом readme следующего содержания:

This directory (and version of CentOS) is deprecated.

Последний слепок есть на vault.centos.org и если поправить и активировать ссылки baseurl в соответствующих файлах в /etc/yum.repos.d/, то эти замороженные последние версии можно будет получать через dnf или yum, что восстановит работу с базовыми репозиториями, естественно без любых обновлений и исправлений.

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

Internet Society про изоляцию Интернет в России, общий обзор того что происходит, в основном, про последние два года. Ничего нового, но много ссылок, некоторые из которых недоступны из России (sic!), на исследования и публикации всякого рода. По собственным оценкам Internet Society, до изоляции очень далеко, особенно если ориентироваться на объективно измеряемые технические параметры, о чём в статье и говорится прямым текстов в самом начале: "Россия не Китай и практически невозможно изолировать Россию в Интернете". Что-то, конечно изменилось, как со стороны России так и с другой стороны, эти примеры приводятся, включая недавний закон о запрете публикации информации о средствах обхода блокировок. В конце призыв ко всем о защите Интернета который мы знаем, но сдаётся мне, что как было уже не будет.

Как сделать snapshot UFS во FreeBSD, пошаговая инструкция.

Microsoft про сайт-приманку на code.microsoft.com, конечно, сначала он не был приманкой, а просто сайтом с которого перенесли сервис и забыли и его реально смогли поэксплуатировать злоумышленники. А то что сайт является сайтом-приманкой было раскрыто этой весной, поэтому проект свернули.

Что можно увидеть со стороны, в аварии DNS, вызванной DoS и почему не стоит пренебрегать коллективным опытом заключённым в RFC, а ещё что-то про облака.

"DNSSEC не нужен?" - по версии Geoff Huston. TLS обскакал DNSSEC в одном из решений для обеспечения запрашиваемого уровня безопасности, а DNSSEC не смог предложить ничего лучшего за прошедшие 30 лет и всем в общем-то уже всё равно, что DNS небезопасен.

Береговая станция давно анонсируемого и продвигаемого проекта оптики по Северному Ледовитому океану - ПВОЛС "Пролярный экспресс" - попала в объектив одного из сподвижников нашего чата - @ATroyansky

Пишут, что первый этап Полярного экспреса от береговой станции Теребирка Мурманской области, что на фото, до Андермы Ненецкого автономного округа длиной в 650 км построен осенью прошлого года. Сейчас строят второй этап Дикси - Андерма. Завершение запланировано на 2026 год. Но здые языки говорят, что будут задержки и завершение перенесут на 2028 год.

Кабель для Полярного экспресса идет в дело свой. Завод по его производству построен в Мурманске - https://xn--e1ahdckegffejda6k5a1a.xn--p1ai/novosti/v-murmanske-otkryli-zavod/. Усилители, как пишет википедия, делает ИТМО - ранее Ленинградский Интститут Точной Механики и оптики. А вот про каналообразующее оборудование ничего не нашел. Плохо искал или пока не определились?

Корче, работа идет. Не так быстро как хотелось бы, но идет. Это вам не мелочь у родителей тырить.

Удивительно, что глобальные проекты так редко попадают в ифополе, единственная новость на сайте за два года https://полярныйэкспресс.рф/#novosti и гадай - нет новостей потому что некогда, работаем, или нет - потому что всё забросили. Хорошо что есть кому ножками дойти.
Соседний проект https://www.farnorthfiber.com/ такой же проблемой страдает, там тоже с новостями негусто, последние от прошлого года ищутся.

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

RIPE labs презентует интересную работу, про то как поменялся Интернет за последние 20 лет, в котором повторяется исследование, собственно, двадцатилетней давности. Сама работа доступна по подписке.
Основные выводы остались: Интернет и используемые политики BGP это не про кратчайшие пути это про деньги и другие мотивы операторов автономных систем. Но сами характеры этих путей изменились - пиринг всех со всеми пришёл на смену иерархии и виноваты в этом, по мнению авторов, точки обмена трафиком. Да и в целом, всё стало гораздо запутаннее.

Если вы спрашиваете: "Зачем вам нужен IPv6?" - то вы подходите к вопросу не с той стороны, потому что IPv6 это уже ответ, к которому вы приходите решая какую-то из ваших проблем: инженерную или бизнес. Если у вас таких проблем нет, для которых нужен IPv6, то и IPv6 вам не нужен. Привычный ответ на вопрос: "Зачем нужен IPv6 контент-провайдерам?" - потому что NAT ухудшает сервис. Но контент-провайдеры могут считать по другому, насчёт своего сервиса.

Конечно, таким не хвалятся, как и аптаймами железок, но что уж есть, то есть, CVE-2024-6387 - мимо:

- OpenSSH < 4.4p1 is vulnerable
- 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable
- 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again

Несмотря ни на что - обновляйтесь вовремя, даже если потенциальная возможность атаковать именно вас, кажется незначительной.

Взгляд зацепился за статью про тесты IPSec от Red Hat, в которой я так и не понял зачем они приплели туда AES-SHA1 если всё равно все плюшки показывали на AES-GCM-128, на котором в параллельном режиме, программно, вытащили всю ширину доступной полосы. Нет напрашивающегося сравнения с AES-SHA1, для которого приведён только однопоточный тест, даже без указания загрузки CPU, что вызывает подозрение.
SHA1, конечно, лучше не пользоваться, но наверняка если GCM нет, то уж SHA256 должен найтись, но тесты производительности, в этом случае, Red Hat оставили на нас самих.

Кстати, как работает AES-GCM, много и подробно с интерактивными примерами.

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

Как и обещал, в заключении серии постов про тестирование EVPN-MPLS с Active-Active на IRB, пишу про результаты нагрузочных тестов.

Особенность тестирования:
Первоначально пускаем 1 Гб/с по ранее описанной методике и в прогрессии увеличиваем.

Заметили, что при достижении трафика 5% от максимального, т.е. 5Гб/с, получаем потери.

Связано это с тем, что обрывается LDP сессия.

PE2-MR381 : LDP : CRITI : [LDP_SESSION_DOWN_2]: Clearing up session on interface ce5 with peer 20.0.0.2"

А она обрывается, потому что CPU немного устал...

PE2-MR381 : CMM : CRITI : [CMM_MONITOR_CPU_CORE_2]: CPU core usage in Critical Level.[Threshold 80% Current usage 80.119%][bgpd:66.052%, zNSM_ASYNC:55.699%, bcmINTR:52.244%]

ну и на десерт IS-IS + BGP разваливаются

PE2-MR381 : IS-IS : CRITI : [ISIS_OPR_ADJ_STATE_2]: ADJCHG: Tag UNDERLAY, Nbr ce5-0001.0000.0002 on ce5: LAN Neighbor Up to LAN Neighbor Down, HoldTimerExpired.

PE2-MR381 : BGP : CRITI : [BGP_OPR_NEIGH_STATE_DOWN_2]: Neighbour [20.0.0.2] Session down due to Hold Timer Expiry

И что делать? Коробка должна гнать 2.4 Тб/с, а умирает при 5 Гб/с...
Как бы очевидно то, что исходя из проблем выше, транзитный трафик идущий на IRB, попадает на CPU, чего очевидно быть не должно.
Пообщались с вендором, ребята всё это дело зафиксировали, собрали инфу, подтвердили в лабе. Выяснилось, что при таком сценарии, все UDP пакеты попадают в очередь ведущую прямиком на CPU. А вот с TCP всё отлично работает и таких проблем нет. Интересно то, что мы в данном тесте не пытались менять дефолтное поведение TREXа, т.к. нам были не важны вложения и достаточно было той энтропии, которая в итоге получалась, а он то как раз всё шлёт как UDP :)

В общем баг зафиксировали, в ближайшее время будет фикс, ориентировочно к концу Q3 2024.

На всякий случай, проверили результаты с TCP и переделали наши потоки.

При максимально возможной нагрузке (~95 Gbps) - потерь нет.

На этом историю про тестирование MR в контексте EVPN-MPLS завершаю, вернусь после выпуска фиксов и повторим.



P.S. Если вам нравится мой канал, расскажите о нём тем, кому это тоже может быть интересно. Ваша поддержка очень важна для меня. Спасибо!

#импортозамещение #цод #коммутаторы #маршрутизаторы #vxlan #mpls #b4com