Skip to content
Log in Sign up My account

Sim 02: EIGRP Feasible Successor and Unequal-Cost Load Balancing

Blueprint 1.9.b, 1.9.c, 1.9.e, 1.9.f

Difficulty Time target Devices Faults
Hard 25 minutes 4 x IOSv 3

Scenario

R1 reaches the application network 10.4.40.0/24 behind R4 over two paths: a fast path through R2 and a slower path through R3. The design uses classic-mode EIGRP AS 100 with interface delay values set deliberately so that the R3 path is a feasible successor, and variance 2 on R1 so that both paths carry traffic in proportion to their metrics.

This lab uses classic mode so that you can calculate the metrics by hand. The DUAL logic is identical in named mode; only the metric scale differs.

Download the lab

CML lab file · EVE-NG lab file

4 nodes. The lab boots already broken (the faults are in the start-up configs, so skip Break it). CML: Import a lab, then start it. EVE-NG: import the .unl from the lab list; if your image folder names differ, edit each node's image.

Topology

graph LR
  R1["R1"] -- "Gi0/0 .1  10.1.2.0/30  .2 Gi0/0" --- R2["R2"]
  R1 -- "Gi0/1 .1  10.1.3.0/30  .2 Gi0/0" --- R3["R3"]
  R2 -- "Gi0/1 .1  10.2.4.0/30  .2 Gi0/0" --- R4["R4<br/>Lo40 10.4.40.1/24"]
  R3 -- "Gi0/1 .1  10.3.4.0/30  .2 Gi0/1" --- R4
Device Interface Address Configured delay
R1 Gi0/0 10.1.2.1/30 delay 10 (100 microseconds)
R1 Gi0/1 10.1.3.1/30 delay 100 (1000 microseconds)
R2 Gi0/0 / Gi0/1 10.1.2.2/30 / 10.2.4.1/30 Gi0/1 delay 10
R3 Gi0/0 / Gi0/1 10.1.3.2/30 / 10.3.4.1/30 Gi0/1 delay 15
R4 Gi0/0 / Gi0/1 10.2.4.2/30 / 10.3.4.2/30 default
R4 Lo40 10.4.40.1/24 default loopback delay, 5000 microseconds

Every router also has Loopback0 = 10.255.255.N/32.

Design metrics (classic mode, K1 = K3 = 1)

Classic metric = 256 x (10,000,000 / minimum bandwidth in kbps + total delay in tens of microseconds). Every path has a minimum bandwidth of 1,000,000 kbps (GigabitEthernet), which contributes 10. A router adds the delay of the interface on which it receives the route.

Router and path Total delay (tens of us) Metric
R2 via R4 500 + 10 = 510 256 x 520 = 133120
R3 via R4 500 + 15 = 515 256 x 525 = 134400
R1 via R2 510 + 10 = 520 256 x 530 = 135680 (successor, FD)
R1 via R3 515 + 100 = 615 256 x 625 = 160000

Feasibility condition on R1: R3's reported distance 134400 is less than R1's feasible distance 135680, so the R3 path is a feasible successor. Variance: 160000 is less than 2 x 135680 = 271360, so with variance 2 both paths are installed.

Build it in CML

Four IOSv nodes, cabled as in the diagram. Paste the baseline and save it.

Baseline configuration

R1 baseline 
hostname R1
interface Loopback0
 ip address 10.255.255.1 255.255.255.255
interface GigabitEthernet0/0
 ip address 10.1.2.1 255.255.255.252
 delay 10
 no shutdown
interface GigabitEthernet0/1
 ip address 10.1.3.1 255.255.255.252
 delay 100
 no shutdown
!
router eigrp 100
 eigrp router-id 10.255.255.1
 network 10.0.0.0
 variance 2
R2 baseline 
hostname R2
interface Loopback0
 ip address 10.255.255.2 255.255.255.255
interface GigabitEthernet0/0
 ip address 10.1.2.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 ip address 10.2.4.1 255.255.255.252
 delay 10
 no shutdown
!
router eigrp 100
 eigrp router-id 10.255.255.2
 network 10.0.0.0
R3 baseline 
hostname R3
interface Loopback0
 ip address 10.255.255.3 255.255.255.255
interface GigabitEthernet0/0
 ip address 10.1.3.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 ip address 10.3.4.1 255.255.255.252
 delay 15
 no shutdown
!
router eigrp 100
 eigrp router-id 10.255.255.3
 network 10.0.0.0
R4 baseline 
hostname R4
interface Loopback0
 ip address 10.255.255.4 255.255.255.255
interface Loopback40
 ip address 10.4.40.1 255.255.255.0
interface GigabitEthernet0/0
 ip address 10.2.4.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 ip address 10.3.4.2 255.255.255.252
 no shutdown
!
router eigrp 100
 eigrp router-id 10.255.255.4
 network 10.0.0.0

Verify the baseline

R1# show ip eigrp topology 10.4.40.0/24 | include FD|Composite|via
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 135680
  10.1.2.2 (GigabitEthernet0/0), from 10.1.2.2, Send flag is 0x0
      Composite metric is (135680/133120), route is Internal
  10.1.3.2 (GigabitEthernet0/1), from 10.1.3.2, Send flag is 0x0
      Composite metric is (160000/134400), route is Internal

R1# show ip route 10.4.40.0
Routing entry for 10.4.40.0/24
  Known via "eigrp 100", distance 90, metric 135680, type internal
  ...
  Routing Descriptor Blocks:
  * 10.1.2.2, from 10.1.2.2, ..., via GigabitEthernet0/0
      Route metric is 135680, traffic share count is ...
    10.1.3.2, from 10.1.3.2, ..., via GigabitEthernet0/1
      Route metric is 160000, traffic share count is ...

Two descriptor blocks with different metrics prove unequal-cost load balancing. The traffic share counts are in inverse proportion to the metrics, so the R2 path gets the larger share.

Break it

Fault injection (for the lab partner or script only) 
! ---- R1 ----
router eigrp 100
 maximum-paths 1
!
! ---- R3 ----
interface GigabitEthernet0/1
 delay 25
router eigrp 100
 metric weights 0 1 1 1 0 0

Trouble ticket

Ticket 1002: slow failover and no load sharing

"The application team says traffic to 10.4.40.0/24 is no longer shared across both WAN paths, and during this morning's maintenance on R2 the application was unreachable for several seconds. Before the last change, the backup path through R3 was used instantly and also carried part of the load."

Requirements: R1 must have both paths to 10.4.40.0/24 in its routing table with unequal traffic share. The path through R3 must be a feasible successor. Keep the documented delay values.

Restrictions: Do not change any interface bandwidth. Do not use offset lists or static routes.

Symptoms

  • show ip route 10.4.40.0 on R1 shows only one path, via R2.
  • show ip eigrp topology 10.4.40.0/24 on R1 lists only the R2 path.
  • R3 has no EIGRP neighbors.

Root cause and fix

Root cause and fix: fault 1

K-value mismatch on R3. R3 was given metric weights 0 1 1 1 0 0, which turns on K2. EIGRP neighbors must have identical K values, so R3 loses both of its adjacencies and the R3 path disappears completely.

Diagnose:

R1# show logging | include DUAL
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.3.2 (GigabitEthernet0/1) is down: K-value mismatch

R3# show ip protocols | include K1|metric weight
  EIGRP metric weight K1=1, K2=1, K3=1, K4=0, K5=0
R1# show ip protocols | include K1|metric weight
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

Fix:

R3(config)# router eigrp 100
R3(config-router)# no metric weights

no metric weights restores the defaults (K1 = K3 = 1, others 0). R3 forms adjacencies with R1 and R4 again.

Root cause and fix: fault 2

The delay on R3 Gi0/1 was raised from 15 to 25. R3's own metric to 10.4.40.0/24 becomes 256 x (10 + 525) = 136960. That is R3's reported distance to R1, and 136960 is not less than R1's feasible distance of 135680, so the R3 path fails the feasibility condition. A path that is not a feasible successor is never used for unequal-cost load balancing, whatever the variance, and it cannot take over without a DUAL query, which is why failover took seconds.

Diagnose. A plain show ip eigrp topology hides non-feasible paths, so use all-links or the specific prefix:

R1# show ip eigrp topology all-links | section 10.4.40.0
P 10.4.40.0/24, 1 successors, FD is 135680, serno 21
        via 10.1.2.2 (135680/133120), GigabitEthernet0/0
        via 10.1.3.2 (162560/136960), GigabitEthernet0/1

R3# show interfaces GigabitEthernet0/1 | include DLY
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 250 usec,

The reported distance via R3 (136960) is higher than the FD (135680). The interface shows 250 microseconds instead of the documented 150.

Fix:

R3(config)# interface GigabitEthernet0/1
R3(config-if)# delay 15

The R3 path returns as (160000/134400) and now passes the feasibility condition.

Root cause and fix: fault 3

R1 is limited to one path. With faults 1 and 2 fixed, the topology table shows a feasible successor and variance 2 is still configured, but the routing table still has one entry. maximum-paths 1 caps the number of paths EIGRP may install, and that cap applies to unequal-cost paths too.

Diagnose:

R1# show ip protocols | include Maximum
  Maximum path: 1
  Maximum hopcount 100
  Maximum metric variance 2

Fix:

R1(config)# router eigrp 100
R1(config-router)# no maximum-paths 1

The default for EIGRP is four paths.

Final verification

R1# show ip route 10.4.40.0 | include via|share
  * 10.1.2.2, from 10.1.2.2, ..., via GigabitEthernet0/0
      Route metric is 135680, traffic share count is ...
    10.1.3.2, from 10.1.3.2, ..., via GigabitEthernet0/1
      Route metric is 160000, traffic share count is ...

Test the failover: on R2, shutdown Gi0/1 while running ping 10.4.40.1 repeat 1000 from R1. With a feasible successor in place, at most one or two pings are lost. Remember to no shutdown afterwards.

Exam trap

Variance only applies to paths that already meet the feasibility condition (reported distance less than the feasible distance). A candidate that sees a path "within variance" but forgets to check the reported distance will pick the wrong answer. Check the second number in (metric/RD) against the FD first, then apply variance.

Exam trap

show ip eigrp topology shows successors and feasible successors only. To see every path a router has learned, including ones that fail the feasibility condition, use show ip eigrp topology all-links or name the prefix.