Showing posts with label vzAny contract. Show all posts
Showing posts with label vzAny contract. Show all posts

Tuesday, 26 August 2025

What is a Contract Preferred Group in ACI?

 🔷 What is a Contract Preferred Group in ACI?

In Cisco ACI, Endpoint Groups (EPGs) typically require contracts to communicate with each other. This follows the “allow list” model, where communication is explicitly permitted only if a contract exists.

The Preferred Group (PG) feature simplifies this by allowing certain EPGs within the same VRF to communicate freely without contracts.


Key Concepts

Term

Description

Included EPGs

EPGs that are part of the preferred group and can communicate with each other without contracts.

Excluded EPGs

EPGs outside the preferred group that still require contracts to communicate.

VRF PG Setting

Must be enabled for the preferred group to work. Without this, even included EPGs won’t communicate freely.


🛠️ Configuration Steps

  1. Enable Preferred Group on VRF:
    • Go to the VRF settings in APIC or Nexus Dashboard Orchestrator (NDO).
    • Check the Preferred Group box.
  2. Add EPGs to the Preferred Group:
    • In the EPG properties, check Include in Preferred Group.
    • Save the configuration.
  3. Verify Membership:
    • You can view all EPGs in the preferred group under the VRF’s properties.

🌐 Multi-Site Considerations

  • In a stretched VRF across multiple sites, preferred group EPGs are shadowed in other sites to enable inter-site communication.
  • This allows, for example, a web EPG in Site 1 to communicate with an app EPG in Site 2 without contracts.

⚠️ Limitations

  • Preferred Groups are not supported for L3Out external EPGs.
  • If vzAny is already consuming/providing a contract in the VRF, you should not configure preferred groups.
  • All EPGs in a preferred group must be managed consistently (either all via APIC or all via NDO).

 

Monday, 18 August 2025

Taboo vs vzAny Contract

 

AspectTaboo ContractvzAny Contract
PurposeUsed to explicitly deny certain types of traffic for an EPGUsed to apply contracts to all EPGs within a VRF in a simplified manner
FunctionalityActs as a deny filter for specific traffic (e.g., block port 80 or 23)Acts as a wildcard to apply contracts to all EPGs in a VRF
Application ScopeApplied to individual EPGs to block trafficApplied to entire VRF, affecting all EPGs within it
Use CasePrevent specific traffic types (e.g., cleartext communication)Enable free intra-VRF communication or many-to-one service consumption
Configuration ComplexityRequires manual filter creation and careful applicationSimplifies configuration by automating contract relationships
TCAM UsageMay consume more TCAM entries depending on filter granularityOptimizes TCAM usage by reducing entries to a single group-level contract
Best PracticesGenerally discouraged unless absolutely necessary Recommended for efficient policy management in large-scale environments
LimitationsNot suitable for inter-EPG communication controlMust follow strict guidelines to avoid unintended traffic leaks