For more details, please see ourCookie Policy.

Service Providers

“SDN-Based” Network Analytics is here… Now.

by pmoyer ‎10-23-2015 02:10 PM - edited ‎10-23-2015 02:25 PM (4,745 Views)

Network analytics is all the buzz these days. Every network operator needs to understand the traffic on their network so they can ensure that they are providing high-value services and/or to determine a way to monetize their network. The Data Center and Enterprise network operators we talk to want vendors to provide the proper solution; however, the solutions that are available today either require a network architecture change or they provide a very in-efficient and tedious data collection capability. The bottom line is that real-time network analytics is not just marketing buzz; its real and its desperately needed.


Network analytics is often tied to another huge market buzzword – Big Data. While Big Data and Analytics are often spoken of together, I’m going to focus specifically on the analytics side of that conversation. I’ll focus this blog on the what and how of network analytics; and more specifically, how does SDN improve network analytics?


In a previous blog I mentioned what could be possible when network analytics meets SDN & OpenFlow. Now I’ll delve into the guts of how an SDN solution is now ripe for deployment.


There are two segments of network analytics that are relevant to this discussion:


  1. How do you capture the interesting network data-plane traffic and what type of flows do you need to capture? Let’s call this data collection; the focal topic of this blog.
  2. What do you do with this data once captured? Let’s call this data analysis; a focal point for a future blog.


The Problem


To start, the current mode of operation for data traffic collection is extremely challenging. It is cumbersome, complex, not very dynamic and often very expensive. This is where SDN and more specifically, OpenFlow, comes in to save the day.


There are many problems associated with the current methods for capturing data plane traffic in networks. One solution requires network taps to be physically deployed through-out the network. The other option is to use span ports on routers and switches to duplicate traffic into an out-of-band “monitoring or visibility fabric”. The challenges with both of those solutions are multi-dimensional: they are expensive, they can be intrusive to deploy and manage, and they may not be able to capture all the relevant data. While the concept of deploying a dedicated, out-of-band visibility fabric in data centers has recently begun to gain some industry traction, it is a very expensive proposition. The visibility fabric adds an additional layer of switches in the data center that only provide one function – that being, to receive the data traffic from network taps or router/switch span ports and to filter and direct that traffic to the various analytics tools that are being used. Talk about an expensive solution in terms of CAPEX and OPEX!


If an operator chooses not to deploy a dedicated visibility fabric, then complex ACL-policies can be configured in routers and switches to filter which types of traffic gets duplicated to the various analytics tools that are being used. The challenge with this mode of operation is that there are many different types of limitations in networking gear related to providing this capability. Especially in terms of things that really matter to operators; like scale, complexity, the granularity of data traffic filtering and the ability to duplicate data flows to multiple tools. Sure, you may be able to accomplish some type of traffic filtering in the router by configuring these complex ACL-policies, but that’s a very thorny schematic to deploy and manage. Furthermore, it lacks a real-time and dynamic update capability and is not centrally managed. Just how do you operate and manage the tens or hundreds of these ACL-policies scattered across the many routers and switches in your network?


The Answer


There are a few key requests that we hear from our customers when discussing a solution that solves the problem of data collection for network analytics. How can we make it easier for them to deploy and operate and how can we provide this without the high CAPEX associated with deploying a dedicated visibility fabric?


Our answer includes an efficient and programmatic approach that comes with an SDN-based solution; and it provides this without a dedicated visibility fabric and without the cumbersome and problematic issues associated with network tap and span port based solutions. It provides high levels of granularity in terms of traffic filtering, it does this at scale, it is efficient, dynamic and centrally managed via a slick GUI, and there are no complex ACL-policies to configure. “Say what?”


It’s an efficient and inline answer to this problem. And this capability is now available with Brocade products that are already deployed in production networks; and to be more specific about the benefit of being inline, the concept of a visibility fabric is collapsed into the network infrastructure itself; it does not sit off to the side of the network.


Here’s what it looks like from a high level.




This solution introduces an SDN controller based approach, as shown above. It also leverages the highly programmatic toolset that comes with OpenFlow; and combines that with innovative features that are available in our MLX and ICX platforms. The MLX core router shown in the diagram is also functioning as an inline per-flow mirroring platform; otherwise known as a FlowTap device. The FlowTap device can also be an ICX. Our Brocade Flow Optimizer (BFO) application, that already provides an elegant SDN solution for various other use cases, now supports this FlowTap use case. User defined policies are input into the BFO app as profiles and these profiles determine the matching criteria of the flows that are then mirrored to analytics devices. The key secret sauce here is that the normal forwarding of those flows is not interrupted. Copies of those flows are mirrored by OpenFlow to egress ports that are connected to various analytic devices. Think about that for a second … this solution allows the operator, using the slick GUI provided by BFO, to mirror any flow that traverses their production network (consisting of MLX routers and ICX switches) to their various analytic tools, without interrupting or impacting the normal forwarding of those flows. Cool, huh!


This provides an inline data collection capability, along with all the dynamic and programmatic matching capabilities that you get with OpenFlow. This also leverages the hybrid port mode that the MLX and ICX platforms support. In fact, hybrid port mode is the enabler of this solution because without it this type of inline mirroring capability would not be possible. While the diagram shows the analytic device(s) hanging directly off of the FlowTap device (an MLX in this example), this is not absolutely required. A remote mirroring capability is also possible by leveraging a tunneling mechanism with this solution and remote mirroring will be further enhanced in future versions of BFO and MLX software. I will write another blog when those additional enhancements are available.


One additional note worth mentioning is that you may have noticed from the diagram that sFlow is part of the solution. The sFlow component is optional in this use case. The operator does not need to enable or use sFlow to obtain the real-time and dynamic data collection capability this SDN solution provides. However, leveraging sFlow with this solution provides additional benefits in terms of network visibility. When sFlow is enabled with this solution, the network operators gain a substantial level of network traffic visibility that is provided from sFlow packet sampling. The BFO application collects the sFlow samples and this provides a Dynamic Flow Learning and Reporting enhancement to this FlowTap analytics solution. This provides real-time traffic visibility for L2, L3 (IPv4/IPv6), MPLS and even VxLAN flows and this visibility is built into the BFO application.


This blog did not touch on the analytic devices themselves; in other words, what type of data analytics devices are needed to provide useful analysis of the data that is being mirrored? Those analytic tools will be covered in a separate blog but suffice it to say that there are plenty of open-source and commercial tools available that provide various analytic capabilities; such as operational troubleshooting, performance analysis, security, etc.


To add to this, in the not-too-distant future, a Machine Learning (ML) capability could be combined to a network analytics solution such as this. That would be an incredibly powerful capability for network analytics this is not available anywhere today.


Well, I hope this blog provides an introduction to our SDN-based network analytics solution. To recap the highlights, this SDN-based solution provides an elegant, efficient, dynamic and real-time data collection and data visibility offering that is not available from other vendors. And it provides this without requiring physical changes to the network architecture and in particular, it does this without the need to deploy a dedicated out-of-band visibility or monitoring fabric.


As usual, please ask questions or provide comments in the comment section of this page. Also, if you are a network operator who wants to fully understand the specifics of this powerful solution, please reach out to your Brocade Sales team for a deep-dive discussion or even a remote demo of this solution. And stay tuned for further updates on this solution in subsequent blogs!