ACI Application Centric Deployment (ACD) and Subnet Sharing with Route Leaking

1. Overview

In Cisco ACI, a powerful feature called route leaking enables applications and services to communicate seamlessly across Virtual Routing and Forwarding (VRF) instances. This allows for efficient data flow within the network infrastructure, even when applications reside in separate VRFs for security or isolation purposes. Route leaking achieves this by sharing routing information between VRFs, while still maintaining the necessary security boundaries.

In Cisco ACI, the route leaking technique can be used to address various use cases:

1. Shared services in a Network Centric Deployment model (one BD (subnet) = one EPG)
2. Shared service in an Application Centric Deployment model (one BD (subnet) = multiple EPGs)
3. Shared L3out
4. Shared services /L3out with ESG

In this blog, we’ll delve into shared services within an Application Centric Deployment model (one Bridge Domain = multiple Endpoint Groups). Stay tuned for future discussions on the remaining options! 

Shared services in a Network Centric Deployment model (one BD (subnet) = one EPG)

https://community.cisco.com/t5/data-center-and-cloud-blogs/cisco-aci-inter-vrf-tenant-route-leaking-design-simplified/ba-p/3820919

2. Benefits and Drawbacks of Route Leaking in ACI

• Reduce routing devices involved in a multiple VRF environment
• Optimize network performance by enabling direct communication between Virtual Routing and Forwarding (VRF) instances, bypassing external paths
• Manual configuration in large deployments can lead to accidental route leaks, potentially disrupting network traffic. Mitigate this risk by leveraging automation tools and employing stricter configuration controls
• Route leaking can increase the complexity of network security policies, as communication across VRFs needs careful control
• Troubleshooting and managing large-scale route leaking deployments can be complex. Implementing clear documentation, monitoring tools, and standardized configurations can help alleviate these challenges

For optimal network performance in multi-VRF environments, Cisco ACI’s route leaking offers a powerful approach. However, to fully leverage its potential, a thorough understanding of its advantages and potential drawbacks is crucial during the design phase. By carefully evaluating your specific deployment requirements, you can tailor your network architecture to maximize the benefits of route leaking while mitigating associated risks.

3. Logical Lab Topology

Tenant, VRF, BD, BD subnets, AP, EPG and contracts are pre-configured as shown on the lab topology view.

1. All EPGs in VRF-1 used in the lab scenario are configured to use the same bridge domain (BD-1 with subnet 172.16.0.0/23)
2. All EPGs in Shared-Services used for the lab scenario are configured to use the same bridge domain (Shared-BD with subnet 192.168.0.0/23)
3. Both VRF-1 and Shared-Services vrfs are part of the same tenant, Tenant-1

The goal is to configure route leaking so that EPGs in VRF-1 can access shared services (Syslog, NTP, DNS, and SNMP) homed in Shared-Services VRF.

4. Configuration Steps

The configuration steps are:

• Configure the provider and consumer side subnets with ‘Shared between VRFs’ scope checked
• Make sure the contract scope is appropriately configured for all contracts required for the communication between the EPGs. For inter-VRF in the same tenant, contract scope can be application (if EPGs are under same application profile), tenant or global.

4.1 Configuring subnet under the providers EPG

In Cisco ACI’s Application Centric Deployment (ACD) model, where multiple Endpoint Groups (EPGs) share a single Bridge Domain (BD) and subnet, adding the subnet directly to a multiple provider EPGs is not allowed, as illustrated in the screenshot. As you experienced, attempting to add the same subnet to another EPG (App2-EPG) results in a “duplicate IP subnet” error. This confirms that the network centric deployment approach of route leaking, adding subnet on the provider EPG doesn’t work in ACD.

For route leaking between EPGs in an ACD model, you need to leverage provider-consumer contracts applied on both side of the communication. These contracts establish a communication channel between EPGs, allowing contracts on the provider EPG consumed by the consumer EPG and vise versa. This approach ensures controlled and secure communication between consumer and shared services.

4.1.1 Provider contract for EPGs in VRF-1 (Consumer VRF)

In a typical Cisco ACI setup, a Shared Services Virtual Routing and Forwarding (VRF) acts as the provider, offering services to other VRFs like VRF-1. To enable route leaking in ACD model and allow EPGs within VRF-1 to consume these services, we’ll follow the below approach:

• We’ll create a dummy contract on the consumer VRF (VRF-1). EPGs needing access to Shared Services will use the dummy contract as a provided contract. The EPGs in shared services vrf consume the dummy contract.

Once the dummy contract above in red (Leaking-any-1-ct) is applied, the class ID changed from private range to global range and route is leaked from the Shared Services VRF with class ID 0.

LEAF-102# show ip route vrf Tenant-1:VRF-1 
IP Route Table for VRF "Tenant-1:VRF-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

172.16.0.0/23, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.1.216.66%overlay-1, [1/0], 00:11:23, static, rwVnid: vxlan-2097157
172.16.0.1/32, ubest/mbest: 1/0, attached, pervasive
    *via 172.16.0.1, vlan98, [0/0], 1d14h, local, local
192.168.0.0/23, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.1.216.66%overlay-1, [1/0], 00:19:58, static, rwVnid: vxlan-3112968

LEAF-102# vsh -c 'show ip route 192.168.0.0/23 detail vrf Tenant-1:VRF-1'
IP Route Table for VRF "Tenant-1:VRF-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.0.0/23, ubest/mbest: 1/0, attached, direct, pervasive, dcs
    *via 10.1.216.66%overlay-1, [1/0], 00:22:23, static
         recursive next hop: 10.1.216.66/32%overlay-1
         vrf crossing information:  VNID:0x2f8008 ClassId:0 Flush#:0

4.1.1 Provider contract for EPGs in Shared Service VRF and consume it in VRF-1 (Consumer VRF)

This contract is the contract needed to consume the shared services by a consumer VRF (VRF-1).

LEAF-102# vsh -c 'show ip route 172.16.0.0/23 detail vrf Tenant-1:Shared-Services'
IP Route Table for VRF "Tenant-1:Shared-Services"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

172.16.0.0/23, ubest/mbest: 1/0, attached, direct, pervasive, dcs
    *via 10.1.216.66%overlay-1, [1/0], 00:00:42, static
         recursive next hop: 10.1.216.66/32%overlay-1
         vrf crossing information:  VNID:0x200005 ClassId:0 Flush#:0x1

5. Verification

The ping verification test is executed based on the host configurations within each Endpoint Group (EPG) in the provided representation.

• 172.16.0.10 should ping 192.168.0.10,30,&40
• 172.16.0.20 should ping 192.168.0.10,30,&40
• 172.16.0.30 should ping 192.168.0.20,30,&40
• 172.16.0.30 should ping 192.168.0.20,30,&40

About