Translating a command between platforms is a vocabulary exercise. Show becomes display, neighbour becomes peer, and the hierarchy shifts by a word or two.
Underneath that sits a genuine architectural difference in how configuration is applied, and it affects operational practice far more than the syntax does.
Two configuration models
| Property | Immediate model | Candidate model |
|---|---|---|
| When a change applies | As each line is entered | When the change set is committed |
| Partial application possible | Yes | No |
| Validation | Per line | Whole set before applying |
| Undo | Reverse each line manually | Roll back to a previous state |
| Risk while editing | Half a change is live | Nothing is live until committed |
The immediate model is used by Cisco IOS and by Huawei VRP. The candidate model is used by Junos and by Nokia SR OS in its model driven form.
The practical difference appears during an access list change on a remote device. In the immediate model, the deny takes effect the moment it is typed and the permit that follows it has not been entered yet, which is a well known way to lose a session. In the candidate model, neither line is active until both are committed together.
Rollback changes what is possible
A candidate system retains previous committed states and can return to one by number, which converts an incorrect change from a reconstruction exercise into a single command.
It also supports a commit that automatically reverts unless confirmed within a time limit, which is the safest way to make a change that could remove your own access. If the change breaks connectivity, the device restores the previous configuration by itself.
Immediate systems address the same risk with an archive and a scheduled reload, which works and requires more preparation and more discipline.
The vocabulary, once
| Concept | Cisco | Juniper | Nokia | Huawei |
|---|---|---|---|---|
| Read state | show | show | show | display |
| Adjacent router | neighbor | neighbor | neighbor | peer |
| Enter configuration | configure terminal | configure | configure | system-view |
| Save | write memory | commit | admin save | save |
| Negate a line | no | delete | no | undo |
The last row is the one that catches people mid session, because the muscle memory for negating a line is strong and the wrong word produces an error rather than a result.
Hierarchy differs more than syntax
Cisco and Huawei use a largely flat configuration with mode changes, so the same statement can appear at several levels and its meaning depends on where it was entered.
Junos and Nokia use an explicit tree, where a statement's position fully determines its scope and the configuration can be displayed as structured data. That is why automation against those platforms is generally less painful, since the configuration is already a document rather than a transcript.
What this means when working across platforms
The translation worth internalising is not the command list, it is the model. Knowing whether a device applies changes immediately determines whether a remote change needs a safety net before it is started.
The command differences can be looked up in seconds. The consequence of forgetting which model you are on cannot be undone as quickly.
Note: on an immediate platform, build the whole change offline and paste it in one operation rather than typing it line by line. It does not provide the atomicity of a commit, and it substantially shortens the window in which half a change is live.