Цикл 1, Лабораторная 4, Вопрос 3.

Отвечен
1
0

Не смог понять, как конкретно ограничить очередь по пакетам: в class-default в policy-map или на интерфейсе через hold-queue? Ведь в условии отсутствия классификации трафика, результат будет идентичный.

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

Ограничивайте в policy-map, чтобы результат был виден в конфиге.

  • Sever Sudakov
    В таком случае, название темы сбивает с толку…
1
2

Как я понял,

Tx-Ring — настраивает выходной аппаратный буфер.

Hold-queue out — настраивает суммарный размер программного буфера всех программных очередей (в RAM).

Queue-limit — настраивает длину программного буфера для данной конкретной программной очереди (внутри данного класса).

Сумма всех Queue-limit не должна превышать значения Hold-queue out, иначе будут непредсказуемые дропы.

 

Про TX-Ring: http://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/ip-to-atm-class-of-service/6142-txringlimit-6142.html#topic6

Значение Tx-Ring напрямую влияет на эффективность и скорость  сериализации: чем оно больше, тем большими пачками может CPU за одно прерывание закидывать в выходной аппаратный буфер наши пакетики , а значит, эффективность сериализации растет, но скорость сериализации падает. Это хорошо для высокоскоростных интерфейсов, т.к. позволяет эффективно обрабатывать бурсты, но для низкоскоростных  может привести к большим задержкам и джиттеру VoIP-трафика (низкоскоростному интерфейсу нужно гораздо больше времени, чтобы поместить выходной буфер в физическую среду).

С другой стороны, слишком маленькое значение Tx-Ring ведет к увеличению нагрузки на софтовую очередь Hold-queue (т.н. back pressure из хардварной в софтовую очередь) и может ограничить  пропускную способность высокоскоростного интерфейса. (Вот последнее утверждение я не до конца понял. Циска объясняет это так: Low Value of Tx-Ring can introduce reduced throughput if tuned to such a low value that no packets are ready to be sent once the wire is free.   Типа приходится  слишком часто перекладывать пакеты из софтового буфера в аппаратный и CPU иногда не успевает это сделать?)

 

Влияние Txring на задержку и джиттер:

http://wiki.nil.com/Queuing_Principles_in_Cisco_IOS/Tx-ring-limit

0
0

Методом подключения практического опыта, который показывает, что

  • настройки длины очереди в policy-map’e на трафик влияют (количество output drop’ов снижается),
  • а hold-queue out в настройках интерфейса — нет,

решил что настраивать надо в policy-map ))

Но что тогда есть очередь hold-queue out, зачем она сделана и на что влияет, для меня пока осталось не ясным.

  • akostrikov
    Судя по описанию — это очередь для пакетов, которые нужно «тяжело» процессить и которые не уложились в обработку по interrupt(прерыванию). При этом обработка не через прерывание — это нормально (Some packets are always processed). http://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/6343-queue-drops.html When a packet enters the router, the router attempts to forward it at interrupt level. If a match cannot be found in an appropriate cache table, the packet is queued in the input queue of the incoming interface to be processed. Some packets are always processed, but with the appropriate configuration and in stable networks, the rate of processed packets must never congest the input queue. If the input queue is full, the packet is dropped. Here is a sample output: router#show interfaces ethernet 0/0 … Input queue: 30/75/187/0 (size/max/drops/flushes); Total output drops: 0 Output queue :0/40 (size/max)… In this sample output, there is no way to see exactly which packets have been dropped. In order to troubleshoot input queue drops, you must find out which packets fill the input queue. In this example, 30 packets are in the input queue of interface ethernet0/0 when the show interfaces ethernet 0/0 command is issued. The queue depth is 75 packets and there have been 187 drops since the interface counters were last cleared. The system counts input queue drops if the number of packet buffers allocated to the interface is exhausted or reaches its maximum threshold. You can increase the maximum queue value with the hold-queue command for each interface (the queue length value can be between 0 and 4096. The default value is 75). P.S. Не знаю как тут правильно форматировать текст.
  • Larchen
    Читал этот документ. В части input Hold-q — всё ясно, да, пусть полежат в очереди для пакетов которые нужно process-switch’ить, а мы пока не успеваем. Но какой это имеет смысл в направлении Output? Пакет уже свиченулся (не важно как), ждёт возможности вставиться в TX-Ring. Причем ждёт в очереди соответствующего размера для соответствующего класса, определённого в policy-map’e, установленного в направлении out. Какой тогда смысл в настройке на интерфейсе hold-queue out? Эта настройка влияет на то, что показывает команда show interface , но по факту на объёмы сброса при перегрузках не влияет. Вот и не понятно, что это за исходящая очередь.
  • akostrikov
    Именно по out: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/quality-of-service-qos/sol_ov_c22-708224.html Note: The aggregate queue-limit of the configured CBWFQ classes must be equal or smaller than the configured configured on the assigned interface. If the hold-queue limit is smaller than the configured aggregate queue-limits of the classes, the system will drop packets on the inbound interface appearing as and in the interface statistic.
  • Larchen
    Спасибо. То, что нужно.
Показано 3 результата
Ваш ответ

для ответа.