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.
Jump to a section
A simple way to picture Junos Troubleshooting Basics
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.
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.
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. 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. 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. 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. 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. 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.
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.
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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
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
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.
Mistake
If a ping fails, the destination device is broken.
Correct
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.
Mistake
Rebooting a Junos device will clear the log files and fix most problems.
Correct
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.
Mistake
All logs are in one file called 'messages'.
Correct
'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.
Mistake
The `show interfaces` command shows interface speed only.
Correct
`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.
Mistake
Traceroute shows the speed of each link.
Correct
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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
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.
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.
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.
`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.
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.
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.
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.
You've finished Junos Troubleshooting Basics. Continue through the JNCIA-JUNOS study guide to build a complete picture of the exam.
Done with this chapter?