[BlackDeath]

CPU - Q9550

RAM - 4GB

2 ETH - Intel PRO/1000

Freebsd 7.1

ipfw (dummynet) + pf (nat)

quagga (BGP fullview)

драйвера от яндекса

основная задача сервера - нарезка анлимитов, натинг и выпуск в мир из локалки. В ipfw применяются таблицы для распизивания пакетов по трубам, суммарно во всех таблицах ~3000 строк

 

машина в работе уже 2-й месяц, все бы хорошо, но вот сегодня возникла проблема - не принимает новые коннекты ни на себя ни через себя. Причем отбрасывается только определенный % новых соединений, так например при попытке запустить пинг с локальной машины в мир, примерно 6 из 1- стратов будут успешны, и если сессия уже открылась - то дальше дропов нет, все пакеты идут как по маслу :) Тоже самое и при попытке попасть по SSH на сервер, примерно 6 из 1- попыток удачные, остальные же завершаются connetcion timeout.

 

netstat -m

13680/2835/16515 mbufs in use (current/cache/total)

13675/2459/16134/262144 mbuf clusters in use (current/cache/total/max)

13674/1686 mbuf+clusters out of packet secondary zone in use (current/cache)

0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max)

0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)

0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)

34021K/6042K/37064K bytes allocated to network (current/cache/total)

0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)

0/0/0 requests for jumbo clusters denied (4k/9k/16k)

0/6/6656 sfbufs in use (current/peak/max)

 

pfctl -si

No ALTQ support in kernel

ALTQ related functions disabled

Status: Enabled for 0 days 01:45:44 Debug: Urgent

 

State Table Total Rate

current entries 195009

searches 316595893 65904.8/s

inserts 17979127 2834.0/s

removals 17872118 2817.2/s

Counters

match 61204850 9647.7/s

bad-offset 0 0.0/s

fragment 13 0.0/s

short 1 0.0/s

normalize 37 0.0/s

memory 30457579 4801.0/s

bad-timestamp 0 0.0/s

congestion 0 0.0/s

ip-option 2 0.0/s

proto-cksum 1618 0.3/s

state-mismatch 72916 11.5/s

state-insert 48161 7.6/s

state-limit 0 0.0/s

src-limit 0 0.0/s

synproxy 0 0.0/s

 

конфиги:

 

sysctl.conf

 

kern.maxfiles=204800

kern.maxfilesperproc=200000

net.inet.tcp.blackhole=2

net.inet.udp.blackhole=1

kern.ipc.somaxconn=4096

kern.sync_on_panic=1

net.inet.tcp.nolocaltimewait=1

net.inet.ip.redirect=0

net.isr.direct=1

net.inet.ip.portrange.first=1024

net.inet.ip.portrange.last=65535

net.inet.ip.portrange.randomized=0

net.inet.ip.dummynet.hash_size=1024

net.inet.ip.fw.dyn_max=8192

kern.ipc.nmbclusters=262144

kern.ipc.maxsockets=204800

net.inet.tcp.maxtcptw=40960

 

pf.conf

# Options: tune the behavior of pf, default values are given.

#set timeout { interval 10, frag 30 }

set timeout { tcp.first 30, tcp.opening 20, tcp.established 86400 }

set timeout { tcp.closing 700, tcp.finwait 30, tcp.closed 60 }

#set timeout { udp.first 60, udp.single 30, udp.multiple 60 }

#set timeout { icmp.first 20, icmp.error 10 }

#set timeout { other.first 60, other.single 30, other.multiple 60 }

#set timeout { adaptive.start 0, adaptive.end 0 }

set limit { states 200000, frags 100000, src-nodes 50000}

#set loginterface none

#set optimization normal

#set block-policy drop

#set require-order yes

 

в ядре:

options HZ=1000

options KVA_PAGES=512

 

куда копать - непонятно, сейчас поменяли таймауты в pf.conf, до этого были дефолтные, раскоментил и поменял значения:

set timeout { tcp.first 30, tcp.opening 20, tcp.established 86400 }

set timeout { tcp.closing 700, tcp.finwait 30, tcp.closed 60 }

 

сразу стало принимать все коннекты - все побежало бодро, однако напрягает мысль, что параметры pf никак не влияеют на отработку коннектов на сам сервер, т.е. они же влияют только на проходящий трафик, и то, что у него было 195 000 записей из 200 000, поидеи не должно было сказываться на коннектах по ssh на сервер.

 

Может кто заметит что-то не совсем верное в конфиге, или посоветует параметры таймаутов в pf для более лучшей настройки ?

[[GP]Villi]

почему это они не влияют? в общем мне кажется что вы банально приблизились к лимиту, поставьте 300 000 и посмотрите.

а почему у вас так много стейтов, сколько клиентов за роутером? мне кажется имеет смысл поставить set optimization aggresive .

[BlackDeath]

За роутером около 4000 клиентов....

Поставил set optimization aggresive, увеличил число записей до 300 000.

Вопрос, какими параметрами руководствоваться при определении максимального кол-ва записей, какие ресурсы это отжирает, на чем основываться, чтоб не превысить реальный предел системы?

Можно ли как-нить уменьшить это число записей, я так понимаю это записи keep state от правил, или binat правила сюда также входят?

 

Вот мои правила pf.conf:

scrub in all

binat on $int1 from 10.1.yy.y to any -> 195.114.xx.x

...... и таких около 100 записей

 

#Dynamic ip pool

nat on $int1 from $internal_net to any -> { 91.xxx.xxx.128/25 91.xxx.xxx.64/26 91.xxx.xxx.32/27 91.xxx.xxx.16/28 91.xxx.xxx.8/29 91.xxx.xxx.4/30 } round-robin sticky-address

 

pass in quick on $int_if proto udp from any to any port 53 modulate state

pass out quick on $int_if proto udp from any to any port 53 modulate state

pass all modulate state (source-track rule, max-src-states 1500)

[[GP]Villi]

а зачем вам на все пакеты modulate state я так понимаю вы ограничиваете количество соединений 1500?

 

да в количество этих записей входят стейты и от ната и от state правил, от бината тоже скорее всего.

 

если я не ошибаюсь пока таблица этих записей влезает в l2 кеш процессора то все хорошо, как только его начинает нехватать то становится плохо.

 

pass in quick on $int_if proto udp from any to any port 53 modulate state

pass out quick on $int_if proto udp from any to any port 53 modulate state

а что вы пытаетесь этими правилами сделать?

Изменено 2 мая, 2009 пользователем [GP]Villi

[BlackDeath]

modulate state поставил чтоб избавиться от записей keep state, но уже понял - что это безсмысленно :)

А правила 53 порта стоят из-за большой активности DNS которая просто не помещается в 1500 сессий, вот и добавил эти правила, чтоб для DNS небыло ограничения по кол-ву сессий.

Кстати на данный момент пока все работает стабильно, но остался вопрос, какое ставить кол-во записей для хранения состояний, на чем основываться при выборе этого пораметра, какие ограничения на него накладываются, и какие всетаки таймауты лучше использовать?

[Ivan_83]

syn-proxy=modulate+futures=keep state++

короче в мане явно написано что модулейт статейт включает в себя кип стэйт + доп функционал.

 

в вашем случае, имхо, вы не можете избавится от таблицы состояний, ибо у вас:

pass all modulate state (source-track rule, max-src-states 1500)

откуда оно будет брать колличество для подсчёта в 1500?...

 

вот так без стейтов:

pass in quick on $int_if proto udp from any to any port 53

pass out quick on $int_if proto udp from any to any port 53

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

 

4000 клиентов * 1500 = 6 000 000 сессий всего, без учёта того что со вне приходит и с самого сервера.

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

[qwePurple]

modulate state поставил чтоб избавиться от записей keep state, но уже понял - что это безсмысленно :)

А правила 53 порта стоят из-за большой активности DNS которая просто не помещается в 1500 сессий, вот и добавил эти правила, чтоб для DNS небыло ограничения по кол-ву сессий.

Кстати на данный момент пока все работает стабильно, но остался вопрос, какое ставить кол-во записей для хранения состояний, на чем основываться при выборе этого пораметра, какие ограничения на него накладываются, и какие всетаки таймауты лучше использовать?

Раз уж Вы используете pf в качестве nat (не в качестве фильтра трафика), то возможно есть смысл убрать pass правила и оставить лишь:

 

pass all no state

 

А также описать skip для интерфейсов, которые отношения к nat не имеют (это все, кроме $int1, насколько понимаю).

 

Относительно таблицы состояний:

 

Понаблюдайте за

pfctl -si

current entries ...

 

при разных нагрузках.

 

Потом укажите в конфиге pf такое значение, чтоб оно было недостижимым в current entries. Насколько мне ясно, State Table использует память динамически, поэтому казав в set limit states 1000000 ничего страшного не произойдёт :)

Изменено 7 мая, 2009 пользователем qwePurple