Common Causes of "Unknown" Leaf State

 

 Common Causes of "Unknown" Leaf State

• Certificate Issues: The leaf might not be presenting a valid certificate chain to the APIC, which prevents proper SSL handshake and authentication.

• LLDP Mismatch or Failure: ACI relies on LLDP (Link Layer Discovery Protocol) for fabric discovery. If LLDP info isn’t exchanged correctly between APIC and leaf, discovery fails.

• Firmware Incompatibility: The leaf switch might be running a version of ACI software that’s not compatible with the APIC or spine switches.

• Hardware Problems: Faulty transceivers, cables, or ports can block communication between APIC and leaf.

• Time Sync Issues: If the leaf’s system time is out of sync with the APIC, certificate validation may fail.

• Incorrect Node ID or Serial Number: If the leaf was previously part of another fabric or misconfigured, it may need to be wiped and re-initialized.

ACI Contracts Components - Contacts Vs Filters Vs Aliases Vs Labels

 In Cisco ACI (Application Centric Infrastructure), Contracts are a key component of the policy model, used to define how endpoints (EPGs) communicate with each other. Within contracts, the terms Labels, Filters, Aliases, and Subjects each play distinct roles. Here's a breakdown of each:

---

🔹 1. Filters

• Purpose: Define the actual traffic (protocols, ports) that is allowed or denied.
• Details:
• Filters are composed of entries specifying Layer 4 information like TCP/UDP ports and protocols.
• They are reusable across multiple contracts.
• Example: A filter might allow TCP traffic on port 80 (HTTP).

---

🔹 2. Subjects

• Purpose: Act as containers within a contract that reference filters and define directionality.
• Details:
• A contract can have multiple subjects.
• Each subject can reference one or more filters.
• You can specify whether the traffic is unidirectional or bidirectional.
• Example: A subject might define that HTTP traffic is allowed from EPG A to EPG B.

---

🔹 3. Aliases

• Purpose: Provide a way to abstract or alias filters for reuse or simplification.
• Details:
• Aliases are less commonly used and are more relevant in complex policy models.
• They can help in referencing filters indirectly, making policy definitions more modular.

---

🔹 4. Labels

• Purpose: Used for categorization and policy enforcement.
• Details:
• Labels can be applied to contracts, EPGs, and other objects.
• They help in grouping and applying policies based on tags.
• Useful in large environments for automation and policy scaling.

---

🧩 How They Work Together in a Contract

• A Contract contains one or more Subjects.
• Each Subject references one or more Filters (or Aliases to filters).
• Labels can be used to tag contracts or EPGs for organizational or policy purposes.

 

Difference between Aliases and Labels - Aliases VS Labels - Cisco ACI

 

Feature	Aliases	Labels
Purpose	Abstract reference to filters for modular contract design	Tagging mechanism for categorization and automation
Used In	Subjects within Contracts	EPGs, Contracts, Bridge Domains, Application Profiles, etc.
Functionality	Indirectly reference filters to simplify reuse	Group and organize objects; used in automation workflows
Visibility	Internal, technical use	Administrative, visible in UI and automation tools
Example Use Case	Reuse a common filter across multiple subjects	Tag all web-tier contracts with web-tier for easy grouping
Impact on Policy	Affects how filters are applied in traffic rules	Helps in applying policies based on tags or roles
Automation Role	Minimal	Significant (used in scripts, templates, etc.)

 

Choosing the Right Cisco 10G SFP+: A Simple Comparison Guide

🟢 Standard Modules

These are full-featured and support everything (including FCoE, OTN, etc.).

• SFP-10G-SR: Short range (up to 400m on multimode fiber)
• SFP-10G-LR: Long range (up to 10km on single-mode fiber)
• SFP-10G-ER: Extended range (up to 40km)
• SFP-10G-ZR: Ultra-long range (up to 80km)

✅ Supports all protocols
✅ TAA compliant
✅ Good for enterprise/data center use

---

🔵 S-Class Modules (e.g., SFP-10G-SR-S, LR-S, ER-S, ZR-S)

These are cost-effective versions of standard modules.

• Same distance and fiber type as standard ones
• ❌ No FCoE support
• ❌ Not TAA compliant
• ✅ Cheaper

Use these if you don’t need advanced features like Fibre Channel over Ethernet.

---

🟠 Special Environment Modules

For harsh or non-standard environments:

• SFP-10G-SR-X: Extended temperature (-5°C to 85°C)
• SFP-10G-SR-I: Industrial temperature (-40°C to 85°C)
• SFP-10G-T-X: Copper (RJ-45), up to 30m at 10G

 

Taboo vs vzAny Contract

 

Aspect	Taboo Contract	vzAny Contract
Purpose	Used to explicitly deny certain types of traffic for an EPG	Used to apply contracts to all EPGs within a VRF in a simplified manner
Functionality	Acts 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 Scope	Applied to individual EPGs to block traffic	Applied to entire VRF, affecting all EPGs within it
Use Case	Prevent specific traffic types (e.g., cleartext communication)	Enable free intra-VRF communication or many-to-one service consumption
Configuration Complexity	Requires manual filter creation and careful application	Simplifies configuration by automating contract relationships
TCAM Usage	May consume more TCAM entries depending on filter granularity	Optimizes TCAM usage by reducing entries to a single group-level contract
Best Practices	Generally discouraged unless absolutely necessary 1	Recommended for efficient policy management in large-scale environments 2 3
Limitations	Not suitable for inter-EPG communication control	Must follow strict guidelines to avoid unintended traffic leaks 2 3

What is a Taboo Contract?

 In Cisco ACI (Application Centric Infrastructure), a taboo contract is a special type of contract used to explicitly deny specific types of traffic between endpoint groups (EPGs), even if other contracts would otherwise allow it.

🔍 What is a Taboo Contract?

• Purpose: Taboo contracts are designed to block traffic that matches certain filters. They override any other contracts that might permit that traffic.
• Application: Unlike standard contracts which are applied between EPGs (one consuming and one providing), taboo contracts are applied to an entire EPG. This means they affect all traffic originating from or destined to that EPG 

• Use Case: For example, if you want to ensure that an EPG never uses insecure protocols like HTTP (port 80) or Telnet (port 23), you can apply a taboo contract with filters for those ports 

🛑 Key Characteristics

• Deny Action: Taboo contracts only support the "deny" action. They are used to block traffic, not to permit it.
• Logging: Optionally, taboo contracts can also log the denied traffic for auditing or troubleshooting purposes 
• Priority: They take precedence over regular contracts. If a packet matches a taboo filter, it is dropped—even if a regular contract would otherwise allow it 

⚠️ Best Practices & Cautions

• Many experts recommend avoiding taboo contracts unless absolutely necessary. Instead, it's often better to design your standard contracts carefully to only permit the desired traffic 
• Taboo contracts can add complexity and may lead to unintended traffic drops if not managed properly

 

Cisco ACI - Flood in Encapsulation

🧠 What Is "Flood in Encapsulation"?

Flood in encapsulation is a setting in Cisco ACI that controls how broadcast or unknown traffic is handled within a bridge domain when multiple EPGs use different VLANs.

---

📦 Example Scenario

Let’s say:

• EPG1 uses VLAN X
• EPG2 uses VLAN Y
• Both EPGs are part of the same bridge domain

If flood in encapsulation is enabled, then:

• Broadcast or unknown traffic from EPG1 will only flood within VLAN X
• It won’t reach EPG2 (VLAN Y), even though they share the same bridge domain

---

✅ Why Use It?

This helps limit unnecessary traffic between EPGs and improves security and performance by keeping flooding local to each VLAN.