CPU и пропускная способность роутера

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

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

Вариант с железом Juniper, Cisco и т.п. интересует только если сервер с юниксом не потянет физически такую нагрузку, ни с каким процессором. Что у джуников, что у цисок обнаружилась масса весьма неприятных подводных камней, да и железки которые будут гонять нужный нам трафик обойдутся в поистине космические деньги. И потому хочется понять предел, насколько можно нагрузить какой-нибудь Xeon в качестве магистрального роутера.

Vyatta рекламит что-мол комп с одним Xeon QC 2.53 и дебианом гоняет 4 ГБит/с, но это всё ж реклама. Интересует реальное применение хотя бы на честном гигабите.

из личного опыта:

проц Intel® Core 2 Quad Q6600, 2.4GHz/1066MHz/8MB
сетевухи PWLA8492MT, Intel® PRO/1000 MT Dual Port Server Adapter

FreeBSD, BGP full-view, примерно 200000 pps, 500мбит трафика. И еще запас довольно приличный по производительности остается.

> И еще запас довольно приличный по производительности остается.

CPU load?

И ведётся ли статистика? netflow, ipcad...

Сейчас как раз час пик, загрузка CPU 30-40%.
На этой машине netflow нету, если бы был, то ядерный ng_netflow отъел бы примерно 30-50%.

В линуксе по netflow я не в курсе. Если есть что-то, что работает на уровне ядра, то надо его использовать. User space демон не потянет скорее всего такую нагрузку.

300-400 абонентов - это всего или в час пик? Если всего и роутер используется для объединения локалок, то аналогичный по мощности сервер справится без проблем. Главное на сетевых картах не экономить.

> На этой машине netflow нету, если бы был, то ядерный ng_netflow отъел бы примерно 30-50%.

А вот это не есть good. У нас правда не нетфлоу как таковой, а ipcad со своими дампами. Пишется от кого, кому и сколько. Нам это жизненно необходимо.

> 300-400 абонентов - это всего или в час пик?

~250 юриков всего - сейчас, 95% сидят на трафике. С установкой этого сервака планируется ввести массовые анлимы с шейпером (шейпить будем на местах, с этим проблем нет), что автоматически повлечёт массовое качалово торрентов с рабочего места и прочие прелести. Нам не жалко, у нас flat-rate... Но боимся что сервак ляжет. И ещё больше боимся что ляжет когда наберём ещё клиентов и придётся на полном серьёзе гонять гигабит.

> Если всего и роутер используется для объединения локалок, то аналогичный по мощности сервер справится без проблем.

Роутер в первую голову под BGP на IX, а также раздачу и подсчёт трафика с жирных каналов на непосредственно объекты. VPN между объектами делаются крайне редко и не силами железки на IX.

> Сейчас как раз час пик, загрузка CPU 30-40%.

Посмотри ещё, оно при этих 30-40% насколько каждое ядро загружает? В "top -S" колонка C, на каком ядре процесс крутится...

Одно ядро только нагружается на 30-40%. На сетевухах polling включен (аналог NAPI в линуксе), он в FreeBSD плохо с многопроцессорностью дружит.

Если взять железо помощнее, должно потянуть без проблем.

Можете поспрашивать еще на http://forum.nag.ru/, там больше спецов в подобных вопросах.

в книжке про linux qos и т.д. автор писал, что два ксеона и пару тысяч правил tc, iptables держат 400 мбит и не напрягаются особо

а взять на тестирование железо или в аренду нельзя для тестов?

> а взять на тестирование железо или в аренду нельзя для тестов?

Жирного канала где можно было бы развернуться пока нет, он только будет. А гонять сейчас образы дисков между двумя компами по FTP через этот сервак - нет чистоты эксперимента. А потом о как будем расширяться кажется что гигабит или сотни тысяч соединений оно не может или может со страшной перегрузкой, нам такие варианты не нужны... Поэтому полагаюсь только на опыт людей по форумам.

Есть же трафикогенераторы. Пакет поменьше поставь и тестируй.
Еще вроде какой-то умеет дампы tcpdump'a слать.

> 1 гбит/с на 300-400 клиентов

всё очень меняется от того что это за трафик. Сколько будет соединений в таблице conntrack(а лучше без него, тем более nat не нужен) и сколько pps будет.

Я всё же склоняюсь к тому что надо стенд собирать и мерять нагрузку в условиях приближенных к реальности. И учитывать что тачку убивает грузит не трафик сам по себе(хотя и тут затык поймать можно) а pps.

PS polling тока на входящий траф работает, на исходящий не действует. Да и нормальные сетевушки сами кое-какие операции оптимизируют, поэтому не уверен что поллинг сильно поможет. По крайней мере принципиальной разницы на реальном потоке в 500мбит на селероне не заметил. А вот фаервол просаживал проц очень сильно.

iptables без правил+conntrack снижает кпд на 30%. читал в рассылках netfilter

на линухе не проверял, а на фре нагрузка раз в десять возрастала по top после pfctl -e.

если бы не подсчет трафика, то L3 свитч вас спас бы.

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

блин, там бридж был а не рутер, сорри

использовать во freebsd на таких каналах pf довольно глупо :]

> всё очень меняется от того что это за трафик

Сейчас как обычно - аська, www, почта, местами voip. С введением анлимов чувствую начнутся торренты и прочие edonkey... С одной стороны каналы к юзерам там будут тухлые, с другой каналов этих будет много. А надо ещё и в развитие чтобы железка всеми правдами и неправдами 1-2 гигабита в пределе гоняла + BGP.

Вариант с умным свитчем не покатит - IP "брать" не у кого, своя AS-ка, нужен именно роутер.

> iptables без правил+conntrack снижает кпд на 30%

Это то есть как? Делаем policy forward accept, iptables -F и получаем _бОльшую_ загрузку CPU? Это странно как-то...

> получаем _бОльшую_ загрузку CPU?

делаем modprobe iptables и получаем нагрузку. Что логично, фаервол "просматривает" каждый пакет.

> А надо ещё и в развитие чтобы железка всеми правдами и неправдами 1-2 гигабита в пределе гоняла + BGP.

тогда сразу подбирай такую чтобы справилась. Гигабтные каналы в bound объеденяете? Или сразу 10gb интерфейс? :)

> использовать во freebsd на таких каналах pf довольно глупо :]

в чём именно глупость? На тачке селерон, справляется нормально, аптайм 500 дней был когда заходил в последний раз месяц назад.

>Это то есть как? Делаем policy forward accept, iptables -F и получаем _бОльшую_ загрузку CPU? Это странно как-то...

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

> делаем modprobe iptables и получаем нагрузку. Что логично, фаервол "просматривает" каждый пакет.

А если iptables вообще из ядра выкинуть, на что это повлияет?

> тогда сразу подбирай такую чтобы справилась.

Я думал может кто уже вживую подобные вещи гоняет, чтобы по опыту знать какие всё-таки железки брать. Стенд собирать всё-таки я боюсь реальной картины не получится.

И это, никто так толком и не сказал - параллелится всё-таки роутинг на несколько процессорных ядер? Кто-то говорит роутинг одно ядро грузит, у Виатты на сайте написано если 4 гигабита вам мало вкрутите ещё 1 проц и будет 8 гбит гонять. Кому верить? :)

> Гигабтные каналы в bound объеденяете? Или сразу 10gb интерфейс? :)

Не, если и будет 2 гига, то только в варианте 1 до одного аплинка и 1 до другого и ещё 1 гиг до клиентов. Доп. сетевушку двухпортовую вкрутим просто.

> А если iptables вообще из ядра выкинуть, на что это повлияет?

ты процетировал то на что это может влиять.

> Стенд собирать всё-таки я боюсь реальной картины не получится.

Реальная картина будет тока в реальности. А на стенде ты проведёшь оценку.

Мой прогноз: обычный современный писюк справиться, мне кто-то говорил о положительном опыте эксплуатации ксеона вместо циски. Тока на счёт шины не уверен, смотри чтобы производительности хватало. Лучше если сетевые будут pci-express.

> ты процетировал то на что это может влиять.

Я не про скорость, что функциально от этого исчезнет кроме фаервола? Нужен ipcad и всякая мелочь по мониторингу типа tcpdump, nload... Если сосбтвенно сам фаервол и шейпер работать не будут, а остальное будет то это замечательно.

> Лучше если сетевые будут pci-express.

Да это и так понятно, уже нацелились на Intel двухпортовые.

> Я не про скорость, что функциально от этого исчезнет кроме фаервола?

Думаю что ничего не исчезнет в твоём случае. Но я бы фаервол оставил. Вот с conntrack сложнее, правил будет в нём десятки миллионов. В принципе, для него это не проблема.

Как поведёт себя ipcad на таких скоростях уже не помню, но, вроде справлялся на 300-500мбит.

Короче, мой прогноз даже с фаерволом и ipcad будет работать на core 2 duo исходя из того что фаерволить 500мбит трафа вообще не проблема для современных ксеонов.

на самом деле в ваших задачах цпу не будет критическим местом. Критическими будут ваши сетевые платы. Из личного опыта могу сказать, что была проблема с сетевухами длинка (поллинг как-то не очень хотел работать, имхо - кривая реализация драйверов)
Просто роутить трафик - проц сильный не нужен (нужно будет только оттюнить сетевой стек, чуть больше 100мбит спокойно роутит Пентиум 266). 
Насчет подсчета трафика - тут уже как вы захотите. Если вы хотите считать средством iptables - гигабит ничего не вытянет, если netflow/sflow - тут уже как настроите (sflow менее требователен, т.к. не каждый пакет берется)

и забыл еще добавить. Реально гигабит можно раскачать только на сетевых картах PCI-X

Пропускной способности pci-e вполне хватит. Даже 1x.

хм, забавная идея два гигабитных реалтека патчкордом соединить. Как-нить на досуге iperf погоняю.

возможно ли разнести маршрутизацию, BGP и подсчёт трафика на разные машины? BGP и маршрутизация - понятно, а подсчёт зазеркаливанием порта? Больше точек отказа, правда...

как то было необходимо соединить новеловский сервак который стоял в одной подсетке, с а доступ к нему шел в основном из другой в общей сложности машин было около 90 - и соединять пришлось сервером - потому что ipx-трафик надо было пропускать весь а ip- очень избирательно - свич не поставишь ... поставился linux две сетевухи 100mb pci ipxbridge и нетфильтер - загрузка проца была - 1-3%(p4-2400) но при этом пользователи при дневой нагрузке испытывали затыки - затыки эти точно изза проброса трафика между сервером - потому что остановка хаба тут же убирала все затыки. трафик когда начинались затыки был около 70 мбит примерно...

давно это было но может поможет :)

опечатался - остановка - постановка хаба - вместо сервера

1. Берёшь процы с максимальной частотой из расчёта "одно ядро на один физический интерфейс (неважно, роутить ты между ними будешь, или в бонды объединять) плюс хотя бы одно ядро для остальной системы". На сколько денег хватит.
2. Собираешь conntrack модулем (на всякий случай), и не загружаешь его -> убираешь из iptables таблицу nat и все правила со --state. Или придумываешь способ обхода через таблицу raw.
3. Тюнишь всякие route table hash или как их там, чтобы роутинг меньше жрал, но это уже не особо влияет.
4. Если есть возможность обойтись без netflow и реальной детализации по портам и протоколам, ограничившись только статистикой по IP адресам, поднимаешь ipcad с capture-ports disable.

Получаешь систему, способную смаршрутизировать любой траффик до гигабита на каждую сетевуху. Даже вне зависимости от количества соединений. Главное только не включать ничего, связанного со --state или таблицей nat.

Шейперы (tc/htb) и фаерволл на форвард (iptables + ipset) позволяют достаточно гибко себя настраивать. До состояния, когда что есть фильтрация, что её нет, не важно. Ну, ладно, с шейперами сложнее, но iptables можно докрутить до такого вне зависимости от общего количества правил.

В своё время два Dual-Core Xeon 5160 с шестью сетевухами (две встроенные плюс две по два порта, все intel e1000) в двух бондах и двумя full view в quagga спокойно рулили два с половиной гигабита. И был ещё тридцатипроцентный запас прочности.

Если требуется полная детализация траффика, будет не всё так хорошо, в этом случае ipcad будет жрать прилично, и надо смотреть. За вируснёй следить. Но при нормальном траффике без аномалий гигабит обсчитает легко. На 3.0ГГц :) Меньшую частоту не имею, сказать точно не могу. Возможно, в этом случае стоит поискать альтернативы ipcad'у.

рекомендую почитать здесь: http://forum.nag.ru/forum/index.php?showtopic=46366
сам дистр очень хорошие показатели дает