Contract Scope Across Application Profiles
Tenant-Prod has application profile AP-Front with EPG-Web in VRF-Prod (BD 10.10.10.0/24) and AP-Back with EPG-App in VRF-Prod (BD 10.10.20.0/24). Contract Web-to-App is provided by EPG-App and consumed by EPG-Web. Its only subject has one filter entry: TCP, destination port 443, Apply Both Directions enabled, Reverse Filter Ports enabled. The contract scope is Application Profile. Web servers on 10.10.10.10 open TCP 443 to app servers on 10.10.20.10, and every connection times out. The endpoints are learned, the BDs are deployed on the same leaves, and no faults are open. A separate ping test between the same two hosts also fails. In a lab with both EPGs in the same application profile and the same contract, the connection succeeds. The security team later asks for a second consumer, EPG-Reporting, which sits in VRF-Shared in the same tenant, to reach the same provider on TCP 443.
1. Why do the connections time out even though the contract is applied to both EPGs and the filter is correct?
Read the worked answer
Contract scope sets the boundary inside which the contract is instantiated. Application Profile means the provider and consumer must be in the same application profile. Here EPG-App is in AP-Back and EPG-Web is in AP-Front, so the contract is never programmed on the leaves even though it appears under both EPGs in APIC. The VRF drops the traffic because the default action between EPGs in a VRF is deny. The lab result confirms it: the identical contract works when both EPGs share an application profile. Because both EPGs are in VRF-Prod, the correct scope is VRF (context); Tenant or Global would also work but grant a wider boundary than needed. Change the scope, then re-check that the contract shows as applied and that the filter is deployed.
2. What must change for EPG-Reporting in VRF-Shared to consume the same contract? Explain the reasoning.
Read the worked answer
With the scope at VRF, the contract only covers EPGs inside VRF-Prod. EPG-Reporting is in VRF-Shared, so you must raise the scope to Tenant (same tenant) or Global (across tenants). Tenant scope lets the fabric leak the provider EPG's prefixes into the consumer VRF for contract traffic, so verify that EPG-Reporting's BD has a subnet and that the EPG actually consumes the contract. If the provider must remain reachable only on TCP 443, keep the same filter; do not widen it to all IP just to make it work. Also confirm that no other contract or VRF policy is enforcing a stricter rule between the two VRFs. If the two EPGs were in different tenants, only Global would work, and both tenants would need the contract exported and imported appropriately.
3. After the scope is corrected and the TCP 443 connection is permitted, the return traffic from the app server to the web server is still dropped. What filter behavior explains this, and how do you fix it?
Read the worked answer
ACI filters are stateless, so the reverse direction must be permitted explicitly. Apply Both Directions creates the reverse entry, but without Reverse Filter Ports that reverse entry still matches destination port 443. The server's reply has source port 443 and a destination port in the client's ephemeral range, so it does not match and is dropped by the implicit deny. Enabling Reverse Filter Ports makes the reverse entry swap the ports (source 443, any destination), which matches the reply. Alternatively, add a separate filter entry with source port 443 and no destination port. Test with the actual application flow, not just a ping, because ICMP has no ports and will behave differently from TCP.