[Comm] Advanced Routing & QoS

[Andrey Orlov]

On 2002 December 02 Monday 20:08, you wrote:
> Для начала, извините за крос-постинг. Я предполагаю, данная тема
> интересует многих.

Довольно-таки. Что касается статьи то у меня особых замечаний нет, хотя я бы
расширил пункты 7,8 (оформив их как некий cookbook, хорошим (но недостаточным) приближением 
может быть Advanced Router HOWTO), кроме того должен заметить - ссылка в п.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" - пусто). 

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

1. Использования неинициализированой памяти (в модулях ядра, похоже);

2. Неосвобождения памяти (опять же в модулях ядра);

3. Отсутствия проверок граничных условий;

4. Отсутствия проверок допустимости параметров;

5. Отсутствия проверок переполнения и т.п.

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

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

1. Поискать другое решение (в случае если этот код вообще никто не поддерживает и это лишь
забавный реликт, оставшийся от ядер 2.2.*);

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

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

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

-- 
WthBstRgrds -- Андрей Орлов --  
 --- www.neural.ru, cray на neural.ru ---
----------------------------------------