QOS

Reply to QOS on Fri, 13 Feb 2026 19:57:20 GMT

Joseph W. Doherty — Fri, 13 Feb 2026 19:57:20 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:19 GMT

Mlex1 — Fri, 13 Feb 2026 19:57:19 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:18 GMT

balaji.bandi — Fri, 13 Feb 2026 19:57:18 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:17 GMT

Joseph W. Doherty — Fri, 13 Feb 2026 19:57:17 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:16 GMT

Joseph W. Doherty — Fri, 13 Feb 2026 19:57:16 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:15 GMT

Mlex1 — Fri, 13 Feb 2026 19:57:15 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:14 GMT

Joseph W. Doherty — Fri, 13 Feb 2026 19:57:14 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:13 GMT

Mlex1 — Fri, 13 Feb 2026 19:57:13 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:12 GMT

Joseph W. Doherty — Fri, 13 Feb 2026 19:57:12 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:11 GMT

Mlex1 — Fri, 13 Feb 2026 19:57:11 GMT

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

Reply to QOS on Fri, 13 Feb 2026 19:57:10 GMT

Giuseppe Larosa — Fri, 13 Feb 2026 19:57:10 GMT

Здравствуйте,
@Mlex1
, если у вас только один класс трафика LLQ, результат будет таким же. Надеюсь, это поможет Джузеппе

Reply to QOS on Fri, 13 Feb 2026 19:57:09 GMT

Mlex1 — Fri, 13 Feb 2026 19:57:09 GMT

Здравствуйте Например, если у вас есть пакеты VOIP и класс видеопотока, оба с LLQ, и вы хотите обеспечить предпочтительное обращение с пакетами VOIP, вы связываете их класс-карту с наилучшим уровнем приоритета (вероятно, 1), а класс видео — с менее предпочтительным уровнем приоритета (вероятно, 2). Я прочитал в Интернете то, что вы написали. У меня немного другой вопрос: я имею в виду, что при настройке
приоритета 1 процент 30 и приоритета 30 процент
результат будет одинаковым? Желаю всего наилучшего.

Reply to QOS on Fri, 13 Feb 2026 19:57:08 GMT

Giuseppe Larosa — Fri, 13 Feb 2026 19:57:08 GMT

Здравствуйте,
@Mlex1
, если у вас есть карта политик с несколькими картами классов/классами трафика и вы хотите иметь две очереди LLQ, команда priority level позволяет решать проблему конкуренции между очередями LLQ. В вашем случае, когда в карте политик определена одна карта классов, два набора команд дают одинаковый результат: одну очередь LLQ со встроенным полисером, равным 30 % пропускной способности интерфейса. Если у вас было несколько карт классов и две из них с LLQ (команда priority), уровень приоритета предоставляет два уровня для управления конкуренцией между двумя очередями LLQ. Например, если у вас есть пакеты VOIP и класс видеопотока, оба с LLQ, и вы хотите обеспечить предпочтительное обращение с пакетами VOIP, вы связываете их карту классов с наилучшим уровнем приоритета (вероятно, 1), а класс видео — с менее предпочтительным уровнем приоритета (вероятно, 2). Надеюсь, это поможет. Джузеппе

Reply to QOS on Fri, 13 Feb 2026 19:57:07 GMT

Joseph W. Doherty — Fri, 13 Feb 2026 19:57:07 GMT

О, я мог бы упомянуть, что поддержка двух физических очередей LLQ (уровни 1 и 2) была функцией, добавленной в CBWFQ позже. Насколько я помню, «неожиданный» способ работы неявного полицейского класса LLQ не был хорошо задокументирован, когда CBWFQ был впервые выпущен. Однако
@balaji.bandi
в своей ссылке явно описывает его, например: Только трафик, соответствующий токен-бакету, гарантированно имеет низкую задержку.
Любой избыточный трафик отправляется, если канал не перегружен,
или отбрасывается, если канал перегружен. Или Как отмечалось ранее, предлагаемая нагрузка приоритетного класса измеряется контроллером трафика.
В условиях перегрузки приоритетный класс не может использовать избыточную пропускную способность. Или Примечание: Исключением из этих рекомендаций для LLQ является Frame Relay на маршрутизаторе Cisco 7200 и других платформах, не относящихся к Route/Switch Processor (RSP).
Первоначальная реализация LLQ над Frame Relay на этих платформах не позволяла классам приоритетов превышать настроенную скорость в периоды отсутствия перегрузки. В версии Cisco IOS Software Release 12.2 это исключение устранено, и несоответствующие пакеты отбрасываются только в случае перегрузки. Кстати, документация Cisco по QoS значительно улучшилась за последние годы. Также в этом справочнике мы находим: Используйте команду
tx-ring-limit
для настройки размера кольца передачи на значение, отличное от значения по умолчанию. Cisco рекомендует настраивать кольцо передачи при передаче голосового трафика. Незнание этого сводило меня с ума несколько десятилетий назад, когда я разрабатывал эффективное QoS. Наконец я нашел упоминание о необходимости этого в техническом примечании при использовании ATM, которым мы не пользовались. Это полезно не только для голоса, хотя и не должно быть столь важным в локальной сети или любом интерфейсе с высокой пропускной способностью, и, предположительно (по крайней мере, в одно время), Cisco отметила, что некоторые устройства автоматически уменьшают его настройку, когда устройство обнаруживает интерфейс с примененным QoS. @Mlex1
, наконец, я, возможно, эксперт
по
QoS на этих форумах. Если у вас есть другие вопросы по QoS, не стесняйтесь их задавать. Однако имейте в виду, что я считаю большую часть материалов по QoS, касающихся его использования, некачественными. Когда речь заходит о QoS, я считаю себя легендой. ; ) Но если серьезно, я потратил около половины своего времени, более десяти лет, на создание действительно эффективного QoS в производственной среде. Я считаю, что мне это удалось. Кстати, я начинал с рекомендаций из «книг», поэтому я довольно хорошо с ними знаком (и с их зачастую неидеальной эффективностью).