07-04-2023 11:07 AM
suppose:
source ip = 10.212.105.2/24
destination ip = 192.168.1.2/24
someone already set up vzAny contract between the source and destination subnets.
I used below method to verify the contract :
1 check epg name
APIC# show endpoints ip 10.212.105.2
2 check pc tag
APIC# show epg TEST-epg detail
Policy Tag : 11114
3 show whehter there are contracts
APIC# moquery -c actrlRule -f 'actrl.Rule.sPcTag=="11114" and actrl.Rule.dPcTag=="55"'
No Mos found
The result is "No Mos found".
So can I say the vzAny contract was not set up correctly ?
08-13-2023 11:32 AM
Hi,
If contract is being Consumed AND Provided by VzAny, both the Source and Destination PcTag would be 0.
Please use inbuilt script contract_parser.py invoked from CLI to validate.
-----------------------------------------
If you find my reply solved your question or issue, kindly click the 'Accept as Solution' button and vote it as helpful.
You can also learn more about Cisco ACI through our live Ask the Experts (ATXs) session. Check out the ATXs Resources [https://community.cisco.com/t5/data-center-and-cloud-knowledge/cisco-aci-ask-the-experts-resources/ta-p/4394491] to view the latest schedule for upcoming sessions, as well as the useful references, e.g. online guides, FAQs.
-----------------------------------------
08-13-2023 04:06 PM
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.
<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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide