LINUX.ORG.RU

Тестирование производительности и управление трафиком в iptables


0

0

Николай Малых провел тестирование производительности iptables для определения задержек вносимых при обработке пакетов в больших (десятки тысяч правил) таблицах iptables.

Для тестирования использовался встроенный в ядро Linux генератор пакетов, который создавал поток пакетов UDP, адресованных в порт discard (9) тестового хоста.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Интересно такой же тестик для сравнения с OpenBSD, например. И для ipv6.

realloc ★★★★
()

Мне не совсем понятна практическая ценность такого сорта тестов, где

приводятся некоторые абсолютные цифры.

Другое дело, если бы автор показал, например, что netfilter на х%

быстрее того же pf или ipf?

Sun-ch
()

у вас всё показывается? у меня connection failed. если есть возможность можете куда-нить выложить это дело?

sakura-obscura
()
Ответ на: комментарий от Sun-ch

> Мне не совсем понятна практическая ценность такого сорта тестов, где

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

realloc ★★★★
()
Ответ на: комментарий от Sun-ch

> Мне не совсем понятна практическая ценность такого сорта тестов, где приводятся некоторые абсолютные цифры.

Ценоость (некоторая) для того, кто пользовать соберётся. Если у меня уже linux то подобные оценки могут сказать, что скорость работы приемлимая (или же нет). В этом случае, сравнение с другими fw - не обязательно. Хотя и не было бы лишним...

atrus ★★★★★
()
Ответ на: комментарий от realloc

Фигня это все.

В реальной жизни, обычно обрабатываются пакеты, устанавливающие

соединение а дальше только отслеживается состояние (keep-state)

Sun-ch
()
Ответ на: комментарий от Sun-ch

> Фигня это все.

> В реальной жизни, обычно обрабатываются пакеты, устанавливающие соединение а дальше только отслеживается состояние (keep-state)

По флажкам tcp пакета смотреть можно, а вот по udp не судьба :-( Но даже по tcp это не спасает от левого трафика.

Спасает конечно conntrack, а теперь появилась даже надежда, что он и для ipv6 будет.

anonymous
()
Ответ на: комментарий от anonymous

>По флажкам tcp пакета смотреть можно, а вот по udp не судьба

у pf есть keep state для udp пакетов: считает промежутки времени между пакетам что-ли, но мне всегда внушала недоверие такая особенность; хотя вроде работает...

Pi ★★★★★
()
Ответ на: комментарий от Sun-ch

> быстрее того же pf или ipf?

Нет, он не быстрее, он просто работает на нескольких десятках тысяч
правил... в отличие от того же pf ;)

annonymous ★★
()

имхо неправильный и ничего не показывающий тест.

вот если попробовать матчить надо на основе src/dst ip, да на роутере/бридже, вот тогда видно насколько iptables тормоз и насколько нуждается в кардинальном изменении(всякие bsd pf/ipf кстати ненамного отличаются)

пример того КАК надо это делать и как надо матчить правила - nf-hipac (http://hipac.org/), но к сожалению проект можно считать мертвым, так как для 2.6 рабочих версий нет, а для 2.4 последняя версия под 2.4.25, и та иногда валится.

devil
()
Ответ на: комментарий от Pi

4k

> у pf есть keep state для udp пакетов
у iptables тоже есть нечто подобное, иначе NAT для UDP был бы просто невозможен

mumpster ★★★★★
()
Ответ на: комментарий от devil

4k

> идно насколько iptables тормоз
бред - hipac сделан на основе iptables
"which traverses the rules in a chain linearly per packet until a matching rule is found "
- ну так сделай ветвление! сразу получишь сущственный выигрыш
я так скажу - в наше время PIV и PCI-X - это уже небольшая проблема
даже с шифрованием трафика 10мбит эзер не может выйти за пределы 0.00 0.00 0.00 :-)

mumpster ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.