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