Accepted Solutions
Hi @joseph1.blanchard ,
Here is a direct cut-and-paste from another answer I gave - I think it might clear up the confusion.
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.
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.
