Parks HQ wants guest-subnet traffic forced through a firewall path while staff traffic continues to follow normal destination routing. Which tool fits that selective steering use-case?

Parks HQ wants guest-subnet traffic forced through a firewall path while staff traffic continues on normal destination routing. Policy-Based Routing that matches the guest subnet and sets the firewall next hop fits that selective steering use-case: only matched guest packets take the firewall path; unmatched staff flows keep using the RIB. PBR therefore implements policy exception without redesigning every civic route for staff users.

BPDU Filter on the firewall outside interface only manipulates STP BPDU behavior; it does not match guest subnets or set Layer-3 next hops. Changing the native VLAN on every access port citywide is a broad L2 change that does not selectively steer guest packets to a firewall next hop and risks VLAN mismatches. Disabling the RIB so no routes exist for staff users breaks staff forwarding entirely rather than preserving normal destination routing for them.

Exam caveat: PBR match criteria must be accurate (ACL/prefix for guest only), and the firewall next hop must be reachable from the PBR router. Unmatched traffic should fall through to destination-based routing—that is a feature for the staff path, not a failure. ENCOR contrasts PBR with pure RIB forwarding; it is not an STP tool and not a reason to delete the RIB.

Operational check: classify guest vs staff source subnets, apply PBR on the parks ingress interface facing those users, and traceroute/pcap both classes. Guest should hairpin toward the firewall path; staff should follow OSPF/BGP RIB exits. Watch counters on the PBR ACL and firewall interface to ensure policy hits match expected guest volume and that staff never matches the guest ACL by accident.