Junos Release Notes 10.0

® ®
Juniper Networks JUNOS 10.0 Software

Release Notes
Release 10.0R4
04 February 2011
Revision 9
These release notes accompany Release 10.0R4 of the JUNOS Software. They describe
device documentation and known problems with the software. JUNOS Software runs
on all Juniper Networks M Series, MX Series, and T Series routing platforms, SRX
Series Services Gateways, J Series Services Routers, and EX Series Ethernet Switches.
You can also find these release notes on the Juniper Networks JUNOS Software
Documentation Web page, which is located at
http://www.juniper.net/techpubs/software/junos.
Contents JUNOS Software Release Notes for Juniper Networks M Series Multiservice
Edge Routers, MX Series Ethernet Service Routers, and T Series Core
Routers .....................................................................................................6
New Features in JUNOS Release 10.0 for M Series, MX Series, and T
Series Routers ....................................................................................6
Class of Service ..................................................................................6
High Availability .................................................................................7
Interfaces and Chassis ........................................................................8
JUNOScope .......................................................................................16
JUNOS XML API and Scripting ..........................................................17
Layer 2 Ethernet Services .................................................................19
MPLS Applications ............................................................................22
Multicast ...........................................................................................22
Network Management ......................................................................24
Routing Protocols .............................................................................24
Services Applications ........................................................................26
Subscriber Access Management .......................................................29
System Logging ................................................................................35
■ 1
JUNOS 10.0 Software Release Notes
User Interface and Configuration ......................................................38

VPNs ................................................................................................39
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M
Series, MX Series, and T Series Routers ............................................42
Class of Service ................................................................................42
Forwarding and Sampling ................................................................42
Interfaces and Chassis ......................................................................42
MPLS Applications ............................................................................47
Multiplay ..........................................................................................47
Platform and Infrastructure ..............................................................47
Routing Protocols .............................................................................47
Services Applications ........................................................................48
Subscriber Access Management .......................................................49
VPNs ................................................................................................52
Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series
Routers .............................................................................................54
Current Software Release .................................................................54
Previous Releases .............................................................................79
Errata and Changes in Documentation for JUNOS Software Release 10.0
for M Series, MX Series, and T Series Routers ................................104
Changes to the JUNOS Documentation Set .....................................104
Errata .............................................................................................104
Upgrade and Downgrade Instructions for JUNOS Release 10.0 for M
Series, MX Series, and T Series Routers ..........................................108
Basic Procedure for Upgrading to Release 10.0 ..............................108
Upgrade Policy for JUNOS Software Extended End-Of-Life
Releases ...................................................................................111
Upgrading a Router with Redundant Routing Engines ....................111
Upgrading the Software for a Routing Matrix .................................112
Upgrading Using ISSU .....................................................................113
Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled
for Both PIM and NSR ..............................................................113
Downgrade from Release 10.0 .......................................................114
JUNOS Software Release Notes for Juniper Networks SRX Series Services
Gateways and J Series Services Routers ................................................116
New Features in JUNOS Release 10.0 for SRX Series Services Gateways
and J Series Services Routers ..........................................................116
Software Features ...........................................................................117
Hardware Features—SRX100 Services Gateways ...........................138
Hardware Features—SRX210 and SRX240 Services Gateways .......138
Hardware Features—SRX210 Services Gateway with Integrated
Convergence Services (Available in North America Only) .........140
Convergence Services (Available in North America Only) .........142
Hardware Features—SRX650 Services Gateways ...........................144
Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX
Series Services Gateways and J Series Services Routers ..................146
Chassis Cluster ...............................................................................146
Command-Line Interface (CLI) ........................................................147
Configuration .................................................................................147
Flow and Processing .......................................................................148
2 ■
Hardware .......................................................................................149
Interfaces and Routing ...................................................................149
Intrusion Detection and Prevention (IDP) .......................................150
J-Web .............................................................................................150
Management and Administration ...................................................151
Security ..........................................................................................151
WLAN .............................................................................................151
Known Limitations in JUNOS Release 10.0 for SRX Series Services
Gateways and J Series Services Routers ..........................................152
[accounting-options] Hierarchy ......................................................152
AX411 Access Point .......................................................................152
Chassis Cluster ...............................................................................152
Command-Line Interface (CLI) ........................................................154
Dynamic VPN .................................................................................154
Flow and Processing .......................................................................155
fwauth Security ..............................................................................156
Hardware .......................................................................................156
IGMP ..............................................................................................157
Interfaces and Routing ...................................................................157
Integrated Convergence Services ....................................................159
J-Web .............................................................................................160
Network Address Translation (NAT) ................................................161
NetScreen-Remote ..........................................................................161
Performance ..................................................................................161
PPP over Ethernet (PoE) .................................................................161
SNMP .............................................................................................161
System ...........................................................................................161
Unified Threat Management (UTM) ................................................161
VPNs ..............................................................................................162
Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J
Series Services Routers ...................................................................162
Outstanding Issues In JUNOS Release 10.0 for SRX Series Services
Gateways and J Series Services Routers ...................................162
Resolved Issues in JUNOS Release 10.0 for SRX Series Services
Gateways and J Series Services Routers ...................................182
Errata and Changes in Documentation for JUNOS Release 10.0 for SRX
Application Layer Gateways (ALGs) ................................................184
Attack Detection and Prevention ....................................................185
Chassis Cluster ...............................................................................185
CLI Reference .................................................................................185
CompactFlash Card Support ...........................................................185
Feature Support Reference .............................................................185
Flow ...............................................................................................186
Hardware Documentation ..............................................................186
Installing Software Packages ..........................................................187
Integrated Convergence Services ....................................................188
J-Web .............................................................................................189
Power over Ethernet (PoE) .............................................................190
■ 3
Screens ...........................................................................................190
WLAN .............................................................................................190
Hardware Requirements for JUNOS Release 10.0 for SRX Series Services
Gateways and J Series Services Routers ..........................................191
Transceiver Compatibility for SRX Series and J Series Devices .......191
Power and Heat Dissipation Requirements for J Series PIMs ..........191
Supported Third-Party Hardware ....................................................191
J Series CompactFlash and Memory Requirements ........................192
Dual-Root Partitioning Scheme Documentation for SRX Series Services
Gateways ........................................................................................193
Dual-Root Partitioning Scheme .......................................................193
Maximizing ALG Sessions .....................................................................202
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the
Second Routing Engine ..................................................................202
Upgrade and Downgrade Instructions for JUNOS Release 10.0 for SRX
Releases ...................................................................................204
JUNOS Software Release Notes for EX Series Switches ................................205
New Features in JUNOS Release 10.0 for EX Series Switches ................205
Hardware .......................................................................................205
Access Control and Port Security ....................................................206
Bridging, VLANs, and Spanning Trees ............................................206
Ethernet Switching .........................................................................206
Interfaces .......................................................................................207
Layer 2 and Layer 3 Protocols ........................................................207
Management and RMON ................................................................207
Packet Filters ..................................................................................208
Port Mirroring .................................................................................208
Virtual Chassis ................................................................................208
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for EX
Series Switches ...............................................................................209
User Interface and Configuration ....................................................209
Limitations in JUNOS Release 10.0 for EX Series Switches ....................210
Class of Service ..............................................................................210
Infrastructure .................................................................................210
Interfaces .......................................................................................211
Outstanding Issues in JUNOS Release 10.0 for EX Series Switches ........211
Class of Service ..............................................................................212
Firewall Filters ................................................................................213
Hardware .......................................................................................213
Infrastructure .................................................................................213
Interfaces .......................................................................................215
Resolved Issues in JUNOS Release 10.0 for EX Series Switches .............216
Infrastructure .................................................................................216
4 ■
Interfaces .......................................................................................217
Management and RMON ................................................................217
Errata in Documentation for JUNOS Release 10.0 for EX Series
Switches .........................................................................................217
Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series
Switches .........................................................................................218
Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series
Switches ..................................................................................218
Releases ...................................................................................219
Upgrading from JUNOS Release 9.3R1 to Release 10.0 for EX Series
Switches ..................................................................................219
Upgrading from JUNOS Release 9.2 to Release 10.0 for EX Series
Switches ..................................................................................219
Downgrading from JUNOS Release 10.0 to Release 9.2 for EX4200
Switches ..................................................................................221
JUNOS Documentation and Release Notes ..................................................222
Documentation Feedback ............................................................................222
Requesting Technical Support .....................................................................222
Revision History ..........................................................................................224
■ 5
JUNOS Software Release Notes for Juniper Networks M Series Multiservice Edge
Routers, MX Series Ethernet Service Routers, and T Series Core Routers
■ New Features in JUNOS Release 10.0 for M Series, MX Series, and T Series
Routers on page 6
■ Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M Series,
MX Series, and T Series Routers on page 42
■ Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series
Routers on page 54
■ Errata and Changes in Documentation for JUNOS Software Release 10.0 for M
Series, MX Series, and T Series Routers on page 104
■ Upgrade and Downgrade Instructions for JUNOS Release 10.0 for M Series, MX
Series, and T Series Routers on page 108
New Features in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
The following features have been added to JUNOS Release 10.0. Following the
description is the title of the manual or manuals to consult for further information.
Class of Service
■ Class-of-service support for PBB (MX Series routers)—Enables quality-of-service

(QoS) information to be mapped and carried across a provider backbone bridge
(PBB). In IEEE standard (802.1ah) networks, information is mapped and carried
across the network using three priority code point (PCP) bits and one drop
eligibility indicator (DEI) bit. The PCP and DEI bits are present in the service
VLAN, Backbone Service Instance Identifier (BSID).
To provide appropriate QoS treatment inside the MX Series router and transport
QoS information across the network, it is important to provide capabilities to
classify and rewrite (mark) the PCP and DEI from one tag to another.
Behavior aggregate classification classifies a packet into various forwarding
classes (FCs) and packet loss priorities (PLPs) based on certain fields of the packet.
A VLAN-tagged logical interface can be configured to classify packets based on
the PCP and DEI using the existing IEEE 802.1p (only PCP) or IEEE 802.1ad (PCP
and DEI) classifier.
To classify packets for a VLAN-tagged logical interface based only on PCP, include
the ieee-802.1 statement at the [edit class-of-service interfaces interface-name unit
unit-number classifiers] hierarchy level. To classify packets based on the PCP and
DEI, include the ieee-802.1ad statement at the same hierarchy level.
A rewrite rule sets the appropriate CoS bits in the outgoing packet, thus allowing
the next downstream device to classify the packet into the appropriate service
group. A VLAN-tagged logical interface can be configured to rewrite the PCP and
DEI classifier of outgoing packets based on the forwarding class and the loss
priority using IEEE 802.1p (PCP) or IEEE 802.1ad (PCP and DEI) rewrite rules.
To rewrite packets for a VLAN-tagged logical interface using the existing IEEE
802.1p (PCP) rewrite rules, include the ieee-802.1 statement at the [edit
6 ■ JUNOS Software Release Notes for Juniper Networks M Series Multiservice Edge Routers, MX Series Ethernet Service Routers,
and T Series Core Routers
class-of-service interfaces unit unit-number rewrite-rules] hierarchy level. To classify

packets based on the IEEE 802.1ad (PCP and DEI) rewrite rules, include the
ieee-802.1ad statement at the same hierarchy level.
To further support CoS for PBB, new ISID and DEI terms are available when
configuring firewall filters. Include terms at the [edit firewall family bridge filter
filter-name term term-name] hierarchy level.
[Class of Service]
■ Assigning forwarding class and DSCP value for Routing Engine generated
traffic—You can set the forwarding class and DSCP for traffic originating in the
Routing Engine. To configure these forwarding class and DSCP (for Routing
Engine generated traffic only), apply an output filter to the loopback (lo.0)
interface and set the appropriate forwarding class and DSCP configuration for
various protocols. When you specify DSCP as a binary value, you must prefix it
with the character ‘b’. For example, use b100110 instead of 100110. This is
applicable in all places a binary DSCP value is specified under the firewall
hierarchy.
[Class of Service]
High Availability
■ Integrated Multi-Service Gateway (IMSG) high availability call continuity (MX

Series routers)—Provides additional high availability functionality for the border
signaling gateway (BSG) by maintaining the SIP state of active calls in the event
of a switchover. The feature prevents the loss of call state and thereby prevents
the failure of in-dialog changes such as call hold, re-invite, refer for call transfer,
ending a call, and so on. The call continuity feature includes synchronization of
state between the master and backup PIC and software fault tolerance.
You can use the following command to display the high availability status of a
BSG: show services border-signaling-gateway status gateway gateway-name.
[Multiplay Solutions, System Basics Command Reference]
■ In-service software update (ISSU) (T Series Core Routers and TX Matrix routers
with ST-FPC1, ST-FPC2, and ST-FPC4.1)—Support for ISSU is now available on
T Series Core Routers and TX Matrix routers with new Flexible PIC Concentrators:
■ ST-FPC1
■ ST-FPC2
■ ST-FPC4.1
[High Availability]
■ Unified ISSU support for ESE major version change—Starting with JUNOS
Release 10.0, the JUNOS Software unified ISSU supports ESE major version
changes, and ensures that DPCs on MX Series, and the IQE and IQ2E PICs remain
online during the unified ISSU process even if the ESE major versions are
different.
In JUNOS Software releases earlier than Release 10.0, the DPCs on MX Series
Ethernet Services routers, and the IQE and IQ2E PICs were rebooted during the
unified ISSU process if there was a change in the Ethernet Service Engine (ESE)
New Features in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers ■ 7
major versions. However, in JUNOS Release 10.0, only a temporary disruption

in traffic—similar to the one during the hardware update of the Packet Forwarding
Engine and its interfaces where the traffic is halted and discarded—is expected
on DPCs on MX Series, and the IQE and IQ2E PICs, during the unified ISSU if
the ESE major versions are different across the JUNOS Software releases. In such
cases, the MAC interface statistics and the dynamic MAC entries are lost during
the unified ISSU, and the dynamic MAC entries are relearned after the unified
ISSU. All other statistics, including the static MAC entries, are maintained across
the unified ISSU.
[High Availability]
■ Nonstop active routing support on TX Plus Matrix router—JUNOS Release
10.0 extends the nonstop active routing support to TX Plus Matrix routers and
T1600 routers connected to a routing matrix.
[High Availability]
■ Enhancements to unified ISSU support on PICs—JUNOS Release 10.0 introduces
the following enhancements to the unified ISSU support on PICs:
■ Adds unified ISSU support to the following PICs:
■ PB-1CHOC12-STM4-IQE-SFP, 1-port channelized OC12/STM4 enhanced
IQ PIC
■ PB-1OC12-STM4-IQE-SFP, 1-port non-channelized OC12/STM4 enhanced
IQ PIC
■ PB-4CHDS3-E3-IQE-BNC, 4-port channelized DS3/E3 enhanced IQ PIC
■ PB-4DS3-E3-IQE-BNC, 4-port non-channelized DS3/E3 enhanced IQ PIC
■ Extends the unified ISSU support on the 4-port 10-Gigabit Ethernet PIC
(PD-4XGE-XFP) to TX Matrix routers
■ Enhances the unified ISSU support on 1-port channelized OC48/STM16

enhanced IQ PIC (PB-1CHOC48-STM16-IQE) to include support for CoS
scalability features.
[High Availability]
Interfaces and Chassis
■ ATM IMA and ATM PWE3 support on Circuit Emulation (CE) PICs—M7i, M10i,
M40e, M120, and M320 routers with 4-port COC3 CE PICs and 12-port T1/E1
CE PICs now support ATM IMA and ATM PWE3.
The 12-port T1/E1 PIC supports discrete T1 ATM IMA and the 4-port COC3 PIC
supports CHOC3/STM1 (down to T1) ATM IMA.
The following protocols are supported:

■ ATM (IMA) at T1/E1 level (up to 4 IMA groups with 2 to 8 IMA links each)
■ ATM PWE3 via dynamic labels (LDP, RSVP-TE), static labels are not required
■ ATM over PWE3 (RFC 4717)
8 ■ New Features in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
For information on configuration, see the Network Interfaces Configuration Guide.

[Network Interfaces]
■ New CBP and PIP pseudo-logical interfaces supported (MX Series routers)—For
carrier Ethernet networks, you can configure a connection between a customer
routing instance (PBN or PBBN I-component) and a provider routing instance
(PBBN B-component).
A customer backbone port (CBP) is a backbone edge bridge port that can receive
and transmit I-tagged frames for multiple customers, and assign B-VIDs and
translate I-SID on the basis of the received I-SID. A CBP is configured in the
B-component of PBBN edge bridge.
A provider instance port (PIP) is configured in the I-component of the PBBN edge
bridge and contains a set of multiplexed VIPs.
Configure CBP and PIP pseudo-logical interfaces in the same way that you
configure other logical interfaces in the JUNOS Software. To configure a CBP or
PIP interface, include the cbp or pip statement at the [edit interface unit
logical-unit-number] hierarchy level, then associate the interface to a routing
instance by including the interface [cbp | pip] statement at the [edit
routing-instances instance-name] hierarchy level.
■ Rate limiting of Ethernet OAM messages—M Series, M320 with Enhanced III
FPC, M120, M7i and M10 with CFEB, and MX Series routers support rate limiting
of Ethernet OAM messages. Depending on the connectivity fault management
(CFM) configuration, CFM packets are either discarded, sent to the CPU for
processing, or flooded to other bridge interfaces. This feature allows the router
to intercept incoming CFM packets for prevention of DoS attacks.
You can apply rate limiting of Ethernet OAM messages at either of two CFM
policing levels, as follows:
■ Global-level CFM policing—Uses a policer at the global level to police the
CFM traffic belonging to all the sessions.
■ Session-level CFM policing—Uses a policer created to police the CFM traffic
belonging to one session.
To configure global-level CFM policing, use the policer statement and its options
at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level.
To configure session-level CFM policing, use the policer statement at the [edit
protocols oam ethernet connectivity-fault-management maintenance-domain name
level number maintenance-association name] hierarchy level.
■ New interface range commands—Enable you to group a range of identical
interfaces and apply a common configuration for that group of interfaces with
a reduced number of configuration statements.
To configure an interface range group, include the interface-range statement and
substatements at the [edit interfaces] hierarchy level.
To view an interface range in expanded configuration, use the show | display
inheritance command.
■ Multi-chassis link aggregation (MC-AE)—MX Series routers with Aggregated
Ethernet PICs are an improvement over regular LAG, allowing one device to form
a logical LAG interface with two or more other devices. MC-AE provides additional
benefits over the traditional LAG in terms of node level redundancy, multi-homing
support, and loop-free Layer 2 network without running STP.
On one end of the MC-AE is an MC-AE client device (MC-AE-C) which has one or
more physical links in an LAG. This client device does not need to be aware of
MC-AE. On the other side of the MC-AE are two or more MC-AE network devices
(MC-AE-N). Each network devices has one or more physical links connected to
a single client device. The MC-AE-N network devices coordinate with each other
to ensure that data traffic is forwarded properly.
This MC-AE implementation supports the following:

■ Active-Standby mode using LACP.
■ MC-AE is supported only between two chassis.
■ L2CKT functions with ether-ccc encapsulation.
■ VPLS functions with ether-vpls and vlan-vpls.
■ Network triangle and square topology (limitations apply, see the Network
Interfaces Configuration Guide).
■ PW status-tlv with independent mode.
■ LACP (limitations apply, see the Network Interfaces Configuration Guide).
■ Inter-chassis control protocol.
This MC-AE implementation does not support the following:

■ ICL-PL
■ MC-AE square topology
■ L2VPN
■ BGP-VPLS
To configure MC-AE, use the aggregated-ether-options mc-ae statement and its

options at the [edit interfaces aen] hierarchy level.
■ Unicast and multicast packet classification on the egress interface—For the
IQ, IQ2, IQE, LSQ, and ATM2 PIC interfaces, you can configure a mapping table
to map the forwarding class to a user-configured queue number to apply to
unicast and multicast traffic on egress. To configure packet classification by
egress interface, first configure a forwarding class map and one or more queue
numbers for the egress interface at the [edit class-of-service
forwarding-classes-interface-specific forwarding-class-map-name] hierarchy level,
then apply the map to the logical interface using the output-forwarding-class-map
statement at the [edit class-of-service interface interface-name unit

logical-unit-number] hierarchy level.
[Class of Service]
■ CFM support for PBB (MX Series routers)—IEEE 802.1ag Connectivity Fault
Management (CFM) provides fault isolation and detection over large Layer 2
networks which may span several service provider networks. You can configure
CFM to monitor, isolate, and verify faults in the network.
Provider backbone bridges (PBB) define architecture and bridge protocols for
interconnection of multiple provider bridge networks (PBNs). A provider backbone
bridged network (PBBN) comprises a set of backbone edge bridges (BEBs)
interconnected by some or all of the S-VLANs supported by a PBN. The SVLANs
used to encapsulate customer frames are known as backbone VLANs (B-VLANs).
The Operation, Administration, and Maintenance (OAM) protocol is enabled by
customers, service providers, and network operators in their respective
maintenance domains to provide fault isolation and detection in a PBBN network.
In the OAM protocol, the end nodes in maintenance domains are called
maintenance end points (MEPs) and initiate OAM processes. MEPs are configured
for the B-component of the BEB. MEPs can be configured in either a downstream
or upstream direction.
Intermediate nodes respond to OAM processes and are called maintenance
intermediate points (MIPs). MIPs are configured for the I-component of the BEB.
Using MEPs and MIPs, CFM provides end-to-end connectivity in the BVLAN.
To configure a MEP or a MIP, include the mep or mip statement at the [edit
protocols oam ethernet connectivity-fault-management maintenance-domain
domain-name maintenance-association] hierarchy level.
The linktrace protocol provides path discovery and fault verification. Linktrace
is enabled by default and can be used whenever an MEP is configured.
To enable the continuity check protocol to provide fault detection and notification,
include the continuity-check statement at the [edit protocols oam ethernet
connectivity-fault-management maintenance-domain domain-name
maintenance-association] hierarchy level.
The loopback protocol (modeled on the standard IP ping) is used to perform fault
verification and isolation after a fault is detected. Loopback, like linktrace, is
enabled by default and can be used whenever an MEP is configured.
■ RFC 4601–compliant PIM hello address list option processing—PIM hello
address list option processing is RFC 4601 compliant. Secondary address list
processing of existing neighbors allows incremental changes. Previously, when
a PIM neighbor’s secondary address list changed, the PIM neighbor was deleted.
This resulted in the deletion of the PIM forwarding state for that neighbor.
■ ATM-to-Ethernet interworking—Supported on M120, M320, and T Series routers;
and supported on MX Series routers with aggregated Ethernet, Gigabit Ethernet,
and 10-Gigabit Ethernet interfaces. This feature is available on all Enhanced
Queuing (EQ) DPCs and Enhanced DPCS for MX Series routers.
To configure Ethernet-ATM interworking for MX Series routers, include the
encapsulation vlan-vci-ccc statement at the [edit interface interface-name] hierarchy
level. To enable the ATM-to-Ethernet interworking cross-connect function, include

the vlan-vci-tagging statement at the [edit interfaces interface-name] hierarchy level.
[Network Interfaces, MX Series Solutions Guide]
■ Packet-based IPsec services (M Series, MX Series, and T Series routers
equipped with services PICs or DPCs)—Adds support for packet-based IPsec
services instead of flow-based service for IPsec tunnels that have any-any match
conditions configured. If the configuration does not specify any match conditions,
flowless IPsec is provided to link-type tunnels and dynamic tunnels in both
dedicated and shared mode. This feature also supports a mix of flowless and
flow-based IPsec within a service set. If a service set has some terms with any-any
match and some terms with conditions specified in the from clause, packet-based
service is provided for any-any tunnels and flow-based service is provided for
other tunnels with selectors.
In addition, the following related CLI statements are now supported:

■ Include the passive-mode-tunneling statement at the [edit services service-set
service-set-name ipsec-vpn-options] hierarchy level to enable tunneling of
malformed packets.
■ Include the anti-replay-window-size statement at the [edit services ipsec-vpn
rule rule-name term term-name then] hierarchy level to specify the size of the
antireplay window.
■ Include the no-ipsec-tunnel-in-traceroute statement at the [edit services

ipsec-vp]n hierarchy level to prevent the IPsec tunnel from being treated as
a next hop. If you configure this statement, TTL is not decremented and no
ICMP error is generated if the packet size exceeds the tunnel MTU value.
■ Include the level statement at the [edit services ipsec-vpn traceoptions]

hierarchy level to set a tracing level for the process.
■ Include the anti-replay-window-size statement at the [edit services service-set

ipsec-vpn-options] hierarchy level to specify the size of the antireplay window.
■ Include the no-anti-replay statement at the [edit services service-set

ipsec-vpn-options] hierarchy level to disable anti-replay check.
■ Include the clear-dont-fragment-bit statement at the [edit services service-set

ipsec-vpn-options] hierarchy level to clear the Don’t Fragment (DF) bit on all
IPv4 packets entering the IPsec tunnel. If the encapsulated packet size
exceeds the tunnel MTU, the packet is fragmented before encapsulation.
■ Include the tunnel-mtu statement at the [edit services service-set

ipsec-vpn-options] hierarchy level to set the maximum transmission unit
(MTU) for IPsec tunnels.
The show services ipsec-vpn ipsec statistics service-set operational mode command
output has been enhanced with several additional fields.
[Services Interfaces, System Basics and Services Command Reference]
■ Graceful Routing Engine switchover (GRES) for IQ2 PICs (JCS1200
platform)—GRES support is enabled for IQ2 PICs installed on the JCS1200 Control
System.
[Protected System Domain]

■ Support for 16-port 10-Gigabit Ethernet Modular Port Concentrator (MPC) on
MX Series routers—MX960, MX480, and M240 routers now support the 16-port
10-Gigabit Ethernet MPC (16x10GE 3D MPC [model numbers
MPC-3D,16XGE-SFPP-R-B, MPC-3D-16XGE-SFPP]) fixed configuration Field
Replaceable Unit (FRU). This MPC contains the JUNOS Trio chipset that provides
scalability in bandwidth, subscribers, and services capabilities of the routers.
The following are some of the key features of the 16x10GE 3D MPC:
■ Contains 16 built-in 10-Gigabit Ethernet ports in groups of 4 each. It does
not contain separate slots for Modular Interface Cards (MICs).
■ Supports up to 120 Gbps of full-duplex traffic.
■ Supports LAN-PHY mode at 10.3125 Gbps.
NOTE: The 16x10GE 3D MPC does not support the WAN-PHY mode.
■ Supports small form-factor pluggable transceivers of the SFP+ standard:

■ 10-GBase-ER (model number: SFPP-10GE-ER)
■ 10-GBase-LR (model number: SFPP-10GE-LR)
■ 10-GBase-LRM (model number: SFPP-10GE-LRM)
■ 10-GBase-SR (model number: SFPP-10GE-SR)
■ Supports an effective line rate of twelve 10-Gigabit Ethernet ports.
■ If all sixteen 10-Gigabit Ethernet ports are used, the line card is
oversubscribed in the ratio of 4:3.
■ Supports one full-duplex 10-Gigabit tunnel interface for each Packet

Forwarding Engine.
■ Supports intelligent oversubscription services.
The 16x10GE 3D MPC supports the following JUNOS Release 9.2 features
supported for MX Series routers:
■ Layer 3 routing protocols and MPLS features
■ Layer 2 features such as VPLS (excluding integrated routing and bridging
(IRB), Layer 2 Spanning Tree Protocol (STP), Operation, Administration, and
Maintenance (OAM), and IGMP snooping)
■ Firewall filters and policers (excluding TCAM)
■ Class-of-service (CoS) features (excluding per-unit scheduler, hierarchical

scheduler, and input queuing features). For more information about
configuring CoS features for this MPC, see the JUNOS Class of Service
Configuration Guide.
For more information about the supported and unsupported JUNOS Software
features for this MPC, see “Protocols and Applications Supported by MX Series
MPCs” in the MX Series Line Card Guide.
To configure a full-duplex 10-Gigabit tunnel interface for each Packet Forwarding
Engine, include the bandwidth statement with the 10g option at the [edit chassis
fpc slot-number pic number tunnel-services] hierarchy level. For example, a
full-duplex 10–Gbps tunnel on a 10–Gigabit Ethernet port can be configured,
while two other 10–Gigabit Ethernet ports on the same Packet Forwarding Engine
can concurrently forward line-rate traffic.
The JUNOS Software introduces the number-of-ports active-ports configuration
statement at the [edit chassis fpc slot-number] hierarchy level. This statement
can be used for enabling or disabling the physical ports on the Packet Forwarding
Engines of the MPC. This configuration can be used for the following purposes:
■ Enabling Switch Control Board (SCB) redundancy—For maximum
bandwidth capabilities (12-port line-rate bandwidth), the 16x10GE 3D MPC
utilizes all available SCBs (3 SCBs for an MX960 router, 2 SCBs for an MX480
and MX 240 router) actively in the chassis.
If SCB redundancy (2+1 SCBs on an MX960 router or 1+1 SCB on an MX480
or MX240 router) is required, ports on the line card can be disabled by setting
the number of usable ports per line card to 8. In this case, the third and
fourth ports (ports 0/2-3, 1/2-3, 2/2-3, 3/2-3) on every Packet Forwarding
Engine are disabled.
■ Ensuring guaranteed bandwidth by preventing oversubscription—The
16x10GE 3D MPC supports one 10-Gigabit tunnel interface for each Packet
Forwarding Engine. The effective line-rate bandwidth of the MPC is 12 ports.
Therefore, configuring a tunnel interface might further result in the Packet
Forwarding Engines being oversubscribed. To prevent such oversubscription
and to ensure a guaranteed bandwidth, include the number-of-ports
configuration statement to disable one or two ports per Packet Forwarding
Engine.
To configure the number of active ports on the MPC, include the number-of-ports
active-ports configuration statement at the [edit chassis fpc slot-number] hierarchy
level:
[edit chassis fpc 4]

number-of-ports 8/12;
Specify either 8 or 12 ports using this statement. When eight active ports are
configured, two ports per Packet Forwarding Engine are disabled, and the LEDs
on the MPC are set to Yellow. When you specify 12 active ports, one port per
Packet Forwarding Engine is disabled and the corresponding LED is set to Yellow.
When you do not include this statement in the configuration, all 16 default ports
on the MPC are active.
NOTE:
■ Committing the configuration after including the number-of-ports active-ports
configuration statement brings down the Ethernet interfaces for all ports on the
MPC before the port configuration becomes active.
■ A minimum of one high-capacity fan tray is necessary for meeting the cooling
requirements of the MPC. The JUNOS Software generates a chassis Yellow alarm,
recommending fan tray upgrade for optimal performance, if the MX router
chassis contains an old fan tray.
[MX Series Line Card Guide, System Basics, Class of Service]

■ New 16-port 10-Gigabit Ethernet MPC with SFP+ (model number:
MPC-3D-16XGE-SFPP)--Supported on MX Series routers. For a list of supported
MPCs, see the MX Series Line Card Guide.
■ Firewall filtering supports nonzero DSCP values—The MX Series 16-port 10
Gigabit Ethernet Line Card now supports parity in firewall filtering features
supported by other platforms as of JUNOS Release 9.2. The only associated CLI
change is that the dscp statement at the [edit firewall family family-name filter
filter-name term term-name from] hierarchy level now accepts nonzero DSCP
values.
■ Support for port-mirroring of CCC, VPLS, and bridged traffic and mirror-once
features—The MX Series 16-port 10 Gigabit Ethernet Line Card now supports
parity in sampling, port-mirroring, and monitoring features supported by other
MX Series routers as of JUNOS Release 9.2. In addition, the port-mirroring of
CCC, VPLS, and bridged traffic and mirror-once features introduced in JUNOS
Releases 9.3 and 9.4 are also supported. There are no associated CLI changes.
■ Annex-B lockout—On M120 routers and M320 routers with Enhanced III FPCs,
the lockout feature for Annex B is supported as described in ITU-T
Recommendation G.841. To configure Annex B lockout, use the lockout statement
at the [edit interfaces so-fpc/pic/port sonet-options aps] hierarchy level. To display
an Annex B lockout configuration, use the show aps extensive command.
■ 4-port Channelized OC12/STM4 (Type 3) PIC—Supported on the T Series routers.
This Type 3 PIC supports T640-FPC3-ES and contains the same features as the
Type 2 PIC.
[PIC Guide]
■ Support for two new AC power supplies on the T640 and T1600 routers—The
T640 and T1600 routers now support two new AC power supplies:
■ Wye three-phase AC power supply
■ Delta three-phase AC power supply
Both redundant AC PEMs in a router must be the same type (wye or delta).
Issue the show chassis hardware, show chassis environment pem commands to
view or verify details of the installed AC power supplies. The JUNOS Software
generates an alarm if power supplies of different types are installed on the same
chassis. To view generated alarms, issue the show system alarms command.
[System Basics and Services Command Reference]
JUNOScope
■ Monitoring pseudowires—Starting with JUNOS Release 10.0, JUNOScope enables

you to monitor traffic and set an alarm when a certain condition occurs. It
involves two main steps:
■ Configure the devices in JUNOScope with the SNMP trap destination. SNMP
trap destinations define the hosts that will receive the SNMP traps that are
generated by the trap group when certain conditions apply. In this way,
JUNOScope is notified about each object on its managed devices without
having to request for any information.
■ Create templates of Remote Monitoring (RMON) events for which the traps
are generated. SNMP makes use of RMON enhancements to the management
information base (MIB) structure to monitor traffic and set an alarm when
a certain condition occurs.
You can also view important attributes of a pseudowire such as jitter, delay,
packet loss, and so on. To use this feature, use the Monitor Pseudowires Wizard
(Provisioning > Pseudowires > Monitoring).
[JUNOScope]
■ Support for diagnostic tests—Starting with JUNOS Release 10.0, JUNOScope
enables you to diagnose any routing problems by running diagnostic commands.
These diagnostic commands allow you to capture and analyze routing platform
control traffic.
JUNOScope supports the following diagnostic commands:

■ Ping—Verifies that the host can be reached over the network. The output is
useful for diagnosing host and network connectivity problems.
■ LSP Ping—Isolates and identifies faults in an MPLS-based network.
■ Traceroute—Displays a list of routers that exist between the device and a

specified destination host. This output is useful for diagnosing a point of
failure in the path from the device to the destination host, and addressing
network traffic latency and throughput problems.
■ BERT Test—Tests the quality of links.
[JUNOScope]
■ Support for Layer 2 virtual packet network (l2vpn) pseudowires—Starting
with Release 10.0, JUNOScope extends its support to the provisioning of
BGP-based l2vpn pseudowires for devices in JUNOScope. The provisioning l2vpn
pseudowires workflow consists of two main tasks: provisioning l2vpn
pseudowires, and filtering and testing l2vpn pseudowires. To use these features,
access Provisioning > Pseudowires > Provisioning l2vpn Pseudowires, as well
as Provisioning > Pseudowires > Filter and Test l2vpn Pseudowires.
JUNOScope also enables you to generate a stitching configuration that connects

an LDP-based l2circuit pseudowire with a BGP-based l2vpn pseudowire, and
push the generated configuration to a selected device. You can create a stitching
configuration between two l2vpn pseudowires, two l2circuit pseudowires, or
between an l2circuit pseudowire and an l2vpn pseudowire. To use this feature,
access Provisioning > Pseudowires > Stitching l2circuit > l2vpn.
[JUNOScope]
JUNOS XML API and Scripting
■ Support for XML output for ping mpls commands—The ping mpls (l2circuit |
l2vpn | l3vpn | ldp | lsp-end-point | rsvp) operational mode commands now support
a request tag element to get XML output that can be used by JunoScope.
[JUNOS XML API Operational Reference]
■ New JUNOS XML API operational request tag elements—Table 1 on page 17
lists the JUNOS Extensible Markup Language (XML) operational request tag
elements that are new in JUNOS Release 10.0, along with the corresponding CLI
command and response tag element.
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.0
Request Tag Element CLI Command Response Tag Element
<clear-aaa-statistics-table> clear network-access aaa statistics <clear-aaa-module-statistics>

clear_aaa_statistics_table
<clear-idp-application-system-cache> clear security idp application-identification <clear-idp-

application-system-cache application-system-
cache-information>
<clear-service- clear services border-signaling-gateway <bsg-drain-nr-details>

border-signaling- name-resolution-cache
gateway-
name-resolution-cache>
clear_service_
border_signaling_gateway_
name_ resolution_cache
<clear-service- clear services border-signaling-gateway <bsg-drain-nr-details>

border-signaling- name-resolution-cache all
gateway-name-
resolution-cache-all>
clear_service_border_
signaling_gateway_name_
resolution_cache_all
<clear-service- clear services border-signaling-gateway <bsg-statistics-clear-denied-messages>

bsg-denied-messages> denied-messages
clear_service_bsg_denied_messages
<get-fm-fpc-errors> show chassis fabric errors fpc <fm-fru-errors>

get_fm_fpc_errors
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.0 (continued)
<get-fm-sib-errors> show chassis fabric errors sib <fm-fru-errors>

get_fm_sib_errors
<get-idp-addos-application-information> show security idp application- identification <get-idp-

get_idp_addos_application_information application-system-cache addos-application-information>
<get-idp-application-system-cache> show security idp application-ddos application <idp-application-system-cache-information>

get_idp_application_system_cache
<get-ospf3-backup-coverage-information> show ospf3 backup coverage <ospf3-backup-coverage-information>

get_ospf3_backup_coverage_information
<get-ospf3-backup-lsp-information> show ospf3 backup lsp <ospf3-backup-lsp-information>

get_ospf3_backup_lsp_information
<get-ospf3-backup-neighbor-information> show ospf3 backup neighbor <ospf3-backup-neighbor-information>

get_ospf3_backup_neighbor_information
<get-ospf3-backup-spf-information> show ospf3 backup spf <ospf3-backup-spf-information>

get_ospf3_backup_spf_information
<get-ospf-backup-coverage-information> show ospf backup coverage <ospf-backup-coverage-information>

get_ospf_backup_coverage_information
<get-ospf-backup-lsp-information> show ospf backup lsp <ospf-backup-lsp-information>

get_ospf_backup_lsp_information
<get-ospf-backup-neighbor-information> show ospf backup neighbor <ospf-backup-neighbor-information>

get_ospf_backup_neighbor_information
<get-ospf-backup-spf-information> show ospf backup spf <ospf-backup-spf-information>

get_ospf_backup_spf_information
<get-power-usage-information> show chassis power <power-usage-information>

get_power_usage_information
<get-pppoe- show pppoe service-name-tables <pppoe-service-name-table-information >

service-name-
table-information>
get_pppoe_service_name_table_information
<get-pppoe-underlying-interface-information> show pppoe underlying-interfaces <pppoe-underlying-interface-information>

get_pppoe_underlying_interface_information
<get-service- show services border-signaling-gateway <bsg-statistics-

border-signaling-gateway-calls-duration> calls-duration calls-duration>
get_service_border_signaling_gateway_calls_
duration
<get-service- show services border-signaling-gateway <bsg-name-resolution-cache-

border-signaling-gateway-name- name-resolution-cache information>
resolution-cache>
get_service_border_signaling_gateway_name_
resolution_cache
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.0 (continued)
<get-service- show services border-signaling-gateway <bsg-name-resolution-cache-

border-signaling-gateway- name-resolution-cache all information>
name- resolution-cache-all>
get_service_border_signaling_gateway_name_
resolution_cache_all
<get-service- show services border-signaling-gateway <bsg-statistics-

bsg-denied-messages> calls-duration calls-duration>
get_service_bsg_denied_messages
<get-service-bsg-denied-messages> show services border-signaling-gateway <bsg-statistics

get_service_bsg_denied_messages denied-messages -denied-
messages-details>
<get-service-bsg- show services border-signaling-gateway <bsg-information-details>

information-by-call- by-call-context-id
context-id>
get_service_bsg_information_by_call_context_id
<get-service-bsg-status-information> show services border-signaling-gateway status <bsg-status-information>

get_service_bsg_status_information
<request-dhcp- request dhcp server reconfigure NONE

server-reconfigure-information>
request_dhcp_
server_reconfigure_information
<request-dhcp- request dhcp server reconfigure NONE

server-reconfigure-information>
<request-ping-ldp-p2mp-lsp> ping mpls ldp p2mp NONE

request_ping_ldp_p2mp_lsp
[XML API Operational Reference]
Layer 2 Ethernet Services
■ IEEE 802.1ah PBB (MX Series routers)—Provider backbone bridges (PBB), also
known as MAC-in-MAC, provide support to carrier Ethernet networks. PBB defines
a hierarchical network architecture and new frame formats that extend the
functionality of provider bridges (IEEE802.1ad) for service providers that want
to offer Layer 2 Ethernet services to their customers. With PBB, customer bridged
(IEEE 802.1q) networks are aggregated into provider backbone bridge networks
(IEEE 802.1ah networks).
A PBBN is composed of a set of backbone edge bridges (BEBs) interconnected
by some or all of the S-VLANs supported by a provider bridged network (PBN).
Each BEB provides interfaces that encapsulate (or verify the encapsulation of)
customer frames, thus allowing customer MAC (C-MAC) addresses and VLANs
to be independent of the backbone MAC (B-MAC) addresses and VLANs
administered by the PBBN operator. The backbone is segregated into broadcast
domains by means of a VLAN identifier (B-VID). A new 24-bit service identifier

(I-SID) is defined and used to associate a given customer MAC frame with a
provider service instance (also called the service delimiter).
To configure PBB, configure an I-component routing instance and a B-component
routing instance. The B-component is the provider routing instance. Each
B-component contains the BVLAN bridge domains of a PBBN network that map
a backbone service instance tag (I-tag) to a BVLAN. The I-component is the
customer routing instance. The I-component contains the SVLAN bridge domains
of a PBN network that maps to a backbone service instance tag (I-tag). Each
SVLAN is uniquely mapped to a single ISID (1:1 mapping), or multiple SVLANs
can be mapped to an ISID (N:1 mapping).
Each I-component and B-component routing instance must be associated with
a CPB interface or a PIP interface. These interfaces provide a connection between
the customer routing instances (PBN or PBBN I-component) and provider routing
instance (PBBN B-component).
PBB for JUNOS supports both E-LINE and E-LAN service, enhanced carrier-level
CoS, and IEEE 802.1ag Connectivity Fault Management (CFM).
To configure PBB, include the routing-instance instance-name statement at the
[edit] hierarchy level. You must create a routing instance for both the I-component
and B-component at the [edit routing-instances] hierarchy level.
[VPNs]
■ BFD support for VCCV—Bidirectional Forwarding Detection (BFD) support for
virtual circuit connection verification (VCCV) allows you to configure a control
channel for a pseudowire, in addition to the corresponding operations and
management functions to be used over that control channel. BFD provides a low
resource mechanism for the continuous monitoring of the pseudowire data path
and for detecting dataplane failures. This feature adds support for asynchronous
mode BFD support for VCCV, as descibed in
draft-ietf-pseudowiree3-vccv-bfd-02.txt, Bidirectional Forwarding Detection (BFD)
for the Pseudowire Virtual Circuit Connectivity Verification (VCCV). Previously, a
ping was used to detect pseudowire failures. However, the processing resources
required for a ping are greater than what is needed for BFD. In addition, BFD is
capable of detecting data plane failure faster than a VCCV ping. BFD for
pseudowires is supported for Layer 2 circuits (LDP-based), Layer 2 VPNs
(BGP-based), and VPLS (LDP-based or BGP-based).
To configure OAM for Layer 2 VPNs, include the oam statement and
substatements at the [edit routing-instances routing-instance-name protocols l2vpn]
hierarchy level:
oam {
bfd-liveness-detection {
detection-time {
threshold milliseconds;
}
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
multiplier number;
no-adaptation;
transmit-interval {
minimum-interval milliseconds;
threshold milliseconds;
}
version bfd-protocol-version;
}
control-channel {
pwe3-control-word;
pseudowire-label-ttl-1;
router-alert-label;
}
}
You can configure many of the same OAM statements for VPLS and Layer 2
circuits. To enable OAM for VPLS, configure the oam statement and substatements
at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level
and at the [edit routing-instances routing-instance-name protocols vpls neighbor
address] hierarchy level. The pwe3-control-word statement configured at the [edit
routing-instances routing-instance-name protocols l2vpn oam control-channel]
hierarchy level is not applicable to VPLS configurations.
To enable OAM for Layer 2 circuits, configure the oam statement and
substatements at the [edit protocols l2circuit neighbor address interface
interface-name] hierarchy level. The control-channel statement and substatements
configured at the [edit routing-instances routing-instance-name protocols l2vpn
oam] hierarchy level do not apply to Layer 2 circuit configurations.
The show ldp database extensive command has been modified to provide
information about the VCCV control channel. The show bfd session extensive
command has been modified to display information about BFD for Layer 2 VPNs,
Layer 2 circuits, and VPLS.
[VPNs]
■ VPLS root protection topology change actions—You can control the actions
taken by the MX Series router when the topology changes in a multihomed Layer
2 ring VPLS environment using root protection. Specifically, MAC flush messages
are sent from the blocked PE to LDP peers based on the system identifier to IP
address mapping. To configure VPLS root protection topology change actions,
include the backup-bridge-priority, system-id, and vpls-flush-on-topology-change
statements at the [edit protocols (mstp | rstp | vstp)] hierarchy level (to control
global STP behavior) or the [edit protocols vstp vlan-id] hierarchy level (to control
a particular VLAN).
[MX Layer 2 Configuration]
MPLS Applications
■ RSVP node-ID hello support—The JUNOS Software now supports node-ID based
RSVP hellos to help interoperate with other vendor’s equipment. This feature
complements the current support for interface-based RSVP hellos. Node-ID based
RSVP hellos are specified in RFC 4558, Node-ID Based Resource Reservation
Protocol (RSVP) Hello: A Clarification Statement. RSVP node-ID hellos are useful
if you have configured BFD to detect problems over RSVP interfaces, allowing
you to disable interface hellos for these interfaces. You can also use node-ID
hellos for graceful restart procedures.
Node-ID hellos can be enabled globally for all RSVP neighbors. By default, node-ID
hello support is disabled (interface hellos are enabled by default). If you have
not enabled RSVP node IDs on the router, the JUNOS Software does not accept
any node-ID hello packets. To enable RSVP node-ID hellos on the router, include
the node-hello statement at the [edit protocols rsvp] hierarchy level. You can also
disable RSVP interface hellos globally by including the no-interface-hello statement
at the [edit protocols rsvp] hierarchy level. If you configure the no-interface-hello
statement, you can then configure a hello interval on an RSVP interface. This
configuration disables RSVP interface hellos globally, but enables RSVP interface
hellos on the specified interface (you might want to do this for backwards
compatibility).
[MPLS]
Multicast
■ Hub-and-spoke support for multiprotocol BGP-based multicast VPNs with

PIM-SSM GRE S-PMSI transport—Multiprotocol BGP-based (MBGP) multicast
VPNs (also referred to as next-generation Layer 3 VPN multicast) can be
configured using protocol-independent multicast source-specific multicast
(PIM-SSM) selective provider multicast service interface (S-PMSI) tunnels in a
hub-and-spoke topology.
This feature is useful in the following scenarios:
■ Customer sources and rendezvous points (RPs) are located only in the hub
sites and customer receivers are located in spoke sites or other hub sites.
■ Customer sources are located only in spoke sites and customer receivers are
located only in hub sites.
To configure MBGP MVPNs to use PIM-SSM S-PMSI tunnels in a hub-and-spoke

topology, do the following:
■ Include the group-range statement and specify the group address range at
the [edit routing-instances routing-instance-name provider-tunnel selective group
group-address source source-address pim-ssm] hierarchy level on all PE routers
participating in the MVPN.
■ Include the threshold-rate statement and specify zero as the threshold value
at the [edit routing-instances routing-instance-name provider-tunnel selective
group group-address source source-address] hierarchy level on all PE routers
participating in the MVPN.
■ Include the family inet-mvpn statement and family inet6-mvpn statement at

the [edit routing-instances routing-instance-name vrf-advertise-selective]
hierarchy level to selectively advertise routes on PE routers that use one VRF
for unicast routing and a separate VRF for MVPN routing.
[VPNs, Routing Protocols, 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: 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 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]
■ Independently configurable loopback addresses for VRF VPNs—The local
loopback address configured in a virtual routing function (VRF) routing instance
is used as the source address when sending PIM hello messages, join messages,
and prune messages over multicast tunnel interfaces.
For compatibility with certain other vendor’s routers, the address used in the
VRF routing instance for multicast tunnel interfaces must be the same as the
primary loopback address configured in the default routing instance.
The primary loopback address in the default routing instance is typically
configured on the lo0.0 interface.
To configure the router to use the primary loopback address configured in the
default routing instance as the multicast tunnel interface address in all VRF
routing instances, include the use-master-lo0-for-mdt statement at the [edit
protocols pim] hierarchy level.
Prior to committing this change, you should ensure that this change to the
multicast tunnel interface address does not create duplicate IP addresses in any
of the customer networks attached to the VRF routing instance.
After the use-master-lo0-for-mdt statement is included, you can delete the loopback
address configured in the VRF routing instances.
[Multicast, VPNs, Routing Protocols Command Reference]
Network Management
■ Enterprise-specific BGP trap support for BGP clients with IPv6

addresses—JUNOS Release 10.0 introduces two enterprise-specific traps,
jnxBgpM2Established and jnxBgpM2BackwardTransition, to support BGP clients
that follow IPv6 addressing. The previous versions of JUNOS Software supported
only the standard BGP traps, BgpM2Established and BgpM2BackwardTransition.
The standard BGP traps supported only IPv4 addresses, and returned 0.0.0.0 as
the IP address of the BGP remote peer if the remote peer was configured with
an IPv6 address. The newly introduced enterprise-specific traps support IPv6
addressing and contain the proper IPv6 address of the remote peer if the remote
peer is configured with an IPv6 address. However, to ensure backward
compatibility, JUNOS Release 10.0 also supports the standard traps. The standard
traps are generated when the BGP clients are configured with IPv4 addresses.
[Network Management]
Routing Protocols
■ New show route rd-prefix command for Layer 3 VPNs—Speeds troubleshooting

of route errors by enabling you to view the exact route specified by a
route-distinguisher:prefix notification. Instead of searching for routes with errors
in the output of the show route protocols bgp extensive command, for example,
you can now filter route output by the route-distinguisher and prefix to more
quickly find the route with errors; for example, show route rd-prefix
1.1.1.111:2:111.111.111.111 detail.
The show route rd-prefix command also enables you to view multiple routes that
best match a mask or range of route-distinguisher:prefix notifications; for
example, show route rd-prefix 1.1.1.11:2:1/8.
[Routing Protocols and Policies Command Reference]
■ Support for alternate loop-free routes for OSPF—Adds fast reroute capability
for OSPF. The JUNOS Software precomputes loop-free backup routes for all OSPF
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 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 OSPF interface. Because it is common practice to enable LDP on
an interface for which OSPF is already enabled, this feature also provides support
for LDP label-switched paths (LSPs). The level of backup coverage available
through OSPF 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 OSPF
using alternate loop-free routes: link protection and node-link protection. When
you enable link protection or node-link protection on an OSPF 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 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 (ospf | ospf3)
area area-id 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 (ospf | ospf3) area area-id
interface interface-name] hierarchy level. Both link protection and node-link
protection are also supported for OSPFv3 unicast realms and OSPF unicast
topologies. Multicast realms and topologies are not supported. Link protection
and node-link protection are also supported for all OSPFv2 and OSPFv3 routing
instances and for logical systems.
By default, all the interfaces in an OSPF 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 (ospf |ospf3) area area-id interface interface-name] hierarchy level.
When you enable link protection or node-link protection on an OSPF interface,
the JUNOS Software automatically calculates backup next-hop routes for all the
topologies in an OSPF instance. To disable the calculation of next-hop backup
routes for a specific OSPF instance or topology, include the disable statement at
the [edit protocols (ospf | ospf3) backup-spf-options] or [edit protocols ospf topology
topology-name backup-spf-options] hierarchy level. To prevent the installation of
backup next-hop routes in the routing table or forwarding table for a specific
OSPF instance or topology, include the no-install statement at the [edit protocols
(ospf | ospf3) backup-spf-options] or [edit protocols ospf topology topology-name
backup-spf-options] hierarchy level. You can also limit the number of backup
next-hop routes that are installed to a subset of routes as described in RFC 5286,
Basic Specification for IP Fast Reroute: Loop-Free Alternates. Include the
downstream-paths-only statement at the [edit protocols (ospf | ospf3)
backup-spf-options] or [edit protocols (ospf | ospf3) backup-spf-options] hierarchy
level.
You can enhance backup coverage for OSPF 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] hierarchy level. 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
(ospf | ospf3) backup lsp 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 (ospf | ospf3) backup spf command. Use the show
(ospf | ospf3) backup coverage command to display how many nodes and prefixes
for each address family are protected. In addition, the show (ospf | ospf3) interface
detail command has been enhanced to display the type of protection, Link or
Node Link, that has been applied to each interface.
[Routing Protocols, Routing Protocols and Policies Command Reference]
■ Support for BGP flow specification version 7—Enables you to configure the
router to comply with the term-ordering algorithm first defined in version 7 of
the BGP flow specification and supported through the latest version, Internet
draft draft-ietf-idr-flow-spec-09.txt, Dissemination of Flow Specification Routes.

By default, the JUNOS Software uses the term-ordering algorithm defined in
version 6 of the BGP flow specification draft. Include the standard statement at
the [edit routing-options flow term-order] hierarchy level to specify to use the
term-ordering algorithm first defined in version 7. To revert to using the
term-ordering algorithm defined in version 6 if you change the default behavior,
include the legacy statement at the [edit routing-options flow term-order] hierarchy
level. These statements are also supported with routing instances. We recommend
that you configure the JUNOS Software to use the term-ordering algorithm first
defined in version 7 of the BGP flow specification draft. We also recommend
that you configure the JUNOS Software to use the same term-ordering algorithm
on all routing instances configured on a router.
Use the new command show route protocol flow to display locally configured flow
specification routes for all routing instances. The show route table inetflow.0
command has been enhanced to display the field term:identifier after each prefix,
which indicates the order in which a term is evaluated. An identifier of 1 is
assigned to the first term evaluated in an active flow route. If the flow route
encounters an error during installation, the term field displays an identifier of
N/A.
[Routing Protocols, Routing Protocols and Policies Command Reference]
Services Applications
■ E-LINE and E-LAN services in PBB (MX Series routers)—To support IEEE
802.1ah provider backbone bridges (PBB), you can configure E-LINE
(point-to-point) or E-LAN (point-to-multipoint) services.
To configure E-LINE or E-LAN services, include the eline or elan statement at the
[edit routing-instances instance service-groups] hierarchy level.
[Network Interfaces, VPNs, MX Solutions]
■ Integrated Multi-Service Gateway (IMSG) BSG overload protection—Provides
the border signaling gateway (BSG) with an overload protection mechanism that
ensures a graceful rejection of any excessive dialogs or transactions. The
mechanism includes a fairness algorithm that prioritizes the transactions of
established calls and prevents monopolization of resources by a few network
entities.
You can use the following command to display information about dropped
messages: show services border-signaling-gateway denied-messages gateway
gateway-name. This command lists information logged since the last time the
tracking log was reset.
You can use the following command to reset the tracking log: clear services
border-signaling-gateway denied-messages gateway gateway-name.
■ Integrated Multi-Service Gateway (IMSG) management features (MX Series
routers)—Enable voice users to troubleshoot and monitor faults and performance
in the voice network. The new features include display of abbreviated or detailed
information on all active calls, a histogram showing call duration, and new system
log alerts.
You can display abbreviated or detailed information about all active calls by
entering one of the following commands:
■ show services border-signaling-gateway by-contact gateway gateway-name (brief
| detailed)
Omitting the variable contact causes information about all calls to be listed.
■ show services border-signaling-gateway by-request–uri gateway gateway-name
(brief | detailed)
Omitting the variable request-uri causes information about all calls to be
listed.
You can display a histogram showing call duration by entering the following
command: show services border-signaling-gateway calls-duration gateway
gateway-name.
The following new error alerts are available in the system log:
■ Concurrent calls alert—This alert, which is part of the call admission control
(CAC) feature, appears when the number of concurrent calls crosses a
threshold that can be configured in the CLI.
■ Header and values length alert—This alert appears when a call is dropped
because a header or value exceeds a maximum length (128 or 256,
depending on information in the header).

■ RPM timestamping extension (MX Series routers)—Adds support for
timestamping of RPM probes in the Packet Forwarding Engine host processer.
On MX Series routers only, you can enable this feature by including the
hardware-timestamp statement at the [edit services rpm probe probe-name test
test-name] hierarchy level.
[Services Interfaces]
■ Integrated Multi-Service Gateway (IMSG) provides DNS support (M Series and
MX Series routers)—The border signaling gateway (BSG) now fully supports DNS
to resolve SIP Uniform Resource Identifiers (URIs) into the IP address, port, and
transport protocol of the next hop. This feature complies with RFC 3263, Session
Initiation Protocol (SIP): Locating SIP Servers.
You can specify how the BSG handles the caching of DNS entries. To configure,
include the name-resolution-cache statement at the [edit services
border-signaling-gateway gateway gateway-name] hierarchy level.
To view data that is cached in the BSG, use the show services
border-signaling-gateway name-resolution-cache command.
To remove all cached entries, use the clear services border-signaling-gateway
command.
[Multiplay Solutions, Services Interfaces, System Basics and Services Command
Reference]
■ Interim AACL bulk statistics for dynamic application awareness
subscribers—Provide support for interim application-aware access list (AACL)
statistics. You can now select whether to display delta or interim statistics records
and specify a reporting interval. To specify the statistics properties, include the
statistics statement at the [edit services local-policy-decision-function] hierarchy
level.
■ New option for restricting a NETCONF TCP port—Enables you to restrict
incoming NETCONF connections to a specified TCP port without configuring a
firewall. A new configuration option, port, has been added to the [edit system
services netconf ssh] hierarchy level. To configure the TCP port used for
NETCONF-over-SSH connections, set the port statement to the desired TCP port
number at the [edit system services netconf ssh] hierarchy level. The configured
port accepts only NETCONF-over-SSH sessions; regular SSH session requests for
this port are rejected. The default SSH port (22) continues to accept NETCONF
sessions even with a configured NETCONF server port. You can use the
UI_LOGIN_EVENT information, which now includes SSH connection information
for the addresses and ports of the source and destination hosts, to create event
policies that monitor the incoming NETCONF server connections and further
restrict their conditions.
[NETCONF API Guide]
■ Border gateway function (BGF) supports IPsec for H.248 messages and for
session mirroring (M120, M320, T640 routers, and MX Series routers)—You
can use existing JUNOS IPsec functionality to protect H.248 messages sent
between the BGF and the external gateway controller and to protect session
mirroring information sent to a delivery function. Both transport and tunnel
modes are supported for H.248 messages. Tunnel mode is supported for mirrored
sessions.
To configure IPsec to protect H.248 messages in transport mode, create a manual,
bidirectional security association at the [edit security ipsec] hierarchy level. You
then apply the security association to the BGF by including the
ipsec-transport-security-association statement at the [edit services pgcp gateway
gateway-name] hierarchy level.
To configure IPsec to protect H.248 messages or mirrored sessions in tunnel
mode, configure an IPsec VPN service at the [edit services ipsec-vpn] hierarchy
level, and then configure the service PIC that the IPsec VPN will use. The IPsec
VPN can use the same service PIC as the BGF, or it can use a dedicated service
PIC.
[Multiplay Solutions, Services Interfaces]
■ New keyword completions for the show security idp counters command—The
show security idp counters operational mode command supports the following
new keyword completions: dfa, flow, ips, log, packet, policy-manager, and
tcp-reassembler.
[System Basics and Services Commmand Reference]
■ New command to clear ip-action flows—The new clear services flows ip-action
command enables you to clear ip-action entries configured at the [edit security
idp] hierarchy level for use with dynamic application awareness for JUNOS
Software features.

■ New options for configuring global session timeout settings (Multiservices
PICs and DPCs)—You can now configure session timeout settings on a global
basis at the [edit interfaces interface-name services-options] hierarchy level for
use with dynamic application awareness for JUNOS Software sessions. You can
include the following settings:
■ inactivity-non-tcp-timeout—Set an inactivity timeout period for non-TCP
established sessions.
■ inactivity-tcp-timeout—Set an inactivity timeout period for TCP established
sessions.
■ session-timeout—Set a session timeout period for established sessions.
■ disable-global-timeout-override—Disallow overriding global inactivity or session

timeout.
Subscriber Access Management
■ Support for PPPoE service name tables (M120 routers and M320
routers)—Enables you to configure up to 16 PPPoE service name tables on an
M120 router or M320 router and assign the service name tables to underlying
PPPoE interfaces. A PPPoE service name table defines the set of services, also
referred to as service name tags, that the router, acting as a remote access
concentrator (AC), can provide to a PPPoE client. The PPPoE client first broadcasts
a PPPoE Active Discovery Initiation (PADI) control packet to all remote ACs in
the network to request that an AC support certain services. Upon receipt of the
PADI packet, one or more routers (ACs) respond by sending a PPPoE Active
Discovery Offer (PADO) packet to the client to indicate that they can service the
client request.
The creation of PPPoE service name tables enables the router to support multiple
services requested by PPPoE clients, and to specify an action to take (delay,
drop, or terminate) upon receipt of a PADI packet requesting that service.
Configuring PPPoE service name tables in a subscriber network also enables you
to provide load balancing and redundancy across a set of remote ACs by
specifying the appropriate AC to receive and service a particular PADI request.
Each PPPoE service name table can include a maximum of 16 service name
tags. The default action associated with a service name tag is terminate, which
directs the router to immediately respond to the client with a PADO packet.
Alternatively, you can associate either the delay nondefault action or drop (ignore)
nondefault action with a service name tag. You can optionally specify up to 16
agent circuit identifier (ACI)/agent remote identifier (ARI) pairs for each service
name tag. An ACI/ARI pair contains an agent circuit ID string that identifies the
DSLAM interface that initiated the service request, and an agent remote ID string
that identifies the subscriber on the DSLAM interface that initiated the service
request. The ACI/ARI pair specification supports the use of wildcard characters.
In addition to one or more service name tags, a PPPoE service name table
includes one empty service name tag, which is a service name tag of zero length
that represents any service. The empty service name tag is associated with the
terminate (default), delay, or drop action, and cannot be associated with any
ACI/ARI pairs.
To configure a service name table, perform the following tasks:

■ To create the service name table, include the service-name-tables statement
at the [edit protocols pppoe] hierarchy level.
■ To configure a service name tag and associated action, include the service
statement at the [edit protocols pppoe service-name-tables table-name]
hierarchy level.
■ To configure optional ACI/ARI pairs for a service name tag, include the
agent-specifier statement at the [edit protocols pppoe service-name-tables
table-name service service-name] hierarchy level.
■ To configure an empty service name tag and associated action, include the
empty-service statement at the [edit protocols pppoe service-name-tables
table-name] hierarchy level.
■ To assign a PPPoE service name table to an underlying PPPoE interface that

is configured with PPPoE encapsulation, include the pppoe-underlying-options
statement at the [edit interfaces interface-name unit logical-unit-number]
hierarchy level.
■ To define tracing options for PPPoE processes, include the traceoptions

statement at the [edit protocols pppoe] hierarchy level.
To verify the PPPoE service name table configuration, use the following
operational commands:
■ To display the configuration of a PPPoE service name table, issue the show
pppoe service-name-table command.
■ To display the name of the PPPoE service name table assigned to a PPPoE
underlying interface, issue the show pppoe underlying-interfaces command.
■ To display the status of the PPPoE underlying interface, issue the show
interfaces command.
[Network Interfaces, Interfaces Command Reference, Subscriber Access]

■ IPv6 address assignment pools (MX Series routers)—Enable you to create local
address assignment pools that support IPv6 prefix delegation.
Local IPv6 pools enable client applications, such as DHCP, to request delegated
IPv6 prefixes for authenticated and unauthenticated subscribers, based on
client-specific attributes.
You configure IPv6 address assignment pools at the [edit access
address-assignment pool name family inet6] hierarchy level. You can populate the
pool with specific IPv6 prefixes or with named ranges of IPv6 prefixes. When
creating the address assignment pools, you can also configure DHCP attributes
that specify optional information for subscribers.
Once the address assignment pool is configured, you specify how the DHCPv6
local server uses the pool. For information on configuring the extended DHCPv6
local server to use address assignment pools, see "Configuring How the Extended
DHCP Local Server Determines Which Address-Assignment Pool To Use" in the
Subscriber Access Configuration Guide.
Use the show network-access address-assignment pool operational command to
view information for address assignment pools. Use the traceoptions statement
at the [edit system processes general-authentication-service] hierarchy level to
track address assignment pool operations and to log events.
[Subscriber Access]
■ Support for dynamic VLAN interface authentication—Enables you to
dynamically create an underlying VLAN interface for incoming subscribers,
associate interfaces created on this VLAN with the default logical system and a
specified routing instance, and define RADIUS authentication values for the
dynamically created interfaces.
As of JUNOS Release 9.6, you can use dynamic profiles, in conjunction with
RADIUS, to dynamically create logical VLAN interfaces in the default logical
system (LS) and in a specified routing instance (RI). As DHCP clients in the same
VLAN become active, corresponding interfaces are assigned to any specified
routing instances. In this release, you can use the dhcp-v4 value for the accept
statement at the [interfaces interface-name auto-configure vlan-ranges dynamic-profile
dynamic-profile-name] hierarchy level to specify that incoming IPv4 DHCP discover
packets trigger the authentication of a VLAN as it is dynamically created.
Subsequent DHCP client traffic in the same VLAN is handled by DHCP and new
interfaces are assigned to the routing instance associated with that VLAN. This
functionality enables you to assign subscribers to specific routing instances based
on their VLAN ID.
To define authentication values for dynamically created VLAN interfaces, include
the authentication statement at the [edit interfaces interface-name auto-configure
vlan-ranges] or [edit interfaces interface-name auto-configure stacked-vlan-ranges]
hierarchy levels. The authentication statement supports both a password and
username-include statement. The username-include statement supports delimiter,
domain-name, user-prefix, mac-address, option-82, and circuit-type statements. For
information about these statements, see the Junos OS Subscriber Access
Configuration Guide. The username-include statement also includes a new
radius-realm statement. When included, the RADIUS realm is appended as a last
piece to the username and used by RADIUS to direct the authentication request
to a profile that does not allocate addresses.
NOTE: Once a VLAN interface is created, it remains active unless you use the existing
clear auto-configuration interfaces interface-name CLI command to delete it.
■ Enhanced AAA troubleshooting (MX Series routers)—New CLI operational

commands have been added and existing commands have been modified to
provide enhanced troubleshooting and debugging information for AAA operations.
The commands are described in the following list:
■ show network-access aaa subscriber session-id—New command that displays

information for a specific subscriber session, including username, IP address,
client type, number of attached services, and the current authentication,
accounting, and service states. You can display brief or detailed output for
the session.
■ show network-access aaa statistics address-assignment client—New command
that displays AAA statistics for a specific client (such as DHCP). New counters
include the Out of memory counter that indicates an address cannot be handed
out to the client due to memory issues, and the No matches counter that
indicates that there were no network matches for the pools you configured.
■ show network-access aaa statistics address-assignment pool—New command

that displays AAA information for a specific address assignment pool. New
counters include the Out of memory counter that indicates addresses cannot
be handed out due to memory issues, and the Out of addresses counter that
indicates that there are no available addresses in the pool.
■ show network-access aaa subscriber statistics username—Modified command;

nonessential counters have been removed.
■ clear network-access aaa statistics—New command that enables you to clear

AAA information. You can clear statistics related to accounting, address
assignment, authentication, dynamic requests, and reauthentication.
[Subscriber Access]
■ Round-robin method for accessing RADIUS servers (MX Series
routers)—Enables you to configure the router to use the round-robin method
when exchanging authentication and accounting messages with RADIUS servers.
The round-robin access method provides load balancing by rotating router
requests among the list of configured RADIUS servers. For example, if three
RADIUS servers are configured to support the router, the router sends the first
request to server1, and uses server2 and server3 as backup servers. The router
then sends the second request to server2, and uses server3 and server1 as
backups. By default, the router uses the direct access method, in which there is
no load balancing. For example, in the direct method, the router always accesses
server1 (the primary server) first, and uses server2 and server3 as backup servers.
To configure the method the router uses to access RADIUS accounting and
authentication servers, use the following two statements at the [edit access profile
profile-name radius options] hierarchy level.
■ client-accounting-algorithm (direct | round-robin)—Configures the access method
for accounting servers.
■ client-authentication-algorithm (direct | round-robin)—Configures the access
method for authentication servers.
[Subscriber Access]
■ Dynamic reconfiguration of extended DHCP local server clients (MX Series
routers)—Dynamic reconfiguration of clients enables the extended DHCP local
server to initiate a client update without waiting for the client to initiate a request.
The DHCP local server sends a forcerenew message to the client. Clients that
support the forcerenew message then send a lease renewal message to the server.
The server refuses to renew the lease and instead sends a NAK to the client,
causing the client to re-initiate the DHCP connection. A successful reconnection

results in the reconfiguration of the DHCP client. DHCP relay and DHCP relay
proxy do not participate in the client reconfiguration or react to forcerenew
messages other than to forward them to the client.
Without dynamic reconfiguration, the DHCP client initiates all of the basic DHCP
interactions that take place between client and server. The DHCP local server
can send information to a client only in response to a request from that client.
In subscriber management scenarios, this behavior does not enable a client to
be quickly updated with its network address and configuration in the event of
server changes, such as a restructuring of the service provider’s addressing
scheme or a change in the DHCP local server IP addresses that were provided
to the DHCP clients. The clients operate as though nothing has changed, but they
are unable to communicate over the access network because the server changes
typically result in clearing the DHCP server binding table. An outage then exists
while the DHCP local server has to wait for the client to send a message to renew
its lease or rebind to the server. Dynamic reconfiguration avoids the outage and
the wait.
You can enable dynamic reconfiguration for all DHCP clients or only the DHCP
clients serviced by a specified group of interfaces, and you can modify the
reconfiguration behavior accordingly. To enable dynamic reconfiguration with
default reconfiguration values for all DHCP clients, include only the reconfigure
statement at the [edit system services dhcp-local-server] hierarchy level.
Alternatively, to enable dynamic reconfiguration for only the DHCP clients
serviced by a specified group of interfaces, include only the reconfigure statement
at the [edit system services dhcp-local-server group group-name] hierarchy level.
You can optionally modify the behavior of the reconfiguration process by
including the appropriate statements at the [edit system services dhcp-local-server
reconfigure] hierarchy level for all DHCP clients. To override this global
configuration for only the DHCP clients serviced by a specified group of interfaces,
you can include the statements with different values at the [edit system services
dhcp-local-server group group-name reconfigure] hierarchy level.
Include the attempts statement to specify how many times the local server sends
the forcerenew message to initiate client reconfiguration. Include the timeout
statement to set the initial interval between the first and second attempts.
By default, the DHCP client’s original configuration is restored if all of the
reconfiguration attempts fail. Include the clear-on-abort statement to delete the
client instead.
You configure an authentication token by including the token statement. The
DHCP local server will then include this token inside the authentication option
when it sends forcerenew messages. If the service provider has previously
configured the DHCP client with this token, then the client can compare that
token against the newly received token, and reject the message if the tokens do
not match.
In the event of a RADIUS-initiated disconnect, the client is deleted by default.
You can configure the client to be reconfigured instead of deleted by including
the radius-disconnect statement at the [edit system services dhcp-local-server
reconfigure trigger] hierarchy level for all clients or the [edit system services
dhcp-local-server group group-name reconfigure trigger] hierarchy level for only the
DHCP clients serviced by a specified group of interfaces.
[Subscriber Access]
■ Support for CoS on static PPPoE subscriber interfaces (M120 and M320
routers)—Enables you to configure CoS functionality for static PPPoE subscriber
interfaces configured on Gigabit Ethernet Intelligent Queuing 2 (IQ2) and Ethernet
Enhanced IQ2 (IQ2E) PICs on the M120 and M320 routers.
For both IQ2 and IQ2E PICs, you can now attach an output traffic control profile
that contains basic shaping and scheduling properties directly to a PPPoE interface
at the [edit class-of-service interfaces] hierarchy level. In this type of scenario,
you could use each PPPoE interface to represent a household and shape all of
the household traffic to an aggregate rate. Each forwarding class is mapped to
a queue, and represents one type of service provided to a household customer.
The IQ2E PIC supports hierarchical scheduling functionality that is not available
on the IQ2 PIC. To shape customer or DSLAM traffic at different levels of the
PPPoE interface hierarchy, you can attach traffic control profiles to interface sets
that contain PPPoE members.
[Subscriber Access, Class of Service]
■ Support for framed routes and addresses for PPP dynamic subscriber interfaces
(M120, M320, and MX Series routers)—Enables you to configure framed routes
and addresses for PPP subscriber interfaces in a dynamic profile. In previous
releases, framed routes were supported for DHCP subscriber interfaces only.
Note that this feature does not apply to PPPoE interfaces on MX Series routers.
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.
The Framed-Route attribute [22] has been extended to support PPP subscribers.
The values for the framed route and addresses are dynamically supplied to
subscriber interfaces using this attribute.
To dynamically configure framed routes using values specified in the
Framed-Route attribute [22] for a PPP subscriber interface, include the
$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 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 for a PPP subscriber interface, include the $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 a variable for the qualified next hop ($junos-interface-name).
You do not need to configure the 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]
■ Support for hierarchical CoS on IP demux interfaces over aggregated Ethernet
(MX Series routers)—Enables you to configure hierarchical CoS for a static or
dynamic IP demultiplexing (demux) subscriber interface with an aggregated
Ethernet interface as its underlying logical interface. In earlier releases,
hierarchical CoS on aggregated Ethernet was only supported for static and
dynamic VLAN subscriber interfaces.
This feature is supported on EQ DPCs on MX Series routers.
To use this feature, you must first configure the aggregated Ethernet interface
at the [edit interfaces] hierarchy level. You then configure the static subscriber
interface at the [edit interfaces interface-name demux0] hierarchy level, or the
dynamic subscriber interface at the [edit dynamic-profiles profile-name interfaces
demux0] hierarchy level. Note that hierarchical CoS is not supported on interface
sets of demux interfaces.
To enable hierarchical CoS for the aggregated Ethernet interface, include the
hierarchical-scheduler statement at the [edit class-of-service interfaces
interface-name] hierarchy level. You must also enable link-protection mode for
the interface by including the link-protection statement.
You then attach the output traffic control profile to the static demux interface at
the [edit class-of-service interfaces interface-name] hierarchy level, or to the
dynamic demux interface at the [edit dynamic profiles profile-name class-of-service
interfaces interface-name] hierarchy level.
[Subscriber Access]
System Logging
■ New and deprecated system log tags—The following sets of system log messages
are new in this release:
■ AUTOCONFD—Messages generated by the auto-configuration (autoconfd)
process.
■ ICCPD—Messages generated by the interchassis communication (iccpd)
process.
The following system log messages are new in this release:

■ CHASSISD_FM_ERROR_CLOS_F13_HSR
■ CHASSISD_FM_ERROR_CLOS_F13_HST
■ CHASSISD_FM_ERROR_CLOS_F2_HSR
■ CHASSISD_FM_ERROR_CLOS_F2_HST
■ CHASSISD_FM_ERROR_F13_FB_HSR_TXP
■ CHASSISD_FM_ERROR_F13_FB_RX_VC
■ CHASSISD_FM_ERROR_F13_FB_TXP
■ CHASSISD_FM_ERROR_F13_FB_TX_VC
■ CHASSISD_FM_ERROR_F13_VC_PWR
■ CHASSISD_FM_ERROR_SIB_L_FB_RX_VC
■ CHASSISD_FM_ERROR_SIB_L_FB_SMF
■ CHASSISD_FM_ERROR_SIB_L_FB_TXP
■ CHASSISD_FM_ERROR_SIB_L_FB_TX_VC
■ CHASSISD_FM_ERROR_SIB_L_HSR_PFE
■ CHASSISD_FM_ERROR_SIB_L_VC_PWR
■ CHASSISD_MAC_ADDRESS_CBP_ERROR
■ CHASSISD_MAC_ADDRESS_IRB_ERROR
■ CHASSISD_MAC_ADDRESS_PIP_ERROR
■ CHASSISD_MIC_OFFLINE_NOTICE
■ COSD_IFD_SHAPER_ERR
■ DYNAMIC_VPN_AUTH_CONNECT_FAIL
■ DYNAMIC_VPN_AUTH_FAIL
■ DYNAMIC_VPN_AUTH_INVALID
■ DYNAMIC_VPN_AUTH_NO_CONFIG
■ DYNAMIC_VPN_AUTH_NO_LICENSE
■ DYNAMIC_VPN_AUTH_OK
■ DYNAMIC_VPN_CLIENT_CONFIG_WRITE
■ DYNAMIC_VPN_CONN_DEL_NOTIFY
■ DYNAMIC_VPN_CONN_DEL_REQUEST
■ DYNAMIC_VPN_CONN_EST_NOTIFY
■ DYNAMIC_VPN_INIT_SUCCESSFUL
■ ESWD_DAI_FAILED
■ ESWD_DHCP_UNTRUSTED
■ ESWD_STP_BASE_MAC_ERROR
■ ESWD_STP_LOOP_PROTECT_CLEARED
■ ESWD_STP_LOOP_PROTECT_IN_EFFECT
■ ESWD_STP_ROOT_PROTECT_CLEARED
■ ESWD_STP_ROOT_PROTECT_IN_EFFECT
■ ESWD_ST_CTL_BW_INFO
■ ESWD_ST_CTL_ERROR_DISABLED
■ ESWD_ST_CTL_ERROR_ENABLED
■ ESWD_ST_CTL_INFO
■ IDP_APPDDOS_APP_ATTACK_EVENT
■ IDP_APPDDOS_APP_STATE_EVENT
■ L2ALD_PBBN_IFL_REVA
■ L2ALD_PBBN_REINSTATE_IFBDS
■ L2ALD_PBBN_RETRACT_IFBDS
■ L2ALD_PIP_IFD_READ_RETRY
■ RPD_LAYER2_VC_BFD_DOWN
■ RPD_LAYER2_VC_BFD_UP
■ RPD_RIP_AUTH_REQUEST
■ RT_GTP_BAD_LICENSE
■ RT_GTP_DEL_TUNNEL_V1
■ RT_GTP_PKT_APN_IE
■ RT_GTP_PKT_DESCRIPTION_CHARGING
■ RT_GTP_PKT_DESCRIPTION_V0
■ RT_GTP_PKT_DESCRIPTION_V1
■ RT_GTP_PKT_ENDUSER_ADDR_IE_IPV4
■ RT_GTP_PKT_GSNADDR_IE
■ RT_GTP_PKT_IMSI_IE
■ RT_GTP_PKT_MSISDN_IE
■ RT_GTP_PKT_RESULT
■ RT_GTP_SANITY_EXTENSION_HEADER
■ RT_GTP_SYSTEM_ERROR
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:
■ CHASSISD_FM_SIB_TYPE_ERROR
■ CHASSISD_GRES_UNSUPP_INTERFACE
■ CHASSISD_PFE_SUPPORT_ERROR
■ UI_MGD_TERMINATE
[System Log]
User Interface and Configuration
■ Support for new AC Power Entry Module (PEM) and fan tray for MX Series
routers—MX Series routers now support an enhanced AC PEM to provide the
necessary power infrastructure to support up to 12 higher capacity DPCs with
higher port density and slot capacity. To support the cooling requirements for
the enhanced AC PEMs, the routers support enhanced fan trays and fans. The
JUNOS Software introduces the following configuration statements and operational
mode commands to configure and monitor power and fan tray operations:
■ Configuration statements:
■ fru-poweron-sequence—Include the fru-poweron-sequence statement at
the [edit chassis] hierarchy level to configure the power-on sequence
for the DPCs in the chassis.
■ Operational mode commands:

■ show chassis power—Show power limits and usage.
■ show chassis power sequence—Show power-on sequence for the DPCs
in the chassis.
■ show chassis fan—Show status information about the fan tray and fans.
The show chassis fpc detail command introduces a new output line Max Power
Consumption in the CLI output to show the maximum power consumption in
watts.
[System Basics, System Basics and Services Command Reference]
■ UI_LOGIN_EVENT message enhanced with additional information—In addition
to the username, user class, and process ID, the UI_LOGIN_EVENT message now
has SSH connection information, including the address and port for both the
source and destination hosts and also a client mode string. Client mode indicates,
for example, whether the user is in cli or netconf mode. Event policies can utilize
the extended UI_LOGIN_EVENT information to monitor for events that violate
conditions or policies and then take the appropriate action.
[Syslog Messages]
VPNs
■ Configurable label block sizes for VPLS—Enable you to configure the label
block size for VPLS instances. This allows more efficient usage of the limited
label space, thus allowing the router to support a larger number of VPLS instances.
The configurable block sizes are 2, 4, 8, and 16. To configure, include the
label-block-size statement at the [edit routing-instances instance-name protocols
vpls] hierarchy level.
[VPNs]
■ IPv6 support for multiprotocol BGP-based multicast VPNs—Multiprotocol
BGP-based multicast VPNs (also referred to as next-generation Layer 3 VPN
multicast) can transport IPv6 multicast customer traffic over an IPv4 core network
using RSVP-TE tunnels. This feature does not require IPv6 support in the core
network.
To enable IPv6 multicast customer traffic transport over an IPv4 core network
that has already been configured, do the following:
■ Include the ipv6-tunneling statement at the [edit protocols mpls] hierarchy
level on all PE routers participating in the MVPN.
■ Include the unicast statement at the [edit protocols bgp family inet6-vpn]
hierarchy level on all PE routers participating in the MVPN.
■ Include the signaling statement at the [edit protocols bgp family inet6-mvpn]
hierarchy level on all PE routers participating in the MVPN.
■ By default, the routers support MLD version 1 (MLDv1). If you want to use
MLDv2 on the customer edge (CE) routers, include the version statement at
the [edit protocols mld] hierarchy level and specify a value of 2.
■ If you want to use static rendezvous point (RP) configuration, include the
interface interface-name statement at the [edit protocols mld] hierarchy level
on the PE to CE interfaces on all PE routers participating in the MVPN.
■ If you want to use static RP configuration, include the address ipv6-address

statement at the [edit routing-instances routing-instance-name protocols pim
rp local] hierarchy level on the PE router acting as the RP in the MVPN
instance, and include the address ipv6-address statement at the [edit
routing-instances routing-instance-name protocols pim rp static] hierarchy level
on all PE routers participating in the MVPN except the RP router in the MVPN
instance.
■ If you want to use dynamic-RP bootstrap router (BSR) configuration, include

the priority statement at the [edit routing-instances routing-instance-name
protocols pim rp bootstrap family inet6] hierarchy level and specify the priority
value on the desired BSR. Also include the family statement at the [edit
interfaces interface-name unit logical-unit-number] hierarchy level and specify
the inet6 family on the core facing interfaces.
When IPv6 support for MBGP MVPNs is configured, the vpn-instance.mvpn-inet6

route table is created. You can display this route table using the show route table
vpn-instance.mvpn-inet6 command. You can display the customer multicast IPv6

state and RSVP-TE tunnel information using the show mvpn instance command.
[Multicast Protocols, MPLS Applications, Routing Protocols, Routing Protocols and
Policies Command Reference]
■ Full support for shared-tree data distribution (RPT-SPT) across provider
cores—For multiprotocol BGP-based multicast VPNs (also referred to as
next-generation Layer 3 multicast VPNs), this feature provides support for all
RPT-SPT mode operations, as described in Section 13 of the BGP-MVPN draft
(draft-ietf-l3vpn-2547bis-mcast-bgp-00.txt). The following operations are supported:
■ Generating Source-Active A-D route on a PE
■ Receiving Source-Active A-D route on a PE
■ Pruning source off the shared tree
To configure RPT-SPT mode, include the rpt-spt statement at the [edit

routing-instances routing-instance-name protocols mvpn mvpn-mode] hierarchy level
for all VRFs that make up the VPN. To configure a selective provider tunnel for
the shared tree, include the wildcard-group-inet, wildcard-group-inet6, and
wildcard-source statements at the [edit routing-instances routing-instance-name
provider-tunnel selective] hierarchy level.
CAUTION: When you configure RPT-SPT mode, receivers or sources directly attached
to the PE router are not supported. As a workaround, place a CE router between any
receiver or source and the PE router.
[VPNs, Routing Protocols Command Reference]

■ Label allocation and substitution policy—There is a new method for controlling
label advertisements on MPLS ingress and AS border routers (ASBRs). Previously,
labels could only be assigned on a per-next-hop (by default) or a per-table basis
(by configuring the vrf-table-label statement). This choice affects all routes of a
given routing instance.
You can now configure a policy to generate labels on a per-route basis by
specifying a label allocation policy using the allocation label-allocation-policy
statement at the [edit routing-instances routing-instance-name routing-options label]
hierarchy level.
To configure the label allocation policy, include the label-allocation statement at
the [edit policy-options policy-statement policy-statement-name term term-name then]
hierarchy level. You can configure the label allocation mode as either per-nexthop
or per-table.
In addition, the way in which labels are allocated on a VPN option B ASBR has
been changed. Once a VRF table is configured on the ASBR (this type of
configuration is uncommon for the option B model), the ASBR does not generate
the MPLS swap or swap-and-push state for transit routes. Instead, the ASBR
re-advertises a local virtual-tunnel or vrf-table-label label and forwards that transit
traffic based on IP forwarding tables. The label substitution helps to conserve
labels on Juniper Networks routers.
However, this type of label substitution effectively breaks the MPLS forwarding
path, which becomes visible when using an MPLS OAM tool such as LSP ping.
The way in which labels are substituted is now configurable on a per-route basis
by specifying a label substitution policy using the substitution label-substituion-policy
statement at the [edit routing-instances routing-instance-name routing-options label]
hierarchy level.
The label substitution policy is used to determine whether or not a label should
be substituted on an ASBR router. The results of the policy operation are either
accept (label substitution is performed) or reject (label substitution is not
performed). The default behavior is to accept. The following set command
example illustrates how you can configure a reject label substitution policy: set
policy-options policy-statement no-label-substitution term default then reject.
[VPNs]
Related Topics ■ Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M Series,
■ Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers on
page 54
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M Series, MX Series,
and T Series Routers
Class of Service
■ Support for classifiers and rewrite-rules with a subscriber interface in dynamic

profiles—You can now associate classifiers and rewrite-rules with a subscriber
interface in a dynamic profile. In the current release, this feature is available for
testing purposes only.
You must statically configure the classifiers and rewrite-rules at the [edit
class-of-service] hierarchy. To associate a classifier configuration with a subscriber
interface in a dynamic profile, include the classifiers statement at the [edit dynamic
profiles profile-name class-of-service interfaces interface-name unit
logical-unit-number] hierarchy level.
To associate a rewrite-rule configuration with a subscriber interface in a dynamic
profile, include the rewrite-rules statement at the [edit dynamic profiles profile-name
class-of-service interfaces interface-name unit logical-unit-number] hierarchy level.
The JUNOS Subscriber Access Configuration Guide does not contain configuration
information for this feature.
[Class of Service ]
Forwarding and Sampling
■ Enhancement to the show firewall command—The show firewall command now

supports a terse option that enables you to display only the names of firewall
filters. This option displays no other information about the firewall filters
configured on your system. Use the show firewall terse command to verify that
all the correct filters are installed.
42 ■ Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
■ Null control word with cell relay (M Series and T Series routers running JUNOS
Release 8.3 or higher only)—When an MPLS Layer 2 circuit is configured with
cell transport mode on a router running JUNOS Release 8.3 or higher, the
use-null-cw statement inserts (for sending traffic) or strips (for receiving traffic)
a null control word in the MPLS packets to allow interoperability between Juniper
Networks routers running JUNOS Release 8.2 or lower.
You can configure the use-null-cw statement at the [edit interfaces interface-name
atm-options] hierarchy level and the [edit dynamic-profiles profile-name interfaces
atm-options] hierarchy level.
NOTE: The use-null-cw statement is only supported on routers running JUNOS Release
8.3 or higher.
■ Enhancement to show oam ethernet link-fault-management detail command—The
output of the show oam ethernet link-fault-management detail command now
includes the following two new fields: OAM total symbol error event information
and OAM total frame error event information. These fields display the total number
of errored symbols and errored frames, respectively, and are updated at every
interval regardless of whether the threshold for sending event TLVs has been
crossed. Previously, the show oam ethernet link-fault management detail command
displayed only the number of errored symbols reported in TLV events transmitted
since the OAM layer was reset and the number of errored frames detected since
the OAM layer was reset.
[Interfaces Command Reference]
■ Enhancement to show oam ethernet connectivity-fault-management
commands—The output of the show oam ethernet connectivity-fault-management
mep-statistics, show oam ethernet connectivity-fault-management interfaces, and
show oam ethernet connectivity-fault-management mep-database commands
includes the following three new fields: Out of sync 1DMs received, which displays
the number of out of sync one-way delay measurement packets received; Valid
DMMs received, which displays the number of valid two-way delay measurement
request packets received, and Invalid DMMs received, which displays the number
of invalid two-way delay measurement request packets received.
■ Enhancements to optics-options with alarms and warnings—You can now
configure the MX Series router to drop the 10-Gigabit Ethernet link or to generate
log messages when the receiving signal is below the alarm and warning
thresholds. In this release, two alarms and warning types are defined by the
JUNOS Software: “low-light-alarm” and “low-light-warning.”
To drop the 10-Gigabit Ethernet link when the receiving signal is below the
“low-light-alarm,” you would typically have the following configuration:
[edit interfaces]
xe-0/0/0 {
optics-options {
alarm low-light-alarm {
link-down;
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers ■ 43
}
}
}
■ New restrictions on service PIC redundancy settings—When you configure
the redundancy-options statement at the [edit interfaces rlsq number] hierarchy
level, certain combinations of interface settings that use the hot-standby and
warm-standby statements are no longer permitted and result in a configuration
error.
■ Update to the request inteface revert/switchover command—All rlsq switchover
or revert operations are allowed from the rlsqnumber level only and not for
individual channelized interfaces (rlsqnumber:unit). The output format has been
modified to provide more detailed feedback on the status of requested actions.
■ Update to the show interfaces redundancy command—Provides a new option,
show interfaces redundancy detail, that includes an additional field to report the
standby mode.
■ Reduced frame-error threshold window (MX Series routers)—The frame error
threshold window has been reduced from 1 second to 100 milliseconds. Frame
error is a threshold for sending frame error events or taking the action specified
in the action profile. A frame error is any frame error on the underlying physical
layer. The threshold is reached when the number of frame errors reaches the
configured value within the window. Starting with JUNOS Software Release 10.0,
the default window is 100 milliseconds and is not configurable.
To configure the frame-error count, include the frame-error statement at the [edit
protocols oam ethernet link-fault-management action-profile event link-event-rate]
or [edit protocols oam link-fault-management interface interface-name
event-thresholds] hierarchy levels.
■ Non-support for connectivity fault management with circuit
cross-connect—The JUNOS Release 9.6R1 Release Notes reported that M7i
routers and M10i routers with an Enhanced Compact Forwarding Engine Board
(CFEB-E) do not support connectivity fault management (CFM) with circuit
cross-connect (CCC) encapsulation.
This issue has been resolved in JUNOS Release 10.0.
■ Restriction on compatibility-mode adtran and verilink—On 2-port and 4-port
channelized DS3 (T3) IQ interfaces, you cannot configure compatibility-mode
adtran or verilink at the [edit interfaces interface-name t3-options] hierarchy level.
If configured, the default mode is applied on both the interfaces, that is, no
subrating.
■ Non-support for multiple service sets on a single interface—When you include

dynamic application awareness for JUNOS functionality in a service set, including
IDP profiles, application identification rules, application-aware access list rules,
and policy-decision statistics profiles, you can apply only one service set to a
single interface.
■ Intelligent Queuing Enhanced (IQE) interfaces low bandwidth
optimization—On M Series, T Series, and MX Series routers with MX-FPC Type
2 (9.5 onwards) with IQE interfaces running JUNOS Release 10.0 and later;
improved MTU default parameters are provided to enhance performance with
low bandwidth interfaces such as E1 or ds0. If a low bandwidth interface
experiences packet drops, you can also specify an increased large-delay or
huge-delay buffer as a workaround.
To increase the delay buffer size, use the q-pic-large-buffer statement at the [edit
chassis interface-fpc/pic/port] hierarchy level. For more information, see the
System Basics Configuration Guide.
Alternatively, you can configure the buffer size explicitly using the
[class-of-services] hierarchy level for each network control queue to ensure that
the queues have the required amount of buffer. For more information, see the
Class of Service Configuration Guide.
For information on MTU configuration, see the Network Interfaces Configuration
Guide.
[Network Interfaces, System Basics, Class of Service]
■ Circuit emulation (CE) interfaces firmware compatibility for ATM IMA on
M7i, M10i, M40e, M120, and M320 routers—Provides a Firmware mismatch
syslog message and a show interface command output message in the IMA Group
state and IMA Link state if the PIC's firmware is not compatible in JUNOS Release
10.0 and later.
NOTE: CE PICs require firmware version rom-ce-9.3.pbin or rom-ce-10.0.pbin for ATM

IMA functionality on M7i, M10i, M40e, M120, and M320 routers with JUNOS Release
10.0R1.
CE PICs manufactured with the 560-028081.pbin firmware will display the

following entry in /var/log/messages when the JUNOS Software is upgraded to
release 10.0R1 or later:
Firmware mismatch. Need to upgrade PIC PROM Binary CPU firmware for IMA.
If you configure IMA with this combination of JUNOS and CE PIC firmware, the
following entry will appear:
Firmware error. Need to upgrade PIC PROM Binary CPU firmware for IMA.
The show interfaces ce-fpc/pic/port command output will show the following:
Physical link is Down

IMA Group state : NE: Firmware Error
IMA Link state : Line: Firmware Error
You must contact JTAC for a PIC firmware upgrade to proceed with IMA.
[Interfaces Command Reference, System Log Messages Reference]

■ New command to clear Link Aggregation Control Protocol statistics—A new
command, clear lacp statistics, enables you to clear Link Aggregation Control
Protocol (LACP) statistics. Use the interfaces option to clear interface statistics.
You can also clear interface statistics for a specific interface only by using the
interfaces interface-name option.
■ Change to the show interfaces aenumber extensive command—The output of
the show interfaces aenumber command no longer displays Link Aggregation
Control Protocol (LACP) statistics. To display LACP statistics, use the show lacp
statistics interfaces command.
MPLS Applications
■ New ping mpls option—There is now an instance option for the ping mpls ldp
and ping mpls lsp-end-point commands. The instance option allows you to ping
the combination of a routing instance and forwarding equivalence class (FEC)
associated with an LSP connection.
[System Basics Command Reference]
Multiplay
■ Border gateway function (BGF)—The maximum-synchronization-time configuration

statement has been removed from the [edit services pgcp gateway gateway-name
graceful-restart] hierarchy. The system uses a default value of 720 seconds to
provide a high level of performance.
[Multiplay Solutions, Services Interfaces]
Platform and Infrastructure
■ Enhancement to show interfaces command—The show interfaces command

includes a new field, INET6 Address flags, that displays a flag for any IPv6 address
that is in a state other than “permanent” or “ready-to-use.”
Routing Protocols
■ Limitation on the routing instance name when filter-based forwarding is

configured—The name of a routing instance can be a maximum of 128 characters
and can contain letters, numbers, and hyphens. In JUNOS Release 9.0 and later,
when filter-based forwarding is configured, you can no longer specify default as
the actual routing instance name. You also cannot use any special characters (!
@ # $ % ^ & * , +< > : ;) within the name of a routing instance.
Specify the routing instance name with the routing-instance statement:
routing-instance routing-instance-name {...}.
[Routing Protocols, Policy Framework, VPNs]
■ Change to the show ospf/ospf3 route detail command output—The show
ospf/osfp3 route detail command displays an optional capability value for
intra-area router routes only. Intra-area routers appear as Intra Router, Intra AS
BR (Autonomous System Border Router), and Intra Area/AS BR in the output
display. The command no longer displays the optional capability value for
inter-area ASBR routes.
■ Usage of the slash (/) character in a routing instance name—You now specify
a slash (/) character in a routing instance name, but only if you do not have a
logical system also configured. You cannot specify a slash character in a routing
instance name if a logical system other than the default is explicitly configured.
To configure a routing instance, include the routing-instance-name statement at

the [edit routing-instances] hierarchy level. [Routing Protocols, VPNs]
■ Support for having the algorithm that determines the single best path evaluate
AS numbers in AS paths for VPN routes—By default, the third step of the
algorithm that determines the active route evaluates the length of the AS path
but not the contents of the AS path. In some VPN scenarios with BGP multiple
path routes, it can also be useful to compare the AS numbers of the AS paths
and to have the algorithm select the route whose AS numbers match. Include
the as-path-compare statement at the [edit routing-instances routing-instance-name
routing-options multipath] hierarchy level.
[Routing Protocols]
■ Support for having the algorithm that determines the single best path skip
the step that evaluates an AS path—By default, the third step of the algorithm
that determines the active route evaluates the length of an AS path. To enable
the JUNOS Software to skip this step, include the as-path-ignore statement at the
[edit protocols bgp path-selection] hierarchy level. You cannot configure this
statement for a specific routing instance.
[Routing Protocols]
■ New command to clear ip-action flows—Adds the new clear services flows
ip-action command, which enables you to clear ip-action entries generated by the
router to log, drop, or block traffic based on previous matches. The IP action
options and targets are configured at the [edit security idp idp-policy policy-name
rulebase-ips rule rule-name then] hierarchy level.
■ Increase in flow-tap capability—On the flow-tap application, you can now install
a maximum of 100 filters and achieve 100 Kpps throughput. Previously, the
limits were 20 filters and 25 Kpps throughput.
■ Border gateway function (BGF)—When the BGF initially registers with a gateway
controller, it declares the H.248 profile that will be used to control the BGF. The
profile specifies the H.248 options that are supported. For interoperability, you
may need to change the H.248 profile that the BGF declares.
The BGF declares the profile according to the H.248 standard, which is
profile-name/profile-version. For example, the default profile is declared as
ETSI_BGF/1.
To change the profile, include the profile-name and profile-version statements at
the [edit services pgcp gateway gateway-name h248-options h248-profile] hierarchy
level.
■ Integrated Multi-Service Gateway (IMSG)—Assigning maximum values to both
committed-information-rate and committed-burst-size results in no rate limit being
applied to gates for the service class.
■ New configuration to avoid IDP traffic loss (MX Series routers)—When the
MultiServices DPC configured for a service set is either administratively taken
offline or undergoes a failure, all the traffic entering the configured interface with
an IDP service set would be dropped without notification. To avoid this traffic
loss, include the bypass-traffic-on-pic-failure statement at the [edit services

service-set service-set-name service-set-options] hierarchy level and (for TCP traffic
only) the ignore-errors tcp statement at the [edit interfaces interface-name
services-options] hierarchy level. When you configure these statements, the
affected packets are forwarded, in the event of a MultiServices DPC failure or
offlining, as though interface-style services were not configured. This issue applies
only to MultiServices DPCs on MX Series routers and does not affect MS-400
PICs on M120 or M320 routers. [Services Interfaces]
■ Failure of the Packet Forwarding Engine-based RPM feature with stateful
firewall rules—The Packet Forwarding Engine-based RPM feature does not
support any stateful firewall configurations. If you need to combine RPM
timestamping with stateful firewall, you should use the interface-based RPM
timestamping service. Multiservices DPCs support stateful firewall processing as
well as RPM timestamping.
■ RPM service configuration on unit 0—You cannot configure RPM service on
unit 0 because RPM requires a dedicated logical interface; the same unit cannot
support both RPM and other services. Because active flow monitoring requires
unit 0, but RPM can function on any logical interface, a constraint check prevents
you from committing an RPM configuration there.
■ Modification to the show pppoe interfaces command (M120, M320, MX Series,

J Series routers)—In Junos OS Release 9.5 and above, the extensive option for
the show pppoe interfaces command is supported only for J Series routers, which
can be configured as PPPoE clients. The show pppoe interfaces command no
longer supports the extensive option for M120, M320, and MX Series routers in
Junos OS Release 9.5 and above. When an M120, M320, or MX Series router is
configured as an access concentrator server, the statistics for the PPPoE server
interfaces do not increment. As a result, when you issue the show pppoe interfaces
extensive command on a M120, M320, or MX Series router, the statistics are
always displayed as zeros.
■ Enhancement to the clear pppoe statistics command (M120, M320, MX Series,
J Series routers)—The clear pppoe statistics command includes a new option,
underlying-interface-name, for M120, M320, and MX Series routers in Junos OS
Release 9.5 and above. The option enables you to reset the statistics of the
underlying PPPoE interface for static and dynamic PPPoE interfaces. In Junos
OS Release 9.5 and above, the interface interface-name option for the clear pppoe
statistics command is supported only for J Series routers. The clear pppoe
statistics command no longer supports the interface interface-name option for
the M120, M320 and MX Series routers in Junos OS Release 9.5 and above.
■ Support for statically configured schedulers in dynamic profiles for subscriber
access (M120, M320, and MX Series routers)—You can now configure a
combination of static and dynamic parameters for individual schedulers in a
dynamic profile for M120, M320, and MX Series routers. In earlier releases, a
dynamic profile supported one definition for a dynamic scheduler, which
contained scheduler parameters specified using predefined variables. For
example:
schedulers {
$junos-cos-scheduler {
transmit-rate percent $junos-cos-scheduler-tx;
buffer-size percent $junos-cos-scheduler-bs;
priority $junos-cos-scheduler-pri;
drop-profile-map loss-priority low protocol any drop-profile
$junos-cos-scheduler-dropfile-low;
drop-profile-map loss-priority high protocol any drop-profile
$junos-cos-scheduler-dropfile-high;
drop-profile-map loss-priority medium-low protocol any drop-profile
$junos-cos-scheduler-dropfile-medium-low;
drop-profile-map loss-priority medium-high protocol any drop-profile
$junos-cos-scheduler-dropfile-medium-high;
drop-profile-map loss-priority any protocol any drop-profile
$junos-cos-scheduler-dropfile-any;
}
}
Within a dynamic profile, you can choose to configure one dynamic scheduler
definition, or combine static and dynamic scheduler parameters in many static
scheduler definitions. Combining static and dynamic scheduler parameters
enables you to provide subscribers with unique rate configurations that the
RADIUS definitions for predefined variables do not allow.
To configure a static scheduler that contains both static and dynamic parameters,
include the schedulers scheduler-name statement at the [edit dynamic profiles
profile-name class-of-service] hierarchy level. Schedulers that combine static and
dynamic parameters must have a specific scheduler name, not the
$junos-cos-scheduler variable.
In the following example, the network administrator configures the transmission
rate for the data service with the transmit-rate statement. By specifying the
$junos-cos-scheduler-tx variable, RADIUS returns the actual percentage value for
the transmission rate when the subscriber logs in. The network administrator
also specifies the rate-limit statement, which limits the transmission rate to the
rate-controlled amount during congestion.
For the best-effort service, the network administrator assigns the remaining
transmission rate that is available using the remainder statement.
schedulers {
data-scheduler {
transmit-rate percent rate-limit $junos-cos-scheduler-tx;
priority $junos-cos-scheduler-pri;
drop-profile-map loss-priority low protocol any drop-profile d0;
drop-profile-map loss-priority medium-low protocol any drop-profile d1;
drop-profile-map loss-priority medium-high protocol any drop-profile d2;
drop-profile-map loss-priority high protocol any drop-profile d3;
drop-profile-map loss-priority any protocol any drop-profile all;
}
best-effort-scheduler {
transmit-rate remainder
priority medium-high;
drop-profile-map loss-priority low protocol any drop-profile
$junos-cos-scheduler-dropfile-low;
drop-profile-map loss-priority medium-low protocol any drop-profile d1;
drop-profile-map loss-priority medium-high protocol any drop-profile
$junos-cos-scheduler-dropfile-medium-high;
drop-profile-map loss-priority high protocol any drop-profile d3;
drop-profile-map loss-priority any protocol any drop-profile
$junos-cos-scheduler-dropfile-any;
}
}
[Subscriber Access]
■ Per-service subscriber statistics—The show network-access aaa subscribers
statistics username command now displays statistics on a per-service basis for
the specified subscriber. The command output displays the name of each service
followed by creation request, deletion request, and request timeout statistics for
that service.
[Subscriber Access]
■ Bidirectional PPP authentication in subscriber management—Subscriber
management does not allow bidirectional PPP authentication. Unlike traditional
PPP support, authentication is performed only by the router, never by the remote
peer. Additionally, authentication and address assignment are wholly owned by
the authd process for subscriber management. When you configure the
ppp-options statement in the [edit dynamic-profiles] hierarchy, you can configure
either CHAP or PAP authentication, but there are no additional options under
either the CHAP or PAP stanza. Also, other options under the ppp-options
statement, which are either commonly used or mandatory for traditional PPP
interface configuration, are not used in subscriber management dynamic profiles.
[Subscriber Access]
■ Enabling and disabling DHCP snooping support—You can now explicitly enable
or disable DHCP snooping support on the router. If you disable DHCP snooping
support, the router drops snooped DHCP discover and request messages.
To enable DHCP snooping support, include the allow-snooped-clients statement
at the [edit forwarding-options dhcp-relay overrides] hierarchy level. To disable
DHCP snooping support, include the no-allow-snooped-clients statement at the
[edit forwarding-options dhcp-relay overrides] hierarchy level. Both statements are
also supported at the named group level and per-interface level.
In JUNOS Release 10.0 and earlier, DHCP snooping is enabled by default. In
release 10.1 and later, DHCP snooping is disabled by default.
[Subscriber Access]
■ RADIUS interim accounting—When subscriber management receives the
RADIUS Acct-Interim-Interval attribute (attribute 85), RADIUS interim accounting
is performed based on the value in the attribute. The router uses the following
guidelines:
■ Attribute value is within the acceptable range (10 to 1440
minutes)—Accounting is updated at the specified interval.
■ Attribute value of 0—No RADIUS accounting is performed.
■ Attribute value is less than the minimum acceptable value (10

minutes)—Accounting is updated at the minimum interval.
■ Attribute value is greater than the maximum acceptable value (1440

minutes)—Accounting is updated at the maximum interval.
In previous releases, a RADIUS attribute set to zero (0) prevented subscribers

from connecting.
[Subscriber Access]
VPNs
■ New configuration statement for removing dynamically learned MAC

addresses from the MAC address database—Media access control (MAC) flush
processing removes MAC addresses from the MAC address database that have
been learned dynamically. With the dynamically learned MAC addresses removed,
MAC address convergence requires less time to complete.
In this release, you enable MAC flush processing for the virtual private LAN
service (VPLS) routing instance or for the mesh group under a VPLS routing
instance by using the mac-flush statement instead of the mac-tlv-receive and
mac-tlv-send statements.
mac-flush [ explicit-mac-flush-message-options ];
To clear dynamically learned MAC addresses globally across all devices

participating in the routing instance, you can include the statement at the
following hierarchy levels:
■ [edit logical-systems logical-system-name routing-instances routing-instance-name
protocols vpls]
■ [edit routing-instances routing-instance-name protocols vpls]
To clear the MAC addresses on the routers in a specific mesh group, you can
include the statement at the following hierarchy levels:
■ [edit logical-systems logical-system-name routing-instances routing-instance-name
protocols vpls mesh-group mesh-group-name]
■ [edit routing-instances routing-instance-name protocols vpls
mesh-group mesh-group-name]
NOTE: The mac-tlv-receive and mac-tlv-send statements have been removed from the
software and are no longer visible in the [edit logical-systems logical-system-name
routing-instances routing-instance-name protocols vpls] and [edit routing-instances
routing-instance-name protocols vpls] hierarchy levels. Although the mac-tlv-receive and
mac-tlv-send statements are recognized in the current release, they will be removed
in a future release. We recommend that you update your configurations and use the
mac-flush statement.
To also configure the router to send explicit MAC flush messages, you can include
explicit-mac-flush-message-options with the statement:
■ any-interface—(Optional) Send a MAC flush message when any
customer-facing attachment circuit interface goes down.
■ any-spoke—(Optional) Send a MAC FLUSH-FROM-ME flush message to all
provider edge (PE) routers in the core when one of the spoke pseudowires
between the multitenant unit switch and the other network-facing provider
edge (NPE) router goes down, causing the multitenant unit switch to switch
to this NPE router.
NOTE: This option has a similar effect in a VPLS multihoming environment with
multiple multitenant unit switches connected to NPE routers, where both multitenant
unit switches have pseudowires that terminate in a mesh group with local switching
configured. If the any-spoke option is enabled, then both PE routers send MAC
FLUSH-FROM-ME flush messages to all PEs in the core.
■ propagate—(Optional) Propagate MAC flush to the core.
[VPNs]
Related Topics ■ New Features in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
on page 6
Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
The current software release is Release 10.0R4. For information about obtaining the
software packages, see “Upgrade and Downgrade Instructions for JUNOS Release
10.0 for M Series, MX Series, and T Series Routers” on page 108.
■ Current Software Release on page 54
■ Previous Releases on page 79
Current Software Release
Outstanding Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series
Routers
Class of Service
■ On MX Series routers with Enhanced DPCs, bandwidth sharing between two

schedulers, one with high and the other with strict-high priority, might not be
as expected when the schedulers are oversubscribed. That is, only one queue
can use all of the excess bandwidth. This issue occurs when the schedulers are
configured on logical interfaces. [PR/265603]
■ Incorrect class-of-service rewrites might occur when MPLS packets transit between
FPC-ES and FPC-E with the copy-plp statement turned off. [PR/533213]
■ Under certain conditions, the class-of-service configuration might not take effect
on an IQ2 PIC. [PR/541814]
■ The numerical values configured for the ip-options match criteria on a firewall
filter match any ip-options no matter what is specified. [PR/516778]
High Availability
■ The primary Routing Engine might lose the CM/CP information if it loses
connectivity with the redundant Routing Engine (i.e,. by disabling GRES, or
halting and rebooting the redundant Routing Engine). This can cause small packet
drop on multicast traffic upon a multicast distribution tree change. [PR/278882]
■ The SSH keys are not in sync between the master and backup Routing Engine
when SSH is enabled after a graceful Routing Engine switchover (GRES).
[PR/455062]
■ When an ISSU upgrade is performed to or from JUNOS Releases 9.6R3 or 10.0R2,
the logical interface and logical interface sets that have traffic control profiles
configured on them will be affected. [PR/491834]
54 ■ Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
■ For Automatic Protection Switching (APS) on SONET/SDH interfaces, there are

no operational mode commands that display the presence of APS mode
mismatches. An APS mode mismatch occurs when one side is configured to use
bidirectional mode, and the other side is configured to use unidirectional mode.
[PR/65800]
■ The output of the show interfaces diagnostics optics command includes the "Laser
rx power low alarm" field even if the transceiver is a type (such as XENPAK) that
does not support this alarm. [PR/103444]
■ On the M120 router, hot-swapping the fan tray might cause the Check CB alarm
to activate. [PR/268735]
■ On the JCS1200 platform, when you issue the clear -config -T switch[1] command
using the management module, the switch module returns to its factory default
setting instead of the Juniper Networks default setting. As a workaround, do not
issue the command. [PR/274399]
■ On the Juniper Control System (JCS) platform, the control and management
traffic for all Routing Engines shares the same physical link on the same switch
module. In rare cases, the physical link might become oversubscribed, causing
the management connection to Protected System Domains (PSDs) to be dropped.
[PR/293126]
■ On a Protected System Domain (PSD) configured with a large number of BGP
peers and routes (for example, 5000 peers and a million routes), FPCs might
restart during a graceful Routing Engine switchover (GRES). [PR/295464]
■ When two routers are connected via SONET/SDH interfaces that are configured
as container interfaces and the Routing Engine on one router reboots, the
container interfaces on the other router might go down and come up again.
[PR/302757]
■ When forwarding-options is configured without route accounting, the commit
completes with the message "Could not retrieve the route-accounting." However,
no functionality is affected. [PR/312933]
■ If virtual tunnel PICs and ingress traffic manager are enabled on the same Packet
Forwarding Engine/PIC on an EQ DPC, then the SNMP walk of the interface may
time out. [PR/458565]
■ While using an AE-20 on a TX matrix router, the AE link might not respond after
the chassis control is restarted. As a workaround, deactivate and reactivate the
AE interface. [PR/458926]
■ The bridge-domain MAC learn limit on the Packet Forwarding Engine can
sometimes become negative if the bridge domain is deleted and added
immediately as part of a configuration change. If that happens, the MAC learning
on that bridge domain can be affected. As a workaround, deactivate and reactivate
the bridge domain or VPLS routing instance configuration. [PR/467549]
■ If a firewall show command is followed by the clear command in quick succession,
there is a possibility that the show command will time out. If the show command
is issued after a few seconds (5 seconds ideally), this issue will not be seen.
[PR/479497]
Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers ■ 55
■ On a TX Matrix router, commit returns a validation error if there are no fxp0

configurations at the [groups lccX] hierarchy level , and the following is applied
simultaneously:
groups {
int-disable {
interfaces <*> disable;
interfaces {
<*> {
disable;
}
}
}
}
[PR/482612]
■ With JUNOS Release 10.0, the system supports only 31 remote PEs. [PR/488139]
■ The output of the show chassis environment pem command displays the voltage
used in the FPC slots 0 through 3, even after the FPC is taken offline. [PR/528821]
■ The SCB displays an incorrect state when it is removed without taking it offline
using the CLI or buttons. This is not a cosmetic error and might impact the traffic.
[PR/536866]
■ While inserting the DPC into the chassis, the chassid log might display a bogus
error message: "FPC X temperature is -60 degrees C, which is outside operating
range." This message does not impact any functionality. [PR/470512]
■ On a TX Matrix router, an aggregate bundle composed of member links from
different LCCs has the same slot/PIC/port, and results in duplication of Link
Aggregation Control Protocol (LACP) port numbers. For example, a bundle with
actor and partner shown below will result in a duplicate LACP port number since
ge-0/3/0 and ge-8/3/0 (and similarly ge-1/3/0 and ge-9/3/0) are the same
slot/PIC/port but from different LCCs.
Actor Partner
ge-0/3/0 ge-1/3/0
ge-8/3/0 ge-9/3/0
On MX960 routers, duplicate LACP port numbers will result in aggregate bundles
composed of member links for the same PIC and port on slots (0, 8), (1,9), (2,10),
and (3,11). Also, the following sets of ports on any slot will have duplicate LACP
port numbers:
■ PIC 0 port 8 and PIC 1 port (0,8)
NOTE: The duplicate LACP port number described above does not affect the
aggregation, but affects the SNMP extracting port information, and shows an identical
pair of SNMP dot3adAggPortPartnerOperPort and dot3adAggPortActorPort for the
above mentioned links of the aggregate bundle.
[PR/526749]
■ The command clear l2-learning remote-backbone-edge-bridges causes the MX-DPC
to stop and restart. There is no work-around. Do not use this command on MX
Series routers. [PR/546438]
MPLS Applications
■ The rt column in the output of the show mpls lsp command and the active route
counter in the output of the show mpls lsp extensive command are incorrect
when per-packet load balancing is configured. [PR/22376]
■ The routing protocol process might crash at rsvp_find_lp_tag_route occasionally.
[PR/55748]
■ For point-to-multipoint label-switched paths configured for VPLS, the ping mpls
command reports a 100 percent packet loss even though the VPLS connection
is active. [PR/287990]
■ The routing protocol process crashes when configuration changes occur that
involve adding an interface to the routing protocols. [PR/456241]
■ During an RSVP local repair process, when a link flaps or the IGP metric changes
along the LSP path, the routing protocol process scheduler slips. [PR/513312]
■ Under NGEN-MVPN with vrf-table-label configured on the provider edge, the
provider router connecting to that provider edge might keep an old P2MP MPLS
label entry upon label-switched path optimization or reroute. There is no
workaround. [PR/538144]
■ An LSP with auto-bw might stay down for approximately 30 minutes after a
Routing Engine switchover or a Routing Engine restart when graceful restart
fails. As a workaround, disable and reenable MPLS or OSPF stanza. [PR/539524]
Network Management
■ The interface description configured on the logical instance displays only on a

commit full and not with the commit command. [PR/288595]
■ Tcpdump may crash when IPv6 malformed packets are received with
NextHeader=AH. [PR/399073]
■ After changes are made to the firewall, and the counters are cleared and
commited, SNMP sends the wrong value for 5 seconds and a discrepancy occurs
between the CLI output and the get SNMP output. [PR/459583]
■ The SNMP process might restart when a core dump is generated. [PR/517230]
■ On T Series routers, a Layer 2 maximum transmission unit (MTU) check is not

supported for MPLS packets exiting the routing platform. [PR/46238]
■ When you configure a source class usage (SCU) name with an integer (for
example, 100) and use this source class as a firewall filter match condition, the
class identifier might be misinterpreted as an integer, which might cause the
filter to disregard the match. [PR/50247]
■ If you configure 11 or more logical interfaces in a single VPLS instance, VPLS
statistics might not be reported correctly. [PR/65496]
■ When a large number of kernel system log messages are generated, the log
information might become garbled and the severity level could change. This
behavior has no operational impact. [PR/71427]
■ In the situation where link services (LS) interface to a CE router appears in the
VPN routing and forwarding table (VRF table) and fragmentation is required,
Internet Control Message Protocol (ICMP) cannot be forwarded out of the LS
interface from a remote PE router that is in the VRF table. As a workaround,
include the vrf-table-label statement at the [edit routing-instances
routing-instance-name] hierarchy level. [PR/75361]
■ Traceroute does not work when ICMP tunneling is configured. [PR/94310]
■ If you ping a nonexistent IPv6 address that belongs to the same subnet as an
existing point-to-point link, the packet loops between the two point-to-point
interfaces until the time-to-live expires. [PR/94954]
■ On T Series and M320 routers, multicast traffic with the "do not fragment" bit
is being dropped due to configuring a low MTU value. The router might stop
forwarding all traffic transiting this interface if the clear pim join command is
executed. [PR/95272]
■ A firewall filter that matches the forwarding class of incoming packets (that is,
includes the forwarding-class statement at the [edit firewall filter filter-name term
term-name from] hierarchy level) might incorrectly discard traffic destined for the
Routing Engine. Transit traffic is handled correctly. [PR/97722]
■ The JUNOS Software does not support dynamic ARP resolution on Ethernet
interfaces that are designated for port mirroring. This causes the Packet
Forwarding Engine to drop mirrored packets. As a workaround, configure the
next-hop address as a static ARP entry by including the arp ip-address statement
at the [edit interfaces interface-name] hierarchy level. [PR/237107]
■ When you perform an in-service software upgrade (ISSU) on a routing platform
with an FPC3 or an Enhanced FPC3 with 256 MB of memory and the number
of routes in the routing table exceeds 750,000, route loss might occur. If route
loss occurs, as a workaround, perform either of the following tasks:
■ Replace the FPC3 or Enhanced FPC3 with another FPC that has more
memory, or
■ After the ISSU is complete, reboot only the FPC3 or Enhanced FPC3.
[PR/282146]
■ For Routing Engines rated at 850 MHz (which appear as RE-850 in the output of
the show chassis hardware command), messages like the following might be
written to the system log when you insert a PC Card: “bad Vcc request” and
“Device does not support APM.” Despite the messages, operations that involve
the PC card work properly. [PR/293301]
■ On a Protected System Domain, an FPC might generate a core file and stop
operating under the following conditions:
■ A firewall policer with a large number of counters (for example, 20,000) is
applied to a shared uplink interface, and
■ The FPC that houses the interface does not have a sufficiently powerful CPU.
As a workaround, reduce the number of counters or install a more powerful FPC.

[PR/311906]
■ When a CFEB failover occurs on an M10i or M7i router that has had 4000 or
more IFLs, the following message appears:
IFRT: 'IFD ioctl' (opcode 10) failed

ifd 153; does not exist
IFRT: 'IFD Ether autonegotiation config' (opcode 163) failed
The message has no operational impact. When the backup CFEB becomes the
active CFEB, the message will not display. [PR/400774]
■ The following error message may show up for tunnel pics in /var/log/messages:
“/kernel: if_tunnel_cookie_remove no callback!!!”. These messages are harmless
and are not valid. [PR/422715]
■ Redirect drops that are not real errors are taken into account for "Iwo HDRF"
error statistics that are reported in the output of the show pfe statistics errors
command on I-chip based routers. Since redirect drops are expected in a VPLS
(and Ethernet in general) environment, this behavior could be misleading.
[PR/430344]
■ In some cases, the alarms displayed in FPM and the alarms shown using the
show chassis alarms sfc 0 command mismatch. [PR/445895]
■ The configured static NDP entry is cleared automatically after a certain interval.
[PR/453710]
■ The SFC management interface em0 is often displayed as fxp0 in several warning
messages. [PR/454074]
■ If the subinterface on an aggregate interface goes down, the GRE traffic egressing
that interface might not use the backup subinterface resulting in the GRE traffic
being dropped. [PR/454751]
■ Under rare conditions, the router may generate FUD core while incorporating
changes made when some DHCP-related configurations are added or deleted
(for example, delete bootp server address). [PR/458132]
■ If you add a destination to a tunnel interface, and if the destination's outgoing
interface is the tunnel itself, the action creates a cyclic chain between the tunnel
and the destination that causes the kernel to restart. [PR/472324]
■ The VPN label does not get pushed on the label stack for Routing
Engine–generated traffic with l3vpn-composite-next-hop activated. As a
workaround, configure per-packet load balancing to push the VPN/tunnel labels

correctly. [PR/472707]
■ On restarting with a large-scale configuration (16,000 logical interfaces per MPC),
the MPC-3D-16XGE-SFPP card may take up to 15 minutes to come up.
[PR/478548]
■ Payload corruption and packet drops might occur for packets bigger than 3000
bytes when MPLS over GRE is configured on an MS-100. [PR/478563]
■ The traffic sent to ports on PB-4OC3-4OC12-SON-SFP PICs in an MX-FPC2 (sent
above the configured bandwidth) may be dropped silently and
non-deterministically. This uncontrolled traffic drop can lead to high priority
traffic such as the PPP LCP being dropped. Depending on traffic conditions, this
can cause a link configured for PPP to bounce indefinitely. [PR/493793]
■ The MAC address of a configured static NDP entry is overwritten when NA is
received from a connected device. [PR/499418]
■ The static NDP entry remains permanent if the refcount is more than 1, even
after deleting the static configuration. [PR/499441]
■ When eight FPC cards are swapped out and replaced with a different FPC type,
the kernel crashes when the last FPC is powered on. [PR/502075]
■ The tty sessions to a router can cause a null pointer dereference. [PR/502816]
■ The TTL on the wire is one less than the tunnel TTL configured through the CLI.
[PR/506454]
■ When an AE interface on an ECMP path is taken down, packet drops can occur
on traffic that is on another link in the ECMP path. [PR/513102]
■ The Packet Forwarding Engine incorrectly imposes a rate limit function for the
host-bound virtual LAN tagged packets with an IEEE 802.1p value of 1. There is
no workaround. [PR/529862]
Routing Policy and Firewall Filters
■ The following features are not supported in a 12-16x10G DPC:

■ Known unicast and unknown unicast types in the input match condition
'Traffic-type' in a family bridge/VPLS
■ The following match conditions do not work:
■ learn-vlan-1p-priority
■ learn-vlan-1p-priority-except
■ learn-vlan-id
■ learn-vlan-id-except
■ user-vlan-1p-priority
■ user-vlan-1p-priority-except
■ user-vlan-id
■ user-vlan-id-except
■ VPLS flood FTF and input FTF
■ Simple filters
■ Filter action 'then ipsec-sa'
■ Filter action 'then next-hop-group'
■ MAC filter output accounting and output policing
[PR/466990]
Routing Protocols
■ When you configure damping globally and use the import policy to prevent
damping for specific routes, and a new route is received from a peer with the
local interface address as the next hop, the route is added to the routing table
with default damping parameters, even though the import policy has a non
default setting. As a result, damping settings do not change appropriately when
the route attributes change. [PR/51975]
■ When you issue the show ldp traffic-statistics command, the following system
log message might be generated for all forwarding equivalence classes (FECs)
with an ingress counter set to zero: "send rnhstats GET: error: ENOENT — Item
not found." [PR/67647]
■ If ICMP tunneling is enabled on the router and you configure a new logical system
that does not have ICMP tunneling enabled, the feature is globally disabled.
[PR/81884]
■ The keepalive timeout counter for multicast sessions may not display after you
deactivate and activate the pim protocol. This is a cosmetic issue and there is no
interruption to the multicast traffic flow. [PR/419509]
■ Setting the advertise-high-metric option while using IS-IS overload also suppresses
route leaking. [PR/419624]
■ On JUNOS OSPF, all locally generated Type 5 LSAs are purged and regenerated
while deleting an NSSA area from the area border router (ABR). [PR/457579]
■ When aggregate interfaces are used for VPN applications, load balancing may
not happen with a Layer 2 circuit configuration. [PR/471935]
■ During transient periods where both a secondary and primary LSP exists in a
routing table, and the number of LSP NHs is greater than 16 in a multi-gateway
scenario, IS-IS may remove the preferred LSP NH. For example, IS-IS could
remove an HIPRI LSP. [PR/485748]
■ The routing protocol process crashes at task_reconfigure in task.c:2653 during
a failed MVPN configuration change. [PR/486183]
■ On recieving a BGP open message with the hold time as 0 seconds, the router
may ignore that value and set its holdtimer to 90 seconds. [PR/487107]
■ The BGP BMP message for IPv6 withdraw encoding does not follow the BMP-draft.
[PR/512780]
■ When an interface comes up after a down event, and LDP-IGP sync is configured
for that interface, OSPF does not include the interface in its LFA calculations
while the interface is in LDP sync hold-down state. [PR/515482]
■ Under rare circumstances, multiple commits might crash both the Routing
Engines. The routing protocol process dumps core and restarts only on the master
Routing Engine. This issue occurs when commits are executed within a minute.
[PR/516479]
■ When the received next hop for a route has the same address as the EBGP peer
to which the route is readvertised, the next hop is erroneously set to the peer's
address instead of the next hop to self. [PR/533647]
■ When a certain combination of route-damp parameters is configured for BGP,
the resulting internal calculations result in an attempt to allocate 0 bytes of
memory, causing the routing protocol process to crash and restart. As a
workaround, avoid the exact combination of poison values in the configuration.
[PR/534780]
■ When an IGMP snooping host interface goes down, mcsnoopd does not update
the affected next hops for the statically configured groups. When the interface
comes back up, the affected next hops remain in the inconsistent state, leading
to traffic outage. As a workaround, restart the mcsnoopd process. [PR/536109]
■ When an interface is added in a routing instance with rpf-check enabled, the
routing protocol process might crash if the route distinguisher is also changed
at the same time. [PR/539321]
■ The show services accounting flow-detail extensive command sometimes displays

incorrect information about input and output interfaces. [PR/40446]
■ When a routing platform is configured for graceful Routing Engine switchover
(GRES) and Adaptive Services (AS) PIC redundancy, and a switchover to the
backup Routing Engine occurs, the redundant services interface (rsp-) always
activates the primary services interface (sp-), even if the secondary interface was
active before the switchover. [PR/59070]
■ Detection of failure of remote PPP clients on the LNS through LCP echo requests
will take a longer time due to the increase in the number of echo request retries.
[PR/250640]
■ When a standard application is specified at the [edit security idp idp-policy
policy-name rulebase-ips rule rule-name match application] hierarchy level, the IDP
does not detect the attack on the non-standard port (for example, junos:ftp on
port 85). [PR/477748]
■ Flow monitoring records are not generated as fragmented IPv6 packets are not
getting sampled. [PR/478571]
■ The MS-PIC or MS-DPC might restart when active SIP flows are forcefully cleared
using the clear service stateful-firewall flows command. [PR/518810]
■ After an user establishes an SSH connection, the sshd process is spawned on
the server and services the user. After the connection is established, the sshd
process listens on a socket and keeps polling in the select() and sleeps until there
is something to be processed on the socket. When the client closes the
connection, a message is sent on the socket to the server, which reads and
processes the tear-down of the connection. However, when a blocking TCP is
sent to the client to detect the client's presence, the timeout never expires.
[PR/538342]
■ The router always uses the revert-interval value that is configured at the [edit
access] hierarchy level, and ignores any revert-interval value that is configured
at the [edit access profile] hierarchy level. If no value is configured, the router
uses the default value of 600 seconds. [PR/454040]
■ The RADIUS accounting stop messages do not include the Acct-Terminate-Cause
attribute (type 49). [PR/458034]
■ On an MX Series router running an affected release and configured for subscriber
management with a DHCP local server retrieving information from RADIUS, the
Framed-IP-Netmask returned by RADIUS may be ignored if a Framed-Pool is
also returned (and points to an existing pool). The netmask used will be that of
the network configured in the pool. [PR/487332]
■ The DHCP clients may not get bound after a filter action under a firewall filter
context is deactivated and deleted. [PR/488627]
■ When the allow-command show interfaces $ is set in the class definition (specified
inside a user configuration), the user is unable to access any commands that
begin with show. [PR/55413]
■ The user cannot prevent the deletion of configuration groups with the
allow-configuration and deny-configuration statements. [PR/59187]
■ On M20 routers, after a Routing Engine mastership switchover, it might not be
possible to enter CLI configuration mode on the new master Routing Engine.
Also, the request system reboot and request system halt commands do not clearly
fail but do not return the CLI prompt either. [PR/64899]
■ The JUNOScript perl module for NETCONF does not support configuration-text.
[PR/82004]
■ The “Local Password:" prompt appears even though the authentication order
has a password configured. [PR/94671]
■ The logical system administrator can modify and delete master administrator-only
configurations by performing local operations such as issuing the load override,
load replace, and load update commands. [PR/238991]
■ The “replace:” tag is missing from the output of the save terminal command from
inside a configuration object.
Example:
edit system
save terminal
system {
host-name blue;
}
[PR/269736]
■ The user can still commit an invalid configuration successfully, even when DDL
checks exist. [PR/282896]
■ After AI scripts are added, the existing management sessions (including the one
used to add the AI scripts) must exit the edit mode and reenter it for any
subsequent configuration changes to take effect. Changes made in these existing
edit sessions are not written to the candidate configuration. [PR/297475]
■ A user class configuration with the deny command ".*" returns .noop error when
enter is used on the router CLI. As a workaround, replace "^$" with
"^.noop-command$" in allow regex. [PR/311426]
■ Users who have superuser privileges will sometimes have their access restricted
to view permission only when they log in through TACACS. [PR/388053]
■ On M Series, MX Series, and T Series routers, the user cannot differentiate
between active and inactive configurations for system identity, management
access, user management, and date and time pages. [PR/433353]
■ When the syslog configuration for forwarding messages to a remote host has
the source-address configured, the messages may not be filtered by regular
expressions. [PR/446140]
■ Selecting the Monitor port for any port in the Chassis Viewer page takes the user
to the common Port Monitoring page instead of the corresponding Monitoring
page of the selected port. [PR/446890]
■ In J-Web, the associated 'dscp' and 'dscpv6' for a logical interface might not be
mapped properly while editing the classifiers of a logical interface. This might
also affect the "Delete" functionality as well. [PR/455670]
■ The router may generate erroneous authd error log messages when PPP/DHCP
clients are used. [PR/457428]
■ In an M Series chassis setup or a dual RE Chassis, the Chassis Information page
Monitor > System View > Chassis Information in the J-Web interface displays
an incorrect value for Routing engine module in the Master tab and no value for
Routing engine module in the Backup tab. [PR/463811]
■ On MX Series routers, J-Web does not display the USB related information under
Monitor> SystemView> System Information> Storage. [PR/465147]
■ On M7i and M10i routers with Enhanced CFEB installed, the chassis viewer
plug-in does not display the Routing Engine in the front view and the E-CFEB in
the rear view. However, the chassis contents from the system (left-side tab)
display the list of components correctly. [PR/483375]
■ When a new-line character (\n) is used within the op script argument descriptions,
the help output might display incorrectly, and could result in an extra output
being displayed when the op script runs. [PR/485253]
■ On J-Web, the error message: “Fatal error: Allowed memory size..." displays
when the Interfaces tab is selected. This message also displays when the
Interfaces tab under Class-of-Service is selected. [PR/495825]
■ Invalid XML characters such as &#x11 (0x11) or &#20 (0x14) are allowed to be
loaded into the router. As a result, the XML parsers break as the characters are
not XML compliant. [PR/502994]
■ The annotate command does not appear when it is used under the edit private
command for class of service. [PR/535574]
■ When you use an https connection on Internet Explorer to save a report from
the View Events page (Monitor > Events and Alarms > View events) in the
J-Web interface, the following error message is displayed: Internet Explorer was
not able to open the Internet site. [PR/542887]
VPNs
■ When you modify the frame-relay-tcc statement at the [edit interfaces

interface-name unit logical-unit-number] hierarchy level of a Layer 2 VPN, the
connection for the second logical interface might not come up. As a workaround,
restart the chassis process (chassisd) or reboot the router. [PR/32763]
■ On a router configured for nonstop active routing (NSR) (the nonstop-routing
statement is included at the [edit routing-options] hierarchy level), if a nonstop
active routing switchover occurs after the configuration for routing instances
changes in certain ways, the BGP sessions between PE and CE routers might not
be established after the switchover. [PR/399275]
■ On MX Series, M120, and new EIII FPCs on M320 routers, the ISO/Connectionless
Network Service (CLNS) packets over the translational cross-connect (TCC) are
dropped in the case of Frame Relay, even though the family TCC has been
configured to switch family iso on the Frame Relay interface. [PR/462052]
■ The routing protocol process crashes when the rd value for an old instance is
different from the rd value for a new instance in the VLAN ID. [PR/512499]
■ If a VRF routing instance contains a static route that is resolved via a route that
was auto-exported from another routing instance, the static route might not be
removed when the physical interface goes down. [PR/531540]
■ Under certain circumstances, the container interfaces might not send the proper
martini modes to the routing protocol process. This results in an incorrect cntl
word related information being sent to the Packet Forwarding Engine.
[PR/541998]
Resolved Issues in JUNOS Release 10.0 for M Series, MX Series, and T Series
Routers
Class of Service
■ When you set the port speed of a multirate SONET Type 2 PIC to OC3, the CoS
speed value is not changed correctly within the Packet Forwarding Engine. The
speed value remains OC12, which results in unexpected CoS behavior. There is
no workaround. [PR/279617: This issue has been resolved.]
■ When a VLAN ID is changed, the following message appears in the messages
log: "COSD_GENCFG_WRITE_FAILED: GENCFG write failed for Classifier to IFL
74. Reason: File exists.” This log message appears when the configuration is
committed with VPLS configured on the Gigabit Ethernet interface, and the
class-of-service classifier or rewrite rules that contain IEEE 802.1P on the interface
are used. [PR/408552: This issue has been resolved.]
■ If a logical interface is configured or added to an interface-set for which an
existing traffic control profile is applied, any rate-limit functionality will not be
applied to the new logical interface. To correct this problem, deactivate and
activate the interface portion of the class-of-service configuration. [PR/485872:
This issue has been resolved.]
■ On an I-chip-based platform for strict high priority queue (SHQ), the buffer size
allocated by the Packet Forwarding Engine is capped by the tx-rate. If the tx-rate
is configured to a very small value or is not configured, and is automatically
allotted a zero or a very small remaining value; the queue is also allotted a
proportionately small delay buffer. This can sometimes lead to red and tail drops
on the SHQ when there is a burst of traffic (with a certain traffic pattern) on it.
As a workaround, configure a nominal tx-rate value (5 percent) for the SHQ.
[PR/509513: This issue has been resolved.]
■ On M Series and T Series routers, the forwarding class information is lost when
the packet enters the GRE tunnel with a clear-dont-fragment bit enabled.
Additionally, on an Enhanced FPC or M120 FEB, the packet is also likely to be
dropped if it is classified to a packet loss priority (PLP) other than low.
■ In a scaled configuration, the class-of-service classifier does not work properly.
■ When a logical interface set has a shaping-rate less than the sum of transmit-rates
of its queues and when the configuration is corrected so that the logical interface
set gets the correct shaping-rate, ADPC might crash. [PR/523507: This issue has
been resolved.]
■ On an MX-FPC Ichip physical interface queueing with rate-limit or exact
configuration enabled, the in-contract traffic is dropped when other queues are
over-subscribed. [PR/526339: This issue has been resolved.]
■ Policers cannot be modified after a system upgrade due to a flaw in the parser
routine. This error occurs when the current item is deleted and the parser cannot
proceed to the next item. With the fix, the routine in the forwarding process
(dwfd) has been modified so that the next item in the object tree is fetched before
the current object is parsed. [PR/433418: This issue has been resolved.]
■ While the JUNOS Software adopts random as its sampling algorithm, the
SAMPLING_ALGORITHM in the flow monitoring version 9 template shows 0x01
(deterministic) instead of 0x02 (random). [PR/438621: This issue has been
resolved.]
■ A JUNOS Software compiler bug in the match combination optimization can
cause an incorrect firewall filter evaluation. [PR/493356: This issue has been
resolved.]
■ When a Layer 2 policer is configured under a logical interface that has multiple
families configured under it, and the policer is changed to another, the newly
configured policer might not take effect unless the policer configuration is
deactivated and reactivated. [PR/501726: This issue has been resolved.]
■ When a filter with an ip-options "any" firewall match is applied on an interface
on the MX-MPC, the filter is not applied. If the hardware is present at the time
of the configuration commit, a commit warning is issued. However, the commit
does not fail and the rest of the configuration is applied. [PR/524519: This issue
has been resolved.]
■ On T640 and T1600 routers with ST chipset FPCs, in some cases where the IPv6
firewall filters with match conditions configured on address prefixes are longer
than 64 bits, the filter may not be evaluated correctly. This might lead to loss of
packets. [PR/524809: This issue has been resolved.]
■ When logical systems are configured, the show bridge-domains operational
command might timeout and return the following error message: “error: time
out communicating with l2-learning daemon.” [PR/536604: This issue has been
resolved.]
■ The MX DPC might reboot with the error message: "EZ:

ezchip_get_srh_msg_from_srhq". [PR/310223: This issue has been resolved.]
■ The backup Routing Engine can fail to obtain mastership in the following cases:
■ re0 gets stuck and doesn't reboot.
■ Due to a hardware problem, re0 looses its connectivity with both the Control
Board and the Packet Forwarding Engine.

■ When a backup Routing Engine is replaced after a graceful Routing Engine
switchover (GRES), the device control process (dcd) generates a new link local
address on non-MAC interfaces such as SONET. [PR/429078: This issue has been
resolved.]
■ CFMD might crash when the following is configured and commited at once on
a VPLS setup:
■ Encapsulation VLAN-VPLS on a physical and logical interface
■ Family VPLS on a logical unit
■ Interface is added in the VPLS routing instance
As a workaround, add the above configurations one at a time and commit.

■ When lockout is configured and the router is rebooted, the working router is
stuck in the wait-to-restore state while the protect router still shows channel state
working and no requests, but no longer shows the lockout flag. [PR/474482: This
issue has been resolved.]
■ When an IQ2 PIC is brought online with a class-of-service configuration that
includes a scheduler using the rate-limit options, the system incorrectly reports
that rate limiting is not supported on the PIC. [PR/482199: This issue has been
resolved.]
■ The AE logical interface flaps when the PIC that has the active link-protection
member link is taken offline. [PR/493492: This issue has been resolved.]
■ On MX Series routers, traffic is forwarded over the backup link even after the
primary link is disabled and enabled again. [PR/493861: This issue has been
resolved.]
■ When link trace entries are added in the path database, there is no check to see
if the current number of entries have reached the path database size. Due to
this, the entries were get learnt beyond the path database size (configured or
default). [PR/494584: This issue has been resolved.]
■ Polling ifInOctets on Gigabit Ethernet IQ PIC VLANs might momentarily return a
higher value. [PR/500852: This issue has been resolved.]
■ Under certain circumstances, a backup Routing Engine reboot followed by a
Routing Engine failover can cause the LACP to flap, which causes AE bundles to
flap. [PR/502937: This issue has been resolved.]
■ When the show lacp interface aex command is used for a nonexistent AE interface,
no error is returned. [PR/503806: This issue has been resolved.]
■ If a T640-FPC4-ES is installed in a T1600 router and an SIB statistics collection
is performed, the message log might report "JBUS: U32 read error, client .." only
if one of the SIBs is faulted or in the offline state. This system log message will
also appear if the T640-FPC4-ES FPC is removed from the chassis. There is no
operational impact. [PR/504363: This issue has been resolved.]
■ On MX Series routers with JUNOS Release 10.0R2 or higher, the backup Routing
Engine might report the following warning message upon commit once network
service is configured under the chassis stanza: "WARNING: network services flag
has been changed, please reboot system." [PR/505690: This issue has been
resolved.]
■ On an M20 router with AC PEMS, the alarm message “Power Supply x not
providing power” is generated when the power cord is removed. The alarm is
not cleared when the power cord is reconnected. [PR/506413: This issue has
been resolved.]
■ When an FEB switchover occurs on an Ichip with APS protect status enabled,
the traffic is duplicated. [PR/506747: This issue has been resolved.]
■ The JUNOS Software may accept duplicate data-link connection identifiers (DLCIs)
configured on the same physical interface. [PR/506908: This issue has been
resolved.]
■ The Routing Engine on slot 1 takes mastership regardless of the user-configured
Routing Engine mastership priority. [PR/507724: This issue has been resolved.]
■ On M7i routers with JUNOS Release 8.5 or later, the output of the show interfaces
fxp0 command shows the fxp0 interface to be in the link up state even when
the interface is disabled with no cables connected. [PR/508261: This issue has
been resolved.]
■ The AE interface does not generate ICMP redirect messages. [PR/508691: This
■ On M7i and M10i routers, the syncer process writes to the file
/var/rundb/chassisd.dynamic.db every 30 seconds. [PR/511901: This issue has
been resolved.]
■ Under certain circumstances, the chassisd process might crash on a backup

Routing Engine while a configuration is commited. [PR/512044: This issue has
been resolved.]
■ When the 1x10GE PIC is taken online, 1x10GE PIC related error messages displays
in the logs. However, these messages do not have any functional impact.
■ When a container logical interface unit is added or deleted, an APS channel
mismatch trap is raised from all the protect container interfaces. [PR/512825:
■ Due to a flaw in implementation, the execution of the show interfaces
mac-database command causes the IQ2 PIC to reboot with the core. [PR/513407:
■ APSD does not perform a switchover to the primary circuit, and both the primary
and secondary circuits remain disabled when the following steps are performed:
■ Force traffic from the primary circuit to the secondary circuit.
■ Remove the Tx on the secondary circuit at the local end, or insert LOS on
the secondary circuit from the near end to the far end.

■ When the show chassis hardware models command or the show chassis hardware
| display xml command is used, the FRU part-number 710-013035 displays the
model number T1600-FPC3-ES instead of T640-FPC3-ES. [PR/514072: This issue
has been resolved.]
■ When the show chassis hardware models or show chassis hardware | display xml
command is issued for M320-FPC*-E3 with part-numbers 710-025464,
710-025853, and 710-025855, the model number does not display correctly.
■ A local protocol MTU on an interface with PPP encapsulation might be higher
than the configured media MTU after a PPP negotiation when the remote end
has a higher media MTU configured. [PR/514079: This issue has been resolved.]
■ The monitor traffic interface (tcpdump) does not produce an outbound output
with matching option when used with the encapsulation
flexibile-ethernet-services. [PR/514247: This issue has been resolved.]
■ Due to a 32 bit timer overflow, the SPC BCM register does not read properly.
This is a cosmetic issue. [PR/514325: This issue has been resolved.]
■ When traffic flows across IQE SDH/SONET interfaces, instantaneous inaccurate
traffic rate values with smaller packet sizes occur when the show interface
command is issued. [PR/514330: This issue has been resolved.]
■ The SIB details might not display in the output of the show chassis hardware
command after the SIB is inserted in the slot. [PR/515789: This issue has been
resolved.]
■ Under certain conditions, some Packet Forwarding Engines may fail to install
VPN multicast routes when downstream interfaces are RLSQ bundles. [PR/515878:
■ The T1600-FPC4-ES might experience HSL2 CRC errors at the fabric portion
leading to "destination errors," "Check SIB," and other fabric plane errors. It is
recommended to upgrade the JUNOS Software to a version that contains the fix.
■ On some XENPAK modules, the output of the show chassis hardware command
shows the message "NON-JNPR UNKNOWN" when the FPC is booted. There is
no impact on the traffic. To solve this issue, take the PIC offline and bring it back
online. [PR/516411: This issue has been resolved.]
■ On an M120, M7i, or M10i router with Enhanced CFEB running JUNOS Release
10.0 and a VRF routing instance configured with vrf-table-label, the VPN traffic
might not flow when an ATM II IQ PIC is used for a core-facing link. [PR/516485:
■ When a Frame Relay interface goes down, the interface statistics might still
indicate that the data-link connection identifier (DLCI) is active. [PR/516497:
■ When the configuration of shaping and scheduling is added or removed from
the CLI, the traffic from the other PE routers is lost. [PR/517320: This issue has
been resolved.]
■ On IQ2 and IQ2E 10GE PICs operating in WAN-PHY mode, the path trace
information is not transmitted to the remote end. [PR/518331: This issue has
been resolved.]
■ In JUNOS Release 10.0 and later, the MIB value for OID ifSpeed and ifHighSpeed
on the aggregated Ethernet logical interface is shown incorrectly as 0. This occurs
when the bandwidth of the logical interface is not configured for the aggregated
Ethernet interface. [PR/519855: This issue has been resolved.]
■ When the centralized configuration management (CCM) interval is set to 1m or
above, the CCM flaps for an incorrect hold_time adjacency entry. [PR/520064:
■ The CE_SUPPORT-DCD crashes when a commit is performed. [PR/521380: This
■ When multiple routed IPsec tunnels are configured, and the tunnel with the
inside-service-interface defined in the service-set goes down, the other tunnels
with the ipsec-inside-interface configured only in the IPsec rules might stop
forwarding traffic until the main tunnel comes back up. [PR/524935: This issue
has been resolved.]
■ When M120 Type 1 FPCs are configured for 2:1 FPC:FEB mapping, and one of
the FPCs restarts, the restarting FPC might not initialize properly and might result
in a small percentage of packet loss for all interfaces on that FPC. As a
workaround, restart the FPC. [PR/529994: This issue has been resolved.]
■ When the clear interfaces statistics command is used, if a member link is
deactivated from an aggregate (AE or AS on any platform) and if the show
interfaces extensive command is used immediately, incorrect values (very high
values) might be seen for the counters such as Transmitted and Queued packets
under the Queue counters. If the clear interface statistics command is not issued
prior to deactivating the member link, this will not occur. [PR/530297: This issue
has been resolved.]
■ When any subscriber interface (PPPoE or DHCP) is used, the VPLS connections
go down. [PR/530435: This issue has been resolved.]
■ When Automatic Protection Switching (APS) is configured on a 4x STM-1 SDH,
SMIR PIC, the transmitted value of the K2 byte shows 0x00 for both unidirectional
and bidirectional instead of 0x04 and 0x05, respectively. [PR/531030: This issue
has been resolved.]
■ On MX960 routers, the link status stays in the "Link ok" state when the SCB is
removed without taking it offline through the CLI or switch. [PR/536860: This
■ On MX Series routers with 10.x Power Budget, after a “Power Budget: Chassis
experiencing power shortage” alarm occurs, the alarm does not clear even after
the power budget problem is cleared. [PR/540522: This issue has been resolved.]
■ When an ATM II interface is configured as a Layer 2 circuit with cell transport

mode on a router running JUNOS Release 8.2 or lower, interoperability issues
with other network equipment and another Juniper router running JUNOS Release
8.3 or higher may occur. [PR/255622: This issue has been resolved.]
■ The bpdu-block-on-edge configuration may not work properly when the interface
is configured as 'edge' at the [edit protocols vstp vlan vlan-id interface
interface-name] hierarchy level. [PR/522198: This issue has been resolved.]
■ A Spanning Tree Protocol triggered MAC flush might fail if there are frequent
topology changes with a significant number of MAC addresses learned. For
multiple Spanning Tree Protocols, restart l2cpd-services to come out of the state,
and for the Rapid Spanning Tree Protocol, reboot the corresponding DPC.
MPLS Applications
■ With BFD enabled over IGP and an RSVP session built across it, when the RSVP
peer does not support RSVP Hello (or is disabled), the BFD session down event
triggers only the IGP neighbor to go down. The RSVP session remains up until
a session timeout occurs. [PR/302921: This issue has been resolved.]
■ When a direct link between two PEs is disabled, the P2MP MPLS LSP may go
down with the CSPF error "bad strict route." [PR/500146: This issue has been
resolved.]
■ In cases where the secondary Routing Engine contains no label-switched path
up states due to lack of NSR support, such label-switched paths may not go to
the up state even after a switchover. [PR/501969: This issue has been resolved.]
■ The routing protocol process might crash with an assert in rsvp_PSB_set_selfID
while a graceful Routing Engine restart is performed when P2MP LSPs are present.
■ The name of the bypass label-switched path supports only 32 characters instead
of 64. [PR/515244: This issue has been resolved.]
■ A targeted LDP neighbor may remain up with an old IP address that was
previously in use with the loopback address on the remote neighbor. This may
occur when either of the following is performed on the remote neighbor:
■ A secondary loopback (lower than the current primary) address is added
and no primary keyword is associated with either of these addresses.
■ A second loopback address is added with the primary keyword.
This results in the targeted LDP neighbor being up with both IP addresses. The
neighbor with the old address may continue to remain up even after the old
loopback address is deleted on the remote neighbor. This neighborship with the
old address eventually times out when the router-id is changed to reflect the new
loopback address on the remote neighbor. [PR/518102: This issue has been
resolved.]
■ At adjust intervals, the maximum average bandwidth utilization for the LSP
should be reset to zero. MPLS sometimes fails to reset the maximum average
bandwidth utilization for the LSP to zero while performing a periodic
auto-bandwidth adjustment at the adjust interval. This prevents periodic
auto-bandwidth adjustment from adjusting to a lower bandwidth when the traffic
rate drops. [PR/528619: This issue has been resolved.]
■ The maximum average bandwidth utilization computed by MPLS for
auto-bandwidth might sometimes be higher than the actual traffic rate (twice
the traffic rate). This occurs when the MPLS statistics response from the Packet
Forwarding Engine comes in late, and two statistic entries for the same LSP fall
in the same MPLS auto-bandwidth averaging timer interval. [PR/536759: This
Network Management
■ After an LCC switchover, the SNMP process fails to send traps with resource
temporarily unavailable errors. [PR/493385: This issue has been resolved.]
■ Memory leaks might occur on the mib2d. [PR/517565: This issue has been
resolved.]
■ The SNMPD might crash when the filter-duplicate statement is used. [PR/519389:
■ SNMP might stop working after a router reboot, DPC/FPC/MPC restart, or a
graceful Routing Engine switchover. [PR/525002: This issue has been resolved.]
■ The SNMP MIB OID tree under dot3adAggPort fails. This issue might occur when
virtual LAN tagging is not configured on the AE interface, and if the mib2d process
is restarted using the restart mibprocess command. [PR/528555: This issue has
been resolved.]
■ The telnetd core file can be seen on routers enabled with telnet service.
■ On M7i routers, kernel panic might occur during route changes. [PR/439420:
■ If you configure an IP address with a larger subnet, for example, /19, on a

different interface first and the router begins to negotiate for the ARP of a specific
host on that interface and gets stuck in a hold state. If you later configure a more
specific subnet of /29 on another interface from where the host can be reached,
the forwarding table will still prefer the route with the hold entry via /19 instead
of the route with the ucst entry via /29. [PR/491468: This issue has been resolved.]
■ The Source Class Usage (SCU) statistics counter value might drop occasionally
when used with the accounting profile. [PR/493662: This issue has been resolved.]
■ The AE VLAN session classifier instantiation in a dynamic profile fails as the L2
classifier fails to install in the Packet Forwarding Engine. [PR/494488: This issue
has been resolved.]
■ On an MX Series router , an uRPF with more than 16 route paths can trigger a
jtree error and might cause the DPC to crash. [PR/509091: This issue has been
resolved.]
■ In a setup with two VPN routing and forwarding tables (VRFs) of a provider edge
connected to different customer edges and auto-export configured, when a ping
is executed from a customer edge to a provider edge interface in the other VRF
, the Internet Control Message Protocol reply returns the source interface IP of
the provider edge that is connected directly, instead of the interface IP of the
other VRF provider edge. [PR/510834: This issue has been resolved.]
■ Memory leaks might occur on the mib2d rtslib. [PR/510902: This issue has been
resolved.]
■ The VPN PIM neighborship over the mt- interfaces might not recover after a
graceful Routing Engine switchover. [PR/511366: This issue has been resolved.]
■ On tcpdump or monitor traffic interface for a lo0 interface with an IP address
having the last octet >= 224 (x.x.x.224 or higher) , the following message
displays: "inet class for 0xe1e11955 unknown." [PR/511911: This issue has been
resolved.]
■ Under rare conditions, the compressed system-generated routing protocol process
core files might be corrupted. As a workaround, disable the compression using
sysctl kern.compress_user_cores. [PR/513193: This issue has been resolved.]
■ Setting the TCP maximum segment size (MSS) might not change the actual MSS
value. [PR/514196: This issue has been resolved.]
■ On M120 and MX Series routers, when an AE interface (with LACP enabled) is
used as a core-facing interface for L3VPN, non-MPLS traffic received on the AE
interface can sometimes get black-holed. To recover from this state, deactivate
and reactivate the AE interface in the configuration. [PR/514278: This issue has
been resolved.]
■ When IGMP snooping is enabled, a multicast traffic drop might be seen if an
IGMP join or leave occurs on other interfaces. [PR/515420: This issue has been
resolved.]
■ When the primary link flaps with the route-memory-enhanced statement enabled,
jtree might get corrupted and traffic forwarding is affected. As a workaround,
deactivate the route-memory-enhanced statement under the chassis stanza.
Changes to the route-memory-enhanced statement take effect only when Packet
Forwarding Engine is rebooted. [PR/517919: This issue has been resolved.]
■ On some M Series, MX Series, and T Series routers, when a firewall filter is

applied on the egress of an aggregate interface, packet loss might occur after
adding, removing, or changing the service configuration on the egress side of
the aggregate interface. As a workaround, deactivate and reactivate the output
firewall filter on the aggregate interface. [PR/517992: This issue has been
resolved.]
■ Under certain conditions, traffic flow through an RLSQ bundle can be dropped
after it is removed and added back to a VPN routing and forwarding table (VRF).
■ When container AE interfaces are enabled on JUNOS Release 10.0 or 10.1, the
following message displays when one of the member links flap: “CHPJAR1-re0
fpc3 SCHED: %PFE-0: Thread 40 (PFE Manager) ran for 2015 ms without
yielding.” [PR/518714: This issue has been resolved.]
■ When the destination class usage (DCU) is configured with a unicast reverse-path
filter (uRPF) and egress forwarding-table filter within the VRF, a VPN route flap
might trigger a jtree memory leak. [PR/521609: This issue has been resolved.]
■ When a socket connection between the Routing Engine and the FPC is
reestablished, the FPC might run into a software crash because of an invalid
counter being referenced. There is no workaround. [PR/525357: This issue has
been resolved.]
■ On MX Series routers, repeated graceful Routing Engine switchover (GRES) under
certain configurations might result in kernel panics. Three kernel cores are
observed: with a soft update files system trace, with a TCP packet processing
stack trace, and with a trace of IFF configuration write. [PR/525583: This issue
has been resolved.]
■ On some routers, enabling IP-payload-based load balancing for MPLS packets
can cause some pseudowire packets to be reordered. [PR/528657: This issue
has been resolved.]
■ Asp_ifl_update messages might be seen on routers running JUNOS Release 10.0
and higher. Ignore these messages as they do not impact functionality.
■ A router might send raw IPv6 host-generated packets over the Ethernet towards
its BGP IPv6 peers. [PR/536336: This issue has been resolved.]
■ On some M Series, MX Series, and T Series routers, when a family CCC filter is
applied on multiple interfaces that belong to different L2VPN routing instances,
packet loss might occur after the routing instances are deactivated and
reactivated. As a workaround, deactivate and reactivate the CCC filter on the
interfaces. [PR/521357: This issue has been resolved.]
Routing Protocols
■ The backup Routing Engine might generate routing protocol process and kernel
cores if the BGP damping is configured along with nonstop active routing (NSR).
■ PIM asserts in dense groups can lead to a routing protocol process memory leak.
■ When a PIC with a PIM-enabled interface is brought online, the router might
send the first PIM hello slightly before the interface comes up. This causes the
router to drop the first PIM hello message towards its neighbor. [PR/482903:
■ The Juniper Networks rendezvous point (RP) does not process PIM Register
messages from a first-hop router in an IPv6 embedded RP group when the
Register message does not have the null-bit set. [PR/486902: This issue has been
resolved.]
■ When nonstop active routing (NSR) is running and BGP groups are added (eg a
VRF with a BGP in it), the routing protocol process might crash. As a workaround,
configure the new BGP groups after disabling the NSR. Then. reenable the NSR.
■ When l3vpn-composite-next-hop is configured, it should only be used by Layer
3 VPN routes. However, non-Layer 3 VPN routes are also able to use it.
■ After a graceful Routing Engine switchover (GRES) event with NSR enabled and
a scaled Layer 3 VPN eBGP test, some BGP sessions fail due to an expired
hold-down timer if the hold-down timer is lower than the default 30 seconds.
To avoid this issue, set the hold-down timer to the default value of 30 seconds.
■ When a family inet6 addressing is added to a router configured with multicast
VPN, the routing protocol process might crash and restart. [PR/503296: This
■ Upon a graceful Routing Engine switchover with NSR, the routing protocol process
will crash due to a wrong process for the PIM instance. [PR/503921: This issue
has been resolved.]
■ Nonstop routing (NSR) does not work correctly if an automatic route distinguisher
is used with a Layer 2 VPN routing-instance. [PR/513949: This issue has been
resolved.]
■ When multiple sham-links are configured with the same remote endpoint IP
address, a commit error occurs and configuration checkout fails. [PR/515343:
■ In route reflector and ASBR VPN scenarios, the routing protocol process might
crash as changes occur to a prefix in the primary table at the same time as BGP
tries to send out updates via the secondary table. [PR/515626: This issue has
been resolved.]
■ The mirror receive task variable might not be cleared when the routing protocol
process is heavily scaled. Hence, the NSR replication for RIP status stays in the
"InProgress" state forever. [PR/516003: This issue has been resolved.]
■ A warning message displays when the show igmp snooping interface command
is used with no IGMP snooping configured. [PR/516355: This issue has been
resolved.]
■ The configured robust count value is not applied on the non-querier router when
it receives a robust count value of 0. It uses the default value (2) instead of the
configured value. [PR/520252: This issue has been resolved.]
■ The new NSR master might not send the OSPF hello messages immediately after
a switchover. [PR/522036: This issue has been resolved.]
■ After a graceful restart, the forwarding state of both provider edge routers might
get stuck at the pruned state. However, traffic flow is not affected. [PR/522179:
■ Upon an NSR mastership switch or ISSU upgrade, the multicast resolve route for
IPv4 224/4 or inet6 ff00::/8 might be missing within the forwarding table. To
recover from this condition, deactivate and reactivate the protocol pim stanza,
or restart the routing protocol process. [PR/522605: This issue has been resolved.]
■ When an l2circuit ID greater than 2,147,483,647 is configured, and l2circuit
tracing is enabled using the set protocols l2circuit traceoptions command, some
of the trace messages provide the wrong value (a negative number) for the virtual
circuit ID. [PR/523492: This issue has been resolved.]
■ The tag_encoder is unable to handle attempts to stack EXPLICIT_V6_ NULL (label
2) over an existing stack with label 2 on top. Additionally, the BGP module does
not send label 2 when readvertising a prefix from an inet6 unicast session to a
inet6 labeled-unicast session. [PR/523824: This issue has been resolved.]
■ On MX80 routers, non IS-IS fragmented GRE packets are filtered before they are
forwarded to the Routing Engine. [PR/529727: This issue has been resolved.]
■ For JUNOS Release 9.5 and higher, the BGP parse community begins with “0”
as the octal value. This behavior is different in earlier releases. [PR/530086: This
■ The master routing protocol process crashes three minutes after a graceful Routing
Engine switchover. [PR/533363: This issue has been resolved.]
■ The Overload bit in the ISIS LSP MT-TLV might trigger IS-IS to install a default
route to the overload bit advertiser and the show isis database extensive
command might report an unknown TLV. [PR/533680: This issue has been
resolved.]
■ When the labeled-unicast inet6 route is reflected by route reflectors, the label
might be set to explicit-null. [PR/534150: This issue has been resolved.]
■ The routing protocol process might crash when a BGP connection attempt is met
with an RST from the peer. This is due to an unlikely race condition. [PR/540895:
■ For Adaptive Services II PICs, a temporary file might be created every 15 minutes
in the /var/log/flowc/ directory even if flow collector services is not configured.
The file is deleted if there are no clients, and re-created only when a client
connects and attempts to write to the file. [PR/75515: This issue has been
resolved.]
■ If the Juniper-Firewall-Attribute attribute in a RADIUS server configuration file
names a policer that sets a bandwidth limit for Layer 2 Tunneling Protocol (L2TP)
sessions but not an exclude-bandwidth limit, the bandwidth limit might not be
set correctly. [PR/254503: This issue has been resolved.]
■ On M Series routers (M120 and M320) with many service sets configured with
IDP policies, kernel messages are seen in the messages file once traffic passes
through these service sets. These messages stop when the traffic is stopped.
■ In JUNOS Release 10.0R2, a performance related issue is seen when the IDP
plug-in is enabled. The connection per second value for HTTP (64 bytes) with
AACL, AI, and IDP (with Recommended Attacks group) plug-ins have been
downgraded to 7,600 through 7,900 per second. [PR/476162: This issue has
been resolved.]
■ On an MS-PIC or MS-DPC running NAT functionality, the show services nat pool
detail command might erroneously display positive and negative number of ports
in use. [PR/506880: This issue has been resolved.]
■ On an MS-PIC or MS-DPC running NAT functionality, the NAT ports might not
be released correctly, resulting in the resources being permanently allocated
until a PIC or DPC restart is triggered. [PR/509847: This issue has been resolved.]
■ When a backup gateway is configured in any term under an IPsec stanza, for
any subsequent terms where this backup gateway is now configured as the
primary, IPsec tunnel establishment will fail. [PR/510608: This issue has been
resolved.]
■ The MS-PIC or MS-DPC might restart if a high rate of SIP and RTSP traffic is
processed within the Application Layer Gateways (ALGs). [PR/512909: This issue
has been resolved.]
■ NAT over FTP fails when it receives a SERVER 227 code string "Entering passive
mode" in lowercase. [PR/522029: This issue has been resolved.]
■ L2tpd asserts when short frames are sent. This causes the l2tpd to crash. As per
RFC 1661 and 1662, such packets should be treated as invalid and discarded.
■ When traffic is forwarded in an L2TP session and a teardown request is received,
the ASPIC crashes with a memory access violation in mlppp_output. [PR/537225:
■ BFD sessions and other protocol adjacencies configured with low hello or dead
timers over aggregate or IRB interfaces might flap upon configuration commit,
when the dhcp-local-server or dhcp-relay is used. [PR/507428: This issue has
been resolved.]
■ J-Web does not display the USB option under Maintain> Reboot> Reboot from
the media. [PR/464774: This issue has been resolved.]
■ If the time zone is set to “Europe/Berlin,” the command commit at "time-string"
will fail. [PR/483273: This issue has been resolved.]
■ If the user in the Backup Routing Engine with config-private mode activates
graceful Routing Engine switchover (GRES) and uses commit synchronize, a
synchronization error may occur during GRES switchover. [PR/486637: This
■ In configure private mode, activating or deactivating two consecutive nested
objects can cause a syntax error during commit. [PR/506677: This issue has
been resolved.]
■ The show log xxx | last x command behaves as if the screen length is set to 0,
and the --more xx%-- prompt does not appear. [PR/517023: This issue has been
resolved.]
■ On a router configured with a large number of interfaces, when a few interfaces
are constantly added and deleted, a minor memory leak may occur in the "pfed"
process. [PR/522346: This issue has been resolved.]
■ The group-inherited configuration under the [interface-range] hierarchy level does
not take effect. [PR/522872: This issue has been resolved.]
■ When | last is used with show commands, only the last line is displayed.
VPNs
■ While upgrading JUNOS Software with l2circuit configuration underthe logical

systems, the validation might fail with an "interface version mismatch" error.
You can ignore this error and upgrade the JUNOS Software using the no-validate
option. [PR/497190: This issue has been resolved.]
■ On an egress PE acting as the leaf of a spmsi p-tunnel, if the ingress PE withdraws
the unicast route towards the source, the routing protocol process crashes when
the c-mcast route is withdrawn. [PR/517183: This issue has been resolved.]
■ The routing protocol process crashes repeatedly on the new master, a few minutes
after a graceful Routing Engine switchover (GRES). [PR/527465: This issue has
been resolved.]
■ When a CE-facing interface in a VPLS instance is deactivated, the routing protocol
process might get stuck in a loop, leading to a high CPU utilization. [PR/531987:
Previous Releases
Release 10.0R3
The following issues have been resolved since JUNOS Release 10.0R3. The identifier
following the description is the tracking number in our bug database.
Class of Service
■ On the Qchip, the shaping accuracy is affected by the configured logical interface
shaping rate. [PR/79319: This issue has been resolved.]
■ The DHCP traffic may stop being processed for some subscribers under heavy
login and logout conditions when the 802.1 classifiers are in use. [PR/470513:
■ On a shared scheduler configuration with CoS configured, the rate-limit feature
may stop functioning on changing the scheduler transmit rate. [PR/483536: This
■ The following operations may result in large incorrect queue statistics on IQ2
interfaces:
■ When the IQ2 PIC is restarted, or the interface is deactivated and reactivated,
while traffic is on and the configuration defines a high priority queue on the
interface.
■ When the high priority queue number is changed under the class-of-service
configuration while traffic is on.

■ On M Series (except M120 and M320) routers, packet classification will not work
on aggregated Ethernet bundles that have LACP enabled. [PR/492057: This issue
has been resolved.]
■ The class-of-service process crashes on commit if a scheduler-map definition
does not have any forwarding-class statement. [PR/499755: This issue has been
resolved.]
■ The output firewall filter counter does not work when the firewall is configured
for discard next hop. [PR/404645: This issue has been resolved.]
■ Under certain conditions for prefix optimization, the firewall compiler may
discard a prefix configured for accept. This issue depends on the set of prefixes
configured to match across the various terms. [PR/486633: This issue has been
resolved.]
■ When the MS PIC used for an RLSQ interface resides on an E3 FPC (M320), traffic
might stop flowing across the RLSQ interface after the policer on the interface
is deactivated. [PR/498069: This issue has been resolved.]
■ When a filter group is configured on an interface residing on an ES FPC, the
rpf-check configured on that interface will not function correctly. As a
workaround, deactivate the configured filter group. [PR/503609: This issue has
been resolved.]
■ After configuring a three-color-policer, a dfwc core file is generated. [PR/509742:
High Availability
■ On an ISSU upgrade from JUNOS Release 9.3 to any of the current higher releases,
the ATM logical interfaces will flap. [PR/491511: This issue has been resolved.]
■ When the ATM scheduler map is programmed, the code does not check if the
early packet discard (EPD) configured on the forwarding class exceeds the
max_epd that the hardware supports. [PR/70336: This issue has been resolved.]
■ The following messages are displayed on both the primary and secondary RLSQ
MS 500 PICs: “SCHED: %PFE-0: Thread 7 ran for x ms without yielding",
"Scheduler Oinker." [PR/286357: This issue has been resolved.]
■ On M Series and MX Series routers, the ifHCInOctets retrieved by SNMP may
report an incorrect value. [PR/420985: This issue has been resolved.]
■ The show interfaces diagnostics optics command displays wrong diagnostic
information for the SumitomoElectric SFP with vendor part number
SCP6F44-J3-ANE. [PR/463837: This issue has been resolved.]
■ For AnnexB, the force command may not work as expected when loss of signal
is present. This is because the previous command did not complete for both the
protect and the working circuit, and priority comparison does not consider the
signal fail condition. [PR/465906: This issue has been resolved.]
■ Both the working and protect circuit are stuck in the “disabled” state when the
TX cable is unplugged and the RX cable is plugged for protect circuit after an
Automatic Protection Switching (APS) switchover. [PR/466649: This issue has
been resolved.]
■ On an M320 router, the 4x STM-1 1x STM-4 SFP PIC (PB-4OC3-1OC12-SON-SFP)
currently supports only two ports (0 and 2) when configured for eight queues
per port on an E3 FPC. [PR/475008: This issue has been resolved.]
■ SFPs are absent in the output of the show chassis hardware command following
TOXIC SFP messages. [PR/480828: This issue has been resolved.]
■ When a DPC restarts, a large amount of route (about 700,000 simple IPv4 routes)
remains in the forwarding table learned through another DPC. The sync process
between the Routing Engine and the Packet Forwarding Engine will take too
long, and the Routing Engine will restart the FPC. This repeats endlessly.
To restore the service and get the DPC out of the boot loop, restart the chassis
process or the routing process. [PR/481164: This issue has been resolved.]
■ In some cases during the periodic error status monitoring, error messages such
as “Wi seg ucode discards in fabric stream” might be displayed on adjacent
streams. These messages are cosmetic and can be ignored. [PR/481344: This
■ Under certain conditions, when aggregate interfaces are used and the member
links are located on more that one FPC, multicast traffic will not use one or more
of the aggregate child links. This can happen after an FPC reboot.
If the aggregate member links are located on the same FPC, this problem is not
triggered. To recover from this condition, deactivate and activate the aggregate
interface. [PR/484007: This issue has been resolved.]
■ The logical unit of a Gigabit Ethernet interface may show less than 1000 Mbps
of bandwidth even if there is no speed configuration under the physical interface.
As a workaround, manually set the bandwidth on the logical interface.
■ When loopback is configured on t3 under ct3, t1 under ct1, or e1 under ce1, no
error syslog message is logged. Additionally, the show interface extensive
command on the t3/t1/e1 displays "loopback" even though it is not actually
applied. [PR/486424: This issue has been resolved.]
■ On an M20 router with an LS PIC, the backup Routing Engine kernel may core
at rnh_index_alloc. [PR/486646: This issue has been resolved.]
■ Traffic may be sent out on a child link of an aggregated Ethernet (AE) bundle
even when it is not in the Collecting-Distributing Link Aggregation Control Protocol
(LACP) state if and only if the following conditions are met:
■ The remote end configured one link to be primary and another to be backup.
■ On the System Under Test (SUT), a unit of the AE bundle is disabled, then
enabled.
As a workaround, deactivate and activate the child link that is not in the
Collecting-Distributing LACP state. [PR/487786: This issue has been resolved.]
■ With GRES configured, a container interface (CI) configuration can trigger a
kernel core on the backup Routing Engine. [PR/488679: This issue has been
resolved.]
■ Container interfaces with ATM children with OAM may not initiate sending of
OAM cells after Automatic Protection Switching (APS) switchovers. [PR/489250:
■ Commit fails with IEEE 802.1p config when applied to container interfaces.
■ Kernel panic may occur if the child ATM interfaces are removed or disabled
under container. [PR/490196: This issue has been resolved.]
■ The system may not learn all MACs in the hardware within a second across the
fabric when trying to learn all new MACs at a 10–Gigabit line rate. A small fraction
will be learned via the software path, in the order of hundreds of seconds.
However, all MACs are learned eventually. [PR/489705: This issue has been
resolved.]
■ When filter-based forwarding is applied to the output interface and the egress
Packet Forwarding Engine (PFE) is different from the ingress PFE, the traffic gets
regular discards. [PR/490214: This issue has been resolved.]
■ During graceful Routing Engine switchover (GRES), if the peer's discovery state
is passive, the LFM state machine should be kickstarted even if the kernel state
is SEND_ANY, otherwise the peer will be stuck in PASSIVE_WAIT state. As a
workaround, configure both sides in the link-discovery mode as “active.”
■ On the IEEE 802.1ag CFM, when the loss threshold is configured to 256, it
displays a '0.' [PR/491422: This issue has been resolved.]
■ Whenever the system gets busy, the master Routing Engine might relinquish
mastership and take the line cards offline soon after. [PR/491583: This issue has
been resolved.]
■ The CI logical interface state may go out of sync when OAM is configured and
the logical interface flaps due to OAM. [PR/491866: This issue has been resolved.]
■ The chassis cell relay mode might not be set properly for CI interfaces.
■ The DPC remains in the ready state and the demux0 interface remains in a down
state after a chassisd restart without graceful Routing Engine switchover enabled.
■ When an SCB with an active plane is powered down, an HSL link error occurs
on unrelated SCBs. [PR/493151: This issue has been resolved.]
■ The CLI does not respond when Control+c is entered at the "more” separator.
■ The system may generate a core file when the DPC is removed before it is taken
offline. [PR/494625: This issue has been resolved.]
■ An outer virtual LAN tag is not added in a provider edge-customer edge link when
VPLS traffic arrives with an MPLS value of 2, 3, 4, or 5. However, VPLS traffic
with a value of 0, 1, 6, or 7 does not have this issue. [PR/495555: This issue has
been resolved.]
■ When ilmid uses a large amount of memory, the following error message displays:
“/kernel: Process (1702,ilmid) has exceeded 85% of RLIMIT_DATA: used 129084
KB Max 131072 KB.” [PR/495645: This issue has been resolved.]
■ The one-port OC12-3 PIC cannot support eight queues when the no-concatenate
option is configured. [PR/499452: This issue has been resolved.]
■ When an F4 OAM is enabled for a VPI and the encaps for a unit are changed
using that VPI and VCI to ATM-CCC cell rrelay, followed by the deletion of the
logical interface, the VPI list might be corrupted . Any subsequent change can
cause the system to crash. [PR/499479: This issue has been resolved.]
■ On a 4–port ChOC3/STM1 and 12–port T1/E1 circuit emulation PICs, the ATM
logical interface packets counter does not increment if the PIC is configured in
the ATM IMA mode. [PR/500153: This issue has been resolved.]
■ When t1-options are configured at the [edit interfaces ct1-x/y/z] hierarchy level,
some ct1 interfaces of a 10xCHT1 IQ PIC might flap when the configuration
changes are committed. As a workaround, remove the t1-options. [PR/500820:

■ On 40x1 Gigabit Ethernet PICs, very short fragments of fragmented TCP, UDP,
and ICMP packets may be incorrectly dropped with the diagnostic L4 length too
short. [501526: This issue has been resolved.]
■ The configured TTL set for GRE traffic is set properly for locally generated Routing
Engine packets, but is not set properly for transit packets. [PR/502087: This issue
has been resolved.]
■ In JUNOS Release 10.0, if the MX-MPCs power up while the A-DPCs are offline,
and if ISSU is performed, the MPCs will crash. [PR/502837: This issue has been
resolved.]
■ When an ATM AIS cell is received from the virtual channel under vlan-vci-ccc
encapsulation, the logical interface will be incorrectly marked down. There is no
workaround. [PR/503653: This issue has been resolved.]
■ The yellow marking for the three-color-policers is incorrect. Even after the excess
burst buffer is full, the yellow counters continue to increment at the same rate
as the green buffers. [PR/504192: This issue has been resolved.]
■ Under certain circumstances, the E3 IQ PIC might report bogus CCV, CES, and
CSES alarms. [PR/505921: This issue has been resolved.]
■ The show interfaces diagnostics optics interface command does not display the
unit of measurement when the received power is in a very low range (power <
5e-10). It shows the value of 0.00 without any unit of measurement. [PR/507653:
■ On MX Series routers, the chassisd crashes when the SCB is taken offline and
removed. [PR/510950: This issue has been resolved.]
been resolved.]
■ Under certain circumstances, the chassisd process might crash on a backup
Routing Engine while a configuration is commited. [PR/512044: This issue has
been resolved.]
■ On an MX Series router, the DHCP ACK messages are dropped when a client
Rebind request is processed by a different DHCP server. This issue may occur
in an environment where the provider has multiple DHCP servers for redundancy
purposes. [PR/487138: This issue has been resolved.]
■ The family ISO MTU configured explicitly under the IRB interface logical unit will
decrement by three if you change the interface MTU on the interface that belongs
to the same bridge domain. [PR/493209: This issue has been resolved.]
■ In JUNOS Release 10.0, the MX 960 router displays the following i2c messages
related to the fan:
rocky-re0 /kernel: PCF8584(WR): target ack failure on byte 0

rocky-re0 /kernel: PCF8584(WR): (i2c_s1=0x08, group=0xe, device=0x54)
This is a cosmetic issue and has no impact on the router. [PR/500824: This issue
has been resolved.]
Network Management
■ Under certain SNMP conditions, the following log message is displayed:
M10i-RE0 pfed: PFED_NOTIF_GLOBAL_STAT_UNKNOWN: Unknown global

notification stat: transit options/ttl-exceeded (re-injected)
M10i-RE0 pfed: PFED_NOTIF_STAT_UNKNOWN: Unknown notification type stat:
Unknown
This log message might also be displayed during the installation of AI Scripts
(version 2.1R2 or above) on the router. AI Scripts versions prior to 2.1R2 do not
cause these messages. This is a cosmetic message, and does not have any impact.
■ When monitor traffic matching x is used on RLSQ bundles, no outbound packets
are displayed. [PR/468959: This issue has been resolved.]
■ The SNMP MIB walk on jnxFWCounterDisplayName may miss certain policer
counters of firewall filters applied with respect to logical interfaces (subinterfaces).
■ Under certain conditions, the SNMPD crashes due to a BAD_PAGE_FAULT.
MPLS Applications
■ No point-to-multipoint LSPs are reported when the show mpls lsp p2mp command
is issued. As a workaround, execute the show mpls lsp command before you
execute the show mpls lsp p2mp command. [PR/266343: This issue has been
resolved.]
■ Constrained Shortest Path First (CSPF) fails to calculate a P2MP LSP reroute path
merging upon a user configuration change. [PR/454692: This issue has been
resolved.]
■ When an RSVP LSP is configured with the no-install-to-address option and is not
associated with CCC connection flaps, the routing protocol process will crash
when the LSP comes up again. To avoid the problem, make sure that the LSP is
either a transmit LSP for a CCC connection or that the install option is also
configured on the LSP. [PR/471339: This issue has been resolved.]
■ A traffic engineered label-switched path that is down might not get re-signaled.
■ While performing an MPLS LDP traceroute in a tunneled MPLS LDP environment,
all hops except the second hop show 127.0.0.1 as the router hop. [PR/486999:
■ The NGEN-MVPN multicast traffic might be dropped at the ingress router if a

point-to-multipoint LSP reoptimization is performed. [PR/491533: This issue has
been resolved.]
■ A rare condition between the MVPN and RSVP P2MP signaling leads to the
creation of stale flood next hops. [PR/491586: This issue has been resolved.]
■ Under some circumstances where LDP is enabled, a memory leak might occur
where the routing protocol process does not free up memory. [PR/493885: This
■ An incorrectly changed LDP session authentication key causes the LDP session
to fail, and the LDP/IGP syncronization feature stops working. The IGP continues
to advertise the link at normal metric values. [PR/499226: This issue has been
resolved.]
■ LDP might not handle certain error conditions gracefully when NSR is enabled.
This might cause the LDP replication state to be stuck in the "In Progress" state
forever. [PR/505043: This issue has been resolved.]
■ The show route table mpls.0 label-switched-path lspname command may cause
the routing protocol process to core if no route is found. [PR/507239: This issue
has been resolved.]
■ The output of the show route forwarding-table family vpls multicast command may
display an unexpected output such as “rtinfo” with the multicast knob because
this knob is supported only with inet and inet6 families and is not supported for
the ISO, NTP, MPLS, UNIX, and VPLS families. The output of this command will
be fixed in JUNOS 10.1R1 to display the message: “Multicasting is not supported
by UNIX, ISO, NTP, MPLS, and VPLS protocols.” [PR/235712: This issue has been
resolved.]
■ When certain FPCs (T1600-FPC4-ES, T640-FPC4-1P-ES, T640-FPC1-ES,
T640-FPC2-ES, and T640-FPC3-ES) receive corrupted cells via high-speed links,
they might unnecessarily reboot and report the following system log error
message: "Unrecoverable Error: Flist gtop bit toggled !." No reset is needed to
recover from this condition. [PR/441844: This issue has been resolved.]
■ When the strict-high priority queue is overloaded, the high priority queue may
starve, resulting in the loss of high priority traffic. [PR/455152: This issue has
been resolved.]
■ When the flow monitoring version 9 feature is enabled on an MS PIC (or service
PIC which supports flow monitoring version 9), the MS PIC may crash upon
receiving certain corrupted IPv6 packets. [PR/458361: This issue has been
resolved.]
■ Reading the list of boot devices from the BIOS may fail once in hundreds or
thousands of times due to an improper locking mechanism. [PR/461320: This
■ After upgrading from JUNOS Release 9.3 to Release 9.5, the timestamps in the
log files show the UTC time instead of the local time corresponding to the
specified time zone. [PR/469175: This issue has been resolved.]
■ On T640 and TX Series routers which have outgoing interface on a GFPC , the
interface might report LSIF errors or cell mismatched errors after it receives an
IPv6 packet with an invalid payload. The interface still accepts traffic, but discards
all outgoing packets. To recover, reboot the FPC on T640 and TX Series routers.
But if the IPv6 packets of the invalid payload are still transmitted, the problem
will occur again. [PR/470219: This issue has been resolved.]
■ When an aggregated SONET with a Cisco High-Level Data Link Control (HDLC)
encapsulation is configured, a member link may not be marked as linkdown in
the Packet Forwarding Engine if the remote end of the link is disabled.
■ The output of the show arp command does not show the entire demux interface
identifier, making it difficult to determine with which specific demux subinterface
a given ARP entry is associated. [PR/482008: This issue has been resolved.]
■ If a duplicate IPv6 address is configured, every ICMP6 packet received (icmp
request, icmp neighbor solicitation, or icmp neighbor advertisement) will trigger
an mbuf leak. Such a duplicate address configuration might not get noticed at
the VRRP backup router which is not used for data forwarding. Correcting the
configuration and deactivating or activating the interface will stop the mbuf leak.
■ The fxp0 packet counter statistics are inconsistent between the physical interface
and the logical interface as the statistics are updated twice. [PR/486200: This
■ Jtree corruption may be observed when the DCU is configured on ES-FPCs.
■ A problem occurs on an M120 router with an FEB redundancy configuration
when the backup FEB is protecting a non-primary FEB. In this case, the Routing
Engine will prompt the incorrect Packet Forwarding Engine for status, causing
delays in the SNMP responses. [PR/490172: This issue has been resolved.]
■ An issue occurs when one or more multicast routes (i.e., one or more <S,G>
s) have received joins over an AE interface represented by two (or more) AE legs
on separate Packet Forwarding Engines. In a Packet Forwarding Engine ASIC
forwarding, the next hop shared by these multicast routes contains a list
representing the two (or more) Packet Forwarding Engines. When this next hop
list is no longer referenced by any active multicast route, it is not correctly freed
and remains stranded in the Packet Forwarding Engine ASIC memory. This issue
does not occur when the AE legs are all on the same Packet Forwarding Engine.
■ Due to excessive logging at the FPC, the E3 FPC Type 3 core dumps multiple
times. [PR/494534: This issue has been resolved.]
■ In certain cases, a configuration change can cause the backup Routing Engine
to reboot. [PR/497290: This issue has been resolved.]
■ On T Series routers with ES-FPCs, removing or adding flow-tap filters may trigger
an FPC reboot. However, the other FPC types in the same system are not affected.
■ When a next-hop chain has multiple types of next-hop dependencies, including
indirect next-hop, aggregate next-hop, and multiple unicast next-hops, during
an aggregate link flap (down/up), a certain sequence of events from the kernel
is expected by the Packet Forwarding Engine for the next-hop change and delete
updates. However, during a quick link flap (down/up), in an extreme corner case,
the Packet Forwarding Engine does not receive the expected sequence, and the
FPC will crash. [PR/499315: This issue has been resolved.]
■ On IQ2 PICs, when copy-plp is enabled under class of service, the DCU provides
the wrong statistics. [PR/499378: This issue has been resolved.]
■ The L2RW does not report an error when the required L2_pgm length is longer
than what the hardware can support. [PR/501318: This issue has been resolved.]
■ On an ichip platform, when the downstream multicast member link flaps, the
Packet Forwarding Engine rarely has a chance to fail multicast next-hop handling.
This can cause multicast traffic drops. [PR/501852: This issue has been resolved.]
■ On a TX Matrix Plus router, if one of the two external RJ–45 links between a
TXP-CIP and an LCC Control Board is broken, the router does not generate an
alarm. [PR/508219: This issue has been resolved.]
■ On M120 and MX Series routers when AE interface (with LACP enabled) is used
as a core facing interface for L3VPN, the non-MPLS traffic received on the AE
interface can sometimes get black holed. To recover from this state, deactivate
and activate the AE interface in configuration. [PR/514278: This issue has been
resolved.]
Routing Protocols
■ If a static route is pointing to a discard configuration, a failure might occur when

the router attempts to collect the multicast statistic data. [PR/434298: This issue
has been resolved.]
■ Deleting a logical system causes the routing protocol process to be stuck in an
infinite loop. [PR/439000: This issue has been resolved.]
■ The routing protocol process periodically dumps core due to a failed soft assertion:
"rt_notbest_sanity: Path selection failure" in rt_table.c. [PR/451021: This issue
has been resolved.]
■ If the routing protocol process (rpd) experiences a restart, it may not receive the
first PIM hello packet from a PIM neighbor after the restart. This may delay the
establishment of PIM neighbors, and therefore multicast traffic convergence, for
up to twice the PIM hello interval. [PR/452751: This issue has been resolved.]
■ When the last CE interface in a VPLS instance goes down, pseudowires in the
VPLS instance are also removed. However, the multicast snooping process does
not remove the logical interface indices corresponding to these pseudowires
from the OIF list of the default bd, mg, vlan routes. This leaves the multicast
snooping routes in an inconsistent state.
When a CE interface comes up again, new pseudowire comes up and OIF list
for the default bd, mg, vlan route is updated by the multicast snooping process.
The kernel finds a stale iflindex for the old pseudowire in the OIF list and rejects
the next-hop add. This problem persists until the multicast snooping process is
restarted. [PR/467347: This issue has been resolved.]
■ If a router modifies the next-hop protocol to self (for example, using an export
policy with next-hop-self) on a peer group containing "internal" peers, and
nonstop routing is configured on the router, the routing protocol process may
send duplicate updates to the peers in this peer group during a Routing Engine
switchover. [PR/468505: This issue has been resolved.]
■ When running PIM and a link flap occurs, the routing protocol process might
crash. [PR/480422: This issue has been resolved.]
■ When a PIC with a PIM-enabled interface is brought online, the router might
send the first PIM hello slightly before the interface comes up. This causes the
router to drop the first PIM hello message to its neighbor. [PR/482903: This issue
has been resolved.]
■ Whenever a graceful Routing Engine switchover (GRES) is performed, the BMP
header for the consequent updates may become corrupted until the BMP session
is deactivated and activated. [PR/486068: This issue has been resolved.]
■ The output of the show igmp interfaces command might display the configured
IGMP query-interval value incorrectly in the output. [PR/488146: This issue has
been resolved.]
■ In some conditions where the next-hop information must be merged for a new
configuration, some next-hop information does not merge correctly, causing the
routing protocol process to crash. [PR/489220: This issue has been resolved.]
■ The routing protocol process may core frequently because of malformed BGP
updates generated by the JUNOS Software. This might be because of the total
length and the path attribute length. [PR/489891: This issue has been resolved.]
■ When multicast RPF routes are configured, the show route rib-groups command
causes the routing protocol process (RPD) to go into an infinite loop. [PR/490390:
■ The MPLS LSPs are not advertised as links into the non-backbone OSPF areas,
even though they are configured to be advertised. [PR/491692: This issue has
been resolved.]
■ The PIM running in the main instance might stop working if the PIM is configured
in a no-forwarding routing instance. [PR/492017: This issue has been resolved.]
■ If there are enough routing instances with PIM configured, and there is enough
IGMP/MLD join state present and a configuration change is made, a routing
protocol process scheduler slip might occur. [PR/493062: This issue has been
resolved.]
■ On an unnumbered Ethernet interface in P2P mode, OSPF does not skip
validation of the network mask received in the hello packets. This could result
in a failure to bring up an adjacency on such interfaces while interoperating with
other vendors. As a workaround, convert the interface to a regular numbered
interface on both sides. [PR/493206: This issue has been resolved.]
■ In a NSR configuration, the backup Routing Engine can lose the connection to
the active Routing Engine during configuration commit. The problem occurs
more often when the configuration includes a large number of routing instances.
This is caused by the routing protocol process on the backup Routing Engine
leaking file descriptors during commit synchronization. To recover, restart the
routing protocol process on the backup Routing Engine. [PR/506883: This issue
has been resolved.]
■ When the routing-instances routing-instances-name routing-options multipath
vpn-unequal-cost equal-external-internal statement is configured, some VPN routes
learned from different route reflectors can be shown as multipath. [PR/507236:

■ The routing protocol process might crash if the router receives a flow route with
a rate-limit bandwidth is less than 1000 bps. [PR/508715: This issue has been
resolved.]
■ In route reflector and ASBR VPN scenarios, the routing protocol process might
crash when changes occur to a prefix in the primary table at the same time as
BGP tries to send out updates via the secondary table. [PR/515626: This issue
has been resolved.]

■ A static route pointing to a destination is incorrectly added for a source NAT
when a next-hop type service set is used. [PR/476165: This issue has been
resolved.]
■ When an SIP ALG is enabled on ASPIC, MSPIC, or MSDPC, the PIC could crash
while freeing the Via header NAT port. [PR/490329: This issue has been resolved.]
■ MSDPC might crash while running a combination of SIP and other ALGs due to
a possible double freeing of memory. [PR/491218: This issue has been resolved.]
■ In some call scenarios, the SIP ALG on a services PIC can cause NAT port leaks.
■ The show services nat pool name CLI filter does not have any effect. [PR/493820:
■ Under certain conditions, the replication socket between two Routing Engines
for the local policy decision function process (LPDFD) does not close properly.
This results in high CPU consumption by the LPDFD. As a workaround, restart
the local policy decision function process (LPDFD) on the master Routing Engine’s
restart local-policy-decision-function. [PR/495363: This issue has been resolved.]
■ Configuring different autonomous system types (origin and peer) toward two v5
servers does not work and origin is taken as the autonomous system type for
both flow servers. [PR/496954: This issue has been resolved.]
■ Following a JUNOS Software upgrade, the L2TP on an M7i router dumps core.
■ When the router reboots after an upgrade, the following commit error occurs:
“Cannot configure local-dump without configuring file name in neither
traceoptions nor output.” [PR/500365: This issue has been resolved.]
■ When a backup gateway is configured in any term under IPsec stanza, for any
subsequent terms where this backup gateway is now configured as the primary,
IPsec tunnel establishment will fail. [PR/510608: This issue has been resolved.]
■ When using a NAT DCE RPC ALG on a services PIC, the PIC might crash while
processing the binding request. [PR/510997: This issue has been resolved.]
■ The wildcard apply groups do not work properly in JUNOS Release 9.1 and above.
■ When jcs:syslog() is used in an event script, messages do not appear until another
system application sends a syslog message. [PR/449778: This issue has been
resolved.]
■ The core files cannot be removed using the file delete command unless the
Routing Engine name is included in the path. [PR/469168: This issue has been
resolved.]
■ The deactivate configuration statement cannot be blocked through the
deny-configuration statement. [PR/488352: This issue has been resolved.]
■ When commit scripts are used and the configuration contains a policy which
uses an apply-group with a then action of “then community + EXPORT,” the
commit fails. [PR/501876: This issue has been resolved.]
■ The load replace command does not consider the allow-configuration
configuration. [PR/501992: This issue has been resolved.]
■ On M10i, M120, M320, and MX Series routers with dual Routing Engines running
JUNOS Release 9.4 or later, the dfwd process running on the backup Routing
Engine might access the /var/pdb/rdm.taf file every 30 seconds, causing excessive
writes to the hard disk drive. This problem does not occur when GRES is enabled.
VPNs
■ Configuring a forwarding-cache threshold under a routing instance for NG-MVPN

might not produce the expected behavior and might not limit the number of
forwarding cache entries. [PR/438164: This issue has been resolved.]
■ In an MLAN scenario where two PEs are connected to the multicast receiver,
when the PE acting as the designated router (DR) has a link failure on the MLAN,
the backup PE that becomes the DR is unable to forward traffic. [PR/490153:
■ When different prefixes are advertised to the same source by different PE routers,
an egress PE router is prevented from picking the lower prefix route for RPF
when the PR advertising the higher prefix loses its route to the source.
■ When multipath is enabled in a routing instance with NG MVPN, the traffic might
get dropped on the receiver PE. [PR/508090: This issue has been resolved.]
Release 10.0R2
The following issues have been resolved since JUNOS Release 10.0R2. The identifier
Class of Service
■ The structure of inter-component data traffic is changed for the MX Series XDPC.
This change increases the inter-component traffic rate and causes performance
problems typically at 10x1G XDPC. Each component has enough headroom to
handle increased traffic. However, actual performance is restricted to meet
optimal performance. This problem occurs because this performance restriction
value is not increased after increasing the inter-component data rate. [PR/469135:
■ Using the IPv4 template to collect NetFlow version 9 statistics on the ingress
L3VPN PE devices may result in the BGP IP next-hop address not being included
in the report. [PR/467403: This issue has been resolved.]
■ Some ranges of burst sizes may result in unexpected packet drops when the
traffic rates are close to the policing rate. Increase the burst size to resolve this
problem. [PR/478659: This issue has been resolved.]
■ Under certain circumstances, after a GRES switchover, the new master Routing
Engine sends an invalid LACP frame. As a result, the aggregated interface fails.
■ When the show interfaces extensive command is used, some interfaces may not
display the correct value for the Oversized Frames counter. [PR/437176: This
■ When configured for WAN-PHY framing, the ports on the 4-port 10–Gigabit
Ethernet PIC (SAUZA) always report zero for path-level errors (BIP-B3) in the
output of the show interfaces extensive command.
After the fix, the BIP-B3 counter increments when path-level errors occur.
However, this counter is an approximation and not an accurate accounting of
the path-level errors that actually occur on the link. [PR/447653: This issue has
been resolved.]
■ On an MX960 router, when more than eight Dense Port Concentrators (DPCs)
(including unconfigured DPCs) are loaded, the output of the show interface
extensive command can be very slow if the source class usage/destination class
usage (SCU/DCU) is configured for some units. [PR/449034: This issue has been
resolved.]
■ Interrupts that occur from links (non-zero) that are not configured or enabled in
the PIC due to a hardware issue in the DFPGA causes syslog to overload and
eventually leads the FPC to core. [PR/455877: This issue has been resolved.]
■ The master Routing Engine fails to establish a connection with the backup Routing
Engine due to an autonegotiation issue with the em1 interface. [PR/461469: This
■ For AnnexB, the force command may not work as expected when loss of signal
is present. This is because the previous command does not complete for both
the protect and the working circuit, and priority comparison does not consider
the signal fail condition. [PR/465906: This issue has been resolved.]
■ Both the working and protect circuit were stuck in the “disabled” state when the
TX cable was unplugged and RX cable was plugged for protect circuit after an
Automatic Protection Switching (APS) switchover. [PR/466649: This issue has
been resolved.]
■ When an untagged aggregated Ethernet interface is configured with LACP and
GE IQ2 PICs as the child interface, the input packet count might be constantly
decremented to zero when no data packets arrive on the interface. The decrease
in packet count is equal to the incoming LACP packet count. [PR/471177: This
■ With a default configuration, when a Tri-Rate copper small form-factor pluggable
transceiver (SFP) installed in a DPCE-R-20GE-2XGE board is replaced with an
SFP-LX/SFP-SX, the link stays down. Activate and deactivate the SFP to restore
the link. [PR/473127: This issue has been resolved.]
■ On JUNOS trio chipset platforms, forwarding table filter (FTF) is not supported
for family VPLS. [PR/476611: This issue has been resolved.]
■ On a 4x CHOC3 SONET CE SFP PIC and 12x T1/E1 CE PIC, if a T1 or E1 interface
is deleted and re-created, the t1 or e1 interface that is connected to the 4x CHOC3
SONET CE SFP PIC or 12x T1/E1 CE PIC will observe framing error and traffic
halts.
As a workaround, after the T1 or E1 interface is deleted and re-created on the
4x CHOC3 SONET CE SFP PIC or 12x T1/E1 CE PIC, deactivate and activate the
e1 interface's encapsulation. This deactivate/activate will make the framing errors
disappear. [PR/482491: This issue has been resolved.]
■ The show aps group group-name commands do not work for container group
names. [PR/483440: This issue has been resolved.]
■ Under certain conditions, when aggregate interfaces are used, and the member
links are located on more that one FPC, multicast traffic will not use one or more
of the aggregate child links. This can happen after an FPC reboot.
If the aggregate member links are located on the same FPC, this problem is not
triggered. To recover from this condition, deactivate and activate the aggregate
■ Traffic may be sent out on a child link of an Aggregated Ethernet (AE) bundle
even when it is not in the Collecting-Distributing Link Aggregation Control
Protocols (LACP) state if and only if the following conditions are met:
■ The remote end configured one link to be primary and other to be backup
■ On the System Under Test (SUT), a unit of the AE bundle is disabled then
subsequently enabled.
As a workaround, deactivate and activate the child link which is not in the
Collecting-Disturbing LACP state. [PR/487786: This issue has been resolved.]
■ With GRES configured, a container interface (CI) configuration can trigger a
kernel core on the backup Routing Engine. [PR/488679: This issue has been
resolved.]
■ Container interfaces with ATM children with OAM may not initiate sending of
OAM cells after Automatic Protection Switching (APS) switchovers. [PR/489250:
■ Commit fails with IEEE 802.1p config when applied to container interfaces.
■ Kernel panic may occur if the child ATM interfaces are removed or disabled
under the container. [PR/490196: This issue has been resolved.]
■ The CI logical interface state may go out of sync when OAM is configured and
the logical interface flaps due to OAM. [PR/491866: This issue has been resolved.]
■ The chassis cell relay mode might not be set properly for CI interfaces.
■ In a combo DPC, the physical link stays up when an interface with the SFP-T is
disabled. However, port 0 of the combo DPC is not impacted by this issue.
MPLS Applications
■ Constrained Shortest Path First (CSPF) fails to calculate a P2MP LSP reroute path
merging upon user configuration change. [PR/454692: This issue has been
resolved.]
■ When a large number (more than 100) of NGEN-MVPN P2MP LSPs based on an
LSP template are active, the routing protocol process might crash if the LSP
template is deleted and added back. [PR/477376: This issue has been resolved.]
Network Management
■ A problem with the IPv6 n2m add routine causes the mib2d to fail at the
vlogging_event. [PR/472453: This issue has been resolved.]
■ The SNMP MIB walk on jnxFWCounterDisplayName may miss certain policer
counters of firewall filters applied with respect to logical interfaces (subinterfaces).
■ Under some circumstances, the interface process (physical interface) may

interfere with the operation of an LSI interface. [PR/102431: This issue has been
resolved.]
■ When certain FPCs (T1600-FPC4-ES, T640-FPC4-1P-ES, T640-FPC1-ES,
T640-FPC2-ES, and T640-FPC3-ES) receive corrupted cells via high-speed links,
they might unnecessarily reboot and report the following system log error
message: "Unrecoverable Error: Flist gtop bit toggled !." No reset is needed to
recover from this condition. [PR/441844: This issue has been resolved.]
■ On M Series routers, if you disable and enable IPv6 on an interface, routing on
that interface will no longer work. [PR/459781: This issue has been resolved.]
■ An FPC may stop forwarding traffic when an aggregate interface flaps and the
router uses per-prefix load balancing (default configuration) for some prefixes.
A more likely scenario under which this issue can occur is when an aggregate
interface is configured with just a single link (that flaps), and per-prefix load
balancing is used.
As a workaround, use load balancing per-packet policy for all prefixes (per-flow
load balancing) and/or do not have aggregate interfaces flap. [PR/477326: This
■ With JUNOS Release 9.3 or later, configuring policer or SCU/DCU on interfaces
belonging to FPC-ES may cause memory corruption which leads to either traffic
lost or FPC to restart unexpectedly. [PR/481185: This issue has been resolved.]
Routing Protocols
■ The BGP strip confederation logic does not include the number of memory
segments to check which leads to it running on random data, causing the routing
protocol process (RPD) to core. [PR/465624: This issue has been resolved.]
■ When nonstop routing is configured on the router, the routing protocol process
may restart with a core dump. [PR/472701: This issue has been resolved.]
■ When the routing protocol process (rpd) fails after an rpd restart, the daemon
may be unable to install new LSI logical interfaces. The following error is returned:
ENOMEM. [PR/473774: This issue has been resolved.]
■ During an ISSU upgrade, the BGP session might flap due to differences in the
negotiation of keepalive messages between versions. [PR/476285: This issue has
been resolved.]
■ After a mastership switchover, incorrect BFD packets may be sent out due to
stale information within the ppmd. This may result in the BFD sessions flapping
repeatedly. [PR/478447: This issue has been resolved.]
■ Under certain circumstances, Juniper Networks PIM implementation might send
(S,G,rpt) prune message towards RP too early after receiving the (S,G,rpt) prune
message from a downstream router. [PR/478589: This issue has been resolved.]
■ The routing protocol process (RPD) CPU usage may be high if both BGP multipath
and family inet-mpvn are configured under BGP. [PR/479574: This issue has
been resolved.]
■ If multipath is enabled between two AS boundary routers running InterAS Option
B, and there are multiple external neighbors advertising a VPN prefix on provider
edge (PE) routers, when the routing protocol process (RPD) generates new routes
BGP will generate a different label from the VPN prefix that was previously
advertised to the peers that are part of the AS. [PR/479754: This issue has been
resolved.]
■ The MVPN c-multicast traffic is duplicated onto the LAN segment as the interface
mismatch is not processed within the PIM. Interface mismatch is needed to
trigger an assert to prevent traffic duplication. As a workaround, configure PIM
under the main instance. [PR/481467: This issue has been resolved.]
■ The routing protocol process may core frequently because of malformed BGP
updates generated by the JUNOS Software. This could be because of the total
length and the path attribute length. [PR/489891: This issue has been resolved.]
■ The service DPCs may crash during conversation timeout cleanup for the
DCE-RPC. [PR/475436: This issue has been resolved.]
■ When a malformed RTSP packet not conforming to an RTSP RFC syntax is
processed by the RTSP Application Layer Gateway (ALG ) within the Service PIC
(or Service DPC), the PIC might core. [PR/476321: This issue has been resolved.]
■ Via header translation may be incorrectly performed by the SIP ALG when it
contains only an IP address and no port. [PR/482998: This issue has been
resolved.]
■ The SIP ALG does not translate the route header properly, which leads to the SIP
calls being dropped after 20 seconds. [PR/483014: This issue has been resolved.]
■ The SIP parser may drop 200 “OK for REGISTER” messages if the contact has
multiple entries. [PR/483030: This issue has been resolved.]
■ When the get-configuration or load-configuration commands are run using

JUNOScript, these events are not recorded in the system log. [PR/64544: This
VPNs
■ On an MX960 router, the VPLS instance may not learn the remote CE MAC
address when the clear vpls mac-address command is used. [PR/476020: This
■ P2MP LSP cannot be recovered when the P router (which is also configured as
the BGP reflector) goes down. [PR/481441: This issue has been resolved.]
■ In an MLAN scenario where two PEs are connected to the multicast receiver,
when the PE acting as the designated router (DR) has a link failure on the MLAN,
the backup PE which becomes the DR is unable to forward traffic. [PR/490153:
Release 10.0 R1
The following issues have been resolved since JUNOS Release 9.6 R4. The identifier
Class of Service
■ On the Qchip, the shaping accuracy is affected by the configured logical interface
shaping rate. [PR/79319: This issue has been resolved.]
■ DHCP traffic might stop being processed for some subscribers under heavy login
and logout conditions when the 802.1 classifiers are in use. [PR/470513: This
■ The following operations might result in large incorrect queue statistics on IQ2
interfaces:
■ When the IQ2 PIC is restarted, or the interface is deactivated and reactivated,
while traffic is on and the configuration defines a high priority queue on the
interface.
■ When the high priority queue number is changed under the class-of-service
configuration while traffic is on.

■ On M Series (except M120 and M320) routers, packet classification will not work
on aggregated Ethernet bundles that have LACP enabled. [PR/492057: This issue
has been resolved.]
■ The class-of-service process crashes on commit if a scheduler-map definition
does not have any forwarding-class statement. [PR/499755: This issue has been
resolved.]
■ On an Ichip-based platform for strict high priority queue (SHQ), the buffer size
allocated by the Packet Forwarding Engine is capped by the tx-rate. If the tx-rate
is configured to a very small value or is not configured, and is automatically
allotted a zero or a very small remaining value; the queue is also allotted a
proportionately small delay buffer. This can sometimes lead to Red and Tail
drops on the SHQ when there is a burst of traffic (with a certain traffic pattern)
on it. As a workaround, configure a nominal tx-rate value (5 percent) for the
SHQ. [PR/509513: This issue has been resolved.]
■ Under certain conditions for prefix optimization, the firewall compiler might
discard a prefix configured for accept. This issue depends on the set of prefixes
configured to match across the various terms. [PR/486633: This issue has been
resolved.]
■ A JUNOS Software compiler bug in the match combination optimization could
cause an incorrect firewall filter evaluation. [PR/493356: This issue has been
resolved.]
■ When the MS PIC used for an RLSQ interface resides on an E3 FPC (M320), traffic
might stop flowing across the RLSQ interface after the policer on the interface
is deactivated. [PR/498069: This issue has been resolved.]
■ When a Layer 2 policer is configured under a logical interface having multiple
families configured under it, and the policer is changed to another, the newly
configured policer might not take effect unless the policer configuration is
deactivated and activated. [PR/501726: This issue has been resolved.]
■ When a filter group is configured on an interface residing on an ES FPC, the
rpf-check configured on that interface will not function correctly. As a
workaround, deactivate the configured filter group. [PR/503609: This issue has
been resolved.]
■ After configuring a three-color-policer, a dfwc core file is generated. [PR/509742:
High Availability
■ On an ISSU upgrade from JUNOS Release 9.3 to any of the current higher releases,
the ATM logical interfaces will flap. [PR/491511: This issue has been resolved.]
■ Configuration of duplicate virtual-ip addresses is not allowed across routing

instances and logical systems. [PR/402235: This issue has been resolved.]
■ On M Series and MX Series routers, the ifHCInOctets retrieved by SNMP might
report an incorrect value. [PR/420985: This issue has been resolved.]
■ For an IQ2 PIC logical interface, the Input Bytes counter and the Input Packets
counter might occasionally be incorrect. The statistics are incorrect when there
is significant local traffic associated with the logical interface:
■ The transit Input Bytes and Packets counters for a short duration might count
backwards or reset to zero.
■ The Total Input Bytes and Packet counters for a short duration might count
backwards.
This issue is transient and happens only during steady traffic flow with significant
local traffic. If the traffic is stopped or if the local traffic is marginal compared
to the total traffic for the logical interface, then the counters will become accurate.
■ Under some conditions, if an interface flaps for an interval less than the
hold-down time configured value, that interface might stop forwarding even
though it shows as being UP. As a workaround, enable traffic monitoring on the
interface, or enable and disable the interface. [PR/423065: This issue has been
resolved.]
■ CFMD might crash when the following are configured and commited at once on
a VPLS setup:
■ Encapsulation VLAN-VPLS on a physical and logical interface
■ Family VPLS on a logical unit
■ Interface is added in the VPLS routing instance
As a workaround, add the above configurations one at a time and commit.

■ The show interfaces diagnostics optics command displays wrong diagnostic
information for the SumitomoElectric SFP with vendor part number
SCP6F44-J3-ANE. [PR/463837: This issue has been resolved.]
■ SFPs are absent in the show chassis hardware output following TOXIC SFP
messages. [PR/480828: This issue has been resolved.]
■ In some cases during the periodic error status monitoring, error messages such
as “Wi seg ucode discards in fabric stream” can be displayed on adjacent streams.
These messages are cosmetic and can be ignored. [PR/481344: This issue has
been resolved.]
■ On a TX Matrix router, commit returns a validation error if there are no fxp0
configurations in the [groups lccX] hierarchy level , and the following is applied
simultaneously:
groups {
int-disable {
interfaces <*> disable
interfaces {
<*> {
disable;
}
}
}
}

■ During graceful Routing Engine switchover (GRES), if the peer's discovery state
is passive, the LFM state machine should be kick started even if the kernel state
is SEND_ANY, otherwise the peer will be stuck in PASSIVE_WAIT state. As a
workaround, configure both sides in the link-discovery mode as “active.”
■ The DPC remains in the ready state and the demux0 interface remains in a down
state after a chassisd restart without graceful Routing Engine switchover (GRES)
enabled. [PR/492961: This issue has been resolved.]
■ When an SCB which has an active plane is powered down, HSL link error occurs
on unrelated SCBs. [PR/493151: This issue has been resolved.]
■ The AE logical interface flaps when the PIC that has the active link-protection
member link is taken offline. [PR/493492: This issue has been resolved.]
■ The CLI does not respond when Control+c is entered at the "more” separator.
■ The system might generate a core file when the DPC is removed before it is
taken offline. [PR/494625: This issue has been resolved.]
■ An outer virtual LAN tag is not added in a provider edge-customer edge link when
VPLS traffic arrives with an MPLS value of 2, 3, 4, or 5. However, VPLS traffic
with a value of 0, 1, 6, or 7 does not have this issue. [PR/495555: This issue has
been resolved.]
■ The one-port OC12-3 PIC cannot support eight queues when the no-concatenate
option is configured. [PR/499452: This issue has been resolved.]
■ During a link UP/DOWN transition, jsscd might crash as a result of a NULL
message dereferencing by jsscd. [PR/502745: This issue has been resolved.]
■ Occasionally, a backup Routing Engine reboot followed by a Routing Engine

failover can cause LACP to flap, causing ae bundles to flap. [PR/502937: This
■ When an ATM AIS cell is received from the virtual channel under vlan-vci-ccc
encapsulation, the logical interface will be incorrectly marked as down. There is
no workaround. [PR/503653: This issue has been resolved.]
■ When native-vlan-id is configured for aggregated interface with the child links on
an IQ2 PIC, the LACPs are dropped and the links go down. [PR/507040: This
■ The show interfaces diagnostics optics interface command does not display the
unit of measurement when the received power is in a very low range (power <
5e-10). It shows the value of 0.00 without any unit of measurement. [PR/507653:
■ When the master Routing Engine is down and the backup Routing Engine is
rebooted, the backup Routing Engine reboots as backup. It does not become the
master for five to six minutes. [PR/507724: This issue has been resolved.]
■ On MX Series routers, the chassisd crashes when the SCB is taken offline and
removed. [PR/510950: This issue has been resolved.]
been resolved.]
■ Due to a flaw in implementation, the execution of the show interfaces
mac-database command causes the IQ2 PIC to reboot with the core. [PR/513407:
■ The output of the show chassis hardware command might not display the SIB
details when the SIB is inserted in the slot. [PR/515789: This issue has been
resolved.]
■ On some XENPAK modules, the output of the show chassis hardware command
shows the message "NON-JNPR UNKNOWN" when the FPC is booted. There is
no impact on the traffic. To solve this issue, take the PIC offline and bring it back
online. [PR/516411: This issue has been resolved.]
MPLS Applications
■ Sometimes, a traffic engineered label-switched path that is down does not get
re-signaled. [PR/478375: This issue has been resolved.]
■ The NGEN-MVPN multicast traffic might be dropped at the ingress router if a
point-to-multipoint LSP reoptimization is performed. [PR/491533: This issue has
been resolved.]
■ A rare condition between the MVPN and RSVP P2MP signaling leads to the
creation of stale flood next hops. [PR/491586: This issue has been resolved.]
■ An incorrectly changed LDP session authentication key causes the LDP session
to fail, and the LDP/IGP syncronization feature stops working. The IGP continues
to advertise the link at normal metric values. [PR/499226: This issue has been
resolved.]
■ LDP might not handle certain error conditions gracefully when NSR is enabled.
This might cause the LDP replication state to be stuck in the "In Progress" state
forever. [PR/505043: This issue has been resolved.]
Network Management
■ Under certain SNMP conditions, the following log message is displayed:
M10i-RE0 pfed: PFED_NOTIF_GLOBAL_STAT_UNKNOWN: Unknown global

notification stat: transit options/ttl-exceeded (re-injected)
M10i-RE0 pfed: PFED_NOTIF_STAT_UNKNOWN: Unknown notification type stat:
Unknown
This log message might also be displayed during the installation of AI Scripts
(version 2.1R2 or above) on the router. AI Scripts versions prior to 2.1R2 do not
cause these messages. This is a cosmetic message, and does not have any impact.
■ When monitor traffic matching x is used on RLSQ bundles, no outbound packets
are displayed. [PR/468959: This issue has been resolved.]
■ The output of the show route forwarding-table family vpls multicast command might
display an unexpected output such as “rtinfo” with the multicast knob because
this knob is supported only with inet and inet6 families and is not supported for
te ISO, NTP, MPLS, UNIX, and VPLS families. The output of this command will
be fixed in 10.1R1 to display the message: “Multicasting is not supported by the
UNIX, ISO, NTP, MPLS, and VPLS protocols.” [PR/235712: This issue has been
resolved.]
■ Reading the list of boot devices from the BIOS might fail once in hundreds or
thousands of times due to an improper locking mechanism. [PR/461320: This
■ On T640 and TX Series routers with an outgoing interface on a GFPC, the interface
might report LSIF errors or cell-mismatched errors after it receives an IPv6 packet
with an invalid payload. The interface still accepts traffic, but discards all outgoing
packets. To recover, reboot the FPC on T640 and TX Series routers. However,
if the IPv6 packets of the invalid payload are still transmitted, the problem will
occur again. [PR/470219: This issue has been resolved.]
■ When an aggregated SONET with a Cisco High-Level Data Link Control (HDLC)
encapsulation is configured, a member link might not be marked as linkdown
in the Packet Forwarding Engine if the remote end of the link is disabled.
■ The output of the show arp command does not show the entire demux interface
identifier, making it difficult to determine with which specific demux subinterface
a given ARP entry is associated. [PR/482008: This issue has been resolved.]
■ The syslog usually logs data only when the per-fabric-stream counter increases.
However, the syslog starts logging even if the counter value is not increasing.
■ The Source Class Usage (SCU) statistics counter value might drop occasionally
when it is used with the accounting profile. [PR/493662: This issue has been
resolved.]
■ The traffic sent to ports on PB-4OC3-4OC12-SON-SFP PICs in an MX-FPC2 (sent
above the configured bandwidth) might be dropped silently and
non-deterministically. This uncontrolled traffic drop can lead to high priority
traffic such as the PPP LCP being dropped. Depending on traffic conditions, this
can cause a link configured for PPP to bounce indefinitely. [PR/493793: This
■ An issue occurs when one or more multicast routes (such as one or more
<S,G>s) have received joins over an AE interface represented by two (or more)
AE legs on separate Packet Forwarding Engines. In a Packet Forwarding Engine
ASIC forwarding, the next hop shared by these multicast routes contains a list
representing the two (or more) Packet Forwarding Engines. When this next hop
list is no longer referenced by any active multicast route, it is not correctly freed
and remains stranded in the Packet Forwarding Engine ASIC memory. This issue
does not occur when the AE legs are all on the same Packet Forwarding Engine.
■ Due to excessive logging at the FPC, the E3 FPC Type 3 core dumps multiple
times. [PR/494534: This issue has been resolved.]
■ In certain cases, a configuration change can cause the backup Routing Engine
to reboot. [PR/497290: This issue has been resolved.]
■ On T Series routers with ES-FPCs, removing or adding flow-tap filters might
trigger an FPC reboot. However, the other FPC types in the same system are not
affected. [PR/499233: This issue has been resolved.]
■ When a next-hop chain has multiple types of next-hop dependencies, including
indirect next-hop, aggregate next-hop, and multiple unicast next-hops, during
an aggregate link flap (down/up), a certain sequence of events from the kernel
is expected by the Packet Forwarding Engine for the next-hop change and delete
updates. However, during a quick link flap (down/up), in an extreme corner case,
the Packet Forwarding Engine does not receive the expected sequence, and the
FPC will crash. [PR/499315: This issue has been resolved.]
■ On IQ2 PICs, when copy-plp is enabled under class of service, the DCU provides
the wrong statistics. [PR/499378: This issue has been resolved.]
■ The L2RW does not report an error when the required L2_pgm length is longer
than what the hardware can support. [PR/501318: This issue has been resolved.]
■ On an iChip platform, when the downstream multicast member link flaps, the
Packet Forwarding Engine rarely has a chance to fail multicast next-hop handling.
This can cause multicast traffic drops. [PR/501852: This issue has been resolved.]
■ On a TX Matrix Plus router, if one of the two external RJ–45 links between a
TXP-CIP and an LCC Control Board is broken, the router does not generate an
alarm. [PR/508219: This issue has been resolved.]
■ On some M, MX, and T Series routers, when a firewall filter is applied on the
egress of an aggregate interface, packet loss might occur after adding, removing,
or changing the service configuration on the egress side of the aggregate interface.
As a workaround, deactivate and activate the output firewall filter on the aggregate
■ When a socket connection between the Routing Engine and the FPC is
reestablished, the FPC might run into a software crash because of an invalid
counter being referenced. There is no workaround. [PR/525357: This issue has
been resolved.]
Routing Protocols
■ Deleting a logical system causes the routing protocol process to be stuck in an

infinite loop. [PR/439000: This issue has been resolved.]
■ The routing protocol process dumps core due to a soft assertion failed:
"rt_notbest_sanity: Path selection failure" in rt_table.c. As a workaround, use
the bgp path-selection external-router-id statement or the bgp path-selection
always-compare-med statement. [PR/451021: This issue has been resolved.]
■ When nonstop active routing (NSR) is running and BGP groups are added (eg a
VRF with a BGP in it), the routing protocol process might crash. As a workaround,
configure the new BGP groups after disabling the NSR. Reenable the NSR.
■ If there are enough routing instances with PIM configured, and there is enough
IGMP/MLD join state present and a configuration change is made, a routing
protocol process scheduler slip might occur. [PR/493062: This issue has been
resolved.]
■ On an unnumbered Ethernet interface in P2P mode, OSPF does not skip
validation of the network mask received in the hello packets. This could result
in a failure to bring up an adjacency on such interfaces while interoperating with
other vendors. As a workaround, convert the interface to a regular numbered
interface on both sides. [PR/493206: This issue has been resolved.]
■ When l3vpn-composite-next-hop is configured, it should only be used by L3VPN
routes. However, non-L3VPN routes are also able to use it. [PR/496028: This
■ In an NSR configuration, the backup Routing Engine can lose the connection to
the active Routing Engine during a configuration commit. The problem occurs
more often when the configuration includes a large number of routing instances.
This is caused by the routing protocol process on the backup Routing Engine
leaking file descriptors during commit synchronization. To recover, restart the
routing protocol process on the backup Routing Engine. [PR/506883: This issue
has been resolved.]
■ When the routing-instances routing-instances-name routing-options multipath
vpn-unequal-cost equal-external-internal statement is configured, some VPN routes
learned from different route reflectors can be shown as multipath. [PR/507236:
■ Nonstop routing (NSR) does not work correctly if an automatic route distinguisher
is used with a L2VPN routing-instance. [PR/513949: This issue has been resolved.]

■ On M Series routers (M120 and M320) with many service-sets configured with
idp policies, kernel messages are seen in the messages file once traffic passes
through these service-sets. These messages stop when the traffic is stopped.
■ A static route pointing to a destination is incorrectly added for a source NAT
when a next-hop type service set is used. [PR/476165: This issue has been
resolved.]
■ MSDPC might crash while running a combination of SIP and other ALGs due to
a possible double freeing of memory. [PR/491218: This issue has been resolved.]
■ The SIP ALG on the services PIC might cause NAT port leaks in some call
scenarios. [PR/491220: This issue has been resolved.]
■ The show services nat pool name CLI filter does not have any effect. [PR/493820:
■ Under certain conditions, the replication socket between two Routing Engines
for the local policy decision function process (LPDFD) does not close properly.
This results in high CPU consumption by the LPDFD. As a workaround, restart
the local policy decision function process (LPDFD) on the master Routing Engine’s
restart local-policy-decision-function. [PR/495363: This issue has been resolved.]
■ The l2tp on an M7i LNS crashes following an upgrade from JUNOS Release 9.3R1
to 9.6R2. [PR/498423: This issue has been resolved.]
■ When using a NAT DCE RPC ALG on a services PIC, the PIC might crash while
processing the binding request. [PR/510997: This issue has been resolved.]
■ When an event policy is configured for an event with the attributes-match clause
and if the event occurs without the attribute mentioned in the attributes-match
clause, then the policy action gets executed. This behavior is wrong as the policy
action should not executed. [PR/421808: This issue has been resolved.]
■ The wildcard apply groups do not work properly in JUNOS Release 9.1 and above.
■ The deactivate configuration statement is not blocked through the
deny-configuration statement. [PR/488352: This issue has been resolved.]
■ When commit scripts are used and the configuration contains a policy which
uses an apply-group with a then action of “then community + EXPORT,” the
commit fails. [PR/501876: This issue has been resolved.]
■ On M10i, M120, M320, and MX Series routers with dual Routing Engines running
JUNOS Release 9.4 or later, the dfwd process running on the backup Routing
Engine might access the /var/pdb/rdm.taf file every 30 seconds, causing excessive
writes to the hard disk drive. This problem does not occur when GRES is enabled.
VPNs
■ When different prefixes are advertised to the same source by different PE routers,
an egress PE router is prevented from picking the lower prefix route for RPF
when the PR advertising the higher prefix loses its route to the source.
■ While upgrading JUNOS Software with l2circuit configuration in the logical
systems, the validation might fail with an "interface version mismatch" error.
You can ignore this error and upgrade the JUNOS Software using the no-validate
option. [PR/497190: This issue has been resolved.]
■ When multipath is enabled in a routing instance with NG MVPN, the traffic might
get dropped on the receiver PE. [PR/508090: This issue has been resolved.]
on page 6
Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX
Series, and T Series Routers
Changes to the JUNOS Documentation Set
The title of the JUNOS Hierarchy and RFC Reference is now JUNOS Hierarchy and
Standards Reference.
Documentation for the extended DHCP relay agent feature is no longer included in
the Policy Framework Configuration Guide. For DHCP relay agent documentation, see
the Subscriber Access Configuration Guide or the documentation for Subscriber Access
Management.
Errata
This section lists outstanding issues with the documentation.
104 ■ Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX Series, and T Series Routers
Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX Series, and T Series Routers
High Availability
■ TX Matrix Plus routers and T1600 routers that are configured as part of a routing
matrix do not currently support nonstop active routing. [High Availability
Configuration Guide]
■ Nonstop active routing support on TX Plus Matrix router—JUNOS Release
10.0 extends nonstop active routing support to TX Plus Matrix routers and T1600
routers connected to a routing matrix. [JUNOS Routing Matrix with a TX Matrix
Plus Router Feature Guide]
Network Interfaces
■ The Network Interfaces Configuration Guide in Chapter 5: Configuring Protocol

Family and Interface Address Properties, the section "Enabling Source Class and
Destination Class Usage" contains the following incorrect statement that can be
ignored: On T Series, M120, and M320 routers, the destination-class and
source-class statements are not supported at the [edit firewall family family-name
filter filter-name term term-name from] hierarchy level. On other M Series routers,
these statements are supported.
■ The Network Interfaces Configuration Guide, Chapter 61, Configuring SONET/SDH
Interfaces, included a subsection titled Configuring APS Using a Container Interface
with ATM Encapsulation. This information was mistakenly included and should
not have been published until JUNOS Release 10.4.
■ The Configuring Layer 2 Circuit Transport Mode chapter in the Network Interfaces
Configuration Guide states that one way to configure an ATM II interface to enable
a Layer 2 circuit connection across all versions of JUNOS Software is the following:
■ For Layer 2 circuit cell relay and Layer 2 trunk modes, the atm-l2circuit-mode
cell statement at the [edit chassis fpc slot pic slot] hierarchy level and the
encapsulation atm-ccc-cell-relay statement at the [edit interface interface-name]
hierarchy level.
The configuration above is correct and will interoperate with routers running all
versions of JUNOS Software.
However, the chapter does not mention that you can also include the
encapsulation atm-ccc-cell-relay statement at the [edit interface interface-name unit
logical-unit-number] hierarchy level. When you use the above configuration, keep
the following points in mind:
■ • This configuration will interoperate between Juniper Networks routers
running JUNOS Release 8.2 or lower.
■ This configuration will NOT interoperate with other network equipment,
including a Juniper Networks router running JUNOS Release 8.3 or higher.
■ • For a Juniper Networks router running JUNOS Release 8.3 or higher to

interoperate with another Juniper Networks router running JUNOS Release
8.2 or lower, on the router running JUNOS Release 8.3 or higher, include
Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX Series, and T Series Routers ■ 105
the use-null-cw statement at the [edit interfaces interface-name atm-options]

hierarchy level.
■ • The use-null-cw statement inserts (for sending traffic) or strips (for receiving
traffic) an extra null control word in the MPLS packet.
■ • The use-null-cw statement is not supported on a router running JUNOS

Release 8.2 or lower.
The Subscriber Access Configuration Guide contains the following dynamic variable
errors:
■ The Configuring a Dynamic Profile for Client Access topic erroneously uses the
$junos-underlying-interface variable when configuring an IGMP interface in the
client access dynamic profile. The following example provides the appropriate
use of the $junos-interface-name variable:
[edit dynamic-profiles access-profile]

user@host# set protocols igmp interface $junos-interface-name
■ Table 25 in the Dynamic Variables Overview topic neglects to define the

$junos-igmp-version predefined dynamic variable. This variable is defined as
follows:
$junos-igmp-version—IGMP version configured in a client access profile. The
JUNOS software obtains this information from the RADIUS server when a
subscriber accesses the router. The version is applied to the accessing subscriber
when the profile is instantiated. You specify this variable at the [dynamic-profiles
profile-name protocols igmp] hierarchy level for the interface statement.
In addition, the Subscriber Access Configuration Guide erroneously specifies the
use of a colon (:) when you configure the dynamic profile to define the IGMP
version for client interfaces. The following example provides the appropriate
syntax for setting the IGMP interface to obtain the IGMP version from RADIUS:
[edit dynamic-profiles access-profile protocols igmp interface $junos-interface-name]

user@host# set version $junos-igmp-version
■ The Subscriber Access Configuration Guide and the System Basics Configuration
Guide contain information about the override-nas-information statement. This
statement does not appear in the CLI and is not supported.
[Subscriber Access Configuration Guide, System Basics Configuration Guide]
■ When you modify dynamic CoS parameters with a RADIUS change of
authorization (CoA) message, the JUNOS Software accepts invalid configurations.
For example, if you specify that a transmit rate that exceeds the allowed 100
percent, the system does not reject the configuration and returns unexpected
shaping behavior.
106 ■ Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX Series, and T Series Routers
Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX Series, and T Series Routers
[Subscriber Access Configuration Guide]

■ We do not support multicast RIF mapping and ANCP when configured
simultaneously on the same logical interface. For example, we do not support
when a multicast VLAN and ANCP are configured on the same logical interface,
and the subscriber VLANs are the same for both ANCP and multicast.
[Subscriber Access Configuration Guide]
■ The show system statistics bridge command displays system statistics on MX

Series routers. [System Basics Command Reference]
VPNs
■ The mac-tlv-receive and mac-tlv-send statements have been removed from the
software and are no longer visible in the [edit logical-systems logical-system-name
routing-instances routing-instance-name protocols vpls] and [edit routing-instances
routing-instance-name protocols vpls] hierarchy levels. Although the mac-tlv-receive
and mac-tlv-send statements are recognized in the current release, they will be
removed in a future release. We recommend that you update your configurations
and use the mac-flush statement described in the Changes in Default Behavior and
Syntax in JUNOS Release 10.0 for M Series, MX Series, and T Series Routers section
of the release notes.
[VPNs]
■ In Chapter 19, Configuring VPLS of the VPNs Configuration Guide, an incorrect
statement that caused contradictory information about which platforms support
LDP BGP interworking has been removed. The M7i router was also omitted from
the list of supported platforms. The M7i router does support LDP BGP
interworking.
[VPNs]
on page 6
page 54
Errata and Changes in Documentation for JUNOS Software Release 10.0 for M Series, MX Series, and T Series Routers ■ 107
Upgrade and Downgrade Instructions for JUNOS Release 10.0 for M Series, MX Series,
and T Series Routers
This section discusses the following topics:
■ Basic Procedure for Upgrading to Release 10.0 on page 108
■ Upgrade Policy for JUNOS Software Extended End-Of-Life Releases on page 111
■ Upgrading a Router with Redundant Routing Engines on page 111
■ Upgrading the Software for a Routing Matrix on page 112
■ Upgrading Using ISSU on page 113
■ Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both PIM
and NSR on page 113
■ Downgrade from Release 10.0 on page 114
Basic Procedure for Upgrading to Release 10.0
In order to install JUNOS 10.0 or later, you must be running JUNOS 9.0S2, 9.1S1,
9.2R4, 9.3R3, 9.4R3, 9.5R1, 9.6B1 or later minor versions. See PR 436019 for more
information.
When upgrading or downgrading the JUNOS Software, always use the jinstall package.
Use other packages (such as the jbundle package) only when so instructed by a Juniper
Networks support representative. For information about the contents of the jinstall
package and details of the installation process, see the Junos OS Installation and
Upgrade Guide.
NOTE: With JUNOS Release 9.0 and later, the compact flash disk memory requirement
for JUNOS Software is 1 GB. For M7i and M10i routers with only 256 MB memory,
see the Customer Support Center JTAC Technical Bulletin PSN-2007-10-001 at
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001&actionBtn=Search.
NOTE: Before upgrading, back up the file system and the currently active JUNOS
configuration so that you can recover to a known, stable environment in case the
upgrade is unsuccessful. Issue the following command:
user@host> request system snapshot
The installation process rebuilds the file system and completely reinstalls the JUNOS
Software. Configuration information from the previous software installation is retained,
but the contents of log files might be erased. Stored files on the routing platform,
such as configuration templates and shell scripts (the only exceptions are the
juniper.conf and ssh files) may be removed. To preserve the stored files, copy them
to another system before upgrading or downgrading the routing platform. For more
information, see the Junos OS System Basics Configuration Guide.
108 ■ Upgrade and Downgrade Instructions for JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
Upgrade and Downgrade Instructions for JUNOS Release 10.0 for M Series, MX Series, and T Series Routers
In order to upgrade to JUNOS Software Release 10.0 or later, a router must be running
one of the following JUNOS Software releases:
■ 9.1S1
■ 9.2R4
■ 9.3R3
■ 9.4R3
■ 9.5R1 or later
Upgrade and Downgrade Instructions for JUNOS Release 10.0 for M Series, MX Series, and T Series Routers ■ 109
The download and installation process for JUNOS Release 10.0 is the same as for
previous JUNOS releases.
If you are not familiar with the download and installation process, follow these steps:
1. Using a Web browser, follow the links to the download URL on the Juniper
Networks Web page. Choose either Canada and U.S. Version or Worldwide
Version:
■ https://www.juniper.net/support/csc/swdist-domestic/ (customers in the United
States and Canada)
■ https://www.juniper.net/support/csc/swdist-ww/ (all other customers)
2. Log in to the Juniper Networks authentication system using the username

(generally your e-mail address) and password supplied by Juniper Networks
representatives.
3. Download the software to a local host.
4. Copy the software to the routing platform or to your internal software distribution
site.
5. Install the new jinstall package on the routing platform.
NOTE: We recommend that you upgrade all software packages out of band using
the console because in-band connections are lost during the upgrade process.
Customers in the United States and Canada use the following command:
user@host> request system software add validate reboot

source/jinstall-10.0R4.7-domestic-signed.tgz
All other customers use the following command:
user@host> request system software add validate reboot

source/jinstall-10.0R4.7-export-signed.tgz
Replace source with one of the following values:

■ /pathname—For a software package that is installed from a local directory
on the router.
■ For software packages that are downloaded and installed from a remote
location:
■ ftp://hostname/pathname
■ http://hostname/pathname
■ scp://hostname/pathname (available only for Canada and U.S. version)
The validate option validates the software package against the current
configuration as a prerequisite to adding the software package to ensure that
the router reboots successfully. This is the default behavior when the software
package being added is a different release.
Adding the reboot command reboots the router after the upgrade is validated
and installed. When the reboot is complete, the router displays the login prompt.
The loading process can take 5 to 10 minutes.
Rebooting occurs only if the upgrade is successful.
NOTE: After you install a JUNOS 10.0 jinstall package, you cannot issue the request
system software rollback command to return to the previously installed software.
Instead you must issue the request system software add validate command and specify
the jinstall package that corresponds to the previously installed software.
NOTE: Before you upgrade a router that you are using for voice traffic, you should
monitor call traffic on each virtual BGF. Confirm that no emergency calls are active.
When you have determined that no emergency calls are active, you can wait for
non-emergency call traffic to drain as a result of graceful shutdown, or you can force
a shutdown. For detailed information on how to monitor call traffic before upgrading,
see the JUNOS Multiplay Solutions Guide.
Upgrade Policy for JUNOS Software Extended End-Of-Life Releases
An expanded upgrade and downgrade path is now available for the JUNOS Software
Extended End-of-Life (EEOL) releases. You can upgrade directly from one EEOL
release to one of two adjacent later EEOL releases. You can also downgrade directly
from one EEOL release to one of two adjacent earlier EEOL releases.
For example, JUNOS Software Releases 8.5, 9.3, 10.0, and 10.4 are all EEOL releases.
You can upgrade from JUNOS Software Release 8.5 directly to either 9.3 or 10.0. To
upgrade from Release 8.5 to 10.4, you first need to upgrade to JUNOS Software
release 9.3 or 10.0, and then upgrade a second time to 10.4. Similarly, you can
downgrade directly from JUNOS Software Release 10.4 to either 10.0 or 9.3. To
downgrade from release 10.4 to 8.5, you first need to downgrade to 10.0 or 9.3, and
then perform a second downgrade to Release 8.5.
For upgrades and downgrades to or from a non-EEOL release, the current policy is
that you can upgrade and downgrade by no more than three releases at a time. This
policy remains unchanged.
For more information on EEOL releases and to review a list of EEOL releases, see
http://www.juniper.net/support/eol/junos.html.
Upgrading a Router with Redundant Routing Engines
If the router has two Routing Engines, perform a JUNOS Software installation on each
Routing Engine separately to avoid disrupting network operation as follows:
1. Disable graceful Routing Engine switchover (GRES) on the master Routing Engine
and save the configuration change to both Routing Engines.
2. Install the new JUNOS Software release on the backup Routing Engine while
keeping the currently running software version on the master Routing Engine.
3. After making sure that the new software version is running correctly on the
backup Routing Engine, switch over to the backup Routing Engine to activate
the new software.
4. Install the new software on the original master Routing Engine that is now active
as the backup Routing Engine.
For the detailed procedure, see the Junos OS Installation and Upgrade Guide.
Upgrading the Software for a Routing Matrix
A routing matrix can use either a TX Matrix router as the switch-card chassis (SCC)
or a TX Matrix Plus router as the switch-fabric chassis (SFC). By default, when you
upgrade software for a TX Matrix router or a TX Matrix Plus router, the new image
is loaded onto the TX Matrix or TX Matrix Plus router (specified in the JUNOS CLI by
using the scc or sfc option) and distributed to all T640 routers or T1600 routers in
the routing matrix (specified in the JUNOS CLI by using the lcc option). To avoid
network disruption during the upgrade, ensure the following before beginning the
upgrade process:
■ A minimum of free disk space and DRAM on each Routing Engine. The software
upgrade will fail on any Routing Engine without the required amount of free disk
space and DRAM. To determine the amount of disk space currently available on
all Routing Engines of the routing matrix, use the CLI show system storage
command. To determine the amount of DRAM currently available on all the
Routing Engines in the routing matrix, use the CLI show chassis routing-engine
command.
■ The master Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or
SFC) and T640 routers or T1600 routers (LCC) are all re0 or are all re1.
■ The backup Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or
SFC) and T640 routers or T1600 routers (LCC) are all re1 or are all re0.
■ All master Routing Engines in all routers run the same version of software. This
is necessary for the routing matrix to operate.
■ All master and backup Routing Engines run the same version of software before
beginning the upgrade procedure. Different versions of the JUNOS Software can
have incompatible message formats especially if you turn on GRES. Because the
steps in the process include changing mastership, running the same version of
software is recommended.
■ For a routing matrix with a TX Matrix router, the same Routing Engine model is
used within a TX Matrix router (SCC) and within a T640 router (LCC) of a routing
matrix. For example, a routing matrix with an SCC using two RE-A-2000s and
an LCC using two RE-1600s is supported. However, an SCC or an LCC with two
different Routing Engine models is not supported. We suggest that all Routing
Engines are the same model throughout all routers in the routing matrix. To
determine the Routing Engine type, use the CLI show chassis hardware | match
routing command.
■ For a routing matrix with a TX Matrix Plus router, the SFC contains two model
RE-DUO-C2600-16G Routing Engines, and each LCC contains two model
RE-DUO-C1800-8G Routing Engines.
NOTE: It is considered best practice to make sure that all master Routing Engines
are re0 and all backup Routing Engines are re1 (or vice versa). For the purposes of
this document, the master Routing Engine is re0 and the backup Routing Engine is
re1.
To upgrade the software for a routing matrix, perform the following steps:
1. Disable graceful Routing Engine switchover (GRES) on the master Routing Engine
(re0) and save the configuration change to both Routing Engines.
2. Install the new JUNOS Software release on the backup Routing Engine (re1) while
keeping the currently running software version on the master Routing Engine
(re0).
3. Load the new JUNOS Software on the backup Routing Engine. After making sure
that the new software version is running correctly on the backup Routing Engine
(re1), switch mastership back to the original master Routing Engine (re0) to
activate the new software.
4. Install the new software on the new backup Routing Engine (re0).
For the detailed procedure, see the Routing Matrix with a TX Matrix Feature Guide or the
Routing Matrix with a TX Matrix Plus Feature Guide.
Upgrading Using ISSU
Unified in-service software upgrade (ISSU) enables you to upgrade between two
different JUNOS Software releases with no disruption on the control plane and with
minimal disruption of traffic. Unified in-service software upgrade is only supported
by dual Routing Engine platforms. In addition, graceful Routing Engine switchover
(GRES) and nonstop active routing (NSR) must be enabled. For additional information
about using unified in-service software upgrade, see the Junos OS High Availability
Configuration Guide.
Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both
PIM and NSR
JUNOS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the
following PIM features are not currently supported with NSR. The commit operation
fails if the configuration includes both NSR and one or more of these features:
■ Anycast RP
■ Draft-Rosen multicast VPNs (MVPNs)
■ Local RP
■ Next-generation MVPNs with PIM provider tunnels
■ PIM join load balancing
JUNOS 9.3 introduced a new configuration statement that disables NSR for PIM only,
so that you can activate incompatible PIM features and continue to use NSR for the
other protocols on the router: the nonstop-routing disable statement at the [edit
protocols pim] hierarchy level. (Note that this statement disables NSR for all PIM
features, not only incompatible features.)
If neither NSR nor PIM is enabled on the router to be upgraded or if one of the
unsupported PIM features is enabled but NSR is not enabled, no additional steps are
necessary and you can use the standard upgrade procedure described in other sections
of these instructions. If NSR is enabled and no NSR-incompatible PIM features are
enabled, use the standard reboot or ISSU procedures described in the other sections
of these instructions.
Because the nonstop-routing disable statement was not available in JUNOS Release
9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router
to be upgraded from JUNOS Release 9.2 or earlier to a later release, you must disable
PIM before the upgrade and reenable it after the router is running the upgraded
JUNOS Software and you have entered the nonstop-routing disable statement. If your
router is running JUNOS Release 9.3 or later, you can upgrade to a later release
without disabling NSR or PIM–simply use the standard reboot or ISSU procedures
described in the other sections of these instructions.
To disable and reenable PIM:

1. On the router running JUNOS Release 9.2 or earlier, enter configuration mode
and disable PIM:
[edit]
user@host# deactivate protocols pim
user@host# commit
2. Upgrade to JUNOS Release 9.3 or later software using the instructions appropriate
for the router type. You can either use the standard procedure with reboot or
use ISSU.
3. After the router reboots and is running the upgraded JUNOS Software, enter
configuration mode, disable PIM NSR with the nonstop-routing disable statement,
and then reenable PIM:
[edit]
user@host# set protocols pim nonstop-routing disable
user@host# activate protocols pim
user@host# commit
Downgrade from Release 10.0
To downgrade from Release 10.0 to another supported release, follow the procedure
for upgrading, but replace the 10.0 jinstall package with one that corresponds to the
appropriate release.
NOTE: You cannot downgrade more than three releases. For example, if your routing
platform is running JUNOS Release 9.3, you can downgrade the software to
Release 9.0 directly, but not to Release 8.5 or earlier; as a workaround, you can first
downgrade to Release 9.0 and then downgrade to Release 8.5.
For more information, see the Junos OS Installation and Upgrade Guide.
on page 6
page 54
JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways
and J Series Services Routers
Powered by JUNOS Software, Juniper Networks SRX Series Services Gateways provide
robust networking and security services. SRX Series Services Gateways range from
lower-end devices designed to secure small distributed enterprise locations to high-end
devices designed to secure enterprise infrastructure, data centers, and server farms.
The SRX Series Services Gateways include the SRX100, SRX210, SRX240, SRX650,
SRX3400, SRX3600, SRX5600, and SRX5800 devices.
Juniper Networks J Series Services Routers running JUNOS Software provide stable,
reliable, and efficient IP routing, WAN and LAN connectivity, and management
services for small to medium-sized enterprise networks. These routers also provide
network security features, including a stateful firewall with access control policies
and screens to protect against attacks and intrusions, and IPsec VPNs. The J Series
Services Routers include the J2320, J2350, J4350, and J6350 devices.
■ New Features in JUNOS Release 10.0 for SRX Series Services Gateways and J
Series Services Routers on page 116
■ Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX Series
Services Gateways and J Series Services Routers on page 146
■ Known Limitations in JUNOS Release 10.0 for SRX Series Services Gateways and
J Series Services Routers on page 152
■ Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J Series
Services Routers on page 162
■ Errata and Changes in Documentation for JUNOS Release 10.0 for SRX Series
■ Hardware Requirements for JUNOS Release 10.0 for SRX Series Services Gateways
and J Series Services Routers on page 191
■ Dual-Root Partitioning Scheme Documentation for SRX Series Services
Gateways on page 193
■ Maximizing ALG Sessions on page 202
■ Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second
Routing Engine on page 202
■ Upgrade and Downgrade Instructions for JUNOS Release 10.0 for SRX Series
New Features in JUNOS Release 10.0 for SRX Series Services Gateways and J Series
Services Routers
The following features have been added to JUNOS Release 10.0. Following the
description is the title of the manual or manuals to consult for further information.
■ Software Features on page 117
■ Hardware Features—SRX100 Services Gateways on page 138
■ Hardware Features—SRX210 and SRX240 Services Gateways on page 138
116 ■ JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways and J Series Services Routers
New Features in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
■ Hardware Features—SRX210 Services Gateway with Integrated Convergence

Services (Available in North America Only) on page 140
■ Hardware Features—SRX240 Services Gateway with Integrated Convergence
Services (Available in North America Only) on page 142
■ Hardware Features—SRX650 Services Gateways on page 144
Software Features
Application Layer Gateways (ALGs)
■ PPTP ALG—This feature is now supported on SRX3400, SRX3600, SRX5600,

and SRX5800 devices in addition to existing support on SRX100, SRX210,
SRX240, and J Series devices.
JUNOS Software provides Point-to-Point Tunneling Protocol (PPTP) support. PPTP
is a Layer 2 protocol that tunnels PPP data across TCP/IP networks. The PPTP
client is freely available on Windows systems and is widely deployed for building
VPNs. PPTP is used to provide IP security at the Network Layer. PPTP uses TCP
for its control connection and GRE for its PPP data. The PPTP ALG consists of a
control connection and a data tunnel. The control connection runs over TCP and
is used to establish and disconnect calls. The data tunnel carries PPP packets
encapsulated in GRE packets, which are carried over IP.
To configure the PPTP ALG, use the edit security alg pptp statement at the [edit
security alg] hierarchy level.
[Junos OS Security Configuration Guide]
■ RSH ALG—This feature is now supported on SRX3400, SRX3600, SRX5600, and
SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240,
and J Series devices.
The Remote Shell (RSH) ALG handles TCP packets destined for port 514 and
processes the RSH port command. The RSH ALG performs NAT on the port in
the port command and opens gates as necessary.
To configure the RSH ALG, use the edit security alg rsh statement at the [edit
■ RTSP ALG—This feature is now supported on SRX3400, SRX3600, SRX5600,
To configure the Real-Time Streaming Protocol (RTSP) ALG, use the edit security
alg rtsp statement at the [edit security alg] hierarchy level.
■ TALK ALG—This feature is now supported on SRX3400, SRX3600, SRX5600,
The TALK protocol uses UDP port 517 and port 518 for control channel
connections. The talk program consists of a server and a client. The server handles
client notifications and helps to establish talk sessions. There are two types of
New Features in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers ■ 117
talk servers: ntalk and talkd. The TALK ALG processes packets of both ntalk and
talkd formats. It also performs NAT and gate opening as necessary.
To configure the TALK ALG, use the edit security alg talk statement at the [edit
■ Layer 2 mode with chassis clustering—This feature is supported on SRX5600
and SRX5800 devices.
The following Application Layer Gateways (ALGs) are supported in Layer 2 mode
with chassis clustering:
■ Real-Time Streaming Protocol (RTSP)
■ Domain Name System (DNS)
■ File Transfer Protocol (FTP)
■ Trivial File Transfer Protocol (TFTP)
Chassis Cluster
■ Dampening time between back-to-back redundancy group failovers—This

feature is supported on SRX Series and J Series devices.
You can set the minimum interval to be allowed between back-to-back failovers
for the specified redundancy group with the hold-down-interval statement (affects
manual failovers, as well as automatic failovers associated with monitoring
failures). On a failover, the previous primary node moves to the secondary-hold
state and stays there until the hold-down interval expires, after which it moves
to the secondary state.
Redundancy group 0 has a default dampening time of 300 seconds (5 minutes),
with a configurable range of 300 through 1800 seconds. Redundancy groups 1
through 128 have a default dampening time of 1 second, with a range of 0
through 1800 seconds.
■ Dual control links—This feature is supported on SRX5600 and SRX5800 devices.
You can connect two control links between each device in a cluster, effectively
reducing the chance of control link failure. This functionality requires a second
Routing Engine to be installed on each device in the cluster, as well as a second
Switch Control Board (SCB) to house the Routing Engine for the SRX5000 line.
The purpose of the second Routing Engine is only to initialize the second switch;
it does not provide any other redundancy functionality. When the second Routing
Engine boots, it goes to single user mode and you cannot use the CLI or enter
configuration mode.
Having two control links helps to avoid a single point of failure by reducing the
number of disabled cases that are caused by control link failure. (For a chassis
cluster with one control link, if the control link goes down, all redundancy groups
on the secondary node go to ineligible and eventually to the disabled state.)
118 ■ New Features in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
Configuration and Management
■ AX411 Access Point support—This feature is supported on SRX210, SRX240,

and SRX650 devices.
JUNOS Release 10.0 provides support for configuring and managing the Juniper
Networks AX411 Access Point from an SRX210, SRX240, or SRX650 device.
The AX411 Access Point provides network access for wireless clients such as
laptop or desktop computers, personal digital assistants (PDAs), or any other
device equipped with a Wi-Fi adapter and supporting drivers. The AX411 Access
Point supports the IEEE 802.11n wireless networking standard with backward
compatibility for IEEE 802.11a/b/g standards.
The AX411 Access Point can be configured and managed from the SRX Series
device through the JUNOS CLI or J-Web interface.
You can configure and manage up to two AX411 Access Points from an SRX
Series Services Gateway without installing a license on the SRX Series device.
To configure and manage additional AX411 Access Points, you must install one
or more licenses on the SRX Series device. Each of these licenses specifies the
number of access points that can be configured and managed in addition to the
two that are automatically supported on the device.
The following licenses are available for the SRX Series Services Gateway:
■ 2-access point license
You can install multiple licenses in any increment to increase the number of
access points supported on the SRX Series device. The following are the maximum
numbers of access points that can be configured and managed from SRX Series
devices:
■ SRX210—4 access points
NOTE: The number of licensed access points can exceed the maximum number of
supported access points. However, you can only configure and manage the maximum
number of access points.
To configure the AX411 Access Point, use the [edit wlan] hierarchy.
[Junos OS WLAN Configuration and Administration Guide]
Flow and Processing
■ Data path debugging—This feature is supported on SRX3400, SRX3600,

SRX5600, and SRX5800 devices.
Data path debugging provides tracing and debugging at multiple processing units
along the packet-processing path.
Data path debugging also provides the following enhancements:

■ Custom action profile that provides more debugging flexibility
■ More debugging events
■ Platform-independent event: jexec
■ Platform-dependent events:
■ mac-ingress
■ mac-egress (SRX3400 and SRX3600 devices only)
■ More debugging actions:

■ count
■ packet-dump
■ Increased hardware support:

■ SRX3000 line devices
■ SRX5000 line devices with Flex IOCs
■ Integration with flow trace within data path debugging
■ New record-pic-history option for showing the packet-processing path
■ New preserve-trace-order option for serializing the trace to its original

order

■ General Packet Radio Service (GPRS)—This feature is supported on SRX3400,
SRX3600, SRX5600, and SRX5800 devices.
GPRS networks connect to several external networks including those of roaming
partners, corporate customers, GPRS Roaming Exchange (GRX) providers, and
the public Internet. GPRS network operators face the challenge of protecting
their network while providing and controlling access to and from these external
networks. Juniper Networks provides solutions to many of the security problems
plaguing GPRS network operators.
In the GPRS architecture, the fundamental cause of security threats to an
operator’s network is the inherent lack of security in GPRS tunneling protocol
(GTP). GTP is the protocol used between GPRS support nodes (GSNs).
Communication between different GPRS networks is not secure because GTP

does not provide any authentication, data integrity, or confidentiality protection.
Implementing Internet Protocol security (IPsec) for connections between roaming
partners, setting traffic rate limits, and using stateful inspection can eliminate a
majority of the GTP’s security risks. Juniper Networks security devices mitigate
a wide variety of attacks on the Gp, Gn, and Gi interfaces. The GTP firewall
features in JUNOS Software address key security issues in mobile operators’
networks.
When the JUNOS Software GPRS is enabled, the following features are supported:
■ GTP packet sanity check
■ GTP stateful inspection
■ GGSN redirection
■ Policy-based GTP inspection
■ GTP message length filtering
■ GTP message type screening
■ GTP IMSI prefix and APN filtering
■ Removal of IEs of GTP R6
■ GSN rate limiting
■ GTP sequence number validation
■ Cleanup of hanging GTP tunnel
■ GTP traffic logging
■ GTP tunnel failover for high availability

■ Multiclass multilink functionality—This feature is now supported on SRX210,
SRX240, SRX650 devices and J Series devices.
JUNOS Release 10.0 now provides multiclass multilink functionality. The
multiclass multilink enables users to classify multilink packets and allows
scheduling of packets based on class priority.
Note the following changes to multiclass multilink functionality:

■ Multilink functionality has been moved to the lsq-0/0/0 interface in JUNOS
Release 10.0.
■ Multilink interface ls-0/0/0 has been deprecated. All multilink features
supported byls-0/0/0 are now supported by lsq-0/0/0.
[Junos OS Interfaces and Routing Configuration Guide]

■ Number of sessions—This feature is supported on SRX3400, SRX3600, SRX5600,
and SRX5800 devices.
For JUNOS Release 10.0, the session numbers have been increased. Table 2 on
page 122 provides the details of the number of sessions.
Table 2: Number of Sessions on SRX3400, SRX3600, SRX5600, and SRX5800 Devices
Maximum Sessions in
SRX Series Release 9.6 and Maximum Sessions in
Device earlier Release 10.0 Central Point (CP)
SRX3400 1 million (M) 2.25 million (M) Combo CP
SRX3600 2M 2.25M Combo CP
SRX5600 8M/2M 9M/2.25M Full CP/combo CP
SRX5800 8M/2M 10M/2.25M Full CP/combo CP
Integrated Convergence Services Features
Integrated Convergence Services optimizes and secures VoIP communication and

applications running on Juniper Networks SRX Series Services Gateways. Integrated
Convergence Services components include a SIP-based media gateway (SRX Series
MGW) with an integrated DSP, POTS interfaces, expansion cards, and a survivable
call server (SRX Series SCS) that takes control to provide call handling and routing
when the SIP peer call server is unreachable.
■ Integrated Convergence Services SRX Series MGW functionality—This feature
is supported on SRX210 and SRX240 devices.
The SRX Series MGW is a standards-based SIP media gateway that connects VoIP
networks to the PSTN so that calls can be made from, and routed to, local analog
telephones, fax machines, and SIP IP phones behind it. When the SRX Series
MGW is active, a SIP peer call server at the data center, or elsewhere, provides
call handling services and call routing for the branch.
Integrated Convergence Services supports the Open Convergence Architecture
and gives you the flexibility to select the SIP call servers, IP phones, and service
providers to be used.
The SRX Series MGW includes the following features:

■ Emergency call support that allows the SRX Series MGW to intercept all
branch calls whose called number matches that of a configured emergency
number, for example 9-1-1. The SRX Series MGW routes these calls to a local
PSTN trunk, if you configure SRX Series MGW trunks, or to the peer call
server.
■ Emergency 911 preemptive calling in which all intercepted emergency calls,
for example, 9-1-1 in the United States, dialed from an analog telephone are
given priority. They are routed to an available FXO PSTN trunk. If all trunks
are handling other calls, the call that has been active longest is terminated.
Before the line is seized, a triple-fast beep is played.
■ Onboard telephony FXS and FXO POTS interfaces that provide local number
preservation for incoming calls and support for emergency calls. If you have
configured the SRX Series survivable call server (SRX Series SCS), these
interfaces can also be used for call routing when the SIP peer call server
cannot be reached because of network failure or other fault conditions.
■ SIP registration of FXS stations in which each FXS port is registered to the
SIP peer call server through the SRX Series MGW.
■ Trunk access codes for prefix-based PSTN routing. The administrator can
configure a prefix in the dial plan to route a call directly to the PSTN.
[JUNOS Software Integrated Convergence Services Configuration and Administration

Guide]
■ Integrated Convergence Services SRX Series SCS functionality—This feature
The SRX Series SCS provides local call handling and basic call routing when the
SIP peer call server cannot be reached to provide these services for the branch.
The SRX Series SCS includes the following features and services:
■ SIP keepalive messages to determine if the peer call server is responsive. If
it is not, the survivable call server takes control. The survivable call server
is invoked immediately if a local interface, such as the WAN interface, goes
down.
■ Destination class-of-restriction call routing to determine rights users have to
make types of calls from certain stations.
■ Emergency 911 preemptive calling in which all intercepted emergency calls,

for example, 9-1-1 in the United States, dialed from an analog telephone are
given priority. They are routed to an available FXO PSTN trunk. If all trunks
are handling other calls, the call that has been active longest is terminated.
■ Voicemail answering and retrieval. After a configured number of rings, the

system forwards the call to a defined voicemail number. Users of local
extensions can retrieve their voicemail by dialing specific digits.
■ Digit manipulation for remapping digits.

Guide]
■ Integrated Convergence Services music on hold—This feature is supported on
SRX210 and SRX240 devices.
Music on hold allows for music to be played for all calls that are placed on hold.
The music is played from a previously loaded file. You can specify the format
and the order in which files are played, if there is more than one file.
■ Integrated Convergence Services voice-specific features—These features are
supported on SRX210 and SRX240 devices.
■ Jitter buffer handling in which a jitter buffer provides local packet caching.
This feature allows VoIP packets to be transmitted at a steady rate by
reducing jitter.
■ Voice continuity for an improved voice quality experience.
■ Tone detection to enable calling features based on digit identification or

tones generated by other analog devices or the PSTN.

Guide]
■ Integrated Convergence Services policy-based routing—This feature is
supported on SRX210 and SRX240 devices.
Policy-based routing allows calls to be routed through the media gateway instead
of originating or terminating there. In this case, routing is based on the incoming
and outgoing trunks, as opposed to based on a called party using a digit pattern
for the dialed number. You can use this feature to hairpin calls (send calls back
in the direction from which they came) on two trunks of the same or different
type. You can use policy-based routing with both the media gateway and the
survivable call server.
■ Integrated Convergence Services analog fax machines support—This feature
Integrated Convergence Services provides the following support for analog fax
machines:
■ Codec support to enable an analog fax to be sent over G.711 U-law encoding.
■ Support to directly connect an analog fax machine to an FXS port, referred
to as direct mapping, bypassing auto attendant.

Guide]
Intrusion Detection and Prevention (IDP)
■ IDP application-level DDoS protection—This feature is supported on SRX3400,

Application-level distributed denial-of-service (application-level DDoS) attacks
are different than traditional Level 3 and Level 4 DDoS attacks, such as a SYN
flood. From a Level 3 and Level 4 perspective, application DDoS attacks might
appear as legitimate transactions. Traditional Level 3 and Level 4 DDoS mitigation
solutions can only rate-limit both attacks and begin the application transactions,
instead of denying those from attackers.
The application-level DDoS IDP module uses application-level metrics to
differentiate between good and bad application requests and identify offending
source address and drop/deny requests from them. Based on the DDoS application
threshold user configuration, if thresholds are exceeded, session and ip-actions
will be applied on traffic from offending source addresses. The feature will protect
servers against DNS and HTTP application DDoS attacks.
■ L2 transparent mode for IDP—This feature is supported on SRX3400, SRX3600,
IDP is now supported in transparent mode. All IDP functions will remain the
same when transparent mode is enabled.
■ IDP SNMP MIB support—This feature is supported on SRX100, SRX210, SRX240,
and SRX650 devices.
The enterprise-specific IDP MIB,jnxJsIdpMIB, whose object ID is {jnxJsIdpRoot 1},

extends SNMP support to the following features:
■ Key monitoring and threshold-crossing traps
■ Attack-related monitoring and traps
■ IDP database update status and traps
[JUNOS Software Release Notes]

■ SSL key generation with cryptographic hardware acceleration for IDP SSL
decryption—This feature is supported on SRX3400, SRX3600, SRX5600, and
SRX5800 devices.
IDP hardware acceleration for SSL key generation and exchange support is added
to use existing hardware for SSL key generation and exchange for RSA keys less
than or equal to 2048 bits. All other processing, including bulk decrypting, is
done in software. Using the hardware accelerator, IDP SSL traffic throughputs
per SPU for the recommended policy are 1 Gbps for the 512-bit key, 750 Mbps
for the 1024-bit key, and 250 Mbps for the 2048-bit key.
For a client-to-server IDP policy, the bulk decryption is done only for the
client-to-server traffic data. To optimize the performance, the server-to-client
SSL traffic is not decrypted in this scenario.
■ UAC coordinated threat control (CTC)—This feature is supported on SRX3400,
Unified Access Control (UAC) can use attack information sent by IDP to decide
the access policy for traffic in which an attack has been detected. To use this
feature, you must configure the Infranet Controller to receive IDP log information.
You should also configure filters to limit the amount and type of log file data that
is received by the IC. To turn on the sending of IDP log files to the Infranet
Controller, enable IDP on the Infranet Controller.
[JUNOS Software Security Configuration Guide, Unified Access Control Administration
Guide]
IPsec
■ Dynamic VPN client—This feature is now supported on SRX100 devices in

addition to existing support on SRX210 and SRX240 devices.
■ UAC Layer 3 enforcement—This feature is supported on SRX210, SRX240,
SRX650, SRX3400, SRX3600, SRX5600, SRX5800, and J Series devices.
This feature adds IPsec support between the Infranet Controller, the Odyssey
Access Client, and the SRX Series device. IPsec is set up between the client and
the SRX Series device to ensure data privacy and integrity. When the client
authenticates to the Infranet Controller, it receives the IPsec policies from the
Infranet Controller and automatically sets up an IPsec tunnel to the SRX Series
device. When data is sent to the protected resource (behind the SRX Series
device), the data is encrypted using the policies.
Interfaces and Routing
■ Aggregated Ethernet interfaces—This feature is supported on SRX3400,

Link aggregation of Ethernet interfaces is defined in the IEEE 802.3ad standard.
The JUNOS Software implementation of 802.3ad balances traffic across the
member links within an aggregated Ethernet bundle based on the Layer 3
information carried in the packet. This implementation uses the same
load-balancing algorithm used for per-packet load balancing. Aggregated Ethernet
interfaces can use interfaces from different IOCs, Flex IOCs, or port modules.
Some of the advantages of using aggregated Ethernet Interfaces are as follows:

■ Increased bandwidth
■ Link availability
■ Standard-based
J-Web
■ J-Web user interface enhancements—This feature is supported on SRX Series

devices.
The J-Web user interface has been updated in JUNOS Release 10.0. The menu
system has been updated to provide more intuitive navigation to most pages.
For example, in the new Configure>Security>Zones interface page, the

following functionality is supported:
■ Zone configuration information
■ Zone interfaces configuration
■ Host Inbound Traffic option
In addition, the VPN features have been redesigned to improve usability.

[Junos OS Administration Guide for Security Devices, Junos OS Interfaces and Routing
Configuration Guide]
■ Single Commit on J-Web—This feature is supported on SRX100, SRX210,
In the J-Web interface, you can now commit the complete J-Web configuration
with a single commit action instead of committing configuration on each J-Web
configuration page. The following changes have been made for the single commit
feature:
■ There are three new elements in the top pane of the J-Web interface. These
J-Web elements appear only when you have made any changes to the
configuration.
■ Commit—Commits uncommitted configuration changes. The committed
changes are reflected in the active configuration file.
■ Compare—Displays the uncommitted changes by comparing the
candidate configuration with the active configuration on the device.
■ Discard—Discards the uncommitted changes from the candidate

configuration file.
■ When you click the OK, Apply, or Save buttons in the J-Web configuration
pages, the system does not commit the configuration; instead, it checks for
syntax errors (commit check) and saves the configuration in the candidate
configuration file.
■ Logout—After configuring the device, if you click Logout without committing

the configuration, a message appears asking if you want to commit the
configuration.
■ Login—When you log in to a device with an uncommitted configuration, a

message appears informing you of pending changes from the previous
session and giving you an opportunity to commit them.
These changes do not apply to the Initial Setup J-Web page and the Point and
Click CLI pages.
The candidate configuration file is shared across J-Web and CLI users; as a
consequence, if you commit the configuration using the CLI, any pending commits
from J-Web are committed as well.
[Junos OS CLI User Guide]
Management and Administration
■ System logging
■ Improved VPN error handling—This feature is supported on SRX3400,
VPN error handling performance has been improved significantly to handle

VPN behavior under less than optimal situations, such as the following:
■ Bursts of VPN activity
■ Configuration update synchronization occurring concurrently with other
VPN operations
■ Logging alternatives—This feature is supported on SRX Series and J Series

devices.
Users now have a choice between
■ Configuring the device to send all log messages through the Routing
Engine to a single server
or
■ Configuring the device to send an increased number of security messages
through a revenue port while sending other logging messages through
the Routing Engine to another server
The event logging mode, logging to a single server, is the default.

To set the device to use the stream mode in order to send more security
logs, enter the following at the CLI prompt:
user@host> set security log mode stream
[Junos OS Administration Guide for Security Devices]
Manual BIOS upgrade using JUNOS CLI
■ This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices.

For branch SRX Series devices, BIOS is made up of U-boot and JUNOS loader.
Apart from this SRX240 and SRX650 also have U-shell binary as part of the BIOS.
On SRX100, SRX210 and SRX240, there is support of Backup BIOS which
constitutes a backup copy of U-boot in addition to the active copy from which
the system generally boots up.
■
Table 3 on page 130 provides details of BIOS components supported for different
platforms.
Table 3: Manual BIOS Upgrade components
BIOS Components SRX100 SRX210 SRX240 SRX650
Active U-boot Yes Yes Yes Yes
Loader Yes Yes Yes Yes
U-shell Yes Yes
Backup U-boot Yes Yes Yes
Table 4 on page 130 provides you the CLI commands used for manual BIOS
upgrade.
Table 4: CLI Commands for Manual BIOS Upgrade
Active BIOS Backup BIOS
request system firmware upgrade re bios request system firmware upgrade re bios backup
Procedure for BIOS upgrade

1. Installing a jloader-srxsme package
1. Copy the jloader-srxme signed package to the device.
NOTE: Note that this package should be of the same version as that of the
corresponding JUNOS version; for example, on a device with a 10.0 JUNOS package
installed, the jloader-srxsme package should also be of version 10.0.
2. Install the package using the request system software add <path to
jloader-srxsme package> no-copy no-validate command.
root> request system software add /var/tmp/jloader-srxsme-10.0R4-signed.tgz

no-copy no-validate
Installing package '/var/tmp/jloader-srxsme-10.0R4-signed.tgz' ...

Verified jloader-srxsme-10.0R4.tgz signed by PackageProduction_10_0_0
Adding jloader-srxsme...
Available space: 427640 require: 2674
Mounted jloader-srxsme package on /dev/md5...
Saving state for rollback ...
root> show version
Model: srx240h
JUNOS Software Release [10.0R4]
JUNOS BIOS Software Suite [10.0R4]
NOTE: Installing the jloader-srxsme package puts the necessary images under
directory/boot.
2. Verifying that images for upgrade are installed

■ The show system firmware command can be used to get version of images
available for upgrade. The available version is printed under column
Available version. The user needs to verify that the correct version of
BIOS images available for upgrade.
root> show system firmware
Part Type Tag Current Available Status

version version
Routing Engine 0 RE BIOS 0 1.5 1.7 OK
Routing Engine 0 RE BIOS Backup 1 1.5 1.7 OK
Routing Engine 0 RE FPGA 11 12.3.0 OK
3. BIOS upgrade
Active BIOS:
1. Initiate the upgrade using the request system firmware upgade re bios
command.
root> request system firmware upgrade re bios
Part Type Tag

Current Available Status
version version
Perform indicated firmware upgrade ? [yes,no] (no) yes
Firmware upgrade initiated.
2. Monitor the status of upgrade using the show system firmware command.

version version
Routing Engine 0 RE BIOS 0 1.5 1.7 PROGRAMMING

version version
Routing Engine 0 RE BIOS 0 1.5 1.7 UPGRADED
SUCCESSFULLY

NOTE: The device must be rebooted for the upgraded active BIOS to take effect.
Backup BIOS:
1. Initiate the upgrade using the request system firmware upgade re bios
backup command.
root> request system firmware upgrade re bios backup
Part Type Tag

Current Available Status
version version
Perform indicated firmware upgrade ? [yes,no] (no) yes
Firmware upgrade initiated.
2. Monitor the status of upgrade using the show system firmware command.
Part Type TagCurrent Available Status

version version
Routing Engine 0 RE BIOS Backup 1 1.5 1.7 PROGRAMMING

version version
Routing Engine 0 RE BIOS Backup 1 1.7 1.7 UPGRADED
SUCCESSFULLY
■ Configuring simple filters and policers—This feature is supported on SRX3400,

To handle oversubscribed traffic in the SRX3400, SRX3600, SRX5600, and

SRX5800 devices, you can configure simple filters and policing. The simple filter
functionality comprises of the following:
■ Classifying packets according to configured policies
■ Taking appropriate actions based on the results of classification
NOTE: For SRX5600 and SRX5800 devices, the simple filter or policing actions can
be applied only to logical interfaces residing in an SRX5000 line Flex I/O Card (IOC),
because only an SRX5000 line Flex IOC supports the simple filter and policing features
on SRX5600 and SRX5800 devices.
■ Ingress logical interface policing—This feature is supported on SRX5600 and

SRX5800 devices.
Policers allow you to limit traffic of a certain class to a specified bandwidth and
burst size. You can use policers to limit the amount of traffic passing into or out
of an interface. JUNOS Release 10.0 supports only inbound (ingress) interface
policers. On SRX5600 and SRX5800 devices, two IOCs (40X1 Gigabit Ethernet
and 4X10 Gigabit Ethernet) are supported. A simple filter feature is available for
applying a simple filter or policing actions to logical interfaces residing in an
SRX5000 line Flex IOC on SRX5600 and SRX5800 devices.
Security
■ Network Address Translation (NAT)

■ Persistent NAT—This feature is now supported on SRX3400, SRX3600,
SRX5600, and SRX5800 devices in addition to existing support on SRX100,
NOTE: Persistent NAT is sometimes referred to as cone NAT. The term cone NAT
has been replaced by persistent NAT by the IETF.
■ Removing persistent NAT query bindings—This feature is now supported

on SRX3400, SRX3600, SRX5600, and SRX5800 devices in addition to
existing support on SRX100, SRX210, SRX240, SRX650, and J Series devices.
When all sessions of a persistent NAT binding are gone, the binding remains
in a query state in the SRX Series device’s memory for a specified inactivity
timeout period. The query binding is automatically removed from memory
when the inactivity timeout period expires (the default is 5 minutes). In
JUNOS Release 10.0, you can explicitly remove all or specific persistent NAT
query bindings with the clear security nat source persistent-nat-table command.
NOTE: This command does not affect persistent NAT bindings where there are active
sessions.
Unified Threat Management (UTM)
■ Juniper local Web filtering—This feature is supported on SRX100, SRX210,

SRX240, SRX650, and J Series devices.
With local Web filtering, the firewall intercepts every HTTP request in a TCP
connection and extracts the URL. The decision making is done on the device
after it identifies if the requested URL is in the user-defined url-blacklist or
url-whitelist category. If the URL is in the url-blacklist, the request is blocked; if
it is in the url-whitelist, the request is permitted. If the URL is not in either list,
the defined default action occurs (block, log-and-permit, or permit). You can
permit or block access to a requested site by binding a Web filtering profile to
a firewall policy. Local Web filtering provides basic Web filtering without requiring
an additional license or external category server.
■ UTM WELF support—This feature is supported on SRX100, SRX210, SRX240,
and SRX650 devices.
Support has been added to the Unified Threat Management feature for sending
log file information in the WebTrends Enhanced Log file Format (WELF). The
WELF Reference defines the WebTrends industry standard log file exchange
format. Any system logging to this format will be compatible with Firewall Suite
2.0 and later, Firewall Reporting Center 1.0 and later, and Security Reporting
Center 2.0 and later. To configure logging in the WELF format, use the format
statement from the [set security log source-address stream] hierarchy.
VPNs
■ Dynamic VPN client/server enhancements—This feature is supported on

Several enhancements have been added to make VPN configuration easier. Those
enhancements include additional field diagnostics and statistics, and configuration
warnings. Three new operational commands have been added that show client
version information, user information, and user tunnel table information. Use
the dynamic-vpn client version, dynamic-vpn users, and dynamic-vpn users terse
statements from the [show security] hierarchy.
Support for chassis cluster mode—When the device is put into chassis cluster
mode, dynamic VPN failover is supported. The following information is relevant
for VPN chassis cluster functionality:
■ If there is no client configuration information available on the device when
a failover occurs, the setup client (on the remote access device) detects that
the client configuration information is missing and displays an appropriate
error message.
■ If there is an inconsistency with the client configuration values on the device,
the connection fails. The connection will continue to fail until the information
is provided correctly.
[JUNOS CLI Reference Guide]

■ VPN routing and forwarding (VRF)—This feature is now supported on SRX
Series devices in addition to existing support on J Series devices.
VPN routing and forwarding (VRF) for a Layer 3 VPN implementation allows
multiple instances of a routing table to coexist within the same device at the
same time. Because the routing instances are independent, the same or
overlapping IP addresses can be used without conflicting with each other.
The real-time performance monitoring (RPM) probes specified to a VRF table
will be handled by FWDD-RT; therefore providing more accurate results. This
feature supports RPM ICMP and UDP probes configured with routing instances
of type VRF.TCP probes are not supported for JUNOS Release 10.0.
[Junos OS Administration Guide for Security Devices]
Hardware Features—SRX100 Services Gateways
Dual-Root Partitioning Scheme
JUNOS Release 10.0 supports dual-root partitions on SRX100 devices. Dual-root

partitioning allows the device to remain functional if there is file system corruption
and facilitates easy recovery of the corrupted file system.
For more details on upgrading to JUNOS Release 10.0, see the section “Dual-Root
Partitioning Scheme Documentation for SRX Series Services Gateways” on page 193.
Hardware Features—SRX210 and SRX240 Services Gateways
4-Port FXO Mini-Physical Interface Module
This feature is supported on SRX210 and SRX240 devices with Integrated Convergence
Services and cannot be used in standalone mode.
The 4-Port Foreign Exchange Office (FXO) Mini-Physical Interface Module (Mini-PIM)
provides trunk lines and simultaneous calls on the public switched telephone networks
(PSTN). The 4-Port FXO Mini-PIM is supported on the SRX210 Services Gateway with
Integrated Convergence Services.
The 4-Port FXO Mini-PIM adds four more trunk lines to the Session Initiation Protocol
(SIP) media gateway. The 4-Port FXO Mini-PIM uses an RJ-11 connector type cable.
The following key features are supported on the 4-Port FXO Mini-PIM:
■ Highly programmable and globally compliant foreign exchange office analog
interface
■ Global design to support software programmable country-specific parameters
■ International safety standard
■ Caller ID support
■ Pulse dialing support
■ Parallel handset detection
■ Line voltage and loop current monitor to detect the parallel phones
■ Programmable line interface for
■ AC termination
■ DC termination
■ Ringer impedance
■ Ring detect threshold
2-Port FXS/2-Port FXO Mini-Physical Interface Module
This feature is supported on SRX210 and SRX240 devices with Integrated Convergence
Services and cannot be used in standalone mode.
The 2-Port Foreign Exchange Subscribers (FXS)/2-Port Foreign Exchange Office (FXO)
Mini-Physical Interface Module (Mini-PIM) provides analog lines and simultaneous
calls on the public switched telephone networks (PSTN). The 2-Port FXS/2-Port FXO
Mini-PIM is supported on the SRX210 Services Gateway with Integrated Convergence
Services.
The 2-Port FXS/2-Port FXO uses an RJ-11 connector type cable.
NOTE: The 2-Port FXS/2-Port FXO Mini-PIM does not support the failover relay
between any of the FXS and FXO ports.
The following key features are supported on the 2-Port FXS/2-Port FXO Mini-PIM:
■ Highly programmable and globally compliant FXO and FXS interface
■ Global design to support software programmable country-specific parameters
■ International safety standard
■ Caller ID support
■ Pulse dialing support
■ Parallel handset detection
■ Line voltage and loop current monitor to detect the parallel phones
■ Programmable line interface for:
■ AC termination
■ DC termination
■ Ringer impedance
■ Ring detect threshold
G.SHDSL Mini-Physical Interface Module
This feature is supported on SRX210 and SRX240 devices.
The Global.standard High-Bit-Rate Digital Subscriber Line (G.SHDSL) Mini-Physical

Interface Module (Mini-PIM) provides the physical connection to DSL network media
types.
The G.SHDSL Mini-PIM is compatible with the ITU-T G.991.2 standards.
The G.SHDSL Mini-PIM can be configured to operate in the following modes:

■ 4X2-wire (4-port 2-wire)
The G.SHDSL Mini-PIM can operate in any of the following annexes:

■ Annex A
■ Annex B
■ Annex G
■ Annex F
The G.SHDSL Mini-PIM provides the following key features:

■ 2-wire mode, 4-wire mode, and 8-wire operating mode support
■ Virtual circuits per Mini-PIM (30 maximum)
■ ATM-over-G.SHDSL framing
■ ATM CoS support
■ Dying gasp support
■ Wetting current support
■ Maximum MTU size of 9180 bytes
■ Noise margin support
■ Point-to-Point Protocol over ATM and PPPoE over ATM encapsulation support
JUNOS Release 10.0 supports dual-root partitions on SRX210 and SRX240 devices.
Dual-root partitioning allows the device to remain functional if there is file system
corruption and facilitates easy recovery of the corrupted file system.
For more details on upgrading to JUNOS Release 10.0, see the section ““Dual-Root
Partitioning Scheme Documentation for SRX Series Services Gateways” on page 193”.

Convergence Services (Available in North America Only)
The existing functionality on the SRX210 Services Gateway with Integrated

Convergence Services is enhanced to include the voice functionality, which provides
complete functionality and flexibility for delivering secure, reliable data and voice
services over IP, along with multiple interfaces that support WAN and LAN
connectivity. This product is available in North America only.
Integrated Convergence Services runs on SRX210 devices. The SRX210 base system
includes Foreign Exchange Station (FXS) ports and Foreign Exchange Office (FXO)
ports on the base system. The system also includes expansion slots in which you
can configure Mini-Physical Interface Modules (Mini-PIMs) to increase the number

of lines and users. The system’s digital signal processing (DSP) unit provides real-time
voice processing resources critical to VoIP and offloads these tasks from the main
CPU.
Besides Session Initiation Protocol (SIP)/analog voice support, additional features

include 3G Wireless support, digital subscriber line access multiplexer (DSLAM),
flexible data/voice, and Power over Ethernet (PoE).
The SRX210 Services Gateway with Integrated Convergence Services has redundant
and resilient hardware. Table 5 on page 141 provides the specifications for the SRX210
Services Gateway with Integrated Convergence Services.
Table 5: SRX210 Services Gateway with Integrated Convergence Services

Specifications
Description Value
Dimensions (H x W x D) 1.73 in. x 11.1 in. x 7.04 in.
44 mm x 282 mm x 179 mm
Chassis weight 3.76 lb. (1.70 kg)
Altitude No performance degradation to 6561 ft (2000 m)
Temperature Normal operation ensured in temperature range of 32°F (0°C) to

104°F (+40°C)
Nonoperating storage temperature in shipping container: –40°F

(–40°C) to 158°F (70°C)
Noise level Less than 70 dB(A) as per EN ISO 7779
Relative humidity (Operating) 5% to 90% noncondensing
Table 6 on page 141 provides information about the hardware features of the SRX210
Table 6: SRX210 Services Gateway with Integrated Convergence Services Hardware

Features
Feature Description
Memory ■ DDR: 1 GB
■ Boot flash: 4 MB
■ Internal flash: 2 GB
AC input voltage 100 to 240 VAC
Power supply adapter 150 watts

Features (continued)
Feature Description
Fast Ethernet Eight ports on the front panel provide LAN and WAN connectivity
to hubs, switches, local servers, and workstations with link speeds
of 10/100 Mbps.
Universal serial bus (USB) One port on the front panel supports a USB storage device that
can function as a secondary boot device in the event of internal
flash failure. The USB port also provides an interface for
communicating with peripherals such as USB storage devices and
USB storage-device adapters.
Console One port on the front panel functions as a management port for
directly logging into a device to configure it by using the CLI.
Voice interface The following voice interface ports provide voice functionality:
■ Two Foreign Exchange Station (FXS) ports on the front panel
provide an interface for connecting analog phones, fax
machines, or similar devices.
■ Two Foreign Exchange Office (FXO) ports on the front panel
provide direct connection to the telephone exchange or public
switched telephone network (PSTN) central office (CO).
Mini-PIM One slot on the front panel supports the following Mini-Physical
Interface Modules to provide LAN and WAN functionality, along
with access to the T1, E1, Gigabit Ethernet, ADSL, G.SHDSL, serial,
and voice interfaces:
■ T1/E1 Mini-PIM
■ 1-Port Small Form-factor Pluggable (SFP) Mini-PIM
■ ADSL2+ Mini-PIM
■ Serial Mini-PIM
■ 4-Port FXO Mini-PIM
■ 2-Port FXO/2-Port FXS Mini-PIM
■ G.SHDSL Mini-PIM
[SRX210 Services Gateway Hardware Guide]

Convergence Services (Available in North America Only)
JUNOS Software for the SRX240 Services Gateway with Integrated Convergence
Services integrates Juniper Networks’ world-class network security with its robust
routing capabilities.
The existing functionality on the SRX240 Services Gateway with Integrated

Convergence Services is enhanced to include voice functionality, which provides
complete functionality and flexibility for delivering secure, reliable data and voice
services over IP, along with multiple interfaces that support WAN and LAN
connectivity. Besides Session Initiation Protocol (SIP)/analog voice support, additional
features include 3G Wireless support, digital subscriber line access multiplexer

(DSLAM), and Power over Ethernet (PoE). This product is available in North America
only.
Integrated Convergence Services runs on the SRX240 devices. The SRX240 base
system includes Foreign Exchange Station (FXS) ports and Foreign Exchange Office
(FXO) ports. The system also includes expansion slots in which you can configure
Mini-Physical Interface Modules (Mini-PIMs) to increase the number of lines and
users. The system’s digital signal processing (DSP) unit provides real-time voice
processing resources critical to VoIP and offloads these tasks from the main CPU.
The SRX240 Services Gateway with Integrated Convergence Services has redundant
and resilient hardware. Table 7 on page 143 provides the SRX240 Services Gateway
specifications.
Table 7: SRX240 Services Gateway with Integrated Convergence Services

Specifications
Description Value
Dimensions (H x W x D) 17.5 in. x 1.73 in. x 15 in.
(444 mm x 44 mm x 381 mm)
Chassis weight 12.5 lb. (5.67 kg)
Altitude No performance degradation to 10,000 ft (3048 m)
Temperature Normal operation ensured in temperature range of 32°F (0°C) to

104°F (+40°C)
Nonoperating storage temperature in shipping container: –40°F

(–40°C) to 158°F (70°C)
Relative humidity (Operating) 5% to 90% noncondensing
Table 8 on page 143 provides information about the hardware features of the SRX240

Features
Feature Description
Memory ■ DDR: 1 GB
■ NAND flash: 4 MB
■ Internal flash: 1 GB
AC input voltage 100 to 240 VAC
Power supply adapter 360 watts

Features (continued)
Feature Description
Gigabit Ethernet Sixteen ports on the front panel function as front-end network
ports and provide LAN and WAN connectivity to hubs, switches,
local servers, and workstations with link speeds of 10/100 Mbps.
All Gigabit Ethernet ports support PoE.
Universal serial bus (USB) Two ports on the front panel support a USB storage device that
can function as a secondary boot device in the event of internal
flash failure. The USB port also provides an interface for
communicating with peripherals such as USB storage devices and
USB storage-device adapters.
Console One port on the front panel functions as a management port for
directly logging into a device to configure it by using the CLI.
Voice interface The following voice interface ports provide voice functionality:
■ Two Foreign Exchange Station (FXS) ports on the back panel
provide an interface for connecting analog phones, fax
machines, or similar devices.
■ Two Foreign Exchange Office (FXO) ports on the back panel
provide direct connection to the telephone exchange or public
switched telephone network (PSTN) central office (CO).
Mini-PIM Four slots on the front panel supports the following Mini-Physical
Interface Modules to provide LAN and WAN functionality, along
with access to the T1, E1, Gigabit Ethernet, ADSL, serial, and voice
interfaces:
■ T1/E1 Mini-PIM
■ 1-Port Small Form-factor Pluggable (SFP) Mini-PIM
■ ADSL2+ Mini-PIM
■ Serial Mini-PIM
■ 4-Port FXO Mini-PIM
■ 2-Port FXO/2-Port FXS Mini-PIM
■ G.SHDSL Mini-PIM
[SRX240 Services Gateway Hardware Guide]
Hardware Features—SRX650 Services Gateways
DC Power Supply
In addition to the 645-W AC power supply including PoE power, the SRX650 Services
Gateway now supports a 645-W DC power supply including PoE power. The SRX650
Services Gateway uses either one AC or one DC power supply unit (PSU). The services
gateway is equipped with one AC power supply; a second PSU is optional (sold
separately).
A second PSU can be used to meet power requirements exceeding the wattage
provided by a single PSU in a nonredundant configuration by using two power supplies
in a system using more power than a single PSU provides. A second AC or DC power
supply can be used with its matching type of power supply to provide redundancy
and load-sharing to the services gateway and its components. If one power supply
fails or is removed, the remaining power supply redistributes the electrical load
without interruption. The services gateway reassesses the power required to support
its configuration and issues errors if the available power is insufficient.
CAUTION: Do not mix AC and DC power supplies within the same services gateway.
Damage to the device might occur.
All power supplies are hot-swappable and support single or dual redundant power
supply versions. Each power supply is cooled by the system’s fans. The power supplies
produce and distribute different output voltages to the services gateway components
according to their voltage requirements.
The 645-W DC power supply provides the following output/consumption:

■ 390 W @12 V
■ 255 W @PoE on a single power supply, or with redundancy using the two power
supply option
■ 510 W @PoE using the two power supply option operating as nonredundant
NOTE: Using the two power supply option operating as nonredundant for up to 510
W @PoE power, the administrator has the ability to prioritize the PoE ports that will
receive power if an outage should occur to either the power source or to one of the
power supplies.
Resilient Partitioning
The SRX650 Services Gateway supports dual-root partitioning designed to provide:

■ Constant ability for the services gateway to boot and remain accessible over
WAN
■ High level of resilience against file system corruptions and sudden power outages
of the services gateway
The SRX650 Services Gateway can boot from the following storage media (in order
of priority):
■ Internal CompactFlash card (default; always present)
■ External CompactFlash card (alternate)
■ USB storage device (alternate)
The dual-root partitions allow the SRX650 devices to remain functional if there is file
system corruption and facilitates easy recovery of the corrupted file system.
The dual-root partitioning scheme keeps the primary and backup JUNOS Software
images in two independently bootable root partitions. If the primary root partition
becomes corrupted, the system will be able to boot from the backup JUNOS Software
image located in the other root partition and remain fully functional.
When the SRX650 device powers on, it tries to boot the JUNOS Software from the
default storage media. If the device fails to boot from the default storage media, it
tries to boot from the alternate storage media. With the dual-root partitioning scheme,
the SRX650 device first tries to boot the JUNOS Software from the primary root
partition and then from the backup root partition on the default storage media. If
both primary and backup root partitions of a media fail to boot, then the device tries
to boot from the next available type of storage media. The SRX650 device remains
fully functional even if it boots the JUNOS Software from the backup root partition
of storage media.
NOTE: SRX650 devices that ship from the factory with JUNOS Release 10.0 are
formatted with the dual-root partitioning scheme.
Existing SRX650 devices that are running JUNOS Release 9.6 or earlier use the
single-root partitioning scheme. While upgrading these devices to JUNOS Release
10.0, you can choose to format the storage media with dual-root partitions (strongly
recommended) or retain the existing single-root partitioning.
For more details on upgrading to JUNOS Release 10.0, see the section “Dual-Root
Partitioning Scheme Documentation for SRX Series Services Gateways” on page 193.
Related Topics ■ Known Limitations in JUNOS Release 10.0 for SRX Series Services Gateways and
Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX Series Services
Gateways and J Series Services Routers
The following current system behavior, configuration statement usage, and operational
mode command usage might not yet be documented in the JUNOS Software
documentation:
Chassis Cluster
■ On SRX650 devices in chassis cluster mode, the CT1/E1 PIC goes offline and
does not come online.
146 ■ Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services
Routers
Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
■ In a chassis cluster configuration on an SRX100, SRX210, SRX240, or SRX650

device, the default values of the heartbeat-threshold and heartbeat-interval options
in the [edit chassis cluster] hierarchy are 8 beats and 2000 ms respectively. These
values cannot be changed on these devices.
Command-Line Interface (CLI)
■ On SRX Series devices, the show security monitoring fpc 0 command is now
available.
The output of this CLI command on SRX Series devices differs from previous
implementations on other devices. Note the following sample output:
show security monitoring fpc 0
FPC 0
PIC 0
CPU utilization : 0 %
Memory utilization : 65 %
Current flow session : 0
Max flow session : 131072
NOTE: When SRX Series devices operate in packet mode, flow sessions will not be
created and current flow session will remain zero as shown in the sample output
above. The maximum number of sessions will differ from one device to another. On
SRX3400, SRX3600, SRX5600, AND SRX5800 devices, the output will include two
more lines: SPU current cp session and SPU max cp session.
■ On SRX210 devices with Integrated Convergence Services, TDM configuration

change might interrupt existing TDM calls if any MPIMs are configured. The voice
calls through the MPIM do not work. Run the CLI restart rtmd command after
making a configuration change to the MPIM ports.
■ On SRX210 devices with Integrated Convergence Services, registrations are not
working when PCS is configured and removed thorough CLI. The dial tone
vanishes when the analog station calls the SIP station. As a workaround, either
run the rtmd restart command or restart the device.
■ On SRX5600 and SRX5800 devices, the set security end-to-end-debug CLI hierarchy
has been changed to set security datapath-debug.
Configuration
■ J Series devices no longer allow a configuration in which a tunnel's source or

destination address falls under the subnet of the same logical interface’s address.
Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services
Routers ■ 147
■ on SRX100, SRX210, SRX240 and , SRX650 devices, the current JUNOS default
configuration is inconsistent to the one used in SSGs, thus creating multiple
problems when migrating to SRX devices.
■ The ge-0/0/0 interface should be configured as the Untrust port (with DHCP
client enabled).
■ The rest of the on-board ports should be bridged together, with a VLAN IFL
and DHCP server enabled (where applicable).
■ Default policies should allow trust->untrust traffic
■ Default NAT rules should do interface-nat for all trust->untrust traffic
■ DNS/Wins paramaters should be passed from server to client and, if not

available, we should pre-configure a DNS server (required for download of
security packages).
■ The default values for IKE and IPsec security association (SA) lifetimes for standard
VPNs have been changed in this release:
■ The default value for the lifetime-seconds configuration statement at the [edit
security ike proposal proposal-name] hierarchy level has been changed from
3600 seconds to 28,800 seconds.
■ The default value for the lifetime-seconds configuration statement at the [edit
security ipsec proposal proposal-name] hierarchy level has been changed from
28,800 seconds to 3600 seconds.
Flow and Processing
■ SRX650 devices now support 2-GB DRAM.

■ On SRX Series devices, the factory default for the maximum number of backup
configurations allowed is 5. Therefore, you can have one active configuration
and a maximum of five rollback configurations. Increasing this backup
configuration number will result in increased memory usage on disk and
increased commit time.
To modify the factory defaults, use the following commands:
root@host# set system max-configurations-on-flash number
root@host# set system max-configuration-rollbacks number
where max-configurations-on-flash indicates backup configurations to be stored

in the configuration partition and max-configuration-rollbacks indicates the
maximum number of backup configurations.
■ On J Series devices, the following configuration changes must be done after
rollback or upgrade from JUNOS Release 10.0 to 9.6 and earlier releases.
■ Rename lsq-0/0/0 to ls-0/0/0 in all its occurrences.
■ Remove fragmentation-map from the [class-of-service] hierarchy level and
from [class-of-service interfaces lsq-0/0/0], if configured.
■ Remove multilink-max-classes from [ls-0/0/0 unit 0], if configured.
Routers
■ Remove link-layer-overhead from [ls-0/0/0 unit 0], if configured.
■ If the LFI forwarding class is mapped to no-fragmentation in fragmentation-map

and the configuration hierarchy is enabled on lsq-0/0/0 in JUNOS
Release10.0, then
■ Add interleave-fragments under [ls-0/0/0 unit 0]
■ Adjust classifier configured for LFI on lsq-0/0/0 under [class-of-service]
to classify packets to Q2
If the aforementioned instructions are not followed, the bundle will be incorrectly
processed.
Hardware
■ On SRX210 devices with Integrated Convergence Services, the power on/off

button does not work consistently, which prevents automatic startup.
■ On SRX210 devices with Integrated Convergence Services, when an FXS to FXO
call is answered during the first ring, there is a slight delay of 3–5 seconds before
the audio starts. The called party hears the audio a few seconds after the call is
established during SIP/TDM calls. However, if the FXS to FXO call is answered
after a couple of rings, the voice path between the parties is established
immediately.
■ On SRX210 devices with Integrated Convergence Services, local FXS or FXO
lines are not getting a hang-up signal when the WAN link goes down during a
sunny day call with a local SIP phone.
■ On SRX210 devices with Integrated Convergence Services, the average time
taken to play the dial tone before setting up a call is more than 800 ms. On
average, the dial tone delay should not be more than 300 ms.
■ On SRX210 devices with Integrated Convergence Services, when an FXS to FXO
or SIP to FXO call is made, dialed digits on the FXS (or SIP) phone are heard on
the FXO side with some distortion. However, digits pressed on the FXO side are
heard without distortion on the FXS (or SIP) side.
■ On SRX210 devices with Integrated Convergence Services, in all call combinations
of SIP/FXS/FXO calls, echo canceller comfort noise is noticeable in some call
scenarios.
■ On SRX210 devices with Integrated Convergence Services, sometimes the dial
tone on FXS lines is not very clearly generated. It is interrupted by a modem init
type of noise.
■ On SRX Series devices, to minimize the size of system logs, the default logging
level in the factory configuration has changed from any any to any critical.
■ On SRX3000 and SRX5000 line devices, the set protocols bgp family inet flow and
set routing-options flow CLI statements are no longer available, because BGP flow
spec functionality is not supported on these devices.
Routers ■ 149
■ On SRX100, SRX210, SRX240, and SRX650 devices, the autoinstallation

functionality on an interface enables a DHCP client on the interface and remains
in the DHCP client mode. In previous releases, after a certain period, the interface
changed from being a DHCP client to a DHCP server.
■ On SRX Series and J Series devices with compressed DFA, the application
signature will have a different file name, /var/db/idpd/bins/compressed_ai.bin
instead of the current name /var/db/idpd/bins/compiled_ai.bin.
■ On SRX5600 and SRX5800 devices, while running commands in IDP, ensure
that you provide the service field values for custom attack definitions in lowercase.
In the following example, the protocol service field value udp is specified in
lowercase:
set security idp custom-attack temp severity info attack-type signature context packet
direction any pattern .* protocol udp destination-port match equal value 1333
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, for brute force and
time-binding-related attacks, the logging is to be done only when the match count
is equal to the threshold. That is, only one log is generated within the 60-second
period in which the threshold is measured. This process prevents repetitive logs
from being generated and ensures consistency with other IDP platforms like
IDP-standalone.
J-Web
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, to add the Predefined

Attacks and Predefined Attack Groups, users do not need to type the attack
names. Instead, users can select attacks from the Predefined Attacks and
Predefined Attack Group lists and click the left arrow to add them.
■ On SRX100, SRX210, SRX240, and SRX650 devices, the LED status (Alarm, HA,
ExpressCard, Power Status, and Power) shown in the front panel for Chassis
View does not replicate the exact status of the device.
Routers
■ On SRX5600 and SRX5800 devices running a previous release of JUNOS Software,

security logs were always time stamped using the UTC time zone. In JUNOS
Release 10.0, you can use the set system time-zone CLI command to specify the
local time zone that the system should use when time stamping the security
logs. If you want to time stamp logs using the UTC time zone, use the set system
time-zone utc and set security log utc-timestamp CLI statements.
Security
■ J Series devices do not support the authentication order password radius or

password ldap in the edit access profile profile-name authentication-order command.
Instead, use the order radius password or ldap password.
WLAN
■ While configuring the AX411 Access Point on your SRX devices, you must enter
the WLAN admin password using the set wlan admin-authentication password
command. This command prompts for the password and the password entered
is stored in encrypted form.
NOTE:
■ Without wlan config option enabled, the AX411 Access Points will be managed
with the default password.
■ Changing the wlan admin-authentication password when the wlan subsystem option
is disabled might result in mismanagement of Access Points . You might have
to power cycle the Access Points manually to avoid this issue.
■ The SRX Series devices that are not using the AX411 Access Point can optionally
delete the wlan config option.
■ Accessing the AX411 Access Point through SSH is disabled by default. You can
enable the SSH access using the set wlan access-point <name> external system
services enable-ssh command.
Routers ■ 151
Known Limitations in JUNOS Release 10.0 for SRX Series Services Gateways and J Series
Services Routers
[accounting-options] Hierarchy
■ On SRX210 and SRX240 devices, the accounting, source-class, and

destination-class statements in the [accounting-options] hierarchy level are not
supported.
AX411 Access Point
■ On SRX100 devices, there are command-line interface (CLI) commands and

J-Web tabs for Wireless LAN configurations related to the AX411 Access Point.
However, at this time the SRX100 devices do not support the AX411 Access
Point.
Chassis Cluster
On SRX Series and J Series devices, the following features are not supported when
chassis clustering is enabled on the device:
■ All packet-based protocols, such as MPLS, Connectionless Network Service (CLNS),
and IP version 6 (IPv6)
■ Any function that depends on the configurable interfaces:
■ lsq-0/0/0—Link services Multilink Point-to-Point Protocol (MLPPP), Multilink
Frame Relay (MLFR), and Compressed Real-Time Transport Protocol (CRTP)
■ gr-0/0/0—Generic routing encapsulation (GRE) and tunneling
■ ip-0/0/0—IP-over-IP (IP-IP) encapsulation
■ pd-0/0/0, pe/0/0/0, and mt-0/0/0—All multicast protocols
■ lt-0/0/0—Real-time performance monitoring (RPM)
■ WXC Integrated Services Module (WXC ISM 200)

■ ISDN BRI
■ Layer 2 Ethernet switching
The factory default configuration for SRX100, SRX210, and SRX240 devices
automatically enables Layer 2 Ethernet switching. Because Layer 2 Ethernet
switching is not supported in chassis cluster mode, for these devices, if you use
the factory default configuration, you must delete the Ethernet switching
configuration before you enable chassis clustering.
CAUTION: Enabling chassis clustering while Ethernet switching is enabled is not a

supported configuration. Doing so might result in undesirable behavior from the
devices, leading to possible network instability.
152 ■ Known Limitations in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
Known Limitations in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
The default configuration for other SRX Series devices and all J Series devices
does not enable Ethernet switching. However, if you have enabled Ethernet
switching, be sure to disable it before enabling clustering on these devices too.
SRX Series devices have the following limitations:

■ On SRX Series devices, multicast traffic streams are not supported on chassis
clusters.
■ On SRX3000 and SRX5000 line chassis clusters, screen statistics data can be
gathered on the primary device only.
■ On SRX Series devices, the IDP feature is not supported in active/active chassis
clustering.
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, in-service software
upgrade (ISSU) does not support version downgrading. That is, ISSU does not
support running an ISSU install of a JUNOS Software version that is earlier than
the currently installed version.
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices in a chassis cluster,
only four QoS queues are supported per interface.
■ On SRX240 devices in a chassis cluster, the reth interface cannot be used as the
underlying interface for Point-to-Point Protocol over Ethernet (PPPoE.)
■ Only SRX3400, SRX3600, SRX5600, and SRX5800 devices support IPv6
configuration over the integrated routing and bridging (IRB) interface. Other SRX
Series devices and J Series devices do not.
■ On SRX3400, SRX3600, SRX5600 and SRX5800 devices, only redundant Ethernet
interfaces (reth) are supported for IKE external interface configuration in IPSec
VPN. Other interface types can be configured but IPSec VPN may not work.
J Series devices have the following limitations:

■ A Fast Ethernet port from a 4-port Ethernet PIM cannot be used as a fabric link
port in a chassis cluster.
■ On devices in chassis cluster mode, packet capture is not supported on the reth
interface.
■ In large chassis cluster configurations on SRX3400 or SRX3600 devices, you
need to increase the wait time before triggering failover. In a full-capacity
implementation, we recommend increasing the wait to 8 seconds by modifying
heartbeat-threshold and heartbeat-interval values in the [edit chassis cluster]
hierarchy.
The product of the heartbeat-threshold and heartbeat-interval values defines the
time before failover. The default values (heartbeat-threshold of 3 beats and
heartbeat-interval of 1000 milliseconds) produce a wait time of 3 seconds.
To change the wait time, modify the option values so that the product equals
the desired setting. For example, setting the heartbeat-threshold to 8 and
maintaining the default value for the heartbeat-interval (1000 milliseconds) yields
a wait time of 8 seconds. Similarly, setting the heartbeat-threshold to 4 and the
heartbeat-interval to 2000 milliseconds also yields a wait time of 8 seconds.
Known Limitations in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers ■ 153
Command-Line Interface (CLI)
On SRX210 and SRX240 devices, J-Web crashes if more than nine users log into the
device via the CLI.
The number of users allowed to access the device is limited as follows:

■ For SRX210 devices: four CLI users and three J-Web users
■ For SRX240 devices: six CLI users and five J-Web users
Dynamic VPN
SRX100, SRX210, and SRX240 devices have the following limitations:

■ The IKE configuration for the dynamic VPN client does not support the
hexadecimal preshared key.
■ The dynamic VPN client IPsec does not support the Authentication Header (AH)
protocol and the Encapsulating Security Payload (ESP) protocol with NULL
authentication.
■ When you log in through the Web browser (instead of logging in through the
dynamic VPN client) and a new client is available, you are prompted for a client
upgrade even if the force-upgrade option is configured. Conversely, if you log in
using the dynamic VPN client with the force-upgrade option configured, the client
upgrade occurs automatically (without a prompt).
Flow and Processing
■ Maximum concurrent SSH, Telnet, and Web sessions—On SRX210, SRX240,

and SRX650 devices, the maximum number of concurrent sessions is as follows:
Sessions SRX210 SRX240 SRX650
ssh 3 5 5
telnet 3 5 5
Web 3 5 5
NOTE: These defaults are provided for performance reasons.
■ On SRX210 and SRX240 devices, for optimized efficiency, we recommend that

you limit use of CLI and J-Web to the following numbers of sessions:
Device CLI J-Web Console
SRX210 3 3 1
SRX240 5 5 1
■ On SRX100 devices, Level 3 control protocols (OSPF, using multicast destination

MAC address) on a VLAN Level 3 interface work only with access ports.
■ On SRX210, SRX240, J2320, J2350, J4350, and J6350 devices, broadcast TFTP
is not supported when flow is enabled on the device.
■ On SRX5800 devices, network processing bundling is not supported in Layer 2
transparent mode.
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, downgrading is not
supported in low-impact in-service software upgrade (ISSU) chassis cluster
upgrades.
■ Equal-cost multipath (ECMP) does not work with NAT/tunnelling when transit
traffic is passed.
fwauth Security
■ On SRX devices, high memory utilization for fwauthd is observed after sending
fwauth failure users for an extended duration.
Hardware
This section covers filter and policing limitations.

■ On SRX3400 and SRX3600 devices, the following feature is not supported by a
simple filter:
■ Forwarding class as match condition
■ On SRX3400 and SRX3600 devices, the following features are not supported by
a policer or a three-color-policer:
■ Color-aware mode of a three-color-policer
■ Filter-specific policer
■ Forwarding class as action of a policer
■ Logical interface policer
■ Logical interface three-color policer
■ Logical interface bandwidth policer
■ Packet loss priority as action of a policer
■ Packet loss priority as action of a three-color-policer
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the following features

are not supported by a firewall filter:
■ Policer action
■ Egress FBF
■ FTF
■ SRX3400 and SRX3600 devices have the following limitations of a simple filter:
■ In the packet processor on an IOC, up to 100 logical interfaces can be applied
with simple filters.
■ In the packet processor on an IOC, the maximum number of terms of all
simple filters is 4000.
■ In the packet processor on an IOC, the maximum number of policers is

4000.
■ In the packet processor on an IOC, the maximum number of

three-color-policers is 2000.
■ The maximum burst size of a policer or three-color-policer is 16 MB.
■ On SRX650 devices, the CT1/E1 PIC does not work in 9.6R1. This issue is resolved
in JUNOS Release 9.6R2 and JUNOS Release 10.0, but if you roll back to the
9.6R1 image, this issue is still seen.
IGMP
■ SRX100 devices do not support IGMP snooping.
■ On SRX650 devices, MAC pause frame and FCS error frame counters are not
supported for the interfaces ge-0/0/0 through ge-0/0/3.
■ On SRX240 devices, the IP multicast switching is not supported; because of this,
multicast snooping is based on corresponding IP multicast Layer 2 address
(01:00:5e:xx:xx:xx). On SRX240 devices, all multicast receivers with an IP
multicast address mapped to the same Layer 2 address will receive the packets.
■ On SRX240 and SRX650 devices, the VLAN range from 3967 to 4094 falls under
the reserved VLAN address range, and the user is not allowed any configured
VLANs from this range.
■ On SRX650 devices, the last 4 ports of a 24-Gigabit Ethernet switch GPIM can
be used either as RJ-45 or SFP ports. If both are present and providing power,
the SFP media is preferred. If the SFP media is removed or the link is brought
down, then the interface will switch to the RJ-45 medium. This can take up to
15 seconds, during which the LED for the RJ-45 port might go up and down
intermittently. Similarly when the RJ-45 medium is active and an SFP link is
brought up, the interface will transition to the SFP medium, and this transition
could also take a few seconds.
■ On SRX Series and J Series devices, you can configure the st0 interface for IPsec
VPN in any routing instance, but you must configure the gateway external
interface in inet.0. The system allows you to assign an external interface that is
placed in a routing instance other than inet.0, but that configuration is not
supported.
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the following multicast
IPv6 and MVPN CLI commands are not supported. However, if you enter these
commands in the CLI editor, they will appear to succeed and will not display an
error message.
■ show pim interfaces inet6
■ show pim neighbors inet6
■ show pim source inet6
■ show pim rps inet6
■ show pim join inet6
■ show pim mvpn
■ show multicast next-hops inet6
■ show multicast rpf inet6
■ show multicast route inet6
■ show multicast scope inet6
■ show multicast pim-to-mld-proxy
■ show multicast statistics inet6
■ show multicast usage inet6
■ show msdp sa group group
■ set protocols pim interface interface family inet6
■ set protocols pim disable interface interface family inet6
■ set protocols pim family inet6
■ set protocols pim disable family inet6
■ set protocols pim apply-groups group disable family inet6
■ set protocols pim apply-groups group family inet6
■ set protocols pim apply-groups-except group disable family inet6
■ set protocols pim apply-groups group interface interface family inet6
■ set protocols pim apply-groups group apply-groups-except group family inet6
■ set protocols pim apply-groups group apply-groups-except group disable family

inet6
■ set protocols pim assert-timeout timeout-value family inet6
■ set protocols pim disable apply-groups group family inet6
■ set protocols pim disable apply-groups-except group family inet6
■ set protocols pim disable export export-join-policy family inet6
■ set protocols pim disable dr-election-on-p2p family inet6
■ set protocols pim dr-election-on-p2p family inet6
■ set protocols pim export export-join-policy family inet6
■ set protocols pim import export-join-policy family inet6
■ set protocols pim disable import export-join-policy family inet6
■ On SRX100, SRX210, SRX240, SRX650, and J series devices, Flow mode does
not support asymmetric routing for stateful sessions. As a result of this behavior
trace-route might not work when VRRP is configured across SRX devices.
Integrated Convergence Services
■ On SRX210 and SRX240 devices with Integrated Convergence Services, cluster

configuration is not supported. Also, clustering of the media gateway (MGW)
chassis is not supported even if Integrated Convergence Services is not used.
■ On SRX devices with application-level distributed denial-of-service

(application-level DDoS) detection, there will be a slight decline in session
capacity.
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, application-level
distributed DDoS detection does not work if two rules with different
application-level DDoS applications process traffic going to a single destination
application server. When setting up application-level DDoS rules, make sure you
do not configure rulebase-ddos rules that have two different application-ddos
objects while the traffic destined to one application server can process more
than one rule. Essentially, for each protected application server, you have to
configure application-level DDoS, so traffic destined for one protected server is
only processesed by one application-level DDoS rule.
NOTE: Application-level DDoS rules are terminal, which means that once traffic is
processed by one rule, it will not be processed by other rules.
The following configuration options will commit, but will not work properly.
Application
source-zone destination-zone destination-ip service application-ddos Server
source–zone-1 dst-1 any http http-appddos1 1.1.1.1:80
source-zone-2 dst-1 any http http-appddos2 1.1.1.1:80
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the application-level

distributed DDoS rulebase (rulebase-ddos) does not support proto mapping. If
you configure an application other than default, and if the application is from
either predefined JUNOS Software applications or a custom application that maps
an application service to a nonstandard port, application-level DDoS detection
will not work.
When you configure the application setting as default, IDP uses application
identification to detect applications running on standard and nonstandard ports;
hence the application-level DDoS detection would work properly.
■ On SRX Series and J Series devices, IP actions do not work when you select a
timeout value greater than 65535 in the IDP policy.
■ The maximum number of IDP sessions supported is 16000 on SRX210 devices,
32000 on SRX240 devices, and 128000 on SRX650 devices.
■ On SRX Series devices there is a 100-MB policy size limit for integrated mode
and a 150-MB policy size limit for dedicated mode, both for predefined templates
and custom policy. The current IDP policy templates supported are dynamic,
based on the attack signatures being added. Therefore, be aware that supported
templates might eventually grow past the policy-size limit.
On SRX Series devices, the following IDP policies are supported:

■ DMZ_Services
■ DNS_Service
■ File_Server
■ Getting_Started
■ IDP_Default
■ Recommended
■ Web_Server
■ On SRX Series devices, IDP does not inspect existing sessions that fail over or
fail back in chassis clustering. However, new sessions will be inspected.
■ IDP does not allow header checks for nonpacket contexts.
J-Web
■ On J Series devices, some J-Web pages for new features (for example, the Quick
Configuration page for the switching features on J Series devices) display content
in one or more modal pop-up windows. In the modal pop-up windows, you can
interact only with the content in the window and not with the rest of the J-Web
page. As a result, online Help is not available when modal pop-up windows are
displayed. You can access the online Help for a feature only by clicking the Help
button on a J-Web page.
■ On SRX Series devices, you can not use J-Web to configure a VLAN interface for
an IKE gateway. VLAN interfaces are not currently supported to be used as IKE
external-interfaces.
Network Address Translation (NAT)
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, IKE negotiations

involving NAT traversal do not work if the IKE peer is behind a NAT device that
will change the source IP address of the IKE packets during the negotiation. For
example, if the NAT device is configured with DIP, it changes the source IP
because the IKE protocol switches the UDP port from 500 to 4500.
NetScreen-Remote
■ On SRX Series devices, Netscreen-Remote is not supported in JUNOS Release

10.0.
Performance
■ J Series devices now support IDP and UTM functionality. Under heavy network
traffic in a few areas of functionality, such as NAT and IPsec VPN, performance
is still being improved to reach the high levels to which Juniper Networks is
consistently committed.
PPP over Ethernet (PoE)
■ On SRX240 devices in a chassis cluster, the reth interface cannot be used as the
underlying interface for Point-to-Point Protocol over Ethernet (PPPoE).
SNMP
■ On J Series devices, the SNMP NAT-related MIB is not supported in JUNOS Release
10.0.
System
■ On SRX650 devices, if one of the four Gigabit Ethernet ports (ge-0/0/0 through
ge-0/0/3) is linked up at 10 or 100 Mbps, it will not support jumbo frames.
Frames greater than 1500 bytes are dropped.
■ Unified Threat Management (UTM) requires 1 GB of memory. If your J2320,

J2350, or J4350 device has only 512 MB of memory, you must upgrade the
memory to 1 GB to run UTM.
VPNs
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the IPsec NAT-T tunnels
scaling and sustaining issues are as follows:
■ For a given private IP address, the NAT device should translate both 500
and 4500 private ports to same public IP address.
■ The total number of tunnels from a given public translated IP cannot exceed
1000 tunnels.
■ On an SRX240 High Memory device, protocols running over generic routing

encapsulation (GRE) or IP-IP tunnels might not come up when both the tunnel
interface and the underlying physical interface are configured and the
configuration is committed simultaneously. As a workaround, deactivate and
activate the tunnel interface (gr-0/0/0 or ip-0/0/0).
■ On a J Series device, when heavy bidirectional data traffic (80 Mbps or more)
passes through an IP-IP tunnel, traffic might stop flowing through the IP-IP tunnel
over time.
Related Topics ■ New Features in JUNOS Release 10.0 for SRX Series Services Gateways and J
Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services
Routers
■ Outstanding Issues In JUNOS Release 10.0 for SRX Series Services Gateways and
■ Resolved Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J
Outstanding Issues In JUNOS Release 10.0 for SRX Series Services

The following problems currently exist in SRX Series and J Series devices. The
identifier following the description is the tracking number in our bug database.
NOTE: Other software issues that are common to SRX Series Services Gateways and
J Series Services Routers, and M, MX, and T Series routers are listed in Issues in
JUNOS Release 10.0 for M Series, MX Series, and T Series Routers.
162 ■ Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
■ On SRX5600 devices, if you run the show security alg sip counters command
while doing a bulk call generation, it might bring down the SPU with a flowd
core file error. [PR/292956]
■ On SRX210 devices, the SCCP call cannot be set up after disabling and enabling
the SCCP ALG. The call does not go through. [PR/409586]
■ On SRX3400 and SRX3600 devices, RTSP, TFTP, and FTP ALG at scale in Layer
2 mode with A/P is not supported in JUNOS Release 10.0.[PR/474140]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, by default ALGs are
enabled. When security policies are configured with IDP service, there might be
packet drops. When IDP service is enabled through security policy configuration,
we recommend that you disable some or all ALGs through configuration to avoid
packet drops. For example: set security alg rtsp disable.
NOTE: Disabling ALGs will prevent auxiliary or pinholes session creation, and those
sessions might not be permitted based on security policy. The choice depends on
the customer network and what services are being run, whether ALGs need to be
enabled, and whether IDP inspection is required for all or a subset of traffic.
[PR/474629]
■ On an SRX240 device using SIP, a normal sip call goes through fine, but if the
called party tries call holding, after 20 seconds the receiving packet on both the
calling and called phones is not seen. The workaround for this to enter set security
alg sip retain-hold-resource. [PR/514765]
Authentication
■ On J Series devices, your attempt to log in to the router from a management

device through FTP or Telnet might fail if you type your username and password
in quick succession before the prompt is displayed, in some operating systems.
As a workaround, type your username and password after getting the prompts.
[PR/255024]
■ On J Series devices, after the user is authenticated, if the webauth-policy is deleted
or changed and an entry exists in the firewall authentication table, then an
authentication entry created as a result of webauth will be deleted only if a traffic
flow session exists for that entry. Otherwise, the webauth entry will not get
deleted and will only age out. This behavior will not cause a security breach.
[PR/309534]
Issues in JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers ■ 163
Chassis Cluster
■ On J Series devices in a chassis cluster, the show interface terse command on

the secondary Routing Engine does not display the same details as that of the
primary Routing Engine. [PR/237982]
■ On J4350 Services Routers, because the clear security alg sip call command
triggers a SIP RTO to synchronize sessions in a chassis cluster, use of the
command on one node with the node-id, local, or primary option might result in
a SIP call being removed from both nodes. [PR/263976]
■ On J Series devices, when a new redundancy group is added to a chassis cluster,
the node with lower priority might be elected as primary when the preempt
option is not enabled for the nodes in the redundancy group. [PR/265340]
■ On J Series devices, when you commit a configuration for a node belonging to
a chassis cluster, all the redundancy groups might fail over to node 0. If graceful
protocol restart is not configured, the failover can destabilize routing protocol
adjacencies and disrupt traffic forwarding. To allow the commit operation to
take place without causing a failover, we recommend that you use the set chassis
cluster heartbeat-threshold 5 command on the cluster. [PR/265801]
■ On J Series devices in a chassis cluster, a high load of SIP ALG traffic might result
in some call leaks in active resource manager groups and gates on the backup
router. [PR/268613]
■ On SRX Series devices in a chassis cluster, configuring the set system process
jsrp-service disable command only on the primary node causes the cluster to go
into an incorrect state. [PR/292411]
■ On SRX Series devices in a chassis cluster, using the set system processes
chassis-control disable command for 4 to 5 minutes and then enabling it causes
the device to crash. Do not use this command on an SRX Series device in a
chassis cluster. [PR/296022]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, 8-queue configurations
are not reflected on the chassis cluster interface. [PR/389451]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the iflset functionality
is not supported for aggregated interfaces like reth. [PR/391377]
■ On an SRX210 device in a chassis cluster, when you upgrade the nodes,
sometimes the forwarding process might crash and get restarted. [PR/396728]
■ On an SRX210 device in a chassis cluster, sometimes the reth interface MAC
address might not make it to the switch filter table. This results in the dropping
of traffic sent to the reth interface. As a workaround, restart the Packet Forwarding
Engine. [PR/401139]
■ On an SRX210 device in a chassis cluster, the fabric monitoring option is enabled
by default. This can cause one of the nodes to move to a disabled state. You can
disable fabric monitoring by using the following CLI command:
set chassis cluster fabric-monitoring disable
[PR/404866]
■ On an SRX210 Low Memory device in a chassis cluster, the firewall filter does
not work on the reth interfaces. [PR/407336]
■ On an SRX210 device in a chassis cluster, the restart forwarding method is not
recommended because when the control link goes through forwarding, the restart
forwarding process causes disruption in the control traffic. [PR/408436]
■ On an SRX210 device in a chassis cluster, there might be a loss of about 5 packets
with 20 Mbps of UDP traffic on an RG0 failover. [PR/413642]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, no trap is generated
for redundancy group 0 failover. You can check on the redundancy group 0 state
only when you log into the device. The nonavailability of this information is
caused by a failure of the SNMP walk on the backup (secondary) node. As a
workaround, use a master-only IP address across the cluster so that you can
query a single IP address and that IP address will always be the master for
redundancy group 0. [PR/413719]
■ On an SRX210 device with an FTP session ramp-up rate of 70, either of the
following might disable the secondary node:
■ Back-to-back redundancy group 0 failover
■ Back-to-back primary node reboot
[PR/414663]
■ If an SRX210 device receives more traffic than it can handle, node 1 either
disappears or gets disabled. [PR/416087]
■ On SRX3400, SRX3600, SRX5600, SRX5800, J2300, J2320, J2350, J4350, and
J6350 devices in an active/active chassis cluster, when the fabric link fails and
then recovers, services with a short time-to-live (such as ALG FTP) stop working.
[PR/419095]
■ On SRX3400 and SRX3600 devices in a chassis cluster, ESP authentication errors
occur while traffic is sent through 4000 site-to-site IPsec tunnels. [PR/426073]
■ On SRX650, J2300, J2320, J2350, J4350, and J6350 devices, doing a redundancy
group 0 failover with 1000 logical interfaces on the reth interface causes
replication errors. As a result, the ksyncd process generates a core file.
[PR/428636]
■ On SRX5800 devices, SNMP traps might not be generated for the
ineligible-primary state. [PR/434144]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices in chassis cluster
active/active mode, the J-Flow samplings do not occur and the records are not
exported to the cflowd server. [PR/436739]
■ On SRX240 Low Memory and High Memory devices, binding the same IKE policy
to a dynamic gateway and a site-to-site gateway is not allowed. [PR/440833]
■ On SRX650 devices, the following message appears on the new primary node
after a reboot or a RG0 failover:
WARNING: cli has been replaced by an updated version:

CLI release 9.6B1.5 built by builder on 2009-04-29 08:24:20 UTC
Restart cli using the new version ? [yes,no] (yes) yes
[PR/444470]
■ On SRX650 devices in active/active mode, FTP fail transfer might fail after you
reboot the active redundancy group node. [PR/454503]
■ On SRX240 devices, the cluster might get destabilized when the file system is
full and logging is configured on JSRPD and chassisd. The log file size for the
various modules should be appropriately set to prevent the file system from
getting full. [PR/454926]
ping to the redundant Ethernet reth interface fails when the cluster ID changes.
[PR/458729]
■ On SRX100 devices, after primary node reboot and cold synchronization are
finished, the chassis cluster auth session timeout age and application name
cannot synchronize with the chassis cluster peers. [PR/460181]
■ On SRX5600 devices, low-impact in-service software upgrade (ISSU) chassis
cluster upgrade does not succeed with the no-old-master-upgrade option when
users upgrade from JUNOS Release 9.6R2 to JUNOS Release 10.0R2.[PR/471235]
GTP tunnel indexes are not synchronized between nodes. When two nodes in
a chassis cluster use the same index for different GTP tunnels, if you clear the
tunnel using the index from one node, an extra tunnel might be removed from
the other node. [PR/472109]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the secondary node
displays incorrect interface status after a low-impact in-service software upgrade
(ISSU) from JUNOS Release 9.6R2 to JUNOS Release 10.0R2. [PR/482566]
■ For SRX100, SRX210, SRX240, and SRX650 devices in chassis cluster mode,
J-Web shows switching pages available for configuration, but switching is not
supported in chassis cluster mode. [PR/515909]
Class of Service (CoS)
■ J4350 and J6350 devices might not have the requisite data buffers needed to
meet expected delay-bandwidth requirements. Lack of data buffers might degrade
CoS performance with smaller-sized (500 bytes or less) packets. [PR/73054]
■ On J Series devices, with a CoS configuration, when you try to delete all the flow
sessions using the clear security flow session command, the WXC application
acceleration platform might fail over with heavy traffic. [PR/273843]
■ On SRX Series devices, class-of-service-based forwarding (CBF) is not working.
[PR/304830]
■ On SRX5600 devices, class of service is not supported in transparent mode.
[PR/424286]
■ On J Series devices, a reduced throughput over an ML bundle might be observed
due to drops by the reassembly logic although the multilink fragments have been
received at the member links. The symptom is that the member link ingress PPS
matches the egress PPS of the transmitting side and the SHOWcommand for ML
bundle show interface lsq-0/0/0 extensive shows drops such as fragment timeout,
missing sequence number, out-of-order sequence number or out-of-range
sequence number. As a work-around, configure a larger drop timeout (default

being 100ms) on the bundle at the receiving device. [PR/523154]
Enhanced Switching
■ On J Series devices, if the access port is tagged with the same VLAN that is
configured at the port, the access port accepts tagged packets and determines
the MAC. [PR/302635]
Flow and Processing
■ On J Series devices, even when forwarding options are set to drop packets for
the ISO protocol family, the device forms End System-to-Intermediate System
(ES-IS) adjacencies and transmits packets because ES-IS packets are Layer 2
terminating packets. [PR/252957]
■ On SRX Series devices, the show security flow session command currently does
not display aggregate session information. Instead, it displays sessions on a
per-SPU basis. [PR/264439]
■ On J Series devices, OSPF over a multipoint interface connected as a
hub-and-spoke network does not restart when a new path is found to the same
destination. [PR/280771]
■ On SRX Series devices, when traffic matches a deny policy, sessions will not be
created successfully. However, sessions are still consumed, and the
unicast-sessions and sessions-in-use fields shown by the show security flow session
summary command will reflect this. [PR/284299] [PR/397300]
■ On J Series devices, outbound filters will be applied twice for host-generated
IPv4 traffic. [PR/301199]
■ On SRX Series devices, configuring the flow filter with the all flag might result
in traces that are not related to the configured filter. As a workaround, use the
flow trace flag basic with the command set security flow traceoptions flag.
[PR/304083]
■ On SRX210, SRX240, and SRX650 devices, after the device fragments packets,
the FTP over a GRE link might not perform properly due to packet serialization.
[PR/412055]
■ On SRX240 devices, traffic flooding occurs when multiple Multicast (MC) IP group
addresses are mapped to the same MC MAC address because multicast switching
is based on the Layer 2 address. [PR/418519]
■ On SRX650 devices, the input DA errors are not updated when packets are
dropped due to MAC filtering on the following:
■ SRX240
■ SRX210
■ 16-port and 24-port GPIMs
■ SRX650 front-end port
This is due to MAC filtering implemented in hardware.
[PR/423777]
■ On SRX650 devices, the uplinks to the CPU can be exhausted and the system
can be limited to 2.5 GB throughput traffic when the device is using similar kinds
of source MAC addresses. [PR/428526]
■ On SRX5600 and SRX5800 devices, the network processing bundle configuration
CLI does not check if PICs in the bundle are valid. [PR/429780]
■ On SRX650 devices, packet loss is observed when the device interoperates with
an SSG20 with AMI line-encoding. [PR/430475]
■ On an SRX210 on-board Ethernet port, an IPv6 multicast packet received gets
duplicated at the ingress. This happens only for IPv6 multicast traffic in ingress.
[PR/432834]
■ On SRX3400 and SRX3600 devices, the ramp rate of session creation is slow at
times for fragmented UDP traffic. [PR/434508]
■ On SRX5800 devices, when there are nonexistent PICs in the network processing
bundle, the traffic is sent out to the PICs and is lost. [PR/434976]
■ The SRX5600 and SRX5800 devices create more than the expected number of
flow sessions with NAT traffic. [PR/437481]
■ On J Series devices, NAT traffic that is going to the WXC ISM 200 and returning
back in clear (that is, not accelerated by the WXC ISM 200) does not work.
[PR/438152]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, there is missing
information in the jnxJsFwAuthMultipleFailure trap message. The trap message is
required to contain the username, IP address, application, and trap name, but
the username is missing. [PR/439314]
■ On SRX5800 devices, for any network processing bundle configuration change
to take effect, a reboot is needed. Currently there is no message displayed after
a bundle configuration change. [PR/441546]
■ On SRX5800 devices, the IOC hot swap is not supported with network processing
bundling. If an IOC that has network processing bundling configured gets
unplugged, all traffic to that network processor bundle will be lost. [PR/441961]
■ On SRX5800 devices with interfaces in a network processing bundle, the ICMP
flood or UDP flood cannot be detected at the threshold rate. However, it can be
detected at a higher rate when the per-network processor rate reaches the
threshold. [PR/442376]
■ On J Series and low-end SRX Series devices using VLAN Level 3, the multicast
receiver does not receive traffic. [PR/448208]
■ On an SRX3400 device in combo mode with two SPCs and one NPC, not all
sessions are created under the stress test. [PR/450482]
■ On SRX240 PoE and J4350 devices, the first packet on each multilink class gets
dropped on reassembly. [PR/455023]
■ On SRX240 PoE and J Series devices, packet drops are seen on the lsq interface
when transit traffic with a frame length of 128 bytes is sent. [PR/455714]
■ On SRX5600 and SRX5800 devices, system log messages are not generated
when CPU utilization returns to normal. [PR/456304]
■ On SRX210, SRX240, and J6350 devices, the serial interface goes down for long
duration traffic when FPGA 2.3 version is loaded in the device. As a result, the
multilink goes down. This issue is not seen when downgrading the FPGA version
from 2.3 to 1.14. [PR/461471]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, in end-to-end
debugging, the cp-lbt event actions are not working. There is no change in
behavior with or without the cp-lbt event. [PR/462288]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, data path-debug rate-limit
is not working properly.
When users configure a low rate limit for a large number of trace messages, the
system should suspend the trace messages after the configured maximum is
reached. The system is not suspending the trace messages. [PR/464151]
■ GPRS tunneling protocol (GTP) application is supported on well-known ports
only. Customized GTP application on not so well-known ports are not supported.
[PR/464357]
■ On J Series devices, interfaces with different bandwidths (even if they are of
same interface type, for example, serial interfaces with different clock rates or
channelized T1/E1 interfaces with different timeslots) should not be bundled
under one ML bundle. [PR/464410]
■ On SRX5600 devices, the request system storage cleanup command will delete
the configuration file juniper.conf.spu.gz from /var/tmp/. This will cause failure
of VPN. [PR/474581]
Hardware
■ On SRX210 devices, the MTU size is limited to 1518 bytes for the 1-port SFP
Mini-PIM. [PR/296498]
■ On SRX240 and SRX650 devices and 16-port or 24-port GPIMs, the 1G half-duplex
mode of operation is not supported in the autonegotiation mode. [PR/424008]
■ On SRX240 devices, the Mini-PIM LEDs glow red for a short duration (1 second)
when the device is powered on. [PR/429942]
■ On SRX240 devices, the file installation fails on the right USB slot when both of
the USB slots have USB storage devices attached. [PR/437563]
■ On SRX240 devices, the combinations of Mini-PIMs cause SFP-Copper links to
go down in some instances during bootup, restarting fwdd, and restarting
chassisd. As a workaround, reboot the device and the link will be up. [PR/437788]
Infrastructure
■ On J Series devices, you cannot use a USB device that provides U3 features (such
as the U3 Titanium device from SanDisk Corporation) as the media device during
system boot. You must remove the U3 support before using the device as a boot
medium. For the U3 Titanium device, you can use the U3 Launchpad Removal
Tool on a Windows-based system to remove the U3 features. The tool is available
for download at http://www.sandisk.com/Retail/Default.aspx?CatID=1415. (To restore
the U3 features, use the U3 Launchpad Installer Tool accessible at
http://www.sandisk.com/Retail/Default.aspx?CatID=1411). [PR/102645]
■ On J Series devices, if the device does not have an ARP entry for an IP address,
it drops the first packet from itself to that IP address. [PR/233867]
■ On J Series devices, when you press the F10 key to save and exit from BIOS
configuration mode, the operation might not work as expected. As a workaround,
use the Save and Exit option from the Exit menu. This issue can be seen on the
J4350 and J6350 routers with BIOS Version 080011 and on the J2320 and J2350
routers with BIOS Version 080012. [PR/237721]
■ On J Series devices, the Clear NVRAM option in the BIOS configuration mode
does not work as expected. This issue can be seen on the J4350 and J6350 routers
with BIOS Version 080011 and on the J2320 and J2350 routers with BIOS Version
080012. To help mitigate this issue, note any changes you make to the BIOS
configuration so that you can revert to the default BIOS configuration as needed.
[PR/237722]
■ On J Series devices, If you enable security trace options, the log file might not
be created in the default location at /var/log/security-trace. As a workaround,
manually set the log file to the directory /var/log/security-trace. [PR/254563]
■ On J4350 and J6350 devices, the link status of the onboard Gigabit Ethernet
interfaces (ge-0/0/0 through ge-0/0/3) or the 1-port Gigabit Ethernet ePIM
interface fails when you configure these interfaces in loopback mode. [PR/72381]
■ On J Series Routers, asymmetric routing, such as tracing a route to a destination
behind J Series devices with Virtual Router Redundancy Protocol (VRRP), does
not work. [PR/237589]
■ On SRX5600 and SRX5800 devices, the ping operation to far-end reth interfaces
does not work for different routing instances. [PR/408500]
■ On SRX240 and SRX650 devices, when you are configuring the link options on
an interface, only the following scenarios are supported:
■ Autonegotiation is enabled on both sides.
■ Autonegotiation is disabled on both sides (forced speed), and both sides are
set to the same speed and duplex.
If one side is set to autonegotiation mode and the other side is set to forced
speed, the behavior is indeterminate and not supported. [PR/423632]
■ On SRX Series and J Series devices, the RPM operation will not work for the
probe-type tcp-ping when the probe is configured with the option
destination-interface. [PR/424925]
■ On SRX650 devices, the following loopback features are not implemented for
T1/E1 GPIMs:
■ Line
■ FDL payload
■ Inband line
■ Inband payload
[PR/425040]
■ On J4350 devices, multicast traffic is not received when the source and the
receiver are connected to same PE routers. [PR/429130]
■ In J Series xDSL PIMs, mapping between IP CoS and ATM CoS is not supported.
If the user configures IP CoS in conjunction with ATM CoS, the logical interface
level shaper matching ATM CoS rate must be configured to avoid congestion
drops in SAR.
Example:
set interfaces at-5/0/0 unit 0 vci 1.110
set interfaces at-5/0/0 unit 0 shaping cbr 62400 ATM COS
set class-of-service interfaces at-5/0/0 unit 0 scheduler-map sche_map IP COS
set class-of-service interfaces at-5/0/0 unit 0 shaping-rate 62400 ADD IFL SHAPER
[PR/430756]
■ On SRX650 devices, configuring dual and quad T1/E1 framing at the chassis
level has no effect. [PR/432071]
■ On SRX240 devices, the serial interface maximum speed in extensive output is
displayed as 16384 Kbps instead of 8.0 Mbps. [PR/437530]
■ On SRX Series devices, incorrect Layer 2 circuit replication on the backup Routing
Engine might occur when you:
■ Configure nonstop routing (NSR) and Layer 2 circuit standby simultaneously
and commit them
■ Delete the NSR configuration and then add the configuration back when
both the NSR and Layer 2 circuits are up
As a workaround:
1. Configure the Layer 2 circuit for non-standby connection.
2. Change the configuration to standby connection.
3. Add the NSR configuration.
[PR/440743]
■ On SRX210 Low Memory devices, the E1 interface will flap and traffic will not
pass through the interface if you restart forwarding while traffic is passing through
the interface. [PR/441312]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you configure

the SAP listen option using the protocol sap listen command in the CLI, listening
fails in both sparse and sparse-dense modes. [PR/441833]
■ On J Series devices, one member link is going down in a Multilink (ML) bundle
during bidirectional traffic with Multilink Frame Relay (MFR). [PR/445679]
■ On J Series devices, the DS3 interface does not have an option to configure
multilink-frame-relay-uni-nni (MFR). [PR/453289]
■ On SRX210 PoE devices, the ATM interface on an G.SHDSL interface will not go
down when the interface is disabled through the disable command. [PR/453896]
■ On SRX100, SRX210, and J Series devices, out-of-band dial-in access using a
serial modem does not work. [PR/458114]
■ On SRX210 PoE devices, the G.SHDSL link does not come up with octal port line
card of total access 1000 ADTRAN DSLAM. [PR/459554]
■ On J Series devices, egress drops are seen on a bundle for traffic with a bigger
packet size and smaller fragmentation threshold. [PR/461417]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the show datapath-debug
counter command gives error messages from the secondary node. [PR/477017]
■ For SRX210, SRX240, and SRX650 devices, attach a scheduler to queue 3 of the
WAN interfaces with high priority. For multilink, attach the scheduler to the
MLPPP bundle (lsq-0/0/0) and the WAN interface. Without the scheduler, the
PPP session might flap when the bundle or the WAN link is oversubscribed.
[PR/471340]
■ On SRX240 High Memory devices, decompress functionality with express
antivirus has issues that might cause watchdog timeout (lead to a crash). As a
workaround, disable the decompress functionality for the express antivirus
feature. [PR/521684]
The following issues currently exist in SRX210 and SRX240 devices with Integrated
Convergence Services:
■ On SRX210 devices with Integrated Convergence Services, the call hold feature
does not work for Xlite softphones. [PR/432725]
■ On SRX240 devices with Integrated Convergence Services, T1 configuration does
not support all the 24 time slots for voice calls. It is limited to 5 time slots or line
channels currently. [PR/442934]
■ At least one time slot must be configured for data for voice channels on T1 lines
to work. [PR/442932]
■ The music-on-hold feature is not supported for SIP phones. [PR/443681]
■ The peer call server configuration for the media gateway page in J-Web does not
correctly display the port number field when TCP is used as the transport.
[PR/445734]
■ When you click the trunk-group field in J-Web, the configured trunk values are
not displayed. [PR/445765]
■ You cannot edit the extension number on the J-Web call features page.
[PR/447523]
■ When you edit the remote access number in J-Web, the change is not displayed
until you refresh the page. [PR/447530]
■ Comfort noise packets are not generated when both voice activity detection
(VAD) and comfort noise generation are enabled for an FXS station. [PR/448191]
■ In J-Web, if you do not configure the class of restriction and a station template,
you cannot configure a station. [PR/452439]
■ J-Web does not provide support for the SIP template extension inheritance feature.
[PR/455787]
■ SNMP does not provide support for survivable call server (SRX Series SCS)
statistics. [PR/456454]
■ For J-Web, a commit is completed when a trunk group is configured without one
or more trunks, but the trunk group configuration is not visible in J-Web or the
CLI. You should not be able to configure a trunk group that does not contain at
least one trunk. [PR/460489]
■ Consecutive G.711 faxes pass through between two FXS ports fails when
originating and terminating sides alternate. [PR/465775]
■ When T1 lines for stations or trunks are configured, you might hear a momentary
burst of noise on the phone. [PR/467334]
■ You must restart the flow daemon to commit runtime T1 configuration changes.
[PR/468594]
■ Voice codec support is limited to G.711 u-law only. [PR/469094] [PR/485021]
■ The SRX210 device allows the FXS 2 port to be configured as a station and as
an FXS trunk concurrently. In this case, the system does not display a commit
error. [PR/473561]
■ FXS-FXS calls with Avaya SES+CM as the peer call server work only if media is
sent through Avaya. [PR/488184]
■ On SRX240 devices, simultaneous call capacity is limited to 10 calls. [PR/489024]
■ When the heartbeat-survivable-interval is configured below 500 milliseconds
and when the media gateway is operating in survivable state, there is a very rare
chance that the system will send OPTIONS messages continuously on the default
route interface. Therefore, we recommend that you configure the
heartbeat-survivable-interval as 500 milliseconds (default) or more. [PR/492344]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when the firewall and
IDP policy both enable diffServ marking with a different DSCP value for the same
traffic, the firewall DSCP value takes precedence and the traffic is marked using
the firewall DSCP value. [PR/297437]
■ The SRX210, SRX240, and SRX650 devices support only one IDP policy at any
given time. When you make changes to the IDP policy and commit, the current
policy is completely removed before the new policy becomes effective. During
the update, IDP will not inspect the traffic that is passing through the device for
attacks. As a result, there is no IDP policy enforcement. [PR/392421]
■ On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices, in J-Web
selecting Configuration>Quick Configuration>Security Policies>IDP
Policies>Security Package Update>Help brings up the IDP policy Help page
instead of the Signature update Help page. To access the corresponding Help
page, select: Configuration>Quick Configuration>IDP
Policies>Signature/Policies Update and then click Help. [PR/409127]
■ On SRX3400, SRX3600, SRX5600 and SRX5800 devices, if you want to change
to dedicated mode, the configuration of the security forwarding-process
application-services maximize-idp-sessions command should be done right before
rebooting the device. This should be done to avoid recompiling IDP policies
during every commit. [PR/426575]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, IDP is not officially
supported in an active/active chassis cluster configuration. The user must disable
the IDP configuration when the devices are configured in an active/active chassis
cluster. [PR/432252]
■ On SRX3400, SRX3600, and SRX5600 devices, when you configure IDP to run
in decoupled mode using the set security forwarding-process application-services
maximize-idp-sessions command, network address translation (NAT) information
will not be shown in the event log. [PR/445908]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if you configure a
policy containing more than 70 rules, with each rule containing the predefined
attack groups (Critical, Major, and Minor), policy compilation fails and the
configured policy load will also fail. [PR/449731]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices in
maximize-idp-sessions mode, there is an IPC channel between two data plane
processes. The channel is responsible for transferring the "close session" message
(and other messages) from the firewall process to the IDP process. Under stress
conditions, the channel becomes full and extra messages might get lost. This
causes IDP sessions in the IDP process to stay for longer than necessary, and
they will time out eventually. [PR/458900]
■ When an SRX Series device running JUNOS Release 10.0 (Layer 2
access-integrated mode) is rolled back to the Release 9.6 image, the DUT comes
up in Release 9.6 with Layer 2 access-integrated mode, which was not supported
in JUNOS Release 9.6. [PR/469069]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you change
device IDP mode from regular to maximize-idp-sessions, the warning message
to reboot the device will not be displayed if there is no security IDP under
configuration. As a workaround, configure security IDP first, then set
maximize-idp-sessions as the last step before rebooting the device. [PR/464979]
J-Flow
■ SRX3400, SRX3600, SRX5600, and SRX5800 devices support 4-byte autonomous

system (AS) for BGP configuration. However, the J-Flow template versions 5 and
8 do not support 4-byte AS, because these J-Flow templates have 2 bytes for the
SRC/DST AS field. [PR/416497]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, J-Flow sampling on

the virtual router interface does not show the values of autonomous system (AS)
and mask length values. The AS and mask length values of cflowd packets show
0 while sampling the packet on the virtual router interface. [PR/419563]
■ On SRX Series devices, J-Flow Multicast traffic is not sampled in the output
direction. [PR/447357]
J-Web
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the LEDs on the Routing
Engine and PICs are not shown as green when they are up and online on the
J-Web Chassis View. [PR/297693]
■ On SRX Series devices, when the user adds LACP interface details, a pop-up
window appears in which there are two buttons to move the interface left and
right. The LACP page currently does not have images incorporated with these
two buttons. [PR/305885]
■ On SRX210 devices, there is no maximum length limit when the user commits
the hostname in CLI mode; however, only a maximum of 58 characters are
displayed in the J-Web System Identification panel. [PR/390887]
■ On SRX210, SRX240, and SRX650 devices, the complete contents of the ToolTips
are not displayed in the J-Web Chassis View. As a workaround, drag the Chassis
View image down to see the complete ToolTip. [PR/396016]
■ On SRX100, SRX210, SRX240, and SRX650 devices, the LED status in the Chassis
View is not in sync with the LED status on the device. [PR/397392]
■ On SRX Series devices, when you right-click Configure Interface on an interface
in the J-Web Chassis View, the Configure>Interfaces page for all interfaces is
displayed instead of the configuration page for the selected interface. [PR/405392]
■ On SRX210 Low Memory devices in the rear view of the Chassis viewer image,
the image of ExpressCard remains the same whether a 3G card is present or
not. [PR/407916]
■ On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices, selecting
Configure>Security>Policy>IDP Policies>Security Package Update>Help
in the J-Web user interface brings up the IDP policy Help page instead of the
Signature update Help page. To access the corresponding Help page, select
Configure>IDP>Signature Update and then click Help. [PR/409127]
■ On SRX Series devices, the CLI Terminal feature is not working in J-Web over
IPv6. [PR/409939]
■ On SRX210 High Memory, SRX240 PoE, and J Series devices, IDP Custom Attacks
and Dynamic Attack groups cannot be configured using J-Web. [PR/416885]
■ On SRX210, SRX240, J2350, J4350, and J6350 devices, when J-Web users select
the tabs on the bottom-left menu, the corresponding screen is not displayed
fully, so users must scroll the page to see all of the content. This issue occurs
when the computer is set to a low resolution. As a workaround, set the computer
resolution to 1280 x 1024. [PR/423555]
■ On SRX Series and J Series devices, users cannot differentiate between Active
and Inactive configurations on the System Identity, Management Access, User
Management, and Date & Time pages. [PR/433353]
■ On SRX210 devices, in Chassis View, right-clicking any port and then clicking
Configure Port takes the user to the Link aggregation page. [PR/433623]
■ On SRX100 devices, in J-Web users can configure the scheduler without entering
any stop date. The device submits the scheduler successfully, but the submitted
value is not displayed on the screen saved in the device. [PR/439636]
■ On SRX100, SRX210, SRX240, and SRX650 devices, in J-Web the associated
dscp and dscpv6 classifiers for a logical interface might not be mapped properly
when the user edits the classifiers of a logical interface. This can affect the Delete
functionality as well. [PR/455670]
■ On SRX Series and J Series devices, when J-Web is used to configure a VLAN,
the option to add an IPv6 address appears. Only IPv4 addresses are supported.
[PR/459530]
■ On SRX Series devices in J-Web the left side menu items and page content might
disappear when Troubleshoot is clicked twice. As a workaround, click the
Configure or Monitor menu to get back the relevant content. [PR/459936]
■ On SRX100, SRX210, SRX240, SRX650, and J Series devices, in J-Web, the
options Input filter and Output Filter are displayed in VLAN configuration page.
This feature is not supported, and the user cannot obtain or configure any value
under these filter options. [PR/460244]
■ On SRX100, SRX210, SRX240, SRX650, and J Series devices, in the J-Web
interface, if you try to change the position of columns in J-Web by using the
drag-and-drop method, only the column header moves to the new position
instead of the entire column. The following pages are affected:
■ OSPF Global Settings table on the OSPF Configuration page
■ Global Information table on the BGP Configuration page
■ Add Interface window on the LACP Configuration page
[PR/465030]
■ On SRX100, SRX210, SRX240, SRX650, and J Series devices, in the J-Web
interface, the Traceoptions tab in the Edit Global Settings window of the OSPF
Configuration page (Configuration>Routing>OSPF Configuration) does not
display the available flags (tracing parameters). As a workaround, use the CLI to
view the available flags. [PR/475313]
■ On SRX100, SRX210, SRX240, SRX650, and J Series devices, when you have a
large number of static routes configured, and if you have navigated to pages
other than to page 1 in the Route Information table in the J-Web interface
(Monitor>Routing>Route Information), changing the Route Table to query
other routes refreshes the page but does not return you to page 1. For example,
if you run the query from page 3 and the new query returns very few results,
the Route Information table continues to display page 3 with no results. To view
the results, navigate to page 1 manually. [PR/476338]
■ On SRX Series devices, deactivating the IDP node from the CLI or removing
active-policy from the CLI does not clear the counters under show security idp
status. [PR/508873]
■ On SRX Series devices operating under stress conditions, the output for the show
security idp attack table command might be empty at times. [PR/508976]
■ On SRX Series devices, IDP commands become unresponsive during the following
scenarios:
■ The device is operating under heavy traffic conditions for a long time.
■ There are thousands of ip-action entries.
■ Users have executed the ip-action show command from the CLI.
As a workaround, do not issue the show security flow ip-action | count command
from the CLI. [PR/510250]
■ On SRX100, SRX210, and SRX240 devices, the following issues exist on the
VLAN Configuration page:
■ After you add a new VLAN, the details grid does not show the IP address.
■ While you are editing the VLAN, the IP address is blank.
■ While you are editing the VLAN, the VLAN name appears in the output filter
value.
As a workaround, refresh the VLAN Configuration page to see the corrected

details grid. [PR/511756]
■ On SRX100, SRX210, SRX240, and SRX650 devices, the configured aggregated
Ethernet interface disappears if it is committed because of syntax. [PR/515157]
■ On SRX100, SRX210, SRX240, and SRX650 devices, when you select the none
option to configure the aggregated Ethernet interface with a trunk VLAN, you
cannot commit the configuration [PR/515162]
■ On SRX Series and J Series devices, the width of the J-Web Policy Events detail
table exceeds the window size and there is no scrollbar to get to the missing
columns. As a workaround, adjust the column width. [PR/516666]
■ On SRX Series and J Series devices, J-Web pages take more time to load the log
files from the Monitor>Event page. [PR/516725]
■ On SRX Series and J Series devices, J-Web does not display the system log files.
[PR/516675]
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the queue statistics

are not correct after deletion and re-creation of a logical interface (IFL) or creation
of a new IFL. IFL statistics are not cleared for 15 minutes after chassis-control is
restarted. [PR/417947]
■ On SRX5600 devices, when the system is in an unstable state (for example SPU
reboot), NFS might generate residual.nfs files under the /var/tmp directory,
which can occupy the disk space for a very long time. As a workaround, run the
request sys storage cleanup command to clean up when the system has low disk
space. [PR/420553]
■ On SRX5800 devices, when VPN is not in use, the device will not generate the
var/tmp/spu_kmd_init/ file, which is logged by Iked_cfg. This should not happen
because it is not an error condition. As a result disk space might be wasted over
time. As a workaround, run the cp /dev/null /var/tmp/spu_kmd_init command
from the shell to create this file. Also run request sys storage cleanup to clean up
when the system has low disk space. [PR/425380]
■ On SRX650 devices, the kernel crashes when the link goes down during TFTP
installation of the srxsme image. [PR/425419]
■ On SRX650 devices, continuous messages are displayed from syslogd when ports
are in switching mode. [PR/426815]
■ On SRX240 devices, if a timeout occurs during the TFTP installation, booting the
existing kernel using the boot command might crash the kernel. As a workaround,
use the reboot command from the loader prompt. [PR/431955]
■ On SRX240 devices, when you configure the system log hostname as 1 or 2, the
device goes to the shell prompt. [PR/435570]
■ On SRX240 devices, the Scheduler Oinker messages are seen on the console at
various instances with various Mini-PIM combinations. These messages are seen
during bootup, restarting fwdd, restarting chassisd, and configuration commits.
[PR/437553]
■ On SRX5600 and SRX5800 devices, data path debug trace messages are getting
dropped at above 1000 packets per second (pps). [PR/446098]
■ On J2350, J4350, and J6350 devices, extended bit error rate test (BERT) takes
an additional 3 hours to complete even though a BERT-period of 24 hours is set.
[PR/447636]
NetScreen Manager (NSM)
■ On NSM applications, the traffic and attack logs are not getting updated in the
NSM Log Viewer screen for all devices loaded with JUNOS Release 10.0 R3.
[PR/515115]
■ On NSM applications, the IDP policy update fails while pushing small policies to
the device. As a workaround, disable the confirmed-commit command GUI using
the following path:
Preferences>device update>Netconf->use confirmed commit
[PR/516151]
Power over Ethernet (PoE)
■ On SRX240 and SRX210 devices, the output of the PoE operational commands
takes roughly 20 seconds to reflect a new configuration or a change in status of
the ports. [PR/419920]
■ On SRX210 and SRX240 devices, the deactivate poe interface all command does
not deactivate the PoE ports. Instead, the PoE feature can be turned off by using
the disable configuration option. Otherwise, the device must be rebooted for the
deactivate setting to take effect. [PR/426772]
■ On SRX210 and SRX240 devices, the output for the show poe telemetries
command shows the telemetry data in chronological order. This should be
changed to reverse-chronological order (most recent data first). [PR/429033]
■ On SRX210 and SRX240 devices, the class-4 powered device does not get
powered on when PoE is configured to operate in class management mode.
[PR/437406]
■ SRX210 and SRX240 devices operating under overload conditions take longer
to power off than what is specified in the standards. [PR/437416]
■ On SRX210 and SRX240 devices, the last powered device will not power on if
the allocated power becomes equal to the power limit on the device. Power
allocated must always be less than the power limit. For example, SRX240 devices
cannot be configured such that allocated power becomes 150 W, even though
it is possible to allocate the power up to 149.8 W. [PR/437792]
■ On SRX210 and SRX240 devices, reset of the PoE controller fails when the restart
chassis-control command is issued and also after system reboot. PoE functionality
is not negatively impacted by this failure. [PR/441798]
■ On SRX100, SRX210, SRX240, and SRX650 devices with factory default
configurations, the devices are not able to manage the access point. This might
be due to the DHCP default gateway not being set. [PR/468090]
Routing Protocols
■ On SRX210 devices with ports in ethernet-switching mode, OSPF hello packets

that contain a ToS value of 0xC0 are not switched to other ports in the same
VLAN. [PR/500981]
■ On SRX Series and J Series devices, high CPU utilization, resulting from
CPU-intensive commands, SNMP walks, and other reasons, can cause Bidirectional
Forwarding Detection (BFD) to flap, or send an excessive number of update
messages to advertise network reachability information. [PR/505541]
Security
■ On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the egress filter-based

forwarding (FBF) feature is not supported. [PR/396849]
■ On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices in a chassis
cluster, if the Infranet Controller auth table mapping action is configured as
provision auth table as needed, UAC terminates the existing sessions after Routing
Engine failover. You might have to initiate new sessions. Existing sessions will
not get affected after Routing Engine failover if the Infranet Controller auth table
mapping action is configured as always provision auth table. [PR/416843]
Unified Access Control (UAC)
■ On J Series devices, MAC address-based authentication does not work when the
router is configured as a UAC Layer 2 Enforcer. [PR/431595]
USB Modem
■ On SRX100, SRX210, SRX240, and SRX650 devices, when you restart fwdd at
the dial-out side, the umd interface goes down and the call never gets connected.
As a workaround, disable the dialer interface and restart the forwarding daemon.
Enable the dialer interface when the forwarding daemon is up and running. As
a result, the dial-out side reconnects with the dial-in side successfully.
Perform the following steps:
1. Disable the dialer interface:
user@host# set interfaces dl0 disable
user@host# commit
2. Restart the forwarding daemon:
user@host# run restart forwarding Forwarding Daemon started, pid 1407
user@host# delete interfaces dl0 disable
user@host# commit
3. Enable the dialer interface:

user@host# delete interfaces dl0 disable
user@host# commit
[PR/480206]
■ On SRX210 High Memory devices, content filtering provides the ability to block
protocol commands. In some cases, blocking these commands interferes with
protocol continuity, causing the session to hang. For instance, blocking the FETCH
command for the IMAP protocol causes the client to hang without receiving any
response. [PR/303584]
■ On SRX210 High Memory devices, when the content filtering message type is
set to protocol-only, customized messages appear in the log file. [PR/403602]
■ On SRX210 High Memory devices, the express antivirus feature does not send
a replacement block message for HTTP upload (POST) transactions if the current
antivirus status is engine-not-ready and the fallback setting for this state is block.
An empty file is generated on the HTTP server without any block message
contained within it. [PR/412632]
■ On SRX240, SRX650, J2320, J2350, J4350, and J6350 devices, Outlook Express
is sending infected mail (with an EICAR test file) to the mail server (directly, not
through DUT). Eudora 7 is using the IMAP protocol to download this mail (through
DUT). Mail retrieval is slow, and the EICAR test file is not detected. [PR/424797]
■ On SRX650 devices operating under stress conditions, the UTM subsystem file
partition might fill up faster than UTM can process and clean up existing
temporary files. In that case, the user might see error messages. As a workaround,
reboot the system [PR/435124]
■ On SRX240 High Memory devices, FTP download for large files (larger than 4
MB) does not work in a two-device topology. [PR/435366]
■ On SRX210, SRX240, and SRX650 devices, the Websense server stops taking
new connections after HTTP stress. All new sessions get blocked. As a
workaround, reboot the Websense server. [PR/435425]
■ On SRX240 devices, if the device is under UTM stress traffic for several hours,
users might get the following error while issuing a UTM command:
the utmd subsystem is not responding to management requests.
As a workaround, restart the utmd process. [PR/436029]
■ On SRX100 High Memory, SRX210 High Memory, SRX240 High Memory, and
SRX650 devices, the antispam requests more than 1500 are not supported due
to system limitation. [PR/451329]
■ On SRX210 High Memory devices, forwarding daemon might run out of memory
with large UTM configuration such as 30000 objects configured including 15000
URLs in blacklist. This results in forwarding daemon to core and stop forwarding.
[PR/518490]
■ On (SRX100, SRX210, and SRX240) High Memory devices, and SRX650 devices,
antispam sessions-per-client over-limit is not supported. [PR/514562]
Virtual LANs (VLANs)
■ On SRX650 devices, when VLAN tagging is configured and traffic is sent, the
output of show interfaces ge-0/0/1 media detail VLAN tagged frame count is not
shown. [PR/397849]
■ On SRX240, SRX650, J4350, and J6350 devices, tagged frames on an access
port with the same VLAN tag are not getting dropped. [PR/414856]
■ On SRX100, SRX210, and SRX240 devices, the packets are not being sent out
of the physical interface when the VLAN ID associated with the VLAN interface
is changed. As a workaround, you need to clear the ARP. [PR/438151]
■ On an SRX100 device, when ping packets are sent across a Layer 2 link
aggregation group (LAG) interface, the target device receives duplicate packets.
[PR/514924]
VPNs
■ On SRX5600 devices, the shared IKE limit for IKE users is not currently enforced.
More users than are specified in the shared IKE limit are able to establish
IKE/IPsec tunnels. [PR/288551]
■ On SRX210 and SRX240 devices, concurrent login to the device from a different
management systems (for example, laptop or computers) are not supported.
The first user session will get disconnected when a second user session is started
from a different management system. Also, the status in the first user system is
displayed incorrectly as “Connected”. [PR/434447]
■ On SRX Series and J Series devices, the site-to-site policy-based VPNs in a three
or more zone scenario will not work if the policies match the address “any”,
instead of specific addresses, and all cross-zone traffic policies are pointing to
the single site-to-site VPN tunnel. As a workaround, configure address books in
different zones to match the source and destination, and use the address book
name in the policy to match the source and destination. [PR/441967]
WXC Integrated Services Module
■ When two J Series devices with WXC Integrated Services Modules (WXC ISM
200s) installed are configured as peers, traceroute fails if redirect-wx is configured
on both peers. [PR/227958]
■ On J6350 devices, JUNOS Software does not support policy-based VPN with WXC
Integrated Services Modules (WXC ISM 200s). [PR/281822]
Resolved Issues in JUNOS Release 10.0 for SRX Series Services Gateways
and J Series Services Routers
The following issues from JUNOS Release 10.0 R3 for SRX Series Services Gateways
and J Series Services Routers have been resolved in this release. The identifier
NOTE: Other software issues that are common to SRX Series Services Gateways and
J Series Services Routers, and M, MX, and T Series routers are listed in Issues in
JUNOS Release 10.0 for M Series, MX Series, and T Series Routers.
Flow and Processing
■ On an SRX5800 device with a 1-Gbps IOC, when more than 10 ports per port
module were used, intermittent packet loss occurred because of oversubscription.
■ On SRX210, SRX240, and SRX650 devices, the aggregated Ethernet interface
was marked as disabled when xSTP over LAG was deactivated. The ports became
blocked and stopped to switch traffic. [PR/515559: This issue has been resolved.]
Hardware
■ On SRX650 devices, the 16-port Gigabit Ethernet switch GPIM was incorrectly
labeled as XGPIM. This switch was a double-high XPIM that operated only in
slots 2 to 4 or 6 to 8 that connected to the 20-gigabit connector in slots 2 or 6,
respectively. [PR/444511: This issue has been resolved.]
■ On J2320 devices, when you enabled the DHCP client, the default route was not
added to the route table. [PR/296469: This issue has been resolved.]
■ On SRX240 devices, drops in out-of-profile LLQ packets were seen in the presence
of data traffic, even when the combined (data+LLQ) traffic did not oversubscribe
the multilink bundle. [PR/417474: This issue has been resolved]
J-Web
■ On SRX Series and J Series devices, on the spanning-tree configuration page, the
Edit interface/msti window did not save the data before committing the
configuration. [PR/433506: This issue has been resolved.]
■ On SRX100, SRX210, SRX240, and SRX650 devices, the edited IP address of
the VLAN was not reflected in the “Details” section of the VLAN table because
of a refresh issue. [PR/512558: This issue has been resolved.]
■ On SRX Series and J Series devices with session-init and session-close enabled,
you were not allowed to clear sessions manually when too many sessions were
in status "used". [PR/445730: This issue has been resolved.]
■ On SRX210 High Memory devices, the express antivirus initial database download
failed due to the slow start of the device interface. [PR/388535: This issue has
been resolved.]
Errata and Changes in Documentation for JUNOS Release 10.0 for SRX Series Services
■ The JUNOS Software Security Configuration Guide incorrectly states that ALGs are
not supported in transparent mode on SRX3400, SRX3600, SRX5600, and
SRX5800 devices. The FTP, TFTP, RTSP, and DNS ALGs are supported in
transparent mode on those devices. Other ALGs are not.
■ ALG configuration examples in the JUNOS Software Security Configuration Guide
incorrectly show policy-based NAT configurations. NAT configurations are now
rule-based.
184 ■ Errata and Changes in Documentation for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services
Routers
Errata and Changes in Documentation for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
Attack Detection and Prevention
■ The default parameters documented in the firewall/NAT screen configuration

options table in the JUNOS Software Security Configuration Guide and the J-Web
online Help do not match the default parameters in the CLI. The correct default
parameters are:
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
}
[edit security screen ids-option untrust-screen]
Chassis Cluster
■ In the Junos OS Security Configuration Guide, the “Chassis Cluster” chapter

incorrectly states that the dual control links feature is supported on the SRX5000
and SRX3000 lines. This feature is supported on the SRX5000 line only.
■ The "Understanding the Data Plane" section in the Security Configuration Guide
incorrectly states the following: For most SRX-series chassis clusters and for all
J-series chassis clusters, the fabric link can be any pair of Ethernet interfaces
spanning the cluster. For SRX 210 devices, the fabric link can be any pair of
Ethernet ports. The correct information for this section is: For SRX Series chassis
clusters, the fabric link can be any pair of Ethernet interfaces spanning the cluster;
for J Series chassis clusters, any pair of Gigabit Ethernet interfaces.
CLI Reference
The “Services Configuration Statement Hierarchy” section in the JUNOS® Software

CLI Reference refers to the JUNOS Services Interfaces Configuration Guide, which has
the following error in the sections “Data Size” and “Configuring the Probe”:
■ The minimum data size required by the UDP timestamp probe is identified as 44
bytes. This is incorrect: the minimum data size required by the UDP timestamp probe
is 52 bytes.
CompactFlash Card Support
■ The JUNOS Software Administration Guide incorrectly states that JUNOS supports
a 256-MB CompactFlash card size. JUNOS supports only 512-MB and 1024-MB
CompactFlash card sizes.
Feature Support Reference
Table 31, Feature Support Reference for SRX Series and J Series Devices for JUNOS
Errata and Changes in Documentation for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services
Routers ■ 185
10.0, on page 27 incorrectly states that, for the secure and router context support
feature, the SRX3400, SRX3600, SRX5600, SRX650 and SRX5800 devices support
the selective stateless packet-based service feature.
These devices do not support selective stateless packet-based service feature.
Flow
■ The Junos OS CLI Reference and Junos OS Security Configuration Guide state that
the following aggressive aging statements are supported on all SRX Series devices
when in fact they are not supported on SRX3400, SRX3600, SRX5600, and
SRX5800 devices:
■ [edit security flow aging early-ageout]
■ [edit security flow aging high-watermark]
■ [edit security flow aging low-watermark
■ The “Understanding Selective Stateless Packet-Based Services” section in the

JUNOS Software Administration Guide states: “The following security features are
not supported with selective stateless packet-based services—stateful firewall
NAT, IPsec VPN, DOS screens, J-flow traffic analysis, WXC integrated security
module, security policies, zones, attack detection and prevention, PKI, ALGs,
and chassis cluster.” This statement is not correct. With selective packet-mode,
traffic that is sent through flow is able to use all of those services, even in a single
VR scenario.
Hardware Documentation
■ The Mini-PIM hardware information, formerly located in the SRX210 Services

Gateway Hardware Guide and the SRX240 Services Gateway Hardware Guide, is
now located in the new SRX Series Services Gateways for the Branch Physical
Interface Modules Hardware Guide.
■ The GPIM and XPIM information, formerly located in the SRX650 Services Gateway
Hardware Guide, is now located in the new SRX Series Services Gateways for the
Branch Physical Interface Modules Hardware Guide.
■ On SRX100 devices, the Alarm LED is off, indicating that the device is starting
up.
Note that when the device is on, if the Alarm LED is off, it indicates that no
alarms are present on the device.
■ The “Configuring Basic Settings for the SRX100 Services Gateway with a
Configuration Editor” section in the SRX100 Services Gateway Hardware Guide
contains the following inaccuracies:
■ The documentation incorrectly implies that the management port and
loopback address must be defined for the device.
■ The documentation should indicate that the SSH remote access can be
enabled.
■ The documentation indicates the CLI command set services ssh, which is
incorrect. The correct command is set system services ssh.
Routers
■ The J-Web Initial Set Up screenshot shown in the SRX210 Services Gateway Getting
Started Guide and the SRX240 Services Gateway Getting Started Guide contains
the following inaccuracies: The J-Web screenshot incorrectly shows the “Enable
DHCP on ge-0/0/0.0” checkbox as disabled in factory default settings. The J-Web
screenshot should indicate the “Enable DHCP on ge-0/0/0.0” check box as enabled
in factory default settings.
■ The SRX650 Services Gateway Hardware Guide erroneously indicates that the HA
SYS LED and HA LED components are not supported. As of JUNOS Release 9.6,
the LEDs function correctly and are fully supported by the SRX650 Services
Gateway.
Installing Software Packages
■ The current SRX210 documentation does not include the following information:
On SRX210 devices, the /var hierarchy is hosted in a separate partition (instead
of the root partition). If JUNOS Software installation fails as a result of insufficient
space:
1. Use the request system storage cleanup command to delete temporary files.
2. Delete any user-created files in both the root partition and under the /var
hierarchy.
■ The “Installing Software using the TFTPBOOT Method on the SRX100, SRX210,
and SRX650 Services Gateway” section in the JUNOS Software Administration
Guide contains the following inaccuracies:
■ The documentation incorrectly implies that the TFTPBOOT method requires
a separate secondary device to retrieve software from the TFTP server.
■ The documentation should indicate that the TFTPBOOT method does not
work reliably over slow speeds or large latency networks.
■ The documentation indicates that before starting the installation, you only
need to configure the gateway IP, device IP address, and device IP netmask
manually in some cases, when actually you need to configure them manually
in all cases.
■ The documentation should indicate that on the SRX100, SRX210, and SRX240
devices, only the ge-0/0/0 port supports TFTP in uboot and on the SRX650
device, all front-end ports support TFTP in uboot.
■ Step 2 of the “Installing JUNOS Software Using TFTPBOOT” instructions

should mention that the URL path is relative to the TFTP server’s TFTP root
directory. The instructions should also mention that you should store the
JUNOS Software image file in the TFTP server’s TFTP root directory.
■ The documentation should indicate that the TFTPBOOT method installs

software on the internal flash on SRX100, SRX210, and SRX240 devices,
whereas on SRX650 devices, the TFTP method can install software on the
internal or external CompactFlash card.
Routers ■ 187
■ The JUNOS Software Administration Guide is missing the following information

about installing software using USB on SRX100, SRX210, SRX240, and SRX650
devices:
You can install or recover the JUNOS Software using USB on SRX100, SRX210,
SRX240, and SRX650 devices. During the installation process, the installation
package from the USB is installed on the specified boot media.
Before you begin the installation, ensure the following prerequisites are met:
■ U-boot and Loader are up and running on the device.
■ USB is available with the JUNOS Software package to be installed on the
device.
To install the software image on the specified boot media:

1. Go to the Loader prompt. For more information on accessing the Loader
prompt, see “Accessing the Loader Prompt” on page 260 of the JUNOS
Software Administration Guide.
2. Enter the following command at the Loader prompt:

Loader>install URL
Where URL is file:///package
Example:
Loader>install file:///junos-srxsme-9.4-200811.0-domestic.tgz
When you are done, the file reads the package from the USB and installs the
software package. After the software installation is complete, the device boots
from the specified boot media.
NOTE: USB to USB installation is not supported. Also, on SRX100, SRX210, and
SRX240 devices, the software image will always be installed on NAND flash, but on
SRX650 devices, the software image can be installed either on the internal or external
CompactFlash card based on the boot media specified.
■ The SRX Series Integrated Convergence Services Configuration and Administration

Guide does not include show commands for this release.
■ On SRX210 and SRX240 devices with Integrated Convergence Services, the
Transport Layer Security (TLS) option for the SIP protocol transport is not
supported in this release. However, it is documented in the Integrated
Convergence Services entries of the JUNOS Software CLI Reference Guide.
Routers
■ The JUNOS Software Security Configuration Guide does not state that custom
attacks and custom attack groups in IDP policies can now be configured and
installed even when a valid license and signature database are not installed on
the device.
■ The JUNOS Software CLI Reference is missing information about the following
IDP policy template commands:
■ Use this command to display the download status of a policy template:
user@host>request security idp security-package download status
Done; Successfully downloaded from

(https://devdb.secteam.juniper.net/xmlexport.cgi).
■ Use this command to display the installation status of a policy template:
user@host>request security idp security-package install status
Done;policy-templates has been successfully updated into internal

repository
(=>/var/db/scripts/commit/templates.xsl)!
■ The ip-action definition on SRX3400, SRX3600, SRX5600, and SRX5800 in the

JUNOS Software Security Configuration Guide on page 504 table 73 is incorrect.
The correct definition should be: Enables you to implicitly block a source address
to protect the network from future intrusions while permitting legitimate traffic.
You can configure one of the following IP action options in application-level
DDoS: ip-block, ip-close, and ip-notify.
■ The exclude-context-values option in the JUNOS Software Security Configuration
Guide on page 810 table 101 is missing. The definition for exclude-context-values
should be: Configure a list of common context value patterns that should be
excluded from application-level DDoS detection. For example, if you have a Web
server that receives a high number of HTTP requests on home/landing page, you
can exclude it from application-level DDoS detection.
■ The JUNOS Software Security Configuration Guide incorrectly states that IDP is
not supported in transparent mode on SRX3400, SRX3600, SRX5600, and
SRX5800 devices. IDP is supported in transparent mode on those devices.
■ The IDP rule notification options listed in the JUNOS Software Security
Configuration Guide incorrectly include the Send Emails and Run Scripts options,
which are not supported in the JUNOS 10.0 Release.
J-Web
The following information pertains to SRX Series and J Series devices:

■ J-Web security package update Help page—The J-Web Security Package Update
Help page does not contain information about download status.
■ J-Web pages for stateless firewall filters—There is no documentation describing
the J-Web pages for stateless firewall filters. To find these pages in J-Web, go to
Routers ■ 189
Configure>Security>Firewall Filters, then select IPv4 Firewall Filters or IPv6

Firewall Filters. After configuring filters, select Assign to Interfaces to assign
your configured filters to interfaces.
■ There is no documentation describing the J-Web pages for media gateways. To
find these pages in J-Web, go to Monitor>Media Gateway.
Power over Ethernet (PoE)
The Power over Ethernet (PoE) section in the SRX210 Services Gateway Hardware
Guide (for JUNOS Release 10.0) incorrectly states that PoE+ support (IEEE 802.3 at
standard) is available on all SRX210 devices.
The guide should state that

■ PoE (IEEE 802.3 af) support is enabled only on the SRX210 Services Gateway
PoE model
■ PoE+ (IEEE802.3 at) support is enabled only on the SRX210 Services Gateway
with Integrated Convergence Services
Screens
The following information pertains to SRX Series and J Series devices:

■ In the JUNOS Software Design and Implementation Guide, the “Implementing
Firewall Deployments for Branch Offices” chapter contains incorrect screen
configuration instructions.
Examples throughout this guide describe how to configure screen options using
the set security screen screen-name CLI statements. Instead, you should use the
set security screen ids-option screen-name CLI statements. All screen configuration
options are located at the [set security screen ids-option screen-name] level of the
configuration hierarchy.
WLAN
The following information pertains to SRX210, SRX240, and SRX650 devices:

■ The Junos OS WLAN Configuration and Administration Guide lists available licenses
in increments of 2-, 4-, 8-, and 16-access points. Licenses are available only in
increments of 2-, 4-, 8-, and 14-access points.
■ The Junos OS WLAN Configuration and Administration Guide provides information
on AX411 access point clustering. Access point clustering is no longer supported.
Routers
Hardware Requirements for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
Hardware Requirements for JUNOS Release 10.0 for SRX Series Services Gateways and J
Series Services Routers
■ Transceiver Compatibility for SRX Series and J Series Devices on page 191
■ Power and Heat Dissipation Requirements for J Series PIMs on page 191
■ Supported Third-Party Hardware on page 191
■ J Series CompactFlash and Memory Requirements on page 192
Transceiver Compatibility for SRX Series and J Series Devices
We strongly recommend that only transceivers provided by Juniper Networks be

used on SRX Series and J Series interface modules. Different transceiver types
(long-range, short-range, copper, and so on) can be used together on multiport SFP
interface modules as long as they are provided by Juniper Networks. We cannot
guarantee that the interface module will operate correctly if third-party transceivers
are used.
Please contact Juniper Networks for the correct transceiver part number for your
device.
Power and Heat Dissipation Requirements for J Series PIMs
On J Series Services Routers, the system monitors the PIMs and verifies that the PIMs
fall within the power and heat dissipation capacity of the chassis. If power
management is enabled and the capacity is exceeded, the system prevents one or
more of the PIMs from becoming active.
CAUTION: Disabling power management can result in hardware damage if you

overload the chassis capacities.
You can also use CLI commands to choose which PIMs are disabled. For details about
calculating the power and heat dissipation capacity of each PIM and troubleshooting
procedures, see the J Series Services Routers Hardware Guide.
Supported Third-Party Hardware
The following third-party hardware is supported for use with J Series Services Routers
running Junos OS.
USB Modem We recommend using a U.S. Robotics USB 56K V.92 Modem, model number USR
5637.
Storage Devices The USB slots on J Series Services Routers accept a USB storage device or USB storage
device adapter with a CompactFlash card installed, as defined in the CompactFlash
Specification published by the CompactFlash Association. When the USB device is
installed and configured, it automatically acts as a secondary boot device if the
Hardware Requirements for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers ■ 191
primary CompactFlash card fails on startup. Depending on the size of the USB storage
device, you can also configure it to receive any core files generated during a router
failure. The USB device must have a storage capacity of at least 256 MB.
Table 9 on page 192 lists the USB and CompactFlash card devices supported for use
with the J Series Services Routers.
Table 9: Supported Storage Devices on the J Series Services Routers
Manufacturer Storage Capacity Third-Party Part Number
SanDisk—Cruzer Mini 2.0 256 MB SDCZ2-256-A10
SanDisk 512 MB SDCZ3-512-A10
SanDisk 1024 MB SDCZ7-1024-A10
Kingston 512 MB DTI/512KR
Kingston 1024 MB DTI/1GBKR
SanDisk—ImageMate USB 2.0 N/A SDDR-91-A15

Reader/Writer for CompactFlash Type I
and II
SanDisk CompactFlash 512 MB SDCFB-512-455
SanDisk CompactFlash 1 GB SDCFB-1000.A10
J Series CompactFlash and Memory Requirements
Table 10 on page 192 lists the CompactFlash card and DRAM requirements for J Series
Services Routers.
Table 10: J Series CompactFlash Card and DRAM Requirements
Minimum CompactFlash Minimum DRAM Maximum DRAM

Model Card Required Required Supported
J2320 512 MB 512 MB 1 GB
J2350 512 MB 512 MB 1 GB
J4350 512 MB 512 MB 2 GB
J6350 512 MB 1 GB 2 GB
192 ■ Hardware Requirements for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services Routers
Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways
■ Changes In Default Behavior and Syntax in JUNOS Release 10.0 for SRX Series
■ Upgrade and Downgrade Instructions for JUNOS Release 10.0 for SRX Series
Release 10.0 supports dual-root partitions on SRX100, SRX210, SRX240, and SRX650
devices. Dual-root partition allow the SRX Series devices to remain functional if there
is file system corruption and facilitate easy recovery of the corrupted file system.
SRX Series devices running JUNOS Release 9.6 or earlier support a single-root
partitioning scheme where there is only one root partition. Because both the primary
and backup JUNOS Software images are located on the same root partition, the
system fails to boot if there is corruption in the root file system. The dual-root
partitioning scheme guards against this scenario by keeping the primary and backup
JUNOS Software images in two independently bootable root partitions. If the primary
root partition becomes corrupted, the system will be able to boot from the backup
JUNOS Software image located in the other root partition and remain fully functional.
SRX Series devices that ship with JUNOS Release 10.0 are formatted with dual-root
partitions from the factory. SRX Series devices that are running JUNOS Release 9.6
or earlier can be formatted with dual-root partitions when upgrading to JUNOS Release
10.0.
NOTE: The dual-root partitioning scheme allows the SRX Series devices to remain
functional if there is file system corruption and facilitates easy recovery of the
corrupted file system. Although you can install JUNOS Release 10.0 on SRX100,
SRX210, SRX240, and SRX650 devices with the single-root partitioning scheme, we
strongly recommend the use of the dual-root partitioning scheme.
Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways ■ 193
Selection of Boot Media and Boot Partition
When the SRX Series device powers on, it tries to boot the JUNOS Software from the
default storage media. If the device fails to boot from the default storage media, it
tries to boot from the alternate storage media.
SRX100, SRX210, SRX240 devices boot from the following storage media (in order
of priority):
1. Internal NAND flash (default; always present)
2. USB storage device (alternate)
SRX650 devices boot from the following storage media (in order of priority):
1. Internal CompactFlash card (default; always present)
2. External CompactFlash card (alternate)
3. USB storage device (alternate)
With the dual-root partitioning scheme, the SRX Series device first tries to boot the
JUNOS Software from the primary root partition and then from the backup root
partition on the default storage media. If both primary and backup root partitions of
a media fail to boot, then the SRX Series device tries to boot from the next available
type of storage media. The SRX Series device remains fully functional even if it boots
the JUNOS Software from the backup root partition of storage media.
Important Differences Between Single-Root and Dual-Root Partitioning Schemes
Note the following important differences in how SRX Series devices use the two types
of partitioning systems.
■ With the single-root partitioning scheme, there is one root partition that contains
both the primary and backup JUNOS Software images. With the dual-root
partitioning scheme, the primary and backup copies of JUNOS Software are in
different partitions. The partition containing the backup copy is mounted only
when required.
■ With the dual-root partitioning scheme, when the request system software add
command is performed for a JUNOS Software package, the contents of the other
root partition are erased. The contents of the other root partition will not be valid
unless the installation is completed successfully.
■ With the dual-root partitioning scheme, after a new JUNOS Software image is
installed, add-on packages like jais or jfirmware should be reinstalled as required.
■ With the dual-root partitioning scheme, the request system software rollback CLI
command does not delete the current JUNOS Software image. It is possible to
switch back to the image by issuing the rollback command again.
■ With the dual-root partitioning scheme, the request system software delete-backup
CLI command does not take any action. The JUNOS Software image in the other
root partition will not be deleted.
194 ■ Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways
Upgrade Methods
SRX Series devices that ship from the factory with JUNOS Release 10.0 are formatted
with the dual-root partitioning scheme.
Existing SRX Series devices that are running JUNOS Release 9.6 or earlier use the
single-root partitioning scheme. While upgrading these routers to JUNOS Release
10.0, you can choose to format the storage media with dual-root partitions (strongly
recommended) or retain the existing single-root partitioning.
Certain JUNOS Software upgrade methods format the internal media before
installation, whereas other methods do not. To install JUNOS Release 10.0 with the
dual-root partitioning scheme, you must use an upgrade method that formats the
internal media before installation.
The following upgrade methods format the internal media before installation:
■ Installation from the boot loader using a TFTP server
■ Installation from the boot loader using a USB storage device
■ Installation from the CLI using the special partition option (available in JUNOS
Release 10.0)
The following upgrade methods retain the existing partitioning scheme:

■ Installation using the CLI
■ Installation using J-Web
WARNING: Upgrade methods that format the internal media before installation wipe
out the existing contents of the media. Only the current configuration will be
preserved. Any important data should be backed up before starting the process.
NOTE: Once the media has been formatted with the dual-root partitioning scheme,
you can use conventional CLI or J-Web installation methods, which retain the existing
partitioning and contents of the media, for subsequent upgrades.
Upgrading to JUNOS Release 10.0 Without Transitioning to Dual-Root Partitioning
If dual-root partitioning is not desired, use the conventional CLI and J-Web installation
methods, as described in the Junos OS Administration Guide for Security Devices.
Upgrading to JUNOS Release 10.0 with Dual-Root Partitioning
To format the media with dual-root partitioning while upgrading to Release 10.0, use
one of the following installation methods:
■ Installation from the boot loader using a TFTP server. This method is preferable
if console access to the system is available and a TFTP server is available in the
network.
■ Installation from the boot loader using a USB storage device. This method is
preferable if console access to the system is available and the system can be
physically accessed to plug in a USB storage device.
■ Installation from CLI using the special partition option. This method is
recommended only when console access is not available. This installation can
be performed remotely.
NOTE: After upgrading to JUNOS Release 10.0, the U-boot and boot loader must be
upgraded for the dual-root partitioning scheme to work properly.
Each of the aforementioned methods of installing JUNOS 10.0 with dual-root

partitioning is described in detail in the following sections:
■ Installing from the Boot Loader Using a TFTP Server on page 196
■ Installing from the Boot Loader Using a USB Storage Device on page 197
■ Installing from the CLI Using the partition Option on page 197
■ Upgrading the Boot Loader on page 198
Installing from the Boot Loader Using a TFTP Server
See the Junos OS Administration Guide for Security Devices for detailed information
on installing JUNOS Software using a TFTP server.
To install JUNOS Release 10.0 from the boot loader using a TFTP server:
1. Upload the JUNOS Software image to a TFTP server.
2. Stop the device at the loader prompt and set the following variables:
■ ipaddr
loader> set ipaddr=<IP-address-of-the-device>
■ netmask
loader> set netmask=<netmask>
■ gatewayip
loader> set gatewayip=<gateway-IP-address>
■ serverip
loader> set serverip=<TFTP-server-IP-address>
3. Install the image using the following command at the loader prompt:
loader> install tftp://<server-ip>/<image-path-on-server>
For example:
loader> install tftp://10.77.25.12/junos-srxsme-10.0R2-domestic.tgz
This will format the internal media and install the new JUNOS Software image
on the media with dual-root partitioning.
4. Once the system boots up with JUNOS Release 10.0, upgrade the U-boot and
boot loader immediately. See “Upgrading the Boot Loader” on page 198.
Installing from the Boot Loader Using a USB Storage Device
To install JUNOS Release 10.0 from the boot loader using a USB storage device:
1. Format a USB storage device in MS-DOS format.
2. Copy the JUNOS Software image onto the USB storage device.
3. Plug the USB storage device into the device.
4. Stop the device at the loader prompt and issue the following command:
loader> install file:///<image-path-on-usb>
For example:
loader> install file:///junos-srxsme-10.0R2-domestic.tgz
This will format the internal media and install the new JUNOS Software image
on the media with dual-root partitioning.
5. Once the system boots up with JUNOS Release 10.0, upgrade the U-boot and
boot loader immediately. See “Upgrading the Boot Loader” on page 198.
Installing from the CLI Using the partition Option
To install JUNOS Release 10.0 with the partition option:

1. Upgrade the device to JUNOS Release 10.0 or later using the CLI or J-Web. This
will install the new image with the older single-root partitioning scheme.
2. After the device reboots with JUNOS Release 10.0, upgrade the boot loader to
version 1.5. See “Upgrading the Boot Loader” on page 198.
3. Reinstall the 10.0 image from JUNOS CLI using the request system software add
command with the partition option. This will copy the image to the device, then
reboot the device for installation. The device will boot up with the 10.0 image
installed with the dual-root partitioning scheme.
NOTE: This process might take 15–20 minutes. The system will not be accessible
over the network during this time.
Upgrading the Boot Loader
To upgrade the boot loader to version 1.5:

1. Upgrade to JUNOS Release 10.0 (with or without dual-root support enabled).
The JUNOS 10.0 image contains the latest boot loader binaries in the following
path: /boot/uboot, /boot/loader.
2. Enter the shell prompt.
3. Run the following command from the shell prompt:
bootupgrade –u /boot/uboot –l /boot/loader
Installing JUNOS Release 9.6 or Earlier Release on Systems with Dual-Root

Partitioning
JUNOS Release 9.6 and earlier is not compatible with the dual-root partitioning
scheme. These releases can only be installed if the media is reformatted with
single-root partitioning. Any attempt to install JUNOS Release 9.6 or earlier on a
device with dual-root partitioning without reformatting the media will fail with an
error. You must install the JUNOS Release 9.6 or earlier image from the boot loader
using a TFTP server or USB storage device.
NOTE: You cannot install a JUNOS Release 9.6 or earlier package on a system with
dual-root partitioning using the JUNOS CLI or J-Web. An error will be returned if this
is attempted.
NOTE: You do not need to reinstall the earlier version of the boot loader.
Reinstalling the Single-Root Partition Release Over TFTP
To reinstall JUNOS Software from the boot loader using a TFTP server:
1. Upload the JUNOS Software image to a TFTP server.
2. Stop the device at the loader prompt and set the following variables:
■ ipaddr
loader> set ipaddr=<IP-address-of-the-device>
■ netmask
loader> set netmask=<netmask>
■ gatewayip
loader> set gatewayip=<gateway-IP-address>
■ serverip
loader> set serverip=<TFTP-server-IP-address>
3. Install the image using the following command at the loader prompt:
user@host> install tftp://<server-ip>/<image-path-on-server>
For example:
loader> install tftp://10.77.25.12/junos-srxsme-9.6R1-domestic.tgz
This will format the internal media and install the JUNOS Software image on the
media with single-root partitioning.
Reinstalling the Single-Root Partition Release Using USB
To reinstall JUNOS Software from the boot loader using a USB storage device:
1. Format a USB storage device in MS-DOS format.
2. Copy the JUNOS Software image onto the USB storage device.
3. Plug the USB storage device into the SRX Series device.
4. Stop the device at the loader prompt and issue the following command:
user@host> install file://<image-path-on-usb>
For example:
loader> install file:///junos-srxsme-9.6R1-domestic.tgz
This will format the internal media and install the JUNOS Software image on the
media with single-root partitioning.
Recovery of the Primary JUNOS Software Image with Dual-Root Partitioning Scheme
If the SRX Series Services Gateway is unable to boot from the primary JUNOS Software
image, and boots up from the backup JUNOS Software image in the backup root
partition, a message is displayed on the console at the time of login indicating that
the device has booted from the backup JUNOS Software image:
login: user
Password:
***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** **
** It is possible that the active copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the active copy in case **
** it has been corrupted. **
** **
***********************************************************************
Because the system is left with only one functional root partition, you should
immediately restore the primary JUNOS Software image. This can be done by installing
a new image using the CLI or J-Web. The newly installed image will become the
primary image, and the device will boot from it on the next reboot.
CLI Changes
This section describes CLI changes when the SRX Series device runs JUNOS Release
10.0 with the dual-root partitioning scheme.
■ Changes to the Snapshot CLI on page 200
■ partition Option with the request system software add Command on page 201
Changes to the Snapshot CLI
On an SRX Series device, you can configure the primary or secondary boot device
with a “snapshot” of the current configuration, default factory configuration, or rescue
configuration. The snapshot feature is modified to support dual-root partitioning.
The options as-primary, swap-size, config-size, root-size, var-size, and data-size are not
supported on SRX Series devices.
With the dual-root partitioning scheme, performing a snapshot to a USB storage

device that is less than 1 GB is not supported.
With the dual-root partitioning scheme, you must use the partition option when
performing a snapshot. If the partition option is not specified, the snapshot operation
fails with a message that the media needs to be partitioned for snapshot.
The output for the show system snapshot CLI command is changed in devices with
dual-root partitions to show the snapshot information for both root partitions:
user@host> show system snapshot media usb

Information for snapshot on usb (/dev/da1s1a) (primary)
Creation date: Jul 24 16:16:01 2009
JUNOS version on snapshot:
junos : 10.0I20090723_1017-domestic
Information for snapshot on usb (/dev/da1s2a) (backup)
Creation date: Jul 24 16:17:13 2009
JUNOS version on snapshot:
junos : 10.0I20090724_0719-domestic
NOTE: You can use the show system snapshot media internal command to determine
the partitioning scheme present on the internal media. Information for only one root
is displayed for single-root partitioning, whereas information for both roots is
displayed for dual-root partitioning.
NOTE: Any removable media that has been formatted with dual-root partitioning
will not be recognized correctly by the show system snapshot CLI command on
systems that have single-root partitioning. Intermixing dual-root and single-root
formatted media on the same system is strongly discouraged.
partition Option with the request system software add Command
A new partition option is available with the request system software add CLI command.
Using this option will cause the media to be formatted and repartitioned before the
software is installed.
When the partition option is used, the format and install process is scheduled to run
on the next reboot. Therefore, it is recommended that this option be used together
with the reboot option.
For example:
user@host>request system software add junos-srxsme-10.0R2-domestic.tgz no-copy

no-validate partition reboot
Copying package junos-srxsme-10.0R2-domestic.tgz to var/tmp/install
Rebooting ...
The system will reboot and complete the installation.
WARNING: Using the partition option with the request system software add CLI
command erases the existing contents of the media. Only the current configuration
is preserved. Any important data should be backed up before starting the process.
Maximizing ALG Sessions

On SRX3400, SRX3600, SRX5600, and SRX5800 devices, by default, the session
capacity number for RTSP, FTP, and TFTP ALG sessions is 10,000 per flow SPU. The
maximize-alg-sessions option enables you to increase defaults as follows:
■ RTSP, FTP, and TFTP ALG session capacity: 25,000 sessions per flow SPU
■ TCP Proxy connection capacity: 40,000 sessions per flow SPU
NOTE: Flow session capacity will be reduced to half per flow SPU and the above
capacity numbers will not change on the central point SPU.
You can configure maximum ALG sessions as follows:
security {
forwarding-process {
application-services {
maximize-alg-sessions;
}
}
}
You must reboot the device (and its peer in the chassis cluster) for the configuration
to take effect.
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing
Engine
A second Routing Engine is required for each device in a cluster if you are using the
dual control links feature (SRX5000 line only). The second Routing Engine does not
provide backup functionality; its purpose is only to initialize the switch on the Switch
Control Board (SCB). The second Routing Engine must be running JUNOS Release
10.0 or later.
Because you cannot run the CLI or enter configuration mode on the second Routing
Engine, you cannot upgrade the JUNOS Software image with the usual upgrade
commands. Instead, use the master Routing Engine (RE0) to create a bootable USB
storage device, which you can then use to install a software image on the second
Routing Engine (RE1).
To upgrade the software image on the second Routing Engine (RE1):

1. Use FTP to copy the installation media into the /var/tmp directory of the master
Routing Engine (RE0).
2. Insert a USB storage device into the USB port on the master Routing Engine
(RE0).
3. In the UNIX shell, navigate to the /var/tmp directory:
start shell
202 ■ Maximizing ALG Sessions

Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing Engine
cd /var/tmp
4. Log in as root or superuser:
su [enter]
password: [enter SU password]
5. Issue the following command;
dd if=installMedia of=/dev/externalDrive bs=64
where
■ externalDrive—Refers to the removable media name. For example, the
removable media name on an SRX5000 line device is da0 for both Routing
Engines.
■ installMedia—Refers to the installation media downloaded into the /var/tmp
directory. For example, install-media-srx5000-10.0R2-domestic.tgz.
The following code example can be used to write the image that you copied to
the master Routing Engine (RE0) in step 1 onto the USB storage device:
dd if=install-media-srx5000-10.0R2-domestic.tgz of=/dev/da0 bs=64k
6. Log out as root or superuser:
exit
7. After the software image is written to the USB storage device, remove the device
and insert it into the USB port on the second Routing Engine (RE1).
8. Move the console connection from the master Routing Engine (RE0) to the second
Routing Engine (RE1), if you do not already have a connection.
9. Reboot the second Routing Engine (RE1). Issue the following command:
# reboot
■ When the following system output appears, press y:
WARNING: The installation will erase the contents of your disks.

Do you wish to continue (y/n)?
■ When the following system output appears, remove the USB storage device
and press Enter:
Eject the installation media and hit [Enter] to reboot?
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing Engine ■ 203
Upgrade and Downgrade Instructions for JUNOS Release 10.0 for SRX Series Services
In order to upgrade to JUNOS Release 10.0 or later, your device must be running
one of the following JUNOS Software releases:
■ 9.1S1
■ 9.2R4
■ 9.3R3
■ 9.4R3
■ 9.5R1 or later
If your device is running an earlier release, upgrade to one of these releases and then
to the 10.0 release. For example, to upgrade from Release 9.2R1, first upgrade to
Release 9.2R4 and then to Release 10.0R2.
For additional upgrade and download information, see the JUNOS Software Migration
Guide.
204 ■ Upgrade and Downgrade Instructions for JUNOS Release 10.0 for SRX Series Services Gateways and J Series Services
Routers
JUNOS Software Release Notes for EX Series Switches
JUNOS Software Release Notes for EX Series Switches

■ New Features in JUNOS Release 10.0 for EX Series Switches on page 205
■ Changes in Default Behavior and Syntax in JUNOS Release 10.0 for EX Series
Switches on page 209
■ Limitations in JUNOS Release 10.0 for EX Series Switches on page 210
■ Outstanding Issues in JUNOS Release 10.0 for EX Series Switches on page 211
■ Resolved Issues in JUNOS Release 10.0 for EX Series Switches on page 216
■ Errata in Documentation for JUNOS Release 10.0 for EX Series
■ Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series
New Features in JUNOS Release 10.0 for EX Series Switches

New features in Release 10.0 of JUNOS Software for EX Series switches are described
in this section.
Not all EX Series software features are supported on all EX Series platforms in the
current release. For a list of all EX Series software features and their platform support,
see EX Series Switch Software Features Overview.
New features are described on the following pages:

■ Hardware on page 205
■ Access Control and Port Security on page 206
■ Bridging, VLANs, and Spanning Trees on page 206
■ Ethernet Switching on page 206
■ Interfaces on page 207
■ Layer 2 and Layer 3 Protocols on page 207
■ Management and RMON on page 207
■ Packet Filters on page 208
■ Port Mirroring on page 208
■ Virtual Chassis on page 208
Hardware
■ Ability to remove and replace uplink modules in EX3200 and EX4200 switches
without powering off the switch or disrupting switch functions—You can now
remove and replace uplink modules in EX3200 and EX4200 switches without
powering off the switch or disrupting switch functions. The switch detects the
newly installed uplink module and creates the required interfaces if the uplink
module has transceivers installed in its ports and when new transceivers are
installed in those ports.
JUNOS Software Release Notes for EX Series Switches ■ 205

■ New optical transceiver support—The SFP uplink module in EX3200 and EX4200
switches now supports two new optical transceivers:
■ EX-SFP-1FE-LX40K (100Base-LX40K, 40 km)
■ EX-SFP-1FE-LH (100Base-LH/100Base-ZX, 80 km)
■ SFP+ direct attach cable support—EX8200 switches now support the following
SFP+ direct attach cables:
■ EX-SFP-10GE-DAC-1m
Access Control and Port Security
■ Proxy ARP support—On EX Series switches, proxy ARP can now be configured
in restricted mode (in addition to the default mode of unrestricted). When an
interface is set to restricted proxy ARP mode, it does not proxy for hosts on the
same subnet. Also, now when you configure proxy ARP on an interface, it is set
on that interface only and is not set globally. Proxy ARP is now supported on
EX8200 switches in addition to EX3200 and EX4200 switches.
Bridging, VLANs, and Spanning Trees
■ Multiple VLAN Registration Protocol (MVRP)—Multiple VLAN Registration

Protocol (MVRP) is used to manage dynamic VLAN registration in a LAN. MVRP
is an application protocol of the Multiple Registration Protocol (MRP) and is
defined in the IEEE 802.1ak standard. MRP and MVRP were designed by IEEE
to perform the same functions as Generic Attribute Registration Protocol (GARP)
and GARP VLAN Registration Protocol (GVRP) while overcoming some of the
limitations in GARP and GVRP, in particular limitations on bandwidth usage in
large networks with large numbers of VLANs.
■ Support for unknown unicast forwarding on EX8200 switches—The ability to
channel unknown unicast packets to a specific trunk interface is now available
on EX8200 switches. Unknown unicast traffic consists of unicast packets with
unknown destination MAC addresses. By default, the switch floods these unicast
packets that are traveling in a VLAN to all interfaces that are members of the
VLAN. Forwarding this type of traffic to interfaces on the switch can trigger a
security issue. The LAN is suddenly flooded with packets, creating unnecessary
traffic that leads to poor network performance or even a complete loss of network
service. This is known as a traffic storm. To prevent a storm, you can disable
the flooding of unknown unicast packets to all interfaces by channeling them to
a specific trunk interface.
Ethernet Switching
■ VLAN ID translation—VLAN ID translation is used to map traffic with different

VLAN ID tags to a single VLAN. When VLAN ID translation is used to map different
206 ■ New Features in JUNOS Release 10.0 for EX Series Switches

New Features in JUNOS Release 10.0 for EX Series Switches
VLAN ID tags to a single VLAN, VLAN tags are swapped for a new VLAN tag. No
new tags are added to the traffic.
VLAN ID translation is useful whenever traffic that requires identical treatment
from multiple networks is traversing access interfaces on an EX Series switch.
VLAN ID translation is therefore useful as part of certain Q-in-Q tunneling
configurations, but it can also be used without Q-in-Q tunneling.
■ Layer 2 protocol tunneling—Layer 2 protocol tunneling (L2PT) allows you to
send Layer 2 protocol data units (PDUs) across a service provider network and
deliver them to switches that are not part of the local broadcast domain.
Interfaces
■ Support for interface ranges—The interface-range configuration statement helps

group interfaces of the same type that share a common configuration profile,
thus reducing the time and effort required to configure interfaces on EX Series
switches. The configurations common to all the interfaces can be included in
the interface-range definition.
■ Support for digital optical monitoring (DOM)—You can view diagnostic details
for the Gigabit Ethernet SFP, SFP+, or XFP transceivers installed in EX3200 or
EX4200 switches or for the Gigabit Ethernet SFP or SFP+ transceivers installed
in EX8200 switches by issuing the CLI operational mode command show
interfaces diagnostics optics.
■ Enhancement to Link Aggregation Control Protocol (LACP)—When a
dual-homed server is deployed with a switch, the network interface cards form
a LAG with the switch. During a server upgrade the server might not be able to
exchange LACP PDUs. In such a situation you can configure an interface to be
in the UP state even if no PDUs are exchanged.
Layer 2 and Layer 3 Protocols
■ Virtual routing and forwarding (VRF) multicast—EX Series switches are now
able to forward VRF multicast traffic.
■ Virtual Router Redundancy Protocol (VRRP) for IPv6—For Gigabit Ethernet,
10-Gigabit Ethernet, and logical interfaces, you can configure VRRP for IPv6.
VRRP for IPv6 allows hosts on a LAN to make use of redundant virtual routers
on that LAN without requiring more than the static configuration of a single
default route on the hosts.
Management and RMON
■ System snapshot—You can create copies of the software running on an EX

Series switch by using the system snapshot feature. The system snapshot feature
takes a snapshot of the files currently used to boot the switch—the currently
running JUNOS Software, the active configuration, and the rescue
configuration—and copies all of these files into the destination media within the
switch. You can then use these snapshots to boot the switch after the next reload
or as a backup-boot or file-saving option.
New Features in JUNOS Release 10.0 for EX Series Switches ■ 207

■ sFlow technology support on EX8200 switches—sFlow technology is now

supported on EX8200 switches.
■ Ethernet OAM link fault management—Ethernet OAM link fault management
(LFM) is now supported on EX8200 switches.
Packet Filters
■ Support for firewall filters on aggregated Ethernet interfaces in EX8200

switches—EX8200 switches now support firewall filters on Layer 2 and Layer 3
aggregated Ethernet interfaces. On aggregated Ethernet interfaces, firewall filters
are supported on the following bind points:
■ Ingress—ports and router interfaces
■ Egress—ports and router interfaces
■ Dynamic allocation of TCAM to firewall filters in EX3200 and EX4200

switches—On EX3200 and EX4200 switches, the ternary content addressable
memory (TCAM) usage limits set for specific types of firewall filters (such as
firewall filters applied to ports, VLANs, or router interfaces) have been removed.
TCAM is now allocated dynamically to firewall filters as they are configured,
regardless of their type. An error message is generated when you try to configure
a firewall filter after the TCAM is full.
Port Mirroring
■ Enhancement to remote port mirroring—You can now prevent flooding of

mirrored traffic to the member interfaces of the VLAN in the intermediate switch
by setting ingress-only or egress-only attributes on the members of the VLAN.
Virtual Chassis
■ Automatic software update on Virtual Chassis member switches—The

automatic software update feature allows you to automatically update the software
version on prospective member switches as they are added so that they can join
a Virtual Chassis configuration.
■ Configuring Virtual Chassis ports (VCPs) from the LCD—You can configure
the uplink module ports and the EX4200-24F network ports as VCPs using the
LCD panel on the front of EX4200 switches in a Virtual Chassis configuration.
Related Topics ■ Changes in Default Behavior and Syntax in JUNOS Release 10.0 for EX Series
208 ■ New Features in JUNOS Release 10.0 for EX Series Switches

Changes in Default Behavior and Syntax in JUNOS Release 10.0 for EX Series Switches
■ Errata in Documentation for JUNOS Release 10.0 for EX Series Switches on

page 217
■ Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series Switches
on page 218
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for EX Series Switches
The following current system behavior, configuration statement usage, or operational
mode command usage might not yet be documented in the JUNOS Software
documentation:
■ EX Series switches now support the show multicast rpf instance instance-name
command.
■ On EX3200 switches and EX4200 switches, the request system power-off

other-routing-engine command and the request system power-off both-routing-engines
command are disabled.
■ The output of the show chassis hardware command for EX3200 switches and
EX4200 switches has been changed. The Description field in the output now
displays SFP-100-LX40 for the 100Base-LH interface and SFP-100-LH for the
100Base-ZX interface.
■ You no longer need to reboot the switch for changes to the operating mode of
an SFP+ uplink module to take effect, unless one of the ports is a Virtual Chassis
port. If any port on an SFP+ uplink module has been configured as a Virtual
Chassis port, then the change in operating mode takes effect the next time the
switch is rebooted.
The CLI command for configuring the SFP+ uplink module has been changed
to include a warning that describes this behavior. The message is displayed
regardless of SFP+ uplink module port configuration. For example:
{master:1}[edit]
user@ex4200-24p-12# set chassis fpc 0 pic 1 sfpplus pic-mode 1g
[edit]
'juniper-config'
warning: If any port in this pic is used as vc-port, sfpplus pic-mode
change will only be applied after reboot of the fpc; otherwise no reboot
required.
■ On EX8200 switches, you can now add the power-off fpc option to the request
system halt and request system reboot commands so that line cards are powered
off first after the commands are issued. These commands, with the new option,
power off all line cards in a switch with a single Routing Engine or a switch with
master and backup Routing Engines and on which GRES is not enabled. These
commands reduce the delay in shutting down the interfaces on line cards when
Changes in Default Behavior and Syntax in JUNOS Release 10.0 for EX Series Switches ■ 209
the switch is halted or restarted and facilitate faster convergence of protocols

and updates to MAC address tables in devices connected to the switch.
Related Topics ■ New Features in JUNOS Release 10.0 for EX Series Switches on page 205
page 217
on page 218
Limitations in JUNOS Release 10.0 for EX Series Switches

This section lists the limitations in JUNOS Release 10.0R4 for EX Series switches.
■ On EX Series switches, configuring more than 64,000 MAC address clone routes
in a single VLAN causes the Routing Engine to create core files and reboot.
Class of Service
■ On EX4200 switches, the traffic is shaped at rates above 500 Kbps, even when
the shaping rate configured is 500 Kbps or less.
Infrastructure
■ On EX Series switches, an SNMP query fails when the SNMP index size of a table
is greater than 128 bytes, because the Net SNMP tool does not support SNMP
index sizes greater than 128 bytes.
■ Spanning-tree, GVRP, or IGMP snooping configuration windows might load slowly
in the J-Web interface. Wait till the windows load completely before entering
information, or some information might get lost.
■ On EX Series switches, the show snmp mib walk etherMIB command does not
display any output, even though the etherMIB is supported. This problem occurs
because the values are not populated at the module level— they are populated
at the table level only. You can issue show snmp mib walk dot3StatsTable, show
snmp mib walk dot3PauseTable, and show snmp mib walk dot3ControlTable
commands to display the output at the table level.
210 ■ Limitations in JUNOS Release 10.0 for EX Series Switches

Outstanding Issues in JUNOS Release 10.0 for EX Series Switches
Interfaces
■ EX Series switches do not support queued packet counters. Therefore, the queued
packet counter in the output of the show interfaces interface-name extensive
command always displays a count of 0 and is never updated.
■ On EX3200 and EX4200 switches, when port mirroring is configured on any
interface, the mirrored packets leaving a tagged interface might contain an
incorrect VLAN ID.
■ On EX8200 switches, port mirroring configuration on a Layer 3 interface with
the output configured to a VLAN is not supported.
■ On EX8200 switches, when an egress VLAN that belongs to a routed VLAN
interface (RVI) is configured as the input for a port mirroring analyzer, the
analyzer incorrectly appends a dot1q (802.1Q) header to the mirrored packets
or does not mirror any packets at all. As a workaround, configure a port mirroring
analyzer with each port of the VLAN as egress input.
■ EX Series switches do not support IPv6 interface statistics. Therefore, all values
in the output of the show snmp mib walk ipv6IfStatsTable command always display
a count of 0.
page 217
on page 218

The following are outstanding issues in JUNOS Release 10.0R4 for EX Series switches.
The identifier following the description is the tracking number in our bug database.
NOTE: Other software issues that are common to both EX Series switches and M,
MX, and T Series routers are listed in “Issues in JUNOS Release 10.0 for M Series,
MX Series, and T Series Routers” on page 54.
Outstanding Issues in JUNOS Release 10.0 for EX Series Switches ■ 211

NOTE: The following PRs that were previously included in the JUNOS Release 10.0R3
release notes as outstanding issues have been removed, because these issues are
not present in JUNOS Release 10.0R4 for EX Series switches:
313195, 397290, 406714, 409934, 423694
■ When you have configured more than 1024 supplicants on a single interface,
802.1X authentication might not work as expected and causes the 802.1X process
(dot1xd) to fail. [PR/444082]
■ The switch always uses the revert-interval value that is configured at the [edit
access] hierarchy level, and ignores any revert-interval value that is configured
at the [edit access profile] hierarchy level. If no value is configured, the router
uses the default value of 600 seconds. [PR/454040]
■ On EX Series switches, DHCP relay between routing instances does not work.
[PR/515184]
■ A 802.1X supplicant might obtain a DHCP address in the connecting and the
held states when a local DHCP server is configured. [PR/526884]
■ The 802.1X authentication process might not work if a static MAC bypass address
is configured without a VLAN assignment. [PR/546001]
■ On EX8200 switches, when the links on STP-enabled routed VLAN interfaces

(RVIs) come up, control packets might egress before the STP BPDUs. [PR/300576]
■ When Multiple VLAN Registration Protocol (MVRP) and MSTP are enabled together
on EX Series switches, convergence does not occur between MVRP and MSTP.
[PR/449248]
■ On EX Series switches, when the VLAN with the lowest-numbered VLAN ID is
down, the show ntp associations command output displays the following message:
/usr/bin/ntpq: write to localhost failed: No route to host
[PR/466595]
■ When MVRP and VSTP are enabled together on EX Series switches, convergence
does not occur between MVRP and VSTP. [PR/477019]
Class of Service
■ On EX3200 and EX4200 switches, the show interface queue command output
displays the count of transmitted packets and queued packets together under
the field Queued instead of displaying the values separately under the Queued
and Transmitted fields. [PR/259525]
212 ■ Outstanding Issues in JUNOS Release 10.0 for EX Series Switches

■ On EX8200 switches, classification of packets using ingress firewall filter rules

with forwarding-class and loss-priority configurations does not rewrite the DSCP
or 802.1p bits. Rewriting of packets is determined by the forwarding-class and
loss-priority values set in the DSCP classifier applied on the interface. [PR/399331]
Firewall Filters
■ On EX Series switches, when interface ranges or VLAN ranges are used in

configuring firewall filters, egress firewall filter rules take more than 5 minutes
to install. [PR/468806]
Hardware
■ When an EX8216 switch power cycle completes, the Last reboot reason for the
master and backup Routing Engines in the show chassis routing-engine command
output might display incorrect values. [PR/415569]
Infrastructure
■ The RADIUS request sent by an EX Series switch contains both Extensible

Authentication Protocol (EAP) Identity Response and State attributes. [PR/300790]
■ On EX8200 switches, RIP version 1 does not work properly. [PR/394905]
■ In the J-Web interface, you cannot commit some configuration changes in the
Ports Configuration page and in the VLAN Configuration page because of the
following limitations for port mirroring ports and port mirroring VLANs:
■ A port configured as the output port for an analyzer cannot be a member of
any VLAN other than the default VLAN.
■ A VLAN configured to receive analyzer output can be associated with only
one port.
[PR/400814]
■ When you issue the request system power-off command, the switch halts instead
of turning off power. [PR/415772]
■ In the J-Web interface, uploading a software package to the switch might not
work properly if you are using Microsoft Internet Explorer version 7. [PR/424859]
■ In the J-Web interface, the Ethernet Switching monitoring page might not display
monitoring details if there are more than 13,000 MAC entries on the switch.
[PR/425693]
■ If an SRE module, RE module, SF module, line card, or Virtual Chassis member
is in offline mode, the J-Web interface might not update the dashboard image
accordingly. [PR/431441].
■ In the J-Web interface, in the Port Security Configuration page, you are required
to configure action when you configure MAC limit even though configuring an
action value is not mandatory in the CLI. [PR/434836]

■ On EX8200 switches, if IS-IS is enabled on routed VLAN interfaces (RVIs), IS-IS

adjacency states go down and come up after a graceful Routing Engine switchover
(GRES). [PR/429589, 442373]
■ In the J-Web interface, changing the port role from Desktop, Desktop and Phone,
and Layer 2 Uplink to another port role might not remove the configurations for
enabling dynamic ARP inspection and DHCP snooping. [PR/445080]
■ On EX Series switches, MAC addresses not present in the forwarding database
(FDB) because of hash collision are not removed from the Ethernet switching
process (eswd). These MAC addresses do not age out of the Ethernet switching
table even if traffic is stopped completely and are never relearned when traffic
is sent to these MAC addresses, even when there is no hash collision. [PR/451431]
■ On EX Series switches, aggregated Ethernet interfaces might go down because
the software forwarding process (SFID) stops functioning and generates core
files. [PR/452622]
■ In the J-Web interface, the DSCP classifiers associated with a logical interface
might not appear to be mapped properly when you are editing that list of
classifiers. This issue might affect the Delete functionality also. [PR/455670]
■ On EX8200 switches, when IGMP snooping is enabled, the IPv6 multicast Layer
2 control frame is not forwarded to other interfaces in the same VLAN.
[PR/456700]
■ In the J-Web interface, the menu on the left side of the J-Web pages and contents
of the J-Web pages might disappear when you click twice on the Troubleshoot
tab. As a workaround, click on the Dashboard tab or Configure tab, and click
again on the Troubleshoot tab to display the menu and contents of the page.
[PR/459936]
■ In the J-Web interface, the Chassis Information page (Monitor > System View
> Chassis Information) displays an incorrect name in the Routing engine
module field for the master switch and displays no value in the Routing engine
module field for the backup switch. [PR/463811]
■ The jnxFirewall MIB might not be populated with a firewall filter configuration.
As a workaround, perform the following configuration to skip the firewall MIB:
user@switch# show snmp

view firewall_exclude {
oid .1.3.6.1.4.1.2636.3.5 exclude;
oid .1;
}
community public {
view firewall_exclude;
authorization read-only;
}
[PR/464061]
■ In the J-Web interface, in the OSPF Global Settings table in the OSPF Configuration
page, the Global Information table in the BGP Configuration page, or the Add
Interface window in the LACP Configuration page, if you try to change the position
of columns using the drag-and-drop method, only the column header moves to
the new position instead of the entire column. [PR/465030]
214 ■ Outstanding Issues in JUNOS Release 10.0 for EX Series Switches

■ When you have a large number of static routes configured, and if you have
navigated to pages other than page 1 in the Route Information table in the J-Web
interface (Monitor > Routing > Route Information), changing the Route Table
to query other routes refreshes the page but does not return to page 1. For
example, if you run the query from page 3 and the new query returns very few
results, the Route Information table continues to display page 3 with no results.
To view the results, navigate to page 1 manually. [PR/476338]
■ In the J-Web interface, the dashboard does not display the uplink ports when
transceivers are not plugged into the ports. [PR/477549]
■ On EX3200 and EX4200 switches, the logical interface counters of the member
interface in a Layer 3 LAG might keep incrementing even though the physical
interface is down. [PR/493188]
■ When you access the J-Web interface using Microsoft Internet Explorer over an
HTTPS connection, and try to save a report from the View Events page (Monitor
> Events and Alarms > View events) an error message might be displayed.
[PR/542887]
Interfaces
■ The system log might display the following messages when the monitor interfaces
interface-name command is issued simultaneously from multiple Telnet sessions:
Nov 21 11:55:29 st-grande02-re0 /kernel: ifd_pfestat_req_wait_internal:

ifd ge-6/0/40, stats_req 0xa8f33d80, sreq_id 41028, new sreq_id 42053
Nov 21 11:55:44 st-grande02-re0 login: LOGIN_INFORMATION: User regress
logged in from host 172.24.104.140 on device ttyp5
Nov 21 11:55:45 st-grande02-re0 su: regress to root on /dev/ttyp5
ifd ge-0/0/35, stats_req 0xa8a9dd20, sreq_id 4380, new sreq_id 5405
ifd ge-0/0/30, stats_req 0xa8b60de0, sreq_id 54857, new sreq_id 55882
ifd ge-0/0/31, stats_req 0xa89a56c0, sreq_id 36596, new sreq_id 37621
ifd ge-0/0/33, stats_req 0xa8bd3d20, sreq_id 32622, new sreq_id 33647
ifd ge-0/0/31, stats_req 0xa8bd3d20, sreq_id 52160, new sreq_id 53185
[PR/403842]
■ On EX8200 switches, aggregated Ethernet interfaces might go down and come
back up for a few minutes while the switch is updating many routes. [PR/416976]
■ IGMP snooping does not function for IGMPv3 reports with the exclude filter
mode. [PR/286600]


page 217
on page 218
Resolved Issues in JUNOS Release 10.0 for EX Series Switches

The following are the issues that have been resolved since JUNOS Release 10.0R1
for EX Series switches. The identifier following the descriptions is the tracking number
in our bug database.
NOTE: Other software issues that are common to both EX Series switches and M,
MX, and T Series routers are listed in “Issues in JUNOS Release 10.0 for M Series,
MX Series, and T Series Routers” on page 54.
■ When a MAC address is moved dynamically between two interfaces on the same
VLAN, both configured for 802.1X authentication, the MAC address might get
authenticated through both interfaces. [PR/426474: This issue has been resolved.]
■ When extended IGRP (EIGRP) routers are connected to EX Series switches, the
EIGRP routing protocol does not work. [PR/465914: This issue has been resolved.]
■ An interface configured for 802.1X authentication might not get assigned to
server-reject VLANs or server-fail VLANs. [PR/534219:This issue has been
resolved.]
■ At times, the 802.1X client might not be included in the data VLAN though it is
included in the server-reject VLAN. [PR/535264: This issue has been resolved.]
Infrastructure
■ On EX Series switches, when you configure interface ranges under [edit groups
group-name interfaces], the configuration is committed successfully and no error
message is displayed, even though interface ranges are not supported under
configuration groups. [PR/453538: This issue has been resolved.]
■ In the J-Web interface, in the OSPF Configuration page (Configuration > Routing
> OSPF Configuration), the Traceoptions tab in the Edit Global Settings window
does not display the available flags (tracing parameters). As a workaround, use
the CLI to view the available flags. [PR/475313: This issue has been resolved.]
■ If you attempt to set the time zone to Europe/Berlin on a switch with dual Routing
Engines, the commit command might fail. [PR/483273: This issue has been
resolved.]
216 ■ Resolved Issues in JUNOS Release 10.0 for EX Series Switches

Errata in Documentation for JUNOS Release 10.0 for EX Series Switches
■ On EX Series switches, if you perform multiple commit checks and then commit
the configuration, the CLI process might restart. [PR/485106: This issue has been
resolved.]
■ On EX8200 switches, the system log messages from the line cards display the
timestamp in UTC, instead of the time zone specified in the CLI configuration.
■ On EX Series switches, the /var directory appears full after some files in the
/var/log directory are deleted. To avoid this problem, use the clear log filename
command to clear the log files, instead of deleting them manually. [PR/496298:
■ On EX Series switches. when IGMP snooping is enabled, non-IGMP packets with
a destination address in the 224.0.0.x range (link-local range) are not forwarded
to all ports on the VLAN. [PR/502435: This issue has been resolved.]
Interfaces
■ Under certain circumstances, a backup Routing Engine reboot followed by a

Routing Engine failover can cause the LACP to flap, which causes AE bundles to
flap. [PR/502937: This issue has been resolved.]
■ When aggregated Ethernet (ae) interfaces are configured on an EX Series switch
and then the forwarding process (pfem) restarts, the messages received by pfem
can be out of order, causing VLAN membership data to be corrupted. [PR/527117:
Management and RMON
■ Memory leaks might occur on the mib2d. [PR/517565: This issue has been
resolved.]
page 217
on page 218
Errata in Documentation for JUNOS Release 10.0 for EX Series Switches

Errata in Documentation for JUNOS Release 10.0 for EX Series Switches ■ 217
■ The topic Layer 3 Protocols Supported on EX Series Switches incorrectly states

that VRRP for IPv6 is not supported on routed VLAN interfaces (RVIs).
on page 218
Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series Switches
The following pages list the issues in JUNOS Release 10.0R4 for EX Series switches
regarding software upgrade or downgrade:
■ Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series
■ Upgrading from JUNOS Release 9.3R1 to Release 10.0 for EX Series
■ Upgrading from JUNOS Release 9.2 to Release 10.0 for EX Series
■ Downgrading from JUNOS Release 10.0 to Release 9.2 for EX4200
Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series

Switches
The ARP aging time configuration in the system configuration stanza in JUNOS Release
9.4R1 is incompatible with the ARP aging time configuration in JUNOS Release 9.3R1
or earlier and JUNOS Release 9.4R2 or later. If you have configured system arp
aging-timer aging-time on EX Series switches running JUNOS Release 9.4R1 and upgrade
to JUNOS Release 9.4R2 or later or downgrade to JUNOS Release 9.3R1 or earlier,
the switch will display configuration errors on booting up after the upgrade or
downgrade. As a workaround, delete the arp aging-timer aging-time configuration in
the system configuration stanza and reapply the configuration after you complete
the upgrade or downgrade.
The format of the file in which the Virtual Chassis topology information is stored was
changed in JUNOS Release 9.4. When you downgrade JUNOS Release 9.4 or later
running on EX4200 switches in a Virtual Chassis to JUNOS Release 9.3 or earlier,
218 ■ Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series Switches
make topology changes, and then upgrade to JUNOS Release 9.4 or later, the topology
changes you have made using JUNOS Release 9.3 or earlier are not retained. The
switch restores the last topology change you have made using JUNOS Release 9.4.
Upgrading from JUNOS Release 9.3R1 to Release 10.0 for EX Series

Switches
If you are upgrading from JUNOS Release 9.3R1 and have voice over IP (VoIP) enabled
on a private VLAN (PVLAN), you must remove this configuration before upgrading,
to prevent upgrade problems. VoIP on PVLAN interfaces is not supported in releases
later than JUNOS Release 9.3R1.
Upgrading from JUNOS Release 9.2 to Release 10.0 for EX Series Switches
For JUNOS Release 9.3 and later for EX Series switches, during the upgrade process,
the switch performs reference checks on VLANs and interfaces in the 802.1X
configuration stanza. If there are references in the 802.1X stanza to names or tags
of VLANs that are not currently configured on the switch or to interfaces that are not
configured or do not belong to the ethernet-switching family, the upgrade will fail. In
addition, static MAC addresses on single-supplicant mode interfaces are not supported.
CAUTION: If your Release 9.2 configuration includes any of the following conditions,
revise the configuration before upgrading to Release 10.0. If you do not take these
actions, the upgrade will fail:
Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series Switches ■ 219
■ Ensure that all VLAN names and tags in the 802.1X configuration stanza are
configured on the switch and that all interfaces are configured on the switch and
assigned to the ethernet-switching family. If the VLAN or the interface is not
configured and you try to commit the configuration, the commit will fail.
■ Remove static MAC addresses on single-supplicant mode interfaces. If they exist
and you try to commit the configuration, the commit will fail.
■ In an 802.1X configuration stanza, if authentication-profile-name does not exist
and you try to commit the configuration, the commit will fail.
■ In an 802.1X configuration stanza, broadcast and multicast MAC addresses are
not supported in a static MAC configuration. If they exist and you try to commit
the configuration, the commit will fail.
■ Support for static MAC bypass in single or single-secure mode has been removed.
If static MAC bypass exists and you try to commit the configuration, the commit
will fail.
■ In an 802.1X configuration stanza, the switch will not accept the option vrange
as an assigned VLAN name. If it exists and you try to commit the configuration,
the commit will fail.
■ Enabling 802.1X and the port mirroring feature on the same interface is not
supported. If you enable 802.1X and port mirroring on the same interface and
then attempt to commit the configuration, the commit will fail.
■ In an 802.1X configuration stanza, if the VLAN name or tag specified under dot1x
authenticator static does not exist and you try to commit the configuration, the
commit will fail.
■ If the MSTP configuration contains a VLAN (under protocols mstp msti msti-id)
that does not exist on the switch and you try to commit the configuration, the
commit will fail. Remove the VLAN from the MSTP configuration before you
perform an upgrade.
■ In the interfaces configuration stanza, if no-auto-negotiation is configured but
speed and link duplex settings are not configured under ether-options and you
try to commit the configuration, the commit will fail. If no-auto-negotiation is
configured under ether-options, you must configure speed and link duplex settings.
■ In the ethernet-switching-options configuration, if action is not configured for the
number of MAC addresses allowed on the interface (under secure-access-port
interface interface-name mac-limit in the CLI or in the Port Security Configuration
page in the J-Web interface), and you try to commit the configuration, the commit
will fail. You must configure an action for the MAC address limit before upgrading
from Release 9.2 to Release 10.0.
■ If you have configured a tagged interface on logical interface 0 (unit 0), configure
a tagged interface on a logical interface other than unit 0 before upgrading from
Release 9.2 to Release 10.0. If you have not done this and you try to commit
the configuration, the commit will fail. Beginning with JUNOS Release 9.3 for EX
Series switches, untagged packets, BPDUs (such as in LACP and STP), and
priority-tagged packets are processed on logical interface 0 and not on logical
220 ■ Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series Switches
interface 32767. In addition, if you have not configured any untagged interfaces,
the switch creates a default logical interface 0.
■ On EX4200 switches, if you have installed advanced licenses for features such
as BGP, rename the /config/license directory to /config/.license_priv before
upgrading from Release 9.2 to Release 9.3 or later. If the switch does not have
a /config/license directory, create the /config/.license_priv directory manually
before you upgrade. If you do not rename the /config/license directory or create
the /config/.license_priv directory manually, the licenses installed will be deleted
after you upgrade from Release 9.2 to Release 9.3 or later.
Downgrading from JUNOS Release 10.0 to Release 9.2 for EX4200

Switches
When you downgrade a Virtual Chassis configuration from JUNOS Release 10.0 to
Release 9.2 for EX Series switches, member switches might not retain the mastership
priorities that had been configured previously. To restore the previously configured
mastership priorities, commit the configuration by issuing the commit command.
page 217
Upgrade and Downgrade Issues for JUNOS Release 10.0 for EX Series Switches ■ 221
JUNOS Documentation and Release Notes

For a list of related JUNOS documentation, see
http://www.juniper.net/techpubs/software/junos/ .
If the information in the latest release notes differs from the information in the
documentation, follow the JUNOS Release Notes.
To obtain the most current version of all Juniper Networks® technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/ .
Juniper Networks supports a technical book program to publish books by Juniper

Networks engineers and subject matter experts with book publishers around the
world. These books go beyond the technical documentation to explore the nuances
of network architecture, deployment, and administration using the Junos operating
system (Junos OS) and Juniper Networks devices. In addition, the Juniper Networks
Technical Library, published in conjunction with O'Reilly Media, explores improving
network security, reliability, and availability using Junos OS configuration techniques.
All the books are for sale at technical bookstores and book outlets around the world.
The current list can be viewed at http://www.juniper.net/books .
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
techpubs-comments@juniper.net, or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include
the following information with your comments:
■ Document name
■ Document part number
■ Page number
■ Software release version
Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support
contract, or are covered under warranty, and need postsales technical support, you
can access our tools and resources online or open a case with JTAC.
■ JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.
■ Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.
222 ■ JUNOS Documentation and Release Notes

Requesting Technical Support
■ JTAC Hours of Operation —The JTAC centers have resources available 24 hours
a day, 7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:
■ Find CSC offerings: http://www.juniper.net/customers/support/
■ Search for known bugs: http://www2.juniper.net/kb/
■ Find product documentation: http://www.juniper.net/techpubs/
■ Find solutions and answer questions using our Knowledge Base:
http://kb.juniper.net/
■ Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/
■ Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/
■ Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/
■ Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool located at https://tools.juniper.net/SerialNumberEntitlementSearch/.
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.

■ Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
■ Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/support/requesting-support.html.
If you are reporting a hardware or software problem, issue the following command
from the CLI before contacting support:
user@host> request support information | save filename
To provide a core file to Juniper Networks for analysis, compress the file with the
gzip utility, rename the file to include your company name, and copy it to
ftp.juniper.net:pub/incoming. Then send the filename, along with software version
information (the output of the show version command) and the configuration, to
support@juniper.net. For documentation issues, fill out the bug report form located at
https://www.juniper.net/cgi-bin/docbugreport/.
Requesting Technical Support ■ 223

Revision History
04 February 2011—Revision 9, JUNOS Release 10.0R4
03 December 2010—Revision 8, JUNOS Release 10.0R4
13 September 2010—Revision 7, JUNOS Release 10.0R4
30 August 2010—Revision 6, JUNOS Release 10.0R4
25 August 2010—Revision 5, JUNOS Release 10.0R4
28 May 2010—Revision 4, JUNOS Release 10.0R3
19 April 2010—Revision 3, JUNOS Release 10.0R3
15 December 2009—Revision 2, JUNOS Release 10.0R2
4 November 2009—Revision 1, JUNOS Release 10.0R1
Copyright © 2011, Juniper Networks, Inc. All rights reserved.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or
otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed
to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347,
6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
224 ■ Requesting Technical Support

Junos Release Notes 10.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Junos Release Notes 10.0

Uploaded by

Copyright:

Available Formats

® ®

Juniper Networks JUNOS 10.0 Software

User Interface and Configuration ......................................................38

■ Class-of-service support for PBB (MX Series routers)—Enables quality-of-service

class-of-service interfaces unit unit-number rewrite-rules] hierarchy level. To classify

■ Integrated Multi-Service Gateway (IMSG) high availability call continuity (MX

major versions. However, in JUNOS Release 10.0, only a temporary disruption

■ PB-4CHDS3-E3-IQE-BNC, 4-port channelized DS3/E3 enhanced IQ PIC

■ PB-4DS3-E3-IQE-BNC, 4-port non-channelized DS3/E3 enhanced IQ PIC

■ Enhances the unified ISSU support on 1-port channelized OC48/STM16

Interfaces and Chassis

The following protocols are supported:

■ ATM over PWE3 (RFC 4717)

For information on configuration, see the Network Interfaces Configuration Guide.

This MC-AE implementation supports the following:

■ L2CKT functions with ether-ccc encapsulation.

■ VPLS functions with ether-vpls and vlan-vpls.

■ PW status-tlv with independent mode.

■ LACP (limitations apply, see the Network Interfaces Configuration Guide).

■ Inter-chassis control protocol.

This MC-AE implementation does not support the following:

To configure MC-AE, use the aggregated-ether-options mc-ae statement and its

statement at the [edit class-of-service interface interface-name unit

level. To enable the ATM-to-Ethernet interworking cross-connect function, include

In addition, the following related CLI statements are now supported:

■ Include the no-ipsec-tunnel-in-traceroute statement at the [edit services

■ Include the level statement at the [edit services ipsec-vpn traceoptions]

■ Include the anti-replay-window-size statement at the [edit services service-set

■ Include the no-anti-replay statement at the [edit services service-set

■ Include the clear-dont-fragment-bit statement at the [edit services service-set

■ Include the tunnel-mtu statement at the [edit services service-set

[Protected System Domain]

■ Supports LAN-PHY mode at 10.3125 Gbps.

■ Supports small form-factor pluggable transceivers of the SFP+ standard:

■ 10-GBase-LRM (model number: SFPP-10GE-LRM)

■ 10-GBase-SR (model number: SFPP-10GE-SR)

■ Supports an effective line rate of twelve 10-Gigabit Ethernet ports.

■ Supports one full-duplex 10-Gigabit tunnel interface for each Packet

■ Supports intelligent oversubscription services.

■ Firewall filters and policers (excluding TCAM)

■ Class-of-service (CoS) features (excluding per-unit scheduler, hierarchical

[edit chassis fpc 4]

[MX Series Line Card Guide, System Basics, Class of Service]

■ Monitoring pseudowires—Starting with JUNOS Release 10.0, JUNOScope enables

JUNOScope supports the following diagnostic commands:

■ Traceroute—Displays a list of routers that exist between the device and a

■ BERT Test—Tests the quality of links.

JUNOScope also enables you to generate a stitching configuration that connects

JUNOS XML API and Scripting

Request Tag Element CLI Command Response Tag Element

<clear-aaa-statistics-table> clear network-access aaa statistics <clear-aaa-module-statistics>

<clear-idp-application-system-cache> clear security idp application-identification <clear-idp-

<clear-service- clear services border-signaling-gateway <bsg-drain-nr-details>

<clear-service- clear services border-signaling-gateway <bsg-drain-nr-details>

<clear-service- clear services border-signaling-gateway <bsg-statistics-clear-denied-messages>

<get-fm-fpc-errors> show chassis fabric errors fpc <fm-fru-errors>

Request Tag Element CLI Command Response Tag Element

<get-fm-sib-errors> show chassis fabric errors sib <fm-fru-errors>

<get-idp-addos-application-information> show security idp application- identification <get-idp-

<get-idp-application-system-cache> show security idp application-ddos application <idp-application-system-cache-information>

<get-ospf3-backup-coverage-information> show ospf3 backup coverage <ospf3-backup-coverage-information>

<get-ospf3-backup-lsp-information> show ospf3 backup lsp <ospf3-backup-lsp-information>

<get-ospf3-backup-neighbor-information> show ospf3 backup neighbor <ospf3-backup-neighbor-information>