Ключевые слова:cisco, voice, voip, shaper, qos, queue, (найти похожие документы)
Date: Mon, 14 Oct 2002 19:13:36 +0600
From: "Vasiliy A. Belov" <vab@rtcomm.ru>
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" <vab@rtcomm.ru>
> Итак максимальное количество одновременных разговоров по 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,
но лезть в описание ломает...
