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

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

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

Товарищ скинул https://t.iss.one/habr_com/61393, я в ожидании открыл и сильно разочаровался. Самого главного ощущения от дефрагментации и тяжёлой работы, того самого глубокого звука диска, резонирующего в корпусе, проникавшего через стол прямо тебе в душу, который никогда больше не забудешь - к большому сожалению, передать не удалось. Сравниться с ним мог, наверное, лишь Norton Disk Doctor или Speed Disk, последний заставлял диски издавать такие звуки, что не в каждом фильме ужасов услышишь.
Помним и больше никогда не возвращаемся.

Cloudflare рассказывает как бороться с BGP утечками и перехватами на конкретном примере со своим 1.1.1.1/32, который произошёл 27 июня. Обратите внимание на временные отрезки, которые приводятся очень подробно, между фактическим началом проблемы (на самом деле двух проблем) и её обнаружением с заведением тикета прошёл час, а окончательно всё разрешилось через семь часов. Последствия были не сильно большие, в основном боролись с утечками и неправильным поведением фильтрации недействительных маршрутов по ROA и это всё не в инфраструктуре Cloudflare.
Помимо инцидента, подробно рассказывается про техники борьбы и подходы к обеспечению безопасности в мире BGP. Стоит обратить внимание на monocle если ещё не видели - это bgpdump на Rust стероидах.

Кто и как сканирует IPv6 в Интернет. Если про себя никак не заявлять, то может быть вас и не найдут, но заявлять обычно приходится. Исследователи так и делают, добавляют IPv6 адреса в DNS разными способами, после чего смотрят кто же их находит.

Распределение IPv4 префиксов по регионам, между RIR, по типам и по компаниям. Но тут всё должно быть знакомо. В России ресурсных записей IPv4 больше всего, но по количеству IP даже в десятку не входим, там главенствует США с 44% всех адресов, без DoD тоже никуда.

Атака на NAT маршрутизатора результатом которой является перехват правильного значения последовательности TCP и порта, а дальше, как говорится, дело техники. Тут конечно опять маршрутизаторы подвели, которые ничего не проверяют и всё упрощают и таких много. Для проведения атаки надо быть в локальной сети и это не обязательно Wi-Fi, но авторы проверили на нём и нашли, что в 75 из 93 локаций их атака успешна.