Part 3 of 5 · Troubleshooting Vault

EIGRP Module C · Enterprise Routing Master Series

Troubleshooting Vault & Production Error Reference

Six real-world EIGRP path tuning failures with authentic syslog messages, root cause analysis, and production-hardened fixes. Each error is documented from live field experience — use this as your on-call reference when load balancing, variance, or offset-lists behave unexpectedly.

Author: Hrishi Pradhan

Level: Basic to Advanced

Errors: 6 Production Scenarios

Fixes: Verified CLI

Troubleshooting Vault

Six production failures with authentic syslog messages and hardened fixes

Critical Errors

How to Use This Vault

Each error below includes the exact syslog message you will see in production, the root cause, the business impact, and the verified CLI fix. Match your syslog to the error heading to jump to the resolution.

1 Offset-List Breaks Feasible Successor Critical

Syslog Message

%DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 10.1.13.2 (Gi0/2) is up: new adjacency
%DUAL-6-DUAL_STATE: Route 10.1.10.0/24 became Active -- no feasible successor
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 10.1.13.2 (Gi0/2) is down: holding time expired

Root Cause

An offset-list was applied to inflate the metric of a specific route on a backup path. The inflation pushed the Reported Distance above the Feasible Distance, breaking the Feasibility Condition. The route lost its Feasible Successor and entered Active state during the next primary link failure.

Business Impact

Route fails to failover instantly — enters Active state during outages
Query propagation across the network when the route is triggered
Extended convergence window (up to 3 minutes before SIA)
Silent misconfiguration — passes validation checks but fails in production

Production Fix

! Step 1: Identify the offset-list in effect
show run | section offset-list
show ip eigrp topology all-links | include 10.1.10.0

! Step 2: Remove or reduce the offset
router eigrp 1234
 no offset-list MATCH_ROUTE in 1000 GigabitEthernet0/2

! OR reduce the offset so RD stays below FD:
router eigrp 1234
 offset-list MATCH_ROUTE in 100 GigabitEthernet0/2

! Step 3: Verify FS returns
show ip eigrp topology 10.1.10.0/24
! Look for "1 successors" with a backup path listed

2 Variance Not Installing Path (Feasibility Failed) Critical

Syslog Message

%DUAL-5-NBRCHANGE: EIGRP-IPv4 1234: Neighbor 10.1.13.2 (Gi0/2) is up: new adjacency
! No syslog explicitly mentions variance
! Symptom is silent: only 1 path installed despite variance 2

Root Cause

Variance was configured, but the candidate path fails the Feasibility Condition. Variance cannot override the Feasibility Condition — it only allows paths that already qualify as Feasible Successors to be installed at unequal cost. If the RD of the candidate is greater than or equal to the FD, the path will never be installed regardless of variance value.

Business Impact

Engineer believes load balancing is active, but only one path carries traffic
Backup link sits completely idle despite adequate bandwidth
Misleading network design decisions based on incorrect assumption
Silent failure — no warning messages in logs

Production Fix

! Step 1: Confirm the Feasibility Condition on the candidate path
show ip eigrp topology all-links | include 10.1.10.0 -A 3

! Look at the RD vs FD values
! If RD >= FD, the candidate path cannot be installed with variance

! Step 2: Verify variance is high enough (once Feasibility passes)
show ip protocols | include variance

! Step 3: If Feasibility fails, adjust the metric to bring RD below FD
! Common approach — reduce delay on the backup path
interface GigabitEthernet0/2
 delay 100

! OR use offset-list on the primary path to raise FD
router eigrp 1234
 offset-list MATCH_ROUTE in 5000 GigabitEthernet0/1

! Step 4: Verify both paths now install
show ip route 10.1.10.0

3 Share Count Disproportional Traffic Distribution Warning

Syslog Message

! No syslog — this is a performance symptom observed via monitoring
! Traffic graphs show one link at 95% utilization, the other at 20%

Root Cause

Traffic is being distributed based on EIGRP's share-count ratio, not on link bandwidth. A high-bandwidth link paired with a much lower-bandwidth backup will receive a share-count ratio proportional to their metrics — which may not match the actual bandwidth ratio. The engineer expected roughly 10:1 traffic split (matching the bandwidth ratio), but the share-count only gives 2:1 or 3:1.

Business Impact

Bandwidth is not evenly utilized despite both paths being "active"
Primary link becomes congested while backup sits idle
Monitoring dashboards show abnormal traffic patterns
Applications experience latency spikes on the congested link

Production Fix

! Step 1: Understand the share count ratio
show ip route 10.1.10.0
! Look for "traffic share count is N" on each path

! Step 2: Calculate actual bandwidth ratio vs share count ratio
! If you need higher traffic on one path, lower its metric further

! Step 3: Adjust metrics to change the share ratio
interface GigabitEthernet0/1
 delay 5
! Reduces metric, increasing share count on this path

! Step 4: Verify the new share ratio
show ip route 10.1.10.0
! Expected: higher share count on the path you want more traffic on

4 Maximum-Path Limit Not Respected Warning

Syslog Message

! No syslog — this is observed via CLI verification
! Expected 6 equal-cost paths, only 4 installed in routing table

Root Cause

The EIGRP maximum-path value is set to its default (4 in classic IOS, 16 in modern IOS). Even though 6 equal-cost paths exist in the topology table, only 4 are being installed because the maximum-path limit has not been raised.

Business Impact

Bandwidth from extra parallel links is not utilized
Traffic distribution is unbalanced on high-bandwidth links
Silent inefficiency — no error messages
Underutilized capacity on dense mesh topologies

Production Fix

! Step 1: Verify the current maximum-path setting
show ip protocols | include Maximum path

! Step 2: Increase maximum-path
router eigrp 1234
 maximum-paths 8
! Allow up to 8 equal-cost paths

! Step 3: Verify all paths are now installed
show ip route 10.1.10.0
! Should now show up to 8 paths

show ip protocols | include Maximum path
! Should now show "Maximum path: 8"

5 Outbound Offset-List Propagated Unexpectedly Critical

Syslog Message

! No syslog — downstream routers experience unexpected metric changes
! Remote sites report path selection flips after neighbor configuration change

Root Cause

An outbound offset-list was applied with a value that is not a multiple of 256. EIGRP internally scales metric values by 256, so outbound offsets are divided by 256 and rounded up when propagated to neighbors. An offset of 1000 is interpreted as 4 on the downstream router — causing unexpected path selection changes for downstream routers.

Business Impact

Downstream routers pick unexpected paths due to unexpected metric inflation
Traffic patterns change silently across the topology
Difficult to diagnose because the local router's own metrics are unchanged
Can cascade into SIA events during primary link failures

Production Fix

! Step 1: Verify outbound offset-list configuration
show run | section offset-list
! Look for any "out" direction entries

! Step 2: Understand the scaling effect
! Offset of 1000 in outbound = 1000/256 rounded up = 4 on downstream
! Always use offset values that are multiples of 256 for predictable results
! Examples: 256, 512, 768, 1024, 2048

! Step 3: Adjust or remove the outbound offset
router eigrp 1234
 no offset-list MATCH_ROUTE out 1000 GigabitEthernet0/1

! OR use a multiple of 256:
router eigrp 1234
 offset-list MATCH_ROUTE out 1024 GigabitEthernet0/1
! This becomes +4 on downstream routers (1024/256 = 4)

! Step 4: Verify on the downstream neighbor
show ip eigrp topology 10.1.10.0/24
! Compare against the intended metric increase

6 Asymmetric Routing from Variance Critical

Syslog Message

! No syslog — observed via application behavior
! TCP sessions fail or reset; firewall logs show asymmetric flows
! Latency and jitter spike for specific applications

Root Cause

Variance enables unequal-cost load balancing, which causes packets for the same flow to be distributed across paths with different latency. This creates asymmetric routing — traffic from A to B goes via path 1, while traffic from B to A goes via path 2. Stateful firewalls, load balancers, and some applications reject or drop the mismatched flows.

Business Impact

Stateful firewalls drop legitimate traffic (asymmetric flow detection)
TCP sessions reset or time out intermittently
Applications report high jitter and variable latency
Difficult to diagnose — pattern depends on which path a flow lands on

Production Fix

! Step 1: Identify whether paths have different latency characteristics
show ip eigrp topology 10.1.10.0/24
! Compare metrics and interface types
! WAN links with different physical latency are the common cause

! Step 2: Decide on the correct fix — three options:

! Option A: Remove variance (disable unequal-cost LB)
router eigrp 1234
 no variance
! Falls back to equal-cost only

! Option B: Tune metrics so paths become equal-cost
interface GigabitEthernet0/2
 delay 50
! Match the metric of the primary path

! Option C: Use CEF per-packet vs per-destination tuning
! (Not usually recommended — causes reordering)

! Step 3: Verify with application traffic
! Test TCP session establishment and long-lived connections
! Confirm firewall logs no longer show asymmetric flows

! Step 4: Document the design decision
! Note: variance across links with different latency
! is inherently risky for stateful applications.