QOS
-
О, я мог бы упомянуть, что поддержка двух физических очередей 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 в производственной среде. Я считаю, что мне это удалось. Кстати, я начинал с рекомендаций из «книг», поэтому я довольно хорошо с ними знаком (и с их зачастую неидеальной эффективностью). -
Здравствуйте,
@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%, но
только
в случае перегрузки (в отличие от явного контролера).
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти