ipfw2 динамическое ограничение кол-ва сессий для ip

Если ограничение пропускной способности для каждого конкретного
пользователя - не самоцель, а только средство "справедливо" разделить между
ними имеющийся канал, то более корректной будет работа с одним каналом и
несколькими очередями (возможно, с различным проиритетом), например:

/sbin/ipfw pipe 1 config bw 1000Kbit/s
/sbin/ipfw queue 1 config pipe 1 weight 50 mask dst-ip 0x00000000
/sbin/ipfw add queue 1 ip from any to 192.168.0.1/24

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

/sbin/ipfw pipe 1 config bw 1000Kbit/s
/sbin/ipfw queue 1 config pipe 1 weight 50 mask dst-ip 0x00000000
/sbin/ipfw queue 2 config pipe 1 weight 75 mask dst-ip 0x00000000
/sbin/ipfw add queue 1 ip from any to 192.168.0.1/25
/sbin/ipfw add queue 2 ip from any to 192.168.0.128/25

даст некоторый проиоритет в использовании канала пользователям с адресами,
большими 192.168.0.128. Это неплохой инструмент для VIP-обслуживания
некоторых абонентов сети без "глобального" ущемления прав рядовых
пользователей: если никому из VIP-группы в данный момент канал не нужен, то
обычные пользователи делят между собой пропускную способность поровну, но
если VIP-абоненту понадобились услуги - простые пользователи автоматически
подвигаются

--- cut

Я бы ещё добавил в конце правил очереди via int in/out...

Тебе ещё, возможно, пригодится это

http://www.opennet.ru/base/net/ipfw_one_pass.txt.html.



From: Alexander Sheiko <adsh@i.com.ua>

 AV>>> Как нарезку траффика сделать очень плавной и четкой?


Общие сведения:
http://www.opennet.ru/base/net/red_qos.txt.html

Подробный "разбор полётов":
http://www.icir.org/floyd/papers/red/red.html (скачай PDF оттуда)
http://www.icir.org/floyd/REDparameters.txt
http://ee.tamu.edu/~zzlarry/vprm_red.html
http://www.opennet.ru/base/net/linux_traffic_qos.txt.html

Hедавно я сам с этим всем разбирался. Переход от tail drop к gred выглядит
разительно. В первом случае - скорость прокачки постоянно скачет, в
статистике куча дропов. Во втором - наблюдается плавное регулирование
скорости, без скачков, и - очень малое количество дропов. Экспериментально у
меня очень хорошо заработала такая настройка gred 0.002/10/30/0.1 для
конфигурирования очередей (я загонял очереди с масками в пайпы) . Число
слотов в очередях поставил в сотню. При увеличении очереди от 10 до 30
слотов - процент дропаемых пакетов плавно растёт от нуля до 10. При
дальнейшем увеличении очереди (2 х 30 = 60 слотов) - процент дропаемых
пакетов плавно растёт от 10 до 100. В случае простого red - после достижения
очереди в 30 слотов дропаются все пакеты. Gred тут действует заметно мягче.
Смысл тут в том, что, при передаче данных, исходя из процента дропнутых
пакетов (и не только), автоматически устанавливатся оптимальная скорость
передачи.

Если что написал не совсем точно - пусть меня коллеги поправят.