Features in JUNOS Software Release 9.4 for M-series, MX-series, and T-series Routing Platforms

The following features have been added to JUNOS Release 9.3. Following the description is the title of the manual or manuals to consult for further information. For a complete list of manuals, see Table 8, Table 9, and Table 11.

Hardware

• New Flexible Port Concentrator (FPC) MX-FPC3 (MX-series)—supports SONET/SDH PICs on MX-series platforms. For a list of supported PICs, see the MX-series PIC Guide.

• New Enhanced IQ PICs with SFP (M40e, M120, and T-series routing platforms)—The following Enhanced Intelligent Queuing (IQ) PICs with small form-factor pluggable transceivers (SFP) are available:

  • 4-port Channelized SONET/SDH OC12/STM4 Enhanced IQ PIC
  • 1-port Channelized SONET/SDH OC48/STM16 Enhanced IQ PIC
  The Enhanced IQ PICs support all the same features as existing IQ PICs. They have additional COS and diagnostic features. The valid configuration statements are also the same; for some options, limits and ranges of values are different to support augmented capabilities. [PIC Guides, Class of Service, Network Interfaces]
• New Flexible PIC Concentrator (FPC)—The T640 and T1600 routing nodes support a new Type 1 FPC (T640-FPC1-ES).

  Note: All SIBs in the routing node must be SIB version B or the T640-SIB for T640 routing nodes connected to a TX Matrix before you install the T640-FPC1-ES.

  [T640 and T1600 Hardware Guides]

• New Enhanced CFEB (M7i and M10i routers)—The new Enhanced CFEB (CFEB-E) introduced on the M7i and M10i routing platforms provides additional performance, scaling, and functional capabilities. The CFEB-E provides the following enhancements to the M7i and M10i routers:
  • Increased number of logical interfaces.
  • Increased advanced services capabilities through the Multiservices PIC integration (M7i routers only).
  • Increased route, next-hop, and interface lookup memory allows installation of more routes and scaling of the network and services.
  • Increased per-FPC throughput.
  • Integrated Multiservices PIC and ASM PIC support (M7i only).
  • Enhanced class-of-service (CoS) features.

  [Hardware Guides]

• JCS 1200 platform supports mixed JUNOS Software versions—Protected System Domains (PSDs) and Root System Domains (RSDs) can now run different versions of JUNOS software. Each PSD or RSD must be running JUNOS Release 9.4 or later. [Protected System Domain]

• M40e, M120, M320, and T-series platforms support new Enhanced IQ2 (IQ2E) PICs, which include the following:

  • 4-port Gigabit Ethernet IQ2E, PB-4GE-TYPE1-SFP-IQ2E
  • 8-port Gigabit Ethernet IQ2E (Type 2), PB-8GE-TYPE2-SFP-IQ2E
  • 8-port Gigabit Ethernet IQ2E (Type 3), PC-8GE-TYPE3-SFP-IQ2E
  • 1-port 10-Gigabit Ethernet IQ2E, PC-1XGE-TYPE3-XFP-IQ2E
  M7i and M10i platforms support the new 4-port Gigabit Ethernet IQ2E (PE-4GE-TYPE1-SFP-IQ2E).

  The IQ2E PICs support a feature set similar to the IQ2 PICs but with the following enhancements: increased number of schedulers, hierarchical scheduler, four levels of strict priorities with priority propagation among scheduling levels, dynamic allocation of scheduler resources across ports, and enhanced drop statistics. [PIC Guides]

User Interface and Configuration

• Support for configuring ARP aging time for a logical interface—Provides the flexibility of configuring an ARP aging timer for each logical interface of family type inet, in addition to configuring a system-wide ARP aging timer at the [edit system arp] hierarchy level. To configure the ARP aging timer at the logical interface level, specify the timer value in minutes at the [edit system arp aging-timer interface interface-name] hierarchy level. [System Basics]

Interfaces and Chassis

• New Enhanced Intelligent Queuing (IQE) PICs (M40e, M120, M320, T320, T640, and TX platforms)—Support all features of the existing IQ PICs, and the interface configuration syntax is identical. The IQE PICs configuration statement limits and the option (range) limits vary to support augmented capabilities. For PIC compatibility, see the hardware Guide for your router. [Network Interfaces]
• Distributed PPM support for LACP (MX-series routers)—Enables you to switch between distributed and centralized periodic packet management (PPM). By default, distributed PPM is active. To enable centralized PPM, include the ppm centralized statement at the [edit protocols lacp] hierarchy level. To re-enable distributed PPM, include the ppm distributed statement at the [edit protocols lacp] hierarchy level. You can display LACP statistics output using the show lacp interfaces command. Previously, the LACP statistics were displayed using the show interfaces interface-name extensive command. [Network Interfaces, Interfaces Command Reference]
• Support for Maintenance Intermediate Points (MIPs) for Ethernet OAM 802.1ag CFM Protocol at a bridge-domain level on MX-series platforms—Enables you to define a maintenance domain (MD) for each default level. The MIP names are created as default-level-number at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. Multiple substatements allow for bridge-domain, routing-instance, and mip-half-function configuration. To display the MIP configuration, use the show oam ethernet connectivity-fault-management mip (bridge-domain | instance-name | interface-name) command. [Network Interfaces, Interfaces Command Reference]
• Support of Tri-Rate Copper SFPs on a Combo Line Rate DPC on an MX-series platform for Metro Ethernet and enterprise applications—Enables 20x1 Copper SFPs to provide backwards compatibility with 100/10BASE-T and 1000BASE-T operation through an SGMII interface. To enable, set the port speed to 1 Gbps, 100 Mbps, or 10 Mbps. The port speed is then negotiated to the configured value. If a match does not occur, the link will not come up. [Network Interfaces, MX-series DPC Guide]
• Ethernet ring protection switching (MX-series)—Loop avoidance protocol for Ethernet rings. Ethernet ring protection switching is responsible for the setup and control of an Ethernet ring. It helps provide highly reliable Ethernet networks by detecting Ethernet link failures and correcting the failures in less than 50 ms. An APS protocol coordinates the protection actions over the ring. To configure the Ethernet ring protection control protocol, include the ethernet-ring ethernet-ring-name statement at the [edit protocols protection-group] hierarchy level. [Network Interfaces]
• Static or dynamic IP demux subscriber interfaces over aggregated Ethernet links (MX-series routers)—Enables you to configure a logical subscriber interface over a static or dynamic IP demultiplexing (demux) interface. Prior to this release of JUNOS software, IP demux interfaces supported only Gigabit Ethernet, Fast Ethernet, and 10-Gigabit Ethernet links that were not part of an aggregated Ethernet bundle.

  A static or dynamic IP demux subscriber interface stacked on an aggregated Ethernet logical interface is considered active—and the subscriber interface demultiplexes packets received on all child interfaces in the aggregated Ethernet bundle—when the underlying Ethernet bundle is active. An aggregated Ethernet logical interface is considered active when it has two or more active members. Otherwise, the aggregated Ethernet logical interface is considered inactive.

  Traffic forwarding through an IP demux logical interface is dependent on the configuration of the underlying logical interface:

  • 1:1 active/backup link redundancy—For one-to-one active/backup link redundancy, configure the aggregated Ethernet interface in link protection mode, which requires that two underlying physical interfaces be designated as primary and backup links. For link redundancy at the DPC level, configure the aggregated Ethernet interface on physical interfaces that reside on different DPCs.
  • Load balancing—For traffic load balancing between the member links in an aggregated Ethernet bundle, configure the aggregated Ethernet interface to operate in Link Aggregation Control Protocol (LACP) active mode, which requires a two-link bundle in which one link is active and the other is in standby mode.

  The following table lists key features supported with static or dynamic IP demux subscriber interfaces, organized by type of underlying logical interface. IP demux interfaces over aggregated Ethernet are subject to the same scaling and configuration limitations inherent to aggregated Ethernet logical interfaces.

  Feature	Static or Dynamic IP Demux Subscriber Interface
  	Aggregated Ethernet Underlying Interface	Non-Aggregated Underlying Interface
  Protocol family support	IPv4 only	IPv4 only
  Per-subscriber firewall filtering and statistics	Supported	Supported
  Hierarchical CoS	No	Supported
  Per-subscriber CoS parameters within the [edit dynamic-profiles profile-name protocols] hierarchy level	No	Supported
  Per-subscriber IGMP configuration within the [edit dynamic-profiles profile-name protocols] hierarchy level	No	No

  To configure an aggregated Ethernet logical interface to serve as the underlying interface for a static or dynamic IP demux subscriber interface, include statements at the static [edit interfaces aex unit logical-unit-number] hierarchy level for each Ethernet link of the aggregated bundle:

  1. Enable demultiplexing of incoming traffic to the Ethernet links based on IPv4 destination or source addresses in the incoming packets. To configure, include either the demux-destination statement with an IPv4 destination address or the demux-source statement with an IPv4 source address.
  2. Configure the IP address (explicit or derived) of each link in the aggregated Ethernet interface. To configure an IP address of an Ethernet link, include the family inet address statement sequence. To configure a derived IP address for an Ethernet link, include the family inet unnumbered-address statement.

  To configure a static or dynamic IP demux subscriber interface using an appropriately configured aggregated Ethernet logical interface as the underlying logical interface, include statements at the static [edit interfaces demux0] hierarchy level or at the [edit dynamic-profiles profile-name interfaces demux0] hierarchy level:

  1. Configure the IP demux interface on a physical device (of the underlying logical interface).
  2. Specify the underlying interface on which the IP demux interface is running (or is to run).
  3. Specify how ingress IPv4 traffic is to be demultiplexed based on packet destination or source addresses.
  4. (Optional) Specify a filter to apply when a packet is received or transmitted on the interface.

  The following configuration statements and operational commands have been expanded to support IP demux interfaces over aggregated Ethernet logical interfaces:

  • The unit logical unit configuration statement, when included under the [edit interfaces aex] hierarchy level, has been expanded to support demux-destination (demux interface) and demux-source (demux interface) statements for an IP demux underlying interface
  • The show interfaces demux0 (demux interfaces) operational command has been enhanced to display an aggregated Ethernet logical interface as an underlying interface for an IP demux interface.
  • The show interfaces (aggregated Ethernet) operational command output has been updated to indicate when an aggregated Ethernet logical unit is being used as an underlying interface for an IP demux interface and to display the logical demultiplexing destination or source family type; however the command output does not display the supported IP demux logical interface.

  [Network Interfaces, Subscriber Access, Interfaces Command Reference]

• With JUNOS Release 9.4, the JCS 1200 platform adds support for the following Ethernet IQ2 PICs:

  • 4-port Gigabit Ethernet IQ2, SFP (PB-4GE-TYPE1-SFP)
  • 8-port Gigabit Ethernet IQ2, SFP (Type 2) (PB-8GE-TYPE2-SFP-IQ2)
  • 8-port Gigabit Ethernet IQ2, SFP (Type 3) (PC-8GE-TYPE3-SFP-IQ2)
  • 1-port 10-Gigabit Ethernet IQ2, XFP (PC-1XGE-TYPE3-XFP-IQ2)
  [Protected System Domain ]

• With JUNOS Release 9.4, the following PICs support interfaces that can be shared by multiple Protected System Domains (PSDs). PSDs are configured on a T-series routing platform that is connected to a JCS 1200 platform.

  • 1-port 10-Gigabit Ethernet DWDM
  • 1-port 10-Gigabit Ethernet XENPAK
  • 10-port 1-Gigabit Ethernet SFP
  To configure Gigabit Ethernet interfaces as shared interfaces, you configure parameters on both the Root System Domain (RSD) and the PSD. On the RSD, you configure the physical interface and then configure and assign each logical shared interface under it to a specific PSD. On the PSD, you configure the physical interface as well and identify it as a shared interface. Then configure the assigned logical interfaces under it and bind each one to a peer interface on a Tunnel PIC owned by the PSD. The tunnel peer transports packets between the PSD and the shared interface on the RSD.

  When you configure shared interfaces, the values for several parameters configured on the RSD and the PSD must match:

  • VLAN tagging must be configured on the physical Gigabit Ethernet interface in both the RSD and the PSD.
  • The same logical unit number must be specified on the physical shared interface (ge-fpc/pic/slot.logical unit-number) and on the physical uplink tunnel interface (ut-fpc/pic/slot.logical unit-number) owned by the PSD.
  • The same virtual LAN (VLAN) identifier must be specified on the logical Ethernet interface configured in both the RSD and the PSD.

  [Protected System Domain ]

• The IQ2E PIC family extends the CoS scaling and functionality of the IQ2 PIC family.

  Table 1: Main IQ2E Enhancements over the IQ2 Family

  Feature	IQ2	IQ2E
  Schedulers	1K	2K (8 queues) 4K (4 queues)
  Scheduler hierarchy	2 (vlan, queues)	(vlan group, vlan, queues)
  Priority levels	strict-high, low	strict-high, high, medium, low, and excess
  Priority propagation between scheduling levels	No	Yes
  Schedulers resource allocation across ports	Static	Dynamic
  Per drop-profile RED drop statistics	No	Yes

  IQ2E PICs support all the existing features of IQ2 PICs.

  Note: IQ2E cards do not support the shared scheduler keyword.

  IQ2E PICs are designed with increased microcode space, enabling more features to be added in future releases.

  IQ2E PICs are configured in the same way as IQ2 PICs, but offer additional CoS parameters, and some value ranges are extended to support the enhancements. [Network Interfaces, Class of Service, PIC Guide]

• Ethernet 802.1ag support on trunk port—On MX-series routers starting with JUNOS Release 9.4, users can easily specify a list of VLANs on a single logical interface which can be part of a set of bridge domains with matching VLAN IDs.

  To configure a list of VLANs, use the direction (up | down) | interface (ge | xge)- (fpc/pic/port | fpc/pic/port.domain | fpc/pic/port.domain vlan vlan-id) statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier mep mep-id] hierarchy level.

  To display the current 802.1ag configuration, use the show routing-instances command. [Network Interfaces]

• Channelized SDH (cstm) Enhanced Intelligent Queuing (IQE) interfaces support simultaneous E1 and E3 channelization within a single STM-1—On M40e, M120, M320, T320, T640, and TX platforms, JUNOS Release 9.4 supports mixing of E3 and E1 channels under the same cau4 interface. This is useful for a cstm1 interface with only one cau4. You can operate both e3 and e1/ce1 simultaneously on one cstm1 interface. To configure simultaneous E1 and E3 channelization, use the tug-3 statement and its partition and no-partition options under the [edit interfaces (cstm1-fpc/pic/port | cau4-fpc/pic/port)] hierarchy level. To display the configuration, use the show interface (cau4-fpc/pic/port | cau4-fpc/pic/port) command. [Network Interfaces]
• SONET APS ANNEX.B (G.841) for ATM support for M120 and M320—JUNOS Release 9.4 adds Multiplex Section Protection (MSP) protection switching on SDH interfaces. To configure the Annex.B parameters, use the sonet-options aps annex-b statement at the [edit interfaces so-fpc/pic/port] hierarchy level. Use the show aps extensive command to display an existing Annex.B configuration. [Network Interfaces]
• Supports for the new Clear-Channel OC3/STM1 Enhanced Intelligent Queuing (IQE) PICs and DS3/E3 IQE PICs —The IQE PICs support all features of the existing IQ PICs, and the interface configuration syntax is identical. The Enhanced IQ PICs configuration statement limits and the option (range) limits vary to support augmented capabilities. [Network Interfaces]

JUNOScope

• JUNOScope support for the JCS 1200 platform product—A JUNOScope administrator can create a record for a Root System Domain (RSD) and a Protected System Domain (PSD). Users can perform all configuration manager operations. The inventory scan operation on an RSD scans the device for both the hardware and software inventory. However for a PSD, only the software inventory scan is performed. Users can perform all software manager and looking glass operations. [JUNOScope]

Services Applications

• Port mirroring functionality is now supported on TX Matrix platforms. There are no associated CLI or behavioral changes. [Services Interfaces]
• Support for IPv6 flow aggregation templates—Adds support for IPv6 traffic templates for use with version 9 flow aggregation. Previously, only IPv4 and MPLS templates were supported. To configure, include the family inet6 statement at the [edit forwarding-options sampling input] hierarchy level and the new ipv6-template option at the [edit services flow-monitoring version9 template template-name] hierarchy level. To filter the IPv6 traffic on a media interface, include the sampling (input | output) statement at the [edit interfaces interface-name unit logical-unit-number family inet6] hierarchy level. [Services Interfaces, Feature Guide]
• MultiServices DPC enhanced feature support (MX routing platforms)—Adds support for generic routing encapsulation (GRE) tunnels and graceful Routing Engine switchover (GRES) on the MultiServices DPC. There are no associated changes to the existing CLI. [Services Interfaces]
• Active monitoring enhancement—Adds support for application of multiple simultaneous version 9 flow aggregation templates in active monitoring configurations on services interfaces. Previously, only one type of traffic template (IPv4 or MPLS) could be specified at a time. The restrictions are lifted at the [edit forwarding-options sampling input] and [edit services flow-monitoring version-9] hierarchy levels; no new CLI statements are required. [Services Interfaces, Feature Guide]
• Session Policy Decision Function (SPDF) solution for the Integrated Multi-Service Gateway—The SPDF is modeled after TISPAN’s SPDF component. The SPDF handles media sessions and resources for the BSG. The BSG sends to the SPDF a summary of any new media session that is signaled through SIP. The SPDF then decides whether the media session can start and configures the border gateway function (BGF) in such a way that the media session’s service is assured. To configure, include the embedded-spdf statement at the [edit services border-signaling-gateway gateway gateway-name] hierarchy level. [Services Interfaces Guide, Multiplay Solutions]
• Quality of service for the border signaling gateway (M320, Reno-M120, and T640 platforms)—Enables you to use new quality-of-service (QoS) functionality. You can configure a service class and apply it based on a media policy. Quality of service can be selectively applied according to the selected media type. You can configure one set of QoS parameters for a video stream and a different set of parameters for voice. You can also prevent packet gateway (PG) saturation by limiting the number of concurrent sessions.

  To configure a service class, enter the service-class statement at the [edit services border-signaling-gateway gw-name embedded-spdf] hierarchy level and include a committed-information-rate (bytes per second) and committed-burst-size (bytes).

  To apply a configured service class based on a media policy, enter the following statement at the [edit services border-signaling-gateway gateway gw-name sip new-call-usage-policy policy-name] hierarchy level: set term term-name then media-processing service-class service-class-name.

  To limit the number of concurrent sessions, enter the max-concurrent-calls statement at the [edit services pgcp gateway gateway-name] hierarchy level. [Services Interfaces, Multiplay Solutions]

• Routing of SIP requests for the border signaling gateway (BSG)—For routing of SIP requests, you can specify a next-hop action that controls the SIP entity towards which SIP requests are sent. You can set the next hop to either a static IP address or to be extracted from the SIP request according to SIP rules. Also, you can specify the exit point of the request from the BSG by setting an egress service point. To configure, include the route statement at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then] hierarchy level. [Services Interfaces Guide, Multiplay Solutions]

Subscriber Access Management

• Accounting volume statistics (MX-series platforms)—The subscriber access management feature now supports the collection of volume statistics (total number of bytes) for subscriber sessions. You can specify that subscriber access management collect either time statistics or both volume and time statistics. Use the accounting statistics <volume-time | time> statement at the [edit access profile] hierarchy level to specify the type of statistics to collect. [Subscriber Access]
• Time-based accounting for Mobile IP subscribers (MX-series routers)—The JUNOS Mobile IP home agent application now supports time-based accounting for Mobile IP subscribers. Accounting begins when the Mobile IP home agent registers the mobile node and creates a binding with the mobile node. Accounting stops when the binding is deleted.

  Any of the following actions can cause the binding to be deleted:

  • The mobile user logs off.
  • The binding lifetime expires.
  • The binding is cleared by the administrator.
  • The mobile node is deregistered for any reason.
  • The foreign agent sends a revocation message.

  The Acct-Start message sent by the home agent to the AAA server includes the network address identifier (NAI) in the User-Name attribute and the home address of the mobile IP node in the Framed-IP-Address attribute. The Acct-Stop message additionally includes the Acct-Session-Id and Acct-Session-Time attributes.

  To configure time-based accounting for mobile IP subscribers, include the statistics time statement at the [edit access profile profile-name accounting] hierarchy level. This configuration turns on time-based accounting for all mobile IP subscribers associated with this profile; you cannot enable accounting for individual subscribers.

  Mobile IP is currently supported in only the default logical router or default routing instance. You cannot currently configure time-based accounting for only the Mobile IP service in the default logical router or default routing instance. Enabling time-based accounting for Mobile IP also enables time-based accounting for all other services that are configured in the default logical router or default routing instance. If you do not want time-based accounting to apply to other services, then you must configure those services in a different logical router or routing instance. [Subscriber Access]

• Semantic checking support for dynamic profiles—Variables are applied to dynamic profiles dynamically and cannot be checked with existing CLI checks. Semantic checking validates some variables in dynamic profiles to help identify potential configuration errors. Semantic checks are performed during commit and during profile instantiation. Commit time checks ensure that variables appear in the correct location within the dynamic profile. Checks performed before profile instantiation ensure that the values that replace the variables are correct. The checks performed on the values include range validation, variable type validation, existence of variables where they are mandatory, and variable matching to regular expressions. A commit time check failure results in an error message being displayed and logged into /var/log/messages and the commit not taking place. An instantiation failure results in an error being logged in /var/log/messages and the profile instantiation failing. [Subscriber Access]
• JUNOS predefined internal variables support dynamic CoS configuration in subscriber dynamic access profiles (EQ DPCs on MX-series routers) — You can configure a client dynamic profile that specifies class-of-service (CoS) parameters that the router obtains from the RADIUS server when a client authenticates over a router interface associated with the client dynamic profile.

  Prior to this release of JUNOS software, dynamic CoS configuration for subscriber access required that you create user-defined variables at the [edit dynamic-profiles profile-name variables] hierarchy level.

  Note: To associate dynamically configured initial CoS features with a subscriber interface, you can now reference JUNOS internal variables in a client dynamic profile for that interface. Do not define and reference user-defined variables for CoS parameters in a client dynamic profile.

  This feature is supported only for interfaces on Enhanced Queuing Dense Port Concentrators (EQ DPCs) in MX-series routers.

  First you must configure support for RADIUS dynamic requests. You can then define CoS parameter values on a RADIUS authentication server.

  To support dynamic configuration of traffic-shaping CoS parameters, you must configure Juniper Networks VSA 26-108. To support dynamic configuration of CoS scheduling and queuing parameters, you must configure Juniper Networks VSA 26–146.

  Using JUNOS Predefined Internal Variables to Dynamically Configure Initial Traffic Shaping

  To provide an initial scheduler map name and traffic shaping parameters obtained from the RADIUS authentication server when a subscriber logs in, configure a client dynamic profile and then apply the profile to the interface. Within the client dynamic profile, configure a traffic-control profile that references any of the following JUNOS internal variables for CoS by including statements at the [edit dynamic-profiles client-profile-name class-of-service traffic-control-profiles tc-profile-name] hierarchy level:

  • $junos-cos-scheduler-map—Name of a scheduler map. Can be referenced in the scheduler-map statement.
  • $junos-cos-shaping-rate—Traffic-shaping rate. Can be referenced in the shaping-rate statement.
  • $junos-cos-guaranteed-rate—Guaranteed traffic rate. Can be referenced in the guaranteed-rate statement.
  • $junos-cos-delay-buffer-rate—Delay-buffer rate. Can be referenced in the delay-buffer-rate statement.

  Using JUNOS Predefined Internal Variables to Dynamically Configure Initial Scheduling and Queuing

  To provide an initial scheduler name and scheduling and queuing parameters obtained from the RADIUS authentication server when a subscriber logs in, configure a client dynamic profile and then apply the profile to the interface. Within the dynamic profile, configure a scheduler definition that references any of the following JUNOS internal variables for CoS by including statements at the [edit dynamic-profiles client-profile-name class-of-service traffic-control-profiles client-profile-name] hierarchy level:

  • $junos-cos-scheduler—Name of a scheduler. Can be referenced in the schedulers statement.
  • $junos-cos-scheduler-tx—Transmission rate for the scheduler. Can be referenced in the transmit-rate statement.
  • $junos-cos-scheduler-bs—Size of the buffer for the scheduler. Can be referenced in the buffer-size statement.
  • $junos-cos-scheduler-pri—Queuing priority level for the scheduler. Can be referenced in the priority statement.
  • $junos-cos-scheduler-dropfile-low—Name of the drop profile assigned to the loss-priority value low. Can be referenced in the dropfile statement.
  • $junos-cos-scheduler-dropfile-medium-low—Name of the drop profile assigned to the loss-priority value medium-low. Can be referenced in the drop-profile statement.
  • $junos-cos-scheduler-dropfile-medium-high—Name of the drop profile assigned to the loss-priority value medium-high. Can be referenced in the drop-profile statement.
  • $junos-cos-scheduler-dropfile-high—Name of the drop profile assigned to the loss-priority value high. Can be referenced in the drop-profile statement.
  • $junos-cos-scheduler-dropfile-any—Name of the drop profile assigned to the loss-priority value any. Can be referenced in the drop-profile statement.

  [Subscriber Access]

• Access Node Control Protocol (ANCP) supported (MX-series routers)—The JUNOS software now supports the topology discovery capability of ANCP. ANCP acts as a control plane between a service-oriented Layer 3 edge device and a Layer 2 access node.

  Queuing and scheduling mechanisms must avoid congestion within the access network while contending with multiple flows and distinct QoS requirements. These mechanisms require the edge device, a network access server (NAS), also known as a broadband remote access server, to provide information about the access network and subscriber traffic.

  The NAS gets this information from the access node, typically a DSL access multiplexer (DSLAM). The information includes the access network topology, DSL line state, actual upstream and downstream net data rates of a synchronized DSL link, maximum attainable upstream and downstream net data rates, interleaving delay, and so on.

  The NAS then shapes the aggregate egress traffic to subscribers based on the local loop throughput reported by the DSLAM. This traffic shaping optimizes traffic flow while avoiding traffic drops in the access node.

  To specify the interval between adjacency messages sent to ANCP adjacency peers, include the adjacency-timer seconds statement at the [edit protocols ancp] hierarchy level. The range is 1 through 25 seconds; the default is 10 seconds. Subscribers are identified by a system-wide unique access loop identifier that is associated with a named set of VLANs. To configure the interface set, include interface-set set-name statement at the [edit protocols ancp interfaces] hierarchy level. To configure the access loop identifier, include the access-identifier identifier statement at the [edit protocols ancp interfaces interface-set set-name] hierarchy level.

  To specify how long other processes wait for ANCP to restart, include the maximum-helper-restart-time seconds statement at the [edit protocols ancp] hierarchy level. The range is 30 through 300 seconds; the default is 90 seconds. If ANCP goes down and does not restore its sessions with the peer DSLAMs within the specified interval, the CoS updates implemented as a result of ANCP are maintained. The shaping rates change only if ANCP sends updates to shape subscriber traffic after ANCP comes back up and restores its sessions.

  To include an access node in the list of ANCP neighbors that can establish a TCP connection with the edge device, include the neighbor ip-address statement at the [edit protocols ancp] hierarchy level. ANCP traffic monitoring and adjusting is available only to access nodes whose IP addresses are configured in this manner.

  To run ANCP in a mode that is backwards compatible with an early draft of the standard (draft-ietf-ancp-protocol-00.txt), include the pre-ietf-mode statement at the [edit protocols ancp] hierarchy level.

  To specify that CoS policy for interface sets (subscriber VLANs) is adjusted based on information received from the access network in ANCP messages, include the qos-adjust statement at the [edit protocols ancp] hierarchy level.

  To troubleshoot ANCP, you can trace its operations by including the flag flag statement at the [edit protocols ancp traceoptions] hierarchy level.

  To remove the ANCP neighbor configuration, issue the clear ancp neighbor command.

  To monitor ANCP operations, issue the following commands:

  • show ancp cos—Display CoS state information for all subscribers.
  • show ancp cos identifier—Display CoS state information for the subscriber identified by the access loop identifier.
  • show ancp cos last-update—Display the most recently updated CoS state information for all subscribers.
  • show ancp cos pending-update—Display the CoS state information that is pending update for all subscribers.
  • show ancp neighbor—Display DSLAM-related information for all ANCP neighbors.
  • show ancp neighbor (ip-address | mac-address)—Display DSLAM-related information for the ANCP neighbor specified by the access node’s IP address or MAC address.
  • show ancp subscriber brief—Display information about all ANCP subscribers.

    show ancp subscriber identifier identifier —Display information about the ANCP subscriber specified by the access loop identifier.

  • show ancp subscriber neighbor ip-address—Display information about all ANCP subscribers accessed through the specified neighbor.

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

  • Total number of logical interfaces: 52,000

  • Total number of subscribers per interface per session:

    • One subscriber per VLAN configuration: 52,000
    • Multisession configuration: 120,000

  Note: Qualification of the multisession configuration used 24,000 logical interfaces.

  [Subscriber Access]
• Shaping-rate adjustments manage subscriber bandwidth at scheduler nodes to prevent overcommitment of the access bandwidth to each subscriber access client (EQ DPCs on MX-series routers)—Manages the subscriber’s aggregate bandwidth so that bandwidth contention does not occur at the subscriber’s residential gateway interface on the broadband service router (BSR). Without this feature, bandwidth oversubscription at the subscriber’s residential gateway can degrade not only the subscriber’s video service, but also other services such as voice and data.

  For this release, a BSR can perform shaping-rate adjustments on scheduler nodes that are static logical interface sets configured to represent subscriber local loops. In this scenario, traffic destined to a subscriber is delivered from the access network, through a BSR, to a DSL access multiplexer (DSLAM). The DSLAM multiplexes subscriber traffic to a DSL line (also known as a local loop) to the subscriber’s residential gateway. The Access Node Control Protocol (ANCP) communicates local loop speed to the BSR, which can shape traffic destined to the subscribers to the local loop speed. A new JUNOS daemon, the Access Node Control Protocol daemon (ancpd), supports ANCP by acquiring subscriber line rate information from DSLAMs and then communicating this local loop speed to the JUNOS class-of-service daemon (cosd).

  Keep the following points in mind when you configure shaping-rate adjustment:

  • Shaping-rate adjustments are supported only for interfaces configured for hierarchical schedulers, and only interfaces on EQ DPCs in MX-series routers can be configured for hierarchical schedulers.
  • For this release, ANCP shaping-rate adjustments are supported only on subscriber scheduler nodes represented by static logical interface sets, and are not supported on static logical interfaces.
  • You must configure an initial shaping rate for the scheduler node by including the shaping-rate statement in a traffic-control profile applied to the scheduler node. Specify the initial shaping rate as a peak rate, in bits per second (bps), and not as a percentage. Other methods of configuring a shaping rate are not supported with this feature.
  • After shaping-rate adjustments are enabled and the BSR has performed shaping-rate adjustments on a scheduler node, you can configure a new shaping rate by including the shaping-rate statement in a traffic-control profile and then applying that profile to that scheduler node. This new shaping-rate value does not result in throttling of ingress traffic at the queues managed by the scheduler node unless or until the shaping-rate adjustment feature is disabled.
  • The Layer 2 Tunneling Protocol (L2TP) is often used to carry traffic securely between an L2TP Network Server (LNS) and an L2TP Access Concentrator (LAC). The QoS adjustment feature supports the shaping overhead options that you can use to add a specified number of bytes to the actual packet length when determining shaped session packet length. ANCP shaping-rate adjustments are not supported for ingress traffic, only for egress traffic. To configure the number of bytes to add to the packet at the egress side of the tunnel, include the egress-shaping-overhead and mode statements at the [edit chassis fpc slot-number pic pic-number traffic-manager] hierarchy level. Use the shaping overhead options if you need to account for encapsulation overhead.

  To enable ANCP shaping-rate adjustments on a supported scheduler node for a subscriber, perform the following steps:

  1. Configure static logical interface sets to be used as CoS hierarchical schedulers for subscribers.

     For each logical interface in the logical interface set, enable the use of CoS hierarchical scheduling by including the hierarchical-scheduler statement at the at the [edit interfaces ethernet-interface-name] hierarchy level.

     For each interface set, include the interface-set statement and specify an interface set name as the interface-set-name option, and then apply the logical interface set to logical interfaces. For each logical interface in a logical interface set, include the interface statement and specify the interface name as the ethernet-interface-name option at the [edit interfaces interface-set interface-set-name] hierarchy level:

     [edit]interfaces {ethernet-interface-name {hierarchical-scheduler;(flexible-vlan-tagging | stacked-vlan-tagging);}...interface-set interface-set-name {interface ethernet-interface-name {vlan-tags-outer vlan-tag;}...}}
     To apply the logical interface set to interfaces at the stacked VLAN level, include the vlan-tags-outer statement and specify a service VLAN (S-VLAN) tag as the vlan-tag option.

  2. Enable hierarchical scheduling on the static logical interface sets by including statements at the [edit class-of-service interfaces] hierarchy level. To enable all traffic heading to devices downstream from the Ethernet interfaces in the interface set to be gathered into an interface set, include the interface-set statement and specify the name of a statically configured logical interface set as the interface-set-name option. To apply output traffic scheduling and shaping parameters at the logical interface level (level 3) of a logical interface set, include the output-traffic-control-profile statement and specify the name of a traffic-control profile as the profile-name option at the [edit class-of-service interfaces interface-set interface-set-name] hierarchy level.

     [edit]class-of-service {interfaces {interface-set interface-set-name {output-traffic-control-profile profile-name;}...}}

  3. Configure the traffic-control profiles that are applied to the scheduler nodes (static logical interface sets) by including statements at the [edit class-of-service traffic-control-profiles] hierarchy level:

     [edit]class-of-service {traffic-control-profiles {profile-name { # Specify a scheduler map & traffic controlsscheduler-map (map-name | $junos-cos-scheduler-map);shaping-rate (rate | $junos-cos-shaping-rate);guaranteed-rate (percent percentage | rate | $junos-cos-guaranteed-rate;delay-buffer-rate (percent percentage | rate | $junos-cos-delay-buffer-rate);}...}}
     A traffic-control profile defines the characteristics of the scheduler node to which it is applied. The scheduler map referenced in a traffic control profile defines the queues (forwarding classes) over the scheduler node. The shaping rate, guaranteed rate, and buffer-delay rate specified in a traffic-control profile define the traffic-shaping parameters enforced by the scheduler node on the queues over it.

     Note: Either the shaping-rate statement, the guaranteed-rate statement, or both are required in a traffic-control profile. For a traffic-control profile that is applied to a scheduler node whose bandwidth management is adjusted through shaping-rate adjustments by the BSR, always include the shaping-rate statement and specify a shaping-rate value as a peak rate, in bits per second (bps), and not as a percentage.

  4. Configure the scheduler maps referenced from the traffic-control profiles for the scheduler nodes. A scheduler map establishes the queues that comprise a scheduler node and associates each queue with a specific scheduler map. To configure scheduler maps, include the following statements at the [edit class-of-service scheduler-maps] hierarchy level:

     [edit]class-of-service {scheduler-maps { # Define the queues that comprise each scheduler nodemap-name { # Map each queue in the scheduler node to a schedulerforwarding-class class-name scheduler scheduler-name;...}...}}

  5. Configure the schedulers referenced in the scheduler maps that define the queues. A scheduler defines the scheduling and queuing characteristics of the queue with which it is associated in a scheduler map. To configure schedulers, include the following statements at the [edit class-of-service schedulers] hierarchy level:

     [edit]class-of-service {schedulers { # Define scheduling characteristics of a queuescheduler-name { # Transmit rate and buffer management parameterstransmit-rate transmit-rate-option;buffer-size buffer-size-option;priority priority-level;drop-profile-map loss-priority loss-priority-option protocol any drop-profile drop-profile-name;...}...}}

  6. To enable ANCP shaping-rate adjustments for the subscriber interface-sets, include the qos-adjust statement at the [edit protocols ancp] hierarchy level and include the interface-set statement for each interface set that represents a subscriber:

     [edit]protocols {ancp {qos-adjust;interfaces {interface-set {interface-set-name {access-identifier “identifier-string”;}}}}}
     To specify subscriber-specific access identifier information for an interface set, include the access-identifier statement and specify a quoted text string as the identifier-string option at the [edit protocols ancp interfaces interface-set interface-set-name] hierarchy level.

  To disable ANCP shaping-rate adjustment on the BSR, disable QoS adjustments for the ANCP protocol:

  [edit protocols ancp]user@router# delete qos-adjust

  [Subscriber Access]

• Subscriber Secure Policy License (MX-series routers)—The subscriber secure policy feature requires the Subscriber Secure Policy License. You can configure and use the feature for a 30-day grace period. After the grace period, you must purchase a license key from Juniper Networks to continue using the subscriber secure policy feature. To display license key information, issue the show system license command. [Software Installation and Upgrade]
• Subscriber secure policy (MX-series platforms)—Subscriber secure policy is a subscriber access management feature that provides RADIUS-initiated traffic mirroring on a per-subscriber basis. The original traffic is sent to its intended destination and the mirrored traffic is sent to a mediation device for analysis. Subscriber secure policy runs on the existing JUNOS flow-tap service infrastructure.

  Subscriber secure policy uses RADIUS-based triggers, rather than CLI commands, to initiate traffic mirroring. When a subscriber logs on, the trigger in the RADIUS Access-Accept message initiates the mirroring. This type of RADIUS-initiated mirroring enables you to mirror per-subscriber traffic without regard to how often the subscriber logs on or off, or which router or interface the subscriber uses. If the subscriber is already logged on, the trigger in a RADIUS CoA message initiates the mirroring action.

  Access and viewing of subscriber secure policy configuration and operation is restricted to authorized users. The actual mirroring operation is transparent to subscribers whose traffic is being mirrored. [Subscriber Access]

• Static VLAN subscriber interfaces over aggregated Ethernet with support for static and dynamic hierarchical CoS (EQ DPCs in MX–series routers)—This release of JUNOS software supports the dynamic configuration of static VLANs, including the dynamic configuration of hierarchical class of service (CoS). Prior to this release of JUNOS software, hierarchical CoS support for VLAN subscriber interfaces was limited to static VLAN interfaces over Gigabit Ethernet, Fast Ethernet, and 10-Gigabit Ethernet links that were not part of an aggregated Ethernet bundle.

  Note: For this release of JUNOS software, hierarchical CoS is not supported for dynamic VLAN interfaces over aggregated Ethernet links, nor for IP demultiplexing (demux) interfaces over aggregated Ethernet links.

  A static VLAN subscriber interface over aggregated Ethernet can also support one-to-one active/backup link redundancy, depending on how you configure the underlying aggregated Ethernet interface:

  • If you need to support one-to-one active/backup link redundancy, configure the aggregated Ethernet interface in link protection mode, which requires that the two underlying physical interfaces be designated as primary and backup links.
  • If you need to support one-to-one active/backup link redundancy at the DPC level, configure the aggregated Ethernet interface on physical interfaces that reside on different EQ DPCs.

  Note: One-to-one active/backup link redundancy is also supported with firewall filters and policy filters for static non-VLAN interfaces configured on aggregated Ethernet logical interfaces, provided LACP is not active.

  The following configuration statements and operational commands have been expanded to support static VLAN subscriber interfaces over aggregated Ethernet logical interfaces:

  • The show interface redundancy operational command output has been expanded to include aggregated Ethernet logical interfaces. For an aggregated Ethernet interface, the command output shows the aex logical interface number in the Interface field and the interface names of the primary and backup links for egress traffic in the Primary and Secondary fields.
  • The show firewall operational command output has been expanded to include the number of packets that are affected by a policy. To include this information in the output, specify the filter filter-name counter counter-name command options.

  Configuring the Aggregated Ethernet Logical Interface

  For a static VLAN subscriber interface over aggregated Ethernet to support static or dynamic hierarchical CoS, you must configure the link aggregation (LAG) bundle underlying the static VLAN subscriber interface as follows:

  • Both physical links of the aggregated Ethernet logical interface must be capable of operating in hierarchical scheduling mode, which is only supported for ports on EQ DPCs in MX-series routers.
  • The LAG bundle must operate in link-protect mode. To configure, include the link-protection statement at the [edit interfaces aex aggregated-ether-options] hierarchy level.

  Applying Hierarchical CoS to the Aggregated Ethernet Interface

  You can attach static or dynamic traffic shaping and scheduling parameters to the aggregated Ethernet logical interface at the physical (device) level or at the logical (unit) level. As an example, consider the following scenario:

  • An aggregated Ethernet physical interface, ae15, has two subscribers that are represented by logical units 0 and 1.
  • We want to shape the entire aggregated Ethernet interface to 500 Mbps and apply individual CoS parameters to each of the subscriber VLANs. To implement this traffic shaping and scheduling scheme, we have configured three traffic-control profiles with the parameters shown in the following table.

  Traffic-Control Profile Name	Configured Parameters
  	Scheduler-Map Name	Shaping Rate	Guaranteed Rate	Delay-Buffer Rate
  tcp_for_ae_device_pir_500m	—	500 m	—	—
  tcp_for_ae_smap_video_pir_20m_delay_30m	smap_video	20 m	—	30 m
  tcp_for_ae_smap_video_cir_50m_delay_75m	smap_video	—	50 m	75 m

  In the following class-of-service stanza, one traffic-control profile is applied to the physical interface (ae15) to shape the entire aggregated Ethernet interface to 500 Mbps. The second and third traffic-control profiles are applied to the logical interfaces (ae15.0 and ae15.1, respectively) to specify individual CoS parameters to each of the subscriber VLANs:

  class-of-service {traffic-control-profiles { # Configure traffic-control profilestcp_for_ae_device_pir_500m {. . .}tcp_for_ae_smap_video_pir_20m_delay_30m {. . .}tcp_for_ae_smap_video_cir_50m_delay_75m {. . .}}interfaces {ae15 { # Attach 1st traffic-control profile to ae15output-traffic-control-profile tcp_for_ae_device_pir_500m; unit 0 { # Attach 2nd traffic-control profile to ae15.0output-traffic-control-profile tcp-for-ae_smap_video_pir_20m_delay_30m; }unit 1 { # Attach 3rd traffic-control profile to ae15.1output-traffic-control-profile tcp_for_ae_smap_video_cir_50m_delay_75m; }}}}

  When you apply hierarchical CoS parameters to the physical interface of an aggregated Ethernet logical interface (such as ae15 in the example above), those CoS parameters apply to each of the associated member links of the logical interface. When you apply hierarchical CoS parameters to a physical interface of an aggregated Ethernet logical interface (such as ae15.0 or ae15.1 in the example above), those CoS parameters apply to the associated logical interfaces on each member link.

  You can include a similar class-of-service stanza at one of the following hierarchy levels, depending on whether you are configuring static or dynamic CoS:

  • [edit]
  • [edit dynamic-profiles profile-name]

  The example does not show configurations for the scheduler map smap_video (referenced by two of the traffic-control profiles), nor for any schedulers, forwarding-classes, or drop profiles.

  [Subscriber Access]

Multicast

• JUNOS software supports configuring accept any-source multicast (ASM) join messages (*,G) for group addresses—You can configure the JUNOS software to accept any-source multicast (ASM) join messages (*,G) for group addresses that are within the range configured for source-specific multicast (SSM) groups. This allows you to support a mix of any-source and source-specific multicast groups simultaneously.

  To configure the router to accept any-source multicast join messages for groups within the SSM address range, include the asm-override-ssm statement at the [edit routing-options multicast] hierarchy level. [Multicast Protocols Configuration Guide]

• JUNOS software support for IGMPv3 snooping on Layer 2 interfaces for MX-series routers— This support gives hosts the flexibility to choose the sources that they want to receive traffic from and to choose sources they do not want to receive traffic from. No additional configuration is required. Both the include and exclude modes are supported. [Multicast Protocols Configuration Guide, Routing Protocols and Policies Command Reference]
• JUNOS software supports the ability to configure a provider network to operate in source-specific multicast (SSM) mode—When MVPN is used over an SSM provider core, no PIM rendezvous points are required to provide autodiscovery between PE routers. Instead, a BGP NLRI and multicast distribution tree (MDT) subsequent address family identifier (SAFI) are used to facilitate autodiscovery of PE routers by one another. To configure source-specific multicast in a provider network, include the pim-ssm statement at the [edit routing-instances routing-instance-name provider-tunnel] hierarchy level. To enable MDT SAFI autodiscovery, include the inet-mdt statement at the [edit routing-instances routing-instance-name protocols pim mvpn autodiscovery] hierarchy level. [Multicast Protocols Configuration Guide, VPNs Configuration Guide, Routing Protocols Configuration Guide, Feature Guide]

Mulitplay

• PGCP—The PGCP session mirroring feature now supports mirroring of IPv6 traffic. IPv6 packets are encapsulated in an IPv4 header and sent to the deliver function. [Multiplay Solutions]
• Syslog messages from the pgcpd process (all platforms)—As of JUNOS Release 9.4, the pgcpd process generates messages that can be directed to a syslog server. These messages facilitate troubleshooting and performance analysis. No new CLI configuration is required.

  The pgcpd process syslog messages are shown in the following table, which lists each logged event, the event’s description that appears in the syslog, and its severity.

  Event	Description	Severity
  PGCPD startup	The pgcpd process just started up.	Notice
  PGCPD failure	The pgcpd state changed to failure.	Error
  PGCPD shutdown	The pgcpd process shut down.	Notice
  BGF startup	The BGF was out-of-service and is now in-service.	Notice
  BGF failure	The BGF was in-service and moved to out-of-service.	Error
  BGF graceful shutdown	The BGF was in-service and moved to out-of-service due to an administrative graceful shutdown.	Notice
  BGF forced shutdown	The BGF was in-service and moved to out-of-service due to an administrative forced shutdown.	Notice
  BGF disabled shutdown	The BGF was in-service and moved to out-of-service due to an administrative PIC disabled.	Notice
  BGF registered	BGF registered successfully with SPDF.	Notice
  BGF failed to register	BGF failed to register with SPDF, received reject or timeout.	Notice
  BGF network disconnection	The BGF was disconnected from the SPDF because of a network disruption.	Warning
  BGF reconnect	The BGF was registered with the SPDF, became disconnected, sent a DC/900 service-change to that PGC, and received a confirmation reply.	Notice
  BGF failed to reconnect	The BGF was registered with the SPDF, became disconnected, sent a DC/900 service-change to that PGC, and received a rejection or the request has timed out.	Warning
  Switchover	Switchover from active to backup Routing Engine.	Warning
  Inactivity timer expired	The PG notified the PGC that the keepalive timer expired.	Warning
  Media inactivity	No RTP media packets arrived so media is inactive.	Notice
  Remote source address change	Set source address from packet as gate remote source address.	Notice
  Manager received gate rate limit violation notification	The gate has a rate limit violation.	Notice

  [Multiplay Solutions, System Log Messages].

• Border signaling gateway statistics (M320, M120, and T640 platforms)—Enables you to view basic information about active and closed calls.

  The following commands display counters for active, completed, and failed calls by service point and egress or ingress:

  • show services border-signaling-gateway gateway gw calls
  • show services border-signaling-gateway gateway gw calls-failed

  The following commands provide more detailed information about active calls and enable you to use filters to control what information is displayed. Each command provides three options for the level of detail you want displayed: brief, summary, or detail.

  • show services border-signaling-gateway gateway gw by-request-uri request-uri
  • show services border-signaling-gateway gateway gw by-contact contact

  You can also clear all of the counters displayed by the show commands. To clear all border signaling gateway statistical counters, enter the clear services border-signaling-gateway statistics command. [CR System Basics and Services]

• Border signaling gateway trace options (M320, M120, and T640 platforms)—Enables you to configure trace options for extraction and storage of log information for border signaling gateway components. Options for each of the following components can be separately configured:

  • session-trace
  • sip-stack
  • signaling
  • framework
  • datastore
  • sbc-utlities
  You can also configure the trace file to which traced information is written.

  To configure trace options for border signaling gateway components, enter one or more of the following statements at the [edit services border-signaling-gateway gateway-name gw traceoptions flag] hierarchy level: session-trace, sip-stack, signaling, framework, datastore, and sbc-utilities.

  To configure trace file options, enter the following statements at the [edit services border-signaling-gateway gateway-name gw name traceoptions file] hierarchy level: filename, files, match, and size. [Multiplay Solutions, Services Interfaces, CR System Basics and Services].

• BSG SIP timers—The BSG software supports Timer C, an INVITE transaction timeout, to handle the case where the INVITE request never generates a final response and all resources are not released. The software supports Timer C as defined in RFC 3261, SIP: Session Initiation Protocol. To configure, include the timer-c statement at the [edit services border-signaling-gateway gateway gateway-name sip timers] hierarchy level. The BSG also supports a timer that controls the maximum time a call can be inactive (signaling inactive). To configure, include the maximum-call-duration statement at the [edit services border-signaling-gateway gateway gateway-name sip timers] hierarchy level. [Services Interfaces, Multiplay Solutions]

MPLS Applications

• LDP LSP action based on a BFD failure event—In the event of a BFD failure, JUNOS can now respond by removing the route corresponding to the LSP or the route's next hop from the appropriate routing tables (for example, inet.0 or inet.3, or both). LDP adds the route or the route's next hop back to the routing tables only after all the relevant BFD sessions have been restored. To enable this feature, include the failure-action remove-route statement at the [edit protocols ldp oam bfd-liveness-detection] hierarchy level. When this feature is enabled, any related event will be logged.

  When the failure-action remove-nexthop statement is configured at the [edit protocols ldp oam bfd-liveness-detection] hierarchy level, a BFD session down removes the corresponding next hop from the appropriate routing tables. The next hop is added back to the routing tables when the corresponding BFD sessions comes back up.

  You can optionally configure the holddown-interval statement at the [edit protocols ldp oam bfd-liveness-detection] hierarchy level. The holddown-interval statement allows you to specify the duration for which the BFD session should be continuously up before adding the route or next hop. Specifying a hold-down time of zero seconds implies that the route or next hop will be added as soon as the BFD session comes back up. The default value is zero. [MPLS]

• RSVP LSP Action Based on BFD Failures—When a BFD session for an RSVP LSP path goes down, you can configure the JUNOS software to teardown and resignal the LSP path. A standby LSP path could be configured to handle traffic while the primary LSP path is unavailable. The router can automatically recover from LSP failures that can be detected by BFD. By default, if a BFD session fails, the event is simply logged.

  To enable the JUNOS software to teardown an RSVP LSP path in the event of a BFD failure, include the failure-action statement at the [edit protocols mpls oam bfd-liveness-detetection] hierarchy level for all of the RSVP LSPs or at the [edit protocols mpls label-switched-path lsp-name oam bfd-liveness-detetection] hierarchy level for a specific RSVP LSP. You can also include the failure-action statement at the [edit protocols mpls label-switched path lsp-name primary path-name oam bfd-liveness-detetection] hierarchy level for a specific primary LSP path and at the [edit protocols mpls label-switched-path lsp-name secondary path-name oam bfd-liveness-detetection] hierarchy level for a specific secondary LSP path.

  You can configure either the teardown or make-before-break options. The teardown option causes the LSP path to be taken down and resignaled immediately. The make-before-break option causes the JUNOS software to attempt to re-signal the LSP in a make-before-break fashion before tearing down the old LSP. You can configure the teardown-timeout option to automatically teardown the LSP after the time period specified. [MPLS]

• Support for RSVP RRO node ID sub-object—To interoperate with other vendor's equipment, the JUNOS software now supports the RRO node ID sub-object for use in inter-AS link and node protection configurations. The RRO node ID sub-object is defined in RFC 4561. The node-id refers to the router address as defined in OSPF-TE or the traffic engineering router ID as defined in ISIS-TE. The address is expected to be constant for the duration of the LSP. A new flag node-id 0x20 has been added to the IPv4 and IPv6 sub-object in the RRO. It is recommended that a node set this flag when including the node ID sub-object. The node ID sub-object is essentially an IPv4 and IPv6 sub-object with this flag set. This functionality is enabled by default in JUNOS 9.4 and later. For compatibility, you might need to disable the node ID sub-object by including the no-node-id-subobject statement at the [edit protocols rsvp] hierarchy level. [MPLS]
• IP tunnels for MPLS traffic—You can now encapsulate the MPLS label stack for a packet with an IP header, making it possible to tunnel MPLS over networks that do not have MPLS enabled on their core routers. The JUNOS software supports both types of IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE. JUNOS can both push the IP-based encapsulation on MPLS packets at the ingress of an IP tunnel and pop the IP-based encapsulation at the egress. This feature is based on the functionality described in RFC 4023, Encapsulating MPLS in IP. For JUNOS Release 9.4, support was added for the M120 and M320 routers. To tunnel MPLS-labeled packets over a non-MPLS-enabled IP network, configure the family mpls statement at the [edit interfaces interface-name unit unit-number] hierarchy level. [MPLS]

MX-Series Layer 2

• Support for bridge protocol data unit (BPDU) protection on the MX-series routers—You can configure bridge protocol data unit (BPDU) protection to ignore BPDUs received on interfaces where none should be expected (for example, a LAN interface on a network edge with no other bridges present). If a BPDU is received on a blocked interface, the interface is disabled and the interface stops forwarding frames. By default, all BPDUs are accepted and processed on all interfaces. To configure edge port blocking for a particular STP family member, include the bpdu-block-on-edge statement for MSTP, RSTP, or VSTP at the [edit protocols <mstp | rstp | vstp>] hierarchy level. [MX L2]
• STP loop protection to improve the stability of Layer 2 networks—STP loop protection enhances the normal checks the STP performs on interfaces by performing a specified action when BPDUs are not received on a non-designated port interface. You can choose to block the interface or issue an alarm when BPDUs are not received on the port. By default (that is, without STP loop protection configured), an interface that stops receiving BPDUs will assume the designated port role and possibly result in an STP loop. You configure STP loop protection to prevent selected interfaces from interpreting the lack of BPDUs as a “false positive” for making the interface the designated port. STP loop protection is enabled for all STP instances on the interface, but blocks or alarms only those instances that stop receiving BPDUs. To configure STP loop protection, include the bpdu-timeout-action statement with either the block or alarm options for the STP interface at the [edit protocols xstp interface interface-name] hierarchy level. [MX L2]
• Support for applying port-mirroring firewall filter on MX-series routers—You can now apply a port-mirroring firewall filter to family ccc as well as bridge and vpls. If you apply a Layer 2 port-mirroring firewall filter to a logical interface, only packets received on that logical interface are mirrored. To apply a port-mirroring firewall filter to an input or output logical interface, configure the filter and then include the input or output statement at the [edit interfaces interface-name unit logical-unit-number family (bridge | ccc | vpls) filter] hierarchy level. [MX L2]
• Trunk port enhancements (MX-series routers only)—Provides support for various enhancements to the trunk port feature, including dynamic profiles for VPLS pseudowires, VLAN identifier translation, automatic bridge domain configuration, and the reporting of media access control (MAC) address moves.

  To associate a dynamic profile with VPLS, include the associate-profile profile-name statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level. You configure the dynamic profile by including the profile-name at the [edit dynamic-profiles] hierarchy level. To define the profile associated with VPLS pseudowires, include the interfaces $junos-interface-ifd-name unit $junos-underlying-interface-unit statement at the [edit dynamic-profiles profile-name] hierarchy level.

  Note: Before deleting a dynamic profile configured at the [edit dynamic-profiles] hierarchy level, you need to make sure that there are no associations between this dynamic profile and any VPLS pseudowires. You associate a dynamic profile to a VPLS pseudowire using the associate-profile statement. Failure to do so would corrupt the profiles database irrecoverably. The associate-profile statement can also be associated at the neighbor and mesh-group hierarchy levels for VPLS.

  The VLAN translation feature enables you to configure a trunk port interface to translate VLAN identifiers associated with the incoming interface into the VLAN identifier of the destination bridge domain at egress. Include the vlan-rewrite translate number number statement at the [edit interfaces family bridge] hierarchy level. The first number in the statement refers to the VLAN identifier on the incoming packet and the second number refers to the number to which the VLAN identifier on the outbound packet is translated.

  You can now configure multiple bridge domains using a single statement. Previously, you had to configure each bridge domain separately. Include the vlan-id-list vlan-id-range statement at the [edit bridge-domains bridge-domain-name] hierarchy level. The statement is supported only for bridge domains that include trunk port interfaces. In addition, Internet routing and bridging (IRB) interfaces are not supported with this configuration.

  When a MAC address appears on a different physical interface or within a different unit of the same physical interface and this behavior occurs frequently, it is considered a MAC move. You can now configure the router to report a MAC address move based on the following parameters: the number of times a MAC address move occurs, a specified period of time over which the MAC address move occurs, and the specified number of times a MAC address move occurs in one second.

  To configure reporting of a MAC address move if it occurs a specified number of times, include the threshold-count number statement at the [edit l2-learning global-mac-move] hierarchy level. To configure reporting of a MAC move if it occurs for a specified period of time, include the notification-time seconds statement at the [edit l2-learning global-mac-move] hierarchy level. To configure MAC reporting if it occurs at least a specified number of times in one second, include the threshold-time number statement at the [edit l2-learning global-mac-move] hierarchy level. Use the new show l2-learning mac-move-buffer command to view detailed information about MAC address moves. [Layer 2, Network Interfaces]

Network Management

• New enterprise-specific MIB to support TDM PICs—JUNOS software Release 9.4 introduces a new enterprise-specific MIB, jnx-pwtdm.mib, to extend MIB support to TDM PICs. jnx-pwtdm.mib is the Juniper Networks implementation of the SNMP standard managed objects for the TDM over packet-switched networks MIB (draft-ietf-pwe3-tdm-mib-08.txt).

  The enterprise-specific implementation of the MIB:

  • Uses a combination of pwType, pwName, and pwIndex as the index instead of the PWIndex used in the standard implementation.
  • Supports only a subset of the MIB objects in the standard version.
  • Provides only read-only access to the MIB objects.

  [Network Management]

• Configuration options to filter out interfaces from SNMP Get and GetNext operations—The JUNOS software now enables you to filter out information related to specific interfaces from the output of SNMP Get and GetNext requests performed on interface-related MIBs such as IF MIB, ATM MIB, RMON MIB, and the Juniper Networks enterprise-specific IF MIB. You can use the following options of the filter-interfaces statement at the [edit snmp] hierarchy level to specify interfaces that must be hidden from the SNMP Get and GetNext query outputs:

  • interfaces—Hides interfaces that match regular expressions specified using this option.
  • all-internal-interfaces—Hides the internal interfaces.
  However, note that these settings are limited to SNMP operations, and the users can continue to access information related to the interfaces (including those hidden using the filter-interfaces options) using the appropriate JUNOS CLI commands. [Network Management]

• MIBs support the JCS 1200 platform include:

  • nxBoxSystemDomainType—Used to determine the system domain type (RSD or PSD).
  • jnxFruType value of protectedSystemDomain(16)—Used to identify PSDs.
  • JnxChassisId—The definition now includes JCS chassis IDs.
  • jnxFruPsdAssignment—Added to the jnxFruTable to indicate the PSD to which an FPC or PIC has been assigned.
  • jnxBoxSystemDomainType—Used to determine the system domain type (RSD or PSD).
  [Network Management]

Routing Policy and Firewall Filters

• Aggregate policer support for different family address types configured on the same interface—Enables you to configure separate firewall filters for different family address types that share the same interface and to configure the same policer as an action for each filter. To configure the aggregate policer, include the logical-interface-policer statement at the [edit firewall policer policer-name] hierarchy level. To apply the policer as a firewall filter action, include the policer name statement at the [edit firewall family family-name filter filter-name term term-name then] hierarchy level. [Policy]
• Support for minimum policer bandwidth limit of 8000 bps (MX-series, M120, and M320 platforms only)—Enables you to specify a policer bandwidth limit as low as 8000 bits per second. On all other platforms, the minimum policer bandwidth remains 32,000 bits per second. Include the bandwidth-limit limit statement at the [edit firewall policer policer-name if-exceeding] hierarchy level. [Policy]
• Load balancing of Ethernet pseudowire and VPLS traffic (MX-series, M120, and M320 platforms only)—Enables you to configure per-packet load balancing for Ethernet pseudowire traffic based on IP information. Include the ether-pseudowire statement at the [edit forwarding-options hash-key family mpls payload] hierarchy level. You can also configure load balancing for Ethernet circuit cross-connect traffic (CCC) traffic. Include the ip statement at the [edit forwarding-options hash-key family mpls payload] hierarchy level. On the M120 and M320 routers only, you can also configure load balancing for VPLS traffic based on MPLS labels and IP information. All the following statements can be configured at the [edit forwarding-options hash-key family multiservice] hierarchy level. Include the label-1 statement to incorporate the first label into the hash key. Include the label-2 statement to incorporate the second label into the hash key. To incorporate the payload data into the hash key, include the payload statement. To include the IP address of the IPv4 payload into the hash key, include the payload ip statement. To include Layer 3 IP information only, include the payload ip layer-3-only statement.

  Note: VPLS load balancing is not supported on the MX-series.

  [Policy, VPNs]

• Support for two new loss priorities (M7i and M10i routers)—The new Enhanced CFEB (CFEB-E) supports two additional loss priorities of medium-high and medium-low, in addition to the existing high and low options. To configure these loss priorities, include the medium-high and medium-low statements at the [edit firewall filter filter-name] hierarchy level. [Policy]

VPNs

• The ping vpls instance command—Supported on T1600 routing platforms. [System Basics and Services Reference, VPNs, Feature Guide]
• 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 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]
• Integrated routing and bridging support for inter-AS VPLS between BGP-signaled VPLS and LDP-signaled VPLS (MX-series only)—Enables you to configure an integrated routing and bridging (IRB) interface on a router that functions as an autonomous system border router (ASBR) in an inter-AS VPLS environment between BGP-signaled VPLS and LDP-signaled VPLS. Previously, you could configure an IRB interface only on a provider edge (PE) router that did not function as an ASBR. To configure the IRB interface on the ASBR, include the routing-interface interface-name statement at the [edit routing-instances routing-instance-name] hierarchy level. To configure inter-AS VPLS on the ASBR, include the neighbor address statement for each PE router that participates in the mesh group at the [edit routing-instances routing-instance-name protocols vpls mesh-group group-name] hierarchy level. [VPNs]
• JUNOS software supports inter-AS VPLS and inter-AS L2VPNs using a VPLS control plane described in RFC 4364 as option (b) or method (b)—This feature requires IBGP peering between the PE routers, including AS border routers (ASBRs), within an AS and also requires EBGP peering between the ASBRs of different ASs. All inter-AS control and data plane operations are done by the ASBRs. No new configuration statements are introduced to support this feature. [Feature Guide, VPNs Configuration Guide]

High Availability

• Unified ISSU support for LACP on MX-series Ethernet Services routers—JUNOS software now extends the unified ISSU support to Link Aggregation Control Protocol process (LACPD) on MX-series devices. Unified ISSU support for LACPD ensures that the local and remote adjacencies are preserved during and after ISSU. [High Availability]
• Unified ISSU support for Enhanced Scaling—For FPC3 on the T640 and T1600 routing nodes.

• Graceful Routing Engine switchover support of dynamic DHCP subscriber access—Graceful Routing Engine switchover (GRES) currently supports most features associated directly with dynamic DHCP subscriber access. However, the following caveats apply to GRES when using a dynamic DHCP subscriber access configuration:

  • GRES does not support in-service software upgrade (ISSU) on systems that are running DHCP subscriber access.
  • Any partially complete subscriber secure policy activations that are lost during a failure are not recovered.
  • GRES does not support IP demux interfaces in a DHCP subscriber access configuration.
  • Using GRES while managing dynamic DHCP subscribers can result in delays in subscriber and service management features following a Routing Engine switchover. These delays vary depending on the size of your dynamic configuration.
  [JUNOS High Availability Configuration Guide]

• Unified ISSU support on additional PICs—JUNOS software now supports Unified ISSU on the following PICs:

  • 4-port DS3 PIC (model number PB-4DS3)
  • 4-port T1 PIC (model number PB-4T1-RJ48)
  • 4-port E3 PIC (model number PB-4E3-QPP)
  • 4-port E1 RJ48 PIC (model number PB-4E1-RJ48)
  • 4-port E1 Coaxial PIC (model number PB-4E1-COAX)
  The PICs are supported on M120, M320, T320, T640, and TX Matrix routing platforms. [High Availability]

Class of Service

• Replace the Type of Service (ToS) bit value on the M320 and T-series, M120, and M40e routing platforms with IQE PICs, or on any system with IQ2 or Enhanced IQ2 PICs—You can replace the Type of Service (ToS) bit value on the incoming packet header on a logical interface with a user-defined value. The new ToS value is used for all class-of-service processing and is applied before any other class-of-service or firewall treatment of the packet. The PIC uses the translation-table statement to determine the new ToS bit values. There are four supported types of translation tables: IP-precedence, IPv4 DSCP, IPv6 DSCP, and MPLS EXP. You can configure a maximum of eight tables for each supported type. If a translation table is enabled for a particular type of traffic, behavioral aggregate (BA) classification of same type must be configured for that logical interface. [Class-of-Service]
• Support for limiting the transmit rate of the MS-PIC logical interface on Type 1, 2, or 3 Multiservices PICs (MS-PICs)—You can limit the transmit rate of the MS-PIC logical interface (lsq-) in the same way as other types of queuing PICs. You can also assign a percentage of the excess bandwidth to MS-PIC logical interfaces. As with other types of PICs, the strict-high queue (voice) can starve low and medium priority queues. To prevent the strict-high queue from starving other queues, you should rate-limit the queue.

  To rate-limit the MS-PIC logical interface, include the transmit-rate statement with the rate-limit option at the [edit class-of-service schedulers scheduler-name] hierarchy level. To share excess bandwidth among MS-PIC logical interfaces, include the excess-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. Both of these statements apply to egress traffic only, and only for per-unit schedulers. There is no hierarchical or shared-scheduler support. You must still complete the configuration by configuring the scheduler map and applying it to the MS-PIC interface. [Class-of-Service]

• Support for applying a transmit rate limit to logical interfaces on Type 1, 2, or 3 Multiservices PICs—Typically, rate limits are used to prevent a strict-high queue (such as voice) from starving lower priority queues. You can only rate-limit one queue per logical interface. To apply a rate limit to a Multiservices PIC interface, configure the rate limit in a scheduler and apply the scheduler map to the Multiservices (lsq-) interface at the [edit class-of-service interfaces] hierarchy level. [Class-of-Service]
• Support for configuring BA classification based on the IEEE 802.1 bits for bridged Ethernet over ATM, PPP, and Frame Relay for VPLS applications on the M320 and M120 routers equipped with IQ2 PICs—You can configure BA classification based on the IEEE 802.1 bits for bridged Ethernet over ATM, PPP, and Frame Relay for VPLS applications. The BA classification is applied to the first (outer) tag when tagged frames are received. Untagged frames are bypassed and a value of 000 for the classification IEEE 802.1p bits is assumed. There is no support for CCC, and only port-mode VPLS is supported (in port-mode VPLS, only VLANs on a single physical port are included in the VPLS instance). There is no support for multilink PPP bonding with VPLS. For bridging over Frame Relay, only frames that do not preserve the frame check sequence (FCS) field are supported. Frames that preserve the FCS field are silently discarded. [VPNs, Class-of-Service]
• Support for configuring a ToS rewrite rule so that the DCSP bits of GRE packets are consistent with the service provider’s overall CoS policy—You can configure a ToS rewrite rule so the router sets the DCSP bits of GRE packets to be consistent with the service provider’s overall CoS policy. The bits are written at the ingress provider edge (PE) router. To configure the rewrite rules on the ingress PE, include the rewrite-rules statement at the [edit class-of-service] hierarchy level. You apply the rule to the proper ingress interface at the [edit class-of-service interfaces] hierarchy level to complete the configuration. The rewrite rules are applied to all unicast packets and multicast groups. You cannot configure different rewrite rules for different multicast groups. The use of DSCPv6 bits is not supported because IPv6 multicast is not supported. You cannot perform EXP marking in this fashion. [Class-of-Service]
• Extended CoS functionality (M7i and M10i routers)—The new Enhanced CFEB (CFEB-E) introduced for the M7i and M10i routers extends support for the following CoS features:
  • 8 CoS queues and 16 forwarding classes—The class statement has been introduced at the [edit class-of service forwarding-classes] hierarchy level to support this feature.
  • Hierarchical policing using Tricolor Marking trTCM and srTCM—The tri-color statement has been introduced at the [edit class-of-service] hierarchy level to support this feature.

    [Class-of-Service]

JUNOS XML API and Scripting

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

  Table 2: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 9.4

  Request Tag Element	CLI Command	Response Tag Element
  <clear-ancp-neighbor-connection>	clear ancp neighbor	<ancp-neighbor-information>
  <clear-appid-application-system-cache>	clear services application-identification application-system-cache	<clear-appid-application-system-cache- information>
  <clear-appid-counter>	clear services application-identification application-system-cache	<clear-appid-counter>
  <clear-helper-statistics-information>	clear helper statistics	NONE
  <clear-idp-application-system-cache>	clear security idp application- identification application-system-cache	<clear-idp-application-system-cache- information>
  <clear-idp-attack-table>	clear security idp attack table	<clear-idp-attack-table-information>
  <clear-idp-counters-by-counter-class>	clear security idp counters	<clear-idp-counters-by-counter-class- information>
  <clear-idp-ssl-session-cache-information>	clear security idp ssl-inspection session-id-cache	<clear-idp-ssl-session-cache-information>
  <clear-lacp-interface-statistics>	clear lacp statistics interfaces	NONE
  <clear-service-border-signaling-gateway- statistics>	clear services border-signaling-gateway statistics	<service-border-signaling-gateway-drain-information>
  <get-ancp-cos-information>	show ancp cos	<ancp-cos-information>
  <get-ancp-cos-last-update-information>	show ancp cos last-update	<ancp-cos-information>
  <get-ancp-cos-pending-information>	show ancp cos pending-update	<ancp-cos-information>
  <get-ancp-neighbor-information>	show ancp neighbor	<ancp-neighbor-information>
  <get-ancp-subscriber-information>	show ancp subscriber	<ancp-subscriber-information>
  <get-appid-application-system-cache>	show services application-identification application-system-cache	<appid-application-system-cache- information>
  <get-appid-counter>	show services application-identification counter	<appid-counter>
  <get-appid-package-version>	show services application-identification version	<appid-package-version>
  <get-global-mac-count>	show bridge mac-table global-count	NONE
  <get-header-redirect-set-statistics-information>	show services service-identification header-redirect statistics	<header-redirect-set-statistics- information>
  <get-helper-statistics-information>	show helper statistics	<helper-statistics-information>
  <get-idp-application-system-cache>	show security idp application- identification application-system-cache	<idp-application-system-cache- information>
  <get-idp-attack-table-information>	show security idp attack table	<idp-attack-table-information>
  <get-idp-counter-information>	show security idp counters	<idp-counter-information>
  <get-idp-memory-information>	show security idp memory	<idp-memory-information>
  <get-idp-security-package-information>	show security idp security-package- version	<idp-security-package-information>
  <get-idp-ssl-key-information>	show security idp ssl-inspection key	<idp-ssl-key-information>
  <get-idp-ssl-session-cache-information>	show security idp ssl-inspection session-id-cache	<get-idp-ssl-session-cache-information>
  <get-idp-status-information>	show security idp status	<idp-status-information>
  <get-lacp-interface-statistics>	show lacp statistics interfaces	NONE
  <get-mip-ha-interface-information>	show mobile-ip home-agent interface	<mip-ha-interface-information>
  <get-pim-mvpn-information>	show pim mvpn	<pim-mvpn-information>
  <get-rps-chassis-information>	show chassis redundant-power-supply	<rps-chassis-information>
  <get-rps-led-information>	show redundant-power-supply led	<rps-led-information>
  <get-rps-power-supply-information>	show redundant-power-supply power- supply	<rps-power-supply-information>
  <get-rps-status-information>	show redundant-power-supply status	<rps-status-information>
  <get-rps-version-information>	show redundant-power-supply version	<rps-version-information>
  <get-service-border-signaling-gateway- information-by-contact>	show services border-signaling-gateway information by-contact	<bsg-information-details>
  <get-service-border-signaling-gateway- information-by-request-uri>	show services border-signaling-gateway information by-request-uris	<bsg-information-details>
  <get-service-border-signaling-gateway- statistics-calls-failed>	show services border-signaling-gateway statistics calls-failed	<bsg-statistics-calls-failed-details>
  <get-service-border-signaling-gateway- statistics-calls>	show services border-signaling-gateway statistics calls	<bsg-statistics-calls-details>
  <network-services>	show chassis network-services	<network-services>
  <request-appid-application-package-download- version>	request services application-identification download version	<appid-download-status>
  <request-appid-application-package-download>	request services application-identification download	<appid-download-status>
  <request-idp-security-package-download- version>	request security idp security-package download version	<secpack-download-status>
  <request-idp-security-package-download>	request security idp security-package download	<secpack-download-status>
  <request-idp-security-package-install>	request security idp security-package install	<secpack-update-status>
  <request-idp-ssl-key-add>	request security idp ssl-inspection key add	<request-idp-ssl-key-add>
  <request-idp-ssl-key-delete>	request security idp ssl-inspection key delete	NONE

  [JUNOS XML API Operational Reference]

System Logging

• New and deprecated system log tags—The following sets of system log messages are new in this release:

  • ANCPD—This describes messages with the ANCPD prefix. They are generated by the access node control protocol process (ancpd), also known as layer 2 control (l2c), which works with a special internet group management protocol (igmp) session to collect outgoing interface (oif) mapping events in a scalable manner.
  • ANTISPAM—This describes messages with the ANTISPAM prefix. They are generated by the antispam process (antispamd) which decides what action should be performed when the device detects a message that it deems to be spam.
  • APPIDD—This describes messages with the APPIDD prefix. They are generated by application identification process (appid) which is a passive application protocol identification library that implements a state machine for efficient pattern matching of regex-like application content signatures.
  • APPPXY—This describes messages with the APPXY prefix. They are generated by the application proxy process (appxyd).
  • AV—This describes messages with the AV prefix. They are generated by the antivirus scanning process (avd).
  • CONTENT—This describes messages with the CONTENT prefix. They are generated by the content filtering process (contentd).
  • ESWD—This describes messages with the ESW prefix. They are generated by the Ethernet switching process (eswd) which maintains the timeout (lease time) value for each IP-address-MAC-address binding in its database.
  • IDP—This describes messages with the IDP prefix. They are generated by the Intrusion Detection and Prevention (IDP) process.
  • LPDFD—This describes messages with the LPDFD prefix. They are generated by the local policy decision function process (lpdfd). A policy decision function is a component in the IP multimedia subsystem which controls traffic entering the packet-switched network by allocating or denying IP bearer resources.
  • NEXTHOP—This describes messages with the NEXTHOP prefix. They are generated by the process which decides the next hop.
  • PGCPD—This describes messages with the PGCPD prefix. They are generated by the packet gateway control protocol process (pgcpd) which decodes packet gateway control protocol (pgcpd) messages that virtual packet gateways (vpg) receive from the packet gateway controller (pgc) and translates the pgcp messages to inter-process communication (ipc) messages.
  • PROFILER—This describes messages with the PROFILER prefix. They are generated by the profiler service process (profilerd).

  The following system log messages are new in this release:

  • DFCD_GENCFG_MALLOC_FAILED
  • DFCD_GENCFG_WRITE_FAILED
  • DFCD_LINH_MALLOC_FAILED
  • DFCD_LI_NEXT_HOP_ADD_FAILED
  • IDP_SESSION_LOG_EVENT
  • L2ALD_MAC_MOVE_NOTIFICATION
  • RPD_DYN_CFG_BUSY_SIGNAL_FAILED
  • RPD_DYN_CFG_GET_SES_STATE_FAILED
  • RPD_RT_CFG_CREATE_ENTRY_FAILED
  • RPD_RT_CFG_INVALID_VALUE

  The following system log messages are no longer documented:

  • L2ALD_FLOOD_NH_LIMIT_REACHED
  • RPD_TAI_P_TUNNEL_EXISTS

Related Topics

• Changes in Default Behavior and Syntax in JUNOS Software Release 9.4 for M-series, MX-series, and T-series Routing Platforms
• Issues in JUNOS Software Release 9.4 for M-series, MX-series, and T-series Routing Platforms
• Errata and Changes in Documentation for JUNOS Software Release 9.4 for M-series, MX-series, and T-series Routing Platforms
• Upgrade and Downgrade Instructions for JUNOS Software Release 9.4 for M-series, MX-series, and T-series Routing Platforms