NX-OS EVPN null route: keep the discard inside one tenant

The request arrives as a one-line change: blackhole one address. You add a host route to Null0 inside the tenant context, the prefix disappears from the local table as expected, and then the questions start. Did the route leave the box? Did the far VTEPs discard, or did they simply lose reachability? Is a second tenant now affected?

A correct local static route answers only the first of those, which is why a blackhole change is really three reviewed outcomes rather than one command.

What the change actually has to produce

Start by writing the three outcomes down. The intended tenant must discard the destination locally. Only the authorized route may be exported, with nothing else riding along. Every receiving VTEP must select the intended discard action rather than a different path.

Each outcome has its own evidence, and none of them implies the others. A local Null0 route produces local discard and, without redistribution, exports nothing at all. A redistributed route without the agreed community arrives as an ordinary prefix and gets forwarded. A community without the receiving policy may be ignored entirely.

Writing the outcomes first also protects you from a common failure: a change that appears to work because the destination was already unreachable for an unrelated reason. If you cannot describe how you would tell the difference, the acceptance test is not yet designed.

The local statement only does the first part

For NX-OS in the 10.4(x) train, the null route sits inside the tenant's VRF context rather than in a single command that names the VRF. The fragment is short, and it is emphatically not a complete EVPN configuration.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

The address is a documentation prefix, not a target. Note the syntax difference from IOS, where the VRF name appears inside the route command itself, and confirm the supported form for the release you actually run before pasting anything.

On its own this line discards traffic for that host inside TENANT_A and does nothing else. It does not tag the route, does not select it for BGP, and does not set a community. Those are separate configuration decisions, and each one is a place where the change can be either too narrow to work or too broad to be safe.

The local discard also affects legitimate traffic to the same destination. If the intent is to stop one abusing source while real users still need the address, a null route is the wrong tool and you will learn that from the first support call.

Export and import are separate agreements

Redistribution is where scope is decided. Restrict the eligible prefixes to the approved mitigation, keep it inside the tenant, and limit the originating peers to those in the design. Redistributing every static route because one tagged host route needs to travel is how a maintenance change becomes a routing incident.

The BLACKHOLE community is an agreement about a well-known value, not an authorization for any neighbour to discard any address. RFC 7999 describes it in those terms, and the trust boundary around who may advertise it is part of the design rather than an implementation detail.

The receiving side needs its own configuration. On NX-OS, Type 5 null routes require route-map treatment at the VTEP to select the discard behaviour, which is documented alongside the export steps. A sending device that tags correctly and a receiver that ignores the tag produce a change that looks applied and forwards traffic anyway.

Review the route-map for side effects while you are there. A newly restrictive policy can suppress legitimate reachability for unrelated prefixes, and that damage appears later than the blackhole and is harder to attribute to it.

Write the withdrawal before the insertion

Record the destination owner, the reason, the approver and an expiry before anything is configured. A discard with no expiry becomes a permanent entry whose origin nobody remembers, and the next person to debug the address will treat it as a normal part of the network.

Keep an independent management path that does not depend on the route you are changing. If the mitigation covers an address you use to reach the device, you have created a lockout with extra steps.

Name the exact control that removes the mitigation, and test that removal in a lab or during a window where you can afford it. Withdrawal that nobody has rehearsed is a plan rather than a procedure.

Accept with evidence, not with the command output

Check the selected routing state and the forwarding state at the intended VTEPs, and check a neighbouring destination that must remain unaffected. Confirm that no other tenant imported the prefix, because cross-tenant leakage is the failure mode that turns a maintenance action into an incident.

Then withdraw and verify that the normal route and the service return. The NX-OS EVPN null-route guide for the 10.4(x) release documents the tagging, redistribution and receiving policy described here, and it is the reference to check against your own release.