raven428

Куплю новый или б/у 3ware 9650SE-8LPML, можно без батарейки и проводов, но в рабочем состоянии. Предложения в ЛС.

здравствуйте. открывать новую тему для такого вопроса как-то шибко жирно, поэтому пишу сюда. ддосят в адрес одного из натов вот такими пакетами (кусок flow-report): # recn: ip-source-address*,ip-destination-address*,ip-source-port*,ip-destination-port*,ip-protocol*,ip-tos*,octets,packets 1.52.161.156,x.y.z.98,43444,80,17,0,514,1 1.52.161.156,x.y.z.98,45842,80,17,0,514,1 1.52.161.156,x.y.z.98,46869,80,17,0,508,1 1.52.161.156,x.y.z.98,52587,80,17,0,514,1 1.52.161.156,x.y.z.98,60538,80,17,0,526,1 1.52.161.225,x.y.z.98,32994,80,17,0,526,1 1.52.161.225,x.y.z.98,35435,80,17,0,455,1 обратных адресов много, больше 100к. оператор маленький, входящий канал тоже. его успешно забивают так, что bgp прыгает вверх-вниз. может ли такое быть, что какой-нибудь абонент за этим натом какими-то действиями что-то инициирует и получает в ответ флуд? с порта 80 нат точно ничего не высылает наружу, т.е. инициация должна быть косвенная. другими словами, можно ли зафильтровать что-то исходящее, чтобы прекратить входящий флуд или не забивать голову и обращаться к аплинку за очисткой трафика?

радиус является частью биллинга, так что его так просто не сменить. через ssh поменять всё получилось, спасибо. а вот цитату про "EAP-MD5, EAP-GTC, EAP-OTP, and EAP-MSCHAPV2" не понял. слова, конечно, знакомые, а вот смысл неясен: если я таким способом в боевой сети буду на этих устройствах использовать EAP-MD5, то чем это может обернуться в плохом смысле этого слова?

есть Ubiquiti NanoBridge M2. хочется беспроводные подключения авторизовать в радиусе по 802.1х, но радиус умеет только md5 авторизацию (тип 5), которая, к слову, успешно работает у нас со свичами zyxel и dlink по 802.1х. ubnt шлёт в радиус авторизацию tls (тип 19) и получает от радиуса отлупы. как сделать, чтобы ubnt слал в радиус md5?

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

перезалил сюда. сейчас видно?

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

здравствуйте. в FreeBSD 7 номера пайпов можно было делать до 2млрд, а в FreeBSD 8 стало можно только до 65535. можно ли это вернуть до 2млрд, подкрутив размер переменной в исходниках ядра? если да, то что нужно крутить? может быть кто-то знает. спасибо.

"таймеры отложенных прерываний вернуть для эксперементов в дефолт." - это что? "natd выкинуть, заменить на pfnat". где вы увидели natd? я пробовал схему с ng_nat, и ipfw nat работает примерно в полтора раза быстрей, я это проверил на практике. hw.em.rxd и hw.em.txd в sysctl нет. давно они появились?

сейчас 60-80 мегабит, весь проходит через нат. не натовый трафик я пустил мимо неё.

может быть ещё подскажите, что нужно предпринять в ipfw, чтобы в этих сотне с лишним натов не забивались таблицы. например, чтобы было, скажем, по 200-300 записей на один серый адрес и остальное всё "забывалось"? или может быть ещё какие-то ограничения сделать?

вы будете смеяться, но с ipfw nat работает примерно в полтора раза быстрей, чем с ng_nat. да, и ipfw nat и natd - это всё таки разные вещи, хоть и работают в одном месте.

здравствуйте. посоветуйте, что покрутить для уменьшения нагрузки на "swi1: net" и увеличить производительность, а значит и размер полосы, которую он может отнатить. вот конфиги: # -- [r00] 8 marta 108 - 01 natd2_enable="YES" natd2_alias="92.43.185.2" natd2_network="10.72.21.0/24" natd2_port="8702" ... (повторяем 118 раз) ... # -- [r30] agal 46 - 05 natd118_enable="YES" natd118_alias="92.43.185.118" natd118_network="10.72.217.0/24" natd118_port="8818" $fwcmd table 2 flush $fwcmd table 3 flush for nat in ${nats}; do natd_port="$(eval echo \${${nat}_port})" natd_alias="$(eval echo \${${nat}_alias})" natd_network="$(eval echo \${${nat}_network})" $fwcmd nat $natd_port config ip $natd_alias deny_in reset same_ports natd_port1=$natd_port $fwcmd table 2 add $natd_network $natd_port1 $fwcmd table 3 add $natd_alias $natd_port1 done for oif in ${oiflist}; do $fwcmd add 2000 nat tablearg all from any to table\(3\) in via ${oif} $fwcmd add 2000 nat tablearg all from table\(2\) to any out via ${oif} done ещё в файерволе есть ещё около 170 всяких deny/allow и пайпы. загрузка этого роутера на 60 мегабитах около 60-65% в "sw1: net" ну и остальное по мелочи. работает он на xeon e5410, два гига памяти, гиг всегда свободен. /etc/sysctl.conf: security.jail.allow_raw_sockets=1 kern.maxfiles=40000 net.inet.ip.fw.one_pass=0 dev.em.0.rx_int_delay=1500 dev.em.0.tx_int_delay=1500 dev.em.0.rx_abs_int_delay=2000 dev.em.0.tx_abs_int_delay=2000 dev.em.1.rx_int_delay=1500 dev.em.1.tx_int_delay=1500 dev.em.1.rx_abs_int_delay=2000 dev.em.1.tx_abs_int_delay=2000 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.intr_queue_maxlen=256 net.graph.maxdgram=81920 net.graph.recvspace=81920 net.inet.ip.dummynet.io_fast=1 net.isr.direct=0 если убрать net.isr.direct=0, то роутер начинает произвольно перегружаться кернел паниками, видимых причин я не обнаружил. /boot/loader.conf autoboot_delay="1" geom_mirror_load="YES" geom_journal_load="YES" if_tap_load="YES" ng_ipfw_load="YES" ipfw_nat_load="YES" kern.maxusers="2048" net.graph.maxalloc=4096 kern.ipc.maxpipekva=32000000

решение: увеличить NAT_BUF_LEN в /usr/src/sys/netinet/ip_fw.h и пересобрать ядро.

flow-report всё хорошо умеет делать, но не в рилтайме и хорошо жрёт цпу. поэтому у нас детализация трафика стоит 50р за час детализации, чтобы у абонента не было желания страдать фигнёй.