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.

Figure 1. Stretched Bridge Domain with Layer 2 Broadcast Extension

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

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.

Figure 2. Stretched Bridge Domain with No Layer 2 Broadcast Extension

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

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.

Figure 3. Stretched EPG Across Sites

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.

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).

Figure 4. VRF Stretching with Inter-site Contracts

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.

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.

Figure 5. Shared Services with Stretched Provider EPG

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:

Figure 6. Migration of Cisco ACI Fabric to Cisco ACI Multi-Site

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.