Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

No index entries found.

New and Changed Features

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

Hardware

  • Support for 12-port rate-selectable MIC (MIC-MRATE) on MPC8E and MPC9E (MX2010 and MX2020)—Starting with Junos OS Release 15.1F5, the MPCs MPC8E and MPC9E support the 12-port rate-selectable MIC (MIC-MRATE) on the MX2000 line of routers. MIC-MRATE uses the quad small form-factor pluggable plus (QSFP+) transceiver for connectivity and supports port speeds of 100 Gbps, 40 Gbps, and 10 Gbps. MIC-MRATE also supports breakout cables, which you can use to split a 40-Gigabit Ethernet port into four 10-Gigabit Ethernet ports.

    MIC-MRATE supports a maximum of 48 10-Gigabit Ethernet interfaces. On MPC8E with MIC-MRATE, you can configure four ports as 100-Gigabit Ethernet interfaces. On MPC9E with MIC-MRATE, you can configure eight ports as 100-Gigabit Ethernet interfaces.

    MIC-MRATE also supports remote port identification. The LEDs for individual ports on the MIC and the related CLI commands help identify ports and assist in guided cabling.

    Note: To use MIC-MRATE on Junos OS Release 15.1F5, you must download and install the Junos Continuity software package for Junos OS Release 15.1F5.

    Junos Continuity software package is not required for Junos OS Releases 15.1F6 and later.

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

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

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

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

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

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

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

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

    Junos Continuity software package is not required for Junos OS Releases 15.1F6 and later.
  • Support for MPC8E on MX2010 and MX2020 routers—Starting in Release 15.1F5, Junos OS supports MPC8E, a new Modular Port Concentrator (MPC) with two Modular Interface Card (MIC) slots, that provides a maximum bandwidth of 960 Gbps. MPC8E has four Packet Forwarding Engines, each providing a maximum bandwidth of 240 Gbps.

    Note: To use the MPC8E MPC on Junos OS Release 15.1F5, you must download and install the Junos Continuity software package for Junos OS Release 15.1F5.

    Junos Continuity software package is not required for Junos OS Releases 15.1F6 and later.

    MPC8E supports:

    • Line-rate throughput of up to 960 Gbps on the MX2000 line of routers.
    • Two 12-port MIC-MRATE MICs with QSFP+ transceivers that support rate-selectability at the port level.
    • Configuration of four ports out of 12 MIC-MRATE ports as 100-Gigabit Ethernet ports.
    • Configuration of PIC-based tunnel interfaces from the Junos CLI, which allows you to configure 4,000 tunnel interfaces per PIC and 16,000 tunnel interfaces per line card.
    • Maximum Transmission Unit (MTU) size of 16,000 bytes for transit traffic.
    • Dynamic power management for effective utilization of available power.
    • Inline flow monitoring for higher scalability and performance.
    • Flexible queuing using an add-on license to support 32,000 queues per line card, including queues on both ingress and egress interfaces. You can use an additional license to support up to 512,000 queues per slot or 1,000,000 queues per slot.
    • Hyper mode to speed up packet processing.

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

  • Support for 12-port rate-selectable MIC (MIC-MRATE) on MPC8E and MPC9E (MX2010 and MX2020)—Starting with Junos OS Release 15.1F5, the MPCs MPC8E and MPC9E support the 12-port rate-selectable MIC (MIC-MRATE) on the MX2000 line of routers. MIC-MRATE uses the quad small form-factor pluggable plus (QSFP+) transceiver for connectivity and supports port speeds of 100 Gbps, 40 Gbps, and 10 Gbps. MIC-MRATE also supports breakout cables, which you can use to split a 40-Gigabit Ethernet port into four 10-Gigabit Ethernet ports.

    MIC-MRATE supports a maximum of 48 10-Gigabit Ethernet interfaces. On MPC8E with MIC-MRATE, you can configure four ports as 100-Gigabit Ethernet interfaces. On MPC9E with MIC-MRATE, you can configure eight ports as 100-Gigabit Ethernet interfaces.

    MIC-MRATE also supports remote port identification. The LEDs for individual ports on the MIC and the related CLI commands help identify ports and assist in guided cabling.

    Note: To use MIC-MRATE on Junos OS Release 15.1F5, you must download and install the Junos Continuity software package for Junos OS Release 15.1F5.

    Junos Continuity software package is not required for Junos OS Releases 15.1F6 and later.

  • Support for MPC9E (MX2010 and MX2020)—Starting with Junos OS Release 15.1F5, MX2020 and MX2010 routers support the Modular Port Concentrator (MPC) MPC9E (MX2K-MPC9E) with two Modular Interface Card (MIC) slots. MPC9E supports only the new 12-port rate-selectable MIC MIC-MRATE. MPC9E has four Packet Forwarding Engines, each with forwarding capability of up to 400 Gbps.

    Note: To use MPC9E on Junos OS Release 15.1F5, you must download and install the Junos Continuity software package for Junos OS Release 15.1F5.

    Junos Continuity software package is not required for Junos OS Release 15.1F6 and later.

    MPC9E supports:

    • Line-rate throughput of up to 1.6 Tbps on the MX2000 line of routers with SFB2.
    • Two 12-port MIC-MRATE MICs with QSFP+ transceivers that support rate-selectability at the port level.
    • Configuration of 8 ports out of the 12 MIC-MRATE ports as 100-Gigabit Ethernet ports.
    • Comfiguration of PIC-based tunnel interfaces from the Junos CLI, which allows you to configure 4,000 tunnel interfaces per PIC and 16,000 tunnel interfaces per line card.
    • Maximum Transmission Unit (MTU) size of 16,000 bytes for transit traffic.
    • Dynamic power management for effective utilization of available power.
    • Inline flow monitoring for higher scalability and performance.
    • Flexible queuing using an add-on license to support 32,000 queues per line card, including queues on both ingress and egress interfaces. You can use an additional license to support up to 512,000 queues or one 1,000,000 queues per slot.
    • Hyper mode to speed up packet processing.
  • Support for enhanced Switch Fabric Board (SFB2) for increased fabric bandwidth per slot (MX2010 and MX2020)—Starting with Release 15.1F5, Junos OS supports an enhanced Switch Fabric Board (model number: MX2000-SFB2-S) that provides increased fabric bandwidth per slot. The MX2000 line of routers support SFB and SFB2, but not both at the same time. However, during an upgrade from SFB to SFB2, the MX2000 line of routers support both SFB and SFB2 at the same time for the duration of the upgrade.

    Note: To use SFB2 on Junos OS Release 15.1F5, you must download and install the Junos Continuity software package for Junos OS Release 15.1F5.

    Junos Continuity software package is not required for Junos OS Releases 15.1F6 and later.

  • Support for MPC7E 10G (MX2020, MX2010, MX960, MX480, and MX240)—Starting with Junos OS Release 15.1F5, MX2020, MX2010, MX960, MX480, and MX240 routers support the Modular Port Concentrator (MPC) MPC7E 10G (MPC7E-10G). This is a fixed-configuration MPC with 40 10-Gigabit Ethernet ports. To use the MPC7E 10G on Junos OS Release 15.1F5, you must download and install the Junos Continuity software package for Junos OS Release 15.1F5.

    Junos Continuity software package is not required for Junos OS Releases 15.1F6 and later.

    Note:

    • On the MX2000 line of routers, the MPC7E 10G is plugged into an adapter card. Therefore, to use the MPC7E 10G MPC on MX2000 line of routers, the adapter card must be installed on the routers.
    • To operate the MPC7E 10G on MX240, MX480, and MX960 routers, the routers must be equipped with high-capacity power supply, high-capacity fan tray, and Enhanced Switch Control Board SCBE2.

    The main features of the MPC7E-10G MPC are the following:

    • Line-rate throughput of up to 400 Gbps on MX240, MX480, MX960, MX2010, and MX2020 routers.
    • Forty 10-Gigabit Ethernet ports. The ports support small-form factor pluggable plus (SFP+) transceivers.
    • Supports maximum transmission units (MTUs) from 256 bytes through 16,000 bytes.
    • Supports hyper mode to speed up packet processing.
    • Supports flexible queuing by using an add-on license to support 32,000 queues per line card, including queues on both ingress and egress interfaces. You can use an additional license to support up to 512,000 queues.

    Note: On MX240, MX480, and MX960 routers, the MPC7E 10G powers on only if the network-services mode on the router is configured as either enhanced-ip or enhanced-ethernet. On MX2000 routers, no additional configuration is required because by default the router operates in enhanced-ip mode.

Class of Service (CoS)

  • Copy ToS bits from incoming IP header to outer GRE IP header (MX Series with MPCs)—Starting in Junos OS Release 15.1F5, you can set GRE tunnel interfaces to copy the ToS bits (DSCP value) from the incoming IPv4 header to the outer GRE IP header for transit traffic. You can set this at the individual GRE interface level by including the copy-tos-to-outer-ip-header-transit statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number] hierarchy level, or globally by including the copy-tos-to-outer service-type ([ gre ] | [ mt ]) statement at the [edit chassis] hierarchy level.

    You can also now rewrite the DSCP/IP precedence value in both the inner and outer headers with the rewrite rules ([ dscp ] | [ inet-precedence ]) default protocol ([ inet-both ] | [ inet-outer ]) statement at the [edit class-of-service interfaces interface-name] hierarchy level.

General Routing

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

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

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

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

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

  • Support for the combined operation of Synchronous Ethernet and Precision Time Protocol or hybrid mode (MX104)—A combined operation of Synchronous Ethernet and Precision Time Protocol (PTP), also known as hybrid mode, is supported on the MX104 routers. In hybrid mode, the Synchronous Ethernet equipment clock (EEC) derives the frequency from Synchronous Ethernet and the phase and time of day from PTP (also known as IEEE 1588v2) for time synchronization.

    Synchronous Ethernet and PTP provide frequency and phase synchronization; however, the accuracy in the order of nanoseconds is difficult to achieve through either PTP or Synchronous Ethernet, and they do not support a large number of network hops. Hybrid mode resolves these issues by extending the number of network hops and also provides the clock synchronization accuracy in the order of tens of nanoseconds.

    To configure hybrid mode, include the hybrid synchronous-ethernet-mapping clock-source ip-address interface interface-name1 statement at the [edit protocols ptp slave] hierarchy level.

    To set the Ethernet Synchronization Message Channel (ESMC) from the PTP clock class, include the convert-clock-class-to-quality-level statement at the [edit protocols ptp slave] hierarchy level.

    To override the default PTP clock class to ESMC mapping, include the clock-class-to-quality-level-mapping quality-level ql-value clock-class clock-class-value statement at the [edit protocols ptp slave] hierarchy level, where clock-class indicates the current state of the clock and the quality-level indicates the clock type.

    Note that if the selected Synchronous Ethernet reference fails, the router continues to work in PTP mode. You can use the show ptp hybrid status operational command to find the current operating mode.

    Note:

    • To switch between the PTP and Synchronous Ethernet modes, you must first deactivate the configuration for the current mode and then commit the configuration. Wait for 30 seconds, configure the new mode and its related parameters, and then commit the configuration.
    • Hybrid mode is not supported on integrated routing and bridging (IRB) and aggregated Ethernet interfaces configured on MX104 routers.
    • Unified in-service software upgrade (unified ISSU) is not supported when clock synchronization is configured for hybrid mode on MX104 routers.

  • Support for PTP over IRB interfaces (MX104)—Starting in Junos OS Release 15.1F5, MX104 routers support Precision Time Protocol (PTP) over integrated routing and bridging (IRB) interfaces. In releases before Junos OS Release 15.1F5, MX104 routers support PTP over physical Ethernet interfaces only.

Interfaces and Chassis

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

IPv6

  • Forced IPv6 DNS server address insertion(MX Series)—Starting in Junos OS Release 15.1F5, MX Series devices can dynamically provision DHCPv6 lease times and DNSv6 server IP addresses for DHCPv6 clients. The IP addresses and lease times are provided to DHCPv6 clients in DHCPv6 Advertisement and Reply messages without requiring a Solicit or Request message from a CPE device.

Management

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

MPLS

  • Support for IS-IS segment routing (MX Series)—Starting with Junos OS Release 15.1F5, IS-IS segment routing support is enabled through MPLS. Currently, label advertisements are supported for IS-IS only. IS-IS creates an adjacency segment per adjacency, per level, and per address family (one each for IPv4 and IPv6). Junos OS IS-IS implementation allocates node segment label blocks in accordance with the IS-IS protocol extensions for supporting segment routing node segments and provides a mechanism to the network operator to provision an IPv4 or IPv6 address family node segment index. To configure segment routing, use the following configuration statements at the [edit protocols isis] hierarchy level:
    • source-packet-routing—Enable the source packet routing feature.
    • node-segment—Enable source packet routing at all levels.
    • use-source-packet-routing—Enable use of source packet routing node segment labels for computing backup paths for normal IPv4 or IPv6 IS-IS prefixes and primary IS-IS source packet routing node segments.
    • no-advertise-adjacency-segment—Disable advertising of the adjacency segment on all levels for a specific interface.
  • Subnet-match authentication for LDP sessions (MX Series and T Series)—Starting with Junos OS Release 15.1F5, support for Hashed Message Authentication Code (HMAC) and MD5 authentication for LDP sessions is extended from a per-session configuration to a subnet-match (that is, longest-prefix-match) configuration.

    This feature provides flexibility in configuring authentication for automatically targeted LDP (TLDP) sessions, making the deployment of remote loop-free alternate (LFA) and FEC 129 pseudowires easy.

    To enable this feature, configure the session-group option at the [edit protocols ldp session] hierarchy level, and then enable the required authentication for the configured session group.

Multicast

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

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

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

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

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

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

Network Management and Monitoring

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

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

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

Platform and Infrastructure

  • Virtual MX Series router (vMX)—Starting in Junos OS Release 15.1F3, you can deploy vMX routers on x86 servers. vMX supports most of the features available on MX Series routers and allows you to leverage Junos OS to provide a quick and flexible deployment. vMX provides the following benefits:
    • Optimizes carrier-grade routing for the x86 environment
    • Simplifies operations by consistency with MX Series routers
    • Introduces new services without reconfiguration of current infrastructure
  • Performance mode is default for chassis (vMX)—Starting in Junos OS Release 15.1F5, performance mode is enabled by default for the chassis. Performance mode needs more vCPUs and memory to run at higher bandwidth, while lite mode needs fewer vCPUs and memory to run at lower bandwidth. You enable lite mode by configuring the lite-mode option at the [edit chassis fpc 0] hierarchy level.

Routing Protocols

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

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

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

    Use the following CLI hierarchy to configure BGP-ORR:

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

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

    • show bgp group—View the primary and backup configurations of BGP-ORR.
    • show isis bgp-orr—View the IS-IS BGP-ORR metric (RIB).
    • show route advertising protocol bgp peer —Verify whether the routes are being advertised according to the BGP-ORR rules.
  • IS-IS purge originator identification TLV (MX Series)—Beginning with Release 15.1F4, Junos OS supports RFC 6232, Purge Originator Identification TLV for IS-IS, which defines a type, length and value (TLV) for identifying the origin of a purge initiated by the IS-IS protocol. You can configure this feature to add this TLV to a purge, along with the system ID of the Intermediate System (IS) that has initiated this purge. This makes it easier to locate the origin of the purge and its cause.
  • BGP flow specification for IPv6 (MX Series)—Starting with Junos OS Release 15.1F5, this feature extends IPv6 support to the BGP flow specification which enables propagation of traffic flow specification rules for IPv6 and IPv6 VPN. The BGP flow specification automates coordination of traffic filtering rules in order to mitigate distributed denial-of-service attacks. In earlier Junos OS releases, flow-specific rules were propagated for IPv4 over BGP as network layer reachability information.

    To enable the BGP flow specification for IPv6, include the flow statement at the [edit routing-options] hierarchy level for global configuration or at the [edit routing-instances routing-instance-name routing-options] hierarchy level for instance-level configuration.

  • BGP labeled unicast supports stack of labels (MX Series)—Beginning with Release 15.1F5, Junos OS supports RFC 3107, Carrying Label Information in BGP-4, that allows stacking of multiple labels in the BGP labeled unicast. In earlier Junos OS Releases, only one label per prefix was supported in the BGP unicast label. Junos OS now supports a label stack of up to five labels per prefix in the BGP labeled unicast updates. BGP labeled unicast updates with more than five labels are not supported, and Junos OS sets their state to hidden. This feature allows the use of BGP unicast label stack to control packet forwarding in the network and to reflect the BGP unicast label stack routes to its clients without changing the next hop.
  • Restricting LSP flooding over IS-IS interfaces (MX Series)—Beginning with Junos OS Release 15.1F5, the IS-IS protocol can restrict flooding of LSAs to control sharing of routes between multiple level 2 metro ring networks. You can segregate both level 1 and level 2 networks into flood groups by using area IDs as tags to identify a flood group. Configure interfaces with specific area IDs to modify the flooding behavior as per your requirements. For example, when a router is connected to five level 2 metro ring networks, by default all the routers in the five rings are flooded with all LSP routes. You can configure five distinct flood groups on the ring-facing interfaces on the pre-aggregation device to restrict LSP flooding to a specific area. Configure area IDs on interfaces to segregate them into flood groups. LSPs that belong to the specified area only are flooded through these interfaces. However, self-originated LSPs are not affected by this configuration.
  • Micro loop avoidance when IS-IS link fails (MX Series and T Series)—Beginning with Release 15.1F5, Junos OS enables a device to defer IS-IS route download when an IS-IS link fails in order to avoid micro loops. When local links go down, the IS-IS protocol floods an entire area with the database. If the node connected to the local interface that has failed converges faster than the neighboring node, then the connected node redirects traffic to the converged path. This redirection can result in micro looping of traffic until the neighboring node converges. When the primary path of a protected node fails, the connected node does not need to converge quickly if the configured back up path is not impacted. In this case, traffic flow towards a converged path is deferred until the configured delay time.

Services Applications

  • Support for inline LSQ logical interface—Starting in Junos OS Release 15.1F4, 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.
  • Class-of-service (CoS) marking and reclassification for the MS-MICs and MS-MPCs—Starting with Junos Release 15.1F5, 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.]

  • Exclude interfaces support in flowspec (rpd-infra) (MX Series)—Starting in Release 15.1, Junos OS excludes applying the flowspec filter to traffic received on specific interfaces. A new term is added at the beginning of the flowspec filter that accepts any packet received on these specific interfaces. The new term is a variable that creates an exclusion list of terms attached to the forwarding table filter as a part of the flow specification filter.

    To exclude the flowspec filter from being applied to traffic received on specific interfaces, you must first configure a group-id on such interfaces by including the family inet filter group group-id statement at the [edit interfaces] hierarchy level, and then attach the flowspec filter with the interface group by including the flow interface-group group-id exclude statement at the [edit routing-options] hiearchy level. You can configure only one group-id per routing instance with the set routing-options flow interface-group group-id statement.

  • 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.1F5, 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:

    [edit applications]
    application ike-esp-application-name { application-protocol ike-esp-nat; protocol udp; destination-port 500; inactivity-timeout 3600; }
    application-set ike-esp-application-set-name { application ike-esp-application-name; }
    [edit services nat]
    pool ike-isp-nat-pool-name { address ip-prefix; port automatic; }
    rule rule-name { match-direction input; term 0 { from { source-address address; application-sets ike-esp-application-set-name; } then { translated { source-pool ike-isp-nat-pool-name; translation-type napt-44; } } } }
  • Support for IP reassembly on an L2TP connection—You can now configure the service interfaces on MX Series routers with MPC2E-3D-NG, MPC2E-3D-NG-Q, MPC3E-3D-NG, MPC3E-3D-NG-Q, and MPC5E to support IP packet reassembly on a Layer 2 Tunneling Protocol (L2TP) connection. The IP packet is fragmented over an L2TP connection when the packet size exceeds the maximum transmission unit (MTU) defined for the connection. Depending on the direction of the traffic flow, the fragmentation can occur either at the L2TP access concentrator (LAC) or at the L2TP network server (LNS),and reassembly occurs at the peer interface. (In an L2TP connection, a LAC is a peer interface for the LNS and vice versa.)

    You can configure the service interfaces on the LAC or on the LNS to reassemble the fragmented packets before they can be further processed on the network. On a router running Junos OS, a service set is used to define the reassembly rules on the service interface. The service set is then assigned to the L2TP service at the [edit services l2tp] hierarchy level to configure IP reassembly for L2TP fragments.

    You can view the reassembly statistics by using the show services inline ip-reassembly statistics <fpc fpc-slot | pfe pfe-slot> command.

    See IP Packet Fragment Reassembly for L2TP Overview

  • Support for inline flow monitoring on MPC7E-MRATE, MPC8E, and MPC9E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 15.1F5, MPC7E-MRATE, MPC8E, and MPC9E support inline flow monitoring. Inline active flow monitoring provides for higher scalability and performance, as the scaling and performance are not dependent on the capacity of the services interface.
  • Exclude interfaces support in flowspec (rpd-infra) (MX Series)—Starting in Release 15.1, Junos OS excludes applying the flowspec filter to traffic received on specific interfaces. A new term is added at the beginning of the flowspec filter that accepts any packet received on these specific interfaces. The new term is a variable that creates an exclusion list of terms attached to the forwarding table filter as a part of the flow specification filter.

    To exclude the flowspec filter from being applied to traffic received on specific interfaces, you must first configure a group-id on such interfaces by including the family inet filter group group-id statement at the [edit interfaces] hierarchy level, and then attach the flowspec filter with the interface group by including the flow interface-group group-id exclude statement at the [edit routing-options] hiearchy level. You can configure only one group-id per routing instance with the set routing-options flow interface-group group-id statement.

Software Installation and Upgrade

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

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

Software-Defined Networking

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

    These triggers elicit one of the following responses:

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

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

  • IGP-based topology discovery (MX Series)—Starting in Junos OS Release 15.1F4, the NorthStar Controller supports dynamic topology acquisition by using routing protocols (IS-IS, OSPF, and BGP LS) to obtain real-time topology updates.
  • Support of Internet draft draft-crabbe-pce-pce-initiated-lsp-03 for the stateful PCE-initiated LSP implementation (MX Series and T Series)—In the partial client-side implementation of the stateful Path Computation Element (PCE) architecture, the implementation of PCE-controlled LSPs that are dynamically initiated by a PCE is currently based on version 1 of Internet draft draft-crabbe-pce-pce-initiated-lsp. Starting with Junos OS Release 14.2R4 and 15.1F4, this implementation is upgraded to support version 3, as defined in Internet draft draft-crabbe-pce-pce-initiated-lsp-03.

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

  • Support of Internet draft draft-ietf-pce-stateful-pce-07 for the stateful PCC implementation (MX Series and T Series)—The partial client-side implementation of the stateful Path Computation Element (PCE) architecture is currently based on version 2 of Internet draft draft-ietf-pce-stateful-pce. Starting with Junos OS Release 14.2R4 and 15.1F4, this implementation is upgraded to support version 7, as defined in Internet draft draft-ietf-pce-stateful-pce-07.

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

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

Subscriber Management and Services

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

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

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

  • Support for a static unnumbered interface with $junos-routing-instance (MX Series)—Starting in Junos OS Release 15.1F5, 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.
  • Static provisioning of unique subscriber ID including interface description—Starting in Junos OS Release 15.1F5, you can configure DCHP server and DHCP relay to concatenate the interface description with the username during the subscriber authentication or client authentication process. The interface description is separated from the other username fields by the specified delimiter, or by the default delimiter “.” if no delimiter is specified. The interface description can include either the logical interface description or the device interface description.

    Note: Ensure that the specified delimiter is not part of the interface description.

    Use the new interface-description (device-interface | logical-interface) configuration statement at one of the following hierarchy levels to specify that either the device interface description or logical interface description be concatenated to the other username fields:

    • [edit forwarding-options dhcp-relay authentication username-include]
    • [edit forwarding-options dhcp-relay dhcpv6 authentication username-include]
    • [edit forwarding-options dhcp-relay dhcpv6 group group-name authentication username-include]
    • [edit forwarding-options dhcp-relay group group-name authentication username-include]
    • [edit logical-systems logical-system-name forwarding-options dhcp-relay authentication username-include]
    • [edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name authentication username-include]
    • [edit logical-systems logical-system-name routing-instances routing-instance-name forwarding-options dhcp-relay authentication username-include]
    • [edit logical-systems logical-system-name routing-instances routing-instance-name forwarding-options dhcp-relay group group-name authentication username-include]
    • [edit logical-systems logical-system-name routing-instances routing-instance-name system services dhcp-local-server authentication username-include]
    • [edit logical-systems logical-system-name routing-instances routing-instance-name system services dhcp-local-server group group-name authentication username-include]
    • [edit logical-systems logical-system-name system services dhcp-local-server authentication username-include]
    • [edit logical-systems logical-system-name system services dhcp-local-server group group-name authentication username-include]
    • [edit routing-instances routing-instance-name forwarding-options dhcp-relay authentication username-include]
    • [edit routing-instances routing-instance-name forwarding-options dhcp-relay group group-name authentication username-include]
    • [edit routing-instances routing-instance-name system services dhcp-local-server authentication username-include]
    • [edit routing-instances routing-instance-name system services dhcp-local-server group group-name authentication username-include]
    • [edit system services dhcp-local-server authentication username-include]
    • [edit system services dhcp-local-server dhcpv6 authentication username-include]
    • [edit system services dhcp-local-server dhcpv6 group group-name authentication username-include]
    • [edit system services dhcp-local-server group group-name authentication username-include]
  • Flat file output for service filter-based accounting—Starting in Junos OS Release 15.1F5, you can configure service-based accounting to output to a flat file, in either IPDR or CSV format, as defined by the accounting-options configuration statement. To configure flat file output for service-based accounting, use the new local flat-file-profile flat-file-profile-name configuration statement at the [edit access profile profile-name] hierarchy level. Next, add the new service-accounting configuration statement at the [edit accounting-options flat-file-profile flat-file-profile-name fields] hierarchy level. Then either add the new local configuration statement at the [edit access profile profile-name service accounting-order] hierarchy level, or use the existing activation-protocol configuration statement at the [edit access profile profile-name service accounting-order] hierarchy level and activate the service through a CLI configuration or command.
  • Support for maximum session limits on L2TP service interfaces (MX Series)—Starting in Junos OS Release 15.1F5, you can include the l2tp-maximum-session number statement at the [edit interfaces service-interface] hierarchy level to specify the maximum number of sessions that are allowed on an individual service interface (si). New session requests on an interface are accepted only when the session count is less than the maximum session limit. If the limit has been reached, subsequent requests are dropped and the LNS responds with a CDN message (Result Code 2, Error Code 4). When a pool of interfaces is configured, interfaces at the maximum limit are ignored in favor of an interface in the pool that has a lower session count.
  • Enhanced load balancing on L2TP physical service interfaces (MX Series)—Starting in Junos OS Release 15.1F5, when a service interface in a service device pool is rebooted, session reconnects and new session requests are distributed based on the number of sessions on the available interfaces in the pool. The sessions are assigned to the interface with the fewest sessions. If more than one interface has the minimum number of sessions, then a random selection determines which interface gets the session.

    In earlier releases, session load balancing is a simple round-robin distribution among the interfaces. Consequently, fewer sessions are assigned to a newly rebooted interface than to the other interfaces. For example, consider a pool with two si interfaces, si-0/0/0 and si-1/0/0. Each has 100 sessions. If si-1/0/0 reboots, it drops all 100 sessions. As the sessions reconnect, they alternate between the two interfaces so that when all sessions have reconnected, si-0/0/0 has 150 sessions and the reconnected si-1/0/0 interface has only 50 sessions.

    Consider the same pool with the new behavior. As sessions reconnect, si-1/0/0 has fewer sessions (0 to start) than si-0/0/0 (100). Because the interface with the fewest sessions is selected, all sessions are assigned to si-1/0/0 until it reaches the same count as si-0/0/0.

  • Support for username stripping per routing instance (MX Series)—Starting in Junos OS Release 15.1F5, you can configure a subscriber access profile so that a portion of each subscriber login string is discarded and the remaining characters are used as a modified username by an external AAA server for session authentication and accounting. The modified username appears in RADIUS Access-Request, Acct-Start, and Acct-Stop messages; RADIUS-initiated disconnect requests; and change of authorization (CoA) requests. This username stripping configuration replaces a domain map configuration, but can be overridden by a AAA server.

    Use the following statements at the [edit access profile profile-name session-options strip-user-name] hierarchy level to configure username stripping:

    • delimiter delimiter —Specify up to eight characters that the router uses to determine the boundary between the new modified username and the part of the original username that is discarded. There is no default delimiter.
    • parse-direction (left-to-right | right-to-left)—Specify the direction in which the login string is examined until one of the configured delimiters is identified; left-to-right is the default. The delimiter and all characters to the right of the delimiter are discarded.

    For example, consider a login string of drgt21@example.com$84 with the delimiters configured to be /@$%#. If the parse direction is left-to-right, the @ delimiter is reached first and the modified username is drgt21. If the parse direction is right-to-left, then the $ delimiter is reached first and the modified username is drgt21@example.com.

    Best Practice: We recommend that you do not configure username stripping either when multiple user authentications are needed or when a global domain map is configured for the same subscribers covered by the AAA options configuration.

    The show network-access aaa subscribers session-id id-number detail command displays the modified username in the Session Authentication Username field. The clear network-access aaa subscriber username username command requires you to specify the original, unstripped username (login string). The output of the show subscribers command displays the unstripped username, and when you issue the show subscribers user-name username command, you must specify the unstripped username.

  • AAA option sets to authorize and configure subscribers per routing instance to support username stripping (MX Series)—Starting in Junos OS Release 15.1F5, you can include one or more of the following statements at the new [edit access aaa-options aaa-options-name] hierarchy level to define a set of AAA options for a subscriber or set of subscribers that username stripping is applied to:
    • access-profile profile-name —Specify the name of the access profile that includes the username stripping configuration.
    • aaa-context aaa-context-name —Specify the logical-system:routing-instance that the subscriber session uses for AAA (RADIUS) interactions like authenticating and accounting.
    • subscriber-context subscriber-context-name —Specify the logical-system:routing-instance in which the subscriber interface is placed.

    Note: Only the default (master) logical system is supported.

    Use the aaa-options aaa-options-name statement at the [edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit ppp-options] hierarchy level to apply the attributes to PPP subscribers tunneled from the LAC to the LNS inline service interface.

    Alternatively, use the aaa-options aaa-options-name statement at the [edit access group-profile profile-name ppp-options] hierarchy level to apply the attributes to PPP subscribers tunneled from LACs that are members of the user group.

    Usernames are examined and modified according to the subscriber and AAA contexts specified in the option set. In the event of a conflict between option sets configured in both a group profile and a dynamic profile, the dynamic profile takes precedence.

  • Shared memory log supports filter-based debugging (MX Series)—Starting in Junos OS Release 15.1F5, Junos OS supports filter-based debugging using the shared memory log.

    Junos OS uses a shared memory space to store log entries for subscriber service daemons, such as jpppd, jdhcpd, jl2tpd, autoconfd, bbe-smgd, authd, cosd, and dfwd. You can display the shared memory log (shmlog) output using the show shmlog entries logname (logname | all) <filter filter> <flag-name flag> command.

    By default, shared memory logging is enabled. To disable the shmlog, at the [edit system services subscriber-management] hierarchy level, use the set overrides shmlog disable command

    By default, shmlog filtering is disabled. To enable shmlog filtering, at the [edit system services subscriber-management overrides] hierarchy level, use the set shmlog filtering enable command.

    To display shmlog output for all daemon logs, use the logname all option with the show shmlog entries command. To limit shmlog output to a specific daemon log, provide the daemon name after the logname option followed by an asterisk. For example, logname jpppd* or logname authd*.

    To filter shmlog output, use the filter filter option with the show shmlog entries logname (logname | all) command. To display a list of valid filters, use the show shmlog entries logname all ? command.

    You can also limit output to shmlog entries with specific flags, such as transmit-packets, configuration, sessionDb, and so on, using the flag-name flag option with the show shmlog entries logname (logname | all) command. To display a list of valid flags, use the show shmlog entries logname all flag-name ? command.

    To direct shmlog output to a file, at the [edit system services subscriber-management overrides] hierarchy level, use the set shmlog file <filename> command. To view shmlog output stored in a text file, use the show shmlog entries filename filename command.

  • Configurable session limits for L2TP (MX Series)—Starting in Junos OS Release 15.1F5, you can configure a limit on the maximum number of L2TP sessions allowed for the chassis, for all tunnels, for a tunnel-group, for a client group, and for a client. When the session limit is reached, no new sessions can be established until the number of current sessions drops below the configured limit. These configured session limits have no effect on the maximum supported chassis limits that are imposed through the Juniper Networks license.

    When an L2TP session request is initiated, the LNS checks whether the number of current active sessions is less than the configured limit in the following order: chassis > tunnel > tunnel group > session-limit group > client.

    At each level, when the count is less or when no limit is configured, the check passes and the LNS proceeds to check the next level. If all levels pass the check, the session can be established. If at any level the current session count is equal to the configured limit, then the LNS rejects the session request and does not check any other level. When the LNS rejects a session request for an existing tunnel, it returns a Call-Disconnect-Notify (CDN) message with a result code and error code both set to 4 in response to the ICRQ. When the rejected request is for a new tunnel, the tunnel is established but the session fails to come up, causing the tunnel to come down because it has no sessions.

    The LAC performs the same session limit check, but only for the chassis and tunnel levels. The LAC rejects requests by returning a PPP terminate message to the client.

    Use the maximum-sessions statement at any of the following hierarchy levels:

    • [edit access profile profile-name client client-name l2tp]
    • [edit services l2tp]
    • [edit services l2tp sessions-limit-group]
    • [edit services l2tp tunnel]
    • [edit services l2tp tunnel-group group-name]

    Use the following commands to monitor the number of active sessions compared to the configured maximums:

    • show services l2tp client—Display about all L2TP clients or a specific L2TP client.
    • show services l2tp session-limit-group—Display information about all session-limit groups or a specific session limit group.
    • show services l2tp summary—Display L2TP summary information, including sessions at the chassis level.
    • show services l2tp tunnel—Display information about all L2TP tunnels or a specific L2TP tunnel.
    • show services l2tp tunnel-group—Display information about all L2TP tunnel groups or a specific L2TP tunnel group.
  • Ensuring IPCP negotiation for IPv4 DNS addresses (MX Series)—Starting in Junos OS Release 15.1F5, the router can prompt customer premises equipment (CPE) to negotiate both primary and secondary IPv4 DNS addresses during IPCP negotiation. This feature is useful when the CPE fails to send DNS address options in the IPCP configure request message, or when the options are sent but rejected. In earlier releases, either situation results in no DNS address negotiation even though IPv4 DNS addresses are available on the router. This DNS option enables the router to control IPv4 DNS address provisioning for dynamic and static terminated PPPoE and LNS subscribers.

    Specify the DNS negotiation option with the ipcp-suggest-dns-option statement at one of the following hierarchy levels:

    • [edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” ppp-options]—Configure the router to prompt the CPE to negotiate the DNS addresses for dynamic PPPoE subscribers.
    • [edit interfaces interface-name ppp-options]—Configure the router to prompt the CPE to negotiate the DNS addresses for static PPPoE subscribers.
    • [edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit “$junos-interface-unit” ppp-options]—Configure the router to prompt the CPE to negotiate the DNS addresses for dynamic LNS subscribers.
    • [edit interfaces si-slot/pic/port unit logical-unit-number ppp-options]—Configure the router to prompt the CPE to negotiate the DNS addresses for static LNS subscribers.
    • [edit access group-profile profile-name ppp-options]—Configure the router to prompt the CPE to negotiate the DNS addresses for tunneled PPP subscribers with an LNS user group profile.
  • Dynamic subscriber and service management on statically configured interfaces (MX Series)—Starting in Junos OS Release 15.1F5, enhanced subscriber management supports dynamic service activation and deactivation for static subscribers. These static subscribers work with the native Juniper Networks Session and Resource Control (SRC), or you can configure RADIUS to activate and deactivate the services with change of authorization (CoA) messages. Note, however, that with RADIUS, authentication failure does not prevent the underlying interface from coming up and forwarding traffic. Instead, it prevents the subscriber from coming up, and thus service activation/deactivation. Authorization parameters such as IP addresses, net masks, policy lists, and QoS are also not imposed when using RADIUS.

    Use the following commands to provide administrative control of static subscribers:

    • request services static-subscribers login interface interface-name
    • request services static-subscribers logout interface interface-name
    • request services static-subscribers login group group-name
    • request services static-subscribers logout group group-name

    Use the following commands to monitor static subscribers:

    • show static-subscribers
    • show static-subscribers interface interface-name
    • show static-subscribers group group-name

VPNs

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

Related Documentation

Modified: 2016-09-29

Previous Page Next Page