Debounce Timer in Cisco ACI

Understanding Interface Flapping and the Debounce Timer in Cisco ACI

Interface flapping on Cisco ACI leaf switches is one of the most commonly misunderstood issues in environments connected to WAN, DWDM, dark fiber, or service-provider transport networks.

A frequent question from engineers is:

“Why does the interface continue to flap even though a 100 ms debounce timer is configured?”

What Is the Debounce Timer in Cisco ACI?

In Cisco ACI (Nexus 9000 Series leaf switches), the debounce timer is a Layer-1 interface stabilization mechanism applied to physical Ethernet interfaces.

Its purpose is to delay link-state transitions (up/down) in order to suppress rapid state changes caused by brief physical interruptions—conditions that are common when connecting to transport, WAN, or service-provider networks.

Key Characteristics

• Configured per physical Ethernet interface

• Time specified in milliseconds

• Valid range: 1–5000 ms

• A value of 0 disables debounce

• Applies only to physical interfaces (not port-channels directly)

Common Use Cases

• 10G / 25G / 40G / 100G uplinks

• DWDM, OTN, UVN, WAN, and dark-fiber circuits

Why the Debounce Timer Exists

Cisco introduced the debounce timer to solve a very specific real-world problem:

High-speed Ethernet ports connected to transport networks may experience brief physical interruptions during protection switching or reconvergence, which can generate repeated link-state changes even when no true failure exists.

Typical Scenarios

• Optical protection switching

• Momentary loss of light (LOS)

• Transceiver Tx power transitioning to N/A

• Short break-link events during transport reconvergence

• Micro-interruptions that do not represent an actual outage

Without Debounce

• Interfaces immediately go down

• Port-channels recalculate

• ACI endpoint learning resets

• Routing adjacencies bounce

• Applications experience unnecessary disruption

The debounce timer exists to protect the control plane from physical-layer noise, not to mask real failures.

What the Debounce Timer Actually Does ?

Functional Behavior

When a Nexus leaf detects a link-down condition at the PHY:

1. The switch waits for the configured debounce interval.

2. If the link recovers within that interval:

   • The link-down event is suppressed.

   • No flap is registered.

3. If the link remains down longer than the debounce interval:

   • The interface is declared down.

   • A full down/up transition occurs.

In simple terms:The debounce timer filters short-duration noise, not genuine outages.

What the Debounce Timer Does Not Do?

This is where most misconceptions arise. The debounce timer:

• ❌ Does not prevent loss of signal at the PHY

• ❌ Does not fix optical instability

• ❌ Does not suppress CRC errors or giant frames

• ❌ Does not hide outages longer than the configured value

• ❌ Does not guarantee a “no-flap” condition

If the actual loss of signal exceeds the debounce interval, a flap is expected and correct behavior.

Why a 100 ms Debounce Is Often Insufficient ?

In DWDM, UVN, and WAN environments, a 100 ms debounce is frequently too small to absorb real transport-layer behavior.

Cisco best practice is to:

• Start at 500 ms

• Increase in 500 ms increments

• Stop once the link stabilises

Why 100 ms Fails in Practice

Transport vendors often advertise “<50 ms protection switching,” but this typically refers to internal transport convergence, not what the customer-facing optical interface experiences.

At the Cisco PHY, the interface may see:

• Longer LOS than expected

• Multiple short LOS events back-to-back

• Tx power resets

• Laser shut/no-shut behavior

Individually, these events may be brief—but cumulatively they often exceed 100 ms.

Result

• Debounce expires

• Interface flaps

• Debounce is blamed incorrectly

In reality, the debounce timer is functioning exactly as designed.

Cisco-Recommended Debounce Strategy

Cisco’s documented guidance is straightforward:

• Start with 500 ms

• Increase in 500 ms increments

• Stop when stability is achieved

• Balance against failure-detection requirements

Example Configuration

interface ethernet x/y
  link debounce time 500

If instability persists:

link debounce time 1000

This approach aligns debounce behavior with real physical conditions, not theoretical transport SLAs.

Link MAC-Up Timer

Cisco also provides the link mac-up timer, specifically designed for DWDM and dark-fiber links.

Purpose

• Delays the MAC-layer UP state after physical signal restoration

• Prevents rapid up/down oscillation following protection switching

  
  
  
  

  Note: This feature should only be used on DWDM links.

Example

interface ethernet x/y
  link mac-up timer 10

Design Logic

• Debounce timer smooths the DOWN transition

• MAC-up timer smooths the UP transition

Used together, these timers significantly improve interface stability on transport-connected links.

How to Troubleshoot Debounce-Related Flaps in ACI ?

Step 1: Verify Debounce Configuration

show interface debounce

Confirm that:

• The interface is listed

• The configured value is correct

Step 2: Measure the Actual Outage Duration (Most Important)

show system internal ethpm event-history interface ethernet x/y

If the DOWN → UP duration exceeds the debounce value, the observed flap is expected behavior.

Step 3: Check Physical Error Indicators

show interface ethernet x/y counters errors

CRC errors or giant frames indicate genuine physical-layer issues, not debounce failure.

Step 4: Review Optical Health

show interface ethernet x/y transceiver details

Look for:

• Rx/Tx power fluctuations

• N/A states

• Alarms or warnings

Step 5: Tune Timers and Retest

Adjust debounce and MAC-up timers using Cisco-recommended increments and validate during known transport events.

Design Considerations and Trade-Offs

Increasing debounce improves stability, but it comes with trade-offs:

Benefit	Trade-Off
Fewer interface flaps	Slower failure detection
Stable port-channels	Delayed convergence
Reduced control-plane churn	Longer detection of real outages

This is a design choice, not a defect.

For WAN and DWDM circuits, stability is usually more valuable than millisecond-level failure detection.

APIC GUI Configuration steps :

You are already in the right place:

APIC → Fabric → Fabric Policies → Policies → Interface → Link Level

Step 1 — Create a NEW Link Level Policy (recommended)

Don’t edit “default” unless you intentionally want it global.

1. Go to: Fabric → Fabric Policies → Policies → Interface → Link Level

2. Click Create (or “+”)

3. Give it a name, e.g.:

   • LLP_WAN_Debounce_500ms

4. Set:

   • Link debounce interval (msec): 500

5. Save/Submit

Apply the policy to the correct interfaces (the part people miss)

Creating the policy alone doesn’t change the port. You must attach it via the interface policy group used by that port.

Host-facing / L3Out / external-facing ports

Typical case: leaf port is in an interface policy group (Access / PC / vPC policy group).

Steps:

1. Go to: Fabric → Access Policies

2. Find the Interface Policy Group used by the affected port:

   • For single port: Leaf Interface Policy Group

   • For port-channel: Port Channel Policy Group

   • For vPC: vPC Interface Policy Group

3. Edit that policy group

4. In the Link Level Policy field, select your new policy:

   • LLP_WAN_Debounce_500ms

5. Submit

6. Confirm the interface policy group is actually mapped to the port via:

   • Leaf Interface Profile → Leaf Selector → Interface Selector

   
   
   
   

   Tip : If only one circuit is unstable, create a dedicated policy group for that circuit so you don’t impact other ports.

Cisco guidance for WAN/DWDM/Service Provider style links is to start from 500 ms and increase in 500 ms intervals until stable.

Conclusion

The debounce timer in Cisco ACI:

• Is a link-state stabilization tool, not a fix for physical problems

• Works exactly as documented

• Requires proper tuning for transport-connected links

• Must be evaluated based on actual PHY behavior, not theoretical SLAs