iptables limit некорректно ограничивает (пропускает намного меньше, чем заявлено)

[gr3m1in]

по непонятной причине величина лимита, переданная iptables, не соблюдается.
интерфейс в компе один, посему не указываем его явно.
этот интерфейс смотрит в локалку 100Мбит.
для эксперимента тянем с соседнего компа пять файлов размером по паре гигов, они занимают весь канал и заливаются на скорости 15-20 МБ/сек.
при установке лимита в iptables с ограничением в 10000 пакетов в секунду, фактически проходят 150-200 пакетов, остальные уходят в дроп, и скорость получается 30-40кБ/сек.

вот экспериментальный скриптик

ipt='iptables'

# создаем цепочки
$ipt -N junk_chain_in
$ipt -N drop_chain_in

# задаем в них правила
$ipt -A drop_chain_in -j DROP
$ipt -A junk_chain_in -m limit --limit 10000/second -j RETURN
$ipt -A junk_chain_in -j drop_chain_in

# перекладываем туда пришедший трафик
$ipt -A INPUT -j junk_chain_in

при этом, если заменить $ipt -A junk_chain_in -m limit --limit 10000/second -j RETURN на $ipt -A junk_chain_in -j RETURN, т.е. просто убрать лимит - колво пакетов становится порядка 25000/сек.
если вернуть лимит обратно - кол-во пропущеных пакетов НЕ ДОСТИГАЕТ УСТАНОВЛЕННОГО ЗНАЧЕНИЯ, каким бы мы его не выставили.
кол-во прошедших и сброшенных пакетов легко считать по созданным цепочкам.

ВОПРОС: в чем проблема? это проблема iptables, модуля limit или еще чего-то? и главное - КАК ЭТО ЛЕЧИТЬ???

заранее всем благодарен!

[Rootlexx]

gr3m1in
Почитайте это.

[gr3m1in]

gr3m1in
Почитайте это.

Rootlexx, огромное спасибо!
Нашел нужное. Вилы оказались в значении --limit-burst.

Но, как обычно, ответ породил вопрос.
Опытным путем выяснено, что задать значение --limit или --limit-burst болще 10000 нельзя, ругается.
А по локалке может кататься гораздо большее количество пакетов в секунду.
От чего зависит это ограничение - врядли оно прибито гвоздями в коде, это бессмысленно
И как можно обойти, чтобы оперировать объемом пакетов порядка 20-25 тыс.?

[Ariasp]

Опытным путем выяснено, что задать значение --limit или --limit-burst болще 10000 нельзя, ругается.
А по локалке может кататься гораздо большее количество пакетов в секунду.
От чего зависит это ограничение - врядли оно прибито гвоздями в коде, это бессмысленно
И как можно обойти, чтобы оперировать объемом пакетов порядка 20-25 тыс.?

А для чего собственно всё это затевается? Если для ограничения/резервирования ширины полосы пропускания, то это мягко говоря неверный путь. Ибо использование limit предполагает, что в интервале, пока limit-burst не уменьшится хотя бы на 1, пакеты будут дропаться. Т.е. для передачи данных это неприемлемо. Потому бессмысленно как раз использование limit с заоблачными значениями.

[gr3m1in]

А для чего собственно всё это затевается? Если для ограничения/резервирования ширины полосы пропускания, то это мягко говоря неверный путь. Ибо использование limit предполагает, что в интервале, пока limit-burst не уменьшится хотя бы на 1, пакеты будут дропаться. Т.е. для передачи данных это неприемлемо. Потому бессмысленно как раз использование limit с заоблачными значениями.

В целом, не могу не согласиться.
К этому привело техзадание начальника, а описывать всё техзадание целиком будет офтопом на два экрана, да и лень.
Вкратце, значения limit и limit-burst в хвостовых цепочках передергиваются с шагом во времени, напр. раз в неск. секунд.
Исходя из измерений прошедшего трафика расчитываются и выставляются новые значения на следующий промежуток времени.
Для наглядности, это можно назвать грубым шейпером. Просьба ухохатываться негромко.
Вопросы "зачем так брутально" и "почему не юзаем tc" не задавайте.

Обратно к предмету.
От чего зависят потолковые значения и как обойти потолок?
А также осталась не вполне ясным взаимосвязь limit и limit-burst между собой.
Мануалы покурил обильно, но понимание сакрального смысла так и не наступило. Примеры с водоемами и трубами как-то не складываются в целую картину.
Вынужден подбирать значения и коэффициенты эмпирически.
Если кто проникся сутью - объясните, плиз, на пальцах, может остальные глупые вопросы сами отпадут.
Буду крайне признателен!

[AlexUg]

Если кто проникся сутью - объясните, плиз, на пальцах, может остальные глупые вопросы сами отпадут.
Буду крайне признателен!

Попытаюсь это сделать: смотрим сюда (выдержка из статьи)
1.Расширение -m limit подразумевает наличие ключей --limit и --limit-burst. Если вы не указываете эти ключи, то они принимают значение по-умолчанию.
2.Ключ --limit-burst - это максимальное значение счетчика пакетов, при котором срабатывает ограничение.
3.Ключ --limit - это скорость, с которой счетчик burst limit "откручивается назад".
При пападании пакета в данное правило увеличивается "внутренний счетчик" и он будет увеличиваться пока не достигнет limit-burst, все последующие пакеты будут поподать под действие этого правила (если установили -j DROP, то пакеты будут отбрасываться).
Теперь посмотрим на limit -- он определяет с какой скоростью уменьшать "внутренний счетчик", т.е. до достижения предела limit-burst пакеты могут передаваться с максимально возможной скоростью, после достижения передла -- со скоростью уменьшения "внутреннего счетчика".

Вух, вроде так.

[gr3m1in]

При пападании пакета в данное правило увеличивается "внутренний счетчик" и он будет увеличиваться пока не достигнет limit-burst, все последующие пакеты будут поподать под действие этого правила (если установили -j DROP, то пакеты будут отбрасываться).
Теперь посмотрим на limit -- он определяет с какой скоростью уменьшать "внутренний счетчик", т.е. до достижения предела limit-burst пакеты могут передаваться с максимально возможной скоростью, после достижения передла -- со скоростью уменьшения "внутреннего счетчика".

Вух, вроде так.

т.е. за один промежуток времени кол-во пакетов не может превышать limit-burst? но ведь отношение количества пакетов ко времени, судя по синтаксису, задается в limit...
и если limit - это скорость уменьшения счетчика, то за какое время счетчик будет уменьшен на величину limit, если указанное в limit значение - не кол-во пропускаемых пакетов?
экспериментально проверил - итоговое кол-во принятых (ACCEPT) пакетов примерно равно сумме limit и limit-burst... собственно, почему?
вобщем, нехватает ясности в порядке их взаимодействия
попробуем на примерах:

1:
-m limit --limit 1000/second --limit-burst 50 -j ACCEPT
-j DROP

2:
-m limit --limit 50/second --limit-burst 1000 -j ACCEPT
-j DROP

3:
-m limit --limit 1000/second --limit-burst 1000 -j ACCEPT
-j DROP

в чем будет разница и почему?
какое кол-во пакетов будет принято (ACCEPT) за каждую секунду в каждом случае?

[AlexUg]

и если limit - это скорость уменьшения счетчика, то за какое время счетчик будет уменьшен на величину limit, если указанное в limit значение - не кол-во пропускаемых пакетов?

Счетчик уменьшается на 1 со скоростью, которую определяет limit, т.е. --limit 1000/second - говорит о том, что каждую 1/1000 секунды счетчик будет уманьшен на 1.

Извини ввел тебя в заблуждение: пакеты будут попадать под действие правила до достижения ограничений, а не после (как писал в прошдом посте).

Приведу свой пример:
настроил логирование входящих пакетов --limit 3/min --limit-burst 5 -j LOG
результат:
в лог файле 8 пакетов за первую минуту, это говорит о том, что пока не достиг предел limit-burst=5 пакеты попдали под действие LOG (5 пакетов), затем каждые 20 секунд (1/3 мин) счетчик уменьшался и соответственно пакет попадал в лог (еще 3 пакета, полагаю возразишь, что последний пакет должен быть в 00 сек следующей минуты, но в логе именно 8 записей).
в последующие минуты в логе по 3 записи в минуту.

Да и поповоду "интерфейса смотрящего в локалку", если хочешь добится чистоты эксперимента, то в этой самой локалке не должно быть более двух компов. Дело в том, что, говоря простым языком не вдаваясь в подробности, пакеты будут передаваться только при "свободной линии". Это значит если в локалке 3 компа и 3й комп, не задействованный в опытах, начнет, что-то передавать, первые два будут молчать ждать пока 3й не закончит передачу и не освободит линию, такова спецификация ethernet. Соответственно скорость падает и уменьшается кол-во пакетов.
Да поправят меня специалисты.

[gr3m1in]

Счетчик уменьшается на 1 со скоростью, которую определяет limit, т.е. --limit 1000/second - говорит о том, что каждую 1/1000 секунды счетчик будет уманьшен на 1.
настроил логирование входящих пакетов --limit 3/min --limit-burst 5 -j LOG
в лог файле 8 пакетов за первую минуту, это говорит о том, что пока не достиг предел limit-burst=5 пакеты попдали под действие LOG (5 пакетов), затем каждые 20 секунд (1/3 мин) счетчик уменьшался и соответственно пакет попадал в лог (еще 3 пакета, полагаю возразишь, что последний пакет должен быть в 00 сек следующей минуты, но в логе именно 8 записей).
в последующие минуты в логе по 3 записи в минуту.

если limit<limit-burst и [кол-во ожидаемых пакетов]>[limit], то счетчик в любой следующий интеравл будет меньше или равен limit-burst и кол-во совпадений правила за интервал не превысит limit,
и в последующие минуты состояние [кол-во совпавших пакетов]>[limit] больше никогда не достигается? это явление возможно только в перый интервал времени?

[AlexUg]

если limit<limit-burst и [кол-во ожидаемых пакетов]>[limit]

Говоря простым языком -- сровниваешь скорость с расстоянием, что больше 20 км/ч или 500 м?

[gr3m1in]

если limit<limit-burst и [кол-во ожидаемых пакетов]>[limit]

Говоря простым языком -- сровниваешь скорость с расстоянием, что больше 20 км/ч или 500 м?

жаль, что в случае с iptables затруднительно говорить о размерностях измеряемых величин.
всего лишь пытаюсь осмыслить то, что наизмерял...
если сделать --limit 10000/second и --limit-burst 10000, то получаем 20000 +/- 1500 прошедших пакетво за КАЖДУЮ секунду.
провел несколько таких тестов, получил такую зависимость для прошедших пакетов = [limit] + [burst] +/-[random], где random - просто наблюдаемый разброс.
собственно, почему именно так?

[gr3m1in]

всё, осилил.
огромное спасибо всем за ответы!