Junos Troubleshooting Field Notes

Troubleshooting Mindset

The biggest lesson is simple: before touching the network, understand what normal looks like. A value is only useful when there is a baseline to compare it against: usual traffic levels, expected neighbors, interface counters, route counts, CPU behavior, latency, logs, and the latest approved change.

In production, troubleshooting also has to respect change control. Even when the fix looks obvious, the process still matters: maintenance window, impact analysis, implementation plan, rollback plan, pre-checks, post-checks, and approval. That discipline is what separates quick guessing from professional operations.

Observe Before Changing

Junos gives a strong operational toolkit for looking at the system before changing it. Logs, uptime, packet capture, chassis events, and hardware inventory are usually the first signals I want before assuming the protocol is the problem.

show system uptime
show log messages | match ae0
show log chassisd | match "FPC|PIC|PEM|fan|temperature"
show chassis environment
show chassis hardware
show log inventory

For packet-level evidence, monitor traffic is powerful, but it should be used carefully. Juniper explicitly warns that packet monitoring can affect scale and performance, so I treat it like a focused diagnostic tool, not a permanent observer.

monitor traffic interface ge-0/0/0 no-resolve detail
monitor traffic interface ge-0/0/0 matching "port 179" no-resolve detail

Control Plane Health

When the Routing Engine is under pressure, protocol symptoms can look like routing bugs even when the root cause is CPU, memory, daemon load, or churn. I normally start with the RE view, then move into process-level visibility.

show chassis routing-engine
show system processes summary
show system processes extensive
show system processes extensive | match rpd

For rpd, scheduler slips are a useful signal. A slip does not automatically mean the daemon is broken; it means the routing process was too busy to run a task at the expected time. That can happen during route churn, interface flaps, BGP updates, complex policies, or reconvergence.

If a daemon crashes, core files are not something to ignore or delete blindly. They preserve process or kernel state at the time of failure and should normally be collected with support information before escalation to JTAC.

The core file can come from a user process, the Junos kernel, or an embedded host component depending on the platform and failure type. That distinction matters when deciding whether the issue is isolated to a daemon or related to a deeper system event.

show system core-dumps
request support information

My note to myself: do not restart a process just because it looks busy. First understand what made it busy.

Storage, Software, and Recovery

Storage issues are not glamorous, but they can block upgrades, snapshots, and recovery work. Before software maintenance, I like checking available space and cleaning only what the platform identifies as safe to remove.

show system storage
request system storage cleanup dry-run
request system storage cleanup

For software installation under tight space conditions, options such as no-copy and unlink can reduce temporary storage requirements. For recovery scenarios, snapshots and secondary boot media matter because they give the device a known path back.

request system software add <package> no-copy unlink
request system snapshot
set system mirror-flash-on-disk

Routing Checks: OSPF, BGP, and Reachability

Routing troubleshooting is easier when each layer is validated in order. For OSPF, I check physical and data-link state, subnet consistency, area, authentication, timers, network type, and MTU. A neighbor stuck in ExStart or Exchange immediately makes me suspicious of MTU.

show ospf neighbor detail
show interfaces ge-0/0/0 extensive
show ospf statistics

For EBGP over loopbacks, two items are easy to miss: the local address and multihop. If the remote device is not available, a targeted capture can still show whether TCP 179 is arriving, which source address is used, and whether TTL or path reachability may be involved.

set protocols bgp group EBGP type external
set protocols bgp group EBGP local-address 192.0.2.1
set protocols bgp group EBGP multihop
set protocols bgp group EBGP neighbor 192.0.2.2 peer-as 65002

show bgp neighbor
monitor traffic interface ge-0/0/0 matching "port 179" no-resolve detail

High Availability Validation

HA in Junos is a set of different mechanisms, and mixing them up creates confusion. GRES helps preserve forwarding and kernel state during Routing Engine switchover. NSR replicates routing protocol state to the backup RE. Graceful Restart depends on neighbor cooperation. ISSU is about software upgrade with reduced interruption.

BFD belongs in the same operational conversation, but it solves a different problem: fast failure detection for protocols such as BGP, OSPF, IS-IS, RSVP, LDP, and static routes. Also, when a BGP capability such as Graceful Restart is enabled after the session is already established, the session normally needs to restart so capabilities can be renegotiated in the BGP OPEN exchange.

commit synchronize
show chassis routing-engine
show system switchover
show task replication

One operational detail I like from this topic: commit synchronize is not just a nice habit. On dual-RE systems, it helps keep candidate configuration activation aligned across both Routing Engines and reduces surprises during failover work.

Platform, Access, and Control Plane Protection

The original material also touched SNMP, control plane protection, ARP, and interface troubleshooting. I like keeping those in the same note because many incidents start as "routing is broken" and end up being management access, ARP, MTU, or RE protection.

For monitoring, SNMPv3 is the safer operational choice because it supports authentication, integrity, encryption, and user-based access control. Traps are fire-and-forget notifications, while informs request confirmation from the NMS.

For Routing Engine protection, firewall filters applied as input filters on lo0 are a key part of Junos hardening. The filter should explicitly allow expected control and management traffic such as BGP, OSPF or IS-IS, BFD, SSH from management networks, SNMP from the NMS, NTP, and controlled ICMP. Everything else should be handled intentionally, not accidentally.

show arp
show ipv6 neighbors

set interfaces lo0 unit 0 family inet filter input PROTECT-RE

Interfaces, MTU, LACP, and Switching Checks

Physical and Layer 2 checks are easy to underestimate. Interface speed, duplex, link mode, FEC, frame errors, flaps, MTU, encapsulation, and loopback state can all explain symptoms that initially look like protocol problems.

show interfaces ge-0/0/0 extensive
show interfaces statistics ge-0/0/0 detail

ping 192.0.2.1 size 1472 do-not-fragment

The loopback notes are a good reminder that physical Ethernet loopback is not the same thing as the logical lo0 interface. For transport and physical testing, the hierarchy matters.

set interfaces <interface-name> clocking internal
set interfaces <interface-name> ether-options loopback
edit interfaces <interface-name> otn-options

set interfaces ae0 aggregated-ether-options lacp active

For switching, the same-port filtering example is worth remembering: if a switch receives a frame on the same port where the destination MAC is learned, it filters the frame instead of forwarding it. For STP, root bridge election comes down to the lowest Bridge ID: priority first, then MAC address.

LACP is another small detail with real impact: passive/passive does not initiate negotiation. At least one side must be active for the aggregate to form.

Quick Command Map

Corrections I Want to Keep in Mind

• For checking EBGP parameters without access to the peer, packet observation with monitor traffic interface is more useful than relying only on a syslog filter.
• NSR requires GRES and saves routing information on the backup Routing Engine.
• ksyncd is the process involved in kernel state synchronization between Routing Engines with GRES.
• show system uptime gives time, boot, protocol start, and last configuration change context; it is not the same as show version.
• In the hub/switch example, the destination host processes the frame and the switch filters it because the destination MAC is learned on the same ingress port.

Juniper References

• Juniper CLI Reference: monitor traffic
• Juniper CLI Reference: show log
• Juniper CLI Reference: show chassis routing-engine
• Juniper CLI Reference: request system storage cleanup
• Juniper CLI Reference: commit synchronize
• Juniper CLI Reference: show system switchover