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

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

Class of Service

• IEEE 802.1p and DEI rewriting based on forwarding class and PLP at VPLS ingress PE (MX Series routers)—Enables you to rewrite (mark) the IEEE 802.1p or DEI bits on frames at the VPLS ingress PE based on the value of the forwarding class and PLP established for the traffic on MX Series routers. You can rewrite either the outer tag only or both the outer and inner tag. When both tags are rewritten, both get the same value. To configure these rewrite rules, include the ieee-802.1 statement at the [edit class-of-service routing-instances name rewrite-rules] hierarchy level. This feature is supported only on enhanced DPCs.

  [Class of Service]

• IEEE 802.1p and DEI rewriting based on forwarding class and PLP at VPLS ingress PE (IQ2 and IQ2E PICs)—On routers with IQ2 or IQ2E PICs, enables you to rewrite (mark) the IEEE 802.1p or DEI bits on frames at the VPLS ingress PE based on the value of the forwarding class and PLP established for the traffic. You can rewrite either the outer tag separately or both the outer and inner tag. When both tags are rewritten, both get the same value.

  To configure these rewrite rules, include the ieee-802.1 statement at the [edit class-of-service routing-instances name rewrite-rules] hierarchy level.

  [Class of Service]

• BA classification based on the inner VLAN tag (IQ2 and IQ2E PICs)—On routers with IQ2 or IQ2E PICs, enables you to perform behavior aggregate (BA) classification based on the inner VLAN tag. To configure BA classification, include the inner option at the [edit class-of-service interfaces interface-name unit logical-unit-number classifiers ieee-802.1 classifier-name vlan-tag] hierarchy level.

  [Class of Service]

• User-defined DSCP classification (queuing PFEs only)—On MX, M120, and M320 routers with Enhanced Type III FPCs only, you can configure user-defined DSCP-based BA classification for MPLS interfaces (this feature is not available for IQE PICs) or VPLS/L3VPN routing instances (LSI interfaces). The DSCP-based classification for MPLS packets for Layer 2 VPNs is not supported. To classify MPLS packets on the routing instance at the egress PE, include the dscp or dscp-ipv6 statements at the [edit class-of-service routing-instances routing-instance-name classifiers] hierarchy level. To classify MPLS packets at the core-facing interface, apply the classifier at the edit class-of-service interface interface-name unit unit-name classifiers (dscp | dscp-ipv6) classifier-name family mpls] hierarchy level (this feature is not available for IQE PICs or on MX Series routers when ingress queuing is used).

  [Class of Service]

• Forwarding class map for unicast and multicast traffic and a user-configured queue number for egress interfaces—For the IQ, IQ2, IQE, LSQ, and ATM2 PICs in the T320, T640, and T1600 routers, you can configure a forwarding class map for unicast and multicast traffic and a user-configured queue number for an egress interface. DSCP rewrites are not allowed on these interfaces. You cannot apply the forwarding class map on an LSQ physical interface because per-unit scheduling is enabled by default and cannot be disabled manually. The interface-specific forwarding-class map is configured at the [edit class-of-service forwarding-classes-interface-specific forwarding-class-map-name class class-name queue-num queue-number (restricted-queue queue-number)] hierarchy level. You apply the forwarding-class map to the logical unit level at the [edit interfaces interface-name unit logical-unit-number output-forwarding-class-map forwarding-class-map-name] hierarchy level. For PICs that are restricted to four queues, you can control the queue assignment with the restricted-queue option or rely on the routing platform to override the queue assignment using modular arithmetic.

  [Class of Service, Multicast]

High Availability

• New configuration statement to control VRRP advertisements—A new configuration statement vrrp-inherit-from at the [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-number] hierarchy level enables you to control VRRP advertisements from various VRRP groups configured on different subnets of a VLAN. When the vrrp-inherit-from configuration statement is included in the configuration, only the master VRRP group from which the other master VRRP groups are inheriting the state sends out VRRP advertisements. The groups inheriting the state do not send any VRRP advertisements as the state is maintained only on the group from which the state is inherited. If the vrrp-inherit-from statement is not configured, each of the VRRP master groups in the various subnets on the VLAN sends out separate VRRP advertisements and adds to the traffic on the VLAN.

  When you have included the vrrp-inherit-from statement for a VRRP group, the VRRP group inherits the following parameters from the specified group:

  • advertise-interval
  • authentication-key
  • authentication-type
  • fast-interval
  • preempt | no-preempt
  • priority
  • track interfaces
  • track routes

  However, you can configure the accept-data | no-accept-data statement for the group to specify whether the interface should accept packets destined for the virtual IP address.

  [High Availability]

• Nonstop active routing support for LDP OAM features—Extends nonstop active routing support for LDP Operation, Administration, and Maintenance (OAM) features. Nonstop active routing support for LDP OAM features ensures that both egress and ingress LSPs maintain OAM state information, including information about BFD sessions during and after Routing Engine switchover, and minimizes control plane churn and traffic loss during and after the Routing Engine switchover.

  [High Availability]

• Graceful Routing Engine switchover (GRES) support for TX Plus routing matrix—JUNOS Release 9.6 extends GRES support to the TX Matrix Plus router.

  Note: TX Matrix Plus routers and T1600 routers that are configured as part of a routing matrix do not currently support nonstop active routing.

  [High Availability]

• Graceful Routing Engine switchover (GRES) and nonstop active routing support for pseudowire configurations—JUNOS Release 9.6 extends GRES and nonstop active routing support to Layer 2 circuit and LDP-based VPLS pseudowire configurations.

  [High Availability]

• Distributed periodic packet management (PPMD) support for VRRP—Typically, VRRP advertisements are sent by the VRRP process (vrrpd) on the master VRRP router at regular intervals to let other members of the group know that the VRRP master router is operational.

  When the VRRP process is busy and does not send VRRP advertisements, the backup VRRP routers may assume that the master router is down and take over as the master router, causing unnecessary flaps as the takeover occurs, irrespective of the fact that the original master is still active and available, and may restart sending advertisements after the load has decreased. To address this problem and to reduce the load on VRRPD, the JUNOS Software now uses the Periodic Packet Management process (PPMD) to send VRRP advertisements on behalf of VRRPD.

  However, you can further delegate the job of sending VRRP advertisements to the distributed PPMD that resides on the Packet Forwarding Engine. The ability to delegate the sending of VRRP advertisements to the distributed PPMD ensures that the VRRP advertisements are sent even when PPMD—which is now responsible for generating VRRP advertisements—is busy, and prevents the possibility of false alarms when PPMD is busy.

  To configure PPMD to send VRRP advertisements when VRRPD is busy, include the set delegate-processing statement at the [edit protocols vrrp] hierarchy level.

  [edit protocols vrrp]

  set delegate-processing;

  [High Availability]

• Unified ISSU support on additional hardware—JUNOS Release 9.6 extends the unified ISSU support to the following PICs:
  • 4-port Ethernet (PD-4XGE-XFP) PIC (only on T640 and T1600 routers)
  • 1-port Channelized OC48/STM16 Enhanced IQ2 PIC (PB-1CHOC48-STM16-IQE)

  [High Availability]

Interfaces and Chassis

• IPv6 support for unnumbered Ethernet interfaces (M Series and MX Series routers)—Enables you to configure IPv6 processing on an Ethernet interface without assigning an explicit IPv6 address to the interface. Using unnumbered interfaces allows a single subnet to be shared across multiple interfaces. This feature also supports nonsubnetted Ethernet for IPv6 (/128 addressing).

  When you configure an unnumbered Ethernet interface, you configure the interface to borrow an address from a donor interface. To specify the name of the donor interface, include the unnumbered-address interface-name statement at the [edit interfaces interface name unit logical-unit-number family inet6] hierarchy level. The unnumbered-address interface-name statement is also supported at the [edit dynamic-profiles profile-name interfaces interface-name] and [edit logical-systems logical-system-name interfaces interface-name] hierarchy levels.

  The output of the show interface operational command now includes information for IPv6 unnumbered Ethernet interfaces.

  [Network Interfaces, Routing Protocols, Interfaces Command Reference, Subscriber Access]

• 802.1ag optional type, length, and value (TLV) support—Provides configuration support for the Port Status TLV and the Interface Status TLV on M120, M320, and MX Series routers. Configuring the Port Status TLV allows the operator to control the transmission of the Port Status TLV in connectivity fault management PDUs. The Interface Status TLV indicates the status of the interface on which the MEP transmitting the CCM is configured (which is not necessarily the interface on which it resides), or the next-lower interface in the IETF RFC 2863 IF-MIB.

  To configure the Port Status TLV, include the port-status-tlv option at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] hierarchy level. To configure the Interface Status TLV, include the interface-status-tlv option at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] hierarchy level.

  You can use show commands to display the different values of the Port Status TLV, Interface Status TLV, and action profile information. To display information about a local MEP, use the show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier command.

  To display information about a remote MEP, use the show oam ethernet connectivity-fault-management mep-database maintenance domain identifier maintenance-association identifier remote-mep identifier command.

  To display information about an event configured under an action profile that occurs for a remote MEP, including the action taken and the corresponding time, you can display the MEP database output for that remote MEP using the show oam ethernet connectivity-fault-management mep-database maintenance domain identifier maintenance-association identifier remote-mep identifier command.

  When all configured events (under an action profile) are cleared, then the action taken gets reverted (for example, the down interface is up) and corresponding time can be displayed using the show oam ethernet connectivity-fault-management mep-database maintenance domain identifier maintenance-association identifier remote-mep identifier command.

  [Network Interfaces]

• Channelized ATM support on 12-port T1/E1 CE and 4-port Channelized OC3/STM1 circuit emulation interfaces—On M7i, M10i, and M40e routers, support is provided for ATM pseudowires (RFC 4717) and packet encapsulations (RFC 2684).

  CE PICs support the following ATM protocols:

  • ATM over PWE3 (RFC 4717)
  • ATM PWE3 via dynamic labels (LDP, RSVP-TE)

  CE PICs provide ATM pseudowire encapsulation support for cell relay pseudowire or AAL5 pseudowire. Cell relay mode supports logical or physical interfaces. To configure a cell-relay pseudowire, use the encapsulation atm-ccc-cell-relay and atm-l2circuit-mode cell statements at the [edit interfaces at-fpc/pic/port unit n] hierarchy level. To configure an AAL5 pseudowire, use the encapsulation atm-ccc-vc-mux and atm-l2circuit-mode aal5 statements at the [edit interfaces at-fpc/pic/port unit n] hierarchy level.

  Note: The encapsulation atm-ccc-cell-relay command can be set at either the physical interface or logical interface. atm-ccc-vc-mux can only be set at the logical interface.

  ATM OAM on CE interfaces supports the following OAM-FM cell types:

  • F4 AIS (end-to-end)
  • F4 RDI (end-to-end)
  • F4 loopback (end-to-end)
  • F5 loopback
  • F5 AIS
  • F5 RDI

  ATM encapsulations provide congestion control via EPD thresholds on a per logical interface basis. For CE PICs, the EPD number specifies the number of packets (or frames, or cell bundles). To configure the EPD threshold, use the epd-threshold < packets> statement and plp1 < packets> option at the [edit interfaces at-fpc/pic/port unit unit-number] hierarchy level.

  When you configure CE PICs for ATM, you must specify atm-ce as the PIC type in the atm-options. To configure the PIC type, use the pic-type < atm-ce> statement at the [edit interfaces at-fpc/pic/port] hierarchy level.

  With CE PICs, ATM is also supported on E1 and T1 media. You can configure the E1 options or T1 options using the e1-options or t1-options statement at the [edit interfaces at-fpc/pic/port] hierarchy level.

  [Network Interfaces]

• Chassis operational mode commands supported on the TX Matrix Plus router—The following CLI operational mode commands support chassis and fabric management operations on a TX Matrix Plus router:

  Show commands:

  • show chassis alarms
  • show chassis cip (new command introduced for the TX Matrix Plus router)
  • show chassis craft-interface
  • show chassis environment
  • show chassis environment cb
  • show chassis environment cip
  • show chassis environment pem
  • show chassis environment routing-engine
  • show chassis environment scg
  • show chassis environment sib
  • show chassis ethernet-switch
  • show chassis fabric plane
  • show chassis fabric plane-location
  • show chassis fabric topology
  • show chassis firmware
  • show chassis hardware
  • show chassis location
  • show chassis routing-engines
  • show chassis sibs
  • show chassis spmb
  • show chassis temperature-thresholds

  Request commands:

  • request chassis cb
  • request chassis cip (new command introduced for the TX Matrix Plus router)
  • request chassis fpm
  • request chassis sib
  • request chassis spmb

  Clear command:

  • clear chassis display message

  Set command:

  • set chassis display

  Restart command:

  • restart chassis-control

  [System Basics and Services Command Reference]

• New management Ethernet interface em0 for the TX Matrix Plus router and T1600 routers in a routing matrix—The management Ethernet interface used for the TX Matrix Plus router and the T1600 routers in a routing matrix is em0. This interface provides an out-of-band method for connecting to the routers in the routing matrix.

  The Routing Engines in the TX Matrix Plus router and the T1600 routers (in the routing matrix) support only the management Ethernet interface, em0. They do not support the management Ethernet interface, fxp0. Automated scripts developed for standalone T1600 routers that are not in a routing matrix cannot be directly used on T1600 routers in a routing matrix. They might contain references to the fxp0 management Ethernet interface. Before reusing the scripts on T1600 routers in a routing matrix, ensure that all commands in the scripts that reference the fxp0 management Ethernet interface are updated to reference the em0 management Ethernet interface.

  [TX Matrix Plus Hardware Guide, Network Interfaces, System Basics, Interfaces Command Reference, System Basics and Services Command Reference, Software Installation and Upgrade Guide, High Availability]

• Redundant Service PIC (RSP) hot standby (M Series and T Series platforms with MS-PICs and MX Series routers with MS-DPCs)—Enables the use of a redundant pair of service PICs to operate in hot standby mode, facilitating faster switching to the standby PIC in a failover situation. Configuration changes are applied to both of the paired PICs simultaneously. This differs from the previously implemented warm standby functionality, in which the standby PIC receives configuration information at the time of failover. The maximum switchover time is 5 seconds. A typical switchover time would depend on the failure conditions and could be much less than the maximum.

  To configure hot standby for a pair of service PICs, include the hot-standby statement at the [edit interfaces rsp0 redundancy-options] hierarchy level.

  [Multiplay Solutions, Services Interfaces]

• Aggregated interfaces support hierarchical queuing and shaping—M120, MX Series, and T Series routers, with aggregated Ethernet IQ2 PICs in non-link-protect mode, support the following scheduler functions:
  • Per-unit scheduler
  • Hierarchical scheduler
  • Shaping at the physical and logical interface (aggregated interface) level

  You can configure the hierarchical-scheduler mode on an aggregated Ethernet interface in non-link-protect mode using the aggregated-ether-options statement at the [edit interfaces aeX] hierarchy level. Prior to JUNOS Release 9.6, the hierarchical scheduler mode required the aggregated-ether-options statement link-protection option, otherwise a configuration error would result.

  You can also specify the member link bandwidth derivation based on the equal division model (scale) or the replication model (replicate) using the member-link-scheduler (scale | replicate) option at the [edit class-of-service interfaces aeX] hierarchy level. The default setting is scale.

  [Network Interfaces]

• Support for the 4-port 10-Gigabit Ethernet LAN/WAN PIC with XFP (PD-4XGE-XFP) as a shared interface PIC on the JCS1200 platform—On the JCS1200 platform, a single Physical Interface Card (PIC) can be used by different PSDs to forward and receive network traffic. With JUNOS Release 9.6, the 4-port 10-Gigabit Ethernet LAN/WAN PIC with XFP can be used as a shared interface.

  [Protected System Domain]

• 802.1ag Ethernet OAM for CCC encapsulated packets—On M120 and MX Series routers, CFM sessions on interfaces with CCC encapsulation can monitor L2VPN circuits for both L2 circuits and L2 VPNs.

  CFM features supported on L2VPN circuits are as follows:

  • Creation of UP/DOWN MEPs at any level on the customer edge (CE)-facing logical interface.
  • Creation of MIPs at any level on the CE-facing logical interface.
  • Support for continuity check, loopback, and linktrace protocol.
  • Support for Y1731 Ethernet delay measurement protocol.
  • Support for action profiles to bring the CE-facing logical interface down when loss of connectivity is detected.

  To monitor an L2VPN circuit, CFM UP MEP can be configured on the CE-facing logical interfaces of the provider edge routers. To monitor the CE-PE attachment circuit, a CFM DOWN MEP can be configured on the customer logical interfaces of CEn-PEn routers.

  To create a MIP on the CE-facing interface of the PE router, use the interface (ge | xe)-fpc/pic/port.unit statement at the [protocols oam ethernet connectivity-fault-management maintenance-domain < identifier> ] hierarchy level.

  [Network Interfaces]

• Symmetrical load balancing on 802.3ad Link Aggregation (LAG) on MX Series routers—MX Series routers with aggregated Ethernet PICs now support symmetrical load balancing on 802.3ad LAG. This feature is significant when two MX Series routers are connected transparently through Deep Packet Inspection (DPI) devices over a LAG bundle. DPI devices keep track of flows and require information of a given flow in both forward and reverse directions. Before symmetrical load balancing on 802.3ad LAG, the DPIs could misunderstand the flow, leading to traffic disruptions. Adding this feature means that a given flow of traffic (duplex) is ensured to hit the same devices in both directions.

  This feature utilizes a mechanism of interchanging the source and destination addresses for a hash computation of fields, such as source address and destination address. The result of a hash computed on these fields is used to choose the link of the LAG. The hash computation for the forward and reverse flow must be identical. This is achieved by swapping source fields with destination fields for the reverse flow. The swapped operation is complement hash computation or symmetric-hash complement and the regular (or unswapped) operation is symmetric-hash computation or symmetric-hash. The swappable fields are: MAC address, IP address, and port.

  You can now specify whether symmetric hash or complement hash is done for load-balancing traffic. To configure symmetric hash, use the symmetric-hash statement at the [edit forwarding-options hash-key family inet] hierarchy level. To configure symmetric-hash complement, use the symmetric-hash < complement> statement and option at the [edit forwarding-options hash-key family inet] hierarchy level.

  These operations can also be performed at the PIC level by specifying a hash key. To configure a hash key at the PIC level, use the symmetric-hash or symmetric-hash < complement> statement at the [edit chassis fpc fpc-slot pic pic-slot hash-key family inet] and [edit chassis fpc fpc-slot pic pic-slot hash-key family multiservice] hierarchy levels.

  The following restrictions apply:

  • The Packet Forwarding Engine (PFE) can be configured to hash the traffic in either symmetric or complement mode. A single PFE complex cannot work simultaneously in both operational modes and such a configuration can yield undesirable results.
  • The per-PFE setting overrides the chassis-wide setting only for the family configured. For the other families, the PFE complex still inherits the chassis-wide setting (when configured) or the default setting.
  • Any change in the hash-key configuration at the PIC level requires a reboot of the FPC for the changes to take effect.
  • This feature supports VPLS, INET, and bridged traffic only.
  • This feature cannot work in tandem with the per-flow-hash-seed < load-balancing> option. It requires that all the PFE complexes configured in complementary fashion share the same seed. A change in the seed between two counterpart PFE complexes may yield undesired results.

  In order for the symmetric or complement load balancing to work, the child member links of the LAGs should have identical order. To achieve this, configure the link-index while adding the child using the [edit interfaces interface gigether-options 802.3ad link-index link-index-number] command.

  [Network Interfaces, VPN, System Basics]

JUNOS XML API and Scripting

• Support for master source file for event script—Enables you to refresh the local copy of an event script from a master copy stored in a central repository. To configure the location of the master source file for a specific event script, include the source statement at the [edit event-options event-script file filename] hierarchy level. Specify the source as a Hypertext Transfer Protocol (HTTP) URL, FTP URL, or secure copy (scp)-style remote file specification. You then can refresh the local event script from the master copy by including the refresh statement at either the [edit event-options event-script file filename] hierarchy level to refresh a single event script or at the [edit event-options event-script] hierarchy level to refresh all enabled event scripts from their configured source files.

  In addition, you can refresh local event scripts from copies at an alternate location. Include the refresh-from statement and the source URL at the [edit event-options event-script file filename] hierarchy level to refresh a single event script or at the [edit event-options event-script] hierarchy level to refresh all enabled event scripts from copies at the specified source URL.

  [Configuration and Diagnostic Automation Guide]

• 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 9.6, along with their corresponding CLI command and response tag element.

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

  Request Tag Element	CLI Command	Response Tag Element
  <clear-bgp-damping>	clear bgp damping	NONE
  <clear-bgp-neighbor>	clear bgp neighbor	NONE
  <clear-bgp-table>	clear bgp table	NONE
  <clear-cfm-delay-statistics>	clear oam ethernet connectivity-fault-management delay-statistics	NONE
  <clear-cfm-linktrace-path-database>	clear oam ethernet connectivity-fault-management path-database	NONE
  <clear-cfm-statistics>	clear oam ethernet connectivity-fault-management statistics	NONE
  <clear-diameter-function>	clear diameter function	NONE
  <clear-diameter-peer>	clear diameter peer	NONE
  <clear-isis-adjacency-information>	clear isis adjacency	NONE
  <clear-isis-database-information>	clear isis database	NONE
  <clear-isis-overload-information>	clear isis overload	NONE
  <clear-isis-statistics-information>	clear isis statistics	NONE
  <clear-service-msp-flow-ipaction-table>	clear services flows ip-action	<service-msp-flow-drain-information>
  <clear-system-services-reverse-information>	clear system services reverse	NONE
  <get-bgp-rtf-information>	show bgp group rtf	<bgp-rtf-information>
  <get-cfm-delay-statistics>	show oam ethernet connectivity-fault-management delay-statistics	<cfm-delay-statistics>
  <get-cfm-forwarding-state-instance-information>	show oam ethernet connectivity-fault-management forwarding-state instance	<cfm-flood-instance-information>
  <get-cfm-forwarding-state-interface-information>	show oam ethernet connectivity-fault-management forwarding-state interface	<cfm-flood-interface-information>
  <get-cfm-interfaces-information>	show oam ethernet connectivity-fault-management interfaces	<cfm-interface>
  <get-cfm-linktrace-path-database>	show oam ethernet connectivity-fault-management path-database	<cfm-linktrace-path-database>
  <get-cfm-mep-database>	show oam ethernet connectivity-fault-management mep-database	<cfm-mep-database>
  <get-cfm-mep-statistics>	show oam ethernet connectivity-fault-management mep-statistics	<cfm-mep-statistics>
  <get-cfm-mip-information>	show oam ethernet connectivity-fault-management mip	<cfm-mip-information>
  <get-cos-classifier-table-information>	show class-of-service forwarding-table classifier	<cos-classifier-table-information>
  <get-cos-classifier-table-map-information>	show class-of-service forwarding-table classifier mapping	<cos-classifier-table-map-information>
  <get-cos-forwarding-class-information>	show class-of-service forwarding-class	<cos-forwarding-class-information>
  <get-cos- forwarding-class-map-interface- table-information>	show class-of-service forwarding-table forwarding-class-map mapping	<cos-forwarding-class-map- inteface-table-information>
  <get-cos-forwarding-class-map-table-information>	show class-of-service forwarding-table forwarding-class-map	<cos-forwarding-class-map- table-information>
  <get-cos-fragmentation-map-information>	show class-of-service fragmentation-map	<cos-fragmentation-map-information>
  <get-cos-fwtab-fabric-scheduler-map-information>	show class-of-service forwarding-table fabric scheduler-map	<cos-fwtab-fabric-scheduler- map-information>
  <get-cos-interface-map-information>	show class-of-service interface	<cos-interface-information>
  <get-cos-interface-set-map-information>	show class-of-service interface-set	<cos-interface-set-information>
  <get-cos-l2tp-session-map-information>	show class-of-service l2tp-session	<cos-l2tp-session-information>
  <get-cos-loss-priority-map-information>	show class-of-service loss-priority-map	<cos-loss-priority-map-information>
  <get-cos- loss-priority-map- table-binding-information>	show class-of-service forwarding-table loss-priority-map mapping	<cos-loss- priority-map- table-binding-information>
  <get-cos-loss-priority-map-table-information>	show class-of-service forwarding-table loss-priority-map	<cos-loss-priority-map-table-information>
  <get-cos-multi-destination-information>	show class-of-service multi-destination	<cos-multi-destination-information>
  <get-cos-policer-table-map-information>	show class-of-service forwarding-table policer	<cos-policer-table-map-information>
  <get-cos-red-information>	show class-of-service forwarding-table drop-profile	<cos-red-information>
  <get-cos-rewrite-information>	show class-of-service rewrite-rule	<cos-rewrite-information>
  <get-cos-rewrite-table-information>	show class-of-service forwarding-table rewrite-rule	<cos-rewrite-table-information>
  <get-cos-rewrite-table-map-information>	show class-of-service forwarding-table rewrite-rule mapping	<cos-rewrite-table-map-information>
  <get-cos-routing-instance-map-information>	show class-of-service routing-instance	<cos-routing-instance-information>
  <get-cos-scheduler-map-information>	show class-of-service scheduler-map	<cos-scheduler-map-information>
  <get-cos-scheduler-map-table-information>	show class-of-service forwarding-table scheduler-map	<cos-scheduler-map-table-information>
  <get-cos-shaper-table-map-information>	show class-of-service forwarding-table shaper	<cos-shaper-table-map-information>
  <get-cos-table-information>	show class-of-service forwarding-table	<cos-table-information>
  <get-cos-traffic-control-profile-information>	show class-of-service traffic-control-profile	<cos-traffic-control-profile-information>
  <get-cos-translation-table-information>	show class-of-service forwarding-table translation-table	<cos-translation-table-information>
  <get-cos-translation-table-map-information>	show class-of-service translation-table	<cos-translation-table-map-information>
  <get-cos- translation-table-mapping-information>	show class-of-service forwarding-table translation-table mapping	<cos- translation-table-mapping- information>
  <get-cos-virtual-channel-group-information>	show class-of-service virtual-channel-group	<cos-virtual-channel-group-information>
  <get-cos-virtual-channel-information>	show class-of-service virtual-channel	<cos-virtual-channel-information>
  <get-database- replication-statistics- information>	show database-replication statistics	<database-replication- statistics- information>
  <get-database- replication-summary- information>	show database-replication summary	<database-replication- summary-information>
  <get-dhcp-relay-binding-information>	show dhcp relay binding	<dhcp-relay-binding-information>
  <get-dhcp-relay-statistics-information>	show dhcp relay statistics	<dhcp-relay-statistics-information>
  <get-dhcp-server-binding-information>	show dhcp server binding	<dhcp-server-binding-information>
  <get-dhcp-server-statistics-information>	show dhcp server statistics	<dhcp-server-statistics-information>
  <get-diameter-function-information>	show diameter function	<diameter-function-information>
  <get-diameter-function-statistics>	show diameter function statistics	<diameter-function-statistics>
  <get-diameter-information>	show diameter	<diameter-information>
  <get-diameter-instance-information>	show diameter instance	<diameter-instance-information>
  <get-diameter-network-element-information>	show diameter network-element	<diameter-network- element- information>
  <get-diameter- network-element- map-information>	show diameter network-element map	<diameter-network-element- map-information>
  <get-diameter-peer-information>	show diameter peer	<diameter-peer-information>
  <get-diameter-peer-map-information>	show diameter peer map	<diameter-peer-map-information>
  <get-diameter-peer-statistics>	show diameter peer statistics	<diameter-peer-statisitics>
  <get-diameter-route-information>	show diameter route	<diameter-route-information>
  <get-fabric-queue-information>	show class-of-service fabric statistics	<fabric-queue-information>
  <get-igmp-output-group-information>	show igmp output-group	<igmp-output-group-information>
  <get-lldp-information>	show lldp	<lldp-information>
  <get-lldp-information-detail>	show lldp detail	<lldp-information-detail>
  <get-lldp-local-info>	show lldp local-information	<lldp-local-info>
  <get-lldp-neighbors-information>	show lldp neighbors	<lldp-neighbors-information>
  <get-lldp-remote-global-statistics>	show lldp remote-global-statistics	<lldp-remote-global-statistics>
  <get-lldp-statistics-information>	show lldp statistics	<lldp-statistics-information>
  <get-mld-output-group-information>	show mld output-group	<mld-output-group-information>
  <get-multicast-pim-to-igmp-proxy-information>	show multicast pim-to-igmp-proxy	<multicast- pim-to-igmp- proxy- information>
  <get-multicast-pim-to-mld-proxy-information>	show multicast pim-to-mld-proxy	<multicast- pim-to-mld- proxy-information>
  <get-statistics-information>	show system statistics	<statistics>
  <get-system-services-reverse-information>	show system services reverse	<system-services- reverse-information>
  <reload-eedebug-action-profile>	request security datapath-debug action-profile reload-all	<message>
  <request- monitor-ethernet- delay-measurement>	monitor ethernet delay-measurement	<ethdm-results>
  <request-ping-ethernet>	ping ethernet	<ethping-results>
  <request-traceroute-ethernet>	traceroute ethernet	<ethtraceroute-results>

  [JUNOS XML API Operational Reference]

Layer 2 Ethernet Services

• Support for Layer 2 services on routers with MS-DPCs (MX Series routers)—Layer 2 link services are supported on MX Series routers with MS-DPCs containing MS-DPC PICs that eventually bundle PPP links from the Type 2 channelized SONET PICs.

  To enable the Layer 2 service package for LSQ support, include the service-package layer-2 statement at the [edit chassis fpc slot-number pic pic-number adaptive-services] hierarchy level.

  [System Basics, Services Interfaces]

• Link Layer Discovery Protocol (LLDP) support (MX Series routers only)—Enables you to configure the LLDP protocol on interfaces on MX Series routers only. To configure and adjust default parameters, include the lldp statement at the [edit protocols] hierarchy level.

  LLDP is disabled by default. Use the enable statement to enable LLDP and the interfaces statement to enable LLDP on all or some interfaces. Adjust the frequency that LLDP advertises with the advertisement-interval statement. The default is 30 seconds. Adjust the transmit delay that LLDP delays successive advertisements with the transmit-delay statement. The default is 2 seconds. Adjust the hold multiplier that LLDP uses to purge the cache or learned information with the hold-multiplier statement. The default is 4 (or 120 seconds with the default advertisement interval). Adjust the physical topology trap interval that LLDP sends SNMP traps about statistics with the ptopo-configuration-trap-interval statement. The default is 60 seconds. Adjust the physical topology maximum hold time that LLDP holds dynamic entries with the ptopo-configuration-maximum-hold-time statement. The default is 300 seconds.

  [Layer 2 Configuration Guide]

• Layer 2 address learning in logical systems (MX Series routers only)—Enables Layer 2 address learning in logical systems for bridge domains and other virtual-switch routing instances on MX Series routers only. To configure, include the bridge-domains or switch-options statements at the [edit logical-systems logical-system-name] hierarchy level.

  [Layer 2 Configuration Guide]

Multicast

• Support for multicast OIF mapping—Multicast output interface (OIF) mapping enables you to configure multicast streams (data packets) so that they are directed to a different interface than multicast control packets (used for IGMP and MLD joins and leaves). If multiple control interfaces all request the same stream and are mapped to the same output interface, only one copy of the stream is transmitted.

  Note: OIF mapping and reverse OIF mapping are not supported on the same customer or shared interface.

  Configuring OIF mapping on a multicast interface requires the following general steps:

  1. Specify an OIF map.

     The OIF map is a routing policy statement that can contain multiple terms. To specify an OIF map, use the policy-statement statement at the [edit policy-options policy-statement] hierarchy level. The from clause in each term can select multicast flows based on the multicast group (using the route-filter keyword) and the source address (with the source-address-filter keyword). The then clause must accept or reject the term. However, the then clause is enhanced with a new map-to-interface statement at the [edit policy-options policy-statement policy-name term term-name then actions] hierarchy level. The map-to-interface statement sets a value similar to the existing metric or tag actions and requires you to specify either a logical interface (that is, any interface that multicast currently supports) or the keyword self. The self keyword specifies that multicast data packets are sent on the same interface as the control packets and no mapping occurs. If no term matches, then no multicast data packets are sent.

     When creating OIF maps, keep the following in mind:

     • If a physical interface is specified as the map-to-interface statement value (for example, ge-0/0/0), a ".0" is appended to the interface to create a logical interface (for example, ge-0/0/0.0).
     • Routing policy is configured using the CLI per logical system. You cannot configure routing policies dynamically. As part of the policy, you must configure the map-to-interface statement statically.
     • To use OIF mapping, you must also have IGMP, MLD, or PIM configured (see below for configuring IGMP or MLD as passive).
     • You cannot map to a mapped interface.
     • To use CAC with a mapped interface, you must configure it using the maximum-bandwidth statement (see the existing documentation for details about this statement).
     • Juniper Networks recommends that you configure policy statements for IGMP and MLD separately.
  2. Associate the OIF map with an interface.

     To associate a map with a logical interface, use the new oif-map statement at the [edit protocols igmp interface interface-name], [edit dynamic-prfiles profile-name protocols igmp interface interface-name], [edit protocols mld interface interface-name], or [edit dynamic-prfiles profile-name protocols mld interface interface-name] hierarchy levels. The OIF map is applied to all IGMP or MLD requests received on the configured interface.

     Note: If an OIF map is already configured on an interface, the new OIF map is added to the policy.

  3. Disable QoS adjustment.

     When configured, the OIF map performs QoS adjustment on the customer interface. QoS adjustment decreases the available bandwidth to the client interface by mapping multicast streams to the shared interface. This action occurs by default as long as a value is configured for the maximum-bandwidth statement at the [edit routing-options multicast interface interface-name] hierarchy level.

     If you do not want to reduce the customer interface bandwidth, you can specify the no-qos-adjust statement at the [edit routing-options multicast interface interface-name] or [edit dynamic-profiles profile-name routing-options multicast interface interface-name] hierarchy level. When you configure the no-qos-adjust statement for the customer interface, available bandwidth is not reduced on the customer interface when multicast streams are added to the shared interface.

     Note: Specifying the no-qos-adjust statement at the interface level also applies to the reverse-oif-mapping statement and is the preferred method for disabling QoS adjustment. The reverse-oif-mapping no-qos-adjust statement is deprecated but still supported.

  4. (Optional) Define passive mode for IGMP or MLD.

     A new passive statement exists at the [edit protocols igmp interface interface-name] and [edit protocols mld interface interface-name] hierarchy level. The passive statement specifies IGMP or MLD to run on the interface but to not send or receive control traffic (that is, IGMP or MLD reports, queries, and leaves).

     Note: The OIF map interface should not typically pass IGMP or MLD control traffic and should be configured as passive. However, the OIF map implementation does support running IGMP or MLD on an interface (control and data) in addition to mapping data streams to the same interface. In this case, you should configure IGMP or MLD normally (that is, not in passive mode) on the mapped interface.

  You can view OIF map-related information as follows:

  • You can use the show policy policy-name command to view the OIF map as a route policy.
  • The show configuration protocols igmp interface interface-name, show configuration protocols mld interface interface-name, show igmp interface, and show mld interface commands have been enhanced to display any OIF map association (when configured) and passive mode state (either on or off).
  • The show multicast interface command has been enhanced to display the state of no-qos-adjust (when configured).
  • New show igmp output-group and show mld output-group commands for IGMP and MLD display multicast group state for the interface that is sending the multicast data (that is, the output interface [OIF]). For interfaces with no OIF map, these new commands display very similar information as the show igmp group and show mld group commands because the control traffic interface is the same as the output interface. For interfaces with an OIF map, these new commands display the output interface specified by the OIF map. Adding the detail option adds an Input interface field to specify customer interfaces and a Group mode field to specify the group mode.
• Translation of PIM join/prune messages to IGMP or MLD report/leave messages—In some network configurations, customers are unable to run Protocol Independent Multicast (PIM) between the customer edge-facing PIM domain and the core-facing PIM domain, although PIM is running in sparse mode within each of these domains. Because PIM is not running between the domains, customers with this configuration cannot use PIM to forward multicast traffic across the domains. Instead, they might want to use Internet Group Management Protocol (IGMP) to forward IPv4 multicast traffic, or Multicast Listener Discovery (MLD) to forward IPv6 multicast traffic across the domains.

  To enable the use of IGMP or MLD to forward multicast traffic across the PIM domains in such topologies, you can configure the rendezvous point (RP) router that resides between the edge domain and core domain to translate PIM join/prune messages received from PIM neighbors on downstream interfaces into corresponding IGMP or MLD report/leave messages. The router then transmits the report/leave messages by proxying them to one or two upstream interfaces that you configure on the RP router.

  To configure the RP router to translate PIM join/prune messages into IGMP report/leave messages, include the pim-to-igmp-proxy statement at the [edit routing-options multicast] hierarchy level. Similarly, to configure the RP router to translate PIM join/prune messages into MLD report/leave messages, include the pim-to-mld-proxy statement at the [edit routing-options multicast] hierarchy level. As part of the configuration, you must specify the full name of at least one, but not more than two, upstream interfaces on which to enable the PIM-to-IGMP proxy or PIM-to-MLD proxy feature.

  To display the PIM-to-IGMP or PIM-to-MLD proxy state (enabled or disabled) and the name or names of the configured upstream interfaces, issue the show multicast pim-to-igmp-proxy command or the show multicast pim-to-mld-proxy command.

  [Multicast, Routing Protocols and Policies Command Reference]

• Flexible configuration for IGMP/MLD static-join—When you configure static groups on an interface on which you want to receive multicast traffic, you can specify the number of static groups to be automatically created. Additionally you can specify an increment that controls the group addresses to be used when the static groups are automatically created.

  To configure the number of static groups to be created, include the group-count statement and specify the number of groups to be created. To configure the group address increment, include the group-increment statement and specify the number by which the address should be incremented for each group. The increment is specified in dotted decimal notation similar to an IP address. For example, an increment of 0.0.0.3 increments the group address by three for each group created.

  The group-count statement and group-increment statement can be configured at the [edit protocols igmp interface interface-name static group multicast-group-address] and [edit logical-systems logical-system-name protocols igmp interface interface-name static group multicast-group-address] hierarchy levels.

  When you configure a static group on an interface on which you want to receive multicast traffic, you can configure the number of source addresses associated with the static group to be automatically created. Additionally, you can specify an increment that controls the source addresses to be used when the static group source addresses are automatically created.

  To configure the number of source addresses associated with a static group to be automatically created, include the source-count statement and specify the number of addresses to be created. To configure the source address increment include the source-increment statement and specify the number by which the address should be incremented for each source. The source increment is specified in dotted decimal notation similar to an IP address. For example, an increment of 0.0.0.2 increments the source address by two for each source created.

  The source-count statement and source-increment statement can be configured at the [edit protocols igmp interface interface-name static group multicast-group-address source ip-address] and [edit logical-systems logical-system-name protocols igmp interface interface-name static group multicast-group-address source ip-address] hierarchy levels.

  Similar configuration is available for IPv6 multicast traffic using the MLD protocol.

  [Multicast Protocols]

• Disabling PIM for IPv6 family—Enables you to globally disable PIM for IPv6 exclusive of IPv4. Previously, you could only disable PIM for IPv4 and IPv6 simultaneously. This feature also lets you disable PIM on a particular IPv4 or IPv6 interface. Routing instances and logical interfaces are also supported.

  To globally disable PIM for IPv4 or IPv6, include the family family-name (disable) statement at the [edit protocols pim] hierarchy level. To disable PIM for a particular interface, include the family family-name (disable) statement at the [edit protocols pim interface interface-name] hierarchy level.

  [Multicast Protocols]

Network Management

• SNMP support for the TX Matrix Plus router—To extend SNMP support to the newly-introduced TX Matrix Plus router, the integer values for JnxChassisId have been extended up to 28 from the previous maximum of 11. The updated textual convention for JnxChassisId is as follows:

  unknown (1)

  singleChassis (2),

  scc (3),

  lcc0 (4),

  lcc1 (5),

  lcc2 (6),

  lcc3 (7),

  jcs1 (8),

  jcs2 (9),

  jcs3 (10),

  jcs4 (11),

  node0 (12),

  node1 (13),

  sfc0 (14),

  sfc1 (15),

  sfc2 (16),

  sfc3 (17),

  sfc4 (18),

  lcc4 (19),

  lcc5 (20),

  lcc6 (21),

  lcc7 (22),

  lcc8 (23),

  lcc9 (24),

  lcc10 (25),

  lcc11 (26),

  lcc12 (27),

  lcc13 (28),

  lcc14 (29),

  lcc15 (30)

  [Network Management]

• SNMP support for Common Language Equipment Identifier (CLEI) code—A new MIB object jnxContentsChassisCleiCode has been added to the Juniper Networks enterprise-specific Chassis MIB to store the CLEI code, also known as the hardware barcode, of the chassis.

  A CLEI code is an intelligent code that consists of 10 alphanumeric characters with 4 data elements. The first data element is considered the basic code with the first two characters indicating the technology or equipment type, and the third and fourth characters denoting the functional subcategory. The second data element represents the features, and its three characters denote functional capabilities or changes. The third data element has one character and denotes a reference to a manufacturer, system ID, specification, or drawing. The fourth data element consists of two characters and contains complementary data. These two characters provide a means of differentiating or providing uniqueness between the eight character CLEI codes by identifying the manufacturing vintage of the product. For more information about CLEI code, see http://www.commonlanguage.com/resources/commonlang/productshowroom/showroom/equip_id/
  carriers/overview.html.

  [Network Management]

• Enhancements to Juniper Networks enterprise-specific MPLS MIB—The following objects of the enterprise-specific MPLS MIB (jnx-mpls.mib) have been modified to support and store information about manual bypass tunnels through the entire life cycle of a bypass tunnel.

  Both mplsLspState and mplsLspInfoState objects now have two additional values: notInService (integer value: 4) and backupActive (5). The notInService state indicates that the LSP has been torn down or never been signaled due to the lack of demand for its protection. The backupActive state indicates that the LSP is up and carrying user traffic for at least one protected LSP due to the failure of the LSP, which has caused the creation of a backup LSP.

  Similarly, the mplsPathType and mplsPathInfoType objects now have a new value, bypass (5), to denote that the path is a manually configured bypass tunnel.

  In the previous releases, the information about bypass tunnels was stored in the standard mplsTunnelTable that uses a combination of mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId as index. Because the value for mplsTunnelInstance changes when an LSP is signaled or resignaled, new entries are created each time an LSP is signaled or resignaled. This has been causing problems in tracking the state of bypass tunnels. The latest enhancements to the enterprise-specific MIB, which uses LSP name as index, enable the MIB to store information about bypass tunnels in a single entry and users to access information about bypass tunnels through its life cycle using a single index.

  The show mpls lsp bypass command returns information about manually configured bypass tunnels of all states.

  However, you are advised to:

  • Set the max-bypasses value for RSVP interfaces to zero to disable creation of dynamic bypass tunnels.
  • Assign unique names to the LSPs and bypass tunnels.

  [Network Management]

Platform and Infrastructure

• Routing Engine boot sequence for the TX Matrix Plus router and T1600 routers in a routing matrix—The Routing Engines on the TX Matrix Plus router (or switch-fabric chassis) and T1600 routers (or line-card chassis) in the routing matrix boot from the storage media in this order: the USB device (if present), the CompactFlash card (if present), the disk (if present) in slot 1, and then the LAN.

  [TX Matrix Plus Hardware, Software Installation and Upgrade Guide, System Basics, System Basics and Services Command Reference]

• New TX Matrix Plus Router—The TX Matrix Plus router is the centralized switch fabric of the routing matrix, which is a multi-terabit routing system for interconnecting T1600 routers. Each T1600 router connected to the TX Matrix Plus router adds 1.6 terabits per second (Tbps) of non-blocking subscriber switching capacity to the routing matrix. Currently, the TX Matrix Plus supports connections to up to four T1600 routers.

  Note: TX Matrix Plus routers and T1600 routers that are configured as part of a routing matrix do not currently support nonstop active routing.

Routing Policy and Firewall Filters

• Policer support for physical interfaces—Enables you to define a policer for a physical interface and reference the policer in one or more firewall filters, which can then be applied to the physical interface. This feature enables you to configure a single aggregate policer for a physical interface that can be applied to all the logical interfaces and traffic families configured on the physical interface. Previously, you could define aggregate policers only for logical interfaces. A physical interface policer also enables you to apply a single policer to multiple routing instances because a physical interface policer includes all the logical interfaces configured on the physical interface even if they belong to different routing instances.

  To configure a policer for a physical interface, include the physical-interface-policer statement at the [edit firewall policer policer-name] hierarchy level. To configure a firewall filter that references the physical interface policer, include the physical-interface-filter statement at the [edit firewall family family-name filter filter-name] hierarchy level. You must also apply the physical interface policer as an action for the firewall filter term. Include the policer policer-name statement at the [edit firewall family family-name filter filter-name term term-name then] hierarchy level. For policer-name, specify the name of a physical interface policer configured at the [edit firewall policer] hierarchy level. You can apply a firewall filter that references a physical interface policer as an input or output filter to any family on an interface. To apply a firewall filter as a input filter, include the input filter-name statement at the [edit interfaces interface-name unit unit-number family family-name filter] hierarchy level. To apply a firewall filter as an output filter, include the output filter-name statement at the [edit interfaces interface-name unit unit-number family family-name filter] hierarchy level.

  The following example shows how to configure a physical interface policer and reference it in a firewall filter:

  [edit firewall]

  firewall {

  policer shared-police1 {

  physical-interface-policer;

  if-exceeding {

  bandwidth-limit 100m;

  burst-size-limit 500k;

  }

  then {

  discard;

  }

  }

  policer share-police2 {

  physical-interface-policer;

  if-exceeding {

  bandwidth-percent 5;

  burst-size-limit 250k;

  }

  then {

  discard;

  }

  }

  famiy inet {

  filter inet-filter {

  physical-interface-filter;

  term tcp-police-1 {

  from {

  precedence [ critical-ecp immediate-priority ] ;

  protocol tcp;

  }

  then policer shared-police1;

  }

  term tcp-police-2 {

  from {

  precedence [ internet-control routine ];

  protocol tcp;

  }

  then policer shared-police2;

  }

  }

  }

  }

  [Policy]

• Authentication for BFD (MD5/SHA1)—Enables you to apply MD5 or SHA1 authentication requirements to BFD sessions on BGP, IPv4 static routes, IPv6 static routes, IS-IS, OSPFv2, PIM, and RIP protocols. Previously, BFD authentication was accomplished using a plain-text password. This feature also supports authentication key rollover for these protocols, which enables you to update authentication keys without causing associated neighboring sessions to reset. Authentication must be configured on both ends of the session. Additionally, you can configure loose authentication checking during a migration period from a nonauthenticated session to an authenticated session.

  To enable MD5 or SHA1 authentication for BFD on an IPv4 or IPv6 static route, include the authentication algorithm algorithm-name statement and the authentication key-chain keychain-name statement at the [edit routing-options static route address bfd-liveness-detection] hierarchy level. You must also include the authentication-key-chains key-chain keychain-name statement at the [edit security] hierarchy level.

  To enable MD5 or SHA1 authentication for BFD on BGP or RIP, include the authentication algorithm algorithm-name statement and the authentication key-chain keychain-name statement at the [edit protocols protocol-name group group-name bfd-liveness-detection] or [edit protocols protocol-name group group-name neighbor address bfd-liveness-detection] hierarchy level. You must also include the authentication-key-chains key-chain keychain-name statement at the [edit security] hierarchy level.

  To enable MD5 or SHA1 authentication for BFD on IS-IS, OSPFv2, or PIM, include the authentication algorithm algorithm-name statement and the authentication key-chain keychain-name statement at the [edit protocols protocol-name interface interface-name bfd-liveness-detection] hierarchy level. You must also include the authentication-key-chains key-chain keychain-name statement at the [edit security] hierarchy level.

  To enable graceful migration of nonauthenticated to authenticated sessions, include the authentication loose-check statement at the appropriate protocol hierarchy level.

  You can configure this feature for all routing instances supported by BGP, IS-IS, OSPF, and RIP. Logical systems are also supported.

  The show bfd session detail and show bfd session extensive commands have been enhanced to display authentication information when configured.

  [Routing Protocols, System Basics, Multicast Protocols, Routing Protocols and Policies Command Reference]

• Option to repartition jtree memory (M10i and M7i routers [with Enhanced CFEB], M320 router [with Enhanced III FPC1, Enhanced III FPC2, and Enhanced III FPC3], MX Series, and M120 Series routers)—The jtree memory on I-CHIP-based Packet Forwarding Engines has two segments. One segment stores routing tables and related information. The other stores firewall-filter-related information. The new configuration statement route-memory-enhanced enables you to repartition the two jtree memory segments to allocate more memory for routing tables over firewall filters. This option is useful when you want to support larger routing tables. However, we recommend enabling this option only if you do not have a very large firewall filter configuration. To repartition more memory for routing tables, include the route-memory-enhanced statement at the [edit chassis] hierarchy level.

  [System Basics]

• Port mirroring for Layer 2 VPN (M120 and M320 routers)—Enables port mirroring for Layer 2 VPNs on M120 and M320 routers, including firewall filtering capabilities. Previously, port mirroring was only supported for IPv4, IPv6, and VPLS traffic. This feature also enables you to set the maximum length of the mirrored packet.

  To configure port mirroring for a Layer 2 VPN on an M120 or M320 router, include the family ccc statement at the [edit forwarding-options port-mirroring] hierarchy level. To configure port mirroring for a particular instance of a Layer 2 VPN, include the family ccc statement at the [edit forwarding-options port-mirroring instance instance-name] hierarchy level. Optionally, configure the maximum mirrored packet length using the maximum-packet-length statement at the [edit forwarding-options port-mirroring input] hierarchy level.

  To configure a firewall filter for a Layer 2 VPN on an M120 or M320 router, include the family ccc filter filter-name term term-name from match-conditions then action statement at the [edit firewall] hierarchy level. You can apply the filter to a logical interface at the input or output. The filter can also be applied to aggregated Ethernet logical interfaces.

  [Policy Framework, Network Interfaces]

Routing Protocols

• Egress filtering PIMv4/v6 join messages—You can filter PIM sparse mode (PIM-SM ) join and prune messages at the egress interfaces for IPv4 and IPv6 in the upstream direction. The messages can be filtered based on the group address, source address, outgoing interface, PIM neighbor, or combination of these values.

  This can be useful when the core of your network is using a mix of IP and MPLS. You can use this feature to selectively forward or filter PIM join and prune messages to PIM neighbors.

  To filter PIM sparse mode join and prune messages at the egress interfaces, create a policy rejecting the group address, source address, outgoing interface, or PIM neighbor, then apply the policy.

  To apply the policy, include the export statement at the [edit protocols pim], [edit routing-instances routing-instance-name protocols pim], [edit logical-routers logical-router-name protocols pim], or [edit logical-routers logical-router-name routing-instances routing-instance-name protocols pim] hierarchy level.

  You can display the number of messages that have been filtered using the show pim statistics command.

  The PIM egress filter prevents PIM join and prune messages from being sent towards the upstream routers in PIM-SM and PIM source-specific multicast (PIM-SSM) protocol mode. This filter is not supported for PIM dense mode (PIM-DM).

  [Multicast Protocols Configuration Guide, Routing Protocols and Policies Command Reference]

• Reduction in flooding of self-orginated OSPF LSAs—Enables you to override the default behavior of having OSPF flood self-originated link-state advertisements (LSAs) every 30 minutes. When this feature is enabled, the JUNOS Software floods self-originated LSAs with the DoNotAge bit set. As a result, LSAs are not reflooded unless a change occurs in the LSA. This feature reduces OSPF traffic overhead in stable topologies and facilitates the scaling of OSPF networks. You can enable flood reduction for OSPF interfaces, realms, virtual links, sham links, and peer interfaces. Additionally, you can configure this feature for all routing instances supported by OSPF. Logical systems are also supported.

  To enable flood reduction for OSPF interfaces, include the flood-reduction statement at the [edit protocols (ospf | ospf3) area ared-id interface interface-name] hierarchy level. To enable flood reduction for an OSPF realm, include the flood-reduction statement at the [edit protocols ospf3 realm (ipv4-multicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name] hierarchy level. To enable flood reduction for a virtual link, include the flood-reduction statement at the [edit protocols (ospf | ospf3) area area-id virtual-link neighbor-id router-id transit transit-area] hierarchy level. To enable flood reduction for a peer interface, include the flood-reduction statement at the [edit protocols ospf area area-id peer-interface interface-name] hierarchy level. To enable flood reduction for the remote endpoint of a sham link, include the flood-reduction statement at the [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote address] hierarchy level. The show (ospf | opsf3) interface extensive command has been enhanced to display which interfaces are enabled for flood reduction.

  [Routing Protocols, Routing Protocols and Policies Command Reference]

Services Applications

• Border Gateway Function (BGF) RTCP sender and receiver reports (M120, M320, and T640 routers)—Enables a BGF to send statistics for the RTCP sender and receiver reports to the gateway controller when the BGF receives an AUDIT or SUBTRACT request for a given gate.

  To configure RTCP sender and receiver reports, include the rtcp statement at the [edit services pgcp gateway gateway-name monitor media] hierarchy level.

  The show services pgcp gateway gateway-name gate-id gate-id statistics command now displays additional RTCP statistics: fraction lost, cumulative number of packets lost, and interarrival jitter.

  [Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]

• Integrated Multi-Service Gateway (IMSG) provides firewall and security services to SIP signaling traffic (M Series and MX Series routers)—The IMSG provides firewall and security services to SIP signaling traffic before the traffic reaches the border signaling gateway (BSG). This feature uses a simple provisioning model where all the BSG protection elements are collected in a service set that is applied on a services interface subunit. After the service set processes the traffic, it is sent to the BSG. To configure, create a service set with the set of stateful firewall and IDP services that you wish to provide. You then apply the service set as an input service set and output service set on the interface at the [edit interfaces interface-name unit logical-unit-number family inet service (input | output)] hierarchy level.

  [Multiplay Solutions, Services Interfaces]

• Integrated Multi-Service Gateway (IMSG) support for manipulating SIP headers (M120, M320, and T640 routers)—You can now add, remove, or change the value of headers in incoming SIP messages. This feature provides greater interoperability by modifying SIP messages so that they can pass between different peers and vendors. To configure, create a message manipulation rule at the [edit services border-signaling-gateway gateway gateway-name sip message-manipulation-rules] hierarchy level. You then create actions in new transaction policies that specify the message manipulation rules that are applied to either incoming or outgoing messages. Configure these actions at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then message-manipulation] hierarchy level. To display the message manipulation rules that are in effect for a contact or request URI, use the detail level of the show services border-signaling-gateway by-contact or show services border-signaling-gateway by-request-uri operational mode commands.

  [Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]

• ping mpls command enhancements—Enable you to specify the packet size for LSP ping messages transmitted when MPLS-based services are deployed. LSP ping enables providers of these services to diagnose network problems. Previously, the packet size could not be user-defined. This feature enables configuration of the LSP ping packet size for Layer 2 circuits, Layer 2 VPNs, Layer 3 VPNs, LDP, LSP endpoints, and RSVP services. Using this feature you can determine the size of the MTU for LSP ping messages either manually or automatically. This information aids in troubleshooting misconfigured MTUs for an LSP that may cause errors on the network.

  To specify the LSP ping packet size for LDP, RSVP, Layer 3 VPN, and LSP, execute the ping mpls service-name size command. To enable automated MTU size determination for these services, execute the ping mpls service-name sweep command. To specify the LSP ping packet size for Layer 2 circuits at the interface or virtual circuit level, execute the ping mpls l2circuit (interface | virtual-circuit) size command. To enable automated MTU size determination for this service, execute the ping mpls l2circuit (interface | virtual-circuit) sweep command. To specify the LSP ping packet size for Layer 2 VPNs at the interface or instance level, execute the ping mpls l2circuit (interface | instance) size command. To enable automated MTU size determination for this service, execute the ping mpls l2circuit (interface | instance) sweep command.

  [System Basics and Services Command Reference]

• Dynamic application awareness functionality extended to M320 routers—Adds support for Intrusion Detection and Prevention (IDP) and application identification (APPID) functionality on M320 routers equipped with MultiServices (MS100 and MS400) PICs. The feature set is the same as documented for MX Series MultiServices DPCs; there are no new CLI statements or commands. The fast update filter (FUF) feature is not supported on M320 routers in this release.

  [J Series Services Router Guides, Services Interfaces]

• Border gateway function (BGF) usability and H.248 compliance (M120, M320, and T640 routers)—This release provides the following usability and H.248 compliance improvements:
  • Publish supported packages—A virtual BGF can now publish a list of its supported packages, including their version.
  • Always return valid SDP in replies—SDPs returned by the virtual BGF are fully valid. The BGF does not allow omission of any mandatory fields.
  • Enforce the negotiated H.248 version—The virtual BGF now confirms for messages it sends that the version of the message header matches the negotiated version and that the content of the message is valid in the negotiated version. However, the BGF does accept messages whose content does not match the version of the header.
  • Enforce range (minimum and maximum values) for CLI parameters—In addition to the default value configured to H.248 parameters, the operator can configure the minimum and maximum values supported for specific parameters. The range of parameter values has predefined minimum and maximum values according to the BGF functionality, but the operator can use the CLI to narrow the range. The corresponding parameters received via the H.248 interface should be in the range configured in CLI. If not, an H.248 error code #449: "Unsupported or Unknown Parameter or Property Value" should be issued.
  • Prevent TCP SendOnly and RecvOnly—The stream modes SendOnly and RecvOnly are meaningless for TCP (TCP ACKs must always flow). When an attempt is made to create a TCP stream with SendOnly or RecvOnly, the BGF now returns error #473: "Conflicting property values."
  • Support encoding of H.248 messages in lowercase—By default H.248 messages are encoded in uppercase which can be changed to lowercase using the following command: edit service pgcp gateway gw h248-options encoding use-lower-case.
  • Exclude media data inactivity for RTCP streams—By default, media inactivity is detected for both RTP and RTCP streams. An RTCP stream can be excluded using the following command: edit service pgcp gateway gw data-inactivity-detection no-rtcp-check.

  [Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]

• Port mirroring with next-hop groups enhancement—Adds support for port mirroring functionality using next-hop groups without Tunnel PICs on MX Series routers. Previously, port mirroring using next-hop groups, also known as multipacket port mirroring, was supported on MX Series routers, but required installation of a Tunnel PIC.

  To configure the new functionality, include the next-hop-group statement at the [edit forwarding-options port-mirror family inet output] or [edit forwarding-options port-mirror instance instance-name family inet output] hierarchy level. You can disable this configuration by including a disable or disable-all-instances statement at the [edit forwarding-options port-mirror] hierarchy level or by including a disable statement at the [edit forwarding-options port-mirror instance instance-name] hierarchy level. You can display the settings and network status by issuing the show forwarding-options next-hop-group and show forwarding-options port-mirroring operational commands. [Services Interfaces, System Basics and Services Command Reference]

• Active flow monitoring sampling enhancements—Add support for packet sampling on a per Packet Forwarding Engine basis. You can now configure active sampling by defining a sampling instance that specifies a name for the sampling parameters and binding the instance name to a particular Packet Forwarding Engine. To specify the sampling parameters, include the instance statement at the [edit forwarding-options sampling] hierarchy level. To bind an instance to a Packet Forwarding Engine, include the sampling-instances statement at the [edit chassis fpc number] hierarchy level. You can also set global input parameters by including the rate and run-length statements at the [edit forwarding-options sampling input] hierarchy level. In a related development, a proprietary v5 extension template is now available for supporting 4-byte AS information in flow records. To configure this extension, include the version 5 statement at the [edit forwarding-options sampling output flow-server server-name] hierarchy level. [Services Interfaces]
• Support for MultiServices PICs (JCS1200 platform)—MultiServices 400 PICs and IPSec are supported in this release.

  [PSD Configuration Guide]

• Border Gateway Function (BGF) support for pgcpd process running on MS-PIC or MS-DPC (M120, M320, and T640 routers)—The pgcpd process for the BGF can now run on either the Routing Engine or on an MS-PIC or MS-DPC. You can configure up to eight virtual BGFs on the PIC or DPC. You must enable the BGF service package on the PIC or DPC by including the set fpc slot pic slot adaptive-services service-package extension-provider package jservices-bgf-pic statement at the [edit chassis] hierarchy level. To specify whether the virtual BGF runs on the PIC or DPC or on the Routing Engine, include the platform statement at the [edit services pgcp gateway gateway-name] hierarchy level. All show services pgcp operational mode commands now allow you to display either a backup or master PIC or DPC for a virtual BGF.

  [Multiplay Solutions, System Basics and Services Command Reference]

• Border Gateway Function (BGF) support for high availability for PICs running the pgcpd process (M Series and T Series routers with MS-PICs and MX Series routers with MS-DPCs)—The BGF provides a 1:1 redundancy model for PICs and DPCs that are running the pgcpd process. There is one primary service PIC and one secondary service PIC that acts as a backup. If the primary service PIC fails, the secondary PIC becomes active and H.248 traffic is switched over to the new active PIC. When the failed PIC recovers, it comes up as the secondary PIC. The BGF supports hot standby mode to ensure that failover occurs in 5 seconds or less.

  To configure, create a container interface called an rms interface at the [edit interfaces] hierarchy level. On the rms interface, configure the primary and secondary PICs or DPCs. When you configure your virtual BGF, specify the rms interface as the platform device on which the virtual BGF runs by including the platform statement at the [edit services pgcp gateway gateway-name] hierarchy level.

  All show services pgcp operational mode commands now allow you to display information about either the backup or the master PIC or DPC for a virtual BGF.

  [Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]

• Border Gateway Function (BGF) RTCP bandwidth policing (M120, M320, and T640 routers)—Enables a gateway controller to control RTCP bandwidth using two RTCP bandwidth modifiers in the H.248 stream. The “RR“ modifier specifies the SDR (sustained data rate) bandwidth for active receivers, while the “RS” modifier specifies the SDR bandwidth for active senders. When the H.248 stream does not contain the RTCP bandwidth modifiers, the bandwidth specified by the CLI configuration is used.

  You can now specify whether to include RTCP bandwidth in the traffic management SDR for all streams. To include RTCP bandwidth, include the rtcp-include statement at the [edit services pgcp gateway gw-name h248-properties traffic-management sustained-data-rate] hierarchy level.

  [Multiplay Solutions, Services Interfaces]

• Fast update filters for dynamic profiles (MX Series routers)—Fast update filters are now supported for dynamic profiles.

  Fast update filters are a unique type of firewall filter that enable you to incrementally add, remove, or update the filter terms. Dynamically assigned fast update filters provide significant advantages over static filters. Networks can have multiple subscribers who might be mapped to a single logical interface. Because static filters are compiled at commit time, they cannot contain subscriber-specific terms, and therefore cannot distinguish between different subscribers.

  Using fast update filters involves two procedures. The two procedures are the same as the existing procedures used for normal filters. You first configure the filter, and you then use a dynamic profile to apply the filter to an interface family.

  • To configure fast update filters, include the fast-update-filter statement at the [edit dynamic-profiles profile-name firewall family inet] hierarchy level. When used with dynamic profiles, fast update filters are interface-specific and the order of the match field is explicit. You must include the interface-specific statement and the match-order statement when you configure a fast update filter.
  • To apply a fast update filter to an interface family, include the filter statement at the [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number family inet] hierarchy level.

  When a dynamic profile instantiates a session, the router verifies if the applied fast update filter is present on the session’s interface. The router matches filters by name.

  • If a filter with the same name is not present, the router adds all terms of the new filter.
  • If a filter with the same name is present, the router adds only new or modified terms to the filter.

  Note: All terms that you add to an existing filter must be unique. You can ensure the required uniqueness by using the $junos-subscriber-ip-address variable as either the source-address (input filter) or destination-address (output filter) in the from statement at the [edit dynamic-profiles profile-name firewall family inet fast-update-filter term] hierarchy level.

  Use the show firewall and show firewall filter operational commands to view information for fast update filters.

  [Subscriber Access, Policy Framework]

• New option for the show snmp mib command—The show snmp mib command now has a new option ascii that converts the string indices to an “ascii-key” representation, thus making the output more readable. This is in addition to the default option of the decimal format. The syntax for the command is show snmp mib (get | get-next | walk) (ascii | decimal) object-id.

  [System Basics and Services Command Reference]

• Integrated Multi-Service Gateway (IMSG) support for the following features (M120, M320, MX Series, and T640 routers):

  • NAT pool selection—You can now assign different NAT pools for different networks (or peers) and for different network subnets. You do so by assigning a virtual interface to the ingress and egress service points. The virtual interface specifies the NAT pool to be used on the service point. To configure, include the default-media-realm statement at the [edit services border-signaling-gateway gateway gateway-name service-point service-point-name] hierarchy level. The value of the default-media-realm is a virtual interface that you configured at the [edit services pgcp] hierarchy level.
  • Media inactivity detection—The border signaling gateway (BSG) now supports media inactivity detection. To configure, include the data-inactivity-detection statement at the [edit services border-signaling-gateway gateway gateway-name sip new-call-usage-policy policy-name term term-name then media-policy] hierarchy level. To discontinue media inactivity detection while a call is on hold, include the stop-detection-on-drop statement at the [edit services pgcp gateway gateway-name data-inactivity-detection] hierarchy level.
  • Media anchoring—You can now explicitly turn media anchoring on or off. Media anchoring is on by default. To turn media anchoring on or off, use the no-anchoring statement at the [edit services border-signaling-gateway gateway gateway-name sip new-call-usage-policy v term term-name then media-policy] hierarchy level.
  • DSCP—The DSCP value in the embedded SPDF is changed to a 6-bit value instead of an 8-bit value. If you do not specify a DSCP value, the default value is do-not-change. Setting the DSCP to a hexadecimal value is no longer supported. To configure DSCP values, include the dscp statement at the [edit services border-signaling-gateway gateway gateway-name embedded-spdf service-class service-class-name term term-name then] hierarchy level.
  [Multiplay Solutions, Services Interfaces]
• New statement for controlling session offload behavior (MX Series routers)—The new session-offload statement at the [edit chassis fpc slot-number pic number adaptive-services service-package extension-provider] hierarchy level controls session offload behavior for MS-DPCs on MX Series routers. It controls session offload on a per-device basis, where a device is a MultiServices interface (ms-fpc-pic-port). In JUNOS Release 9.6, the session offload function is supported for at most one MultiServices interface. When the offload function is enabled, it is strongly recommended that you limit Dynamic Application Awareness features to that MultiServices interface. The default is to not offload any sessions.

  [System Basics]

Subscriber Access Management

• JUNOS subscriber access scaling values—The following subscriber access scaling values are supported in this release:

  • Number of subscriber VLANs per DPC: 16,000
  • Number of subscriber VLANs per chassis for the MX240 router, which accommodates 2 DPCs: 32,000
  • Number of subscriber VLANs per chassis for the MX480 and the MX960 routers: 64,000
  • Number of DHCP bindings: 120,000
• Diameter base protocol support for Authentication, Authorization, and Accounting (AAA) (MX Series routers)—The Diameter protocol is defined in RFC 3588, Diameter Base Protocol, and provides an alternative to RADIUS that is more flexible and extensible. The Diameter base protocol provides basic services to one or more applications (also called functions) that each runs in a different Diameter instance. The individual application provides the extended AAA functionality. JSRC is the first application that is supported.

  Diameter peers communicate over a TCP transport layer connection by exchanging Diameter messages that convey status, requests, and acknowledgments by means of standard Diameter AVPs and application-specific AVPs. The Diameter transport layer configuration is based on Diameter network elements (DNEs); multiple DNEs per Diameter instance are supported. Currently only the predefined master Diameter instance is supported, but you can configure alternative values for many of the master Diameter instance values.

  Each DNE consists of a prioritized list of peers and a set of routes that define how traffic is forwarded. Each route associates a destination with a function, a function partition, and a metric. When an application sends a message to a routed destination, all routes within the Diameter instance are examined for a match. When the best route to the destination has been selected, the message is forwarded by means of the DNE that includes that route.

  To configure a Diameter network element, include the network-element statement at the [edit diameter] hierarchy level. Include the route statement at the [edit diameter network-element element-name forwarding] hierarchy level. To configure a route for the DNE, include the destination (optional), function (optional), and metric statements at the [edit diameter network-element element-name forwarding route dne-route-name] hierarchy level. Specify the Diameter peers associated with the DNE by including one or more peer statements at the [edit diameter network-element element-name] hierarchy level. Set the priority for each peer with the priority statement at the [edit diameter network-element element-name peer peer-name] hierarchy level.

  Diameter requires you to configure information about the origin node; this is the endpoint node that originates Diameter for the Diameter instance. Include the host and realm statements at the [edit diameter] hierarchy level to configure the Diameter origin.

  Each Diameter peer is specified by a name. Peer attributes include address and the destination TCP port used by active connections to this peer. To configure a Diameter peer, include the peer statement at the [edit diameter] hierarchy level. Include the address and connect-actively statements at the [edit diameter peer peer-name] hierarchy level. To configure the active connection, include the port statement at the [edit diameter peer peer-name connect-actively] hierarchy level.

  [Subscriber Access]

• Support for dynamic 802.1Q VLAN configuration over aggregated Ethernet interfaces—You can now configure dynamic 802.1Q VLANs over aggregated Ethernet interfaces.

  [Subscriber Access]

• DHCPv6 local server (MX Series routers)—Enables the router to function as a server for the DHCP protocol for IP version 6 (IPv6). The DHCPv6 local server sends and receives packets using the IPv6 protocol and informs IPv6 of the routing requirements of the router clients. The local server works together with the AAA service framework to control subscriber access and accounting. For this release, DHCPv6 local server uses RADIUS to supply the IPv6 prefix and client configuration parameters. As a prerequisite for using the DHCPv6 local server with RADIUS, you must configure DHCPv6 authentication.

  The DHCPv6 local server supports the following RADIUS attributes and vendor-specific attributes (VSAs):

  • Session-Timeout (attribute 27)
  • NAS-IPv6-Address (attribute 95)
  • Framed-Interface-Id (attribute 96)
  • Framed-IPv6-Prefix (attribute 97)
  • Login-IPv6-Host (attribute 98)
  • Framed-IPv6-Pool (attribute 100)
  • Delegated-IPv6-Prefix (attribute 123)
  • Maximum-Clients-Per-Interface (VSA 26-143)

  To configure a DHCPv6 local server, use the dhcpv6 statement at the [edit system services dhcp-local-server] hierarchy level. You can configure DHCPv6 globally or for a named group of interfaces.

  The dhcpv6 authentication username-include statement, which specifies the username that is passed to AAA, supports the following new parameters, in addition to the parameters supported by the IPv4 DHCP local server:

  • relay-agent-remote-id—The DHCPv6 Relay Agent Remote-ID option (option 37) from the client PDU name.
  • relay-agent-subscriber-id—The DHCPv6 Relay Agent Subscriber-ID option (option 38) from the client PDU name.

  To view DHCPv6 configuration and information, use the show dhcp server bindings command.

  DHCPv6 local server is compatible with the extended DHCP local server and DHCP relay. DHCPv6 local server does not support dynamic profiles in this release.

  [Subscriber Access]

• Support for DHCP Layer 3 wholesale configuration in a subscriber access network—Enables you to configure DHCP 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 and routing instances. Logical systems enable you to divide the 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. 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.

  Note: In this release, DHCP Layer 3 wholesaling supports the use of only the default logical system using multiple routing instances.

  When configuring DHCP Layer 3 wholesale for a subscriber access network, keep the following in mind:

  • Routing instances must use the same DHCP configuration: DHCP Local Server or DHCP Relay.
  • The configuration must include at least a single address pool with a single range of addresses. However, the configuration can include multiple address pools as long as each address pool uses non-overlapping address ranges.
  • You cannot configure the use-primary statement within a DCHP Layer 3 wholesale configuration. Configuring the use-primary statement on an underlying logical interface results in no routing instance reassignment when a client requiring redirection to a retail routing instance logs in. The client is subsequently logged out.
  • Each routing instance must contain a loopback with one or more addresses to be used for the unnumbered interface. The loopback must also have an address within the subnetwork of each possible client IP address.

  To configure DHCP 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 interface $junos-interface-name] hierarchy level.
  • Include the interface statement along with the $junos-interface-name dynamic variable at the [edit dynamic-profiles profile-name interface “$junos-interface-name” routing-instances “$junos-routing-instance”] hierarchy level.
  • Include the unnumbered-address statement along with the $junos-loopback-interface dynamic variable along with the preferred-source-address option and the $junos-preferred-source-address dynamic variable at the [edit dynamic-profiles profile-name interfaces demux0 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.

• Enhanced PPP support (M120 and M320 routers)—IP address hinting for PPPoE is now supported. Consequently, you can use the PPPoE destination address as the assigned peer address. You specify this address by including the destination statement at the [edit interfaces interface-name family inet address address] hierarchy level.

  The no-authentication configuration for PPPoE is also now supported.

  These two feature enhancements remove the requirement that you must always have a RADIUS server for subscriber-aware services for PPP sessions.

  [Subscriber Access]

• JSRC supports subscriber sessions on static and dynamic interfaces (MX Series routers)—You can use the new JSRC application to interact with the Juniper Networks Session and Resource Control (SRC) software to support dynamic and static subscribers. The SRC software runs on a Juniper Networks C Series Controller and provides a central administrative point for managing subscribers and their services. The SRC software uses the Diameter protocol for communications between JSRC acting as the local SRC peer on an MX Series router and the remote SRC peer (the service activation engine or SAE) on a C Series Controller.

  JSRC requests address and service authorizations from the SAE, activates and deactivates services as specified by the SAE, logs out subscribers as specified by the SAE, and synchronizes subscriber state and service information with the SAE.

  JSRC is a Juniper Networks-specific Diameter application registered with the IANA as Juniper-Policy-Control-JSRC, with an ID of 16777244. JSRC and the SAE exchange Diameter protocol messages that include a variety of attribute-value pairs (AVPs) to convey state information and identify actions requested or performed. Both standard Diameter AVPs and Juniper Networks vendor-specific AVPs (ID 2636) are employed.

  JSRC configuration includes creating and assigning a JSRC partition, enabling authorization of DHCP subscribers, and enabling SRC provisioning of subscriber services.

  To create the JSRC partition, include the partition statement at the [edit jsrc] hierarchy level. To configure the partition, include the diameter-instance, destination-host, and destination-realm statements at the [edit jsrc partition partition-name] hierarchy level. To assign the JSRC partition, include the jsrc-partition statement at the [edit] hierarchy level.

  To enable SRC authorization of DHCP subscribers, include the authorization-order jsrc statement at the [edit access profile profile-name] hierarchy level.

  To enable SRC provisioning for DHCP subscribers, include the provisioning-order jsrc statement at the [edit access profile profile-name] hierarchy level.

  [Subscriber Access]

• Dynamic subscriber and service management on static interfaces (MX Series routers)—You can now associate subscribers with statically configured interfaces and provide dynamic service activation for these subscribers. When the interface comes up, it is treated as a subscriber login. When the interface goes down, it is treated as a subscriber logout.

  Static subscribers are intended to work with JSRC. After the subscribers are present in the session database (SDB), JSRC can report the subscribers to the SAE so that SRC software can subsequently manage the subscribers. Alternatively, you can configure the static subscribers to be authenticated and authorized by means of RADIUS. In this case, RADIUS can then activate and deactivate services with change of authorization (CoA) messages. However, this configuration does not prevent the interface from coming up and forwarding traffic. Further, authorization parameters are not imposed on the subscriber interface.

  Currently, only Ethernet interfaces support static subscribers. Only one static subscriber can exist over a given interface. An interface cannot appear in more than one group. Static subscribers cannot be created over dynamic interfaces.

  To enable JSRC to handle the subscribers at the direction of the SRC software, include the provisioning-order jsrc statement at the [edit access profile profile-name] hierarchy level. If the authentication request fails for a static subscriber, the request is reissued after one hour, when a nonconfigurable timer expires. This action repeats for as long as the interface is operationally up.

  You can force a logout of the static subscriber by issuing the request services static-subscribers logout interface interface-name command. A static subscriber can also be logged out by AAA or an external policy manager. In both cases, no subsequent logins can take place on the underlying interface until you reset the state by issuing the request services static-subscribers login interface interface-name command or the router or process reboots.

  When you commit configuration changes for existing interface groups, static subscribers are logged out and then back in. You can force a logout of an interface group by issuing the request services static-subscriber logout group group-name command. You can subsequently log in a group of interfaces by issuing the request services static-subscriber login group group-name command.

  No new CLI statements are required to configure the dynamic profile for static subscribers. The client profile can be very simple; it is activated at login and deactivated at logout. During a graceful Routing Engine switchover (GRES) event, active static subscribers are recovered, inactive subscribers are cleaned up, and logout continues for subscribers that were in the process of logging out.

  To configure static subscribers, include the static-subscribers statement at the [edit system services] hierarchy level. To configure tracing operations for static subscribers, include the traceoptions statement at the [edit system services static-subscribers] hierarchy level. You can configure the access profile, dynamic profile, and authentication parameters for all groups or for a particular group.

  To configure the access profile that triggers AAA services for the static subscriber for all subscribers, include the access-profile statement at the [edit system services static-subscribers] hierarchy level. Alternatively, include the statement at the [edit system services static-subscribers group group-name] hierarchy level to apply the profile to a specific group and override a top-level configuration.

  To configure the dynamic profile that is instantiated when the static subscriber logs in for all subscribers, include the dynamic-profile statement at the [edit system services static-subscribers] hierarchy level. Alternatively, include the statement at the [edit system services static-subscribers group group-name] hierarchy level to apply the profile to a specific group and override a top-level configuration. Do not specify a dynamic profile that creates a dynamic interface.

  To configure the authentication parameters that trigger an Access-Request message to AAA for all subscribers, include the authentication statement at the [edit system services static-subscribers] hierarchy level. Alternatively, include the statement at the [edit system services static-subscribers group group-name] hierarchy level to configure authentication for a specific group and override a top-level configuration. If you do not configure authentication, then by default the interface name is modified and used as the default username for the client session and the authentication request.

  The configurable authentication parameters include the password and details of how the username is formed. To configure the authentication password for all subscribers, include the password statement at the [edit system services static-subscribers authentication] hierarchy level. Alternatively, include the statement at the [edit system services static-subscribers group group-name authentication] hierarchy level to configure authentication for a specific group and override a top-level configuration.

  The username that is sent to AAA for authentication must include at least one of the following attributes: the domain name, a user prefix, the interface name, a logical system name, or a routing instance name. To configure how the username is formed for all subscribers, include the desired statements at the [edit system services static-subscribers authentication] hierarchy level: domain-name, user-prefix, logical-system-name, or routing-instance-name. Alternatively, include the desired statements at the [edit system services static-subscribers group group-name authentication] hierarchy level to configure the username for a specific group and override a top-level configuration.

  Finally, a group configuration must specify all the interfaces that you expect to support static subscribers. You must also statically configure these interfaces before any static subscribers can be supported on them. To specify the interfaces, include the interface statement at the [edit system services static-subscribers group group-name] hierarchy level. This statement enables you to specify a single interface or a range of interfaces.

  To display information about the state of static subscribers, you can issue any of the following commands:

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

  The following new system log messages are supported:

  • JSSCD_AUTH_CONNECTION_FAILURE
  • JSSCD_DAX_REGISTER_FAILURE
  • JSSCD_DYN_PROFILE_FAILURE
  • JSSCD_INIT
  • JSSCD_RTSOCK_OPEN_FAILURE
  • JSSCD_RTSOCK_REGISTER_FAILURE
  • JSSCD_SDB_OPEN_FAILED
  • JSSCD_TRACE

  [Subscriber Access]

• Using the textual interface description in DHCP relay option 82 Agent Circuit ID suboption (MX Series routers)—DHCP relay agent option 82 support enables you to include the textual interface description in the Agent Circuit ID suboption for static interfaces. By default, when DHCP option 82 is inserted into client packets, the Agent Circuit ID suboption includes the interface identifier. You can now optionally specify that the Agent Circuit ID suboption include the textual description that is configured for the interface instead of the interface identifier. Using the textual description can provide a more descriptive and flexible identification as compared to the standard circuit identifier that contains router interface information.

  To specify that the Agent Circuit ID suboption use the textual interface description, configure the use-interface-description statement at the [edit forwarding-options dhcp-relay relay-option-82 circuit-id] hierarchy level. You can specify that the Agent Circuit ID use the textual description for either the logical interface or the device interface.

  [Subscriber Access]

User Interface and Configuration

• CLI changes for the TX Matrix Plus router—JUNOS Software support for the TX Matrix Plus router introduces some new CLI options. The sfc option introduced in the operational mode commands and configuration statements represents the TX Matrix Plus router (or switch-fabric chassis). The lcc option is now also supported for T1600 routers (or line-card chassis) in a routing matrix.

  In addition, the all-chassis and all-lcc options are now also supported for some commands on the TX Matrix Plus router.

  The all-sfc option is introduced in JUNOS Release 9.6. However, it is reserved for future configurations that can support more than one TX Matrix Plus router (or switch-fabric chassis) in a routing matrix. Currently, only one TX Matrix Plus router is supported in a routing matrix.

  The lcc number and sfc options have been added to the request system software add, request routing-engine login, and file copy and file rename commands to support installation of a software package or bundle on a TX Matrix Plus router or any of the T1600 routers in the routing matrix. The sfc option is used to install the software package or bundle on a TX Matrix router. The lcc number option is used to install a software package or bundle on a T1600 router in the routing matrix.

  [TX Matrix Plus Hardware Guide, Software Installation and Upgrade Guide, System Basics and Services Command Reference]

• Remote RPC support for event scripts—Enables you to remotely execute RPCs from event scripts. To configure support for RPC execution, include the remote hostname(s) at the new hierarchy level [edit event-options event-script file filename remote-execution]. You must configure the username and passphrase statements for each of the remote hosts at the [edit event-options event-script file filename remote-execution remote-hostname] hierarchy level. The remote hostname, username, and passphrase, in addition to the event details, are passed to the event script when it is triggered by an event policy. You can configure the event script to establish a connection with the remote host by invoking the enhanced jcs:open() function, which now accepts a username and passphrase for a remote device. You can then execute the RPCs from within the event script with the jcs:execute() extension function.

  [Configuration and Diagnostic Automation Guide]

• New login script feature—Enables you to configure the router to automatically execute an op script when a user in a designated user class logs in to the CLI. To associate an op script with a given class, include the login-script statement and specify the filename of the op script at the [edit system login class class-name] hierarchy level. The configured op script is executed when any user that has the configured class class-name logs in to the CLI, provided that the script has been enabled.

  [Configuration and Diagnostic Automation Guide]

VPNs

• GRE tunnels for Layer 3 VPNs—You can now configure a GRE tunnel from a PE router to a remote CE router in a Layer 3 VPN. Previously, you could only configure a GRE tunnel from a PE router to a P router or from a PE router to a local CE router. Configure the source statement, the destination statement, and the routing-instance statement at the [edit interfaces gr-fpc|pic|port unit unit-number tunnel] hierarchy level to configure the GRE tunnel on the PE router. Configure the source statement and the destination statement at the [edit interfaces gr-fpc|pic|port unit unit-number tunnel] hierarchy level to configure the GRE tunnel on the remote CE router.

  [VPNs]

• Connectivity-fault management process flooding to interfaces based on mesh groups—A mesh group is a set of interfaces with similar flooding behavior, commonly used in the configuration of LDP BGP VPLS interworking. The flooding behavior configured for each mesh group is used by all the interfaces in that mesh group. The Connectivity Fault Management Protocol uses the data path semantics for packet flooding and therefore must adhere to the flooding behavior for mesh groups. The connectivity-fault management process (cfmd) can now support VPLS and virtual-switch routing instances.

  [VPNs]

• Load balancing and IP header filtering for Layer 3 VPNs—You can now simultaneously enable both load balancing of traffic across both internal and external BGP paths and filtering of traffic based on the IP header. To enable these features, include the vpn-unequal-cost equal-external-internal statement at the [edit routing-instances routing-instance-name routing-options multipath] hierarchy level and the vrf-table-label statement at the [edit routing-instances routing-instance-name] hierarchy level.

  [VPNs]

• PIM source-specific multicast (PIM-SSM) provider tunnel support added to Multiprotocol BGP-based multicast VPNs: next-generation—This feature allows service providers to configure PIM-SSM in the core network to carry customer data. PIM-SSM tunnels can be configured as an inclusive provider multicast service interface (PMSI).

  In addition, a new configuration statement is being added to control the single forwarder election, as described in the Internet draft draft-ietf-l3vpn-2547bis-mcast-bgp.

  By default, the single forwarder election is determined by the IP address from the global administrator field in the route-import community.

  You can configure a router to use the unicast route preference to determine the single forwarder election. To configure the router to use the unicast route preference, include the unicast-umh-election statement. The unicast-umh-election statement can be configured at the [edit logical-systems logical-system-name routing-instances routing-instance-name Protocols mvpn] and [edit routing-instances routing-instance-name protocols mvpn] hierarchy levels.

  [VPNs, Multicast ]

Related Topics

• Changes in Default Behavior and Syntax in JUNOS Release 9.6 for M Series, MX Series, and T Series Routers
• Issues in JUNOS Release 9.6 for M Series, MX Series, and T Series Routers
• Errata and Changes in Documentation for JUNOS Software Release 9.6 for M Series, MX Series, and T Series Routers
• Upgrade and Downgrade Instructions for JUNOS Release 9.6 for M Series, MX Series, and T Series Routers