NetFlow如何決定方向：
NetFlow Direction and it’s Value to Troubleshooting
https://www.plixer.com/blog/netflow-and-ipfix-2/netflow-direction-and-its-value-to-troubleshooting/
Strategies used that attempt to determine flow direction but, aren’t entirely reliable include:
- Comparison of flow start times
- Lowest source port = server
- The relationship of A and B with other hosts on the network. A host with many connections to unique hosts ‘could’ be a server.
- Byte volumes: the host with the lower sent octet delta count is the client. This can be very misleading.
- Observation of TCP flags however, due to flow technologies aggregation methods, this strategy generally fails.
- Examining TTL metrics (if exported) – doesn’t provide a definitive answer.
- Consideration of how the flows were metered (I.e. ingress or egress) however, this is unreliable as some vendors only support egress. In other cases both are exported. Frankly, I never really understood why this was a good strategy. Perhaps someone could share their insight on this.
總結(jié)：基于硬件，比較準(zhǔn)確。
官方文檔：
IP Flow Information Export (IPFIX) Entities
http://www.iana.org/assignments/ipfix/ipfix.xhtml
Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
https://tools.ietf.org/html/rfc5103
Wikipedia：
NetFlow
https://en.wikipedia.org/wiki/NetFlow
pcap轉(zhuǎn)NetFlow以及時(shí)間戳問題
https://sourceforge.net/p/nfdump/mailman/message/23791576/
>> $ nfcapd -p9995 -l ./netflow/
>> $ softflowd -n 127.0.0.1:9995 -r dump.pcap
時(shí)間戳不太對(duì)。而且一個(gè)雙向流會(huì)被拆分成兩個(gè)。
nfcapd -f pcap #辦不到
tshark讀取pcap
tcpreplay，centos
