All EPGs in Application profile

[Nuno Marques]

Hi guys,

When using for instance a L3Out consumed by EPGs from multiple App Profiles, all the EPGs (and contracts) are visible on every App Profile..

i becomes a little confusing when you have 600 EPGs right?

Any practical way avoid that and to show only the application profile specific EPGs in the GUI?

thanks.

[micgarc2]

Hi Nuno,

If the contracts are reused they will still show under every App profile. If you click on the top level folder of the App profile it will show you a topology and you can see what contracts are associated with the objects related to that specific App profile (EPGs, L3 outs, etc).

You also might want to consider how you construct your contracts. If you have multiple EPGs tied to the same BD (in turn the same VRF) you can utilize something called a vzAny contract.  vzAny contracts eases management by allowing for a single point of contract configuration for all EPGs within a context, and also optimizes hardware resource consumption by applying the contract to this one group rather than each EPG individually.

In other words, if you have 500 EPGs that are all part of the same VRF, you can apply the contract(s) to this one vzAny group under the VRF/private network, rather than to each EPG. This might give you a little more visibility and better utilize your TCAM availability.  

Hope this helps!

Regards,

Michael G.

Thank you for participating in the Cisco Support Forum for ACI! If you have other questions related to this post, please let us know. If this response answers your questions, please mark this post "answered" and assign a rating to the response(s) provided. This will help notify other viewers that your question(s) is answered and this helps us provide better responses for this and future questions.

[Mario Rosi]

Hi,

i'm getting in this 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 Internal 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 in in the middle of?

I'd really appreciate if you clarify to me this concept.

Thanks,

Mario

[akabdalla]

can I create a shared application profile between different VRFs but within the same tenant ?

[peterzhang]

No, EPGs can be assigned to only one bridge domain, which can only associate with one VRF. You can share VRF and BDs though.

[akabdalla]

The contract relationship mentioned in the diagrams shows you can have two different EPGs in the same BD.

The question will be is the application  profile is only a 1-to -1 relationship to EPGs or could be 1-to-many

if So could it be possible to use  same application profile shared between VRF of the same Tenant ?

[peterzhang]

You can have multiple EPGs in the same application profiles. But an EPG can be a child of only one application profile at any given time. It's the same that EPG can be associated with one BD at any given time.

But you are specifically talking about application profiles, which represents a group of EPGs. You can't share EPGs between VRFs, because you can't share bridge domains between VRFs.

[peterzhang]

There are 3 ways of completely whitelist the fabric

1. vzAny, which is essentially a representation of ALL EPGs within a given VRF. You can apply both provider and consumer contracts to vzAny. This will simply allow all communication between all EPGs within the same VRF, but not to other VRFs, which requires leaking. You can always choose to apply only a consumer contract or only provider EPGs

This option is under Networking -> VRF -> EPG collection for VRF. ( This is recommended when going with application-centric, where you can do some cool tricks to help reduce TCAM resource, such as "established" flag, icmp, common infrastructure services..etc.. )

2. Under the same option from above, there is a Preferred Group Member ( 2.2(1n) ), it's "disabled" by default. If you enable that option, you can then go to each EPG and select "Include", which will then allow that EPG to communicate with any other EPGs that's also "included", within the same VRF. You can apply this to any L2/L3 EPG as well. However, there is one important caveat: if you apply this option in L3out EPG, you can't use 0.0.0.0/0, rather you'll be using 0.0.0.0/1 and 128.0.0.0/1. This is a good approach in net-centric mode.

3. Unenforced under VRF. This option has always been around since 1.0, it's a "one-click" whitelist all button. Extremely disruptive. Not usually recommended.