Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Important Features in Junos OS Release 20.4

 

For details on these features, go to the other chapters in this guide or click the link in the feature description below.

  • RADIUS attributes for dynamic VLAN assignment on colorless ports (EX2300, EX2300-MP, EX3400, EX4300, and EX4300-MP)—We now support IETF-defined RADIUS attributes that provide VLAN assignments and also indicate whether frames on the VLAN are in tagged or untagged format. This enables the network access control server to dynamically assign VLANs on colorless ports. The VLAN assignments, which are based on device profiling, can be made on either access ports or trunk ports.

    [See How to Configure Dynamic VLAN Assignment for Colorless Ports.]

  • Support for express segments to establish end-to-end segment routing path (MX Series and PTX Series)—Starting in Junos OS Release 20.4R1, express segments can be used to establish end-to-end TE paths between interconnected TE networks. Express segments (also known as virtual TE links) are generated dynamically through policies matching the underlay LSPs. Express segments and the corresponding abstracted topology (required by RFC7926) is generated with policies.

    To apply a policy, include the policy policy-name statement at the [edit protocols express-segment traffic-engineering] hierarchy level.

    To configure express segment, include the express-segment statement under the [edit protocols] hierarchy level.

    [See How to Establish End-to-End Segment Routing Paths Using Express Segments.]

  • Support for IS-IS flood-reflector interfaces (PTX1000, QFX10002, QFX10008)—Starting in Junos OS Release 20.4R1, we support the IS-IS flood reflector feature that offers better scalability for a Level 2 topology. Flood reflectors enable the creation of topologies where Level 1 areas provide transit forwarding for Level 2 destinations within a Level 2 topology.

    The flexible tunnel interfaces (FTI) are designated as flood-reflector interfaces. To enable the flood reflector on an FTI, include the flood-reflector statement at the [edit protocols isis interface interface name level level number hierarchy level.

    You can configure the interface to be either the reflector or the client. To enable the reflector, you can use the flood-reflector reflector cluster-id statement at the [edit protocols isis level level number] hierarchy level.

    To enable the flood reflector client, include the flood-reflector client statement at the [edit protocols isis level level number hierarchy level.

    Note

    You can configure the flood reflector feature on FTIs at Level 2 only.

    [See How to Configure Flood-Reflector Interfaces in IS-IS Networks.]

  • Support for mobility on Junos Multi-Access User Plane (MX204, MX240, MX480, MX960, MX10003)—For Junos OS Release 19.4R1, we introduced Junos Multi-Access User Plane supporting a combined SGW-U/PGW-U (SAEGW-U) on MX Series routers in accordance with 3GPP Release 14 CUPS architecture. This provided high-throughput 4G and 5G fixed-wireless access service with support for 5G non-stand-alone (NSA) mode.

    For Junos OS Release 20.4R1, we introduce support for running an MX router as either a standalone SGW-U or a standalone PGW-U or a combined SAEGW-U to provide high-throughput 4G and 5G mobility service (relocation of a UE to a new eNodeB, new SGW-U, or new SAEGW-U). This includes support for GTP-U based S5-U and S8-U interfaces, to provide links between SGW-U and PGW-U devices, and tunnel relay functionality to forward user plane traffic between S1-U and S5-U/S8-U interfaces or between S5-U/S8-U and SGi interfaces respectively. We support the following mobility scenarios:

    • Handover with eNodeB and no SGW change

    • Handover with SGW change (direct forwarding)

    • Handover with SGW change (indirect forwarding)

    [See How to Implement Mobility for Junos Multi-Access User Plane.]

  • Support for SRv6 network programming and Layer 3 Services over SRv6 in BGP (MX Series)—Starting in Junos OS Release 20.4R1, you can configure BGP based Layer 3 service over SRv6 core. You can enable Layer 3 overlay services with BGP as control pane and SRv6 as dataplane. SRv6 network programming provides flexibility to leverage segment routing without deploying MPLS. Such networks depend only on the IPv6 headers and header extensions for transmitting data.

    To configure IPv4 and IPv6 transport over SRv6 core, include the end-dt4-sid sid and the end-dt6-sid sid statements at the [edit protocols bgp source-packet-routing srv6 locator name hierarchy level.

    To configure IPv4 VPN and IPv6 VPN service over SRv6 core, include the end-dt4-sid sid and the end-dt6-sid sid statements at the [edit routing-instances routing-instance name protocols bgp source-packet-routing srv6 locator name hierarchy level.

    [See How to Enable SRv6 Network Programming and Layer 3 VPN Services over SRv6 in BGP Networks]

  • Phone-home client (EX4650, QFX5120-48Y, and QFX5120-32C )—Starting with Junos OS Release 20.4R1, you can use either the legacy DHCP-options-based ZTP or the phone-home client (PHC) to provision software for the switch. When the switch boots up, if there are DHCP options that have been received from the DHCP server for ZTP, ZTP resumes. If DHCP options are not present, PHC is attempted. PHC enables the switch to securely obtain bootstrapping data, such as a configuration or software image, with no user intervention other than having to physically connect the switch to the network. When the switch first boots up, PHC connects to a redirect server, which redirects to a phone home server to obtain the configuration or software image.

    To initiate either DHCP-options-based ZTP or PHC, the switch must be in a factory-default state, or you can issue the request system zeroize command.

    [See Understanding the Phone-Home Client. ]

  • Phone-home client (EX4300-48MP Virtual Chassis)—Starting in Junos OS Release 20.4R1, the phone-home client (PHC) can securely provision a Virtual Chassis consisting of all EX4300-48MP member switches without requiring user interaction. If the switches all have the factory-default configuration, you just need to:

    • Connect the switches using the Virtual Chassis ports.

    • Connect any network port or the management port to the network.

    • Power on the Virtual Chassis.

    The PHC automatically starts up and connects to the phone-home server (PHS), which responds with bootstrapping information. The PHC then upgrades each member with the new image and applies the configuration, and the Virtual Chassis is ready to go.

    [See Provision a Virtual Chassis Using the Phone-Home Client.]

  • SR-IOV 10GbE high availability support (vSRX 3.0)—Starting in Junos OS Release 20.4R1, vSRX 3.0 supports high availability (HA) single-root I/O virtualization (SR-IOV) deployment.

    If you have a physical network interface card (NIC) that supports SR-IOV, you can attach SR-IOV-enabled vNICs or virtual functions to the vSRX 3.0 instance.

    With this feature, you can access the hardware directly from a virtual machines environment and efficiently share the PCIe devices to optimize performance and capacity. Also, this feature allows you to create many VFs associated with a single physical function (PF) extending the capacity of a device and lowering hardware costs.

    We recommend that you configure all revenue ports of vSRX 3.0 as SR-IOV. On KVM, you can configure SR-IOV high availability on management port: -fxp0/ control port- em0 / fabric port-ge-0/0/*.

    SR-IOV high availability Layer 2 function is not supported. Also, SR-IOV high availability with the vSRX 3.0 on VMWare and Mellanox NICs is not supported.

    [See Configuring SR-IOV 10-Gigabit High Availability on vSRX 3.0.]

  • EVPN-VXLAN Tunnel inspection (SRX4100, SRX4200, SRX4600, and vSRX)—Starting in Junos OS Release 20.4R1, you can use SRX Series devices in your EVPN-VXLAN solution to connect end-points in your campus, data center, branch and public cloud environments while providing embedded security. The SRX Series device performs stateful inspection of VXLAN encapsulated traffic when you enable tunnel inspection.

    You must configure security policies that enable inspection of EVPN EVPN-VXLAN tunnel traffic on your SRX Series devices.

    [See Tunnel Inspection for EVPN-VXLAN by SRX Series Devices.]