Junos Release Notes 10

Juniper Networks JUNOS 10.
1 Software Release Notes

Release 10.1R1 17 February 2010 Revision 2
These release notes accompany Release 10.1R1 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.1 for M Series, MX Series, and T Series Routers ....................................................................................6 Class of Service ..................................................................................6 High Availability ...............................................................................12 Interfaces and Chassis ......................................................................12 JUNOS XML API and Scripting ..........................................................18 MPLS Applications ............................................................................21 Multiplay ..........................................................................................22 Routing Policy and Firewall Filters ....................................................23 Routing Protocols .............................................................................24 Services Applications ........................................................................27 Subscriber Access Management .......................................................27 System Logging ................................................................................36
JUNOS 10.1 Software Release Notes
User Interface and Configuration ......................................................38 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers ............................................42 Class of Service ................................................................................42 Forwarding and Sampling ................................................................42 Interfaces and Chassis ......................................................................42 MPLS Applications ............................................................................46 Multiplay ..........................................................................................46 Routing Policy and Firewall Filters ....................................................46 Routing Protocols .............................................................................47 Services Applications ........................................................................48 Subscriber Access Management .......................................................50 User Interface and Configuration ......................................................50 VPNs ................................................................................................51 Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers .............................................................................................52 Current Software Release .................................................................53 Previous Releases .............................................................................64 Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers ..................................69 Changes to the JUNOS Documentation Set .......................................69 Errata ...............................................................................................69 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers ............................................71 Basic Procedure for Upgrading to Release 10.1 ................................72 Upgrading a Router with Redundant Routing Engines ......................74 Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS Release 10.1 ...................................................................74 Upgrading the Software for a Routing Matrix ...................................76 Upgrading Using ISSU .......................................................................77 Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both PIM and NSR ................................................................77 Downgrade from Release 10.1 .........................................................78 JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways and J Series Services Routers ..................................................80 New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ............................................................80 Software Features .............................................................................81 Hardware Features ...........................................................................92 Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ....................93 Application Layer Gateways (ALGs) ..................................................93 Chassis Cluster .................................................................................94 Command-Line Interface (CLI) ..........................................................95 Configuration ...................................................................................98 Flow and Processing .........................................................................99 Interfaces and Routing ...................................................................100 Intrusion Detection and Prevention (IDP) .......................................100 J-Web .............................................................................................101 Management and Administration ...................................................101 Security ..........................................................................................102
Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ..........................................102 [accounting-options] Hierarchy ......................................................102 AX411 Access Point .......................................................................102 Chassis Cluster ...............................................................................102 Command-Line Interface (CLI) ........................................................104 Dynamic VPN .................................................................................104 Flow and Processing .......................................................................104 Hardware .......................................................................................105 Interfaces and Routing ...................................................................106 Intrusion Detection and Prevention (IDP) .......................................108 J-Web .............................................................................................109 NetScreen-Remote ..........................................................................110 Network Address Translation (NAT) ................................................110 Performance ..................................................................................111 SNMP .............................................................................................111 System ...........................................................................................111 Unified Threat Management (UTM) ................................................111 WLAN .............................................................................................111 VPNs ..............................................................................................111 Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ...................................................................112 Outstanding Issues In JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ...................................112 Resolved Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ...................................136 Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ..................140 Application Layer Gateways (ALGs) ................................................140 Attack Detection and Prevention ....................................................141 CLI ..................................................................................................141 Flow ...............................................................................................141 Hardware Documentation ..............................................................142 Installing Software Packages ..........................................................143 Integrated Convergence Services ....................................................144 Interfaces and Routing ...................................................................144 Intrusion Detection and Prevention (IDP) .......................................145 J-Web .............................................................................................146 Screens ...........................................................................................147 Hardware Requirements for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ..........................................147 Transceiver Compatibility for SRX Series and J Series Devices .......147 Power and Heat Dissipation Requirements for J Series PIMs ..........148 Supported Third-Party Hardware for J Series Services Routers .......148 J Series CompactFlash and Memory Requirements ........................149 Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways ........................................................................................149 Dual-Root Partitioning Scheme .......................................................149 Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing Engine ..................................................................158
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers ..................160 JUNOS Software Release Notes for EX Series Switches ................................160 New Features in JUNOS Release 10.1 for EX Series Switches ................160 Hardware .......................................................................................161 Access Control and Port Security ....................................................162 Bridging, VLANs, and Spanning Trees ............................................162 Class of Service (CoS) .....................................................................162 Infrastructure .................................................................................162 Interfaces .......................................................................................163 Layer 2 and Layer 3 Protocols ........................................................163 Management and RMON ................................................................163 MPLS ..............................................................................................163 Packet Filters ..................................................................................163 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches ...............................................................................164 Layer 2 and Layer 3 Protocols ........................................................164 Infrastructure .................................................................................164 User Interface and Configuration ....................................................164 Limitations in JUNOS Release 10.1 for EX Series Switches ....................165 Access Control and Security ...........................................................165 Class of Service ..............................................................................165 Firewall Filters ................................................................................165 Infrastructure .................................................................................166 Interfaces .......................................................................................167 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches ........168 Access Control and Port Security ....................................................168 Bridging, VLANs, and Spanning Trees ............................................168 Class of Service ..............................................................................168 Firewall Filters ................................................................................168 Infrastructure .................................................................................169 Interfaces .......................................................................................169 J-Web Interface ...............................................................................169 Resolved Issues in JUNOS Release 10.1 for EX Series Switches .............171 Access Control and Port Security ....................................................171 Bridging, VLANs, and Spanning Trees ............................................171 Class of Service ..............................................................................172 Firewall Filters ................................................................................172 Hardware .......................................................................................172 Infrastructure .................................................................................172 J-Web Interface ...............................................................................173 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches .........................................................................................174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches .........................................................................................174 Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series Switches ..................................................................................174 Upgrading from JUNOS Release 9.3R1 to Release 10.1 for EX Series Switches ..................................................................................175 Upgrading from JUNOS Release 9.2 to Release 10.1 for EX Series Switches ..................................................................................175
Downgrading from JUNOS Release 10.1 to Release 9.2 for EX4200 Switches ..................................................................................177 JUNOS Documentation and Release Notes ..................................................178 Documentation Feedback ............................................................................178 Requesting Technical Support .....................................................................178 Revision History ..........................................................................................180
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.1 for M Series, MX Series, and T Series Routers on page 6 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 42 Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 52 Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers on page 69 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 71
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
The following features have been added to JUNOS Release 10.1. Following the description is the title of the manual or manuals to consult for further information.
Class of Service
Intelligent oversubscription service support (MX Series routers with Trio MPC/MIC interfaces)Arriving packets are assigned to one of two traffic classes (control and best-effort) based on their header types and destination MAC address. This allows for lower priority packets to be dropped more intelligently when oversubscription occurs. Only packets mapped to queue 3 are marked as control packets. Protocols such as telnet, FTP, and SSH that are mapped to queue 0 are classified as best-effort. No configuration is necessary, but the queue assignments can be altered with a multifield classifier. [Class of Service]
CoS aspects of the MPC/MIC (MX Series routers with Trio MPC/MIC interfaces)Cover all aspects of CoS configuration for this hardware combination. Support includes shaping rates at the queue level, configurable bandwidth profiles with percentages, dynamic bandwidth allocation among different services, scheduler node scaling, and delay buffer allocation. To configure, include the relevant statements at the [edit class-of-service] hierarchy level and apply them if necessary at other hierarchy levels such as the [edit interfaces] hierarchy level. [Class of Service, Network Interfaces]
Per-priority shaping (MX Series platforms with Trio MPC/MIC interfaces)Enables you to configure a separate shaping rate for each of the five priority levels so that higher priority services such as voice and video do not starve lower priority services such as data. To configure, include the shaping-rate-(excess | priority)-level rate [ burst-size burst ] statement at the [edit class-of-service traffic-control-profiles tcp-name] hierarchy level and apply the traffic control profile at the [edit interfaces] hierarchy level. [Class of Service]
JUNOS Software Release Notes for Juniper Networks M Series Multiservice Edge Routers, MX Series Ethernet Service Routers, and T Series Core Routers
Distribute excess bandwidth among different services for a subscriber (MX Series routers with Trio MPC/MIC interfaces)Service providers often use tiered services that must carry excess bandwidth as traffic patterns vary. By default, excess bandwidth between a configured guaranteed rate and shaping rate is shared equally among all queues, which might not be optimal for all subscribers to a service. You can control the distribution of this excess bandwidth with the excess-rate statement. To configure the excess rate for a traffic control profile, include the excess-rate statement at the [edit class-of-service traffic-control-profiles tcp-name] hierarchy level and apply the traffic control profile at the [edit interfaces] hierarchy level. To configure the excess rate for a queue, include the excess-rate and excess-priority statements at the [edit class-of-service scheduler scheduler-name] hierarchy level. [Class of Service]
Scheduler node scaling (MX Series routers with Trio MPC/MIC interfaces)The hardware supports multiple levels of scheduler nodes. In per-unit-scheduling mode, each logical interface (unit) can have four or eight queues and has a dedicated level 3 scheduler node. The logical interfaces share a common level 2 node (one per port). In hierarchical-scheduling mode, a set of logical interfaces, each with four or eight queues, has a level 2 CoS profile and one of its logical interface children has a level 3 CoS profile. To better control system resources in hierarchical-scheduling mode, you can limit the number of hierarchical levels in the scheduling hierarchy to two. In this case, all logical interfaces and interface sets with CoS profiles share a single (dummy) level 2 node, thereby increasing the maximum number of logical interfaces with CoS profiles (the interface sets must be at level 3). To configure scheduler node scaling, include the maximum-hierarchy-levels statement at the [edit interfaces xe-fpc/pic/port hierarchical-scheduler] hierarchy level. The only supported value is 2. [Class of Service, Network Interfaces]
Forwarding-class aliases (M320 and T Series routers)Enable you to configure up to 16 forwarding classes and 8 queues, with multiple forwarding classes assigned to single queues. To configure, include the class and queue-num statements at the [edit class-of-service forwarding-classes] hierarchy level. [Class of Service]
VLAN shaping on aggregate devices (MX Series routers with Trio MPC/MIC interfaces)VLAN shaping (per-unit scheduling) is supported on aggregated Ethernet interfaces when link protection is enabled on the aggregated Ethernet interface. When VLAN shaping is configured on aggregate Ethernet interfaces with link protection enabled, the shaping is applied to the active child link. To configure link protection on aggregated Ethernet interfaces, include the link-protection statement at the [edit interfaces aex aggregated-ether-options] hierarchy level. Traffic passes only through the designated primary link. This includes transit traffic and locally generated traffic on the router. When the primary link fails, traffic is routed through the backup link. You also can reverse traffic, from the designated backup link to the designated primary link. To revert back to sending traffic to the primary designated link when traffic is passing through the designated backup link, use the revert command; for example, request interfaces revert ae0. To configure a primary and a backup link, include the primary and backup statements at the [edit interfaces ge-fpc/pic/port gigether-options 802.3ad aex] hierarchy level or the [edit interfaces xe-fpc/pic/port fastether-options 802.3ad aex] hierarchy level. To disable link protection, delete
the link-protection statement at the [edit interfaces aex aggregated-ether-options link-protection] hierarchy level. To display the active, primary, and backup link for an aggregated Ethernet interface, use the operational mode command show interfaces redundancy aex. [Class of Service, Network Interfaces]
Re-marking of MVPN GRE encapsulation DCSP at ASBR (MX Series routers with Trio MPC/MIC interfaces)Enables you to configure DSCP marking for GRE encapsulated packets that aligns with the service provider core CoS policy for an MVPN. To configure, include the DSCP rewrite-rule dscp dscp-rule-name with the values at the [edit class-of-service] hierarchy level and then apply the rewrite rule to the core-facing multicast interface at the [edit class-of-service interfaces] hierarchy level. [Class of Service]
PD-5-10XGE-SFPP, 10-port 10-Gigabit Ethernet (Type 4) PIC (T640, T1600, and TX Matrix routers with G-FPC4, ST-FPC4, and ST-FPC4.1)Supports a WAN bandwidth of 100 Gbps in addition to the following features:

Intelligent handling of oversubscribed traffic Line rate operation on up to five 10-Gigabit Ethernet ports Tap features, such as flexible encapsulation, source address (SA) MAC learning, MAC accounting, and MAC policing Stacked virtual LAN (VLAN) tag and VLAN rewrite functionalities
[Network Interfaces, Class of Service, PIC Guide]
Intelligent oversubscription services (MX Series with 16-port 10-Gigabit Ethernet MPC with SFP+)The 16-port 10Gigabit Ethernet Modular Port Concentrator (MPC) is an oversubscribed configuration. Consequently, it is necessary to protect control traffic over best-effort traffic as soon as packets enter the line card. To do this, packets entering the line card are assigned a preclassifier control traffic class according to the header types (such as destination MAC addresses, and Layer 4 ports) in the packet. The preclassifier provides a good way to classify and queue important control traffic in a different high-priority queue from that used for best-effort traffic. The preclassifier (control or best effort) is assigned prior to packets being accepted into the initial stream and is used by the line card as an early designation (before any class-of-service configuration is applied). When oversubscription occurs, control traffic will be queued separately and should not be subject to any dropped packets. The Layer 2 protocols supporting the preclassifier are:

802.1ah 802.1g 802.1x 802.3ad ARP
GMRP GVRP LACP PVST xSTP
The Layer 3 protocols supporting the preclassifier are:

IGMP IPv4/IPv6 ICMP IPv4/IPv6 ISIS IPv4/IPv6 OSPF IPv4/IPv6 PIM IPv4 Router Alert IPv4/IPv6 RSVP IPv4/IPv6 VRRP
The Layer 4 protocols supporting the preclassifier are:

IIPv4/ IPv6 BGP IPv4/ IPv6 LDP IPv4 UDP/L2TP RIP (UDP port checks)
The preclassifier is also supported on label-switching encapsulation PPP. [Class of Service]
Feature support on 16-port 10-Gigabit Ethernet MPC with SFP+ (MX Series routers)The following features are supported on the 16-port 10-Gigabit Ethernet MPC with SFP+:
Accepts traffic destined for GRE tunnels or DVMRP (IP-in-IP) tunnels (JUNOS Release 10.0R2) Bidirectional Forwarding Detection (BFD) protocol (JUNOS Release 10.0R2) Border Gateway Protocol (BGP) (JUNOS Release 10.0R2) BGP/Multiprotocol Label Switching (MPLS) virtual private networks (VPNs) (JUNOS Release 10.0R2) Distance Vector Multicast Routing Protocol (DVMRP) and generic routing encapsulation (GRE) support, access side and server side (JUNOS Release 10.0R2) Firewall filters (JUNOS Release 10.0R2)
Flexible Ethernet encapsulation (JUNOS Release 10.0R2) Graceful Routing Engine switchover (GRES) (JUNOS Release 10.0R2) Ingress differentiated (JUNOS Release 10.0R2) Differentiated Services code point rewrite (DSCP) (JUNOS Release 10.0R2) Intelligent oversubscription (JUNOS Release 10.0R2) Integrated routing and bridging (IRB) (JUNOS Release 10.1R1) Intermediate System-to-Intermediate System (IS-IS) (JUNOS Release 10.0R2) Internet Group Management Protocol (IGMP) (excludes snooping) (JUNOS Release 10.0R2) IPv4 (JUNOS Release 10.0R2) IP multicast (JUNOS Release 10.0R2) Label Distribution Protocol (LDP) (JUNOS Release 10.0R2) Labeled-switched path (LSP) accounting, policers, and filtering (JUNOS Release 10.0R2) LAN-PHY mode (JUNOS Release 10.0R2) Layer 2 frame filtering (JUNOS Release 10.0R2) IEEE 802.3ad link aggregation (JUNOS Release 10.0R2) Link Aggregation Control Protocol (LACP) (JUNOS Release 10.0R2) Local loopback (JUNOS Release 10.0R2) MAC learning, policing (JUNOS Release 10.0R2) Multiple tag protocol identifiers (TPIDs), accounting, and filtering (JUNOS Release 10.0R2) Multiprotocol Label Switching (MPLS) (JUNOS Release 10.0R2) Nonstop active routing (NSR) (JUNOS Release 10.0R2) Multitopology routing (MTR) (JUNOS Release 10.0R2) Open Shortest Path First (OSPF) (JUNOS Release 10.0R2) Packet mirroring (JUNOS Release 10.0R2) Quality of service (QoS) per port: (JUNOS Release 10.0R2)

Eight queues per port Excess-rate configuration at the traffic-control-profile level Excess-rate and excess-priority configuration at the queue level Shaping at the port level
10
Shaping at the queue level Scheduling of queues based on weighted round-robin (WRR) per priority class Tricolor marking Weighted random early detection (WRED)
QoS per virtual LAN (VLAN): (JUNOS Release 10.0R2)

Accounting, filtering, and policing IEEE 802.1p rewrite Classification Excess-rate configuration at the traffic-control-profile level Tricolor marking
Resource Reservation Protocol (RSVP) (JUNOS Release 10.0R2) Routing Information Protocol (RIP) (JUNOS Release 10.0R2) Simple Network Management Protocol (SNMP) (JUNOS Release 10.0R2) IEEE 802.1Q VLANs: (JUNOS Release 10.0R2)

VLAN stacking and rewriting Channels defined by two stacked VLAN tags Flexible VLAN tagging IP service for nonstandard TPID and stacked VLAN tags
Virtual private LAN service (VPLS) (JUNOS Release 10.0R2) Virtual private network (VPN) (JUNOS Release 10.0R2) Virtual Router Redundancy Protocol (VRRP) for IPv4 (JUNOS Release 10.0R2)
To support these features, some modifications have been made to the following configuration statements:
The ability to configure the DSCP as the action of a filter rule is already present in the JUNOS Software. However, with this line card, the value range permitted is modified from 0, to 0 through 63. To include DSCP as the action of a filter rule, include the dscp value parameter at the [edit firewall filter filter-name] hierarchy level. To fully leverage the features offered through the new chipset on the line card, include the enhanced-hash-key option at the [edit forwarding-options] hierarchy level.
[Class of Service]
11
IEEE 802.1ak-2007 MVRP (MX Series routers)The Multiple VLAN Registration Protocol (MVRP) is a standards-based Layer 2 network protocol used among switches to dynamically share and update VLAN information with other bridges. VLAN information exchanged includes:

The set of VLANs that currently have active members The ports through which the active members can be reached
To operate MVRP, edge ports should have the static VLAN configuration. The edge ports will not be configured for MVRP. MVRP is only enabled on the core-facing trunk ports where no static VLANs are configured. To configure MVRP, include the mvrp statement and desired options at the [edit protocols] hierarchy level. [Class of Service]
Elevated packet drops during oversubscription (MX Series routers with Trio MPC/MIC interfaces)During periods of oversubscription, the WRED process drops more packets than expected from relatively full queues. There is no configuration for this feature, which transparently applies scaling to oversubscribed queues. [Class of Service]
High Availability
Enhancements to unified ISSU support on PICs (T Series)JUNOS Release 10.1 extends unified ISSU support for the following PICs to T Series routers:
PB-1CHOC12-STM4-IQE-SFP, 1-port channelized OC12/STM4 enhanced IQ PIC PB-1OC12-STM4-IQE-SFP, 1-port nonchannelized 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
[High Availability]
Interfaces and Chassis
New 60-Gigabit Ethernet Queuing MPC (model number MX-MPC2-3D-Q)Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide. New 60-Gigabit Ethernet MPC (model number MX-MPC2-3D)Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide. New 60-Gigabit Ethernet Enhanced Queuing MPC (model number MX-MPC2-3D-EQ)Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide.
12
New 20-port Gigabit Ethernet MIC with SFP (model number MIC-3D-20GE-SFP)Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide. New Modular Port Concentrators (MPCs) and Modular Interface Cards (MICs)Supported on MX Series platforms. Up to two MICs plug into the MPC to provide the physical interface for the MPC line card. The MPCs provide increased capacity on Gigabit Ethernet and 10-Gigabit Ethernet hardware. For a list of supported MPCs and MICs, see the MX Series Line Card Guide. [Network Interfaces]
New 4-port 10-Gigabit Ethernet MIC with XFP (model number MIC-3D-4XGE-XFP)Supported on MX Series routers. For a list of supported MPCs, see the MX Series Line Card Guide. Layer 2 VPLS, IRB, and mesh group feature parity (MX Series routers with Trio MPC/MIC interfaces)Support for Layer 2 feature parity with JUNOS Release 9.1 on MX Series routers that include Trio Modular Port Concentrators (MPCs) and Modular Interface Cards (MICs). Layer 2 feature parity includes:

Layer 2 bridging VPLS forwarding MAC address learning, aging, and MAC address limit Mesh group support Implicit VLAN mapping Integrated routing and bridging (IRB) Multicast over IRB MAC statistics
Layer 2 features that are not supported in this release include:
Spanning Tree Protocols (xSTP)

VLAN Spanning Tree Protocol (VSTP) Multiple Spanning Tree Protocol (MSTP) Rapid Spanning Tree Protocol (RSTP) Layer 2 Tunneling Protocol (L2TP)
Upgrading a T1600 router to be the LCC0 of the TX Matrix Plus platformYou can now upgrade an operational T1600 router to be the lcc0 in a newly configured TX Matrix Plus platform. The procedures require JUNOS Release 10.1 on the TX Matrix Plus router and the T1600 router. Reboot is required to transfer control of the T1600 router to the routing matrix. You can also downgrade the lcc0 to a standalone T1600 router by rolling back to the former configuration. Upgrade and integration of subsequent operational T1600 routers to form lcc1 and lcc2
13
(and so on) is not supported. Use the offline procedures to upgrade and integrate the remaining T1600 routers into the routing matrix. [TX Matrix Plus Hardware, System Basics and Services Command Reference]
Per-unit scheduling for GRE tunnels using IQ2 PICs (M7i, M10i, M120, M320, T Series, and TX Matrix routers)Supports enhanced IQ2 PIC and IQ2E PIC performance, adding all functionality of tunnel PICs. The QoS for the GRE tunnel traffic will be applied as the traffic is looped through the IQ2/IQ2E PIC. Shaping is performed on full packets that pass through the GRE tunnel. IQ2 and IQ2E PICs support all interfaces that are supported on tunnel PICs, as follows:

gr-fpc/pic/port vt-fpc/pic/port lt-fpc/pic/port ip-fpc/pic/port pe-fpc/pic/port pd-fpc/pic/port mt-fpc/pic/port
The port variable is always zero. The provided tunnel functionality is the same as that of regular tunnel PICs. You can specify that IQ2 and IQ2E PICs work exclusively in tunnel mode or work as both a regular and a tunnel PIC. The default setting uses IQ2 and IQ2E PICs as both a regular and a tunnel PIC. To configure exclusive tunnel mode, use the tunnel-only statement at the [chassis fpc number pic number tunnel-services] hierarchy level. You can use the show interfaces queue gr-fpc/pic/port command to display statistics for the specified tunnel. [Network Interfaces, Class of Service, PIC Guide]
RSD configuration of logical interface filters on shared interfaces (JCS1200 platform)Enables RSD configuration support for logical interface filters on shared interfaces. In previous releases, logical interface filters were configured on each PSD. This release supports configuration on the RSD. To configure a logical interface filter on the RSD, apply the firewall filter to the logical interface on the shared interface by including the filter output filter-name statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level on the RSD. Filtering is performed on the PSD, but logical interface filters configured on the RSD are applied automatically by the PSD. Filters configured on the RSD can co-exist with filters configured on the PSD. Counter statistics related to PSD filtering are available on the RSD. [Protected System Domain]
14
Two new AC power supply modules in chassisThe JUNOS Software now supports two new AC power supply modules on T640 and T1600 routers: AC Power Entry Module 10kW US and AC Power Entry Module 10kW EMEA (for U.S. and EMEA markets, respectively). The two Power Entry Modules (PEMs) cannot interoperate and the JUNOS Software reports an alarm when they do. The show chassis environment pem command output will show AC Input: status instead of DC Input: status and the Temperature will show the actual temperature reading. Two new power supply descriptions, US and EMEA, are added to distinguish the new modules from existing ones in the output of the show chassis hardware command output. [System Basics and Service Command Reference]
Next-hop cloning and permutations disabled in T Series enhanced scaling FPCs (FPC Type 1-ES, FPC Type 2-ES, FPC Type 3-ES, and FPC Type 4-ES)The next-hop cloning and permutations are now disabled in these FPCs with enhanced load-balancing capability. As a result, the memory utilization is reduced for a highly scaled system with a high number of next hops on ECMP or aggregated interfaces. [System Basics]
Fragmentation support for GRE-encapsulated packets (Multiservices DPC) (M120, M7i/M10i with enhanced CFEB, M320 with E3 FPC, and MX Series routers only)Enables the Packet Forwarding Engine to update the IP identification field in the outer IP header of packets encapsulated with generic routing encapsulation (GRE), so that reassembly of the packets is possible after fragmentation. The previous CLI constraint check that requires you to configure either the clear-dont-fragment-bit statement or a tunnel key with the allow-fragmentation statement is no longer enforced. There are no associated changes to the CLI statements or operational mode commands.
NOTE: For other routers, the earlier configuration constraint check still holds. [Services Interfaces, MPLS Applications, MX Series Layer 2 Configuration Guide]
NAT compliance enhancementsAdd modifications to the existing NAT functionality on the services PICs to achieve compliance with RFCs UDP 4787, TCP 5382, and ICMP 5508. These enhancements apply to IPv4IPv4, IPv6IPv6, and IPv4IPv6 source NAT and are not supported with destination NAT. New CLI configuration settings associated with RFC 4787 include the mapping-timeout statement at the [edit services nat pool pool-name] hierarchy level and the address-pooling, filtering-type, and mapping-type statements at the [edit services nat rule rule-name term term-name then translated] hierarchy level. There are no associated changes to the operational mode commands. [Services Interfaces]
Support for VRF in Routing Engine-based sampling on M Series, M320, MX Series, M120, and T Series routersFor VRF Routing Engine-based sampling, the kernel queries the correct VRF route table based on the ingress interface index for the received packet. For interfaces configured in VRF, the sampled packets contain the correct input and output interface SNMP index, the source and destination AS numbers, and the source and destination mask.
15
There are two ways to verify the sampled packets. The first is to include the file sampled statement at the [edit forwarding-options sampling traceoptions] hierarchy level and the local dump statement at the [edit forwarding-options family inet output flow-server server] hierarchy level, and check the sampled file using the tail f /var/tmp/sampled command from the router shell. The second is to export and verify the sampled packets to the flow-server. [Services Interfaces, Feature Guide]
New 4-port Channelized OC12 Enhanced Intelligent Queuing (IQE) type 3 PIC (M Series and T Series routers)Provides increased channelization and an improved QoS model; with channelization capabilities and scaling that make it ideal for edge aggregation. Improved QoS functionality supports policing based on DSCP/IPPREC/EXP, five priority levels, two shaping rates (CIR and PIR), option to use shared scheduling on set of logical interfaces, DSCP rewrite on ingress, and configurable delay buffers for queueing. The QoS capabilities provide service differentiation for service providers. The interface configuration syntax of existing IQ PICs is retained, but configuration limits are changed to match the augmented capabilities of IQE PICs. All functionality available on the 4-port Channelized OC12 IQ Type 2 PIC is supported by this PIC. [Network Interfaces]
Enhanced Intelligent Queuing (IQE) PICs add support for T3 and T1 channelization under SDH framing (M40e, M120, and M320 with Sahara-FPC, and T Series routers)The following IQE PICs are supported:

1-port COC48 IQE 4-port COC12 IQE 1-port COC12 IQE 2-port COC3 IQE
The JUNOS Software supports T1 and CT1 interface types under CAU4. To configure T1 and CT1 interfaces under CAU4, use the t1 and ct1 statements at the [edit interfaces cau4-fpc/pic/port:unit partition number interface-type] hierarchy level. With T1 and CT1 interface configurations under CAU4 interfaces, you can configure a maximum of 84 T1 or CT1 inerfaces. However, the partition range under CAU4 interfaces was previously restricted to from 1 to 63. This range has increased to from 1 to 84 for T1 and CT1 interfaces. The JUNOS Software supports T1, CT1, T3, and CT3 interfaces under Channelized AU4 partitions. To configure T1, CT1, T3, and CT3 interfaces under Channelized AU4, use the ct1 and t1 statements at the [edit interfaces cau4-fpc/pic/port:unit partition partition-number] hierarchy level or the ct3 and t3 statements at the [edit interfaces cau4-fpc/pic/port:unit partition number interface-type] hierarchy level. The JUNOS Software also supports M13 mapped T1 interfaces under CAU4. To configure a T1 interface under CAU4, use the t1 statement at the [edit interfaces
16
cau4-fpc/pic/port:unit partition partition-number interface-type t1] or [edit interfaces cau4-fpc/pic/port:unit partition partition-number interface-type ct1] hierarchy level.
The JUNOS Software does not allow combined configurations of E1 and E3 interfaces together under a CAU4 interface. Similarly, you cannot mix T1, E1, T3, and E3 interfaces directly under CAU4.
NOTE: The TUG-3 partition is not supported. ITU-T VT-mapping in combination with TUG3 partition is not supported.
[Network Interfaces, PIC Guide]
Stateful firewall chaining for FTP, TFTP, and RTSP data sessions (MX Series routers with Multiservices DPCs, and M120 or M320 routers with Multiservices 400 PICs)Adds support for stateful firewall rule sets in Dynamic Application Awareness for JUNOS Software service chains. New application-level gateways (ALGs) are available for FTP (junos-ftp), TFTP (junos-tftp), and RTSP (junos-rtsp); you can include them as values for the applications statement at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level. In addition, you can include new statement options at the [edit interfaces ms-fpc/pic/port services-options ignore-errors] hierarchy level to enable stateful firewall sessions to operate in a no-drop mode and ignore various traffic errors that would normally result in dropped packets. There are no CLI changes in the APPID, IDP, AACL, or L-PDF configurations. The associated operational mode commands should report the new applications when identified. [Services Interfaces]
17
JUNOS XML API and Scripting
18
New JUNOS XML API operational request tag elementsTable 1 on page 19 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 10.1, along with the corresponding CLI command and response tag element for each one.
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.1
Request Tag Element
<clear-dhcpv6-server-binding-information> clear_dhcpv6_server_binding_information <clear-dhcpv6-server-statistics-information> clear_dhcpv6_server_statistics_information <clear-mpls-static-lsp-information> clear_mpls_static_lsp_information <clear-mvrp-interface-statistics> clear_mvrp_interface_statistics <clear-idp-appddos-cache> clear_idp_appddos_cache <clear-idp-status-information> clear_idp_status_information <clear-vrrp-information> clear_vrrp_information <clear-vrrp-interface-statistics> clear_vrrp_interface_statistics <request-script-refresh-from> request_script_refresh_from <get-dhcpv6-server-binding-information> get_dhcpv6_server_binding_information <get-dhcpv6-server-statistics-information> get_dhcpv6_server_statistics_information <get-mpls-static-lsp-information> get_mpls_static_lsp_information <get-mvrp-information> get_mvrp_information <get-mvrp-applicant-information> get_mvrp_applicant_information <get-mvrp-dynamic-vlan-memberships> get_mvrp_dynamic_vlan_memberships <get-mvrp-interface-information> get_mvrp_interface_information
CLI Command
clear dhcpv6 server binding
Response Tag Element

NONE
clear dhcpv6 server statistics
NONE
clear mpls static-lsp
NONE
clear mvrp statistics
NONE
clear security idp application-ddos cache
NONE
clear security idp status
<clear-idp-status-information>
clear vrrp
<vrrp-message>
clear vrrp interface
<vrrp-message>
request system scripts refresh-from
NONE
show dhcpv6 server binding
<dhcpv6-server-binding-information>
show dhcpv6 server statistics
<dhcpv6-server-statistics-information>
show mpls static-lsp
<mpls-static-lsp-information>
show mvrp
<mvrp-information>
show mvrp applicant-state
<mvrp-applicant-state>
show mvrp dynamic-vlan-memberships
<mvrp-vlan-information>
show mvrp interface
<mvrp-interface-information>
19
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.1 (continued)
Request Tag Element
<get-mvrp-registration-state> get_mvrp_registration_state <get-mvrp-interface-statistics> get_mvrp_interface_statistics <get-idp-subscriber-policy-list> get_idp_subscriber_policy_list <get-idp-policy-template-information> get_idp_policy_template_information <get-idp-detail-status-information> get_idp_detail_status_information <get-service-nat-mapping-information> get_service_nat_mapping_information <get-task-memory-information> get_task_memory_information <get-vrrp-information> get_vrrp_information <get-vrrp-interface-information> get_vrrp_interface_information <get-vrrp-track-interfaces> get_vrrp_track_interfaces
CLI Command
show mvrp registration-state
Response Tag Element

<mvrp-registration-information>
show mvrp statistics
<mvrp-interface-statistics>
show security idp policies
<idp-subscriber-policy-list>
show security idp policy-templates-list
<idp-policy-template-information>
show security idp status detail
<idp-detail-status-information>
show services nat mappings
<service-nat-mapping-information>
show task memory
<task-memory-information>
show vrrp
<vrrp-information>
show vrrp interface
<vrrp-information>
show vrrp track
<vrrp-information>
20
[JUNOS XML API Operational Reference]

MPLS Applications
Static LSPs at the ingress routerYou can now configure a named static LSP at the ingress router. This feature allows you to configure multiple static LSPs between two specific routers. It is not necessary to configure unique names for static versus dynamic LSPs (a static LSP could have the same name as a dynamic LSP configured on the same router). This feature also allows you to configure a single-hop static LSP by specifying either an explicit null label or no label. To configure a static LSP on an ingress router, include the ingress statement at the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level. You must also configure the to and next-hop statements at the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level. You can optionally configure the push statement. If you configure the push statement, you must specify a non-reserved label in the range of 0 through 1,048,575. To display information about ingress static LSPs, issue the show mpls lsp static ingress command. To display routing table entries corresponding to ingress static LSPs, issue the show route table inet.3 command or the show route next-hop next-hop-ip-address static-label-switched-path static-lsp-name command. [MPLS, Routing Protocols and Policies Command Reference]
Static LSPs at the transit routerYou can now configure a named static LSP on a transit router. To configure a transit static LSP, include the transit statement at the [edit protocols mpls static-label-switched-path path-name] hierarchy level and include the next-hop statement at the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level. You must also configure either the pop or the swap statement at the [edit protocols mpls static-label-switched-path static-lsp-name transit] hierarchy level. If you configure the swap statement, you must specify a non-reserved label in the range of 0 through 1,048,575. The transit static LSP is added to the mpls.0 routing table. You should configure each static LSP using a unique name and at least a unique incoming label on the router. Each transit static LSP can have one or more incoming labels configured. If a transit LSP has more than one incoming label, each would effectively operate as an independent LSP, meaning you could configure all of the related LSP attributes for each incoming label. The range of incoming labels available is limited to the standard static LSP range of labels (1,000,000 through 1,048,575). To verify that a static LSP has been added to the routing table, issue the show route table mpls.0 command. [MPLS]
Bypass static LSPsYou can now configure a named bypass static LSP for ingress and transit static LSPs, to be used if the primary LSP fails. To configure a bypass static LSP, include the bypass statement at the [edit protocols mpls static-label-switched-path path-name] hierarchy level. You must also configure the to and next-hop statements at the [edit protocols mpls static-label-switched-path static-lsp-name bypass] hierarchy level. You can also configure link and node protection for static LSPs. If you configure both link and node protection for the static LSP and the primary link fails, the node protection feature is preferred.
21
[MPLS]
Static LSP revert timerYou can now configure a revert timer for ingress and transit static LSPs. After traffic has been switched to a bypass static LSP, it is typically switched back to the primary static LSP when it comes back up. There is a configurable delay in the time (called the revert timer) between when the primary static LSP comes up and when traffic is reverted back to it from the bypass static LSP. This delay is needed because when the primary LSP comes back up, it is not certain whether all of the interfaces on the downstream node of the primary path have come up yet. The delay range is from 0 through 65,535 seconds and is configurable at each interface. If you configure a value of 0, traffic is never automatically reverted to the primary LSP, even if it does come back up. The only exception is if the bypass LSP goes down. The default value is 5 seconds. To configure the revert timer for an interface, include the protection-revert-time statement at the [edit protocols mpls interface interface-name static] hierarchy level. You can display the revert timer value for an interface using the show mpls interface detail command. [MPLS]
Static LSP traceoptionsYou can now configure the traceoptions statement to trace messages related to ingress and transit static LSPs by including the static flag at the [edit protocols mpls traceoptions flag] hierarchy level. [MPLS]
Static LSP statisticsYou can now display statistics related to MPLS static LSPs by issuing the show mpls static-lsp statistics command and the monitor static-lsp lsp-name command. The show mpls static-lsp statistics command includes the following options: ingress, transit, bypass, and name static-lsp-name. This command displays the packet count and byte count for the static LSP. You can clear the statistics for static LSPs by issuing the clear mpls static-lsp statistics command. You can also log the static LSP statistics to a file by specifying a file for the MPLS statistics statement. You can configure this file using the set protocols mpls statistics interval interval file filename command. [MPLS, Routing Protocols and Policies Command Reference]
Multiplay
Border Gateway Function (BGF) RTCP XR reportingProvides support for the H.248 RECRTCPXR (Received RTCP Extended Reporting) and RECRTCPXRBM (Received RTCP XR Burst Mode) reporting packages. The RECRTCPXR package defines properties and statistics that provide extended quality-of-service metrics received from the gateway controller. The RECRTCPXRBM package defines properties and statistics that provide burst metrics received from the gateway controller. Report data is available to the BGF when the gateway controller sends the relevant XR reporting packets and RTCP monitoring is active. Not all gateway controllers send the extended reporting packets. When XR packets are not received, all XR fields are displayed as 0s (zeroes). You can use the following existing command to display the RECRTCPXR and RECRTCPXRBM report fields for a given gate-id: show services pgcp gate gateway-name statistics gate-id gate-id. [Multiplay Solutions, System Basics Command Reference]
22
Integrated Multi-Services Gateway (IMSG) failed call reportingProvides more extensive statistics on failed calls through improved show command output. You can use the following existing command to display statistics on failed calls: show services border-signaling-gateway calls-failed gateway gateway-name. [Multiplay Solutions, System Basics Command Reference]
Integrated Multi-Services Gateway (IMSG) media releaseEnables the IMSG SIP function to release media resources when handling calls between two entities in the same media realm (the virtual interface specified in the PGCP configuration). When the new call usage policies for both entities allow media release, media resources are shared instead of being reserved for both entities. This improves the utilization of media resources and prevents latency. To configure media release, enter the media-release statement at the [edit services
border-signaling-gateway gateway-name sip new-call-usage-policy policy-name term term-name then media-policy] hierarchy level.
[Multiplay Solutions, Services Interfaces]

Routing Policy and Firewall Filters
New MPLS firewall filter match conditions (T Series routers)The JUNOS Software now supports filtering MPLS-tagged IPv4 packets based on IP parameters for up to five MPLS stacked labels. To configure the filter match conditions for an MPLS family based on IP parameters, include the from statement at the [edit firewall family family-name filter filter-name term term-name] hierarchy level:
from { match-conditions; }
NOTE: New filter match conditions are applicable only for MPLS-tagged IPv4 packets. MPLS-tagged IPv6 packets are not supported by this filter. [Policy Framework, Routing Protocols and Policies Command Reference]
23
Routing Protocols
BGP support for MDT-SAFI updates without a route targetBy default, the JUNOS Software requires MDT-SAFI updates to have a route target attached. Some vendors do not support attaching route targets to the MDT-SAFI updates. For interoperability with these vendors, the JUNOS Software allows importing MDT-SAFI updates without a route target being attached. The MDT-SAFI is imported if the MDT default address in the MDT-SAFI prefix matches the MDT default address configured within the routing instance. To configure the MDT default address, include the group-address group-address statement at the [edit routing-instances routing-instance-name provider-tunnel pim-ssm] hierarchy level. [Multicast, Policy Framework]
Distributed periodic packet management support for aggregate interfacesExtends support for the Bidirectional Forwarding Detection (BFD) protocol to use the periodic packet management daemon (PPMD) to distribute IPv4 sessions over aggregate interfaces. PPMD automatically runs on the Routing Engine and the Packet Forwarding Engine. To disable PPMD on the Packet Forwarding Engine only, include the no-delegate-processing statement at the [edit routing-options ppm] hierarchy level. Only IPv4 BFD sessions over aggregate interfaces are supported. PPMD does not support IPv6 BFD sessions over an aggregate interface or MPLS BFD sessions over an aggregate interface. [Routing Protocols]
PIM join suppression supportEnables a router to defer sending join messages to an upstream router when identical join messages are sent on the same multiaccess network. This improves scalability and efficiency by reducing the number of identical messages sent to the same router. This feature is useful when there are a large number of routers on a multiaccess network that will be receiving traffic for a particular multicast group. Suppressing joins at each router saves bandwidth and reduces heavy processing at upstream routers. PIM join suppression can be implemented per multiaccess interface and per multicast group. It is only needed on downstream routers, and does not need to be implemented on upstream routers in order for it to work. A tracking bit field on the LAN prune delay hello option is used in the CLI to enable join suppression for downstream routers. By default, the tracking bit is set to 1 and PIM join suppression is disabled. This is the default behavior for JUNOS Release 10.0 and earlier for Juniper Networks routers. With join suppression disabled (T-bit=1), a downstream receiving router will send join messages even if it receives identical joins for the same upstream router, as long as no other router in the network has join suppression enabled. When the tracking bit is set to 0 for at least one neighbor on this interface, join suppression is enabled, and the receiving router will defer sending identical joins. Use reset-tracking-bit in the CLI to enable join suppression. When an upstream router receives a join message, its behavior is independent of the value of the T-bit in the hello option. When join suppression is triggered, a timer is activated and all sending of joins is deferred for the length of time
24
specified by the timer. This is a random timer with value ranges between 0 to Max Override Interval. The timer is reset each time join suppression is triggered, and the defer period is dependent on other settings in the LAN prune delay, including propagation-delay and override-interval. Use the show protocols PIM command to see if the reset-tracking-bit is present, indicating that the T-bit has been changed to 0 and PIM join suppression is enabled. [Multicast, Routing Protocols and Policies Command Reference]
Improve IGMPv3 snooping performance using bulk updates 1a3,14Whenever an individual interface joins or leaves a multicast group, a new next-hop entry is installed in the routing table and the forwarding table. This can require a lot of processing time when the frequency and number of IGMP join and leave messages are high. A new configuration statement can be used to accumulate outgoing interface changes and perform bulk updates to the routing table and forwarding table. This reduces the processing time and memory overhead required when processing join and leave messages, thus improving scalability.This is useful for applications such as Internet Protocol television (IPTV), in which users changing channels can create thousands of interfaces joining or leaving a group in a short period of time. To enable bulk updates of join and leave messages, include the next-hop-hold-time statement and specify the number of milliseconds to wait before processing the messages. The next-hop-hold-time statement can be configured at the [edit routing-instances routing-instance-name] hierarchy level. The hold time can be configured from 1 to 1000 milliseconds. The routing instance must be of type VPLS or virtual-switch. If the next-hop-hold-time statement is deleted from the router configuration, IGMP bulk updates are disabled. The configuration of the next-hop-hold-time statement can be verified using the show multicast snooping route command. [Multicast, Routing Protocols and Policies Command Reference]
Hub-and-spoke support for multiprotocol BGP-based multicast VPNs with PIM-SSM GRE S-PMSI transportMultiprotocol 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:
Include the group-range statement and specify the group address range at the [edit routing-instances routing-instance-name provider-tunnel selective group
25
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]
26
Services Applications
FlowTapLite enhancementsExtend support for interception of IPv6 packets on MX Series, M120, and M320 routers. For IPv6, the global filter taps packets from the default IPv6 routing table and does not tap packets from other VRFs. To tap packets from other VRFs, you can install separate VRF filters. For IPv4, the global filter intercepts all IPv4 packets irrespective of the VRF. The limit for filters remains 3000, which is now shared between IPv4 and IPv6. For example, you can install 3000 IPv4 filters or 3000 IPv6 filters, or a combination of both that totals 3000. You cannot install 3000 IPv4 filters and 3000 IPv6 filters. No new statements are required to configure these enhancements. However, whether you use IPv6 flow tapping or not, you must include the family inet6 statement at the [edit interfaces vt-fpc/pic/port unit logical-unit-number] hierarchy level. [Services Interfaces]
Subscriber Access Management
27
JUNOS subscriber access scaling values (M120, M320, and MX Series routers)Table 2 on page 28 lists the DHCP, PPP, and PPPoE scaling values supported for subscriber access in this release of M120, M320, and MX Series routers. In this table, DPC means only MX Series Enhanced Queuing IP Services DPCs (DPCE-R-Q-40GE-SFP and DPCE-R-Q-4XGE-XFP). These DPCs support only DHCP subscribers; they do not support PPP subscribers.
Table 2: Subscriber Access Scaling Values for M120, M320, and MX Series Routers
Subscriber Access Feature
DHCP client bindings per chassis
M120/M320
MX240 120,000
MX480/960 120,000
DHCP subscriber VLANs
Per DPC Per chassis with DPCs Per Trio MPC/MIC Per chassis with Trio MPC/MIC
16,000 32,000 64,000 64,000
16,000 64,000 64,000 64,000
PPP logical interfaces
Dynamic PPPoE interfaces per chassis Dynamic PPPoE interfaces per IQ2/IQ2E PIC Dynamic PPPoE interfaces per Trio MPC/MIC Static interfaces per chassis
15,999 4000 15,999
63,999 32,000 15,999
63,999 32,000 15,999
PPPoE subscriber VLANs
Per IQ2/IQ2E PIC Per chassis with IQ2/IQ2E PIC Per Trio MPC/MIC Per chassis with Trio MPC/MIC
2000 8000
32,000 32,000
32,000 32,000
PPP connections (logical interfaces) are supported in a range of configurations. For example, 63,999 PPP connections per chassis are supported when all subscribers are configured on the same VLAN. In this case, 63,999 pp0 interfaces are configured under the same VLAN logical interface and the one remaining logical interface is consumed for the single VLAN. At the other extreme, when you configure each subscriber on a separate VLAN (using stacked VLANs), up to 32,000 PPP connections per chassis are supported.
28
In this case, each subscriber connection consumes two logical interfaces: one for the VLAN logical interface and one for the pp0 logical interface. The M120, M320, and MX Series routers support a maximum of 2000 different dynamic profiles per chassis. [Subscriber Access]
Support for dynamic CoS for subscriber interfaces on Trio MPC/MIC interfaces (MX Series routers)Enables you to configure dynamic CoS for subscriber interfaces on Trio MPC/MIC interfaces that are now available on MX Series routers. In earlier releases, dynamic CoS was supported on EQ DPCs only. To configure dynamic CoS on Trio MPC/MIC interfaces, you must enable the hierarchical scheduler for an interface at the [edit interfaces] hierarchy level. You can then configure dynamic CoS parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level. The CoS parameters are dynamically applied to subscribers services when they log in or change services. Trio MPC/MIC interfaces support CoS for the following interface types: static VLAN, demux, static and dynamic PPPoE, and aggregated Ethernet subscriber interfaces. In this release, hierarchical CoS for aggregated Ethernet interfaces is supported on the Trio MPC/MIC product when a static VLAN configured over the aggregated Ethernet interface. It is not supported for static or dynamic demux subscriber interfaces configured over aggregated Ethernet. [Subscriber Access]
Support for CoS on dynamic PPPoE subscriber interfaces (MX Series routers)Enables you to configure CoS for dynamic PPPoE subscriber interfaces on Trio MPC/MIC interfaces available on MX Series routers and the Intelligent Queuing 2 (IQ2) PIC on M120 and M320 Series routers. In earlier releases, only static CoS was supported for static PPPoE subscriber interfaces configured on IQ2 PICs on M120 and M320 Series routers. To configure CoS for a dynamic PPPoE interface, configure the shaping and scheduling parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level. You then attach the traffic control profile to the dynamic PPPoE interface by including the output-traffic-control-profile profile-name statement at the [edit dynamic-profiles profile-name class-of-service interfaces $junos-interface-ifd-name unit $junos-underlying-interface-unit] hierarchy level. When the subscriber logs in, PPP supplies pp0 as the $junos-interface-ifd-name variable, and supplies the PPPoE logical interface number for the $junos-underlying-interface-unit variable. [Subscriber Access]
Support for IPv6 for dynamic subscriber services (MX Series routers)Enables you to configure IPv6 addressing and prefixes for dynamic subscriber services. In earlier releases, dynamic subscriber services supported IPv4 addressing only. You can now configure both IPv4 and IPv6 addressing in the same dynamic profile to grant access and services to IPv4 and IPv6 subscribers. In this release, IPv6 addressing is supported for static and dynamic VLAN subscriber interfaces and dynamic demux subscriber interfaces.
29
To enable IPv6 addressing for a static VLAN subscriber interface, include the family inet6 statement at the [edit dynamic profiles profile-name interfaces interface-name unit logical-unit-number] hierarchy level. To enable IPv6 addressing for a demux subscriber interface, include the family inet6 statement at the [edit dynamic profiles profile-name interfaces demux0] hierarchy level. To enable an IPv6 source address for the interface, specify the new $junos-subscriber-ipv6address predefined variable with the demux-source statement at the [edit dynamic profiles profile-name interfaces demux0 unit $junos-interface-unit family inet6] hierarchy level. The values for this variable are supplied to the interface by DHCP when the subscriber logs in. This feature enables you to configure dynamic, classic, and fast update firewall filters for IPv6 families. In addition, you can configure aggregate CoS when IPv4 and IPv6 families share a logical interface, and per-family CoS when IPv4 and IPv6 families do not share a logical interface (such as a demux interface). The following new predefined variables have been added to implement IPv6 addressing for subscriber services:
Dynamic Profile Variable $junos-framed-route-ipv6-address-prefix $junos-framed-route-ipv6-nexthop $junos-input-ipv6-filter
Definition Route prefix of an IPv6 access route. Next-hop address of an IPv6 access route. Attaches a filter based on RADIUS VSA 26-106 (IPv6-Ingress-Policy-Name) to the interface. IPv6 prefix value used when configuring the Router Advertisement protocol. Attaches a filter based on RADIUS VSA 26-107 (IPv6-Egress-Policy-Name) to the interface. Selects the preferred IPv6 source address associated with the loopback address used for the subscriber. IPv6 address of the subscriber.
$junos-ipv6-ndra-prefix
$junos-output-ipv6-filter
$junos-preferred-source-ipv6-address
$junos-subscriber-ipv6-address
RADIUS supports activation, deactivation, and change of authorization (CoA) for IPv6 services. The following new RADIUS attributes and VSAs have been added to implement IPv6 addressing for subscriber services:
Attribute Number 97 99 26-106 26-107
Attribute Name Framed-IPv6-Prefix Framed-IPv6-Route IPv6-Ingress-Policy-Name IPv6-Egress-Policy-Name
30
Attribute Number 26-129 26-151 26-152 26-153 26-154 26-155 26-156 26-157
Attribute Name IPv6-NdRa-Prefix IPv6-Acct-Input-Octets IPv6-Acct-Output-Octets IPv6-Acct-Input-Packets IPv6-Acct-Output-Packets IPv6-Acct-Input-Gigawords IPv6-Acct-Output-Gigawords IPv6-NdRa-Pool-Name
You can monitor IPv6 statistics by issuing the show subscribers and show network-access aaa subscriber commands. [Subscriber Access]
Support for dynamic PPPoE interfaces (M120, M320, and MX Series routers)Enables you to configure dynamically created PPPoE logical interfaces over statically created underlying interfaces. For subscriber access purposes, the dynamic PPPoE logical interface represents a dynamic PPPoE subscriber interface. The router automatically and transparently creates the dynamic interface in response to an external event, such as the receipt of traffic on an underlying interface. For example, the router creates a dynamic PPPoE logical interface when it receives a PPPoE Active Discovery Request (PADR) control packet from the client on an underlying interface to which a PPPoE dynamic profile is assigned. The router uses the information configured in the dynamic profile to determine the properties of the dynamic PPPoE logical interface. The use of dynamically created PPPoE interfaces gives you the flexibility of having the router create the dynamic PPPoE logical interface only when the subscriber logs in on the associated underlying interface. By contrast, statically created interfaces always allocate and consume system resources upon interface creation, even when no traffic is flowing on the interface. Configuring and using dynamically created interfaces helps you effectively and conveniently manage subscriber access networks that provide services to large numbers of subscribers. Configuration of dynamic PPPoE logical interfaces is supported on Intelligent Queuing 2 (IQ2) PICs on M120 and M320 Series routers, and on Trio MPC/MIC interfaces on MX Series routers. To configure a dynamic PPPoE logical interface:
1.
Configure a dynamic profile to define the attributes of the dynamic PPPoE logical interface. To do so, include the following statements at the [edit dynamic-profiles profile-name] hierarchy level:
dynamic-profiles { profile-name {
31
interfaces pp0 { unit $junos-interface-unit { keepalives interval seconds; no-keepalives; pppoe-options { underlying-interface "$junos-underlying-interface"; server; } ppp-options { chap; pap; } family inet { unnumbered-address interface-name; address address; service { input { service-set service-set-name <service-filter filter-name>; } output { service-set service-set-name <service-filter filter-name>; } } filter { input filter-name; output filter-name; } } } } } }
You can use most of these same statements to configure statically created PPPoE interfaces, with the following important differences. When you configure a profile to dynamically create a PPPoE interface, you must specify the $junos-interface-unit predefined dynamic variable instead of the actual logical unit number for the unit statement, and the $junos-underlying-interface predefined dynamic variable instead of the actual name of the underlying interface for the underlying-interface statement.
2.
Assign the dynamic profile to the underlying interface on which the router creates the dynamic PPPoE interface. To do so, include the pppoe-underlying-options statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level, as follows:
interfaces { interface-name { unit logical-unit-number { encapsulation ppp-over-ethernet; pppoe-underlying-options { access-concentrator name; dynamic-profile profile-name; duplicate-protection; max-sessions number; }
32
} } }
The statements at the [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options] hierarchy level define the following PPPoE-specific attributes for the underlying interface:
To provide an alternative access concentrator (AC) name in the AC-NAME tag in a PPPoE control packet, include the access-concentrator statement. To assign a previously configured dynamic profile to the underlying interface, include the dynamic-profile statement. This is the only required statement for configuring dynamic PPPoE interfaces at the [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options] hierarchy level. To prevent the activation of another dynamic PPPoE logical interface on the same underlying interface on which a dynamic PPPoE logical interface is already active for the same client, include the duplicate-protection statement. To configure the maximum number of dynamic PPPoE logical interfaces (sessions) that the router can activate on the underlying interface, include the max-sessions statement.
To display information about the dynamic PPPoE interface configuration, use the show pppoe underlying-interfaces, show pppoe statistics, and show pppoe interfaces operational commands. You can also use the clear pppoe statistics command to clear packet statistics on the underlying interface. [Subscriber Access]
Support for PPPoE Layer 3 wholesale configuration in a subscriber access networkEnables you to configure PPPoE Layer 3 wholesaling within a subscriber access network. Wholesale access is the process by which an access network provider partitions the access network into separately manageable and accountable subscriber segments for resale to other network providers. An access network provider may elect to wholesale all or part of its network to one or more service providers (retailers). In a Juniper Networks subscriber access network, you accomplish Layer 3 partitioning through the use of logical systems (LSs) and routing instances. Logical systems enable you to divide a physical router into separate, distinct, logical administrative domains. This method of division enables multiple providers to administer the router simultaneously and each have access to only the portions of the configuration that are relevant to their specific logical system. The JUNOS Software supports up to 15 named logical systems in addition to the default logical system (inet.0). Routing instances are typically used in Layer 3 VPN scenarios. A routing instance does not have the same level of administrative separation as does a logical system. The routing instance defines a distinct routing table, set of routing policies, and set of interfaces, but it does not provide administrative isolation.
33
When configuring PPPoE Layer 3 wholesale for a subscriber access network, keep the following in mind:
PPPoE Layer 3 wholesaling supports the use of only the default logical system using multiple routing instances. Each routing instance must contain a loopback with one or more addresses to be used for the unnumbered interface. However, unlike configuring Layer 3 wholesale for DHCP, the loopback interface address does not have to be within the same subnetwork as the client IP address. The system ignores the preferred-source-address option for the unnumbered-address statement when it is configured. To avoid confusion, we recommend that you do not configure the preferred-source-address option for the unnumbered-address statement when configuring an unnumbered interface. However, the system will function appropriately, regardless of whether or not you have configured the preferred-source-address option.
To configure PPPoE Layer 3 wholesale for a subscriber access network:
Include the routing-instances statement along with the $junos-routing-instance dynamic variable at the [edit dynamic-profiles profile-name] hierarchy level. Include the interface statement along with the $junos-interface-name dynamic variable at the [edit dynamic-profiles profile-name routing-instances $junos-routing-instance] hierarchy level. Include the unnumbered-address statement along with $junos-loopback-interface dynamic variable at the [edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit family inet] hierarchy level.
To view the logical system and routing instance for each subscriber, use the show subscriber operational command. [Subscriber Access, Broadband Subscriber Management]
PPP PAP and CHAP enhancements for subscriber management (M120 and M320 routers)Subscriber management supports both bidirectional and unidirectional PPP PAP and CHAP authentication. In subscriber management, the router's PPP interface typically authenticates the remote client (the subscriber). Bidirectional authentication is not usually used in a subscriber management environment, even though it is supported for static interfaces. Also, subscriber management uses AAA to authenticate subscribers, which removes the need to specify an access profile or a default password for PAP or CHAP authentication.
For static interfaces, the router supports bidirectional authentication. If you do not include the passive statement in the configuration, the router functions as the authenticator for remote clients. If you include the passive statement, the router is authenticated by the remote client. Also, when you specify the passive statement for static interfaces, you must specify other attributes, as described in the JUNOS Network Interfaces Guide. For dynamic interfaces, the router supports unidirectional authentication onlythe router always functions as the authenticator. When you configure PPP authentication in a dynamic profile (at the [edit dynamic-profiles] hierarchy
34
level), the pap and chap statements do not support any additional configuration options, including the passive statement. PPP dynamic interfaces are supported only on PPPoE interfaces (interface pp0) for this release. To configure CHAP or PAP authentication for static interfaces, use the following stanza:
[edit interfaces interface-name unit logical-unit-number] ppp-options { chap { access-profile name; default-chap-secret name; local-name name; passive; } pap { access-profile name default-pap-password password; local-name name; local-password password; passive; } }
To configure CHAP or PAP authentication for dynamic interfaces, use the following stanza:
[edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit] ppp-options { chap; pap; }
[Subscriber Access, Network Interfaces]
Support for input and output filters on the Trio MPC/MIC interfaces on MX Series routersEnables you to apply input and output filters to logical interfaces that are running over the Trio MPC/MIC interfaces on MX Series routers. To apply input and output filters for logical interfaces, include the input input-filter-name and output output-filter-name statements. To apply these filters statically, include the statements at the [edit interfaces interface-name unit logical-unit-number filter] hierarchy level. To apply these filters dynamically, include the statements at the [edit dynamic-profiles profile-name interfaces interface-name unit $junos-interface-unit filter] hierarchy level. For information about how to create filters, see the Policy Framework Configuration Guide. [Subscriber Access, Network Interfaces, Policy Framework]
PPPoE interface support for subscriber secure policy traffic mirroring on Trio MPC/MIC interfaces on MX Series routersEnables you to configure subscriber secure policy traffic mirroring to provide RADIUS-initiated mirroring for subscribers on PPPoE interfaces that are running over Trio MPC/MIC interfaces on MX Series routers.
35
For information about how to configure subscriber secure policy traffic mirroring, see the Subscriber Access Configuration Guide. [Subscriber Access]
Support for PPP/PPPoE subscriber interfaces on the Trio MPC/MIC family of products (MX Series routers)Enables you to configure PPP/PPPoE subscriber interfaces that are running over the Trio MPC/MIC family of products when used on MX Series routers. To configure PPP/PPPoE subscriber interfaces, you use the statements and procedures that are described in the JUNOS Network Interfaces Guide. [Subscriber Access, Network Interfaces]
Support for demux VLAN interface configuration on Ethernet and aggregate Ethernet Trio MPC/MIC interfacesEnables the static or dynamic creation of demux VLAN interfaces with an underlying interface of aggregate Ethernet or Gigabit/10Gigabit Ethernet. When configuring static VLAN demux interfaces, specify a VLAN ID for the vlan-id statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number] hierarchy level. You must also specify the underlying device name for the underlying-interface statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number demux-options] hierarchy level. When configuring dynamic VLAN demux interfaces, specify the VLAN ID variable ($junos-vlan-id) for the vlan-id statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number] hierarchy level. You must also specify the underlying device name variable ($junos-interface-ifd-name) for the underlying-interface statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number demux-options] hierarchy level. In addition, keep the following in mind while configuring dynamic VLANs over IP demux interfaces:
Only single VLAN and stacked VLAN tag options are supported as VLAN selectors. IP demux over IP demux stacking is not supported. This support is limited to Trio MPC/MIC interfaces on MX Series routers.
[Subscriber Access]
System Logging
New and deprecated system log families and tagsThe following system log families are new in this release:
ALARMDDescribes messages with the ALARMD prefix. They are generated by the alarm process (alarmd). CONNECTIONDescribes messages with the CONNECTION prefix. They are generated whenever the alarm process is unable to connect to another process.
36
FCDDescribes messages with the FCD prefix. They are generated by the Fibre Channel process (fcd) which connects servers to disks and tape devices in a storage area network. GPRSDDescribes messages with the GPRSD prefix. They are generated by the general packet radio service process (gprsd) that integrates with existing GSM networks and offers mobile subscribers with packet-switched data services access to corporate networks and the Internet. LIBJSNMPDescribes messages with the LIBJSNMP prefix. They are generated by the libjsnmp process. UTMDDescribes messages with the UTMD prefix. They are generated by the unified threat management process (utmd), which protects the network from all types of attack. WEBFILTERDescribes messages with the WEBFILTER prefix. They are generated by the Web filtering process (webfilter), which allows you to manage Internet usage by preventing access to inappropriate Web content.
The following system log messages are new in this release:

COSD_NULL_INPUT_ARGUMENT DCD_GRE_CONFIG_INVALID DCD_PARSE_ERROR_MAX_HIER_LEVELS DCD_PARSE_ERR_INCOMPATIBLE_CFG EVENTD_ALARM_CLEAR EVENTD_TEST_ALARM PFE_ANALYZER_CFG_FAILED PFE_ANALYZER_SHIM_CFG_FAILED PFE_ANALYZER_TABLE_WRITE_FAILED PFE_ANALYZER_TASK_FAILED PFE_COS_B2_ONE_CLASS PFE_COS_B2_UNSUPPORTED RPD_RA_CFG_CREATE_ENTRY_FAILED RPD_RA_CFG_INVALID_VALUE RPD_RA_DYN_CFG_ALREADY_BOUND RPD_RA_DYN_CFG_INVALID_STMT RPD_RA_DYN_CFG_SES_ID_ADD_FAIL
37
RPD_RA_DYN_CFG_SES_ID_MISMATCH RPD_RT_CFG_BR_CONFLICT
The following system log messages are no longer documented:

DFWD_CONFIG_FW_UNSUPPORTED LLDPD_PARSE_ARGS LLDPD_PARSE_BAD_SWITCH LLDPD_PARSE_CMD_ARG LLDPD_PARSE_CMD_EXTRA LLDPD_PARSE_USAGE LPDFD_DYN_SDB_OPEN_FAILED
User Interface and Configuration
Enhanced support for up to 64 ECMP nexthops for load-balancing on M10i routers with Enhanced CFEB, M320, M120, MX Series, and T Series Core routersThe JUNOS Software supports configurations of 16, 32, or 64 equal-cost multipath (ECMP) next hops for RSVP and LDP LSPs on M10i routers with an Enhanced CFEB, and M320, M120, MX Series, and T Series routers. For networks with high-volume traffic, this provides more flexibility to load-balance the traffic over as many as 64 LSPs. To configure the maximum limit for ECMP next hops, include the maximum-ecmp next-hops statement at the [edit chassis] hierarchy level:
[edit chassis] maximum-ecmp next-hops;
You can configure a maximum ECMP next-hop limit of 16, 32, or 64 using this statement. The default limit is 16. The following types of routes support the ECMP maximum next-hop configuration for as many as 64 ECMP gateways:

Static IPv4 and IPv6 routes with direct and indirect next-hop ECMPs LDP ingress and transit routes learned through associated IGP routes RSVP ECMP next hops created for LSPs OSPF IPv4 and IPv6 route ECMPs ISIS IPv4 and IPv6 route ECMPs EBGP IPv4 and IPv6 route ECMPs IBGP (resolving over IGP routes) IPv4 and IPv6 route ECMPs
38
The enhanced ECMP limit of up to 64 ECMP next hops is also applicable for Layer 3 VPNs, Layer 2 VPNs, Layer 2 circuits, and VPLS services that resolve over an MPLS route, because the available ECMP paths in the MPLS route can also be used by such traffic.
NOTE: The following FPCs on M320, T640, and T1600 routers only support 16 ECMP next hops:

(M320, T640, and T1600 routers only) Enhanced II FPC1 (M320, T640, and T1600 routers only) Enhanced II FPC2 (M320 and T640 routers only) Enhanced II FPC3 (T640 and T1600 routers only) FPC2 (T640 and T1600 routers only) FPC3
If a maximum ECMP next-hop limit of 32 or 64 is configured on an M320, T640, or T1600 router with any of these FPCs installed, the Packet Forwarding Engines on these FPCs use only the first 16 ECMP next hops. For Packet Forwarding Engines on FPCs that support only 16 ECMP next hops, the JUNOS Software generates a system log message if a maximum ECMP next-hop limit of 32 or 64 is configured. However, for Packet Forwarding Engines on other FPCs installed on the router, a maximum configured ECMP limit of 32 or 64 ECMP next hops is applicable.
To view the details of the ECMP next hops, issue the show route command. The show route summary command also shows the current configuration for the maximum ECMP limit. To view details of the ECMP LDP paths, issue the traceroute mpls ldp command. [System Basics, Policy Framework, Routing Protocols Command Reference]
Support for configuring time-based user accessThe JUNOS Software enables you to configure time-based restrictions for user access to log in to a device. This is useful for restricting the time and duration of user logins for all users belonging to a login class. You can specify the days of the week when users can log in, the access start time, and the access end time.
To configure user access on specific days of the week, without any restrictions on the duration of login, include the allowed-days statement only.
[edit system] login { class class-name { allowed-days days-of-the-week; }
To configure user access on all the days of the week for a specific duration, include the access-start and access-end statements only.
[edit system]
39
login { class class-name { access-start HHMM; access-end HHMM; } }
To configure user access on specific days of the week for a specified duration, include the allowed-days, access-start, and access-end statements.
[edit system] login { class class-name { allowed-days days-of-the-week; access-start HHMM; access-end HHMM; } }
[System Basics]
Dynamic IPv6 filters (MX Series routers)Subscriber management now supports dynamic IPv6 filters. The dynamic filter feature supports both classic and fast update filters, and both IPv4 and IPv6. You specify the filters in a dynamic profile, which associates the filter to an interface. When the dynamic profile is triggered, the profile applies the filter to an interface. You use the filter statement at the [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number family (inet | inet6)] hierarchy level to associate a dynamic profile to an interface. [Subscriber Access, Policy Framework]
Support for classifiers and rewrite rules in dynamic subscriber-based CoS (MX Series routers)You can now associate classifiers and rewrite rules with a subscriber interface in a dynamic profile. You must statically configure the classifiers and rewrite rules at the static [edit class-of-service] hierarchy level. 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. The supported classifier types for subscriber interfaces are dscp, dscp-ipv6, ieee-802.1, and inet-precedence. 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 supported rewrite rules for subscriber interfaces are dscp, dscp-ipv6, ieee-802.1, and inet-precedence. [Subscriber Access]
Dynamic configuration of the router advertisement protocolIn a network deployment where router interfaces are configured statically, you might need to configure the router advertisement protocol on only a small number of
40
interfaces on which it might run. However, in a subscriber access network, static configuration of the router advertisement protocol becomes impractical because the number of interfaces that potentially need the router advertisement protocol increases substantially. In addition, deploying services in a dynamic environment requires dynamic modifications to interfaces as they are created. To ensure that dynamic interfaces are created with the ability to use the router advertisement protocol, this release supports their configuration dynamically at the [edit dynamic-profiles profile-name protocols] hierarchy level. The dynamic profile applies router advertisement protocol configuration to dynamic interfaces as they are created. To minimally configure the router advertisement protocol, include the router-advertisement statement at the [edit dynamic-profiles profile-name protocols] hierarchy level, and the interface statement along with the $junos-interface-name dynamic variable. All other statements are optional. Optional router advertisement protocol statements include current-hop-limit, default-lifetime, managed-configuration, max-advertisement-interval, min-advertisement-interval, no-managed-configuration, no-other-stateful-configuration, other-stateful-configuration, prefix, reachable-time, and retransmit-timer. All of these statements appear at the [edit dynamic-profiles profile-name protocols router-advertisement] hierarchy level.
NOTE: Statements used for router advertisement protocol configuration at the [edit dynamic-profiles profile-name protocols] hierarchy level are identical in function to the same statements used for static router advertisement protocol configuration, with the exception of the interface and prefix statements which use dynamic variables. [Subscriber Access]
Related Topics
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 42 Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 52 Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers on page 69 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 71
41
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
Class of Service
Forwarding class to queue number maps not supported on Multiservices link services intelligent queuing (LSQ) interfacesIf you configure a forwarding class map associating a forwarding class with a queue number, these maps are not supported on Multiservices link services intelligent queuing (lsq-) interfaces. [Class of Service]
Forwarding and Sampling
Enhancement to the show firewall commandThe 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. [Routing Protocols and Policies Command Reference]
Disabling MAC address learning of neighbors through ARP or neighbor discovery for IPv4 and IPv6 traffic for logical interfacesThe JUNOS Software provides the no-neigbhor-learn configuration statement at the [edit interfaces interface-name unit interface-unit-number family inet] and [edit interfaces interface-name unit interface-unit-number family inet6] hierarchy levels. To disable ARP address learning for IPv4 traffic for a logical interface, include the no-neighbor-learn statement at the [edit interfaces interface-name unit interface-unit-number family inet] hierarchy level:
[edit interfaces interface-name unit interface-unit-number family inet] no-neighbor-learn;
To disable neighbor discovery for IPv6 traffic for a logical interface, include the no-neighbor-learn statement at the [edit interface interface-name unit logical-unit-number family inet6] hierarchy level:
[edit interfaces interface-name unit interface-unit-number family inet6] no-neighbor-learn;
[System Basics]
Logical and physical Ethernet interface bandwidthIf you configure a bandwidth on a logical Ethernet interface greater than the bandwidth configured for the corresponding physical Ethernet interface, the commit fails. The bandwidth of the logical interface should always be less than the bandwidth of the physical
42
interface. If you do not configure a bandwidth for the logical interface, it is automatically set to the bandwidth configured for the physical interface. [Network Interfaces]
Support for linerate mode on 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PIC (T640, T1600, TX Matrix Plus platforms) Enables you to configure the T640, T1600, and TX Matrix Plus routers to operate the 10-port 10-Gigabit OSE PIC in linerate mode, in which the OSE PIC disables oversubscription and operates in line rate mode. By default, the 10-port 10-Gigabit OSE PIC operates in 2:1 oversubscription mode. [System Basics]
New CoS information field added to the show interfaces extensive command outputThe output of the show interfaces extensive command now displays the class-of-service queue allocation information of the physical interfaces (intelligent queueing PICs such as IQ2 and so on) under the new class-of-service information category. In the previous releases, the class-of-service queue allocation information for physical interfaces was listed within the Packet Forwarding Engine configuration category:
host@user# show interfaces extensive ge-7/1/3 Packet Forwarding Engine configuration: Destination slot: 7 CoS information: Direction : Output CoS transmit queue Bandwidth Limit % 95 5 bps 950000000 50000000
Buffer
Priority
0 best-effort low none 3 network-control low none Direction : Input CoS transmit queue Limit
% 95 5
usec 0 0
Bandwidth
Buffer
Priority
0 best-effort low none 3 network-control low none
% 95 5
bps 950000000 50000000
% 95 5
usec 0 0
[Interfaces Command Reference]
Restriction on compatibility-mode adtran and verilinkOn 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. [Network Interfaces]
Support for internal clocking mode on OSE PICsThe 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PIC supports only internal clocking mode on its ports.
43
[Network Interfaces]
Commit-time warning messages at the [edit interfaces] hierarchy level are now system loggedCLI commit-time warnings displayed for configuration at the [edit interfaces] hierarchy level have been removed and are now logged as system log messages. This change is applicable to JUNOS Release 10.1R1 and later, 10.0R2, and 9.3R4. [CLI User Guide] Invalid count of queuesThe PD-5-10XGE-SFPP PICs in T Series routers do not display ingress control queue statistics as output from the show interfaces queue xe-fpc/pic/port forwarding-class command. However, you can use the following commands to display the ingress control queue statistics:

show interfaces queue both-ingress-egress xe-fpc/pic/port show interfaces queue xe-fpc/pic/port show interfaces queue xe-fpc/pic/port ingress
[Network Interfaces]
Support for configuration of a range of interfaces through the interface-range statementEnables you to group a range of identical interfaces and apply a common configuration for the interfaces using 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 group in expanded configuration, use the show | display inheritance command. [Network Interfaces, Interfaces Command Reference]
Enhancement to the show chassis fabric fpcs commandIn JUNOS Release 10.1 and later, the show chassis fabric fpcs command issued on a T640 or T1600 router displays destination errors in addition to link errors. The command output displays a list of Packet Forwarding Engines that have destination errors, for those SIBs that are in the Check state. This enhancement is also applicable to JUNOS Release 9.6 and 10.0. The following sample shows the enhanced output for this command:
user@host> show chassis fabric fpcs
Fabric management FPC state: FPC #3 PFE #1 SIB #2 Plane enabled SIB #3 Link error Destination error on PFEs 6 20 7 8 21 SIB #4 Destination error on PFEs 6 7 8 9 10 11 12 13 14 15 16 17 18 19 0 1 2 3 4 5 9 10 11 12 13 14 15 16 17 18 19 0 1 2 3 4 5
44
20
21
[System Basics Command Reference]
Modification to the output of the show interfaces extensive command outputFor IQ2E interfaces, the show interfaces extensive command output no longer displays the schedulers field, because there is no static scheduler partitioning of schedulers among different ports in IQ2E. [Interfaces Command Reference]
Enhancement to the show chassis sibs commandThe show chassis sibs command now displays destination errors for SIBS in the Check state. In JUNOS Release 10.1 and later and JUNOS Release 9.6 and 10.0, the command displays the number of destination errors for SIBS in the Check state:
user@host> show chassis sibs
Slot State 0 Empty 1 Empty 2 Check (21 destination errors) 55 seconds 3 Check (0 destination errors) 45 seconds 4 Empty
Uptime
1 day, 1 hour, 32 minutes, 1 day, 1 hour, 32 minutes,
use "show chassis fabric fpcs" to determine which PFEs have destination errors
However, for JUNOS Release 9.3 and 9.5, the command only displays the message destination errors or no destination errors for a SIB that is in the Check state, but does not display the number of destination errors:
user@host> show chassis sibs
Slot State 0 Empty 1 Empty 2 Check (destination errors) 55 seconds 3 Check (no destination errors) 45 seconds 4 Empty
Uptime
1 day, 1 hour, 32 minutes, 1 day, 1 hour, 32 minutes,
use "show chassis fabric fpcs" for more details
In addition, the command also displays a message to use the show chassis fabric fpcs command for more information about the destination errors.
45
If there are no SIBs in the Check state, there is no change in the output of this command. [System Basics Command Reference]
MPLS Applications
MPLS statistics file now optionalThe file statement configured at the [edit protocols mpls statistics] hierarchy level is now optional. You still must configure the MPLS statistics statement to collect LSP statistics for the MPLS MIBs. Rather than accessing the LSP statistics in the MPLS statistics file, you can view the statistics using SNMP instead. This change helps to reduce disk space usage on the routing engine, especially on routers on which numerous LSPs have been configured. [MPLS]
NSR tracing flags for MPLSYou can now configure MPLS tracing flags for nonstop active routing (NSR) synchronization events. This enables you to track the progress of NSR synchronization between Routing Engines and record these operations to a log file. To configure, include the flag nsr-synchronization or flag nsr-synchronization-detail statement at the [edit protocols mpls traceoptions] hierarchy level. The two statements are not mutually exclusive; you can track the events at a high level and in detail. [High Availability, MPLS, Routing Protocols]
Multiplay
Border gateway function (BGF) improved efficiency and scalability through use of service interface poolsYou can now use service interface pools to improve the maintainability and scalability of your service set configurations. When your service sets handle VPN traffic, you must specify a service interface pool for the next next-hop-service for the service sets. The interfaces that are members of the pool can serve as either inside or outside interfaces. You should also specify service interface pools as the next-hop service for service sets that do not currently handle VPN traffic. You gain the immediate benefit of more efficient resource utilization and you can add VPNs to the service set in the future without reconfiguring your service sets. [Multiplay Solutions]
Routing Policy and Firewall Filters
The ipsec-sa sa-name firewall filter action is no longer supported on the MX Series routers. To configure one or more actions for a firewall filter, include the actions statement at the [edit firewall family family-name filter filter-name term term-name then] hierarchy level. [Policy]
Enhanced match-conditions support for VPLS and bridge firewall filters (MX Series routers and routers with Enhanced IQ2 [IQ2E] PICs only)The protocol families vpls and bridge now support the interface-set match condition for firewall
46
filters. To configure, include the interface-set interface-set-name statement at the [edit firewall family bridge filter filter-name term term-name from] or the [edit firewall family vpls filter filter-name term term-name from] hierarchy level. The protocol family bridge is supported only on MX Series routers. An interface set is a set of logical interfaces used to configure hierarchical class-ofservice schedulers. Previously only the following protocol families supported the interface-set match condition: ipv4, ipv6, any, and mpls. [Policy]
Routing Protocols
OSPF sham linkAn OSPF sham link is now installed in the routing table as a hidden route. Previously, an OSPF sham link was not installed in the routing table. In addition, a BGP route is no longer exported to OSPF if a corresponding OSPF sham link is available. To configure a sham link, include the sham-link local ip-address statement at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level. [Routing Protocols]
Removal of BGP warning messageIf a BGP group is created without any defined peers, the warning message no longer appears when the configuration is committed. [Routing Protocols]
Increase in limit to external paths accepted for BGP route target filteringYou can now specify for BGP to accept up to 256 external paths for route target filtering. Previously, the maximum number that you could configure was 16. The default value remains one (1). To specify the maximum number of external paths for BGP to accept for route target filtering, include the external-paths number statement at the [edit protocols bgp family route-target] hierarchy level. This statement is also supported for BGP groups and neighbors. [Routing Protocols]
Support for having the algorithm that determines the single best path evaluate AS numbers in AS paths for VPN routesBy 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]
47
Option to view APPID countersUse the option under show services application-identification counter to view the APPID counters for the specified interface. [System Basics and Services Command Reference]
Session offloading on Multiservices PICsTo enable session offloading on a per-PIC basis for Multiservices PICs, include the session-offload statement at the [edit chassis fpc] hierarchy level. [System Basics]
Option to clear the do not fragment bitTo clear the do not fragment bit for IPsec with dynamic endpoints, include the clear-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level. [Services Interfaces]
Option to clear tunnel MTUTo clear the tunnel MTU, include the tunnel-mtu statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level. [Services Interfaces]
M120 router performance with IDPFor M120 routers, the performance number is 4500 connections per second when IDP is enabled. [Services Interfaces]
Enhancement to the output of the show services accounting commandsThe output for the show services accounting usage, show services accounting status, show services accounting memory, and show services accounting errors operational mode commands has been updated to include new fields for use in querying service PICs. [System Basics and Services Command Reference]
Default idle timeout value for UDP- and TCP-based applicationsUpon identification by AppID, the default idle timeout value is set to 30 seconds for UDP-based applications and 1 hour for TCP-based applications. These settings can be overridden by including the idle timeout statement at the [edit services application-identification application application] hierarchy level. [Services Interfaces]
New statement to bypass traffic on exceeding flow limitIf the flow in the service-set crosses the maximum limit set by the max-flow statement, the bypass-traffic-on-exceeding-flow-limits allows the packets to bypass without creating a new session. Following is the required privilege levels:

interface To view the statement in the configuration interface-control To add the statement to the configuration
[Services Interfaces]
Diffie-Hellman group5 added to group1 and group2The group5 designation specifies that IKE should use the 1536-bit Diffie-Hellman prime modulus group
48
when performing the new Diffie-Hellman exchange. To configure the Diffie-Hellman group for an IKE proposal, include the dh-group statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:
[edit services ipsec-vpn ike proposal proposal-name] dh-group (group1 | group2| group5);
[Services Interfaces]
Permanent Limitation for session-timeout on APPID If session-timeout is configured for an APPID application, a session for that application will be cleared once the session-timeout expires. Once the same session is re-created as a new session, it will not be identified by APPID. [Services Interfaces]
Integrated multi-services gateway (IMSG)The clear services border-signaling-gateway gateway-name statistics command no longer clears the active calls counter. [System Basics and Services Command Reference]
New configuration statements for assigning policiesThe following configuration statements at the [edit services border-signaling-gateway gateway-name service-point service-point-name service-policies] hierarchy level have been deprecated and replaced by new statements:

new-call-usage-policies [policy-and-policy-set-names] new-transaction-policies [policy-and-policy-set-names]
Each statement applied policies to calls or transactions entering at the service point. Each is replaced by statements that explicitly apply policies to transactions or policies entering the service point or exiting from the service point. The new statements are:

new-call-usage-input-policies [policy-and-policy-set-names] new-call-usage-output-policies [policy-and-policy-set-names] new-transaction-input-policies [policy-and-policy-set-names] new-transaction-output-policies [policy-and-policy-set-names]
[Services Interfaces, System Basics and Services Command Reference]
Requirement for client-to-servicer and server-to-client signaturesFor certain applications that have signatures for both client-to-server and server-to-client directions, APPID (DAA) needs to see the data packets in both directions on the same session to finish the identification process. For example, for SIP proxy calls, the server may not send the response on the same session (different destination port) and that session will not be identified as application junos:sip. [Services Interfaces]
49
Enabling and disabling DHCP snooping supportYou 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 accountingWhen 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 0No 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]
Restriction on the usage of the annotate command in the configuration hierarchyThe JUNOS Software supports annotation of the configuration using the annotate command up to the last level in the configuration hierarchy. However, annotation of the configuration options or statements within the last level in the hierarchy is not supported. For example, in the following sample configuration hierarchy, annotation is supported up to the level 1 parent hierarchy, but is not supported for the metric child statement:
[edit protocols] isis { interface ge-0/0/0.0 { level 1 metric 10; } } }
50
[CLI User Guide]
Support for accounting is restricted to events and operations on a master Routing EngineStarting with JUNOS Release 9.3, accounting for backup Routing Engine events or operations is not supported on accounting servers such as TACACS+ or RADIUS. Accounting is only supported for events or operations on a master Routing Engine. [CLI User Guide]
Options added to the show arp commandThe vpn and logical-system options have been added to the show arp command. [System Basics Command Reference]
Change in range of the saved-core-files configuration statementThe range of the saved-core-files configuration statement at the [edit system] hierarchy level has been revised from 1 through 64, to 1 through 10 [System Basics Configuration Guide]
VPNs
Mirroring IRB packets as Layer 2 packets (MX Series router)If you associate an IRB with the bridge domain (or VPLS routing instance), and also configure within the bridge domain (or VPLS routing instance) a forwarding table filter with the port-mirror or port-mirror-instance action, then the IRB packet is mirrored as a Layer 2 packet. You can disable this behavior by configuring the no-irb-layer-2-copy statement in the bridge domain (or VPLS routing instance). [MX Series Layer 2 Configuration]
Layer 2 circuits, call admission control (CAC), and bypass LSPsYou can now configure CAC on Layer 2 circuit-based LSPs with bandwidth constraints and also enable link and node protection. However, if the primary LSP fails, CAC might not be applied to the bypass LSP, meaning that the bypass LSP might not meet the bandwidth constraint for the Layer 2 circuit. To minimize the risk of losing traffic, the Layer 2 circuit continues to use the non-CAC bypass LSP while an attempt is made to establish a new Layer 2 circuit route over an LSP that does support CAC. Previously, the Layer 2 circuit route was deleted if the bypass LSP did not have sufficient bandwidth. [VPNs]
Service VLANs and the use of vlan-id all statement in a VPLS routing instanceIf you configure the vlan-id all statement in a VPLS routing instance, we recommend using the input-vlan-map pop and output-vlan-map push statements on the logical interface to pop the service VLAN ID on input and push the service VLAN ID on output and in this way limit the impact of doubly-tagged frames on scaling. [MX Series Layer 2 Configuration]
Layer 2.5 VPNs support ISO family and MPLS family over TCC (MX Series routers)JUNOS Release 8.3 introduced support for M320 and T Series routers. JUNOS Release 10.1 extends support to MX Series routers. Interfaces supporting TCC (Ethernet, extended VLANs, PPP, HDLC, ATM, and Frame Relay) support ISO traffic and MPLS traffic on Layer 2.5 VPNs. Previously,
51
Layer 2.5 VPNs configured on MX Series routers supported only inet traffic. For a protocol to be supported on a Layer 2.5 VPN, you must configure both ends of the VPN with the protocol configuration. IPv6 is not supported. To enable ISO or MPLS traffic over TCC, include the mpls or iso statement at the [edit interfaces interface-name unit logical-unit-number family tcc protocol] hierarchy level. To display which protocol is supported for an interface, issue the show interfaces interface-name extensive operational mode command. The protocol is displayed in the Flags field. To enable ISO over TCC in cases in which the Ethernet interface is on a customer-edge (CE) router, include the point-to-point statement at the [edit protocols isis interface interface-name] hierarchy level on the CE router. When you include this statement, the IS-IS protocol treats the Ethernet interface as point to point, even though the actual interface is a LAN interface. The M Series routing platforms continue to support only inet traffic for Layer 2.5 VPNs. [Network Interfaces, Translational Cross-Connect and Layer 2.5 VPNs Feature Guide, VPNs]
Related Topics
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 6 Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 52 Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers on page 69 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 71
Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
The current software release is Release 10.1R1. For information about obtaining the software packages, see Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 71.

Current Software Release on page 53 Previous Releases on page 64
52
Current Software Release

Outstanding Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
Class of Service
If you try to configure a scheduler map containing two forwarding classes that are mapped to the same queue, the class-of-service scheduler is not applied to the Packet Forwarding Engine. As a workaround, configure a single forwarding class for each available queue. [PR/57907] 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] There is no auto-complete for the show class-of-service scheduler-map command. [PR/469572] There is no auto-complete for the show class-of-service traffic-control-profile command. [PR/469574]
A JUNOS Software compiler bug in the match combination optimization could cause an incorrect firewall filter evaluation. [PR/493356]
High Availability
A problem occurs during graceful Routing Engine switchover (GRES) when a static route pointing to a private interface such as fxp0 is created using the passive retain option. It is recommended to not use the passive option along with the static route on the private interface. [PR/412746] 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]
On aggregated SONET/SDH interfaces, the counter for drops and errors in the show interfaces command output does not display the correct value, because the counter does not collect data from the constituent interfaces within the aggregate interface. [PR/23577] On a 2-port OC12 ATM2 IQ interface, the total virtual path (VP) downtime might not display correctly in the show interfaces command output. [PR/27128]
53
On M20 and M40 routers, when a physical layer problem affects a SONET/SDH interface, carrier transition statistics might not increment correctly in the output of the show interfaces extensive command. [PR/33325] When you configure both the bundle link and constituent links at the [edit
(logical-routers logical-router-name | logical-systems logical-system-name) interfaces]
hierarchy level, the constituent links do not come up. As a workaround, configure the constituent links at the [edit interfaces] hierarchy level. [PR/35578]
When you apply an IPsec firewall filter to match traffic sent across a generic routing encapsulation (GRE) tunnel and originating from the local routing platform, the local traffic is dropped. Transient traffic is not affected. [PR/44871] If you configure IS-IS, MPLS, and graceful Routing Engine switchover (GRES) and a switchover event occurs, the routing platform might end the PPP IP Control Protocol (IPCP) sessions and renegotiate them if the remote side has changed interface MTU settings prior to the switchover event. [PR/61121] If you configure graceful Routing Engine switchover (GRES) and issue the request chassis routing-engine master acquire command, in rare cases the master Routing Engine might fail to relinquish control, or the switchover to the backup Routing Engine might take up to 360 seconds. [PR/61821] 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 1,000,000 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, commit goes through with the message, "Could not retrieve the route-accounting." However, no functionality is affected. [PR/312933]
54
Buffered MAC learning notifications (that have not yet been processed) can cause new MACs to be learned even after traffic is stopped and a clear bridge mac-table command is issued, when software and hardware MAC tables are not in sync. This problem should not occur if the MAC tables in the software and hardware are in sync when the clear command is issued. The clear command can be issued after the software has learned all the MAC entries that are present in the hardware MAC table. [PR/463411]
Under line-rate performance, a few packet drops may occur on the PIC on ingress and egress directions. This is due to clock differences between PIC and the far-end interface. If the far-end interface clock runs slower than the PIC clock, there will be zero drops on the PIC. However, if the far-end interface clock is faster, there will be a few packet drops in the PIC under line-rate conditions. This issue is specific to the 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PICs. [PR/463815] 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 activate the bridge domain or VPLS routing instance configuration. [PR/467549] While PPPoE subscribers are connected to an interface over a dynamic PPPoE VLAN, the JUNOS Software allows you to set the interface to disable and commit the change. This action results in the loss of all subscriber connections. Use care when disabling interfaces. [PR/475111] In some cases during the periodic error status monitoring, error messages such as Wi seg ucode discards in fabric stream may be displayed on adjacent streams. These messages are cosmetic and can be ignored. [PR/481344] The 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PICs may not generate pause frames even when line-rate traffic is sent to its ports. [PR/482142] When services PICs (SP) are bundled using Redundancy Services PIC (RSP) interface hot-standby and if the RSP interface is configured to run on hot-standby mode and if multiple graceful Routing Engine switchovers (GRES) are executed, then the Routing Engine (RE) running as the backup might crash producing a core file. [PR/492127] The ingress filter match does not work when one of the terms in the filter has forwarding-class as a match and discard as an action. This is because the forwarding class match feature for ingress filters attached at the interface unit level is not supported. Behavior aggregate (BA) classification occurs at the unit family level in the packet processing order. [PR/492677] The configured TTL set for GRE traffic is set properly for locally generated Routing Engine packets, but is not set properly for transit packets. There is no workaround. [PR/502087] In JUNOS Release 10.1, if the Neo MPCs power up while the A-DPCs are offline, and if ISSU is performed, the MPCs will crash. [PR/502837] Under certain circumstances, the E3 IQ PIC might report bogus CCV, CES and CSES alarms. [PR/505921]
55
Layer 2 Ethernet Services
On MX960 routers, i2c messages related to the fan such as the following are displayed:
Jan 26 13:32:22 rocky-re0 /kernel: PCF8584(WR): target ack failure on byte 0 Jan 26 13:32:22 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]

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 the per-packet load balancing is configured. [PR/22376] If a circuit cross-connect label-switched path (CCC LSP) traverses a forwarding adjacency LSP, traffic forwarding might be affected. [PR/60088] When you enable per-packet load balancing on parallel label-switched paths (LSPs), the output of the show mpls lsp ingress command might display all the routes on only one of the LSPs even when traffic is evenly balanced across the LSPs. [PR/70487] 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] A rare condition between the MVPN and RSVP P2MP signaling leads to the creation of stale flood next hops. [PR/491586] When a l2circuit uses static LSP as the tunnel between the PEs, and traffic is switched to the ingress bypass LSP, the statistics for both primary LSP and bypass LSP should be updated. But the status are now updated only for the primary LSP. As a workaround, use the set protocols mpls traffic-engineering mpls-forwarding command to update the statistics for both primary and bypass LSP. [PR/495002] An incorrectly changed LDP session authentication key causes the LDP session to fail, which results in the LDP/IGP syncronization feature not working. The IGP continues to advertise the link at normal metric values. [PR/499226]
Platform and Infrastructure
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]
56
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 a Link Services (LS) interface to a CE router appears in the VPN routing and forwarding table (VRF table) and a 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 Periodic Packet Management (PPM) delegation for Bidirectional Forwarding Detection (BFD) sessions is disabled (the delegate-processing statement is removed at the [edit routing-options ppm] hierarchy level), the BFD sessions might be terminated (because a "state is down" message is sent) and reestablished. [PR/280233] 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]
57
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]
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. [PR/436019] 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] In some cases, the alarms displayed in FPM and the alarms shown using the show chassis alarms sfc 0 command mismatch. [PR/445895] The SFC management interface em0 is often displayed as fxp0 in several warning messages. [PR/454074] The VPN label does not get pushed on the label stack for Routing Enginegenerated traffic with l3vpn-composite-next-hop activated. As a workaround, configure per-packet load balancing to push the VPN/tunnel labels correctly. [PR/472707] An invalid IP protocol version is served as a valid version. The JUNOS router forwards IP packets with version field set to values other than 4 and 6, for example, 11 or any (unassigned). [PR/481071] The output of the show arp command does not display the entire demux interface identifier, making it impossible to determine which specific demux sub-interface a given ARP entry is associated with. [PR/482008] During a Routing Engine reboot when processes are being shut down, a rare race condition can lead to a Routing Engine kernel crash. [PR/488484] Swapping out eight FPC cards and replacing them with a different FPC type causes the kernel to crash when the last FPC is powered on. [PR/502075]
58
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] When the flow of multicast traffic changes because an OSPFv3 link goes down, the output from the show multicast statistics inet6 command reports incorrect values in the In kbytes and In packets fields for the new ingress interface. [PR/234969] When you commit a new configuration for nonstop active routing (NSR) on a primary Routing Engine that differs from the configuration for NSR that is already running on the backup Routing Engine, the routing protocol process stops functioning on the backup Routing Engine only. Traffic forwarding is not affected. [PR/254379] 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] 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] When a PIC with a PIM-enabled interface is brought online, the router may 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] During transient periods where both a secondary and primary LSP exist in a routing table, and the number of LSP NHs is greater than 16 in a multigateway scenario, IS-IS may remove the preferred LSP NH. For example, IS-IS could remove an HIPRI LSP. [PR/485748] On MX Series routers, the routing protocol process may crash after an IPv6 routing loop is detected. [PR/490447]
59
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] For Adaptive Services II PICs, even if you do not configure flow collector services, a temporary file might be created every 15 minutes in the /var/log/flowc/ directory. 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] When the Border Signaling Gateway (BSG) configuration contains a policy that has a term with regular expressions, configuration changes might not take effect immediately after the commit process is complete. In most cases, the new policy takes effect immediately. However, complex policies may take longer to take effect depending on how many regular expressions they contain. For example, if you have a term with four regular expressions, configuration changes do not take effect until 50 seconds after you receive the message that the commit process is complete. This behavior occurs whether you have a list or regular expressions (for example, regular-expression [sip:88824.* sip:88821.* sip:88822.sip:88823.*]), or you group regular expressions using the | symbol (for example, "sip:88821.*|sip:88822.*|sip:88823.*|sip:88824.*"). The time taken for the software to apply the configuration changes increases exponentially with the number of regular expressions in your configuration. [PR/448474]
The error message "appid_init_shm: Appid shmem could not be created or already exists. Errno:17" displays during the switchover process even though the graceful Routing Engine switchover (GRES) completes successfully. [PR/457143] 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. [PR/462580] Under some failure scenarios, a switchover of the active BSG from a master to a backup MS-PIC/MS-DPC may take more than two seconds. [PR/467837] The clear services stateful-firewall flows command can cause the MS-DPC to fail. This command should be avoided. There is no workaround. [PR/472386] A performance-related issue may occur when the IDP plug-in is enabled. The connection per second for HTTP (64 bytes) with AACL, AI, and IDP (with Recommended Attacks group) plug-ins has been downgraded to 7.6K through 7.9K per second. [PR/476162] 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]
60
When a standard application is specified under 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] AACL/LLPDF/LPDF do not handle APPID's "best-effort" application determination. [PR/486930] The SIP ALG on the services PIC may cause NAT port leaks in some call scenarios. [PR/491220] In the export version of the JUNOS Software, the signature download does not work for AppID and IDP features in the Dynamic Application Awareness (DAA) suite. In order to resolve this, install the Crypto software suite. [PR/499395]
The revert-interval value configured in the [edit access profile] hierarchy level is ignored. [PR/454040] For a dynamic PPPoE interface in which the subscriber is assigned to a non-default routing-instance (via the LSRI-Name or redirect-LSRI-Name RADIUS VSAs), the IP address assigned to the subscriber must be specified via the framed-ip-address RADIUS attribute. An IP address can not be allocated from a local pool defined in the assigned routing-instance, either when RADIUS returns no address attributes or when the RADIUS framed-pool attribute is returned. [PR/471677] The DHCP clients may not get bound after a filter action under a firewall filter context is deactivated and deleted. [PR/488627] On an MX Series router configured for PPP subscriber access, configuring a large number of PPP subscribers on a single MPC may result in a long boot time for the MPC. Distributing subscribers over multiple MPCs will improve boot times. [PR/490987] Upon a graceful Routing Engine switchover (GRES), forwarding may temporarily stop for PPP sessions under scaling conditions. During this time, the access-internal routes for the subscribers are temporarily not present but are subsequently restored, at which point forwarding resumes. [PR/492022] The destination and destination-profile options for address and unnumbered-address within the family inet and inet6 are allowed to be specified within a dynamic profile, but are not supported. [PR/493279] On an MX Series router configured for PPP subscriber access, subscribers will experience slow login times as the number of subscriber sessions increases. [PR/502756]
Deletion of configuration groups cannot be prevented with the allow-configuration and deny-configuration statements. [PR/59187] Performance is considerably slower for users who have permissions controlled by Juniper-Allow-Commands and/or Juniper-Deny-Commands expressions and have complex regular expressions configured under these same commands. To
61
help avoid this problem, define the expressions in the allow-configuration and deny-configuration commands in a restrictive manner. [PR/63248]
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 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] Users who have superuser privileges will sometimes have their access restricted to view permission only when they log in through TACACS. [PR/388053] The wildcard apply groups do not work properly in JUNOS Release 9.1 and above. [PR/425355] 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] Selecting the monitor port for any port in the Chassis Viewer page displays 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. [PR/455670] J-Web does not display the USB option under Maintain>Reboot>Reboot from the media. [PR/464774] On MX Series routers, J-Web does not display the USB related information under Monitor>SystemView>System Information>Storage. [PR/465147] In the J-Web interface, the options Access Concentrator, Idle Timeout, and Service Name for PPPoE logical interfaces are not supported on MX Series routers. [PR/493451]
62
Commit fails when the commit scripts are used and the configuration contains a policy which uses an apply-group with a then action of 'then community + export.' [PR/501876] The load replace command does not consider the allow-configuration configuration. [PR/501992]
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] Traffic might not flow when an ATM interface is used as the access circuit on an M120 router. [PR/255160] For a VRF instance configured for PIM, MVPN, and provider tunnels (the pim and mvpn statements are included at the [edit routing-instances vpn-name protocols] hierarchy level and the provider-tunnel statement is included at the [edit routing-instances vpn-name] hierarchy level), when PIM is deactivated and reactivated, it fails to install type-5 (source-active) routes in the instance-name.mvpn.0 routing table. This issue arises only when remote c-multicast joins are configured on the ingress PE router (as displayed by the show mvpn c-multicast command). [PR/306983] When you configure inter-AS VPLS with MAC processing at the autonomous system (AS) boundary router along with multihoming, and if a designated forwarding AS boundary router fails and then comes back up again, traffic flowing to the local AS from the other ASs boundary router might be lost. The loss occurs in the time period (tenths of a second) during which the old designated forwarding AS boundary router is taking back the role of designated forwarder. [PR/312730] 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] 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. [PR/493835] In vlan-tagging, stacked-vlan-tagging, and flexible-vlan-tagging modes, untagged packets or mismatching Tag Protocol ID (TPID) packets may be dropped. These dropped packets are not accounted for and are not visible in the CLI. This issue is specific to the 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PICs. [PR/496190]
63
Previous Releases
Release 10.0R2 The following issues have been resolved since JUNOS Release 10.0R2. The identifier following the description is the tracking number in our bug database.
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: This issue has been resolved.]
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. [PR/314855: This issue has been resolved.] When the show interfaces extensive command is used, some interfaces may not display the correct value for the Oversized Frames counter. [PR/437176: This issue has been resolved.] When configured for WAN-PHY framing, the ports on the 4-port 10Gigabit 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.]
64
Interrupts that occur from links (non-zero) that are not configured or enabled in the PIC due to a hardware issue in the DFPGA cause the syslog to overload and eventually cause 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 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 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 are stuck in the disabled state when the TX cable is unplugged and RX cable is 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 issue has been resolved.] 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, the 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 encapsulation. The 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 interface. [PR/484007: 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 the other to be backup.
65
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 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: This issue has been resolved.] Commit fails with IEEE 802.1p config when applied to container interfaces. [PR/489400: This issue has been resolved.] 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. [PR/492197: This issue has been resolved.]
Layer 2 Ethernet Services
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. [PR/477848: This issue has been resolved.]
MPLS Applications
Constrained Shortest Path First (CSPF) fails to calculate a P2MP point-to-multipoint LSP reroute path that is merging with a 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). [PR/485477: This issue has been resolved.]
66
Platform and Infrastructure
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 a load-balancing per-packet policy for all prefixes (per-flow load balancing) and/or do not have aggregate interfaces flap. [PR/477326: This issue has been resolved.]
With JUNOS Release 9.3 or later, configuring policer or SCU/DCU on interfaces belonging to FPC-ES may cause memory corruption, leading to either traffic loss 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, resulting in it running on random data and 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, the Juniper Networks PIM implementation might send (S,G,rpt) prune message towards the RP too early after receiving the (S,G,rpt) prune message from a downstream router. [PR/478589: This issue has been resolved.]
67
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 fails and generates a core file because of malformed BGP update generated by the JUNOS Software. This failure may be due to the total 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 fail and generate a core file. [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 issue has been resolved.]
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 issue has been resolved.] P2MP point-to-multipoint 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.]
68
Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers
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: This issue has been resolved.]
Related Topics
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 6 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 42 Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers on page 69 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 71
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. The new JUNOS Technical Documentation index page (http://www.juniper.net/techpubs/software/junos/index.html ) consolidates documentation for JUNOS Software features that are common to all platforms that run JUNOS Software. The new index page provides direct access to core JUNOS information and links to information for JUNOS features that run on particular platforms.
Errata
This section lists outstanding issues with the documentation.
69
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]
Integrated Multi-Services Gateway (IMSG)
Chapter 15, Maintenance and Failover in the IMSG, describes the IMSG high availability feature. This feature is not supported in this release of the software. [Multiplay Solutions]
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 a IGMP interface is configured 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-versionIGMP 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, System Basics]
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.
70
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
[Subscriber Access]
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]
The Guidelines for Configuring Dynamic CoS for Subscriber Access topic in the Subscriber Access Configuration Guide erroneously states that dynamic CoS is supported for dynamic VLANs on the Trio MPC/MIC family of products. In the current release, dynamic CoS is supported only on static VLANs on Trio MPC/MIC interfaces. [Subscriber Access]
The Subscriber Access Configuration Guide incorrectly describes the authentication-order statement as it is used for subscriber access management. When configuring the authentication-order statement for subscriber access management, you must always specify the radius method. Subscriber access management does not support the password keyword (the default), and authentication fails when you do not specify an authentication method. [Subscriber Access]
The show system statistics bridge command displays system statistics on MX Series routers. [System Basics Command Reference]
Related Topics
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 6 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 42 Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 52 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 71
This section discusses the following topics:

Basic Procedure for Upgrading to Release 10.1 on page 72 Upgrading a Router with Redundant Routing Engines on page 74 Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS Release 10.1 on page 74 Upgrading the Software for a Routing Matrix on page 76
71
Upgrading Using ISSU on page 77 Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both PIM and NSR on page 77 Downgrade from Release 10.1 on page 78
Basic Procedure for Upgrading to Release 10.1

In order to upgrade to JUNOS 10.0 or later, you must be running JUNOS 9.0S2, 9.1S1, 9.2R4, 9.3R3, 9.4R3, 9.5R1, or later minor versions, or you must specify the no-validate option on the request system software install command. 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 Software Installation and Upgrade Guide.
NOTE: You cannot upgrade by more than three releases at a time. For example, if your routing platform is running JUNOS Release 9.4 you can upgrade to JUNOS Release 10.0 but not to JUNOS Release 10.1 As a workaround, first upgrade to JUNOS Release 10.0 and then upgrade to JUNOS Release 10.1.
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 System Basics Configuration Guide.
72
The download and installation process for JUNOS Release 10.1 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. Download the software to a local host. Copy the software to the routing platform or to your internal software distribution site. Install the new jinstall package on the routing platform.
3. 4. 5.
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.1R1.8-domestic-signed.tgz
All other customers use the following command:

user@host> request system software add validate reboot source/jinstall-10.1R1.8-export-signed.tgz
Replace source with one of the following values:
/pathnameFor 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.
73
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.1 Release 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 nonemergency 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.
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. 2. 3.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine and save the configuration change to both Routing Engines. Install the new JUNOS Software release on the backup Routing Engine while keeping the currently running software version on the master Routing Engine. 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. Install the new software on the original master Routing Engine that is now active as the backup Routing Engine.
4.
For the detailed procedure, see the JUNOS Software Installation and Upgrade Guide.
Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS Release 10.1
In releases prior to JUNOS Release 10.1, the draft-rosen multicast VPN feature implements the unicast lo0.x address configured within that instance as the source address used to establish PIM neighbors and create the multicast tunnel. In this mode, the multicast VPN loopback address is used for reverse path forwarding (RPF) route resolution to create the reverse path tree (RPT), or multicast tunnel. The multicast VPN loopback address is also used as the source address in outgoing PIM control messages.
74
In JUNOS Release 10.1 and later, you can use the routers main instance loopback (lo0.0) address (rather than the multicast VPN loopback address) to establish the PIM state for the multicast VPN. We strongly recommend that you perform the following procedure when upgrading to JUNOS Release 10.1 if your draft-rosen multicast VPN network includes both Juniper Network routers and other vendors routers functioning as provider edge (PE) routers. Doing so preserves multicast VPN connectivity throughout the upgrade process. Because JUNOS Release 10.1 supports using the routers main instance loopback (lo0.0) address, it is no longer necessary for the multicast VPN loopback address to match the main instance loopback adddress lo0.0 to maintain interoperability.
NOTE: You might want to maintain a multicast VPN instance lo0.x address to use for protocol peering (such as IBGP sessions), or as a stable router identifier, or to support the PIM bootstrap server function within the VPN instance. Complete the following steps when upgrading routers in your draft-rosen multicast VPN network to JUNOS Release 10.1 if you want to configure the routerss main instance loopback address for draft-rosen multicast VPN:
1.
Upgrade all PE routers to JUNOS Release 10.1 before you configure the loopback address for draft-rosen Multicast VPN.
NOTE: Do not configure the new feature until all the PE routers in the network have been upgraded to JUNOS Release 10.1. After you have upgraded all routers, configure each routers main instance loopback address as the source address for multicast interfaces. Include the default-vpn-source interface-name loopback-interface-name] statement at the [edit protocols pim] hierarchy level. After you have configured the routers main loopback address on each PE router, delete the multicast VPN loopback address (lo0.x) from all routers. We also recommend that you remove the multicast VPN loopback address from all PE routers from other vendors. In JUNOS releases prior to 10.1, to ensure interoperability with other vendors routers in a draft-rosen multicast VPN network, you had to perform additional configuration. Remove that configuration from both the Juniper Networks routers and the other vendors routers. This configuration should be on Juniper Networks routers and on the other vendors routers where you configured the lo0.mvpn address in each VRF instance as the same address as the main loopback (lo0.0) address. This configuration is not required when you upgrade to JUNOS Release 10.1 and use the main loopback address as the source address for multicast interfaces.
2.
3.
NOTE: To maintain a loopback address for a specific instance, configure a loopback address value that does not match the main instance address (lo0.0).
75
For more information about configuring the draft-rosen Multicast VPN feature, see the JUNOS Multicast Configuration 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 conditions 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 be 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.
76
To upgrade the software for a routing matrix, perform the following steps:
1. 2.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine (re0) and save the configuration change to both Routing Engines. 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). 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. Install the new software on the new backup Routing Engine (re0).
3.
4.
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 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 Release 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
77
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 PIMsimply 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. 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
3.
Downgrade from Release 10.1

To downgrade from Release 10.1 to another supported release, follow the procedure for upgrading, but replace the 10.1 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 Software Installation and Upgrade Guide.
78
Related Topics
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 6 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 42 Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on page 52 Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers on page 69
79
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.1 for SRX Series Services Gateways and J Series Services Routers on page 80 Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 93 Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 102 Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 112 Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 140 Hardware Requirements for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 147 Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways on page 149 Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing Engine on page 158 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 160
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
The following features have been added to JUNOS Release 10.1. Following the description is the title of the manual or manuals to consult for further information.

Software Features on page 81 Hardware Features on page 92
80
JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways and J Series Services Routers
Software Features
Application Layer Gateways (ALGs)
DNS ALGThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, SRX650. JUNOS Software for SRX Series devices provides Domain Name System (DNS) support. The DNS ALG monitors DNS query and reply packets and closes the session if the DNS flag indicates that the packet is a reply message. To configure the DNS ALG, use the edit security alg dns statement at the [edit security alg] hierarchy level. [JUNOS Software Security Configuration Guide]
DNS doctoring supportThis feature is supported on all SRX Series and J Series devices. Domain Name System (DNS) ALG functionality has been extended to support static NAT. You should configure static NAT for the DNS server first. Then if the DNS ALG is enabled, public-to-private and private-to-public static address translation can occur for A-records in DNS replies. The DNS ALG also now includes a maximum-message-length command option with a value range of 512 to 8192 bytes and a default value of 512 bytes. The DNS ALG will now drop traffic if the DNS message length exceeds the configured maximum, if the domain name is more than 255 bytes, or if the label length is more than 63 bytes. The ALG will also decompress domain name compression pointers and retrieve their related full domain names, and check for the existence of compression pointer loops and drop the traffic if one exists. Note that the DNS ALG can translate the first 32 A-records in a single DNS reply. A-records after the first 32 will not be handled. Also note that the DNS ALG supports only IPv4 addresses and does not support VPN tunnels. [JUNOS Software Security Configuration Guide]
MS RPC ALGThis 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. The Microsoft RPC (MS RPC) provides a way for a program running on one host to call procedures in a program running on another host. Because of the large number of RPC services and the need to broadcast, the transport address of an RPC service is dynamically negotiated based on the service program's Universal Unique IDentifier (UUID). The specific UUID is mapped to a transport address. JUNOS Software supports MS RPC as a predefined service to allow and deny traffic based on a policy you configure. The MS RPC ALG provides the functionality for all supported devices to handle the dynamic transport address negotiation mechanism of the MS RPC and to ensure UUID-based security policy enforcement. You can define a security policy to permit or deny all RPC requests or to permit or deny by specific UUID number. The ALG also supports route and NAT mode for incoming and outgoing requests. [JUNOS Software Security Configuration Guide]
81
SQL ALGThis feature is now supported on SRX3400, SRX3600, and SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, SRX650, and J Series devices. Enabling the Structured Query Language (SQL) ALG on an SRX Series or J Series device allows SQL*Net traffic in SQL redirect mode to traverse an SRX Series device by creating a TCP pinhole. If the the SQL*Net traffic is not in redirect mode, it will not be handled by the SQL ALG and will instead be processed by configured firewall policies. SQL*Net is a proprietary protocol used by Oracle databases for data access and sharing over networks. Note that the SQL ALG only supports IPv4 addresses as of JUNOS Release 10.1. [JUNOS Software Security Configuration Guide]
Sun RPC ALGThis feature is now supported on SRX3400, SRX3600, SRX5600, and SRX5800 line devices in addition to existing support on SRX100, SRX210, SRX240, SRX650, and J Series devices. Sun Microsystems RPC provides a way for a program running on one host to call procedures in a program running on another host. Because of the large number of RPC services and the need to broadcast, the transport address of an RPC service is dynamically negotiated based on the service's program number and version number. Several binding protocols are defined for mapping the RPC program number and version number to a transport address. JUNOS Software supports the Sun RPC as a predefined service to allow and deny traffic based on a security policy you configure. The Sun RPC ALG provides the functionality for all supported devices to handle the dynamic transport address negotiation mechanism of the Sun RPC and to ensure program number-based security policy enforcement. You can define a security policy to permit or deny all RPC requests or to permit or deny by specific program number. The ALG also supports route and NAT mode for incoming and outgoing requests. [JUNOS Software Security Configuration Guide]
Chassis Cluster
Interface link aggregation in redundant Ethernet interfacesThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 device chassis clusters. Link aggregation groups (LAGs) can now be established across nodes in a chassis cluster. In JUNOS Release 10.1, support for LAGs based on IEEE 802.3ad made it possible to aggregate physical interface links on a standalone device. LAGs provide increased interface bandwidth and link availability by linking physical ports and load-balancing traffic crossing the combined interface. In JUNOS Release 10.1, link aggregation has been extended to chassis cluster configuration allowing a redundant Ethernet interface (known as a reth interface in CLI commands) to add multiple child interfaces from both nodes and thereby create a redundant Ethernet interface link aggregation group. Other than adding more child interfaces (up to a maximum of 16; 8 per node) to a redundant Ethernet interface, no other configuration on an SRX Series device beyond the more general chassis cluster, redundancy group, and redundant Ethernet interface configuration is necessary to use this feature. It is necessary, however, for the switch used to connect the links from both nodes in the cluster
82
to have a LAG link configured and 802.3ad enabled for each redundant Ethernet interface LAG on both nodes so that the aggregate links will be recognized. Standalone link aggregation group interfaces (ae) are supported on clustered devices but cannot be added to redundant Ethernet interfaces. Likewise any child interface of an existing LAG cannot be added to a redundant Ethernet interface and vice versa. The maximum number of total combined standalone aggregate interfaces (ae) and redundant Ethernet interfaces (reth) per cluster is 128. Redundant Ethernet interface configuration also includes a minimum-links setting that allows you to set a minimum number of physical child links in a redundant Ethernet interface LAG that must be working on the primary node for the interface to be up. The default minimum-links value is 1. When the number of physical links on the primary node in a redundant Ethernet interface falls below the minimum-links value, the interface will be down even if some links are still working. Note that management, control, and fabric interfaces do not support standalone LAGs or redundant Ethernet interface LAGs in JUNOS Release 10.1. [JUNOS Software Security Configuration Guide]
Redundancy group IP address monitoring through a secondary interfaceThis feature is supported on SRX3400, SRX3600, SRX5600 and SRX5800 devices. In JUNOS Release 10.1, redundancy group IP address monitoring through a redundant Ethernet (reth) interface has been extended to include monitoring of addresses on secondary links as well as on primary links. Redundancy group failover can thus be tied to the health of both any IP addresses that are currently important to traffic reliability and to any IP addresses that will become important to traffic reliability in the event of a failover. Monitoring can be accomplished only if the IP address is reachable on a redundant Ethernet interface, and IP addresses cannot be monitored over a tunnel. IP address monitoring is not supported on redundant Ethernet interface LAGs or the child interfaces bound to a redundant Ethernet interface LAG. The feature also cannot be used on a cluster running in transparent mode. The maximum number of total monitoring IPs that can be configured per cluster remains 32 for SRX3400 and SRX3600 devices, and 64 for SRX5600 and SRX5800 devices. [JUNOS Software Security Configuration Guide]
83
Integrated Convergence Services
DSCP marking for RTP packets generated by SRX Series Integrated Convergence ServicesThis feature is supported on SRX210 and SRX240 devices that have high memory, power over Ethernet capability, and media gateway capability. Configure DSCP marking to set the desired DSCP bits for RTP packets generated by SRX Series Integrated Convergence Services. DSCP bits are the 6-bit bitmap in the IP header used by devices to decide the forwarding priority of packet routing. When the DSCP bits of RTP packets generated by Integrated Convergence Services are configured, the downstream device can then classify the RTP packets and direct them to a higher priority queue in order to achieve better voice quality when packet traffic is congested. Juniper Networks devices provide classification, priority queuing, and other kinds of CoS configuration under the Class-of-Service configuration hierarchy. Note that the Integrated Convergence Services DSCP marking feature marks only RTP packets of calls that it terminates, which include calls to peer call servers and to peer proxy servers that provide SIP trunks. If a call is not terminated by Integrated Convergence Services, then DSCP marking does not apply. To configure the DSCP marking bitmap for calls terminated by Integrated Convergence Services and the address of the peer call server or peer proxy server to which these calls are routed, use the media-policy statement in the [edit services converged-services] hierarchy level.
set services convergence-service service-class < name > dscp < bitmap > set services convergence-service service-class media-policy < name > term < term-name > from peer-address [< addresses >] set services convergence-service service-class media-policy < name > term then service-class < name >
Intrusion Detection and Prevention (IDP)
IDP in an active/active chassis clusterThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. Intrusion Detection and Prevention (IDP) can now monitor traffic on active/active chassis clusters. As in active/passive clusters, sessions already in progress that fail over or fail back are not inspected by IDP in an active/active cluster. New sessions created after a failover will, however, be inspected by IDP. There are no changes to IDP deployment or logging as a result of extending support to active/active high-end device clusters. IDP also now supports chassis cluster in-service software upgrades (ISSUs), which means that new sessions will continue to be inspected during the ISSU. However, because ISSU requires the nodes to fail over and fail back as the upgrade proceeds, IDP monitoring of any sessions that fail over will cease. It should not be necessary to restart IDP once the ISSU is completed. Note that IDP ISSU support is available on both active/passive and active/active chassis clusters. [JUNOS Software Security Configuration Guide]
IDP application identification enhancement for extended applications with
84
threat prevention supportThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. With the increased use of application protocol encapsulation, the need arises to support the identification of multiple different applications running on the same Layer 7 protocols. In order to do this, the current application identification layer is split into two layers: application and protocol. New extended application signatures have been added to identify these extended applications. [JUNOS Software Security Configuration Guide]
CLI enhancements supported for J-WebThis feature is supported on SRX Series and J Series devices. Additional functionality has been added to existing IDP J-Web pages for several new CLI commands that perform tasks such as the following: list detailed security download status information, list subscriber policies, add additional IDP packet counters to differentiate a packet drop that is the result of a policy from a legitimate drop or an error drop. There are several more newly added commands. [JUNOS CLI Reference Guide]
SNMP MIB for IDP MonitoringThis feature is now supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, and SRX650 devices. [JUNOS Software Security Configuration Guide]
Application-level DDoS loggingThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices with IDP enabled. IDP now provides logging for application-level DDoS events. IDP generates three types of application-level DDoS event logs: attack, state transition, and ip-action. These event logs provide visibility into the application-level DDoS state and provide notifications on occurrences of application-level DDoS attacks for each protected application server. [JUNOS Software Security Configuration Guide, JUNOS Software CLI Reference]
Interfaces and Routing
DOCSIS Mini-PIM InterfaceData over Cable Service Interface Specification (DOCSIS) defines the communications and operation support interface requirements for a data-over-cable system. It is used by cable operators to provide Internet access over their existing cable infrastructure for both residential and business customers. DOCSIS 3.0 is the latest Interface standard allowing channel bonding to deliver speeds higher than 100 Mbps throughput in either direction, far surpassing other WAN technologies such as T1/E1, ADSL2+, ISDN, and DS3. DOCSIS network architecture includes a cable modem on SRX Series Services Gateways with a DOCSIS Mini-Physical Interface Module (Mini-PIM) located at customer premises, and a Cable Modem Termination System (CMTS) located at the head-end or data center locations. Standards-based DOCSIS 3.0 Mini-PIM is interoperable with CMTS equipment. The DOCSIS Mini-PIM provides backward compatibility with CMTS equipment based on the following standards:

DOCSIS 2.0 DOCSIS 1.1
85
DOCSIS 1.0
The DOCSIS Mini-PIM is supported on the following SRX Series Services Gateways:

SRX210 SRX240 The DOCSIS Mini-PIM has the following key features:

Provides high data transfer rates of over 150 Mbps downstream Supports four downstream and four upstream channel bonding Supports quality of service (QoS) Provides interoperability with any DOCSIS-compliant cable modem termination system (CMTS) Supports IPv6 and IPv4 for modem management interfaces Supports Baseline Privacy Interface Plus (BPI+) Supports Advanced Encryption Standard (AES)
[JUNOS Software Security Configuration Guide]
Very-high-bit-rate digital subscriber line (VDSL)VDSL technology is part of the xDSL family of modem technologies that provide faster data transmission over a single flat untwisted or twisted pair of copper wires. The VDSL lines connect service provider networks and customer sites to provide high bandwidth applications (Triple Play services) such as high-speed Internet access, telephone services like voice over IP (VoIP), high-definition TV (HDTV), and interactive gaming services over a single connection. VDSL2 is an enhancement to VDSL and permits the transmission of asymmetric and symmetric (full-duplex) aggregate data rates up to 100 Mbps on short copper loops using a bandwidth up to 30 MHz. The VDSL2 technology is based on the ITU-T G.993.2 standard. The following SRX Series Services Gateways support the VDSL2 Mini-Physical Interface Module (Mini-PIM) (Annex A):

SRX210 Services Gateway SRX240 Services Gateway
The VDSL2 Mini-PIM carries the Ethernet backplane. When the Mini-PIM is plugged into the chassis, the Mini-PIM connects to one of the ports of the baseboard switch. The VDSL2 Mini-PIM supports following features:
ADSL/ADSL2/ADSL2+ backward compatibility with Annex-A, Annex-M Support PTM or EFM [802.3ah] support Operation, Administration, and Maintenance (OAM) support for ADSL/ADSL/ADSL2+ ATM mode
86
ATM QoS (supported only when the VDSL2 Mini-PIM is operating in ADSL2 mode) MLPPP (supported only when the VDSL2 Mini-PIM is operating in ADSL2 mode) MTU size of 1500 bytes (maximum) Support for maximum of 10 PVCs (only in ADSL/ADSL2/ADSL2+ mode) Dying gasp support (ADSL and VDSL2 mode)
Online insertion and removal (hot swap) for SRX650 GPIMsOnline insertion and removal (OIR) functionality is supported on CPU-based and CPU-less Gigabit-Backplane Physical Interface Modules (GPIMs). You can remove or insert a GPIM without powering off the device. The following GPIMs are supported on SRX650 devices:

24-port Ethernet GPIM (with and without PoE) 16-port Ethernet GPIM (with and without PoE) 2-port and 4-port CT1/E1 GPIM
Implement the PPPoE-based radio-to-router protocolThis feature is supported on SRX Series and J Series devices. JUNOS Release 10.1 supports PPPoE-based radio-to-router protocols. These protocols include messages that define how an external device provides the router with timely information about the quality of a link's connection. There is also a flow control mechanism to indicate how much data the device can forward. The device can then use the information provided in the PPPoE messages to dynamically adjust the interface speed of the PPP links. Use the radio-router statement from the [set interfaces <unit>] hierarchy to indicate that metrics announcements received on the interface will be processed by the device.
Class of service (CoS) for devices operating in transparent modeThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. SRX3400, SRX3600, SRX5600, and SRX5800 devices operating in Layer 2 transparent mode support the following CoS functions:
IEEE 802.1p behavior aggregate (BA) classifiers to determine the forwarding treatment for packets entering the device Note that only IEEE 802.1p BA classifier types are supported on devices operating in transparent mode.
Rewrite rules to redefine IEEE 802.1 CoS values in outgoing packets Note that rewrite rules that redefine IP precedence CoS values and Differentiated Services Code Point (DSCP) CoS values are not supported on devices operating in transparent mode.
Shapers to apply rate limiting to an interface Schedulers that define the properties of an output queue
You configure BA classifiers and rewrite rules on transparent mode devices in the same way as on devices operating in Layer 3 mode. For transparent mode
87
devices, however, you apply BA classifiers and rewrite rules only to logical interfaces configured with the family bridge configuration statement. You configure shapers and schedulers on transparent mode devices in the same way as on devices operating in Layer 3 mode. [JUNOS Software Interfaces and Routing Configuration Guide]
Layer 2 Q-in-Q tunnelingThis feature is supported on SRX210, SRX240, SRX650, and J Series devices. Q-in-Q tunneling, defined by the IEEE 802.1ad standard, allows service providers on Ethernet access networks to extend a Layer 2 Ethernet connection between two customer sites. In Q-in-Q tunneling, as a packet travels from a customer VLAN (C-VLAN) to a service provider's VLAN, a service provider-specific 802.1Q tag is added to the packet. This additional tag is used to segregate traffic into service-provider-defined service VLANs (S-VLANs). The original customer 802.1Q tag of the packet remains and is transmitted transparently, passing through the service provider's network. As the packet leaves the S-VLAN in the downstream direction, the extra 802.1Q tag is removed. There are three ways to map C-VLANs to an S-VLAN:
All-in-one bundlingUse the dot1q-tunneling statement at the [edit vlans] hierarchy to map without specifying customer VLANs. All packets from a specific access interface are mapped to the S-VLAN. Many-to-one bundlingUse the customer-vlans statement at the [edit vlans] hierarchy to specify which C-VLANs are mapped to the S-VLAN. Mapping C-VLAN on a specific interfaceUse the mapping statement at the [edit vlans] hierarchy to map a specific C-VLAN on a specified access interface to the S-VLAN.
Table 3 on page 88 lists the C-VLAN to S-VLAN mapping supported on SRX Series and J Series devices.
Table 3: C-VLAN to S-VLAN Mapping Supported on SRX Series and J Series Devices
Mapping All-in-one bundling Many-to-one bundling Mapping C-VLAN on a specific interface SRX210 Yes No No SRX240 Yes No No SRX650 Yes Yes Yes J Series (PIM) Yes No No
Integrated bridging and routing (IRB) interfaces are supported on Q-in-Q VLANs for SRX210, SRX240, SRX650, and J Series devices. Packets arriving on an IRB interface on a Q-in-Q VLAN are routed regardless of whether the packet is single or double tagged. The outgoing routed packets contain an S-VLAN tag only when exiting a trunk interface; the packets exit the interface untagged when exiting an access interface.
88
In a Q-in-Q deployment, customer packets from downstream interfaces are transported without any changes to source and destination MAC addresses. You can disable MAC address learning at both the interface level and the VLAN level. Disabling MAC address learning on an interface disables learning for all the VLANs of which that interface is a member. When you disable MAC address learning on a VLAN, MAC addresses that have already been learned are flushed. [JUNOS Software Interfaces and Routing Configuration Guide]
Layer 2 Link Layer Discovery Protocol (LLDP) and Link Layer Discovery ProtocolMedia Endpoint Discovery (LLDP-MED)This feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices. Devices use LLDP and LLDP-MED to learn and distribute device information on network links. The information allows the device to quickly identify a variety of systems, resulting in a LAN that interoperates smoothly and efficiently. LLDP-capable devices transmit information in Type Length Value (TLV) messages to neighbor devices. Device information can include specifics, such as chassis and port identification and system name and system capabilities. The TLVs leverage this information from parameters that have already been configured in the Juniper Networks JUNOS Software. LLDP-MED goes one step further, exchanging IP-telephony messages between the device and the IP telephone. These TLV messages provide detailed information on PoE policy. The PoE Management TLVs let the device ports advertise the power level and power priority needed. For example, the device can compare the power needed by an IP telephone running on a PoE interface with available resources. If the device cannot meet the resources required by the IP telephone, the device could negotiate with the telephone until a compromise on power is reached. LLDP and LLDP-MED must be explicitly configured on uPIMs (in enhanced switching mode) on J Series devices, base ports on SRX100, SRX210, and SRX240 devices, and Gigabit-Backplane Physical Interface Modules (GPIMs) on SRX650 devices. To configure LLDP on all interfaces or on a specific interface, use the lldp statement at the [set protocols] hierarchy. To configure LLDP-MED on all interfaces or on a specific interface, use the lldp-med statement at the [set protocols] hierarchy. [JUNOS Software Interfaces and Routing Configuration Guide]
Promiscuous modeThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. When promiscuous mode is enabled on a Layer 3 Ethernet interface, all packets received on the interface are sent to the CP/SPU regardless of the destination MAC address of the packet. You can also enable promiscuous mode on chassis cluster redundant Ethernet interfaces and aggregated Ethernet interfaces. If you enable promiscuous mode on a redundant Ethernet interface, promiscuous mode is then enabled on any child physical interfaces. If you enable promiscuous mode on an aggregated Ethernet interface, promiscuous mode is then enabled on all member interfaces. To enable promiscuous mode on an interface, use the promiscuous-mode statement at the [edit interfaces] hierarchy. [JUNOS Software Interfaces and Routing Configuration Guide]
89
Network Address Translation (NAT)
Increased maximum number of source NAT rules supportedThis feature is supported on SRX Series and J Series devices. JUNOS Release 10.1 increases the number of source NAT rules and rule sets that you can configure on a device. In previous releases, the maximum number of source NAT rule sets you could configure on a device was 32 and the maximum number of rules in a source NAT rule set was 8. JUNOS Release 10.1, the maximum number of source NAT rules that you can configure on a device are:

512 for J Series, SRX100, and SRX210 devices 1024 for SRX240 and SRX650 devices 8192 for SRX3400, SRX3600, SRX5600, and SRX5800 devices
These are systemwide maximums for total numbers of source NAT rules. There is no limitation on the number of rules that you can configure in a source NAT rule set as long as the maximum number of source NAT rules allowed on the device is not exceeded.
NOTE: This features does not change the maximum number of rules and rule sets you can configure on a device for static and destination NAT. For static NAT, you can configure up to 32 rule sets and up to 256 rules per rule set. For destination NAT, you can configure up to 32 rule sets and up to 8 rules per rule set.
PPPoE
LN1000 Mobile Secure RouterThis feature is supported on J2320, J6350, and SRX650 devices. To support the credit-based flow control extensions described in [RFC4938], PPPoE peers can now grant each other forwarding credits. The grantee can forward traffic to the peer only when it has a sufficient number of credits to do so. When credit-based forwarding is used on both sides of the session, the radio client can control the flow of traffic by limiting the number of credits it grants to the router. The interfaces statement includes a new radio-router attribute that replaces the resource-component-variables attribute. The radio-router attribute contains the parameters used for rate-based scheduling and OSPF link cost calculations. It also includes a new credit attribute to indicate that credit-based packet scheduling is supported on the PPPoE interfaces that reference this underlying interface. Interfaces that set the encapsulation attribute support the PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery Credit (PADC) messages in the same way that the attribute provides active support for the PPPoE Active Discovery Quality (PADQ) message.
90
The credit interval parameter controls how frequently the router generates credit announcement messages. For PPPoE this corresponds to the interval between PADG credit announcements for each session. For example:
[edit interfaces ge-0/0/1] unit 0 { encapsulation ppp-over-ether; radio-router { credit { interval 10; } bandwidth 80; threshold 5; } }
NOTE: The resource-component-variables attribute has been deprecated, but has an alias to the radio-router variable to minimize impact on existing routers that may have been configured previously. To display PPPoE credit-flow information:
user@host> show pppoe interface detail
pp0.51 Index 73 State: Session up, Session ID: 3, Service name: None, Configured AC name: None, Session AC name: None, Remote MAC address: 00:22:83:84:2e:81, Session uptime: 00:05:48 ago, Auto-reconnect timeout: Never, Idle timeout: Never, Underlying interface: ge-0/0/4.1 Index 72 PADG Credits: Local: 12345, Remote: 6789, Scale factor: 128 bytes PADQ Current bandwidth: 750 Kbps, Maximum 1000 Kbps Quality: 85, Resources 65, Latency 100 msec. Dynamic bandwidth: 3 Kbps pp0.1000 Index 71 State: Down, Session ID: 1, Service name: None, Configured AC name: None, Session AC name: None, Remote MAC address: 00:00:00:00:00:00, Auto-reconnect timeout: Never, Idle timeout: Never, Underlying interface: ge-0/0/1.0 Index 70 PADG Credits: enabled Dynamic bandwidth: enabled
91
Virtual LANs (VLANs)
Flexible Ethernet servicesThis feature is supported on SRX210, SRX240, SRX650, and J Series devices. Use flexible Ethernet services encapsulation when you want to configure multiple per-unit Ethernet encapsulations. This encapsulation type allows you to configure any combination of route, TCC, CCC, and VPLS encapsulations on a single physical port. Aggregated Ethernet bundles cannot use this encapsulation type. For ports configured with flexible Ethernet services encapsulation, VLAN IDs from 1 through 511 are no longer reserved for normal VLANs.
VPNs
Increased maximum number of VPN tunnels supportedThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. VPN supports a maximum of 10000 site-to-site VPN tunnels.
WLAN
AX411 Access Point clusteringThe AX411 Access Point is a Layer 2 device that connects wireless communication devices together to create a wireless network. The access point is connected to the wired network and relays data between the wired and the wireless network. Multiple access points form a part of a bigger wireless network and can be clustered together. The access point cluster is a dynamic, configuration-aware group of access points in the same subnet of a network. A cluster can have up to sixteen member access points. Clusters can share various configuration information such as virtual access point (VAP) settings and quality-of-service (QoS) queue parameters. Any change in configuration on one access point will propagate to all other access points in the cluster. Similarly, any new access point introduced to the cluster will adopt the configuration of other access points in the cluster. Access points are supported on the following SRX Series Services Gateways:

SRX210 SRX240 SRX650
[JUNOS Software WLAN Configuration and Administration Guide]
Hardware Features
Support for 3G wireless functionality on SRX210 Services GatewaysJUNOS Software Release 10.1 supports 3G wireless functionality on SRX210 devices to provide to provide wireless WAN connectivity as backup to primary WAN links. Third-generation (3G) networks are wide area cellular telephone networks that have evolved to include high-data rate services of up to 3 Mbps. The SRX210 device has
92
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
a 3G ExpressCard slot on the back panel. The SRX210 device supports the Juniper Networks wireless modems listed in Table 4 on page 93.
Table 4: Juniper Networks Wireless Modems Supported by the SRX210 Device
Wireless Cards EXPCD-3G-HSPA-T- 3G UMTS ExpressCard for GSM and UMTS Networks, specifically with 850-MHz band support. Available from Juniper Networks starting February 15, 2010.
Release Supported JUNOS Release 10.1. JUNOS Software Release 10.1 provides untested support for this modem for LAB testing purposes only. JUNOS Release 9.5 and JUNOS Release 9.6.
EXPCD-3G-CDMA-V: 3G EVDO ExpressCard for Verizon Wireless. Currently available from Juniper Networks. EXPCD-3G-CDMA-S: 3G EVDO ExpressCard for Sprint. Currently available from Juniper Networks. Sierra Wireless AirCard Global System for Mobile Communications (GSM) High-Speed Downlink Packet Access (HSDPA) ExpressCard - Sierra Wireless AirCard 880E. Currently available from Juniper Networks.
For more information on installing 3G ExpressCards, see the SRX210 Services Gateway Hardware Guide. For more information on configuring the 3G interface, see the JUNOS Software Interfaces and Routing Configuration Guide.
Related Topics
Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 102 Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 112 Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 140
The following current system behavior, configuration statement usage, and operational mode command usage might not yet be documented in the JUNOS Software documentation:
The following CLI commands have been removed as part of RPC ALG data structure cleanup:

clear security alg msrpc portmap clear security alg sunrpc portmap show security alg msrpc portmap show security alg sunrpc portmap
93
The show security alg msrpc object-id-map CLI command has a chassis cluster node option to permit the output to be restricted to a particular node or to query the entire cluster. The show security alg msrpc object-id-map node CLI command options are <node-id | all | local | primary>.
Chassis Cluster
On SRX650 devices in chassis cluster mode, the T1/E1 PIC goes offline and does not come online. The automatic pause timer functionality related to IP address monitoring for redundancy groups has been removed. Instead, a configurable hold-down-interval timer for all redundancy groups has been instituted. See the Configuring a Dampening Time Between Back-to-Back Redundancy Group Failovers section of the JUNOS Software Security Configuration Guide. IP address monitoring on redundancy group 0 is now supported. The chassis cluster redundancy-group group-number ip-monitoring threshold CLI command has been removed. Instead, use the chassis cluster redundancy-group group-number ip-monitoring global-threshold command. IP address monitoring on virtual routers is now supported.
94
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
Routers
Command-Line Interface (CLI)
95
On AX411 Access Points, the possible completions available for the CLI command
set wlan access-point < ap_name > radio < radio_num > radio-options channel number ? have changed from previous Implementations.
Now this CLI command displays the following possible completions: Example 1:
user@host# set wlan access-point ap6 radio 1 radio-options channel number ? Possible completions: 36 Channel 36 40 Channel 40 44 Channel 44 48 Channel 48 52 Channel 52 56 Channel 56 60 Channel 60 64 Channel 64 100 Channel 100 108 Channel 108 112 Channel 112 116 Channel 116 120 Channel 120 124 Channel 124 128 Channel 128 132 Channel 132 136 Channel 136 140 Channel 140 149 Channel 149 153 Channel 153 157 Channel 157 161 Channel 161 165 Channel 165 auto Automatically selected
Example 2:
user@host# set wlan access-point ap6 radio 2 radio-options channel number ? 1 Channel 1 2 Channel 2 3 Channel 3 4 Channel 4 5 Channel 5 6 Channel 6 7 Channel 7 8 Channel 8 9 Channel 9 10 Channel 10 11 Channel 11 12 Channel 12 13 Channel 13 14 Channel 14 auto Automatically selected
On SRX Series devices, the show security monitoring fpc 0 command is now available.
96
Routers
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 do not work when PCS is configured and removed thorough the CLI. The dial tone dissappears 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 command has been changed to set security datapath-debug. On AX411 Access Points, the possible completions available for the CLI command set wlan access-point mav0 radio 1 radio-options mode? are changed from previous implementations. Now this CLI command displays the possible completions as shown below:
Example 1: user@host# set wlan access-point mav0 radio 1 radio-options mode ? Possible completions:
5GHz Radio Frequency -5GHz-n a Radio Frequency -a an Radio Frequency -an [edit]
Example 2: user@host# set wlan access-point mav0 radio 2 radio-options mode ? Possible completions:
2.4GHz Radio Frequency --2.4GHz-n bg Radio Frequency -bg bgn Radio Frequency -bgn
97
On SRX Series devices, the show system storage partitions command now displays the partitioning scheme details on SRX Series devices.
Example 1:
show system storage partitions (dual root partitioning) user@host# show system storage partitions Boot Media: internal (da0) Active Partition: da0s2a Backup Partition: da0s1a Currently booted from: active (da0s2a) Partitions Information: Partition Size Mountpoint s1a 293M altroot s2a 293M / s3e 24M /config s3f 342M /var s4a 30M recovery
Example 2:
show system storage partitions (single root partitioning) user@host# show system storage partitions Boot Media: internal (da0) Partitions Information: Partition Size Mountpoint s1a 898M / s1e 24M /config s1f 61M /var show system storage partitions (USB)
Example 3:
show system storage partitions (usb) user@host# show system storage partitions Boot Media: usb (da1) Active Partition: da1s1a Backup Partition: da1s2a Currently booted from: active (da1s1a) Partitions Information: Partition Size Mountpoint s1a 293M / s2a 293M altroot s3e 24M /config s3f 342M /var s4a 30M recovery
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 interfaces address.
98
Routers
On SRX100, SRX210, SRX240 and, SRX650 devices, the current JUNOS Software default configuration is inconsistent with the one in Secure Services Gateways, thus causing problems when users migrate to SRX Series devices. As a workaround, users should ensure the following steps are taken:
The ge-0/0/0 interface should be configured as the Untrust port (with the 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 apply interface-nat for all trust->untrust traffic. DNS/Wins parameters should be passed from server to client and, if not available, users should preconfigure a DNS server (required for download of security packages).
Flow and Processing
On SRX Series devices, the factory default for the maximum number of backup configurations allowed is five. 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.1 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. 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 Release 10.1, 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
99
If the aforementioned instructions are not followed, the bundle will be incorrectly processed.
On SRX Series devices, to minimize the size of system logs, the default logging level in the factory configuration has been 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. 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 SRX240 High Memory devices, when you activate or deactivate the ATM interface for the VDSL PIM inserted on slots two, three, or four, it might result in a flowd crash due to a bug in the VDSL driver. This problem might not be noticed on SRX210 devices or slot one of SRX 240 devices.
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. On SRX Series and J Series devices, the IDP ip-action statement is now supported on TCP, UDP, and ICMP flows. When the ip-action target is service, the ip-action flow is applied if the traffic matches the values specified for source port, destination port, source address, and destination address. However, for ICMP flows, the destination port is 0, so that any ICMP flow matching source port, source address, and destination address is blocked. For more information, see the JUNOS Software CLI Reference. On SRX3400 and SRX3600 devices in Layer 2 and Layer 3 integrated mode, mode, 30 percent to 40 percent of the logs created in IDP are not exited from IDP. In Layer 2 and Layer 3 dedicated mode, the logs are exited properly.
100
Routers
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.
Management and Administration
On SRX5600 and SRX5800 devices running a previous release of JUNOS Software, security logs were always timestamped using the UTC time zone. In JUNOS Release 10.1, you can use the set system time-zone CLI command to specify the local time zone that the system should use when timestamping the security logs. If you want to timestamp logs using the UTC time zone, use the set system time-zone utc and set security log utc-timestamp CLI statements. Configuring the External CompactFlash card on SRX650 Services Gateways: The SRX650 Services Gateway includes 2GB CompactFlash storage devices:
The Services and Routing Engine (SRE) contains a hot-pluggable CompactFlash (external CompactFlash) storage device used to upload and download files. The chassis contains an internal compact flash used to store the operating system.
By default, only the internal CompactFlash is enabled, and an option to take a snapshot of the configuration from the internal CompactFlash to the external compact flash is not supported. This can be done only by using a USB storage device. To take a snapshot on the external CompactFlash:
1.
Take a snapshot from the internal CompactFlash to the USB storage device using the request system snapshot media usb CLI command. Reboot the device from the USB storage device by using the request system reboot media usb command. Go to the U-boot prompt. For more information, see the "Accessing the U-Boot Prompt" section in the JUNOS Software Administration Guide. At the U-boot prompt, set the following variables:
set ext.cf.pref 1 save reset
2.
3.
4.
5.
Once the system is booted from the USB storage device, take a snapshot on the external CompactFlash using the request system snapshot media external command.
101
NOTE: Once the snapshot has been taken on the external CompactFlash, we recommend you to set the ext.cf.pref to 0 at the U-boot prompt.
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.
Known Limitations in JUNOS Release 10.1 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/0Link services Multilink Point-to-Point Protocol (MLPPP), Multilink
Frame Relay (MLFR), and Compressed Real-Time Transport Protocol (CRTP)
gr-0/0/0Generic routing encapsulation (GRE) and tunneling ip-0/0/0IP-over-IP (IP-IP) encapsulation pd-0/0/0, pe/0/0/0, and mt-0/0/0All multicast protocols lt-0/0/0Real-time performance monitoring (RPM)
WXC Integrated Services Module (WXC ISM 200)
102
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. 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. For more information, see the Disabling Switching on SRX100, SRX210, and SRX240 Devices Before Enabling Chassis Clustering section in the JUNOS Software Security Configuration Guide. SRX Series devices have the following limitations:
Only two of the 10 ports on each PIC of 40-port 1-Gigabit Ethernet I/O cards (IOCs) for SRX5600 and SRX5800 devices can simultaneously enable IP address monitoring. Because there are four PICs per IOC, this permits a total of eight ports per IOC to be monitored. If more than two ports per PIC on 40-port 1-Gigabit Ethernet IOCs are configured for IP address monitoring, the commit will succeed but a log entry will be generated, and the accuracy and stability of IP address monitoring cannot be ensured. This limitation does not apply to any other IOCs or devices. SRX3400, SRX3600, SRX5600, and SRX5800 devices have the following limitations:
IP address monitoring is not permitted on redundant Ethernet interface LAGs or on child interfaces of redundant Ethernet interface LAGs. In-service software upgrade (ISSU) does not support version downgrading. That is, ISSU does not support running an ISSU install of a software release package earlier or with a smaller release number than the currently installed version.
On SRX3000 and SRX5000 line chassis clusters, screen statistics data can be gathered on the primary device only.
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.
103
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.
Command-Line Interface (CLI)
On SRX210 and SRX240 devices, J-Web crashes if more than nine users log in to the device by using 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 sessionsOn SRX210, SRX240, and SRX650 devices, the maximum number of concurrent sessions is as follows:
Sessions
ssh telnet Web
SRX210 3 3 3
SRX240 5 5 5
SRX650 5 5 5
NOTE: These defaults are provided for performance reasons.
104
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 SRX210 SRX240
CLI 3 5
J-Web 3 5
Console 1 1
On SRX100 devices, Layer 3 control protocols (OSPF, using multicast destination MAC address) on the VLAN Layer 3 interface work only with access ports.
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.
105
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 T1/E1 GPIMs (2 or 4 port version) do not work in 9.6R1. This issue is resolved in JUNOS Release 9.6R2 and JUNOS Release 10.1, but if you roll back to the 9.6R1 image, this issue is still seen.
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 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, the user can use IPsec only on an interface that resides in the routing instance inet 0. The user will not be able to assign an internal or external interface to the IKE policy if that interface is placed in a routing instance other than inet 0. 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
106
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 inet 6 set protocols pim apply-groups group apply-groups-except group family inet 6 set protocols pim apply-groups group apply-groups-except group disable family inet 6 set protocols pim assert-timeout timeout-value family inet6 set protocols pim disable apply-groups group family inet 6 set protocols pim disable apply-groups-except group family inet 6 set protocols pim disable export export-join-policy family inet 6 set protocols pim disable dr-election-on-p2p family inet 6 set protocols pim dr-election-on-p2p family inet 6 set protocols pim export export-join-policy family inet 6 set protocols pim import export-join-policy family inet 6 set protocols pim disable import export-join-policy family inet 6
On SRX210 devices, the USB modem interface can handle bidirectional traffic of up to 19 kbps. On oversubscription of this amount (that is, bidirection traffic of 20 kbps or above), keepalives not get exchanged, and the interface goes down.
107
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, application-level distributed denial-of-service (application-level 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 the (application-level DDoS rules so that traffic destined for one protected server only processes 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 can be committed, but they will not work properly:
source-zone sourcezone-1 source-zone-2
destination-zone dst-1 dst-1
destination-ip any any
service http http
application-ddos http-appddos1 http-appddos2
Application Server 1.1.1.1:80 1.1.1.1:80
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the application-level denial-of-service (application-level DDoS) rulebase (rulebase-ddos) does not support port 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 65,535 in the IDP policy. On SRX210, SRX240, and SRX650 devices, the maximum number of IDP sessions supported is 16,000. On SRX Series devices, all IDP policy templates are supported except All Attacks. There is a 100-MB policy size limit for integrated mode and a 150-MB policy size limit for dedicated mode, and 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.
108
On SRX Series devices, the following IDP policies are supported:

DMZ_Services DNS_Service File_Server Getting_Started IDP_Default Recommended Web_Server
IDP deployed in both active/active and active/passive chassis clusters has the following limitations:

No inspection of sessions that fail over or fail back. The IP address action table is not synchronized across nodes. The Routing Engine (RE) on the secondary node might not be able to reach networks that are reachable only through a Packet Forwarding Engine (PFE). The SSL session-ID cache is not synchronized across nodes. If an SSL session reuses a session-ID and it happens to be processed on a node other than the one on which the session-ID is cached, the SSL session cannot be decrypted and will be bypassed for IDP inspection.
IDP deployed in active/active chassis clusters has the following limitation:
For time-binding scope source traffic, if attacks from a source with more than one destination have active sessions distributed across nodes, the attack might not be detected because time-binding counting has a local-node-only view. Detecting this sort of attack requires an RTO synchronization of the time-binding state that is not currently supported.
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 SRX650 devices, you cannot use J-Web to configure a VLAN interface for an IKE gateway. To configure a VLAN interface for an IKE gateway, use the CLI.
109
NetScreen-Remote
On SRX Series devices, NetScreen-Remote is not supported in JUNOS Release 10.1.
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. The following describes the maximum numbers of NAT rules and rule sets supported:
For static NAT, up to 32 rule sets and up to 256 rules per rule set can be configured on a device. For destination NAT, up to 32 rule sets and up to 8 rules per rule set can be configured on a device. For source NAT, the following are the maximum numbers of source NAT rules that can be configured on a device:

512 for J Series, SRX100, and SRX210 devices 1024 for SRX240 and SRX650 devices 8192 for SRX3400, SRX3600, SRX5600, and SRX5800 devices
These are systemwide maximums for total numbers of source NAT rules. There is no limitation on the number of rules that you can configure in a source NAT rule set as long as the maximum number of source NAT rules allowed on the device is not exceeded.
110
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.
SNMP
On J Series devices, the SNMP NAT-related MIB is not supported in JUNOS Release 10.1.
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)
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.
WLAN
The following are the maximum numbers of access points that can be configured and managed from SRX Series devices:

SRX2104 access points SRX2408 access points SRX65016 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.
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.
111
The total number of tunnels from a given public translated IP cannot exceed 1000 tunnels.
Related Topics
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 80 Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 112 Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 140
Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
Outstanding Issues In JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 112 Resolved Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 136
Outstanding Issues In JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
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.
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.1. [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.[PR/474629] .
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.
112
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] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when a firewall authentication session is initiated, the authentication entry will be created on all the SPUs. However, in JUNOS Release 10.1 when multiple firewall authentication sessions are initiated by the same user simultaneously, authentication entries are not created in all the SPUs. As a result, some sessions might time out, and the user will have to reconnect or retry to reach the server. [PR/475706]
AX411 Access Point
On SRX210 PoE devices, the access point reboots when 100 clients are associated simultaneously and each one is transmitting 512 bytes packets at 100 pps. [PR/469418] On SRX 650 devices, when an access point is part of default cluster and you change the default cluster after the access point is connected to it, the changes might not be reflected. As a workaround, restart the wireless LAN service. [PR/497752] On AX411 Access Points, an access point might not synchronize with newly associated configuration (by changing or swapping the MAC address ) and also might not join the changed cluster when it is associated to new config block in the WLAN access-point configuration. As a workaround, deactivate and activate the access point with the following CLI commands:
#deactivate wlan access-point < ap-name > #commit #activate wlan access-point < ap-name > #commit
[PR/504581]
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
113
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, when you upgrade to the latest software image, the interface links do not come up and are not seen in the Packet Forwarding Engine. As a workaround, you can reboot the device to bring up the interface. [PR/399564] 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]
114
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 in to 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 SRX240 and SRX650 devices in chassis cluster active/active preempt mode, the RTSP session breaks after a primary node reboot and preempt failover. The following common ALGs will be broken: RSH, TALK, PPTP, MSRPC, RTSP, SUNRPC, and SQL. [PR/448870]
115
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] On SRX5600 and SRX5800 devices in a chassis cluster whenever the reth interface with static MAC address is configured, the ping operation fails from the directly connected device to the chassis cluster. [PR/455051] On SRX3400, SRX3600, SRX5600, and SRX5800 devices in a chassis cluster, the ping operation to the redundant Ethernet interface (reth) 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 you upgrade from JUNOS Release 9.6R2 to JUNOS Release 10.1. [PR/471235] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the track IP does not display the correct status if the ip-monitor configuration is under RG0. [PR/482556] 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.1R1. [PR/482566] On SRX3400 and SRX3600 devices, chassis cluster upgrades (LICU) with no-old-master-upgrade from JUNOS Release 9.6R2.11 to 10.0R1.x and from JUNOS Release 10.0R1.8 to 10.1x.x do not work. [PR/483485] On SRX5600 devices with an active/active chassis cluster configuration, under stress conditions, memory pointers of the appid module could be inappropriately assigned. This might cause memory corruption. [PR/483522] On SRX3600 devices, after you disable and enable the secondary node track, the IP status remains unreachable. [PR/488890] On SRX5600 and SRX5800 devices, the shaping rate is not honored during LICU upgrades. During LICU upgrades, when the secondary node is upgraded to the primary node, the shaping rate is doubled and continues to be the same doubled value after the LICU upgrade is finished. [PR/499481] On SRX Series devices configured in a chassis cluster, the following informative messages are erroneously displayed during failover, possibly creating the incorrect impression that errors have occurred:

l2ha_set_rg_state: Setting rg state for 1 (MASTER) l2ha_set_rg_state: Setting rg state for 1 (BACKUP)
[PR/498010]
On SRX5600, SRX5800 devices, the shaping rate doubles during LICU upgrades after the secondary node becomes the primary node and continues to be the same doubled value after LICU, when LICU upgrade is performed for JUNOS Release 10.0R2 to 10.1R1.[PR/491834]
116
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) does not work. [PR/304830] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you change the scheduler type on the Layer 2 aggregated Ethernet interface, the clear interface statistics command does not work for the aggregated Ethernet bundle. [PR/485904]
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, J2320, J2350, J4350, and J6350 devices, broadcast TFTP is not supported when flow is enabled on the device. [PR/391399]
117
On SRX210, SRX240, and SRX650 devices, after the device fragments packets, the FTP over a GRE link might not perform properly because of 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 because of 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 an SRX5800 device with a 1-Gbps IOC, when more than 10 ports per port module are used, intermittent packet loss occurs because of oversubscription. As a workaround, reboot the SRX5800 device. [PR/433209 ] 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] On SRX5800 devices, network processing bundling is not supported in Layer 2 transparent mode. [PR/436863] 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 goes to the WXC ISM 200 and return back 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]
118
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 SRX5600 devices, equal-cost multipath (ECMP) does not work at Layer 4 when transit traffic is passed. [PR/444054] 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 J Series devices, there is a drop in throughput on 64 bytes packet size T3 link when bidirectional traffic is directed. [PR/452652] 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, during end-to-end debugging with the jexec event, packet summary trace messages have unknown IP addresses in the packet summary field. [PR/463534] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, data path-debug rate-limit does not work 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 application on other ports is 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]
119
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, downgrading is not supported in low-impact in-service software upgrade (ISSU) chassis cluster upgrades (LICU). [PR/464841] On SRX210 devices, the lowest rate ATM CoS PCR supported is 64 Kbps. The ping operation cannot reach an ATM interface with a PCR lower than 64 Kbps. [PR/470994] SRX3400 and SRX3600 devices with one Services Processing Card and two Network Processing Cards operating under heavy traffic produce fewer flow sessions. [PR/478939] On SRX3400, SRX3600, SRX5600 and SRX5800 devices, in Layer 2 mode, IGMP and multicast are supported only on the 224.X.X.X address. [PR/493166]
Hardware
On SRX210 devices, the MTU size is limited to 1518 bytes for the 1-port SFP Mini-PIM. [PR/296498] On SRX210 devices, the system takes between 2 and 5 minutes to initialize. [PR/298635] 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] On SRX240 devices, when users swap the USBs after startup, the chassis-control subsystem might not respond to any chassis-related commands. As a workaround, avoid swapping plug and play components in the right USB slot. [PR/437798] On SRX650 devices, the 16-port Gigabit Ethernet switch GPIM is incorrectly labeled as XGPIM. This switch is a double-high XPIM that will operate only in slots 2 to 4 or 6 to 8, connecting to the 20-gigabit connector in slots 2 or 6, respectively. [PR/444511] On SRX210 Low Memory devices, 3G AC402 Live Network Card activation gets timed out. [PR/451493] On SRX5600 devices, during an Routing Engine reboot when processes are being shut down, a rare race condition occurs that can lead to a Routing Engine kernel crash. [PR/488484]
120
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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, the SNMP set for the MIB object usmUserPrivKeyChange does not work. [PR/482475] On SRX5600 and SRX5800 devices, e2e.trace shows an incorrect PIC number for the egress message. [PR/487331]
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 J2320 devices, when you enable the DHCP client, the default route is not added to the route table. [PR/296469] On SRX5600 and SRX5800 devices, ping to far-end reth interfaces does not work for different routing instances. [PR/408500] On SRX240 devices, drops in out-of-profile LLQ packets might be seen in the presence of data traffic, even when the combined (data+LLQ) traffic does not oversubscribe the multilink bundle. [PR/417474]
121
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 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 SRX240, SRX650 and SRX5600 devices, the SNMP null zone counter is not increased if the reth interface is put into the null zone. [PR/427256] On J4350 device, multicast traffic is not received when the source and the receiver are connected to same PE routers. [PR/429130] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you change the multicast scoping to a different multicast address, traffic other than which is configured for multicast scoping will not be recieved. [PR/482957] 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
122
Delete the NSR configuration and then add the configuration back when both the NSR and Layer 2 circuits are up
As a workaround:
1. 2. 3.
Configure the Layer 2 circuit for non-standby connection. Change the configuration to standby connection. 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 goes down in a Multilink (ML) bundle during bidirectional traffic with Multilink Frame Relay (MFR). [PR/445679] On SRX Series devices, If you configure attributes of an interface unit under both the [interfaces] and the [logical-router logical-router-name interface] hierarchies, only the configuration at the interfaces level will take effect. [PR/447986] 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 G.SHDSL interface will not go down when the interface is disabled through the disable command. [PR/453896] On SRX210 devices, the modem moves to the dial-out pending state while connecting or disconnecting the call. [PR/454996] On SRX100 and SRX200 devices with VDLS2, multiple carrier transitions (three to four) are seen during long duration traffic testing with ALU 7302 DSLAM. There is no impact on traffic except for the packet loss after long duration traffic testing, which is also seen in the vendor CPE. [PR/467912] On SRX210 devices with VDLS2, remote end ping fails to go above the packet size of 1480 as the packets are get dropped for the default MTU which is 1496 on an interface and the default MTU of the remote host ethernet intf is 1514. [PR/469651] On SRX210 devices with VDLS2, ATM COS VBR related functionality can not be tested due to lack of support from the vendor. [PR/474297] On SRX210 High Memory devices, IGMP v2 JOINS messages are dropped on an integrated routing and bridging (IRB) interface. As a workaround, enable IGMP snooping to use IGMP over integrated bridging and routing (IRB) interfaces. [PR/492564] On SRX100 and SRX210 devices, every time the VDSL2 PIM is restarted in the ADSL mode, the first packet passing through the PIM will be dropped. This occurs because there is a bug in the SAR engine, which will not set the ATM connection until the first packet has been dropped due to no ATM connection. [PR/493099]
123
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 an octal port line card of total access 1000 ADTRAN DSLAM. [PR/459554] On J Series devices, tail drops are seen on a bundle for traffic with a bigger packet size and smaller fragmentation threshold. [PR/461417] On SRX210 High Memory devices, only six logical interfaces come up on the G.SHDSL ATM interface (including OAM channel). The other two logical interfaces are down. [PR/466296] On SRX210 devices, the G.SHDSL ATM logical interface goes down when ATM CoS is enabled on the interface with OAM. As a workaround, restart the FPC to bring up the logical interface. [PR/472198] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the show datapath-debug counter command gives error messages from the secondary node. [PR/477017] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, link speeds of 100 Mbps and 1 Gbps cannot be configured on the ae0 interface with child interfaces configured. When you commit the configuration, the system displays an error about the mismatch between the ae0 and child interfaces. [PR/482649] On SRX210 High Memory devices, IGMP v2 JOINS messages are dropped on an IRB interface. As a workaround, enable IGMP snooping to use IGMP over Integrated bridging and routing (IRB) interfaces. The destination and destination-profile options for address and unnumbered-address within family inet and inet6 are allowed to be specified within a dynamic profile but not supported. [PR/493279] On SRX 240 Low Memory devices and SRX 240 High Memory devices, the RPM Server operation does not work when the probe is configured with the option destination-interface.[PR/450266] On SRX 210-High Memory devices, the physical interface module (PIM) shows time in ADSL2+ ANNEX-M, even though it is configured for ANNEX-M ADSL2. [PR/ 497129] On SRX210 High Memory devices, the GRE tunnel session is not created properly if the tunnel outgoing interface takes a long time to come up. On T1/E1 interfaces of SRX100, SRX210, SRX240, and SRX650 devices, traffic through GRE tunnel may not work. As a workaround, first create the physical interface and commit the configuration and then create a GRE tunnel configuration. [PR/497864] On SRX5600 and SRX5800 devices, load balance does not happen within the aggregated Ethernet (AE) interface when you prefix length with /24 while increamenting the dst ip. [PR/505840]
The following issues currently exist in SRX210 and SRX240 devices with Integrated Convergence Services:
124
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] You cannot edit the media gateway IP address field on the peer call server page in J-Web. [PR/445750] When you click the trunk-group field in J-Web, the configured trunk values are not displayed. [PR/445765] The J-Web Call Feature Add button does not work. [PR/446422] 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] Caller ID is not displayed on FXS stations for FXO to FXS calls in survivable call server (SRX Series SCS) state. [PR/451719] In J-Web, if you do not configure the class of restriction and a station template, you cannot configure a station. [PR/452439] In J-Web, you cannot specify the station type (as either analog or SIP). [PR/452813] 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]
125
The voice prompt is not played when the user dials an invalid extension. [PR/472357] 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] For SIP trunk to FXO trunk calls routed through the peer call server, the SRX Series device removes the called party number in the SIP INVITE messages. [PR/473979] The SIP-to-SIP simultaneous call capacity is limited to 10 calls. [PR/478485]
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] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, HTTP throughput drops 10 percent from ~3.6 Gbps to ~3.2 Gbps with one Services Processing Card. [PR/482801] On SRX5600 and SRX5800 devices, when the device is processing heavy traffic, the show security idp status operational command might fail. As a result, IDP flow, session, and packet statistics do not match firewall statistics. [PR/389501] [PR/388048] The SRX210 device supports 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 SRX210 devices during attack detection, multiple attacks get detected. This happens when the IDP policy contains rules that have the match criteria for the same attacks. Error/warning messages do not appear during policy compilation. [PR/414416] 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, 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]
126
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if you configure a policy containing more than 200 rules, with each rule containing the predefined attack groups (Critical, Major, and Minor), the memory constraint of the Routing Engine (500 MB) is reached. [PR/449731] On SRX3400, and SRX3600 devices, the logging rate is slightly less in SPUs operating in combo mode as compared to SPUs operating in non-combo mode. [PR/457251] 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 hang for longer than necessary, and they will time out eventually. [PR/458900] When an SRX Series device running JUNOS Release 10.1 (Layer 2 access-integrated mode) is rolled back to the JUNOS Release 9.6 image, the DUT comes up in JUNOS 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, the application-level distributed denial-of-service (application-level DDoS) rulebase (rulebase-ddos) does not support port 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 works properly. [PR/472522] On SRX3400, SRX3600, SRX5600, and SRX5800 devices with application-level DDoS protection, the IDP session capacity is dropped by 9 percent in integrated mode. [PR/479552] SRX5600 devices operating at high HTTPS session rate with the default session-id-cache-timeout value might run out of memory and begin dropping sessions. As a workaround, reduce the session-id-cache-timeout value. [PR/476215]
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]
127
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 SRX Series devices, when the user tries to associate an interface to GVRP, a new window appears. This new window shows multiple move-left and move-right buttons. [PR/305919] 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 does not work 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 J2350, J4350, and J6350 devices, users cannot configure firewall filters using J-Web. The Firewall Filters menu was removed because it was not functioning properly. [PR/422898] 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 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]
128
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 device, 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 or saved in the device. [PR/439636] On an SRX5600 device, when you click OK or Cancel from the IPS/Exempt rule configuration page, it takes a long time to go to the next page when the Internet Explorer IE browser is used. The slow response is due to predefined attacks, attack group XML data fetching, and the way Internet Explorer IE refreshes the page. As a workaround, use Firefox 3.5 or later. [PR/449017] 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 J-Web configuration for the routing feature, if you enter double quotation marks in the text boxes that accept characters (for example, protocol name, file name, and description), then you cannot delete the data with double quotation marks through J-Web. As a workaround, you can use the CLI to introduce another backslash, which removes the double quotation marks from the data. [PR/464030] 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]
129
On SRX210, SRX240, SRX650 and J Series devices, in the J-Web interface, Monitor>Switching>Spanning Tree shows a null page when Spanning Tree Protocol is not running on the device. [PR/484202] On SRX210 Low Memory, SRX210 High Memory, and SRX210 PoE devices, in the J-Web interface, Configuration>Routing>Static Routing does not display the IPv4 static route configured in rib inet.0. [PR/487597] On SRX210, SRX240, and SRX650 devices, wired equivalent privacy (WEP) key validation is not properly executed in J-Web, sometimes an error is returned even if the proper validation key has been submitted. [PR/486910] On SRX3400 devices, in chassis cluster mode, the predefined attacks list will also be loaded. [PR/488607] On J2350, J4350, J6350, SRX100 Low Memory, SRX100 High Memory, SRX210 Low Memory, SRX210 High Memory, SRX210 PoE, SRX240 Low Memory, SRX240 High Memory, and SRX650 devices, in J-Web, in all the class of service (CoS) features, system commits configuration without reporting any validation messages, even if you have not done any changes. [PR/495603] On SRX devices, using J-Web the security zone associated to a logical unit other than zero gets associated to a logical unit zero. [PR/504026]
On SRX3400 and SRX3600 devices, a minor alarm is not triggered when the central point or SPU session table is full. [PR/405990] 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 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]
130
On SRX Series and J Series devices with session-init and session-close enabled, you should not clear sessions manually when too many sessions are in status "used". [PR/445730] 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] On SRX5800 devices, rebooting is required for any NP bundle configuration change to take effect. Currently there is no notification displayed after the bundle configuration change to notify that a reboot is required for the change to take effect. [PR/441546] On SRX5600 and SRX5800 devices, the simple filter does not work after reboot of the new primary node. [PR/ 486181]
On SRX210 and SRX240 devices, source NAT using interface IP address on the pp0 interface is not working. Traffic is not forwarded because of NAT translation failure via this interface. [PR/479256] On SRX240 High Memory devices, under HA environment, the secondary box can go to DB> mode when there are many policies configured and TCP/UDP/ICMP traffic matched them. [PR/493095] On J4350 devices, when you place internal calls, interface based persistent network address translation (NAT) displays only one active hairpinning session instead of two, even after the call is established. [PR/504932] On SRX3400, SRX-3600, SRX-5600, and SRX-5800 devices NAT'd behavior in event-logs is incorrect for 10.1. Due to a bug, the log output shows both src and dst IP from client/server instead of just the IP address which is NAT'd. The correct address should be as follows: If only dest is nat?ed, ip address displayed in log should be 0.0.0.0->5.0.0.1 If only src is nat?ed, ip address displayed in log should be 4.0.0.0->0.0.0.0 The 10.1 output shows 4.0.0.0->5.0.0.1 [PR/505454]
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]
131
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 SRX210 devices, the fourth access point connected to the services gateway fails to boot with the default Power over Ethernet (PoE) configuration. As a workaround, configure all the PoE ports to a maximum power of 12.4 watts. Use the following command to configure the ports: root#set poe interface all maximum-power 12.4 [PR/465307] On SRX100, SRX210, SRX240, and SRX650 devices, with factory default configurations the device is not able to manage the AP. This might be due to the DHCP default gateway not being set. [PR/468090] On SRX 210 PoE devices managing AP AX411 access points , the device might not be able to synchronize time with the configured NTP Server. [PR/460111] On SRX 210PoE devices managing AX411 access points, traffic of 64 bytes at speed more than 45 megabits per second (Mbps), might result in loss of keepalives and reboot of the AX411 Access Point. [PR/471357] On SRX 210 PoE devices, high latencies might be observed for the Internet Control Message Protocol (ICMP) pings between two wireless clients when 32 virtual access points (VAPs) are configured. [PR/472131] On SRX 210 PoE devices, when AX411 access points managed by the SRX devices reboot, the configuration might not be reflected onto the AX411 access point. As a result, Ax411 access point retain the factory default configuration. [PR/476850]
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] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, you should not configure rulebase-DDoS rules that have two different application-DDoS objects to run on one destination service because the traffic destined to one application server can encounter more than one rule. Essentially, for each protected application server, you have to configure a single application-level DDoS rule. [PR/467326]
132
SNMP
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the value for jnxBoxDescr.0 MIB object is incorrectly displayed as SRX 3400 instead of SRX3400. Note that there is no blank space between SRX and model number. (3400/3600). [PR/490296]
USB Modem
On SRX210 , SRX100, 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. With this the dial-out side re-connects with the dial-in side successfully. [PR/480206] Perform the following steps:
1.
Disable the dialer interface.

root@noky# set interfaces dl0 disable root@noky# commit
2.
Restart forwarding daemon.

root@noky# run restart forwarding Forwarding Daemon started, pid 1407 root@noky# delete interfaces dl0 disable root@noky# commit
3.
Enable the dialer interface.

root@noky# delete interfaces dl0 disable root@noky# commit
On SRX210 High Memory devices and J6350 devices, packet loss is seen during rapid ping operations between the dialer interfaces when packet size is more than 512 Kbps. [PR/484507] On SRX210 High Memory devices, the modem interface can handle bidirectional traffic of up to 19 Kbps. During oversubscription of 20-Kbps or more traffic, the keepalive packets are not exchanged and the interface goes down. [PR/487258] On SRX210 High Memory devices, IPv6 is not supported on dialer interfaces with a USB modem. [PR/489960] On SRX210 High Memory devices, http traffic is very slow through the umd0 interface. [PR/489961] On SRX210 High Memory devices, on multiple resets of the umd0 interface, the umd0 interface keeps flapping if the d10 (dialer) interface on either the dialin or dialout interface goes down because no keepalive packets are exchanged. As a workaround, increase the ATS0 value to 4 or greater. [PR/492970] On SRX210 Services Gateways with Integrated Convergence Services, when you have USB modem configurations and you remove the USB modem from USB port 1, the device reboots. [PR/491777]
133
On SRX100, SRX210, SRX240, and SRX650 devices, the call terminates if you remove and insert a USB modem. [PR/491820] On SRX210 High Memory devices and J6350 devices, the D10 link flaps during long-duration traffic of 15-Kbps and also when packet size is 256 Kbps or more. [PR/493943]
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]
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 uses 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]
134
For SRX210 High Memory devices, during configuration of access and trunk ports, the individual VLANs from the vlan-range are not listed. [PR/489872] 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 SRX650 devices, customer-vlans and vlan-push do not work together for the same VLAN [PR/476999]. 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 SRX5600 and SRX5800 devices, in Layer 2 mode the first packet is used for MAC learning, and it will not be flooded, so the first packet is dropped if the MAC address is not available in the MAC table. [PR/486980] On SRX5600 and SRX5800 devices, ISIS adjacency is not formed on the VLAN tagged reth interface.[PR/488899] On SRX100 Low Memory, SRX100 High Memory, SRX210 Low Memory, SRX210 High Memory, SRX240 High Memory, and SRX650 devices, the Link Layer Discovery Protocol (LLDP) organization specific Type Length Value (TLV), medium attachment unit (MAU) information always propagates as "Unknown". [PR/480361] On SRX100 High Memory devices and SRX210 Low Memory devices, dot1x unauthenticated ports accept Link Layer Discovery Protocol (LLDP) Protocol Data Units (PDUs) from neighbors. [PR/485845]
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 SRX5600 devices, the IKE authentication method displays an unknown message on the dial-up VPN. [PR/393939] 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]
135
WLAN
On SRX Series devices, when WLAN configuration is committed, it takes a while before the configuration is reflected on the access point, depending on the number of virtual access points and the number of access points connected. [PR/450230] On SRX210, SRX240 and SRX650 devices, J-Web online Help displays the list of all the countries and is not based on the regulatory domain within which the access point is deployed. [PR/469941]
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.1 for SRX Series Services Gateways and J Series Services Routers
The following issues from JUNOS Release 10.0 have been resolved with this release. The identifier following the description is the tracking number in our bug database.
Application Layer Gateways (ALGs) AX411 Access Point
On SRX210 PoE, SRX240 PoE, and SRX650 devices, the access point clustering feature was not supported in JUNOS Release 10.1B1. [PR/481976: This issue has been resolved.]
Chassis Cluster
On SRX5600 and SRX5800 devices, during data path debugging on a chassis cluster in active/active mode, the IOC EZchip egress trace messages were not traced. [PR/440019: This issue has been resolved.] On SRX5600 and SRX5800 devices in a chassis cluster whenever the reth interface with static MAC address was configured, ping operation failed from the directly connected device to the chassis cluster. [PR/455051:This issue has been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the chassis cluster configurations caused the SPU to crash. [PR/460378: This issue has been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, during data path debugging on a chassis cluster in active/active mode with customized action profile, the packets that had been matched by the packet filter were dropped at
136
the secondary node 1 and showed unknown packet summary messages. [PR/477388: This issue has been resolved.]
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, flowd core occurred after you applied a load balance policy. [PR/485532: This issue has been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, a flowd core file error occurred on the backup node when you rebooted the active node and multicast traffic. [PR/484562: This issue has been resolved.] On SRX5800 devices, two nodes in a chassis cluster used the same index for different tunnels. If there was a conflict in the tunnel index and you cleared the tunnel using the index from one node, an extra tunnel might got removed from the other node. [PR/472109: This issue has been resolved.] On SRX3400 and SRX3600 devices, the new primary node on LICU in JUNOS Release 9.6R2 build was affected in the in-service software upgrade (ISSU) window. [PR/473149: This issues has been resolved.] For SRX3400, SRX3600, SRX5600, SRX5800 devices, the aggregated Ethernet load balancing algorithm with Layer 4 src/dst ports was not supported. [PR/486867: This issue has been resolved.]
On SRX5600 devices, class of service was not supported in transparent mode. [PR/424286: This issue has been resolved.]
Flow and Processing
On J2350, J4350, and J6350 devices, OSPF over GRE over IPsec did not work. [PR/105279: This issue has been resolved.] On SRX100 devices with a native VLAN configured on trunk ports, packets sent out were tagged. Instead, packets should have been sent untagged from the trunk port. [PR/455323: This issue has been resolved.] On SRX5600 devices, the request system storage cleanup command was deleting the configuration file juniper.conf.spu.gz from /var/tmp/. This will cause failure of VPN. [PR/474581: This issue has been resolved] On SRX5600 and SRX5800 devices with data path debugging enabled, multicast packets were not traced at the IOC egress chip. [PR/455608: This issue has been resolved.] On SRX and J series devices, the mplsResourceTunnelTable reported bandwidth in bits per second instead of kilobits per second. [PR/432716: This issue has been resolved.] MPLS LSP auto-bandwidth adjustment stopped working when RSVP signaled for the path; either optimization was initiated or the LSP went down. [PR/438157: This issue has been resolved.] On SRX5600 devices, the update Packet Data Protocol (PDP) request initiated from gateway GPRS support nodes (GGSNs) might have gotten dropped if the
137
message did not contain an information element (IE) for GSN addresses. [PR/475645: This issue has been resolved]
On SRX100 Low Memory devices, when you sent the traffic out on a trunk, a single stream was replicated and sent out on all the member ports of that trunk. [PR/497313: This issue has been resolved.]
Hardware
On SRX240 devices, when users swapped the USBs after startup, the chassis-control subsystem might not respond to any chassis-related commands. [PR/437798: This issue has been resolved.] On SRX240 devices, booting up the device with a USB storage device in both the USB slots might have resulted in a kernel crash. [PR/437515: This issue has been resolved.]
On SRX210 devices, after you created a station in J-Web, the details were not displayed until you refreshed the page. [PR/446830: This issue has been resolved.] On SRX210 devices, J-Web did not contain support to configure T1 lines for stations. [PR/470036: This issue has been resolved.] In the Via and Contact headers of REGISTER and INVITE messages, incorrect IP addresses were sent over SIP trunks through VPN tunnels. [PR/478125: This issue has been resolved.] Voice codec support is limited to G.711 u-law only. [PR/469094: This issue has been resolved] [PR/485021: This issue has been resolved]
On SRX3400 devices, the IPv6 transit counters on the reth interface showed invalid value statistics. [PR/391407: This issue has been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, interface statistics on the st0 interface were not accurate. [PR/436857: This issue has been resolved.] On SRX210 PoE devices, the local loopback that was enabled on the G.SHDSL ATM interface did not work. [PR/456393: This issue has been resolved]
On SRX5600 and SRX5800 devices, when the device processes heavy traffic, the show security idp status operational command might fail. As a result, IDP flow, session, and packet statistics did not match firewall statistics. [PR/389501 PR/388048: This issue have been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you performed the SSL inspection, the HTTPS sessions with higher data transaction sizes failed because of heavy CPU usage. As a result, new connections might have failed. [PR/390308: This issue has been resolved.]
138
On SRX100 devices, IDP signature updates might have failed if the last known good IDP policy was active. The situation occurred if you loaded a new IDP policy and it failed to load for any reason. [PR/468184: This issue has been resolved.]
J-Web
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the available list of predefined attacks and groups were not listed on the J-Web IDP IPS and exempt rule configuration pages. [PR/295283: This issue has been resolved.] Tracking PR for all switching pages general issues. [PR/431667: This issue has been resolved]
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 SRX Series and J Series devices, it took extra time to load the J-Web pages when you click Add or Edit in the STP, GVRP and IGMP-Snooping configuration pages. [PR/422523: This issue has been resolved.]
On SRX5600 and SRX5800 devices during data path debugging, the IPsec packets were not traced at the IOC EZchip egress event. [PR/441663: This issue has been resolved.] On SRX5800 devices, when VPN was not in use, the device did 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: This issue has been resolved.]
Power over Ethernet
On SRX210 and SRX240 devices, the class-4 powered device did not get powered on when PoE was configured to operate in class management mode. [PR/437406: This issue has been resolved] SRX210 and SRX240 devices operating under overload conditions took longer to power off than what is specified in the standards. [PR/437416: This issue has been resolved.] On SRX240 and SRX210 devices, the last powered device did not power on if the allocated power became 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: This issue has been resolved.]
139
USB Modem
On SRX210 PoE devices, if you have USR USB modems configured, the device goes into DB mode. [PR/497184: This issue has been resolved.]
On SRX650 devices under stress conditions, heavy data traffic going through the UTM subsystem sometimes led to system buffers being used up and to traffic being stopped. [PR/436998: This issue has been resolved.] On SRX210 High Memory devices, the express antivirus initial database download failed because of the slow start of the device interface. [PR/388535: This issue has been resolved.]
On SRX100, SRX240, and J Series devices, default VLAN was not added to the switch trunk with the "VLAN member all" configuration after reboot. [PR/450869: This issue has been resolved.]
Related Topics
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 80 Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 102 Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 140
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
This section lists outstanding issues with the documentation.
The following section has been removed from the JUNOS Software Security Configuration Guide to reflect RPC ALG data structure cleanup: Display the Sun RPC Port Mapping Table. The Verifying the RPC ALG Tables section of the JUNOS Software Security Configuration Guide has been renamed to Verifying the Microsoft RPC ALG Tables to reflect RPC ALG data structure cleanup.
140
Routers
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
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]
CLI
The following sections have been removed from the JUNOS Software CLI Reference to reflect RPC ALG data structure cleanup:

show security alg sunrpc portmap clear security alg sunrpc portmap
Flow
The JUNOS Software CLI Reference and JUNOS Software 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
141
Information about secure context and router context has been removed from the JUNOS Software Administration Guide and the JUNOS Software Security Configuration Guide. If you want to use both flow-based and packet-based forwarding simultaneously on a system, use the selective stateless packet-based services feature instead. For more information, see Configuring Selective Stateless Packet-Based Services in the JUNOS Software Administration Guide.
Hardware Documentation
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.
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 check box 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 show chassis environment cb 0 command mentioned in the SRX5600 Services Gateway Hardware Guide is modified to show chassis environment cb node 0. The Power over Ethernet section in the SRX210 Services Gateway Hardware Guide incorrectly states that PoE+ support (IEEE 802.3at standard) is available on all models of 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 model.
142
Routers
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. 2.
Use the request system storage cleanup command to delete temporary files. 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 servers TFTP root directory. The instructions should also mention that you should store the JUNOS Software image file in the TFTP servers 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.
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.
143
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. 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
2.
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 JUNOS Release 10.1. On SRX210 and SRX240 devices with Integrated Convergence Services, the Transport Layer Security (TLS) option for the SIP protocol transport is not supported in JUNOS Release 10.1. However, it is documented in the Integrated Convergence Services entries of the JUNOS Software CLI Reference Guide. The JUNOS Software CLI Reference contains Integrated Convergence Services statement entries for the music-on-hold feature which is not supported for this release.
In the JUNOS Interfaces and Routing Configuration Guide, the Configuring VDSL2 Interface chapter incorrectly states that J-Web support for configuring the VDSL2 Interface is not available in this release. The J-Web support is available for VDSL2 interfaces in JUNOS Software release 10.1. In the JUNOS Interfaces and Routing Configuration Guide, the Configuring G.SHDSL Interface chapter incorrectly states that J-Web support for configuring the G.SHDSL Interface is not available in this release. The J-Web support is available for G.SHDSL interfaces in JUNOS Software release 10.1.
144
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 as follows: 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 as follows: 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 CLI Reference guide and the Junos Security Configuration guide states that the maximum acceptable range for the timeout (IDP Policy) is 65535 seconds, whereas the ip-action timeout range has been modified to 0-64800 seconds. The JUNOS Software CLI Reference guide and the Junos Security Configuration guide has missing information about the new CLI option download-timeout, which has been introduced to set security idp security-package automatic download-timeout < value >, to configure the download timeout in minutes. The default value for download-timeout is one minute. If download is completed before the download-timeout, signature is automatically updated after the download. If the download takes longer than download-timeout, auto signature update is aborted. Syntax: user@host# set security idp security-package automatic download-timeout ? Possible completions: < download-timeout > Maximum time for download to complete (1 - 60 minutes)
145
[edit] user@host# set security idp security-package automatic download-timeout Range: 1 60 seconds Default: 1 second
The Junos Software CLI Reference guide incorrectly states the show security idp status and clear security idp status logs, whereas the logs should be as follows:
Correct show security idp status log user@host> show security idp status State of IDP: 2-default, Up since: 2010-02-04 13:37:16 UTC (17:15:02 ago) Packets/second: 5 Peak: 11 @ 2010-02-05 06:51:58 UTC KBits/second : 2 Peak: 5 @ 2010-02-05 06:52:06 UTC Latency (microseconds): [min: 0] [max: 0] [avg: 0] Packet Statistics: [ICMP: 0] [TCP: 82] [UDP: 0] [Other: 0] Flow Statistics: ICMP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] TCP: [Current: 2] [Max: 6 @ 2010-02-05 06:52:08 UTC] UDP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] Other: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] Session Statistics: [ICMP: 0] [TCP: 1] [UDP: 0] [Other: 0] Policy Name : sample Running Detector Version : 10.2.160091104
Correct clear security idp status log user@host> clear security idp status State of IDP: 2-default, Up since: 2010-02-04 13:37:16 UTC (17:13:45 ago) Packets/second: 0 Peak: 0 @ 2010-02-05 06:49:51 UTC KBits/second: 0 Peak: 0 @ 2010-02-05 06:49:51 UTC Latency (microseconds): [min: 0] [max: 0] [avg: 0] Packet Statistics: [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0] Flow Statistics: ICMP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] TCP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] UDP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] Other: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC] Session Statistics: [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0] Policy Name: sample Running Detector Version: 10.2.160091104
The Verifying the Policy Compilation and Load Status section of the JUNOS Software Security Configuration Guide has a missing empty/new line before the IDPD Trace file heading, in the second sample output.
J-Web
The following information pertains to SRX Series and J Series devices:
J-Web security package update Help pageThe J-Web Security Package Update Help page does not contain information about download status. J-Web pages for stateless firewall filtersThere is no documentation describing the J-Web pages for stateless firewall filters. To find these pages in J-Web, go to Configure>Security>Firewall Filters, then select IPv4 Firewall Filters or IPv6
146
Routers
Hardware Requirements for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
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.
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.
Related Topics
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 80 Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 102 Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 112

Transceiver Compatibility for SRX Series and J Series Devices on page 147 Power and Heat Dissipation Requirements for J Series PIMs on page 148 Supported Third-Party Hardware for J Series Services Routers on page 148 J Series CompactFlash and Memory Requirements on page 149
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.
147
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 for J Series Services Routers

The following third-party hardware is supported for use with J Series Services Routers running JUNOS software.
USB Modem
We recommend using a U.S. Robotics USB 56K V.92 Modem, model number USR 5637. 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 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 5 on page 148 lists the USB and CompactFlash card devices supported for use with the J Series Services Routers.
Storage Devices
Table 5: Supported Storage Devices on the J Series Services Routers

Manufacturer SanDiskCruzer Mini 2.0 SanDisk SanDisk Kingston Kingston SanDiskImageMate USB 2.0 Reader/Writer for CompactFlash Type I and II Storage Capacity 256 MB 512 MB 1024 MB 512 MB 1024 MB N/A Third-Party Part Number SDCZ2-256-A10 SDCZ3-512-A10 SDCZ7-1024-A10 DTI/512KR DTI/1GBKR SDDR-91-A15
148
Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways
Table 5: Supported Storage Devices on the J Series Services Routers (continued)

Manufacturer SanDisk CompactFlash SanDisk CompactFlash Storage Capacity 512 MB 1 GB Third-Party Part Number SDCFB-512-455 SDCFB-1000.A10
J Series CompactFlash and Memory Requirements

Table 6 on page 149 lists the CompactFlash card and DRAM requirements for J Series Services Routers.
Table 6: J Series CompactFlash Card and DRAM Requirements
Minimum CompactFlash Card Required 512 MB 512 MB 512 MB 512 MB
Model J2320 J2350 J4350 J6350
Minimum DRAM Required 512 MB 512 MB 512 MB 1 GB
Maximum DRAM Supported 1 GB 1 GB 2 GB 2 GB
Related Topics
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 80 Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 102 Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 93 Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 112 Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 160 Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers on page 140

Dual-Root Partitioning Scheme
JUNOS Release 10.1 supports dual-root partitions on SRX100, SRX210, SRX240, and SRX650 devices. Dual-root partition allow the SRX Series devices to remain functional
149
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.1 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.1.
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.1 on SRX100, SRX210, SRX240, and SRX650 devices with the single-root partitioning scheme, we strongly recommend the use of the dual-root partitioning scheme.
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. 2.
Internal NAND flash (default; always present) USB storage device (alternate)
SRX650 devices boot from the following storage media (in order of priority):
1. 2. 3.
Internal CompactFlash card (default; always present) External CompactFlash card (alternate) 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.
150
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.
Upgrade Methods SRX Series devices that ship from the factory with JUNOS Release 10.10 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.1, 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.1 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.1)
The following upgrade methods retain the existing partitioning scheme:

Installation using the CLI Installation using J-Web
151
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.1 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 Software Administration Guide for Security Devices. Upgrading to JUNOS Release 10.1 with Dual-Root Partitioning To format the media with dual-root partitioning while upgrading to JUNOS Release 10.1, 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.1, 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.1 with dual-root partitioning is described in detail in the following sections:

Installing from the Boot Loader Using a TFTP Server on page 152 Installing from the Boot Loader Using a USB Storage Device on page 153 Installing from the CLI Using the partition Option on page 154 Upgrading the Boot Loader on page 154
Installing from the Boot Loader Using a TFTP Server See the JUNOS Software Administration Guide for Security Devices for detailed information on installing JUNOS Software using a TFTP server.
152
To install JUNOS Release 10.1 from the boot loader using a TFTP server:
1. 2.
Upload the JUNOS Software image to a TFTP server. 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 severip=<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.1R1-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.1, upgrade the U-boot and boot loader immediately. See Upgrading the Boot Loader on page 154.
Installing from the Boot Loader Using a USB Storage Device To install JUNOS Release 10.1 from the boot loader using a USB storage device:
1. 2. 3. 4.
Format a USB storage device in MS-DOS format. Copy the JUNOS Software image onto the USB storage device. Plug the USB storage device into the SRX Series device. 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.1R1-domestic.tgz
153
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.1, upgrade the U-boot and boot loader immediately. See Upgrading the Boot Loader on page 154.
Installing from the CLI Using the partition Option To install JUNOS Release 10.1 with the partition option:
1. 2. 3.
Upgrade the device to JUNOS Release 10.1 or later using the CLI or J-Web. This will install the new image with the older single-root partitioning scheme. After the device reboots with JUNOS Release 10.1, upgrade the boot loader to version 1.5. See Upgrading the Boot Loader on page 154. Reinstall the 10.1 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.1 image installed with the dual-root partitioning scheme.
NOTE: This process might take 1520 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.1 (with or without dual-root support enabled). The JUNOS 10.1 image contains the latest boot loader binaries in the following path: /boot/uboot, /boot/loader.
2. 3.
Enter the shell prompt. 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.
154
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. 2.
Upload the JUNOS Software image to a TFTP server. 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 severip=<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. 2. 3. 4.
Format a USB storage device in MS-DOS format. Copy the JUNOS Software image onto the USB storage device. Plug the USB storage device into the SRX Series device. Stop the device at the loader prompt and issue the following command:
155
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: *********************************************************************** ** ** ** ** ** ** ** ** ** Please re-install JUNOS to recover the active copy in case it has been corrupted. It is possible that the active copy of JUNOS failed to boot up properly, and so this device has booted from the backup copy. WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE ** ** ** ** ** ** ** ** **
***********************************************************************
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.
156
CLI Changes This section describes CLI changes when the SRX Series device runs JUNOS Release 10.1 with the dual-root partitioning scheme.

Changes to the Snapshot CLI on page 157 partition Option with the request system software add Command on page 158
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.1I20090723_1017-domestic usb (/dev/da1s2a) (backup)
Information for snapshot on
Creation date: Jul 24 16:17:13 2009 JUNOS version on snapshot: junos : 10.1I20090724_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.
157
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.1R1-domestic.tgz no-copy no-validate partition reboot Copying package junos-srxsme-10.01R1-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.
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.1 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).
158
To upgrade the software image on the second Routing Engine (RE1):

1. 2. 3.
Use FTP to copy the installation media into the /var/tmp directory of the master Routing Engine (RE0). Insert a USB storage device into the USB port on the master Routing Engine (RE0). In the UNIX shell, navigate to the /var/tmp directory:
start shell 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
externalDriveRefers to the removable media name. For example, the removable media name on an SRX5000 line device is da0 for both Routing
Engines.
installMediaRefers to the installation media downloaded into the /var/tmp directory. For example, install-media-srx5000-10.1R1-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.1R1-domestic.tgz of=/dev/da0 bs=64k
6.
Log out as root or superuser:

exit
7. 8. 9.
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). Move the console connection from the master Routing Engine (RE0) to the second Routing Engine (RE1), if you do not already have a connection. 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:
159
Eject the installation media and hit [Enter] to reboot?
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
In order to upgrade to JUNOS Release 10.1 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.1 release. For example, to upgrade from Release 9.2R1, first upgrade to Release 9.2R4 and then to Release 10.1B3. For additional upgrade and download information, see the JUNOS Software Administration Guide and the JUNOS Software Migration Guide.
JUNOS Software Release Notes for EX Series Switches

New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174
New Features in JUNOS Release 10.1 for EX Series Switches

New features in Release 10.1 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.
160
Routers
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
New features are described on the following pages:

Hardware on page 161 Access Control and Port Security on page 162 Bridging, VLANs, and Spanning Trees on page 162 Class of Service (CoS) on page 162 Infrastructure on page 162 Interfaces on page 163 Layer 2 and Layer 3 Protocols on page 163 Management and RMON on page 163 MPLS on page 163 Packet Filters on page 163
Hardware
EX2200 switchThe EX2200 switch is a fixed-configuration switch that is available in four models24-port or 48-port models with either all ports equipped for Power over Ethernet (PoE) or none of the ports equipped for PoE. All EX2200 models provide network ports that have 10/100/1000BASE-T Gigabit Ethernet connectors and uplink ports that support 1-gigabit small form-factor pluggable (SFP) transceivers for use with fiber connections and copper connections. For information about software features supported on the EX2200 switch, see EX Series Switch Software Features Overview . The following optical interfaces are supported on the EX2200 switch:

EX-SFP-1GE-T (1000BASE-T, 100 m) EX-SFP-1GE-SX (1000BASE-SX, 220 m, 275 m, 500 m, or 550 m) EX-SFP-1GE-LX (1000BASE-LX, 10 km) EX-SFP-1GE-LH (1000BASE-LH or 1000Base-LH, 70 km) EX-SFP-1FE-FX (100BASE-FX, 2 km) EX-SFP-FE20KT13R15 (100BASE-BX-U, 20 km) EX-SFP-FE20KT15R13 (100BASE-BX-D, 20 km)
New optical transceiver supportThe 8-port 10-Gigabit Ethernet SFP+ line card in EX8200 switches now supports one new optical transceiver: EX-SFP-10GE-ER (10GBase-ER, 40 km).
161
Access Control and Port Security
Captive portal authenticationCaptive portal authentication allows you to authenticate users on EX Series switches by redirecting Web browser requests to a login page that requires users to input a username and password before they are allowed access to the network. In addition to using the feature to control network access by requiring users to provide information that is authenticated against a RADIUS server database, you can also use it to display an acceptable-use policy to users before they access your network. An authentication whitelist allows you to specify MAC addresses that are allowed to bypass authentication.
Bridging, VLANs, and Spanning Trees
Proxy ARPProxy ARP can be configured on a per-VLAN basis, in either restricted or unrestricted mode. IPv6 unicast VRF supportEX Series switches now support IPv6 unicast VRF traffic. Private VLANsPrivate VLANs (PVLANs) are now supported on EX8200 switches.
Port shaping and queue shapingPort shaping and queue shaping (the shaping-rate configuration statement) is now available on EX8200 switches.
Infrastructure
IPv6 support on EX8200 switchesEX8200 switches now support configuration of IPv6 addresses. Automatic refreshing of scriptsYou can refresh commit, event, and op scripts automatically using operational mode commands such as request system scripts refresh-from commit, request system scripts refresh-from event, or request system scripts refresh-from op. Source gateway IP address selection for relayed DHCP packetsThe source gateway IP address selection for relayed DHCP packets feature allows you to use the gateway IP address (giaddr) as the source IP address of the switch for relayed DHCP packets when an EX Series switch is used as the DHCP relay agent.
162
Interfaces
Unicast reverse-path forwarding supportUnicast reverse-path forwarding (RPF) is available on EX8200 switches. The unicast RPF feature can be enabled on specific interfaces on EX8200 switches and supports ECMP traffic.
Layer 2 and Layer 3 Protocols
IPv6 Layer 3 multicast routing and forwardingEX3200 and EX4200 switches now support IPv6 Layer 3 multicast routing and forwarding, which includes Multicast Listener Discovery version 1 (MLDv1) and MLDv2 to manage multicast group membership; reverse-path forwarding (RPF) to enable multicast routers to correctly forward multicast traffic to other multicast routers; Protocol Independent Multicast sparse mode (PIM SM) and PIM source-specific multicast (PIM SSM) protocols; and static rendezvous point (RP), bootstrap RP, and embedded RP to manage RP information for multicast groups.
Management and RMON
Real-time performance monitoring (RPM) support on EX8200 switchesRPM is supported on EX8208 and EX8216 switches. SNMP MIB enhancementsThe SNMP agent polls and gets details of all MIBs on EX2200 switches.
MPLS
MPLS enhancementsOn EX3200 and EX4200 switches MPLS supports class of service (CoS), IP over MPLS, and fast reroute to reroute the label-switched path in cases of link failure.
Packet Filters
IPv6 support for firewall filters on EX3200 and EX4200 switchesOn EX3200 and EX4200 switches, you can apply match conditions to IPv6 traffic on Layer 3 interfaces, aggregated Ethernet interfaces, and loopback interfaces. The following are the match conditions applicable to IPv6 traffic: destination-address, destination-port, destination-prefix-list, icmp-code, icmp-type, interface, next-header, packet-length, source-address, source-port, source-prefix-list, tcp-established, tcp-flags, tcp-initial, and traffic-class. The following are the actions and action modifiers applicable to IPv6 traffic: accept, discard, routing-instance, analyzer, count, forwarding-class, loss-priority, and policer.
Enhancement to the interface match condition on EX8200 switchesOn EX8200 switches, you can now specify aggregated Ethernet interfaces as match conditions using the interface match condition. You can configure an ingress or
163
egress firewall filter with an aggregated Ethernet interface as a match condition and apply the firewall filter to ports, VLANs, and Layer 3 interfaces.
Related Topics
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches
The following changes system behavior, configuration statement usage, or operational mode command usage have occurred since the previous release and might not yet be documented in the JUNOS Software for EX Series switches documentation:
Layer 2 and Layer 3 Protocols
EX Series switches now support the show multicast rpf instance instance-name command. The iso option is not available in the show pfe route command because it is not supported on EX Series switches.
Infrastructure
On EX Series switches, the sip-server statement in the [edit system services dhcp] hierarchy is now supported, allowing explicit configuration of SIP server addresses for DHCP servers.
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. If you enable PIM on all interfaces using the interface all command, it is not enabled on the me0 and vme interfaces by default. Therefore you do not need not explicitly disable PIM on the management interfaces. Previously, enabling PIM on all interfaces caused it to be enabled on these management interfaces.
164
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches
Limitations in JUNOS Release 10.1 for EX Series Switches
Related Topics
New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174

This section lists the limitations in JUNOS Release 10.1R1 for EX Series switches.
Access Control and Security
When you have configured more than 1024 supplicants on a single interface, 802.1X authentication might not work as expected and the 802.1X process (dot1xd) might fail.
Class of Service
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. On EX4200 switches, the traffic is shaped at rates above 500 kb, even when the shaping rate configured is less than 500 kb. The minimum shaping rate is 500 kb. When the scheduler map bound to an interface is changed, there might be packet drops temporarily in all the interfaces bound to the scheduler map while the configuration change is being implemented.
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. IGMP packets are not matched by user-configured firewall filters.
165
Infrastructure
If you configure interface parameters on an EX3200 or EX4200 switch running JUNOS Release 9.2 or Release 9.3 for EX Series switches and then attempt to upgrade to a later release or a later version of Release 9.3 than the one that is currently installed, the switch might display the following error message: init: interface-control is thrashing , not restarted. As a workaround, on the interfaces you had previously configured, configure no-auto-negotiation and set the link mode to full-duplex, then commit the revised configuration. The RADIUS request sent by an EX Series switch contains both Extensible Authentication Protocol (EAP) Identity Response and State attributes. 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 does not display any output, even though the etherMIB is supported. This occurs because the values are not populated at the module levelthey 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. When you issue the request system power-off command, the switch halts instead of turning off power. 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. In the J-Web interface, changing port roles from Desktop, Desktop and Phone, and Layer 2 Uplink might not remove the configurations for enabling dynamic ARP inspection and DHCP snooping. 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). When an external RADIUS server goes offline and comes back online after some time, subsequent captive portal authentication requests might fail until the authd daemon is restarted. As a workaround, you can configure the revert intervalthe time after which to revert to the primary serverand restart the authd daemon. Momentary loss of an inter-Routing Engine IPC message might trigger the alarm that displays the message Loss of communication with Backup RE. There is no functionality affected.
166
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. The following message might appear in the system log:
Resolve request came for an address matching on Wrong nh nh:355, type:Unicast...?
You can ignore this message.
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. The following interface counters are not supported on routed VLAN interfaces (RVI): local statistics, traffic statistics, and transit statistics. 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. The show interface detail | extensive command might display double counting of packets or bytes for the transit statistics and traffic statistics counters. You can use the counter information displayed under the Physical interface section of the output. When a virtual management Ethernet (VME) interface is used as a default gateway and the VME is the indirect next hop for any route, the route might not change dynamically and could always point to VME interface.
Related Topics
New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174
167
Outstanding Issues in JUNOS Release 10.1 for EX Series Switches

The following are outstanding issues in JUNOS Release 10.1R1 for EX Series switches. The identifier following the description is the tracking number in our bug database.
NOTE: PRs 300576, 403842, 409934, 415569, 415748, 429589, 440611, 455670, and 488318 which were included in the earlier release notes as outstanding issues, have been removed, because these issues are not applicable to JUNOS Release 10.1R1 for EX Series switches.
If you configure the RADIUS server revert-interval interval option, the switch does not attempt to reconnect to the unreachable server after the revert interval has elapsed. [PR/304637]
There might be traffic loss on VLANs learned through MVRP during GRES. After the GRES, there will not be any traffic loss. [PR/458303] On EX Series switches, in a scaled environment with more than 4000 VLANs, MVRP advertisements might not be sent intermittently when the VLAN membership is modified. [PR/475701]
Class of Service
If you are configuring an interface as part of an aggregated Ethernet interface, and also configuring CoS on that interface, do not commit both configurations using a single commit operation. Use separate commit operations to commit the two configurations. [PR/490542]
Firewall Filters
On an EX2200 switch when you add a syslog action modifier to the firewall filter, the pfem process might core dump when the filter binding is changed from an egress VLAN to an ingress VLAN [PR/495572] If an ingress firewall has been configured with a LAG-interface-match condition and you delete this firewall configuration, the pfem process might core dump. When the pfem process is restarted, it works as expected. [PR/504273]
168
Infrastructure
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. As a workaround, clear those MAC addresses from the Ethernet switching table. [PR/451431] Though the interface-range configuration statement is not supported under the [edit groups] hierarchy, an error message might not be displayed when you use the interface-range statement. [PR/453538] On EX8200 switches, when IGMP snooping is enabled on an interface, the IPv6 multicast Layer 2 control frame is not forwarded to other interfaces in the same VLAN. [PR/456700] The jnxFirewall MIB might not be populated in a firewall filter configuration. As a workaround, set up 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]
On EX2200 switches, the MIB OID ipv6Forwarding indicates that IPv6 is supported even though IPv6 is not supported. The value of the ipv6Forwarding.0 MIB object is 1. [PR/473128] 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]
Interfaces
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]
J-Web Interface
In the J-Web interface, you cannot commit some configuration changes in the Ports Configuration page and 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.
169
A VLAN configured to receive analyzer output can be associated with only one port.
[PR/400814]
In the J-Web interface, uploading a software package to the switch might not work properly if you are using Internet Explorer version 7. [PR/424859] 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] 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] In the J-Web interface, in the OSPF Configuration page (Configuration > Routing > OSPF), 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] 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 Results table continues to display page 3 and shows 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] An IPv4 static route configured sing the CLI might not be displayed when you select the Configure -> Routing-> Static Routing option in the J-Web interface. [PR/487597] In the J-Web interface the OSPF Monitoring page might display an error message if there are multiple interfaces/neighbors detected in an autonomous system. [PR/502132]
Related Topics
New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171
170
Resolved Issues in JUNOS Release 10.1 for EX Series Switches
Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174

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.
When both DHCP relay and DHCP snooping are configured on an EX2200 switch, the DHCP snooping database might not be built on the switch. [PR/480682: This issue has been resolved.]
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: This issue has been resolved.] On EX4200 switches with the access interface through which traffic enters the switch configured as trusted (secure-access-port interface interface-name dhcp-trusted), VLAN Spanning Tree Protocol (VSTP) bridge protocol data units (BPDUs) are sent to the Routing Engine with the learning CPU code 37 instead of the reserved learning CPU code 306. [PR/468095: This issue has been resolved.] On EX3200 and EX4200 switches with large VLAN configurations (more than 1024 VLANs), stale dynamic VLAN entries might be found in the Ethernet switching process (eswd) after you delete VLANs or deactivate the Multiple VLAN Registration Protocol (MVRP). [PR/471647: This issue has been resolved.] On an EX2200 switch, when there is no STP or RTG configured in the network and there is traffic looping, after the network loop is broken, sometimes MAC learning might not occur. As a workaround, restart the forwarding (pfem) process. [PR/473454: This issue has been resolved.] When MVRP and VSTP are enabled together on EX Series switches, convergence does not occur between MVRP and VSTP. [PR/477019: This issue has been resolved.] On EX3200 and EX4200 switches, when MVRP dynamic VLAN creation is disabled, deregistration of VLANs on trunk interfaces does not occur even after the tag associated with the VLAN has been modified. [PR/479636: This issue has been resolved.] On EX3200 and EX4200 switches, stale MVRP VLAN membership entries might be found on blocked interfaces even after MVRP has been deactivated on the peer switch. [PR/482126: This issue has been resolved.]
171
Class of Service
On an EX2200 switch, when a queue is oversubscribed and you modify a scheduler with the buffer-size exact option on it such that it reduces the allocated buffers on the queue, the queue can stop dequeueing packets. As a workaround, stop traffic going out on the port, and deactivate and reactivate class of service (CoS). You can also reboot the switch. [PR/481401: This issue has been resolved.]
Firewall Filters
The accept action and the log and syslog action modifiers in the firewall filter configuration might not work as expected for packets destined for the switch. [PR/406714: This issue has been resolved.] On EX3200 and EX4200 switches, if you configure an egress firewall filter with the match condition source-address or destination-address on a VLAN and its routed VLAN interface (RVI), the firewall filter might not work properly. [PR/476626: This issue has been resolved.]
Hardware
On 48-port SFP line cards used in EX8200 switches, do not install a transceiver in the first or last port on the bottom row (ports 1 and 47). Transceivers installed in these ports are difficult to remove. As a workaround, you can remove the transceiver by using a small flathead screwdriver or other tool to lift the lock on the transceiver. [PR/423694: This issue has been resolved.]
Infrastructure
On an EX2200 switch, if the following message is displayed when the switch is booting, the installed package might be corrupted:
mount_check: SHA1 (/packages/jkernel-ex-10.1-20090925.0) = f45dd191b053b608dafecc0ef3ea329c9f85693b !=5fe72546eed0c0cb83e6addc6709720f56e8b6da
As a workaround, reinstall the image from the loader prompt with the -- format option set. [PR/433663: This issue has been resolved.]
The DHCP snooping database is not built after graceful Routing Engine switchover (GRES) is performed twice. Even though packets are coming from the DHCP server, they are not inserted in the DHCP relay. [PR/461318: This issue has been resolved.] If an interface is assigned to a VLAN before the interface's stg state is set, loops might form in the network if a VLAN ID is assigned to the VLAN while the interface is active in a redundant topology. [PR/472617: This issue has been resolved.] On EX8200 switches, after a graceful Routing Engine switchover (GRES), you can navigate through the Maintenance menu in the LCD even after the Maintenance menu in the LCD has been disabled using the set chassis lcd maintenance-menu disable command. As a workaround, delete the LCD
172
Maintenance menu configuration using the CLI on the new master switch, and then disable the LCD Maintenance menu using the set chassis lcd maintenance-menu disable command. [PR/473597: This issue has been resolved.]
In some rare cases, switch bootup fails when the JUNOS Software is loading. The message Device not ready displays because the NAND flash is not responding. Workaround: Power cycle the switch. [PR/482026: This issue has been resolved.] The name of the ethernet-switching-options authentication-whitelist statement will be changed. The new name is correct in the documentation but is shown in the CLI as ethernet-switching-options white-list. [PR/487167: This issue has been resolved.] A memory leak might be present in the pfem SPF database. As a workaround, you can restart the pfem process. [PR/493197: This issue has been resolved.]
J-Web Interface
In the J-Web interface, the Edit MSTI window in the Spanning Tree Configuration page might not display details of an uncommitted interface configuration. [PR/433506: This issue has been resolved.] 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 double-click the Troubleshoot tab. As a workaround, click the Dashboard tab or the Configure tab, and then click the Troubleshoot tab to display the menu and contents of the page. [PR/459936: This issue has been resolved] In the J-Web interface, in the OSPF Configuration page, no flags are displayed for the Traceoptions tab in OSPF Global Settings. [PR/461558: This issue has been resolved.] In the J-Web interface, in the BGP Configuration page (Configuration > Routing > BGP), if the values entered in the text boxes (for protocols, filename, and description) contain double quotation marks, the J-Web interface does not allow you to delete those values. If the value in the Group Name contains double quotation marks, the J-Web interface allows you to delete the BGP group name, but the deleted value reappears when you refresh the BGP Configuration page. As a workaround, delete the values that contain double quotation marks using the CLI. [PR/464030: This issue has been resolved.] When you access the J-Web interface using the Mozilla Firefox Web browser and move a J-Web window (for example, the Add Interface window) over the browser toolbars, the window appears behind the browser toolbars. After this problem occurs, the window cannot be moved, because the title bar of the window is not visible. If you cancel and reopen the window, the window continues to appear behind the browser toolbars. [PR/473238: This issue has been resolved.] In the J-Web interface Static Routing Configuration page, you might not be able to delete a configured next-hop address because the Delete button is disabled. [PR/476572: This issue has been resolved.]
173
Related Topics
New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174
Errata in Documentation for JUNOS Release 10.1 for EX Series Switches

There are no outstanding documentation issues in this release.
Related Topics
New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171 Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches on page 174
Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches
The following pages list the issues in JUNOS Release 10.1R1 for EX Series switches regarding software upgrade or downgrade:
Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series Switches on page 174 Upgrading from JUNOS Release 9.3R1 to Release 10.1 for EX Series Switches on page 175 Upgrading from JUNOS Release 9.2 to Release 10.1 for EX Series Switches on page 175 Downgrading from JUNOS Release 10.1 to Release 9.2 for EX4200 Switches on page 177
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
174
Errata in Documentation for JUNOS Release 10.1 for EX Series Switches
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, 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.1 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.1 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.1. If you do not take these actions, the upgrade will fail:
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.
175
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.1. 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.1. 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 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.
176
Downgrading from JUNOS Release 10.1 to Release 9.2 for EX4200 Switches
When you downgrade a Virtual Chassis configuration from JUNOS Release 10.1 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.
Related Topics
New Features in JUNOS Release 10.1 for EX Series Switches on page 160 Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches on page 164 Limitations in JUNOS Release 10.1 for EX Series Switches on page 165 Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 168 Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 171 Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on page 174
177
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 JUNOS Software 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 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 policiesFor 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 warrantiesFor product warranty information, visit http://www.juniper.net/support/warranty/.
178
JUNOS Documentation and Release Notes
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/.
179
Revision History
17 February 2010Revision 2, JUNOS Release 10.1R1 15 February 2010Revision 1, JUNOS Release 10.1R1
Copyright 2010, Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOSe is a trademark 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.
180

Junos Release Notes 10

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Junos Release Notes 10

Hochgeladen von

Copyright:

Verfügbare Formate

Juniper Networks JUNOS 10.

1 Software Release Notes

JUNOS 10.1 Software Release Notes

JUNOS 10.1 Software Release Notes

JUNOS 10.1 Software Release Notes

JUNOS 10.1 Software Release Notes

[Network Interfaces, Class of Service, PIC Guide]

802.1ah 802.1g 802.1x 802.3ad ARP

GMRP GVRP LACP PVST xSTP

The Layer 3 protocols supporting the preclassifier are:

The Layer 4 protocols supporting the preclassifier are:

The preclassifier is also supported on label-switching encapsulation PPP. [Class of Service]

JUNOS 10.1 Software Release Notes

QoS per virtual LAN (VLAN): (JUNOS Release 10.0R2)

JUNOS 10.1 Software Release Notes

Layer 2 features that are not supported in this release include:

Spanning Tree Protocols (xSTP)

JUNOS 10.1 Software Release Notes

gr-fpc/pic/port vt-fpc/pic/port lt-fpc/pic/port ip-fpc/pic/port pe-fpc/pic/port pd-fpc/pic/port mt-fpc/pic/port

JUNOS 10.1 Software Release Notes

[Network Interfaces, PIC Guide]

JUNOS 10.1 Software Release Notes

JUNOS XML API and Scripting

Response Tag Element

clear dhcpv6 server statistics

clear mpls static-lsp

clear mvrp statistics

clear security idp application-ddos cache

clear security idp status

clear vrrp interface

request system scripts refresh-from

show dhcpv6 server binding

show dhcpv6 server statistics

show mpls static-lsp

show mvrp applicant-state

show mvrp dynamic-vlan-memberships

show mvrp interface

JUNOS 10.1 Software Release Notes

Response Tag Element

show mvrp statistics

show security idp policies

show security idp policy-templates-list

show security idp status detail

show services nat mappings

show task memory

show vrrp interface

show vrrp track

[JUNOS XML API Operational Reference]

JUNOS 10.1 Software Release Notes

[Multiplay Solutions, Services Interfaces]

JUNOS 10.1 Software Release Notes

To configure MBGP MVPNs to use PIM-SSM S-PMSI tunnels in a hub-and-spoke topology:

JUNOS 10.1 Software Release Notes

group-address source source-address pim-ssm] hierarchy level on all PE routers

participating in the MVPN.

[VPNs, Routing Protocols, Routing Protocols and Policies Command Reference]

Subscriber Access Management

JUNOS 10.1 Software Release Notes

DHCP subscriber VLANs

16,000 32,000 64,000 64,000

16,000 64,000 64,000 64,000

PPP logical interfaces

15,999 4000 15,999

63,999 32,000 15,999