摘要

  • NANOG 98 的演讲讲述了一次 TCP 服务迁移：端口逐个搬到云端，旧站点继续发布原来的服务 IP。
  • 演讲者称，3,000 个端口在六个月内完成迁移；应用问题导致两次回退，交易没有损失。RFC 8955 没有标准化幻灯片中的 redirect-nh。

服务地址写在客户端里，迁移时改不了 IP。DNS 也帮不上忙。NANOG 98 上，基础设施架构师 Hervé Hildenbrand 介绍了这项服务：客户端使用固定 IP，直接跑 TCP。团队无法加一个应用不接受的代理，也不能批量更新客户端固件。

一次搬走整个 /32，就要同时移动三千多个 TCP 端口。让两个站点同时发布同一个前缀，又可能打断正在进行的连接。团队得分批迁移，同时让客户端继续看到原来的地址。

演讲材料展示了做法。普通流量留在旧站点。FlowSpec 只把选定的目的地址、协议和端口组合送往新云的 Anycast 锚点；站点之间通过 MPLS 连接。一个端口准备好，就先迁移它。其他端口不动。

全部端口迁完后，团队从新边缘发布 /32，撤销旧边缘的发布，再删除临时的 FlowSpec 规则。客户端看到的服务 IP 始终不变。

问题藏在“下一跳”里。FlowSpec 可以用 BGP 分发匹配条件，但这不代表它规定了所有转发动作。RFC 8955列出目的前缀、协议和端口等匹配条件。RFC 也明确规定：FlowSpec NLRI 里的下一跳要忽略。标准重定向动作是按 route target 把流量送进指定 VRF。

而演讲幻灯片展示的是 redirect-nh，把流量送到一个 Anycast 地址。RFC 8955 允许其他动作另行标准化，也允许实现方提供自己的动作。但它没有把幻灯片中的做法变成通用功能。演讲没有说明设备实现，也没有给出 redirect-nh 的线格式编码。

迁移还设置了几道操作控制。规则写在 Git/Terraform 中。CI/CD 检查目的地址、端口范围和获准的下一跳；路由器再用过滤器拒绝未授权目标。这个边界很重要：一条错误规则可能以转发速度影响整段骨干网流量。

演讲者报告，六个月迁移了3,000个 TCP 端口，收敛时间不到一秒，应用问题造成两次回退，没有交易损失。这些是演讲中的案例数据，没有独立审计过的服务日志。图上的 192.0.2.50 属于 RFC 5737 预留的文档示例地址段；10.100.0.254 属于 RFC 1918 私有地址空间。它们不是客户的真实地址。

这次演讲没有证明所有网络都能照搬这个办法。它留下了三项具体工作：逐类设备验证重定向动作，限制谁能批准目标，并实际演练撤销规则。端口能逐个移动，是因为其他流量仍留在原有路径。

来源：NANOG 98 演讲页面；Hervé Hildenbrand 的演讲幻灯片；RFC 8955；RFC 5737；RFC 1918.