Did you know you could elevate your game by leveraging NetBrain to do more than just provide a cool network topology map to impress your friends and coworkers? Now, let’s talk about something more specific — SDN strategies are only as good as those who understand the foundation.
I know, I know, I hear some of you scoffing — and did I just get an eye-roll? Paul, the point of SDN is that we get a single pane of glass management and a GUI that makes the complexity disappear. You know what, you’re correct! But what do you do if something doesn’t work like it is supposed to?
Radia Perlman brought us spanning-tree protocol (STP) back in 1985 to help solve all our switching issues. It is a great protocol and has done wonders, but did networks still experience outages? Did networks sometimes have those outages because of the very protocol that was supposed to prevent issues? Yes, and yes. However, like the oft-used expression for the greater good, you must look at the pros over the cons.
One-Minute Overview of NetBrain’s SDN Management
If you’ve been in the data center for any amount of time over the past 10+ years, you’ve experienced cross training — whether the cross training was specific and purposeful or through your daily routine of interacting with another team. You’ve probably gotten more in-depth on SAN fabrics, even if you didn’t want to. You’ve had to learn more about virtualization so that you could troubleshoot issues better. Hypervisors, controllers, virtual switches, and virtual NICs weren’t in your purview, but they had to be. Learning all these things helps you become a well rounded “T” shaped engineer that knows one or two topics like a pro, but you have a wide breadth of knowledge to cover the gambit. It has become imperative that you are no longer an “I” shaped engineer that focuses solely on a single topic; one could argue it makes you a dinosaur in today’s market and community.
Learning all these things helps you become a well rounded “T” shaped engineer that knows one or two topics like a pro, but you have a wide breadth of knowledge to cover the gambit.
For example, look at all the legacy things you’ve learned and how you’ve applied them to the modern network of Software-Defined Networking (SDN). Yes, you can get bogged down with what looks like an albatross of a process to convert your entire environment to micro-segmented white-listed security heaven – or you can look at the foundation and take the journey simply. Most environments that have deployed SDN have begun in an emulation of legacy network topologies. This legacy conversion allows you to model new SDN models around legacy VLAN limits for familiarity. You can convert your existing environment over into an SDN fabric and keep all the legacy nomenclature and capabilities while you work towards more future innovation. The great thing about this concept is that once your environment is implemented with an SDN overlay, it is a lot easier to “move around” the workloads than in years past as you can switch vNICs with hypervisor integration and change IP addressing security posturing, and access controls dynamically. Did I mention that routing and switching still come into play? As you integrate with your service providers or your WAN, you’ll still need to know OSPF, BGP, STP, and more to ensure your network interoperates appropriately.
I sincerely wish everyone reading this would deploy an SDN solution and never have an issue. But if you do have an issue, how do you plan to address it besides calling the OEM back and opening a support case?