Jump to content
Калькуляторы

Linux softrouter

какой прирост в pps даст задействование трех каналов памяти CPU вместо двух?

Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо.

т.е. лучше вообще один канал использовать?

Share this post


Link to post
Share on other sites

Не хочется вынимать процессор физически,

1. можно на этапе загрузки linux как бы отключить один процессор - чтобы linux задействовал только один процессор и посмотреть какой прирост в pps получиться?

Или без физического вынимания программно эту хотелку не реализовать?

2.Если память у одного процессора вынуть, и прибить прерывания с сетевой к процессору который с памятью - это может равнозначно походить на тест системы с одним процессором или все равно оба процессора в системе вяжутся аппаратно и снижают производительность. Если память у одного проца вынуть то numa node в linux остается одна.

 

В этой ветке говорили что лучше иметь один проц но быстрый, для задачи пропуска pps.

Хочется решить - заморачиваться покупкой более быстрого процессора или нет.

Оставляли по одному ядру у двух CPU в BIOS и получили что одно ядро вместо 600 kpps пропустило 1,5 млн pps. память в этом случае была у двух процессоров.

Edited by QWE

Share this post


Link to post
Share on other sites

Кто-нибудь тестировал VPP в качестве NAT Box`a ?

https://wiki.fd.io/view/VPP/SNAT

 

Сейчас в процессе альфа-тестов accel-ppp + VPP-NAT на одной машине (соединены через виртуальный ip link veth)

в первом приближении схема рабочая, с некоторыми оговорками (PPTP - не работает, GRE - не НАТится вообще).

 

но пилить high availability ещё предстоит, очень не хватает банального VRRP или небанального OSPF/BGP (на sandbox пока не решился), есть BFD, но реализовать с ним еще тот ребус.

Share this post


Link to post
Share on other sites

ну вроде как для НАТа не нужны OSPF/BGP.

ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо...

Share this post


Link to post
Share on other sites

ну вроде как для НАТа не нужны OSPF/BGP.

ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо...

 

BFD есть, а к нему можно статический маршут прицепить. Куда интереснее насколько лучше/хуже по сравнению с линуксовым NAT оно справляется с udp или tcp-syn флудом.

Share this post


Link to post
Share on other sites

ну вроде как для НАТа не нужны OSPF/BGP.

ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо...

а что значит колом? linux остановиться? watchdog

Вам конечно виднее - у Вас есть представление о том что должно быть на машинке с НАТ.

Share this post


Link to post
Share on other sites

какой прирост в pps даст задействование трех каналов памяти CPU вместо двух?

Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо.

т.е. лучше вообще один канал использовать?

Речь ведь про LGA 1366? Лучше использовать 2 канала.

Между 1 и 2 каналами разница в ПСП в 1.5 раза.

А вот между 2 и 3 разница ПСП в пару процентов.

Третий канал платформе приделали сугубо для поддержки большего объема памяти.

Share this post


Link to post
Share on other sites

какой прирост в pps даст задействование трех каналов памяти CPU вместо двух?

Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо.

т.е. лучше вообще один канал использовать?

Речь ведь про LGA 1366? Лучше использовать 2 канала.

Между 1 и 2 каналами разница в ПСП в 1.5 раза.

А вот между 2 и 3 разница ПСП в пару процентов.

Третий канал платформе приделали сугубо для поддержки большего объема памяти.

спс

Share this post


Link to post
Share on other sites

BFD есть, а к нему можно статический маршут прицепить.

можно, но коряво как-то.

 

Куда интереснее насколько лучше/хуже по сравнению с линуксовым NAT оно справляется с udp или tcp-syn флудом.

там вроде как просто буфер на N записей, из которого самые старые замещаются новыми. т.е. - непредсказуемое время жизни сессий.

 

ну и + отсутствуют какие-либо нат хелперы.

 

а что значит колом?

да все что угодно. на выбор: краш самого vpp (полное отсыхание сети как следствие); lockup в vpp (тот же результат по факту); вис системы целиком; всплывшая бага, ломающая л3 форвардинг и т.п.

 

разработчики прямым текстом предупреждают о нестабильности и непредсказуемом поведении.

 

ну и да, в при использовании более одного ядра вылезут еще и тараканы dpdk (он вроде как нестабилен в multithreading).

 

не, можете пробовать, но как по мне - для какого-либо практического использования оно еще слишком сырое и недоделанное. хоть и активно пилится. правда - в какую-то странную степь (пихать MPLS и прочее, не доделав человеческую дин.маршрутизацию - как-то слишком уж упорото ИМХО).

Share this post


Link to post
Share on other sites

(пихать MPLS и прочее, не доделав человеческую дин.маршрутизацию - как-то слишком уж упорото ИМХО).

 

Правельно. В оригенальном linux MPLS появился не давно. Но, правельно что они с этого начинают.

Share this post


Link to post
Share on other sites

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Share this post


Link to post
Share on other sites

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

FRRouting+VPP

Share this post


Link to post
Share on other sites

FRRouting+VPP

vpp sandbox, который отдельный проект и в данный момент с текущим срезом vpp, судя по слухам, не работает...

ну и да, удивлен что они таки реализовали втягивание системных роутов. потому как в офф мануале все вяжется плясками с бубном: https://wiki.fd.io/view/VPP_Sandbox/router

Share this post


Link to post
Share on other sites

vpp sandbox, который отдельный проект и в данный момент с текущим срезом vpp, судя по слухам, не работает...

А почему тогда в документации всё работает?

Share this post


Link to post
Share on other sites

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

FRRouting+VPP

 

Unfortunately the VPP's router plugin is not being actively maintained and is not part of the official VPP repository, being maintained separately in the VPP Sandbox (VPPsb) [5]. Its latest versions are broken since a few changes were made in the VPP API, so we're going to use older versions of VPP/VPPsb where things are known to work.

Share this post


Link to post
Share on other sites

А почему тогда в документации всё работает?

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

Share this post


Link to post
Share on other sites

А почему тогда в документации всё работает?

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

А что именно там не работает?

Share this post


Link to post
Share on other sites

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

FRRouting+VPP

 

По поводу реализации BGP в VPP в рассылку написали

 

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

We use ODL's BGP implementation:

http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html

 

https://wiki.fd.io/view/Hc2vpp

 

To configure BGP you may use RESTCONF or NETCONF protocols (no CLI).

You can find request examples in the link from my previous email to have general overview.

BGP configuration in HC has few differences. Please find details in:

https://gerrit.fd.io/r/#/c/7814/

After merge job for 7814 finishes, you should find rendered adoc at:

https://docs.fd.io/hc2vpp/1.17.07-SNAPSHOT/hc2vpp-parent/release-notes-aggregator/user_running_honeycomb.html#_using_bgp

 

Как я понял консоли как у cisco нет, и через файл как bird этот BGP не сконфигурить. Тупая копи-паста не годна.

Edited by QWE

Share this post


Link to post
Share on other sites

А что именно там не работает?

пост выше прочитайте, написано же...

 

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет?

Share this post


Link to post
Share on other sites

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет?

на яве структуры и типы данных значительно тяжелее чем в си?

Share this post


Link to post
Share on other sites

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет?

на яве структуры и типы данных значительно тяжелее чем в си?

А реально ли сделать BGP на bash'е?

Share this post


Link to post
Share on other sites

Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html

Сервер должен работать как Nat.

Если через сервер пускать реальный трафик, то всё корректно работает.

Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться.

 

Может кто сталкивался. В чём может быть проблема?

Share this post


Link to post
Share on other sites

на яве структуры и типы данных значительно тяжелее чем в си?

само собой. интерпретируемый байт-код, ООП, все дела.

 

поинтересуйтесь сколько ресурсов жрут ява-приложения, сравните с не-ява аналогами. разница эдак на порядок...

Share this post


Link to post
Share on other sites

Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html

Сервер должен работать как Nat.

Если через сервер пускать реальный трафик, то всё корректно работает.

Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться.

 

Может кто сталкивался. В чём может быть проблема?

 

Очень вероятно в том, что trex не statefull генератор, а NAT в линуксе реализован на основе отслеживания состояния сессий (connection tracking)

Т.е., например, чтобы стартанула nat сессия для обычного tcp соединения connection tracking механизм должен засечь SYN пакет, а trex их не шлет.

Да и просто одного syn тоже будет недостаточно, нужен ответный syn-ack. Пробуйте warp17. В нем реализован tcp стэк и очень быстрый. Миллионы соедений, огромный pps. У меня тесты linux nat на ура прошли с его помощью.

Share this post


Link to post
Share on other sites

Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html

Сервер должен работать как Nat.

Если через сервер пускать реальный трафик, то всё корректно работает.

Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться.

 

Может кто сталкивался. В чём может быть проблема?

 

Очень вероятно в том, что trex не statefull генератор, а NAT в линуксе реализован на основе отслеживания состояния сессий (connection tracking)

Т.е., например, чтобы стартанула nat сессия для обычного tcp соединения connection tracking механизм должен засечь SYN пакет, а trex их не шлет.

Да и просто одного syn тоже будет недостаточно, нужен ответный syn-ack. Пробуйте warp17. В нем реализован tcp стэк и очень быстрый. Миллионы соедений, огромный pps. У меня тесты linux nat на ура прошли с его помощью.

В нём нету даже MPLS!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now