Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

JNU Use Cases for CSDS

Learn about Junos Node Unifier (JNU) use cases and how these use cases fit in the Connected Security Distributed Services (CSDS) Architecture.

In a JNU topology, a JNU satellite communicates with the JNU controller using the jnud process. A satellite exports its configuration and operational schema to the controller. The controller learns the satellite schema, enabling the jnud process to present a unified CLI view of both the nodes. The controller is the central point of configuration for all the satellites.

In this topic, you'll see JNU use cases and how these use cases fit in the CSDS Architecture.

Run Configuration Commands from a Single Touchpoint

You can run Junos OS configurations commands from the controller. Note the following information and best practices when you run configuration commands:

  • The controller's configuration hierarchy show chassis jnu-management lists the names of all satellites in the JNU topology. The command output shows the device model and Junos OS release details of each satellite. The satellite's configuration hierarchy is available in the [edit chassis satellite satellite-name] hierarchy level. From this configuration hierarchy, you can run all the satellite-specific configuration commands. After the controller learns the configuration schema of a satellite, the controller uses the configuration schema of the device and Junos OS release information to make configuration changes on that satellite.

  • You should not commit in the satellite context. Instead, use top commit for the satellite configuration.

  • When you commit a satellite-specific configuration in the controller, the controller performs commit check operation on the satellites. This action has one of the following outcomes:

    • If the commit check succeeds, controller sends commit to the satellite. If the commit check succeeds on the satellite, then the commit also succeeds on the controller. The satellite then applies the configuration. If any satellite encounters a commit failure, the controller logs the failure, while the remaining satellites finish the commit without issues.

    • If the commit check fails, the controller aborts the commit and rolls back the configuration on the satellites.

  • In dual-controller JNU topology, the first controller sends the satellite configuration to the other controller. If the first controller cannot reach the other controller, the first controller's commit fails.

Run Operational Commands from a Single Touchpoint

  • You can run the satellite-specific operational commands on the controller by appending device-list instance-name option to the command. Here instance-name is the name of the satellite. See the following sample configuration command:

    • To run an operational command on a single satellite, use show security ipsec security-associations -device-list 10.10.10.8.

    • To run an operational command on multiple satellites, use show security ipsec security-associations -device-list [10.10.10.8 10.10.10.19 10.10.10.15].

  • The controller propagates the operational command to the satellite. The satellite runs the operational command and returns the output to be displayed on the controller.

Note:

The controller's configuration mode does not support the satellite's operational mode commands. You must run the satellite's operational commands in the controller's operational mode.

Upgrade Devices in JNU Topology

You need to upgrade the nodes in JNU topology locally. Adhere to the following sequence when you're upgrading Junos OS on the nodes in JNU topology:

Table 1: Upgrade Sequence in JNU Topology

Deployment Scenario

Upgrade Sequence

Single MX Series and standalone SRX Series

  1. Upgrade the controller:

    • Upgrade MX Series, including both the routing engines (REs).

  2. Upgrade the satellite:

    • Upgrade the SRX Series Firewall.

      or

    • If you have vSRX,

      1. Upgrade JDM.

      2. Upgrade vSRX.

Dual MX Series and standalone SRX Series

  1. Upgrade both the controllers:

    • Upgrade MX1, including both the REs.

    • Upgrade MX2, including both the REs.

  2. Upgrade the satellite:

    • Upgrade the SRX Series Firewall.

      or

    • If you have vSRX,

      1. Upgrade JDM.

      2. Upgrade vSRX.

Single MX Series and SRX Series in MNHA

  1. Upgrade the controller:

    • Upgrade MX Series, including both the REs.

  2. Upgrade the satellites:

    • Upgrade the SRX Series Firewalls.

      1. Upgrade SRX Series Firewall node 1 in MNHA.

      2. Upgrade SRX Series Firewall node 2 in MNHA.

      or

    • If you have vSRX Virtual Firewalls,

      1. Upgrade JDM.

      2. Upgrade vSRX node 1 in MNHA.

      3. Upgrade vSRX node 2 in MNHA.

Dual MX Series and SRX Series in MNHA

  1. Upgrade both the controllers:

    • Upgrade MX1, including both the REs.

    • Upgrade MX2, including both the REs.

  2. Upgrade the satellites:

    • Upgrade the SRX Series Firewalls.

      1. Upgrade SRX Series Firewall node 1 in MNHA.

      2. Upgrade SRX Series Firewall node 2 in MNHA.

      or

    • If you have vSRX Virtual Firewalls,

      1. Upgrade JDM.

      2. Upgrade vSRX node 1 in MNHA.

      3. Upgrade vSRX node 2 in MNHA.

Consider the following points when upgrading the nodes in JNU topology:

  • To upgrade MX Series, see Junos® OS Software Installation and Upgrade Guide.

    When you upgrade both the controllers, ensure to upgrade both the REs. After you upgrade the controller, you might notice a warning message, as shown below, if you run a configuration command before you upgrade the satellites. You must not run Junos configuration commands until you upgrade the satellites.

    Ignore any warning messages you might notice during the commit operations until you upgrade the satellites.

    After the controller upgrades, the device removes JNU-specific merged controller schema. The device re-creates the JNU controller merged schema after the satellite upgrade and join operations. Until then you cannot run the satellite-specific operational commands from the controller.

  • If you have JDM, see JDM and vSRX Virtual Firewall Upgrade Process.

  • To upgrade the standalone SRX Series Firewall, see Installing Software on SRX Series Firewalls.

    To upgrade both the firewalls in MNHA, see Software Upgrade in Multinode High Availability

  • After the upgrade, ensure that all the nodes are in the same version. Two SRX Series Firewalls cannot have different version. The same applies to MX Series.

To downgrade Junos OS, follows the same sequence.

For more details on JDM and vSRX downgrade process, see JDM and vSRX Virtual Firewall Deletion Process.

Related Documentation