QOS
-
Здравствуйте,
@Mlex1
, если у вас есть карта политик с несколькими картами классов/классами трафика и вы хотите иметь две очереди LLQ, команда priority level позволяет решать проблему конкуренции между очередями LLQ. В вашем случае, когда в карте политик определена одна карта классов, два набора команд дают одинаковый результат: одну очередь LLQ со встроенным полисером, равным 30 % пропускной способности интерфейса. Если у вас было несколько карт классов и две из них с LLQ (команда priority), уровень приоритета предоставляет два уровня для управления конкуренцией между двумя очередями LLQ. Например, если у вас есть пакеты VOIP и класс видеопотока, оба с LLQ, и вы хотите обеспечить предпочтительное обращение с пакетами VOIP, вы связываете их карту классов с наилучшим уровнем приоритета (вероятно, 1), а класс видео — с менее предпочтительным уровнем приоритета (вероятно, 2). Надеюсь, это поможет. Джузеппе -
Здравствуйте Например, если у вас есть пакеты VOIP и класс видеопотока, оба с LLQ, и вы хотите обеспечить предпочтительное обращение с пакетами VOIP, вы связываете их класс-карту с наилучшим уровнем приоритета (вероятно, 1), а класс видео — с менее предпочтительным уровнем приоритета (вероятно, 2). Я прочитал в Интернете то, что вы написали. У меня немного другой вопрос: я имею в виду, что при настройке
приоритета 1 процент 30 и приоритета 30 процент
результат будет одинаковым? Желаю всего наилучшего. -
Здравствуйте,
@Mlex1
, если у вас только один класс трафика LLQ, результат будет таким же. Надеюсь, это поможет Джузеппе -
Хорошо, для примера я выбрал этот вариант, как это работает на практике? policy-map TEST
class FOR_TEST
priority percent 30 трафик с приоритетом всегда будет контролироваться до 30% пропускной способности интерфейса, приоритетный трафик никогда не может использовать более 30% пропускной способности интерфейса.
Я прав? Желаю всего наилучшего -
приоритетный трафик всегда будет контролироваться до 30% пропускной способности интерфейса, «Всегда», нет. (Для постоянного контроля необходимо добавить явный контролер.) приоритетный трафик никогда не может использовать более 30% пропускной способности интерфейса. «Никогда», нет; может использовать до 100%. (По крайней мере,
удивительно
, но раньше так и было.) -
Если у вас есть ссылка, поделитесь ею, пожалуйста, или любой другой документацией. Желаю всего наилучшего
-
Кроме того, что уже ответил
@balaji.bandi
? Поскольку на ваши первоначальные вопросы уже даны ответы, есть ли у вас другие вопросы, или ответы неясны, или вы ищете подтверждение в документации? Поскольку QoS — это обширная тема, постарайтесь быть как можно более конкретными в своих последующих вопросах. -
В условиях перегрузки приоритетный класс не может использовать избыточную пропускную способность. Я правильно понимаю, что если нет перегрузки интерфейса, приоритетный класс может использовать более 30 или 40% и так далее? Желаю всего наилучшего.
-
Я правильно понимаю, что если нет перегрузки интерфейса, приоритет может использовать более 30 или 40% и так далее? Верно. Кстати, это не только мое мнение, это также утверждает Cisco в своей документации, на которую ссылается
@balaji.bandi
и которую я привел в предыдущем ответе. Я полагаю, что причина такого поведения заключается в том, что неявный полисер гарантирует трафику, не относящемуся к LLQ, определенный процент пропускной способности, но, как и в случае с другими классами, если есть доступная пропускная способность, трафик класса LLQ может ее использовать. Если вы хотите всегда ограничивать пропускную способность класса LLQ, вы можете настроить явный полисер. -
Кстати, техническая записка по ATM, на которую я ссылался:
https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/ip-to-atm-class-of-service/6142-txringlimit-6142.html Как я уже писал ранее, настройка tx-ring-limit может иметь решающее значение для правильной работы политики CBWFQ, и не только для интерфейсов ATM или поддержки голосовой связи. По сути, она контролирует настройку глубины аппаратной
FIFO
-очереди интерфейса. Перефразируя фразу из
«Дюны»
«Страх убивает разум»,
можно
сказать,
что FIFO убивает QoS
. Кроме того, «вещи» очереди CBWFQ вступают в игру только при переполнении очереди tx-ring. Я упоминаю об этом, потому что любой, кому нужно использовать LLQ, скорее всего, пытается обеспечить эффективное QoS. -
Добавляю предложение и пояснение
@Giuseppe Larosa
. Какая модель устройства и код IOS используется на устройстве? Ознакомьтесь с приведенным ниже справочным руководством: https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html BB
=====Preenayamo Vasudevam=====
***** Оцените все полезные ответы *****
Как обратиться за помощью к сообществу Cisco -
Привет Полагаю, вы также неправильно поняли, что в ссылке речь идет именно о проценте оставшейся пропускной способности Желаю всего наилучшего
-
Эти настройки отличаются или совпадают, и как они работают в реальных условиях? policy-map TEST класс FOR_TEST priority lavel 1 percent 30 ! policy-map TEST класс FOR_TEST приоритет процент 30 Как показано, они одинаковы (и как уже описано другими). Также, как и: policy-map TEST класс FOR_TEST уровень приоритета 2 процент 30 Что касается того, как они будут работать, все они будут обеспечивать один физический LLQ, а трафик
только
в классе FOR_TEST будет контролироваться на уровне 30%, но
только
в случае перегрузки (в отличие от явного контролера).
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти