A school district WAN team applies PBR with set ip next-hop for selected student-portal traffic on an IOS XE border. What should verification focus on?
Select an answer to reveal the explanation.
Short Explanation
PBR only works if it hangs on the door where the packets walk in. Check the ingress interface, confirm matches take the set next hop, and make sure everyone else still follows the normal map.
Full Explanation
Verification for the school district’s PBR with set ip next-hop must prove three things: the policy route-map is attached to the correct ingress interface, matched student-portal packets use the configured next hop, and unmatched traffic still follows the destination RIB. PBR only classifies packets where the ip policy route-map is applied; wrong interface placement is a common miss. Operational checks should include show ip policy, show route-map, and targeted traceroute/debugs for match versus non-match flows—not unrelated BGP or EIGRP side effects.
Stripping BGP communities from every student-portal prefix is unrelated to whether PBR is steering packets and does not verify set ip next-hop behavior. PBR should not delete the primary default from the global RIB; if the default disappeared, that is a separate routing change, not successful PBR verification. Clearing EIGRP feasible successors so PBR can “install statics” misunderstands PBR—PBR does not require emptying the EIGRP topology to function and does not install ordinary statics in place of the policy.
Exam caveat: confirm CEF is enabled as expected for PBR performance, and distinguish policy counters incrementing from actual next-hop usability. If the next hop is down, fallback behavior depends on set ip next-hop versus default-next-hop constructs.
Operational check: generate student-portal traffic and a control flow from another subnet; confirm only matches show the alternate next hop in path tracing while show ip route remains unchanged for normal destinations. Document the ingress interface and ACL hits before closing the change window.