Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

Как встроенный в LLQ полисер защищает трафик CBWFQ от starvation?

отредактировано июня 2016 Раздел: Policing shaping
Товарищи, у меня разрыв мозга, выручайте.

Помогите ответить на вопрос: Пусть у нас есть роутер с 3 входными 1GbE интерфейсами и одним выходным 1GbE . Если на выходном интерфейсе 1GbE настроено LLQ и приоритетный класс ограничен командой priority percent 10, и мы специально вдуваем в этот интерфейс 2 Gbps трафика приоритетного класса наряду с 1Gbps остального трафика, то трафик приоритетного класса получит 100 Mbps или займет весь интерфейс?

Я думаю, что т.к. приоритетный класс попадает в Tx-Ring напрямую, минуя CBWFQ Scheduler, а роутер не приступает к обработке CBFWQ очередей, пока не освободится софтверная FIFO очередь PQ приоритетного класса (а она не освободится, пока мы вдуваем 2 Gbps трафика), то очередь CBWFQ никогда не наступит!

На каждый цикл прерывания роутер будет обнаруживать, что PQ все еще не пустая и перемещать пакетики из PQ в Tx-Ring, и будет все время занят только этой очередью. И в интерфейс будут попадать только 100 Mbps приоритетного трафика.

Что я упустил?
Тэги темы:

Комментарии

  • отредактировано апреля 2016
    Сам спросил, сам ответил: PQ не отправляется напрямую в TxRing, а проходит перед этим еще через одну ступень - степень смешивания с суммарной очередью CBWFQ ( происходит смешивание двух очередей FIFO перед сериализацией ). Картинка прилагается.


    Таким образом, каждую единицу времени будут смешиваться по N пакетов из LLQ и по N пакетов из суммарной CBWFQ очереди.
  • не знаю чего там в циске, но в джуне один тип трафика(приоритетный) может вызвать "голодание" менее приоритетного трафика.
  • Команда priority в целом определяет полосу определенной ширины (в процентах от ширины линка в случае priority percent), и трафик, укаладывающийся в эту полосу, будет обслужен в очереди LLQ. Трафик, превышающий установленный лимит, будет обслужен в общей очереди FIFO, то есть как best effort если нет перегрузки на линке. Если перегрузка есть, то "лишний" трафик не будет обслуживаться совсем и будет дропнут. Об этом пишут тут и тут
  • Меня просто смущала данная картинка с алгоритмом LLQ:


    Если ее понимать буквально, то можно сделать такой вывод: при условии, что трафик LLQ не превысит рамок, но при этом будет поступать постоянно, то CBWFQ останется с носом (Мы будем ходить в данном алгоритме по кругу).

    Для себя я разрешил этот парадокс так: роутер захватывает из выходной hold-queue за раз определенное количество трафика - такое, которое может уместиться в TxRing. И можно представить себе, что это определенное количество трафика поделено между всеми очередями (и LLQ, и CBWFQ). Т.е. за раз роутер зачерпывает из hold-queue трафик всех классов (согласно их весам), включая приоритетный (приоритетного трафика в одном черпке не может быть больше установленного лимита!). Отличие LLQ в том, что ее трафик вставляется в tx-ring каждое прерывание (т.к. сразу попадает в начало выходной hold-queue очереди), а трафик очередей CNWFQ перед тем, как попасть под раздачу, сначала должен быть выбран в процессе Round-Robin между очередями CBWFQ.

    Именно поэтому трафик VoIP нельзя использовать с чистым CBWFQ. Если, допустим, на роутер прилетит VoIP пакет и попадет в очередь своего VoIP класса, то может статься, что в данный момент времени этот пакет опоздал на перенос в TxRing, и роутер зачерпывает из всех остальных очередей по кругу. Очередь до VoIP пакета, конечно, дойдет, но может быть слишком поздно - на принимающем конце он уже будет считаться пропавшим без вести.
  • В той книге, что вы читаете на 254 странице написано следующее....However, Cisco must also protect
    their intellectual assets. So, for some of the newer queuing tools, Cisco has not yet published
    every detail about how the scheduling algorithm works.

    Соответственно пытаетесь додумать работу шедулера. На ум действительно приходит механизм обслуживания типа SRR с bandwidth percent (вместо byte count из CQ). А так ли это?

Войдите или Зарегистрируйтесь чтобы комментировать.