QWE Опубликовано 21 июля, 2017 · Жалоба какой прирост в pps даст задействование трех каналов памяти CPU вместо двух? Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо. т.е. лучше вообще один канал использовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 21 июля, 2017 (изменено) · Жалоба Не хочется вынимать процессор физически, 1. можно на этапе загрузки linux как бы отключить один процессор - чтобы linux задействовал только один процессор и посмотреть какой прирост в pps получиться? Или без физического вынимания программно эту хотелку не реализовать? 2.Если память у одного процессора вынуть, и прибить прерывания с сетевой к процессору который с памятью - это может равнозначно походить на тест системы с одним процессором или все равно оба процессора в системе вяжутся аппаратно и снижают производительность. Если память у одного проца вынуть то numa node в linux остается одна. В этой ветке говорили что лучше иметь один проц но быстрый, для задачи пропуска pps. Хочется решить - заморачиваться покупкой более быстрого процессора или нет. Оставляли по одному ядру у двух CPU в BIOS и получили что одно ядро вместо 600 kpps пропустило 1,5 млн pps. память в этом случае была у двух процессоров. Изменено 21 июля, 2017 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sorkua Опубликовано 21 июля, 2017 · Жалоба Кто-нибудь тестировал 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, но реализовать с ним еще тот ребус. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 21 июля, 2017 · Жалоба ну вроде как для НАТа не нужны OSPF/BGP. ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a290 Опубликовано 21 июля, 2017 · Жалоба ну вроде как для НАТа не нужны OSPF/BGP. ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо... BFD есть, а к нему можно статический маршут прицепить. Куда интереснее насколько лучше/хуже по сравнению с линуксовым NAT оно справляется с udp или tcp-syn флудом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 21 июля, 2017 · Жалоба ну вроде как для НАТа не нужны OSPF/BGP. ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо... а что значит колом? linux остановиться? watchdog Вам конечно виднее - у Вас есть представление о том что должно быть на машинке с НАТ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 21 июля, 2017 · Жалоба какой прирост в pps даст задействование трех каналов памяти CPU вместо двух? Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо. т.е. лучше вообще один канал использовать? Речь ведь про LGA 1366? Лучше использовать 2 канала. Между 1 и 2 каналами разница в ПСП в 1.5 раза. А вот между 2 и 3 разница ПСП в пару процентов. Третий канал платформе приделали сугубо для поддержки большего объема памяти. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 21 июля, 2017 · Жалоба какой прирост в pps даст задействование трех каналов памяти CPU вместо двух? Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо. т.е. лучше вообще один канал использовать? Речь ведь про LGA 1366? Лучше использовать 2 канала. Между 1 и 2 каналами разница в ПСП в 1.5 раза. А вот между 2 и 3 разница ПСП в пару процентов. Третий канал платформе приделали сугубо для поддержки большего объема памяти. спс Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 23 июля, 2017 · Жалоба BFD есть, а к нему можно статический маршут прицепить. можно, но коряво как-то. Куда интереснее насколько лучше/хуже по сравнению с линуксовым NAT оно справляется с udp или tcp-syn флудом. там вроде как просто буфер на N записей, из которого самые старые замещаются новыми. т.е. - непредсказуемое время жизни сессий. ну и + отсутствуют какие-либо нат хелперы. а что значит колом? да все что угодно. на выбор: краш самого vpp (полное отсыхание сети как следствие); lockup в vpp (тот же результат по факту); вис системы целиком; всплывшая бага, ломающая л3 форвардинг и т.п. разработчики прямым текстом предупреждают о нестабильности и непредсказуемом поведении. ну и да, в при использовании более одного ядра вылезут еще и тараканы dpdk (он вроде как нестабилен в multithreading). не, можете пробовать, но как по мне - для какого-либо практического использования оно еще слишком сырое и недоделанное. хоть и активно пилится. правда - в какую-то странную степь (пихать MPLS и прочее, не доделав человеческую дин.маршрутизацию - как-то слишком уж упорото ИМХО). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 23 июля, 2017 · Жалоба (пихать MPLS и прочее, не доделав человеческую дин.маршрутизацию - как-то слишком уж упорото ИМХО). Правельно. В оригенальном linux MPLS появился не давно. Но, правельно что они с этого начинают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 25 июля, 2017 · Жалоба Но, правельно что они с этого начинают. начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 26 июля, 2017 · Жалоба Но, правельно что они с этого начинают. начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн). Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP FRRouting+VPP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 26 июля, 2017 · Жалоба FRRouting+VPP vpp sandbox, который отдельный проект и в данный момент с текущим срезом vpp, судя по слухам, не работает... ну и да, удивлен что они таки реализовали втягивание системных роутов. потому как в офф мануале все вяжется плясками с бубном: https://wiki.fd.io/view/VPP_Sandbox/router Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 26 июля, 2017 · Жалоба vpp sandbox, который отдельный проект и в данный момент с текущим срезом vpp, судя по слухам, не работает... А почему тогда в документации всё работает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 26 июля, 2017 · Жалоба Но, правельно что они с этого начинают. начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 26 июля, 2017 · Жалоба А почему тогда в документации всё работает? документация видать обновляется еще реже, чем vpp sandbox. работало на момент написания - и здорово. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 26 июля, 2017 · Жалоба А почему тогда в документации всё работает? документация видать обновляется еще реже, чем vpp sandbox. работало на момент написания - и здорово. А что именно там не работает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 27 июля, 2017 (изменено) · Жалоба Но, правельно что они с этого начинают. начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить 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 не сконфигурить. Тупая копи-паста не годна. Изменено 27 июля, 2017 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 27 июля, 2017 · Жалоба А что именно там не работает? пост выше прочитайте, написано же... hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP. бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 27 июля, 2017 · Жалоба hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP. бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет? на яве структуры и типы данных значительно тяжелее чем в си? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 27 июля, 2017 · Жалоба hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP. бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет? на яве структуры и типы данных значительно тяжелее чем в си? А реально ли сделать BGP на bash'е? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 27 июля, 2017 · Жалоба Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html Сервер должен работать как Nat. Если через сервер пускать реальный трафик, то всё корректно работает. Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться. Может кто сталкивался. В чём может быть проблема? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 27 июля, 2017 · Жалоба на яве структуры и типы данных значительно тяжелее чем в си? само собой. интерпретируемый байт-код, ООП, все дела. поинтересуйтесь сколько ресурсов жрут ява-приложения, сравните с не-ява аналогами. разница эдак на порядок... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 27 июля, 2017 · Жалоба Тестируем сервер при помощи 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 на ура прошли с его помощью. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 27 июля, 2017 · Жалоба Тестируем сервер при помощи 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! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...