Перейти к содержимому
Калькуляторы

FreeBSD, нарушается последовательность пакетов

Привет!

 

Есть проблема с 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, запущенном на входе и выходе.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

означает

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

означает

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем GrandPr1de

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с 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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Я же писал...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я же писал...

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я же писал...

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

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

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

 

Пайпы:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

что в sysctl.conf?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Привет

 

Может кто-нибудь объяснить как между собой коррелируют нити 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Может.

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

В случае с 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) гарантированно обрабатывались в одном потоке на одном ядре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

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

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.