У провайдера на 67% больше трафика насчитывается чем в WinXP

Хм, сообщение толи пропало, то ли модератор его стер (причины для удаления, впрочем, не вижу). дубль два:

Pine, поделитесь логами на alienhard сапака mail.ru, возможно, у меня будут какие-то идеи.

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

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

[Сообщение изменено пользователем 19.09.2004 11:13]

Да забудьте Вы про эту блуду :-d Все велосипеды уже изобретены. Вот более менее нормальная программа работающая с логами http://www.internetaccessmonitor.ru/rus/products/i...
Internet Access Monitor - анализатор логов для всех популярных прокси серверов Программа для контроля эффективности использования Интернет-канала Вашей организации. Позволяет отслеживать кто, когда, куда, откуда и зачем выходил в Интернет. Были и у ней косяки, по крайней мере год назад были с anonimusами. Её только надо ставить к выньруту или ИСЕ.
Вот её конкурент http://www.advsoft.ru/ru/products/proxyinspector/
Эта намного лучше, но таблеток к ней не найдёте :-d

Ага.

Кстати, у релкома внешка 2.25 руб\Мб стоит, наверное, это за счет обмана клиентов на 5 процентов достигается :-d

Бред какойто. Если Вы настраивали нетап, то в курсе наверное, что надо быть полным идиотом, чтоб наоборот подсчет трафика настроить.

:-d :-d :-d

Давайте маленьку разминку для ума... Пусть есть два клиента, подключенных к разным аплинкам (естественно, через разные роутеры). Трафик идет от одного клиента к другому. Как правильно настроить обсчет этого трафика в нетапе, чтобы одному клиенту он был исходящим, а второму - входящим?

сетка отправителя в сетка получателя

Ы? Они оба отправители и оба получатели. И надо, чтобы трафик у обоих правильно считался.

> set q=mx
> delnet.ru
Server: 213.242.199.177
Address: 213.242.199.177#53

delnet.ru mail exchanger = 2 ns4.delnet.ru.
delnet.ru mail exchanger = 1 ns2.delnet.ru.
>
пристал :-) это резерв... помог бы лучше spamassasin настроить за вознаграждение ессно

[Сообщение изменено пользователем 20.09.2004 03:04]

дак 2 строчки и пиши с одной в другую такой то трафик, город типа, с другой в одну можешь написать супервнешка... Если это с одного оператора ходят, то меж ними ваще локальный трафик будет, смотря какая политика. Если б они за одним роутером сидели, тады б ваще не было статистики, как у pine в логах. Сосед его долбит по 139 порту. У него в логах есть, у меня нет :-)
Вы меня экзаменуете что ли? :-)

Канефна. А вот правильный ответ: в UTM в силу их ущербной концепции реализовать требуемое вообще невозможно.

Когда и адрес источника, и адрес назначения принадлежат клиентам, UTM оказывается перед выбором, к какому из клиентов его приписать, к тому, который src или к тому, который dst. Каждый пакет классифицирован либо как "входящий", либо как "исходящий". Если приписывать всегда к тому, который dst, то мы посчитаем исходящий не тому клиенту, а если к тому, который src - то не тому клиенту посчитается входящий.

Delnet, в простейшей схеме запутались. А если сюда еще и бесплатные-внутригород-внешку навесить, да разную стоимость?

В общем, жду логов от Pine.

[Сообщение изменено пользователем 19.09.2004 12:45]

:-d :-d :-d Не кажется ли Вам, что тут обсуждается не проблема pine, а бсуждение софта? Лучше софт обсуждать на форумах разработчиков :-) . И если правильно настроенный сертифицированный софт имеет какие то погрешности, то при чем тут провайдер? Кинуться искать другой софт? Идеальных не бывает, кроме самописных. Потом докажи тому же клиенту, что ты не верблюд, если писал сам. Будут конкретные решения, пишите письма.

[Сообщение изменено пользователем 19.09.2004 14:24]

гы, лол.

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

В настройках тарификации, раздел тарификация/классы трафика вводятся параметры сети отправителя и сети получателя. Если пользователи находятся в разных сетях, исходящий трафик одного будет входящим для другого и наоборот.

Ось UNIX, LINUX или BSD не может перепутать входящие или исходящие пакеты с байтиками, коллектор собирает статистику и передает его UTM, а UTM не выбирает, а четко заполняет таблицы, по типу что сказали, то и делаю.

Пользователи "А" и "Б" У пользователя "А" IP-адрес 213.80.56.5/32, у "Б" 217.234.45.6/32.
В UTM с коллектора поступит следующая информация:
src...........................dst.............................объем
195.34.35.36........213.80.56.5..............10 мб
195.34.35.36........217.234.45.6............15 мб
213.80.56.5...........217.234.45.6............20 мб
217.234.45.6.........213.80.56.5..............30 мб

UTM припишет как входящий трафик для "А" 10+30
для "Б" 15+20, аналогично исходящий.

Не вводите юзеров в заблуждение. Это написано им, а не ВАМ :-d

С уважением, Валерий.

[Сообщение изменено пользователем 20.09.2004 03:32]

Я - точно "чайник", т.е. ламер мастдайный:-) :-) :-) (с 13 лет за компом, счас 34)
но вот сижу в аське часа по 4-5 (не сильно много то и передают текста, по передаче пакетов смотрю), пару раз на свой любимый майл.ру за 3 письмами залезу. 80 р. херакс! Я может чего не понимаю? FireWall стоит как башня:-) Спорить с провайдером - сил нет, они такими вумными словами отшиваются или ващщщщщщще не желают разговаривать с лицом диаметрального пола (то бишь женского). Мальчики, подскажите, сильная Вы наша половина человечества, защитите хрупкое создание:-)

Увы, проблема кривой концепции UTM, не позволяющей корректно учитывать исходящий и входящий трафк от клиента к клиенту, обсуждалась в их форуме и подтверждена дядей Абылаем (так зовут разработчика). Т.ч. тут имеет место лишь Ваше непонимание принципов работы используемоего у Вас биллинга, собственно поэтому я и просил у Pine логи - проверить, не вызвало ли это непонимание некорректную настройку оного. К вечеру выделю время, проанализирую то, что он мне прислал, и скажу, если будут какие-то мысли.

[Сообщение изменено пользователем 20.09.2004 12:20]

buggzy, не вводи никого в заблуждение. на одном форуме ты уже доказал, что очень умный. Все это и так уже поняли.
Даже хорошо написаная прога в кривых руках - и мы имеем закономерный результат.
Прежде чем сказать "какой я умный, а у них все криво" неплохо задуматься на тему на самом ли деле это так.

Разработчики UTM считают, что это так. Хотя если пользователи считают иначе, все ОК. До первого недовольного клиента.

Убедительно прошу левый народ не лезть не в свою область :-)

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


Сразу видно, что ты "программист" - как любишь себя называть. Любой компании, которая занимается провайдингом, нет смысла "обсчитывать" клиентов по трафику, если они на что то претендуют большее, чем имеют. Это законы бизнеса, имхо.

http://netup.ru/phorum/viewthread.php?tid=1962



Чтобы Вам не перенапрягаться, перевожу: если трафик идет от одного клиента к другому, считается только входящий трафик, исходящий у обоих будет 0. Провайдеры, у которых тарифы с платным исходящим, нервно курят.

Уточнение... Описанная мной схема - для случая, когда коллектор только один. Когда их два, все еще хуже: либо исходящий насчитается не тому клиенту, которому надо, либо входящий насчитается вдвое больше, а исходящий будет 0.

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


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

Готов поспорить, что без труда найду кучу людей, которые в этом вообще ничего не увидят. Но они молчат, в отличие от ;-)

Про твой профессионализм я уже наслышан, о чем упоминал выше. В другом форуме ты отлично засветился.

Pine, увы, но выделенная желтым колонка из Ваших логов, подписанная как "получено", содержит статистику по отправленным данным. Это неплохо видно, например, если посмотреть трафик с хоста relay.mplik.ru порта 25, там в желтой колонке число больше в 30 раз, что характерно именно для отправляемых данных.

С данными биллинга не сверял, поскольку, полагаю, вопрос исчерпан.