With more vendors introducing sFlow support, we have seen some users running into one issue in particular: they are unable to see OUT traffic from the sFlow device within NetFlow Analyzer. Let me try to explain why this is happening.
An overview on sFlow technology
sFlow, like NetFlow, is a monitoring technology that allows you to capture the traffic data from a switched or routed network to give complete visibility into the use of network bandwidth.
sFlow datagrams are exported based on sampling, which minimizes the impact on device CPU, memory, and available bandwidth. Based on a defined sampling rate, one out of N packets (where N is the sampling rate) is captured and sent to NetFlow Analyzer for traffic analysis.
The issue
There are two main reasons for NetFlow Analyzer not displaying OUT traffic:
- NetFlow/sFlow is not enabled on all the interfaces of the monitored devices.
- There is an issue with the exporting devices, which is specific to sFlow.
1. NetFlow/sFlow not enabled on all interfaces
By default, only IN traffic across an interface is accounted for. However, we can capture the OUT traffic for other interfaces from this IN traffic because a captured flow will contain information on the exit interface of the traffic flow. So, in order to view both IN and OUT traffic graphs for a specific interface, NetFlow/sFlow should be enabled on all the interfaces through which traffic flows.
2. Issue with the exporting device
Now to the specific issue with sFlow. What if you have enabled sFlow on all the devices but still cannot view any OUT traffic?
All sFlow packets exported are expected to include the following key fields:
- Source interface (input interface for traffic)
- Destination interface (output interface for traffic)
- Source IP address
- Destination IP address
- Protocol
- Source port
- Destination port
- ToS
Based on the destination interface value, a flow is classified as the OUT traffic for that destination interface by the reporting tools.
Every interface on a device has a unique interface index (inIndex), and based on the ifIndex value, NetFlow Analyzer adds that interface to the product for reporting. The sFlow packets exported from the device contain these ifIndex values for the input interface and the output interface, where the input interface value corresponds to IN traffic and the output interface value corresponds to OUT traffic.
When a device that exports sFlow does not have an ifIndex value corresponding to the output interface, the output interface value will be marked as zero. NetFlow Analyzer captures this traffic, and since ifIndex zero is not a valid interface value, NetFlow Analyzer cannot classify the flow as OUT traffic for any interface. What you end up seeing is all the interfaces with IN traffic and no OUT traffic displayed. The device vendor has to handle marking the destination interface with the actual ifIndex.
How do you verify this?
Simple. Packet analysis. This is not rocket science. Install a packet capture program (Wireshark is the best I have worked with) on the NetFlow Analyzer server and capture the sFlow packets from the exporting device. After you have a few minutes of packet capture, select the UDP packet, decode it into sFlow format, and open the sFlow datagram. Expand the flow set and check if the values corresponding to the input interface and output interface are nonzero. If they are zero, you have an issue. Here’s an sFlow datagram with zero as the output interface:
Incorrect reporting methodology
Many reporting tools group all the flows with a destination interface value of zero together into a single interface and show the combined OUT traffic. But we believe that this is wrong simply because OUT traffic for different interfaces should not be grouped into a single interface’s OUT traffic. It does not help in capacity planning, trend analysis, or getting a proper idea of traffic patterns.
NetFlow Analyzer does not show traffic heading to null interfaces as we believe not showing any reports is better than showing incorrect traffic. Keep pushing your device vendor to handle this issue in their next firmware update rather than being satisfied with an incorrect report.
Download | Interactive demo | Customers | Bandwidth monitoring | Network security | CBQoS monitoring
Thank you for the information. I can attest that turning on ip route-cache cef on all of the interfaces solved the problem for me.