Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

New and Changed Features

 

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

Hardware

  • Support for guided cabling (TX Matrix Plus routers with 3D SIBs)—Junos OS Release 14.1 and later support guided cabling in a routing matrix based on a TX Matrix Plus router with 3D SIBs. When you enable guided cabling, blinking LEDs on unconnected ports help you connect cables between the TXP-F13-3D and the TXP-LCC-3D SIBs.

    Use the following commands to enable or disable guided cabling:

    • To enable guided cabling, use the request chassis fabric guided-cabling (all-lcc | lcc lcc-number) enable (plane-by-plane | port-by-port) operational mode command.

    • To disable guided cabling, use the request chassis fabric guided-cabling (all-lcc | lcc lcc-number) disable operational mode command.

    [See Guided Cabling Overview, request chassis fabric guided-cabling enable, and request chassis fabric guided-cabling disable]

  • Support for simultaneous BITS/BITS redundancy on SCBE2 (MX240, MX480, and MX960)—Starting with Junos OS Release 14.1, simultaneous BITS/BITS redundancy is supported on SCBE2 on MX240, MX480, and MX960 routers. You can configure both the external interfaces for BITS input. One of the BITS inputs is considered as a primary clock source and the other as a secondary clock source on the basis of the configured clock quality.

    [See Centralized Clocking Overview.]

  • Unified ISSU support (TX Matrix Plus router with 3D SIBs)—Beginning with Junos OS Release 14.1, unified in-service software upgrade (ISSU) is supported on a TX Matrix Plus router with 3D SIBs. Unified ISSU enables you to upgrade from an earlier Junos OS release to a later one with no disruption on the control plane and with minimal disruption of traffic.

    [See Unified ISSU Concepts]

  • Support for OTN MIC on MPC6E (MX2010 and MX2020)—The 24-port 10-Gigabit Ethernet OTN MIC with SFPP (MIC6-10G-OTN) is supported on MPC6E on the MX2010 and MX2020 routers. The OTN MIC supports both LAN PHY and WAN PHY framing modes on a per-port basis.

    The MIC supports the following features:

    • Transparent transport of 24 10-Gigabit Ethernet signals with optical channel data unit 2 (ODU2) and ODU2e framing on a per port basis

    • ITU-standard optical transport network (OTN) performance monitoring and alarm management

    • Pre-forward error correction (pre-FEC)-based bit error rate (BER). Fast reroute (FRR) uses the pre-FEC BER as an indication of the condition of an OTN link

    To configure the OTN options for this MIC, use the set otn-options statement at the [edit interfaces interfaceType-fpc/pic/port] hierarchy level.

  • OTN support for 10-Gigabit Ethernet and 100-Gigabit Ethernet interfaces on MPC5E and MPC6E (MX240, MX480, MX960, MX2010, and MX2020)—Junos OS Release 14.1R3 extends optical transport network (OTN) support for 10-Gigabit Ethernet and 100-Gigabit Ethernet interfaces on MPC5E and MPC6E. MPC5E-40G10G and MPC5EQ-40G10G support OTN on 10-Gigabit Ethernet interfaces, and MPC5E-100G10G and MPC5EQ-100G10G support OTN on 10-Gigabit Ethernet interfaces and 100-Gigabit Ethernet interfaces. The OTN MICs MIC6-10G-OTN and MIC6-100G-CFP2 on MPC6E support OTN on 10-Gigabit Ethernet interfaces and 100-Gigabit Ethernet interfaces, respectively.

    OTN support includes:

    • Transparent transport of 10-Gigabit Ethernet signals with optical channel transport unit 2 (OTU2) framing

    • Transparent transport of 100-Gigabit Ethernet signals with OTU4 framing

    • ITU-T standard OTN performance monitoring and alarm management

    Compared with SONET/SDH, OTN provides stronger forward error correction, transparent transport of client signals, and switching scalability. To configure the OTN options for the interfaces, use the set otn-options configuration statement at the [edit interfaces interfaceType-fpc/pic/port] hierarchy level.

  • Support for fixed-configuration MPC (MX240, MX480, MX960, MX2010, and MX2020)—MX2020, MX2010, MX960, MX480, and MX240 routers support a new MPC, MPC5E (model number: MPC5E-40G10G). On the MX2010 and MX2020 routers, MPC5E is housed in an adapter card. MPC5E is a fixed-configuration MPC with four built-in PICs and does not contain separate slots for Modular Interface Cards (MICs). MPC5E supports two Packet Forwarding Engines, PFEO and PFE1. PFE0 hosts PIC0 and PIC2 while PFE1 hosts PIC1 and PIC3. A maximum of two PICs can be kept powered on (PIC0 or PIC2 and PIC1 or PIC3). The other PICs are required to be kept powered off.

    MPC5E supports:

    • Flexible queuing option by using an add-on license

    • Forwarding capability of up to 130 Gbps per Packet Forwarding Engine

    • Intelligent oversubscription services

    • Quad small form-factor pluggable plus transceivers (QSFP+) and small form-factor pluggable plus transceivers (SFP+) for connectivity

    • Up to 240 Gbps of full-duplex traffic

    • WAN-PHY mode on 10-Gigabit Ethernet Interfaces on a per-port basis

    Note

    On MX960 routers, all the MPC slots work with chassis temperature of up to 40°C (104°F). However, when the chassis temperature exceeds 40°C (104°F), slots 0 and 11 can only work with MPC1, MPC2, and the 16x10GE MPC.

    [See Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5E.]

  • Support for new fixed-configuration queuing MPC (MX240, MX480, MX960, MX2010, and MX2020)—MX2020, MX2010, MX960, MX480, and MX240 routers support a new queuing MPC, MPC5EQ (model number: MPC5EQ-40G10G). On the MX2010 and MX2020 routers, MPC5EQ is housed in an adapter card. MPC5EQ, like MPC5E is a fixed-configuration MPC with four built-in PICs and does not contain separate slots for Modular Interface Cards (MICs). MPC5EQ, like MPC5E supports two Packet Forwarding Engines, PFEO and PFE1. PFE0 hosts PIC0 and PIC2 while PFE1 hosts PIC1 and PIC3. A maximum of two PICs can be kept powered on (PIC0 or PIC2 and PIC1 or PIC3). The other PICs are required to be kept powered off.

    MPC5EQ supports 1 million queues per slot on all MX Series routers. All the other software features supported on MPC5E are also supported on MPC5EQ.

    Note

    On the MX960 router, FPC slot 0 and FPC slot 11 are not NEBS compliant beyond 104°F (40°C). This is a cooling restriction.

    [See Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5E.]

  • Software feature support on the MPC5E— MPC5E supports the following key features:

    • Basic Layer 2 features and virtual private LAN services (VPLS) functionality

    • Class of service (CoS)

    • Flexible Queuing option—By using an add-on license, MPC5E supports a limited number of queues (32,000 queues per slot including ingress and egress)

    • Hierarchical QoS

    • Intelligent oversubscription services

    • Interoperability with existing MPCs and DPCs

    • MPLS

    • MX Virtual Chassis

    The following features are not supported on MPC5E:

    • Active flow monitoring and services

    • Subscriber management features

    [See Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5E.]

  • Software feature support on the MPC5EQ—MPC5EQ supports 1 million queues per slot on all MX Series routers. All the other software features supported on MPC5E are also supported on MPC5EQ.

    [See Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5E.]

  • Support for new 520-gigabit full duplex Modular Port Concentrator (MPC6E) with two Modular Interface Card (MIC) slots (MX2010 and MX2020)—The MX2020 and MX2010 routers support a new MPC, MPC6E (model number: MX2K-MPC6E). MPC6E is a 100-Gigabit Ethernet MPC that provides increased density and performance to MX Series routers in broadband access networks for services such as Layer 3 peering, VPLS and Layer 3 aggregation, and video distribution.

    MPC6E provides packet-forwarding services that deliver up to 520 Gbps of full-duplex traffic. It has two separate slots for MICs and supports four Packet Forwarding Engines with a throughput of 130 Gbps per Packet Forwarding Engine. It also supports two MIC slots as WAN ports that provide physical interface flexibility.

    MPC6E supports:

    • 100-Gigabit Ethernet interfaces

    • Forwarding capability of up to 130 Gbps per Packet Forwarding Engine

    • Intelligent oversubscription services

    • Two separate slots for MICs (MIC6-10G and MIC6-100G-CXP)

    • Two Packet Forwarding Engines for each MIC slot

    • Up to 560 Gbps of full-duplex traffic for the two MIC slots

    • WAN-PHY mode on 10-Gigabit Ethernet interfaces on a per port basis

    [See Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5E.]

  • Feature support on MPC6E—MPC6E supports the following software features:

    • Basic Layer 2 features and virtual private LAN service (VPLS) functionality, except for Operation, Administration, and Maintenance (OAM)

    • Class of service (CoS)

    • Firewall filters and policers

    • Intelligent hierarchical policers

    • Internet Group Management Protocol (IGMP) snooping with bridging, integrated routing and bridging (IRB), or VPLS

    • Interoperability with existing DPCs and MPCs

    • Layer 2 trunk port

    • Layer 3 routing protocols

    • Multicast forwarding

    • MPLS

    • MPLS-fast reroute (FRR) VPLS instance prioritization

    • Precision Time Protocol (PTP) (IEEE 1588)

    • Synchronous Ethernet

    • Tunnel service

    The following features are not supported on MPC6E:

    • Active flow monitoring and services

    • Fine-grained queuing and input queuing

    • Unified in-service software upgrade (ISSU)

    • Virtual Chassis support

    [See Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5E.]

Authentication, Authorization and Accounting (AAA) (RADIUS)

  • RADIUS functionality over IPv6 for system AAA—Starting in Release 14.1R2, 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. (Note that if an IPv6 RADIUS server is configured without any source-address, default ::0 is considered as the source address.)

Class of Service (CoS)

  • Distributed periodic packet management support for aggregated Ethernet interfaces (T4000)—Starting with Release 14.1, Junos OS extends support on T4000 routers for the Bidirectional Forwarding Detection (BFD) protocol to use the periodic packet management daemon (ppmd) to distribute IPv4 sessions over aggregated Ethernet interfaces. Only IPv4 BFD sessions over aggregated Ethernet interfaces are supported. The ppmd process automatically runs on the Routing Engine and the Packet Forwarding Engine. To disable ppmd on the Packet Forwarding Engine only, include the no-delegate-processing statement at the [edit routing-options ppm] hierarchy level. The ppmd process does not support IPv6 BFD sessions or MPLS BFD sessions over an aggregated Ethernet interface.

    [See ppm and no-delegate-processing.]

  • Support for limiting traffic black-hole time by detecting Packet Forwarding Engine destinations that are unreachable (T4000)—Junos OS Release 14.1 and later releases extend support for T4000 routers to limit traffic black-hole time by detecting unreachable destination Packet Forwarding Engines. The router signals neighboring routers when it cannot carry traffic because of the inability of some or all source Packet Forwarding Engines to forward traffic to some or all destination Packet Forwarding Engines on any fabric plane, after interfaces have been created. This inability to forward traffic results in a traffic black hole. By default, the system limits traffic black-hole time by detecting severely degraded fabric. No user interaction is necessary.

    [See Traffic Blackholing Caused by Fabric Degradation, Disabling FPC Restart, degraded, action-fpc-restart-disable, show chassis fabric reachability, and show chassis fabric unreachable-destinations.]

  • Setting IPv4 and IPv6 DSCP and MPLS EXP bits independently (T4000 and TXP-4000-3D)—Junos OS Release 14.1 and later releases extend support to set the packet DSCP and MPLS EXP bits independently on IPv4 and IPv6 packets on T4000 Type 5 FPCs (model numbers: T4000-FBC5-3D and T4000-FPC5-LSR) in T4000 routers and the TXP-4000-3D chassis. To enable this feature for IPv4, include the protocol mpls statement at the [edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules dscp rewrite-name] hierarchy level. To enable this feature for IPv6, include the protocol mpls statement at the [edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules dscp-ipv6 rewrite-name] hierarchy level. You can set DSCP IPv4 and IPv6 values only at the ingress MPLS node. The following rewrite combinations are supported:

    • DSCP or inet-precedence and EXP rewrite on IPv4 packets

    • DSCPv6 and EXP rewrite on IPv6 packets

    [See Applying Rewrite Rules to Output Logical Interfaces, Setting IPv6 DSCP and MPLS EXP Values Independently, Configuring DSCP Values for IPv6 Packets Entering the MPLS Tunnel, and Configuring Rewrite Rules.]

  • Layer 2 CoS-based traffic metering (MX80 and MX Series routers with MPCs)—Starting with Junos OS Release 14.1, Layer 2 accounting statistics are available on a per class-of-service basis. Both bytes and packet total are counted (flow rates are not).

    A single, aggregate counter can be used with each forwarding class to count inet and inet6 flows. For ingress, only packets forwarded to the fabric are counted, and for egress, only packets forwarded to the WAN are counted. You can exclude overhead bytes from the count, as well as dropped packets and non-relevant network protocols such as ARP, BFD, and EOAM. You can configure counters with any or all of the following parameters:

    • logical/physical interfaces

    • IPv4/IPv6 traffic types

    • unicast/multicast traffic

    • ingress/egress flows

    Configure the counters using the enhanced command under forwarding-class-accounting in the CLI.

  • Support for CoS hierarchical schedulers on MPC5E (MX240, MX480, MX960, MX2010, and MX2020)—You can configure class-of-service (CoS) hierarchical schedulers on MPC5E interfaces. This feature is supported on egress only.

    You can use hierarchical schedulers to define traffic control profiles, which set the following CoS parameters on a CoS interface:

    • Delay buffer rate

    • Excess bandwidth

    • Guaranteed rate

    • Overhead accounting

    • Scheduler map

    • Shaping rate

Dynamic Host Configuration Protocol (DHCP)

  • Recursive DNS server ICMPv6 router advertisement option support (M Series, MX Series, and T Series)—Beginning with Junos OS Release 14.1, you can configure a maximum of three recursive DNS server addresses and their respective lifetimes through static configuration at the interface level for IPv6 hosts. Previously, rpd supported only link-local address information, prefix information, and the link MTU. The router advertisement-based DNS configuration is useful in networks where an IPv6 host’s address is auto-configured through an IPv6 stateless address and where there is no DHCPv6 infrastructure available.

    To configure the recursive DNS server address, include the dns-server-address statement at the [edit protocols router-advertisement interface interface-name] hierarchy level.

    [See Example: Configuring Recursive DNS Address.]

Forwarding and Sampling

  • Native analyzer support (MX240, MX480, and MX960)—Starting in Junos OS Release 14.1, support is provided for native analyzers and remote port-mirroring capabilities on the MX240, MX480, and MX960. 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] hierarchy level.

General Routing

  • Updated behavior in static link protection Mode (M Series, MX Series, and T Series)—In static link protection mode you can designate a primary and backup physical link to support aggregated interfaces link protection. Starting with Junos OS Release 14.1, you can configure a backup link to accept ingress traffic, discard ingress traffic, or remain down until it becomes active and starts carrying traffic. By default, the backup link accepts ingress traffic. The following new attributes have been added to link-protection to control these settings:

    • bkp-state-accept: Default, accept ingress traffic on the backup link

    • bkp-state-discard: Discard ingress traffic on the backup link

    • bkp-state-down: Mark the backup link as Down while the primary link is active

  • Support for preserving prenormalized ToS value in an egress mirrored or sampled packet (M Series, MX Series, and T Series)—Beginning with Junos OS Release 14.1, on MPC-based interfaces, you can preserve the prenormalized type-of-service (ToS) value for egress mirrored or sampled packets. To retain the pre-rewrite ToS value in mirrored or sampled packets, configure the pre-rewrite-tos statement at the [edit forwarding-options sampling] hierarchy level. This preserves the pre-rewrite ToS value for all forms of sampling, such as Routing Engine-based sampling, port mirroring, flow monitoring, and so on. This statement is effective for egress sampling only.

High Availability (HA) and Resiliency

  • Detailed information about the stages in an ISSU operation—Starting in release 14.1R9, Junos OS provides more detailed information about the stages in an ISSU operation. A new option verbose is added at the request system software in-service-upgrade package-name hierarchy level to provide information about the progress of an ISSU operation.

    When this option included in the command, the output provides the following additional information:

    • State of various RE daemons.

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

    • Progress of an ISSU operation, such as the initialization, hardware synchronization, and the completion of the ISSU operation.

    This option is supported only on MX240, MX480, MX960, MX2010, and MX2020 3D Universal Edge Routers.

  • MX Series Virtual Chassis support for determining member router health (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, you can configure an IP-based packet connection, known as a heartbeat connection, between the master router and backup router in an MX Series Virtual Chassis. The heartbeat connection exchanges heartbeat packets that provide important information about the availability and health of each member router.

    If a disruption or split occurs in the Virtual Chassis configuration, the heartbeat connection helps prevent the member routers from changing roles, which could cause undesirable results.

    To configure a heartbeat connection, first create a secure and reliable route between the master router and backup router. You can then configure the connection by including the heartbeat-address and heartbeat-timeout statements at the [edit virtual-chassis] hierarchy level.

  • MX Series Virtual Chassis support for locality bias (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, you can configure locality bias for aggregated Ethernet and equal-cost multipath (ECMP) traffic in an MX Series Virtual Chassis. Locality bias directs unicast transit traffic for ECMP groups and aggregated Ethernet bundles to egress links in the same (local) member router in the Virtual Chassis rather than to egress links in the remote member router, provided that the local member router has an equal or larger number of available egress links than the remote member router.

    Configuring locality bias enables you to conserve bandwidth on the Virtual Chassis port links by directing all ECMP and aggregated Ethernet data traffic to local egress links rather than across the Virtual Chassis port links between member routers.

    To enable locality bias, configure the locality-bias statement at the [edit virtual-chassis] hierarchy level.

    Best Practice

    To avoid possible traffic loss and oversubscription on egress interfaces, make sure that you understand the utilization requirements for the local links in your network before changing the locality bias configuration.

  • MX Series Virtual Chassis support for unified ISSU (MX Series routers with MPCs/MICs)—Starting in Junos OS Release 14.1, you can perform a unified in-service software upgrade (unified ISSU) on member routers in an MX Series Virtual Chassis configuration. Unified ISSU enables you to upgrade the the system software on the Virtual Chassis member routers with minimal traffic disruption and no disruption on the control plane.

    To start a unified ISSU in an MX Series Virtual Chassis, issue the request system software in-service-upgrade package-name command from the master Routing Engine in the Virtual Chassis master router (VC-Mm). This command always reboots each of the four Routing Engines in the Virtual Chassis.

    [See Unified ISSU in a Virtual Chassis and Unified ISSU System Requirements.]

  • MX Series Virtual Chassis support for Layer 2 spanning-tree protocols (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, an MX Series Virtual Chassis configuration supports the following Layer 2 Control Protocol (L2CP) features, known collectively as xSTP:

    • Spanning Tree Protocol (STP)

    • Rapid Spanning Tree Protocol (RSTP)

    • Multiple Spanning Tree Protocol (MSTP)

    • VLAN Spanning Tree Protocol (VSTP)

    Spanning-tree protocols resolve the forwarding loops in a Layer 2 network, thereby creating a loop-free tree topology. Configuring spanning-tree protocols provides link redundancy in case of link failures, and prevents undesirable loops in the data path.

    To configure and manage STP, RSTP, MSTP, or VSTP in a Virtual Chassis, you use the same procedures for a member router in an MX Series Virtual Chassis as you do for a standalone MX Series router.

    [See Spanning-Tree Protocols Supported and Virtual Chassis Components Overview.]

  • MX Series Virtual Chassis support for inline flow monitoring (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, you can configure inline flow monitoring for an MX Series Virtual Chassis. Inline flow monitoring enables you to actively monitor the flow of traffic by means of a router participating in the network.

    Inline flow monitoring for an MX Series Virtual Chassis provides the following support:

    • Active sampling and exporting of both IPv4 and IPv6 traffic flows

    • Sampling traffic flows in both the ingress and egress directions

    • Configuration of flow collection on either IPv4 or IPv6 devices

    • Use of the IPFIX flow collection template for traffic sampling (both IPv4 and IPv6 export records)

  • Support for LACP with fast hellos during unified ISSU (MX Series)—Starting in Junos OS Release 14.1, MX Series routers support LACP with fast hellos during unified ISSU. This support is disabled by default. To enable it you need to enter the new CLI set protocols lacp fast-hello-issu on both the DUT and peer routers before starting unified ISSU. The peer router must also be an MX Series router for this functionality to work.

Interfaces and Chassis

  • Support for physical interface damping (T Series)—Beginning with Junos OS Release 14.1, 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 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.]

  • Support for MC-LAG on logical systems—Starting with Junos OS Release 14.1, you can configure multichassis link aggregation (MC-LAG) interfaces on logical systems within a router. To configure ICCP for MC-LAG interfaces on logical systems, include the iccp statement at the [edit logical-systems logical-system-name protocols] hierarchy level. To view ICCP information for MC-LAG on logical systems, use the show iccp logical-system logical-system-name command. To view ARP statistics or remote MAC addresses for the multichassis aggregated Ethernet (MC-AE) nodes for all or specified redundancy groups on a logical system, use the show l2-learning redundancy-groups group-name logical-system logical-system-name (arp-statistics | remote-macs) command. To view neighbor discovery statistical details for MC-AE nodes on redundancy groups of a logical group, use the show l2-learning redundancy-groups group-name logical-system logical-system-name nd-statistics command.

    [See Multichassis Link Aggregation on Logical Systems Overview.]

  • Inline Multilink PPP, Multilink Frame Relay, and Multilink Frame Relay End-to-End for time-division multiplexing WAN interfaces (MX Series)— Starting in Junos OS Release 14.1, this feature allows support of Inline Multilink PPP (MLPPP), Multilink Frame Relay (FRF.16), and Multilink Frame Relay End-to-End (FRF.15) for time-division multiplexing (TDM) WAN interfaces provide bundling services through the Packet Forwarding Engine without requiring a PIC or Dense Port Concentrator (DPC).

    Traditionally, bundling services are used to bundle multiple low-speed links to create a higher bandwidth pipe. This combined bandwidth is available to traffic from all links and supports link fragmentation and interleaving (LFI) on the bundle, reducing high priority packet transmission delay.

    This support includes multiple links on the same bundle as well as multiclass extension for MLPPP. Through this service you can enable bundling services without additional DPC slots to support Service DPC and free up the slots for other MICs.

    For connecting many smaller sites in VPNs, bundling the TDM circuits with MLPPP/MLFR technology is the only way to offer higher bandwidth and link redundancy.

    MLPPP enables you to bundle multiple PPP links into a single multilink bundle, and MLFR enables you to bundle multiple Frame Relay data-link connection identifiers (DLCIs) into a single multilink bundle. Multilink bundles provide additional bandwidth, load balancing, and redundancy by aggregating low-speed links, such as T1, E1, and serial links.

    [See Inline MLPPP for WAN Interfaces Overview, Example: Configuring Inline MLPPP and Multilink Frame Relay End-to-End (FRF.15) for WAN Interfaces, and Example: Configuring Inline Multilink Frame Relay (FRF.16) for WAN Interfaces.]

  • SFPP-10G-CT50-ZR (MX Series)—Staring in Junos OS Release 14.1, the SPFF-10G-CT50-ZR 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. Only WAN-PHY and LAN-PHY modes are supported. 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 SPFF-10G-CT50-ZR transceiver:

    MX Series:

    • 16-port 10-Gigabit Ethernet MPC (model number: MPC-3D-16XGE-SFPP)—Supported in Junos OS Release 12.3R6, 13.2R3, 13.3R2, 14.1, 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 and wavelength.]

  • SFPP-10G-ZR-OTN-XT (MX Series, T1600, and T4000)—Starting in Junos OS Release 14.1, the SFPP-10G-ZR-OTN-XT dual-rate extended temperature 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 ITU-T and Juniper specifications. In addition, the transceiver supports LAN-PHY and WAN-PHY modes and OTN rates and provides a NEBS-compliant 10-Gigabit Ethernet ZR transceiver for the MX Series interface modules listed here. The following interface modules support the SFPP-10G-ZR-OTN-XT transceiver:

    MX Series:

    • 10-Gigabit Ethernet MIC with SFP+ (model number: MIC3-3D-10XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and later

    • 16-port 10-Gigabit Ethernet (model number: MPC-3D-16XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and later

    • 32-port 10-Gigabit Ethernet MPC4E (model number: MPC4E-3D-32XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, 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.3R5, 13.2R3, 13.3, and later

    T1600 and T4000 routers:

    • 10-Gigabit Ethernet LAN/WAN PIC with Oversubscription and SFP+ (model numbers: PD-5-10XGE-SFPP and PF-24XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, and later

    • 10-Gigabit Ethernet LAN/WAN PIC with SFP+ (model number: PF-12XGE-SFPP)—Supported in Junos OS Release 12.3R5, 13.2R3, 13.3, 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.]

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

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

  • Support for MPC5E on SCBE2 (MX Series)—Starting with Junos OS Release 14.1R2, MPC5E is supported on SCBE2 on MX240, MX480, and MX960 routers.

  • New command to set the license mode for MPCs (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 14.1R2, 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.

  • Loop prevention in VPLS network due to MAC moves (MX Series)—Starting with Junos OS Release 14.1R2, you can use the base learning interface approach and the statistical approach 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 you can configure such MACs to disregard the moves. The cooloff time and statistical approach wait time are used internally to find out the looped interface. You can configure the interface recovery time 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.

  • Entropy label support in mixed mode (MX Series)—Beginning with Junos OS Release 14.1R2, the entropy label 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. You can configure the entropy label without enhanced-ip configuration.

  • Support for Synchronous Ethernet on MPC5E and MPC6E (MX240, MX480, MX960, MX2010, and MX2020 routers)—Junos OS extends Synchronous Ethernet support for 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 Message Channel (ESMC) and external clocking.

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

  • Support for ITU-T Y.1731 ETH-LM, ETH-SLM, and ETH-DM on aggregated Ethernet interfaces (MX Series routers with MPCs)—Starting with Junos OS Release 14.1R4, 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 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.

  • 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.]

  • Support for fabric black-hole detection and recovery (TX Matrix Plus) router—Starting in Junos OS Release 14.1R6, TX Matrix Plus routers can detect and recover from fabric faults that are not caused by hardware failure but might be a result of a fabric black-hole condition.

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

    • Destination reprogramming

    • FPC reboot

    • Related faults recovery

    • SIB reboot

    You can disable the automatic recovery feature by using the auto-recovery-disable statement at the [edit chassis fabric degraded] hierarchy level. You can configure the FPCs to go offline when a traffic black-hole condition is detected in the routing matrix by using the fpc-offline-on-blackholing statement at the [edit chassis fabric degraded] hierarchy level.

    You can configure the FPCs to restart when a traffic black-hole condition is detected in the routing matrix by using the fpc-restart statement at the [edit chassis fabric degraded] hierarchy level.

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

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

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

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

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

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

IPv6

  • Expanded ALG support with NAT64 (MX Series routers with MS-MPC or MS-MIC line cards)—Starting with Junos OS Release 14.1, the FTP, TFPT, SIP, RTSP, and PPPT ALGs are supported. To configure the ALGs, include the applications [applications-list] statement at the [edit services nat rule rule-name term termname from] hierarchy level.

    Include in the ALG list, applications-list, Junos OS identifiers for desired ALGs:

    • junos-ftp for FTP

    • junos-tftp for TFTP

    • junos-sip for SIP

    • junos-rtsp for RTSP

    • junos-pppt for PPPT

  • Limit softwire flows per IPv6 prefix for DS-Lite (MX Series routers with MS-DPC interface cards)—Junos OS provides a configurable option to limit the number of softwire flows from a subscriber’s Basic Bridging Broadband (B4) device at a given point in time, thus limiting excessive use of addresses within the subnet available to a subscriber. This limitation reduces the risk of denial-of-service (DoS) attacks.

    To specify the size of the subnet subject to limitation, include the dslite-ipv6-prefix-length prefix-length statement at the [edit services service-set service-set-name softwire-options] hierarchy level. Specify a prefix length of 56, 64, 98, or 128.

    Starting in Junos OS Release 14.1, the show services nat mappings address-pooling-paired operational command output shows the mapping for the prefix. The mapping shows the address of the active B4.

    The show services softwire flows output shows active and inactive softwire flows from the same prefix.

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

    Note

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

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

    • Creation of Virtual Chassis.

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

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

    • Padding of Ethernet Frames with VLAN.

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

    • Termination or tunneling of all subscriber-based services.

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

Layer 2 Features

  • Support for configuring PPP NCP negotiation mode (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, both static and dynamic subscriber interfaces use passive PPP NCP negotiation by default. To enable active negotiation, use the new initiate-ncp configuration statement with the appropriate option:

    • For IPv4 (inet family) subscriber interfaces, use the initiate-ncp ip statement.

    • For IPv6 (inet6 family) subscriber interfaces, use the initiate-ncp ipv6 statement.

    You can also configure the negotiation mode for the PPP server in an IPv4/IPv6 dual-stack configuration:

    • For active negotiation, use the initiate-ncp ip statement for the IPv4 subscriber interface and the initiate-ncp ipv6 statement for the IPv6 subscriber interface.

    • For passive negotiation, use the initiate-ncp dual-stack-passive statement, which overrides the initiate-ncp ip and initiate-ncp ipv6 statements if they are configured.

    [See PPP Network Control Protocol Negotiation Mode Overview.]

  • Global configuration for LAC interoperation using Cisco NAS Port Info AVP (MX Series)—Starting in Junos OS Release 14.1, you can globally configure LAC interoperation with a Cisco Systems LNS by specifying the LAC’s NAS port method as cisco-avp with the nas-port statement at the [edit services l2tp tunnel] hierarchy level. This causes the LAC to include the Cisco NAS Port Info AVP (100) in the ICRQ messages it sends to the LNS for all tunnels.

    In earlier releases, you can configure interoperation only in a tunnel profile, so that it applies only to tunnels instantiated with that profile. The tunnel profile configuration now has precedence over the global configuration. You can override both by including the Tunnel-Nas-Port-Method VSA [26–30] in a RADIUS server configuration that modifies or creates a tunnel profile.

    [See Globally Configuring the LAC to Interoperate with Cisco LNS Devices.]

  • Enhanced support for firewall filter match conditions based on IEEE 802.1p VLAN priority bits (M320 and MX Series)—Starting in Junos OS Release 14.1, the M320 router supports firewall filter match conditions based on IEEE 802.1p VLAN priority bits. The M320 router also supports these match conditions with the presence of a control word in a VPLS instance. Also starting with Junos OS Release 14.1, MX Series routers support firewall filter match conditions based on IEEE 802.1p VLAN priority bits in both a VPLS instance and a Layer 2 VPN instance.

    [See Firewall Filter Match Conditions for VPLS Traffic and Firewall Filter Match Conditions for Layer 2 CCC Traffic.]

MPLS

  • LSP selection for default forwarding class using CBF (M Series, MX Series, and T Series)—When CoS-based forwarding (CBF) is configured on a VPLS PE router, VPLS BUM traffic (broadcast, unknown, and multicast traffic) uses the default forwarding class for label-switched path (LSP) selection. Starting in Junos OS Release 14.1, the LSP for the default forwarding class is configurable, enabling the association of VPLS BUM traffic with an LSP through CBF configuration.

    [See Load Balancing VPLS Non-Unicast Traffic Across Member Links of an Aggregate Interface.]

  • Support for load balancing VPLS non-unicast traffic across member links of an aggregate interface (M Series, MX Series, and T Series)—By default, VPLS non-unicast (or BUM — broadcast, unknown, and multicast) traffic sent across aggregate Ethernet interfaces is sent across only one member link of the aggregate interface. Starting in Junos OS Release 14.1, load balancing VPLS BUM traffic across all members of an aggregate interface can be enabled for each VPLS instance.

    [See Load Balancing VPLS Non-Unicast Traffic Across Member Links of an Aggregate Interface.]

  • Entropy label and FAT label support (MX Series and T Series)—Starting in Release 14.1, Junos OS supports entropy labels and Flow Aware Transport for Pseudowires (FAT) labels. Entropy labels and FAT labels when configured on the label-switching routers (LSRs) and label edge routers (LERs) 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.

    In Junos OS Release 14.1, entropy labels can be used for RSVP-signaled label-switched paths (LSPs) and point-to-point LDP-signaled LSPs. FAT flow labels can be used for LDP-signaled forwarding equivalence class (FEC 128 and FEC 129) pseudowires for virtual private LAN service (VPLS) and virtual private wire service (VPWS) networks.

    [See Configuring the Entropy Label for LSPs and FAT Flow Labels Overview.]

Multicast

  • Multicast-only fast reroute (MoFRR) (MX Series)—Starting in Junos OS Release 14.1, MoFRR functionality is available, in which packet loss is minimalized in PIM and multipoint LDP domains. This enhancement is available on the MX Series operating in enhanced IP mode and with MPC line cards. A new configuration statement, stream-protection, enables MoFRR. When establishing the primary and backup ECMPs, MoFRR attempts to select two separate upstream routers, if two such routers are available. If separate upstream routers are not available, but there are two links through the same upstream router, the protocol selects that router for both paths.

    Note

    MoFRR might select the same upstream router to establish the primary and the backup paths, even when two separate upstream routers are available.

    [See Example: Configuring Multicast-Only Fast Reroute in a PIM Domain and Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain.]

Network Management and Monitoring

  • Configuring SNMP to match jnxNatObjects values for MS-DPC and MS-MIC (MX Series)—In Junos OS Release 14.1R6, 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.

  • Forwarding Class extension to Interface MIB (MX Series)—Beginning with Junos OS Release 14.1, a new enterprise-specific forwarding class MIB, jnxIfAccountingStats, is available to monitor the statistics for various accounting parameters configured on the interface with the available forwarding classes. This is an extension to the Enterprise-Specific Interface MIB. The Forwarding Class MIB is currently supported only on the MX Series.

    [See SNMP MIB explorer.]

  • SNMP notifying target for removed notify target configuration (M Series, MX Series, and T Series)—Beginning with Junos OS Release 14.1, when a trap target is deleted from Juniper Networks devices, either a syslog event or a syslog trap is generated as per the user configuration. The existing SNMP trap jnxSyslogTrap is sent to all target network management systems (NMSs) specified in the SNMP agent including the target NMS, which is being deleted. By default, in the event of target deletion, only a syslog event is generated. To trigger a trap on deletion of a trap target, configure a syslog event policy, which sends the syslog as a trap to the network management systems.

  • Alarm MIB support (MX Series)—Beginning with Release 14.1, Junos OS supports RFC 3877, Alarm MIB, which provides the generic SNMP-based alarm management framework to address the problems occurring on a particular network resource. The jnxAlarmMib reports active alarms and the history of alarms through the SNMP MIB tables. A new daemon called alarm management daemon, AlarmMgmtD, reports notifications defined in the alarm model table. The Alarm MIB is currently supported only on the MX Series.

    To configure alarm management, include the alarm-management statement at the [edit snmp] hierarchy level.

    [See Interpreting the Enterprise-Specific Alarm MIB.]

  • SNMP MIB support for Ethernet OAM (MX Series)—Starting in Junos OS Release 14.1, SNMP MIB support is enabled for Ethernet OAM on MX Series routers. See Standard SNMP MIBs Supported by Junos OS to view the standard MIBs (in IEEE 802.1ag, Connectivity Fault Management and IEEE 802.1ap, Management Information Base (MIB) definitions for VLAN Bridges) that are supported for Ethernet OAM.

  • Subscriber accounting MIB support (M Series, MX Series, and T Series)—Starting in Junos OS Release 14.1, a new enterprise-specific Subscriber MIB, jnxSubscriberAccountingTable, has been added to the jnxSubscriberGeneral MIB to monitor subscriber sessions that are configured for RADIUS accounting. The jnxSubscriberAccountingTable MIB is a subset of the jnxSubscriberTable MIB.

  • SNMP support to monitor subscriber count per port (M Series, MX Series, and T Series)—Beginning with Junos OS Release 14.1, a new enterprise-specific Subscriber MIB, jnxSubscriberPortCountTable, has been added to the jnxSubscriberGeneral MIB to provide the number of active subscribers per port for tunneled and terminated subscribers.

  • Enhancement for viewing the details of user authentication (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.1, you can configure the following statements to view the attribute values of a logged in user:

    • enhanced-accounting—This configuration statement displays the details such as access privileges, access modes, and remote port of a user logged in through the RADIUS server or the TACAC+ server or local database. To enable this feature, use the set system radius-options enhanced-accounting command for the RADIUS server or the set system tacplus-options enhanced-accounting command for the TACAC+ server.

    • enhanced-avs-max—This configuration statement helps to limit the number of attribute values to be displayed when enhanced-accounting is enabled. To enable this feature, use the set system accounting enhanced-avs-max command.

Network Operations and Troubleshooting Automation

  • Upgrade to automation libraries (M Series, MX Series, and T Series)—SLAX is an alternative syntax for XSLT that is tailored for readability and familiarity, following the style of C and Perl. SLAX was originally developed as part of Junos OS. It is used for on-box scripting to allow users to customize and enhance the CLI. The Junos OS automation infrastructure uses the libslax and libxslt open source libraries. Beginning in Junos OS Release 14.1, these libraries have been upgraded to libxslt-1.1.28 and libslax.0.14.1.

  • Script dampening (M Series, MX Series, and T Series)—Beginning in Junos OS Release 14.1, the impact of processor-intensive scripts on the performance of the Routing Engine can be minimized by configuring Junos OS to dampen or slow down the execution of any commit, op, or event script. To slow down script execution, include the dampen statement at the [edit event-options event-script], [edit system scripts commit], or [edit system scripts op] hierarchy level.

    [See Dampening Script Execution.]

Platform and Infrastructure

  • Virtual route reflector (VRR)—Starting in Junos OS Release 14.1R3, 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

  • Virtual MX Series router (vMX)—Starting in Junos OS Release 14.1R5, you can deploy vMX routers on x86 servers. vMX supports most of the features available on MX Series routers and allows you to leverage Junos OS to provide a quicker and more flexible deployment. Some vMX benefits include:

    • Optimizing carrier-grade routing for the x86 environment

    • Leveraging Junos OS for MX Series routers

    • Simplifying operations through consistency with MX Series routers

    • Introducing new services without reconfiguring the current infrastructure

Port Security

  • Storm control support (MX240, MX480, and MX960)—Starting in Junos OS Release 14.1, support exists for storm control that enables the router to monitor traffic levels and to drop broadcast, multicast, and unknown unicast packets when a specified traffic level – called the storm control level — is exceeded, thereby preventing packets from proliferating and degrading the LAN.

    You can modify the storm-control configuration by configuring a storm control profile at the [edit forwarding-options] hierarchy level, and then binding the storm control profile to a specific logical interface or to a group of logical interfaces. The group can include a range of interfaces or all interfaces on the switch.

    [ See Layer 2 Device Security Feature Guide for MX Series Routers.]

  • Access port security (MX240, MX480, and MX960)—Starting in Junos OS Release 14.1, Layer 2 software access port security is supported on the MX240, MX480, and MX960:

    • DAI– DAI protects switches against ARP spoofing. DAI inspects ARP packets on the LAN and uses the information in the DHCP snooping database on the switch to validate ARP packets and to protect against ARP cache poisoning.

    • DHCP option 82–You can use DHCP option 82, also known as the DHCP relay agent information option, to help protect the router against attacks such as spoofing (forging) of IP addresses and MAC addresses, and DHCP IP address starvation.

    • DHCP snooping—DHCP snooping filters and blocks ingress DHCP server messages on untrusted ports, and builds and maintains an IP address to MAC address binding database. Most port security features depend on DHCP snooping.

    • IP source guard–You can use the IP source guard access port security feature to mitigate the effects of source IP address spoofing and source MAC address spoofing.

    • Static IP–You can add static (fixed) IP addresses and bind them to fixed MAC addresses in the DHCP snooping database.

    • Trusted DHCP server interface–You can configure any interface on a switch that connects to a DHCP server as a trusted interface (port). Configuring a DHCP server on a trusted interface protects against rogue DHCP servers sending leases.

[See Layer 2 Port Security Feature Guide for MX Series Routers.]

Routing Policy and Firewall Filters

  • Firewall filter match condition support for IPv6 extension headers (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, IPv6 firewall filters support extension header types as match conditions. This feature enables you to control the transmission of IPv6 packets based on the presence of specified extension header types in the packet. In the first fragment of a packet, the filter searches for a match in any of the extension header types. When a packet with a fragment header is found (a subsequent fragment), the filter only searches for a match of the next extension header type.

    [See Standard Firewall Filter Match Conditions for IPv6 Traffic.]

  • Firewall filter match condition support for additional ICMPv6 types (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, IPv6 firewall filters support several additional ICMPv6 match conditions. This feature enables you to specify match conditions for the following ICMP message types:

    • certificate-path-advertisement (149)

    • certificate-path-solicitation (148)

    • home-agent-address-discovery-reply (145)

    • home-agent-address-discovery-request (144)

    • inverse-neighbor-discovery-advertisement (142)

    • inverse-neighbor-discovery-solicitation (141)

    • mobile-prefix-advertisement-reply (147)

    • mobile-prefix-solicitation (146)

    • private-experimentation-100 (100)

    • private-experimentation-101 (101)

    • private-experimentation-200 (200)

    • private-experimentation-201 (201)

    [See Standard Firewall Filter Match Conditions for IPv6 Traffic.]

  • IPv6 support for next-hop groups (MX Series)—Starting in Junos OS Release 14.1R2, 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.

  • Support for consistent load balancing for ECMP groups (MX Series routers with MPCs)—Effective in Junos OS Release 14.1R2, 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.

    [See Actions in Routing Policy Terms. ]

  • Support for logical queue-depth in the Packet Forwarding Engine for IP options packets for a given protocol (M Series, MX Series, and T Series)— Starting with Junos OS Release 14.1R8, you can configure logical queue-depth in the Packet Forwarding Engine for IP options packets for a given protocol. The queue-depth indicates the number of IP options packets that can be enqueued in the Packet Forwarding Engine logical queue, beyond which it would start dropping the packets.

Routing Protocols

  • Nonstop active routing for BGP multicast VPNs (M Series, MX Series, and T Series)—Starting in Junos OS Release 14.1, this feature enables nonstop active routing for the BGP multicast VPNs (MVPNs). This feature synchronizes the MVPN routes, cmcast, provider-tunnel and forwarding information between the master and the backup Routing Engines.

    [See advertise-from-main-vpn-tables.]

  • Advertising multiple paths in BGP (MX Series and T Series)—Starting in Junos OS Release 14.1, this feature allows up to 20 BGP add-paths to be advertised for a subset of prefixes that match the add-path prefix-policy.

    To enable this feature for a prefix, the add-path prefix-policy term matching the prefix should have a new then action to set add-path send-count<2...20>. This new action is a not applicable if the policy-statement containing it is used anywhere other than add-path prefix-policy.

    [See Actions in Routing Policy Terms, path-count, and prefix-policy.]

  • Egress protection for BGP labeled unicast (M Series, MX Series, and T Series)—Starting in Junos OS Release 14.1, fast protection for egress nodes is available to services in which BGP labeled unicast interconnects IGP areas, levels, or autonomous systems (ASs). If a provider router detects that an egress router (AS or area border router) is down, it immediately forwards the traffic destined to that router to a protector router that forwards the traffic downstream to the destination.

    [See Egress Protection for BGP Labeled Unicast.]

  • Selecting backup LFA for IS-IS routing protocol (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.1, the default loop-free alternate (LFA) selection algorithm or criteria can be overridden with an LFA policy. These policies are configured for each destination (IPv4 and IPv6) and a primary next-hop interface. These backup policies enforce LFA selection based on admin-group, srlg, neighbor, neighbor-tag, bandwidth, protection-type, and metric attributes of the backup path. During backup shortest-path-first (SPF) computation, each attribute (both node and link) of the backup path, stored per backup-next hop, is accumulated by IGP. For the routes created internally by IGP, the attribute set of every backup path is evaluated against the policy configured per destination per prefix primary next-hop interface. The first or the best backup path is selected and installed as the backup next-hop in the routing table. To configure the backup selection policy, include the backup-selection configuration statement at the [edit routing-options] hierarchy level. The show backup-selection command displays the configured policies for a given interface and destination. The display can be filtered against a particular destination, prefix, interface, or logical systems.

    [See Example: Configuring Backup Selection Policy for IS-IS Protocol.]

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

    • or

    Caution

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

Services Applications

  • Support for inline video monitoring (MX Series routers with MPCs)—Starting in Junos OS Release 14.1, video monitoring using media delivery indexing (MDI) criteria is supported. MDI information enables you to identify devices that are causing excessive jitter or packet loss for streaming video applications. To configure inline video monitoring criteria, include the templates and interfaces statements at the [edit services video-monitoring] hierarchy level.

    Inline video monitoring is available for the following MPC interface cards:

    • MPCE1

    • MPCE2

    • MPC-16XGE

    [See Inline Video Monitoring Overview.]

  • Enhancements to IPsec packet fragmentation (MX Series routers with MS-MICs and MS-MPCs)—Starting with Junos OS Release 14.1, in packets that are transmitted through static and dynamic endpoint IPsec tunnels, you can enable the value set in the Don't Fragment (DF) bit of the packet entering the tunnel to be copied only to the outer header of the IPsec packet and to not cause any modification to the DF bit in the inner header of the IPsec packet. To copy the DF bit value to only the outer header and not modify the inner header, use the copy-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level for static tunnels and at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level for dynamic endpoints. To configure the DF bit in only the outer header of the IPsec packet and to leave the inner header unmodified, include the set-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level for static tunnels and at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level for dynamic endpoints.

    [See copy-dont-fragment-bit (Services IPsec VPN) , set-dont-fragment-bit (Services IPsec VPN), copy-dont-fragment-bit (Services Set), and set-dont-fragment-bit (Services Set).]

  • Support for configuring template ID, observation domain ID, and source ID for Version 9 and IPFIX flow templates—Starting with Junos OS Release 14.1, you can define the template ID for version 9 and IPFIX templates for inline flow monitoring. To specify the template ID for version 9 flows, include the template-id id statement at the [edit services flow-monitoring version9 template template-name] hierarchy level. To specify the template ID for version IPFIX flows, include the template-id statement at the [edit services flow-monitoring version-ipfix template template-name] hierarchy level. To specify the options template ID for version 9 flows, include the options-template-id statement at the [edit services flow-monitoring version9 template template-name] hierarchy level. To specify the options template ID for version IPFIX flows, include the options-template-id statement at the [edit services flow-monitoring version-ipfix template template-name] hierarchy level. The template ID and options template ID can be a value in the range of 1024 through 65535.

    Until Junos OS Release 13.3, the observation domain ID is predefined and is set to a fixed value, which is derived from the combination of FPC slot, sampling protocol, Packet Forwarding Engine Instance, and LU Instance fields. This derivation creates a unique observation domain per LU per family. Starting with Junos OS Release 14.1, you can configure the observation domain ID, which causes the first 8 bits of the field to be configured. For version 9 flows, a 32-bit value that identifies the Exporter Observation Domain is called the source ID.

    [See Configuring Observation Domain ID and Source ID for Version 9 and IPFIX Flows and Configuring Template ID and Options Template ID for Version 9 and IPFIX Flows.]

  • Increased number of IPsec tunnels (MX80, MX240, MX480, and MX960)—Starting with Junos OS Release 14.1, you can configure a maximum of up to 8000 IPsec tunnels using 6000 service sets on a router. In such a scenario, you can employ up to 8000 logical interfaces in your environment and configure IPv4, IPv6, and dead peer detection (DPD) protocols. Until Junos OS Release 13.3, the maximum number of IPsec tunnels supported with 6000 service sets was 6000 tunnels.

  • IPsec invalid SPI notification (MX Series and T Series)—Starting in Junos OS Release 14.1R3, 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 hierarchy level [edit services ipsec-vpn ike policy]. 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.

  • Data plane inline support added for 6rd and 6to4 tunnels connecting IPv6 clients to IPv4 networks (MX Series routers with MPC line cards)—Starting with Release 14.1R3, Junos OS supports inline 6rd and 6to4 on Modular Port Concentrator (MPC) line cards with Trio chipsets, saving customers the cost of using MS-DPCs for the required tunneling, encapsulation, and decapsulation processes. Anycast is supported for 6to4 (next-hop service interfaces only ). Hairpinning is also supported for traffic between 6rd domains.

    There are no CLI changes for 6rd and 6to4 configurations. To implement the inline functionality, configure service interfaces on the MPC card as inline services interfaces (si- ) rather than as MultiServices (ms-) interfaces.

    Two new operational commands have been added: show services inline softwire statistics and clear services inline softwire statistics.

  • Support for RPM probes with IPv6 sources and destinations (MX Series routers with MPCs)—Starting with Junos OS Release 14.1R4, 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 sends 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 PCP version 2 (MX Series)—Starting in Junos OS Release 14.1R4, 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.

Software Installation and Upgrade

  • Unified ISSU support for LFM (M Series and MX Series)—Starting in Junos OS Release 14.1, the LFM protocol supports unified ISSU on M Series and MX Series with some restrictions. Connectivity failures that occur during the unified ISSU period are not detected until after unified ISSU has completed. If unified ISSU is initiated while discovery is in progress, the discovery completes only after unified ISSU has finished. LFM features that require Routing Engine involvement do not work during the unified ISSU period. Unified ISSU cannot run on the local and remote ends at the same time. The peer router must also be a Juniper Networks router running Junos OS that supports LFM ISSU for this feature to work on the local end.

  • Unified ISSU support (MX104)—Starting with Junos OS Release 14.1, unified ISSU is supported on the MX104.

    Unified ISSU is supported on the following MICs on MX104 routers:

    • Gigabit Ethernet MIC with SFP (MIC-3D-20GE-SFP)

    • Gigabit Ethernet MIC with SFP (E) (MIC-3D-20GE-SFP-E)

    • Gigabit Ethernet MIC with SFP (EH) (MIC-3D-20GE-SFP-EH)

    • 10-Gigabit Ethernet MICs with XFP (MIC-3D-2XGE-XFP)

    • Tri-Rate Copper Ethernet MIC (MIC-3D-40GE-TX)

    When unified ISSU is not supported on a MIC, at the beginning of the upgrade, Junos OS issues a warning that the MIC will be taken offline. After the MIC is taken offline and unified ISSU is complete, the MIC is brought back online.

    Unified ISSU is not supported on the following MICs on MX104 routers:

    • ATM MIC with SFP (MIC-3D-8OC3-2OC12-ATM)

    • Channelized E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE)

    • Channelized E1/T1 Circuit Emulation MIC (H) (MIC-3D-16CHE1-T1-CE-H)

    • Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP (MIC-3D-4COC3-1COC12-CE)

    • Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP (H) (MIC-4COC3-1COC12-CE-H)

    • Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-4CHOC3-2CHOC12)

    • Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-8CHOC3-4CHOC12)

    • DS3/E3 MIC (MIC-3D-8DS3-E3)

    • SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-4OC3OC12-1OC48)

    • SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-8OC3OC12-4OC48)

    • SONET/SDH OC192/STM64 MIC with XFP (MIC-3D-1OC192-XFP)

    During unified ISSU, the protocols and applications that are not supported on MX104 routers are the same as those that are not supported on other MX Series routers undergoing unified ISSU.

    [See Unified ISSU System Requirements.]

  • Support for LACP with fast hellos during unified ISSU (MX Series)—Starting in Junos OS Release 14.1, MX Series routers support LACP with fast hellos during unified ISSU. This support is disabled by default. To enable it you need to enter the new CLI knob set protocols lacp fast-hello-issu on both the DUT and peer routers before starting unified ISSU. The peer router must also be an MX Series router for this functionality to work.

  • Unified ISSU support on L2TP LNS (M Series, MX Series, and T Series)—Junos OS Release 14.1 and later releases support unified ISSU on the L2TP network server (LNS). When an upgrade is initiated, the LNS completes any L2TP negotiations that are in progress but rejects any new negotiations until the upgrade has completed. No new tunnels or sessions are established during the upgrade.

    [See L2TP for Subscriber Access Overview.]

  • Unified ISSU support (TX Matrix Plus router with 3D SIBs)—Starting in Junos OS Release 14.1, unified ISSU is supported on TX Matrix Plus routers with 3D SIBs. Unified ISSU enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic.

    [See Unified ISSU System Requirements.]

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

Spanning-Tree Protocols

Subscriber Management and Services

Note

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

  • RADIUS VSAs in output of test aaa command when authentication is unsuccessful (MX Series)—Starting in Junos OS Releases 13.2R3 and 14.1R1, when you run the test aaa command, the command output includes all subscriber attributes when authentication is unsuccessful. In previous releases, the test aaa command returned a partial list of attributes when authentication was unsuccessful.

    [See Testing a Subscriber AAA Configuration.]

  • Using DHCP relay agent optional information to enhance security (MX Series)—Starting in Junos OS Release 14.1, you can provide additional security by configuring DHCP relay agent to include optional information in client requests that the relay forwards to the DHCP server. The optional information helps minimize potential security shortcomings that might exist when a DHCP server on a central LAN allows connections from central access devices.

    For DHCPv4, DHCP relay agent inserts Relay Agent Information Option (option 82) Agent Remote ID (suboption 2) into the relayed client requests. For DHCPv6, DHCPv6 relay agent inserts Relay Agent Remote-ID (option 37) into the relayed (RELAY-FORW) DHCPv6 messages.

    [See Using DHCP Relay Agent Option 82 Information and DHCPv6 Relay Agent Options.]

  • Support for Agent-Remote-Id when testing subscriber authentication (MX Series)—Starting in Junos OS Release 14.1, you can use the agent-remote-id ari option with the test aaa dhcp user and test aaa ppp user commands to verify DHCP and PPP subscriber authentication in those networks that use the DSL Forum Agent-Remote-Id (VSA 26-2). If the ARI value that you specify includes special characters, such as a phone number that includes parentheses and a hyphen, you must enclose the value in quotation marks (“”), as in the following example:

    [See Testing a Subscriber AAA Configuration.]

  • RADIUS-based usage thresholds for subscriber services (MX Series)—Starting in Junos OS Release 14.1, you can set usage thresholds for subscriber services that are dynamically activated or modified.

    Subscriber management supports two types of usage thresholds—traffic volume and time. You use Juniper Networks VSAs to set the usage thresholds. The VSAs are transmitted in RADIUS Access-Accept messages for dynamically activated services, or in RADIUS-initiated CoA-Request messages for existing services. The traffic volume threshold sets the maximum amount of traffic that can use the service before the service is deactivated. The time threshold sets the maximum length of time that the service can be active.

    [See Usage Thresholds for Subscriber Services.]

  • Overriding short DHCP leases offered by third-party DHCP servers (MX Series)—Starting in Junos OS Release 14.1, you can specify the minimum DHCP lease time allowed by the DHCP local server or DHCP relay agent. This feature enables you to avoid potential issues when a third party owns or manages the DHCP server or address-assignment pool that provides the client lease. In some cases, the third party might provide address leases that are unsuitable for the subscriber access environment. For example, extremely short lease times can create unnecessary traffic that results in reduced performance in the network.

    In addition to specifying a minimum lease time, you can also specify the action the router takes when receiving a DHCP lease time that is less than the minimum acceptable value.

    [See DHCP Lease Time Violation.]

  • Support for L2TP AVPs that report access line information to the LNS (MX Series)—Starting in Junos OS Release 14.1, you can configure the LAC to include L2TP AVPs in ICRQ messages to convey attributes such as line identification and traffic rates. The LAC receives the information from the DSLAM (ANCP access node) associated with the subscriber line; the values can be sourced from the ANCP agent or PPPoE intermediate agent tags carried in PADI and PADR discovery packets. You can also configure the LAC to send Connect-Speed-Update-Notification messages to the LNS to report updates to the subscriber connection speeds compared to the initial values conveyed by L2TP AVP 24 and AVP 38.

    [See Forwarding of Subscriber Access Line Information by the LAC and Configuring the LAC to Report Access Line Information to the LNS.]

  • Support for RADIUS accounting message retry and timeout (MX Series)—Starting in Junos OS Release 14.1, you can include the new accounting-retry and accounting-timeout statements to specify retry and timeout values for RADIUS accounting messages separately from authentication messages. When you do so, the existing retry and timeout statements apply only to authentication messages; otherwise, they also apply to accounting messages.

    Separate settings are useful for the following reasons:

    • Authentication is time critical. Consequently, dropped packets need to be retransmitted quickly and short timeouts are desirable. Fewer retransmissions are sufficient because an unsuccessful subscriber is likely to attempt another login quickly.

    • Accounting is less time critical, but it is important not to lose the accounting messages. Long timeouts and more retransmissions reduce packet loss.

    [See accounting-retry and accounting-timeout.]

  • Conserving IPv4 addresses for dual-stack PPP subscribers (MX Series routers with MPCs or MICs)—Beginning in Junos OS Release 14.1, the IPv4 address saving feature for dual-stack PPP subscribers when they are not using the IPv4 service is expanded. During IPv4 address negotiation, if the broadband network gateway (BNG) receives an Access-Reject response from the RADIUS server that includes the Unisphere-Ipv4-release-control VSA and Reply Message attribute #18, the BNG sends an IPCP terminate request to the CPE. The CPE is then allowed to renegotiate IP NCP. However, if Unisphere-Ipv4-release-control VSA and Reply Message attribute #18 are not included in the Access-Reject response, the CPE must renegotiate the LCP link before being allowed to renegotiate IP NCP.

  • Dynamic Domain Name System (DNS) Resolver for IPv6 (MX Series)—Beginning in Junos OS Release 14.1, in a network that uses Neighbor Discovery Router Advertisement (NDRA) to provide IPv6 addressing, the DNS server address can be provided in Router Advertisements sent to IPv6 hosts. The address is included in a field called Recursive DNS Server (RDNSS). This feature is useful in networks that are not running DHCPv6.

    To configure (the default lifetime is 1800 seconds):

    [See DNS Resolver for IPv6 DNS Overview.]

  • Subscriber interfaces over point-to-point MPLS pseudowires (MX Series routers with MPCs or MICs)—Beginning in Junos OS Release 14.1, pseudowire subscriber interfaces support the following features:

    • Access Node Control Protocol (ANCP), which is used to monitor subscriber access lines and to report and modify subscriber traffic on the access lines between the subscribers and the access nodes.

    • Agent circuit identifier (ACI) interface sets, which are dynamic VLAN subscriber interfaces that are created based on ACI information and that originate at the same household or on the same access-loop port.

    • CoS shaping-rate and overhead-accounting attributes for dynamic ACI interface sets.

  • Minimum retransmission interval for L2TP control packets (MX Series)—Starting in Junos OS Release 14.1, you can give a remote L2TP peer more or less time to respond to a control message sent by the local peer by including the minimum-retransmission-interval statement to configure the minimum interval that the local peer waits for a response. You can configure a minimum value of 1, 2, 4, 8, or 16 seconds; previously, the minimum interval was fixed at 1 second. The peer retransmits the message if a response is not received before the timeout expires, but waits for double the previous interval. The interval doubles with each retransmission until the maximum of 16 seconds is reached.

    [See Retransmission of L2TP Control Messages.]

  • Support for dynamic VLAN authentication based on subscriber packet type (MX Series)—Starting in Junos OS Release 14.1, you can limit the packet types that trigger RADIUS authentication for dynamic, auto-sensed VLANs. In earlier releases, authentication is triggered by packet types configured with the accept statement in VLAN dynamic profiles.

    Now you can specify that a subset of accepted packet types triggers authentication by including the packet-types statement at the [edit interfaces interface-name auto-configure vlan-ranges authentication] or [edit interfaces interface-name auto-configure stacked-vlan-ranges authentication] hierarchy level.

    Because PPPoE subscribers are authenticated by PPP, you can conserve resources in a mixed PPPoE and IP environment by limiting VLAN authentication to the IP packets. You can also use this statement with the Client-Profile-Name VSA [26-174] to override a dynamic profile for certain subscriber types in a mixed access environment.

  • Clear DS-Lite mappings and flows (MX Series routers with MS-DPC interface cards)—In Junos OS Release 14.1 and later releases, you can clear DS-Lite mapping statistics and flows for a specific subscriber, Basic Bridging Broadband Device (B4), or host behind a B4 using the following new operational commands.

    • clear services nat mappings app—Clear address-pooling paired mappings.

    • clear services nat mappings eim—Clear endpoint independent mappings.

    • clear services nat mappings pcp—Clear port control protocol (PCP) mappings.

    • clear services nat mappings service-set—Clear all NAT mappings for a service-set.

    • clear services nat flows—Clear all NAT flows. This command has the following scope options:

      • b4address—Clear all flows for a subsciber B4 address.

      • service-set—Clear all flows for a service set.

      • subscriber—The subscriber address.

  • Support for ATM virtual path shaping on ATM MICs with SFP (MX Series)—Starting in Junos OS Release 14.1, class-of-service (CoS) hierarchical shaping for ATM virtual paths (VPs) is supported on MIC-3D-8OC3-2OC12-ATM.

    The following configuration requirements apply to ATM VP shaping:

    • All ATM interfaces that are members of an interface set must share the same virtual path identifier (VPI) and have a unique virtual circuit identifier (VCI).

    • The ATM interface set can include only ATM interfaces. It cannot include Ethernet interfaces.

    • The ATM interface set cannot include PPPoE over ATM interfaces, but it can include the underlying ATM interface over which PPPoE over ATM is carried.

    To configure an ATM interface set and its members, use the interface-set stanza at the [edit interfaces] or [edit dynamic-profiles profile-name interfaces] hierarchy level, specifying the ATM physical interface (at-slot/mic/port) and logical unit numbers.

    After you configure the ATM interface set, you must create a CoS traffic control profile that includes the peak-rate (peak cell rate, or PCR), sustained-rate (sustained cell rate, or SCR), and max-burst-size (maximum burst size, or MBS) statements to shape the ATM cells transmitted on the ATM MIC. You then associate the traffic control profile to the ATM interface set.

  • Modifications to output fields of test aaa command (MX Series)—Starting in Junos OS Release 14.1. the output of the test aaa [dhcp | ppp] user command is modified to improve readability. The modifications include the following:

    • The output now includes the corresponding tag for service-related attributes. For example, the following output includes the tag number (1) for the filter-service.

      Service Name (1) - filter-service(100,200)

    • The output now includes the service activation type. For example:

      Service Activation Type (1) - 1

    • The junos-adf-rule-v4 output field is now titled IPv4 ADF Rule.

    • The junos-adf-rule-v6 output field is now titled IPv6 ADF Rule.

  • DHCPv6 local server and relay agent username and option 37 (MX Series)—Starting in Junos OS Releases 12.3R7, 13.2R4, 13.3R2, and 14.1R1, the MX Series router supports the generation of an ASCII version of the authentication username. When you configure a DHCPv6 local server or relay agent to concatenate the authentication username with the Agent Remote-ID option 37, the router uses only the remote-id portion of option 37 and ignores the enterprise number.

    The router no longer supports the enterprise-id and remote-id options for the relay-agent–remote-id statement.

  • Realm name parsing (MX Series)—Starting in Junos OS Release 14.1, the router supports realm name delimiters and parsing, when determining domain names that are used for the domain mapping feature. The realm name support is similar to the existing domain name support, and is used when subscriber usernames are presented in the realm name format (such as, abc.com\marilyn) rather than in the typical domain name format (such as, joseph@abc.com). You use the parse-order statement to specify the order in which the router searches for the domain name—you can specify that the router searches first for either the domain name or the realm name in the subscriber username. You can also specify the unique character that is the realm name delimiter, and the parsing direction the router uses to identify the resulting domain name that is used for domain mapping operations.

  • Specifying a domain map for usernames without a domain or realm name (MX Series)—Starting in Junos OS Release 14.1, you can specify a domain map name of none for the map domain-map-name statement at the [edit access domain] hierarchy level. The router uses the domain map named none to perform domain map operations for subscriber usernames that do not include a domain or realm name.

  • MLPPP support for LNS and PPPoE subscribers (MX Series)—Multilink PPP (MLPPP) support is provided for static and dynamic LNS (L2TP network server) and PPPoE (Point-to-Point Protocol over Ethernet) terminated and tunneled subscribers running on the MX Series with access-facing MPC2 slots. The following features are supported:

    • Mixed mode for customers with both MLPPP and single link PPP subscribers

    • Fragmentation-maps for both static and dynamic inline service si interfaces

    • Co-existence support for member link IFL and the bundle IFL on different lookup engines

    • Link fragmentation and interleaving (LFI) for a single-link bundle

    • Minimization of fragment reordering

  • Subscriber management and services feature and scaling parity (MX104)—Starting in Junos OS Release 14.1, the MX104 router supports all subscriber management and services features that are supported by the MX80 router. In addition, the scaling and performance values for the MX104 router match those of the MX80 router.

  • Subscriber management and services feature and scaling parity (MX2010 and MX2020)—Starting in Junos OS Release 14.1, the MX2010 and the MX2020 routers support all subscriber management and services features that are supported by the MX240, MX480, and MX960 routers. In addition, the scaling and performance values for the MX2010 and the MX2020 match those of MX960 routers.

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

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

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

    • Minor error— 6-254 errors per second

    • Major error—255 and more errors per second

User Interface and Configuration

  • New commit check for static label uniqueness—Previously, applications, such as MPLS LSPs and Layer 2 circuits that use static labels, did not check to ensure that an incoming label name was not being used by another application. This caused the routing protocol process (RPD) to generate a core file. Starting in Junos OS Release 14.1, a commit check has been implemented to ensure the uniqueness of static labels across applications.

VLAN Infrastructure

  • VXLAN gateway support (MX80, MX240, MX480, MX960, MX2010, and MX2020)—Starting in Junos OS Release 14.1R2, the MX80, MX240, MX480, MX960, MX2010, and MX2020 support Virtual Extensible Local Area Network (VXLAN) Gateways. Each VXLAN Gateway supports the following functionalities:

    • 32,000 VXLANs with one VXLAN per bridge domain

    • 8000 VXLAN Tunnel End Points (VTEPs)

    • 32,000 multicast groups

    • Switching functionality with traditional Layer 2 networks and VPLS networks

    • Inter VXLAN routing and VXLAN-only bridging domain with IRB

    • Virtual switches

    • VXLAN with VRF functionality

    • Configurable load balancing

    • Statistics for remote VTEP

  • OVSDB support (MX80, MX240, MX480, MX960)—Starting in Release 14.1, 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 through the OVSDB schema, thereby enabling virtual machine (VM) traffic from entities in a virtual network to be forwarded to entities in a physical network and the reverse.

    You can set up a connection between the MX management interface (fxp0) and an NSX controller by using the edit protocols ovsdb controller ip-address statement, and OVSDB-managed Virtual Extensible LANs (VXLANs) by using the edit bridge-domains bridge-domain-name vxlan ovsdb-managed or edit routing-instances routing-instance-name bridge-domain bridge-domain-name vxlan ovsdb-managed statement.

VPNs

  • Control word for BGP VPLS (M320 and MX Series)—For hash calculation, transit routers must determine the payload. While parsing an MPLS encapsulated packet for hashing, a transit router can incorrectly calculate an Ethernet payload as an IPv4 or IPv6 payload if the first nibble of the DA MAC is 0x4 or 0x6, respectively. This false positive can cause out-of-order packet delivery over a pseudowire. Starting in Junos OS Release 14.1, this issue can be avoided by configuring a BGP VPLS PE router to request that other BGP VPLS PE routers insert a control word between the label stack and the MPLS payload.

    [See Control Word for BGP VPLS Overview.]

  • Group VPN member support (MX240, MX480, and MX960)—Starting with Junos OS Release 14.1, MX Series routers with MS-MPC-PIC and MS-MIC-16G line cards provide the group VPN member functionality support with one or more Cisco group controller or key servers (GC/KS). The group members can connect to a maximum of four Cisco GC/KSs with minimum interoperability with the cooperative servers.

    This feature also provides system logging support for the group VPN functionality and routing instance support for both control and data traffic.

    [See Example: Configuring Group VPN on Routing Devices.]

  • IRB interface on EVPNs (MX Series routers with MPCs and MICs only)—In an Ethernet VPN (EVPN) solution, multiple bridge domains can be defined within a particular EVPN instance, and one or more EVPN instances can be associated with a single Layer 3 VPN VRF. In general, each data center tenant is assigned a unique Layer 3 VPN VRF, although the tenant can consist of one or more EVPN instances or bridge domains per EVPN instance.

    To support this flexibility and scalability factor, beginning with Junos OS Release 14.1, the EVPN solution provides support for the integrated routing and bridging (IRB) interface on MX Series routers containing MPC interfaces to facilitate optimal Layer 2 and Layer 3 forwarding along with virtual machine mobility. The IRB interfaces are configured on each configured bridge domain including the default bridge domain for an EVPN instance.

    [See Example: Configuring EVPN with IRB Solution.]

  • Virtual switch support for EVPNs (MX Series routers with MPCs and MICs only)—Starting with Junos OS Release 14.1, the Ethernet VPN (EVPN) solution on MX Series routers with MPC interfaces is extended to provide virtual switch support that enables multiple tenants with independent VLAN and subnet space within an EVPN instance. Virtual switch provides the ability to extend Ethernet VLANs over a WAN using a single EVPN instance while maintaining data-plane separation between the various VLANs associated with that instance. A single EVPN instance can stretch up to 4094 bridge domains defined in a virtual switch to remote sites.

    [See Example: Configuring EVPN with Support for Virtual Switch.]

  • Multihoming support for EVPNs (MX Series routers with MPCs and MICs only)—Starting with Junos OS Release 14.1, the Ethernet VPN (EVPN) solution on MX Series routers with MPC interfaces is extended to provide multihoming functionality in the active-standby redundancy mode of operation.

    To enable EVPN active-standby multihoming, include the single-active statement at the [edit interfaces esi] hierarchy level.

    [See Example: Configuring EVPN Multihoming.]

  • VRF localization (MX Series routers with MPC line cards)—Starting with Junos OS Release 14.1R3, 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.

  • Integrating EVPN with VXLAN for Layer 2 data center interconnect (MX Series routers 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.

    Although several solutions are available for data center connectivity, the integration of EVPN with VXLAN starting in Junos OS Release 14.1R4 provides an added advantage over the existing MPLS data center interconnect (DCI) technologies.

    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 routers with DPCs)—Starting with Junos OS Release 14.1R4, 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.

  • Active-active multihoming support for EVPNs (MX Series routers with MPCs and MICs only)—Starting with Junos OS Release 14.1R4, the Ethernet VPN (EVPN) solution on MX Series routers with MPC and MIC interfaces is extended to provide multihoming functionality in the active-active redundancy mode of operation. This feature enables load balancing of Layer 2 unicast traffic across all the multihomed links on and toward a customer edge device.

    The EVPN active-active multihoming feature provides link-level and node-level redundancy along with effective utilization of resources.

    To enable EVPN active-active multihoming, include the all-active statement at the [edit interfaces esi] hierarchy level.