1. ACI Route Leaking Overview
Route leaking is one of the key features of Cisco ACI, which allows routes to be shared between Virtual Routing and Forwarding (VRF) instances within the same tenant or across different tenants.
In Cisco ACI, the route leaking technique can be used to address various use cases:
- Shared services in a Network Centric Deployment model
- Shared service in an Application Centric Deployment model
- Shared L3out
- Shared services /L3out with ESG
Cisco ACI’s route leaking technique provides a powerful mechanism for sharing routes between VRFs, in the same tenant or across different tenants, allowing for enhanced connectivity and flexibility between applications and services, while maintaining the necessary security and isolation requirements.
This blog focuses on the first one – Shared services in a Network Centric Deployment model (one BD (subnet) = one EPG) . The other options will be discussed on upcoming blogs.
2. Benefits and Drawbacks of Route Leaking in ACI
- Reduce routing devices involved in a multiple VRF environment
- Improve network performance by avoiding traffic to use outside path for inter-VRF communication
- Accidental route leaking can happen if manual configuration is used in a scaled environment
- May increase the complexity of network security policies
- Troubleshooting and operation can get complex with scaled environment using route leaking
So, it is critical to understand the pros and cons of this (ACI route leaking) powerful feature during the design phase to get the most out of it based on the unique requirements of the specific deployment.
3. Logical Lab Topology
Tenant, VRF, BD, BD subnets, AP, EPG and contracts are pre-configured.
4. Configuration Steps
4.1. Provider BD, EPG and Contract
- Configure the provider side subnet at the provider EPG
- Make sure the contract scope is global since it is route leaking cross tenant. For inter-VRF in the same tenant, contract scope tenant or global works.
- Export the provider tenant (Tenant-2) side contract to consumer tenant (Tenant-1)
Configure subnet under the provider EPG with scope ‘Advertised Externally’ (if the subnet needs to be advertised externally) and ‘Shared between VRFs’. ‘No Default SVI Gateway’ subnet control need to be checked to avoid creating additional SVI for the subnet.
The scope of the contract used for the route leaking between subnets in different tenant should be global.
Export the contract from the provider tenant (Tenant-2) to the consumer tenant (Tenant-1) for inter-VRF communication in different tenants.
4.2. Apply Contract (Provider / Consumer)
Contract on the consumer tenant EPG is applied as contract interface using the contract exported from the provider tenant.
5. Verification
5.1. Routing table
The leaked subnet on the consumer tenant/VRF shows with classID of the provider EPG (pcTag 36). The classification on the consumer VRF for the leaked route is based on the subnet. Any communication to the provider subnet on the consumer tenant/VRF is treated as mapped to one EPG. So this route leaking method has limitation with application centric deployment model (one BD/subnet with more than one EPG). The next blog – ‘ACI Route leaking – Shared Services (Application Centric Deployment)’, will cover route leaking method for application centric deployment models.
To identify the VRF name from the VNID, query the APIC for fvCtx object and filter based on the segment ID or scope.
5.2. Zoning rule in each VRF
Inter-VRF traffic policy enforcement happens on the consumer VRF. The provider VRF (Figure 9) has an implicit zoning-rule to permit inter-VRF traffic from the provider EPG (pcTag 36) to pcTag 14 (the system-reserved class ID for inter-VRF traffic). With the implicit zoning rule, the provider-to-consumer traffic is permitted at the provider VRF without “policy applied bit” set. Inter-VRF contract modify the class-ID (pcTag) of the provider EPG to 36, a public defined range (16-16384).
The consumer VRF has an implicit zoning rule to deny traffic from the provider EPG to any with a priority of 12. Rule ID: 4110 denies traffic from the provider EPG (pcTag 36) to any with priority 12. Rule ID: 4296 allows traffic between provider EPG with pcTag 36 and consumer EPG with pcTag 32773 based on contract – ‘Leaking-permit-any’.
5.2. Ping check
Ping from endpoint in the provider EPG to endpoint in the consumer EPG
Ping from endpoint in the consumer EPG to endpoint in the provider EPG
https://deliabtech.com/data-center/aci-contract-priority/