Re: vzAny and contract definition

Mario Rosi · ‎10-13-2017

Hi,

i'm getting in vzAny topic because i've to model the ACI guy for a bronwfield to ACI migration but i've not clear the concept of vzAny.

Reading around i see that each one is describing the vzAny as an object that allow to save the number of contracts, because applied only once to ALL the EPGs inside the same VRF (L3Out and L2Out external EPGs as well that belong to the same VRF).

Now, in order to let it working, a CONTRACT need two actors, i mean, tow EPGs (in any form, internal vs internal EPGs, internal vs external EPGs...).

When we start to talk about vzAny, you say that the ONLY one contract is applied to all the EPGs internal the same VRF; OK, but who is the second actor, the second EPG that contract refer to?

I mean, if vzAny is applied to all the EPGs inside the same VRF, who is the second EPG the contract is in the middle of?

I'd really appreciate iany clarification about this concept.

Thanks,

Mario

nvermand · ‎10-13-2017

Hi Mario,

You have to see vzAny as a shorcut to "all EPGs in the VRF". This means that when you define a contract, vzAny, as the "EPG" object, can be either consumer of provider of the contract. The other side (consumer or provider) will be a normal EPG (access EPG or external EPG). This will reduce the number of entries in the TCAM since one side of the contract relation will be reduced to a single class ID (vzAny).
The following example shows the TCAM entry for an EPG consuming the default contract, provided by vzAny:

leaf-01# show zoning-rule scope 2588672

Rule ID SrcEPG DstEPG FilterID operSt Scope Action Priority
======= ====== ====== ======== ====== ===== ====== ========

....
4133 16387 0 default enabled 2588672 permit src_any_any(15)

The source class ID is the pcTag of the consumer EPG (16387) and the destination is a reserved pcTag (15), representing all the vzAny zone, or in other words, all EPGs in that VRF scope.
Hope it helps

Nicolas

Mario Rosi · ‎10-16-2017

Hi Nicolas,

thanks for your reply; just a calrification at your sentence:

"You have to see vzAny as a shorcut to "all EPGs in the VRF". This means that when you define a contract, vzAny, as the "EPG" object, can be either consumer of provider of the contract. The other side (consumer or provider) will be a normal EPG (access EPG or external EPG)."

Beeing the rule "vzAny = all EPGs in the VRF, when i had to use it, from my understanding, the other side would be a EPG (access EPG or external EPG) of another VRF... otherwise how could be that and EPG, part of the same VRF, be at the same time included in the vzAny object and also the second actor (as consumer or provider)?

nvermand · ‎10-16-2017

Why would that be an issue? vzAny doesn't rewrite pcTag of EPGs, it's just another object. Also, if EPG consumes and provides the contract at the same time, this doesn't have any impact, since there's no policy enforcement within an EPG (src=dst=EPG, assuming you're not using intra-EPG contract)

Nicolas

randreetta · ‎08-06-2019

@nvermand wrote:
Hi Mario,

You have to see vzAny as a shorcut to "all EPGs in the VRF". This means that when you define a contract, vzAny, as the "EPG" object, can be either consumer of provider of the contract. The other side (consumer or provider) will be a normal EPG (access EPG or external EPG). This will reduce the number of entries in the TCAM since one side of the contract relation will be reduced to a single class ID (vzAny).
The following example shows the TCAM entry for an EPG consuming the default contract, provided by vzAny:

leaf-01# show zoning-rule scope 2588672
Rule ID SrcEPG DstEPG FilterID operSt Scope Action Priority
======= ====== ====== ======== ====== ===== ====== ========
....
4133 16387 0 default enabled 2588672 permit src_any_any(15)

The source class ID is the pcTag of the consumer EPG (16387) and the destination is a reserved pcTag (15), representing all the vzAny zone, or in other words, all EPGs in that VRF scope.
Hope it helps

Nicolas

'15' seems to be related to the priority (a kind of order to be followed applying the rules)

The destination EPG class ID seems to be '0' (ZERO). It looks like pcTag values 0-15 are reserved, I see them appearing quite often for default or implicit rules, but it's not clear if vzAny uses pcTag 15. The last column doesn't seem to be related to pcTag value.

melgebal · ‎02-10-2020

Hi All,

The source class ID is the pcTag of the consumer EPG (16387) and the destination is a reserved pcTag (0) not 15, 15 is the priority, pcTag of 0 is used for vzAny to represent any EPG in a specific VRF (scope)

melgebal · ‎10-18-2017

Hi Mario,

Let me help explaining how vzAny contract works and providing a practical example on how it works:

"A single endpoint group named "Shared" is providing a contract, with multiple endpoint groups
consuming that contract" - Cisco ACI Best Practices

I have one outside EPG that talks to the outside world and all EPGs should be allowed to talk to it because it is already protected with a firewall, so instead of creating a pair of contracts for each EPG, I have used the vzAny here with the predefined default contract as a consumer and the Outside EPG as a provider so now I have allowed all the EPGs that attached to this VRF to sourced traffic to outside but what about the other direction, unfortunately you must go to each EPG and create a separate contract in the opposite direction [(Outside EPG - Consumer > EPG - Provider)

So instead if you have 5 EPGs plus the outside, vzAny would help in creating 6 contracts instead of 10.

I hope that helps.