IPv6 Neighbor Discovery

Inspect a directly connected IPv6 adjacency, distinguish DAD from reachability, and diagnose an absent peer address.

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

By the end, you should be able to:

Configure one isolated IPv6 routed interface.
Interpret neighbor and duplicate-address states in context.
Scope link-local addresses to the correct interface.

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.

A directly connected IPv6 adjacency

Original physical topology. The only cable connects S1 Ethernet8 to Host B eth1; interface scope identifies the link.

Scenario and baseline

S1 Ethernet8 is a clean routed port, admin-down, without LAG/VLAN membership or this lab address. Linux B is already up with 2001:db8:10::2/64 on eth1. No gateway is needed for the directly connected exchange. Independent management access remains untouched.

Neighbor Discovery uses ICMPv6, not ARP. Address assignment first involves duplicate-address detection (DAD); a tentative or duplicate address is not equivalent to a usable neighbor. Link-local fe80:: addresses require an interface/zone context.

Configure and inspect IPv6 state

sudo config interface ip add Ethernet8 2001:db8:10::1/64
sudo config interface startup Ethernet8
show ipv6 interfaces
show ipv6 route 2001:db8:10::2
show ndp
ip -6 address show dev Ethernet8
ip -6 neigh show dev Ethernet8

The community IP-add implementation accepts an IPv6 prefix. Verify image IPv6 support, DAD completion, and link state before interpreting neighbors. Do not suppress DAD or disable ICMPv6 to force success.

2001:db8:10::2 dev Ethernet8 lladdr 02:00:00:00:00:22 REACHABLE

Illustrative shortened output, not a device observation.

Exercise demand without overclaiming

# Host B only
ping -6 -c 3 2001:db8:10::1
# S1, after demand
show ndp
ip -6 neigh show dev Ethernet8

Neighbor Solicitation/Advertisement supplies local-link adjacency information. REACHABLE is a recent reachability state; STALE alone is not a failure. With captures, distinguish DAD probes from ordinary address resolution and neighbor-unreachability detection.

This ping targets S1 itself, so it tests the local IP stack and link, not routed transit across two switch ports. IPv6 transit needs its own second subnet, return path, and hardware evidence. No automatic default-router behavior is assumed.

Fault and exact restoration

# Host B only: remove the prepared address
sudo ip -6 address del 2001:db8:10::2/64 dev eth1
# S1: bounded demand toward the now absent address
ping -6 -c 3 -I Ethernet8 2001:db8:10::2
ip -6 neigh show dev Ethernet8
# Host B: restore the same prepared address
sudo ip -6 address add 2001:db8:10::2/64 dev eth1

Cached state may initially remain; after demand and re-resolution the neighbor can become INCOMPLETE/FAILED. A missing peer address differs from an unusable local tentative address. Wait for normal DAD after restoration and repeat the original exchange.

# S1 teardown
sudo config interface ip remove Ethernet8 2001:db8:10::1/64
sudo config interface shutdown Ethernet8
show ipv6 interfaces

B retains its original prepared address. Restore only this lab’s port/address additions; leave startup files unchanged.

Key takeaways

ND uses ICMPv6 on the local link.
DAD, address resolution, and reachability state are different checks.
Link-local addressing needs an interface scope.
A ping to the switch does not validate transit forwarding.

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.