Приветствую всех!
Стоит следующая задача: есть несколько Linux-машин, которые используются для подключения клиентов по VPN, единовременно подключены до 300-350 человек, три четверти из которых - пользователи безлимитных тарифов с ограниченной скоростью. Нужно выбрать шейпер для Linux, который сможет адекватно обрабатывать такую систему. На данный момент используется shaperd, но, к сожалению при таком трафике (15-20 Мбит/с на каждой машине) и кол-ве подключений он начинает сильно перегружать машину, а у пользователей начинаются проблемы, связаные с увеличением времени отклика до удаленных узлов и потери пакетов до них.
Кто что сможет предложить?
Спасибо!
если скоростя ~10 Мбит то тогда tc c дисциплиной red
>если скоростя ~10 Мбит то тогда tc c дисциплиной red
А примеры реализации есть? Вопрос: как будут уживаться на одном маршрутизаторе клиенты не лимитированные и резаные с помощью tc?
Как насчет CBQ? Что если трафик больше?
>>если скоростя ~10 Мбит то тогда tc c дисциплиной red
>А примеры реализации есть? Вопрос: как будут уживаться на одном маршрутизаторе клиенты
>не лимитированные и резаные с помощью tc?
>Как насчет CBQ? Что если трафик больше?вместо cbq лучше применять htb у него проблнм с таймингом меньше
>>>если скоростя ~10 Мбит то тогда tc c дисциплиной red
>>А примеры реализации есть? Вопрос: как будут уживаться на одном маршрутизаторе клиенты
>>не лимитированные и резаные с помощью tc?
>>Как насчет CBQ? Что если трафик больше?
>
>вместо cbq лучше применять htb у него проблнм с таймингом меньше
Подниму еще раз эту тему. Насколько я понимаю, дисциплина red является бесклассовой и немного не подходит на по критериям. Наиболее правильным выбором, если меня никто не опровергнет, мне кажется посоветованный Den'ом htb. Если ли у кого-нибудь практика внедрения такого шейпинга при кол-ве пользователей, которых нужно единовременно шейпить близко к 400, а траффик от них чуть больше 10-12 Мбит/с?
Какие методы используются для такого рода шейпинга интернет-провайдерами еще (как программные, так и аппаратные)?
Спасибо за овтеты!
Наиболее правильным выбором, если
>меня никто не опровергнет, мне кажется посоветованный Den'ом htb. Если ли
>у кого-нибудь практика внедрения такого шейпинга при кол-ве пользователей, которых нужно
>единовременно шейпить близко к 400, а траффик от них чуть больше
>10-12 Мбит/с?
>Какие методы используются для такого рода шейпинга интернет-провайдерами еще (как программные, так
>и аппаратные)?В случае HTB есть свои проблемы.
Я так понимаю, что 400 абсолютно разных клиентов сос своими правилами?Нормально сделал такое только под FreeBSD. Использовал pipe в ipfw и
приоритеты на очереди. Также можно использовать table в ipfw для обжимания траффика по направлениям.С линухом пробовал СBQ, HTB. Есть для меня пока серьезное препятствие - грамотно обжать в линуксах гораздо сложнее, чем во фре.
Дело в том, что vpn интерфейсы динамические, и вставить правило HTB на несуществующий интерфейс невозможно. Т.е. надо добавлять правило при подъеме интерфейса. При этом сложно планировать иерархию... В принципе это решается хранением HTB конфига в базе данных вместе с инфой для авторизации. Надо не забывать, что CBQ и HTB умеет работать только с исходящим трафиком, поэтому вход от пользователя жмется через Жо.у !!!
Возникают также проблемы с NAT. Вот если жать на исходящем интерфейсе, как узнать от кого оно идет, если через NAT уже прошло? Есть модуль conntrack в iptables. С ним легче, но как мы с iptables в tc передадим правила обжима? - УРА. Есть маркировка в iptables, которую понимает tc.Вроде всё решили, но подведя итог - в голову лезут одни маты.
P.S. Наблюдалось в ядре 2.4.20 c gr-security патчем раз в 1-2 мясяца затыкание траффика полностью HTB'ой. Приходилось перегружать правила HTB.
Они были сделаны с помощью описательной утилиты XML-htb. Не помню точно, как пишется. Конфиг был в XML и транслировался в скрипт с tc.
В принципе 400 клиентов одновременно, но все они работают скажем по 4-5 тарифам, то есть пять правил.
Почему проблемы с обжатием входящего от клиента? Один исходящий жмем на pppNN, исходящие в сторону пользователя жмем на WAN-интерфейсе.
Есть еще вариант - вразрез между pptpd серверами и граничным маршрутизатором поставить машину под управлением FreeBSD (NAT тогда организовать на пограничном маршрутизаторе, что снимет хотя бы одну проблему), тогда возникает следующий вопрос: какие характеристики может удовлетворить одна мощная машина под FreeBSD (трафик + одновременно зажимаемые пользователи)?
А в повседневной жизни провайдеры не самого большого уровня как справляются с зажимом по анлимным тарифом? каким софтом и железками, кто-нибудь из-за руля такой компании может сказать?
>В принципе 400 клиентов одновременно, но все они работают скажем по 4-5
>тарифам, то есть пять правил.
Да, но нужно прописывать каждому индивидуально, даже одинаковые.
>Почему проблемы с обжатием входящего от клиента? Один исходящий жмем на pppNN,
>исходящие в сторону пользователя жмем на WAN-интерфейсе.
помоему, наоборот - исходящий от пользователя
>Есть еще вариант - вразрез между pptpd серверами и граничным маршрутизатором поставить
>машину под управлением FreeBSD (NAT тогда организовать на пограничном маршрутизаторе, что
>снимет хотя бы одну проблему), тогда возникает следующий вопрос: какие характеристики
>может удовлетворить одна мощная машина под FreeBSD (трафик + одновременно зажимаемые
>пользователи)?
>А в повседневной жизни провайдеры не самого большого уровня как справляются с
>зажимом по анлимным тарифом? каким софтом и железками, кто-нибудь из-за руля
>такой компании может сказать?
Пень3 500 уже много лет держит почтовик, ospf, bgp с одного прова и графики. Анлим клиенты до 256к каждый - штук 30. Плюс к этому около 1мбит/сек транзита. Сетевухи всякие - реалтек, винбонд - короче Г редкое.
Вот аптайм его: 0,24 0,44 0,54.
Но там сейчас exim стоит и 6.0 freebsd. exim с внешним mysql сервером.
Дохера берет проца система сбора трафика nacctd.Вообще нужно ставить нормальные сетевухи с аппаратным чексумом пакетов - intel pro100 либо лучше, 3com 905b либо лучше, есть ряд SMC с боьшими микрухами (Etherpower 2 зовутся). Они ОЧЕНЬ помогают прохождению трафика и разгрузки сервака. Кстати, polling режим тоже дает прирост. К примеру на 4.7 freebsd замена 3-х realtek сетевух на intel дала 30%-е снижение загрузки на p3 700.
Промежуток - это лишняя часть, головная боль, если где-то допустить ошибку. Я видел провов с таким решением. У них есть отдельно шейпер, он-же локальный роутер и счетчик траффа (именно съем данных, а не учет - этим занимается вычислительный кластер из 3-х серваков под linux с Oracle на борту), а после него NAT машина. Количество обжимаемого трафика - до нескольких сотен мегабит на один тазик. Сеть имеет много ветвей. Что не на цисках - то обычно забекаплено с помощью vrrp.
Непонятки, ведь классов по сути придется создать не так много, а вот классификаторами (фильтрами) по IP, например, направлять такой-то адрес в такой-то класс?>Пень3 500 уже много лет держит почтовик, ospf, bgp с одного прова
>и графики. Анлим клиенты до 256к каждый - штук 30. Плюс
>к этому около 1мбит/сек транзита. Сетевухи всякие - реалтек, винбонд -
>короче Г редкое.Не, тут условия другие. 200-250 анлимщиков единовременно + около 10-12 Мбит/с трафика.
>Промежуток - это лишняя часть, головная боль, если где-то допустить ошибку. Я
>видел провов с таким решением. У них есть отдельно шейпер, он-же
>локальный роутер и счетчик траффа (именно съем данных, а не учет
>- этим занимается вычислительный кластер из 3-х серваков под linux с
>Oracle на борту), а после него NAT машина. Количество обжимаемого трафика
>- до нескольких сотен мегабит на один тазик. Сеть имеет много
>ветвей. Что не на цисках - то обычно забекаплено с помощью
>vrrp.В принципе условия близки - шейпер стоит как раз на локальном роутере (за ним - граничный маршрутизатор), съем трафика в частности идет с них, обработка уже в другом месте.
>Непонятки, ведь классов по сути придется создать не так много, а вот
>классификаторами (фильтрами) по IP, например, направлять такой-то адрес в такой-то класс?
Тогда все, кто попадет в класс будут делить полосу между собой.
Для анлима с жесткой скоростью: сколько активных клиентов - столько и классов
>>Непонятки, ведь классов по сути придется создать не так много, а вот
>>классификаторами (фильтрами) по IP, например, направлять такой-то адрес в такой-то класс?
>Тогда все, кто попадет в класс будут делить полосу между собой.
>Для анлима с жесткой скоростью: сколько активных клиентов - столько и классов
>Опять не до конца понял. Смари (пример с www.linuximq.net),
- /sbin/tc class add dev imq1 parent 2: classid 2:1 htb rate 80000Kbit
- /sbin/tc class add dev imq1 parent 2: classid 2:2 htb rate 80000Kbit
- /sbin/tc class add dev imq1 parent 2:1 classid 2:10 htb rate 256kbit ceil 384kbit
- /sbin/tc class add dev imq1 parent 2:1 classid 2:20 htb rate 512kbit ceil 648kbit
- /sbin/tc filter add dev imq1 parent 2: protocol ip prio 1 u32 match ip dst ccc.ccc.ccc.ccc/dd match ip src aaa.aaa.aaa.aaa/bb flowid 2:10Тут фильтром некто добавляется в потом 2:10, получается, что у этого некто скорость будет огнраничиваться 256 Кбит (в каком-то направлении, регулиуемом ус-вом), если фильтром добавить второго "некто" в это же flowid 2:10, то они поделят 256 пополам, да?
если да, то получается, что с подключением кадого пользователя мы должны создавать новую очередь (класс) с дисциплиной htb и неповторяющимся classid (2:nn в этом примере) + для нового подключения создаем фильтр. Так? пардон за кучу вопросов - новая для меня тема.
>С линухом пробовал СBQ, HTB. Есть для меня пока серьезное препятствие -
>грамотно обжать в линуксах гораздо сложнее, чем во фре.
>Дело в том, что vpn интерфейсы динамические, и вставить правило HTB на
>несуществующий интерфейс невозможно. Т.е. надо добавлять правило при подъеме интерфейса. При
>этом сложно планировать иерархию... В принципе это решается хранением HTB конфига
>в базе данных вместе с инфой для авторизации.http://www.linuximq.net/
iptables -t mangle -A POSTROUTING -o ppp+ -j IMQ --todev 1
и shaper на интерфейс imq1>Надо не забывать,
>что CBQ и HTB умеет работать только с исходящим трафиком, поэтому
>вход от пользователя жмется через Жо.у !!!iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
>Возникают также проблемы с NAT. Вот если жать на исходящем интерфейсе, как
>узнать от кого оно идет, если через NAT уже прошло? Есть
>модуль conntrack в iptables. С ним легче, но как мы с
>iptables в tc передадим правила обжима? - УРА. Есть маркировка в
>iptables, которую понимает tc.http://www.linuximq.net/patchs/imq-nat.diff
и не надо маркировки
>http://www.linuximq.net/
>iptables -t mangle -A POSTROUTING -o ppp+ -j IMQ --todev 1
>и shaper на интерфейс imq1При каких условиях опробован этот подход?
хммм... А вот это интересно.
Нужно будет попробовать.
спсб.
>http://www.linuximq.net/patchs/imq-nat.diff
>и не надо маркировкиУважаемый nrvalex, помучаю еще чуть-чуть :).
Выходит, что при наличии, предположим, четырых правил по ограничению мы создаем (четыре тарифа с разной скоростью, например) мы создаем четыре класса с дисциплиной HTB, а затем производит с помощью фильтра-классификатора u32 направление пользователя в зависимости от его данных по тарифу в определенный класс. Завешиваем при поднятии PPP-интерфейса динамически правила на вновь сформированные интерфейсы IMQ1/0 для кромсания обоих сторон потока трафика?