Может ли priority queue в LLQ полностью заблокировать остальные очереди в случае congestion?

Отвечен
2
0

Если идут пакеты из класса с указанием priority, то маршрутизатор сосредотачивается на передаче этих пакетов. Как только все приоритетные пакеты закончились, наступает очередь CBWFQ…

Теоретически, если у нас на интерфейсе перегрузка и пакеты из класса priority идут и идут, и никак не закончатся, то очередь CBWFQ никогда не наступит, несмотря на policing приоритетной очереди?

Лучший ответ
1
0

Из того, что я на данный момент понял короткий ответ — если LLQ задан с bandwidth — то ответ нет. (но вроде бы можно (или можно было) задать без указаний ограничений, и тогда будет то, что ты сказал, но он будет использовать всю доступную пропускную способность outgoing интерфейса, или то, что осталось после Шейпинга.)

LLQ и CBWFQ — это методы реорганизации софтовой очереди, а вот с TX-Ring (хардварной очереди) всё уже идет в таком порядке, как реорганизовали, т.е. можно представить например, что за раз снимается не один пакет, а пачкой сразу несколько (и ты задаешь какая часть пачки для какого класса) из софтовой очереди в TX-Ring и затем они все вперемешку отправляются на интерфейс …

Если конкретнее:

Как ты, наверное знаешь:

  1. LLQ — метод задает ширину канала в Килобитах (т.е. в той же единице измерения, что и CBWFQ (Bandwidth reservation) )

(config-pmap-c)#priority <bandwidth-kbps | percent <percentage>> [burst-size]

  1. Если трафик к которому применяется LLQ поступает в очередь со скоростью менее заданной ширины (см п. 1) — он сразу же «проталкивается» к концу очереди, т.к. смысл всего танца в том чтобы снизить Latency(задержку пакета в роутере/свиче), т.е. не позволить пакетам VoIP торчать в очереди >300ms.

 

  1. Если трафик к которому применяется LLQ поступает в очередь со скоростью более заданной  ширины (командой priority), та часть трафика, что умещается в ограничения продолжает проталкиваться сразу в конец софтовой очереди. Часть, которая не умещается ставится в очередь «на правах» FIFO (т.е. в конец не проталкивается), если в очереди есть место. Если в очереди нет уже даже места (например т.к. все потоки с указанным priority и bandwidth заняли всё доступное) этот избыток трафика (обрабатываемого через LLQ) отбрасывается  (если у нас tail drop).

Так вот, если задать Резервирование BW для одного трафика (CBWFQ, командой bandwidth), и LLQ  для другого трафика (команда priority), То ты в сумме можешь задать только 100% или какая бы там ни была BW в килобитах/с, следовательно Ответ на твой вопрос:

Нет, LLQ не помешает зарезервированному трафику, потому-что LLQ —  это тот же самый Bandwidth reservation (CBWFQ) с функцией проталкивания трафика в конец очереди.  То есть он с ними на равне! С единственной разницей, что для LLQ пакеты не ждут всю софтовую очередь и не теряют драгоценные миллисекунды, если не превышают заданных ограничений.

Т.е. Ключевой момент в том, что при задании LLQ, для потока данных ты здесь все равно не можешь превысить скорость, с которой он будет выталкиваться в интерфейс (Сериализация), и даже скорость, которая осталась от уже зарезервированной ширины канала.

Т.е. Ты как вариант ещё можешь представить, что из Software-очереди (как она там правильно называется?:) ) в TxRing берется не по одному пакету, а сразу пачкой по несколько. А задача LLQ, как и CBWFQ, засунуть в эту пачку только кол-во пакетов ограниченное настройками заданными в kbit/s  или в процентах (от этой пачки). А с HW-Queue (TxRing) все уже уходит вперемешку, то есть  задача LLQ – не заставлять пакет ждать время, пока он пройдет софтовую очередь, и одновременно с этим не мешать другим потокам с зарезервированной полосой. Т.е. методы LLQ и CBWFQ они работают на уровне Софтовых очередей, они реорганизуют траффик на уровне софтовых очередей, а затем оттуда этот трафик уже приземляется в HW-Queue (TxRing) и отправляется со скоростью интерфейса.

Ответ на твой вопрос на 5:17. Звук тихий очень — у меня микро неочень.., и звуковой нет дискретной.

  • YEVGENIY ARTEMENKO
    Ну может у циски и так, но не факт что все так реализуют, не факт даже, что у циски везде такая реализация. Забор пакетов не происходит «через равные промежутки времени» — иначе мы не сможем обеспечить Fair Queueing. Забор пакетов через равные промежутки времени — это Round Robin, просто так проще было объяснить… Вот цитата из одного из документов выданных экспертами: «WFQ is one of Cisco’s premier queuing techniques. It is a flow-based queuing algorithm that creates BIT-WISE FAIRNESS by allowing each queue to be serviced fairly in terms of byte count.»
  • moonshiner
  • YEVGENIY ARTEMENKO
    А к чему это конкретно? Это вообще 2008, -7 лет. Много изменилось, нужно уточнять, может уже ip precedence не используется так в WFQ, но посмотрим когда будем CBWFQ ковырять в середине мая…
  • moonshiner
    Я сомневаюсь, что скрытые формулы подсчета весов изменились. Ведь ничего прорывного в области QoS за 8 лет не произошло. Я запостил эту ссылку для того, чтобы не потерять информацию о том как НА САМОМ деле распределяется полоса в CBWFQ и LLQ. В официальных документах такой информации не найти. Ну и тебе, Евгений, это может быть полезно для симуляции)
  • YEVGENIY ARTEMENKO
    Да моя модель с несколькими очередями как раз, это подтверждает, то что ты скинул, но я где-то вроде бы слышал, что сейчас ip precedence для без безклассового WQF не используется по умолчанию, а делятся поровну просто…
Лучший ответ
1
0

Вот что я имел Ввиду посмотри, ответ на твой вопрос на 5:17. Звук тихий очень — у меня микро неочень.., и звуковой нет дискретной.

  • moonshiner
    Спасибо за проделанную работу, Евгений!
  • YEVGENIY ARTEMENKO
    Я тренируюсь… тоже хочу делать обучающие видео :)
Отличный ответ
0
0

Схороню картинку:

https://itnetworkingpros.files.wordpress.com/2011/12/llq.png

 

Now what does this priority command really do for us, well it creates a low latency queue for traffic that needs to be transmitted before other type of data. So if there is data in the low latency queue when does the data in the other queue’s get transmitted, easy when the low latency queue is empty or when the low latency queue exceeds its specified amount of bandwidth. The low latency queue is also policed by the bandwidth we have allocated it. If the low latency queue ever exceeds the amount of bandwidth it has been allocated it will drop the packet and move to another queue.

1
0

Если говорим про LLQ. LLQ=1PQ+CBWFQ

И настройка PQ вида

Router(config)# policy-map policy1
Router(config-pmap)# class class1
Router(config-pmap-c)#priority <bandwidth-kbps | percent <percentage>> [burst-size]
Команда "priority" указывает на первоочередное обслуживание данного класса + выставляет ограничение по скорости для данного класса.
Иными словами, команда "priority" имеет "internal policer", а значит место для другого вида трафика остается. В этом и прелесть технологии, и голос ходит, и дата... и никто не страдает.
  • moonshiner
    Господа, вы приводите здесь данные из учебников, которые я уже прочитал вдоль и поперед, пытаясь понять, как этот «internal policer» спасает CBWFQ от недоедания. Возможно, моя логика где то ущербна, если так, прошу указать, где: (1) Выходной аппаратный буфер интерфейса заполняется до определенного порога, звенит звоночек, — и вот на помощь ринулась наша service-policy, в которой настроен LLQ. (2) LLQ раскидывает трафик по софтверным очередям (в RAM) в соответствии с проведенной заранее классификацией. (3) Пусть в первую приоритетную очередь льется в 2 раза больше трафика, чем мы разрешили. Соответственно, половина отбрасывается, а оставшаяся половина полностью забивает приоритетный FIFO буфер. (4) Пусть остального трафика, попадающего в очереди CBWFQ тоже очень много (больше, чем способен передать интерфейс), т.е. состояние Congestion сохраняется. [Вывод]: пока очередь Priority Queue не освободится, трафик остальных очередей не передается. Если такая ситуация (забитая Priority Queue) продлится хотя бы несколько секунд, то весь трафик CBWFQ будет tail-дропнут, а передаваться будет только тоненький поток трафика из Priority Queue (тоненький, потому что он режется при помощи «internal policer»). Вот чувствую, что где-то изъян в моих рассуждениях, но где?
  • Alexey2112
    Рекомендую посмотреть видеоуркои Джереми Чаора «CBT Nuggets Ccvp 642-642 Qos», на рутрекере есть. Данный вопрос в 5м видео разъясняется.
  • YEVGENIY ARTEMENKO
    «Соответственно, половина отбрасывается, а оставшаяся половина полностью забивает приоритетный FIFO буфер.» LLQ по моему как раз и обеспечивает не FIFO а LIFO.
  • YEVGENIY ARTEMENKO
    «Господа, вы приводите здесь данные из учебников, которые я уже прочитал вдоль и поперед, » — на это отвечу: Знания не имеют линейную структуру, как в книге, структура знаний — что-то между иерархией (деревья) и сетью. Т.е. ты мог прочитать, но мог просто не уловить концепцию, которая ближе к корню/ям…
0
0

Так и есть. Поэтому надо ограничивать скорость priority queue. Полисинг ограничит скорость priority queue, и остальные очереди получат своё обслуживание.

0
0

«Полисинг ограничит скорость priority queue, и остальные очереди получат своё обслуживание.»

Как из первого вытекает второе, если приоритетная очередь будет всегда забита? Ну вот не кончается всплеск приоритетного трафика, и все тут! А в это время мы iperf’ом забиваем интерфейс, чтобы он был в состоянии congestion.

Получается, буфер очереди PQ никак не высвобождается, а значит, остальной трафик останавливается, даже если мы дадим команду priority percent 1.

 

  • Manana
    >>> «Полисинг ограничит скорость priority queue, и остальные очереди получат своё обслуживание.» >>> Как из первого вытекает второе, если приоритетная очередь будет всегда забита? Ну, я просто хотел сказать, что по факту так получается, что полисер ограничивает priority queue. Как это работает? Ну, можно предположить, что коммутатор смотрит, есть ли пакеты в priority queue, и не превышена ли полоса? Если пакеты есть и полоса не превышена — передаёт пакеты; если пакеты есть, но полоса превышена — пакеты ждут в буфере, и т.д. В документе http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfconmg.html#wp1001291 можно посмотреть раздел LLQ Bandwidth Allocation.
0
0
Показано 7 результатов
Ваш ответ

для ответа.