症状
家庭主路由、旁路由、Mesh 节点或测试设备中有两台以上设备发送 IPv6 Router Advertisement(RA)后,某些终端的 IPv6 出口会在数分钟到数小时内改变:一个站点先快后慢、只有部分设备连接失败,或者默认路由看似仍在却走了未预期网关。IPv4 仍可用并不能证明这是应用层或 DNS 单点故障。
RFC 4191 定义了 RA 中默认路由偏好和更具体路由信息的扩展。它与 RA 生命周期、接口度量和操作系统策略共同影响最终选路。因而“看到两条 default”不是完整结论,也不应把每个 RA 都直接判成恶意;本页只讨论已获授权网络中,多台合法或待确认设备的出口冲突。
判断层级
按 RA 发送者 → 前缀/默认路由生命周期 → 路由偏好与更具体路由 → 本机接口选择 → 实际目的地址路径 收敛。先找出谁在发 RA,再讨论应该保留哪一个。不要先删 DHCPv6、关闭 IPv6 或把全部设备接到同一旁路由。
如果问题仅发生在一个 SSID 或 VLAN,优先检查该二层广播域;如果在所有 LAN 都发生,才把主路由、旁路由和 Mesh 回程纳入同一证据链。
只读诊断命令
在自己管理的 LAN 上捕获少量 ICMPv6 RA,或以系统路由表代替抓包。不要把完整 MAC 地址、地址租约或家庭前缀写入文章、工单或共享日志。
# Linux/OpenWrt:查看默认路由、到测试目的地的选择与 RA 报文摘要
ip -6 route show default
ip -6 route get 2606:4700:4700::1111
tcpdump -ni <lan-interface> 'icmp6 && ip6[40] == 134' -c 10
# macOS:观察 IPv6 路由表;不修改接口优先级
netstat -rn -f inet6
route -n get -inet6 2606:4700:4700::1111
记录的是“是否有多个发送者、每个发送者发布的默认路由状态、复现时命中的下一跳”,不是网络中的真实地址清单。若终端不允许抓包,只比较问题发生前后的默认路由和测试结果即可。
判断分支
- 只有预期主路由发送 RA,终端仍频繁换路:检查该路由器的 RA 生命周期、WAN IPv6 上游状态和终端的接口切换;不要把正常的续约误判为优先级冲突。
- 主路由与旁路由都发送默认 RA,但只有一台应承担出口:将旁路由改为不宣告默认路由,或把它放到独立 VLAN;保留 LAN 管理回程后再验证。
- 第二台设备只应提供一个内部前缀:确认它是否通过 RFC 4191 的更具体路由发布了预期范围,而非发布默认出口。更具体路由不能替代默认路由边界设计。
- 未知设备发送 RA:先隔离到获授权的接入端口并取证,再检查 AP、桥接、容器或测试路由器。不要在没有来源证据时对全网下发封禁规则。
最小修复
每个 VLAN 明确一个默认 IPv6 出口;需要旁路由访问的流量使用更具体、可解释的路由或受限策略,而不是让旁路由和主路由竞争 default。变更前导出现有 OpenWrt 网络与防火墙配置,先在一台测试终端确认 LAN 管理地址和预期 IPv6 路由仍可达。
RA Guard 或交换机侧保护可减少非预期 RA 进入接入网,但它必须按设备和协议能力设计。它不能修复错误前缀委派、Wi-Fi 漫游、网线问题或终端自身的 VPN 接口优先级。
验证
在一个完整 RA 生命周期内重复观察默认路由和到同一 IPv6 测试地址的下一跳;然后让另一台终端在相同 VLAN 做对照。确认预期网关稳定、管理 LAN 可达、仅为内部前缀设置的更具体路由仍生效。若是多 VLAN 网络,应逐个验证,不要把一个 VLAN 的成功外推到全部 SSID。
证据与边界
默认路由偏好与更具体路由的协议含义以 RFC 4191 为准,证据由 Research Engine 静态抓取。本文不提供绕过网络控制的手法,也不对任何特定设备能否发送或过滤 RA 作保证。