[wtyd]

Есть такой проект https://github.com/kohler/click/. Теоретически интересен он тем, что есть его вариант с netmap, который обещает производительность, которую обеспечивает netmap :-). Т.е. должно быть охренительно быстро.

 

Кто-нибудь смотрел, трогал ? Из документации я пока ничего не понял в его языке описания цепочек :-). Вроде бы этот клик можно настроить как вообще что угодно -- как фильтрующий или шейпящий бридж. Ограничивается всё мерой понимания, фантазией и знанием этого языка.

 

В общем, интересуют мнения.

[t0ly]

самому интересно, но думаю с ним можно будет работать только в узкозаточеном функционале

[pavel.odintsov]

Я бы явно попробовал. Решения для роутинга на базе Intel DPDK легко уделывают возможности линукс бокса по роутингу.

[t0ly]

меня пока смущает только динамическая маршрутизация

[wtyd]

Я бы явно попробовал. Решения для роутинга на базе Intel DPDK легко уделывают возможности линукс бокса по роутингу.

 

Любое софтовое решение, если оно обеспечивает предел по pps среды передачи данных, уделывет не только линукс, но и тем более БЗД и даже каталист при определённом раскладе :-). Т.е. наверняка это решение позволит больше, чем каталист, но портов будет меньше, чем у последнего.

 

Вроде из описания следует, что не важно, на какой ОС запускать -- в юзерспейсе управляющая программа, а само таинство выполняется модулем к ядру. На сегодня имеем netmap, pf_ring и DPDK как технологии быстрой обработки пакетов. По-моему, у всех трёх заявлена производительность равная или близкая к пределу стандартов 1G/10G, всё зависит от ЦПУ и карты, на сколько я понял. Нот что-то софта на этих технологиях нет, за исключением пропатченных libpcap и всего остального, что может юзать libpcap.

 

Жаль, что ещё никто не разбирался с этим кликом ...

[Ivan_83]

Софт будет.

Сейчас идёт накопление кодовой базы, опыта и вики знаний.

 

Для сравнения можно сесть и за вечер налабать нетграф модуль который будет что то делать в L2/L3/L4 без особых сложностей.

Чтобы налабать под нетмап аналогичное нужно заметно больше времени.

Но задача облегчается тем, что система не падает в случае косяков.

 

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

Если в нетграфе ты берёшь л3 пакет то ты уже уверен что он прошёл входные проверки и можно ещё раз не проверять кучу всякой банальщины, а сразу что то с ним делать, и потом ты его выплёвываешь и система сама его до обрабатывает и отсылает куда нужно.

А здесь нужно весь стёк с нуля городить, и арп и кеш к нему и таблицу роутинга и прочее. Такое быстро не делается.

 

У яндекса уже больше года что то на нетмапе есть, вроде даже в продакшене, но деталей они не озвучивают.

[pavel.odintsov]

Готовые роутинг-модули есть для DPDK в примерах даже, но там тупо статический роутинг по набору правил, но обещают до 80mpps и выше.

 

На PF_RING/ZC (200 евро за сетевку лицензия) я уже довольно давно и тесно пишу - в принципе, сроутить им можно очень много, но там нет тулкита по конкретно роутингу, то есть LPM матчинг и сам протокол роутинга надо лабать самостоятельно, но в примерах там есть examples роутера по RFC, для него заявляли line rate для 2х 10GE.

 

netmap на Linux - ужасное багалово, как он работает и почему - совершенно не ясно, у меня так и не вышло его завести, чтобы он на 100kpps не убивал мне всю машину.

 

Так что если у кого есть интерес, можно попробовать поднять стенды, ибо Linux-таки не лучшая платформа под роутинг, как ни крути. Очень много деталей и мелочей и очень сильная завязка на ядро, а тот же dpdk работает на любом ядре, так как вся обработка в общем-то уносится в модуль ядра.

[pavel.odintsov]

Вот пруфлинк на тему роутингв силами PF_RING десятки целиком - http://www.ntop.org/pf_ring/pf_ring-dna-rfc-2544-benchmark/

 

Вот PDF со сравнением PF_RING/Linux forward: http://www.ntop.org/wp-content/uploads/2012/04/DNA_ip_forward_RFC2544.pdf по-моему, убедительнее некуда.

 

Я давно-давно спрашивал автора PF_RING Luca Deri на тему, какой софт они для этого использовали и мне ответили вот это: https://svn.ntop.org/svn/ntop/trunk/PF_RING/userland/examples/pfbridge.c

Edited December 30, 2014 by pavel.odintsov

[t0ly]

я прошу прощения, а BGP к PF_RING как то прикрутить можно?

[pavel.odintsov]

t0ly почему нет? Но вопрос скорее в чуточку ином - нужно научить BIRD/Quagga подавать команды перестройки роутинг таблицы не ядру, а приложению на PF_RING. В принципе, это все реально написать. Но я все равно думаю, что DPDK для этой задачи и лучше, хоть я его и знаю очень плохо.

 

Вот, посмотрите тут http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/intel-dpdk-sample-applications-user-guide.html "L3 Forwarding Sample Application" на странице 58.

[s.lobanov]

Для квагги есть патчи, позволяющие грузить маршруты не в ядро, а куда-либо, возможно уже в апстриме, надо смотреьб

[pavel.odintsov]

Где-то была инфа, что Quagga может управлять как SDN и передавать управляющие команды контроллеру сетевого устройства. У Кумулуса вроде оно так и используется. То есть поидее нужен SDN контроллер и форвард энджин к нему кастомный.

[s.lobanov]

pavel.odintsov

Раньше я читал лист рассылку quagga, поэтому помню,что эта тема поднималась и были наработки. Сейчас оно принято в апстрим:

http://www.gossamer-threads.com/lists/quagga/dev/24177

http://www.nongnu.org/quagga/docs/docs-multi/zebra-FIB-push-interface.html

 

Так что принимайте роуты от зебры и запихивайте их куда вам нравится

[pavel.odintsov]

Спасибо, круто!

[t0ly]

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