cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4038
Views
5
Helpful
3
Replies

Best way to transition a VRF from unenforced mode to enforced and still maintain IP any any connectivity?

jgesualdi
Level 1
Level 1

On my ACI network my VRF's are set to unenforced mode. I want to transition the network from unenforced to unforced mode but everything still needs to be basically IP any any. The network is not production yet but I don't want to impact the testing that's currently being done on it.

 

 The 2 options I want to use is either vzAny or prefered group membership. My first question is how would I do this with VzAny? What do I need to change and where do I apply it without breaking things?  This includes all epg's including the external epg. 

 

Prefered group seems to be a bit more straight forward to configure. My question here is which is a better way to go? Prefered group or VZany? If I do decide to use prefered group can I have a contract between my prefered group epg 's and non prefered group epg's?

 

Thx 

 

 

1 Accepted Solution

Accepted Solutions

Marcel Zehnder
Spotlight
Spotlight

Hi

 

I would recommend to go for preferred group. vzAny is okay if you do a permit-any kind of design (aka network centric design) - but as soon as you want to apply some more granular polices in the same VRF you might put yourself in a dead end situation.

 

If you work with a preferred group it's pretty easy: All EPGs inside the preferred group are able to communicate without a contract. EPGs outside of the preferred group must have contracts in place. Also if communication between a EPG outside of the preferred group and a EPG inside the group is needed, a contract must be in place.

 

Just remeber: the preferred group is not an object, it's just a way how to configure permit statements - so you can't configure a contract between an non preferred group epg (let's assume the name of this EPG is "EPG-X") and the preferred group itself. Instead you must apply a contract between EPG-X and each and every EPG inside the preffered group to which EPG-X must be able to communicate.

 

Also have a look at the restrictions (for instance if you do transit routing):

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_APIC_Contract_Preferred_Group.html

 

HTH

 

 

View solution in original post

3 Replies 3

Marcel Zehnder
Spotlight
Spotlight

Hi

 

I would recommend to go for preferred group. vzAny is okay if you do a permit-any kind of design (aka network centric design) - but as soon as you want to apply some more granular polices in the same VRF you might put yourself in a dead end situation.

 

If you work with a preferred group it's pretty easy: All EPGs inside the preferred group are able to communicate without a contract. EPGs outside of the preferred group must have contracts in place. Also if communication between a EPG outside of the preferred group and a EPG inside the group is needed, a contract must be in place.

 

Just remeber: the preferred group is not an object, it's just a way how to configure permit statements - so you can't configure a contract between an non preferred group epg (let's assume the name of this EPG is "EPG-X") and the preferred group itself. Instead you must apply a contract between EPG-X and each and every EPG inside the preffered group to which EPG-X must be able to communicate.

 

Also have a look at the restrictions (for instance if you do transit routing):

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_APIC_Contract_Preferred_Group.html

 

HTH

 

 

Hi Marcel,

 

conerning the use of "Preferred group" instead of vzAny, what about if i'd go for the use of both them?

 

I mean, let's suppose to have a scenario of migration from Brownfield to ACI where in each Tenant i would have just one VRF (in the scheme in attachement named VRF Prod) where all the internal EPGs/BDs/VLANs are allowed to talk each other (in the legacy environment they do inter-vlan routing).

 

Now i want to let them to talk to external world via different L3Out external EPGs for different reasons.

 

What about to introduce the "Preferred Group" to let them to talk each other (saving contracts) and at the same time to have "vzAny" in place as well internally the same VRF, introducing so two new VRFs VRF EXT_Prod and VRF FWINTRA_PROD in order to have:

 

- 5 contracts between vzAny and L3Out external EPGs (as shown in the draw)

- 4 contracts between L3Out FWINTRA_Prod and the remaining 4 L3Out external EPGs

 
I would have still to configure associations between internal EPGs/BDs and the L3Out external EPGs (am i right?) but i would save a lot of contracts.
 
Yes, i would have the tie that any new one internal EPG will have to follow the same rules (i could think to introduce a seprate VRF to support new EPGs that have to follow different rules) but in the end i would save a lot of hw resources (i'm talking about 400 VLANs an so contracts in place would be quite a lot).
 
What do you think?
 
Thanks

 

 

Hi Marcel,

 

conerning the use of "Preferred group" instead of vzAny, what about if i'd go for the use of both them?

 

I mean, let's suppose to have a scenario of migration from Brownfield to ACI where in each Tenant i would have just one VRF (in the scheme in attachement named VRF Prod) where all the internal EPGs/BDs/VLANs are allowed to talk each other (in the legacy environment they do inter-vlan routing).

 

Now i want to let them to talk to external world via different L3Out external EPGs for different reasons.

 

What about to introduce the "Preferred Group" to let them to talk each other (saving contracts) and at the same time to have "vzAny" in place as well internally the same VRF, introducing so two new VRFs VRF EXT_Prod and VRF FWINTRA_PROD in order to have:

 

- 5 contracts between vzAny and L3Out external EPGs (as shown in the draw)

- 4 contracts between L3Out FWINTRA_Prod and the remaining 4 L3Out external EPGs

 
I would have still to configure associations between internal EPGs/BDs and the L3Out external EPGs (am i right?) but i would save a lot of contracts.
 
Yes, i would have the tie that any new one internal EPG will have to follow the same rules (i could think to introduce a seprate VRF to support new EPGs that have to follow different rules) but in the end i would save a lot of hw resources (i'm talking about 400 VLANs an so contracts in place would be quite a lot).
 
What do you think?
 
Thanks

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Save 25% on Day-2 Operations Add-On License