The last few months I have been busy with the migration from an outdated Cisco ACI environment to a brand new VMware NSX-T cluster. In the coming weeks I will make a few blogpost about this migration.

But let’s begin with the start. I will briefly explain how Cisco ACI works before I take you on my journey in this transition. [This is a simplification of how ACI works, but for this post it contains enough info. I’m not an Cisco ACI specialist so it’s maybe to basic for the real Cisco ACI end-bosses]

Cisco ACI is the micro segmentation solution offered by Cisco. The solution has many capabilities, but for this migration we only had to migrate the VMs which are located in the Cisco ACI environment.

All the ACI ESXi hosts were in a VMware vSphere cluster connected to a distributed switch which is managed by Cisco ACI. The VMs where al hosted on a FC SAN.

The picture below is the logical constructs present within ACI.

https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/aci-secure-adc-design-guide.html#CiscoACIoverview

In short; EPG (End Point Groups) are a logical construct of VMs. These EPGs are represented within vCenter/ESXi as an distributed portgroup. The communication between these EPG is arranged with a contract. A contract is a collection of protocols/ports.

So the contracts are the glue between EPG’s to create micro segmentation. An EPG can be a Consumer or a Provider. If you translate this to the NSX-DFW you can see them as described below;

  • Source is a EPG-Provider
  • Destination is a EPG-Consumer
  • Service is a Contract

In theory all the EPGs can exist within the same subnet these are named bridge domains in ACI. But as you can see in the picture below there can be more than 1 bridge domain, both with their own EPGs. If we take the picture below to the VMware side of things you would see 3 distributed portgroups within the distributed virtual switch.

To make things a little more complicated; A bridge domain is assigned to a VRF in this case VRF1. This VRF is assigned to a Tenant (in this case Prod). Each tenant has is own set of EPG, bridge domains and contracts.

https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/aci-secure-adc-design-guide.html#CiscoACIoverview

So to sum this up; you could have multiple tenants with multiple vrf’s containing multiple bridge domains with a collection af EPGs.

What to migrate

Now we have the basics outlined let’s tell you a little more about the current configuration of Cisco ACI with this customer.

Because there was already micro segmentation in place between the EPGs the main goal of this migration was to migrate as clean as possible from ACI to NSX without adjusting the firewall rules. Because the fundamental differences between ACI and NSX we had to be somehow creative to fix this.

Below a summarization of the things we needed to fix during the migration. I will only point out the points which are relevant.

  • VMs within the same EPG can communicate with each other (without contract)
  • Production and Acceptance have their own tenant thus their own contracts and EPGs
  • If the traffic is not send to an EPG in the same bridge domain the traffic is send to the firewall (l3-out EPG “External”
  • There were a few contracts which applies to all EPG
  • There is an DHCP relay configured for two bridge domain
  • A separate Heartbeat EPG for Windows clusters

So as you can see there are a few things which are not default to NSX. In my next post I will adres above points and the solutions we came up with.

The original article was posted on: www.ruudharreman.nl

Related articles

  • Cloud Native
  • Application Navigator
  • Kubernetes Platform
  • Digital Workspace
  • Cloud Infrastructure
  • ITTS (IT Transformation Services)
  • Managed Security Operations
  • Multi-Cloud Platform
  • Backup & Disaster Recovery
Visit our knowledge hub
Visit our knowledge hub
Ruud Harreman Virtualization Consultant

Let's talk!

Knowledge is key for our existence. This knowledge we use for disruptive innovation and changing organizations. Are you ready for change?

"*" indicates required fields

First name*
Last name*
Hidden