Darwinggl Posted February 10, 2015 Posted February 10, 2015 Привет! Есть проблема с 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, запущенном на входе и выходе. Помогите найти пути решения. Вставить ник Quote
alibek Posted February 10, 2015 Posted February 10, 2015 Так для UDP разве бывает порядок следования пакетов? Для него это нормально, UDP не гарантирует ни доставку, ни последовательность. Вставить ник Quote
Darwinggl Posted February 10, 2015 Author Posted February 10, 2015 Так для UDP разве бывает порядок следования пакетов? Для него это нормально, UDP не гарантирует ни доставку, ни последовательность. Это не означает, что можно невозбранно терять и менять порядок следования пакетов. Вставить ник Quote
GrandPr1de Posted February 10, 2015 Posted February 10, 2015 Это не означает, что можно невозбранно терять и менять порядок следования пакетов. означает Вставить ник Quote
DVM-Avgoor Posted February 10, 2015 Posted February 10, 2015 А если убрать _весь_ тюнинг? Вставить ник Quote
vlad11 Posted February 10, 2015 Posted February 10, 2015 Наоборот, еще убрать rxcsum, txcsum, TSO4 у сетевых и перегрузить машину. Вставить ник Quote
Darwinggl Posted February 11, 2015 Author Posted February 11, 2015 ifconfig_igb1="inet XX.XX.XX.XX netmask 255.255.255.128 up -rxcsum -txcsum -promisc -lro" ifconfig_igb2="up -rxcsum -txcsum -lro -promisc " Вставить ник Quote
TheUser Posted February 11, 2015 Posted February 11, 2015 Это не означает, что можно невозбранно терять и менять порядок следования пакетов. означает С точки зрения протокола UDP и приложения, его использующего, означает. С точки зрения сетевого оборудования - нет. Вставить ник Quote
GrandPr1de Posted February 11, 2015 Posted February 11, 2015 С точки зрения сетевого оборудования - нет. С чего это вдруг? У вас сетевое оборудование данные генерирует или всё таки приложения? Если приложение - то оно шлем в любом удобном ему порядке, и именно в таком порядке пойдут по сети, и именно такой порядок будет верным. Ситуацию наблюдаем с помощью tcpdump, запущенном на входе и выходе. дамп покажите хоть Вставить ник Quote
TheUser Posted February 11, 2015 Posted February 11, 2015 Если приложение - то оно шлем в любом удобном ему порядке, и именно в таком порядке пойдут по сети, и именно такой порядок будет верным. Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с freebsd, нет? Вставить ник Quote
GrandPr1de Posted February 11, 2015 Posted February 11, 2015 (edited) Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с freebsd, нет? надо видеть дамп... интересно, там netisr включен или выключен?... Edited February 11, 2015 by GrandPr1de Вставить ник Quote
Darwinggl Posted February 12, 2015 Author Posted February 12, 2015 Так в этом и заключается проблема ТС - последовательность меняется при прохождении через тазик с 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 Как видно, порядок пакетов при прохождении через шлюз изменился. Вставить ник Quote
GrandPr1de Posted February 12, 2015 Posted February 12, 2015 а при выключенном шейпере в данном направлении? как пайпы конфигурите? Вставить ник Quote
Darwinggl Posted February 12, 2015 Author Posted February 12, 2015 а при выключенном шейпере в данном направлении? как пайпы конфигурите? Я же писал... Если абонента снять с шейпера, проблема не решается. Вставить ник Quote
GrandPr1de Posted February 12, 2015 Posted February 12, 2015 Я же писал... да точно, и всё таки, как пайпы конфигурите? Кроме дамминета в фаерволе ещё что-нибудь есть? Вставить ник Quote
Darwinggl Posted February 12, 2015 Author Posted February 12, 2015 Я же писал... да точно, и всё таки, как пайпы конфигурите? Кроме дамминета в фаерволе ещё что-нибудь есть? Кроме дамминета в фаерволе больше ничего нет. Пайпы: 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 Вставить ник Quote
GrandPr1de Posted February 12, 2015 Posted February 12, 2015 т.е. два правила в фаерволе? при этом вы подгружаете ng_ipfw. hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=6000 это вам точно нужно? что в sysctl.conf? Вставить ник Quote
Darwinggl Posted February 24, 2015 Author Posted February 24, 2015 Привет Может кто-нибудь объяснить как между собой коррелируют нити 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. Вставить ник Quote
DVM-Avgoor Posted February 24, 2015 Posted February 24, 2015 т.к. через машину идет коммерческий трафик Вот тут и проблема, а не в очередях и пакетах. Вставить ник Quote
vlad11 Posted February 24, 2015 Posted February 24, 2015 т.к. через машину идет коммерческий трафик Вот тут и проблема, а не в очередях и пакетах. Осталось выяснить, что на конечных узлах стоит. Не Микротик ли, страдающий целым букетом проблем? Вставить ник Quote
Ivan_83 Posted February 25, 2015 Posted February 25, 2015 Может кто-нибудь объяснить как между собой коррелируют нити netisr и прерывания igb очередей? Чем грозит отключение потоков в netisr? Отключить весь тюнинг не представляется возможным, т.к. через машину идет коммерческий трафик и какие-либо эксперименты не допустимы. Может. Генерируется прерывание. Если включён direct то isr не используется и пакет обрабатывается в контексте потока прерывания. Под обработкой поднимается что при fastforward=1 он уходит туда, и если он транзитный и его фаеволы не дропают то пакет улетает в сеть. Если fastfroward=0 то там чуть больше проверок. Когда включён dispatch то isr используется, и во время обработки прервания - обработчик прерывания просто ставит пакет в очередь, а isr поток из этой очереди его забирает. В этом случае у нас больше переключений контекста, дополнительный оверхэд на работу с очередью, чуть больше время обработки, зато мы гарантированно не теряем пакеты при резких всплесках и можем гарантированно их обрабатывать на всех ядрах. В случае с direct для раскидывания по ядрам нужно чтобы сетевуха это умела. Есть ещё потоки нетграфа, они практически как isr, но для их использования хук ноды должен указвать флаг HK_QUEUE (если правильно помню), тогда пакет встанет в очередь и будет обработан уже потоками нетграфа. Вставить ник Quote
Darwinggl Posted February 25, 2015 Author Posted February 25, 2015 Спасибо за развернутый ответ. В случае с 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) гарантированно обрабатывались в одном потоке на одном ядре. Вставить ник Quote
Ivan_83 Posted February 25, 2015 Posted February 25, 2015 Является ли достаточным показателем умения раскидывать прерывания то, что top -SPH показывает по 8 прерываний на каждую igb сетевую карту? Эта тема неоднократно поднималась: сетевухи используют RSS или как его там алгоритм, в случае pppoe оно всё в одно прерывание будет гнать. Каким образом при отключенном isr можно отслеживать потери пакетов (в целом на железке)? Так же как и при включённом. На железе - обычно в sysctl hw.ИМЯ_СЕТЕВУХИ, если в драйвере реализован вывод счётчиков таким образом. Остальное через netstat /systat силами системы. Кстати, вот тут какой-то японец писал про распределение пакетов по обработчикам isr в зависимости от значения хеш-функции от IP, номеров портов и т.д. проходящих потоков. Такое решение помогло бы в нашей ситуации - тогда пакеты в рамках одной сессии (или пары src-dst ip) гарантированно обрабатывались в одном потоке на одном ядре. Темой особо не интересовался. Ну не он один. Там периодически какие то правки на эту тему то появляются то исчезают, у меня ощущение что каждый тянет одеяло на себя: свой конкретный оптимальный случай хочет в ядро запихать. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.