First let me start out by saying that network automation and SDN are not the same. They share some common goals but achieve them in different ways.
Generic Automation uses the tools that each network vendor thinks we should be working with. Say OSPF, BGP, ISIS, vlans, etc. We then apply automation routines against those tools to achieve getting a packet from x to y or placing a server on a given vlan/subnet.
Software Defined Networking (SDN) is a way over used term that is supposed to describe the creation of other non vendor standard tools through a framework of devices that are all connected. The idea is that we should be able to write our own protocols to achieve what we want, how we want, when we want, without relying on pre-baked tools from network vendors.
Unfortunately SDN has turned into simple automation tasks (not because SDN is dead). CTOs see SDN on the front of a magazine and Network Operations managers want to get rid of the ticket queue. So it comes down from the CTO’s office, “let’s push SDN”. The operations Manager contracts some coders to write some expect scripts and api calls to accomplish maybe 3 main tasks that are filling up is queue daily. The CTO then goes to another company with “SDN” under his belt and continues propagating the incorrect term.
Now… Who really cares? honestly, its not really that big of a deal. You could call SDN anything. Heck, let’s just make up our minds to call it automation. There.. We are done. It’s settled. SDN = automation.
One major glitch. Automation still requires network engineers to troubleshoot and maintain. SDN does not. When companies truly start making the push to SDN, network engineers will either have to change their tool belt or go into management.
Here are some very opinionated fun facts:
Anything not automated is not going to stick around too much longer.
Anyone not keen on automation will most likely find themselves in the same position.
There will be a few that make it through the Network Engineer End of days.
1. The wizard at networking technology X
This guy will be around for troubleshooting and teaching developers how to automate prior to SDN taking a foot hold. If he doesn’t adjust his tool belt, he will eventually fall.
2. The network engineer willing to start learning to code and automate.
This guy has a much longer life ahead of him. Like the fortran developers out there today, he will be very handsomely paid. He will bridge the gap between networking and software development prior to SDN taking over.
Now.. the whole reason why I even started writing this silly post was because I saw this over at Lame Journal. In that post, John writes
“It seems like virtual networking integration with OpenStack is no longer optional. What’s that mean? What’s happening there?”
I would venture to say that its not just virtual networking. It’s all networking. Now that we have a pre-baked API (Neutron) and network vendors are already writing drivers for their hardware, why in the world would anyone write custom automation routines anymore?
The End of Days is coming upon us with a vengeance.
Drivers already supported by Neutron.
| Plugin/Driver Name | Contact Name | IRC Nick |
|---|---|---|
| ML2 | Neutron Team | rkukura, mestery |
| Big Switch/Floodlight | Kevin Benton | kevinbenton |
| Arista Networks | Sukhdev Kapur | Sukhdev |
| Embrane | Ivar Lazzaro | ivar-lazzaro |
| PLUMgrid | Edgar Magana | emagana |
| Mellanox | Irena Berezovsky | irenab |
| Cisco | Kyle Mestery | mestery |
| Brocade | Shiv Haris | shivh |
| Tail-f NCS | Luke Gorrie | lukego |
| A10 Networks | Micheal Thompson | layer427expert |
| Nicira/VMware | Armando Migliaccio | armax |
| Ryu | Nachi Ueno | nati_ueno |
| Metaplugin | NTT Team | nati_ueno, hichihara |
| NEC | Akihiro Motoki | amotoki |
| vArmour | Gary Duan | garyduan |
| Midokura | Lucas Eznarriaga | luqas |
| Nuage Networks | Ronak Shah | rms_13 |
| Place Holder | Person 1 Name | irc_nick |
You may notice Juniper is not listed here. Not to fret, more on Juniper can be found here.
Now, lets say I am a network operations manager. I get approximately 200 requests a week to add or make some sort of change to a load balancer vip. I could write my own automation to help with all of these requests. A10 Networks has had a REST API for a some time. F5 has been a bit sluggish and offers some services through a rest API if you are bold enough to run their latest code. But why bother?
You’ll notice A10 is listed above as having drivers for Neutron. (I have a team mate in the processes of vetting these drivers. I will write more when I have more info)
So whether we have made the jump to openstack or not, it would seem we may be able to make use of Neutron in any environment. Time to get the virtual lab setup. For this, I will request a demo vm from A10 Networks.
Additional Credits:
Awesome pic of a neutron taken from this post.