Ограничение входящего трафика.

IMQ? http://www.linuximq.net/

Попробую конечно, просто от imq остались неприятные воспоминания: когда три года назад сетапил nntp, то для эксперимента воспользовался imq. Результат: кернел паник из-за этого модуля раз в сутки в стабильно. Плюнул, зашейперил на роутере его трафик: аптайм 850 дней на текущий момент.

Использую htb+sfq. Как раз по меткам. В вашем случае не подойдет?

> Результат: кернел паник из-за этого модуля раз в сутки в стабильно
Да, когда-то давно модуль imq имел таки приколы (наблюдал kernel panic при rmmod imq с присутствием правил iptables ... -j IMQ), потом вроде это пофиксили, по крайней мере, работая с ним, kernel panic-ов больше не видел

>Использую htb+sfq. Как раз по меткам. В вашем случае не подойдет? Это может использоваться только для исходящего трафика. Мне очень хочется не выходить за пределы ppp, и резать в обе стороны именно в нем. То есть хочется все-таки ingress, точнее его новый полисер победить.

В догонку: http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg17653.html

"Thats actually a completely different problem. Unlike with imq, packets are delivered to ifb *before* they pass through iptables. So at that time they're not marked. I don't see a good solution for this that allows to keep the iptables rules, I'd suggest to switch to ematches."

В общем буду копать в сторону этих ematches (я так понял это em_meta). У кого-то есть пример использования? :-)

> Есть задача такого рода: Итак, линукс. Есть много (до 2000) ppp интерфейсов. Надо резать скорость каждому интерфейсу. Но резать не одним скопом, а каждому свою персонально выставлять, да еще разделять на два-три класса (интернет, внутренние ресурсы, городские ресурсы).

Я так понял - Интернет, внутренние и городские ресурсы находятся за eth0? При этом существует туева хуча ppp*-соединений (через тот же eth) ?

Slavaz, понял правильно.

дай более-менее реальный пример.
Например, что нужно от конкретно одного ppp-соединения:
- ограничить скорость (ХХХмбит/с) на внутренние ресурсы сети (пусть будет 192.168.0.0/24)
- ограничить скорость (XXXмбит/с) на городскую сеть (10.0.0.0/8)
- ограничить скорость (XXXкбит/с) в Интернет

Ещё что? Не исключено. что можно решить шейпингом исходящего канала (на eth0).
Да, и какая должна быть минимально гарантированная скорость для ppp-соединения?

Ок, вот какая картина. Сервер. eth0 смотрит во внутрь, на нем навешаны вланы на которых запущены pppoe сервера. Юзера получают реальные ip адреса. Серых нет. Наружу смотрит eth1. Шейпера приходят с радиуса и стартуют из ip-up при старте ppp соелинения. Есть список городских ресурсов, есть список локальных ресурсов и есть городские паритеты (примерно 30-40 сетей с разными масками). Проблемы с приемом для юзера нет (прием для юзера у нас это egress на ppp, тут все просто). Для работы egress я классифицирую сразу iptables (-j CLASSIFY) и отправляю в дисциплину. Конфиг tc реально занимает 5-7 строк. А вот что в новых ядрах делать с ingress (у юзера это передача) - я еще не знаю. В старом полисире (NET_CLS_POLICE) я маркировал с помощью iptables пакеты и в фильтре дропал по достижению нужного rate. Но его больше нет:
http://www.mail-archive.com/netdev@vger.kernel.org/msg59513.html
Вот и ищу альтернативные варианты.
PS. Адреса динамические, то есть привязаны по портам ppp.
PS1. Скорости от 256 Кбит до 10 Мбит.