用社区驱动选路的模式
常见做法是把「路由来源或业务类型」编码成社区标签：上游或客户侧在发布时按约定打标，本端在入方向匹配标签后设置 LOCAL_PREF、MED 或过滤动作。这样策略只需维护标签定义，不必按前缀逐条列举，新增网段时通常只改打标规则而不动匹配规则。
基本信息
| 流程 | 打标 → 跨 AS 传递 → 本端匹配 → 设置属性 |
|---|---|
| 优势 | 策略语义集中在标签定义，减少逐前缀维护 |
| 前提 | 双方社区编号约定形成书面文档并版本管理 |
| 配套开关 | 邻居必须开启 send-community 才能传递属性 |
| 回程要求 | 双向都需要对应标签，否则策略只做了一半 |
典型使用场景
- 按来源类别分流：客户、对等、上游分别打不同标签，本端据此设置优先级
- 客户自助控制：客户通过宣告特定社区表达路由偏好，运营商按约定执行
- 互联网出口优化：用众所周知的社区值请求上游调整发布范围或路径
- 迁移期标记：给新链路路由打专用标签，便于统计与回退
- 审计与对账：标签即业务语义，出现问题时可快速核对双方是否按约定执行
按标签设置 LOCAL_PREF
按标签设置 LOCAL_PREF
# 对端打标：客户路由统一加 65002:300
route-map RM-TAG permit 10
set community 65002:300 additive
!
router bgp 65002
neighbor 10.0.0.1 route-map RM-TAG out
!
# 本端匹配：命中标签后设置本地优先级
ip community-list standard CL-PEER permit 65002:300
route-map RM-PEER permit 10
match community CL-PEER
set local-preference 90
!
router bgp 65001
neighbor 10.0.0.2 route-map RM-PEER in
!
show ip bgp 10.100.0.0/16标签设计要点
| 要素 | 建议 | 原因 |
|---|---|---|
| 编号结构 | 固定字段表达来源与用途 | 便于正则批量匹配与人工解读 |
| 文档管理 | 与配置同版本变更记录 | 任一侧调整都能追溯到变更原因 |
| 默认处理 | 未打标的流量明确兜底策略 | 避免新增来源因无标签而落在意外分支 |
| 方向覆盖 | 入向与出向都设计标签语义 | 单向标签会让策略出现半边失效 |
核对与排错
核对与排错
# 1) 对端是否真的发出社区
show ip bgp neighbors 10.0.0.2 advertised-routes
# 2) 本端是否收到社区
show ip bgp 10.100.0.0/16 | include Community
# 3) 匹配是否命中
show route-map RM-PEER
# 4) 属性是否按预期生效
show ip bgp 10.100.0.0/16 | include LocPrf社区标签跨越了组织边界：约定了却不按约定执行时，故障往往表现为「策略不生效」而不是明确报错。变更前先确认双方标签表版本一致，并在变更后抽样核对实际收到的社区值。