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

freebsd + core2quad + nat = скидывание сессий

Весь мозг уже сломал... Собрал кучу софтовых роутеров разных направленностей, нагруженностей и конфигураций, но на такое наткнулся первый раз (почти первый).

 

Симптомы: скидывание 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

 

В итоге у меня кроме греха на связку проц-система никаких идей больше нет. Проц поменять пока не на что.

Share this post


Link to post
Share on other sites
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 к отдельным ядрам процессора.
Edited by photon

Share this post


Link to post
Share on other sites

Я думаю что в данной ситуации "дело не в бобине".

По крайней мере не в софте точно. То что перепробованы варианты с разными версиями фри и нат подсистемы, говорит явно не в пользу версии автора.

Попробуйте поменять сетевуху, проверьте промежуточное железо, свичи, еще роутеры если есть, "компьютер с торрентами" тоже проверьте, uTP отключите на нем.

Share this post


Link to post
Share on other sites

Скидывание сессий = дисконнект всех tcp-соединений.. Всякие аськи, джабберы, игрухи на базе tcp - все это на клиентских машинах дисконнектится и тутже реконнектится. Реконнект происходит успешно. Происходит это одновременно не только по разным приложениям, но и по разным компьютерам.

 

Проблема явно где-то в самом сервере (не за его пределами), т.к. рядом уже давно рабочая система... Врублено все это в циску 3-его уровня. В соседний порт включен нат-сервер: на двух ксеонах, Freebsd7.1, pf, так же одна сетевуха Intel, но другая (сейчас не скажу точно какая). Второй сервер (который проблемный) воткнут рядом, порт настроен идентично, система тоже настраивалась идентично, только железо другое немножко. Проблема возникает у всех компьютеров сразу, идущих через проблемный нат. Когда переключаю их всех на основной нат-сервер, проблемы исчезают у всех.

 

Мысль про убирание "set optimization aggressive" мне самому приходила, когда писал первый пост, буду пробовать в купе с остальными предложениями. Но основной сервер работает именно с этой опцией.

 

надо попробовать прибить соответствующие kernel threads к отдельным ядрам процессора.
Подскажите, как это сделать.

 

Спасибо за рекомендации. Буду опробовать их завтра...

Share this post


Link to post
Share on other sites
Скидывание сессий = дисконнект всех tcp-соединений.. Всякие аськи, джабберы, игрухи на базе tcp - все это на клиентских машинах дисконнектится и тутже реконнектится. Реконнект происходит успешно. Происходит это одновременно не только по разным приложениям, но и по разным компьютерам.
Ну кроме pf грешить тут особо не на что. Опция optimization aggressive, убивая стейты, оптимизирует расход kernel memory, а не процессорного времени.

 

надо попробовать прибить соответствующие kernel threads к отдельным ядрам процессора.
Подскажите, как это сделать.

С помощью программы cpuset.
Edited by photon

Share this post


Link to post
Share on other sites

а не пробовали пошаманить, например сетевую карту попробовать воткнуть проверенную.

Share this post


Link to post
Share on other sites

belial,

сетевая проверенная, работает в другом сервере - не нат, но тоже роутер с большой нагрузкой.

 

Кажется нашел причину.

 

dsk, проблема действительно была не в данном сервере. На конкретную идею натолкнул Ваш пост. Дело в переключалке между натами. Она перекидывала между разными натами. Сессии есессно скидывались, когда промежуточный пакет поподал на чужой нат, а тот отправлял отлуп.

 

Рассказываю, как грится, для потомков.

 

Переключалка у меня работала на ipfw fwd на отдельном роутере. Дело в том, что стандартный роутинг по таблице маршрутизации автоматически переопрашивает arp роутеров, куда отправляет пакет. А вот ipfw fwd этого не делает. Когда mac сервера, указанного в ipfw fwd, отсутствует в arp-таблице, правило игнорится совсем (даже счетчики не увеличиваются). Достаточно пингануть этот IP, как правило сразу включается... И выключается обратно по таймауту arp-записи. Жесткая прибивка MAC вроде как решила проблему.. будем посмотреть.

 

На основной НАТ (который рабочий) траф всегда уходил через ipfw, но по каким-то стечениям звезд, arp, видимо, всегда оставался. Вставка перед ним второго правила, уводящего часть трафика на испытуемый нат, совершенно идентична правилу, уводящему на основной нат, поэтому подозрения на это место даже близко не падало.

 

Спасибо всем за участие :) Как минимум морально поддержали.

Edited by Cliff

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