NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Lab Objectives

Understand how EIGRP builds its composite metric from bandwidth, delay, reliability, and load (with emphasis on bandwidth and delay used by default).
Configure interface bandwidth values and EIGRP (AS 111) on the base topology and observe how metric differences affect path selection (successor vs feasible successor).
Verify EIGRP topology and routing decisions with appropriate show commands and interpret the outputs.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Configure Interface Bandwidth on R1

Set the interface bandwidth values on R1 to influence EIGRP metric computation. Use these target bandwidths (in kbps):

Gi0/0 (towards R2): 10000
Gi0/1 (towards R3): 2000
Gi0/2 (towards R4): 1000

Do NOT change delays.

Task 2: Enable EIGRP (AS 111) on R1–R4

Enable EIGRP autonomous system 111 on R1, R2, R3 and R4 so they advertise the 10.10.x.x inter-router networks and the 10.10.40.0/24 LAN behind R2. Use network statements that include the 10.0.0.0/8 and 192.168.0.0/16 address ranges as needed.

Task 3: Examine EIGRP Metrics and Path Selection from R1

From R1:

Show EIGRP neighbors and the topology table for the route to 10.10.40.0/24.
Identify the successor and any feasible successor, and explain why R1 selected that successor based on metric values.

Think About It: If Gi0/2 on R1 (towards R4) had a higher bandwidth than Gi0/0 (towards R2), how would that affect which path R1 prefers to reach 10.10.40.0/24? Why?

Lab Solution

(First — reproduce the exact base topology used in this lesson.)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP addresses shown are exact on each interface.

Task 1 Solution: Configure Interface Bandwidth on R1

What we are doing: We are setting the interface bandwidth values on R1 so EIGRP uses those bandwidth values when calculating the composite metric. EIGRP’s metric (by default) is based on bandwidth and delay — the lowest bandwidth along a path and the sum of delays on the path are the critical inputs. Adjusting the interface bandwidth is the safe way to influence EIGRP's path selection without touching delay.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# bandwidth 10000
R1(config-if)# exit
R1(config)# interface GigabitEthernet0/1
R1(config-if)# bandwidth 2000
R1(config-if)# exit
R1(config)# interface GigabitEthernet0/2
R1(config-if)# bandwidth 1000
R1(config-if)# exit

What these commands do: bandwidth <kbps> sets the bandwidth metric value the router advertises and uses in metric computation. It does not change the physical link speed — it changes the administrative bandwidth value used by routing protocols.
Why this matters: EIGRP chooses routes using the minimum (bottleneck) bandwidth on the path. Lowering bandwidth on an interface increases the computed metric for any path that includes that interface, making EIGRP less likely to select that path as a successor.

Verify:

R1# show interfaces GigabitEthernet0/0 | include bandwidth
  bandwidth 10000 Kbit
R1# show interfaces GigabitEthernet0/1 | include bandwidth
  bandwidth 2000 Kbit
R1# show interfaces GigabitEthernet0/2 | include bandwidth
  bandwidth 1000 Kbit

Expected output shows the bandwidth lines reporting the values you configured.

Tip: Setting bandwidth is a local administrative value. In production, you change it to reflect the policy (EIGRP metric tuning) — don't change physical interface speed settings unless you understand side effects.

Task 2 Solution: Enable EIGRP (AS 111) on R1–R4

What we are doing: We will enable EIGRP AS 111 on each router so they exchange routes for the 10.10.x.x interconnects and the LAN behind R2 (10.10.40.0/24). Using a network statement that matches 10.0.0.0 will include all 10.10.x.x interfaces.

! On R1
R1(config)# router eigrp 111
R1(config-router)# network 10.0.0.0
R1(config-router)# network 203.0.113.0
R1(config-router)# no auto-summary
R1(config-router)# exit

! On R2
R2(config)# router eigrp 111
R2(config-router)# network 10.0.0.0
R2(config-router)# network 192.168.0.0
R2(config-router)# no auto-summary
R2(config-router)# exit

! On R3
R3(config)# router eigrp 111
R3(config-router)# network 10.0.0.0
R3(config-router)# no auto-summary
R3(config-router)# exit

! On R4
R4(config)# router eigrp 111
R4(config-router)# network 10.0.0.0
R4(config-router)# no auto-summary
R4(config-router)# exit

What these commands do:
- router eigrp 111 places the router into EIGRP AS 111.
- network 10.0.0.0 tells EIGRP to enable on any interface in the 10.0.0.0/8 space (this includes the 10.10.x.x links).
- network 192.168.0.0 on R2 advertises the LANs (VLAN subnets) behind R2.
- no auto-summary disables classful automatic summarization (recommended in modern networks to avoid unexpected summarization).
Why this matters: EIGRP must be enabled on the correct interfaces to learn and advertise reachable networks. no auto-summary prevents networks from being summarized at classful boundaries, which can hide subnets from remote routers.

Verify:

R1# show ip eigrp neighbors
IP-EIGRP neighbors for AS(111)
H   Address        Interface       Hold  Uptime   SRTT   RTO  Q  Seq
0   10.10.10.2     Gi0/0           12    00:02:10 20     1000  0  5
1   10.10.20.2     Gi0/1           12    00:02:08 22     1000  0  4
2   10.10.30.2     Gi0/2           13    00:02:07 30     1000  0  3

R1# show ip route eigrp
Codes: C - connected, D - EIGRP
D   10.10.40.0/24 [90/281600] via 10.10.10.2, 00:02:05, GigabitEthernet0/0

Expected: show ip eigrp neighbors lists R2, R3, R4 reachable. show ip route eigrp shows routes learned via EIGRP with metric values.

Real‑world note: In datacenters and campus networks, consistent bandwidth values and no auto-summary are standard to avoid unexpected metric shifts and to make path selection predictable.

Task 3 Solution: Examine EIGRP Metrics and Path Selection from R1

What we are doing: We inspect the EIGRP topology to see the successor (best path) and any feasible successor (backup path that satisfies the feasibility condition). Then we interpret metric numbers to explain why R1 selected the successor.

R1# show ip eigrp topology 10.10.40.0
IP-EIGRP Topology Table for AS(111) Version 3
Codes: P - Passive, A - Active
P 10.10.40.0/24, 1 successors, FD is 281600
  via 10.10.10.2 (281600/281600), GigabitEthernet0/0
P 10.10.40.0/24, 1 feasible successors, reported distance 140800
  via 10.10.20.2 (563200/140800), GigabitEthernet0/1

What the output shows:
- FD is 281600 — the Feasible Distance (best composite metric from R1 to that destination).
- The first via 10.10.10.2 (281600/281600) line shows the successor: next-hop 10.10.10.2 with metric (Total metric / Reported distance). Here both numbers are equal because the neighbor reports a distance equal to the computed total in this simple example.
- The second entry shows a feasible successor candidate where the neighbor reports a reported distance (the neighbor’s advertised distance to the destination) of 140800, and the local composite metric via that neighbor would be 563200. The feasibility condition is: the neighbor’s reported distance must be strictly less than our current FD (281600) to be a feasible successor. Since 140800 < 281600, it qualifies.
Why R1 selected the shown successor:
- EIGRP chooses the path with the lowest composite metric as the successor. In this example, the path via 10.10.10.2 (Gi0/0) yields FD 281600 which is lower than the alternative path’s computed metric (563200), so it is selected.
- The feasible successor is a path whose neighbor-reported distance is less than our FD — this guarantees loop-free alternate path eligibility and allows fast failover without recomputation.

Verify:

R1# show ip route 10.10.40.0
Routing entry for 10.10.40.0/24
  Known via "eigrp 111", distance 90, metric 281600, type external
  Redistributing via eigrp 111
  Miss-age 00:02:05, using 1 algorithms
  Routing Descriptor Blocks:
  * 10.10.10.2, from 10.10.10.2, 00:02:05 ago, via GigabitEthernet0/0
      Route metric is 281600, traffic share count is 1

Expected: The route is installed with metric 281600 and points to the configured successor next-hop.

Analogy: Think of EIGRP metric as a "travel time" that's influenced by the narrowest lane on the path (bandwidth) and total stops (delay). The successor is the fastest route; a feasible successor is a verified second-best route that can be used immediately if the first route fails.

Troubleshooting Scenario

Scenario: R1 prefers R4 path but you expect R2

Symptom: Ping from R1 to a host on R2’s 10.10.40.0/24 goes via Gi0/2 (toward R4) instead of the Gi0/0 path toward R2.

Your task: Find and fix the issue.

Hint: Check interface bandwidth settings on R1 and compare EIGRP topology metrics.

Solution:

Likely cause: Gi0/0 on R1 has a lower bandwidth value configured (or Gi0/2 has a higher value), which inflated the metric via Gi0/0 so R1 prefers the Gi0/2 path.
Fix: On R1, correct the bandwidth value to the intended administrative kbps (e.g., 10000 for Gi0/0):

R1(config)# interface GigabitEthernet0/0
R1(config-if)# bandwidth 10000

Then verify and, if necessary, clear EIGRP processes or wait for reconvergence:

R1# clear ip eigrp neighbors
R1# show ip eigrp topology 10.10.40.0

Explanation: Restoring the correct bandwidth returns the composite metric to the expected value, and EIGRP will reselect the proper successor.

Warning: Do not rely on bandwidth changes for QoS — it is only for routing protocol metrics. In production, coordinate metric tuning across design and operations teams.

Verification Checklist

Interface bandwidth on R1 Gi0/0 is 10000, Gi0/1 is 2000, Gi0/2 is 1000.
EIGRP AS 111 is enabled on R1–R4 and neighbors are established (show ip eigrp neighbors).
R1’s topology table shows the successor and any feasible successor for 10.10.40.0/24 (show ip eigrp topology 10.10.40.0).
The installed route on R1 points to the successor next-hop with the expected metric (show ip route 10.10.40.0).

Common Mistakes

Symptom	Cause	Fix
Neighbor never forms on one link	`network` statement does not include that interface's IP	Add correct `network` statement (e.g., `network 10.0.0.0`) under `router eigrp 111`
EIGRP uses unexpected path	Incorrect `bandwidth` values or changed `delay` on interfaces	Correct `bandwidth` on interfaces; verify with `show interfaces`
Route shows as AD or not present	EIGRP process not enabled or `no auto-summary` causing summarization	Ensure `router eigrp 111` exists and `no auto-summary` is configured; verify with `show ip protocols`
Feasible successor not listed even though metric seems lower	Feasibility condition not met (neighbor's reported distance >= FD)	Inspect `show ip eigrp topology` to see neighbor-reported distance and compare to FD

Challenge Task

Add a loopback interface on R2 representing a web server network 192.168.10.0/24 and advertise it in EIGRP. Then, tune the bandwidth on R1 interfaces so that R1 has an equal-cost path to the loopback via R3 and R4 (so you see equal-cost load balancing). Verify by showing the routing table and observing multiple equal-cost EIGRP paths installed.

Think: To get equal-cost EIGRP paths you must make the composite metrics identical — adjust bandwidth values to make the bottleneck values produce the same FD across both paths.

Key Takeaways

EIGRP’s composite metric uses bandwidth and delay by default; reliability and load exist but are rarely changed.
bandwidth on an interface is an administrative value that strongly affects EIGRP path selection — change it cautiously.
A successor is the best path (lowest metric). A feasible successor is a loop-free backup whose neighbor-reported distance is less than the local FD.
Use show ip eigrp neighbors, show ip eigrp topology, and show ip route to verify path selection and metric reasoning.

Important: In production networks, precise metric tuning can influence traffic engineering and failover behavior. Always document changes and test in a maintenance window.