Showing posts with label ACI Symmetric Hashing. Show all posts
Showing posts with label ACI Symmetric Hashing. Show all posts

Sunday, 3 August 2025

Forward Error Correction (FEC) in Cisco ACI

 In Cisco ACIForward Error Correction (FEC) is a mechanism used to improve the reliability of high-speed data transmission across physical links, especially in environments using 25G, 40G, 100G, or 400G interfaces.

🔍 What Is Forward Error Correction?

FEC is a technique where the sender adds redundant data (parity bits) to each transmission. If some bits are corrupted during transit, the receiver can detect and correct those errors without needing a retransmission. Think of it like sending a puzzle with extra pieces so the receiver can still complete it even if a few pieces go missing.

🧠 How FEC Works in Cisco ACI

In ACI, FEC is negotiated between switches and endpoints during auto-negotiation. The devices advertise their supported FEC modes and agree on the best one. Common FEC modes include:

  • FC-FEC (Firecode FEC): Used for 25G links.
  • RS-FEC (Reed-Solomon FEC): Used for 25G, 100G, and 400G links.
  • CL91-RS-FEC and IEEE-RS-FEC: Advanced versions for higher speeds.
  • AUTO-FEC: Automatically selects the best FEC mode based on link capabilities.

⚙️ Why It Matters

FEC is especially important in Cisco ACI because:

  • High-speed links (like 25G or 100G) are more prone to bit errors.
  • Breakout ports (e.g., 4x25G from a 100G port) often require FEC to maintain link stability.
  • Copper DAC cables used in short-distance connections rely on FEC to compensate for signal degradation.

Use Cases

  • Ensuring error-free transmission over high-speed links.
  • Supporting auto-negotiation on breakout ports.
  • Enhancing link reliability without increasing latency or requiring retransmissions.

 

Symmetric hashing in Cisco ACI

 

🔄 Symmetric Hashing in Cisco ACI: A Traffic Balancing Philosophy

Imagine a highway with multiple lanes, and cars (data packets) trying to reach their destination. Normally, each car chooses a lane based on its starting point and destination. But what if the return journey picks a different lane? That’s what happens with asymmetric hashing — the forward and reverse paths of a data flow may travel through different physical links.

In Cisco ACI, symmetric hashing is like a rule that says: “If you go out through lane 3, you must come back through lane 3.” It ensures that both directions of a traffic flow — from source to destination and back — follow the same physical path within a port channel.

This matters a lot when you're dealing with devices like firewalls, load balancers, or any system that tracks sessions. If traffic enters through one link and exits through another, it can confuse these devices, leading to dropped packets or broken connections.


Symmetric hashing is not supported on the following switches:
  • Cisco Nexus 93128TX
  • Cisco Nexus 9372PX
  • Cisco Nexus 9372PX-E
  • Cisco Nexus 9372TX
  • Cisco Nexus 9372TX-E
  • Cisco Nexus 9396PX
  • Cisco Nexus 9396TX

🧠 Why Cisco ACI Made It Optional

Cisco ACI’s default behavior is asymmetric — it spreads traffic across links based on a hash of various packet fields (IP, MAC, ports). This works well for general load balancing. But when precision and consistency are needed, ACI gives you the option to enable symmetric hashing in the port-channel policy.

Once enabled, you can choose the hashing algorithm — like using only IP addresses or including Layer 4 ports — to fine-tune how traffic is distributed.

Use Cases That Benefit

  • Firewall clusters that expect consistent ingress/egress paths.
  • Load balancers that rely on session stickiness.
  • Troubleshooting scenarios where symmetric paths simplify packet tracing.