AS48635 在 Juniper 边缘路由器上配置聚合策略本意只宣告汇总前缀，实测却发现更具体路由仍被发送，形成“BGP 僵尸路由”，干扰流量工程甚至引发故障。
配置预期与实际偏差：
生产环境中，运维团队通过 bgpq3 自动生成前缀列表 as48635-v4（含 2.57.56.0/22 与 5.157.80.0/21），在 policy-statement as6453-v4-out 中仅匹配该列表放行，其余拒绝。routing-options aggregate 下同时定义 discard 路由与 generate 默认路由，期望仅向对端 AS6453（TATA）宣告两个聚合前缀。然而 show route advertising-protocol bgp 80.231.152.77 输出显示，inet.0 表包含 909266 个目的地、3698169 条路由，除两个聚合外，更具体路由 5.157.80.0/21 后仍出现 5.157.80.0/ 等更长掩码条目，说明导出策略未生效。
僵尸路由观测现象：
现场抓取的 CLI 输出中，聚合路由 Next-hop 为 Self、标记 I（内部），而后续更具体路由同样出现在宣告列表中，且未被 reject term 过滤。IPv6 采用相同配置逻辑，结果完全一致，均出现僵尸路由。原文未给出具体数据说明受影响更具体路由的数量、掩码长度分布，或是否导致实际流量偏移。
可能成因与排查方向：
作者提示自身以 FRRouting 与 MikroTik 为主，对 JunOS 细节掌握有限。结合配置看，aggregate discard 与 generate 0.0.0.0/0 discard 可能与 RIB 安装顺序、策略求值时机存在交互；multipath multiple-as 与 remove-private all 是否改变了路由导出前的属性判断，原文未给出具体数据。建议依次核对：策略术语匹配顺序、aggregate 路由是否真正安装进转发表、BGP 导出是否在聚合生成前执行、是否存在隐式导出路径。
对运维工程师的启示：聚合策略看似正确，实测却可能因厂商实现差异泄露更具体路由。上线前必须用 advertising-protocol 实测验证导出列表，并对比 IPv4/IPv6 双栈行为；遇到僵尸路由时，优先排查策略求值顺序与聚合路由安装时序，避免依赖单一厂商经验造成盲区。
原文: APNIC Blog（2023-04-13）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog