A housing authority dual-stack site needs an IPv6 backup path that stays out of the table while a preferred dynamic IPv6 route is present. What approach is correct?
Select an answer to reveal the explanation.
Short Explanation
IPv6 backups play by the same floating-static idea: worse AD keeps them sleeping. When the preferred IPv6 path vanishes, the higher-AD static wakes up — no IPv4 tricks required.
Full Explanation
Floating static behavior is address-family specific. A housing authority dual-stack site that needs an IPv6 backup to remain standby while a preferred dynamic IPv6 route is present must install a floating IPv6 static with a higher administrative distance than that preferred source (for example, higher than OSPFv3’s AD). The backup next hop is configured for the IPv6 prefix, but the worse AD keeps the static from installing until the dynamic IPv6 route is withdrawn.
Advertising or relying on an IPv4 static does not create IPv6 RIB entries; IPv6 does not “inherit” IPv4 floating backups. Configuring the backup with AD 1 forces it to override dynamic IPv6 routes and makes it primary, not standby. Deleting the primary IPv6 route daily for production testing is operationally unsafe and is not a design for automatic failover.
Exam caveat: compare AD within the IPv6 routing table; IPv4 AD values on another static do not govern IPv6 installation. Know the AD of the preferred protocol (OSPFv3, EIGRP for IPv6, etc.) before choosing the floating value. Operational check: with the preferred IPv6 route present, ensure the backup static is not active for that prefix; withdraw or fail the primary path, confirm the higher-AD IPv6 static installs, and verify dual-stack user traffic to that destination follows the backup IPv6 next hop.