Ethernet даптер с аппаратным ACL

iptables не модно уже?

Дело не в моде, куча мелких пакетов нагружает ЦП обработкой прерываний.

Аппаратный роутер пробовали? в нем то же iptables

Вы хотите сказать, что нагрузка такая, что роутер не справится? Не верю.

Это что за ЦП такой и куда смотрит интерфейс?

куча мелких пакетов нагружает ЦП обработкой прерываний.

Давно уже есть interrupt coalescing и interrupt mitigation.

nVidida ActiveArmor ?

т.е. nVidia

«аппаратный роутер» это длинк-дир-300? это же смешно. 700-800к пакетов/сек могут уделать железку уровня i7 + 82545EM, а это SOHO говно еле-еле тянет 1к

много мелких пакетов это настоящая головная боль. я даже не знаю как тут обойтись без настоящего аппаратного роутера/фаервола.

Хм. Впечатляет. А zyxel zywall какой-нибудь справится?

intel 82599 ))

Аппаратный роутер пробовали? в нем то же iptables

В каком месте?

Давно уже есть interrupt coalescing и interrupt mitigation.

Я знаю, что такое реализовали люди из яндекса, для интеловских сетевых карт и под freebsd. А так это еще где-то есть?

Я знаю, что такое реализовали люди из яндекса, для интеловских сетевых карт и под freebsd. А так это еще где-то есть?

Что «это» - coalescing? Это свойство карты (man ethtool), яндекс не при делах. Interrupt mitigation - это NAPI, не новая уже вещь (несмотря на N), и яндекс тоже вроде не при делах. Может, мы о разных вещах говорим?

Может быть о разных. Но вроде как каждый приходящий фрейм вызывает прерывание. Но в яндексе смогли изменить это поведение и запилить драйвера, которые ведут себя по-другому. Лично наблюдал, как «шейпер» на каком-то 2-х ядерном ксеоне обслуживал 5к абонентов имея загрузку в ~20-30% на ядра.

судя по тестам например ZyWALL 5, он ни чем не лучше обычного роутера с линуксом и айпитейблс

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

Но вроде как каждый приходящий фрейм вызывает прерывание.

Настраивается в карте (не во всех картах, конечно).

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

Сильно сомневаюсь, что драйвера без поддержки устройства способны на такой трюк. Разве что в каких-то узких условиях (одно устройство на IRQ, например).

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

Не могу спорить, просто слышал что только из яндекса и только для интеловских и только во фре такое сделано, собственно и видел. Но на самом деле аппаратные роутеры рулят :)

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

Нужно для предотвращения DDoS

ТС, есть же разные методы и не обязательно производить фильтрацию на своей стороне. Можно просить вышестоящего провайдера заворачивать трафик на атакуемый ip в null. А если вы еще и имеете связность с провайдером по bgp, то существует метод с названием bgp blackhole community. Расписывать смысла нет - легко гуглится, смысл лишь в том, что вы от себя сможете управлять фильтрацией трафика на стороне вышестоящего провайдера.

а масса шейпов там летает не благодаря не дровам, а благодаря кавайной связке ipfw2 tablearg dummynet

а масса шейпов там летает не благодаря не дровам, а благодаря кавайной связке ipfw2 tablearg dummynet

Я просто полагал _такое_ количество трафика сможет запросто нагнуть обычный PC.

та нет, без шейпов пайпов айпитейблов линух тянет такой же трафик как и фря. ну +-

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

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

если дос идет всего с нескольких адресов, то просите провайдера отфильтровать. если это настоящий ддос с огромного количества адресов тогда ... я вам не завидую %)

просто слышал что только из яндекса и только для интеловских и только во фре такое сделано

Из всего этого можно поверить в «только для интеловских».

и да, оч трудно рулить кваггой когда

тазик даже на намлок не овечает %) (это к вопросу о блекхолах)

ну и какой вывод? - нафиг тазики :)

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

ВСё же не в Яндексе. NAPI тут уже упомянули. Далее, надо выбрать

1. сетевую карту, для которой есть драйвер с поддержкой NAPI
2а. сетевую карту, у которой есть отдельная очередь на приём и отдельная на передачу
2б. сетевую карту, у которой не две очереди, а больше
3. многоядерный процессор и несколько многоядерных процессоров.

Что касается 1 - intel e100 и e1000 давно работают в NAPI, e1000e - не очень давно.
Что касается 2 - не каждая карта Intel имеет более одной очереди, тут надо выбирать внимательно. Плюс драйвер может быть собран без поддержки нескольких очередей.

Что касается процессоров/ядер. Некоторые системы (железки в смысле) допускают обработку прерывания несколькими ядрами, некоторые нет. Это, наверное, от контроллера прерываний зависит. В случае систем, обрабатывающих прерывания всеми ядрами, сначала можно ничего не настраивать, хотя говорят, что обработку прерываний от сетевых карт лучше выводить на одно ядро для одной очереди. В случае систем, которые так не умеют, надо сразу проверить, что там много прерываний на одно ядро не сели, а то будут спецэффекты. Ну и irqbalance.

800к пока что нечем было сделать, но порядка 80к сделал - на проце оба ядра загружены на 100%, но LA невелик: даже браузер шевелится рядом, страницы открывает. ethstatus показывает, что ошибок нет. Проц - AMD Athlon(tm) 64 X2 Dual Core Processor 5000+

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

130к пакетов, LA приближается к 4, проц - Зеон, 3 ггц. Держит - на все пинги отвечает