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

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

не совсем додуплил причем здесь intel.

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

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

Эмммм, причем здесь фирмварей? Вы в курсе насчет SDN&NFV? Я говорю о открытых аналогах Скат/RDP/Brain4Net/6WIND/etc...

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

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

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

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

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

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

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

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

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

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

Вы в курсе насчет SDN&NFV? Я говорю о открытых аналогах Скат/RDP/Brain4Net/6WIND/etc...

А есть какие-то открытые имплементации MANO?

дяденька

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

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

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

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

А перевести лень было?

Mikrotik: the Beginning?

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

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

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

Amazon да, рулит.

Он многофункционален очень, там и туннели ipsec есть, и acl и многое другое, поставить его хоть куда можно, чтобы посмотреть, интерфейс cisco like

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

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

на зарплату - это скорее всего вам нужно обратиться в Pantheon Technologies или Cisco, а так этот проект пилится ровно также как и ядро линукса

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

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

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

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

Здравствуйте. Если не на ванильном, то с какими патчами?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ладно...

Тогда вам нужно https://wiki.fd.io/view/Vicn

Но я, если честно не использовал

IPSEC

IPsec?

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

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

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

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

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

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

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

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

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

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

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

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

к слову, как тут с nat хелперами? они вообще есть? или active ftp, gre и т.п. - тоже «старые и дырявые» протоколы, наравне с pptp/sip?

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

Alg здесь не работает, хотя мы проверяли pptp и sip - работают

Pptp работает же поверх gre, и да, как я уже сказал sip n pptp дырявые и ненужные протоколв, используйте ice и l2tp/ipsec

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

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

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

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