netmap и будущее софтовых маршрутизаторов

[ttttt 195]

Когда-то мы уже обсуждали маршрутизацию на тазиках на базе netmap/dpdk. С тех пор прошло много времени, на свет появилось несколько интересных проектов. Всем стало понятно, что старым сетевым стэкам freebsd и linux пора на пенсию.

Коммерческие стэки на базе dpdk, типа 6wind, показали увеличение производительности на порядок. Даже vyatta интегрировала стэк на базе dpdk в коммерческую версию своего продукта - vyatta 5600.

 

Но нас интересует open source. И похоже здесь первым кандидатом в полноценные роутеры будет ни что-нибудь, а pfSense! О чем пишет Джим в блоге: https://blog.pfsense.org/?p=1866

Начиная с версии 3.0 в pfSense планируется внедрение стэка на базе netmap (ранее планировалось dpdk в 2.3, но от идеи отказались в пользу netmap). Для этого разработчиками pfSense был начат проект netmap-fwd, который на данный момент является простенькой drop-in заменой ядерного роутера для FreeBSD и может форвардить 1 млн PPS на атоме на одном ядре, т.е. пятикратное увеличение производительности. Никаких оптимизаций пока не делалось. BGPD тоже пока нет, но все в планах.

 

В общем следите за pfSense, пробуйте netmap-fwd, старые стэки уже не подходят для 10G.

Изменено 2015-10-20 18:24:34 пользователем ttttt

[Lynx100 90]

а о чем говорить если пока кроме фреймворков толком ничего  нету....

поставят это на рельсы - будет что тестировать и обсуждать

а в продакшн как по мне даже если будет уже штатно, то пока рано, пока не повылизывается все

Изменено 2015-10-20 18:13:10 пользователем Lynx100

[supportod 1]

Для продакшена сыро.

Когда появится поддержка Реалтека! тогда и будем тестить

[Lynx100 90]

Для продакшена сыро.

Когда появится поддержка Реалтека! тогда и будем тестить

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

[ttttt 195]

Когда появится поддержка Реалтека! тогда и будем тестить

Его нетмап поддерживает, как и другие карты: cxgbe, em, igb, ixgbe, ixl, lem, re

 

Вот слайды из презентации, по ним лучше понять, что такое netmap-fwd и как он работает:

https://github.com/NetgateUSA/netmap-fwd/raw/master/netmap-fwd.pdf

[Lynx100 90]

 

Когда появится поддержка Реалтека! тогда и будем тестить

Его нетмап поддерживает, как и другие карты: cxgbe, em, igb, ixgbe, ixl, lem, re

 

Вот слайды из презентации, по ним лучше понять, что такое netmap-fwd и как он работает:

https://github.com/NetgateUSA/netmap-fwd/raw/master/netmap-fwd.pdf

 

в линуксе вроде риалтек не поддерживается

 

"This is a preliminary version supporting the ixgbe and e1000/e1000e driver. Patches for other devices (igb, r8169, forcedeth) are untested and probably not working yet.

[loki 86]

Эх, доживем ли  ? 

Приходилось юзать ipfw-netmap, сыро, но по производительности впечатляет.

[ttttt 195]

Ну pfsense пока единственные у кого есть и возможность и желание этим заниматься, если не они, то кто?

[NiTr0 585]

еще https://github.com/intersvyaz/zerod проект есть, на наге всплыл линк. не смотрел, по описанию - вроде интересно.

Изменено 2015-10-20 23:30:32 пользователем NiTr0

[ttttt 195]

https://github.com/intersvyaz/zerod

pthread_rwlock_rdlock(&sess->lock_client);
...
pthread_rwlock_unlock(&sess->lock_client);

Такое там на каждый пакет. Не внушает, погубит большую часть профита от batching'а.

[ntil 57]

но в любом случае это будет маршрутизация (коммутация) через память (trouch memory switching).

у меня есть определенные идеи (часть которых выражена в тестовом железе), как этого избежать. 

если интересно - можем обсудить.

[ttttt 195]

но в любом случае это будет маршрутизация (коммутация) через память

ну почему, есть же DDIO в xeon'ах, кому нужно много-много форвардить, там через кэш уже

 

Но в общем выкладывайте, все интересно.

[ntil 57]

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

 

В целом задачу L3 маршрутизации можно разделить на две основных задачи пересылка данных между интерфейсами – forwarding и поиск маршрутов в таблице маршрутизации (lookup)

 

В своих экспериментах, которые я проводил пару лет назад, еще до войны я использовал ПЛИС ALTERA Cyclone-1 на 5К элементов и подключенный к нему MII Ethernet PHY (RTL8201BL) а также ИС SSRAM IDT71V546S 128Kx36 в качестве пакетного буфера. Древнесть элементной базы (12-15 лет) обусловлена ее наличием и принципом протянул руку до полки.

Особенности применяемой SSRAM позволяли эмулировать в ПЛИС ее работу как двухпортовой (временное разделение). Также для экономии ног между ПЛИС ипользовались только 8 линий данных SSRAM – т.е. фактическая конфигурация 128Кх8 (для этих тестов все-равно более чем избыточна).

 

В качастве lookup engine использовал простую затычку на FPGA (отдельный корпус) – 8 статических записей.

Физический интерфейс Ethernet всего один , и маршрутизация выполняется между  VLAN.

 

Общий алгоритм работы следующий:

1. RXU принимается пакет в пакетный буфер, во время приема сразу подсчитывается контрольная сумма Ethernet, извлекается Ethernet и IP заголовок.
   
2. Если FCS корректна – запись в буфере помечается как готовая к лукапу и заголовок передается в lookup engine иначе запись используется для приема следующего пакета.
   
3. Lookup engine возвращает «паттерн преобразования» - новый DMAC, VID, и пакет в буфере помечается как готовый к передаче.
   
4. TXU передает пакет производя преобразования с использованием паттерна преобразования на лету и вычисляя новую Ethernet FCS
   
5. по завершении передачи TXU отмечает запись в пактном буфере как свободную.   
   

 

Ограничения в тестовом окружении:

• Ststic ARP
  
• Обрабатываются только тегированные 802.1q VLAN 
  
• Не декрементируется поле TTL IP пакета. 
  
• Hardcoded lookup table (routing table)
  

 

Обоснованно предполагается что на ИС семейства Cyclone 5 возможно реализовать форвардер для 10Г интерфейсов 

Что же касается Lookup Engine – отдельно тестировался в симуляции LE на 16M IPv4 роутов (максимально теоретически возможный BGP full View вследствии полной разагрегации сетей до /24) 

 

[Lynx100 90]

 

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

 

В целом задачу L3 маршрутизации можно разделить на две основных задачи пересылка данных между интерфейсами – forwarding и поиск маршрутов в таблице маршрутизации (lookup)

 

В своих экспериментах, которые я проводил пару лет назад, еще до войны я использовал ПЛИС ALTERA Cyclone-1 на 5К элементов и подключенный к нему MII Ethernet PHY (RTL8201BL) а также ИС SSRAM IDT71V546S 128Kx36 в качестве пакетного буфера. Древнесть элементной базы (12-15 лет) обусловлена ее наличием и принципом протянул руку до полки.

Особенности применяемой SSRAM позволяли эмулировать в ПЛИС ее работу как двухпортовой (временное разделение). Также для экономии ног между ПЛИС ипользовались только 8 линий данных SSRAM – т.е. фактическая конфигурация 128Кх8 (для этих тестов все-равно более чем избыточна).

 

В качастве lookup engine использовал простую затычку на FPGA (отдельный корпус) – 8 статических записей.

Физический интерфейс Ethernet всего один , и маршрутизация выполняется между  VLAN.

 

Общий алгоритм работы следующий:

1. RXU принимается пакет в пакетный буфер, во время приема сразу подсчитывается контрольная сумма Ethernet, извлекается Ethernet и IP заголовок.
2. Если FCS корректна – запись в буфере помечается как готовая к лукапу и заголовок передается в lookup engine иначе запись используется для приема следующего пакета.
3. Lookup engine возвращает «паттерн преобразования» - новый DMAC, VID, и пакет в буфере помечается как готовый к передаче.
4. TXU передает пакет производя преобразования с использованием паттерна преобразования на лету и вычисляя новую Ethernet FCS
5. по завершении передачи TXU отмечает запись в пактном буфере как свободную.   

 

Ограничения в тестовом окружении:

• Ststic ARP
• Обрабатываются только тегированные 802.1q VLAN 
• Не декрементируется поле TTL IP пакета. 
• Hardcoded lookup table (routing table)

 

Обоснованно предполагается что на ИС семейства Cyclone 5 возможно реализовать форвардер для 10Г интерфейсов 

Что же касается Lookup Engine – отдельно тестировался в симуляции LE на 16M IPv4 роутов (максимально теоретически возможный BGP full View вследствии полной разагрегации сетей до /24) 

 

если пойти дальше - получится Juniper

[ntil 57]

фича в том что стоимость самого железа весьма низка. нужный циклон 5 - порядка 100у.е. 

[ntil 57]

эту конструкцию не обязательно применять как бордер, думаю вполне можно использовать как агрегатор vlan-per-customer с большим количеством q-in-q интерфейсов (в теории 16М, т.е. полный диапазон q-in-q). я думаю возможен даже ip unnumbered. но при этом конечно потребуется модифицировать логику lookup engine.

 

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

[ttttt 195]

Ну это все наверное будет иметь смысл ближе к 100G.

Тут вон проблема, что мало желающих банально под архитектуру современных процессоров переписать стэк, чтобы лайнрейт 10G тянуть, а вы о FPGA

Изменено 2015-10-22 12:38:32 пользователем ttttt

[ntil 57]

fpga для такой задачи дешевле чем ксеон. и жрет меньше.

основные затраты в разработке - но я вот этим занимаюсь вообще для развлекухи за бесплатно.

[Чучундра 259]

 

Общий алгоритм работы следующий:

1. RXU принимается пакет в пакетный буфер, во время приема сразу подсчитывается контрольная сумма Ethernet, извлекается Ethernet и IP заголовок.
2. Если FCS корректна – запись в буфере помечается как готовая к лукапу и заголовок передается в lookup engine иначе запись используется для приема следующего пакета.
3. Lookup engine возвращает «паттерн преобразования» - новый DMAC, VID, и пакет в буфере помечается как готовый к передаче.
4. TXU передает пакет производя преобразования с использованием паттерна преобразования на лету и вычисляя новую Ethernet FCS
5. по завершении передачи TXU отмечает запись в пактном буфере как свободную.   

 

Ограничения в тестовом окружении:

• Ststic ARP
• Обрабатываются только тегированные 802.1q VLAN 
• Не декрементируется поле TTL IP пакета. 
• Hardcoded lookup table (routing table)

 

Обоснованно предполагается что на ИС семейства Cyclone 5 возможно реализовать форвардер для 10Г интерфейсов 

Что же касается Lookup Engine – отдельно тестировался в симуляции LE на 16M IPv4 роутов (максимально теоретически возможный BGP full View вследствии полной разагрегации сетей до /24) 

 

 

свичинг и форвардинг это конечно хорошо, но для полноценного бордера не хватает еще шейпера. Можно ли его реализовать на этом ПЛИС-е ?

Изменено 2015-10-23 19:32:03 пользователем Чучундра

[l1ght 377]

 

 

Общий алгоритм работы следующий:

1. RXU принимается пакет в пакетный буфер, во время приема сразу подсчитывается контрольная сумма Ethernet, извлекается Ethernet и IP заголовок.
2. Если FCS корректна – запись в буфере помечается как готовая к лукапу и заголовок передается в lookup engine иначе запись используется для приема следующего пакета.
3. Lookup engine возвращает «паттерн преобразования» - новый DMAC, VID, и пакет в буфере помечается как готовый к передаче.
4. TXU передает пакет производя преобразования с использованием паттерна преобразования на лету и вычисляя новую Ethernet FCS
5. по завершении передачи TXU отмечает запись в пактном буфере как свободную.   

 

Ограничения в тестовом окружении:

• Ststic ARP
• Обрабатываются только тегированные 802.1q VLAN 
• Не декрементируется поле TTL IP пакета. 
• Hardcoded lookup table (routing table)

 

Обоснованно предполагается что на ИС семейства Cyclone 5 возможно реализовать форвардер для 10Г интерфейсов 

Что же касается Lookup Engine – отдельно тестировался в симуляции LE на 16M IPv4 роутов (максимально теоретически возможный BGP full View вследствии полной разагрегации сетей до /24) 

 

 

свичинг и форвардинг это конечно хорошо, но для полноценного бордера не хватает еще шейпера. Можно ли его реализовать на этом ПЛИС-е ?

 

шейпер на бордере?

ничего не перепутали?

[NEP 217]

Для продакшена сыро.

Когда появится поддержка Реалтека! тогда и будем тестить

 

А ралтек даст 1 млн pps?

 

фича в том что стоимость самого железа весьма низка. нужный циклон 5 - порядка 100у.е. 

 

 

Фича в том, что стоимость ПЛИС для построения TCAM BGP full view будет стоить порядка 1000 у.е. Для того, чтобы роутить 1-н пакет за 1-н такт - нужно построить регистровую память, где 1-н БИТ - это триггер (два транзистора). А построить нужно МЕГАБАЙТЫ такой памяти.

Изменено 2015-10-24 04:30:05 пользователем NEP

[][-RaY 387]

Вот что то типа того похоже

http://rdp.ru/

[NiTr0 585]

 

 

Для того, чтобы роутить 1-н пакет за 1-н такт - нужно построить регистровую память, где 1-н БИТ - это триггер (два транзистора). А построить нужно МЕГАБАЙТЫ такой памяти.

SRAM есть готовая же, не проблема.

 

Ну и да, для простого бгп ipv4 роутинга достаточно всего 16М памяти (ну по 1 байту на /24 подсеть)... Правда для меньших подсетей придется городить еще что-то...

[ttttt 195]

А ралтек даст 1 млн pps?

А что ему помешает?

Это с 10G картами есть сложности, а гигабитные все дубовые.

[Чучундра 259]

 

 

 

шейпер на бордере?

ничего не перепутали?

 

таки перепутал, имелся  ввиду сервер доступа.