Jump to content
Калькуляторы

ipt-ratelimit трафик полисинг в iptables

Так должно стрельнуть:

 

diff --git a/compat.h b/compat.h
index 6e0c8af..35d0709 100644
--- a/compat.h
+++ b/compat.h
@@ -1,8 +1,9 @@
-
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3,19,0)
static inline bool seq_has_overflowed(struct seq_file *m)
{
       return m->count == m->size;
}
+#endif

#if LINUX_VERSION_CODE < KERNEL_VERSION(3,15,0)
void kvfree(const void *addr)

 

Фикс в гит добавили.

Share this post


Link to post
Share on other sites

Так стреляет, спасибо.

make -C /lib/modules/4.1.7-200.fc22.x86_64/build/ M=/root/ipt-ratelimit-master modules CONFIG_DEBUG_INFO=y

make[1]: вход в каталог «/usr/src/kernels/4.1.7-200.fc22.x86_64»

CC [M] /root/ipt-ratelimit-master/xt_ratelimit.o

Building modules, stage 2.

MODPOST 1 modules

CC /root/ipt-ratelimit-master/xt_ratelimit.mod.o

LD [M] /root/ipt-ratelimit-master/xt_ratelimit.ko

make[1]: выход из каталога «/usr/src/kernels/4.1.7-200.fc22.x86_64»

sync

gcc -O2 -Wall -Wunused -fPIC -o libxt_ratelimit_sh.o -c libxt_ratelimit.c

In file included from /usr/include/stdint.h:25:0,

from /usr/lib/gcc/x86_64-redhat-linux/5.1.1/include/stdint.h:9,

from libxt_ratelimit.c:24:

/usr/include/features.h:148:3: предупреждение: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]

# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"

^

gcc -shared -o libxt_ratelimit.so libxt_ratelimit_sh.o

rm libxt_ratelimit_sh.o

Share this post


Link to post
Share on other sites

Итак, запустили модуль в продакшн.

Стоит уже двое суток

Машинка 2x Intel Xeon E5649

X520-DA2

на Машине запущено:

1. NAT

2. IPT_Netflow

3. IPT_Ratelimit

4. NFQUEUE_Filter

5. Другя мелочь (Ipsetы, хитрый CAR для ограничения почты, quagga)

 

root@nat-10g-4:/# cat /proc/net/ipt_ratelimit/limit_in | wc -l
17902

Рядом стоит такая же машина но в связке с BRASом, без IPT_Ratelimit, разница в загрузке CPU при сравнимом трафике ~3%

 

Модуль без проблем переваривает >10Gb/s In+Out.

По полисингу впечатления следующие:

1. Немножко переливает (вместо 30 мегабит, speedtest.net показывает 31.5, вместо 10 мегабит, выдает 10.3) - но это даже хорошо, недовольных абонентов нет.

2. Это полисер, поэтому в начале есть бёрст вплоть до 300 мегабит в гиговом порту, но потом скорость опускается до тарифной, на железных брасах было тоже самое, потому уже привыкли к этому.

в целом полисит довольно ровно, на торрентах и http/ftp, все четко по тарифу, прямо красота.

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

 

AABC, есть вопрос.

Насколько тяжелая процедура для модуля - дерганье из файла cat /proc/net/ipt_ratelimit? Нам для отказа от BRASа не хватает аккаунтинга, планировали сделать аккаунтинг из данного файла?

Привыкли к железным BRASам, радиусу и "сессиям", вот хотим попробовать "эмулировать" это скриптами.

cpu.png

pps_in.png

pps_out.png

traf_in.png

traf_out.png

total_pps.png

Share this post


Link to post
Share on other sites

В итоге модулем очень довольны

Спасибо за тест.

 

AABC, есть вопрос.

Насколько тяжелая процедура для модуля - дерганье из файла cat /proc/net/ipt_ratelimit?

 

Сам интерфейс seq_file довольно медленный (в этом можно убедиться сделав time cat /proc/net/nf_conntrack). В остальном должна быть не большая нагрузка. Попробуйте делать cat с нужной вам частотой и напишите на сколько увеличилась нагрузка. Вам нужно 1 строку часто считывать или всю таблицу, и как часто?

 

Нам для отказа от BRASа не хватает аккаунтинга, планировали сделать аккаунтинг из данного файла?

 

Что именно? Там же и сейчас есть подсчет пакетов и байтов (conf+rej pkt/bytes).

Share this post


Link to post
Share on other sites

Тестируем, пока впечатления только положительные.

 

а действие обновить, и если нет добавить (к примеру =) скорость имеет смысл?

 

echo +10.10.0.1,10.10.0.5 10000000 > /proc/net/ipt_ratelimit/test_out

echo =10.10.0.1,10.10.0.5 20000000 > /proc/net/ipt_ratelimit/test_out

Share this post


Link to post
Share on other sites

Просто подсети не подойдут? (Они планируются.)

 

Подсети были бы очень кстати. Пока приходится парсить подсеть на отдельные адреса при добавлении, что не совсем удобно.

 

В остальном все просто замечательно. Огромное спасибо за идею и реализацию!

Share this post


Link to post
Share on other sites

В итоге модулем очень довольны

Спасибо за тест.

 

AABC, есть вопрос.

Насколько тяжелая процедура для модуля - дерганье из файла cat /proc/net/ipt_ratelimit?

 

Сам интерфейс seq_file довольно медленный (в этом можно убедиться сделав time cat /proc/net/nf_conntrack). В остальном должна быть не большая нагрузка. Попробуйте делать cat с нужной вам частотой и напишите на сколько увеличилась нагрузка. Вам нужно 1 строку часто считывать или всю таблицу, и как часто?

 

Нам для отказа от BRASа не хватает аккаунтинга, планировали сделать аккаунтинг из данного файла?

 

Что именно? Там же и сейчас есть подсчет пакетов и байтов (conf+rej pkt/bytes).

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

Выгребать планируем весь файл для подсчета трафика (раз в пять минут)

А так же одну строчку для просмотра "сессии", эпизодически, но может быть и 5-10 раз в минуту по запросу из OSS системы.

 

Вопрос больше, как доставить эти циферки в биллинг :), попробуем складировать сразу в базу.

Но если не получится, есть мысли дописать к модулю RADIUS обвязку, как в LISG :)

Share this post


Link to post
Share on other sites

Тестируем, пока впечатления только положительные.

 

а действие обновить, и если нет добавить (к примеру =) скорость имеет смысл?

 

echo +10.10.0.1,10.10.0.5 10000000 > /proc/net/ipt_ratelimit/test_out

echo =10.10.0.1,10.10.0.5 20000000 > /proc/net/ipt_ratelimit/test_out

Update как-то уже начал кодить, но потом понял, что это лишнее усложнение. На практике, всегда можно делать -... +... Спасибо за тестирование!

Share this post


Link to post
Share on other sites

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

Выгребать планируем весь файл для подсчета трафика (раз в пять минут)

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

 

А так же одну строчку для просмотра "сессии", эпизодически, но может быть и 5-10 раз в минуту по запросу из OSS системы.

Над этим надо подумать. Скажем, сделать netlink интерфейс для таких запросов.

 

Вопрос больше, как доставить эти циферки в биллинг :), попробуем складировать сразу в базу.

Но если не получится, есть мысли дописать к модулю RADIUS обвязку, как в LISG :)

По идее, нет никаких kernel событий, которые надо было бы именно из модуля слать в radius.

 

Просто подсети не подойдут? (Они планируются.)

 

Подсети были бы очень кстати. Пока приходится парсить подсеть на отдельные адреса при добавлении, что не совсем удобно.

 

В остальном все просто замечательно. Огромное спасибо за идею и реализацию!

Подсети будут. Пожалуйста. Идея такой реализации полисинга - Igor Diakonov.

Share this post


Link to post
Share on other sites

Кстати, по идее вообще для l3-connected неплохая возможная замена брасу может статься )) Действительно, если бы еще обвязку сделать - клево было

Кстати, а какую минимальную скорость можно поставить?

Edited by SyJet

Share this post


Link to post
Share on other sites

Кстати, по идее вообще для l3-connected неплохая возможная замена брасу может статься )) Действительно, если бы еще обвязку сделать - клево было

 

Мы именно так и планируем.

Просто обвязка как правило у всех будет своя, и ее не обязательно делать именно в kernel space

 

Для меня самый большой вопрос, делать ли "сессии" как в LISG, или просто складывать IPDR в биллинг. А в OSS систему выводить текущие счетчики

Share this post


Link to post
Share on other sites

Удалось собрать не модулем, а монолитно.

Да, и ipt_netflow уже несколько лет монолитно трудиться.

Теперь буду ratelimit тестировать.

Спасибо!

Share this post


Link to post
Share on other sites

А такой вопрос, если у абонента было допустим

 

echo +10.10.0.1 10000000 > /proc/net/ipt_ratelimit/test_out

 

и он решил купить себе ещё 1 IP, добавить IP к тарифу можно будет только через - а потом + с 2-мя IP ?

 

echo -10.10.0.1 10000000 > /proc/net/ipt_ratelimit/test_out

echo +10.10.0.1,10.10.0.2 10000000 > /proc/net/ipt_ratelimit/test_out

 

А возможно сделать чтоб добавлять IP к уже работающему тарифу, без удаления ?

Edited by Pavel.M.A

Share this post


Link to post
Share on other sites

добавить IP к тарифу можно будет только через - а потом + с 2-мя IP ?

Добавить IP к клиенту, да.

 

А возможно сделать чтоб добавлять IP к уже работающему тарифу, без удаления ?

Зачем? Разве не просто сделать -+?

Share this post


Link to post
Share on other sites

-+ - трафик потеряется и найдутся задроты, которые будут писать "каждый вечер/час/день разрывы"

Share this post


Link to post
Share on other sites

-+ - трафик потеряется и найдутся задроты, которые будут писать "каждый вечер/час/день разрывы"

 

Не потеряется, так как, если нет правила, то нет и полисинга, а значит и пакеты не дропаются. Полисинг делается только для тех IP, которые +.

Share this post


Link to post
Share on other sites

Обнаружилась проблема: падает ядро, при запущенном perf top. Пока не выявлена причина будьте внимательны, возможно это с модулем ipt_ratelimit связано.

3.13.0-65-generic 3.10.0-229.14.1.el7.x86_64

Share this post


Link to post
Share on other sites

3.16 и 4.1 дебиановские с модулем не падали ни разу. Ни с perf top, ни с ftrace...

Share this post


Link to post
Share on other sites

ipt_ratelimit

 

Добрый час! А не могли бы поделиться составом изменений в стандартные настройки sysctl, ethtool, и если можно, iptables-save, и какая нагрузка в пакетах и трафике, и число записей conntrack, в чнн (можно в личку).

Какой процессор, и тип памяти у Вас, какая частота работы памяти.

 

Какое из указанных ядер предпочтительней с Вашей точки зрения (Загрузка процессора, perf top и управление питанием).

 

Будем искать причину, и тестить. Пока предварительно memory corruption ("непонятная фигня", краши где попало каждый раз)

Edited by sanyasi

Share this post


Link to post
Share on other sites

Будем искать причину, и тестить. Пока предварительно memory corruption ("непонятная фигня", краши где попало каждый раз)

 

Да. Не помешает протестить железо в стиле https://openvz.org/Hardware_testing

Share this post


Link to post
Share on other sites

А не могли бы поделиться составом изменений в стандартные настройки sysctl, ethtool, и если можно, iptables-save, и какая нагрузка в пакетах и трафике, и число записей conntrack, в чнн (можно в личку).

Какой процессор, и тип памяти у Вас, какая частота работы памяти.

 

Какое из указанных ядер предпочтительней с Вашей точки зрения (Загрузка процессора, perf top и управление питанием).

 

Там выше dazgluk про железо и трафик писал http://forum.nag.ru/forum/index.php?showtopic=108580&view=findpost&p=1184625. При загрузке - intel_idle.max_cstate=0 processor.max_cstate=0, частота процессора загнана в максимум через cpufreq-set.

 

ethtool -G eth0 rx 4096

ethtool -G eth0 tx 4096

ethtool -C eth0 rx-usecs 500

ethtool -A eth0 rx off tx off

ethtool -K eth0 ntuple on (сомнительно, но на данной конкретной машине отключение вызывает постоянное дерганье native_read_tsc и delay_tsc в perf top, что ведёт к росту загрузки процентов на 20)

ethtool -K eth0 gro off

ethtool -K eth0 gso off

echo 33554432 > /sys/module/nf_conntrack/parameters/hashsize

echo 4194304 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

 

Вобщем-то всё...

iptables-save | wc -l

10990

Показывать не буду - смысла нет.

Вся суть сводится к

-A FORWARD -i INTERNAL_IF -m ratelimit --ratelimit-set limit_out --ratelimit-mode src -j DROP

-A FORWARD -o INTERNAL_IF -m ratelimit --ratelimit-set limit_in --ratelimit-mode dst -j DROP

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

дальше 100500 наших фильтров и прочих настроек ната.

Share this post


Link to post
Share on other sites

Обнаружилась проблема: падает ядро, при запущенном perf top. Пока не выявлена причина будьте внимательны, возможно это с модулем ipt_ratelimit связано.

3.13.0-65-generic 3.10.0-229.14.1.el7.x86_64

3.16 и 4.1 дебиановские с модулем не падали ни разу. Ни с perf top, ни с ftrace...

 

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

 

  • https://lwn.net/Articles/600645/ "3.14 kernel was randomly crashed. The reason was kernel stack overflow"
  • https://lwn.net/Articles/600644/ "Linus has also, unsurprisingly, made it clear that he is not interested in changing the stack size in the 3.15 kernel. But the 3.16 merge window can be expected to open in the near future; at that point, we may well see this patch go in as one of the first changes."

 

Возможно, проблема была в размере стека. У sanyasi, как я понимаю, дополнительно был запущен Accel-PPP с сотнями соединений, правда, я не знаю заводит ли Accel-PPP threadы на каждое соединение или нет, если да, то это всё отъедает стек. В ipt-ratelimit так же был массив 1024 байта на стеке (это удалено в последних патчах), и в какой нибудь ситуации стек мог переполниться.

 

Если кто-то захочет продолжить тестирование, то берите последнюю версию. Как только убедимся, что она стабильна буду делать поддержку префиксов для IP адресов. Вроде бы, у sanyasi уже пара дней всё ок.

Edited by aabc

Share this post


Link to post
Share on other sites

Если кто-то захочет продолжить тестирование, то берите последнюю версию. Как только убедимся, что она стабильна буду делать поддержку префиксов для IP адресов. Вроде бы, у sanyasi уже пара дней всё ок.

 

Последняя версия, пару дней уже как, ядро 4.2.3. Записей, правда, не очень много.

Полет нормальный!

Share this post


Link to post
Share on other sites

Автору этого чудного модуля - Многая лета!

 

Выяснилась причина падения серверов, с ядрами > 3.2 и accel-ppp. Причина в accel-ppp или нелюбви новых ядер к accel-ppp.

 

uname -r

3.13.0-65-generic

up 23 days, 20:39, 1 user, load average: 0,00, 0,01, 0,05 на сервере без accel-ppp

 

11996 записей в таблице шейпа

трафик до 5G (реально работающих через сервер около 6000)

Share this post


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