Дамы и господа.
Есть следующая конфигурация: CISCO 2610XM, IOS: c2600-is-mz.122-11.T8. Serial0/0 "Смотрит" на провайдера, Frame-Relay, 128К. К FastEthernet0/0 подключены VoIP-шлюз на 8 линий и, через роутер, внутренняя сеть, из которой должен быть доступен интернет (входящий трафик >> исходящего). Мне надо настроить CISCO так, что бы, если клиентов VoIP нет, то весь канал был доступен пользователям интернет, но телефония должна иметь преимущество. Если я правильно понял импортный язык, то эта CISCO без дополнительных настроек должна пропускать VoIP-пакеты в первую очередь.
Однако, наш провайдер умышленно не желает делать приоретизацию VoIP-трафика, поэтому, мне надо входящие 128К разделить между VoIP и "просто" IP. Могу ли я сделать это для входящего трафика?
Где можно про это почитать, сильно желательно на русском языке?Прошу прощения за корявое изложение проблемы.
>преимущество. Если я правильно понял импортный язык, то эта CISCO без >дополнительных настроек должна пропускать VoIP-пакеты в первую очередь.
по умолчанию -- ничего не должна>Однако, наш провайдер умышленно не желает делать приоретизацию VoIP-трафика,
печально, но тут ничем не поможешь>входящие 128К разделить между VoIP и "просто" IP. Могу ли я
>сделать это для входящего трафика?
для входящего -- безсмысленно, для исходящего -- запросто, см ниже>Где можно про это почитать, сильно желательно на русском языке?
см LLQ на сайте cisco. примерная конфигурацияclass-map match-all ts
match access-group name ts
class-map match-all print
match access-group name print
class-map match-all voice
match ip precedence 5policy-map v4tp
class voice
priority 208
class ts
bandwidth percent 20
class print
bandwidth percent 40int s0/0
bandwidth 512
service-policy output v4tp>VoIP-шлюз на 8 линий
на канале 128Кб даже на G.723 кодеках ничего хорошего не получится
Спасибо за пинок в нужном направлении.
Однако, почему на 128К ничего хорошего не получится?
По рассчётам, на одну линию, с приемлемым качеством, нужно 14,4Kbps.
У нас реально работают 6 линий. Причём очень редко одновременно вламываются более 4 клиентов. 14,4х6=86,4Kbps. Т.е. канал занят на 60%.
Объясните мне, где я не прав?
И потом, если я пережму трафик для интернет клиентов на интерфейсе FastEthernet0/0, не разгрузит ли это входящий канал для VoIP?Из реального опыта следует - если трафика интернет-клиентов нет, то при занятии всех шести линий, качество очень даже приемлемое. А далее начинаются приколы нашего провайдера, но с этим мы бороться не можем. Совет уйти к другому провайдеру не применим в силу ряда обстоятельств. :-(
>4 клиентов. 14,4х6=86,4Kbps. Т.е. канал занят на 60%.
>Объясните мне, где я не прав?
да все нормально
главное чтоб задержка была маленькая>И потом, если я пережму трафик для интернет клиентов на интерфейсе FastEthernet0/0,
>не разгрузит ли это входящий канал для VoIP?
практически нет
потому что трафик обычно идет в соотношении исходящий к входящему = 1 к 10, то есть насколько ж тебе нужно ужать исходящий чтобы реально это повлияло и на входящий, короче интернета не будет вообще
вариант только брать под телефонию отдельный канал
иначе любой всплеск убъет телефонию нафик
>потому что трафик обычно идет в соотношении исходящий к входящему = 1
>к 10, то есть насколько ж тебе нужно ужать исходящий чтобы
>реально это повлияло и на входящий, короче интернета не будет вообще
Или я не понял, или меня не поняли. Попытаюсь объяснить:
Введу определения:
Исходящий трафик - трафик идущий от Cisco независимо от интерфейса.
Входящий трафик - трафик идущий к Cisco независимо от интерфейса.
Я на Cisco пережимаю исходящий трафик на интерфейсе FastEthernet0/0 в направлении пользователей интернет. Соответственно, должен уменьшится входящий трафик на интерфейсе Serial0/0 от провайдера. (Я прав?)
Хотя, даже если я прав, толку от этого будет 0 - трафик придётся блокировать жестко, не зависимо от того есть сейчас IP-клиенты или нет. В результате получаем мёртвый интернет.>вариант только брать под телефонию отдельный канал
>иначе любой всплеск убъет телефонию нафик
:-\ С удовольствием бы. Но, как прозвучало в каком-то фильме - "Сьисть-то он сьисть, да кто-ж ему дасть."
В результате, приходим к выводу - или убивать интернет, или убивать IP-телефонию. :-(((
>>потому что трафик обычно идет в соотношении исходящий к входящему = 1
>>к 10, то есть насколько ж тебе нужно ужать исходящий чтобы
>>реально это повлияло и на входящий, короче интернета не будет вообще
>Или я не понял, или меня не поняли. Попытаюсь объяснить:
>Введу определения:
>Исходящий трафик - трафик идущий от Cisco независимо от интерфейса.
>Входящий трафик - трафик идущий к Cisco независимо от интерфейса.направление трафика всегда рассматривается с относительно портов циско - именно так ка ты описал
>Я на Cisco пережимаю исходящий трафик на интерфейсе FastEthernet0/0 в направлении пользователей
>интернет. Соответственно, должен уменьшится входящий трафик на интерфейсе Serial0/0 от провайдера.
>(Я прав?)при схеме (вроде так из скзанного получается):
клиенты--<ethernet[cisco]serial>--ISP
нет - ты не можешь (как правило) ограничить входящий трафик. входящий трафик контролирует твой провайдер. можешь его принимать или отбрасывать, но канал до тебя он "забил", поскольку уже пришел. если хочешь отбрасывать не нужный трафик, то лучше на мой взгляд это делать на "входе" - на сериале твоем.
а вообще начинать надо с того, что узнать, предоставляет ли твой ИСП услугу ВоИП - приоритет рохождения голосовых пакетов должен поддерживаться по всему маршруту их следования. Один маршрутизатор на пути, который плюет на приоритетную обработку твоих пакетов - и каюк. Поэтому выясняй у провайдера на счет данной услуги (воип - это не интренет) и потом требуй от него того, что он обещал.
>Хотя, даже если я прав, толку от этого будет 0 - трафик
>придётся блокировать жестко, не зависимо от того есть сейчас IP-клиенты или
>нет. В результате получаем мёртвый интернет.
>конфиг выше отвечает твоей задаче, но требуется взаимодействие с твоим провайдером, и с теми кто за ним (но это уже забота провайдера)
>>вариант только брать под телефонию отдельный канал
>>иначе любой всплеск убъет телефонию нафик
>:-\ С удовольствием бы. Но, как прозвучало в каком-то фильме - "Сьисть-то
>он сьисть, да кто-ж ему дасть."
>В результате, приходим к выводу - или убивать интернет, или убивать IP-телефонию.
>:-(((как в том мультфильме - "ребята, давайте жить дружно" :))
>а вообще начинать надо с того, что узнать, предоставляет ли твой ИСП
>услугу ВоИП - приоритет рохождения голосовых пакетов должен поддерживаться по всему
>маршруту их следования. Один маршрутизатор на пути, который плюет на приоритетную
>обработку твоих пакетов - и каюк.>Извините но это полная чепуха. Вы думаете что на всем пути следования
все маршрутизаторы будут поддерживать приоретизацию госового трафика?
Могут но в России лет через двадцать.Реально все работает и так.
У нас голос работает уже три года и сэкономили на этом кучу денег.
Схема: Vanguard V320 (с голосовой картой)с обеих сторон:Мурманск-Новгород
Связь: Inernet 128k (до нашего провайдера)
Приоретизацию трафика делают только наши маршрутизаторы по следующей
схеме на входе ->DVDV на выходе VVDD т.е. опрерируют четверками пакетов.
Качество связи определяется ping-ом и только ping-ом критичная величина
440ms Размер пакета по IP 64 байта тип кодека лучше выбрать опытным путем
а не стараться выбирать самый маленький.
Так у нас работают 6 городов.
Cisco я не не знаю только-только начал изучать (урывками) поэтому практически советовать не могу,но по поводу выше сказанного это все работает и работает давно так-что даже в голову не бери,что там тебе
должен обеспечивать провайдер.
>
>>а вообще начинать надо с того, что узнать, предоставляет ли твой ИСП
>>услугу ВоИП - приоритет рохождения голосовых пакетов должен поддерживаться по всему
>>маршруту их следования. Один маршрутизатор на пути, который плюет на приоритетную
>>обработку твоих пакетов - и каюк.>
>
> Извините но это полная чепуха. Вы думаете что на всем пути
>следования
>все маршрутизаторы будут поддерживать приоретизацию госового трафика?а Вы пробовали этого добиться от вышестоящих провайдеров?
>Могут но в России лет через двадцать.Реально все работает и так.
я не знаю, что будет завтра - не то что ч/з 20 лет. но есть есть такой вид услуг как "доступ в интернет" (коммутируемый, по выделенному каналу, etc - но _интернет_) и есть другоая услуга - "IP телефония". не надо путать одно с другим. провайдеров, которые работают уже сейчас именно на вторую услугу - пруд пруди. провайдеров VoIP и овер других протоколов.
как работаете Вы - это Ваше дело.
>У нас голос работает уже три года и сэкономили на этом кучу
>денег.
>Схема: Vanguard V320 (с голосовой картой)с обеих сторон:Мурманск-Новгород
>Связь: Inernet 128k (до нашего провайдера)
>Приоретизацию трафика делают только наши маршрутизаторы по следующей
>схеме на входе ->DVDV на выходе VVDD т.е. опрерируют четверками пакетов.
>Качество связи определяется ping-ом и только ping-ом критичная величина
>440ms Размер пакета по IP 64 байта тип кодека лучше выбрать опытным
>путем
>а не стараться выбирать самый маленький.
>Так у нас работают 6 городов.
>Cisco я не не знаю только-только начал изучать (урывками) поэтому практически
>советовать не могу,но по поводу выше сказанного это все работает и
>работает давно так-что даже в голову не бери,что там тебе
>должен обеспечивать провайдер.
PS рад что у Вас все замечательно работает и все довольны, но прежде чем называть чепухой чьи-то соображения, может стоит их для начала вдумчиво прочитать?
>нет - ты не можешь (как правило) ограничить входящий трафик. входящий трафик
>контролирует твой провайдер. можешь его принимать или отбрасывать, но канал до
>тебя он "забил", поскольку уже пришел. если хочешь отбрасывать не нужный
>трафик, то лучше на мой взгляд это делать на "входе" -
>на сериале твоем.на входе сериала никак нельзя, трафик провайдер тебе насчитает а ты его не получил, сам отбросил на входе сериала :))))) а канал твой все равно будет забит.
если провайдер сам будет у себя приоритезировать трафик уходящий на тебя это есть гуд, настроишь такие же правила у себя и счастье. Иначе лучше все оставить как есть.
>если провайдер сам будет у себя приоритезировать трафик уходящий на тебя это
>есть гуд, настроишь такие же правила у себя и счастье. Иначе
>лучше все оставить как есть.См. выше. Провайдер _УМЫШЛЕННО_ не желает делать приоретизацию VoIP. Т.к. нашим провайдером является телеком, то наша IP-телефония у него как кость в горле. А сменить провайдера, в силу обстоятельств, мы не можем.
Оставлять всё "Как есть", тоже желания мало - количество жалоб на плохое качество связи будет расти, а это отрицательно влияет на деловой имидж компании. :-(
Вам же пишут, трафик от провайдера довас уже дошел(читай забил канал), отбросив его у себя на входе ничего путного не получите. А приотизировать на выход уже другое дело.
вариант только заиметь еще один канала персонально под телефонию
либо поставить еще одну циску непосредственно на площадке у провайдера, но это целесообразно только если там ее можно подключить по более толстому каналу чем ваш
тогда можно куосить узкое место своими кисками с обоих концов
>>если провайдер сам будет у себя приоритезировать трафик уходящий на тебя это
>>есть гуд, настроишь такие же правила у себя и счастье. Иначе
>>лучше все оставить как есть.
>
>См. выше. Провайдер _УМЫШЛЕННО_ не желает делать приоретизацию VoIP. Т.к. нашим провайдером
>является телеком, то наша IP-телефония у него как кость в горле.слушай - сколько у Вас провайеров поблизости, и ч/з кого каналы во внешний мир в конечном счете идут?
если интересно мыль на lsmail@rambler.ru - я стал редко на форуме появляться.
>А сменить провайдера, в силу обстоятельств, мы не можем.
>Оставлять всё "Как есть", тоже желания мало - количество жалоб на плохое
>качество связи будет расти, а это отрицательно влияет на деловой имидж
>компании. :-(
Даже если бы и было 1е+6 провайдеров, по условиям лицензии мы имеем право гнать трафик только через наш любимый и единственный телеком.
Хоть там у меня и работает друг, но недавно он мне заявил: "Своей IP-телефонией, вы отбираете у нас клиентов, в результате у телекома падают доходы и нам не платят премию." Если это говорит сисадмин телекома, представьте, как им там промывают мозги. А что говорить об обычных работниках?
Так что...
Прежде всего, для каналов меньше 512 кбит требуется делать фрагментацию пакетов. Без этого попадает скажем пакет данных стандартным размером в 1500 байт, и пока он передается по линии (для 128 к это будет
100 мсек) голосовые пакеты изойдут таймаутами.Фрагментация делается средствами MultilinkPPP почитайте на cisco.com на тему QoS и MPPP.
Второе. Никакими средствами невозможно повлиять на входящий трафик, потому что он уже прошел и забил тесный канал. Следовательно в лучшем случае, вы сможете настроить качество для исходящего потока, а входящий у вас все равно будет не работоспособен.
И третье. В VoIP пакетах, накладные расходы (заголовки пакетов, служебная информация) существенно превышают полезную нагрузку.Так, для общепринятого кодека g729 со скоростью 9600 Кюит реальная полоса оказывается в 24К бита. Для менее качественного g729r53 - полоса 16 Кбит.
Иными словами при данных параметрах задача передачи голоса не решается.
-----Впрочем, есть замечательный вариант в данном случае - заказать отдельный PVC под голос на 128К. С одной стороны, отсутствие потока интернет данных делает ненужным фрагментацию, с другой стороны инкапсуляция голоса VoFR позволяет добится потока данных в 12Кбит/сек для G729, что является наилучшим возможным значением на сегодняшний день.
>И третье. В VoIP пакетах, накладные расходы (заголовки пакетов, служебная информация) существенно
>превышают полезную нагрузку.Так, для общепринятого кодека g729 со скоростью 9600 Кюит
>реальная полоса оказывается в 24К бита. Для менее качественного g729r53 -
при использования cRTP получается около 12Кбит на G.729
>при использования cRTP получается около 12Кбит на G.729Ну если вы имели реальный опыт работы с оборудованием Cisco, то могли бы заметить, что коммпрессия до сих пор нормально не работает, даже на IOSах версии 12.3
Да и кроме того компрессия должна быть включена с обоих сторон да и то при условии что оба конца собраны на Cisco, а с этим в данном случае полный провал :)
>Да и кроме того компрессия должна быть включена с обоих сторон да
>и то при условии что оба конца собраны на Cisco, а
>с этим в данном случае полный провал :)
совершенно справедливые выссказывания. все до одного. единственное что я сейчас не совсем понимаю и по причине засыпания не собираюсь в данный момент по докам рыться - это на счет фрагментации пакетов - причем тут Multilink PPP?
>совершенно справедливые выссказывания. все до одного. единственное что я сейчас не совсем
>понимаю и по причине засыпания не собираюсь в данный момент по
>докам рыться - это на счет фрагментации пакетов - причем тут
>Multilink PPP?да к тому что нужно делать не только фрагментацию но и интерливинг, а это все делается только на мультилинке
>Да и кроме того компрессия должна быть включена с обоих сторон да
>и то при условии что оба конца собраны на Cisco, а
>с этим в данном случае полный провал :)Я бы не стал утверждать, что провал полный. С момента открытия темы на моей CISCO появилось 4 голосовых порта FXO. Теперь сижу и разбираюсь, как заставить их работать. Может кто кинет ссылкой с примером настройки этих портов (желательно на русском языке)?
>Ну если вы имели реальный опыт работы с оборудованием Cisco, то могли бы заметить, что коммпрессия до сих пор нормально не работает, даже на IOSах версии 12.3э... а в чем проблема-то? у меня компрессия включена уже как полгода, проблем вроде не заметил. где смотреть?
interface Serial2/0:3
bandwidth 512
ip address 192.168.х.х 255.255.255.0
service-policy output v2tp
encapsulation ppp
ip tcp header-compression iphc-format
ip ospf message-digest-key 1 md5 7 хххххххххххххххххх
no cdp enable
ip rtp header-compression iphc-format
>>Ну если вы имели реальный опыт работы с оборудованием Cisco, то могли бы заметить, что коммпрессия до сих пор нормально не работает, даже на IOSах версии 12.3
>
>э... а в чем проблема-то? у меня компрессия включена уже как полгода,
>проблем вроде не заметил. где смотреть?дада у меня тоже компрессия работает давным давно
реально ужимает почти два раза при 40байтном пакете (полезная нагрузка)Interface Multilink1:
Rcvd: 231189 total, 230924 compressed, 4 errors
0 dropped, 1019112 buffer copies, 0 buffer failures
Sent: 247653 total, 245683 compressed,
9267219 bytes saved, 10458500 bytes sent
1.88 efficiency improvement factorне вижу проблем
вижу 1.88 коэфициент сжатия
может имелось ввиду что компрессию надо на обоих концах активировать иначе толку действительно нет, а провайдеры как правило отказываются
Смотреть тут для начала.sho ip rtp header-compression
Может быть и нет никакой компрессии?
А проблемы не усматриваются, они услышиваются.
После включения компресии клиенты начинают жаловаться на трески, провалы и качество связи перестает быть идеальным и гарантированным.
>Смотреть тут для начала.
>sho ip rtp header-compression
то что я привел как раз оно и есть!>Может быть и нет никакой компрессии?
там все написано>А проблемы не усматриваются, они услышиваются.
>После включения компресии клиенты начинают жаловаться на трески, провалы и качество связи
>перестает быть идеальным и гарантированным.
что-то сомнительно
ip rtp header-compression сжимает только заголовки ртпшных пакетов 40байт в 2-4 и то только на время транспортировки
содержимого пакета оно никак не касается
так что каким образом это может ухудшить качество голоса?
наоборот уменьшение пакета даже улучшает его проходимость