QOS

[Mlex1]

Хорошо, для примера я выбрал этот вариант, как это работает на практике? policy-map TEST
class FOR_TEST
priority percent 30 трафик с приоритетом всегда будет контролироваться до 30% пропускной способности интерфейса, приоритетный трафик никогда не может использовать более 30% пропускной способности интерфейса.
Я прав? Желаю всего наилучшего

[Joseph W. Doherty]

приоритетный трафик всегда будет контролироваться до 30% пропускной способности интерфейса, «Всегда», нет. (Для постоянного контроля необходимо добавить явный контролер.) приоритетный трафик никогда не может использовать более 30% пропускной способности интерфейса. «Никогда», нет; может использовать до 100%. (По крайней мере,
удивительно
, но раньше так и было.)

[Mlex1]

Если у вас есть ссылка, поделитесь ею, пожалуйста, или любой другой документацией. Желаю всего наилучшего

[Joseph W. Doherty]

Кроме того, что уже ответил
@balaji.bandi
? Поскольку на ваши первоначальные вопросы уже даны ответы, есть ли у вас другие вопросы, или ответы неясны, или вы ищете подтверждение в документации? Поскольку QoS — это обширная тема, постарайтесь быть как можно более конкретными в своих последующих вопросах.

[Mlex1]

В условиях перегрузки приоритетный класс не может использовать избыточную пропускную способность. Я правильно понимаю, что если нет перегрузки интерфейса, приоритетный класс может использовать более 30 или 40% и так далее? Желаю всего наилучшего.

[Joseph W. Doherty]

Я правильно понимаю, что если нет перегрузки интерфейса, приоритет может использовать более 30 или 40% и так далее? Верно. Кстати, это не только мое мнение, это также утверждает Cisco в своей документации, на которую ссылается
@balaji.bandi
и которую я привел в предыдущем ответе. Я полагаю, что причина такого поведения заключается в том, что неявный полисер гарантирует трафику, не относящемуся к LLQ, определенный процент пропускной способности, но, как и в случае с другими классами, если есть доступная пропускная способность, трафик класса LLQ может ее использовать. Если вы хотите всегда ограничивать пропускную способность класса LLQ, вы можете настроить явный полисер.

[Joseph W. Doherty]

Кстати, техническая записка по 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.

[balaji.bandi]

Добавляю предложение и пояснение
@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

[Mlex1]

Привет Полагаю, вы также неправильно поняли, что в ссылке речь идет именно о проценте оставшейся пропускной способности Желаю всего наилучшего

[Joseph W. Doherty]

Эти настройки отличаются или совпадают, и как они работают в реальных условиях? 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%, но
только
в случае перегрузки (в отличие от явного контролера).