Software-defined networking has come into the spotlight in the IT and networking worlds for good reason. Like any alternative that offers significant cost savings, SDN is the new buzzword that has execs tapping their technology professionals to investigate further.
Rather than using costly brand-name switches to connect your monitoring tools, SDN centralizes network control by separating control logic to off-device computers. It empowers you with a great amount of flexibility and programmable control over how packets and traffic travel across your network.
Compared to the expense of a Cisco switch, for example, it would seem that the use of bare-metal switches and software-defined networking would be the obvious foundation for your network design.
But, if that were truly the case, why is there a virtual 50/50 split between IT decision makers on whether or not to adopt SDN?
As they look five years into the future, these same decision makers are far more bullish on software-defined networking: 77% believe that SDN will be implemented by most businesses, according to the above-referenced Juniper survey.
As for now, however, the oft-spoken methodology still has its areas of concern, many of which are founded in the true, total cost of investment.
SDN appears to be a big money saver on the surface, given its minimal implementation investment, but its true cost runs deeper. You’re not simply going to implement software-defined networking tomorrow and hit the ground running. While the largest enterprises in the world may only be concerned with developing the highest-performing networks regardless of cost, the large majority of businesses suffer from the expense of creating an SDN-ready environment.
The operation of most network security functions today must change in order for them to work in an SDN environment. When the SDN stack jointly meets your physical infrastructure and hypervisor in cloud environments, your monitoring process no longer has the checks in place to thwart attackers.
IDS/IPS also suffers from dropped Ethernet frames and the lagging rate at which an SDN software stack replicates traffic on ports, exposing you to greater risk of costly data breaches. As we discussed in a previous blog, the impact on profits can be crippling.
One of the supposed benefits of software-defined networking is its dynamic provisioning and automation. Yet, is this truly a benefit offered from day one? If you want to leverage SDN for DevOps and streamline the controls of your network services and processes, it takes a significant investment in DevOps, which most companies simply don’t have the budget for. It’s also yet to be proven whether this is absolutely possible.
Network engineers have developed skill sets to take advantage of physical network components and monitoring tools. SDN opens you up to advantageous functionality, but it will take time to adapt to a radically different way to manage your network. Expect to work through issues in the early stages when you face never-before-seen situations. Working through these trial-and-error issues and other costs of education is inevitable – and it’s going to impact your bottom line.
With potentially larger costs, ones that go beyond the basis of implementation, it’s important to understand exactly how your network is going to function and what it really takes to reap the benefits of software-defined networking. With an incomplete understanding of how you’ll integrate SDN with the rest of your network infrastructure, you risk your network’s security and your bottom line.
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!
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.
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.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.