VRF Route Leaking for Shared Services

VRF Route Leaking for Shared Services

When using the common tenant, the restriction was to keep all the applications at least in the same VRF.However, there are scenarios where although most of the applications are closed within its own VRF, a few applications have to be able to communicate across VRFs.In such scenarios, the VRF route leaking needs to be configured. Such requirements are not specific to ACI but sometimes seen in traditional routers as well.

Look at the following example where the EPG 1 in VRF 1 needs to communicate with EPG 2 in VRF 2.

For EPG 1 to be able to communicate with EPG 2, there are two things to consider.

1. Leak the subnets for EPG 1 and EPG 2 into each VRF for forwarding.

2. Allow the traffic with a contract for security

In Cisco ACI, both are accomplished via a contract. Configuring an appropriate contract between two EPGs in different VRFs implies subnets for these EPGs need to be leaked at the same time.

The appropriate contract here depends on the scope of contracts. By default, the scope of all contracts is set to VRF. In case, the VRF route leaking is required, the scope needs to be set to either global, tenant, or application profile. In case the two VRFs are in the same tenant, the scope tenant can be used. In case the two EPGs are in the same application profile in the same tenant, the scope application profile can be used. In the example of this section, the two VRFs and EPGs are in different tenants. Hence, it needs to be scope global.

The contract in a user tenant is not visible from other user tenants. Hence, you need to explicitly export the contract from the provider tenant to the consumer tenant. When exporting a contract to another tenant, the provider tenant must be the one that exports the contract. Or you could use a contract with a global scope from the common tenant to avoid exporting the contract.

On top of the contract configuration across VRFs, you need do two more following configurations so that APIC can tell which subnets for these EPGs need to be leaked:

• Enable “Shared between VRFs” on the BD/EPG subnet (pervasive gateway).
• Move the BD subnet (pervasive gateway) configuration under the EPG in the provider side.

With these settings, the final configuration will look like this:

The reason why the subnet needs to be configured under the EPG in the provider side is to avoid unnecessary route leaking. You can see this configuration in the scenario where BD 1 contains two subnets and each leak to different VRFs as EPG X and EPG 1 as the provider respectively. If the subnets are configured under BD 1, both subnets are leaked to both VRFs since “Shared between VRFs” are enabled on both.

On the consumer side, there is no strict requirement. You can configure the subnet with “Shared between VRFs” under either EPG or BD.

Also please note that even if the subnet is configured under the EPG, the subnet will be deployed as the pervasive gateway for the entire BD. There are no functional differences between EPG and BD subnet except for the leaking part. If there are other EPGs in BD 1 that need to use 10.10.10.1 as its default gateway, they can use it while the subnet is configured only under EPG 1.

The following steps show an example overview of the configuration for the VRF route leaking between EPG 1 in tenant 1 and EPG 2 in tenant 2:

---