boco

интересно, кто раньше загнется от трафика - суды или фильтровалки реестра? =)

действительно, проверил на нашем - тоже отдает text/plain. вероятно, это сделано с целью помешать автоматическому определению видеоконтента (неважно, для целей блокирования или наоборот, записи на диск).

а что такое групповой нат? =)

можно пример запроса и ответа?

на 1000 абонентов? эмпирически на тарифах до 100 mbit - два r1304b + mpd. цена вопроса меньше 2 штук баксов. без шуток. аппаратных pptp не бывает. мое мнение - в плане терминации pptp/l2tp конкурентов у mpd нет.

зачем? многовато, на мой взгляд. вы же сами пишете, что у вас сервер ложится от входящих syn. все верно. чем плох same ports? вообще, конечно, дело ваше. но я бы попробовал. у меня с такими настройками ната фряха тащила 5 гбит входящего трафика на обычном e3-1240. линукс тащит больше. и, кстати, over9000 ядер совсем не гарантируют over9000 производительность ната. скорее, наоборот.

я же показал в посте: ipfw nat 3111 config igb0 ip 31.163.206.111 ipfw add nat 3111 ip from any to 31.163.206.111 in recv vlan158 ipfw add nat 3111 ip from 10.1.10.40 to any out xmit vlan158 в посте пример, а я просил актуальный конфиг. это весь фаервол? и у вас реально абоненты натятся в over 3000 белых ипов (судя по номеру нат-инстанса)? в общем, попробуйте примерно так: firewall.conf fw='/sbin/ipfw -q' # flush rules ${fw} -f flush # skip out ${fw} add 100 skipto 400 all from any to any out # in ${fw} add 200 nat tablearg all from any to table\(2\) ${fw} add 300 pass all from any to any # out ${fw} add 400 nat tablearg all from table\(1\) to any ${fw} add 500 pass all from any to any а нат примерно так: $ipfw nat $count config ip $natip deny_in same_ports reset

покажите конфигурацию фаервола и ната.

не, вроде первый. до этого был "технический сбой" =) ps. уже удалили. прям на глазах, пока копировал урл из реестра в их проверочную форму

ретрансмит - это да, косяк. http://www.freebsd.org/cgi/query-pr.cgi?pr=154842, только в фиксе, как я понял, обошлись memset'ом: if (h->out[POS_CODE] != RAD_ACCESS_REQUEST) { /* Insert the request authenticator into the request */ - insert_request_authenticator(h, h->srv); + memset(&h->out[POS_AUTH], 0, LEN_AUTH); + insert_request_authenticator(h, 0); } другой вопрос интереснее - почему mpd начинает сыпать этими ретрансмитами? возможно, фаервол блокирует acct-response от radius?

+ включите в mpd отладочные логи radius и, возможно, fsm

судя по top, у вас ix использует по 8 прерываний (intr{irq267: ix0:que }). попробуйте прибить их к 8 ядрам таким образом, чтобы первое прерывание ix0 и ix1 были на, скажем cpu0, второе прерывание ix0 и ix1 - на cpu1 и так далее. ps. я же говорил, что e3-1280 порвет эти два e5. =)

так вы не удалили из конфига "set radius config /usr/local/etc/mpd5/radius.conf" что ли?

а зачем такие странные значения таймаута и повторов (1812 1813)? насколько необходима опция "set radius enable message-authentic"? если нужды нет - попробуйте отключить.

неа, тоже не представляют. на первый взгляд, схема легко масштабируется горизонтально. проблему я вижу только с cdn, которые для разных регионов отдают по dns разные ip для одного и того же хостнейма. если ркн предполагает распространять в своем новом реестре кортежи "ip+url", то, очевидно, работать это будет только для одного региона. а фэйчить dns, согласно документу того же ркн - некошер =)

для гугла-то? не, не представляют =) http://en.wikipedia.org/wiki/Anycast

Смотря у кого, очень даже не копеечный есть, у тех у кого десятки гигабит. Можете написать сколько в максимуме можно пропустить, и на чем? вы не поняли. конкретно с хоста www.youtube.com - трафик копеечный. видео раздается совсем с других серверов. в проксировании видео потребности нет, проксировать надо только www.youtube.com (к слову, это всего один ip, одинаковый для всех клиентов по всему миру - очень удобно для обсуждаемой схемы блокирования)

насчет контрольной суммы не переживайте - все там нормально. можете отключить checksum offloading с помощью ethtool и убедиться. я бы на вашем месте скапчурил эти пакеты с якобы неверным секретом и проверил вручную, правда это или фрирадиус врет.

а следующим - выпуск специализированного детского браузера. и пусть родители ставят свом чадам этот браузер в добровольном порядке. решает вообще все проблемы описанные как нерешаемые. =) с www.youtube.com трафик копеечный, все он прожует.

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

jfyi http://svnweb.freebsd.org/base?view=revision&revision=249848 может быть, вам тоже поможет...

http://top.rbc.ru/society/13/05/2013/857360.shtml?print смешно...

хм. у меня совершенно противоположное впечатление сложилось. правда немного цепанули его дифирамбы закону, но о мертвых можно только так: или хорошо, или ничего =)

эээ... я не знаю, что вам нужно. мне нужна была версия с выпиленным route cache. это 3.6 и выше. взял самое свежее из 3.6.

отсюда: http://kernel.ubuntu.com/~kernel-ppa/mainline/