NetFlow is a protocol for exporting aggregated IP flow totals. As such it is well suited to IP traffic accounting on Internet routers. With Netflow V9 (AKA IPFIX it can look into Layer 2 traffic as well)
sFlow is a general purpose network traffic measurement system technology. sFlow is designed to be embedded in any network device and to provide continuous statistics on any protocol (L2, L3, L4, and up to L7), so that all traffic throughout a network can be accurately characterized and monitored. These statistics are essential for congestion control, troubleshooting, security surveillance, network planning etc. They can also be used for IP accounting purposes.
Netflow mirrors all traffic, and places a load on the CPU when utilised.
SFlow is a packet sampling technology where the switch captures every 100th packet (configurable) per interface and sends it off to the collector. sFlow is built into the ASIC, and places minimal load on the CPU.
Netflow supported by Cisco, Juniper, Alcatel Lucent, Huawei, Enterasys, Nortel, VMWare
sFlow supported by Alaxala, Alcatel Lucent, Allied Telesis, Arista Networks, Brocade, Cisco, Dell, D-Link, Enterasys, Extreme, Fortinet, Hewlett-Packard, Hitachi, Huawei, IBM, Juniper, LG-Ericsson, Mellanox, MRV, NEC, Netgear, Proxim Wireless, Quanta Computer, Vyatta, ZTE and ZyXEL (see sFlow link)
This error is caused by Windows 7 clients specifically.
Cisco is aware of the problem, but has never fixed the issue on the controller. Since the Cisco bug tool requires access, i've posted the answer as described by Cisco.
In our own setup with 11 to 12.000 clients a day, we get tons of these errors on our WLC 8540.
The bug can be found here:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuh22382
Case description:
Symptom: Windows 7 clients connecting to wireless networks with WPA2 and session timeout may get disconnected during the key exchange after reauthentication.
This is because on the re-keying process the Win7 clients are sending message M2 with what the WLC considers to be a MIC error. "debug client" on the WLC will show messages similar to the following:
*Dot1x_NW_MsgTask_0: Apr 01 23:27:38.321: 60:67:20:b6:20:f4 EAPOL-key M2 with invalid secure bit (set) received from mobile 60:67:20:b6:20:f4
*Dot1x_NW_MsgTask_0: Apr 01 23:27:38.321: 60:67:20:b6:20:f4 Received EAPOL-key M2 with invalid MIC from mobile 60:67:20:b6:20:f4
*osapiBsnTimer: Apr 01 23:27:39.427: 60:67:20:b6:20:f4 802.1x 'timeoutEvt' Timer expired for station 60:67:20:b6:20:f4 and for message = M2
*dot1xMsgTask: Apr 01 23:27:39.427: 60:67:20:b6:20:f4 Retransmit 1 of EAPOL-Key M1 (length 121) for mobile 60:67:20:b6:20:f4
Usually at this point, the WLC will retransmit the M1, and then the second time the client sends its M2, it will not have an invalid MIC, and the key exchange will succeed.
Conditions:Windows 7 Clients connecting to wireless network with WPA2/AES with EAP, and session timeout enabled on the WLAN.
This problem is seen with all client chipsets.
Workaround: Use WPA1 or
Disable session timeout.
This problem can be mitigated by reducing the EAPOL key retransmission timeout (e.g. "config advanced eap eapol-key-timeout 300") Do be aware that reducing this value might negatively impact key negotiations with some very old and slow clients.
More Info:How to reproduce:
- configure a WLAN with WPA2 + 802.1x (local EAP or RADIUS)
- Enable session timeout.
- Bring any Windows 7 device.
- connect to the wlan, complete authentication..
- wait for the session timeout
This bug is marked as Junked because it is a Microsoft, not a Cisco bug.
Best Answer
It is wholly dependent on the software that is collecting the flow. You would need to look up what the software vendor recommends and configure your devices accordingly. If it is higher you will get flows reporting the full flow duration instead of the say 60 second interval that is expected by certain platforms. This leads to incorrect flow accounting and general misinformation. Take the reverse for shorter flow expiration timers. If you can't find any information for your export product I would recommend 60 seconds, it is the most common in my experience.