Подсчет и учет нескольких гигабит трафика

Вопрос. А чем сейчас трафик считают?

Объемы не самые маленькие - около 5-6 гигабит?

 

На данный момент трафик миррорится на узловой циске на TRAF-сервер.

На сервере freebsd  ipcad/ipacctd,  который собирает трафик скриптами его раскладывает и пишет данные по трафику в базу биллинга.

Проблема в том, что таких серверов уже 5 штук. Железо там далеко не новое, но и процы и сетевушки в полке.

Данная схема была успешной лет 10 назад. С тех пор у нас и существует. Но по моему сейчас уже неактуальна.

Есть желание как то оптимизировать сей процесс.

Если считать напрямую на BRAS-ах (у нас тазики на freebsd)  - растет нагрузка, тоже не вариант.

У кого как организован учет трафика для абонентов?

Как правильно?

P.S. сюда просьба не приплетать Яровую с ее пакетами. Вопрос чисто практический.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 минуты назад, Negator сказал:

У кого как организован учет трафика для абонентов?

Netflow/sflow/radius accounting.

 

Со СКАТ-а, например, netflow весьма удобно собирать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо, ставить СКАТ пока предлагать не нужно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, snvoronkov сказал:

Netflow/sflow/radius accounting.

 

 

И какая производительность?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 Если коллекторы под FreeBSD, наименее нагружный способ с ipwf tee, сливаемый во флоу локально , затем или по фтп по крону в учёт. ipcad кстати много не кушает

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я снимаю счётчики с портов доступа по snmp.

Нагрузка, очевидно, практически нулевая.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для чего считать?

Если просто для общего представления, то SNMP достаточно.

Если для учёта, то netflow или радиус-аккаунтинг. Правда не думал, что до сих пор остались тарифы с оплатой трафика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Снимаем для учета, для отписок органам. Регулярно шлют кто куда и когда ходил.

Реальников мало, NAT, поэтому трафик нужен.

Тарифов по трафику конечно нет давно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кто и куда ходил - вроде бы это незаконно собирать. Это прерогатива спец.служб и правоохранительных органов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, Negator сказал:

И какая производительность?

Производительность чего? Скат в одно лицо и трафик фильтрует, и флоу скидывает на сервак на фряке. Там  софтина его считает по абонентам раз в 10 минут. Сбор флоу - константная нагрузка в 5% одного ядра старого оптерона, обсчет - секунд 10-20. Тоже на одном ядре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Есть тарифы с лимитом трафика - например, 10 гиг в сутки, далее режется скорость до полуночи.

Тарифов именно с оплатой трафика давно нет, конечно.

 

А что до органов - я не сталкивался с запросами "куда ходил". Вообще ни разу за всю историю.

Все запросы были из серии "вычислить по ипу".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
22 часа назад, Negator сказал:

 

del

Изменено пользователем ichthyandr

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 час назад, Negator сказал:

Снимаем для учета, для отписок органам. Регулярно шлют кто куда и когда ходил.

Реальников мало, NAT, поэтому трафик нужен.

Тарифов по трафику конечно нет давно.

 

 Для того, чтобы уменьшить объем и облегчить работу коллектора, я помощью правильного ipfw загоняю в tee только нужный трафик, тот что для разборок надобен, торренты  и флуд клиентский - тоже не загоняю в коллектор. Сначала писал всё - ipcad съедал одно ядро полностью иногда. Причём для разборок иногда нужен только куда клиент ходил по http/https и когда. Ответы оттуда тоже можно писать, исключительно для разборок с клиентами, но в рабочее время проще trafshow онлайн посмотреть, чтобы сказать чем их канал выеден.

 

17 часов назад, rdc сказал:

А что до органов - я не сталкивался с запросами "куда ходил". Вообще ни разу за всю историю.

Все запросы были из серии "вычислить по ипу".

 По IP ната ? А так - 50% запросов от прочих правоохранителей - именно кто и когда посещал какой-либо ресурс, банковский там или майлвру. Ну редко - форум какой-либо. Остальные - типа тут подземный стук, сообщите, кто стучал... Или вот серийный номер спёртого ноутбука - не светился ли он у вас :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Запросы в основном вида кто посещал мейл.ру тогда то. Ну и IP.

А у нас там NAT.

Вот и приходится лазить в трафик и сообщать органам информацию.

Ну и посмотреть был ли трафик у абонента и сколько тоже бывает полезно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
14 часов назад, Negator сказал:

Запросы в основном вида кто посещал мейл.ру тогда то. Ну и IP.

А у нас там NAT.

Вот и приходится лазить в трафик и сообщать органам информацию.

Ну и посмотреть был ли трафик у абонента и сколько тоже бывает полезно.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да у нас все то же самое. Разве что за НАТ-ом не сотни, а десятки. Запросы кривые, у того же майлру адресов обычно много, посылаю уточнять, регулярно отказываю.

Вот и думаю - есть ли вообще смысл собирать этот трафик?

Может с порта доступа собирать количество? Исключительно для статистики и разборок с абонентами.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 27.09.2017 в 16:49, YuryD сказал:

 Для того, чтобы уменьшить объем и облегчить работу коллектора, я помощью правильного ipfw загоняю в tee только нужный трафик, тот что для разборок надобен, торренты  и флуд клиентский - тоже не загоняю в коллектор. Сначала писал всё - ipcad съедал одно ядро полностью иногда. Причём для разборок иногда нужен только куда клиент ходил по http/https и когда. Ответы оттуда тоже можно писать, исключительно для разборок с клиентами, но в рабочее время проще trafshow онлайн посмотреть, чтобы сказать чем их канал выеден.

 

А не поделитесь какой трафик нужный?

Есть желание миррорить на цисках только его и загонять на сервак подсчета трафика.

 

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

Хотя по закону должны вроде сохранять инфу кто куда когда ходил.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, Negator сказал:

Есть желание миррорить на цисках только его и загонять на сервак подсчета трафика.

 

 Мои киски миррорят порты целиком :( Как прикрутить фильтры к flow-tools не пробовал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 04.10.2017 в 13:49, Negator сказал:

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

я вам еще более дорогой вариант скажу, но вдруг у вас эта железка завалялась ))

cisco sce8000, сливает инфу о трафике хоть в нетфлоу, хоть в собственном формате RDR, причем у этого формата огромное преимущество перед нетфлоу - данные льются уже сагрегированные (причем не только "ip-port-bytes", но и URL и еще куча ненужностей). ~5 лет назад с обработкой RDR с трафика в 3-4 гигабита (или даже больше) без проблем справлялся древний даже по тем временам сервер.

сейчас принимаемую с SCE инфу о 1,5+ гбитах трафика нормально лопатит скромная виртуалка с двумя ядрами от E5620.

Изменено пользователем nixx

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти