Jump to content
Калькуляторы

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

есть сервер

CentOS 5

rp-pppoe 3.8

 

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

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

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

 

Спасибо.

 

Share this post


Link to post
Share on other sites

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

 

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

или

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

Share this post


Link to post
Share on other sites
или.

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

Здесь

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

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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
А зачем все таки так ТП реализованы? у вас биллинга нет?
Биллинг есть, я просто хотел бы снизить нагрузку на сам роутер.

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

 

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

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

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

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

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

 

Вопросы:

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

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

 

Спасибо.

Share this post


Link to post
Share on other sites

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

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

 

Share this post


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

Нет такого функционала в линуксе. И 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 by Nafanya

Share this post


Link to post
Share on other sites
каждому хосту из подсети скорость 1мбит
Гм, а для Linux как будет выглядеть?

 

Share this post


Link to post
Share on other sites
Гм, а для 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 зависят, то етсь смысл прописать все фильтры заранее и их не менять, а в шейпер только добавлять редиректы... мне так кажется.

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this