Стоит или не стоит использовать MPLS вопрос странный, так как любой задаче нужен свой инструмент. Поэтому сравнение "в лоб" не всегда корректны, но всё же вот тут сравнили IPSec, "чистый" MPLS и чистый роутинг https://www.802101.com/is-mpls-faster/
www.802101.com
Is MPLS faster?
Is MPLS faster? Comparing speeds of OSPF and IPSec VPN to MPLS in EVE-NG. #MPLS #OSPF #VPN #CiscoChampion
Forwarded from likeabus channel (Sergey Bocharnikov)
Как и обещал, в заключении серии постов про тестирование EVPN-MPLS с Active-Active на IRB, пишу про результаты нагрузочных тестов.
Особенность тестирования:
Первоначально пускаем 1 Гб/с по ранее описанной методике и в прогрессии увеличиваем.
Заметили, что при достижении трафика 5% от максимального, т.е. 5Гб/с, получаем потери.
Связано это с тем, что обрывается LDP сессия.
А она обрывается, потому что CPU немного устал...
ну и на десерт IS-IS + BGP разваливаются
И что делать? Коробка должна гнать 2.4 Тб/с, а умирает при 5 Гб/с...
Как бы очевидно то, что исходя из проблем выше, транзитный трафик идущий на IRB, попадает на CPU, чего очевидно быть не должно.
Пообщались с вендором, ребята всё это дело зафиксировали, собрали инфу, подтвердили в лабе. Выяснилось, что при таком сценарии, все UDP пакеты попадают в очередь ведущую прямиком на CPU. А вот с TCP всё отлично работает и таких проблем нет. Интересно то, что мы в данном тесте не пытались менять дефолтное поведение TREXа, т.к. нам были не важны вложения и достаточно было той энтропии, которая в итоге получалась, а он то как раз всё шлёт как UDP :)
В общем баг зафиксировали, в ближайшее время будет фикс, ориентировочно к концу Q3 2024.
На всякий случай, проверили результаты с TCP и переделали наши потоки.
На этом историю про тестирование MR в контексте EVPN-MPLS завершаю, вернусь после выпуска фиксов и повторим.
P.S. Если вам нравится мой канал, расскажите о нём тем, кому это тоже может быть интересно. Ваша поддержка очень важна для меня. Спасибо!
#импортозамещение #цод #коммутаторы #маршрутизаторы #vxlan #mpls #b4com
Особенность тестирования:
Первоначально пускаем 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
👍9