Jump to content

BGP 10G Soft Router Своими руками v1.0


Recommended Posts

В том, что ТКАМа нету? или в отсутсвии асика?

 

Это как бы одно и тоже

 

"асик" - это специализированный процессор с параллельно-конвейерной архитектурой реализованный на плис, на таких же плис, как ступень конвейера имплементируется TCAM.

:)

Имелась ввиду не сама-по себе ассоциативная память, а скорость её работы.

Да и асики разные бывают, по сути-то асик это проц заточенный под одну, вполне конкретную задачу, т.е. DSP тоже асики.

Link to post
Share on other sites
  • Replies 477
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

Nexus 9372 может уже 128к маршрутов, а 93180 - весь мильен. Вообще не вижу места серверу на бордере.

А смысл? Нынче железо настолько дёшево и быстро, что наоборот, в спец-железках все меньше и меньше смысла. Сервер за 300$ может жевать 10G, а это на минуточку уровень такого себе оператора средне

Posted Images

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

2. Вопрос весьма спорный, я получал сведения, что новые оптероны существенно быстрее работают с памятью.

Новые оптероны имеют те же ядра, что и FX8150 десктопный. Линейка с piledriver ядрами еще массово не продается, да и там скорее эволюция, чем революция - выше производительность на ядро, но хуже с латентностью (незначительно, в пределах погрешности). И латентность памяти и кешей у них выше, чем у феномов.

Пропускная способность конечно может быть и выше, за счет 4-канальной памяти у 62xx - но это все равно NUMA в одном корпусе, склейка из 2 ядер, и с все теми же большими задержками, от того не все так однозначно.

Link to post
Share on other sites

CAM используется для L2, снятия и постановки тегов вланов, поиска маков...

TCAM используется для ip маршрутизации, acl...

Думаю стоит расказать об это экстриму, который в своих х480 использует один и тот же ТКАМ как для маршрутов, так и для маков.

Link to post
Share on other sites

Новые оптероны имеют те же ядра, что и FX8150 десктопный. Линейка с piledriver ядрами еще массово не продается, да и там скорее эволюция, чем революция - выше производительность на ядро, но хуже с латентностью (незначительно, в пределах погрешности). И латентность памяти и кешей у них выше, чем у феномов.

Пропускная способность конечно может быть и выше, за счет 4-канальной памяти у 62xx - но это все равно NUMA в одном корпусе, склейка из 2 ядер, и с все теми же большими задержками, от того не все так однозначно.

Сложно сказать, я пилидрайвер (именно эту архитектуру я имел ввиду под "новыми оптеронами") я еще не щупал, но вот такие вот слух ходют, что с памятью они быстрее зеонов серии Е5 работают.

Link to post
Share on other sites

Думаю стоит расказать об это экстриму, который в своих х480 использует один и тот же ТКАМ как для маршрутов, так и для маков.

 

TCAM может эффективно решить обе задачи. И что? ntil привел реализацию референсного cam от actel, так что по вашему Екстрим использует это УГ? :)

Link to post
Share on other sites

Думаю стоит расказать об это экстриму, который в своих х480 использует один и тот же ТКАМ как для маршрутов, так и для маков.

 

TCAM может эффективно решить обе задачи. И что? ntil привел реализацию референсного cam от actel, так что по вашему Екстрим использует это УГ? :)

Ну если учесть, какие возможности заявляет экстрим для 480 - врят ли:)

Link to post
Share on other sites

Новые оптероны имеют те же ядра, что и FX8150 десктопный. Линейка с piledriver ядрами еще массово не продается, да и там скорее эволюция, чем революция - выше производительность на ядро, но хуже с латентностью (незначительно, в пределах погрешности). И латентность памяти и кешей у них выше, чем у феномов.

Пропускная способность конечно может быть и выше, за счет 4-канальной памяти у 62xx - но это все равно NUMA в одном корпусе, склейка из 2 ядер, и с все теми же большими задержками, от того не все так однозначно.

Сложно сказать, я пилидрайвер (именно эту архитектуру я имел ввиду под "новыми оптеронами") я еще не щупал, но вот такие вот слух ходют, что с памятью они быстрее зеонов серии Е5 работают.

У меня домашняя машина на этом самом пайлдрайвере(trinity FM2), с памятью там все то же что у атлонов стареньких.

Link to post
Share on other sites

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии )

 

Вводная

Протокол - IPv4

количество маршрутов - 1М

Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин.

Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию.

(тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно).

Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам.

 

 

как это работает:

по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска.

далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам.

 

В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ.

т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС

но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек.

соответственно 1200\16= 75 МППС

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

 

восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет).

 

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

 

Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

Link to post
Share on other sites

Сложно сказать, я пилидрайвер (именно эту архитектуру я имел ввиду под "новыми оптеронами") я еще не щупал, но вот такие вот слух ходют, что с памятью они быстрее зеонов серии Е5 работают.

Посмотрите обзоры FX8350. Результаты не лучше чем 8150-го. Да собссно никто и не заявлял чуда по части подсистемы памяти. +10% ipc на равных тактовых - да, наблюдается, меньшее потребление - наблюдается, на этом все и оканчивается.

Link to post
Share on other sites

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии )

 

Вводная

Протокол - IPv4

количество маршрутов - 1М

Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин.

Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию.

(тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно).

Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам.

 

 

как это работает:

по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска.

далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам.

 

В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ.

т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС

но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек.

соответственно 1200\16= 75 МППС

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

 

восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет).

 

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

 

Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

 

Бред.

 

Какой DDR2? :D Вы несете чушь! Вы вообще понимаете отличие DDR2 (SDRAM) памяти от SRAM? Понимаете что такое латентность? Вы понимаете, что латентность DDR может достигать сотен тактов спецпроцессора, а SRAM работает на частоте процессора и не имеет латентности по определению? И при произвольном доступе вот это 200\16=12,5 МППС вообще БРЕД в квадрате. Это можете поделить смело на 50, а лучше на 100 и получить свои сопливые 125 КППС и это ТЕОРЕТИЧЕСКИЙ потолок.

Link to post
Share on other sites

DDR2 SRAM !!статическая память!!. прочитайте внимательно! у меня ща на девборде припаяна. я прекрасно знаю отличия. у нее латентности (в тактах) нет, DDR2 просто говорит о стробировании сигнала на шине по обоим фронтам импульсов.

 

вовторых Ваши аргументы не обоснованы, т.к. не содержат соответствующей аргументации, только визги "БРЕД" :) чуствую что говорю не с технарем а с гумманитарием.

 

в третьих подтверждением корректности методики расчетов производительности служит собраный лично мною тестбенч на паре десятибаксовых первых циклонах на 20К вентилей, и SRAM памяти выпаяной хрен знает откуда.

Link to post
Share on other sites
Это можете поделить смело на 50, а лучше на 100 и получить свои сопливые 125 КППС и это ТЕОРЕТИЧЕСКИЙ потолок.

Аргументируйте, почему именно 50, 100 а не 1221 например?

Link to post
Share on other sites

у меня стоят новые 8150 и 8350 - могу с уверенность сказать что даже до i7 им далеко, неговоря уже о Xeon.

Так что в роутинге и перестройке таблицы БГП Интел до сих пор рулит.

Link to post
Share on other sites

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии )

 

Вводная

Протокол - IPv4

количество маршрутов - 1М

Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин.

Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию.

(тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно).

Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам.

 

 

как это работает:

по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска.

далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам.

 

В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ.

т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС

но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек.

соответственно 1200\16= 75 МППС

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

 

восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет).

 

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

 

Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

А это где так работает БЖП?

Помоему это время давно ушло в историю.

Link to post
Share on other sites

а причем тут бгп. ?

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

 

здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

Link to post
Share on other sites

а причем тут бгп. ?

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

 

здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

БЖП это протокол, а в софтовом роутере таблицу наполняет квага(например),

а аппаратный поиск, давно так не делается,

там проц тогда нужен, на соточной мыльнице, минимум 3-6 гигагерц, чтобы перелопатить поток с простой раскладкой пакетов по портам на уровне маков.

 

Сегодня уже и софтовые роутеры так не работают.

Аппаратные роутеры используют коммутационные матрицы, то же и софтовые, только в софтовый идет емуляция поля коммутации.

По крайней мере, это уже с нетфлова идет, глупо делать по другому.

 

Потому и говорят - таблицу наполняет.

Link to post
Share on other sites

а причем тут бгп. ?

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

 

здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

БЖП это протокол, а в софтовом роутере таблицу наполняет квага(например),

а аппаратный поиск, давно так не делается,

там проц тогда нужен, на соточной мыльнице, минимум 3-6 гигагерц, чтобы перелопатить поток с простой раскладкой пакетов по портам на уровне маков.

 

Сегодня уже и софтовые роутеры так не работают.

Аппаратные роутеры используют коммутационные матрицы, то же и софтовые, только в софтовый идет емуляция поля коммутации.

По крайней мере, это уже с нетфлова идет, глупо делать по другому.

 

Потому и говорят - таблицу наполняет.

Пожалуйста, прочитайте мои предыдущие посты. я какраз и сетую за хадверный роутер на ПЛИС, описывал и отстаивал методику расчета производительности движка выборки маршрута из уже для него, ХАРДВАРНОГО, специально оптимизированной для аппаратного разбора таблицы..

БГП там может хоть на АРМ крутится, не о нем реч.

Link to post
Share on other sites

Я сетую за софтовый.

Простой пример,

если у прова один маршрут, и он получил фюв, то хард всервно должен отчехлить под задачу матрицу по полной программе,

а софтовый, может заменить все хозяйство дефаултом.

 

Хардовый роутер, это винда, разрешено то что разрешено, кнопки нет - будь здоров.

софтовый это фря, нет кнопки нарисуем.

По производительности, хардовый обходит софтовый, потому как у него логический автомат заточен под решение распространненой задачи,

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

Если решать на софтовом аналогические задачи, то это на порядоу дешевле.

 

И если сегодня какойто производитель выпустит нормальную сетевую, которую интел уже сделал минимум пять лет назад,

то цыски накроются медным тазом.

 

Вот сижу и думаю, может сделать самому такую карточку, и посмотреть на реакцию интела.

Link to post
Share on other sites

если у прова один маршрут, и он получил фюв, то хард всервно должен отчехлить под задачу матрицу по полной программе,

а софтовый, может заменить все хозяйство дефаултом.

Кто помешает аппаратному роутеру забить один дефолт в ткам вместо горки роутов? Как собссно умеют те же 3550, которые кое у кого стоят вместо бордюров.

И какая принципиальная разница, куда control plane пихает роуты - в таблицу ядра, или в ткам?

Link to post
Share on other sites

Таблица ядра(коммутационное поле) это логический автомат,

там понятие "обработка", арифметика отсутствует как класс,

он работает согласно тактовой частоте,

у него нет понятия нагрузки и скорость обработки зависит от скорости работы полупроводниковых переходов,

а ткам, это память, которую юзает проц, который занимается арифметикой, пыхтит, греется и пугает всех 100%-ной загрузкой.

 

Пример коммутационного поля

http://www.intuit.ru/department/network/telenetdev/1/

 

Link to post
Share on other sites

а ткам, это память, которую юзает проц

C какой такой радости? Как раз в ткаме и живет таблица маршрутизации. И наполняется она контрол плейном, на его усмотрение. Контрол плейн может и один роут туда вбить, дефолт, вместо фулл вью, а фулл вью при этом держать только в контрол плейне и анонсить соседям оттуда же. Никто собссно не запрещает.

Link to post
Share on other sites

а ткам, это память, которую юзает проц

C какой такой радости? Как раз в ткаме и живет таблица маршрутизации. И наполняется она контрол плейном, на его усмотрение. Контрол плейн может и один роут туда вбить, дефолт, вместо фулл вью, а фулл вью при этом держать только в контрол плейне и анонсить соседям оттуда же. Никто собссно не запрещает.

 

Есть понятие память,

есть понятие что с нее можно слепить,

есть понятие софтовая коммутационная матрица,

и есть понятие хранение таблицы в памяти.

Если память использовать как хранилище в котором находится таблица маршрутизации,

то нужен проц, который будет дергать регистры и сравнивать с ип адресом,

на эту задачу уйдет вагон машинных циклов.

Но есть память использовать как матрицу для построения коммутационной таблицы,

то нужен один машинный цикл, для получения результата.

 

Вот ответ, мегапризводительности.

Хардовый роутер отправляет пакет, без участия проца, за один такт кварца.

Софтовый роутер, тратит несколько машинных циклов для решения аналогичной проблемы,

алгоритм который описал ntil.

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

сегодня на таких задачах используют метод матриц прямого доступа.

Цыфры ип адреса, это не значения а координаты точки выхода,

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

Это мгновенная операция и даже на софтовом уровне обойдется парой машинных циклов.

 

То что сейчас подняли в данном топике, это оптимизация работы сетевой карты,

на предмет парализации потоков, это вариант масштабирования,

но не оптимизации решения задачи, продавливание лбом.

Вариант где замахнулись на 100гиг - использование процессора видеокарты кубо, проца производительней чем риск процессора.

Тоже продавливание задачи лбом.

Третий вариант от интела, это самый перспективный вариант, который они положили пол сукно, до хороших времен.

Он заключается в сращивании аппаратного решения и софтового...

Сегодня, на базе наличного парка микросхем, можно самому сделать решения с паяльником, на коленке,

и такой роутер будет дешевле и производительней на порядок аппаратного.

 

Вот только никак не разродятся.

 

Отсюда, софтовый роутер, уделает аппаратный.

Link to post
Share on other sites

а ткам, это память, которую юзает проц

C какой такой радости? Как раз в ткаме и живет таблица маршрутизации. И наполняется она контрол плейном, на его усмотрение. Контрол плейн может и один роут туда вбить, дефолт, вместо фулл вью, а фулл вью при этом держать только в контрол плейне и анонсить соседям оттуда же. Никто собссно не запрещает.

 

Есть понятие память,

есть понятие что с нее можно слепить,

есть понятие софтовая коммутационная матрица,

и есть понятие хранение таблицы в памяти.

Ознакомьтесь лучше, что такое ткам, и в чем его отличие от памяти контрол-плейна...

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...