Cisco ACI migration options

April 19th 2018

CISCO ACI migration options

Hopefully, if you have arrived here and are reading this, you have also read our previous articles on what ACI is and what deployment options are available for you to consider.

The previous articles focused on how a new, greenfield fabric could be deployed. Some businesses may want to deploy ACI only for new applications, but the majority will want to migrate some, if not all of their existing applications to the new fabric to some extent.

With this in mind, you are now probably wondering how existing applications can be migrated between the existing network and the ACI fabric. We have seen a number of different ways to achieve this and will aim to cover most of these in this article.

Fortunately for the network engineers, consultants and designers out there, the common underlying concepts of a network are all still there within an ACI fabric. They might seem abstracted at first, but trust us, they are still there.

Before determining the exact migration strategy, an architectural question needs to be answered. Are we migrating to a ‘Network-Centric’ or an ‘Application-Centric’ model?

“What is difference between Network-Centric and Application-Centric?”

This is a common question we hear when talking to people about ACI and migrations. Honestly, from an underlying networking perspective there isn’t any difference. The network/application centric terminology provides a way to describe which elements need to be built within the ACI fabric and also which devices provide typical networking functions; e.g. default gateway, routing or security policy enforcement.

Network-centric approach

‘Network-Centric’ is an approach that allows your existing network architecture and flows (north, east, south, west) to remain the same, therefore offering the support teams a transition period to get to grips with the new terminologies used by an ACI fabric. For most companies, it brings a level of simplicity for ‘Day 1’ adoption. This includes the ability to easily migrate existing processes and procedures that often surround the network, such as security policy and network troubleshooting. This approach, depending on your design may or may not use a small subset of ACI contracts for connectivity within the fabric.

Typically, with a network centric approach, a one-to-one mapping between legacy network constructs (VLANs, SVIs and VRFs) and new ACI network constructs (EPGs, Bridge Domains and VRFs) is maintained for ease of adoption.

Application-centric approach.

An ‘Application-Centric’ design is often seen as a ‘Day 2’ adoption strategy. This approach presents a considerably steeper learning curve as it requires engineers and designers to have a solid understanding of how the ACI constructs relate and map together to provide network connectivity. It also requires an understanding of all of the tweaks and knobs that ACI offers to provide the segmentation of services. The biggest element of this approach is the use of contracts and potentially L4-L7 Service-Insertion (previously known as Service Graphing) to build your security policy for the North, South, East and West datacenter flows. This approach often also requires business processes and procedures to be redefined. One particular area of focus needs to be around the way new applications are requested and evaluated. From our experience, the update of the business processes and procedures can be as much work as the migration itself.

The most noticeable difference of the application centric design is how a number of EPGs can share a single bridge domain which leads to a requirement to provide/consume contracts between the EPGs before connectivity can be established.

Once the decision has been made as to whether the migration will be network or application centric and a detailed fabric/tenant architecture has been created, you have a couple of options to actually get you there.

Migration to application-centric deployment

The first adoption option, which is often seen as the simplest, is to build out a new ACI fabric either within your existing datacenter or a new one and simply connect it to your existing network.

This includes building new networks on new IP addressing for equivalent services. For example, the existing network may have a single vlan/subnet to host multiple management functions. This approach would provision new tenants, application profiles and EPGs to host new server instances for the existing functions.  The new application instances would be configured on the new addressing scheme. Once tested, services could be failed over to the new ACI based instances over time.

The most significant point here being that the original management vlan on the legacy network would be superseded by application specific EPGs within the fabric.

The obvious advantages to this is that it allows you to adopt an Application-Centric tenant architecture approach from ‘Day 1’ as you’ll have fresh compute infrastructure to build new environments on. This also allows you and your team(s) to gradually adopt and build on the new terminologies and concepts that come with an Application-Centric strategy. The main disadvantage to this approach is that both networks could run in parallel for a long time and with that often comes both hidden and visible costs. These include internal resource effort and vendor support and maintenance costs.

Migration to network-centric deployment.

The second adoption option, which most companies appear to be choosing is through the replacement of hardware due to end of life (EoL) announcements for the existing Nexus product lines. This often drives a Network-Centric tenant architecture approach from ‘Day 1’. The main advantage of this approach is the reuse of existing compute infrastructure and the fact that the cost of the fabric hardware is absorbed as a hardware refresh. The disadvantage to this approach is the time, resource and planning needed to migrate your existing infrastructure to the new fabric.

When the adoption of ACI within the datacenter is driven through hardware replacement there are fortunately, a number of migrations options available depending on your business and change management processes. These migration options are generally made simpler when adopting a Network-Centric tenant architecture.

Network-Centric Migration Option One

If you are fortunate enough to already have ACI capable Nexus devices operating in NXOS mode, then you have the ability to repurpose existing switches and begin a gradual migration to ACI. It is recommended to purchase at least one spine and leaf switch pair operating in ACI mode to start the migration but would be dependent on your existing business requirements. The disadvantage of this migration option is that it is quite intrusive, requires a lot of planning to execute efficiently and may bring additional cost.

The first step is to deploy an APIC cluster and new ‘ACI Ready’ Leaf and Spine switches (swing equipment) within your Datacenter and connect them to your existing network. Once everything is installed and connected you can begin provisioning your new fabric, and describe your existing network using a network-centric approach and mapping the EPGs to the links connected to your old network.

Once everything is installed and connected you can begin provisioning your new fabric, and describe your existing network using a network-centric approach and mapping the EPGs to the links connected to your old network.

You are now ready to start converting and importing your existing ‘ACI Capable’ access switch hardware running in NXOS mode into the new fabric. The first step is to pre-stage the port configurations and hardware in the fabric. You will then need to either reload one or both (depending on your change processes) of the switches in the identified switch pair and migrate the uplinks to the Spine switches. If you are rebooting one switch at a time, you will need to ensure that all servers are configured with either NIC teaming or using an LACP bundling option and configurations are consistent across the NXOS configurations for failover to occur successfully.

You will need to repeat the pre-staging of configuration and the rebooting of existing access switch hardware running NXOS into ‘ACI Ready’ switches.

Now that all of your access switches have been converted to ‘ACI Ready’ switches and are successfully forwarding traffic for your attached endpoints. The next step is to connect your fabric to the existing external services. There are a number of ways to achieve this, which will ultimately come down to your existing requirements.

The next step is to migrate the gateways from the existing distribution block to the fabric and make use of the anycast (pervasive) gateway feature.

Once all of your default gateways have been migrated to the fabric, you are ready to convert your existing distribution switches from ‘ACI Capable’ to ‘ACI Ready’ the same as we did for the access switches.

Your migration is now complete.

Network-centric Migration Option Two

The second migration option requires the addition of a new ACI fabric alongside your existing network infrastructure and connecting them together at ‘Layer 2’ and/or ‘Layer 3’. This is generally where choosing a ‘Network-Centric’ migration approach works best as it gives your support engineers a nice consistent end-to-end mapping of network terminology throughout the migration. The main advantage of this approach is that it provides you with the flexibility to migrate workloads as and when business lines agree. Our engineers have seen that due to the time it takes to achieve a full datacenter migration, the number of free ports is often attractive to new projects which increases the rate of deployment. Therefore, the initial ACI fabric port count and purchase often doesn’t always factor in the element of organic growth between the start and finish of the migrations.

There are a number of options for connecting an ACI fabric and an existing network together at ‘Layer 2’. All of which come with their own considerations and largely depend on the appetite for change and planned downtime of the business.

The first L2 option is called ‘Network-Stitching’. This simply provides a ‘Layer 2’ trunk between the fabric and your existing network. The main consideration here is around spanning-tree topologies and controlled outages for the migration of gateways from routed interfaces.

The second option is using ‘Network Stitching’ with ‘OTV’. This provides the ability to extend L2 across an IP network and is often attractive when you want to migrate workloads to a new ACI fabric located in a new physical location. This option gives you the ability to simply migrate workloads between physical locations and then use a planned outage to migrate gateways from your old network to the fabric.

Alternatively, as our engineers have experienced first-hand, this option also provides the ability to provide FHRP in addition to spanning-tree isolation within the same or separate physical datacenter locations. This allows you to co-exist the same gateways on the old network infrastructure as well as the new ACI fabric. This also offers minimal downtime for workload migrations and appliance role-swaps, all whilst optimising forwarding from the local breakout, providing isolation for routing and spanning-tree computations.

The main thing to remember is that the option you choose is the one that is right for your business. Within many organisations, migration strategies will not always be driven solely by technological elements. There are a number of non-technical factors that will need to be met to allow businesses to operate. These include; business uptime (service availability), budgets, willingness to adopt new technologies (risk vs reward) and project timelines.

Try to keep it as simple as possible based on your constraints. It is also important to remember that some of these use-cases come with additional considerations depending on how your existing network is setup. We have tried to highlight the main focus points that you might encounter but it is hard to provide a conclusive list until you start the process.

BestPath have the ability to assist with ACI migration activities or planning. We have access to tools that can perform discovery of your existing datacenter to identify services that need to be migrated and also automate the deployment of your fabric configuration.

BestPath.

BACK TO BLOG

More