入口选路靠协同
对端从哪条链路进入本 AS，不由本端单方面决定：本端只能用 MED、AS_PATH 预置或按运营商提供的社区请求来表达意向，最终由对端按其 LOCAL_PREF 与过滤策略决策。因此入口选路本质上是协同设计——本端负责把意向表达清楚、保留多入口冗余，对端是否采纳必须从对端视角验证。
基本信息
| 本端手段 | MED 设置、AS_PATH 预置、按运营商社区请求 |
|---|---|
| 对端因素 | 其 LOCAL_PREF 与过滤策略优先级高于 MED |
| 验证方式 | 从对端视角确认实际入口，而不是只看本端配置 |
| 冗余要求 | 关键业务保持多入口可用 |
| 一致性 | 同一对端的多条链路 MED 取值要成体系 |
| 协同要求 | 变更前与对端约定，并确认其是否采纳 |
典型使用场景
- 多运营商出口：请求对端优先使用某条链路
- 备份链路保护：用 MED 让流量走主用入口
- 割接迁移：临时调整入口意向并观察对端是否按预期切换
- 排障「流量仍走备用」：确认对端是否真的按 MED 决策
- 社区协同：使用运营商提供的社区请求其调整本地优先级
设置入口意向
设置入口意向
route-map RM-ENTRY permit 10
set metric 50 # MED 建议值
set as-path prepend 65001 65001 # 需要更强意向时才用
!
router bgp 65001
neighbor 10.0.0.2 route-map RM-ENTRY out
!
show ip bgp neighbors 10.0.0.2 advertised-routes # 核对发出的属性
show ip bgp 10.1.1.0/24 # 核对本端该前缀的属性入口意向手段对比
| 手段 | 作用对象 | 强度与限制 |
|---|---|---|
| MED | 同一邻居 AS | 建议性质，对端 LOCAL_PREF 优先时无效 |
| AS_PATH 预置 | 对端与更远端的路径长度 | 强度更高，但会波及更远的选路 |
| 运营商社区请求 | 由运营商按其策略执行 | 受合同与其内部策略约束 |
| 改接入方式 | 物理与逻辑拓扑 | 最彻底，但周期与成本最高 |
MED 是建议不是命令：对端若已按 LOCAL_PREF 决策，MED 完全不起作用。入口问题必须在对端视角验证结果，只看本端是否发出属性没有任何意义。
同一对端多条链路的 MED 取值要成体系：随意配置会让对端按不可预期的顺序选择入口，事后也难以从单条命令推断哪条链路会被选中。