- play_arrow CSDS Architecture Overview
- play_arrow CSDS Deployment Overview
- play_arrow CSDS Deployment Scenarios and Topologies
- Deployment Scenarios and Topologies
- CSDS Dual MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Multinode HA)
- CSDS Single MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Standalone)
- CSDS Single MX Series (CSDS Traffic Orchestrator) and Scaled-Out SRX Series Firewalls (MNHA)
- CSDS Dual MX Series (CSDS Traffic Orchestrator) and Scaled-Out SRX Series Firewalls (MNHA)
- play_arrow ECMP-Based Consistent Hashing in CSDS
- How CSDS Works with ECMP Based Consistent Hashing
- IPsec VPN Traffic Flow in Single MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Standalone)
- NAT Traffic Flow in Single MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Standalone)
- Stateful Firewall Traffic Flow in Single MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Standalone)
- Stateful Firewall and NAT Traffic Flow in Dual MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Multinode HA)
- play_arrow CSDS Traffic Orchestrator
- How Does CSDS Traffic Orchestrator Work
- IPsec VPN Traffic Flow in Single MX Series (CSDS Traffic Orchestrator) and Scaled-Out SRX Series Firewalls
- NAT Traffic Flow in Single MX Series (CSDS Traffic Orchestrator) and Scaled-Out SRX Series Firewalls
- Stateful Firewall Traffic Flow in Single MX Series (CSDS Traffic Orchestrator) and Scaled-Out SRX Series Firewalls
- play_arrow vSRX Orchestration with JDM in CSDS
- play_arrow Configure CSDS
- Example: Single MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Standalone) for IPsec VPN
- Example: Single MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Standalone) for NAT and Stateful Firewall
- Example: Dual MX Series (ECMP Based Consistent Hashing) and Scaled-Out SRX Series Firewalls (Multinode HA) for NAT and Stateful Firewall
- Example: Single MX Series (CSDS Traffic Orchestrator) and Scaled-Out SRX Series Firewall (MNHA) for Stateful Firewall
- Configure Junos Node Unifier for CSDS
- Install and Configure Junos Device Manager for CSDS
JNU Use Cases for CSDS
Learn about Junos Node Unifier (JNU) use cases and how they fit in the Connected Security Distributed Services (CSDS) architecture.
In JNU topology, JNU satellite communicates with JNU controller using the jnud process. Satellite exports its configuration and operational schema to controller. This enables the controller's jnud process to present a unified command line interface (CLI) view of both the nodes. Controller is the central point of configuration for all satellites.
In this topic, you'll see JNU use cases and how they work in CSDS.
Run Configuration CLIs From a Single Touchpoint
You can run Junos OS configurations commands from the controller. Note the following points when you run configuration commands:The controller's configuration hierarchy
show chassis jnu-managementlists the names of all satellites in the JNU topology. This command shows the corresponding Junos device model and Junos OS release details. The satellite's configuration hierarchy is available in[edit chassis satellite satellite-name]hierarchy level. From this configuration hierarchy, you can run all the satellite-specific configuration commands. Once controller learns the corresponding configuration schema of satellite, the controller uses the configuration schema of that Junos device model and Junos OS release to make configuration changes on that satellite.You should not commit in the satellite context. Instead, use
top commitfor the satellite configuration.When you perform a satellite-specific configuration commit in the controller, the controller sends commit check to the satellite. One of the following happens:
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 the commit fails in any of the satellites, the controller logs the failure, while the other satellites proceed with the commit successfully.
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 CLIs From a Single Touchpoint
- You can run the satellite-specific operational commands by appending
device-list instance-nameoption 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.
The controller's configuration mode does not support the satellite's operational mode commands. You need to 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:
Deployment Scenario | Upgrade Sequence |
|---|---|
Single MX Series and standalone SRX Series |
|
Dual MX Series and standalone SRX Series |
|
Single MX Series and SRX Series in Multinode High Availability |
|
Dual MX Series and SRX Series in Multinode High Availability |
|
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 the controller upgrade, you may notice warning message as shown below if you run a configuration command even before the satellites are upgraded. You must not run Junos configuration commands until the satellites are upgraded.
content_copy zoom_out_mapuser@mx1# exit Exiting configuration mode warning: schema /var/db/jnu-controller-schema.db not found error: Command remap failed
Ignore any warning messages that you might notice during the commit operations until the satellites are also upgraded.
After the controller upgrades, the device removes JNU-specific merged controller schema. The device recreates 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 Multinode High Availability, 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 Virtual Firewall downgrade process, see JDM and vSRX Virtual Firewall Deletion Process.
