ACI Multi-site Object Naming Consideration

Overview

ACI multi-site uses inter-site network (ISN) for communication between data center sites. Contract is used to define the communication requirement between EPGs. When contract with the right scope is applied between site-local EPGs, the ACI objects are mirrored on the remote sites. The mirrored objects appear as if they are deployed in each of these site’s controllers, while only actually being deployed in one of the sites. These mirrored objects are called “shadow” objects and they appear with the same names as the ones that were deployed directly to each site. Because of the shadow objects requirement for inter-site communication between site-local EPGs, this blog focuses on ACI multi-site object naming consideration an engineer need to be aware of.

To learn more about contracts

Example,

• A tenant is stretched between Site1 and Site2
• EPG-1, VRF-1 and BD-1 are deployed in Site1 only
• EPG-2, VRF-2 and BD-2 are deployed in Site2 only
• Corresponding shadow VRFs, bridge domains and EPGs will be deployed as shown in the figure below. Due to the shadow ACI objects, it’s unequivocally important to design the naming of ACI objects to avoid a conflicting names when there is a need to communicate between EPGs in different sites.

Inter-Site Communication Use cases

1. Stretched tenant, VRF, BD, and site-local EPGs

When there is a need for communication between site-local EPGs both sharing a stretched tenant, VRF, and BD, the APP/EPG name combination should be unique.

Trying to deploy site-local EPGs with the same AP/EPG name combination and provider/consumer contract will result with the following error message.

Error message when the same AP/EPG name is pushed to SITE-2 - 'Template deploy failed: Duplicate name for different objects in different templates is not allowed: AP: AP1-1 EPG: EPG-1 is already deployed by schema: B-tenant1 - template: Template1-1 on site SITE-1'

2. Stretched tenant and VRF with site-local BDs and EPGs

When there is a need for communication between site-local EPGs associated with site-local BDs and sharing a stretched tenant and VRF, the BD name and APP/EPG name combination should be unique.

Trying to deploy site-local BDs with the same name will result with the following error message.

Error message - 'Template deploy failed: bd type BD-1 from template Template1-1 in schema B-tenant1 must be deployed on site SITE-2 before epg type EPG-1 can be deployed on the site. Ensure bd type BD-1 is defined on a template associated also to site SITE-2'

3. Stretched tenant with site-local VRFs, BDs and EPGs

When there is a need for communication between site-local EPGs associated with site-local VRFs, BDs and sharing a stretched tenant, the VRF and BD names and APP/EPG name combination should be unique. This is a shared services scenario where contract is used to leak routes for data flow and policy enforcement at the same time. Contract should be defined with tenant or global scope.

The BD subnets have to be unique to avoid address conflict during route leaking.

Trying to deploy site-local VRFs with the same name will result with the following error message.

Error message - 'Template deploy failed: Duplicate name for different objects in different templates is not allowed: vrf: VRF1 is already deployed by schema: B-tenant1 - template: Template1-1 on site SITE-2'

4. Site-local tenants, VRFs, BDs and EPGs

This use case is when each site has it’s own tenant, VRF, BD, APP/EPG. Contract is defined on the provider tenant with global scope and should be deployed on both sites.

The tenant name has to be always unique, but the VRF, BD, AP, and EPG can be the same. Unique VRF, BD, AP and EPG in each site can have a positive impact on operational and troubleshooting efforts as the environment grow in size and complexity. The BD subnets have to be unique to avoid address conflict during route leaking.

The following picture show some of the naming combinations that are not supported (you can’t create the same site-local tenant name) and that are supported.

Cisco Multi-Site Deployment Guide for ACI Fabrics

About