cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2632
Views
7
Helpful
2
Replies

BD - EPG communicate with other EPGs

jmaurer101
Level 1
Level 1

I'm new to ACI so please forgive me.

 

I have multiple BD EPGs that are connected and have subnets. Inside the subnets I can ping everyone. But I would like to have EPG 1 reach EPG 2. They are in the same VRF. 

 

Typical routing is placing static routes inside the VRF and communication works. I am assuming that because they are inside the VRF that the routes are statically placed. Is that correct or is there more to the story? Is there a check box I need to check? Do I need to setup contracts? If so could I get an example?

1 Accepted Solution

Accepted Solutions

RedNectar
VIP
VIP

Hi @jmaurer101 ,

Welcome to the wonderful world of ACI - possibly a little like AIW (Alice in Wonderland) for newcomers.

By and large, you don't need to worry about routing at all in ACI so long as your BDs are in the same VRF. Forget trying to troubleshoot via routing commands - it just works in ACI

But to allow two EPGs to be able to communicate, you must do one of four things:

  1. Unenforced Policy Control
    Configure the VRF with the Policy Control Enforcement Preference set to Unenforced.
    This will allow ALL EPGs to communicate freely without ANY restriction.
    This approach is absolutely NOT RECOMMENDED but sadly implemented by many users - either from poor advice or poor design.
  2. Use vzAny with the default contract
    Have the EPG Collection for VRF (which is called vzAny) both Provide and Consume the default contract (which is configured in the common tenant)
    The result is EXACTLY the same as #1 above, and is in fact just a more convoluted way of achieving the same end, and so this this approach is even recommended less that #1, and again sadly you will often hear users say "I use vzAny" to allow my EPGs to communicate.  When I hear this comment I almost cry, because all they have done is #1 but gone to a lot more trouble.
    DO NOT USE THIS METHOD.
  3. Preferred Groups.
    This is a two-step process:
    1. Configure VRF to enable the Preferred Group option
    2. Configure each EPG that you wish to allow to communicate freely as a Preferred Group Member

    The result is that any EPG in the Preferred Group can communicate freely with any other Preferred Group member - even if you add EVERY EPG to the Preferred Group, this method is preferable to both #1 and #2 above because you can then later selectively remove EPGs from the Preferred Group and configure contracts for them to communicate with other EPGs
    This method is a good starting point if you are desperate to get going quickly
  4. Use Contracts
    The BEST method to allow EPGs to communicate is to make sure your EPGs are arranged with similar endpoints providing the same services in the same EPGs, then configure contracts for all the different services that are to be provided by each EPG, have that EPG Provide that contract, and any EPG that need that service Consumes that contract. If ALL EPGs need to consume the contract (such as maybe a DNS contract) then have the vzAny construct consume the contract rather than EVERY EPG.

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.

View solution in original post

2 Replies 2

RedNectar
VIP
VIP

Hi @jmaurer101 ,

Welcome to the wonderful world of ACI - possibly a little like AIW (Alice in Wonderland) for newcomers.

By and large, you don't need to worry about routing at all in ACI so long as your BDs are in the same VRF. Forget trying to troubleshoot via routing commands - it just works in ACI

But to allow two EPGs to be able to communicate, you must do one of four things:

  1. Unenforced Policy Control
    Configure the VRF with the Policy Control Enforcement Preference set to Unenforced.
    This will allow ALL EPGs to communicate freely without ANY restriction.
    This approach is absolutely NOT RECOMMENDED but sadly implemented by many users - either from poor advice or poor design.
  2. Use vzAny with the default contract
    Have the EPG Collection for VRF (which is called vzAny) both Provide and Consume the default contract (which is configured in the common tenant)
    The result is EXACTLY the same as #1 above, and is in fact just a more convoluted way of achieving the same end, and so this this approach is even recommended less that #1, and again sadly you will often hear users say "I use vzAny" to allow my EPGs to communicate.  When I hear this comment I almost cry, because all they have done is #1 but gone to a lot more trouble.
    DO NOT USE THIS METHOD.
  3. Preferred Groups.
    This is a two-step process:
    1. Configure VRF to enable the Preferred Group option
    2. Configure each EPG that you wish to allow to communicate freely as a Preferred Group Member

    The result is that any EPG in the Preferred Group can communicate freely with any other Preferred Group member - even if you add EVERY EPG to the Preferred Group, this method is preferable to both #1 and #2 above because you can then later selectively remove EPGs from the Preferred Group and configure contracts for them to communicate with other EPGs
    This method is a good starting point if you are desperate to get going quickly
  4. Use Contracts
    The BEST method to allow EPGs to communicate is to make sure your EPGs are arranged with similar endpoints providing the same services in the same EPGs, then configure contracts for all the different services that are to be provided by each EPG, have that EPG Provide that contract, and any EPG that need that service Consumes that contract. If ALL EPGs need to consume the contract (such as maybe a DNS contract) then have the vzAny construct consume the contract rather than EVERY EPG.

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.

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