Multi-Vendor Network CLI Cheat Sheet: IOS XR, Junos, SR OS, VRP

Network engineers who operate multi-vendor environments spend a surprising amount of time translating commands between Cisco, Juniper, Nokia and Huawei — and mistranslations are a leading cause of change-window incidents. A side-by-side CLI reference eliminates the guesswork: the same task has four different syntaxes, and the differences are systematic rather than arbitrary. This cheat sheet compares configuration models, diagnostic commands, and routing protocol configuration across IOS XR, Junos, SR OS and VRP.

Configuration Models: Commit vs. Apply-and-Save

Juniper Junos and Nokia SR OS use a transactional candidate model; Cisco IOS XR also requires an explicit commit; Huawei VRP applies commands immediately and you save explicitly. Setting a hostname:

# Cisco IOS XR
configure terminal → hostname R1 → commit
# Juniper Junos
configure → set system host-name R1 → commit   (rollback with 'rollback 0')
# Nokia SR OS
configure → system name R1 → commit → save
# Huawei VRP
system-view → sysname R1 → return → save

Mistaking write memory for commit on Junos does nothing — knowing which model each platform uses prevents these silent no-ops.

How to Use the Scenario Blocks

Cheat sheets that list commands alphabetically are useful for translation but useless under pressure. What you need during an incident is a sequence: what to configure, what to verify, and where to look when verification fails. Each block below follows that three-stage pattern — Configure, Verify, Troubleshoot — across all four platforms, so you can run the same workflow on IOS XR, Junos, SR OS or VRP without re-deriving it.

Read the blocks as complete procedures rather than isolated commands. A link that will not come up is almost never a single missing command; it is a sequence of checks that eliminates possibilities in order. The order matters more than the syntax, and the order is portable across vendors even when the syntax is not.

Scenario 1: Bringing Up a New Router-to-Router Link

Configure — address the interface, enable it, and confirm the description so that future operators know what the link is for.

# Cisco IOS XR
interface GigabitEthernet0/0/0/1
 description Core-to-Edge
 ipv4 address 10.1.1.1 255.255.255.252
 no shutdown
commit

# Juniper Junos
set interfaces ge-0/0/1 description "Core-to-Edge"
set interfaces ge-0/0/1 unit 0 family inet address 10.1.1.1/30
commit

# Nokia SR OS
/configure port 1/1/1 no shutdown
/configure router interface "to-edge" port 1/1/1
/configure router interface "to-edge" address 10.1.1.1/30
/configure router interface "to-edge" no shutdown

# Huawei VRP
interface GigabitEthernet0/0/1
 description Core-to-Edge
 ip address 10.1.1.1 255.255.255.252
 undo shutdown
quit
save

Verify — the interface must be up and the neighbour must be reachable before you announce anything.

IOS XR:  show interfaces GigabitEthernet0/0/0/1 brief ; show arp
Junos:   show interfaces ge-0/0/1 terse ; show arp no-resolve
Nokia:   show port 1/1/1 ; show router arp
Huawei:  display interface brief ; display arp
Common:  ping the far end from a loopback source, not from the link address

Troubleshoot — if the interface is down, work outward: optics, then cabling, then speed and duplex, then MTU. All four platforms report light levels and DOM data, but under different names: show controllers on IOS XR, show interfaces diagnostics optics on Junos, show port 1/1/1 detail on Nokia, and display interface transceiver verbose on VRP. If the interface is up but ARP or the ping fails, look for an address-family mismatch (Junos requires the family inet, VRP requires the global ip address to be in the right VPN instance) before you touch the physical layer.

Scenario 2: A BGP Session Stuck in Active or Idle

Configure — establish the peering with the minimum viable policy so that you can prove reachability before you add filtering.

# Cisco IOS XR
router bgp 65001
 neighbor 203.0.113.5
  remote-as 65002
  address-family ipv4 unicast
commit

# Juniper Junos
set protocols bgp group EBGP type external
set protocols bgp group EBGP peer-as 65002
set protocols bgp group EBGP neighbor 203.0.113.5
commit

# Nokia SR OS
/configure router autonomous-system 65001
/configure router bgp group "EBGP" peer-as 65002
/configure router bgp group "EBGP" neighbor 203.0.113.5

# Huawei VRP
bgp 65001
 peer 203.0.113.5 as-number 65002
 ipv4-family unicast
  peer 203.0.113.5 enable
save

Verify — check state, uptime, prefix counts and the local AS seen by the peer.

IOS XR:  show bgp summary ; show bgp neighbor 203.0.113.5
Junos:   show bgp summary ; show bgp neighbor 203.0.113.5
Nokia:   show router bgp summary ; show router bgp neighbor 203.0.113.5
Huawei:  display bgp peer ; display bgp peer 203.0.113.5 verbose

Troubleshoot — "Active" means the local device is trying to open TCP 179 and getting nothing back; "Idle" usually means a timer or a configuration state, not a network problem. Walk the stack in order: (1) is TCP reachable? Run a traceroute to 203.0.113.5 and confirm the packets leave the correct interface. (2) Is there an ACL or filter blocking TCP 179 inbound? Check with a packet capture rather than by reading configuration. (3) Does the remote AS number match what the peer expects? A mismatch produces an OPEN message followed by an immediate NOTIFICATION. (4) Do the hold times and authentication keys match? A key mismatch shows as a session that flaps up and down within seconds, which is diagnostically different from a session that never leaves Active.

Scenario 3: Adding a VLAN Across Mixed Vendors

Configure — create the VLAN or bridge domain, then add the port to it.

# Cisco IOS XR (L2VPN / bridge domain)
interface GigabitEthernet0/0/0/1
 l2transport
commit
l2vpn
 bridge group BG
  bridge-domain VLAN10
   interface GigabitEthernet0/0/0/1.10
commit

# Juniper Junos
set vlans VLAN10 vlan-id 10
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members VLAN10

# Nokia SR OS
/configure vlan 10 create
/configure vlan 10 ports 1/1/1 tagged

# Huawei VRP
vlan 10
interface GigabitEthernet0/0/1
 port link-type trunk
 port trunk allow-pass vlan 10
save

Verify — a VLAN exists on every platform; what differs is where membership is reported.

IOS XR:  show l2vpn bridge-domain brief
Junos:   show vlans ; show ethernet-switching table
Nokia:   show vlan 10
Huawei:  display vlan 10 ; display vlan 10 verbose

Troubleshoot — the classic failure is a native VLAN or tag-state mismatch, which presents as traffic that leaves one side untagged and arrives at the other expecting a tag. Confirm the tag state on both ends first; on Junos the value lives in the unit's family ethernet-switching configuration, on Nokia in the tagged versus port keyword on the VLAN port attachment, and on Cisco and Huawei in the encapsulation or link-type statement. Second failure mode: the MAC address table shows the address learned on the wrong VLAN, which almost always means the access port that should be a member of the VLAN is still in the default VLAN.

Scenario 4: Interface Errors and Physical-Layer Faults

Configure — nothing; this scenario is diagnostic. But do verify you have logging and counter timestamps enabled, because error counters that reset on a flap tell you nothing about frequency.

Verify — pull the counters and read the error types.

IOS XR:  show interfaces GigabitEthernet0/0/0/1 | include error|CRC|drop
Junos:   show interfaces ge-0/0/1 extensive | match "errors|CRC|drops"
Nokia:   show port 1/1/1 detail
Huawei:  display interface GigabitEthernet0/0/1 | include CRC|error

Troubleshoot — interpret by error type rather than by magnitude. CRC and input errors point to the physical path: dirty fibre, a failing optic, a bent patch lead, or a duplex mismatch on copper. Runts and giants suggest an MTU mismatch somewhere in the path. Output drops that appear only under load point to oversubscription or a queueing policy, not to a fault. Flapping with no counters incrementing usually means a protocol or a spanning-tree event rather than a physical fault. Cross-check with the peer's counters: errors counted on both ends nearly always mean the medium; errors on one end only usually mean the receiving optic.

Scenario 5: Collecting Evidence and Escalating

Configure — set traceoptions or debugs with strict filters and file rotation before you reproduce the problem.

# Junos
set protocols bgp traceoptions file bgp.log size 20m files 5
set protocols bgp traceoptions flag update detail
commit ; monitor start bgp

# IOS XR
debug bgp updates
show logging | include BGP

# Huawei
terminal monitor ; terminal debugging
debugging bgp update

Verify — confirm the trace file is actually growing and that the filter is narrow enough not to affect control-plane CPU.

IOS XR:  show processes cpu | include bgp
Junos:   show log bgp.log | last 20 ; show system processes extensive | match rpd
Huawei:  display cpu-usage ; display logbuffer

Troubleshoot — before opening a ticket, collect: the current configuration in an importable format, protocol state at failure time, logs covering the window, and interface counters. Doing this in a repeatable order means the same checklist works on every platform in the network, and it means you never have to restart a device to reproduce a fault you have already captured.

Diagnostic Command Equivalents

Ping, Traceroute and Capture

# Extended ping with source interface
Cisco:  ping 10.0.0.2 source loopback0
Junos:  ping 10.0.0.2 source 192.168.1.1
Nokia:  ping 10.0.0.2 source-address 192.168.1.1
Huawei: ping -a 192.168.1.1 10.0.0.2
# Traffic capture
Cisco:  monitor capture test interface gig0/0 both match ip any
Junos:  monitor traffic interface ge-0/0/0
Huawei: capture-packet interface gig0/0/0

Two habits make these commands more useful than they look. Always specify a source address or interface for a ping: a ping from the outgoing interface proves far less than a ping from the loopback you actually advertise, and on all four platforms the default source can differ from what you assume. And prefer file-based captures over on-screen output — a pcap you can open in Wireshark is worth far more than a screenful of hex that scrolls away during the incident.

OSPF and BGP Equivalents

# OSPF on a single interface
Cisco IOS XR: router ospf 1 / area 0 / interface GigabitEthernet0/0/0/0 / passive disable
Junos:  set protocols ospf area 0 interface ge-0/0/0 passive
Nokia:  configure router ospf area 0.0.0.0 interface "to-core"
Huawei: ospf 1 / area 0 / network 10.0.0.0 0.0.0.255
# BGP neighbor
Cisco:  neighbor 10.0.0.1 remote-as 65001
Junos:  set protocols bgp group external peer-as 65001 neighbor 10.0.0.1
Nokia:  configure router bgp neighbor 10.0.0.1 peer-as 65001
Huawei: bgp 65000 / peer 10.0.0.1 as-number 65001

Note that Junos writes passive where Cisco and Huawei use passive-interface or silent-interface, and that Nokia places the area at the router level rather than in the protocol instance. When translating, do not translate the keyword — translate the intent, then look up the keyword on the target platform.

For the deeper single-platform references, see Arista EOS CLI 模式指南 and NVIDIA MLNX-OS CLI 指南, plus the VRP command set in 华为路由器交换机命令大全, and the command-by-command comparison tables in the multi-vendor CLI comparison sheet.

原文链接：https://undercodetesting.com/master-multi-vendor-network-cli-the-ultimate-cheat-sheet-for-cisco-juniper-nokia-huawei-engineers-video