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.
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.
That said users with the correct privilege level can run the command start shell from operational mode and get dropped back into the shell.
When signing into an unconfigured juniper device there will not be a password configured to the root account. Before any configuration can be applied as the running configuration a password needs to be set.
CLI Modes
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.
CLI Help
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.
The active configuration is stored in /config/juniper.conf.gz
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.
There are a couple of modifiers available to the commit command. Commit check looks at the configuration you are about to apply and if there are any syntax errors it will let you know. It also does a bit of a sanity check to make sure you aren’t referencing any policies that don’t exist or that there aren’t any configurations that are incompatible with each other. Check doesn’t then commit the candidate configuration, just lets you know if it sees an issue.
Commit confirmed is a very important one. It will make the candidate the active configuration but then automatically rolls the device back to the previous configuration unless you confirm it. So if you make a change and accidentally cut yourself off from the device, it will come back automatically (after 10 minutes with commit confirmed).
The way you then confirm the commit is just by issuing a standard commit command.
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.
If for whatever reason a configuration file is corrupt when Junos starts and it can’t find the config that should be the active config at /config/juniper.conf.gz it will try and load the rescue configuration (/config/rescue.conf.gz). If this can’t be found it will try and load the last working file (/config/juniper.conf.1.gz) and if it’s really messed up and can’t find that it will revert to /etc/config/factory.conf which is a very basic configuration – same as out the box.
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.
Deactivating Configuration
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.
CLI navigation
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.
Filtering Output:
Output is filtered using the pipe key (same as unix) – important commands to know putting after the pipe in:
compare – show|compare allows you to display differences between your candidate configuration and your active configuration.
display – allows you to display information in a different manner. (so instead of just a show command you can do display set command to make it more readable)
find – looks for the first occurance of the specified string of characters, and then from that point it will show you all the information in your configuration.
match – basically grep in Unix, it will only return output lines that have the string of characters specified.
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.
J-Web – Junos Web GUI
Juniper doesn’t only have a cli on which to configure it. There is also a web gui that can be used to configure Juniper devices and some organisations use this apparently (is it still flash based? If so I’m guessing they don’t)
In order to access the web gui there is a small amount of CLI setup that needs to be done. It’s not enabled out the box.
First as always the root-authentication password needs to be set in the CLI. The second step changes between devices but usually you need to enable J-web and set the http service to allow. You also need to check to see what the IP address is that’s assigned to your device by default. (might be 192.168.1.1 by default) else it would need to have an IP address assigned to it as well.
Dashboard
Once you have logged in you are presented with your dashboard. On this dashboard you get an image of your device, including a highlight to show which ports are plugged in. This image of a device has a card slot where you can put in a new card.
There is also a graph of resource utilisation that shows you the CPU and memory utilisation for both the control and forwarding planes as well as what percentage of the storage (internal flash memory) is being used.
Also shows the devices Serial Number, uptime, system time.etc – gives quite a good high level snapshot of the device.
Configure
There are setup wizards in the configure tab, and wizards for configuring PPPoE, FW policy, VPNs and NAT.
In the inital setup wizard first you put in information about your topology, what you’d like your security policy to be, what the NAT policy should look like, and then it will allow you to check and confirm the configuration that it would be applying, and to actually apply that.
Through this wizard you can either edit an existing configuration, or you can create a new one.
Though there are some configuration items that are not configurable through the J-web interface – Some items that can be configured from the configure part of the web menu are listed below:
- Interfaces
- Access
- NAT
- Security
- IPsec VPN
- Wireless LAN
- Switching
- Routing
- Class of Service
- System Properties
- Chassis Cluster
- Services
- CLI Tools
Monitor
There is a lot of information that can be monitored from the Monitor tab of the J-web interface as well. If you go onto the System View menu dropdown and select Chassis Information you can see the Model number of the device, as well as part number and serial number of our for instance routing engine. If we had a backup routing engine we would be able to see its details from this page too. Essentially we can get all the information from the chassis from this page. Lots of the important information here is also on the dashboard but you can look at the monitoring information for a lot of services and daemons on the device (MPLS, Routing, Switching, Wireless, NAT.etc.
Maintain
In the maintain tab there are options relating to viewing configuration management, to upload a new configuration, or to view our commit history or our rescue configuration (here we can set or rollback our rescue configuration). We can also download or rollback any of our previous commits that are still stored.
We can use the maintain tab to apply different licenses, do software upgrades, reboot the device, manage the dile system or take/rollback to snapshots of the system. – All this is done in the maintain tab.
Troubleshoot
The last tab in the web gui is the troubleshoot tab. There are a couple of tools that can be accessed here. Standard ping, mpls ping, traceroute, packet capture (which can be customised) and rpm, and you can also use a CLI terminal from here.