[Hawk128]

С natd тоже проблем нет. Трафик уже не маленький.

 

А вот с ipfw nat (kernel) были проблемы, под нагрузкой перегружал сетевой интерфейс и начинались дропы. Примерно при 200 kpps. Перевел на natd - нагрузка на систему упала в 2-3 раза при том же трафике. Очень странно.

Изменено 21 марта, 2010 пользователем Hawk128

[Alexandr Ovcharenko]

2. net.inet.ip.fastforwarding=1 нельзя юзать с NAT

Объясните плиз подробнее!! Тема ната очень волнует.

Я уже запарился искать причину кернел паники на FreeBSD 8.0 (обновлялась до последней STABLE) с использованием ipfw kernel nat или с ng_nat. Первый же пакет, прилетающий на нат, стабильно ложит систему. При этом natd работает абсолютно без проблем. У меня как раз net.inet.ip.fastforwarding=1 - может это и оно. Но на другой железяке с FreeBSD 8.0 + ng_nat ничего не паникует. Разница в железяках - разные мамы (но обе интел), разные сетевухи (но все интел), на первой машине SATA-RAID (зеркало), на второй просто винт. Но как-то с трудом верится что причина кернел паника на нате может лежать в плоскости железа.

Изменено 21 марта, 2010 пользователем Alexandr Ovcharenko

[jab]

Я уже запарился искать причину кернел паника на FreeBSD 8.0 (обновлялась до последней STABLE) с использованием ipfw kernel nat или с ng_nat. При этом natd работает без абсолютно проблем. У меня как раз net.inet.ip.fastforwarding=1 - может это и оно. Но на другой железяке с FreeBSD 8.0 + ng_nat ничего не паникует. Разница в железяках - разные мамы (но обе интел), разные сетевухи (но все интел), на первой машине SATA-RAID (зеркало), на второй просто винт. Но как-то с трудом верится что причина кернел паника на нате может лежать в плоскости железа.

Обычно причина кернел паника лежит в бэктрейсе коредампа.

[wsimons]

с яндексовскими драйверами разумно использовать net.isr.direct=1

Кстати, вот тут уже отмечали, что драйвера от yandex в сочетании с ng_car (а у меня именно так!) дают непредсказуемый результат.

wsimons, а у Вас что по этому поводу (net.isr.direct=? и net.inet.ip.fastforwarding=?) ?

Кстати, у нас net.isr.direct: 1

А вот фастфорвардинг стоит на 0, ибо когда стоял 1, то наблюдалось что:

все хорошо работает, но до момента перезагрузки (или выключения), после которой машина встает и через 15-40 секунд уходит в кернел паник с ошибками вида discard frame w/o packet header. Причем, ничего не падало, если в момент когда это хозяйство запускается отключить внешний линк от карточки, или-же отключить эту карточку (уже в запущенной системе, но тут важно было успеть это сделать до кернел паник).

Изменено 21 марта, 2010 пользователем wsimons

[AlKov]

...

Кстати, у нас net.isr.direct: 1

А вот фастфорвардинг стоит на 0, ибо когда стоял 1, то наблюдалось что:

все хорошо работает, но до момента перезагрузки (или выключения), после которой машина встает и через 15-40 секунд уходит в кернел паник с ошибками вида discard frame w/o packet header. Причем, ничего не падало, если в момент когда это хозяйство запускается отключить внешний линк от карточки, или-же отключить эту карточку (уже в запущенной системе, но тут важно было успеть это сделать до кернел паник).

Хм.. похоже.. Правда, кернел паник не было, но симптомы близкие. Попробую завтра включить net.isr.direct..

1. NAT с тачки убери

2. net.inet.ip.fastforwarding=1 нельзя юзать с NAT

 

увы пока с имеющимися граблями не совертую мешать

нат дамминет и ng_car

разнеси по тачкам и все будет нормуль

 

и обновись!

МЛЯТЬ!! _НЕТУ НАТ-а_ на этой машине! _НЕТУ дамминет_ на этой машине! _НЕТУ ipfw_ на этой машине!!! Них.., извините, нету! ;)

mpd+ng-car, правила shape передаются mpd radius-ом. Есть pf, но там пара десятков практически ничего не решающих правил (доступ клиентов на tcp 1723 и GRE, ну и доступ админам).

ВСЁ!!! Больше с сетью ничего не работает на этой машине!

NAT, firewall, routing - все на другой Linux тачке. Там все путем.

 

И как все же объяснить вот это:

465 он-лайн, ~75 Mbit, ~14k pps, (uplink 80 Mbit. т.е. почти "полка")

top -S
last pid: 47499;  load averages:  3.55,  3.29,  3.37                                                                                 up 1+01:41:46  19:48:30
385 processes: 8 running, 361 sleeping, 16 waiting
CPU states:  5.6% user,  0.0% nice,  8.5% system, 52.4% interrupt, 33.5% idle
Mem: 658M Active, 2651M Inact, 277M Wired, 159M Cache, 214M Buf, 29M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   14 root         1 -44 -163     0K    16K CPU1   1  20.1H 100.10% swi1: net
   11 root         1 171   52     0K    16K RUN    0 615:19 23.44% idle: cpu0
   10 root         1 171   52     0K    16K RUN    1 667:21 11.47% idle: cpu1
   12 root         1 -32 -151     0K    16K WAIT   0 116:18  4.64% swi4: clock sio
   25 root         1  43    0     0K    16K RUN    0  33:40  2.10% em0_rx_kthread_1
   28 root         1  43    0     0K    16K RUN    0  28:31  1.27% em1_rx_kthread_0
   24 root         1  43    0     0K    16K RUN    0  33:39  1.22% em0_rx_kthread_0
   29 root         1  43    0     0K    16K RUN    0  28:28  1.17% em1_rx_kthread_1

WinMtr ya.ru на клиенте

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             my_NAS      -    0 |  101 |  101 |    0 |   54 |   94 |   46 |
|                             my_router-       0 |  101 |  101 |    0 |   55 |  126 |   47 |
|                          my_gateway -        6 |  101 |   95 |   31 |   56 |   94 |   62 |
|                           87.245.248.18 -    4 |  101 |   97 |   47 |   77 |  156 |   78 |
|                           87.245.248.17 -    3 |  100 |   97 |   47 |   83 |  125 |   78 |
|                           87.245.233.13 -    4 |  100 |   96 |   63 |  103 |  188 |  110 |
|                            77.88.56.126 -    7 |  100 |   93 |   62 |   97 |  219 |   94 |
|                          87.250.228.136 -    5 |  100 |   95 |   62 |   99 |  219 |   94 |
|                              77.88.21.8 -    4 |  100 |   96 |   62 |   97 |  188 |   79 |
|________________________________________________|______|______|______|______|__
____|______|
   WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir  ( stanimir@cr.nivis.com )

До яндексовских драйверов при swi1: net ~ 75% дропы на клиенте доходили до 25%, сейчас, как видите, swi1: net - 100% с гаком !!!!! и практически без дропов (на моем железе).

Бред какой-то... Но работает..

Изменено 21 марта, 2010 пользователем AlKov

[AntonS]

dev.em.0.rx_int_delay=400

dev.em.0.tx_int_delay=400

dev.em.0.rx_abs_int_delay=600

dev.em.0.tx_abs_int_delay=600

dev.em.1.rx_int_delay=400

dev.em.1.tx_int_delay=400

dev.em.1.rx_abs_int_delay=600

dev.em.1.tx_abs_int_delay=600

 

сделай

и флашни все правила файрвола

у тебя по прерываниями затыкается система

msi-x походу мать не умеет

программные прерывание надо понизить

[AlKov]

dev.em.0.rx_int_delay=400

dev.em.0.tx_int_delay=400

dev.em.0.rx_abs_int_delay=600

dev.em.0.tx_abs_int_delay=600

dev.em.1.rx_int_delay=400

dev.em.1.tx_int_delay=400

dev.em.1.rx_abs_int_delay=600

dev.em.1.tx_abs_int_delay=600

 

сделай

Сделал. До этого было

dev.em.0.rx_kthreads: 2
dev.em.0.rx_int_delay: 0
dev.em.0.tx_int_delay: 0
dev.em.0.rx_abs_int_delay: 66
dev.em.0.tx_abs_int_delay: 66
dev.em.0.rx_kthread_priority: 127

dev.em.1.rx_kthreads: 2
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 0
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_kthread_priority: 127

 

Кстати, а с этим - dev.em.0.rx_kthreads: 2 и этим - dev.em.0.rx_kthread_priority: 127 что-нибудь надо делать??

и флашни все правила файрвола

у тебя по прерываниями затыкается система

msi-x походу мать не умеет

программные прерывание надо понизить

Каким образом?

P.S. Кстати, все же net.isr.direct: 1 и mpd, или ng_car (??) несовместимы.. Рискнул испортить юзерам воскресенье и успешно испортил - через минуты полторы после установки "1", машинка успешно подвесилась.. :( Именно тихо-мирно повисла (как и описывал ранее) без всяких кернел паник..

[wsimons]

P.S. Кстати, все же net.isr.direct: 1 и mpd, или ng_car (??) несовместимы.. Рискнул испортить юзерам воскресенье и успешно испортил - через минуты полторы после установки "1", машинка успешно подвесилась.. :( Именно тихо-мирно повисла (как и описывал ранее) без всяких кернел паник..

Хм, а у нас работает. Хотя, разные сетевухи, разный тюнинх может быть.

[AntonS]

ты обновился?

или все старую пытаешься заставить работать?

[AlKov]

ты обновился?

или все старую пытаешься заставить работать?

А с 6.3 на 8.0 в один заход реально обновиться? С compat6, например. Пока нагуглить подобное не смог...

[AntonS]

ты до RELENG_6 обновись

а то не обновился и чего то хочешь

[[GP]Villi]

Объясните плиз подробнее!! Тема ната очень волнует.

Я уже запарился искать причину кернел паники на FreeBSD 8.0 (обновлялась до последней STABLE) с использованием ipfw kernel nat или с ng_nat. Первый же пакет, прилетающий на нат, стабильно ложит систему. При этом natd работает абсолютно без проблем. У меня как раз net.inet.ip.fastforwarding=1 - может это и оно. Но на другой железяке с FreeBSD 8.0 + ng_nat ничего не паникует. Разница в железяках - разные мамы (но обе интел), разные сетевухи (но все интел), на первой машине SATA-RAID (зеркало), на второй просто винт. Но как-то с трудом верится что причина кернел паника на нате может лежать в плоскости железа.

 

Due to the architecture of libalias(3), ipfw nat is not compatible with
     the TCP segmentation offloading (TSO).  Thus, to reliably nat your net-
     work traffic, please disable TSO on your NICs using ifconfig(8).

 

Возможно ответ в этом?

[AlKov]

Сервер после установки "родных" дров от интела и тюнинга как бы вполне "разгрузился".

last pid: 89038; load averages: 0.87, 0.79, 0.90 up 7+05:10:21 23:55:00 383 processes: 5 running, 362 sleeping, 16 waiting CPU states: 5.2% user, 0.0% nice, 29.2% system, 14.6% interrupt, 50.9% idle Mem: 1858M Active, 1396M Inact, 312M Wired, 190M [code]last pid: 89038; load averages: 0.87, 0.79, 0.90 up 7+05:10:21 23:55:00
383 processes: 5 running, 362 sleeping, 16 waiting
CPU states: 5.2% user, 0.0% nice, 29.2% system, 14.6% interrupt, 50.9% idle
Mem: 1858M Active, 1396M Inact, 312M Wired, 190M Cache, 214M Buf, 30M Free
Swap: 8192M Total, 124K Used, 8192M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
10 root 1 171 52 0K 16K RUN 1 89.7H 57.62% idle: cpu1
11 root 1 171 52 0K 16K RUN 0 77.4H 51.81% idle: cpu0
23 root 1 -68 0 0K 16K CPU0 0 61.4H 36.96% em1 taskq
14 root 1 -44 -163 0K 16K CPU1 1 47.1H 21.83% swi1: net
22 root 1 -68 0 0K 16K - 1 23.3H 15.09% em0 taskq
12 root 1 -32 -151 0K 16K WAIT 1 769:17 1.95% swi4: clock sio

(это сейчас порядка 400 он-лайн pptp, при более 500 em1 taskq не более 60%), но сервак упрямо падает при где-то 560-580 он-лайн.. Начинается этот "процесс" с "ошибки 718" у юзеров, появлением "дупликатов" в логе радиуса, реаккаунтингом и прочими "прелестями". В конце-концов приходится делать ребут mpd и radius.

В логе mpd в этот момент подобные записи

Mar 29 20:21:35 core mpd: [L-103] CHAP: Auth return status: busy
Mar 29 20:21:36 core mpd: [L-64] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:36 core mpd: [L-333] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:36 core mpd: [L-102] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:36 core mpd: [L-344] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:37 core mpd: [L-167] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:37 core mpd: [L-310] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:37 core mpd: [L-514] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:37 core mpd: [L-366] RADIUS: rad_send_request for user 'XXXXXXXX' failed: No valid RADIUS responses received
Mar 29 20:21:38 core mpd: [L-5] PPTP call terminated
Mar 29 20:21:38 core mpd: [L-5] Link: DOWN event
Mar 29 20:21:38 core mpd: [L-5] LCP: Close event
Mar 29 20:21:38 core mpd: [L-5] LCP: state change Stopped --> Closed

Судя по всему, mpd здесь "не при делах". По-видимому, проблема то ли у радиуса, то ли у mysql, с которым он работает.

Но в top-е в этот момент не видно явной загрузки ни радиуса, ни мускуля. Может по прерываниям машина задыхается??

 

Сегодня плюс ко всему получил второе разочарование - похоже, я напрасно поверил в существующее утверждение о том, что onboard сетевые карты работают хуже pci-ных.

Получил новое железо: mb - intel s5500bc, onboard LAN - 82575EB и парой pci-e 82572EI ( EXPI9400PTBLK). После установки FreeBSD 8.0 STABLE получил ошеломляющий результат в виде глюка с поднятием тех самых EXPI9400PTBLK - после ребута по статусу сетевая находится в он-лайн, но трафик с нее не ходит до момента физического передергивания сетевого кабеля.. :( В тоже время onboard сетевые поднимаются без проблем.. Попробовал установить драйвера от intel (em.6.9.21) - результат аналогичный..

Еще более удивил pciconf -l -v -c

igb0@pci0:1:0:0:        class=0x020000 card=0x34dc8086 chip=0x10a78086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82575EB Gigabit Network Connection'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 2  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit
    cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled
    cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4)
igb1@pci0:1:0:1:        class=0x020000 card=0x34dc8086 chip=0x10a78086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82575EB Gigabit Network Connection'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 2  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit
    cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled
    cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4)
em0@pci0:3:0:0: class=0x020000 card=0x10828086 chip=0x107d8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'PRO/1000 PT'
    class      = network
    subclass   = ethernet
    cap 01[c8] = powerspec 2  supports D0 D3  current D0
    cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
    cap 10[e0] = PCI-Express 1 endpoint max data 256(256) link x1(x1)
em1@pci0:5:0:0: class=0x020000 card=0x10828086 chip=0x107d8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'PRO/1000 PT'
    class      = network
    subclass   = ethernet
    cap 01[c8] = powerspec 2  supports D0 D3  current D0
    cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
    cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)

Как оказалось, onboard сетевые умеют MSI-X, а специально купленные pci-e нет.. Вообщем, полнейшее разочарование, недоумение и непонятки о дальнейших действиях.. Скорее всего буду юзать onboard LAN. Деньги на ветер... :(

[AntonS]

может просто не понимание и не читание форума?

[Hawk128]

Похоже на то. Intel продает прекрасные внешние на 82575(6) чипсетах, которые очень даже много чего умеют...

[jab]

 

:-)))

[KES]

с яндексовскими драйверами разумно использовать net.isr.direct=1

Кстати, вот тут уже отмечали, что драйвера от yandex в сочетании с ng_car (а у меня именно так!) дают непредсказуемый результат.

wsimons, а у Вас что по этому поводу (net.isr.direct=? и net.inet.ip.fastforwarding=?) ?

Кстати, у нас net.isr.direct: 1

А вот фастфорвардинг стоит на 0, ибо когда стоял 1, то наблюдалось что:

все хорошо работает, но до момента перезагрузки (или выключения), после которой машина встает и через 15-40 секунд уходит в кернел паник с ошибками вида discard frame w/o packet header. Причем, ничего не падало, если в момент когда это хозяйство запускается отключить внешний линк от карточки, или-же отключить эту карточку (уже в запущенной системе, но тут важно было успеть это сделать до кернел паник).

Шайтан!!!

пару часов назад поставил net.inet.ip.fastforwarding=1. Прочитав это сообщение пошел менять /boot/loader.conf обратно на 0 успел только сохранить файл и сервак ушел в даун. Завтра нужно будет бежать на тех площадку.... (((((((

Изменено 13 ноября, 2010 пользователем KES