A Small Yellow Wooden Door: Thinking Practically About SDN

As I do most days, I took a walk in the woods at the back of my garden after a hearty dinner. I was quite surprised to come across a small wooden yellow door I’d never seen before, set into the trunk of a tree I’d never noticed until today. I opened the door and squeezed inside, where I found a spiral staircase heading downwards. Being a curious sort of fellow, I proceeded to walk down the stairs, which seemed to go on forever; an irritating humming noise that slowly got louder was the only sign of progress. Eventually, I got to the bottom and stepped into a large, bright and cold room – really more of a sparsely decorated great hall than anything else.

As you can imagine, I was rather nervous by now; I wondered whether the giant who lived here was friendly or not. Suddenly, a wizard appeared in front of me, waved his wand, and spoke some magic words (which wouldn’t be magic if I told you what they were). “Don’t worry, Mr. Network,” he said. “Quite a few Misters and Little Misses have been here before you. Actually, you’re one of the last to arrive, other than Mr. Impossible.” I experienced some very strange sensations as he continued. “Everyone is still ‘around’ of course, but perhaps not in the form you might remember. I hope you don’t mind, but I’m going to have to separate the control and management planes from your body. Nothing to worry about, I assure you. Welcome to the new decouplingly decoupled, systematically systemic,  programmably programmable, drag-and-drop hive mind! Sorry…I mean ‘centrally controlled’ future.”*

As I mentioned in my first article The Man in the White Suit, fiction isn’t my strong point, but what you are about to read is just that. The reason I’ve been able to write this is because it should (in fact) be fact, or at least closely related to it (as far as I’m concerned). There’s a great deal that ‘should’ and ‘could’ be possible now within the networking field that simply isn’t. I’ve not had time to consider SDN, its protocols and its use cases in any great depth just yet, but that really doesn’t matter. What I’m about to describe could be done with an SDN related group of technologies I’m sure, but it could also be achieved even if SDN was just a random electrical impulse in Greg’s mind as he sat on a plane flying somewhere near Stanford. I want to give you an example of what should have been for a long time and finally, will soon be possible**. Something that you can relate to.

Abstraction is a cornerstone of many of the network tools and technologies available today or in the near future, but for most it’s hard to get too excited about a concept based on abstractions that in no way impact on their professional lives today. Yes, SDN is now a reality, but for most it’s not mature or prevalent enough to be more than just an overexposed concept and perhaps a great idea. Centralised, decoupled, automated, orchestrated and integrated thin switch zero-touch provisioning utilising standard profiles and policies with white box equipment probably isn’t generating too much interest or even desire in the reality of your working world now. Don’t ignore it until it’s too late of course; this article contains warnings that I hope won’t pass you by. If you don’t think this will impact your network, your business or your company with its unpleasant and unwelcome wrapper of service management and operations ‘oversight’ and ‘robust’ controls, you’re wrong. There is a revolution coming your way, and I hope you embrace it. It’s a threat to your status quo***, but also a fantastic opportunity.

Obviously, what follows below is oversimplified and idealised; it’s limited in scope and ambition. You’ve had enough of grand ideas, I suspect. I’m demonstrating today’s kind of tasks on today’s hardware using tomorrow’s technology (well, tomorrow’s products, really). This isn’t too likely as the coming changes in the industry are far more fundamental than the improvements in configuration and management I’ll show you. However, relating the possibilities to what we do today makes it more relevant, understandable and real, and will hopefully get you thinking about the benefits and positives of the future. Automation will probably make even the tasks shown pretty redundant, but let’s take one step at a time. I’ll ignore overlays, virtualisation and orchestration, and keep it simple. I hope you appreciate it. I’ve no doubt the GUI will be king soon, but for now, I’ll show my appreciation for a well thought-out and powerful CLI.

Here’s where our real (technical) fantasy starts – with four switches that need to be installed to form the backbone of a new network zone (or DMZ if you’d rather). I need to hook them together, hook them to a firewall cluster and apply the usual standard company configuration. Nothing too technically complex but, in today’s networking arena, this is still a fair bit of work. In my mind, this zone will be used to connect a fair number of powerful discrete and blade-based servers that will probably host thousands of virtual guests. Here’s what it looks like.

SimpleNetworkZone

OK, so some moves, adds and changes, guy or gal racks and cables everything up according to a simple design you supplied. In return, you’ve been given four UIDs.

First up, let’s login to our active Central Controller (CC) after establishing an SSH connection to it.

> login: mrnetwork

> password: xxxxxxxxx

>># Welcome Mr Network.

Next, let’s enable ‘new device discovery’ on all our inter-connect controller (ICC) switches; which we use to connect our CC to our physical network devices. For the sake of security, we’ll only enable discovery for 5 minutes;

>> enable mgmt devices discovery 5

>># Device Discovery enabled for five minutes

This will automatically enable the reception and transmission of a low-level discovery protocol (and only this protocol) on any dormant ports on our ICC switches. Dormant ports are those that a known (and controlled) network device isn’t present on (as far as we know) and are essentially disabled. They will only accept our discovery protocol packets when discovery is enabled. OK, so, what do we get back?

>>& Discovered switch device, UID: XXX599 on IC 01, int. 25 and ICC 02, int. 25. Manage this device? [YES|no] YES

>># Attempting to manage switch device, UID: XXX599… Successful

>>& Discovered switch device, UID: XXX958 on ICC 01, int. 26 and ICC 02, int. 26. Manage this device? [YES|no] YES

>># Attempting to manage switch device, UID: XXX958… Successful

>>& Discovered switch device, UID: XXX209 on ICC 01, int. 27 and ICC 02, int. 27. Manage this device? [YES|no] YES

>># Attempting to manage switch device, UID: XXX209… Successful

>>& Discovered switch device, UID: XXX199 on ICC 01, int. 28 and ICC 02, int. 28. Manage this device? [YES|no] YES

>># Attempting to manage switch device, UID: XXX199… Successful

So, the UIDs and interfaces match the information we have been given; these are indeed the new devices we want to manage so we hit [RETURN] to enable management for them (the uppercase YES is the default choice). What does this mean? Well, interfaces 25-28 on the two ICC switches are no longer dormant; they are automatically enabled and a list of allowed protocols and flows between the new switches, our ICC switches and our CC are permitted. At this point there’s no IP address configured on the new devices but we can still communicate over IP because the new devices will process any suitable IP packets directed at them by a CC. Also, all management communications have been suitably secured with TLS in a number of ways based on the UID and other device specific parameters.

So let’s give our new switches some friendly names and put them into a Device Group so we can configure them as a, err, well, a group (note the scalable hierarchy);

>> create mgmt group location DC01-NOC parent DMZs name DMZ10 description “DMZ10 – New Web Service Zone”

>># Group DC01-NOC\DMZs\DMZ10 created successfully

>>

>> modify mgmt device XXX599 group DC01-NOC\DMZs\DMZ10 description “DMZ10 Primary L3 Switch”

>># Switch device, UID: XXX599 added to group DC01-NOC\DMZs\DMZ10 successfully

>># Switch device, UID: XXX599 description changed to DMZ10 Primary L3 Switch successfully

>>

>> modify mgmt device XXX958 group DC01-NOC\DMZs\DMZ10 description “DMZ10 Secondary L3 Switch”

>># Switch device, UID: XXX958 added to group DC01-NOC\DMZs\DMZ10 successfully

>># Switch device, UID: XXX958 description changed to DMZ10 Secondary L3 Switch successfully

>>

>> modify mgmt device XXX209 group DC01-NOC\DMZs\DMZ10 description “DMZ10 L2 Switch 1″

>># Switch device, UID: XXX209 added to group DC01-NOC\DMZs\DMZ10 successfully

>># Switch device, UID: XXX209 description changed to DMZ10 L2 Switch 1 successfully

>>

>> modify mgmt device XXX199 group DC01-NOC\DMZs\DMZ10 description “DMZ10 L2 Switch 2″

>># Switch device, UID: XXX199 added to group DC01-NOC\DMZs\DMZ10 successfully

>># Switch device, UID: XXX199 description changed to DMZ10 L2 Switch 2 successfully

Note that [TAB] auto-complete is now possible and can be used with the device UID or description and group name or path.

OK, so we’ve given our switches some friendly names and assigned them all to a group call DMZ10 which exists under some useful device hierarchy we’ve defined earlier. Let’s check our work so far (and note how the CLI is omitting repeated information);

>> show mgmt devices group DC01-NOC\DMZs\DMZ10

>># =========Group=========#==No==#====Device====#=Capabilities=#====Description====#

>># DC01-NOC\DMZs\DMZ10      001     XXX599        Switch         DMZ10 Primary L3 Switch

>># -                        – 2     -  958        -              –     Secondary L3 Switch

>># -                        – 3     -  209        -              –     L2 Switch 1

>># -                        – 4     -  199        -              –     -  -      2

Sweet – it’s all looking good. So, let’s get on with connecting our switches up by enabling a different kind of discovery on our group of switches (for only 2 minutes this time) – handled by LLDP and reported back to our CC. To save some keystrokes, we’ll use the cd command so we don’t need to specify the path to the group each time;

>> cd DC01-NOC\DMZs

>># The current path is: DC01-NOC\DMZs

>> enable layer-two device discovery 2 group DMZ10

>># Layer One Device Discovery enabled for two minutes between members of group: DC01-NOC\DMZs\DMZ10

>># Group members 001 and 002 are connected to each other;

>># -001 int1/1, 2/1 <> int1/1, 2/1 002-

>># Group members 001 and 003 are connected to each other;

>># -001 int1/2, 2/2 <> int1/1, 2/1 003-

….

>>& Configure these links permanently? [ALL|none|choose] ALL

>># These links have been successfully configured permanently;

>># -001 int1/1, 2/1 <> int1/1, 2/1 002-

>># -001 int1/2, 2/2 <> int1/1, 2/1 003-

Oh yeah! Our switches are linked, so let’s do some boring stuff based on some templates (stored procedures they could be considered, or perhaps policies or profiles) just to get the switches up to our standards;

>> cd ..

>># The current path is \DC01-NOC

>> execute procedures stdrd-sec stdrd-logging stdrd-ntp stdrd-snmp stdrd-cli group \DMZs\DMZ10

>>& Executing procedure: stdrd-sec on members of group: DC01-NOC\DMZs\DMZ10… Succesful

>>& Executing procedure: stdrd-logging on members of group: DC01-NOC\DMZs\DMZ10… Succesful

>>& Executing procedure: stdrd-ntp on members of group: DC01-NOC\DMZs\DMZ10… Succesful

>>& Executing procedure: stdrd-snmp on members of group: DC01-NOC\DMZs\DMZ10… Succesful

>>& Executing procedure: stdrd-cli on members of group: DC01-NOC\DMZs\DMZ10… Succesful

Of course, I could collapse these five templates into one (or group them, too) and save some time, but for the sake of the demonstration I haven’t. So, our switches are under our control, inter-linked as planned, and now have some solid standard configuration applied. Just a couple more things to do to hook up to the firewall cluster and set up some standard in-band L3 interfaces for SNMP, NTP, logging and the like and we’re done.

>> cd DMZs

>># The current path is \DC01-NOC\DMZs

>> show mgmt devices group DMZ10

>> show mgmt devices group DC01-NOC\DMZs\DMZ10

>># =========Group=========#==No==#====Device====#=Capabilities=#====Description====#

>># DC01-NOC\DMZs\DMZ10      001     XXX599        Switch         DMZ10 Primary L3 Switch

>># -                        – 2     -  958        -              –     Secondary L3 Switch

>># -                        – 3     -  209        -              –     L2 Switch 1

>># -                        – 4     -  199        -              –     -  -      2

>>

>> create layer-three interface DMZ1001 1.1.1.5/27 primary .4 default .1

>># Switch: DC01-NOC\DMZs\DMZ1001 IP processing enabled for IP address: 1.1.1.5/27

>># – HSRP primary processing enabled for IP address: 1.1.1.4/27

>># – Default gateway enabled, using IP address: 1.1.1.1/27

We repeat for switch 002, but set it as the secondary.

For our access switches, it’s even simpler and of course, as this all passes through our controller and it’s sanity checking everything, network wide, we know we can’t make a mistake by using a duplicate IP, an NTP server that doesn’t exist or whatever.

>> create layer-three interface DMZ1003 1.1.1.7/27 default .1

>># Switch: DC01-NOC\DMZs\DMZ1001 IP processing enabled for IP address: 1.1.1.7/27

>># – Default gateway enabled, using IP address: 1.1.1.1/27

OK, let’s finish off with those firewall interfaces. Note they are automatically assigned to our in-band L3 management network.

>> cd ..

>># The current path is \DC01-NOC

>> execute procedures stdrd-fw-int device DMZs\DMZ1001 interface 3/1, 4/1 device DMZs\DMZ1001 interface 3/1, 4/1

>>& Executing procedure: stdrd-fw-int on device: DC01-NOC\DMZs\DMZ1001 interfaces 3/1, 4/1 … Succesful

>>& Executing procedure: stdrd-fw-int on device: DC01-NOC\DMZs\DMZ1002 interfaces 3/1, 4/1 … Succesful

>> enable interface device DMZs\DMZ1001 interface 3/1, 4/1 device DMZs\DMZ1001 interface 3/1, 4/1

>>& Enabling device: DC01-NOC\DMZs\DMZ1001 interfaces 3/1, 4/1 … Succesful

>>& Enabling device: DC01-NOC\DMZs\DMZ1002 interfaces 3/1, 4/1 … Succesful

Job done in around 20 commands (excluding where we just had to hit [RETURN]) – pretty slick and very quick. Next up, the servers get cabled in a fairly standard fashion (if they haven’t been already), VMware and/or some other goodness gets loaded up and some program or another is used to automatically push out suitable settings to our physical and virtual switches. So, that’s no real effort either. Rinse and repeat. If we need load balancers or firewalls (expensive broken routers after all), no problem. They will be just another guest if their functions aren’t already integrated into the controller itself.

If you think (and it would certainly be the case in this example) that you might repeat the design implemented, perhaps you’d want to program it? Here’s how you might do some of that using the very old but popular Tcl (as used with F5′s iRules and some Cisco products). It might seem longer than a CLI command script, but it’ll reduce errors and it keeps things simple. It will also tie into an overlay GUI very easily.

#Enable device discovery

mgmt::device_discovery enable 5

#Wait 1 minute to allow discovery to occur

wait 1

#Display discovered devices

mgmt::device_discovery display

#Prompt to confirm and accept new devices

mgmt::device_discovery prompt

#Prompt for new group location

group::create location prompt

#Prompt for new group parent

group::create parent prompt

#Prompt for new group name

group::create name prompt

#Prompt for new group description

group::create description

create mgmt group location $location parent $parent name $gname description $description

#Prompt for switch one name and description and add to group

switch::modify description prompt

group::add UID auto description $description

#Prompt for switch two name and description and add to group

switch::modify description prompt

group::add UID auto description $description

#Prompt for switch three name and description and add to group

switch::modify description prompt

group::add UID auto description $description

#Prompt for switch four name and description and add to group

switch::modify description prompt

group::add UID auto description $description

#Enable L2 discovery

layer-two::device_discovery 2 group $gname

And so on…

Is this enough? Have I whet your appetite? Is this radical enough to get you interested, or perhaps afraid? I’ve more interesting things to describe, but I thought I’d test the waters with this, which is I’d agree pretty simple, but also demonstrates the power, the benefits and the genuine ‘savings’ that can be had with today’s technology and a new approach – at least I hope so.

*Full credit to Roger Hargreaves for the simple and fun (yet often linguistically complex) books in the original Mr Men and Little Miss series of books.

**Based on the recent Anuta nCloudX webinar, everything in this article has been far surpassed already, it just needs to become popular.

***Some thoughts on SDN and virtualisation’s effects on the employment market can be found here: You’ve Changed – SDN’s Casualties

Steven Iveson

Steven Iveson

Steven Iveson, the last of four children of the seventies, was born in London and has never been too far from a shooting, bombing or riot. He's now grateful to live in a small town in East Yorkshire in the north east of England with his wife Sam and their four children. He's worked in the IT industry for over 15 years in a variety of roles, predominantly in data centre environments. Working with switches and routers pretty much from the start he now also has a thirst for application delivery, SDN, virtualisation and related products and technologies. He's published a number of F5 Networks related books and is a regular contributor at DevCentral.
Steven Iveson
Steven Iveson