Skip to content

 Home

o Your O'Reilly
 Profile
 History
 Playlists
 Highlights
o Answers
o Explore
 All Topics
 Most Popular Titles
 Recommended
 Early Releases
 Shared Playlists
 Resource Centers
o Live Events
 All Events
 Architectural Katas
 AI & ML
 Data Sci & Eng
 Programming
 Infra & Ops
 Software Arch
o Interactive
 Scenarios
 Sandboxes
 Jupyter Notebooks
o Certifications
o Settings
o Support
o Newsletters
o Sign Out

Table of Contents for

 CCNP Data Center Application Centric Infrastructure 300-620 DCACI
Official Cert Guide

CLOSE
 CCNP Data Center Application
Centric Infrastructure 300-620 DCACI Official Cert Guideby Ammar
AhmadiPublished by Cisco Press, 2021
1. Cover Page (01:09 mins)
2. About This eBook (01:09 mins)
3. Title Page (01:09 mins)
4. Copyright Page (03:27 mins)
5. About the Author (01:09 mins)
6. About the Technical Reviewers (01:09 mins)
7. Dedication (01:09 mins)
8. Acknowledgments (01:09 mins)
9. Contents at a Glance (01:09 mins)
10. Reader Services (01:09 mins)
11. Contents (13:48 mins)
12. Icons Used in This Book (01:09 mins)
13. Command Syntax Conventions (01:09 mins)
14. Introduction (12:39 mins)
15. Figure Credit (01:09 mins)
16. Part I Introduction to Deployment (01:09 mins)
o  Chapter 1 The Big Picture: Why ACI? (32:12 mins)
o  Chapter 2 Understanding ACI Hardware and Topologies  (42:33 mins)
o  Chapter 3 Initializing an ACI Fabric (93:09 mins)
o  Chapter 4 Exploring ACI (59:48 mins)
17. Part II ACI Fundamentals (01:09 mins)
o  Chapter 5 Tenant Building Blocks (44:51 mins)
o  Chapter 6 Access Policies (55:12 mins)
o  Chapter 7 Implementing Access Policies (92:00 mins)
o  Chapter 8 Implementing Tenant Policies  (97:45 mins)
18. Part III External Connectivity (01:09 mins)
o  Chapter 9 L3Outs (125:21 mins)
o  Chapter 10 Extending Layer 2 Outside ACI  (60:57 mins)
19. Part IV Integrations (01:09 mins)
o  Chapter 11 Integrating ACI into vSphere Using VDS  (54:03 mins)
o  Chapter 12 Implementing Service Graphs  (69:00 mins)
20. Part V Management and Monitoring (01:09 mins)
o  Chapter 13 Implementing Management (35:39 mins)
o  Chapter 14 Monitoring ACI Using Syslog and SNMP  (51:45 mins)
o  Chapter 15 Implementing AAA and RBAC  (63:15 mins)
21. Part VI Operations (01:09 mins)
o  Chapter 16 ACI Anywhere (26:27 mins)
22. Part VII Final Preparation (01:09 mins)
o  Chapter 17 Final Preparation (10:21 mins)
23. Appendix A Answers to the “Do I Know This Already?” Questions  (27:36 mins)
24. Appendix B CCNP Data Center Application Centric Infrastructure DCACI 300-620
Exam Updates (02:18 mins)
25. Glossary (23:00 mins)
26. Index (69:00 mins)
27. Appendix C Memory Tables (32:12 mins)
28. Appendix D Memory Tables Answer Key (34:30 mins)
29. Appendix E Study Planner (04:36 mins)
30. Where are the companion content files? - Register  (01:09 mins)
31. Inside Front Cover (01:09 mins)
32. Inside Back Cover (01:09 mins)
33. Code Snippets (05:45 mins)
 Search in book...

 Toggle Font Controls

o
o
o
o
PREV Previous Chapter

Part II ACI Fundamentals

NEXT Next Chapter

Chapter 6 Access Policies

Chapter 5
Tenant Building Blocks

This chapter covers the following topics:

Understanding the Basic Objects in Tenants: This section describes the key

logical constructs in tenants, including bridge domains and EPGs.
Contract Security Enforcement Basics: This section details how ACI uses
contracts, subjects, filters, and filter entries to enforce whitelisting.
Objects Enabling Connectivity Outside the Fabric: This section describes
how L3Outs and external EPGs fit in the bigger picture of tenants.
Tenant Hierarchy Review: This section covers the relationships between
tenant objects.
This chapter covers the following exam topics:
 1.6 Implement ACI logical constructs
 1.6.a tenant
 1.6.b application profile
 1.6.c VRF
 1.6.d bridge domain (unicast routing, Layer 2 unknown
hardware proxy, ARP flooding)
 1.6.e endpoint groups (EPG)
 1.6.f contracts (filter, provider, consumer, reverse port filter,
VRF enforced)
Because ACI functions are based on objects, it is reasonable to expect that a
book introducing ACI as a multitenant solution would include detailed coverage
of the theory around objects that make up tenants. This chapter begins with an
overview of key tenant constructs that all ACI engineers need to know. It
provides a basic understanding of how contracts enforce security in ACI.
Because ACI needs to also enable communication with the outside world, this
chapter also discusses the role of tenant L3Outs and related objects.

“DO I KNOW THIS ALREADY?” QUIZ

The “Do I Know This Already?” quiz allows you to assess whether you should
read this entire chapter thoroughly or jump to the “Exam Preparation Tasks”
section. If you are in doubt about your answers to these questions or your own
assessment of your knowledge of the topics, read the entire chapter. Table 5-
1 lists the major headings in this chapter and their corresponding “Do I Know
This Already?” quiz questions. You can find the answers in Appendix A,
“Answers to the ‘Do I Know This Already?’ Questions.”
Table 5-1 “Do I Know This Already?” Section-to-Question Mapping
Foundation Topics Section

Understanding the Basic Objects in Tenants

Contract Security Enforcement Basics

Objects Enabling Connectivity Outside the Fabric

Tenant Hierarchy Review

Caution
 The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you
do not know the answer to a question or are only partially sure of the answer, you should
mark that question as wrong for purposes of the self-assessment. Giving yourself credit
for an answer you correctly guess skews your self-assessment results and might provide
you with a false sense of security
1. Which tenant does ACI use to push configurations to switches in-band?
1. Mgmt
2. User
3. Infra
4. Common
2. Which tenant allows deployment of a shared L3Out?
1. Mgmt
2. User
3. Infra
4. Common
3. Which of the following most accurately describes an EPG?
1. An EPG defines a broadcast domain in ACI.
2. An EPG is a logical grouping of IP-based endpoints that reside inside an
ACI fabric.
3. An EPG is the equivalent of a VLAN in ACI.
4. An EPG is a logical grouping of endpoints, IP-based or otherwise, that
have similar policy-handling requirements and are bound to a single
bridge domain.
4. Which of the following statements about application profiles is true?
1. EPGs tied to different bridge domains cannot be grouped into a single
application profile.
2. An application profile is typically a grouping of EPGs that together form
a multitiered application.
3. An application profile is bound to a VRF instance.
4. The function of application profiles is to differentiate between DMZ and
inside zones of a firewall.
5. Which of the following commands displays all routes in a VRF instance
called DCACI?
1. show ip route DCACI:CCNP
2. show route DCACI
3. show ip route
4. show ip route CCNP:DCACI
6. Which of the following defines the action that should be taken on interesting
traffic?
1. Filter
2. Filter entry
3. Subject
4. Contract
7. True or false: There is no way to isolate traffic between endpoints that reside
in the same EPG.
1. True
2. False
8. An administrator has defined constructs that match traffic based on
destination ports 80 and 443, allowing such traffic along with return traffic
through the ports. The contract is expected to be applied to communication
between a client EPG and a web EPG. How should the contract be applied to
the two EPGs to allow the clients to establish communication with the web
EPG?
1. In the consumer direction on both EPGs
2. In the provider direction on both EPGs
3. In the provider direction on the client EPG and in the consumer direction
on the web EPG
4. In the consumer direction on the client EPG and in the provider direction
on the web EPG
9. True or false: An external EPG represents endpoints outside ACI and behind
an L3Out.
1. True
2. False
10. True or false: Large numbers of filters can be created in any given tenant.
1. True
2. False

FOUNDATION TOPICS
UNDERSTANDING THE BASIC OBJECTS
IN TENANTS
ACI has multiple tenants enabled out of the box. There is little reason not to
deploy multiple user tenants to achieve fault isolation and tighter administrative
control. However, to fully leverage ACI multitenancy, you must first master the
tenant hierarchy.
In true multitenancy environments where roles are heavily delineated, tenant
policies are typically configured by a user who has been assigned either the
tenant-admin role or a role with similar privileges. (For more on implementation
of roles, see Chapter 15, “Implementing AAA and RBAC.”)

Tenants

An ACI tenant is a secure and exclusive virtual computing environment that

forms a unit of isolation from a policy perspective but does not represent a
private network.
If you investigate further into use cases for tenants in the real world, you will
find that tenants are often deployed in order to achieve these two technical
controls:
 Administrative separation: When a business acquires other
entities and needs to allow outside administrators access into its data
centers, tenants are often used as a unit of administrative separation. This
is accomplished through role-based access control (RBAC). Other
instances where administrative separation may be important are when
business units or application owners want to be involved in the process
of defining network and security policies for applications. In this case,
each relevant business unit can be provided its own tenants, or a tenant
can be defined and dedicated to a specific application. Another instance
in which administrative separation is vital is in service provider
environments, where customers sometimes have access and visibility into
the endpoints and systems they own.
 Configuration fault isolation: An application is a collection of
tightly integrated endpoints that need to communicate with one another
to achieve a particular business objective. Some applications have low
business relevance and some have high business relevance. The
networking, security, and QoS handling required for applications are
defined in tenants. A hospital, for example, will likely consider its
 electronic medical record system to be business critical, with very well-
defined dependencies, and may want any network or security policy
changes around such an environment to be bound by change control. In
such a case, it might make sense to place such an application and its
dependencies in its own tenant. The same hospital may see a host of
other applications as having very little business relevance and may
therefore lump such applications into another tenant. The idea here is that
configuration changes made in one tenant should have very limited or no
impact on endpoints and applications in other tenants.
Figure 5-1 shows how you can navigate to the Tenants menu in the APIC GUI
and execute the tenant creation wizard by clicking Add Tenant.

Figure 5-1 Navigating to the Tenants Menu and Clicking Add Tenant

In the Create Tenant wizard, you can enter the name of the desired tenant and
click Submit to create the tenant, as shown in Figure 5-2. Note in this figure that
one of the items you can create simultaneously while in the Create Tenant
wizard is a VRF instance (VRFs are discussed later in this chapter.)
Figure 5-2 Create Tenant Wizard
Note
This chapter does not cover all configuration items depicted in the figures. Chapters 7,
“Implementing Access Policies,” through 15 address additional configurations and
features that are within the scope of the Implementing Cisco Application Centric
Infrastructure DCACI 300-620.
Note
Tenants cannot be nested within each other.

Predefined Tenants in ACI

ACI comes preconfigured with three tenants:

 Infra: The infra tenant is for internal communication between ACI

switches and APICs in an ACI fabric. When APICs push policy to leaf
switches, they are communicating into the infra tenant. Likewise, when
leaf and spine switches communicate with one another, they do so in the
infra tenant. The infra tenant is the underlay that connects ACI switches
together and does not get exposed to the user space (user-created
tenants). In essence, the infra tenant has its own private network space
and bridge domains. Fabric discovery, image management, and DHCP
for fabric functions are all handled within this tenant. Note also that an
Application Virtual Switch (AVS) software switch can be considered an
 extension of an ACI fabric into virtualized infrastructure. When AVS is
deployed, it also communicates with other ACI components in the infra
tenant.
 Mgmt: APICs configure switches in a fabric via the infra tenant,
but it is likely that administrators at some point will want APIC GUI
access or CLI access to nodes within a fabric to validate that a policy has
been pushed or to troubleshoot issues. Administrator SSH access to ACI
switches and any contracts limiting communication with switch
management IP addresses are configured in the mgmt tenant. Both out-
of-band and in-band management options are configured in this tenant.
 Common: The common tenant is a special tenant for providing
common services to other tenants in an ACI fabric. The common tenant
is most beneficial for placement of services that are consumed by
multiple tenants. Such services typically include DNS, DHCP, and
Active Directory. The common tenant also allows the creation of shared
Layer 3 connections outside the fabric, shared bridge domains, and
shared VRF instances.
Note
This section refers to the infra tenant as the underlay in ACI. The term underlay can
technically be used to refer not just to the tenant itself but also to the protocols that
enable interswitch connectivity within the fabric. That said, user traffic typically resides
in either user-created tenants or the common tenant. Therefore, user tenants and the
common tenant can be considered the overlay in ACI.

VRF Instances

A virtual routing and forwarding (VRF) instance is a mechanism used to

partition a routing table into multiple routing tables for the purpose of enabling
Layer 3 segmentation over common hardware. In ACI, each tenant can contain
multiple VRF instances.
IP addresses within a VRF need to be unique, or traffic can be black-holed. IP
address overlap between different VRFs, on the other hand, is not an issue.
Where subnet overlap does exist within ACI VRFs, the overlapping
subnets cannot be leaked between the VRFs to allow communication.
VRF instances are sometimes also referred to as private networks, or contexts.
Figure 5-3 provides a view from within the newly created tenant DCACI. To
create a VRF instance, navigate to the tenant in which you intend to create the
VRF, open Networking, right-click on VRFs, and select Create VRF.
Figure 5-3 Navigating to the Create VRF Wizard
Figure 5-4 displays the Create VRF wizard, in which you enter the name of the
desired VRF and click Finish to create the VRF. Note in this figure that you can
create bridge domains simultaneously when creating a VRF. (Bridge domains
are covered later in this chapter.)

Figure 5-4 Create VRF Wizard

Example 5-1 illustrates that routing tables in ACI find meaning only in the
context of VRF instances. There is no concept of a default VRF in ACI. As you
can see, the command show ip route is invalid in ACI. A reference to a tenant
and VRF using the syntax show ip route vrf {tenant-name:vrf-name} is
required when verifying the routing table of user-created VRFs within ACI. The
list of VRFs that have been activated on a leaf and the references needed to pull
further output can be identified using the show vrf command.
Example 5-1 Routing Table Output in ACI

Click here to view code image

DC1-LEAF101# show ip route

Incorrect command "show ip route"

DC1-LEAF101# show vrf

VRF-Name VRF-I State Reason

black-hole 3 Up --

DCACI:Chapter5 6 Up --

management 2 Up --

overlay-1 4 Up --

DC1-LEAF101# show ip route vrf DCACI:Chapter5

IP Route Table for VRF "DCACI: Chapter5"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

10.233.52.0/24, ubest/mbest: 1/0, attached, direct, pervasive

*via 10.233.47.66%overlay-1, [1/0], 09w05d, static

10.233.52.1/32, ubest/mbest: 1/0, attached, pervasive

*via 10.233.52.1, vlan12, [0/0], 09w05d, local, local

Note that the subnet and IP addresses shown in Example 5-1 were not created as
a result of the VRF instance creation process demonstrated in Figure 5-
3 and Figure 5-4.

Bridge Domains (BDs)

Official ACI documentation describes a bridge domain (BD) as a Layer 2

forwarding construct that is somewhat analogous to a VLAN and has to be
associated with a VRF instance.
The official definition, presumably, explains why the term bridge has been used
in the name of this construct since a bridge domain is the true boundary of any
server-flooded traffic.
Although this definition is technically accurate and must be understood for the
purpose of the DCACI 300-620 exam, it is a great source of confusion for
newcomers to ACI. So, let’s first explore endpoint groups and application
profiles and then revisit bridge domains to get a better understanding of the role
these two constructs play in the greater picture of ACI.

Endpoint Groups (EPGs)

An endpoint group (EPG) is a grouping of physical or virtual network

endpoints that reside within a single bridge domain and have similar policy
requirements. Endpoints within an EPG may be directly or indirectly attached to
ACI leaf switches but communicate in some fashion over an ACI fabric. ACI
can classify both IP-based and non-IP-based endpoints into EPGs.
Some examples of endpoints that can be classified into EPGs include virtual
machines, physical servers, appliance ports, Kubernetes namespaces, and users
accessing ACI.

Application Profiles
An application profile is a container that allows EPGs to be grouped according
to their relationship with one another to simplify configuration and auditing of
relevant policies and to enable a level of policy reuse.
Many modern applications contain multiple components (tiers). For instance, an
e-commerce application could require one or more web servers, backend
database servers, storage, and access to outside resources that enable financial
transactions. In ACI deployments, especially if whitelisting is desired, each one
of these component types (for example, web servers) would be classified into a
separate EPG. An important benefit of organizing interrelated component EPGs
of a multitiered application into an application profile container is that the
allowed communication between these application tiers can then be easily
audited by exploring the resulting application profile topology. Figure 5-5
presents a sample application profile topology comprising a web tier and a
database tier rendered by ACI.

Figure 5-5 An Application Profile Topology

Another advantage of application profiles is that they allow application policy
requirements to be modeled to accommodate policy standardization and future
reuse. For example, let’s say an IT department finds itself spinning up new
instances of a very specific multitiered application very often. It understands the
communication protocols that should be allowed between various tiers of these
standardized deployments because it has already had to implement whitelisting
policies for a previous multitiered instance of this same application. By limiting
the scope of policies that have already been created to that of an application
profile, the IT department can apply the same policies to new instances of
this multitiered application without having the various instances of the
application communicating with one another. This requires that the new
instance of the application be placed in a new application profile. This type of
policy reuse can cut down on the time needed to deploy applications and
ensures that when policy changes are needed (for example, when a new port
needs to be opened between application tiers), they can be applied to all
instances at once.
Note
Scope-limiting policies and creating new application profiles for each application
instance is not the only way to take advantage of policy reuse for standardized
applications in ACI. In many cases with ACI, you can achieve desired business or
technical objectives in multiple ways.
EPGs can be organized into application profiles according to one of the
following:
 The application they provide, such as a DNS server, a LAMP
stack, or SAP
 The function they provide (such as infrastructure)
 Where they are in the structure of the data center (such as the
DMZ)
 Any organizing principle that a tenant administrator chooses to use

EPGs that are placed in an application profile do not need to be bound to the
same bridge domain. In addition, application profiles are not tied to VRF
instances.

The Pain of Designing Around Subnet Boundaries

In traditional data centers, security policy in particular is usually applied at
subnet boundaries. Access lists are rarely used to drop traffic flows within
traditional data centers, but when they are, they are almost always used for
isolated use cases that do not involve very granular control at the individual IP
address level.
For example, technical controls such as access lists and route maps may be used
in traditional data centers to prevent non-production server traffic from reaching
a production server block if production and non-production server blocks have
very well-defined subnets and no interdependencies. However, it is very
unlikely that an organization that uses traditional networking capabilities would
leverage its data center network to set up controls and define policy for limiting
communications to and from every single server.
Where application-level firewalling is needed for an endpoint or set of
endpoints within a traditionally built data center, careful engineering is applied
to ensure that traffic is pushed through a firewall. The common traditional
solution to a requirement like this may be to build out a new security zone on a
firewall and move the default gateway for the subnet in question onto the
firewall to guarantee that the firewall has control over traffic flowing into and
out of the subnet. This type of solution, shown in Figure 5-6, forces engineers to
think a lot about subnet boundaries when designing networks.

Figure 5-6 Security by Routing Traffic Through Firewalls

Sometimes engineers may decide to enforce security by leveraging a firewall in
transparent mode in conjunction with an isolation VLAN. This solution ensures
that certain critical endpoints are firewalled off from other endpoints within a
subnet and allows for limited policy control within a subnet boundary. Figure 5-
7 demonstrates how a transparent firewall attached to a traditional network can
be placed between endpoints within a subnet to segment the subnet into two
VLANs (VLAN 100 and 200 in this case) to enforce security policies between
the VLANs.

Figure 5-7 Security Through Transparent Bridging via Firewalls

There are several challenges associated with both of these security solutions
when implemented using traditional networking capabilities. First, if the servers
are already in production, dropping a firewall into the traffic path after the fact
almost always necessitates an outage of the servers that are firewalled off. This
is particularly true when segmenting the subnet in which the server resides.
Second, granular east–west traffic filtering using these methods is nearly
impossible. (For instance, what happens if a subnet needs to be subdivided into
10 sets of servers and security zones?) Finally, even with these methods, there is
very little that can be done to specifically direct only the desired traffic through
security devices. In other words, engineers may find that it requires a lot more
planning to design a solution that sends all traffic from certain servers to
firewalls if a required secondary objective were for traffic from these servers to
completely bypass said firewalls when the traffic is found to be destined toward
backup appliances.
The complexity of enforcing solutions to security challenges using traditional
data center networks underscores the basic point that subnet boundaries play an
important role in the average data center. Even though security policy has been
the main focus in this discussion, the reality is that the challenge and rigidity
involved in designing networks with subnet boundaries in mind also extend to
other aspects of policy enforcement.

BDs and EPGs in Practice

Unlike traditional networks, ACI breaks the shackles and endless limitations
imposed by subnet boundaries to eliminate the need for overengineered designs.
It does so by decoupling Layer 3 boundaries from security and forwarding
policies.
For the purpose of gaining a fuller picture, let’s redefine bridge domains and
EPGs based on their practical application.

As a construct that is directly associated with a VRF instance, a bridge domain

serves as the subnet boundary for any number of associated EPGs. One or more
subnets can be assigned to a bridge domain. General forwarding aspects of the
associated subnets—such as whether flooding and multicast are enabled or
whether the subnets should be advertised out of an ACI fabric or not—are
governed by the bridge domain.

Endpoints that live within a bridge domain subnet need to be associated with an
EPG to be able to forward traffic within ACI. An EPG serves as an endpoint
identity from a policy perspective. EPGs are the point of security policy
enforcement within ACI. Traffic flowing between EPGs can be selectively
filtered through the use of contracts. Policies not necessarily related to security,
such as QoS, can also be applied at the EPG level. If traffic from a set of
endpoints may need to be selectively punted to a firewall or any other stateful
services device, a policy-based redirect (PBR) operation can be applied to the
EPG to bypass the default forwarding rules. In a sense, therefore, EPG
boundaries also have a hand in the application of forwarding policies.
Figure 5-8 demonstrates how ACI decouples policy from forwarding by using
bridge domains as the subnet definition point and EPGs as the policy
application point.

Figure 5-8 Selective Policy Application at the EPG Boundary

Note
Endpoints within an EPG can reside in different subnets as long as all the subnets are
associated with the same bridge domain to which the EPG is associated.

Configuring Bridge Domains, Application Profiles, and

EPGs
Because EPGs need to be associated with bridge domains and application
profiles need to be created before EPGs, the ideal order of operation is to first
create bridge domains, then application profiles, and finally EPGs.
Figure 5-9 shows how to navigate to the Create Bridge Domain wizard. Within
the Tenants view, open Networking, right-click Bridge Domains, and select
Create Bridge Domain.

Figure 5-9 Navigating to the Create Bridge Domain Wizard

In the first page of the Create Bridge Domain wizard, which relates to general
aspects of the bridge domain, enter a name for the bridge domain and associate
the bridge domain to a VRF instance, as shown in Figure 5-10. Then click Next.
Figure 5-10 Create Bridge Domain Wizard, Page 1
Figure 5-11 shows the second page of the Create Bridge Domain wizard, where
you enter Layer 3 configurations for the bridge domain. Click the + sign in the
Subnets section to open the Create Subnet page.

Figure 5-11 Create Bridge Domain Wizard, Page 2

In the Create Subnet page, enter the default gateway IP address of the desired
subnet, using CIDR notion (see Figure 5-12). This gateway IP address will be
created in ACI when certain conditions are met. Click OK to return to page 2 of
the Create Bridge Domain wizard. Then click Next to move to the last page of
the Create Bridge Domain wizard. Note that you can assign multiple subnet IP
addresses to each bridge domain.

Figure 5-12 Creating a Subnet for the Bridge Domain

Figure 5-13 shows the final page of the Create Bridge Domain wizard, which
provides advanced bridge domain settings. Click Finish.
Figure 5-13 Create Bridge Domain Wizard, Page 3
After you create bridge domains, you can create application profiles. Figure 5-
14 shows how to navigate to a tenant, right-click Application Profile, and select
Create Application Profile.

Figure 5-14 Navigating to the Create Application Profile Wizard

In the Create Application Profile wizard, enter a name for the application profile
and click Submit, as shown in Figure 5-15.
Figure 5-15 Creating an Application Profile
Once an application profile has been created, you can create EPGs within the
application profile. Navigate to the Tenants view, right-click the desired
application profile under which EPGs should be created, and select Create
Application EPG to access the Create Application EPG wizard. As shown
in Figure 5-16, you enter a name for an EPG and click Finish.

Figure 5-16 Create Application EPG Wizard

Classifying Endpoints into EPGs
In the backend, EPGs and bridge domains each correlate to VXLAN IDs, which
are not supported on most server operating systems. ACI needs a mechanism to
classify or place endpoint traffic it receives on switch ports into the proper
EPGs. ACI most often classifies endpoints and associated traffic into EPGs
through the encapsulations that have been mapped to the leaf interfaces on
which traffic arrives.

VLAN IDs and VXLAN IDs are forms of encapsulation that ACI uses to
classify Ethernet traffic into EPGs.
Note
A uSeg EPG is a specific type of endpoint group that uses endpoint attributes as opposed
to encapsulations to classify endpoints. For instance, if you wanted to dynamically
classify all virtual machines that run a specific operating system (OS) into an EPG, you
could use uEPGs. Classifying endpoints into uSeg EPGs is particularly useful when
there is a need to leverage endpoint attributes defined outside ACI (for example,
VMware vCenter) to whitelist communication. Use of uSeg EPGs for whitelisting is
called microsegmentation.
Figure 5-17 provides a simple but realistic depiction of a tenant, a VRF
instance, bridge domains, EPGs, and subnets, and it shows how VLAN
encapsulations are used to classify endpoints into a given EPG. The
encapsulation configurations shown are commonly configured within tenants
and at the EPG level. In this case, the tenant administrator has decided to map
the EPG named DNS to port channel 1 on Leaf 101 using the VLAN 101
encapsulation. Likewise, the same encapsulation has been mapped to port 1
(Eth1/1) on Leaf 102 to classify server traffic in VLAN 101 into the DNS EPG.
Encapsulations can also be mapped to virtual port channels.
Figure 5-17 Mapping EPGs to Encapsulations
There is no hard requirement for an EPG to be mapped to a single encapsulation
across all leaf switches within an ACI fabric. However, it is common practice,
and most companies do it to promote standardization.
Note
If you do a cursory review of the ACI GUI, you might wonder why there is a subnet
definition section under the EPG view if bridge domains are the construct that defines
subnets. Although you can define a subnet under an EPG (and definition of subnets
under EPGs is required in some cases), it is still the switch virtual interface (SVI)
associated with the bridge domain and not the EPG that handles routing. Later chapters
expand on this simplistic explanation.

APIC CLI Configuration of Tenant Objects

The GUI-based configurations performed in this section can be completed using
the CLI commands depicted in Example 5-2.
As a review, the command tenant DCACI in Example 5-2 creates a tenant
named DCACI. Under the tenant, the ACI engineer creates a VRF instance
called Chapter5 by using the vrf context Chapter5 command.
The exit command that follows is required because a bridge domain is not a
VRF subtree but a tenant child object. The command bridge-domain BD-
CRTICAL-STUFF creates a bridge domain named BD-CRITICAL-STUFF
under the tenant, and vrf member Chapter5 associates the bridge domain with
the Chapter5 VRF. The command interface bridge-domain BD-CRITICAL-
STUFF is used to signal the intent to create one or more SVIs under the bridge
domain BD-CRITICAL-STUFF. The ip address subcommand creates an SVI
with the address 10.220.0.1/16 as the default gateway. Although the subnet has
been created as a secondary subnet, it could as well have been defined as the
primary IP address with the secondary keyword omitted from the command.
Example 5-2 CLI Equivalents for Configurations Performed in This Section

Click here to view code image

apic1# show run tenant DCACI

# Command: show running-config tenant DCACI

# Time: Sat Sep 21 21:12:14 2019

tenant DCACI

vrf context Chapter5

exit

bridge-domain BD-CRITICAL-STUFF

vrf member Chapter5

exit

application Critical-Application

exit

interface bridge-domain BD-CRITICAL-STUFF

ip address 10.220.0.1/16 secondary

exit

exit
CONTRACT SECURITY ENFORCEMENT
BASICS
ACI performs whitelisting out of the box. This means that, by default, ACI acts
as a firewall and drops all communication between EPGs unless security rules
(most commonly contracts) are put in place to allow communication.
ACI security policy enforcement generally involves the implementation of
contracts, subjects, and filters.

Contracts, Subjects, and Filters

In the ACI whitelisting model, all inter-EPG communication is blocked by
default unless explicitly permitted. Contracts, subjects, and filters complement
each other to specify the level of communication allowed to take place between
EPGs. These constructs can be described as follows:

 Filter: The job of a filter is to match interesting traffic flows. The

EtherType, the Layer 3 protocol type, and Layer 4 ports involved in
communication flows can all be used to match interesting traffic
using filter entries. Filters can be defined to be relatively generic to
enable extensive reuse.
 Subject: Once filters are defined, they are linked to one or
more subjects. A subject determines the actions that are taken on the
interesting traffic. Should matching traffic be forwarded, dropped, or
punted to a firewall or load balancer? Should the traffic that has been
matched by filters be reclassified into a different QoS bucket? These can
all be defined by subjects. A subject can also define whether
corresponding ports for return traffic should be opened up.
 Contract: A contract references one or more subjects and is
associated directionally to EPGs to determine which traffic flows are
bound by the contract. Contracts are scope limited and can also be
configured to modify traffic QoS markings.
Because the concept of ACI contracts can be difficult to grasp, some examples
are in order. Figure 5-18 shows an example of how you might set up filters,
subjects, and contracts to lock down a basic multitier application. Applications
also require connectivity to critical services such as DNS and some method to
enable connectivity for outside users. This figure does not show contracts
beyond those needed for the various tiers of the application to communicate.
Figure 5-18 Filters, Subjects, and Contracts
For now, do not worry about implementation procedures for contracts, subjects,
and filters. Implementation of these objects is covered in Chapter 8,
“Implementing Tenant Policies.”

ACI allows open communication between endpoints residing in a single EPG

(intra-EPG) by default without the need for contracts, but intra-EPG
communication can also be locked down. Figure 5-16, presented earlier in this
chapter, shows the Intra EPG Isolation configuration option, which is set to
Unenforced by default. There are very compelling use cases for setting Intra
EPG Isolation to Enforced. For example, management stations that would reside
either outside an ACI fabric or in a separate EPG may need to communicate
with server CIMC out-of-band connections, but CIMC ports across multiple
servers have no need to cross-communicate. Where there is no need for
endpoints within an EPG to communicate with one another, intra-EPG isolation
can be implemented on the given EPG. This feature uses private VLAN
functionality without the headache of administrators having to define primary
and secondary VLANs for bare-metal connections.

Contract Direction

ACI contracts are directional because TCP/IP communication is inherently

directional. A client service initiates communication with a server. The server is
a provider of a service to the client machine, and the client is a consumer of a
service. (A sample directional application of contracts is presented in Figure 5-
18.)
All communication within data centers conforms to this provider/consumer
model. Although a web server provides services to users, it is also consuming
services itself. For example, it may attempt to initiate communication with a
backend database server, NTP servers, and DNS servers. In these cases, the web
server acts as a client machine. Any contracts that allow outside users to access
web services on the web server should be applied to the web server EPG in the
provider direction. However, any contracts that allow the web server to
communicate with other servers for NTP, DNS, and backend database access
need to be applied to the web EPG in the consumer direction and to the database
server, NTP servers, and DNS servers in the provider direction.

Contract Scope
A contract scope is a condition that determines whether a contract can be
enforced between EPGs. Options for contract scope are as follows:

 Application profile: A contract with an application profile scope

can be enforced between EPGs if they reside within the same application
profile.
 VRF: A contract with a VRF scope can be enforced between EPGs
if they reside within the same VRF instance. EPGs can be in different
application profiles.
 Tenant: A contract with a tenant scope can be applied between
EPGs if they are all in the same tenant. The EPGs can be in different
VRFs and application profiles.
 Global: A contract with a global scope can be applied between any
EPGs within a fabric and can be exported between tenants to enable
 cross-tenant communication. If a global scope contract is placed in the
common tenant, it can enable cross-tenant communication without the
need to be exported and imported between tenants.
To better understand contract scopes, reexamine Figure 5-18. Notice that Web
Server A and Web Server B can communicate with one another without
contracts because they are in the same EPG. An administrator who wanted to
prevent all communication between endpoints within an EPG could block all
intra-EPG traffic at the EPG level. However, this is not always desirable.
Sometimes, a subset of endpoints within an EPG might be in a clustered setup
and need to communicate, while others should not be allowed to communicate.
Moreover, the contracts shown in Figure 5-18 enable open communication
between Web Server A and App Server B, with the hope that the firewall blocks
such communication if it is not desired. If the suffixes A and B denote different
applications, the contracts depicted would be considered suboptimal because
ACI would allow communication across different applications.
As an alternative, consider Figure 5-19. All endpoints suffixed with the letter A
form a LAMP stack and have been placed into an application profile called
LAMP1. Similarly, endpoints suffixed with the letter B form a separate three-
tier application and have been placed into LAMP2. Moreover, the scope of the
contracts, which was unclear from the previous example, has been clarified to
be Application Profile. With this modification, even if a slight configuration
mistake were to occur in contract configuration and its application to the EPGs
(for example, if all ports were erroneously opened), the mistake would be scope
limited to each application profile. In other words, various tiers of different
application profiles would still be unable to communicate. Therefore, you can
translate the logic applied by the contract scope to mean “apply this contract
between EPGs only if they are all in the same application profile.”
Figure 5-19 Contract Scope Example
As an extension of this example, what scope would you need to use in a new
contract applied to all of the depicted EPGs, assuming that the contract seeks to
allow them to communicate with an NTP server that is in a separate VRF
instance within the same tenant? If you answered that the scope needs to be
Tenant, you would be right. What scope would have to be defined if the NTP
server were in a different tenant? The answer in that case would be Global.

Zero-Trust Using EPGs and Contracts

A zero-trust network architecture is an information security framework
originally proposed by research and advisory firm Forrester that addresses the
inherent weakness of a perimeter-focused approach to security by assuming no
default trust between entities.
Attainment of a zero-trust data center is the primary security objective of EPGs
and contracts. As noted earlier, ACI assumes no trust by default between EPGs
unless the desired communication has been whitelisted.
OBJECTS ENABLING CONNECTIVITY
OUTSIDE THE FABRIC
Whereas bridge domains, EPGs, and other constructs introduced in this chapter
enable the deployment of applications and communication of application tiers,
at some point, tenant endpoints need to communicate with the outside world.
External EPGs and L3Out objects play a key role in enabling such
communication.

External EPGs

An external EPG is a special type of EPG that represents endpoints outside an

ACI fabric, such as user laptops, campus IoT devices, or Internet users. There
are many reasons you might want to classify traffic outside ACI. One reason to
do so is to be able to apply different security policies to different sets of users.
External EPGs classify outside traffic using subnets, but the subnets can be as
granular and numerous as needed.
Figure 5-20 shows three external EPGs that are allowed different levels of
access to servers within an ACI fabric. Any traffic sourced from IP addresses
defined in the external EPG named EXT-ADMINS will be allowed access to all
the depicted servers via SSH, HTTPS, and RDP, but all other internal users
classified into the external EPG called EXT-INTERNAL will be limited to
HTTPS access to the web server. All users sourcing traffic from the Internet
will be classified into the external EPG called EXT-INTERNET and will
therefore be denied any form of access to these specific servers because no
contracts permitting communication have been associated between the servers
and EXT-INTERNET.
Figure 5-20 Controlling Access to ACI Fabrics by Using External EPGs
One point that is important to clarify here is that external EPG subnets are
longest prefix-match subnets. Therefore, EXT-INTERNET, which consists of
the 0.0.0.0/0 subnet, classifies all endpoints out on the Internet but not internal
subnets in the more specific 10.0.0.0/8 range allocated to EXT-INTERNAL.
Expanding on this concept, it is important to understand that any given outside
endpoint will be classified to one and only one external EPG. Just because the
administrator group defined by EXT-ADMINS at 10.10.2.0/24 also falls within
the 10.0.0.0/8 range does not mean that administrators will have some of their
access removed to reflect the access levels of the 10.0.0.0/8 range. Likewise, if
EXT-INTERNAL were allocated more access than EXT-ADMINS, the
10.10.2.0/24 administrator subnet would not inherit expanded access.
So, what happens if an administrator associates a particular subnet with multiple
external EPGs? ACI triggers a fault, and the second subnet allocation to an
external EPG is invalidated. The only exception to this rule is the 0.0.0.0/0
subnet. Regardless of this exception, deployment of multiple external EPGs that
reference the same subnet is bad practice.

External EPGs, sometimes referred to as outside EPGs, classify traffic based on

a longest-prefix match, and any given outside endpoint will be classified into
the most specific applicable external EPG that has been defined.
Note
Other types of external EPGs exist. The type of external EPG used for classification of
external traffic that is described here is configured with the Scope value External
Subnets for the External EPG. Chapter 9, “L3Outs,” addresses the other Scope settings
that are available.
Also, as shown in Figure 5-20, external EPGs associate with objects called
Layer 3 Outs, which in turn bind to VRF instances.

Layer 3 Outside (L3Out)

An L3Out is an object that defines a route peering or a series of route peerings

to allow route propagation between ACI and an external Layer 3 switch, router,
or appliance. BGP, OSPF, and EIGRP are all supported protocols for use on
L3Outs. Static routes pointing outside ACI can also be configured on L3Outs.
A regular L3Out is configured within a tenant and is bound to a single VRF
instance. A number of specialized L3Outs can be created in the infra tenant,
which can advertise routes from multiple ACI VRF instances to the outside
world. This book focuses on regular L3Outs.

TENANT HIERARCHY REVIEW

Figure 5-21 provides an overview of the tenant hierarchy and the relationship
between the objects outlined so far in this chapter. Each relationship between
tenant objects is shown to be either a 1:n (one-to-many) relationship or
an n:n (many-to-many) relationship. Figure 5-21 shows, for example, that any
one bridge domain can be associated with one and only one VRF instance.
However, any one bridge domain can also have many subnets associated with it,
so a bridge domain can have a 1:n relationship with subnets.
Figure 5-21 Objects That Reside in Tenants and Their Relationships

EXAM PREPARATION TASKS

As mentioned in the section “How to Use This Book” in the Introduction, you
have a couple of choices for exam preparation: Chapter 17, “Final Preparation,”
and the exam simulation questions in the Pearson Test Prep Software Online.

REVIEW ALL KEY TOPICS

Review the most important topics in this chapter, noted with the Key Topic icon
in the outer margin of the page. Table 5-2 lists these key topics and the page
number on which each is found.

Table 5-2 Key Topics for Chapter 5

Key Topic Description
Element

Paragraph Defines tenants

List Describes predefined tenants in ACI

 Paragraph Defines VRF instances

Paragraph Defines bridge domains

Paragraph Defines EPGs

Paragraph Defines application profiles

Paragraph Describes associations between application profiles, bridge domains, an

EPGs

Paragraph Describes practical bridge domain functions

Paragraph Describes practical EPG functions

Paragraph Lists encapsulations in ACI for Ethernet traffic

List Defines contracts, subjects, filters, and filter entries

Paragraph Defines and provides a sample use case for intra-EPG isolation

Paragraph Defines contract direction options

List Lists and describes contract scopes

Paragraph Defines external EPGs

Paragraph Describes method of endpoint classification by external EPGs

Paragraph Defines L3Outs

COMPLETE TABLES AND LISTS FROM

MEMORY
There are no memory tables or lists in this chapter.

DEFINE KEY TERMS

 Define the following key terms from this chapter and check your answers in the
glossary:
tenant
fabric policy
fabric port
access policy
Virtual Machine Manager (VMM) domain
virtual routing and forwarding (VRF) instance
application profile
bridge domain (BD)
endpoint group (EPG)
filter
subject
contract
contract scope
consumer
provider
external EPG
L3Out
Find answers on the fly, or master something new. Subscribe today. See pricing
options.

 Support
 
 Sign Out
© 2021 O'Reilly Media, Inc. Terms of Service / Privacy Policy