Junos monitor traffic: Packet Capture Examples

Junos offers two complementary ways to capture packets. The quick one is monitor traffic interface, a tcpdump-style operational command that prints packets to the screen or saves them to a file with no configuration change. The persistent one is the forwarding-options packet-capture mechanism: you define a firewall filter with a sample action, apply it to the interface, and Junos writes matching traffic to a pcap file you can pull off the box and open in Wireshark. This guide shows both approaches with real command examples on SRX and EX/QFX platforms.

The two methods solve different problems, and choosing wrongly wastes time. monitor traffic is for the question "what is on this wire right now?" — it is interactive, terminates when you press Ctrl-C, and costs you nothing to run because it needs no configuration. The firewall-filter sampler is for "catch this every time it happens, including at 03:00 when nobody is watching", because it stays armed across commits and writes to disk. Most investigations start with the first and graduate to the second.

Quick Capture with monitor traffic

Run from operational mode; Ctrl-C stops the capture. Add a quoted tcpdump-style expression to narrow the traffic:

user@host> monitor traffic interface ge-0/0/0
user@host> monitor traffic interface ge-0/0/0 size 1500 count 20
user@host> monitor traffic interface ge-0/0/0 "icmp"
user@host> monitor traffic interface ge-0/0/0 "host 172.16.1.1 and tcp port 443"

Be aware of two Junos limitations: the monitor traffic command cannot apply match conditions to inbound traffic, and on the interface form, Layer 3 and Layer 4 match conditions (the | match pipe) are not supported. Both limitations come from where the filter is attached in the packet path: the capture is taken as close to the wire as practical, so by the time Junos could evaluate a rich expression it has already forwarded or dropped the packet.

The options you will actually use most often are size (bytes captured per packet, raising it above the default shows more payload), count (stop after N packets, useful for scripts), no-resolve (do not turn addresses into names, which keeps a slow DNS server from stalling the output), write-file (stream to a file instead of the terminal) and detail for a summary view. A practical session on a busy uplink looks like this:

user@host> monitor traffic interface ge-0/0/24 no-resolve count 200
user@host> monitor traffic interface ge-0/0/24 "tcp port 179" size 200
user@host> monitor traffic interface ge-0/0/24 "host 172.16.1.1 and host 172.16.2.1"
user@host> monitor traffic interface ae0.100 "vlan 100"

Two cautions. First, monitor traffic is not free: on a line-rate uplink the output can flood your SSH session and consume CPU, which is exactly when you least want to add load. Use count and a narrow filter. Second, the capture reflects what the interface sees at the point of attachment, so on an aggregate interface (ae0) you capture the member link's view unless you target the logical unit. If your filter returns nothing, verify you are watching the interface you think you are watching with show interfaces terse before concluding the traffic is absent.

Persistent Capture with forwarding-options packet-capture

Configure the capture file, define a firewall filter that samples only the traffic you care about, and apply it to the interface. The following SRX example captures ICMP between 172.16.1.1 and 172.16.2.1 only:

[edit forwarding-options packet-capture]
user@host# set file filename CAPTURE1

[edit firewall]
user@host# set filter CAPTURE_FILTER term 1 from source-address 172.16.1.1/32
user@host# set filter CAPTURE_FILTER term 1 from destination-address 172.16.2.1/32
user@host# set filter CAPTURE_FILTER term 1 from protocol icmp
user@host# set filter CAPTURE_FILTER term 1 then count COUNT1
user@host# set filter CAPTURE_FILTER term 1 then sample
user@host# set filter CAPTURE_FILTER term 2 then accept

[edit interfaces ge-0/0/0 unit 0 family inet]
user@host# set filter input CAPTURE_FILTER

The structure rewards a careful read, because the accept in term 2 is not decoration. A firewall filter ends with an implicit discard, so if term 1 samples and then falls through, and no later term accepts, every packet that matched the capture condition is silently dropped — you have built a traffic black hole that also happens to produce a capture file. Always terminate a sampling filter with an explicit accept, and test with a small count first so you can see whether packets are being matched before you trust the capture.

The sample action copies the packet to the packet-capture process rather than diverting it, so production traffic is unaffected. That is the property that makes this safe to leave configured during an intermittent fault.

Commit, generate the traffic you want to catch, then check the packet counter and locate the capture file. Junos appends the interface name to the filename:

user@host> show firewall
Filter: CAPTURE_FILTER
Counters:
Name      Bytes    Packets
COUNT1    420      5

user@host> file list /var/tmp
/var/tmp/CAPTURE1.ge-0/0/0

Reading that output correctly is most of the diagnosis. A counter of 420 bytes over 5 packets is roughly 84 bytes per packet, which is consistent with ICMP — a useful sanity check that your match conditions are catching what you intended and not an accidental stream of ARP. If the counter stays at zero, the filter is not matching; check the term order, the address mask (/32 versus a subnet) and whether the traffic is actually passing the interface where the filter is applied. Remember that an input filter only sees traffic arriving on that interface, so a capture applied in the wrong direction produces a perfectly valid, perfectly empty file.

Choosing Scope: Filters, Terms and Direction

Real troubleshooting rarely needs a broad capture. Narrow the filter to the conversation in question and add terms for each hypothesis you want to test separately, so the counters tell you which case is happening rather than just "some traffic matched":

set firewall filter TRACE term tcp-syn from protocol tcp
set firewall filter TRACE term tcp-syn from tcp-flags "syn&!ack"
set firewall filter TRACE term tcp-syn then count SYN_COUNT
set firewall filter TRACE term tcp-syn then sample
set firewall filter TRACE term tcp-rst from protocol tcp
set firewall filter TRACE term tcp-rst from tcp-flags rst
set firewall filter TRACE term tcp-rst then count RST_COUNT
set firewall filter TRACE term tcp-rst then sample
set firewall filter TRACE term else then accept

With separate counters for SYN and RST you can distinguish "the server never answered" from "the server actively refused" by reading two numbers instead of opening Wireshark at all. That is usually the fastest path to a conclusion, and the pcap becomes confirmation rather than exploration. The same terms and actions are documented in detail in our Junos firewall filter reference for terms, match conditions and actions.

Pulling the Capture File and Analyzing It

Copy the file to a workstation over scp and open it in Wireshark:

user@host> file copy /var/tmp/CAPTURE1.ge-0/0/0 scp://user@192.168.200.10/tmp/

Slash characters in the interface suffix are legal in a Junos filename but awkward in shell pipelines, so quote the path when you script the copy. The capture file is a standard pcap, which means the same analysis workflow documented for any other capture source applies: open the file, apply a display filter, and follow the TCP or ICMP stream rather than reading packet by packet. The display-filter syntax that makes a thousand-packet file readable in seconds is covered in our related Wireshark article, and the same expressions you would use with tcpdump translate directly to the ones accepted by monitor traffic.

Capacity, Performance and Safety Notes

A sampler is not free, and on an ASR-class or high-density EX platform the cost is visible in the control-plane CPU graph rather than in throughput. The mechanism copies matching packets to the packet-capture process, which then writes them to flash. Two consequences follow. First, the wider your match conditions, the more CPU you spend copying; a filter that samples every packet on a 10G uplink is qualitatively different from one that samples ICMP between two hosts. Second, every captured packet consumes both memory and flash, so an unattended capture on a busy link can fill /var/tmp and, on smaller platforms, the root filesystem. Check free space before you leave a capture armed overnight:

user@host> show system storage
user@host> file list /var/tmp
user@host> show firewall

On SRX platforms the packet-capture process also competes with session setup for CPU, so if you are chasing a performance problem rather than a reachability problem, prefer sampling on a single term with a narrow address pair. When the goal is throughput analysis rather than fault isolation, a flow-based exporter such as sFlow, NetFlow or IPFIX gives you aggregate statistics for a fraction of the overhead, and packet-level capture is the wrong tool.

Two more practical details. If the device is managed in a Virtual Chassis or an SRX cluster, remember that you must apply the filter on the specific member or node that sees the traffic; the capture file also lands on that member, so file list on the master may show nothing at all. And if the traffic you are trying to catch is itself being dropped by a security policy further down the path, the sampler still records it, because the sample action runs on ingress before the session is evaluated — a useful property when the question is "does the packet even arrive?"

Disabling the Capture When You Are Done

Remember to disable the capture when you are done — leaving packet capture running on a busy interface costs CPU:

[edit forwarding-options]
user@host# set packet-capture disable

A cleaner approach is to remove the whole block and the filter reference in one commit, so the interface returns to a plain forwarding path with no allocation attached:

delete forwarding-options packet-capture
delete interfaces ge-0/0/0 unit 0 family inet filter input
delete firewall filter CAPTURE_FILTER
commit
show firewall

Finally, confirm the capture really stopped by checking that no file is still growing, and delete the pcap from /var/tmp once you have copied it off. Files left on the device consume flash on small SRX and EX platforms, and a full filesystem causes commit failures long after anyone remembers the capture.

Which Method Should You Reach For?

• Live, right now, no config change, you are watching the screen: monitor traffic interface with count and a quoted expression.
• Intermittent fault, overnight, evidence needed later: firewall filter with count + sample, pcap retrieved with file copy.
• You need a hardware copy of the traffic in parallel, not per-packet: port mirroring to an analyser port instead of a per-packet sampler.
• You need to see what a router itself generated: traceoptions or, on Genie-capable platforms, capture on the logical interface the traffic leaves from.

Related Articles

Pair packet capture with our Junos monitor interface guide for real-time traffic, the tcpdump filters guide, and the Wireshark capture versus display filters article. If you are working on IOS-XE equipment in the same network, the equivalent workflow is the embedded packet capture runbook.

原文链接：https://rayka-co.com/lesson/junos-packet-capture-configuration-example