用BGP community给路由打标签,再通过路由策略匹配标签批量改写Local-Pref、MED或AS路径,就能把多线BGP选路从“逐条改”变成“按组调”,这是当前性价比最高的优化方式。
BGP社区属性到底是什么:路由身上的一张便利贴
BGP community可以理解成路由前缀的一张便利贴,它本身不改变路由走向,只是给一组前缀做标记,真正生效的是后面路由策略里的匹配动作。
- 标准社区属性有NO_EXPORT、NO_ADVERTISE、LOCAL_AS等,用来快速控制路由通告范围。
- 自定义社区通常写成
AS号:数值,比如65001:100,含义完全由网络管理员定义。 - 一个前缀可以同时携带多个community,方便叠加不同维度的分类。
如果不使用community,运维人员只能逐条前缀写策略,前缀数量一旦上来,维护成本非常高,社区属性让策略从“逐条硬写”变成“按标签批量处理”。
BGP community属性配置实例:先打标签再下策略
第一步:规划标签,别想到哪打到哪
标签规划是实操中最容易跳过的环节,但后期返工基本都出在这里,建议先用表格把业务意图固定下来。
| Community标签 | 业务含义 |
|---|---|
| 65001:100 | 来自电信线路的路由 |
| 65001:200 | 来自联通线路的路由 |
| 65001:300 | 国际出口路由 |
| 65001:900 | 视频会议等高优先级业务 |
标签一旦确定,就不要随意变更,后续策略全部引用这些标签,改动作时只动策略,不碰前缀列表。
第二步:入口路由打标签
以华为VRP设备为例,先定义前缀列表匹配电信网段:
ip ip-prefix TELECOM permit 202.10.0.0 16 greater-equal 16 less-equal 24
再创建route-policy给匹配到的路由追加community:
route-policy SET_TELECOM permit node 10 if-match ip-prefix TELECOM apply community 65001:100 additive
关键词是additive,不加这个参数,原有community会被覆盖,后续多个维度的分类就会丢失。
第三步:出口策略调用community
在Cisco IOS上,先定义community-list精确匹配电信标签:
ip community-list expanded FROM_TELECOM permit 65001:100
然后创建route-map调用该community-list,并设置本地优先级:
route-map FROM_TELECOM permit 10
match community FROM_TELECOM
set local-preference 200
最后在BGP邻居入方向调用:
neighbor 203.0.113.1 route-map FROM_TELECOM in
这样所有携带65001:100标签的路由都会自动获得更高的本地优先级,不用逐条前缀去写。
多线BGP机房如何优化路由:出站和入站分开管
出站方向:本地路由器说了算
出站流量由本地AS的BGP决策过程控制,Local-Pref越高越优先,这个属性只在本AS内有效,运维人员完全可以自主决定流量从电信还是联通出去。
实际操作时,可以在入口策略中直接给不同线路的路由设置不同Local-Pref。
- 电信线路路由:Local-Pref 200
- 联通线路路由:Local-Pref 150
- 国际出口路由:Local-Pref 100
这样正常情况下优先走电信,电信故障路由消失后,联通路由自动进入路由表,不需要人工切换。
入站方向:需要上游配合
入站流量由对端AS决策,本地无法直接控制,常用手段是向不同上游发送不同community,由上游根据约定执行AS Path Prepend或MED调整。
比如告诉电信:收到65001:200标签的路由时,请增加一个AS号,让联通方向看起来更短,这就是利用community协调多方的典型场景。
在北京多线BGP机房托管时,如果只是把电信、联通、移动线路拉进机房,不配community选路,流量经常绕路,延迟增加,这也是为什么相当一部分企业双线BGP接入价格不低,但实际体验并不好。
BGP本地优先级和MED对比:标签让它们各司其职
Local-Pref与MED的核心区别
| 对比项 | Local-Pref | MED |
|---|---|---|
| 作用范围 | 仅本AS内部 | 传递给外部邻居 |
| 控制方向 | 出站流量 | 入站流量 |
| 数值含义 | 越大越优先 | 越小越优先 |
| 是否强制对端遵守 | 完全自主 | 对端不一定采信 |
community如何减少策略维护量
传统做法是直接对前缀列表设置Local-Pref和MED,但前缀列表经常变化,一旦增加新网段,多条策略都要同步更新。
用community之后,新增网段只需在入口打一次标签,后续所有Local-Pref、MED策略都基于标签匹配,不用再动,批量调整时,比如把全部联通线路降级,只需要改一条匹配65001:200的route-policy。
企业双线BGP接入价格不低,规划不当等于多线变单线
很多企业采购了双线BGP带宽,但路由器只运行默认BGP,没有做任何选路策略,结果所有出站流量全部命中BGP默认最优路径,另一条线路长期闲置,双线接入的钱花出去了,实际只用了单线。
行业共识认为,无规划的BGP双线接入多数情况下只有一条主线路在承载流量,要避免这种浪费,至少要做两件事:
- 给从不同运营商收到的路由打上不同community标签。
- 按业务优先级设置Local-Pref,让视频会议走低延迟线路,大流量下载走成本更低的线路。
具体操作路径:
- 登录出口路由器,进入BGP进程。
- 在邻居入方向调用打标签的route-policy。
- 创建匹配community的route-policy设置Local-Pref。
- 将选路策略应用到全局或指定邻居。
- 保存配置并观察路由表与流量统计。
这套操作不依赖高端设备,多数企业级路由器都支持,关键是前期标签规划清楚,后期维护成本才会低。
容易踩的坑:additive、传递和匹配顺序
additive别漏:不加会覆盖已有community
如果一条路由已经携带了65001:100,后续策略又执行apply community 65001:200,没有additive时,原来的65001:100会被直接覆盖,多个维度的分类就会丢失,后面依赖旧标签的策略全部失效。
发给EBGP邻居时要允许发送community
部分设备默认不向EBGP邻居发送community属性,思科设备需要在BGP配置中显式执行neighbor x.x.x.x send-community,否则对端收不到自定义标签,入站控制策略无法生效,华为设备也要检查路由策略是否应用到了EBGP邻居方向。
community-filter匹配顺序
多条community-list匹配时,设备按序号依次判断,精确匹配要放在前面,宽泛匹配放后面,如果先写了放通所有流量,后面的策略根本不会被执行。
BGP社区属性优化路由选路常见问题
BGP community属性配置后为什么不生效?
最常见原因是属性被覆盖,或邻居未开启community发送能力,检查apply community或set community是否带additive参数,同时确认BGP邻居是否配置了send-community,另一类原因是route-policy没有在BGP邻居方向调用,策略写得再好也不会执行。
BGP本地优先级和MED对比,做多线选路先用哪个?
控制出站流量先调Local-Pref,因为本AS完全可控,控制入站流量再考虑MED,但上游不一定采信,实际项目中可以先给路由打community,再按标签批量调Local-Pref,观察流量后再决定是否向对端发送MED。
多线BGP机房如何用community实现自动故障切换?
给每条线路的路由打上不同community,出口策略匹配主线路community设置高Local-Pref,备用线路默认低优先级,主线路故障路由消失后,备用线路路由自动进入路由表,这就是用community分组替代逐条跟踪前缀的切换方式。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/643327.html





