The Cisco IT network services team views network programmability—the broader category that includes SDN, or Software-Defined Networking—as one of our top priorities.
To clarify terms, SDN is a network architecture that decouples the control plane (that is, the building of a routing table) from the data plane, moving the control plane to a software-based centralized controller. In Cisco IT, we see the real value of SDN as enabling network programmability. Network programmability requires two capabilities: harvesting information from network devices, and automatically pushing out new configurations in response to dynamic network conditions or service-provisioning requests.
We’re in the early stages of weaving network programmability into Cisco IT programs. So far, we’ve identified five internal use cases.
Use Case 1: Automating Network Provisioning for Internal Private Cloud
Automated network provisioning is our first production use case for network programmability. Cisco IT offers infrastructure-as-a-service (IaaS) from our internal private cloud, which we call Cisco IT Elastic Infrastructure Services (CITEIS), shown in Figure 1. We’re currently automating network provisioning for CITEIS users by using application programmatic interfaces (APIs) exposed by the Cisco Nexus 1000V Switch and Cisco Prime Network Services Controller (formerly Cisco Virtual Network Management Center). We’re also using a virtual network overlay technique, vPath on the Nexus 1000V, to simplify service insertion and service chaining.
Figure 1 Automated Network Provisioning in the Cisco Private Cloud
Use Case 2: Simplifying Operations by Centralizing Policy and Configuration Management
We’re currently conducting a proof of concept for a classic SDN use case, simplifying switch and router configuration. Network administrators make configuration changes centrally on a controller. Then the controller pushes out the new configuration, automatically using the right command syntax for each device’s hardware and software version. Abstracting the device-specific command syntax will spare network administrators from having to memorize or look up the right syntax for various combinations of device hardware and operating systems used in the Cisco global network.
Use Case 3: Increasing WAN Utilization Through Traffic Steering
Today, routing protocols select paths based on factors such as bandwidth, delay, and hop count —but they don’t typically consider circuit utilization. As a result, the lower-speed backup WAN circuits in Cisco branch offices are used only when the primary circuit fails. When the primary circuit is functioning, why not take advantage of the secondary circuit for non-critical traffic, such as PC backups?
We’ve already created a prototype for traffic steering, and expect to build a proof of concept in calendar year 2014. In the prototype, we used onePK APIs to steer appropriate types of traffic to underutilized low-speed circuits, increasing the utilization of these circuits (Figure 2). When the APIs detect a failure in the primary circuit, they automatically invoke another policy that instructs network devices to drop all non-essential traffic. This helps Cisco IT increase WAN utilization while providing the best possible quality of experience for critical applications when a branch office’s main circuit fails.
Figure 2 Cisco IT’s Traffic Steering Use Case, or Routing Non-Critical Traffic Over Backup Circuits
Use Case 4: Detecting and Mitigating Security Threats
Today, if our network detects that a laptop is sending malware or attacking another system, it prevents further damage by blocking all traffic to and from that laptop. The downside is that the laptop owner can’t work, and our security engineers can’t remotely access the laptop for remediation.
We plan to use onePK APIs to program the network to selectively block only the malware or attack traffic —not other traffic. This more granular approach to mitigation will enable Cisco users to remain productive if their endpoint is infected. It will also accelerate remediation by allowing network security engineers to diagnose and remediate the problem over the network.
Use Case 5: Aggregating Data Center Network Tap Traffic
Numerous Cisco IT teams tap our data center networks to visualize traffic traversing the network—for example, to troubleshoot problems, monitor security, and measure application performance. We actually receive more requests for taps than the network devices can support.
Our idea is to use The Cisco eXtensible Network Controller (XNC) to provide centralized programmatic control of network taps, enabling the same number of staff to support more tap requests. XNC will also let us merge and filter traffic to provide richer and more relevant information.