problems with netflow from dVS 5.1

[Jingati]

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?

[vmroyale]

Note: Discussion successfully moved from VMware Knowledge Base to VMware vSphere™ vNetwork

[candace]

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.

[shiouchi]

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.

[shiouchi]

I tested VMware ESXi v5.5 these days, and I found these annoying bugs are fixed!