BGP AS路径预挂如何影响选路

前几天我在云上复现一个带宽限速实验，原本以为难点在限速规则本身，结果真正让我卡住的，是BGP的AS路径预挂有没有挂对地方。那种感觉很像你明明把门锁换了，回家却发现钥匙开的是邻居家的门。

这套实验里，两台运行FRR的虚拟设备都和Transit Gateway建BGP会话。VNF1正常发布默认路由，VNF2也发布默认路由，但在route-map里给AS路径加长，让TGW认为VNF1的路径更短，从而只把流量交给VNF1。听起来很直白：谁的路更长，谁就往后站。

坑就藏在“加在哪里”。我一开始把set as-path prepend挂在出向route-map上，配置看着没毛病，可实际发出的默认路由AS路径并没有被加长。后来用debug bgp updates out看UPDATE才发现，发送时只带了本端ASN，预挂根本没作用到那条默认路由上。结果两台VNF发布的路径长度一样，TGW直接做ECMP，流量同时打到两台设备，限速测量当场失去意义。

正确的做法，是把预挂挂在default-originate引用的route-map上。这个细节如果不写进实验笔记，下次复现时很容易再栽一次。因为问题不在限速参数，而在控制面已经把流量分给了两条路。

改完配置也别急着打流。修改BGP配置或重启FRR之后，TGW完成路由切换通常要等20到30秒。可以先用show ip bgp summary确认会话建立，再去TGW侧看默认路由下一跳是不是指向预期的那台VNF。真正让我放心的验证方式，是在两台VNF的gre1接口上同时观察流量：业务流量只出现在VNF1上，VNF2上没有，才说明AS路径预挂确实影响了实际转发路径。只看BGP路由表不够，因为控制面看起来对了，转发面未必跟你想的一样。

如果发现两台VNF都有流量，我会先回头查预挂是否真的作用在默认路由上，而不是急着调tc规则。这个顺序能省掉很多无效排查。AS路径预挂不是简单加一串数字，它改变的是TGW对路径长短的判断，最终必须落到接口流量上验证。我现在会把FRR版本、route-map挂载位置、收敛等待时间和接口观察结果一起记下来，这样下次再看到“路径明明更长却还在转发”，就知道该往哪儿看了。