I85PREP
⌘ K
Huawei HCIA-Datacom study materials
Huawei HCIA-Datacom study resources

Two IPv6 Routers Advertising - Wrong Default Gateway and DHCPv6 Flags

Huawei HCIA-Datacom · Put your knowledge to work in context.

All case studies

Two IPv6 Routers Advertising - Wrong Default Gateway and DHCPv6 Flags

A branch LAN uses prefix 2001:db8:10:1::/64. Two routers advertise RAs on it. R1 is a legacy router whose uplink was decommissioned but which is still powered on and advertising the prefix with default lifetime 1800 and router preference high. R2 is the new gateway with the real uplink toward HQ (2001:db8:20::/64); its RA uses preference medium and default lifetime 1800. Hosts configure global addresses correctly and can ping both routers' link-local addresses, but they cannot reach 2001:db8:20::10. R2 has a static route ::/0 toward the ISP and a specific route for 2001:db8:20::/64. Management also wants DNS delivered by DHCPv6, and the current RA advertises M=0 and O=0 while R2 runs a DHCPv6 server.

1. Explain why hosts have valid addresses and can reach both link-local addresses, yet cannot reach HQ. What single mechanism explains it?

Read the worked answer

Address configuration and default-gateway selection are separate processes in IPv6, and only the second one is broken.

  • Addresses: the prefix information option in the RA makes hosts build a 2001:db8:10:1::/64 address regardless of which router sent it. Both routers advertise the same prefix, so the addresses are correct and stable.
  • Link-local reachability: a ping to a router's link-local address is on-link; it uses the neighbour cache and needs no default route at all. So success here proves nothing about forwarding.
  • Default gateway: this comes from the router lifetime in the RA, and when several routers advertise, hosts prefer the one with the highest router preference, then the longest lifetime. R1 advertises preference high, R2 only medium, so essentially every host installs R1 as its default router.

R1 has no working uplink, so it either drops or blackholes the off-link packets. Hosts never try R2, because it is not their default. Result: addresses fine, link-locals fine, everything off-link dead.

Confirmation: display ipv6 neighbors and display ipv6 interface on R2 show few or no hosts talking to it off-link; on a host, ip -6 route / netsh interface ipv6 show route shows R1's link-local as the default next hop with the high-preference metric. A capture of RAs on the segment shows two advertisements with different preference values.

2. Describe the fix, in order, including the residual risk if R1 remains powered on and advertising.

Read the worked answer

The goal is that every host selects R2 and only R2.

  1. Immediate: shut the legacy router's RA function (undo ipv6 nd ra halt reversed - i.e. suppress advertisements) or shut down that interface, after confirming nothing else depends on R1. This removes the high-preference default at the source; hosts fall back to R2 within the router lifetime, so expect up to 1800 s of residual failure unless you also flush host caches or use a shorter lifetime during the change.
  2. Reinforce R2: set R2's router preference to high (ipv6 nd router-preference high) so that if R1 ever reappears it loses the election. Verify with display ipv6 interface GigabitEthernet0/0/0 and by capturing RAs.
  3. Prevent recurrence at the network edge: enable RA guard (or ND snooping/RA suppression) on the access switches so only the approved router's RAs are forwarded to the LAN. This is the real fix - step 1 alone leaves the same failure available next time someone powers on an old device.
  4. Check the other direction: HQ must have a route back to 2001:db8:10:1::/64 via R2; a host that can send but not receive looks identical to a default-router problem from the user's seat. Validate with ping from both ends.

Residual risk if R1 stays powered and advertising with no RA guard: whichever device is powered on last wins the election again, and the outage returns silently at the next power event.

3. Management wants DNS from DHCPv6 while keeping SLAAC addresses. The RA currently has M=0 and O=0, and hosts are not taking DNS from R2's DHCPv6 server. Explain the flag semantics and choose an approach.

Read the worked answer

The flags tell the host which other configuration methods to use; they are independent of address assignment.

  • M=1 - managed address configuration: use DHCPv6 for addresses.
  • O=1 - other configuration: use DHCPv6 for non-address parameters such as DNS and domain search.
  • M=0, O=0 - the host should get addresses from SLAAC and should not query a DHCPv6 server at all. Even if R2's DHCPv6 server is perfectly configured, compliant hosts will never ask it for a DNS option. That fully explains the symptom.

Two supported approaches:

  1. Set O=1, keep M=0. Hosts keep SLAAC addresses (A=1) and additionally request DNS via DHCPv6. This matches management's request literally and keeps the addressing model simple. Cost: DNS now depends on a DHCPv6 server, and a DHCPv6 failure means hosts have addresses but no name resolution.
  2. Push DNS in the RA via RDNSS (ipv6 nd ra dns server 2001:db8:10:1::53, with an appropriate lifetime). Stateless, no server dependency, survives DHCPv6 outages, and works even on hosts that ignore DHCPv6. It does not deliver domain search lists on all stacks.

Recommendation: if the only requirement is DNS, use RDNSS and leave M/O at 0 - fewer moving parts. If search domains or per-host options are needed, set O=1 and keep M=0, and make the DHCPv6 server redundant. Either way, verify with display ipv6 dhcp server counters or a RA capture, and remember that clients hold their old DNS until lifetime expiry, so the change is not instantly visible.