1. 首先确认故障范围:单台服务器、某一机房(台湾)还是全部CN2线路。收集时间点和影响的IP/域名。检查用户反馈(丢包、延迟、无法访问、端口不可达)。记录发生时间、持续时间、影响量级与变更历史(如配置更新、内核升级、BGP调优)。
2. 在服务器上执行基本检查:查看负载与进程(top、htop),网络接口状态(ip addr show / ifconfig),路由表(ip route show),防火墙规则(iptables -S 或 nft list ruleset),端口监听(ss -tunlp / netstat -tunlp)。若服务异常,先重启对应服务并观察日志(systemctl restart ... && journalctl -u ... -n 200)。
3. 用 ping 测试目标(如客户IP或外部节点):ping -c 10 目标IP,注意丢包率与延迟波动。使用 traceroute/tracert(Linux: traceroute -n 目标IP;Windows: tracert)或 mtr(mtr -rwzbc100 目标IP)连续观测跳数与丢包点,定位是否在机房出口或运营商网络出现问题。记录时间戳和结果保存为文件。
4. 若 ICMP 被限速,使用 TCP Traceroute(tcptraceroute 或 nmap --traceroute)到服务端口来判定TCP路径问题。MTR(mtr)可长期运行观察抖动。示例:mtr -r -c 1000 -w 目标IP > mtr_result.txt。检查连续丢包的跳点,若丢包从台湾出口开始,倾向运营商链路问题。
5. 在服务器上抓包定位问题(需注意流量与磁盘)。示例:tcpdump -i eth0 host 目标IP and port 80 -s 0 -w /tmp/capture.pcap。抓取客户端到服务端的SYN/ACK交互,观察是否有重传、RST或MSS/MTU异常(PMTU 黑洞)。将 pcap 文件下载并用 Wireshark 分析,或用 tcpdump -r 简易查看。
6. 若怀疑 MTU 问题,测试不同大小的 ping:ping -M do -s 1472 目标IP(Linux)逐步降低直到不分片。检查网卡、隧道或VPN是否有小 MTU(如 GRE/VxLAN)。必要时在服务器侧调整 MTU 或在应用层开启 TCP MSS 修剪(iptables --clamp-mss-to-pmtu -t mangle -A FORWARD)。
7. 若使用BGP,检查BGP会话状态(show ip bgp summary / vtysh 等)。确认路由是否被黑洞或被更优路径覆盖。查看路由前缀是否被正确传播,是否有被社区(community)改写。若对方运营商(中国电信 CN2)出问题,准备 BGP 路由回退或宣布更高优先级路由。
8. 登录机房管理面板或运营商状态页查看是否有公告(如海缆维护、CN2节点故障)。若无公告,直接联系大陆/台湾上游(提供商 NOC),提交工单并附上故障时间、MTR/traceroute 输出、tcpdump、服务器日志与影响范围。
9. 提交工单时提供清晰信息:影响时间(UTC/本地)、受影响IP、MTR/traceroute 输出、tcpdump pcap、服务器接口信息(ethtool 输出)、路由表、BGP邻居状态。示例工单段落:”影响IP x.x.x.x 时间:2026-05-16 08:00-08:15 UTC;现象:外网到x.x.x.x 丢包 40% 且延迟突增;已抓包与 mtr 附件,请协助核查 CN2 台湾出口。”
10. 若上游修复需时,可采取应急绕路:启用备用链路或VPN(走其他ISP或海外节点);在DNS层面临时将流量导向备用机房(低TTL备份记录);在BGP层面宣布更优路径(如果可控)以避开故障链路;或使用CDN/加速服务(如按需开启静态内容分发)。务必在变更前通知相关方并记录回滚步骤。
11. 故障恢复后,回溯分析:查看服务日志(/var/log/*)、系统日志(dmesg、kernel log)、监控指标(CPU、内存、netstat -s、ifconfig/rx/tx errors、SNMP counters)。比对故障前后配置变更(运维变更单)以确认是否人为改动导致。归档所有证据供后续RCA。
12. 为减少未来影响:建立自动化监控(MTR定期采样、ICMP/TCP可用性监控)、多链路冗余、低TTL DNS Failover、实现BGP多出口策略和健康检查(BFD/keepalive)、自动抓包触发与报警联动。与CN2供应商签订SLA并确认故障响应流程与联络窗口。
13. 快速检查清单:1) 确认是否是本机服务或端口问题;2) ping/traceroute 定位丢包跳点;3) 抓包看是否有SYN/ACK丢失或重传;4) 检查MTU/PMTU;5) 验证防火墙/安全组规则;6) 查看上游公告并开工单。
14. 答:出现“某跳丢包高但下一跳恢复”的情况通常是该跳(通常是运营商的路由器)对ICMP或控制包做了限速或优先级处理,未必影响实际转发。判断依据:查看TCP层的数据包是否实际丢失(通过tcpdump看重传)以及应用层是否受影响。如果应用层正常,可忽略单纯ICMP丢包;若TCP重传明显或用户感知到丢包/延迟,则应联系该跳所属运营商进一步排查。
15. 答:提供完整且结构化的信息可以大幅提高响应速度:故障时间范围、受影响IP、MTR/traceroute 输出(带时间戳)、tcpdump pcap、服务器接口统计(ifconfig/ethtool output)、是否影响全部用户或部分用户、业务影响级别和联系方式。清晰的证据和复现步骤能让NOC快速定位到链路或设备。
16. 答:优先选择低风险、快速可行的绕行方案:启用已存在的备用链路或VPN隧道,将流量引导到非故障的出口;通过DNS临时降低TTL并切换到备用IP;若有BGP控制权,可临时宣布不同的更优路由;另外使用商业加速/CDN服务作为短期替代能迅速缓解用户访问问题。在变更前准备回滚计划并通知相关团队。