LINUX.ORG.RU

Soft switch/router VPP

 , , , ,


4

3

Цель открытого проекта VPP — создание свича/маршрутизатора L2/L3+ с множеством функций, включая полноценный NAT, с высокой производительностью обрабатывающего сетевые пакеты при использовании обычного процессора за счёт векторной обработки данных (эта технология уже используется в новых промышленных сетевых устройствах). Проект ведётся Cisco, Pantheon Technologies и другими.

Продукт работает на Intel DPDK. Этот фрэймворк позволяет использовать сетевую карту Intel в обход ядра операционной системы.

Продукт не является стабильным; все отчёты об ошибках и запросы функциональности принимаются кураторами. Разработчики будут благодарны за тестирование.

>>> Страница VPP

>>> Страница DPDK

>>> Список рассылки

>>> Подробности

★★★

Проверено: Shaman007 ()

- убрал весь «данный». Нелья использовать слово «данный», оно омерзительно, в русском языке нет определенного артикля. For a reason!

- убрал пассаж про быстрый DPDK и развитие сетевого стека. Возможно, автор новости не понимает зачем нужен DPDK (а он нужен и годен).

Shaman007 ★★★★★ ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от Shaman007

Имелось ввиду, что на линуксовом ядре нельзя достичь овер 10 миллионов пакетов в секунду на мультипроцессорной системе, чего позволяет достичь vpp на одном ядре используя dpdk. Спасибо за поправки. А насчет медленного линуксового стека правда, даже на lkml статья была. Новость написал ради того, чтобы народ знал что на сегодняшний день есть открытые и бесплатные реализации SDN. Сам являюсь тестировщиком этого продукта, конкретно NAT модуля. Насчет того причем здесь intel: в свое время dpdk был отдельной разработкой, потом перешёл в руки интела, драйвера поддерживаются в основном картами на чипе интела от гигабитных до 50 гигабитных, также вроде есть поддержка карт mellanox

init_ ★★★ ()
Ответ на: комментарий от AVL2

Я так понимаю, это для замены фирмварей коммутаторов?

Нет. VPP — набор неплохих юзерспейсных библиотек на околосетевую тему под нормальной лицензией. DPDK — тоже. Вообще, байпасс сетевого стека — это очень небольшая и далеко не самая важная часть DPDK.

Увы, что в случае сабжа, что в случае DPDK огорчает ровно одно: разработчики до сих пор не допёрли, что на C++ можно писать *ровно* в таком же стиле и получать *ровно* такой же машинный код на выходе.

Macil ★★★★★ ()
Ответ на: комментарий от init_

Имелось ввиду, что на линуксовом ядре нельзя достичь овер 10 миллионов пакетов в секунду на мультипроцессорной системе

Можно, 14,88 мегапакетов на 10Гб/c интерфейсе. Ну не на ванильном, естественно, но без DPDK.

Shaman007 ★★★★★ ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от Macil

Посмотрел по диагонали, все равно пока не очень понятно. Судя по тому, что для настройки интерфейсов они используют свою утилиту vppctl, это отдельная сетевая подсистема?

AVL2 ★★★★★ ()
Ответ на: комментарий от init_

Насчет того причем здесь intel: в свое время dpdk был отдельной разработкой, потом перешёл в руки интела, драйвера поддерживаются в основном картами на чипе интела от гигабитных до 50 гигабитных, также вроде есть поддержка карт mellanox

Изначально оно работало и было оптимизировано под intel, но сейчас оно и под arm работает, и сетевушек умеет побольше.

Laz ★★★★ ()
Ответ на: комментарий от AVL2

Судя по тому, что для настройки интерфейсов они используют свою утилиту vppctl, это отдельная сетевая подсистема?

За VPP сказать не могу, не погружался, но в случае с dpdk подразумевается наличие в приложении userspace tcp-стека, который монопольно использует сетевую карту на полную катушку. Полагаю, что у VPP суть та же.

Laz ★★★★ ()
Последнее исправление: Laz (всего исправлений: 1)
Ответ на: комментарий от Laz

Ну вот в связи с этим интересно, насколько полно этот стек реализован. Или там три команды с подъемом интерфейсов, присвоением им адресов и организацией ната и на этом все.

И еще, как этот стек совместим с обычными сетевыми сервисами и тунелями. Тем же openvpn, bind и тому подобным.

Реализован ли свой файрволл, netfilter/iptables и есть ли возможность использовать, к примеру shorewall совместно с ним...

AVL2 ★★★★★ ()
Ответ на: комментарий от hiend

У DPDK, кстати, заявлена поддержка амазоновского Elastic Network Adapter, можно безболезненно поиграться - очень уж интересная штука.

Вроде как даже 1G сетевые карты позволяют потрогать технологию.

Amazon да, рулит.

EuGeneus ★★ ()
Ответ на: комментарий от AVL2

все верно, когда вы произведете настройку VPP (в конфигурационном файле описываются установленные сетевые карточки, какие вы хотите использовать в подсистеме VPP), после запуска интерфейсы исчезнут из линуксового окружения и станут доступны в VPP, то есть по этим интерфейсам у вас уже не будут доступны какие-то службы, например SSH, но вы всегда сможете создать tap устройство (а оно это поддерживает из двух команд) из VPP, которое поднимет виртуальный интерфейс в линуксовом окружении, и вот тогда вы сможете настроить доступ к хостовой машине через VPP маршрут

init_ ★★★ ()
Ответ на: комментарий от AVL2

в VPP существует несколько технологий для бридживания соединений в линуксовый юзерспэйс, такие как tap, с другими я пока не разбирался, но они тоже есть. То есть когда вы поднимете tap устройство в vpp, у вас появится tap устройство и в самом linux окружении, на которое вы сможете натравить необходимые службы (iptables, bind, etc...)

init_ ★★★ ()
Последнее исправление: init_ (всего исправлений: 1)
Ответ на: комментарий от Laz

dpdk да, у него большой список устройств, но так как VPP используется патченый dpdk, то список устройств ограничен, например то что поддерживает ванильный dpdk - не факт что будет поддерживать vpp с патченным dpdk, но вы всегда сможете попробовать :) например у меня заработало на гигабитном сервачном интефейсе intel (igb), а также 10g интеловом (ixgbe). Скоро приедет 10g mellanox - попробую и на нем

init_ ★★★ ()
Ответ на: комментарий от Shaman007

ну да, например с драйвером netmap от Луиджи, но как например подружить этот драйвер с какими то функциями рядовому айтишнику - это уже вопрос, также как и голый dpdk. VPP дает эту возможность, настраивать практически все что угодно за неимением навыков программировать

init_ ★★★ ()
Ответ на: комментарий от Kroz

это и есть открытая имплементация, кстати там есть API через который она легко интегрируется в OpenStack, поддержка таких «прослоек» как netconf, python api, honeycomb и что-то там еще было, кажется

init_ ★★★ ()

кто-нибудь готов пощупать этот проект? хочется просто пронести его в росскийское компьюнити, тестеров больше станет, а может и сами разработчики подтянутся, проект молодой, начал развиваться с 2016 года, и за это время он сильно вырос, так что наверное имеет смысл протестировать. Сам я работаю на оператора связи, для нас это интересно сократить парк серверов за счет большей пропускной способности VPP и сделать более отказоустойчивую систему доступа

init_ ★★★ ()
Ответ на: комментарий от init_

Понятно. Но тогда сразу возникает вопрос, а какая в итоге производительность получается, например, между openvpn сервером и клиентом на двух машинах c vpp? То есть, верим, что vpp быстр и ненапряжен для процессора, но так ли быстр будет переход трафика из vpp в подсистему линукса и назад, в vpp?

И еще вопрос, я так понимаю, настраивать нетфильтр в таком случае не надо? Иначе тормозной стек линукса так и будет тормозить? Файрволл, нат, днат и снат настраивается средствами vpp? Адреса на tap назначать тоже не надо, они же уже назначены на интерфейсы vpp?

AVL2 ★★★★★ ()
Ответ на: комментарий от init_

Я ставил vswitch. Оказалось, что он довольно специфичен и годен только для виртуализации. Хотелось бы понять, насколько эта штука полезна, прежде чем разбираться с ее компиляцией в центос.

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

в первом вопросе - производительность упрется в клиент и сервер vpn, задача vpp этот трафик смаршрутизировать/снатировать с минимальной нагрузкой. Адрес на TAP нужно будет назначить на уровне самого VPP, например если вы поднимаете TAP устройство, то на стороне VPP нужно назначить адрес к примеру 10.10.1.1/24, а на стороне Linux стека назначить адрес 10.10.1.2/24 и связь между этими адресами будет налажена, в таком случае будет работать основа маршрутизации в VPP, с какой физической сетевой карты придет трафик и в какое TAP устройство уйдет этот трафик, можно назначать несколько TAP устройств с разной адресацией, дальше, если хотите можно применять контейнеризацию через ip netns (входящий в комплект iproute2)

init_ ★★★ ()
Ответ на: комментарий от AVL2

компилировать ничего не нужно, если вы внимательно изучите этот вопрос, то для CentOS, Debian и Ubuntu есть готовые пакеты, мы ждем релиза, в котором много патчей будет замержено, но если вы тестировщик, можете смело накатывать мастер релиз, все это описано в документации на wiki fd.io

init_ ★★★ ()
Ответ на: комментарий от init_

это и есть открытая имплементация,

«Это» - это что? Если ты про VPP, то это VNF'ка. А меня интересует MANO - Management and Orchestration.

C VNF'ками проблем нет; SDN контроллер, VIM - тоже открытые есть. А вот оркестратора я не видел, только прориетарные решения. А ведь вся сила NFV именно в оркестраторе.

Kroz ★★★★★ ()
Ответ на: комментарий от init_

Да, но тогда понятно, почему такое внимание уделено НАТ. По сути 99% серверов с vpp будет использовать DNAT/NAT просто чтобы прибиндить сервис к интерфейсу тап и пропустить трафик от него через физический интерфейс. Такая ерунда сейчас с usb-модемами йота. Хошь не хошь, он раздает компьютеру сетку 10.0.0.0/24 и натит трафик с внутреннего интерфейса на внешний.

Проблема в том, что многие протоколы либо не работают, либо глючат с нат. ip-телефония, например. Мультикаст тоже его не любит.

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

чисто для NAT реализации tap не нужен, VPP умеет внутри себя натировать трафик, например, у вас есть 2 интерфейса (один вход, другой выход), они биндятся внутри VPP и внутри VPP настраивается NAT, никакой iptables не нужен в этом плане

init_ ★★★ ()
Ответ на: комментарий от init_

Я так понимаю вы говорите о Opendaylight, если так, то VPP прекрасно с ним интегрируется через Honeycomb

OpenDaylight - это SDN контроллер
Я про оркестратор - Network Service Orchestrator, VNF оркеатратор etc.

Ладно...

Kroz ★★★★★ ()
Ответ на: комментарий от init_

чисто для NAT реализации tap не нужен, VPP умеет внутри себя натировать трафик, например, у вас есть 2 интерфейса (один вход, другой выход), они биндятся внутри VPP и внутри VPP настраивается NAT, никакой iptables не нужен в этом плане

Это понятно, что весь nat оказывается внутри vpp, а не в netfilter. Но от этого нат не перестает быть натом со всеми своими проблемами, пусть даже быстрым. Вопрос в том, что в принципе непонятно, зачем назначать адрес внешнему физичесому интерфейсу? Мы же в свиче адреса не назначаем? Весь L2 не требует адресов. Так зачем он требуется в vpp? Отдали физический интерфейс в vpp, создали нужное количество интерфейсов tap, назначили реальные адреса им и пользуемся ими в системе. Зачем эти адреса назначать именно физическим интерфейсам и добавлять виртуальные частные адреса внутри на tap, чтобы настраивать nat?

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

не совсем понял вопроса? зачем вам использовать линуксовый TAP когда можно внутри VPP назначить физическим сетевушкам локальный и реальный адрес, и локалку натировать реальным адресом. А причем тут l2? NAT это ведь уже как минимум L3 уровень и до L7. Смотрите, у вас есть сеть из N клиентов с серыми адресами, есть железка с двумя физическими интерфейсами (внутри VPP), на них в VPP вы вешаете локальную адресацию (куда вы смаршрутизируете серых клиентов) и на другой интерфейс белую адресацию с шлюзом к вышестоящему роутеру, настраиваете также вунтри VPP NAT (с одним белым адресом или с диапазоном адресов, неважно) и маршрут по умолчанию. Никаких TAP устройств вам не нужно при этом, TAP нужен только для того чтобы управлять сервером через маршрутизацию VPP и для других плюшек

init_ ★★★ ()
Последнее исправление: init_ (всего исправлений: 3)
Ответ на: комментарий от init_

Ну редко кто делает роутер из компьютера совершенно без сетевых служб, то есть один только роутинг, dhcp и нат.

Еще нужен bind, ssh, openvpn и все все те службы, которые через нат не работают или работают откровенно плохо и для которых есть или прокси или реализации самого сервера на роутере, где есть возможность прибиндится на внешний адрес и работать напрямую, без натов, снатов, днатов и роутингов из локалки вовне.

А еще есть просто серверы, в которых стоит тоже самая проблема скорости соединений и там вообще роутинга как такового может не быть. Например, nas.

Я посмотрел уже кейс такого включения. предлагают использовать snat. На мой взгляд не слишком оптимальный вариант.

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

Если вы о службах таких как днс, то под натом они прекрасно работают, у сипа есть специальные костыли под нат. А если по существу пптп и сип признаны дырявыми и старыми протоколами, вместо них существует l2tp и ICE соответственно

init_ ★★★ ()
Ответ на: комментарий от AVL2

Кстати говоря, разработчики недавно починили трех кортёжный пакет, он не работал, к нему относились такие вещи как gre, обычный пакет состоит из 5 кортежей

init_ ★★★ ()

как по мне - на данный момент это сферический конь в вакууме, хоть и персепктивный. из того, что ИМХО не хватает:

1. динамическая маршрутизация (либо хотя бы подгребание маршрутов из указанной таблицы маршрутизации хоста - хотя тут могут быть проблемы) 2. шейпинг (сабж если и будут тестить, то в первую очередь ISP а не махровый энтерпрайз/магистралы) 3. терминация туннелей (потому же почему и п.2), с радиусом и т.п.

NiTr0 ★★★★★ ()
Ответ на: комментарий от AVL2

Нат в vpp очень интересно сделан в плане таблиц состояний и это его особенная фишка, в линуксе таймауты по конкретному протоколу, а в vpp просто ограничение, по достижению которого таблица очищается

init_ ★★★ ()
Ответ на: комментарий от NiTr0

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

init_ ★★★ ()
Ответ на: комментарий от NiTr0

да и хелперы эти потихоньку начали уже выпиливать из ядра линукса, последний раз когда я на пограничнике обновил ядро с 3.9 до 4.4, пользователи стали жаловаться на неработоспособность pptp

init_ ★★★ ()
Ответ на: комментарий от init_

Да протоколов может быть много. И с натом у них могут быть какие угодно отношения. Зачем мне внутри локалки, например, нат вообще нужен?

Я бы еще понял, если бы сервисы планировалось не сейчас так когда то биндить напрямую на интерфейсы vpp, например, через либу. То есть старое через tap, а новое нативно, без проблем. Так нет, давай нат, нат и нат для всего.

Дело не в этом. Я же изначально спрашивал, это для фирмварей коммутаторов и роутеров придумано? Тогда ситуация понятна. Но вы спорите, нет, это для серверов и компьютеров. Вот это и удивляет.

AVL2 ★★★★★ ()