摘要

  • 0.0.0.0/0 与 ::/0 不携带任何具体目的前缀，却能匹配最长前缀查找后剩下的全部地址。它不是全网可达性的知识，而是邻居对“其余部分”的转发承诺。
  • 默认路由的生成、出口许可、接收、入口许可、RIB 选优、FIB 下发与实际送达是七个不同状态。只看 BGP session 或 /0 存在，会把真实黑洞误报为稳定。
  • 领导者只有在邻居范围明确、健康条件贴合服务、接收方保有拒绝权、default-only 探针分散、撤回与回滚经过演练时，才应授权这种最后手段的委托。

先从接收方看一次故障。AS 64580 从区域运营商 AS 64520 接收一条 IPv4 默认路由。09:41，AS 64520 通向主要上游的传输中断；客户侧接口、EBGP session 和若干区域路由不受影响。因为 default-originate 没有附加条件，AS 64520 仍向客户发送 /0。

客户的控制面没有明显变化。session 是 Established，默认路由仍为 best path，硬件 FIB 仍指向同一个 next hop。监控探测运营商 loopback、本地 DNS 与两个更具体前缀，全部成功。其他目的地却沿 /0 进入 AS 64520，在缺失的上游出口前被丢弃。

这是一个合成场景，但每个动作都有真实协议与实现依据。默认路由没有伪造属性；邻居也没有违背 BGP session 的存活条件。错误在于组织把“仍然宣告最后手段”解释成“最后手段仍然可以完成承诺”。

零长度前缀如何获得最大剩余范围

RFC 1812 的转发选择先做匹配，再保留最长的前缀。198.51.100.0/24 只覆盖其中一个地址块；0.0.0.0/0 的前缀长度为零，因此对所有 IPv4 地址都成立，但会输给任何可用的更具体路由。IPv6 的 ::/0 同理。

所以 /0 从来不是“每个包都走这里”。它只负责 residual set，也就是本地表中没有更长匹配的目的地集合。这个集合不是固定清单。某条 /24 出现时，那部分地址离开默认路由的管辖；/24 撤回时，同一批地址又立刻落回 /0。默认路由的字节完全没变，实际控制面却扩张了。

这解释了它为何既轻又重。广告方只发布一个极薄声明；接收方则把自己当前没有更具体知识的全部目的地交给它。广告方决定是否发出广泛承诺，接收方的路由库存决定承诺在此刻到底覆盖多少流量。

RFC 4098 把 default route、default-free routing table 与 full default-free table 分开。前者是最后手段；后两者由更具体的 BGP 路由组成。接收默认、接收全表、接收默认加少量 specifics，是三种不同的信息量、设备成本与失败边界，不能都称作“有互联网路由”。

显式配置不是形式要求，而是权力边界

RFC 4632 把 0.0.0.0/0 称为退化的默认前缀，并要求实现能够接受它。紧接着，文档为跨域传播设置了限制：为了避免意外广告，只有显式配置后才应把默认路由发送给另一个 routing domain，绝不能把它当作无需配置就会自然出现的默认选项。

RFC 7454 给出关系层面的做法。除了特定 customer/provider 场景，通常不应接收或广告 IPv4、IPv6 默认路由，并建议在其他边界过滤。它也承认合理需求：资源较小的客户可能只向 provider 请求一条默认，而不接收全表。

两条规则共同说明，/0 不是禁用对象，也不是普遍许可。它是一项双方明确同意、按邻居限定的委托。客户需要它，不代表 provider 可以把它发给 peer、上游、IXP route server 或同一模板下的全部租户。一个地址族的许可，也不能自动扩展到另一个地址族或另一个 VRF。

出口方应精确列出哪些邻居可收默认；入口方应只允许来自已授权角色的 exact /0。两边都做过滤不是重复劳动，而是自治网络之间的双重控制：一方配置错误时，另一方仍能在本地拒绝。

RFC 8212 解决相邻问题：没有明确 import/export policy 时，EBGP 不应默默交换路由。但“policy 对象存在”不证明其语义正确。显式 route-map 仍可能向错误邻居放行默认，或让一个过时健康条件持续批准 /0。规则存在只证明没有落入空策略，不证明规则值得信任。

“默认路由还在”至少混合了七件事

一次可审计的故障不能只写“default was up”。首先，广告方生成候选默认。其次，出口策略允许它发给某一邻居。第三，接收方在 wire 上收到 UPDATE。第四，入口策略接受。第五，本地 BGP 在多个候选间选优。第六，routing system 把结果写入硬件 FIB。第七，包从 next hop 之后实际到达目的地。

这些状态可以任意错开。候选已生成但被 export filter 拒绝；UPDATE 已收到但被 import filter 拒绝；路由已接受却输给另一条默认；RIB 已选中而 FIB 尚未下发；FIB 已指向活跃接口，而邻居之后没有可用路径。

session 状态只是更早的一层。Established 说明双方仍在维持 BGP 控制通道，不说明 provider 的其他 transit、tunnel、策略或数据面健全。NEXT_HOP 可递归解析，也只说明本地知道下一跳在哪里，不说明下一跳能履行整个残余集合的转发责任。

撤回也不需要摧毁 session。RFC 4271 的 UPDATE 机制允许发送方撤回 /0，同时保留其他路由与邻接。接收方随后选择另一条默认，或者明确进入无路由状态。若运营工具只会 clear 整个邻居，便把一个路由承诺的失败扩大成全部控制面状态的丢失。

同名命令在不同系统上并不是同一契约

Cisco IOS 当前文档把 neighbor ... default-originate 定义为 per-neighbor 命令，并明确指出本机不需要存在 0.0.0.0。Nexus 文档进一步说明，这个人工生成的默认既不要求 routing table 中有 /0，也不必在本地 BGP RIB 建立该路由。可选 route-map 才能把广告与另一条已安装路由的存在联系起来。

FRRouting 文档采用另一项默认保护：即使 0.0.0.0/0 已在 routing table，BGP 默认也不会宣告它。运营者必须显式启用 neighbor default-originate，并可加 route-map 条件。

Junos 把问题放在 routing policy 模型中。BGP 默认出口的是活跃 BGP 路由；static、aggregate、generated 等显式配置路由需要 export policy 才能进入 BGP。其条件路由示例显示，active route state 与出口策略共同决定传播。

差异会直接改变故障结果。在人工 per-neighbor 模型中，删除本机 static /0 可能完全不影响无条件广告；在依赖 active generated route 的模型中，支持路由失活可能正是撤回触发器。把一台设备的 runbook 复制到另一平台，会让路由在工程师以为会撤回时继续存在，也可能在工程师以为独立时随本地路由一起消失。

因此，文档只能建立假设，运行测试才能建立事实。对当前软件版本逐项检查 local RIB、BGP RIB、advertised-routes 与对端 received-routes；移除支持条件但保持邻接；记录何时重新计算、何时发出 withdrawal、何时对端换路、何时 FIB 改变。恢复条件后再验证重新广告。没有这条证据链，命令名只是相似的文字。

健康条件是代理变量，不是承诺本身

给默认广告加条件通常是正确方向，却不是自动正确。条件只回答“这个 predicate 是否成立”。它是否能代表 /0 的服务，要由运营者另外证明。

provider loopback 可达，只证明一个 loopback 可达。static route 活跃，可能只证明配置仍在或递归仍能完成。full-table count 超过阈值，只证明数量不少，不证明选中的出口转发。interface up 只证明本地 carrier。BFD session 只验证某个对端与某条路径。任何一个都无法独自覆盖“所有当前未被更具体路由匹配的目的地”。

正确做法是从承诺反推证据。若 /0 代表公共互联网 transit，探测应跨独立网络、不同上游依赖与真实客户 egress；若它只代表私有 WAN 出口，就不应伪装成公共互联网健康测试。范围越窄，条件越能精确；范围越宽，单一信号越容易制造假绿灯。

多信号也包含政策选择。要求全部通过，可能因一个探针目标故障而撤掉仍有价值的最后路径；只要求一个通过，会让孤岛式可达掩盖大面积失败。quorum、hysteresis、hold-down 与恢复门槛决定谁承担误撤回和迟撤回的成本。它们不是中性参数。

条件必须保存历史。记录每个信号的变化时刻、组合判断何时翻转、默认何时撤回、对端何时改选、FIB 何时下发、包何时恢复。只保存事后稳定状态，会使一次真实黑洞在审计中消失。

AS_PATH 记录的是广告路径，不是万物路径

默认路由携带普通 BGP 属性。AS_PATH 描述 /0 这个 advertisement 如何传播，并参与 loop detection。NEXT_HOP 指示由该路由选中的包交给谁。LOCAL_PREF 等本地政策可在多条默认之间排序。

这些字段都没有列出残余集合内每个目的地的真实路径。AS_PATH 64520 不意味着所有地址都只隔一个 AS；它只意味着 AS 64520 发送了这条默认。其内部可能依赖多个 upstream、部分路由、隧道、过滤与控制器，UPDATE 没有揭示这些细节。

同样，两条默认不自动等于两份独立性。不同 router、不同 session 可能共用城域光纤、transit、route controller 或同一个探针条件。拔掉一条 session 的演练会成功，而真正的 common-mode failure 让两条默认继续存在、两条数据路径同时失效。

本地 preference 只表达接收方的决定。它不是实时健康评分。若运营者把商业主备顺序永久编码成高低 LOCAL_PREF，却没有把真实 failure state 连接到撤回或降级，那么“首选”在故障时仍会胜出。

更具体路由会从两个方向掩盖真相

在开场场景中，几个探针成功，是因为其目的地有存活的 more-specific，根本没有使用坏掉的 /0。如果监控目标集中在这些前缀，少数绿灯会遮住残余集合的大面积黑洞。

反方向也成立。一条健康默认无法救回坏掉的 /24，因为最长前缀先选更具体路由。误广告、陈旧或 next hop 失效的 /24 可以单独毁掉一个服务，其他互联网流量仍经 /0 正常。默认健康不应成为清除 more-specific 告警的理由。

每个包探针都应记录实际命中的 prefix、选中的 FIB next hop 与 egress。否则，通过结果可能验证了 /24，仪表盘却把功劳记在 /0 上。路由 churn 还会改变探针归属：specific 撤回时，目的地进入 default scope；specific 回来时又离开。默认记录没变，验证对象却变了。

泄漏 /0 等于未经授权转让剩余流量

从错误关系接受一条默认，会把接收方未知的所有目的地交给广告者。影响大小取决于本地表：有全表的 core 可能只剩很小 residual set；只收默认的小客户则可能转走几乎全部外部流量。

出口过滤应精确绑定客户清单，阻止 /0 到 peer、provider、route server 与无关租户。入口过滤应从授权邻居只接收 exact zero-length prefix，并在其他关系全部拒绝。过滤表达式需要审查，避免一个看似“最大长度为 0”的模板在平台语义或地址族转换中得到意外结果。

自动化放大了边界错误。peer-group inheritance、VRF 模板与双栈生成器可能一次把许可扩展到几十个邻居。必须同时审查 intended config 与 observed Adj-RIB-Out；对端 Adj-RIB-In 证明到达；外部 collector 只能发现部分逃逸。collector 没看到，不等于任何错误邻居都没收到。

证据链必须从承诺一直延伸到包

每个 default relationship 首先要写清服务语义：公共互联网 transit、选定外部服务、私有 WAN 出口，还是其他有限用途。然后记录 advertiser、receiver、AFI/SAFI、VRF、neighbor role、审批者与撤回责任人。

其次记录生成模型：无条件 synthetic、带条件的 neighbor 命令、static/generated route 加 export policy，或明确允许的再广告。保存 predicate 输入、quorum、timer、hysteresis 与失败行为。一个配置截图无法描述运行状态机。

运行时要保留 candidate route、post-policy advertisement、对端 pre-policy 与 accepted view、best-path 原因、RIB、recursive next hop 和 hardware FIB，并给每次变更加时间戳。同时记录竞争默认与探针使用的 more-specific。

包探针必须从接收方发起，因为委托在那里转化为实际 forwarding。至少一组目的地只能通过 /0 到达，并跨多个独立网络；另一组明确由 more-specific 覆盖，用来验证最长前缀边界。结果要带选路证据，不能只存 HTTP 成功码。

故障演练要保留 customer-facing BGP session，同时切断真正支撑默认的上游条件。分别测量 predicate failure、withdrawal、alternate RIB selection、FIB programming 与 packet recovery。没有 alternate 时，也要证明客户停止把包送入已死 provider，而不是持续静默黑洞。

回滚是整个契约，不是恢复一行命令。它应一起恢复生成方式、predicate、timer、邻居范围、属性、客户 import preference、探针与告警阈值。配置看似恢复而包仍经旧 next hop，不算回滚完成。

最小协调必须保留本地退出权

默认路由体现了极薄的跨域协调：双方不共享每个目的地的完整图谱，provider 发布一个压缩承诺，customer 在本地自愿把它作为 fallback。这可以降低状态、设备负担与策略复杂度。

但信息越少，越不能制造额外权威。“provider”标签不证明运行路径，“已接收”不代表永远同意，“session up”不代表服务完整。接收方始终保留拒绝、降级或改选权；广告方必须在证据失效时撤回；双方都不需要一个中心机构替它们判断当前包是否能走通。

Running-Code Primacy 决定证据顺序。合同说明预期，配置说明意图，UPDATE 证明发送，RIB/FIB 证明本地行动，包才检验运行结果。每一层都重要，但没有一层可以冒充下一层。