覆盖还是追加
route-map 里的 set community 默认是覆盖语义：设置新值会把路由上已有的团体属性全部替换掉。加 additive 关键字之后变成追加，原有取值会被保留。这在入方向打标时很关键——上游的 no-export 之类标记一旦被覆盖，这条路由的可传播范围就跟着变了。
基本信息
| 命令 | set community <值> [additive] |
|---|---|
| 默认行为 | 覆盖路由上已有的团体值 |
| additive | 在已有值之后追加，保留上游标记 |
| 典型用法 | 入方向打标时保留上游标记 |
| 核对命令 | show ip bgp <前缀> 查看 Community 字段 |
典型使用场景
- 入方向新增本域标记，同时保留上游的 no-export
- 分级打标：按来源追加不同标记供下游策略使用
- 排障「上游标记消失」：检查是否漏写 additive
- 策略评审：明确每个 set community 是覆盖还是追加
- 跨域对接：确认对端对团体属性的处理约定
示例与核对
示例与核对
route-map RM-IN permit 10
set community 65001:100 65001:101 additive # 追加标记，保留原有取值
!
show ip bgp 10.1.0.0/16 | include Community # 核对最终团体集合
!
# 不加 additive 时：原有团体值会被整体替换两种语义对照
| 写法 | 效果 | 风险 |
|---|---|---|
| set community X | 覆盖已有值 | 上游标记丢失 |
| additive | 追加到已有值之后 | 团体数量增长，需要控制规模 |
| 配合删除操作 | 先删指定值再设置 | 顺序不当会删错对象 |
漏写 additive 时上游的 no-export 等标记会被覆盖：路由的可传播范围随之改变，这类问题往往在对端出现异常路由时才被发现。
additive 的语义是追加标记，不是数值运算：把多个取值理解为相加，预期就会与实际结果不符。
团体值会随追加不断增长：建议在设计阶段就确定标记层级与数量上限，避免属性膨胀影响后续维护。
入方向打标建议放在策略靠前的位置：顺序不同会让后续判断建立在不同的标记集合上，结果差异很大。
定期清理无用团体值：长期追加会让属性列表越来越长，审计与排障都更费力。