cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
2299
Views
15
Helpful
6
Replies
netbeginner
Explorer

ACI Contract Inter EPG

Hi All,

 

This is related to cisco ACI contract. 

 

ACI Version 4.1

 

We have a VRF (Eg : VRF-A) with multiple EPGs.

 

There is a contract applied on VRF-A with ANY-ANY rule, which obviously reflect for EPGs as well.

 

We want to apply a Contract restriction (allow specific port only) between 02 EPGs in VRF-A   (Eg :  EPG-1 and EPG-2)

 

We have applied a standard contract / rule set (Bi-Directional) with PROVIDED and CONSUMED on both EPG-1 and EPG-2 , still All things are working as like before (i.e. no restriction been applied and effective).

 

We also checked by applying Taboos contract (Created with specific port allow), but this time result is something different .....Everything stopped working between EPG-1 and EPG-2.

 

Pls note that Taboos contract by-default applied with PROVIDED only. it's not available with CONSUMED

 

Read somewhere that taboos contract will take priority always and taboos contract will be applied where there is ANY-ANY contarct applied on respective VRF (just like our case). 

 

please guide what we are missing and why our contract for allowing specific port is not taking effect.  

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
RedNectar
Engager

Hi @netbeginner ,

I went to reply to this question when I saw that you have two excellent answers already, so I hesitated. Then decided I'd throw in some personal ideas for ACI best practice. I'll call them...

RedNectar's Rules for ACI contracts

  1. Never apply a contract that is both consumed and provided in each direction.  Doing so just shows that the implementer can't figure out which EPG contains the servers and which contains the clients.
    • Exception: When using first generation switches, there was a legitimate use for using a contract that allowed TCP Established traffic to be consumed and provided by vzAny to conserve TCAM, but it was a kludge to overcome a design weakness of too little TCAM to do the job properly.
    • OK. There may be other exceptions too, such as if one EPG's servers need to SSH to another EPG's servers, and vice-versa. But even then, I might be tempted to create two identical contracts (EPG.A.SSH.Service_Ct and EPG.B.SSH.Service_Ct) to save confusion.
  2. Never have vzAny provide and consume the default contract or any other contract that allows all traffic. I realise this rule is redundant given Rule#1 above, but I really want to emphasise that this is a VERY BAD IDEA and I am ASTOUNDED at the number of sites that have implemented such a contract, and even more astounded that some so-called experts have suggested using such a design. Doing so just shows that the implementer has no idea that the same result can be much more easily achieved by setting the VRF Policy Control Enforcement Direction to UNENFORCED and is setting the environment up to run into the exact problem you have in the future.
    • If the design calls for all traffic to be permitted between all EPGs in a VRF, achieve this using Preferred Groups as my esteemed colleagues have pointed out.
  3. Never use Taboo Contracts. And avoid using deny statements in all contracts, life will be simpler if you go to the trouble of sorting out what services each EPG needs to provide, and which services each EPG needs to consume, and creating appropriate contracts for each service.

So now comes the tricky question of how to apply these rules to your situation.  These are the steps I'd recommend, assuming the EPGs you wish to isolate are EPG.A and EPG.B:

Part 1: Preferred Groups

  1. Enable Preferred Groups in the VRF: Tenants > YourTenant > Networking > VRFs > YourVRF >| [Policy] tab
  2. Make each EPG except EPG.A and EPG.B members of the preferred group: Tenants > YourTenant > Application Profiles > YourAppProf > Application EPGs > Each_EPG_in_turn >| [Policy] >| [General]

Part 2: Filters and Contracts:
This is the tricky bit, and has several sub-stages:

Individual EPGs stage

  1. Identify what services need to be PROVIDED by EPG.A. In other words, examine all the listening TCP/UDP ports in all the endpoints in EPG.A
  2. Create a filter based on each service, typically named after the service, such as SQL.Service_Fltr and add the appropriate TCP (or UDP) port(s) for that service as the destination port.
    • Tip: Create all filters in the common tenant
    • If you have services that negotiate TCP/UDP ports dynamically, such as FTP, then you are screwed - ACI is NOT able to to handle traffic at the Application layer. (I've always wondered why ACI is actually called Application Centric Infrastructure). If this is the case forget all the above and work out how to use a firewall.
  3. Create a Contract to accumulate all the different services for EPG.A that are to be made available to EPG.B. Perhaps call this EPG.A.to.EPG.B.Services_Ct.
  4. Have EPG.A provide this contract
  5. Have EPG.B consume this contract
  6. Repeat steps 1-5 above swapping EPG.B with EPG.A (if only ONE EPG is actually providing any services, this step may not be necessary)

EPG.A and EPG.B services stage. In this case, I'm assuming that the remaining EPGs that are communicating happily with each other using Preferred Groups as described in Part 1 will be allowed to consume all services from both EPG.A and EPG.B, and both EPG.A and EPG.B will be allowed to consume all services from all other EPGs

  1. Create a Contract to accumulate all the different services for EPG.A that are to be made available to all the other EPGs.  Recall you created filters for ALL services for EPG.A in step 2 above. Perhaps call this EPG.A.All.Services_Ct.
  2. Have EPG.A provide this contract
  3. Have each other EPG consume this contract
  4. Repeat steps i-iii above swapping EPG.B with EPG.A 

Other EPG Services stage. In this case, I'm assuming that both EPG.A and EPG.B will be allowed to consume all services from all other EPGs.

  1. Create a filter that allows all traffic - there is one in the common tenant called default, but I prefer to spell it out and create an All.IP.Traffic_Fltr and restrict it to all IP traffic rather than the default ALL traffic.
  2. Have every EPG EXCEPT EPG.A and EPG.B provide this contract
  3. Have EPG.A and EPG.B consume this 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


 

 

RedNectar
aka Chris Welsh


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

View solution in original post

6 REPLIES 6
Sergiu.Daniluk
VIP Advocate

Hi @netbeginner 

The vzAny-to-vzAny contract is the one allowing the traffic. Basically, the traffic is matched against the zoning rules, in the following order:

 

  1. contracts between specific EPGs
  2. contracts defined for vzAny-to-vzAny
  3. Preferred group
  4. vzAny configured to provide and consume a contract with a filter such as common/default
  5. The implicit deny

 

In other words, if your flow will not match on the EPG-to-EPG contract, but it will match on the vzAny-to-vzAny contract, thus will be allowed.Note: the flow does not match because of the specific ports configured in the EPG-to-EPG contract. Zoning rules table, works basically like an ACL.  The reason why it works like this is for example to have vzAny with a contract to redirect all traffic to an external firewall and then to use specific EPG-to-EPG contracts for specific traffic for direct communication, without being redirected to firewall.

 

What I believe you can do is to add another filter into the existing EPG-to-EPG contract, filtering on IP (so basically any traffic) with action "deny" and priority "medium" or "lowest".

 

Stay safe,

Sergiu

Robert Burns
Cisco Employee

Rather than using vzAny with a permit-any rule, you might be better served using Preferred Groups and/or standard Contracts if you need more granular policy.  You could keep all EPGs other than these two in a Preferred Group, then apply your standard contract between EPG-1 and EPG-2.  Your problem is that you're never going to hit the implicit Deny with a vzAny contract allowing any:any.  Deny rules (standard contracts) do take precedence over vzAny, but its a deny:specific type of rule.  You want an "only-allow" type of rule which you can only achieve with a discrete contract and implicit deny catching everything else. 

  • vzAny - Defines communication between all EPGs within a VRF (in your case any any:any rule)
  • Preferred Groups - Allows unrestricted communication between select EPGs within a VRF
  • Contract - Allows specific communication between EPGs
  • Taboo - Denys specific communication coming into an EPG.

Security policies within ACI follow this precedence:

  1. Inter-EPG Contract
  2. Inter-EPG Isolation
  3. Taboo Contract
  4. EPG-to-EPG (specific filters)
  5. EPG-to-EPG (default filters)
  6. EPG-to-vzAny
  7. vzAny-to-vzAny (specific filters)
  8. vzAny-to-vzAny (default filters)
  9. any-to-any Implicit Deny

Robert

RedNectar
Engager

Hi @netbeginner ,

I went to reply to this question when I saw that you have two excellent answers already, so I hesitated. Then decided I'd throw in some personal ideas for ACI best practice. I'll call them...

RedNectar's Rules for ACI contracts

  1. Never apply a contract that is both consumed and provided in each direction.  Doing so just shows that the implementer can't figure out which EPG contains the servers and which contains the clients.
    • Exception: When using first generation switches, there was a legitimate use for using a contract that allowed TCP Established traffic to be consumed and provided by vzAny to conserve TCAM, but it was a kludge to overcome a design weakness of too little TCAM to do the job properly.
    • OK. There may be other exceptions too, such as if one EPG's servers need to SSH to another EPG's servers, and vice-versa. But even then, I might be tempted to create two identical contracts (EPG.A.SSH.Service_Ct and EPG.B.SSH.Service_Ct) to save confusion.
  2. Never have vzAny provide and consume the default contract or any other contract that allows all traffic. I realise this rule is redundant given Rule#1 above, but I really want to emphasise that this is a VERY BAD IDEA and I am ASTOUNDED at the number of sites that have implemented such a contract, and even more astounded that some so-called experts have suggested using such a design. Doing so just shows that the implementer has no idea that the same result can be much more easily achieved by setting the VRF Policy Control Enforcement Direction to UNENFORCED and is setting the environment up to run into the exact problem you have in the future.
    • If the design calls for all traffic to be permitted between all EPGs in a VRF, achieve this using Preferred Groups as my esteemed colleagues have pointed out.
  3. Never use Taboo Contracts. And avoid using deny statements in all contracts, life will be simpler if you go to the trouble of sorting out what services each EPG needs to provide, and which services each EPG needs to consume, and creating appropriate contracts for each service.

So now comes the tricky question of how to apply these rules to your situation.  These are the steps I'd recommend, assuming the EPGs you wish to isolate are EPG.A and EPG.B:

Part 1: Preferred Groups

  1. Enable Preferred Groups in the VRF: Tenants > YourTenant > Networking > VRFs > YourVRF >| [Policy] tab
  2. Make each EPG except EPG.A and EPG.B members of the preferred group: Tenants > YourTenant > Application Profiles > YourAppProf > Application EPGs > Each_EPG_in_turn >| [Policy] >| [General]

Part 2: Filters and Contracts:
This is the tricky bit, and has several sub-stages:

Individual EPGs stage

  1. Identify what services need to be PROVIDED by EPG.A. In other words, examine all the listening TCP/UDP ports in all the endpoints in EPG.A
  2. Create a filter based on each service, typically named after the service, such as SQL.Service_Fltr and add the appropriate TCP (or UDP) port(s) for that service as the destination port.
    • Tip: Create all filters in the common tenant
    • If you have services that negotiate TCP/UDP ports dynamically, such as FTP, then you are screwed - ACI is NOT able to to handle traffic at the Application layer. (I've always wondered why ACI is actually called Application Centric Infrastructure). If this is the case forget all the above and work out how to use a firewall.
  3. Create a Contract to accumulate all the different services for EPG.A that are to be made available to EPG.B. Perhaps call this EPG.A.to.EPG.B.Services_Ct.
  4. Have EPG.A provide this contract
  5. Have EPG.B consume this contract
  6. Repeat steps 1-5 above swapping EPG.B with EPG.A (if only ONE EPG is actually providing any services, this step may not be necessary)

EPG.A and EPG.B services stage. In this case, I'm assuming that the remaining EPGs that are communicating happily with each other using Preferred Groups as described in Part 1 will be allowed to consume all services from both EPG.A and EPG.B, and both EPG.A and EPG.B will be allowed to consume all services from all other EPGs

  1. Create a Contract to accumulate all the different services for EPG.A that are to be made available to all the other EPGs.  Recall you created filters for ALL services for EPG.A in step 2 above. Perhaps call this EPG.A.All.Services_Ct.
  2. Have EPG.A provide this contract
  3. Have each other EPG consume this contract
  4. Repeat steps i-iii above swapping EPG.B with EPG.A 

Other EPG Services stage. In this case, I'm assuming that both EPG.A and EPG.B will be allowed to consume all services from all other EPGs.

  1. Create a filter that allows all traffic - there is one in the common tenant called default, but I prefer to spell it out and create an All.IP.Traffic_Fltr and restrict it to all IP traffic rather than the default ALL traffic.
  2. Have every EPG EXCEPT EPG.A and EPG.B provide this contract
  3. Have EPG.A and EPG.B consume this 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


 

 

RedNectar
aka Chris Welsh


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

View solution in original post

"RedNectar's Rules for ACI contracts" - love it!

Fantastic ! Explanation RedNectar.... 

 

@ Sergiu : You mean to add one more rule in Contract Rule Group with Deny all and then apply . is it...

Yes, but with lower priority, because by default deny filters have higher preference.