digim

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

тоесть после замены тех 50 на 10 все стало в шоколаде?

максимальный буфер для приема пакета, с учетом максимального МТУ+запас, причем тут переполнение? вот бы автора диверта сюда...

имхо это ты в диверте лишнего надивертил надо не забывать что пакет попадает в фаервол на каждом интерфейсе, плюс ко всему можно задавать уточняющие директивы in out recv xmit для более точной ловли пакетов в нужных местах, и по идее если просто указать from any to any то в системе с двумя сетевухами он может 4 раза посчитать один и тот же трафик. так что курите маны по ипфв, он клевый и вполне этого заслуживает.

кто бы сомневался...а под freebsd?

Хм. Как-то странно. На athlon xp 2500+ и пользователь один? А железо не глючное?... пользователь один, закачка в один поток, чем проверить глючность железа? железо работает 24x7 и других глюков за ним незамечено. мать abit NF7, вторая сетевуха - intel 82559, больше там ничего нет.

у меня на 6.2prerelease без шейпинга и очередей на athlon xp 2500+ и встроенной в чипсет сетевухе от нвидиа из 700мег посчиталось 200 на bpf считалке и успевало около 1 мега на диверте прежде чем сеть отваливалась. пользователь был один

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

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

а зачем мусорить в системе дубликатами пакетов? еще неизвестно какие после этого можно поиметь дополнительные глюки(я про tee) я уже адаптирую под свои нужды другое решение, жаль что эксперимент с СТГ неудался, по простоте развертывания он мне подходит, но видать не за теми зайцами надо гнаться...

зачем платить 25 баксов за нетфлоу от старгейзера если есть более другие рабочие решения(netams, abills), тем более что у нетфлоу своя специфика и он подходит далеко не всем. да и общая волна у СТГ какая-то неработоспособная, нетфлоу то не косячит случаем?

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

Т.е. как правильно должно быть?? У меня 3 интерфейса: внутренний(em0), контент-сервера(em1) и внешний(fxp0). Нужно считать внутренний трафик, трафик с контент-серверов и инет-трафик. Соответственно 3 направления указаны в rules У меня сейчас так: <Module cap_divert> iface = em0 15701 </Module> т.е. пытаюсь собирать всё, что в итоге идёт внутрь сети.. Что значит - "..для каждого направления должен быть свой порт.." ? Как тогда должна выглядеть секция описания модуля? вот попробуй ради интереса укажи другой порт и посмотри что будет в тво

есть, но там ни слова про диверт

так вот - поковырявшись в исходниках выяснилось что текущий код документации не соответствует совершенно. то что указано в http://www.stargazer.dp.ua/doc20/conf_divert.html просто не будет работать на диверт-портах отличных от 15701, для задания порта оказывается используется директива Port в секции конфигурации cap_divert. и похоже никакого намека на то что для каждого направления должен быть свой порт хотя чему удивляться - документации под 2.4 на сайте до сих пор нет. но даже с учетом этого диверт как следует у меня не заработал...