Да, видимо тормоз. Ткните пальцем где Вы писали о том что и на базе каких технологий работает (с указанием имен технологий чтобы я в случае смог выгуглить).
Вы гоните. У Вас были только общие фразы. Понять что именно под ними Вы имеете ввиду было невозможно. Непонятно какие программно-аппаратные комплексы обеспечивали Вам вашу приоритетизацию пакетов и какими стандартами это регулируется.
Нашел ссылку только на Cisco IOS. Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами? Как Вы проверяете соответствие реальной ситуации обещанной? Существуют ли способы измерения QoS?
Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
было спрошено какая технология -- я ответил. детали не запрашивались какими стандартами это регулируется.
нафига тут какие-то стандарты?! это настройка моего оборудования, зачем мне на это стандарты?
Нашел ссылку только на Cisco IOS. Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами? Как Вы проверяете соответствие реальной ситуации обещанной? Существуют ли способы измерения QoS?
Да, моей Cisco. У провайдера я беру выделенный канал, без всяких его цисок. FR или LL или еще что. Контролирую задержку и потери на канале. Средства измерения есть в IOS.
Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
Мне на это наплевать, мне надо что бы параметры предоствляемого канала были в заявленных пределах (задержка, потери, ширина), а из-за чего они ухудшились -- мне уже все равно (ошибки на последней миле, оверсубскрайбинг, ошибки в настройке оборудования) и бить провайдера по голове буду одинаково.
Спасибо за ответ. Иначе говоря, качество Вы гарантируете только на своей циске, а дальше что Бог пошлет. То есть Вы не требуете скажем у провайдера таких же строгих приоритетов трафика как у себя.
Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
Пошлите в Википедию, что ли... По моему опыту характерная черта всех цисководов в том что они не могут объяснить все в двух словах - им проще послать. В результате я ничего не понимаю в BGP, QoS и VoIP.
> Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
Для данного вопроса это совершенно пофиг. Может быть и НС, и поток в FR, и сочетание всего вместе, лишь бы оно удовлетворяло принципу, что от точки A до точки B обеспечивается IP поток скорости не меньше указанной. При этом точки вполне могут находиться на разных континентах.
> Спасибо за ответ. Иначе говоря, качество Вы гарантируете только на своей циске, а дальше что Бог пошлет. То есть Вы не требуете скажем у провайдера таких же строгих приоритетов трафика как у себя.
От транспортного провайдера требуется обеспечение договоренного CIR. А от того кому приходит другой конец канала - если он обеспечивает QoS - обеспечение нужной политики (которая определяет 1) классификацию трафика, 2) приоритизацию трафика при сохранении заданных гарантированных, предельных полос и реакции на всплески). Если стыкуются сети разной подчинённости, на их стыке определяется как каждая сторона понимает QoS метки другой стороны (приоритет 802.1p, TOS пакета IP и так далее). Есть стандартные понимания этих значений, которых сейчас вполне достаточно чтобы включив QoS в принципе и настроив полосы - можно было ожидать, что оно будет работать так как надо. Пока не сломали;))
Ваш ответ подходит под мое определение IP-cояединения точка-точка. То есть ві покупаете у провайдера не просто QoS а IP QoS между конкретными точками A и B и на нижележащий транспорт Вам наплевать.
Вопросы о "строгих приоритетах" возникли оттого, что меня смущала Ваша привязка к CIR. CIR - это всего лишь гарантированная полоса пропускания, а голосовой траффик еще чувствителен к latency и даже jitter. Эта тройка параметров полностью определяет QoS?
Что насчет разных схем приоритетности/queuing disciplines? Вам все равно какую провайдер будет использовать для Вашего трафика? Или три параметра QoS определяют ее практически однозначно и требований трех параметров (или даже двух) достаточно?
> Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
Вот такие вещи решаются только юридически.:)
> Существуют ли способы измерения QoS?
Да. Загрузить поток на полную обещанную полосу и проверить с другой стороны, что пришло столько же.
> Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами?
Понимание QoS тегов сейчас достаточно стандартно, чтобы надеяться не только на Cisco.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2006-10-16 03:26 pm (UTC)no subject
Date: 2006-10-16 03:39 pm (UTC)no subject
Date: 2006-10-16 03:49 pm (UTC)no subject
Date: 2006-10-16 05:24 pm (UTC)no subject
Date: 2006-10-16 08:46 pm (UTC)no subject
Date: 2006-10-16 09:29 pm (UTC)ссылку на пост где я писал ключевое слово (стрикт приорити) мне искать лень...
no subject
Date: 2006-10-16 11:45 pm (UTC)Нашел ссылку только на Cisco IOS. Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами? Как Вы проверяете соответствие реальной ситуации обещанной? Существуют ли способы измерения QoS?
Сможете ли Вы отловить момент когда кусок канала, выделяемый Вам провайдером, уменьшится? Грубо говоря момент когда сумма проданных провайдером "гарантированных полос" превысит возможности внешних каналов?
no subject
Date: 2006-10-17 04:27 am (UTC)здрасте. каков вопрос -- таков ответ.
разжевать в постановке вопроса не звучало
было спрошено какая технология -- я ответил. детали не запрашивались
нафига тут какие-то стандарты?! это настройка моего оборудования, зачем мне на это стандарты?
Да, моей Cisco. У провайдера я беру выделенный канал, без всяких его цисок. FR или LL или еще что. Контролирую задержку и потери на канале. Средства измерения есть в IOS.
Мне на это наплевать, мне надо что бы параметры предоствляемого канала были в заявленных пределах (задержка, потери, ширина), а из-за чего они ухудшились -- мне уже все равно (ошибки на последней миле, оверсубскрайбинг, ошибки в настройке оборудования) и бить провайдера по голове буду одинаково.
no subject
Date: 2006-10-17 04:44 am (UTC)Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
no subject
Date: 2006-10-17 05:33 am (UTC)no subject
Date: 2006-10-17 06:33 pm (UTC)no subject
Date: 2006-10-17 07:05 pm (UTC)что там в википедии творится -- я не знаю, могу послать на www.cisco.com с предварительным заходом на http://www.protocols.ru/
no subject
Date: 2006-10-17 08:44 pm (UTC)no subject
Date: 2006-10-17 10:20 pm (UTC)таки не знаете.
я не зря на такие основы посылаю. а ietf слишком много содержит постороннего и многое там отсутствует
no subject
Date: 2006-10-17 05:40 am (UTC)> Что значит "выделенный канал"? Просто IP? Или просто НС - физическое соединение точка-точка?
Для данного вопроса это совершенно пофиг. Может быть и НС, и поток в FR, и сочетание всего вместе, лишь бы оно удовлетворяло принципу, что от точки A до точки B обеспечивается IP поток скорости не меньше указанной. При этом точки вполне могут находиться на разных континентах.
> Спасибо за ответ. Иначе говоря, качество Вы гарантируете только на своей циске, а дальше что Бог пошлет. То есть Вы не требуете скажем у провайдера таких же строгих приоритетов трафика как у себя.
От транспортного провайдера требуется обеспечение договоренного CIR. А от того кому приходит другой конец канала - если он обеспечивает QoS - обеспечение нужной политики (которая определяет 1) классификацию трафика, 2) приоритизацию трафика при сохранении заданных гарантированных, предельных полос и реакции на всплески). Если стыкуются сети разной подчинённости, на их стыке определяется как каждая сторона понимает QoS метки другой стороны (приоритет 802.1p, TOS пакета IP и так далее). Есть стандартные понимания этих значений, которых сейчас вполне достаточно чтобы включив QoS в принципе и настроив полосы - можно было ожидать, что оно будет работать так как надо. Пока не сломали;))
no subject
Date: 2006-10-17 06:49 pm (UTC)Вопросы о "строгих приоритетах" возникли оттого, что меня смущала Ваша привязка к CIR. CIR - это всего лишь гарантированная полоса пропускания, а голосовой траффик еще чувствителен к latency и даже jitter. Эта тройка параметров полностью определяет QoS?
Что насчет разных схем приоритетности/queuing disciplines? Вам все равно какую провайдер будет использовать для Вашего трафика? Или три параметра QoS определяют ее практически однозначно и требований трех параметров (или даже двух) достаточно?
no subject
Date: 2006-10-17 05:48 am (UTC)Вот такие вещи решаются только юридически.:)
> Существуют ли способы измерения QoS?
Да. Загрузить поток на полную обещанную полосу и проверить с другой стороны, что пришло столько же.
> Похоже что Ваш хваленый QoS обеспечивается Вам Циской и Циской провайдера и дальше по цепочке, где каждая пара связана контрактными обязательствами?
Понимание QoS тегов сейчас достаточно стандартно, чтобы надеяться не только на Cisco.
no subject
Date: 2006-10-17 06:55 pm (UTC)Я имел ввиду, сможете ли Вы вовремя отловить снижение QoS. Как его потом вернуть взад - в-общем, понятно.
> Понимание QoS тегов сейчас достаточно стандартно, чтобы надеяться не только на Cisco.
В-общем, вы ответили на вопрос.