With more vendors introducing sFlow support, we have seen some users coming with one issue in particular. The issue that 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 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, 1 out of N packets (where N is the sampling rate) is captured and sent to NetFlow Analyzer for traffic analysis.
To The Issue :
There are two main reasons for NetFlow Analyzer to not display OUT traffic:
1. NetFlow / sFlow is not enabled on all the interfaces of the monitored devices
2. Issue with exporting devices – This is specific to sFlow
1. NetFlow/sFlow not enabled on all interfaces:
By default, flow based traffic accounting is ingress in nature, ie. 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.
Now to the specific issue with sFow. What if you have enabled sFlow on all the devices, but still cannot view any OUT traffic?
2. Issue with the exporting Device:
All sFlow packets exported will have and are expected to have the following key fields:
Source Interface (Input Interface for traffic)
Source IP Address
Destination IP address
In addition to this, a flow will also have information on the Destination Interface (Output Interface for traffic) along with some other fields. Based on the destination interface value, a flow is classified as the OUT traffic for that destination interface by the reporting tools.
To explain more, every interface on a device has an unique interface index 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 Input Interface and Output Interface where Input interface value corresponds to IN traffic and Output interface value is the OUT traffic.
When devices that exports sFlow does not have an Ifindex value corresponding to the output interface, then the output interface value will be marked as 0. NetFlow Analyzer, captures this traffic and since Ifindex 0 is not a valid interface, NetFlow Analyzer cannot classify the flow as OUT traffic for any interface. What you end up seeing is all interfaces with IN traffic and no OUT traffic displayed. The Destination Interface being marked with the actual Ifindex has to be handled by the device vendor.
How do I verify this?
Simple. Packet Analysis. And this is no 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 to sFlow format and open the sFlow datagram. Expand the flow set and check if values corresponding to Input interface and Output interfaces are non zero. If they are zero, you have an issue. Look at an sFlow Datagram with 0 as the Output Interface:
Incorrect Reporting Methodology :
Many reporting tools group all the flows with Destination Interface as 0 together into a single interface and shows a combined OUT traffic. But, we believe that this is incorrect simply because OUT traffic for different interfaces should not be clubbed into a single interface’s OUT traffic. It does not help in any capacity planning or trend analysis nor in getting a proper idea on traffic patterns.
NetFlow Analyzer does not show traffic heading to null interface as we believe not showing any reports rather than showing incorrect traffic.
And keep pushing your device vendor to handle this issue in their next firmware rather than being satisfied with an incorrect report.
Thanks and Regards