The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"QOS:AddPac+Cisco через 384К-канал"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение [Проследить за развитием треда]

"QOS:AddPac+Cisco через 384К-канал"  
Сообщение от bda email(??) on 11-Фев-07, 22:41 
Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом AP-300B и маршрутизатором Cisco 1751.

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


Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно эти команды делают -никому не известно.

Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже сталкивался.

PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях. Влияние конвертеров - исключено, т.к. условия лабораторные.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от Lacunacoil email(ok) on 12-Фев-07, 16:47 
>Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом
>AP-300B и маршрутизатором Cisco 1751.
>
>Никак не пойму, каким образом формировать очереди на аддпаке, так что-бы голосовые
>пакеты уходили в первую очередь и не давились прочим трафиком. Причем
>на циске в сторону аддпака - все нормально: пакеты красятся и
>ставятся в очередь так что качество разговора в сторону аддпака -
>отличное, но от аддпака в сторону циски - страдает от других
>потоков трафика.
>
>
>Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные
>формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно
>эти команды делают -никому не известно.
>
>Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже
>сталкивался.
>
>PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно
>осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный
>на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях.
>Влияние конвертеров - исключено, т.к. условия лабораторные.


http://ap200.nm.ru/  тут посмотри

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от bda email(ok) on 12-Фев-07, 19:10 
>>Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом
>>AP-300B и маршрутизатором Cisco 1751.
>>
>>Никак не пойму, каким образом формировать очереди на аддпаке, так что-бы голосовые
>>пакеты уходили в первую очередь и не давились прочим трафиком. Причем
>>на циске в сторону аддпака - все нормально: пакеты красятся и
>>ставятся в очередь так что качество разговора в сторону аддпака -
>>отличное, но от аддпака в сторону циски - страдает от других
>>потоков трафика.
>>
>>
>>Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные
>>формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно
>>эти команды делают -никому не известно.
>>
>>Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже
>>сталкивался.
>>
>>PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно
>>осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный
>>на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях.
>>Влияние конвертеров - исключено, т.к. условия лабораторные.
>
>
>http://ap200.nm.ru/  тут посмотри

Толкового по QOS и очередям на этом сайте нет. Пока я вообще не могу понять, зачем нужны эти команды, которые как-бы должны управлять QOS`ом...


Люди, реально необходима помощь, т.к. я жестко повязан бюджетом и уже заложил эти шлюзы... ХЕЛП!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от bda email(??) on 25-Фев-07, 18:09 
>>>Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом
>>>AP-300B и маршрутизатором Cisco 1751.
>>>
>>>Никак не пойму, каким образом формировать очереди на аддпаке, так что-бы голосовые
>>>пакеты уходили в первую очередь и не давились прочим трафиком. Причем
>>>на циске в сторону аддпака - все нормально: пакеты красятся и
>>>ставятся в очередь так что качество разговора в сторону аддпака -
>>>отличное, но от аддпака в сторону циски - страдает от других
>>>потоков трафика.
>>>
>>>
>>>Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные
>>>формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно
>>>эти команды делают -никому не известно.
>>>
>>>Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже
>>>сталкивался.
>>>
>>>PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно
>>>осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный
>>>на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях.
>>>Влияние конвертеров - исключено, т.к. условия лабораторные.
>>
>>
>>http://ap200.nm.ru/  тут посмотри
>
>Толкового по QOS и очередям на этом сайте нет. Пока я вообще
>не могу понять, зачем нужны эти команды, которые как-бы должны управлять
>QOS`ом...
>
>
>Люди, реально необходима помощь, т.к. я жестко повязан бюджетом и уже заложил
>эти шлюзы... ХЕЛП!

Коллеги! Помогите! Может все-таки кто-то на эту тему что-то копал уже. Как все-таки работает маханизм создания очередей у аддпаке?

Кстати, ставил такой опыт: два аддпака через тонкий канал, ПК, которые установлены за аддпаками нагрузили линию с помощью iperf`a, и НИКАКИЕ настройки на аддпаках не дали приоритета или что-то подобного LLQ для голосового тафика....

ХЕЛП!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от Lacunacoil email(ok) on 25-Фев-07, 18:28 
>>>>Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом
>>>>AP-300B и маршрутизатором Cisco 1751.
>>>>
>>>>Никак не пойму, каким образом формировать очереди на аддпаке, так что-бы голосовые
>>>>пакеты уходили в первую очередь и не давились прочим трафиком. Причем
>>>>на циске в сторону аддпака - все нормально: пакеты красятся и
>>>>ставятся в очередь так что качество разговора в сторону аддпака -
>>>>отличное, но от аддпака в сторону циски - страдает от других
>>>>потоков трафика.
>>>>
>>>>
>>>>Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные
>>>>формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно
>>>>эти команды делают -никому не известно.
>>>>
>>>>Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже
>>>>сталкивался.
>>>>
>>>>PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно
>>>>осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный
>>>>на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях.
>>>>Влияние конвертеров - исключено, т.к. условия лабораторные.
>>>
>>>
>>>http://ap200.nm.ru/  тут посмотри
>>
>>Толкового по QOS и очередям на этом сайте нет. Пока я вообще
>>не могу понять, зачем нужны эти команды, которые как-бы должны управлять
>>QOS`ом...
>>
>>
>>Люди, реально необходима помощь, т.к. я жестко повязан бюджетом и уже заложил
>>эти шлюзы... ХЕЛП!
>
>Коллеги! Помогите! Может все-таки кто-то на эту тему что-то копал уже. Как
>все-таки работает маханизм создания очередей у аддпаке?
>
>Кстати, ставил такой опыт: два аддпака через тонкий канал, ПК, которые установлены
>за аддпаками нагрузили линию с помощью iperf`a, и НИКАКИЕ настройки на
>аддпаках не дали приоритета или что-то подобного LLQ для голосового тафика....
>
>
>ХЕЛП!

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от bda email(??) on 25-Фев-07, 21:02 
>>>>>Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом
>>>>>AP-300B и маршрутизатором Cisco 1751.
>>>>>
>>>>>Никак не пойму, каким образом формировать очереди на аддпаке, так что-бы голосовые
>>>>>пакеты уходили в первую очередь и не давились прочим трафиком. Причем
>>>>>на циске в сторону аддпака - все нормально: пакеты красятся и
>>>>>ставятся в очередь так что качество разговора в сторону аддпака -
>>>>>отличное, но от аддпака в сторону циски - страдает от других
>>>>>потоков трафика.
>>>>>
>>>>>
>>>>>Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные
>>>>>формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно
>>>>>эти команды делают -никому не известно.
>>>>>
>>>>>Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже
>>>>>сталкивался.
>>>>>
>>>>>PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно
>>>>>осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный
>>>>>на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях.
>>>>>Влияние конвертеров - исключено, т.к. условия лабораторные.
>>>>
>>>>
>>>>http://ap200.nm.ru/  тут посмотри
>>>
>>>Толкового по QOS и очередям на этом сайте нет. Пока я вообще
>>>не могу понять, зачем нужны эти команды, которые как-бы должны управлять
>>>QOS`ом...
>>>
>>>
>>>Люди, реально необходима помощь, т.к. я жестко повязан бюджетом и уже заложил
>>>эти шлюзы... ХЕЛП!
>>
>>Коллеги! Помогите! Может все-таки кто-то на эту тему что-то копал уже. Как
>>все-таки работает маханизм создания очередей у аддпаке?
>>
>>Кстати, ставил такой опыт: два аддпака через тонкий канал, ПК, которые установлены
>>за аддпаками нагрузили линию с помощью iperf`a, и НИКАКИЕ настройки на
>>аддпаках не дали приоритета или что-то подобного LLQ для голосового тафика....
>>
>>
>>ХЕЛП!
>
>addpac :)
>давай попробуем разобраться вместе, покажи что уже пробывал и какой был результат.
>
>Будем предлогать варианты.


Для начала, была собрана следующая схема:
http://bda.cttc-ryazan.ru/VoIP-LAB.jpg

В схеме - два ПК, на которых отработывал iperf - сначала с TCP, затем с UDP-нагрузкой.

В результате, если с TCP-нагрузкой addpac боролся как-то сам, причем никаких команд вида qos-control - не вводилось.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от Lacunacoil email(ok) on 25-Фев-07, 22:16 
>>>>>>Уважаемые коллеги! Помогите со следующей проблемой: qos на тонком 384К-линке между шлюзом
>>>>>>AP-300B и маршрутизатором Cisco 1751.
>>>>>>
>>>>>>Никак не пойму, каким образом формировать очереди на аддпаке, так что-бы голосовые
>>>>>>пакеты уходили в первую очередь и не давились прочим трафиком. Причем
>>>>>>на циске в сторону аддпака - все нормально: пакеты красятся и
>>>>>>ставятся в очередь так что качество разговора в сторону аддпака -
>>>>>>отличное, но от аддпака в сторону циски - страдает от других
>>>>>>потоков трафика.
>>>>>>
>>>>>>
>>>>>>Хорошего мана по QOS для аддпака - не нашел, только какие-то невнятные
>>>>>>формулировки, что необходимо ввеести команду qos-qontrol и max-frame. Но что конкретно
>>>>>>эти команды делают -никому не известно.
>>>>>>
>>>>>>Коллеги, подскажите как настроить qos для голоса на аддпаке! Может кто-то уже
>>>>>>сталкивался.
>>>>>>
>>>>>>PS. Потоки трафика создавались синтетически, iperf`ом из-за аддпака в сторону циски. Паралельно
>>>>>>осуществлялись голосовые вызовы на G.729 (RAS). Соединение строилось через 384К-линк, построенный
>>>>>>на конвертерах. Схема собиралась на стенде, т.е. не в реальных условиях.
>>>>>>Влияние конвертеров - исключено, т.к. условия лабораторные.
>>>>>
>>>>>
>>>>>http://ap200.nm.ru/  тут посмотри
>>>>
>>>>Толкового по QOS и очередям на этом сайте нет. Пока я вообще
>>>>не могу понять, зачем нужны эти команды, которые как-бы должны управлять
>>>>QOS`ом...
>>>>
>>>>
>>>>Люди, реально необходима помощь, т.к. я жестко повязан бюджетом и уже заложил
>>>>эти шлюзы... ХЕЛП!
>>>
>>>Коллеги! Помогите! Может все-таки кто-то на эту тему что-то копал уже. Как
>>>все-таки работает маханизм создания очередей у аддпаке?
>>>
>>>Кстати, ставил такой опыт: два аддпака через тонкий канал, ПК, которые установлены
>>>за аддпаками нагрузили линию с помощью iperf`a, и НИКАКИЕ настройки на
>>>аддпаках не дали приоритета или что-то подобного LLQ для голосового тафика....
>>>
>>>
>>>ХЕЛП!
>>
>>addpac :)
>>давай попробуем разобраться вместе, покажи что уже пробывал и какой был результат.
>>
>>Будем предлогать варианты.
>
>
>Для начала, была собрана следующая схема:
>http://bda.cttc-ryazan.ru/VoIP-LAB.jpg
>
>В схеме - два ПК, на которых отработывал iperf - сначала с
>TCP, затем с UDP-нагрузкой.
>
>В результате, если с TCP-нагрузкой addpac боролся как-то сам, причем никаких команд
>вида qos-control - не вводилось.
>
>Но с UDP-нагрузкой - аддпак - не смог бороться вообще никак, причем
>тут уже пробовались разные варианты.


как я понимаю поток шел от 10.13.29.1 ?
что уже было опробовано ? Команды в студию.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от andreyka459 email(??) on 26-Фев-07, 09:10 
ip-tos rtp precedence 5 не забыли?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от bda email(ok) on 26-Фев-07, 10:05 
>ip-tos rtp precedence 5 не забыли?

Именно четко не указывал TOS=5, но позвольте спросить: а что это даст? Ведь это только маркировка, не влияние на создание очереди для трафика прокрашенного именно пятым тосом...

PS Испробую - доложу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от andreyka459 email(??) on 26-Фев-07, 13:42 
>>ip-tos rtp precedence 5 не забыли?
>
>Именно четко не указывал TOS=5, но позвольте спросить: а что это даст?
>Ведь это только маркировка, не влияние на создание очереди для трафика
>прокрашенного именно пятым тосом...
>
>PS Испробую - доложу.

эта маркировка пакета в поле tos заголовка
если модем tos вдруг поддерживает, то проблема решится

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от bda email(ok) on 26-Фев-07, 14:06 
>>>ip-tos rtp precedence 5 не забыли?
>>
>>Именно четко не указывал TOS=5, но позвольте спросить: а что это даст?
>>Ведь это только маркировка, не влияние на создание очереди для трафика
>>прокрашенного именно пятым тосом...
>>
>>PS Испробую - доложу.
>
>эта маркировка пакета в поле tos заголовка
>если модем tos вдруг поддерживает, то проблема решится

очевидно, модемы TOS - не поддерживают и нет на них механизма WFQ... Т.е.вероятно, необходимо как-то организовать очередность в исходящем интерфейсе... Но как?!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "QOS:AddPac+Cisco через 384К-канал"  
Сообщение от andreyka459 email(??) on 26-Фев-07, 18:53 
>очевидно, модемы TOS - не поддерживают и нет на них механизма WFQ...
>Т.е.вероятно, необходимо как-то организовать очередность в исходящем интерфейсе... Но как?!

qos-control  другого вроде нет. расшифровка параметров попадается нечасто, но гдето была.

Я почему советую, на других несложных модемах помогало. Хотя поддержка tos вроде  и заявлена небыла(но очевидно была в нвличии). И кроме того на CISCO jitter-buffer надо подлинее сделать. при скорости 384кбит длина jb должна быть не менее 60мс. (ведь время передачи одного пакета 1500байт ~30мс) Помоему по умолчанию на cisco много меньще.

у меня так выглядит (на соотв dialpeer):
playout-delay maximum 200
playout-delay nominal 100
playout-delay minimum high

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру