Inter-VRF Leaking and Shared services in ACI

I- EPG to EPG

• Option1: Subnet Under Provider EPG

In the case of inter-VRF contracts for EPG-to-EPG or EPG-to-L3Out (with 3Out EPG as the provider), the consumer VRF enforces contract policies.

Whereas consumer EPG classification is done at the consumer VRF just like with intra-VRF contracts, the derivation of the provider EPG class ID from the consumer VRF is based on looking up the subnet, because the consumer VRF always need to enforce policy regardless of the endpoint’s learning status.

Since the Provider subnet is tied to the EPG, The Class id (pctag) of the provider EPG is leaked along with VRF VNID rewrite info to the consumer VRF:

vsh
show ip route vrf  PROD:PROD 172.31.50.200 detail
...
   vrf crossing information:  VNID:0x218001 ClassId:10945 Flush#:0x1

Since the provider EPG class ID needs to be at another VRF, the provider EPG class ID uses a number from the global class ID range in order to avoid class ID conflict in the consumer VRF. The class ID allocation range is as follows:

• System-reserved: 1 —> 15.

• Global allocation range: 16 —> 16384 for inter-VRF provider EPGs. (The ID is unique per ACI fabric.)

• Local allocation range: 16385 —> 65535 for VRF scoped EPGs. (The ID is unique per VRF.)

Zoning rules:

• The consumer VRF has zoning rules to permit consumer-to-provider and provider-to-consumer traffic. An implicit deny rule is also created in the consumer VRF to deny traffic from the provider EPG to any. This is done so that the provider EPG can’t talk to any endpoints in the consumer VRF unless a contract is configured.
  

• The provider VRF has an implicit zoning-rule to permit inter-VRF traffic from the provider. This is done so that the provider-to-consumer traffic is permitted at the provider VRF without “policy applied bit” set and the policy is enforced at the consumer VRF. Class ID 14 is the system-reserved class ID for inter-VRF traffic.

• Option2: Subnet Under Bridge Domain

• The subnets subnet-1 and subnet -2 are leaked between VRF with VRF rewrite info but classId:0 which mean the subnet is not tied to the EPG, therefore, the classification can’t be done based on the provider EPG subnet similar to option:

vsh
show ip route vrf PROD:PROD 172.31.50.200 detail
                    ...
    vrf crossing information:  VNID:0x218001 ClassId:0 Flush#:0x1

• To classify the endpoint, a lookup is done in actual endpoint table which contains exact /32 host IPs and EPG information.
• When the Endpoint is classified, the policy is applied, since both VRF are consumer and provider, and zoning rules are programmed in both VRF.