Contract with vzAny & Priority

What is vzAny?

In Cisco ACI, each VRF automatically has a special object called vzAny:

• It represents all EPGs inside that VRF.

• Instead of attaching a contract to every single EPG, you can attach the contract once to vzAny.

• This is particularly useful for shared services such as DNS, NTP, or Syslog.

Think of vzAny as a shortcut: “apply this contract to all EPGs in this VRF.”

Why Use vzAny with Shared Services?

Shared infrastructure services are usually provided centrally and consumed by many EPGs.Instead of configuring the contract separately on every EPG, vzAny lets you do it once.

Example:

• NTP servers are placed in an EPG.

• An NTP contract allows UDP port 123.

• Instead of attaching this contract to 50+ application EPGs, bind it to vzAny → now every EPG in that VRF can use the NTP service.

The vzAny managed entity offers a means to link all Endpoint Groups (EPGs) within a Virtual Routing and Forwarding (VRF) instance to one or multiple contracts (vzBrCP), eliminating the need to establish individual contract relationships for each EPG.

 This ensures that whenever a new EPG is introduced to a VRF, vzAny contract rules are applied automatically.

The vzAny entity includes all entities within the same Virtual Routing and Forwarding (VRF), including internal EPGs within application profiles, external EPGs for L2Outs and L3Outs, as well as out-of-band or in-band EPGs (External Management Network Instance Profile in the APIC user interface) in the management tenant.

While vzAny is supported as a consumer for a shared service, it is not supported in the role of a provider for a shared service.

Please note that utilizing vzAny as a consumer for a shared service contract implies that any entity within the consumer VRF can establish communication with the provider application in the provider VRF.

When the contract scope associated with vzAny involves the Application Profile, the leaf switches will not consolidate zoning rules with pcTag 0. Instead, they will program multiple zoning rules with the individual pcTag of each Endpoint Group (EPG).

While this approach simplifies configuration, it does not contribute to saving policy TCAM usage.

Contract Priority

EPG Hierarchy:

More-specific EPGs take precedence over vzAny and preferred groups.

EPG Relationships:

EPG-to-EPG (priority 7 or 9) overrides EPG-to-vzAny (priority 13 or 15) and vzAny-to-EPG (priority 14 or 16), which in turn overrides vzAny-to-vzAny (priority 17 or 20).

Source-Destination Priority:

Specific source prioritized over specific destination (e.g., EPG-to-vzAny over vzAny-to-EPG).

Layer 4 Specificity:

More-specific Layer 4 (IP) rules take precedence (unspecified)

Filter Specificity:

Specific filters override "any" filters (e.g., EPG-to-EPG contract with a specific filter over one with a default filter).

Destination-Source Priority:

Specific destination prioritized over specific source (e.g., sport-any-to-dport-80 over sport-80-to-dport-any).

Deny Actions and Protocol Specificity:

Deny actions and specific protocols take precedence.

Log and Action Priority:

Within the same zoning-rule priority, deny + log prevails over deny, which prevails over redirect or permit action.

Redirect and Permit Specificity:

Between redirect and permit actions, more specific protocol and specific Layer 4 port prevail.

Action Resolution:

Between redirect and permit, if filters are identical, redirect prevails over permit. If filter rules overlap in ports and have the same priority, the resolution is non-deterministic. Conflicting rules of this type should be avoided for deterministic actions.

Priority Order:

Lower priority numbers denote higher precedence; hence, rules with lower values (i.e., higher priority) take precedence over those with higher values (i.e., lower priority).

Understanding vzAny with NTP Contract (Provider/Consumer for Common Services)

Topology

• Tenant: infra-services

• VRF: VRF-SHARED

• NTP EPG: EPG-NTP-SERVERS (represents the physical/VM NTP servers)

• Contract: CON-NTP with filter udp/123

• vzAny: the built-in “all EPGs in VRF-SHARED”

Step-by-Step Configuration

Step A – Create Filter

Tenant: infra-services

Object: Filter

Name: FLT-NTP

Protocol: UDP

Source Port: any

Destination Port: 123

Step B – Create Contract

Tenant: infra-services

Object: Contract

Name: CON-NTP

Subject: NTP-SUBJ

Filter: FLT-NTP

Step C – Bind NTP EPG as Provider

EPG: EPG-NTP-SERVERS

Provided Contracts: CON-NTP

Step D – Bind vzAny as Consumer

VRF: VRF-SHARED

vzAny → Consumed Contracts: CON-NTP

Result: All EPGs in VRF-SHARED can consume the NTP service.

Verification

In APIC GUI

• Go to: Tenant → VRF-SHARED → vzAny → Operational → Contracts

• You should see:

  • Provider: EPG-NTP-SERVERS

  • Consumer: vzAny

  • Contract: CON-NTP (UDP/123)

On Leaf Switch CLI

show zoning-rule | grep CON-NTP

Expected output snippet:

Consumer EPG Provider EPG Contract

vzAny EPG-NTP-SERVERS CON-NTP

Outcome

• Every application EPG in VRF-SHARED can now reach the NTP servers without additional config.

• Future EPGs added to this VRF automatically inherit the contract through vzAny.

Things to Watch Out For

• Correct Role: Using vzAny as Consumer is the common pattern for shared services.

• Provider Limitation: vzAny should not be used as a Provider in Service Graph contracts (this triggers fault F0467).

• Scope: Contracts bound to vzAny apply to all EPGs in the VRF. Use carefully if you want strict segmentation.

Summary

• vzAny is a VRF-wide shortcut for contract policies.

• Ideal for common/shared services (DNS, NTP, Syslog).

• Best practice: Keep vzAny as Consumer for shared infra services.

• Do not use vzAny as Provider in Service Graph contracts → unsupported and will raise F0467.