Being able to connect to a Juniper to device to configure it is an important consideration. Straight out the box you can’t remotely access your device through SSH (or Telnet if you hate security) as the services aren’t enabled and there’s no network address configured. You’re most likely to do an inital manual config through a serial connection (as with almost any Network equipment from any vendor).
You can use either the Console port or the Auxillary port for this initial config. (Pro tip don’t buy the crappy £3 ones you can get from ebay, they don’t work in half the network devices you plug them into and it’s incredibly frustrating. Spend a bit more on a decent USB to RS232 connector.)
From there open up your terminal, hit enter a few times and cross your fingers because it can be finnicky.
Once you have made that connection you’ll be asked for a username. When at factory setting this user will be root, and there will not yet be a password set on it. Also when signing into root, you will be signed in directly to the unix shell, so if you want to reach the Junos CLI you need to run cli. (This is actually very helpful, if there is something wrong with the CLI then you can investigate it at the package level).
Non-root users who are created after the initial login will not have to go through this process, they will be dropped straight into the CLI.
There are two modes in the Junos CLI, much like with Cisco. There is a Operational mode which is really for things like checking logs and ports with show commands, and Configuration mode which is geared towards actually editing the running config of these network devices.
Operational is the first mode you’re dropped into when running the CLI. You can tell you’re in configuration mode because at the start of the line it will say “user@hostname>”. The little greater than prompt is the clue.
There are little cheat codes you can use in operational mode with the help command, that will tell you a little bit about a command. (For example: help topic routing-options static. – doesn’t give you syntax but can give you a little reminder.)
If you want help on how to use a command syntaxically that’s there too – and is called on with (for example) help syntax routing-options static.
Active versus candidate configuration
From operational mode you can enter configuration mode. There are three different configuration modes you can enter. You can either:
1- Type configure on its own. -This creates a candidate configuration on the device, a config that is not currently the config of the box but can be modified and changed without impacting the currenty running state, that won’t be committed until we are ready to commit it. If multiple people do the same thing at the same time they will all be sharing that one candidate configuration file. That can be disastrous.
2- Type configure private – Arguably best practice, in this mode each user gets their own private candidate configuration file to mess with. Again they can change it however they want without affecting the current running of the device and can apply it when they are ready.
If seperate users both merge their private config files – the system intelligently handles it (you don’t just overwrite what the other user has changed in the meantime, unless you change the exact same attribute – in that case whoever commited last gets to change that attribute).
Another thing to note when in configure private – you can only commit when you are at the top of the configuration tree.
3- Type configure exclusive – This is something of a nuclear option, when you configure exclusive you create a candidate that you can edit, and as before unapplied changes won’t be put into effect, but it gives that user an exclusive lock on the configuration of the device. If another user logs in and tries to edit the configuration they get an error message telling them the config database is locked. The only ways to fix this are for the person who has tried to configure exclusive needs to finish what they are doing and log out, or for another user with privilege to request the exclusive user is logged off / kills the session.
Configuration is the second mode you’re dropped into once you have selected the appropriate config mode, and you can tell you’re in this because the cli will start with “user@hostname#”. The hash mark is the clue this time, along with a banner in the square brackets so we know exactly what is being configured at a given time (much more specific than ios, useful when you’re as forgetful as me).
Once you are done making changes in configuration mode, you push out your canditate to be the active running config file by typing commit. When you commit a candidate Junos runs some sanity checking on it, looking for conflicting changes and then pushes it out. The order we make changes in in Junos is much less important than on IOS because it doesn’t apply the changes until we have finished.
Reverting to previous configurations
When you do type commit and the file becomes active it is stored in the config directory (/config/)
Not just the active configuration gets stored here, but the first three ‘rollback files’ are stored here too. By default 49 copies of previous configurations are retained as well in the /var/config directory.
We can view the details (date and time at which that file was made the active config) of these rollback files while in Junos config mode with the rollback command. This can be useful when debugging / working out what has gone wrong and when with a commit. (This can actually be done in operational mode too! show system commit).
Configuration files can be rolled back to using the rollback command too. For instance if you wanted to go to the most recent active configuration before your current one you would issue the command rollback 1 from config mode it would make that old configuration the current candidate configuration.
Editing Renaming and Comparing Configuration
Junos makes it fairly simple to compare configuration differences of candidates against against active configs.
If you make changes to a current candidate file and want to see what changes exactly have been made in relation to the active config you can pipe the show command to compare: show | compare
This is useful as it lets you see either what changes have been made from previous active configs by first using the rollback command, or what changes you have made on this candidate and possibly forgotten. Definitely something that would be worth checking before you commite a config to make sure there is nothing missing or there that could cause issues. – super helpful command.
Load Merge configuration – From config mode you can show the contents of certain files within the Junos CLI. (Similar to a CAT in linux). – this is done with the run file list command. They are stored in the /var/home/lab/ interface and can contain snippets of code that you can merge with your current config candidate.
You can view files stored using run file list and choose one with run file show FILENAME. Where FILENAME is the stored config.
From here, once you have confirmed you want to merge the contents of this file with the one in your candidate config you can run load merge FILENAME and it will overwrite the specific heirarchies laid defined in the file. – Note, this will try and copy it as is, so if it’s in the wrong hierarchy/edit branch it’ll come up with lots of errors. You also need to put relative on the end.
so if you were editing the config of a specific interface you’d run: edit interfaces to reach the correct heirarchy and then you’d run load merge FILENAME relative and it should update.
Display Set command is another very useful command. If you want to know the exact commands needed to implement an existing config. So for instance if you can see that an interface is assigned to a specific vlan and can’t remember how to assign that you could navigate to that hierarchy and run show | display set to see how it was done (from the root of the config tree). Again the relative keyword can be used to make this relative to the branch you’re on.
More exciting than that – you can use this feature to configure files with commands that would make repeating or only slightly changing the configurations much faster than setting them up one at a time. – you can paste whole configs into switches this way.
Load Override Configuration
You can also – rather than merging – just override the entire configuration file with a saved file. You’d do this with load override FILENAME and it will clear all of the existing config and load in only what is in the saved file.
It is sometimes necessary to deactivate commands in Junos CLI. This is simply done by running deactivate and then the configured command. This does not delete it from the configuration but it stops it being active – allowing it to be recovered at a later date if needed without jumping between old versions of the config. It’s not the same as shutting down an interface though – in Junos you do that by disabling the port (set disable interfaces ge/0/0/1) – also needs committing.
Modifying, managing, and saving configuration files
You can copy interface configurations with the copy command, for example: copy ge-0/0/1 to ge/0/0/2 which takes an exact copy of that port’s information and duplicates it.
Once this has been done it is fairly trivial swapping out information that you would want to be unique on each port, for instance IP addresses. This can be done with the replace pattern command.
So if in a heirarchy you have an IP address of say – 10.10.10.50 and you wanted to make it 10.10.10.55 you could run the command (while editing the interface) replace pattern 10.50 with 10.55 and it will swap it out. You could also use this to replace larger groups of information – for instance if you spelt the vlan name wrong for a whole group of interfaces. Also a super helpful command.
You can also annotate the configuration, leaving comments to explain yourself to future you (or other engineers). This is done with the annotate command.
For instance if you made a change and had to shut down a service running on an interface you would run a command that – for example does: annotate interface ge/0/0/4 “This is the reason I did the thing”. You can then see the command if you do a show command – they look like the kind of comments you get in C.
Navigating around the CLI takes a little practice. In Operational most of what you do is with show commands so you can show and tab your way through quite easily.
In Configuration mode there’s a little more to remember. You can use the edit command in a similar way to how you might use cd on other CLIs. so if you were to run the command edit protocols ospf you would jump to OSPF in the heirarchy and make changes to the OSPF configuration.
You can get back to the top of the tree with the command top.
If you don’t want to be that specific and editing down to the interface to then make changes – you can also specify the path (for instance show protocols ospf would have the same effect) – but it would be executed from the top of the tree. If you want to run a command from the top of the tree and don’t want to navigate out of it you can run the top command as well.
And if you just want to jump back a ‘directory’ or branch in the tree you can just use the up command.
Setting up management port and remote access
If you then correctly set up this imaginary routers fxp0 (management ethernet) interface with an IP address (this interface is embedded in the routing agent of an MX router. What’s great about this is that even when line cards are removed this port will still be accessible – it’s also management traffic only it can’t do routing stuff.)
You can then get to the device remotely using SSH (assuming the service is enabled). As best practice this is probably the first thing to do.
You can also enable other services for file transfers (SCP [secure copy protocol] is safter than FTP), you can also enable HTTP(s) for web gui management if that’s your style.
Junos Web GUI