When SDN breaks down

null

Software defined networking (SDN) is finally beginning to live up to the hype as more organizations adopt the technology to create efficient, centralized network management, roll out new applications and services with greater agility, enhance security, and reduce operational costs. But as the technology becomes more mainstream, enterprises are realizing that along with the benefits come new operational challenges, especially since most organizations that turn to SDN end up with a hybrid network where SDN architecture is merged with traditional data center and MPLS networks. Let’s take a look at the challenges created by SDN and how organizations can better manage their hybrid networks.

SDN is like a high-end sports car

Ideally, SDN enables the network to be directly programmable and the underlying infrastructure to be abstracted for more efficient deployment of applications and network services, but when there’s an issue, layers of SDN abstraction can make troubleshooting very difficult. In that sense, SDN is similar to sports cars. Sports cars are designed to get you where you want to go faster, be high performing and high-end. But, when sports cars need repairs or break down, they can be incredibly difficult and expensive to fix. 

Think of policy orchestration as the engine of a sports car. Orchestration is an important capability of SDN, offering a slew of benefits including faster service deployments. But the abstraction that comes with policy orchestration is perhaps the element of SDN which can prove to be the most troublesome when something goes wrong. When a sports car’s engine is performing at its best, it’s extremely powerful, as is orchestration when the network is running effectively, but when an application issue arises within the SDN fabric, abstraction can create visibility and complexity challenges, just like engine issues can spiral into other problems. With potentially hundreds of applications deployed across the SDN fabric, it can be very challenging to map a single app’s dependency to the underlying network infrastructure.

Provisioning a new service is one of the tasks SDN does best. During this process, SDN abstracts away network-level complexity, including the interconnection between and traffic paths of routers, firewalls and load balancers, allowing network teams to get new services up and running with a newfound speed and agility. However, in a huge data center running thousands of applications, there is also a lot of room for something to go wrong with an application that’s already been provisioned during this process. There could be an accidental network misconfiguration or a bad cable and unless engineers can rapidly identify the underlying issue among all of the applications — which can be like trying to find a needle in a haystack — realizing the benefits of SDN abstraction will be a challenge. 

Check under the hood for full network visibility 

When it comes to SDN, many organizations are ill-equipped to effectively visualize what’s going on underneath the hood. Ideally, network engineers are able to see both SDN and non-SDN networks side by side, so they can visualize the physical and logical interconnections, and correlate the layers of abstraction at any given moment. This view becomes even more important at critical times like troubleshooting. Speed is the most important aspect of troubleshooting, especially when network downtime can directly impact an organization’s bottom line. 

The goal for any network team is to reduce MTTR (mean time to repair) and get the issue resolved asap. Unfortunately, existing manual troubleshooting and mapping strategies like CLI and network diagramming are less effective in complex hybrid networks, leaving engineers to frantically race against the clock to identify the problem. Therefore, having complete end-to-end visibility across hybrid networks is critical if network engineers want to stand a chance when it comes to quickly identifying and mitigating potential issues.

Luckily, organizations can turn to automation to help manage their SDN infrastructure in a consistent and familiar way, as they do the rest of their network. Enabled by automation, network engineers can view both traditional and application centric infrastructure as well as data integration with the SDN console, in a single view. This allows organizations to acclimate to an application centric infrastructure and understand how application dependencies map to the underlying fabric. In hybrid environments where abstraction can lead to a cloudy view of the network, automated processes and the right data integration can give engineers the on-demand visibility they need. 

Automate the day-to-day operations

Even when end-to-end visibility is achieved, there are still other ongoing operational challenges within complex hybrid environments. This is where automating day-to-day network operations becomes critical, allowing engineers to effectively manage complex networks while also focusing on more value driven workflows like implementation of new technologies or identifying security threats. 

For example, a programable set of procedures, known as a runbook or playbook, can be automated and used by anyone to collect and analyze network data. Runbook automation allows network teams to automate consuming processes like issuing CLI commands across multiple devices, while automated integration of ITSM systems like ServiceNow or SIEM systems gives network engineers real-time, critical insight. This contextualized insight means faster response times and increased organizational agility, across network, security and application teams.

Sharing is caring 

Another challenge associated with SDN is the way it’s affecting the network engineer’s job description and required know-how. In fact, a recent survey administered by NetBrain found that 62 percent of respondents whose organization has implemented SDN indicated that additional training is required to handle the new demands of the job. This is likely similar to the challenge mechanics experienced with the introduction of electric sports cars, forced to adapt their skillset to do the job. 

Luckily in the case of SDN, increased visibility and automation can help network engineers apply existing knowledge to these new environments. In addition, the importance of sharing critical knowledge – whether that be design information, troubleshooting steps or network change history – within and among network teams as the quickest way for teams to get up to speed with new technologies cannot be understated. 

Despite whether or not an organization has implemented SDN, enterprises have long suffered from siloed approaches to network management. SDN brings greater complexity, which creates even more urgency for organizations to find ways to effectively share their collective expertise. As network environments grow in complexity, the role of the network engineer will become even more valuable. App developers can spin up new services quickly, but when something goes awry, network engineers are the ones who understand the underlying protocols and can ultimately solve the problem.

The benefits SDN delivers are clear – increased agility, centralized management and lower costs. But that’s only when things are going right with the network. Just like with a high-end sports car, when things aren’t working 100 percent, identifying and fixing an issue can be incredibly complicated. This is why organizations must invest in the right visibility and automation tools so that when an issue does arise, network teams will be prepared. When implementing SDN, having deep visibility across the hybrid network and finding ways to automate day-to-day operations are essential.

Jason Baudreau, Product Strategist at NetBrain Technologies 

Image Credit: Ra2Studio / Shutterstock