Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

New and Changed Features

 

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

Hardware

  • New MPC variants that support higher scale and bandwidth (MX Series)—Starting with Junos OS Release 15.1R1, the following variants of a new MPC with higher scale and bandwidth are supported on MX Series routers:

    • MPC2E-3D-NG—80 Gbps capacity without hierarchical quality of service (HQoS)

    • MPC2E-3D-NG-Q—80 Gbps capacity with HQoS

    • MPC3E-3D-NG—130 Gbps capacity without HQoS

    • MPC3E-3D-NG-Q—130 Gbps capacity with HQoS

    The HQoS variants of this MPC support flexible queuing at 80 Gbps or 130 Gbps. See MIC/MPC Compatibility for supported MICs on these MPCs.

    Note

    The MPC2E-3D-NG, MPC2E-3D-NG-Q, MPC3E-3D-NG, and MPC3E-3D-NG-Q are also supported in Junos OS Release 14.1R4. To support these MPCs in 14.1R4, you must install Junos Continuity software. See Junos Continuity Software for more details.

    Note

    The non-HQoS MPCs support MIC-3D-4COC3-1COC12-CE, MIC-3D-8CHOC3-4CHOC12, and MIC-3D-4CHOC3-2CHOC12 when they are upgraded to the HQoS model through a license.

    MPC2E-3D-NG and MPC2E-3D-NG-Q do not support MIC3-3D-10XGE-SFPP, MIC3-3D-1X100GE-CFP, MIC3-3D-1X100GE-CXP, and MIC3-3D-2X40GE-QSFPP.

  • Starting in Junos OS Release 15.1R1, the Juniper Networks MX2010 and Juniper Networks MX2020 routers support the following new power distribution modules:

    • 7-feed single-phase AC PDM

    • 9-feed single-phase AC PDM

    • 7-feed DC PDM

    In addition, this release supports a new optimized power fan tray.

Bridging and Learning

  • Support for modifying MAC table aging timer for bridge domains (MX Series)—Starting with Junos OS Release 15.1R1, you can modify the aging timer for MAC table entries of a bridge domain. When the aging timer for a MAC address in a MAC table expires, the MAC address is removed from the table. This aging process ensures that the router tracks only active MAC addresses on the network and that it is able to flush out MAC addresses that are no longer available.

    The default aging timer for MAC entries is 300 seconds. Depending on how long you want to keep a MAC address in a MAC table before it expires, you can either increase or decrease the aging timer. To modify the aging timer for MAC entries in a MAC table, use the mac-table-aging-timer statement at one of the following hierarchy levels:

    • [edit bridge-domains bridge-domain-name bridge-options]

    • [edit routing-instances routing-instance-name protocols vpls]

    • [edit routing-instances routing-instance-name protocols evpn]

  • Support for L2TP drain (MX Series)—Starting in Junos OS Release 15.1R1, you can prevent the creation of new Layer 2 Tunneling Protocol (L2TP) sessions, destinations, and tunnels at an LNS or a LAC for administrative purposes.

    To configure this feature, use the drain statement at the [edit services l2tp] hierarchy level. You can configure this feature at the global level or for a specific destination or tunnel. Configuring this feature on a router sets the administrative state of the L2TP session, destination, or tunnel to drain, which ensures that no new destinations, sessions, or tunnels are created at the specified LNS or LAC.

    Note

    This feature does not affect existing L2TP sessions, destinations, or tunnels.

    [See Configuring L2TP Drain, show services l2tp destination, and show services l2tp tunnel.]

Class of Service (CoS)

  • Extended MPC support for per-unit schedulers (MX Series)—Starting in Junos OS Release 15.1R1 you can configure per-unit schedulers on the non-queuing MPC6E, meaning you can include the per-unit-scheduler statement at the [edit interfaces interface name] hierarchy level. When per-unit schedulers are enabled, you can define dedicated schedulers for logical interfaces.

    Enabling per-unit schedulers on the MPC6E adds additional output to the show interfaces interface name [detail | extensive] command. This additional output lists the maximum resources available and the number of configured resources for schedulers.

    [See Scheduler Maps and Shaping Rate to DLCIs and VLANs.]

  • Change to CoS shaping rate fallback behavior (MX Series)—Starting in Junos OS Release 15.1R1, when a CoS service profile is deactivated, the traffic shaping rate falls back in the following order: ANCP shaping rate, PPPoE IA tag rate, or shaping rate configured in the traffic control profile. In earlier releases, the traffic shaping rate falls back to the ANCP adjusted rate or the traffic control profile value.

    Now when an ANCP shaping rate adjustment is removed, the rate falls back to the PPPoE IA tag rate or the traffic control profile value. In earlier releases, the rate falls back to the traffic control profile value.

    [See CoS Adjustment Control Profiles Overview.]

  • Hierarchical CoS support for GRE tunnel interface output queues (MX Series routers with MPC5E)–Starting with Junos OS Release 15.1R2, you can manage output queuing of traffic entering GRE tunnel interfaces hosted on MPC5E line cards in MX Series routers. Support for the output-traffic-control-profile configuration statement, which applies an output traffic scheduling and shaping profile to the interface, is extended to GRE tunnel physical and logical interfaces. Support for the output-traffic-control-profile-remaining configuration statement, which applies an output traffic scheduling and shaping profile for remaining traffic to the interface, is extended to GRE tunnel physical interfaces.

    Note

    Interface sets (sets of interfaces used to configure hierarchical CoS schedulers on supported Ethernet interfaces) are not supported on GRE tunnel interfaces.

    [See Configuring Traffic Control Profiles for Shared Scheduling and Shaping.]

  • Support for suppressing the default classifier (MX Series)—Beginning with Junos OS Release 15.1R5, you can disable the application of the default classifier on an interface or a routing instance to preserve the incoming classifier. This is done by applying the no-default option at the [edit class-of-service routing-instances routing-instance-name classifiers] hierarchy level. This is useful, for example, in a bridge domain, where the default classifier for the interface overrides the configured classifier for the domain.

    [See Applying Behavior Aggregate Classifiers to Logical Interfaces.]

High Availability (HA) and Resiliency

  • MX Series Virtual Chassis support for MX2010 and MX2020 member routers (MX Series routers with MPCs/MICs)—Starting in Junos OS Release 15.1R1, you can configure an MX2010 router or MX2020 router as a member router in an MX Series Virtual Chassis. In earlier releases, MX2010 routers and MX2020 routers cannot function as member routers in an MX Series Virtual Chassis.

    In a two-member Virtual Chassis configuration, the following member router combinations are supported with an MX2010 router or MX2020 router:

    • MX960 router and MX2010 router

    • MX960 router and MX2020 router

    • MX2010 router and MX2020 router

    • MX2010 router and MX2010 router

    • MX2020 router and MX2020 router

    To ensure that a Virtual Chassis configuration consisting of an MX2020 router and either an MX960 router or MX2010 router forms properly, you must issue the request virtual-chassis member-id set member member-id slots-per-chassis slot-count command, where member-id is the member ID (0 or 1) configured for the MX960 router or MX2010 router, and slot-count is 20 to match the slot count for the MX2020 router. In addition, for a Virtual Chassis that includes an MX2020 member router, all four Routing Engines in the Virtual Chassis configuration must have at least 16 gigabytes of memory.

    [See Configuring an MX2020 Member Router in an Existing MX Series Virtual Chassis.]

  • Relay daemon code removed for MX Series Virtual Chassis (MX Series routers with MPCs/MICs)—Starting in Junos OS Release 15.1R1, the code associated with the relay software process (relayd) has been removed for use with MX Series Virtual Chassis configurations. In earlier releases, the relayd functionality was disabled, but the code implementing this functionality was still present in the software. Removing the relayd functionality and related software code reduces the risk of timing issues for MX Series Virtual Chassis configurations and improves overall performance and stability.

    With the removal of the relay daemon code for MX Series Virtual Chassis, certain operational commands no longer display information pertaining to the relayd process in the output for an MX Series Virtual Chassis. Examples of the affected commands include show system core-dumps, show system memory, and show system processes.

    In addition, the following relayd error messages have been removed from the software for MX Series Virtual Chassis:

    • RELAYD_COMMAND_OPTIONS

    • RELAYD_COMMAND_OPTION_ERROR

    • RELAYD_SYSCALL_ERROR

  • Configuration support for multiple MEPs for interfaces belonging to a single VPLS service, CCC, or bridge domain (MX Series)—Starting with Junos OS Release 15.1R1, you can configure multiple maintenance endpoints (MEPs) for a single combination of maintenance association and maintenance domain IDs for interfaces belonging to a particular VPLS service, circuit cross-connect (CCC), or bridge domain.

    To configure multiple MEPs, use the existing mep mep-id statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance association ma-name] hierarchy level.

  • NSR and validation-extension for BGP flowspec—Starting in Junos OS Release 15.1R1, changes are implemented to add NSR support for existing inet-flow and inetvpnflow families and to extend routes validation for BGP flowspec. Two new statements are introduced as part of this enhancement.

    [See enforce-first-as and no-install.]

  • Enhancements made to unified ISSU for VRRPv3 to avoid adjacency flap (M Series and MX Series)—Starting in Junos OS Release 15.1R1, enhancements have been made to maintain protocol adjacency with peer routers during unified ISSU and to maintain interoperability among equipment and with other Junos OS releases and other Juniper Networks products. This design is for VRRPv3 only. VRRPv1 and VRRPv2 are not supported. The show vrrp command output is updated to display unified ISSU information.

    [See show vrrp and Junos OS Support for VRRPv3.]

  • New solution to determine when to tear down old LSP instances (M Series, MX Series, and T Series)—Starting in Junos OS Release 15.1R1, a feedback mechanism supersedes the delay created by using the optimize-hold-dead-delay statement. Configure this feature by using the optimize-adaptive-teardown statement on routers acting as the ingress for the affected LSPs.

    [See Achieving a Make-Before-Break, Hitless Switchover for LSPs, and optimze-adaptive-teardown.]

  • Graceful restart values are configurable at the [edit routing-instances] hierarchy level (M Series and T Series)—Starting in Junos OS Release 15.1R1, the graceful-restart configuration statement is configurable at the level of individual routing instances. This means you can have different values for different instances. For example, you can have a routing instance configured with IGMP snooping and another with PIM snooping and configure a graceful restart timer value at the instance level that is tuned for each instance.

    [See Configuring Graceful Restart for Multicast Snooping and graceful-restart (Multicast Snooping).]

  • Junos OS achieves higher scaling for VRRP over logical interfaces—Starting in Junos OS Release 15.1R1, a new option for the delegate-processing statement allows for VRRP over logical interfaces such as aggregated Ethernet and IRB interfaces.

    [See delegate-processing.]

  • New option providing detailed information about the stages in an ISSU operation (MX240, MX480, MX960, MX2010, and MX2020 Universal Routing Platforms)—Starting in Junos OS Release 15.1R6 a new option, verbose, is added at the [request system software in-service-upgrade package-name] hierarchy level. This new option provides information about all stages in a unified ISSU operation.

    When this option added to the command, the output provides the following additional information:

    • State of various Routing Engine daemons

    • Daemon that caused the failure of an unified ISSU operation in cases where the ISSU is aborted because of daemon readiness check failure

    • Progress of a unified ISSU operation, such as the initialization, hardware synchronization, and completion

Interfaces and Chassis

  • Synchronous Ethernet and Precision Time Protocol (PTP) support on MPC3E-3D-NG-Q, MPC3E-3D-NG, MPC2E-3D-NG-Q, and MPC2E-3D-NG (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 15.1R2, synchronous Ethernet and PTP are supported on MPC3E-3D-NG-Q, MPC3E-3D-NG, MPC2E-3D-NG-Q, and MPC2E-3D-NG. The PTP feature includes support for ordinary clock (OC) and boundary clock (BC).

    [See Precision Time Protocol Overview and Synchronous Ethernet.]

  • CFP-100GBASE-ZR (MX Series)—In Junos OS Release 13.3R6, 14.1R4, 14.2R3, and 15.1R1 and later, the CFP-100GBASE-ZR transceiver provides advanced dual polarization-quadrature phase shift keying (DP-QPSK) coherent digital signal processing (DSP) and forward error correction (FEC)-enabled robust tolerance to optical impairments and supports 80 km reach over single-mode fiber. The transceiver is not specified as part of IEEE 802.3 but is built according to Juniper Networks specifications. The following interface modules support the CFP-100GBASE-ZR transceiver:

    • 2x100GE + 8x10GE MPC4E (MPC4E-3D-2CGE-8XGE)

    • 100-Gigabit Ethernet MIC with CFP (MIC3-3D-1X100GE-CFP)

    For more information about the interface modules, see the “Cables and Connectors” section in the MX Series Interface Module Reference.

    [See 100-Gigabit Ethernet 100GBASE-R Optical Interface Specifications and Supported Network Interface Standards by Transceiver for ACX, M, MX, and T Series Routers.]

  • Maximum generation rate for ICMP and ICMPv6 messages is configurable (MX Series)—Starting in Junos OS Release 15.1R1, you can configure the maximum rate at which ICMP and ICMPv6 messages that are not ttl-expired are generated by using the icmp and icmp6 and configuration statements at the [edit chassis] hierarchy level.

  • CPU utilization status (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 15.1R1, you can view the average CPU utilization status of the local Routing Engine in the past 1 minute, 5 minutes, and 15 minutes using the show chassis routing-engine command. You can also view the average CPU utilization status of FPCs in the master Routing Engine in the past 1 minute, 5 minutes, and 15 minutes using the show chassis fpc command. In addition, the following three new Juniper Networks enterprise-specific SNMP MIB objects are introduced in the jnxOperatingTable table in the jnxBoxAnatomy MIB:

    • jnxOperating1MinAvgCPU

    • jnxOperating5MinAvgCPU

    • jnxOperating15MinAvgCPU

    [See jnxBoxAnatomy, show chassis fpc, and show chassis routing engine.]

  • Support for a resource-monitoring mechanism using CLI statements and SNMP MIB objects (MX Series routers with DPCs and MPCs)—Starting in Junos OS Release 15.1R1, Junos OS supports a resource monitoring capability using both the configuration statements in the CLI and SNMP MIB queries. You can employ this utility to provision sufficient headroom (memory space limits that are set for the application or virtual router) for monitoring the health and operating efficiency of DPCs and MPCs. To configure the resource-monitoring capability on MX240, MX480, MX960, MX2010, and MX2020 routers, include the resource-monitor statement and its substatements at the [edit system services] hierarchy level. You specify the high threshold value that is common for all the memory spaces or regions and the watermark values for the different memory blocks on DPCs and MPCs.

  • Dynamic learning of source and destination MAC addresses on aggregated Ethernet interfaces (M Series, MX Series, and T Series)—Starting in Junos OS Release 15.1R1, support for dynamic learning of the source and destination MAC addresses is extended to aggregated Ethernet interfaces on the following cards: Gigabit Ethernet DPCs on MX Series routers, Gigabit Ethernet IQ and Gigabit Ethernet PICs with SFPs (except the 10-port Gigabit Ethernet PIC and the built-in Gigabit Ethernet port on the M7i router), 100-Gigabit Ethernet Type 5 PIC with CFP configured, and MPC3E, MPC4E, MPC5E, MPC5EQ, and MPC6E MPCs.

    [See Configuring MAC Address Accounting.]

  • Support for MACsec (MX Series)—Starting in Junos OS Release 15.1R1, you can configure Media Access Control Security (MACsec) on MX Series routers with the enhanced 20-port Gigabit Ethernet MIC (model number MIC-3D-20GE-SFP-E). MACsec is an industry-standard security technology that provides secure communication for almost all types of traffic on Ethernet links. You can enable MACsec using static connectivity association key (CAK) security mode by using the connectivity-association connectivity-association-name statement and its substatements at the [edit security macsec] hierarchy level. MACsec is supported on MX Series routers with MACsec-capable interfaces. MACsec using static secure association key (SAK) security mode does not work properly on MX80 routers and FPC slots other than slot 0 of MX104 routers.

  • Fabric hardening enhancements (MX Series)—Starting in Junos OS Release 15.1R1, fabric hardening can be configured with two new CLI configuration commands, per fpc bandwidth-degradation and per fpc blackhole-action. Fabric hardening is the process of controlling bandwidth degradation to prevent traffic blackholing. The new commands give you more control over what threshold of bandwidth degradation to react to, and which corrective action to take.

    The per fpc bandwidth-degradation command determines how the FPC reacts when it reaches a specified bandwidth degradation percentage. The per fpc bandwidth-degradation command and the offline-on-fabric-bandwidth-reduction commands are mutually exclusive. If both commands are configured, an error is issued during the commit check.

    The per fpc blackhole-action command determines how the FPC responds to a 100 percent fabric degradation scenario. This command is optional and overrides the default fabric hardening procedures.

  • Support for flexible queuing on non-HQoS MPCs (MX Series)—Starting in Junos OS Release 15.1R1, you can enable flexible queuing on non-HQoS MPCs, such as the MPC2E-3D-NG and MPC3E-3D-NG. When flexible queuing is enabled, non-HQoS MPCs support a limited queuing capability of 32,000 queues per slot, including ingress and egress.

    You can enable flexible queuing by including the flexible-queuing-mode statement at the [edit chassis fpc] hierarchy level. When flexible queuing is enabled, the MPC is restarted and is brought online only if the power required for the queuing component is available in the PEM. The MPC remains offline if the PEM cannot meet the power requirement for the queuing component.

    The following MICs are supported on non-HQoS MPCs only when flexible queuing is enabled:

    • MIC-3D-8CHOC3-4CHOC12

    • MIC-3D-4CHOC3-2CHOC12

    You must purchase an add-on license to enable flexible queuing on a non-HQoS MPC.

  • Support for dynamic power management (MX Series)—Starting in Junos OS Release 15.1R1, MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, and MPC2E-3D-NG-Q support dynamic power management. When you enable dynamic power management, an MPC is powered on only if the power entry module (PEM) can meet the worst-case power requirement for the MPC. Power budgeting for MICs is performed only when a MIC is brought online. Whether or not a new device is powered on depends on the availability of power in the PEM.

    You can enable dynamic power management by including the mic-aware-power-management statement at the [edit chassis] hierarchy level. This feature is disabled by default. When this feature is disabled, the Chassis Manager checks for the worst-case power requirement of the MICs before allocating power for the MPCs. When dynamic power management is enabled, worst-case power consumption by MICs is not considered while budgeting power for an MPC. Every time you disable or enable dynamic power management, you must restart the chassis or the MPC for the changes to take effect.

  • Maximum generation rate for ICMP and ICMPv6 messages is configurable (MX Series)—Starting in Junos OS Release 15.1R1, you can configure the maximum rate at which ICMP and ICMPv6 messages that are not ttl-expired are generated by using the icmp and icmp6 and configuration statements at the [edit chassis] hierarchy level.

  • Synchronous Ethernet and Precision Time Protocol (PTP) support on MPC4E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 15.1R1, synchronous Ethernet and PTP are supported on MPC4E. The PTP feature includes support for ordinary clock (OC) and boundary clock (BC).

    [See Precision Time Protocol Overview, Synchronous Ethernet, and Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC4Es.]

  • Support for hyper mode to increase packet processing rate on enhanced MPCs (MX240, MX480, MX960, MX2010, and MX2020)—Starting in Junos OS Release 15.1R1, MPC3E, MPC4E, MPC5E, and MPC6E support the hyper mode feature. Enabling the hyper mode feature increases the rate at which a data packet is processed, which results in the optimization of the lifetime of a data packet. Optimization of the data packet lifetime enables better performance and throughput.

    Note

    You can enable hyper mode only if the network-service mode on the router is configured as either enhanced-ip or enhanced-ethernet. Also, you cannot enable the hyper mode feature for a specific Packet Forwarding Engine on an MPC—that is, when you enable the feature, it is applicable for all Packet Forwarding Engines on the router.

    When you enable the hyper mode feature, the following features are not supported:

    • Creation of Virtual Chassis.

    • Interoperability with legacy DPCs, including MS-DPCs. The MPC in hyper mode accepts and transmits data packets only from other existing MPCs.

    • Interoperability with non-Ethernet MICs and non-Ethernet Interfaces such as channelized interfaces, multilink interfaces, and SONET interfaces.

    • Padding of Ethernet frames with VLAN.

    • Sending Internet Control Message Protocol (ICMP) redirect messages.

    • Termination or tunneling of all subscriber-based services.

    To configure the hyper mode feature, use the hyper-mode statement at the [edit forwarding-options] hierarchy level. To view the changed configuration, use the show forwarding-options hyper-mode command.

  • QSFPP-40GE-LX4 (MX Series)—In Junos OS Release 15.1R3 and later, the QSFPP-40GE-LX4 transceiver provides 2 km reach over single-mode fiber, 100 m (with OM3 MMF cable), or 150 m (with OM4 MMF cable) reach over multimode fiber. Signaling speed for each channel is 10.3125 GBd with aggregated data rate 41.25 Gb/s. The module enables 40GBASE links over a pair of either SMF or MMF terminated with duplex LC connectors. The LC connector supports connections with physical contact (PC) or ultra physical contact (UPC) connectors. Patch cords with APC connectors are not supported. The 6x40GE +24X10GE MPC5EQ (model number: MPC5EQ-40G10G) supports the QSFPP-40GE-LX4 transceiver.

    For more information about the interface modules, see the “Cables and Connectors” section for the specific module in the MX Series Interface Module Reference.

    [See 40-Gigabit Ethernet 40GBASE-R Optical Interface Specifications.]

  • CFP2-100G-ER4-D (MX Series)—In Junos OS Releases 13.3R9, 14.2R6, 15.1R3 and later, the CFP2-100G-ER4-D transceiver provides dual-rate 40 km reach over G.652 single-mode fiber. Signaling speed for each channel is either 25.78125 GBd with aggregated data rate 103.125 Gb/s of 100GBASE-R, or 27.952493 GBd with aggregated data rate 111.81 Gb/s of OTU4 client interface. The CFP2-100G-ER4-D transceiver supports both IEEE 100GBASE-ER4 and ITU-T G.959.1 application code 4L1-9C1F. The duplex LC connector supports connections with Physical Contact (PC) or Ultra Physical Contact (UPC) connectors. Patch cords with APC connectors are not supported. The CFP2-100G-ER4-D supports the 100GBASE-ER4 standard. The following MPCs and MIC support the CFP2-100G-ER4-D transceiver:

    • 2x100GE + 4x10GE MPC5E (model number: MPC5E-100G10G)

    • 2x100GE + 4x10GE MPC5EQ (model number: MPC5EQ-100G10G)

    • 100-Gigabit Ethernet MIC with CFP2 (model number: MIC6-100G-CFP2)

    For more information about the interface modules, see the “Cables and Connectors” section for the specific module in the MX Series Interface Module Reference.

    [See 100-Gigabit Ethernet 100GBASE-R Optical Interface Specifications.]

  • CFP2-100G-SR10-D3 (MX Series)—In Junos OS Release 15.1R3 and later, the CFP2-100G-SR10-D3 transceiver provides dual rate 100 m (with OM3 MMF cable) and 150 m (with OM4 MFF cable) reach over multimode fiber. Signaling speed for each channel is either 10.3125 GBd with aggregated data rate 103.125 Gb/s of 100GBASE-R, or 11.181 GBd with aggregated data rate 111.81 Gb/s of OTU4 client interface. With 24-fiber ribbon cables that have MPO connectors, the module can support 100-gigabit links. With ribbon to duplex fiber breakout cables, the module can also support 10 x 10 Gigabit mode. The recommended Option A in IEEE STD 802.3-2012 is required. The CFP2-100G-SR10-D3 transceiver supports the 100GBASE-SR10 standard. The following MPCs and MIC support the CFP2-100G-SR10-D3 transceiver:

    • 2x100GE + 4x10GE MPC5E (model number: MPC5E-100G10G)

    • 2x100GE + 4x10GE MPC5EQ (model number: MPC5EQ-100G10G)

    • 100-Gigabit Ethernet MIC with CFP2 (model number: MIC6-100G-CFP2)

    For more information about the interface modules, see the “Cables and Connectors” section for the specific module in the MX Series Interface Module Reference.

    [See 100-Gigabit Ethernet 100GBASE-R Optical Interface Specifications.]

  • Enhancement to policer configuration—Starting in Junos OS Release 15.1R6, you can configure the MPC to take a value in the range 0 through 5 for the policer tick byte by using the policer-limit statement at the [edit chassis] hierarchy level. If this statement is not configured, the policer tick byte can take values up to 7, which is the default behavior. You can use the set chassis policer-limit command to enable this feature.

    You must restart the MPC or the router for the changes to take effect.

IPv6

Junos OS XML API and Scripting

  • Support for replacing patterns in configuration data within NETCONF and Junos XML protocol sessions (M Series, MX Series, and T Series)—Starting in Junos OS Release 15.1R1, you can replace variables and identifiers in the candidate configuration when performing a <load-configuration> operation in a Junos XML protocol or NETCONF session. The replace-pattern attribute specifies the pattern to replace, the with attribute specifies the replacement pattern, and the optional upto attribute indicates the number of occurrences to replace. The scope of the replacement is determined by the placement of the attributes in the configuration data. The functionality of the attribute is identical to that of the replace pattern configuration mode command in the Junos OS CLI.

    [See Replacing Patterns in Configuration Data Using the NETCONF or Junos XML Protocol.]

  • Junos OS SNMP scripts to support custom MIBs (M Series, MX Series, and T Series)—Starting with Junos OS Release 15.1R1, you can use Junos OS SNMP scripts to support custom MIBs until they are implemented in Junos OS. SNMP scripts are triggered automatically when the SNMP manager requests information from the SNMP agent for an object identifier (OID) that is mapped to an SNMP script for an unsupported OID. The script acts like an SNMP subagent, and the system sends the return value from the script to the network management system (NMS).

    [See SNMP Scripts Overview.]

Layer 2 Features

  • Configuration support for backup liveness detection between multichassis link aggregation peers (MX Series)—Starting with Junos OS Release 15.1R1, you can configure backup liveness detection between multichassis link aggregation (MC-LAG) peers.

    Backup liveness detection determines the peer status (that is, whether the peer is up or down) by exchanging keepalive messages between two MC-LAG peers on a configured IP address. MC-LAG peers use an Inter-Chassis Control Protocol (ICCP) connection to communicate. When an ICCP connection is operationally down, a peer can send liveness detection requests to determine the peer status. If a peer fails to respond to the liveness detection request within a specified time interval, the liveness detection check fails and the peer is concluded to be down.

    To configure backup liveness detection between MC-LAG peers, use the backup-liveness-detection backup-peer-ip backup-peer-ip-address statement at the [edit protocols iccp peer] hierarchy level.

    [See Configuring Multichassis Link Aggregation on MX Series Routers and show iccp.]

  • Support for PTP over Ethernet (MX Series)—Starting in Junos OS Release 15.1, Precision Time Protocol (PTP) is supported over Ethernet links on MX Series routers. This functionality is supported in compliance with the IEEE 1588-2008 specification.

    Some base station vendors might use only packet interfaces using Ethernet encapsulation for PTP for time and phase synchronization. To provide packet-based timing capability to packet interfaces used by such vendors, you can configure Ethernet encapsulation for PTP on the master port of any node (that is, an MX Series router) that is directly connected to the base station.

    To configure Ethernet as the encapsulation type for the transport of PTP packets on master or slave interfaces, use the transport 802.3 statement at the [edit protocols ptp slave interface interface-name multicast-mode] or [edit protocols ptp master interface interface-name multicast-mode] hierarchy level.

    [See Configuring Precision Time Protocol.]

  • Support extended for Layer 2 features (MX Series routers with MPC5E and MPC6)—Starting with Junos OS Release 15.1R2, Junos OS extends support for the following Layer 2 features on MX Series routers with MPC5E and MPC6:

    • Active-active multihoming support for EVPNs

    • Ethernet frame padding with VLAN for DPCs and MPCs

    • IEEE 802.1ad provider bridges

    • IGMP snooping with bridging, IRB, and VPLS

    • Layer 2 and Layer 2.5 integrated routing and bridging (IRB) and Spanning Tree Protocols (xSTP)

    • Layer 2 protocol tunneling (L2PT) support

    • Layer 2 support for MX Series Virtual Chassis

    • Layer 2 Tunneling Protocol (L2TP)

    • Link aggregation group (LAG)—VLAN-CCC encapsulation

    • Loop Detection using the MAC address Move

    • Multichassis LAG—active/active and active/standby

    • Multichassis LAG—active/active with IGMP snooping

    • Truck ports

    [See Junos OS Layer 2 Switching and Bridging Library.]

  • Hot-standby support for VPLS redundant pseudowires–Starting in Release 15.1R4, Junos OS enables you to configure redundant pseudowires. If a primary pseudowire fails, Junos OS switches service to a preconfigured redundant pseudowire.

    The time required for the redundant pseudowire to recover traffic from the primary pseudowire depends on the number of pseudowires and the option configured for pseudowire redundancy. There are three options:

    • Backup redundancy

    • Standby redundancy

    • Hot-standby

    The hot-standby option enables Junos OS to reduce the amount of traffic it discards during a transition from a primary to redundant pseudowire. Both the active and standby paths are kept open within the Layer 2 domain. Now you can configure the hot-standby option to configure pseudowires for virtual private LAN services (VPLS) running the Label Distribution Protocol (LDP).

  • Implicit maximum bandwidth for inline services for L2TP LNS (MX Series)—Starting in Junos OS Release 15.1R5, you are no longer required to explicitly specify a bandwidth for L2TP LNS tunnel traffic using inline services. When you do not specify a bandwidth, the maximum bandwidth supported on the PIC is automatically available for the inline services; inline services can use up to this maximum value. For example:

    user@host> show interfaces si-3/0/0
    user@host> show interfaces si-3/1/0

    In earlier releases, you must specify a bandwidth to enable inline services by including the bandwidth statement with the inline-services statement.

Management

  • Support for enforcing RFC-compliant behavior in NETCONF sessions (M Series, MX Series, and T Series)—Starting in Junos OS Release 15.1R1, you can require that the NETCONF server enforce certain behaviors during the NETCONF session by configuring the rfc-compliant statement at the [edit system services netconf] hierarchy level. When you configure the rfc-compliant statement, the NETCONF server explicitly declares the NETCONF namespace in its replies and qualifies all NETCONF tags with the nc prefix. Also, <get> and <get-config> operations that return no configuration data do not include an empty <configuration> element in RPC replies.

    [See Configuring RFC-Compliant NETCONF Sessions.]

  • New YANG features including configuration hierarchy must constraints published in YANG and a new module that defines Junos OS YANG extensions (M Series, MX Series, and T Series)—Starting in Junos OS Release 15.1R1, the Juniper Networks configuration YANG module includes configuration constraints published using either the YANG must statement or the Junos OS YANG extension junos:must. Constraints that cannot be mapped directly to YANG’s must statement, which include expressions containing special keywords or symbols such as all, any, unique, $, __, and wildcard characters, are published using junos:must.

    The new junos-extension module contains definitions for Junos OS YANG extensions including the must and must-message keywords. The junos-extension module is bound to the namespace URI http://yang.juniper.net/yang/1.1/je and uses the prefix junos. You can download Juniper Networks YANG modules from the website, or you can generate the modules by using the show system schema operational mode command on the local device.

    [See Using Juniper Networks YANG Modules.]

MPLS

  • New command to display the MPLS label availability in RPD (M Series, MX Series, and T Series)—Starting with Junos OS Release 15.1R1, a new show command, show mpls label usage, is introduced to display the available label space resource in RPD and also the applications that use the label space in RPD. Using this command, the administrator can monitor the available labels in each label space and the applications that are using the labels.

    [See show mpls label usage.]

  • Pro-active loss and delay measurement (MX Series routers with MPCs and MICs only)—Starting in Junos OS Release 15.1R1, this feature enables you to monitor and measure packet loss, packet delay, or both for associated bidirectional MPLS ultimate-hop popping point-to-point label-switched paths (LSPs), using the show performance-monitoring mpls lsp command. This command provides a summary of the performance metrics for packet loss, two-way channel delay and round trip delay, as well as related metric like delay variation and channel throughput.

    You can configure pro-active loss and delay measurement using the performance-monitoring configuration statement. This functionality provides real-time visibility into network performance, thereby facilitating network performance planning, troubleshooting, and evaluation.

    [See Configuring Pro-Active Loss and Delay Measurements.]

  • Configuring Layer 3 VPN egress protection with PLR as protector (M Series, MX Series, and T Series)—Starting in Junos OS Release 15.1R1, this feature addresses a special scenario of egress node protection, where the point of local repair (PLR) and the protector are co-located as one router. In this case, there is no need to have a bypass LSP reroute traffic during local repair.

    In the co-located protector model, the PLR or the protector is directly connected to the CE device through a backup AC, while in the Centralized protector model, the PLR or the protector has an MPLS tunnel to the backup PE device.

    [See Example: Configuring Layer 3 VPN Egress Protection with PLR as Protector.]

  • Support for NSR, IGP-FA, and static route on container LSPs (M Series, MX Series, and T Series)—Starting with Junos OS Release 15.1R1, container label-switched paths (LSPs) provide support for nonstop active routing (NSR), IGP forwarding adjacency, and static routes to address the requirements of a wider business case.

    NSR synchronizes the LSP state between redundant Routing Engines, thereby reducing the time to rebuild the container LSP upon a Routing Engine switchover and avoiding traffic loss. Because IGP forwarding adjacency and static routes are widely deployed for RSVP point-to-point LSPs, and container LSPs are dynamically created point-to-point LSPs, these features are also required to fully deploy container LSPs in the field.

    [See Dynamic Bandwidth Management Using Container LSP Overview.]

  • Support for DDoS on pseudowire subscriber logical interface (M Series and MX Series)—Starting with Junos OS Release 15.1R3, distributed denial-of-service (DDoS) protection is supported on the services side of an MPLS pseudowire subscriber logical interface. DDoS protection identifies and suppresses malicious control packets while enabling legitimate control traffic to be processed. This protection enables the device to continue functioning, even when attacked from multiple sources. Junos OS DDoS protection provides a single point of protection management that enables network administrators to customize a profile appropriate for the control traffic on their networks.

  • Support for Policer and Filter on pseudowire subscriber logical interface (M Series and MX Series)—Starting with Junos OS Release 15.1R3, Policer and Filter are supported on the services side of an MPLS pseudowire subscriber logical interface. Policer defines a set of traffic rate limits and sets consequences for traffic that does not conform to the configured limits. Firewall filters restrict traffic destined for the Routing Engine based on its source, protocol, and application. Also, firewall filters limit the traffic rate of packets destined for the Routing Engine to protect against flood or denial-of-service (DoS) attacks.

  • Support for accurate transmit logical interface statistics on pseudowire subscriber logical interface (M Series and MX Series)—Starting with Junos OS Release 15.1R3, accurate transmit logical interface statistics are supported on the services side of an MPLS pseudowire subscriber logical interface. These statistics report actual transmit statistics instead of the load statistics given by the router for the pseudowire subscriber service logical interfaces.

  • Support for Ethernet circuit cross-connect (CCC) encapsulation on pseudowire subscriber logical interface (M Series and MX Series)—Starting with Junos OS Release 15.1R3, CCC encapsulation is supported on the transport side of an MPLS pseudowire subscriber logical interface. This feature helps in migrating or deploying seamless MPLS architectures in access networks. Customers deploying either business edge or broadband residential edge access networks use this feature to configure interfaces over the virtual Ethernet interface similar to what is already available on physical Ethernet interfaces.

    You can define only one transport logical interface per pseudowire subscriber logical interface. Although the unit number can be any valid value, we recommend that unit 0 represent the transport logical interface. Two types of pseudowire signaling are allowed, Layer 2 circuit and Layer 2 VPN.

  • MPLS over dynamic GRE tunnel scaling of 32K (MX Series)—Starting in Junos OS Release 15.1R3, MX Series routers support dynamic GRE tunnels scaling to 32K. Additionally, the previous IFL dependency is removed so rpd now creates a new tunnel composite nexthop rather than creating an IFL. The tunnel composite nexthop has encapsulation data of the dynamic tunnel with a VPN label. To enable nexthop base dynamic tunnel mode, you set the next-hop-based-tunnel statement from the [routing-options] hierarchy level. By configuring this new statement, you can switch an IFL-based tunnel to a nexthop-based dynamic tunnel. You can view output of this new statement with the following show commands: show dynamic-tunnels database, show route table inet.3 extensive, show route table inet.3, show route table bgp.l3vpn.0, and show route table bgp.l3vpn.0 extensive.

    Note

    Dynamic tunnels are not supported on logical systems.

Multicast

  • Latency fairness optimized multicast (MX Series)—Starting with Junos OS Release 15.1R1, 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, point-to-multipoint connections, and on integrated routing and bridging (IRB) interfaces.

    [See multicast-replication.]

  • IGMP snooping on pseudowires (MX Series)—Starting in Junos OS Release 15.1R1, you can prevent multicast traffic from traversing a pseudowire (to egress PE routers) unless there are IGMP receivers for the traffic.

    The default IGMP snooping implementation for a VPLS instance adds each pseudowire interface to its oif list. This includes traffic sent from the ingress PE router to the egress PE router regardless of interest. The snoop-pseudowires option prevents multicast traffic from traversing the pseudowire (to the egress PE routers) unless there are IGMP receivers for the traffic. In other words, multicast traffic is forwarded only to VPLS core interfaces that are either router interfaces or IGMP receivers. In addition to the benefit of sending traffic to interested PE routers only, snoop-pseudowires optimizes a common path between PE-P routers wherever possible. Thus, if two PE routers connect through the same P router, only one copy of the packet is sent because the packet is replicated on only those P routers for which the path is divergent.

    [See snoop-pseudowires.]

  • Sender-based RPF and hot-root standby for ingress replication provider tunnels (MX Series routers with MPCs running in "enhanced-ip" mode)—Starting in Junos OS Release 15.1R1, support has been added for sender-based RPF and hot-root standby to ingress replication for selective (not inclusive) provider tunnels. This feature extends the sender-based RPF functionality for RSVP-P2MP added in Junos OS Release 14.2, which, in conjunction with hot-root standby, provides support for live-live NGEN MVPN traffic. The configuration of the router, whether for RSVP-P2MP or ingress replication provider tunnels, determines the form of sender-based RPF and hot-root standby that are implemented when their respective CLI configurations are enabled.

    Ingress replication works by introducing a unique VPN label to advertise each upstream PE router per VRF. This allows the ingress replication to distinguish the sending PE router and the VRF. When ingress replication is used as the selective provider tunnel, ingress replication tunnels must also be configured for all interested egress PE routers or border routers. When sender-based RPF is disabled, it causes all type 4 routes to be re-advertised with the VT/LSI label. Ingress replication is not intended to work in S-PMSI only configurations.

    [See hot-root-standby (MBGP MVPN) and sender-based-rpf (MBGP MVPN).]

  • Fast-failover according to flow rate (MX Series routers with MPCs)—Starting in Junos OS Release 15.1R1, for routers operating in Enhanced IP Network Services mode, you can configure a threshold that triggers fast failover in NG MVPNs with hot-root standby on the basis of aggregate flow rate. For example, fast failover (as defined in Draft Morin L3VPN Fast Failover 05) is triggered if the flow rate of monitored multicast traffic from the provider tunnel drops below the set threshold.

    [See sender-based-rpf (MBGP MVPN).]

Network Management and Monitoring

  • Configuring SNMP to match jnxNatObjects values for MS-DPC and MS-MIC (MX Series)—In Junos OS Release 13.3R7, 14.1R6, 14.2R4, and 15.1R2, you can configure the snmp-value-match-msmic statement at the [edit services service-set service-set-name nat-options] hierarchy level.

    In networks where both MS-DPC and MS-MIC are deployed, you can configure this statement to ensure that the values for MS-MIC-specific objects in the jnxNatObjects MIB table match the values for MS-DPC objects. By default, this feature is disabled. You can use the deactivate services service-set service-set-name nat-options snmp-value-match-msmic configuration mode command to disable this feature.

  • Tracing tacplus processing (M Series, MX Series, and T Series)—Starting in Release 15.1R1, Junos OS allows users to trace tacplus processing. To trace tacplus processing, include the tacplus statement at the [edit system accounting traceoptions flag] hierarchy level.

    [See traceoptions (System Accounting).]

  • Support for multi-lane digital optical monitoring (DOM) MIB (MX960, MX480, and MX240)—Starting with Junos OS Release 15.1R1, Junos OS supports the following SNMP tables and objects in the jnxDomMib MIB that gives you information about multi-lane digital optical modules in 10-gigabit small form-factor pluggable transceiver (XFP), small formfactor pluggable transceiver (SFP), small form-factor pluggable plus transceiver (SFP+), quad small form-factor pluggable transceiver (QSFP), and C form-factor pluggable transceiver (CFP):

    • jnxDomModuleLaneTable

    • jnxDomCurrentModuleVoltage in jnxDomCurrentTable table

    • jnxDomCurrentModuleVoltageHighAlarmThreshold in jnxDomCurrentTable table

    • jnxDomCurrentModuleVoltageLowAlarmThreshold in jnxDomCurrentTable table

    • jnxDomCurrentModuleVoltageHighWarningThreshold in jnxDomCurrentTable table

    • jnxDomCurrentModuleVoltageLowWarningThreshold in jnxDomCurrentTable table

    • jnxDomCurrentModuleLaneCount in jnxDomCurrentTable

    Junos OS also supports the jnxDomLaneNotifications traps.

    [See Enterprise-Specific SNMP Traps Supported by Junos OS, and Digital Optical Monitoring MIB.]

  • SNMP support for Service OAM (SOAM) performance monitoring functions (MX Series)—Starting in Junos OS Release 15.1R1, SNMP supports Service OAM (SOAM) performance monitoring functions that are defined in Technical Specification MEF 17, the Service OAM performance monitoring requirements specified in SOAM-PM, and the Service OAM management objects specified in Technical Specification MEF 7.1.

    A new enterprise-specific MIB, SOAM PM MIB, that defines the management objects for Ethernet services operations, administration, and maintenance for performance monitoring, has been added and SNMP support is available for the MIB objects defined in Technical Specification MEF 36.

  • SNMP support for fabric and WAN queue depth monitoring (MX Series)—Starting in Junos OS Release 15.1R1, Junos OS supports monitoring of fabric and WAN queues at the Packet Forwarding Engine level. You can configure fabric and WAN queue depth monitoring by enabling the queue-threshold statement at the [edit chassis fpc slot-number traffic-manager] hierarchy level. When the fabric-queue and wan-queue statements are configured, an SNMP trap is generated when the fabric queue or WAN queue depth exceeds the configured threshold value.

    The SNMP traps jnxCosFabricQueueOverflow, jnxCosFabricQueueOverflowCleared, jnxCosWanQueueOverflow, and jnxCosWanQueueOverflowCleared have been added to the Juniper Networks enterprise-specific Class of Service (COS) MIB to support fabric and WAN queue monitoring.

  • SNMP support for monitoring fabric power utilization (MX Series)—Starting in Junos OS Release 15.1R1, Junos OS supports monitoring of fabric power utilization. An SNMP trap is generated whenever the fabric power consumption exceeds the configured threshold value. The SNMP trap jnxFabricHighPower has been added to the jnxFabricChassisTraps group to indicate excessive power consumption. The SNMP trap jnxFabricHighPowerCleared added to the jnxFabricChassisOKTraps group sends notification when the condition of consuming excessive power is cleared.

  • Support for the interface-set SNMP index (MX Series)—Starting with Junos OS Release 15.1R2, Junos OS supports the interface-set SNMP index that provides information about interface-set queue statistics. The following interface-set SNMP index MIBs are introduced in the Juniper Networks enterprise-specific Class-of-Service MIB:

    • jnxCosIfTable in jnxCos MIB

    • jnxCosIfsetQstatTable in jnxCos MIB

    [See jnxCosIfTable and jnxCosIfsetQstatTable.]

Routing Policy and Firewall Filters

  • Support for consistent load balancing for ECMP groups (MX Series routers with MPCs)—Starting in Junos OS Release 15.1R1, on MX Series routers with modular port concentrators (MPCs) only, you can prevent the reordering of flows to active paths in an ECMP group when one or more paths fail. Only flows that are inactive are redirected. This feature applies only to Layer 3 adjacencies learned through external BGP connections. It overrides the default behavior of disrupting all existing, including active, TCP connections when an active path fails. Include the consistent-hash statement at the [edit policy-options policy-statement policy-statement-name then load-balance] hierarchy level. You must also configure a global per-packet load-balancing policy.

    [See Actions in Routing Policy Terms.]

  • New fast-lookup-filter statement (MX240, MX480, MX960, MX2010, and MX2020 routers with MPC5E, MPC5EQ, and MPC6E MPCs and compatible MICs)—Starting in Junos OS Release 15.1R1, the fast-lookup-filter option is available at the [edit firewall family (inet | inet6) filter filter-name] hierarchy level. This allows for hardware assist from compatible MPCs in the firewall filter lookup. There are 4096 hardware filters available for this purpose, each of which can support up to 255 terms. Within the firewall, filters and their terms, ranges, prefix lists, and the except keyword are all supported. Only the inet and inet6 protocol families are supported.

    [See fast-lookup-filter.]

  • New forwarding-class-accounting statement (MX Series)—Starting in Junos OS Release 15.1R1, you can enable new forwarding class accounting statistics at the [edit interfaces interface-name] and [edit interfaces interface-name unit interface-unit-number] hierarchy levels. These statistics replace the need to use firewall filters for gathering accounting statistics. Statistics can be gathered in ingress, egress, or both directions. Statistics are displayed for IPv4, IPv6, MPLS, Layer 2, and other families.

    [See forwarding-class-accounting.]

  • Support for interfaces that use the same filter list to use a common template (MX5, MX10, MX40, and MX80 routers, and routers that use MX Series MPC line cards)—Starting in Junos OS Release 15.1R3, on MX5, MX10, MX40, MX80, and MX Series routers with modular port concentrators (MPCs) only, you can configure all interfaces that use the same filter list to use a common template. This feature can be used to save microkernel memory and DMEM memory. Include the filter-list-template statement at the [edit firewall family (inet | inet6) filter filter-name] hierarchy level.

Routing Protocols

  • BGP Prefix Independent Convergence for inet (MX Series routers with MPCs)—Beginning with Junos OS Release 15.1R1, BGP Prefix Independent Convergence (PIC), which was initially supported for Layer 3 VPN routers, is extended to BGP with multiple routes in the global tables such as inet and inet6 unicast, and inet and inet6 labeled unicast. When the BGP PIC feature is enabled on a router, BGP installs to the Packet Forwarding Engine the second best path in addition to the calculated best path to a destination. When an IGP loses reachability to a prefix, the router uses this backup path to minimize traffic loss until the global convergence through the BGP is resolved, thereby drastically reducing the outage duration.

    [See Use Case for BGP PIC for Inet.]

  • Entropy label support for BGP-LU (MX Series routers with MPCs, and T Series routers with HC-FPC)—Beginning with Junos OS Release 15.1R1, entropy labels for BGP labeled unicast LSPs are supported. You can configure entropy labels for BGP labeled unicasts to achieve end-to-end load balancing. BGP labeled unicasts generally concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems. RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. However, there are no entropy labels at the stitching points. Therefore, in the absence of entropy labels, the load-balancing decision at the stitching points was based on deep packet inspection. Junos OS now allows the insertion of entropy labels at the BGP labeled unicast LSP ingress.

    [See Entropy Label for BGP Labeled Unicast LSP Overview.]

  • Multi-instance support for RSVP-TE (M Series, MX Series, and T Series)—Beginning with Junos OS Release 15.1R1, multi-instance support is extended to the existing MPLS RSVP-Traffic Engineering (TE) functionality. This support is available only for a virtual router instance type. A router can create and participate in multiple independent TE topology partitions, which allows each partitioned TE domain to scale independently.

    [See RSVP LSP Tunnels Overview]

    Multi-instance support is also extended for LDP over RSVP tunneling for a virtual router routing instance. This supports splitting of a single routing and MPLS domain into multiple domains so that each domain can be scaled independently. BGP labeled unicast can be used to stitch these domains for service FECs. Each domain uses intra-domain LDP over RSVP LSP for MPLS forwarding.

    [See Tunneling LDP LSPs in RSVP LSPs Overview.]

    Starting with Junos OS Release 15.1R1, you can configure the interfaces for routing instances at the [edit routing-instances instance-name protocols mpls], [edit routing-instances instance-name protocols rsvp], and [edit routing-instance instance-name protocols ldp] hierarchy levels. You cannot configure an interface that already exists in a routing instance under [edit protocols mpls], [edit protocols rsvp], and [edit protocols ldp} hierarchy levels.

  • Support for long-lived BGP graceful restart (M Series, MX Series, and T Series)— Starting in Release 15.1R1, Junos OS supports the mechanism to preserve BGP routing details from a failed BGP peer for a longer period than the duration for which such routing information is maintained using the BGP graceful restart functionality. Long-lived graceful restart (LLGR) receiver or helper mode for BGP is enabled by default, unless graceful restart receiver or helper mode is globally disabled at the [edit routing-options] hierarchy level.

    To enable the BGP long-lived graceful restart capability, include the long-lived receiver enable statement at the [edit protocols bgp graceful-restart], [edit protocols bgp group group-name graceful-restart], and [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hierarchy levels.

  • Selection of backup LFA for OSPF routing protocol (M Series, MX Series, and T Series)—Starting with Junos OS Release 15.1R1, the default loop-free alternative (LFA) selection algorithm or criteria can be overridden with an LFA policy. These policies are configured per destination per primary next-hop interface or per destination. These backup policies enforce LFA selection based on admin-group, srlg, node, bandwidth, protection-type, and metric attributes of the backup path. During backup shortest-path-first (SPF) computation, each attribute (both node and link) of the backup path, stored per backup next hop, is accumulated by IGP. For the routes created internally by IGP, the attribute set of every backup path is evaluated against the policy configured per destination per prefix primary next-hop interface. The first or the best backup path is selected and installed as the backup next hop in the routing table.

    [See Example-configuring-backup-selection-policy-for-ospf-protocol.]

  • Remote LFA support for LDP in OSPF (MX Series)—Beginning with Junos OS Release 15.1R1, you can configure a remote loop-free alternate (LFA) to extend the backup provided by the LFA in an OSPF network. This feature is useful especially for Layer 1 metro-rings where the remote LFA is not directly connected to the PLR. The existing LDP implemented for the MPLS tunnel setup can be reused for the protection of OSPF networks and subsequent LDP destinations thereby eliminating the need for RSVP-TE backup tunnels for backup coverage.

    [See Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks.]

  • Configuring per-interface NDP cache protection (MX Series)—Starting in Junos OS Release 15.1R1, you can configure IPv6 neighbor discovery protocol (NDP) cache protection on a per-interface basis. NDP performs address resolution and maintains the neighbor cache, and can be susceptible to denial-of-service (DoS) attacks that overwhelm the device’s control plane with unassigned address resolution requests, resulting in a cache overflow. One strategy for mitigating this type of DoS attack is to enforce neighbor discovery queue limits, restricting the overall number of IPV6 neighbors and new unresolved next-hop addresses that can be added to the cache.

    The device has default cache limits that can be changed system-wide, or you can use this feature to override default or system-wide limits on a per-interface basis.

    [See Example: Configuring NDP Cache Protection to Prevent Denial-of-Service Attacks.]

  • Configuring per-prefix LFA and node to link protection fallback for OSPF (M Series, MX Series, and T Series) —Starting in Junos OS Release 15.1R1, you can configure the following features for OSPF:

    • Per-prefix loop-free alternates (LFAs)

    • Fallback to link protecting LFA from node protecting LFA

    In certain topologies and usage scenarios, it might be possible that multiple destinations are originating the same prefix and there is no viable LFA to the best prefix originator, while a non-best prefix originator has one.

    In certain topologies it might be desirable to have local repair protection to node failures in the primary next hop, which might not be available. In that case, to ensure that some level of local repair capabilities exist, a fallback mechanism is required. Since the link protection is less stringent than node protection, it might be possible that link protection exists and provides the same to those destinations (and hence the prefixes originated by the destinations).

    [See Configuring Per-Prefix LFA for OSPF and Configuring Node to Link Protection Fallback for OSPF.]

  • OSPFv3-TTL propagation policy for TE-Shortcuts and FA-LSPs in-line with other modules in the system (MX Series)—Starting in Junos OS Release 15.1R2, the OSPFv3-TTL propagation policy will be dictated by MPLS-TTL propagation policy which, by default, allows propagation of TTL.

    This change makes behavior of OSPFV3 in-line with the default behavior of rest of the system, allowing you to disable TTL propagation for the above mentioned LSPs and for traffic-engineering-shortcuts (TE-Shortcuts) and forwarding adjacency LSPs (FA-LSPs) using OSPFv3 as IGP, by configuring the no-propagate-ttl statement at the [edit protocols mpls] hierarchy.

  • OSPF domain-id interoperability (MX Series)— Starting in Junos OS Release 15.1R2, to enable interoperability with routers from other vendors, you can set the AS number for domain-id attributes to 0 at the following hierarchical levels:

    • or

    Caution

    Do not downgrade Junos OS after configuring the AS number for domain-id attributes to 0. Set the AS number to a nonzero value and commit the configuration before downgrading Junos OS.

Services Applications

  • Support for inline MPLS Junos Traffic Vision with IPFIX and v9 (MX Series)—Starting in Junos OS Release 15.1R1, support of the MX Series routers for the inline Junos Traffic Vision feature is extended to the MPLS family consisting of the IP Flow Information Export (IPFIX) protocol and flow monitoring version 9 (v9). Currently, the inline Junos Traffic Vision feature is supported only on the MS-MIC and MS-MPC consisting of the IPv4, IPv6, and virtual private LAN service (VPLS) protocols.

  • Support for NAT port block allocation (MX Series routers with MS-MPCs or MS-MICs)—Starting in Junos OS Release 15.1R1, you can configure port block allocation for NAT with port translation (NAPT) on MX Series routers with MS-MPCs or MS-MICs. The existing CLI and configuration procedures used for other interface cards remain unchanged. Deterministic port block allocation is not supported.

    [See secured-port-block-allocation and Configuring Address Pools for Network Address Port Translation (NAPT) Overview.]

  • Support for inline 6rd and 6to4 (MX Series routers with MPCs )—Starting in Junos OS Release 15.1R1, you can configure inline 6rd or 6to4 on an MPC. You can use the inline capability to avoid the cost of using MS-DPCs for required tunneling, encapsulation, and decapsulation processes. Anycast is supported for 6to4 using next-hop service interfaces. Hairpinning is also supported for traffic between 6rd domains. The CLI configuration statements for inline and service PIC-based 6rd remain unchanged. To implement the inline functionality, configure service interfaces on the MPC as inline services interfaces (si-) rather than as multiservices (ms-) interfaces. Two new operational mode commands have been added: show services inline softwire statistics and clear services inline softwire statistics.

    [See Tunneling Services for IPv4-to-IPv6 Transition Overview, show services inline softwire statistics, and clear services inline softwire statistics.]

  • Support for interim logging for NAT port block allocation (MX Series routers with MS-MPCs or MS-MICs)—Starting in Junos OS Release 15.1R1, you can can configure interim logging for NAT with port translation on MX Series routers with MS-MPCs or MS-MICs. Default logging sends a single log entry for ports allocated to a subscriber. These syslog entries can be lost for long running flows. Interim logging triggers re-sending of logs at configured time intervals for active blocks that have traffic on at least one of the ports of the block, ensuring that there is a recent syslog entry for active blocks. You can specify interim logging by including the pba-interim-logging-interval statement at the [edit interfaces interface-name services-options] hierarchy level.

    [See pba-interim-logging-interval and Configuring NAT Session Logs.]

  • Support for NAT mapping controls and EIF session limits (MX Series routers with MS-MICs)—Starting in Junos OS Release 15.1R1, you can control network address translation (NAT) mapping refresh behavior and establish endpoint-independent filtering session limits for flows on MS-MICs. The following features, previously introduced on MS-DPCs, are available:

    • Clear NAT mappings using the clear services nat mappings command.

    • Configure criteria for refreshing NAT mappings for inbound flows and outbound flows. To configure refresh criteria, include the mapping-refresh statement at the [edit services nat rule rule-name term term-name then translated secure-nat-mapping] hierarchy level.

    • Configure a limit for inbound sessions for an EIF mapping. To configure this limit, include the eif-flow-limit statement at the [edit services nat rule rule-name term term-name then translated secure-nat-mapping] hierarchy level.

    • Configure a limit for the number of dropped flows (ingress, egress, or both) for a specified service set. To configure this limit, include the max-drop-flows statement at the [edit services service-set service-set-name] hierarchy level.

    [See clear-services-nat-mappings, clear-services-nat-flows mapping-refresh, eif-flow-limit, and max-drop-flows.]

  • Support for per-service throughput for NAT and inline flow monitoring services (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 15.1R1, you can configure the capability to transmit the throughput details per service for Junos Address Aware (carrier-grade NAT) and Junos Traffic Vision (previously known as J-Flow) in the last time interval to an external log collector. The default time interval at which the throughput data is sent is 300 seconds, which you can configure to suit your network needs. Multiple instances of the same service running on different PICs within a router are supported. This functionality is supported on MX Series routers with MS-MCPs and MS-MICs, and also in the MX Series Virtual Chassis configuration.

  • Support for generation of SNMP traps and alarms for inline video monitoring (MX Series)—Starting in Junos OS Release 15.1R1, SNMP support is introduced for the media delivery index (MDI) metrics of inline video monitoring. Inline video monitoring is available on MX Series routers using only MPCE1, MPCE2, and MPC-16XGE. Until Junos OS Release 14.2, inline MDI generated only syslogs when the computed MDI metric value was not within the configured range. SNMP support is now added to enable SNMP traps to be triggered when the computed delay factor, media rate variation (MRV), or media loss rate (MLR) values are not within the configured range. You can retrieve the MDI statistics, flow levels, error details, and MDI record-level information using SNMP Get and Get Next requests. The SNMP traps and alarms that are generated when the MDI metrics exceed the configured ranges can be cleared as necessary. Also, you can control the flooding of SNMP traps on the system.

  • Support for Layer 2 services over GRE tunnel interfaces (MX Series routers with MPCs)—Starting in Junos OS Release 15.1R1, you can configure Layer 2 Ethernet services over GRE interfaces (gr-fpc/pic/port to use GRE encapsulation). To enable Layer 2 Ethernet packets to be terminated on GRE tunnels, you must configure the bridge domain protocol family on the gr- interfaces and associate the gr- interfaces with the bridge domain. You must configure the GRE interfaces as core-facing interfaces, and they must be access or trunk interfaces. To configure the bridge domain family on gr- interfaces, include the family bridge statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number] hierarchy level.

  • Support for stateless source IPv6 prefix translation (MX Series routers with MPCs)—Starting in Junos OS Release 15.1R1, you can configure stateless translation of source address prefixes in IPv6 networks. This capability is supported on MX Series routers with MPCs where inline NAT is supported. To configure stateless network prefix translation for IPv6 packets (NPTv6), include the translation-type nptv6 statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level. The NPTv6 translator translates the source address prefix in such a way that the transport layer checksum of the packet does not need to be recomputed.

  • Support for logging flow monitoring records with version 9 and IPFIX templates for NAT events (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 15.1R1, you can configure MX Series routers with MS-MPCs and MS-MICs to log NAT events by using Junos Traffic Vision (previously known as J-Flow) version 9 or IPFIX (version 10) template format. NAT event logger generates messages in flow monitoring format for various NAT events, such as the creation of a NAT entry, deletion of a NAT entry, and for invalid NAT processing. These events also support NAT64 translations (translation of IPv6 addresses to IPv4 addresses), binding information base (BIB) events, and more detailed error generation. The generated records or logs for NAT events in flow template format are sent to the specified host or external device that functions as the NetFlow collector.

  • Support for unified ISSU on inline LSQ interfaces (MX Series)—Starting in Junos OS Release 15.1R1, unified in-service software upgrade (ISSU) is supported on inline link services intelligent queuing (IQ) (lsq-) interfaces on MX Series routers. Unified ISSU enables an upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. The inline LSQ logical interface (lsq-slot/pic/0) is a virtual service logical interface that resides on the Packet Forwarding Engine to provide Layer 2 bundling services that do not need a service PIC.

  • Inline TWAMP requester support (MX Series)—Starting in Junos OS Release 15.1R1, MX Series routers support the inline Two-Way Active Measurement Protocol (TWAMP) control-client and session-sender for transmission of TWAMP probes using IPv4 between the sender (control-client) and the receiver (session-sender or server). The control-client and session-sender reside on the same router. The TWAMP control-client can also work with a third-party server implementation.

  • Ethernet over generic routing encapsulation (GRE) and GRE key support for label blocks (MX Series)—Starting in Junos OS Release 15.1R1, MX Series routers support the following in compliance with RFC 2890:

    • Adding a bridge family on general tunneling protocol

    • Switching functionality supporting connections to the traditional Layer 2 network and VPLS network

    • Routing functionality supporting integrated routing and bridging (IRB)

    • Configuring the GRE key and performing the hash load balance operation both at the gre tunnel initiated and transit routers hierarchies

    • Providing statistics for the GRE-L2 tunnel

  • Support for IRB in a P-VLAN bridge domain (MX Series)—Starting in Junos OS Release 15.1R1, MX Series routers support IRB in a private VLAN (P-VLAN) bridge domain. All IP features such as IP multicast, IPv4, IPv6, and VRRP that work for IRB in a normal bridge domain also work for IRB in a P-VLAN bridge domain.

  • Enhancements to the RFC 2544-based benchmarking tests (MX104)—Starting in Junos OS Release 15.1R1, MX104 routers support RFC 2544-based benchmarking tests for Ethernet transparent LAN (E-LAN) services configured using LDP-based VPLS and BGP-based VPLS. The RFC 2544 tests are performed to measure and demonstrate the service-level agreement (SLA) parameters before the E-LAN service is activated. The tests measure throughput, latency, frame-loss rate, and back-to-back frames. RFC 2544 performance measurement testing for Layer 2 E-LAN services on MX104 routers supports UNI-to-UNI unicast traffic only. You can enable reflection at the VPLS user-to-network interface (UNI). The following features are also supported:

    • RFC 2544 signature check–Verifies the signature pattern in the RFC 2544 packets, by default.

    • MAC swap for pseudowire egress reflection–Swaps the MAC addresses for pseudowire reflection.

    • Ether type filter for both pseudowire and Layer 2 reflection–Specifies the ether type used for reflection.

  • Support for PCP version 2 (MX Series)—Starting in Release 15.1R1, Junos OS supports Port Control Protocol (PCP) version 2, defined by IETF RFC 6887. PCP version 2 uses the client once for authentication. Junos OS is able to decode and process version 2 and version 1 messages. There are no CLI changes for PCP version 2 support.

    [See Port Control Protocol Overview.]

  • Support for inline MLPPP interface bundles on Channelized E1/T1 Circuit Emulation MICs (MX80, MX104, MX240, MX480, and MX960)—Starting in Junos OS Release 15.1R1, you can configure inline MLPPP interfaces on MX80, MX104, MX240, MX480, and MX960 routers with Channelized E1/T1 Circuit Emulation MICs. Inline Multilink PPP (MLPPP), Multilink Frame Relay (FRF.16), and Multilink Frame Relay End-to-End (FRF.15) for time-division multiplexing (TDM) WAN interfaces provide bundling services through the Packet Forwarding Engine without requiring a PIC or Dense Port Concentrator (DPC). The inline LSQ logical interface (lsq-slot/pic/0) is a virtual service logical interface that resides on the Packet Forwarding Engine to provide Layer 2 bundling services that do not need a service PIC. A maximum of up to eight inline MLPPP interface bundles are supported on Channelized E1/T1 Circuit Emulation MICs, similar to the support for inline MLPPP bundles on other MICs with which they are compatible.

  • Data plane inline support for 6rd and 6to4 tunnels connecting IPv6 clients to IPv4 networks (MX Series with MPC5E and MPC6E)—Starting with Junos OS Release 15.1R3, Junos OS supports inline 6rd and 6to4 on MPC5E and MPC6E line cards. In releases earlier than Junos OS Release 15.1R3, inline 6rd and 6to4 was supported on MPC3E line cards only.

    [See Configuring Inline 6rd.]

  • Support for inline LSQ logical interface—Starting in Junos OS Release 15.1R3, MPC2E-3D-NG and MPC3E-3D-NG support inline LSQ logical interface when flexible queuing is enabled. The inline LSQ logical interface (referred to as lsq-) is a virtual service logical interface that resides on the Packet Forwarding Engine to provide Layer 2 bundling services that do not need a service PIC.

  • Support for H.323 NAT on MS-MPC and MS-MIC (MX Series routers)—Starting in Junos OS Release 15.1R5, the H.323 ALG is supported in NAPT-44 rules and IPv4 stateful-firewall rules on the MX Series. H.323 is a legacy VoIP protocol.

    To configure H.323 in a NAPT-44 rule, include the application-sets junos-h323-suite statement at the [edit services nat rule rule-name term term-name from] hierarchy level. To configure H.323 in a stateful-firewall rule, include the application-sets junos-h323-suite statement at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.

    To show H.323 ALG statistics, issue the show services alg statistics application-protocol h323 command.

  • Class-of-service (CoS) marking and reclassification for the MS-MICs and MS-MPCs—Starting with Junos OS Release 15.1R5, the MS-MIC and MS-MPC support CoS configuration, which enables you to configure Differentiated Services code point (DSCP) marking and forwarding-class assignment for packets transiting the MS-MIC or MS-MPC. You can configure the CoS service alongside the stateful firewall and NAT services, using a similar rule structure.

    [See Configuring CoS Rules.]

  • Support for IKE and IPsec on NAPT-44 and NAT64 (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 15.1R5, you can enable the passing of IKE and IPsec packets through NAPT-44 and NAT64 filters between IPsec peers that are not NAT-T compliant by using the IKE-ESP-TUNNEL-MODE-NAT-ALG on MS-MPCs and MS-MICs.

    Use the following hierarchy to enable the IKE-ESP-TUNNEL-MODE-NAT-ALG:

  • Support for AMS warm standby on MS-MPC and MS-MIC (MX Series routers)—Starting in Junos OS Release 15.1R5, one service interface can be the backup interface for multiple service interfaces. This feature is called AMS warm standby. To make a service interface the backup for multiple service interfaces, you configure an AMS interface for each service interface you want to protect. Each of these AMS interfaces has two member interfaces—a primary member interface, which is the service interface you want to protect, and the secondary member interface, which is the backup service interface. You can use the same secondary member interface in multiple AMS interfaces.

    To configure a warm-standby AMS interface, include the primary mams-a/b/0 statement and the secondary mams-a/b/0 statement at the [edit interfaces amsn redundancy-options] hierarchy level.

    If you use redundancy-options in an AMS interface, you cannot use load-balancing-options in the same AMS interface.

    You cannot use the same member interface in both an AMS interface that includes load-balancing-options and an AMS interface that includes redundancy-options.

    To show the state of an AMS interface configured with warm standby, issue the show interfaces redundancy command.

    To switch from the primary interface to the secondary interface, issue the request interface switchover amsn command.

    To revert to the primary interface from the secondary interface, issue the request interface revert amsn command.

  • Note

    Support for IPv6 on RPM probes is not supported in Junos OS Release 15.1R1. However, documentation for this feature is included in the Junos OS 15.1R1 documentation set.

Software-Defined Networking

  • OpenFlow support (MX2010 and MX2020)—Starting with Junos OS Release 15.1R2, the MX2010 and MX2020 routers support OpenFlow v1.0 and v1.3.1. OpenFlow enables you to control traffic in an existing network using a remote controller by adding, deleting, and modifying flows on a switch. You can configure one OpenFlow virtual switch and one active OpenFlow controller at the [edit protocols openflow] hierarchy level on each device running Junos OS that supports OpenFlow. You can also direct traffic from OpenFlow networks over MPLS networks by using logical tunnel interfaces and MPLS LSP tunnel cross-connects.

    [See Understanding Support for OpenFlow on Devices Running Junos OS.]

  • OVSDB support (MX2010 and MX2020)—Starting with Junos OS Release 15.1R2, the Junos OS implementation of the Open vSwitch Database (OVSDB) management protocol provides a means through which VMware NSX controllers and MX2010 and MX2020 routers that support OVSDB can communicate.

    In an NSX multi-hypervisor environment, NSX controllers and MX2010 and MX2020 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.

    [See Understanding the OVSDB Protocol Running on Juniper Networks Devices.]

Software Installation and Upgrade

  • Validate system software add against running configuration on remote host or routing engine—Beginning with Junos OS Release 15.1R2, you can use the validate-on-host hostname and validate-on-routing-engine routing-engine options with the request system software add package-name command to verify a candidate software bundle against the running configuration on the specified remote host or Routing Engine.

  • Validate system software against running configuration on remote host—Beginning with Junos OS Release 15.1R2, 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.

  • Support for FreeBSD 10 kernel for Junos OS (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 15.1R1, on the MX240, MX480, MX960, MX2010, and MX2020 only, FreeBSD 10 is the underlying OS for Junos OS instead of FreeBSD 6.1. This feature includes a simplified package naming system that drops the domestic and world-wide naming convention. Because installation restructures the file system, logs and configurations are lost unless precautions are taken. There are now Junos OS and OAM volumes, which provide the ability to boot from the OAM volume upon failures. Some system commands display different output and a few others are deprecated.

    [See Understanding Junos OS with Upgraded FreeBSD.]

Software Licensing

  • Licensing enhancements (M Series, MX Series and T Series)—Starting with Junos OS Release 15.1R1, licensing enhancements on routers running Junos OS enable you to configure and delete license keys in a Junos OS CLI configuration file. The license keys are validated and installed after a successful commit of the configuration file. If a license key is invalid, the commit fails and issues an error message. You can configure individual license keys or multiple license keys by issuing Junos OS CLI commands or by loading the license key configuration contained in a file. All installed license keys are stored in the /config/license/ directory.

    To install an individual license key in the Junos OS CLI, issue the set system license keys key name command, and then issue the commit command.

    For example:

    To verify that the license key was installed, issue the show system license command.

    For example:

    To install multiple license keys in the Junos OS CLI, issue the set system license keys key name command, and then issue the commit command.

    For example:

    To verify that the license key was installed, issue the show system license command.

    To install an individual license key configuration in a file, issue the cat command:

    For example:

    Load and merge the license configuration file.

    For example:

    Issue the show | compare command to see the configuration, and then issue the commit command.

    For example:

    To verify that the license key was installed, issue the show system license command.

    For example:

    To install multiple license keys in a file, issue the cat command:

    For example:

    Load and merge the license configuration file, and then issue the commit command.

    For example:

    To verify that the license key was installed, issue the show system license command.

    You can also delete or deactivate individual and multiple license keys in the Junos OS CLI by issuing the delete system license keys or deactivate system license keys commands. Do not use the request system license delete command to delete the license keys.

    For example, to issue the delete system license keys command:

Subscriber Management and Services (MX Series)

  • Additional IPsec encryption algorithms added to support IPsec update data path processing (MX Series)—Starting in Junos OS Release 15.1R1, you can configure three new IPsec encryption algorithm options for manual Security Associations at the [edit security ipsec security-association sa-name manual direction encryption] hierarchy level: aes-128-cbc, aes-192-cbc, and aes-256-cbc.

    [See encryption (Junos OS).]

  • Captive portal content delivery (HTTP redirect) supported on MS-MICs, MS-MPCs, and the Routing Engine (MX Series)—Starting in Junos OS Release 15.1R1, you can configure the captive portal content delivery (HTTP redirect) service package for installation using the set chassis operational mode command. You can deploy HTTP redirect functionality with a local server or a remote server. The Routing Engine-based captive portal supports a walled garden as a firewall service filter only.

    [See HTTP Redirect Service Overview.]

  • LNS support for IPv6-only configurations (MX Series)—Starting in Junos OS Release 15.1R1, L2TP LNS supports IPv6-only configurations, in addition to existing IPv4-only and dual-stack configurations. Include the family inet6 statement in the dynamic profile for IPv6-only dynamic LNS sessions. In earlier releases, LNS supports IPv4-only and dual-stack IPv4/IPv6 configurations.

    Note

    Dynamic LNS sessions require you to include the dial-options statement in the dynamic profile, which in turn requires you to include the family inet statement. This means that you must include the address families as follows:

    • IPv4-only LNS sessions: family inet

    • IPv6-only LNS sessions: family inet and family inet6

    • Dual-stack IPv4/IPv6 LNS sessions: family inet and family inet6

    [See Configuring a Dynamic Profile for Dynamic LNS Sessions.]

  • MAC address option for the Calling-Station-ID attribute (MX Series)—Starting in Junos OS Release 15.1R1 , you can specify that the subscriber MAC address is included in the Calling-Station-ID RADIUS attribute (31) that is passed to the RADIUS server. To do so, include the mac-address option when you configure the calling-station-id-format statement at the [edit access profile profile-name radius options] hierarchy level.

    When all format options are configured, they are ordered in the Calling-Station-Id as follows:

    [See Configuring a Calling-Station-ID with Additional Attributes.]

  • Support for overriding L2TP result codes (MX Series)—Starting in Junos OS Release 15.1R1, you can configure the LNS to override result codes 4 and 5 with result code 2 in Call-Disconnect-Notify (CDN) messages. These result codes indicate that the number of L2TP sessions have reached the configured maximum value and the LNS can support no more sessions. When the LAC receives the code, it fails over to another LNS to establish subsequent sessions. Some third-party LACs respond only to result code 2.

    Include the override-result-code session-out-of-resource statement at the [edit access-profile access-profile-name client client-name l2tp] hierarchy level. Issue the show services l2tp detail | extensive command to display whether the override is enabled.

    [See override-result-code (L2TP Profile).]

  • Support for up to 256 L2TP tunnel groups (MX Series)—Starting in Junos OS Release 15.1R1, you can configure and commit up to 256 tunnel groups. In earlier releases, the CLI prevents you from committing the configuration when you create more than 32 groups.

    [See Configuring an L2TP Tunnel Group for LNS Sessions with Inline Services Interfaces.]

  • DHCPv6 relay agent Remote-ID (option 37) based on DHCPv4 relay agent information option 82 (MX Series)—Starting in Junos OS Release 15.1R1, DHCPv6 relay agent supports a Remote-ID option (option 37) that is based on the DHCPv4 relay agent information option (option 82). When you enable this feature in dual-stack environments, the DHCPv6 relay agent checks the DHCPv4 binding for the option 82 Remote-ID suboption (suboption 2) and uses that information as option 37 in the outgoing RELAY-FORW message. In addition, you can specify the action DHCPv6 relay agent takes if the DHCPv4 binding does not include an option 82 suboption 2 value; either forward the Solicit message without option 37 or drop the message.

    [See Inserting DHCPv6 Remote-ID Option (Option 37) In DHCPv6 Packets.]

  • Juniper Networks VSA 26-181 (DHCPv6-Guided-Relay-Server) support (MX Series)—Starting in Junos OS Release 15.1R1, the Junos OS AAA implementation supports Juniper Networks VSA 26-181 (DHCPv6-Guided-Relay-Server). The new support enables RADIUS to use Access-Accept messages to specify the addresses of the DHCPv6 servers to which the DHCPv6 relay agent sends Solicit and subsequent DHCPv6 messages for particular clients. The list of DHCPv6 servers specified by VSA 26-181 takes precedence over the locally configured DHCPv6 server groups for the particular client. You use multiple instances of VSA 26-181 to specify a list of DHCPv6 servers. Creating a list of servers provides load balancing for your DHCPv6 servers, and also enables you to specify explicit servers for a specific client.

    [See Juniper Networks VSAs Supported by the AAA Service Framework.]

  • Asynchronous single hop BFD support for IP liveness detection (MX Series)—Starting in Junos OS Release 15.1R1, Bidirectional Forwarding Detection (BFD) supports Layer 3 liveness detection of IP sessions between the broadband network gateway (BNG) and customer premises equipment (CPE). You can show all BFD sessions for subscribers using the show bfd subscriber session operational mode command.

    [See show bfd subscriber session.]

  • IP session monitoring for DHCP subscribers using the BFD protocol support for active session health checks (MX Series)—Starting in Junos OS Release 15.1R1, you can configure a DHCP local server, or DHCP relay agent, or DHCP relay proxy agent to periodically initiate a live detection request to an allocated subscriber IP address of every bound client that is configured to be monitored by using the BFD protocol as the liveness detection mechanism. If a given subscriber fails to respond to a configured number of liveness detection requests, then that subscriber’s binding is deleted and its resources released.

    [See DHCP Liveness Detection Overview.]

  • IPCP negotiation with optional peer IP address (MX Series)—Starting in Junos OS Release 15.1R1, you can configure the peer-ip-address-optional statement to enable the Internet Protocol Control Protocol (IPCP) negotiation to succeed even though the peer does not include the IP address option in an IPCP configuration request for static and dynamic, and terminated and tunneled, Point-to-Point Protocol over Ethernet (PPPoE) subscribers. By default, this statement is disabled. This feature also supports high availability (HA) and unified in-service software upgrade (ISSU).

    You must assign an IP address by configuring the Framed-IP-Address RADIUS attribute, or the Framed-Pool RADIUS attribute, or by allocating an IP address from the local address pool without a RADIUS-specified pool name, with an optional Framed-Route RADIUS attribute returned from the RADIUS Server.

    [See peer-ip-address-optional.]

  • Support for enhanced subscriber management subscriber logical interfaces or interface sets over MPLS pseudowires for a CoS scheduler hierarchy (MX Series)—Starting in Junos OS Release 15.1R1, you can enable a CoS scheduling hierarchy for enhanced subscriber management subscriber logical interfaces or interface sets over MPLS pseudowire logical interfaces to function as a Layer 2 node in a CoS hierarchical scheduler. A subscriber logical interface is considered to operate at Layer 2 only if you configure three-level hierarchical scheduling on the logical tunnel anchor point on the physical interface (the IFD). An MPLS pseudowire is a virtual device that is stacked above the logical tunnel anchor point. Implicit hierarchy processes the interface stack properly in such a setup. To configure three-level hierarchical scheduling, include the implicit-hierarchy statement at the [edit interfaces “$junos-interface-ifd-name” hierarchical-scheduler] or [edit interfaces lt-device hierarchical-scheduler] hierarchy level.

  • Support for enhanced subscriber management subscriber logical interfaces or interface sets over underlying logical interfaces for a CoS scheduler hierarchy (MX Series)—Starting in Junos OS Release 15.1R1, you can enable a CoS scheduling hierarchy for enhanced subscriber management subscriber logical interfaces or interface sets over underlying logical interfaces. In Junos OS Release 14.2 and earlier, an interface set can be either at Layer 2 or Layer 3 levels of the CoS three-level hierarchical scheduler. You can now enable an enhanced subscriber management subscriber logical interface, such as an underlying logical interface, to function as a Layer 2 node in a CoS hierarchical scheduler. To configure three-level hierarchical scheduling, include the implicit-hierarchy statement at the [edit interfaces “$junos-interface-ifd-name” hierarchical-scheduler] or [edit interfaces lt-device hierarchical-scheduler] hierarchy level.

  • Enhanced subscriber management support for ACI-based PPPoE subscriber session lockout (MX Series)—Starting in Junos OS Release 15.1R1, enhanced subscriber management supports identification and filtering of PPPoE subscriber sessions by either the agent circuit identifier (ACI) value or the unique media access control (MAC) source address. You can use this feature when you configure PPPoE subscriber session lockout on static or dynamic VLAN and static or dynamic VLAN demux underlying interfaces.

    ACI-based or MAC-based PPPoE subscriber session lockout prevents a failed or short-lived PPPoE subscriber session from reconnecting to the router for a default or configurable time period. ACI-based PPPoE subscriber session lockout is useful for configurations such as PPPoE interworking in which MAC source addresses are not unique on the PPPoE underlying interface.

    To configure ACI-based PPPoE subscriber session lockout for enhanced subscriber management, use the same procedure that you use to configure it on a router without enhanced subscriber management enabled.

    [See PPPoE Subscriber Session Lockout Overview.]

  • Subscriber Secure Policy (SSP) interception of Layer 2 datagrams (MX Series)—Starting in Junos OS Release 15.1R1, when DTCP- or RADIUS-initiated SSP intercepts traffic on a logical subscriber interface, including VLAN interfaces, the software intercepts Layer 2 datagrams and sends them to the mediation device. Previously, the software intercepted Layer 3 datagrams on logical subscriber interfaces.

    Interception of subscriber traffic on an L2TP LAC interface is unchanged. The Junos OS software sends the entire HDLC frame to the mediation device.

    Interception of subscriber traffic based on interface family, such as IPv4 or IPv6, is also unchanged. The Junos OS software sends the Layer 3 datagram to the mediation device.

    Interception of traffic based on a subscriber joining a multicast group is also unchanged. Layer 3 multicast traffic is intercepted and sent to the mediation device. However, multicast traffic that passes through a logical subscriber interface is intercepted along with other subscriber traffic, and is sent as a Layer 2 datagram to the mediation device.

    [See Subscriber Secure Policy Overview.]

  • Additional methods to derive values for L2TP connect speeds (MX Series)—Starting in Junos OS Release 15.1R1, several new ways are supported for determining the transmit and receive connect speeds that the LAC sends to the LNS:

    • The Juniper Networks VSAs, Tx-Connect-Speed (26-162) and Rx-Connect-Speed (26-163), can provide the values.

    • The Juniper Networks VSA, Tunnel-Tx-Speed-Method (26-94), can specify a method (source) for the LAC to derive the values.

    • You can configure the LAC to use the actual downstream traffic rate enforced by CoS for the transmit speed. The actual method requires the effective shaping rate to be enabled and does not provide a receive speed, which is determined by the fallback scheme.

    You can also configure the LAC not to send the connect speeds.

    [See Transmission of Tx Connect-Speed and Rx Connect-Speed AVPs from LAC to LNS.]

  • Pseudowire device support for reverse-path forwarding check (MX Series)—Starting in Junos OS Release 15.1R1, unicast reverse-path forwarding checks are supported on pseudowire subscriber logical interface devices (ps0) for both the inet and inet6 address families. Include the rpf-check statement at the [edit interfaces ps0 unit logical-unit-number family family] hierarchy level for either address family.

    [See Configuring a Pseudowire Subscriber Logical Interface Device.]

  • Destination-equal load balancing for L2TP sessions (MX Series)—Starting in Junos OS Release 15.1R1, you can enable the LAC to balance the L2TP session load equally across all tunnels at the highest available preference level by evaluating the number of sessions to the destinations and the number of sessions carried by the tunnels. By default, tunnel selection within a preference level is strictly random. Include the destination-equal-load-balancing statement at the [edit services l2tp] hierarchy level to load-balance the sessions. The weighted-load-balancing statement must be disabled.

    [See LAC Tunnel Selection Overview and Configuring Destination-Equal Load Balancing for LAC Tunnel Sessions.]

  • Support for Extensible Subscriber Services Manager (MX Series)—Starting in Junos OS Release 15.1R1, Junos OS supports Extensible Subscriber Services Manager (ESSM), a background process that enables dynamic provisioning of business services.

  • Loopback address as source address on DHCP relay agent—Starting in Junos OS Release 15.1R1, you can configure the DHCPv4 and DHCPv6 relay agent to use the relay agent loopback address as the source address in DHCP packets. In network configurations where a firewall on the broadband network gateway (BNG) is between the DHCP relay agent and the DHCP server, only the BNG loopback address passes through the BNG firewall. In that case, DHCP unicast packets do not pass through and are discarded. You can use two new configuration statements to override the DHCP source address with the BNG loopback address so DHCP packets do not pass through the firewall.

  • Support for DUID based on link-layer address in DHCPv6—Starting in Junos OS Release 15.1R1, the DHCPv6 server supports clients using a DHCP Unique ID (DUID) based on link-layer address (DUID-LL). To change from the default vendor-assigned DUID based on enterprise number (DUID-EN) to DUID-LL, use the new server-duid-type duid-ll configuration statement at the [edit system services dhcp-local-server dhcpv6] hierarchy level.

  • New support for Framed-IP-Netmask for access-internal routes (MX Series)—Starting in Junos OS Release 15.1R2, 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.

    When the SDB_FRAMED_PROTOCOL attribute is equal to AUTHD_FRAMED_PROTOCOL_PPP, the show subscribers command now displays the actual value of Framed-IP-Netmask in the IP Netmask field. Otherwise, the field displays the default value of 255.255.255.255.

  • Support for saving accounting files when Routing Engine mastership changes (MX Series)—Starting in Junos OS Release 15.1R2, you can configure the router to save the accounting files from the new backup Routing Engine to the new master Routing Engine when a change in mastership occurs. To do so, include the push-backup-to-master statement at the [edit accounting-options file filename] hierarchy level.

    Configure this option when the new backup Routing Engine is not able to connect to the archive site; for example, when the site is not connected by means of an out-of-band interface or the path to the site is routed through a line card. The files are stored in the /var/log/pfedBackup directory on the router. The master Routing Engine includes these accounting files with its own current accounting files when it transfers the files from the backup directory to the archive site at the next transfer interval.

  • Disabling DHCP snooping filters for DHCP traffic that can be directly forwarded (MX Series)—Starting in Junos OS Release 15.1R2, you can disable DHCP snooping filters for an address family in the routing context in which snooping is configured.

    When you first enable DHCP snooping, all DHCP traffic is snooped by default and only DHCP packets associated with subscribers (or their creation) will be handled, all other DHCP packets will be discarded. You can optionally modify this dropping behavior based on the type of interface—configured interfaces, non-configured interfaces, or all interfaces. All snooped DHCP traffic is still forwarded to the routing plane in the routing iInstance, and in some cases, this results in excessive DHCP traffic being sent to the routing plane for snooping The no-snoop statement disables snooping filters for DHCP traffic that can be forwarded directly from the hardware control plane, such as Layer 3 unicast traffic with a valid route, preventing that DHCP traffic from being forwarded to the slower routing plane of the routing instance.

  • Disabling DHCP snooping filters for DHCP traffic that can be directly forwarded (MX Series)—Starting in Junos OS Release 15.1R2, you can disable DHCP snooping filters for an address family in the routing context in which snooping is configured.

    When you first enable DHCP snooping, all DHCP traffic is snooped by default and only DHCP packets associated with subscribers (or their creation) will be handled, all other DHCP packets will be discarded. You can optionally modify this dropping behavior based on the type of interface—configured interfaces, non-configured interfaces, or all interfaces. All snooped DHCP traffic is still forwarded to the routing plane in the routing iInstance, and in some cases, this results in excessive DHCP traffic being sent to the routing plane for snooping The no-snoop statement disables snooping filters for DHCP traffic that can be forwarded directly from the hardware control plane, such as Layer 3 unicast traffic with a valid route, preventing that DHCP traffic from being forwarded to the slower routing plane of the routing instance.

  • Enhanced subscriber management support for source class usage in firewall filters (MX Series with MPCs)—Starting in Junos OS Release 15.1R3, you can configure the source-class and source-class-except match conditions in a firewall filter that you create as part of a dynamic profile for use with enhanced subscriber management. Defining a firewall filter with matching based on source classes allows you to monitor the traffic of specific subscribers from specific network zones.

    To configure a firewall filter term that matches an IPv4 or IPv6 source address field to one or more source classes, use the source-class class-name match condition at the [edit dynamic-profiles profile-name firewall family family-name filter filter-name term term-name from] hierarchy level. To configure a firewall filter term that does not match the IP source address field to the specified source classes, use the source-class-except class-name match condition at the same hierarchy level.

    This feature enables you to dynamically configure firewall filters with the source-class and source-class-except match conditions as part of the same dynamic profile that activates services for a subscriber using enhanced subscriber management. In previous releases, you had to statically define the firewall filter outside of the dynamic profile used for service activation, which was a more time-consuming task and much less efficient

    • Enhanced subscriber management support for configuring routing protocols in dynamic profiles(MX Series with MPCs)—Starting in Junos OS Release 15.1R3, you can configure routing protocols (also known as routing services) on enhanced subscriber management interfaces as part of a dynamic profile. To do so, you must use the routing-services statement at the [edit dynamic-profiles profile-name interfaces “$junos-interface-ifd-name” unit “$junos-underlying-interface-unit”] hierarchy level.

      When you enable enhanced subscriber management, the routing-services statement is required to configure all routing protocols except IGMP and MLD on dynamically created subscriber interfaces. The IGMP and MLD routing protocols are natively supported on enhanced subscriber management interfaces, and therefore do not require you to specify the routing-services statement.

      When a dynamic profile containing the routing-services statement is instantiated, the router creates an enhanced subscriber management logical interface, also referred to as a pseudo logical interface, in the form demux0.nnnn (for example, demux0.3221225472). Any associated subscriber routes or routes learned from a routing protocol running on the enhanced subscriber management interface use this pseudo interface as the next-hop interface.

    • New commands for verifying and managing enhanced subscriber management (MX Series with MPCs)—Starting in Junos OS Release 15.1R3, , you can use the following operational commands to verify and manage enhanced subscriber management interfaces:

    • To display statistics information about enhanced subscriber management interfaces, use the show system subscriber-management statistics command. In addition to displaying basic packet statistics, you can use the available command options to view statistics specific to DHCP (dhcp), dynamic VLAN (dvlan), PPP (ppp), and PPPoE (pppoe) subscriber configurations.

    • To reset all statistics counters to zero, use the clear system subscriber-management statistics command.

    • To display information about how routes are mapped to specific enhanced subscriber management interfaces, use the show system subscriber-management route command. You can customize and filter the output by including one or more options in a single command.

    • Access Node Control Protocol agent support and limitations—Starting in Junos OS Release 15.1R3, the Access Node Control Protocol (ANCP) agent requires enhanced subscriber management to be enabled, but support for the agent is limited to applying ANCP data to CoS traffic shaping for dynamic PPPoE and DHCP IP demux subscribers.

      The ANCP agent does not support the following:

    • Static or dynamic VLAN or VLAN demux interfaces.

    • Static or dynamic interface-sets, including but not limited to agent circuit identifier (ACI) VLANs and VLAN-tagged interface-sets.

    • RADIUS authentication or accounting.

    • Universal CAC for IPTV and VOD on MX Series Routers—Starting in Junos OS Release 15.1R3, universal call admission control (CAC) is supported for multicast IPTV and unicast video on demand (VOD) traffic on MX Series routers. Universal CAC provides enhanced bandwidth management and prevents interface oversubscription to ensure high quality output by using dedicated and shared video bandwidth pools to limit the amount of traffic on subscriber interfaces.

      To configure universal CAC, include the access-cac statement at the [edit dynamic profiles profile name] hierarchy level. You can then configure dedicated video bandwidth pools for IPTV by including the multicast-video-bandwidth statement, shared video bandwidth pools for IPTV and VOD by including the video-bandwidth statement, and multicast video policies by including the multicast-video-policy statement at the [edit dynamic profiles profile name access-cac]hierarchy level.

    • SNMP support for enhanced subscriber management dynamic interfaces—Starting in Junos OS Release 15.1R3, SNMP support is available for enhanced subscriber management dynamic interfaces such as VLAN, PPP, and so on. An extension has been added to the Juniper Networks enterprise-specific Interface MIB to map enhanced subscriber management interfaces to logical route-mapping interfaces and to collect information about enhanced subscriber management interfaces. By default, data about enhanced subscriber management interfaces is not collected in the interfaces tables such as ifTable, ifXTable, and ifStackTable.

      To enable querying of enhanced subscriber management interfaces through the Interface MIB, the Interface MIB must be configured at the interface level by enabling the interface-mib statement at the [edit dynamic-profiles profile name interfaces interface-name] hierarchy level. A link trap is sent for an enhanced subscriber management interface only if the interface name is present in ifTable and traps are enabled.

    • Enhanced subscriber management supported on the Multiservices Modular Interfaces Card (MS-MIC) and the Multiservices Modular PIC Concentrator (MS-MPC) (MX Series)—Starting in Junos OS Release 15.1R3, the Carrier-Grade Network Address Translation (CGNAT) and inline flow monitoring services available with enhanced subscriber management support MS-MPCs and MS-MICs.

    • Captive portal content delivery (HTTP redirect) supported on the Multiservices Modular Interfaces Card (MS-MIC) and the Multiservices Modular PIC Concentrator (MS-MPC), and the Routing Engine (MX Series)—Starting in Junos OS Release 15.1R3, you can configure the captive portal content delivery (HTTP redirect) service package for installation using the set chassis operational mode command. You can deploy HTTP redirect functionality with a local server or a remote server. The Routing Engine-based captive portal supports a walled garden as a firewall service filter only.

    • Effective shaping rate and CoS adjustment control profiles on enhanced subscriber management interfaces (MX Series)—Starting in Junos OS Release 15.1R3, CoS adjustment control profiles that determine the applications and algorithms that can modify a subscriber’s shaping characteristics after a subscriber is instantiated are supported for enhanced subscriber management interfaces. Also, the effective shaping rate capability, which enables the actual downstream traffic rate to be computed and displayed, is also supported for enhanced subscriber management interfaces for accounting purposes.

      When you configure CoS adjustment profiles and effective shaping rate on your router, the enhanced subscriber management interfaces that are defined as part of a dynamic profile at the [edit dynamic-profiles profile-name interfaces “$junos-interface-ifd-name” unit “$junos-underlying-interface-unit”] hierarchy level are considered for these functionalities. Only Ethernet interfaces are supported for these functionalities. Only dynamic subscribers are supported and static subscribers on enhanced subscriber management interfaces are not supported. Only the downstream shaping rate is validated and the upstream shaping rate is set to the advisory rate. Byte adjustments are not included in the effective shaping-rate. When cell-mode is specified, the Juniper Networks router adjusts rates (such as the shaping-rate) to “rate * 48/53” to account for 5-byte ATM AAL5 headers and does not account for cell padding.

    • Enhanced subscriber management support for ACI-based PPPoE subscriber session lockout (MX Series)—Starting in Junos OS Release 15.1R3, enhanced subscriber management supports identification and filtering of PPPoE subscriber sessions by either the agent circuit identifier (ACI) value or the unique media access control (MAC) source address. You can use this feature when you configure PPPoE subscriber session lockout on static or dynamic VLAN and static or dynamic VLAN demux underlying interfaces.

      ACI-based or MAC-based PPPoE subscriber session lockout prevents a failed or short-lived PPPoE subscriber session from reconnecting to the router for a default or configurable time period. ACI-based PPPoE subscriber session lockout is useful for configurations such as PPPoE interworking in which MAC source addresses are not unique on the PPPoE underlying interface.

      To configure ACI-based PPPoE subscriber session lockout for enhanced subscriber management, use the same procedure that you use to configure it on a router without enhanced subscriber management enabled.

    • Support for enhanced subscriber management subscriber logical interfaces or interface sets over MPLS pseudowires for a CoS scheduler hierarchy (MX Series)—Starting in Junos OS Release 15.1R3, you can enable a CoS scheduling hierarchy for enhanced subscriber management subscriber logical interfaces or interface sets over MPLS pseudowire logical interfaces to function as a Layer 2 node in a CoS hierarchical scheduler. A subscriber logical interface is considered to operate at Layer 2 only if you configure three-level hierarchical scheduling on the logical tunnel anchor point on the physical interface (the IFD). An MPLS pseudowire is a virtual device that is stacked above the logical tunnel anchor point. Implicit hierarchy processes the interface stack properly in such a setup.

      To configure three-level hierarchical scheduling, include the implicit-hierarchy statement at the [edit interfaces “$junos-interface-ifd-name” hierarchical-scheduler] or [edit interfaces lt-device hierarchical-scheduler] hierarchy level.

    • Support for enhanced subscriber management subscriber logical interfaces or interface sets over underlying logical interfaces for a CoS scheduler hierarchy (MX Series)—Starting in Junos OS Release 15.1R3, you can enable a CoS scheduling hierarchy for enhanced subscriber management subscriber logical interfaces or interface sets over underlying logical interfaces. In previous releases of Junos OS, an interface set could be either at Layer 2 or Layer 3 levels of the CoS three-level hierarchical scheduler. You can now enable an enhanced subscriber management subscriber logical interface, such as an underlying logical interface, to function as a Layer 2 node in a CoS hierarchical scheduler. To configure three-level hierarchical scheduling, include the implicit-hierarchy statement at the [edit interfaces $junos-interface-ifd-name hierarchical-scheduler] or [edit interfaces lt-device hierarchical-scheduler] hierarchy level.

    • Changes in enhanced subscriber management support for allocating shared memory space (MX Series with MPCs)—Starting in Junos OS Release 15.1R3, the first time you enable enhanced subscriber management, you must configure max-db-size for 400 MB or less (300 MB is recommended). The max-db-size command can be found at the [edit system configuration-database] hierarchy level, and is used to allocated the amount of shared memory available to the configuration database.

    • Enhanced subscriber management on MX Series routers with MPCs—Starting in Junos OS Release 15.1R3, you can configure and enable Junos OS enhanced subscriber management. Enhanced subscriber management is a next-generation broadband edge software architecture for wireline subscriber management. With enhanced subscriber management, you can take advantage of optimized scaling and performance for configuration and management of dynamic interfaces and services.

      Configuring enhanced subscriber management consists of the following high-level tasks:

      1. Download and install Junos OS Release 15.1R3, and reboot the router. Note

        Because unified in-service software upgrade (unified ISSU) is not supported for subscriber management when you upgrade from a release that does not support enhanced subscriber management (Junos OS Release 14.2 or earlier) to a release that does support enhanced subscriber management (15.1R3 and later), all subscriber sessions and subscriber state are lost after such an upgrade.

      2. Configure enhanced IP network services on the router.
      3. Enable enhanced subscriber management.
      4. Configure the maximum amount of shared memory (400 MB or less) used to store the configuration database for enhanced subscriber management.
      5. (Optional) Enable graceful Routing Engine switchover (GRES) and nonstop active routing (NSR).
      6. Commit the configuration and reboot the router.

      After you configure and enable enhanced subscriber management, you can use dynamic profiles as usual for creating and managing dynamic subscriber interfaces and services.

  • Support for a static unnumbered interface with $junos-routing-instance (MX Series)—Starting in Junos OS Release 15.1R3, you can configure a static logical interface as the unnumbered interface in a dynamic profile that includes dynamic routing instance assignment by means of the $junos-routing-instance predefined variable.

    Note

    This configuration fails commit if you also configure a preferred source address, either statically with the preferred-source-address statement or dynamically with the $junos-preferred-source-address predefined variable.

    Note

    The static interface must belong to the routing instance; otherwise the profile instantiation fails.

    In earlier releases, when the dynamic profile includes the $junos-routing-instance predefined variable, you must do both of the following, else the commit fails:

    • Use the $junos-loopback-interface-address predefined variable to dynamically assign an address to the unnumbered interface. You cannot configure a static interface address.

    • Use the $junos-preferred-source-address predefined variable to dynamically assign a secondary IP address to the unnumbered interface. You cannot configure a static preferred source address.

  • Extended hardware support for L2TP inline IP reassembly (MX Series)—Starting in Junos OS Release 15.1R3, L2TP inline IP reassembly support is extended to the following MPCs:

    MPC2E-3D-NG

    MPC5E-40G10G

    MPC2E-3D-NG-Q

    MPC5EQ-40G10G

    MPC3E-3D-NG

    MPC5E-100G10G

    MPC3E-3D-NG-Q

    MPC5EQ-100G10G

  • Monitoring only ingress traffic for subscriber idle timeouts—Starting in Junos OS Release 15.1R3, you can specify that only ingress traffic is monitored for subscriber idle timeout processing. When you Include the client-idle-timeout-ingress-only statement at the [edit access-profile profile-name session-options] hierarchy level, subscribers are logged out or disconnected if no ingress traffic is received for the duration of the idle timeout period. Egress traffic is not monitored. When you do not include this statement, both ingress and egress traffic are monitored during the timeout period to determine whether subscribers are logged out or disconnected.

  • Support for service session termination causes (MX Series)—Starting in Junos OS Release 15.1R3, new internal identifiers are available that identify the reasons that authd initiates termination of individual service sessions. In earlier releases, the termination cause for a service session is the same as that for the parent subscriber session.

    The service termination causes map to default code values that are reported in the RADIUS Acct-Terminate-Cause attribute (49) in Acct-Stop messages for the service. You can use the new service-shutdown option with the terminate-code aaa statement at the [edit access] hierarchy level to remap any of the new termination causes to any number in the range 1 through 4,294,967,295:

    • network-logout—Termination was initiated by deactivation of one family for a dual-stack subscriber, typically triggered by termination of the corresponding Layer 3 access protocol. Default code value is 6.

    • remote-reset—Termination was initiated by an external authority, such as a RADIUS CoA service-deactivation. Default code value is 10.

    • subscriber-logout—Overrides the default inheritance of the subscriber session value with a different value when you map it to a different value. Default code value is 1, meaning that it inherits the terminate cause from the parent subscriber session.

    • time-limit—Service time limit was reached. Default code value is 5.

    • volume-limit—Service traffic volume limit was reached. Default code value is 10.

    The show network-access aaa terminate-code aaa detail command displays the new termination causes and their current code values.

  • New option for service type added to test aaa commands (MX Series)—Starting in Junos OS Release 15.1R4, you can include the service-type option with the test aaa ppp user and test aaa dhcp user commands to test the AAA configuration of a subscriber. You can use this option to distinguish a test session from an actual subscriber session. The option specifies a value for the Service-Type RADIUS attribute [6] in the test Access-Request message; when you do not include this option, the test uses a service type of Framed. You can specify a number in the range 1 through 255, or you can specify one of the following strings that corresponds to an RFC-defined service type; the numbers are the values that are carried in the RADIUS attribute to specify the service:

    administrative (6)

    callback-nas-prompt (9)

    authenticate-only (8)

    framed (2)

    call-check (10)

    login (1)

    callback-admin (11)

    nas-prompt (7)

    callback-framed (4)

    outbound (5)

    callback-login (3)

    When the Service-Type RADIUS attribute [6] is received in an Access-Accept message, it overrides the value inserted in the Access-Request message by this command.

  • New predefined variable for dynamic underlying interfaces (MX Series)—Starting in Junos OS Release 15.1R4, you can use the Juniper Networks predefined variable, $junos-underlying-ifd-name, to reference the underlying physical interface when you configure CoS properties for an underlying logical interface in a dynamic profile. The new variable is useful when the $junos-interface-ifd-name variable already references a different physical interface, such as in configurations with stacked logical interfaces. For example, in a PPPoE session where the PPP logical interface is stacked over a demux VLAN logical interface, $junos-interface-ifd-name is set to the pp0 physical interface. In this case you can specify the $junos-underlying-ifd-name predefined variable with the interfaces statement at the [edit dynamic-profiles profile-name class-of-service] hierarchy level to reference the underlying physical interface.

  • Increase in range for RADIUS server accounting-retry statement (MX Series)—Starting in Junos OS Release 15.1R4, you can configure the router to make a maximum of 60 attempts to send interim accounting messages to the RADIUS accounting server when it has received no response. In earlier releases, the maximum number of attempts is 30.

    Best Practice

    We recommend that you do not configure a retry duration greater than or equal to 30 accounting retries times 90 seconds per accounting timeout period. Configure fewer retries, a shorter timeout, or both.

  • New predefined variables and Juniper Networks VSAs for family any interface filters (MX Series)—Starting in Junos OS Release 15.1R4, you can use the $junos-input-interface-filter and $junos-output-interface-filter predefined variables to attach a filter to a dynamic interface created for family any. The filter names are derived from the Juniper Networks VSAs, Input-Interface-Filter (26-191) and Output-Interface-filter (26-192). These VSAs are conveyed in the following RADIUS messages: Access-Request, Acct-Start, Acct-Stop, and Acct-Interim-Interval. You can specify the variables as the filter names with input and output statements at the [edit dynamic-profiles profile-name interfaces interface-name unit logical-interface-number filter] hierarchy level.

  • New predefined variable to group subscribers on a physical interface (MX Series)—Starting in Junos OS Release 15.1R4, you can specify the new Juniper Networks predefined variable, $junos-phy-ifd-interface-set-name, with the interface-set statement at the [edit dynamic-profiles profile-name interfaces] hierarchy level to configure an interface set associated with the underlying physical interface in a dynamic profile. This predefined variable enables you to group all the subscribers on a specific physical interface so that you can apply services to the entire group of subscribers.

    Another use case is optimizing CoS level 2 node resources by grouping residential subscribers into an interface set associated with the physical interface in a topology where residential and business subscribers share the interface, enabling the use of CoS level 2 nodes for the interface set rather than for each residential interface.

  • Configuring default values for routing instances (MX Series)—Starting in Junos OS Release 15.1R4, you can define a default value for the Juniper Networks predefined variable, $junos-routing-instance. This value is used in the event RADIUS does not supply a value for $junos-routing-instance. To configure a default value, use the predefined-variable-defaults statement at the [edit dynamic-profiles] hierarchy level. For example, to set the default value to RI-default:

  • Hot-standby support for VPLS redundant PWs—Starting in Junos 15.1R4, Junos OS enables you to configure redundant pseudowires (PWs). If a primary PW fails, Junos OS switches service to a preconfigured redundant PW.

    The time required for the redundant PW to recover traffic from the primary PW depends on the number of PWs and the option configured for PW redundancy. There are three options:

    • Backup redundancy

    • Standby redundancy

    • Hot-standby

    The hot-standby option enables Junos OS to reduce the amount of traffic it discards during a transition from a primary to redundant PW. Both the active and standby paths are kept open within the Layer 2 domain. Now you can configure the hot-standby option to configure PWs for virtual private LAN services (VPLS) running the Label Distribution Protocol (LDP).

  • Enhanced DHCP dual-stack support (MX Series)—Starting in Junos OS Release 15.1R4, subscriber management supports a single-session DHCP dual-stack model that provides a more efficient configuration and management of dual-stack subscribers.

    The single-session dual-stack model addresses session-related inefficiencies that exist in the traditional dual-stack—for example, the new model requires single sessions for authentication and accounting, as opposed to multiple sessions that are often needed in a traditional dual-stack configuration. The single-session dual-stack model also simplifies router configuration, reduces RADIUS message load, and improves accounting session performance for subscriber households with dual-stack environments.

    [See Single-Session DHCP Dual-Stack Overview.]

  • DHCPv6 subscriber identification criteria and automatic logout—Starting in Junos OS Release 15.1R5, the DHCPv6 local server and the DHCPv6 relay agent can identify a DHCPv6 client by the incoming-interface option in addition to the client identifier. The incoming interface allows only one client device to connect on the interface. If the client device changes—that is, if DHCPv6 receives a Solicit message from a client whose incoming interface matches the existing interface—DHCPv6 automatically logs out the existing client without waiting for the normal lease expiration. It deletes the existing client binding and creates a binding for the newly connected device.

    For DHCPv6 local server, include the client-negotiation-match incoming-interface statement at the [edit system services dhcp-local-server dhcpv6 overrides], [edit system services dhcp-local-server dhcpv6 group group-name overrides], or [edit system services dhcp-local-server dhcpv6 group group-name interface interface-name overrides] hierarchy levels.

    For DHCPv6 relay agent, include the client-negotiation-match incoming-interface statement at the [edit forwarding-options dhcp-relay dhcpv6 overrides], [edit forwarding-options dhcp-relay dhcpv6 group group-name overrides], or [edit forwarding-options dhcp-relay dhcpv6 group group-name interface interface-name overrides] hierarchy levels.

  • RADIUS attributes added to LNS messages (MX Series)—Starting in Junos OS Release 15.1R7, the LNS includes the following RADIUS attributes when it sends an Access-Request message to the RADIUS server:

    • Tunnel-Type (64)

    • Tunnel-Medium-Type (65)

    • Tunnel-Client-Endpoint (66)

    • Tunnel-Server-Endpoint (67)

    • Acct-Tunnel-Connection (68)

    • Tunnel-Assignment-Id (82)

    • Tunnel-Client-Auth-Id (90)

    • Tunnel-Server-Auth-Id (91)

  • DHCP rate adjustment (MX Series)—Starting in Junos OS Release 15.1R5, you can use DHCP tags to modify the CLI-configured and RADIUS-configured shaping rate values after a subscriber is instantiated. The new values are conveyed in DHCP option 82, suboption 9 discovery packets. Suboption 9 contains the Internet Assigned Numbers Authority (IANA) DSL Forum VSA (vendor ID 3561).

    Configure the shaping rate adjustment controls by including the dhcp-tags statement at the [edit class-of-service adjustment-control-profiles profile-name application] hierarchy level. Specify the desired rate-adjustment algorithm and set a priority for the DHCP Tags application in the adjustment control profile.

  • Configurable grace period for unresponsive RADIUS servers (MX Series)—Starting in Junos OS Release 15.1R6, you can use the timeout-grace statement at the [edit access radius-options] hierarchy level to configure a grace period that determines when an unresponsive RADIUS authentication server is marked as down or unreachable. When the server fails to respond to any of the attempts made for an authentication request, it times out, the time is noted, and the grace period begins. If the server is unresponsive for subsequent authentication requests, the grace period is checked each time the server times out. When the check determines that the grace period has expired, the server is marked as down or unreachable.

    You can configure the grace period in the range 0 through 30 seconds; the default is 10 seconds. Use a short grace period to declare servers unavailable sooner and direct requests to available servers. Use a long grace period to give unresponsive servers more opportunities to respond.

    In earlier releases, the grace period is 10 seconds and is not configurable.

  • Traffic shaping and tunnel switches (MX Series)—Starting in Junos OS Release 15.1R6, when a dynamic profile attaches a statically configured firewall filter to an L2TP tunnel switch (LTS) session, the filter polices traffic from the LTS (acting as a LAC) to the ultimate endpoint LNS, in addition to the previously supported traffic from the LAC to the LTS (acting as an LNS). In previous releases, the firewall filter applied to only the traffic from the LAC to the LTS.

  • Enhancement to Gx-Plus Application (MX Series)—Starting in Junos OS Release 15.1R6, the following enhancements to the Gx-Plus client application on the BNG are available:

    • When a monitored service is deactivated separate from a subscriber logout, the CCR-U indicates that the service is no longer active and includes the service’s usage data.

    • The router updates the monitoring key and threshold values when they are received in a RAR message from the PCRF.

    • A CCR-U is sent to the PCRF after the router sends an RAA message in response to an RAR message that requests service activations or deactivations.

    • When the PCRF returns threshold values that are lower than the current values, the new threshold becomes the sum of the current value and the returned value.

    • The PCEF has default minimum threshold values. If the change between the current value and the value returned by the PCRF is less than the minimum value, then the new value is adjusted to the minimum.

    • The CCR-I message includes the Diameter AVP Subscription-Id attribute (443) with the Subscription-Id-Type Diameter AVP sub-attribute (450) set to 4 (END_USER_PRIVATE) and the Subscription-Id-Data Diameter AVP sub-attribute (444) set to reserved.

System Logging

  • System log messages to indicate checksum errors on the DDR3 interface—Starting in Junos OS Release 13.3 R9, two new system log messages, XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MINOR and XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MAJOR, are added to indicate memory-related problems on the interfaces to the double data rate type 3 (DDR3) memory. These error messages indicate that an FPC has detected a checksum error, which is causing packet drops.

    The following error threshold values classify the error as a major error or a minor error:

    • Minor error— 6-254 errors per second

    • Major error—255 and more errors per second

User Interface and Configuration

  • Support for displaying configuration differences in XML tag format (M Series, MX Series, and T Series)—Starting with Junos OS Release 15.1R1, you can use the show compare | display xml command to compare the candidate configuration with the current committed configuration and display the differences between the two configurations in XML tag format.

    [See Understanding the show | compare | display xml Command Output.]

VPNs

  • Leveraging DPCs for EVPN deployment (MX Series routers with DPCs)—Starting with Junos OS Release 15.1R1, DPCs can be leveraged to provide support for Ethernet VPN (EVPN) functionality. Earlier, the EVPN functionality was provided by MX Series routers with MPC and MIC interfaces only.

    The DPC support for EVPN is provided with the following considerations:

    • DPCs provide support for EVPN in the active/standby mode of operation including support for the following:

      • EVPN instance (EVI)

      • Virtual switch (VS)

      • Integrated routing and bridging (IRB) interfaces

    • DPCs intended for providing the EVPN active/standby mode support should be the customer edge (CE) device-facing line card. The provider edge (PE) device interfaces in the EVPN domain should use only MPC and MIC interfaces.

      [See EVPN Multihoming Overview.]

  • Note

    Although present in the code, the Ethernet VPN (EVPN) active/active multihoming feature is not supported in Junos OS Release 15.1R2.

    Active/active multihoming support for EVPNs (MX Series routers with MPCs and MICs only)—The Ethernet VPN (EVPN) solution on MX Series routers with MPC and MIC interfaces is extended to provide multihoming functionality in the active/active redundancy mode of operation. This feature enables load-balancing of Layer 2 unicast traffic across all the multihomed links on and toward a customer edge device, and provides link-level and node-level redundancy along with effective utilization of resources.

  • Enhanced Group VPNv2 member features (MX10, MX20, MX40, MX80, MX240, MX480, MX960)—Starting in Junos OS Release 15.1R1, Group VPNv2 member features have been enhanced to include the following:

    • Accept group domain of interpretation (GDOI) push messages from Cisco group controller/key server (GC/KS) as per RFC 6407.

    • Support for group associated policy (GAP) payload, including activation time delay (ATD) and deactivation time delay (DTD), in push messages from Cisco GC/KS as per RFC 6407.

    • Support standardized push ACK messages from MX Series group member router to Cisco GC/KS as per IETF RFC 8263RFC 8263.

    • IP Delivery Delayed Detection Protocol. Time-based anti-replay protection for Group VPNv2 data traffic on MX Series group member routers as per IETF draft RFC http://tools.ietf.org/html/draft-weis-delay-detection-00 .

    • Support for SHA-256 HMAC algorithm for authentication.

    • Support partial fail open for business-critical traffic.

    • Support for control-plane debug traces per member IP address and server IP address.

    • Same gateway for multiple groups, wherein the same local and remote address pair is used for multiple groups.

    [See Group VPNv2 Overview.]

  • Segmented inter-area P2MP LSP (M Series, MX Series, and T Series)—Starting with Junos OS Release 15.1R1, P2MP LSPs can be segmented at the area boundary. A segmented P2MP LSP consists of an ingress area segment(ingress PE router or ASBR), backbone area segment (Transit ABR), and egress area segment (egress PE routers or ASBRs). Each of the intra-area segments can be carried over provider tunnels such as P2MP RSVP-TE LSP, P2MP mLDP LSP, or ingress replication. Segmentation of inter-area P2MP LSP occurs when the S-PMSI auto-discovery routes are advertised, which triggers the inclusion of a new BGP extended community or inter-area P2MP segmented next-hop extended community in the ingress PE router or ASBR, transit ABR, and egress PE routers or ASBRs.

    [See Example: Configuring Segmented Inter-Area P2MP LSP.]

  • EVPN with VXLAN data plane encapsulation (MX Series)—Starting in Junos OS Release 15.1R3, MX Series routers can use EVPN with VXLAN encapsulation to provide Layer 2 connectivity for end stations within a Virtualized Network (VN) created by the Contrail virtualization software. The end stations consist of virtual hosts connected to the virtualized server, and non-virtualized bare metal servers connected to top-of-rack platforms. MX Series routers also function as default gateways for the inter-VN traffic among end stations that belong to different VNs. EVPN is used as a Layer 2 overlay solution to provide Layer 2 connections over the IP underlay for the endpoints within a VN whenever Layer 2 connectivity is required by an end station.

  • MVPN source-active upstream multicast hop selection and redundant source improvements–Starting in Junos OS Release 15.1R3, you can use new configuration statements available at the [edit protocols mvpn] hierarchy level to influence the source-active upstream multicast hop selection process. You can use the umh-selection-additional-input statement to influence the upstream multicast hop selection by making the MVPN consider some combination of route preference and RSVP tunnel status. You can use the source-redundancy statement so that the MVPN acts on all redundant sources sending to a specific group address as the same source.