IPv4/IPv6双栈网络IPv4故障闭环排查指南

做网络运维这行早些年大家愁的是“双栈网络里 IPv6 怎么配”现在风向反过来了——双栈跑起来以后真正让人头疼的恰恰是 IPv4 故障反而更隐蔽了。这个“IPv4/IPv6 双栈网络 IPv4 故障闭环排查指南”标题我一看就来劲因为它戳中了很多人踩过的坑业务方报“IPv4 访问慢、时好时坏”可我们查下来 IPv6 一切正常用户甚至怀疑“是不是 IPv4 该淘汰了”。实际上没那么玄这类问题往往就藏在 ARP、路由表或者 DNS 策略里。这篇指南就是把这套排查思路完整拆开双栈环境下 IPv4 故障为什么难查、什么叫闭环排查、每一步该用什么工具和命令最后用一个真实处理过的案例全程复盘让同行能直接照着抄作业。1. 双栈没你想的那么玄IPv4故障为什么更难查1.1 双栈机制独立协议栈共享物理链路很多人一听“IPv4/IPv6 双栈”就以为是把两个协议揉在一起其实不是。双栈就是在同一张物理网络上同时跑两套完全独立的协议栈IPv4 这边有 ARP、IPv4 路由表、NAT、DHCPv4IPv6 那边有 NDP邻居发现协议、IPv6 路由表、SLAAC 或 DHCPv6。应用层通过 DNS 拿 A 记录和 AAAA 记录操作系统再按 Happy Eyeballs 算法RFC 6555 和 8305决定优先尝试哪个地址族。这里的关键词是“独立又耦合”。独立体现在控制面IPv4 的路由协议可以崩IPv6 的转发照常通IPv4 的 ARP 风暴也基本影响不到 NDP。耦合体现在数据面光纤断了、交换机端口 down 了、MTU 不通了两个协议栈一起完蛋。理解这个关系之后才能解释为什么双栈环境里会出现“v6 通 v4 不通”这种看起来匪夷所思的现象——因为坏的根本不是物理链路而是 IPv4 自己的二层或控制面环节。另外还有一层耦合容易被忽略防火墙和安全设备。很多防护策略同时作用于 v4 和 v6但规则条件里只写了 v4 的地址或端口比如一条针对源地址段的 ACCEPT 规则v4 流量能过v6 流量却因为匹配不到而落进默认 DENY。这也会造成“v6 不通 v4 通”和标题相反但排查逻辑是同一个不能因为一个栈通了就断定链路没问题。1.2 IPv4故障在双栈环境里更隐蔽的三个原因第一个原因是应用层的自救机制。有了 Happy Eyeballs客户端会并行发起 IPv4 和 IPv6 连接谁先成功就用谁。如果 IPv4 故障是“间歇性延迟高”而不是“完全不通”用户很难察觉到异常因为应用早就悄悄切到 IPv6 了。表面看一切正常实际上 v4 侧已经在持续丢包只是没有人上报。第二个原因是监控盲区。很多团队做双栈改造时监控系统只加了 IPv6 的探测任务比如每 30 秒 ping 一次 IPv6 网关、跑一次 v6 的 HTTP 检查但 IPv4 的监控项还停留在旧的“单点拨测”根本没覆盖到新增的网段和路径。结果就是 v6 挂了能收到告警v4 挂了要等用户投诉。第三个原因是排查时的思维惯性。传统排查习惯是“先确认网络通不通”于是随手 ping 了一下发现通就认为网络没问题。在双栈环境里这个判断必须拆成两条线v4 通了没有v6 通了没有我见过太多人只看到 v6 通就跳过了 v4 检查结果绕了一大圈最后发现问题是 IPv4 地址池耗尽或者 DHCP 租约异常。所谓闭环排查第一步就是建立这种“双视角”的检查习惯。2. 闭环排查四步法先定现象再缩小范围最后验证2.1 为什么强调“闭环”两个字“闭环排查”这个词听起来像管理话术但放到网络故障里非常实在。闭环意味着四个阶段缺一不可确认现象、界定范围、定位根因、验证修复。很多运维同行的问题不是不会用命令而是跳步。最常见的跳步是“改了配置就算完事”。比如怀疑路由问题在核心交换机上敲了一条静态路由流量恢复然后就没有然后了。结果一周后故障复现才发现当初那条路由根本不是根因只是碰巧把流量引到了别的路径上绕开了故障点。这不是修复是掩盖。闭环要求的是修复动作必须能解释根因修复之后还必须按多个维度验证确认故障不会以别的形式冒出来。另一个跳步是“现象没定义清楚就开查”。用户说“网页打不开”你直接跑到机房抓包可能折腾半天才发现用户指的是某个内网系统超时和机房链路半毛钱关系没有。所以闭环第一步一定是把“打不开”“很慢”这样的口语翻译成可执行的技术描述。2.2 第一步把模糊反馈翻译成技术现象拿到反馈后我通常先填一张现象画像表内容不超过六项维度要问清楚的问题哪个栈只有 IPv4 受影响还是 v4/v6 都异常哪个方向用户访问服务器还是服务器主动外连时间规律持续故障还是间歇性是否和业务高峰重合变更关联故障前最近一次网络变更、版本发布是什么范围边界单个用户、单个网段、还是全网表现形态完全不通、高延迟、丢包、还是“偶尔超时”这张表填完故障基本已经从“不明觉厉”变成“有方向的问题了”。比如“只有 IPv4、某个网段、持续故障”那大概率是该网段的网关 ARP、DHCP 或路由策略出问题“间歇性、和高峰重合”则要考虑 NAT 表项溢出、连接跟踪表满、ECMP 哈希不均等资源型问题。这一步千万别嫌麻烦它省下来的时间远超填表的时间。我自己的经验是只要现象描述足够精确后边的排查步骤一般不超过四到五步就能命中根因。2.3 第二步三分法定界把故障按坐标定位范围界定的本质是回答“故障到底在哪一段”。我习惯用三分法拆按端侧分是源端问题、中间路径问题还是目的端问题。最简单的验证方法就是“换端测试”从另一台不同网段的机器访问同一个目标如果也失败说明问题在目标端或路径上源端可以排除。按层次分物理链路一出现故障就是 v4/v6 同时遭殃所以一旦发现只有一个栈异常直接跳过物理层重点查 L2ARP/VLAN、L3路由/策略、L4端口/TCP、L7DNS/应用。分层的价值是把排查范围从“整个网络”缩小到“某一层”避免在无关环节浪费时间。按协议分IPv4 专属故障ARP、DHCPv4、NAT、OSPFv2、v4 路由黑洞、IPv6 专属故障NDP 邻居表、SLAAC、DHCPv6、OSPFv3、共享故障MTU、DNS、防火墙资源耗尽、物理链路。这个分类最实用因为只要确认“v6 正常”IPv4 专属的几个环节就成了重点嫌疑对象。2.4 第三步定位根因必须形成证据链定位根因不是找到一个可疑点就停手而是要把“现象—证据—结论”串成一条逻辑链。比如发现 ARP 表里网关 MAC 地址在几个交换机端口之间跳变这只是证据还需要说明这个跳变如何导致 IPv4 丢包冲突设备抢答网关 ARP 后发往网关的流量被错误转发到该设备该设备不具备转发能力又丢弃报文所以表现为“v4 间歇性不通v6 完全正常”。证据链闭合结论才算成立。实操中我会随手记录每一步的命令输出哪怕只是 tcpdump 抓到的三条 ARP 报文。这些输出既是自己的排查轨迹也是写故障报告的第一手素材。很多问题排查到一半被打断回来全靠这些记录续命。2.5 第四步修复后必须做四维验证修复动作完成后验证不是“再 ping 两下看通不通”我会按四个维度做回归连通性验证ping 网关和远端目标v4/v6 都测、稳定性验证持续监测 30 分钟以上观察延迟和丢包曲线、业务层验证实际访问对应服务确认不是“网络通但业务不通”、长期观测验证在监控平台挂上告警观察 24 到 72 小时。有人觉得这样小题大做但“验证不彻底”恰恰是故障复发的温床。尤其像 ARP 漂移这类问题冲突设备可能只在特定时间段上线修完确认的那一刻是好的第二天同一时间又冒出来。只有把长期观测纳入闭环才能真正收尾。3. 排查工具实测三层递进抓包放最后3.1 第一层链路与邻居层排查先解决“是不是我”这一层解决的是本地栈和直连链路的问题。首选命令永远是 ping但必须同时测网关的 v4 地址和 v6 地址。如果 v4 ping 网关不通、v6 通基本可以排除物理链路把注意力放到 IPv4 的二层协议上。接下来查邻居表Linux 用ip neighWindows 用arp -a查看网关 MAC 地址是否稳定、是否有多个 IP 对应同一 MAC 的异常。用arping比如arping -I eth0 192.0.2.1主动探测连续发几个包看是否有多个 MAC 应答。一个 IP 多个 MAC 就是地址冲突或网关漂移的实锤。还有一个很多人忽略的点sticky ARP 或端口安全策略。交换机的动态 ARP 表如果被异常刷新会把网关 MAC 学到错误端口导致流量黑洞。排查时可以登录交换机看mac address-table里网关虚拟 MAC 出现在几个端口上。如果出现多端口基本就是二层环路或者私接设备。这一层还有一个命令值得养成习惯ethtool eth0检查网卡速率、双工模式和错误计数。双工不匹配一边自动协商一边强制百兆全双工会造成高延迟和偶发丢包而 v4/v6 都会受影响如果恰好只测了 v6 就会漏判。3.2 第二层路由与转发排查确认包有没有走对路链路层没问题后就要确认三层转发是否正常。先在源端看本机路由Linuxip route show重点看默认路由是否走了正确的下一跳。网络设备show ip route看目标网段的路由是否存在、是否被黑洞路由吃掉了。然后进行路径探测。这里必须提醒一个经典误区traceroute的输出不能只看“哪一跳星号”就断定哪里丢包。很多核心设备对 ICMP 或 UDP 的 TTL 超时报文做了限速或直接丢弃导致中间跳显示星号但实际转发完全正常。更麻烦的是 ECMP等价多路径场景同一目的地存在多条路径traceroute 的每个包可能被哈希到不同路径结果表现为“路径跳变”或者“某些跳不通”这是正常现象不是故障。正确的做法是多次探测并对比Linux 下用traceroute -n -T -p 443 目标IP走 TCP 443更能反映真实业务路径。同时用mtr -n -r -c 100 目标IP做连续探测看每一跳的丢包率的稳定性和走向。如果怀疑 ECMP 哈希不均可以用ping的源地址变化-I指定不同源IP来模拟不同哈希结果看延迟和丢包是否存在明显分化。路由层面还容易踩“策略路由”的坑。双栈设备经常配了基于源地址的策略路由比如某个 VLAN 的 IPv4 流量强制走特定出口。这种策略在路由表里看不出来必须看show ip policy或具体的 PBR 配置。我曾经遇到过一次 v4 不通的故障查了两小时最后发现是策略路由里的下一跳交换机 down 了而正常的路由表默认路径被策略覆盖了。所以“路由表看着没问题”不等于“转发路径没问题”。3.3 第三层连接与应用层排查把网络问题和服务问题分开如果网络链路和路由都正常但业务还是不通问题往往出在 L4/L7。这层排查的核心命令是ssLinux或netstatss -tan看本机与外部的 TCP 连接状态。如果大量连接停在SYN_SENT说明 SYN 包发出去了但没回 ACK多半是中间设备丢包或目标端 backlog 满如果停在SYN_RECV说明目标收到了 SYN 但回包没到源端要查反向路径。ss -lntp看服务监听地址。这里有个双栈专属大坑一个服务如果只监听在0.0.0.0:80那么它只提供 IPv4 服务如果监听在[::]:80在 Linux 上通常也接受 IPv4 映射连接但 Windows 上不一定是这个行为。很多“IPv4 端口不通但 IPv6 正常”的故障根因就是服务只绑定了 v6 地址。端口连通性测试推荐nc -vz 目标IP 端口或者telnet 目标IP 端口。注意要分别用 v4 地址和 v6 地址测不要只测域名——因为 DNS 解析结果可能只返回 AAAA 记录误导你判断。应用层最重要的工具是 DNS 排查dig 域名 A和dig 域名 AAAA分别确认两类记录是否存在。dig 域名 short看解析结果是否返回了预期 IP。如果 A 记录解析超时或返回空客户端会等待很长时间才回退表现为“IPv4 访问特别慢”。DNS 还有一个双栈特有的超时陷阱某些系统配置了多个 DNS 服务器第一个 DNS 只响应 v6第二个只响应 v4。当应用发起 v4 DNS 查询时如果查询被分流到 v6 服务器上就会一直等到超时再换下一个造成 v4 解析延迟数秒。这个可以用dig指定服务器逐个测试来验证。3.4 抓包的正确姿势定位到环节后再取证抓包不是排查的第一步它是定位到具体链路或设备后的取证动作。没有方向地全链路抓包只会抓到几十 GB 的数据然后不知道从哪看起。定位到“某一跳丢包”或“某台设备异常”后再用 tcpdump 精确过滤# 在可疑设备镜像口或服务器上抓取特定主机的双向流量 tcpdump -i any host 192.0.2.10 -nn -w /tmp/capture.pcap # 只看 ARP 请求和应答 tcpdump -i eth0 arp -nn # 只看 TCP 握手失败过程留意 SYN 是否有响应 tcpdump -i eth0 tcp port 443 -nn tcp[tcpflags] (tcp-syn|tcp-ack) ! 0 # 抓 ICMP 不可达信息排查 MTU 黑洞 tcpdump -i any icmp and host 192.0.2.1 -nn抓包的关键不是抓得多而是抓到“故障发生的那个瞬间”。所以看到间歇性故障抓包一定要挂足够长的时间并配合 ping 或业务请求持续触发流量否则很容易错过问题报文。抓到包后优先看三类内容有没有重复的 ARP 应答、SYN 有没有回包、有没有 ICMP 分片不可达。这三类基本覆盖了双栈环境里 v4 故障的九成根因。4. 一次双栈IPv4故障的完整闭环复盘4.1 故障现象v4间歇性失败v6完全正常模拟项目X的案例是这样的某公司办公网做了双栈改造核心业务系统同时提供 v4 和 v6 访问。改造后没多久二楼的研发同事反馈通过 IPv4 访问内部 Git 服务时经常性超时或连接重置但用 IPv6 地址访问同一服务就特别流畅。故障不是持续的大约每隔十几分钟出现一次每次持续一两分钟。先填现象画像协议栈是 IPv4 异常、IPv6 正常方向是用户端访问服务器时间规律是间歇性范围只涉及二楼研发网段其他楼层没同类问题表现形态是超时和连接重置。到这里基本能排除物理链路重点怀疑二层或三层的不稳定。4.2 排查过程从ARP表一路追到接入交换机第一步做连通性测试。从二楼一台终端 ping 网关的 v4 地址发现丢包率在 20% 左右但 ping 网关的 v6 地址零丢包。这就实锤了“物理链路没问题问题在 IPv4 二层协议”。第二步查邻居表。在终端上执行ip neigh发现网关 IP 的 MAC 地址在几分钟内发生了三次跳变分别对应了三台交换机的端口。这时基本可以断定存在 ARP 地址冲突或网关 MAC 漂移。MAC 漂移的原因要么是交换机二层环路导致网关 MAC 从多个端口被学习到要么是有人私接设备抢答 ARP。第三步抓包取证。在接入交换机的镜像口挂 tcpdump过滤arp抓了大概五分钟抓到关键证据同一网关 IP 有三条 ARP 应答分别来自三台设备的 MAC。更关键的是其中一条应答来自一台无线 AP 的管理口地址——那台 AP 的管理 IP 被人为设置成了和网关同网段的静态地址恰好和网关 IP 冲突。第四步分析根因链路。网关设备定期发送免费 ARPGratuitous ARP刷新各终端 ARP 表而冲突的 AP 因为配置了相同 IP也会在某些情况下响应 ARP 请求。终端 ARP 表被刷新成 AP 的 MAC 后发往网关的流量就跑到 AP 上AP 又没有路由转发能力只能把包丢掉直到下一次网关免费 ARP 把 ARP 表纠正回来。这就解释了为什么故障是间歇性的也解释了为什么 v6 完全不受影响——IPv6 的 NDP 邻居表完全独立和 ARP 表没有关系。4.3 修复与闭环验证改IP不是终点根因明确后修复动作很小把无线 AP 的管理 IP 改成其他网段并在 DHCP 服务器里加了一条排除地址防止再次分配到这个冲突 IP。改完两分钟二楼终端 ping 网关 v4 的丢包率降到 0。但闭环没完。我又做了三件事第一持续 ping 网关 v4 地址两个小时确认没有再次出现丢包第二让二楼研发同事实际访问 Git 服务连续提交和拉取代码半小时确认业务层完全正常第三回到监控平台给网关 IP 加了一条 ARP 表项变化告警并对照 IPAMIP 地址管理台账排查了全网的静态 IP 配置杜绝类似冲突再出现。这次故障从上报到闭环整个过程大约三小时。真正定位到根因其实只花了不到四十分钟剩下大部分时间都花在确认现象、排除误判和验证修复上。复盘时团队的共识是如果在故障一开始就意识到“v4 和 v6 要分开查”可能还能再快半小时。5. 双栈IPv4故障速查表与三个压箱底的经验5.1 常见故障速查表在双栈网络里排障最值钱的是方向感。我根据自己的实操经验整理了一张速查表基本覆盖了日常能遇到的大部分 v4 故障场景故障表现优先怀疑方向快速定位命令/方法v4 间歇性断流v6 正常ARP 冲突、网关 MAC 漂移ip neigh、arping、交换机mac address-tablev4 完全不通v6 正常v4 路由缺失、DHCP 租约异常、NAT 失效ip route show、show ip route、DHCP 日志v4 ping 通业务端口不通服务只监听 v6、防火墙策略拦截、TCP backlog 满ss -lntp、nc -vz 目标 v4地址 端口v4 高延迟v6 正常出口策略路由异常、ECMP 哈希不均mtr -n -r、多次 traceroute 对比v4 大包不通小包正常MTU 黑洞、PMTUD 失效ping -M do -s 1472逐级测试v4 域名解析超时A 记录缺失、DNS 服务器分流错误dig 域名 A、dig 每个服务器 域名 Av4 连接建立后频繁重置NAT 表项老化、防火墙连接状态表溢出查看网络设备 NAT/会话表使用率v4 某些网页能开某些开不了域名解析到旧地址、CDN 只配置了 v4对比 A 记录与 CDN 节点 IP这张表不是万能药但它能帮你把 80% 的“看着没头绪”的问题压缩成两三个候选方向。剩下的 20%就靠前面的闭环方法和抓包手段去抠。5.2 经验一永远先看服务监听地址双栈环境里最容易被忽略的问题之一是服务进程监听地址的细微差异。很多应用默认配置是listen [::]:80或者listen 0.0.0.0:80这两者在大多数系统上都能同时服务 v4 和 v6但有些场景下只监听 v6 地址的进程v4 连接会被拒。比如某些 Java 或 Node.js 应用在双栈 socket 配置不规范时会出现“v6 能访问v4 连接直接 refused”的情况。排查时不要只看端口有没有监听一定要用ss -lntp看清楚监听地址是0.0.0.0还是[::]再确认对应进程的 IPV6_V6ONLY 参数设置。如果服务只绑定了 v6v4 流量自然进不来但网络侧看起来完全健康。这类问题用网络命令查一辈子也查不出来必须把视角切到应用配置上。5.3 经验二MTU黑洞比你想的更常见IPv4 分片和 MTU 问题在双栈环境里尤其容易发作因为隧道封装会显著增加包头开销。比如 IPv4-over-IPv6 隧道场景IPv6 基础包头加隧道头可能增加 40 字节以上导致原来 1500 的 MTU 变成 1460。如果链路两端的 MTU 不一致又禁用了 ICMP 分片不可达消息的转发大包就会在中间被静默丢弃表现为“大文件传输失败、网页图片加载不出来、ping 小包却完全正常”。排查方法很直接从源端发一个固定大小且禁止分片的 ping 包逐步增大找到临界值。Linux 下用ping -M do -s 1472 -c 3 目标IP1472 是 1500 MTU 对应最大负载需要按路径 MTU 减掉 IP 头。如果-M do模式下大包不通而-M want模式能通就能确认是路径 MTU 或分片限制问题。修复的思路是统一二三层设备的 MTU或在防火墙上允许 ICMP 的 Fragmentation Needed 消息恢复 PMTUD 机制。5.4 经验三别把“IPv4地址池”当成理所当然的资源双栈改造之后很多人的注意力全放在 IPv6 规划上反而忽略了 IPv4 侧依然存在的资源瓶颈。我在实际项目里见过不止一次内网 IPv4 地址段本来就紧DHCP 地址池几乎耗尽新增设备无地址可用。这种故障的隐蔽之处在于IPv6 侧用 SLAAC 自动分配地址所有新设备都能正常上网给人的感觉是“网络没问题”但老旧的 IPv4 依赖系统比如某些只会解析 A 记录的老应用越用越卡、越用越频繁超时。处理这种问题的思路不是临时调 DHCP 池子而是从 IPAM 规划层面做压缩清理回收长期不用的地址、把静态 IP 改为保留地址池、推动存量应用增加 AAAA 支持。很多公司觉得“IPv4 地址反正也申请不到新的了凑合用”但实际上内部地址的浪费率往往在 30% 以上整理一轮能挤出不少余量。6. 最后的话把排查变成流程而不是运气我自己处理过不少双栈网络的故障最大的体会是IPv4 问题的根因从来都不复杂复杂的是一开始就掉进“只看单栈”的思维陷阱。无论是 ARP 冲突、路由策略覆盖、NAT 表溢出还是服务监听地址配置只要严格按“确认现象—界定范围—定位根因—验证修复”的闭环来走再配合 v4/v6 双视角的检测手段基本不会偏到哪儿去。最后再分享一个实在的建议每个团队都值得把本网络的双栈拓扑、关键网关 IP、DHCP 地址池范围、NAT 表项上限这些信息整理成一张“网络家底表”。故障发生时对照这张表可以省掉大量从零开始的信息收集时间。排障靠流程不靠灵光一现这才是双栈时代运维最该养成的工作习惯。