We all know that Google, Fastly, and Facebook… are defining networks as a software (yes, SDN, but the real Software Defined Network) using custom tools. But what exactly does SDN mean?

SDN is an “idea”, a good one, but it has been converted into a buzzword to push useless solutions from vendors to customers. So let’s forget what we know regarding SDN for a while. And let’s start from the 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 to how your network came up. Are you configuring devices manually one by one? Are you adding virtual networks one by one? Then no, your network is not an SDN solution.

An SDN solution should automatically build the required environment with almost no human interaction. Examples:

• 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 prepare and configure the device. Meraki and the new SD-WAN solutions are going in this way.
• A new customer needs a new environment (VRF, routing, firewalls, …): once the customer is added to a DB, a set of scripts builds 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 to how you make and track changes on the network. Examples:

• Do you allow your network users to ask for tailored solutions (i.e. a custom network that bridges 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 roll back?

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 exist, so probably your network is already monitored by 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.

Troubleshooting a network usually need 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 by checking the monitor, not connecting to devices, one by one, and looking for anomalies.

SDN: 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, and Juniper Contrail can easily help to build stretched sites. But of course, products are not enough.

The first and most important refers to methodology (or business processes). Examples:

• How the network team operates? Every guy has his 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 a user request to the network team? Everything because their boss is more powerful or can the network team deny crazy requests?

If every crazy request must be satisfied, don’t waste money looking for an SDN solution. Before, review internal procedures and work methodologies.

The second step for SDN (and automation in general) is “standardization”. Standard is not referred to as some fancy ISO document but as an internal standard. Examples:

• 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 always using the same VLANs for the same purpose.

Third step: find the most time-spending tasks, review them, and try to automatize them.

Conclusions

In this post, we reviewed what an SDN solution should do, and the first step to converting 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 software.

In the next post, we’ll see an SDN approach for legacy networks.