Release 8.4 Features

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

Note: Starting with JUNOS Release 8.5, Juniper Networks will discontinue offering printed documentation for JUNOS software documentation, M-series and T-series hardware installation and PIC guides, and the JUNOScope Software User Guide. The JUNOScope software CD-ROMs will also be discontinued. The following model numbers will no longer be available: JUNOS-DOC-S JNCSP-DOC-S JNSCP-SOL-CFG JNSCP-SOL-IMS JNSCP-SOL-LKG JNSCP-SOL-SSL JNSCP-SOL-SWM DOC-M10i-HW-S DOC-M120-HW-S DOC-M160-HW-S DOC-M20-HW-S DOC-M320-HW-S DOC-M40e-HW-S DOC-M7i-HW-S DOC-MX960-HW-S DOC-T320-HW-S DOC-T640-HW-S DOC-TX-HW-S Juniper Networks will continue to include printed Quick Start Guides with router shipments and specific installation documentation will continue to be shipped with field-replaceable units (FRUs).

Hardware

• MX480 Ethernet services router—The new MX480 Ethernet services router is an Ethernet-optimized edge router that provides both switching and carrier-class Ethernet routing. The MX480 router has a capacity of up to 240 gigabits per second (Gbps) full duplex, high-density Ethernet interfaces, and high-capacity switching throughput. The MX480 router is used in configurations in which Ethernet ports, Layer 2 switches, Layer 2/Layer 3 switch routers, and Layer 3 routers with general-purpose applications are supported for core IP/MPLS routing, intra–point-of-presence (POP) IP-MPLS routing, and intra-POP Ethernet switching.

  The MX480 router includes the following hardware features:

  • Slots for one or two Switch Control Boards (SCBs) and up to six Dense Port Concentrators (DPCs), which provide Ethernet ports
  • Two types of DPCs: 40-port Gigabit Ethernet and 4-port 10-Gigabit Ethernet
  • Four Packet Forwarding Engines on each DPC
  • RE-S-1300 and RE-S-2000 Routing Engines

  The MX480 router supports the same software features as the MX960 Ethernet services router. The show chassis family of commands has been updated to provide information about MX480 routers.

• J2320 and J2350 Services Routers—The J2320 and J2350 Services Routers enhance and extend the capabilities of the existing J2300 Services Router. They provide significantly improved performance and a modular architecture for increased flexibility.

  The J2320 Services Router occupies 1 rack unit (RU), uses AC power, and provides three input/output (I/O) slots.

  The J2350 Services Router occupies 1.5 RUs, uses AC or DC power, and provides five I/O slots.

  The new Services Routers support the same JUNOS functionality as the J2300 Services Router, and offer the following additional features:

  • Removable Physical Interface Modules (PIMs).
  • Support for Gigabit Ethernet universal PIMS (uPIMs), Avaya voice over IP (VoIP) modules, and all other existing J-series PIMs (except the DS3 PIM, the E3 PIM, and the Gigabit Ethernet ePIM).
  • Built-in 4-port Gigabit Ethernet interface, which serves as the primary LAN link connection. Each port supports link speeds of 10, 100, or 1000 megabits per second (Mbps).
  • An optional Crypto Accelerator Module that enhances performance of cryptographic algorithms used in IP Security (IPSec) services. A Services Router without the Crypto Accelerator Module uses the existing software-based OpenSSL implementation of IPSec algorithms.
  • A time-division multiplexing (TDM) midplane to support VoIP services.

  [J-series Getting Started]

• Enhanced III FPCs (Type 1, 2, and 3) for the M320 router—New Flexible PIC Concentrators (FPCs) support additional class-of-service (CoS) features on the M320 router. There are currently no configuration rules that limit the combinations of Physical Interface Cards (PICs) that can be installed in the Enhanced III FPCs. [M320 PIC Guide, FPC Installation Instructions, CoS, Network Interfaces]

  Note: Please contact Juniper Networks customer support before installing Enhanced III FPCs and other FPC types simultaneously in an M320 router. [PR/233908]

• New Multi-Rate SONET/SDH PICs with SFP (M-series and T-series routing platforms)—The new Multi-Rate SONET/SDH PICs use next-generation application-specific integrated circuits (ASICs) and field-programmable gate arrays (FPGAs). Interfaces can be concatenated or nonconcatenated and support small form-factor pluggable (SFP) optics. The new SONET/SDH PIC types are 2-port and 4-port OC3/STM1, 1-port and 4-port OC12/STM4, and 1-port OC48/STM16. [PIC Guides, Network Interfaces, Interfaces Command Reference]
• 1-port Gigabit Ethernet uPIM with SFP (J2320, J2350, J4350, and J6350 Services Routers)—A new 1-port Gigabit Ethernet uPIM provides SFP connectors for use with a variety of copper and optical interfaces. The uPIM can be installed in either high-speed or regular slots on the J2320, J2350, J4350, and J6350 Services Routers. [J-series Getting Started, J-series Basic Configuration]
• Lower DSP-capacity Avaya TGM550 modules for VoIP services (J-series Services Routers)—For VoIP deployments that require fewer voice channels, J-series Services Routers now support Avaya TGM550 Terminal Gateway Modules (TGMs) with low-density digital signal processors (DSPs) that provide 10 or 20 channels. [J-series Basic Configuration]

• Support for high-density TIMs (J-series Services Routers)—J-series Services Routers now support the following high-density Avaya Telephony Interface Modules (TIMs) for VoIP service:

  • Avaya TIM508—Has eight analog telephone ports, which you can configure as direct inward dialing (DID) trunk ports.
  • Avaya TIM516—Has 16 analog telephone ports, 8 of which you can configure as DID trunk ports.
  • Avaya TIM518—Has eight analog telephone ports and eight analog trunk ports. You can configure some or all of the analog telephone (LINE) ports as analog DID trunk ports.
  [J-series Basic Configuration]
• Power management (J-series Services Routers)—On J-series Services Routers, the system monitors the PIMs and verifies that a newly inserted PIM falls within the power capacity of the chassis. Command-line interface (CLI) commands allow the user to choose which PIM to turn off if power capacity is exceeded. [J-series Getting Started]

User Interface and Configuration

• Device-initiated SSH connection (outbound SSH)—Enables you to allow devices to initiate SSH connections. Previously, only client applications could initiate SSH connections. This feature is useful if the device is located behind a firewall using Network Address Translation (NAT) and the device must make the connection to the application. To enable device-initiated SSH connections, include the outbound-ssh statement at the [edit system services] hierarchy level. [System Basics]
• Simplified command expressions for RADIUS and TACACS+ servers—Expressions used in RADIUS and TACACS+ server configuration files to grant and deny user permissions have been simplified. Instead of a single expression with a list of pipe-separated commands (for example, allow-commands=command1 | command2 | ... | commandN), you can specify each command as a separate expression. The new syntax is valid for the following statements in the RADIUS or TACACS+ server configuration file: allow-commands, allow-configuration, deny-commands, deny-configuration, and user-permissions. [System Basics]

• Additional commands for Avaya VoIP service (J-series Services Routers)—The following operational mode commands provide improved access to and detailed information about Avaya modules for VoIP service:

  • request tgm login fpc slot-number user username—Enables users to log in to the TGM550 TGM.
  • show tgm fpc slot-number dsp-capacity—Reports the number of voice channels that the TGM550 module supports (10, 20, or 80). The number depends on the capacity of the DSPs on the TGM.
  • show tgm telephony-interface-module status—Displays the status of TIMs.
  [J-series Basic Configuration, System Basics and Services Command Reference]

Interfaces and Chassis

• VRRP with IPv6—Enables the routing platform to use Virtual Router Redundancy Protocol (VRRP) with interfaces that have Internet Protocol version 6 (IPv6) addresses. The JUNOS software implementation is based on Internet draft draft-ietf-vrrp-ipv6-spec-07 (Virtual Router Redundancy Protocol for IPv6), RFC 2461 (Neighbor Discovery for IPv6), and RFC 2338 (Virtual Router Redundancy Protocol). [Network Interfaces]
• Extended support for operational mode commands (MX-series Ethernet services routers)—The following commands have been extended to support MX-series routers: show chassis hardware, show chassis fpc, show chassis fpc pic-status, show chassis fabric (fpcs | plane | summary), show interfaces, and show interfaces mac-database. [Interfaces Command Reference]
• IEEE 802.1ag CFM for Ethernet OAM (M320, MX-series, and T-series routing platforms)—Enables you to use IEEE 802.1ag connectivity-fault management (CFM) on Gigabit Ethernet and 10-Gigabit Ethernet interfaces to monitor service instances in an Ethernet network. CFM maintenance endpoints (MEPs) are actively managed entities associated with a specific service instance that generate and receive CFM frames and track response messages. As a requirement for CFM to work, you must enable distributed periodic packet management (PPM) by including the delegate-processing statement at the [edit routing-options ppm] hierarchy level. CFM supports a continuity-check protocol. To configure CFM, include statements at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. [Network Interfaces]
• IEEE 802.3ah LFM for Ethernet OAM on more routing platforms—Extends IEEE 802.3ah link-fault management (LFM) functionality for Ethernet Operation, Administration, and Management (OAM) on Fast Ethernet and Gigabit Ethernet interfaces to all M-series routers. LFM provides peer discovery and link monitoring, remote fault signaling and detection, and remote loopback. You can also configure protocol data unit (PDU) thresholds for each interface. To configure LFM, include statements at the [edit protocols oam ethernet link-fault-management] hierarchy level. [Network Interfaces]
• Ethernet Layer 2 switching on uPIMs (J2320, J2350, J4350, and J6350 Services Routers)—Enables 6-port, 8-port, and 16-port Gigabit Ethernet uPIMs to forward traffic at both Open Systems Interconnection (OSI) Layer 2 (switching) and OSI Layer 3 (routing). You can configure a uPIM to operate in one of two modes: routing mode (the default) or switching mode. Routing mode provides traditional routing services.

  Switching mode provides the following features:

  • Layer 3 forwarding—Routing of traffic destined for WAN interfaces—interfaces on other PIMs installed in the chassis
  • Layer 2 forwarding—Switching of intra-LAN traffic from one host on the LAN to another LAN host—one port on a uPIM to another port on the same uPIM

  To enable routing or switching mode, include the routing or switching statement at the [edit chassis fpc fpc-slot-number pic pic-slot-number ethernet pic-mode] hierarchy level. To view Layer 2 switching statistics, issue the show interfaces interface-name switch-port command. To clear Layer 2 switching statistics, issue the clear interfaces statistics interface-name switch-port command. [J-series Basic Configuration, Network Interfaces, System Basics, Interfaces Command Reference]

  Note: Gigabit Ethernet uPIMs enabled for switching mode do not provide virtual LAN (VLAN) support or spanning-tree support.

• New DHCP server option (J-series Services Routers)—Allows you to specify the next server used for DHCP communication after a boot client establishes initial contact. Use of this feature inserts an IP address into the siaddr field of a DHCP protocol packet. To specify the next DHCP server, include the next-server statement at the [edit system services dhcp], [edit system services dhcp pool pool-id], or [edit system services dhcp static-binding mac-address] hierarchy level. [J-series Basic Configuration]
• Extended support for CCC and VPLS on aggregated Ethernet interfaces (Gigabit Ethernet IQ2 PICs)—Circuit cross-connect (CCC) and virtual private LAN service (VPLS) are now supported on aggregated Ethernet interfaces when you configure the interfaces on Gigabit Ethernet IQ2 PICs. [VPNs, Feature Guide]

Services Applications

• Support for DFC and passive flow monitoring on MultiServices 400 PICs—Dynamic flow capture (DFC) and passive flow monitoring are now available on MultiServices 400 PICs. These features are configured the same way as on equivalent Monitoring Services PICs; there are no new statements or commands. [Services Interfaces, Feature Guide]
• New link services operational command and event reporting—Adds support for the show services link-services cpu-usage command, which displays CPU usage for Link Services IQ (LSQ) CPUs on Adaptive Services and MultiServices PICs. In addition, two new event logs are added for bundle down and redundant LSQ switchover events. [Services Interfaces, System Log Messages]
• Support for PGCP—Enables you to configure Packet Gateway Control Protocol (PGCP) options on M-series and T-series routing platforms and to enable the routing platform to function as a packet gateway. The packet gateway interacts with a packet gateway controller to enable calls between VoIP devices in the network. PGCP is supported on all MultiServices PICs.

  To configure PGCP, include statements at the [edit services pgcp] hierarchy level. To view status and statistics for the PGCP configuration, issue the new show services pgcp active-configuration, show services pgcp gate, show services pgcp gates, show services pgcp statistics, show services pgcp termination, and show services pgcp terminations commands. [Services Interfaces, System Basics and Services Command Reference]

  Note: Please contact Juniper Networks customer support before implementing PGCP. [PR/237140]

• Support for NAT traversal for VoIP—Enables you to configure destination port translation for packet gateway flows. You apply twice NAT for VoIP packets (media stream only) as they traverse through the gates created by PGCP to achieve security between realms, or service providers. To apply twice NAT, the packet gateway instructs the PIC to allocate a specified number of NAT addresses and ports from a given PGCP NAT pool on a per-gate basis. The packet gateway specifies which NAT pool to use.

  To enable combined voice and video flows on the AS PIC, include the ports-per-session statement at the new [edit services pgcp gateway gateway-name] hierarchy level. Voice services require two ports to support Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) flows; video services require two additional ports to support Rapid Spanning Tree Protocol (RSTP) and forwarding equivalence class (FEC) flows. The default value is 2 ports.

  The packet gateway monitors traffic that is flowing through a gate. If no IP packets are received during a configured amount of time, the packet gateway notifies the packet gateway controller. To configure settings that control packet inactivity for gates, include the following statements at the [edit services pgcp gateway gateway-name] hierarchy level:

  • gate-inactivity-delay sets the delay after a gate is created before packet inactivity detection begins.
  • gate-inactivity-duration sets the duration of packet inactivity detection.
  • cleanup-timeout configures the media gateway controller (MGC) to clean the gate state when the configured duration expires.

  In the current release, you can also configure application layer gateways (ALGs) for Internet Control Message Protocol (ICMP) and traceroute under stateful firewall, NAT, or CoS rules when twice NAT is configured in the same service set. [Services Interfaces]

• Support for bidirectional NAT (J-series Services Routers only)—Enables you to specify the NAT type of a particular term in a NAT rule as either traditional (symmetric) NAT or full-cone NAT, in which all requests from the same internal IP address are mapped to the same external IP address. Port mapping is also supported, but not required. To configure this feature, include the nat-type statement at the [edit services nat rule rule-name term term-name] hierarchy level. By default, symmetric NAT is supported. [Services Interfaces]

Layer 2 Ethernet Services

• Bridge domains and virtual switching (MX-series routers)—Add support for Layer 2 bridge domains and virtual switches. Like a VLAN, a bridge domain spans one or more ports on multiple devices and can be created within a user-created virtual switch or the default virtual switch. VLANs can be switched based on zero or one VLAN identifier, or tunneled using a stacked VLAN identifier. VLAN identifiers can be exchanged (swapped), added (pushed), or removed (popped) at the ingress or egress interface. The VLAN Tag Protocol Identifier (TPID) field can also be manipulated. Additionally, a virtual switch can run one of the spanning-tree protocols (see the subsequent item titled “Spanning-tree protocols support for Layer 2 bridging and VPLS”) and spanning-tree bridge protocol data units (BPDUs) can be tunneled.

  To create a bridge domain, specify its name at the [edit bridge-domains] hierarchy level. To include an interface in the bridge domain, include the interface interface-name statement. You can also specify a VLAN identifier for each bridge domain by including the vlan-id number statement. To specify dual VLAN tags, include the vlan-tags outer number inner number statement. You can specify either the vlan-tags or the vlan-id statement for a bridge domain, not both. You can also group one or more bridge domains in a virtual switch at the [edit routing-instances routing-instance-name] hierarchy level. [Network Interfaces, Routing, Interfaces Command Reference, Routing Protocols and Policies Command Reference]

• Integrated routing and bridging (MX-series routers)—Adds support for integrated routing and bridging (IRB), which enables routing of Layer 3 traffic between a bridge domain or VPLS routing instance and another routed interface. An IRB virtual interface is used to interconnect the target Layer 3 interface and the VPLS routing instance or bridge domain. Routing of IP version 4 (IPv4), IPv6, and International Organization for Standardization (ISO) packets is supported. Packets that are destined for the router’s media access control (MAC) address are delivered to the IRB interface. IRB handles Layer 3 control packets for protocols such as Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), OSPF, and RIP. [Network Interfaces, Routing, Feature Guide, Interfaces Command Reference]
• Spanning-tree protocols support for Layer 2 bridging and VPLS (MX-series routers)—As part of the new Layer 2 bridging and IRB feature, the JUNOS software includes support for spanning-tree protocols to prevent forwarding loops: Spanning Tree Protocol (STP), Rapid STP (RSTP), and Multiple STP (MSTP). Each of these protocols creates a tree topology in which there is only one active Layer 2 data path between any two stations. To configure RSTP or MSTP, include the rstp or mstp statement at the [edit protocols] or [edit routing-instances routing-instance-name protocols] hierarchy level. To configure STP, include the force-version stp statement at the [edit protocols rstp] or [edit routing-instances instance-name protocols rstp] hierarchy level.

  To run STP for provider edge to customer edge (PE to CE) VPLS interfaces, configure a routing instance with the new Layer 2 control instance type and enable STP within this control instance. You can use the Layer 2 control instance only if your VPLS domain is connected to a single PE router. To configure a Layer 2 control instance, include the layer2-control statement at the [edit routing-instances instance-name instance-type] hierarchy level. [Routing, Feature Guide, Network Interfaces]

• Nonstop bridging for spanning-tree protocols (MX-series routers)—Nonstop bridging prevents data traffic loss during Routing Engine switchovers. For spanning-tree protocols, such as STP, RSTP, and MSTP, nonstop bridging replicates the protocol state on the backup Routing Engine. When a Routing Engine switchover occurs, the replicated protocol state is used to construct the spanning tree. You must configure graceful Routing Engine switchover as a prerequisite to using nonstop bridging. To enable nonstop bridging, include the nonstop-bridging statement at the [edit protocols layer2-control] hierarchy level. [Routing, Feature Guide]

  Note: Nonstop bridging does not work as expected if the spanning-tree environment experiences a topology change during the switchover.

• Layer 2 forwarding support for bridging and VPLS (MX-series routers)—As part of the new support for Layer 2 bridging and IRB, the JUNOS software enables you to configure various Layer 2 forwarding properties. These include disabling MAC address learning, adding static MAC entries, limiting the number of MAC entries learned by an interface, modifying the timeout interval for MAC entries, and enabling MAC accounting.

  To configure the various Layer 2 forwarding features, include the following statements in the configuration. Several of the statements can be included at multiple hierarchy levels, enabling you to control the scope at which the statement applies (for example, the entire router, a bridge domain, a VPLS routing instance, or a single interface). For information about the hierarchy levels, see the documentation.

  • To disable MAC address learning (which is enabled by default), include the no-mac-learning statement at the appropriate hierarchy level.
  • To add a static MAC address entry, include the static-mac mac-address statement at the appropriate hierarchy level.
  • To limit the number of MAC addresses learned from a domain, routing instance, or interface, include the interface-mac-limit limit statement at the appropriate hierarchy level. To specify that packets be discarded when the limit is reached (instead of being forwarded) include the packet-action drop statement at the appropriate hierarchy level.
  • To limit the number of MAC addresses learned on the entire router, include the global-mac-limit limit statement at the [edit protocols l2-learning] hierarchy level.
  • To modify the timeout interval for all MAC entries on the routing platform, include the mac-table-aging-time seconds statement at the [edit protocols l2-learning] hierarchy level.
  • To enable MAC accounting (which is disabled by default), include the mac-statistics statement at the appropriate hierarchy level.

  The following are new Layer 2 forwarding operational mode commands:

  • clear bridge mac-table—Delete all or specified MAC address table entries.
  • clear vpls mac-table—Delete all or specified MAC address table entries in a VPLS domain.
  • show bridge mac-table—Display information about all MAC address table entries or specified entries.
  • show vpls mac-table—Display information about all MAC address table entries or specified entries in a VPLS domain.

  [Routing, Routing Protocols and Policies Command Reference]

• New firewall filter match conditions for Layer 2 bridging and VPLS (MX-series routers)—As part of the support for Layer 2 bridging and IRB, the JUNOS software adds support for the following new firewall filter match conditions for Layer 2 services and VPLS:
  • learn-vlan-id
  • learn-vlan-id-except
  • traffic-type (broadcast | multicast | unknown-unicast | known-unicast)
  • traffic-type-except
  • user-vlan-id
  • user-vlan-id-except

  Firewall filters for Layer 2 bridging and VPLS also support the following existing match conditions:

  • destination-mac-address
  • ether-type
  • interface-group
  • source-mac-address
  • vlan-ether-type

  To configure firewall filters for bridge domains, specify the conditions that a packet must match by including statements at the [edit firewall family bridge filter filter-name term term-name from] hierarchy level. To apply the filter to a bridge domain, include the input filter-name statement at the [edit bridge-domains bridge-domain-name forwarding-options filter] hierarchy level.

  To configure firewall filters for VPLS routing instances, specify the conditions that a packet must match by including statements at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level. To apply the filter to a VPLS routing instance, include the input filter-name statement at [edit routing-instances routing-instance-name forwarding-options family vpls filter] hierarchy level. [Policy]

• Setting the network services mode (MX-series routers)—Enables you to set the network services mode on the router to either Ethernet-Services mode (for processing Layer 2 traffic only) or IP-Services mode (for processing Layer 2 and Layer 3 traffic). The two modes differ in which DPCs and software functionality they support. To set the network services mode, include the network-services (ethernet | ip) statement at the [edit chassis] hierarchy level. [System Basics]

Routing Protocols

• Nonstop routing for BGP, IS-IS, OSPF, OSPFv3, and LDP (M10i, M20, M40e, M320, and T-series routing platforms)—Enables routing platforms containing dual Routing Engines to preserve routing information on the backup Routing Engine. When a switchover to the backup Routing Engine occurs, neighboring nodes are unaware of the change and continue sending packets to the routing platform. Nonstop routing (NSR) uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information. However, nonstop routing also runs the routing protocol process (rpd) on the backup Routing Engine. By saving this additional routing information, nonstop routing is self-contained and does not rely on helper routers to assist the routing platform as it recovers. To enable nonstop routing, you must configure GRES as a prerequisite. To configure GRES, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level. To configure nonstop routing, include the nonstop-routing statement at the [edit routing-options] hierarchy level. To configure nonstop routing trace options flags for BGP, IS-IS, OSPF, OSPFv3, and LDP, include the nsr-synchronization statement at the [edit protocols protocol-name traceoptions flag] hierarchy level and specify the detail, disable, receive, or send option.

  The following limitations and requirements apply to nonstop routing: You cannot enable nonstop routing and graceful restart protocol extensions simultaneously. To ensure proper operation, include either the nonstop-routing statement or the graceful-restart statement at the [edit routing-options] hierarchy level, but not both statements at the same time. If you modify the configuration after you enable nonstop routing, you must issue the commit synchronize command on the master Routing Engine to synchronize both Routing Engines. If you issue this command on the backup Routing Engine, the JUNOS system software displays a warning and commits the candidate configuration. Please contact Juniper Networks customer support before implementing nonstop routing for BGP. [PR/233935]

  [High Availability, Routing, System Basics]

• Extended platform support for BFD (J-series Services Routers)—You can now configure bidirectional forwarding detection (BFD) timers on J-series Services Routers. To configure BFD timers for a static route, include the bfd-liveness-detection statement at the [edit routing-options static route] hierarchy level. You can also configure BFD timers for BGP, IS-IS, OSPF, and RIP by including the bfd-liveness-detection statement at the [edit protocols protocol-name] hierarchy level. [Routing]

MPLS Applications

• Expanded support for LSP traceroute—Enables you to run a periodic ingress trace for MPLS LSPs that use LDP for signaling. This feature provides the ability to trace all paths in a specified forwarding equivalence class (FEC). The frequency of the trace is configurable. The FEC topology information is stored in a database accessible from the CLI. Topology changes do not automatically trigger an LSP trace. You can also manually initiate a trace for an FEC. If the FEC is currently in the database, the database contents can be updated with the results. The periodic LDP OAM configuration now includes statements that allow you to configure the periodic traceroute parameters. These parameters apply to all FECs specified in the ldp oam statement. To configure a periodic trace of MPLS LSPs signaled with LDP, include the periodic-traceroute statement at the [edit protocols ldp oam fec fec-address] hierarchy level. You can also configure the following statements at the [edit protocols ldp oam fec fec-address periodic-traceroute] hierarchy level: frequency, wait, retries, ttl, exp, source, paths, and fanout. To log the results of the MPLS LSP trace, include the traceoptions statement at the [edit protocols mpls oam] hierarchy level. You can include the following options at the [edit protocols mpls oam traceoptions flag] hierarchy level: all, configuration, database, network, rpc-packet-details, and traceroute. [MPLS Applications]

Routing Policy and Firewall Filters

• DHCP state persistence (M-series, MX-series, and T-series routing platforms)—Enables the extended Dynamic Host Configuration Protocol (DHCP) relay agent to maintain the state of active DHCP client leases in persistent storage and to recover this state if the DHCP relay agent process fails or is manually restarted, or if you manually reboot (gracefully shut down) the router. This feature prevents the loss of active DHCP clients in either of these circumstances. If a power failure occurs or if the kernel stops operating on a single Routing Engine, however, the state of active DHCP client leases is lost. DHCP state persistence is automatically enabled when you configure the extended DHCP relay agent on the router. To configure the extended DHCP relay agent, include the dhcp-relay statement at any of the following hierarchy levels:
  • [edit forwarding-options]
  • [edit logical-routers logical-router-name forwarding-options]
  • [edit logical-routers logical-router-name routing-instances instance-name forwarding-options]
  • [edit routing-instances instance-name forwarding-options]

  The DHCP relay agent records in persistent storage only those DHCP clients that are fully bound, which means that they currently have an active lease on an IP address from a DHCP server. DHCP clients in a renewal or rebind state are considered to be fully bound, and their state is also maintained in persistent storage. When a DHCP client lease expires or the client is released, the DHCP relay agent removes the client state from persistent storage. [Policy]

VPNs

• Multiprotocol BGP-based multicast VPN—Adds support for a new type of multicast virtual private network (VPN) that uses multiprotocol BGP and MPLS. A multicast VPN is defined by a set of sender sites and a set of receiver sites; a site can belong to both sets of sites and can both originate and receive multicast traffic. Sites within a given multicast VPN can be either within the same or different networks, so the multicast VPN can be either an intranet or an extranet. A given site can be in more than one multicast VPN, meaning that multicast VPNs can overlap. Not all sites within a multicast VPN must be connected to the same service provider. Multicast VPNs are defined by a set of administrative policies, which delineate the sets of sender sites and receivers. Multicast VPN customers establish the policies, but multicast VPN service providers implement them by using their existing BGP and MPLS VPN infrastructure. To configure multicast VPNs, include the mvpn statement in the configuration for a routing instance at the [edit routing-instances routing-instance-name protocols] hierarchy level.

  [VPNs, Multicast, Feature Guide, Routing]

• LDP-based VPLS—Enables you to use LDP as the signaling protocol for VPLS; previously, only BGP could be used for VPLS signaling. To enable VPLS signaling using LDP, include the vpls-id, neighbor, and interface statements at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level. The vpls-id statement specifies the virtual circuit identifier used for the VPLS routing instance. The neighbor statement specifies all of the other PE routers that participate in the VPLS domain. The interface statement specifies the interfaces that are a part of the VPLS routing instance. The encapsulation signaled for LDP is Ethernet for both Ethernet and Ethernet tagged modes. A mixture of Ethernet and VLAN encapsulation is allowed on local customer edge (CE) facing interfaces Also, only one mode of signaling is supported for each routing instance, either LDP or BGP. [VPNs, Feature Guide]
• Multipath load balancing for EBGP and IBGP VPNs—Enables you to select EBGP and IBGP paths as candidates for multipath. This can be useful in the context of VPN configurations. This feature is an extension of protocol independent multipath and is configurable only within a routing instance. It can be useful in the context of VPN configurations in which the best path might have been advertised in either EBGP or IBGP. To enable this feature, include the vpn-unequal-cost statement with the equal-external-internal option at the [edit routing-instances routing-instance-name routing-options multipath] hierarchy level. [VPNs]

Class of Service

• Classification of control-plane traffic—Enables you to specify the queue for all packets generated by the Routing Engine, such as routing protocol-related or Layer 2-related traffic. Transit traffic is unaffected. The queue must already be correctly configured. You can also specify the DiffServ code point (DSCP) bits for the type-of-service (ToS) field in the generated packets. To specify the queue to use, include the host-outbound-traffic statement at the [edit class-of-service] hierarchy level. If you do not include the statement, all outbound packets generated by the Routing Engine use queue 3 and the DSCP bits are set to 0. The MPLS EXP and IEEE 802.1p bits remain unchanged. [CoS]
• CoS for MX-series routers—Adds support for CoS on MX-series routers. Classification and rewrite is supported for IRB and Layer 2 interfaces, in addition to other Layer 3 interfaces. Port level queuing, scheduling, and shaping are supported for this release. [CoS]
• Independent values for DSCP and EXP bits (M120 routers, M320 routers with Enhanced III FPCs, and MX-series routers)—Enables you to set the DSCP bits in the IPv4 header independently of the EXP bits in the MPLS header. The values are set at the ingress MPLS tunnel node. To configure this feature, include the protocol mpls statement at the [edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules (dscp | inet-precedence) rewrite-name] hierarchy level. [CoS]
• Extended support for trTCM (MX-series routers)—Extends support for two-rate tricolor marking (trTCM) on MX-series routers, which do not support four loss-preference values. [CoS]
• CoS with mixed FPC types (M320 routers)—The Enhanced III FPCs introduced for the M320 router with JUNOS Release 8.4 provide different CoS functionality than the standard and Enhanced II M320 FPCs. You can mix the FPC types in a single M320 router, but CoS processing of packets traveling between an Enhanced III FPC and another FPC type on the router differs from the processing of packets traveling between two FPCs of the same type. [CoS]
• L2TP policing (Gigabit Ethernet IQ2 PICs)—Allows policing for multiple Layer 2 Tunneling Protocol (L2TP) sessions on a single Gigabit Ethernet IQ2 interface. Each session can have four to eight classes of traffic (or queues), and two classes can be assigned their own policer. You can use this feature to police different types of L2TP sessions (such as voice and data). [CoS]

Network Management

• Enhanced SNMP support for logical routers and routing instances—The SNMP manager for a routing instance can now request and manage SNMP data for that routing instance and any other routing instances in the same logical router, but not for routing instances in other logical routers. As in previous releases, by default the SNMP manager for the default routing instance in the main router (inet.0) can access SNMP data from all routing instances. To restrict that manager’s access to the default routing instance only, include the routing-instance-access statement at the [edit snmp] hierarchy level.

  You can also perform the following actions:

  • Assign clients of a configured SNMP community to a routing instance and logical router other than the default routing instance in the main router. Include the routing-instances routing-instance-name clients statement at the [edit snmp community community-name] hierarchy level.
  • Specify whether or not SNMP queries are allowed, either for a specific routing instance or for all routing instances in a logical router. Include the routing-instance-access access-list statement at the [edit snmp] hierarchy level.
  • Specify that a trap destination that has an associated routing instance receive traps only from that routing instance and other routing instances in the same logical router (instead of receiving all traps). Include the logical-router-trap-filter statement at the [edit snmp] hierarchy level. Trap destinations in the main router continue to receive all traps.

  [Network Management, Feature Guide]

• SNMP support for spanning-tree protocols (MX-series routers)—Support for the following standard and Juniper Networks enterprise MIBs has been added:
  • RFC 4188, Definitions of Managed Objects for Bridges—Supports IEEE 802.1d STP (1998) only.
  • RFC 4318, Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol—Supports IEEE 802.1t and 802.1w extensions for RSTP.
  • Multiple Instance Virtual Switch MIB (mib-jnx-mimstp.txt)—Supports IEEE 802.1s (2002) for MSTP.

  [Network Management]

• Generating SNMP traps when MAC address table is full (MX-series routers)—On MX-series routers, the enterprise-specific Ethernet MAC MIB (mib-jnx-mac.txt) generates SNMP traps when the limits set by the global-mac-limit, interface-mac-limit, and mac-table-size statements are exceeded, which is beneficial for both regular LANs and VPLS networks. For more information about these statements, see the preceding section titled “Layer 2 forwarding support for bridging and VPLS” and the documentation. [Network Management]

• SNMP support for monitoring L2TP tunneling and sessions—An enterprise-specific MIB (mib-jnx-l2tp.txt) enables you to use SNMP to monitor L2TP tunneling and sessions. The L2TP MIB provides statistics and status for the following:

  • L2TP system-wide performance
  • L2TP tunnel groups
  • L2TP tunnels
  • L2TP sessions
  • L2TP Multilink Point-to-Point Protocol (MLPPP) sessions
  [Network Management]

• SNMP support for RPM—An enterprise-specific real-time performance monitoring (RPM) MIB (mib-jnx-rpm.txt) enables you to maintain real-time performance-related data with SNMP and access jitter measurements and calculations through SNMP MIB objects. The RPM MIB provides the following information:

  • Measurements from the latest RPM probe sample
  • A summary of the results for a specific RPM entry
  • A set of calculated values for each RPM entry, for each collection of probes maintained within that entry, and for each supported measurement set within that collection of probes
  • Measurements for each sample stored in the history table of RPM probe entries
  • Historical data for each collection of probes within each RPM entry
  • A set of calculated values for a number of historical RPM entries, for each collection of probes maintained within an entry, and for each supported calculated type within the collection of probes
  [Network Management]

JUNOScope

• URL interface for application integration with JUNOScope—You can now launch JUNOScope from an external Web application. Using an addressable URL, you can directly access a specified JUNOScope page without having to log in using the JUNOScope server login page. If you use other management applications and want to use the features provided by JUNOScope, you can provide URLs in your application to features in JUNOScope. All pages accessible through a manual login can now be accessed through the URL interface, provided you have the requisite privileges to access the page. [JUNOScope]
• JUNOScope Microsoft Internet Explorer 7 with Windows Vista support—In addition to Netscape Navigator 6 support, the JUNOScope software supports the Microsoft Internet Explorer Version 7 Web browser with Windows Vista. Internet Explorer Version 7 includes platform advances, security, and privacy protection. [JUNOScope]
• Extended element management support (J2320 and J2350 Services Routers, MX480 Ethernet services routers)—Enables you to use the JUNOScope software to configure these newly supported router models and to use the JUNOScope element management tools (such as Looking Glass, Configuration Manager, Inventory Management, and Software Manager) to manage them. [JUNOScope, J-series Getting Started, MX480 Hardware Guide]

JUNOS XML API and Scripting

• Limit permissions for executing event policy actions—Enables you to specify the JUNOS username that is used to perform an action defined in an event policy (actions include changing the configuration, issuing operational mode commands, and uploading files). By default, user root performs all script actions. By specifying a username that has fewer JUNOS permissions, you can limit the circumstances in which the script performs the action. [Automation]
• Delay interval for upload actions defined in an event policy—Enables you to set the delay interval for an upload operation that is defined in an event policy. The delay interval is the amount of time the event process waits to upload the file after the policy is triggered. As in previous versions of the JUNOS software, you can still associate an upload delay interval with a destination as well. If the destination for an upload action with a defined delay interval also has a delay interval, the event process uses the sum of the two intervals. [Automation]
• Refer to a correlating event in a policy action—Enables you to refer to a correlating event in the definition of a policy action. A correlating event is one that must occur within a specified amount of time before another event if the second event is to trigger a policy action. When used in a policy action, the $*.attribute-name (dollar sign and asterisk) notation represents the specified attribute in the correlating event that occurred most recently. [Automation]
• Trigger a policy based on event count—Enables you to specify how many times a triggering event must occur within a specified amount of time for a policy action to be performed. [Automation]
• Retry upload operations—Enables you to specify how many times (and at what time interval) the event process attempts to upload a file if a previous upload attempt fails. [Automation]
• JUNOS XML tag elements and utility MIB for op scripting—Enables you to write op scripts that use JUNOS Extensible Markup Language (XML) operational request tag elements to write, retrieve, and clear data in a new JUNOS MIB called jnx-util.mib. The MIB defines objects for counters, character strings, and integers. The new JUNOS XML tag elements for creating and removing objects are <request-snmp-utility-mib-set> and <request-snmp-utility-mib-clear>. To retrieve objects, use the existing <get-snmp-object>, <next-snmp-object>, and <walk-snmp-object> tag elements. [Automation, Network Management, JUNOS XML API Operational Reference]
• JUNOS XML tag element for accounting records—Enables you to write op scripts that use the JUNOS XML <add-accounting-file-record> operational request tag element to create accounting records and add data to them. [Automation, Network Management, JUNOS XML API Operational Reference]
• XML schemata for JUNOS XML operational tag elements—XML schemata for JUNOS operational requests and responses are available along with the existing schema for JUNOS configuration information. The schemata are accessible with the JUNOS software packages on the software download Web page: https://www.juniper.net/support/csc/swdist-domestic/. [JUNOS XML API Operational Reference]
• Table 1 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 8.4, along with the corresponding CLI command and response tag element for each one.

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

  Request Tag Element	CLI Command	Response Tag Element
  <clear-bridge-interface-mac-table>	clear bridge mac-table interface	None
  <clear-bridge-mac-table>	clear bridge mac-table	None
  <clear-vpls-interface-mac-table>	clear vpls mac-table interface	None
  <clear-vpls-mac-table>	clear vpls mac-table	None
  <get-bridge-domain-alt-root- flood-route-information>	show bridge flood route alt-root-flood	<l2ald-bridge-domain-flood-route-information>
  <get-bridge-domain-bd-flood- route-information>	show bridge flood route bd-flood	<l2ald-bridge-domain-flood-route-information>
  <get-bridge-domain-event- queue-information>	show bridge flood event-queue	<l2ald-bridge-domain-flood-event-queue>
  <get-bridge-domain-mlp-flood- route-information>	show bridge flood route mlp-flood	<l2ald-bridge-domain-flood-route-information>
  <get-bridge-domain-re-flood- route-information>	show bridge flood route re-flood	<l2ald-bridge-domain-flood-route-information>
  <get-bridge-instance-information>	show bridge domain	None
  <get-bridge-interface-mac-table>	show bridge mac-table interface	None
  <get-bridge-mac-table>	show bridge mac-table	None
  <get-bridge-statistics-information>	show bridge statistics	<bridge-statistics-information>
  <get-dot1x-interface-information>	show dot1x interface	<dot1x-interface-information>
  <get-link-services-cpu-usage>	show services link-services cpu-usage	<lsqinfo-cpu-usage-information>
  <get-mvpn-instance-information>	show mvpn instance	<mvpn-instance-information>
  <get-pgcpd-active-configuration>	show services pgcp active-configuration	<pgcpd-active-configuration>
  <get-power-management>	show chassis power-ratings	<power-management-information>
  <get-service-pgcp-gate>	show services pgcp gate	<service-pgcp-gate>
  <get-service-pgcp-gates>	show services pgcp gates	<service-pgcp-gates>
  <get-service-pgcp-statistics-gateway>	show services pgcp statistics gateway	<service-pgcp-statistics-gateway>
  <get-service-pgcp-statistics>	show services pgcp statistics	<service-pgcp-statistics>
  <get-service-pgcp-termination>	show services pgcp termination	<service-pgcp-termination>
  <get-service-pgcp-terminations>	show services pgcp terminations	<service-pgcp-terminations>
  <get-show-bridge-domain-all-ce-flood- route-information>	show bridge flood route all-ce-flood	<l2ald-bridge-domain-flood-route-information>
  <get-show-bridge-domain-ve-flood- route-information>	show bridge flood route all-ve-flood	<l2ald-bridge-domain-flood-route-information>
  <get-spmb-sib-information>	show chassis spmb sibs	<sib-information>
  <get-tgm-telephony-interface- module-status>	show tgm telephony-interface-module	<telephony-interface-module-status-information>
  <get-vpls-all-ce-flood-route-information>	show vpls flood route all-ce-flood	<l2ald-vpls-flood-route-information>
  <get-vpls-all-flood-route-information>	show vpls flood route all-flood	<l2ald-vpls-flood-route-information>
  <get-vpls-alt-root-flood-route-information>	show vpls flood route alt-root-flood	<l2ald-vpls-flood-route-information>
  <get-vpls-ce-flood-route-information>	show vpls flood route ce-flood	<l2ald-vpls-flood-route-information>
  <get-vpls-event-queue-information>	show vpls flood event-queue	<l2ald-vpls-flood-event-queue>
  <get-vpls-interface-mac-table>	show vpls mac-table interface	None
  <get-vpls-mac-table>	show vpls mac-table	None

  [JUNOS XML Operational Reference]

System Log

The following sets of system log messages are new in this release:

• CFMD—Messages generated by the connectivity-fault management process, which supports OAM functions that are defined in the IEEE 802.1ag standard for Ethernet interfaces.
• DH_SVC—Messages generated by the DHCP services process, which automatically allocates network IP addresses and delivers configuration settings to client hosts in a TCP/IP network.
• L2ALD—Messages generated by the Layer 2 address learning process, which supports the dynamic acquisition of information about MAC addresses in a Layer 2 bridge environment.
• L2CPD—Messages generated by the Layer 2 Control Protocol process, which supports the transmission of control messages for Layer 2 spanning tree protocols in a Layer 2 bridge environment.
• MPLS_OAM—Messages generated by the MPLS OAM process, which supports traceroute operations for LDP LSPs.

The following system log messages are new in this release:

• ASP_COS_RULE_MATCH
• ASP_L2TP_BULK_STATS_QUERY_FAIL
• ASP_SFW_ADJUSTING_ALG_LEVEL
• BFDD_MIRROR_ERROR
• BFDD_MIRROR_VERSION_MISMATCH
• CHASSISD_BLOWERS_SPEED_MEDIUM
• CHASSISD_PIC_VERSION_ERROR
• CHASSISD_POWER_RATINGS_EXCEEDED
• CHASSISD_VOLTAGE_READ_FAILED
• CHASSISD_VOLTAGE_SENSOR_INIT
• COSD_EXACT_RATE_UNSUPP_INTERFACE
• COSD_EXACT_RATE_UNSUPP_SESSION
• COSD_HIGH_PRIO_QUEUES_INTERFACE
• COSD_HIGH_PRIO_QUEUES_SESSION
• COSD_L2TP_COS_NOT_CONFIGURED
• COSD_L2TP_COS_NOT_SUPPORTED
• COSD_L2TP_SHAPING_NOT_CONFIGURED
• COSD_RATE_LIMIT_NOT_SUPPORTED
• COSD_REWRITE_RULE_LIMIT_EXCEEDED
• COSD_TRICOLOR_NOT_SUPPORTED
• COSD_TX_QUEUE_RATES_TOO_HIGH
• EVENTD_POLICY_ACTION_FAILED
• EVENTD_SET_PROCESS_PRIV_FAILED
• JADE_SOCKET_ERROR
• L2TPD_POLICER_ADD_FAILED
• L2TPD_POLICER_PROFILE_DEL_FAILED
• PPMD_ASSERT_SOFT
• PPMD_OPEN_ERROR
• RPD_BGP_NEIGHBOR_STATE_CHANGED
• RPD_MPLS_OAM_READ_ERROR
• RPD_MPLS_OAM_WRITE_ERROR
• UI_COMMIT_PROGRESS
• UI_COMMIT_SYNC_FORCE

The following system log messages are no longer documented, either because they indicate internal software errors that are not caused by configuration problems or because they are no longer generated. If these messages appear in your log, contact your technical support representative for assistance:

• AUTOD_ARGUMENT_FAILURE
• AUTOD_NOT_ROOT (previously called AUTOD_PERMISSION_FAILURE)
• AUTOD_PID_FILE_LOCK (previously called AUTOD_PIDLOCK_FAILURE)
• DFWD_ARGUMENT_ERROR
• DHCPD_ARGUMENT_FAILURE
• DHCPD_DAEMONIZE_FAILED (previously called DHCPD_DAEMON_FAILURE)
• DHCPD_EVLIB_CREATE_FAILURE
• DHCPD_EVLIB_MAINLOOP_FAILURE
• DHCPD_NOT_ROOT (previously called DHCPD_PERMISSION_FAILURE)
• DHCPD_PID_FILE_LOCK (previously called DHCPD_PIDLOCK_FAILURE)
• DHCPD_PID_FILE_UPDATE (previously called DHCPD_PIDUPDATE_FAILURE)
• EVENTD_POLICY_IGNORED
• RPD_VPLS_LR_FAILED
• UI_SCHEMA_MISMATCH_MINOR

The text logged for the RPD_MIRROR_ERROR tag is now “Unable to establish mirror connection between Routing Engines: error-message”.

The text logged for the RPD_MIRROR_VERSION_MISMATCH tag is now “Versions of mirror software on Routing Engines are incompatible: error-message”. [System Log]