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

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

Class of Service

Support for Layer 2 policers at the VLAN level on Trio MPC/MIC interfaces (MX Series platforms with Trio MPC/MIC interfaces)—Layer 2 policers at the VLAN level are supported on an MX Series router with Trio MPCs/MICs.
[Class of Service]

High Availability

Nonstop active routing support for Layer 2 VPN and Layer 3 VPN over RSPV-TE LSPs—Starting with Release 10.2, the JUNOS Software extends the nonstop active routing support to Layer 2 VPN and Layer 3 VPN over RSVP-TE LSPs. JUNOS Release 10.2 also extends the nonstop active routing support for Layer 3 VPNs to cover the following OSPF features and configurations:
- domain-id domain-id statement at the [edit routing-instances routing-instance-name protocols (ospf | ospf3)] hierarchy level
- domain-vpn-tag number statement at the [edit routing-instances routing-instance-name protocols (ospf | ospf3)] hierarchy level
- metric number statement at the [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote] hierarchy level
- sham-link local address statement at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level
- sham-link-remote address <metric number> statement at the [edit routing-instances routing-instance-name protocols ospf area area-id] hierarchy level

Interfaces and Chassis

Support for external clock synchronization on T Series routers (T320, T640, T1600)—The T320, T640, and T1600 routers support external clock interfaces on the Sonic Clock Generators (SCG). When external clock synchronization is configured, this clock is distributed through the FPCs to each PIC interface.
To configure external clock synchronization, include the following statements at the [edit chassis] hierarchy level:
synchronization { primary (external-a | external-b);secondary (external-s | external-b);switching-mode (revertive | non-revertive);validation-interval seconds;}
[System Basics]
Support for 802.1ag Ethernet OAM for VPLS extended to M320 (with Enhanced III FPC), M120, and to M10i and M7i (with CFEB) routers with IQ2, IQ2E, and HGE PICs—Extends the 802.1ag VPLS functionality to the specified routers. 802.1ag was previously supported only on Layer 2 circuits, Layer 2 VPNs, and routable interfaces on the specified router, FPC, and interface combinations.
Configuration for this feature is performed in the same way as the existing OAM VPLS CLI feature configuration on MX Series routers. To configure CFM, include the connectivity-fault-management statement and substatements at the [edit protocols oam ethernet] hierarchy level
[Network Interfaces]
Quality-of-service (QoS) support for ATM on Circuit Emulation PICs—On M7i, M10i, M40e, M120, and M320 routers, the Channelized OC3/STM1 Circuit Emulation PICs (PB-4CHOC3-CE-SFP and PE-4CHOC3-CE-SFP) and E1/T1 Circuit Emulation PICs (PB-12T1E1-CE-TELCO and PE-12T1E1-CE-TELCO) provide QoS features that match or exceed those of the ATM-II PIC.
Circuit Emulation PICs provide ingress and egress direction traffic shaping. Policing is performed by monitoring the configured parameters on the incoming traffic and is also referred to as ingress shaping. Egress shaping uses queuing and scheduling to shape the outgoing traffic. This is an enhancement over the ATM-II PIC, which only provides egress shaping. Classification is provided per virtual circuit (VC).
The following features are supported:
- Port-level egress shaping
- Support for CBR, rtVBR, nrtVBR, and UBR
- Policing on a per VC basis
- Independent PCR and SCR policing
- Counting, tagging, or discard policing actions
CLI configuration is similar to that of QoS features for the ATM-II PIC. To configure shaping for logical interfaces in port promiscuous mode, use the shaping statement and its substatements at the [interfaces at-fpc/pic/port unit] hierarchy level.
[Network Interfaces]
New 2-port MIC with XFP (model number MIC-3D-2XGE-XFP)—Supported on MX Series routers. The MIC is available for the new Type 1 MPCs. For a list of supported MICs and MPCs, see the MX Series Line Card Guide.
New 30-Gigabit Ethernet Queuing MPC (model number MX-MPC1-3D-Q)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
New 30-Gigabit Ethernet MPC (model number MX-MPC1-3D)—Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
Restrictions on NAT configuration on the Oracle Services DPC (MX Series platforms with Oracle Services DPC interfaces)—If you configure a basic 1:1 destination NAT rule with address prefixes in the pool, NAT will not work as expected. Also, if you configure port allocation for all NAT translations with a redundancy services (RSP) interface, NAT will not work as expected.
[Services Interfaces]
Voice over IP (VoIP) services—In JUNOS Release 10.2, MX Series MPCs support Border Gateway Function (BGF) and Integrated Multi-Service Gateway (IMSG). For a list of supported protocols and applications, see the MX Series Line Card Guide.
New 40-port dual-wide Tri-rate MIC (model number MIC-3D-40GE-TX)—Supported on the MX Series routers. The Tri-rate MIC contains 40 autonegotiating 10Base-T, 100Base-TX, or 1000Base-T Megabit Ethernet ports. The Tri-rate MIC installs into both slots of an MPC. For a list of supported MICs and MPCs, see the MX Series Line Card Guide.
Support for Layer 2 Ethernet OAM (MX Series routers with Trio MPC/MIC Ethernet interfaces)—If you configure Ethernet interfaces, all Layer 2 OAM functions are supported through JUNOS Release 9.1.
[Network Interfaces]
Support for MPC tunnel features with other DPC types (MX Series platforms with Trio MPC/MIC interfaces)—If you configure tunnels on an MX Series router with both Trio MPCs/MICs and DPCs, all tunnel functions are supported through JUNOS Release 9.2.
[Network Interfaces]
Modular Port Concentrators (MPCs) on MX Series routers—Provide tunnel support parity, replacing traditional tunnel and services PICs with tunnels that were supported on a "virtual" port on the MX Series PFE. MX Series routers support a virtual PIC and a virtual port, visible for tunnel configuration, and eliminating the need for a tunnel PIC. Traditional tunnel PIC features are supported, including:
- GRE keys
- GRE Clear-dont-fragment
Certain services PIC features are not supported. On MPCs there are no tunnel PICs. Instead some bandwidth is taken off the WAN ports from the MX router and reserved for tunneling. In the presence of tunnel traffic, all WAN ports are affected in case of oversubscription.
On MX Series routers, two types of tunnel ports are supported, as follows:
- A 1–Gbps tunnel port of 10x1GE PFE complex
- A 10–Gbps tunnel port on 1x10GE PFE complex
On MX Series routers, tunnel services can be enabled by configuring tunnel-services bandwidth on a particular PIC. For example:
user@host# show chassis
```
  fpc 0 {
    pic 0 {
        tunnel-services {
            bandwidth 1g;
        }
    }

    pic 1 {
        tunnel-services {
            bandwidth 1g;
        }
    }

  }
```
This enables tunnel services with a bandwidth of 1–Gbps on FPC 0 and PIC 0. Correspondingly, chassisd would create devices such as the following:
- vt-0/0/10, ip-0/0/10, etc. for pic0
- vt-0/1/10 ip-0/1/10 etc. for pic1
Currently supported bandwidth values are 1 Gbps and 10 Gbps. Devices are created with port 10 for 1-Gbps tunnels and port 0 for 10-Gbps tunnels.
These tunnels with their associated configurations work when an MX-DPC is replaced by an MPC. This means the router will create tunnel devices based on the tunnel services configuration. This means that although the same PFE supports vt-0/0/10 and vt-0/1/10, two devices must be created to be compatible with the above configuration. The MPC allows you to configure 4 tunnels MICs per MPC (to support vt-0/0/10, vt-0/1/10, vt-0/2/10, vt-0/3/10), although in reality there are only two physical MICs. This is achieved by creating logical MICs on MPCs.
In addition, you can add physical interfaces to the MPC because there are no MICs associated with these tunnel physical interfaces.
[Services Interfaces]
New MX80 Ethernet services router—The new MX80 Ethernet Services router is a compact Ethernet-optimized edge router that provides both switching and carrier-class Ethernet routing. The MX80 router has a capacity of up to 40 gigabits per second (Gbps) full duplex, high-density Ethernet interfaces, and high-capacity switching throughput. The MX80 router is available either as a fixed chassis or a modular chassis.
The modular MX80 router includes the following hardware features:
- 2 U high
- Two slots that support the following Modular Interface Cards (MICs): 20-port Gigabit Ethernet MIC with SFP, 2-port 10-Gigabit Ethernet MIC with XFP, and 40-port Gigabit Ethernet MIC (dual-wide)
- Four built-in 10-Gigabit Ethernet ports
- JUNOS Trio chipset for increased scalability of L2/L3 packet forwarding, buffering, and queuing
The MX80 router supports parity in software features supported by other MX Series routers as of JUNOS Release 9.2. The show chassis family of commands has been updated to provide information about MX80 routers.
[MX80 Hardware]
New MX80 Ethernet services router—There are two MX80 routers: one with a modular chassis and one with a fixed chassis. Each router is a compact Ethernet-optimized edge router that provides provide switching and carrier class Ethernet routing. Both provide up to 40 gigabits per second (Gbps) full duplex, high-density Ethernet interfaces and high capacity switching throughput. Both use the Trio chipset for increased scalability of L2/L3 packet forwarding, buffering, and queuing. Each router supports parity in software features supported by other MX Series routers as of JUNOS Release 9.2.
Note: The fixed MX80 router does not support hierarchical queuing, congestion dropping, or statistics.
The modular MX80 router includes four built-in 10-Gigabit Ethernet ports and two slots that support the following Modular Interface Cards (MICs):
- 20-port Gigabit Ethernet MIC with SFP
- 2-port 10-Gigabit Ethernet MIC with XFP
- 40-port Gigabit Ethernet MIC (dual-wide)
The fixed MX48 router includes four built-in 10-Gigabit Ethernet ports and 48 built-in 10/100/1000Base-TX-RJ45 ports.
The MX80 router is a single-board router with a built-in Routing Engine and one Packet Forwarding Engine (PFE), which can have up to two Modular Interface Cards (MICs). (A Services PIC slot is currently not supported.) The PFE has two “pseudo” Flexible PIC Concentrators (FPC 0 and FPC1). Because there is no switching fabric, the single PFE takes care of both ingress and egress packet forwarding.
On both routers, the four built-in 10-Gigabit Ethernet ports are mapped to FPC 0. On the modular MX80 router, the MIC slots are mapped to FPC 1. On the fixed MX80 router, the 48 built-in 10/100/1000Base-TX-RJ45 ports are mapped to FPC 1.
[MX80 Hardware]
Tunable XFP support (MX960, MX480, MX240, T640, T1600, and TX Matrix routers)—Provides support for wavelength tunable non-OTN (optical transport network) 10–Gigabit Ethernet XFPs. All forwarding, OAM, and control plane features supported on the current DPCs, MICs, and PICs are supported on the above routers. This feature is not supported on MX80 and T320 routers.
You can use the existing wavelength statement to configure the wavelength of the optics at the [edit interfaces interface-name optic-options] hierarchy level.
The following existing configuration mode commands are supported for tunable XFPs:
- show chassis hardware
- show chassis pic
- show interfaces
[Network Interfaces]
Enhanced graceful Routing Engine switchover (GRES) support for PD-5-10XGE-SFPP PICs (TX Matrix)—JUNOS Release 10.2 extends GRES support for PD-5-10XGE-SFPP, 10-port 10-GBE Oversubscribed Ethernet PICs to TX Matrix routers.
Targeted broadcast support for virtual routing and forwarding (VRF) (M Series, MX Series, and T Series routers)—Enables IP packets destined for a Layer 3 broadcast address to transit to an egress interface on a router. The packets are broadcast only if the egress interface is a LAN interface. This feature is useful when the Routing Engine is flooded with packets to process.
Targeted broadcast enables a broadcast packet destined for a remote network to transit across networks until the destination network is reached. In the destination network, the broadcast packet is broadcast as a normal broadcast packet.
To configure targeted broadcast on a broadcast interface, include the targeted-broadcast statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level.
You can configure targeted broadcast in two ways:
- To forward broadcast packets to both the egress interface and the Routing Engine, include the forward-and-send-to-re statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.
- To forward broadcast packets to the egress interface only, include the forward-only statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.
When you do not include the targeted-broadcast statement, a copy of each broadcast packet is sent to the Routing Engine. When you include the targeted-broadcast statement without either the forward-and-send-to-re or forward-only statement, broadcast packets are discarded.
[Network Interfaces]
Extend support for 64-bit JUNOS Software to include RE-1800 Series Routing Engines (M120, M320, MX960, MX480, and MX240 routers)—Supported Routing Engines include:
- RE-1800x2-A—Supports 64-bit JUNOS Software on M120 and M320 routers.
- RE-1800x2-S—Supports 64-bit JUNOS Software on MX240, MX480, and MX960 routers.
- RE-1800x4-S—Supports 64-bit JUNOS Software on MX240, MX480, and MX960 routers.
[System Basics]
Enhanced IQ (IQE) PICs for M7i and M10i routers—M7i and M10i routers now support the following Enhanced IQ (IQE) PICs:
- 4-port Channelized DS3 and E3 Enhanced IQ (IQE)PIC (PE-4CHDS3-E3-IQE-BNC)
- 10-port Channelized E1/T1 Enhanced IQ (IQE) PIC (PE-10CHE-T1-IQE-RJ48)
- 2-port Channelized OC3/STM1 Enhanced IQ (IQE) PIC with SFP (PE-2CHOC3-STM1-IQE-SFP)
- 1-port Channelized OC12/STM4 Enhanced IQ (IQE) PIC with SFP (PE-1CHOC12STM4-IQE-SFP)
- 4-port DS3/E3 Enhanced IQ (IQE)PIC (PE-4DS3-E3-IQE-BNC)
- 4-port SONET/SDH OC3/STM1 Enhanced IQ (IQE) PIC with SFP (PE-4OC3-STM1-IQE-SFP)
- 1-port SONET/SDH OC12/STM4 Enhanced IQ (IQE) PIC with SFP (PE-1OC12-STM4-IQE-SFP)
The IQE PICs support the same features as the existing IQ PICs, as well as enhanced CoS and diagnostic features. The valid configuration statements are also the same, but the limits and range of values for some options are different to support augmented capabilities.
[M7i PIC Guide, M10i PIC Guide, Class of Service, Network Interfaces]
High availability hot-standby for FRF.15 (MLFR) and FRF.16 (MFR) configurations on Multiservices PICs and DPCs (M Series, MX Series, and T Series routers)—Extends support for the hot-standby option to FRF.15 and FRF.16 on redundant paired LSQ interfaces. This feature is supported on Multiservices PICs and DPCs.
Provides a switchover time of 5 seconds or less for FRF.15, and provides a maximum of 10 seconds switchover time for FRF.16.
To configure redundant LSQ hot-standby functionality for FRF.15, configure the hot-standby statement at the [edit interfaces rlsqnumber redundancy-options] hierarchy level and the multilink-frame-relay-end-to-end statement at the [edit interfaces rlsqnumber unit logical-unit-number encapsulation] hierarchy level.
To configure redundant LSQ hot-standby functionality for FRF.16, include the hot-standby statement at the [edit interfaces rlsqnumber:number encapsulation multilink-frame-relay-uni-nni redundancy-options] hierarchy level.
[Services Interfaces]
Support for xSTP on Trio MPC/MIC interfaces (MX Series platforms with Trio MPC/MIC interfaces)—All types of xSTPs are supported on an MX Series router with Trio MPCs/MICs.
[Layer 2 Configuration Guide]
New statement to sync the FPC that is brought online with other active FPCs (M320, T320, T640, T1600, TX Matrix, and TX Matrix Plus routers)—M320, T320, T640, T1600, TX Matrix, and TX Matrix Plus routers now support the fpc-resync configuration statement at the [edit chassis] hierarchy level. When you bring a Flexible PIC Concentrator (FPC) online, the sequence number on the FPC may not be synchronized with the other active FPCs in the router, which may result in the loss of a small amount of initial traffic. To avoid any traffic loss, include the fpc-resync statement at the [edit chassis] hierarchy level. This ensures that the sequence numbers of the FPC that is brought online is resynchronized with the other active FPCs in the router.
[System Basics]

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.2, 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.2

Request Tag Element	CLI Command	Response Tag Element
<clear-service-bsg-registrations> clear_service_bsg_registrations	clear services border-signaling-gateway registrations	<clear-service-bsg-registrations>
<clear-service-bsg-registrations-statistics> clear_service_bsg_registrations_statistics	clear services border-signaling-gateway registrations statistics	<clear-service-bsg-registrations>
<clear-services-bsg-registrations-subscription> clear_services_bsg_registrations_subscription	clear services border-signaling-gateway registrations subscription	<clear-services-bsg-registrations-subscription>
<get-syslog-facility-information> get_syslog_facility_information	help syslog facility	<syslog-tag-information>
<request-ping-rsvp-dynamic-bypass-lsp> request_ping_rsvp_dynamic_bypass_lsp	ping mpls rsvp dynamic-bypass	NONE
<request-ping-rsvp-manual-bypass-lsp> request_ping_rsvp_manual_bypass_lsp	ping mpls rsvp manual-bypass	NONE
<request-logout-user> request_logout_user	request system logout	<logout-user>
<get-environment- power-supply-unit- information> get_environment_ power_supply_unit_information	show chassis environment power-supply-unit	<environment-component-information>
<get-fm-topology> get_fm_topology	show chassis fabric map	<fm-topology>
<get-fm-plane-location-information> get_fm_plane_location_information	show chassis fabric plane-location	<fm-plane-location-information>
<get-fru-power-on-sequence> get_fru_power_on_sequence	show chassis power sequence	<fru-power-on-sequence>
<get-power-budget-information> get_power_budget_information	show chassis power-budget-statistics	<power-budget-information>
<get-tfeb-information> get_tfeb_information	show chassis tfeb	<scb-information>
<get-vcpu-information> get_vcpu_information	show chassis vcpu	<vcpu-information>
<get-cos-service-session-information> get_cos_service_session_information	show class-of-service service-session	<cos-service-session-information>
<get-gre-ka-information> get_gre_ka_information	show oam gre-keepalive	<oamd-information>
<get-pppoe-session-information> get_pppoe_session_information	show pppoe sessions	<pppoe-session-information>
<get-r2cp-interface-information> get_r2cp_interface_information	show r2cp interfaces	<r2cp-interface-information>
<get-r2cp-radio-information> get_r2cp_radio_information	show r2cp radio	<r2cp-radio-information>
<get-r2cp-session-information> get_r2cp_session_information	show r2cp sessions	<r2cp-session-information>
<get-r2cp-statistics> get_r2cp_statistics	show r2cp statistics	<r2cp-statistics>
<get-service- accounting-error- inline-jflow- information> get_service_ accounting_error_ inline_jflow_ information	show services accounting errors inline-jflow	<service-accouting-inline-jflow-error-infomation>
<get-service- accounting-status-inline- jflow-flow-information> get_service_ accounting_status_ inline_jflow_ flow_information	show services accounting flow inline-jflow	<service-accouting-inline-jflow-flow-infomation>
<get-service- accounting-status-inline- jflow-information> get_service_ accounting_status_ inline_jflow_ information	show services accounting status inline-jflow	<service-accouting-inline-jflow-information>
<get-service- border-signaling- gateway-address- of-record> get_service_ border_signaling_ gateway_address_ of_record	show services border-signaling-gateway address-of-record	<bsg-address-of-records>
<get-service-border- signaling-gateway- address-of- record-bindings> get_service_ border_signaling_ gateway_address_ of_record_ bindings	show services border-signaling-gateway address-of-record bindings	<bsg-address-of-record-bindings>
<get-service- border-signaling-gateway- statistics-calls-by-server> get_service_border_ signaling_gateway_ statistics_calls_ by_server	show services border-signaling-gateway calls by-server	NONE
<get-service- border-signaling- gateway-statistics- calls-by-sp> get_service_ border_signaling_ gateway_statistics_ calls_by_sp	show services border-signaling-gateway calls by-service-point	NONE
<get-service- border-signaling-gateway- statistics-calls-duration -by-server> get_service_border_ signaling_gateway_ statistics_calls_ duration_by_server	show services border-signaling-gateway calls-duration by-server	NONE
<get-service- border-signaling-gateway- statistics-calls-duration-by- sp> get_service_border_signaling _gateway_statistics_calls_ duration_by_sp	show services border-signaling-gateway calls-duration by-service-point	NONE
<get-service- border-signaling-gateway- statistics-failed- calls-by-server> get_service_ border_signaling_gateway_ statistics_failed_calls_by_ server	show services border-signaling-gateway calls-failed by-server	NONE
<get-service-border-signaling-gateway -statistics-failed- calls-by-sp> get_service_ border_signaling_gateway _statistics_failed_calls_ by_sp	show services border-signaling-gateway calls-failed by-service-point	NONE
<get-service- bsg-registrations> get_service_ bsg_registrations	show services border-signaling-gateway registrations	<bsg-registrations>
<get-service- bsg-registrations- realm-statistics> get_service_bsg_ registrations_ realm_statistics	show services border-signaling-gateway registrations realm	<bsg-registrations-realm>
<get-service- bsg-registrations- statistics> get_service_ bsg_registrations_ statistics	show services border-signaling-gateway registrations statistics	<bsg-registrations>
<get-service-border- signaling-gateway- routing-blacklist> get_service_ border_signaling_ gateway_routing_ blacklist	show services border-signaling-gateway routing-blacklist	<bsg-routing-blacklist>
<get-service- softwire-table- information> get_service_ softwire_table_ information	show services softwire	<service-softwire-table-information>
<get-service- fwnat-flow- table-information> get_service_ fwnat_flow_table_ information	show services softwire flows	<service-fwnat-flow-table-information>
<get-subscribers- summary> get_subscribers_ summary	show subscribers summary	<subscriber>
<get-system- storage-partitions> get_system_ storage_partitions	show system storage partitions	<system-storage-information>
<get-system- virtual-memory- information> get_system_ virtual_memory_information	show system virtual-memory	<system-virtual-memory-information>

[JUNOS XML API Operational Reference]

Layer 2 Ethernet Services

Ethernet Ring Protocol (ERP) support for multiple ring instances on the same physical ring (MX Series routers)—This Layer 2 feature extends Ethernet Ring Protocol (ERP) support to include multiple ring instances on the same physical ring on MX960, MX480, and MX240 routers. Each ring instance will control a set of virtual LAN (VLAN) IDs. For a physical ring, traffic between two nodes usually follows the same path. By creating multiple ring instances, some traffic passes through one path, while other traffic can pass through a different path. The result is improved load-balancing of traffic in the physical ring.
To configure multiple ring instances, include the data-channel configuration statement with VLAN ID options at the [edit protocols protection-group ethernet-ring group-name] hierarchy level.
New operational mode commands support this feature. To display data channel information for all Ethernet ring protection groups, use the show protection-group ethernet-ring data-channel command. To display data channel information for a specific Ethernet ring protection group, use the show protection-group ethernet-ring data-channel groupname command. To display data channel VLAN information for all Ethernet ring protection groups, use the show protection-group ethernet-ring vlan command. To display data channel VLAN information for a specific Ethernet ring protection group, use the show protection-group ethernet-ring vlan groupname command.
[Layer 2 Configuration, Interfaces Command Reference]

MPLS Applications

Switching LSPs away from a network node—You can configure the router to switch active LSPs away from a network node using a bypass LSP enabled for an interface. This feature can be used in maintenance of active networks when a network device needs to be replaced without interrupting traffic passing through the network. The LSPs can be either static or dynamic. You need to first configure either link or node protection for the traffic that needs to pass around the network device you intend to disable. To function properly, the bypass LSP must use a different logical interface than the protected LSP.
To configure the router to switch traffic around a network node, configure the always-mark-connection-protection-tlv statement at the [edit protocols mpls interface interface-name] hierarchy level. This statement marks all OAM traffic transiting this interface in preparation for switching the traffic to an alternate path based on the OAM functionality. Next, configure the switch-away-lsps statement at the [edit protocols mpls interface interface-name] hierarchy level. This statement switches the traffic from the protected LSP to the bypass LSP, effectively bypassing the default downstream network device. The actual link is not brought down by this procedure itself. This feature is supported on MX Series routers only.
[MPLS]
Hello acknowledgements for non-session RSVP neighbors—You can now acknowledge hello messages sent from non-session RSVP neighbors with a hello acknowledgement message by including the hello-acknowledgements statement at the [edit protocols rsvp hello-acknowledgements] hierarchy level. When hellos are received from non-session neighbors, an RSVP neighbor relationship is created and periodic hello messages can now be received from the non-session neighbor. Interface-based neighbors are not automatically aged out.
[MPLS]

Multicast

Load-balancing multicast tunnel interfaces among available PICs—For draft-rosen Layer 3 VPNs, enables you to manually load-balance multicast tunnel interfaces across a configured list of tunnel-capable PICs. To configure the list, include the tunnel-devices statement at the [edit routing-instances instance-name protocols pim] hierarchy level. In some cases, you might need to manually force a rebalanced state. To do this, run the request pim multicast-tunnel rebalance command with or without the instance option.
[Multicast]
Internet Group Management Protocol (IGMP) snooping support for multichassis link aggregation group (MC-LAG) interfaces—Multichassis link aggregation group (MC-LAG) enables a device to form a logical LAG interface with two or more network devices. You can use multicast snooping over MC-LAG interfaces to replicate join and leave messages between MC-LAG peer devices to facilitate faster recovery of membership information after a service interruption.
Add the multichassis-lag-replicate-state statement at the [edit multicast-snooping-options] hierarchy level to enable snooping for MC-LAG interfaces. This feature supports dual-link MC-LAG interfaces in an active-standby mode, in which only one link is in active mode and the other is in standby mode at any given time.
In MC-LAG, if a standby link takes over as the active link, it can recover the membership information of the interface from the network by generating an IGMP query. However, this recovery can take between 1 and 10 seconds, which is too long for some applications. To keep service restoration time to a minimum, the active link can use IGMP snooping to replicate membership information to the standby link.
In the active-standby mode, join and leave messages are sent only through the active member link. Once the messages are received by the active link, they are flooded to all router interfaces, and forwarding entries are built for the received messages. Additionally, the messages are replicated from the active link to the standby link, using an Interchassis Communication Protocol (ICCP) connection. The standby link applies routine processing to the replicated packet, except that it does not add itself as the next hop for any route, and it does not send the replicated packet to the network.
After a failover, the multicast membership status of the link can be recovered within a few seconds or less by retrieving the replicated messages. This recovery is much faster than the 10–second outage that can occur if the recovery procedure relies only on IGMP queries.
When this feature is enabled, multicast snooping automatically identifies the active link during initialization and failover, and runs without any administrator intervention.
If the user deletes the configuration of IGMP snooping or deletes the multichassis-lag-replicate-state statement, this feature is disabled on that MC-LAG link or on the whole IGMP snooping domain. The active device stops replicating IGMP messages to the peer, and the IGMP data already installed on the standby device times out.
Use the show igmp snooping interface and show igmp snooping membership commands to display group information on both the active side and the standby side of an MC-LAG interface.
If the ICCP connection is lost, both links of the MC-LAG transition to the active state, and the client device starts load-balancing traffic between the two links. In this situation, the IGMP messages are not replicated.
[Multicast, Network Interfaces]

Multiplay

Integrated Multi-Service Gateway (IMSG) access mode support (VoIP subscriber management)—The border signaling gateway (BSG) now provides access mode support, which includes:
- Recording of subscriber registrations
- Tracking of subscriber address of record (AOR)
Access mode support enables the deployment of the BSG in a service provider’s border with large business enterprises, small offices, and home networks. The BSG enables endpoints and IPBXs to register for SIP service with the carrier/service provider’s registrar. Access mode support also enables new transaction policies to filter incoming messages based on their registration state.
You can now configure additional filtering of incoming messages by entering the uri-hiding and registration-state statements for contacts and request URIs at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name from] hierarchy level.
Signaling realms are assigned to the messages handled by service points. The default signaling realm for a subscriber’s messages is the ingress service point of their register message, so it is not usually necessary to explicitly define signaling realms. However, you may want to assign signaling realms to accumulate information about messages flowing through different service points used by the same customer. When a customer receives services through multiple service points, information on the overall service provided can be accumulated by assigning the same signaling realm to new transaction policies at each service point.
You configure signaling realms that can be used in new transaction policies by entering the signaling-realms statement at the [edit services border-signaling-gateway gateway-name sip] hierarchy level. You configure how messages are associated with a signaling realm by entering the signaling-realms statement at the [edit services border-signaling-gateway gateway-name sip new-transaction-policy term term-name] hierarchy level.
You can display information about subscriber registrations, address of record, and signaling realm assignments by using one of the following commands:
- show services border-signaling-gateway address-of-record bindings
- show services border-signaling-gateway registrations
You can clear registration statistics by using the following commands:
- clear services border-signaling-gateway registrations statistics
- show services border-signaling-gateway registrations subscription
[Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]
Integrated Multi-Service Gateway (IMSG) redirection of messages to contact address—When the border signaling gateway (BSG) receives a 3XX response, it now sends a redirected request using a request URI based on the contact information in the 3XX response. You can specify the maximum number of recursive redirection attempts allowed before sending a 408 timeout response by entering the recursion-limit statement at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then on-3xx-response] hierarchy level. Requests are not redirected for 380 responses.
[Multiplay Solutions, Services Interfaces]
Integrated Multi-Service Gateway (IMSG) support for up to four border signaling gateways (BSGs) on a router—You can now configure up to four border signaling gateways on a router. Each BSG must be defined on a separate MS-PIC.
[Session Border Control Solutions]
Integrated Multi-Service Gateway (IMSG) border signaling gateway (BSG) server clusters—Server clusters allow routing incoming transactions to one of several possible next-hops, thus providing load balancing and server redundancy. Server clusters are defined in the CLI and can be used as route policy actions.
You define server clusters by entering the server-cluster statement at the [edit services border-signaling-gateway gateway gateway-name sip routing-destinations] hierarchy level. Each cluster consists of configured servers. In order to configure server clusters, you must first configure individual servers and server availability checking by entering statements at the [edit services border-signaling-gateway gateway gateway-name sip routing-destinations] hierarchy level. After configuring routing-destinations, you can configure routing of transactions to a particular server cluster by entering the server-cluster statement at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then route] hierarchy level.
You can display call activity by server by entering the show services border-signaling-gateway calls command with the by-server option. If you do not use the by server option, you must use the by-service-point option. You can no longer use the show services border-signaling-gateway calls command without specifying one of these two options.
You can display unavailable servers by entering the show services border-signaling-gateway routing-blacklist command.
[Session Border Control Solutions, Services Interfaces, Systems Basics and Services Command Reference]
Integrated Multi-Service Gateway (IMSG) support on M7i and M10i routers—M7i and M10i routers now support the IMSG running on an MS-100 PIC.
[Session Border Control Solutions]
Border Gateway Function (BGF) virtual BGF scability—You can now configure up to 32 virtual BGFs on a router. Previously, you could configure a maximum of eight virtual BGFs on a router. Those eight virtual BGFs had to reside on a single MS-PIC. As of JUNOS Release 10.2, eight virtual BGFs can be configured on each of four MS-PICs.
[Session Border Control Solutions]

Routing Policy and Firewall Filters

Support for MPC firewall filter features (MX Series platforms with Trio MPC/MIC interfaces)—If you configure and apply firewalls to an MX Series router with Trio MPCs/MICs, some match conditions are not supported. Generally, all firewall functions are supported through JUNOS Release 9.2.
[Layer 2 Configuration]
Removal of input-list and output-list statements for firewall filters for the ccc and mpls protocol families applied to loopback, internal Ethernet, and USB modem interfaces—The input-list filter-names and output list filter-names statements for firewall filters for the ccc and mpls protocol families have been removed for these interfaces: management and internal Ethernet interfaces (fxp), loopback interfaces (lo), and USB modem interfaces (umd). Configuration of input lists and output lists for firewall filters for the ccc and mlps protocol families applied to other interfaces are not affected.
[Policy Framework]
Support for the discard action for the tricolor marking policer applied to a firewall filter—The discard action was not previously supported for the tricolor marking policer applied to a firewall filter. With this support for the discard action, the tricolor marking policer no longer needs to include the logical-interface-policer statement at the [edit firewall three-color-policer name] hierarchy level. This change applies only to the following routers: M120, M320 with Enhanced-III FPCSs, MX Series, and M7i and M10i with Enhanced CFEB (CFEB-E).
[Policy Framework]
Support for the match condition prefix-list for firewall filters for the protocol family VPLS—This match condition is already supported for IPv4 and IPv6 protocol families. To enable the prefix-list firewall filters match condition for VPLS, include the prefix-list prefix-list-name match condition at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level.
[Policy Framework]

Option to enable enhanced jtree memory allocation for Layer 3 VPNs (T640 and T1600 routers with Enhanced Scaling FPC3 and Enhanced Scaling FPC4)—To utilize memory across segments, JUNOS Release 10.2 extends support for allocating jtree memory for Layer 3 VPNs in different segments. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all affected FPCs to activate the configuration. To verify the configuration, use the show pfe fpc slot detail command.

Note: For T Series routers only. With JUNOS Release 10.2, enhanced jtree memory allocation is turned OFF by default. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all affected FPCs to activate the configuration. For JUNOS Release 9.3 to 10.1, the default routing tables (inet.0 and inet6.0) use both memory segments by default.

[System Basics]

Layer 2 Gigabit Ethernet logical interface policing support extended to MX Series routers—Enables you to configure the following policer types on the input and output interfaces:
- Single-rate two color
- Two-rate color-blind three color
- Two-rate color-aware three color
- Single-rate color-blind three color
- Single-rate color-aware three color
To configure, create the policer at the [edit firewall] hierarchy level. In addition to the policer condition and action, you must include the logical-interface-policer statement. To apply the policer to the input or output interface, include the layer2-policer statement at the [edit interface ge-fpc/pic/port unit logical-unit-number] hierarchy level.
[Network Interfaces, Class of Service, Policy]

Routing Protocols

Only the system log notes failure to add routes to the Trio MPC/MIC (MX Series platforms)—For Layer 3 and MPLS features, the Trio MPC/MIC is compatible with JUNOS Release 9.2. However, the syslog process is the only mechanism that records failure to add routes to the MPC.
[Routing Protocols]

Keepalive support for GRE interfaces (ichip based M Series and MX Series)—Enables GRE tunnel interfaces to detect when a tunnel interface is down. This feature is needed in static routing environments in which the keepalive mechanism in a dynamic routing protocol cannot be relied upon to detect a link down condition. To configure keepalives on GRE tunnel interface, include both the keepalive-time statement and the hold-time statement at the [edit protocols oam gre-tunnel interface interface-name] hierarchy level.

Note: For proper operation of keepalives on a GRE interface, you must also include the family inet statement at the [edit interfaces interface-name unit unit] hierarchy level. If you do not include this statement, the interface is marked as down.

[Services Interfaces, Interfaces Command Reference]

Support for OSPF database protection for OSPF and OSPFv3—Enables you to limit the number of link-state advertisements (LSAs) not generated by the router in a given OSPF instance. This feature is particularly useful for networks configured with VPN routing and forwarding on provider edge and customer edge routers using the OSPF routing protocol. By limiting LSAs not generated by the router, the link-state database in your network is protected from being overrun by excessive LSAs from sources other than your router. To enable database protection, include the database-protection statement at the [edit protocols (ospf | ospf3)] hierarchy level. This feature also supports routing instances, logical systems, and OSPFv3 realms. Besides configuring the maximum number of LSAs not from the router, you can specify parameters to determine how your network will respond when certain conditions are met. These include a warning threshold for issuing warning messages, an ignore count to limit the number of times the database can enter the ignore state before it goes into the isolate state, and a reset time for resuming normal operations if the database has avoided being in the ignore or isolate state for the specified period of time. However, once the link-state database enters the isolate state, a command to reset the database must be issued before normal operations can be resumed. In support of this feature, the clear ospf database-protection command has been added, and the output for the show ospf overview command has been enhanced to show the current database protection status.
[Routing Protocols]
Revert time for redundant Layer 2 pseudowires—You can now modify the behavior for redundant Layer 2 circuit and VPLS pseudowires by configuring a revert time. When a primary pseudowire fails and traffic is switched to an alternate pseudowire, the revert time specifies how long the router should wait before attempting to switch the traffic back to the primary pseudowire. The router does not attempt to switch traffic back to the primary pseudowire if the primary pseudowires has not been restored. To configure a revert time for redundant Layer 2 pseudowires, specify a time, in seconds, using the revert-time statement at the [edit protocols l2circuit neighbor address interface interface-name] hierarchy level for Layer 2 circuit configurations, and at the [edit routing-instances routing-instance-name protocols vpls neighbor address] hierarchy level for VPLS configurations.
[VPNs]
Support for having the algorithm that determines that the single best path skip the step that evaluates an AS path—By default, the third step of the algorithm that determines the active route evaluates the length of an AS path. To enable the JUNOS Software to skip this step, include the as-path-ignore statement at the [edit protocols bgp path-selection] hierarchy level. You cannot configure this statement for a specific routing instance.
[Routing Protocols]

Services Applications

Inline flow monitoring support (MX Series only)—Adds the capability to support flow monitoring and sampling services inline in the data path, without the need for a services PIC, on MX Series Modular Port Concentrators (MPCs).
To configure inline flow monitoring, include the inline-jflow statement at the [edit forwarding-options sampling instance instance-name family inet output] hierarchy level. Inline sampling exclusively supports a new format called version-ipfix that uses UDP as the transport protocol. When you configure inline sampling, you must include the version-ipfix statement at the [edit forwarding-options sampling instance instance-name family inet output flow-server address] hierarchy level and also at the [edit services flow-monitoring] hierarchy level. The following operational commands include new inline fpc keywords to display inline configuration information: show services accounting errors, show services accounting flow, and show services accounting status.
[Services Interfaces, System Basics and Services Command Reference]
Transition of IPv4 traffic to IPv6 addresses using DS-Lite—Adds support for DS-Lite, a means for transitioning IPv4 traffic to IPv6 addresses. This transition will become necessary as the supply of unique IPv4 addresses nears exhaustion. New subscriber homes are allocated IPv6 addresses and IPv6-capable equipment; DS-Lite provides a method for the private IPv4 addresses behind the IPv6 equipment to reach the IPv4 network. An IPv4 host communicates with a NAT endpoint over an IPv6 network using softwires. DS-Lite creates the IPv6 softwires that terminate on the services PIC. Packets coming out of the softwire can then have other services such as NAT applied on them.
To implement DS-Lite, include the softwire-concentrator-ip and softwire-type statements at the [edit services softwire-concentrator rule rule-name] hierarchy level. You can include softwire-concentrator-rules statements in service-set specifications as you would other types of service rules. The following new operational commands enable you to display DS-Lite configuration information: show services softwire, show services softwire flows, and show services softwire count. The existing show services stateful-firewall flows command also displays softwire information.
[Services Interfaces, System Basics and Services Command Reference]
AACL statistics for dynamic packet-triggered subscribers—Provide support for packet-triggered subscribers and policy control (PTSP) statistics collection in a flat file using the local policy decision function (L-PDF). If you specify in the rule that statistics collection and reporting are based on application or application group for each subscriber, then this flat file method is used.
To specify that PTSP statistics are reported, include the flag pstp-statistics statement at the [edit system services local-policy-decision-function traceoptions] hierarchy level. To configure the AACL statistics profile to support PTSP statistics collection, include the record-mode interim-active-only statement at the [edit system services local-policy-decision-function aacl-statistics-profile profile-name] hierarchy level and include all-fields at the [edit system services local-policy-decision-function aacl-statistics-profile profile-name aacl-fields] hierarchy level. The following operational commands display information about the packet-triggered subscribers: show services subscriber bandwidth, show services subscriber dynamic-policies, show services subscriber flows, show services subscriber sessions, and show services subscriber statistics.
[Services Interfaces, System Basics and Services Command Reference, Subscriber Access]

Subscriber Access Management

Support for subscriber management features on Trio MPC/MIC interfaces (MX Series routers)—Enables support for all subscriber management features introduced in JUNOS Release 10.1 and lower-numbered releases on Trio MPC/MIC interfaces available on MX Series routers.
For a list of the subscriber management features and other protocols and applications supported on the MX Series MPCs, see Protocols and Applications Supported by MX Series MPCs in the MX Series 3D Universal Edge Routers Line Card Guide.
[Subscriber Access, MX Series Line Card ]
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 interfaces that are running over Trio MPC/MIC interfaces on MX Series routers.
[Subscriber Access]
Support for frame and cell-shaping mode and byte adjustments on static and dynamic subscriber interfaces (MX Series routers)—Enables you to configure frame-based and cell-based shaping mode and byte adjustments on static or dynamic subscriber interfaces in a broadband access network. This feature is supported on Trio MPC/MIC interfaces on MX Series routers.
In a broadband access network, ATM traffic can be passed downstream from other customer premise equipment (CPE) to the MX Series router. Managing the bandwidth of downstream ATM traffic to Ethernet interfaces can be difficult because of the different Layer 2 encapsulations.
You can configure the shaping mode to shape downstream ATM traffic based on either frames or cells. In frame shaping mode, shaping is based on the number of bytes in the frame, without regard to cell encapsulation or padding overhead. Frame is the default shaping mode on the router.
In cell shaping mode, shaping is based on the number of bytes in cells, and accounts for the ATM cell encapsulation and padding overhead. When you specify cell shaping, the resulting traffic stream conforms exactly to the policing rates configured in downstream ATM switches, reducing the number of packet drops in the Ethernet network.
In addition, you can account for the different byte sizes per encapsulation by configuring a byte adjustment value for the shaping mode. For example, you can configure frame shaping mode and a byte adjustment value to account for differences in Layer 2 protocols for downstream Ethernet traffic.
To configure the shaping mode, include the new overhead-accounting (frame-mode | cell-mode) statement at the [edit class-of-service traffic-control-profiles profile-name] hierarchy level or the [edit dynamic-profiles class-of-service traffic-control-profiles profile-name] hierarchy level.
To configure byte adjustments, include the bytes byte-value option with the overhead-accounting (frame-mode | cell-mode) statement. We recommend that you configure the byte-value that represents the difference between the CPE protocol overhead and the BRAS protocol overhead. The configurable range is -120 to 124 bytes.
[Subscriber Access, Class of Service]
Support for dynamic distribution of excess bandwidth among different subscriber services on subscriber interfaces (MX Series routers with Trio MPC/MIC interfaces)—Enables you to control the distribution of excess bandwidth sharing on dynamic subscriber interfaces on Trio MPC/MIC interfaces available on MX Series routers. In earlier releases, excess bandwidth sharing was supported on EQ DPCs only.
Service providers often used tiered services that must utilize excess bandwidth as traffic patterns vary. By default, excess bandwidth between a configured guaranteed rate and shaping rate is shared equally among all queues with the same excess priority value, which might not be optimal for all subscribers to a service.
To configure the excess rate for a traffic control profile in a dynamic profile, include the excess-rate statement at the [edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name] hierarchy level and apply the traffic control profile at the [edit dynamic-profiles profile-name class-of-service interfaces interface-name] hierarchy level. To configure the excess rate for a queue, include the excess-rate and excess-priority statements at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level.
[Subscriber Access]
Support for MAC address validation on Trio MPC/MIC interfaces on MX Series routers—Enables MAC (source address) validation to use filters over Trio MPC/MIC interfaces on MX Series routers. MAC validation is the process of verifying that the origin of the MAC address received matches the origin present in the router ARP entry table. You can enable MAC validation in either strict or loose mode on static or dynamic demux interfaces using dynamic profiles.
[Subscriber Access]
Support for IP demux subscriber secure policy and MAC validate configuration on Trio MPC/MIC interfaces—Enables the configuration of subscriber secure policy and MAC validation using dynamic IP demux interfaces over Trio MPC/MIC physical interfaces on MX Series routers.
[Subscriber Access]
Support for dynamic 802.1Q VLAN interface configuration for PPPoE over Trio MPC/MIC interfaces on MX Series routers—Enables you to configure dynamic 802.1Q VLANs for PPPoE on Trio MPC/MIC interfaces on MX Series routers. This support includes an enhancement to the accept statement to include a new pppoe VLAN Ethernet packet type. You can specify this packet type at the [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile profile-name] and the [edit interfaces interface-name auto-configure stacked-vlan-ranges dynamic-profile profile-name] hierarchy levels. The pppoe VLAN Ethernet packet type option is supported only for Trio MPC/MIC interfaces on MX Series routers.
[Subscriber Access]
Support for IPv6 demux configuration on Trio MPC/MIC interfaces on MX Series routers—Enables dynamic IPv6 demux configuration on Trio MPC/MIC interfaces on MX Series routers.
[Subscriber Access]
Support for dynamic CoS for IP demux interfaces on Trio MPC/MIC interfaces (MX Series routers)—Enables you to configure dynamic CoS for a static or dynamic IP demultiplexing (demux) subscriber interface on the Trio MPC/MIC interfaces available on MX Series routers. In earlier releases, dynamic CoS for IP demux interfaces was supported on EQ DPCs only.
Hierarchical CoS for aggregated Ethernet interfaces is now supported on the Trio MPC/MIC family when a static or dynamic demux subscriber interface is the underlying interface. In earlier releases, hierarchical CoS for aggregated Ethernet was only supported on the Trio MPC/MIC family when a static or dynamic VLAN was the underlying interface.
[Subscriber Access]
Support for non-hierarchical dynamic CoS configurations on subscriber interfaces (MX Series routers)—Enables you to configure per-unit scheduling dynamically for subscriber interfaces configured on EQ DPCs and Trio MPC/MIC interfaces on MX Series routers and Ethernet Enhanced IQ2 (IQ2E) PICs on M120 and M320 routers.
In earlier releases, you had to enable hierarchical scheduling prior to configuring a dynamic access or service profile with CoS parameters. In per-unit scheduling configurations, each Layer 3 scheduler node is allocated a dedicated set of queues. If you do not explicitly configure CoS parameters, a default traffic profile with queues is attached to the logical interface. Interfaces are not dynamically created with a new set of queues when the existing queue limit is reached.
To enable per-unit scheduling for the subscriber interface, include the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level. You can then configure dynamic CoS parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level and the remaining static parameters at the [edit class-of-service] hierarchy level.
[Subscriber Access]
PPPoE service name table enhancements (M120, M320, and MX Series routers)—Support the following new and enhanced features for PPPoE service name tables:
- Configuration of any service.
  The any service acts as a default service for non-empty service entries that do not match the empty or named service entries configured in the PPPoE service name table on the router. The any service is useful when you want to match the agent circuit ID and agent remote ID information for a PPPoE client, but do not care about the service name tag that is transmitted in the control packet.
  To configure the any service, include the service any statement at the [edit protocols pppoe service-name-table table-name] hierarchy level.
- Association of agent circuit identifier/agent remote identifier (ACI/ARI) pairs with empty or any service.
  Associating an ACI/ARI pair with an empty or any service enables you to identify the DSLAM interface that initiated the service request (agent circuit ID string) and the subscriber on the DSLAM interface that initiated the service request (remote ID string). In lower-numbered releases, you could not associate ACI/ARI pairs with the empty service.
  To configure an ACI/ARI pair for an empty or any service, include the agent-specifier statement at the [edit protocols pppoe service-name-table table-name service ( empty | any )] hierarchy level.
- Association of a PPPoE dynamic profile with a named service, empty service, any service, or ACI/ARI pair.
  You can associate a previously configured PPPoE dynamic profile with a named, empty, or any service entry in the PPPoE service name table, or with an ACI/ARI pair defined for these services. The router uses the attributes defined in the profile to instantiate a dynamic PPPoE interface to handle the PPPoE session. The dynamic profile associated with the PPPoE service name table entry overrides the dynamic profile assigned to the underlying Ethernet interface.
  To associate a dynamic profile with a named, empty, or any service, include the dynamic-profile statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.
  To associate a dynamic profile with an ACI/ARI pair, include the dynamic-profile statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string] hierarchy level.
- Association of routing instance with named service, empty service, any service, or ACI/ARI pair.
  To specify the routing instance in which the router should create the dynamic PPPoE interface, you can associate a previously configured routing instance with a named, empty, or any service entry in the PPPoE service name table, or with an ACI/ARI pair defined for these services. The routing instance associated with the PPPoE service name table entry overrides the routing instance associated with the underlying Ethernet interface.
  To associate a routing instance with a named, empty, or any service, include the routing-instance statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.
  To associate a routing instance with an ACI/ARI pair, include the routing-instance statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string] hierarchy level.
- Association of static PPPoE interface with ACI/ARI pair.
  You can associate a previously configured static PPPoE interface with an ACI/ARI pair defined for a named, empty, or any service entry configured in the PPPoE service name table. The router reserves the specified static interface for use only with the matching service name table entry.
  To associate a static PPPoE interface with an ACI/ARI pair, include the static-interface statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string] hierarchy level.
- Configurable maximum sessions limit for named service, empty service, or any service.
  You can configure the maximum number of active PPPoE sessions using either dynamic or static PPPoE interfaces that the router can establish with the specified service name table entry, in the range from 1 through the platform-specific maximum for your router. The default value is equal to the maximum number of PPPoE sessions supported on your router. The maximum sessions value associated with the PPPoE service name table entry is used in conjunction with the maximum sessions value configured for the underlying Ethernet interface.
  To configure the maximum sessions limit for a named, empty, or any service, include the max-sessions statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.
- Option to globally advertise named services in PPPoE Active Discovery Offer (PADO) control packets.
  By default, advertisement of named services in PADO control packets sent by the router is disabled. You can enable advertisement of named services in the PADO packet when you define the PPPoE protocol. If you do so, make sure the number and length of the named service entries advertised in the PADO packet do not exceed the MTU size of the underlying Ethernet interface.
  To enable advertisement of named services in PADO control packets sent by the router, include the pado-advertise statement at the [edit protocols pppoe] hierarchy level.
- Increased system maximums for PPPoE service name tables, named service entries, and ACI/ARI pairs.
  You can now configure a maximum of 32 PPPoE service name tables per M120, M320, or MX Series router; a maximum of 512 named service entries (excluding empty and any service entries) per PPPoE service name table; and a maximum of 8000 ACI/ARI pairs per PPPoE service name table.
To verify the PPPoE service name table configuration, use the following new and updated operational commands:
- To display information about all active PPPoE sessions and optionally filter the output by service name, agent circuit ID string, or remote ID string, issue the new show pppoe sessions command.
- To display configuration information for a PPPoE service name table, issue the show pppoe service-name-tables command. This command has been updated to include information about the any service, maximum sessions, and active sessions. This command also displays information about the dynamic profile, routing instance, and static interface attributes, if configured.
- To display session-specific information about PPPoE interfaces, issue the show pppoe interfaces command. This command has been updated to include the service name, agent circuit ID string, and agent remote ID string used to establish the active PPPoE session on the interface.
[Network Interfaces, Interfaces Command Reference, Subscriber Access]
Maximum queues for static and dynamic subscriber interfaces on Trio MPC modules (MX Series routers)—Enable you to scale to a maximum number of dedicated queues for static and dynamic subscriber interfaces configured on certain Trio MPC modules.
The following table lists the number of dedicated queues per module.
MPC Name
Number of Dedicated Queues
20–Gigabit Ethernet Queuing MPC
64,000 egress
40–Gigabit Ethernet Queuing MPC
128,000 egress
40–Gigabit Ethernet Enhanced Queuing MPC
512,000 egress
These values are supported for static CoS configurations configured at the [edit class-of-service] hierarchy level and dynamic CoS configurations configured at the [edit dynamic profiles profile-name class-of-service] hierarchy level. Hierarchical scheduling must be enabled on the interface, and per-unit scheduling is not supported.
When the maximum number of queues on the module is reached, a new system log message, COSD_OUT_OF_DEDICATED_QUEUES, is generated. All subsequent subscriber interfaces are not provided a dedicated set of queues. In hierarchical scheduling configurations, traffic from these logical interfaces is considered unclassified and attached to a common set of queues that are shared by all subsequent logical interfaces. These common queues are the default port queues that are created for every port. You can configure common queues for the physical interface by including the output-traffic-control-profile-remaining statement at the [edit class-of-service interfaces] hierarchy level.
The output of the show class-of-service interface interface-name operational command has been extended to display the traffic profile that is attached to the specified logical interface. In addition, the output displays the number of queues that have been consumed by the logical interfaces configured over a specific physical interface.
[Class of Service, Subscriber Access]
Dynamic profile and enhanced RADIUS support for MLPPP subscriber services (M120 and M320 routers)—RADIUS can now dynamically assign IPv4 addresses for MLPPP connections. The same address is allocated to all links in a bundle. AAA disconnects any link that is allocated an address different than the address previously allocated to member links in the bundle. The IP address is released for reallocation when the last member link in a bundle logs out.
The Acct-Multi-Session-Id attribute enables RADIUS to link multiple related sessions into a single log file. RADIUS uses the session database (SDB) bundle session ID for the value of Acct-Multi-Session-Id. This bundle ID enables RADIUS to initiate a disconnect for an entire bundle. By tracking the member link sessions, RADIUS is also able to disconnect the individual member links in a bundle.
The Acct-Link-Count [51] attribute records the number of links present in a multilink session at the time the accounting record is generated.
Include the dynamic-profiles profile-name statement at the [edit] hierarchy level to define a dynamic profile that specifies attributes to be applied dynamically to MLPPP bundle interfaces.
The dynamic-profile profile-name statement at the [edit interfaces interface-name unit logical-unit-number ppp-options] hierarchy level now supports certain LSQ interfaces. Include this statement to assign the dynamic profile to the LSQ MLPPP bundle interface.
These MLPPP subscriber access features are supported only on the Channelized DS3/E3 Enhanced IP PIC (PB-4CHDS3-E3-IQE-BNC) on M120 and M320 routers. The MLPPP subscriber services are available only on LSQ interfaces configured on Adaptive Services PICs or Multiservices PICs.
[Subscriber Access]
Address-assignment pool linking (MX Series routers)—Subscriber management enables you to link an address-assignment pool to a second pool. Linking enables you to provide a backup address pool in the event that all addresses in the primary address-assignment pool are allocated. The router automatically begins allocating addresses from the secondary (linked) address-assignment pool when the primary pool is fully allocated.
Both IPv4 and IPv6 address-assignment pools support linking. However, the secondary pool must be the same family type as the primary pool. You cannot link an IPv4 address-assignment pool to an IPv6 pool, or vice versa.
You use the link statement at the [edit access address-assignment pool pool-name] hierarchy level to specify the secondary address-assignment pool.
You use the show network-access aaa statistics address-assignment pool command to display information about an address-assignment pool, such as the percentage of the pool that has been allocated.
[Subscriber Access]
Distinguishing DHCP duplicate clients by subinterface (MX Series routers)—You can now optionally configure DHCP to include the client subinterface when distinguishing between duplicate DHCP clients (clients with the same MAC or client ID) in the same subnet.
By default, DHCP distinguishes clients by subnet. However, when multiple subinterfaces share the same underlying loopback interface with the same preferred source address, the subinterfaces appear to be on the same subnet, and DHCP is unable to differentiate between duplicate clients. The optional configuration enables DHCP to use the client subinterface to differentiate between the duplicate clients within the subnet.
Distinguishing DHCP clients by subinterface is supported on DHCPv4 only, and is supported per logical system routing instance.
- To enable duplicate client subinterface support for DHCP local server, include the duplicate-clients-on-interface statement at the [edit system services dhcp-local-server] hierarchy level.
- To enable duplicate client subinterface support for DHCP relay agent, include the duplicate-clients-on-interface statement at the [edit forwarding-options dhcp-relay] hierarchy level. Also, DHCP relay must be configured to insert option 82 Agent Circuit ID with the interface name, and the DHCP local server must echo this option 82 in its reply.
[Subscriber Access]

MPC Name	Number of Dedicated Queues
20–Gigabit Ethernet Queuing MPC	64,000 egress
40–Gigabit Ethernet Queuing MPC	128,000 egress
40–Gigabit Ethernet Enhanced Queuing MPC	512,000 egress

Sending a DHCP relay and relay proxy release message (MX Series routers)—You can configure DHCP relay and relay proxy to generate and send a release message to the DHCP server whenever DHCP relay or relay proxy delete a client. This release message sent by DHCP relay and relay proxy includes option 82 information. By default, no release message is sent.

To configure DHCP relay and relay proxy to send a release message, include the send-release-on-delete statement at the following hierarchy levels:

Global configuration—[edit forwarding-options dhcp-relay overrides]
Named group configuration—[edit forwarding-options dhcp-relay group group-name overrides]

Per interface configuration—[edit forwarding-options dhcp-relay group group-name interface interface-name overrides]

Note: In earlier releases, if the client-discover-match statement was configured, DHCP relay sent a release message to the DHCP server when a client was deleted. This is no longer the case. To configure DHCP to send the release message, you must configure the send-release-on-delete statement.

[Subscriber Access]

SNMP trap support for subscriber secure policy (MX Series routers)—Subscriber secure policy supports the use of SNMPv3 traps to capture and report packet mirroring information to an external mediation device. The traps map to messages defined in the Lawfully Authorized Electronic Surveillance (LAES) for IP Network Access, American National Standard for Telecommunications.

You use standard configuration methods, as described in the JUNOS Network Management Configuration Guide, to configure the mediation device to receive the SNMPv3 trap information. Your configuration must include the authentication and privacy keys.

The SNMPv3 traps, which are provided in the Juniper Packet Mirroring MIB, jnx-js-packet mirror.mib, are described in the following table:

Table 2: SNMP Traps for Subscriber Secure Policy

Trap	Description
jnxPacketMirrorLiSubscriberLoggedIn	A subscriber, who is identified to have a mirrored service that is activated at login, has successfully logged in.
jnxPacketMirrorSessionLiSubscriberLogInFailed	A subscriber, who is identified to have a mirrored service that is activated at login, has failed to log in.
jnxPacketMirrorInterfaceLiSubscriberLoggedOut	A subscriber, who had an active mirrored service, has logged out.
jnxPacketMirrorInterfaceLiServiceActivated	A mirrored session has been activated.
jnxPacketMirrorSessionLiServiceActivationFailed	A mirrored session for a subscriber has failed.
jnxPacketMirrorSessionLiServiceDeactivated	A mirrored session for an established subscriber has been deactivated.
jnxPacketMirrorMirroringFailure	A mirrored service request failed due to an invalid value in the request. Note: This trap is not related to LAES messages.