Accepted Solutions
Hi @AirBorn ,
Great question - and touches on a topic that you really need to understand to get the best out of TCAM resources.
Let's start with an example. Assume you have an EPG called Web providing a contract called HTTP being consumed by EPG User. The HTTP contract is built on a filter specifying Destination Port=80 - no specify source port.
The most straightforward way to apply this contract is with both the Apply Both Directions and Reversse Filter Ports options checked, as shown below:
The way the contract works is that the chosen filter is applied to traffic coming from the Consumer to the Provider, so traffic with a DP=80 is permitted. By checking the Apply Both Directions, the filter is also used for traffic travelling from the Provider to the Consumer, but because the Reverse Filter Ports option is checked, the contract will be allowing traffic with a SP=80 rather than DP=80.
By in large, this is what you want a contract to do - permit forward traffic from the Consumer to the Provider and return traffic in the opposite direction.
Now let's play with those options. Assume you remove the Reverse Filter Ports option. Now the contract is still applied in both directions, but with DP=80 in each direction - essentially removing the whole idea of Consumer and Provider as only traffic with DP=80 would be allowed. No return traffic would get through, unless you added another contract to allow say SP=80 to pass.
What you end up is with a pretty useless contract, and in my opinion, one that shouldn't even be supported in the GUI configuration.
However, the last possible variation (you clearly can't Reverse Filter Ports if you don't Apply in Both Directions) is to only apply in one direction. This option only uses a single TCAM entry rather than two as shown in the above examples.
Again, like the previous example, you will need a different contract and filter to allow the return traffic with SP=80, but there is more clever way of doing this using a special EPG* called vzAny.
vzAny represents the collection of EPGs that belong to the same VRF. Instead of associating contracts to each individual EPG, you can configure a contract to the vzAny EPG which is found under your VRF configuration's EPG Collection for VRF. (Tenant > tenant > Networking > VRF > vrf > EPG Collection for VRF)
The idea is, you create a contract that allows all TCP traffic with the ACK flag set - there is a pre-defined filter for that you can use defined in the common tenant called est. You then make the vzAny EPG both a Consumer and a Provider of this contract which then allows every EPG in that VRF to accept traffic with the ACK flag set but uses only a single TCAM entry for all EPGs.
In the following diagram, the HTTP and SQL contracts allow traffic from the consuming EPGs to reach the providing EPGs, while the Established contract allows universal traffic between EPGs so long as the TCP session is established. Essentially, the HTTP and SQL contracts are only needed to allow the initial TCP SYN packet through to establish the session. all other traffic is handled by the vzAny EPG and its Established 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
* I've been taken to task be a colleague for calling vzAny an EPG. Strictly speaking he's correct of course. It is in fact a special child object of a VRF that can consume and provide contracts just like an EPG. So in the context of providing and consuming contracts, it makes it much easier to undersand by calling it an EPG.
Hi @AirBorn ,
Great question - and touches on a topic that you really need to understand to get the best out of TCAM resources.
Let's start with an example. Assume you have an EPG called Web providing a contract called HTTP being consumed by EPG User. The HTTP contract is built on a filter specifying Destination Port=80 - no specify source port.
The most straightforward way to apply this contract is with both the Apply Both Directions and Reversse Filter Ports options checked, as shown below:
The way the contract works is that the chosen filter is applied to traffic coming from the Consumer to the Provider, so traffic with a DP=80 is permitted. By checking the Apply Both Directions, the filter is also used for traffic travelling from the Provider to the Consumer, but because the Reverse Filter Ports option is checked, the contract will be allowing traffic with a SP=80 rather than DP=80.
By in large, this is what you want a contract to do - permit forward traffic from the Consumer to the Provider and return traffic in the opposite direction.
Now let's play with those options. Assume you remove the Reverse Filter Ports option. Now the contract is still applied in both directions, but with DP=80 in each direction - essentially removing the whole idea of Consumer and Provider as only traffic with DP=80 would be allowed. No return traffic would get through, unless you added another contract to allow say SP=80 to pass.
What you end up is with a pretty useless contract, and in my opinion, one that shouldn't even be supported in the GUI configuration.
However, the last possible variation (you clearly can't Reverse Filter Ports if you don't Apply in Both Directions) is to only apply in one direction. This option only uses a single TCAM entry rather than two as shown in the above examples.
Again, like the previous example, you will need a different contract and filter to allow the return traffic with SP=80, but there is more clever way of doing this using a special EPG* called vzAny.
vzAny represents the collection of EPGs that belong to the same VRF. Instead of associating contracts to each individual EPG, you can configure a contract to the vzAny EPG which is found under your VRF configuration's EPG Collection for VRF. (Tenant > tenant > Networking > VRF > vrf > EPG Collection for VRF)
The idea is, you create a contract that allows all TCP traffic with the ACK flag set - there is a pre-defined filter for that you can use defined in the common tenant called est. You then make the vzAny EPG both a Consumer and a Provider of this contract which then allows every EPG in that VRF to accept traffic with the ACK flag set but uses only a single TCAM entry for all EPGs.
In the following diagram, the HTTP and SQL contracts allow traffic from the consuming EPGs to reach the providing EPGs, while the Established contract allows universal traffic between EPGs so long as the TCP session is established. Essentially, the HTTP and SQL contracts are only needed to allow the initial TCP SYN packet through to establish the session. all other traffic is handled by the vzAny EPG and its Established 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
* I've been taken to task be a colleague for calling vzAny an EPG. Strictly speaking he's correct of course. It is in fact a special child object of a VRF that can consume and provide contracts just like an EPG. So in the context of providing and consuming contracts, it makes it much easier to undersand by calling it an EPG.
@richmond - point taken. I guess I'm kind of stuck in first geration switch thinking mode. So I'll concede to say that the best pracice if you don't have any first generation switches in the fabric is to use my original option #1 but with Policy Compression enabled if you wish to conserve TCAM - which shouldn't be such an issue on later model switches.
So here's a new diagram for my original Option #1 to conserve TCAM.
Note that by enabling policy compression, contract statistics for both directions will be aggregated.
@richmond - Thanks mate ...
...But:
- There is no No-stats box - even though the guide DOES say "When configuring the contract subjects, enable the no stats directive." Instead, the only options to set for directive are: None; Log; Enable Policy Compression
- When you set the Enable Policy Compression directive (as shown in the diagram), a moquery -c actrlRule
shows that the no_stats option is set. (See below)
# actrl.Rule scopeId : 2818053 sPcTag : 32771 dPcTag : 16386 fltId : 257 action : no_stats,permit actrlCfgFailedBmp : actrlCfgFailedTs : 00:00:00:00.000 actrlCfgState : 0 childAction : ctrctName : ChrisTest descr : direction : uni-dir-ignore dn : topology/pod-1/node-102/sys/actrl/scope-2818053/rule-2818053-s-32771-d-16386-f-257 id : 4311 lcOwn : implicit markDscp : unspecified modTs : 2019-05-18T11:34:59.354 monPolDn : uni/tn-common/monepg-default name : nameAlias : operSt : enabled operStQual : prio : fully_qual qosGrp : unspecified rn : rule-2818053-s-32771-d-16386-f-257 status : type : tenant
Above examples are from ACI verison 4.01 - perhaps the No Stats option is from a previous version.
