It’s been almost a year since Cisco publicly unveiled its Application Centric Infrastructure (ACI). As we’ve noted in the past, ACI had to overcome a number of preconceived notions about Software Defined Networking (SDN), and without some detailed explanation, it was hard to get your head around how ACI worked and how it related to SDN. As we continue to clarify the message, there are still a number of ACI myths running around out there that we have to spend a good amount of time dispelling, so I thought I’d summarize them here. (Like Centralized Policy Management, Centralized Myth Handling can lead to greater efficiency and increased compliance. :-)).
1. MYTH: Cisco has limited software expertise and can’t deliver a true SDN solution because ACI requires Cisco switches (hardware) as well as the APIC controller (software).
REALITY: Cisco believes data centers require a solution that combines the flexibility of software with the performance and scalability of hardware. ACI is the first data center and cloud solution to offer full visibility and integrated management of both physical and virtual networked IT resources, all built around the policy requirements of the application. ACI delivers SDN, but goes well beyond it to also deliver policy-based automation.
2. MYTH: ACI requires an expensive “forklift upgrade”– Cisco customers must replace their existing Nexus switches with new ACI-capable switches.
REALITY: ACI is actually quite affordable due to the licensing model we use and because customers can extend ACI policy management to their entire data center by implementing a “pod” with a cost-effective ACI starter kit. On July 29, Cisco announced four ACI starter kits which are cost effective bundles that are ideal for proof-of-concept and lab deployments, and to create an ACI central policy “appliance” for existing Cisco Nexus 2000-7000 infrastructure to scale out private clouds using ACI. Customers who compare ACI to SDN software-only solutions discover that operational costs, roughly 75 percent of overall IT costs, are substantially lower with ACI — so the total cost of ownership is compelling. Along with the fact that the existing network infrastructure can still be leveraged.
3. MYTH: The ACI solution is not open; Cisco doesn’t do enough with the open community.
REALITY: Openness is a core tenet in ACI design. We see openness in three dimensions: open source, open standards, and open APIs. This naturally fosters an open ecosystem as well. Several partners like F5 and Citrix already are shipping device packs for joint deployments. Customers experience tremendous benefits when vendors come together to provide tightly integrated solutions engineered to work together out of the box.
ACI is designed to operate in heterogeneous data center environments with multiple vendors and multiple hypervisors. ACI supports an open ecosystem covering a broad range of Layer 4-7 services, orchestration platforms, and automation tools. One of the key drivers behind this ecosystem is OpFlex, an open standards initiative that helps customers achieve an intelligent, multivendor, policy-enabled infrastructure. Additionally, through contributions to OpenStack Neutron with our Group-Based Policy model, we are offering a fully open source policy API available to any OpenStack user. Cisco is also working with open source Linux vendors like Red Hat and Canonical to distribute an ACI Opflex agent for OVS, and contributing the Group-based Policy model to Open Daylight.
4. MYTH: Customers want SDN solutions for their data center networks, but ACI is not an SDN solution.
REALITY: We believe that SDN or even software defined data centers are not the sole results customers are looking for – it is the policy-based management and automation provided by ACI that delivers tremendous benefits to application deployment and troubleshooting– and provides a compelling TCO by cutting operational costs. Channel partners agree with us: a recent study by Baird Equity Research surveyed 60 channel solution providers and found that they would recommend the Nexus 9000 portfolio and ACI to their customers.
5. MYTH: Cisco can’t compete against cheap commodity “white box” switches – they are the future of data center networks.
REALITY: The truth is that only a handful of companies can effectively deploy white boxes because they require a great deal of operational management and troubleshooting, which is more expensive than the upfront costs of non-commodity hardware. Deutsche Bank published a report last year titled “Whitebox Switches Are Not Exactly a Bargain” which explains how the total cost equation changes when you take into account operational costs. In addition, white boxes don’t include the rich features and capabilities that most companies want. Channel solution providers know this very well. The same Baird Equity Research study of 60 channel solution providers cited above indicated that only 2% would recommend NSX running on white-box or non-Cisco networking gear.
In the data center, “one size does not fit all”, so Cisco offers a variety of switch configurations to match customer needs. For example, customers can start with merchant silicon-based line cards and migrate to an ACI environment with ACI-capable line cards and APIC, if and when they wish.
BOTTOM LINE: We believe that Cisco will continue to win with our partners in the data center by delivering innovation through a highly secure and application centric infrastructure. Through training, support, and new certifications, we are empowering over two million networking engineers and thousands of channel partners worldwide to succeed with ACI in the data center and cloud.
Tags: ACI, APIC, Application Centric Networking, Nexus 9000, Open Daylight, OpenStack, OpFlex, SDN
[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: APIC, Application Centric, Application policy, Cisco ACI, OpenFlow, OpFlex, ovsdb, SDN
[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: APIC, Application Centric, Application policy, Cisco ACI, OpenFlow, OpFlex, ovsdb, SDN
The next stable OpenStack release codenamed “Juno” is slated to be released October 16, 2014. From improving live upgrades in Nova to enabling easier migration from Nova Network to Neutron, the OpenStack Juno release will address operational challenges in addition to providing many new features and enhancements across all projects.
As indicated in the latest Stackalytics contributor statistics, Cisco has contributed to seven different OpenStack projects including Neutron, Cinder, Nova, Horizon and Ceilometer as part of the Juno development cycle. This is up from five projects in the Icehouse release. Cisco also ranks first in the number of completed blueprints in Neutron as well.
In this blog post, I’ll focus on Neutron contributions, which are the major share of contributions in Juno from Cisco.
Cisco OpenStack team lead Neutron Community Contributions
An important blueprint that Cisco collaborated on and implemented with the community was to develop the Router Advertisement Daemon (radvd) for IPv6. With this support, multiple IPv6 configuration modes including SLAAC and DHCPv6 (both Stateful and Stateless modes) are now possible in Neutron. The implementation provides for running a radvd process in the router namespace for handling IPv6 auto address configuration.
To support the distributed routing model introduced by Distributed Virtual Router (DVR), this Firewall as a Service (FWaaS) blueprint implementation handles firewalling North–South traffic with DVR. The fix ensures that firewall rules are installed in the appropriate namespaces across the Network and Compute nodes to support perimeter firewall (North-South). However, firewalling East-West traffic with DVR will be handled in the next development cycle as a Distributed Firewall use case.
Additional capabilities in the ML2 and services framework were contributed for enabling better plugin and vendor driver integration. This included the following blueprint implementations -
Cisco device specific contributions in Neutron
Cisco added Application Policy Infrastructure Controller (APIC) ML2 MD and Layer 3 Service Plugin in the Juno development cycle. The ML2 APIC MD translates Neutron API calls into APIC data model specific requests and achieves tenant Layer 2 isolation through End-Point-Groups (EPG).
The APIC MD supports dynamic topology discovery using LLDP, reducing the configuration burden in Neutron for APIC MD and also ensures data is in-sync between Neutron and APIC. Additionally, the Layer 3 APIC service plugin enables configuration of internal and external subnet gateways on routers using Contracts to enable communication between EPGs as well as provide external connectivity. The APIC ML2 MD and Service Plugin have also been made available with OpenStack IceHouse release. Installation and Operation Guide for the driver and plugin is available here.
Enterprise-class virtual networking solution using Cisco Nexus1000v is enabled in OpenStack with its own core plugin. In addition to providing host based overlays using VxLAN (in both unicast and multi-cast mode), it provides Network and Policy Profile extensions for virtual machine policy provisioning.
The Nexus 1000v plugin added support for accepting REST API responses in JSON format from Virtual Supervisor Module (VSM) as well as control for enabling Policy Profile visibility across tenants. More information on features and how it integrates with OpenStack is provided here.
As an alternative to the default Layer 3 service implementations in Neutron, a Cisco router service plugin is now available that delivers Layer 3 services using the Cisco Cloud Services Router(CSR) 1000v.
The Cisco Router Service Plugin introduces a notion of “hosting device” to bind a Neutron router to a device that implements the router configuration. This allows the flexibility to add virtual as well as physical devices seamlessly into the framework for configuring services. Additionally, a Layer 3+ “configuration agent” is available upstream as well that interacts with the service plugin and is responsible for configuring the device for routing and advanced services. The configuration agent is multi-service capable, supports configuration of hardware or software based L3 service devices via device drivers and also provides device health monitoring statistics.
The VPN as a Service (VPNaaS) driver using the CSR1000v has been available since the Icehouse release, as a proof-of-concept implementation. The Juno release enhances the CSR1000v VPN driver such that it can be used in a more dynamic, semi-automated manner to establish IPSec site-to-site connections, and paves the way for a fully integrated and dynamic implementation with the Layer 3 router plugin planned for the Kilo development cycle.
The OpenStack team at Cisco has led, implemented and successfully merged upstream numerous blueprints for the Neutron Juno release. Clearly, some have been critical for the community and others enable customers to better integrate Cisco networking solutions with OpenStack Networking.
Stay tuned for more information on other project contributions in Juno and on Cisco lead sessions at the Kilo Summit in Paris !
You can also download OpenStack Cisco Validated Designs, White papers, and more at www.cisco.com/go/openstack
Tags: ACI, APIC, CSR1000v, IPv6, Juno, Neutron, Nexus1000V, OpenStack
I am a consultant at a Cisco partner and I get to see a lot of different networks. Most of the networks are Cisco, but there are a few that are not. From time to time, I get network assessment projects. I love these types of projects as they are an exploration of uncharted networks to see what can be discovered. Personally I like to have my network consistent, orderly, and precise. The common components of the configurations on all device should be identical. These network assessments usually do not conform to these standards. Syslog configured on some devices pointing to a device that no longer Read More »
Tags: #ciscochampion, APIC, nexus