Do You REALLY Want to Program Your Network?
The primary benefit of SDN (as claimed by its promoters) is a geek’s dream: the ability to program the network (or, more precisely, control network’s behavior through programmable tools).
Sounds great – we’ll finally be able to fix that pesky detail the vendor never wanted to implement (probably for a good reason). But should we REALLY do that?
If you’re Facebook, Yahoo or Google, the answer is obviously Yes.
If you prefer being MacGyver over having a stable network (and love being called when your masterpiece crashes at 2AM), go for it ... but what if you happen to be somewhere in the middle of the U-curve? Should you stay away from SDN until it crystalizes into mature shrink-wrapped software products or should you start getting your hands dirty?
Learning and labbing has never hurt anyone. You might not be ready to deploy OpenFlow or any other SDN tool in your network but that doesn’t mean you don’t have to know what it is and how it works. Experience never hurt anyone – if nothing else, you’ll be able to explain why things don’t work as well as marketing whitepapers claim they should.
Get a few switches that support OpenFlow: Linksys, HP Procurve or Mikrotik. Download OpenDaylight. Make them work.
Get Cisco’s CSR. Configure it with NETCONF. Connect it to a Quagga BGP daemon. Insert BGP routes into CSR’s forwarding table. Play with OnePK (once it becomes available).
Figure out what Chef and Puppet are all about. Write a few Perl or Python scripts. Get some serious Linux skills.
From Theory to Practice
You got your hands dirty in the lab. You got NETCONF running with a Cisco router and Juniper switch. You programmed an Arista switch with Python. You even got some OpenFlow entries into a switch to serve as ACLs. Your boss is not totally opposed to your ideas. Now what?
Go for the low-hanging fruit. There must be something in your environment that everyone detests doing, but it still has to be done. VLANs? ACLs? Some interesting logging and correlation stuff? You know it best. Go for it.
Make it useful. Solving the hard problem (example: configuring VLANs through NETCONF) is just half the work. Now you have to make your tool useful to everyone else. You’ll probably have to implement at least a minimal GUI (read: web page) to allow the operators to enter parameters and trigger your tool.
Aim for minimal impact. Whatever you do, start small – minimal configuration changes, minimal modifications to existing network operation. Go for solutions that you can deploy on individual non-critical devices.
Software development is more than writing code. Understanding the SDN technologies and tools and having some programming proficiency is not the end of the journey – it’s just the first step out of the Shire.
You should approach your network programmability solution like any other mission-critical software project. It needs source control, unit tests, integration and validation tests and well-defined deployment process. You will probably have to fix a bug or two, in which case revision control and regression tests become a must.
If the above paragraph sounds like Latin to you, find someone who knows more. If you have a good programming team in your environment, now’s a good time to talk to them and become their temporary apprentice.
No job is finished until the paperwork is done. Write the documentation and user instructions. You might also want to get this as a permanent reminder.
Anything else? Sure, I have plenty of design and implementation ideas, but they’ll have to wait for another blog post.
* Industrial control device drivers for RSX-11M;
* Symbolic kernel debugger for RSX-11M
* Token ring-like file sharing network for CP/M using RS-232 @ 100kbps or so;
* Network file server with Linux-like operating system and file system structure for CP/M clients (because I hated flat directory structure of CP/M and early MS/DOS);
* Transactional database (because there was none on MS-DOS);
* Scripting language to be able to develop applications faster than using dBase or Clipper;
* port of sendmail to MS-DOS (you really don't want to know the details) and DECnet (really), IPX and UUCP plugins for the ported sendmail;
* Email client to go with the mail server (remember, these were still pre-Windows days, everything was done on 80x24 terminal screens).
... and then I stopped doing crazy things and started doing crazier things (aka networking).
I'm sort-of lazy (programming-wise) these days - only did a couple web sites in recent years.
Let's look at some analogies: Wireless started as standalone AP, then standalone AP with some configuration tool, then dumb AP with wireless controllers. It likes to SDN, isn't it?
The real benefit of the SDN movement is that it opens up APIs for control of networking products, allowing independent software vendors to develop controllers that solve real world problems. Being informed about SDN will allow customers to understand the capabilities of SDN and make informed choices when selecting solutions.