Cisco Application Policy Infrastructure Controller Data Center Policy Model

Size: px
Start display at page:

Download "Cisco Application Policy Infrastructure Controller Data Center Policy Model"

Transcription

1 White Paper Cisco Application Policy Infrastructure Controller Data Center Policy Model This paper examines the Cisco Application Centric Infrastructure (ACI) approach to modeling business applications to the Cisco ACI network fabric and applying consistent, robust policies to those applications. The approach is a unique blend of mapping hardware and software capabilities to the deployment of applications either graphically through the Cisco Application Policy Infrastructure Controller (APIC) GUI or programmatically through the Cisco APIC API. Cisco ACI Policy Theory The Cisco ACI fabric is designed as an application-centric intelligent network. The Cisco APIC policy model is defined from the top down as a policy enforcement engine focused on the application itself and abstracting the networking functionality underneath. The policy model marries with the advanced hardware capabilities of the Cisco ACI fabric underneath the business application-focused control system. The Cisco APIC policy model is an object-oriented model based on promise theory. Promise theory is based on declarative, scalable control of intelligent objects, in comparison to legacy imperative models, which can be thought of as heavyweight, top-down management. An imperative model is a big brain system or top-down style of management. In these systems the central manager must be aware of both the configuration commands of underlying objects and the current state of those objects. Figure 1 depicts this model Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 21

2 Figure 1. Imperative Model of Systems Management in Which Intelligent Controller Pushes Configuration to Underlying Components Promise theory, in contrast, relies on the underlying objects to handle configuration state changes initiated by the control system as desired state changes. The objects are in turn also responsible for passing exceptions or faults back to the control system. This lightens the burden and complexity of the control system and allows for greater scale. These systems scale further by allowing for methods of underlying objects to in turn request state changes from one another and/or lower level objects. Figure 2 depicts promise theory. Figure 2. Promise Theory Approach to Large-Scale System Control Underlying the promise theory-based model, Cisco APIC builds an object model to focus on the deployment of applications and with the applications themselves as the central focus. Traditionally applications have been restricted by capabilities of the network. Concepts such as addressing, VLAN, and security have been tied together, limiting the scale and mobility of the application itself. Because today s applications are being redesigned for mobility and web scale, this is not conducive to rapid and consistent deployment Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 21

3 The physical Cisco ACI fabric itself is built on a spine-leaf design; its topology is illustrated in Figure 3 using a bipartite graph, where each leaf, known as an leaf, is a switch that connects to each spine switch, and no direct connections are allowed between leaf switches and between spine switches. The ileaves act as the connection point for all external devices and networks, and the spine acts as the high-speed forwarding engine between leaves. Cisco ACI fabric is managed, monitored, and administered by the Cisco APIC. Figure 3. ACI Spine-Leaf Fabric Design Cisco APIC Policy Object Model At the top level the APIC policy model is built on a series of one or more tenants, which allow the network infrastructure administration and data flows to be segregated out. One or more tenants can be used for customers, business units, or groups, depending on organizational needs. For instance, a given enterprise might use one tenant for the entire organization, while a cloud provider might have customers using one or more tenants to represent its organization. Tenants further break down into private Layer 3 networks, which directly relate to a Virtual Route Forwarding (VRF) instance or separate IP space. Each tenant may have one or more private Layer 3 networks depending on the business needs of that tenant. Private Layer 3 networks provide a way to further separate the organizational and forwarding requirements below a given tenant. Because contexts use separate forwarding instances, IP addressing can be duplicated in separate contexts for the purpose of multitenancy. Below the context the model provides a series of objects that define the application itself. These objects are endpoints, endpoint groups (EPGs), and the policies that define their relationship. It is important to note that policies in this case are more than just a set of access control lists (ACLs) and include a collection of inbound/outbound filters, traffic quality settings, marking rules/redirection, rules and Layer 4 through 7 service device graphs. This relationship is shown in Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 21

4 Figure 4. Cisco APIC Logical Object Model Figure 4 depicts two contexts under a given tenant and the series of applications that make up that context. The EPGs shown are groups of endpoints that make up an application tier or other logical application grouping. For example, Application B shown expanded on the right, could be a blue web tier, red application tier, and orange database tier. The combination of EPGs and the policies that define their interaction is an application profile on the Cisco ACI fabric. Endpoint Groups Endpoint groups (EPGs) are a collection of similar endpoints representing an application tier or set of services. They provide a logical grouping for objects that require similar policy. For example, an EPG could be the group of components that make up an applications web tier. Endpoints themselves are defined using NIC, vnic, IP address, or DNS name with extensibility for future methods of identifying application components. EPGs are also used to represent other entities such as outside networks, network services, security devices, network storage, and so on. EPGs are collections of one or more endpoints providing a similar function. They are a logical grouping with varying use options depending on the application deployment model in use. Figure 5 depicts the relationship between endpoints, EPGs, and applications themselves Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 21

5 Figure 5. Endpoint Group Relationships EPGs are designed for flexibility, allowing their use to be customized to one or more deployment models a given customer might choose. The EPGs themselves are then used to define where policy is applied. Within the Cisco ACI fabric, policy is applied between EPGs, therefore defining how EPGs communicate with one another. This is designed to be extensible in the future to policy application within an EPG itself. Some example uses of EPGs are: EPG defined by traditional network VLANs All endpoints connecting to a given VLAN are placed in an EPG EPG defined by a VxLAN Same as preceding using VxLAN EPG mapped to a VMware port group EPG defined by IPs or subnet For example, or * EPG defined by DNS names or DNS ranges For example, example.web.cisco.com or *.web.cisco.com The use of EPG is intentionally left both flexible and extensible. The model is intended to provide tools to build an application s network representation in a model that maps to the actual environment s deployment model. Additionally, the definition of endpoints themselves is intended to be extensible to provide support for future product enhancements and industry requirements. The implementation of EPGs within the fabric provides several valuable benefits. EPGs act as a single policy enforcement point for a group of contained objects. This simplifies configuration of these policies and makes sure that it is consistent. Additional policy is applied based on not subnet, but rather on the EPG itself. This means that IP addressing changes to the endpoint itself do not necessarily change its policy, as is commonly the case in traditional networks (the exception here is an endpoint defined by its IP). Alternatively, moving an endpoint to another EPG would apply the new policy to the leaf switch to which the endpoint is connected and define new behavior for that endpoint based on the new EPG. Figure 6 depicts these benefits Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 21

6 Figure 6. EPG Benefits within Fabric The final benefit provided by EPGs is in the way in which policy is enforced for an EPG. The physical ternary content-addressable memory (TCAM) in which policy is stored for enforcement is an expensive component of switch hardware and therefore tends to lower policy scale or raise hardware costs. Within the Cisco ACI fabric, policy is applied based on the EPG rather than the endpoint itself. This policy size can be expressed as n * m * f, where n is the number of sources, m is the number of destinations, and f is the number of policy filters. Within the Cisco ACI fabric, sources and destinations become one entry for a given EPG, which reduces the number of total entries required. This benefit is shown in Figure 7. Figure 7. EPG Role in Policy Reduction 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 21

7 As discussed, policy within an Cisco ACI fabric is applied between two EPGs. These policies can be applied in either a unidirectional or bidirectional mode between any given pair of EPGs. These policies then define the allowed communication between EPGs. This is shown in Figure 8. Figure 8. Unidirectional and Bidirectional Policy Enforcement Cisco APIC Policy Enforcement The relationship between EPGs and policies can be thought of as a matrix with one axis representing source EPGs (sepgs) and the other representing destination EPGs (depgs). One or more policies will be placed in the intersection between appropriate sepgs and depgs. The matrix will end up sparsely populated in most cases because many EPGs will have no need to communicate with one another. (See Figure 9) Figure 9. Policy Enforcement Matrix 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 21

8 Policies themselves break down into a series of filters for quality of service, access control, and so on. Filters are specific rules that make up the policy between two EPGs. Filters are composed of inbound and outbound: permit, deny, redirect, log, copy (separate from SPAN), and mark functions. Policies allow for wildcard functionality within the definition. The enforcement of policy typically takes a most specific match first approach. The table in Figure 10 shows the specific enforcement order. Figure 10. Wildcard Enforcement Rules Enforcement of policy within the fabric is always guaranteed; however, policy can be applied in one of two places. Policy can be enforced opportunistically at the ingress leaf; otherwise, it is enforced on the egress leaf. Whether or not policy can be enforced at ingress is determined by whether the destination EPG is known. The source EPG will always be known, and policy rules pertaining to that source as both an sepg and a depg are always pushed to the appropriate leaf switch when an endpoint attaches. After policy is pushed to an leaf, it is stored and enforced in hardware. Because the Cisco APIC is aware of all EPGs and the endpoints assigned to them, the leaf to which the EPG is attached will always have all policies required and will never need to punt traffic to a controller, as might be the case in other systems. (See Figure 11) Figure 11. Applying Policy to Leaf Nodes 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 21

9 If the destination EPG is not known, policy cannot be enforced at ingress. Instead, the source EPG is tagged, and policy applied bits are not marked. Both of these fields exist in the reserved bits of the VxLAN header. The packet is then forwarded to the forwarding proxy, typically resident in the spine. The spine is aware of all destinations in the fabric; therefore, if the destination is unknown, the packet is dropped. If the destination is known, the packet is forwarded to the destination leaf. The spine never enforces policy; this will be handled by the egress leaf. When a packet is received by the egress leaf, the sepg and the policy applied bits are read (these were tagged at ingress). If the policy applied bits are marked as applied, the packet is forwarded without additional processing. If instead the policy applied bits do not show that policy has been applied, the sepg marked in the packet is matched with the depg (always known on the egress leaf), and the appropriate policy is then applied. This is shown in Figure 12. Figure 12. Enforcing Policy on Fabric 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 21

10 The opportunistic policy application allows for efficient handling of policy within the fabric. This opportunistic nature of policy application is further represented in Figure 13. Figure 13. Opportunistic Ingress Enforcement of Policy Multicast Policy Enforcement The nature of multicast makes the requirements for policy enforcement slightly different. Although the source EPG is easily determined at ingress because it is never a multicast address, the destination is an abstract entity; the multicast group may consist of endpoints from multiple EPGs. In multicast cases the Cisco ACI fabric uses a multicast group for policy enforcement. The multicast groups are defined by specifying a multicast address range or ranges. Policy is then configured between the sepg and the multicast group. (See Figure 14) Figure 14. Multicast Group (Specialized Multicast EPG) 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 21

11 The multicast group (EPG group corresponding to the multicast stream) will always be the destination and never used as a source EPG. Traffic sent to a multicast group will be either from the multicast source or a receiver joining the stream through an IGMP join. Because multicast streams are nonhierarchical and the stream itself will already be in the forwarding table (using IGMP join), multicast policy is always enforced at ingress. This prevents the need for multicast policy to be written to egress leaves. (See Figure 15) Figure 15. Multicast Policy Enforcement Application Network Profiles As stated earlier, an application network profile (ANP) within the fabric is a collection of the EPGs, their connections, and the policies that define those connections. ANPs become the logical representation of all of an application and its interdependencies on the Cisco ACI fabric. ANPs are designed to be modeled in a logical fashion, which matches the way applications are designed and deployed. The configuration and enforcement of the policies and connectivity are then handled by the system itself using the Cisco APIC rather than through an administrator. Figure 16 shows an example ANP. Figure 16. Application Network Profile 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 21

12 Creating ANPs requires three general steps: Creation of EPGs, as discussed earlier Creation of policies that define connectivity and include: Permit Deny Log Mark Redirect Copy to Service graphs Creating connection points between EPGs utilizing policy constructs known as contracts Contracts Contracts define inbound and outbound permits, denies, QoS, redirects, and service graphs. Contracts allow for both simple and complex definition of how a given EPG communicates with other EPGs dependent on the requirements of a given environment. This relationship is shown in Figure 17. Figure 17. Contracts with Application Network Profiles (ANPs) In Figure 17 we see the relationship between the three tiers of a web application defined by EPG connectivity and the contracts that define their communication. The sum of these parts becomes an ANP. Contracts also provide reusability and policy consistency for services that typically communicate with multiple EPGs. Figure 18 uses the concept of network file system (NFS) and management resources to show this Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 21

13 Figure 18. Complete Application Profile Figure 18 shows the basic three-tier web application used previously with some common additional connectivity that would be required in the real world. In this diagram we see shared network services, NFS, and management, which would be used by all three tiers as well as other EPGs within the fabric. In these cases the contract provides a reusable policy defining how the NFS and MGMT EPGs produce functions or services that can be consumed by other EPGs. Within the Cisco ACI fabric, the what and where of policy application have been intentionally separated. This allows policy to be created independently of how it is applied and reused where required. The actual policy configured in the fabric will be determined based on the policy itself defined as a contract (the what) and the intersection of EPGs and other contracts with those policies (the where). In more complex application deployment environments, contracts can be further broken down using subjects, which can be thought of as applications or subapplications. To better understand this concept, think of a web server. Although it might be classified as web, it might be producing HTTP, HTTPS, FTP, and so on, and each of these subapplications might require different policies. Within the Cisco APIC model, these separate functions or services are defined using subjects, and subjects are combined within contracts to represent the set of rules that define how an EPG communicates with other EPGs. (See Figure 19) Figure 19. Subjects within Contract 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 21

14 Subjects describe the functions that an application exposes to other processes on the network. This can be thought of as producing a set of functions: that is, the web server produces HTTP, HTTPS, and FTP. Other EPGs then consume one or more of these functions; which EPGs consume these services are defined by creating relationships between EPGs and contracts, which contain the subjects defining applications or subapplications. Full policy is defined by administrators defining groups of EPGs that can consume what another provides. This model provides functionality for hierarchical EPGs, or more simply EPGs that are groups of applications and subapplications. (See Figure 20) Figure 20. Subjects within Contract Additionally, this model provides the capability to define a disallow list on a per EPG basis. These disallows override the contract itself, making sure that certain communication can be denied on a per EPG basis. These disallows are known as taboos. This capability provides the ability to provide a blacklist model within the Cisco ACI fabric, as shown in Figure 21. Figure 21. Use of Taboos to Create Blacklist Behavior 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 21

15 Figure 21 shows that a contract can be defined allowing all traffic from all EPGs. This allow is then refined by creating a taboo list of specific ports or ranges that are undesirable. This model provides a transitional method for customers desiring to migrate over time from a blacklist model, which is typically in use today, to the more desirable whitelist model. Blacklist is a model in which all communication is open unless explicitly denied, whereas a whitelist model requires communication to be explicitly defined before being permitted. It is important to remember that disallow lists are optional, and in a full whitelist model they will rarely be needed. Contracts provide a grouping for the descriptions and associated policies that define those application services. They can be contained within a given scope, tenant, context, or EPG as a local contract. An EPG is also capable of subscribing to multiple contracts, which will provide the superset of defined policies. Although contracts can be used to define complex real-world application relationships, they can also be used very simply for traditional application deployment models. For instance, if a single VLAN/VxLAN is used to define separate services, and those VLANs are tied to port groups within VMware, a simple contract model can be defined without unneeded complexity. (See Figure 22) Figure 22. Using Contracts with VMware Port Groups However, in more advanced application deployment models such as PaaS, SOA 2.0, and Web 2.0 models, where more application granularity is required, complex contract relationships can be used. These relationships can be used to define detailed relationships between components within a single EPG and to multiple other EPGs. This is shown in Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 21

16 Figure 23. Modeling Complex Applications Using Contracts Figure 23 shows that multiple application tiers may exist within a single EPG, and relationships are defined between those tiers as well as tiers residing in external EPGs. This allows complex relationships to be defined where certain constructs are consumed by other constructs that might reside within various EPGs. Functionality is provided by the Cisco ACI policy model to define relationships based on these components, which can be thought of as services, functions, applications, or subapplications residing in the same container. Figure 23 also depicts the ability to provide intra-epg policy, which is policy applied within a given EPG. This functionality will be supported in future releases without the requirement to change the model deployed today. As shown in the diagram, an EPG can consume its own resources as defined by the contract. In the diagram both NFS and database exist within an EPG that has requirements to consume those relationships. The policy is depicted by the arrows looping back to the application policy construct. Although contracts provide the means to support more complex application models, they do not dictate additional complexity. As stated, for simple application relationships, simple contracts can be used. For complex application relationships, the contract provides a means for building those relationships and reusing them where required. Contracts break down into subcomponents: Subjects: Group of filters that apply to a specific app or service Filters, which are used to classify traffic Actions such as permit, deny, mark, and so on to perform on matches to those filters Labels, which are used optionally to group objects such as subjects and EPGs for the purpose of further defining policy enforcement In a simple environment, the relationship between two EPGs would look similar to that in Figure 24. Here web and app EPGs are considered a single application construct and defined by a given set of filters. This will be a very common deployment scenario. Even in complex environments, this model will be preferred for many applications Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 21

17 Figure 24. Simple Policy Contract Relationships Many environments will require more complex relationships; some examples of this are: Environments using complex middleware systems Environments in which one set of servers provides functionality to multiple applications or groups (for example, a database farm providing data for several applications) PaaS, SOA, and Web 2.0 environments Environments where multiple services run within a single OS In these environments the Cisco ACI fabric provides a more robust set of optional features to model actual application deployments in a logical fashion. In both cases the Cisco APIC and fabric software are responsible for flattening the policy down and applying it for hardware enforcement. This relationship between the logical model, which is used to configure application relationships, and the concrete model used to implement them on the fabric simplifies design, deployment, and change within the fabric. An example of this would be an SQL database farm providing database services to multiple development teams within an organization: for instance, a red team, blue team, and green team each using separate database constructs supplied by the same farm. In this instance, a separate policy might be required for each team s access to the database farm. Figure 25 depicts this relationship Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 21

18 Figure 25. Single Database Farm Serving Three Separate Groups Requiring Separate Policy Controls The simple models discussed previously do not adequately cover this more complex relationship between EPGs. In these instances, we need the ability to separate policy for the three separate database instances within the SQL- DB EPG, which can be thought of as subapplications and are referred to within ACI as subjects. The Cisco ACI fabric provides multiple ways to model this application behavior depending on user preference and application complexity. The first way in which to model this behavior is using three contracts, one for each team. Remember that an EPG can inherit more than one contract and will receive the superset of rules defined there. In Figure 26 each app team s EPG connects to the SQL-DB EPG using its own specific contract. Figure 26. Utilizing Three Contracts to Define Separate Consumer Relationships 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 21

19 As shown, the SQL-DB EPG inherits the superset of policies from three separate contracts. Each application team s EPG then connects to the appropriate contract. The contract itself designates the policy, while the relationship defined by the arrows denotes where policy will be applied or who is providing/consuming which service. In this example the Red-App EPG will consume SQL-DB services with the QoS, ACL, marking, redirect, and so on behavior defined within the Red-Team APC. The same will be true for the blue and green teams.bbb In many instances, there will be groups of contracts that get applied together quite frequently. For example, if multiple DB farms are created that all require access by the three teams in our example or development, test, and production farms are used. In these cases, a bundle can be used to logically group the contracts. Bundles are optional; a bundle can be thought of as a container for one or more contracts for the purpose of ease of use. The use of bundles is depicted in Figure 27. Figure 27. Using Bundles to Group Contracts In Figure 27 it is very important to note the attachment points of the arrows showing relationship. Remember that policy is determined by what and where within the fabric. In this example we want SQL-DB EPG to provide all contracts within the contract bundle, so we attach the bundle itself to the EPG. For each of the three application teams, we only want access defined by its specific contract, so we attach each team to consume the corresponding contract itself within the bundle. This same relationship can optionally be modeled in another way using labels. Labels provide another grouping function for use within application policy definition. In most environments labels will not be required, but they are available for deployments with advanced application models and teams who are familiar with the concept. Using labels, a single contract can be used to represent multiple services or components of applications provided by a given EPG. In this case the labels represent the DB EPG providing database services to three separate teams. By labeling the subjects and the EPGs using them, separate policy can be applied within a given contract even if the traffic types or other classifiers are identical. Figure 28 shows this relationship Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 21

20 Figure 28. Using Labels to Group Objects within Policy Model In Figure 28 the SQL-DB EPG provides services using a single contract called SQ-DB, which defines the database services it provides to three different teams. Each of the three teams EPGs that will consume these services are then attached to the same traffic. By using labels on the subjects and the EPGs themselves, specific separate rules are defined for each team. The rules within the contract that matches the label will be the only ones applied for each EPG. This holds true even if the classification within the construct is the same: for example, the same Layer 4 ports and so on. Labels provide a very powerful classification tool that allows objects to be grouped together for the purpose of policy enforcement. This also allows applications to be moved quickly through various development lifecycles. For example, if the red label service Red-App represented a development environment that needed to be promoted to test represented by the blue label, the only required change would be to the label assigned to that EPG. Summary The Cisco ACI policy model is designed top down using a promise theory model to control a scalable architecture of defined network and service objects. This model provides robust repeatable controls, multitenancy, and minimal requirements for detailed knowledge by the control system known as the Cisco APIC. The model is designed to scale beyond current needs to the needs of private clouds, public clouds, and software-defined data centers. The policy enforcement model within the fabric is built from the ground up in an application-centric object model. This provides a logical model for laying out applications, which will then be applied to the fabric by the Cisco APIC. This helps to bridge the gaps in communication between application requirements and the network constructs that enforce them. The Cisco APIC model is designed for rapid provisioning of applications on the network that can be tied to robust policy enforcement while maintaining a workload anywhere approach Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 21

21 Additional References For additional references: Printed in USA C / Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 21

Principles of Application Centric Infrastructure

Principles of Application Centric Infrastructure White Paper Principles of Application Centric Infrastructure What You Will Learn One of the main innovations in application centric infrastructure (ACI) is the introduction of a highly abstracted interface

More information

Cisco Application Centric Infrastructure and Microsoft SCVMM and Azure Pack

Cisco Application Centric Infrastructure and Microsoft SCVMM and Azure Pack White Paper Cisco Application Centric Infrastructure and Microsoft SCVMM and Azure Pack Introduction Cisco Application Centric Infrastructure (ACI) is a next-generation data center fabric infrastructure

More information

Cisco Application Centric Infrastructure (ACI) - Endpoint Groups (EPG) Usage and Design

Cisco Application Centric Infrastructure (ACI) - Endpoint Groups (EPG) Usage and Design White Paper Cisco Application Centric Infrastructure (ACI) - Endpoint Groups (EPG) Usage and Design Emerging IT technologies have brought about a shift from IT as a cost center to IT as a business driver.

More information

Cisco HyperFlex Systems

Cisco HyperFlex Systems White Paper Cisco HyperFlex Systems Install and Manage Cisco HyperFlex Systems in a Cisco ACI Environment Original Update: January 2017 Updated: March 2018 Note: This document contains material and data

More information

ACI Terminology. This chapter contains the following sections: ACI Terminology, on page 1. Cisco ACI Term. (Approximation)

ACI Terminology. This chapter contains the following sections: ACI Terminology, on page 1. Cisco ACI Term. (Approximation) This chapter contains the following sections:, on page 1 Alias API Inspector App Center Alias A changeable name for a given object. While the name of an object, once created, cannot be changed, the Alias

More information

Service Graph Design with Cisco Application Centric Infrastructure

Service Graph Design with Cisco Application Centric Infrastructure White Paper Service Graph Design with Cisco Application Centric Infrastructure 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 101 Contents Introduction...

More information

Working with Contracts

Working with Contracts Contracts, page 1 Filters, page 9 Taboo Contracts, page 12 Inter-Tenant Contracts, page 15 Contracts Contracts provide a way for the Cisco Application Centric Infrastructure (ACI) administrator to control

More information

Cisco ACI Terminology ACI Terminology 2

Cisco ACI Terminology ACI Terminology 2 inology ACI Terminology 2 Revised: May 24, 2018, ACI Terminology Cisco ACI Term Alias API Inspector App Center Application Policy Infrastructure Controller (APIC) Application Profile Atomic Counters Alias

More information

VXLAN Overview: Cisco Nexus 9000 Series Switches

VXLAN Overview: Cisco Nexus 9000 Series Switches White Paper VXLAN Overview: Cisco Nexus 9000 Series Switches What You Will Learn Traditional network segmentation has been provided by VLANs that are standardized under the IEEE 802.1Q group. VLANs provide

More information

Deploy Microsoft SQL Server 2014 on a Cisco Application Centric Infrastructure Policy Framework

Deploy Microsoft SQL Server 2014 on a Cisco Application Centric Infrastructure Policy Framework White Paper Deploy Microsoft SQL Server 2014 on a Cisco Application Centric Infrastructure Policy Framework August 2015 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.

More information

Virtual Machine Manager Domains

Virtual Machine Manager Domains This chapter contains the following sections: Cisco ACI VM Networking Support for Virtual Machine Managers, page 1 VMM Domain Policy Model, page 3 Virtual Machine Manager Domain Main Components, page 3,

More information

Use Case: Three-Tier Application with Transit Topology

Use Case: Three-Tier Application with Transit Topology Use Case: Three-Tier Application with Transit Topology About Deploying a Three-Tier Application with Transit Topology, on page 1 Deploying a Three-Tier Application, on page 3 Transit Routing with OSPF

More information

Layer 3 IP Multicast Architecture and Design in Cisco ACI Fabric

Layer 3 IP Multicast Architecture and Design in Cisco ACI Fabric White Paper Layer 3 IP Multicast Architecture and Design in Cisco ACI Fabric What You Will Learn Many enterprise data center applications require IP multicast support and rely on multicast packet delivery

More information

Routing Design. Transit Routing. About Transit Routing

Routing Design. Transit Routing. About Transit Routing Transit Routing, page 1 L3Out Ingress Policy Enforcement, page 16 L3Out MTU Considerations, page 20 Shared L3Outs, page 22 L3Out Router IDs, page 27 Multiple External Connectivity, page 30 Transit Routing

More information

Cisco CloudCenter Solution with Cisco ACI: Common Use Cases

Cisco CloudCenter Solution with Cisco ACI: Common Use Cases Cisco CloudCenter Solution with Cisco ACI: Common Use Cases Cisco ACI increases network security, automates communication policies based on business-relevant application requirements, and decreases developer

More information

Cisco ACI Multi-Site Fundamentals Guide

Cisco ACI Multi-Site Fundamentals Guide First Published: 2017-08-10 Last Modified: 2017-10-09 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387)

More information

Network Programmability with Cisco Application Centric Infrastructure

Network Programmability with Cisco Application Centric Infrastructure White Paper Network Programmability with Cisco Application Centric Infrastructure What You Will Learn This document examines the programmability support on Cisco Application Centric Infrastructure (ACI).

More information

Cisco ACI vcenter Plugin

Cisco ACI vcenter Plugin This chapter contains the following sections: About Cisco ACI with VMware vsphere Web Client, page 1 Getting Started with, page 2 Features and Limitations, page 7 GUI, page 12 Performing ACI Object Configurations,

More information

Layer 4 to Layer 7 Design

Layer 4 to Layer 7 Design Service Graphs and Layer 4 to Layer 7 Services Integration, page 1 Firewall Service Graphs, page 5 Service Node Failover, page 10 Service Graphs with Multiple Consumers and Providers, page 12 Reusing a

More information

Modeling an Application with Cisco ACI Multi-Site Policy Manager

Modeling an Application with Cisco ACI Multi-Site Policy Manager Modeling an Application with Cisco ACI Multi-Site Policy Manager Introduction Cisco Application Centric Infrastructure (Cisco ACI ) Multi-Site is the policy manager component used to define intersite policies

More information

ACI Transit Routing, Route Peering, and EIGRP Support

ACI Transit Routing, Route Peering, and EIGRP Support ACI Transit Routing, Route Peering, and EIGRP Support ACI Transit Routing This chapter contains the following sections: ACI Transit Routing, on page 1 Transit Routing Use Cases, on page 1 ACI Fabric Route

More information

Multi-Site Use Cases. Cisco ACI Multi-Site Service Integration. Supported Use Cases. East-West Intra-VRF/Non-Shared Service

Multi-Site Use Cases. Cisco ACI Multi-Site Service Integration. Supported Use Cases. East-West Intra-VRF/Non-Shared Service Cisco ACI Multi-Site Service Integration, on page 1 Cisco ACI Multi-Site Back-to-Back Spine Connectivity Across Sites Without IPN, on page 8 Bridge Domain with Layer 2 Broadcast Extension, on page 9 Bridge

More information

DevNet Technical Breakout: Introduction to ACI Programming and APIs.

DevNet Technical Breakout: Introduction to ACI Programming and APIs. DevNet Technical Breakout: Introduction to ACI Programming and APIs. Michael Cohen Agenda Introduction to ACI ACI Policy ACI APIs REST API Python API L4-7 Scripting Opflex 3 Application Centric Infrastructure

More information

Cisco ACI App Center. One Platform, Many Applications. Overview

Cisco ACI App Center. One Platform, Many Applications. Overview White Paper Cisco ACI App Center One Platform, Many Applications Overview Cisco Application Centric Infrastructure (Cisco ACI ) is a comprehensive software-defined networking (SDN) solution designed from

More information

Intuit Application Centric ACI Deployment Case Study

Intuit Application Centric ACI Deployment Case Study Intuit Application Centric ACI Deployment Case Study Joon Cho, Principal Network Engineer, Intuit Lawrence Zhu, Solutions Architect, Cisco Agenda Introduction Architecture / Principle Design Rollout Key

More information

Layer 4 to Layer 7 Service Insertion, page 1

Layer 4 to Layer 7 Service Insertion, page 1 This chapter contains the following sections:, page 1 Layer 4 to Layer 7 Policy Model, page 2 About Service Graphs, page 2 About Policy-Based Redirect, page 5 Automated Service Insertion, page 12 About

More information

Intra-EPG Isolation Enforcement and Cisco ACI

Intra-EPG Isolation Enforcement and Cisco ACI This chapter contains the following sections: Intra-EPG Isolation for VMware VDS or Microsoft vswitch, on page 1 Intra-EPG Isolation Enforcement for Cisco AVS, on page 6 Intra-EPG Isolation Enforcement

More information

Cisco ACI Virtual Machine Networking

Cisco ACI Virtual Machine Networking This chapter contains the following sections: Cisco ACI VM Networking Supports Multiple Vendors' Virtual Machine Managers, page 1 Virtual Machine Manager Domain Main Components, page 2 Virtual Machine

More information

Cisco ACI Virtual Machine Networking

Cisco ACI Virtual Machine Networking This chapter contains the following sections: Cisco ACI VM Networking Supports Multiple Vendors' Virtual Machine Managers, page 1 Virtual Machine Manager Domain Main Components, page 2 Virtual Machine

More information

Service Insertion with ACI using F5 iworkflow

Service Insertion with ACI using F5 iworkflow Service Insertion with ACI using F5 iworkflow Gert Wolfis F5 EMEA Cloud SE October 2016 Agenda F5 and Cisco ACI Joint Solution Cisco ACI L4 L7 Service Insertion Overview F5 and Cisco ACI Integration Models

More information

Cisco ACI Virtual Machine Networking

Cisco ACI Virtual Machine Networking This chapter contains the following sections: Cisco ACI VM Networking Supports Multiple Vendors' Virtual Machine Managers, page 1 Virtual Machine Manager Domain Main Components, page 2 Virtual Machine

More information

Virtual Security Gateway Overview

Virtual Security Gateway Overview This chapter contains the following sections: Information About the Cisco Virtual Security Gateway, page 1 Cisco Virtual Security Gateway Configuration for the Network, page 10 Feature History for Overview,

More information

Segmentation. Threat Defense. Visibility

Segmentation. Threat Defense. Visibility Segmentation Threat Defense Visibility Establish boundaries: network, compute, virtual Enforce policy by functions, devices, organizations, compliance Control and prevent unauthorized access to networks,

More information

Cisco ACI Multi-Pod/Multi-Site Deployment Options Max Ardica Principal Engineer BRKACI-2003

Cisco ACI Multi-Pod/Multi-Site Deployment Options Max Ardica Principal Engineer BRKACI-2003 Cisco ACI Multi-Pod/Multi-Site Deployment Options Max Ardica Principal Engineer BRKACI-2003 Agenda ACI Introduction and Multi-Fabric Use Cases ACI Multi-Fabric Design Options ACI Stretched Fabric Overview

More information

Intra-EPG Isolation Enforcement and Cisco ACI

Intra-EPG Isolation Enforcement and Cisco ACI This chapter contains the following sections: Intra-EPG Isolation for VMware vds, page 1 Intra-EPG Isolation Enforcement for Cisco AVS, page 5 Intra-EPG Isolation for VMware vds Intra-EPG Isolation is

More information

Forwarding Within the ACI Fabric

Forwarding Within the ACI Fabric This chapter contains the following sections: About, page 1 ACI Fabric Optimizes Modern Data Center Traffic Flows, page 2 VXLAN in ACI, page 3 Layer 3 VNIDs Facilitate Transporting Inter-subnet Tenant

More information

Virtualization Design

Virtualization Design VMM Integration with UCS-B, on page 1 VMM Integration with AVS or VDS, on page 3 VMM Domain Resolution Immediacy, on page 6 OpenStack and Cisco ACI, on page 8 VMM Integration with UCS-B About VMM Integration

More information

Verified Scalability Guide for Cisco APIC, Release 3.0(1k) and Cisco Nexus 9000 Series ACI-Mode Switches, Release 13.0(1k)

Verified Scalability Guide for Cisco APIC, Release 3.0(1k) and Cisco Nexus 9000 Series ACI-Mode Switches, Release 13.0(1k) Verified Scalability Guide for Cisco APIC, Release 3.0(1k) and Cisco Nexus 9000 Series ACI-Mode Switches, Release 13.0(1k) Overview 2 General Scalability Limits 2 Fabric Topology, SPAN, Tenants, Contexts

More information

Cisco UCS Director Tech Module Cisco Application Centric Infrastructure (ACI)

Cisco UCS Director Tech Module Cisco Application Centric Infrastructure (ACI) Cisco UCS Director Tech Module Cisco Application Centric Infrastructure (ACI) Version: 1.0 September 2016 1 Agenda Overview & Architecture Hardware & Software Compatibility Licensing Orchestration Capabilities

More information

ACI Fabric Endpoint Learning

ACI Fabric Endpoint Learning White Paper ACI Fabric Endpoint Learning 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 45 Contents Introduction... 3 Goals of this document...

More information

Configuring APIC Accounts

Configuring APIC Accounts This chapter contains the following sections: Adding an APIC Account, page 1 Viewing APIC Reports, page 3 Assigning an APIC account to a Pod, page 15 Handling APIC Failover, page 15 Adding an APIC Account

More information

Policy Driven Data Centre with ACI

Policy Driven Data Centre with ACI Policy Driven Data Centre with ACI Chris Gascoigne Technical Solutions Architect #clmel Agenda Introduction What is policy Network policy Application policy Conclusion Introduction Traditional Data Centre

More information

Verified Scalability Guide for Cisco APIC, Release 3.0(1k) and Cisco Nexus 9000 Series ACI-Mode Switches, Release 13.0(1k)

Verified Scalability Guide for Cisco APIC, Release 3.0(1k) and Cisco Nexus 9000 Series ACI-Mode Switches, Release 13.0(1k) Verified Scalability Guide for Cisco APIC, Release 3.0(1k) and Cisco Nexus 9000 Series ACI-Mode Switches, Release 13.0(1k) Overview 2 General Scalability Limits 2 Fabric Topology, SPAN, Tenants, Contexts

More information

OpFlex: An Open Policy Protocol

OpFlex: An Open Policy Protocol White Paper OpFlex: An Open Policy Protocol Data Center Challenges As data center environments become increasingly dynamic, networks are increasingly asked to provide agility and flexibility without compromising

More information

Cisco ACI vpod. One intent: Any workload, Any location, Any cloud. Introduction

Cisco ACI vpod. One intent: Any workload, Any location, Any cloud. Introduction Cisco ACI vpod One intent: Any workload, Any location, Any cloud Organizations are increasingly adopting hybrid data center models to meet their infrastructure demands, to get flexibility and to optimize

More information

Integrating the Cisco ASA with Cisco Nexus 9000 Series Switches and the Cisco Application Centric Infrastructure

Integrating the Cisco ASA with Cisco Nexus 9000 Series Switches and the Cisco Application Centric Infrastructure Solution Guide Integrating the Cisco ASA with Cisco Nexus 9000 Series Switches and the Cisco Application Centric Infrastructure Data Center Design Opportunities Modern designs for the highly secure data

More information

Exam Questions

Exam Questions Exam Questions 300-170 DCVAI Implementing Cisco Data Center Virtualization and Automation (DCVAI) https://www.2passeasy.com/dumps/300-170/ 1. Which management interface is selected by the Cisco APIC by

More information

Cisco ACI Multi-Pod and Service Node Integration

Cisco ACI Multi-Pod and Service Node Integration White Paper Cisco ACI Multi-Pod and Service Node Integration 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 68 Contents Introduction... 3 Prerequisites...

More information

Building NFV Solutions with OpenStack and Cisco ACI

Building NFV Solutions with OpenStack and Cisco ACI Building NFV Solutions with OpenStack and Cisco ACI Domenico Dastoli @domdastoli INSBU Technical Marketing Engineer Iftikhar Rathore - INSBU Technical Marketing Engineer Agenda Brief Introduction to Cisco

More information

Cisco SDN 解决方案 ACI 的基本概念

Cisco SDN 解决方案 ACI 的基本概念 Cisco SDN 解决方案 ACI 的基本概念 Presented by: Shangxin Du(@shdu)-Solution Support Engineer, Cisco TAC Aug 26 th, 2015 2013 Cisco and/or its affiliates. All rights reserved. 1 Type Consumption Delivery Big data,

More information

ACI Multi-Site Architecture and Deployment. Max Ardica Principal Engineer - INSBU

ACI Multi-Site Architecture and Deployment. Max Ardica Principal Engineer - INSBU ACI Multi-Site Architecture and Deployment Max Ardica Principal Engineer - INSBU Agenda ACI Network and Policy Domain Evolution ACI Multi-Site Deep Dive Overview and Use Cases Introducing ACI Multi-Site

More information

Cisco ACI Virtual Machine Networking

Cisco ACI Virtual Machine Networking This chapter contains the following sections: Cisco ACI VM Networking Supports Multiple Vendors' Virtual Machine Managers, page 1 Virtual Machine Manager Domain Main Components, page 2 Virtual Machine

More information

Exam Questions Demo Cisco. Exam Questions

Exam Questions Demo   Cisco. Exam Questions Cisco Exam Questions 300-170 DCVAI Implementing Cisco Data Center Virtualization and Automation (DCVAI) Version:Demo 1. Which management interface is selected by the Cisco APIC by default if an in band

More information

Automate Application Deployment with F5 Local Traffic Manager and Cisco Application Centric Infrastructure

Automate Application Deployment with F5 Local Traffic Manager and Cisco Application Centric Infrastructure Automate Application Deployment with F5 Local Traffic Manager and Cisco Application Centric Infrastructure White Paper 2016 Cisco F5 Networks. All rights reserved. Page 1 Contents What You Will Learn...

More information

Design Guide for Cisco ACI with Avi Vantage

Design Guide for Cisco ACI with Avi Vantage Page 1 of 23 Design Guide for Cisco ACI with Avi Vantage view online Overview Cisco ACI Cisco Application Centric Infrastructure (ACI) is a software defined networking solution offered by Cisco for data

More information

Configuring Cisco Nexus 9000 Series Switches in ACI Mode (DCAC9K) v3.0

Configuring Cisco Nexus 9000 Series Switches in ACI Mode (DCAC9K) v3.0 Configuring Cisco Nexus 9000 Series Switches in ACI Mode (DCAC9K) v3.0 What you ll learn in this course The Configuring Cisco Nexus 9000 Series Switches in ACI Mode (DCAC9K) v3.0 course is designed for

More information

Cisco Application Centric Infrastructure

Cisco Application Centric Infrastructure Data Sheet Cisco Application Centric Infrastructure What s Inside At a glance: Cisco ACI solution Main benefits Cisco ACI building blocks Main features Fabric Management and Automation Network Security

More information

Configuring Policy-Based Redirect

Configuring Policy-Based Redirect About Policy-Based Redirect, on page 1 About Multi-Node Policy-Based Redirect, on page 3 About Symmetric Policy-Based Redirect, on page 3 Policy Based Redirect and Hashing Algorithms, on page 4 Policy-Based

More information

Question No: 3 Which configuration is needed to extend the EPG out of the Cisco ACI fabric?

Question No: 3 Which configuration is needed to extend the EPG out of the Cisco ACI fabric? Volume: 60 Questions Question No: 1 You discover that a VLAN is not enabled on a leaf port even though on EPG is provisioned. Which cause of the issue is most likely true? A. Cisco Discovery protocol is

More information

Networking Domains. Physical domain profiles (physdomp) are typically used for bare metal server attachment and management access.

Networking Domains. Physical domain profiles (physdomp) are typically used for bare metal server attachment and management access. This chapter contains the following sections:, on page 1 Bridge Domains, on page 2 VMM Domains, on page 2 Configuring Physical Domains, on page 4 A fabric administrator creates domain policies that configure

More information

SharkFest 16. Cisco ACI and Wireshark. Karsten Hecker Senior Technical Instructor Fast Lane Germany. Getting Back Our Data

SharkFest 16. Cisco ACI and Wireshark. Karsten Hecker Senior Technical Instructor Fast Lane Germany. Getting Back Our Data SharkFest 16 Cisco ACI and Wireshark Getting Back Our Data Karsten Hecker Senior Technical Instructor Fast Lane Germany Current Challenges for SPAN Current Challenges for SPAN connect through the CLI manually

More information

Cisco ACI and Cisco AVS

Cisco ACI and Cisco AVS This chapter includes the following sections: Cisco AVS Overview, page 1 Installing the Cisco AVS, page 5 Key Post-Installation Configuration Tasks for the Cisco AVS, page 14 Distributed Firewall, page

More information

Quick Start Guide (SDN)

Quick Start Guide (SDN) NetBrain Integrated Edition 7.1 Quick Start Guide (SDN) Version 7.1 Last Updated 2018-07-24 Copyright 2004-2018 NetBrain Technologies, Inc. All rights reserved. Contents 1. Discovering and Visualizing

More information

Cisco UCS Director and ACI Advanced Deployment Lab

Cisco UCS Director and ACI Advanced Deployment Lab Cisco UCS Director and ACI Advanced Deployment Lab Michael Zimmerman, TME Vishal Mehta, TME Agenda Introduction Cisco UCS Director ACI Integration and Key Concepts Cisco UCS Director Application Container

More information

Routing Implementation

Routing Implementation L3Out Subnets, page 1 L3Out Subnets About Defining L3Out Subnets L3Outs are the Cisco Application Centric Infrastructure (ACI) objects used to provide external connectivity in external Layer 3 networks.

More information

F5 BIG-IP Local Traffic Manager Service Insertion with Cisco Application Centric Infrastructure

F5 BIG-IP Local Traffic Manager Service Insertion with Cisco Application Centric Infrastructure F5 BIG-IP Local Traffic Manager Service Insertion with Cisco Application Centric Infrastructure Deployment Guide December 2015 2015 Cisco F5. All rights reserved. Page 1 Contents Introduction... 4 Preface...

More information

Cisco Nexus Data Broker

Cisco Nexus Data Broker Data Sheet Cisco Nexus Data Broker Product Overview You used to monitor traffic mainly to manage network operations. Today, when you monitor traffic you can find out instantly what is happening throughout

More information

STRATEGIC WHITE PAPER. Securing cloud environments with Nuage Networks VSP: Policy-based security automation and microsegmentation overview

STRATEGIC WHITE PAPER. Securing cloud environments with Nuage Networks VSP: Policy-based security automation and microsegmentation overview STRATEGIC WHITE PAPER Securing cloud environments with Nuage Networks VSP: Policy-based security automation and microsegmentation overview Abstract Cloud architectures rely on Software-Defined Networking

More information

Configuring Layer 4 to Layer 7 Resource Pools

Configuring Layer 4 to Layer 7 Resource Pools Configuring Layer 4 to Layer 7 Resource Pools About Layer 4 to Layer 7 Resource Pools, page 1 About External IP Address Pools, page 2 About External Layer 3 Routed Domains and the Associated VLAN Pools,

More information

Schema Management. Schema Management

Schema Management. Schema Management , page 1 Creating a Schema Template, page 2 Configuring an Application Profile, page 2 Configuring a Contract, page 3 Configuring a Bridge Domain, page 4 Configuring a VRF for the Tenant, page 4 Configuring

More information

Cisco ACI Simulator Release Notes, Release 1.1(1j)

Cisco ACI Simulator Release Notes, Release 1.1(1j) Cisco ACI Simulator Release Notes, This document provides the compatibility information, usage guidelines, and the scale values that were validated in testing this Cisco ACI Simulator release. Use this

More information

Cisco ACI Multi-Site, Release 1.1(1), Release Notes

Cisco ACI Multi-Site, Release 1.1(1), Release Notes Cisco ACI Multi-Site, Release 1.1(1), Release Notes This document describes the features, caveats, and limitations for the Cisco Application Centric Infrastructure Multi-Site software. The Cisco Application

More information

Microsegmentation with Cisco ACI

Microsegmentation with Cisco ACI This chapter contains the following sections:, page 1 Microsegmentation with the Cisco Application Centric Infrastructure (ACI) provides the ability to automatically assign endpoints to logical security

More information

Configuring Policy-Based Redirect

Configuring Policy-Based Redirect About Policy-Based Redirect, page 1 About Symmetric Policy-Based Redirect, page 8 Using the GUI, page 8 Using the NX-OS-Style CLI, page 10 Verifying a Policy-Based Redirect Configuration Using the NX-OS-Style

More information

Integration of Hypervisors and L4-7 Services into an ACI Fabric. Azeem Suleman, Principal Engineer, Insieme Business Unit

Integration of Hypervisors and L4-7 Services into an ACI Fabric. Azeem Suleman, Principal Engineer, Insieme Business Unit Integration of Hypervisors and L4-7 Services into an ACI Fabric Azeem Suleman, Principal Engineer, Insieme Business Unit Agenda Introduction to ACI Review of ACI Policy Model Hypervisor Integration Layer

More information

New and Changed Information

New and Changed Information This chapter contains the following sections:, page 1 The following table provides an overview of the significant changes to this guide for this current release. The table does not provide an exhaustive

More information

Configuring Policy-Based Redirect

Configuring Policy-Based Redirect About Policy-Based Redirect, page 1 About Symmetric Policy-Based Redirect, page 8 Policy Based Redirect and Hashing Algorithms, page 8 Using the GUI, page 9 Using the NX-OS-Style CLI, page 10 Verifying

More information

Chapter 4. Fundamental Concepts and Models

Chapter 4. Fundamental Concepts and Models Chapter 4. Fundamental Concepts and Models 4.1 Roles and Boundaries 4.2 Cloud Characteristics 4.3 Cloud Delivery Models 4.4 Cloud Deployment Models The upcoming sections cover introductory topic areas

More information

Service Insertion with Cisco Application Centric Infrastructure

Service Insertion with Cisco Application Centric Infrastructure Guide Service Insertion with Cisco Application Centric Infrastructure August 2014 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 21 Contents

More information

2018 Cisco and/or its affiliates. All rights reserved.

2018 Cisco and/or its affiliates. All rights reserved. Beyond Data Center A Journey to self-driving Data Center with Analytics, Intelligent and Assurance Mohamad Imaduddin Systems Engineer Cisco Oct 2018 App is the new Business Developer is the new Customer

More information

Disclaimer This presentation may contain product features that are currently under development. This overview of new technology represents no commitme

Disclaimer This presentation may contain product features that are currently under development. This overview of new technology represents no commitme SAI2803BU The Road to Micro- Segmentation with VMware NSX #VMworld #SAI2803BU Disclaimer This presentation may contain product features that are currently under development. This overview of new technology

More information

Cisco ACI Simulator Release Notes, Release 2.2(3)

Cisco ACI Simulator Release Notes, Release 2.2(3) Cisco ACI Simulator Release Notes, Release 2.2(3) This document provides the compatibility information, usage guidelines, and the scale values that were validated in testing this Cisco ACI Simulator release.

More information

Quick Start Guide (SDN)

Quick Start Guide (SDN) NetBrain Integrated Edition 7.1 Quick Start Guide (SDN) Version 7.1a Last Updated 2018-09-03 Copyright 2004-2018 NetBrain Technologies, Inc. All rights reserved. Contents 1. Discovering and Visualizing

More information

Integrating NetScaler ADCs with Cisco ACI

Integrating NetScaler ADCs with Cisco ACI Docs.Citrix.com Integrating NetScaler ADCs with Cisco ACI http://docs.citrix.com/content/docs/en-us/netscaler/10-1/ns-solutions-con/cisco-aci-wrapper.html Jan. 28, 2011 citrix.com 1 Integrating NetScaler

More information

Table of Contents HOL-PRT-1305

Table of Contents HOL-PRT-1305 Table of Contents Lab Overview... 2 - Abstract... 3 Overview of Cisco Nexus 1000V series Enhanced-VXLAN... 5 vcloud Director Networking and Cisco Nexus 1000V... 7 Solution Architecture... 9 Verify Cisco

More information

Running RHV integrated with Cisco ACI. JuanLage Principal Engineer - Cisco May 2018

Running RHV integrated with Cisco ACI. JuanLage Principal Engineer - Cisco May 2018 Running RHV integrated with Cisco ACI JuanLage Principal Engineer - Cisco May 2018 Agenda Why we need SDN on the Data Center What problem are we solving? Introduction to Cisco Application Centric Infrastructure

More information

PSOACI Tetration Overview. Mike Herbert

PSOACI Tetration Overview. Mike Herbert Tetration Overview Mike Herbert Cisco Spark How Questions? Use Cisco Spark to communicate with the speaker after the session 1. Find this session in the Cisco Live Mobile App 2. Click Join the Discussion

More information

Cisco ACI Simulator Release Notes, Release 3.0(2)

Cisco ACI Simulator Release Notes, Release 3.0(2) Cisco ACI Simulator Release Notes, Release 3.0(2) This document provides the compatibility information, usage guidelines, and the scale values that were validated in testing this Cisco ACI Simulator release.

More information

Cisco ACI - Application Policy Enforcement Using APIC

Cisco ACI - Application Policy Enforcement Using APIC Cisco ACI - Application Policy Enforcement Using APIC Azeem Suleman Solutions Architect House Keeping Notes Tuesday April 15, 2014 Thank you for attending Cisco Connect Toronto 2014, here are a few housekeeping

More information

Basic User Tenant Configuration

Basic User Tenant Configuration This chapter contains the following sections: Tenants, page 1 Routing Within the Tenant, page 2 Creating Tenants, VRF, and Bridge Domains, page 10 Deploying an Application Policy, page 12 Statically Deploying

More information

Deploying enterprise applications on Dell Hybrid Cloud System for Microsoft Cloud Platform System Standard

Deploying enterprise applications on Dell Hybrid Cloud System for Microsoft Cloud Platform System Standard Deploying enterprise applications on Dell Hybrid Cloud System for Microsoft Cloud Platform System Standard Date 7-18-2016 Copyright This document is provided as-is. Information and views expressed in this

More information

lecture 18: network virtualization platform (NVP) 5590: software defined networking anduo wang, Temple University TTLMAN 401B, R 17:30-20:00

lecture 18: network virtualization platform (NVP) 5590: software defined networking anduo wang, Temple University TTLMAN 401B, R 17:30-20:00 lecture 18: network virtualization platform (NVP) 5590: software defined networking anduo wang, Temple University TTLMAN 401B, R 17:30-20:00 Network Virtualization in multi-tenant Datacenters Teemu Koponen.,

More information

Practical Applications of Cisco ACI Micro Segmentation

Practical Applications of Cisco ACI Micro Segmentation BRKACI-2301 Practical Applications of Cisco ACI Micro Segmentation @JuanLage, Principal Engineer INSBU Cisco Spark How Questions? Use Cisco Spark to communicate with the speaker after the session 1. Find

More information

Intra-EPG Isolation Enforcement and Cisco ACI

Intra-EPG Isolation Enforcement and Cisco ACI This chapter contains the following sections: Intra-EPG Isolation for VMware vds, page 1 Configuring Intra-EPG Isolation for VMware vds using the GUI, page 3 Configuring Intra-EPG Isolation for VMware

More information

Cisco Cloud Architecture with Microsoft Cloud Platform Peter Lackey Technical Solutions Architect PSOSPG-1002

Cisco Cloud Architecture with Microsoft Cloud Platform Peter Lackey Technical Solutions Architect PSOSPG-1002 Cisco Cloud Architecture with Microsoft Cloud Platform Peter Lackey Technical Solutions Architect PSOSPG-1002 Agenda Joint Cisco and Microsoft Integration Efforts Introduction to CCA-MCP What is a Pattern?

More information

Cisco Nexus 1000V InterCloud

Cisco Nexus 1000V InterCloud Deployment Guide Cisco Nexus 1000V InterCloud Deployment Guide (Draft) June 2013 2013 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 49 Contents

More information

SDN Security BRKSEC Alok Mittal Security Business Group, Cisco

SDN Security BRKSEC Alok Mittal Security Business Group, Cisco SDN Security Alok Mittal Security Business Group, Cisco Security at the Speed of the Network Automating and Accelerating Security Through SDN Countering threats is complex and difficult. Software Defined

More information

Health Scores. Understanding Health Scores

Health Scores. Understanding Health Scores Understanding, on page 1 Understanding Faults, on page 4 How Are Calculated, on page 5 Health Score Use Cases, on page 7 Understanding ACME's Operations team has been challenged on a regular basis to answer

More information

Migration from Classic DC Network to Application Centric Infrastructure

Migration from Classic DC Network to Application Centric Infrastructure Migration from Classic DC Network to Application Centric Infrastructure Kannan Ponnuswamy, Solution Architect, Cisco Advanced Services Acronyms IOS vpc VDC AAA VRF STP ISE FTP ToR UCS FEX OTV QoS BGP PIM

More information

DELL EMC VSCALE FABRIC

DELL EMC VSCALE FABRIC NETWORK DATA SHEET DELL EMC VSCALE FABRIC FIELD-PROVEN BENEFITS Increased utilization and ROI Create shared resource pools (compute, storage, and data protection) that connect to a common, automated network

More information