Updating the Router with JunosE Hotfix Files

A JunosE hotfix is a file or collection of files that you can apply to update an operational E Series router to address one or more specific, critical software issues. The hotfix can replace or add functionality to one or more software components. Hotfixes also enable the delivery of software updates without having to load an entire software release. Hotfixes can also deploy debugging code to collect data that facilitates troubleshooting of software issues.

Although most hotfixes can also be manually activated without reloading the router, some hotfixes cannot. You can configure any hotfix to be activated automatically when the router reloads.

A hotfix consists of a .hfx file and possibly other supporting files. The .hfx file manages the associated files in much the same way that a .rel file manages supporting files associated with a release image.

To use a hotfix, you must use the copy command to download the file from a network host to the router. You cannot copy the hotfix to an FTP file server. You can use file system commands such as dir, rename, and delete with the hotfix. After a hotfix is copied to the local flash card, it remains there until you explicitly delete it.

Hotfixes must be activated to take effect. A startup hotfix is automatically activated during system initialization. A hot-patchable hotfix does not require a reload to become active; it takes effect immediately if compatibilities and dependencies are correctly met. You can manually install hot-patchable hotfixes with the hotfix activate command. Hot-patchable hotfixes can also be configured to be activated as a startup hotfix.

Arming a hotfix prepares it for activation after a system reload. You can configure hotfixes in several ways with the boot hotfix and hotfix activate commands, as in the following examples:

Activated immediately on an active router but not armed as a startup hotfix. In this case, the hotfix is activated only until the SRP module reloads. If the SRP module reloads, then you must manually activate the hotfix again (if desired) with the hotfix activate command.
Activated immediately on an active router and armed as a startup hotfix. In this case the hotfix is automatically activated after every reload.
Armed as a startup hotfix with the boot hotfix command but not immediately activated. In this case the hotfix is activated when the SRP module reloads.

When a system reloads with the backup settings specified by the boot backup command, no armed hotfixes are activated. The currently armed hotfix settings are retained in the event that the router reverts back to its normal boot settings.

Hotfix Compatibility and Dependency

Hotfixes can have compatibility and dependency requirements. A given hotfix is compatible with one or more releases. It can be dependent on one or more other hotfixes being active. Compatibility and dependency requirements are stored as part of the hotfix. The requirements are enforced at the time of arming or activation. If the software installed and active on the router does not match the requirements specified in the hotfix, then activation of the hotfix fails. Such a failure generates appropriate error and log messages.

The following restrictions can apply to a hotfix:

Dependency—A hotfix that must be active or armed before another hotfix can be activated or armed.
Safe With—A list of hotfixes with which another hotfix is compatible and can safely be concurrently armed or activated. This list applies only to hotfixes that have some patched functionality in common and are armed or activated concurrently.
Unsafe With—A list of hotfixes with which another hotfix is not compatible and cannot safely be concurrently armed or activated. The CLI displays a warning message when you try to activate a hotfix that is unsafe with one or more active or armed hotfixes.
Manual Activate [Active / Standby] Srp—The name of a binary flag that indicates whether manual activation of the hotfix is allowed on the active and standby SRP modules. When the flag is set to false, you cannot manually activate the hotfix; instead, the hotfix can only be activated as a startup hotfix. The CLI displays a warning message when you try to activate a hotfix that cannot be manually activated.
Manual Deactivate [Active / Standby] Srp—The name of a binary flag that indicates whether manual deactivation of the hotfix is allowed on the active and standby SRP modules. When the flag is set to false, you cannot manually deactivate the hotfix. You must disarm the hotfix and reload the router. The CLI displays a warning message when you try to deactivate a hotfix that cannot be manually deactivated.
Line card requires reload—The name of a binary flag that indicates whether line modules require a reload for the hotfix to become active on the module. The CLI displays a warning message if the line modules must be reloaded. If the warning is confirmed, the SRP module reloads each line module. The flag applies to all line modules targeted by the hotfix that are installed in the router.

Hotfixes remain armed only for compatible releases. If you change the armed release by issuing the boot system command, hotfixes that are not compatible with the new release are no longer armed. However, if you subsequently rearm a compatible release, the previously armed hotfixes for that release are automatically armed again.

Removing Hotfixes

You can deactivate, disarm, and delete hotfixes from a router. When you deactivate a hotfix, any functionality that was added as part of the hotfix is automatically removed (even though the .hfx file remains on the router).

You cannot deactivate a hotfix that is a dependency for other hotfixes until you deactivate the dependent hotfixes. When a hotfix is no longer active, you can use the delete command to remove the hotfix file from the flash card.

Hotfixes and Backup Settings

The boot backup command does not explicitly support hotfix files. When a system reloads with the backup settings specified by the boot backup command, no armed hotfixes are activated. However, the armed hotfix settings are retained in the event that the system reverts to its normal (nonbackup) boot settings. If that happens, these hotfixes are automatically rearmed and reactivated after a reload.

Hotfixes and Standby SRP Modules

Hotfixes are supported in redundant SRP module configurations. Hotfix files are synchronized between the active and standby SRP modules by both automatic and manual synchronization. Hotfix activation restrictions are enforced identically on the active and standby SRP modules. A hotfix that is hot-patchable on the active module is hot-patchable on the standby module. A hotfix that requires startup activation on the active SRP module also requires startup activation on the standby SRP module.

Hotfixes are synchronized from the active SRP module to the standby SRP module. The standby SRP automatically activates the hotfixes that are armed as startup hotfixes. However, if the synchronization reveals that the set of active hotfixes on the standby SRP module is different from the set of armed hotfixes on the active SRP module, then the standby SRP module automatically reboots. This action causes the standby SRP module to activate the startup hotfixes. When you activate or arm a hotfix for startup activation, compatibility and dependency checks are performed independently on the active and standby SRP modules.

Hotfixes and Line Modules

For line modules, a hotfix consists of one or more image fixes specific to a particular model of module or to a module type, depending on the fix. When a hotfix is activated, each image fix contained in the hotfix is activated on all applicable modules that are installed in the router. When existing line modules come online during startup and when new line modules are inserted in the chassis, image fixes for that particular line module are requested and activated during module startup.

Line module image hotfixes that have been armed as startup hotfixes are activated before application configuration occurs on the line module.

Only image fixes contained in hotfixes that are active on the primary SRP module can be activated on the line modules during startup. Hotfixes that are armed but not active on the primary SRP module are not activated on line modules.

A hotfix can contain a combination of image fixes. System controller (SC) and interface controller (IC) image fixes are cumulative and activated in the order in which they were armed. For forwarding controller (FC) image fixes, the last one armed is the only one applied.

Note: Because image fixes are activated in a particular order, we recommend that you create a list of any hotfixes that you are currently running or intend to run with a new FC image fix. JTAC can then provide you with the correct order of activation.

A hotfix cannot be partially activated on a router. If activation of any image hotfix fails on any corresponding module, the entire activation fails for all applicable line modules. Activation failure results in the generation of an appropriate log message. E Series routers do not support activation of a hotfix on a per-slot basis or a per-subsystem basis.

For example, suppose that a hotfix contains an image fix for the SRP module and the GE-2 line module. The SRP image fix is successfully activated on the SRP module, but the activation of the GE-2 image fix fails for some reason. In this case, the SRP module image fix is deactivated and no further attempts are made to activate the image fix on other GE-2 modules.

boot hotfix

Use to arm the specified hotfix as a startup hotfix that is automatically activated the next time the SRP module reboots.
Arming fails if the specified hotfix depends on a hotfix that is not already armed. In this event, the CLI displays an error message similar to the following:
% The hotfix, 975, requires the following hotfixes to be armed: 990
Arming fails if the hotfix is not compatible with the armed release. The CLI displays the following error message:
% Hotfix is incompatible with armed release.
When a router reverts to its backup boot settings, as specified by the boot backup command, no armed hotfixes are activated. The armed hotfix settings are retained in the event the router reverts back to its normal boot settings.
Example
host1(config)#boot hotfix hf63037.hfx
Use the no version to disarm a specified hotfix. You can disarm all hotfixes armed for all releases by specifying the all-releases keyword. If any startup hotfixes are armed, the CLI then prompts you to confirm the deletion,
If the hotfix being disarmed is a dependency for another armed hotfix, the command fails and the CLI displays an error message similar to the following:
The hotfix, 990, has the following armed dependents which must be disarmedfirst: 975
% Disarming failed
When you disarm hotfixes that have dependencies, you must disarm them in the reverse sequence from which they were armed. However, if you have issued the all-releases keyword, the disarming automatically takes place in the correct order.
See boot hotfix.

no boot hotfix all-releases

Use in Boot mode to disarm all armed hotfixes for all releases.
Example
:boot##no boot hotfix all-releases
There is no affirmative version of this command; there is only a no version.
See no boot hotfix all-releases.

hotfix activate

Use to manually activate the specified hotfix.
Each image fix contained in the hotfix is downloaded from the local flash card to the SRP module and any corresponding line module, and then activated on the modules.
When a new line module is inserted in the router, all applicable image fixes are activated during initialization of the module. Activation is performed by the line module operational image before application configuration takes place on the module.
An activation failure for any image fix on its corresponding line module causes the entire activation to fail. The image fix is then deactivated on any modules on which it was successfully activated.
Activation fails if the specified hotfix is incompatible with the running release, In this event, an error message similar to the following is displayed:
% Hotfix is incompatible with running release.
Activation fails if the specified hotfix depends on other hotfixes that have not been activated. The CLI displays an error message similar to the following:
The hotfix, 975, requires the following hotfixes to be activated: 990
% Activation failed
Startup hotfixes cannot be manually activated. If you attempt to manually activate a startup hotfix, the operation fails and generates the following error message:
% Manual activation not allowed
Example
host1#hotfix activate hf63037.hfx
Use the no version to manually deactivate the specified hotfix. Deactivation restores the system to the state that existed before the hotfix was activated. You can specify the all keyword to deactivate all active hotfixes.
When you deactivate hotfixes that have dependencies, you must deactivate them in the reverse sequence from which they were armed. However, if you have issued the all keyword, the disarming automatically takes place in the correct order.
See hotfix activate.

Monitoring Hotfixes

Several commands provide information about hotfixes that have been loaded on the router. You can use the show hotfix command to discover the armed and activation status of all hotfixes or a specific hotfix. The output lists the hotfix by name and a unique ID number, which is useful if the filename has been changed. This command also displays dependencies for each hotfix; that is, other hotfixes that must be activated before that hotfix can be activated. For more usage details and sample output, see show hotfix.

The dir command displays all hotfixes present on the local flash card. The in use field indicates that the hotfix is either currently activated or armed to be activated as a startup hotfix for the currently armed release.

host1# dir
*** Active/standby file systems are not synchronized. ***
Active System Controller:
                                        unshared                          in 
          file                size        size          date (UTC)        use
-------------------------   ---------   ---------   -------------------   ---
reboot.hty                     596288      596288   03/07/2005 19:35:52      
system.log                       6762        6762   03/07/2005 17:30:08      
haIpSetup.mac                    4874        4874   03/24/2004 10:02:08      
6-0-1p0-5.rel               148489185   148489185   02/28/2005 18:17:32    !      
hf63035.hfx                     30445       30445   03/07/2005 14:04:02    !      
hf63030.hfx                     28675       28675   03/05/2005 18:22:32    
...

You can use the show version command to display a summary of each of the hotfixes currently activated on the system, including the hotfix name and hotfix ID.

host1#show version

Juniper Edge Routing Switch ERX-1400
Copyright (c) 1999-2005 Juniper Networks, Inc.  All rights reserved.
System Release: 6-0-1p0-5.rel               
        Version: 6.0.1 patch-0.5   (January 28, 2005  14:55)
        Active hotfixes: 
                  hf63036.hfx (Id: 1020)
                  hf63037.hfx (Id: 1030)
System running for: 7 days, 3 hours, 55 minutes, 5 seconds
        (since FRI FEB 04 2005 13:01:30 UTC)

The show boot command displays the current boot settings, including armed hotfixes that will be activated when the router reboots.

host1#show boot
 
System Release:   6-0-1p0-5.rel
        Armed Hotfixes: hf63035.hfx
        hf63036.hfx
        hf63037.hfx
System Configuration: running-configuration

The header of the show configuration command output includes the armed hotfix summary. You can issue the show configuration system file-system command to display the boot hotfix commands that restore the router to its current configuration when you issue the configuration script on a router configured with factory defaults.

Hotfixes that are active when you issue the show configuration command are not part of the command output or the resulting configuration script. Only armed hotfixes are part of the show configuration script.

host1#show configuration system file-system

! Configuration script being generated on TUE MAR 22 2005 16:43:41 UTC
! Juniper Edge Routing Switch ERX-1400
! Version: 6.0.1 patch-0.5   (January 28, 2005  14:55)
!  Active hotfixes: hf63036.hfx (Id: 23453036)
!                        hf63037.hfx (Id: 34563037)
! Copyright (c) 1999-2005 Juniper Networks, Inc.  All rights reserved.
! 
! Commands displayed are limited to those available at privilege level 15
! 
boot config running-configuration
boot system 6-0-1p0-5.rel               
boot hotfix hf63036.hfx
boot hotfix hf63037.hfx
no boot backup
no boot subsystem
no boot backup subsystem
no boot force-backup

show hotfix

Use to display the name, ID, activation and arming status, and dependencies for all hotfixes or a specific hotfix available on the local file system.
You can issue the detail keyword to additionally display a synopsis of the hotfix behavior. The detailed output for a specific hotfix also indicates compatible and incompatible hotfixes and lists modules affected by the hotfix.
Field descriptions
- name—Filename of the hotfix
- id—Number uniquely identifying the hotfix; nonconfigurable so that you can identify the hotfix if the filename has been changed
- active—Status of hotfix activation; X indicates that the hotfix is active
- armed—Status of hotfix arming; X indicates that the hotfix is armed to be activated; only hotfixes armed for the currently armed release are displayed as armed
- requires—Hotfix ID number or numbers identifying hotfix dependencies, which are hotfixes that must be activated before this hotfix can be activated
- synopsis—Brief description of the functionality or behavior of the hotfix
- Description—More detailed description of the functionality or behavior of the hotfix
- Dependencies—Hotfix ID number or numbers identifying hotfix dependencies, which are hotfixes that must be activated before this hotfix can be activated
- Safe to repatch—Hotfix ID number or numbers of hotfixes that can be concurrently active with this hotfix; applies only to hotfixes that fix the same existing functionality
- Unsafe with—Hotfix ID number or numbers of hotfixes that are incompatible and cannot be activated at the same time as this hotfix
- Notes—Restrictions on manual activations or deactivations

Example 1

host1#show hotfix

      name          id    active   armed   requires
----------------   ----   ------   -----   ----------
sleep.hfx           975     X        X          990
clock.hfx           990     X        X             
showHotfix.hfx     2010                          
incompatible.hfx    410                           
hfActivate.hfx      960

Example 2—The detail keyword additionally displays a synopsis of the hotfix.

host1#show hotfix detail
 
      name          id    active   armed   requires
----------------   ----   ------   -----   ----------
sleep.hfx           975     X        X          990
clock.hfx           990     X        X             
showHotfix.hfx     2010                           
incompatible.hfx    410                           
hfActivate.hfx      960                           
      name                             synopsis                    
----------------   ------------------------------------------------
sleep.hfx          Modify the output of the sleep command.         
clock.hfx          Modify the behavior of show clock.              
showHotfix.hfx     Changes the output of show hotfix.              
incompatible.hfx   Changes the output of show hotfix.              
hfActivate.hfx      Change log message severity for hotfix activate.

Example 3—The detail keyword for a particular hotfix displays the most detailed information.

host1#show hotfix clock.hfx detail
HotfixId: 990

Synopsis: Modify the behavior of show clock.

Active: Yes
Armed: Yes

Description:  Changes the output of the show clock command.

Affected modules: SRP, GE, VTM

Dependencies:

Safe to repatch:

Unsafe with:

Notes:
1) This hotfix can only be activated when the active SRP reloads
2) Arming this hotfix will cause the standby SRP to reload

See show hotfix.

Example: Using and Monitoring Hotfixes

This example presents several aspects of hotfix use. In this example, 6-0-1p0-5.rel is the currently armed and active release. Hotfix hf63035.hfx is compatible with this release and is currently activated and armed as a startup hotfix.

host1# dir
Active System Controller:
                                        unshared                          in 
          file                size        size          date (UTC)        use
-------------------------   ---------   ---------   -------------------   ---
reboot.hty                     596288      596288   03/07/2005 19:35:52      
system.log                       6762        6762   03/07/2005 17:30:08      
haIpSetup.mac                    4874        4874   03/24/2004 10:02:08      
6-0-1p0-5.rel               125987342   125987342   02/30/2005 18:17:32    !      
6-1-0.rel                   148489185   148489185   02/28/2005 20:19:20       
hf63035.hfx                     30445       30445   03/07/2005 14:04:02    !      
hf63036.hfx                     27445       27445   03/07/2005 16:12:05
hf63037.hfx                     28324       28324   03/07/2005 16:13:25
host1# show hotfix detail
   name         id     active  armed   requires
-----------  --------  ------  -----   -----------
hf63035.hfx  12343035    X       X     
hf63036.hfx  23453036                     
hf63037.hfx  34563037                  23453036
    name             synopsis
-----------      --------------------------------------------
hf63035.hfx      Fix for CQ63035, bgp crash, out of resources    
hf63036.hfx      Fixed show version formatting issue 
hf63037.hfx      Increased max session limit on ERX310 to 32,000
                  
host1(config)# boot hotfix hf63037.hfx
% The hotfix, 34563037, requires the following hotfix(es) to be armed:
        23453036

The hf63036.hfx hotfix must be armed as a startup hotfix:

host1(config)# boot hotfix hf63036.hfx

This command succeeds because hf63036.hfx is compatible with the currently armed release, 6-1-0.rel, and has no dependencies on other hotfixes.

Now the attempt to arm hf63037.hfx succeeds because its dependency on hf63036.hfx has been met.

host1(config)# boot hotfix hf63037.hfx

Now suppose the user reloads the router:

host1# reload

As the router loads the armed release, 6-1-0.rel, the hotfix loader discovers three armed startup hotfixes, hf63035.hfx, hf63036.hfx, and hf63037.hfx. Only hf63036.hfx and hf63037.hfx are activated. Hotfix hf63035.hfx is disarmed because it is incompatible with the new running release. The router therefore becomes operational running 6-1-0.rel with hf63036.hfx and hf63037.hfx activated.

host1# dir unshared                      in 
          file            size        size          date (UTC)        use
--------------------   ---------   ---------   -------------------   ---
reboot.hty                596288      596288   03/07/2005 19:35:52      
system.log                 6762        6762   03/07/2005 17:30:08      
haIpSetup.mac             4874        4874   03/24/2004 10:02:08      
6-0-1p0-5.rel           125987342   125987342   02/30/2005 18:17:32          
6-1-0.rel               148489185   148489185   02/28/2005 20:19:20    !   
hf63035.hfx               30445       30445   03/07/2005 14:04:02          
hf63036.hfx               27445       27445   03/07/2005 16:12:05    !
hf63037.hfx               28324       28324   03/07/2005 16:13:25    !
host1#show hotfix
 
   name      active  armed   requires
-----------  ------  -----   --------
hf63035.hfx                       
hf63036.hfx    X       X       
hf63037.hfx    X       X      23453036

Now suppose the user attempts to deactivate hf63036.hfx:

host1#no hotfix activate hf63036.hfx
The hotfix, 23453036, has the following active dependents which must be deactivated first:
        34563037
% De-activation failed.

The command fails because hf63037.hfx is dependent on hf63036.hfx. Interdependent hotfixes must be deactivated and disarmed in the reverse order that they were activated.

When 6-0-1p0-5.rel is re-armed and the router reloaded, the hotfix loader determines that the startup hotfixes, hf63036.hfx and hf63037.hfx, are incompatible with the release. It disarms these hotfixes. The user decides to delete the now unnecessary hotfixes from the router.

host1# delete hf63036.hfx
host1# delete hf63037.hfx
host1# dir
Active System Controller:
                                        unshared                          in 
          file                size        size          date (UTC)        use
-------------------------   ---------   ---------   -------------------   ---
reboot.hty                     596288      596288   03/07/2005 19:35:52      
system.log                       6762        6762   03/07/2005 17:30:08      
haIpSetup.mac                    4874        4874   03/24/2004 10:02:08      
6-0-1p0-5.rel               125987342   125987342   02/30/2005 18:17:32    !      
6-1-0.rel                   148489185   148412851   02/28/2005 20:19:20       
hf63035.hfx                     30445       30445   03/07/2005 14:04:02    !      

host1# show hotfix detail
 
   name         active     armed   requires
-----------  ------------  -----   --------
hf63035.hfx       X          X         ---