1.

确认问题与范围：初步收集症状与影响面

- 先确认是单点还是大面积：确认影响的是单台主机、单个业务端口还是整个出口/多机房。 - 收集时间窗口与波动特征：记录首次出现时间、是否间歇、是否与流量增长同时发生。 - 采集基础数据：保留至少 10 分钟内的 ping、traceroute/mtr、业务日志、监控告警时间线（建议 UTC 时间）。

2.

本地网络与主机检查：排除内网问题

- 检查网口与链路：使用 ifconfig/ip link/ethtool 检查错误计数、丢包、速率、双工不匹配。示例：ethtool -S eth0；ip -s link show eth0。 - 检查CPU/IO负载：top、vmstat、iostat，确认是否因系统资源导致延迟。 - 检查队列与QoS：tc qdisc show dev eth0，查看是否触发 fq_codel 或 HTB 限制，是否有丢包在 egress/ingress。 - MTU/MSS 检查：确认路径MTU变化，使用 ping -M do -s 1472 目标 来测试 MTU 问题。

3.

外部路径诊断：用 traceroute/mtr 精确定位跳点

- 建议工具与参数：traceroute -n -I -w 2 TARGET（ICMP），traceroute -n -T -p 80 TARGET（TCP），mtr -r -c 100 -w TARGET（得到统计）。 - 定位延迟突增跳点：比对每个 hop 的平均时延、丢包率。如果某个 hop 后延迟激增且丢包出现，说明问题在该 hop 或其之后。 - 多点测试：在不同机房/不同出口对同一目标做相同 traceroute，区分是上游问题还是接入侧问题。

4.

BGP与路由层面检查：确认是否为路径变动或策略问题

- 查看本地路由表与邻居状态：在路由器上 run show ip bgp summary / show bgp neighbors /show ip route，确认是否有 BGP flap、邻居重启或大量 withdraw。 - 使用公共 Looking Glass：到上游或目标的 looking glass（如 China Telecom、Level3、NTT）跑 traceroute/bgp 查看差异。列出 AS_PATH 及社区标签以判断是否走了 CN2 专线或被引导到其他链路。 - 检查是否被黑洞/清洗：确认中间是否有黑洞社区或流量工程行为导致延迟增加。

5.

流量层面与抓包分析：验证协议与端口影响

- 抓取示例流量：在问题发生时用 tcpdump -i eth0 host TARGET and port 80 -w /tmp/trace.pcap，时间窗口建议 60-300 秒。 - 比较 ICMP 与 TCP：ICMP 可能被优先处理或被限速，使用 TCP traceroute（-T）与应用层抓包对比，判断是否是控制面与数据面差异。 - 检查 MSS/重传：在 pcap 中搜索 TCP 重传、SYN 重试、零窗口与高 RTT 的 ACK 间隔。

6.

上游与对端沟通模板：高效上报所需信息

- 必备信息清单：发生时间（UTC）、影响目标 IP、源 IP、traceroute/mtr 输出（带时间戳）、pcap（压缩）、ifconfig/ethtool 输出、BGP show 输出、监控图（延迟、丢包、流量）。 - 上报示例一行：事件时间|源机|目标IP|问题现象|首要可疑 hop（traceroute 行号）|已抓包(有/无)。 - 建议同时发到上游 NOC 与 CN2 专线运维：注明期望（例如请求对方检查 hop X 到 Y 的拥塞或 MPLS LSP 状态），并附上 MTR 报告。

7.

临时应急方案：快速降低业务影响的可行手段

- 切换出口或机房：将流量临时走备用出口或备用云区域（BGP 切换/流量工程）。 - 改用其他承载链路：如果具备多运营商，立即把受影响目标的流量 Reroute 到非 CN2 链路，或临时使用第三方 CDN/加速。 - 调整应用层策略：降速、限制并发、增加重试与熔断，把长连接迁移到低延迟路径。 - 临时黑洞与清洗：如为 DDoS 导致延迟，协调清洗厂商或上游做清洗，同时最小化对正常流量的影响。

8.

长期优化与恢复验证：根因确认与防复发措施

- 跟踪问题直至闭环：拿到上游答复后核对修复时间点，复测 traceroute/mtr、业务响应，确保 RTT 恢复到基线。 - 建立自动化检测：配置针对关键目标的主动监测（mtr/traceroute 日志化），并在 hop 延迟或丢包超过阈值时告警并保存 pcap。 - 调整 BGP 策略与流量工程：根据上游路径质量，设置本地优先级、prepends 或利用社区让 CN2/非 CN2 路径分流。 - 编写事后报告：包含事件时间线、证据（traceroute、pcap）、根因、采取措施、改进项（如扩容、增加对等、调整 QoS）。

9.

问：如何快速判断是 CN2 专线本身拥塞还是上游互联点问题？

- 做法：从多个不同源（本机房、另一机房、云上测试点）对同一目标做 traceroute/mtr，比较跳点差异。若所有源在同一上游 hop（属于 CN2 或某个交换点）后延迟上升，倾向于上游/交换点问题；若只有本侧出口出现，则可能是本地链路或PE故障。

10.

答：如果 traceroute 显示第 N 跳开始延迟突增，应如何向上游提交故障信息？

- 模板：事件时间(UTC)、源IP、目标IP、完整 mtr/traceroute（txt）、第N跳 IP 与 AS、丢包/延迟统计、抓包（pcap.gz）、本地路由/接口日志、期望对方检查的项（如 MPLS LSP、接口错误、队列饱和）。请附时间戳并标注可复现窗口。

11.

问：临时绕行 CN2 的风险与注意事项有哪些？

- 风险点：绕行可能增加延迟或抖动、影响带宽计费、触发路径 MTU/MSS 问题、改变源 NAT 或安全策略。应先在非生产流量做流量分流测试，确认路由/ACL/防火墙策略和证书/会话保持等对业务无破坏。

12.

答：排查结束后如何做复盘以降低类似事件发生概率？

- 建议复盘内容：事件摘要、根因证据、修复步骤、影响范围、SLA 偏差、缺陷列表（需要改进的点）、预防措施（监控阈值、冗余设计、BGP 策略、SOP更新），并把抓到的样本数据与上游确认记录归档。

13.

问：没有公网路由器权限时我能做哪些有限的排查和应急？

- 可做项：从服务器端进行 ping/traceroute、抓包、检查应用重试与超时策略、临时切换到备用域名/IP、联系托管/云提供商提供路由层日志与 traceroute。把抓到的证据格式化后上报给有权限方。

14.

答：联系上游时如何提高响应速度与定位效率？

- 提示：提供精简而完整的证据包（时间序列 + traceroute/mtr + pcap + BGP show），标明影响等级与业务SLA，给出可复现时间窗口并请求在该窗口内进行流量镜像或接口统计；对关键客户建议同时电话与邮件并抄送 SLA 支持窗口。

来源：运维经验美国cn2线路延迟突增的排查步骤与应急方案