First, the essential ideas
- IPv6 address and prefix
- An IPv6 address is a 128-bit identifier written in hexadecimal groups. A prefix identifies leading bits shared by an address block. Day 12 explains how to expand :: and read a /64.
- Interface and link
- An interface is a device's network connection. A link is the local network over which neighboring interfaces communicate without an intervening IP router. Our lab link is one cable between two routers.
- Unicast
- Unicast identifies one interface as the destination. Global, unique-local and link-local are unicast categories; link-local is not a fourth delivery type alongside unicast, multicast and anycast.
- Scope and zone
- Scope limits where an address has meaning. A zone is a particular region of that scope, such as your selected local link. An interface selection tells a tool which local link you mean.
- Global and unique-local
- Global unicast supports addressing beyond one link, subject to allocation and routing. Unique-local addresses support private routing within and between cooperating networks, not normal global Internet routing. Neither label is a security policy.
- Multicast group
- Multicast identifies a group of receiving interfaces. A group address is different from the individual unicast address of each member. Group membership and permitted scope determine the intended audience.
- Anycast and routing choice
- Anycast uses a shared address at multiple service locations. Routing chooses a destination for a packet. A routing metric is a protocol's measure of path preference, not necessarily geographical distance or server load.
- Neighbor discovery
- IPv6 neighbor discovery exchanges local control messages to learn about nearby interfaces and other link information. It uses multicast for some tasks. Its detailed message exchanges and automatic assignment belong to Day 14.
- ICMPv6 and ping
- ICMPv6 carries IPv6 control messages. Ping sends echo requests and waits for echo replies. Receiving replies tests that exchange with that address, not every address, service or security setting on the device.
- Console and command modes
- Console is a virtual device's text window in GNS3. Right-click the named router and choose Console before typing. Cisco prompts ending >, #, (config)# and (config-if)# mark user, privileged, global and interface modes.
- Baseline and rollback
- A baseline records the original configuration and actual observations. Rollback restores the intended settings after a controlled change. Repeat the original tests rather than assuming that an accepted command fixed the problem.
- Loopback and unspecified
- The special value ::1 is loopback: the local device talking to itself. The special value :: is unspecified: no address has been selected in a permitted protocol situation. Neither is an ordinary remote peer target to assign in this lab.
Start by asking two questions: who is the intended recipient, and where is this address meaningful? Those questions are related but different. A router can show a link-local address, another unicast address and several joined multicast groups on the same interface without having a fault.
See the idea
Five topology comparisons
One interface, a member group, or one routing-selected recipient. Scope is a separate question.
One interface
Unicast names one interface. Global, unique-local and link-local are unicast categories; a link-local test must identify the intended local link.
What this model leaves out: This compares intended recipients, not measured delivery or physical wiring. It omits routing and membership protocols; the separate lab scene shows the two actual endpoints.
Full visual explanation and references
IPv6: who should receive it?
Three concept panels compare unicast to one interface, multicast to group members, and anycast to one routing-selected recipient. These are address roles, not a wired topology.
This compares intended recipients, not measured delivery or physical wiring. It omits routing and membership protocols; the separate lab scene shows the two actual endpoints.
- One interface
Unicast names one interface. Global, unique-local and link-local are unicast categories; a link-local test must identify the intended local link.
www.rfc-editor.orgwww.rfc-editor.org - A group of members
Multicast identifies a group within a defined scope. A joined-group entry is membership evidence, not proof that every receiver got an application packet.
www.rfc-editor.orgwww.cisco.com - One routed recipient
Anycast shares an address across service instances. Routing selects a destination; a special prefix, physical distance or automatic load check does not identify that choice.
www.rfc-editor.org
One peer. Two different address tests.
Router1 connects directly to Router2 on one isolated link. Requests end at Router2 and replies return to Router1; the tests use two different addresses on that same peer.
Only Router1, Router2 and one cable are simulated. Internet access, anycast services and multicast applications are omitted; the arrows describe expected peer tests, not captured traffic.
- Verify both targets
Router1 tests Router2 at 2001:db8:13:1::2 and fe80::13:2. Both requests end at Router2; select Router1's cable interface for the link-local target.
www.cisco.comwww.cisco.com - Remove one assignment
Remove only Router2's documentation address. The original target should stop replying; a request to retained fe80::13:2 still ends at Router2 on this link.
www.cisco.comwww.cisco.com - Restore and retest
Restore 2001:db8:13:1::2/64 on Router2. Repeat both peer tests and the reverse checks; a completed reply returns to the router that sent the request.
www.cisco.comwww.cisco.com
One idea at a time
Start with something familiar.
You do not need a running network to begin. Read the definitions, classify the paper examples, then use the lab if you have an authorized router image. Commands go in the named GNS3 router's Console, not in your computer's terminal. An address category is a clue to the test you need, not proof that the device is reachable.
Why learn this?
An operator may see one successful ping and assume that every service is healthy. This lesson shows why that conclusion is too broad. A device can retain local communication while losing the particular address an application expects. The exact source, destination and interface must accompany the result.
An everyday comparison
As a memory aid, compare a named person, a subscribed group and one available branch of a service. These are organizational metaphors, not literal forwarding rules; real devices do not understand people, subscriptions or business opening hours.
What happens in a network
Use the three ideas to remember one interface, a group of interfaces and one routing-selected instance. Then add a separate scope question. The memory aid does not tell you the actual address prefix, which interface to use or how a router chooses a path.
Where the comparison stopsAnycast does not automatically choose the least busy server or physically closest office. Multicast is not a promise of reliable delivery to every member. Reachability and application health still need appropriate evidence.
Follow one worked example
- Classify the address before planning a test.
A target beginning fe80 is a link-local unicast example. ff02::1 is a link-scoped multicast group. An ordinary-looking unicast address might be used by anycast, but its text alone cannot prove that deployment.
Why: Avoid treating every address on a screen as an interchangeable device destination.
- Choose the actual local link for link-local traffic.
Router1's Console may ask for an output interface when you ping Router2's link-local address. Enter Router1's recorded cable port, not Router2's port or an interface on your physical laptop.
Why: Link-local addresses are meaningful on a selected link; the tool needs that scope context.
- Compare two targets on the same peer.
The lab first verifies Router2 at 2001:db8:13:1::2 and fe80::13:2. Removing only the first assignment should stop replies to that target while the separately configured link-local address remains available on the same link.
Why: One remaining working address does not prove that a removed address or dependent application still works.
- Restore the assignment and repeat identical tests.
Restore Router2's original /64 address, inspect it, and repeat both target tests. Record actual results; do not copy expected success symbols into your evidence table.
Why: A before-change-after comparison supports a precise conclusion without blaming an entire protocol.
Your first small task
On paper, place fe80::13:2, fd7a:115c:a1e0:13::2, ff02::1, ::1 and :: into categories. Write whether each example is a normal remote peer target, needs link context, refers to the local device or indicates no assigned source address.
Show a hint
Read the beginning and special complete values, then check the intended use. Do not configure the paper-only unique-local example on a real network.
Check the expected result
The first is link-local; the second is unique-local unicast; the third is a multicast group; ::1 is loopback; :: is unspecified and must not be assigned as a host destination.
Pause and explain it in your own words
Router1 can ping Router2's link-local address after Router2 loses its documentation address. Is all IPv6 service therefore healthy?
Show a hint
Name the exact address that replied, the selected link and the address that was removed.
Show the explanation
No. The result supports only the local exchange with the retained link-local address. Retest the removed address after restoring it, and use separate tests for any application. Our lab has no Internet connection or application server.
Short answer
What should you understand today?
Unicast targets one interface, multicast targets a group, and anycast lets routing select a destination using a shared address. Link-local is unicast limited to one link, not a separate delivery type. Identify the address category and scope, then verify the exact interface and destination; a successful local test does not establish Internet or application connectivity.
Before you begin
Learning targets
- Complete Day 12's IPv6 notation exercise; be able to expand an address and identify its /64 prefix.
- Use a fresh disconnected GNS3 project with two authorized Cisco IOS or IOS XE routers and one routed Ethernet port each.
- Have legal permission to run the selected images in GNS3, or use an authorized Cisco Modeling Labs environment or the labeled paper alternative.
- Prepare a text notes file using Notepad on Windows, TextEdit on macOS or a plain-text editor on Linux.
- Separate unicast, multicast and anycast delivery behavior from the scope of an address.
- Recognize global, unique-local and link-local unicast and the loopback and unspecified special cases.
- Explain why anycast needs routing and service context rather than a distinctive hexadecimal prefix.
- Configure unique link-local and documentation addresses, then inspect the interface's multicast memberships.
- Remove one peer address safely, compare two exact tests, restore the address and retest both directions.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
IPv6 address and prefix
An IPv6 address is a 128-bit identifier written in hexadecimal groups. A prefix identifies leading bits shared by an address block. Day 12 explains how to expand :: and read a /64.
Interface and link
An interface is a device's network connection. A link is the local network over which neighboring interfaces communicate without an intervening IP router. Our lab link is one cable between two routers.
Unicast
Unicast identifies one interface as the destination. Global, unique-local and link-local are unicast categories; link-local is not a fourth delivery type alongside unicast, multicast and anycast.
Scope and zone
Scope limits where an address has meaning. A zone is a particular region of that scope, such as your selected local link. An interface selection tells a tool which local link you mean.
Global and unique-local
Global unicast supports addressing beyond one link, subject to allocation and routing. Unique-local addresses support private routing within and between cooperating networks, not normal global Internet routing. Neither label is a security policy.
Multicast group
Multicast identifies a group of receiving interfaces. A group address is different from the individual unicast address of each member. Group membership and permitted scope determine the intended audience.
Anycast and routing choice
Anycast uses a shared address at multiple service locations. Routing chooses a destination for a packet. A routing metric is a protocol's measure of path preference, not necessarily geographical distance or server load.
Neighbor discovery
IPv6 neighbor discovery exchanges local control messages to learn about nearby interfaces and other link information. It uses multicast for some tasks. Its detailed message exchanges and automatic assignment belong to Day 14.
ICMPv6 and ping
ICMPv6 carries IPv6 control messages. Ping sends echo requests and waits for echo replies. Receiving replies tests that exchange with that address, not every address, service or security setting on the device.
Console and command modes
Console is a virtual device's text window in GNS3. Right-click the named router and choose Console before typing. Cisco prompts ending >, #, (config)# and (config-if)# mark user, privileged, global and interface modes.
Baseline and rollback
A baseline records the original configuration and actual observations. Rollback restores the intended settings after a controlled change. Repeat the original tests rather than assuming that an accepted command fixed the problem.
Loopback and unspecified
The special value ::1 is loopback: the local device talking to itself. The special value :: is unspecified: no address has been selected in a permitted protocol situation. Neither is an ordinary remote peer target to assign in this lab.
Loopback
The special address ::1 refers to the local node. A reply tests a local function and does not demonstrate that another device or cable is reachable.
Unspecified address
The special value :: indicates the absence of an address in defined protocol situations. It is not an address to assign to a host or use as an ordinary destination.
Documentation address
An address from example space such as 2001:db8::/32. It supports documentation and disconnected exercises, not a public production allocation.
Separate recipient type from address scope
Unicast, multicast and anycast answer a recipient question: one interface, a group, or one routing-selected recipient of a shared address. Scope answers where an address is meaningful. Link-local belongs under unicast, so the chapter title does not describe four mutually exclusive delivery modes. IPv6 does not use broadcast addresses. An interface can have multiple addresses and group memberships; count and classify them before deciding that extra entries are errors.
- Address appearance can identify several categories, but it cannot reveal every deployment property.
- Several valid addresses on one interface do not automatically mean duplicate addressing.
Global and unique-local are not security settings
Global unicast is used for communication beyond one link, but a plausible-looking address does not prove a legitimate allocation, route or Internet access. Our 2001:db8::/32 examples are reserved for documentation and must stay in the disconnected exercise. Unique-local addresses occupy fc00::/7; the locally assigned form uses fd00::/8. A production ULA plan uses a pseudo-random 40-bit Global ID to reduce collision risk, not a familiar number copied from a tutorial. ULAs can be routed across cooperating private networks; they are not confined to one cable.
- Do not equate unique-local with link-local, a firewall rule or automatic privacy.
- A successful documentation-address ping in this isolated lab does not test public IPv6 routing.
Link-local needs the correct link context
Link-local unicast is identified by fe80::/10. The standard format sets the following 54 bits to zero before the 64-bit interface identifier, which explains the familiar fe80:: addresses in this lab. Routers do not carry link-local-addressed packets across to another link. The same numerical link-local address can exist on separate links, but it must not be duplicated on one link. An output interface or local zone identifier resolves which link a diagnostic tool means.
- A link-local address need not be derived from a hardware address; this lab assigns it manually.
- Selecting the correct interface is part of the test, not an optional cosmetic detail.
Multicast identifies a group, not a device port
IPv6 multicast uses ff00::/8, with additional fields describing properties including scope. ff02::1 identifies all IPv6 nodes on the local link, while ff02::2 identifies local IPv6 routers. Interfaces also join solicited-node multicast groups associated with their addresses. Their detailed derivation and neighbor-discovery exchanges are reserved for Day 14. Seeing a joined group in a display proves local membership state; it does not prove an application stream arrived or every member replied to a ping.
- Scope matters for multicast too; do not assume every multicast address is limited to one link.
- This lab observes memberships and makes no claim to simulate a multicast application or multicast routing.
Anycast depends on routing and service readiness
An anycast service makes one address available at multiple locations. Routing chooses a destination based on the routes and policies available from a particular source. Nearest is a routing concept, not a promise of the geographically closest or least-loaded server. The address comes from unicast space, so no universal leading hex pattern identifies anycast. Operating the service requires appropriate routing and application readiness; entering the same ordinary address on two adjacent lab devices is not a sound anycast deployment.
- Anycast delivery selects a recipient; it does not replicate the same request to every service instance.
- Route reachability and service health are separate facts that an operational deployment must coordinate.
Special values prevent misleading tests
The loopback address ::1 refers to the local node. A reply from it does not test a cable, neighboring router or remote service. The unspecified address :: represents the absence of an address in permitted protocol contexts and is not an ordinary address to assign to an interface. Do not confuse a shortened address containing :: with the complete special value ::. A technical note should include the source device, full target, selected output interface, time and observed result.
- Test the peer's address, not the sender's own address or the loopback special value.
- Missed replies can also reflect filtering, rate limits or interface problems; do not diagnose by a single ping alone.
Turn address classification into an operator checklist
Use a five-part record: planned address, category, meaningful scope, local interface and actual observation. Start with a known-good isolated baseline, change one assignment, compare the same targets, then restore and retest. Do not expand a limited local success into a claim about routing or applications. The lab uses documented IOS-style commands, but exact port names and software support depend on the authorized image. QCS has source-reviewed these steps; it has not executed this lesson on a Cisco image.
- GNS3 does not supply Cisco images; use them only where the applicable entitlement permits.
- A paper result, a command accepted by a device and an observed reply are different kinds of evidence.
Real-world walkthrough
The local check passes, but the intended target is missing
A trainee validates a maintenance change using a link-local ping and writes that IPv6 is fully restored. The intended monitoring address was removed, however, and the trainee never retested that target. This fictional incident shows an evidence problem rather than proving a particular production outage. The correct response is to compare the assigned addresses and test the actual requirement, not to disable IPv6 or assume that every failure has the same cause.
- Write the original requirement as a complete test: source Router1, destination 2001:db8:13:1::2, and the isolated cable interface.
- Read Router2's actual assignments and distinguish the missing documentation address from the retained fe80::13:2 link-local address.
- Compare both target results using the correct output interface for link-local. Keep the local success and missing-target failure as separate observations.
- Restore only the authorized missing address in the disconnected lab and repeat the original target test, then verify the reverse direction.
- In a real network, obtain approval and check other causes such as firewalls, source selection, link state or rate limiting. This controlled example is not a universal diagnosis.
Guided GNS3 lab
One peer, two unicast addresses, different test outcomes
Configure a direct isolated Router1-to-Router2 link, inspect address categories and multicast memberships, and prove through your own observations that removing one address need not remove a separately configured link-local address.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| Router1 | Mapped cable port; example GigabitEthernet0/0 | 2001:db8:13:1::1/64 | Documentation-only peer address; never use as a public allocation |
| Router1 | Same mapped cable port | fe80::13:1 link-local | Unique local-link endpoint address; configure with link-local keyword |
| Router2 | Mapped cable port; example GigabitEthernet0/0 | 2001:db8:13:1::2/64 | Peer target removed and restored in the controlled exercise |
| Router2 | Same mapped cable port | fe80::13:2 link-local | Retained local-link target, distinct from Router1 |
Set up the lab
- Create a new GNS3 project named Day13-address-scope. Add two routers from an already installed, legally authorized IOS or IOS XE template. If you have no such template, stop and use the paper exercise or authorized CML; never download an unlicensed image.
- Rename the nodes Router1 and Router2. Select Add a link, click Router1 and choose an unused routed Ethernet port, then click Router2 and choose its port. Exit link mode. Do not add Cloud, NAT or an adapter connected to your computer's real network.
- Use GNS3 port labels and show ip interface brief to record each cable endpoint. Example mapping: Router1 cable -> GigabitEthernet0/0/0; Router2 cable -> Ethernet0/0. In that case replace every Router1 GigabitEthernet0/0 with GigabitEthernet0/0/0 and every Router2 example with Ethernet0/0. Never guess a port.
- Start both routers, then right-click the named node and choose Console. Press Enter for a prompt; decline the initial setup dialog on these new lab devices. Commands are typed without the prompt. If an unknown password is requested, stop and use the authorized template setup instructions.
- Record show version and baseline configuration for each router in Day13-baseline.txt. Use Notepad on Windows, TextEdit in plain-text mode on macOS, or a plain-text editor on Linux. Save a clean project snapshot before any lab changes; keep the whole project disconnected.
- The example commands use standard IOS-style interface, ipv6 address and ping forms. Cisco's cited link-local worked example used IOS 12.4(15)T1; this is not a recommendation to deploy that old release. Record your actual permitted model and version. If its commands or prompt differ, consult that release's documentation instead of guessing.
Record Router1's clean baseline
In the isolated project, right-click Router1 and choose Console before typing. Record the software and current configuration. Compare the cable label with the interface list before using any example port below. Press Space at a pagination prompt to continue; save the actual output in your notes.
enable
show version
show ip interface brief
show running-configWhat each command means
enable- Enter privileged EXEC mode from >; if already at #, skip enable. Do not type the prompt itself.
show version- Display the actual software release and device information; record them rather than assuming an image version.
show ip interface brief- List real interface names and their administrative and protocol states; map the cable port.
show running-config- Display the running configuration for the baseline record without changing it.
- What you should see
- Your notes identify Router1's exact cable port, software release and original settings. An administratively down port can be normal before configuration.
- Why this step matters
- A validated interface mapping and saved baseline prevent commands from being applied to an unintended port.
Record Router2's clean baseline
In the isolated project, right-click Router2 and choose Console before typing. Repeat the inspection independently. Router2's interface name need not match Router1's. Confirm the diagram has only the single inter-router cable and no real-network connection before proceeding.
enable
show version
show ip interface brief
show running-configWhat each command means
enable- Enter privileged EXEC mode from >; if already at #, skip enable. Do not type the prompt itself.
show version- Record Router2's actual software release and platform.
show ip interface brief- Find Router2's cable interface and record its exact name and current state.
show running-config- Save Router2's original running configuration in the baseline notes.
- What you should see
- Both endpoints now have separate, checked interface mappings and baseline records; neither router carries production traffic.
- Why this step matters
- Matching device roles does not guarantee matching interface names or configurations.
Assign Router1's two addresses
In the isolated project, right-click Router1 and choose Console before typing. Replace the example interface with Router1's mapped port. Configure only the two planned addresses and enable that isolated interface. No global transit-routing or automatic-address-assignment setup is required for this endpoint exercise.
enable
configure terminal
interface GigabitEthernet0/0
ipv6 address fe80::13:1 link-local
ipv6 address 2001:db8:13:1::1/64
no shutdown
end
show ipv6 interface GigabitEthernet0/0What each command means
enable- Enter privileged EXEC mode from >; if already at #, skip enable. Do not type the prompt itself.
configure terminal- Enter global configuration mode; subsequent configuration applies only to this fresh lab device.
interface GigabitEthernet0/0- Select the mapped cable interface; replace GigabitEthernet0/0 with the recorded exact name on this router.
ipv6 address fe80::13:1 link-local- Assign Router1's local-link address explicitly; do not add a /64 to this command form.
ipv6 address 2001:db8:13:1::1/64- Assign Router1 the planned documentation address with a 64-bit subnet prefix.
no shutdown- Enable this mapped lab port administratively; this does not repair a missing cable or stopped peer.
end- Leave configuration mode and return to the # prompt for inspection or testing.
show ipv6 interface GigabitEthernet0/0- Display the selected interface's state, link-local address, other addresses and multicast memberships.
- What you should see
- The display should identify both planned addresses. Wait for address checks to complete; the link may not be fully operational until Router2 is started and enabled.
- Why this step matters
- Separate assignments allow the later exercise to remove one address while retaining the other.
Assign Router2's two addresses
In the isolated project, right-click Router2 and choose Console before typing. Use Router2's independently mapped port. Check the final digits carefully: Router2 uses ::2 and Router1 uses ::1. Stop on a duplicate-address error rather than disabling the duplicate check.
enable
configure terminal
interface GigabitEthernet0/0
ipv6 address fe80::13:2 link-local
ipv6 address 2001:db8:13:1::2/64
no shutdown
end
show ipv6 interface GigabitEthernet0/0What each command means
enable- Enter privileged EXEC mode from >; if already at #, skip enable. Do not type the prompt itself.
configure terminal- Enter global configuration mode; subsequent configuration applies only to this fresh lab device.
interface GigabitEthernet0/0- Select the mapped cable interface; replace GigabitEthernet0/0 with the recorded exact name on this router.
ipv6 address fe80::13:2 link-local- Assign Router2 its unique local-link address on the cable interface.
ipv6 address 2001:db8:13:1::2/64- Assign the documentation address that Router1 will test and that the fault will later remove.
no shutdown- Enable only Router2's mapped lab cable port.
end- Leave configuration mode and return to the # prompt for inspection or testing.
show ipv6 interface GigabitEthernet0/0- Display the selected interface's state, link-local address, other addresses and multicast memberships.
- What you should see
- Both interfaces should reach up/up with the planned addresses and no duplicate-address failure. Confirm the actual state rather than assuming accepted commands guarantee it.
- Why this step matters
- The baseline requires a working link and two distinct endpoint addresses before any controlled fault is introduced.
Verify both Router2 targets from Router1
In the isolated project, right-click Router1 and choose Console before typing. Run one ping at a time. If the link-local ping asks Output Interface, enter this router's mapped cable interface, for example GigabitEthernet0/0, and press Enter. That response is not a new command. Do not append /64 or a guessed %zone to the target. Verify these are Router2's targets, not Router1's own addresses; record the actual replies separately.
ping ipv6 2001:db8:13:1::2
ping ipv6 fe80::13:2What each command means
ping ipv6 2001:db8:13:1::2- Send echo requests to the other router at 2001:db8:13:1::2; this is a peer test, not a ping to this router's own address.
ping ipv6 fe80::13:2- Test the peer's link-local address fe80::13:2; supply the mapped output interface when prompted to select the correct link.
- What you should see
- Both peer tests should return replies once interface and neighbor initialization finish. If they do not, troubleshoot before starting the fault; a transient first loss is not a completed baseline.
- Why this step matters
- The two results refer to distinct addresses on one peer. Establishing both first makes later comparison meaningful.
Verify both Router1 targets from Router2
In the isolated project, right-click Router2 and choose Console before typing. Run one ping at a time. If the link-local ping asks Output Interface, enter this router's mapped cable interface, for example GigabitEthernet0/0, and press Enter. That response is not a new command. Do not append /64 or a guessed %zone to the target. Use Router2's cable port when prompted. Record this reverse-direction baseline separately from Router1's results.
ping ipv6 2001:db8:13:1::1
ping ipv6 fe80::13:1What each command means
ping ipv6 2001:db8:13:1::1- Send echo requests to the other router at 2001:db8:13:1::1; this is a peer test, not a ping to this router's own address.
ping ipv6 fe80::13:1- Test the peer's link-local address fe80::13:1; supply the mapped output interface when prompted to select the correct link.
- What you should see
- Router2 should receive replies from each Router1 target. Do not continue until the selected source, target and local port are recorded and understood.
- Why this step matters
- Testing the reverse direction catches mistaken targets and provides a recovery test that is independent of the first command.
Classify Router1's joined groups
In the isolated project, right-click Router1 and choose Console before typing. Inspect the detailed interface display again. Copy address entries into separate columns for link-local, documentation unicast and joined multicast groups. Do not change membership or ping a group merely to fill a result column.
show ipv6 interface GigabitEthernet0/0What each command means
show ipv6 interface GigabitEthernet0/0- Display the selected interface's state, link-local address, other addresses and multicast memberships.
- What you should see
- The display should include the planned unicast addresses and multicast memberships, including ff02::1 on the active IPv6 interface. Other groups depend on enabled features and addresses; record them rather than inventing a fixed list.
- Why this step matters
- An address list mixes different roles. A group-membership line is not another individual host address or proof of application traffic.
Remove only Router2's documentation address
In the isolated project, right-click Router2 and choose Console before typing. Confirm its cable port against the baseline and current topology. Remove the exact documentation assignment only; keep fe80::13:2 and the cable interface enabled. Never use the broad no ipv6 address command without an address here.
configure terminal
interface GigabitEthernet0/0
no ipv6 address 2001:db8:13:1::2/64
end
show ipv6 interface GigabitEthernet0/0What each command means
configure terminal- Enter global configuration mode; subsequent configuration applies only to this fresh lab device.
interface GigabitEthernet0/0- Select the mapped cable interface; replace GigabitEthernet0/0 with the recorded exact name on this router.
no ipv6 address 2001:db8:13:1::2/64- Remove only Router2's specified documentation address; retain its separately configured link-local address.
end- Leave configuration mode and return to the # prompt for inspection or testing.
show ipv6 interface GigabitEthernet0/0- Display the selected interface's state, link-local address, other addresses and multicast memberships.
- What you should see
- The exact documentation address should disappear while fe80::13:2 remains and the interface remains up. Stop if another address or interface changed unexpectedly.
- Why this step matters
- The controlled change is one removed assignment, not a broken cable, changed route or disabled IPv6 stack.
Compare failure and local success on Router1
In the isolated project, right-click Router1 and choose Console before typing. Run one ping at a time. If the link-local ping asks Output Interface, enter this router's mapped cable interface, for example GigabitEthernet0/0, and press Enter. That response is not a new command. Do not append /64 or a guessed %zone to the target. Repeat the identical original targets. Do not replace the failed documentation target with ::1 or with Router1's own address.
ping ipv6 2001:db8:13:1::2
ping ipv6 fe80::13:2What each command means
ping ipv6 2001:db8:13:1::2- Send echo requests to the other router at 2001:db8:13:1::2; this is a peer test, not a ping to this router's own address.
ping ipv6 fe80::13:2- Test the peer's link-local address fe80::13:2; supply the mapped output interface when prompted to select the correct link.
- What you should see
- No replies are expected from the removed documentation address. Replies should still come from fe80::13:2 on the retained link. A cached neighbor mapping cannot make Router2 own an address that was removed.
- Why this step matters
- The contrast supports a narrow conclusion: local connectivity survived, but the original target is unavailable. It does not certify Internet or application health.
Restore Router2's original assignment
In the isolated project, right-click Router2 and choose Console before typing. Reconfirm the mapped interface and restore the exact original documentation address and /64. Keep the existing link-local assignment unchanged. Inspect the result before asking Router1 to retest.
configure terminal
interface GigabitEthernet0/0
ipv6 address 2001:db8:13:1::2/64
end
show ipv6 interface GigabitEthernet0/0What each command means
configure terminal- Enter global configuration mode; subsequent configuration applies only to this fresh lab device.
interface GigabitEthernet0/0- Select the mapped cable interface; replace GigabitEthernet0/0 with the recorded exact name on this router.
ipv6 address 2001:db8:13:1::2/64- Restore the specific removed documentation address with its original prefix length.
end- Leave configuration mode and return to the # prompt for inspection or testing.
show ipv6 interface GigabitEthernet0/0- Display the selected interface's state, link-local address, other addresses and multicast memberships.
- What you should see
- Both Router2 addresses should again be present, with a usable interface and no duplicate-address failure. An accepted command alone does not establish restored reachability.
- Why this step matters
- Rollback restores the planned configuration rather than changing the requirement to match the fault.
Retest the original Router1 checks
In the isolated project, right-click Router1 and choose Console before typing. Run one ping at a time. If the link-local ping asks Output Interface, enter this router's mapped cable interface, for example GigabitEthernet0/0, and press Enter. That response is not a new command. Do not append /64 or a guessed %zone to the target. Repeat both baseline targets after restoration and compare the observation table. Keep this step separate from the configuration step.
ping ipv6 2001:db8:13:1::2
ping ipv6 fe80::13:2What each command means
ping ipv6 2001:db8:13:1::2- Send echo requests to the other router at 2001:db8:13:1::2; this is a peer test, not a ping to this router's own address.
ping ipv6 fe80::13:2- Test the peer's link-local address fe80::13:2; supply the mapped output interface when prompted to select the correct link.
- What you should see
- Both tests should return replies again. If the documentation target still fails, inspect the exact restored address and interface instead of treating the local-link success as enough.
- Why this step matters
- The original failure must be retested directly; success to a different address does not close the fault.
Retest the reverse direction on Router2
In the isolated project, right-click Router2 and choose Console before typing. Run one ping at a time. If the link-local ping asks Output Interface, enter this router's mapped cable interface, for example GigabitEthernet0/0, and press Enter. That response is not a new command. Do not append /64 or a guessed %zone to the target. Test Router1's original two addresses and save final observations in the same notes file. Keep the project disconnected.
ping ipv6 2001:db8:13:1::1
ping ipv6 fe80::13:1What each command means
ping ipv6 2001:db8:13:1::1- Send echo requests to the other router at 2001:db8:13:1::1; this is a peer test, not a ping to this router's own address.
ping ipv6 fe80::13:1- Test the peer's link-local address fe80::13:1; supply the mapped output interface when prompted to select the correct link.
- What you should see
- Both reverse tests should return replies. The final record distinguishes baseline, removed-address and restored states, with actual source, target and interface details.
- Why this step matters
- Recovery evidence includes the intended state and repeated peer exchanges, not a copied example output.
Compare groups and services on paper
Do not enter commands. Draw Sender, MemberA, MemberB and Nonmember for multicast; draw Client, RouteChoice, ServiceA and ServiceB for anycast as described in the teaching section. Label these paper models, not additional GNS3 nodes. Trace intended recipients and write what was not simulated.
- What you should see
- The multicast exercise marks the two members as intended recipients; the anycast exercise chooses one service under the stated fictional routing rule. Neither result is reported as measured delivery.
- Why this step matters
- Conceptual comparisons cover the address types without pretending that this two-router lab runs multicast applications or a redundant anycast service.
Verify
- Record both actual software versions, exact mapped interfaces, operational states and the distinct assigned unicast addresses.
- Save the actual joined multicast groups separately from unicast assignments; membership is not an application delivery measurement.
- Before the fault, verify both peer targets in both directions and record which local interface was used for link-local testing.
- During the fault, confirm Router2 no longer owns the documentation target, then record its failed original ping and the retained link-local result.
- After restoration, verify the original assignment and repeat both targets from both routers; do not accept a self-ping as recovery.
- Label paper comparisons and expected results honestly. QCS has not run this lesson on a Cisco image, and this lab does not measure Internet, anycast or application service health.
Troubleshoot
- Perform these tests only in the isolated project. If a mapped interface is missing, recheck the selected template, adapters and cable labels. Do not paste commands into a guessed interface or a router carrying shared traffic.
- If an interface is administratively down, return to that router's Console and the checked cable interface, then use no shutdown as shown in its setup step. If protocol remains down, verify both nodes are started and the cable uses their recorded ports.
- If a link-local ping asks for an interface, enter the sending router's mapped cable port. A percent-zone suffix copied from another operating system or a port from the receiving router is not a reliable substitute.
- If the expected baseline does not work, inspect exact assignments, duplicate-address status and interface state first. Neighbor initialization can affect early probes; repeat a baseline test after stabilization. Persistent loss can also reflect filtering or rate limits and is not a unique layer diagnosis.
- If the removed documentation target still replies, confirm the exact-address removal and check that there are no extra nodes or duplicate assignments. Do not explain away the unexpected result as a successful cached reply.
- If the restored target fails while link-local still replies, compare every address group and /64 against the table. Record the specific failing target; do not disable IPv6 controls or add routes without evidence.
GNS3 does not provide Cisco images. Use Cisco software only when its applicable license or entitlement permits the selected environment. Do not share or redistribute image files. Cisco Modeling Labs is the official alternative; ownership of CML reference images does not grant permission to export them into GNS3. Without authorized images, complete the labeled paper exercise and do not claim hands-on execution.
- Complete the restoration and both-direction retests before finishing. Save your actual notes and keep them separate from the lesson's predicted observations.
- Stop Router1 and Router2 in GNS3. For this new disposable project, return to the saved clean project snapshot if you want the original pre-lab state; first preserve the evidence you need.
- Do not erase a real router or remove unrelated addresses. All testing, restoration and snapshot work here applies only to the isolated lab, never production or shared traffic.
- Keep authorized software within its permitted environment and do not export or share Cisco image files with the project.
Practice set
Answer before you reveal
01Is link-local a fourth alternative to unicast, multicast and anycast?
Recipient behavior and scope are separate questions. Classifying fe80::13:2 as unicast and local-link avoids treating two compatible properties as competing answers.
02Why can a link-local ping require the sending interface?
A link-local numerical value can appear on separate links. The local interface selection resolves that ambiguity; it is not part of a globally unique address and is not the remote interface name.
03What is wrong with using fd00::1 everywhere because ULA means private?
The locally assigned fd00::/8 form includes a pseudo-random 40-bit Global ID to reduce collision risk. Private routing still needs route and security policy, especially when networks merge.
04Does an address beginning with 2001 prove public Internet reachability?
The lesson deliberately uses 2001:db8::/32 documentation space in a disconnected project. Successful peer replies there show only the local test, not a public allocation or Internet connection.
05Can the text of an ordinary unicast-format address prove that a service uses anycast?
Anycast does not have a universal distinctive prefix. Under the paper example's stated routing rule one available service is selected; the rule does not claim geographical proximity or automatic health checking.
06What does a joined multicast group entry establish?
The membership display is useful local state. Application delivery, forwarding policy and group scope need their own evidence. This exercise does not deploy a multicast application.
07During the controlled fault, why may link-local work while the original target fails?
The two tests name different targets on one peer. A retained local reply cannot substitute for restoring and retesting the removed address, and a cached neighbor entry does not reassign that address.
08Why is a reply from ::1 insufficient to close a remote connectivity incident?
An evidence record must match the actual requirement. Use the named peer target, source and local interface, then record results; self-tests and paper predictions cannot replace those observations.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Ask who the recipient is and where the address is meaningful before selecting a test.
- Link-local is unicast limited to one link; unique-local can be routed within a cooperating private network.
- Multicast membership describes a group relationship, not measured application delivery.
- Anycast uses unicast-format addresses and routing choice; it is not identified by a magic prefix or automatically by geography.
- A retained link-local reply cannot prove that a removed unicast target or dependent application works.
- Keep baseline, controlled fault and restoration evidence separate, and never report paper predictions or static review as device execution.