Что можно увидеть со стороны, в аварии 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

"Суха, мой друг, теория везде, а древо жизни пышно зеленеет." Вы используете терминологию слоёв OSI, потому что вас этому уже научили, и все эти термины используют - в копилку мнений про нужность/ненужность OSI. В этом случае не учить OSI поможет конечно, но не сразу, а после того как вымрут все динозавры этому наученные. Стоит ли? А конкретики всегда можно добавить, общайтесь так как хотите, главное чтобы вас понимали. Работающим сетям, OSI точно уже никак не помешает.

Ругают Cisco с позиции бизнеса, акций и капитализации, но в конце есть что-то понятное - про зоопарк операционок, внутренних конкурирующих продуктов и лицензионный ад.

На какие адреса ссылаются домены второго уровня и кому эти адреса принадлежат, из тех зон до каких смог дотянуться автор (национальные в основном мимо), все лица знакомые:

AS16509 (AMAZON-02, US) (52.4M, 16%)
AS13335 (CLOUDFLARENET, US) (40M, 12%)
AS396982 (GOOGLE-CLOUD-PLATFORM, US) (31M, 9.5%)
AS15169 (GOOGLE, US) (19M, 5.8%)
AS58182 (WIX_COM, IL) (18M, 5.5%)

Кроме того, интересные моменты по использованию адресов из частного адресного пространства, IPv6 и следованию RFC.

Реализация протоколов маршрутизации на Rust. Сейчас OSPF, BGP, RIP. Какие конкретно реализованы RFC можно смотреть на GitHub. IS-IS в процессе.

BSD против Linux в тестах производительности. OpenBSD завести не смогли, зато FreeBSD и Ubuntu последних версий на месте. На разных тестах побеждают разные системы, так что поводов для холивара меньше не стало.

Кто никогда не работал с такой сетью - ничего не знает про сети, кто продолжает работать с такой сетью дальше - так ничего и не узнал.

Очередная серверная федерала. Ужас нах 😳

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