I capture some netflow generated from vDS5.1. It uses v10 protocol. When use wireshark to check the data flow sets, I found all the values for "StartTime" and "EndTime" are in 1970. According to spec, they should be the absolute time.
This is an example shows the dissecting result:
The hex values for StartTime is: 0x00012fd1 (the packet is taken today, Dec. 13, 2012
Set 1
FlowSet Id: (Data) (256)
FlowSet Length: 56
Flow 1
Octets: 229
Packets: 1
SrcAddr: 10.8.1.16 (10.8.1.16)
DstAddr: 10.8.255.255 (10.8.255.255)
SrcPort: 138
DstPort: 138
InputInt: 0
OutputInt: 10
Enterprise Private entry: ((null)) Type 888: Value (hex bytes): 00 00 00 00
[Duration: 0.000000000 seconds]
StartTime: Jan 1, 1970 13:36:17.000000000 Pacific Standard Time
EndTime: Jan 1, 1970 13:36:17.000000000 Pacific Standard Time
Protocol: 17
Flow End Reason: Idle timeout (1)
Padding (2 bytes)
How do we know the actual time the data set was generated?
Note: Discussion successfully moved from VMware Knowledge Base to VMware vSphere™ vNetwork
I wonder why VMware are not looking at this? I have a ticket open for this problem and I have had no update at all.
Unfortunately, we can not get the actual time. What is set in the StartTime/Endtime - the System Uptime.
In netflow v9 or earlier, there are "System Uptime" field and "UNIX Seconds" field in the header of a netflow record so that you can culculate the actual StartTime/EndTime with a sysuptime-relative StartTime/EndTime. But v10 header has no such field.
The StartTime/EndTime must contain the absolute time indeed, VMware made a mistake and it still be there.
I tested VMware ESXi v5.5 these days, and I found these annoying bugs are fixed!