Max

2.016.7.6 RC-3

вот вам и ответ: Aug 10 19:57:09 localhost stargazer: [b]User ' root^I' not found in system.[/b] Aug 10 19:57:09 localhost stargazer: [b]Group ' root' not found in system.[/b] Aug 10 19:57:09 localhost stargazer: [b]Error in file /etc/stargazer/stargazer.conf, line 115[/b]

Вопрос к автору, вчера в логе появилось: not well-formed (invalid token) 2006-08-10 20:06:29 -- Parse error at line 1: not well-formed (invalid token) 2006-08-10 20:06:37 -- Parse error at line 1: not well-formed (invalid token) 2006-08-10 20:06:41 -- Parse error at line 1: not well-formed (invalid token) 2006-08-10 20:06:44 -- Parse error at line 1: not well-formed (invalid token) 2006-08-10 20:06:46 -- Parse error at line 1: not well-formed (invalid token) 2006-08-10 20:06:48 -- Parse error at line 1: not well-formed (invalid token) 2006-08-10 20:06:51 -- Parse error at line 1: no

что то я про такой косяк первый раз слышу...

енто в ТЗ уже было указано

попробуйте указать логин в кавычках

или ставить стг-2.4 там говорят это умеют

так он вроде показал...

Собственно всё, стабильный продукт получен (mod_netflow.tar), кому интересно обращайтесь.

покажите ваши скрипты onconnect и ondisconnect

качаешь архив, далее tar -zxf sgauth.2.12.6 cd ./sgauth.2.12.6 make ./sgauth <server> <port> <login> <password> Что тут такого?

скорее всего не правильно указан интерфес на котором надо вести учёт трафика.

фенкс, учту.

ee /usr/local/etc/rc.d/stargazer.sh #!/bin/sh stargazer echo "Now Stargazer Started!"

Ой как плохо....в нашей сфере это сильно плохо.... Но это особенность протокола Netflow v.5 а не модуля, я тут ничего поделать не могу.

Впн модуль нужен для двух вещей, во-первых: он должен реализовывать функции радиус сервера (иметь такой же интерфейс (API еслихотите)) для внешних клиентов, таких как mpd, PPTPD,pppd,pppoed. А во-вторых: иметь возможность собирать статистику с данных клиенто, тоесть получается полноценный сервер радиуса с возможностью доступа к базе СТГ, пока такого нет, от сюда вывод: необходимо написать модуль который был бы прослойкой между уже существующим радиусом (FreeRadius например) (так как писать свой радиус геморно, да и кросплатформенность потеряется, так сделал Netup, у них свой радиус.) и стг. Да

А вот и схема:http://stg-tarif.narod.ru/shema_new.JPG Собственно описание: Случай 1. (Цыска 2620 умеющая нетфлоу): У цыски есть аппаратный модуль который генерит нетфлоу поток, но так как стандарт посессионный то он отправит инфу о трафике только по закрытии сессии пользователем по протоколу UDP на колектор - что не гарантирует доставку статистики до биллинга. Решили исправить данный недостаток, но об этом чуть позже. Случай 2. (Сервер доступа Ос FreeBSD/Linux): Так как это оси то под них есть куча сенсоров (программа для сбора статистики, превоащения её в формат netflow v.5 и отправки

сдесь дело не в модуле netflow, а в сенсоре именно он собирает статистику, и отправляет её на колектор/модуль стг, а так как спецификация протола netflow v.5 описывает по сессионную реализацию то и информацию о пройденом трафике СЕНСОР (а это может быть любая программа умеющая это делать) собирает по сессиям и отправялет на коллектор. А не постоянно шлёт инфу на колектор о проходящем трафике. На счёт алив пакетов: такого в стандарте не предусмотрено, я думаю. Хотя спрошу у программиста. Вобщем счас нарисую схему для тех кто не понял.

Теперь програмер задолбается это исправлять :argh: !

ну я бы не стал всё так драматизировать, поголовное число лицензированных провайдеров считают именно по netflow снимая статистику с cisco, и ничего прекрасно живут и считают.

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

И так время идёт, а развитие билинга идёт очень медленно (это не вкоем случае не в укор автора я прекрасно понимаю что билинг бесплатный и требовать или настаивать на чём что никто не имеет права), но сеть разрастается и требуются новые решения промышленного масштаба (не скриптами, а в коробочной версии), по этому после удачной рализации модуля stg-2.4+ netflow_cap.so пишу тех задание для програмера на исправление текущих ошибок и разных фитч. Я описываю недостатки версии сервера 2.0.16.7.6 и конфигуратора 1.60.7, но исправления будут вноситься исключительно в версию 2.4+ ################

хорошие новости, 4.08.2006 будет закончен модуль netflow_cap.so для стг-2.4+ Данный модуль прошёл стрессовое тестирование на трёх серверах под управлением OC FreeBSD 4.9 & FreeBSD 5.4, а так же на линуксе RHEL. Подсчёт ведётся очень точно! Единственный минус выявленный в процессе эксплуатации это то ограничение технологии NETFLOW, как известно протокол нетфлоу посессионный, а именно: поток нетфлоу с сенсора сбрасывается на коллектор только после завершения сессии (закачки)! Это значит что если кто то начал качать 600 метров то билинг узнает об этом только после скачивания этого объёма тр

http://local.com.ua/?op=39&st=2&dwnld=1143205566

про пинг: перепустить пробовали, иногда помогает.... про левый трафик: преведите к следующему виду ваш рулес: # noping ICMP 0.0.0.0/0 NULL # no local traffic ALL 127.0.0.1/32 NULL # no TCP/UDP from server ALL 192.168.0.0/24 NULL ALL 192.168.200.190/32 NULL # mail ALL mailserver.net/32 DIR0 # last ALL 0.0.0.0/0 DIR1