FreeBSD: PF NAT против IPFW NAT. Какой быстрее?

[vppkn 102]

А у меня вот что с ipfw происходит:

 

 

last pid: 75717; load averages: 4.07, 3.83, 3.86 up 13+07:28:16 20:42:47

394 processes: 8 running, 363 sleeping, 20 waiting, 3 lock

CPU 0: 1.2% user, 0.0% nice, 6.7% system, 42.1% interrupt, 50.0% idle

CPU 1: 0.0% user, 0.0% nice, 14.6% system, 43.7% interrupt, 41.7% idle

CPU 2: 0.0% user, 0.0% nice, 9.1% system, 49.6% interrupt, 41.3% idle

CPU 3: 0.0% user, 0.0% nice, 6.7% system, 75.6% interrupt, 17.7% idle

Mem: 62M Active, 640M Inact, 754M Wired, 72K Cache, 417M Buf, 2475M Free

Swap: 4096M Total, 4096M Free

А что за процессор?

[sergeev 1]

Читал его заметки, кое-что себе взял. Но что можно крутить в моём случае

 

hw.bce.rx_ticks: 18

hw.bce.rx_ticks_int: 18

hw.bce.rx_quick_cons_trip: 6

hw.bce.rx_quick_cons_trip_int: 6

hw.bce.tx_ticks: 80

hw.bce.tx_ticks_int: 80

hw.bce.tx_quick_cons_trip: 20

hw.bce.tx_quick_cons_trip_int: 20

hw.bce.loose_rx_mtu: 0

hw.bce.hdr_split: 1

hw.bce.tx_pages: 2

hw.bce.rx_pages: 2

hw.bce.msi_enable: 1

hw.bce.tso_enable: 1

hw.bce.verbose: 1

 

По прерыванием выставлял стандартно:

 

net.isr.numthreads: 4

net.isr.maxprot: 16

net.isr.defaultqlimit: 4096

net.isr.maxqlimit: 10240

net.isr.bindthreads: 0

net.isr.maxthreads: 4

net.isr.direct: 0

net.isr.direct_force: 0

net.isr.dispatch: deferred

 

Процессор:

 

hw.machine: amd64

hw.model: Intel® Xeon® CPU 5140 @ 2.33GHz

hw.ncpu: 4

hw.machine_arch: amd64

[Artcv 4]

load averages: 4.07, 3.83, 3.86

 

Такие показатели нормальные считаются?

[sergeev 1]

load averages: 4.07, 3.83, 3.86

 

Такие показатели нормальные считаются?

 

Нет конечно, о чём и пишу. Сервер практически работает в холостую, а нагрузка большая. Как только убираю нат - всё хорошо. Из-за ipfw nat получается большое кол-во прерываний и net.isr не успевает их разгрести и система уходит в перезагрузку.

 

В ipfw правила только для ната:

 

nat 11 ip from 172.16.200.0/24 to any out

nat 11 ip from any to 1.1.1.1 in

ipfw nat 11 config ip 1.1.1.1 same_ports reset

[andryas 1 058]

Правильно, кажется делать так::

out via <interface>

in via <interface>

 

и поотключайте всякие -rxcsum -tso

[sergeev 1]

Спасибо, попробуем.

[nightfly 1 221]

Кстати да, "-rxcsum -txcsum -tso" практически объязательны на данный момент. libalias их очень не любит.

[sergeev 1]

Кстати да, "-rxcsum -txcsum -tso" практически объязательны на данный момент. libalias их очень не любит.

Вот за проверку контрольных сумм как-то подзабыл, эти опции по умолчанию включены

options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE> и hw.bce.tso_enable: 1

Ночью буду пробывать.

 

Но подниму еще вопрос - ddos nat со стороны пользователя - возможен? 40-50 интерфейсов и мизер трафика а NAS уходил в перезагрузку. Сейчас около недели всё тихо.

[nightfly 1 221]

Но подниму еще вопрос - ddos nat со стороны пользователя - возможен? 40-50 интерфейсов и мизер трафика а NAS уходил в перезагрузку. Сейчас около недели всё тихо.

Не должно быть.

По сути NAT далеко не настолько трудоемкая задача. Максимум, что там может кончиться это доступная ядру память. Смотрим в vmstat и если что крутим KVA_PAGES, vm.kmem_size и соответственно буфера. К сожелению статистика ipfw nat show очень скудная, но если вы не видите там шестизначных цифр - все должно быть вполне нормально, даже по дефолту.

 

При невырубленных чексумах и ТСО у нас в свое время просто захлопывались физические сетевухи и не подымались до down/up. Уход в ребут уже недобрый симптом намекающий на извечные проблемы с тунельными соединениями и сколько помниться крутившийся какраз вокруг isr и flowtables и mpd. Точнее ничего не скажу - с pppoe/pptp не работаем очень давно.

[laffytaffy 84]

Кстати, какие на данный момент сетевые лучше использовать, что там новее Intel 82576 (драйвер igb) появилось, подскажите?

[LV10 273]

82599EB

[laffytaffy 84]

а если по-скромнее, гигабитные?

[mlevel 52]

Думав переходити на ipfw kernel nat з pf, але:

1. round-robin nat не настільки просто реалізувати як в pf

2. не дружить з апаратним tos

[vppkn 102]

Думав переходити на ipfw kernel nat з pf, але:

А причина думания про переход?

[LV10 273]

имхо, лучше чем 82576 igb не видел

[smokenet 0]

Господа, а кто знает вариант нормального не дорогого аппаратного NATа?

Жевать нужно 500Мбит на 1000 клиентов с пакетами до 30Мбит.

 

(Намучились с Микротиками и софтовыми решениями)

[KaYot 3 606]

Требования не совместимы - аппаратный, нормальный, недорогой.

Чем тазик с линуксом не устраивает для этих целей? Соберите нормальный сервер - любой 4ех ядерник, серверную мать, ECC память и двухголовую сетевку на 82576 - один раз настроите и забудете о нем пока в гигабит не упретесь, чем там мучаться?

[smokenet 0]

Intel Quad-Core Xeon E3-1220 3.1GHz/8MB/5GT (BX80623E31220) s1155 BOX + Asus P8B-C/4L (s1155, Intel C202, PCI-E x16) + ECC DDR3

 

дают такие показания по нагрузке и, судя даже по графику процессора, по устойчивости, при 500 абонентов на 200Мбит во фре 8 64bit

 

 

 

А несовместимые слова - нужно совместить. Иначе не было-бы смысла в вопросе ))))))))

[KaYot 3 606]

Значит нужно что-то менять в софте, у вас судя по загрузке NAT где-то в user space крутится. Ядерный при таком трафике должен давать от силы 5% загрузку, вот я и предлагаю linux+iptables для этого.

А по аппаратным - вам нужна железка уровня cisco ASA 5550 или что-то из ACE, но недорогими их назвать язык не поворачивается..

[Kucher2 122]

IPFW2 против PF.

[greyshadow 22]

CPU: Intel® Xeon® CPU E5504 @ 2.00GHz (2008.09-MHz 686-class CPU) (1 шт)

FreeBSD 8.1-RELEASE

 

200-800 pppoe юзерей с NAT-ом при трафике до 600М - CPU выше 30% не поднимается....

[vppkn 102]

CPU: Intel® Xeon® CPU E5504 @ 2.00GHz (2008.09-MHz 686-class CPU) (1 шт)

FreeBSD 8.1-RELEASE

Ну а нат то какой из?

[greyshadow 22]

ipfw + natd

[vppkn 102]

ipfw + natd

Нифига себе какой natd производительный .

[greyshadow 22]

Ну их там вообще-то 6 штук вертиться и в 6 адресов соответственно НАТ-ится...