什么是 BGP Community？路由策略标签、流量引导与 BLACKHOLE

开篇定义： BGP Community 是附在一条 BGP 路由上的可选属性，用来向接收方传递策略信息。它表达的是"希望你怎么处理这条路由"；真正执行什么，取决于接收网络自己配置的路由策略。

两条上游，会话都是 Established，前缀两边都发了，流量进来却五五开。你想让 A 承担大头、B 只做备份；或者反过来，让某个前缀只在欧洲可见、别的地区根本搜不到。这时候会撞上一堵墙：路由一旦离开你的路由器，走哪条路进来，是别人家网络自己选的。你在自己这边能做的非常有限。

标准做法是给路由打个标签——BGP Community。但在依赖它之前，先把四句话钉在墙上：

它附着在已有路由上；
ASN、ROA 和 IRR 分别负责身份、授权和登记；
路由是否继续传播，由沿途网络分别决定；
接收方没有对应策略时，标签不会触发动作。

Community 的正式定义来自 RFC 1997：一组具有共同属性的目的地，作为可选传递属性附着在 BGP 更新里。RFC 1997

白脸小鹿把一枚小标签系在路由卡上，递向上游守门人；守门人面前摆着自己的策略手册，尚未决定是否照办。

你发出去的是一张带标签的请求。收不收、办不办，是守门人的事。

1. 它发出信号，处理权在接收方

先把四个事实摆清楚，后面所有内容都建立在这上面：

它是附在路由上的标签。 前缀、起源 ASN、AS_PATH 该怎么传还怎么传，Community 只是搭顺风车的一个属性。
标签能表达来源、用途或请求。 "这条路由从法兰克福进来""请优先走我""只给你的 Peer 看"。
上游可以响应标签。 常见动作：调 Local Preference、限制再宣告范围、转发前追加 AS_PATH。
接收方永远有最后决定权。 保留、改写、剥掉、无视，四种处理都可能发生。

放到你已经熟悉的概念里，位置是这样的：

概念	回答的问题
IP 前缀	哪段地址被宣告
ASN	哪个网络在宣告
BGP	网络之间怎么交换路由
Community	发送方希望这条路由被怎么处理
ROA	地址持有方授权哪个 ASN 宣告这段前缀
IRR Route Object	哪个 ASN 登记了宣告这段前缀的意图

这套分层在 BGP 基础里讲得更细。这里只强调一句：你发送的是策略请求，接收方的路由器仍由对方控制。市场上偶尔能听到"发了某个 Community 就能控制全网走线"的说法，那种话术可以直接扔掉。

2. Community 补上路由处理意图这一层

上游会过滤你的前缀，也会读取 AS_PATH，但这两层信息只说明"这条路由能不能进、更新经过了谁"，没有表达收到之后该怎么处理。前缀过滤负责准入；AS_PATH 记录路径。按机房、按 Peer、按地区的处理意图，需要 Community 来传递。

没有 Community，每一条特殊要求都得服务商在自己那边逐个邻居手工配置。有了标签，发送方分类一次，运营方就能对带同一标签的所有路由统一执行：

有了标签，发送方分类一次，运营方对带同一标签的所有路由统一执行：

客户路由
   ↓
附加 Community
   ↓
上游识别标签
   ↓
上游本地策略
   ↓
决定传播范围、优先级或 AS_PATH

注意这条链上任何一个箭头都可能断。标签在策略看到之前就被剥掉，或者策略压根没配，结果都一样：什么都没发生，而且没有任何报错。BGP 的世界里，静默是默认行为。

3. Community 的格式和策略语义

类别	基本形式	需要知道的事
Standard Community	32 位，常见写法 `ASN:value`	RFC 1997 的经典属性。两半各 16 位，四字节 ASN 塞不进去
Large Community	`ASN:value1:value2`，三个 32 位字段	为四字节 ASN 设计，现代网络的首选（RFC 8092）
Extended Community	8 字节	独立的另一个属性，主要用在 Route Target 和 VPN 场景（RFC 4360）
Provider-defined 策略语义	通常承载在 Standard 或 Large Community 里，具体值由上游定义	真正干活的部分，实际采购和运维最该关注的

这张表把三种属性格式和一种运营分类放在一起，是为了对应上游文档里的实际写法。Provider-defined 属于策略语义层，通常承载在前三种属性格式之一上，接收方再为这个值约定处理动作。

这张表里藏着两个容易踩的坑。

Standard 和 Large 的关系。 Standard Community 由两个 16 位数字组成；四字节 ASN 需要 Large Community 的三个 32 位字段，第一段可以完整放下 ASN。Large Community 和 Standard Community 之间没有升级迁移关系，两者在生产环境里并行使用，用哪一种看上游文档。

Community 和 Extended Community 的关系。 它们属于两种不同的路径属性，格式和用途也不同。VPN 里常见的 Route Target 属于 Extended Community。处理其中一种的策略和工具，未必能处理另一种。

这张表总结成一句话：相同格式与相同含义是两件事。 64500:70 这个值本身没有定义，只有当上游文档说明它的用途、对应会话配置了策略时，它才会产生效果。（64496–64511 是文档保留的 ASN 段，本文所有示例值均为示意，不对应任何一家真实服务商。）

4. Well-Known：本文重点讲四个常见值

本文重点介绍四个常见的标准化值。它们的基础语义写在 RFC 里；其他 Well-Known Community 还有各自的用途，本文不展开：

Community	含义
`NO_EXPORT`	不要宣告到 BGP confederation 之外——在普通非 confederation 场景里，通常不会越过下一个外部 eBGP 边界
`NO_ADVERTISE`	不要宣告给任何 BGP 邻居，内网外网都不行
`NO_EXPORT_SUBCONFED`	不要宣告给外部邻居，confederation 内的其他成员也算外部
`BLACKHOLE`	请求接收方丢弃发往这段前缀的流量

前三个的语义来自 RFC 1997，BLACKHOLE 单独由 RFC 7999 定义。RFC 7999

两个误会需要提前拆掉。

误会一：拿到 Well-known 名称，上游就会按同一方式执行。 实际处理仍由设备和运营者的策略决定：有的执行、有的透传、有的直接剥掉。RFC 8642 正是为这类差异提供规范。针对某个特定邻居使用 Well-known 值前，先确认对方的行为。RFC 8642

误会二：BLACKHOLE 能自动提供 DDoS 防护。 它表达的是"请丢弃发往这段前缀的流量"。是否接收、是否执行，由接收网络决定：很多网络只对授权前缀生效——通常要求是你已合法宣告的前缀的更具体段——有的限制最长前缀长度，有的要求提前申请开通。生效时，流量会被丢弃，也不会进入清洗设备；这段前缀会暂时不可达，这就是它的用途和代价。

5. Provider-Defined：真正干活的部分

Well-known 值管的是边缘情况。日常那些活——入站流量引导、传播范围控制、路径降级——全靠各家服务商自己定义并写进文档的 Community：

业务目标	上游可能提供的 Community 能力	实际改变的是什么
让某个上游更偏好你的路由	上游调高自己对你的 Local Preference	那家上游自己的网络怎么把流量发给你
让某个地区少看到你的路由	区域传播控制	路由在上游足迹的部分区域内的传播
让某类邻居收不到你的路由	Peer / Transit 出口控制	上游把你的路由再宣告给谁
让某条路径不那么优先	上游代为 AS_PATH prepend	远端网络比较你的几条路径时的结果
遇到攻击时临时丢流量	BLACKHOLE / RTBH	流量在接收方网络内被丢弃

三个层面必须分开，因为销售话术最喜欢把它们揉在一起：

Local Preference 是接收方 AS 内部的事。 上游因为你带的标签调高了 LP，效果是它的网络发往你时更愿意走你们的直连——你的入站流量因此变多。对这家上游之外的网络，一点影响都没有。
AS_PATH prepend 改变的是第三方对你的几条路径的比较结果。 路径短的赢，你在自己的出站方向可以自己 prepend，也可以让上游通过 Community 在它的再宣告里代做。思路一样，作用点不同。
Community 本身两件事都不干。 它是扳机，扣下去之后枪管朝哪，是上游的配置说了算。

所以诚实的说法只有这一种：如果上游支持这个 Community，它可能按文档执行对应策略；其余每个网络仍然按自己的策略选路。 比这更硬的承诺，BGP 给不了。

6. 双上游实战：四个场景

                ┌── 上游 A
你的网络 ────────┤
                └── 上游 B

假设两个会话都宣告同一个前缀。会话本身是什么关系、怎么建，Transit 和 Peering 的区别里有完整说明。这里直接进场景。

场景一：A 做主用。 在 A 的会话上带上它文档里"调高 Local Preference"的 Community，它的网络从此优先从直连把流量发给你。可以同时在 B 的方向自己 prepend 几段 AS_PATH，或者用 B 的 prepend Community，让你的路由在 B 的下游看起来更绕。一推一拉，主备就出来了。

场景二：B 只服务一个区域。 用 B 的区域控制 Community，让 B 只在自己的欧洲足迹内再宣告你的前缀。足迹之外，B 的客户压根看不到这条路由。验证方式很直接：法兰克福的 Looking Glass 查得到，新加坡的查不到——这就对了。

场景三：某个前缀只给 Peer 看。 用上游的 peer-only 出口 Community，路由到达它的互联伙伴，但不再向上游的 Transit 传播。注意 NO_EXPORT 在这里通常太钝：它一到第一个 eBGP 边界就停，很可能比你要的范围还少一站。

场景四：某个前缀正在被攻击。 向参与 BLACKHOLE 服务的上游，宣告被攻击前缀的一个更具体段并带上 BLACKHOLE Community。发往这个具体段的流量在对方边缘被丢弃，覆盖它的原始前缀照常可达。这正是多宿架构的价值时刻——一条上游烧掉一个前缀，另一条还撑着你的网络。

白脸小鹿站在双轨传送带的岔口，在主路径上举起信号旗，副路径前的闸门随之收窄。

调优先级、限区域、只给 Peer、丢流量：四个请求，两条会话，同一个机制——标签加文档化策略。

7. 验证：一条四层的阶梯

本地路由表里能看到 Community，证明不了上游执行了它。上游执行了，也证明不了全球每个网络都采用这个结果。验证得一层一层来：

第 1 层  你的路由器     标签有没有附在正确的前缀上？
                        有没有被你自己的 outbound 策略剥掉、原样送进 Adj-RIB-Out？

第 2 层  上游视角       对方在正确的会话上收到没有？
                        它文档里的策略有没有匹配到这个标签？

第 3 层  Looking Glass 路径有没有按预期变化？
                        Community 在被观测的路由上还在不在？

第 4 层  多个观测点     不同地区看到的路径差异符合设计吗？
                        有没有意外的黑洞、有没有网络还在走旧路径？

白脸小鹿踩着四级折梯，举着单筒望远镜，在不同高度逐层查看那张带标签的路由卡。

验证要沿着四层阶梯往上走：同一张带标签的路由卡，每一层回答一个不同的问题。

第 1 层是你的责任。outbound 策略是最常见的沉默杀手——一条 route-map 或一次属性改写，标签就没了，而你本地看什么都是正常的。第 2 层是对话，"我们执行了"这种口头回答不算数，要看对方的 Looking Glass。第 3 层开始借助第三方视角，Route Server 和公开 Looking Glass 能告诉你路径动没动；如果观测点公开 Community，还能看出属性有没有留下。第 4 层收口：跨区域各查一遍。Community 触发的策略，恰恰是最容易"阿姆斯特丹生效、新加坡没动静"的东西。

三个习惯让结果可靠：

一个 Looking Glass 只代表一个观测点。 多查几个，跨区域查。
记录检查时间和位置。 查询结果带着时间戳，反映的是当时状态；上游策略随时可能调整或撤销。
路由观测和起源授权一起看。 授权那一层怎么核对，RPKI 和 IRR 的区别里写得最全。

8. Community、IRR、RPKI：各管各的问题

这几套系统回答的问题完全不同，谁也替代不了谁：

系统	它回答的问题
BGP Community	发送方希望这条路由被怎么处理
IRR	哪个 ASN 登记了宣告哪段前缀的意图
RPKI / ROA	地址持有方授权哪个 ASN 宣告这段前缀
Looking Glass	某个网络当前看到了什么
BGP 会话	两台路由器的控制面连上了没有

交叉的地方最容易出误解：

Community 修不好错误的起源 ASN。ROA 写的是甲、你用乙宣告，带什么标签都没用。起源、授权、上线的完整链条见拿到 ASN 之后该做什么。
IRR Route Object 装不下 Community 的含义，Community 也不会把你的意图写进任何一套过滤系统会读的数据库。
RPKI Valid 和上游执不执行你的 Community 毫无关系，授权和策略是两层。
会话 Established 和流量通不通也没有关系，可达性是在下游逐前缀决定的。

9. 采购前，把十一个问题问完

买 Transit、BGP VPS 或者任何带 BGP 会话的服务之前，这张清单比单价重要，因为上面每一条都是你事后在自己这边修不了的：

压缩成一句话：真正需要问完整的是"支持哪些、作用在哪些会话、怎么验证、怎么撤销"。我的建议很直接——答不上来这十一个问题的上游，报价再低也要慎重。 白纸黑字写不下来的承诺，等于不存在。

顺带划清一个边界：SKNK 提供的是 ASN 赞助和 IPv6 PA /48 分配，不卖 Transit，也不做托管 BGP。上面这些问题交给承载你流量的服务商；LIR 负责注册资源，职责不同。ROA、IRR、首次宣告的完整上线顺序，见如何通过 BGP 宣告 IPv6 /48。

FAQ

BGP Community 是所有网络通用的吗？

每个网络自己决定对收到的属性怎么处理：执行、透传、改写或者丢弃。Well-known 值有 RFC 写下的基础语义，但各网络的实际处理仍然不同，这正是 RFC 8642 需要专门规范的原因。

发了某个 Community，能保证流量走指定上游吗？

它只能影响愿意响应这个标签的网络——最直接的就是你发给它的那家上游。更远的网络按自己的标准选路。Community 引导流量是一种影响机制，最终选路仍由各网络决定。

NO_EXPORT 和 NO_ADVERTISE 有什么区别？

NO_ADVERTISE 更严格：路由可以留在接收路由器的本地 RIB，但不能再传给任何 BGP 邻居。NO_EXPORT 允许在接收方 AS 内部（或 confederation 内）传播；在普通非 confederation 场景里，它通常不会越过下一个外部 eBGP 边界。一个留在本地，一个留在服务商网络内部。

BLACKHOLE Community 是 DDoS 防护服务吗？

BLACKHOLE 是"请丢弃发往这段前缀的流量"的标准化请求。是否执行看接收方的策略、是否提前开通、你对这段前缀有没有授权。生效之后流量会被丢弃，前缀也会暂时不可达；它用移除攻击目标的方式止住攻击。

Community 能替代 ROA 或 IRR 吗？

三者分别处理不同问题：ROA 管起源授权，IRR 管给过滤器读的登记，Community 管路由被接受之后的处理方式。它们各自承担自己的职责。

为什么本地能看到 Community，上游却不执行？

按顺序核对：标签是否附在对的前缀和对的会话上；是否被你自己的 outbound 策略在 Adj-RIB-Out 之前剥掉；上游文档是否定义了这个值；策略是否需要按客户开通。静默丢弃属于 BGP 的正常行为。

普通 VPS 支持 BGP Community 吗？

只有真正给你 BGP 会话的产品才谈得上支持，而且各家差异很大。如果是隧道、绑定地址或服务商代宣告，你根本没有自己的 BGP 宣告，Community 无从谈起。有会话的，按上面那张采购清单问。

Large Community 和 Standard 该用哪个？

上游文档说支持哪个，就用哪个。Large 对四字节 ASN 更合适，是现代网络的方向，但对方不读的标签只是装饰。很多网络对同一个意图两种都发。

小结

Community 是从"宣告一条路由"到"和承载你的网络沟通"之间补上的那一环。Standard、Large、Extended 是格式，Well-known 是边缘情况，Provider-defined 才是日常干活的部分。

它需要三个条件：属性带着请求出发，服务商的文档化策略决定发生什么，你再通过自己的路由器、对方的设备、Looking Glass 和多个观测点验证结果。采购时把十一个问题问完，运营时把四层阶梯走完，剩下的交给对方的配置。

一句话记住

BGP Community 是附在路由上的策略标签：它向接收方提出传播、优先级或路径处理请求，真实效果取决于对方的文档、配置和你自己的验证。

参考资料

继续阅读

BGP 基础：互联网怎么知道流量该往哪送 —— Community 搭便车的那个协议
什么是多宿？为什么一条互联网连接不够用 —— 让入站引导变得值得的那套架构
Transit 和 Peering 有什么区别？ —— 你的标签跑在哪两类会话上
RPKI、IRR、ROA 到底有什么区别？ —— Community 替代不了的那两层授权
拿到 ASN 之后该做什么？ —— ROA、IRR、会话、首次宣告的完整顺序
如何通过 BGP 宣告 IPv6 /48？ —— 第一次生产宣告的核对清单