Qos Tail Drop MES3324F

[owenear]

Столкнулся со следующей проблемой на MES3324F.
Клиент подключен двумя гигабитными портами в лацпе.
Растут дропы в очередях даже при незагруженных интерфейсах.

Код: Выделить всё

gigabitethernet1/0/15 is up (connected)
  Interface index is 63
  Hardware is gigabitethernet, MAC address is e0:d9:e3:a3:3e:cf
  Description: client-1
  Interface MTU is 9000
  Full-duplex, 1000Mbps, link type is auto, media type is 1G-Fiber
  Link is up for 3 days, 22 hours, 1 minutes and 9 seconds
  Advertised link modes: 1000baseT/Full 
  Flow control is off, MDIX mode is off
  15 second input rate is 37029 Kbit/s
  15 second output rate is 310160 Kbit/s
      33617434 packets input, 10456812912 bytes received
      10322 broadcasts, 374 multicasts
      0 input errors, 0 FCS, 0 alignment
      0 oversize, 0 internal MAC
      0 pause frames received
      76891332 packets output, 99624098367 bytes sent
      55493 broadcasts, 2808619 multicasts
      0 output errors, 0 collisions
      0 excessive collisions, 0 late collisions
      0 pause frames transmitted
      0 symbol errors, 0 carrier, 0 SQE test error
  Output queues: (queue #: packets passed/packets dropped)
      1: 71448176/9534
      2: 964/0
      3: 2630176/0
      4: 0/0
      5: 0/0
      6: 2287/0
      7: 2820771/0
      8: 0/0


Код: Выделить всё

gigabitethernet1/0/16 is up (connected)
  Interface index is 64
  Hardware is gigabitethernet, MAC address is e0:d9:e3:a3:3e:d0
  Description: client-2
  Interface MTU is 9000
  Full-duplex, 1000Mbps, link type is auto, media type is 1G-Fiber
  Link is up for 3 days, 22 hours, 2 minutes and 39 seconds
  Advertised link modes: 1000baseT/Full 
  Flow control is off, MDIX mode is off
  15 second input rate is 29868 Kbit/s
  15 second output rate is 340834 Kbit/s
      32591721 packets input, 9633286633 bytes received
      132 broadcasts, 4333 multicasts
      0 input errors, 0 FCS, 0 alignment
      0 oversize, 0 internal MAC
      0 pause frames received
      86191398 packets output, 113294360545 bytes sent
      4600 broadcasts, 4849381 multicasts
      0 output errors, 0 collisions
      0 excessive collisions, 0 late collisions
      0 pause frames transmitted
      0 symbol errors, 0 carrier, 0 SQE test error
  Output queues: (queue #: packets passed/packets dropped)
      1: 78525986/13222
      2: 704/0
      3: 2790710/0
      4: 0/0
      5: 0/0
      6: 1391/0
      7: 4906281/0
      8: 0/0


Пробовал увеличивать размеры очередей - ситуация улучшается, однако дропы все-равно присутствуют.
И мне непонятно откуда они вообще есть, если перегрузки нет на интерфейсе и он загружен на треть
Настройки qos следующие:

Код: Выделить всё

qos tail-drop profile 1
 queue 1 limit 400
 queue 2 limit 100
 queue 3 limit 100
 queue 4 limit 100
 queue 5 limit 100
 queue 6 limit 100
 queue 7 limit 100
 queue 8 limit 100
 port-limit 400
exit
!
qos map dscp-queue 34 to 7
!
priority-queue out num-of-queues 2
!
wrr-queue bandwidth 1 1 1 1 1 1
qos statistics interface

....

interface gigabitethernet1/0/15
 description  client-1
 channel-group 4 mode auto
 qos tail-drop profile 1
exit
!
interface gigabitethernet1/0/16
 description  client-2                 
 channel-group 4 mode auto
 qos tail-drop profile 1
exit


Помогите разобраться в чем проблема.

P.S. Version: 4.0.13.3

[Евгений Т]

Здравствуйте.

Для переполнения выходного буфера не обязательно превышение выходной утилизации интерфейса. Достаточно и всплесков трафика в очереди (что характерно для TCP-трафика).
Рекомендую произвести обновление до актуальной версии ПО
https://eltex-co.ru/upload/iblock/344/m ... 015-R2.zip
и расширить очереди до 900->1500->2500 дескрипторов. Дропы по итогу должны уйти.

[owenear]

Спасибо. Попробуем обновиться и увеличить очереди.

[owenear]

Обновились и увеличили размер очередей - это помогло. Дропы пропали.
Но обращу внимание, что при дефолтном профайле дропы присутствуют в очередях даже на тех портах где весь трафик идет после полисера на роутере (к примеру в 50Мбит), то есть никаких всплесков, которые должны вызывать дропы пакетов быть не может. Та же ситуация происходит и в очереди куда попадает один мультикастный поток. Также наблюдаются дропы, хотя трафик не предполагает никаких бурстов. Кроме того очередь strict priority. Эта проблема также решилась увеличением очередей.

Получается, что дефолтные размеры очередей слишком маленькие, по крайней мере для гигабитных интерфейсов.
На 10ках такой проблемы нет, однако они практически не загружены (1,5 Гбит/с в пике)
На всех гигабитных портах дроп профайл пришлось поменять.

По крайней мере это все справедливо в нашем случае.