[vladd]

Приветствую всех! Имеется сервер с сетевой картой Intel X520-DA2, подключенный по SFP+ к свитчу DGS-3420-26SC. К этому же свитчу подключены несколько уходящих в разные места гигабитных линков, некоторые из которых объединены в LACP-транки. Все эти линки сведены на сервер в разных вланах. Задача сервера - обычная маршрутизация (бордер), и ничего более, с чем он прекрасно справляется. Общая нагрузка (входящий+исходящий) на него не превышает 5Г, прерывания по ядрам раскинуты, их загрузка - не более 20-25%.

 

Возникает странная проблема, биться над которой приходится уже второй месяц. Если на 10Г линке отключен flow-control, то на свитче начинают возникать TX-дропы на 1-гигабитных портах (!), вызванные переполнением буфера передачи, и соответственно начинаются потери пакетов - причем вне зависимости от времени суток и загрузки сети. При этом загрузка каждого порта - не более 600-700 мбит. Как при этом могут возникуть дропы из-за переполнения буфера на этом порту, ума не приложу.

 

Если же на 10-гигабитном порту включить flow-control, то дропы пропадают, но в ЧНН задержки от сервера до любого другого узла вырастают до 10-20ms вместо привычных 0.1-0.4. И то, и другое никуда не годится. Загрузки каждого из 1-гигабитных линков опять же не превышают 60-70% - это на сто процентов проверено. Задержки вырастают даже до тех узлов, которые подключены через гигабитный линк с загрузкой не более 10%.

 

Подскажите, в связи с чем это может быть? Вроде ничего из отдельно взятых узлов этой схемы не перегружено и в помине, но в целом какая-то неведомая хрень.

[terrible]

а если попробовать включить flow control и на свиче (на линках) и на сетевушке?

Какой либо тюнинг сетевушки делали?

[vladd]

Конечно же включал и выключал flow control на обоих концах линка - и на свитче, и на сетевушке. Из тюнинга - только увеличил размер буфера (ethtool -G) до максимального. А также разные значения InterruptThrottleRate. Кроме этого там тюнить вроде нечего.

 

Больше всего интересует вариант с отключенным flow control. Почему при загрузке на гиговых портах менее 70% на них возникают дропы при передаче трафика с 10-гигового? Пока единственный приходящий вариант в голову вариант - это микроберсты на 10-гиговом линке. Но неужели у длинка такая микроскопическая очередь передачи на гиговых портах?

 

Кстати, брали еще на тест свитч Ruby (4x10g+24x1g) - такие же дропы, но там не включается flow сontrol на десятке, пришлось его отдать.

Edited December 10, 2012 by vladd

[doubtpoint]

Больше всего интересует вариант с отключенным flow control.

Почему при загрузке на гиговых портах менее 70% на них возникают дропы при передаче трафика с 10-гигового? Пока единственный приходящий вариант в голову вариант - это микроберсты на 10-гиговом линке. Но неужели у длинка такая микроскопическая очередь передачи на гиговых портах?

Так флоуконтрол надо включать на 1г портах(с двух сторон), а на 10Г наоборот выключать (медленный 1г порт тормозит 10Г и приводит к задержкам)

Кстати, у длинка буфера на порт действительно микроскопические. Точно размер буфера неизвестен, но из описания Буфер пакетов: 2MB(это у них Мбит на все устройство).С учетом, жесткого распределения по портам(возможно группам портов) и использования на любой пакет 512-2048 байт, это может быть 2-4 пакета на 1Г порт.

Edited December 10, 2012 by doubtpoint

[Alex/AT]

Виноват бурстовый характер трафика - на 10Г для 1Гбит порта единомоментно приходит больше, чем 1Г порт может прожевать, даже с учетом буфера.

Если включить флоуконтрол на 10Г - 10Г порт будет вынужден ждать, пока 1Г прожует бурст, вызывая задержки и ингресс дропы.

 

Попробуйте на сервере на 10G линке раскидать VLAN'ы по исходящим round-robin очередям так, чтобы была одна очередь на каждый исходящий гиговый порт свитча.

Ничего шейпить/полисить не надо - именно раскидайте чередованием. Размер отправки для чередования подбирать согласно буферам свитча, либо вообще чередовать по 1 пакету.

В терминологии Linux это будет DRR (Deficit Round Robin) qdisc, параметр размера отправки - квант (quantum), по умолчанию равен MTU, очереди - субклассы.

[s.lobanov]

vladd

Не так давно тоже обратил внимание на TX-дропы на гиговых линках при 10G-аплинке. Причина точно описана в посте Alex/AT.

 

Но проблема в том, что совет

Попробуйте на сервере на 10G линке раскидать VLAN'ы по исходящим round-robin очередям так, чтобы была одна очередь на каждый исходящий гиговый порт свитча.

вам не поможет, поскольку у большинства современных свитчей единый буфер кадров(в пределах устройства/линейной карты(в модульных коммутаторах)/свитч-фабрики), а не на каждом порту. всё чем это поможет - просто TX-дропы будут более равномерно распределяться по 1G линкам.

 

Вообще, первопричина этого явления в том, что на bras-е надо делать peak rate надо делать поменьше для многомегабитных тарифов.

[doubtpoint]

А что под "раскидать 10Г" есть из 1-4 порта sfp+ и SFP 24-48 с большим буфером? Функционал особо не нужен (4К VLAN). Неглючный. При цене не дороже длинка в 2 раза?

[vladd]

Тоже интересно, есть ли в природе такое? Смотрю в сторону Juniper EX3300-24T, но размер буфера нигде у него не указан в спеках.

[passer]

+1

 

На столе лежит Juniper EX3300-48T, взятый на тест. Но в доке размер буфера пакетов найти не удалось. Кстати, для экстримов - тоже. А у делинка размер буфера просто смешной.

 

 

[s.lobanov]

passer

В принципе, размер буфера можно вычислить по дропам. Например выплёвываете 4Мб трафика из 10G порта, они пролетают в 1G порт без TX-дропов и так по немножку наращиваете, до тех пор пока не начнуться дропы. Получите верхнюю оценку. Чтобы получить реальный размер буфера нужно ещё учесть что на временном расстоянии между началом отправки и началом дропов сколько-то фреймов вылетело из буфера, но делать это не обязательно, вам же сравнить надо, у кого больше, а не вычислить размер буфера.

[tunny]

Summit x450

[passer]

А где у Summit указан размер буффера?

[Alex/AT]

вам не поможет, поскольку у большинства современных свитчей единый буфер кадров(в пределах устройства/линейной карты(в модульных коммутаторах)/свитч-фабрики), а не на каждом порту. всё чем это поможет - просто TX-дропы будут более равномерно распределяться по 1G линкам.

3420 egress-buffered, может и помочь... На 3627 не помогло бы точно - там дропы будут на ingress 10G :)

[vladd]

Как показало тестирование, на Juniper EX3300-48T - аналогичная проблема. Как только трафик превысил 300 мбит, дропы стали стремительно нарастать. Неужели серьезный вроде вендор опустился до уровня мыльниц?

 

root@juniper> show interfaces ge-0/0/1 detail

Physical interface: ge-0/0/1, Enabled, Physical link is Up

Interface index: 134, SNMP ifIndex: 506, Generation: 137

Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled,

Auto-negotiation: Enabled, Remote fault: Online

Device flags : Present Running

Interface flags: SNMP-Traps Internal: 0x4000

Link flags : None

CoS queues : 8 supported, 8 maximum usable queues

Hold-times : Up 0 ms, Down 0 ms

Current address: 78:fe:3d:ea:fa:43, Hardware address: 78:fe:3d:ea:fa:44

Last flapped : 2012-12-22 11:08:27 MSK (07:43:29 ago)

Statistics last cleared: Never

Traffic statistics:

Input bytes : 661571173013 318779200 bps

Output bytes : 1092126634721 445624704 bps

Input packets: 1043178919 61038 pps

Output packets: 1136142197 61284 pps

IPv6 transit statistics:

Input bytes : 0

Output bytes : 0

Input packets: 0

Output packets: 0

Egress queues: 8 supported, 4 in use

Queue counters: Queued packets Transmitted packets Dropped packets

0 best-effort 0 1136132443 101473

1 assured-forw 0 0 0

5 expedited-fo 0 0 0

7 network-cont 0 28761 0

Edited December 22, 2012 by vladd

[s.lobanov]

vladd

Покажите

show interfaces queue XXX egress 
show class-of-service scheduler-map
show class-of-service forwarding-table scheduler-map

[eill]

vladd, а чем вы смотрите статистику дропов на исходящих интерфейсах на 3420-26sc?

 

sh ports 1 det?

 

просто сеть построена на аналогичных агрегатах, а проблема заинтересовала.

[s.lobanov]

просто сеть построена на аналогичных агрегатах, а проблема заинтересовала.

 

В самом деле, не такая уж это и проблема. Если вы предоставляете только интернет, то вообще пофиг на эти дропы. Если же есть мультикаст/своя телефония, то засунуть их в pq- или wrr-очередь с большим коэффициентом(смотря что поддерживает оборудование) и не будут они дропаться

[eill]

s.lobanov мультикаст есть, приоритеты уже настроены, бегает все нормально, но тем не менее. Да и вдруг здесь найдется нормальное решение данной проблемы?

[vladd]

vladd, а чем вы смотрите статистику дропов на исходящих интерфейсах на 3420-26sc?

 

show error ports 25

 

В самом деле, не такая уж это и проблема. Если вы предоставляете только интернет, то вообще пофиг на эти дропы.

 

В том то и дело, что не пофиг - при задержках 40-50мс до центра, эти дропы не позволяют получить скорость больше 1-2 мб/с в один tcp-поток. При тарифах 10-80 мбит. А люди меряют всякими спидтестами, у них показывает несоответствие, и сразу же начинается вонь. Особенно когда у конкурентов со спидтестом все в порядке - в этом случае бесполезно объяснять, что мерять надо торрентом или что скорость больше 10 мбит в один поток труднодостижима. Самое обидное, что больше всего дропов в ЧНН, скорости падают ощутимо, а около 40% внешних каналов не загружено - напрямую с бордера качается 100 мбит в один поток.

 

Вот данные по интерфейсу ge-0/0/0, на самом деле их шесть, и на каждом аналогичные дропы.

 

root@juniper> show interfaces queue ge-0/0/0 egress                   
Physical interface: ge-0/0/0, Enabled, Physical link is Up
 Interface index: 133, SNMP ifIndex: 504
Forwarding classes: 16 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
 Queued:
 Transmitted:
   Packets              :            4733500185
   Bytes                :         4429766939921
   Tail-dropped packets :               1841912
Queue: 1, Forwarding classes: assured-forwarding
 Queued:
 Transmitted:
   Packets              :                     0
   Bytes                :                     0
   Tail-dropped packets :                     0
Queue: 5, Forwarding classes: expedited-forwarding
 Queued:
 Transmitted:
   Packets              :                     0
   Bytes                :                     0
   Tail-dropped packets :                     0
Queue: 7, Forwarding classes: network-control
 Queued:
 Transmitted:
   Packets              :                163959
   Bytes                :              18967927
   Tail-dropped packets :                     0

 

root@juniper> show class-of-service scheduler-map                     
Scheduler map: <default>, Index: 2

 Scheduler: <default-be>, Forwarding class: best-effort, Index: 21
   Transmit rate: 95 percent, Rate Limit: none, Buffer size: 95 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-nc>, Forwarding class: network-control, Index: 23
   Transmit rate: 5 percent, Rate Limit: none, Buffer size: 5 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

Scheduler map: <default-chassis>, Index: 4

 Scheduler: <default-ch-scheduler>, Forwarding class: best-effort, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-ch-scheduler>, Forwarding class: expedited-forwarding, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-ch-scheduler>, Forwarding class: assured-forwarding, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-ch-scheduler>, Forwarding class: network-control, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      


Scheduler map: <default-chassis-derived>, Index: 5

 Scheduler: <default-ch-scheduler>, Forwarding class: best-effort, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-ch-scheduler>, Forwarding class: expedited-forwarding, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-ch-scheduler>, Forwarding class: assured-forwarding, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 Scheduler: <default-ch-scheduler>, Forwarding class: network-control, Index: 25
   Transmit rate: 25 percent, Rate Limit: none, Buffer size: 25 percent, Buffer Limit: none, Priority: low
   Excess Priority: low
   Drop profiles:
     Loss priority   Protocol    Index    Name
     High            non-TCP         1    <default-drop-profile>      
     High            TCP             1    <default-drop-profile>      

 

 

root@juniper> show class-of-service forwarding-table scheduler-map    
...

Interface: ge-0/0/0, (Index: 133, Map index: 2, Map type: FINAL, Num of queues: 2):
Index: 0
 Entry 0 (Scheduler index: 0, Forwarding class #: 0, Queue #: 0):
   Tx rate: 0 Kb (95%), Buffer size: 95 percent
Priority low
Excess rate: proportion 0 Excess priority: low
   PLP high: 1, PLP low: 1
 Entry 1 (Scheduler index: 0, Forwarding class #: 3, Queue #: 7):
   Tx rate: 0 Kb (5%), Buffer size: 5 percent
Priority low
Excess rate: proportion 0 Excess priority: low
   PLP high: 1, PLP low: 1

Edited December 23, 2012 by vladd

[martini]

бегал както мультикаст около 1.5 гигабита на длинк свичах.. и что я туда только не ставил.. и 3612 и 3420 и зюхеля разные... одна беда - дропы на интерфейсах.. Но решил попробовать Juniper 3200 и о чудо - дропы пропали )) Но так как джуник нужен был для других задач, решено было заказать сиську какуюто.. и заказал 3550 на попробовать.. приехала, легла на свое место и тихонько жужжыт.. и ни одного дропа нету )

Вобщем Длинк и иже с ними на ответственных магистралях и мультикасте - зло, а на всех остальных задачах - отлично себя ведут.

[s.lobanov]

В самом деле, не такая уж это и проблема. Если вы предоставляете только интернет, то вообще пофиг на эти дропы.

 

В том то и дело, что не пофиг - при задержках 40-50мс до центра, эти дропы не позволяют получить скорость больше 1-2 мб/с в один tcp-поток. При тарифах 10-80 мбит.

 

Откуда у вас такие зверские задержки? Абоненты во Владивостоке, а брасы в Москве? Поставить свой спидтест рядом с абонентами получается не вариант?

 

Покажите настройки высокоскоростных тарифных планов(параметры шейпера/полисера на egress) на вашем брасе. Если на egress полисер, то нужно понимать, что пока в корзине маркеров что-то есть, трафик будет пропускаться на скорости интерфейса. Проще говоря, сглаживающий буфер так или иначе должен где-то быть и возможно, в вашем случае, есть смысл заставить bras работать иначе(чтобы исходящий из него трафик был уже сглаженным и не вызывал out-дропы)

 

бегал както мультикаст около 1.5 гигабита на длинк свичах.. и что я туда только не ставил.. и 3612 и 3420 и зюхеля разные... одна беда - дропы на интерфейсах..

 

Странно это... Я тестировал QoS на различном китайском барахле класса D-Link(но не dlink), работало без проблем, очереди выстраивались, нужный(окрашенный) трафик не дропался.

[vladd]

В том то и дело, что не пофиг - при задержках 40-50мс до центра, эти дропы не позволяют получить скорость больше 1-2 мб/с в один tcp-поток. При тарифах 10-80 мбит.

Откуда у вас такие зверские задержки? Абоненты во Владивостоке, а брасы в Москве? Поставить свой спидтест рядом с абонентами получается не вариант?

 

Свой спидтест стоит, но они тоже умные, и меряют только Москву-Питер. И до туда как раз такие задержки в нашем регионе.

 

Покажите настройки высокоскоростных тарифных планов(параметры шейпера/полисера на egress) на вашем брасе.

 

Дропы происходят _до_ резалки скоростей/браса. В качестве резалок используется dummynet. Сейчас в качестве эксперимента хотим поставить в него 10Г-сетевуху, чтобы вообще выкинуть промежуточный свитч и LACP.

Edited December 23, 2012 by vladd

[s.lobanov]

Дропы происходят _до_ резалки скоростей/браса. В качестве резалок используется dummynet. Сейчас в качестве эксперимента хотим поставить в него 10Г-сетевуху, чтобы вообще выкинуть промежуточный свитч и LACP.

 

Если вы раскидываете 10G в 6G LACP, то тут даже прикинуть нужный размер буфера практически невозможно, т.к. у вас дропы происходят по причине флуктуаций балансировки между физ. портами. Нормально это у вас не будет работать. Включайте BRAS по 10G-линку.

[vladd]

Если вы раскидываете 10G в 6G LACP, то тут даже прикинуть нужный размер буфера практически невозможно, т.к. у вас дропы происходят по причине флуктуаций балансировки между физ. портами. Нормально это у вас не будет работать. Включайте BRAS по 10G-линку.

Это думаю решит проблему, но что делать с теми, кто идет в обход браса? Есть несколько других потребителей - организации, субпровайдеры, они включены по отдельным 1Г-линкам, не в LACP. И на них также дропы при загрузке от 200 мбит.

[digsi]

воткните их через промежуточный коммутатор с большим буфером на порт, помогает сгладить флуктуации