Sing a new song for sorting server groups and policy

Cisco ACI Tutorial – Part 3

If you have been responsible for defining groups of servers and devices to which policy can be applied, you have probably used structures called Access Control Lists, or ACLs.

ACLs are typically based on IP addresses and IP address ranges, with added refinements for UDP/TCP port numbers.

ACI has no concept of ACLs.  In this part of the tutorial I’ll explain how ACI uses the concept of Application Profiles (APs) and End Point Groups (EPGs) to identify devices and policy groupings.  Later I will add Contracts and Filters to complete the story, but for now I want to relate these new concepts to the picture I presented in the previous tutorial.

TIP:	If you have not read Cisco ACI Tutorial – Part #1, now would be a good time. It contains a diagram of the topology and some important notes about conventions used. Similarly, you will get more familiar with the context of this tutorial if you also take a look at Cisco ACI Tutorial – Part #2

The following diagram adds the relationship between  Application Profiles, End Point Groups, and Bridge Domains to the diagram from Part #2.

EPGs are children of the AP and the AP is a child of the Tenant. The Tenant owns the AP and the AP owns the EPGs.  But each EPG must be linked to a Bridge Domain. And here’s the catch.  The Bridged Domain that the EPG is is linked to doesn’t have to belong to the same Tenant as the EPG itself.

In the diagram above, you can see that the AP called  AP1 has three EPGs. The AP and all its EPGs then belong to the Tenant called RedNectar, but the EPG called DB-EPG is linked to a BD in the common tenant.  The common tenant is a special tenant where shared configuration can be defined. I have used this relationship here just to illustrate that there is a little chink in the hierarchical model, in that entities that are linked rather than related (parent-child) can be linked outside the parent-child relationship.

As far as IP addressing goes, devices in the PublicServers-EPG could be in either the 203.0.113.0/24 subnet, or the 10.1.4.0/24 subnet. Traffic between devices on the 203.0.113.0/24 subnet will be bridged in the normal way based on MAC addresses, but traffic between 203.0.113.0/24 devices and 10.1.4.0/24 devices will be routed freely (remember there is NO restriction between devices in the same EPG) without policy applied.

Key Point:

End Point Groups are basic unit of policy enforcement.  End Points (=something with an IP address) within the same EPG can communicate freely without restrictions – ping each other, share files… Later I will show how a Contract is needed to permit devices in different EPGs to communicate.

However the more interesting arrangement above concerns the two EPGs linked to the Clients-BD. Note that there are two EPGs but only one subnet.  This means that some End Points that are on the same subnet will NOT be able to freely communicate with each other – they will need a Contract to be able to communicate.

---

 

Time out – re read that last paragraph

Yes – it says that you can easily configure different communication  policies between devices on the same subnet. Something that would involve tedious editing of MAC address ACLs or PACLs (Port Access Control Lists) in a traditional environment.

The result is something akin to what you might have used Cisco’s Private VLANs for in the past – each End Point uses the same default gateway IP address, but only End Points in the same EPG can communicate freely.

---

For our configuration model I won’t make it as sophisticated as the diagram.  I will simply start by configuring an AP with two EPGs.

Note the naming used for the EPGs. It is no accident that they closely relate to the BDs that they are linked to.  It is possible to have multiple EPGs linked to a single BD (as in the example above), but unless you are specifically attempting fine grained separation, I wouldn’t recommend having more than one EPG linked to a BD.

The EPG is the atomic unit for applying policy. All devices in the same EPG therefore have unrestricted access to each other, but for traffic to travel between EPGs there will need to be a Contract.

For our example, I will begin by creating one Application Profile (AP), and two End Point Groups (EPGs) within the AP.

Configuration Steps

Step 1: Add a new Application Profile

The application profile is a set of requirements that an application instance has on the virtualizable fabric. The policy regulates connectivity and visibility among endpoints within the scope of the policy.

Application profiles define the policies, services and relationships between End Point Groups (EPGs). Each application profile contains one or more EPG that can communicate with the other EPGs in the same application profile and with EPGs in other application profiles according to the contract rules. [Adapted from ACI Help]

The Application Profile is a container object for End Point Groups. An Application Profile can also be used to limit the scope of a Contract. [RedNectar’s Definition]

TENANTS > RedNectar > Tenant RedNectar > Application Profiles

• (+) Create Application Profile
  • Name: AP1

Step 2: Add two new Application End Point Groups

An End Point Group (EPG) is a collection of physical and / or virtual end points that require common services and policies. End point examples include servers, virtual machines, storage, or clients on the Internet. An End Point Group example is a set of servers providing a common application, function or service. [From ACI Help]

An End Point Group (EPG) is a group of End Points that require common services and policies, such a server farm.  End Points are defined by IP and/or MAC addresses.  End Point Groups must be associated with a single Bridge Domain to enable Layer 2/3 connectivity, and End Point Groups must be associated with at least one (VLAN) Domain, either a Physical Domain or a VMM Domain  so that the ACI Fabric can detect incoming traffic from an End Point.

The ACI Fabric uses 802.1Q VLAN tags (or VXLAN VNIDs) to identify which EPG incoming traffic is associated with.  [RedNectar’s Definition]

TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs

• (+) Create Application EPG
  • Name: InternalClients-EPG
  • Bridge Domain: RedNectar/Clients-BD

TIP:	Take note of the fact that there is a section in the EPG configuration where you can associate the EPG to a list of Domains(*).  Domains play a very important role in the EPG as you will see in part #5 of this Tutorial.

• (+) Create Application EPG
  • Name: PublicServers-EPG
  • Bridge Domain: RedNectar/PublicServers-BD

So now your configuration can be encapsulated by the following illustration:

---

Filters, Subjects and Contracts

Before you can apply policy to traffic flowing between EPGs, you will need to create the Contracts that define the policy to be applied. And since Contracts have Subjects and Subjects are linked to Filters, you will need to define those too.

The following diagram shows the relationship between EPGs, Contracts, Subjects and Filters.

Filters are easy to understand.  A filter simply allows traffic on a particular UDP/TCP port (or traffic on a particular protocol like ICMP).  So in my example I have one filter called HTTP-Fltr with two entries – one I have named TCP80 which filters on destination TCP port 80, the other named UDP80, which filters on destination UDP port 80. Another filter is called HTTPS-Fltr with only one entry – TCP443 and the last one is called App-Fltr and has one entry called TCP88.  No prizes for guessing how that naming scheme works!

However, I would like to point out that there is a subtle difference between the first two filters and the last. Filters are defined within a Tenant space, so I have defined the first two in the common tenant, which means they will be available to all Tenants. The third one is defined within the RedNectar tenant.

Now Contracts are not directly linked to Filters.  Instead, Cisco has added an extra layer of flexibility (and complexity) by giving Contracts a child object called a Subject.  And it is the Subjects that are linked to Filters – in my example the Contract ServerToClient.PN.Ct has two Subjects and one of those Subjects (Web-Subj) is linked to two Filters from the common tenant.

Finally, the crux of the matter is the way policy is applied through the Contract.  For a Contract to pass traffic, the EPG either has to Consume a Contract or Provide a Contract. and every Contract must have at least one consumer and one provider to be of any use.  Later I will discuss how Contracts can also be used to redirect traffic to services such as Firewalls and Load Balancers. but for now, notice how the name of the contract indicates the direction of consumption.

There are two things to consider when naming contracts; direction and scope.  With the name ServerToClient-PN.Ct I have indicated that the direction of consumption is from Server To Client, and in the PN in the name indicates that the scope of the contract is Private Network.  When you are looking at a list of contracts and trying to apply one to an EPG, knowing the scope of each contract is important.

For my example, I will continue by examining the pre-defined filters in the common Tenant, then creating a new Filter in the common Tenant for Web traffic which will filter on TCP ports 80 and 443.

I will then create a new Contract in the common Tenant – for ping traffic. In the process, Subjects will be added to the Contract and linked to the Filters that were examined/created earlier.

For diversity, I will then repeat the process of creating a Filter and Contract in the RedNectar Tenant.

Configuration Steps

Step 3: Examine pre-defined Filters

A filter policy is a group of resolvable filter entries. Each filter entry is a combination of network traffic classification properties. [Adapted from ACI Help]

TENANTS > common > Tenant common > Security Policies > Filters

• Note that there are a set of pre-defined filters defined in the common Tenant.  These filter can be linked to any Subject in any Contract in any other Tenant.

Step 4: Create a common Filter for web traffic

TENANTS > common > Tenant common > Security Policies > Filters

• (+) Create Filter
  • Name: Web-Fltr
  • Add (+) Entries:
    • Name: TCP80
      EtherType: IP
      IP Protocol: tcp
      Stateful: [x] Checked
      Source Port Range From: any To: any [See Note below]
      Destination Port Range From: http To: http
  • Add (+) Entries:
    • Name: TCP443
      EtherType: IP
      IP Protocol: tcp
      Stateful: [x] Checked
      Source Port Range From: any To: any
      Destination Port Range From: 443 To: 443

Note:

For the second entry I could have selected the Destination Port Range From: https To: https, but I wanted to illustrate that it is possible to type port numbers in these fields – but it is tricky. Type quickly and hit Tab as soon as you have finished typing.

Step 5: Create a common Contract for web traffic and a common Contract for ping traffic.

A service contract/deal can exist between two or more participating peer entities, such as two applications running and talking to each other behind different endpoint groups, or between providers and consumers, such as a DNS contract between a provider entity and a consumer entity.

A subject is a sub-application running behind an endpoint group (for example, an Exchange server). A subject is parented by the contract, which can encapsulate multiple subjects. An endpoint group associated to a contract is providing one or more subjects or is communicating with the subject as a peer entity. An endpoint group always associates with a subject and defines rules under the association for consuming/providing/peer-to-peer communications to that subject.

One or more subjects within a contract use filters to specify the type of traffic that can be communicated and how it occurs.  Each filter entry is a combination of network traffic classification properties. [Adapted from ACI Help]

TENANTS > common> Tenant common > Security Policies > Contracts

• (+) Create Contract
  • Name: Ping-TnCt
  • Scope: Tenant
  • Add (+) Subjects:
    • Name: Ping-Subj
    • Add (+) FILTERS
      • Name: common/icmp

Step 6: Create a tenant Filter for custom application traffic

Note:

Make sure you do NOT do the following configuration in the common Tenant – I am switching back to Tenant RedNectar’s configuration.

TENANTS > RedNectar > Tenant RedNectar > Security Policies > Filters

• (+) Create Filter
  • Name: App-Fltr
  • Add (+) Entries:
    • Name: TCP88
      EtherType: IP
      IP Protocol: tcp
      Stateful: [x] Checked
      Source Port Range From: any To: any
      Destination Port Range From: 88 To: 88

Step 7: Create a tenant Contract for web traffic and custom application traffic

TENANTS > RedNectar > Tenant RedNectar > Security Policies > Contracts

• (+) Create Contract
  • Name: PubSrvsToIntClnts-PN.Ct 
  • Scope: Private Network [Default]
  • Add (+) Subjects:
    • Name: Web-Subj
    • Add (+) FILTERS
      • Name: common/Web-Fltr
  • Add (+) Subjects:
    • Name: App-Subj
    • Add (+) FILTERS
      • Name: RedNectar/App-Fltr

Note:

The above result could have also been achieved using a single Subject with two filters added. Separating each filter into it’s own subject allows for future flexibility is you say wanted to add QoS policies to one of the subjects. Indeed, the above could also have been achieved by creating two contracts, one for Web and one for App traffic.  It all depends on the level of granularity required.

 Consuming and Providing Contracts

Now that you have all of the building blocks – EPGs, Filters and Contracts defined, you can start defining how policy is to be applied to allow traffic between our EPGs.  To do this, you will return to the EPGs you created earlier, and link the contracts in a provider-consumer relationship.  The PubSrvsToIntClnts-PN.Ct contract will be be linked as a provided contract to the PublicServers-EPG and as a consumed contract to the InternalClients EPG.  This will allow devices in the InternalClients-EPG to ask for TCP services on ports 80, 443 and 88 from devices in the PublicServer-EPG.  Return traffic will be allowed of course, but devices in the PublicServer-EPG will not be able to consume Web traffic from the InternalClients-EPG even if those devices have services listening on TCP ports 80, 443 or 88.

However, the Ping-Tn.Ct contract is a little different.  In this case, you will want devices in the PublicServer-EPG to be able ping the InternalClients-EPG devices and  the InternalClients-EPG devices to be able to ping the PublicServer-EPG devices.  So to make this happen, each EPG will have to be both a provider to and a consumer of the contract.

[Edit: 2015-11-27. Since ACI v1.1, ICMP filters only need to be applied in one direction. Once an EPG has been defined either a  provider to or a consumer of a contract with an ICMP filter it is able to both send and receive ICMP traffic to a corresponding consumer or provider. However, you still need both a consumer and a provider.  Two providers can’t ping each other, nor can two consumers.]

Configuration Steps

Step 8: Link EPGs with contacts in their appropriate consumer-provider relationship.

TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs > EPG InternalClients-EPG > Contracts

•  (+) Add Consumed Contract
  • Contract: RedNectar/PubSrvsToIntClnts-PN.Ct

•  (+) Add Consumed Contract
  • Contract: common/Ping-TnCt

•  (+) Add Provided Contract [Edit: 2015-11-27. This is now unnecessary]
  • Contract: common/Ping-TnCt

TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs > EPG PublicServers-EPG > Contracts

•  (+) Add Provided Contract
  • Contract: RedNectar/PubSrvsToIntClnts-PN.Ct

•  (+) Add Consumed Contract [Edit: 2015-11-27. This is now unnecessary]
  • Contract: common/Ping-TnCt

•  (+) Add Provided Contract
  • Contract: common/Ping-TnCt

Step 9: Verify your configuration

TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs

• You should see icons representing your EPGs and your Contracts.  You can move these icons around, and without too much trouble, you should be able to get your screen looking something like this:
  

Note that the arrows show the direction from Provider  to Consumer.  In the case of the Ping-TnContr, the arrows are pointing away from the contract, indicating that both EPGs are consuming the contract, but unfortunately there is no indication that both EPGs are also providing the contract as well.

TIP:	If your screen seems to have arrows going different ways to my illustration, select some other top menu item (like SYSTEM) then navigate back to TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs.

TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs > EPG PublicServers-EPG | [OPERATIONAL] | [CONTRACTS]
TENANTS > RedNectar > Tenant RedNectar > Application Profiles > AP1 > Application EPGs > EPG InternalClients-EPG | [OPERATIONAL] | [CONTRACTS]

Note the filters that are produced when you create contracts.

Discussion

You now have policies in place to control traffic between devices in the two EPGs you have created. But at the moment there is absolutely no use for your AP, your EPGs or any other policy related configuration that you have completed, because you have yet to tell the APIC which connected devices and servers belong to which EPG.

And before you can do that, you will have to tell the APIC how to identify traffic and on which interfaces to expect traffic for these EPGs.

And to do that you will need to learn all about the  Access Policy Chain – a new “interface range” command.

Next…

RedNectar

Note:

If you would like the author or one of my colleagues to assist with the setup of your ACI installation, contact acimentor@housley.com.au and refer to this article. Housley works mainly around APJC, but are not restricted to this area.

Footnotes

Domains

Note:

Domains  are sometimes referred to as Domain Profiles (in EPG configuration and in the help documentation).   Don’t confuse them with Bridge Domains, they are entirely different concepts – think of Domains as VLAN Domains and you will be closer to the mark. The use of Domains will come to prominence in parts #5 and #6 of this tutorial.