Re: [Comm] Advanced Routing & QoS

[Andy Gorev <gorev@mailru.com>]

Andrey Orlov wrote:

> On 2002 December 02 Monday 20:08, you wrote:
>
> >Для начала, извините за крос-постинг. Я предполагаю, данная тема
> >интересует многих.
>
> Довольно-таки. Что касается статьи то у меня особых замечаний нет, 
> хотя я бы
> расширил пункты 7,8 (оформив их как некий cookbook, хорошим (но 
> недостаточным) приближением может быть Advanced Router HOWTO)

Дело в том, Андрей, что статья изначально задумывалась как обзор 
возможностей, с дальнейшей ссылкой на ресурсы с примерами по реализации, 
а не инструмент для быстрой настройки. Другими словами, это не HOWTO. 
Если расширять раздел 7, то там надо рассматривать редко-используемые 
классификаторы, про описание которых даже в отмеченном HOWTO прямо так и 
сказано, что: "For more filtering commands, see the Advanced Filters 
chapter".

По поводу п.8 (т.е. реализации), я так понимаю, вы предлагаете сделать 
обмен работающими конфигурациями? Для этого надо писать отдельный 
материал. Или вы имели в виду уточнение использования cbq.init? Так я-же 
подчеркнул, что сей скрипт - наполовину комментарий с инструкцией по его 
использованию. В нем даже примеры есть. Для взаимопомощи существуют 
списки рассылок. Конечно, если общественность будет настаивать, обзор 
можно будет наполнить конкретными конфигами. Только есть ли в этом 
смысл? Для неподготовленного статья и так трудно читается, а для 
остальных указаны ссылки, по которым искать дополнительную информацию, 
конфиги, примеры, и прочее.

В любом случае, спасибо за ваше предложение, возможно в печатной 
документации соответствующие пункты будут расширены.

> кроме того должен заметить - ссылка в п.8 на man 8 tc
> немножко лукавая : man 8 tc во всех пунтктах посвященный фильтрам, 
> ссылается на
> man 8 tc-filters, который похоже еще не написали : во всяком случае в 
> дистрибутиве
> его не имеет места (сейчас тяжело посмотреть, но кажется в sysiphus 
> тоже). Да и остальная
> часть man tc,  больше похожа на сумму из tc <....> help. 
> Использоваение же самого man 8 tc для
> понимания работы упомянутых u32 & fw - невозможно  (в версии из ALM2.0 
> man tc|grep -iE "u32|fw" - пусто). 

Похоже у вас старая версия iproute2. Текущий билд из Сизифа включает в себя:
ip.8.bz2
tc-cbq.8.bz2
tc-htb.8.gz
tc-pbfifo.8.gz
tc-pfifo_fast.8.gz
tc-prio.8.gz
tc-red.8.gz
tc-sfq.8.gz
tc-tbf.8.gz
tc.8.gz
Обновитесь, или, если нет такой возможности, маны доступны на LARTC 
http://lartc.org/manpages/

> Тем не менее, статья особых нареканий не вызывает, а вот вопрос по 
> поводу ip/tc у
> меня есть : последние две недели я вожусь с настройками посредством tc 
> и у меня
> возникает странное ощущение того, что этот код крайне плохо отлажен 
> (или крайне
> плохо собран в нашем случае, я использую ALM2.0 со всеми апдейтами). Я 
> не настолько
> хорошо в этом разбираюсь, что бы сразу начинать  тыкать пальцем в 
> ошибки в коде - я
> собственно tc раньше и не трогал, но мне хотелось бы понять текущий 
> статус этого кода:
> нечто отлаженное,  часто используемое и надежно работающие
> или некий код, 80% декларированного функционала  которого никто 
> никогда не использовал.
> По ощущениям (еще раз - это именно ощущения, на полуинтуитивном 
> уровне) я склоняюсь ко
> второму варианту, так как те особенности работы, которые я наблюдаю 
> могут быть результатом:
>
> 1. Использования неинициализированой памяти (в модулях ядра, похоже);
>
> 2. Неосвобождения памяти (опять же в модулях ядра);
>
> 3. Отсутствия проверок граничных условий;
>
> 4. Отсутствия проверок допустимости параметров;
>
> 5. Отсутствия проверок переполнения и т.п.


Я не могу опровергнуть, или подтвердить ваши предположения, так как не 
являюсь программистом, тем более на ядерном уровне. Однако у меня тоже 
есть собственные наблюдения. Я работаю в одном из крупнейших Белорусских 
ISP. И провайдим мы как ни странно на Alt :-). Уже около двух лет на 
нескольких серверах работает связка из CBQ+u32+TBF общим числом около 
500 классов. Серверы, на которых крутится все это хозяйство далеко не 
мощные, особенно по нынешним временам. Тем не менее особых проблем 
замечено не было. На ядрах 2.2 _иногда_ были странные "отъезжания 
крыши", если говорить несколько раз за сутки "service cbq restart". 
Однако uptime у этих серверов был все-равно более месяца. Примерная 
конфигурация тогда - 128RAM-P2-400. На ядрах 2.4 и более мощных 
конфигурациях проблем с QoS вообще нет.

По поводу статуса кода я могу сказать вот что.  Вообще говоря это вопрос 
к мантайнеру пакета iproute2, и по счастливому совпадению мантайнера-же 
ядра - Константину. В ядре все эти фильтры и классификаторы - есть 
типичные модули, никоим образом не добавляемые каким-либо Patch-O-Matik, 
т.е. идут в составе классического ядра от Linus. Таким образом, можно 
законно предположить, что AltLinux как разработчики, и Константин в 
частности, имеют к этому коду самое общее отношение, как  например и мы 
с вами. Они его просто поддерживают, но вряд-ли особенно вдумчиво 
тестируют. Хотя возможно я и ошибаюсь. Следовательно, это вопрос 
напрямую к Кузнецову. Попробуйте, может быть он вам и ответит ;-)

Статус кода iproute2 достаточно легко понять, если сходить на 
официальный склад сборок ftp://ftp.inr.ac.ru/ip-routing/. Какая сборка в 
дистрибутивах Алт, и почему - вопрос опять-же к мантайнеру.

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


Если Вам удастся вытащить какую-либо информацию из Кузнецова, я думаю 
она будет многим здесь интересна и полезна.

> Эти пять пунктов я заметил при использовании tbf, prio, u32  в меньшей 
> степени - cbq
> (kernel24-up-2.4.18-alt6master, AFAIR).
> Подробнее я рассказывать не буду - так как в данный момент интересует 
> не помощь в
> решении конкретных проблем, а понимание текущего статуса этого кода, 
> особенно статус
> этого кода в рамках AltLinux (так как менять дистрибутив в обозримом 
> будущем я не намерен),
> чбы решить для себя что делать дальше:
>
> 1. Поискать другое решение (в случае если этот код вообще никто не 
> поддерживает и это лишь
> забавный реликт, оставшийся от ядер 2.2.*);

Ни в коем случае не реликт! Чтобы отказаться от этого "реликта", вам 
придется отказаться не только от Альта, но и от Линукса вообще. Код 
находится в состоянии постоянного развития. Неужели ничего не говорит 
хотя-бы факт появления HTB в последних ядрах? Для интереса, можете взять 
ядро 2.5 и посмотреть-рассказать как с этим там.

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

Это да, никогда не завредит. Особенно исходники. Код отлаженный, 
проверенный, многими используется! Про апдейты - один из самых 
популярных сейчас патчей - IMQ. Я на него ссылался в обзоре.

> 3. В том или ином виде присоеденится к его поддержке (вряд ли как 
> писатель кода - но по крайней
> мере отследить баги и написать баг-репорты  с точным описанием глюков 
> - если код перспективный
> но у команды разработчиков не хватает рук, времени, тестовой базы и 
> т.п.);

Не знаю, как насчет баг-репортов, но специалисты по этим делам тусуются 
в своем комьюнити. Подпишитесь, очень полезно почитать о том, как люди 
решают свои проблемы с помощью iproute2. 
http://www.lartc.org/#mailinglist Средний трафик там 20-30 писем в сутки.

> Буду благодарен если ктонть мне это прояснит.

Надеюсь помог =)

-- 
С Уважением,
Андрей Горев