BGP路由策略中社区属性的核心作用，是把成千上万条路由按业务意图贴上可识别的“标签”，让路由控制器能够批量执行策略，而不是逐条去匹配前缀，解决的是大规模网络环境下路由策略的“自动化分组”与“跨域协作”问题。
社区属性（Community Attribute）本质上是一组32位的数值，附加在BGP路由上，随路由一起通告，它不直接改变路由的选路结果，而是作为一个携带信息的载体，让对端路由器根据这个标签来执行预先约定好的策略，理解这一点，就理解了社区属性在整个BGP策略体系中的定位它更像是路由的“身份证号”，而不是路由的“优先级”。
社区属性究竟是什么？先厘清它的底层逻辑
社区属性在RFC 1997中被定义，它不是一个简单的数字，而是一组可以同时附加在一条路由上的多个32位值，这些值分为两类：公有社区值和私有社区值。
公有社区值由IANA分配，具有全局含义,常见的有以下几种：
- NO_EXPORT（0xFFFFFF01）：收到此属性的路由器不得将该路由通告给任何外部AS（自治系统），这个值用得最多,常用于控制路由的传播范围。
- NO_ADVERTISE（0xFFFFFF02）：收到此属性的路由器不得将该路由通告给任何邻居，包括内部和外部，这个值相当于“到此为止”。
- LOCAL_AS（0xFFFFFF03）：收到此属性的路由器不得将该路由通告给AS-Path中出现的任何外部AS，主要用于联盟（Confederation）场景下防止路由环。
- NO_PEER（0xFFFFFF04）：收到此属性的路由器不得将该路由通告给任何IBGP对等体以外的邻居。
私有社区值则是管理员自行定义的，格式通常为AS号:自定义值，例如65001:100，这种格式便于识别该值所属的AS，业内专家指出，绝大多数生产环境中的社区属性策略，用的都是这种私有格式，因为它的语义完全由本地网络管理员控制,灵活度最高。
社区属性的核心工作方式不是路由器自动处理，而是在入方向或出方向的route-policy中，通过匹配社区值来触发动作，这意味着它本身没有动作，动作全在策略里，收到一条带65001:100社区值的路由，本地路由器就给它设置local-preference为200，这条路由可以同时携带多个社区值,策略也可以针对不同值组合执行不同动作。
BGP community怎么用？三个真实场景下的设置思路
社区属性的价值在于简化策略，没有社区属性之前，对路由做策略要针对具体前缀逐一匹配，维护成本极高，有了社区属性，只需要标记一次,后续策略全部按标签批量处理。
客户路由隔离与策略批量下发
这是社区属性最常见的用途，运营商或大型企业网络，通常有大量客户接入，每家客户的路由需要不同的选路偏好，但前缀数量巨大，行业共识认为，运营商的典型做法是在客户接入路由器上，对客户宣告的路由打上社区标签,然后在上游路由器上统一匹配这些标签执行策略。
具体操作思路如下：
- 在客户接入路由器的入方向policy中，为不同客户配置不同社区值，例如
AS65000:1000代表重点客户，AS65000:2000代表普通客户。 - 在核心路由器上，配置匹配
AS65000:1000的policy，设置较高的local-preference值。 - 核心路由器向对端AS通告时，在出方向policy中,再次根据社区值决定是否附加NO_EXPORT属性。
这种做法的好处是，新增客户或调整客户等级时，只需要修改接入端的社区标记,核心策略完全不用动。
跨域协作中的路由策略传递
在运营商互联或企业多出口场景下，社区属性是协商策略的“通用语言”，两个AS之间签订对等协议时，会约定一组社区值的含义，当一方需要另一方帮忙做流量调控时，只需发布带特定社区值的路由,对端看到后按约定执行。
举个例子，A运营商和B运营商互联，约定BAS:500表示“请将路由的local-preference降低”，BAS:600表示“请将路由的MED值调高”，A运营商在向B发布路由时，如果希望某条路由在B侧优选优先级降低，就在路由上附加BAS:500，B运营商路由器收到后，自动匹配该社区值并调整local-preference，整个过程不需要双方临时沟通,完全自动化。
这在Quagga、FRRouting或Cisco IOS等主流设备上都是标准配置思路，比如在FRRouting的BGP配置中，通过route-map设置community，再通过ip community-list匹配,命令为：
route-map SET-COMMUNITY permit 10 set community 65001:200 route-map MATCH-COMMUNITY permit 10 match community SET-COMMUNITY set local-preference 50
流量黑洞与定向引流
当网络遭受DDoS攻击时，需要快速将恶意流量牵引到清洗设备，BGP社区属性提供了一个非常高效的方案，运营商约定一个特殊社区值，例如AS65001:666表示“黑洞路由”，客户路由器将该社区值附加在目标前缀上宣告出去，上游路由器匹配到后，直接将下一跳指向Null0接口（丢弃口）。
由于社区属性是随路由实时通告的，客户发出带黑洞社区值的路由后，通常数十秒内就能完成全网黑洞生效，比传统手动逐台设备配置快得多，据工信部发布的网络安全通告信息,近年来国内主流云厂商和运营商都普遍采用此类方案防御大流量攻击。
社区属性与路由策略整合：一个完整的设计流程
要把社区属性用好，关键不只是命令，而是整体设计思路，以下是一个相对完整的社区策略设计流程,适用于大多数需要精细控制路由传播的网络。
第一步：定义社区值语义表
在动手配置前，先建立一张全局的社区值对照表，这张表要覆盖所有可能的策略场景,一般建议至少包含以下几类：
- 选路类：调整local-preference、MED、AS-Path。
- 传播控制类：是否允许向对端AS通告、是否允许向下游客户传递。
- 业务标识类：区分客户等级、业务类型、地理位置。
- 动作类：黑洞、重定向、抑制宣告。
每类分配一个独立的区间，避免语义重叠，例如AS65001:1000-1999用于选路类，AS65001:2000-2999用于传播控制类。
第二步：在边界路由器上标记社区
标记动作发生在路由的入方向，以客户接入为例，在客户接入路由器的入方向policy中，根据客户来源接口或对端AS号，给每条客户路由附加对应的社区值，这一步的关键在于标记要准确且分类清晰，如果同一客户有多个等级的流量，还要结合前缀列表或AS-Path匹配来细分。
第三步：在核心路由器上执行策略
核心路由器不需要关心客户具体的路由前缀，只需要根据社区值匹配来调整选路参数，匹配到AS65001:1000的客户路由，设置local-preference 200；匹配到AS65001:2000的，设置local-preference 100。
第四步：在出方向控制传播
当向对端AS通告路由时，需要根据社区值决定是否附加NO_EXPORT或NO_ADVERTISE属性，这一步通常在上游路由器出方向配置，核心逻辑是：不希望被对端继续传递的路由，加上NO_EXPORT社区值；完全不允许被通告的路由,加上NO_ADVERTISE。
第五步：验证与排障
配置完成后，用show bgp community或show bgp community-list命令检查路由携带的社区值是否与预期相符，在调试模式中，查看route-policy的统计信息，确认匹配结果，一个常见的排障思路是：先确认路由是否带上了正确的community，再确认策略的匹配方向是否正确,最后确认动作是否生效。
社区属性配置中容易踩的坑与规避方法
社区属性看似简单，但在实际生产环境中，有相当一部分网络故障源于社区值误配,以下几个坑比较典型。
坑一：社区值传递被意外剥离
默认情况下，Cisco设备的BGP不会向eBGP邻居传递社区属性，需要全局配置neighbor x.x.x.x send-community，很多初次配置的人会发现路由对端收不到community，以为是策略问题,实际上只是没开传递开关。
规避方法：核对所有eBGP邻居下是否都开启了send-community，同时确认IBGP邻居是否配置了send-community extended（如果需要扩展社区属性）。
坑二：匹配顺序错误导致策略失效
社区列表匹配是逐条匹配的，如果前面的规则直接permit或deny，后面的规则就不会再执行，而且社区值匹配通常区分大小写格式,十六进制和十进制混用也会导致匹配失败。
规避方法：在设计route-policy时，将精确匹配放在前面，模糊匹配放在后面,并且先确认所有community的格式统一。
坑三：no-export与local-as生效范围混淆
NO_EXPORT的含义是“不传给任何eBGP邻居”，在联盟场景下，NO_EXPORT不阻止在子AS间传递，如果想在联盟内部隔离，需要使用LOCAL_AS，不少网络管理员在实际配置时混淆了这两者,导致路由在联盟内部意外外泄。
规避方法：在联盟环境中，优先使用LOCAL_AS来限制传播；在普通多AS环境中,使用NO_EXPORT。
常见问题解答
以下三个问题覆盖了社区属性使用中最常被搜索求解的知识点。
Q1：BGP community值怎么区分公有和私有？怎么规划私有值不会跟公有冲突？
公有社区值的范围由RFC 1997规定，即0xFFFFFF00到0xFFFFFFFF，任何在此范围内的值都是保留的，不能自定义使用，私有范围的社区值通常按AS号:自定义编号的方式组织，例如AS65001:100，这里有一个注意事项：当社区值格式不是AS:自定义值，而是单个32位整数时，需要查IANA注册列表确认是否被占用，如果使用AS:自定义值格式且AS部分是自己的AS号，一般不会冲突,因为这个值的全局语义由你的AS控制。
Q2：用community控制选路和直接用prefix-list控速，到底哪个更好？两者有本质区别吗？
两者解决的是不同层面的问题。prefix-list匹配的是“谁的路由”，community匹配的是“路由被贴了什么标签”，prefix-list适合前缀数目少、策略变化不频繁的场景，community适合前缀数目大、策略需要动态调整的场景，前者是静态匹配，后者是动态标记，实际环境中两者经常配合使用，比如先用prefix-list粗筛路径,再用community做细粒度分类。
Q3：在不同厂商设备上（如Cisco、华为、Juniper），社区属性的匹配命令差异大吗？
核心概念统一，但命令语法差异明显，Cisco用ip community-list和set community，华为用ip community-filter和apply community，Juniper用community和policy-options结构，三者都支持标准的32位社区值定义，也都支持additive（追加）模式，需要特别说明的是，匹配逻辑在Juniper中更接近“正则表达式匹配社区列表”，而Cisco和华为则更侧重于“列表顺序匹配”，如果网络中存在多厂商设备互联，建议在核心策略上统一使用标准的well-known community值（如NO_EXPORT）,这些值的解析在所有厂商设备上行为完全一致。
社区属性本身不解决问题，它是你网络策略管理体系中的一环，它的价值在于：让路由策略从“一屋子的手工标记”变成“一套可复用的自动化标签体系”，当你面对成百上千条需要差异化处理的路由时，社区属性是让运维工作从“疲于奔命”走向“从容可控”的那把钥匙，理解这一点，你就具备了设计一套稳定、可扩展的BGP路由策略的基础条件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/643515.html
