Multi-Vendor CLI Cheat Sheet: Cisco, Juniper, Huawei and Nokia

Managing a multi-vendor network means switching between Cisco IOS, Juniper Junos, Huawei VRP and Nokia SR OS on the same day - and the concepts are identical while the syntax differs just enough to cause mistakes. This cheat sheet lines up the four CLIs task by task: interface configuration, OSPF, BGP peering, VLAN trunking and ACLs, so you can translate between platforms instead of relearning each one.

What Actually Differs Between the Four CLIs

There are only five real differences between these platforms, and everything else is vocabulary. First, the show verb: Cisco, Junos and Nokia use show, Huawei uses display. Second, the negative verb: Cisco prefixes with no, Junos uses delete, Huawei uses undo, Nokia removes by navigating back with no inside the changed context. Third, the commit model: Junos and Nokia SR OS use a candidate configuration that requires an explicit commit, Cisco IOS applies immediately and needs write memory or copy running-config startup-config to persist, and Huawei VRP also applies immediately but requires save to survive a reload.

Fourth, the addressing and interface naming: Cisco and Huawei index interfaces as GigabitEthernet0/1 and GigabitEthernet0/0/1 respectively, Junos uses ge-0/0/1 with a mandatory logical unit, and Nokia SR OS names physical ports 1/1/1 and then binds them to logical interfaces by name. Fifth, the masks: Cisco and Huawei accept dotted-decimal masks in configuration, Junos uses prefix length (/24), and Nokia uses prefix length as well. Miss any of these five and you will produce a command that the device either rejects or, worse, accepts with a different meaning than you intended.

Interface Configuration Side by Side

# Cisco IOS
interface GigabitEthernet0/1
 description Uplink-to-Core
 ip address 192.168.1.1 255.255.255.0
 no shutdown

# Juniper Junos
set interfaces ge-0/0/1 description "Uplink-to-Core"
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24

# Huawei VRP
interface GigabitEthernet0/0/1
 description Uplink-to-Core
 ip address 192.168.1.1 255.255.255.0
 undo shutdown

# Nokia SR OS
/configure port 1/1/1 ethernet
/configure router interface "to-core" port 1/1/1
/configure router interface "to-core" address 192.168.1.1/24

Junos applies changes only on commit; Nokia uses slash-navigation with /admin save; Cisco and Huawei apply commands immediately. Read the four snippets again and notice that only Junos needs a unit 0 statement. That logical unit is where addresses, VLAN tags and protocol families live. Nokia achieves the same separation differently, by binding a physical port to a named logical interface. Cisco and Huawei collapse both layers into the physical interface unless you configure subinterfaces.

Command Verb Mapping

The persist row is the one that bites hardest. On Junos, a successful commit is already persistent - the candidate configuration is checked, activated and written to /config in one step, so there is no separate "save". On Huawei VRP, the opposite is true: system-view commands take effect immediately and a reboot discards everything you have not explicitly saved. Nokia sits between the two - commit activates, but the configuration file itself is written by admin save. Cisco IOS is closest to Huawei, which is exactly why engineers who move from IOS to VRP get away with unpractised habits until the first power cycle.

OSPF Configuration

# Cisco IOS
router ospf 1
 network 10.0.0.0 0.255.255.255 area 0

# Juniper Junos
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0

# Huawei VRP
ospf 1
 area 0
  network 10.0.0.0 0.255.255.255

# Nokia SR OS
/configure router ospf area 0 interface "to-core"

OSPF exposes the deepest philosophical split in the group. Cisco, Huawei and Juniper-with-the-network-alternative (not shown) can enable OSPF on interfaces by matching an address range with a wildcard mask. Junos and Nokia enable it per interface, by name. The per-interface model is more precise: it cannot accidentally enable OSPF on an interface you forgot about because the interface now sits inside a summarised range. The range model is more compact on a device with hundreds of access interfaces. When you translate Cisco configuration into Junos, the wildcard-to-interface conversion is the step that most often gets missed, and the symptom is an adjacency that simply never forms because the interface was never placed in the protocol.

Note also that Huawei nests the area one level deeper than Cisco: ospf 1 then area 0 then network. Copy-pasting a Cisco OSPF block into VRP without adjusting the indentation level produces syntax errors rather than silent misconfiguration, which is at least a fail-safe.

BGP Peering

# Cisco IOS
router bgp 65001
 neighbor 203.0.113.5 remote-as 65002
 neighbor 203.0.113.5 password Str0ngBGP!

# Juniper Junos
set protocols bgp group EBGP neighbor 203.0.113.5 peer-as 65002
set protocols bgp group EBGP neighbor 203.0.113.5 authentication-key "$9$abc123"

# Huawei VRP
bgp 65001
 peer 203.0.113.5 as-number 65002
 peer 203.0.113.5 password cipher Str0ngBGP!

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

All four platforms describe BGP the same way - local AS, peer address, peer AS, authentication - but Junos and Nokia force you to name a group before you can define a neighbor, while Cisco and Huawei let you configure a peer at the top level and attach policy afterwards. The group is a design decision, not a syntax quirk: it becomes your policy attachment point, and operating 200 peers through 12 groups is considerably less error-prone than operating 200 peers individually.

Authentication is where translation produces outages. Junos stores the key obfuscated as $9$...; you cannot copy that string into a Cisco configuration. Huawei distinguishes plaintext (simple) from encrypted (cipher) keys, and the choice affects whether the key is recoverable from the configuration. When migrating a peering between vendors, always re-enter the shared secret as plaintext on both ends during the change window and verify the TCP session comes up before removing the old configuration.

VLAN Trunking and ACLs

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

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

# Cisco ACL
access-list 100 permit tcp any host 10.1.1.1 eq 22
access-list 100 deny ip any any

# Juniper firewall filter
set firewall family inet filter SSH-RULE term 1 from protocol tcp
set firewall family inet filter SSH-RULE term 1 from destination-port 22
set firewall family inet filter SSH-RULE term 1 then accept

L2 configuration shows the sharpest structural difference in the whole cheat sheet. Cisco and Huawei define a VLAN globally and then list the VLANs a port carries; Huawei makes the port's role explicit with port link-type trunk or access. Junos puts the VLAN membership on the logical interface as a vlan-id and allows multiple units per physical port. Nokia treats a VLAN as a named object and attaches ports to it, which reads almost like an intent statement: "VLAN 10 carries tagged traffic on port 1/1/1".

The ACL comparison is equally instructive. Cisco access lists are ordered statements applied to an interface with ip access-group; Huawei ACLs are named or numbered rule sets applied with traffic-filter. Junos and Nokia do not have an equivalent of a numbered access list at all - both use a structured filter with named terms, each term carrying its own match conditions and action. This is why "the firewall rule" is never a one-to-one translation: you are converting a statement list into a decision tree, and you must add an explicit then accept or discard term to reproduce the implicit default behaviour the other platforms assume.

Verification Command Comparison

Two rows deserve comment. Huawei's display bgp peer reports state, uptime and prefix counts in a denser format than Cisco's show ip bgp summary, and the state names differ: VRP prints Established just like IOS, but intermediate states such as Idle, Connect and Active carry the same meaning only if you remember that "Active" means "trying to connect and failing". Nokia's configuration is not a file to be displayed but a running database, so admin display-config is the correct command and it accepts filters that show only what has changed from the defaults - an extremely useful habit when auditing a device you did not build.

Why the Syntax Diverges

None of these differences are arbitrary, and understanding the reason makes them easier to remember. Cisco IOS and Huawei VRP inherited a flat, imperative CLI in which every command is a command. Junos and Nokia SR OS were built from the start around a configuration database: the CLI is a thin editor over that database, which is why every statement is a complete path (set ... or /configure ... path ... value), why changes are staged, and why rollback exists. Junos pushes this furthest, treating configuration as a text document that can be replaced, diffed with show | compare, and rolled back by number. Nokia keeps the database but presents a navigation-tree editor, so you move into a context and then set values rather than writing one full path per line.

Huawei VRP is deliberately closer to IOS than to Junos - a fact that surprises engineers who expect a completely foreign CLI. Interface configuration, access lists, OSPF network statements and even the BGP syntax shape are recognisably IOS-like. The reliable differences are the verb (display, undo, save), the numbering of interface slots (0/0/1 rather than 0/1), and the extra nesting levels in protocol configuration.

Translation Rules That Prevent Outages

• Never translate a command without translating the save model at the same time. Ask "does this platform apply immediately, and does it need an explicit save?" before you type anything.
• Convert wildcard-mask OSPF/EIGRP network statements into explicit interface statements when the target is Junos or Nokia. Verify with the neighbor command, not with the configuration.
• Translate ACLs as decision trees, not line lists. Add an explicit final term on Junos and Nokia that matches the implicit deny you expect.
• Re-enter authentication secrets in plaintext on both ends during a cross-vendor migration; encrypted forms are platform-specific and non-portable.
• When comparing outputs, compare semantics, not formats. Uptime, counters and state names are presented differently on every platform.
• Take a configuration backup on the target device before the window, and know the rollback command for each platform in advance.

Practical Translation Tips

• Cisco show = Junos/Huawei/Nokia show (Nokia) but Huawei uses display - when in doubt try display on VRP gear.
• Cisco no prefix = Junos delete = Huawei undo.
• Junos and Nokia require explicit commit/save before changes persist; Cisco IOS and Huawei apply-and-save separately.
• Junos interfaces always need a logical unit; Cisco and Huawei do not unless the port carries multiple VLANs or families.
• ? works everywhere - and on all four platforms it is tab-completion-aware, so use it instead of guessing a keyword.

Which Platform to Reach For

Related Reading on This Site

See the Cisco vs Juniper troubleshooting cheat sheet and H3C vs Huawei CLI comparison for deeper pair-wise references, the Comware-to-VRP command mapping table for the third major Chinese CLI, and the scenario-based multi-vendor configure / verify / troubleshoot playbook.

原文链接：https://undercodetesting.com/cli-multivendor-cheat-sheet-for-network-engineers-essential-commands-across-cisco-juniper-huawei-and-nokia