Symptom
Traffic is dropped at the ingress Leaf due to a missing Contract rule (SECURITY_GROUP_DENY).
Conditions
- transit routing within the same L3Out
- same External EPG
- 0.0.0.0/0 with "External Subnet for External EPG" is used to match both Source and Destination
- vzAny contract is used:
- - either with vzAny itself being both Consumer and Provider
- - or with vzAny being either Consumer or Provider and External EPG being either Provider or Consumer respectively
Workaround
- Either replace 0.0.0.0/0 with a combination of 0.0.0.0/1 and 128.0.0.0/1 for External EPG classification
- Or create a dummy Application EPG (fvAEPg) in the same VRF as the L3Out (this dummy EPG doesn't have to be deployed anywhere)
Further Problem Description
When 0.0.0.0/0 is used for External EPG classification of both Source and Destination (in L3Out(s)), the pcTags assigned are:
- Source: VRF pcTag
- Destination: 15 (reserved for 0.0.0.0/0)
When the dummy EPG is deployed, there's a corresponding zoning-rule(s) programmed at the ingress Leaf, which the above pair of pcTags matches:
- - either for 0-to-0 (coming from the Contract that's both consumed and provided by the vzAny)
- - or for 0-to-15 (vzAny-to-0/0_ExtEPG) and VRF_pcTag-to-0 (0/0_ExtEPG-to-vzAny) coming from the Contract with vzAny being Consumer or Provider and External EPG being Provider or Consumer respectively
When there's no dummy EPG present, there's no such zoning-rule(s) programmed at the ingress Leaf and so it drops the packet.
This is because for PE to download the Contract to the leaf there has to be at least one other (Ext)EPG participating in it.
When the more specific prefixes (like 0.0.0.0/1 and 128.0.0.0/1) are used for classification, both Source and Destination pcTags will be of the External EPG they're configured in, and so the pcTag pair matches the hidden rule in ACLQOS that allows all intra-EPG traffic.
The behavior is by design. The bug is filed to fix the public-facing documentation.
