# Junos Troubleshooting Basics

> Chapter 15 of the Courseiva JUNIPER-JNCIA-JUNOS curriculum — https://courseiva.com/learn/juniper-jncia-junos/junos-troubleshooting-basics

**Official objective:** 6.1 — Use monitoring, logging, and diagnostic tools to troubleshoot common Junos issues.

## Introduction

What happens when a Junos router stops forwarding traffic or a switch goes offline in the middle of the night? Troubleshooting is the systematic process of identifying and fixing these problems, and it is the most practical skill you will use on the job. For the JNCIA-JUNOS exam, objective 6.1 tests whether you know the built-in tools Junos provides to monitor the network, read logs, and diagnose faults – the same toolkit real network engineers rely on every day.

## The Lost House Keys Analogy

Have you ever stood outside your own front door, pockets empty, knowing your house keys are somewhere inside? You could panic and kick the door down, but that is expensive and destructive. Instead, you take a logical approach. First, you check the last place you remember having them – your coat pocket from this morning. That is like checking the system log. Then, you retrace your steps: the kitchen counter, the bedroom dresser. That is like using tracing tools. Finally, you might shout to a family member, 'Have you seen my keys?' That is like using `ping` to see if a device is awake. In IT, troubleshooting a Junos device is exactly this. You do not just reboot and hope (kicking the door down). You use logs, which are like a diary of everything the device has done. You use monitoring tools, which are like motion-sensor cameras showing you what happened while you were out. You use diagnostic commands, which are like asking specific questions: 'Where were you at 3:00 pm?' A systematic, step-by-step search always finds the problem faster than random guesswork. The Junos operating system gives you all the tools you need to find your digital house keys without breaking anything.

## Core explanation

Troubleshooting on a Junos device is like being a detective. You are looking for clues to explain why something is not working. Junos gives you several key tools to find those clues.

First, let us talk about **monitoring**. Monitoring means watching the network continuously to see if things are healthy. The most basic monitoring tool is `ping`. Ping sends a small packet of data to another device, like a router or a server, and waits for a reply. If you get a reply, the device is alive and reachable. If you do not, there is a problem on the network path. A more advanced tool is `traceroute`, which shows you the exact path your data takes hop-by-hop through routers. Each hop is a router. If it stops at hop 3, you know the problem is somewhere between hop 3 and hop 4.

Second, there is **logging**. Logging is the device writing down everything important that happens. Think of it as a black box on an aeroplane. Junos stores these records in **system log files**, often called syslog. These files live in the `/var/log` directory on the device. The most important log is `messages`. To see it, you type the command `show log messages`. This file contains everything from an interface going down to someone logging in. You can search for specific things, like the word 'error', using the pipe `|` and the `match` command. For example: `show log messages | match error`. This shows you only the lines with 'error' in them.

Third, there is **diagnostic tools**. These are commands you run to check the device's health right now. One critical command is `show interfaces`. This shows you every port (interface) on the device and its status. A key piece of information is the **interface status**. It tells you if the port is physically connected (carrier detect) and if the protocol is running. You want to see 'up' for both the physical and protocol states. If you see 'down', you have a cable problem or a configuration problem.

Another crucial diagnostic tool is the **monitoring interface traffic** command. You can watch traffic flow in real-time. For example, `monitor interface ge-0/0/0` shows you live traffic counters for that interface. This is useful when you think a link is overloaded.

Junos also has **traffic analysis** tools. The most famous is `tcpdump`, which captures packets flying across the network. It is a deep dive tool for when you need to see the actual data being sent. For beginners, knowing it exists is more important than mastering it.

Finally, there is the **configuration history**. Junos keeps a record of every change you make to the configuration. You can see the last several configurations using `show system rollback`. If a change breaks something, you can roll back to a working configuration from before the change. This is one of the best features of Junos and it saves network engineers hours of work.

All these tools replace the old way of troubleshooting, which was 'guess and reboot'. With Junos, you use data to find the root cause. You gather clues from logs, test connectivity with ping and traceroute, check ports with show interfaces, and use the rollback feature to undo mistakes. For the exam, memorise these commands: `show log messages`, `show interfaces`, `ping`, `traceroute`, and `show system rollback`. They are your five best friends.

## Real-world context

Meet Sarah. Sarah is a junior network engineer at a mid-sized company that runs a chain of retail stores. Each store has a Juniper switch that connects the point-of-sale (POS) system, Wi-Fi, and security cameras back to the head office. One Tuesday morning, the manager of Store 12 calls in a panic: 'Our POS system is not connecting! We cannot process credit cards.'

Sarah's first step is **not** to drive to the store. Instead, she opens a secure shell (SSH) session to the switch in Store 12 from her desk. She starts with monitoring: she types `ping 8.8.8.8` from the switch. If that works, the switch can reach the internet, so the problem is likely a cable or configuration issue at the store, not a wide area network (WAN) outage.

It does not work. The ping fails. Now Sarah knows there is a connectivity problem. She uses `traceroute 8.8.8.8`. The traceroute stops at the head office router. This tells her the problem is on the connection between the head office and the store.

Next, she uses logging. She types `show log messages | match store12` to see if the switch reported anything. She sees lines mentioning interface ge-0/0/0 went down at 3:00 AM. That is the interface connecting to the WAN. Very suspicious.

Now she uses diagnostics. She types `show interfaces ge-0/0/0`. The output shows 'Physical link: Down'. This confirms the cable or the connection from the internet service provider (ISP) is dead. Sarah calls the ISP with the specific interface information.

While waiting for the ISP, she checks the configuration history using `show system rollback`. She sees that a junior team member made a change to the interface configuration yesterday evening. Using `show system rollback 1`, she compares the current config to the one before the change. She sees the change was unrelated (an update to the DHCP server settings on a different VLAN), but she checks anyway. It is not the cause.

The ISP fixes the line. Sarah then re-checks everything:
- `ping 8.8.8.8` now succeeds.
- `show interfaces ge-0/0/0` shows 'Physical link: Up' and 'Protocol: Up'.
- She asks the store manager to try a test card. It works.

Sarah closes the ticket. All the troubleshooting was done remotely in 20 minutes using logging, monitoring, and diagnostic tools. She never touched the switch. This is the real-world power of knowing the basics of Junos troubleshooting.

## Exam focus

The JNCIA-JUNOS exam tests objective 6.1 heavily. Expect multiple-choice questions that ask you to match a problem with the correct diagnostic command. They love testing the following concepts, so pay close attention.

**What they test:**
- The exact syntax of common `show` commands.
- The difference between `show log messages` and `show interfaces`.
- How to interpret output from `ping` and `traceroute`.
- The purpose of `show system rollback`.
- What information is stored in log files (versus interface counters).

**Common trap patterns:**
- They will list four commands and ask which one you use to see if an interface cable is plugged in. The correct answer is `show interfaces`, but some candidates choose `show log messages` because they think logs show everything. Logs show events (like 'Interface down'), but they do not show the real-time status. The `show interfaces` command shows the exact current status.
- They will give you a log line saying 'Interface ge-0/0/1 down' and ask what time the interface failed. The log line includes a timestamp, so read the question carefully.
- They will ask about the `monitor interface` command. Know that it shows real-time traffic, not historical data.
- They will test `traceroute` by showing a partial output stopping at hop 4 and ask where the problem is. The answer is between hop 4 and hop 5.
- They will present a scenario where a change broke something and ask how to revert. The answer is `show system rollback` followed by `rollback 0` or a specific number.

**Key definitions to memorise:**
- **Syslog**: The logging system. The log file is typically `/var/log/messages`.
- **Interface status**: Two parts: Physical link (cable connection) and Protocol (logical connection). Both must be 'up' for the interface to work.
- **Ping**: Tests reachability. A failure means the destination is unreachable.
- **Traceroute**: Shows the path packets take. Each hop is a router.
- **Rollback**: The ability to revert to a previous configuration. Numbered starting from 0 (current config) going backwards.

**Question types:**
- 'Which command do you use to view the system log?' Answer: `show log messages`.
- 'Your ping to 10.0.0.1 fails. What does this mean?' Answer: The device is not reachable.
- 'You see 'Physical link: Down' on an interface. What is the most likely cause?' Answer: A cable is unplugged or faulty.
- 'How do you see the last five configurations?' Answer: `show system rollback`.

Practise identifying the right tool for the job. If the question says 'real-time traffic', the answer is `monitor interface`. If 'historical event', the answer is `show log messages`. If 'cable status', the answer is `show interfaces`. Get this right and you will pick up easy marks.

## Step by step

1. **1. Identify the Problem** — Ask: 'What is not working? Is a device unreachable? Is traffic slow? Are users reporting errors?' Write down the exact symptom. For Junos, this could be 'Cannot ping the core router' or 'Interface ge-0/0/2 is flapping (going up and down)'.
2. **2. Isolate the Scope** — Use `ping` to test connectivity from the affected device. If the device cannot ping its own default gateway, the problem is local. If it can ping the gateway but not the destination, the problem is further away. This narrows down where to look.
3. **3. Check Logs for Clues** — Type `show log messages` to see recent events. Use the `match` filter to find specific terms like the interface name or 'error'. Logs often tell you exactly what happened and when, such as 'link down' at a specific time.
4. **4. Inspect the Interface** — Use `show interfaces <interface-name>` to verify the physical and protocol status. If physical is down, check cables and the far-end device. If protocol is down, check configuration (like IP addressing). Look for errors like CRC or collisions that indicate a bad cable.
5. **5. Check Recent Configuration Changes** — Use `show system rollback` to list the last saved configurations. Compare the current configuration (rollback 0) with a prior one (e.g., rollback 2) using `show | compare rollback 2`. If a recent change introduced the problem, roll back to the previous working config using `rollback 2` and commit.
6. **6. Implement and Verify a Fix** — After identifying the root cause (e.g., replacing a faulty cable, correcting a config error, or rolling back a change), apply the fix. Then verify by re-running the initial test (ping, interface status, or user test). Confirm the issue is resolved and no new problems appeared.

## Comparisons

### show log messages vs show interfaces

**show log messages:**
- Displays historical events recorded over time.
- Used to find when and what happened (e.g., interface down at 3:00 AM).
- Output is a text log of events with timestamps.

**show interfaces:**
- Displays current real-time status of interfaces.
- Used to verify physical and protocol connectivity right now.
- Output is a structured table showing interface details (speed, status, errors).

### ping vs traceroute

**ping:**
- Tests only if a destination is reachable (returning replies).
- Does not show the path; only tells you success or failure.
- Uses ICMP echo requests and waits for replies.

**traceroute:**
- Shows the entire path of routers (hops) to the destination.
- Reveals where packets stop or are delayed (e.g., hop 3).
- Uses UDP or ICMP packets with increasing TTL values to discover hops.

### monitor interface vs show interfaces

**monitor interface:**
- Shows traffic statistics in real-time (updating every second).
- Used to watch for congestion or bursts of traffic live.
- Exit with Ctrl+C; it does not store historical data.

**show interfaces:**
- Shows a static snapshot of interface statistics at the moment you run it.
- Used to check counters like errors, packets sent, and link status.
- Output is a one-time view; no continuous updates.

## Diagram

_A decision flowchart showing the systematic Junos troubleshooting process from problem report to resolution._

```mermaid
flowchart TD
    A[Problem Reported] --> B[Ping Test]
    B -->|Success| C[Check Application]
    B -->|Failure| D[Traceroute]
    D --> E{Stops at Hop X?}
    E -->|Yes| F[Check interface between Hop X and X+1]
    E -->|No| G[Check logs with 'show log messages']
    F --> H[Use 'show interfaces' on suspect link]
    H -->|Physical Down| I[Check cables & power]
    H -->|Protocol Down| J[Check IP config & encapsulation]
    G --> K[Look for error or link down events]
    K --> L[Review recent changes using 'show system rollback']
    L --> M[Rollback if needed]
    I --> N[Resolve cable issue]
    J --> N
    N --> O[Re-test with ping]
    M --> O
    O -->|Pass| P[Issue resolved]
```

## Common misconceptions

- **Misconception:** If a ping fails, the destination device is broken. **Reality:** A ping failure could be caused by the source device, an intermediate router, a firewall rule blocking ICMP, or the destination. It only confirms no reply was received, not the exact location of the fault. (Ping is a simple test, so beginners assume the target is the problem. In reality, many things can block pings, especially firewalls.)
- **Misconception:** Rebooting a Junos device will clear the log files and fix most problems. **Reality:** Rebooting usually does not clear the log files (they persist in storage), and it rarely fixes configuration errors. Rebooting is a last resort because it disrupts traffic. (In home computing, rebooting fixes many issues. Beginners transfer this habit to enterprise equipment, not realising Junos devices are designed to stay up for months or years.)
- **Misconception:** All logs are in one file called 'messages'. **Reality:** 'messages' is the main system log, but Junos has multiple log files. For example, `interactive-commands` logs every command typed by an administrator. 'messages' is not the only file. (The exam focuses on 'messages', so students assume it is the only log file. Junos actually uses multiple logs for different purposes.)
- **Misconception:** The `show interfaces` command shows interface speed only. **Reality:** `show interfaces` shows many details: physical link status, protocol status, input/output errors, packets sent/received, MTU, and speed. It is a comprehensive status report, not just speed. (Beginners see 'speed' in the output and focus only on that. They miss the critical 'Physical link: Down' line that indicates a cable is unplugged.)
- **Misconception:** Traceroute shows the speed of each link. **Reality:** Traceroute shows the path (the list of routers) and the round-trip time (RTT) to each hop. The RTT gives a clue about latency, but it is not a measurement of link speed (bandwidth). (The word 'traceroute' sounds analytical, so beginners assume it measures speed. It actually maps the route and measures delay, not bandwidth.)

## Key takeaways

- The `show log messages` command displays the main system log file containing events like interface failures or user logins.
- To check whether a cable is physically connected, use `show interfaces` and look for 'Physical link: Up'.
- If a ping to an IP address fails, the destination is unreachable, but the fault could be anywhere along the network path.
- The `traceroute` command reveals every router hop between your device and a destination, helping you isolate where packets stop.
- Junos keeps a history of configuration changes accessible via `show system rollback`, allowing you to revert to a previous working state.
- The `monitor interface ge-0/0/0` command shows real-time traffic counters on an interface, useful for spotting congestion.
- Log files are persistent and survive a reboot, so you can investigate crashes or problems that happened before the device restarted.
- To view only error lines in the log file, use `show log messages | match error`.
- When a network device fails, always check the physical layer first: cables, power, and interface status.
- Junos troubleshooting is systematic: start with ping, then traceroute, then logs, then interface status, then rollback if misconfiguration is suspected.

## FAQ

**What does the `show log messages` command do?**

It displays the contents of the main system log file (`/var/log/messages`), which records important events like interface state changes, login attempts, and errors. This is your first stop for finding clues about problems.

**If I see 'Physical link: Down', what should I check?**

Check the physical cable connection: is it plugged in securely? Is the far-end device powered on? Also check for damaged cables or ports. This status means the electrical signal is not detected.

**How do I undo a configuration change that broke the network?**

First, type `show system rollback` to see the previous configurations. Then, type `rollback N`, where N is the number of the working configuration (e.g., `rollback 1`). Finally, type `commit` to activate the reverted configuration.

**What is the difference between `ping` and `traceroute`?**

`Ping` tests if a destination is reachable (yes or no). `Traceroute` shows the exact path packets take through each router, where each router is called a hop. Traceroute helps you find *where* along the path the failure is.

**Can I see logs from yesterday?**

Yes. Log files are stored in `/var/log/`. Some systems rotate logs (rename them with a date), so you might see `messages.0` (older) or `messages` (current). Use `show log messages.0` to view archived logs.

**Why does `ping` work but the network still feels slow?**

Ping only tests reachability and very basic round-trip time. It does not measure bandwidth or congestion. Use `monitor interface` to see traffic levels, or check for errors on interfaces with `show interfaces`. High output drops indicate a bottleneck.

**What does 'Physical link: Up, Protocol: Down' mean?**

It means the cable connection is good (physical layer is working), but the logical protocol (like IP) is not configured correctly. Check if the interface has an IP address or if the encapsulation type matches the far end.

## Check your understanding

1. **Which command would you use to see if an interface is physically connected?**

   Answer: `show interfaces <interface-name>` — look for 'Physical link: Up'.

2. **A user reports a device is unreachable. Your ping from the Junos router to that device fails. What should you do next?**

   Answer: Run `traceroute` to the device to see where the path stops, then check logs and the interface status at that hop.

3. **How do you view the system log to find error messages?**

   Answer: Use `show log messages | match error` to filter for lines containing 'error'.

4. **You made a configuration change that broke connectivity. How do you revert to the previous working configuration?**

   Answer: Use `show system rollback` to see the list, then `rollback 1` (or the number of the previous config), then `commit`.

5. **What does 'Physical link: Down' indicate on a Junos interface?**

   Answer: It indicates no electrical signal is detected on the cable, meaning the cable is unplugged, faulty, or the far-end device is powered off.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/juniper-jncia-junos/junos-troubleshooting-basics