Бордер router на БУ железе, просьба оценить и посоветовать что нить.

Сильно зависит от количества клиентов/задач.

Если за этим «бордером» будет один кастомер то почему и нет :)

А так, сервер он для серверства, а бордеру свою железо нужно.

у меня есть сомнения по поводу

1) работает ли tcp offload engine под линуксов вообще (возможно, потребуются экзотические дрова)

2) нужен ли этот offload для роутера. По-моему, нет, он же пакеты форвардит, на содержимое плевать.

А по поводу производительности... А сколько нужно-то?

На железке планирую установить модуль ipt_NETFLOW, возможно будут правила iptables для влючения/отключения абонентов + bird.
Думаю если железка прокачает не менее 1Гбит/с реального трафика с учетом функций то будет хорошо.
Может кто такую железку реально использует под аналогичные задачи?

а каналы в интернет какие?

1 провайдер - 1 сервер. 1Гбит/с к провайдеру - 1 Гбит/с внутрь АС. Схема - один основной провайдер другой резервный.

Зароутить гигабит реального трафика (а не мелких пакетов по 64байта, тут может и забуксовать) для этого сервера раз плюнуть. Но вот сколько отожрут всякие netflow и bird я хз. Надо бы потестить... Возьми железку какая есть в наличии и устрой тест. Для реалистичности можно миррорить на неё реальный трафик.

Спроси лучше на форумах/мейлах quagga или bird, им виднее.

bird совсем не отъедает ресурсы и он работает, как это правильно сказать с обычным приоритетом в userspace. вот netflow грузит однозначно. Каждый сетевой пакет должен попасть в этот модуль.

pps так же важен

вот netflow грузит однозначно.

При трафике мегабит в 200 загрузки от ipt_NETFLOW не видно практически на Intel Q8300 .

1 провайдер - 1 сервер.

Кстати, если бордеров будет более двух, нужно будет или full mesh делать, или рефлектор.

Гигабит должно зароутить без проблем. Сетевые лучше двухпортовые, чем однопортовые, если будет fv собирайте ядрос LC_TRIE

Описание вашего броадкома я читал по диагонали, но вроде там про количество очередей ни слова, а значит эти ваши 8 ядер вряд ли помогут (RPS разве что). Для гигабита вполне хватит 4х ядер, лучше тут выбрать побольше частоты и побольше кеша. Два ядра E6800@3.33GHz нормально роутят 700М, ничего кроме fv нет.

будет или full mesh делать, или рефлектор.

если их будет 2 - достаточно будет только full mesh. А вот если больше - тогда отражатель или конфедерации(ну это если совсем...)

А, и да - если это не критично - выруби conntrack на системе совсем. Делай только stateless-firewall - поможет сэкономить ресурсов

«если будет fv собирайте ядрос LC_TRIE»

а это что?

А вот это к чему относится?
«MSI allows interrupt distribution in a multi-CPU host system.»

«лучше тут выбрать побольше частоты и побольше кеша»

Частота понятно а в кэш процессора разве поместится bgp fullview ?

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

«MSI allows interrupt distribution in a multi-CPU host system.»

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

LC_TRIE - метод хранения роут таблицы в ядре, по дефолту хештаблица.

MSI вам конечно размажет прерывания одной очереди по всем ядрам,

Кстати, как выясняется, далеко не везде. Есть зависимость от материнки.

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