If you were waiting to upgrade from ASA 8.4(5), because you would lose bidirectional flow exports, then wait no more. Cisco ASA NetFlow Bidirectional support has been added in version 9.1(2).
If you recall, bidirectional flows were removed in versions 8.5(1), 8.6(1), 8.7(1), 9.0(1), and 9.1(1). As a result, those who chose to update from 8.4(5) lost the ability to receive true bidirectional flows from their ASA. This changes in v9.1(2), where Cisco has re-enabled these features.
What does this mean exactly? The ASA exports multiple templates which represent different types of flows.
ASA NSEL Templates
- Extended: if the flow is torn down before the configured delay, the flow-create event is not sent; an extended flow teardown event is sent instead.
- Denied: flow was explicitly denied from being created in the first place. A Denied no XLATE event shows that the event was denied and no translation of the source and destination IP addresses and ports is done. This is typical when using NAT addresses.
- Flow Created: event is exported as soon as the flow is created
- Teardown: events indicate that an existing flow in the flow database of the appliance has ended. It could be due to “natural” causes (TCP: fin/fin-ack/ack, UDP: firewall times it out), or it could be a flow that has a problem detected midstream and the firewall shuts it off. The Teardown event will give you the total byte count (both inbound and outbound) for the entire flow in the octetTotalCounts field.
- Flow Update: For long lived flows, records are periodically sent with the delta byte counts since the last flow-update event. Nothing is sent for the last minute the flow is active (I.e. bytes are lost). Also nothing is sent for short lived flows (I.e. no bytes are sent).
Keeping the 5 templates outlined above in mind, the following is the flow export behavior in version 9.1(2).
- If only the flow-update template is exported and a flow is short lived, no information is sent on the flow.
- If only the flow-teardown template is exported and the flow is short lived. At flow teardown, a flow-teardown record is sent containing the total byte count over the life of the flow.
- If both the flow-update and flow-teardown templates are exported and the flow is short lived. At flow teardown, only a flow-teardown record is sent containing the total byte count over the life of the flow.
- If only the flow-update template is exported and a flow is long lived, flow-update records are periodically sent with the delta byte counts since the last flow-update event. At flow teardown nothing is sent and the sum of all delta byte counts may fall short of the actual number of bytes sent over the life of the flow. In other words, the actual flow is under reported because the last update is never sent.
- If only the flow-teardown is exported and the flow is long lived. At flow teardown, a flow-teardown record is sent containing the total byte count over the life of the flow.
- If both the flow-update and flow-teardown are exported and the flow is long lived. Flow-update records are periodically sent with the delta byte count since the last flow-update event. A flow-teardown record is also sent containing the total byte count over the life of the flow.
In short, the active timeout issue is still not resolved and vendors must use the flow-teardown to report on 100% of the data. This can result in spikes in the trends with utilization well over 100% in some intervals. Because of the above behavior, if the NetFlow reporting solution uses both the flow-update and flow-teardown templates the reports will be over stated. This is because the flow tear-down contains all the bytes that were incrementally reported by the flow-update. Also, the last few bytes of a long-lived flow are reported by tear-down templates, but not the flow-update. If only the flow-update is used for reporting, then short lived flows aren’t reported. Confused?
Cisco Engineers are aware of the above and we are hoping that they address it soon.
Bidirectional Flows
- Most NetFlow/IPFIX implementations are unidirectional, meaning TCP connections between two hosts result in two flows (i.e. A to B and B to A). This is because flows are generally only metered inbound, or ingress, on interfaces and the responding flow is captured on a different interface. Hence two flows. Bidirectional flows should be implemented according to RFC 5103, where a single flow represents A to B and B to A. Obviously the size of the flow increases by almost double, however, it can result in nearly half the volume of flows back to the high volume NetFlow collector. The SonicWALL IPFIX configuration is the only vendor we have seen implement this according to RFC 5103. Bidirectional flows from the Cisco ASA NetFlow export are not RFC 5103 compliant and have generally led to confusion. Without Cisco ASA 8.4(5) or 9.1(2) NetFlow, the Cisco ASA exports a single flow record with a total of how much traffic was transferred between both hosts; however, the Cisco ASA NetFlow exports do not indicate how much of the total went in each direction.
So if you were waiting to upgrade from 8.4(5), upgrade today! With Cisco ASA NSEL v9.1(2) you can get true bidirectional flows.