BlackDeath

modulate state поставил чтоб избавиться от записей keep state, но уже понял - что это безсмысленно :) А правила 53 порта стоят из-за большой активности DNS которая просто не помещается в 1500 сессий, вот и добавил эти правила, чтоб для DNS небыло ограничения по кол-ву сессий. Кстати на данный момент пока все работает стабильно, но остался вопрос, какое ставить кол-во записей для хранения состояний, на чем основываться при выборе этого пораметра, какие ограничения на него накладываются, и какие всетаки таймауты лучше использовать?

За роутером около 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)

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 для более лучшей настройки ?

По поводу tables коль уж их затронули, хочу обратить Ваше внимание на следующий баг: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127209 На слабонагруженых машинах практически не проявляется, однако при добавлении через utm_rfw около 2000 записей, таблицы начинают глючить именно так, как и описано.

А пример подобного конфига можно? Например для такого: Суммарно канал - 100Мбит надо сделать: постоянных 6 пользователей с рейтом - 10Мбит цеилом - 100Мбит для каждого 15-17 пользователей с рейтом 2Мбит цеилом - 5Мбит для каждого и кучу динамических пользователей каждый со своим шейпом (из списка 128/256/512/1024/2048) :)

Подниму тему, заодно задам вопрос :) Вопсчем мы собрали вот что: CPU - E8600 Core2Duo MB - ASUS P5BV-C RAM - 2x1GB Kingston HDD Вертится это все на данный момент на ОС Fedora Core, c htb tc, iptables (nat+users_access+tc_ipt_mark), quagga c 2мя BGP ( принимаю пока только дефолты). Хотели перейти на FreeBSD 7.0 c ipfwnat и ng_netflow, однако столкнулись с проблемой выбора шейпера. Задача такая: Имеется 2 канала по 100Мбит, надо настроить шейпование, в которе можно динамически добавлять правила шеловским скриптом, однако при этом есть еще ряд пользователей, у которых есть дефолтный минимальный порог, ниже которого их зарезать не надо, но при наличии свободного канала, им надо выдать всю полосу пропускания. На данный момент эта задача легко решается при помощи htb tc (RAIT & CEIL) + iptables mangle MARK. А вот под ФРЮ никак не могу найти ничего подходящего, чтобы также красиво справлялось с поставленной задачей.... Обычные ipfw pipes от dumminet не могут помочь с вопросом rait&ceil.... ALTQ - работает только с PF и как следствие нельзя создать динамику правил, т.е. при каждом изменении надо полностью перечитывать правила в PF, что понятное дело не допустимо. Netgraph великолепно решает задачу через mpd, который однако пока не получается застваить работать с множеством шейпов по ip на одном интерфейсе, ему нравится шейпить только интерфейс, а переходить на pppoe нам вовсе не хочется.... Вопсчем, уважаемый ALL, ждем предложений и идей по поводу поставленной задачи.....

Недавно сами сталкивались с вопросом выбора железа, остановились на ASUS P5BV-C, E8600, 2GB RAM Изначально долго мучали бортовые сетевые от марвела, но после 3-го глюка за 2 дня с хаотичным отвалом сетевых, без сообщеий в логах, когда выборочно одна из сетевых тупо переставала гонять трафик, но при этом была "в апе" и сервер её пинговал, решили, что всетаки интегрированные сетевые для роутинга "ни в зуб ногой", чего и подозревали..... Поставили 2 Интел ПРО1000 - проблем не знаем :) P.S. ОС fedora, Border, NAT, tc, ipcad правда пока без ipset, 100Мбит на 2 интерфейсах, около 1500-2000 одновременных сессий, еще по 50-60% времени свободно на каждом ядре. Хотим попробывать перейти на FreeBSD, но пока вопрос стоит в динамическом шейпинге с возможностью rait+ceil, но по этому поводу уже поднял темку, всем желающим помочь - писать сюда: http://forum.nag.ru/forum/index.php?showtopic=44336

Народ вот пишет про то - что систему лучше поднимать на флешке, поискали по поставщикам железа, все морозятся и никто ничего подобного не знает ни о каких контролерах и прочем. Народ, кто использует такую технологию построения серверов - подскажите, где и какое железо для этих целей вы покупаете? какие контролеры и какие флешки нужно/лучше использовать?

Итак, как говорится, подводя итоги: 1. Корпус CSV 1U-M (250ВТ) 2. Мать ASUS P5M2-M, в релиз ноте по FreeBSD 7.0 не нашел поддержку Broadcom® BCM5721, может кто знает - подскажите. 3. Процессор Xeon 3040 4. 2 Ethernet Intel PRO/1000 PT(XT) [возможно PF или XF ибо есть куда воткнуться оптикой] на счет PT опять же не уверен есть ли поддержка в freeBSD 7.x кто знает - подскажите плз. 5. Память Corsar 2 планки по 1GB Внешние карточки для перестраховки если вдруг интегрированные всетаки не справятся по какой-то причине. Работать будет под FreeBSD 7.0-RELEASE посоветуйте плз. что юзать для шейпинга, натирования, формирования netflow пакетов. BGP будем на quagga крутить, может кто знает лучшую альтернативу?

если железяке не надо разбираться с тегами и не надо управления от неё - то практически любой "тупой" свитчек - они почти все на данный момент идут с размером окна для пропуска тегированного пакета :) мы пользуем "тупые" планеты FSD-803 они пропускают "таг" без проблем.

чет както смущают интегрированные карточки....

обычно пару mac-ip мало кто из пользователей додумывается сменить ;) а если додумается - то понятное дело в неуправляемой сети ничего не поможет :) в пн. буду на работе - подготовлю архив и скину ;)

неочень много :) недельку наверное ;)

Так сказать: "проходя мимо" :) Поскольку у нас роутингом локалки занимается Huawei а не софт-роутер, то соответственно трабла со сменой ip не решалась установкой ipguard :( Вопсчем написал софтину - которая по snmp v3 опрашивает Huawei и собирает с него arp таблицу, сравнивает текущую с сохраненной ранее таблицей в MySQL и делает следующее: 1. Если из пары ip-mac ни ip ни mac еще не встречались в других парах - то естественно длбавляет эту пару как новую запись в мускул. 2. Если mac из пары ip-mac уже был замечен в связке с другим ip - то скидывает эту запись в отдельную таблицу мускула (завется diff), и добавляется событие о захвате mac-ом чужого ip. 3. Если ip из пары уже был замечен в другой связке - тупо не реагирует (сначала реагировала, однако как показала практика это событие и нафиг не надо :) ) 4. Если mac из пары находился в таблице "diff" и теперь появился в связке со своим "основным" ip - то он убирается из diff и добавляется событие о возврате macа на родной ip. 5. Если имеется более 5 записей mac-ip с одинаковым mac-ом - считаем это трояном с arp-spoofing и заносим его в таблицу вирусников паралельно запуская pl скрипт с передачей ему mac-a вирусника, скрипт в свою очередь идет по telnet на huawei и добавляет запись в acl вирусников, который навешивает на все интерфейсы. Кроме того по возникновению данного события отсылается e-mail админу с mac-ом вирусника. Также есть таблица в которой хранятся пары ip-mac, смены между которыми надо просто игнорировать (вариант когда 2ip на одном интерфейсе висят алиасом). Ко всему этому добру есть веб-морда в которой ясно видны все съезды/переезды ip по mac-ам и вирусники с возможностью их разблокировки. Откомпилено это все на FreeBSD, впринципе использовался чистый си + net-snmp библиотеки - поидеи должна компилиться на любой *nix платформе. Поскольку для опроса arp таблицы используются стандартные snmp mib - то теоретически способна работать с любой железякой поддержующей эти самые mib.... И скрипт блокировки/разблокировки вирусников также можно переписать для работы с любой железкой. Еще раз повторюсь - что это решение было сделано для работы с аппаратным роутером ибо для софтварного итак есть прекрасные проги :)

Итак, давайте попробуем подвести итоги :) В нашем случае есть смысл ставить софтовый роутер ибо со слов jab с такой нагрузкой вполне справится роутер под правильно настроенной FreeBSD. Однако нам так и не удалось ответить на 2 вопроса: 1. Какое железо брать для софтварного роутера (мать, проц, память, сетевые)? Наверное этот вопрос более всего адресован именно jab. 2. На каких нагрузках лучше уже переходить на аппаратное решение?