A year and a half or so ago we bought some secondhand Juniper EX4200 switches for deployment to do OOB, camera, wifi, and other applications where inexpensive POE switches were appropriate, and the fact that they were EOL didn’t represent a barrier to acceptance.

The team was a little concerned because “it’s not Cisco or something that pretends to be”, so I wrote up a short cheat sheet on how to do password recovery and upgrade the software on them, so we could get things up and running.

The Juniper EX cheat sheet:

Suppose you’ve got a second hand switch fresh out of the box. First thing you probably need to do is perform password recovery on it. To do this, plug a serial console cable into the CON RJ45 port on the back and power on. This is a Cisco/Juniper/Sun/Adtran standard pinout not the ungodly “standard” RS232D pinouts that once proliferated on USR and 3Com devices. The RJ45 serial cable you have in your laptop bag should work fine.

Speed is 9600/8N1. Junipers as a rule are picky about parity. If you should have 7E1 by default on your terminal program, some characters won’t work.

Power on. Observe bios messages within a few seconds on the serial console. You’ll have a brief opportunity to hit space to interrupt autoboot and get a “boot>” prompt. At that point, “boot -s” will boot to single user. Read the prompt carefully. You’ll have the opportunity to select “recovery” instead of “/bin /sh” for your shell, which will get you the new plaintext root password prompts.

After you reboot, you’ll login as root with your new password and get a shell prompt. To run the Juniper CLI, type “cli”.

Doubtless you’ll want to upgrade the software. There are two OOB ports on the back: CON (serial console, which you’ve already used) and MGMT (management ethernet). You can’t route over the management ethernet (not a separate VRF anyway) so don’t even bother trying. But it’s useful for copying in software upgrades on an otherwise unconfigured switch.

Before we get to that point though, set the date/time. This need not be exact. But Juniper’s software packages are signed with X.509 certs and they can’t be validated if the clock is reset to 1970 or something.

set date 201809072130

Now we can set up the management ethernet and SSH:

configure
set system services ssh protocol-version v2
set interf me0 unit 0 family inet addr 192.168.255.1/24
commit and-quit

Plug in an ethernet between it and your laptop, set a different ip address on your laptop ethernet, and SCP the new jinstall software bundle in (note that the bundles are different for different models of switch and that’s reflected in their names). You may wish to try to ssh in as root first in order to make sure that ssh is actually running.

maddog:Downloads rs$ scp -p jinstall-ex-4200-15.1R7.8-domestic-signed.tgz root@192.168.255.1:/var/tmp/
root@192.168.255.1's password: jinstall-ex-4200-15.1R7.8-domestic-signed.tgz 100% 132MB 3.3MB/s 00:40
maddog:Downloads rs$

Once it’s copied in, you actually start the upgrade with:

request system software add /var/tmp/jinstall-ex-4200-15.1R7.8-domestic-signed.tgz

When that’s done,

request system reboot

will actually boot into the new OS partition.

The EX series switches (since Junos 10.3 or thereabout) have dual boot capabilities from primary and backup partitions. You might think this is primarily as an upgrade/rollback function, and certainly it could be used for that, but in RS’ experience the more common use is to recover from a boot partition failure. This happens more often than you might think - like most Unix systems, Junos is not especially thrilled with having its power unceremoniously yanked. Yet still people do it, because most of the time you get away with it.

The right way to power down a Junos system, by the way, is:

request system power-off

But I digress. When you have a configuration of an EX switch which you’re happy with, it behooves you to back it up.

show system storage partition

will give you some information about what you’re booted from. Note that the physical devices associated with “primary” and “alternate” depend on what you booted from. The one that you’re not booted from will always be “alternate”.

So,

request system snapshot media internal slice alternate

will back up your currently running configuration to the “other” boot device. More reading here.

You might be swapping out a broken system and want to install an archived config, or you might want to start with an archived configuration, rename, re-IP, and move forward as a good beginning point for a new switch.

More on configuration file loading.

To replace an entire configuration, specify the override option at any level of the hierarchy. A load override operation completely replaces the current candidate configuration with the file you are loading. Thus, if you saved a complete configuration, use this option.

[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) filename <relative> <json>

So, at top-level,

load override terminal

will replace the whole configuration with a “show configuration” style config when you paste it in (not a “show configuration | display set” style configuration). Many of these tips and workflows are applicable to other Junos devices such as SRX firewalls and MX routers.