混合云流量出口的“出路之困”
故障定位思路
折腾BGP Community时，我发现最麻烦的往往不是安装，而是配置。当企业同时使用阿里云、AWS以及自建IDC时，网络拓扑变得相当复杂。通常我们会通过专线将各个站点连通，形成一个混合云网络。然而，一旦需要访问互联网（比如员工办公、API调用、数据同步），就面临一个实际问题：流量到底从哪个出口出去？
默认情况下，路由器可能选择最直接的路由，或者采用等价负载均衡。这会导致：
- 成本失控：不同云厂商的互联网出口带宽单价不同，默认走最贵线路造成浪费；
- 延迟不可控：某些业务要求低延迟，却走了跨区域绕行；
- 安全合规难满足：审计要求流量必须经过特定出口（例如政府规定某些数据必须从本地IDC出口）。
传统方法要么手工写大量静态路由，要么依靠策略路由（PBR）逐条配置，维护成本极高，且不适应动态变化。这时，BGP（边界网关协议）内置的Community属性就提供了一个优雅的解决方案。
先理解BGP和Community：好比快递单上的备注与BGP Community
BGP是什么？
BGP是互联网的“邮政系统”，负责在不同自治系统（AS）之间交换路由信息。简单说，当你的路由器通过BGP从云厂商学到一条路由（比如0.0.0.0/0默认路由），它就知道了“通过这个邻居可以到达互联网”。
Community又是什么？
BGP Community是一个可选的传递属性，相当于贴在路由“信封”上的一个标签。标准格式是ASN:Value，比如65001:100。路由器可以读取这个标签，然后根据预设规则决定如何处理这条路由。换句话说：Community让路由带上了身份信息。
举个例子：阿里云专线发给你的默认路由，可以贴上Community标签65001:80，表示“这条路由的出口优先级是80”。你的路由器收到后，如果配置了规则“当Community为65001:80时，设置本地优先级（Local Preference）为200”，那么这条路由就会比没有标签的默认路由更优先被选中。
补充参考：此处可内链到“BGP Community故障排查实例”。
跨云专线场景：标签如何指挥流量走向？
实际操作要点
假设你的混合云包含三部分：
- 本地IDC（AS 65001）
- 阿里云通过专线连接IDC，并通告默认路由
- AWS也通过专线连接IDC，也通告默认路由
从IDC访问互联网，你有两个出口：一条走阿里云专线再转公网，一条走AWS专线再转公网。你想让大部分业务流量走阿里云（因为带宽包月便宜），但要求视频会议流量必须走AWS（因为AWS出口到特定地区的延迟更低）。
传统方法是：在IDC出口路由器上配置策略路由，根据源IP或目标端口指定下一跳。但策略路由无法与BGP动态路由联动——当专线故障时，需要手动切换。
BGP Community方案是这样工作的：
- 在阿里云侧：向IDC通告默认路由时，附加Community
65001:10（表示阿里云出口优先级为10，数字越小越优先）。 - 在AWS侧：通告默认路由时，附加Community
65001:20（优先级20）。 - 在IDC路由器上：配置入站路由策略——“如果收到Community为65001:10的默认路由，则设置Local Preference为300；如果Community为65001:20，则设置Local Preference为200”。
- 结果：阿里云的默认路由优先使用（Local Preference高），除非阿里云专线中断，该路由撤销，AWS的路由自动切换为主用。
同时，针对视频会议流量，你可以在IDC路由器上增加一条策略：针对来自视频会议段的数据包，将下一跳强制指向AWS的专线接口（或者通过PBR结合路由标签）。但更高级的做法是：让视频会议服务器使用特定的下一跳IP，或者通过NAT策略配合。
进阶玩法：用Community实现“出口分组”与“流量染色”
我的处理经验
Community不光能调优先级，还能作为“过滤器”。当你有多条专线时，可以将不同云服务的路由按功能分组：
- 普通业务路由：Community =
65001:100，走普通出口 - 合规业务路由：Community =
65001:200，必须走本地IDC的物理出口 - 备份路由：Community =
65001:999，仅在主出口全故障时使用
你的核心路由器只需要做好一件事：根据Community匹配规则修改Local Preference或下一跳。这样，所有动态路由变更都不需要人工干预。
这个思路在云厂商的专线网关中也得到支持。例如：在阿里云高速通道中，你可以为直连VPC的路由设置Community，然后通过云企业网（CEN）或边界路由器（VBR）的路由策略来调整最终选路。AWS Direct Connect也允许在虚拟接口上启用BGP Community。
延伸阅读：此处可内链到“BGP Community配置案例”相关文章。
想继续深入：此处可内链到“BGP Community优化清单”文章。
落地配置中的关键点（给想动手的你）——BGP Community
验证与回滚
虽然本篇文章面向概念科普，但简单提一下实际配置中的注意事项：
- Community值需要双方商定：你和云厂商专线团队必须统一ASN和Value含义，避免冲突。通常云厂商会有固定保留值，你需要确认是否可使用自定义Community。
- 避免路由环路：小心不要将带有重要Community的路由再通告给其他邻居，导致回路。可以在出站策略中过滤不需要的Community。
- 收敛时间：BGP本身收敛较快（秒级），但如果你使用了复杂的策略路由配合，可能增加处理延迟。建议先用模拟环境验证。
- 备选方案：AS Path Prepending：如果不支持Community，也可以通过人为延长AS路径长度来实现优先级调整。但Community更精细。
进阶阅读：此处可内链到“BGP Community性能优化”指南。
总结：Community是混合云出口调度的一把钥匙
先看关键判断
混合云网络最头疼的不是布线，而是流量控制权。BGP Community提供了一种标准、动态、可扩展的机制，让运维人员告别手工路由表，像给快递贴标签一样轻松指定每条路由的“去向”。尽管它需要一定的BGP基础，但一旦掌握，就能以声明式的方式管理多出口流量，降低故障响应时间，并有效控制云上带宽成本。
下次当你面对多个专线出口不知道该优先使用哪个时，不妨想想Community：给它贴个标签，一切就清晰了。后续只要定期检查关键指标，BGP Community就不会变成维护负担。
延伸阅读