NX-OS EVPN 空路由：把丢弃留在一个租户内

需求往往只有一行：把某个地址黑洞掉。你在租户上下文中加一条指向 Null0 的主机路由，前缀如期从本地表消失，问题随之而来：路由离开设备了吗？远端 VTEP 是丢掉了，还是仅仅不可达？第二个租户是否已被牵连？

正确的本地静态路由只回答第一个问题，所以一次黑洞变更其实是三个需要分别复核的结果，而不是一条命令。

变更究竟要产出什么

先把三个结果写下来。目标租户必须在本地丢弃该目的地。只允许导出被授权的那条路由，不能夹带别的前缀。每台接收端 VTEP 必须选中预期的丢弃动作，而不是改走别的路径。

每个结果各有证据，彼此不能相互替代。本地 Null0 路由产生本地丢弃，但若不做重分发，它什么也不会导出。重分发出去却不带约定 community 的路由会以普通前缀到达并被转发。带了 community 而接收端没有相应策略，则可能被完全忽略。

先把结果写下来，还能防住一种常见误判：目标地址早就因为无关原因不可达，于是变更看上去生效了。如果你描述不出如何区分这两种情况，验收测试就还没设计好。

在 10.4(x) 系列的 NX-OS 中，空路由位于租户的 VRF 上下文里，而不是写在一条点名 VRF 的命令中。片段很短，但它绝不是一份完整的 EVPN 配置。

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

这个地址是文档用前缀，不是真实目标。注意它与 IOS 的语法差异：在 IOS 里 VRF 名写在路由命令内部。粘贴任何内容之前，先确认你实际运行的版本支持哪种写法。

单看这一行，它只丢弃 TENANT_A 内去往该主机的流量，别的什么都不做。它不给路由打标签，不为 BGP 选中它，也不设置 community。这些都是彼此独立的配置决策，每一处都可能让变更要么窄到不生效，要么宽到不安全。

本地丢弃也会影响去往同一目的地的正常流量。如果本意是拦住一个滥用来源，而真实用户仍需要这个地址，那空路由就是错误的工具，第一个支持电话就会让你明白这一点。

范围由重分发决定。把可导出的前缀限定在获批的处置范围内，把它留在租户内，并把起源 peer 限制在设计之内。为了运走一条打了标签的主机路由就重分发所有静态路由，正是把维护变更变成路由事故的典型路径。

BLACKHOLE community 是对一个公认取值的约定，并不是允许任何邻居丢弃任何地址的授权。RFC 7999 正是这样描述的；谁能发布它，这条信任边界属于设计的一部分，而不是实现细节。

接收侧需要自己的配置。在 NX-OS 上，Type 5 空路由需要 VTEP 侧用 route-map 处理才能选中丢弃行为，这一点与导出步骤一起有文档记载。发送端标签打对了，接收端却忽略标签，结果就是变更看起来已下发，流量照旧被转发。

既然人在现场，就顺手复核 route-map 的副作用。新收紧的策略可能压掉无关前缀的正常可达性，而这种损害比黑洞本身出现得更晚，也更难归因。

在改动任何配置之前，记录目的地的归属人、原因、审批人和到期时间。没有到期时间的丢弃会变成一条无人记得来历的永久条目，下一个排查该地址的人会把它当成网络的正常组成部分。

保留一条不依赖你所改路由的独立管理通道。如果处置范围覆盖了你用来登录设备的地址，那就是给自己加了几步的自锁。

写清楚解除处置的确切操作，并在实验室或你能承受的时间窗里演练这次解除。没人演练过的撤回只是计划，不是流程。

在预期的 VTEP 上检查选中的路由状态与转发状态，同时检查一个必须不受影响的邻近目的地。确认没有其他租户导入该前缀，因为跨租户泄漏正是把维护动作变成事故的那种失败模式。

然后撤回，并确认正常路由与业务恢复。关于 NX-OS EVPN 空路由指南（面向 10.4(x) 版本）记录了本文所述打标签、重分发与接收策略，也是对照你自己所用版本时应当查阅的参考。