Cisco Application Policy Infrastructure Controller Data Center Policy Model
|
|
- Amos Reynolds
- 6 years ago
- Views:
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
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 informationCisco 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 informationCisco 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 informationCisco 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 informationACI 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 informationService 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 informationWorking 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 informationCisco 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 informationVXLAN 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 informationDeploy 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 informationVirtual 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 informationUse 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 informationLayer 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 informationRouting 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 informationCisco 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 informationCisco 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 informationNetwork 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 informationCisco 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 informationLayer 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 informationModeling 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 informationACI 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 informationMulti-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 informationDevNet 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 informationCisco 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 informationIntuit 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 informationLayer 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 informationIntra-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 informationCisco 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 informationCisco 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 informationService 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 informationCisco 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 informationVirtual 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 informationSegmentation. 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 informationCisco 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 informationIntra-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 informationForwarding 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 informationVirtualization 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 informationVerified 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 informationCisco 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 informationACI 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 informationConfiguring 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 informationPolicy 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 informationVerified 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 informationOpFlex: 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 informationCisco 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 informationIntegrating 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 informationExam 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 informationCisco 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 informationBuilding 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 informationCisco 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 informationACI 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 informationCisco 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 informationExam 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 informationAutomate 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 informationDesign 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 informationConfiguring 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 informationCisco 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 informationConfiguring 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 informationQuestion 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 informationNetworking 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 informationSharkFest 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 informationCisco 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 informationQuick 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 informationCisco 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 informationRouting 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 informationF5 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 informationCisco 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 informationSTRATEGIC 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 informationConfiguring 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 informationSchema 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 informationCisco 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 informationCisco 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 informationMicrosegmentation 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 informationConfiguring 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 informationIntegration 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 informationNew 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 informationConfiguring 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 informationChapter 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 informationService 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 information2018 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 informationDisclaimer 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 informationCisco 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 informationQuick 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 informationIntegrating 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 informationTable 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 informationRunning 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 informationPSOACI 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 informationCisco 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 informationCisco 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 informationBasic 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 informationDeploying 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 informationlecture 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 informationPractical 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 informationIntra-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 informationCisco 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 informationCisco 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 informationSDN 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 informationHealth 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 informationMigration 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 informationDELL 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