For the 3rd installment on my three part SDN series, building on A Business Case for SDN, and the SDN Ecosystem, the most practical way to start exploring an SDN deployment is with a proof of concept (POC). But even if you have the approval to go ahead with an SDN POC, it can be difficult to know where to start. Let’s cut through the uncertainty and lay out what it takes to do a successful SDN POC.
Identify a pain point
Start by identifying a key pain point in networking that you’d like to address with SDN. For example, you might want to improve campus security, or improve the performance of collaborative tools, or streamline your data center. Specific tasks in these areas include adding a network tap, increasing the speed of a LAN link, or reassigning VLANs.
We’ll assume you have surveyed business unit leaders, ranked overall IT strategies and come back with one SDN application to start your evolution. Similar to a cloud or BYOD initiative, giving visibility for SDN can help you bring the company together, and can also build support for improving how IT can drive the business. If you understand the pain points and how SDN can improve operations, you can evangelize how SDN can be a competitive advantage for each department. You can then rank departmental projects in order of priority and use each group as an example of how SDN can drive economic as well as employee benefits.
For example, on the campus, you may rank security as your top concern and therefore focus the SDN discussion around onboarding devices into the network. SDN could augment your BYOD strategy and help with the onboarding process – you could look at the behavior of recently-added devices and potentially shut those ports down or isolate a device.
Thinking through the metrics for success
The POC involves setting up an SDN test bed and determining if the SDN solution can deliver the benefits you’re expecting. For sake of argument, let’s pick an SDN network tap as the application. The idea here is to be able to turn on tapping functionality on any SDN-enabled port, thereby not having to use parallel fixed infrastructure providing tapping functionality.
The choice here is either fixed CapEx / OpEx for purpose-built monitoring and tapping tools, or leveraging an SDN network tap that can be bolted onto your network and used as a dynamic probe. Here the POC could explore the overall cost of the gear (CapEx) and the cost for training in both non-SDN and SDN paradigms (OpEx). You could also look at whether SDN gives you all the functionality or just a subset. Once you have the technical details, you can make an informed decision.
Building an SDN POC using a network tap
To lay out the whole solution, we need:
- An SDN-capable network switch and OpenFlow-enabled switch operating system, allowing external control from the OpenFlow driven controller
- SDN controller software such as Ryu, NOX or OpenDaylight
- A network application (in our case, a network tap)
- Conventional network tap gear for functionality and usability comparisons.
You can assemble these components by buying from different vendors, buy a starter or developers kit that includes all of these components, or go with an all-in-one solution from a mainstream vendor such as Cisco or HP if you’re willing to pay a higher price.
Think about the skills that you and your team have. If you are Python warriors, for example, then Ryu (built by NTT Laboratories) might be a good sandbox for you. If you know your team needs GUIs and your scripting bench is already overtasked, then think about something more GUI-based, like OpenDaylight. Today not all controllers are alike. Some are single threaded; some are built for high availability environments. Mapping your team’s skills to the development needs of your SDN stack will go a long way in ensuring that your adoption of SDN technology matches your needs and abilities.
Expanding the POC
Once the POC is carried out, it can be expanded into a trial by extending the POC to a functional area of network operations.
The list of SDN ideas is long and focused on the idea of IT agility. Here’s a more complete list to leave you with beyond the one we have walked through.
- Establishing virtual Ethernet networks without VLANs
- Enabling applications to dynamically request services from the network
- Reducing CAPEX by using bare-metal switches instead of name-brand switches
- Evolving network functionality more rapidly based on a software development lifecycle
- More easily implementing QoS
- Implementing more effective security functionality
An SDN POC will familiarize you with the benefits of SDN and help you to build a strong business case for SDN within your organization. By assembling a few SDN components you can demonstrate the value of SDN compared with the traditional way of doing things.