Hi @goodmarty ,
You speak of the most misunderstood, misused and abused concept in ACI. The EPG Collection for a VRF called vzAny
People (not just you) often talk of a "vzAny Contract" - this is no such thing in ACI.
- vzAny is able to CONSUME a contract on behalf of every EPG that links back to that VRF via it's Bridge Domain
- vzAny is able to PROVIDE a contract on behalf of every EPG that links back to that VRF via it's Bridge Domain - but this is a pretty stupid idea UNLESS
- vzAny is both Providing and Consuming the same contract, which effectively allows free communication between all EPGs for that particular contract.
- There is a popular myth that when vzAny is in use, it uses the default Contract from the common tenant, which (by default) allows all traffic. This may be true in many cases, but it not necessarily true
<RedNectar's personal gripe>
I personally think using vzAny to both provide and consume the default contract from the common tenant is a complete waste of time and whomever thought of recommending that anyone actually do this should take much of the blame for the massive amount of misunderstanding there is about the use of vzAny.
IF full communication between all EPGs that link back to a VRF is required, it is FAR SIMPLER and way less confusing to simply change the Policy Control Enforcement Preference for the VRF to Unenforced
But better still, the same result can be achieved by enabling Preferred Groups for that VRF and every EPG that links back to that VRF. Using this approach allows you to easily remove some EPGs from the Preferred Group in the future if finer granularity is required.
Note: There are many use cases for using vzAny to both provide and consume a contract - such as redirecting all traffic through a service graph - but that does NOT use the default contract from the common tenant.
</gripe>
But back to your question. I'm going to assume that since you referred to "vzAny contract" you mean that the contract is both provided and consumed by vzAny
So if you are trying to troubleshoot contracts with vzAny, you'll need to be looking at pcTag=0, NOT 11114 or 55
Issue the following command, replacing 2201 with any switch where your VRF exists. Or you can use the entire range of leaf switches you have to be sure:
apic1# fabric 2201 show zoning-rule src-epg 0 dst-epg 0
----------------------------------------------------------------
Node 2201 (Leaf2201)
----------------------------------------------------------------
+---------+--------+--------+----------+---------+---------+----------+-----------------------+----------+----------------------------+
| Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority |
+---------+--------+--------+----------+---------+---------+----------+-----------------------+----------+----------------------------+
...<snip>...
| 4159 | 0 | 0 | 18 | uni-dir | enabled | 2523137 | common:AppServices_Ct | permit | any_any_filter(17) |
| 4372 | 0 | 0 | 17 | uni-dir | enabled | 2523137 | common:AppServices_Ct | permit | any_any_filter(17) |
+---------+--------+--------+----------+---------+---------+----------+-----------------------+----------+----------------------------+
In my example above, I see that the contract AppServices_Ct in the common tenant is provided and consumed by vzAny
If you DON'T see something like that, THEN you can say
"the vzAny contract was not set up to both provide and consume a contract" - as to whether this means it was or wasn't "set up "correctly" depends on what you actually mean by "someone already set up vzAny contract between the source and destination subnets" - as I said, MY assumption is that you mean it was set up to provide and consume a contract.
I hope this helps.
Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.
RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.
