| Platform | Junos Software by Platform | Release Type | Last Updated |
|---|---|---|---|
| vSRX | Junos 19.4R3-S1 | Service | 06 Jan 2021 |
| vSRX 3.0 | Junos 19.4R3-S1 | Service | 06 Jan 2021 |
| SRX100H2 / SRX110H2 / SRX210HE2 / SRX220H2 / SRX240H2 | Junos 12.3X48-D105 | Standard | 16 Oct 2020 |
| SRX300 / SRX320 / SRX340 / SRX345 | Junos 19.4R3-S1 | Service | 06 Jan 2021 |
| SRX380 | Junos 20.2R3 | Standard | 26 Apr 2021 |
| SRX550 | Junos 12.3X48-D105 | Standard | 16 Oct 2020 |
| SRX550HM | Junos 19.4R3-S1 | Service | 06 Jan 2021 |
| SRX650 | Junos 12.3X48-D105 | Standard | 16 Oct 2020 |
| SRX1400 | Junos 12.3X48-D105 | Standard | 16 Oct 2020 |
| SRX1500 | Junos 20.2R3 | Standard | 26 Apr 2021 |
| SRX3400 / SRX3600 | Junos 12.3X48-D105 | Standard | 16 Oct 2020 |
| SRX4100 / SRX4200 | Junos 19.4R3-S1 | Service | 06 Jan 2021 |
| SRX4600 | Junos 19.4R3-S1 | Service | 06 Jan 2021 |
| SRX5400 / SRX5600 / SRX5800 with SRX5K-RE3-128G (*1) |
Junos 19.4R3 | Standard | 04 May 2021 |
| SRX5400 / SRX5600 / SRX5800 with RE-1800X4 (*1) |
Junos 19.4R3 | Standard | 04 May 2021 |
| SRX5400 / SRX5600 / SRX5800 with SRX5K-RE-13-20 (*1) |
Junos 12.3X48-D105(*2) | Standard | 16 Oct 2020 |
As an IT professional, it’s hard to keep up with the pace of innovation when costly training sessions and talent shortages have become a way of life. Adding to that, the pace of innovation and cybersecurity attacks are moving faster than ever, leading to increased risk of threats.
Juniper Sky Enterprise makes cloud network management simple and quick for IT teams of all sizes and experience levels deploying Juniper switching and security devices. It's easier than ever to use cloud-managed switches and cloud-managed firewalls. With Juniper Sky Enterprise, you can:
Run in an elastic, multitenant, secure, and reliable cloud infrastructure in SSAE16 SOC-1/2/3-compliant data centers. The highest levels of physical and infrastructure security ensure that data is kept private—no user traffic passes through the Juniper Sky Enterprise system.
Perform day-to-day management of your EX Series and SRX Series devices centrally from one intuitive, web-based portal using simplified workflows. Use the centralized dashboard for managing, monitoring, reporting, and securing your enterprise.
Use Zero Touch Provisioning (ZTP) for fast, simple deployment of cloud-managed switches and cloud-managed firewalls. A simple device replacement and renewal process helps you avoid costly truck rolls.
Get real-time visibility into the threats and risks the SRX Series device has detected and mitigated. With advanced reporting for AppSecure, UTM, and Juniper Advanced Threat Prevention, you gain granular insights into the network.
Simplify workflows to configure and manage switch interfaces, VLANs, and routes. Easily monitor switch resources and capacity. Gain access to full Power over Ethernet (PoE) settings to enable, disable, and monitor PoE-connected devices. Visualize Virtual Chassis configurations.
Easily administer new user accounts with two-factor authentication and role-based access control (RBAC). An audit change log provides additional security.
Perform bulk updates to a range of devices and track the changes across the network. Track device inventory and schedule routine configuration backups across your devices.
Centralize the distribution and deployment of Junos OS software. Upgrade hundreds of devices with minimal effort and receive a detailed upgrade report when complete.
The table below details important information relevant to each Junos OS release. The dates and milestones provided are in accordance with the policies at the time of each software release and are in accordance with stated End of Life/End of Support policies for Juniper Networks.
Last updated: 1 Apr 2021
| Product | FRS Date | End of Engineering | End of Support |
|---|---|---|---|
| Junos OS 21.1 | 03/25/2021 | 03/25/2023 | 09/25/2023 |
| Junos OS 20.4 | 12/25/2020 | 12/25/2023 | 06/25/2024 |
| Junos OS 20.3 | 09/29/2020 | 09/29/2022 | 03/29/2023 |
| Junos OS 20.2 | 06/30/2020 | 06/30/2023 | 12/30/2023 |
| Junos OS 20.1 | 03/27/2020 | 03/27/2022 | 09/27/2022 |
| Junos OS 19.4 | 12/26/2019 | 12/26/2022 | 06/26/2023 |
| Junos OS 19.3 | 09/26/2019 | 09/26/2022 | 03/26/2023 |
| Junos OS 19.2 | 06/26/2019 | 06/26/2022 | 12/26/2022 |
| Junos OS 19.1 | 03/27/2019 | 03/27/2022 | 09/27/2022 |
| Junos OS 18.4 | 12/22/2018 | 12/22/2021 | 06/22/2022 |
| Junos OS 18.3 | 09/26/2018 | 09/26/2021 | 03/26/2022 |
| Junos OS 18.2 | 06/29/2018 | 06/29/2021 | 12/29/2021 |
| Junos OS 18.1 | 03/28/2018 | 03/28/2021 | 09/28/2021 |
| Junos OS 17.410 | 12/21/2017 | 12/21/2020 | 06/21/2021 |
Enabling larger EVPN-VXLAN data center infrastructure can be a scaling challenge, requiring additional tools to fully control the way workloads communicate across fabric pods or DC sites. Starting with Junos OS release 20.3, seamless EVPN-VXLAN stitching offers a method to interconnect pods and sites at their edges that provides improved control and scaling.
The figure below shows a data center with four pods. The left side shows an approach that interconnects pods using a full mesh of leaf-to-leaf VXLAN tunnels. The right side uses EVPN-VXLAN stitching, where the intra-pod tunnels terminate at their local interconnect gateway and then just a few VXLAN tunnels are used to interconnect the pods. In this example, tunnel stitching happens at the spine layer, however it can also be done at the super-spine or border-leaf layer, depending on the DC design.
Seamless EVPN-VXLAN stitching has two main use cases:
Multi-pod DC fabric architectures – the interconnect gateways are placed at the spine layer, unifying scaling between the two pods.
Data center interconnect (DCI) – instead of using an over-the-top (OTT) full mesh between sites, the interconnect gateways create the DCI interconnect VXLAN tunnels, thus reducing the number of tunnels and next-hops.
Seamless EVPN-VXLAN stitching simplifies Layer 2 DCI and multi-pod architectures by providing clear demarcation points between pods and sites, thereby enabling improved flood control. As a result, this solution offers better overall scaling.
Leveraging and implementing virtualization and multitenancy in the data center can be complex, requiring multiple touch points in the architecture to see the first benefits of virtualization.
A new routing instance type, MAC-VRF, adds more flexibility when enabling new server connectivity within the fabric. And with support for edge-routed bridging (leaf routed) and bridged overlay (routed outside the fabric) architectures, MAC-VRF offers a consistent approach to enabling L2 services.
In the figure below, Tenant 44 (MAC-VRF44) and Tenant 55 (MAC-VRF55) are using dedicated MAC-VRF Layer 2 instances on the leaf devices, enabling them to be fully isolated from each other. In cases where these tenants want to communicate, they can add dedicated EVPN Type-5 Layer 3 instances (not shown) to interconnect. This provides the tenants with a range of options to support both their isolation and collaboration needs.
Overall, the MAC-VRF provides additional capabilities for network virtualization and multitenancy. It also offers better control of VXLAN tunnel distribution as well as VXLAN tunnel distribution and flooding optimizations. Plus, it enables interoperability with other vendors.
Not all traffic is equal. When deploying applications in a data center, some applications require more special treatment than others, whether it’s due to how much we trust their traffic or because of the volume of traffic they generate. When these applications are located within the same subnet it can be challenging to provide differentiation. Something is needed to identify and separate each application’s traffic.
Filter-based forwarding (FBF) can help. FBF may not be new, but applying it to edge-routed bridging architectures injects more intelligence into the DC fabric. FBF on QFX5120 leaf nodes enables the operator to forward each application’s traffic as they wish. This makes it possible to enable app steering during a specific time of day, or if a particular app/server begins to show suspicious behavior from a security point of view.
In the figure below, three servers have been deployed in the same IP subnet and by default, their traffic will all be treated the same. However, each server’s traffic has different characteristics: App1 is creating a lot of ‘elephant’ traffic; App2 has low volume but its traffic needs to flow through a specific firewall cluster for more advanced policing; and App3 generates lots of traffic but it’s fully trusted so can flow directly out to the core IP network.
Using filter-based forwarding at the leaf layer adds application awareness of the data center fabric. It also improves load balancing and flow engineering capabilities and offers improved flow isolation.
Modern data center EVPN-VXLAN fabrics have eliminated many of the challenges of traditional 3-tier architectures, such as loop detection. One such challenge is loop detection and prevention. Leaf-spine architectures use all-active link designs and EVPN includes several built-in mechanisms (split horizon, designated forwarder election, MAC mobility tracking) that lower the risk of network instability, compared to legacy Spanning Tree-based infrastructures.
Still, loops can happen when server-to-leaf connections are mis-cabled or misconfigured. Since uptime is a critical metric for any data center, many vendors still recommend using STP. Yes, STP in a modern DC! Fortunately, there’s a better way.
Starting with Junos OS release 20.4, the QFX5120 supports connectivity fault management (CFM) into the DC fabric. Based on the IEEE 802.1ag standard, CFM’s heartbeat mechanism provides enhanced Ethernet loop detection over legacy options like xSTP and BGP. But that’s not all. Through information-sharing within the QFX platform, EVPN can provide information to CFM TLVs like node name, port name and ESI information to help identify the source of the problem.
In the figure below, Server 2 is connected to leaf devices L2 and L4. Both leaf devices are using the same trunk-level VLAN ID. however they have accidentally been configured to use different ESI values. This could create an Ethernet loop. But thanks to CFM heartbeats, the loop has been blocked. Plus, because CFM TLV extensions include details about the problem, the origin of the loop can be identified.
This solution represents a more elegant approach for loop detection within an EVPN-VXLAN fabric, truly eliminating the need for legacy loop detection solutions like xSTP. It also reduces loop detection times and enhances visibility into the cause of the issue, thereby reducing time to resolution.
If someone could arrange a competition between different physical network topologies, the spine-and-leaf fabric would reign as the undisputed champion in many ways. What is different about the spine-and-leaf that would declare this type of network topology “the champion?”
The spine-and-leaf is a special kind of network, called a fabric, with some interesting mathematical properties. One of the most interesting, from a design perspective, is that fabrics are regular, which means they are built out of what some may call “micro-modules”— clearly repeatable sections of the network topology. These repeating sections of the network topology are not directly related to traditional modules built around creating failure and security domains, but they still enable some interesting properties related to the design and management of a data center network.
Many five-stage fabric designs easily lend themselves to breaking the network up into fabs and pods, as shown in the illustration below. Any fab or pod can be replaced without impacting the overall fabric design much like an access layer module in a traditional three-layer hierarchical design.
The repeatability of these modules enables automation, just as any other modular network design does. New pods can be added to the fabric and measured while the load is slowly moved onto them to ensure they are operating correctly—all while the fabric is in production. This is called a canary and allows the operator to add or replace network elements at the pod or fab level while controlling risk.
Because pods and fabs can be replaced in this way, they can also be managed in generations, or a repeatable set of hardware, software, configurations and tools. By controlling the number of generations within the fabric, the operator can directly control one of the many elements of network complexity—the variability of configurations.
The spine-and-leaf is also a universal topology, which means it can optimally support just about every kind of traffic flow on a single physical topology. This enables several types of applications, including applications with extremely hard performance requirements, to run efficiently across a spine-and-leaf fabric.
While the spine-and-leaf is a fascinating kind of network topology, many network engineers are still unaware of (or not fully aware of) the many interesting aspects of this network design, its origin and its properties.
