Chapter 1. New and Changed Information

New Features and Changed Behavior in Cisco APIC

Cisco APIC Release Version

Feature

Description

What Changed

Release 2.2(1n)

Preferred Group Member

Support for vzAny marked as a Preferred Group Member, allowing communications between EPGs in the group without a contract.

--

Release 1.0(1e)

This feature was introduced.

--

--

- What vzAny Is

- How vzAny Works

- vzAny Guidelines and Limitations

What vzAny Is

The vzAny managed object provides a convenient way of associating all endpoint groups (EPGs) in a Virtual Routing and Forwarding (VRF) instance to one or more contracts (vzBrCP), instead of creating a separate contract relation for each EPG.

In the Cisco ACI fabric, EPGs can only communicate with other EPGs according to contract rules. A relationship between an EPG and a contract specifies whether the EPG provides the communications defined by the contract rules, consumes them, or both. By dynamically applying contract rules to all EPGs in a VRF, 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.

Note

In the APIC GUI under tenants, a VRF is also known as a private network (a network within a tenant) or a context.

In the case of shared services, you must define the provider EPG shared subnet under the EPG in order to properly derive the pcTag (classification) of the destination from the consumer (vzAny) side. If you are migrating from a BD-to-BD shared services configuration, where both the consumer and provider subnets are defined under bridge domains, to vzAny acting as a shared service consumer, you must take an extra configuration step where you add the provider subnet to the EPG with the shared flags at minimum.

Note

If you add the EPG subnet as a duplicate of the defined BD subnet, ensure that both definitions of the subnet always have the same flags defined. Failure to do so can result in unexpected fabric forwarding behavior.

To use vzAny, navigate to Tenants > tenant-name > Networking > VRFs > vrf-name > EPG Collection for VRF.

How vzAny Works

The following scenarios illustrate how vzAny works:

- EPG contract provider and consumer relations without using vzAny

- vzAny is the consumer and one EPG is the provider

- vzAny is the provider and one EPG is the consumer

- vzAny is the provider and the consumer

EPG1 provides FTP to EPG2 and EPG3 without using vzAny

Using vzAny, Any EPG in the Context Consumes the FTP that EPG1 Provides

Using vzAny, Any EPG in the Context Provides the FTP that EPG1 Consumes

Using vzAny, Any EPG in the Context can Consumer and Provide FTP

While these scenarios illustrate very simple configurations, large production systems can easily have thousands of contract relationships in a single VRF. In such cases, vzAny could eliminate half or more of the contract relationships. This simplification not only makes the configuration much easier to maintain but can also save on switch TCAM buffer consumption.

vzAny Guidelines and Limitations

Observe the following guidelines when using vzAny:

- All EPGs in a VRF can take the role of a provider, a consumer, or both depending on the configuration.

- In addition to application profile EPGs, vzAny providers and consumers include external EPGs such as l2extOut and l3extOut, and endpoint groups for out-of-band (mgmtOoB) or in-band (mgmtInB) access.

- vzAny is supported as a consumer of a shared service but is not supported as a provider of a shared service.

- vzAny implicitly permits all subnets. When vzAny is in use for a VRF, it also includes the L3out, hence it is equivalent to having created a L3external classification that includes the subnets specified in the VRF itself.

- If an EPG, within a VRF, is consuming a shared service contract from an EPG of a different VRF (that we call provider VRF), the traffic from the EPG of the provider VRF is filtered within the consumer VRF. vzAny is equivalent to a wildcard for the source or destination EPG. Be careful when you configure a contract with a vzAny in the consumer VRF because the vzAny contracts may also apply to the traffic between the EPG of the provider VRF and the EPG of the consumer VRF.

Note

Failure to observe this guideline could allow unintended traffic between EPGs across VRFs.

- Configuring a VRF with vzAny as both the provider and the consumer, and with the default allow all filter, is the same as configuring an unenforced VRF. The unenforced VRF is a simpler configuration that produces the same result. In addition, all EPGs within that VRF are free to communicate to each other without a contract. If vzAny is marked as a Preferred Group Member, only those EPGs marked as a Preferred Group Member will be able to communicate with each other without a contract. Alternatively, any EPG, within that VRF that is not marked as a Preferred Group Member, will be unable to communicate without a contract

Note

It is not recommended to enable Preferred Group Member (marked as Include) for vzAny when configuring a VRF with vzAny as both the provider and the consumer, and with the default allow all filter, due to it then disables the ability for all EPGs within that VRF to communicate without a contract.

- If the contract scope is application-profile, the vzAny configuration is ignored and filter rules are expanded; CAM utilization is the same as if specific consumers and providers are deployed. In this case, there is no saving in CAM usage.

- Since vzAny dynamically enables its contract rules for any current or future EPG in a VRF, good practice is to document such configurations.

- In the case of shared services using inter-VRF contracts, you must define the provider EPG shared subnet under the EPG in order to properly derive the pcTag (classification) of the destination from the consumer (vzAny) side. If you are migrating from a BD-to-BD shared services configuration, where both the consumer and provider subnets are defined under bridge domains, to vzAny acting as a shared service consumer, you must take an extra configuration step where you add the provider subnet to the EPG with the shared flags at minimum.

Note

For inter-VRF contracts, if you add the EPG subnet as a duplicate of the defined BD subnet, ensure that both definitions of the subnet always have the same flags defined. Failure to do so can result in unexpected fabric forwarding behavior.

Trademarks

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS REFERENCED IN THIS DOCUMENTATION ARE SUBJECT TO CHANGE WITHOUT NOTICE. EXCEPT AS MAY OTHERWISE BE AGREED BY CISCO IN WRITING, ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS DOCUMENTATION ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.

The Cisco End User License Agreement and any supplemental license terms govern your use of any Cisco software, including this product documentation, and are located at: http://www.cisco.com/go/softwareterms.Cisco product warranty information is available at http://www.cisco.com/go/warranty. US Federal Communications Commission Notices are found here http://www.cisco.com/c/en/us/products/us-fcc-notice.html.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any products and features described herein as in development or available at a future date remain in varying stages of development and will be offered on a when-and if-available basis. Any such product or feature roadmaps are subject to change at the sole discretion of Cisco and Cisco will have no liability for delay in the delivery or failure to deliver any products or feature roadmap items that may be set forth in this document.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com go trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)