Cisco Blogs


Cisco Blog > Data Center and Cloud

The Benefits of an Application Policy Language in Cisco ACI: Part 4 – Application Policies for DevOps

October 21, 2014 at 5:00 am PST

[Note: This is the last installment of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not.  Part 1 | Part 2 | Part 3]

As noted earlier in this series, modern DevOps applications such as Puppet, Chef, and CFEngine have already moved toward the declarative model of IT automation, so there is already some obvious synergy between DevOps and the Cisco ACI policy model. DevOps automation products are also optimizing application delivery processes and are designed to automate critical IT tasks to make the organization more agile and efficient.

In an early 2014 blog post, Andi Mann, vice president of strategic solutions at CA Technologies, wrote about the evolution to DevOps and the synergy with the Cisco ACI policy model:

Though the DevOps approach of today—with its notable improvements to culture, process, and tools—certainly delivers many efficiencies, automation and orchestration of hardware infrastructure has still been limited by traditional data center devices, such as servers, network switches and storage devices. Adding a virtualization layer to server, network, and storage, IT was able to divide some of these infrastructure devices, and enable a bit more fluidity in compute resourcing, but this still comes with manual steps or custom scripting to prepare the end-to-end application infrastructure and its networking needs used in a DevOps approach.

The drag created by these traditional application infrastructures has been somewhat reduced by giving that problem to cloud providers, but in reality this drag never really went away until Cisco innovated application-centric programmability with Cisco ACI. This innovative new solution is now poised to greatly benefit the whole application economy, especially management of the DevOps application environment…

Read More »

Tags: , , , , , , , , ,

The Benefits of an Application Policy Language in Cisco ACI: Part 2 – The OpFlex Protocol

October 14, 2014 at 5:00 am PST

[Note: This is the second of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not.  Part 1 | Part 3 | Part 4]

Following on from the first part of our series, this blog post takes a closer look at some of these architectural components of Cisco ACI and the VMware NSX software overlay solution to quantify the advantages of Cisco’s application-centric policies and demonstrate how the architecture supports greater scale and more robust IT automation.

As called for in the requirements listed in the previous section, Cisco ACI is an open architecture that includes the policy controller and policy repository (Cisco APIC), infrastructure nodes (network devices, virtual switches, network services, etc.) under Cisco APIC control, and a protocol communication between Cisco APIC and the infrastructure. For Cisco ACI, that protocol is OpFlex.

OpFlex was designed with the Cisco ACI policy model and cloud automation objectives in mind, including important features that other SDN protocols could not deliver. OpFlex supports the Cisco ACI approach of separating the application policy from the network and infrastructure, but not the control plane itself. This approach provides the desired centralization of policy management, allowing automation of the entire infrastructure without limiting scalability through a centralized control point or creating a single point of catastrophic failure. Through Cisco ACI and OpFlex, the control engines are distributed, essentially staying with the infrastructure nodes that enforce the policies.

Read More »

Tags: , , , , , , ,

The Benefits of an Application Policy Language in Cisco ACI: Part 1 – Enabling Automation

October 10, 2014 at 5:00 am PST

[Note: This is the first of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not.  Part 2 | Part 3 | Part 4]

IT departments and lines of business are looking at cloud automation tools and software-defined networking (SDN) architectures to accelerate application delivery, reduce operating costs, and increase business agility. The success of an IT or cloud automation solution depends largely on the business policies that can be carried out by the infrastructure through the SDN architecture.

Through a detailed comparison of critical architectural components, this blog series shows how the Cisco Application Centric Infrastructure (ACI) architecture supports a more business-relevant application policy language, greater scalability through a distributed enforcement system rather than centralized control, and greater network visibility than alternative software overlay solutions or traditional SDN designs.

Historically, IT departments have sought out greater automation as device proliferation has accelerated to overcome the challenges of applying manual processes for critical tasks. About 20 years ago the automation of desktop and PC management was an imperative, and about 10 years ago server automation became important as applications migrated to larger numbers of modular x86 and RISC-based systems. Today, with the consolidation of data centers, IT must address not only application and data proliferation, but also the emergence of large scale application virtualization and cloud deployments, requiring IT to focus on cloud and network automation.

The emergence of SDN promised a new era of centrally managed, software-based automation tools that could accelerate network management, optimization, and remediation. Gartner has defined SDN as “a new approach to designing, building and operating networks that focuses on delivering business agility while lowering capital and operational costs.” (Source: “Ending the Confusion About Software-Defined Networking: A Taxonomy”, Gartner, March 2013)

Furthermore, Gartner, in an early 2014 report (“Mainstream Organizations Should Prepare for SDN Now”, Gartner, March 2014), notes that “SDN is a radical new way of networking and requires senior infrastructure leaders to rethink traditional networking practices and paradigms.” In this same report, Gartner makes an initial comparison of mainstream SDN solutions that are emerging, including VMware NSX, and Cisco ACI. There has been some discussion whether Cisco ACI is an SDN solution or something more, but most agree that, in a broad sense, the IT automation objectives of SDN and Cisco ACI are basically the same, and some of the baseline architectural features, including a central policy controller, programmable devices, and use of overlay networks, lead to a useful comparison.

This blog series focuses on the way that Cisco ACI expands traditional SDN methodology with a new application-centric policy model. It specifically compares critical protocols and components in Cisco ACI with VMware NSX to show the advantages of Cisco ACI over software overlay networks and the advantages of the ACI application policy model over what has been offered by prior SDN solutions. It also discusses what the Cisco solution means for customers, the industry, and the larger SDN community.

Read More »

Tags: , , , , , , ,

OpenDaylight Unleashes Hydrogen to the Masses

The OpenDaylight Project today announced that its first open source software release Hydrogen is now available for download. As the first simultaneous code release cross-community it has contributions across fifty organizations and includes over one million lines of code. Yes. ODL > 1MLOC. For those of you interested that’s approximately two hundred and thirty man-years of work completed in less than twelve months.

It was around this time last year that the media started to pick up on a few rumors that something may be in the works with software-defined networking and controllers. I remember our first meeting at Citrix where the community started to collaborate on The OpenDaylight Project and come to common ground on how to start something this large. We had multiple companies and academics in the room and many ideas of where we wanted this project to go but there was one thing we had in common: the belief and vision to drive networking software innovation to the Internet in a new way and accelerate SDN in the open; transparently and with diverse community support. Each of us had notions of what we could bring to the table, from controller offerings to virtualization solutions, SDN protocol plugins and apps to solve IT problems. Over two days at Citrix we looked at things from a customer perspective, a developer perspective and ultimately and arguably the most important, a community perspective. From there The OpenDaylight Project emerged under the Linux Foundation. As I look back I want to applaud and thank the companies, partners, developers, community members and the Linux Foundation for driving such a large vision from concept to reality in less than twelve months, which is an incredible feat in itself.

Hydrogen is truly a community release. Use cases span across enterprise, service provider, academia, data center, transport and NfV. There are multiple southbound protocols abstracted to a common northbound API for cross-vendor integration and interoperability and three editions have been created to ensure multi-domain support and application delivery as well as deployment modularity and flexibility for different domain-specific configurations. These packages have a consistent environment yet are tailored to domain and role-based needs of network engineers, developers and operators.

  • The Base Edition, which includes a scalable and multi-vendor SDN protocol based on OSGi, the latest (and backward compatible) OpenFlow 1.3 Plugin and Protocol Library, OVSDB, NetConf/Yang model driver SDN and Java-based YANG tooling for model-driven development.
  • The Virtualization Edition (which includes the Base Edition) and adds Affinity Metadata Service (essentially APIs to express workload relationships and service levels), Defense4All (DDoS detection & mitigation), Open DOVE, VTN, OpenStack Neutron NorthBound API support and a virtual tenant network offering.
  • The Service Provider Edition (again, including the Base Edition) that also offers the Metadata Services and Defense4All but includes BGP-LS and PCEP, LISP Flow Mapping and SNMP4SDN to manage routers, gateways switches.

More information can be found on the website with regards to the releases and projects themselves.

I want to stress the importance of how well the vision has been delivered to date. I’ve been involved in multiple standards-bodies and in open source discussions in the past but this is truly one of the largest undertakings I’ve seen come together in my entire career. OpenDaylight developers have been coding day and night to get this release out the door and it’s amazing to see the collaboration and coherency of the team as we unite to deliver on the industry’s first cross-vendor SDN and NfV Platform. In addition and frequently not mentioned is that many of the protocols listed in the Editions above are also standardized at organizations like the IETF during the same period. Code and specs at the same time. It’s been a long time since rough consensus and running code has been the norm.

Over here at Cisco we’re fully committed to OpenDaylight. We’re currently using it as a core component in our WAN Orchestration offering for service providers to allow intelligent network placement and automated capacity and workload planning. The ACI team (formerly Insieme) collaborated with IBM, Midokura and Plexxi to create a project in OpenDaylight that creates a northbound API that can set policy and be used across a wide range of network devices. And of course we’re bringing components of the OpenDaylight codebase into our own controllers and ensuring application portability for customers, partners and developers alike. From this I would expect to see more code donations going into the community moving forward as well. We made several announcements last week about our campus/branch controller that includes OpenDaylight technology.

At the end of the day an open source project is only as strong as its developers, its community and its code. As we as a community move forward with OpenDaylight I expect it to become stronger with more members joining with new project proposals as new code contributors coming onboard from different industries as well. As I look at our roadmap and upcoming release schedule I’m pumped for what’s next and so happy the community has catalyzed a developer community around networking.

Please do visit the site, download the code and take Hydrogen for a test-drive. We want to hear feedback on what we can make better, what features to add or how you’re going to utilize it. Moreover, we’d love you to participate. It’s a kick-ass community and I think you’ll have fun and the best part; you’ll see your hard work unleashed on the Internet and across multiple communities too.

Tags: , , , , , , , , , , , , , , , , , , ,