Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

New and Changed Features

This section describes the new features and enhancements to existing features in Junos OS Release 15.1F4 for the MX Series and the T Series.

Hardware

  • New Routing Engine RE-S-X6-64G (MX240, MX480, and MX960)—Starting in Junos OS Release 15.1F4, the Routing Engine RE-S-X6-64G is supported on MX240, MX480, and MX960 routers. This Routing Engine has an increased computing capability and scalability to support the rapid rise in the data plane capacity. The Routing Engine is based on a modular virtualized architecture and leverages the hardware-assisted virtualization capabilities.

    Note: Subscriber services and virtual-chassis support is not available in Junos OS 15.1Fx releases.

    The Routing Engine has a 64-bit CPU and supports a 64-bit kernel and 64-bit applications. With its multicore capabilities, the Routing Engine supports symmetric multiprocessing in the Junos OS kernel and hosted applications.

    Note: The Routing Engine RE-S-X6-64G is supported only on SCBE2, and it is not compatible with the SCB or the SCBE.

  • New rate-selectable MPC MPC7E-MRATE (MX2020, MX2010, MX960, MX480, and MX240)—Starting in Junos OS Release 15.1F4, the rate-selectable MPC MPC7E (Multi-Rate) (model number: MPC7E-MRATE) is supported on MX2020, MX2010, MX960, MX480, and MX240 routers.

    The main features of the MPC7E-MRATE MPC are the following:

    • Line-rate throughput of up to 480 Gbps on MX240, MX480, and MX960 routers.
    • Line-rate throughput of up to 400 Gbps on the MX2000 line of routers.
    • Twelve ports that can each be configured as a 40-Gigabit Ethernet port or as four 10-Gigabit Ethernet ports by using a breakout cable. The ports support quad small-form factor pluggable plus (QSFP+) transceivers.
    • Four ports—0/2, 0/5, 1/2, and 1/5—out of the twelve ports can be configured as 100-Gigabit Ethernet ports.
    • You can configure different combinations of port speeds as long as the aggregate capacity per group of six ports labeled 0/0 through 0/5 does not exceed 240 Gbps. Similarly, aggregate capacity per group of the other six ports labeled 1/0 through 1/5 must not exceed 240 Gbps.

    Note: To use the MPC7E-MRATE MPC, you must download and install the Junos Continuity software package for Junos OS Release 15.1F4.

General Routing

  • Support for virtualization on RE-S-X6-64G (MX240, MX480, MX960, MX2010, and MX2020)—The Routing Engine RE-S-X6-64G supports virtualization for the following platforms:

    • MX240, MX480, and MX960—Junos OS Release 15.1F3 and later
    • MX2010 and MX2020—Junos OS Release 15.1F5 and later

    Virtualization enables the router to support multiple instances of Junos OS and other operating systems on the same Routing Engine. However, for Junos OS Release 15.1F3, one instance of Junos OS, which runs as a guest operating system, is launched by default. The user needs to log in to this instance for operations and management.

    With virtualization of the Routing Engine, Junos OS supports new request and show commands associated with host and hypervisor processes. The commands are related to:

    • Reboot, halt, and power management for the host
    • Software upgrade for the host
    • Disk snapshot for the host

Interfaces and Chassis

  • Support for dynamic power management on MPC6E—Starting in Junos OS Release 15.1F4, dynamic power management is supported on MPC6E on MX2010 and MX2020 routers. In earlier Junos OS releases, this feature is supported only on MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, and MPC2E-3D-NG-Q on MX240, MX480, MX960, MX2010, and MX2020 3D Universal Edge Routers.
  • Support for flexible queuing on on MPC5E—Starting in Junos OS Release 15.1F4, flexible queuing is supported on MPC5E on MX240, MX480, MX960, MX2010, and MX2020 3D Universal Edge Routers.
  • Dynamic power management enabled by default—Starting in Junos OS Release 15.1F4, dynamic power management is enabled by default. The mic-aware-power-management statement, which was used to enable dynamic power management in earlier releases, is deprecated.

Management

  • Router telemetry data for hardware and software (MX Series)—Starting in Junos OS Release 15.1F3, you can configure MX Series routers to export telemetry data from supported interface hardware. Line card sensor data such as interface RSVP TE LSP events are sent directly to configured collection points without involving polling. You configure all parameters at the [edit services analytics] hierarchy level. You can configure the exact interfaces and LSPs for export statistics using regular expression resource filter matches. Supported MPC hardware on MX Series routers is MPC1 through MPC6E.

Multicast

  • Latency fairness optimized multicast (MX Series)—Starting with Junos OS Release 15.1F3, you can reduce latency in the multicast packet delivery by optimizing multicast packets sent to the Packet Forwarding Engines. You can achieve this by enabling the ingress or local-latency-fairness option in the multicast-replication configuration statement at the [edit forwarding-options] hierarchy level. The multicast-replication statement is supported only on platforms with the enhanced-ip mode enabled. This feature is not supported in VPLS networks and Layer 2 bridging.

Network Management and Monitoring

  • SNMP support for fabric queue depth, WAN queue depth, and fabric counter (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 15.1F3, Junos OS provides SNMP support for WAN queue depth, fabric queue depth, and fabric counter. The following SNMP MIB tables include the associated objects:
    • jnxCosQstatTable table
    • jnxCosIngressQstatTable table
    • jnxFabricMib table

    In addition, this feature supports the following traps for the Packet Forwarding Engine resource monitoring MIBs:

    • jnxPfeMemoryTrapVars
    • jnxPfeMemoryNotifications
  • Support for Timing MIB on MX104 router—Starting in Junos OS Release 15.1F5, MX104 3D Universal Edge Router supports the timing feature. A new enterprise-specific MIB, Timing Feature Defect/Event Notification MIB, has been added to support this feature. The trap notifications are disabled by default. To enable SNMP trap notifications for timing events and defects, include the timing-events statement at the [edit snmp trap-group trap-group object categories] hierarchy level.

Platform and Infrastructure

  • Virtual MX Series router (vMX)—Starting in Junos OS Release 15.1F3, you can deploy vMX routers on x86 servers. vMX supports most of the features available on MX Series routers and allows you to leverage Junos OS to provide a quick and flexible deployment. vMX provides the following benefits:
    • Optimizes carrier-grade routing for the x86 environment
    • Simplifies operations by consistency with MX Series routers
    • Introduces new services without reconfiguration of current infrastructure
  • Flow caching support on virtual MX Series router (vMX)—Starting in Junos OS Release 15.1F4, you can enable flow caching on vMX routers for SR-IOV deployments. You enable flow caching by configuring the performance-mode option at the [edit chassis fpc 0] hierarchy level.

Routing Protocols

  • Weighted ECMP support for one-hop IS-IS neighbors (MX Series)—Beginning with Junos OS Release 15.1F4, you can configure the IS-IS protocol to get the logical interface bandwidth information associated with the gateways of equal-cost multipath (ECMP) next hop. During per-packet load balancing, traffic distribution is based on the available bandwidth to facilitate optimal bandwidth usage for incoming traffic on an ECMP path of one hop distance. The Packet Forwarding Engine does not distribute the traffic equally, but considers the balance values and distributes the traffic according to the bandwidth availability. However, this feature is not available for ECMP paths that are more than one hop away.
  • Support for BGP Optimal Route Reflection (BGP-ORR) (MX Series)—Starting with Junos OS Release 15.1F4, you can configure BGP-ORR with IS-IS as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.

    To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.

    Client groups sharing the same or similar IGP topology can be grouped as one BGP peer group. You can configure optimal-route-reflection to enable BGP-ORR in that BGP peer group. You can also configure one of the client nodes as the primary node (igp-primary) in a BGP peer group so that the IGP metric from that primary node is used to select the best path and advertise it to the clients in the same BGP peer group. Optionally, you can also select another client node as the backup node (igp-backup), which is used when the primary node (igp-primary) goes down or is unreachable.

    Use the following CLI hierarchy to configure BGP-ORR:

    [edit protocols bgp]
    group group-name{optimal-route-reflection {igp-primary ipv4-address;igp-backup ipv4-address;}}

    Use the following CLI commands to monitor and troubleshoot the configuration for BGP-ORR:

    • show bgp group—View the primary and backup configurations of BGP-ORR.
    • show isis bgp-orr—View the IS-IS BGP-ORR metric (RIB).
    • show route advertising protocol bgp peer—Verify whether the routes are being advertised according to the BGP-ORR rules.
  • IS-IS purge originator identification TLV (MX Series)—Beginning with Release 15.1F4, Junos OS supports RFC 6232, Purge Originator Identification TLV for IS-IS, which defines a type, length and value (TLV) for identifying the origin of a purge initiated by the IS-IS protocol. You can configure this feature to add this TLV to a purge along with the system ID of the Intermediate System (IS) that has initiated this purge. This makes it easier to locate the origin of the purge and its cause.

Software Installation and Upgradation

  • Limited encryption Junos OS image (“Junos Limited”) created for customers in Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia (MX240, MX480, MX960, MX2010, MX2020)—Starting in Junos OS Release 15.1F4, customers in the Eurasian Customs Union (currently comprising of Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia) should use the “Junos Limited” image for MX240, MX480, MX960, MX2010, and MX2020 routers instead of the “Junos Worldwide” image. The “Junos Limited” image does not have data-plane encryption and is intended only for countries in the Eurasian Customs Union because these countries have import restrictions on software containing data plane encryption. Unlike the “Junos Worldwide” image, the “Junos Limited” image supports control plane encryption through Secure Shell (SSH) and Secure Sockets Layer (SSL), thus allowing secure management of the system.

    Note: The limited encryption Junos OS image (“Junos Limited”) is to be used by customers in Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia. Customers in all other countries should use the “Junos” image that was introduced in 15.1R1 to replace “Junos Domestic” image.

Software-Defined Networking

  • Dynamic acquisition of network topology (MX Series)—Starting in Junos OS Release 15.1F4, the network topology abstraction daemon (ntad) provides the functionality to dynamically acquire the network topology. The NorthStar Controller runs Junos OS in a virtual machine (VM) that uses BGP-LS (the preferred protocol) or OSPF/IS-IS to learn the network topology. In Junos OS, BGP-LS or IGP publishes the acquired topology it learns into the traffic engineering database, which provides an in-memory representation of the network topology. The network topology abstraction daemon produces a copy of the traffic engineering database that the topology server uses.
  • Standby and secondary LSPs (MX Series)—Starting in Junos OS Release 15.1F4, standby and secondary LSPs provide an alternate route in the event the primary route fails. The tunnel ID, from node, to node, and IP address of a secondary or standby LSP are identical to that of the primary LSP. However, secondary and standby LSPs have the following differences:
    • A secondary LSP is not signaled until the primary LSP fails.
    • A standby LSP is signaled regardless of the status of the primary LSP.
  • PCC multiple template support (MX Series)—Starting in Junos OS Release 15.1F4, you can create LSP templates to define a set of LSP attributes to apply to all PCE-initiated LSPs that provide a name match with the regular expression (regex) name specified in the template. By associating LSPs (through regex name matching) with an LSP template, you can automatically enable or disable LSP attributes across any LSPs that provide a name match with the regex name.
  • PCC delegation of auto-bandwidth and TE++ (MX Series)—Starting in Junos OS Release 15.1F4, a TE++ LSP includes a set of paths that are configured as a specific container statement and individual LSP statements, called sub-LSPs, which all have equal bandwidth. For TE++ LSPs, a normalization process resizes the LSP when either of the following two triggers occurs:
    • A periodic timer occurs.
    • Bandwidth thresholds are met.

    These triggers elicit one of the following responses:

    • No change is required.
    • LSP splitting—add another LSP and distribute bandwidth across all the LSPs.
    • LSP merging—delete an LSP and distribute bandwidth across all the LSPs.

    For a TE++ LSP, the NorthStar Controller displays a single LSP with a set of paths. The LSP name is based on the matching prefix name of all members. The correlation between TE LSPs is based on association, and the LSP is deleted when there are no remaining TE LSPs.

  • IGP-based topology discovery (MX Series)—Starting in Junos OS Release 15.1F4, the NorthStar Controller supports dynamic topology acquisition by using routing protocols (IS-IS, OSPF, and BGP LS) to obtain real-time topology updates.
  • Standby and secondary LSPs (MX Series)—Starting in Junos OS Release 15.1F4, standby and secondary LSPs provide an alternate route in the event the primary route fails. The tunnel ID, from node, to node, and IP address of a secondary or standby LSP are identical to that of the primary LSP. However, secondary and standby LSPs have the following differences:
    • A secondary LSP is not signaled until the primary LSP fails.
    • A standby LSP is signaled regardless of the status of the primary LSP.
  • Support of Internet draft draft-ietf-pce-stateful-pce-07 for the stateful PCC implementation (MX Series and T Series)—The partial client-side implementation of the stateful Path Computation Element (PCE) architecture is currently based on version 2 of Internet draft draft-ietf-pce-stateful-pce. Starting with Junos OS Release 14.2R4 and 15.1F4, this implementation is upgraded to support version 7, as defined in Internet draft draft-ietf-pce-stateful-pce-07.

    Releases prior to 14.2R4 support the older version of the PCE draft, causing interoperability issues between a Path Computation Client (PCC) running a previous release and a stateful PCE server that adheres to Internet draft draft-ietf-pce-stateful-pce-07.

  • Support of Internet draft draft-crabbe-pce-pce-initiated-lsp-03 for the stateful PCE-initiated LSP implementation (MX Series and T Series)—In the partial client-side implementation of the stateful Path Computation Element (PCE) architecture, the implementation of PCE-controlled LSPs that are dynamically initiated by a PCE is currently based on version 1 of Internet draft draft-crabbe-pce-pce-initiated-lsp. Starting with Junos OS Release 14.2R4 and 15.1F4, this implementation is upgraded to support version 3, as defined in Internet draft draft-crabbe-pce-pce-initiated-lsp-03.

    Releases earlier than Junos OS Release 14.2R4 support the older version of the PCE draft, causing interoperability issues between a Path Computation Client (PCC) running a previous release and a stateful PCE server that adheres to Internet draft draft-crabbe-pce-pce-initiated-lsp-03.

  • OVSDB support (MX80, MX240, MX480, MX960, MX2010, MX2020 routers)—Starting with Junos OS Release 15.1F4, the Junos OS implementation of the Open vSwitch Database (OVSDB) management protocol provides a means through which VMware NSX controllers and MX Series routers that support OVSDB can communicate. In an NSX multi-hypervisor environment, NSX controllers and MX routers can exchange control and statistical information via the OVSDB schema, thereby enabling virtual machine (VM) traffic from entities in a virtual network to be forwarded to entities in a physical network and the reverse.

Subscriber Management and Services (MX Series)

  • New support for Framed-IP-Netmask for access-internal routes (MX Series)—Starting in Junos OS Release 15.1F3, the mask value returned by RADIUS in the Framed-IP-Netmask attribute during PPP negotiation is considered for application to the access-internal route for the subscriber session. In earlier releases, the attribute mask is ignored and a /32 netmask is always applied, with the consequence that the address is set to the value of the Framed-IP-Address attribute returned by RADIUS.

    Now, when the SDB_FRAMED_PROTOCOL attribute is equal to AUTHD_FRAMED_PROTOCOL_PPP, the value of SDB_USER_IP_MASK is set to 255.255.255.255 by default. This value is overridden by the Framed-IP-Netmask value, if present.

    The IP Netmask field in the output of the show subscribers command now displays the default value of 255.255.255.255 or the actual value of Framed-IP-Netmask only when the SDB_FRAMED_PROTOCOL attribute is equal to AUTHD_FRAMED_PROTOCOL_PPP.

VPNs

  • VPLS dynamic profiles not supported with 64-bit rpd (MX Series)— Starting with Junos OS Release 15.1F3, virtual private LAN service (VPLS) dynamic profiles are not supported with the 64-bit mode routing protocol process (rpd). A new system log error (RPD_DYN_CFG_64RPD_UNSUPPORTED) is displayed when this condition occurs indicating that rpd failed to notify the dynamic configuration clients about its availability to process the dynamic configuration requests. To enable the VPLS dynamic profiles configuration and use 32-bit mode, configure rpd by using the set system process routing force-32-bit command in the CLI.

Related Documentation

Modified: 2016-04-20