Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

EIGRP Unequal Cost Load Balancing: Why Variance Is the Weaker of Two Conditions

Network Infrastructure ｜ Concept ｜ Advanced ｜ 21 min read

EIGRP is the only widely deployed IGP that will load balance across paths of different cost, and the command that enables it is one line. That makes variance look simpler than it is. The multiplier does not, on its own, decide which paths get installed. It supplies one of two conditions, and the other condition — the feasibility test — is the one that silently rejects most of the paths people expect variance to unlock. An engineer who sets variance 4 on a router with an obvious backup path and sees no change in the routing table has hit exactly this, and no amount of raising the multiplier will help.

A path is installed as an unequal-cost route only if it is a feasible successor — its advertised distance is strictly less than the local feasible distance — and its total metric is no greater than the variance multiplier times the feasible distance. The first condition is about loop freedom and cannot be relaxed by configuration. The second is about how much worse a path you are willing to use. Variance controls only the second. A path that fails the feasibility test is not a candidate at any multiplier, which means the fix in that situation is to change the metric so the path becomes feasible, not to raise the variance.

This article covers unequal-cost load balancing end to end. Section one defines exactly what variance does and what the two conditions are. Section two explains why raising it often changes nothing, and how to make a non-feasible path feasible. Section three is the configuration — variance, maximum-paths, and the traffic-share options that decide whether the installed paths actually carry traffic. Section four is verification, including how to prove that a specific flow is using a specific link. Section five covers when unequal-cost load balancing is the wrong answer, which is more often than its reputation suggests.

Blog ClaimVariance is the weaker of the two conditions for installing an unequal-cost path — the feasibility test is the one that actually decides, which is why the correct response to "variance is not working" is almost always a delay adjustment rather than a larger multiplier.
 
The two-condition test: feasibility is evaluated first and is not configurable, so a path that fails it is rejected regardless of how large the variance multiplier is — even when its total metric is well inside the threshold.

What Does the Variance Command Actually Do?

What are the two conditions for installing an unequal-cost path?

A path is installed alongside the successor only when both hold. First, the path must be a feasible successor: the neighbour's advertised distance must be strictly less than the local feasible distance. This is the loop-freedom guarantee and no command relaxes it. Second, the path's total metric must be less than or equal to the variance multiplier times the feasible distance. Variance defaults to 1, which makes the threshold equal to the FD itself and therefore permits only paths with an identical metric — ordinary equal-cost load balancing. Raising it to 2 permits any feasible successor up to twice the best metric.

A Deeper Dive into the Mechanism

Why the default is 1 and what that means

With variance 1 the threshold equals the feasible distance, so only paths whose total metric exactly matches the best are installed. Those paths are also, by definition, feasible successors, so the first condition is satisfied automatically. This is why equal-cost load balancing appears to need no configuration — it is variance 1 doing its job, and every EIGRP router does it out of the box up to maximum-paths.

! Equal-cost: two paths with identical metrics, variance untouched
R1# show ip route 10.9.9.0
Routing entry for 10.9.9.0/24
  Known via "eigrp 100", distance 90, metric 3072
  Routing Descriptor Blocks:
  * 10.0.12.2, from 10.0.12.2, 00:14:22 ago, via GigabitEthernet0/1
      Route metric is 3072, traffic share count is 1
    10.0.13.3, from 10.0.13.3, 00:14:22 ago, via GigabitEthernet0/2
      Route metric is 3072, traffic share count is 1
! ^ Equal metrics, equal share. No variance command involved.

The threshold arithmetic, worked

The threshold is variance multiplied by the feasible distance, not by the successor's current metric. Those are usually the same number, but they diverge after a topology change that raised the successor's metric without the route going active — in which case the threshold is computed from the older, lower FD and is therefore tighter than you might expect.

! FD 3072, variance 3 -> threshold 9216
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  topology base
   variance 3
   maximum-paths 4
  exit-af-topology
 exit-address-family
!
R1# show ip eigrp topology 10.9.9.0/24
  State is Passive, Query origin flag is 1, 3 Successor(s), FD is 3072
  Descriptor Blocks:
  10.0.12.2 (Gi0/1), from 10.0.12.2
      Composite metric is (3072/1792), route is Internal
  10.0.13.3 (Gi0/2), from 10.0.13.3
      Composite metric is (5120/2816), route is Internal
  10.0.15.5 (Gi0/4), from 10.0.15.5
      Composite metric is (8960/2560), route is Internal
! ^ All three: AD below 3072, and total metric at or below 9216.
!   '3 Successor(s)' here means three installed paths.

What the RIB metric means when several paths are installed

With unequal-cost paths installed, the routing table shows a single metric on the Routing entry line — the successor's — while each descriptor block carries its own. That single number is what gets compared against other routing protocols for administrative-distance purposes and what gets redistributed onward if you redistribute EIGRP elsewhere. The more expensive installed paths contribute nothing to it. This matters when a downstream protocol is making its own decision based on the redistributed metric: it will see the best path's cost, not a blend, and will therefore assume better connectivity than the aggregate actually provides.

R1# show ip route 10.9.9.0 | include Known via|Route metric
  Known via "eigrp 100", distance 90, metric 3072, type internal
      Route metric is 3072, traffic share count is 5
      Route metric is 5120, traffic share count is 3
! ^ The entry-level metric 3072 is the successor's. Redistribution
!   and AD comparison both use that value, not 5120 and not a blend.

What variance does not do

  • It does not override the feasibility condition. A path with an advertised distance at or above the FD is never installed, at any multiplier.
  • It does not change which path is the successor. The lowest-metric path remains the successor and the RIB metric shown is the successor's metric.
  • It does not distribute traffic evenly. Distribution is proportional to the inverse of the metric unless you change traffic-share.
  • It does not raise the ceiling on installed paths. That is maximum-paths, which is a separate limit applied after both tests.
  • It does not apply across autonomous systems or to routes learned from another protocol before redistribution.
Setting Range Default Controls Where configured
variance 1–128 1 How much worse than FD a feasible path may be topology base (named) or router mode (classic)
maximum-paths 1–32 (platform dependent) 4 How many paths may be installed in total topology base or router mode
traffic-share balanced — Default Traffic proportional to inverse of metric topology base or router mode
traffic-share min across-interfaces — Off Install all paths but send only over the best topology base or router mode
Why variance goes to 128 and why you should notThe multiplier accepts values up to 128, which would permit a path 128 times worse than the best. Nothing in EIGRP prevents that, and the traffic-share calculation would send a proportionally tiny fraction over it — but that fraction still experiences the latency and jitter of the slow path, and TCP flows hashed onto it perform badly while everything looks healthy in aggregate. In practice a multiplier above 2 or 3 is difficult to justify.
Compute the threshold before you configureRead FD is N from the topology entry, multiply by your intended variance, and then check each candidate's total metric against it. If the candidate you care about does not appear in show ip eigrp topology at all, the problem is feasibility and the threshold is irrelevant — that is the case covered in the next section.
Sub claimVariance sets a ceiling on how much worse a path may be, and nothing else — every other aspect of unequal-cost load balancing is governed by the feasibility condition, maximum-paths, or traffic-share.

Why Does Increasing Variance Sometimes Change Nothing?

What is the usual explanation?

The path you want is not a feasible successor. Variance widens the metric threshold, but a path whose advertised distance is at or above the feasible distance was never a candidate to begin with, so widening the threshold has nothing to act on. The diagnostic is show ip eigrp topology all-links, which reveals paths excluded by the feasibility test — they do not appear in the ordinary topology output. The fix is to reduce the advertised distance that neighbour is sending, which means lowering the delay on interfaces along that path, or to raise the local feasible distance, which happens only through the active process.

A Deeper Dive into Non-Feasible Paths

Seeing the rejected candidate

! Ordinary topology output - the path simply is not there
R1# show ip eigrp topology 10.9.9.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
  Descriptor Blocks:
  10.0.12.2 (Gi0/1), from 10.0.12.2
      Composite metric is (3072/1792), route is Internal
!
! all-links reveals what was excluded and why
R1# show ip eigrp topology all-links 10.9.9.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
  Descriptor Blocks:
  10.0.12.2 (Gi0/1), from 10.0.12.2
      Composite metric is (3072/1792), route is Internal
  10.0.14.4 (Gi0/3), from 10.0.14.4
      Composite metric is (4096/3584), route is Internal
! ^ AD 3584 is NOT less than FD 3072. Rejected by test 1.
!   Total metric 4096 would pass variance 2 easily - irrelevant.

Making a path feasible by lowering its advertised distance

The advertised distance is computed by the neighbour, from its own path to the destination. To reduce it you must reduce the metric somewhere along that neighbour's path — typically by lowering the delay on an interface upstream of it. Delay is the correct instrument because it is cumulative and because it is read by EIGRP and almost nothing else, whereas bandwidth is consumed by QoS policies, SNMP reporting, and NetFlow calculations.

! On R4 (or upstream of it): reduce delay so its AD falls below R1's FD
R4(config)# interface GigabitEthernet0/1
R4(config-if)# delay 5
! ^ delay is in tens of microseconds. 5 = 50 usec.
!
! Back on R1, the AD has dropped and the path now qualifies
R1# show ip eigrp topology 10.9.9.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 3072
  10.0.12.2 (Gi0/1), from 10.0.12.2
      Composite metric is (3072/1792), route is Internal
  10.0.14.4 (Gi0/3), from 10.0.14.4
      Composite metric is (3840/2816), route is Internal
! ^ AD 2816 < FD 3072. Feasible. And 3840 <= 2 x 3072 = 6144.

How much delay to change, and where

Delay is configured in tens of microseconds and contributes to the metric as the cumulative sum divided by ten, scaled by 256. That gives a workable rule: every unit of delay removed from an interface reduces the metric by 256 for every router downstream of it. To close a gap of 768 between an advertised distance and a feasible distance you need to remove three units of delay somewhere along that path — and it must be on a link the neighbour's own path traverses, not on your link to the neighbour, because your link cost affects the total metric rather than the advertised distance.

That last distinction is the one people get wrong. Lowering the delay on your own interface toward the neighbour reduces the total metric, which helps with the variance threshold and does nothing for feasibility. Only a change upstream of the neighbour reduces what it advertises.

! Gap to close: AD 3584 must drop below FD 3072, so at least 512.
! Each unit of 'delay' removed = 256 off the metric. Remove 2 units.
!
! WRONG - this is R1's own link. Changes total metric, not AD.
R1(config)# interface GigabitEthernet0/3
R1(config-if)# delay 8
!
! RIGHT - upstream of R4, on the path R4 uses to the destination
R4(config)# interface GigabitEthernet0/1
R4(config-if)# delay 8
! Default Gigabit delay is 10. Setting 8 removes 2 units = 512.
!
! Confirm the advertised distance actually moved
R1# show ip eigrp topology all-links 10.9.9.0/24 | include 10.0.14.4
  10.0.14.4 (Gi0/3), from 10.0.14.4
      Composite metric is (3584/3072), route is Internal
! ^ Still not strictly less than FD 3072. Remove one more unit.

The other lever: raising the local feasible distance

A higher FD makes the feasibility test easier to pass, because more advertised distances fall below it. But FD is a historical minimum and only recomputes when the route goes active — you cannot raise it directly. What you can do is make the successor's path genuinely more expensive and then force the route through the active process, after which the new FD reflects the higher metric. This is a blunt approach and is rarely the right answer in production, because it degrades the primary path to improve the backup.

Pitfall: raising variance repeatedly with no effect Symptom: variance 2, then 4, then 10 are applied in turn and the routing table never gains a second path, despite an obvious physical alternative. Cause: the alternative path fails the feasibility condition, so it is not a candidate at any multiplier. Confirm: show ip eigrp topology all-links <prefix> and compare each advertised distance — the second number in each metric pair — against FD is N. Fix: lower the delay on interfaces along the alternative path so the neighbour advertises a smaller distance. Revert the inflated variance afterwards; leaving it at 10 permits genuinely poor paths once feasibility changes for some other prefix.
Change delay in small steps and re-checkA delay adjustment propagates to every downstream router and changes their feasible distances too, which can create a feasible successor in one place while removing one somewhere else. Move one or two units at a time, verify the intended prefix, then spot-check a handful of others on neighbouring routers before moving further. A large single change is far harder to reason about than three small ones.
The asymmetric-topology caseHub-and-spoke designs produce this constantly. A spoke's backup path to another spoke goes up to the hub and back down, so its advertised distance includes both legs and is usually higher than the spoke's own direct FD. No variance setting will make that path usable. The architectural answers are a direct spoke-to-spoke path, summarisation that changes the metrics involved, or accepting that the backup requires the active process.
Sub claimWhen variance appears not to work, the multiplier is never the problem — the candidate failed a test that runs before variance is consulted, and all-links is the only output that shows it.

How Do I Configure Variance and Control Traffic Distribution?

What are the three commands and what does each control?

variance sets the metric threshold. maximum-paths caps how many paths may be installed once both tests pass — it defaults to 4, and a router with six qualifying paths installs the four best. traffic-share decides how the installed paths are used: balanced, the default, distributes traffic inversely proportional to metric, so a path twice as expensive receives roughly half as much; min across-interfaces installs every qualifying path in the RIB but sends traffic only over the lowest-metric ones, which gives instant failover without ever using a slower path in steady state.

A Deeper Dive into Configuration

Named mode and classic mode side by side

! ===== NAMED MODE: all three live in topology base =====
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  topology base
   variance 2
   maximum-paths 6
   traffic-share balanced
  exit-af-topology
 exit-address-family
!
! ===== CLASSIC MODE: router configuration mode =====
router eigrp 100
 variance 2
 maximum-paths 6
 traffic-share balanced
 network 10.0.0.0

traffic-share balanced: proportional, not equal

The default distributes load inversely to the metric. A path with metric 3072 and a path with metric 5120 do not each carry half the traffic; the cheaper path carries proportionally more. IOS expresses this with a traffic share count per path in show ip route, and CEF uses those counts to weight its hash buckets. The counts are relative integers, not percentages.

R1# show ip route 10.9.9.0
Routing entry for 10.9.9.0/24
  Known via "eigrp 100", distance 90, metric 3072
  Routing Descriptor Blocks:
  * 10.0.12.2, from 10.0.12.2, 00:02:14 ago, via GigabitEthernet0/1
      Route metric is 3072, traffic share count is 5
    10.0.13.3, from 10.0.13.3, 00:02:14 ago, via GigabitEthernet0/2
      Route metric is 5120, traffic share count is 3
! ^ 5:3 in favour of the cheaper path. Roughly the inverse of the
!   metric ratio 3072:5120. Not 50/50.

traffic-share min across-interfaces: redundancy without using the slow path

This option installs the qualifying paths in the RIB so failover is immediate, but restricts forwarding to the minimum-metric paths. It is the right choice when the backup exists purely for resilience and using it in steady state would hurt — a low-bandwidth or high-latency circuit that must be available but should carry nothing until the primary fails.

! Install for failover, but forward only over the best path
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  topology base
   variance 4
   traffic-share min across-interfaces
  exit-af-topology
 exit-address-family
!
R1# show ip route 10.9.9.0
  Routing Descriptor Blocks:
  * 10.0.12.2, from 10.0.12.2, via GigabitEthernet0/1
      Route metric is 3072, traffic share count is 1
    10.0.13.3, from 10.0.13.3, via GigabitEthernet0/2
      Route metric is 9216, traffic share count is 0
! ^ Share count 0 = installed and ready, but carrying no traffic.

Applying variance on a live network

The change itself is non-disruptive in the sense that no adjacency resets and no route is withdrawn — EIGRP simply recomputes which paths qualify and updates the RIB. What does change immediately is the forwarding behaviour of every prefix that gains a second path, so flows that were pinned to one interface begin hashing across two. On a network with stateful devices in the path, that redistribution is the risk, not the routing change. Apply it during a window, and check the prefixes you care about rather than assuming the effect is uniform: variance acts per prefix, so some destinations may gain a second path while others gain none.

! Count how many prefixes gained a second path after the change
R1# show ip route eigrp | count via
Number of lines which match regexp = 63
! ...compare against the same count before. The difference is the
! number of additional next hops variance introduced.
!
! Rollback is a single line and takes effect immediately
R1(config-router-af-topology)# variance 1

maximum-paths as a separate ceiling

Both tests can pass for more paths than you want in the forwarding table. maximum-paths applies afterwards and keeps the lowest-metric ones. Setting it to 1 is a legitimate way to disable all load balancing including equal-cost, which is occasionally required when an upstream device cannot tolerate flows arriving on multiple interfaces.

! Disable load balancing entirely, including equal-cost
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  topology base
   maximum-paths 1
  exit-af-topology
 exit-address-family
!
! Verify the effective settings the process is running with
R1# show eigrp protocols | include Maximum path|variance
    Maximum path: 1
    Maximum metric variance 2

Variance and summaries, externals, and mixed route types

Three route categories behave differently and are worth knowing before you rely on variance in a real topology. A summary route generated locally has an advertised distance of zero from the Null0 interface and a metric derived from the best component, so it can mask the unequal-cost behaviour of the specifics it replaces — downstream routers see one summary with one metric and no unequal-cost opportunity at all. External routes, redistributed into EIGRP, carry the metric assigned at redistribution rather than one derived from the path, so two externals redistributed with identical seed metrics will always be equal-cost regardless of how different the underlying paths are. And EIGRP never load balances between an internal and an external route for the same prefix, because administrative distance 90 beats 170 before variance is ever consulted.

! Externals inherit the seed metric, not the path's real cost
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  topology base
   ! bw(kbps) delay(tens of usec) reliability load mtu
   redistribute ospf 1 metric 1000000 100 255 1 1500
   variance 2
  exit-af-topology
 exit-address-family
!
R1# show ip route 172.20.0.0
Routing entry for 172.20.0.0/16
  Known via "eigrp 100", distance 170, metric 2570240, type external
! ^ AD 170 marks it external. An internal route to the same prefix
!   at AD 90 would win outright, with no variance evaluation.
!
! A locally generated summary hides the specifics entirely
R1# show ip eigrp topology 10.1.0.0/16 | include via
      via Summary (2816/0), Null0
! ^ AD 0 from Null0. Downstream sees one path, one metric.

How the packets are actually distributed

Traffic share counts describe intent; CEF performs the distribution. By default CEF load-shares per destination — more precisely, per flow, using a hash over source and destination addresses — so a single conversation stays on one path. Per-packet load sharing exists but reorders packets and is a poor fit for TCP and for anything latency-sensitive. This means unequal-cost load balancing distributes conversations, not bandwidth, and a small number of large flows will not divide neatly no matter what the share counts say.

! Confirm the load-sharing algorithm in use
R1# show ip cef 10.9.9.0/24 internal | include load|share
  per-destination sharing
!
! Per-packet is available but rarely appropriate
interface GigabitEthernet0/1
 ! ip load-sharing per-packet
 ip load-sharing per-destination
!
! Change the hash inputs if distribution is uneven
ip cef load-sharing algorithm universal
! Alternatives: original, tunnel, include-ports source destination
Goal variance traffic-share maximum-paths Result
Equal-cost only (default) 1 balanced 4 Identical-metric paths share evenly
Use a somewhat worse backup 2 balanced 4 Backup carries a proportional share
Backup for failover only 4 min across-interfaces 4 Installed, share count 0, instant failover
No load balancing at all 1 — 1 Single path in the RIB
Wide multi-path fabric 1 balanced 8–16 Many equal-cost paths, even distribution
Start with min across-interfacesIf the reason for enabling variance is resilience rather than capacity, traffic-share min across-interfaces gives you the failover benefit with none of the risk of routing production traffic over a slow circuit. Move to balanced only when you have measured that the secondary path can carry its proportional share acceptably.
Sub claimVariance decides which paths are installed and traffic-share decides whether they carry anything — conflating the two is why networks end up sending real traffic over a backup circuit that was only ever meant to sit ready.

How Do I Verify That Traffic Is Actually Using Both Paths?

What proves it rather than suggesting it?

Three layers, in order. The topology table proves the path passed both tests. The routing table proves it was installed and shows its traffic share count. CEF proves how a specific flow will actually be forwarded — show ip cef exact-route takes a source and destination and names the egress interface, which is the only output that answers "which link will this conversation take". Interface counters then confirm the distribution in aggregate. Stopping at the routing table is the common mistake, because a path installed with a share count of zero appears identical to one carrying traffic.

A Deeper Dive into Verification

Layer 1: the topology table

R1# show ip eigrp topology 10.9.9.0/24 | include Successor|Composite
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 3072
      Composite metric is (3072/1792), route is Internal
      Composite metric is (5120/2816), route is Internal
! '2 Successor(s)' with variance configured means two installed paths.

Layer 2: the routing table and share counts

R1# show ip route 10.9.9.0
Routing entry for 10.9.9.0/24
  Known via "eigrp 100", distance 90, metric 3072, type internal
  Redistributing via eigrp 100
  Last update from 10.0.13.3 on GigabitEthernet0/2, 00:04:41 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 10.0.12.2, 00:04:41 ago, via GigabitEthernet0/1
      Route metric is 3072, traffic share count is 5
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    10.0.13.3, from 10.0.13.3, 00:04:41 ago, via GigabitEthernet0/2
      Route metric is 5120, traffic share count is 3
! A share count of 0 on any block means installed but not forwarding.

Layer 3: CEF, which decides per flow

! Which interface will THIS conversation use?
R1# show ip cef exact-route 10.1.1.5 10.9.9.20
10.1.1.5 -> 10.9.9.20 => IP adj out of GigabitEthernet0/1, addr 10.0.12.2
!
R1# show ip cef exact-route 10.1.1.6 10.9.9.20
10.1.1.6 -> 10.9.9.20 => IP adj out of GigabitEthernet0/2, addr 10.0.13.3
! ^ Two sources, two different egress interfaces. The hash is working.
!   The SAME source and destination will always take the same path.
!
! See the weighted bucket allocation behind those answers
R1# show ip cef 10.9.9.0/24 internal | include bucket|share

Layer 4: interface counters over time

! Aggregate confirmation - do the rates match the share counts?
R1# show interfaces GigabitEthernet0/1 | include 5 minute output
  5 minute output rate 612000000 bits/sec, 58000 packets/sec
R1# show interfaces GigabitEthernet0/2 | include 5 minute output
  5 minute output rate 371000000 bits/sec, 35000 packets/sec
! ^ Roughly 5:3, matching the traffic share counts. With few large
!   flows the ratio will be far less clean - that is CEF hashing,
!   not a variance problem.
Question Command Healthy indicator Failure indicator
Did the path pass both tests? show ip eigrp topology <prefix> More than one Successor 1 Successor; check all-links
Was it installed? show ip route <prefix> Multiple descriptor blocks One block despite variance
Will it carry traffic? show ip route <prefix> Non-zero traffic share count Share count 0
Which path for this flow? show ip cef exact-route <src> <dst> Different flows name different interfaces Every flow names the same one
Is the split as intended? show interfaces rates Ratio approximates the share counts One interface near zero
Are the settings in effect? show eigrp protocols Expected variance and maximum path Values differ from the configuration
Pitfall: concluding load balancing failed from interface counters alone Symptom: two paths are installed with sensible share counts, but one interface carries almost all the traffic and the other is nearly idle. Cause: CEF hashes per flow, so a small number of high-volume conversations will not distribute evenly regardless of the share counts. Three large backup streams cannot be split five ways. Confirm: show ip cef exact-route for the specific source and destination pairs that dominate — they will all resolve to the same interface. Fix: nothing in EIGRP addresses this. Change the CEF load-sharing algorithm to include Layer 4 ports if the flows differ there, or accept that a handful of elephant flows cannot be balanced by a per-flow hash.
Verify after every metric changeBecause feasibility depends on advertised distances that other routers compute, a delay change made elsewhere in the network can silently remove a feasible successor and collapse your unequal-cost path back to one. Adding a topology check for the prefixes that matter to your post-change validation catches it immediately rather than during the next failure.
Sub claimOnly show ip cef exact-route answers what a given conversation will actually do — the routing table describes intent, and a share count of zero looks exactly like a share count of five until you check.

When Is Unequal-Cost Load Balancing the Wrong Answer?

What are the situations where variance hurts?

Four. When the paths differ substantially in latency, because a flow hashed onto the slow path experiences that latency permanently while aggregate statistics look fine. When the secondary path has meaningfully less capacity, because a proportional share of peak traffic can still exceed it. When applications are sensitive to path asymmetry, because return traffic hashes independently and may take the other link. And when the real requirement was resilience rather than capacity, in which case installing the path with traffic-share min across-interfaces delivers the benefit without any of the exposure.

A Deeper Dive into the Failure Modes

Latency disparity and the flows that lose

Traffic share counts distribute conversations, not packets from a single conversation. A voice call or a database session hashed onto a path with 40 ms more latency stays there for its lifetime. Aggregate monitoring shows both links utilised and both healthy; the affected users report a problem that no interface counter reflects. This is the most common reason a variance deployment gets rolled back.

! Measure the difference before enabling, not after
R1# ping 10.9.9.20 source 10.1.1.1 repeat 20
Success rate is 100 percent (20/20), round-trip min/avg/max = 1/2/4 ms
!
! Force the test over the backup by shutting the primary temporarily
R1(config)# interface GigabitEthernet0/1
R1(config-if)# shutdown
R1# ping 10.9.9.20 source 10.1.1.1 repeat 20
Success rate is 100 percent (20/20), round-trip min/avg/max = 38/42/51 ms
! ^ 2 ms versus 42 ms. Do not balance across these two paths.
!   Install for failover with 'traffic-share min across-interfaces'.

Capacity disparity and the proportional-share trap

Share counts are computed from metrics, and metrics are computed from configured bandwidth and delay — not from what the circuit can actually sustain today. A path whose configured bandwidth is optimistic, or a shared circuit whose available capacity varies, will receive a share proportional to its nominal metric and drop traffic when peak arrives. The metric has no feedback loop from real utilisation, and enabling the load coefficient K2 to create one causes route flapping instead.

Pitfall: variance across links with very different real capacity Symptom: after enabling variance, output drops appear on the secondary interface during business-hours peaks while the primary is comfortably below capacity. Aggregate utilisation looks acceptable. Cause: the share count was derived from the configured metric, which does not reflect the secondary path's actual sustainable throughput. Confirm: show interfaces <secondary> | include drops|output rate during peak, compared against the primary. Fix: either correct the delay so the metric ratio reflects reality and the share drops accordingly, or switch to traffic-share min across-interfaces so the secondary carries nothing until it is needed.

Asymmetry, and why it matters more than it used to

Forward and return paths hash independently, on different routers, using different source and destination orderings. Two paths of unequal cost make asymmetric routing considerably more likely. On a network of routers this is harmless. On a network containing stateful firewalls, NAT devices, or anything performing deep inspection, a flow whose two directions traverse different devices will be dropped by the one that never saw the handshake.

! Check both directions of the same conversation
R1# show ip cef exact-route 10.1.1.5 10.9.9.20
10.1.1.5 -> 10.9.9.20 => IP adj out of GigabitEthernet0/1
!
R9# show ip cef exact-route 10.9.9.20 10.1.1.5
10.9.9.20 -> 10.1.1.5 => IP adj out of GigabitEthernet0/2
! ^ Forward and return take different links. Fine between routers;
!   fatal if a stateful device sits on either path.

When it is the right answer

  • Two WAN circuits of similar latency and similar capacity where a single one cannot carry peak load — variance turns the second into usable capacity rather than idle standby.
  • Campus uplinks where the metrics differ only because of a cabling constraint, not because the paths are meaningfully different in quality.
  • Any topology where the requirement is sub-second failover and traffic-share min across-interfaces is used, so the second path is installed but dormant.
  • Data centre fabrics with many equal-cost paths, where variance 1 and a high maximum-paths is the correct configuration and no unequal-cost behaviour is wanted at all.
Situation Use variance? traffic-share Reasoning
Two similar WAN circuits, both needed at peak Yes, 2 balanced Genuine capacity gain, comparable quality
Primary fibre plus a slow backup circuit Yes, 4–8 min across-interfaces Fast failover without using the slow path
Paths differing by tens of milliseconds Only with min min across-interfaces Hashed flows would suffer permanently
Stateful firewall in either path No — Asymmetry breaks connection state
Equal-cost fabric No — leave at 1 balanced Raise maximum-paths instead
Few very large flows Limited value either Per-flow hashing cannot split an elephant
The question that settles itAsk whether you want the second path to carry production traffic on an ordinary Tuesday. If yes, and the paths are comparable in latency and capacity, use variance with balanced. If no, use variance with min across-interfaces and get the failover benefit with none of the risk. Most requirements described as "load balancing" turn out to be the second case.
Exam contextVariance is a P0 topic in the CCIE Enterprise Infrastructure blueprint's EIGRP coverage and is examined as a two-part problem: compute whether a given path qualifies, then configure the multiplier that admits it. The reliably tested trap is a path that satisfies the metric threshold but fails the feasibility condition, where the expected answer is to adjust delay rather than raise variance. ENARSI 300-410 covers the same material including traffic-share and the interaction with maximum-paths.
Sub claimMost requirements phrased as load balancing are resilience requirements, and traffic-share min across-interfaces satisfies them completely while removing every risk that unequal-cost forwarding introduces.

Conclusion

Variance is a threshold, not a permission. It answers one question — how much worse than the best path am I willing to accept — and it answers it only for paths that have already proven themselves loop-free by the feasibility condition. Holding those two tests apart is the whole of understanding the feature. The feasibility test uses the neighbour's advertised distance against your feasible distance and is not configurable; the variance test uses the total metric against a multiple of the feasible distance and is. A path that fails the first is invisible in the ordinary topology output and immune to every value of the second.

That structure dictates the troubleshooting method. When variance appears not to work, go to show ip eigrp topology all-links and compare each candidate's advertised distance against the feasible distance printed on the state line. If the advertised distance is too high, the fix is upstream — lower the delay along that neighbour's path so it advertises a smaller number — and not a larger multiplier. If the advertised distance is fine and the total metric is above the threshold, then and only then is variance the right lever.

Beyond the mechanics, the design question is worth asking before the configuration question. Installing a path and forwarding over it are separate decisions, and traffic-share min across-interfaces separates them cleanly. A great many networks that enabled variance for load balancing actually wanted sub-second failover, got it, and also got production traffic on a circuit that was never sized for it. Build the topology, set variance deliberately high, watch which candidates still fail, then adjust delay upstream until one flips from rejected to installed. The moment it flips is the moment the two conditions stop being an abstraction.

Reference Notes

  1. RFC 7868, Section 3.4.1 — the Feasibility Condition: a neighbour qualifies only when its reported distance is strictly less than the local feasible distance.
  2. RFC 7868, Section 3.4.2 — feasible distance as the minimum computed distance since the route last transitioned from active to passive.
  3. RFC 7868, Section 5.5 — the composite metric and default coefficients K1 = K3 = 1, K2 = K4 = K5 = 0.
  4. Cisco, "How Does Unequal Cost Path Load Balancing Work in IGRP and EIGRP?" — a path is used only if it is a feasible successor and its metric is within the variance multiple of the best metric.
  5. Cisco, "How Does Unequal Cost Path Load Balancing Work in IGRP and EIGRP?" — traffic is distributed in inverse proportion to the metrics of the installed paths.
  6. Cisco IOS-XE EIGRP Configuration Guide — variance accepts a multiplier from 1 to 128, with a default of 1.
  7. Cisco IOS-XE EIGRP Configuration Guide — maximum-paths defaults to 4 and limits the number of paths installed after both conditions are evaluated.
  8. Cisco IOS-XE EIGRP Configuration Guide — traffic-share balanced is the default; traffic-share min across-interfaces installs paths for failover while forwarding only over the minimum-metric paths.
  9. Cisco IOS-XE EIGRP Configuration Guide — in named mode, variance, maximum-paths, and traffic-share are configured under topology base.
  10. Cisco, "How CEF Load Balancing Works" — per-destination load sharing hashes source and destination addresses so a given flow uses a single path.
  11. Cisco, "How CEF Load Balancing Works" — ip cef load-sharing algorithm options and the effect of including Layer 4 ports in the hash.
  12. Cisco IOS-XE EIGRP Configuration Guide — show ip eigrp topology all-links displays paths excluded by the feasibility condition, which are absent from the default topology output.