Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

New and Changed Features

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

Hardware

  • SFPP-10G-DT-ZRC2 (MX Series)—Starting in Junos OS Release 14.2, the SFPP-10G-DT-ZRC2 tunable transceiver provides a duplex LC connector and supports the 10GBASE-Z optical interface specification and monitoring. The transceiver is not specified as part of the 10-Gigabit Ethernet standard and is instead built according to Juniper Networks specifications. The SFPP-10G-DT-ZRC2 transceiver supports WAN-PHY and LAN-PHY modes. To configure the wavelength on the transceiver, use the wavelength statement at the [edit interfaces interface-name optics-options] hierarchy level.

    The following interface modules support the SFPP-10G-DT-ZRC2 transceiver:

    MX Series MPCs and MICs:

    • 10-Gigabit Ethernet MIC with SFP+ (model number: MIC3-3D-10XGE-SFPP)—Supported in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1R1, and later
    • 16-port 10-Gigabit Ethernet MPC (model number: MPC-3D-16XGE-SFPP)—Supported in Junos OS Release 12.3R8, 13.2R5, 13.3R3, 14.1R2, 14.2, and later
    • 32-port 10-Gigabit Ethernet MPC4E (model number: MPC4E-3D-32XGE-SFPP)—Supported in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1R1, and later
    • 2-port 100-Gigabit Ethernet + 8-port 10-Gigabit Ethernet MPC4E (model number: MPC4E-3D-2CGE-8XGE)—Supported in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1R1, and later

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

    [See 10-Gigabit Ethernet 10GBASE Optical Interface Specifications, MX Series Interface Module Reference PDF Document, and wavelength.]

Authentication, Authorization and Accounting (AAA) (RADIUS)

  • RADIUS functionality over IPv6 for system AAA—Starting in Release 14.2, Junos OS supports RADIUS functionality over IPv6 for system AAA (authentication, authorization, and accounting) in addition to the existing RADIUS functionality over IPv4 for system AAA. With this feature, Junos OS users can log in to the router authenticated through RADIUS over an IPv6 network. Thus, Junos OS users can now configure both IPv4 and IPv6 RADIUS servers for AAA. To accept the IPv6 source address, include the source-address-inet6 statement at the [edit system radius-server ipv6] hierarchy level. (If an IPv6 RADIUS server is configured without any source-address-inet6, default ::0 is used as the source address.)

    [See Configuring RADIUS Authentication, and Configuring RADIUS System Accounting.]

Class of Service (CoS)

  • Support for user-configurable traffic class map (T4000 routers with Type 5 FPC)—Starting with Junos OS Release 14.2 introduces a user-configurable input priority map, known as a traffic class map, that helps prioritize and classify input traffic entering a Packet Forwarding Engine during ingress oversubscription. You can define traffic class maps for a packet on the basis of the following CoS code points:
    • Differentiated Services code point (DSCP) for IP DiffServ
    • IP precedence bits
    • MPLS EXP bits
    • IEEE 802.1p CoS bits
    • IEEE-802.1ad drop eligible indicator (DEI) bits

    You can associate the traffic class map to one of the following traffic classes:

    • Real time
    • Network control
    • Best effort

    [See Configuring Traffic Class Maps.]

  • Source class accounting (T4000)—Starting with Junos OS Release 14.2, the source class accounting is performed at the ingress on a T4000 Type 5 FPC in T4000 routers.

    [See Understanding Source Class Usage and Destination Class Usage Options.]

  • Increased per-VC bandwidth speed on ATM MIC with SFP (MX Series with MPCs and ATM MIC with SFP)—Starting in Junos OS Release 14.2, you can configure constant bit rate (CBR) bandwith speeds up to 622 Mbps (OC12) per virtual circuit (VC) on an MX Series router with an ATM MIC with SFP (model number MIC-3D-8OC3-2OC12-ATM) and a supported MPC installed. In earlier Junos OS releases, you could configure per-VC CBR bandwidth speeds only up to 155 Mbps (OC3) on an ATM MIC with SFP.

    With the increased per-VC CBR bandwidth speed, each VC can support up to line rate traffic in OC12 mode, subject to the following restrictions:

    • You must configure the CBR service category when you define the ATM traffic shaping and scheduling profile.

      For other ATM service categories including variable bit rate nonreal time (VBR-NRT), variable bit rate real time (VBR-RT), and unspecified bit rate (UBR), the per-VC bandwidth speed for an ATM MIC with SFP remains a maximum of 155 Mbps.

    • The actual Layer 3 payload throughput you obtain depends on the ATM encapsulation type and IP packet size you use.

    [See CoS on Circuit Emulation ATM MICs Overview.]

  • Support for packet marking schemes on a per-customer basis (MX Series)—Traditionally, packet marking in Junos OS uses the forwarding class and loss priority determined from a BA classifier or multifield classifier. This approach does not allow for direct assignment of rewrite rules on a per-customer basis due to the limited number of combinations of forwarding class and loss priority.

    Beginning with Junos OS Release 14.2R3, there is a packet marking scheme, called policy map, that allows the definition of rewrite rules on a per-customer basis. Policy maps are defined at the [edit class-of-service policy-map] hierarchy level and can be assigned to a customer through a firewall action, an ingress interface, or a routing policy.

General Routing

  • Configurable TCP MSS value (MX Series)—Starting in Junos OS Release 14.2, you can configure the TCP MSS value on MX Series routers. To specify a TCP MSS value, include the tcp-mss statement at the [edit interfaces interface-name unit logical-unit-number family family] hierarchy level.
  • Configuring routing process mode (MX Series)— Starting in Junos OS Release 14.2, you can configure routing process mode to 64-bit mode or 32-bit mode.

    [See routing.]

High Availability (HA) and Resiliency

  • Support for Ethernet alarm indication signal (MX Series)—Starting with Junos OS Release 14.2, ITU-T Y.1731 Ethernet alarm indication signal function (ETH-AIS) is supported on MX Series routers. ETH-AIS provides fault management for service providers where it enables the service provider to suppress alarms when a fault condition is detected. Using ETH-AIS, you can differentiate faults at the customer level and faults at the provider level. When a fault condition is detected, a maintenance end point (MEP) generates and transmits ETH-AIS packets to the configured router for a specified duration until the fault condition is cleared. An MEP that is configured to generate ETH-AIS packets transmits the signals to a level higher than its own. Therefore, the MEP receiving ETH-AIS packets recognizes that the fault is at a lower level and suppresses alarms at its own level.

    MX Series routers support ETH-AIS protocol data unit (PDU) generation for server MEPs on the basis of the following defect conditions:

    • Loss of connectivity (physical link loss detection)
    • Layer 2 circuit or Layer 2 VPN down

    [See Ethernet Alarm Indication Signal (ETH-AIS) Function Overview.]

  • MX Series Virtual Chassis support for logical systems (MX Series with MPCs)—Starting in Junos OS Release 14.2, MX Series Virtual Chassis configurations support the use of logical systems. A logical system independently performs a subset of the tasks performed by the main router and has a unique routing table, and unique interfaces, policies, and routing instances. In earlier Junos OS releases, MX Series Virtual Chassis configurations do not support the logical systems feature.

    To configure routing policies or enable a protocol such as OSPF when you are using logical systems with an MX Series Virtual Chassis, you must include routing policy configuration statements at the [edit logical-systems logical-system-name policy-options] hierarchy level, and protocol configuration statements at the [edit logical-systems logical-system-name protocols] hierarchy level.

    [See Introduction to Logical Systems.]

  • MX Series Virtual Chassis support on MS-MPCs (MX Series with MS-MPCs)—Starting in Junos OS Release 14.2, you can configure a two-member MX Series Virtual Chassis to use the stateful firewall advanced service on MX240, MX480, or MX960 routers with Multiservices MPCs (MS-MPCs) and Multiservices MICs (MS-MICs) installed. A two-member MX Series Virtual Chassis configuration supports a maximum of four MS-MPCs and four MS-MICs per Virtual Chassis.

    In earlier Junos OS releases, MX240, MX480, and MX960 routers did not support MS-MPCs or MS-MICs in MX Series Virtual Chassis configurations.

  • Support for MS-MPC on SCBE2 (MX Series)—Starting with Junos OS Release 14.2R2, MS-MPC is supported on SCBE2 on MX240, MX480, and MX960 routers.
  • MX Series Virtual Chassis support for MX2010 and MX2020 member routers (MX Series with MPCs/MICs)—Starting in Junos OS Release 14.2R2, 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.

  • Enhancements made to unified ISSU for VRRPv3 to avoid adjacency flap (M Series and MX Series)—Starting in Junos OS Release 14.2R2, 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.

Interfaces and Chassis

  • Unified in-service software upgrade support—Starting with Junos OS Release 14.2, unified in-service software upgrade (unified ISSU) is supported on the following MICs:
    • Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP
    • Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP
    • Channelized E1/T1 Circuit Emulation MIC
    • DS3/E3 MIC
  • Support for inline active flow monitoring (T4000 routers with T4000-FPC5-3D)—Beginning with Release 14.2, Junos OS supports inline active flow monitoring services on T4000 routers with T4000-FPC5-3D. Inline active flow monitoring is implemented on the Packet Forwarding Engine. Inline active flow monitoring supports version 9 and IPFIX flow collection templates.

    [See Configuring Inline Active flow Monitoring.]

  • New command to set the license mode for MPCs (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 14.2, you can set the license mode for enhanced MPCs such as MPC4E, MPC5E, and MPC6E by including the ir-mode configuration statement at the [edit chassis fpc] hierarchy level. Setting the license mode enables you to distinguish between an MPC with an IR license and an MPC with an R license after the MPC is installed on the router.

    Note: You cannot set or alter the license of the MPC when you configure the mode. The license mode settings are used only to provide information.

    The license mode settings are set per slot. If the MPC is installed on a different slot, or moved to another device, the license mode settings must be re-configured on the new slot or device. Also, the license mode settings configured on the previous slot must be removed. To view the current license mode settings, as well as the effect of the new settings, use the show chassis fpc and show chassis hardware extensive commands. To delete the license mode settings, use the delete chassis fpc command.

  • Supported for mixed-mode aggregated Ethernet (MX Series)—Starting with Junos OS Release 14.2, support for mixed aggregated Ethernet bundles is extended to MX240, MX480, MX960, MX2010, and MX2020 routers, thereby enabling you to configure the MPC-based member links with any combination of rates—10-Gigabit Ethernet, 40-Gigabit Ethernet, and 100-Gigabit Ethernet—on an aggregated Ethernet interface.

    [See Understanding Mixed Rates and Mixed Modes on Aggregated Ethernet Bundles.]

  • Support for MPC5E on SCBE2 (MX Series)—Starting with Junos OS Release 14.2, MPC5E is supported on SCBE2 on the MX240, MX480, and MX960.
  • Entropy label support in mixed mode (MX Series)—Beginning with Junos OS Release 14.2, the entropy label is supported in mixed mode for chassis. MX Series 3D Universal Edge Router DPCs support the pop-out entropy label but do not support the flow label. The entropy label can be configured without enhanced-ip configuration.
  • Support for private VLAN (MX240, MX480, and MX960)—Starting with Junos OS Release 14.2, you can configure a private VLAN on a single MX Series router to span multiple MX Series routers. VLANs limit broadcasts to specified users. Private VLANs take this concept a step further by limiting communication within the VLAN. Private VLANs accomplish this limitation by restricting traffic flows through their member switch ports (which are called private ports) so that these ports communicate only with a specified uplink trunk port or with specified ports within the same VLAN. The uplink trunk port (or link aggregation group or LAG) is usually connected to a router, firewall, server, or provider network. Each private VLAN typically contains many private ports that communicate only with a single uplink, thereby preventing the ports from communicating with each other. Private VLANs provide Layer 2 isolation between ports within the same VLAN, splitting a broadcast domain into multiple isolated broadcast subdomains and essentially putting secondary VLANs inside another primary VLAN.

    You can configure an isolated VLAN within a private VLAN that spans multiple switches by including the isolated-vlan vlan-id statement at the [edit bridge-domains bridge-domain-name] hierarchy level. You configure an interface to be the trunk port, connecting routers that are configured with a private VLAN across these routers by including the interface-mode trunk inter-switch-link statement at the [edit interfaces ethernet-interface-name unit logical-unit-number family bridge] hierarchy level. The private VLAN trunk port is a member of all the VLANs within the private VLAN (that is, the primary VLAN, the community VLANs, and the interswitch isolated VLAN). It can communicate with all ports other than the isolated ports. You configure a community VLAN, which is a secondary VLAN that transports frames among community interfaces within the same community and forwards frames upstream to the primary VLAN, by specifying a list of VLAN IDs separated by spaces by including the community-vlan vlan-ids statement at the [edit bridge-domains bridge-domain-name] hierarchy level.

    This functionality is supported only on MX240, MX480, and MX960 routers that function in enhanced LAN mode (by entering the network-services lan statement at the [edit chassis] hierarchy level).

  • Port-based network access control (MX240, MX480, and MX960)—Starting in Junos OS Release 14.2, support is implemented for controlling access to your network through an MX Series router by using several different authentication methods, by configuring 802.1X, MAC RADIUS, or a captive portal. This functionality is supported on an MX Series Virtual Chassis combination that functions in enhanced LAN mode (by entering the network-services lan statement at the [edit chassis] hierarchy level). Port-based network access control is supported on MX240, MX480, and MX960 routers with MPCs in both the MX-LAN mode and the non-MX-LAN mode (with other supported network services modes on MPCs on these routers). To configure the IEEE 802.1x Port-Based Network Access Control protocol on Ethernet interfaces, you must configure the authenticator statement at the [edit protocols authentication-access-control] hierarchy level. You can also configure captive portal authentication on a router so that users connected to the switch are authenticated before being allowed to access the network. You can also configure Junos Pulse Access Control Service as the access policy to authenticate and authorize users connected to the switch for admission to the network and for access to protected network resources by using the uac-policy statement.
  • MAC RADIUS authentication (MX Series routers with DPCs and MPCs)—Starting in Junos OS Release 14.2, on MX Series routers with MPCs and DPCs, you can permit devices that are not 802.1X-enabled LAN access by configuring MAC RADIUS authentication on the MX Series router interfaces to which the hosts are connected. You can also allow non-802.1X-enabled devices to access the LAN by configuring their MAC address for static MAC bypass of authentication. You can configure MAC RADIUS authentication on an interface that also allows 802.1X authentication, or you can configure either authentication method alone. Include the mac-radius flap-on-disconnect statement at the [edit protocols dot1x authenticator interface interface-name] hierarchy level to cause the router to reset the interface on which the supplicant is authenticated when the RADIUS server sends a disconnect message to a supplicant. If the interface is configured for multiple supplicant mode, the switch resets all the supplicants on the specified interface. This option takes effect only when the restrict option is also set. To restrict authentication to MAC RADIUS only, include the mac-radius restrict statement at the [edit protocols dot1x authenticator interface interface-name] hierarchy level. In restrictive mode, all 802.1X packets are eliminated and the attached device on the interface is considered a nonresponsive host.

    If both MAC RADIUS and 802.1X authentication are enabled on the interface, the switch first sends the host three EAPOL requests to the host. If there is no response from the host, the switch sends the host’s MAC address to the RADIUS server to check whether it is a permitted MAC address. If the MAC address is configured as permitted on the RADIUS server, the RADIUS server sends a message to the switch that the MAC address is a permitted address, and the switch opens LAN access to the nonresponsive host on the interface to which it is connected.

  • Support for MACsec (MX Series)—Starting in Junos OS Release 14.2R2, 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 or static secure association key (SAK) 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 in both enhanced LAN mode (by entering the network-services lan statement at the [edit chassis] hierarchy level) and in non-enhanced LAN mode.

    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. MACsec is not supported with unified ISSU. After a unified ISSU operation is completed, an FPC reboot is required for MACSec to work. If you upgrade a router from an earlier Junos OS release to Release 14.2R2 using unified ISSU and MACsec is configured on that router, you must reboot the FPC for MACsec to function properly.

  • Support for fabric black-hole detection and recovery (TX Matrix Plus)—Starting in Junos OS Release 14.2, TX Matrix Plus routers can detect and recover from fabric faults that are not caused by hardware failure.

    To recover from a fabric black-hole condition, the routing matrix uses the following options:

    • SFC SIB Reboot
    • LCC SIB Reboot
    • FPC Reboot
    • Destination Reprogramming
    • Interchassis Link Retraining

    You can disable the automatic recovery feature by using the auto-recovery-disable statement at the [edit chassis fabric degraded] hierarchy level. You can also turn the FPC offline by using the fpc-offline-on-blackholing statement at the [edit chassis fabric degraded] hierarchy level if nonrecoverable errors are present in the routing matrix.

    [See fpc-offline-on-blackholing and auto-recovery-disable.]

  • Support for inclusion of element IDs 54 and 64 in IPFIX templates (MX Series)—Starting with Junos OS Release 14.2, the following attributes can be contained in IPFIX flow templates that are sent to the flow collector:
    • fragmentIdentification (element ID 54)
    • ipv6ExtensionHeaders (element ID 64)

    To enable the inclusion of element ID 54 and element ID 64, IPFIX flow templates that are exported to the flow collector, include the ipv6-extended-attrib statement at the [edit chassis fpc slot-number inline-services flow-table-size] hierarchy level. Collection of IPv4 fragmentation IDs occurs automatically without having to configure this setting explicitly.

  • Enhanced Y.1731 functionality on VPWS to support ETH-LM for dual VLAN tags (MX Series)–Staring with Release 14.2, Junos OS supports Ethernet frame loss measurement (ETH-LM) between maintenance association end points (MEPs) configured on Ethernet physical or logical interfaces on Rev-B Dense Port Concentrators (DPCs) in MX Series routers. Additionally, the Y.1731 functionality supports ETH-LM only for an end-to-end connection that uses Virtual Private Wire Service (VPWS). Prior to Junos OS Release 14.2, this functionality did not support ETH-LM for dual VLAN identifier tags. It only supported ETH-LM for untagged or single VLAN identifier tags. Starting with Junos OS Release 14.2, the Y.1731 functionality supports ETH-LM on VPWS for dual VLAN identifier tags as well.
  • Support for enhanced link aggregation group on (MX Series routers with MPCs)—Starting in Junos OS Release 14.2, you can configure an enhanced link aggregation group (LAG) on MX Series routers. When you associate a physical interface with an aggregated Ethernet interface, the physical child links are also associated with the parent aggregated Ethernet interface to form a LAG.

    In the absence of enhanced LAG support, one child next hop is created for each member link of an aggregated Ethernet interface for each VLAN interface. For example, an aggregate next hop for an aggregated Ethernet interface with 16 member links leads to the installation of 17 next hops per VLAN created. Thus the number of next hops supported on the routers with aggregated Ethernet interfaces is significantly reduced.

    With the enhanced LAG support, when the set chassis network-services enhanced-ip statement is configured, child next hops are not created for member links and, as a result, a higher number of next hops can be supported.

  • Support for physical interface damping (M Series and MX Series )—Beginning with Junos OS 14.2, interface damping is supported on physical interfaces to address longer periodic flapping lasting 5 seconds or more, with an up and down duration of one second. This damping method limits the number of advertisements of longer interface up and down events to the upper-level protocols. For longer periodic interface flaps, configure interface damping with the damping statement at the [edit interfaces interface-name] hierarchy level. You use the show interfaces extensive command to view the interface damping values and link state.

    [See Damping Longer Physical Interface Transitions.]

  • Ethernet ring protection switching (MX Series)—Starting with Junos OS Release 14.2, MX Series routers support Ethernet ring protection switching (ERPS) which is defined in ITU-T Recommendation G.8032/Y.1344 version 2. ERPS comprises the following features:
    • G.8032/Y.1344 version 2 compliant protocol state-machine with the new FDB flush mechanism
    • Support for revertive and nonrevertive mode of operation of the Ethernet ring
    • Support for manual commands such as manual switch, force switch, and clear commands
    • Support for configurable wait-to-restore, wait-to-block, and guard timers
    • Support for multiple logical ring instances on the same physical ring
    • Support for ring interconnection using non-virtual-channel mode. Ring interconnection using virtual channel mode is not supported.
    • Support for ring ID values from 1 through 239
    • Support for ring protection link neighbor node
    • Support for topology change propagation from a sub-ring to an interconnected major ring
    • Ability to add a node or remove a node from the Ethernet ring

    [See Understanding Ethernet Ring Protection Switching Functionality.]

  • MS-MIC support (MX104)—Starting in Junos OS Release 14.2, the Multiservices MIC (MS-MIC-16G) is supported on MX104 3D Universal Edge Routers. The MS-MIC has an enhanced memory of 16 GB and provides improved scaling and high performance. The MX104 chassis is capable of supporting two MS-MICs.

    The MS-MIC supports the following software features:

    • Active flow monitoring exports flow monitoring version 9 records, based on RFC 3954
    • IPsec encryption
    • Network Address Translation (NAT) for IP addresses
    • Port Address Translation (PAT) for port numbers
    • Real-time performance monitoring
    • Stateful firewall with packet inspection which detects SYN attacks, ICMP and UDP floods, and ping-of-death attacks
    • Traffic sampling

    [See Multiservices MIC.]

  • Support for hold-off timing synchronization (MX Series)—Starting in Junos OS Release 14.2, you can configure hold-off time for Synchronous Ethernet interfaces and external clock synchronization sources to prevent rapid successive switching. If an interface goes down, hold-off time delays short signal failures from being sent to the clock selection process.

    If you configure hold-off time when quality level (QL) mode is enabled, the configured quality level is used in the clock selection process during the hold-off time period. After the hold-off time period ends, a signal failure is sent to the clock selection process.

    To configure hold-off time, include the hold-off-time statement at the [set chassis synchronization source interfaces (external-a | external-b | interface interface-name)] hierarchy level.

    [See Understanding Clock Synchronization on MX Series Routers.]

  • Support for Synchronous Ethernet on MPC5E and MPC6E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 14.2, Junos OS extends Synchronous Ethernet support to MPC5E and MPC6E on the MX240, MX480, MX960, MX2010, and MX2020 routers. MPC5E-40G10G, MPC5EQ-40G10G, MPC5E-100G10G, MPC5EQ-100G10G, and MX2K-MPC6E support Ethernet Synchronization Messaging Channel (ESMC) and external clocking.

    To configure Synchronous Ethernet, include the synchronization statement and its substatements at the [edit chassis] hierarchy level.

  • Support for REST interfaces (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.2, M Series, MX Series, and T Series routers support REST interfaces for secure connection to Junos OS devices and execution of remote procedure calls, a REST API Explorer GUI enabling you to conveniently experiment with any of the REST APIs, and a variety of formatting and display options, including JSON support.

    [See REST API Guide.]

  • Aggregated Ethernet-specific naming for logical systems—Starting in Junos OS Release 14.2, aggregated Ethernet interfaces created under a logical system can be individually named. Prior to Release 14.2, aggregated Ethernet interfaces were named automatically, AE1, AE2, and so on, upon setting the device count, and system resources were allocated for each aggregated Ethernet interface regardless of whether it was used or not. This change allows administrators to use whatever naming scheme makes sense in the context of their deployment and is more efficient in the allocation of system resources.
  • Increase available bandwidth by bypassing the queuing chip (MX240, MX480, MX960, MX2010, MX2020)—On MPC1 Q, MPC1E Q, MPC2 Q, MPC2 EQ, MPC2E Q, MPC2E EQ, and MPC5E Q line cards, starting with Junos OS Release 14.2, when hierarchical and per-VLAN queuing features are not required, you can bypass the queuing chip to increase the available bandwidth on an interface. You can bypass the queuing chip by enabling the bypass-queuing-chip statement at the [edit interfaces interface-name] hierarchy level.

    [See Increase Available Bandwidth on Rich-Queuing MPCs by Bypassing the Queuing Chip.]

  • Configuration support to keep an MC-LAG aggregated Ethernet link up for a peer with limited LACP capability—Starting with Junos OS Release 14.2, you can configure an aggregated Ethernet link or interface in an MC-LAG topology to remain up even when the peer link or peer interface has limited Link Access Control Protocol (LACP) capability.

    To configure this feature, configure the force-up statement at the [edit interfaces interface-name aggregated-ether-options lacp] hierarchy level.

  • Load balancing for ECMP next hops (MX Series)—Starting with Junos OS Release 14.2, the following load-balancing solutions are supported on equal-cost multipath (ECMP) next hops to correct traffic imbalance among the member links:
    • Adaptive — Uses real-time feedback and control mechanism to monitor and manage traffic imbalances.
    • Random spray — Packet random spray load balancing randomly sprays the packets to the aggregate next hops to ensure that the next hops are equally loaded.

    To configure adaptive load balancing use the ecmp-alb statement at the [edit chassis] hierarchy level. However, to configure adaptive load balancing, make sure that the per-packet statement is enabled at the [edit policy-options policy-statement policy_name then load-balance] hierarchy level. To configure random load balancing, use the random statement at the [edit policy-options policy-statement policy_name then load-balance] hierarchy level.

  • Enhanced Y.1731 functionality on VPWS to support ETH-LM for dual VLAN tags (MX Series)—Starting with Release 14.2, Junos OS supports Ethernet frame loss measurement (ETH-LM) between maintenance association end points (MEPs) configured on Ethernet physical or logical interfaces on Enhanced Dense Port Concentrators (DPCEs) in MX Series routers. The Y.1731 functionality supports ETH-LM only for an end-to-end connection that uses Virtual Private Wire Service (VPWS). In releases before Release 14.2, Junos OS supports ETH-LM only for untagged or single-tagged VLAN identifiers. Starting with Junos OS Release 14.2, ETH-LM is supported on VPWS for dual VLAN identifier tags as well.

    [See Ethernet Frame Loss Measurement Overview.]

  • Support for interface damping for longer periodic interface flaps (MX960, MX480, MX240, MX80 3D Universal Edge Routers and M10i Multiservice Edge Routers)—Starting with Junos OS Release 14.2, interface damping is supported on physical interfaces to address longer periodic flapping lasting 5 seconds or more, with an up and down duration of 1 second. This damping method limits the number of advertisements of longer interface up and down events to the upper-level protocols. For longer periodic interface flaps, configure interface damping by using the damping statement at the [edit interfaces interface-name] hierarchy level. You use the show interfaces extensive command to view the interface damping values and link state.

    [See Damping Longer Physical Interface Transitions.]

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

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

  • Provide egress VLAN ID and direction information in sampling records (MX Series)—Starting in Release 14.2R2 , Junos OS includes egress VLAN ID and flow direction information in output records and, optionally, flow keys, when you perform sampling using the IPFIX or version 9 templates.
    • VLAN ID used for single-tagging is output to field 58, Vlan Id.
    • VLAN IDs used for dual-tagging (QinQ) are output to fields 243, Dot1q Vlan Id, and 245, Dot1q Customer Vlan Id. (IPFIX template only)
    • To put one or two Vlan IDs in the flow key of the output record, include the vlan-id option at the [edit services flow-monitoring version-ipfix template template-name flow-key] or [edit services flow-monitoring version9 template template-name flow-key] hierarchy level.
    • To put flow direction in the flow key of the output record, include the flow-direction option at the [edit services flow-monitoring version-ipfix template template-name flow-key] or [edit services flow-monitoring version9 template template-name flow-key] hierarchy level.
    • The flow direction field in the output record contains an initial value of 0xFF. The field contains 0x00 (ingress) or 0x01 (egress) only when you include the flow-direction vlan-id option at the [edit services flow-monitoring version-ipfix template template-name flow-key] or [edit services flow-monitoring version9 template template-name flow-key] hierarchy level.

    Note: In Junos OS releases earlier than Release 14.2R2, only ingress VLAN IDs were reported in flow records.

    [See Configuring Flow Aggregation to Use IPFIX Flow Templates and Configuring Flow Aggregation to Use Version 9 Flow Templates.]

  • Support for ITU-T Y.1731 ETH-LM, ETH-SLM, and ETH-DM on aggregated Ethernet interfaces (MX Series routers with MPCs)—Starting in Junos OS Release 14.2R3, you can configure ITU-T Y.1731 standard-compliant Ethernet loss measurement (ETH-LM), Ethernet synthetic loss measurement (ETH-SLM), and Ethernet delay measurement (ETH-DM) capabilities on aggregated Ethernet (ae) interfaces. These performance monitoring functionalities are supported on MX Series routers with MPCs, where the same level of support for the Ethernet services OAM mechanisms as the level of support on non-aggregated Ethernet interfaces is available on aggregated Ethernet interfaces. ETH-DM is supported on MPC3E and MPC4E modules with only software timestamping. ETH-SLM is supported on MPC3E and MPC4E modules.
  • Configuration support to improve MC-LAG Layer 2 and Layer 3 convergence (MX Series)—Starting with Junos OS Release 14.2R3, you can configure multichassis link aggregation (MC-LAG) interfaces to improve Layer 2 and Layer 3 convergence time to subsecond values when a multichassis aggregated Ethernet link goes down or comes up in a bridge domain.

    To use this feature, ensure that the interchassis link (ICL) is configured on an aggregated Ethernet interface. For Layer 2 convergence, configure the enhanced-convergence statement at the [edit interfaces aeX aggregated-ether-options mc-ae] hierarchy level. For Layer 3, configure the enhanced-convergence statement at the [edit interfaces irb unit unit-number] hierarchy level for an integrated routing and bridging (IRB) interface.

    Note:

    • If the enhanced-convergence feature is configured on a multichassis aggregated Ethernet interface of a bridge domain that has an IRB interface, the IRB interface must also be configured for the convergence feature.
    • All multichassis aggregated Ethernet interfaces that are part of a bridge domain must be configured for enhanced convergence in order to utilize this feature on any of them.
    • On enabling or disabling the enhanced convergence feature, all services get deleted and re-created.

    [See Configuring Active-Active Bridging and VRRP over IRB in Multichassis Link Aggregation on MX Series Routers.]

  • LACP hold-up timer configuration support on LAG interfaces—Starting with Junos OS Release 14.2R3, you can configure a Link Aggregation Control Protocol (LACP) hold-up timer value for link aggregation group (LAG) interfaces.

    You configure the hold-up timer to prevent excessive flapping of a child (member) link of a LAG interface due to transport layer issues. With transport layer issues, it is possible for a link to be physically up and still cause an LACP state-machine flap. An LACP state-machine flapping can adversely affect traffic on the LAG interface. To prevent this, a hold-up timer value is configured. LACP monitors the PDUs received on the child link for the configured time value, but does not allow the member link to transition from the expired or defaulted state to current state. This configuration thus prevents excessive flapping of the member link.

    To configure the LACP hold-up timer for LAG interfaces, use the hold-time up timer-value statement at the [edit interfaces ae aeX aggregated-ether-options lacp] hierarchy level.

  • CFP-100GBASE-ZR (MX Series)—In Junos OS Release 14.2R3 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 14.2R7, 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 statements at the [edit chassis] hierarchy level.

IPv4

  • IPv4 address conservation method for hosting providers (MX Series)—Starting in Junos OS Release 14.2R4, you can configure a static route on an IRB interface with or without pinning to a specific underlying interface, thereby conserving the usage of IP address space.

    When a customer needs servers to be assigned within a block of IP addresses, several IP addresses are consumed. These include the network and broadcast IP addresses, the addresses for the router gateway that the servers are connected to, and the addresses of the individual servers. When this effect is multiplied across thousands of hosting providers, IP address space is far from being used efficiently.

    This issue can be resolved by configuring the interface on the router with an address from the reserved IPv4 prefix for shared address space (RFC 6598) and by using static routes pointed at the interface. IANA has recorded the allocation of an IPv4 /10 for use as shared address space. The shared address space address range is 100.64.0.0/10.

    This way, the interface in the router is allocated an IP address from the shared address space, so it is not consuming publicly routable address space, and connectivity is handled with static routes on an interface. The interface in the server is configured with a publicly routable address, but the router interfaces are not. Network and broadcast addresses are consumed out of the shared address space rather than the publicly routable address space.

IPv6

  • IPv6 support for next-hop groups (MX Series)—Starting in Junos OS Release 14.2, this feature allows support of next-hop groups of type inet6 (IPv6). The following features are also supported:
    • Configuration of interfaces of inet6 (IPv6) type at the [edit forwarding-options port-mirroring family inet6 output] hierarchy level or subgroups at the [edit forwarding-options port-mirroring family inet6 output next-hop-group] hierarchy level.
    • Configuration of next-hop groups as filter action.
    • Configuration of next-hop groups as port-mirror destination when specified at the [edit forwarding-options port-mirroring family inet6 output] hierarchy level.

    [See next-hop-group, port-mirroring, and [edit firewall] Hierarchy Level.]

Junos Fusion

  • Junos Fusion (MX Series)—Starting with Release 14.2, Junos Fusion is supported on MX Series routers. For Junos Fusion related information, see New and Changed Features for Junos Fusion.

Layer 2 Features

  • Egress protection service mirroring for BGP-signaled Layer 2 service (MX Series)— Starting in Junos OS Release 14.2, this feature enables BGP-signaled multihomed l2vpn to restore egress traffic in the following scenarios:
    • PE to CE link failure
    • Egress PE node failure

    [See Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services, Example: Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services, and host-standby.]

  • Create multiple pseudowires on a per-virtual circuit basis (MX Series)—Starting in Junos OS Release 14.2, you can create multiple pseudowires between the same pair of PEs in LDP-VPLS for a single routing instance, using the same loopback address. Do this with the vpls-id-list option under LDP-VPLS neighbor. For each pseudowire created under a neighbor, VPLS creates a VT/LSI interface and adds both it and the label route to the mpls.0 table. Each pseudowire terminates in its specified mesh-group. Support is added at the following CLI hierarchy level: [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address pseudowire-status-tlv vpls-id-list vc-id-numbers vc-id-number].

    [See the vpls-id-list command reference.]

  • Native analyzer support (MX240, MX480 and MX960)—Starting with Junos OS Release 14.2, MX Series routers support native analyzers and remote port-mirroring capabilities. A native analyzer configuration contains both an input stanza and an output stanza in the analyzer hierarchy for mirroring packets. In remote port mirroring, the mirrored traffic is flooded into a remote mirroring VLAN that can be specifically created for the purpose of receiving mirrored traffic. The analyzer configuration is available at the [edit forwarding-options analyzer] hierarchy level.

Layer 2 VPN

  • Control word feature for LDP VPLS and FEC129 VPLS (MX Series)— Starting with Junos OS Release 14.2R4, the control word feature is supported for LDP VPLS and FEC129 VPLS.

Management

  • YANG module that defines the Junos OS configuration hierarchy—Starting with Junos OS Release 14.2, Juniper Networks provides a YANG module that defines the Junos OS configuration hierarchy. You can download the YANG module that defines the complete Junos OS configuration hierarchy for all devices running that Junos OS release from the Juniper Networks website at http://www.juniper.net/. You can also generate a YANG module that defines the device-specific configuration hierarchy by using the show system schema module configuration format yang operational mode command on the local device. The Juniper Networks YANG module, configuration, is bound to the namespace URI http://yang.juniper.net/yang/1.1/jc and uses the prefix jc.

    [See Understanding YANG on Devices Running Junos OS.]

MPLS

  • On-demand packet loss and delay measurement (MX Series routers with MPCs and MICs only)—Starting with Release 14.2, Junos OS introduces an on-demand tool to monitor and measure packet loss, packet delay, or both for associated bidirectional MPLS ultimate hop popping (UHP) point-to-point label-switched paths (LSPs), using the monitor mpls loss rsvp, monitor mpls delay rsvp, and monitor mpls loss-delay rsvp commands, respectively.

    These commands provide an on-demand summary of performance metrics for direct mode packet loss, two-way packet delay, and related metrics, such as inter-packet delay variation and channel throughput measurement.

    This functionality provides real-time visibility into network performance, thereby facilitating network performance planning, troubleshooting, and evaluation.

  • GMPLS RSVP-TE VLAN LSP signaling (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.2, the point-to-point Layer 2 connectivity between two client routers across an external or third-party server-layer network can be set up by the client routers on an on-demand basis using GMPLS RSVP-TE signaling. This feature provides the client routers the flexibility to establish, maintain, and provision each individual Layer 2 connection, without any dependency on the server-layer administration. As a result, the burden on the operational expenses of the provider network, in terms of provisioning individual Layer 2 connections, is reduced.

    In traditional Layer 2 VPN technology that is based on LDP and BGP, the provider network handled the provisioning activity for each Layer 2 circuit established between two client routers.

    [See GMPLS RSVP-TE VLAN LSP Signaling Overview and Example: Configuring GMPLS RSVP-TE VLAN LSP Signaling.]

  • Extension of traceroute over MPLS tunnels—Starting with Junos OS Release 14.2, a new command as of Junos OS Release 14.2, traceroute mpls bgp, enables you to perform end-to-end LSP traceroute by having the transit routers provide information to the ingress router about the start and ending of new tunnels for the following cases:
    • For hierarchical LSPs for the following use cases:
      • LBGP over LDP (traceroute explores all ECMP paths)
      • LBGP over RSVP (traceroute explores all ECMP paths)
      • LDP over RSVP (traceroute explores all ECMP paths)
      • RSVP over BYPASS
    • For stitched LSP case for LDP stitched to labeled BGP

    The mechanism by which this is accomplished is explained in RFC 6424, which extends RFC 4370. Use traceroute mpls bgp as a debugging tool to locate MPLS BGP forwarding issues in a network. The traceroute mpls bgp command is supported on all platforms.

    [See traceroute mpls bgp.]

  • Dynamic bandwidth management using container LSPs (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.2, a new type of LSP, called a container LSP, is introduced to enable load balancing across multiple point-to-point member LSPs between the same ingress and egress routers. Each member LSP takes a different path to the same destination and can be routed along a different IGP cost path.

    Based on the configuration and aggregate traffic, a container LSP provides support for dynamic bandwidth management by enabling the ingress router to dynamically add and remove member LSPs through a process called LSP splitting and LSP merging respectively. Member LSPs can also be re-optimized with different bandwidth values in a make-before-break way.

    [See Dynamic Bandwidth Management Using MP-LSP Overview and Example: Configuring Dynamic Bandwidth Management Using MP-LSP.]

  • Egress peer engineering of service labels (BGP, MPLS) and egress peer protection for BGP-LU (MX Series)—Beginning with Junos OS Release 14.2R4, you can enable traffic engineering of service traffic, such as MPLS LSP traffic between autonomous systems (ASs), using BGP-labeled unicast for optimum utilization of the advertised egress routes. You can specify one or more backup devices for the primary egress AS boundary router. Junos OS installs the backup path in addition to the primary path in the MPLS forwarding table, which enables MPLS fast reroute (FRR) when the primary link fails.
  • Support of Internet draft draft-ietf-pce-stateful-pce-07 for the stateful PCC implementation (M Series, 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, this implementation is upgraded to support version 7, as defined in Internet draft draft-ietf-pce-stateful-pce-07.

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

  • Support of Internet draft draft-crabbe-pce-pce-initiated-lsp-03 for the stateful PCE-initiated LSP implementation (M Series, 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, this implementation is upgraded to support version 3, as defined in Internet draft draft-crabbe-pce-pce-initiated-lsp-03.

    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-crabbe-pce-pce-initiated-lsp-03.

Multicast

  • BGP link state distribution (M Series, MX Series, and T Series)—Starting with Release 14.2, Junos OS introduce a new mechanism to distribute topology information across multiple areas and autonomous systems (ASs) by extending the BGP protocol to carry link state information.

    Earlier, this information was acquired using an IGP, which has scaling limitations when it comes to distributing large a database. Using BGP provides a policy-controlled and scalable means of distributing the multi-area and multi-AS topology information.

    This information is used for computing paths for MPLS LSPs spanning multiple domains, such as inter-area TE LSP, and enables external path computing entities, such as ALTO and PCE, to acquire network topology.

    [See Link State Distribution Using BGP Overview and Example: Configuring GMPLS RSVP-TE VLAN LSP Signaling.]

  • MLD snooping (MX Series routers with MPCs)—Beginning with Junos OS Release 14.2, support for MLD snooping is available on MX Series routers with MPCs (MPC-1, MPC-2, MPC-3, and MPC-4). MLD snooping restricts the forwarding of IPv6 multicast traffic to only those interfaces in a bridge-domain/VPLS that have interested listeners. The operational commands for mld-snooping, including defaults, behavior, logging, and tracing, are the same as for IGMP snooping (which provides the same functionality for IPv4 traffic).
  • Separate multicast snooping domains for different logical systems (MX Series routers with MPCs and DPCs)—Starting in Junos OS Release 14.2, support for multicast, PIM, and IGMP snooping is available for named logical systems on MX Series routers with MPCs and DPCs. Multicast traffic specific to one logical system does not have to flood the entire bridge domain.

    This enhancement extends all the available snooping functionality in the default logical system (including separate routing tables, routing instances, policies, and interface configurations) to all of the named logical systems on the router. Likewise, the output of show commands is restricted to data from the named logical system only. The master logical system, however, can view the states of any or all named logical systems configured on the device.

    For service providers, the main benefits of this change are the ability to provide customers with distinct multicast domains for snooping and the ability to simplify multicast snooping testing by collapsing multiple routers onto a single device via logical systems. Multicast snooping per named logical systems also extends to MC-LAG in logical systems that were introduced in Junos OS Release 14.1.

    Multicast snooping in named logical systems does not support unified ISSU. We recommend that, prior to performing unified ISSU, the provider remove all IGMP-snooping specific configurations. Graceful Routing Engine switchover (GRES) is not affected by this change. IGMP snooping support for P2MP in VPLS for logical systems applies where such configurations are already valid.

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, and 14.2R4, 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.

  • Logical interfaces summary (MX Series)—Beginning with Junos OS Release 14.1R2, a new show command, show interfaces summary, is available to display the status and statistics on the logical interfaces configured on the device at the Flexible PIC Concentrator (FPC) level.

    [See show interfaces summary.]

  • Enhancements to SNMP statistics operational mode commands (M Series, MX Series, and T Series)—Beginning with Junos OS Release 14.2, you can use the show snmp stats-response-statistics command to view the statistics of SNMP statistics responses sent from the Packet Forwarding Engine during the MIB II process (mib2d). In addition, you can use the subagents option in the show snmp statistics command to view the statistics of the protocol data units (PDUs) and the number of SNMP requests and responses per subagent. The subagents option also helps you to view the SNMP statistics received from each subagent per logical system.

    [See show snmp stats-response-time and show snmp statistics.]

  • SNMP support for enterprise-specific MVPN MIB (M Series and T Series)—Starting with Junos OS Release 14.2, Junos OS SNMP supports the enterprise-specific MVPN MIB. Junos OS SNMP support for MVPN is based on the enterprise-specific extension of the IETF standard MIBs defined in Internet draft draft-ietf-l3vpn-mvpn-mib-03.txt, MPLS/BGP Layer 3 VPN Multicast Management Information Base.

    [See Juniper Networks Enterprise-Specific MIBs and Supported Devices, Juniper Networks Enterprise-Specific MIBs, and SNMP MIBs and Traps Reference.]

  • Support for RFC 4133, Entity MIB (MX240, MX480, and MX960)—Starting with Release 14.2, Junos OS supports tables and objects defined in RFC 4133, Entity MIB, except:
    • entityLogicalGroup table
    • entityNotificationsGroup table
    • entPhysicalMfgDate and entPhysicalUris objects in entityPhysical2Group table
    • entLPMappingTable and entPhysicalContainsTable in entityMappingGroup table

    [See Standard SNMP MIBs Supported by Junos OS.]

  • Support for RFC 4268, Entity State MIB (MX240, MX480, and MX960)—Starting with Release 14.2, Junos OS supports all objects and tables defined in RFC 4268, Entity State MIB.
  • Support for RFC 3635, Definitions of Managed Objects for the Ethernet-like Interface Types (MX Series only)—Starting with Release 14.2, Junos OS supports all objects and tables defined in RFC 3635, Definitions of Managed Objects for the Ethernet-like Interface Types, except dot3StatsRateControlAbility and dot3StatsRateControlStatus in dot3StatsEntry table.

    [See Standard SNMP MIBs Supported by Junos OS.]

  • Enhancement to reduce the time taken for performing system commit (M Series, MX Series, and T Series)—Beginning with Junos OS Release 14.2, you can configure the delta-export statement at the [edit system commit] hierarchy level to reduce the time taken to commit the configuration changes.

    [See commit (system) and delta-export.]

  • SNMP support for the timing feature—Starting in Junos OS Release 14.2, SNMP supports the timing feature. Currently, SNMP support is limited to defect and event notifications through SNMP traps. A new enterprise-specific MIB, Timing Feature Defect/Event Notification MIB, has been added to monitor the operation of PTP clocks within the network. The trap notifications are disabled by default. To enable trap notifications for the timing feature, include the timing-event statement at the [edit snmp trap-group trap-group object categories] hierarchy level to enable SNMP trap notifications for timing events and defects.
  • SNMP support for fabric queue depth, WAN queue depth, and fabric counter (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 14.2R3, 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

    [See jnxCosQstatTable, jnxCosIngressQstatTable, jnxFabricMib, jnxPfeMemoryTrapVars, and jnxPfeMemoryNotificationsPrefix.]

Operation, Administration, and Maintenance (OAM)

  • Support for MEF-36-compliant performance monitoring (MX Series)—Starting in Release 14.2R5, Junos OS supports performance monitoring that is compliant with Technical Specification MEF 36. You can enable MEF-36-compliant performance monitoring by configuring the measurement-interval statement at the [edit protocols oam ethernet cfm performance-monitoring] or [edit protocols oam ethernet cfm performance-monitoring sla-iterator-profiles profile-name] hierarchy level.

    Note: When MEF-36-compliant performance monitoring is enabled, an SNMP get next request for a variable might not fetch the current value unless an SNMP walk is performed before performing the get next request. This limitation applies only to the current statistics for delay measurement, loss measurement, and synthetic loss measurement.

    When MEF-36-compliant performance monitoring is enabled:

    • The output for the field Current delay measurement statistics might display a measurement interval of 0 (zero) and an incorrect timestamp until the first cycle time has expired.
    • Supported data TLV size for performance monitoring protocol data units (PDUs) is 1386 bytes when MEF-36-compliant performance monitoring is enabled. The TLV size is 1400 bytes in legacy mode.
    • The maximum configurable value for the lower threshold bin is 4,294,967,294.
    • Frame loss ratio (FLR) is excluded in loss measurements during period of unavailability for synthetic loss measurement only. In case of loss measurement, FLR is included even during period of unavailability.
    • During a period of loss of continuity (adjacency down), although SOAM PDUs are not sent, FLR and availability calculations are not stopped. These calculations are performed with the assumption of 100% loss.
    • The number of SOAM PDUs that are sent during the first measurement interval might be less than expected. This is because of a delay in detecting the adjacency state at the performance monitoring session level.
    • The number of SOAM PDUs transmitted during a measurement interval for a cycle time of 100 ms might not be accurate. For example, in a measurement interval of two minutes with a cycle time 100 ms, the SOAM PDUs transmitted might be in the range of 1198—2000.

    When MEF-36-compliant performance monitoring is disabled, the show oam ethernet connectivity-fault-management maintenance-domain sla-iterator-history maintenance-domain md-name maintenance-association ma-name mep mep-id sla-iterator profile-name command displays 32 records from this Junos OS release onward. In earlier releases, the command displays 16 records.

  • Loopback tracking for IEEE 802.3ah OAM link-fault management (MX Series)—Starting in Junos OS Release 14.2, MX Series routers support loopback tracking for the Ethernet Operation, Administration, and Management (OAM) link-fault management process (lfmd). When loopback tracking is enabled and the Ethernet OAM lfmd process detects its own generated packets on an interface, it marks the interface as down. When the loopback issue resolves, the interface is brought back up. To enable loopback tracking for Ethernet OAM, include the loopback-tracking statement at the [edit protocols oam ethernet link-fault-management interface] hierarchy level. hierarchy level.
  • Ethernet loss measurement counter support for each class in a multiclass environment—Junos OS supports Ethernet loss measurement (ETH-LM) for multiclass services. The ETH-LM feature is used by operators to collect frame loss counter values for ingress and egress service frames. Starting with Junos OS Release 14.2R3, the ETH-LM feature is extended to support the frame loss measurement counters for each class of packets in a multiclass environment. Counters for each class of packets are supported for point-to-point services only.

    Note: ETH-LM is currently supported for VPWS services only.

    ETH-LM maintains counters based on the forwarding class and loss priority of a packet. The loss priority determines the color of a packet—green indicates loss priority low for committed information rate (CIR) and yellow indicates loss priority medium-high for excess information rate (EIR). The color (green and yellow) counters are maintained for each class of packets. Based on the counters supported on an interface, you can configure the following accounting modes for Ethernet loss measurement:

    • Forwarding class-based accounting with color—In this mode, traffic is serviced based on packet loss priority and forwarding class. Two counters–green and yellow–are maintained for each forwarding class on each service interface. In this mode, an OAM (operation, accounting, and maintenance) packet collects counters based on the forwarding class.

      To configure this mode of loss measurement accounting, use the enable-multiclass-loss-measurement statement at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.

    • Forwarding class-based accounting without color—In this mode, traffic is serviced based on the forwarding class only. Only one counter is maintained for each forwarding class in each service interface.

      To configure this mode of loss measurement accounting, use the enable-multiclass-loss-measurement and colorless-loss-measurement statements at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.

    • Color-based accounting—In this mode, traffic is serviced based on the loss priority. Two counters—green and yellow—are maintained for each service interface. Color-based accounting is the default loss measurement mode and requires no configuration.
    • Code point-based accounting—In this mode, traffic is serviced based on the 802.1p priority bits. One counter is maintained for each code point (priority bit) on each service interface. If there are user virtual LAN or 802.1p rewrite rules configured, loss measurement accounting is done before applying the rewrite rules.

      To configure this mode, use the code-point-based-lm-accounting statement at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.

      Note: Code point-based accounting mode does not work if virtual LAN pop or push is configured on the interface. If pop or push is configured, the 802.1p bits are removed from the data packets. Therefore, in such cases, you can use forwarding class-based accounting if a one-to-one mapping exists between a forwarding class and the 802.1p bits value; otherwise you can use the priority-based accounting mode.

    • Priority-based accounting—In this mode, four counters are maintained for each forwarding class for each interface, with each counter corresponding to one of the two colors. To configure this mode, use the priority-based-lm-accounting statement at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.

Routing Policy and Firewall Filters

  • New flexible offset firewall filter terms (MX Series routers with MPCs or MICs)—In Junos OS releases earlier than Release 14.2, you configured firewall filter terms using the CLI only on pre-defined or fixed offsets within the IP packet, such as source address, destination port, and so on. Starting in Junos OS Release 14.2, new flexible offset firewall filter terms are available. These flexible offset filter terms allow a user to begin the search for match conditions at Layer 2, Layer 3, Layer 4, or payload locations within the IP packet and to vary the match parameters within those locations.

    [See Firewall Filter Match Conditions for IPv6 Traffic].

  • New firewall family bridge match criteria for IPv6 (MX Series routers with MPCs or MICs)—For IPv4 traffic, the following header match criteria are supported in bridge filters: IP source address, IP destination address, protocol type, and DiffServ code point (DSCP). Starting in Junos OS Release 14.2, the same match criteria have been added to the [firewall family bridge filter filter-name term rule-name from] hierarchy for the matching of IPv6 fields in firewall bridge filters. In addition, the IPv6 next-header and payload-protocol fields can be matched.

    [See Firewall Filter Match Conditions for IPv6 Traffic.]

  • New walkup statement available (M Series, MX Series, and T Series)—Starting in Junos OS Release 14.2, a new walkup feature is available. The walkup feature allows the user to change the default route filter prefix match behavior, so that the evaluation walks up multiple route filters contained within a single policy term, in order to allow matches on terms other than the default longest match. This can be applied globally or locally to a single policy. This feature can be configured in the main routing instance and in logical systems, but not in routing instances.
  • Support for consistent load balancing for ECMP groups (MX Series routers with MPCs)—Starting in Junos OS Release 14.2R2, on MX Series 3D Universal Edge 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.
  • Support for logical queue-depth in the PFE for IP options packets for a given protocol (M Series, MX Series, and T Series)— Starting with Junos OS Release 14.2R6, you can configure logical queue-depth in the PFE for IP options packets for a given protocol. The queue-depth indicates the number of IP options packets which can be enqueued in the PFE logical queue, beyond which it would start dropping the packets.

Routing Protocols

  • Virtual route reflector using 64-bit routing processes (MX Series)—Starting with Junos OS Release 14.2, many of the applications running on Junos OS can be shifted to external and more robust, powerful computing resources, thereby preserving the hardware resources on devices running Junos OS for switching and routing functionalities. Among the protocols and modules that can be transferred to external computing utilities, control plane protocols are suited for such an offloading. Such a virtualized process can be run on more powerful blade servers, and the computed entities can be downloaded to the router or the switch. With such an approach, the scaling dimensions for each of the virtualized processes can be increased to a large level.

    Out of the various processes that run within rpd, route reflector is an operation that requires a considerable amount of computing power (both with memory utilization and computation overhead). Such a virtualized module, virtual route reflector, can be run on external servers to achieve more scaling numbers. The virtualization of such functional blocks enables the service to be run on external high-performance servers. To enable this capability of a virtual route reflector, the entire Junos OS is virtualized and launched as a VM (virtual machine). To achieve higher and effective scaling numbers, rpd is configured as a 64-bit application, which benefits from a much better address space. The 64-bit capacity of rpd requires the kernel to also be of 64-bit type. The purpose of route reflection is loop prevention when the internal BGP (IBGP) routing devices are not fully meshed. To accomplish this, RRs break one of the rules of normal BGP operation: They readvertise routes learned from an internal BGP peer to other internal BGP peers. A new Junos OS platform image called vrr64 is provided. You can use the jinstall64-vrr package to install the 64-bit virtual route reflector on your device. Raw disk image format is supported for the VRR image. The new Junos OS platform image is converted to kernel-based virtual machine (KVM) or a Quick Emulator (QEMU) disk image, which is launched as a VM on the QEMU hardware virtualizer.

  • BGP-static routes (MX Series)—Beginning with Junos OS Release 14.2, you can configure and advertise BGP-static routes in a BGP network. You can advertise a BGP-static route in a BGP network, even if it is not the active route for the prefix. BGP-static routes do not flap unless they are deleted manually. You can define a policy that determines which BGP-static routes need to be advertised and included in the advertisements. Peer routers receive advertisements for these BGP-static routes regardless of dynamic routing information learned by the advertising router.

    To configure BGP-static routes, include the bgp-static route statement at the [edit routing-options] hierarchy level.

    [See BGP-Static Routes in a BGP Network.]

  • Remote LFA support for LDP in IS-IS (MX Series)—Beginning with Junos OS Release 14.2, you can configure a remote loop-free alternate (LFA) to extend the backup provided by the LFA in an IS-IS 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 IS-IS networks and subsequent LDP destinations, thereby eliminating the need for RSVP-TE backup tunnels for backup coverage.

    To configure remote LFA over LDP tunnels, include the remote-backup-calculation statement at the [edit protocols isis backup-spf-options] hierarchy level and the auto-targeted-session statement at the [edit protocols ldp] hierarchy level.

    [See Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks.]

  • OSPF domain-id interoperability (MX Series)— Starting in Junos OS Release 14.2R4, 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:
    • [edit routing-instances routing-instance name protocols ospf domain-id]
      or
      [edit policy-options community community name members]

    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.

  • Flow-aware transport pseudowire for BGP L2VPN and BGP VPLS (MX Series)— Starting with Junos OS Release 14.2R7, the flow-aware transport (FAT) label is supported for BGP-signaled pseudowires such as L2VPN and VPLS. Configuring flow-label-receive and flow-label-trasmit on the label edge routers (LERs) enables the transit routers or label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload.
  • 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 14.2R4, 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.

Services Applications

  • Support for interim logging for NAT port block allocation (MX Series routers with MS-MPCs/MS-MICs)—Starting in Junos OS Release 14.2R2, you 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 the 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.
  • Support for transmission of probes between a TWAMP client and a TWAMP server (MX Series)—Starting in Junos OS Release 14.2R2, you can configure an MX Series router that contains a Packet Forwarding Engine with 16-port 10-Gigabit Ethernet MPCs, FPCs (MPCs), MPC3Es, or MPC4Es to function as a Two-Way Active Measurement Protocol (TWAMP) client. A TWAMP client is a device that sends probe or test packets and functions as the generator or initiator of the probes. A TWAMP server is a device that receives the probes from the client and functions as the reflector or the receiver. A client opens a TCP connection with the server on a well-known port, which is port number 862. The host that initiates the TCP connection takes the roles of the control-client and (in the two-host implementation) the session-sender. Such a device is also called the TWAMP client. The host that acknowledges the TCP connection accepts the roles of a server and (in the two-host implementation) the session-reflector. Such a device is also called the TWAMP server.
  • 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 14.2R2, you can configure MX Series routers with MS-MPCs and MS-MICs to log network address translation (NAT) events 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 (such as NAT address pools or address values being exhausted for allocation). 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. Until Junos OS Release 14.2R1, MS-PIC uses the system logging protocol (syslog) to generate session logging. System log messages can be sent directly from the MS-PIC to an external system-logging server. For this transmission of syslogs to work properly, the services PIC interface must have an IP address and appropriate system logging options configured.
  • IPsec invalid SPI notification (M Series, MX Series, and T Series)—Starting in Junos OS Release 14.2, you can enable automatic recovery when peers in a security association (SA) become unsynchronized. When peers become unsynchronized, this can cause the transmission of packets with invalid security parameter index (SPI) values and the dropping of those packets by the receiving peer. You can enable automatic recovery by using the new respond-bad-spi max-responses configuration statement, which appears under the [edit services ipsec-vpn ike policy] hierarchy level. This statement results in a resynchronization of the SAs.

    The max-responses value has a default of 5 and a range of 1 through 30.

    [See Configuring IKE Policies.]

  • IPv6 support for aggregated multiservices (AMS) interfaces (MX Series with MS-MPCs)—Starting in Junos OS Release 14.2, you can use AMS interfaces for IPv6 traffic. To configure IPv6 support for an AMS interface, include the family inet6 statement at the [edit interfaces ams-interface-name unit unit-number] hierarchy level.

    Note: When family inet and family inet6 are set for an AMS interface sub-unit, the hash-keys set at the [edit services service-set-name load-balancing-options] hierarchy level apply both to IPv4 and IPv6 flows.

  • ICMP, ping, and traceroute ALGs for MS-MICs and MS-MPCs (MX Series)—Starting with Junos OS Release 14.2, Junos OS extension-provider packages that are preinstalled and preconfigured on the MS-MIC and MS-MPC offer support for ping, traceroute, and ICMP ALGs in a consistent manner that is identical to the support that the uKernel service provides. Parity and uniformity of support is established for these ALGs between MS-MICs/MS-MPCs and the uKernel service. Until Junos OS Release 14.1, ICMP ALGs, ping ALGs, and traceroute ALGs were not entirely supported on MX Series routers with MS-MICs and MS-MPCs in comparison with the uKernel service that enables Network Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC. Support was available for handling of ICMP error response packets that match any existing flow in the opposite direction and NAT processing of ICMP packets with NAT processing of ping packets.
  • Support for IP reassembly on GRE tunnel interfaces for (MX Series routers with MPCs)—Starting with Junos OS Release 14.2, you can configure the generic routing encapsulation (GRE) tunnel interfaces on MX Series routers with MPCs to support IP packet reassembly. You can configure the GRE interfaces to reassemble the fragmented packets at the endpoint of the tunnel before they can be further processed on the network by including the reassemble-packets statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number] hierarchy level. You can view the reassembly statistics by using the show services inline ip-reassembly statistics <fpc fpc-slot | pfe pfe-slot> command. Inline IP reassembly is supported on MX80, MX240, MX480, MX960, MX2010, MX2020, and MX104 routers. The line modules compatible with the corresponding MX Series routers that support the reassembly of GRE packets are MPC1, MPC2, MPC3, MPC4, and MPC-16X10GE. Until Junos OS Release 14.1, reassembly of IP fragments received at GRE tunnels is supported only on MX Series routers with MS-DPCs.
  • Enhancements to the RFC 2544-based benchmarking tests (MX104)—RFC 2544 tests are performed by transmitting test packets from a device that functions as a generator. These packets are sent to a device that functions as a reflector. The reflector receives and reflects packets back to the generator. MX104 routers can be configured as reflectors. Starting with Junos OS Release 14.2, MX104 routers support RFC 2544-based benchmarking tests for Ethernet transparent LAN (E-LAN) services configured using bridge domains. The RFC 2544 tests are performed to measure and demonstrate the service-level agreement (SLA) parameters before activation of the service. 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 user-to-network interface (UNI)-to-UNI unicast traffic only.
  • Support for PCP version 2 (MX Series)—Starting in Release 14.2R3, 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.
  • Support for RPM probes with IPv6 sources and destinations (MX Series routers with MPCs)—Starting in Junos OS Release 14.2R3, the RPM client router (the router or switch that originates the RPM probes) can send probe packets to the RPM probe server (the device that receives the RPM probes) that contains an IPv6 address. To specify the destination IPv6 address used for the probes, include the target (url ipv6-url | address ipv6-address) statement at the [edit services rpm probe owner test test-name] hierarchy level. You can also define the RPM client or the source that sents RPM probes to contain an IPv6 address. To specify the IPv6 protocol-related settings and the source IPv6 address of the client from which the RPM probes are sent, include the inet6-options source-address ipv6-address statement at the [edit services rpm probe owner test test-name] hierarchy level.
  • Support for H.323 NAT on MS-MPC and MS-MIC (MX Series routers)—Starting in Junos OS Release 14.2R7, 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.

  • Support for AMS warm standby on MS-MPC and MS-MIC (MX Series routers)—Starting in Junos OS Release 14.2R7, 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.

  • NAT with deterministic IP address and port mapping—Starting in Junos OS Release 14.2R7, you can configure deterministic NAT mapping for NAPT44. Deterministic NAT mapping ensures that a given internal IP address and port are always mapped to the same external IP address and port, and the reverse mapping of a given translated external IP address and port are always mapped to the same internal IP address. Deterministic NAT mapping eliminates the need for logging address translations.

    Configure deterministic NAT translation in a NAT rule by including the translation-type deterministic-napt44 statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level.

    Configure the range low value to be at least 1024 and the range high value to be no more than 65,535 at the [edit services nat pool pool-name port] hierarchy level. If you configure any ports below 1024, they are readjusted.

    You can configure up to 64,512 ports to make available for each internal subscriber with the deterministic-port-block-allocation block-size block-size statement at the [edit services nat pool pool-name port] hierarchy level. If you do not include this statement, the default value is 512. If you configure the block-size as 0, Junos OS automatically calculates the block size by using the number of configured subscriber IP addresses, the number of external translated IP addresses, and the port range.

  • Support for IKE and IPsec Passthrough NAPT-44 and NAT64 (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 14.2R7, 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;
    gate-timeout 90;
    child-inactivity-timeout 6000;
    }
    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;
    }
    }
    }
    }
  • Class-of-service (CoS) marking and reclassification for the MS-MICs and MS-MPCs—Starting with Junos Release 14.2R7, 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.]

Software-Defined Networking (SDN)

  • Support for OpenFlow v1.3.1 (MX Series)—Starting with Junos OS Release 14.2, MX Series routers support OpenFlow v1.3.1. In addition to the OpenFlow v1.0 functionality that is already supported on MX Series routers, OpenFlow v1.3.1 allows the action specified in one or more flow entries to direct packets to a base action called a group. The purpose of the group action is to further process these packets and assign a more specific forwarding action to them. You can view groups that were added, modified, or deleted from the group table by the OpenFlow controller using the show openflow groups command. You can view group statistics using the show openflow statistics groups command.

    [See Understanding How the OpenFlow Group Action Works.]

  • OVSDB support (MX Series)—Starting with Junos OS Release 14.2, 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 Series routers can exchange control and statistical information, 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 Open vSwitch Database Management Protocol Running on Juniper Networks Devices and Product Compatibility.]

  • OpenFlow v1.3.1 with IPv6 match conditions (MX80 3D Universal Edge, MX240, MX480, and MX960 3D Universal Edge Routers)—Starting with Junos OS Release 14.2R3, the MX80 3D Universal Edge, MX240, MX480, and MX960 3D Universal Edge routers support IPv6 match conditions OFPXMT_OFB_IPV6_SRC and OFPXMT_OFB_IPV6_DST.

    [See OpenFlow v1.3.1 Compliance Matrix for Devices Running Junos OS.]

  • OVSDB schema update (MX Series)—Starting with Junos OS Release 14.2R4, the OVSDB schema for physical devices version that is implemented on the MX Series routers is version 1.3.0. In addition, the schema now supports the multicast MACs local table.

    [See Open vSwitch Database Schema For Physical Devices.]

  • Destination MAC address rewrites for OpenFlow (MX80, MX240, MX480, and MX960)—Some types of network equipment that function as routers accept and handle packets only if the destination MAC address in the packet is the same as the MAC address of the Layer 3 interface on which the packet is received. To interoperate with these routers, connected devices must also be able to rewrite the destination MAC address of an incoming packet. Starting with Junos OS Release 14.2R6, an OpenFlow controller can configure an MX Series router that supports OpenFlow to rewrite the destination MAC address of an incoming packet.

    [See Understanding How the OpenFlow Destination MAC Address Rewrite Action Works.]

Software Installation and Upgrade

  • Validate system software against running configuration on remote host—Beginning with Junos OS Release 14.2R5, 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.
  • Validate system software add against running configuration on remote host or routing engine—Beginning with Junos OS Release 14.2R5, 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.

Subscriber Management and Services

Note: Subscriber management is not supported in Release 14.2R6.

Although present in the code, the subscriber management features are not supported in Junos OS Release 14.2. Documentation for subscriber management features is included in the Junos OS Release 14.2 documentation set.

  • Excluding diameter AVPs from JSRC messages (MX Series)—Starting in Junos OS Release 14.2, you can configure the router to exclude the Diameter user-name (1) AVP from authorization requests and provision requests sent to the SAE (remote SRC peer).

    [See Excluding AVPs from Diameter Messages for JSRC.]

  • Support for PPPoE-Description VSA (MX Series)—Starting in Junos OS Release 14.2, you can use Juniper Networks VSA 26-24 (PPPoE Description) when using RADIUS to authenticate subscribers based on the client MAC address.

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

  • DHCP relay agent for clients in different VRF than DHCP server (MX Series)—Starting in Junos OS Release 14.2, subscriber management provides enhanced security when exchanging DHCP messages between a DHCP server and DHCP clients that reside in different virtual routing instances (VRFs). The DHCP cross-VRF message exchange uses the DHCP relay agent to ensure that there is no direct routing between the client VRF and the DHCP server VRF.

    To exchange DHCP messages between the two VRFs, you configure both the server side and the client side of the DHCP relay to permit traffic based on the Agent Circuit ID (DHCP option 82 suboption 1) in DHCPv4 packets and the Relay Agent Interface-ID (DHCPv6 option 18) in DHCPv6 packets.

    [See DHCP Message Exchange Between DHCP Clients and DHCP Server in Different VRFs.]

  • ANCP agent adjustment of downstream data rate and overhead for SDSL, VDSL, and VDSL2 subscriber lines (MX Series)—Starting in Junos OS Release 14.2, you can configure the ANCP agent to provide two independent, adjusted values to CoS for downstream subscriber traffic on frame mode DSL types (SDSL, VDSL, and VDSL2), enabling CoS to more accurately adjust the effective shaping rate for the downstream subscriber traffic. You can specify a percentage value that is applied to the actual, unadjusted data rate received in ANCP Port Up messages. You can also specify a number of bytes that is added to or subtracted from the frame overhead for the traffic.

    [See Configuring the ANCP Agent to Report Traffic Rates to CoS.]

  • Concurrent support for PPPoE-over-ATM and IPoE-over-ATM subscriber interfaces on a single ATM PVC (MX Series with MPCs and ATM MICs with SFP)—Starting in Junos OS Release 14.2 for MX Series routers with ATM MICs with SFP installed, you can configure subscriber interfaces for both PPP-over-Ethernet-over-ATM (PPPoE-over-ATM) and IP-over-Ethernet-over-ATM (IPoE-over-ATM) concurrently on a single ATM PVC. The concurrent PPPoE-over-ATM and IPoE-over-ATM configuration supports all features specific to PPPoE-over-ATM interfaces and IPoE-over ATM interfaces, with no changes.

    To configure concurrent PPPoE-over-ATM and IPoE-over-ATM subscriber interfaces on a single ATM PVC, you configure the ATM logical interface as an IPoE-over-ATM interface by specifying the ether-over-atm-llc encapsulation type. You then use the family pppoe stanza at the [edit interfaces at-fpc/pic/port unit logical-unit-number] hierarchy level to configure PPPoE-over-ATM as a supported family. When the router detects the family pppoe stanza and the IPoE-over-ATM encapsulation, it identifies the configuration as concurrently supporting both PPPoE-over-ATM and IPoE-over-ATM on the ATM PVC.

    [See Configuring Concurrent PPPoE-over-ATM and IPoE-over-ATM Subscriber Interfaces on an ATM PVC.]

  • Configuration support to change the maximum transmission unit size and maximum receive unit size for PPP subscriber access—To prevent frequent fragmentation and reassembly of Point-to-Point Protocol (PPP) packets, starting in Junos OS Release 14.2, you can configure the PPP maximum transmission unit (MTU) size and the maximum receive unit (MRU) size that is sent during link control protocol (LCP) negotiation for the following PPP subscribers:
    • PPP over Ethernet (PPPoE) subscribers
    • PPP over Ethernet over ATM (PPPoE over ATM) subscribers
    • PPP over ATM (PPPoA) subscribers
    • Tunneled PPP LAC subscribers
    • Tunneled PPP LNS subscribers

    To configure the MTU size for each of the PPP subscribers, include the mtu (size | use-lower-layer) statement, and to configure the MRU size, include the mru size statement at the following hierarchy levels:

    • For dynamic and static PPP LNS subscribers associated with a group profile—[edit access group-profile group-profile-name ppp ppp-options]
    • For dynamic PPP subscribers—[edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” ppp-options]
    • For dynamic LNS subscribers—[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit “$junos-interface-unit” ppp-options]
    • For static PPP subscribers—[edit interfaces pp0 unit unit-number ppp-options]
    • For static LNS subscribers—[edit interfaces si interface-id unit unit-number ppp-options]
  • Support for IP reassembly on an L2TP connection (MX Series routers with MPC3E and MPC4E)—Starting in Junos OS Release 14.2, you can configure the service interfaces on MX Series routers with MPC3E and MPC4E 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.]

  • Global support for LAC forwarding of subscriber line information (MX Series)—Starting in Junos OS Release 14.2, you can configure the LAC to forward subscriber line information and optionally to include the Connection Speed Update Enable AVP (98) for all destinations with the access-line-information statement at the [edit services l2tp] hierarchy level. In earlier releases, you can configure this only on a per-destination basis. Both the global and per-destination configurations are disabled by default.

    The global and per-destination settings interact in the following way:

    • Access line information—You can enable forwarding at the global or per-destination level. When forwarding is enabled globally, you cannot disable the global setting for a specific destination.
    • Connection speed updates—You can enable updates at the global or per-destination level. You can disable the global setting for a specific destination by specifying access-line-information for the destination and omitting connection-speed-update.

    [See Subscriber Access Line Information Forwarding by the LAC Overview.]

  • Support for up to 256 L2TP tunnel groups (MX Series)—Starting in Junos OS Release 14.2R5, 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.

System Management

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

User Interface and Configuration

  • Support for allowing commands in a Junos OS op script (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.2, you can specify a regular expression that defines which commands to explicitly allow during execution of a Junos OS op script. The commands that you specify are performed even if a user login class denies that command. The permission to perform commands within a script applies to all users.

    [See Defining Commands to Allow in an Op Script.]

VPNs

  • Virtual route reflector (VRR)—Starting in Junos OS Release 14.2, you can implement route reflector capability using a general-purpose virtual machine on a 64-bit Intel-based blade server or appliance. Benefits of the VRR are:
    • Improved scalability (depending on the server core hardware use)
    • Scalability of the BGP network with lower cost using VRR at multiple locations in the network
    • Fast and more flexible deployment using Intel servers rather than router hardware
    • Space savings through elimination of router hardware
  • VRF localization (MX Series with MPCs)—Starting with Junos OS Release 14.2, VRF localization provides a mechanism for localizing routes of VRF to specific line cards to help maximize the number of routes that a router can handle. CE-facing interfaces localize all the routes of instance type VRF to specific line cards. If CE-facing interfaces are logical interfaces like AE or RLSQ or IRB, then the line card number has to be configured to localize routes. Core-facing line cards store all the VRF routes. These cards have to be configured as VPN core-facing only or VPN core-facing default. To configure VRF localization, configure the localized-fib configuration statement at the [edit routing-instances instance-name routing-options] hierarchy level and configure vpn-localization at the [edit chassis fpc fpc-slot] hierarchy level. The show route vpn-localization command displays the localization information of all the VRFs in the system.

    [See Example: Configuring VRF Localization on MX Series.]

  • Loop prevention in VPLS network due to MAC moves (MX Series)—Starting with Junos OS Release 14.2, the base learning interface approach and the statistical approach can be used to prevent a loop in a VPLS network by disabling the suspect customer-facing interface that is connected to the loop. Some virtual MACs can genuinely move between different interfaces and such MACs can be configured to ignore the moves. The cooloff time and statistical approach wait time are used internally to find out the looped interface. The interface recovery time can be configured to auto-enable the interface that gets disabled due to a loop in the network. To configure these parameters of VPLS MAC moves, include the vpls-mac-move statement at the [edit protocols l2-learning] hierarchy level. The show vpls mac-move-action instance instance-name command displays the learning interfaces that are disabled, in a VPLS instance due to a MAC move. The clear vpls mac-move-action interface ifl-name command enables an interface disabled due to a MAC move.

    [See Example: Configuring Loop Prevention in VPLS Network Due to MAC Moves.]

  • Integrating EVPN with VXLAN for Layer 2 data center interconnect (MX Series with MPCs and MICs only)—Virtual Extensible Local Area Network (VXLAN) is a technology that provides intra data center connectivity using a tunneling scheme to stretch Layer 2 connections over an intervening Layer 3 network.

    The Ethernet VPN (EVPN) technology, on the other hand, provides a solution for multipoint Layer 2 VPN services with advanced multihoming capabilities, using BGP control plane over MPLS/IP network.

    EVPN provides mechanisms for next generation DCI by adding extended control plane procedures to exchange Layer 2 MAC address and Layer 3 IP address information among the participating Data Center Border Routers (DCBRs). EVPN with its advanced features like active-active redundancy, aliasing, and mass MAC withdrawal helps in addressing the DCI challenges, such as seamless VM mobility and optimal IP routing, thus making it essential to provide VXLAN solutions over EVPN.

  • Leveraging DPCs for EVPN deployment (MX Series with DPCs)—Starting with Junos OS Release 14.2R3, 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 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.
  • Overlay ping and traceroute functionality for VXLAN tunnels (MX Series)—Starting in Junos OS Release 14.2R4, two new CLI commands supporting ping and traceroute troubleshooting functionality are provided to debug VXLAN overlay tunnels: ping overlay vni vni-id tunnel-src ip-address-src tunnel-dst ip-address-dst and traceroute overlay vni vni-id tunnel-src ip-address-src tunnel-dst ip-address-dst. Use the ping overlay and traceroute overlay commands to validate and verify the presence of the VXLAN tunnel endpoints within the context of the overlay VXLAN Network Identifier or VXLAN Segment ID (VNI) segment.
  • EVPN with VXLAN data plane encapsulation (MX Series)—Starting in Junos OS Release 14.2R4, 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.
  • IPv6 support over IRB interfaces for EVPN (MX Series)—Starting in Junos OS Release 14.2R5, the Ethernet VPN (EVPN ) integrated routing and bridging (IRB) solution supports IPv6 and the Neighborhood Discovery Protocol (NDP). NDP is used by IPv6 nodes on the same link to discover each other’s presence, determine each other’s Link Layer addresses, find routers, and maintain reachability information about the paths to active neighbors. IPv6 addresses over IRB for EVPN is supported for unique VLAN EVPN instances and for virtual switches with protocol EVPN instances.

Modified: 2017-12-12