Патчкорд

Интернет управляется через почтовые списки рассылки, а этими рассылками управляет Mailman, первая версия которого появилась в 1999 году. RIPE NCC решили переехать на третью версию со второй, говорят что ничего сломаться не должно.

Starlink как замена, даже проводного провайдера, вполне рабочее решение, особенно при наличии соответствующей наземной инфраструктуры у самого Starlink. Конечно не везде и не для всего, необходимо учитывать и нюансы работы приложений. Отдельно рассматриваются облачные игры и видеоконференции. Оригинал публикации, где всего больше.

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Как и обещал, в заключении серии постов про тестирование 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

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

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

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

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

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

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