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 
  
[+] Expand All
[-] Collapse All

New and Changed Features

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

High Availability (HA) and Resiliency

  • Support for unified ISSU on MX Series routers with MPC5E and MPC6E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 15.1F2, Junos OS supports unified in-service software upgrade (ISSU) on MX Series routers with MPC5E (MPC5E-40G10G, MPC5E-100G10G), MPC5EQ (MPC5EQ-40G10G, MPC5EQ-100G10G), and MPC6E (MX2K-MPC6E). Junos OS also extends support for unified ISSU on the following MICs that are supported on MPC6E:
    • 10-Gigabit Ethernet MIC with SFP+ (24 Ports)
    • 10-Gigabit Ethernet OTN MIC with SFP+ (24 Ports) (non-OTN mode only)
    • 100-Gigabit Ethernet MIC with CFP2 (non-OTN mode only)
    • 100-Gigabit Ethernet MIC with CXP (4 Ports)

Interfaces and Chassis

  • Support for ITU-T Y.1731 ETH-LM, ETH-SLM, and ETH-DM on aggregated Ethernet interfaces (MX Series routers with MPCs)—Starting in Junos OS Release 15.1F2, you can configure ITU-T Y.1731 standard-compliant Ethernet loss measurement (ETH-LM), Ethernet synthetic loss measurement (ETH-SLM), and Ethernet delay measurement (ETH-DM) capabilities on aggregated Ethernet (ae) interfaces. These performance monitoring functionalities are supported on MX Series routers with MPCs, where the same level of support for the Ethernet services OAM mechanisms as the level of support on non-aggregated Ethernet interfaces is available on aggregated Ethernet interfaces. ETH-DM is supported on MPC3E and MPC4E modules with only software timestamping. ETH-SLM is supported on MPC3E and MPC4E modules.
  • Routing Engine failover detection (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 15.1F2, you use the on-re-to-fpc-stale configuration statement at the [edit chassis redundancy failover] hierarchy level to instruct the backup Routing Engine to take the mastership if the em0 interface fails on the master Routing Engine.
  • Support for targeted aggregated Ethernet distribution (MX Series routers with MPCs/MICs)—In Junos OS Release 15.1F2 and later, you can direct traffic through specified links of a logical interface of an aggregate Ethernet bundle that is configured without link protection. This feature is supported on interfaces configured on MX Series MPCs and MICs.

    By default, aggregated Ethernet bundles use a hash-based algorithm to distribute traffic over multiple links. Traffic destined through a logical interface of a bundle can exit through any of the member links based on the hashing algorithm. Therefore, egress policy enforcement might not always be accurate.

    By configuring targeted aggregated Ethernet distribution, you can create distribution lists consisting of specific child member links. You can, therefore, enforce egress transit traffic to traverse through the specified links of the distribution lists. This configuration helps you enforce egress policies correctly. That is, you can implement policers on specific links that carry the desired traffic.

    Note: Targeted aggregated Ethernet distribution can be applied to egress transit traffic only, excluding host outbound traffic.

MPLS

  • Leaking MPLS routes to nondefault routing instances (MX Series routers with MPC/MIC interfaces)—Starting in Junos OS Release 15.1F2, you can use the import-labeled-routes statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level to specify one or more nondefault routing instances where you want MPLS pseudowire labeled routes to be leaked from the mpls.0 path routing table in the master routing instance.

    This capability prevents traffic loss in an L2VPN/VPLS configuration where the remote PE router is learned from the IGP in a nondefault routing instance. Because ingress-labeled routes are installed only in the master mpls.0 table by default, no route is found in the routing-instance-name.mpls.0 table when L2VPN/VPLS traffic received on the core-facing interface, and that traffic is dropped.

Multicast

  • Protection against label spoofing or errant label injection across ASBRs (MX Series)—Starting with Junos OS Release 15.1F2, you can use regular BGP implicit and explicit export policies to restrict VPN ASBR peer route advertisement to a given routing instance.

    This is especially useful in the context of Inter-AS VPN Option-B ASBRs because it prevents a peer ASBR in a neighboring AS from spoofing or unintentionally injecting a VPN label intended for a different peer AS or intra-AS into the protected AS. In other words, service providers can configure a common ASBR so it does not accept MPLS packets from a peer ASBR unless the label has been explicitly advertised to the common ASBR.

    Two new commands are introduced to provide this protection: mpls-forwarding at the [edit routing-instances name instance-type mpls-forwarding] hierarchy level and forwarding-context at the [edit protocols bgp group group-name neighbor address], hierarchy level.

  • SAFI 129 NLRI compliance with RFC 6514 (MX Series)—Starting with Junos OS Release 15.1F2, the NLRI format available for BGP VPN multicast is changing from the de facto format of SAFI 128 to SAFI 129 as defined in RFC 6514. SAFI 128 uses length, label, prefix. SAFI 129 uses length, prefix.

    To use SAFI 129, enable the rfc6514-compliant-safi129 statement at any of the following hierarchy levels: [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp group group-name neighbor address].

  • Improved scaling for multicast OIFs (MX Series)—Starting with Junos OS Release 15.1F2, for both Rosen and next-generation MVPN, improvements have been made to increase the number of possible outgoing interfaces (OIFs) used in virtual routing and forwarding (VRF). Changes have also been made to improve the efficiency and scalability of PIM Join/Prune message processing.

    These changes are implemented by default and do not need to be explicitly enabled. The following operational commands support the increased scaling.

    • show multicast next-hops terse
    • show multicast route oif-count
    • show multicast statistics interface
    • show pim join downstream-count
  • Improved multicast convergence and RPT-SPT support for BGP-MVPN (MX Series)—Starting with Junos OS Release 15.1F2, support for multicast forwarding-cache threshold is extended to rendezvous-point tree shortest-path tree (RPT-SPT) mode for BGP-MVPN. In addition, for both Rosen and next-generation MVPNs, PE routers across all sites should see the same set of multicast routes even if the configured forwarding-cache limit is exceeded.

    To configure a specific threshold for MVPN RPT, set one or both of the mvpn-rpt-suppress and mvpn-rpt-reuse statements at the [edit routing-instances name routing-options multicast forwarding-cache] or [edit logical system name routing-instances name routing-options multicast forwarding-cache] hierarchy level.

    In addition, the show multicast forwarding-cache statistics command provides information about both the general and RPT-suppression states. Likewise, a list of suppressed customer-multicast states can be seen by running the show mvpn suppressed general|mvpn-rpt inet|inet6 instance name summary command.

Services Applications

  • Support for inline MPLS Junos Traffic Vision with IPFIX and v9 (MX Series)—Starting in Junos OS Release 15.1F2, support of the MX Series routers for the inline Junos Traffic Vision feature is extended to the MPLS family (MPLS and MPLS-IPv4 templates) consisting of the IP Flow Information Export (IPFIX) protocol and flow monitoring version 9 (v9). In previous releases, the inline Junos Traffic Vision feature is supported only for IPv4, IPv6, and VPLS families.

    Inline Junos Traffic Vision feature is extended to MPC5E and MPC6E (XL-based chips) for VPLS address family. Also, Inline Junos Traffic Vision support using version 9 templates is extended to VPLS family.

Software Installation and Upgrade

  • Validate system software against running configuration on remote host—Beginning with Junos OS Release 15.1F2, you can use the on (host host <username username> | routing-engine routing-engine) option with the request system software validate package-name command to verify candidate system software against the running configuration on the specified remote host or Routing Engine.

System Management

  • Statement introduced to deny hidden commands—Starting in Release 15.1F2, Junos OS allows users to deny hidden commands to all users except root. To deny hidden commands to all users except root, use the set system no-hidden-commands statement at the [edit] hierarchy level.

User Interface and Configuration

  • Monitoring, detecting, and taking action on degraded physical 10-Gigabit, 40-Gigabit, and 100-Gigabit Ethernet links to minimize packet loss (MX Series routers with MPCE, MPC3, and MPC4E)—Starting with Junos OS Release 15.1F2, you can monitor physical link degradation (indicated by bit error rate (BER) threshold levels) on Ethernet interfaces, and take corrective actions if the BER threshold value drops to a value in the range of 10-13 to 10-5.

    Layer 2 and Layer 3 protocols support the monitoring of physical link degradation. An Ethernet link also supports monitoring of physical link degradation through the Link Fault Signaling (LFS) protocol. However, for both of these monitoring mechanisms, the BER threshold value range of 10-13 to 10-5 is very low. Because of the low BER threshold value, the physical link degradation goes undetected, causing disruption and packet loss on an Ethernet link.

    The following new configurations have been introduced at the [edit interfaces interface-name] hierarchy level to support the physical link degrade monitoring and recovery feature on Junos OS:

    • To monitor physical link degrade on Ethernet interfaces, configure the link-degrade-monitor statement.

    • To configure the BER threshold value at which the corrective action must be triggered on or cleared from an interface, use the link-degrade-monitor thresholds (set value | clear value) statement. The value is the BER threshold value in scientific notation. You can configure this value in the 1E–n format, where 1 is the mantissa (remains constant) and n is the exponent. For example, a threshold value of IE–3 refers to the BER threshold value of 1x10-3.

      The supported exponent range is 1 through 16, and the default value is 7 for the set configuration and 12 for the clear configuration.

    • To configure the link degrade interval value, use the link-degrade-monitor thresholds interval value statement. The configured interval value determines the number of consecutive link degrade events that are considered before any corrective action is taken. The supported value range for the interval is 1 through 256, and the default interval is 10.
    • To configure link degrade warning thresholds, use the link-degrade-monitor thresholds (warning-set value | warning-clear value) statement. The value is again specified in the 1E–n format, and the supported value range for n is 1 through 16. With this configuration, every time the BER threshold value is reached, a system message is logged to indicate that link degradation has occurred (warning-set) or link degradation has been cleared (warning-clear) on an interface.
    • To configure the link degrade action that is taken when the configured BER threshold level is reached, use the link-degrade action media-based statement. A media-based action or fast reroute brings down the physical interface at the local end of the interface, and stops BER monitoring on the interface (although link fail is active at the local end, and recovery fail is active on the remote end of the degraded link) until an autorecovery mechanism is triggered.
    • To configure the link degrade recovery options, use the link-degrade recovery (auto interval value | manual) statement. The recovery mechanism triggers the recovery of a degraded link.

      The auto recovery option is used with the media-based action when there are no Layer 2 or Layer 3 protocols configured on the interface. With the auto recovery option, you must configure the interval value in seconds. The system then triggers the autorecovery mechanism on a degraded link. The default interval is 1800 seconds.

      The manual recovery option is configured with the media-based action configuration when Layer 2 and Layer 3 protocols are configured on an interface. To trigger manual recovery, use the request interface link-degrade-recover interface-name statement.

    You can view the link recovery status and the BER threshold values by using the show interfaces interface-name command.

VPNs

  • Flow-aware transport pseudowire for BGP L2VPN and BGP VPLS (MX Series and T Series)— Starting with Junos OS Release 15.1F2, the flow-aware transport (FAT) label that is supported for BGP-signaled pseudowires such as L2VPN and VPLS is configured only on the label edge routers (LERs). This causes the transit routers or label-switching routers(LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload. The FAT flow label can be used for LDP-signaled forwarding equivalence class (FEC 128 and FEC 129) pseudowires for VPWS and VPLS pseudowires.

Related Documentation

Modified: 2017-07-06