Cisco vs Juniper: Troubleshooting Commands Cheat Sheet

Engineers who work in multi-vendor environments constantly translate between Cisco IOS and Juniper Junos commands. This cheat sheet maps the most common troubleshooting commands side by side - management, routing table, BGP, IS-IS, and support collection - so you can diagnose the same problem on either platform without fumbling for syntax.

How to Use This Cheat Sheet

IOS and Junos solve the same problems with the same underlying concepts, but they expose those concepts through very different command hierarchies. Cisco IOS grew out of a flat CLI where protocol families are the first keyword: show ip route, show ip bgp, show clns neighbors. Junos was designed around a hierarchical configuration database, so its operational commands are grouped by subsystem or table: show route, show bgp, show isis adjacency, show chassis, show system.

The practical rule is simple. On IOS, ask "which protocol owns this data?" and prefix with ip, ipv6, clns or mpls. On Junos, ask "which table or daemon owns this data?" and use route, isis, bgp, chassis or system. Once that mapping becomes automatic, the rest of the translation is mechanical, and you stop losing change-window minutes to syntax recall.

One structural difference deserves attention before anything else: IOS runs in a single configuration mode where changes take effect as you press Enter, while Junos keeps a separate operational mode and a candidate configuration that only becomes active after commit. On Junos, show commands are operational-mode commands; on IOS they are available both from the exec prompt and, in many cases, inside configuration mode.

Management Commands

Three of these rows hide important differences. On IOS, show version is the one-stop command: image name, uptime, memory, serial number and the reason for the last reload all appear in a single screen. On Junos the same information is spread across show version, show system uptime, show chassis hardware and show system boot-messages. Similarly, IOS reports control-plane CPU with show processes cpu sorted, while Junos breaks routing-engine load into two useful commands: show chassis routing-engine for the daemon-by-daemon split, and show system processes extensive for the full process list sorted by CPU. Finally, note that Junos devices do not have a "line" concept - remote sessions are identified by user name, so you disconnect them with request system logout rather than by clearing a tty.

Routing Table

The conceptual trap here is the separation between the routing table (the RIB, built by the routing protocol daemons) and the forwarding table (the FIB, programmed into hardware). IOS shows the RIB with show ip route and the FIB with show ip cef; Junos shows the RIB with show route and the FIB with show route forwarding-table. When a prefix appears in the RIB but traffic is not forwarded, you are looking at a FIB-programming problem, and the forwarding-table command is where the answer lives.

Junos adds a concept IOS does not name explicitly: hidden routes. A route is hidden when it was received but not installed - an unresolvable next hop, a failed route validation, or a policy rejection. show route hidden surfaces them, and show route <prefix> detail explains why the route is inactive. On IOS the closest equivalent evidence is show ip bgp <prefix> showing a next-hop that fails RIB validation, plus show ip route <prefix> reporting the route as "not installed".

BGP Troubleshooting

The natural first command on both platforms is the neighbor summary, and the two outputs are nearly equivalent: state, uptime, prefixes received, and the counters that reveal a flapping session. Where they diverge is in how you inspect a single neighbor. On IOS, everything about one peer lives under show ip bgp neighbor A.A.A.A, including timers, capabilities, message counters and the complete policy configuration applied in both directions. On Junos, the peer view is show bgp neighbor A.A.A.A, while the policy view is split into show route advertising-protocol bgp and show route receive-protocol bgp - which is actually more direct, because it answers "what exactly did this peer send me?" in one command.

Avoid the hard reset unless you have no alternative. On a full-table session, clear ip bgp tears down the session and re-exchanges every prefix; the soft reset, which requires neighbor soft-reconfiguration inbound on IOS or route refresh support on both platforms, re-runs the inbound policy without dropping the peering. Junos negotiates route-refresh capability by default, which is one reason many operators consider Junos peering easier to work with during policy changes.

IS-IS Commands

IS-IS is where the naming divergence is largest, because IOS inherited its operational commands from the Connectionless Network Service world: adjacency and interface information is filed under clns, while the link-state database is filed under isis. Junos uses isis for everything IS-IS related. The useful additions on each side are show clns neighbors detail versus show isis adjacency detail for per-adjacency hold time, uptime and interface information, and show isis database detail or show isis database extensive for the actual TLVs. When an adjacency is up but the topology is not converging, compare the LSDB on both ends: a level mismatch or a mismatched authentication key shows up as an empty or truncated database on one side.

Logs and Files

Log handling reflects each platform's architecture. On IOS, the logging buffer is an in-memory ring that disappears on reload unless you also send messages to a syslog server or copy them to flash. On Junos, messages are written to /var/log/messages and the logging daemon keeps them across restarts, so show log messages | last 50 is usually enough to reconstruct an event after the fact. Junos also writes a separate log per protocol if you configure one, which makes isolating BGP or IS-IS events far easier than grepping a shared buffer.

For storage, remember that file list on Junos can navigate the entire filesystem - file list /var/tmp, file show /var/log/messages, file list detail /cf/var/db - whereas IOS is limited to the filesystems the platform exposes, typically bootflash:, flash: or harddisk:. Junos also surfaces crash evidence directly with show system core-dumps; on IOS you look for crashinfo files in bootflash after a reload.

The Operate and Configure Split

Half of multi-vendor confusion has nothing to do with show commands. IOS puts you in one mode tree where typing a command that starts with no removes configuration, and write memory or copy running-config startup-config persists it. Junos separates operational mode (prompt ends in >) from configuration mode (prompt ends in #), builds changes in a candidate configuration, and activates them with commit. Two consequences follow. First, a Junos engineer who types write memory on IOS is fine, but an IOS engineer who types write memory on Junos gets an error - and worse, an engineer who forgets commit on Junos sees a running configuration that does not match the candidate and assumes the device ignored the change. Second, Junos makes rollback trivial: rollback 1 loads the previous committed configuration, and commit confirmed 5 automatically reverts in five minutes unless you confirm. IOS has no equivalent safety net without an external archive and configuration replace feature.

Filtering Show Output

Both platforms support output filters, but only if you reach for them. Junos adds | display set and | display inheritance, which render a hierarchical configuration as set-style commands and show values inherited from groups - both extremely useful when you are comparing configurations across vendors. IOS adds | section, which is the closest analogue to Junos's "show configuration interfaces" and is far more precise than a long include regex.

Interface and Link Troubleshooting

Both platforms hide physical-layer problems in different places. IOS reports input errors, CRC, runts and giants inline in show interfaces output, but you have to read past the rate lines. Junos splits the data: show interfaces terse gives you the up/down matrix, while show interfaces extensive is the only place where error counters, MAC learn state and per-queue statistics appear. If a link is flapping, show interfaces extensive plus show log messages on Junos, or show interfaces plus show logging with link-state logging enabled on IOS, will normally identify whether the fault is optical, a cabling issue, or a protocol flap.

OSPF Troubleshooting

OSPF is the friendliest of the protocols to translate because the vocabulary is identical: neighbor, database, interface, area. The names diverge slightly - IOS uses show ip ospf neighbor, Junos uses show ospf neighbor - but the output columns mean the same thing. When adjacencies are stuck in EXSTART or EXCHANGE, both platforms show an MTU mismatch in the neighbor detail output, and both support per-interface MTU checks. On Junos, remember that OSPF is configured per interface unit under protocols ospf area, so an interface missing from show ospf interface usually means a missing interface statement rather than a network statement.

Debug, Trace and Packet Capture

# IOS: conditional capture with a filter, then copy off-box
monitor capture CAP interface GigabitEthernet0/1 both match ipv4 protocol tcp any any eq 179
monitor capture CAP start
monitor capture CAP stop
monitor capture CAP export tftp://10.0.0.5/cap.pcap

# Junos: capture to a file you can scp later
monitor traffic interface ge-0/0/1 no-resolve write-file /var/tmp/bgp.pcap
file list /var/tmp/bgp.pcap
# On Junos you can also use packet-triggered tracing for BGP messages
set protocols bgp traceoptions file bgp.log size 10m files 5
commit
monitor start bgp

Two habits make debugs survivable. First, always filter: an unfiltered debug ip packet on a busy IOS router is a self-inflicted outage, and an unfiltered Junos traceoptions configuration on a full-table peering generates gigabytes. Second, always give traceoptions a file, a size and a file count so the daemon rotates rather than filling the filesystem. Both platforms support the practical alternative of capturing traffic and reading it in Wireshark instead of debugging on the control plane.

Common Multi-Vendor Pitfalls

• show ip route and show route are not interchangeable habits - on Junos, show ip route is not a command, and on IOS, show route is not a command either. Muscle memory is the enemy here.
• IOS "administratively down" is Junos "down" with an ADMIN flag in show interfaces terse; the same fault has two different vocabulary words.
• Prefixes are expressed as 10.0.0.0/8 on both platforms, but masking differs: IOS accepts dotted-decimal masks on many commands (255.255.255.0) while Junos requires prefix length or netmask syntax in a from clause.
• Counters presented as "49 days" on one platform may be "4w1d" on another; when comparing uptime across vendors, convert to seconds before drawing conclusions.
• Junos requires commit before changes take effect and rollback to undo; IOS's no command removes configuration but never reverts the whole change set.

Collecting Evidence for a TAC Case

Both vendors want the same artefacts: current configuration, interface statistics, protocol state, logs covering the failure window, and hardware health. On IOS, a single show tech-support collects nearly everything but can take minutes on a large chassis and may time out the session. On Junos, request support information writes to a file that you then copy off the device.

# Cisco IOS
show tech-support | redirect bootflash:tech-R1-20260914.txt
show logging > bootflash:log-R1.txt
copy bootflash:tech-R1-20260914.txt tftp://10.0.0.5/

# Juniper Junos
request support information | save /var/tmp/RSI-R1.txt
show log messages | save /var/tmp/messages-R1.txt
file copy /var/tmp/RSI-R1.txt 10.0.0.5:/tftp/

Collect configuration and logs before you change anything. A control-plane restart, an interface bounce, or a clear bgp rewrites the evidence you need, and vendors routinely close cases as "cannot reproduce" when the state at failure time has been overwritten.

The command families are conceptually identical - show vs show, show ip route vs show route - so translating between them is mostly about knowing the Junos protocol/table keywords.

Related articles: Juniper Ethernet interface troubleshooting checklist, Junos password recovery guide, Cisco IOS password recovery procedure, and the field-by-field guide to show interfaces extensive.

原文链接：https://www.bgphelp.com/2017/02/17/cisco-juniper-troubleshooting-commands