ECMP and Next-Hop Groups

Represent two eligible next hops, inspect their dependencies, and avoid turning route multiplicity into a distribution claim.

Lesson 13 of 18Prerequisite: core lessons 01–09 or equivalent operator knowledge

By the end, you should be able to:

Configure two explicit next hops for one remote prefix.
Separate route candidates from usable next-hop members.
Remove one path without deleting the entire intended group.

Scope: community SONiC 202505 source baseline; single ASIC/default namespace unless stated. Commands, outputs, faults, and recovery are illustrative only. Confirm image, management mode, and platform support before a separate lab. No device commands, builds, containers, or packet tests were executed for this course.

Two next hops for one prefix

Original branching topology. The two downstream paths are pre-provisioned, loop-free, and have return routes; they are not an accidental shared Ethernet segment.

Scenario and baseline

Use a prepared routed lab: A is 192.0.2.10/24 with gateway S1 Ethernet0 192.0.2.1/24. S1 Ethernet4 is 198.51.100.1/30 toward R1 .2, and Ethernet8 is 198.51.100.5/30 toward R2 .6. Those ports are routed, not VLAN/LAG members. Both downstream routers already reach 203.0.113.0/24 and return 192.0.2.0/24 through S1. No S1 static path for that remote prefix exists initially.

Equivalent route preference, supported multipath configuration, resolved adjacencies, and target limits determine whether both next hops become eligible. Two configured strings are not sufficient proof.

Add the two explicit paths

sudo config route add prefix 203.0.113.0/24 nexthop 198.51.100.2 dev Ethernet4
sudo config route add prefix 203.0.113.0/24 nexthop 198.51.100.6 dev Ethernet8
show ip route 203.0.113.10
show arp
sonic-db-cli CONFIG_DB HGETALL "STATIC_ROUTE|203.0.113.0/24"

The pinned CLI can append another next hop to an existing prefix. Inspect before adding; repeated add is not a safe replacement or retry strategy. Verify the actual image’s static-routing and ECMP support.

S>* 203.0.113.0/24 [1/0] via 198.51.100.2, Ethernet4
                         via 198.51.100.6, Ethernet8

Illustrative shortened output, not a device observation.

Inspect membership and traffic separately

Correlate both adjacencies, selected routing state, next-hop-group dependencies, orchestration/SAI responses, and platform-specific evidence. RouteOrch maps next-hop group members to resolved objects; it can defer work when dependencies are absent. ASIC_DB state is not an independent physical table readback.

Traffic evidence needs a defined flow set and counters/captures on the relevant links. An ordinary ping is one narrow flow family. Hash fields, seeds, resilience, and ASIC capabilities differ; no exact split or failover time is asserted here.

show interfaces counters
show logging --lines 50

Remove one exact member and restore

sudo config route del prefix 203.0.113.0/24 nexthop 198.51.100.6 dev Ethernet8
show ip route 203.0.113.10
# Restore the removed path once
sudo config route add prefix 203.0.113.0/24 nexthop 198.51.100.6 dev Ethernet8

After convergence, the remaining eligible R1 path should still cover the destination under this topology. Check return reachability and fresh traffic; do not promise hitless remapping. Prefix-only deletion would remove more than this one intended member.

# Cleanup only the two lab additions
sudo config route del prefix 203.0.113.0/24 nexthop 198.51.100.2 dev Ethernet4
sudo config route del prefix 203.0.113.0/24 nexthop 198.51.100.6 dev Ethernet8

The prepared interface and downstream baseline remains intact. Confirm no lab path is left and do not save.

Key takeaways

Configured next hops must become eligible and resolved.
Exact member deletion differs from whole-prefix deletion.
Group programming and traffic distribution require separate evidence.
Hardware hashing and failure timing are platform-dependent.

Check your understanding

Six questions, four options each. Check each answer for an explanation, review your score, and retry.

Sources & scope

Reviewed 18 October 2026. Community release-source pins: utilities 7511bf2f8ea3582c2b67cf5016f8e8237e62882b; buildimage ff3c0c9f686a1d0dbddbe813b233b3b7a51bd8e2. FRR 10.2 and RFC references explain semantics; they do not identify an installed image’s exact daemon version. Windows reference code is separately pinned: SWSS b8a9b65494c234ac33b6cf0a2b7f13fb291cee7f, buildimage 128f6802b6e1, utilities cc4fbb3e8313, SAI Redis dd925f4cf6fa. These are source-inspection baselines, not deployed-binary or hardware validation.

Exact inspected files and actual website checks are recorded in SOURCE-REVIEW.txt. No vendor CLI extension, production support level, scale, or timing guarantee is implied.