A water utility configures an IPv6 static to a remote SCADA /64 and needs to verify forwarding. What confirms the route is installed?
Select an answer to reveal the explanation.
Short Explanation
Check the IPv6 routing table for that /64 and next hop — that’s the scoreboard. IPv4 tables and LLDP name tags don’t prove IPv6 forwarding.
Full Explanation
A water utility IPv6 static to a remote SCADA /64 is confirmed the same way as any IPv6 route: the IPv6 routing table must list that /64 with the configured next hop, and traffic destined to addresses in the prefix must use it. IPv4 and IPv6 tables are separate; success in one does not prove the other. Verification commands such as show ipv6 route (and CEF/FIB equivalents) are the scoreboard for SCADA IPv6 reachability on treatment and distribution networks where telemetry must not depend on accidental IPv4 tunnels.
An IPv4 routing table will not show a translated copy of the IPv6 SCADA prefix as proof of IPv6 installation—looking only at IPv4 is a false positive risk. LLDP naming the remote switch shows Layer 2 topology hints, not an IPv6 RIB entry and not forwarding proof. Redistribution into OSPFv2 is irrelevant to validating a local IPv6 static and incorrectly mixes IPv4 OSPF with IPv6 reachability checks.
Exam caveat: ensure you are inspecting the IPv6 RIB, not IPv4; also confirm the next hop is reachable via IPv6 (often a link-local next hop on the interconnect). A static can sit in the config yet fail to install if the outgoing interface is down or the next hop does not resolve. Operational check: show the /64 in the IPv6 routing table with the expected next hop, ping a SCADA address in that prefix from the utility router or a test host, and verify the path follows the static’s next hop and interface rather than an unintended default.