Eigrp Unequal Cost Load balancing

Today, revisiting a topic from my earlier lab days back in 2011, I found myself reflecting on EIGRP’s unequal cost load balancing. It’s a foundational concept in routing, and while network architectures have evolved dramatically, understanding these mechanisms remains crucial for anyone diving deep into network engineering, especially for maintaining legacy systems or troubleshooting complex routing behaviors. Back then, getting the desired result after hours of lab work was a eureka moment, and I’m updating this post now to share a 2025 perspective on this powerful, albeit now more niche, EIGRP feature. Kindly tell me if I’m missing any modern nuances!

One of the most important factors in choosing EIGRP as an IGP in the early 2010s, and a unique selling point even today for specific scenarios, is its ability to perform unequal cost load balancing. To enable this feature in EIGRP, we need to issue the `variance` command under the EIGRP process. For a path to be considered for unequal cost load balancing, it must be a feasible successor with a metric less than or equal to the successor’s metric times the variance.

Feasible Distance (FD) is the best metric to a destination learned via a successor. Advertised Distance (AD) is the metric reported by a neighbor to that destination.

A path whose advertised distance is lower than the feasible distance of the successor is deemed as a feasible successor.

Note: Only routes that are feasible successors can be used for unequal cost load balancing. This is a critical EIGRP rule, ensuring loop-free paths by maintaining a backup path that is “closer” to the destination than the current best path.

The formula for EIGRP Metric calculation, by default, is a composite metric that takes into account several parameters:

Metric = [k1 * bandwidth + (k2 * bandwidth)/(256 – load) + k3 * delay] *[k5/(reliability + k4)]

The “k” values are derived from the `metric weights` command. By default, K1 and K3 are set to 1, and all other values (K2, K4, K5) are set to 0. This essentially means that only bandwidth and delay are taken into account for the default metric calculation. “Bandwidth” is derived from the inverse bandwidth in Kbps times 10⁷ (10⁷/BWKbps). “Delay” is delay in tens of microseconds (DLYusec/10). These values are added together and then scaled by a factor of 256. The composite metric is therefore represented by default as:

Metric = (10⁷/BWKbps + DLYusec/10) * 256

Note: From an operational perspective, try to adjust Delay values instead of Bandwidth when performing traffic engineering. Changing the bandwidth setting on an interface can drastically affect traffic handling in the network, particularly if QoS mechanisms like policing, shaping, or scheduling are relying on that bandwidth value. Modifying delay is generally a safer method for influencing EIGRP routing without unintended side effects on QoS.

In order to achieve any desired ratio, suppose we want to distribute traffic in a ratio of 3:1 among the successors and feasible successors. If we are primarily manipulating delay, we can set up our equation like so (assuming BW1 and BW2 are taken directly from the interfaces, and we’re solving for Delay):

3 * [(10⁷/BW1 in Kbps) + (Delay1 in usec/10)] * 256 = [(10⁷/BW2 in Kbps) + (Delay2 in usec/10)] * 256

Here in the above formula, watch out for BW1, Delay1, BW2, and Delay2, ensuring they correspond to the correct paths. By taking BW1 and BW2 as they are from the interface, you can find a relationship, for example, Delay1 = (something) * Delay2, allowing you to derive the required delay value for one path relative to the other to achieve your desired load-sharing ratio.

Once you’ve determined the appropriate delay values, you can apply them to the respective interfaces. Then, verify your configuration and the resulting traffic distribution by using the following commands:

Router# show ip route [destination network address] | include traffic|share

Check the “traffic share count” in the output to see the exact distribution ratio between both paths. Also, don’t forget to include the `variance` command in the EIGRP process; without it, unequal cost load balancing will not occur.

To examine the EIGRP topology and verify feasible successors:

Router# show ip eigrp topology [destination network address]

This command will show you the successor and any feasible successors, along with their respective metrics and advertised distances, allowing you to confirm that your delay adjustments and variance settings are having the desired effect.

—

EIGRP in the Modern Network: SDN, Automation, and Controller-Based Deployments (2025 Perspective)

While EIGRP unequal cost load balancing remains a potent feature, its role in modern network architectures has shifted significantly since this post was first published. In 2025, greenfield enterprise and data center deployments are overwhelmingly leaning towards Software-Defined Networking (SDN), model-driven automation, and a strong emphasis on open standards.

• SDN and Intent-Based Networking (IBN): Platforms like Cisco DNA Center and Cisco ACI (Application Centric Infrastructure) abstract away much of the underlying routing protocol configuration. While EIGRP can still run on devices managed by these controllers, the preferred protocols for new, intent-driven fabrics are often OSPFv3, IS-IS, or BGP (especially for EVPN in data centers). These protocols offer better programmability and easier integration with model-driven configuration (NETCONF/RESTCONF) and telemetry (gNMI).
• Cloud and Hybrid Cloud: In hybrid and multi-cloud environments, BGP is the de-facto standard for inter-domain routing, connecting on-premises networks to cloud providers. EIGRP, being a Cisco-proprietary protocol, doesn’t translate well into these heterogeneous environments.
• SD-WAN: Solutions like Cisco SD-WAN (Viptela) use overlay routing protocols (often BGP or OMP – Overlay Management Protocol) to manage traffic steering across diverse underlay networks. While the underlay might still use an IGP like EIGRP, the intelligent load balancing and path selection are managed at the overlay level by the SD-WAN controller, often overshadowing the need for manual EIGRP variance tuning.

EIGRP is not obsolete, especially in large existing Cisco-centric environments. It’s robust and performs well. However, for new designs focused on automation, open standards, and multi-vendor interoperability, engineers typically opt for OSPF, IS-IS, or BGP due to their broader ecosystem support and deeper integration with modern automation tools and telemetry.

Automating Routing Policy and Path Changes in 2025

Manually calculating and applying `delay` values and `variance` settings, while illustrative, is prone to human error and time-consuming in large networks. In 2025, network automation is not a luxury, but a necessity for implementing and verifying such routing policy changes.

Here’s how network automation frameworks and tools come into play:

1. **Desired State Configuration:** Instead of directly typing CLI commands, engineers define the desired state of their network using data models (e.g., YANG) and templating engines (e.g., Jinja2).
2. **Configuration Generation:** Automation tools like Ansible or Nornir can consume these data models and templates to generate the exact EIGRP `delay` and `variance` commands for multiple devices. For example, a playbook could iterate through a list of interfaces and calculate the optimal delay for each path based on predefined criteria, then push the configuration.

# Example Ansible Playbook Snippet for EIGRP Variance/Delay
- name: Configure EIGRP Unequal Cost Load Balancing
  hosts: routers
  gather_facts: false

  vars:
    eigrp_as_number: 100
    variance_multiplier: 3 # Based on calculation for desired ratio
    interface_delays:
      GigabitEthernet0/1: 1000 # Example calculated delay in microseconds/10
      GigabitEthernet0/2: 3000

  tasks:
    - name: Ensure EIGRP variance is configured
      cisco.ios.ios_config:
        lines:
          - "router eigrp {{ eigrp_as_number }}"
          - "variance {{ variance_multiplier }}"
        match: strict
        diff_against: running

    - name: Apply specific interface delays
      cisco.ios.ios_config:
        lines:
          - "interface {{ item.key }}"
          - "delay {{ item.value }}"
        parents: "interface {{ item.key }}"
        match: strict
        diff_against: running
      loop: "{{ interface_delays | dict2items }}"
    

3. Deployment and Validation:

• NAPALM/Netmiko: Libraries like NAPALM or Netmiko within Python scripts or automation frameworks handle the connection and configuration pushing (e.g., `interface GigabitEthernet0/1`, `delay 1000`).
• Pre/Post-Checks: Before applying changes, `show` commands (`show ip eigrp topology`, `show ip route`) are collected. After changes, the same commands are run again to validate the outcome. Tools like pyATS can parse this output programmatically, comparing states and ensuring the load balancing is configured as expected (e.g., checking “traffic share count”). This drastically reduces the risk of misconfigurations.
• Telemetry: For ongoing monitoring, streaming telemetry (e.g., via gNMI) can provide real-time updates on interface metrics, routing table changes, and traffic statistics, allowing for proactive adjustments or anomaly detection.

By leveraging automation, network engineers can implement complex EIGRP traffic engineering policies with greater accuracy, speed, and confidence, moving away from manual “hours in the lab” to programmatic, repeatable deployments.

Conclusion

In conclusion, EIGRP unequal cost load balancing remains a testament to the protocol’s intelligent path selection capabilities. While the networking landscape has evolved towards SDN and automation, understanding the underlying principles of feasible successors, composite metrics, and the `variance` command is still highly valuable. The modern approach, however, shifts from manual CLI adjustments to defining desired states and deploying changes programmatically through automation tools, ensuring efficiency, accuracy, and robust verification in an increasingly complex and dynamic network environment.

• About
• Latest Posts

Afroz Ahmad

I'm Afroz, a Network Engineer and CCIE with 17 years of experience in Computer Networking, Data Centers, Telecom, Internet Services and ISPs. Currently, I work as a Network Designer for a leading ISP equipment vendor. I share my expertise through my blog and courses, aiming to share my knowledge and simplify complex networking concepts for both beginners and experienced professionals.

Latest posts by Afroz Ahmad (see all)

• Justifying a $50k or even Higher Annual Switch Upgrade: What Must-Have Features Are We Missing? - November 13, 2025
• Managing Overlapping Private IPs in Multi-Client Site-to-Site VPNs: Best Practices? - November 7, 2025
• Epson EpiqVision Flex CO-W01 Projector Review - February 21, 2025