Как CBWFQ определяет, какой трафик является высокоприоритетным, а какой нет?

[Mitrixsen]

Здравствуйте, все. В настоящее время я изучаю QoS для экзамена ENCOR и настраиваю классы и очереди. Я понимаю, что CBWFQ — это алгоритм очередей, в котором мы можем определять наши классы, создавать для них очереди и гарантировать каждому из них минимальный процент пропускной способности во время перегрузки. Мои источники также говорят, что планировщик
будет помещать больше пакетов из очередей с более высоким приоритетом во время CBWFQ
. И здесь у меня возникает вопрос.
Как мы сообщаем коммутатору/маршрутизатору о приоритете наших классов? Как мы сообщаем нашему устройству, что важно, а что нет? Я не нашел никаких команд, касающихся этого. Внутри карты политик мы можем настроить несколько вещей, таких как распределение пропускной способности, WRED и т. д., но как планировщик узнает, что считается высоким приоритетом, а что нет? Например, как устройство/планировщик узнает, что трафик, классифицированный, скажем, как CLASS-A, должен считаться более важным, чем остальной, и что во время CBWFQ из него должно отправляться больше пакетов? Спасибо. Дэвид

[Joseph W. Doherty]

«Как
мы сообщаем коммутатору/маршрутизатору о приоритете наших классов? Как мы сообщаем нашему устройству, что важно, а что нет?» Все просто: это основано на распределении пропускной способности по классам, а именно на коэффициентах декьюинга. Например, приведенная ниже Карта политик x Класс a Процент приоритета 30 Класс class-default Оставшаяся пропускная способность, процент 100 Какой из двух классов может содержать трафик с более высоким приоритетом? Или задано: Карта политик y Класс a Процент пропускной способности 1 Класс class-default Процент пропускной способности 5 Какой из двух классов может содержать трафик с более высоким приоритетом? А также, насколько он важнее? Я знаю, что обычно CBWFQ преподается как резервирование или гарантия пропускной способности, но его также можно рассматривать по коэффициентам удаления из очереди. Или данное: Карта политик z Класс a Процент пропускной способности 10 Класс class-default Процент пропускной способности 50 Чем политика z отличается от политики y?

[Ramblin Tech]

«
Например, как устройство/планировщик узнает, что трафик, классифицированный, скажем, как CLASS-A, следует считать более важным, чем остальной, и что из него должно отправляться больше пакетов во время CBWFQ?
» Краткий ответ: вы указываете планировщику, насколько важен для вас класс, с помощью команды bandwidth в policy-map для этого класса. Чем важнее класс, тем выше настроенное распределение пропускной способности для него по сравнению с менее важными классами. Затем планировщик удаляет из очереди относительно больше трафика из класса с более высокой пропускной способностью для последовательной передачи. Более подробный ответ: то, сколько трафика планировщик должен извлечь из «потока» и сериализовать, прежде чем перейти к обслуживанию следующего потока в данном «раунде», определяется различными алгоритмами планирования (Round-Robin, WRR, Deficit RR, Fair Queue, WFQ, CB-WFQ и т. д.). В CB-WFQ «поток» — это класс трафика, определяемый картой классов и назначаемый очереди. Само название/обозначение очереди не имеет присущего ему приоритета, поскольку относительное назначение приоритета происходит из команды настройки пропускной способности (Примечание: я использую здесь строчную букву «p» для обозначения относительных приоритетов, чтобы отличать очереди, запланированные через CB-WFQ, от «приоритетных» очередей, запланированных как строгий приоритет). Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя собственная вина, так как они не генерируются ИИ.

[MHM Cisco World]

Cisco делает таблицу для всего трафика с высоким приоритетом и помечает его. Думаю, я уже делился этим с вами. Используйте ACL для сопоставления этого трафика, а затем отметьте или укажите глубину очереди для него. Также вы можете указать процент каждого трафика от пропускной способности канала. MHM

[Devaa]

Привет
[, @Mitrixsen] Ответ на ваш вопрос — это команда
priority
внутри
класса
в
policy-map
. Дополнительную информацию см. в этом
документе
. Примечание: LLQ позволяет настраивать несколько очередей/классов в качестве приоритетных очередей для каждой policy-map. LLQ фактически помещает пакеты из нескольких LLQ (очередей/классов) в одну внутреннюю LLQ. Таким образом, пакеты в различных настроенных приоритетных очередях по-прежнему планируются перед не приоритетными очередями, но они обслуживаются на основе времени их прибытия для всех пакетов в любой из приоритетных очередей. policy-map ABCD class ICMP bandwith percent 10 ---> Normal Queue class CLI priority percent 10 ---> Priority Queue
end ![CBFQ with LLQ.png]

[Joseph W. Doherty]

Я подозреваю, что Джим не видел моего ответа, когда публиковал свой. Его ответ в основном повторяет то же самое, но его использование потока, на класс, хотя и правильно с точки зрения его связи с классом, может быть неправильно понято, поскольку класс может иметь, и часто имеет, несколько потоков (src/dst) внутри класса, а CBWFQ поддерживает FQ внутри класса или классов. CBWFQ FQ до HQF на самом деле был WFQ, и его потоки также конкурировали с потоками других классов. (Надеюсь, вам не понадобится знать о CBWFQ до HQF, но знайте, что у него есть некоторые значительные и не очевидные различия при одинаковом синтаксисе.) После HQF FQ извлекает свои потоки из очереди равномерно внутри класса и извлекает класс из очереди относительно других классов, как и ожидалось.

[Ramblin Tech]

Привет, Джо! Да, наши ответы прошли мимо друг друга. Я сам не совсем доволен использованием слова «поток» в своем ответе, так как его слишком легко спутать с концепцией потока из 5-тупл IP. Я использовал его скорее как абстрактное понятие, поскольку в некоторых публикациях по сетевому/рабочему планированию «поток» может использоваться в абстрактном смысле для обозначения сессии работы, требующей обслуживания. «Очередь» могла бы быть другим вариантом формулировки, но она может иметь свой собственный багаж, связанный с зависимостями от реализации и алгоритма планирования. В любом случае... я думаю, что идея была понята. Отказ от ответственности: я давно работаю в CSCO. Плохие ответы — моя собственная вина, так как они не генерируются ИИ.

[Joseph W. Doherty]

@Ramblin Tech
написал:
Привет, Джо! Да, наши ответы прошли мимо друг друга. Я сам не совсем доволен использованием слова «поток» в своем ответе, так как его слишком легко спутать с концепцией потока из 5-тупл IP. Я использовал его скорее как абстрактное понятие, поскольку в некоторых публикациях по сетевому/рабочему планированию «поток» может использоваться в абстрактном смысле для обозначения сеанса работы, требующего обслуживания. «Очередь» могла бы быть другим вариантом формулировки, но она может иметь свой собственный багаж, связанный с зависимостями от реализации и алгоритма планирования. В любом случае... я думаю, что идея была понята. Джим, я точно понял, что ты написал, но, как и ты, я почувствовал, что «поток», как ты его использовал, может быть неправильно понят по той причине, которую ты указал. Кроме того, когда вы активируете FQ в классе, CBWFQ может выполнять оба вида «потоков»: поток/очередь вашего класса или поток/очередь из 5-х элементов. Помимо FQ, два вида «потоков» также могут быть использованы при использовании иерархической политики, поскольку потоки подчиненных (например, дочерних) классов политики отображаются в один поток родительского класса.