Explore the six ways a smart SD-WAN solution has helped banks eliminate network problems that…
The Worst Advice We’ve Seen About SDN
Think about keyboards for a second. If you use a smartphone everyday like I do, then you probably type a fair share of your sentences on a pop-up, software-based keyboard, with built-in autocorrect and emoji, rather than a set of dedicated and relatively limited hard keys.
The gap between the two is useful in seeing the similar differences between software-defined networking and legacy network infrastructure. That’s to say, using software provides much more flexibility, meaning smarter configuration and adaptability.
What are the biggest SDN misconceptions, myths and lies?
Still, making the shift to SDN has to be done in a smart way. Given the amount of hype around these trends, there’s plenty of bad advice and misconceptions out there. Here’s some of the worst we have seen and how you can steer clear of its effects:
1. SDN is just another network upgrade
Any organization thinking seriously about SDN should plan to dedicate much more than a weekend or a few working days to getting it right. Moreover, it’s unrealistic to think that all applications will move to the new network architecture on day one.
“SDN is an entirely new approach to how applications are routed and supported.”
So there will be quality-sensitive programs, like VoIP, that will require low packet loss and latency and as such will benefit immediately from smart bandwidth aggregation and prioritization. Others that are less demanding, such as bulk file transfers, will still be well served by a combination of MPLS and broadband links.
Think of SDN as an entirely new approach to how applications are routed and supported. It’s not a new coat of paint or a simple button that gets pushed.
2. SDN means the end of differentiated hardware
What does something software-defined have to do with hardware? Plenty.
One of the most touted value propositions of SDN is that it frees network engineering teams from having to wrangle with dedicated appliances that don’t work well in concert. Instead, SDN, through the use of protocols like OpenFlow, allows for functions to be executed on “white boxes” (commodity hardware).
However, SDN is far from the end of hardware. High-performance equipment will be critical to achieving the levels of responsiveness and availability that technology organizations and service providers require for ample return on investment. Which brings us to…
3. Performance will take care of itself in SDN implementations
SDN offers many benefits, most notably intelligent handling of packets and the potential to achieve big savings thanks to the smarter use of network resources. Performance changes have to be accounted for along the way, though.
By itself, SDN can create issues with latency. The reason is simple: Packets have to be moved back and forth between the data and management/control planes, which can drag down speed.
Accordingly, SDN solutions need precise mechanisms for intelligently handling packets. Top-notch hardware can also help close performance gaps.
4. Automation and virtualization are all that is needed for SDN
This advice is often presented when selling solutions that are similar to SDN but are not actually SDN. Programmable Ethernet fabrics, automation/orchestration tools and virtualized network functions have much in common with, despite not being, SDN.
SDN may be applied to a wide set of areas from security to network virtualization. It is more of an approach or a mechanism that can be instituted in other solutions, than a specific solution in its own right. The principles of SDN are in solutions that make it easier to manage networks without worrying about hardware.
Automation tools, network virtualization, etc. can solve problems. They just shouldn’t be confused with SDN.
5. SDN solves all security problems
Security is one of the biggest potential perks of SDN. More specifically, SDN enables granular management of both perimeter and internal traffic as they are routed through the same firewall. The flow-based nature of SDN allows for fine-grained security policies.
At the same time, there are security concerns to keep an eye on. SDN controllers have to be shielded against denial-of-service attacks. Controllers also need plans for routing traffic in the wake of an outage.