A cooperative's NOC is troubleshooting a suspected DDoS-style flood aimed at a POP router and wants to see, in near real time, how much traffic each firewall-filter term is matching without disrupting the accept and discard decisions already configured. Which action should be added to the terms of interest to provide this visibility?

The count action in a Junos firewall-filter term increments a named counter every time a packet matches that term, and because it is non-terminating, it can be added alongside an existing terminating action like accept or discard without changing the term's actual forwarding decision. This gives the NOC exactly the visibility requested: 'show firewall filter <name>' reveals per-term packet and byte counts, useful for confirming which terms are absorbing the suspected flood traffic in near real time. Replacing the existing action with reject would change the term's behavior — it would start actively dropping and notifying on matched traffic instead of preserving whatever accept or discard decision was already configured, which is the opposite of the non-disruptive visibility being asked for, and reject's notifications could also assist an attacker in confirming the filter's presence. A routing policy logging route changes addresses an entirely different layer — routing-table churn — and would tell the NOC nothing about packet-level traffic volume hitting a firewall-filter term. A static route with a lower preference redirects traffic path selection for routed destinations; it does not measure how much traffic a filter term is matching and could also unpredictably reroute legitimate traffic during an active incident. Adding count terms is a standard first troubleshooting step precisely because it is additive and non-disruptive. To use it, the NOC would add count <name> to each term of interest, then poll 'show firewall filter <name>' repeatedly to watch which counters climb fastest during the suspected flood.