Re: [Nfdump-discuss] UPDATE Re: vSphere 5.1 distributed switch to nfcapd with IPFIX
netflow collecting and processing tools
Brought to you by:
phaag
Menu
▾
▴
Re: [Nfdump-discuss] UPDATE Re: vSphere 5.1 distributed switch to nfcapd with IPFIX
|
From: Peter H. <ph...@us...> - 2013-06-22 16:09:06
|
Hi David, On 6/21/13 W25 2:39, David Walsh wrote: > Hi All, > I was having issues with the dates in IPFIX net flow packets from vSphere 5.1 vDistributed Switched at the > beginning of May. Nfsen and NFdump display the date as 1970 00:00:00 and not the current time. > After dumping the netfow packets as per Peter's suggestion and analysing in Wireshark, and seeing an issue that someone > else had raised on the VMware communities site, I opened a support case with VMware. > > After a bit of back and forwards, I received a response from an engineer this morning. > > Peter, would you be able to have a read and comment on his (VMware's point of view) answer please? Hmm .. the comment is not very helpful. In the wireshark screenshot, you clearly can see, that the version is 10. This means it's IPFIX and not netflow of any version. Exactly at that point, netflow is different from IPFIX, in that IPFIX uses other timestamp models. Although, the reference is netflow v9 which is different. It seems to me, that the VMware reference is not IPFIX compatible. I need to check the pcap, when I'm back in the office. Sorry for the delay. Stay tuned. - Peter > > > " > Hello David, > > My name is XXXXX and I am a senior engineer assisting XXXXX on this SR. Our sincere apologies for the delay here. One of > my colleagues in our Escalations Team got a chance to reproduce this. > > As per the standard defined by Cisco for Netflow packet header, time is calculated in 'Unix Seconds' i.e. Seconds since > 0000 Coordinated Universal Time (UTC) 1970. > > Details: > > http://www.cisco.com/en/US/docs/ios-xml/ios/netflow/configuration/12-4t/cfg-nflow-data-expt.html > > In the example cited by you earlier (see attached screesnhot), the duration of the flow if 0 seconds: > > [Duration: 0.000000000 seconds] > StartTime: Jan 22, 1970 09:06:47.000000000 EST > EndTime: Jan 22, 1970 09:06:47.000000000 EST > > hence the start time and the end time are same. In our opinion this "time setting" is default as per Cisco's > Implementation and would be noticed with any netflow enabled device. > > I am not in office tomorrow however we can discuss this on Monday. Let me know if you have any questions in the interim. > " > > > This was the screenshot in Wireshark I sent them to help track down my issue. > > > > > > On 07/05/2013, at 5:10 PM, Peter Haag <ph...@us... <mailto:ph...@us...>> wrote: > >> >> Run something like: >> >> ./tcpdump -n -i <if> -s 1600 -w /tmp/vsphere.pcap 'port xxxxx' >> >> Let it run for a couple of minutes - at least twice the template repeat time and send me the pcap. >> >> Thanks >> >> - Peter >> >> On 7/5/13 2:44 AM, David Walsh wrote: >>> Hi, >>> I have some vSphere 5.1 VDS's sending IPFIX net flow to our nfsen server. (nfsen v 1.3.5) >>> >>> I am running nfdump Version: 1.6.9 with the IPFIX patch posted on this list on the 13/4/2013 by Peter. >>> >>> I am receiving the net flow data and below is the output in raw form after I applied the patch. You will notice that >>> "first" and "last" are set on 1970-01-01 10:00:00. There is an up to date time in the last variable of the packet in >>> "received at". >>> >>> NFsen can read the data and it is correct (I compare it to data we pull via snmp) however NFsen /ndump are formatting >>> the data with timestamps of 1970-01-01 10:00:00 instead of the actual time. >>> >>> I notice this has been raised on various sites but I have not seen a fix. I don't mind testing some patches if they >>> become available to fix up this timestamp issue. >>> >>> >>> >>> # nfdump -M /opt/data/nfsen/profiles-data/live/netflow-vds-vsh -R 2013/05/03/nfcapd.201305031040 -c 100 -o raw >>> >>> >>> Flow Record: >>> Flags = 0x06 FLOW, Unsampled >>> export sysid = 2 >>> size = 72 >>> first = 0 [1970-01-01 10:00:00] >>> last = 0 [1970-01-01 10:00:00] >>> msec_first = 0 >>> msec_last = 0 >>> src addr = 110.175.94.222 >>> dst addr = 192.168.64.6 >>> src port = 58464 >>> dst port = 443 >>> fwd status = 157 >>> tcp flags = 0x00 ...... >>> proto = 6 >>> (src)tos = 0 >>> (in)packets = 9 >>> (in)bytes = 1500 >>> input = 1678 >>> output = 1799 >>> ip router = 10.1.4.39 >>> received at = 1367541600163 [2013-05-03 10:40:00.163] >>> >>> >>> Flow Record: >>> Flags = 0x06 FLOW, Unsampled >>> export sysid = 2 >>> size = 72 >>> first = 0 [1970-01-01 10:00:00] >>> last = 0 [1970-01-01 10:00:00] >>> msec_first = 0 >>> msec_last = 0 >>> src addr = 101.163.67.76 >>> dst addr = 192.168.64.6 >>> src port = 2735 >>> dst port = 443 >>> fwd status = 255 >>> tcp flags = 0x00 ...... >>> proto = 6 >>> (src)tos = 0 >>> (in)packets = 1 >>> (in)bytes = 40 >>> input = 1678 >>> output = 1799 >>> ip router = 10.1.4.39 >>> received at = 1367541600163 [2013-05-03 10:40:00.163] >>> >>> Kind Regards, >>> David >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>> their applications. This 200-page book is written by three acclaimed >>> leaders in the field. The early access version is available now. >>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >>> _______________________________________________ >>> Nfdump-discuss mailing list >>> Nfd...@li... <mailto:Nfd...@li...> >>> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss >>> >> >> -- >> Be nice to your netflow data. Use NfSen and nfdump :) > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > Nfdump-discuss mailing list > Nfd...@li... > https://lists.sourceforge.net/lists/listinfo/nfdump-discuss > -- -- Be nice to your netflow data |