Is SDN just a buzzword?
We all know that Google, Fastly, Facebook… are defining network as a software (yes, SDN, but the real Software Defined Network) using customized tools. But what exactly does SDN mean? SDN is a good idea, but it has been converted to a buzzword to push useless solutions from vendors to customers. So let’s forget what we know about SDN for a while. And let’s start from the very beginning.
SDN, Software Defined Network, means that network is defined by software, not humans. The word “defined” means “built”, “operated”, “monitored”, …
In other words you can have VMware NSX or Cisco ACI installed, but if you’re operating manually via browser, you don’t have an SDN solution in place. Otherwise if you have a lot of physical routers, but you’re managing them with a custom set of automatic scripts, then you’re a bit closer to an SDN solution.
Software “built” Network
The word “built” refers on how your network came up. Are you configuring devices manually one by one? Are you adding virtual networks one by one? Then no, you’re network is not an SDN solution.
An SDN solution should automatically build the required environment with almost no human interaction.
- A new device must be installed: the serial number is added to a CMDB and a role is defined. Then a set of automatic scripts do prepare and configure the device. Meraki and the new SD-WAN solutions are going this way.
- A new customer needs a new environment (VRF, routing, firewalls, …): once the customer is added to a DB, a set of scripts build all virtual appliances with the right configurations. VMware NSX and Cisco ACI can be used to achieve that, but they are not out-of-the-box solutions.
Software “operated” Network
The word “operated” refers on how you make and track changes on the network.
- Do you allow your network users to ask for tailored solutions (i.e. a custom network that bridge devices placed in two different DMZ)
- How do you change NTP servers on all your network devices?
- How do you find a MAC address within your network?
- How do you track changes on your network and how do you rollback?
Even if your network is probably unique, you should maintain a standard within. You probably don’t want to allow any fancy customization requested by users.
Software “monitored” Network
That’s the easiest part: how is your network monitored? Many commercial and open source software solutions exist, so probably your network is already monitored by a software, but:
- How do you add a new device to your monitor?
- How do you add a new network port to your monitor?
- How do you troubleshoot an issue on your network?
If you’re manually adding each interface to your monitor infrastructure, maybe there is something you can improve.
Obviously troubleshooting a network usually needs an human intervention, and often the CLI is still required to understand what is going on in the deep. But with a real SDN solution operators should identify the broken device checking the monitor, not connecting to devices, one by one, looking for anomalies.
SDN is used as a buzzword to push useless solutions!
How to start?
As I mentioned before, there are some solutions that can solve a specific case or can act as enablers. Meraki, Viptela, Nuage… can easily help to deploy hundreds of interconnected sites. VMware NSX, Cisco ACI, Juniper Contrail can easily help to build stretched sites. But of course product are not enough.
The first and important refers on methodology (or business processes).
- How does the network team operate? Every guy has its own custom approach or are people following the same procedures?
- How do requests come to the network team? Via a ticketing system, or near the coffee machine?
- What can users request to the network team? Everything, because their boss is more powerful or can the network team deny crazy requests?
Obviously if every crazy request must be satisfied, don’t waste money looking for an SDN solution. Before, review internal procedures and work on the methodologies.
The second step for SDN (and automation in general) is “standardization”. Standard is not referred to some fancy ISO document, but an internal standard.
- ACLs should use a naming convention, and if the same ACL is configured on multiple devices, use the same name.
- If you have dozens or hundreds of branch offices, consider to always use the same VLANs for the same purpose.
Third step: find the most time-spending tasks, review them, and try to automatize.
In this post we reviewed what an SDN solution should do, and the first step to convert an existing solution to something closer to SDN. Even if some vendors and solutions have been mentioned, legacy devices can still be used to implement an SDN solution. In the next post we’ll see how and why we should handle a network as we’re writing a software.
From NSX to ACI: the multi-tenancy story!
This article is not intended to explore in deep, however, the different pieces of the NSX-V vMware SDN solution, the goal here is to provide an overview on the topic: “all that normally is made on a HW and SW combination, here is done in SW”.
…at the beginning of this writing, my wish was to use this white paper to talk about CISCO ACI Multi POD solution, but suddenly I thought that it would have been much better to debate about it using a pragmatic approach; (too boring just talk about something that is already written somewhere) let’s give to it a spark!