An engineer adds an FBF term to steer finance-subnet traffic, yet counters show an earlier accept term always hits first. What principle explains why the FBF action never applies?
Select an answer to reveal the explanation.
Short Explanation
Filters read top to bottom like a checklist—first match wins. If an early accept already grabbed the finance packets, the later FBF term never gets a turn. Reorder or tighten matches so steering happens before the catch-all.
Full Explanation
When an engineer adds an FBF term to steer finance-subnet traffic yet counters show an earlier accept term always hits first, the principle that explains why the FBF action never applies is that firewall filter terms are evaluated in order, so an earlier matching term can shadow a later FBF term. Junos applies the first matching term’s action and stops, which means a broad accept ahead of a specific routing-instance action permanently prevents finance steering on that civic leaf. FBF terms do not always evaluate before accept terms regardless of configuration order; order in the filter is authoritative. Term order is not ignored when the filter is attached to an IRB—attachment point does not suspend sequential evaluation. It is also false that only the last term in a filter can ever match, so earlier accepts are irrelevant; earlier matches are exactly what shadow later FBF terms. Exam caveat: treat filter term order as a first-class troubleshooting axis whenever municipal FBF appears configured but never hits. Operational check: show filter counters on the finance leaf, identify the earlier accept that consumes the traffic, reorder or narrow that term, commit, and confirm the FBF term’s hit count and routing-instance action finally increment for finance test flows.