The OpenNET Project / Index page

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

traffic-shape для VoIP (cisco voice voip shaper qos queue)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: cisco, voice, voip, shaper, qos, queue,  (найти похожие документы)
Date: Mon, 14 Oct 2002 19:13:36 +0600 From: "Vasiliy A. Belov" <[email protected]> Newsgroups: ftn.ru.cisco Subject: traffic-shape для VoIP > если же в общих словах то > policy map QoS > class VOIP > bandwidth percent 100 > class VPN > bandwidth percent X > проценты посчитать, или использовать для других классов > просто конкретное число IMHO bandwith 100% странная идея, все бумаги по LLQ советуют голос определять в приоритетную очередь, чтобы без задержек и jitter-а. Hо при этом ограничить ему общую скорость, дабы остальное хоть как то жило. Скажем так - policy-map MY_MAP class voice priority 1024 police 1024000 32000 32000 conform-action transmit exceed-action drop class vpn bandwidth percent 50 class ANY random-detect А если есть полный T1 голоса - это ж типа 50-60 одновременных разговоров... Вряд ли это. Или пора на второй раскошеливаться. ;) > если у тебя это на входящем интерфейсе то шейпить там бестолку, тк > дропаться это будет в output queue предидущей железяки Опять же IMHO policing полосы низкоприоритетного трафика на входящем интерфейсе будет способствовать разгрузке и "входящего" канала (по принципу срыва скорости tcp сессий, ключевое слово RED (WRED), читать зачем он нужен).
From: "Vasiliy A. Belov" <[email protected]> > Итак максимальное количество одновременных разговоров по voip - это 24 у > меня, но на практике дело больше 5-ти не шло. Это может изменится, но я не > думаю, что оно будет больше 10-ти. Кодек - 729. > VPN это связь с ремотным офисом. Оно больше 128К быть не может. У них ISDN. > Вот все остальное и беспокоит меня больше всего. Дело в том, что я пользую > этот канал по самое не могу время от времени. Hедано 10 CD из MSDN-а > скачивал, да еще и у меня бекам сиквела идет на ремоный фтп. Т.е. бывает > ситуации 1-2 раза в неделю, что в течении нескольких часом канал > используется на 95-99%. Вот если в это время будут поступать звонки, то > нужно чтобы приоритет был отдан звонкам. Я не хочу _перманентно_ > резервировать полосу пропускания для звонков и VPN. Хочется чтобы это было > динамично. Ясно. Плохо, т.к. затык все же на входе... IMHO тогда так - 1. policy на выходе все же не помешает policy-map OUT class voice priority 128 # где-то 22K * max sessions, а уже сколько - 5 или 24 - решать админу class vpn bandwith 128 class ANY fair-queue Хотя я бы добавил в voice policy, примерно такое - police 128000 4000 4000 conform-action transmit exceed-action drop Комментарий - - голос - в приорететную очередь, но с лимитом (примерно на 22K * max число одновременных разговоров, наивероятнейшее или физический max), - vpn-у - его bandwith, - всему остальному - остальное. 2. на входе (imho опять же) стоит сделать так - policy-map IN class vpn+voice bandwith 256 class ANY bandwith percent 80 random-detect Комментарий - дропанье пакетов в очереди "для остального" при попытке получить больше чем N% (80% канала в примере) будет приводить к срыву скоростей tcp сессий этого самого "остального" и позволит хоть как то разгрузить канал "на вход" для важных приложений. Возможно стоит описать, управление дропами через команды CAR, но лезть в описание ломает...

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




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

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