在BGP路由优选过程中，community属性不直接参与选路计算，但通过路由策略改写LOCAL_PREF、AS_PATH等权重参数的方式，它能间接决定最终路由走向两者结合的核心要点在于理清作用顺序，避免策略互相覆盖。
搞懂BGP community是什么，才知道它在选路里的真实位置
很多网工配置了community却不知道它到底改了哪个选路参数，根源在于把“属性”和“选路规则”混为一谈，BGP community是一个可选传递属性，本质上是给路由打的一串标签，100:300 表示“这是来自核心区的路由”，它本身不分优先级、不影响Cost值。
community属性与BGP路由优选顺序的关系
业内专家指出，标准BGP决策顺序从weight、LOCAL_PREF一路走到MED、AS_PATH等参数，整个链条上根本没有community的位置，但community可以被Route-Map识别，配合ip community-list或ip community-list expanded使用，进而触发set local-preference、set as-path prepend等动作，可以理解为：community是“门牌”，策略是“开关”，先看到门牌,开关才决定放行还是改路。
属性传递机制对策略生效路径的影响
BGP community的传递范围需要特别留意，它只在IBGP邻居间默认保留，从EBGP学到的路由发给其他EBGP邻居时，默认会剥离community，这在实际组网中很容易踩坑当你打算用community标记上游运营商路由，再传给下游分支时，如果没在EBGP对端配置send-community（新版是send-community both），下游根本看不到标签,策略自然失效。
路由优选与community结合时的冲突点
真正的痛点不在配置语法，而在“多个策略同时命中”时规则打架。
修改LOCAL_PREF与community匹配顺序的矛盾
典型的错误场景是：入方向Route-Map先匹配community，执行set local-preference 200；同一台设备还有另一个Route-Map匹配了AS-PATH，执行set local-preference 100，只要两条策略都被neighbor X route-map Y in挂载,后匹配到的规则会直接覆盖前面的结果。
问题的关键在于BGP策略有先后顺序，community匹配和AS_PATH匹配如果都落到同一个路由上，谁写在后面谁生效，所以配置priority的共识是：
先做community打标，再做基于community的条件选路，两步拆到不同Route-Map里，或者用continue语句接管后续匹配。
过滤场景下的社区属性丢失问题
很多同行喜欢用ip community-list standard 100 permit 100:200配合deny做路由过滤，但忽略了一个事实当你对一个EBGP邻居同时启用了出方向和入方向的策略，出方向策略如果先剥离了community,入方向策略就永远匹配不到目标标签。
更隐蔽的问题是route-policy里的apply community none，有些模板为了清零community属性，会在出方向统一设置none，结果下游收到的路由所有标签都被清空,之前做的所有community标记全部报废。
实操中必须掌握的注意要点
既然理论搞清楚了,落地时请盯紧以下几个动作：
配置community属性时的三个规范动作
一是统一定义社区标签语义，建议在企业内部建立一张“社区标签对照表”，比如100:10代表“骨干出口”、100:20代表“备份出口”，并在所有设备上保持一致,很多故障源于不同设备用同一数字串但语义相反。
二是匹配规则黄金法则用命名型community-list替代数字型，命名型可读性强,能大幅降低后期排障理解成本。
ip community-list standard CORE-ROUTES permit 100:10
route-policy SET-CORE permit node 10
if community matches-any CORE-ROUTES then
set local-preference 300三是严格区分入方向、出方向策略中的community意图，入方向策略里一般是“根据收到的community做选路决策”，出方向策略里一般是“给路由打标签再发送”，两条路线职责不同,写在一起很容易自我干扰。
复杂互访场景下社区属性与选路策略的排障方法
当网络里有两个运营商出口、三条专线互联的时候,community出问题时的排障思路比命令本身更重要。
排查第一步：查看实际收到的community
执行show bgp ipv4 unicast 10.0.0.0/24，重点观察Community:这一行，理想状态下应显示你期望的标签值，100:10，如果你期望的是100:10，但显示的是no-export或空字符串，说明上游出方向策略没放行,或者中间设备做了剥离。
排查第二步：检查策略命中顺序
再用show route-map查看每个Route-Map里的match和set子句顺序，注意match community和match as-path不能放在同一个节点里混合做OR逻辑，因为route-policy节点内默认是AND逻辑这是思科和华为设备行为上容易混淆的细节。
排查第三步：验证community的传递路径
在IBGP邻居之间可以放心使用community，但跨AS传递必须检查send-community配置，你可以在中间路由器上执行show tcp bfd sessions旁路，或者在选路路由器上用debug bgp updates看社区属性是否随Update报文一起发出。
路由策略最佳实践：让community标签与选路参数解耦
与其把community当作直接控制选路的旋钮，不如把它当成“信息通道”,只在需要区分同等优先级路由时才干预选路参数。
推荐的做法是“标签驱动策略，策略最小化”
IBGP全互联环境下，用community标记“来自客户侧”的路由，但不动LOCAL_PREF，仅在需要做流量牵引时，用一条精确的Route-Map匹配100:10并set LOCAL_PREF，其他路由保持默认值在180，这样做的优势很明显默认情况下的选路行为完全遵循BGP标准顺序，可预测,好排障。
慎用community做全局禁止
不要试图用community实现“凡是打上某个标签的一律不接受”，比如deny加100:99的配置，除非你对全网community标签的分布有绝对掌控，否则这种一刀切策略容易误伤正常路由，多数生产环境只需要用community配合advertise和allowas-in做定向控制。
常见误区与应对建议
整理三个大家最容易忽略的细节：
- NO_EXPORT和NO_ADVERTISE是系统自带community，不需要你自己创建，分发路由时记得它们默认只对EBGP生效,对IBGP邻居无效。
- community属性不参与路径选择，不代表它不会影响选路结果，同一个前缀如果从多个邻居收到，其中一条带community的被策略改了LOCAL_PREF，另一条没带的不变,最后选路结果截然不同。
- 不要试图用community替代AS_PATH中的prepend功能，如果你想让某条链路成为备份链路，
set as-path prepend
直接作用于AS_PATH长度，比community加
local-preference更直观,且不存在标签传递丢失的风险。
路由选路规则与社区属性的终极协同思路
任何基于community的选路设计，最后都得回到一个问题上：不依赖community时，你的选路规则是否已经足够合理？社区属性只是辅助工具，它的价值在于让网络具备“按策略自动适应”的能力,而不是让运维依赖一堆临时打上的标签来修正错误的基础选路。
行业共识认为，大多数网络故障不是出在BGP选路标准本身，而是出在策略叠加后规则间的相互作用，你的关注重点应当放在三件事：保持community标签语义唯一、Route-Map匹配顺序单调、跨AS传递链路显式声明允许community字段。
Q&A：路由必会问到社区属性场景注意点
Q1：BGP routing policy中，community匹配不生效，可能是什么原因？
A1：检查三个位置，一，邻居方向上有没有启用send-community both；二，Route-Map里的match语句是不是用了match community精确匹配，而收到的community是多个值且顺序不同；三，设备型号的community匹配默认是否区分大小写，如果前两步都无误，用show bgp neighbors x.x.x.x advertised-routes确认发出的Update里是否真的携带期望标签。
Q2：出方向和入方向Route-Map可以同时处理同一个community属性吗？
A2：可以，但建议把职责分开，入方向Route-Map负责“识别community并修改选路参数”，出方向Route-Map负责“给即将发布的路由追加或移除community”，最忌讳的是出方向先移除label，入方向又期待它能匹配到原标签,这样逻辑上就断了。
Q3：用community打标签来提升路由优先级，是否会导致环路风险？
A3：community本身不携带防环信息，真正防环还是要靠AS_PATH和BGP的环路检测机制，如果你在多个AS之间反复传递带特定community的路由，不会产生路由环路，但可能造成策略意外叠加比如某条路由经过两跳IBGP，每跳都执行set local-preference 500，结果值还是500，但策略意图会变得混乱，收敛变慢，建议只用community标记来源，不用它直接覆盖权重,除非你明确知道该标签的传播范围已限定在单台设备或单一AS内。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/643383.html
