форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[ Отслеживать ]

"Выбор шейпера для шлюза"

Сообщение от Ziminson (ok) on 10-Дек-08, 11:13

Здравствуйте, подскажите пожалуйста куда копать при решении такой проблемы - есть шлюз с 4 интерфейсами - один смотрит в инет, остальные - локальные подсети. 2 из них под натом ходят в инет, третья - сервера для локального пользования. Требуется ограничить скорость скачки/закачки для каждого пользователя, причем с возможностью гибко менять скорость, но в локальной сети резать ее не надо. Я пробовал решать эту проблему с помощью htb, однако он поднимается на каждом интерфейсе и соответственно режет вообще весь трафик, даже в локалке. Может ли сквид разруливать это?

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выбор шейпера для шлюза"

Сообщение от Oleg_Rus (ok) on 11-Дек-08, 09:39

>[оверквотинг удален] >локальные подсети. 2 из них под натом ходят в инет, третья >- сервера для локального пользования. >Требуется ограничить скорость скачки/закачки для каждого пользователя, причем с возможностью гибко менять >скорость, но в локальной сети резать ее не надо. > >Я пробовал решать эту проблему с помощью htb, однако он поднимается на >каждом интерфейсе и соответственно режет вообще весь трафик, даже в локалке. > > >Может ли сквид разруливать это? Единственно верным решением данной задачи будет установка дополнительного роутера point-to-point на твой инерфейс, глядящий во внешний мир. Рассказать ему, что у тебя в сети есть те, кому надо резать скорость и исхощящий с этого роутера (соответственно, входящий в твою сеть) будешь рулить так, как тебе надо. Рассказать роутеру о том, что у тебя есть адреса, которым надо резать скорость можно так: поднять nfs-сервер на твоем роутере (можно в другом месте), собрать в один файл адреса:скорости и положить в директорию для nfs'a и уже на новом роутере забирать эти данные, чтобы "править миром" )))

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Выбор шейпера для шлюза"
	Сообщение от Pahanivo (ok) on 11-Дек-08, 11:02
	>[оверквотинг удален] >Единственно верным решением данной задачи будет установка дополнительного роутера point-to-point на твой >инерфейс, глядящий во внешний мир. Рассказать ему, что у тебя в >сети есть те, кому надо резать скорость и исхощящий с этого >роутера (соответственно, входящий в твою сеть) будешь рулить так, как тебе >надо. >Рассказать роутеру о том, что у тебя есть адреса, которым надо резать >скорость можно так: >поднять nfs-сервер на твоем роутере (можно в другом месте), собрать в один >файл адреса:скорости и положить в директорию для nfs'a и уже на >новом роутере забирать эти данные, чтобы "править миром" ))) бред
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Выбор шейпера для шлюза"

Сообщение от masters (ok) on 11-Дек-08, 09:59

>Может ли сквид разруливать это? ipfw в Фре с этим прекрасно справляется, HTB кстати тоже не плохо. Для того, чтобы в локалке не резал - просто выставляешь юзерам скорость для локалки 100Мбит/с. А чтобы не на всех интерфейсах поднимался - есть параметр DEV. tc class add dev $DEV parent 1: classid 1:100 htb rate 100mbit prio 1 tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip src $LANMASK flowid 1:100

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Выбор шейпера для шлюза"
	Сообщение от Pahanivo (ok) on 11-Дек-08, 11:02
	>[оверквотинг удален] >ipfw в Фре с этим прекрасно справляется, HTB кстати тоже не плохо. > >Для того, чтобы в локалке не резал - просто выставляешь юзерам скорость >для локалки 100Мбит/с. А чтобы не на всех интерфейсах поднимался - >есть параметр DEV. > >tc class add dev $DEV parent 1: classid 1:100 htb rate 100mbit >prio 1 >tc filter add dev $DEV parent 1: protocol ip prio 1 u32 >match ip src $LANMASK flowid 1:100 токмна не ipfw, а ipfw + dummynet
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Выбор шейпера для шлюза"
	Сообщение от dimanoname on 11-Дек-08, 19:06
	К вышесказанному могу добавить, что можно еще включить использование ifb для шейпинга на входящем интерфейсе Погуглите насчет ifb(скажу лишь что хорошее начало всего вопроса маршрутизации - LARTC http://www.opennet.dev/docs/RUS/LARTC/), в сети очень много про это написано. приведу в пример свой может и не очень удачный конфиг #!/bin/bash DEV="ppp0" modprobe ifb ip link set dev ifb0 up # Перенаправляем трафик с интерфейса, который смотрит в инет на ifb0 tc qdisc del dev $DEV handle ffff: ingress tc qdisc add dev $DEV handle ffff: ingress tc filter add dev $DEV parent ffff: protocol ip u32 match u32 0 0 action mirredegress redirect dev ifb0 # А дальше уже как хотим можем резать _входящий_ трафик. tc qdisc del dev ifb0 root handle 1: tc qdisc add dev ifb0 root handle 1: htb default 2 r2q 1 # Main class tc class add dev ifb0 parent 1: classid 1:1 htb rate 100mbit quantum 6000 # For local traff, ssh etc tc class add dev ifb0 parent 1:1 classid 1:2 htb rate 100mbit quantum 6000 burst 5k cburst 5k # For ppp0 tc class add dev ifb0 parent 1:1 classid 1:3 htb rate 1024kbit ceil 1024kbit quantum 1600 burst 1k # For 14k users tc class add dev ifb0 parent 1:3 classid 1:31 htb rate 14kbps ceil 28kbps quantum 1600 burst 1k # User=NoName, режем входящий и исходящий трафик пользователям tc filter add dev ifb0 protocol ip parent 1:0 prio 0 u32 match ip dst 10.х.х.х/32 flowid 1:31 tc filter add dev ifb0 protocol ip parent 1:0 prio 0 u32 match ip src 10.х.х.х/32 flowid 1:31 tc filter add dev ifb0 protocol ip parent 1:0 prio 0 u32 match ip dst 192.168.у.у/32 flowid 1:31 tc filter add dev ifb0 protocol ip parent 1:0 prio 0 u32 match ip src 192.168.у.у/32 flowid 1:31 У меня сделан шейпер всего лишь на 2 компьютера по 14кбит каждому с возможностью "займа" до 28. Соотвественно он "подхватывает" только пакеты идущие через ppp0 интерфейс(у меня VPN), а интерфейсы eth0 eth1 итд не трогает, таким образом локальный трафик бежит свободно. Аналогом ifb является imq, но в пределах маленькой сети разницы я не вижу, но ядро для поддержки ifb пересобирать не требуется, достаточно лишь modprobe ifb
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Выбор шейпера для шлюза"
	Сообщение от sonkilla (ok) on 11-Дек-08, 21:52
	А что если просто разрулить через CBQ init? Единственным его недастатком было то что нельзя резать исходяший трафик от пользователя(а может и можно но в документации я ничего ненашол)полазив по форумам и докам по htb я решил ету проблему маркировкой пакетов.Приведу пример создаем скрипт rc.mark пишем в него например для 5той подсети всей правило по маркированию(для едениченых клиентов айпи лучше писать без маски во всяком случае с маской у меня несработало) iptables -t mangle -A FORWARD -s 192.168.5.0/24 -j MARK --set-mark 5001 iptables -t mangle -A FORWARD -d 192.168.5.0/24 -j MARK --set-mark 6002 и так далее всех клиентов Теперь в /etc/sysconfig/cbq/ создаем конфиги для каждого правила в нашем случаее cbq-1001.net5UP (режем исходящий) следующего содержания DEVICE=eth0,10Mbit,1Mbit (имя интерфейса смотряшего в инет остальное есть в доках по cbq) RATE=64Kbit WEIGHT=8Kbit PEAK=64Kbit BOUNDED=yes PRIO=5 MARK=5001 в данном примере ограничиваем на 64кб/сек Следующий конфиг для тойже 5той подсети только ограничение уже на скачку cbq-1001.net5DOWN DEVICE=eth0,10Mbit,1Mbit (имя интерфейса смотряшего в инет остальное есть в доках по cbq) RATE=64Kbit WEIGHT=8Kbit PEAK=64Kbit BOUNDED=yes PRIO=5 MARK=6001 В итоге зажимаем 5тую подсеть на выходе в инет на выходном интерфейсе.У меня так работает надеюсь и вам пригодиться все вышеописанное.Главное один раз сесть и разгребсти всех клиентов и создать конфиги а дальше менять скорости можно будет находу через кансоль либо создать пхп или перл скрипты.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]