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-х, а сейчас - это тотальный общий контроль над каждым узлом вовлечённым в сетевое взаимодействие и одновременно с тотальным недоверием к нему. Конечно без ИИ и машинного обучения никуда, и постквантовая эра где-то уже рядом ходит.

Значимые изменения в Python начиная с 3.5, напоминалка о сроках поддержки версий и полезные инструменты. Для тех кто просто использует то что стоит в системе и совсем не следит за внутренней кухней.

Проблемы безопасности RADIUS и что с ними можно сделать, точнее что не надо делать, не переходя при этом на TACACS+. Черновик возможного стандарта, который может и не станет стандартом, но проблемы все известные чтобы про все них прочитать в одном месте. Про PAP и CHAP тоже есть и про шифрование, от того же автора.

Про сложности валидации RPKI и как это исправить, презентация с JANOG54 от Job Snijders и Matsuzaki Yoshinobu. А так как это широко используемый механизм, но всё ещё в стадии внедрения, изменения лучше не пропускать.

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

Читаем стандарт 802.1Q и находим ответы на вопросы про native vlan, PVID, vlan0, vlan1 и hybrid links.

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