JN0-106 Operational Monitoring and Maintenance Practice Question

Exhibit

Refer to the exhibit.
```
user@router> show interfaces ge-0/0/0 extensive | match errors
  Input errors: 0, Output errors: 0, Input drops: 5, Output drops: 0
  Input errors: 0, CRC errors: 0, Framing errors: 0, Runts: 0, Giants: 0
  Policed discards: 0, Resource errors: 0
```

Refer to the exhibit. An engineer notices that input drops are increasing. What is the most likely cause?

⚠ Common exam trap

Candidates often confuse input drops with CRC errors or assume a speed mismatch is the cause, but Junos explicitly separates input drops (buffer overflow) from physical-layer errors, and the question's exhibit would show no CRC errors or link flaps, isolating the issue to buffer exhaustion.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Buffer overflow

Input drops occur when the ingress interface's receive buffer is full and cannot accept more packets, typically due to the ingress rate exceeding the interface's ability to process or forward packets to the internal switch fabric. In Junos, this is often caused by microbursts or sustained oversubscription, not by a speed mismatch (which would show as errors or link flaps) or cable faults (which cause physical-layer errors). Buffer overflow is the correct answer because input drops directly indicate that the packet buffer has been exhausted.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Speed mismatch
Why it's wrong here
A speed mismatch between a Junos interface and its peer (e.g., one side set to 100 Mbps while the other runs at 1 Gbps) normally prevents the link from coming up or produces a storm of physical-layer errors such as CRC, alignment, or framing errors, because the receiving hardware is sampling at the wrong bit rate. It does not cause the ingress buffer to overflow, since the buffer only fills when packets are being successfully received at the line rate. Here, the exhibit shows a stable link with zero CRC errors, so a speed mismatch is not the cause of the input drops.
✓
Buffer overflow
Why this is correct
Input drops are specifically the counter that increments when the ingress packet buffer or the shared memory on the forwarding engine is full, forcing new packets to be discarded before they can be processed. This occurs when traffic bursts (often micro-bursts) exceed the interface's buffering capacity or when congestion causes tail-drop at the input queue. Unlike physical-layer errors, this is a congestion-related drop, and it is the correct explanation for the observed input drops in the exhibit.
✗
Cable fault
Why it's wrong here
A faulty cable or connector would impair the electrical or optical signal, leading to corrupted bits that are caught by the Ethernet frame check sequence and counted as CRC errors or alignment errors, not as buffer drops. The interface would also show physical-layer error counters incrementing and possibly link flaps or speed/duplex negotiation problems. Since the exhibit reports zero CRC errors and a stable link, a cable fault cannot account for the input drops.
✗
CRC errors
Why it's wrong here
The CRC error counter increments whenever the Ethernet frame check sequence fails, meaning the frame was corrupted in transit and is discarded after error checking. The exhibit explicitly shows CRC errors at zero, which rules out this cause immediately. Even if CRC errors were present, they would appear under 'input errors' rather than 'input drops,' because they are discarded due to invalid data, not due to a full buffer or congestion.

Go deeper

JN0-106 Operational Monitoring and Maintenance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question