The goal of software defined networks (SDNs) is to make networks as dynamic and agile as storage and virtual servers already are. This agility is achieved by using a layer of software that resides on top of network hardware and that enables network administrators to define business rules for network traffic routing. They can then apply these traffic-shaping rules to network routers and other hardware with software so they don’t have to go through manual hardware configurations.

SDN is still a new concept for most organizations. Companies like SDN’s virtualization potential for networks, but many pieces of hardware from an assortment of vendors must all be able to work with the overlay of SDN software. This complicates SDN deployment to a greater degree than the deployment of virtual servers or storage.

So what planning issues for SDN should organizations be thinking about? Here are 10 key considerations to keep in mind.

SEE: Quick glossary: Software-defined networking (Tech Pro Research)

1: Ensuring end-to-end visibility of the network at any time of day

The good thing about SDN is that you can immediately respond to a network resource demand with software–but this can also affect the procedures for network management that your company has been using to manually manage physical networks. For instance, if you provision a new network infrastructure with SDN during the day and your daily check of what’s new on the network is run only once, at end of day, there is going to be a gap in visibility between what you have actually deployed onto the network and what your management reports are telling you. Synchronizing these activities should be part of any SDN implementation.

2: Avoiding network capacity issues

Virtualization lets you deploy new resources quickly–but it also creates significant extra overhead that must be continuously managed. This occurs most often in on-demand resource allocation situations. After the demand has gone away, IT forgets to de-provision the extra resources, so these resources continue to place demands on network capacity even when it is not needed. De-provisioning should be built into any SDN deployment as a logical last step once the need for the provisioned resource ceases.

3: Solving performance monitoring

Since SDN is an evolving network approach, many commercial network performance monitoring solutions are still not fully SDN-ready. At a minimum, these solutions must offer open application programming interfaces (APIs) that newer concepts like SDN can plug into They must also be able to integrate SDN network data with data that is flowing in from non-SDN networks, since organizations deploying SDN run hybrid networks that combine both SDN and non-SDN. The goal from a performance management standpoint should be to create a 360-degree view of the network.

4: Linking network performance to specific business needs

The challenge with SDN is no different than it is with manually configured networks. Ultimately from a service perspective, network administrators must be able to answer business case-specific service questions, like, How is the video confidence line between headquarters in New York and our office in Singapore performing? To answer questions like this, performance monitoring software must be able to integrate performance reporting from both SDN and non-SDN networks and to organize the information so it can granularly report on a particular business context. This may require some customization in the performance management software you are using.

SEE: Software defined data centers: The smart person’s guide

5: Managing security risks

Because SDN is a new technology, organizations can encounter heightened security risks. They aren’t up to speed on potential vulnerabilities and security weaknesses on SDN. To prepare for this, they should research as much as they can about any protocol weaknesses, dangers of SDN switch impersonation, etc., that could develop with SDN–and take precautionary steps.

6: Coordinating SDN network security with application security

Applications use the network, so when they are first deployed on SDN, IT should ensure that best practices for security in applications are synchronized with the security practices that are in place for SDN. These might include differences in protocols, for instance, that are common to SDN but not to other physically deployed networks that apps also use. The best way to do this is to revisit application coding standards to ensure that app security routines address the needs of both SDN and non-SDN networks.

7: Guaranteeing quality of service (QoS)

Guaranteeing network QoS is hard work. Each vendor of every single piece of network equipment preconfigures QoS settings on its own devices at the factory–but when all these devices with different QoS settings start working together on your own network, your network QoS might be far away from what you need it to be, thanks to the QoS incompatibilities between devices. Network administrators faced with guaranteeing high levels of nonstop service with abundant bandwidth (such as might be required for a telesurgery application) can’t afford to operate with different QoS standards. The same problem exists on SDN networks, which is why the business rules for specific business use cases and network provisioning should be carefully defined and rigorously enforced.

SEE: Building the Software Defined Data Center (ZDNet special feature)

8: Using outside vendors

Organizations sometimes use outside vendors on their network servicing and installations. If you are using SDN, be careful to use only vendors that have strong SDN knowledge and that can deliver what your business rules require.

9: Integrating WAN

SDN was primarily designed for use on internal corporate networks, but now many IT organizations are being asked to provide end-to-end quality network service that is a hybrid pipeline of both the internal network and the external wide area networks (WANs) that most likely flow over public internet. If you need to integrate end-to-end performance of your internal networks with an external WAN, this is yet another SDN requirement that your staff should design for.

10: Building SDN knowledge and best practices

Although SDN has been around awhile, its adoption rate in companies has proceeded rather slowly. Much of this is due to the ongoing evolution of the technology and to the many points of the network that must be brought into SDN for an organization to realize SDN’s full benefits. Therefore, when you move to SDN, it may be necessary to create your own best practices for the technology since little is yet known about it. By engaging SDN experts that you or your vendors have access to, you can speed this learning process while avoiding costly errors as you move forward.

Also read…

Other advice?

If you’ve embarked on an SDN deployment, what issues tripped you up? Share your experiences and suggestions with fellow TechRepublic members.