The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This is the most basic Cisco ACI Multi-Site use case, in which a tenant and VRF are stretched between sites. The EPGs in the VRF (with their bridge domains (BDs) and subnets), as well as their provider and consumer contracts are also stretched between sites.
In this use case, Layer 2 broadcast flooding is enabled across fabrics. Unknown unicast traffic is forwarded across sites leveraging the Head-End Replication (HER) capabilities of the spine nodes that replicate and send the frames to each remote fabric where the Layer 2 BD has been stretched.
This use case enables:
Same application hierarchy deployed on all sites with common policies. This allows seamlessly deploying workloads belonging to the various EPGs across different fabrics and governing their communication with common and consistent policies.
Layer 2 clustering
Live VM migration
Active/Active high availability between the sites
Using Service Graphs to push shared applications between sites is not supported.
Prerequisites for this Use Case
Sites have been added, APIC controllers are active, and communications are established.
The tenant to be stretched has been created.
The Multi-Site Site and Tenant Manager account is available
Configuration |
Description |
Stretched or Local |
---|---|---|
Tenant |
Imported from APIC or created in Multi-Site |
Stretched |
Network Mappings of Site L3Outs |
Configured in the APIC GUI and linked in the stretched tenant |
Local, but linked to other sites |
VRF |
VRF for the tenant |
Stretched |
Bridge Domain |
Layer 2 stretching enabled Layer 2 flooding enabled Subnets to be shared added |
Stretched |
EPGs |
EPGs in the BD |
Stretched |
Contracts |
Include the filters needed to govern EPG communication |
Stretched |
This Cisco ACI Multi-Site use case is similar to the first use case where a tenant, VRF, and their EPGs (with their bridge domains and subnets) are stretched between sites.
However, in this use case, Layer 2 broadcast flooding is localized at each site. Layer 2 broadcast, multicast and unknown unicast traffic is not forwarded across sites over replicated VXLAN tunnels.
This use case enables:
Control plane overhead is reduced by keeping Layer 2 flooding local
Inter-site IP mobility for disaster recovery
"Cold" VM Migration
Using Service Graphs to push shared applications between sites is not supported.
Prerequisites for this Use Case
Sites have been added, APIC controllers are active, and communications are established.
The tenant to be stretched has been created.
The Multi-Site Site and Tenant Manager account is available
Configuration |
Description |
Stretched or Local |
---|---|---|
Tenant and VRF |
Imported from APIC or created in Multi-Site |
Stretched |
Network Mappings of Site L3Outs |
Configured in the APIC GUI and linked in the stretched tenant |
Local, but linked to other sites |
Bridge Domain |
Layer 2 stretching enabled Layer 2 flooding disabled Subnets to be shared added |
Stretched |
EPGs |
All EPGs in the BD |
Stretched |
Contracts |
Include whatever filters and contracts are needed to govern EPG communication |
Stretched |
This Cisco ACI Multi-Site use case provides endpoint groups (EPGs) stretched across multiple sites. Stretched EPG is defined as an endpoint group that expands across multiple sites where the underlying networking, site local, and bridge domain can be distinct.
This use case enables Layer 3 forwarding to be used among all sites.
Prerequisites for this Use Case
Sites have been added, APIC controllers are active, and communications are established.
The relevant tenants have been created.
The Multi-Site Site and Tenant Manager account is available
A physical domain and VMM domain must exist on APIC.
Configuration |
Description |
Stretched or Local |
---|---|---|
Tenant, VRF and EPGs |
Imported from APIC or created in Multi-Site. |
Stretched |
Network Mappings of Site L3Outs |
Configured in the APIC GUI and linked in the stretched tenant |
Local, but linked to other sites |
Bridge Domains (DBs) |
Layer 2 stretching disabled. |
Stretched |
Subnets |
Unique for each BD on the local site. |
Local |
Contract |
Contracts configured on site where they are provided |
Local |
This Multi-Site use case provides inter-site communication between endpoints connected to different Bridge Domains (BDs) that are part of the same stretched VRF. VRF Stretching is a convenient way to manage EPGs across sites (and the contracts between them).
In the diagram above, the App-EPGs provide the C1 and C2 contracts across the sites, and the Web-EPGs consume them across the sites.
This use case has the following benefits:
The tenant and VRF are stretched across sites, but EPGs and their policies (including subnets) are locally defined.
Because the VRF is stretched between sites, contracts govern cross-site communication between the EPGs. Contracts can be consistently provided and consumed within a site or across sites.
Traffic is routed within and between sites (with local subnets) and static routing between sites is supported.
Separate profiles are used to define and push local and stretched objects.
No Layer 2 stretching and local Layer 2 Broadcast domains.
“Cold” VM migration, without the capability of preserving the IP address of the migrated endpoints.
Using Service Graphs to push shared applications between sites are not supported.
Prerequisites for this Use Case
Sites have been added, APIC controllers are active, and communications are established.
The tenants to be stretched have been created.
The Multi-Site Site and Tenant Manager account is available.
Configuration |
Description |
Stretched or Local |
---|---|---|
Tenant and VRF |
Imported from APIC or created in Multi-Site |
Stretched |
Site L3Outs |
Configured in local site APIC GUI and linked in the stretched tenant |
Local |
EPGs providing contracts |
EPGs for each site that provides services. |
Local |
EPGs consuming contracts |
EPGS that consume the provided contracts, may be in the same site or multiple sites |
Local |
Bridge Domains for each EPG |
Layer 2 stretching disabled Layer 2 flooding disabled |
Local |
Contracts |
Contracts configured on site where they are provided |
Local, but shared |
In this use case, the Provider EPGs in one group of sites offer shared services and the EPGs in another group of sites consume the services. All sites have local EPGs and bridge domains.
In the diagram above, Site 4 and Site 5 (with BigData-EPG, in Tenant BigData/VRF BigData), provides shared data services, and the EPGs in Site 1 to Site 3, in Tenant 1/VRF 1, consume the services.
In the Shared Services usecase of Multi-Site, at the VRF boundary routes are leaked between VRFs for routing connectivity and by importing contracts across sites.
This use case has the following benefits:
Shared services enable communications across VRFs and tenants while preserving the isolation and security policies of the tenants.
A shared service is supported only with non-overlapping and non-duplicate subnets.
Each group of sites has a different tenant, VRF, and one or more EPGs stretched across it.
Site groups can be configured to use Layer 2 Broadcast extensions or to localize Layer 2 flooding.
Stretched EPGs share the same bridge domain, but the EPGs have subnets that are configured under the EPG, not under the bridge domain.
The provider contract must be set to global scope.
VRF route leaking enables communication across the VRFs.
Using Service Graphs to push shared applications between sites is not supported.
Prerequisites for this Use Case
Sites have been added, APIC controllers are active, and communications are established.
The relevant tenants have been created.
The Multi-Site Site and Tenant Manager account is available
This is a common Cisco ACI Multi-Site use case, in which a tenant is migrated or imported from Cisco ACI fabric to Cisco ACI Multi-Site.
This use case is targeted for Brownfield to Greenfield and Greenfield to Greenfield types of deployments. The Brownfield to Brownfield use case is only supported in this release if both Cisco APIC sites are deployed with the same configuration. Other Brownfield to Brownfield use cases will be deployed in a future Cisco ACI Multi-Site release.
Note | Cisco ACI Multi-POD migration to Cisco ACI Multi-Site will be supported in a future Cisco ACI Multi-Site release. |
For Brownfield configurations, two scenarios are considered for deployments:
A single pod ACI fabric is in place already. You can add another site in a multi-site configuration.
Two ACI fabrics are in place already (Each fabric is configured as a single pod), the objects (tenants, VRFs, and EPGs) across sites are initially defined with identical names and policies, and they are connected leveraging a traditional L2/L3 DCI solution. You can convert this configuration to multi-site as explained in the following configuration diagram:
This use case enables:
Same application hierarchy deployed on all sites with common policies.
Layer 2 clustering
Prerequisites for this Use Case
The sites have been added, the APIC controllers are active, and communication is established.
The tenant to be stretched has been created.
The Cisco ACI Multi-Site Site and Tenant Manager account is available.
Configuration |
Description |
Stretched or Local |
---|---|---|
Tenant |
Create a tenant in Multi-Site and import the tenant policies from APIC |
Stretched |
VRF |
VRF for the tenant |
Stretched |
Bridge Domain |
Layer 2 stretching enabled Layer 2 flooding enabled Subnets to be shared added |
Stretched |
EPGs |
EPGs in the BD |
Stretched |
Contracts |
Include the filters needed to govern EPG communication |
Stretched |