Vladimir Опубликовано 7 октября, 2004 · Жалоба тогда и коллектор нафиг не нужен, берем iptables, считаем, аггрегируем, льем в базу и ждем, что клиент раскричится, а мы ему если что, этот трафик простим Кста, эксперименты с iptables показали, что при 6-7 тысячах правил и приличном трафике загрузка проца на 2 ГГц P4 уже непотребная... а если так ... 2000 клиентов обслуживаются на 15 маршрутизаторах соответственно, на каждом - максимум 300 клиентов на каждого из 300 клиентов на каждом маршрутизаторе стратегия такая: изначально закрыто все всем кроме icmp, кроме внутреннего веб-сервера и пптп-порта на маршрутизаторе клиент идет на пптп авторизуется если все ок: 1. включаем локалку 2. включаем правило подсчета на лок. сеть (одна цепочка - вход, другая - выход) 3. включаем шейпер на его ip адрес периодически дампим его лок трафик клиент отвалился по таймауту или прервал работу: 1. выключаем ему локалку 2. выключаем правила для подсчета лок трафика 3. выключаем шейпер 4. дампим его интернет-трафик (одной записью) значит: 1. правил еще меньше, так как они создаются/закрываются динамически в зависимости от работающих одновременно клиентов, и нагрузка на терминатор еще меньше НО - не слишком сложная схема ? тогда нафиг нетфлоу - интернет-трафик считаем по сессиям, а локальный - дампами цепочек Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sultan Опубликовано 7 октября, 2004 · Жалоба Для линукса ядерных решений нет. Варианты основаные на ipcains|iptables - не варианты. Хм. Весьма категорично. iptables QUEUE - считает с точностью до байта, ничего не теряя как ULOG... На стендовом iP-200MMX с двумя realtek'ами дает до 75Мбит/с посчитанных и записанных в логи. Эта же машина без считалки дает до 83 Мбит/с. Считалось NetPIPE_3.5. pps хотя бы при 64-байтных пакетах? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 7 октября, 2004 · Жалоба я тут уже копаюсь с flow-toolsвопрос следующий - как я вижу, при построении грамотной системы желательно разделить механизм подсчета трафика таким образом: несколько NAS (только терминирование клиентов + netflow), отдельный радиус-сервер, отдельный биллинг-сервер, отдельный коллектор трафика Только что закончил востановления системы подсчета тарфика. умер винт на коллекторе онже и систмеа посчета с вебной мордой, в общем все поломалось Мои соображения Коллекторов как можно больше (но больше 2 потоков от маршрутизатора не получиться), то есть 2 коллектора, от коллекторов сохранять файлики с нужной агрегацией, потом можно либо редирект либо на билинговую систему. Файлики лучьше сохранять так что потом их млжно было в билинговую систему засунуть. Трафик нет флов юдипишный, так что прерывов в работе коллекторов не рекомендутся (потеря статистики в зависимости от активности клиентов) А остальное по вкусу, радиусов тоже бы рекомедовал несколько, защита не только от падения радиуса он и время авторизации можно уменьшить, если первый радус очень занят то на следующий запрос уйдет в принципе все можно задублировать вопрос только в цене Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 7 октября, 2004 · Жалоба pps хотя бы при 64-байтных пакетах? Стенд сейчас под другое задействован, попробовал на живом участке... В общей сложности получилось 400 Kpps, из них 70 Кpps - ftp, остальное мои издевательства 64-байтными пакетами. Старый участок на rtl8139, никакого polling'а ессно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaiser Опубликовано 8 октября, 2004 · Жалоба Гость, получилось 400 Kpps, из них 70 Кpps - ftp ну не верю, и все тут. даже если на порядок уменьшить - все-равно не верю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 8 октября, 2004 · Жалоба ну не верю, и все тут. даже если на порядок уменьшить - все-равно не верю. И правильно... Ночью спать надо, а не сетку пакетами мучить... это не Kpps, а Kppm ;) На 60 делить надо :) Сорри... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...