Перейти до

вымучил наконец лимиты скорости


Рекомендованные сообщения

и так обещал поделится , делюсь лимиты во все стороны (правда еще не доделал скипт выборки скорости, но на форуме полно примеров.)

и так цель в не зависимости от варианта подключения (pptp, pppoe, lan, vlan) делаем нарезку скорости клиенту по IP .

Целью было несколько принципиальных "НО" на которые я немог не обратить внимания

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

2) клиент сам выбирает вариант подключения (все варианты доступны pptp, pppoe, lan) но его лимиты должны всегда быть в действии.

3) многие считают что нет смысла резать исходящий канал "НО" его надо резать а то зафлудят вирусами.

 

Итак после длительного гулянья по интернету (как то не хотелось читать хендбук про tc) пришел к выводу что избавится о всех этих "НО" в линуксе возможно или метками , или завернув все в один интерфейс , ближе к телу для меня интерфейс и я сплясал отсюда

 

и так при старте системы делаем

modprobe ifb
ip  link set ifb0 up (созадл мой общий интерфейс)
tc qdisc add dev ifb0 root handle 1: htb default 1
tc class  add dev ifb0 parent 1: classid 1:1 htb rate 37mbit burst 15k (задал максимальную скорость корорая имеется)
tc qdisc add dev eth0 ingress handle ffff:
tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 (слил вес трафик от провайдера на этот интерфейс)
tc qdisc add dev vlan100 ingress handle ffff:
tc filter add dev vlan100 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 (слил вес трафик  с локального эзернет  на этот интерфейс)

 

далее при в OnConnect

 

tc class add dev ifb0 parent 1:1 classid 1:1$ID htb rate минимальная_гарантированная_скоростьkbit ceil Максимальная_скорость_для_тарифаmbit burst 15k (Создал подкласс для этого клиента )
tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip src $IP flowid 1:1$ID (зафильтровал весь исходящий трафик по IP клиента)
tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip dst $IP flowid 1:1$ID(зафильтровал весь Входящий трафик по IP клиента)

 

ну и соответственно стер все в скрипте onDisconnect

И так с эзернетом разобрались

а как же в ppp ?

все просто

в /etc/ppp/ip-up.d/ заделал скриптик который клеит весь трафик с интерфейса на ifb0

#!/bin/sh
tc qdisc add dev $PPP_IFACE ingress handle ffff:
tc filter add dev $PPP_IFACE parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

 

Заранее оговорюсь , это мой первый опыт работы с TC так что сильно не пинать , лимиты работают , друг другу не мешают.

знаюших TC просба если что не так подправить и выложить

 

 

П.С с натом на одной машине не тестировал

П.П.С не знаю с какой нагрузкой все это будет работать

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 51
  • Створено
  • Остання відповідь

Top Posters In This Topic

Заранее оговорюсь , это мой первый опыт работы с TC так что сильно не пинать , лимиты работают , друг другу не мешают.

знаюших TC просба если что не так подправить и выложить

 

 

П.С с натом на одной машине не тестировал

П.П.С не знаю с какой нагрузкой все это будет работать

 

Ну, почему же все даже относительно хорошо вышло.

Для мелких провайдеров уже есть пример, как втулить на один сервер несколько видов подключения.

Крупняки же этим заниматься не будут - логичнее и правильнее разносить разный вид подключений по разным НАСам.

По поводу НАТа - нафик его делать на ifb, делаеть его более правильно на исходящем интерфейсе.

 

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

Ссылка на сообщение
Поделиться на других сайтах

это вы так тошнотворно dummynet эмулируете? :D

 

Так точно сэр ! :D)) dummynet самое хорошее что изобретено в *никсе .. жаль в линуксе его нет. Вот бы хардовую поддержку линукса в BSD .. тогда бы гемора такого не было :)

Ссылка на сообщение
Поделиться на других сайтах

Так точно сэр ! :D)) dummynet самое хорошее что изобретено в *никсе .. жаль в линуксе его нет. Вот бы хардовую поддержку линукса в BSD .. тогда бы гемора такого не было :)

 

Напишем? :D

Ссылка на сообщение
Поделиться на других сайтах

Так точно сэр ! :))) dummynet самое хорошее что изобретено в *никсе .. жаль в линуксе его нет. Вот бы хардовую поддержку линукса в BSD .. тогда бы гемора такого не было :)

 

Напишем? ;)

увы и ах :)

Ссылка на сообщение
Поделиться на других сайтах
увы и ах

ыгы и ох http://lists.freebsd...une/003916.html

 

Но работает оно как и все в этих ваших линуксах :)

 

 

heretic.jpg

ЗЫ либо еще страшнее и святотатнее: http://habrahabr.ru/blogs/testing/127639/

Ссылка на сообщение
Поделиться на других сайтах

долго и упорно чесал голову по поводу того как же прилепить сюда нат... а потом решение пришло само собой.

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

в OnConnect

 

tc class add dev ifb0 parent 1:1 classid 1:1$ID htb rate минимальная_гарантированная_скоростьkbit ceil Максимальная_скорость_для_тарифаmbit burst 15k (Создал подкласс для этого клиента )tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip src 0.0.0.0/0 flowid 1:1$ID (зафильтровал весь исходящий трафик по IP клиента)[/conde]

и все .. лимиты стоят даже при нат :)

Ссылка на сообщение
Поделиться на других сайтах

Боюсь, что при нагрузке рухнет все по ЦПУ. (((

Как там сейчас при всех абонентах загрузка? Если память не изменяет, вроде 1600 абонентов.

Ссылка на сообщение
Поделиться на других сайтах

облом по китайски :lol:) из за опухания мозга от тц черт попутал

tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip src 0.0.0.0/0 flowid 1:1$ID (зафильтровал весь исходящий трафик по IP клиента) тупо сливает в последнюю трубу всех клиентов

Ссылка на сообщение
Поделиться на других сайтах

читал читал про линукс шейпер .. и убедился чтто никак не обьединить лимиты и нат в один тазик :lol:) как не крути до бсд линуксу рости и рости ...

Ссылка на сообщение
Поделиться на других сайтах

Покаялся таки :lol:

 

Проще и дубовее dummynet найти ничего не возможно. Все хорошо и отлично пока речь не заходит о нормальном полисинге.

 

heretics.jpg

Ссылка на сообщение
Поделиться на других сайтах

облом по китайски :)) из за опухания мозга от тц черт попутал

tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip src 0.0.0.0/0 flowid 1:1$ID (зафильтровал весь исходящий трафик по IP клиента) тупо сливает в последнюю трубу всех клиентов

В PREROUTING перед NAT-ом ставьте метки, их потом класифицируйте в tc.

Кроме того, в tc для большого количества клиентов полезно использовать дерево хешей (тогда match-иться будет не по очереди в таблице, а деревом).

Ссылка на сообщение
Поделиться на других сайтах

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

Чего это - никак?

Если ingress с пользовательского туннеля/локального интерфейса заворачивается на IFB - траффик в IFB попадает до того, как пройдет по iptables. Т.е. - до ната и т.п.

И еще замечание - для классов эдак с более чем сотней правил уже нужно делать хеш-таблицу. Пример инициализации шейпера есть и на наге, а я делал для себя свой. Работает прекрасно, сейчас на брасах на 3 интерфейсах (собссно ifb для тех, у кого не предусмотрено разграничение мир/Украина, + на исходящем на мир и на исходящем на Украину) по 9000 классов (по 12 таблиц подсетей /24, на каждый ип - 3 класса: корневой и 2 подкласса: общий траф и высокоприоритетный траффик), среднее кол-во правил, которое проходит каждый пакет - порядка 10. Собссно вот скрипт, вот его конфиг.

 

P.S. Я так и не понял - накой вы заворачивали траффик в ifb с обеих интерфейсов, и уже на нем шейпили? С тем же успехом могли бы и собссно egress qdisc повешать на интерфейсы. IFB нужен только для того, чтобы шейпить поступающий на ифейс траффик, исходящий с роутера прекрасно шейпится на интерфейсе.

Ссылка на сообщение
Поделиться на других сайтах

P.S. Я так и не понял - накой вы заворачивали траффик в ifb с обеих интерфейсов, и уже на нем шейпили? С тем же успехом могли бы и собссно egress qdisc повешать на интерфейсы. IFB нужен только для того, чтобы шейпить поступающий на ифейс траффик, исходящий с роутера прекрасно шейпится на интерфейсе.

Ситуация у человека такова, что на одном тазике 3 вида подключений и не так просто в скрипте OnConnect не просто узнать с какого вида подключается клиент.

Ссылка на сообщение
Поделиться на других сайтах

попробывал модуль линукса dummynet .. долго ломал голову над pipe, так как после создания пайпа трафик начинал рубится ("нет это не рио-де-жанейро"(ц)Остап) но потом дошло что надо указывать направления (благо хоть бе з интерфейсов) шрйпит нормально .. кстате есть возможность делать к примеру такое "ipfw pipe 4 config bw 1Mbit/s mask src-ip 0x00000ff" и это радует ... сейчас скрещу с Snat поглядим справится ли зверушка

 

П.С. (одни костыли ... куда нас это доведет)

 

 

 

Запустил нат .. пока полет нормальный

Ссылка на сообщение
Поделиться на других сайтах

Ситуация у человека такова, что на одном тазике 3 вида подключений и не так просто в скрипте OnConnect не просто узнать с какого вида подключается клиент.

Непросто? Неужели?

ip a|grep " $ip/32" - если результат пустой, значит по эзернету, не пустой - туннель. Шейпить соотвтственно.

Ссылка на сообщение
Поделиться на других сайтах

прикинул текст OnConnect

 

ipfw table (id-tarif) add $IP

iptables -t nat -A POSTROUTING -s $IP -o eth0 -j SNAT --to $snat_ip

 

смотрю и ужасаюсь :)

 

Ситуация у человека такова, что на одном тазике 3 вида подключений и не так просто в скрипте OnConnect не просто узнать с какого вида подключается клиент.

Непросто? Неужели?

ip a|grep " $ip/32" - если результат пустой, значит по эзернету, не пустой - туннель. Шейпить соотвтственно.

а если этот эзернет на 5 вланах ?

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

ага ... бегать по всем конфигом и смотреть случайно там клинет или нет ... не вариант (ipfw) спасло линукс :) собирался сносить уже ..

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...