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

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

Class of Service

• Enhanced IQ PIC for the M320, M120, T-series, and M40e—Allows the user to apply a hierarchical policer for the premium and aggregate (premium plus normal) traffic levels to an interface. To configure the hierarchical policer, apply the policing-priority statement to the proper forwarding class and configure a hierarchical policer for the aggregate and premium level. [Class of Service]
• Allocating extra CIR bandwidth equally amongst all PVCs—By default, all logical (lsq-) interfaces on a MultiServices (MS) PIC share bandwidth equally in the excess region (that is, bandwidth available once these interfaces have exhausted their committed information rate (CIR).

  However, you can configure the excess-rate statement to control an independent set of parameters for bandwidth sharing in the excess region of a Frame Relay data-link connection identifier (DLCI) on an MS PIC. You configure the excess-rate statement at the [edit class-of-service traffic-control-profile] hierarchy level.

  [Network Interfaces, Class of Service]

• Customizing type-of-service bits—By default, all logical (lsq-) interfaces on a MultiServices (MS) PIC preserve the type-of-service (ToS) bits in an incoming packet header.

  However, you can configure the translation-tables statement to replace the arriving ToS bit pattern to a user-defined value. You configure the translation-tables statement at the [edit class-of-service] hierarchy level.

  This feature follows exactly the same configuration rules as the Enhanced IQ PIC. [Class of Service]

• Rate-limit and excess rate/excess priority option—You can configure bandwidth sharing rate limits, excess rate, and excess priority at the queue level on the following routers:

  • M120 (rate limit and excess priority only; excess rate is handled by the hardware.)
  • MX-series (rate limit, excess rate, and excess priority)
  • T-series (rate limit, excess rate, and excess priority)
  Some Packet Forwarding Engine chipsets support rate limits by enabling rate control and keeping the queue length small. The Enhanced Type II FPCs support configuration of excess priority but do not support configuration of excess rate. The Enhanced Type III FPCs support configuration of excess rate and excess priority.

  You configure rate limits when you have a concern that low latency packets (such as high or strict-high priority packets for voice) might starve low-priority and medium-priority packets. In the JUNOS software, the low latency queue is implemented by rate-limiting packets to the transmit bandwidth. The rate limiting is performed immediately before queueing the packet for transmission. All packets which exceed the rate limit are dropped, not queued.

  By default, if the excess priority is not configured for a queue, the excess priority will be the same as the normal queue priority. If none of the queues have an excess rate configured, then the excess rate will be the same as the transmit rate percentage. If at least one of the queues has an excess rate configured, then the excess rate for the queues which do not have an excess rate configured will be set to zero.

  When the physical interface is on queuing hardware such as the IQ, IQ2, IQE PICs, or MX-series DPCs, these features are not supported.

  You cannot configure both rate limits and buffer sizes on these Packet Forwarding Engines.

  Four levels of excess priorities are supported: low, medium-low, medium-high, and high.

  All queues can be rate limited, whether eight or four queues are configured. The queue is shaped by limiting the queue to the transmit rate and reducing the queue buffer size to 1 millisecond. For example, a rate-limited queue (scheduler) with a configured transmit rate of 100 Mbps has a delay buffer of 1 millisecond of 100 megabytes, and the queue is shaped (rate controlled) to 100 Mbps. The queue output will be exactly 100 Mbps and the 1-millisecond buffer is available to absorb any transmission bursts. Any traffic above and beyond this limit is tail-dropped and in statistics this traffic is counted as rate-limited drops.

  To configure rate limits for non-queuing Packet Forwarding Engines, include the shaping rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level.

  To configure the excess rate for non-queuing Packet Forwarding Engines, include the excess-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level.

  To configure the excess priority for non-queuing Packet Forwarding Engines, include the excess-priority at the [edit class-of-service schedulers scheduler-name] hierarchy level.

  The relationship among the configured guaranteed rate, excess rate, guaranteed priority, excess priority, and offered load is not always obvious. [Class of Service]

Hardware

• New 10-port Channelized E1/T1 Enhanced IQ (IQE) PIC with RJ-48 connector (M40e, M120, M320, and T series)—The IQE PICs support the same features as existing IQ PICs. In addition, they support enhanced 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. Model number PB-10CHE1-T1-IQE-RJ48. [PIC Guides, Class of Service, Network Interfaces]
• New Flexible PIC Concentrators (FPCs) (T640 and T1600)—The T640 and T1600 core routers support a new Type 2 FPC (T640-FPC2-ES) and a new Type 4 FPC (T640-FPC4-1P-ES).

  Note: Before you install the T640-FPC2-ES or the T640-FPC4-1P-ES in a T640 routing node, all SIBs must be SIB version B, or T640–SIBs for T640 nodes connected to a TX matrix. [PIC Guides]

• New Flexible PIC Concentrators (FPCs) MX-FPC2 (MX-series)—JUNOS Release 9.5 supports the MX-FPC2 on MX-series platforms. The MX-FPC2 supports up to two PICs per FPC. For a list of supported PICs, see the MX-series PIC Guide. [MX-series PIC Guide, MX240 Hardware Guide, MX480 Hardware Guide, MX960 Hardware Guide]

High Availability

• Nonstop active routing support for RSVP-TE LSPs—Starting with Release 9.5, the JUNOS software extends nonstop active routing support to transit label-switching routers (LSR) that are part of an RSVP-TE LSP. Nonstop active routing support on transit LSRs ensures that the master to backup Routing Engine switchover on an LSR remains transparent to the network neighbors and that the path and LSP information remains unaltered during and after the switchover. You can use the show rsvp version command to find out the nonstop active routing mode and state on a label-switching router.

  However, the JUNOS software does not support the following features for nonstop active routing on RSVP-TE LSRs:

  • Point-to-multipoint (P2MP) LSPs
  • Generalized Multiprotocol Label Switching (GMPLS) and LSP hierarchy
  • Inter-domain or loose hop expansion LSPs

  [High Availability]

• Unified ISSU support on additional hardware—Extends the unified ISSU support to the following routing platforms and PICs:

  • M10i routing platforms with Enhanced Compact Forwarding Engine Board (CFEB-E)

  • Enhanced IQ2 PICs (IQ2-E):

    • PC-8GE-TYPE3-SFP-IQ2E
    • PB-8GE-TYPE2-SFP-IQ2E
    • PB-4GE-TYPE1-SFP-IQ2E
    • PC-1XGE-TYPE3-XFP-IQ2E

[High Availability]

Interfaces and Chassis

• New 10-port Channelized E1/T1 IQE PIC (M320, M120, T-series platforms)—Provides 10 E1/T1 ports with increased channelization and enhanced COS features. To configure, use the same interface configuration syntax as for the existing Channelized E1 IQ PIC and Channelized T1 IQ PIC. The configuration limits have changed to match its augmented capabilities. [Network Interfaces, Class of Service]
• Ethernet Local Management Interface (E-LMI) (MX-series)—Enables you to configure an MX-series router with ge, xe, or ae interfaces, operating on the provider edge (PE), to send connectivity status and configuration parameters of Ethernet services available on the customer edge (CE) port. The E-LMI procedures and protocols are used for enabling autoconfiguration of the CE to support Metro Ethernet services.

  E-LMI interoperates with an Operations, Administration, and Management (OAM) protocol, such as Connectivity Fault Management (CFM), that runs within the provider network to collect OAM status. CFM runs at the provider maintenance level (User Network Interface [UNI] UNI-N to UNI-N with up Management End Points [MEPs] at the UNI). E-LMI relies on the CFM for end-to-end status of Ethernet virtual connections (EVCs) across CFM domains (SVLAN domain or VPLS).

  To configure E-LMI, include the connectivity-fault-management, evcs, and lmi statements at the [edit protocols oam ethernet] hierarchy level. [Network Interfaces]

• Ethernet Delay Measurement (ETH-DM) (MX-series)—Enables you to configure on-demand Operations, Administration, and Maintenance (OAM) for measurement of frame delay and frame delay variation (jitter) in either one-way or two-way mode, gathering frame delay statistics, and is capable of simultaneous statistics collection from multiple sessions. ETH-DM provides fine control to operators for triggering delay measurement on a given service and can be used to monitor SLAs. ETH-DM also collects other useful information, such as worst and best case delays, average delay, and average delay variation. ETH-DM supports hardware-based timestamping in the receive direction for delay measurements. Provides run-time display of delay statistics when two-way delay measurement is triggered. ETH-DM records the last 100 samples collected per session. You can retrieve the history at any time. JUNOS software maintains various counters for ETH-DM PDUs which can be retrieved at any time. You can clear all the ETH-DM statistics and PDU counters. ETH-DM is fully compliant with ITU-T Y.1731.

  To trigger ETH-DM, use the monitor ethernet delay-measurement (one-way | two-way) (remote-mac-address | mep identifier) maintenance-domain name maintenance-association ma-id [count count] [wait time] operational command.

  To enable hardware assisted time stamping in reception path, use the performance-monitoring hardware-assisted-timestamping statement at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level.

  To retrieve the last 100 ETH-DM statistics per session, two show commands are provided; one for all (all OAM frame counters and ETH-DM) statistics and one for ETH-DM statistics only.

  To retrieve all statistics for given session, use the show oam ethernet connectivity-fault-management mep-statistics maintenance-domain name maintenance-association name [local-mep identifier] [remote-mep identifier] [count count] command.

  To retrieve only ETH-DM stats for given session, use the show oam ethernet connectivity-fault-management delay-statistics maintenance-domain name maintenance-association name [local-mep identifier] [remote-mep identifier] [count count] command.

  [Network Interfaces]

• Unidirectional link support on 10-Gigabit Ethernet IQ2 PIC interfaces (T-series routing platforms)—Enables 10-Gigabit Ethernet IQ2 PIC interfaces on T-series routing platforms to operate in unidirectional mode. Unidirectional links reduce the number of ports required for broadcast video traffic applications, where most of the traffic flow is in only one direction. [Multiplay Solutions, Network Interfaces]
• Support for new Flexible PIC Concentrator with enhanced scalability (T640, T1600)—Supports four Type 2 PICs per FPC2. For PIC compatibility, see the T640 Routing Node PIC Guide and T1600 Routing Node PIC Guide.

  [Network Interfaces, PIC Guide]

• Support for new Flexible PIC Concentrator FPC4-1 with enhanced scalability (T640, T1600)—Supports one Type 4 PIC per FPC4-1. For PIC compatibility, see the T640 Routing Node PIC Guide and T1600 Routing Node PIC Guide.

  [Network Interfaces, PIC Guide]

• New auto-negotiation of speed and disable Auto MDI/MDIX features (MX-series)—Support for auto-negotiation of speed on MX-series platforms with 10/100/1000 capable DPCs and Tri-Rate Copper SFPs. The auto-negotiation specified interface speed is propagated to other CoS, routing protocols, and other system components. Half duplex mode is not supported.

  To specify the auto-negotiation speed, use the speed <(auto | 1 Gbps | 100 Mbps | 10 Mbps)> statement in the [edit interface ge-/fpc/pic/port] hierarchy level.

  To set port speed negotiation to a specific rate, set the port speed to either 1 Gbps, 100 Mbps, or 10 Mbps. If the negotiated speed and the interface-speed do not match, the link will not be brought up.

  If you set the auto-negotiation speed auto option, then the port speed is negotiated.

  You can disable Auto MDI/MDIX using the no-auto-mdix statement under the [edit interface ge-/fpc/pic/port gigether-options] hierarchy level.

  Use the show interfaces ge-fpc/pic/port brief command to display the auto negotiation of speed and Auto MDI/MDIX states.

  [Network Interfaces]

• Extended period for T1 and E1 bit error rate test (BERT) (M-series, T-series)—Supports running BERT for a period of up to 24 hours (previous 4–minute maximum) on the following T1 and E1 interfaces, and includes channelized PICs which can be channelized down to T1 or E1 interfaces:

  IQ PICs:

  • 10-port CT1 IQ PIC
  • 10-port CE1 IQ PIC
  • 1-port OC3 Channelized down to T1/DS0 IQ PIC
  • 1-port Channelized STM1 IQ PIC
  • 2-port Channelized STM1 IQ PIC
  • 1-port Channelized 0C12 IQ PIC

  IQE PICs:

  • 4-port DS3/E3 Channelized IQE PIC (Type 1)
  • 10-port CHT1/E1 Channelized IQE PIC (Type 1)
  • 2-port COC3/STM1 Channelized IQE PIC (Type 1)
  • 1-port COC12/STM4 Channelized IQE PIC (Type 1)
  • 4-port CHOC12/STM4 Channelized IQE PIC (Type 2)
  • 1-port CHOC48/STM16 Channelized IQE PIC (Type 2)

  Standard PICs:

  • 2-port T1 PIC
  • 4-port T1 PIC
  • 2-port E1 PIC
  • 4-port E1 PIC
  • 10-port CE1 704 PIC
  • 1-port OC3 Channelized down to T1 PIC
  • 1-port STM1 Channelized down to E1 PIC
  • 1-port OC12 Channelized PIC

  To configure the BERT period on T1 interfaces, use the bert-period seconds statement at the [edit interfaces t1-fpc/pic/port t1-options] hierarchy level. The range is from 1 through 86,400 seconds. The default value is 240 seconds.

  To configure the BERT period on E1 interfaces, use the bert-period seconds statement at the [edit interfaces e1-fpc/pic/port e1-options] hierarchy level. The range is from 1 through 86,400 seconds. The default period is 10 seconds.

  You can use the show interfaces t1-fpc/pic/port extensive | find BERT command to display T1 PIC BERT results.

  You can use the show interfaces e1-fpc/pic/port extensive | find BERT command to display E1 PIC BERT results.

  [Network Interfaces]

• New Flexible PIC Concentrator (FPC) MX-FPC2 (MX-series)—Supports non-Ethernet PICs on MX-series platforms. For a list of supported PICs, see the MX-series PIC Guide. [Network Interfaces, PIC Guide]
• JUNOS software Layer 3 datapath support for Type 2 FPC (MX-series)—Supports two PICs per FPC. For PIC compatibility, see the MX-series PIC Guide. [Network Interfaces]
• VPLS support on new Flexible PIC Concentrator MX-FPC2 (MX-series)—Supports non-Ethernet PICs on MX-series platforms. For a complete list of supported PICs, see the MX-series Hardware Guide.

  [Network Interfaces, MX-series Hardware Guide]

• Support for inter-PSD forwarding (JCS 1200)—Enables communication between PSDs without requiring dedicated physical links. Instead, PSD communication is achieved by using internal tunnel PICs that reside on the PSD. The PSDs communicate over logical interfaces (ifls) configured on the tunnel PICs. Multiple logical interfaces can be configured on the tunnel PIC, allowing the PSD to communicate with multiple PSDs over the same tunnel PIC.

  For inter-PSD forwarding, each PSD that needs to communicate with another PSD must have a Tunnel PIC attached. To configure inter-PSD forwarding on a PSD, include the following statements at the [edit interfaces] hierarchy level of the associated PSDs:

  xt-fpc/pic/port {unit unit-number {peer-psd psdn;peer-interface logical-interface-name;encapsulation frame-relay;point-to-point;dlci dlci-value;}}

  Currently, only Frame Relay encapsulation is supported for inter-PSD forwarding. [JUNOS PSD Configuration Guide].

• VLAN rewrite operations on incoming and outgoing frames (M320, M120, and MX platforms)—Supports adding a new VLAN tag in front of the existing one, removing a VLAN tag or replacing the existing tag with a new user-configured tag, on tagged frames only, on a per logical interface basis in both the ingress and egress directions. Encapsulation on the logical interface must be vlan-ccc, vlan-vpls, extended-vlan-ccc, or extended-vlan-vpls. This enhancement also supports rewrite operations on untagged frames under ethernet-ccc and ethernet-vpls encapsulations.

  The JUNOS software supports the following rewrite operations under ethernet-ccc and ethernet-vpls encapsulations:

  • push— A VLAN tag will be added to the incoming untagged frame.
  • pop— VLAN tag is removed from the outgoing frame.
  • push-push— An outer and inner VLAN tag will be added to the incoming untagged frame.
  • pop-pop— Both the outer and inner VLAN tags of the outgoing frame are removed.

  push-push and pop-pop operations are not supported on Ethernet IQ PICs. Ethernet IQ2 PICs support all the above mentioned rewrite operations.

  M320 and M120 platforms with the following PICs, support this feature:

  • Ethernet IQ PICs:

    • Gigabit Ethernet IQ, 1-port SFP
    • Gigabit Ethernet IQ, 2-port SFP

  • Ethernet IQ2 PICs:

    • 1-Gigabit Ethernet IQ2, 4-port SFP oversubscription
    • 1-Gigabit Ethernet IQ2, 8-port SFP oversubscription
    • 1-Gigabit Ethernet IQ2, 8-port SFP line rate
    • 10-Gigabit Ethernet IQ2, 1-port XFP line rate

    Enhanced Ethernet IQ2E PICs:

    • 1-Gigabit Ethernet IQ2E, 4-port
    • 1-Gigabit Ethernet IQ2E, 8-port
    • 10-Gigabit Ethernet IQ2E, 1-port

  MX platforms with the following DPCs support this feature:

  • Gigabit Ethernet R, 40-port SFP
  • Gigabit Ethernet R EQ, 40-port SFP
  • 10-Gigabit Ethernet R, 1-port XFP
  • 10-Gigabit Ethernet R EQ, 1-port XFP

  In the input-vlan-map, only the push and push-push operations are permitted. Similarly, only pop and pop-pop operations are permitted in the output-vlan-map. For push and push-push operations, the tag parameters must be explicitly specified. All other rules for configuring input-vlan-map and output-vlan-map remain the unchanged.

  To configure an input VLAN map, use the input-vlan-map statement and options at the [edit interfaces interface-name fpc/pic/port unit number] hierarchy level.

  To configure an output VLAN map, use the output-vlan-map statement and options at the [edit interfaces interface-name fpc/pic/port unit number] hierarchy level.

  Note: Unit encapsulation must be set to ethernet-ccc or ethernet-vpls , otherwise input VLAN map and output VLAN map settings will not be valid.

  You can use the show interface interface-name dpc/pic/port command to display the Index, SNMP ifIndex, flags, In(push), Out(pop), and Encapsulation parameters. [Network Interfaces]

• 1–port 10–Gigabit XENPAK PIC as a shared interface PIC (JCS 1200)—Support for the 1-port 10 Gigabit XENPAK PIC (PC-1XGE-XENPAK) as a shared interface PIC on the JCS 1200 platform. This shared interface supports VLAN tag IP routing (Ethernet or ENET2) encapsulation. [JUNOS PSD Configuration Guide]
• TX-series supports unnumbered Ethernet interfaces (TX-series)—Removes TX-series restriction on configuring unnumbered Ethernet interfaces. [Network Interfaces]

Layer 2 Ethernet Services

• Next-hop groups (MX-series)—You can configure next-hop groups for the MX-series routers using either IP addresses or Layer 2 addresses for the next hops. Use the group-type[inet|layer-2] statement at [edit forwarding-options next-hop-group group-name] to establish the next-hop groups. You can also reference more than one port-mirroring instance in a filter on MX-series routers. Use the port-mirror-instance instance-name statement at the [edit firewall family family-name filter filter-name term term-name] to refer to one of several port-mirroring instances. [Layer 2 Configuration Guide, Policy Framework]
• DHCP support for integrated routing and bridging (MX-series routers)—DHCP is now supported in integrated routing and bridging (IRB) configurations. When you configure IRB in a network that is using DHCP, the DHCP information (for example, authentication, address assignment, and so on) is propagated in the associated bridge domain. This enables the DHCP server to configure client IP addresses residing within the bridge domain. This feature currently works only for static configurations. The show dhcp server binding detail command has been enhanced to show both the Layer 2 interface and the IRB interface when applicable. [Subscriber Access]
• Hash key load balancing support for Layer 3 and Layer 4 fields—By default, the hash key mechanism to load-balance frames across LAG interfaces is based on Layer 2 fields (such as frame source and destination address) as well as the input logical interface (unit). No Layer 3 or Layer 4 fields are examined and are part of the default hash process, so the default is not optimized for Layer 2 switching (the frame source and destination MAC addresses are the same). One link is overutilized and other links are underutilized.

  You can configure the load-balancing hash key for Layer 2 traffic to use fields in the Layer 3 and Layer 4 headers inside the frame payload for load-balancing purposes using the payload statement. You can configure the statement to look at layer-3 (and source-address-only or destination-address-only packet header fields) or layer-4 fields. You configure this statement at the [edit forwarding-options hash-key family multiservice] hierarchy level. [Layer 2 Configuration Guide, Policy, Network Interfaces]

MPLS Applications

• GRES for MPLS ingress and egress P2MP LSPs—Graceful Routing Engine switchover (GRES) and graceful restart are now supported for point-to-multipoint (P2MP) LSPs at ingress and egress routers. The P2MP LSPs must be configured using static routes or CCC. GRES and graceful restart are not supported on P2MP LSPs configured for VPLS or next-generation multicast VPNs (MVPNs). GRES and graceful restart allow the traffic to be forwarded at the Packet Forwarding Engine (PFE) based on the old state while the control plane recovers using the standard graceful restart procedures. This functionality is enabled automatically whenever you enable GRES and graceful restart on the router. [MPLS Applications]
• Statistics for P2MP LSPs—A number of commands have been enhanced to allow you to display statistics related to point-to-multipoint (P2MP) LSPs.

  The revised commands are:

  • show mpls lsp statistics p2mp
  • show mpls lsp statistics p2mp ingress
  • show mpls lsp statistics p2mp transit
  • monitor label-switched-path sub-LSP-name

  You can now display information on P2MP LSPs by issuing these commands on either the ingress router of the P2MP LSP or from any of the routers along any of the sub-LSP paths. [Routing Protocols Reference]

• Automatic policers for P2MP LSPs—You can now configure automatic policers for point-to-multipoint (P2MP) LSPs. P2MP LSPs allow you to establish LSPs with a single origin and multiple destinations. Automatic policers allow you to automatically limit the amount of traffic sent over the P2MP LSP, providing a strict service guarantee for network traffic. You configure automatic policers on the trunk routing node for the P2MP LSP using the auto-policing statement configured at the [edit protocols mpls] hierarchy level. [MPLS Configuration Guide]

Multicast

• Hierarchical bandwidth adjustment and reverse OIF mapping—Enables you to disable hierarchical bandwidth adjustment for all subscriber interfaces that are reverse OIF mapped from a specified multicast interface. Reverse OIF mapping is used to determine the subscriber VLAN interface and the multicast traffic bandwidth on the interface.

  To disable hierarchical bandwidth adjustment for all subscribers on a multicast interface, include the no-qos-adjust statement at the [edit routing-options multicast interface [interface-names] reverse-oif-mapping] hierarchy level.

  To display the multicast bandwidth consumed on the subscriber interfaces, issue the show multicast interfaces command. [Multicast, Subscriber Access]

• Turn off spanning-tree interface state (MX-series)—By default, the IGMP snooping process on an MX-series router is aware of topology changes made by any of the spanning-tree protocols (STPs).

  The default behavior for the IGMP snooping process on an MX-series router can be changed to ignore the spanning-tree topology change messages. To ignore the spanning-tree topology change messages, include the ignore-stp-topology-change statement at the [edit routing-instances routing-instance-name bridge-domains bridge-domain-name multicast-snooping-options] hierarchy level.

  [Multicast, MX-series Layer 2 Configuration Guide]

• Full support for IGMPv3 snooping on Layer 2 interfaces (MX-series)—The JUNOS software provides full support for IGMPv3 snooping on Layer 2 interfaces for VPLS instances and IRB bridging. Only Include mode and Internet Standard Multicast (ISM) version of Exclude Mode are supported for this release. This support gives the hosts the flexibility to choose the source from which they want to receive the traffic. No additional configuration is required. [Multicast, Routing Protocols and Policies Command Reference]
• Dynamic reuse of data multicast distribution tree group addresses —A limited number of multicast group addresses are available for use in data multicast distribution tree (MDT) tunnels. By default when the available multicast group addresses are all used, no new data MDTs can be created.

  You can enable dynamic reuse of data MDT group addresses. Dynamic reuse of data MDT group addresses allows multiple multicast streams to share a single MDT and multicast provider group address. For example, three streams can use the same provider group address and MDT tunnel. When the feature is enabled, new streams are assigned to a particular MDT in a round-robin fashion. Note that if the provider tunnel is being used by multiple customer streams, it might result in egress routers receiving customer traffic that is not requested by the attached customer sites. This is similar to what happens if multiple customer streams are sent on the default MDT tunnel.

  To enable dynamic reuse of data MDT group addresses, include the data-mdt-reuse statement. The data-mdt-reuse statement can be configured at the [edit logical-systems logical-system-name routing-instances routing-instance-name protocols pim mdt] and [edit routing-instances routing-instance-name protocols pim mdt] hierarchy levels. [Multicast, Routing Protocols and Policies Command Reference]

Platform and Infrastructure

• Enhancements to Juniper Networks enterprise-specific MPLS MIB —The following objects of the enterprise-specific MPLS MIB ( jnx-mpls.mib ) have been modified to support and store information about manual bypass tunnels through the entire life cycle of a bypass tunnel. Both mplsLspState and mplsLspInfoState objects now have two additional values: notInService (integer value: 4) and backupActive (5). The notInService state indicates that the LSP has been torn down or never been signaled due to the lack of demand for its protection. The backupActive state indicates that the LSP is up and carrying user traffic for at least one protected LSP due to the failure of the LSP, which has caused the creation of a backup LSP. Similarly, the mplsPathType and mplsPathInfoType objects now have a new value, bypass (5), to denote that the path is a manually-configured bypass tunnel. In the previous releases, the information about bypass tunnels was stored in the standard mplsTunnelTable that uses a combination of mplsTunnelIndex , mplsTunnelInstance , mplsTunnelIngressLSRId , and mplsTunnelEgressLSRId as index. Because the value for mplsTunnelInstance changes when an LSP is signaled or resignaled, new entries are created each time an LSP is signaled or resignaled. This has been causing problems in tracking the state of bypass tunnels. The latest enhancements to the enterprise-specific MIB, which uses the LSP name as index, enable the MIB to store information about bypass tunnels in a single entry and users to access information about bypass tunnels through its life cycle using a single index. The show mpls lsp bypass command returns information about bypass tunnels of all states. [Network Management]

Routing Policy and Firewall Filters

• Dynamic configuration support for routing policies—Enables you to configure routing policies in a dynamic database that is not subject to the same verification required to commit configuration changes to the standard configuration database. As a result, you can quickly commit routing policies that can be referenced and applied in the standard configuration as needed. The dynamic database is stored in the /var/run/db/juniper.dyn directory.

  To configure a dynamic database, enter the configure dynamic command to be placed in the [edit dynamic] hierarchy. At the [edit dynamic policy-options] hierarchy level, you can configure the following statements: as-path as-path-name, as-path-group group-name, community community-name, condition condition-name, prefix-list prefix-list-name, and policy-statement policy-statement-name. No other configuration is supported at the [edit dynamic] hierarchy level.

  All the policies that you configure in the dynamic database can be referred to in policies configured in the standard configuration under the [edit policy-options] hierarchy level. To define a routing policy based on the dynamic database configuration, include the dynamic-db statement at the [edit policy-options policy-statement policy-statement-name] hierarchy level in the standard configuration mode. You can also include the dyanmic-db statement at the following hierarchy levels: [edit policy-options as-path as-path-name, [edit policy-options as-path-group group-ame], [edit policy-options community community-name, [edit policy-options condition condition-name], and [edit policy-options prefix-list prefix-list-name]. In this way, you can define any of these policy objects using the dynamic database configuration. You can then apply any of these policies that reference the dynamic database configuration to a routing policy configured in the standard configuration. For example, include the dynamic-db statement at the [edit policy-options prefix-list p11] hierarchy level to create a prefix list, p11, that references the dynamic database configuration. You can then include the prefix-list p11 statement at the [edit policy-options policy-statement policy-statement-name from] hierarchy level in the standard configuration to define a routing policy that matches on a prefix list configured in the dynamic database.

  Currently, BGP is the only protocol to which you can apply routing policies configured in the dynamic database. You must use the standard configuration mode to apply routing policies configured in the dynamic database. For example, you configure policy-statement dyn-policy1 at the [edit dynamic] hierarchy level. You then define a routing policy based on the dynamic database configuration by including the dynamic-db statement at the [edit policy-options policy-statement dyn-policy1] hierarchy level. You can then apply the dyn-policy-1 routing policy at the [edit protocols bgp group group-name neighbor address export] or [edit protocols bgp group group-name neighbor address import] hierarchy level in the standard configuration mode. [Policy]

• IEEE 802.1p priority match conditions for Layer 2 VPN firewall filters (MX-series routers)—Enables you to configure firewall filters for Layer 2 VPN traffic that match on learned and user IEEE 802.1p priority fields. To match on a learned 802.1p priority field, include the learn-vlan-1p-priority value statement at the [edit firewall family ccc filter filter-name term term-name from] hierarchy level. To match on a user 802.1p priority field, include the user-vlan-1p-priority value statement at the [edit firewall family ccc filter filter-name term term-name from] hierarchy level. These match conditions were previously supported with VPLS and Layer 2 bridging only. [Policy, Layer 2 Configuration Guide]
• Port mirroring for VPLS traffic and multiple port-mirroring instances for IPv4, IPv6, and VPLS traffic (M7i, M10i, M120, M320 routers)—Extends port-mirroring support for VPLS traffic to M7i, M10i, M120, and M320 routers. Previously, only the MX-series routers supported port mirroring for VPLS traffic. The M7i or M10i router must include the Enhanced CFEB (CFEB-E) to use this feature. In addition, on the M320, VPLS port mirroring is supported only on Enhanced III FPCs. Include the family vpls statement at the [edit forwarding-options port-mirroring] hierarchy level.

  You can also configure multiple port-mirroring instances for VPLS, IPv6, and VPLS traffic with each instance specifying different input sampling properties and output mirror destination properties. Multiple port-mirroring instances were previously supported only on the MX-series routers. To configure a port-mirroring instance, include the instance port-mirroring-instance-name statement at the [edit forwarding-options port-mirroring] hierarchy level. To configure a family address type for a port-mirroring instance, include the family (inet | inet6 | vpls) statement at the [edit forwarding-options port-mirroring instance port-mirror-instance-name] hierarchy level. To configure input properties for a port-mirroring instance, include the input statement at the [edit forwarding-options port-mirroring instance port-mirroring-instance-name] hierarchy level. To configure output properties for a port-mirroring instance, include the output statement at the [edit forwarding-options port-mirroring family (inet | inet6 | vpls)] hierarchy level. You can also associate a port-mirroring instance with a specific FPC on an M320 router and with a specific FEB on an M120 router. To associate a port-mirroring instance with a specific FPC on an M320 router, include the port-mirror-instance instance-name statement at the [edit chassis fpc number] hierarchy level. To associate a port-mirroring instance with a specific FEB on an M120 router, include the port-mirror-instance instance-name statement at the [edit chassis feb slot number] hierarchy level. You can associate only one port mirroring instance with each FPC on an M320 router and with each FEB on an M120 router. In addition, on an M120 router, you cannot configure a port mirroring instance on a FEB configured as a backup FEB. [Policy, System Basics]

• Packet loss priority match condition for firewall filters extended to M120 and M320 routers—Enables you to configure a firewall filter that matches on a specific packet loss priority (PLP) level. To configure a PLP match condition, include the loss-priority level statement at the [edit firewall filter filter-name term term-name from] hierarchy level. For the level, you can include one or more of the following values: high, low, medium-high, or medium-low. All protocol families are supported with the loss-priority match condition. To configure a family type for a firewall filter, include the family (any | ccc | inet | inet6 | mpls | vpls) statement at the [edit firewall] hierarchy level. The loss-priority level was previously supported only on the MX-series routers and on the M7i and M10i routers that use the new Enhanced CFEB (CFEB-E). [Policy]

Routing Protocols

• Routing Engines as BGP route reflectors (JCS 1200)—To decrease BGP control traffic and minimize the number of update messages, a BGP route reflector is used in many networks to distribute BGP routes within the AS. This feature leverages the large memory and 64-bit processor capacity of the JCS routing engine, making it an ideal candidate for route reflection.

  To configure this option, the blade bay data includes support for a new routing platform type: Standalone Control Element (PRDSCE). The SCE platform does not have forwarding plane (PFE) support and does not require RSD connectivity. The platform has network connectivity by fxp0 and fxp1 interfaces only. [JUNOS PSD Configuration Guide]

• Support for alternate loop-free routes for IS-IS —Adds fast reroute capability for IS-IS. The JUNOS software precomputes loop-free backup routes for all IS-IS routes. These backup routes are preinstalled in the Packet Forwarding Engine, which performs a local repair and implements the backup path when the link for a primary next hop for a particular route is no longer available. A loop-free path is one that does not return traffic through the router to reach a given destination. That is, a neighbor that already forwards traffic to the router is not used as a backup route to that destination.

  You can enable support for alternate loop-free routes on any IS-IS interface. Because it is common practice to enable LDP on an interface for which IS-IS is already enabled, this feature also provides support for LDP label-switched paths (LSPs).

  The level of backup coverage available through IS-IS routes depends on the actual network topology and is typically less than 100 percent for all destinations on any given router. You can extend backup coverage to include RSVP LSP paths.

  The JUNOS software provides two mechanisms to enable fast reroute for IS-IS using alternate loop-free routes: link protection and node-link protection. When you enable link protection or node-link protection on an IS-IS interface, the JUNOS software creates an alternate path to the primary next hop for all destination routes that traverse a protected interface. Link protection offers per-link traffic protection. Use link protection when you assume that only one link might become unavailable but that the neighboring node on the primary path would still be available through another interface. Node-link protection establishes an alternate path through a different router altogether. Use node-link protection when you assume that access to a node is lost when a link is no longer available.

  To enable link protection for all destination routes that traverse a specific interface, include the link-protection statement at the [edit protocols isis interface interface-name] hierarchy level. To enable node-link protection for all destination routes that traverse a specific interface, include the node-link-protection statement at the [edit protocols isis interface interface-name] hierarchy level. By default, all the interfaces in a routing instance can function as backup interfaces for a protected interface. To exclude a specific interface from functioning as a backup for a protected interface, include the no-eligible-backup statement at the [edit protocols isis interface interface-name] hierarchy level. You can enhance backup coverage for IS-IS routes and LDP LSP paths by configuring RSVP LSPs as additional backup paths. Include the backup statement at the [edit mpls label-switched-path lsp-name]. You must also specify the address of the egress router for the LSP by including the to address statement at the [edit mpls label-switched-path lsp-name] hierarchy level.

  Several new commands are available to support this new feature. Use the show isis backup label-switched-path command to display which MPLS LSPs have been designated as backup paths. To display shortest-path-first (SPF) calculations for each neighbor, use the show isis backup spf results command. Use the show isis backup coverage command to display how many nodes and prefixes for each address family are protected. In addition, the show isis detail command has been enhanced to display the type of protection, link or link-node, applied to each interface. [Routing Protocols, Routing Protocols and Policies Command Reference]

• Support for the BGP Monitoring Protocol—Enables you to collect data from the BGP Adjacency-RIB-In routing tables and to periodically have that data sent to a monitoring station. The JUNOS software implementation of the BGP Monitoring Protocol (BMP) is based on Internet draft BGP Monitoring Protocol draft-scudder-bmp-01.txt. To configure BMP, include the bmp station- address bmp-station-address statements at the [edit routing-options] hierarchy level. For bmp-station-address, include the IP address of the monitoring station. You must also configure the port number of the monitoring station. Include the station-port station-port-number statement at the [edit routing-options bmp] hierarchy level. You can also configure BMP for individual logical systems.

  Optionally, you can configure how often to send data to the monitoring station with the statistics-timeout seconds statement. The default is 1 hour. You can also configure a memory threshold to stop collecting BMP data when it is exceeded as well as a time interval to wait before reestablishing a BMP session that has ended after exceeding the memory threshold. Use the memory-lmit bytes statement to configure the memory threshold. The default is 10 MB. To configure the interval to wait before reestablishing the BMP session, include the memory-connect-timeout seconds statement. The default is 10 minutes. [Routing Protocols]

• Alias support for local autonomous system number for BGP—Enables you to configure a local autonomous system (AS) number assigned to a BGP group or neighbor as an alias to the system AS. As a result, a BGP peer considers any local AS to which it is assigned as equivalent to the primary AS number configured for the router. When you configure a local AS number as an alias, that number is no longer prepended in the BGP path when a BGP peer sends route updates to an external peer. Only the primary AS number is prepended in the BGP path. To configure a local AS as an alias to the system AS, include the alias statement at the [edit protocols bgp group group-name local-as number] or [edit protocols bgp group group-name neighbor address local-as number] hierarchy level. You configure the AS for the router with the autonomous-system number statement at the [edit routing-options] hierarchy level. [Routing Protocols]
• Support to hold down BGP peering sessions after a nonstop active routing switchover—Enables you to configure the router not to reestablish a BGP peering session after a nonstop active routing (NSR) switchover either for a specified period of time or until you manually reestablish the session. Include the idle-after-switch-over (seconds | forever) statement at the [edit protocols bgp] hierarchy level. For seconds, you can configure a value from 1 through 4294967295. After an NSR switchover, the BGP peering session is not reestablished until after the specified period of time. If you specify the forever option, the BGP peering session is not reestablished until you issue the clear bgp neighbor command from the master Routing Engine. The idle-after-switch-over statement is also supported at the BGP group and BGP neighbor hierarchy levels. [Routing Protocols]

Services Applications

• Support for TCP maximum segment size (MSS) adjustment on M-series routers and T-series routing platforms—The TCP protocol negotiates an MSS value during session connection establishment between two peers. The MSS value negotiated is primarily based on the MTU of the interfaces to which the communicating peers are directly connected to. However in the network, due to variation in link MTU on the path taken by the TCP packets, some packets which are still well within the MSS value may be fragmented when the concerned packet's size exceeds the link's MTU.

  To reduce the possibility of fragmentation and to protect against packet loss, include the tcp-mss mss-value statement to specify an appropriate TCP MSS value.

  If the router receives a TCP packet with the SYN bit and MSS option set and the MSS option specified in the packet is larger than the MSS value specified by the tcp-mss statement, the router replaces the MSS value in the packet with the lower value specified by the tcp-mss statement.

  To configure a TCP MSS value, include the tcp-mss statement at the [edit services service-set service-set-name] hierarchy level:

  [edit services service-set service-set-name {tcp-mss mss-value;}

  The range for the tcp-mss mss-value parameter is from 536 to 65,535.

  To view statistics of SYN packets received and SYN packets whose MSS value is modified, issue the show services service-sets statistics tcp-mss operational mode command. [Services Interfaces, System Basics]

• Flow-tap support on additional platforms—Adds support for a version of the flow-tap application on MX-series platforms and on M120 and M320 routers. Unlike the previously released flow-tap application, this functionality resides in the Packet Forwarding Engine rather than in a service PIC. You must configure a service PIC or DPC or a regular tunnel port to provide tunneling.

  To configure the new feature, include the flow-tap-lite statement at the [edit services] hierarchy level and assign the designated tunnel interface for use by the dynamic flow capture process (dfcd). The original flow-tap feature and the new version share the same Dynamic Tasking Control Protocol (DTCP) SSH architecture to install the DTCP filters and authenticate users. [Services Interfaces, Feature Guide]

• Border gateway function (BGF) and Integrated Multi-Service Gateway (IMSG) support on MX platform—Adds support for BGF and IMSG features on MultiServices DPCs on MX-series routers. This functionality was previously released on services PICs running on M-series and T-series routing platforms. [Services Interfaces, Multiplay Solutions, DPC Guide, System Basics and Services Command References]
• Call admission control (CAC) for Border Signaling Gateway (BSG)—Enables you to configure a policy action to prevent voice traffic congestion and to ensure that there is enough bandwidth for authorized flows. CAC is applied during the call setup phase. You configure admission control rules in named objects called controllers. For each controller you configure, you can specify:
  • Maximum number of concurrent dialogs and out-of-dialog transactions
  • Maximum rate of dialog and out-of-dialog transaction attempts per second
  • Committed burst size (number of dialogs and out-dialog-transactions)

  When a call cannot be admitted due to a CAC violation, the call request is rejected with a code 403.

  To configure a controller file, enter the controller-name statement at the [edit services border-signaling-gateway gateway gateway-name admission-control] hierarchy level.

  To enforce the admission control on dialogs, enter the following statements at the [edit services border-signaling-gateway gateway gateway-name admission-control controller-name dialogs] hierarchy level: maximum-concurrent, committed-attempts-rate, committed-burst-size.

  To enforce admission control on transactions, enter the following statements at the [edit services border-signaling-gateway gateway gateway-name admission-control controller-name transactions] hierarchy level: maximum-concurrent, committed-attempts-rate, committed-burst-size.

  To assign a CAC controller to a policy action, enter the admission-control statement at the [edit services border-signaling gateway gateway-name new-transaction-policy policy-name term term-name then] hierarchy level.

  You can use the following show commands to display information about call admission control:

  • show services border-signaling-gateway by-contact contact detailed gateway gateway-name
  • show services border-signaling-gateway by-request–uri request–uri detailed gateway gateway-name
  • show services border-signaling-gateway admission-control gateway gateway-name

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

• MultiServices PICs support on the JCS 1200—MultiServices 500 PICs running Layer 3 services packages are now supported on the JCS 1200. [JUNOS PSD Configuration Guide]
• TWAMP support extension—Support has been added for existing RPM Two-Way Active Measurement Protocol (TWAMP) functionality on MX-series routers that do not have MultiServices DPCs installed.

  To configure TWAMP, include the twamp statement at the [edit services rpm] hierarchy as previously documented, but do not specify the twamp-server statement for any interface. There are no new CLI statements associated with this feature and the existing operational commands function as documented. [Services Interfaces]

• RPM TWAMP enhancements—Adds support for TWAMP functionality on MultiServices PICs configured in Layer 3 mode. Also adds support for encryption and authentication mode, based on RFC 4656.

  To configure the mode, include the authentication-mode statement at the [edit services twamp server] hierarchy level and specify the value authenticated or encrypted. [Services Interfaces]

• Flow aggregation template enhancements—Adds the following new fields to the flow record templates used for version 9 flow aggregation:

  • IPv4 template—Adds IPv4 next-hop address
  • IPv6 template—Adds IPv6 next-hop address, OIF egress interface, and BGP source and destination AS numbers
  • MPLS template—Adds MPLS EXP information
  [Services Interfaces, Feature Guide]
• Integrated Multi-Service Gateway (IMSG) support for BGF state changes and load balancing (M120, M320, and T640 platforms)—A virtual border gateway function (BGF) that is controlled by the BSG supports the full set of virtual BGF state changes (in-service and out-of-service). To display the current state of the virtual BGF, check the status field that is displayed using the show services pgcp active-configuration command. The BGF also supports distributed virtual BGF load balancing using a round-robin algorithm. [Multiplay Solutions, CR:System Basics and Services]
• Border Gateway Function (BGF) user interface enhancements—Enhanced formats for operational commands and trace options configuration statements provide greater flexibility for monitoring the status of virtual BGFs.

  Operational Commands

  For ease of operation the CLI now enables the user to present each vBGF separately. The new syntax is show services pgcp xxxxx gateway gw-name, where xxxxx represents the desired display. For example, to display vBGF-5 statistics use show services pgcp statistics gateway vBGF-5 .

  Similarly, to display all existing vBGFs use the wildcard “*” to replace the gateway name: for example, show services pgcp statistics gateway * .

  Trace Options

  You can now configure trace options for extraction and storage of log information for the H.248 stack, the BGF core, and SBC utilities. To configure, include one or more of the following statements at the [edit services pgcp traceoptions flag] hierarchy level: session-trace, h.248-stack, bgf-core, sbc-util.

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

• Border Gateway Function (BGF) preferential handling of emergency calls during overload (M120, M320, and T640 platforms)—Enables the gateway controller and the administrator to provide preferred processing for emergency calls when the BGF is at an overload processing state. The BGF processing queue is divided into three watermarks that you enable and provision. To configure, include the queue-limit-percentage, reject-new-calls-threshold, and reject-all-commands-threshold statements at the [edit services pgcp gateway overload-control] hierarchy level. To display the current enforcement and transaction queue states, issue the show services pgcp active-configuration gateway gateway-name command and review the Usage Counters. [Multiplay Solutions, Services Interfaces, System Basics Command Reference]
• New application-aware access list (AACL) service (MX-series platforms)—Adds support for a new service that uses application names and groups as matching criteria for filtering traffic. AACL is a stateless, rules-based service that can be combined with application identification to enable policies to be applied to flows based on application and application group membership in addition to traditional packet matching rules.

  In JUNOS Release 9.5, AACL is supported only on MultiServices DPCs running on MX-series platforms. It is configured in a similar way to other rules-based services such as NAT, CoS, and stateful firewall. To configure AACL, include rule specifications for match criteria and actions at the [edit services application-aware-access-list] hierarchy level. You can chain AACL rules along with other service rules by including them in a service-set definition at the [edit services service-set] hierarchy level, as previously documented. There are no new operational commands associated specifically with AACL. [Services Interfaces]

• New service for identifying applications—Application identification (APPID) is a component of a larger project to provide Deep Packet Inspection (DPI) functionality on MX-series platforms. The two main features are per-subscriber, per-application group bandwidth control and Intrusion Detection and Prevention (IDP). The APPID feature is used to identify applications as constituents of application groups in TCP/UDP traffic. To configure APPID, include statements at the [edit services application-identification] hierarchy level to specify parameter values for identifying applications, enable or disable application rules, and gather the applications and rules into groups. A new operational command, show/clear application-identification application-system-cache, allows you to view and delete stored cache entries. [Services Interfaces, System Basics, and Services Command Reference]
• IDP functionality extended to MX-series platforms—Adds support for Intrusion Detection and Prevention (IDP) functionality using Deep Packet Inspection (DPI) technology on MX-series platforms equipped with MultiServices DPCs. This feature set is already supported on J-series platforms and is described in J-series Services Router documentation. To configure IDP properties, include statements at the [edit security idp] hierarchy level. You configure IDP processes by including the idp-policy statement at the [edit system processes] hierarchy level. To specify an IDP profile, include the new idp-profile statement at the [edit services service-set] hierarchy level. To configure SNMP IDP objects, include the idp statement at the [edit snmp health-monitor] hierarchy level. Operational commands for monitoring and regulating IDP activity use the clear/request/show security idp command syntax. [J-series Services Router Guides, Services Interfaces]
• Local policy decision functionality for application-related services (MX-series platforms)—Adds support for a new process that regulates collection of statistics related to applications and application groups and tracking of information about dynamic subscribers. This functionality is collectively named the local policy decision function (L-PDF); in JUNOS Release 9.5 it is supported only on MX-series platforms equipped with MultiServices DPCs. The application identification (APPID) service defines the applications and how they are grouped. The application-aware access list (AACL) service defines the applications and application groups for which statistics are collected for a specific user or interface. The L-PDF configuration defines the way in which the statistics are output.

  To configure properties for statistics output, include the policy-decision-statistics-profile statement at the [edit accounting-options] hierarchy level. A new traceoptions configuration is available at the [edit services local-policy-decision-function] hierarchy level. To configure a dynamic profile to attach a specified service-set to an interface, include the service statement at the [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number family inet] hierarchy level. The following new operational commands are supported:

  • show services statistics
  • show services application-aware-access-list statistics
  • show services flows

  [Services Interfaces, System Basics and Services Command Reference]

Software Installation and Upgrade

• Subscriber interface creation licensing support (MX-series routers)—To enable some router scaling levels, you must purchase, install, and manage separate software license packs. This release supports subscriber interface creation limits. The presence on the router of the appropriate software license keys (passwords) determines how many subscriber interfaces you can configure for use with the JUNOS Subscriber Access Feature Pack.

  For information about how to purchase JUNOS software licenses, contact your Juniper Networks sales representative. [Software Installation and Upgrade Guide]

Subscriber Access Management

• Extended DHCP relay proxy (MX-series routers)—The extended DHCP relay proxy mode feature supports subscriber access management. The DHCP relay proxy supports all features of the DHCP relay. However, while the extended DHCP relay is virtually transparent, DHCP clients see the DHCP relay proxy as the DHCP server, and the actual DHCP server sees the DHCP relay proxy as a DHCP relay that communicates with clients.

  DHCP relay proxy helps improve security for service providers by hiding internal DHCP servers from the view of the attached DHCP clients and providing denial of service (DOS) protection. Also, in a network with multiple DHCP servers, DHCP relay proxy reduces access network traffic by forwarding a single lease to a client. In contrast to the extended DHCP relay, the extended DHCP relay proxy can be used in a logical router.

  To configure DHCP relay proxy support, include the proxy-mode statement at the [edit forwarding-options dhcp-relay overrides] hierarchy level or the [edit forwarding-options dhcp-relay group overrides] hierarchy level.

  The extended DHCP relay proxy is not compatible with the J-series DHCP server. Also, you cannot configure both the extended DHCP relay proxy and the extended DHCP local server on the same interface. [Subscriber Access]

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

  • Number of subscriber VLANs per DPC: 16,000
  • Number of subscriber VLANs per chassis for MX-240 routing platform, which accommodates 2 DPCs: 32,000
  • Number of subscriber VLANs per chassis for MX-480 and MX-960 routing platforms: 64,000
  • Number of DHCP bindings: 120,000
• Mobile IP supports multiple logical routers and routing instances (MX-series routers)—You can now configure the Mobile IP home agent feature independently in any named routing instance in any configured logical router. Previously, Mobile IP supported only the default routing instance and default logical router.

  The CLI has been enhanced to add the services hierarchy to the following additional hierarchies:

  • [edit logical-systems logical-system-name]
  • [edit routing-instances routing-instances-name]
  • [edit logical-systems logical-system-name routing-instances routing-instances-name]

  This feature enables you to configure a Mobile IP subscriber in a routing instance in a specific logical router based on the vendor-specific attributes (VSAs) returned from the RADIUS server during authentication of the subscriber.

  Multiple logical router and routing instance support is available only when you configure local authentication for Mobile IP. When you instead configure RADIUS authentication, only the default logical router and routing instance are supported.

  Only the local option is available for the order statement; the aaa option is not supported for nondefault logical routers and routing instances. Otherwise, all previously supported Mobile IP configuration statements are available at the new hierarchy levels. [Subscriber Access]

• Support for RADIUS framed-route attribute [22] (M120, M320, and MX-series Routers)—Enables you to configure the RADIUS Framed-Route Attribute [22] for Access-Accept and CoA-Request messages. The Framed-Route attribute enables you to provide routing information to be configured for the subscriber on the NAS.

  The format for the string is:

  addr [/maskLen] [nexthop [cost]] [tag tagValue] [distance distValue]

  [Subscriber Access]

• Support for dynamic configuration of framed routes and addresses (M120, M320, and MX-series routers)—Enables you to configure framed routes and addresses in a dynamic profile. The values for the framed route and addresses are dynamically supplied to subscriber interfaces using RADIUS attributes.

  Framed routes are used so traffic from the subsets can traverse the subscriber interface. By applying framed routes, you can extend the per-subscriber interface management to any subnetworks behind the dynamic subscriber interface.

  To dynamically configure framed routes using values specified in Framed-Route Attribute [22], include the new junos-framed-route-ip-address-prefix variable with the route statement at the [edit dynamic profiles profile-name routing-options access] hierarchy level. For each route, you can configure variables for the next-hop IP address (junos-framed-route-nexthop), the cost metric (junos-framed-route-cost), and the preference value (junos-framed-route-distance).

  Configuring support for access-internal variables is optional, but it ensures that if the next-hop value is missing in the Framed-Routes Attribute [22], values from the access-internal variables are used instead. To configure access-internal variables, include the new junos-subscriber-ip-address variable with the route statement at the [edit dynamic profiles profile-name routing-options access-internal] hierarchy level. For each access-internal variable, you can configure variables for the qualified next-hop (junos-underlying-interface) and the MAC address (junos-mac-address).

  To monitor framed routes, issue the show route protocol access command. To monitor access-internal variables, issue the show route protocol access-internal command.

  [Subscriber Access]

• Enhancement of client firewall filter and CoS attribute aggregation (MX-series routers)—Using the aggregate-clients statement in DHCP local server and DHCP relay agent dynamic profile configurations enable multiple DHCP clients to share the same VLAN logical interface (for example, multiple clients belonging to the same household). By default, the aggregate-clients feature is disabled and a single DHCP client is allowed per VLAN when a dynamic profile is associated with the VLAN logical interface.

  In this release the aggregate-clients statement enables you to either merge (the default action; available in a previous release) or replace the firewall filters, CoS schedulers, and IGMP configuration of multiple DHCP clients that share the same VLAN logical interface. When you choose to merge software components, the behavior is as follows:

  • Firewall filters—The filters are chained together using the precedence as the order of execution. If the same firewall filter is attached multiple times, the filter is executed only once.
  • CoS schedulers—The different CoS schedulers are merged as if the scheduler map has multiple schedulers. The merge operation for the individual traffic-control-profiles parameters (shaping-rate, delay-buffer-rate, guaranteed-rate) preserves the maximum value for each parameter.
  • IGMP configuration—The current IGMP configuration is replaced with the configuration of the newest DHCP client.

  When you choose to replace software components, each new client session replaces the previous session.

  You can configure the aggregate-clients attribute for all interfaces or for groups of interfaces. This feature supports static VLANs. [Subscriber Access]

• ANCP individual VLAN support and neighbor configuration enhancements (MX-series routers)—ANCP is now supported on individual VLANs. Previously, ANCP was supported only on groups of VLANs (interface sets) carrying services to a subscriber. Now you can configure ANCP on individual logical interfaces for single VLANs that carry services to a subscriber.

  To configure ANCP for an individual VLAN, include the access-identifier statement at the [edit protocols ancp interfaces interface-name] hierarchy level. The access identifier no longer has to be unique across the router. Now it must only be unique for individual ANCP neighbors. You must specify neighbor ip-address in the access-identifier statement when the access identifier is unique only for a neighbor.

  You can now configure the maximum number of discovery table entries accepted from neighbors. To configure this limit globally for all ANCP neighbors, include the maximum-discovery-table-entries statement at the [edit protocols ancp] hierarchy level.

  You can now specify several ANCP parameters for individual neighbors in addition to setting global parameters for all neighbors. Individual neighbor configurations take precedence over the global configuration.

  To configure individual neighbor parameters, you can include any of the following statements at the [edit protocols ancp neighbor ip-address] hierarchy level:

  • adjacency-timer—Specify the interval between adjacency messages sent to this ANCP neighbor.
  • discovery-mode—This statement currently has no effect. By default, topology discovery is enabled globally for all neighbors and cannot be disabled.
  • ietf—Specify that the neighbor is running in IETF mode. This statement is not available at the [edit protocols ancp] hierarchy level for global configuration. By default, ANCP neighbors run in IETF mode. This statement is useful when you configure pre-IETF mode globally but want to negate that mode for individual neighbors.
  • maximum-discovery-table-entries—Configure the maximum number of discovery table entries accepted from this neighbor.
  • pre-ietf—Specify that the neighbor is running in pre-IETF mode.

  The output for the show ancp cos and show ancp subscriber commands has been enhanced to support this feature. For access identifers that are not unique across the network, you can issue the show ancp subscriber identifier identifier-string neighbor ip-address command to display subscriber information for a particular neighbor associated with the access identifier. [Subscriber Access, Protocols Command Reference]

• Mobile IP home agent support for WiMAX (MX-series routers)—The Mobile IP home agent can now receive, process, and send Worldwide Interoperability for Microwave Access (WiMAX) vendor-specific RADIUS attributes (VSAs). This feature enables Mobile IP home agent to work in a WiMAX home connectivity services network (HCSN), to provide for mobility management at the IP layer.

  To enable the WiMAX feature for Mobile IP, include the wimax statement at the new [edit services mobile-ip access-type] hierarchy level. To disable the WiMAX feature, include the generic statement at the [edit services mobile-ip access-type] hierarchy level.

  To determine which release and version number of the WiMAX Forum Network Architecture is supported by the current Mobile IP implementation, enter the show mobile-ip wimax release command.

  Reauthentication of WiMAX subscribers is not currently supported. [Subscriber Access, System Basics and Services Command Reference]

• GRES support for dynamically-created IP DEMUX interfaces—GRES now supports IP DEMUX interfaces in a DHCP subscriber access configuration.

System Logging

New and deprecated system log tags—The following system log message is new in this release:

• HNCACHED—This describes messages with the HNCACHED prefix. They are generated by the hostname-caching process.

The following system log messages are new in this release:

• DFWD_POLICER_LIMIT_EXCEEDED
• ESWD_BPDU_BLOCK_ERROR_DISABLED
• ESWD_ST_CTL_BW_INFO
• ESWD_ST_CTL_INVALID_LEVEL
• ESWD_ST_CTL_INVALID_NO_BR
• ESWD_ST_CTL_INVALID_NO_UNKNUNI
• EVENTD_SCRIPT_CHECKSUM_MISMATCH
• LLDPD_PARSE_ARGS
• LLDPD_PARSE_BAD_SWITCH
• LLDPD_PARSE_CMD_ARG
• LLDPD_PARSE_CMD_EXTRA
• LLDPD_PARSE_USAGE
• MIB2D_IF_FLAPPING_MISSING
• PFE_FW_SYSLOG_ETH
• RPD_DYN_CFG_GET_SES_TYPE_FAILED
• RPD_MC_COSD_WRITE_ERROR
• RPD_MPLS_INTERFACE_ROUTE_ERROR
• RPD_MPLS_TABLE_ROUTE_ERROR
• RPD_TASK_DYN_REINIT

The following system log messages are no longer documented:

• RDD_TRACE_FILE_OPEN_FAILED
• RPD_DYN_CFG_BAD_REQ_OPCODE

User Interface and Configuration

• New directory structure and file system access for logical systems—Beginning with JUNOS Release 9.5, logical systems have their own individual directory structure created in the /var/logical-system/logical-system-name directory. This directory contains the following subdirectories:
  • /config—Contains the current operational router configuration specific to the logical system.
  • /log—Contains system log and tracing files specific to the logical system.
  • /tmp—Contains temporary files specific to the logical system.

  Backward compatibility is maintained by creating software links from /var/logs/logical-system-name to /var/logical-systems/logical-system-name.

  The new file system access for each logical system enables logical system users to view trace logs and modify logical system files. Logical system administrators have full access to view and modify all files specific to the logical system.

  [System Basics]

• Support for optionally configuring checksum values to check the integrity of scripts—Enables you to configure checksum values to validate the integrity of commit, operations, and events scripts. The supported hash algorithms for calculating checksum are md5, sha-256, and sha1. You can configure one or more hash algorithms for the checksum values.

  To configure checksum values for commit scripts, include the appropriate hash algorithms at the [edit system scripts commit file file-name checksum] hierarchy level. To configure checksum values for operations scripts, include the appropriate hash algorithms at the [edit system scripts op file file-name checksum] hierarchy level. To configure checksum values for events scripts, include the appropriate hash algorithms at the [edit event-options event-script file file-name checksum] hierarchy level.

  To view the calculated checksum value, issue the file checksum (md5 | sha-256 | sha1) operational mode command. [Automation, System Basics and Services Command Reference]

• Dynamic auto-sensed VLAN support—This release supports the automatic configuration of VLANs and stacked VLANs on static Ethernet interfaces. You can configure a single set of up to 32 ranges per VLAN or stacked VLAN type. When using mixed VLAN tagging, you can configure up to 64 VLANs per port (32 VLANs and 32 stacked VLANs). This feature supports vlan-tagging, stacked-vlan-tagging, and flexible-vlan-tagging (both VLAN tagging and stacked VLAN tagging and on the same port) encapsulations.

  You enable automatic configuration of VLANs by including the vlan-id statement in a dynamic profile at the [edit dynamic-profiles profile-name] hierarchy level and by referencing the dynamic profile in the auto-configure statement at the [edit interfaces interface-name] hierarchy level.

  Using the vlan-id statement, you specify the junos-vlan-id variable for the VLAN ID. This statement and variable combination obtains an actual VLAN ID from a range of VLAN IDs that you specify at the [edit interfaces interface-name ] hierarchy level.

  You enable automatic configuration of stacked VLANS by defining a dynamic stacked VLAN profile and using the vlan-tags statement at the [edit dynamic-profiles] hierarchy level. In the vlan-tags statement, you specify the junos-stacked-vlan-id variable for the outer VLAN ID and the junos-vlan-id variable for the inner VLAN ID. This statement and variable combination obtains an actual outer and inner stacked VLAN ID from a range of VLAN IDs that you specify.

  You define VLAN or stacked VLAN ranges with the auto-configure statement at the [edit interfaces interface-name] hierarchy level. To define VLAN ranges, include the vlan-ranges statement at the [edit interfaces interface-name auto-configure] hierarchy level. You must then specify the dynamic VLAN profile using the dynamic-profile statement at the [edit interfaces interface-name auto-configure vlan-ranges] or [edit interfaces interface-name auto-configure vlan-ranges] hierarchy level, the VLAN interface type (inet) by using the accept statement at the [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile] or [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile] hierarchy level, and finally specify the VLAN ranges that you want accessing clients to use with the ranges statement at the [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile] or [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile] hierarchy level.

  When specifying values for the low-tag and high-tag variables for the vlan-ranges or stacked-vlan-ranges statement, you can define tag ranges from 1 to 4094 or use the any option to specify the use of the entire VLAN range. You can use the clear auto-configuration interfaces interface-name command to manually remove a dynamically-created VLAN or stacked VLAN interface.

  Note: You can only remove dynamically-created VLANs or stacked VLANs when no subscribers are using the interface either directly on that VLAN interface or on a separate IP DEMUX interface using that VLAN as its underlying interface.

  [Network Interfaces, Subscriber Access]

VPNs

• Layer 3 VPN BGP routes and labels—You can now configure Juniper Networks routers to accept larger numbers of Layer 3 VPN BGP updates with unique inner VPN labels by including the l3vpn-composite-nexthop statement at the [edit routing-options] hierarchy level. This feature is available on M120, M320, and MX-series routers. The neighboring PE routers are typically non-Juniper Networks routers configured to assign a unique inner label to each Layer 3 VPN BGP route. The l3vpn-composite-nexthop statement is disabled by default.

  When you configure the l3vpn-composite-nexthop statement and issue the commit command, the BGP session is immediately restarted. For more information, see PR 292173. [VPNs]

• VPLS routing instance prioritization—When a path is rerouted using fast reroute, the Packet Forwarding Engine (PFE) collects all the affected next-hops and changes them to the backup link one after another in no particular order. When a fast reroute event occurs, the time needed to restore connectivity depends on the number of affected next-hops which can lead to longer fast reroute times for all affected traffic. You can now prioritize specific VPLS routing instances for faster fast reroute convergence. The next-hops for a higher priority VPLS routing instance are modified first and therefore the traffic traversing the higher priority VPLS routing instance is restored faster.

  To prioritize a VPLS routing instance, configure the fast-reroute-priority statement at the [edit routing-instances routing-instance-name forwarding-options] hierarchy level. You can configure a priority of high, medium, or low. [VPNs]

• Extranet next-generation MVPN—The extranet next-generation multicast VPN (MVPN) functionality (also known as overlapping MVPNs) allows multicast receivers in a given VRF routing instance to receive traffic from multicast sources in another VRF routing instance. Extranet MVPNs support PIM-ASM or PIM-SSM in customer instances. PIM-DM in customer instances is not supported. Extranet MVPNs require the use of RSVP-TE P2MP LSPs for provider tunnels. Extranet MVPNs also support both inclusive and selective tunnels.

  The following extranet MVPN topologies are supported:

  • The source and receiver are in different VPNs attached to different PE routers.
  • The source and receiver are in different VPNs but attached to the same PE router.
  • Multiple receivers are attached to one PE router but in different VPNs.
  • Prefix-based extranets, where a few selected sources are exported from one VPN to another, are also supported.

  The configuration for extranet next-generation MVPNs relies on existing configuration statements.

  If there is more than one MVPN routing instance on a PE router, extranet next-generation MVPNs require VT interfaces to be configured on all MVPN routing instances on a PE router that is designated to receive traffic from the same source. If there is only one MVPN routing instance on a PE router that has receivers for a particular source, the MVPN routing instance does not need to have a VT interface configured. VT interfaces are not required for unicast routing instances which can still rely upon label-switching interfaces (LSIs).

  PIM-DM is not supported in the MVPN SP core for Draft-Rosen. [VPNs]

• LDP BGP interworking additional platform support—LDP BGP interworking is now supported on the M10i, M40e, M120, and T-series routers and the TX Matrix platform. [VPNs]
• VLAN range for L2 VPN (MX-series)—Supports bundling a list of VLAN IDs on a logical interface and using it for a cross-connect, to enhance existing functionality, dramatically reduce usage of system resources such as logical interfaces and next-hops, and simplify configuration.

  To configure a VLAN ID list, use the vlan-id-list list statement at the [edit interfaces interface-name-fpc/pic/portunit unit-number] hierarchy level.

  To configure a group of VLAN tags, use the vlan-tags <(inner | inner-list list)> statement at the [edit interfaces interface-name-fpc/pic/port] hierarchy level.

  Note: TPID is not supported with inner-list.

  An example configuration for this feature follows:

  interfaces {ge-1/1/0 {vlan-tagging;encapsulation flexible-ethernet-services;unit 10 {encapsulation vlan-ccc;vlan-id-list [20 30-40 45];}}ge-1/1/1 {flexible-vlan-tagging;encapsulation flexible-ethernet-services;unit 10 {encapsulation vlan-ccc;vlan-tags outer 200 inner-list [50-60 80 90-100];}}}

  [Network Interfaces]

• Static pseudowires (M-series and T-series routers)—You can now configure static pseudowires. Static pseudowires are designed for networks that do not support or have not enabled LDP. Without LDP, Layer 2 circuits could not be signaled in previous JUNOS software releases. You enable static pseudowires by configuring static values for the in and out labels needed to bring up a pseudowire connection. You must configure unique labels for the static pseudowire configuration to commit. The ignore-mtu-mismatch, ignore-vlan-id, and ignore-encaps-mismatch statements are not relevant for static pseudowire configurations since there is no way for the peer router to forward this information.

  To configure a static pseudowire, include the static statement at the [edit protocols l2circuit neighbor address interface interface-name] hierarchy level. You must also configure the incoming-label label statement and outgoing-label label statement at the [edit protocols l2circuit neighbor address interface interface-name static] hierarchy level. You can also configure the static statement and sub-statements at the [edit protocols l2circuit neighbor address interface interface-name backup-neighbor neighbor] hierarchy level. If you configure the neighbor as static, you must configure the backup neighbor as static as well.

  Note that when you configure static pseudowires, you need to manually compare the encapsulation, TDM bit rate, and control word of the router with the remote peer router and ensure that they match, otherwise the data path can be affected. For example, data would be forwarded from one end of the pseudowire, but would be dropped at the other end as there is a mismatch in the encapsulation, TDM bit rate, or control word.

  You can also make it possible to ping a static pseudowire by configuring the send-oam statement at the [edit protocols l2circuit neighbor address interface interface-name static] hierarchy level. If you configure the send-oam statement, it applies to the backup neighbor as well. Once you have enabled this statement, you can ping the static pseudowire by issuing the ping mpls l2circuit command.

  The command output of the show l2circuit connection command has been modified to indicate if a pseudowire on a router is static. The Layer 2 circuit interface is labeled with SP (meaning static pseudowire). [VPNs]

JUNOS XML API and Scripting

• New JUNOS XML API operational request tag elements—Table 1 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 9.5, 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 9.5

  Request Tag Element	CLI Command	Response Tag Element
  <clear-ancp-subscriber-identifier-information>	clear ancp subscriber identifier	<ancp-subscriber-identifier-information>
  <clear-mpls-lsp-information>	clear mpls lsp	NONE
  <clear-elmi-statistics>	clear oam ethernet lmi statistics	NONE
  <clear-ospf-database-information>	clear ospf database	NONE
  <clear-ospf-io-statistics-information>	clear ospf io-statistics	NONE
  <clear-ospf-neighbor-information>	clear ospf neighbor	NONE
  <clear-ospf-overload-information>	clear ospf overload	NONE
  <clear-ospf3-database-information>	clear ospf3 database	NONE
  <clear-ospf3-io-statistics-information>	clear ospf3 io-statistics	NONE
  <clear-ospf3-neighbor-information>	clear ospf3 neighbor	NONE
  <clear-ospf3-overload-information>	clear ospf3 overload	NONE
  <clear-ospf3-statistics-information>	clear ospf3 statistics	NONE
  <clear-rsvp-session-information>	clear rsvp session	NONE
  <clear-rsvp-counters-information>	clear rsvp statistics	NONE
  <clear-idp-application-system-cache>	clear security idp application-identification application-system-cache	<idp-applications-information>
  <clear-service-msp-flow-table-information>	clear services flows	<service-msp-flow-drain-information>
  <clear-service-pgcp-gates-gateway>	clear services pgcp gates gateway	<service-pgcp-gates-gateway-drain-information>
  <clear-service-pgcp-statistics-gateway>	clear services pgcp statistics gateway	<service-pgcp-statistics-gateway-drain-information>
  <request-ping-l2circuit-interface>	ping mpls l2circuit interface	NONE
  <request-ping-l2circuit-virtual-circuit>	ping mpls l2circuit virtual-circuit	NONE
  <request-ping-l2vpn-instance>	ping mpls l2vpn instance	NONE
  <request-ping-l2vpn-interface>	ping mpls l2vpn interface	NONE
  <request-ping-l3vpn>	ping mpls l3vpn	NONE
  <request-ping-ldp-lsp>	ping mpls ldp	NONE
  <request-ping-lsp-end-point>	ping mpls lsp-end-point	NONE
  <request-ping-rsvp-lsp>	ping mpls rsvp	NONE
  <request-ping-vpls-instance>	ping vpls instance	NONE
  <request-appid-application- package-uninstall>	request services application-identification uninstall	<appid-apppack-uinstall>
  <check-in-service-upgrade>	request system software validate in-service-upgrade	NONE
  <get-environment-cip-information>	show chassis environment cip	<environment-component-information>
  <get-cos-multi-destination-information>	show class-of-service multi-destination	<cos-multi-destination-information>
  <get-isis-backup-coverage-information>	show isis backup coverage	<isis-backup-coverage-information>
  <get-isis-backup-lsp-information>	show isis backup label-switched-path	<isis-backup-lsp-information>
  <get-isis-backup-spf-results-information>	show isis backup spf results	<isis-backup-spf-results-information>
  <get-mip-wimax-release-information>	show mobile-ip wimax release	<mip-wimax-release-information>
  <get-evc-infromation>	show oam ethernet evc	<elmi-evc-information>
  <get-elmi-information>	show oam ethernet lmi	<elmi-interface-information>
  <get-elmi-statistics>	show oam ethernet lmi statistics	<elmi-interface-statistics>
  <get-idp-applications-information>	show security idp application-statistics	<idp-applications-information>
  <get-service-border-signaling- gateway-statistics-admission-control>	show services border-signaling-gateway admission-control	<bsg-statistics-admission-control>
  <get-service-border-signaling- gateway-information-by-contact>	show services border-signaling-gateway by-contact	<bsg-information-details>
  <get-service-border-signaling- gateway-information-by-request-uri>	show services border-signaling-gateway by-request-uri	<bsg-information-details>
  <get-service-border-signaling- gateway-statistics-calls>	show services border-signaling-gateway calls	<bsg-statistics-calls-details>
  <get-service-border-signaling- gateway-statistics-calls-failed>	show services border-signaling-gateway calls-failed	<bsg-statistics-calls-failed-details>
  <get-service-msp-flow-table-information>	show services flows	<service-sfw-flow-table-information>
  <get-service-pgcp-active- configuration-gateway>	show services pgcp active-configuration gateway	<service-pgcp-active-configuration-gateway>
  <get-service-pgcp- conversation-information-gateway>	show services pgcp conversations gateway	<service-pgcp-conversation-gateway-information>
  <get-service-pgcp-flow- table-information-gateway>	show services pgcp flows gateway	<service-pgcp-flow-table-gateway-information>
  <get-service-pgcp-gate>	show services pgcp gate	<service-pgcp-gate>
  <get-service-pgcp-gate-gateway>	show services pgcp gate gateway	<service-pgcp-gate-gateway>
  <get-services-pgcpd-root- termination-gateway>	show services pgcp root-termination gateway	<services-pgcpd-root-termination-gateway>
  <get-service-pgcp-terminations-gateway>	show services pgcp terminations gateway	<service-pgcp-terminations-gateway>
  <get-service-set-plugin- summary>	show services service-sets plug-ins	<service-set-plugin-summary>
  <get-service-set-tcp-mss-statistics>	show services service-sets statistics tcp-mss	<service-set-tcp-mss-statistics>
  <get-name-resolution-info>	show system name-resolution	<name-resolution-info>

  [JUNOS XML API Operational Reference]

Related Topics

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