[Darwinggl]

Привет!

 

Есть проблема с FreeBSD шлюзом, на котором терминируются L3 абонентские сесии.

Версия 9.2-STABLE, сетевая 82576. Абоненты шейпятся dummynet, vlan-интерфейсов порядка тысячи.

 

net.isr.maxthreads=16
net.isr.defaultqlimit=4096
net.link.ifqmaxlen=10240

hw.igb.lro=0
hw.igb.low_latency=2000
hw.igb.ave_latency=4000
hw.igb.bulk_latency=6000
hw.igb.rx_process_limit=400
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.max_interrupt_rate=32000

kern.ipc.nmbclusters=524288
kern.ipc.nmbjumbop=262144
kern.ipc.maxsockbuf=83886080
hw.intr_storm_threshold=20000
ng_ipfw_load="YES"
alias_ftp_load="YES"



if_igb_load="YES"
geom_mirror_load=YES
ipfw_load="YES"

kern.hz=4000

 

Суть проблемы - меняется порядок следования пакетов. Замечено на UDP-трафике. Если абонента снять с шейпера, проблема не решается.

LACP или иных способов агрегации каналов не используем. Ситуацию наблюдаем с помощью tcpdump, запущенном на входе и выходе.

Помогите найти пути решения.

[alibek]

Так для UDP разве бывает порядок следования пакетов?

Для него это нормально, UDP не гарантирует ни доставку, ни последовательность.

[Darwinggl]

Так для UDP разве бывает порядок следования пакетов?

Для него это нормально, UDP не гарантирует ни доставку, ни последовательность.

Это не означает, что можно невозбранно терять и менять порядок следования пакетов.

[GrandPr1de]

Это не означает, что можно невозбранно терять и менять порядок следования пакетов.

означает

[DVM-Avgoor]

А если убрать _весь_ тюнинг?

[vlad11]

Наоборот, еще убрать rxcsum, txcsum, TSO4 у сетевых и перегрузить машину.

[Darwinggl]

ifconfig_igb1="inet XX.XX.XX.XX netmask 255.255.255.128 up -rxcsum -txcsum -promisc -lro"
ifconfig_igb2="up -rxcsum -txcsum -lro -promisc "

[TheUser]

Это не означает, что можно невозбранно терять и менять порядок следования пакетов.

означает

С точки зрения протокола UDP и приложения, его использующего, означает. С точки зрения сетевого оборудования - нет.

[GrandPr1de]

С точки зрения сетевого оборудования - нет.

С чего это вдруг? У вас сетевое оборудование данные генерирует или всё таки приложения?

Если приложение - то оно шлем в любом удобном ему порядке, и именно в таком порядке пойдут по сети, и именно такой порядок будет верным.

Ситуацию наблюдаем с помощью tcpdump, запущенном на входе и выходе.

дамп покажите хоть

[TheUser]

Если приложение - то оно шлем в любом удобном ему порядке, и именно в таком порядке пойдут по сети, и именно такой порядок будет верным.

Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с freebsd, нет?

[GrandPr1de]

Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с freebsd, нет?

надо видеть дамп...

интересно, там netisr включен или выключен?...

Edited February 11, 2015 by GrandPr1de

[Darwinggl]

Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с freebsd, нет?

надо видеть дамп...

интересно, там netisr включен или выключен?...

что касается netisr

# sysctl net.isr
net.isr.numthreads: 16
net.isr.maxprot: 16
net.isr.defaultqlimit: 4096
net.isr.maxqlimit: 10240
net.isr.bindthreads: 0
net.isr.maxthreads: 16
net.isr.direct: 0
net.isr.direct_force: 0
net.isr.dispatch: direct

 

По поводу дампа, тут все просто, был написан скрипт, который воспроизводит данную проблему. Скрипт генерирует UDP пакеты разной длины и шлет их через FreeBSD'шный шлюз в заданной последовательности:

На входе (igb0) картина такая:

IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615
IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492
IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615
IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492

 

А на выходе (vlan интерфейс):

IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615
IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492
IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492
IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615

 

Как видно, порядок пакетов при прохождении через шлюз изменился.

[GrandPr1de]

а при выключенном шейпере в данном направлении?

как пайпы конфигурите?

[Darwinggl]

а при выключенном шейпере в данном направлении?

как пайпы конфигурите?

 

Я же писал...

Если абонента снять с шейпера, проблема не решается.

[GrandPr1de]

Я же писал...

да точно, и всё таки, как пайпы конфигурите?

Кроме дамминета в фаерволе ещё что-нибудь есть?

[Darwinggl]

Я же писал...

да точно, и всё таки, как пайпы конфигурите?

Кроме дамминета в фаерволе ещё что-нибудь есть?

Кроме дамминета в фаерволе больше ничего нет.

 

Пайпы:

pipe tablearg ip from any to table(16) out via vlan*
pipe tablearg ip from table(17) to any in via vlan*

 

В таблице абонентские сети привязываются к пайпам.

Пайпы

12.000 Mbit/s    0 ms burst 0
q131136  50 sl. 0 flows (1 buckets) sched 65600 weight 0 lmax 0 pri 0 droptail
sched 65600 type FIFO flags 0x1 32768 buckets 14 active
   mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000

12.000 Mbit/s    0 ms burst 0
q131104  50 sl. 0 flows (1 buckets) sched 65568 weight 0 lmax 0 pri 0 droptail
sched 65568 type FIFO flags 0x1 32768 buckets 4 active
   mask:  0x00 0xffffffff/0x0000 -> 0x00000000/0x0000

[GrandPr1de]

т.е. два правила в фаерволе? при этом вы подгружаете ng_ipfw.

hw.igb.low_latency=2000
hw.igb.ave_latency=4000
hw.igb.bulk_latency=6000

это вам точно нужно?

 

что в sysctl.conf?

[Darwinggl]

Привет

 

Может кто-нибудь объяснить как между собой коррелируют нити netisr и прерывания igb очередей? Чем грозит отключение потоков в netisr?

Отключить весь тюнинг не представляется возможным, т.к. через машину идет коммерческий трафик и какие-либо эксперименты не допустимы.

 

Меня смущает еще вывод netstat -Q:

#netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         8            8
Default queue limit               4096        10240
Dispatch policy                 direct          n/a
Threads bound to CPUs         disabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1  10240   flow  default   ---
igmp       2   4096 source  default   ---
rtsock     3   1024 source  default   ---
arp        7   4096 source  default   ---
ether      9   4096 source   direct   ---

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
  0   0   ip         0     1 27031259        0        0        2 27031261
  0   0   igmp       0     0        0        0        0        0        0
  0   0   rtsock     0     8        0        0        0    40144    40144
  0   0   arp        0     0 17473797        0        0        0 17473797
  0   0   ether      0     0 3424331738        0        0        0 3424331738
  1   1   ip         0     0 868045497        0        0        0 868045497
  1   1   igmp       0     0        0        0        0        0        0
  1   1   rtsock     0     0        0        0        0        0        0
  1   1   arp        0     0        0        0        0        0        0
  1   1   ether      0     0 2833888542        0        0        0 2833888542
  2   2   ip         0     1 705085703        0        0        2 705085705
  2   2   igmp       0     0        0        0        0        0        0
  2   2   rtsock     0     0        0        0        0        0        0
  2   2   arp        0     0        0        0        0        0        0
  2   2   ether      0     0 4245441054        0        0        0 4245441054
  3   3   ip         0     1 841181863        0        0        2 841181865
  3   3   igmp       0     0        0        0        0        0        0
  3   3   rtsock     0     0        0        0        0        0        0
  3   3   arp        0     0        0        0        0        0        0
  3   3   ether      0     0 2898602573        0        0        0 2898602573
  4   4   ip         0     0 1330342052        0        0        0 1330342052
  4   4   igmp       0     0        0        0        0        0        0
  4   4   rtsock     0     0        0        0        0        0        0
  4   4   arp        0     0        0        0        0        0        0
  4   4   ether      0     0 2726208890        0        0        0 2726208890
  5   5   ip         0     0 1108369835        0        0        0 1108369835
  5   5   igmp       0     0        0        0        0        0        0
  5   5   rtsock     0     0        0        0        0        0        0
  5   5   arp        0     0        0        0        0        0        0
  5   5   ether      0     0 3434355155        0        0        0 3434355155
  6   6   ip         0    14 1302603711        0        0 33066832 1335667822
  6   6   igmp       0     0        0        0        0        0        0
  6   6   rtsock     0     0        0        0        0        0        0
  6   6   arp        0     0        0        0        0        0        0
  6   6   ether      0     0 2909362322        0        0        0 2909362322
  7   7   ip         0     0 1262496778        0        0        0 1262496778
  7   7   igmp       0     0        0        0        0        0        0
  7   7   rtsock     0     0        0        0        0        0        0
  7   7   arp        0     0        0        0        0        0        0
  7   7   ether      0     0 2980323173        0        0        0 2980323173

Почему-то счетчик Queued растет только на 6 WSID для пакетов типа IP.

[DVM-Avgoor]

т.к. через машину идет коммерческий трафик

 

Вот тут и проблема, а не в очередях и пакетах.

[vlad11]

т.к. через машину идет коммерческий трафик

 

Вот тут и проблема, а не в очередях и пакетах.

 

Осталось выяснить, что на конечных узлах стоит. Не Микротик ли, страдающий целым букетом проблем?

[Ivan_83]

Может кто-нибудь объяснить как между собой коррелируют нити netisr и прерывания igb очередей? Чем грозит отключение потоков в netisr? Отключить весь тюнинг не представляется возможным, т.к. через машину идет коммерческий трафик и какие-либо эксперименты не допустимы.

Может.

Генерируется прерывание.

Если включён direct то isr не используется и пакет обрабатывается в контексте потока прерывания. Под обработкой поднимается что при fastforward=1 он уходит туда, и если он транзитный и его фаеволы не дропают то пакет улетает в сеть. Если fastfroward=0 то там чуть больше проверок.

Когда включён dispatch то isr используется, и во время обработки прервания - обработчик прерывания просто ставит пакет в очередь, а isr поток из этой очереди его забирает. В этом случае у нас больше переключений контекста, дополнительный оверхэд на работу с очередью, чуть больше время обработки, зато мы гарантированно не теряем пакеты при резких всплесках и можем гарантированно их обрабатывать на всех ядрах. В случае с direct для раскидывания по ядрам нужно чтобы сетевуха это умела.

 

Есть ещё потоки нетграфа, они практически как isr, но для их использования хук ноды должен указвать флаг HK_QUEUE (если правильно помню), тогда пакет встанет в очередь и будет обработан уже потоками нетграфа.

[Darwinggl]

Спасибо за развернутый ответ.

В случае с direct для раскидывания по ядрам нужно чтобы сетевуха это умела.

Является ли достаточным показателем умения раскидывать прерывания то, что top -SPH показывает по 8 прерываний на каждую igb сетевую карту?

 

12 root -92 - 0K 1024K CPU5 5 424:20 9.23% intr{irq261: igb0:que}

12 root -92 - 0K 1024K WAIT 0 487:48 8.54% intr{irq256: igb0:que}

12 root -92 - 0K 1024K WAIT 6 361:38 8.50% intr{irq262: igb0:que}

12 root -92 - 0K 1024K CPU7 7 323:43 7.81% intr{irq263: igb0:que}

12 root -92 - 0K 1024K WAIT 3 268:24 7.47% intr{irq277: igb2:que}

12 root -92 - 0K 1024K CPU2 2 327:17 7.28% intr{irq258: igb0:que}

12 root -92 - 0K 1024K WAIT 1 312:36 7.28% intr{irq257: igb0:que}

12 root -92 - 0K 1024K WAIT 2 371:11 7.13% intr{irq276: igb2:que}

12 root -92 - 0K 1024K WAIT 3 315:40 7.13% intr{irq259: igb0:que}

12 root -92 - 0K 1024K WAIT 4 351:27 6.93% intr{irq260: igb0:que}

12 root -92 - 0K 1024K WAIT 4 243:52 5.76% intr{irq278: igb2:que}

12 root -92 - 0K 1024K WAIT 5 302:06 5.47% intr{irq279: igb2:que}

12 root -92 - 0K 1024K WAIT 0 265:03 5.03% intr{irq274: igb2:que}

12 root -92 - 0K 1024K WAIT 1 260:51 4.88% intr{irq275: igb2:que}

12 root -92 - 0K 1024K WAIT 7 269:29 4.59% intr{irq281: igb2:que}

12 root -92 - 0K 1024K WAIT 6 257:30 4.30% intr{irq280: igb2:que}

 

Каким образом при отключенном isr можно отслеживать потери пакетов (в целом на железке)?

 

Кстати, вот тут

какой-то японец писал про распределение пакетов по обработчикам isr в зависимости от значения хеш-функции от IP, номеров портов и т.д. проходящих потоков. Такое решение помогло бы в нашей ситуации - тогда пакеты в рамках одной сессии (или пары src-dst ip) гарантированно обрабатывались в одном потоке на одном ядре.

[Ivan_83]

Является ли достаточным показателем умения раскидывать прерывания то, что top -SPH показывает по 8 прерываний на каждую igb сетевую карту?

Эта тема неоднократно поднималась: сетевухи используют RSS или как его там алгоритм, в случае pppoe оно всё в одно прерывание будет гнать.

 

Каким образом при отключенном isr можно отслеживать потери пакетов (в целом на железке)?

Так же как и при включённом.

На железе - обычно в sysctl hw.ИМЯ_СЕТЕВУХИ, если в драйвере реализован вывод счётчиков таким образом.

Остальное через netstat /systat силами системы.

 

Кстати, вот тут

какой-то японец писал про распределение пакетов по обработчикам isr в зависимости от значения хеш-функции от IP, номеров портов и т.д. проходящих потоков. Такое решение помогло бы в нашей ситуации - тогда пакеты в рамках одной сессии (или пары src-dst ip) гарантированно обрабатывались в одном потоке на одном ядре.

Темой особо не интересовался.

Ну не он один. Там периодически какие то правки на эту тему то появляются то исчезают, у меня ощущение что каждый тянет одеяло на себя: свой конкретный оптимальный случай хочет в ядро запихать.