_INF_ Опубликовано 1 апреля, 2013 · Жалоба есть почти 40 мбит нетфлоу потока с одной железки flow-capture из-за слабого проца не успевает все пережевать.. в результате в netstat вижу кучу пакетов в recvq, ну и что не влазит естественно дропается.. nfdump пока еще не развернул.. готовлюсь ) Есть у кого success story по принятию такого? Ставили i7 и 4 SATA винта (10k rpm) в raid0, прекрасно работало, обработка шла на этой же машине. Плохо то, что flow-capture задействует только одно ядро :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 1 апреля, 2013 (изменено) · Жалоба вот именно. процы конечно на машине с флоу капчер слабоватые, но nfdump (на тестовой машине) жует .. попробовал на x5670 там же где nfdump запустить флоу капчер ) в сотку сразу же улетело.. но вот чот файлы сильно здоровые у nfdump ( Изменено 1 апреля, 2013 пользователем zhenya` Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmx Опубликовано 12 апреля, 2013 (изменено) · Жалоба попробовал на x5670 там же где nfdump запустить флоу капчер ) в сотку сразу же улетело.. Гм. Вот я из любопытства решил посмотреть сколько этот наш коллектор сможет теоретически переработать нетфловов. Немолодой офисный писюк, Core2 Quad, на loopback интерфейсе. Физическими железками проверять лень, да и скорее всего порядок будет тот же. Проверял так: $ time flow-gen -V5 -n 10000000 | flow-send -x 10 -V5 0/127.0.0.1/9500 real 0m27.438s user 0m3.812s sys 0m3.908s Немного покрутил -x (xmit_delay), 10 дало где-то 170 мегабит. На такой скорости разброс потерь пакетов где-то от 0,1% до 0,7%. top показывает использование CPU: flow-send 24%, flow-gen 4%, xenoeye 12%. Это все кажется довольно логичным, там же нечему в CPU упираться, сплошной IO. Ну, разве что на каждый пакет несколько раз выделять/освобождать память и вызывать localtime. То есть если коллектор не умничает, минимально парсит пакет и складывает на диск, в CPU упереться не должно. Тем более, судя по тому что вы тут пишете, провайдерам нетфлов нужен больше для форс-мажора, отдать данные по IP-адресам за какое-то время. Предварительно просчитывать ничего не нужно, складывай себе и все. На всякий случай повторюсь: использовать в провайдерском хозяйстве на таких скоростях наш коллектор не очень осмысленно. Если бы нужда заставила хранить столько фловов только ради того чтоб отдавать IP-адреса и время, я бы скорее всего думал о какой-то агрегации, для такого часть информации не нужна, а все хранить - дисков не напасешься Изменено 12 апреля, 2013 пользователем vmx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 18 сентября, 2014 · Жалоба Подскажите как вам помочь? Могу предоставить файл с нат трансляциями и тд и тп . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmx Опубликовано 18 сентября, 2014 · Жалоба Подскажите как вам помочь? Могу предоставить файл с нат трансляциями и тд и тп . Ну, я даже слегка растерялся. Если хотите помочь, напишите что вас в программе не устраивает, какие встретились непонятные моменты и что нужно сделать еще. Мы все никак не можем выпустить очередную версию, еще отпускное настроение. Надеюсь скоро, но пока лучше брать версию из trunk В общем пишите что не так, как нужно правильно. Мы все постараемся осмыслить и учесть Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 18 сентября, 2014 · Жалоба Подскажите как вам помочь? Могу предоставить файл с нат трансляциями и тд и тп . Ну, я даже слегка растерялся. Если хотите помочь, напишите что вас в программе не устраивает, какие встретились непонятные моменты и что нужно сделать еще. Мы все никак не можем выпустить очередную версию, еще отпускное настроение. Надеюсь скоро, но пока лучше брать версию из trunk В общем пишите что не так, как нужно правильно. Мы все постараемся осмыслить и учесть Неплохо бы приделать фишки от v9 netflow именно видеть Натинги (в nfdump и в nfsene их можно смореть, однако тот же rrd меня там не очень устраивает ) - есть готовый pcap этого дела . Также как у вас сделать отчет чтобы как в nfsen общее потребление трафика по времени видеть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vmx Опубликовано 19 сентября, 2014 · Жалоба Неплохо бы приделать фишки от v9 netflow именно видеть Натинги (в nfdump и в nfsene их можно смореть, однако тот же rrd меня там не очень устраивает ) - есть готовый pcap этого дела . Также как у вас сделать отчет чтобы как в nfsen общее потребление трафика по времени видеть? Натинги это NSEL/NEL? Не уверен что мы сможем быстро это сделать. Мы вообще про Netflow v9 не сильно думали. Но присылайте конечно, будем думать. Прямо на xenoeye@xenoeye.com если небольшие образцы. Или выложите куда-то, а ссылку пришлете. Общее потребление трафика по времени - это что-то типа такого: http://xenoeye.com/extradl/tmp/dgr150414.png ? В trunk версии это есть, график можно зумить/скролить мышкой. Разбивку (это разноцветные столбики) можно делать по любому полю netflow(v5), протокол там, as и т.п. Или можно не делать. Мы даже сделали отчеты с автообновлением, но понятно что они показывают текущую ситуацию очень условно - когда сенсор решит отдать флов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 19 сентября, 2014 · Жалоба Неплохо бы приделать фишки от v9 netflow именно видеть Натинги (в nfdump и в nfsene их можно смореть, однако тот же rrd меня там не очень устраивает ) - есть готовый pcap этого дела . Также как у вас сделать отчет чтобы как в nfsen общее потребление трафика по времени видеть? Натинги это NSEL/NEL? Не уверен что мы сможем быстро это сделать. Мы вообще про Netflow v9 не сильно думали. Но присылайте конечно, будем думать. Прямо на xenoeye@xenoeye.com если небольшие образцы. Или выложите куда-то, а ссылку пришлете. Общее потребление трафика по времени - это что-то типа такого: http://xenoeye.com/e...p/dgr150414.png ? В trunk версии это есть, график можно зумить/скролить мышкой. Разбивку (это разноцветные столбики) можно делать по любому полю netflow(v5), протокол там, as и т.п. Или можно не делать. Мы даже сделали отчеты с автообновлением, но понятно что они показывают текущую ситуацию очень условно - когда сенсор решит отдать флов Да NSEL/NEL . На мыло вам отослал . >Общее потребление трафика по времени - это что-то типа такого: http://xenoeye.com/e...p/dgr150414.png ? В trunk версии это есть, график можно зумить/скролить мышкой. Окей попробую deb собрать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...