Unified visibility is needed for the dynamic infrastructure of today, the SDNs of tomorrow

By Huy Nguyen, Gigamon senior director of product management, Network World |  Networking

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

The promise of software defined networking (SDN) is to deliver centralized and programmable traffic engineering. However, one of the obstacles standing in the way of mass SDN deployment is visibility.  Questions persist about how organizations will monitor these dynamic data networks.

These agile and diverse networks, after all, could be comprised of mixed network architectures and topologies, contain non-interoperable "islands" of SDN stemming from varying implementations of OpenFlow standards, and have applications residing on multi-tenant servers. Yet this doesn't mean that we can't look to an SDN approach and use it as a model for a unified monitoring fabric.

However, so far, current solutions do not address the new monitoring complexities that have evolved and will continue to worsen with SDN. Effective ways to manage and provision monitored network traffic pervasively across different topologies remains elusive. Let's take a look at the three main reasons why current propositions aren't suited to solve the problem of monitoring the SDN production network and why a unified monitoring fabric is required.

First, there may be value in the coexistence of both centralized architectures and the distributed network protocols of today. SDN may not be right for every organization. Plus, it is highly unlikely that any organization will "forklift" their entire network infrastructure for SDN-enabled technology. This will result in mixed topologies and there is no method that exists today to achieve pervasive traffic visibility across physical networks, virtual networks and hybrid networks that contain traditional network topologies and SDN.

Second, depending on the deployment use case, a different SDN solution may be deployed for each scenario. For example, a network virtualization application may deploy a specific controller and switch eco-system.  A traffic engineering solution may require a different controller and switch eco-system. This is largely due to the lack of northbound APIs which results in applications being tied to a controller-switch ecosystem today.

The result is islands of SDN that are best suited to specific problem areas.  However, there still needs to be a consistent way to monitor, troubleshoot and manage these SDN islands and optimally deliver monitored traffic to the tools that serve as the dashboard for the network, security and applications teams.


Originally published on Network World |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

NetworkingWhite Papers & Webcasts

See more White Papers | Webcasts

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question