New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers

The following features have been added to JUNOS Release 10.1. Following the description is the title of the manual or manuals to consult for further information.

Class of Service

Intelligent oversubscription service support (MX Series routers with Trio MPC/MIC interfaces)—Arriving packets are assigned to one of two traffic classes (control and best-effort) based on their header types and destination MAC address. This allows for lower priority packets to be dropped more intelligently when oversubscription occurs. Only packets mapped to queue 3 are marked as control packets. Protocols such as telnet, FTP, and SSH that are mapped to queue 0 are classified as best-effort. No configuration is necessary, but the queue assignments can be altered with a multifield classifier.
[Class of Service]
CoS aspects of the MPC/MIC (MX Series routers with Trio MPC/MIC interfaces)—Cover all aspects of CoS configuration for this hardware combination. Support includes shaping rates at the queue level, configurable bandwidth profiles with percentages, dynamic bandwidth allocation among different services, scheduler node scaling, and delay buffer allocation. To configure, include the relevant statements at the [edit class-of-service] hierarchy level and apply them if necessary at other hierarchy levels such as the [edit interfaces] hierarchy level.
[Class of Service, Network Interfaces]
Per-priority shaping (MX Series platforms with Trio MPC/MIC interfaces)—Enables you to configure a separate shaping rate for each of the five priority levels so that higher priority services such as voice and video do not starve lower priority services such as data. To configure, include the shaping-rate-(excess | priority)-level rate [ burst-size burst ] statement at the [edit class-of-service traffic-control-profiles tcp-name] hierarchy level and apply the traffic control profile at the [edit interfaces] hierarchy level.
[Class of Service]
Distribute excess bandwidth among different services for a subscriber (MX Series routers with Trio MPC/MIC interfaces)—Service providers often use tiered services that must carry excess bandwidth as traffic patterns vary. By default, excess bandwidth between a configured guaranteed rate and shaping rate is shared equally among all queues, which might not be optimal for all subscribers to a service. You can control the distribution of this excess bandwidth with the excess-rate statement. To configure the excess rate for a traffic control profile, include the excess-rate statement at the [edit class-of-service traffic-control-profiles tcp-name] hierarchy level and apply the traffic control profile at the [edit interfaces] hierarchy level. To configure the excess rate for a queue, include the excess-rate and excess-priority statements at the [edit class-of-service scheduler scheduler-name] hierarchy level.
[Class of Service]
Scheduler node scaling (MX Series routers with Trio MPC/MIC interfaces)—The hardware supports multiple levels of scheduler nodes. In per-unit-scheduling mode, each logical interface (unit) can have four or eight queues and has a dedicated level 3 scheduler node. The logical interfaces share a common level 2 node (one per port). In hierarchical-scheduling mode, a set of logical interfaces, each with four or eight queues, has a level 2 CoS profile and one of its logical interface children has a level 3 CoS profile. To better control system resources in hierarchical-scheduling mode, you can limit the number of hierarchical levels in the scheduling hierarchy to two. In this case, all logical interfaces and interface sets with CoS profiles share a single (dummy) level 2 node, thereby increasing the maximum number of logical interfaces with CoS profiles (the interface sets must be at level 3). To configure scheduler node scaling, include the maximum-hierarchy-levels statement at the [edit interfaces xe-fpc/pic/port hierarchical-scheduler] hierarchy level. The only supported value is 2.
[Class of Service, Network Interfaces]
Forwarding-class aliases (M320 and T Series routers)—Enable you to configure up to 16 forwarding classes and 8 queues, with multiple forwarding classes assigned to single queues. To configure, include the class and queue-num statements at the [edit class-of-service forwarding-classes] hierarchy level.
[Class of Service]
VLAN shaping on aggregate devices (MX Series routers with Trio MPC/MIC interfaces)—VLAN shaping (per-unit scheduling) is supported on aggregated Ethernet interfaces when link protection is enabled on the aggregated Ethernet interface. When VLAN shaping is configured on aggregate Ethernet interfaces with link protection enabled, the shaping is applied to the active child link. To configure link protection on aggregated Ethernet interfaces, include the link-protection statement at the [edit interfaces aex aggregated-ether-options] hierarchy level. Traffic passes only through the designated primary link. This includes transit traffic and locally generated traffic on the router. When the primary link fails, traffic is routed through the backup link. You also can reverse traffic, from the designated backup link to the designated primary link. To revert back to sending traffic to the primary designated link when traffic is passing through the designated backup link, use the revert command; for example, request interfaces revert ae0. To configure a primary and a backup link, include the primary and backup statements at the [edit interfaces ge-fpc/pic/port gigether-options 802.3ad aex] hierarchy level or the [edit interfaces xe-fpc/pic/port fastether-options 802.3ad aex] hierarchy level. To disable link protection, delete the link-protection statement at the [edit interfaces aex aggregated-ether-options link-protection] hierarchy level. To display the active, primary, and backup link for an aggregated Ethernet interface, use the operational mode command show interfaces redundancy aex.
[Class of Service, Network Interfaces]
Re-marking of MVPN GRE encapsulation DCSP at ASBR (MX Series routers with Trio MPC/MIC interfaces)—Enables you to configure DSCP marking for GRE encapsulated packets that aligns with the service provider core CoS policy for an MVPN. To configure, include the DSCP rewrite-rule dscp dscp-rule-name with the values at the [edit class-of-service] hierarchy level and then apply the rewrite rule to the core-facing multicast interface at the [edit class-of-service interfaces] hierarchy level.
[Class of Service]
PD-5-10XGE-SFPP, 10-port 10-Gigabit Ethernet (Type 4) PIC (T640, T1600, and TX Matrix routers with G-FPC4, ST-FPC4, and ST-FPC4.1)—Supports a WAN bandwidth of 100 Gbps in addition to the following features:
- Intelligent handling of oversubscribed traffic
- Line rate operation on up to five 10-Gigabit Ethernet ports
- Tap features, such as flexible encapsulation, source address (SA) MAC learning, MAC accounting, and MAC policing
- Stacked virtual LAN (VLAN) tag and VLAN rewrite functionalities
[Network Interfaces, Class of Service, PIC Guide]
Intelligent oversubscription services (MX Series with 16-port 10-Gigabit Ethernet MPC with SFP+)—The 16-port 10-Gigabit Ethernet Modular Port Concentrator (MPC) is an oversubscribed configuration. Consequently, it is necessary to protect control traffic over best-effort traffic as soon as packets enter the line card. To do this, packets entering the line card are assigned a preclassifier control traffic class according to the header types (such as destination MAC addresses, and Layer 4 ports) in the packet. The preclassifier provides a good way to classify and queue important control traffic in a different high-priority queue from that used for best-effort traffic.
The preclassifier (control or best effort) is assigned prior to packets being accepted into the initial stream and is used by the line card as an early designation (before any class-of-service configuration is applied). When oversubscription occurs, control traffic will be queued separately and should not be subject to any dropped packets.
The Layer 2 protocols supporting the preclassifier are:
- 802.1ah
- 802.1g
- 802.1x
- 802.3ad
- ARP
- GMRP
- GVRP
- LACP
- PVST
- xSTP
The Layer 3 protocols supporting the preclassifier are:
- IGMP
- IPv4/IPv6 ICMP
- IPv4/IPv6 ISIS
- IPv4/IPv6 OSPF
- IPv4/IPv6 PIM
- IPv4 Router Alert
- IPv4/IPv6 RSVP
- IPv4/IPv6 VRRP
The Layer 4 protocols supporting the preclassifier are:
- IIPv4/ IPv6 BGP
- IPv4/ IPv6 LDP
- IPv4 UDP/L2TP
- RIP (UDP port checks)
The preclassifier is also supported on label-switching encapsulation PPP.
[Class of Service]
Feature support on 16-port 10-Gigabit Ethernet MPC with SFP+ (MX Series routers)—The following features are supported on the 16-port 10-Gigabit Ethernet MPC with SFP+:
- Accepts traffic destined for GRE tunnels or DVMRP (IP-in-IP) tunnels (JUNOS Release 10.0R2)
- Bidirectional Forwarding Detection (BFD) protocol (JUNOS Release 10.0R2)
- Border Gateway Protocol (BGP) (JUNOS Release 10.0R2)
- BGP/Multiprotocol Label Switching (MPLS) virtual private networks (VPNs) (JUNOS Release 10.0R2)
- Distance Vector Multicast Routing Protocol (DVMRP) and generic routing encapsulation (GRE) support, access side and server side (JUNOS Release 10.0R2)
- Firewall filters (JUNOS Release 10.0R2)
- Flexible Ethernet encapsulation (JUNOS Release 10.0R2)
- Graceful Routing Engine switchover (GRES) (JUNOS Release 10.0R2)
- Ingress differentiated (JUNOS Release 10.0R2)
- Differentiated Services code point rewrite (DSCP) (JUNOS Release 10.0R2)
- Intelligent oversubscription (JUNOS Release 10.0R2)
- Integrated routing and bridging (IRB) (JUNOS Release 10.1R1)
- Intermediate System-to-Intermediate System (IS-IS) (JUNOS Release 10.0R2)
- Internet Group Management Protocol (IGMP) (excludes snooping) (JUNOS Release 10.0R2)
- IPv4 (JUNOS Release 10.0R2)
- IP multicast (JUNOS Release 10.0R2)
- Label Distribution Protocol (LDP) (JUNOS Release 10.0R2)
- Labeled-switched path (LSP) accounting, policers, and filtering (JUNOS Release 10.0R2)
- LAN-PHY mode (JUNOS Release 10.0R2)
- Layer 2 frame filtering (JUNOS Release 10.0R2)
- IEEE 802.3ad link aggregation (JUNOS Release 10.0R2)
- Link Aggregation Control Protocol (LACP) (JUNOS Release 10.0R2)
- Local loopback (JUNOS Release 10.0R2)
- MAC learning, policing (JUNOS Release 10.0R2)
- Multiple tag protocol identifiers (TPIDs), accounting, and filtering (JUNOS Release 10.0R2)
- Multiprotocol Label Switching (MPLS) (JUNOS Release 10.0R2)
- Nonstop active routing (NSR) (JUNOS Release 10.0R2)
- Multitopology routing (MTR) (JUNOS Release 10.0R2)
- Open Shortest Path First (OSPF) (JUNOS Release 10.0R2)
- Packet mirroring (JUNOS Release 10.0R2)
- Quality of service (QoS) per port: (JUNOS Release 10.0R2)
  - Eight queues per port
  - Excess-rate configuration at the traffic-control-profile level
  - Excess-rate and excess-priority configuration at the queue level
  - Shaping at the port level
  - Shaping at the queue level
  - Scheduling of queues based on weighted round-robin (WRR) per priority class
  - Tricolor marking
  - Weighted random early detection (WRED)
- QoS per virtual LAN (VLAN): (JUNOS Release 10.0R2)
  - Accounting, filtering, and policing
  - IEEE 802.1p rewrite
  - Classification
  - Excess-rate configuration at the traffic-control-profile level
  - Tricolor marking
- Resource Reservation Protocol (RSVP) (JUNOS Release 10.0R2)
- Routing Information Protocol (RIP) (JUNOS Release 10.0R2)
- Simple Network Management Protocol (SNMP) (JUNOS Release 10.0R2)
- IEEE 802.1Q VLANs: (JUNOS Release 10.0R2)
  - VLAN stacking and rewriting
  - Channels defined by two stacked VLAN tags
  - Flexible VLAN tagging
  - IP service for nonstandard TPID and stacked VLAN tags
- Virtual private LAN service (VPLS) (JUNOS Release 10.0R2)
- Virtual private network (VPN) (JUNOS Release 10.0R2)
- Virtual Router Redundancy Protocol (VRRP) for IPv4 (JUNOS Release 10.0R2)
To support these features, some modifications have been made to the following configuration statements:
- The ability to configure the DSCP as the action of a filter rule is already present in the JUNOS Software. However, with this line card, the value range permitted is modified from 0, to 0 through 63. To include DSCP as the action of a filter rule, include the dscp value parameter at the [edit firewall filter filter-name] hierarchy level.
- To fully leverage the features offered through the new chipset on the line card, include the enhanced-hash-key option at the [edit forwarding-options] hierarchy level.
[Class of Service]
IEEE 802.1ak-2007 MVRP (MX Series routers)—The Multiple VLAN Registration Protocol (MVRP) is a standards-based Layer 2 network protocol used among switches to dynamically share and update VLAN information with other bridges. VLAN information exchanged includes:
- The set of VLANs that currently have active members
- The ports through which the active members can be reached
To operate MVRP, edge ports should have the static VLAN configuration. The edge ports will not be configured for MVRP. MVRP is only enabled on the core-facing trunk ports where no static VLANs are configured.
To configure MVRP, include the mvrp statement and desired options at the [edit protocols] hierarchy level.
[Class of Service]
Elevated packet drops during oversubscription (MX Series routers with Trio MPC/MIC interfaces)—During periods of oversubscription, the WRED process drops more packets than expected from relatively full queues. There is no configuration for this feature, which transparently applies scaling to oversubscribed queues.
[Class of Service]

High Availability

Enhancements to unified ISSU support on PICs (T Series)—JUNOS Release 10.1 extends unified ISSU support for the following PICs to T Series routers:
- PB-1CHOC12-STM4-IQE-SFP, 1-port channelized OC12/STM4 enhanced IQ PIC
- PB-1OC12-STM4-IQE-SFP, 1-port nonchannelized OC12/STM4 enhanced IQ PIC
- PB-4CHDS3-E3-IQE-BNC, 4-port channelized DS3/E3 enhanced IQ PIC
- PB-4DS3-E3-IQE-BNC, 4-port non-channelized DS3/E3 enhanced IQ PIC
[High Availability]

Interfaces and Chassis

New 60-Gigabit Ethernet Queuing MPC (model number MX-MPC2-3D-Q)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
New 60-Gigabit Ethernet MPC (model number MX-MPC2-3D)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
New 60-Gigabit Ethernet Enhanced Queuing MPC (model number MX-MPC2-3D-EQ)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
New 20-port Gigabit Ethernet MIC with SFP (model number MIC-3D-20GE-SFP)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
New Modular Port Concentrators (MPCs) and Modular Interface Cards (MICs)—Supported on MX Series platforms. Up to two MICs plug into the MPC to provide the physical interface for the MPC line card. The MPCs provide increased capacity on Gigabit Ethernet and 10-Gigabit Ethernet hardware. For a list of supported MPCs and MICs, see the MX Series Line Card Guide.
[Network Interfaces]
New 4-port 10-Gigabit Ethernet MIC with XFP (model number MIC-3D-4XGE-XFP)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
Layer 2 VPLS, IRB, and mesh group feature parity (MX Series routers with Trio MPC/MIC interfaces)—Support for Layer 2 feature parity with JUNOS Release 9.1 on MX Series routers that include Trio Modular Port Concentrators (MPCs) and Modular Interface Cards (MICs).
Layer 2 feature parity includes:
- Layer 2 bridging
- VPLS forwarding
- MAC address learning, aging, and MAC address limit
- Mesh group support
- Implicit VLAN mapping
- Integrated routing and bridging (IRB)
- Multicast over IRB
- MAC statistics
Layer 2 features that are not supported in this release include:
- Spanning Tree Protocols (xSTP)
  - VLAN Spanning Tree Protocol (VSTP)
  - Multiple Spanning Tree Protocol (MSTP)
  - Rapid Spanning Tree Protocol (RSTP)
  - Layer 2 Tunneling Protocol (L2TP)
Upgrading a T1600 router to be the LCC0 of the TX Matrix Plus platform—You can now upgrade an operational T1600 router to be the lcc0 in a newly configured TX Matrix Plus platform. The procedures require JUNOS Release 10.1 on the TX Matrix Plus router and the T1600 router. Reboot is required to transfer control of the T1600 router to the routing matrix. You can also downgrade the lcc0 to a standalone T1600 router by rolling back to the former configuration. Upgrade and integration of subsequent operational T1600 routers to form lcc1 and lcc2 (and so on) is not supported. Use the offline procedures to upgrade and integrate the remaining T1600 routers into the routing matrix.
[TX Matrix Plus Hardware, System Basics and Services Command Reference]
Per-unit scheduling for GRE tunnels using IQ2 PICs (M7i, M10i, M120, and M320 routers with E3–FPC)—Supports enhanced IQ2 PIC and IQ2E PIC performance, adding all functionality of tunnel PICs. The QoS for the GRE tunnel traffic will be applied as the traffic is looped through the IQ2/IQ2E PIC.
Shaping is performed on full packets that pass through the GRE tunnel.
IQ2 and IQ2E PICs support all interfaces that are supported on tunnel PICs, as follows:
- gr-fpc/pic/port
- vt-fpc/pic/port
- lt-fpc/pic/port
- ip-fpc/pic/port
- pe-fpc/pic/port
- pd-fpc/pic/port
- mt-fpc/pic/port
The port variable is always zero.
The provided tunnel functionality is the same as that of regular tunnel PICs.
When tunnel services are enabled on IQ2 and IQ2E PICs, they work exclusively as tunnel PICs. The physical ports on the PICs cannot be used in tunnel mode. To configure exclusive tunnel mode, use the tunnel-only statement at the [chassis fpc number pic number] hierarchy level.
You can use the show interfaces queue gr-fpc/pic/port command to display statistics for the specified tunnel.
[Network Interfaces, Class of Service, PIC Guide]
Root System Domain (RSD) configuration of logical interface filters on shared interfaces (JCS1200 platform)—Enables Root System Domain (RSD) configuration support for logical interface filters on shared interfaces. In previous releases, logical interface filters were configured on each Protected System Domain (PSD). This release supports configuration on the RSD.
To configure a logical interface filter on the RSD, apply the firewall filter to the logical interface on the shared interface by including the filter output filter-name statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level on the RSD.
Filtering is performed on the PSD, but logical interface filters configured on the RSD are applied automatically by the PSD. Filters configured on the RSD can co-exist with filters configured on the PSD. Counter statistics related to PSD filtering are available on the RSD.
[Protected System Domain]
Two new AC power supply modules in chassis—The JUNOS Software now supports two new AC power supply modules on T640 and T1600 routers: AC Power Entry Module 10kW US and AC Power Entry Module 10kW EMEA (for U.S. and EMEA markets, respectively). The two Power Entry Modules (PEMs) cannot interoperate and the JUNOS Software reports an alarm when they do. The show chassis environment pem command output will show AC Input: status instead of DC Input: status and the Temperature will show the actual temperature reading. Two new power supply descriptions, US and EMEA, are added to distinguish the new modules from existing ones in the output of the show chassis hardware command output.
[System Basics and Service Command Reference]
Next-hop cloning and permutations disabled in T Series enhanced scaling FPCs (FPC Type 1-ES, FPC Type 2-ES, FPC Type 3-ES, and FPC Type 4-ES)—The next-hop cloning and permutations are now disabled in these FPCs with enhanced load-balancing capability. As a result, the memory utilization is reduced for a highly scaled system with a high number of next hops on ECMP or aggregated interfaces.
[System Basics]
Fragmentation support for GRE-encapsulated packets (Multiservices DPC) (M120, M7i/M10i with enhanced CFEB, M320 with E3 FPC, and MX Series routers only)—Enables the Packet Forwarding Engine to update the IP identification field in the outer IP header of packets encapsulated with generic routing encapsulation (GRE), so that reassembly of the packets is possible after fragmentation. The previous CLI constraint check that requires you to configure either the clear-dont-fragment-bit statement or a tunnel key with the allow-fragmentation statement is no longer enforced. There are no associated changes to the CLI statements or operational mode commands.
Note: For other routers, the earlier configuration constraint check still holds.
[Services Interfaces, MPLS Applications, MX Series Layer 2 Configuration Guide]
NAT compliance enhancements—Add modifications to the existing NAT functionality on the services PICs to achieve compliance with RFCs UDP 4787, TCP 5382, and ICMP 5508. These enhancements apply to IPv4–IPv4, IPv6–IPv6, and IPv4–IPv6 source NAT and are not supported with destination NAT. New CLI configuration settings associated with RFC 4787 include the mapping-timeout statement at the [edit services nat pool pool-name] hierarchy level and the address-pooling, filtering-type, and mapping-type statements at the [edit services nat rule rule-name term term-name then translated] hierarchy level. There are no associated changes to the operational mode commands.
[Services Interfaces]
Support for VRF in Routing Engine-based sampling on M Series, M320, MX Series, M120, and T Series routers—For VRF Routing Engine-based sampling, the kernel queries the correct VRF route table based on the ingress interface index for the received packet. For interfaces configured in VRF, the sampled packets contain the correct input and output interface SNMP index, the source and destination AS numbers, and the source and destination mask.
There are two ways to verify the sampled packets. The first is to include the file sampled statement at the [edit forwarding-options sampling traceoptions] hierarchy level and the local dump statement at the [edit forwarding-options family inet output flow-server server] hierarchy level, and check the sampled file using the tail –f /var/tmp/sampled command from the router shell. The second is to export and verify the sampled packets to the flow-server.
[Services Interfaces, Feature Guide]
New 4-port Channelized OC12 Enhanced Intelligent Queuing (IQE) type 3 PIC (M Series and T Series routers)—Provides increased channelization and an improved QoS model; with channelization capabilities and scaling that make it ideal for edge aggregation.
Improved QoS functionality supports policing based on DSCP/IPPREC/EXP, five priority levels, two shaping rates (CIR and PIR), option to use shared scheduling on set of logical interfaces, DSCP rewrite on ingress, and configurable delay buffers for queueing. The QoS capabilities provide service differentiation for service providers.
The interface configuration syntax of existing IQ PICs is retained, but configuration limits are changed to match the augmented capabilities of IQE PICs.
All functionality available on the 4-port Channelized OC12 IQ Type 2 PIC is supported by this PIC.
[Network Interfaces]
Enhanced Intelligent Queuing (IQE) PICs add support for T3 and T1 channelization under SDH framing (M40e, M120, and M320 with Sahara-FPC, and T Series routers)—The following IQE PICs are supported:
- 1-port COC48 IQE
- 4-port COC12 IQE
- 1-port COC12 IQE
- 2-port COC3 IQE
The JUNOS Software supports T1 and CT1 interface types under CAU4. To configure T1 and CT1 interfaces under CAU4, use the t1 and ct1 statements at the [edit interfaces cau4-fpc/pic/port:unit partition number interface-type] hierarchy level.
With T1 and CT1 interface configurations under CAU4 interfaces, you can configure a maximum of 84 T1 or CT1 inerfaces. However, the partition range under CAU4 interfaces was previously restricted to from 1 to 63. This range has increased to from 1 to 84 for T1 and CT1 interfaces.
The JUNOS Software supports T1, CT1, T3, and CT3 interfaces under Channelized AU4 partitions. To configure T1, CT1, T3, and CT3 interfaces under Channelized AU4, use the ct1 and t1 statements at the [edit interfaces cau4-fpc/pic/port:unit partition partition-number] hierarchy level or the ct3 and t3 statements at the [edit interfaces cau4-fpc/pic/port:unit partition number interface-type] hierarchy level.
The JUNOS Software also supports M13 mapped T1 interfaces under CAU4. To configure a T1 interface under CAU4, use the t1 statement at the [edit interfaces cau4-fpc/pic/port:unit partition partition-number interface-type t1] or [edit interfaces cau4-fpc/pic/port:unit partition partition-number interface-type ct1] hierarchy level.
The JUNOS Software does not allow combined configurations of E1 and E3 interfaces together under a CAU4 interface.
Similarly, you cannot mix T1, E1, T3, and E3 interfaces directly under CAU4.
Note: The TUG-3 partition is not supported.
ITU-T VT-mapping in combination with TUG3 partition is not supported.
[Network Interfaces, PIC Guide]
Stateful firewall chaining for FTP, TFTP, and RTSP data sessions (MX Series routers with Multiservices DPCs, and M120 or M320 routers with Multiservices 400 PICs)—Adds support for stateful firewall rule sets in Dynamic Application Awareness for JUNOS Software service chains. New application-level gateways (ALGs) are available for FTP (junos-ftp), TFTP (junos-tftp), and RTSP (junos-rtsp); you can include them as values for the applications statement at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level. In addition, you can include new statement options at the [edit interfaces ms-fpc/pic/port services-options ignore-errors] hierarchy level to enable stateful firewall sessions to operate in a no-drop mode and ignore various traffic errors that would normally result in dropped packets. There are no CLI changes in the APPID, IDP, AACL, or L-PDF configurations. The associated operational mode commands should report the new applications when identified.
[Services Interfaces]

JUNOS XML API and Scripting

New JUNOS XML API operational request tag elements—Table 1 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 10.1, along with the corresponding CLI command and response tag element for each one.

Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.1

Request Tag Element	CLI Command	Response Tag Element
<clear-dhcpv6-server-binding-information> clear_dhcpv6_server_binding_information	clear dhcpv6 server binding	NONE
<clear-dhcpv6-server-statistics-information> clear_dhcpv6_server_statistics_information	clear dhcpv6 server statistics	NONE
<clear-mpls-static-lsp-information> clear_mpls_static_lsp_information	clear mpls static-lsp	NONE
<clear-mvrp-interface-statistics> clear_mvrp_interface_statistics	clear mvrp statistics	NONE
<clear-idp-appddos-cache> clear_idp_appddos_cache	clear security idp application-ddos cache	NONE
<clear-idp-status-information> clear_idp_status_information	clear security idp status	<clear-idp-status-information>
<clear-vrrp-information> clear_vrrp_information	clear vrrp	<vrrp-message>
<clear-vrrp-interface-statistics> clear_vrrp_interface_statistics	clear vrrp interface	<vrrp-message>
<request-script-refresh-from> request_script_refresh_from	request system scripts refresh-from	NONE
<get-dhcpv6-server-binding-information> get_dhcpv6_server_binding_information	show dhcpv6 server binding	<dhcpv6-server-binding-information>
<get-dhcpv6-server-statistics-information> get_dhcpv6_server_statistics_information	show dhcpv6 server statistics	<dhcpv6-server-statistics-information>
<get-mpls-static-lsp-information> get_mpls_static_lsp_information	show mpls static-lsp	<mpls-static-lsp-information>
<get-mvrp-information> get_mvrp_information	show mvrp	<mvrp-information>
<get-mvrp-applicant-information> get_mvrp_applicant_information	show mvrp applicant-state	<mvrp-applicant-state>
<get-mvrp-dynamic-vlan-memberships> get_mvrp_dynamic_vlan_memberships	show mvrp dynamic-vlan-memberships	<mvrp-vlan-information>
<get-mvrp-interface-information> get_mvrp_interface_information	show mvrp interface	<mvrp-interface-information>
<get-mvrp-registration-state> get_mvrp_registration_state	show mvrp registration-state	<mvrp-registration-information>
<get-mvrp-interface-statistics> get_mvrp_interface_statistics	show mvrp statistics	<mvrp-interface-statistics>
<get-idp-subscriber-policy-list> get_idp_subscriber_policy_list	show security idp policies	<idp-subscriber-policy-list>
<get-idp-policy-template-information> get_idp_policy_template_information	show security idp policy-templates-list	<idp-policy-template-information>
<get-idp-detail-status-information> get_idp_detail_status_information	show security idp status detail	<idp-detail-status-information>
<get-service-nat-mapping-information> get_service_nat_mapping_information	show services nat mappings	<service-nat-mapping-information>
<get-task-memory-information> get_task_memory_information	show task memory	<task-memory-information>
<get-vrrp-information> get_vrrp_information	show vrrp	<vrrp-information>
<get-vrrp-interface-information> get_vrrp_interface_information	show vrrp interface	<vrrp-information>
<get-vrrp-track-interfaces> get_vrrp_track_interfaces	show vrrp track	<vrrp-information>

[JUNOS XML API Operational Reference]

MPLS Applications

Static LSPs at the ingress router—You can now configure a named static LSP at the ingress router. This feature allows you to configure multiple static LSPs between two specific routers. It is not necessary to configure unique names for static versus dynamic LSPs (a static LSP could have the same name as a dynamic LSP configured on the same router). This feature also allows you to configure a single-hop static LSP by specifying either an explicit null label or no label.
To configure a static LSP on an ingress router, include the ingress statement at the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level. You must also configure the to and next-hop statements at the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level. You can optionally configure the push statement. If you configure the push statement, you must specify a non-reserved label in the range of 0 through 1,048,575.
To display information about ingress static LSPs, issue the show mpls lsp static ingress command. To display routing table entries corresponding to ingress static LSPs, issue the show route table inet.3 command or the show route next-hop next-hop-ip-address static-label-switched-path static-lsp-name command.
[MPLS, Routing Protocols and Policies Command Reference]
Static LSPs at the transit router—You can now configure a named static LSP on a transit router. To configure a transit static LSP, include the transit statement at the [edit protocols mpls static-label-switched-path path-name] hierarchy level and include the next-hop statement at the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level. You must also configure either the pop or the swap statement at the [edit protocols mpls static-label-switched-path static-lsp-name transit] hierarchy level. If you configure the swap statement, you must specify a non-reserved label in the range of 0 through 1,048,575.
The transit static LSP is added to the mpls.0 routing table. You should configure each static LSP using a unique name and at least a unique incoming label on the router. Each transit static LSP can have one or more incoming labels configured. If a transit LSP has more than one incoming label, each would effectively operate as an independent LSP, meaning you could configure all of the related LSP attributes for each incoming label. The range of incoming labels available is limited to the standard static LSP range of labels (1,000,000 through 1,048,575). To verify that a static LSP has been added to the routing table, issue the show route table mpls.0 command.
[MPLS]
Bypass static LSPs—You can now configure a named bypass static LSP for ingress and transit static LSPs, to be used if the primary LSP fails. To configure a bypass static LSP, include the bypass statement at the [edit protocols mpls static-label-switched-path path-name] hierarchy level. You must also configure the to and next-hop statements at the [edit protocols mpls static-label-switched-path static-lsp-name bypass] hierarchy level. You can also configure link and node protection for static LSPs. If you configure both link and node protection for the static LSP and the primary link fails, the node protection feature is preferred.
[MPLS]
Static LSP revert timer—You can now configure a revert timer for ingress and transit static LSPs. After traffic has been switched to a bypass static LSP, it is typically switched back to the primary static LSP when it comes back up. There is a configurable delay in the time (called the revert timer) between when the primary static LSP comes up and when traffic is reverted back to it from the bypass static LSP. This delay is needed because when the primary LSP comes back up, it is not certain whether all of the interfaces on the downstream node of the primary path have come up yet. The delay range is from 0 through 65,535 seconds and is configurable at each interface. If you configure a value of 0, traffic is never automatically reverted to the primary LSP, even if it does come back up. The only exception is if the bypass LSP goes down. The default value is 5 seconds. To configure the revert timer for an interface, include the protection-revert-time statement at the [edit protocols mpls interface interface-name static] hierarchy level. You can display the revert timer value for an interface using the show mpls interface detail command.
[MPLS]
Static LSP traceoptions—You can now configure the traceoptions statement to trace messages related to ingress and transit static LSPs by including the static flag at the [edit protocols mpls traceoptions flag] hierarchy level.
[MPLS]
Static LSP statistics—You can now display statistics related to MPLS static LSPs by issuing the show mpls static-lsp statistics command and the monitor static-lsp lsp-name command. The show mpls static-lsp statistics command includes the following options: ingress, transit, bypass, and name static-lsp-name. This command displays the packet count and byte count for the static LSP. You can clear the statistics for static LSPs by issuing the clear mpls static-lsp statistics command. You can also log the static LSP statistics to a file by specifying a file for the MPLS statistics statement. You can configure this file using the set protocols mpls statistics interval interval file filename command.
[MPLS, Routing Protocols and Policies Command Reference]

Multiplay

Border Gateway Function (BGF) RTCP XR reporting—Provides support for the H.248 RECRTCPXR (Received RTCP Extended Reporting) and RECRTCPXRBM (Received RTCP XR Burst Mode) reporting packages. The RECRTCPXR package defines properties and statistics that provide extended quality-of-service metrics received from the gateway controller. The RECRTCPXRBM package defines properties and statistics that provide burst metrics received from the gateway controller. Report data is available to the BGF when the gateway controller sends the relevant XR reporting packets and RTCP monitoring is active. Not all gateway controllers send the extended reporting packets. When XR packets are not received, all XR fields are displayed as 0s (zeroes).
You can use the following existing command to display the RECRTCPXR and RECRTCPXRBM report fields for a given gate-id: show services pgcp gate gateway-name statistics gate-id gate-id.
[Multiplay Solutions, System Basics Command Reference]
Integrated Multi-Services Gateway (IMSG) failed call reporting—Provides more extensive statistics on failed calls through improved show command output.
You can use the following existing command to display statistics on failed calls: show services border-signaling-gateway calls-failed gateway gateway-name.
[Multiplay Solutions, System Basics Command Reference]
Integrated Multi-Services Gateway (IMSG) media release—Enables the IMSG SIP function to release media resources when handling calls between two entities in the same media realm (the virtual interface specified in the PGCP configuration). When the new call usage policies for both entities allow media release, media resources are shared instead of being reserved for both entities. This improves the utilization of media resources and prevents latency.
To configure media release, enter the media-release statement at the [edit services border-signaling-gateway gateway-name sip new-call-usage-policy policy-name term term-name then media-policy] hierarchy level.
[Multiplay Solutions, Services Interfaces]

Routing Policy and Firewall Filters

New MPLS firewall filter match conditions (T Series routers)—The JUNOS Software now supports filtering MPLS-tagged IPv4 packets based on IP parameters for up to five MPLS stacked labels.
To configure the filter match conditions for an MPLS family based on IP parameters, include the from statement at the [edit firewall family family-name filter filter-name term term-name] hierarchy level:
from {match-conditions;}
Note: New filter match conditions are applicable only for MPLS-tagged IPv4 packets. MPLS-tagged IPv6 packets are not supported by this filter.
[Policy Framework, Routing Protocols and Policies Command Reference]

Routing Protocols

BGP support for MDT-SAFI updates without a route target—By default, the JUNOS Software requires MDT-SAFI updates to have a route target attached. Some vendors do not support attaching route targets to the MDT-SAFI updates. For interoperability with these vendors, the JUNOS Software allows importing MDT-SAFI updates without a route target being attached. The MDT-SAFI is imported if the MDT default address in the MDT-SAFI prefix matches the MDT default address configured within the routing instance.
To configure the MDT default address, include the group-address group-address statement at the [edit routing-instances routing-instance-name provider-tunnel pim-ssm] hierarchy level.
[Multicast, Policy Framework]
Distributed periodic packet management support for aggregate interfaces—Extends support for the Bidirectional Forwarding Detection (BFD) protocol to use the periodic packet management daemon (PPMD) to distribute IPv4 sessions over aggregate interfaces. PPMD 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. Only IPv4 BFD sessions over aggregate interfaces are supported. PPMD does not support IPv6 BFD sessions over an aggregate interface or MPLS BFD sessions over an aggregate interface.
[Routing Protocols]
PIM join suppression support—Enables a router to defer sending join messages to an upstream router when identical join messages are sent on the same multiaccess network. This improves scalability and efficiency by reducing the number of identical messages sent to the same router.
This feature is useful when there are a large number of routers on a multiaccess network that will be receiving traffic for a particular multicast group. Suppressing joins at each router saves bandwidth and reduces heavy processing at upstream routers.
PIM join suppression can be implemented per multiaccess interface and per multicast group. It is only needed on downstream routers, and does not need to be implemented on upstream routers in order for it to work.
A tracking bit field on the LAN prune delay hello option is used in the CLI to enable join suppression for downstream routers. By default, the tracking bit is set to 1 and PIM join suppression is disabled. This is the default behavior for JUNOS Release 10.0 and earlier for Juniper Networks routers. With join suppression disabled (T-bit=1), a downstream receiving router will send join messages even if it receives identical joins for the same upstream router, as long as no other router in the network has join suppression enabled. When the tracking bit is set to 0 for at least one neighbor on this interface, join suppression is enabled, and the receiving router will defer sending identical joins. Use reset-tracking-bit in the CLI to enable join suppression.
When an upstream router receives a join message, its behavior is independent of the value of the T-bit in the hello option. When join suppression is triggered, a timer is activated and all sending of joins is deferred for the length of time specified by the timer. This is a random timer with value ranges between 0 to Max Override Interval. The timer is reset each time join suppression is triggered, and the defer period is dependent on other settings in the LAN prune delay, including propagation-delay and override-interval.
Use the show protocols PIM command to see if the reset-tracking-bit is present, indicating that the T-bit has been changed to 0 and PIM join suppression is enabled.
[Multicast, Routing Protocols and Policies Command Reference]
Improve IGMPv3 snooping performance using bulk updates 1a3,14—Whenever an individual interface joins or leaves a multicast group, a new next-hop entry is installed in the routing table and the forwarding table. This can require a lot of processing time when the frequency and number of IGMP join and leave messages are high.
A new configuration statement can be used to accumulate outgoing interface changes and perform bulk updates to the routing table and forwarding table. This reduces the processing time and memory overhead required when processing join and leave messages, thus improving scalability.This is useful for applications such as Internet Protocol television (IPTV), in which users changing channels can create thousands of interfaces joining or leaving a group in a short period of time.
To enable bulk updates of join and leave messages, include the next-hop-hold-time statement and specify the number of milliseconds to wait before processing the messages. The next-hop-hold-time statement can be configured at the [edit routing-instances routing-instance-name] hierarchy level. The hold time can be configured from 1 to 1000 milliseconds. The routing instance must be of type VPLS or virtual-switch.
If the next-hop-hold-time statement is deleted from the router configuration, IGMP bulk updates are disabled. The configuration of the next-hop-hold-time statement can be verified using the show multicast snooping route command.
[Multicast, Routing Protocols and Policies Command Reference]
Hub-and-spoke support for multiprotocol BGP-based multicast VPNs with PIM-SSM GRE S-PMSI transport—Multiprotocol BGP-based (MBGP) multicast VPNs (also referred to as next-generation Layer 3 VPN multicast) can be configured using protocol-independent multicast source-specific multicast (PIM-SSM) selective provider multicast service interface (S-PMSI) tunnels in a hub-and-spoke topology.
This feature is useful in the following scenarios:
- Customer sources and rendezvous points (RPs) are located only in the hub sites and customer receivers are located in spoke sites or other hub sites.
- Customer sources are located only in spoke sites and customer receivers are located only in hub sites.
To configure MBGP MVPNs to use PIM-SSM S-PMSI tunnels in a hub-and-spoke topology:
- Include the group-range statement and specify the group address range at the [edit routing-instances routing-instance-name provider-tunnel selective group group-address source source-address pim-ssm] hierarchy level on all PE routers participating in the MVPN.
- Include the threshold-rate statement and specify zero as the threshold value at the [edit routing-instances routing-instance-name provider-tunnel selective group group-address source source-address] hierarchy level on all PE routers participating in the MVPN.
- Include the family inet-mvpn statement and family inet6-mvpn statement at the [edit routing-instances routing-instance-name vrf-advertise-selective] hierarchy level to selectively advertise routes on PE routers that use one VRF for unicast routing and a separate VRF for MVPN routing.
[VPNs, Routing Protocols, Routing Protocols and Policies Command Reference]

Services Applications

FlowTapLite enhancements—Extend support for interception of IPv6 packets on MX Series, M120, and M320 routers. For IPv6, the global filter taps packets from the default IPv6 routing table and does not tap packets from other VRFs. To tap packets from other VRFs, you can install separate VRF filters. For IPv4, the global filter intercepts all IPv4 packets irrespective of the VRF. The limit for filters remains 3000, which is now shared between IPv4 and IPv6. For example, you can install 3000 IPv4 filters or 3000 IPv6 filters, or a combination of both that totals 3000. You cannot install 3000 IPv4 filters and 3000 IPv6 filters.
No new statements are required to configure these enhancements. However, whether you use IPv6 flow tapping or not, you must include the family inet6 statement at the [edit interfaces vt-fpc/pic/port unit logical-unit-number] hierarchy level.
[Services Interfaces]

Subscriber Access Management

JUNOS subscriber access scaling values (M120, M320, and MX Series routers)—Table 2 lists the DHCP, PPP, and PPPoE scaling values supported for subscriber access in this release of M120, M320, and MX Series routers. In this table, DPC means only MX Series Enhanced Queuing IP Services DPCs (DPCE-R-Q-40GE-SFP and DPCE-R-Q-4XGE-XFP). These DPCs support only DHCP subscribers; they do not support PPP subscribers.

Table 2: Subscriber Access Scaling Values for M120, M320, and MX Series Routers

Subscriber Access Feature	M120/M320	MX240	MX480/960
DHCP client bindings per chassis	–	120,000	120,000

DHCP subscriber VLANs
Per DPC	–	16,000	16,000
Per chassis with DPCs	–	32,000	64,000
Per Trio MPC/MIC	–	64,000	64,000
Per chassis with Trio MPC/MIC	–	64,000	64,000

PPP logical interfaces
Dynamic PPPoE interfaces per chassis	15,999	63,999	63,999
Dynamic PPPoE interfaces per IQ2/IQ2E PIC	4000	–	–
Dynamic PPPoE interfaces per Trio MPC/MIC	–	32,000	32,000
Static interfaces per chassis	15,999	15,999	15,999

PPPoE subscriber VLANs
Per IQ2/IQ2E PIC	2000	–	–
Per chassis with IQ2/IQ2E PIC	8000	–	–
Per Trio MPC/MIC	–	32,000	32,000
Per chassis with Trio MPC/MIC	–	32,000	32,000

PPP connections (logical interfaces) are supported in a range of configurations. For example, 63,999 PPP connections per chassis are supported when all subscribers are configured on the same VLAN. In this case, 63,999 pp0 interfaces are configured under the same VLAN logical interface and the one remaining logical interface is consumed for the single VLAN.

At the other extreme, when you configure each subscriber on a separate VLAN (using stacked VLANs), up to 32,000 PPP connections per chassis are supported. In this case, each subscriber connection consumes two logical interfaces: one for the VLAN logical interface and one for the pp0 logical interface.

The M120, M320, and MX Series routers support a maximum of 2000 different dynamic profiles per chassis. [Subscriber Access]

Support for dynamic CoS for subscriber interfaces on Trio MPC/MIC interfaces (MX Series routers)—Enables you to configure dynamic CoS for subscriber interfaces on Trio MPC/MIC interfaces that are now available on MX Series routers. In earlier releases, dynamic CoS was supported on EQ DPCs only.
To configure dynamic CoS on Trio MPC/MIC interfaces, you must enable the hierarchical scheduler for an interface at the [edit interfaces] hierarchy level. You can then configure dynamic CoS parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level. The CoS parameters are dynamically applied to subscriber’s services when they log in or change services.
Trio MPC/MIC interfaces support CoS for the following interface types: static VLAN, demux, static and dynamic PPPoE, and aggregated Ethernet subscriber interfaces.
In this release, hierarchical CoS for aggregated Ethernet interfaces is supported on the Trio MPC/MIC product when a static VLAN configured over the aggregated Ethernet interface. It is not supported for static or dynamic demux subscriber interfaces configured over aggregated Ethernet.
[Subscriber Access]
Support for CoS on dynamic PPPoE subscriber interfaces (MX Series routers)—Enables you to configure CoS for dynamic PPPoE subscriber interfaces on Trio MPC/MIC interfaces available on MX Series routers and the Intelligent Queuing 2 (IQ2) PIC on M120 and M320 Series routers.
In earlier releases, only static CoS was supported for static PPPoE subscriber interfaces configured on IQ2 PICs on M120 and M320 Series routers.
To configure CoS for a dynamic PPPoE interface, configure the shaping and scheduling parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level. You then attach the traffic control profile to the dynamic PPPoE interface by including the output-traffic-control-profile profile-name statement at the [edit dynamic-profiles profile-name class-of-service interfaces $junos-interface-ifd-name unit $junos-underlying-interface-unit] hierarchy level.
When the subscriber logs in, PPP supplies pp0 as the $junos-interface-ifd-name variable, and supplies the PPPoE logical interface number for the $junos-underlying-interface-unit variable.
[Subscriber Access]

Support for IPv6 for dynamic subscriber services (MX Series routers)—Enables you to configure IPv6 addressing and prefixes for dynamic subscriber services. In earlier releases, dynamic subscriber services supported IPv4 addressing only. You can now configure both IPv4 and IPv6 addressing in the same dynamic profile to grant access and services to IPv4 and IPv6 subscribers.

In this release, IPv6 addressing is supported for static and dynamic VLAN subscriber interfaces and dynamic demux subscriber interfaces.

To enable IPv6 addressing for a static VLAN subscriber interface, include the family inet6 statement at the [edit dynamic profiles profile-name interfaces interface-name unit logical-unit-number] hierarchy level.

To enable IPv6 addressing for a demux subscriber interface, include the family inet6 statement at the [edit dynamic profiles profile-name interfaces demux0] hierarchy level. To enable an IPv6 source address for the interface, specify the new $junos-subscriber-ipv6–address predefined variable with the demux-source statement at the [edit dynamic profiles profile-name interfaces demux0 unit $junos-interface-unit family inet6] hierarchy level. The values for this variable are supplied to the interface by DHCP when the subscriber logs in.

This feature enables you to configure dynamic, classic, and fast update firewall filters for IPv6 families. In addition, you can configure aggregate CoS when IPv4 and IPv6 families share a logical interface, and per-family CoS when IPv4 and IPv6 families do not share a logical interface (such as a demux interface).

The following new predefined variables have been added to implement IPv6 addressing for subscriber services:

Dynamic Profile Variable	Definition
$junos-framed-route-ipv6-address-prefix	Route prefix of an IPv6 access route.
$junos-framed-route-ipv6-nexthop	Next-hop address of an IPv6 access route.
$junos-input-ipv6-filter	Attaches a filter based on RADIUS VSA 26-106 (IPv6-Ingress-Policy-Name) to the interface.
$junos-ipv6-ndra-prefix	IPv6 prefix value used when configuring the Router Advertisement protocol.
$junos-output-ipv6-filter	Attaches a filter based on RADIUS VSA 26-107 (IPv6-Egress-Policy-Name) to the interface.
$junos-preferred-source-ipv6-address	Selects the preferred IPv6 source address associated with the loopback address used for the subscriber.
$junos-subscriber-ipv6-address	IPv6 address of the subscriber.

RADIUS supports activation, deactivation, and change of authorization (CoA) for IPv6 services. The following new RADIUS attributes and VSAs have been added to implement IPv6 addressing for subscriber services:

Attribute Number	Attribute Name
97	Framed-IPv6-Prefix
99	Framed-IPv6-Route
26-106	IPv6-Ingress-Policy-Name
26-107	IPv6-Egress-Policy-Name
26-129	IPv6-NdRa-Prefix
26-151	IPv6-Acct-Input-Octets
26-152	IPv6-Acct-Output-Octets
26-153	IPv6-Acct-Input-Packets
26-154	IPv6-Acct-Output-Packets
26-155	IPv6-Acct-Input-Gigawords
26-156	IPv6-Acct-Output-Gigawords
26-157	IPv6-NdRa-Pool-Name

You can monitor IPv6 statistics by issuing the show subscribers and show network-access aaa subscriber commands.

[Subscriber Access]

Support for dynamic PPPoE interfaces (M120, M320, and MX Series routers)—Enables you to configure dynamically created PPPoE logical interfaces over statically created underlying interfaces. For subscriber access purposes, the dynamic PPPoE logical interface represents a dynamic PPPoE subscriber interface. The router automatically and transparently creates the dynamic interface in response to an external event, such as the receipt of traffic on an underlying interface. For example, the router creates a dynamic PPPoE logical interface when it receives a PPPoE Active Discovery Request (PADR) control packet from the client on an underlying interface to which a PPPoE dynamic profile is assigned. The router uses the information configured in the dynamic profile to determine the properties of the dynamic PPPoE logical interface.
The use of dynamically created PPPoE interfaces gives you the flexibility of having the router create the dynamic PPPoE logical interface only when the subscriber logs in on the associated underlying interface. By contrast, statically created interfaces always allocate and consume system resources upon interface creation, even when no traffic is flowing on the interface. Configuring and using dynamically created interfaces helps you effectively and conveniently manage subscriber access networks that provide services to large numbers of subscribers.
Configuration of dynamic PPPoE logical interfaces is supported on Intelligent Queuing 2 (IQ2) PICs on M120 and M320 Series routers, and on Trio MPC/MIC interfaces on MX Series routers.
To configure a dynamic PPPoE logical interface:
1. Configure a dynamic profile to define the attributes of the dynamic PPPoE logical interface. To do so, include the following statements at the [edit dynamic-profiles profile-name] hierarchy level:
  dynamic-profiles {profile-name {interfaces pp0 {unit $junos-interface-unit {keepalives interval seconds;no-keepalives;pppoe-options {underlying-interface "$junos-underlying-interface";server;}ppp-options {chap;pap;}family inet {unnumbered-address interface-name;address address;service {input {service-set service-set-name <service-filter filter-name>;}output {service-set service-set-name <service-filter filter-name>;}}filter {input filter-name;output filter-name;}}}}}}
  You can use most of these same statements to configure statically created PPPoE interfaces, with the following important differences. When you configure a profile to dynamically create a PPPoE interface, you must specify the $junos-interface-unit predefined dynamic variable instead of the actual logical unit number for the unit statement, and the $junos-underlying-interface predefined dynamic variable instead of the actual name of the underlying interface for the underlying-interface statement.
2. Assign the dynamic profile to the underlying interface on which the router creates the dynamic PPPoE interface. To do so, include the pppoe-underlying-options statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level, as follows:
  interfaces {interface-name {unit logical-unit-number {encapsulation ppp-over-ethernet;pppoe-underlying-options {access-concentrator name;dynamic-profile profile-name;duplicate-protection;max-sessions number;}}}}
  The statements at the [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options] hierarchy level define the following PPPoE-specific attributes for the underlying interface:
  - To provide an alternative access concentrator (AC) name in the AC-NAME tag in a PPPoE control packet, include the access-concentrator statement.
  - To assign a previously configured dynamic profile to the underlying interface, include the dynamic-profile statement. This is the only required statement for configuring dynamic PPPoE interfaces at the [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options] hierarchy level.
  - To prevent the activation of another dynamic PPPoE logical interface on the same underlying interface on which a dynamic PPPoE logical interface is already active for the same client, include the duplicate-protection statement.
  - To configure the maximum number of dynamic PPPoE logical interfaces (sessions) that the router can activate on the underlying interface, include the max-sessions statement.
To display information about the dynamic PPPoE interface configuration, use the show pppoe underlying-interfaces, show pppoe statistics, and show pppoe interfaces operational commands. You can also use the clear pppoe statistics command to clear packet statistics on the underlying interface.
[Subscriber Access]
Support for PPPoE Layer 3 wholesale configuration in a subscriber access network—Enables you to configure PPPoE Layer 3 wholesaling within a subscriber access network. Wholesale access is the process by which an access network provider partitions the access network into separately manageable and accountable subscriber segments for resale to other network providers. An access network provider may elect to wholesale all or part of its network to one or more service providers (retailers).
In a Juniper Networks subscriber access network, you accomplish Layer 3 partitioning through the use of logical systems (LSs) and routing instances. Logical systems enable you to divide a physical router into separate, distinct, logical administrative domains. This method of division enables multiple providers to administer the router simultaneously and each have access to only the portions of the configuration that are relevant to their specific logical system. The JUNOS Software supports up to 15 named logical systems in addition to the default logical system (inet.0).
Routing instances are typically used in Layer 3 VPN scenarios. A routing instance does not have the same level of administrative separation as does a logical system. The routing instance defines a distinct routing table, set of routing policies, and set of interfaces, but it does not provide administrative isolation.
When configuring PPPoE Layer 3 wholesale for a subscriber access network, keep the following in mind:
- PPPoE Layer 3 wholesaling supports the use of only the default logical system using multiple routing instances.
- Each routing instance must contain a loopback with one or more addresses to be used for the unnumbered interface. However, unlike configuring Layer 3 wholesale for DHCP, the loopback interface address does not have to be within the same subnetwork as the client IP address.
- The system ignores the preferred-source-address option for the unnumbered-address statement when it is configured. To avoid confusion, we recommend that you do not configure the preferred-source-address option for the unnumbered-address statement when configuring an unnumbered interface. However, the system will function appropriately, regardless of whether or not you have configured the preferred-source-address option.
To configure PPPoE Layer 3 wholesale for a subscriber access network:
- Include the routing-instances statement along with the $junos-routing-instance dynamic variable at the [edit dynamic-profiles profile-name] hierarchy level.
- Include the interface statement along with the $junos-interface-name dynamic variable at the [edit dynamic-profiles profile-name routing-instances “$junos-routing-instance”] hierarchy level.
- Include the unnumbered-address statement along with $junos-loopback-interface dynamic variable at the [edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” family inet] hierarchy level.
To view the logical system and routing instance for each subscriber, use the show subscriber operational command.
[Subscriber Access, Broadband Subscriber Management]
PPP PAP and CHAP enhancements for subscriber management (M120 and M320 routers)—Subscriber management supports both bidirectional and unidirectional PPP PAP and CHAP authentication.
In subscriber management, the router's PPP interface typically authenticates the remote client (the subscriber). Bidirectional authentication is not usually used in a subscriber management environment, even though it is supported for static interfaces. Also, subscriber management uses AAA to authenticate subscribers, which removes the need to specify an access profile or a default password for PAP or CHAP authentication.
- For static interfaces, the router supports bidirectional authentication. If you do not include the passive statement in the configuration, the router functions as the authenticator for remote clients. If you include the passive statement, the router is authenticated by the remote client. Also, when you specify the passive statement for static interfaces, you must specify other attributes, as described in the JUNOS Network Interfaces Guide.
- For dynamic interfaces, the router supports unidirectional authentication only—the router always functions as the authenticator. When you configure PPP authentication in a dynamic profile (at the [edit dynamic-profiles] hierarchy level), the pap and chap statements do not support any additional configuration options, including the passive statement. PPP dynamic interfaces are supported only on PPPoE interfaces (interface pp0) for this release.
To configure CHAP or PAP authentication for static interfaces, use the following stanza:
[edit interfaces interface-name unit logical-unit-number]ppp-options {chap {access-profile name;default-chap-secret name;local-name name;passive;}pap {access-profile namedefault-pap-password password;local-name name;local-password password;passive;}}
To configure CHAP or PAP authentication for dynamic interfaces, use the following stanza:
[edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit]ppp-options {chap;pap;}
[Subscriber Access, Network Interfaces]
Support for input and output filters on the Trio MPC/MIC interfaces on MX Series routers—Enables you to apply input and output filters to logical interfaces that are running over the Trio MPC/MIC interfaces on MX Series routers.
To apply input and output filters for logical interfaces, include the input input-filter-name and output output-filter-name statements. To apply these filters statically, include the statements at the [edit interfaces interface-name unit logical-unit-number filter] hierarchy level. To apply these filters dynamically, include the statements at the [edit dynamic-profiles profile-name interfaces interface-name unit “$junos-interface-unit” filter] hierarchy level. For information about how to create filters, see the Policy Framework Configuration Guide.
[Subscriber Access, Network Interfaces, Policy Framework]
PPPoE interface support for subscriber secure policy traffic mirroring on Trio MPC/MIC interfaces on MX Series routers—Enables you to configure subscriber secure policy traffic mirroring to provide RADIUS-initiated mirroring for subscribers on PPPoE interfaces that are running over Trio MPC/MIC interfaces on MX Series routers.
For information about how to configure subscriber secure policy traffic mirroring, see the Subscriber Access Configuration Guide.
[Subscriber Access]
Support for PPP/PPPoE subscriber interfaces on the Trio MPC/MIC family of products (MX Series routers)—Enables you to configure PPP/PPPoE subscriber interfaces that are running over the Trio MPC/MIC family of products when used on MX Series routers. To configure PPP/PPPoE subscriber interfaces, you use the statements and procedures that are described in the JUNOS Network Interfaces Guide.
[Subscriber Access, Network Interfaces]
Support for demux VLAN interface configuration on Ethernet and aggregate Ethernet Trio MPC/MIC interfaces—Enables the static or dynamic creation of demux VLAN interfaces with an underlying interface of aggregate Ethernet or Gigabit/10–Gigabit Ethernet.
When configuring static VLAN demux interfaces, specify a VLAN ID for the vlan-id statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number] hierarchy level. You must also specify the underlying device name for the underlying-interface statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number demux-options] hierarchy level.
When configuring dynamic VLAN demux interfaces, specify the VLAN ID variable ($junos-vlan-id) for the vlan-id statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number] hierarchy level. You must also specify the underlying device name variable ($junos-interface-ifd-name) for the underlying-interface statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number demux-options] hierarchy level.
In addition, keep the following in mind while configuring dynamic VLANs over IP demux interfaces:
- Only single VLAN and stacked VLAN tag options are supported as VLAN selectors.
- IP demux over IP demux stacking is not supported.
- This support is limited to Trio MPC/MIC interfaces on MX Series routers.
[Subscriber Access]

System Logging

New and deprecated system log families and tags—The following system log families are new in this release:
- ALARMD—Describes messages with the ALARMD prefix. They are generated by the alarm process (alarmd).
- CONNECTION—Describes messages with the CONNECTION prefix. They are generated whenever the alarm process is unable to connect to another process.
- FCD—Describes messages with the FCD prefix. They are generated by the Fibre Channel process (fcd) which connects servers to disks and tape devices in a storage area network.
- GPRSD—Describes messages with the GPRSD prefix. They are generated by the general packet radio service process (gprsd) that integrates with existing GSM networks and offers mobile subscribers with packet-switched data services access to corporate networks and the Internet.
- LIBJSNMP—Describes messages with the LIBJSNMP prefix. They are generated by the libjsnmp process.
- UTMD—Describes messages with the UTMD prefix. They are generated by the unified threat management process (utmd), which protects the network from all types of attack.
- WEBFILTER—Describes messages with the WEBFILTER prefix. They are generated by the Web filtering process (webfilter), which allows you to manage Internet usage by preventing access to inappropriate Web content.
The following system log messages are new in this release:
- COSD_NULL_INPUT_ARGUMENT
- DCD_GRE_CONFIG_INVALID
- DCD_PARSE_ERROR_MAX_HIER_LEVELS
- DCD_PARSE_ERR_INCOMPATIBLE_CFG
- EVENTD_ALARM_CLEAR
- EVENTD_TEST_ALARM
- PFE_ANALYZER_CFG_FAILED
- PFE_ANALYZER_SHIM_CFG_FAILED
- PFE_ANALYZER_TABLE_WRITE_FAILED
- PFE_ANALYZER_TASK_FAILED
- PFE_COS_B2_ONE_CLASS
- PFE_COS_B2_UNSUPPORTED
- RPD_RA_CFG_CREATE_ENTRY_FAILED
- RPD_RA_CFG_INVALID_VALUE
- RPD_RA_DYN_CFG_ALREADY_BOUND
- RPD_RA_DYN_CFG_INVALID_STMT
- RPD_RA_DYN_CFG_SES_ID_ADD_FAIL
- RPD_RA_DYN_CFG_SES_ID_MISMATCH
- RPD_RT_CFG_BR_CONFLICT
The following system log messages are no longer documented:
- DFWD_CONFIG_FW_UNSUPPORTED
- LLDPD_PARSE_ARGS
- LLDPD_PARSE_BAD_SWITCH
- LLDPD_PARSE_CMD_ARG
- LLDPD_PARSE_CMD_EXTRA
- LLDPD_PARSE_USAGE
- LPDFD_DYN_SDB_OPEN_FAILED

User Interface and Configuration

Enhanced support for up to 64 ECMP next hops for load balancing on M10i routers with Enhanced CFEB, M320, M120, MX Series, and T Series Core routers—The JUNOS Software supports configurations of 16, 32, or 64 equal-cost multipath (ECMP) next hops for RSVP and LDP LSPs on M10i routers with an Enhanced CFEB, and M320, M120, MX Series, and T Series routers. For networks with high-volume traffic, this provides more flexibility to load-balance the traffic over as many as 64 LSPs.

To configure the maximum limit for ECMP next hops, include the maximum-ecmp next-hops statement at the [edit chassis] hierarchy level:

[edit chassis]maximum-ecmp next-hops;

You can configure a maximum ECMP next-hop limit of 16, 32, or 64 using this statement. The default limit is 16.

The following types of routes support the ECMP maximum next-hop configuration for as many as 64 ECMP gateways:

Static IPv4 and IPv6 routes with direct and indirect next-hop ECMPs
LDP ingress and transit routes learned through associated IGP routes
RSVP ECMP next hops created for LSPs
OSPF IPv4 and IPv6 route ECMPs
ISIS IPv4 and IPv6 route ECMPs
EBGP IPv4 and IPv6 route ECMPs
IBGP (resolving over IGP routes) IPv4 and IPv6 route ECMPs

The enhanced ECMP limit of up to 64 ECMP next hops is also applicable for Layer 3 VPNs, Layer 2 VPNs, Layer 2 circuits, and VPLS services that resolve over an MPLS route, because the available ECMP paths in the MPLS route can also be used by such traffic.

The following FPCs on M320, T640, and T1600 routers only support 16 ECMP next hops:

(M320, T640, and T1600 routers only) Enhanced II FPC1
(M320, T640, and T1600 routers only) Enhanced II FPC2
(M320 and T640 routers only) Enhanced II FPC3
(T640 and T1600 routers only) FPC2
(T640 and T1600 routers only) FPC3

Note: If a maximum ECMP next-hop limit of 32 or 64 is configured on an M320, T640, or T1600 router with any of these FPCs installed, the Packet Forwarding Engines on these FPCs use only the first 16 ECMP next hops. For Packet Forwarding Engines on FPCs that support only 16 ECMP next hops, the JUNOS Software generates a system log message if a maximum ECMP next-hop limit of 32 or 64 is configured. However, for Packet Forwarding Engines on other FPCs installed on the router, a maximum configured ECMP limit of 32 or 64 ECMP next hops is applicable.

To view the details of the ECMP next hops, issue the show route command. The show route summary command also shows the current configuration for the maximum ECMP limit. To view details of the ECMP LDP paths, issue the traceroute mpls ldp command.

[System Basics, Policy Framework, Routing Protocols Command Reference]

Support for configuring time-based user access—The JUNOS Software enables you to configure time-based restrictions for user access to log in to a device. This is useful for restricting the time and duration of user logins for all users belonging to a login class. You can specify the days of the week when users can log in, the access start time, and the access end time.
- To configure user access on specific days of the week, without any restrictions on the duration of login, include the allowed-days statement only.
  [edit system]login {class class-name {allowed-days days-of-the-week;}
- To configure user access on all the days of the week for a specific duration, include the access-start and access-end statements only.
  [edit system]login {class class-name {access-start HHMM;access-end HHMM;}}
- To configure user access on specific days of the week for a specified duration, include the allowed-days, access-start, and access-end statements.
[edit system]login {class class-name {allowed-days days-of-the-week;access-start HHMM;access-end HHMM;}}
[System Basics]
Dynamic IPv6 filters (MX Series routers)—Subscriber management now supports dynamic IPv6 filters. The dynamic filter feature supports both classic and fast update filters, and both IPv4 and IPv6.
You specify the filters in a dynamic profile, which associates the filter to an interface. When the dynamic profile is triggered, the profile applies the filter to an interface.
You use the filter statement at the [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number family (inet | inet6)] hierarchy level to associate a dynamic profile to an interface.
[Subscriber Access, Policy Framework]
Support for classifiers and rewrite rules in dynamic subscriber-based CoS (MX Series routers)—You can now associate classifiers and rewrite rules with a subscriber interface in a dynamic profile. You must statically configure the classifiers and rewrite rules at the static [edit class-of-service] hierarchy level.
To associate a classifier configuration with a subscriber interface in a dynamic profile, include the classifiers statement at the [edit dynamic profiles profile-name class-of-service interfaces interface-name unit logical-unit-number] hierarchy level. The supported classifier types for subscriber interfaces are dscp, dscp-ipv6, ieee-802.1, and inet-precedence.
To associate a rewrite-rule configuration with a subscriber interface in a dynamic profile, include the rewrite-rules statement at the [edit dynamic profiles profile-name class-of-service interfaces interface-name unit logical-unit-number] hierarchy level. The supported rewrite rules for subscriber interfaces are dscp, dscp-ipv6, ieee-802.1, and inet-precedence.
[Subscriber Access]

Dynamic configuration of the router advertisement protocol—In a network deployment where router interfaces are configured statically, you might need to configure the router advertisement protocol on only a small number of interfaces on which it might run. However, in a subscriber access network, static configuration of the router advertisement protocol becomes impractical because the number of interfaces that potentially need the router advertisement protocol increases substantially. In addition, deploying services in a dynamic environment requires dynamic modifications to interfaces as they are created. To ensure that dynamic interfaces are created with the ability to use the router advertisement protocol, this release supports their configuration dynamically at the [edit dynamic-profiles profile-name protocols] hierarchy level. The dynamic profile applies router advertisement protocol configuration to dynamic interfaces as they are created.

To minimally configure the router advertisement protocol, include the router-advertisement statement at the [edit dynamic-profiles profile-name protocols] hierarchy level, and the interface statement along with the $junos-interface-name dynamic variable. All other statements are optional.

Optional router advertisement protocol statements include current-hop-limit, default-lifetime, managed-configuration, max-advertisement-interval, min-advertisement-interval, no-managed-configuration, no-other-stateful-configuration, other-stateful-configuration, prefix, reachable-time, and retransmit-timer. All of these statements appear at the [edit dynamic-profiles profile-name protocols router-advertisement] hierarchy level.

Note: Statements used for router advertisement protocol configuration at the [edit dynamic-profiles profile-name protocols] hierarchy level are identical in function to the same statements used for static router advertisement protocol configuration, with the exception of the interface and prefix statements which use dynamic variables.