Juniper PTX Update FPGA or BIOS

What this page is about

Junos OS and the firmware that lives on the hardware are two different things. Junos OS is installed on the Routing Engine disk and is upgraded with request system software add. The firmware layer — the RE BIOS ROM that boots the routing engine, the baseboard FPGA that manages the RE hardware, and the power supply (PEM/PSU) controller firmware — is programmed separately through the request system firmware upgrade command family. On a PTX class router the three commands you will see most often are:

request system firmware upgrade re fpga
request system firmware upgrade re bios
request system firmware upgrade re power

They look harmless, but each one writes to non-volatile memory inside the routing engine or inside the power hardware, and the new version normally only becomes active after a reload. Get the sequence right and it is a 20–40 minute maintenance window. Get it wrong — cut the power in the middle of a BIOS program cycle, or upgrade both routing engines at the same time on a dual-RE chassis — and you are opening a TAC case at 3 a.m.

This article is the complete procedure around those three commands: how to read the current firmware state, how to check that the right firmware package is installed, how to run the upgrade, how to verify it, how to recover, and the risks that actually bite people.

When you need to do this

• TAC points at a PR (problem report) that is fixed only by a newer FPGA or BIOS revision.
• The target Junos OS release has a minimum recommended BIOS/FPGA level, or the release notes list a firmware upgrade as part of the upgrade path.
• A chassis LED, fan tray behaviour, or power-supply reporting anomaly is traced back to old power/PEM controller firmware.
• The hardware is being re-deployed or RMA-replacement parts are at a different firmware level than the rest of the chassis, and you want everything aligned.
• You are preparing a router for a feature (for example certain 400G/800G optics or timing features) that depends on a specific FPGA revision.

Applicable devices and releases

• Platforms: PTX Series routers running Junos OS (the same command family exists on MX Series and on Junos OS Evolved platforms, with a different option set). On PTX10008 and PTX10016 the PEM firmware is a documented target of its own, managed with pem slot <slot-number> mcu (primary | secondary). PTX1000/PTX10002 class boxes expose RE FPGA, BIOS and CPLD entries in the same output.
• Firmware source: the firmware images ship inside the jfirmware package that is tied to a specific Junos release and platform. The firmware package for MX Series is not the same file as the one for PTX Series — never cross-load them.
• Release differences: the set of valid component names (fpga, bios, power, pem, cb, ctrl-fpga, fancpld, optics CPLDs and so on) varies by platform and by Junos release, and new options are added over time. Before you schedule the window, type the command and let the CLI tell you what it accepts:

user@ptx> request system firmware upgrade re ?
Possible completions:
  bios                 Upgrade BIOS
  ctrl-fpga            Upgrade Control FPGA
  fancpld              Upgrade fanboard CPLD
  fpga                 Upgrade baseboard FPGA
  no-validate          Don't validate the upgrade request
  progress             Check the progress of the upgrade

If power is not in the completion list on your build, that platform exposes the power hardware under a different target (for example pem ... mcu on PTX10008/PTX10016, or a PEM entry that is updated together with the baseboard firmware). Always confirm against the CLI completion and the platform's documentation rather than assuming the three commands below are identical everywhere.

Prerequisites and pre-checks

• Out-of-band console access. A firmware upgrade ends with a reload. Do not do this over an SSH session that rides the router's own data path.
• A maintenance window. FPGA/BIOS upgrades on the routing engine are traffic affecting because of the required reload.
• Redundancy plan. On a dual-RE chassis, upgrade one routing engine at a time so the second RE can carry the control plane. Do not run the same command on both REs in parallel.
• Backups. Save the configuration and take a system snapshot before you touch firmware:

user@ptx> show configuration | save /var/tmp/ptx-config-$(date +%Y%m%d).conf
user@ptx> request system snapshot

• Check the software level first. Confirm which Junos release and which firmware package are installed. If an older jfirmware package is still hanging around, it has to be removed before the new one is installed — that is documented behaviour, not folklore:

user@ptx> show version | match jfirmware
user@ptx> request system software delete jfirmware

• Know your disk space. The firmware package plus the images need space on the RE. request system software add needs a clean /var/tmp; a stale package or core file can break the add.
• Power and environment. Confirm both PEMs/PSUs are present and healthy, all fan trays are populated, and the chassis is on protected power. Programming firmware with a brownout is how a serviceable RE becomes an RMA.

Step 1 — read the current firmware state

The authoritative view of what is installed versus what the software package can install is show system firmware. The Current version, Available version and Status columns tell you exactly which parts need work. A representative output (abbreviated; exact parts differ between MX, PTX and Junos OS Evolved platforms) looks like this:

user@ptx> show system firmware
Part             Type           Tag Current   Available Status
                                   version   version
CB 0             CB FPGA        0   0.4.0     0.4.0     OK
Routing Engine 0 RE BIOS        7   0.13.1    0.11.01   OK
Routing Engine 0 RE FPGA        2   405.0.0   402.0.00  OK
Routing Engine 0 RE SSD1        3   12028     12028     OK
Routing Engine 0 RE BITSCPLD    9   2.6.0     2.214.0   OK
Routing Engine 1                0   0.0.0               OK
PEM 0            PSU DC         8   1.11.0              OK

How to read it:

• Current version lower than Available version → an upgrade is available and can be requested for that part.
• The Tag column is the tag number you reference when a command needs to target a specific part.
• Status is OK in steady state, PROGRAMMING while a write is in flight, and UPGRADED SUCCESSFULLY when the new image is written and waiting for a reload.

Two useful complementary views:

user@ptx> show chassis firmware
user@ptx> show chassis hardware | match "PEM|PSU|RE " 

show chassis firmware gives a per-chassis part/type/version list (BIOS, RE-FPGA, CPLD and so on) and, on platforms where it is supported, reports both routing engines even though the primary RE only sees its own firmware through show system firmware — a practical trick when you need to confirm the backup RE is already at the right FPGA level without switching mastership.

Step 2 — make sure the firmware package matches the release

Firmware images are delivered with the software release. If the firmware package is missing or stale, install the one that belongs to the running Junos release:

user@ptx> request system software add /var/tmp/jfirmware-x86-32-XX.XRXX.X.tgz
user@ptx> show version | match jfirmware

Do not skip the version check: a mismatched firmware package is the most common reason a part shows an Available version you did not expect, or shows nothing at all to upgrade. On VM Host based routing engines (for example RE-PTX-X8) the host OS and the Junos package are installed separately and several legacy request system commands behave differently — check the platform-specific documentation before you assume the command set in this article is identical on that RE.

Step 3 — run the three upgrades, one component at a time

Run the commands from the operational CLI on the routing engine you are working on. Take them one at a time so that a failure is isolated to one part, and read the confirmation prompt before you accept it.

user@ptx> request system firmware upgrade re fpga

Part                   Type            Tag  Current   Available Status
                                            version   version
Routing Engine 0       RE FPGA         2    402.0.0   405.0.0   OK

Perform indicated firmware upgrade ? [yes,no] (no) yes

Firmware upgrade initiated for Routing Engine 0 RE FPGA

user@ptx> request system firmware upgrade re bios
user@ptx> request system firmware upgrade re power

Practical notes on each target:

• re fpga — programs the baseboard FPGA. This is the one that most often carries a PR fix, and on some platforms it also covers more than one tag (a CB FPGA or a control FPGA may appear as a separate line in show system firmware and may need its own request).
• re bios — programs the RE BIOS ROM. The routing engine keeps an active and a backup BIOS image, and the system boots from the active one — so a failed BIOS write is not automatically fatal, but you still need a stable power feed and a stable console until it completes. Some builds additionally accept a progress keyword to poll the BIOS write rather than watching show system firmware.
• re power — programs the power supply controller firmware. On PTX10008/PTX10016 the documented mechanism for PEM firmware is request system firmware upgrade pem slot <slot-number> mcu (primary | secondary). Power firmware is the slowest and the most sensitive to interruption: never pull a PEM, and never power off the chassis while this is running.

Step 4 — monitor until the write completes

The upgrade is not finished when the command returns. Poll the firmware table until the status settles:

user@ptx> show system firmware

Part             Type           Tag Current   Available Status
Routing Engine 0 RE FPGA        2   402.0.0   405.0.0   PROGRAMMING

...
Routing Engine 0 RE FPGA        2   402.0.0   405.0.0   UPGRADED SUCCESSFULLY

PROGRAMMING means a write is in progress — do not reboot, do not commit, do not remove power. Depending on the component this can take several minutes; the FPGA and power targets take longer than the BIOS ROM on most PTX hardware.

Step 5 — reload and verify

The new firmware becomes active only after the routing engine boots again:

user@ptx> request system reboot
user@ptx> show system boot-messages | last 20
user@ptx> show system firmware
user@ptx> show version

Verification means three things, all of them:

• show system firmware no longer lists the part as needing an upgrade: the version you saw under Available version is now the Current version, and the status is OK (not UPGRADED SUCCESSFULLY, which simply means “written, not yet active”).
• The chassis comes up with no new alarms: show chassis alarms, show chassis environment pem, show chassis environment.
• Traffic and control plane behave as before the window — protocols re-establish, interfaces are up (show interfaces terse, show route summary).

Dual routing engine chassis: the safe order

1. Upgrade the backup (non-master) RE first, using a session on that RE — log in to re1 and run the same request system firmware upgrade re ... commands there. The firmware command acts on the routing engine it is executed on; repeating the documentation's instruction to “repeat the steps on the other Routing Engine” is the correct interpretation.
2. Reload the backup RE only (request system reboot from that RE, or reboot it with the mastership still on the primary) and verify.
3. Switch mastership (request chassis routing-engine master switch) and verify the control plane is stable on the newly promoted RE.
4. Now upgrade the RE that has become the backup, reload it, and verify.
5. Leave mastership where your operational practice wants it, and take a fresh snapshot (request system snapshot) on the master.

Rollback and recovery

• There is no universal firmware downgrade command. What the router can install is defined by the Available version carried in the installed firmware package. Going back to an older FPGA/BIOS level means installing an older Junos/firmware package (or a jfirmware package that carries that level) and re-running the upgrade request — plan for a second maintenance window, and check with JTAC before doing it on a production chassis.
• If a firmware write fails: delete the firmware package and install it again, then retry the upgrade. This is the documented recovery path:

user@ptx> request system software delete firmware-package-name
user@ptx> request system software add firmware-package-name
user@ptx> request system firmware upgrade re fpga

• If the RE fails to boot after a BIOS upgrade: the platform keeps a backup BIOS image, so the chassis can fall back; recovery may require console access, the boot menu, and possibly a USB or PXE boot of a Junos image. Have the console server and the software image ready before the window, not after.
• Configuration rollback is separate from firmware rollback. request system software rollback and rollback 1 in configuration mode deal with software and config, not with FPGA/BIOS revisions. Do not confuse the two when writing your back-out plan.

Risk warnings

• Do not interrupt a programming cycle. Power loss, a hard reset, or a pulled PEM while the status is PROGRAMMING can leave the FPGA/BIOS or the PEM controller in an unusable state.
• Expect a reload — schedule it, do not discover it.
• One component, one RE at a time. Batching all three upgrades plus both REs plus a Junos upgrade into one window maximises the blast radius and the ambiguity if something fails.
• Version skew inside the chassis is a real operational risk. If fan trays or PEMs are at mixed firmware levels, the chassis may report alarm states that look like hardware faults.
• Read the release notes and the PR. A firmware level that fixes one PR sometimes changes LED behaviour or telemetry fields, which your monitoring may treat as a fault. Update the monitoring expectations at the same time.

Troubleshooting quick table

• No upgrade offered for a part / Available version blank — the installed firmware package does not carry an image for that part, or the package belongs to a different platform. Check show version | match jfirmware and re-install the correct jfirmware for the Junos release.
• Command rejected / option not found — the option name differs on your platform or release. Use CLI completion (request system firmware upgrade ?, then ... re ?) to see what this build accepts; for PEM hardware on PTX10008/PTX10016 use the pem slot ... mcu form.
• Status stuck in PROGRAMMING — wait for the documented completion time; verify the console log and show system alarms. If the process truly dies, restart the RE and retry after deleting and re-adding the firmware package.
• Status UPGRADED SUCCESSFULLY but version unchanged after reload — the reboot did not happen, the RE booted from another image/partition, or you rebooted the wrong RE. Check show system uptime and show chassis routing-engine.
• Backup RE never gets its firmware updated — you ran the command only on the primary. The request acts locally; log in to the other RE and repeat.

Quick reference

show system firmware                                  # current vs available, per part
show chassis firmware                                 # per-chassis firmware view
show version | match jfirmware                        # is the firmware package present
request system software delete jfirmware              # remove a stale firmware package
request system software add /var/tmp/jfirmware-*.tgz   # install the matching package
request system firmware upgrade re fpga                # baseboard FPGA
request system firmware upgrade re bios                # RE BIOS ROM
request system firmware upgrade re power               # power supply/PEM firmware
request system firmware upgrade pem slot 0 mcu primary # PEM MCU firmware (PTX10008/10016)
request system reboot                                  # activate the new firmware
request system snapshot                                # back up the software state
show chassis alarms ; show chassis environment pem     # post-upgrade health check

Treat the three commands at the top of this page as the beginning of a procedure, not the procedure itself: read the current state, confirm the package, upgrade one target at a time, watch the status settle, reload deliberately, and verify with the firmware table, the chassis alarms and the control plane before you close the window.