Netflow - совпадают входящий и выходящий объемы

[sandyboy]

Есть роутер на FreeBSD 5.4, задача - снимать загруженность входного канала.

Уже всё перепробовал - четырьмя разными способами статистику снимал (ipcad, softflowd, flowd, ng_netgraph), всё равно входящий траффик на интерфейсе точно равен исходящему (смотрю в ManageEngine Netflow Analizer 5 под WinXP). Это лечится? тем печальнее что нормального (т.е. бесплатного, но функционального) софта для сбора netflow под win особо и нет...

Edited August 31, 2006 by sandyboy

[stacs]

А по логам что видно?

[sandyboy]

В которых? вроде, сенсоры логов не пишут.

Да, сейчас стоит ipcad - так он по команде stat выдаёт только received для обоих интерфейсов :(

[stacs]

всё равно входящий траффик на интерфейсе точно равен исходящему (смотрю в ManageEngine Netflow Analizer 5 под WinXP)

 

NetFlow должен вываливать логи пакетов.

Что может быть проще, сем посмотреть что в них :)

[Egor]

ng_netflow работает нормально, надо под него только схему правильно собрать.

[stacs]

Так есть у Вас логи от netflow или нет? :)

[sandyboy]

Настроил сбор и просмотр статистики под FreeBSD через flow-tools/FlowScan/CUFlow - уже ничего не понимаю. Через flowdumper - видно, что пакеты бегут через интерфейс в обе стороны. А в статистике - только входящий показывается, хоть тресни. Ну что я делаю не так???

 

вот кусочек лога:

---------------------------------------------------------------------------------------

2006/09/01 13:55:18 10.0.10.12.138 -> 10.0.255.255.138 17 1 229

2006/09/01 13:55:35 10.0.11.22.1798 -> 10.0.0.111.62287 6(SYN|ACK|FIN) 5 208

2006/09/01 13:55:35 10.0.0.111.62287 -> 10.0.11.22.1798 6(PUSH|ACK|FIN) 4 3870

2006/09/01 13:55:20 10.0.11.57.4098 -> 255.255.255.255.67 17 1 389

---------------------------------------------------------------------------------------

 

Третья строчка - на самом деле исходящий траф (10.0.0.111 - IP самой тестовой машины) - а стрелка указывает что это якобы входящий :( Может быть есть способ как-то объяснить flow-capture какой траффик считать входящим, а какой исходящим?

Edited September 1, 2006 by sandyboy

[Shiva]

Стрелка показывает кто куда слал, слева сорс, справа дестнайшен.

Допустим надо статистику для 10.0.11.22

Тогда все записи с source ip = 10.0.11.22 будут исходящим.

а все записи с destination ip = 10.0.11.22 буду входящим.

 

Так не судьба выборку сделать?

[sandyboy]

Не знаю, мало вероятно.

Больше похоже на глюк самой фрюхи - если 3 разных сенсора на 2 разных коллектора передают одинаково - ПОЛНЫЙ траф как однонаправленный :(

[Kuzmich]

Не замечал в 5.4 фрюхе таких глюков... однако, давно уже пользуюсь шестой веткой.

 

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

 

Если я напишу настройку для ng_netflow - полегчает?

 

А может быть проблема в этом, как его... ну в той XP-софтине, на основании отчтов которой строятся предположения о кривизне сенсоров и операционной системы в целом. flow-print в руки, и посчитать вручную трафик (хоть в том же экселе) за пять минут.

[Гoсть]

Однако, в классическом нетфлове (это тот что на циске) траф учитывается только при поступлении в интерфейс (input). Исходящий траф (output) не может быть зафиксирован нетфловом. И это не бага, а технологическая особенность протокола. Таким образом, что-бы получить полную картину необходимо с циски снимать фловы на ВСЕХ сетевых интерфейсах.

Думаете во фре принцип работы совсем другой?

[Egor]

Думаете во фре принцип работы совсем другой?

"совсем" это как? :))

для ng_netflow не точно такой же, это факт.

[ssk]

Однако, в классическом нетфлове (это тот что на циске) траф учитывается только при поступлении в интерфейс (input). Исходящий траф (output) не может быть зафиксирован нетфловом. И это не бага, а технологическая особенность протокола. Таким образом, что-бы получить полную картину необходимо с циски снимать фловы на ВСЕХ сетевых интерфейсах.

Думаете во фре принцип работы совсем другой?

У меня на одной из машин с bsd поток с ng_netflow снимается и пишется как по входящему так и по исходящему трафу.

 

На циске же с некотрых пор появилось ip flow ingress/egress, только вот зачем он там нужен неясно.

[sandyboy]

2 Kuzmich

 

1. netgraph я и сам нормально настроил - благо, в данной конфигурации ничего сложного нет. IPCAD тоже в настройке несложен (скорее, даже слишком примитивен) и трудно в нём ошибиться.

2. Для сбора использовал 2 порта под Win явно Linux-совых систем и один вариант под FreeBSD собирал - повторяемость результатов 100%.

3. Главное - как понять, действительно ли считается только ВХОДЯЩИЙ (это не самый лучший, но приемлимый вариант) или оно просто валит в одну кучу ПОЛНЫЙ траффик. Так и прийдется руками подсчитать и сравнить. Что самое обидное - на многих скринах в статейках по настройке полный траффик показывается - а у меня нет...

4. Вариант с полным отказом от готовых коллекторов-визуализаторов не проходит - надо в короткие сроки обеспечить просмотр статистики руководством - а оно дюже эти красивости любит.

 

2 ssk

чем собираешь\смотришь статистику? самописными скриптами?

Edited September 5, 2006 by sandyboy

[GateKeeper]

2006/09/01 13:55:18 10.0.10.12.138 -> 10.0.255.255.138 17 1 229

2006/09/01 13:55:35 10.0.11.22.1798 -> 10.0.0.111.62287 6(SYN|ACK|FIN) 5 208

2006/09/01 13:55:35 10.0.0.111.62287 -> 10.0.11.22.1798 6(PUSH|ACK|FIN) 4 3870

2006/09/01 13:55:20 10.0.11.57.4098 -> 255.255.255.255.67 17 1 389

---------------------------------------------------------------------------------------

 

Третья строчка - на самом деле исходящий траф (10.0.0.111 - IP самой тестовой машины) - а стрелка указывает что это якобы входящий :( Может быть есть способ как-то объяснить flow-capture какой траффик считать входящим, а какой исходящим?

Очнитесь! Третья строчка указывает на то, что для 10.0.0.111 это ИСХОДЯЩИЙ:

At 2006/09/01 13:55:35 from 10.0.0.111.62287 to 10.0.11.22.1798 a packet was sent with PUSH|ACK|FIN flags set.

 

Стрелка об этом и говорит. Если вопрос не об этом, то, конечно, за неимением штатного телепата приходится строить догадки.

[sandyboy]

2 GateKeeper

Суть проблемы: стоит роутер на FreeBSD 5.4 с двумя интерфейсами, на обоих реальные инетовские адреса, за вторым - две подсетки на 16 и 8 адресов соотв. Роутится всё отлично, но! все средства сбора netflow загоняют в ИСХОДЯЩИЙ полный траффик проходящий через интерфейс. Сейчас зафильтровал правилами в IPCADе траффик, чтобы считался только входящий на эти 2 подсетки - но очень хочется иметь нормальный учёт полного траффика.

Насчет стрелочек - во всех статейках на эту тему стрелочки на скиринах в обе стороны, а не в одну!!! и графики в отчетах тоже. Какой траффик входящий а какой исходящий, я-то лично и без телепатов вижу, а вот как это сенсору\коллектору netflow объяснить?

Edited September 6, 2006 by sandyboy

[bekket]

2 GateKeeper

Насчет стрелочек - во всех статейках на эту тему стрелочки на скиринах в обе стороны, а не в одну!!!

Скрины в студию.

В чём собственно проблема? Есть протокол NetFlow, который, хоть убейте, считает в одну сторону. Это аксиома. Вы пытаетесь на некоторой вариации его же заставить считать в обе. ИМХО то что у кого-то получилось не по правилам, еще не значит, что получится у вас.

Проблема решается либо изменением самой политики учета, либо применением другого инструмента.

 

Кстати под Винь есть еще PRTG для анализа по NetFlow.

[apostle]

хотелось бы поднять этот же вопрос: neflow analyzer считает одинаково и вход., и исход. траф.:

данные netflow analyzer 6 (критерии troubleshoot report'а:

From 2007-07-04 11:23 To 2007-07-04 12:23; source address = 10.0.0.5, 10.0.2.7, 10.0.0.239, 192.168.25.20; указано Match any of the following критерии). рез-т:

IN Traffic Details  Showing 1 to 2    
Source IP Destination IP Application Source Port Dest . Port Protocol DSCP NAME  TCP FLAGS   Traffic No of Packets 

10.0.2.7 1 Unique Destinations Any Any Any Any Any Any 2.57 KB 12 
10.0.0.5 1 Unique Destinations Any Any Any Any Any Any 1.64 KB 5 
...
...
OUT Traffic Details  Showing 1 to 2    
Source IP Destination IP Application Source Port Dest . Port Protocol DSCP NAME  TCP FLAGS   Traffic No of Packets 

10.0.2.7 1 Unique Destinations Any Any Any Any Any Any 2.57 KB 12 
10.0.0.5 1 Unique Destinations Any Any Any Any Any Any 1.64 KB 5

это широковещательные сообщения из сети провайдера.

к тому же появляются вопросы относительно корректности подсчета данных; для сравнения:

free62# ./flow-cat -p /usr/netflow/2007/2007-07/2007-07-04/ | ./flow-stat -f10 -p -S3 | more
#  --- ---- ---- Report Information --- --- ---
#
# Fields:    Total
# Symbols:   Disabled
# Sorting:   Descending Field 3
# Name:      Source/Destination IP
#
# Args:      ./flow-stat -f10 -p -S3
#
#
# mode:                 streaming
# capture start:        Wed Jul  4 11:29:32 2007
# capture end:          Wed Jul  4 12:15:00 2007
# capture period:       2728 seconds
# compress:             off
# byte order:           little
# stream version:       3
# export version:       5
# lost flows:           630
# corrupt packets:      0
# capture flows:        660
#
#
# src IPaddr     dst IPaddr       flows                 octets                packets
#
10.0.0.239       10.0.15.255      2                     48352                 453
10.0.2.7         10.0.15.255      6                     45725                 572
10.0.0.5         255.255.255.255  1                     29192                 89
10.0.0.52        10.0.15.255      2                     28533                 197
192.168.25.20    239.255.255.250  1                     15090                 30
169.254.21.67    169.254.255.255  3                     14323                 88
10.0.13.81       10.0.15.255      2                     11123                 49
10.0.13.120      10.0.15.255      2                     8806                  68

netflow генерируется след. скриптом для netgraph:

 

#!/bin/sh
/usr/sbin/ngctl  -f- <<-SEQ
  mkpeer fxp0: netflow lower iface0

  name fxp0:lower netflow0

  connect netflow0: fxp0: out0 upper
  connect netflow0: fxp1: out1 upper
  connect netflow0: fxp1: iface1 lower
  msg netflow0: setifindex {iface=1 index=2}
  msg netflow0: setifindex {iface=0 index=1}

  mkpeer netflow0: one2many export one
  name netflow0:export flow2
  mkpeer flow2: ksocket many0 inet/dgram/udp
  mkpeer flow2: ksocket many1 inet/dgram/udp
  msg flow2:many0  bind inet/192.168.25.4:9996
  msg flow2:many0 connect inet/192.168.25.7:9996

  msg flow2:many1 bind inet/192.168.25.4:9990
  msg flow2:many1 connect inet/192.168.25.4:9991
SEQ

192.168.25.7 - linux-хост с установленным netflow analyzer 6, 192.168.25.4 - тестовый freebsd-маршутизатор.