For the most of my career I spent time configuring TCP stacks, IP ACLs, firewall rules and layer2 links. I worked with devices of multiple vendors, pulled together hubs, switches, routers and packet filters, used hardware and software tools to find why an application won’t connect to a remore peer. For the most time. Still, these days are over, since I’ve choosen a career working with customers a few years back. And while the interesst in techology is still there, the desire to dive into cabling and repetitive flipping switches has become very low over the years. Just as everything else in computing has been consumerized by the cloud, the network itself is still manual work (if done properly).

Software-Defined Networks may be here to overcome this perpective.

About the term

Now a few old colleagues founded a new startup, going into the “Software Defined Network” (SDN) business. Software Defined Networks have been a hot topic for a while now. Today, the apparently most prominent players in this field are the IETF with a dedicated working group (see RFC7149, defining the Service Providers Perspective), and OpenDaylight, a linux foundation community, aiming to accelerate adoption of SDN and Network Functions Virtualization (NFV)

The SDN promise is to helps abstracting the physical layer from the logical functionality, separating the “data plane” from the “control plane”. And the promise is tempting. Being able to define data to flow to the right consumers, without the worry about VLans and VPNs.

Startup Approach

Their approach is to have centrally controlled Routers, Switches and Access Points, that allow to build the data plane. The product is completed through the control plane, that is provisioned on the Internet. (AKA a hosted or cloud console.)

While that concept of separting control and data plane is predominant in the datacenter world already, local area networks are still configured mostly manually. At this point, the product I am currently trialing, tries to improve things.

 Experience

The box arrived in my lab only on Friday night. The WLAN Accesspoint itself makes a very good first impression. The hardware is made from high quality plastic and comes with a power adapter, a wall mount and ca. 0.5m of patch cable, which is obviously too short to be used in the lab, but should be sufficient to patch it up with the wall socket.

Having hooked the device up with a very basic router, I found the device boots within a very short period of time, probably 2 seconds or less untill DHCP got itself an IP address and fires the first DNS request. A few https request and a connection to port 3900/tco later, the device showed in the control portal as “up to date“.

While I have not yet found the time to configure a proper router to assess the traffic flowing from the device to the control plane, the configuration for the device to spawn a 5GHz WLAN was done in less than 1 minute. To get there took no device or hardware specific settings. Just set the location, the purpose and configure the WLan SSID to be broadcast and you’re set. Going into more details of network configuration will wash up hardware and network related settings for sure though.