香港机房的一个客户说他新买的“CN2 GIA”香港服务器，白天测速“飞起”，一到晚高峰（20:00—23:00）就从 500 Mbps 跌到 30 Mbps，还丢包。销售拍着胸脯保证是“纯 GIA 线路”，可我从北京电信拨回去一跑 mtr，一路 59.43.* 后面居然接了 202.97.*——这不就露馅了么？当夜我连上带外 BMC，把机器和交换机端口参数一项项排查，又搭了几台内地云主机做对向探针，跑了一夜的数据，第二天一早拿着表格和 traceroute 截图跟对方 NOC（Network Operations Center）当面摊牌：你这不是纯 GIA，是 CN2 GT + 163 混线。后续怎么解决、怎么维权，下面慢慢说。

1. 场景与测试环境（尽量可复现）

机房与设备

位置：香港葵涌某 Tier III 机房，机柜两相冗余供电，冷通道封闭。

服务器（被测）：

• 型号：Supermicro 1U
• CPU：Intel Xeon Silver 4314（16C/32T）
• 内存：128 GB DDR4-3200
• 网卡：Intel X710 10 GbE（直连上联交换机，单链路）
• 系统：CentOS 7.9（符合你之前的环境偏好），ELRepo kernel-ml 5.4（为启用 BBR）

交换机：Arista 7050 系列（上联运营商边界）

对端探针（内地）

• 北京电信（AS4134/AS4809）
• 上海联通（AS4837/AS9929）
• 广州移动（AS9808）

工具版本

• mtr 0.94、traceroute 2.1.0、iperf3 3.12、tcpdump 4.99、smokeping 2.7

测试时间段

• 日间：10:00–12:00（相对空闲）
• 晚高峰：20:00–23:00（最容易露出真相）

注：为了避免“本机瓶颈”干扰，我在香港服务器上关闭多余服务，CPU 干扰 <10%，磁盘 IO 可忽略；ethtool -k 里保留 GRO/LRO 默认（只做路由与转发不建议开，单机下载可保留），MTU 1500。

2. 背景要点：CN2、GIA、163、9929 到底谁是谁？

CN2 通常指中国电信的下一代网络（AS4809）。其中：

• CN2 GIA（Global Internet Access）：端到端走 CN2，跨境与国内段一致，高价、低拥塞、少跳数，晚高峰稳定。
• CN2 GT：国际段 CN2，但国内段切回 163 骨干（AS4134，IP 常见 202.97.*），晚上容易拥塞。

163 骨干（AS4134）：电信传统骨干，容量大但晚高峰常拥塞。

联通 9929（AS9929）：联通精品网，常被一些商家“张冠李戴”宣传成 CN2/GIA，本质不同。

联通 4837、移动 9808：常规骨干，表现视地区和时段而定。

经验法则（不是 100% 但非常有用）

• traceroute/mtr 路由中出现大量 59.43.* 路由器，多为 CN2 路由器；
• 如果后续又出现 202.97.*（电信 163 骨干），大概率是 CN2 GT/混线 而非纯 GIA；
• 纯 GIA 典型特征：跳数少、RTT 抖动小、晚高峰吞吐稳定，且全程几乎不触达 202.97.*。

3. 一眼辨别（肉眼版）：我平时先看这 4 件事

mtr/traceroute 里是否全程 59.43 段且不进 202.97

AS Path 是否始终在 AS4809 等 CN2 域内，不“掉回” AS4134

晚高峰 RTT 抖动与丢包（smokeping 看 rrd 图是否“开叉”）

吞吐是否稳定（iperf3 多并发 8–16 流在高峰时段仍能维持 70%+ 的白天水平）

4. 严谨实操流程（可落地执行）

4.1 路由观测

# 从内地三点分别对香港测试 IP 发起
mtr -rwzc 100 <HK_TEST_IP>
traceroute -n -T -p 80 <HK_TEST_IP>   # TCP 80，避免ICMP策略

快速判读要点

样例 A（疑似 GIA）：

... -> 59.43.187.1 -> 59.43.80.13 -> 59.43.246.66 -> <HK POP> -> <HK_TEST_IP>

全程 59.43.*，跳数 8–12，RTT 稳。

样例 B（疑似 GT/混线）：

... -> 59.43.2.45 -> 59.43.246.66 -> 202.97.53.97 -> 202.97.90.58 -> <HK_TEST_IP>

中后段出现 202.97.*，晚高峰更明显。

4.2 连续质量监测

# 香港 -> 内地三点对向 ICMP 延迟观测
smokeping --config=/etc/smokeping/config.d/main
# 或一次性采样
for i in {1..300}; do ping -c1 -W1 <BJ_CT_IP> | ts | tee -a bj_ct_ping.log; sleep 1; done

4.3 吞吐测试（避免 CDN/缓存）

# 香港为 client，内地探针为 server
# 内地探针：
iperf3 -s -p 5201

# 香港 client（分时段跑）
iperf3 -c <BJ_CT_IP> -P 8 -t 60 -p 5201 | tee bj_ct_day.log
iperf3 -c <BJ_CT_IP> -P 8 -t 60 -p 5201 | tee bj_ct_peak.log

4.4 抓包辅助定位
# 观察对端 ASN/TTL/丢包及回程 DSCP
tcpdump -i eth0 -nn host <BJ_CT_IP> and port 5201 -vvv -w iperf_peak.pcap

5. 我那晚采到的“证据表”

5.1 路由与 ASPath（节选）

判读：北京电信这条路由在中后段落入 202.97.*，不满足纯 GIA 的“端到端 CN2”特征。

5.2 延迟与抖动（300 次 ICMP 采样）

判读：电信高峰期“开叉”明显，典型 163 拥塞特征；纯 GIA 正常应不至于抖这么大。

5.3 吞吐（iperf3 并发 8 流）

判读：纯 GIA 在 500 Mbps 业务下，晚高峰通常也能稳在 350–450 Mbps（具体看带宽承诺与拥塞），很少“断崖式”跌到 100 Mbps 左右。

6. 半自动“真假判断”脚本（拿去就能用）

6.1 一键采集（Bash）

#!/usr/bin/env bash
# run_probe.sh  内地探针端执行
TARGET=${1:-<HK_TEST_IP>}
TIME=$(date +%Y%m%d%H%M)

mkdir -p results/$TIME
mtr -rwzc 50 $TARGET > results/$TIME/mtr.txt
traceroute -n -T -p 80 $TARGET > results/$TIME/tcp_tr.txt
for i in {1..300}; do ping -c1 -W1 $TARGET | sed -n '2p' >> results/$TIME/ping.txt; sleep 1; done
iperf3 -c $TARGET -P 8 -t 60 > results/$TIME/iperf.txt
echo "done: results/$TIME"

6.2 路由判读（Python）

#!/usr/bin/env python3
import re, sys, pathlib, json
p = pathlib.Path(sys.argv[1])  # 传 mtr 或 traceroute 文件
txt = p.read_text()

is_cn2 = bool(re.search(r'\b59\.43\.\d+\.\d+\b', txt))
has_163 = bool(re.search(r'\b202\.97\.\d+\.\d+\b', txt))
as4809 = bool(re.search(r'AS4809|China Telecom Next Generation', txt))
as4134 = bool(re.search(r'AS4134|CHINANET', txt))

result = {"CN2_hint": is_cn2, "AS4809": as4809, "163_hint": has_163, "AS4134": as4134}

if is_cn2 and not has_163:
    result["guess"] = "Likely_GIA"
elif is_cn2 and has_163:
    result["guess"] = "Likely_GT_or_Mix"
else:
    result["guess"] = "Non_CN2_or_Unknown"

print(json.dumps(result, ensure_ascii=False, indent=2))

说明：不是权威鉴定书，但足以筛出 80% 的“假 GIA / 混线”场景；剩下 20% 需要结合高峰期性能与运营商侧证明材料（如 BGP 社区/承诺路由策略）。

7. 为了不“冤枉”线路：把本机调优先做了

避免把服务器自身瓶颈误当网络问题：

(1) 开 BBR（CentOS 7 + kernel-ml）

# 安装新内核（ELRepo）
yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install -y kernel-ml
grub2-set-default 0 && reboot

# 重启后
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -p

(2) TCP 缓冲与 FD

cat >> /etc/sysctl.d/99-tcp.conf <<'EOF'
net.core.rmem_max=67108864
net.core.wmem_max=67108864
net.ipv4.tcp_rmem=4096 87380 33554432
net.ipv4.tcp_wmem=4096 65536 33554432
EOF
sysctl --system

ulimit -n 1048576

(3) 网卡/交换机

ethtool eth0            # 确认 Speed: 10000Mb/s, Link detected: yes
ethtool -g eth0         # ring buffer 适当调大

只有在确认本机无瓶颈后，再去判网络真假，才有说服力。

8. 常见“坑”与我当场的处理

“只保回程 GIA，去程随缘”

坑点：销售口中的“GIA”只指回程（香港→内地）；**去程（内地→香港）**走 163/其它。

处理：要求对方提供双向路由承诺与测试 IP。用双向 mtr 验证，保留截图与时间戳。

“部分省份走 GIA，其他省份走普通线”

坑点：PBR/策略路由只对“热点省份”走 CN2，其它扔给便宜线路。

处理：采多地探针。至少电信北/上/广三点；晚上 20:00 后再测一轮。

“白天像 GIA，晚上像 163”

坑点：白天带宽足够，看起来像 GIA；晚高峰拥塞后露馅。

处理：把测试分时段做成日间+高峰固定动作，并设置 smokeping 长期曲线。

“联通 9929 被营销成 GIA”

处理：看 AS（AS9929≠AS4809），让对方给出AS Path 与 BGP 社区说明。嘴上说不算。

“IP 段障眼法”

坑点：给你一个“好看的”测试 IP，实际业务切到其他段。

处理：要求与业务同网段的测试 IP；或上线后立刻抽样对客户真实业务 IP 做路由留痕。

“带宽承诺语焉不详”

坑点：写“500M 峰值”，不写保底/争用比。

处理：合同写清：保底带宽、争用比、时段 SLA、丢包/抖动阈值，并附测试方法。

9. 现场“对线”清单：我给对方 NOC 的 6 项证据

• traceroute/mtr：出现 59.43.* 后转入 202.97.* 的完整截图（含时间戳）。
• AS Path：抓三个时段的 ASPath，对比是否始终停留在 AS4809。
• smokeping 曲线：高峰期“开叉”示意（P95 上扬、loss 增加）。
• iperf3 报告：日间与高峰平均吞吐对比表（保证相同并发）。
• pcap 抓包：证明流量确实走了目标端口与对端，排除本地 QoS 影响。
• 合同条款草案：把“GIA 端到端”“带宽保底”“指标阈值”写进附录。

10. “真假 GIA”量化判定表（我的常用阈值，供参考）

结论规则（实务）：满足任意 2 项强指示或1 强 + 2 中强，基本可判“非纯 GIA”。记得保留证据链。

11. 采购与SLA建议（踩坑后总结）

必须要：同网段测试 IP、双向路由证明、高峰期样本。

写进合同：

• “端到端 CN2 GIA（AS4809），不得在国内段落入 AS4134/202.97.*”
• “带宽保底 X Mbps；丢包 ≤0.5%；P95 抖动 ≤12 ms（20:00–23:00）”
• 违约条款：连续 N 天不达标，退费/补偿。
• 运营阶段：部署 smokeping + iperf3 的周报，成为常规巡检。

12. 尾声：冷气口边的和解

第二天我拎着打印好的三张图表去找对方 NOC。对方工程师看完沉默了半分钟，说：“你这个证据链，没法反驳。” 下午他们把路由策略改回全程 AS4809，我当场重测，高峰吞吐回到 420 Mbps、抖动降到 10 ms。客户说：“总算不用跟老板解释了。” 我把空杯子扔进回收桶，心想：辨真伪不是靠嘴，是靠可复现的数据与过程。这篇笔记，也送给像我们一样在机房冷风口写脚本、用数据说话的人。