Also, if you get messaging about exporting flows, try changing the port number on your zmq endpoint away from 2055 and stick with local host for the IP.
> On Dec 22, 2015, at 03:06, Yasser Slarmie <[email protected]> wrote: > > Ok, I see lots of output for the netcat dump, meaning that the flow data > reaches nprobe. The GUI still doesn't show anything though. > Nprobe console logging messages for nprobe shows 460 collected packets and > 3182 processed flows: > > > 22/Dec/2015 11:01:56 [nprobe.c:2476] Flow drop stats: [0 bytes/0 pkts][0 > flows] > 22/Dec/2015 11:01:56 [nprobe.c:2481] Total flow stats: [0 bytes/0 pkts][0 > flows/0 pkts sent] > 22/Dec/2015 11:02:26 [nprobe.c:2589] --------------------------------- > 22/Dec/2015 11:02:26 [nprobe.c:2590] Average traffic: [0.00 pps][0 b/sec] > 22/Dec/2015 11:02:26 [nprobe.c:2597] Current traffic: [0.00 pps][0 b/sec] > 22/Dec/2015 11:02:26 [nprobe.c:2603] Current flow export rate: [0.0 flows/sec] > 22/Dec/2015 11:02:26 [nprobe.c:2606] Flow drops: [export queue too > long=0][too many flows=0] > 22/Dec/2015 11:02:26 [nprobe.c:2610] Export Queue: 0/512000 [0.0 %] > 22/Dec/2015 11:02:26 [nprobe.c:2615] Flow Buckets: > [active=1][allocated=1][toBeExported=0] > 22/Dec/2015 11:02:26 [cache.c:1200] Redis Cache [0 total/0.0 get/sec][0 > total/0.0 set/sec] > 22/Dec/2015 11:02:26 [nprobe.c:2633] Collector Threads: [460 pkts@0] > 22/Dec/2015 11:02:26 [nprobe.c:2457] Processed packets: 0 (max bucket search: > 0) > 22/Dec/2015 11:02:26 [nprobe.c:2440] Fragment queue length: 0 > 22/Dec/2015 11:02:26 [nprobe.c:2466] Flow export stats: [0 bytes/0 pkts][0 > flows/0 pkts sent] > 22/Dec/2015 11:02:26 [nprobe.c:2473] Flow collection: [collected pkts: > 460][processed flows: 3182] > 22/Dec/2015 11:02:26 [nprobe.c:2476] Flow drop stats: [0 bytes/0 pkts][0 > flows] > 22/Dec/2015 11:02:26 [nprobe.c:2481] Total flow stats: [0 bytes/0 pkts][0 > flows/0 pkts sent] > > > I also changed the listening IP from localhost to the IP of the server itself > as follows: > > ntopng -i tcp://137.158.154.30:2055 > > nprobe --zmq tcp://137.158.154.30:2055 --collector-port 9991 -i none -n none > -b 1 > > > What could I check next? > > Regards, > Yasser > > Date: Tue, 22 Dec 2015 00:56:49 -0600 > From: [email protected] > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > Awesome. You are not running into the same issue that I did which is good. I > am also a bit fuzzy on the PF_Ring interaction as well, but I have it enabled > also and still got bit by rpf..... > > I see you ran netcat on port 2055, I think we got our wires crossed on what > port you were using. I see from the tcpdump that you are using 9991 for flow > data. > > What do you see if you stop nprobe/ntopng, run 'netcat -lu 9991 | hexdump -C' > ? This should confirm that the flow-data is actually making it through any > filtering such as iptables/ufw. > > Erik > > On Tue, Dec 22, 2015 at 12:33 AM, Yasser Slarmie <[email protected]> > wrote: > Hi Erik, > > The server has only 1 nic and a single default-gateway and there is IP > reachability between the netflow exporter and collector. I turned rpf off, > just for the sake of argument, but I still don't see the packets passing the > kernel. > > PF_Ring is enabled, but I don't know enough about it to say whether the > packets will bypass the kernel or not.. > > ~$ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 0.0.0.0 137.158.154.1 0.0.0.0 UG 0 0 0 eth0 > 137.158.154.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > > > > root@devubunfl001:~# cat /proc/sys/net/ipv4/conf/eth0/rp_filter > 1 > root@devubunfl001:~# echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter > root@devubunfl001:~# cat /proc/sys/net/ipv4/conf/eth0/rp_filter > 0 > > > root@devubunfl001:~# netcat -lU 2055 | hexdump -C > ^C > > > > root@devubunfl001:~# ufw status > Status: active > > To Action From > -- ------ ---- > 9991/udp ALLOW Anywhere > 22 ALLOW Anywhere > 80/tcp ALLOW Anywhere > 123 ALLOW Anywhere > 3000/tcp ALLOW Anywhere > 2055/tcp ALLOW Anywhere > 9991/udp (v6) ALLOW Anywhere (v6) > 22 (v6) ALLOW Anywhere (v6) > 80/tcp (v6) ALLOW Anywhere (v6) > 123 (v6) ALLOW Anywhere (v6) > 3000/tcp (v6) ALLOW Anywhere (v6) > 2055/tcp (v6) ALLOW Anywhere (v6) > > > > root@devubunfl001:~# tcpdump -n host 137.158.248.10 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 08:15:53.230349 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 1320 > 08:15:55.232036 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length 816 > 08:16:08.229221 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length 456 > 08:16:11.229323 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length 744 > 08:16:12.228999 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length 168 > 08:16:13.229034 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length 456 > ^C > 6 packets captured > 7 packets received by filter > 0 packets dropped by kernel > > > > Date: Mon, 21 Dec 2015 16:09:52 -0600 > From: [email protected] > > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > Exactly what I am referring to. Your plight sounds exactly like mine as I > just got bit by this and wasted Luca and crew's time sorting it out. Ubuntu > runs RPF check in the kernel and if the Netflow traffic arrives on an > interface that doesn't have a route back to the source via the interface it > was received on, the kernel rejects it. > > You can verify by running netcat -lu 2055 | hexdump -C after starting the > netflow feed from the router. > > Tcpdump runs at the interface pre RPF check, Netcat will bind to the port and > tell you if the kernel passed the traffic. If you do not see traffic data, > it's being dropped before nProbe can capture it. > > > > On Mon, Dec 21, 2015 at 3:54 PM, Yasser Slarmie <[email protected]> > wrote: > Ntop and nprobe are on the same server. Are you perhaps alluding to urpf that > may be breaking things? The netflow packets arrive on the server, so I > believe nprobe should be able to interpret it without any routing back to the > source or requiring to do so. > > Sent from my Windows Phone > From: Erik Schmersal > Sent: 2015-12-21 07:37 PM > > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > Is netflow being received on the same interface where Ubuntu's default route > pointing out of? Or is the route back to the flow source pointing out the > same interface that the flows are coming in on? > > On Mon, Dec 21, 2015 at 9:24 AM, Yasser Slarmie <[email protected]> > wrote: > Hi Eric, > > My commands are: > > ntopng -i tcp://127.0.0.1:2055 & > > nprobe --zmq "tcp://127.0.0.1:2055" --collector-port 9991 -i none -n none -b > 1 & > > Regards, > Yasser > > From: [email protected] > Date: Mon, 21 Dec 2015 07:59:00 -0600 > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > > Can you post your nProbe and nTop commands? > > On Dec 21, 2015, at 03:29, Yasser Slarmie <[email protected]> wrote: > > Hello guys, > > I don't know how to bottom-post on a thread from April 2015, but the above > subject line is still the same. > > I'm implementing ntopng and nprobe for a University (so professional license > is installed and working) and they want to test it specifically for netflow > exports coming from their 6 Cisco Wireless LAN Controllers. > > I have ntopng and nprobe setup but the GUI doesn't interpret any of the > received netflow data. The packets do arrive on the Ubuntu server though. As > a test, I exported traffic from their Cisco 6500 switch, and the GUI > displays the data correctly. > > I took a pcap dump of the received WLC traffic. It's available here: > http://1drv.ms/1mf2iuC > > Could someone please help with what I should do to get the data to display? > > Kind regards, > Yasser > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > _______________________________________________ Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > _______________________________________________ Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > _______________________________________________ Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
