1.

准备与资料收集

操作概述与必备；a) 确认目标机房名称与提供商（例如 SKT/KT/LG U+ 及第三方CN2层）；b) 准备工具：ping/traceroute/mtr/whois、浏览器访问 Looking Glass、PeeringDB、bgp.he.net；c) 获取目标 IP 段、机房对外出口 IP 或 ASN（向销售或客服索要）。

2.

使用 Looking Glass 获取骨干互联视角

具体步骤；a) 在浏览器搜索“[运营商名] Looking Glass”并访问；b) 在 LG 页面输入目标出口 IP 或 ASN，分别运行 ping、traceroute、BGP routes 查询；c) 记录到达国内/国际出口的 AS 路径、所走 IX（例如 KINX、IX.KR）和中间节点 RTT；d) 保存截图与文本以便比对不同 LG 的结果。

3.

用 traceroute/MTR 验证实际路径与延迟

命令与判断；a) 本地/服务器上执行 mtr -rwzbc 100 目标IP（Linux）或使用 WinMTR（Windows）；b) 观察丢包是否在机房段或中间骨干段发生，若丢包点在国内骨干或 CN2 节点，可能是互联质量问题；c) 用各地 VPS（日本/新加坡/中国电信/联通/移动）重复测试，判断跨网联通稳定性。

4.

核查 BGP 路由与 AS 路径可信性

操作步骤；a) 在 bgp.he.net 或 bgpview.io 输入目标 ASN，查看 peers 列表与上游/下游关系；b) 核对 AS_PATH，判断是否通过“短路由”到达国内主干（CN2 常采用直连国际骨干的策略）；c) 使用 whois 查询 ASN 的注册信息和 IRR 条目，确认运营商是否有清晰的路由策略记录。

5.

查询互联伙伴与商业对等信息（PeeringDB）

如何核对；a) 在 PeeringDB 搜索机房或 ASN，查看其所在 IX、交换端口和是否有公开的对等政策（Open/Selective/Restrictive）；b) 优先选择在多个主要 IX（如 KINX、SG-IX）有交换和直连的机房；c) 若可能，要求供应商出示当前对等伙伴清单或端口利用率报告。

6.

带宽、QoS 与冗余验证

检查要点与测试；a) 要求机房提供骨干链路的带宽承诺、SLA与流量工程（如是否支持 BGP anycast/backup paths）；b) 验证是否有双路由/多上游，使用 traceroute 在不同时间段测试路径是否切换；c) 要求查看 DDoS 防护策略、黑洞机制与流量清洗节点位置。

7.

实际采购前的验证清单

现场核查与远程验证步骤；a) 索要并核对：ASN/IP 列表、对等表、上游列表、SLA 文档；b) 在合同前用临时试用 IP 做 48-72 小时的持续 MTR/iperf 测试并保存日志；c) 比较不同机房的平均延迟、峰值丢包与路径稳定性再决定。

8.

问：如何快速判断一个韩国 CN2 机房是真正走 CN2 骨干？

答：查看 BGP AS_PATH 与 PeeringDB 信息；a) 在 Looking Glass 或 bgp.he.net 查询出口 IP 的 AS_PATH，如果路径中直接经过 CN2 运营商的 ASN（如联通国际/电信国际的 CN2 ASN）且中间跳数较少，说明走的是 CN2 骨干；b) 同时在 PeeringDB 上确认该机房或 ASN 与主要国际 IX 有直连记录；c) 结合 MTR 多点测试，若从中国多线路到该 IP 的延迟一致且丢包低，则基本可判定为 CN2 质量。

9.

问：在没有现场访问权限时，如何做最完整的远程核查？

答：依次使用 Looking Glass、PeeringDB、bgp.he.net 和多区域 MTR；a) 从至少 3 个不同运营商/地区的 VPS 对目标 IP 做 MTR 并比对路由与丢包点；b) 在多个 Looking Glass 上查 BGP routes 与 traceroute，确认上游 ASN 一致性；c) 要求供应商提供试用 IP 与临时带宽，进行 48-72 小时的持续性能监测。

10.

问：发现骨干路径有丢包或绕路，后续应如何与机房/供应商沟通？

答：提供证据与明确需求并要求整改措施；a) 将 MTR/traceroute 的文本输出、时间戳和测试节点列表整理成附件发给供应商；b) 指出问题发生的具体跳点（IP/ASN）并要求运营商与对应上游或 IX 联络排查；c) 若对方无法改善，可要求更换出口/调整 BGP 策略或考虑其他机房。

来源：选择强的韩国cn2机房时必须核查的网络互联与骨干信息