External EPG Longest-Prefix Classification
Tenant-Prod VRF-Prod contains BD-App 10.20.0.0/24 and EPG-App. L3Out L3Out-WAN runs eBGP with ACI AS 65001 and external AS 65002 over a vPC on border leaves 101 and 102, SVI VLAN 100, ACI peer addresses 10.0.0.1 and 10.0.0.5, external peers 10.0.0.2 and 10.0.0.6. The external router advertises 172.16.0.0/16 and the more specific 172.16.1.0/24. Two external EPGs are configured: Ext-WAN with subnet 172.16.0.0/16 and Ext-Partner with subnet 172.16.1.0/24, both flagged External Subnets for the External EPG. Contract App-to-WAN is provided by Ext-WAN and consumed by EPG-App; its filter permits all IP. BGP is Established on both leaves, and the VRF routing table shows 172.16.0.0/16 and 172.16.1.0/24 through the L3Out. Pings from 10.20.0.10 to 172.16.2.10 succeed; pings to 172.16.1.10 fail. No faults are open on the L3Out, and the external router has no ACLs.
1. Why does 172.16.1.10 fail while 172.16.2.10 succeeds, even though both prefixes are in the routing table?
Read the worked answer
Both prefixes are in the routing table, so this is not a routing failure. ACI classifies the destination into an external EPG by matching it against the external EPG subnets with longest-prefix match. 172.16.2.10 matches only 172.16.0.0/16, so it lands in Ext-WAN, which has contract App-to-WAN with EPG-App, and the packet is permitted. 172.16.1.10 matches both 172.16.0.0/16 and 172.16.1.0/24, and the /24 wins, so it is classified into Ext-Partner. Ext-Partner has no contract with EPG-App, so the packet hits the implicit deny. The fact that the /16 prefix is advertised and installed does not help: classification is not route lookup, and the contract is applied after classification.
2. What are your options to permit the traffic, and which one do you recommend? Explain the trade-offs.
Read the worked answer
The direct fix is to add a contract between EPG-App and Ext-Partner, ideally with a filter limited to the ports the partner actually uses. This preserves the separation between the WAN and partner prefixes and keeps the permission narrow. Adding 172.16.1.0/24 to Ext-WAN would compete with Ext-Partner's /24 for the same prefix and defeat the intent of a separate partner EPG; it also would not fix classification if Ext-Partner remains configured. Do not try to rely on the /16 contract: the more specific external EPG wins even though the /16 also matches. After the change, verify with show contracts and a test from the actual host, and confirm the return path is also permitted.
3. If only a subset of EPG-App hosts should reach the partner, how would you implement that?
Read the worked answer
Contracts apply to an EPG, not to individual hosts, so if only some EPG-App hosts should reach the partner, split the source. Options are a uSeg EPG based on IP, VM name or another attribute for those hosts, or a separate BD and EPG for the restricted subnet, then consume the partner contract only from that EPG. Note that a contract filter can match L3 protocol, ports and ICMP type, but not destination IP addresses, so you cannot restrict 172.16.1.0/24 inside a filter; the segmentation has to happen on the source side. Keep the contract scope at VRF because both objects are in VRF-Prod, and verify the EPG classification on the leaf after the change.