By: Jody
The vast majority of ACI customers do not start out with an Application Centric deployment of ACI; mainly because they do not have a clear understanding of their applications and the vast amount of interdependencies.
However, with the advent of Tetration and other 3rd party analytics tools, the knowledge about how your applications are connected is increasing and customers are looking to migrate some apps from the “Network-Centric approach (Vlan=EPG=BD) to a full ACI-Centric model.
Let me be clear; The Network-Centric model serves many customers well. It allows them to migrate their existing compute/applications/network into ACI in a way that is familiar and well understood.
Customers operating their fabrics in a Network-Centric model continue to gain numerous benefits from ACI, such as Single Pane of Glass management from the UI, elimination of box-by-box mgmt of the entire data center, the ability to upgrade the entire fabric (APICS+Switches) from one location with ease, decreased time to resolution during issues due to the availability of consolidated faults and health scores, etc.
However, for those customers who want to take their ACI deployment to the next level, moving applications into an ACI-Centric Model is one of the next logical steps.
Below, we will discuss a sample methodology for moving applications into an ACI-Centric Model.
Here are 8 assumptions before we begin:
1) This document assumes that the customer has the data needed to build out the application profiles for their ACI-Centric application.
2) This data can be obtained in several manners, such as:
- Application Dependency mapping via Cisco Tetration Analytics
- Cisco Advanced Services ANP Analysis Service
- Customer knowledge of applications
- 3rd party tools
3) Network Centric Mode is currently used (Network-centric means 1 vlan = 1 bd = 1 epg)
- All legacy vlans that will be a part migrated to the ACI-Centric application exist on the fabric (or will be operational prior to the migration to aci-centric implementation).
- All legacy vlans exist on the L2 trunk between the Legacy network and ACI fabric
- New ACI-Centric Vlans will live exclusively inside of ACI (do not extend the ACI-centric vlans outside of ACI)
4) VMM Integration to the ACI Fabric must be completed before moving VMs from the Legacy network to the ACI Fabric. Pre-work includes, but not limited to, installation of additional connectivity from FIs to the ACI Fabric, configuration of ESXi vnics, and OOB connectivity.
5) L2 connectivity traffic between the ACI Fabric and Legacy network should be monitored before, during and after migration.
6) All L3GW functionality for applications will migrate from the Legacy network to the ACI Fabric prior to activation of ACI-Centric EPGs.
7) EPG to EPG communication is a permit any. << Highly recommended; Contracts for ACI Centric-mode should be configured last
8) DHCP Labels are created prior to migration
Here are 10 generic migration guidelines.
The following guidelines should be followed when migrating applications to the ACI Fabric.
1) Map existing Vlans into ACI in Network-Centric Mode (L2 only – no contracts)
Create legacy EPGs and BDs on the ACI Fabric. BDs will be initially created as L2. L3GW functionality will remain on the legacy network until after L3GW Migration.
2) L2 BD configurations – For each of your bridge domains, it is recommended that they are configured with the following:
- IP Subnet check is enabled
- Flood is enabled (for migration)
- ARP flooding is enabled (for migration)
- BD is associated with respective VRF and L3out
- Unicast Routing is DISABLED at the BD level
- IP address and VMAC are configured on the BD
3) Create static bindings for the Legacy EPGs on the L2 trunk between the ACI Fabric and Legacy network
4) Identify list of servers (both bare-metal and VMs) present in the legacy network that will be migrated to ACI.
5) Create L3out for Tenant and establish routing availability from ACI to legacy environment
6) Migrate L3GWs for legacy Vlans into ACI Fabric
Validate routing from inside the ACI Fabric and outside of the ACI Fabric.
7) Create New Application Profile and EPGs from application data analysis
- Associate New EPGs with the proper BDs
- Associate new EPGs with the proper VMM Domains for VMs
- Configure static bindings for Physical devices
8) Migrate Servers – Servers associated with the various application will move to the ACI Fabric and be associated with the specific EPG designated based on the output of the data analysis.
- Bare Metal
- VMs
9) Deploy ACI-centric contracts (optional)
10) Perform Cleanup
- Remove unneeded EPGs
- Remove L2 connections to legacy environments (once all migration of services is completed)
Here’s a sample migration of the application “NewApp” to an ACI-Centric Model.
The diagrams below represent a “story-board” approach of how we would migrate an application into ACI.
Network-Centric Mode
In general, I would recommend the “crawl/walk/run” approach to ACI deployments. For the application below, there are different components spread across (3) different Vlans, vlan 5, 6, and 7. So the first step (crawl) is to migrate these Vlans in the ACI-fabric in a network-centric approach, meaning that we will implement an approach where Vlan=EPG=BD.
L3GW Migration
Once we have all of the L2 Vlans available on ACI (EPG/BDs are created, and an L2 trunk is configured between ACI and the Legacy environment), we can then migrate the L3GW services to ACI. This involves creating a L3out (External Routed Network) from ACI to the outside network, and then migrating each Vlan/Subnet to ACI, one at a time.
ACI-Centric component creation
Now that we have L3GW functionality, we are fully operating in a Network-Centric model for our Vlans. Next, assuming we have the data that shows us how to deploy our application in ACI-Centric mode, we will take that data and configure our new Application Profiles, EPGs, and Contracts (to be used later) into ACI.
Server Migration into new ACI-Centric EPGs
Now that we have EPGs built for our ACI-Centric Application, we can begin moving servers (both bare-metal and virtual) into the EPGs. This also serves as an opportunity to determine if we need to remove unneeded EPGs (i.e., EPGs with no endpoints) from the fabric.
Decommission of Legacy components
Once all endpoints have been removed from a legacy network-centric EPG, such as Vlan5_EPG, it can be deleted. Additionally, once all servers have been migrated off of the legacy infrastructure, the L2 trunk between ACI and the Legacy network can be decommissioned.
A couple of caveats…
- DHCP relay is only available on the primary subnet for a BD; if multiple subnets are needed on a BD, keep this in mind, as DHCP relay will only be forwarded to a DHCP server on the primary subnet
- Do not combine multiple external Vlans into one ACI BD and extend those vlans outside of ACI. Consider the case where you have two legacy Vlans (Vlan 11 and Vlan 12) with HSRP configured, and L3GW functionality on the non-ACI equipment. The HSRP hellos from both Vlan 11 and Vlan 12 would be visible to each and result in problems.
And that wraps up today’s blog! But more to come on ACI right here on the ACI Board on Cisco Community.
In the meantime, please drop a comment and let us know if this migration piece was helpful. Feel free to even comment in ACI topics you’d like to see discussed here in the near future!
1 Comment
