An engineer configures a static route for a decommissioned subnet at a co-op's head-end and wants the router to actively notify any sender that the destination is unreachable, rather than dropping packets without a trace. Which next-hop keyword accomplishes this?
Select an answer to reveal the explanation.
Short Explanation
Reject is the polite bouncer: it still turns traffic away at the door, but it actually tells the sender why, firing back an ICMP destination-unreachable message. That feedback is exactly what makes troubleshooting for the sender faster instead of leaving them guessing.
Full Explanation
The reject next-hop option drops matched packets and generates an ICMP destination-unreachable message back toward the source, giving the sender explicit, immediate feedback that the destination isn't reachable. This is the better choice than a silent drop whenever visibility into the failure matters — for instance, so a sending host's application fails fast with a clear error instead of timing out. discard achieves the drop but deliberately withholds that notification, which is the opposite of what's being asked for here. A qualified next-hop toward the backup transit provider wouldn't reject anything — it would actually forward the traffic somewhere live, which contradicts the goal of signaling that the subnet is gone. There's no standard 'next-hop of none' construct in Junos static route configuration; an unconfigured or unresolved next-hop simply leaves the route unusable rather than producing a deliberate, informative reject behavior. The operational nuance worth remembering: reject generates real ICMP traffic, so under a large-scale abuse scenario it could itself add load, which is one reason engineers sometimes prefer discard instead. A concrete check is a traceroute from the sending side, which will show the rejecting router as the point where the path terminates with an unreachable response.