Перейти к содержимому
Калькуляторы

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)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отпишитесь о результатах :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Машинка 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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 :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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 как-то уже начал кодить, но потом понял, что это лишнее усложнение. На практике, всегда можно делать -... +... Спасибо за тестирование!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

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

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем SyJet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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 к уже работающему тарифу, без удаления ?

Изменено пользователем Pavel.M.A

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обнаружилась проблема: падает ядро, при запущенном 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...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ipt_ratelimit

 

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

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

 

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

 

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

Изменено пользователем sanyasi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не могли бы поделиться составом изменений в стандартные настройки 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 наших фильтров и прочих настроек ната.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обнаружилась проблема: падает ядро, при запущенном 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 уже пара дней всё ок.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Выяснилась причина падения серверов, с ядрами > 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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.