Re: [Sysadmins] Нужен стабильный шейпер/QoS

[Mike Almateia <mike.almateia@gmail.com>]

On Monday 20 October 2008 18:55:45 lad wrote:
> Mike Almateia пишет:
> > On Saturday 18 October 2008 21:31:00 ladimir@pisem.net wrote:
> >> У кого-нибудь стоит маршрутизатор на ALT с более менее сложными
> >> правилами?
> >>
> >> Самое главное - интересует именно стабильность. при нескольких
> >> десятков правил.  Т.е. аптайм при редких изменения правил.
> >> Также интересно:
> >> Прикрутить netflow.
> >> Возможность организовать HA-кластер.
> >> Возможность подключить мостом (ну как etables). Что бы не
> >> перенастраивать шлюз по умолчанию в случае если нужно убрать железку
> >> из сети. (Ничего про это не нашёл - для QoS)
> >>
> >> т.е. у кого-нибудь работает подобное?
> >
> > Могу сказать только про QoS и шейпинг.
> > Имел дело с настройкой шейпинга для pptp сервера.
> > Всё настраивалось через CBQ, на сервере было до 500 интерфейсов ppp, на
> > каждом по несколько правил CBQ.
> > Всё работало стабильно и без проблем, трафик резался точно без скачков.
> > Единственнй минус у CBQ - не простая настройка.
>
> Можно
> uname -a
> uptime  ...ну в среднем
> и задача собственно cbq. что им добивались (я так понимаю это одна из
> наиболее навороченных дисциплин, зачем)?
uname сейчас не скажу, так как доступа на сервера больше не имёю.
Это был ALT Master 2.4 с ядром 2.6.18 из сизифа (ядро обновлялось по причине 
поддержки новым ядром сетевой карточки, обновление не связно с qos никак)

Задача: при подключении пользователя выставить шейпинг средствами CBQ и 
приоритет трафика.
Все данные для правил (скорость, приоритет) передавались по RADIUS в pppd, 
который запускал бинарник выставляющий правила на интерфейс.
Ядро автоматически убивает правила, при опускании интерфейса.
Дисциплин много, почему использовался CBQ - наиболее проверенный механизм.
Можно использовать HTB - он проще в использовании.

Доков на русском по QoS, команде - tc можно найти множество хотя бы на 
opennet.ru, поискав по ключевым словам - QoS, tc, CBQ.