Шейпить блок IP-адресов

[deaf.people]

есть сервер

CentOS 5

rp-pppoe 3.8

 

Хотелось бы шейпить ppp интерфейсы, просто тупо ограничить скорость, допустим 1мбит.

Но хотелось бы не каждый ip шейпить, а определенный диапазаон.

Каким образом это лучше сделать?

 

Спасибо.

 

[Ivan Rostovikov]

Определитесь, что именно хотите шейпить:

 

>Хотелось бы шейпить ppp интерфейсы

или

>определенный диапазаон

 

Отсюда вытикают разные методы.

[micros]

IP адреса на PPP интерфейсах? или какие именно?

а вобще заворачиваете все PPP на IFB или IMQ интерфейсы и на них tc filter для определенных IP. пожете и по src и по dst адресам шейпить, пропустив кое что без ограничений для определенных адресов локалки, или для сайтив каких нибудь.

[deaf.people]

ну так как я раздаю IP-адреса PPPoE-клиентам, IP-адреса РАЗДАЮТСЯ СОГЛАСНО ВЫБРАННОМУ ТП, потому мы знаем на какой скорости клиенту работать.

так вот, нам известны IP АДРЕСА ИСТОЧНИКА, и вот хочется заранее прописать шейпер, а не при каждом подключении PPPoE.

 

Как по Вашему, это лучший метод или ?

 

[Ivan Rostovikov]

или.

 

Клиенты начнут прыгать с тарифа на тариф - вы замучаетесь менять адреса.

[deaf.people]

или.

 

Клиенты начнут прыгать с тарифа на тариф - вы замучаетесь менять адреса.

я же сказал, ип выдается согласно тп,

тариф безлим 1 мбит = 1 блок адресов

тариф безлим 2 мбит = второй блок адресов и т д.

клиенты прыгают с тарифа на тариф раз в месяц, это не критично

[martin74]

берем в руки htb.init, и прописываем на выходной сетевухе и на ifb. На ifb загнать трафик со всех впн интерфейсов.

[Minkevich]

точного префикса Вам сказать не могу, но скорее всего где-то можно будет указать маску.

 

например: 192.168.0.0/24 (255.255.255.0)

[micros]

А зачем все таки так ТП реализованы? у вас биллинга нет?

но в любом случаем вам уже не раз предложили использовать HTB и перенаправлять трафик с PPP на IFB. а к ним фильтры U32 c ip dst или ip src ...там можно и подсеть указать и конкретный ip.

Можете задействовать iptables для маркировки трафика, и тогда в классификаторе u32 будет вместо ip src/dst распределение по маркировке.

 

а собственно что же?... почитайте сами. вам в поиск на этом форуме по постам nuclearcat (он как раз приводил кусок шейпера на PPP), поиск по IFB.

Почитайте здесь

Здесь

Здесь обязательно u32 расписан полностью (спасибо nuclearcat за ссылку на сей документ

Еще читайте LARTC. ссылки счас нет под рукой, но и самого документа и его переводов в интернете куча. Стоит пожалуй начинать даже с него.

 

[deaf.people]

м-да, спасибо micros, плохо значит искал я.

 

[ugenk]

ugenk@deb50:~$ cat /etc/ppp/ip-up.d/99shaper

#!/bin/sh

# два аттрибута - Upstream-Speed-Limit и Downstream-Speed-Limit, но в принципе соль по вкусу :)

if cat /var/run/radattr.${IFNAME} |grep Upstream-Speed-Limit

then

UP=`cat /var/run/radattr.${IFNAME} |grep Upstream-Speed-Limit |awk '{print $2}'`

DOWN=`cat /var/run/radattr.${IFNAME} |grep Downstream-Speed-Limit |awk '{print $2}'`

fi

# если параметры не пришли - можно выставить скорость по умолчанию

#[ -z $UP ] && UP=128

#[ -z $DOWN ] && DOWN=256

 

# или не шейпить вовсе

[ -z $UP ] && [ -z $DOWN ] && exit

 

/sbin/tc qdisc del dev $IFNAME root

/sbin/tc qdisc add dev $IFNAME root tbf rate ${DOWN}Kbit latency 10ms burst $[$DOWN*128]

 

/sbin/tc qdisc del dev $IFNAME handle ffff: ingress

/sbin/tc qdisc add dev $IFNAME handle ffff: ingress

/sbin/tc filter add dev $IFNAME parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate ${UP}Kbit burst $[$DOWN*128] mtu 9k drop flowid :1

 

[deaf.people]

А зачем все таки так ТП реализованы? у вас биллинга нет?

Биллинг есть, я просто хотел бы снизить нагрузку на сам роутер.

Еще раз попытаюсь описать, чего я хочу:

 

Допустим, есть база клиентов, ~1000, активных ~300

После успешной авторизации, поднимается ppp-интерфейс и тут запускается скрипт шейпинга, то есть получается каждый раз при поднятии интерфейса запускается один и тот же скрипт (на перл).

Я вот подумал, а если сделать так.

При подключении определенного клиента, ему выдается ip-адрес согласно ТП (тарифному плану), то есть получается, клиенту ТП "Безлим-64" присваивается адрес 192.168.64.x, а клиенту ТП "Безлим-128" присваивается адрес 192.168.128.x

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

 

Вопросы:

Кто-то так делает и возможно ли это реализовать в какой то дициплине (я пока туго там шарю)?

На сколько разгрузит систему такой метод шейпинга?

 

Спасибо.

[Ivan Rostovikov]

Т.е. Вы хотите одним классом задать ограничение сразу для всей подсети но для каждого адреса в отдельности. ?

Нет такого функционала в линуксе. И IMHO нигде нет.

 

[nuclearcat]

ugenk уже подсказку написал. Писать скрипт

[Nafanya]

Т.е. Вы хотите одним классом задать ограничение сразу для всей подсети но для каждого адреса в отдельности. ?

Нет такого функционала в линуксе. И IMHO нигде нет.

ну как это нет? вот например на фре

 

для входящего траффика

ipfw pipe 1 config bw 1024Kbit/s mask dst-ip 0XFFFFFFFF out
ipfw add 9 pipe 1 allow ip from any to 192.168.100.0/24

 

для исходящего

#создаем пайп с маской
ipfw pipe 2 config bw 1024Kbit/s mask src-ip 0XFFFFFFFF in
#ограничиваем скорость для каждого хоста в подсети
ipfw add 10 pipe 2 allow ip from 192.168.100.0/24 to any

 

каждому хосту из подсети скорость 1мбит

Edited April 13, 2009 by Nafanya

[Ivan Rostovikov]

Круто.

Посыпаю голову пеплом.

[deaf.people]

каждому хосту из подсети скорость 1мбит

Гм, а для Linux как будет выглядеть?

 

[micros]

Гм, а для Linux как будет выглядеть?

Примерно так

 

#!/bin/bash
#----------------------------------------------
echo "root qdisc"
tc qdisc del dev eth0 root 2> /dev/null
tc qdisc add dev eth0 root handle 1:0 htb default 20
echo "DONE" 
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 5Mbit quantum 1500 burst 600K
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1024Kbit quantum 1500 burst 128K
tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst 192.168.1.0/24 flowid 1:10

 

Это примитив шейпера на одном из интерфейсов. Если eth0 смотрит во внутреннюю сеть то он как раз ограничит трафик входящий к клиентам (для eth0 это будет исходящий трафик)

То что вы спрашивали - как раз в последней строке, можно и /16 подсеть задать.

А еще можно прочитать самое начало документа ссылку на который я давал

и поменять последнюю строку так

tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \
        classid 1:10 \
    match u32 0xc0a80100 0xffffff00 at 16

 

мог и ошибиться, пробуйте.

 

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

 

но у вас же не один интерфейс eth0, а много ppp, чтобы не писать для каждого фильтр - придумали ifb и imq (ну imq еще не только для этого придумали)

 

редирект всех ppp - на ifb, где уже классы и фильтры.

При добавлении ppp вам в шейпер нужно будет вносить изменения. Рас уж у вас тарифы от ip зависят, то етсь смысл прописать все фильтры заранее и их не менять, а в шейпер только добавлять редиректы... мне так кажется.

 

в общем пища для размышлений у вас есть. читайте , читайте.

[deaf.people]

Спасибо, буду пробывать все варианты.

[Cramac]

Подниму старую тему, интересует вариант шейпить определенные адреса в сети что ломятся в интернет...

 

Сейчас шепит ППП интерфейсы, хотим уйти от них...

[NiTr0]

Хеш-таблицы, как-то так. Либо близкий проект - sc, обсуждаемый в этом разделе.

[Cramac]

хм, как же люди на кто использует ipoe шейпят?

 

и по ссылке и с sc все основаны на tc. Хочется узнать мнение кто уже работает, чтоб не сильно спотыкаться :)

[NiTr0]

все основаны на tc

Более того: tc - единственная штатная утиль для контроля шейпера :) Не считая ессно прямого обращения к API ядра из ПО.

Не, можно прикрутить порт ipfw, только на кой он нужен - не знаю.

[Cramac]

значит осталось только с правилами разобраться...