An assessor’s office uses PBR with set ip next-hop toward a preferred exit. When that next hop becomes unreachable, what is the typical default behavior for matched packets?
Select an answer to reveal the explanation.
Short Explanation
When the preferred exit is unavailable, you can expect ordinary set ip next-hop PBR to fall back to the regular destination-based route lookup. That usually keeps matched traffic from being trapped just because the policy next hop failed.
Full Explanation
With ordinary set ip next-hop PBR, when the configured next hop becomes unreachable, IOS typically falls back to the normal destination-based RIB lookup for matched packets. This differs from set ip default-next-hop style constructs, which apply when the RIB lacks an explicit route; knowing which set clause is used is essential to predicting failure behavior. The claim that matched packets are normally dropped until an operator clears the route-map is wrong: next-hop loss alone does not cause that permanent drop, because fallback to the RIB is the usual outcome. PBR also does not convert its entry into a /32 static host route in every VRF when the next hop fails; that is not a side effect of PBR. Nor does OSPF originate a Type-5 external for the policy ACL: PBR controls forwarding and does not redistribute the ACL into OSPF. Exam caveat: read the exact set command, because set ip next-hop verify-availability or object tracking can affect when a hop is considered valid, while set ip default next-hop engages only if no specific RIB route exists. Practical check: shut the preferred exit or withdraw its next hop, send matching traffic, and confirm it follows the route selected by show ip route rather than blackholing; restore the hop and verify policy steering returns. Document whether tracking is in use so on-call engineers know the expected fail-open behavior.