Cliff Опубликовано 27 февраля, 2010 · Жалоба Весь мозг уже сломал... Собрал кучу софтовых роутеров разных направленностей, нагруженностей и конфигураций, но на такое наткнулся первый раз (почти первый). Симптомы: скидывание NAT-сессий, причем одновременно на нескольких клиентских машинах. Иногда чаще, иногда реже. Ниже я буду называть это "момент проблемы". Но там реально один момент - скидывает и дальше работает. Кроме как на tcp (скидывание сессии) - это ни на каком другом трафике не отображается. icmp ходит без потерь. Подобные симптомы были, когда делал роутеры на 915-ом чипсете (Intel) + одноядерный Pentium + включенный HyperThreading (тогда умные люди подсказали выключить его и все проблемы исчезли). В данном случае железо: MB Asus p5q-cm / Intel Pentium Core 2 Quad (Q8400) / 2GB ОЗУ / сетевая одна Intel expi9400pt (однопортовая гигабитная), встроенная realtec не используется. Система голая, т.к. собиралась изначально под нат-only. Пробовал... 1. Опции BIOS относительно процессора (всякие там Virtualization и т.п.): все ключал, все выключал - никакой разницы. 2. Версию Freebsd: 7.1, 7.2, 7.3RC2 - никакой разницы, 8.0 пока не пробовал, да и боюсь невыгодно будет, т.к. предполагаю использовать драйвера от яндекса, т.к. нужна большая нагрузка и распараллеливание сетевухи по ядрам. 3. Сам нат: либо вот так: дописывание в GENERIC: options IPFILTER options ALTQ options ALTQ_NOPCC # Required for SMP build device pf + pf.conf: set block-policy drop set limit src-nodes 1000000 set limit states 1000000 set limit frags 200000 set optimization aggressive set skip on { lo0, em0, vlan24 } nat on vlan26 from { 10.0.0.0/8 } to any -> 1.2.3.4 + rc.conf: pf_enable="YES" # Enable PF (load module if required) pf_rules="/etc/pf.conf" # rules definition file for pf pf_program="/sbin/pfctl" # where the pfctl program lives либо так: дописывание в GENERIC: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_NAT options LIBALIAS + rc.firewall: [Nn][Aa][Tt]) ${fwcmd} nat 1 config ip 1.2.3.4 ${fwcmd} add nat 1 all from 10.0.0.0/8 to any out via vlan26 ${fwcmd} add nat 1 all from any to 1.2.3.4 in via vlan26 ${fwcmd} add 65000 pass ip from any to any ;; + rc.conf: firewall_enable="YES" firewall_type="NAT" firewall_nat_enable="YES" firewall_nat_interface="vlan26" тоже совершенно одинаковые симптомы. 4. Так же пробовал в ядро впихивать "options HZ=2000" или убирать совсем - тоже ничего не поменяло. 5. Изначально собирал сразу с драйверами от яндекса, потом вернул штатные и в основном все опыты проводил на штатных дровах от сетевухи - но и тут разницы никакой. Еще в самом начале, когда ставил дрова от яндекса прописал и забыл (т.е. при всех опытах оно оставалось висеть) следующее: sysctl.conf: net.inet.ip.forwarding=1 dev.em.0.rx_kthreads=4 dev.em.0.rx_int_delay=250 dev.em.0.tx_int_delay=250 dev.em.0.rx_abs_int_delay=250 dev.em.0.tx_abs_int_delay=250 dev.em.0.rx_processing_limit=400 Когда вернул штатные драйвера, в messages видел ругань на dev.em.0.rx_kthreads, на что внимания есессно не обращал. Диагностика: 1. Нагрузка. Проблема появляется даже при минимальном трафике 10Мбит/с, 1 килопакет. Т.е. достаточно несколько работающих компов (один с торрентами) занатить. 2. Регулярность проблемы. Ну в целом за час раз 10-20 скидывает при вышеуказанной нагрузке. Больше нагрузку даже и не думал еще давать. 3. ifconfig em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> ether 00:15:17:51:6a:ff inet 2.2.2.2 netmask 0xffffffe0 broadcast 2.2.2.31 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MA GIC> ether 90:e6:ba:c9:9d:f2 media: Ethernet autoselect (10baseT/UTP <half-duplex>) status: no carrier plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 vlan24: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether 00:15:17:51:6a:ff inet 192.168.0.99 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active vlan: 24 parent interface: em0 vlan26: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether 00:15:17:51:6a:ff inet 1.2.3.4 netmask 0xfffffff0 broadcast 1.2.3.47 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active vlan: 26 parent interface: em0 Как, в принципе, должно быть уже понятно, vlan24 - внутренняя подсеть, vlan26 - наружу в инет. em0 (нетегированный) почти не используется (в основном для ssh на сам сервер) re0 - встроенный реалтек вообще не использыется 4. netstat -w 1 сейчас уже не очень адекватный (траффика вообще почти нет, но он такой же, когда есть проблема): input (Total) output packets errs bytes packets errs bytes colls 1640 0 1589568 1640 0 1589776 0 1184 0 1107692 1184 0 1107904 0 353 0 336648 352 0 336800 0 366 0 380448 366 0 380660 0 641 0 633660 638 0 633692 0 674 0 662170 674 0 662382 0 691 0 706182 690 0 706334 0 512 0 537708 512 0 537920 0 463 0 431172 462 0 431324 0 608 0 642706 608 0 642752 0 539 0 565572 538 0 565724 0 456 0 387940 456 0 388136 0 607 0 596652 606 0 596804 0 862 0 833272 862 0 833468 0 689 0 653704 688 0 653856 0 430 0 451208 430 0 451420 0 327 0 319840 324 0 319872 0 502 0 505862 502 0 506074 0 В момент проблемы никаких реакций не наблюдается (ни изменения траффика, ни дропнутых пакетов, ни ошибок на интерфейсе). 4. pfctl -si Показывает что-то в виде этого: State Table Total Rate current entries 83 searches 6572160 24.2/s inserts 55442 0.2/s removals 55359 0.2/s Counters match 237271 0.9/s bad-offset 0 0.0/s fragment 1 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 469 0.0/s state-mismatch 104 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s Так же не заметил никаких изменений в момент проблемы. 5. pfctl -ss показывает визуально снижение кол-ва сессий, но все субъективно. 6. kernel_nat (libalias+ipfw) не знаю как диагностировать. 7. systat -vmstat 1 users Load 0.00 0.00 0.00 27 фев 18:46 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 25220 4388 84076 5644 1456244 count All 114344 9176 2232632 11808 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 8005 total 24 347 1 31 5 121 zfod fdc0 irq6 ozfod uhci0+ 16 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle %ozfod 1 uhci4++ 19 | | | | | | | | | | | daefr 2000 cpu0: time prcfr 4 em0 irq256 1 dtbuf totfr 2000 cpu1: time Namei Name-cache Dir-cache 100000 desvn react 2000 cpu3: time Calls hits % hits % 64500 numvn pdwak 2000 cpu2: time 21853 frevn pdpgs intrn Disks ad6 184112 wire KB/t 16.00 21216 act tps 1 350268 inact MB/s 0.02 420 cache %busy 0 1455824 free 114880 buf 8. sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x107d subvendor=0x8086 subdevice=0x1092 class=0x020000 dev.em.0.%parent: pci3 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 250 dev.em.0.tx_int_delay: 250 dev.em.0.rx_abs_int_delay: 250 dev.em.0.tx_abs_int_delay: 250 dev.em.0.rx_processing_limit: 400 В итоге у меня кроме греха на связку проц-система никаких идей больше нет. Проц поменять пока не на что. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 27 февраля, 2010 · Жалоба чем диагностируете "скидывание" сессий? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 27 февраля, 2010 (изменено) · Жалоба pf.conf:set block-policy drop set limit src-nodes 1000000 set limit states 1000000 set limit frags 200000 set optimization aggressive Лучше поставить set optimization normal. Aggressive слишком быстро уничтожает pf states, если вы это имеете в виду под "скидыванием сессий". Если проблема сбрасывания сессий связана с многопроцессорностью, то надо попробовать прибить соответствующие kernel threads к отдельным ядрам процессора. Изменено 28 февраля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 28 февраля, 2010 · Жалоба Я думаю что в данной ситуации "дело не в бобине". По крайней мере не в софте точно. То что перепробованы варианты с разными версиями фри и нат подсистемы, говорит явно не в пользу версии автора. Попробуйте поменять сетевуху, проверьте промежуточное железо, свичи, еще роутеры если есть, "компьютер с торрентами" тоже проверьте, uTP отключите на нем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cliff Опубликовано 28 февраля, 2010 · Жалоба Скидывание сессий = дисконнект всех tcp-соединений.. Всякие аськи, джабберы, игрухи на базе tcp - все это на клиентских машинах дисконнектится и тутже реконнектится. Реконнект происходит успешно. Происходит это одновременно не только по разным приложениям, но и по разным компьютерам. Проблема явно где-то в самом сервере (не за его пределами), т.к. рядом уже давно рабочая система... Врублено все это в циску 3-его уровня. В соседний порт включен нат-сервер: на двух ксеонах, Freebsd7.1, pf, так же одна сетевуха Intel, но другая (сейчас не скажу точно какая). Второй сервер (который проблемный) воткнут рядом, порт настроен идентично, система тоже настраивалась идентично, только железо другое немножко. Проблема возникает у всех компьютеров сразу, идущих через проблемный нат. Когда переключаю их всех на основной нат-сервер, проблемы исчезают у всех. Мысль про убирание "set optimization aggressive" мне самому приходила, когда писал первый пост, буду пробовать в купе с остальными предложениями. Но основной сервер работает именно с этой опцией. надо попробовать прибить соответствующие kernel threads к отдельным ядрам процессора.Подскажите, как это сделать. Спасибо за рекомендации. Буду опробовать их завтра... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 2 марта, 2010 (изменено) · Жалоба Скидывание сессий = дисконнект всех tcp-соединений.. Всякие аськи, джабберы, игрухи на базе tcp - все это на клиентских машинах дисконнектится и тутже реконнектится. Реконнект происходит успешно. Происходит это одновременно не только по разным приложениям, но и по разным компьютерам.Ну кроме pf грешить тут особо не на что. Опция optimization aggressive, убивая стейты, оптимизирует расход kernel memory, а не процессорного времени. надо попробовать прибить соответствующие kernel threads к отдельным ядрам процессора.Подскажите, как это сделать. С помощью программы cpuset. Изменено 2 марта, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
belial Опубликовано 2 марта, 2010 · Жалоба а не пробовали пошаманить, например сетевую карту попробовать воткнуть проверенную. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cliff Опубликовано 2 марта, 2010 (изменено) · Жалоба belial, сетевая проверенная, работает в другом сервере - не нат, но тоже роутер с большой нагрузкой. Кажется нашел причину. dsk, проблема действительно была не в данном сервере. На конкретную идею натолкнул Ваш пост. Дело в переключалке между натами. Она перекидывала между разными натами. Сессии есессно скидывались, когда промежуточный пакет поподал на чужой нат, а тот отправлял отлуп. Рассказываю, как грится, для потомков. Переключалка у меня работала на ipfw fwd на отдельном роутере. Дело в том, что стандартный роутинг по таблице маршрутизации автоматически переопрашивает arp роутеров, куда отправляет пакет. А вот ipfw fwd этого не делает. Когда mac сервера, указанного в ipfw fwd, отсутствует в arp-таблице, правило игнорится совсем (даже счетчики не увеличиваются). Достаточно пингануть этот IP, как правило сразу включается... И выключается обратно по таймауту arp-записи. Жесткая прибивка MAC вроде как решила проблему.. будем посмотреть. На основной НАТ (который рабочий) траф всегда уходил через ipfw, но по каким-то стечениям звезд, arp, видимо, всегда оставался. Вставка перед ним второго правила, уводящего часть трафика на испытуемый нат, совершенно идентична правилу, уводящему на основной нат, поэтому подозрения на это место даже близко не падало. Спасибо всем за участие :) Как минимум морально поддержали. Изменено 2 марта, 2010 пользователем Cliff Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
