Leveraging the vSphere 5.0 NetFlow support to monitor and report traffic data in a Service Provider vCloud environment

One of the cool networking features in vSphere 5.0 is the built-in support for NetFlow. This was first introduced in VI3.5 as an experimental feature and then it vanished, for some reason, in vSphere 4.x.

I’ve blogged already about NetFlow with VI3.5 in this blog post, and I explained how you can configure it form the command line on an ESX host to push the Netflow data to an external collector/analyzer.

The cool thing is that now it is fully supported in vSphere 5.0 and it can be configured also right from the GUI. Let’s have a quick look first on this.

Configuring NetFlow on the vNetwork Distributed Switch

1 – You will need to go to your networking panel in vSphere 5.0 and choose the vNetwork Distributed Switch (vDS) you want, and then right click and choose “Edit Settings”

2 – Go to the “NetFlow” tab and then fill the required fields as shown in the screenshot below.

3 – The first field is the NetFlow collector/analyzer IP address and the relevant port it will be listening to. The second field is the vDS IP which I must say can cause a lot of confusion. This doesn’t have to be a real IP address, it’s more of an identifier, if you will. This IP address will *not* be attached to any ESX vNIC. Think of it as if you are sending an email to someone with “your name” in the sender field so that the recipient knows from where it’s coming from. It’s important in our case here because you will probably have many ESX hosts in the cluster, each sending the data to the same collector. The unified IP address here is meant to tell that collector that all these data are coming from the same source/router rather than different ones.

4 – The rest of the settings are self explanatory and aimed to tweak the NetFlow exporting settings. Just keep in mind that if you set the “Sampling rate” to “0” the sampling will be disabled and you will be pushing all the traffic stats. This is of course the most accurate results you will have but in the same time it may require more resources from the ESX hosts in a busy network environment.

5 – In our case here, we are typically selecting the “External Networks” vDS which will have the external traffic of the customers/tenants in the SP (typically out to the Internet or their Site-to-Site VPN)

6 – Last step is to enable the NetFlow monitoring on the designated ports, up-links or port-groups. In our case here, I enabled the monitoring on a port-group which is in effect an external network for a pool of customers.

Use cases for a vCloud Service Provider

I’ll list below some of the use cases for a Service Provider applying this in their vCloud environment:

  • Traffic Reporting: Some end-customers would like to have a “live” traffic statistics for their cloud. With something like “NetFlow Analyzer” from ManageEngine (one of my all-time-favorites) , the SP can facilitate that to its customers. A scheduled reports can also be set to push the traffic statistics to each tenant based on his Organization Network.
  • Bandwidth Utilization: a customer may want to have a capped bandwidth for his/her cloud external networking or at least a notification if they exceeded a specific quota. With NetFlow (and again NF Analyzer) you can set specific thresholds so that the customer get notified if they exceeded a certain bandwidth per day/week/month ..etc.
  • Security: Through the NetFlow properties like (Protocol, Source and Destinations ports), a Service Provider can generate some security related reports like suspicious virus traffic. If you want to have a more accurate results, you can also leverage the Port-Mirroring feature in vSphere 5.0 (will talk about it in a future post)

  • DoS attacks: With NetFlow, a Service Provider can easily identify internal DoS attacks that may be launched between a tenant and another across Organization Networks or shared External Networks.

What about the Enterprises and Private Clouds?

Similar use cases can be also considered in an enterprise or a private cloud. For example, a developer may want to analyze the internal or external traffic of his applications in the cloud. A Networking/Security team may want to have a visibility into a cloud environment for troubleshooting, security, auditing (you name it) and with a tool like this, it’s quite easy and very effective to achieve that.

Conclusion

Leveraging the NetFlow support in vSphere 5.0 with 3rd-party collectors/analyzers can be a of a great benefit to any Service Provider. I’ve personally managed various ISPs in the old days and I know for a fact that with a simple protocol like NetFlow I was able to not only have the required visibility in my environment, but also have a very effective tool to monitor and troubleshoot any problems. Of course you can still leverage expensive and high-end solutions like IPSs or traffic-shapers with a lot of administration and redesigning of your network infrastructure to have the inter-VM traffic visibility, but everything has its limit at the end of the day.

Share Button