[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
By Gina Nienaber, Marketing Manager, SP Product and Solutions Marketing
Cisco estimates over 50 billion new devices will be connected to the Internet by 2020. To support the Internet of Everything, service providers must undergo an infrastructure transformation. The network needs to become more open, programmable, automated, adaptive, and agile. To guide this transformation, the Cisco open network strategy for service providers is depicted as three interwoven layers: the Evolved Programmable Network (physical and virtual network Infrastructure), the Evolved Services Platform (for orchestration of resources) and Applications and Services layer to enable virtualized services such as Cloud VPN and Security. With these three layers working together, providers can begin to realize the benefits of an open network that is readily open to new devices, open for quickly enabling new services, and open to endless possibilities.
Last week, Cisco announced two Read More »
Tags: Cisco Evolved Programmable Network, control, epn, esp, evolved services platform, IPv6, NFV, open network architecture, open network strategy, programmability, SDN, Service Provider, SP, virtualization
Written by Greg Nehib, Cisco Senior Product Marketing Manager
Network functions virtualization (NFV) and Software Defined Networking (SDN) will get a lot of interest this year at BBWF 2014 Broadband World Forum 2014 as carriers seek to make networks more agile and efficient. In talking to both service providers and large enterprises, it’s clear that we are already in another major transition in the networking industry.
I’ve spoken with many talented individuals about what NFV and SDN means to their networks. Some of these visions are very broad and long ranging and some are more narrowly focused on delivering or optimizing a single service very quickly. It’s clear that NFV has already been deployed in many different service applications while SDN has been noticeably slower to develop a focused following. Even in the case of Virtualized Network Functions (VNFs), there is an interesting combination of features focused on services delivery and features focused on infrastructure innovation. In this case “services” are typically the services that carriers sell to their end customers such as a Virtual Private Network (VPN) and “infrastructure” is the virtualization of the typical network functions such as a virtualized route reflector on an x86 based server instead of running the route reflector application in an existing (physical) router. Read More »
Tags: BBWF, Cisco, network functions virtualization, opex, router, SDN, service providers, software defined network, virtualization, VNF
Organizations are migrating to the cloud because it dramatically reduces IT costs as we make much more efficient use of resources (either ours or by leveraging some cloud provider’s resources at optimal times). When done right, cloud also increases business agility because applications and new capacity can be spun up quickly on demand (on-premises or off), network and services configurations can be updated automatically to suit the changing needs of the applications, and, with enough bacon, unicorns can fly and the IT staff can get home at a reasonable hour.
Whenever you ask a CIO-type at any of these organizations what’s holding them back from all this cloud goodness, though, more often than not the answer has something to do with security: “Don’t trust the cloud…”, “Don’t trust the other guy in the cloud…”, “Cloud’s not compliant…”. You have to be something of a control freak to be a CIO/CISO these days, and, well, isn’t “cloud” all about giving up some control, after all (in return for efficiency and agility)?
Even if you overcome your control issues and you find a cloud you can trust (even if it’s your own private cloud – we can take baby steps here…), if we are going to achieve our instant on-demand application deployment, network provisioning and cost-efficient workload placement process, it turns out all the security stuff can throw another obstacle in our way. Cloud security isn’t like old-fashioned data center security where you could just put a huge firewall in front of the data center and call it good. For secure multi-tenancy and a secure cloud overall, virtually every workload (or “every virtual workload”?) needs to be secured from every other (except for the exceptions we want to make). Some folks call this “microsegmentation”, a fancy word for an old concept, but, a fundamental requirement that cloud deployments need to address. (Spoiler alert: ACI does this very well.) Read More »
Tags: ACI, application centric infrastructure, Cisco ASA, SDN
We are excited to announce the availability of Cisco Nexus Data Broker software release 2.0. Using the Cisco Nexus Data Broker software, Cisco’s approach replaces the traditional purpose-built matrix switches used for network taps or SPAN aggregation with one or more OpenFlow-enabled Cisco Nexus switches.
Visibility into application traffic has traditionally been important for infrastructure operations to maintain security, resolve problems, and perform resource planning. Now, however, as a result of technological advances and the ubiquity of the Internet, organizations increasingly are seeking not just visibility but real-time feedback about their business systems to more effectively engage their customers. Also, with the rapid evolution of cloud-based technologies, there is a strong need for scalable and cost-effective network traffic tap/SPAN aggregation for traffic monitoring solutions. The traditional approach that uses purpose-built matrix switches for netowrk tap/SPAN aggregation to feed traffic to multiple systems for security, compliance and application performance monitoring has three primary challenges:
- This approach is too expensive to scale the visibility to meet today’s business requirements.
- The purpose-built switches are statically programmed with predetermined filtering and forwarding rules, so they cannot act in an event-based way to provide traffic visibility in real time.
- Support for interconnecting multiple switches for a scalable deployment that suits your data center architecture is limited.
With Cisco Nexus Data Broker (see Figure 1), the traffic is tapped into this bank of switches in the same manner as in a purpose-built matrix network. However, with Cisco Nexus Data Broker, you can interconnect these Cisco Nexus switches to build a scalable tap and SPAN aggregation infrastructure. You also can use a combination of network taps and SPAN sources to bring the copy of the production traffic to this infrastructure. In addition, you can distribute the network tap and SPAN sources and traffic monitoring and analysis tools across multiple Cisco Nexus switches. Cisco Nexus Data Broker also provides the flexibility to aggregate traffic from multiple tap or SPAN sources and replicate and forward traffic to multiple analysis tools for monitoring. See Table 1 for a list of important features and functions.
Features of the New Cisco Data Broker Release 2.0
|Supported topology for Cisco® Monitor Manager network
- Cisco Nexus Data Broker software discovers the Cisco Nexus switches and associated topology for Tap/SPAN aggregation.
- The software allows you to configure ports as monitoring tool ports or input Tap/SPAN ports.
- You can set end-device names for easy identification in the topology.
|Support for QinQ to tag input source Tap/SPAN port
- You can tag traffic with a VLAN for each input Tap or SPAN port.
- Q-in-Q support in edge Tap and SPAN ports allow you to uniquely identify the source of traffic and preserve production VLAN information.
|Symmetric hashing or symmetric load balancing*
- You can configure the hashing based on Layer 3 (IP address) or Layer 3 + Layer 4 (protocol ports) for load balancing the traffic across a port-channel link.
- You can spread the traffic across multiple tool instances to meet the high-traffic-volume scale.
|Rules for matching monitored traffic
- You can match traffic based on Layer 1 through Layer 4 criteria.
- You can configure the software to send only the required traffic to the monitoring tools without flooding the tools with unnecessary traffic.
- You can configure action to set the VLAN ID for the matched traffic.
|Replicate and forward traffic
- You can configure the software to aggregate traffic from multiple input Tap/SPAN ports that could be spread across multiple Cisco Nexus switches.
- You can replicate and forward traffic to multiple monitoring tools that can be connected across multiple Cisco Nexus switches.
- This solution is the only one that supports any:many forwarding across a topology.
- You can time-stamp a packet at ingress using the Precision Time Protocol (PTP; IEEE 1588), thereby providing nanosecond accuracy. You can use this capability for critical transaction monitoring and archiving data for regulatory compliance and advance troubleshooting.
- You can configure the software to truncate a packet beyond specified bytes.
- The minimum is 64 bytes.
- You can retain a header for only analysis and troubleshooting.
- You can configure the software to discard the payload for security or compliance reasons.
|End-to-end path visibility
- For each traffic forwarding rule, the solution provides a complete end-to-end path visibility all the way from source ports to the monitoring tools, including the path through the network.
|React to changes in the Tap/SPAN aggregation network states
- You can monitor and keep track of network condition changes.
- You can configure the software to react to link or node failures by automatically reprogramming the flows through an alternative path.
|Management for multiple disjointed Cisco Monitor Manager networks
- You can manage multiple independent traffic monitoring networks, which may be disjointed, using the same Cisco Nexus Data Broker instance. For example, if you have five data centers and you want to deploy an independent Cisco Monitor Manager solution for each data center, you can manage all of these five independent deployments using a single Cisco Nexus Data Broker instance by creating a logical partition (network slice) for each monitoring network.
|Role Based Access Control (RBAC)
- Application access can be integrated with corporate AAA server for both authentication and authorization
- You can create port groups and associate the port groups with specific user roles
- Capability to assign users to specific roles and port groups; users can manage only those ports
*Feature supported only on Cisco Nexus 3500.
**Feature supported only on Cisco Nexus 3100.
Please visit the Cisco NDB website for more information. If you are going to be in NYC at Interop Sep 29 -- Oct 2, please visit us to hear Jothi Prakash Prabakaran talk about Nexus Data Broker as a scalable network traffic monitoring solution in the Cisco booth (#611) theater.
Tags: Cisco Nexus Data Broker, Data Center Visibility, NDB, Nexus 3000, Nexus 7000, SDN, Tap/SPAN aggregation