Cisco Blogs


Cisco Blog > Data Center and Cloud

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: , , , , , , ,

Summary – Network Design for Automation

There has been a lot of recent online discussion about automation of the datacenter network, how we all may (or may not) need to learn programming, the value of a CCIE, and similar topics. This blog tries to look beyond all that. Assume network configuration has been automated. How does that affect network design?

Read my full article to find out more..

Tags: , , , , , , , , ,

Network Design for Automation

20140519-CISCO-spine-and-leafThere has been a lot of recent online discussion about automation of the datacenter network, how we all may (or may not) need to learn programming, the value of a CCIE, and similar topics. This blog tries to look beyond all that. Assume network configuration has been automated. How does that affect network design?

Automation can greatly change the network landscape, or it may change little. It depends on what you’re presently doing for design. Why? The reason is that the programmers probably assumed you’ve built your network in a certain way. As an example, Cisco DFA (Dynamic Fabric Automation) and ACI (Application Centric Infrastructure) are based on a Spine-Leaf CLOS tree topology.

Yes, some OpenFlow vendors have claimed to support arbitrary topologies. Arbitrary topologies are just not a great idea. Supporting them makes the programmers work harder to anticipate all the arbitrary things you might do. I want the programmers to focus on key functionality. Building the network in a well-defined way is a price I’m quite willing to pay. Yes, some backwards or migration compatibility is also desirable.

The programmers probably assumed you bought the right equipment and put it together in some rational way. The automated tool will have to tell you how to cable it up, or it  might check your compliance with the recommended design. Plan on this when you look to automation for sites, a datacenter, or a WAN network.

The good news here is the the Cisco automated tools are likely to align with Cisco Validated Designs. The CVD’s provide a great starting point for any network design, and they have recently been displaying some great graphics. They’re a useful resource if you don’t want to re-invent the wheel — especially a square wheel. While I disagree with a few aspects of some of them, over the years most of them have been great guidelines.

The more problematic part of this is that right now, many of us are (still!) operating in the era of hand-crafted networks. What does the machine era and the assembly line bring with it? We will have to give up one-off designs and some degree of customization. The focus will shift to repeated design elements and components. Namely, the type of design the automated tool can work with.

Some network designers are already operating in such a fashion. Their networks may not be automated, but they follow repeatable standards. Like an early factory working with inter-changeable parts. Such sites have likely created a small number of design templates and then used them repeatedly. Examples: ”small remote office”, “medium remote office”, “MPLS-only office”, or “MPLS with DMVPN backup office”.

However you carve things up, there should only be a few standard models, including “datacenter” and perhaps “HQ” or “campus”. If you know the number of users (or size range) in each such site, you can then pre-size WAN links, approximate number of APs, licenses, whatever. You can also pre-plan your addressing, with, say, a large block of  /25′s for very small offices, /23′s for medium, etc.

On the equipment side, a small office might have one router with both MPLS and DMVPN links, one core switch, and some small number of access switches. A larger office might have one router each for MPLS and one for DMPVN, two core switches, and more access switches. Add APs, WAAS, and other finishing touches as appropriate. Degree of criticality is another dimension you can add to the mix: critical sites would have more redundancy, or be more self-contained. Whatever you do, standardize the equipment models as much as possible, updating every year or two (to keep the spares inventory simple).

It takes some time to think through and document such internal standards. But probably not as much as you think! And then you win when you go to deploy, because everything becomes repeatable.

Read More »

Tags: , , , , , , , , ,

Delivering Policy in the Age of Open Source

This is an exciting time in the history of datacenter infrastructure.  We are witnessing the collision of two major trends: the maturation of open source software and the redefinition of infrastructure policy.
The trend towards open source is self-evident.  Platforms such as OpenStack and OpenDaylight are gaining huge developer mindshare as well as support and investment from major vendors.  Even some newer technologies like Docker, which employs linux kernel containers, and Ceph, a software-based storage solution, offer promising paths in open source.  Given the fundamental requirements of interoperability in architecturally diverse infrastructure environments, its no surprise that open source is gaining momentum.

The second trend around policy is a bit earlier in its evolution but equally disruptive.  Today, there is a huge disconnect between how application developers think about their requirements and the languages and tools through which they are communicated to the infrastructure itself.  For example,  just to handle networking, a simple three tier app must be deconstructed into an array of VLANs, ACLs, and routes spread across a number of devices.  Storage and compute present similar challenges as well.   To simplify this interaction and create more scalable systems, we need to actually rethink how resources are requested and distributed between different components.  This really boils down to shifting the abstraction model away from configuring individual devices to focus on separately capturing user intent, operational, infrastructure, and compliance requirements.

At Cisco, we’ve really embraced both of these trends.  We are active contributors to over 100 open source projects and were founding members of OpenStack Neutron and OpenDaylight.  We’ve also made open source a successful business practice by incorporating and integrating popular projects with our products.  In parallel, Cisco has accumulated a lot of experience in describing policy through the work we’ve done with Cisco Unified Computing (UCS) and most recently with Cisco Application-Centric Infrastructure (ACI).

Building on this foundation, we see a unique opportunity to collaborate with the open source community to deliver a vision for policy-driven infrastructure.  This will enhance the usability, scale, and interoperability of open source software and benefit the entire infrastructure ecosystem.

This vision includes two initiatives in the open source community:

GroupBasedPolicy

  1. Group-Based Policy: An information model designed to express applications’ resource requirements from the network through a hardware-independent, declarative language and leave a simple control and dataplane in place.  This approach replaces traditional networking constructs like VLANs with new primitives such as “groups”, which model tiers or components of an application, and “contracts” describing relationships between them.  Group-Based Policy will be available in the context of OpenStack Neutron as well as OpenDaylight through a plug in model that can support any software or hardware infrastructure.
  2. OpFlex: A distributed framework of intelligent agents within each networking device designed to resolve policies.  These agents would translate an abstract, hardware-independent policy taken from a logically central repository into device-specific features and capabilities.

 

Let’s look a bit more closely at each of these initiatives.

Read More »

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