<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2975524&amp;fmt=gif">
BLOG

The Controller Problem in Software-Defined Networking

October 12, 2017

SDN and NFV controller network visibility garland technology
It was great to see our technology partner, Big Switch Networks, included in this year’s Gartner Magic Quadrant for Data Center Networking. After years of using the Big Monitoring Fabric (BMF) as a network packet broker/Trojan horse to get into the data center, Big Cloud Fabric (BCF) is driving the commercial, cost-effective SDN fabric market forward.

But if you read through the Gartner report, you’ll find a cautionary statement that we want to address:

“Despite being an early proponent of open SDN and OpenFlow, Big Switch uses a proprietary protocol within its BCF. Thus, third-party switches cannot be integrated into BCF.”—from the Gartner Magic Quadrant for Data Center Networking

This reported concern is worth discussing because it harks back to something that's seemed to hold software-defined networking back for yearsthe open controller. 

Fabric Solutions vs. the Open SDN Future That Was Promised

In a perfect world, software-defined networking would drive cost efficiency because the separation of control and data planes would be rooted in bare metal switches and vendor-independent hardware/software. That was part of the promise that drove SDN to peak-hype around 2012 and 2013.

But the most important part of this open SDN vision was the open-source controller that would power programmatic capabilities. There were a number of unique controllers, but OpenFlow was one of the earliest and seemed poised to become the standard for SDN deployments.

>> Download Now: Visibility Architecture in SDN & NFV Environments [Free whitepaper]


However, standardizing OpenFlow proved to more of an uphill battle than the open source community may have expected. This is where fabric solutions have stepped in.
Fabrics have become the new normal to bridge the gap between traditional vendor-locked data centers and the open SDN future. Some parts of fabric architectures are proprietary, but they can still offer SDN benefits like programmability and centralized control.

When you look at Gartner’s warning about the Big Cloud Fabric, you might think that Big Switch Networks errs more on the side of vendor lock-in than you’d like. In reality, these SDN fabric solutions can get you closer to open SDN than expected.

Balancing Proprietary Architecture with Open SDN Controllers

Proprietary aspects of SDN fabrics like the Big Cloud Fabric are necessities at this stage of SDN maturity. Without them, businesses looking for the agility and flexibility of a software-defined network would have to come up with makeshift solutions while waiting for true SDN solutions.

But the proprietary protocol that Big Switch Networks uses in BCF is actually an open source project. It’s called Project Floodlight and the SDN controller is based on the OpenFlow protocol that rose to prominence early in the software-defined networking story. With OpenFlow at its core, Floodight® lets BCF deployments work with both physical and virtual switches so you can take advantage of SDN benefits.

Big Switch may have started Project Floodlight, but the commitment to open source has led to an ever-growing list of switches, routers, virtual switches, and access points that integrate with the SDN fabric solutions based on the protocol. If vendor lock-in is your concern, you can be sure that it’s possible to achieve SDN in the data center without missing out on the flexibility of open source hardware and software.

The real question you should be asking yourself is whether or not your data center network is set up for visibility across all these fabric components. A centralized, programmable, open source controller won’t do much good if you’re constantly dropping packets—which is why our partnership with Big Switch networks is so strong.

Looking to add visibility to your SDN deployment, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do!

SDN and NFV environment visibility architecture

See Everything. Secure Everything.

Contact us now to secure and optimized your network operations

Heartbeats Packets Inside the Bypass TAP

If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.

If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.

While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.

Some of you may have noticed a flaw in the logic behind this solution!  You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.

Glossary

  1. Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.

  2. Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.

  3. Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.

NETWORK MANAGEMENT | THE 101 SERIES