Juniper EX系列交换机命令安装tgz包

什么是 Junos 软件包

Junos OS 是 Juniper 网络设备（EX 交换机、SRX 防火墙、MX 路由器等）的操作系统，软件以 .tgz 压缩包形式发布，例如 jinstall-ex-3300-15.1R7.9-domestic-signed.tgz（EX 系列系统包）、junos-srxsme-19.1R3.9.tgz（SRX 系列系统包）。通过 install 命令加载软件包，即可完成系统升级或重新安装。

install 命令说明

install file:/// 从设备本地路径加载软件包，适用于通过 USB 存储或已拷贝到本地的镜像文件进行安装。安装完成后需要 reboot 重启设备生效，可用 show system software 或 show version 确认版本。

USB 安装命令

USB安装命令：

install file:///jinstall-ex-3300-15.1R7.9-domestic-signed.tgz

install file:///junos-srxsme-19.1R3.9.tgz

包名SRX部分最低版本要求

junos-srxsme-19.1R3.9.tgz

包名与版本要求

包名需与设备型号匹配：EX3300 对应 jinstall-ex-3300 系列包，SRX 系列对应 junos-srxsme 系列包，且 SRX 部分存在最低版本要求，低于要求版本无法直接升级。domestic 后缀表示中国区版本，与标准国际版不通用。

注意事项

1. 升级前务必执行 save configuration 备份配置；2. 确认设备型号、包名与版本匹配，避免升级失败；3. 安装过程（含 reboot）严禁断电，否则可能导致设备无法启动；4. 生产环境升级建议选择业务低峰期，并在升级前咨询 Juniper 官方支持确认升级路径。

Understanding the Junos Package Model

Junos OS is distributed as a small number of release-specific package files, and every one of them is platform-bound. The package that runs on an EX3300 is not the package that runs on an EX4300, and neither of them is the package that runs on an SRX branch device, even though the release number printed in the filename may be identical. Junos refuses to install a package built for a different platform, and the failure is usually immediate — which is the good outcome. The bad outcome is installing a package that is accepted by the platform check but is not the release your configuration and hardware support require.

Junos packages fall into a few broad families, and the filename prefix identifies the family:

• jinstall-<platform> — the full system image for a specific hardware platform, such as jinstall-ex-3300. This is the standard complete upgrade package.
• junos-srxsme-<release> — the branch (small and medium enterprise) SRX system package, used for SRX100 through SRX300-series style devices.
• junos-<platform> variants — service, routing and MX/PTX family packages, where the release train and hardware support differ from the branch and EX lines.
• Optional add-on packages — components such as additional software modules, J-Web packages or specific feature images, installed alongside or after the base system.

The practical rule is that you install a base system package first and any add-on packages second, and that you never assume a package is correct because a search result or a filename looks familiar. Match the platform, match the release train, and confirm the upgrade path is supported by Juniper before you copy anything into the device's filesystem.

Reading a Junos Package Filename

A filename such as jinstall-ex-3300-15.1R7.9-domestic-signed.tgz carries five pieces of information, and misreading any one of them is a common cause of a failed or wasted upgrade.

The domestic segment deserves explicit attention. Devices in China are frequently shipped with a China-region image, and cross-flashing between a domestic build and an international build of what appears to be the same release is not a supported operation. If a device is running a domestic image, upgrade it with a domestic image.

The install Command: What It Actually Does

The install command in the Junos CLI is the local-file counterpart to request system software add. Instead of fetching a package over TFTP, FTP, HTTP or SCP, it takes a file that already exists on the device's own filesystem — which in practice means a file on USB storage, or an image you have already transferred into a local directory.

install file:///jinstall-ex-3300-15.1R7.9-domestic-signed.tgz

The file:/// prefix is the Junos pseudo-URL for the local filesystem, and the triple slash is not a typo: the first two slashes introduce the URL scheme, and the third begins the absolute path. The path that follows is resolved from the root of the media the device presents, which is why USB installs are usually written as a single filename rather than a nested directory path.

What the command does, in order: it validates that the file is a Junos package, checks that the package is built for the running platform, verifies the signature on signed images, unpacks the components into the device's alternate software partition or snapshot area, and stages the release so it becomes active on the next boot. It does not reboot the device and it does not make the new release active immediately.

install file:///junos-srxsme-19.1R3.9.tgz

For the SRX branch family, the same mechanism is used with the junos-srxsme package. On these platforms the install is comparatively fast, but the reboot that follows is where the time is spent, and the device must not lose power at any point during either phase.

Preparing the USB Media

The install works from whatever the device mounts. Prepare the media before you go on site, since the failure mode of a badly prepared USB stick is a device that has been taken out of service for an upgrade that cannot proceed.

1. Format the USB device with a filesystem the platform can read — FAT32 is the safe choice for most platforms and is what a Junos USB install expects by default.
2. Copy only the packages you intend to install, and copy them at the root of the filesystem so that file:///<name>.tgz resolves without a directory component.
3. Verify the file integrity after copying. Transfer errors on large packages are common and produce an install that fails partway through: file checksum sha-256 /path/to/package.tgz on the device, compared against the checksum published by Juniper.
4. Check the file size against the published size. A truncated copy looks like a valid file to the operating system but fails the package validation step.
5. If the device is a Virtual Chassis or a stack, plan for the fact that each member needs to be upgraded and that the reboot sequence is per-device rather than per-chassis.

Running the Installation Step by Step

1. Record the current state: show version, show chassis hardware and the current rescue configuration. This is your rollback reference and your proof of what was running before.
2. Back up the configuration: save configuration, and copy the file off the device, not just into its local filesystem.
3. Identify the package and confirm it matches the platform and the supported upgrade path.
4. Insert the USB media and confirm the device can see the file, for example with file list / or by listing the mounted media from the shell.
5. Run install file:///<package>.tgz and read the output. A signature or platform mismatch is reported here, before anything is written.
6. Wait for the command to complete. Do not interrupt it, do not remove the USB media, and do not start a second operation in parallel.
7. Confirm the staged release with show system software before rebooting, so that a bad staging step is discovered while the device is still running the old release.
8. Reboot with request system reboot.
9. Wait for the device to come back — this can take considerably longer than a normal boot — then confirm with show version.
10. Verify the configuration loaded as expected, that all interfaces and protocols came up, and that the new release is the one you intended.

Verifying the Installed Software

Three commands answer three different questions, and it is worth running all three rather than trusting one.

show version
show system software
show system snapshot media internal

show version reports the release the device is currently running, including the build and the platform string — the authoritative answer to "what am I running now". show system software lists the software components and packages known to the system, which is how you confirm that the package you installed is the one the system recognises, rather than a stale file left on the media. show system snapshot shows the snapshot or alternate partition state, which is what a rollback would restore. A successful upgrade should leave all three consistent; if show version shows the new release but the snapshot still shows the old one, capture that fact before doing anything else, because it changes the recovery options available to you.

Rebooting and What to Expect

The reboot is the phase that carries the most risk of perceived failure. A first boot after an upgrade is slower than a routine restart because the system may rebuild internal state and regenerate files. Do not conclude the device is bricked because it has been quiet for several minutes; watch the console if you have one, and give the device its full boot window before intervening.

After the device is up, do not declare success on the basis of show version alone. Verify the operational state that matters for the change window: interface status, routing adjacencies, switch uplinks, and any services the device terminates. An upgrade that completes cleanly but leaves an interface admin-down is still an outage.

The SRX Minimum-Version Constraint

For the SRX branch family, a minimum software version applies before certain packages can be installed. A device running a release below that minimum cannot jump directly to the newer package; it must first be brought up to the minimum release, typically by installing an intermediate package and rebooting, and only then upgraded to the target release. Attempting to skip the intermediate step results in an install that is rejected or, worse, a device that boots into an unusable state and must be recovered from the console.

junos-srxsme-19.1R3.9.tgz

Once the intermediate release is installed and running, the target package installs normally with the same install file:/// mechanism. The specific minimum version depends on the platform and the target release, so confirm it against the release notes or Juniper support before scheduling the window — this is the single most common reason a planned SRX upgrade does not complete.

Recovering from a Failed Install

Junos is designed so that a failed upgrade is recoverable, and the recovery options are worth knowing before you need them.

request system software rollback
request system snapshot
request system reboot

If the device boots into the new release but the services do not come up as expected, request system software rollback switches back to the previous software on platforms that keep an alternate copy. If the device does not boot into the CLI at all, the recovery path is the console: interrupt the boot, enter single-user or recovery mode, and either restore the previous configuration or reinstall a known-good package from the USB media. The rescue configuration is the last-resort way to get a working configuration loaded so the device can be reached.

The reason the pre-upgrade steps matter so much is precisely this asymmetry: preparation takes minutes, and recovery takes a console session, a maintenance window, and physical access to a device that may be in a remote rack.

Common Failure Modes and Their Fixes

Pre-Upgrade Checklist

1. Confirm the target release is supported on this exact platform and in this release train.
2. Confirm the supported upgrade path — including any minimum-version step — before booking the window.
3. Record show version, show chassis hardware and the current configuration off the device.
4. Verify the package with its published checksum and file size.
5. Confirm the export variant (domestic versus international) matches what the device is running.
6. Have console access available, even if the upgrade is normally done in-band.
7. Schedule the window for low traffic, and arrange for no other change to touch the same rack during it.
8. After the upgrade, verify services, not just the version string.

Related Reading

• Junos OS Upgrade with request system software add — the remote-package counterpart to the local install method described here.
• SRX 设备升级步骤 — the SRX-specific upgrade workflow and its constraints.
• Juniper PTX: Update FPGA or BIOS — component firmware updates that accompany a platform upgrade.
• Juniper EX Switch Ops: Initial Setup and Key Commands — post-upgrade verification for EX switches.