A township wants selected agency traffic forced out a specific DCI path rather than the default tenant exit. How can filter-based forwarding support that traffic-engineering goal?
Select an answer to reveal the explanation.
Short Explanation
FBF is a policy on-ramp: match the agency flows and hand them a routing instance whose next hop is the DCI exit you want. Throwing away Type-5 routes or discarding traffic is not engineering—it is breaking reachability.
Full Explanation
When a township wants selected agency traffic forced out a specific DCI path rather than the default tenant exit, filter-based forwarding can support that traffic-engineering goal by matching the agency traffic in a filter and selecting an alternate next-hop or routing instance that exits via the desired DCI path. The match isolates the civic flows that need the special interconnect, and the FBF action places them in a forwarding context whose routes point at the preferred border or DCI handoff. Deleting all Type-5 routes so only underlay defaults remain is a blunt withdrawal that breaks overlay L3 services rather than surgically steering one agency. Converting every leaf to CRB so DCI selection becomes automatic confuses fabric gateway placement with per-flow DCI engineering and does not replace an FBF match-and-redirect. Matching agency prefixes or ports and discarding them until operators pick a path manually denies service instead of engineering an exit. Exam caveat: FBF is a valid describe-level tool for policy-based exit or DCI selection when alternate routing instances or next-hop contexts exist. Operational check: define the DCI-bound routing instance with the preferred border routes, apply an FBF filter matching the agency prefixes, generate test traffic, and verify traceroute or border counters show the forced DCI path while other agencies retain the default tenant exit.