Re: Empty flow files

From: R. Drew Davis (drew@research.bell-labs.com)
Date: Thu Jun 28 2001 - 17:20:00 PDT

  • Next message: hans: "problem compiling arts++"

    > Date: Thu, 28 Jun 2001 15:42:51 -0700
    > From: Diane Proscino-Tharp <Diane.Proscino-Tharp@oracle.com>
    > To: cflowd@caida.org
    > Subject: Empty flow files
    >
    >I have been seeing the same thread in which cflowdmux/cflowd/cfdcollect
    >are all running but the flow files are empty. I am experienceing the
    >same problem.
    >
    >Here is my enviornment:
    >Solaris 2.6
    >arts++-1-1-a6
    >cflowd-2-1-b1 (patched)
    >FlowScan-1.006
    >
    >I have a Catalyst 6509 configured for NDE:
    >
    >switch> sho mls nde
    >Netflow Data Export version: 7
    >Netflow Data Export enabled
    >Netflow Data Export configured for port 2055 on host xxx.xxx.xxx.xxx
    >Total packets exported = 1660592
    >switch>
    >
    >
    >Here is what my unix system tells me: (runing Solaris 2.6)
    >
    >explain% ps -ef | grep cfl
    >flowscan 1783 1 0 14:38:00 pts/5 0:00 cflowd
    >cflowd/etc/cflowd.conf
    >flowscan 1787 1 0 14:38:46 pts/5 0:02 cfdcollect
    >cflowd/etc/cfdcollect.conf
    >flowscan 1826 1819 0 14:50:41 pts/1 0:00 grep cfl
    >flowscan 1780 1 0 14:37:43 pts/5 0:00 cflowdmux
    >cflowd/etc/cflowd.conf
    >explain%
    >explain% netstat -an | grep 20
    > *.2055 Idle
    >1x8.x7.1.xx4.5910 1x0.3x.2x.xx7.33123 24820 0 8760 0
    >ESTABLISHED
    > *.2056 *.* 0 0 0 0
    >LISTEN
    >127.0.0.1.2056 127.0.0.1.32871 32768 0 32768 0
    >TIME_WAIT
    >explain%
    >
    >explain% ipcs -a
    >IPC status from <running system> as of Thu Jun 28 14:52:08 2001
    >Message Queue facility not in system.
    >T ID KEY MODE OWNER GROUP CREATOR
    >CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
    >Shared Memory:
    >m 4096 0x0000339d --rw-r--r-- flowscan flowscan flowscan
    >flowscan 2 2101248 1780 1807 14:38:00 14:48:51 14:37:43
    >T ID KEY MODE OWNER GROUP CREATOR
    >CGROUP NSEMS OTIME CTIME
    >Semaphores:
    >s 0 0x0000339d --ra-ra-ra- flowscan flowscan flowscan
    >flowscan 2 14:52:07 12:10:47
    >s 1 0x0000339b --ra-ra-ra- flowscan flowscan flowscan
    >flowscan 2 13:20:27 12:33:31
    >explain%
    >
    >I did a tcpdump and I can see packets coming from my switch to my
    >server, but nothing else happens. I don't see any messages in my
    >syslog file. No errors, no confirmation that the processes have
    >started, nothing.
    >
    >Any suggestions, direction where to continue looking/troubleshooting
    >would be greatly appreciated.
    >
    >Thanks,
    >-- Diane
    >
    >--
    >*****************************
    >Diane Proscino-Tharp
    >Voice: 408-506-3759
    >Location: 4op2/219
    >Email: dproscin@oracle.com
    >*****************************

    The strange silence of the messages makes me think you should examine
    your /etc/syslog.conf to see if messages are maybe going somewhere
    different then you think. (or maybe are getting thrown away?).

    The use of version 7 format for the netflow data worries me.

    Joe L. posted a FAQ excerpt today that probably accounts for why the
    netflow data is getting ignored. You have to take care to mark it
    with an appropriate IP address and you have to put that IP address in
    the cflowd configurations.

    > Date: Thu, 28 Jun 2001 16:54:24 -0400
    > From: Joe Loiacono <jloiacon@nastg.gsfc.nasa.gov>
    > To: Liger-dc <liger_dc@yahoo.com>, Cflowd <cflowd@caida.org>
    > Subject: Re: Mystery
    > Cc: houle@zeppo.acns.fsu.edu
    >In-reply-to: <20010628194152.80835.qmail@web14601.mail.yahoo.com>
    >
    > From the cflowd FAQ ( http://caida.org/tools/measurement/cflowd/newfaq.xml )
    >
    >"Q: In the CISCOEXPORTER stanze, multiple IP addresses can be defined for a
    >Cisco router. What is the reasoning behind this functionality? How common
    >is it for a router to originate data from more than one interface in a
    >typical network configuration?
    >
    >A: That depends on your version of IOS and your router configuration. In
    >some versions of IOS, if you don't specify the source address to be used by
    >flow-export, you'll get packets with source addresses of one of the
    >interfaces on the box; for other versions of IOS you'll get packets with a
    >bogus (0.0.0.0, for example) source address if you don't specify the source
    >address for flow-export in your router config. I forget Cisco's exact
    >logic, but suffice it to say you're best off configuring the source address
    >for flow-export in your Cisco config and configuring multiple IP addresses
    >in cflowd.conf to be sure."
    >
    >Make sure the CISCOEXPORTER HOST ip address in fact matches your loopback
    >on MSFC. Similar for teh 6509. If they don't match, I believe cflowd drops
    >the packet. I don't know if this is your problem, but it has resulted in
    >the same symptoms for me in the past.
    >
    >Joe
    >
    >At 12:41 PM 06/28/2001 -0700, Liger-dc wrote:
    >>I have configured a catalyst 6509 switch with an MSFC2 Route Switching
    >>Module to export flows to
    >>cflowd.
    >>
    >>The NDE config for the MSFC is shown below....
    >>ip flow-export source Loopback0
    >>ip flow-export version 5
    >>ip flow-export destination 1x6.2x1.xx.xx0 9995
    >>
    >>The NDE config for the C6509 is shown below....
    >>set mls nde 1x6.2x1.xx.xx0 9995
    >>set mls nde enable
    >>
    >>Here is the data from the 'sho ip flo exp' from the msfc
    >>Flow export is enabled
    >> Exporting flows to 1x6.2x1.xx.xx0 (9995)
    >> Exporting using source interface Loopback0
    >> Version 5 flow records
    >> 2342413 flows exported in 34552223 udp datagrams
    >> 0 flows failed due to lack of export packet
    >> 1234052 export packets were sent up to process level
    >> 0 export packets were dropped due to no fib
    >> 0 export packets were dropped due to adjacency issues
    >> 0 export packets were dropped due to fragmentation failures
    >> 0 export packets were dropped due to encapsulation fixup failures
    >> 0 export packets were dropped enqueuing for the RP
    >> 0 export packets were dropped due to IPC rate limiting
    >>
    >>Here is the data from 'sho mls nde' from the 6509
    >>bfs-6000x> (enable) sho mls nde
    >>Netflow Data Export version: 7
    >>Netflow Data Export enabled
    >>Netflow Data Export configured for port 9995 on host 1x6.2x1.xx.xx0
    >>Total packets exported = 34037
    >>
    >>For the second part, I have cflowd configured on a PIII 450, 256MB box
    >>running Red Hat 7.1.
    >>Here is my Cflowd.conf
    >>OPTIONS {
    >># syslog to local6 facility.
    >>LOGFACILITY: local6
    >>
    >># Listen for connections from cfdcollect on port 2056.
    >>TCPCOLLECTPORT: 9995
    >>
    >># Use a 2 megabyte packet buffer in shared memory.
    >>PKTBUFSIZE: 2097152
    >>
    >># Use /usr/local/arts/etc/cflowdtable.socket as named stream socket
    >># for connections from local clients (cfdases et. al.)
    >>TABLESOCKFILE: /usr/local/arts/etc/cflowdtable.socket
    >>
    >># Keep raw flow files in /usr/local/arts/data/cflowd/flows directory.
    >>FLOWDIR: /usr/local/arts/data/cflowd/flows
    >>
    >># Each raw flow file should be 1000000 bytes in length.
    >>FLOWFILELEN: 1000000
    >>
    >># Keep 10 raw flow files per router. Default = 10
    >>NUMFLOWFILES: 5
    >>
    >># Log total missed flows from a router if it exceeds 1000 between
    >># connections from cfdcollect.
    >>MINLOGMISSED: 10
    >>}
    >>
    >>COLLECTOR {
    >>HOST: 1x6.2x1.xx.xx0 # IP address of central collector
    >>(cwsi.acns.fsu.edu)
    >>ADDRESSES: { 1x6.2x1.xx.xx0 }
    >>AUTH: none
    >>}
    >>
    >># BFS-MSFCX
    >>CISCOEXPORTER {
    >> HOST: 1xx.xx.xx.x
    >> ADDRESSES: { 1x6.2x1.xx3.x3 1xx.1xx.x.xx54 xxx.x1.x.x 1x.xx6.xx1.xx
    >> 1x.xx.x.x 1xx.xxx.xxx.x}
    >> CFDATAPORT: 9995
    >> SNMPCOMM: 'public'
    >> LOCALAS: 2553
    >> COLLECT: { protocol, portmatrix, ifmatrix, nexthop,
    >> netmatrix,asmatrix, flows}
    >>
    >>}
    >>
    >># BFS-6000X
    >>CISCOEXPORTER {
    >>HOST: 2x.xx.xx.x
    >> ADDRESSES: { 2x.xx.xx.x }
    >> CFDATAPORT: 9995
    >> SNMPCOMM: 'public'
    >> LOCALAS: 2553
    >> COLLECT: { protocol, portmatrix, netmatrix, asmatrix, flows}
    >>
    >>}
    >>
    >>Here is my cfdcollect.conf
    >>system {
    >> logFacility: local6
    >> dataDirectory: /usr/local/arts/data/cflowd
    >> filePrefix: arts
    >> pidFile: /usr/local/arts/etc/cfdcollect.pid
    >>}
    >>
    >>cflowd {
    >> host: cwsi.acns.fsu.edu
    >> tcpCollectPort: 9995
    >> minPollInterval: 300
    >>
    >>
    >>
    >>
    >>Cflowd installed quietly and below is the 'tail /var/log/messages' after
    >>beginning cflowdmux,
    >>cflowd and cfdcollect respectively
    >>
    >>Jun 28 15:01:13 cwsi cflowdmux[6108]: [I] cflowdmux (version
    >>cflowd-2-1-b1) started.
    >>Jun 28 15:01:13 cwsi cflowdmux[6108]: [I] created 2101248 byte packet
    >>queue shmem segment
    >>{CflowdPacketQueue.cc:247}
    >>Jun 28 15:01:13 cwsi cflowdmux[6108]: [I] attached to 2101248 byte packet
    >>queue at 0x401cf000
    >>Jun 28 15:01:13 cwsi cflowdmux[6108]: [I] created semaphore: id 32769
    >>Jun 28 15:01:13 cwsi cflowdmux[6108]: [I] set UDP recv queue to 261040
    >>bytes for fd 4 (port 9995)
    >>Jun 28 15:01:18 cwsi cflowd[6110]: [I] cflowd (version cflowd-2-1-b1) started



    This archive was generated by hypermail 2b29 : Thu Jun 28 2001 - 17:28:00 PDT