You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
nfdump timestamps when receiving IPFIX exported data get calculated with a relative time stamp from the device instead of absolute timestamp. When this happens nfdump sets the default timestamp (the Coordinated Universal Time (UTC) 1970) for any flow and gives it a duration of 0 seconds because there is no absolute timestamp to measure the duration of the flow.
Cisco added element 160 (systemInitTimeMilliseconds dateTimeMilliseconds) into their IPFIX template so collectors could use the new option record and set the absolute time.
In the pcap attached, I can see the options template with element 160 sent (Frame 168), I see the Date Set with "System Init Time" (Frame 174), and the Data sent with the correct StartTime and EndTime (Frame 180).
With this being sent I still see the coordinated Universal Time stamp in the nfdump output. Is nfdump able to identify the new option record and utilize it or does something need to be done to see that?
Trying with nfdump-1.6.23 which should have fix for element 160,
praines
changed the title
nfdump: IPFIX Timestamps with releative timestamp instead of absolute
nfdump: IPFIX Timestamps with relative timestamp instead of absolute
Nov 4, 2022
Device: Cisco NCS6K - 7.6.1 release
nfdump ver: 1.6.21
This is a follow up to issue #260.
nfdump timestamps when receiving IPFIX exported data get calculated with a relative time stamp from the device instead of absolute timestamp. When this happens nfdump sets the default timestamp (the Coordinated Universal Time (UTC) 1970) for any flow and gives it a duration of 0 seconds because there is no absolute timestamp to measure the duration of the flow.
Cisco added element 160 (systemInitTimeMilliseconds dateTimeMilliseconds) into their IPFIX template so collectors could use the new option record and set the absolute time.
In the pcap attached, I can see the options template with element 160 sent (Frame 168), I see the Date Set with "System Init Time" (Frame 174), and the Data sent with the correct StartTime and EndTime (Frame 180).
With this being sent I still see the coordinated Universal Time stamp in the nfdump output. Is nfdump able to identify the new option record and utilize it or does something need to be done to see that?
nfdump -R nfcapd.202211031755
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
1970-01-01 00:00:00.000 0.000 HOST 200.3.23.1:0 -> 109.130.0.35:0 13 13078 1
1970-01-01 00:00:00.000 0.000 HOST 200.3.18.1:0 -> 109.130.0.55:0 8 12000 1
1970-01-01 00:00:00.000 0.000 HOST 200.3.21.1:0 -> 109.130.0.35:0 4 4024 1
1970-01-01 00:00:00.000 0.000 HOST 200.3.19.1:0 -> 109.130.0.55:0 6 9000 1
1970-01-01 00:00:00.000 0.000 HOST 200.3.22.1:0 -> 109.130.0.35:0 1 1006 1
Frame 168: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: JuniperN_4a:69:4d (fc:96:43:4a:69:4d), Dst: RealtekU_c6:d1:5e (52:54:00:c6:d1:5e)
Internet Protocol Version 4, Src: 137.39.254.47, Dst: 192.10.2.29
User Datagram Protocol, Src Port: 53434, Dst Port: 5000
Cisco NetFlow/IPFIX
Version: 10
Length: 36
Timestamp: Nov 3, 2022 13:42:00.000000000 Eastern Daylight Time
ExportTime: 1667497320
FlowSequence: 1170359
Observation Domain Id: 769
Set 1 [id=3] (Options Template): 338
FlowSet Id: Options Template (V10 [IPFIX]) (3)
FlowSet Length: 20
Options Template (Id = 338) (Scope Count = 1; Data Count = 1)
Template Id: 338
Total Field Count: 2
Scope Field Count: 1
Field (1/1) [Scope]: observationDomainId
0... .... .... .... = Pen provided: No
.000 0000 1001 0101 = Type: observationDomainId (149)
Length: 4
Field (1/1): systemInitTimeMilliseconds
0... .... .... .... = Pen provided: No
.000 0000 1010 0000 = Type: systemInitTimeMilliseconds (160)
Length: 8
Padding: 0000
Frame 174: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: JuniperN_4a:69:4d (fc:96:43:4a:69:4d), Dst: RealtekU_c6:d1:5e (52:54:00:c6:d1:5e)
Internet Protocol Version 4, Src: 137.39.254.47, Dst: 192.10.2.29
User Datagram Protocol, Src Port: 53434, Dst Port: 5000
Cisco NetFlow/IPFIX
Version: 10
Length: 32
Timestamp: Nov 3, 2022 13:42:18.000000000 Eastern Daylight Time
ExportTime: 1667497338
FlowSequence: 1170360
Observation Domain Id: 769
Set 1 [id=338] (1 flows)
FlowSet Id: (Data) (338)
FlowSet Length: 16
[Template Frame: 8]
Flow 1
Observation Domain Id: 769
System Init Time: Oct 13, 2022 15:22:10.653000000 Eastern Daylight Time
Frame 180: 150 bytes on wire (1200 bits), 150 bytes captured (1200 bits)
Ethernet II, Src: JuniperN_4a:69:4d (fc:96:43:4a:69:4d), Dst: RealtekU_c6:d1:5e (52:54:00:c6:d1:5e)
Internet Protocol Version 4, Src: 137.39.254.47, Dst: 192.10.2.29
User Datagram Protocol, Src Port: 53434, Dst Port: 5000
Cisco NetFlow/IPFIX
Version: 10
Length: 108
Timestamp: Nov 3, 2022 13:42:24.000000000 Eastern Daylight Time
ExportTime: 1667497344
FlowSequence: 1170361
Observation Domain Id: 769
Set 1 [id=260] (1 flows)
FlowSet Id: (Data) (260)
FlowSet Length: 92
[Template Frame: 31]
Flow 1
Packets: 3
Octets: 3018
SrcAddr: 200.3.21.1
DstAddr: 109.130.0.35
InputInt: 5
OutputInt: 182
[Duration: 48.478000000 seconds (switched)]
StartTime: 1808352.543000000 seconds
EndTime: 1808401.021000000 seconds
SrcPort: 0
DstPort: 0
SrcAS: 500
DstAS: 0
BGPNextHop: 4.50.100.2
SrcMask: 24
DstMask: 24
Cisco-7.6.1.zip
The text was updated successfully, but these errors were encountered: