pjhtech Tools
Juniper · Junos OS

Junos Firewall Filter Counters and Packet-Drop Checks

Quick answer #

Use show firewall to discover instantiated filters and counters, then show firewall filter CUSTOMER-IN for the relevant filter. A zero counter does not by itself prove that traffic is absent: the filter attachment, term order, address family and exact match conditions all matter.

Scope: Junos OS stateless firewall filters on MX and supported EX/QFX features. Hardware counters vary. SRX security policy/session counters are a separate subsystem and are not replaced by these commands.

Commands #

Read-only operational commands for an existing IPv4 filter:

Commands
Junos OS · Operational CLI

Read-only
show firewall
Read-only

Replace these example values: CUSTOMER-IN.

show firewall filter CUSTOMER-IN
Read-only

Replace these example values: ge-0/0/0.0.

show interfaces ge-0/0/0.0 extensive
Read-only

Replace these example values: ge-0/0/0.

show configuration interfaces ge-0/0/0 | display set
Output may contain sensitive operational data.
Read-only

Replace these example values: CUSTOMER-IN.

show configuration firewall family inet filter CUSTOMER-IN
Output may contain sensitive operational data.

Use the actual instantiated name reported by show firewall. For IPv6, inspect family inet6; for Ethernet switching, inspect the applicable platform's Layer 2 filter configuration. Do not assume an IPv4 filter can count all traffic on a physical port.

What the counters mean #

Configured term counters expose matching packet and byte totals. A term without an explicit counter does not automatically gain a uniquely named hit counter merely because it exists. Read the term's action as well as its number: a rising count is not synonymous with a discard.

Policer statistics describe a different condition from ordinary term matches. Determine what the platform counts and which out-of-profile action is configured before labeling the value as packets dropped. Packet treatment and accounting details can vary by hardware and filter feature.

Interface-specific filters can create separate runtime filter instances for different interfaces and directions. This is why finding the instantiated name first is safer than guessing a name from the configuration. Verify the input or output attachment on the relevant logical interface.

Workflow for a suspected filter problem #

Write down a single test flow: source, destination, protocol, ports and direction. Save the baseline counters. Generate a controlled test, then read the same counters again. Compare the increase against the term conditions and any earlier terminating term. Confirm that routing actually sends the flow through the interface being observed.

Keep the test narrow enough to distinguish the flow from unrelated production traffic. If one counter covers an entire customer subnet, a rising total alone cannot attribute the result to one TCP connection.

Pitfalls #

Do not clear all firewall counters during an incident without first preserving evidence and coordinating with monitoring owners. Do not attach a new diagnostic filter by overwriting an existing production filter. On SRX, a stateless counter is not a substitute for checking security policy and sessions. An allowed packet at one observation point can still be discarded later.

Continue with #

Junos Route Lookup and VRF Routing Table Commands verifies the route to the observed interface; Junos Interface Errors and Optical Power Commands distinguishes interface errors from filter behavior. Use Junos Compare, Commit Confirmed and Rollback Reference before implementing an approved filter change, and CIDR tools to check prefix matches.

Sources

Documentation reviewed: 8 October 2026