Off hand, nothing jumps out at me. If you read the back traffic, that
"Total: Netflows" page normally reads zero - it's tracking the flows defined
by -F (and of which netFlow uses part of the same path, so there's a
counter, but that's not how flows get into netFlow). The counters in the
plugin page are the important ones.
First off - Are you sure that the udp packets are being received by ntop
from the probes?
If you read the data in the plugin report, it shows you exactly what came
in, was processed or ignored and why...
Flow Statistics
Flow Senders 192.168.42.36 [12 pkts]
Gives: # Pkts Received 12
Less: # Pkts with bad version 0
Gives: # Pkts processed 12
# Flows per packet(avg) 30.0
# Flows received 360
Less: # Flows with zero packet count 0
Less: # Flows with zero byte count 0
Less: # Flows with bad data 0
Gives: # Flows processed 360
Ignored Flows
Zero Port 0
in handleIP() 3
less: netFlow 0
less: port <= 1023 3
Gives: Assumed ftpdata 0
Most Recent Discarded Flows
Flow Bytes # Consecutive
Counts
192.168.42.33:137 -> 255.255.255.255:137 234 (3)
# Exported Flows 390
Second - "ignored flows" are just what they would seem to be in ordinary
English usage, Flows that were ignored (for some reason or other). I'm not
sure what you mean by 'problem flows'.
Ignored flows occur in two places... (and if you look at 'Most Recent
Discarded Flows' you'll see the actual values).
Zero Port, which means that one or both of the source/destination port #s is
zero. These are valid packets, but are normally not tcp/ip - for example
ICMP - so the netFlow collector stuffs a zero in the tcp/ip port field.
"in handleIP()" which is the routine in pbuf.c that (surprise) handles IP
packets. If you look at the code in pbuf.c, starting @ 87:
int handleIP(u_short port,
HostTraffic *srcHost, HostTraffic *dstHost,
u_int _length, u_short isPassiveSess,
u_short p2pSessionIdx, int actualDeviceId) {
int idx;
Counter length = (Counter)_length;
if((srcHost == NULL) || (dstHost == NULL)) {
traceEvent(CONST_TRACE_ERROR, "Sanity check failed (4) [Low memory?]");
return(-1);
}
if(isPassiveSess) {
/* Emulate non passive session */
idx = myGlobals.FTPIdx;
} else {
if(p2pSessionIdx) {
switch(p2pSessionIdx) {
case FLAG_P2P_GNUTELLA:
idx = myGlobals.GnutellaIdx;
break;
case FLAG_P2P_KAZAA:
idx = myGlobals.KazaaIdx;
break;
case FLAG_P2P_WINMX:
idx = myGlobals.WinMXIdx;
break;
case FLAG_P2P_DIRECTCONNECT:
idx = myGlobals.DirectConnectIdx;
break;
default:
idx = -1;
break;
}
} else
idx = mapGlobalToLocalIdx(port);
}
if(idx == -1)
return(-1); /* Unable to locate requested index */
else if(idx >= myGlobals.numIpProtosToMonitor) {
traceEvent(CONST_TRACE_ERROR, "Discarding idx=%d for port=%d", idx,
port);
return(-1);
}
There are a lot of reasons why -1 would be returned (and the flow thus
ignored). The most common is idx = mapGlobalToLocalIdx(port); i.e. the
lookup does not return a value. This occurs if neither of the port #s is
recognized as one that ntop is monitoring.
This is more frequent than you think, for example, ftp traffic uses port
20/21 to negotiate a port pair for the actual transfer, which then occurs on
'unmonitored' ports. Since netFlow doesn't send the packet contents, ntop
can't sniff the PORT command and so it tags the traffic as 'bad'.
There's a compile time option in ntop 2.2,
--enable-netflowassumeftpdata Enable assumption that unknown ports for
netflow data are ftp-data [default=disabled]
which forces netFlow to treat these unknown port pairs as ftp. (See, Luca,
this is why it's there).
Luca removed it from 2.3, which is a mistake - it's on my list to
reimplement, this time as a plugin configuration option.
-----Burton
US-based commercial support for ntop:
http://www.ntopsupport.com
mailto:[EMAIL PROTECTED]
Search the ntop mailing lists at gmane:
http://search.gmane.org
HowTo Ask for Help at
http://snapshot.ntop.org/faq.php#83
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy
Lee
Sent: Sunday, July 06, 2003 3:48 PM
To: [EMAIL PROTECTED]
Subject: [Ntop] Ntop and nProbe questions
Hi,
I am new to Ntop (and nProbe) and have scanned the last few months
of this mailing list archives and have read the faq/documentation/
mini-howtos.
I still have some questions that haven't been answered or I wasn't
able understand what I've read.
My goal is to setup nProbe on multiple subnets that emit/export
data back to a single Ntop server (which will reside on one of those
subnets).
Our Ntop is started with: /usr/bin/ntop -i none -m 10.2.0.0/16 -d -L
In the Admin:Plugins:NetFlow page we have set:
Under "Plugin Preferences":
Local Collector UDP Port: 2055
Local Network IP Address/Mask: 0.0.0.0/0.0.0.0
White list:
Black list:
Outgoing Flows: 0.0.0.0
Under "Flow Export Preferences":
NetFlow-device: No
Is this the correct configuration for what we want?
On the bottom section of this page, there is a table with Flow
Statistics and Ignored Flows. What are "ignored flows" and
"problem flows" and why do they exist?
After leaving this setup running for a while using both the current
demo version of nProbe (limit 1000 flows) as well as the recently
announced test version (expired July 30), it doesn't appear that
Ntop is able to shows much information. Only two pages show any data:
- IP Protos: IP Protocol Distribution
- Stats: Global Traffic Statistics
Curiously, the "Total: NetFlows" page shows 0 packets and 0 traffic.
Is this the proper behaviour? I don't think so since the data
presented by Ntop is so barren compared to running Ntop standalone.
I am hoping to be able to demo the Ntop+nProbe setup and then purchase
nProbe for the live implementation use.
Thanks,
Andy Lee
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
