Страница 1 из 1
Про шейпер подскажите
Добавлено: Пт мар 28, 2008 12:37 pm
andy
Чего-то мне не очень понятно на каком интерфейсе режется по скорости исходящий трафик.
Допустим eth0 - uplink. eth1-локалка. ppp2 - клиент
С входящем там все просто ppp2 и даже фильтры не нужны. А вот с исходящем не понимаю. Там же перед eth0 стоит NAT и IP клиентов уже не видно. В свое время для обхода этой проблемы использовал IMQ.
Если можно то разрисуйте ктонибудь дерево шейпера.
Добавлено: Пт мар 28, 2008 2:04 pm
ran
Ну если не хочешь лезть в дебри и исходящий можно на ппп резать - где-то так:
Код: Выделить всё
##### speed client->server
if [ "$DOWNSPEED" != "0" ] ;
then
$TC qdisc add dev $IFACE handle ffff: ingress
$TC filter add dev $IFACE parent ffff: protocol ip \
prio 50 u32 match ip src 0.0.0.0/0 police rate ${DOWNSPEED}kibit \
burst 12k drop flowid :1
fi
Не очень красиво с дропом, но работает... А если хочешь (в смысле в дебри

) - тада действительно - кури IMQ... Кстати IFB ещё есь... И оно наверно получше будет ибо в стандартный кернел включён. А можешь и на внешнем изернете... иптейблом меть чё те нада и по метке фильтрами заворачивай в нужную дисциплину. И не нужны тебе клиентские адреса...
Добавлено: Пт мар 28, 2008 4:53 pm
andy
Это ты входящий для пользователя описал. Где собственно все понятно. Я о другом. В примерах есть скрипт для резанья скорости не доконца догоняю как он работает.
Схема же примерно такая.
<---Входящ----ppp2--- (FORWARD)---NAT---eth0---Исход--->
tc умеет резать только исходящий трафик с интерфейса.
Для Входящего трафика клиента это будет (Исходящий с ppp2) и тут все понятно.
Если нету NAT то Исходящй трафик клиента будет (Исходящий с eth0)
А если NAT есть то фильтры уже применять не получится поскольку после NAT IP адресов клиентов уже нет.
Раньше обходился с помощью IMQ где схема такая
<---Входящ----ppp2--- (FORWARD)---IMQ---Исход---> NAT---eth0
А тут я просто не понимаю как пожно обойтись без дополнительного девайса. Логика не понятна.
Добавлено: Пт мар 28, 2008 5:21 pm
ran
Это ты входящий для пользователя описал
Нет! Исходящий от пользователя! Дисциплина ingress тебе ни о чём не говорит? Я привёл фрагмент моего бывшего рабочего скрипта.
tc умеет резать только исходящий трафик с интерфейса.
Неужели?
http://megalib.com/books/1346/lartc.html А тут я просто не понимаю как пожно обойтись без дополнительного девайса.
Я ж писал выше - можно на внешнем изернете резать. Метить иптейблом, в том месте, где срц ип или входящий ифейс ещё известен и фильтровать по
метке, а не по адресу.
Добавлено: Пт мар 28, 2008 5:54 pm
andy
Чего-то видимо пропустил.
Тоесть получается что и входящий и исходящий режутся на ppp2.
А давно ingress появился в ip route появился?
Добавлено: Пт мар 28, 2008 8:05 pm
ran
andy писал(а):А давно ingress появился в ip route появился?
с рождения

Но учти, что ингресс будет просто грубо и цинично
дропать лишний трафик... Вот ингресс в сочетании с IFB (Intermedia Function Block) - эт другое дело... Но... про дебри я уже писАл

Сам смотри... А для исходящего трафа не так уж и критично... А если клиента не устраивает - пусь сам у себя шейпит, чтоб всю полосу не занимать

Добавлено: Сб мар 29, 2008 10:53 am
andy
Спасибо. Буду разбираться дальше.
пусь сам у себя шейпит
Это было бы здорово! И еще осла сам бы себе резал

Добавлено: Вс мар 30, 2008 9:48 am
ran
И еще осла сам бы себе резал
тем более.. лазит в пиринг - пусть сам заботится о полосе своего исходящего канала. Твоё дело - ограничить согласно тарифного плана

меж прочим при тестах на том фрагменте скрипта, что я приводил, на нормальных тсп сессиях исходящая скорость уменьшается реально на 5 - 7% без потери линка... ну а то, что у него при этом аки не успевают проскаки вать и соответственно входящий канал рубится - его проблемы... я ж грю - если такой хитрож... мудрый - сам пусь шейпит