AWS VPC QoS 限速实验环境上手：用 FRR 与 Transit Gateway 验证带宽限制配置

在云上做带宽限速，最怕两件事：一是限速没生效却看不出来，二是限速生效了但流量路径和预期不一致。AWS 官方博客给出的 VPC QoS 实验环境正好针对这两个问题：用两台运行 FRR 的虚拟网络设备（VNF）配合 Transit Gateway 和 BGP 路由策略，把业务流量强制牵引到指定 VNF 上，再在 VNF 的 GRE 接口上完成限速。整套环境的核心价值不在限速算法本身，而在于它把“流量走哪条路”和“限速规则是否命中”拆成了可逐段验证的步骤，适合在做生产变更之前先隔离复现。

这篇文章按“版本固定—拓扑准备—FRR/TGW 配置—限速验证—回滚检查”的顺序整理这套模板，重点说明哪些配置细节容易踩坑，以及验证过程中如何确认流量真的经过了你以为的那台设备。

这套环境解决什么问题

VPC 内部默认没有原生的带宽限速能力。常见的做法是把流量引到一台虚拟设备上，由设备上的 tc、HTB 等机制做整形。难点在于：流量如何被可靠地牵引到设备上、设备故障时如何切换、切换后限速规则是否还落在同一条路径上。

实验环境用两台 FRR 设备做一主一备，利用 BGP 的 AS 路径长度控制 Transit Gateway 对默认路由的选路，确保业务流量只走 VNF1；VNF2 只在 VNF1 不可用时接管。这样做的目的不是高可用演示，而是让你在验证限速效果时有一个明确的“当前活跃路径”，避免两台设备同时收到流量导致测量结果对不上。

适用场景是云网络限速方案的预验证、BGP 路由策略的实验，以及限速设备故障切换后的行为确认。它不能直接照搬到生产：实验里的 AS 号、网段、TGW 路由表都是隔离的，生产环境需要重新评估路由传播范围、限速设备本身的吞吐上限，以及跨可用区流量成本。

版本固定与准备条件

这套模板对版本敏感，尤其是 FRR。不同小版本在 BGP 默认路由生成和 route-map 应用顺序上存在差异，直接沿用博客里的配置片段而不锁定版本，很容易出现“配置看起来一样但路由行为不同”的情况。建议在实验记录里明确写下 FRR 版本、Transit Gateway 所在区域、VPC 网段和 AS 号规划，后续复现时才能对照。

准备条件包括：一个可用的 AWS 账户、两台能运行 FRR 的 EC2 实例（分别位于不同子网或可用区）、一个 Transit Gateway、以及业务侧至少一台用于打流的实例。安全组和网络 ACL 需要放行 GRE 流量和 iperf3 测试端口，这一点在 AWS re:Post 的第三方虚拟设备排障文档里也有明确要求：VNF 子网、源实例子网、以及 TGW 弹性网络接口关联的 ACL 都要检查。

一个容易被忽略的前置动作是先把 TGW 创建并确认状态为 available。创建命令返回的 ID 要记下来，后续挂载 VPC、配置路由表都依赖它。挂载完成后再验证关联状态，不要在这一步省略检查。

FRR 与 Transit Gateway配置要点

BGP 会话与默认路由发布

两台 VNF 各自与 TGW 建立 BGP 会话。VNF1 正常发布默认路由，VNF2 也发布默认路由，但通过在 route-map 里加长 AS 路径，让 TGW 认为 VNF1 的路径更短，从而只把流量转发给 VNF1。

关键配置片段如下（以 VNF2 为例，AS 号与邻居地址按实验规划替换）：

route-map TGW-DEFAULT permit 10
 set as-path prepend 65001 65001
!
router bgp 65001
 neighbor 169.254.101.2 remote-as 64512
 neighbor 169.254.101.3 remote-as 64512
 address-family ipv4 unicast
  neighbor 169.254.101.2 default-originate route-map TGW-DEFAULT
  neighbor 169.254.101.3 default-originate route-map TGW-DEFAULT
 exit-address-family

这里有一个必须写进实验笔记的坑：set as-path prepend 必须挂在 default-originate 引用的 route-map 上，而不是挂在出向 route-map 上。博客里提到，他们最初把 prepend 写在出向 route-map TGW-OUT 里，用 debug bgp updates out 看实际发出的 UPDATE，发现默认路由的 AS 路径为空（发送时只带本端 ASN），没有被加长。结果两台 VNF 发布的默认路由 AS 路径相同，TGW 在两者之间做 ECMP，流量同时打到两台设备，限速测量直接失去意义。

路由收敛时间

修改 BGP 配置或重启 FRR 之后，TGW 完成路由切换通常需要 20 到 30 秒。验证前要等路由收敛，不要在改完配置后立刻打流。可以先用 show ip bgp summary 确认会话建立，再在 TGW 侧确认路由表里默认路由的下一跳指向预期的那台 VNF。

流量路径确认

博客给出的验证方法是：在两台 VNF 的 gre1 接口上同时观察流量，业务流量只出现在 VNF1 上、VNF2 上没有，说明 AS 路径较短的 VNF1 是首选。这个检查比只看 BGP 路由表更直接，因为它验证的是实际转发路径，而不是控制面状态。

如果发现两台 VNF 都有流量，优先回头检查 prepend 是否真的作用在默认路由上，而不是去调限速参数。

限速验证步骤

验证分三段：先确认单类流量能跑满链路，再确认两类流量同时到来时按比例分配，最后确认反向流量（Server 到 Client）也经过限速设备。

在 Server 上启动两个 iperf3 服务端，分别对应高优先级和尽力而为两个端口：

iperf3 -s -p 8080 -D
iperf3 -s -p 9090 -D

先测只有尽力而为流量时的表现。在 Client 上执行，-R 表示反向，让 Server 向 Client 发送数据，也就是限速的 Server 到 Client 方向：

iperf3 -c 10.20.0.136 -p 9090 -R -t 15 -O 3 -f m

在博客的实验结果里，这一项大约在 98.7 Mbits/sec，接近链路带宽。再测只有高优先级流量时，同样可以用满链路，约 99.3 到 99.4 Mbits/sec。

然后是关键一步：两种流量同时到来。按博客的配置，带宽按 80/20 分配，高优先级拿到约 80%，尽力而为拿到约 20%。如果这里的结果不符合预期，常见原因不是 tc 规则写错，而是流量根本没有同时经过同一台 VNF，或者两个端口被哈希到了不同路径。回到上一节的 gre1 接口观察，先排除路径问题。

另外注意 iperf3 的 -O 3 参数，它跳过前 3 秒的慢启动阶段，避免把 TCP 预热算进平均值。限速验证对测量窗口敏感，建议固定测试时长和跳过时间，保证多次测量可比。

回滚条件与清理顺序

这套实验涉及 BGP、TGW 挂载、VPC 路由表和安全组，变更前至少要保留四类信息：两台 VNF 的完整 FRR 配置备份、TGW 路由表在变更前的关联与传播状态、业务 VPC 路由表中指向 TGW 的条目、以及安全组和网络 ACL 的原始规则。

回滚顺序建议反过来走：先恢复 VNF2 的 AS 路径配置（或直接停掉 VNF2 的 BGP 会话），确认 TGW 默认路由回到 VNF1；再撤销业务 VPC 路由表中为实验新增的条目；最后清理 TGW 挂载和测试实例。不要先删 TGW 挂载再改路由，否则中间会出现一段业务流量没有下一跳的窗口。

如果实验环境是临时搭建的，清理时按 AWS 官方 CLI 教程的步骤删除 TGW 挂载和 TGW 本身，同时确认没有残留的 VPC 路由指向已删除的 TGW，避免后续建同网段环境时出现路由冲突。

从实验到生产之间还差什么

博客里的配置是实验模板，不是生产方案。搬到生产前至少需要补充三件事：限速设备自身的吞吐和并发连接上限评估，因为 BGP 选路只解决流量走向，不解决设备成为瓶颈的问题；跨可用区或跨 VPC 的流量成本核算，流量被牵引到 VNF 后可能产生额外的数据传输费用；以及监控告警，实验里靠人工在 gre1 上观察流量，生产环境需要把接口速率、BGP 会话状态和路由切换事件接入可观测体系，否则主备切换发生时没人知道。

更稳妥的做法是先在隔离的 VPC 里完整跑一遍这套流程，把 FRR 版本、AS 号、网段、iperf3 测量参数和回滚命令写成可重复执行的记录，再评估是否具备进入预生产环境验证的条件。限速配置的可信度，来自路径、规则和回滚三件事都能被独立验证，而不是来自某一组漂亮的 iperf3 数字。