Jump to content
Калькуляторы

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, запущенном на входе и выходе.

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

означает

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
ifconfig_igb1="inet XX.XX.XX.XX netmask 255.255.255.128 up -rxcsum -txcsum -promisc -lro"
ifconfig_igb2="up -rxcsum -txcsum -lro -promisc "

Share this post


Link to post
Share on other sites

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

означает

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by GrandPr1de

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

Я же писал...

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

Share this post


Link to post
Share on other sites

Я же писал...

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

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

Share this post


Link to post
Share on other sites

Я же писал...

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

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

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

 

Пайпы:

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

Share this post


Link to post
Share on other sites

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

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

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

 

что в sysctl.conf?

Share this post


Link to post
Share on other sites

Привет

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


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

Может.

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

 

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

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this