vzAny managed objects provide a convenient way of associating all endpoint groups in a Virtual Routing and Forwarding (VRF) instance to one or more contracts (vzBrCP) instead of creating a separate contract relation for each EPG. vzAny automates the process of configuring EPG contract relationships. Whenever a new EPG is added to a VRF, vzAny contract rules automatically apply. The vzAny one-to-all EPG relationship is the most efficient way of applying contract rules to all EPGs in a VRF.
To understand how the contract and vzAny work, assume you have an EPG called WebServer providing a contract called HTTPS being consumed by EPG users. The HTTPS contract is built on a filter-specifying destination port (DP)=443—without a specific source port.
The most straightforward way to apply this contract is with both the Apply Both Directions and Reverse Filter Ports options checked, as shown in Figure 4-26.
Figure 4-26 Contract with Default Option
The way the contract works is that the selected filter is applied to traffic coming from the consumer to the provider, so traffic with a DP=443 is permitted. When you enable Apply Both Directions, the filter is also used for traffic traveling from the provider to the consumer, but because the Reverse Filter Ports option is checked, the contract will reverse the source/destination port for reverse traffic and allow traffic with a source port (SP)=443.
In normal operation, this is the contract functionality. The contract permits forward traffic from the consumer to the provider and returns traffic in the opposite direction.
Now assume that you remove the Reverse Filter Ports option. The contract is still applied in both directions, but with DP=443 in each direction—essentially removing the whole idea of consumer and provider because only traffic with DP=443 would be allowed. No return traffic would get through, unless you added another contract to allow traffic with SP=443 to pass, as shown in Figure 4-27.
Figure 4-27 Contract with One-Way Traffic
If you disable both options, one direction of the traffic is permitted, but this option is optimal because it uses a single ternary content-addressable memory (TCAM) entry rather than two TCAM entries when both directions are enabled with the reverse path disabled, as shown in Figure 4-28.
Figure 4-28 Contract with Both Subject Options Disabled
In the preceding example, you need a different contract and filter to allow the return traffic with SP=443, but there is a cleverer way of doing this using a special EPG called the vzAny EPG.
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.
The idea is that you can create a contract that allows all TCP traffic with the ACK flag set; you can use a predefined filter 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 Figure 4-29, the HTTPS contracts allow traffic from the consuming EPGs to reach the providing EPGs, while the established contract allows universal traffic between EPGs as long as the TCP session is established. Essentially, the HTTPS 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, as in Figure 4-29.
Figure 4-29 vzAny Contract Example
The ACI filter properties example in Figure 4-30 shows filter protocol, provider/consumer source port or range, and provider/consumer destination port or range.
