From: Vlad Halilow <vlad@ccs.ru>
Subject: [CISCO] Настройка Netramet для учёта трафика посредством netflow
NeTraMet и борьба с ним.
-------------------------
Netramet - это комплекс программ, позволяющих вести учёт трафика посредством netflow,
Netflow - технология, позволяющая получить исчерпывающие данные о трафике, в нашем
случае будет рассматриватся только случай снятия трафика с cisco роутеров, поддерживающих
эту возможность. На настоящий момент доступна версия Netramet версии 4.3 под основные операционные
системы (Solaris, Irix, Linux, и как порт для FreeBSD ). Скачать всё это можно на фтп проекта, указанный
в разделе линков. Разрабатывается следующая версия, но сроки её выхода пока не определены. Основные фичи:
- требует мало ресурсов, по одному этому параметру он как дитё делает кискин netflow collector+analyzer
которому для полноценной работы и убогими схемами агрегации нуна столько ресурсов, что мама не горюй.
- конечные данные можно формировать в каком угодно виде. в отличии например от cflowd который имет их
предопределённое количество, а hostmatrix там до сих пор нету 8(
Пакет состоит из нескольких блоков:
NeTraMet & NetFlowMet - коллекторы, первый предназначен для установки на pc-роутеры, мониторит до
4х интерфейсов, и позволяет привести данные с pc-роутеров в вид, пригодный для обработки стандартными методами
пакета ( менеджером ). Второй - вылавливает приходящие на него пакеты с роутеров, и приводит их в вид пригодный для дальнейшей обработки менеджером.
т.о. на первом этапе, есть возможность сконцентрировать информацию о трафике в едином виде, и обрабатывать
одним и тем-же способом без производства диких скриптов итд.
NeMaC - менеджер ( я его далее буду называть ридером, от слова read т.к. его занятие имено в этом
и заключается ), сканирующий коллекторы, и дампящий по определённым пользователем правилам информацию
в текстовый файл, который затем можно использовать для фильтра.
fd_filter - фильтр, приводящий flow от ридера в божеский вид, который можно скормить хоть екселю.
fd_extract - тулза, для генерения матриц проивзольной ( почти произвольной ) формы для обработки
где угодно ( в том-же екселе по данным снимаемым с екстрактора можно построить симпатишнейшие графики )
далее идут программы не связанные напрямую с работой, т.н. сервисные утилиты.
nifty - иксовый визуализатор. ( сразу говорю, графики построеные каким-ить мртг куда лучше )
rf_rc - remote console,тулза для мониторинья трафика почти в реальном времени ( какой интервал обновления
укажете такой и будет ) в принципе вещь приятная, её вывод можно выкидывать в рутовой окошко иксов, и наблюдать
за гадами тащущими большой варез на весь канал.
NetFwd - проксирование netflow потока с роутера куда нибудь.
srl - вынесен в отдельный абзац, ибо это компилятор simple rules languages, то биш макро-языка
с помощью которого мы будем обьяснять коллектору чего мы от него хотим.
Итак, общее представление о том, чем мы с вами будем заниматься у вас уже есть, и если вы не решили
сачкануть и не побежали писать скрипт для обсчёта трафик через ip accounting - то продолжаем...
Запуск NetFlowMet.
Итак, коллектор висит на порту ( удп ) и записывает все ходы роутера, что-бы мы потом
могли с полным правом выставить счёт юзеру за всю его тонну перекачанный мп3 группы Бюль-Бюль-Оглы,
или видеозаписей последнего съезда КПСС. коллектор вещь очень мудрая, каждый пришедший пакетик, он заботливо
разбирает, и если такого флова ( флов == flow: некий каунтер ( счётчик, в нетрамете размер 32бита ) уникальность
которого гарантируется выставлеными нами параметрами, это и всё остальное далее ) еще нет, он в своём дереве
snmp ( кстати обмен данными между ридером и коллектором идёт именно по этому протоколу ) создаёт новую веточку.
если есть - записывает в неё пришедшие с роутера значения. как это происходит точнее - вот вам ссылка:
http://www.auckland.ac.nz/net/Accounting/ntmref.pdf желания заниматся переводом за мной не замечено.
основные параметры от которых зависит наше с вами счастливое детство:
-m N порт куда можно подцепится и снять информацию о том, кто сколько накачал. по дефолту 161.
-r word :выставить комьюнити ( если вы не знаете что такое комьюнити, то вы явно не сюда попали ),
на чтение. на тот случай, если шеф паралельно с вами снимает с коллектора данные, а потом спросит почему
в его версии с вашего хоста каждый день с playboy.com качается дикое кол-во информации, а в вашей
то-же самое делает весь бухгалтерский отдел.
-w word : тоже самое но на запись, если у вас продвинутые юзера, то путём нехитрого обнуления канунтеров,
ваша контора с их помощью быстро вылетит в трубу, т.к. не расплатится за трафик.
-f N : главный параметр. в зависимости от скорости ваших каналов, и интенсивности их потребления,
под хранение счётчиков нуна разное кол-во памяти, чем больше чем лучше. если выставить слишком мало,
то вы получите в логах Collector in flood mode, а в купе с пустыми дампами трафика это приведёт к резульату
предыдущего параметра. выставляйте в 100000 для начала, а далее посмотрев скорость расхода пространства
отведённого под flow в течении дня, выберете оптимальный. главное не переусердстовать, иначе на жёстком
диске головка дыру протрёт в процесссе свопирования.
-u N : память отводимая под рулезы, т.е. чем мудрей написанный вами алгоритм разработки, тем он длиннее
( не всегда ) тем больше памяти надо выжрать что-бы уместить ваше творение.
запустить его можно например так:
( -D, форк и процесс не будет мозолить вам глаза ).
кстате не забудте сказать на циске:
ip route-cache flow : для всех интерфейсов где нуна считать. ( учитываеться только исходящий трафик )
ip flow-export source FastEthernet0/0.1 ( здесь интерфейс с которого будут отправлятся пакеты на коллектор )
ip flow-export version 5 ( это версия, можете выставить хоть 1, но тогда о номерах автономок можете забыть )
ip flow-export destination 207.46.130.45 9996 ( адрес коллектора, и порт. по дефолту коллектор вешается
именно на такой порт )
итак, ваш сервер биллинга весело замигал лампочкой на сетевом интерфейсе, ибо поток данных с роутера не то что-бы большой,
но нормальный, закряхтел винчестером если вы перебрали с запросами с памятью, то биш первый этап прошли.
дальше куда интереснее.
Запуск NeMaC.
итак, собрать данные это еще даже не пол-дела, а процентов эдак 10. их нужно еще обработать и скинуть
в удобоваримый вид. всё это дело ридера, кроме того он выполняет управляющие функции, как-то: контролирует
расход памяти коллектором, если надо подчищает за ним и загружает ваши программные изыски в него-же.
для начала пара вводным фраз. сколько-бы вы памяти не отвели под flow она рано или поздно закончится,
поэтому нужно умело ею рулить, дабы не получить радостное сообщение в логах о том что трафика много,
но сохранить инфу о нём некуда. основные ключи руления памятью коллектора:
-g N : где Н интервал в секундах, то биш с какой переодичностью ридер будет проверять сколько памяти выжрано, и когда
нужно подчистить.
-h N : здесь указывается размер в процентах, разрешённый к выжиранию коллектором памяти, до прихода часа Х. ( очередного
цикла проверки на занятую память ), если коллектор использует памяти больше заданного, то ридер цинично выносит
часть flow дабы уложить коллектор в разумные пределы. алгоритм определения крайних тривиален, и если есть
интерес можете почитать в английской документации.
-с N : время в секундах, через которые ридер будет пинать коллектор на предмет кто и сколько накачал, будьте
осторожны с этим параметром, если выставить его неправильно ( а где кончается правильно а где неправильно я там и не смог определить ),
можно получить некислый заворот мозгов. так у меня итоговые данные стабильно превышали на 1/5 реальные, только из-за
того, что ридер пинал коллектор раз в 60 секунд. выставте его в 10 минут и будет вам счастье.
-k N : периодичность ( в секундах ) проверки коллектора не предмет а не перезапускалсяли он. если коллектор
сдох а потом его подняли многострадальные скрипты, то ридер по новой загрузит в него рулесы.
-b PATH : путь к файлу мибов, я предлагаю вам не мудрить, и дать ему лин на mib.txt входящий в поставку, на первое
время этого хватит выше крыши.
-r PATH : путь к файлу рулесов, собственно алгоритму обработки flow. самого процесса написания программки коснёмся подробнее.
здесь адрес - это адрес где висит коллектор, а слово после адреса: комьюнити на запись, ибо после того, как
ридер сняли нужную информацию он обнуляет каунтеры.
теперь о рулесах:
есть два способа сказать коллектору что мы от него хотим, это прямое написание rules файла и связанные
с этим геморрой, и более удобный: воспользоватся компилятором srl. в поставке в директории examples
есть несколько примеров того и другого, на всякие случаи жизни. если у вас нет охоты писать свой алгоитм, можете
воспользоватся например rules.x-ip с которым ридер в тупую дампит всё что насобирал коллектор без всякого
разбора в файл. но при приличном трафике, конечноый файл получается мегов по 800 за сутки - легко, что
неправильно. вот простейший пример srl программы, результат которого немногим отличается от вышеупомянутого rules.x-ip,
кроме правда размера эдак на порядок меньше, и минимальной необходимой постобработкой.
---sample.slr---
define net = (4.35.64.120/29, 45.2.5.6/30); #опрееделяем сети с которых нуна считать
define ext = (2,3,4); #определяем snmp индексы интерфейсов трафик на которые неплохо было-бы разделить.
define srv = (53,161,20,21,22,23,69,80,110,25,143,443,119,139); #определяем основные серверные порты, если захочется посмотреть кто в чьём трафике больше заинтересован.
define asn = (2000); #определяем номера автономок для которых тоже нужно считать трафик
IF SourcePeerType == IP SAVE ; #поехали. если пакет не айпишный, лесом
ELSE IGNORE; # Not Ip
store DestClass := 0; #служеюные переменные, их 6 штук, можно юзать как хочется. можно присваивать не только число но и текст 'store DesClass:='W';'
store SourceClass := 0;
IF SourcePeerAddress == net { #если адрес отправителя принадлежит нашим сетям, то
IF DestInterface == ext { #проверяем на какой интерфейс уехало.....
store DestClass := 1;
SAVE DestInterface; #если вы хотите сохранить значение атрибута в конечной строчке, то надо ему сказать SAVE иначе увидите нули.
}
ELSE { store DestClass := 255; } #в противном случае отправитель не наш...
IF SourceTransAddress == srv { SAVE SourceTransAddress; } #а не серверные-ли случайно порты ? если да - сохраняем на потом.
SAVE SourcePeerAddress/32; #cетка наша, знащт сохраняем для лога.
}
# дальше всё повторяется для автономок и адресов куда ушло.
IF SourceASN == asn {
IF DestInterface == ext { store DestClass := 1; SAVE DestInterface; }
ELSE { store DestClass := 255; }
IF SourceTransAddress == srv { SAVE SourceTransAddress; }
SAVE SourceASN;
}
IF DestPeerAddress == net {
IF SourceInterface == ext { store SourceClass := 1; SAVE SourceInterface; }
ELSE { store SourceClass := 255; }
IF DestTransAddress == srv { SAVE DestTransAddress; }
SAVE DestPeerAddress/32;
}
IF DestASN == asn {
IF SourceInterface == ext { store SourceClass := 1; SAVE SourceInterface; }
ELSE { store SourceClass := 255; }
IF DestTransAddress == srv { SAVE DestTransAddress; }
SAVE DestASN;
}
IF DestClass == 0 && SourceClass == 0 { #проверяем наши переменные, если обе нули значт ни тот ни другой пир к нам отношения не имеют.
SAVE SourcePeerAddress/24; # при таком раскладе сохраняем всю информацию о флове, дабы разобратся кто нахаляву пользует наши ресурсы
SAVE DestPeerAddress/24;
SAVE SourceTransAddress;
SAVE DestTransAddress;
SAVE SourceASN;
SAVE DestASN;
SAVE DestTransAddress;
SAVE SourceTRansAddress;
SAVE SourceInterface;
SAVE DestInterface;
store SOurceKind := 255; # и выставляем идентификатор, если #FF то флов левый, если 0 то кто-то наш,
}
COUNT; # даём комманду на внесение в файл
FORMAT # формат в котором флов будет дампится в файл, можно тасовать как хочеш, что-то убрать что-топрибавить, без разницы.
FlowRuleSet FlowIndex FirstTime SourcePeerAddress DestPeerAddress SourceASN DestASN
ToOctets FromOctets ToPDUs FromPDUs SourceInterface DestInterface SourceTRansAddress DestTransAddress SourceKind ;
STATISTICS ; # класть в файл статистику
SET 5; # версия протокола кажется. а может и нет.
-----------------------------------
собственнов всё. на примере ясно как работать с условиями, есть еще такое понятие
как подпрограммы, см. документацию. можно было в принципе проверку на адреса куда ушло не проводить,
а сказать NOMATCH ( не забыв перед этим сказать count если отправитель наш ), после чего все атрибуты поменяются
местами ( SourceAddress <-> DestAddress итд ), и автоматом проедет проверка вторично.
работа с fd_filter.
итак, мы получиили какие-то данные, которые можно использовать для расчёту, но только если
вы своих юзеров ненавидите дикой ненавистью, ибо если вы возмёте и сложите например для одного адреса
входящий трафик, то результат будет превышать реальность на порядок если не больше. это прекрасный способ
отправить в кутузку кого нибудь за долги. если вы хотите жить долго и счастливо, то небходимо провести
пост-обработку, т.к. фловы в файле дампа ридера обладают кумулятивным свойстовм ( да и не только там )
т.е. если кекс качает много и часто, то в первоми интервале вам положится сколько он накачал за первый отрезок
времени, во второй сколько за этот + за предыдущий итд, до тех пор пока флов не отекспайрится. fd_filter
на основе flowindex и firsttime прозводит вычитания счётчиков один из другого, и на выходе вы полуется чистые дельты
трафика за определённый интервал. единственная настройка на этом этапе состоит только в созданнии файла формата
ыходных данных, что-то типа:
-----format.file---------------------------------------------------------
FORMAT:
SourcePeerAddress DestPeerAddress SourceASN DestASN d_ToOctets d_FromOctets d_ToPDUs d_FromPDUs
SourceInterface DestInterface SourceTransAddress DestTransAddress SourceKind;
-------------------------------------------------------------------------
атрибуты с префиксов 'd_' и есть те самые дельты трафика, ради которых вся пляска и затевалась.
на выходе для нашего случая будет:
---------------------------------------------------------------------------
##NeTraMet v4.3: -c600 -r /usr/local/share/NeTraMet/examples/srl/2ip8.bac.rules 207.46.130.45 udp-9996 100000 flows star
ting at 15:26:01 Sat 10 Mar 2001
#Format: sourcepeeraddress destpeeraddress sourceasn destasn d_tooctets d_fromoctets d_topdus d_frompdus sourceinterface de
stinterface sourcetransaddress desttransaddress sourcekind
#Time: 15:26:01 Sat 10 Mar 2001 207.46.130.45 Flows from 0 to 324250
#Ruleset: 4 5 /usr/local/share/NeTraMet/examples/srl/2ip8.bac.rules NeMaC
#EndData: 212.30.151.2
#Time: 15:30:00 Sat 10 Mar 2001 212.30.151.2 Flows from 324249 to 348171
0.0.0.0 262.30.140.34 0 0 36816718 0 77134 0 2 0 0 0 0
277.72.54.4 0.0.0.0 0 0 334038 0 4023 0 0 0 0 0 0
262.30.170.34 0.0.0.0 0 0 5436850 0 70616 0 0 0 0 0 0
0.0.0.0 217.52.34.6 0 0 945658 0 3121 0 2 0 0 0 0
252.30.170.34 0.0.0.0 0 0 211621 0 2380 0 0 0 0 0 0
0.0.0.0 212.30.140.37 0 0 1603532 0 1848 0 2 0 0 0 0
232.50.170.36 0.0.0.0 0 0 11023 0 125 0 0 0 53 0 0
0.0.0.0 212.30.160.36 0 0 13218 0 93 0 2 0 0 53 0
232.183.13.0 237.26.0.0 0 0 78 0 1 0 2 0 53 53 255
219.249.123.0 262.30.177.0 0 0 420 0 5 0 2 0 0 2048 255
-----------------------------------------------------------------------------
не пугайтесь безумный адресов, я просто копирую реальные данные, а давать свои реальные адреса в них
желанием не горю, поэтому пару цифирей в каждом адресе меняю ;)
во собственно и всё. теперь можете воспользоватся либо fd_extract для получения матриц ( правда с этим
примером это у вас не получится, ибо я не рассказал про Tag, но сам ими не пользуюсь так-же как и екстрактором, )
либо набросать перловый скриптик который будет выдавать таблицу с итогом кто куда и сколько раз.
-----------------------------------------------------------------------------
#!/usr/bin/perl
open (ERR,"/home/netflow/data/$ARGV[0].err");
open(SRC,"out"); #out - это файл резултатов fd_filter
while($l=<SRC>)
{
next if($l=~/^#/);
($a[0],$a[1],$a[2],$a[3],$a[4],$a[5],$a[6],$a[7],$a[8],$a[9],$a[10],$a[11],$a[12])=split(' ',$l);
# src dst s_asn d_asn -> <- ->p <-p s_if d_if
if($a[12] == 255) { print ERR "$l";next; }
if($a[0] ne "0.0.0.0")
{
$hash="$a[0]"."#$a[9]"."#$a[10]";
$d{$hash}[0]+=$a[5]; #na adres
$d{$hash}[1]+=$a[4]; #s adres
$d{$hash}[2]+=$a[7];
$d{$hash}[3]+=$a[6];
}
foreach $key (keys (%d))
{
($a,$b,$c)=split('#',$key);
($a[1],$a[2],$a[3],$a[4])=split('.',$a);
$val="'$ARGV[0]','1','$a[1]','$a[2]','$a[3]','$a[4]',$c,$b,'$d{$key}[0]','$d{$key}[1]','$d{$key}[2]','$d{$key}[3]'";
print "$valn";
}
---------------------------------------------
PowerHIT! считаете, рисуете графики если цифири не впечатляют, тащите к шефу, он вам повышает зарплату. а делов-то ;)
NeTraMet: http://www.auckland.ac.nz/net/NeTraMet/
NeTraMet Ftp: ftp://ftp.auckland.ac.nz/pub/iawg/NeTraMet/
Flowc: http://www.rpd.univ.kiev.ua/~roman/soft/flowc/ рулезная тулза, если у вас небольшие каналы. минимум
настроек и положительныйе результаты. правда база обладает немерянными размерами, поэтому если каналы у вас
хоть сколько-нибудь серьёзные, и нету 20гиг под базу - лучше взять нетрамет.
wbr - konsul.
510 Прочтений • [[CISCO] Настройка Netramet для учёта трафика посредством netflow (cisco netflow)] [08.05.2012] [Комментариев: 0]
Vova
