Junos monitor interface: Real-Time Traffic Monitoring

2026年8月29日 LOG admin

When a link starts flapping or a port silently drops errors, monitor interface is the Junos command that shows you what is happening right now — updated every second. Unlike show interfaces, which gives a snapshot, the monitor view tracks delta counters as they change, making it the fastest way to watch a fault develop in real time on EX, QFX and MX platforms.

What monitor interface Does

It displays real-time statistics about interfaces, refreshing every second, and checks for common failures: SONET/SDH and T3 alarms, detected loopbacks, and increases in framing errors. On Junos OS Evolved the command works over SSH sessions, while console and Telnet sessions are not supported.

Because the screen refreshes once per second, the counters it prints are deltas — the number of bytes, packets or errors that accumulated since the previous refresh — rather than the totals you would see in a show command. That is the whole point: a total of 4,000 input errors tells you the link has been unhealthy for a long time, while a delta of 60 input errors per second tells you the link is broken right now and that you should keep watching.

Starting a Monitoring Session

user@router> monitor interface ge-0/0/1

Watch the Input errors, Framing errors and L2 incompletes columns. On a healthy link these stay at zero; a climbing counter under load indicates a physical-layer problem (bad optics, marginal cable, duplex mismatch) rather than a routing issue.

The session opens with a key legend at the top of the screen, and the interface header underneath it. A typical non-Evolved platform looks like this:

Next='n', Quit='q' or ESC, Freeze='f', Thaw='t', Clear='c', Interface='i'

Interface: ge-0/0/1, Enabled, Link is Up
Encapsulation: Ethernet, Speed: 1000mbps
Traffic statistics:                                   Current delta
  Input bytes:                1145556691 (6352 bps)            794
  Output bytes:               2297817461 (6352 bps)            794
  Input packets:                 3715744 (7 pps)                 1
  Output packets:                3753052 (7 pps)                 1
Error statistics:
  Input errors:                        0                        0
  Input drops:                         0                        0
  Framing errors:                      0                        0
  Input discards:                      0                        0
  L2 channel errors:                   0                        0
  L2 mismatch timeouts:                0                        0
  Fifo errors:                         0                        0
  Resource errors:                     0                        0
Output errors:
  Carrier transitions:                 1                        0
  Output errors:                       0                        0

To monitor every interface at once, run the command without an argument. On a switch with dozens of ports the session pages through them, and you can jump to a specific interface from inside the session with the key shown in the legend.

user@switch> monitor interface

Live Delta Counters with the Traffic View

The traffic variant shows byte and packet rates with delta counters since the session started, letting you quantify throughput per interface during maintenance windows:

user@switch> monitor interface traffic
Interface    Link  Input packets        (pps)     Output packets        (pps) Description
ge-0/0/1       Up      392172          (0)             392187          (0)
ge-0/0/22      Up      392169          (0)             392184          (1)

Press c to zero the delta counters mid-session (accumulative counters are untouched — clear those with clear interfaces interval, or with the documented clear interfaces statistics form on recent releases), and p to switch interfaces without restarting the monitor. The on-screen legend printed when the session starts is authoritative for your release — some Junos versions bind the interface key to i rather than p, and the generic keys (n for next, f to freeze the display, t to thaw it, q or ESC to quit) are consistent across the traffic and per-interface views.

The traffic view is the tool of choice for three jobs: proving that traffic is actually flowing during a cutover, checking whether an interface is unbalanced in an aggregated Ethernet bundle, and watching for the momentary zero that reveals a micro-flap seconds before the link goes down.

What the Error Columns Mean

Input errors — the aggregate of receive-side physical problems: CRC errors, frame errors and runt/giant frames. It climbing at the same rate as traffic is the classic signature of a duplex mismatch or a damaged cable.
Framing errors — the receiver cannot align the frame to valid symbol boundaries. On fibre this usually means a dirty connector, a bad optic or an over-driven link budget; on copper it points to a duplex or speed mismatch.
L2 incompletes — frames that were cut short, typically tagged with a physical coding sublayer (PCS) error such as a bad interpacket gap or an FCS failure.
Input drops and discards — packets arrived correctly but were dropped internally, usually because of a policer or a full buffer, not a cable fault.
Carrier transitions — how many times the link state changed. A non-zero delta here means the interface is flapping; fix the physical layer before investigating anything else.
Output errors — transmit-side failures, frequently an MTU or encapsulation problem rather than a fault in the optic.

Common Fault Patterns and What to Do

Carrier transitions climbing, everything else zero. The link is bouncing. Check the log with show log messages | last 100 | find ge-0/0/1, then the optic with show interfaces diagnostics optics ge-0/0/1.
Input errors and framing errors rising together under load. Duplex or speed mismatch. Verify both ends report the same negotiated speed and duplex in the monitor header.
Errors only when a specific traffic pattern runs. Suspect an MTU or encapsulation mismatch rather than the cable — see the DF-bit and jumbo frame discussion in our MTU troubleshooting guide.
Clean counters, poor throughput. The physical layer is fine; look at egress scheduling, shaping or the far-end receiver. Measure the ceiling independently with iperf3 before blaming the interface.
A "Detected loopback" or alarm line appears in the header. The port sees its own transmissions returning; find and remove the loop or the mis-cabled patch before continuing.

A practical workflow is to start the session, record a ten-second baseline with c (clear), then generate the traffic or wait for the symptom and watch which column moves first. Because the display freezes with f, you can capture the moment the counter jumps and read the numbers at leisure instead of chasing a scrolling screen.

Platform and Session Caveats

The command is interactive and cannot be piped — | match, | find and | save do not apply, so scripted monitoring must use show interfaces statistics instead.
On Junos OS Evolved the session must be an SSH session; console and Telnet sessions do not support it.
Output format, available columns and per-queue counters differ between platforms: an EX access switch shows a different set of counters than an MX with MPC line cards, where the show interfaces queue command is needed for per-class detail.
Exit cleanly with q rather than closing the terminal, so the CLI releases the screen and returns to the prompt.
The accumulative counters that show interfaces reports are not cleared by c; use clear interfaces statistics ge-0/0/1 when you want a genuinely fresh baseline for later comparisons or for a ticket.

Correlating with Interface Damping and Hold Times

If monitoring shows the link bouncing, check whether interface damping is masking the flapping behavior — see our guide on Junos hold-time and damping configuration and how to identify a flapped interface with CLI commands. For a systematic physical-layer sweep, follow the Juniper Ethernet interface troubleshooting checklist.

monitor interface vs show interfaces

The two commands answer different questions, and the fastest troubleshooters use them together rather than choosing one.

show interfaces ge-0/0/1 is a snapshot of accumulated totals, ideal for pasting into a ticket and for comparing counters before and after a change.
show interfaces ge-0/0/1 extensive adds the physical detail: negotiated speed and duplex, the number of carrier transitions, MAC-layer statistics, and the error breakdown that monitor interface compresses into a few columns.
monitor interface shows rates. It answers “is it broken now?”, while the show commands answer “how long has it been broken?”.

A practical pattern: run monitor interface on the suspect port, and in a second SSH session keep show log messages | last 50 | find ge-0/0/1 open. The monitor tells you that a carrier transition happened; the log tells you what the device said about it. If syslog is shipping messages to a collector, note the time of the counter jump from the frozen monitor display and search the collector for that minute.

Timing and Refresh Behaviour

The refresh interval is fixed at one second and is not configurable, so do not expect sub-second visibility on bursty links: a microburst that lasts 200 milliseconds appears as a small delta in one refresh and as nothing at all in the next. Keep the device clock synchronised — if you are correlating a monitor session with logs from the same box or with a packet capture, an unsynchronised clock turns a two-minute investigation into an hour of guessing. For per-queue and per-class detail, leave the monitor session and use show interfaces queue ge-0/0/1, which reports queue counters, drops and transmit rates that the simple traffic view does not expose.

Three Worked Scenarios

A flapping uplink on an EX switch. Start monitor interface traffic and watch the Link column; the port that drops to Down for a single refresh is the one to investigate. Repeat with monitor interface ge-0/0/1 to see the carrier transition counter increment at the same second, then check the log for the interface-down reason.
A suspected duplex mismatch after a maintenance window. Clear the counters with c, generate a large transfer through the interface, and watch Input errors and Framing errors. If they climb in step with the transfer and stop when it stops, the physical layer is dropping frames; confirm the negotiated speed and duplex in the interface header against the far end’s configuration.
An aggregation member that is quietly under-used. In monitor interface traffic, a member of an aggregated Ethernet bundle showing a much lower packet rate than its siblings usually points at the load-balancing hash rather than at the hardware — egress hashing is one-sided, so check the traffic mix before assuming the optic is degraded.

Beyond the Interactive Session

Interactive monitoring is for humans; for anything that has to scale, poll or alert, replace it with a programmatic equivalent. show interfaces extensive | display xml or show interfaces statistics polled every 30 seconds gives you the same counters in a parseable form, PyEZ does the same job from Python with structured output, and gNMI streaming telemetry pushes the counters to a collector without any polling at all. The trade-off is resolution: telemetry is sampled at the cadence you configure, while monitor interface is one second and immediate, which is exactly what you want in the middle of an incident.

原文链接：https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/monitor-interface.html