New CLI coming for Cisco ACI/APIC

This video on youtube shows off the NX OS style CLI coming for Cisco ACI with version 1.2 code for the APIC and version 11.2 ACI switch code.

The slides shown at the beginning of the video mention a release date of December 2015. That’s not far away!

I watched the video (20mins) and noticed a couple of interesting things in the CLI

  1. Application Profiles are configured using the application configuration command, although the speaker still referred to it as an “Application Network Profile”
  2. Private Networks are configured using the vrf context  configuration command. I love consistency!
  3. From a snippet of code he showed, it looks like filters are referenced within subjects as access-groups. Clearly trying to appeal to the old CLI jockeys rather than making a clean correlation to the already flawed and inconsistent GUI, or even a correlation to the the API classes and distinguished names.


Note:RedPoint If you would like the author or one of my colleagues to assist with the setup of your ACI installation or ACI training needs, contact and refer to this article. Housley works mainly around APJC, but are not restricted to this area.



Posted in ACI, ACI configuration, Cisco, Data Center, Data Centre, NX OS | Leave a comment

Cisco ACI Tutorial 3 – Sing a new song for sorting server groups and policy

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:RedPoint2 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 ProfilesEnd 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 subnet, or the subnet. Traffic between devices on the subnet will be bridged in the normal way based on MAC addresses, but traffic between devices and 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 ACLs with 32 but masks 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]

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]

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

  • (+) Create Application EPG
    • Name: InternalClients-EPG
    • Bridge Domain: RedNectar/Clients-BD
TIP:RedPoint2 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:

Tn with DB and SN and AP and EPG

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 EPGsContractsSubjects 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; Destination Port Range From: http To: http
    • Add (+) Entries:
      • Name: TCP443; EtherType: IP; IP Protocol: tcp; Destination Port Range From: 443 To: 443
Note:RedPoint 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 soons 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

TENANTS > RedNectar > Tenant RedNectar > Security Policies > Filters

  • (+) Create Filter
    • Name: App-Fltr
    • Add (+) Entries:
      • Name: TCP88; EtherType: IP; IP Protocol: tcp; 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:RedPoint 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 andprovider.  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:

ApplicationEPGs view

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:RedPoint2 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.


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 how to use the new “interface range” command.



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



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.The use of Domains will come to prominence in parts #5 and #6 of this tutorial.
Posted in ACI, ACI configuration, Cisco, configuration tutorial, Data Center, Data Centre, Nexus, Nexus 9000, SDN, Software Defined Networking | Tagged , , , , , , , , , , , , | 2 Comments

Cisco ACI Tutorial 2 – Goodbye to VLANs. Well… not quite

Goodbye to VLANs. Well… not quite

Cisco ACI Tutorial – Part 2

ACI does not use VLANs or even subnets to isolate policy groups. I’m sorry if this is a shock for you, but before I discuss how policy groups are bound by an object known as an End Point Group I’ll use this tutorial to take you through the replacement concepts for VLANS and IP addressing.  The containers used by ACI to provide IP addressing isolation are the Tenant, and the Private Network.  Bridge Domains are used to provide multicast and broadcast isolation (similar to VLANs) and you’ll be pleased to know that we still use Subnets for IP addressing.

In this part of the tutorial I am going to take you through the configuration of the primary containers in ACI as you setup a Tenant, a Private Network, two Bridge Domains and two Subnets.

TIP:RedPoint2 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.

First a little theory

ACI uses the concepts of Tenants, Private NetworksBridge Domains, and Subnets in a hierarchy to contain routed traffic.  Note that the concept of VLANs is entirely absent. Later I will add the most important policy containment concept, End Point Groups (EPGs) to the mix.

This diagram shows the hierarchy of Tenants, Private NetworksBridge Domains, and Subnets.

Note that some relationships are linked such as Bridge Domains are linked to Private Networks, while others are parent-child relationships, such as Subnets, which are children of Bridge Domains which in turn are children of Tenants.  Note that these relationships are also one-to many – a Tenant may have multiple Private Networks, Private Networks can be linked to multiple Bridge Domains, and Bridge Domains many multiple child Subnets.

Note:RedPoint Typically you will have only one Subnet per Bridge Domain, so in that sense a Bridge Domain “resembles” a VLAN, and a Subnet “resembles” a VLAN interface.

The naming and numbering of the items also reveals some of the isolation as well. Note that the names BD1 and BD2 have been used in each Tenant, and that Tenant Large has three Private Networks (VRFs), two of which have an instance of the subnet associated with it.

Note: RedPoint The subnet numbering is on purpose. actually defines the Distributed Gateway address for the subnet, but it is convenient to use the numbering to indicate both in this diagram.

Configuration Steps

Step 1: Add a new Tenant

A tenant is a logical container for application policies that enable an administrator to exercise domain-based access control. A tenant represents a unit of isolation from a policy perspective, but it does not represent a private network. Tenants can represent a customer in a service provider setting, an organization or domain in an enterprise setting, or just a convenient grouping of policies. [From ACI Help]


  • Name: RedNectar
Note:RedPoint Clicking NEXT, and FINISHED is assumed since I have come to the end of the item.  I almost always avoid using the Wizard steps because Wizards are magical creatures that are particularly good at hiding information. By avoiding the Wizards, you will get to know where the individual configuration items are placed.

Step 2: Give the new Tenant a Private Network

A private network is a layer 3 context (a VRF) that provides IP address space isolation for tenants. Each tenant can have one or more private networks, or share one default private network with other tenants when there is no overlapping IP addressing being used in the ACI fabric. [From ACI Help. I added the emphasis to illustrate how the terms private network,  [layer 3] context and VRF are used interchangeably  in ACI terminology]

TENANTS > RedNectar > Tenant RedNectar > Networking > Private Networks

  • (+) Create Private Network
TIP:RedPoint2 The Create Private Network option is reached by right-clicking on the Private Networks element in the Navigation Pane or by clicking the ACTIONS menu at the top right hand side of the Work Pane
    • Name: VRF1
    • Create A Bridge Domain [ ] Unchecked

Step 3: Give the new Tenant two Bridge Domains

A bridge domain represents a L2 forwarding construct within the fabric. One or more EPG can be associated with one bridge domain or subnet. A bridge domain can have one or more subnets associated with it. One or more bridge domains together form a tenant network. [From ACI Help]

TENANTS > RedNectar > Tenant RedNectar > Networking > Bridge Domains

  • (+) Create Bridge Domain
    • Name: Clients-BD
    • Network: RedNectar/VRF1
  • (+) Create Bridge Domain
    • Name: PublicServers-BD
    • Network: RedNectar/VRF1

Step 4: Give the new Bridge Domains a Subnet each

A subnet, which represents routes that will be exported. While a context defines a unique IP address space, that address space can consist of multiple subnets. These subnets are defined per bridge domain. A bridge domain can contain multiple subnets, but a subnet is contained within a single bridge domain.. [From ACI Help]

TENANTS > RedNectar > Tenant RedNectar > Networking > Bridge Domains > Clients-BD > Subnets

  • (+) Create Subnet
    • Gateway IP:

TENANTS > RedNectar > Tenant RedNectar > Networking > Bridge Domains > PublicServers-BD > Subnets

  • (+) Create Subnet
    • Gateway IP:
    • Scope:
      [x] Public Subnet
      [ ] Private Subnet [Unchecked]

Step 5: Verify your configuration

Navigate your way around the Navigation Pane and expand the relevant sections to verify that you have. It should look something like this:

Verify Tenant Config

And diagrammatically, it could be represented like this:


Note that you have created a structure to contain your subnets that does not involve VLANs.  If you have come from a networking background, this will be a foreign concept for you.  Subnets are however contained by another scope called a Bridge Domain.  In many ways a Bridge Domain is similar to a VLAN, but the is not a container for policy enforcement.  For Policy enforcement, you will need to sing a new song for sorting server groups and policy, namely Application Profiles and End Point Groups.



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


Quotations: The quotations supplied to describe the various elements are taken directly from the ACI Help.  I did not write this content and want to be clear about the source.  Which also should give you a heads up: It is a good idea to click the little i symbol in the top right-hand corner of many panes and dialogues.
Naming Conventions: Note also the naming convention used.  You will find that I almost always give an object a descriptive name followed by a dash followed by an identifier – such as Clients-BD – the name only has one dash. If a separator is needed in either part of a name, a dot . or a colon : or an underscore _ is used.  Sometimes a generic name is appropriate, especially if the purpose is not clear (you CAN’T change names later).  If I had have planned multiple VRFs (Private Networks) I may have named them something like DMZ-VRF and Internal-VRF, but in this case I chose a generic VRF1 as a name.
Posted in ACI, ACI configuration, Cisco, configuration tutorial, Data Center, Data Centre, Nexus, Nexus 9000, SDN, Software Defined Networking | Tagged , , , , , , , , , , , , | 2 Comments

Cisco ACI Tutorial – A Configuration Guide

Cisco ACI Tutorial – A Configuration Guide

Cisco ACI Tutorial – Part 1

Note:RedPoint This is the first of a series of at least eight blog posts that I plan to publish over the coming weeks. Make sure you follow my blog so you don’t miss out on the continuing story.

If you are new to Cisco Application Centric Infrastructure (ACI) then you may well be daunted at this new method of configuring switches.  In this multi-part tutorial, I hope to take some of the configuration pain out of your headache.

I will take you through some of the underlying concepts, but do not attempt to explain the theory of ACI, such as VXLAN overlays and the like.


This is a configuration tutorial. It takes you through the steps needed to configure a sample ACI fabric.  The journey will give you important foundations in naming conventions that will help you understand your configuration in the future, and establish some best practices and conventions that will guide you long into the future.

At the completion of the tutorial, you will have a fully configured ACI fabric ready for testing.  You are responsible for making sure that all systems are production ready before deployment in a live network.


To get the most out of this tutorial, you will need some basic understanding of Cisco ACI and the role of the Application Policy Infrastructure Controller (APIC).  Ideally, you will have access to an APIC and an ACI fabric, or the ACI Simulator.  Cisco partners/customers with sufficient rights to their CCO login, will be able to get access to an ACI simulator for a few hours at a time by logging on to Cisco dcloud.  See this post for a dcloud tutorial.

If you are not comfortable with terms like Leaf, Spine, Clos topology, End Point Groups and Application Profiles, then you will do well to do some research before you begin.  I’d recommend the following:

Let’s Begin


To get the ball rolling, I will assume that:

  • Your ACI devices are racked and stacked, and cabled according to the Topology below
  • You have completed the assigned Out of Band (OOB) Management IP addresses to your APIC(s) and assigned addresses to the TEP pool as described in the “Setting up the APIC” section of the APIC Getting Started Guide.
  • You have a management station logged into the APIC GUI ready to begin configuring your ACI fabric.
TIP:RedPoint2 If you have real lab equipment (rather than using a simulator), then you will also be able to physically test your configuration if you have:

  • at least two devices that can act as Bare Metal Servers (ie servers that do NOT run a hypervisor), ideally with two NICs (and a 3rd NIC for RDP or VNC access would also be useful in the lab environment)
  • at least one ESX server, and
    • VMware vCenter v5.5 installed with a NIC on the OOB Management Network.  For my test network I had an ESX with three NICs and ran the vCenter as a VM on the ESX server


This tutorial has seven parts, including this one.

  1. Let’s Begin
    • That’s this first tutorial where I cover the topology I will use, the Lab setup and conventions.
  2. Goodbye to VLANs. Well… not quite
    • Tenants, Private Networks, Bridge Domains and Subnets
  3. Sing a new song for sorting server groups and policy
    • Application Profiles, End Point Groups and Contracts
  4. A new “interface range” command
    • Access Port Profiles and Interface Profiles
    • And all that goes with it (Interface Policies, Policy Groups…)
  5. Connecting servers to the fabric switches
    • Directly connected bare-metal servers and switches without applying policy
    • VMware Virtual Machines
  6. Connecting the outside world
    • External bridged devices with applied policy
    • External routed devices
  7. Serving up services
    • Firewalls, load balancers, SSL offload…

The Topology

You probably know that an ACI Topology consists of Leaf and Spine switches.  For this tutorial, I will use two of each, although in truth the spine switches will not feature much at all in the configuration.  What will be more important is the equipment that is connected to the leaf switches.

ACI Topology

Note that there are two leaves.  To make life simple, I am going to use the following ports on each leaf switch for the following purposes:

Port range Use
1/1-2 External L3 Routers
1/3-4 External L2 Switches
1/5-7 10Gb/s
1/8-10 1Gb/s
 Single Attached Bare Metal Hosts
1/11-16 VPCs to ESX  Hosts
1/17-24 VPCs to UCS B Series
1/25-28 VPCs to Bare Metal Hosts
1/29-32 Port Channels to Bare Metal Hosts
1/33-40 FEX connections
1/41 SPAN Port
1/42-44 APIC attachments

I will refer back to this table in  Tutorial #4 A new “interface range” command.

The setup

AS I mentioned above, I’ll assume you have completed the assigned Out of Band Management IP addresses to your APIC(s) and assigned addresses to the TEP pool as described in the “Setting up the APIC” section of the APIC Getting Started Guide and can now log into your APIC’s GUI.

Already your fabric has begun the discovery process using LLDP, but before you can continue, you will have to register each leaf and spine switch in the APIC.  At the completion of this process, the APIC controllers will discover each other and form an APIC Cluster to become a single management unit.


I will refer to menu items in the APIC in the following manner:

FABRIC > INVENTORY > Pod 1> Leaf 1

means that you should select the main menu item FABRIC, the sub-menu item INVENTORY then expand the POD 1 branch of the Navigation pane, and select the item Leaf 1.  Leaf 1 is in bold print because Leaf 1 is a user assigned name – in your case you may have decided to call it L-101 or something different – so you will have to be on the lookout when menu paths have bolded items, if you don’t follow my names exactly, you may have differences.

Menu Bar, Submenu Bar, Navigation Pane and Work Pane

Sometimes, you will need to click in the Work Pane to perform some tasks, and in this case you may find that the work pane has tabs across the top, and possibly another row of tabs under that or even more tabs under that. When you need to click on a tab, the tab name will appear in square brackets after a vertical bar after the item you need to select in the navigation pane, like FABRIC > INVENTORY > Pod 1 | [OPERATIONAL] | [SWITCHES] | [LEAVES], which says, “After you have selected FABRIC > INVENTORY > Pod 1 in the navigation pane, select the OPERATIONAL tab in the Work Pane, then select the tab under that called SWITCHES, and the tab under that called LEAVES.


Configuration Steps

Step 1: Identify the fabric nodes

Note:RedPoint If you are using Cisco dcloud, you may find that this step has already been completed.

FABRIC > INVENTORY > Fabric Membership

You should see one item in the list with a NODE ID of 0 and no Node Name.  This device is the Leaf switch that your APIC is connected to.

Double-click on this entry and change the following:

  • NODE ID: 101
  • NODE NAME: Leaf1
Note:RedPoint Any text you have to enter will be shown in bold italics. Items that you have to select from a list or click on will be shown in bold only.

You will have to click on UPDATE to complete the change, but from now on you will have to assume that when I reach the end of a configuration item, you may need to click items like NEXT, FINISH, UPDATE and SUBMIT to complete the configuration.

After some time, the spine switches will be discovered via LLDP.  Pretty soon your screen should look something like this:


As each Spine switch is discovered, double-click on the entry and change the following:

  • NODE ID: 201
  • NODE NAME: Spine1
  • NODE ID: 202
  • NODE NAME: Spine2

And finally the second leaf will be discovered. Update to

  • NODE ID: 102
  • NODE NAME: Leaf2

Step 2: Verify your config

Verify your configuration by selecting FABRIC > INVENTORY > Pod 1 | [OPERATIONAL] |[SWITCHES] | [LEAVES] and FABRIC > INVENTORY > Pod 1 | [OPERATIONAL] |[SWITCHES] | [SPINES].

You should see that each switch has been given an INFRASTRUCTURE IP that has come from the range of TEP addresses you gave the APIC in the initial setup, and that the STATUS shows in-serviceVerify Leaves

Assuming all is well, it is time to get ready to say Goodbye to VLANs. Well… not quite



Note:RedPoint If you would like the author or one of my colleagues to assist with the setup of your ACI installation, contact and refer to this article. Housley works mainly around APJC, but are not restricted to this area.
Posted in ACI, ACI configuration, Cisco, configuration tutorial, Data Center, Data Centre, Nexus, Nexus 9000, SDN, Software Defined Networking | Tagged , , , , , , , , , , , , | 3 Comments

VPCS and VPCS multi-host

I have seen a few requests for help about VPCS on the GNS3 forum lately, and some confusion about the VPCS multi-host option and how it is different to the regular GNS3 VPCS host. So if you are confused, or just want to know more about how you can use VPCS in your GNS3 topologies, read on.

Single instance VPCS

There are two ways you can run VPCS – by far the easiest is to add a VPCS host to your topology. By dragging one in from the End devices pane. Once you have added the host, you can start the VPCS process by selecting the VPCS device, then choosing Device | Start (the Device menu can be also accessed by right-clicking on a device).

Once started, a console session can be established with the Virtual PC by choosing Device | Console.

And from here, you can explore VPCS options using the ?


To get stated, you’ll need to set an IP address, like this


…which will set the IP address for the VPC to with a mask of 255.255.255,0 and a default gateway of

And the next most important command you’ll want to learn is:


…which will of course you MUST do before saving your project within GNS3 – GNS3 will NOT save your VPCS (or your Cisco router configs) for you if you forget.

From this point, you’ll want to explore the ping and trace commands. But there are other commands worth checking out like:

show ip 


set dump detail

…to see a summary of packets sent and received by this VPC. (Use set dump off to turn it off)

You can then add another Virtual PC and another – as many as you like.

But there is another way of using the Virtual PC Simulator that gives you even more options – you may have seen it on your Tools menu. VPCS multi-host

VPCS multi-host

Now VPCS multi-host is considerably harder to set up than the normal VPCS. In fact, you have to set it up the way VPCS used to have to be set up in GNS3 v0.x – using either the cloud or host device (both are essentially the same)

To set up a VPCS multi-host, drag either a cloud or host device onto your topology.

Next, select the device, and choose Device | Configure. This brings up the Node Configurator (hopefully soon this will change name to the Properties dialogue).

From here, choose the UDP tab.

Initially, the settings should be just perfect for VPCS[1] – with the Local port setting at 30000, the Remote host set to, and the Remote port set to 20000, so click the Add button, then click OK.


You can now use the connector tool to connect to this nio_udp:30000: interface you have created to another device (make sure you select the nio_upd interface)


Now there isn’t much point using the VPCS multi-host option if you don’t want more than one host, but when you add your second host, you’ll have to be a little more careful at the step where you add the UDP settings under the UDP tab. For the second VPCS host, you need to use ports 20001 and 30001. And for the third VPCS host, ports 20002 and 30002 and so on. You can configure up to nine VPCS hosts in this way.

TIP:RedPoint2 When configuring the UPD ports for the second and subsequent hosts, you might find it easier to click the Add button multiple times until the port number you need for that host number appears in the box. You can then delete the others, or leave them there until you have built your topology – GNS3 will prune any extra unused ports for you when you quit the project!

Once you have got your VPCS hosts connected to your topology, you can choose the Tools | VPCS multi-host option to spawn a session with your hosts. And here is where the first big difference between the regular VPCS hosts and the VPCS multi-host option becomes apparent.

No matter how many VPCS multi-host you configured, only one window opens – and the prompt is slightly different; it will show:


Now the commands for VPCS multi-host are exactly the same as they are for the regular VPCS, except that all of your Virtual PCs are in one window – to access Virtual PC #2, you will have to enter the digit 2 on a command line by itself and hit <Enter> The prompt will change to


You can navigate to any of the 9 Virtual PCs in the same way – press digit <Enter> – as explained in the now slightly expanded help screen.

What’s the point? Why go to all that trouble to set up VPCS multi-host?

There are some simple advantages:

  • You only have to remember to save one file – a single save command saves the config of all your Virtual PCs (up to nine)
  • When you want to ping the same IP address from different hosts, simply change focus to a different Virtual CP, and use the up-arrow key to retrieve commands in your command history.
  • When you use the set dump command, you can see the results, even if the dump is for a different Virtual PC than the one in focus.
  • A single window is easier to mange than multiple windows, especially if you are using a totally Windowed terminal application that doesn’t support tabs (Putty for example).
  • Only a single instance of VPCS is spawned for all (nine) Virtual PCs, which means the amount of RAM and CPU required by VPCS is reduced by a factor of the number of single-instance VPCS you WOULD have used :)

But the most significant difference between Single instance VPCS and VPCS multi-host is possibly one you may never use, but incredibly powerful just the same.

With VPCS multi-host you can load a script file that tests your configuration from multiple points. There is no easier way to explain this than to show you a script checking one of my GNS3 WorkBench exercises. You’ll have to watch the video to see, but in it you’ll see multiple tests being carried out from multiple Virtual PCs, and the set dump feature used on a “remote” Virtual PC (the host) to observe that IP addresses have been NATted to the correct IP address.

The exercise used in the demonstration above was my ICND1 Readiness Test, part of the GNS3 WorkBench.

So the choice is yours – use either the regular Single instance VPCS, or configure your hosts to run in a single VPCS multi-host instance – you might even get adventurous and start writing your own scripts.

For more information on how to run the VPCS multi-host, check out my VPCS Tutorial


Posted in GNS3, GNS3 WorkBench, vpcs | Tagged , , , | 3 Comments

Cisco have a new ACI lab on dcould – here’s how to access it

If you sell/buy/use Cisco products, and you want to practice configuring them, then Cisco’s dcloud is a great resource.  And they have just added another ACI lab: Cisco Application Centric Infrastructure with shared Physical Fabric.

If you already know about dcloud, then go ahead, check out the new lab.  But if you are new to dcloud, then this tutorial will get you going.  You will need a login before proceeding. If you don’t have one, you can register here.

Start ny accessing dcloud at


The first time you access the site for a given browser, you will have to choose your location, and of course log onto the site using your logon details (available to anyone who signs up).

TIP:RedPoint2  Don’t use Internet Explorer for this lab if you want to access the remote desktop PC in full screen mode.


…and of course you’ll have to accept the Cisco dcloud User Agreement and fill out some Profile details if this is the first time for a particular theatre.


Once you hit the Home page, you might like to explore some of the training videos, but for me I want to go straight to the new ACI lab, so I’m going to open the Application Centric Infrastructure section and click More Information, because that is where I’ll download the pdf guide to the lab, and also find a Schedule option there anyway.


By default, your schedule will start at the next quarter hour time slot, but you can click Now is you are impatient. I was! And you can book the lab continuously for up to five days,


You’ll need to fill in some details about why you want the lab, and you session will begin.  It will take up to 15 minutes for the lab to prepare, because what is now happening is that the ACI simulator and a whole swag of Virtual Machines are being loaded up for your use. [Edit: this particular lab doesn’t use the simulator – it gives you access to real ACI kit with your own login]

Now while this is happening, it’s worth thing a little about what Cisco is doing in the background to make this happen.  If you are reading this, then you probably have some knowledge of SDN and Orchestration – and you are now watching it in action.

Once your session is ready, your dashboard will change to:


Now the first thing you will need to do is View your demo, and when you do, you will see a topology with a glowing workstation inviting you to click it! But I want to draw your attention to a couple of other sections on this screen before you launch into your lab:


Check out the DocumentationSession Details, and the Servers sections under your Topology section. Get used to working your way around these because later I’ll refer you to the Session Details section later.

Note:RedPoint Note the time remaining – if you actually manage to schedule more than five days, don’t believe it. Your session WILL end exactly five days later, even if you see that there are three hours to go.

But now it’s time to launch the lab.  The lab is conducted via a “Jump Box” – a session to a remote PC, and clicking on the Wkstn1 icon and selecting the Remote Desktop option. Note there are options to Power Off and Reboot the remote PC if you should get trouble.

However, the first thing you will probably want to do after launching the remote desktop is to expand the window that opens into full screen mode – some of those ACI configuration screens need a LOT of real-estate.

And this will lead you to your first problem: The screen doesn’t actually go full size – but not to worry, there is a solution (unless you still went ahead and used Internet Explorer in spite of my earlier warning).

After you have maximised your desktop, click in the grey area to the side of the login screen and choose Reload Page.


Your session will now be in full screen.  Log in using the user credentials given (dcloud\demouser password C1sco12345) and begin your lab.  You did download the pdf of the lab earlier didn’t you? If not, you can go back to your home page and click on the documentation section.  You’ll need it to find out the login details.

I’ll leave you to enjoy the lab yourself, but before I finish, I want to suggest that running a remote desktop session in a web browser may not give you the best user experience you can get from this site.

A better way to get to the remote desktop is to use Cisco AnyConnect. You can do this one of two ways.

The better way is to download and install the Cisco AnyConnect Client, but a good alternative is to use a SSL connection via your web browser.  In either case, you’ll have to return to your dcloud Home  page and select the Remote Session  section to get the login details you’ll need to make the connection.  This is also the place where you’ll find the link to the SSL login as well.


Note that you can share your login with up to 15 other users, each user has the same password, but a slightly different username of the form vNNNuser1..vNNNuser16

If you choose to use the web based SSL connection, you’ll have to have the latest versions of Java and the wind will need to be in the right direction and the gods smiling upon you. For me, the easier option is to install the VPN Client.

Once your connection is established, all you need to do now is open your Windows Remote Desktop client, and connect to the ip address shown next to yoru remote desktop in your Topology section.


Once you have saved your credentials and favourite screen settings in your Remote Desktop Client, accessing dcloud is a breeze forevermore!


But it doesn’t necessarily stop there.  I find I get the best performance via the RDP connection using my own RDP client and my own Cisco AnyConnect client, but there is yet another way.

Look at the IP address that you see when you access the AIPC in the remote lab:


So long as you are connected via your AnyConnect connection, and you have the password, you can log into this address on your own local browser. I actually find this less satisfactory than the RDP session, but it might suit you.  And I find Chrome more reliable than Safari.

remoteBrowser[Update: 2015-06-30]

Once you have logged into your lab, you might find it tedious swapping to and from your remote session to read the lab guide that you downloaded earlier – especially if you are operating in a full-screen remote desktop session.

So if this bothers you, open a browser in your remote session, and browse to and log in again in the remote session – and then you can download the .pdf of your lab instructions to your remote PC and keep it all in one place.

[End of update: 2015-06-30]

Enjoy your lab!


Note:  This is the first of a few articles I’m writing that relate to ACI. Watch this space for a a multi-stage tutorial on ACI

Posted in Cisco, Cloud, Cloud computing, Data Center, Data Centre | Tagged , , , , , , | 4 Comments

Best after sales support I’ve ever had. Thumbs up for Everki

So here is my backpack. I’ve cut the straps and destroyed it. It was the best backpack I’ve had in 20 years of lugging around a computer



So why did I cut the straps?

To answer that, have a look at another photo.


In this one you can see that the zipper on my backpack has broken :(

So what has that got to do with cutting the straps?

And to answer that, I’ll have to tell you about the support I got from Everki when I told them about the broken zipper.

I have a problem with my Beacon laptop bag. There is part of the zip that seems to have got out of step and missed a bit – and one of the fasteners has become detached. See attached photos.

Is this covered by my “Lifetime Warranty”? If so, what do I do next? I *THINK* I bought it directly from your online store.

BTW – I LOVE the bag – it has been the best bag I have EVER had (and I’ve been carrying a laptop almost daily since 1995)

What followed was a series of exchanges asking me to return the bag, me explaining that I couldn’t because I was travelling so much and so on – every step of the way I got fantastic understanding from Andrea and her supervisor to the point where I didn’t have to return the bag, just a) cut off the serial number, and b) cut the straps.

Here is the result:

2015-05-17 16.07.04



A brand new bag shipped to me in Australlia at no expense to me.

Thank you Everki, I love your product and I love your service even more. And a special thanks to Andrea who patiently took me through the process even when I send the wrong pictures!







Posted in GNS3 WorkBench