Junos Release Notes 10.2

Juniper Networks JUNOS 10.
2 Software Release Notes

Release 10.2R4 10 June 2011 Revision 10
These release notes accompany Release 10.2R4 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 . . . . . 7 New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 JUNOS XML API and Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Layer 2 Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Multiplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Subscriber Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Forwarding and Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 General Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Copyright 2012, Juniper Networks, Inc.
JUNOS 10.2 Software Release Notes
Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 JUNOS XML API and Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Layer 2 Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Platform and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Routing Policy and Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Subscriber Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Current Software Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Previous Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . 118 Changes to the JUNOS Documentation Set . . . . . . . . . . . . . . . . . . . . . . 118 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Basic Procedure for Upgrading to Release 10.2 . . . . . . . . . . . . . . . . . . . . 128 Upgrade Policy for JUNOS Software Extended End-Of-Life Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 130 Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Upgrading the Software for a Routing Matrix . . . . . . . . . . . . . . . . . . . . . 132 Upgrading Using ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Downgrade from Release 10.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Software Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Hardware FeaturesSRX210 Services Gateways . . . . . . . . . . . . . . . . . . 168 Hardware FeaturesSRX240 Services Gateways . . . . . . . . . . . . . . . . . 168 Hardware FeaturesSRX210 and SRX240 Services Gateways with Integrated Convergence Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Hardware FeaturesSRX650 Services Gateways . . . . . . . . . . . . . . . . . 172 Hardware FeaturesSRX3400 and SRX3600 Services Gateways . . . . 173 Advertising Bandwidth for Neighbors on a Broadcast Link Support . . . . . . . 173 Group VPN Interoperability with Ciscos GET VPN . . . . . . . . . . . . . . . . . . . . . 174 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . 175 Application Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Application Layer Gateways (ALGs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 AppSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Command-Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Dynamic VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Flow and Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Interfaces and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Intrusion Detection and Prevention (IDP) . . . . . . . . . . . . . . . . . . . . . . . . 183 J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Management and Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Multilink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Unsupported CLI Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . 188 Accounting-Options Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 AX411 Access Point Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Chassis Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Class-of-Service Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Ethernet-Switching Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Firewall Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Interfaces CLI Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Protocols Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Routing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Services Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Security Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 SNMP Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 System Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 IPv6 and MVPN CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 AppSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Command-Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 DOCSIS Mini-PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Dynamic VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Flow and Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Interfaces and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Intrusion Detection and Prevention (IDP) . . . . . . . . . . . . . . . . . . . . . . . 203 IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 NetScreen-Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Point-to-Point Protocol over Ethernet (PPPoE) . . . . . . . . . . . . . . . . . . 208 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Unified Threat Management (UTM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Outstanding Issues In JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . 211 Resolved Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . 232 Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . 239 Application Layer Gateways (ALGs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Command-Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Flow and Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Hardware Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Installing Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Integrated Convergence Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Interfaces and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Intrusion Detection and Prevention (IDP) . . . . . . . . . . . . . . . . . . . . . . . 248 JUNOS Software Interfaces and Routing Guide . . . . . . . . . . . . . . . . . . . 249 J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Management Information Base (MIB) . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Hardware Requirements for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . 251 Transceiver Compatibility for SRX Series and J Series Devices . . . . . . . 252 Power and Heat Dissipation Requirements for J Series PIMs . . . . . . . . . 252 Supported Third-Party Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 J Series CompactFlash and Memory Requirements . . . . . . . . . . . . . . . . 253 Stream Control Transmission Protocol Overview . . . . . . . . . . . . . . . . . . . . . 254 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Maximizing ALG Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . 256 Upgrade Policy for JUNOS Software Extended End Of Life Releases . . 256 JUNOS Software Release Notes for EX Series Switches . . . . . . . . . . . . . . . . . . . 257 New Features in JUNOS Release 10.2 for EX Series Switches . . . . . . . . . . . . 257 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Bridging, VLANs, and Spanning Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Class of Service (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Layer 2 and Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Management and RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Packet Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Layer 2 and Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 User Interfaces and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Limitations in JUNOS Release 10.2 for EX Series Switches . . . . . . . . . . . . . . 262 Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Bridging, VLANs, and Spanning Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 J-Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Layer 2 and Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Management and RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches . . . . . . . 267 Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Bridging, VLANs, and Spanning Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 J-Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Layer 2 and Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Resolved Issues in JUNOS Release 10.2 for EX Series Switches . . . . . . . . . . . 271 Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Bridging, VLANs, and Spanning Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 J-Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Layer 2 and Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Management and RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches . . 277 Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Upgrade Policy for JUNOS Software Extended End-Of-Life Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Upgrading from JUNOS Release 9.3R1 to Release 10.2 for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Upgrading from JUNOS Release 9.2 to Release 10.2 for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Downgrading from JUNOS Release 10.2 to Release 9.2 for EX4200 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 JUNOS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
JUNOS Software Release Notes for Juniper Networks M Series Multiservice Edge Routers, MX Series Ethernet Service Routers, and T Series Core Routers
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.2 for M Series, MX Series, and T Series Routers on page 7 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 45 Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63 Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers on page 118 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 127
New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers
The following features have been added to JUNOS Release 10.2. Following the description is the title of the manual or manuals to consult for further information.
Class of Service
Support for Layer 2 policers at the VLAN level on Trio MPC/MIC interfaces (MX Series platforms with Trio MPC/MIC interfaces)Layer 2 policers at the VLAN level are supported on an MX Series router with Trio MPCs/MICs. [Class of Service]
Different classifiers for different virtual circuits (ATM interfaces)Enables you to combine Layer 2 and Layer 3 classifications on ATM interfaces where some VCs are part of a VPLS instance and other belong to an L3VPN. To configure, include the classifiers statement at the [edit class-of-service interfaces at-x/y/zunit logical-interface-number] hierarchy level. [Class of Service]
DSCP classification for VPLS at ingress PE (M320 with Enhanced Type III FPC and M120)Enables you to configure DSCP classification for VPLS at ingress PE for encapsulation types vlan-vpls (IQ2 or IQ2E PICs) or ATM II IQ PIC. To configure, define the DSCP classifier at the [edit class-of-service classifiers dscp dscp-name] hierarchy level and apply the DSCP classifier at the [edit interfaces at-fpc-pic-port unit-logical-unit-number classifiers] hierarchy level. The ATM interface must be included in the routing instance. [Class of Service]
High Availability
Nonstop active routing support for Layer 2 VPN and Layer 3 VPN over RSPV-TE LSPsStarting with Release 10.2, the JUNOS Software extends the nonstop active routing support to Layer 2 VPN and Layer 3 VPN over RSVP-TE LSPs. JUNOS Release 10.2 also extends the nonstop active routing support for Layer 3 VPNs to cover the following OSPF features and configurations:
domain-id domain-id statement at the [edit routing-instances routing-instance-name protocols (ospf | ospf3)] hierarchy level
domain-vpn-tag number statement at the [edit routing-instances routing-instance-name protocols (ospf | ospf3)] hierarchy level
metric number statement at the [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote] hierarchy level
sham-link local address statement at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level
sham-link-remote address <metric number> statement at the [edit routing-instances routing-instance-name protocols ospf area area-id] hierarchy level
Interfaces and Chassis
List of supported software features for MX Series MPCsThe following link contains a high-level list of software features for MX Series MPCs. For information about MPC support for subordinate statements of these software features, see the JUNOS Layer 2 Configuration Guide.
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/ general/mpc-mx-series-features.html
New 2-port MIC with XFP (model number MIC-3D-2XGE-XFP)This MIC can be installed into the new Type 1 MPCs (supported on MX240, MX480, MX960 routers) or can be installed directly into two slots in a modular MX80 chassis. For a list of supported MICs and MPCs, see the MX Series Line Card Guide. New 30-Gigabit Ethernet queuing MPC (model number MX-MPC1-3D-Q)Supported on MX240, MX480, and MX960 routers. For a list of supported MPCs, see the MX Series Line Card Guide. New 30-Gigabit Ethernet MPC (model number MX-MPC1-3D)Supported on MX240, MX480, and MX960 routers. For a list of supported MPCs, see the MX Series Line Card Guide. New 40-port dual-wide Tri-rate MIC (model number MIC-3D-40GE-TX)Supported on the MX Series routers. The Tri-rate MIC contains 40 autonegotiating 10Base-T, 100Base-TX, or 1000Base-T Megabit Ethernet ports. The Tri-rate MIC installs into both slots of an MPC in a MX240, MX480, and MX960 routers or directly into two slots in a modular MX80 chassis. For a list of supported MICs and MPCs, see the MX Series Line Card Guide.
Modular Port Concentrators (MPCs) on MX240, MX480, and MX960 routersProvide tunnel support parity, replacing traditional tunnel and services PICs with tunnels that were supported on a "virtual" port on MX240, MX480, and MX960 PFEs. MX240, MX480, MX960 routers support a virtual PIC and a virtual port, visible for tunnel configuration, and eliminating the need for a tunnel PIC. Traditional tunnel PIC features are supported, including:

GRE keys GRE Clear-dont-fragment
Certain services PIC features are not supported. On MPCs there are no tunnel PICs. Instead some bandwidth is taken off the WAN ports from the MX240, MX480, and MX960 routers and reserved for tunneling. In the presence of tunnel traffic, all WAN ports are affected in case of oversubscription. On MX240, MX480, and MX960 routers, the following types of tunnel ports are supported:

A 1Gbps tunnel port on 10x1GE PFE complex A 10Gbps tunnel port on 1x10GE PFE complex
On MX240, MX480, and MX960 routers, tunnel services can be enabled by configuring tunnel-services bandwidth on a particular virtual PIC. For example:
user@host# show chassis fpc 0 { pic 0 { tunnel-services { bandwidth 1g; } } pic 1 { tunnel-services { bandwidth 1g; } } }
This enables tunnel services with a bandwidth of 1 Gbps on FPC 0 and PIC 0. Correspondingly, chassisd can create devices such as the following:

vt-0/0/10, ip-0/0/10, etc. for pic0 vt-0/1/10 ip-0/1/10 etc. for pic1
Currently supported bandwidth values are 1 Gbps and 10 Gbps. Devices are created with port 10 for 1-Gbps tunnels and port 0 for 10-Gbps tunnels. These tunnels with their associated configurations work when an MX-DPC is replaced by an MPC. This means the router creates tunnel devices based on the tunnel services configuration. This means that although the same PFE supports vt-0/0/10 and vt-0/1/10, two devices must be created to be compatible with the above configuration.
The MPC allows you to configure four tunnel MICs per MPC (to support vt-0/0/10, vt-0/1/10, vt-0/2/10, and vt-0/3/10), although in reality there are only two physical MICs. This is achieved by creating logical MICs on MPCs. In addition, you can add physical interfaces to the MPC because no MICs are associated with these tunnel physical interfaces. [Services Interfaces]
Restrictions on NAT configuration on DPCs (MX960, MX480, and MX240 routers with Multiservices DPC services interfaces)If you configure a basic 1:1 destination NAT rule with address prefixes in the pool, NAT will not work as expected. Also, if you configure port allocation for all NAT translations with a redundancy services (RSP) interface, NAT will not work as expected. [Services Interfaces]
Voice over IP (VoIP) servicesIn JUNOS Release 10.2, MX Series MPCs support Border Gateway Function (BGF) and Integrated Multi-Service Gateway (IMSG). For a list of supported protocols and applications, see the MX Series Line Card Guide. Support for Layer 2 Ethernet OAM (MX Series routers with Trio MPC/MIC Ethernet interfaces)MX Series routers with Trio MPC/MIC Ethernet interfaces supports parity of all Layer 2 OAM for 802.1ag for inet family features supported by MX Series routers as of JUNOS Release 9.1. [Network Interfaces]
Support for MPC tunnel features with other DPC types (MX Series platforms with Trio MPC/MIC interfaces)If you configure tunnels on an MX Series router with both Trio MPCs/MICs and DPCs, all tunnel functions support parity with JUNOS Release 9.2. [Network Interfaces]
Enhanced IQ (IQE) PICs for M7i and M10i routersM7i and M10i routers now support the following Enhanced IQ (IQE) PICs:

4-port Channelized DS3 and E3 Enhanced IQ (IQE) PIC (PE-4CHDS3-E3-IQE-BNC) 10-port Channelized E1/T1 Enhanced IQ (IQE) PIC (PE-10CHE-T1-IQE-RJ48) 2-port Channelized OC3/STM1 Enhanced IQ (IQE) PIC with SFP (PE-2CHOC3-STM1-IQE-SFP) 1-port Channelized OC12/STM4 Enhanced IQ (IQE) PIC with SFP (PE-1CHOC12STM4-IQE-SFP) 4-port DS3/E3 Enhanced IQ (IQE) PIC (PE-4DS3-E3-IQE-BNC) 4-port SONET/SDH OC3/STM1 Enhanced IQ (IQE) PIC with SFP (PE-4OC3-STM1-IQE-SFP) 1-port SONET/SDH OC12/STM4 Enhanced IQ (IQE) PIC with SFP (PE-1OC12-STM4-IQE-SFP)
10
The IQE PICs support the same features as the existing IQ PICs, as well as enhanced CoS and diagnostic features. The valid configuration statements are also the same, but the limits and range of values for some options are different to support augmented capabilities. [M7i PIC Guide, M10i PIC Guide, Class of Service, Network Interfaces]
New MX80 Ethernet services routerThere are two MX80 routers: one with a modular chassis and one with a fixed chassis. Each router is a compact Ethernet-optimized edge router that provides provide switching and carrier class Ethernet routing. Both provide up to 40 gigabits per second (Gbps) full duplex, high-density Ethernet interfaces and high capacity switching throughput. Both use the Trio chipset for increased scalability of L2/L3 packet forwarding, buffering, and queuing. Each router supports parity in software features supported by other MX Series routers as of JUNOS Release 9.2. To view JUNOS Release 9.2 documentation, see: http://www.juniper.net/techpubs/software/junos/junos92/index.html. The show chassis family of commands has been updated to provide information about MX80 routers.
NOTE: The MX80 router with fixed configuration does not support hierarchical queuing, congestion dropping, or statistics.
The MX80 router with modular configuration includes four built-in 10-Gigabit Ethernet ports and two slots that support the following Modular Interface Cards (MICs):

20-port Gigabit Ethernet MIC with SFP 2-port 10-Gigabit Ethernet MIC with XFP 40-port Gigabit Ethernet MIC (dual-wide)
The MX80 router with fixed configuration includes 4 built-in 10-Gigabit Ethernet ports and 48 built-in 10/100/1000Base-TX-RJ45 ports. The MX80 router is a single-board router with a built-in Routing Engine and one Packet Forwarding Engine (PFE), which can have up to two MICs. (A Services PIC slot is currently not supported.) The PFE has two pseudo Flexible PIC Concentrators (FPC 0 and FPC1). Because there is no switching fabric, the single PFE takes care of both ingress and egress packet forwarding. On both routers, the four built-in 10-Gigabit Ethernet ports are mapped to FPC 0. On the MX80 router with modular configuration, the MIC slots are mapped to FPC 1. On the MX80 router with fixed configuration, the 48 built-in 10/100/1000Base-TX-RJ45 ports are mapped to FPC 1. [MX80 Hardware]
Tunable XFP support (MX960, MX480, MX240, T640, and T1600)Provides support for wavelength tunable non-optical transport network (OTN) 10Gigabit Ethernet XFPs. All forwarding, OAM, and control plane features supported on the current DPCs, MICs, and PICs are supported on the above routers. This feature is not supported on MX80 and T320 routers.
11
You can use the existing wavelength statement to configure the wavelength of the optics at the [edit interfaces interface-name optic-options] hierarchy level. The following existing configuration mode commands are supported for tunable XFPs:

show chassis hardware show chassis pic show interfaces
[Network Interfaces]
Support for external clock synchronization on T Series routers (T320, T640, T1600)The T320, T640, and T1600 routers support external clock interfaces on the Sonic Clock Generators (SCG). When external clock synchronization is configured, this clock is distributed through the FPCs to each PIC interface. To configure external clock synchronization, include the following statements at the [edit chassis] hierarchy level:
synchronization { primary (external-a | external-b); secondary (external-s | external-b); switching-mode (revertive | non-revertive); validation-interval seconds; }
[System Basics]
Support for 802.1ag Ethernet OAM for VPLS extended to M320 (with Enhanced III FPC), M120, and to M10i and M7i (with CFEB) routers with Gigabit Ethernet IQ2, IQ2E, and IQ2E PICsExtends the 802.1ag VPLS functionality to the specified routers. 802.1ag was previously supported only on Layer 2 circuits, Layer 2 VPNs, and routable interfaces on the specified router, FPC, and interface combinations. Configuration for this feature is performed in the same way as the existing OAM VPLS CLI feature configuration on MX Series routers. To configure CFM, include the connectivity-fault-management statement and substatements at the [edit protocols oam ethernet] hierarchy level. [Network Interfaces]
Quality-of-service (QoS) support for ATM on circuit emulation PICsOn M7i, M10i, M40e, M120, and M320 routers, the Channelized OC3/STM1 Circuit Emulation PICs (PB-4CHOC3-CE-SFP and PE-4CHOC3-CE-SFP) and E1/T1 Circuit Emulation PICs (PB-12T1E1-CE-TELCO and PE-12T1E1-CE-TELCO) provide QoS features that match or exceed those of the ATM-II PIC. Circuit Emulation PICs provide ingress and egress direction traffic shaping. Policing is performed by monitoring the configured parameters on the incoming traffic and is also referred to as ingress shaping. Egress shaping uses queuing and scheduling to shape the outgoing traffic. This is an enhancement over the ATM-II PIC, which only provides egress shaping. Classification is provided per virtual circuit (VC).
12
The following features are supported:

Port-level egress shaping Support for CBR, rtVBR, nrtVBR, and UBR Policing on a per VC basis Independent PCR and SCR policing Counting, tagging, or discard policing actions
CLI configuration is similar to that of QoS features for the ATM-II PIC. To configure shaping for logical interfaces in port promiscuous mode, use the shaping statement and its substatements at the [interfaces at-fpc/pic/port unit] hierarchy level. [Network Interfaces]
Enhanced graceful Routing Engine switchover (GRES) support for PD-5-10XGE-SFPP PICs (T640 routers connected to a TX Matrix router)JUNOS Release 10.2 extends GRES support for 10-port 10-Gigabit Ethernet Oversubscribed Ethernet PIC (PD-5-10XGE-SFPP) in T640 routers connected to a TX Matrix router. Targeted broadcast support for virtual routing and forwarding (VRF) (M Series, MX Series, and T Series routers)Enables IP packets destined for a Layer 3 broadcast address to transit to an egress interface on a router. The packets are broadcast only if the egress interface is a LAN interface. This feature is useful when the Routing Engine is flooded with packets to process. Targeted broadcast enables a broadcast packet destined for a remote network to transit across networks until the destination network is reached. In the destination network, the broadcast packet is broadcast as a normal broadcast packet. To configure targeted broadcast on a broadcast interface, include the targeted-broadcast statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level. You can configure targeted broadcast in two ways:
To forward broadcast packets to both the egress interface and the Routing Engine, include the forward-and-send-to-re statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level. To forward broadcast packets to the egress interface only, include the forward-only statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.
When you do not include the targeted-broadcast statement, a copy of each broadcast packet is sent to the Routing Engine. When you include the targeted-broadcast statement without either the forward-and-send-to-re or forward-only statement, broadcast packets are discarded. [Network Interfaces]
High availability hot-standby for FRF.15 (MLFR) and FRF.16 (MFR) configurations on Multiservices PICs and DPCs (M Series, MX Series, and T Series routers)Extends
13
support for the hot-standby option to FRF.15 and FRF.16 on redundant paired LSQ interfaces. This feature is supported on Multiservices PICs and DPCs. Provides a switchover time of 5 seconds or less for FRF.15, and provides a maximum of 10 seconds switchover time for FRF.16. To configure redundant LSQ hot-standby functionality for FRF.15, configure the hot-standby statement at the [edit interfaces rlsqnumber redundancy-options] hierarchy level and the multilink-frame-relay-end-to-end statement at the [edit interfaces rlsqnumber unit logical-unit-number encapsulation] hierarchy level. To configure redundant LSQ hot-standby functionality for FRF.16, include the hot-standby statement at the [edit interfaces rlsqnumber:number encapsulation multilink-frame-relay-uni-nni redundancy-options] hierarchy level. [Services Interfaces]
M7i, M10i, M120, and M320 routers (with Enhanced III FPC) support ATM scheduler for RFC1483 bridged interfaceExtends ATM scheduler support for RFC1483 bridged interface functionality to the specified routers. [Network Interfaces]
Support for xSTP on Trio MPC/MIC interfaces (MX Series platforms with Trio MPC/MIC interfaces)All types of xSTPs are supported on an MX Series router with Trio MPCs/MICs. [Layer 2 Configuration Guide]
Support for targeted broadcast for virtual routing and forwarding (VRF) instances on MX Series routersThe MX960, MX480, and M240 routers now support targeted broadcast which IP packets destined for a Layer 3 broadcast address to transit to an egress interface on a router. The packets are broadcast only if the egress interface is a LAN interface. This feature is supported on aggregated Ethernet interfaces and is useful when the Routing Engine is flooded with packets to process. Targeted broadcast enables a broadcast packet destined for a remote network to transit across networks till the destination network is reached. In the destination network, the broadcast packet is broadcast as a normal broadcast packet. To configure targeted broadcast on a broadcast interface, include the targeted-broadcast statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level. You can configure targeted broadcast in two ways:
To forward broadcast packets to both the egress interface and the Routing Engine, include the forward-and-send-to-re statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level. To forward broadcast packets to the egress interface only, include the forward-only statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.
When you do not include the targeted-broadcast statement, a copy of each broadcast packet is sent to the Routing Engine. When you include the targeted-broadcast
14
statement without either the forward-and-send-to-re or forward-only statement, broadcast packets are discarded. [Network Interfaces]
New statement to sync the FPC that is brought online with other active FPCs (M320, T320, T640, T1600, TX Matrix, and TX Matrix Plus routers)M320, T320, T640, T1600, TX Matrix, and TX Matrix Plus routers now support the fpc-resync configuration statement at the [edit chassis] hierarchy level. When you bring a Flexible PIC Concentrator (FPC) online, the sequence number on the FPC may not be synchronized with the other active FPCs in the router, which may result in the loss of a small amount of initial traffic. To avoid any traffic loss, include the fpc-resync statement at the [edit chassis] hierarchy level. This ensures that the sequence number of the FPC that is brought online is resynchronized with the other active FPCs in the router. [System Basics]
15
JUNOS XML API and Scripting
16
New JUNOS XML API operational request tag elementsTable 1 on page 17 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 10.2, 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.2
Request Tag Element
<clear-service-bsg-registrations> clear_service_bsg_registrations <clear-service-bsg-registrations-statistics> clear_service_bsg_registrations_statistics <clear-services-bsg-registrations-subscription> clear_services_bsg_registrations_subscription <get-syslog-facility-information> get_syslog_facility_information <request-ping-rsvp-dynamic-bypass-lsp> request_ping_rsvp_dynamic_bypass_lsp <request-ping-rsvp-manual-bypass-lsp> request_ping_rsvp_manual_bypass_lsp <request-logout-user> request_logout_user <get-environmentpower-supply-unitinformation> get_environment_ power_supply_unit_information <get-fm-topology> get_fm_topology <get-fm-plane-location-information> get_fm_plane_location_information <get-fru-power-on-sequence> get_fru_power_on_sequence <get-power-budget-information> get_power_budget_information <get-tfeb-information> get_tfeb_information <get-vcpu-information> get_vcpu_information <get-cos-service-session-information> get_cos_service_session_information
CLI Command
clear services border-signaling-gateway registrations clear services border-signaling-gateway registrations statistics clear services border-signaling-gateway registrations subscription help syslog facility
Response Tag Element

<clear-service-bsg-registrations>
<clear-service-bsg-registrations>
<clear-services-bsg-registrations-subscription>
<syslog-tag-information>
ping mpls rsvp dynamic-bypass
NONE
ping mpls rsvp manual-bypass
NONE
request system logout
<logout-user>
show chassis environment power-supply-unit
<environment-component-information>
show chassis fabric map show chassis fabric plane-location
<fm-topology> <fm-plane-location-information>
show chassis power sequence
<fru-power-on-sequence>
show chassis power-budget-statistics
<power-budget-information>
show chassis tfeb
<scb-information>
show chassis vcpu
<vcpu-information>
show class-of-service service-session
<cos-service-session-information>
17
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.2 (continued)
Request Tag Element
<get-gre-ka-information> get_gre_ka_information <get-pppoe-session-information> get_pppoe_session_information <get-r2cp-interface-information> get_r2cp_interface_information <get-r2cp-radio-information> get_r2cp_radio_information <get-r2cp-session-information> get_r2cp_session_information <get-r2cp-statistics> get_r2cp_statistics <get-serviceaccounting-errorinline-jflowinformation> get_service_ accounting_error_ inline_jflow_ information <get-serviceaccounting-status-inlinejflow-flow-information> get_service_ accounting_status_ inline_jflow_ flow_information <get-serviceaccounting-status-inlinejflow-information> get_service_ accounting_status_ inline_jflow_ information <get-serviceborder-signalinggateway-addressof-record> get_service_ border_signaling_ gateway_address_ of_record
CLI Command
show oam gre-keepalive

<oamd-information>
show pppoe sessions
<pppoe-session-information>
show r2cp interfaces
<r2cp-interface-information>
show r2cp radio
<r2cp-radio-information>
show r2cp sessions
<r2cp-session-information>
show r2cp statistics
<r2cp-statistics>
show services accounting errors inline-jflow
<service-accouting-inline-jflow-error-infomation>
show services accounting flow inline-jflow
<service-accouting-inline-jflow-flow-infomation>
show services accounting status inline-jflow
<service-accouting-inline-jflow-information>
show services border-signaling-gateway address-of-record
<bsg-address-of-records>
18
Request Tag Element
<get-service-bordersignaling-gatewayaddress-ofrecord-bindings> get_service_ border_signaling_ gateway_address_ of_record_ bindings <get-serviceborder-signaling-gatewaystatistics-calls-by-server> get_service_border_ signaling_gateway_ statistics_calls_ by_server <get-serviceborder-signalinggateway-statisticscalls-by-sp> get_service_ border_signaling_ gateway_statistics_ calls_by_sp <get-serviceborder-signaling-gatewaystatistics-calls-duration -by-server> get_service_border_ signaling_gateway_ statistics_calls_ duration_by_server <get-serviceborder-signaling-gatewaystatistics-calls-duration-bysp> get_service_border_signaling _gateway_statistics_calls_ duration_by_sp <get-serviceborder-signaling-gatewaystatistics-failedcalls-by-server> get_service_ border_signaling_gateway_ statistics_failed_calls_by_ server
CLI Command
show services border-signaling-gateway address-of-record bindings

<bsg-address-of-record-bindings>
show services border-signaling-gateway calls by-server
NONE
show services border-signaling-gateway calls by-service-point
NONE
show services border-signaling-gateway calls-duration by-server
NONE
show services border-signaling-gateway calls-duration by-service-point
NONE
show services border-signaling-gateway calls-failed by-server
NONE
19
Request Tag Element
<get-service-border-signaling-gateway -statistics-failedcalls-by-sp> get_service_ border_signaling_gateway _statistics_failed_calls_ by_sp <get-servicebsg-registrations> get_service_ bsg_registrations <get-servicebsg-registrationsrealm-statistics> get_service_bsg_ registrations_ realm_statistics <get-servicebsg-registrationsstatistics> get_service_ bsg_registrations_ statistics <get-service-bordersignaling-gatewayrouting-blacklist> get_service_ border_signaling_ gateway_routing_ blacklist <get-servicesoftwire-tableinformation> get_service_ softwire_table_ information <get-servicefwnat-flowtable-information> get_service_ fwnat_flow_table_ information <get-subscriberssummary> get_subscribers_ summary <get-systemstorage-partitions> get_system_ storage_partitions
CLI Command
show services border-signaling-gateway calls-failed by-service-point

NONE
show services border-signaling-gateway registrations
<bsg-registrations>
show services border-signaling-gateway registrations realm
<bsg-registrations-realm>
show services border-signaling-gateway registrations statistics
<bsg-registrations>
show services border-signaling-gateway routing-blacklist
<bsg-routing-blacklist>
show services softwire
<service-softwire-table-information>
show services softwire flows
<service-fwnat-flow-table-information>
show subscribers summary
<subscriber>
show system storage partitions
<system-storage-information>
20
Request Tag Element
<get-systemvirtual-memoryinformation> get_system_ virtual_memory_information
CLI Command
show system virtual-memory

<system-virtual-memory-information>
[JUNOS XML API Operational Reference]
Layer 2 Ethernet Services
Ethernet Ring Protocol (ERP) support for multiple ring instances on the same physical ring (MX240, MX480, and MX960 routers)This Layer 2 feature extends Ethernet Ring Protocol (ERP) support to include multiple ring instances on the same physical ring on MX960, MX480, and MX240 routers. Each ring instance will control a set of virtual LAN (VLAN) IDs. For a physical ring, traffic between two nodes usually follows the same path. By creating multiple ring instances, some traffic passes through one path, while other traffic can pass through a different path. The result is improved load-balancing of traffic in the physical ring. To configure multiple ring instances, include the data-channel configuration statement with VLAN ID options at the [edit protocols protection-group ethernet-ring group-name] hierarchy level. New operational mode commands support this feature. To display data channel information for all Ethernet ring protection groups, use the show protection-group ethernet-ring data-channel command. To display data channel information for a specific Ethernet ring protection group, use the show protection-group ethernet-ring data-channel groupname command. To display data channel VLAN information for all Ethernet ring protection groups, use the show protection-group ethernet-ring vlan command. To display data channel VLAN information for a specific Ethernet ring protection group, use the show protection-group ethernet-ring vlan groupname command. [Layer 2 Configuration, Interfaces Command Reference]
MPLS Applications
Switching LSPs away from a network nodeYou can configure the router to switch active LSPs away from a network node by using a bypass LSP enabled for an interface. This feature can be used in maintenance of active networks when a network device needs to be replaced without interrupting traffic passing through the network. The LSPs can be either static or dynamic. You need to first configure either link or node protection for the traffic that needs to pass around the network device you intend to disable. To function properly, the bypass LSP must use a different logical interface, rather than the protected LSP. To configure the router to switch traffic around a network node, configure the always-mark-connection-protection-tlv statement at the [edit protocols mpls interface interface-name] hierarchy level. This statement marks all OAM traffic transiting this interface in preparation for switching the traffic to an alternate path based on the OAM
21
functionality. Next, configure the switch-away-lsps statement at the [edit protocols mpls interface interface-name] hierarchy level. This statement switches the traffic from the protected LSP to the bypass LSP, effectively bypassing the default downstream network device. The actual link is not brought down by this procedure itself. This feature is supported on MX Series routers only. [MPLS]
MPLS support on services PICsAdds MPLS label pop support for services PICs on JUNOS routers. Previously, all MPLS traffic would be dropped at the services PIC. No changes are required to CLI configurations for this enhancement. In-service software upgrade (unified ISSU) is supported for tag next hops for MPLS on services PIC traffic, but no support is provided for tags over IPv6 packets or labels on multiple gateways. [MPLS]
Hello acknowledgements for non-session RSVP neighborsYou can now acknowledge hello messages sent from non-session RSVP neighbors with a hello acknowledgement message by including the hello-acknowledgements statement at the [edit protocols rsvp hello-acknowledgements] hierarchy level. When hellos are received from non-session neighbors, an RSVP neighbor relationship is created and periodic hello messages can now be received from the non-session neighbor. Interface-based neighbors are not automatically aged out. [MPLS]
Multicast
Load-balancing multicast tunnel interfaces among available PICsFor draft-rosen Layer 3 VPNs, enables you to manually load-balance multicast tunnel interfaces across a configured list of tunnel-capable PICs. To configure the list, include the tunnel-devices statement at the [edit routing-instances instance-name protocols pim] hierarchy level. In some cases, you might need to manually force a rebalanced state. To do this, run the request pim multicast-tunnel rebalance command with or without the instance option. [Multicast]
Automatic Multicast Tunneling (AMT) supportAutomatic Multicast Tunneling (AMT) facilitates dynamic multicast connectivity between multicast enabled networks across islands of unicast-only networks. This enables service providers, content providers, and their customers that do not have multicast connectivity end-to-end, to participate in delivering multicast traffic. AMT dynamically establishes unicast-encapsulated tunnels between well-known multicast-enabled relay points (AMT relays) and network points reachable only through unicast (AMT gateways). The AMT protocol provides for discovery and handshaking between relays and gateways to establish tunnels dynamically without requiring explicit per-tunnel configuration. AMT relays are typically routers with native IP multicast connectivity that aggregate a potentially large number of AMT tunnels.
22
AMT gateways are devices that require connection to the IP multicast network but lack multicast routing capability or direct connection to multicast-capable routers. Gateways may be either individual hosts or routers that are partitioned from the larger multicast infrastructure. AMT is described in detail in Automatic IP Multicast Without Explicit Tunnels (AMT), draft-ietf-mboned-auto-multicast-09.txt.
NOTE: Multicast sources located behind AMT gateways are not supported.
To configure the AMT protocol, include the amt configuration statement at the [edit protocols] hierarchy level.
amt { traceoptions { file ... flag all; flag errors; flag normal; flag packets; flag tunnels; } relay { family { inet { local-address ip-address; anycast-prefix ip-prefix/ip-prefix-len; } } secret-key-timeout minutes; tunnel-limit number; } } }
To configure the IGMP attributes of AMT relay tunnels, include the amt configuration statement at the [edit protocols igmp] hierarchy level.
igmp { amt { relay { defaults { (accounting | no-accounting); group-policy [ policy-names ]; ssm-map ssm-map-name; version version-number; query-interval interval-seconds; query-response-interval interval-seconds; robust-count count; } } } } }
23
AMT logical interfaces are created dynamically and have an interface identifier in the format ud-FPC/PIC/port.unit. To display tunnel state information for active AMT tunnels, use the show amt tunnel operational mode command. To display AMT protocol message counts and error statistics, use the show amt statistics operational mode command. To display the multicast source and group addresses for an interface, use the show igmp group terse operational mode command. To display gateway IP addresses and UDP port numbers for AMT logical interfaces, use the show interfaces detail operational mode command. To display default parameters for active AMT interfaces, use the show igmp interface operational mode command. To clear AMT tunnel states, use the clear amt tunnel operational mode command. [Multicast, Network Interfaces]
Internet Group Management Protocol (IGMP) snooping support for multichassis link aggregation group (MC-LAG) interfacesMultichassis link aggregation group (MC-LAG) enables a device to form a logical LAG interface with two or more network devices. You can use multicast snooping over MC-LAG interfaces to replicate join and leave messages between MC-LAG peer devices to facilitate faster recovery of membership information after a service interruption. Add the multichassis-lag-replicate-state statement at the [edit multicast-snooping-options] hierarchy level to enable snooping for MC-LAG interfaces. This feature supports dual-link MC-LAG interfaces in an active-standby mode, in which only one link is in active mode and the other is in standby mode at any given time. In MC-LAG, if a standby link takes over as the active link, it can recover the membership information of the interface from the network by generating an IGMP query. However, this recovery can take between 1 and 10 seconds, which is too long for some applications. To keep service restoration time to a minimum, the active link can use IGMP snooping to replicate membership information to the standby link. In the active-standby mode, join and leave messages are sent only through the active member link. Once the messages are received by the active link, they are flooded to all router interfaces, and forwarding entries are built for the received messages. Additionally, the messages are replicated from the active link to the standby link, using an Interchassis Communication Protocol (ICCP) connection. The standby link applies routine processing to the replicated packet, except that it does not add itself as the next hop for any route, and it does not send the replicated packet to the network. After a failover, the multicast membership status of the link can be recovered within a few seconds or less by retrieving the replicated messages. This recovery is much faster than the 10second outage that can occur if the recovery procedure relies only on IGMP queries. When this feature is enabled, multicast snooping automatically identifies the active link during initialization and failover, and runs without any administrator intervention.
24
If the user deletes the configuration of IGMP snooping or deletes the multichassis-lag-replicate-state statement, this feature is disabled on that MC-LAG link or on the whole IGMP snooping domain. The active device stops replicating IGMP messages to the peer, and the IGMP data already installed on the standby device times out. Use the show igmp snooping interface and show igmp snooping membership commands to display group information on both the active side and the standby side of an MC-LAG interface. If the ICCP connection is lost, both links of the MC-LAG transition to the active state, and the client device starts load-balancing traffic between the two links. In this situation, the IGMP messages are not replicated. [Multicast, Network Interfaces]
Internet multicast using ingress replication provider tunnelsA new routing instance type uses existing JUNOS Software technology and ingress replication provider tunnels to carry IP multicast data between routers through an MPLS cloud. This enables a faster path for multicast traffic between sender and receiver routers in large-scale implementations. This configuration is available under PIM and multicast virtual private network (MVPN) infrastructure. The topology consists of routers on the edge of the IP multicast domain that have a set of IP interfaces and a set of MPLS core-facing interfaces. Internet multicast traffic is carried between the IP routers using ingress replication provider tunnels (data plane) and a full-mesh IGBP session (control plane) through the MPLS cloud. The new mpls-internet-multicast routing instance type is configured for the default master instance on each router to support internet multicast over MPLS. When using PIM as the multicast protocol, the mpls-internet-multicast configuration statement is also included at the [edit protocols pim] hierarchy level in the master instance to associate PIM with the mpls-internet-multicast routing instance. The mpls-internet-multicast routing instance is a non-forwarding instance used only for control plane procedures; it does not support any interface configurations. All multicast and unicast routes used for internet multicast are associated only with the master instance (inet.0), not with the routing instance. Each router participating in internet multicast must be configured for BGP MPLS-based internet multicast for control plane procedures. Support for an ingress replication provider tunnel is also configured on all routers to form a full mesh of MPLS point-to-point label-switched paths (LSPs) for the data provider tunnel. The technology standard used is BGP/MPLS IP MVPN, sometimes referred to as next generation. The multicast IP traffic is encapsulated by the routers and carried to other routers over the LSPs formed by the ingress replication provider tunnel. These LSPs can be existing LSPs or triggered dynamically when the routers use autodiscovery. The ingress replication tunnel can be inclusive or selective, depending on the provider tunnel configuration in the routing instance. Additionally, the ingress replication provider tunnel can be configured to create a new tunnel or to use an existing tunnel when an application requests to add a destination. [Multicast]
25
Multiplay
Integrated Multi-Service Gateway (IMSG) access mode support (VoIP subscriber management)The border signaling gateway (BSG) now provides access mode support, which includes:

Recording of subscriber registrations Tracking of subscriber address of record (AOR)
Access mode support enables the deployment of the BSG in a service providers border with large business enterprises, small offices, and home networks. The BSG enables endpoints and IPBXs to register for SIP service with the carrier/service providers registrar. Access mode support also enables new transaction policies to filter incoming messages based on their registration state. You can now configure additional filtering of incoming messages by entering the uri-hiding and registration-state statements for contacts and request URIs at the [edit
services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name from] hierarchy level.
Signaling realms are assigned to the messages handled by service points. The default signaling realm for a subscribers messages is the ingress service point of their register message, so it is not usually necessary to explicitly define signaling realms. However, you may want to assign signaling realms to accumulate information about messages flowing through different service points used by the same customer. When a customer receives services through multiple service points, information on the overall service provided can be accumulated by assigning the same signaling realm to new transaction policies at each service point. You configure signaling realms that can be used in new transaction policies by entering the signaling-realms statement at the [edit services border-signaling-gateway gateway-name sip] hierarchy level. You configure how messages are associated with a signaling realm by entering the signaling-realms statement at the [edit services
border-signaling-gateway gateway-name sip new-transaction-policy term term-name]
hierarchy level. You can display information about subscriber registrations, address of record, and signaling realm assignments by using one of the following commands:

show services border-signaling-gateway address-of-record bindings show services border-signaling-gateway registrations
You can clear registration statistics by using the following commands:

clear services border-signaling-gateway registrations statistics show services border-signaling-gateway registrations subscription
[Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]
Integrated Multi-Service Gateway (IMSG) redirection of messages to contact addressWhen the border signaling gateway (BSG) receives a 3XX response, it now
26
sends a redirected request using a request URI based on the contact information in the 3XX response. You can specify the maximum number of recursive redirection attempts allowed before sending a 408 timeout response by entering the recursion-limit statement at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then on-3xx-response] hierarchy level. Requests are not redirected for 380 responses. [Multiplay Solutions, Services Interfaces]
Integrated Multi-Service Gateway (IMSG) support for up to four border signaling gateways (BSGs) on a routerYou can now configure up to four border signaling gateways on a router. Each BSG must be defined on a separate Multiservices PIC. [Session Border Control Solutions]
Integrated Multi-Service Gateway (IMSG) border signaling gateway (BSG) server clustersServer clusters allow routing incoming transactions to one of several possible next-hops, thus providing load balancing and server redundancy. Server clusters are defined in the CLI and can be used as route policy actions. You define server clusters by entering the server-cluster statement at the [edit services border-signaling-gateway gateway gateway-name sip routing-destinations] hierarchy level. Each cluster consists of configured servers. In order to configure server clusters, you must first configure individual servers and server availability checking by entering statements at the [edit services border-signaling-gateway gateway gateway-name sip routing-destinations] hierarchy level. After configuring routing-destinations, you can configure routing of transactions to a particular server cluster by entering the server-cluster statement at the [edit services border-signaling-gateway gateway
gateway-name sip new-transaction-policy policy-name term term-name then route]
hierarchy level. You can display call activity by server by entering the show services border-signaling-gateway calls command with the by-server option. If you do not use the by server option, you must use the by-service-point option. You can no longer use the show services border-signaling-gateway calls command without specifying one of these two options. You can display unavailable servers by entering the show services border-signaling-gateway routing-blacklist command. [Session Border Control Solutions, Services Interfaces, Systems Basics and Services Command Reference]
Integrated Multi-Service Gateway (IMSG) support on M7i and M10i routersM7i and M10i routers now support the IMSG running on an MS-100 PIC. [Session Border Control Solutions]
Border Gateway Function (BGF) virtual BGF scabilityYou can now configure up to 32 virtual BGFs on a router. Previously, you could configure a maximum of eight virtual BGFs on a router. Those eight virtual BGFs had to reside on a single Multiservices PIC. As of JUNOS Release 10.2, eight virtual BGFs can be configured on each of four Multiservices PICs. [Session Border Control Solutions]
27
Routing Policy and Firewall Filters
Support for MPC firewall filter features (MX Series platforms with Trio MPC/MIC interfaces)If you configure and apply firewalls to an MX Series router with Trio MPCs/MICs, some match conditions are not supported. Generally, all firewall functions are supported through JUNOS Release 9.2. [Layer 2 Configuration]
Removal of input-list and output-list statements for firewall filters for the ccc and mpls protocol families applied to loopback, internal Ethernet, and USB modem interfacesThe input-list filter-names and output list filter-names statements for firewall filters for the ccc and mpls protocol families have been removed for these interfaces: management and internal Ethernet interfaces (fxp), loopback interfaces (lo), and USB modem interfaces (umd). Configuration of input lists and output lists for firewall filters for the ccc and mlps protocol families applied to other interfaces are not affected. [Policy Framework]
Support for the discard action for the tricolor marking policer applied to a firewall filterThe discard action was not previously supported for the tricolor marking policer applied to a firewall filter. With this support for the discard action, the tricolor marking policer no longer needs to include the logical-interface-policer statement at the [edit firewall three-color-policer name] hierarchy level. This change applies only to the following routers: M120, M320 with Enhanced-III FPCSs, MX Series, and M7i and M10i with Enhanced CFEB (CFEB-E). [Policy Framework]
Support for the match condition prefix-list for firewall filters for the protocol family VPLSThis match condition is already supported for IPv4 and IPv6 protocol families. To enable the prefix-list firewall filters match condition for VPLS, include the prefix-list prefix-list-name match condition at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level. [Policy Framework]
Option to enable enhanced jtree memory allocation for Layer 3 VPNs (T640 and T1600 routers with Enhanced Scaling FPC3 and Enhanced Scaling FPC4)To utilize memory across segments, JUNOS Release 10.2 extends support for allocating jtree memory for Layer 3 VPNs in different segments. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all affected FPCs to activate the configuration. To verify the configuration, use the show pfe fpc slot detail command.
NOTE: For T Series routers only. With JUNOS Release 10.2, enhanced jtree memory allocation is turned OFF by default. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all affected FPCs to activate the configuration. For JUNOS Release 9.3 to 10.1, the default routing tables (inet.0 and inet6.0) use both memory segments by default.
28
[System Basics]
Layer 2 Gigabit Ethernet logical interface policing support extended to MX Series routersEnables you to configure the following policer types on the input and output interfaces:

Single-rate two color Two-rate color-blind three color Two-rate color-aware three color Single-rate color-blind three color Single-rate color-aware three color
To configure, create the policer at the [edit firewall] hierarchy level. In addition to the policer condition and action, you must include the logical-interface-policer statement. To apply the policer to the input or output interface, include the layer2-policer statement at the [edit interface ge-fpc/pic/port unit logical-unit-number] hierarchy level. [Network Interfaces, Class of Service, Policy]
Routing Protocols
Only the system log notes failure to add routes to the Trio MPC/MIC (MX Series platforms)For Layer 3 and MPLS features, the Trio MPC/MIC is compatible with JUNOS Release 9.2. However, the syslog process is the only mechanism that records failure to add routes to the MPC. [Routing Protocols]
Keepalive support for GRE interfaces (ichip-based M Series and MX Series routers)Enables GRE tunnel interfaces to detect when a tunnel interface is down. This feature is needed in static routing environments in which the keepalive mechanism in a dynamic routing protocol cannot be relied upon to detect a link down condition. To configure keepalives on GRE tunnel interface, include both the keepalive-time statement and the hold-time statement at the [edit protocols oam gre-tunnel interface interface-name] hierarchy level.
NOTE: For proper operation of keepalives on a GRE interface, you must also include the family inet statement at the [edit interfaces interface-name unit unit] hierarchy level. If you do not include this statement, the interface is marked as down.
[Services Interfaces, Interfaces Command Reference]
Support for OSPF database protection for OSPF and OSPFv3Enables you to limit the number of link-state advertisements (LSAs) not generated by the router in a given OSPF instance. This feature is particularly useful for networks configured with VPN routing and forwarding on provider edge and customer edge routers using the OSPF routing protocol. By limiting LSAs not generated by the router, the link-state database in your network is protected from being overrun by excessive LSAs from sources other
29
than your router. To enable database protection, include the database-protection statement at the [edit protocols (ospf | ospf3)] hierarchy level. This feature also supports routing instances, logical systems, and OSPFv3 realsms. Besides configuring the maximum number of LSAs not from the router, you can specify parameters to determine how your network will respond when certain conditions are met. These parameters include a warning threshold for issuing warning messages, an ignore count to limit the number of times the database can enter the ignore state before it goes into the isolate state, and a reset time for resuming normal operations if the database has avoided being in the ignore or isolate state for the specified period of time. However, once the link-state database enters the isolate state, a command to reset the database must be issued before normal operations can be resumed. In support of this feature, the clear ospf database-protection command has been added, and the output for the show ospf overview command has been enhanced to show the current database protection status. [Routing Protocols]
Revert time for redundant Layer 2 pseudowiresYou can now modify the behavior for redundant Layer 2 circuit and VPLS pseudowires by configuring a revert time. When a primary pseudowire fails and traffic is switched to an alternate pseudowire, the revert time specifies how long the router should wait before attempting to switch the traffic back to the primary pseudowire. The router does not attempt to switch traffic back to the primary pseudowire if the primary pseudowires has not been restored. To configure a revert time for redundant Layer 2 pseudowires, specify a time, in seconds, using the revert-time statement at the [edit protocols l2circuit neighbor address interface interface-name] hierarchy level for Layer 2 circuit configurations, and at the [edit routing-instances routing-instance-name protocols vpls neighbor address] hierarchy level for VPLS configurations. [VPNs]
Support for having the algorithm that determines that the single best path skip the step that evaluates an AS pathBy default, the third step of the algorithm that determines the active route evaluates the length of an AS path. To enable the JUNOS Software to skip this step, include the as-path-ignore statement at the [edit protocols bgp path-selection] hierarchy level. You cannot configure this statement for a specific routing instance. [Routing Protocols]
Services Applications
Inline flow monitoring support (MX240, MX480, and MX960 only)Adds the capability to support flow monitoring and sampling services inline in the data path, without the need for a services PIC, on MX Series Modular Port Concentrators (MPCs). To configure inline flow monitoring, include the inline-jflow statement at the [edit forwarding-options sampling instance instance-name family inet output] hierarchy level. Inline sampling exclusively supports a new format called version-ipfix that uses UDP as the transport protocol. When you configure inline sampling, you must include the version-ipfix statement at the [edit forwarding-options sampling instance instance-name family inet output flow-server address] hierarchy level and also at the [edit services
30
flow-monitoring] hierarchy level. The following operational commands include new inline fpc keywords to display inline configuration information: show services accounting errors, show services accounting flow, and show services accounting status.
[Services Interfaces, System Basics and Services Command Reference]
AACL statistics for dynamic packet-triggered subscribersProvide support for packet-triggered subscribers and policy control (PTSP) statistics collection in a flat file using the local policy decision function (L-PDF). If you specify in the rule that statistics collection and reporting are based on application or application group for each subscriber, then this flat file method is used. To specify that PTSP statistics are reported, include the flag pstp-statistics statement at the [edit system services local-policy-decision-function traceoptions] hierarchy level. To configure the AACL statistics profile to support PTSP statistics collection, include the record-mode interim-active-only statement at the [edit system services local-policy-decision-function aacl-statistics-profile profile-name] hierarchy level and include all-fields at the [edit system services local-policy-decision-function aacl-statistics-profile profile-name aacl-fields] hierarchy level. The following operational commands display information about the packet-triggered subscribers: show services subscriber bandwidth, show services subscriber dynamic-policies, show services subscriber flows, show services subscriber sessions, and show services subscriber statistics. [Services Interfaces, System Basics and Services Command Reference, Subscriber Access]
Subscriber Access Management
Support for subscriber management features on Trio MPC/MIC interfaces (MX Series routers)Enables support for all subscriber management features introduced in JUNOS Release 10.1 and lower-numbered releases on Trio MPC/MIC interfaces available on MX Series routers. For a list of the subscriber management features and other protocols and applications supported on the MX Series MPCs, see Protocols and Applications Supported by MX Series MPCs in the MX Series 3D Universal Edge Routers Line Card Guide. [Subscriber Access, MX Series Line Card ]
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 interfaces that are running over Trio MPC/MIC interfaces on MX Series routers. [Subscriber Access]
Support for frame and cell-shaping mode and byte adjustments on static and dynamic subscriber interfaces (MX Series routers)Enables you to configure frame-based and cell-based shaping mode and byte adjustments on static or dynamic subscriber interfaces in a broadband access network. This feature is supported on Trio MPC/MIC interfaces on MX Series routers. In a broadband access network, ATM traffic can be passed downstream from other customer premise equipment (CPE) to the MX Series router. Managing the bandwidth
31
of downstream ATM traffic to Ethernet interfaces can be difficult because of the different Layer 2 encapsulations. You can configure the shaping mode to shape downstream ATM traffic based on either frames or cells. In frame shaping mode, shaping is based on the number of bytes in the frame, without regard to cell encapsulation or padding overhead. Frame is the default shaping mode on the router. In cell shaping mode, shaping is based on the number of bytes in cells and accounts for the ATM cell encapsulation and padding overhead. When you specify cell shaping, the resulting traffic stream conforms exactly to the policing rates configured in downstream ATM switches, reducing the number of packet drops in the Ethernet network. In addition, you can account for the different byte sizes per encapsulation by configuring a byte adjustment value for the shaping mode. For example, you can configure frame shaping mode and a byte adjustment value to account for differences in Layer 2 protocols for downstream Ethernet traffic. To configure the shaping mode, include the new overhead-accounting (frame-mode | cell-mode) statement at the [edit class-of-service traffic-control-profiles profile-name] hierarchy level or the [edit dynamic-profiles class-of-service traffic-control-profiles profile-name] hierarchy level. To configure byte adjustments, include the bytes byte-value option with the overhead-accounting (frame-mode | cell-mode) statement. We recommend that you configure the byte-value that represents the difference between the CPE protocol overhead and the BRAS protocol overhead. The configurable range is -120 to 124 bytes. [Subscriber Access, Class of Service]
Support for dynamic distribution of excess bandwidth among different subscriber services on subscriber interfaces (MX Series routers with Trio MPC/MIC interfaces)Enables you to control the distribution of excess bandwidth sharing on dynamic subscriber interfaces on Trio MPC/MIC interfaces available on MX Series routers. In earlier releases, excess bandwidth sharing was supported on EQ DPCs only. Service providers often used tiered services that must utilize excess bandwidth as traffic patterns vary. By default, excess bandwidth between a configured guaranteed rate and shaping rate is shared equally among all queues with the same excess priority value, which might not be optimal for all subscribers to a service. To configure the excess rate for a traffic control profile in a dynamic profile, include the excess-rate statement at the [edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name] hierarchy level and apply the traffic control profile at the [edit dynamic-profiles profile-name class-of-service interfaces interface-name] hierarchy level. To configure the excess rate for a queue, include the excess-rate and excess-priority statements at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level. [Subscriber Access]
Support for MAC address validation on Trio MPC/MIC interfaces on MX Series routersEnables MAC (source address) validation to use filters over Trio MPC/MIC
32
interfaces on MX Series routers. MAC validation is the process of verifying that the origin of the MAC address received matches the origin present in the router ARP entry table. You can enable MAC validation in either strict or loose mode on static or dynamic demux interfaces using dynamic profiles. [Subscriber Access]
Support for IP demux subscriber secure policy and MAC validate configuration on Trio MPC/MIC interfacesEnables the configuration of subscriber secure policy and MAC validation using dynamic IP demux interfaces over Trio MPC/MIC physical interfaces on MX Series routers. [Subscriber Access]
Support for dynamic 802.1Q VLAN interface configuration for PPPoE over Trio MPC/MIC interfaces on MX Series routersEnables you to configure dynamic 802.1Q VLANs for PPPoE on Trio MPC/MIC interfaces on MX Series routers. This support includes an enhancement to the accept statement to include a new pppoe VLAN Ethernet packet type. You can specify this packet type at the [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile profile-name] and the [edit
interfaces interface-name auto-configure stacked-vlan-ranges dynamic-profile profile-name] hierarchy levels. The pppoe VLAN Ethernet packet type option is supported
only for Trio MPC/MIC interfaces on MX Series routers. [Subscriber Access]
Support for IPv6 demux configuration on Trio MPC/MIC interfaces on MX Series routersEnables dynamic IPv6 demux configuration on Trio MPC/MIC interfaces on MX Series routers. [Subscriber Access]
Support for dynamic CoS for IP demux interfaces on Trio MPC/MIC interfaces (MX Series routers)Enables you to configure dynamic CoS for a static or dynamic IP demultiplexing (demux) subscriber interface on the Trio MPC/MIC interfaces available on MX Series routers. In earlier releases, dynamic CoS for IP demux interfaces was supported on EQ DPCs only. Hierarchical CoS for aggregated Ethernet interfaces is now supported on the Trio MPC/MIC family when a static or dynamic demux subscriber interface is the underlying interface. In earlier releases, hierarchical CoS for aggregated Ethernet was only supported on the Trio MPC/MIC family when a static or dynamic VLAN was the underlying interface. [Subscriber Access]
Support for non-hierarchical dynamic CoS configurations on subscriber interfaces (MX Series routers)Enables you to dynamically configure per-unit scheduling for subscriber interfaces configured on EQ DPCs and Trio MPC/MIC interfaces on MX Series routers and Ethernet Enhanced IQ2 (IQ2E) PICs on M120 and M320 routers. In earlier releases, you had to enable hierarchical scheduling prior to configuring a dynamic access or service profile with CoS parameters. In per-unit scheduling configurations, each Layer 3 scheduler node is allocated a dedicated set of queues. If you do not explicitly configure CoS parameters, a default traffic profile with queues is
33
attached to the logical interface. Interfaces are not dynamically created with a new set of queues when the existing queue limit is reached. To enable per-unit scheduling for the subscriber interface, include the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level. You can then configure dynamic CoS parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level and the remaining static parameters at the [edit class-of-service] hierarchy level. [Subscriber Access]
PPPoE service name table enhancements (M120, M320, and MX Series routers)Support the following new and enhanced features for PPPoE service name tables:
Configuration of any service. The any service acts as a default service for non-empty service entries that do not match the empty or named service entries configured in the PPPoE service name table on the router. The any service is useful when you want to match the agent circuit ID and agent remote ID information for a PPPoE client, but do not care about the service name tag that is transmitted in the control packet. To configure the any service, include the service any statement at the [edit protocols pppoe service-name-table table-name] hierarchy level.
Association of agent circuit identifier/agent remote identifier (ACI/ARI) pairs with empty or any service. Associating an ACI/ARI pair with an empty or any service enables you to identify the DSLAM interface that initiated the service request (agent circuit ID string) and the subscriber on the DSLAM interface that initiated the service request (remote ID string). In lower-numbered releases, you could not associate ACI/ARI pairs with the empty service. To configure an ACI/ARI pair for an empty or any service, include the agent-specifier statement at the [edit protocols pppoe service-name-table table-name service ( empty | any )] hierarchy level.
Association of a PPPoE dynamic profile with a named service, empty service, any service, or ACI/ARI pair. You can associate a previously configured PPPoE dynamic profile with a named, empty, or any service entry in the PPPoE service name table, or with an ACI/ARI pair defined for these services. The router uses the attributes defined in the profile to instantiate a dynamic PPPoE interface to handle the PPPoE session. The dynamic profile associated with the PPPoE service name table entry overrides the dynamic profile assigned to the underlying Ethernet interface. To associate a dynamic profile with a named, empty, or any service, include the dynamic-profile statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level. To associate a dynamic profile with an ACI/ARI pair, include the dynamic-profile statement at the [edit protocols pppoe service-name-table table-name service (
34
service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string]
hierarchy level.
Association of routing instance with named service, empty service, any service, or ACI/ARI pair. To specify the routing instance in which the router should create the dynamic PPPoE interface, you can associate a previously configured routing instance with a named, empty, or any service entry in the PPPoE service name table, or with an ACI/ARI pair defined for these services. The routing instance associated with the PPPoE service name table entry overrides the routing instance associated with the underlying Ethernet interface. To associate a routing instance with a named, empty, or any service, include the routing-instance statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level. To associate a routing instance with an ACI/ARI pair, include the routing-instance statement at the [edit protocols pppoe service-name-table table-name service (
hierarchy level.
Association of static PPPoE interface with ACI/ARI pair. You can associate a previously configured static PPPoE interface with an ACI/ARI pair defined for a named, empty, or any service entry configured in the PPPoE service name table. The router reserves the specified static interface for use only with the matching service name table entry. To associate a static PPPoE interface with an ACI/ARI pair, include the static-interface statement at the [edit protocols pppoe service-name-table table-name service (
hierarchy level.
Configurable maximum sessions limit for named service, empty service, or any service. You can configure the maximum number of active PPPoE sessions using either dynamic or static PPPoE interfaces that the router can establish with the specified service name table entry, in the range from 1 through the platform-specific maximum for your router. The default value is equal to the maximum number of PPPoE sessions supported on your router. The maximum sessions value associated with the PPPoE service name table entry is used in conjunction with the maximum sessions value configured for the underlying Ethernet interface. To configure the maximum sessions limit for a named, empty, or any service, include the max-sessions statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.
Option to globally advertise named services in PPPoE Active Discovery Offer (PADO) control packets. By default, advertisement of named services in PADO control packets sent by the router is disabled. You can enable advertisement of named services in the PADO packet when you define the PPPoE protocol. If you do so, make sure the number and
35
length of the named service entries advertised in the PADO packet do not exceed the MTU size of the underlying Ethernet interface. To enable advertisement of named services in PADO control packets sent by the router, include the pado-advertise statement at the [edit protocols pppoe] hierarchy level.
Increased system maximums for PPPoE service name tables, named service entries, and ACI/ARI pairs. You can now configure a maximum of 32 PPPoE service name tables per M120, M320, or MX Series router; a maximum of 512 named service entries (excluding empty and any service entries) per PPPoE service name table; and a maximum of 8000 ACI/ARI pairs per PPPoE service name table.
To verify the PPPoE service name table configuration, use the following new and updated operational commands:
To display information about all active PPPoE sessions and optionally filter the output by service name, agent circuit ID string, or remote ID string, issue the new show pppoe sessions command. To display configuration information for a PPPoE service name table, issue the show pppoe service-name-tables command. This command has been updated to include information about the any service, maximum sessions, and active sessions. This command also displays information about the dynamic profile, routing instance, and static interface attributes, if configured. To display session-specific information about PPPoE interfaces, issue the show pppoe interfaces command. This command has been updated to include the service name, agent circuit ID string, and agent remote ID string used to establish the active PPPoE session on the interface.
[Network Interfaces, Interfaces Command Reference, Subscriber Access]
Maximum queues for static and dynamic subscriber interfaces on Trio MPC modules (MX240, MX480, and MX960 routers)Enable you to scale to a maximum number of dedicated queues for static and dynamic subscriber interfaces configured on certain Trio MPC modules. The following table lists the number of dedicated queues per module.
MPC Name
20Gigabit Ethernet Queuing MPC 40Gigabit Ethernet Queuing MPC 40Gigabit Ethernet Enhanced Queuing MPC
Number of Dedicated Queues

64,000 egress 128,000 egress 512,000 egress
These values are supported for static CoS configurations configured at the [edit class-of-service] hierarchy level and dynamic CoS configurations configured at the
36
[edit dynamic profiles profile-name class-of-service] hierarchy level. Hierarchical
scheduling must be enabled on the interface, and per-unit scheduling is not supported. When the maximum number of queues on the module is reached, a new system log message, COSD_OUT_OF_DEDICATED_QUEUES, is generated. All subsequent subscriber interfaces are not provided a dedicated set of queues. In hierarchical scheduling configurations, traffic from these logical interfaces is considered unclassified and attached to a common set of queues that are shared by all subsequent logical interfaces. These common queues are the default port queues that are created for every port. You can configure common queues for the physical interface by including the output-traffic-control-profile-remaining statement at the [edit class-of-service interfaces] hierarchy level. The output of the show class-of-service interface interface-name operational command has been extended to display the traffic profile that is attached to the specified logical interface. In addition, the output displays the number of queues that have been consumed by the logical interfaces configured over a specific physical interface. [Class of Service, Subscriber Access]
Dynamic profile and enhanced RADIUS support for MLPPP subscriber services (M120 and M320 routers)RADIUS can now dynamically assign IPv4 addresses for MLPPP connections. The same address is allocated to all links in a bundle. AAA disconnects any link that is allocated an address different than the address previously allocated to member links in the bundle. The IP address is released for reallocation when the last member link in a bundle logs out. The Acct-Multi-Session-Id attribute enables RADIUS to link multiple related sessions into a single log file. RADIUS uses the session database (SDB) bundle session ID for the value of Acct-Multi-Session-Id. This bundle ID enables RADIUS to initiate a disconnect for an entire bundle. By tracking the member link sessions, RADIUS is also able to disconnect the individual member links in a bundle. The Acct-Link-Count [51] attribute records the number of links present in a multilink session at the time the accounting record is generated. Include the dynamic-profiles profile-name statement at the [edit] hierarchy level to define a dynamic profile that specifies attributes to be applied dynamically to MLPPP bundle interfaces. The dynamic-profile profile-name statement at the [edit interfaces interface-name unit logical-unit-number ppp-options] hierarchy level now supports certain LSQ interfaces. Include this statement to assign the dynamic profile to the LSQ MLPPP bundle interface. These MLPPP subscriber access features are supported only on the Channelized DS3/E3 Enhanced IP PIC (PB-4CHDS3-E3-IQE-BNC) on M120 and M320 routers. The MLPPP subscriber services are available only on LSQ interfaces configured on Adaptive Services PICs or Multiservices PICs. [Subscriber Access]
Address-assignment pool linking (MX Series routers)Subscriber management enables you to link an address-assignment pool to a second pool. Linking enables you to provide a backup address pool in the event that all addresses in the primary
37
address-assignment pool are allocated. The router automatically begins allocating addresses from the secondary (linked) address-assignment pool when the primary pool is fully allocated. Both IPv4 and IPv6 address-assignment pools support linking. However, the secondary pool must be the same family type as the primary pool. You cannot link an IPv4 address-assignment pool to an IPv6 pool, or vice versa. You use the link statement at the [edit access address-assignment pool pool-name] hierarchy level to specify the secondary address-assignment pool. You use the show network-access aaa statistics address-assignment pool command to display information about an address-assignment pool, such as the percentage of the pool that has been allocated. [Subscriber Access]
Distinguishing DHCP duplicate clients by subinterface (MX Series routers)You can now optionally configure DHCP to include the client subinterface when distinguishing between duplicate DHCP clients (clients with the same MAC or client ID) in the same subnet. By default, DHCP distinguishes clients by subnet. However, when multiple subinterfaces share the same underlying loopback interface with the same preferred source address, the subinterfaces appear to be on the same subnet, and DHCP is unable to differentiate between duplicate clients. The optional configuration enables DHCP to use the client subinterface to differentiate between the duplicate clients within the subnet. Distinguishing DHCP clients by subinterface is supported on DHCPv4 only, and is supported per logical system routing instance.
To enable duplicate client subinterface support for DHCP local server, include the duplicate-clients-on-interface statement at the [edit system services dhcp-local-server] hierarchy level. To enable duplicate client subinterface support for DHCP relay agent, include the duplicate-clients-on-interface statement at the [edit forwarding-options dhcp-relay] hierarchy level. Also, DHCP relay must be configured to insert option 82 Agent Circuit ID with the interface name, and the DHCP local server must echo this option 82 in its reply.
[Subscriber Access]
Sending a DHCP relay and relay proxy release message (MX Series routers)You can configure DHCP relay and relay proxy to generate and send a release message to the DHCP server whenever DHCP relay or relay proxy delete a client. This release message sent by DHCP relay and relay proxy includes option 82 information. By default, no release message is sent. To configure DHCP relay and relay proxy to send a release message, include the send-release-on-delete statement at the following hierarchy levels:

Global configuration[edit forwarding-options dhcp-relay overrides] Named group configuration[edit forwarding-options dhcp-relay group group-name
overrides]
38
Per interface configuration[edit forwarding-options dhcp-relay group group-name

interface interface-name overrides]
NOTE: In earlier releases, if the client-discover-match statement was configured, DHCP relay sent a release message to the DHCP server when a client was deleted. This is no longer the case. To configure DHCP to send the release message, you must configure the send-release-on-delete statement.
[Subscriber Access]
SNMP trap support for subscriber secure policy (MX Series routers)Subscriber secure policy supports the use of SNMPv3 traps to capture and report packet mirroring information to an external mediation device. The traps map to messages defined in the Lawfully Authorized Electronic Surveillance (LAES) for IP Network Access, American National Standard for Telecommunications. You use standard configuration methods, as described in the JUNOS Network Management Configuration Guide, to configure the mediation device to receive the SNMPv3 trap information. Your configuration must include the authentication and privacy keys. The SNMPv3 traps, which are provided in the Juniper Packet Mirroring MIB, jnx-js-packet mirror.mib, are described in the following table:
Table 2: SNMP Traps for Subscriber Secure Policy

Trap
jnxPacketMirrorLiSubscriberLoggedIn
Description
Subscriber, who is identified to have a mirrored service that is activated at login, has successfully logged in. Subscriber, who is identified to have a mirrored service that is activated at login, has failed to log in. Subscriber, who had an active mirrored service, has logged out. Mirrored session has been activated. Mirrored session for a subscriber has failed. Mirrored session for an established subscriber has been deactivated. Mirrored service request failed due to an invalid value in the request. NOTE: This trap is not related to LAES messages.
jnxPacketMirrorSessionLiSubscriberLogInFailed
jnxPacketMirrorInterfaceLiSubscriberLoggedOut
jnxPacketMirrorInterfaceLiServiceActivated jnxPacketMirrorSessionLiServiceActivationFailed jnxPacketMirrorSessionLiServiceDeactivated
jnxPacketMirrorMirroringFailure
[Subscriber Access]
39
DTCP support for subscriber secure policy (MX Series routers)DTCP now supports subscriber secure policy, and you no longer need to configure the flow-tap service. You use the radius-flow-tap statement to configure subscriber secure policy directly on DTCP. In previous releases, subscriber secure policy ran on top of the flow-tap service infrastructure. This required that you configure the flow-tap service before configuring subscriber secure policy support. To configure subscriber secure policy on DTCP:
1.
Configure the DTCP-over-SSH serviceInclude the flow-tap-dtcp ssh statement at the [edit system services] hierarchy level.
2. Allocate the tunnel interfaces that the DTCP service can use for subscriber secure
policy mirroringInclude the fpc slot-number pic number tunnel-services bandwidth statement at the [edit chassis] hierarchy level.
3. Configure the tunnel interfacesInclude the interface-name unit number family inet
statement at the [edit interfaces] hierarchy level.

4. Assign the tunnel interface that DTCP uses for subscriber secure policy
mirroringInclude the radius-flow-tap interfaces interface-name statement at the [edit services] hierarchy level.
5. Specify the source IP address that DTCP uses for mirroringInclude the
radius-flow-tap source-ipv4-address ipv4address statement at the [edit services]
hierarchy level. [Subscriber Access]
Support for new RADIUS parameters to dynamically distribute excess bandwidth on subscriber interfaces (MX Series routers)Enables you to configure predefined variables for controlling excess bandwidth on subscriber interfaces. The RADIUS server supplies values for these variables to the router when subscribers log in. The Juniper Networks VSA for CoS scheduling and queuing parameter values (attribute 26146) has been updated to include three new predefined variables for the excess-rate, shaping-rate, and excess-priority parameters. To configure the predefined variables, include the excess-rate percent $junos-cos-scheduler-excess-rate statement, the shaping-rate percent $junos-cos-scheduler-shaping-rate statement, or the excess-priority $junos-cos-excess-priority statement at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level. The Juniper Networks VSA for CoS traffic shaping parameter values (attribute 26108) has been updated to include one new predefined variable attribute for the excess rate parameter. To configure the predefined variable, include the excess-rate percent $junos-cos-excess-rate statement at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level. [Subscriber Access]
Overriding DHCP settings on specific interfaces (MX Series routers)You can now override DHCP local server, DHCPv6 local server, and DHCP relay configuration options
40
for a specific interface or for a range of interfaces. The interface or range of interfaces must be configured in a DHCP group. Previously, you could override DHCP options globally or for a specific named group. An override configuration for a specific interface or range of interfaces takes precedence over a group or global override configuration. To override DHCP options for an interface or range of interfaces, include the overrides statement at the following hierarchies. The configuration is also supported at the [edit logical-systems], [edit logical-systems logical-system-name routing-instance], and [edit routing-instance] hierarchy levels.
For a DHCP local server[edit system services dhcp-local-server group group-name

interface]
For a DHCPv6 local server[edit system services dhcp-local-server dhcpv6 group

group-name interface]
For a DHCP relay agent[forwarding-options dhcp-relay group group-name interface]
[Subscriber Access]
Support for demux VLAN interface configuration on Ethernet and aggregated Ethernet Trio MPC/MIC interfacesEnables the static or dynamic creation of demux VLAN interfaces with an underlying interface of aggregated Ethernet or Gigabit/10Gigabit Ethernet. You can configure either single-tag or stacked demux VLAN interfaces. When configuring single-tagged, static VLAN demux interfaces, specify a VLAN ID for the vlan-id statement at the [edit interfaces demux0 unit unit-number] hierarchy level. When configuring stacked (dual-tagged), static VLAN demux interfaces, specify an inner and outer tag at the [edit interfaces demux0 unit unit-number vlan-tags] hierarchy level. For both single-tagged and stacked VLAN interfaces, you must also specify the underlying device name for the underlying-interface statement at the [edit interfaces demux0 unit unit-number demux-options] hierarchy level. When configuring single-tagged, 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. When configuring stacked (dual-tagged), dynamic VLAN demux interfaces, specify an inner and outer tag at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number vlan-tags] hierarchy level. For both single-tagged and stacked VLAN interfaces, 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.
NOTE: IP demux over VLAN, demux stacking is not supported.
[Subscriber Access]
Specifying the DHCP source address used for IP packets (MX Series routers)By default, when communicating with clients, DHCP uses the IP address of the interface as the source address that is included in IP packets. You can now explicitly specify the source address by configuring the server identifier in the DHCP address-assignment
41
pool. The address you specify is also used in DHCP option 54, and is included in DHCP forcerenew, DHCP offer, DHCP ACK, and DHCP NAK messages. To specify the source IP address for DHCP local server, configure the server identifier as a DHCP attribute for the DHCP address-assignment pool. Include the server-identifier statement at the [edit access address-assignment pool pool-name family inet dhcp-attributes] hierarchy level. This feature is supported for the IPv4 DHCP local server only. [Subscriber Access]
Diameter base protocol support for packet-triggered subscribers and policy control (PTSP) (MX Series routers)The Diameter base protocol provides basic services to one or more applications (also called functions) that each runs in a different Diameter instance. The individual application provides the extended functionality. To support PTSP, a new application is added. To configure the PTSP application, you must include the function packet-triggered-subscribers statement at the [edit diameter network-element element-name forwarding route dne-route-name] hierarchy level. You can use the PTSP application to interact with the Juniper Networks Session and Resource Control (SRC) software to support dynamic packet-triggered subscribers. The SRC software runs on a Juniper Networks C Series Controller and provides a central administrative point for managing subscribers and their services. The SRC software uses the Diameter protocol for communications between the PTSP application acting as the local peer on an MX Series router and the remote SRC peer (the service activation engine or SAE) on a C Series Controller. The PTSP application is a Juniper Networks-specific Diameter application registered with the IANA as Juniper JGx, with an ID of 16777273. PTSP and the SAE exchange Diameter protocol messages that include a variety of attribute-value pairs (AVPs) to convey state information and identify actions requested or performed. Both standard Diameter AVPs and Juniper Networks vendor-specific AVPs (ID 2636) are employed. [Subscriber Access]
PTSP supports dynamic and static policy rules (MX Series routers)You can use the packet-triggered subscribers and policy control (PTSP) application to interact with the Juniper Networks Session and Resource Control (SRC) software to apply dynamic policy rules to packet-triggered subscribers. To enable the SRC peer to download PTSP policies to the MX Series router using Diameter and apply the dynamic PTSP rules to the packet-triggered subscribers, create and assign a PTSP partition. To create the PTSP partition, include the partition statement at the [edit system services packet-triggered-subscribers] hierarchy level. To configure the partition, include the diameter-instance, destination-host, and destination-realm statements at the [edit system services packet-triggered-subscribers partition partition-name] hierarchy level. To assign the PTSP partition, include the packet-triggered-subscribers-partition statement at the [edit system] hierarchy level. You can also create static PTSP rules to apply policies to distinct source IP addresses flowing through a given interface. To configure static PTSP rules, include the service-set and ptsp statements at the [edit services] hierarchy level. Dynamic PTSP policies take precedence over static PTSP policies.
42
If you specify in the rule that statistics collection and reporting are based on the rule for each subscriber, then Diameter is used to report the statistics. If you specify in the rule that statistics collection and reporting are based on application or application group for each subscriber, then the flat file method is used to report the statistics. The flat file method requires you to configure AACL statistics for packet-triggered subscribers. All rules in a given service set must specify the same type of statistics collection and reporting; you cannot mix and match types. The following operational commands display information about the packet-triggered subscribers: show services subscriber bandwidth, show services subscriber dynamic-policies, show services subscriber flows, show services subscriber sessions, and show services subscriber statistics. You can use the clear services subscriber session client-id client-id command to request subscriber logout. [Subscriber Access, System Basics and Services Command Reference]
PTSP support for application identification services (MX Series routers)You can use packet-triggered subscribers and policy control (PTSP) with the application identification (APPID) services. To configure match conditions that support application identification, include the application or application-group statements at the [edit services ptsp rule rule-name term precedence from] hierarchy level. We recommend that you avoid using these match conditions with the forwarding-instance action at the [edit services ptsp forward-rule forward-rule-name term precedence then] hierarchy level because your network topology might lead to unexpected behavior. [Subscriber Access]
Support for show subscribers command enhancementsProvides the following enhancements to the show subscribers CLI command:
Changes to the count option, enabling the option to function with search filters to provide total/active subscribers that match the filter criteria (address, interface, logical-system, and so on). Added client-type, mac-address, and subscriber-state search filter options. A terse display change that changes the IP Address column to IP Address/VLAN ID where the client IP address is shown for DHCP subscriber sessions and the VLAN ID is shown for dynamic-vlan (auto-sensed VLAN) sessions. An added terse display LS:RI column to show the logical system and routing instance of the subscriber. Detail display modifications to include any service sessions associated with the subscriber. Detail display enhancements to support IPv6 address and prefix fields. An added extensive display option to provide more information for each subscriber than the detail display. The additional information includes service session and filter data. A new summary display that provides subscriber summaries by session state, client type, LS:RI, or all of these.
43
[System Basics and Services Command Reference]
JUNOS subscriber access scaling values (M120, M320, and MX Series routers)A spreadsheet is available online that lists the DCHP, PPP, and PPPoE scaling values supported for JUNOS subscriber management beginning with JUNOS Release 10.1. Access the spreadsheet from the Downloads box at
http://www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/ subscriber-access/index.html.
VPNs
VRF table label support added for Enhanced Intelligent Queuing (IQE) Type-1 PICs on M320 routers with E3 FPCsProvides an alternative for Layer 3 VPN applications to perform egress IP filtering at the egress PE router, or for the case when the CE is a Layer 2 switch with no IP capabilities, without the need of a tunnel PIC to loopback the packet. This enhancement adds VRF table label support for the following IQE Type-1 PICs:

PB-1OC12-STM4-IQE-SFP PB-4OC3-STM1-IQE-SFP PB-4DS3-E3-IQE-BNC PB-2CHOC3-STM1-IQE-SFP with no partition to a SONET interface PB-1CHOC12-STM4-IQE-SFP with no partition to a SONET interface
To configure VRF table label support on the listed IQE Type-1 PICs, use the vrf-table-label statement at either the [edit logical-systems logical-system-name routing-instances routing-instance-name] or the [edit routing-instances routing-instance-name] hierarchy level. [VPNs, Network Interfaces, Interfaces Command Reference]
Static VPLSYou can now configure a VPLS domain using static pseduowires. A VPLS domain consists of a set of PE routers that act as a single virtual Ethernet bridge for the customer sites connected to these routers. By configuring static pseudowires for the VPLS domain, you do not need to configure the LDP or BGP protocols that would normally be used for signaling. Static pseudowires require that you configure a set of in and out labels for each pseudowire configured for the VPLS domain. You still need to configure a VPLS identifier and neighbor identifiers for a static VPLS domain. You can configure both static and dynamic neighbors within the same VPLS routing instance. To configure a static pseudowire for a VPLS neighbor, include the static statement at the [edit routing-instances routing-instance-name protocols vpls neighbor address] hierarchy level. You must also configure an incoming and outgoing label for the static pseudowire using the incoming-label and outgoing-label statements, configured at the
[edit routing-instances routing-instance-name protocols vpls neighbor address static]
hierarchy level. You can also configure the static statement for a backup neighbor (if you configure the neighbor as static the backup must also be static) at the [edit
routing-instances routing-instance-name protocols vpls neighbor address backup-neighbor
44
Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers
address] hierarchy level, and for a mesh group at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address]
hierarchy level. If you issue a show vpls connections command, static neighbors are displayed with "SN" next to their addresses in the command output. To enable static VPLS on a router, you need to either configure a virtual tunnel interface (requires the router to have a tunnel PIC) or a label switching interface (LSI). To configure an LSI, include the no-tunnel-services statement at the [edit protocols vpls static-vpls] hierarchy level. [VPNs] Related Documentation
Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 45 Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63 Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers on page 118 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 127
Class of Service
Output forwarding map not supported on multiservices link services intelligent queuingIf you configure an output 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]
Ingress shaping overhead (MX Series routers)For MX Series routers, when ingress queueing is enabled on EQ DPCs, ingress shaping overhead can be made accurate by using the following values for the ingress-shaping-overhead statement:

For Layer 2, subtract 14 bytes For Layer 3 untagged ports, add 2 bytes For Layer 3 dual-tagged ports, add 10 bytes
[Class of Service]
A DSCP action or traffic-class action configured on a DPC in an MX Series router no longer causes the commit to failFor MX Series routers, if you configure a firewall filter with a DSCP action or traffic-class action on a DPC, the commit no longer fails. However, a warning displays and an entry is made in the syslog. [Class of Service]
45
Forwarding and Sampling
Support for the match condition prefix-list for firewall filters for the protocol family VPLS (MX Series routers only)The match condition that is supported for IPv4 and IPv6 protocol families is now also supported for the VPLS family. Support for VPLS prefix lists is limited to IPv4 addresses only; any IPv6 addresses included in the prefix list will be discarded. To enable the prefix-list firewall filters match condition for VPLS, include the prefix-list prefix-list-name match condition at the [edit firewall family vpls filter filter-name term term-name from ] hierarchy level. [Policy Framework]
General Routing
Framed-Route tag option supportedThe MX Series routers now fully support the tag route-tag option in the RADIUS Framed-Route [22] attribute for access routes in dynamic profiles. To use the route tag, include the tag $junos-framed-route-tag statement at the [edit dynamic-profiles profile-name routing-options access route $junos-framed-route-prefix] hierarchy level. Access route tag supportedFor M120, M320, and MX Series routers, you can optionally assign a tag to a statically configured access route. To use the route tag, include the tag route-tag statement at the [edit routing-options access route ip-prefix/prefix-length] hierarchy level.
Deprecated empty-service statementFor PPPoE service name table configurations on M120, M320, and MX Series routers, the empty-service statement has been deprecated at the [edit protocols pppoe service-name-tables table-name] hierarchy level in JUNOS Release 10.2 and later. Instead, use the service empty statement at the [edit protocols pppoe service-name-tables table-name] hierarchy level to configure attributes for the empty service entry in a PPPoE service name table. [Network Interfaces]
Enhancement to show oam ethernet link-fault-management detail commandThe output of the show oam ethernet link-fault-management detail command now includes the following two new fields: OAM total symbol error event information and OAM total frame error event information. These fields display the total number of errored symbols and errored frames, respectively, and are updated at every interval regardless of whether the threshold for sending event TLVs has been crossed. Previously, the show oam ethernet link-fault management detail command displayed only the number of errored symbols reported in TLV events transmitted since the OAM layer was reset and the number of errored frames detected since the OAM layer was reset. [Interfaces Command Reference]
Enhancement to show oam ethernet connectivity-fault-management commandsThe output of the show oam ethernet connectivity-fault-management mep-statistics, show oam ethernet connectivity-fault-management interfaces, and show oam ethernet connectivity-fault-management mep-database commands includes the following three
46
new fields: Out of sync 1DMs received, which displays the number of out-of-sync one-way delay measurement packets received; Valid DMMs received, which displays the number of valid two-way delay measurement request packets received, and Invalid DMMs received, which displays the number of invalid two-way delay measurement request packets received. [Interfaces Command Reference]
Enhancement to the show system license commandFor scalable license-based features such as Subscriber Access (scale-subscriber), L2TP (scale-l2tp), Mobile IP (scale-mobile-ip), and so on, the show system license operational mode command now displays the actual usage count in the Licenses used column based on the number of active sessions or connections as reported by the corresponding feature daemons. [System Basics and Services Command Reference]
show system switchover is deprecated on the master Routing EngineBeginning
JUNOS Release 9.6, the show system switchover command has been deprecated on the master Routing Engine on all routers other than a TX Matrix (switch-card chassis) or a TX Matrix Plus (switch-fabric chassis) router. However, in a routing matrix, if you issue the show system switchover command on the master Routing Engine of the TX Matrix router (or switch-card chassis), the CLI displays graceful switchover information for the master Routing Engine of the T640 routers (or line-card chassis) in the routing matrix. Likewise, if you issue the show system switchover command on the master Routing Engine of a TX Matrix Plus router (or switch-fabric chassis), the CLI displays output for the master Routing Engine of T1600 routers (or line-card chassis) in the routing matrix. [System Basics and Services Command Reference]
Options added to the show arp commandThe vpn and logical-system options have been added to the show arp command. [System Basics Command Reference]
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. [CLI User Guide]
Enhancement to the show chassis fabric fpcs commandThe show chassis fabric fpcs command issued on T Series routers now displays a list of Packet Forwarding Engines with destination errors in addition to link errors. This is applicable for SIBs in the Check state. In JUNOS Release 9.6 and later, the list of Packet Forwarding Engines with destination errors is displayed in the output. In JUNOS releases before 9.6, the output only indicates that there are destination errors. However, the list of Packet Forwarding Engines with destination errors is not displayed. The following is a sample of the enhanced output for this command:
user@host> show chassis fabric fpcs
Fabric management FPC state:
47
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 20 7 8 21 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
[System Basics Command Reference]
Support for demux and PPPoE static interfacesThe maximum number of static logical interfaces supported per physical interface for demux (on demux0) and PPPoE (on pp0) has been increased to 65,536 (logical unit numbers in the range 0 through 65,535). For all other interface types, the maximum number of static interfaces per physical interface remains at 16,386 (logical unit numbers in the range 0 through 16,385). [Network Interfaces]
Enhancement to the show chassis sibs commandThe show chassis sibs command now displays destination errors for SIBS in the Check state. In JUNOS Release 9.6 and later, the Check state message shows the number of Packet Forwarding Engines in the plane having destination errors. For example, Check (10 destination errors) indicates 10 Packet Forwarding Engines having destination errors. If there are no destination errors, and if the SIB transitions to the Check state because of link errors only, the Check state message shows Check (0 destination errors). In JUNOS Release 9.5 and earlier, the Check state message shows Check (destination errors) if there are Packet Forwarding Engines with destination errors in this plane. However, it does not show the number of Packet Forwarding Engines having destination errors. If there are no destination errors and if the SIB transitions to the Check state because of link errors only, the Check state message shows Check (no destination errors).
user@host> show chassis sibs
Slot 0 1 2 3 4
State Check Empty Check Check Check
(destination errors) (destination errors) (destination errors) (destination errors)
Uptime 2 hours, 23 minutes, 2 seconds 2 hours, 23 minutes, 3 seconds 2 hours, 23 minutes, 3 seconds 2 hours, 23 minutes, 3 seconds
use "show chassis fabric fpcs" and "show chassis fabric sibs" for more details
48
In addition, the command also displays a message to use the show chassis fabric fpcs and show chassis fabric sibs commands for more information. If there are no SIBs in the Check state, there is no change in the output of this command. [System Basics Command Reference]
Changes to the output of the show chassis power commandThe output of the show chassis power command has now been revised to show the maximum and actual power capacity details for an AC or DC PEM, based on number of feeds, the number of feeds expected and connected, and other system statistics. The following is a sample of the revised output for the show chassis power command:
PEM 0: State: DC input: DC input: Capacity: DC output: PEM 1: State: DC input: DC input: Capacity: DC output: PEM 2: State: Input: PEM 3: State: Input: Online OK (1 feed expected, 1 feed connected) 48.0 V input (51500 mV) 2800 W (maximum 2800 W) 306 W (zone 0, 6 A at 51 V, 10% of capacity)
Online OK (1 feed expected, 1 feed connected) 48.0 V input (51000 mV) 2800 W (maximum 2800 W) 459 W (zone 1, 9 A at 51 V, 16% of capacity)
Empty Absent
Empty Absent
System: Zone 0: Capacity: Allocated power: Actual usage: Zone 1: Capacity: Allocated power: Actual usage: Total system capacity: Total remaining power:
2800 W (maximum 2800 W) 540 W (2260 W remaining) 306 W 2800 W (maximum 2800 W) 905 W (1895 W remaining) 459 W 5600 W (maximum 5600 W) 4155 W
The following is a sample of the earlier output for the show chassis power command:
DC PEM 0 Limits: Voltage 48 Input: Zone 0 Output: Voltage 58 State: Online Current 101 Feed 2 Current 16 Rating 4100 Switch 1 Power 928 MaxDPC 600 Code 2-G Load(%) RemainingPower 22 3172
DC PEM 1 Limits: Voltage Current Rating 48 101 4100
MaxDPC 600
49
Input:
Zone 1 Output: Voltage 57 State: Online DC PEM 2 Limits: Voltage 48 Input: Zone 0 State: Present DC PEM 3 Limits: Voltage 48 Input: Zone 1 State: Present
Feed 2 Current 7
Switch 1 Power 399
Code 2-G Load(%) RemainingPower 9 3701
Current 70 Feed 1
Rating 2800 Switch 0
MaxDPC 352 Code 1-G
Current 70 Feed 1
Rating 2800 Switch 0
MaxDPC 352 Code 1-G

Enhancement to the show system virtual-memory command outputStarting with JUNOS Release 10.2, the show system virtual-memory command issued with the | display XML pipe option displays XML output for the command in the parent tags: <vmstat-memstat-malloc>, <vmstat-memstat-zone>, <vmstat-sumstat>, <vmstat-intr>, and <vmstat-kernel-state> with each child element as a separate XML tag. The following is a sample output for the next XML output:
user@host> show system virtual-memory | display xml <rpc-reply xmlns:junos="http://xml.juniper.net/junos/10.2R1/junos"> <system-virtual-memory-information> <vmstat-memstat-malloc> <memstat-name>CAM dev queue</memstat-name> <inuse>1</inuse> <memuse>1</memuse> <high-use>-</high-use> <memstat-req>1</memstat-req> <memstat-size>64</memstat-size> ... </vmstat-memstat-malloc> <vmstat-memstat-zone> <zone-name>UMA Kegs:</zone-name> <zone-size>136</zone-size> <count-limit>0</count-limit> <used>71</used> <free>1</free> <zone-req>71</zone-req> ... </vmstat-memstat-zone> <vmstat-sumstat> <cpu-context-switch>934906</cpu-context-switch> <dev-intr>1707986</dev-intr> <soft-intr>33819</soft-intr> <traps>203604</traps> <sys-calls>1200636</sys-calls> <kernel-thrds>60</kernel-thrds>
50
<fork-calls>1313</fork-calls> <vfork-calls>21</vfork-calls> <rfork-calls>0</rfork-calls> <swap-pageins>0</swap-pageins> <swap-pagedin>0</swap-pagedin> <swap-pageouts>0</swap-pageouts> <swap-pagedout>0</swap-pagedout> <vnode-pageins>23094</vnode-pageins> <vnode-pagedin>23119</vnode-pagedin> <vnode-pageouts>226</vnode-pageouts> <vnode-pagedout>3143</vnode-pagedout> <page-daemon-wakeup>0</page-daemon-wakeup> <page-daemon-examined-pages>0</page-daemon-examined-pages> <pages-reactivated>8821</pages-reactivated> <copy-on-write-faults>48364</copy-on-write-faults> <copy-on-write-optimized-faults>31</copy-on-write-optimized-faults> <zero-fill-pages-zeroed>74665</zero-fill-pages-zeroed> <zero-fill-pages-prezeroed>70061</zero-fill-pages-prezeroed> <transit-blocking-page-faults>85</transit-blocking-page-faults> <total-vm-faults>191824</total-vm-faults> <pages-affected-by-kernel-thrd-creat>0</pages-affected-by-kernel-thrd-creat> <pages-affected-by-fork>95343</pages-affected-by-fork> <pages-affected-by-vfork>3526</pages-affected-by-vfork> <pages-affected-by-rfork>0</pages-affected-by-rfork> <pages-freed>221502</pages-freed> <pages-freed-by-deamon>0</pages-freed-by-deamon> <pages-freed-by-exiting-proc>75630</pages-freed-by-exiting-proc> <pages-active>45826</pages-active> <pages-inactive>13227</pages-inactive> <pages-in-vm-cache>49278</pages-in-vm-cache> <pages-wired-down>10640</pages-wired-down> <pages-free>70706</pages-free> <bytes-per-page>4096</bytes-per-page> <swap-pages-used>0</swap-pages-used> <peak-swap-pages-used>0</peak-swap-pages-used> <total-name-lookups>214496</total-name-lookups> <positive-cache-hits>92</positive-cache-hits> <negative-cache-hits>5</negative-cache-hits> <pass2>0</pass2> <cache-deletions>0</cache-deletions> <cache-falsehits>0</cache-falsehits> <toolong>0</toolong> </vmstat-sumstat> <vmstat-intr> <intr-name>irq0: clk </intr-name> <intr-cnt>1243455</intr-cnt> <intr-rate>999</intr-rate> <intr-name>irq4: sio0 </intr-name> <intr-cnt>1140</intr-cnt> <intr-rate>0</intr-rate> <intr-name>irq8: rtc </intr-name> <intr-cnt>159164</intr-cnt> <intr-rate>127</intr-rate> <intr-name>irq9: cbb1 fxp0 </intr-name> <intr-cnt>28490</intr-cnt> <intr-rate>22</intr-rate>
51
<intr-name>irq10: fxp1 </intr-name> <intr-cnt>20593</intr-cnt> <intr-rate>16</intr-rate> <intr-name>irq14: ata0 </intr-name> <intr-cnt>5031</intr-cnt> <intr-rate>4</intr-rate> <intr-name>Total</intr-name> <intr-cnt>1457873</intr-cnt> <intr-rate>1171</intr-rate> </vmstat-intr> <vm-kernel-state> <vm-kmem-map-free>248524800</vm-kmem-map-free> </vm-kernel-state> </system-virtual-memory-information> <cli> <banner></banner> </cli> </rpc-reply>
In JUNOS Releases 10.1 and earlier, the | display XML option for this command does not have an XML API element and the entire output is displayed in a single <output> tag element. [System Basics and Services Command Reference]
PIC combination limitations on M7i, M10i, and M120 routersIn most cases, you can install PICs of different media types in a router. However, configuration rules might limit certain combinations of PICs. For M7i and M10i routers, some PICs of different PIC families cannot be installed in PIC slots 0 and 1, or in slots 2 and 3. For M120 routers, some PICs of different PIC families cannot be installed in the same FPC. If you have different PIC families in the router and are running JUNOS Release 10.2 or later, review the configuration rules to plan which PICs to install in your router. Consult the most recent technical bulletins about configuration rules for PIC combinations on the Juniper Networks Support site at http://www.juniper.net/support/. Newer JUNOS services for some PICs can require significant Internet Processor ASIC memory. Ethernet and SONET PICs typically do not use large amounts of memory. Gigabit Ethernet, ATM2, IQ serial PICs, IQE PICs, and MultiServices PICs use more. To conserve memory, you can group PICs in the same family together on the same FPC. As a workaround, you can:

Install one PIC in a different PIC slot. Remove one of the PICs from the router.
Additional output line in the show system statistics ip commandThe show system statistics ip command now includes a new output line number incoming raw packets dropped due to no socket space to display statistics on packets dropped due to the kernel socket buffer being full. [System Basics and Services Command Reference]
Enhancement to the show chassis fabric sibs commandThe plane unusable by # pfes string in the show chassis fabric sibs command output in the plane state: output field has now been modified to the plane has link errors on # pfes. This indicates that the
52
plane is still usable but has link errors on the number of PFEs indicated. However, it doesnt indicate destination errors. [System Basics and Services Command Reference]
New command to clear Link Aggregation Control Protocol statisticsA new command, clear lacp statistics, enables you to clear Link Aggregation Control Protocol (LACP) statistics. Use the interfaces option to clear interface statistics. You can also clear interface statistics for a specific interface only by using the interfaces interface-name option. [Interfaces Command Reference]
Change to the show interfaces aenumber extensive commandThe output of the show interfaces aenumber command no longer displays Link Aggregation Control Protocol (LACP) statistics. To display LACP statistics, use the show lacp statistics interfaces command. [Interfaces Command Reference]
The jcs:load-configuration template now accepts the $commit-options parameterThe jcs:load-configuration template, included in the import file junos.xsl, now accepts the $commit-options parameter to customize the commit operation. The parameter must be passed to the jcs:load-configuration template as a nodeset. The default value for $commit-options is null. Supported options are:
checkChecks the correctness of the candidate configuration syntax, but does not
commit the changes.
force-synchronizeForces the commit on the other Routing Engine (ignores any
warnings).
logWrites the specified message to the commit log. This is identical to the CLI
configuration mode command commit comment.
synchronizeSynchronizes the commit on both Routing Engines.
To specify commit options, include the desired options within the <commit-options> tag. Use the := operator to create a nodeset and assign it to a variable. Pass this variable in as the argument for the $commit-options parameter when you use the jcs:load-configuration template. For example, to commit the configuration with the synchronize and log options, use the following syntax for the node-set:
var $options := { <commit-options> { <synchronize>; <log> "synchronizing commit"; } }
[JUNOS Configuration and Diagnostic Automation Guide]
53
Modification to the output of the show dhcp/dhcpv6 relay/server binding commandsThe output of the show dhcp server binding summary command, the show dhcp relay binding summary command, and the show dhcpv6 server binding command has been modified to include the number of clients in the init state and the requesting state. [Subscriber Access]
Disable IRB packet from being mirrored as a Layer 2 packetIf you associate integrated routing and bridging (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). [Layer 2 Configuration]
Configuring the 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. [Layer 2 Configuration]
MPLS Applications
Optimal path for bypass LSPsTo ensure that bypass LSPs take the most optimal path to reach their destination, they are now rerouted automatically when you configure or change the configuration of any of the following:
Administrative group for a bypass LSPadmin-group statement at the [edit protocols rsvp interface interface-name link-protection] hierarchy level Fate sharing groupgroup statement at the [edit routing-options fate-sharing] hierarchy level IS-IS overloadoverload statement at the [edit protocols isis] hierarchy level LSP metricmetric statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level
This functionality requires that you configure the optimize-timer statement for link protection at the [edit protocols rsvp interface interface-name link-protection] hierarchy level. [MPLS]
64 character support for bypass LSP nameYou can now configure the name of a bypass LSP using up to 64 characters. You configure a bypass LSP name using the bypass statement at the [edit protocols rsvp interface interface-name link-protection] hierarchy level.
54
[MPLS]
Platform and Infrastructure
Enhancement to show interfaces commandThe show interfaces command includes a new field, INET6 Address flags, that displays a flag for any IPv6 address that is in a state other than permanent or ready-to-use. [Interfaces Command Reference]
Option to enable enhanced jtree memory allocation for Layer 3 VPNs (T640 and T1600 routers with Enhanced Scaling FPC3 and Enhanced Scaling FPC4)For T Series routers only. With JUNOS Release 10.2, enhanced jtree memory allocation is turned OFF by default. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all the affected FPCs to activate the configuration. For JUNOS Release 9.3 to 10.1, the default routing tables (inet.0 and inet6.0) use both memory segments by default. [System Basics]
Three-color policers (M120 and MX Series routers)On MX Series and M120 routers, you can apply three-color policers to aggregated interfaces. [Class of Service]
New configuration to avoid IDP traffic loss (M120, M320, MX960, MX480, and MX240 routers)When the Multiservices PIC or DPC configured for a service set is either administratively taken offline or undergoes a failure, all traffic entering the configured interface with an IDP service set is dropped without notification. To avoid this traffic loss, include the bypass-traffic-on-pic-failure statement at the [edit services service-set service-set-name service-set-options] hierarchy level and (for TCP traffic only) the ignore-errors tcp statement at the [edit interfaces interface-name services-options] hierarchy level. When you configure these statements, the affected packets are forwarded, in the event of a Multiservices PIC or DPC failure or offlining, as though interface-style services are not configured. [Services Interfaces]
Border Gateway Function (BGF)Emergency calls are accepted even while the BGF is in the draining state due to a graceful shutdown if you enter the set accept-emergency-calls-while-graceful configuration statement at the [edit services pgcp gateway gateway-name h248options] hierarchy level. [Session Border Control Solutions, Services Interfaces]
55
Enhancement to APPID, AACL, and L-PDF processing for APPID best-effort application identificationOn MX960, MX480, or MX240 routers with Multiservices DPCs, and M120 or M320 routers equipped with Multiservices 400 PICs, APPID application identification of TCP, UDP, and ICMP flows supports a best-effort application determination as follows:
When a best-effort application determination is made, AACL does not apply any AACL term actions configured for that flow. Instead, AACL or L-PDF tracks the flow and accepts all packets for that flow until a final determination is made, at which time the normal AACL or L-PDFL actions are fully applied to the flow. During the time that APPID has not yet made a final determination of the application associated with a given flow, the flow does not contribute to any per-subscriber or per-application statistics collection. During the time that APPID has not yet made a final determination of the application associated with a given flow, the flow is included in the output of the following operational mode commands:
show services local-policy-decision-function flows (interface interface-name | subscriber subscriber-name)
show services application-aware-access-list flows (interface interface-name | subscriber subscriber-name)
In the command output, the Action field displays "accept" and the Application or Application group field displays unknown for a flow for which APPID has not yet made a final determination.
If a flow ends before APPID has made either a final or a best-effort application identification, AACL or L-PDF uses the "unknown" application ID as a final determination and performs any necessary collection, aggregation, and reporting of statistics based on that Layer 7 application. In particular, if the count AACL term action is configured for the "application-group-any" application, then the statistics for that flow will be collected and aggregated against the count bucket type, and reported as such. If a flow ends while the application identification is on a best-effort basis, AACL or L-PDF uses that best-effort determination as a final determination. AACL or L-PDF performs any necessary collection, aggregation, and reporting of statistics based on that Layer 7 application. In particular, if the count AACL term action is configured for that Layer 7 application, then the statistics for the flow will be collected and aggregated against the AACL or L-PDF statistics.
[Services Interfaces]
The control source component of the dynamic flow capture architecture supports multiple content destinations for DTCP/0.7 implementations of DTCP ADD requestsThe JUNOS Software substantially supports DTCP: Dynamic Tasking Control Protocol, specified in draft-cavuto-dtcp-03.txt at http://www.ietf.org/internet-drafts. In particular, the JUNOS Software supports the current version string for this release of the DTCP protocol: DTCP/0.7. The JUNOS Software dynamic flow capture
56
architecture now enables control sources (clients that monitor electronic data or voice transfer over the network) to process version 0.7 implementations of DTCP ADD request messages that specify multiple content destinations.
NOTE: For implementations of the DTCP protocol earlier than version 0.7, dynamic flow capture does not support DTCP ADD request messages that specify multiple content destinations. If a control source receives a DTCP-ADD request that specifies multiple content destinations but also contains a DTCP protocol version string earlier than DTCP/0.7, the control source rejects the request by sending a response message with the response code 432: Improper Filter Specification.
Differences between the DTCP/0.7 protocol specification and the DTCP/0.5 and DTCP/0.6 protocol specifications are described in APPENDIX A: Prior Implementation of the current Internet draft. [Services Interfaces, Hierarchy and Standards]
Border Gateway Function (BGF) media-service entity removed from the CLIThe media-service entity has been deprecated from the CLI. The media-service configuration statement pointed to a NAT pool to be used by a pgcp rule or virtual interface. Now, you should specify the NAT pools directly in the configuration statements for the pgcp rule or virtual interface. [Session Border Control Solutions, Services Interfaces]
Integrated Multi-Service Gateway (IMSG)The following statements have been replaced with new versions that provide filtering by server or service point:
The show services border-signaling-gateway calls statement is replaced by the show services border-signaling-gateway calls by-server and show services border-signaling-gateway calls by-service-point statements. The show services border-signaling-gateway calls-failed statement is replaced by the show services border-signaling-gateway calls-failed by-server and show services border-signaling-gateway calls-failed by-service-point statements. The show services border-signaling-gateway calls-duration statement is replaced by the show services border-signaling-gateway calls-duration by-server and show services border-signaling-gateway calls-duration by-service-point statements.
[Session Border Control Solutions, Systems Basics and Services CR]
Integrated Multi-Service Gateway (IMSG)You can now use the JUNOS Software CLI to restart a specific border signaling gateway (BSG) by using the restart services border-signaling-gateway gateway gateway-name command. [Session Border Control Solutions ]
Border Gateway Function (BGF) BTLB requirementsThe BGF pgcpd process running on a control service PIC now runs as a block translation look-aside buffer (BTLB) process. In order to correctly activate the process, you must include the following CLI configuration statements:
57
set chassis fpc fpc # pic pic # adaptive-services service-package extension-provider wired-process-mem-size 512
set chassis fpc fpc # pic pic # adaptive-services service-package extension-provider wired-max-processes 8
[Session Border Control Solutions]
IPsec policy for dynamic endpointsWith JUNOS Release 10.2 you can now specify the IPsec policy for dynamic endpoints. To specify an IPsec policy for dynamic endpoints, define the policy and its proposals under the [edit services ipsec-vpn ipsec] hierarchy level. Specify the policy name by including the ipsec-policy policy-name statement at the [edit access profile profile-name client* ike] hierarchy level. If no policy is set, any policy proposed by the dynamic peer will be accepted. [Services Interfaces]
Integrated Multiservice Gateway (IMSG) maximum number of policies and policy-related entities per Border Signaling Gateway (BSG)The following table shows the maximum number of policies and related entities:
Table 3: Maximum Number of Policies and Related Entities

Entity
Policies (total of new call usage and new transaction policies) per BSG New call usage policies per BSG New transaction policies per BSG Policies per service point Service points per BSG Terms per policy Terms per BSG Total of AND and OR operators in a policy term
Maximum
750 500 500 10 100 20 10,000 4
[Session Border Control Solutions]
58
Modification to the show pppoe interfaces command (M120, M320, MX Series, and J Series routers)In JUNOS Release 9.5 and later, the extensive option for the show pppoe interfaces command is supported only for J Series routers, which can be configured as PPPoE clients. The show pppoe interfaces command no longer supports the extensive option for M120, M320, and MX Series routers in JUNOS Release 9.5 and later. When an M120, M320, or MX Series router is configured as an access concentrator server, the statistics for the PPPoE server interfaces do not increment. As a result, when you issue the show pppoe interfaces extensive command on an M120, M320, or MX Series router, the statistics are always displayed as zeros. [Interfaces Command Reference]
Enhancement to the clear pppoe statistics command (M120, M320, MX Series, and J Series routers)The clear pppoe statistics command includes a new option, underlying-interface-name, for M120, M320, and MX Series routers in JUNOS Release 9.5 and later. The option enables you to reset the statistics of the underlying PPPoE interface for static and dynamic PPPoE interfaces. In JUNOS Release 9.5 and later, the interface interface-name option for the clear pppoe statistics command is supported only for J Series routers. The clear pppoe statistics command no longer supports the interface interface-name option for the M120, M320 and MX Series routers in JUNOS Release 9.5 and later. [Interfaces Command Reference]
Address assignment for dynamic PPPoE subscriber interfaces (M120, M320, and MX Series routers)If the subscriber address for a dynamic PPPoE interface is not specified by means of the Framed-IP-Address (8) or Framed-Pool (88) RADIUS IETF attributes during authentication, the router allocates an IP address from the first IPv4 local address-assignment pool defined in the routing instance. For this reason, make sure that the local address assigned for the inet (IPv4) address family is in the same subnet as the addresses obtained from the first IPv4 local address-assignment pool. The router allocates the IP address from the first IPv4 local address-assignment pool under either of the following conditions:

RADIUS returns no address attributes. RADIUS authentication does not take place because only address allocation is requested.
If the first IPv4 local address-assignment pool has no available addresses, or if no IPv4 local address-assignment pools are configured, the router does not allocate an IP address to the dynamic PPPoE subscriber interface and denies access to the associated subscriber. To avoid depletion of IP addresses, you can configure linked address-assignment pools on the first IPv4 address-assignment local pool to create one or more backup pools. [Subscriber Access]
59
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 JUNOS Release 10.1 and later, DHCP snooping is disabled by default. [Subscriber Access]
Configuring default values for predefined variablesYou can now configure default values for certain JUNOS predefined variables. If the external RADIUS server is not available or the vendor-specific attribute (VSA) does not contain a value for the predefined variable, the JUNOS Software uses the default values. To configure default values, include the predefined-variable-defaults predefined-variable variable-option default-value statement at the [edit dynamic-profiles profile-name] hierarchy level. [Subscriber Access]
Modifications to the RADIUS revert-interval statementThe default setting and range have changed for the revert-interval statement at the [edit access profile profile-name radius options] hierarchy level. You can now set a revert interval in the range from 0 (off) through 4,294,967,295 seconds. The default setting is now 60 seconds. [Subscriber Access]
Required pppoe-options subhierarchy for configuring static and dynamic PPPoE interfaces (M120, M320, MX Series routers)When you configure a static or dynamic pp0 (PPPoE) logical interface, you must include the pppoe-options subhierarchy in the configuration. Failure to include the pppoe-options subhierarchy causes the commit operation to fail. This requirement is in effect for configuration of static PPPoE logical interfaces as of JUNOS Release 10.2 and later, and has always been in effect for configuration of dynamic PPPoE subscriber interfaces in a PPPoE dynamic profile. For example, the following configuration now causes the commit operation to fail for both static and dynamic PPPoE logical interfaces:
pp0 { unit 0 { }
To configure a static PPPoE logical interface in JUNOS Release 10.2 and higher-numbered releases, you must include the pppoe-options subhierarchy at the [edit interfaces pp0 unit logical-unit-number] hierarchy level or at the [edit logical-systems logical-system-name interfaces pp0 unit logical-unit-number] hierarchy level. At a minimum, the pppoe-options subhierarchy must include the name of the
60
PPPoE underlying interface and the server statement, which configures the router to act as a PPPoE server. For example:
[edit interfaces] ... pp0 { unit 0 { pppoe-options { underlying-interface ge-1/0/0.0; server; } ... } }
To configure a dynamic PPPoE subscriber interface in a PPPoE dynamic profile, you must include the pppoe-options subhierarchy at the [edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit] hierarchy level. At a minimum, the pppoe-options subhierarchy must include the name of the underlying Ethernet interface, represented by the $junos-underlying-interface predefined dynamic variable, and the server statement. For example:
[edit] dynamic-profiles { pppoe-profile { interfaces { pp0 { unit "$junos-interface-unit" { pppoe-options { underlying-interface "$junos-underlying-interface"; server; } ... } } } } }
[Network Interfaces, Subscriber Access]
VPNs
New configuration statement for removing dynamically learned MAC addresses from the MAC address databaseMedia access control (MAC) flush processing removes MAC addresses from the MAC address database that have been learned dynamically. With the dynamically learned MAC addresses removed, MAC address convergence requires less time to complete. In this release, you enable MAC flush processing for the virtual private LAN service (VPLS) routing instance or for the mesh group under a VPLS routing instance by using the mac-flush statement instead of the mac-tlv-receive and mac-tlv-send statements.
mac-flush [ explicit-mac-flush-message-options ];
61
You can include the statement at the following hierarchy levels:
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]
[edit routing-instances routing-instance-name protocols vpls] [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]
NOTE: The mac-tlv-receive and mac-tlv-send statements were removed from Release 10.0 of the JUNOS Software and are no longer visible in the
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls] and [edit routing-instances routing-instance-name protocols vpls] hierarchy levels. Although the mac-tlv-receive and mac-tlv-send statements are recognized in the current
release, they will be removed in a future release. We recommend that you update your configurations and use the mac-flush statement.
To also configure the router to send explicit MAC flush messages, you can include explicit-mac-flush-message-options with the statement. [VPNs]
SCU support for VRF routing instances with vrf-table-label configuredYou can now configure source class usage (SCU) to count packets on Layer 3 VPNs configured with the vrf-table-label statement. Include the source-class-usage statement at the [edit routing-instances routing-instance-name vrf-table-label] hierarchy level. The source-class-usage statement at this hierarchy level is supported only for the virtual routing and forward (VRF) instance type. Previously, you could not enable SCU when the vrf-table-label statement was configured. Destination class usage (DCU) is not supported when the vrf-table-label statement is configured. [VPNs, Network Interfaces]
Related Documentation
New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 7 Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63 Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers on page 118 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 127
62
Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers
The current software release is Release 10.2R4. For information about obtaining the software packages, see Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 127.

Current Software Release on page 63 Previous Releases on page 96
Current Software Release

Outstanding Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers Class of Service
When a VLAN ID is changed, the following message appears in the messages log: "COSD_GENCFG_WRITE_FAILED: GENCFG write failed for Classifier to IFL 74. Reason: File exists. This log message appears when the configuration is committed with VPLS configured on the Gigabit Ethernet interface, and a class-of-service classifier or rewrite rules that contain IEEE 802.1P on the interface are used. [PR/408552]
A high CPU utilization by the dfwd process might occur if the interface lo0 is configured as part of the interface group 0. [PR/497242] When a VPLS MAC table is cleared by interface name, the operation halts with the error message "error: Unrecognized command". [PR/544324] From Junos OS Release 10.1 and later, the SNMP MIB walk for jnxFWCounter does not work. [PR/551857] On M Series, T Series, and J Series routers, when the installation of a filter that contains a logical interface policer or a physical interface policer fails (for example, due to insufficient jtree memory), the FPC might crash. [PR/579271] When port mirroring is performed with an output filter, and the firewall log feature is enabled, duplicate packets are seen. [PR/583076]
High Availability
The SSH keys are not in sync between the master and backup Routing Engine when SSH is enabled after a graceful Routing Engine switchover (GRES). [PR/455062] When an ISSU upgrade is performed to or from JUNOS Releases 9.6R3 or 10.0R2, the logical interface and logical interface sets that have traffic control profiles configured on them will be affected. [PR/491834] When the standby Routing Engine is upgraded, ISSU aborts with the error message replication_err soft_mask_err. [PR/508028] An intermittent failure in the non-stop Routing Engine might cause a core file to be generated. However, the system does not go down. [PR/527686]
63
When DPCE-R-40GE-TX interfaces are configured at a non-default speed (10m or 100m), and a unified in-service software upgrade is performed, packets are lost for 60 seconds. [PR/573353] If the management interfaces (for example, fxp0) are configured under a non-default routing instance with graceful Routing Engine switchover enabled, the graceful Routing Engine switchover fails. [PR/592125]
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 that does not support this alarm. [PR/103444] When the Rx power level is a negative value, the SFP diagnostics output displays an invalid receiver power level reading. [PR/235771] 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] If a firewall show command is followed by the clear command in a very quick succession, there is a possibility that the show command will time out. If the show command is issued after a few seconds (five seconds ideally), this issue will not be seen. [PR/479497] On the T1600 router, the output of the show chassis hardware models and show chassis hardware clei-models commands does not display the T1600 PICs. [PR/481623] On a 4x CHOC3/CHSTM1 SONET CE SFP PIC, if a SONET Automatic Protection Switching (APS) is configured on COC3/CSTM1 interfaces and an IMA group is created, APS will not work for those IMA groups. There is no workaround. [PR/513343] When the VRRP6 master changes, there is no log output for VRRP IPv6. [PR/514821] Discrepancies exist in MAC and filter statistics between Trio MPC and Enhanced DPCs. [PR/517926] A native-vlan-id option with the value of 0 does not permit untagged packets to be accepted on the interface. [PR/525875] The output of the show chassis environment pem command displays the voltage used in FPC slots 0 through 3, even after the FPC is taken offline. [PR/528821] The "multipoint-destination" configuration statement is not supported on IQE PICs. While the configuration of this statement is accepted without problems initially, subsequent reconfiguration of the interface might cause the FPC and Packet Forwarding Engine to reboot. [PR/529423]
64
On a 20-Port Gigabit Ethernet Enhanced Queuing IP Services DPC with SFP (DPCE-R-Q-20GE-SFP) and 2-Port 10-Gigabit Ethernet Enhanced DPC with XFP (DPCE-R-2XGE-XFP), the link status of the interface goes down when the router toward the peer is removed. [PR/542668] On M320 routers with E3-based FPCs, the MAS value of the queue on Fast Ethernet interfaces do not match the buffer size configuration when a low temporal value is used in the configuration. [PR/553909] In previous Ethernet OAM 802.1ag implementation, an extra 8 bytes (0019 0008 0000 0000) are found in the CFM delay measurement reply (DMR) and loopback reply (LBR) messages when compared with the original delay measurement message (DMM) and loopback message (LBM). The extra bytes do not impact the normal DMM and DMR, or LBM and LBR processing. [PR/557513] When MAC address filters are configured on an aggregated Ethernet interface, the MAC filters might not be programmed on the child link of the aggregated Ethernet interface if and only if the following sequence of events occur:
1.
The aggregated Ethernet interface is disabled through a configuration change.
2. A graceful Routing Engine switchover occurs and the aggregated Ethernet interface
is subsequently enabled on the new master Routing Engine. [PR/561106]
On the same PIC slot of a 20-port 1-Gigabit Ethernet Enhanced DPC and 2-port 10-Gigabit Ethernet Enhanced DPC, any Tri-Rate Copper SFP transceiver with the auto-negotiation statement configured under the [show interfaces interface-name gigether-options] hierarchy level bounces when an SFP-SX fiber is plugged or unplugged. [PR/564121] When graceful Routing Engine switchover is configured on the backup Routing Engine, some situations might lead to the next-hop cleanup not being performed properly. [PR/566885] The output of the show interfaces descriptions routing-instance routing-instance-name command displays other interfaces that do not belong to the requested routing instance. [PR/575096] The output of the show chassis power command displays the DC output value even when PEM is switched off. [PR/589866] When a port is configured for wan-phy framing, input framing errors occur when the sending port is a 10-port 10-Gigabit Ethernet PIC. [PR/598618]
The release message is not sent to the DHCP server, even though the send-release-on-delete flag is set under the DHCP relay configuration. As a workaround, to deactivate or deconfigure an interface, clear all the bindings on the interface before you deactivate or delete the interface. To deactivate or deconfigure the relay, clear all the bindings before you deactivate or delete the relay. [PR/498920]
65
Configuring passive clients to run on demultiplexer interfaces does not result in the access-internal route pointing to the client demultiplexer interface as expected. When configuring passive clients on demultiplexer interfaces, keep the following in mind:
Configuring passive clients on demultiplexer interfaces requires specific static route additions to function properly. Only unnumbered demultiplexer interfaces are supported. However, the underlying interface can be either numbered or unnumbered.
When configuring passive clients over demultiplexer interfaces by using unnumbered underlying interfaces, you must add static routes for both the client-facing and DHCP server-facing interfaces on the router as follows:
The configuration for the server-facing interface must contain the route IP address of the DHCP relay agent and the qualified next-hop interface value to the server. The configuration for the client-facing interface must contain the link address for the next-hop IP address of the server-facing interface and must be configured to resolve that IP address.
When configuring passive clients over demultiplexer interfaces by using numbered underlying interfaces, you must add a static route such that the client-facing interface configuration contains a next-hop address that points to the DHCP server-facing interface on the router. [PR/511676]
The output of the show chassis fabric summary command displays the active fabric LED as "Active" (solid green) while all of the other fabric planes on the concerned SCB as "Spare". [PR/594736]
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] 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] During an RSVP local repair process, when a link flaps or the IGP metric changes along the LSP path, the routing protocol process scheduler slips. [PR/513312] The RSVP sessions through unnumbered interfaces, with advertise-unnumbered-interfaces enabled under OSPF traffic engineering, are not replicated on the backup Routing Engine. [PR/525297] When a commit is performed, the RSVP PATH messages are clustered together for a link or node protected interface from the current RSVP implementation. This might result in dropped RSVP path messages on the neighboring Juniper Networks routers as the queue for these packets becomes overwhelmed. [PR/536190] On M Series and T Series routers, the MPLS label-switched path (LSP) log messages are not logged for nonstandby secondary MPLS LSPs. [PR/560069]
66
In the event where the first label-switched path (LSP) displayed in the output of the show mpls lsp command is down, the following LSP that is up is used for a sufficient number of routes. The LSP that is down might be duplicated in the output from time to time. This is a cosmetic issue. [PR/588714] On MX80 routers, an SNMP walk for LDP tables might cause the routing protocol process to crash. [PR/589923] Packet loss on local traffic occurs inside a VRF when composite next-hops and per-packet load-balancing are configured. [PR/600951]
Network Management
The SNMP process may restart after a core dump is generated. [PR/517230]
On T Series routers, a Layer 2 maximum transmission unit (MTU) check is not supported for MPLS packets exiting the routing platform. [PR/46238] When you configure a source class usage (SCU) name with an integer (for example, 100) and use this source class as a firewall filter match condition, the class identifier might be misinterpreted as an integer, which might cause the filter to disregard the match. [PR/50247] If you configure 11 or more logical interfaces in a single VPLS instance, VPLS statistics might not be reported correctly. [PR/65496] When a large number of kernel system log messages are generated, the log information might become garbled and the severity level could change. This behavior has no operational impact. [PR/71427] Traceroute does not work when ICMP tunneling is configured. [PR/94310] 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] 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]
67
In some cases, the alarms displayed in the FPM and the alarms shown using the show chassis alarms sfc 0 command do not match. [PR/445895] The SFC management interface em0 is often displayed as fxp0 in several warning messages. [PR/454074] On restart with a large-scale configuration (16K IFLs per MPC), the MPC-3D-16XGE-SFPP card might take up to 15 minutes to come up. [PR/478548] 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] The TTL on the wire is one less than the tunnel TTL configured through the CLI. [PR/506454] The data channel applications for protocols such as FTP, TFTP, RTSP, and SIP are not in the same application group as their control channel applications. For example, the control channel application junos:ftp is in the group junos:file-server but its corresponding data application junos:system:ftp-data is not in any group. [PR/507865] When an SIB is taken offline without using the CLI or the offline button and brought back online, the link error alarm does not clear. [PR/536673] Bouncing DHCP subscribers on demultiplexer interfaces can result in subsequent login failures. [PR/550211] After an upgrade to JUNOS Release 10.1 or later, load sharing does not work with Ethernet Layer 2 Virtual Private Networks and circuit cross-connect (CCC) traffic. [PR/573934] When snooping bridge-domain or VPLS instance with snooping enabled is deleted, or a change is made to the virtual LAN ID of the VPLS instance where snooping is enabled, the following system log error entries is reported by the Packet Forwarding Engine:
RT: Failed prefix delete IPv4 - 0.83.0.1.0.82.224/52 (invalid prefix for IGMP snooping) on FE 0 RT: Failed prefix delete IPv4:86 - 0.83.0.1.0.82.224/52 (jt delete failed) RT: Failed prefix delete IPv4:86 - 0.83.0.1.0.82.224/52 (rt delete failed) rt_jtree_topo_handler, route topo (pfx 0.101.0.1.0.99.224/52) getting disconnected, installing discard RT(rt_entry_snoop_find_prefixes): No bd structure found for bd_index = 101 rt_jtree_change: prefix is not correct
[PR/590139] Routing Policy and Firewall Filters
The following features are not supported in a 10-Gigabit Ethernet MPC with SFP+:
Known unicast and unknown unicast types in the input match condition 'Traffic-type' in a family bridge/VPLS Match conditions:

learn-vlan-1p-priority learn-vlan-1p-priority-except
68
learn-vlan-id learn-vlan-id-except user-vlan-1p-priority user-vlan-1p-priority-except user-vlan-id user-vlan-id-except
VPLS flood FTF and input FTF Simple filters Filter action 'then ipsec-sa' Filter action 'then next-hop-group' Mac-filter output accounting and output policing
[PR/466990] Routing Protocols
When you configure damping globally and use the import policy to prevent damping for specific routes, and a new route is received from a peer with the local interface address as the next hop, the route is added to the routing table with default damping parameters, even though the import policy has a non-default setting. As a result, damping settings do not change appropriately when the route attributes change. [PR/51975] When you issue the show ldp traffic-statistics command, the following system log message might be generated for all forwarding equivalence classes (FECs) with an ingress counter set to zero: "send rnhstats GET: error: ENOENT Item not found." [PR/67647] If ICMP tunneling is enabled on the router and you configure a new logical system that does not have ICMP tunneling enabled, the feature is globally disabled. [PR/81884] Setting the advertise-high-metric option while using IS-IS overload also suppresses route leaking. [PR/419624] When aggregate interfaces are used for VPN applications, load balancing might not happen with a Layer 2 circuit configuration. [PR/471935] When a bootstrap message source address is resolved through an interface that is directly connected, the bootstrap message is dropped and not used in the bootstrap router (BSR) election process. [PR/482178] The BGP BMP message for IPv6 withdraw encoding does not follow the BMP-draft. [PR/512780] Under certain circumstances, the BGP path selection does not follow the local preference. This might lead to incorrect BGP path selections. [PR/513233]
69
A invalid configuration with a secondary disabled loopback address might commit successfully, and a firewall filter from this disabled loopback interface might get applied to the master routing table. [PR/515598] The interface name information is missing in the BFD trap and system log message that is generated when a session is up or down for OSPF routes and static routes. [PR/524882] When a certain combination of route damp parameters is configured for BGP, the resulting internal calculations result in an attempt to allocate 0 bytes of memory causing the routing protocol process to crash and restart. As a workaround, avoid the exact combination of poison values in the configuration. [PR/534780] When an interface is added to a routing instance with rpf-check enabled, the routing protocol process might crash if a route-distinguisher is also changed at the same time. [PR/539321] A rare race condition might cause the routing protocol process to crash when an (s,g)/(*,g) entry is removed. [PR/551949] In JUNOS Release 10.0 and later, a direct route to a VRF with a rib-group is not advertised as an inet-vpn route to the IBGP neighbor due to the error "BGP label allocation failure: Need a nexthop address on LAN." [PR/552377] On M Series, MX Series, and T Series routers, the Virtual Router Redundancy Protocol (VRRP) process might become unresponsive when processing is delegated to the Packet Forwarding Engine. As a workaround, remove the delegate-processing option from the [protocols vrrp] hierarchy level. [PR/559033] IS-IS might not use the MPLS label-switched paths (LSPs) if the first 32 characters in the names of the label-switched paths are similar. [PR/568093] On a router configured with IS-IS link protection, the routing protocol process might dump core when there are many prefix updates following an interface flap. [PR/572878] The routing protocol process crashes when the following three events occur:

Flow routes are configured. Both dfwd and the routing protocol process shut down due to a reboot. The dfwd process takes the libdfwd connection down before the routing protocol process cleans up.
[PR/574753]
The configuration of DSCP rewrite rules on a 10-port 10-Gigabit Ethernet LAN/WAN PIC with SFP+ might overwrite the DSCP value from the Routing Engine for a host-generated traffic. [PR/575259] The routing protocol process on a standby Routing Engine might crash during an unified in-service software upgrade (unified ISSU) if the BGP peers flap. [PR/575569] When local AS and auto-export are configured in a hub-spoke environment, hidden routes might exist. [PR/578833]
70
The show bgp replication command on the master Routing Engine might sometimes get struck at the "InProgress" state. [PR/589783] Under certain circumstances, PIM might sent a (S,G,rpt) prune message to the rendezvous point (RP) even before the corresponding (* , G) is sent to the rendezvous point. This results in the multicast traffic flowing through the RPT for a minute until it sends a periodic J/P message. [PR/598735]
When a routing platform is configured for graceful Routing Engine switchover (GRES) and Adaptive Services (AS) PIC redundancy, and a switchover to the backup Routing Engine occurs, the redundant services interface (rsp-) always activates the primary services interface (sp-), even if the secondary interface was active before the switchover. [PR/59070] Detection of failure of remote PPP clients on the LNS through LCP echo requests will take longer due to the increase in the number of echo request retries. [PR/250640] When a standard application is specified at the [edit security idp idp-policy policy-name rulebase-ips rule rule-name match application] hierarchy level, the IDP does not detect the attack on the non-standard port (for example, junos:ftp on port 85). [PR/477748] The output of the show services ids destination-table command might not display any flow and related statistics in the IDS anomaly table for a certain period of time after the flows are activated. [PR/490584] After a user establishes an SSH connection, the sshd process is started on the server and is available for the user. After the connection is established, the sshd process listens on a socket and keeps polling in the select() until there is something to be processed on the socket. When the client closes the connection, a message is sent on the socket to the server, which reads and processes the connection tear-down. However, when a blocking tcp is sent to the client to detect the client's presence, the timeout never expires. [PR/538342] When unit 0 of the Multiservices PIC interface is not specified, the monitor interface traffic command does not display the input packets number properly for that particular ms-I/F interface. [PR/544318] When an SNMP walk is performed on the jnxSpSvcSetSvcType object or any of its subobjects, the SPD_DB_SVC_SET_ADD_FAILURE log message is seen. [PR/546808]
71
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]
User Interface and Configuration
The Local Password:" prompt appears even though the authentication order has a password configured. [PR/94671] The logical system administrator can modify and delete master administrator-only configurations by performing local operations such as issuing the load override, load replace, and load update commands. [PR/238991] After AI scripts are added, the existing management sessions (including the one used to add the AI scripts) must exit the edit mode and reenter for any subsequent configuration changes to take effect. Changes made in these existing edit sessions are not written to the candidate configuration. [PR/297475] On the J-Web interface, the Generate Report option under the Monitor Event and Alarms page opens the report in the same web page. [PR/433883] 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] When a new-line character (\n) is used within the op script argument descriptions, the help output might display incorrectly, and could result in extra output being displayed when the op script executes. [PR/485253] 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] The J-Web interface does not display the drop-profile-map, excess-priority, excess-rate, and rate-limit (transmit rate) parameters that are supported for the configuration of the schedulers. Use these parameters using the CLI. [PR/495947] Invalid XML characters such as &#x11 (0x11) or &#20 (0x14) are allowed to be loaded into the router. As a result, the XML parsers break as the characters are not XML compliant. [PR/502994] Under certain circumstances, the event script time intervals might be overridden by too many events because of a small eventd process buffer size. Specifically, in the case of Service Automation (AIS) event scripts in the AI-script bundle pushed from Servicenow. This might cause the same type of Juniper Message Bundle (JMB) event to be generated more than once an hour. When this issue occurs continuously, it could lead to a permanent increase in the routing engine memory and CPU consumption, depending on the number of scripts running concurrently (maximum is 15). [PR/505359] The auto-complete feature is not disabled on the password fields of the J-Web interface. This could lead to a loss of confidentiality of the users if any of them use a shared host or their machine is compromised at some point. [PR/508425]
72
The delete interfaces | display set |match command deletes all the interface configuration. [PR/512821] In JUNOS Software Release 10.2, the upload and install package does not show warning messages when there are pending changes to be commited. [PR/514853] The show log xxx | last x command operates as if the screen length is set to 0, and the --more xx%-- prompt does not appear. [PR/517023] The annotate command does not show up when it is used under the edit private command for class-of-service. [PR/535574] Httpd dumps core intermittently when the J-Web pages are accessed. [PR/535768] When an HTTPS connection is used for the J-Web interface in Internet Explorer to save a report from the View Events page (Monitor>Events and Alarms>View events), the following error message is displayed Internet Explorer was not able to open the Internet site. This issue also appears in the following places on the J-Web interface:

maintain>config management>history maintain>customer support>support information>Generate Reports Troubleshoot port>Generate Reports maintain>files Monitor>Routing>Route Information>Generate Reports
[PR/542887]
The J-Web pages loads inconsistently when Add IPv4 or IPv6 filters are used in the Internet Explorer and Firefox Web browsers. [PR/543607] When a J-Web session is opened and the login credentials are provided, the J-Web interface takes 20 seconds longer to load the Dashboard page on an HTTPS connection than it does when an HTTP connection is used. [PR/549934] Under certain circumstances, a nested JUNOS configuration group with a wildcard match might not have the desired effect. [PR/556379] After the delete action is performed, the replace actions do not take effect in the load replace terminal operation. [PR/556971] The javascript error "Object Expected" occurs when J-Web pages are navigated before the page loads completely. [PR/567756] When a "validate" RPC is executed using a NETCONF session, some essential information about the session is not populated in the configuration database. [PR/570778] The show system rollback command does not work in the configuration mode, whereas the command works in the operational mode. [PR/580645]
73
VPNs
When you modify the frame-relay-tcc statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level of a Layer 2 VPN, the connection for the second logical interface might not come up. As a workaround, restart the chassis process (chassisd) or reboot the router. [PR/32763] On a router configured for nonstop active routing (NSR) (the nonstop-routing statement is included at the [edit routing-options] hierarchy level), if a nonstop active routing switchover occurs after the configuration for routing instances changes in certain ways, the BGP sessions between PE and CE routers might not be established after the switchover. [PR/399275] The BGP community 0xFF04 (65284) is incorrectly displayed as "mvpn-mcast-rpt" in the output of the show route command. [PR/479156] While upgrading JUNOS Software with l2circuit configuration under the logical systems, the validation might fail with an "interface version mismatch" error. You can ignore this error and upgrade the JUNOS Software using the no-validate option. [PR/497190] In JUNOS Software Release 9.2 and above, the auto-site-id database might get corrupted. This results in the routing protocol process to core when the VPLS configuration is changed. [PR/500351] In a Layer 2 Virtual Private Network setup where both the local and remote sites are configured on the same router, the local and remote interfaces are listed incorrectly in the output of the show l2vpn connections command. [PR/574014] Fragmenting IPsec packets between the originator and the end tunnel might cause an Encapsulating Security Payload (ESP) authentication failure at the end tunnel. [PR/603444] With nonstop active routing and a large number of LDP-based virtual private LAN service configured, the routing protocol process might crash during a graceful Routing Engine switchover event. [PR/610594]
Resolved Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers Class of Service
When the rate-limit option is configured on a physical interface on IQ2 PICs, the show interface queue command might not display the RL-dropped counters. [PR/547218: This issue has been resolved.] The egress rate-limit over a logical interface might drop large packets. [PR/547506: This issue has been resolved.] When only the family inet or MPLS is configured on an interface, the logical interface does not consider the default classifier slot for the ipprec-compatibility. [PR/556497: This issue has been resolved.] On T Series routers with non-ES type FPCs, changing the CoS scheduling or queuing parameters on an interface with a high traffic utilization (close to the line rate or oversubscribed) might cause the FPC that hosts the interface to restart. [PR/565307: This issue has been resolved.]
74
When a firewall filter that contains a packet loss priority (PLP) rewrite references a policer that also contains the PLP rewrite, the PLP bits of the packets matching the filter condition is first set on the PLP set action in the policer, and again set by the PLP set action on the firewall filter itself, which leads to a two-time PLP rewrite. [PR/566896: This issue has been resolved.] On MX Series routers with Enhanced Queuing DPCs and IQ2 or IQ2E PICs with scheduler map and rate limit applied to an interface or interface set, when one of the logical interfaces is deleted, the DPC or PIC might crash. [PR/572245: This issue has been resolved.]
Port mirroring does not work under the bridge-domain forwarding-option filter. [PR/529272: This issue has been resolved.] When a Routing Engine sampling is configured, and each flow server corresponds to a different autonomous system type, the packet size of the exported cflowd v5/8/500 packets might increase. [PR/530008: This issue has been resolved.] When logical systems are configured, the show bridge-domains command might time out and return the following error message: error: timeout communicating with l2-learning daemon. [PR/536604: This issue has been resolved.] On a sampled traffic on a Multiservices PIC, the multicast convergence slows down with the message "RPD_KRT_Q_RETRIES: Indirect Next Hop Update: No buffer space available." [PR/554363: This issue has been resolved.] When a loopback filter is configured, packets sent by the ASIC to the Packet Forwarding Engines CPU for generation of TTL expiry notification are dropped. [PR/555028: This issue has been resolved.] When firewall filters are configured with multiple terms that contain the same count variable and color-blind mode, the three-color policer might produce unexpected results in the firewall filter. To resolve this issue, use a unique count variable within each term. [PR/558550: This issue has been resolved.] The user-vlan-1p-priority matching term in the CCC MF family does not work when the tpid value in the traffic is 0x88a8. [PR/558866: This issue has been resolved.] The mib2d process might crash when a race condition exists between the mib2d process and the dfwd process. [PR/563419: This issue has been resolved.] Under rare cases, the mib2d process might crash. [PR/564360: This issue has been resolved.] On MX Series routers running JUNOS Release 10.2 and later, under certain circumstances, the show interface statistics command might get stuck (does not return anything). Additionally, the show pfe statistics traffic command returns the message "error: the mib-process subsystem is not responding to management requests" and SNMP queries fail. [PR/566681: This issue has been resolved.] When a firewall filter with multiple terms reference the same three-color policer, and has the same count variable configured, the IP packets that match the second or later
75
terms might be corrupted. Use different count variables in each term to prevent this issue. [PR/567546: This issue has been resolved.]
When a VPLS family firewall filter is configured on an interface, packets drop and MAC learning does not occur in some cases, for example, a router reboot. [PR/567635: This issue has been resolved.] The Radius Accounting Interim message might not be sent immediately after a Change of Authorization (CoA), even if the CoA is successfully processed and the coa-immediate-update option is present in the configuration. [PR/570058: This issue has been resolved.] On MX Series routers running JUNOS Release 10.2 and later, when a new link from a newly inserted FPC, DPC, or MPC is configured to an existing aggregate configuration, the newly added link information might not appear in the Link:, LACP info:, LACP Statistics:, and Marker Statistics: fields in the output of the show interface aex extensive command. Deactivate and then activate the aggregate interface to resolve this issue. [PR/571245: This issue has been resolved.] When a VPN routing and forwarding table (VRF table) is configured in a logical system, and there is no loopback filter configured in the VRF table while it is configured on the logical system and the default router, the packets destined for the VRF table reach the filter configured in the logical system. However, the packets are expected to reach the filter configured in the default route table. [PR/575060: This issue has been resolved.] A VLAN spanning tree protocol (VSTP) might leak memory, which might lead to memory exhaustion and impact on traffic. [PR/580153: This issue has been resolved.]
General Routing
The BGP processes changes in a committed import policy using a background job. If the BGP is already in the process of updating its routes from a change in the import policy, and the import policy is subsequently changed in another commit, the second commit's policy might not complete correctly. As a workaround, ensure that there are no outstanding BGP reconfiguration jobs in progress prior to committing a new import policy. Use the show task jobs command and search for BGP Reconfig from the output to verify this. [PR/550902: This issue has been resolved.] The routing protocol process crashes and does not start if the policy condition is enabled for IPv6. As a workaround, remove the policy condition for IPv6 from the configuration and restart the routing protocol process. [PR/553158: This issue has been resolved.]
High Availability
A replication error might occur when a user route with a local next hop is propagated to the backup Routing Engine before the corresponding IFA is replicated. [PR/559458: This issue has been resolved.] When a container interface (used in aggregated Ethernet interfaces) is freed in the memory, the child next hop (member link) on the master Routing Engine is also freed. However, in some cases, the child next hop on the backup Routing Engine is not freed, which results in a crash. [PR/562295: This issue has been resolved.]
76
The output of the monitor interface interface-name command is misaligned. [PR/70077: This issue has been resolved.] During initialization, some garbage data can flow into the unused SONET interface. This data is small in size and does not contain any SOP or EOP information. This data consumes some D4P buffer memory. The D4P buffer does not remove this data until more data comes into the buffer. Periodic health check reports the status as the data-path being stuck. To resolve this issue, purge the D4P buffer. [PR/424326: This issue has been resolved.] On a 10-port 10-Gigabit Ethernet, periodic threads take longer to complete when compared with other hardware. This might increase the average response time for traffic to and from the Routing Engine when it has to go through a 10-port 10-Gigabit Ethernet PIC port. However, this does not impact the transit traffic. [PR/506887: This issue has been resolved.] Upon a link up event, old packets from the previous link down are still dequeued. This leads to huge latency reports. [PR/515842: This issue has been resolved.] When multiple routed IPsec tunnels are configured, and the tunnel with the inside-service-interface defined in the service-set goes down, the other tunnels with the ipsec-inside-interface configured only in the IPsec rules can stop forwarding traffic until the main tunnel comes back up. [PR/524935: This issue has been resolved.] The queue counter of the aggregated Ethernet is counted up after the statistics is cleared and the FPC is restarted. [PR/528027: This issue has been resolved.] The output of the show chassis hardware detail | display xml command does not list the SSRAM modules as direct chassis submodules of the Switching and Forwarding Module SPR. [PR/529277: This issue has been resolved.] When Automatic Protection Switching (APS) is configured on a 4x STM-1 SDH, SMIR PIC, the transmitted value of the K2 byte shows 0x00 for both unidirectional and bidirectional instead of 0x04 and 0x05, respectively. [PR/531030: This issue has been resolved.] On Trio MPCs, multiple changes to a single term in quick succession results in an incorrect filter state in the Packet Forwarding Engine. This causes the MPC to crash. [PR/532791: This issue has been resolved.] An XE circuit on the 16-port 10-Gigabit Ethernet MPC with SFP+ (model number MPC-3D-16XGE-SFPP) might cause a high CPU utilization on the MPC. [PR/535057: This issue has been resolved.] On MX960 routers, the link status stays in the "Link ok" state when the SCB is removed without taking it offline using the CLI or switch. [PR/536860: This issue has been resolved.] When a Gigabit Ethernet or an XE interface on IQ2 PICs is disabled, and the link status is up, the traffic received from the interface might still be forwarded. [PR/543388: This issue has been resolved.]
77
When an IFF maximum transmission unit (MTU) size is configured less than the current MTU size, the message "MTU for address reduced to mtu" is added to the log file. [PR/544026: This issue has been resolved.] When one of the units of an aggregated Ethernet is deactivated, all the other units go down. [PR/544587: This issue has been resolved.] The MPC on MX Series routers might undergo an NMI reset after a reboot. [PR/545909: This issue has been resolved.] On a 10-Gigabit Ethernet PIC, a log is generated when the SFP is plugged in. However, no log is generated when the SFP is not plugged in. [PR/548251: This issue has been resolved.] On MX Series routers, when a fabric plane switchover occurs due to an active plane failure, the new active plane might not work correctly. This might cause severe traffic loss among DPCs and MPCs. [PR/549546: This issue has been resolved.] A connectivity fault management (CFM) ping command fails when the name of the maintenance domain or association is longer than 32 characters. [PR/550014: This issue has been resolved.] If a bridge domain contains more than one aggregated Ethernet interface, and the IRB interfaces experience the right sequence of MAC moves, the FPC might restart. [PR/550824: This issue has been resolved.] On a 10-port 10-Gigabit Ethernet LAN/WAN PIC with SFP+ (PD-5-10XGE-SFPP) for T Series routers, the reactions configurations under the [optics-options] statement do not take effect for "low-light" conditions. [PR/550851: This issue has been resolved.] On MX960 routers, the MPC might reset multiple times after an initial reset. [PR/551610: This issue has been resolved.] If the number of VPLS connection exceeds 31, frequent FPC and NPC crashes might occur. [PR/552099: This issue has been resolved.] The EOA family configurations over a container ATM interface might be deleted and added again upon every commit (including unrelated commits). [PR/553077: This issue has been resolved.] In a rare situation, changes made to a filter might not completely download to the Packet Forwarding Engine. This causes the MPC to crash. [PR/553288: This issue has been resolved.] After a link flap occurs at the source PE, the multicast tunnel interface toward the receiving PEs might be configured with an unlimited MTU size. This might result in no fragmentation for large packets. [PR/554398: This issue has been resolved.] A destination error occurs when an active SCB plane is unplugged. [PR/555250: This issue has been resolved.] When a large OID registration traffic exists from the subagent to the master agent, the registration packets encounter random errors during transmission. This affects the registration process. [PR/555345: This issue has been resolved.]
78
When a remote PE routers address is configured on a local loopback interface, the MVPN PIM neighborship to that PE router in a different VRF might be affected. [PR/558584: This issue has been resolved.] When a member link is added to an existing aggregated interface, an MDT mismatch might occur among the FPCs. This issue occurs only when graceful Routing Engine switchover (GRES) is enabled. [PR/558745: This issue has been resolved.] Under certain conditions, both the primary and the secondary circuits might get disabled. To recover from this condition, deactivate and activate the interface configuration. [PR/559656: This issue has been resolved.] On T Series routers running JUNOS Release 10.2 or 10.3, the chassis process terminates when a standby SCG unit is inserted. [PR/560652: This issue has been resolved.] On a 16-Gigabit Ethernet MPC with SFP+, a certain order of prefix addition and deletion might cause the MPC to restart. [PR/560716: This issue has been resolved.] When a MAC is moved, the resulting flush process might be interrupted when the list is processed. [PR/560730: This issue has been resolved.] The interface on an 20-Gigabit Ethernet MIC with SFP remains in the up state even after the Tx cable is removed. [PR/561254: This issue has been resolved.] With IRB interfaces and Layer 3 load-balanced traffic, a wrong mapping might occur that causes traffic on one child of a load-balanced group to be dropped. This occurs because the IRB interface is being used for the mapping information, instead of the individual child interfaces. [PR/561554: This issue has been resolved.] When multiple physical interfaces exist in a 4-port Channelized DS3 IQ PIC, errors might occur when each controller physical interface is deleted while the PIC is taken offline. [PR/561841: This issue has been resolved.] On MX960 routers with PWR-MX960-4100-AC PEMs (high capacity AC PEMs), the MPCs and DPCs do not power up when the system boots with only HC-AC PEM2,PEM3 being switched on, and PEM0,PEM1 being present but switched off. [PR/562125: This issue has been resolved.] In some cases, when a DPC or MPC is restarted, a wrong physical interface index is assigned to the interface, which might cause the MPC to crash. [PR/563056: This issue has been resolved.] On MX Series routers, the IPv4 multicast packets are dropped when vlan-id is configured as 0 on the interface. [PR/563471: This issue has been resolved.] When the show interfaces interface-set detail command is used, the ifinfo process might crash. [PR/564864: This issue has been resolved.] When a change in the bridge domain membership occurs, and the bridge domain has an IRB interface and a vt-x/y/z interface, the Packet Forwarding Engine that does not have any local interfaces on that bridge domain might restart. [PR/566878: This issue has been resolved.] On an MX240 chassis with a 1440W DC PEM, if the chassis is populated with a single Routing Engine and control board pair in slot 0 and three DPCs (of any type) are inserted
79
in the remaining slots, only two of the DPCs can be powered on. The third DPC remains offline with a "No Power" error as seen in the CLI output and chassisd logs.
user@host> show chassis fpc Temp (%) Slot State 0 30 1 30 2 Offline ---No power--Online 36 10 0 1024 26 Online (C) 37 CPU Utilization (%) Total 5 Interrupt 0 Memory Utilization Buffer
DRAM (MB) Heap 1024 18
The following message is logged in the chassisd logs upon failure to boot the third DPC:
FPC 2 is requesting power (consumption) 333W, total remaining pwr 305 CHASSISD_FRU_OFFLINE_NOTICE: Taking FPC 2 offline: No power
[PR/568281: This issue has been resolved.]
IDMEM parity error messages such as the following is observed on routers with MPC-3D-x MPCs:
MX960-LAB fpc3 LU 2 RD_NACK 2 AP[0x04] TOE Write 0x002913a0 MX960-LAB fpc3 LU 2 IDMEM Parity error in Bank 3, Count 10, IDMEM Bank 3 Offset 0x00014899 IDMEM[0x00052274]
These messages repeat as long as the JUNOS Software encounters the error. These errors occur within uninitialized memory locations and the error message is only cosmetic. [PR/569887: This issue has been resolved.]
Incorrect K2 bytes might be transmitted if the mode bits are not set correctly by the apsd process. [PR/569903: This issue has been resolved.] When the chassisd process receives a temporary error code (such as Device Busy, Try Again, No Buffer Space, or No Memory) while trying to add both the PIC and physical interfaces present in the PIC to the kernel, the chassisd process may not retry adding the physical interface back to the kernel until it succeeds. The device or physical interface does not recover. It is recommended to restart the router or the FPC when this issue is encountered. [PR/570206: This issue has been resolved.] On TX Matrix Plus routers, the set craft-lockout command might cause an FPM interrupt flooding. [PR/571270: This issue has been resolved.] On any JUNOS device that supports Ethernet OAM, the cfmd process might crash when a malformed delay measurement message (DMM) is received. [PR/571673: This issue has been resolved.] The DPC or FPC might crash when composite next hop is used. [PR/573197: This issue has been resolved.] When a cable is disconnected and connected between Ethernet OAM MEPs, incorrect flaps occur on an interface with only one MEP. [PR/576481: This issue has been resolved.]
80
On a 16-port 10-Gigabit Ethernet card, packets with checksum error might cause a wedge condition that affects the host traffic. [PR/579340: This issue has been resolved.] The maintenance association intermediate point (MIP) might not function after a system reboot. [PR/584070: This issue has been resolved.] The maintenance association intermediate points (MIPs) might not respond to 802.1ag link traces that are destined to reach the MIPs. [PR/584331: This issue has been resolved.] On MX Series MPCs, host packets might be dropped due to traffic congestion. [PR/584521: This issue has been resolved.] When certain configuration changes are made and the FPC is restarted, the SFP optics information does not appear in the output of the show chassis hardware command. [PR/584705: This issue has been resolved.] Under some rare conditions, the Trio-based MPC might fail to forward host-bound packets to the Routing Engine. [PR/584957: This issue has been resolved.] On a 10-Gigabit Ethernet MPC with SFP+, the configuration for the interface to go down when the low RX power threshold is reached does not work. [PR/585030: This issue has been resolved.] On Trio MPCs, the log message "fpcX MQCHIP(0) LI Packet length error, pt entry 11 might appear when the maximum-packet-length option is configured under port mirroring. [PR/587266: This issue has been resolved.] An interface with Ethernet OAM configured keeps flapping due to an adjacency timer issue. [PR/588032: This issue has been resolved.] On MX80 and MX Series routers with MX-MPC1-3D, MX-MPC2-3D-EQ, MX-MPC2-3D MPCs and with use of Tri-Rate Copper SFP (SFP-1GE-T), the interface might stop forwarding traffic when the traffic is flowing through the interface and the interface is disabled and enabled again, or a link flap event occurs. There is no workaround to prevent this issue. Ensure that there is no traffic through the interface when the interface is disabled and enabled again. If the issue is encountered, do the following:
For non-aggregated interfaces, ensure that no traffic is being routed to the failed interface. Use the ping count 5 rapid size 1 remote-interface-ip-address command to recover the interface and enable traffic to flow through the interface again. For aggregated interfaces, remove the affected interface from the aggregate interface configuration at both ends and assign an IP address to both the endpoints. Use the ping count 5 rapid size 1 remote-interface-ip-address command to recover the interface and enable traffic to flow through the interface again. Upon recovering, add the interface back to the aggregate interface configuration at both the ends.
On MX80 and MX Series rouers with MX-MPC1-3D, MX-MPC2-3D-EQ, MX-MPC2-3D, MPC-3D-x MPCs, the host-bound packets to an interface might get dropped when the adjacent IP address of this interface is configured on either the same or a different
81
interface in the router. This issue occurs only when the adjacent IPv4 addresses have the same first 30 bits, and has the bit 9 set (that is, the highest order bit of the second octet is set, for example 169.254.x.y or 192.128.x.y). To resolve this issue, deactivate and again activate the affected interface. [PR/596446: This issue has been resolved.]
On an MX960 router, the MPC reboots at regular intervals. [PR/601080: This issue has been resolved.]
On MX Series routers, when both the top and bottom fan trays are enhanced and a mastership switch is performed, the alarm "craftd[1337]: Minor alarm set, Mix of FAN-TRAYS" appears. This occurs only after a switchover or an upgrade. This alarm is temporary, cleared within a few seconds, and does not cause any routing or forwarding issues on the chassis. [PR/541617: This issue has been resolved.] The DHCP relay bindings remain in a release state with a negative lease time. [PR/549520: This issue has been resolved.] The PIM neighborship does not come up over the IRB interface after the DPC is restarted. [PR/559101: This issue has been resolved.] When DHCP clients log in at a high rate, the client might time out and try again. When this occurs, the IP Demux0 interface is already created and it might not get torn down. Instead, a new IP Demux0 interface is created. This results in the existence of a stale IP Demux0 interface. [PR/603511: This issue has been resolved.]
MPLS Applications
The rlist entry corresponding to the previously existing rlist is not being removed which causes the routing protocol process to crash. [PR/513160: This issue has been resolved.] On a P2MP LSP setup, the routing protocol process of the transit router might core when the topology changes with respect to the ingress sub-LSP router. There is no workaround. [PR/549778: This issue has been resolved.] In JUNOS Release 10.2, when the clear mpls lsp autobandwidth command is executed at the ingress router, the updated Maximum AvgBW Utilization field displays a value that is much higher than the actual bandwidth value. [PR/550289: This issue has been resolved.] Under certain circumstances, the routing protocol process might crash when configuration changes are made to label-switched paths at the [edit protocol mpls] hierarchy level. [PR/550699: This issue has been resolved.] On MX80 routers, the MPLS label-switched path (LSP) statistics do not record the transit traffic on a single-hop LSP with an implicit NULL label. [PR/551124: This issue has been resolved.] On point-to-multipoint label-switched paths (LSPs) with link-protection enabled, point-to-multipoint forwarding next-hop leaks might occur when the bypass and primary LSPs are unbound due to any of the following conditions:
Point-to-multipoint reoptimization when link protection with bypass label-switched path is up.
82
Bypass link is down when the link protects the point-to-multipoint LSP. Primary link is down while it is protected by the bypass LSP.
As a workaround, set a longer optimization period to reduce the rate of memory leak, or turn off bypass protection if it is feasible. [PR/554572: This issue has been resolved.]
During periods of high network instability with many links flapping, the presence of a large number of point-to-multipoint LSPs during an MBB rerouting of a point-to-multipoint LSP might cause the MPLS route to become stale. This, in turn, might lead to a routing protocol process assertion failure on a transit router. [PR/555219: This issue has been resolved.] On routers using Trio chipsets, when two or more point-to-multipoint branches transit the same Packet Forwarding Engine, the multicast packets might get corrupted. As a workaround, move the point-to-multipoint tree to different Packet Forwarding Engine entities. [PR/558527: This issue has been resolved.] The routing protocol process might dump core due to corrupted data in the equal-cost multipath (ECMP) indirect next-hop memory location. [PR/561031: This issue has been resolved.] A few prefixes get stuck in the bypass LSP, even after the primary LSP is back in the up state after a link failover. [PR/572658: This issue has been resolved.] When a configuration is changed from a CCC tunnel to a Layer 2 circuit, and committed, and the configuration is changed back to CCC tunnel, and committed, the CCC tunnel configuration does not work. The logical interface stays down. To recover, deactivate and again activate the relevant logical interface. [PR/573672: This issue has been resolved.] A point-to-multipoint LSP with bandwidth requirement might fail to retrace the original path after a graceful restart, and might not come up until the end of the recovery period. [PR/574308: This issue has been resolved.] In some cases where RSVP-signaled label-switched paths (LSPs) and automatic bandwidth adjustment are enabled, the routing protocol process might dump core during a switchover to a bypass LSP. [PR/575284: This issue has been resolved.] VPLS frames might be dropped on the MPLS core routers that are equipped with Trio MPCs. [PR/578190: This issue has been resolved.] When a label-switched path (LSP) reoptimization event (due to an automatic bandwidth adjustment or an optimization timer expiry) occurs during a sampling event, the sample is skipped. As a result, the LSPs bandwidth calculation might be inaccurate during the next sampling event. This inaccuracy might lead to an overestimation of the bandwidth value, thereby causing the affected LSPs to be resignaled with a higher bandwidth value at the next automatic autobandwidth adjustment. [PR/580919: This issue has been resolved.] The status of task replication for LDP protocol does not change from the "in progress" state. [PR/582966: This issue has been resolved.] When dynamic point-to-multipoint LSP template is used in an NG-VPN environment, the routing protocol process crashes. [PR/583231: This issue has been resolved.]
83
In JUNOS Release 10.0 and later, with the adaptive parameter configured, when a class-of-servicebased forwarding (CBF) RSVP label-switched path (LSP) is deleted, an allocated port ID might not be released. Deleting an RSVP LSP deletes its paths automatically. Even if no path is configured explicitly, the implicit primary path is automatically deleted. Because of this, when LSP paths are added and deleted repeatedly over time, the port ID space is exhausted and the routing protocol process might crash when an LSP or path is configured after that. [PR/584032: This issue has been resolved.] Under certain circumstances when automatic bandwidth adjustment is enabled for an LSP, the statistics record for the LSP is carried over to the new session after an LSP optimization. Therefore, the estimated bandwidth for the LSP is higher than expected. [PR/585250: This issue has been resolved.] An issue with the timer initialization during graceful restart might cause the MPLS automatic bandwidth timer smearing to fail. [PR/592478: This issue has been resolved.]
Multicast
The Packet Forwarding Engine might run out of memory when multicast upstream and downstream are on different FPCs, and a multicast next hop change occurs. [PR/577319: This issue has been resolved.]
Network Management
When the firewall filter policer configuration is changed, the SNMP MIBs might not update correctly. As a result, the counters are inaccessible. [PR/555719: This issue has been resolved.] The generation of the snmp engine-id using the use-mac-address option does not work. [PR/557569: This issue has been resolved.] SNMPD dumps core when snmp get and snmp get-next are used for SNMPv3 with security parameters that has variables that might result in a large error response. As a workaround, use a smaller PDU and lesser variables in SNMPv3 with authentication. [PR/559166: This issue has been resolved.]
When the show route forwarding-table family vpls vpn vpls-name command is used, the following message is logged in the log file: /kernel: rtsock: received msg 0 with version 0, expected 96, a reboot or upgrade may be required (proc = rtinfo). This is because the rtinfo utility does not fill the message version in the message buffer that is sent to the kernel. [PR/443413: This issue has been resolved.] On M Series and T Series routers, the kernel crashes when graceful Routing Engine switchover is turned on. [PR/463099: This issue has been resolved.] Under certain circumstances, the message NH: Failed to find nh (xxxx) for deletion appears for the child links of an aggregate interface. However, this message should appear only when the child next hop is not found. This message is only cosmetic. [PR/494528: This issue has been resolved.]
84
ADPC might crash when autosensed virtual LAN and DHCP relay bindings are cleared. [PR/507408: This issue has been resolved.] On T Series routers, the FPC might continuously reboot upon installation. [PR/510414: This issue has been resolved.] After the Multiservices PICs homing PE interfaces used for multicast VPN (MVPN) are taken offline and brought back online, the following message might be logged: flip-re0 fpc3 SLCHIP(0): %PFE-3: Channel 8189 (iif=701) on stream 32 already exists. [PR/527813: This issue has been resolved.] Using reassemble packets on an ADPC interface might cause non-fragmented packets to be sent to the servics PIC. [PR/530367: This issue has been resolved.] The following error message does not indicate any data plane forwarding issue:
mcsn[1124]: RPD_KRT_SEQUENCE: KRT Ifstate: receive sequence mismatch on routing socket -- expected 226684044, got 226684043
The kernel notifies certain processes of certain change events. For example, the kernel notifies the multicast snooping process when there is an indirect next-hop change event. This error message is emitted by the multicast snooping process when the message size received from the kernel exceeds a certain size. As a workaround when IGMP snooping is not used, use the set system processes multicast-snooping disable command to disable the service. [PR/534225: This issue has been resolved.]
On Trio MPCs, multiple changes to a single term in quick succession can cause an incorrect filter state in the Packet Forwarding Engine. This causes the MPC to crash. [PR/540674: This issue has been resolved.] MPCs might unexpectedly reset without saving the core files. The size of core files appears as zero byte. [PR/542900: This issue has been resolved.] The jtree memory might get corrupted when the indirect-nexthop option is changed multiple times. [PR/545142: This issue has been resolved.] On TX Series routers with gimlet FPCs and a large number of routes, when an AE interface in an ECMP path is taken down, small packet drops might occur in the traffic on the other ECMP link. This issue does not occur when an indirect next hop is used. [PR/545166: This issue has been resolved.] In JUNOS Release 9.3 and later, when routers using Enhanced FPCs (T640-FPCx-ES or T1600-FPC4-ES FPCs) have a configuration involving CBF LSPs and aggregate interfaces, a jtree corruption might occur when a flap from a member link in the aggregate occurs on the remote end, or the FPC of the remote router is rebooted. To avoid this issue, use indirect-next-hop (routing-options forwarding-table indirect-next-hop). The error message PFE: Detected error nexthop:" indicates a jtree corruption. [PR/548436: This issue has been resolved.] In a multicast VPN scenario, if the default-vpn-source option is configured under protocol PIM, and also the FPC holding is configured, the Multiservices PIC might crash when it is taken offline. [PR/550061: This issue has been resolved.]
85
In a Layer 2 circuit setup with a link services intelligent queuing interface (LSQ) in the core, and the control-word option enabled, a ping between two CE interfaces fails. As a workaround, use the no-control-word option. [PR/551207: This issue has been resolved.] The IPv6 BGP neighbors might not come back to the up state when an FPC associated with that session is manually taken offline, removed, and re-inserted. [PR/552376: This issue has been resolved.] On an NSR LDP, an LDP database entry mismatch exists between the master and the backup Routing Engines. The backup Routing Engine does not replicate the LDP socket with the error "jsr_sdrl_set_data: No space dlen." [PR/552945: This issue has been resolved.] A kernel core is generated when a logical interface that is a member of an AE bundle is activated and deactivated. [PR/553392: This issue has been resolved.] Layer 2 VPN does not work on Juniper Control System (JCS) shared uplinks. [PR/554096: This issue has been resolved.] In JUNOS Release 10.2 and later, when member links are added and removed from an AE bundle, a memory corruption causes the Packet Forwarding Engine to crash. [PR/554207: This issue has been resolved.] The interface route before the user route gets deleted for the same prefix. [PR/554806: This issue has been resolved.] The NTP server might not respond to clients whose source address is explicitly configured. [PR/556024: This issue has been resolved.] The output of the monitor interface traffic detail command does not display the description field. [PR/556108: This issue has been resolved.] No ICMP host redirect messages are generated when there are multiple VLANs configured on an interface (multiple logical interfaces on a single physical interface). [PR/559317: This issue has been resolved.] A DPC or an MPC might reset when aggregate Ethernet (AE) interfaces are provisioned with IRB. In some case, a DPC may also reset when a member link of an AE interface flaps. [PR/559887: This issue has been resolved.] When the route-memory-enhanced configuration statement is used, the BFD peers might go down and not come back up. [PR/559933: This issue has been resolved.] When a routing entry is created, the memory in the Packet Forwarding Engine is allocated to store the statistics of the routing entry. However, this allocated memory might not be freed when the routing entry is deleted. This issue might lead to the Packet Forwarding Engine causing memory-allocation failure issues in a scaled environment. [PR/559960: This issue has been resolved.] When the same local link address is configured on two interfaces, the message "/kernel: ip6_getpmtu: Invalid Stored MTU" is displayed continuously. [PR/560079: This issue has been resolved.] With the IRB and AE interfaces in a bridge domain, the old next-hop data is not cleared from the Packet Forwarding Engines when they are updated. This causes the Packet
86
Forwarding Engine to crash when that next hop is later referenced. [PR/560813: This issue has been resolved.]
On an MX960 router, when an MPC is installed and OSPF and IS-IS are activated simultaneously, the "jtree memory free using incorrect value 8 correct 0" message is displayed for all DPCs. [PR/562719: This issue has been resolved.] On standalone routers with graceful Routing Engine switchover enabled (using the set chassis redundancy graceful-switchover command), or on multichassis platforms (TX Matrix and TX Matrix Plus routers), FPCs can crash creating a core file when interfaces are moved from one aggregate bundle to another aggregate bundle in a single configuration commit operation. As a workaround, split the operation into two commits. Remove the interface from one bundle and perform a commit, and later add it to another bundle and perform another commit. [PR/563473: This issue has been resolved.] When a child link of an aggregate interface flaps, the kernel makes updates necessary for multicast replications. If the routing protocol process attempts to update the next hop (for example, delete and re-add) when the kernel is also in the process of doing the same, kernel panic might occur. [PR/564484: This issue has been resolved.] The MPC might crash when multicast traffic is forwarded when the interfaces are deactivated. [PR/565454: This issue has been resolved.] When route flaps occur, jtree leaks memory in the per-prefix-label mode with the route-memory-enhanced option enabled. [PR/567788: This issue has been resolved.] When IPv6 packets have a size greater than 1232 bytes, the packets get fragmented. [PR/571596: This issue has been resolved.] On standalone platforms with graceful Routing Engine switchover enabled (using the set chassis redundancy graceful-switchover), or on multichassis platforms (TX Matrix and TX Matrix Plus routers), when a unilist changes rapidly, the backup Routing Engine kernel might crash. On single-chassis systems when the kernel crashes on the backup Routing Engine, no loss of forwarding is seen. However, on multichassis systems, both the master and backup Routing Engines on a line card chassis, as well as the switch card chassis backup Routing Engines, crash. This causes a severe impact and loss of forwarding. The following log is recorded at the time of the kernel crash:
savecore: %DAEMON-1: reboot after panic: nhlist_free unable to add unilist(index = xxxxxxx)to treernhlist_deleted_root.
With two MICs on the same MPC, taking one MIC offline resets the IS-IS and BFD session on the other MIC. [PR/577873: This issue has been resolved.] After a few instances of graceful Routing Engine switchover, the firewall filter applied on the loopback interface might affect the internal control packets from the PICs to the Routing Engine. The PICs might fail to come back online if the packets are blocked. [PR/578049: This issue has been resolved.]
87
After a router or an FPC is restarted, the following message might appear on the ES FPCs:
fpc3 SLCHIP(0): %PFE-3: Disabling non-existent channel 275 on stream 0
The class-of-service configuration on an sp interface might not take effect after the router or the FPC hosting the sp interfaces is rebooted. This might occur when the Lin table on the SLCHIP is initialized to a specific format. [PR/580470: This issue has been resolved.] In JUNOS Release 9.4 and later, Layer 2 and Layer 3 must explicitly be configured for the M7i router's Adaptive Services Module (ASM) to support the mode. [PR/581153: This issue has been resolved.] On MX80 routers with Tri-Rate Copper SFP (SFP-1GE-T) and on other MX Series routers that support MX-MPC2-3D MPCs with Tri-Rate Copper SFP, any state transitions on the MPCfor example, a rebootmight result in a Layer 3 connectivity loss. Disable and enable the interface to recover from this state. [PR/582790: This issue has been resolved.] The FPCs on the T640 routers might crash when the routers jtree memory runs out. [PR/584739: This issue has been resolved.] In rare cases, the kernel thread might get blocked in the middle of a kernel routing protocol process acknowledgment processing. This might result in the corruption of the kernel state and a kernel crash. [PR/586693: This issue has been resolved.] When a loopback firewall filter is deployed on a T Series router with ES FPCs installed, a mixture of some of the following messages is displayed:
routername fpc0 SRCHIP(1): %PFE-6: 512 Multicast list discard route entries routername fpc0 SRCHIP(1): %PFE-3: RKME int_status1 0x100 routername fpc2 SRCHIP(0): %PFE-6: 1 Multicast list discard route entries routername fpc2 SRCHIP(0): %PFE-3: RKME int_status1 0x100 routername fpc3 SLCHIP(0): %PFE-3: 2 new errors (illegal link) in DESRD last stream 32 last lout_key 0xfa routername fpc3 CMALARM: %PFE-3: Error (code: 6, type:Minor) encountered, cmalarm_passive_alarm_signal routername fpc3 SLCHIP(0): %PFE-3: 2 new errors (illegal link) in DESRD last stream 32 last lout_key 0xfa routername fpc3 CMALARM: %PFE-3: Error (code: 6, type:Minor) encountered, cmalarm_passive_alarm_signal
This occurrence of RKME errors does not affect the transit traffic. [PR/588212: This issue has been resolved.]
Some host-bound packets may get dropped on E2 FPCs when there is a heavy host-bound traffic. [PR/588414: This issue has been resolved.]
88
When l3vpn-composite-nexthop option is enabled on an aggregate interface, the FPC might crash. [PR/590371: This issue has been resolved.] When a MLFR (FRF.16) is under a race condition that involves the MLFR bundle member link flap combined with the events that could keep the Packet Forwarding Engine busy (many routes and next-hop addition, deletion, or change), the routing lookup chip (on the FPC that hosts the CE1 member links) might stop forwarding all traffic. During this period, the message fpc5 RCHIP(1): RKME int_status 0x10000000 is logged as an indication to this issue. [PR/594544: This issue has been resolved.]
On Trio MPCs, warning system log messages appear when a firewall filter with large prefix lists is modified or deleted. These messages are cosmetic. [PR/561515: This issue has been resolved.]
Routing Protocols
In rare cases, the routing protocol process might restart due to a software validation failure that could have otherwise caused route drops. [PR/476143: This issue has been resolved.] With a large number of peers in a single BGP group, continuous large route churn might trigger scheduler slips in the routing protocol process. [PR/544573: This issue has been resolved.] When multicast groups are joined and the traffic begins to flow to all the groups, the NPC might crash due to a race condition. [PR/544865: This issue has been resolved.] The link local next hops are improperly propagated to the iBGP peers when the iBGP peers are attached directly. Additionally, the link local next hops are sent to the iBGP peers that are directly attached, when the global address is a loopback address. [PR/544962: This issue has been resolved.] In instances with scaled LACP configurations, the periodic packet management process (ppmd) might experience memory leaks. [PR/547484: This issue has been resolved.] An incoming BGP route with a long AS-path that is a contributor to an aggregate route might cause the routing protocol process to restart. [PR/548322: This issue has been resolved.] When the primary loopback address changes, the routing protocol process might crash when a new data MDT is created. [PR/549483: This issue has been resolved.] The GetRequest operation might fail for certain OIDs located in the multicast routing MIB. [PR/549928: This issue has been resolved.] If there is sufficient activity in the network (for example, due to a topology change) and the PIM neighbor assert state changes, the routing protocol process might crash. [PR/550193: This issue has been resolved.] When a policy matching an extended community using a 4-byte AS and a wildcard is configured, the match condition might fail to match the relevant communities. As a workaround, configure exact matches. [PR/550539: This issue has been resolved.]
89
If a PIM <S, G> join arrives when there is no route to the source, PIM RPF checking is disabled, and a matching multicast route is present, the output interfaces associated with the PIM <S, G> join are not added to the multicast route. [PR/550703: This issue has been resolved.] The IPv6 entries are removed from the output of the show pim interfaces command when the corresponding interface is in the down state. This is a cosmetic issue. [PR/550799: This issue has been resolved.] Under certain circumstances, back-to-back commits related to BGP activities might cause the BGP to not send a route-refresh to a newly added routing instance. [PR/552582: This issue has been resolved.] In rare cases, the withdrawn secondary BGP routes from a CE router can become stuck in bgp.l3vpn.0 on a PE router. As a workaround, use the restart routing soft command.[PR/552724: This issue has been resolved.] When an interface-based IPv6 BGP session with a 2-byte AS format is used, the system might crash. [PR/553772: This issue has been resolved.] An IS-IS adjacency flap at a precise interval can cause the routing protocol process to restart on a neighbor, as it is in the process of purging the LSAs of the previously down node from the local database. [PR/554233: This issue has been resolved.] The PIM <S, G> entries on are missing on the provider core router. [PR/555269: This issue has been resolved.] The Juniper Networks PIM-SM ASM implementation might not set the SPTbit when RPT and SPT are both preferred over the same interface. [PR/555650: This issue has been resolved.] When a graceful Routing Engine switchover occurs and the router moves to the master mode, there is a small possibility that messages intended for the standby Routing Engine are still being flushed. There are a few issues in the way messages intended for the standby Routing Engine are handled, when the Routing Engine has already switched to the master mode. [PR/555656: This issue has been resolved.] When a default route target is sent by a BGP peer, the BGP peer does not track the VPN routes covered by this route target. When the default route target ceases to exist, BGP does not withdraw the VPN routes that were previously covered by that default route target. [PR/556432: This issue has been resolved.] On Trio MPCs, the load balance might be broken when a BGP multipath is configured. [PR/557099: This issue has been resolved.] In JUNOS Release 10.2 and later, when point-to-multipoint label-switched path is used and the routing protocol process is restarted, the routing protocol process might assert continuously. [PR/558545: This issue has been resolved.] When the Link Layer Discovery Protocol (LLDP) advertisement interval value is changed from 30 seconds to 60 seconds, and the show lldp detail command is executed, the output shows 60 seconds. However, the Routing Engine forwards the LLDP packet every 30 seconds. When the interface is deactivated and activated again, the LLDP packets are forwarded every 60 seconds correctly. [PR/560857: This issue has been resolved.]
90
When a routing protocol process is restarted after a crash or a mastership switch, the kernel and the reference counters for the routing protocol process flood branch next hop might not be in sync anymore. The exposure is high in NGEN-MVPN with many local receivers and constant churn of joins and prunes of multicast groups. The routing protocol process might assert and restart while deleting a flooded next hop. As a workaround, restart the system, or deactivate all MVPN instances to get the kernel and the routing protocol process to be in sync upon a routing protocol process restart. [PR/561127: This issue has been resolved.] If a new VPN is added when the advertise-default option is used with the route-target family, the necessary route refresh is not sent. [PR/561211: This issue has been resolved.] Under certain circumstances, the routing protocol process crashes while receiving the IGMP SNMP GetNext request. [PR/561842: This issue has been resolved.] The multicast snooping process might crash and prevent a commit when the apply-group statement is used at the [set groups core-mcsn bridge-domains <*>] hierarchy level. [PR/562776: This issue has been resolved.] The routing protocol process might crash in the following environments:

Auto-export is configured for route leaking between VRFs. Communities are added in the import policy of the second VPN routing and forwarding (VRF) table.
Packets might not be correctly evaluated by a filter in an MPC that contains non-contiguous prefixes. As a workaround, replace the non-contiguous prefixes with equivalent sets of contiguous prefixes. [PR/564286: This issue has been resolved.] The Packet Forwarding Engines on MX Series 3D Universal Edge Routers might experience a rare transient error that temporarily corrupts one of the lookup engines, resulting in packet loss. A set of messages similar to the following is displayed:
fpc0 LU 0 PPE_7 Errors ucode data error 0x00000184 fpc0 PPE Thread Timeout Trap: Count 3, PC 20, 0x0020: entry_index_nh 0x0020: entry_index_nh PPE PPE HW Fault Trap: Count 10831395, PC 2c, 0x002c: entry_policer_nh
Restart the Packet Forwarding Engine to clear this error state. [PR/564998: This issue has been resolved.]
In an LDP nonstop active routing configuration, the LDP replicate session between the master and the backup Routing Engine might be stuck. This might result in incorrect updates to the backup LDP database. As a workaround, deactivate and activate the nonstop active routing configuration again when the router gets into this state. [PR/567148: This issue has been resolved.] If the always-compare-med option is configured when a route change occurs, the routing protocol process might occasionally crash due to a soft assertion. However, the soft assertion does not impact the user traffic. [PR/568725: This issue has been resolved.] During a nonstop active routing (NSR) switchover with a large number of remote Layer 3 VPN prefixes, and a local eBGP session with short hold-timers, routing protocol
91
process scheduler slips might occur, thereby causing the BGP session to flap. [PR/568756: This issue has been resolved.]
The BGP community attribute processing (match communities, add and delete communities) requires high processing power (CPU) and takes a significant amount of time. When complex policies are used to process a very large number of routes (example, multiple full Internet BGP feeds), and if most of the routes have BGP communities attached to them, then the BGP community processing might cause the routing protocol process to consume a large amount of the Routing Engines CPU (up to 100%) for an extended period of time (up to 1 hour). The amount of CPU utilization and the duration vary on a case-by-case basis. During this time, the router logs warning messages related to high CPU utilization of the routing protocol process. These warning messages contain the "RPD_SCHED_SLIP" or the "RPD_SCHED_TASK_LONGRUNTIME" acronyms. [PR/569515: This issue has been resolved.]
When a high amount of host-destined traffic exists on an MX Series router with Trio MPC, OSPF v3 or authenticated IPv4 (for example, authenticated VRRP) packets might be dropped, causing protocol flaps. [PR/569536: This issue has been resolved.] Under certain circumstances, processing of links with maximum metric set by IS-IS shortest path first (SPF) computation algorithm might lead to suboptimal routing decisions. [PR/569649: This issue has been resolved.] Two instances of the peer port modulation (PPM) packet exist under the same logical interface. [PR/572526: This issue has been resolved.] When a core-facing DPC is restarted, the message "mcsn: cannot perform nh operation ADDANDGET nhop (null) type indirect index 0 errno 22" appears. A trigger also moves the interfaces from bridge domains to VPLS instances. To clear this issue, restart multicast snooping. [PR/576058: This issue has been resolved.] On MX80 routers, when IPv6 Virtual Router Redundancy Protocol (VRRP) is configured on the Packet Forwarding Engine, the virtual MAC address for the VIP address is not programmed into the Packet Forwarding Engine. As a result, the traffic that passes through the VIP address (of both transit and host-bound) is discarded as a destination address reject on the interface. [PR/576211: This issue has been resolved.] In a race condition where a route flaps in a short time interval, the routing protocol process might crash. [PR/578339: This issue has been resolved.] On Trio MPCs, when an IRB interface and a VT interface exist in VPLS , the MPC might crash after the protocol, link, or route flaps. [PR/579767: This issue has been resolved.] The routing protocol process might use all the available CPU resources, and have a scheduler slip when an off-route XML ot text request for a BGP neighbor statistics fails to read the results, and SNMP requests for the same information are concurrently serviced. [PR/581203: This issue has been resolved.] The routing protocol process might dump core files when the Distance Vector Multicast Routing Protocol (DVMRP) prune lifetime expires. [PR/584752: This issue has been resolved.]
92
When a BGP peering session with a confederation peer has not negotiated the 4-byte AS, and IPv6 reachability requires to be advertised, the routing protocol process might crash with an assert. [PR/584787: This issue has been resolved.] With NSR enabled, the MPLS label of the routes might incorrectly be allocated when a vt interface exists in the routing instance. [PR/584915: This issue has been resolved.] The routing protocol process dumps core files when OSPF causes a memory corruption. [PR/588018: This issue has been resolved.] The CPU utilization of the routing protocol process might increase if BGP is completely disabled and then reenabled while many SNMP queries are in progress. [PR/590030: This issue has been resolved.]
In scaled environments, the thread in the Multiservices PIC or DPC for cflow might run too long. This causes the PIC or DPC to crash. [PR/494457: This issue has been resolved.] The IPv6 and MPLS route counts are not reflected in the output of the show service accounting status command. [PR/550793: This issue has been resolved.] The Multiservices 400 PIC crashes due to a memory allocation failure when the PIC tries to respond to a Routing Engine CLI request. [PR/558237: This issue has been resolved.] The Multiservices PIC might crash when traffic is received on a Layer 2 Tunneling Protocol (L2TP) session (MLPPP bundle), and a teardown request is also received at the same time. [PR/561039: This issue has been resolved.] If Bidirectional Forwarding Detection protocol (BFD) protection for BGP sessions is configured on a BGP session in a nonmaster routing instance, the BFD might start for that session before the kernel ID of the routing instance is set. This might cause the BFD session to freeze. As a workaround, if the BFD session has the routing table value of 4294967295, use the clear bfd session command to start a new session that will address the issue as long as the routing instance's kernel table is allocated. [PR/563161: This issue has been resolved.] If a class-of-service rule is applied to a service set, the inactive timeout under the user-configured application does not take effect. As a workaround, match the application in the class-of-service rule. [PR/571304: This issue has been resolved.] A NAT configuration with blobs greater than 32,000 might result in a 100 percent utilization of the CPU resources. [PR/578678: This issue has been resolved.]
The DHCP relay bindings remain in a release state with a negative lease time. [PR/553067: This issue has been resolved.] After a graceful Routing Engine switchover, the accounting interim packets are not sent. [PR/582404: This issue has been resolved.]
93
On TX Matrix Plus routers, the system log messages might not be sent from the LCC to the SCC after a graceful Routing Engine switchover. [PR/493138: This issue has been resolved.] When a configuration with a long as-path is displayed in XML format using the show configuration | display xml | no-more command, the closing tag for the as-path <path> is wrongly displayed as </path instead of </path>. [PR/525772: This issue has been resolved.] Errors occur when schedulers are added or edited from the J-Web interface. As a workaround, add or edit the schedulers using the CLI command. [PR/543590: This issue has been resolved.] Login failures to the FPC get sent to the NETCONF "xml stream" incorrectly while connecting to the NETCONF subsystem. This might cause the SSH session to disconnect. [PR/554456: This issue has been resolved.] In the J-Web interface with an HTTPS connection, uploading and downloading a configuration file using the Config Management Upload page (Maintain> Config Management> Upload) might not succeed. [PR/551200: This issue has been resolved.] When the load set command is used to refresh a script file, the script does not refresh, and exits from the CLI after displaying the rpc related errors. [PR/555316: This issue has been resolved.] A commit script that activates an apply group might fail to pass the commit check logic. [PR/576384: This issue has been resolved.] When SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG is enabled, OpenSSL does not properly prevent the modification of the ciphersuite in the session cache. This allows remote attackers to force the downgrade to an unintended cipher through vectors that involves network traffic sniffing to discover a session identifier. On OpenSSL before version 1.0.0c, when J-PAKE is enabled, OpenSSL does not properly validate the public parameters in the J-PAKE protocol. This allows remote attackers to bypass the need for knowledge of the shared secret, and successfully authenticate, by sending crafted values in each round of the protocol. [PR/580380: This issue has been resolved.]
If several get-configuration remote procedure calls (RPCs) are requested to the router frequently, the mgd process might crash. [PR/586416: This issue has been resolved.] A rollback command followed by the commit command sends notifications to all the processes. This leads to a high CPU utilization. [PR/591903: This issue has been resolved.]
94
VPNs
When two MVPN routing instances and at least one L2VPN routing instance are configured, the commit fails with the following message: RPD_RT_DUPLICATE_RD: routing-instance xxx has duplicate route-distinguisher." As a workaround, configure the route-distinguisher-id for each instance manually. [PR/511514: This issue has been resolved.] In a VPLS multihoming scenario, the routing protocol process crashes when a VPLS instance is deleted from the configuration. [PR/546177: This issue has been resolved.] The NG-MVPN traffic may be dropped at an egress PE when a Routing Engine restart event occurs on the P2MP ingress PE router. This issue occurs when multiple route reflectors reflect the MVPN routes in the core. [PR/556148: This issue has been resolved.] IP packets with certain sizes (around 287 bytes of total IP packet size) are corrupted while traversing the Layer 2 circuit or Layer 2 Virtual Private Network and the IP packets terminate on MX Series routers with Trio MPC installed. This corruption of IP packets happens in either of the following two cases:
Layer 2 circuit or Layer 2 Virtual Private Network is terminated (CCC interface is on the Trio MPC). In this case, packets with a total IP packet size equal to 284, 285, or 286 bytes are corrupted. Uplink (PE-P link) is on the Trio MPC. In this case, packets with a total IP packet size equal to 288, 289, or 290 bytes are corrupted.
In MVPN routing instances with local receivers, a flood next hop is created for each (s,g) entry for multicast traffic received from the CE router. After the local receivers are joined or pruned, a new flood next hop is created. However, old flood next hops are not deleted. This leads to a memory leak within the routing protocol process. When this routing protocol process reaches a size of 2 GB, it triggers an assertion and a restart. [PR/569621: This issue has been resolved.] In a local-switched Layer 2 Virtual Circuit scenario, the control and forwarding plane might not be properly updated by the routing protocol process when one of the logical interfaces forming the Layer 2 Virtual Circuit (VC) is down. [PR/572780: This issue has been resolved.] On M320 routers with non-E3 FPCs and T Series routers with the non-ES FPCs, and with the route-memory-enhanced option enabled (using the edit chassis route-memory-enhanced command), multicast VPN might experience traffic loss. [PR/573215: This issue has been resolved.] On MX Series routers with Trio MPC, and LACP or STP packets encapsulated in a Layer 2 circuit, the Layer 2 Virtual Private Network or VPLS might not be forwarded correctly. [PR/578402: This issue has been resolved.] In a multihoming VPLS scenario with VPLS traceoptions enabled, the routing protocol process might crash. As a workaround, disable VPLS traceoptions. [PR/579747: This issue has been resolved.]
95
Previous Releases
Release 10.2R3 Class of Service
When a logical interface set has a shaping-rate less than the sum of the transmit-rates of its queues and when the configuration is corrected so that the logical interface set gets the right shaping-rate, ADPC might crash. [PR/523507: This issue has been resolved.] When class of service is configured for a routing instance using a wild card, the classifier type might not populate correctly when a new routing instance is added. [PR/537378: This issue has been resolved.] When per-unit-scheduler is applied under the interfaces hierarchy and shaping rate is applied under the class-of-service interface hierarchy in the same commit operation, port shaping rate does not work, and the total logical interface transmitted byte rate exceeds the physical interface shaping rate. As a workaround, configure shaping-rate within a traffic-control-profile and apply that to an interface, or deactivate and then activate class-of-service interface interface-name shaping-rate. [PR/539590: This issue has been resolved.] Under certain conditions, the class-of-service configuration might not take effect on an IQ2 PIC. [PR/541814: This issue has been resolved.] The egress rate-limit over a logical interface may drop large packets. [PR/547506: This issue has been resolved.] In JUNOS Release 10.2 and later, the cosd process might crash while a configured commit is processed, as this process accesses a memory location that has already been freed. However, this issue is encountered rarely. [PR/548367: This issue has been resolved.]
When a scheduler associated with a forwarding class that is mapped to a different queue, the associated scheduler also needs to be applied to the new queue. This expected behavior does not occur. [PR/540568: This issue has been resolved.] In JUNOS Release 10.2, the Routing Engine-based sampling might not work if the routing table inet.0 has a route for 128.0.0.1. The issue occurs when this route points to an external interface. [PR/540891: This issue has been resolved.] A GRE interface may have an incoming packet loss if a firewall filter is configured on the forwarding table. [PR/541901: This issue has been resolved.]
96
General Routing
The routing protocol process crashes and does not start if the policy condition is enabled for IPv6. As a workaround, remove the policy condition for IPv6 from the configuration and restart the routing protocol process. [PR/553158: This issue has been resolved.]
High Availability
On M120 routers, the message: "stream blocked detected message" displays when an FEB is switched from the backup to the primary. [PR/540644: This issue has been resolved.]
The MX DPC might reboot with the error message: "EZ: ezchip_get_srh_msg_from_srhq." [PR/310223: This issue has been resolved.] AN OAM trace displays an incorrect next-hop MAC value. [PR/494588: This issue has been resolved.] After an 8216 Routing Engine upgrade to JUNOS Release 9.6 with "chassis" deactivated, the backup Routing Engine starts to reboot with the panic message "panic: filter_idx_alloc: invalid filter index" and crashes when the chassis configuration is enabled and committed. After the Routing Engine finally comes online, the CLI response is slow and the Routing Engine reboots again after three minutes approximately. To stop these reboots, deactivate the chassis on the backup Routing Engine. [PR/489029: This issue has been resolved.] If a T640-FPC4-ES is installed in a T1600 router and an SIB statistics collection is performed, the message log might report "JBUS: U32 read error, client .." only if one of the SIBs is faulted or in the offline state. This system log message will also appear if the T640-FPC4-ES FPC is removed from the chassis. There is no operational impact. [PR/504363: This issue has been resolved.] When traffic flows into the MPC on which a bridge-domain configuration is being changed or the card is booting up, the forwarding software tries to access uninitialized memory for a short duration. This is a cosmetic issue and does not have any functional impact. [PR/506344: This issue has been resolved.] An XE circuit on the 16-Gigabit Ethernet MPC with SFP+ might cause a high CPU utilization on the MPC. [PR/535057] On M7i routers with JUNOS Release 8.5 or later, the output of the show interfaces fxp0 command shows the fxp0 interface to be in the link up state even when the interface is disabled with no cables connected. [PR/508261: This issue has been resolved.] When the PIC is configured with encapsulation atm-ccc-cell-relay psuedowires, and the PIC throughput exceeds 152 Mbps, data loss occurs and the following error message is displayed: [Warning] ce_wp_poll_hspi_stats:2006: PF/Winpath SPI interface error, rx_err_sm 243. This error message is not seen when encapsulation atm-ccc-vc-mux is used.
97
As a workaround, use the atm-ccc-vc-mux encapsulation (AAL5 ATM PW), or use atm-ccc-cell-relay and configure a larger cell bundle size. When the cell bundle size is 5, the PIC passes 190 Mbps without error. [PR/515632: This issue has been resolved.]
In JUNOS Release 10.0 and later, a significantly large number of the following messages appears on the MX960 and SRX5800 routers:
MX960 /kernel: PCF8584(WR): transmit failure on byte 1 MX960 /kernel: PCF8584(WR): (i2c_s1=0x80, group=0xe, device=0x54) MX960 /kernel: PCF8584(WR): busy at start, attempting to clear MX960 /kernel: PCF8584(WR): (i2c_s1=0x00, group=0xe, device=0x54) MX960 /kernel: PCF8584(RD): ack failure on 2nd last byte
These messages are not an indication of a fan failure. They are cosmetic and can be ignored. [PR/531253: This issue has been resolved.]
On Trio FPCs, multiple changes to a single term in quick succession results an incorrect filter state in the Packet Forwarding Engine. This causes the FPC to crash. [PR/532791: This issue has been resolved.] The kernel might crash when bundle messages are sent to the Packet Forwarding Engine when the physical interface is deleted. [PR/532926: This issue has been resolved.] On MX960 routers, the link status stays in the "Link ok" state when the SCB is removed without taking it offline through the CLI or switch. [PR/536860: This issue has been resolved.] The SCB displays an incorrect state when it is removed without taking it offline through the CLI or buttons. This is not a cosmetic error and might have an impact to the traffic. [PR/536866: This issue has been resolved.] The "frame-relay-ether-type" encapsulation is not programmed to the hardware properly. Due to this, the incoming packet parsing fails and the packets are discarded. [PR/539484: This issue has been resolved.] On 1-Gigabit Ethernet MIC interfaces, the MAC transmit statistics only report the octets for the payload and do not count the Ethernet header. [PR/540043: This issue has been resolved.] On MX Series routers with 10.x Power Budget, after a Power Budget: Chassis experiencing power shortage alarm occurs, the alarm does not clear even after the power budget problem is cleared. [PR/540522: This issue has been resolved.] The MX-MPC1-3D-Q accepts VLAN tagged packets even when the interface is not configured with VLAN tagging. [PR/540620: This issue has been resolved.] The link-up time on a 16x 10Gigabit Ethernet MPC is not as less as other platforms (ADPC and other MPCs) due to the emission dispersion compensation (EDC) functionality of the PHY device on the MPC. This causes a delay of 50 mS to 150mS and cannot be changed. [PR/540694: This issue has been resolved.] The sonet-options raise-rdi-on-rei and trigger options does not work well together. Turning the raise-rdi-on-rei option on and back off requires the trigger option to flap in order to assert or clear the RDI-L alarm. As a workaround, when both sonet-options
98
raise-rdi-on-rei and trigger options are configured, flap the sonet-options trigger too.
With JUNOS Release 10.2 and later, when a logical interface on an ATM-II IQ PIC is disabled, the FPC is taken offline and brought back online, and the PIC is reenabled, the logical interface stays down with atm_maker_check_indq error messages. [PR/541688: This issue has been resolved.] When a GE/XE interface on IQ2 PICs is disabled, and the link status is up, the traffic received from the interface might still be forwarded. [PR/543388: This issue has been resolved.] When neither the per-unit scheduler nor the hierarchical scheduler is configured on the physical interface and the physical interface has the overhead-accounting bytes configured, it does not take effect. [PR/544608: This issue has been resolved.] When logical interfaces are created, the NPC crashes and the FPC goes down. [PR/545314: This issue has been resolved.] Chassisd crashes when the show chassis clocks command is executed. [PR/545510: This issue has been resolved.] When configuration changes are made that are unrelated to the interfaces, interface sets, or PICs, a commit failure occurs with the following error message: "error: iflset xxxx configured for nonexisting ifd ge-x/x/x." [PR/546184: This issue has been resolved.] On MX Series routers running JUNOS Release 10.2, the output of the show interface x statistics detail or show interface aex extensive commands might have incorrect or incomplete data such as missing LACP, incorrect transit statistics, and so on. This also causes the ifStackStatus table to be broken. [PR/548615: This issue has been resolved.] A CFM ping command fails when the Maintenance Domain or Maintenance Association is longer than 32 characters. [PR/550014: This issue has been resolved.] On a 10-port oversubscribed 10-Gigabit Ethernet PIC for T Series routers (PD-5-10XGE-SFPP), the reactions configured under the [optics-options] stanza do not take effect for "low-light" conditions. [PR/550851: This issue has been resolved.] After a link flap occurs at the source PE, the multicast tunnel interface towards the receiving PE's might have an unlimited MTU size configured. This might result in a no fragmentation for large packets. [PR/554398: This issue has been resolved.]
The AE interface does not show the system identifier for the attached interfaces in actor role. Because of this, the AE interface gets stuck in the detached state after it is rebooted from both ends. Additionally, the AE interface flaps when the backup Routing Engine is rebooted and GRES is performed. [PR/547739: This issue has been resolved.] When LLDP is enabled, the L2CPD might have a memory leak. [PR/549531: This issue has been resolved.]
99
MPLS Applications
With BFD enabled over IGP and an RSVP session built across it, when the RSVP peer does not support RSVP Hello (or is disabled), the BFD session down event triggers only the IGP neighbor to go down. The RSVP session remains up until a session timeout occurs. [PR/302921: This issue has been resolved.] When a protected link flaps, certain RSVP routes do not lose association with the p2mp_nh. [PR/530750: This issue has been resolved.] The maximum average bandwidth utilization computed by MPLS for auto-bandwidth may sometimes be higher than the actual traffic rate (twice the traffic rate). This occurs when the MPLS statistics response from the Packet Forwarding Engine comes in late, and two statistic entries for the same LSP fall in the same MPLS auto-bandwidth averaging timer interval. [PR/536759: This issue has been resolved.] Under NGEN-MVPN with vrf-table-label configured on the provider edge, the provider router connecting to that provider edge might keep an old P2MP MPLS label entry upon label-switched path optimization or reroute. There is no workaround. [PR/538144: This issue has been resolved.] An LSP with auto-bw might stay down for approximately 30 minutes after a Routing Engine switchover or a Routing Engine restart when graceful restart fails. As a workaround, disable and reenable the MPLS or OSPF stanza. [PR/539524: This issue has been resolved.] When the RSVP path-mtu allow-fragmentation is configured, traffic blackholing might occur. [PR/544365: This issue has been resolved.] In JUNOS 10.2 service releases only, when the clear mpls lsp autobandwidth command is executed at the ingress router, the updated Maximum AvgBW Utilization field displays a value that is much higher than the actual bandwidth. [PR/550289: This issue has been resolved.] On MX80 routers, the MPLS LSP statistics do not record the transit traffic on a single-hop LSP with an implicit NULL label. [PR/551124: This issue has been resolved.]
Network Management
SNMP may stop working after a router reboot, DPC/FPC/MPC restart, or a graceful Routing Engine switchover. [PR/525002: This issue has been resolved.] In JUNOS Release 10.2 and later, the size of the MIB2D process might increase as a result of memory leaks which causes the MIB2D process to crash as it reaches its maximum permitted size. [PR/546872: This issue has been resolved.] In JUNOS Release 9.2 and later, a memory leak occurs in the subagent in a scenario where the snmpd process is not running, or there are issues in communication with a subagent and traps are being generated by the subagent. [PR/547003: This issue has been resolved.] When the firewall filter policer configuration is changed, the SNMP MIBs might not update correctly. This results in the counters being inaccessible. [PR/555719: This issue has been resolved.]
100
Redirect drops that are not real errors are taken into account for "Iwo HDRF" error statistics that are reported in the output of the show pfe statistics errors command on I-chip based routers. Since redirect drops are expected in a VPLS (and Ethernet in general) environment, this behavior could be misleading. [PR/430344: This issue has been resolved.] When the system default-router a.b.c.d command is used, the default route is not installed in the Packet Forwarding Engine. [PR/523663: This issue has been resolved.] When VPLS is configured on the router, the following log messages will appear when the interface goes down:
RT-HAL,rt_entry_delete_msg_proc,XXX: route add posthandler failed RT-HAL,rt_msg_handler,XXX: route process failed
These messages can be ignored. [PR/524548: This issue has been resolved.]
After the Multiservices PICs homing PE interfaces used for MVPN are taken offline and brought back online, the following message may be logged: flip-re0 fpc3 SLCHIP(0): %PFE-3: Channel 8189 (iif=701) on stream 32 already exists. [PR/527813: This issue has been resolved.] The Packet Forwarding Engine incorrectly imposes a rate limit function for the host-bound virtual LAN tagged packets with an IEEE 802.1p value of 1. There is no workaround. [PR/529862: This issue has been resolved.] A router might send raw IPv6 host-generated packets over the Ethernet towards its BGP IPv6 peers. [PR/536336: This issue has been resolved.] On M10i routers, the JUNOS Release 10.2 upgrade fails and aborts when the PIC combinations are verified. As a workaround, use the force option to override the warnings and force the upgrade, but first verify the PIC combinations manually against PSN-2010-06-777. [PR/540468: This issue has been resolved.] In JUNOS Release 10.2 and later, during SNMP queries, the size of the MIB2D process might increase as a result of memory leaks in a statistics-associated library routine (libstats). This causes the MIB2D process to crash as it reaches its maximum permitted size permitted. [PR/541251: This issue has been resolved.] The backup Routing Engine might cause the kernel to crash when a configuration change occurs on the AE bundle during a next-hop index allocation. [PR/544092: This issue has been resolved.] In JUNOS Release 10.0 and later, the FPCs in M320 and T Series routers might crash when the error PFE: Detected error next-hop (corrupted next-hop) is encountered. [PR/546606: This issue has been resolved.] On M120 routers, multicast packet drops occur when both the Fast Ethernet and the SFP Gigabit Ethernet PICs are located on the same Packet Forwarding Engine. [PR/546835: This issue has been resolved.] In a multicast VPN scenario, if the default-vpn-source is configured under protocol PIM, then the FPC holding is configured, the Multiservices PIC might core when it is taken offline. [PR/550061: This issue has been resolved.]
101
When a firewall loopback filter exists and the default term is discard, the multicast forwarding cache entries are created since the resolve request is dropped at the Packet Forwarding Engine level. As a workaround, add an additional term to accept the multicast destination address of 224/4. [PR/531787: This issue has been resolved.]
Routing Protocols
The output of the show ospf statistics command does not display hello packet statistics. [PR/427725: This issue has been resolved.] Packet drops occur during a GRE/NSR switchover, when class of service and scheduler-map are enabled on the aggregated interface. [PR/502365: This issue has been resolved.] When a family inet6 addressing is added to a router configured with multicast VPN, the routing protocol process might crash and restart. [PR/503296: This issue has been resolved.] The mirror receive task variable may not be cleared when the routing protocol process is heavily scaled. Hence, the NSR replication for RIP status stays in the "InProgress" state forever. [PR/516003: This issue has been resolved.] Under rare circumstances, multiple commits might crash both Routing Engines. The routing protocol process dumps core and restarts only on the master Routing Engine. This issue occurs when commits are executed within one minute. [PR/516479: This issue has been resolved.] Upon an NSR mastership switch or ISSU upgrade, the multicast resolve route for IPv4 224/4 or inet6 ff00::/8 might be missing within the forwarding table. To recover from this condition, deactivate and reactivate the protocol PIM stanza, or restart the routing protocol process. [PR/522605: This issue has been resolved.] An ISSU upgrade to JUNOS Release 10.2 with PIM NSR configured fails whenever an incompatble FRU (PIC) is required to be taken offline during a Routing Engine switchover. As a workaround, disable NSR for PIM using the set protocols pim nonstop-routing disable command for the ISSU uppgrade to be successful. [PR/527668: This issue has been resolved.] For JUNOS Release 9.5 and above, the BGP parse community begins with 0 as the octal value. This behavior is different in earlier releases. [PR/530086: This issue has been resolved.] The master routing protocol process crashes three minutes after a graceful Routing Engine switchover. [PR/533363: This issue has been resolved.] The Overload bit in the IS-IS LSP MT-TLV may trigger the IS-IS to install a default route to the overload bit advertiser and the show isis database extensive command may report an unknown TLV. [PR/533680: This issue has been resolved.] The routing protocol process might crash due to an invalid prefix-length value in one of the flow-spec routes. [PR/534757: This issue has been resolved.]
102
If enough join state is associated with a neighbor and that neighbor goes down and comes back up quickly, then that join state may be stranded in an unresolved state until the clear pim join command is issued. [PR/539962: This issue has been resolved.] On Type 2 Trio FPCs, multiple changes to a single term in quick succession can cause an incorrect filter state in the Packet Forwarding Engine. This causes the FPC to crash. [PR/540674: This issue has been resolved.] The routing protocol process might crash when a BGP connection attempt is met with an RST from the peer. This is due to an unlikely race condition. [PR/540895: This issue has been resolved.] Under certain timing conditions, an interior gateway protocol topology change can result in the BGP routes referencing an incorrect egress interface. This problem can occur when active and inactive BGP routes are learned from the same peer and the inactive BGP routes are deleted at the time of the topology change. [PR/543911: This issue has been resolved.] When two identical local interface addresses are shared between two VRFs via auto-export, the routing protocol process might cause a high CPU utilization. [PR/547897: This issue has been resolved.] When the primary loopback address changes, the routing protocol process might crash when a new data mdt is created. [PR/549483: This issue has been resolved.]
For Adaptive Services II PICs, a temporary file might be created every 15 minutes in the /var/log/flowc/ directory even if flow collector services is not configured. The file is deleted if there are no clients, and re-created only when a client connects and attempts to write to the file. [PR/75515: This issue has been resolved.] In JUNOS Release 10.0 and later, the routing instance name is restricted to 63 characters. [PR/533882: This issue has been resolved.] The BGP_IPV4_NEXT_HOP field on the jflow v9 record matches the originator ID instead of the BGP next hop. [PR/534598: This issue has been resolved.] When traffic is forwarded in an L2TP session and a teardown request is received, the ASPIC crashes with a memory access violation in mlppp_output. [PR/537225: This issue has been resolved.] On M Series routers configured for L2TP tunneling with several thousands of PPP connections, when all the PPP sessions expire at the same time, the Multiservices PIC might hang and become unusable. To recover the service, restart the PIC. [PR/541793: This issue has been resolved.] On SG3 PICs (Multiservices 500) with graceful Routing Engine switchover (GRES), wrong record values are seen for the IPv4 netflow export packets. This error occurs when the route records are not installed. [PR/545422: This issue has been resolved.]
103
When the CLI screen length is set to zero and the show log command is used, the more prompt ignores the CLI screen length of zero and only a fraction of the number of lines is displayed. [PR/103595: This issue has been resolved.] Under the Configuration>OSPF>Traceoptions page, J-Web does not display the available flags. [PR/475313: This issue has been resolved.] On a router configured with a large number of interfaces, when a few interfaces are constantly added and deleted, a minor memory leak maybe occur in the "pfed" process. [PR/522346: This issue has been resolved.] The xnm service currently does not support logging of remote-host addresses in system accounting. [PR/535534: This issue has been resolved.] The system continues to use the TACACS server configuration even after it is removed. As a workaround, deactivate and reactivate the accounting configuration. [PR/544770: This issue has been resolved.]
VPNs
If a VRF routing instance contains a static route that is resolved via a route that was auto-exported from another routing instance, the static route might not be removed when the physical interface goes down. [PR/531540: This issue has been resolved.] When a CE-facing interface in a VPLS instance is deactivated, the routing protocol process may get into a loop leading to a high CPU utilization. [PR/531987: This issue has been resolved.] If the C-source and C-RP are learned through different PEs and both of the PEs have data-mdt enabled for the same group, multicast flow may periodically start and stop. The start and stop time depends on when the two PEs refresh their DATA MDT JOIN TLV. [PR/542984: This issue has been resolved.] Under certain circumstances, the container interfaces might not send the proper martini modes to the routing protocol process. This results in incorrect control word related information sent to the Packet Forwarding Engine. [PR/541998: This issue has been resolved.] In a VPLS multi homing scenario, the routing protocol process crashes when a VPLS instance is deleted from the configuration. [PR/546177: This issue has been resolved.]
Release 10.2R2 The following issues have been resolved since JUNOS Release 10.2R2. The identifier following the description is the tracking number in our bug database.
104
Class of Service
If a logical interface is configured or added to an interface set for which an existing traffic control profile is applied, any rate-limit functionality will not be applied to the new logical interface. To resolve this problem, deactivate and activate the interface portion of the class-of-service configuration. [PR/485872: This issue has been resolved.] On M Series and T Series routers, the forwarding class information is lost when the packet enters the GRE tunnel with clear-dont-fragment-bit enabled. Additionally, on an Enhanced FPC or M120 FEB, the packet is also likely to be dropped if it is classified to a packet loss priority (PLP) value other than low. [PR/514162: This issue has been resolved.] In a scaled configuration, the class-of-service classifier does not work properly. [PR/522840: This issue has been resolved.] When the IEEE classifiers are configured on the Trio MPC card and the aggregated Etherenet interfaces are deactivated and activated with schedule map changes, the class-of-service process crashes. [PR/528108: This issue has been resolved.] On virtual LAN demux interfaces over an Aggregate Ethernet with Trio MPCs, the changes made to the configuration are not applied when the commit command is issued. As a workaround, restart the MPC for the committed changes to take effect. [PR/528188: This issue has been resolved.]
While the JUNOS Software adopts random as its sampling algorithm, the SAMPLING_ALGORITHM in the flow monitoring version 9 template shows 0x01 (deterministic) instead of 0x02 (random). [PR/438621: This issue has been resolved.] The unified in-service software upgrade will not work when API clients install policers. [PR/518301: This issue has been resolved.] When a filter with ip-options "any" firewall match is applied on an interface on the MX-MPC, the filter is not applied. If the hardware is present at the time of the configuration commit, a commit warning is issued. However, the commit does not fail and the rest of the configuration is applied. [PR/524519: This issue has been resolved.] On T640 and T1600 routers with ST chipset FPCs, in some cases when the IPv6 firewall filter with match conditions configured on address prefixes is longer than 64 bits, the filter may not be evaluated correctly. This might lead to loss of packets. [PR/524809: This issue has been resolved.] A Routing Engine-based sampling might not work in JUNOS Release 10.2 if the routing table inet.0 has a route for 128.0.0.1. This issue occurs if this route points to an external interface. [PR/540891: This issue has been resolved.]
105
When forwarding-options is configured without route-accounting, the commit goes through with the message, "Could not retrieve the route-accounting." However, no functionality is affected. [PR/312933: This issue has been resolved.] When lockout is configured and the router is rebooted, the working router is stuck in the wait-to-restore state while the protect router still shows channel state working and no requests, but no longer shows the lockout flag. [PR/474482: This issue has been resolved.] When an IQ2 PIC is brought online with a class-of-service configuration that includes a scheduler using the rate-limit options, the system incorrectly reports that rate limiting is not supported on the PIC. [PR/482199: This issue has been resolved.] On MX Series routers, the traffic is forwarded over the backup link even after the primary link is disabled and enabled again. [PR/493861: This issue has been resolved.] On an M20 router with AC PEMS, the alarm message Power Supply x not providing power is generated when the power cord is removed. The alarm is not cleared when the power cord is reconnected. [PR/506413: This issue has been resolved.] Under certain conditions, some Packet Forwarding Engines may fail to install VPN multicast routes when downstream interfaces are RLSQ bundles. [PR/515878: This issue has been resolved.] When a frame relay interface goes down, the interface statistics might still indicate that the data-link connection identifier (DLCI) is active. [PR/516497: This issue has been resolved.] On IQ2 and IQ2E 10GE PICs operating in WAN-PHY mode, the path trace information does not get transmitted to the remote end. [PR/518331: This issue has been resolved.] When one of the two Ethernet connections to another Routing Engine is not present, the mastership is not switched. [PR/521833: This issue has been resolved.] If a donor logical interface does not have a valid ifa (i.e. atleast one address which is unique to the logical interface in the routing instance), the DCD might crash. [PR/524989: This issue has been resolved.] On MX80 routers, T-FEB crashes when the physical interface or logical interface on which incoming traffic is received is deactivated. [PR/525824: This issue has been resolved.] When the clear interfaces statistics command is used, if a member link is deactivated from an aggregate (AE or AS on any platform) and if the show interfaces extensive command is used immediately, incorrect values (very high values) might be seen for the counters such as 'Transmitted and Queued' packets under the Queue counters. If the clear interface statistics command is not issued prior to deactivating the member link, this issue will not be seen. [PR/530297: This issue has been resolved.] On T640 routers, the SCG 0 EXT SYNC UNSUPP alarm displays. This is because external clock sync is not supported on older SCGs. [PR/526063: This issue has been resolved.]
106
On MX Series routers with Multiservices MPCs, the VRRP virtual MAC is unavailable after a mastership change which leads to loss of packets. [PR/529956: This issue has been resolved.] When M120 Type 1 FPCs are configured for 2:1 FPC:FEB mapping, and one of the FPCs restarts, the restarting FPC might not initialize properly and might result in a small percentage of packet loss for all interfaces on that FPC. As a workaround, restart the FPC until the problem stops. [PR/529994: This issue has been resolved.] When any subscriber interface (PPPoE or DHCP) is used, the VPLS connections go down. [PR/530435: This issue has been resolved.] Continuos chassisd trace message is recorded in the chassisd log file. [PR/530486: This issue has been resolved.]
On a TX Matrix router, an aggregate bundle composed of member links from different LCCs has the same slot/PIC/port, and results in the duplication of Link Aggregation Control Protocol (LACP) port numbers. For example, a bundle with the actor and partner shown below will result in a duplicate LACP port number since ge-0/3/0 and ge-8/3/0 (and similarly ge-1/3/0 and ge-9/3/0) are the same slot/PIC/port but from different LCCs.
Actor ge-0/3/0 ge-8/3/0 Partner ge-1/3/0 ge-9/3/0
On MX960 routers, duplicate LACP port numbers will result in aggregate bundles composed of member links for the same PIC and port on slots (0, 8), (1,9), (2,10), and (3,11). Also, the following sets of ports on any slot will have duplicate LACP port numbers:

PIC 0 port 8 and PIC 1 port (0,8) PIC 0 port 9 and PIC 1 port (1,9) PIC 2 port 8 and PIC 3 port (0,8) PIC 2 port 9 and PIC 3 port (1,9)
NOTE: The duplicate LACP port number described above does not affect the aggregation, but affects the SNMP extracting port information and shows an identical pair of SNMP dot3adAggPortPartnerOperPort and dot3adAggPortActorPort for the above mentioned links of the aggregate bundle.
A Spanning Tree Protocol triggered MAC flush might fail if there are frequent topology changes with a significant number of MAC addresses learned. For multiple Spanning Tree Protocols, restart l2cpd-services to come out of the state, and for the Rapid
107
Spanning Tree Protocol, reboot the corresponding DPC. [PR/529130: This issue has been resolved.] MPLS Applications
The routing protocol process might crash with an assert in rsvp_PSB_set_selfID while a graceful Routing Engine restart is performed when P2MP LSPs are present. [PR/512890: This issue has been resolved.] At adjust intervals, the maximum average bandwidth utilization for the LSP should be reset to zero. MPLS sometimes fails to reset the maximum average bandwidth utilization for the LSP to zero while performing a periodic auto-bandwidth adjustment at the adjust interval. This prevents the periodic auto-bandwidth adjustment from adjusting to a lower bandwidth when the traffic rate drops. [PR/528619: This issue has been resolved.]
Network Management
After an LCC switchover, the SNMP process fails to send traps with resource temporarily unavailable errors. [PR/493385: This issue has been resolved.] The SNMP MIB OID tree under dot3adAggPort fails. This issue may occur when virtual LAN tagging is not configured on the AE interface, and if the mib2d process is restarted using the restart mibprocess command. [PR/528555: This issue has been resolved.]
On M7i routers, kernel panic may occur during route changes. [PR/439420: This issue has been resolved.] An invalid IP protocol version is served as a valid version. The JUNOS router forwards IP packets with the version field set to values other than 4 and 6; for example, 11 or any (unassigned). [PR/481071: This issue has been resolved.] In a setup with two VPN routing and forwarding tables (VRFs) of a provider edge connected to different customer edges and auto-export configured, when a ping is executed from a customer edge to a provider edge interface in the other VRF , the Internet Control Message Protocol reply returns the source interface IP of the provider edge that is connected directly instead of the interface IP of the other VRF provider edge. [PR/510834: This issue has been resolved.] A load-balancing issue occurs for egress traffic transiting a SONET aggregated interface bundle when an interface with a different speed or capacity is removed from the bundle. For example, if you have two or more OC12 interfaces and one OC192 interface in a SONET aggregated interface bundle and if the OC192 interface is then removed from the bundle, traffic is not load-balanced properly across the remaining interfaces. As a workaround, deactivate and then activate the SONET aggregated interface to ensure proper load balancing across the member interfaces. [PR/513677: This issue has been resolved.] Setting the TCP maximum segment size (MSS) may not change the actual MSS value. [PR/514196: This issue has been resolved.]
108
When IGMP snooping is enabled, a multicast traffic drop might be seen if an IGMP join or leave occurs on other interfaces. [PR/515420: This issue has been resolved.] When the primary link flaps with the route-memory-enhanced statement enabled, jtree might get corrupted and traffic forwarding is affected. As a workaround deactivate the route-memory-enhanced statement under the chassis stanza. Changes to the route-memory-enhanced statement takes effect only when Packet Forwarding Engine is rebooted. [PR/517919: This issue has been resolved.] Under certain conditions, traffic flow through an RLSQ bundle can be dropped after it is removed and added back to a VPN routing and forwarding table (VRF). [PR/518170: This issue has been resolved.] On MX Series routers, the DPC may crash when the P2MP LSP switches between different AE links. [PR/520773: This issue has been resolved.] When the destination class usage (DCU) is configured with unicast reverse path filter (uRPF) and egress forwarding-table filter within the VRF, a VPN route flap might trigger a jtree memory leak. [PR/521609: This issue has been resolved.] On MX Series routers, repeated graceful Routing Engine switchover (GRES) under certain configurations might result in kernel panics. Three kernel cores are observed: with a soft update files system trace, with a TCP packet processing stack trace, and with a trace of IFF configuration write. [PR/525583: This issue has been resolved.] A neighbor solicitation request does not return any neighbor advertised packets when static neighbors are configured. [PR/527779: This issue has been resolved.] On some routers, enabling IP-payload-based load balancing for MPLS packets can cause some pseudowire packets to be reordered. [PR/528657: This issue has been resolved.] On M120 routers, the output firewall filter does not properly classify traffic over PPPoE subscribers. [PR/528905: This issue has been resolved.] Asp_ifl_update messages may be seen on routers running JUNOS Release 10.0 and later. Ignore these messages as they do not impact functionality. [PR/532648: This issue has been resolved.]
On some M, MX, and T Series routers, when a family CCC filter is applied on multiple interfaces that belong to different L2VPN routing instances, packet loss may occur after the routing instances are deactivated and activated. As a workaround, deactivate and activate the CCC filter on the interfaces. [PR/521357: This issue has been resolved.] When a firewall loopback filter exists and the default term is discard, the multicast forwarding cache entries will be created since the resolve request is dropped at the Packet Forwarding Engine level. As a workaround, add an additional term to accept the multicast destination address 224/4. [PR/531787: This issue has been resolved.]
109
Routing Protocols
The configured robust count value is not applied on the non-querier router when it receives a robust count value of 0. It uses the default value (2) instead of the configured value. [PR/520252: This issue has been resolved.] After a graceful restart, the forwarding state of both provider edge routers might get stuck at the pruned state. However, traffic flow is not affected. [PR/522179: This issue has been resolved.] On M, MX, and T Series routers, the OSPF neighbor status will sometimes be stuck in the init state when the load override configfile command is used in the following scenario:

A logical system with an AE interface exists A router with an AE interface exists Both AE interfaces are connected to each other, and OSPF is enabled on both AE interfaces
This can be recovered by rebooting the system with this configuration instead of using the load override command. [PR/522365: This issue has been resolved.]
When a l2circuit id greater than 2,147,483,647 is configured, and l2circuit tracing is enabled using the set protocols l2circuit traceoptions command, some of the trace messages provide the wrong value (a negative number) for the virtual circuit ID. [PR/523492: This issue has been resolved.] The tag_encoder is unable to handle attempts to stack EXPLICIT_V6_ NULL (label 2) over an existing stack with label 2 on top. Additionally, the BGP module does not send label 2 when readvertising a prefix from an inet6 unicast session to a inet6 labeled-unicast session. [PR/523824: This issue has been resolved.] On TX Matrix routers, the router can drop the PIM hello messages before a join is triggered by the neighbor. This can cause multicast traffic to be dropped before the next periodic join. [PR/529408: This issue has been resolved.] On M120, output filters applied on a PPPoE interface will not take effect. [PR/528905: This issue has been resolved.] On MX80 routers, non IS-IS fragmented GRE packets are filtered before they are forwarded to the Routing Engine. [PR/529727: This issue has been resolved.] With high numbers of L3VPN routes using composite next hops, routing protocol process scheduler slips occur when a graceful Routing Engine switchover is performed with NSR enabled. [PR/530127: This issue has been resolved.] On MX80 routers, path MTU discovery might not work. [PR/531491: This issue has been resolved.] When the labeled-unicast inet6 route is reflected by route reflectors, the label might be set to explicit-null. [PR/534150: This issue has been resolved.]
110
On a Multiservices PIC or Multiservices DPC running NAT functionality, the show services nat pool detail command might erroneously display positive and negative number of ports in use. [PR/506880: This issue has been resolved.] L2tpd asserts when short frames are sent. This causes the l2tpd to crash. As per RFC 1661 and 1662, such packets should be treated as invalid and discarded. [PR/533057: This issue has been resolved.]
During restart, the interface control process will crash if the PPPoE logical interface is configured without PPPoE options. For example:
pp0 { unit 0 { } }
[PR/528824: This issue has been resolved.] User Interface and Configuration
J-Web does not display the USB option under Maintain>Reboot>Reboot from the media. [PR/464774: This issue has been resolved.] On M7i and M10i routers with Enhanced CFEB installed, the chassis viewer plugin does not display the Routing Engine in the front view and the E-CFEB in the rear view. However, the chassis contents from the system (left side tab) displays all the list of components correctly. [PR/483375: This issue has been resolved.] The licenses are not synced between the master and backup Routing Engine unless the system license traceoptions file file-name statement is configured. Configuring the statement will cause the licenses installed on the master Routing Engine to be synced with the backup Routing Engine. [PR/501443: This issue has been resolved.] The group inherited configuration at the [interface-range] hierarchy level does not take effect. [PR/522872: This issue has been resolved.] Navigation from the Monitor RIP Information page to the Route Information page fails with errors. [PR/536255: This issue has been resolved.]
VPNs
The routing protocol process crashes repeatedly on the new master, a few minutes after a graceful Routing Engine switchover. [PR/527465: This issue has been resolved.]
Release 10.2R1 The following issues have been resolved since JUNOS Release 10.1R3. The identifier following the description is the tracking number in our bug database.
111
Class of Service
When you set the port speed of a multirate SONET Type 2 PIC to OC3, the class-of-service (CoS) speed value is not changed correctly within the Packet Forwarding Engine. The speed value remains OC12, which results in unexpected CoS behavior. There is no workaround. [PR/279617: This issue has been resolved.] If a logical interface is configured or added to an interface set for which an existing traffic control profile is applied, any rate-limit functionality will not be applied to the new logical interface. To resolve this problem, deactivate and activate the interface portion of the class-of-service configuration. [PR/485872: This issue has been resolved.] On an Ichip-based platform for strict high priority queue (SHQ), the buffer size allocated by the Packet Forwarding Engine is capped by the tx-rate. If the tx-rate is configured to a very small value or is not configured, and is automatically allotted a zero or a very small remaining value; the queue is also allotted a proportionately small delay buffer. This can sometimes lead to Red and Tail drops on the SHQ when there is a burst of traffic (with a certain traffic pattern) on it. As a workaround, configure a nominal tx-rate value (5 percent) for the SHQ. [PR/509513: This issue has been resolved.] On M Series and T Series routers, the forwarding class information is lost when the packet enters the GRE tunnel with clear-dont-fragment-bit enabled. Additionally, on an Enhanced FPC or M120 FEB, the packet is also likely to be dropped if it is classified to a packet loss priority (PLP) other than low. [PR/514162: This issue has been resolved.] In a scaled configuration, the class-of-service classifier does not work properly. [PR/522840: This issue has been resolved.]
Policers cannot be modified after a system upgrade due to a flaw in the parser routine. This error occurs when the current item is deleted and the parser cannot proceed to the next item. With the fix, the routine in the forwarding process (dwfd) has been modified so that the next item in the object tree is fetched before the current object is parsed. [PR/433418: This issue has been resolved.] When an unified ISSU is performed for JUNOS Release 10.0 through 10.2, the T640-FPC4-ES crashes continuously. [PR/518301: This issue has been resolved.] When a filter with an ip-options "any" firewall match is applied on an interface on the MX-MPC, the filter is not applied. If the hardware is present at the time of the configuration commit, a commit warning is issued. However, the commit does not fail and the rest of the configuration is applied. [PR/524519: This issue has been resolved.] On T640 and T1600 routers with ST chipset FPCs, in some cases when the IPv6 firewall filters with match conditions configured on address prefixes is longer than 64 bits, the filter may not be evaluated correctly. This might lead to loss of packets. [PR/524809: This issue has been resolved.]
112
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: This issue has been resolved.] The backup Routing Engine can fail to obtain mastership in the following cases:

re0 gets stuck and doesn't reboot. Due to a hardware problem, re0 looses its connectivity with both the Control Board and the Packet Forwarding Engine.
On MX Series routers, traffic is forwarded over the backup link even after the primary link is disabled and enabled again. [PR/493861: This issue has been resolved.] When link trace entries are added in the path database, there is no check to determine if the current number of entries have reached the path database size. Because of this, the entries may grow to be greater than the path database size (configured or default). [PR/494584: This issue has been resolved.] Under certain circumstances a backup Routing Engine reboot followed by a Routing Engine failover can cause the LACP to flap, which causes AE bundles to flap. [PR/502937: This issue has been resolved.] On MX Series routers with JUNOS Release 10.0R2 or higher, the backup Routing Engine might report the following warning message upon commit once network service is configured under the chassis stanza: "WARNING: network services flag has been changed, please reboot system." [PR/505690: This issue has been resolved.] The Routing Engine on slot 1 takes mastership regardless of the user-configured Routing Engine mastership priority. [PR/507724: This issue has been resolved.] When the show chassis hardware models command or the show chassis hardware | display xml command is used, the FRU part-number 710-013035 displays the model number T1600-FPC3-ES instead of T640-FPC3-ES. [PR/514072: This issue has been resolved.] When the show chassis hardware models or show chassis hardware | display xml command is issued for M320-FPC*-E3 with part-numbers 710-025464, 710-025853, and 710-025855, the model number does not display correctly. [PR/514074: This issue has been resolved.] When traffic flows across IQE SDH/SONET interfaces, instantaneous inaccurate traffic rate values with smaller packet sizes occur when the show interface command is issued. [PR/514330: This issue has been resolved.] The output of the show chassis hardware command may not display the SIB details when the SIB is inserted in the slot. [PR/515789: This issue has been resolved.] On some XENPAK modules, the output of the show chassis hardware command shows the message "NON-JNPR UNKNOWN" when the FPC is booted. There is no impact on the traffic. To solve this issue, take the PIC offline and bring it back online. [PR/516411: This issue has been resolved.]
113
On an M120, M7i, or M10i router with Enhanced CFEB running JUNOS Release 10.0 and a VRF routing instance configured with vrf-table-label, the VPN traffic might not flow when an ATM II IQ PIC is used for a core-facing link. [PR/516485: This issue has been resolved.] When a Frame Relay interface goes down, the interface statistics might still indicate that the data-link connection identifier (DLCI) is active. [PR/516497: This issue has been resolved.] When the configuration of shaping and scheduling is added or removed from the CLI, the traffic from the other PE routers is lost. [PR/517320: This issue has been resolved.] On IQ2 and IQ2E 10GE PICs operating in WAN-PHY mode, the path trace information does not get transmitted to the remote end. [PR/518331: This issue has been resolved.] When the centralized configuration management (CCM) interval is set to 1m or above, the CCM flaps for an incorrect hold_time adjacency entry. [PR/520064: This issue has been resolved.] The CE_SUPPORT-DCD crashes when a commit is performed. [PR/521380: This issue has been resolved.] When one of two Ethernet connections to another Routing Engine is not present, the mastership is not switched. [PR/521833: This issue has been resolved.] When multiple routed IPsec tunnels are configured, and the tunnel with the inside-service-interface defined in the service-set goes down, the other tunnels with the ipsec-inside-interface configured only in the IPsec rules can stop forwarding traffic until the main tunnel comes back up. [PR/524935: This issue has been resolved.] When M120 Type 1 FPCs are configured for 2:1 FPC:FEB mapping, and one of the FPCs restarts, the restarting FPC might not initialize properly and result in a small percentage of packet loss for all interfaces on that FPC. As a workaround, restart the FPC until the problem stops. [PR/529994: This issue has been resolved.]
The bpdu-block-on-edge configuration may not work properly when the interface is configured as 'edge' under the [edit protocols vstp vlan vlan-id interface interface-name] hierarchy level. [PR/522198: This issue has been resolved.]
Network Management
After an LCC switchover, the SNMP process fails to send traps with resource temporarily unavailable errors. [PR/493385: This issue has been resolved.] Memory leaks might occur on the mib2d. [PR/517565: This issue has been resolved.] The SNMP MIB OID tree under dot3adAggPort fails. This issue may occur when virtual LAN tagging is not configured on the AE interface, and if the mib2d process is restarted using the restart mibprocess command. [PR/528555: This issue has been resolved.]
114
MPLS Applications
A targeted LDP neighbor may remain up with an old IP address that was previously in use with the loopback address on the remote neighbor. This may happen when either of the following is performed on the remote neighbor:
A secondary loopback (lower than the current primary) address is added and no primary keyword is associated with either of these addresses. A second loopback address is added with the primary keyword.
This results in the targeted LDP neighbor being up with both IP addresses. The neighbor with the old address may continue to remain up even after the old loopback address is deleted on the remote neighbor. This neighborship with the old address eventually times out when the router-id is changed to reflect the new loopback address on the remote neighbor. [PR/518102: This issue has been resolved.]
At adjust intervals, the maximum average bandwidth utilization for the LSP should be reset to zero. MPLS sometimes fails to reset the maximum average bandwidth utilization for the LSP to zero while performing a periodic auto-bandwidth adjustment at the adjust interval. This prevents periodic auto-bandwidth adjustment from adjusting to a lower bandwidth when the traffic rate drops. [PR/528619: This issue has been resolved.]
On M7i routers, kernel panic may occur during route changes. [PR/439420: This issue has been resolved.] The configured static NDP entry is cleared automatically after a certain interval. [PR/453710: This issue has been resolved.] 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: This issue has been resolved.] Memory leaks might occur on the mib2d rtslib. [PR/510902: This issue has been resolved.] The VPN PIM neighborship over the mt- interfaces may not recover after a graceful Routing Engine switchover. [PR/511366: This issue has been resolved.] When an AE interface on an ECMP path is taken down, packet drops may occur on the traffic that is on another link in the ECMP path. [PR/513102: This issue has been resolved.] Under rare conditions, the compressed system-generated routing protocol process core files might be corrupted. As a workaround, disable the compression using sysctl kern.compress_user_cores. [PR/513193: This issue has been resolved.] Setting the TCP maximum segment size (MSS) may not change the actual MSS value. [PR/514196: This issue has been resolved.] On M120 and MX Series routers, when an AE interface (with LACP enabled) is used as a core-facing interface for L3VPN, non-MPLS traffic received on the AE interface can
115
sometimes get black-holed. To recover from this state, deactivate and activate the AE interface in the configuration. [PR/514278: This issue has been resolved.]
When IGMP snooping is enabled, a multicast traffic drop might occur if an IGMP join or leave occurs on other interfaces. [PR/515420: This issue has been resolved.] When the primary link flaps with the route-memory-enhanced statement enabled, jtree might get corrupted and traffic forwarding is affected. As a workaround, deactivate the route-memory-enhanced statement under the chassis stanza. Changes to the route-memory-enhanced statement take effect only when Packet Forwarding Engine is rebooted. [PR/517919: This issue has been resolved.] On some M, MX, and T Series routers, when a firewall filter is applied on the egress of an aggregate interface, packet loss may occur after adding, removing, or changing the service configuration on the egress side of the aggregate interface. As a workaround, deactivate and activate the output firewall filter on the aggregate interface. [PR/517992: This issue has been resolved.] When container AE interfaces are enabled on JUNOS Release 10.0 or 10.1, the following message displays when one of the member links flap: CHPJAR1-re0 fpc3 SCHED: %PFE-0: Thread 40 (PFE Manager) ran for 2015 ms without yielding. [PR/518714: This issue has been resolved.] When the destination class usage (DCU) is configured with unicast reverse path filter (uRPF) and egress forwarding-table filter within the VRF, a VPN route flap might trigger a jtree memory leak. [PR/521609: This issue has been resolved.] No NA packets are returned for NS requests with a static NDP, due to an issue with the neighbor advertisement implementation for statically configured neighbors. [PR/527779: This issue has been resolved.] On some routers, enabling IP-payload-based load balancing for MPLS packets can cause some pseudowire packets to be reordered. [PR/528657: This issue has been resolved.]
On some M, MX, and T Series routers, when a family CCC filter is applied on multiple interfaces that belong to different L2VPN routing instances, packet loss may occur after the routing instances are deactivated and activated. As a workaround, deactivate and activate the CCC filter on the interfaces. [PR/521357: This issue has been resolved.]
Routing Protocols
The backup Routing Engine may generate routing protocol process and kernel cores if the BGP damping is configured along with nonstop active routing (NSR). [PR/452217: This issue has been resolved.] When l3vpn-composite-next-hop is configured, it should only be used by L3VPN routes. However, non-L3VPN routes are also able to use it. [PR/496028: This issue has been resolved.] Upon a graceful Routing Engine switchover with NSR, the routing protocol process will crash due to a wrong process for the PIM instance. [PR/503921: This issue has been resolved.]
116
Nonstop routing (NSR) does not work correctly if an automatic route distinguisher is used with an L2VPN routing-instance. [PR/513949: This issue has been resolved.] The output of the show igmp snooping interface command does not display "-snooping," erroneously stating that IGMP itself is not running instead of IGMP-snooping not running. [PR/516355: This issue has been resolved.] The configured robust count value is not applied on the non-querier router when it receives a robust count value of 0. It uses the default value (2) instead of the configured value. [PR/520252: This issue has been resolved.] The new NSR master may not send the OSPF hello messages immediately after a switchover. [PR/522036: This issue has been resolved.] After a graceful restart, the forwarding state of both provider edge routers might get stuck at the pruned state. However, traffic flow is not affected. [PR/522179: This issue has been resolved.] When an l2circuit ID greater than 2,147,483,647 is configured, and l2circuit tracing is enabled using the set protocols l2circuit traceoptions command, some of the trace messages provide the wrong value (a negative number) for the virtual circuit ID. [PR/523492: This issue has been resolved.] The tag_encoder is unable to handle attempts to stack EXPLICIT_V6_ NULL (label 2) over an existing stack with label 2 on top. Additionally, the BGP module does not send label 2 when readvertising a prefix from an inet6 unicast session to a inet6 labeled-unicast session. [PR/523824: This issue has been resolved.] On TX Matrix routers, the router can drop the PIM hello messages before a join is triggered by the neighbor. This can cause multicast traffic to be dropped before the next periodic join. [PR/529408: This issue has been resolved.] When the labeled-unicast inet6 route is reflected by route reflectors, the label might be set to explicit-null. [PR/534150: This issue has been resolved.]
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: This issue has been resolved.] The IPv6 gateway may have a NULL value when the destination address points to an aggregated next hop. [PR/516058: This issue has been resolved.] NAT over FTP fails when it receives a SERVER 227 code string "Entering passive mode" in lowercase. [PR/522029: This issue has been resolved.]
117
BFD sessions and other protocol adjacencies configured with low hello or dead timers over an aggregate or IRB interfaces might flap upon configuration commit when the dhcp-local-server or dhcp-relay is used. [PR/507428: This issue has been resolved.]
Users who have superuser privileges will sometimes have their access restricted to view permission only when they log in through TACACS. [PR/388053: This issue has been resolved.] If the time zone is set to Europe/Berlin, the command commit at "time-string" will fail. [PR/483273: This issue has been resolved.] The group inherited configuration under the interface-range hierarchy level does not take effect. [PR/522872: This issue has been resolved.] Navigation from Monitor RIP Information page to the Route Information page fails with errors. [PR/536255: This issue has been resolved.]
VPNs
While upgrading JUNOS Software with l2circuit configuration underthe logical systems, the validation might fail with an "interface version mismatch" error. You can ignore this error and upgrade the JUNOS Software using the no-validate option. [PR/497190: This issue has been resolved.] The routing protocol process crashes repeatedly on the new master, a few minutes after a graceful Routing Engine switchover (GRES). [PR/527465: This issue has been resolved.] New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 7 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 45 Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers on page 118 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 127
Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers
Changes to the JUNOS Documentation Set
The JUNOS Layer 2 Configuration Guide provides an overview of the Layer 2 functions supported on Juniper Networks routers, including configuring bridge domains, MAC addresses and VLAN learning and forwarding, and spanning-tree protocols. It also details
118
the routing instance types used by Layer 2 applications. This material was formerly covered in the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide. 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. Class of Service
TheJUNOS Class of Service Configuration Guide does not show the correct syntax for the guaranteed-rate and shaping-rate statements available at the [edit class-of-service traffic-control-profiles profile-name] hierarchy level. As of Junos OS Release 9.4, both of these statements support a burst-size option for Enhanced Queuing (EQ) DPCs. Specifying the burst-size option can help to make sure higher priority services do not starve lower priority services. To configure these statements, use the following syntax:
guaranteed-rate (percent percentage | rate) <burst-size bytes>; [edit class-of-service traffic-control-profiles profile-name]
[Junos OS Class of Service Configuration Guide]
In JUNOS Release 10.1 and 10.2, the topic Example: Configuring Large Delay Buffers for Slower Interfaces states Assuming that the sched-best scheduler is assigned to a T1 interface This is an error. The topic should state Assuming that the sched-exped scheduler is assigned to a T1 interface [Class of Service]
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)
The topics Assigning a NAT Pool and Assigning a NAT Pool for the BGF contain a reference to the media-service configuration statement, which was deprecated in JUNOS Release 10.2R1.
119
Assigning a NAT Pool was replaced in Integrated Multi-Service Gateway (IMSG) by a new topic, Configuring NAT Pools. However, Assigning a NAT Pool was not deleted and should be ignored. [Integrated Multi-Service Gateway IMSG]
Assigning a NAT Pool for the BGF was replaced in Border Gateway Function (BGF) by a new topic, Configuring NAT Pools. However, Assigning a NAT Pool was not deleted and should be ignored.
[Integrated Multi-Service Gateway (IMSG), Border Gateway Function (BGF)]
The new-transaction-output-policies configuration statement was introduced in JUNOS Release 10.1R1. The document did not mention the following restriction. New transaction policies that include route or message-manipulation options cannot be configured as new-transaction-output-policies. [Integrated Multi-Service Gateway (IMSG), Services Interfaces Configuration]
For the T320, T640, and T1600 routers, external clock synchronization is not supported on sonic clock generators (SCG) with DB-9 external clock interfaces. [System Basics, Hardware Guides]
The Configuring Aggregated Ethernet Interfaces chapter in the Network Interfaces Configuration Guide contains references to the term multi-chassis. As per the Juniper Networks Corporate Style Guide, multi-chassis should be replaced with multichassis, without a hyphen. [Network Interfaces]
The Configuring ECMP Next Hops for RSVP and LDP LSPs for Load Balancing topic in the System Basics Configuration Guide does not mention the following caveat for configuring ECMP next hops for RSVP LSPs: If RSVP LSPs are configured with bandwidth allocation, for ECMP next hops with more than 16 LSPs, traffic is not distributed optimally based on bandwidths configured. Some LSPs with smaller allocated bandwidths receive more traffic than the ones configured with higher bandwidths. Traffic distribution does not strictly comply with the configured bandwidth allocation. This caveat is applicable to the following routers:
T1600 and T640 routers with Enhanced Scaling FPC1, Enhanced Scaling FPC2, Enhanced Scaling FPC3, Enhanced Scaling FPC 4, and all Type 4 FPCs M320 routers with Enhanced III FPC1, Enhanced III FPC2, and Enhanced III FPC3 MX Series routers with all types of FPCs and DPCs, excluding MPCs
NOTE: This caveat is not applicable to MX Series routers with line cards based on the JUNOS Trio chipset.
120
M120 routers with Type 1, Type 2, and Type 3 FPCs M10i routers with Enhanced CFEB
[System Basics]
The description for the default-address-selection configuration statement in the System Basics Configuration guide must be: Use the loopback interface (interface to the routers or switchs Routing Engine), lo0, for all locally generated IP packets sourced from the interface and sent out on a regular routable interface, but not for packets routed through the loopback interface. [System Basics] The description for the seconds option for the idle-timeout configuration statement must be: The number of seconds a user can remain idle before the session is terminated. Some of the reasons a session can remain idle are:

Absence of ingress traffic on the PPP session Absence of egress traffic on the PPP session Absence of either ingress or egress traffic on the PPP session Absence of either ingress or egress traffic on the PPP session Absence of ingress or egress ppp control traffic
Range0 through 4,294,967,295 seconds Default0 [System Basics]
Output fields displayed for the show chassis fabric topology command on a TX Matrix Plus routerThe description of the output fields on a TX Matrix Plus router for the show chassis fabric topology command is as follows:
121
Table 4: Output fields for the show chassis fabric topology command
Field Name
Out-Links:
Field Description
State of the links from the F13 SIB to the LCC or vice-versa. Out-Links indicate Tx links. In-Links indicate an Rx link. The following additional fields are displayed for each SIB:
and
In-Links:
VCSEL StatusOptical (VCSEL channel) link status for the corresponding electrical (HSL2) link. The states
include: OKOptical signal power is good.

ErrorInternal error. LOSLoss of Signal detected. High CurThe Tx Bias-current is higher than threshold on this channel. This is applicable only to Tx Channels. Low Cur The Tx Bias-current is lower than threshold on this channel. This is applicable only to Tx Channels.
HSL2 ChannelHSL2 is the electrical link used to connect ASICs to the in-link and out-link. The channel number
corresponds to the link and varies based on the ASIC or configuration.

HSL2 Status The status of the HSL2 Channel. Includes the following states: UpChannel is up. DownChannel is down. ResetChannel has been reset. FaultChannel has faults.
The following is a sample output with description of the fields displayed in the output for Out-Links: Out-Links: ========= SF_3_13_FB_A(21,09) -> FPC7_B_SG(3,3,6)_FB_A(18,09)
OK
203
Up
SF_3_13Name of the ASIC, with Fabric F1 or F3 mode. In this case, 3 is the F3 direction and is used in the Tx
path. You can also have F1 mode and Rx path instead.
FB_A (21, 09)Fiber bundle A, with VCSEL unit number 21 within the SIB, and channel number 9 within the unit
number.
FPC7_B_SG(3,3,6FPC 7.with bottom Packet Forwarding Engine (T for top PFE and B for bottom PFE), SG
ASIC, with number 3 and port number 3, with HSL2 link number with the SIB as 6.
FB_A(18, 09)Fiber Bundle, with VCSEL unit number 18 within the SIB, and VCSEL channel number 9 within
the unit number. The following is a sample output with description of the fields displayed in the output for In-Links:
In-Links: ========= FPC0_T_SG(0,0,0)_FB_D(04,11)

-> SF_1_00_FB_D(01,11)
OK
Up
FPC0FPC 0. TTop Packet Forwarding Engine. SG (0, 0, 0)SG ASIC with port number 0 and link 0. FB_D (04,11)Fiber Bundle D with VCSEL 4, channel 11. SF_1Indicates F1 mode and Rx path. SF_1_00_FB_D(01,11) Indicates F1 mode and Rx path with port 0, fiber bundle D, with VCSEL 1, channel 11.
In Chapter 19, Router Chassis Configuration Guidelines and Chapter 20, Summary of Router Chassis Configuration Statements of the System Basics Configuration Guide, the
122
TX Matrix Plus router is omitted from the list of devices that support the fpc-resync statement. The TX Matrix Plus router does support this statement. [System Basics]
The Network Interfaces Configuration Guide, section Creating the IMA Groups (ATM Interfaces) should include the following statement: The PIC is automatically rebooted when a configuration that changes the IMA group count is committed. [Network Interfaces]
In the Network Interfaces Configuration Guide, Chapter 61, Configuring SONET/SDH Interfaces, included a subsection titled Configuring APS Using a Container Interface with ATM Encapsulation. This information was mistakenly included and should not have been published until JUNOS Release 10.4. [Network Interfaces]
The Configuring Layer 2 Circuit Transport Mode chapter in the Network Interfaces Configuration Guide states that one way to configure an ATM II interface to enable a Layer 2 circuit connection across all versions of JUNOS Software is the following:
For Layer 2 circuit cell relay and Layer 2 trunk modes, the atm-l2circuit-mode cell statement at the [edit chassis fpc slot pic slot] hierarchy level and the encapsulation atm-ccc-cell-relay statement at the [edit interface interface-name] hierarchy level.
The configuration above is correct and will interoperate with routers running all versions of JUNOS Software. However, the chapter does not mention that you can also include the encapsulation atm-ccc-cell-relay statement at the [edit interface interface-name unit logical-unit-number] hierarchy level. When you use the above configuration, keep the following points in mind:
This configuration will interoperate between Juniper Networks routers running JUNOS Release 8.2 or lower. This configuration will NOT interoperate with other network equipment, including a Juniper Networks router running JUNOS Release 8.3 or higher. For a Juniper Networks router running JUNOS Release 8.3 or higher to interoperate with another Juniper Networks router running JUNOS Release 8.2 or lower, on the router running JUNOS Release 8.3 or higher, include the use-null-cw statement at the [edit interfaces interface-name atm-options] hierarchy level. The use-null-cw statement inserts (for sending traffic) or strips (for receiving traffic) an extra null control word in the MPLS packet. The use-null-cw statement is not supported on a router running JUNOS Release 8.2 or lower.
[Network Interfaces]
123
The erroneously states that persistent changes work like the load merge command and transient changes work like the load update command. Both persistent and transient changes behave like the load replace command. In the chapter Summary of JUNOS XML and XSLT Tag Elements Used in Commit Scripts, the <change> and <transient-change> tag element summaries include attributes for both tags. Neither the <change> tag nor the <transient-change> tag has attributes. All references to the attributes in the Description section are not applicable to these tags. []
J-Web Interface
To access the J-Web interface, your management device requires the following software:
Supported browsersMicrosoft Internet Explorer version 7.0 or Mozilla Firefox version 3.0 Language supportEnglish-version browsers Supported OSMicrosoft Windows XP Service Pack 3
Multicast
The listings for the following RFCs incorrectly state that the Junos OS supports only SSM include mode. Both include mode and exclude mode are supported in Junos OS Release 9.3 and later.

RFC 3376, Internet Group Management Protocol, Version 3 RFC 3590, Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
[Hierarchy and Standards Reference] Routing Protocols
Bidirectional Forwarding DetectionThe Routing Protocols Configuration Guide contains conflicting information about how to configure the Bidirectional Forwarding Detection (BFD) liveness detection minimum-interval statement. BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. Depending on your network environment, these additional recommendations might apply:
For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions. For very large-scale network deployments with a large number of BFD sessions, please contact Juniper Networks customer support for more information.
124
For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing (NSR) is configured, specify a minimum interval of 2500 ms for Routing Engine-based sessions. For distributed BFD sessions with NSR configured, the minimum interval recommendations are unchanged and depend only on your network deployment.
[Routing Protocols] Services Applications
Border Gateway Function (BGF) apply implicit latching on TCP gates when the gate is createdBy default, latching of gates is done by explicit latch requests. You can configure implicit latching of gates by entering the set implicit-tcp-latch and set implicit-tcp-source-filter configuration statements at the [edit services pgcp gateway gateway-name h248-options] hierarchy level. The new configuration statements result in the following actions:
implicit-tcp-latchIf explicit latching has been applied (using using ipnapt/latch)
on either gate of a gate pair, implicit latching is not applied. If explicit latching has not been applied on either gate:

Latching is applied to both gates of the gate pair. When either of the gates latches, latching is automatically disabled on the other gate.
implicit-tcp-source-filterApplies source address (but not source port) filtering on
incoming packets, using the current remote destination address under the following conditions:

Explicit source filtering has not been applied by use of gm/saf. Explicit latching has not been applied by use of ipnapt/latch.
[Border Gateway Function (BGF), Services Interfaces]
The rate statement for packet sampling is now configured at the following hierarchy level: [edit forwarding options sampling input family family]. [Services Interfaces]
Subscriber Access Management 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:
125
$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. [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]
In the JUNOS Subscriber Access Configuration Guide, Table 26, RADIUS-Based Mirroring Attributes incorrectly indicates that RADIUS VSA 26-10, Juniper-User-Permissions, is required for subscriber secure policy mirroring. In fact, this VSA is not used. [Subscriber Access]
126
Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers
The show system statistics bridge command displays system statistics on MX Series routers. [System Basics Command Reference]
VPNs
In the example Carrier-of-Carriers VPN ExampleCustomer Provides VPN Service in Chapter 23 Configuration Examples for Interprovider and Carrier-of-Carriers VPNs of the VPNs Configuration Guide, the configurations of Router E and Router H (both PE routers) did not include the as-override statement in the [edit routing-instances vpn-isp1] hierarchy level, causing the examples to not work. This statement has now been added to both configurations. [VPNs] In Chapter 10, Configuring Layer 3 VPNs of the VPNs Configuration Guide, the M10i router is omitted from the list of devices that support the vrf-table-label statement. The M10i router does support this statement. [VPNs] In Chapter 19, Configuring VPLS of the VPNs Configuration Guide, an incorrect statement that caused contradictory information about which platforms support LDP BGP interworking has been removed. The M7i router was also omitted from the list of supported platforms. The M7i router does support LDP BGP interworking. [VPNs]
New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 7 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 45 Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 127
This section discusses the following topics:

Basic Procedure for Upgrading to Release 10.2 on page 128 Upgrade Policy for JUNOS Software Extended End-Of-Life Releases on page 130 Upgrading a Router with Redundant Routing Engines on page 130 Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS Release 10.1 on page 131 Upgrading the Software for a Routing Matrix on page 132 Upgrading Using ISSU on page 133
127
Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both PIM and NSR on page 134 Downgrade from Release 10.2 on page 135
Basic Procedure for Upgrading to Release 10.2

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.5 you can upgrade to JUNOS Release 10.1 but not to JUNOS Release 10.2 As a workaround, first upgrade to JUNOS Release 10.1 and then upgrade to JUNOS Release 10.2.
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) might 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.
128
The download and installation process for JUNOS Release 10.2 is the same as for previous JUNOS releases. If you are not familiar with the download and installation process, follow these steps:
1.
Using a Web browser, follow the links to the download URL on the Juniper Networks Web page. Choose either Canada and U.S. Version or Worldwide Version:
https://www.juniper.net/support/csc/swdist-domestic/ (customers in the United
States and Canada)
https://www.juniper.net/support/csc/swdist-ww/ (all other customers)
2. Log in to the Juniper Networks authentication system using the username (generally
your e-mail address) and password supplied by Juniper Networks representatives.

3. Download the software to a local host. 4. Copy the software to the routing platform or to your internal software distribution
site.
5. Install the new jinstall package on the routing platform.
NOTE: We recommend that you upgrade all software packages out of band using the console because in-band connections are lost during the upgrade process.
Customers in the United States and Canada use the following command:
user@host> request system software add validate reboot source/jinstall-10.2R4.8-domestic-signed.tgz
All other customers use the following command:

user@host> request system software add validate reboot source/jinstall-10.2R4.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.
129
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.2 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.
Upgrade Policy for JUNOS Software Extended End-Of-Life Releases

An expanded upgrade and downgrade path is now available for the JUNOS Software Extended End-of-Life (EEOL) releases. You can upgrade directly from one EEOL release to one of two adjacent later EEOL releases. You can also downgrade directly from one EEOL release to one of two adjacent earlier EEOL releases. For example, JUNOS Software Releases 8.5, 9.3, 10.0, and 10.4 are all EEOL releases. You can upgrade from JUNOS Software Release 8.5 directly to either 9.3 or 10.0. To upgrade from Release 8.5 to 10.4, you first need to upgrade to JUNOS Software release 9.3 or 10.0, and then upgrade a second time to 10.4. Similarly, you can downgrade directly from JUNOS Software Release 10.4 to either 10.0 or 9.3. To downgrade from release 10.4 to 8.5, you first need to downgrade to 10.0 or 9.3, and then perform a second downgrade to Release 8.5. For upgrades and downgrades to or from a non-EEOL release, the current policy is that you can upgrade and downgrade by no more than three releases at a time. This policy remains unchanged. For more information on EEOL releases and to review a list of EEOL releases, see http://www.juniper.net/support/eol/junos.html.
Upgrading a Router with Redundant Routing Engines

If the router has two Routing Engines, perform a JUNOS Software installation on each Routing Engine separately to avoid disrupting network operation as follows:
130
1.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine and save the configuration change to both Routing Engines.
2. Install the new JUNOS Software release on the backup Routing Engine while keeping
the currently running software version on the master Routing Engine.

3. After making sure that the new software version is running correctly on the backup
Routing Engine, switch over to the backup Routing Engine to activate the new software.
4. Install the new software on the original master Routing Engine that is now active as
the backup Routing Engine. For the detailed procedure, see the JUNOS 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. 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.
131
2. 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.
3. 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.
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).
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 that the following conditions are met 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.
132
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.
To upgrade the software for a routing matrix, perform the following steps:
1.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine (re0) and save the configuration change to both Routing Engines.
2. Install the new JUNOS Software release on the backup Routing Engine (re1) while
keeping the currently running software version on the master Routing Engine (re0).
3. Load the new JUNOS Software on the backup Routing Engine. After making sure that
the new software version is running correctly on the backup Routing Engine (re1), switch mastership back to the original master Routing Engine (re0) to activate the new software.
4. Install the new software on the new backup Routing Engine (re0).
For the detailed procedure, see the Routing Matrix with a TX Matrix Feature Guide or the Routing Matrix with a TX Matrix Plus Feature Guide.
Upgrading Using ISSU

Unified in-service software upgrade (ISSU) enables you to upgrade between two different JUNOS Software releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU 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.
133
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 enabled, use the standard reboot or unified ISSU procedures described in the other sections of these instructions. Because the nonstop-routing disable statement was not available in JUNOS Release 9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to be upgraded from JUNOS Release 9.2 or earlier to a later release, you must disable PIM before the upgrade and reenable it after the router is running the upgraded JUNOS Software and you have entered the nonstop-routing disable statement. If your router is running JUNOS Release 9.3 or later, you can upgrade to a later release without disabling NSR or PIM by simply usng the standard reboot or unified 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 unified ISSU.
134
3. After the router reboots and is running the upgraded JUNOS Software, enter
configuration mode, disable PIM NSR with the nonstop-routing disable statement, and then reenable PIM:
[edit] user@host# set protocols pim nonstop-routing disable user@host# activate protocols pim user@host# commit
Downgrade from Release 10.2

To downgrade from Release 10.2 to another supported release, follow the procedure for upgrading, but replace the 10.2 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. Related Documentation
New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 7 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 45 Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63 Errata and Changes in Documentation for JUNOS Software Release 10.2 for M Series, MX Series, and T Series Routers on page 118
135
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.2 for SRX Series Services Gateways and J Series Services Routers on page 136 Advertising Bandwidth for Neighbors on a Broadcast Link Support on page 173 Group VPN Interoperability with Ciscos GET VPN on page 174 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 175 Unsupported CLI Statements and Commands on page 188 Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 197 Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211 Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 239 Hardware Requirements for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 251 Stream Control Transmission Protocol Overview on page 254 Maximizing ALG Sessions on page 255 Upgrade and Downgrade Instructions for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 256
New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
The following features have been added to JUNOS Release 10.2. Following the description is the title of the manual or manuals to consult for further information.

Software Features on page 137 Hardware FeaturesSRX210 Services Gateways on page 168
136
Hardware FeaturesSRX240 Services Gateways on page 168 Hardware FeaturesSRX210 and SRX240 Services Gateways with Integrated Convergence Services on page 171 Hardware FeaturesSRX650 Services Gateways on page 172 Hardware FeaturesSRX3400 and SRX3600 Services Gateways on page 173
Software Features
Application Layer Gateways (ALGs)
Layer 2 mode with chassis clusteringThis feature is now supported on SRX3400 and SRX3600 devices in addition to existing support on SRX5600 and SRX5800 devices. The following Application Layer Gateways (ALGs) are supported in Layer 2 mode with chassis clustering:

Real-Time Streaming Protocol (RTSP) File Transfer Protocol (FTP) Trivial File Transfer Protocol (TFTP)
[JUNOS Software Security Configuration Guide, JUNOS Software Layer 2 Bridging and Switching Configuration Guide for Security Devices]
Application Layer Gateway for IKE and ESPThis feature is supported on all SRX Series and J Series devices. An SRX Series or a J Series device can be used solely as a NAT device when placed between VPN clients on the private side of the NAT gateway and the VPN gateways on the public side. Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) traffic is exchanged between the clients and the server. However, if the clients do not support NAT-T and if the device assigns the same NAT-generated IP address to two or more clients, the device will be unable to distinguish and route return traffic properly.
NOTE: If the user wants to support both NAT-T capable and non-NAT-T capable clients, then some additional configurations are required. If there are NAT-Traversal (NAT-T) capable clients, the user must enable the source NAT address persistence.
ALG for IKE and ESP monitors IKE traffic between the client and the server and permits only one IKE Phase 2 message exchange at the same time between any given client-server pair, not just one exchange between any client and any server. This feature allows the device to be configured to return the same NAT-generated IP address for the same IP address without NAT ("address-persistent NAT"). As a result, the device is able to associate a client's outgoing IKE traffic with its return traffic from the server, especially when the IKE session times out and needs to be reestablished.
137
The resulting ESP traffic between the client and the server must also be allowed, especially in the direction from the server to the client. The return ESP traffic must match the following:

The server IP address as source IP The client IP address as destination IP
To address these issues, ALG for IKE and ESP traffic has been created and NAT has been enhanced to enable the SRX Series and J Series devices to pass IKE and ESP traffic with a source NAT pool. [JUNOS Software Security Configuration Guide] AppSecure
JUNOS Software application identificationThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. Application identification is used by IDP to allow or deny traffic based on applications running on nonstandard TCP or UDP ports, without prior knowledge of port binding. Application tracking (AppTrack) can also use the information collected by application identification to provide detailed reports on applications passing through the device. The following improvements have been made to application identification:
Improved granularity for nested application identification allows identification of applications nested in HTTP traffic, such as Facebook. Application definition database contents can now be viewed in the configuration. Custom application and nested application definitions can be created to identify applications that are not be part of the predefined application database. Application tracking (AppTrack) now provides reporting on information collected by application identification.
When using application identification without IDP enabled, you extract the application definition database from the IDP signature database with the command: request services application-identification download. This command will extract and install the application portion of the IDP signature database to your configuration. If you have IDP enabled and will use application identification, you will continue to run the IDP signature database download: request security idp security-package download and request security idp security-package install. If you have modified the default IDP application identification sensor configuration in JUNOS Release 9.6, 10.0, or 10.1, and you upgrade to JUNOS Release 10.2, you will need to reenter your settings by using the CLI commands in the services hierarchy.
NOTE: On the SRX100, SRX210, SRX240, and SRX650 devices, the IDP application identification feature does not change and the hierarchy is still in [edit security idp sensor-configuration application-identification].
138
Table 5 on page 139 shows changes to the applications CLI, and Table 6 on page 139 shows changes to nested applications. Items in bold font are new or have changed. The new hierarchy for application identification is [edit services application-identification].
Table 5: Application Identification Application CLI Changes

Application IDP CLI (existing) Application CLI (new for Release 10.2)
max-checked-bytes application-system-cache-timeout max-packet-memory max-sessions max-tcp-session-packet-memory max-udp-session-packet-memory no-application-system-cache disable application-system-cache-timeout max-sessions no-application-identification no-application-system-cache
The new hierarchy for nested application identification is [services application-identification nested-application-settings].
Table 6: Application Identification Nested Applications CLI Change

Nested Applications IDP CLI (existing)
no-nested-application-system-cache no-nested-application-identification
Nested Applications CLI (new for Release 10.2)

no-application-system-cache no-nested-application
[JUNOS Software CLI Reference, JUNOS Software Security Configuration Guide]
AppTrackThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. Application tracking (AppTrack) delivers statistical information on application usage. AppTrack on high-end SRX Series devices uses application identification to collect byte, packet, and time statistics specific to an application and sends the data to a log server capable of receiving AppTrack-formatted messages. Network management tools generate volumetric reports from the logged statistics. [JUNOS Software Security Configuration Guide]
139
Auto BIOS Upgrade
This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices. JUNOS Release 10.2 is shipped with BIOS version 1.7. For the SRX100 device, the minimum compatible BIOS version is 1.6. For the SRX210, SRX240, and SRX650 devices, the minimum compatible BIOS version is 1.5. If the BIOS version of the current device is earlier than the minimum compatible version, then the auto BIOS upgrade feature upgrades the BIOS automatically to the BIOS shipped with the JUNOS package. The BIOS is upgraded automatically in the following scenarios:
During JUNOS Software upgrading through either the J-Web interface or the CLIIn this case, only the active BIOS is upgraded. During loader installation using TFTP or USBIn this case, only the active BIOS is upgraded. During system boot-upIn this case, both the active BIOS and the backup BIOS are upgraded.
The auto BIOS upgrade feature is enabled by default. Users can disable this feature by using the set chassis routing-engine bios no-auto-upgrade command on the CLI.
NOTE: This command disables the automatic upgrade of BIOS during JUNOS Software upgrade or system boot-up. It does not disable automatic BIOS upgrade during loader installation.
[JUNOS Software Administration Guide for Security Devices, JUNOS Software CLI Reference]
140
Manual BIOS Upgrade Using JUNOS CLI
This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices. For branch SRX Series devices, BIOS is made up of U-boot and JUNOS loader. Apart from this SRX240 and SRX650 also have U-shell binary as part of the BIOS. On SRX100, SRX210 and SRX240, there is support of Backup BIOS, which constitutes a backup copy of U-boot in addition to the active copy from which the system generally boots up. Table 7 on page 141 provides details of BIOS components supported for different platforms.
Table 7: Manual BIOS Upgrade Components

BIOS Components
Active U-boot Loader U-shell Backup U-boot Yes Yes
SRX100
Yes Yes
SRX210
Yes Yes
SRX240
Yes Yes Yes Yes
SRX650
Yes Yes Yes
Table 8 on page 141 provides you the CLI commands used for manual BIOS upgrade.
Table 8: CLI Commands for Manual BIOS Upgrade

Active BIOS
request system firmware upgrade re bios
Backup BIOS
request system firmware upgrade re bios backup
Procedure for BIOS upgrade

1.
Installing a jloader-srxsme package

1.
Copy the jloader-srxme signed package to the device.
NOTE: Note that this package should be of the same version as that of the corresponding JUNOS. For example, on a device with a 10.2 JUNOS package installed, the jloader-srxsme package should also be of version 10.2.
2. Install the package using the request system software add <path to jloader-srxsme
package> no-copy no-validate command.

root> request system software add /var/tmp/jloader-srxsme-10.2B3-signed.tgz no-copy no-validate Installing package '/var/tmp/jloader-srxsme-10.2B3-signed.tgz' ... Verified jloader-srxsme-10.2B3.tgz signed by PackageProduction_10_2_0
141
Adding jloader-srxsme... Available space: 427640 require: 2674 Mounted jloader-srxsme package on /dev/md5... Saving state for rollback ... root> show version Model: srx240h JUNOS Software Release [10.2B3] JUNOS BIOS Software Suite [10.2B3]
NOTE: Installing the jloader-srxsme package puts the necessary images under directory/boot.
2. Verifying that images for upgrade are installed
The show system firmware command can be used to get version of images available for upgrade. The available version is printed under column Available version. The user needs to verify that the correct version of BIOS images available for upgrade.
root> show system firmware
Part Routing Engine 0 Routing Engine 0 Routing Engine 0
Type
Tag
RE BIOS 0 RE BIOS Backup 1 RE FPGA 11
Current version 1.5 1.5 12.3.0
Available version 1.7 1.7
Status OK OK OK
142
3. BIOS upgrade
Active BIOS:
1.
Initiate the upgrade using the request system firmware upgade re bios command.
root> request system firmware upgrade re bios
Part
Current Available version version Routing Engine 0 RE BIOS 0 1.5 1.7 Routing Engine 0 RE BIOS Backup 1 1.5 1.7 Perform indicated firmware upgrade ? [yes,no] (no) yes
Type
Tag
Status OK OK
Firmware upgrade initiated. 2. Monitor the status of upgrade using the show system firmware command. root> show system firmware
Type RE BIOS RE BIOS Backup RE FPGA
Tag 0 1 11
Current version 1.5 1.5 12.3.0
Status PROGRAMMING OK OK
root> show system firmware Part Routing Engine 0 Type RE BIOS Tag 0 Current version 1.5 Available Status version 1.7 UPGRADED SUCCESSFULLY 1.7 OK OK
Routing Engine 0 Routing Engine 0
RE BIOS Backup RE FPGA
1 11
1.5 12.3.0
NOTE: The device must be rebooted for the upgraded active BIOS to take effect.
Backup BIOS:
1.
Initiate the upgrade using the request system firmware upgade re bios backup command.
root> request system firmware upgrade re bios backup
Part
Current Available version version Routing Engine 0 RE BIOS 0 1.5 1.7 Routing Engine 0 RE BIOS Backup 1 1.5 1.7 Perform indicated firmware upgrade ? [yes,no] (no) yes
Type
Tag
Status OK OK
Firmware upgrade initiated. 2. Monitor the status of upgrade using the show system firmware command.
143
root> show system firmware
Type
Current version RE BIOS 0 1.5 RE BIOS Backup 1 1.5 RE FPGA 11 12.3.0
Tag
Status OK PROGRAMMING OK
root> show system firmware Part Routing Engine 0 Routing Engine 0 Routing Engine 0 Type RE BIOS RE BIOS Backup RE FPGA Tag 0 1 11 Current version 1.5 1.7 12.3.0 Available version 1.7 1.7 Status OK UPGRADED SUCCESSFULLY OK
Chassis Cluster
Multicast routing across nodes in a chassis clusterThis feature is supported on all SRX Series and J Series devices. Multicast routing support across nodes in a chassis cluster allows multicast protocols, such as Protocol Independent Multicast (PIM) versions 1 and 2, Internet Group Management Protocol (IGMP), Session Announcement Protocol (SAP), and Distance Vector Multicast Routing Protocol (DVMRP), to send traffic across interfaces in the cluster. Note, however, that the multicast protocols should not be enabled on the chassis management interface (fxp0) or on the fabric interfaces (fab0 and fab1). Multicast sessions will be synched across the cluster and will be maintained during redundant group failovers. During failover, as with other types of traffic, there might be some multicast packet loss. Multicast data forwarding in a chassis cluster uses the incoming interface to determine whether or not the session remains active. Packets will be forwarded to the peer node if a leaf sessions outgoing interface is on the peer instead of on the incoming interfaces node. Multicast routing on a chassis cluster supports tunnels for both incoming and outgoing interfaces. Multicast configuration on a chassis cluster is the same as multicast configuration on a standalone device. [JUNOS Software Security Configuration Guide]
Dual fabric linksThis feature is supported on all SRX Series and J Series devices. You can connect two fabric links between each device in a cluster, which provides a redundant fabric link between the members of a cluster. When you use dual fabric links, the runtime objects (RTOs) and probes are sent on one link and the fabric-forwarded and flow-forwarded packets are sent on the other link. If one fabric link fails, the other fabric link handles the RTOs and probes, as well as the data forwarding. Having two fabric links helps to avoid a possible single point of failure. [JUNOS Software Security Configuration Guide]
144
Dual control linksThis feature is now supported on SRX3400 and SRX3600 devices in addition to existing support on SRX5600 and SRX5800 devices. You can connect two control links between each device in a cluster, which provides a redundant control path between the members of a cluster. For the SRX3400 and SRX3600 devices, this functionality requires an SRX Clustering Module (SCM) to be installed on each device in the cluster. Unlike the SRX5600 and SRX5800 devices, a second Routing Engine is not supported on the SRX3400 and SRX3600 devices. The purpose of the SCM is to initialize the second control link. Having two control links helps to avoid a possible single point of failure. [JUNOS Software Security Configuration Guide]
145
Flow and Processing
Flow CLI enhancementsThis feature is supported on all SRX Series and J Series devices. The show security flow status command displays information on flow processing modes and logging status. The show security flow statistics command displays information on session and packet counters.
NOTE: Services Processing Unit (SPU) information is not displayed on SRX100, SRX210, SRX240, and SRX650 devices.
The central point session command also displays SPU information for the whole system. The security flow session output can be viewed in summary, brief, and extensive mode using the show security flow session command. This command displays information on session detail retrieval. SPU information such as the SPU identifier, FPC, and PIC can be viewed using this command. The SPU identifier displays entries per SPU. Gate statistics can be viewed using the show security flow gate summary command. The show security flow gate command displays the total number of gates. The show security flow gate and the show security flow cp-session command support the following:

Display of multiple filters Display of output in summary mode using filters Display of SPU information for multiple SPU systems
[JUNOS Software Security Configuration Guide]
146
Integrated Convergence Services
Accounting featureThis feature is supported on SRX210 and SRX240 devices. You can configure Integrated Convergence Services to collect and generate accounting information for successful and unsuccessful voice subscriber transactions. The voice daemon generates and collects accounting data about calls made and received between Session Initiation Protocol (SIP), Foreign Exchange Station (FXS), and Foreign Exchange Office (FXO) stations. You can use the accounting feature for calls made when the SRX Series media gateway (SRX Series MGW) is in control or when the SRX Series survivable call server (SRX Series SCS) is in control. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Call parkThis feature is supported on SRX210 and SRX240 devices. The call park feature allows users to park an active call and pick up their call or that of another user later. To use the call park feature, you configure a primary logical extension, which you can think of as a parking lot. You must also configure a range of logical extensions following the primary one that are used to park individual calls. When a user is handling a call, they can transfer it to the parking lot without the caller hearing the transfer process. When the user parks the call, they are told the logical extension number of the parking slot before their connection to the call is dropped. That user or another one can pick up the call and resume the conversation from any phone by calling the extension number of the parking slot. This feature is supported when the SRX Series SCS is in control. Under normal conditions when it is reachable, the peer call server provides this service if it is supported. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Defining a SIP registrar address separate from the peer call serverThis feature is supported on SRX210 and SRX240 devices. By default, the SIP registrar and the peer call server (SIP server) are handled by the same service and therefore have the same address. Under these circumstances, the SRX Series MGW sends SIP REGISTRAR and INVITE messages to the IP address configured for the peer call server. In some SIP network environments, the registrar and the peer call server are separate entities. For these network environments, you can specify separate addresses for the registrar and the peer call server. If you configure a separate address for the registrar, INVITE messages are sent to the peer call server and REGISTER messages are sent to the registrar. If you do not configure a registrar address, the default behavior takes effect. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Defining a SIP registrar address separate from the peer proxy serverThis feature is supported on SRX210 and SRX240 devices.
147
By default, the SIP registrar and the peer proxy server (SIP server) are handled by the same service and therefore have the same address. In this case, the SRX Series MGW sends SIP REGISTRAR and INVITE messages to the IP address configured for the peer proxy server. In some SIP network environments, the registrar and the peer proxy server are separate entities. For these network environments, you can specify separate addresses for the registrar and the peer proxy server. If you configure a separate registrar address, INVITE messages are sent to the peer proxy server and REGISTER messages are sent to the registrar. If you do not configure a registrar address, the default behavior takes effect. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Direct inward dialing listsThis feature is supported on SRX210 and SRX240 devices. You can associate a list of direct inward dialing (DID) numbers with a trunk to be used for assignment to stations. You do not need to assign these DIDs to stations directly. The software assigns a DID number to a single station exclusively. If an incoming call is made to an unassigned DID number, it is directed to and handled by auto attendant. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Disabling SIP registration to the peer call serverThis feature is supported on SRX210 and SRX240 devices. The SRX Series MGW sends registration messages to the peer call server. For some network environments in which all media gateways are known to the peer call server, the SRX Series MGW is not required to register to it. To do so could cause complications. For example, the peer call server could drop the registration message silently, that is, without informing the SRX Series MGW. In this case, the SRX Series MGW might retransmit the message, incurring unnecessary processing and adding to the network load. When you configure peer call server information, you can disable transmission of the registration message to the peer call server to avoid these problems.
NOTE: Disabling transmission of the SRX Series MGW registration to the peer call server does not disable registration of an FXS station to the SRX Series MGW on the device running Integrated Convergence Services.
[JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
148
Disabling SIP registration to the proxy serverThis feature is supported on SRX210 and SRX240 devices. By default, Integrated Convergence Services SIP trunks register to the SIP service providers peer proxy server. For some SIP networks, the peer proxy server is informed about all SIP trunks that communicate with it. In such network environments, the SIP trunk does not need to send a REGISTER message to the peer proxy server. To do so would increase network load unnecessarily. To accommodate these network environments, you can configure the SIP trunk not to register to the peer proxy server. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
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 >
[JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
149
Hunt groupThis feature is supported on SRX210 and SRX240 devices. A hunt group enables a group of users to handle calls collectively. A hunt group specifies a logical extension that outside parties can call. Member stations belonging to the hunt group are specified in a preconfigured station group. When a call comes in on the logical extension, the call is directed to the phone whose station is specified first in the preconfigured station group, and that phone rings. The next incoming call is directed to the second station specified in the station group and its phone rings, and so on. To connect the call, the system hunts through the configured stations in order one at a time. It rings a phone up to the time limit that you specify before it tries the next phone in the configured order This feature is supported when the SRX Series SCS is in control. Under normal conditions when it is reachable, the peer call server provides this service if it is supported. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Pickup groupThis feature is supported on SRX210 and SRX240 devices. Pickup groups enable users to handle incoming calls collectively, as a group. Members of the same pickup group can answer incoming calls directed at any phone extension number within the group. When a phone is called, the first available agent takes the call, whether it comes in on their phone or another phone within the group. To pick up a call, the user dials the digits *8. After the user takes the call, the phone whose number was called no longer rings. Users can belong to one or more pickup groups concurrently. The pickup group feature rings only one phone at a time. If the first phone tried is busy, the next one is tried, and so on. A pickup group can include up to 20 members whose phones can be either analog or SIP, but not a mix of both. This feature is supported when the SRX Series survivable call server (SRX Series SCS) is in control. Under normal conditions when it is reachable, the peer call server provides this service if it is supported. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
Ring groupThis feature is supported on SRX210 and SRX240 devices. A ring group can include up to five members. A ring allows incoming calls to be handled by any member of the group. You configure a ring group with a logical extension that outside parties can call. Calls coming into the logical extension are forwarded to all phones simultaneously. The first member to answer the call takes it, and the phones of other members of the group stop ringing. A ring group can include both SIP and analog stations. This feature is supported when the SRX Series SCS is in control. Under normal conditions when it is reachable, the peer call server provides this service if it is supported. [JUNOS Software Integrated Convergence Services Configuration and Administration Guide]
150
Interfaces and Routing
DOCSIS firmware secure upgrade proceduresThis feature is supported on SRX210 and SRX240 devices. Upgrade Data over Cable System Interface Specifications (DOCSIS) ATP MAC-14 firmware on an SRX210 or SRX240 device using either the cable modem configuration file or SNMP. Choose one of the following procedures for upgrading:
Cable modem configuration file:

1.
Edit the following fields in the configuration file:

a. Change test.img to the name of the new signed firmware image file.
Software Upgrade Filename (9) = new-signed-firmware-image.img

b. Configure the IP address of your TFTP server.
Software upgrade TFTP Server (21) = n.n.n.n

2. Assign the configuration file to the cable modem. 3. Reboot or power-cycle the device. 4. Monitor the progress of the upgrade from the TFTP software server: a. Use the following command to display the software operation status:
SNMP GET docsDevSwOperStatus

b. Wait for resumption of operational status.
SNMP:
1.
Assign the configuration file to the cable modem.
2. Reboot or power-cycle the device. 3. When the device is operational, enter the following commands with the details
for your network:

SNMP SET docsDevSwFilename = new-signed-firmware-image.img SNMP SET docsDevSwServer = TFTP-server-IP-address SNMP SET docsDevSwAdminStatus = upgradeFromMgt(1)
4. Monitor the progress of the upgrade from the TFTP software server: a. Use the following command to display the software operation status:
SNMP GET docsDevSwOperStatus

b. Wait for resumption of operational status.
Link Aggregation Control ProtocolThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.
151
JUNOS Release 10.2 supports the Link Aggregation Control Protocol (LACP), which is a subcomponent of IEEE 802.3ad. LACP provides additional functionality for link aggregation groups (LAGs). For example, when LACP is not enabled, a local LAG might attempt to transmit packets to a remote single interface, which causes the communication to fail. When LACP is enabled, a local LAG cannot transmit packets unless a LAG with LACP is also configured on the remote end of the link. By default, aggregated and redundant Ethernet links do not exchange link aggregation control protocol data units (PDUs), which contain information about the state of the link. You can configure Ethernet links to actively transmit link aggregation control PDUs, or you can configure the links to passively transmit them, sending out link aggregation control PDUs only when they receive them from the remote end of the same link. The local end of a child link is known as the actor and the remote end of the link is known as the partner. That is, the actor sends link aggregation control PDUs to its protocol partner that convey what the actor knows about its own state and that of the partners state. LACP is supported in standalone deployments, where aggregated Ethernet interfaces are supported, and in chassis cluster deployments, where aggregated Ethernet interfaces and redundant Ethernet interfaces are supported simultaneously. Aggregated Ethernet interfaces can be Layer 3 interfaces (VLAN-tagged or untagged) and Layer 2 interfaces. LACP is supported on Layer 3 only. The LACP mode can be off (the default), active, or passive. LACP is enabled by setting the mode to either passive or active. If the actor and partner are both in passive mode, they do not exchange link aggregation control PDUs, which results in the aggregated Ethernet links not coming up. If either the actor or partner is active, they exchange link aggregation control PDUs. To initiate transmission of link aggregation control PDUs and response link aggregation control PDUs, you must enable LACP at both the local and remote ends of the links, and one end must be active. [JUNOS Software Interfaces Configuration Guide for Security Devices]
Layer 2 transparent mode active/active chassis clustersThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. Devices in Layer 2 transparent mode can now be deployed in active/active chassis cluster configurations, as well as active/backup configurations. Active/active chassis cluster configurations support multiple redundancy groups, meaning you are no longer restricted to the creation of only one redundancy group beyond redundancy group 0. Instead, you can configure one or more redundancy groups numbered 1 through 128. Multiple redundancy groups make it possible for traffic to arrive on an interface of one redundancy group and egress on an interface that belongs to another redundancy group. In this situation, the ingress and egress interfaces might not be active on the same node. When this happens, the traffic is forwarded over the fabric link to the appropriate node. Intrusion Detection and Prevention (IDP) is not supported in Layer 2 transparent mode active/active chassis clusters. (IDP is supported in Layer 2 transparent mode
152
active/backup chassis clusters). [JUNOS Software Layer 2 Bridging and Switching Configuration Guide for Security Devices]
Targeted broadcast of ingress IP packetsThis feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices. The IP-directed broadcast feature provides an optional method of sending broadcast packets to hosts on a specified subnet without broadcasting those packets to all hosts on the network. Directed broadcast can be used for implementing remote administration tasks, such as backups and wake-on LAN applications, or for automatic data transfers from providers. If JUNOS Software has a route for the next-hop gateway, broadcast packets are transited to other gateway routers along the path to the final destination. By default, broadcast packets are not sent to the subnet at the final egress port (where there is no next-hop gateway identified as a route), but are discarded after lookup. With targeted broadcast enabled, directed broadcast packets received on an ingress interface are automatically transited to an egress LAN interface and broadcast to the subnet. To enable targeted broadcast on a broadcast interface and send a copy of the packet to the Routing Engine, enter targeted-broadcast forward-and-send-to-re at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level. To broadcast to the egress interface only, enter targeted-broadcast forward-only. If targeted broadcast has been enabled, the show interfaces command output includes a targeted broadcast flag corresponding to the enabled option.
Intrusion Detection and Prevention (IDP)
Enhancements to application-level DDoS protectionThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. The ip-action command for application-level DDoS policies enables you to implicitly block a source address to protect the network from future intrusions while permitting legitimate traffic. With IP connection rate limiting, you can limit the number of connections per second for the matching ip-action target once the ip-action entry is installed on attack detection. To identify the thresholds for the application-level DDoS configuration, connection, context data, and rate statistics collection has also been added. With information collected from statistics reports, you can determine trends on connection rates and application requests destined for your protected servers. This data can then be used to configure server thresholds like connection, context and context value thresholds. The command to set application-ddos statistics is sensor-configuration application-ddos statistics.
NOTE: Statistic reports are saved on the Routing Engine hard disk at /var/log/addos.
153
Following are the main features of this enhancement:
Statistics collection of connection and context rates on a periodic basis (default is once every 1min) Application-level DDoS reporting Connection rate limiting for ip-action. The command to set connection rate limiting is ip-connection-rate-limit. Automatic file compression of statistical data files when file size reaches 10 MB.
[JUNOS Software CLI Reference,JUNOS Software Security Configuration Guide]
IDP inline tap modeThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. Intrusion Detection and Prevention (IDP) inline tap mode provides best case deep inspection analysis of traffic while maintaining overall device performance and stability. The inline tap feature provides passive, inline detection of Application Layer threats for traffic that matches security policies with the IDP application service enabled. When a device is in inline tap mode, packets pass through the firewall inspection process and are also copied to the independent IDP module. This allows the packets to get to the next service module without waiting for IDP processing results. In this way, the device sustains processing even when incoming traffic exceeds the IDP throughput limit (as long as other module limits, such as the firewall, are not exceeded). Since inline tap mode puts IDP in a passive mode for monitoring, preventive actions such as session close, drop, and mark diffserv are deferred. The action drop packet is ignored. Inline tap mode can only be configured if the forwarding process mode is set to maximize IDP sessions, which ensures stability and resiliency for firewall services. You also do not need a separate tap or span port to use inline tap mode.
NOTE: When switching to inline tap mode or back to regular mode, you must restart the device.
The command to enable inline tap mode is at the [security forwarding-process application-services maximize-idp-sessions] hierarchy. [JUNOS Software CLI Reference,JUNOS Software Security Configuration Guide]
IDP packet capture over DMIThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. The packet-capture feature in IDP lets you capture a specified number of packets that precede and follow an attack and transport them through Device Management Interface (DMI) to the host for further offline inspection. By analyzing the captured packets, you can better determine attack behavior, reduce false positive rule matches, and increase confidence in the detection ability of an IDP configuration. The notification section of an IDP policy rule configures specifications and limits for a packet capture, which will be triggered by a match of the rule criteria. Such specifications include the number of packets to be captured before and after an attack and a session-specific time limit for post-attack packet capturing.
154
A sensor configuration sets general specifications and limits for the capture, storage, and transmission of packets on a particular device. The sensor specification includes the memory allocation for caching and maximum supported sessions on the device for packet capture. The sensor configuration also defines the source and host device addresses for transmitting a packet log and its associated message log to the host.
NOTE: Packet capture is a powerful, but resource-intensive feature. We recommend that you configure a packet-capture policy to analyze traffic associated with a single event of particular interest.
Filter support for IDPThis feature is supported on all SRX Series devices. The IDP filter used to view the output of the show security flow session idp summary command has been changed; the new command is show security flow session summary idp. Filters can be used to view the output of the show security flow session summary idp command in summary mode. This command displays the following output:

Valid sessions Pending sessions Invalidated sessions Sessions in other states Total sessions
155
IPsec
Dynamic VPNThis feature is supported on SRX650 devices in addition to existing support on SRX210 and SRX240 devices. The dynamic VPN feature uses Internet Protocol Security (IPsec) technology to create secure VPN tunnels. This feature simplifies remote access by enabling users to establish VPN tunnels without having to manually configure VPN settings on their PCs or laptops. Instead, the client is dynamically delivered to users from the SRX210, SRX240, or SRX650 devices upon successful authentication. This Layer 3 remote access client uses client-side configuration settings that it receives from the server to create and manage a secure VPN tunnel to the server. [JUNOS Software Security Configuration Guide]
IPv6 Support
Address books and address setsAddress book entries can include any combination of IPv4 addresses, IPv6 addresses, and Domain Name System (DNS) names. To configure IPv6 address entries, specify an IPv6 address when you use the address statement at the [edit security zones security-zone name address-book] hierarchy level. The address set configuration takes names of address book entries, not IP addresses, so there are no additional considerations related to IPv6 traffic. [JUNOS Software Security Configuration Guide]
Administrative operationsWe have verified support for the following system services: ping, traceroute, and DNS lookup (client). Chassis clusterIn JUNOS Release 10.2, we support chassis cluster in an active-passive (failover) deployment. [JUNOS Software Security Configuration Guide] Class of serviceYou can use IPv6 DiffServ code points in class of service (Cos) classifier rules and re-write rules. Other CoS features are not IPv6-aware and so do not require special configuration related to IPv6. [JUNOS Software Class of Service Configuration Guide for Security Devices] Flow-based processingIPv6 flow support enables processing of IPv6 traffic by the SRX Series and J Series security features listed in this section. IPv6 flow support is disabled by default, and IPv6 packets are dropped. To enable flow-based processing for IPv6 traffic, modify the mode statement at the [edit security forwarding-options family inet6] hierarchy level. The [show security flow session source-prefix] and [show security flow session destination-prefix] commands you use to monitor session statistics now take IPv6 address arguments. In addition, we have added the [show security flow session family (inet|inet6)] option to filter session statistics by protocol family. [JUNOS Software CLI Reference, JUNOS Software Interfaces Configuration Guide for Security Devices, JUNOS Software Security Configuration Guide]
InterfacesA logical interface can be configured with an IPv4 address, IPv6 address, or both.
156
To configure an IPv6 address for a logical interface, use the inet6 statement at the [edit interfaces interface-name unit logical-unit family] hierarchy level. [JUNOS Software Interfaces Configuration Guide for Security Devices]
LoggingWe have verified support for sending syslog logs and SNMP traps over IPv6. The set security log commands you use to configure logging now take IPv6 address values. Also, note the following flow log messages pertain to IPv6 sessions:
RT_FLOW_IPVX_SESSION_DENYLog written when a packet is denied by policy (when the policy includes logging). RT_FLOW_IPVX_SESSION_CREATELog written when a packet matches a policy and a session is created (when the policy includes logging RT_FLOW_IPVX_SESSION_CLOSELog written when the previously created session is closed.
[Juniper Networks Enterprise-Specific MIBs, JUNOS Software Administration Guide for Security Devices, JUNOS System Log Messages Reference]
Routing protocolsWe have verified support for the following IPv6-related protocols: BFD, BGP, ICMPv6, neighbor discovery (ND), OSPFv3, and RIPng. [JUNOS Routing Protocols Configuration Guide, JUNOS Software Routing Protocols and Policies Configuration Guide for Security Devices] ScreensThere are no configuration considerations to use screens on IPv6 traffic. Note that the following screens are applicable only to IPv4 traffic: ip-bad-option, ip-record-route, ip-security-opt, ip-stream-opt, ip-strict-src-route, ip-timestamp-opt. [JUNOS Software Security Configuration Guide] Security policy (firewall)The matching criteria for security policy rules is based on zones, address objects, and applications. To support security policy rules for IPv6 traffic, you configure zone and address objects with IPv6 values. You can also select IPv6 applications. Note that in security policy rules, the meaning of the wildcard any has changed. When flow support is enabled for IPv6 traffic, the wildcard any matches any IPv4 or IPv6 address. In JUNOS Release 10.2, we introduce new wildcards to match any IPv4 or any IPv6 address: any-ipv4 and any-ipv6. When flow support is not enabled for IPv6 traffic, any matches IPv4 addresses. IPv6 support for IDP and UTM are not included in JUNOS Release 10.2. If your current security policy uses rules with any IP address wildcards and IDP and UTM features enabled, you will encounter configuration commit errors because IDP and UTM features do not yet support IPv6 addresses. To resolve the errors, modify the rule returning the error so that it uses the any-ipv4 wildcard; and create separate rules for IPv6 traffic that do not include IDP or UTM features. [JUNOS Software Security Configuration Guide]
Stateless firewall filtersYou can match IPv6 addreses in firewall filter rules. [JUNOS Software Routing Protocols and Policies Configuration Guide for Security Devices]
157
User authenticationWe have verified support for administrator access to an IPv6 interface using: Telnet, SSH, or HTTP. ZonesThe security zone configuration takes names of interfaces, not IP addresses, so there are no additional considerations related to the zone interface configuration. You also use the zone configuration to explictly permit inbound traffic from network system services and system protocols. Note that you can now use the host inbound traffic configuration to permit traffic from the following IPv6-related services and protocols: DHCPv6, neighbor discovery (ND) protocol, OSPF3, and RIPng. [JUNOS Software Security Configuration Guide]
Check for JUNOS Release 10.2 IPv6 limitations in the section Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 197.
J-Web
J-Web IDP configuration pages enhancementThis feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices. The following pages have been redesigned to enhance usability:

IDP Policies configuration page IDP Signature Update configuration page
An IDP Sensor configuration page has been added.
J-Web interface configuration page enhancementThis feature is supported on SRX210, SRX240, and SRX650 devices. The J-Web options configuration page now includes a tab for configuring T1/E1 options. To configure CT1 or CE1 interfaces, select Interface type as t1 or e1, respectively. If you change the t1 Interface type to e1, the CT1 configuration is deleted and a CE1 configuration is created and vice versa. The Interface configuration page now includes a new tab to configure encapsulation for logical interfaces. The supported encapsulations are:

Cisco HDLC Frame Relay PPP Multilink framerelay-unn-nni
Families supported are:

Inet Inet6 Mlppp
158
Mlfr-end to end Mlfr-uni-nni
[JUNOS Software Interfaces Configuration Guide for Security Devices]
J-Web pages for NG NAT configuration and monitoringThis feature is supported on all SRX Series and J Series devices. The following changes have been made to the J-Web pages for configuring NG NAT:
The pages have been redesigned and converted to the new EXTJS framework to improve usability. A Static NAT page and a Proxy ARP Configuration page have been added. A pop-up window with add and edit options has been added. Sorting by grid has been included.
The following changes have been made to the J-Web pages for monitoring NG NAT:
The pages have been redesigned and converted to the new EXTJS framework to improve usability. A bar chart has been added that displays the 10 top hits. Refresh Interval and Manual Refresh buttons have been added.
J-Web Pages for monitoring IPsec VPNThis feature is supported on all SRX Series and J Series devices. To improve their usability, the pages for IPsec VPN have been redesigned and converted to the new EXTJS framework.
J-Web pages for chassis clusterThis feature is supported on all SRX Series and J Series devices. The following additional configurations are available:

Control port (required) IP monitoring (optional)
To improve their usability, the following features have been redesigned and converted to the new EXTJS framework:

Configure system and interfaces information for individual nodes Configure information for chassis cluster and redundancy groups
Single commit on J-WebThis feature is supported on all SRX Series devices. In the J-Web user interface, you can now commit the complete J-Web configuration with a single commit action instead of committing configuration on each J-Web configuration page. This results in the following improvements:
Enhanced user experience
159
Faster J-Web configuration commitment
Management and Administration
Dual-root partitioningThis feature is supported on the SRX100, SRX210, SRX240, and SRX650 devices. JUNOS Release 10.0 and later releases support dual-root partitioning, which allows SRX Series devices to remain functional if there is file system corruption and facilitates easy recovery of the corrupted file system. SRX Series devices running JUNOS Release 9.6 and earlier releases support a single-root partitioning scheme. As 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 the file system against boot failure by keeping the primary and backup JUNOS Software images in two independent bootable root partitions. If the primary root partition gets corrupted, the system can boot from the backup JUNOS Software image located in another root partition, enabling the system to remain fully functional. SRX Series devices that ship with JUNOS Software Release 10.0 and later releases are formatted with dual-root partitions. The SRX Series devices that run JUNOS Release 9.6 or earlier releases can be formatted with dual-root partitions when you upgrade the system to JUNOS Release 10.0 and later releases.
NOTE: The dual-root partitioning feature allows SRX Series devices to remain functional if there is file system corruption and facilitates easy recovery of the corrupted file system. Although you can install JUNOS Release 10.0 and later on SRX100, SRX210, SRX240, and SRX650 devices with the single-root partitioning scheme, we strongly recommend the use of the dual-root partitioning scheme.
While upgrading the SRX Series devices to JUNOS Release 10.0 and later, you can choose to format the storage media with dual-root partitions (strongly recommended) or retain the existing single-root partitioning. [JUNOS Software Administration Guide for Security Devices]
Performance monitoringThis feature is supported on SRX100, SRX210, SRX240, and SRX650 devices. This feature introduces two new CLI commands for retrieving CPU performance details:
show security monitoring performance spuDisplays Services Processing Unit (SPU)
statistics for all FPC slots over the last 60 seconds.
show security monitoring performance sessionDisplays the number of sessions
added (ramp-up rate) for the last 60 seconds. [JUNOS Software CLI Reference Guide]
160
Network Address Translation (NAT)
NG NAT SNMP MIBThis feature is supported on SRX Series and J Series devices. The enterprise-specific NAT MIB includes support to the following features:
New source NATThese objects represent the source NAT attributes of the translated addresses. When performing source IP address translation, the security device translates the original source IP address, the port number, or both to a different address. The resource address source pool provides the security device with a supply of addresses from which to draw when performing source NAT. The new source NAT contains objects on source IP address translation only. NAT rule hitThis object monitors the NAT rule hits. NAT pool hitThis object monitors the NAT pool hits.
The new objects extend support to the port address translation (PAT) too. These objects allow users to monitor and debug the NAT functionality of the above mentioned devices.
Persistent NAT binding for wildcard portsThis feature is supported on all SRX Series devices. You can specify the address-mapping option with the persistent-nat configuration statement when creating a source NAT rule using persistent NAT. This option allows requests from a specific internal IP address to be mapped to the same external IP address; internal and external ports can be any ports. An external host using any port can send a packet to the internal host by way of the mapped transport address (with a configured incoming policy from external to internal). If this option is not configured, the persistent NAT binding is for specific internal and external IP addresses and ports. You can only specify the address-mapping option when the persistent NAT type is any remote host and the source NAT rule action is one of the following:

Source NAT pool with IP address shifting Source NAT pool with no port translation and no overflow pool [JUNOS Software Security Configuration Guide]
Point-to-Point Protocol over Ethernet (PPPoE)
LN1000 mobile secure routerThis feature is supported on SRX650, J2320, and J6350 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 device. 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
161
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. The credit interval parameter controls how frequently the device 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 devices that might 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
162
R2CP Radio-to-Router Protocol SupportThis feature is supported on all SRX Series and J Series devices. JUNOS Release 10.2 supports the Network Centric Waveform (NCW) radio-specific radio-to-router control protocol (R2CP), which is similar to the PPPoE radio-to-router protocol. Both protocols exchange dynamic metric changes in the network that the routers use to update the OSPF topologies. In radio-router topologies, the router connects to the radio over a Gigabit Ethernet link, and the radio transmits packets over the radio frequency (RF) link. The radio periodically sends metrics to the router, which uses RF link characteristics and other data to inform the router on the shaping and OSPF link capacity. The router uses this information to shape the data traffic and provide the OSPF link cost for its SPF calculations. The radio functions like a Layer 2 switch and can only identify remote radio-router pairs using Layer 2 MAC addresses. With R2CP, the router receives metrics for each neighboring router, identified by the MAC address of the remote router. The R2CP daemon translates the MAC addresses to link the local IPv6 addresses and sends the metrics for each neighbor to OSPF. Processing these metrics is similar to the handling of PPPoE PADQ metrics. Unlike PPPoE, which is a point-to-point link, these R2CP neighbors are treated as nodes in a broadcast LAN. You must configure each neighbor node with a per-unit scheduler for class-of-service. The scheduler context defines the attributes of JUNOS CoS. To define CoS for each radio, you can configure virtual channels to limit traffic. You need to configure virtual channels for as many remote radio-router pairs as there are in the network. You configure virtual channels on a logical interface. You can configure each virtual channel to have a set of eight queues with a scheduler and an optional shaper. When the radio initiates the session with a peer radio-router pair, a new session is created with the remote MAC address of the router and the VLAN over which the traffic flows. JUNOS Software chooses from the list of free virtual channels and assigns the remote MAC address and the eight CoS queues and the scheduler to the remote MAC address. All traffic destined to this remote MAC address is subjected to the CoS that is defined in the virtual channel. A virtual channel group is a collection of virtual channels. Each radio can have only one uniquely assigned virtual channel group. If you have more than one radio connected to the router, you must have one virtual channel group for each local radio-to-router pair. Although a virtual channel group is assigned to a logical interface, a virtual channel is not the same as a logical interface. The only features supported on a virtual channel are queuing, packet scheduling, and accounting. Rewrite rules and routing protocols apply to the entire logical interface.
163
Firewall filter scaling improvementThis feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices. Up to 400 logical input interfaces (in one broadcom packet processor) can be applied with simple filters. In earlier JUNOS Software releases, the number of logical interfaces was limited to 100.
Screens
Detection of TCP/UDP sweep attacksThis feature is supported on all SRX Series and J Series devices. SRX Series and J Series devices can identify and prevent TCP/UDP sweep attacks. By default, the SRX Series or J Series device allows 10 TCP or UDP packets from a single host to pass to multiple destinations within 5000 microseconds. If the number of TCP or UDP packets from a host exceeds this limit, the device logs this as a TCP or UDP sweep.
NOTE: The device drops further packets from this host only if the alarm-without-drop option is not enabled. If the alarm-without-drop option is enabled, the packets are allowed to pass.
Users can reconfigure the default threshold time period by using the following CLI commands:
set security screen idsoption screen-name tcp tcpsweep threshold threshold number set security screen idsoption screen-name udp udpsweep threshold threshold number
Security
Captive portalThis feature is supported on all SRX Series and J Series devices. In a Unified Access Control (UAC) deployment, users might not be aware that they must first sign into the Infranet Controller for authentication when accessing a protected resource behind the JUNOS Enforcer. To help users sign in to the Infranet Controller, you can now configure the captive portal feature. The captive portal feature allows you to configure a policy in the JUNOS Enforcer that automatically redirects HTTP traffic destined for protected resources to the Infranet Controller or to a URL configured on the JUNOS Enforcer. [JUNOS Software Security Configuration Guide]
Domain Name System Security Extensions (DNSSEC) supportThis feature is supported on all SRX Series and J Series devices. The DNSSEC feature is enabled by default. Users can disable the DNSSEC feature by using the CLI set system services dns dnssec disable command. The DNS-enabled devices run a DNS resolver (proxy) that listens on loopback address 127.0.0.1 or ::1. The DNS resolver does a hostname resolution for DNSSEC. Users need to set the server IP address to 127.0.0.1 or ::1 using the set system name-server [127.0.0.1|::1] command so that the DNS resolver forwards all the DNS queries to
164
DNSSEC instead of DNS. If this command is not set, DNS will handle all queries instead of DNSSEC. Users can configure secure domains and assign trusted keys to the domains by using CLI commands. Both signed and unsigned responses can be validated when DNSSEC is enabled.
SCTP stateful supportThis feature is supported on all SRX3400, SRX3600, SRX5600, and SRX5800 devices. Stream Control Transmission Protocol (SCTP) is an IP Transport Layer protocol. SCTP provides a reliable transport service that supports data transfer across the network, in single-IP or multi-IP cases. By configure SCTP profile, the security device can be enabled to perform stateful inspection on all SCTP traffic. The SCTP firewall supports deeper inspection too: packet filtering and limit-rate. [JUNOS Software Security Configuration Guide]
165
Virtual LANs (VLANs)
802.1X dynamic VLAN and MAC bypassThese features are supported on SRX210, SRX240, and SRX650 devices. SRX210, SRX240, and SRX650 devices provide for IEEE 802.1X authentication standards in an enterprise network to implement access control on Ethernet ports in switched mode. Supplicants (hosts) are authenticated when they are first connected to your LAN. By authenticating supplicants before they receive an IP address from a DHCP server, JUNOS Software prevents unauthorized supplicants from gaining access to your LAN. Compatible SRX Series devices can now provide the following IEEE 802.1X features on Ethernet ports configured in switched mode:
802.1X dynamic VLAN assignmentProvides dynamic VLAN assignment from the RADIUS server. 802.1X Guest VlanAllows configurable guest VLAN assignment if authentication fails or if host device does not have supplicant software on it. 802.1X media access control (MAC) bypassConfigures MAC and VLAN assignment on SRX Series devices. 802.1X configurable action at RADIUS timeoutDefines action to be taken in case of a RADIUS server failure or timeout (permit or deny authentication, use a cached value for authentication, or move the supplicant to another VLAN). 802.1X MAC RADIUS authenticationProvides MAC authentication through RADIUS with VLAN assignment option. RADIUS accountingThis feature is supported on SRX100, SRX210, SRX240, and SRX650 devices. This feature gathers statistical data for the RADIUS accounting server for general network monitoring, analyzing and tracking usage patterns, and user billing based on the time or services accessed. VoIP VLAN supportProvides dynamic VoIP VLAN assignment from the RADIUS server. Allows tagged and untagged traffic on an access port with a VLAN tag configured on a phone. SRX100 supports 802.1X MAC RADIUS authentication and 802.1X media access control (MAC) bypass without VLAN assignment option.
166
VPNs
Group VPNs and dynamic policy support for group VPNsThis feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices. A security association (SA) is a unidirectional agreement between VPN participants that defines the rules to use for authentication and encryption algorithms, key exchange mechanisms, and secure communications. With current VPN implementations, the SA is a point-to-point tunnel between two security devices. A group VPN extends IPsec architecture to support SAs that are shared by a group of security devices. Any-to-any connectivity is achieved by preserving the original source and destination IP addresses in the outer header. Secure multicast packets are replicated in the same way as clear-text multicast packets in the core network. With group VPNs, a group server manages keys and SA proposals for members of the group. Between group members that share a key, any unicast or multicast traffic that satisfies the SA proposals can be protected by the key. The group server and group members are linked by a group ID, which can be a number between 1 and 65,535. To join a group, a device must provide correct Phase 1 IKE authentication. In a group VPN, each key that the group server pushes to a group member is associated with an SA proposal. The SA proposal includes protocol, source address, source port, destination address, destination port, and security attributes, such as authentication method and encryption algorithm. On the group member, a group scope policy must be configured that defines the scope of the SA proposal managed by the group server. An SA proposal distributed from the group server is compared against the scope policy on the group member. Any addresses specified in the proposal must be within the range of addresses specified in the scope policy. An SA proposal installed on a group member in this way is called a dynamic policy. To configure the group server, use the group-vpn server statement options at the [edit security] hierarchy. To configure group members, use the group-vpn member statement options at the [edit security] hierarchy. Configure a scope policy on a group member using the policies configuration statement at the [edit security] hierarchy. Use the ipsec-group-vpn configuration statement in the permit tunnel rule to reference the group VPN configured on the member device; this allows multiple dynamic policies for the same VPN to share a single SA. [JUNOS Software Security Configuration Guide]
Dynamic VPN access through the Junos Pulse clientThis feature is supported on SRX100, SRX210, SRX220, SRX240, and SRX650 devices. Junos Pulse enables secure authenticated network connections to protected resources and services over LANs and WANs. Junos Pulses is a remote access client developed to replace the earlier access client called Juniper Networks Access Manager. You must uninstall Access Manager before you install the Junos Pulse client. Junos Pulse supports remote virtual private network tunnel connectivity to SRX Series Services Gateways that are running Junos OS. To configure a firewall access environment for Junos Pulse clients, you must configure the VPN settings on the SRX Series device and create and deploy a firewall connection on the Junos Pulse client.
167
For SRX Series devices running Junos OS Releases 10.2 through 10.4, Junos Pulse is supported but must be deployed separately. In Junos OS Release 11.1 and later releases, if the Pulse client does not exist on the client machine, the Pulse client is automatically downloaded and installed when you log in to an SRX Series device. If the Pulse client exists on the client machine, you must launch the Pulse client. [JUNOS Software Security Configuration Guide]
Hardware FeaturesSRX210 Services Gateways
Support for 3G wireless functionality on SRX210 Services GatewaysJUNOS Software Release 10.2 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 a 3G ExpressCard slot on the back panel. The SRX210 device supports the Juniper Networks wireless modems listed in Table 9 on page 168.
Table 9: Juniper Networks Wireless Modems Supported by the SRX210 Device

Wireless Cards
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 880E/881E supporting Global System for Mobile Communications (GSM) High-Speed Packet Access (HSPA) ExpressCard. Not available from Juniper Networks. Sierra Wireless AirCard AC501/AC502 supporting Global System for Mobile Communications (GSM) High-Speed Packet Access (HSUPA). Not available from Juniper Networks.
Release Supported
JUNOS Software Releases 9.6, 10.0, 10.1, and 10.2.
JUNOS Software Releases 9.6, 10.0, 10.1, and 10.2.
JUNOS Software Releases 9.5, and 9.6.
JUNOS Software Releases 10.1, and 10.2.

SRX240 Services Gateway High Memory DC Power Supply Model This release introduces the SRX240 Services Gateway High Memory with DC Power Supply model (SRX240DC), which includes an internal, fixed DC power supply. The DC power supply feed available on the back panel of the chassis has dual redundant power feeds that provide full power redundancy in the device.
168
Table 10 on page 169 lists the SRX240 Services Gateway High Memory with DC Power Supply model specifications.
Table 10: SRX240 Services Gateway High Memory with DC Power Supply Specifications
Specification
Chassis height Chassis width Chassis depth Chassis weight Altitude
Value
1 Unit (U) 17.5 in. (44.5 cm) 15 in. (38.1 cm) 12.56 lb. (5.7 kg) No performance degradation to 10,000 ft (3048 m) 5% to 90%, noncondensing Normal operation ensured in temperature range of 32F (0C) to 104F (40C) Nonoperating storage temperature in shipping container: 40F (40C) to 158F (70C)
Relative humidity Temperature
Seismic
Designed to meet Telcordia Technologies Zone 4 earthquake requirements 409 BTU/hour (DC power) Note: The specification is an estimate and subject to change.
Maximum thermal output
Noise level
Less than 70 dB(A) as per EN ISO 7779
Table 11 on page 169 lists the SRX240 Services Gateway High Memory with DC Power Supply model hardware features.
Table 11: SRX240 Services Gateway High Memory with DC Power Supply Hardware Features
Feature
DDR memory Power supply rating Input voltage
Description
1 GB 190 watts 48 VDC Operating range: -40.5 V to -72 V
169
Table 11: SRX240 Services Gateway High Memory with DC Power Supply Hardware Features (continued)
Feature
Average Power consumption Gigabit Ethernet ports Console port Universal Serial Bus (USB) ports Mini-PIM slots Internal flash Fans Air filter NEBS-compliant*
Description
72 watts 16 1 2 4 1 GB 6 1 Yes
JUNOS Release 10.2 or later supports NEBS-compliant devices (SRX240 Services Gateway High Memory with AC Power Supply and SRX240 Services Gateway High Memory with DC Power Supply). These NEBS-compliant devices are available from Juniper Networks starting June 30, 2010. Contact your Juniper Networks customer service representative for more information. Air Filters on the SRX240 Services Gateway High Memory The following Network Equipment Building System (NEBS)-compliant SRX Series models employ an air filter to protect the device from dust entering into the system:

SRX240 Services Gateway High Memory with AC Power Supply SRX240 Services Gateway High Memory with DC Power Supply
NOTE: An air filter is not shipped with the SRX240 Services Gateway High Memory with AC Power Supply model. To meet NEBS requirements, you must order the air filter separately. Contact your Juniper Networks customer service representative for more information.
170
NOTE: JUNOS Release 10.2 or later supports NEBS-compliant devices (SRX240 Services Gateway High Memory with AC Power Supply and SRX240 Services Gateway High Memory with DC Power Supply). These NEBS-compliant devices are available from Juniper Networks starting June 30, 2010. Contact your Juniper Networks customer service representative for more information.
The air filter available on the SRX240 Services Gateway High Memory with AC Power Supply model and the SRX240 Services Gateway with DC Power Supply model is hot-insertable and hot-removable. The air intake opening is at the right side of the chassis (when the chassis is viewed from the front side). The air filter weighs approximately 0.2 lbs (0.09 kg).
NOTE: The air filter must be replaced periodically.
Hardware FeaturesSRX210 and SRX240 Services Gateways with Integrated Convergence Services
4-Port FXS Mini-Physical Interface Module The 4-Port Foreign Exchange Subscribers (FXS) Mini-Physical Interface Module (Mini-PIM) provides an interface for connecting telephones, fax machines, and other telephony devices to the SRX Series device. This Mini-PIM is supported on the following devices:

SRX210 Services Gateway with Integrated Convergence Services SRX240 Services Gateway with Integrated Convergence Services
The 4-Port FXS Mini-PIM uses a standard RJ-11 cable.
NOTE: The 4-Port FXS Mini-PIM can be used only with integrated convergence services models of SRX210 and SRX240 Services Gateways and not in standalone mode.
Key Features The following are the key features of the 4-Port FXS Mini-PIM:

Highly programmable and globally compliant FXS interface International safety standard compliant Caller ID support FXS trunking
For more information on the 4-Port FXS Mini-PIM, see the SRX Series Services Gateways for the Branch Physical Interface Modules Hardware Guide.
171
For information on configuring the 4-Port FXS Mini-PIM, see the JUNOS Software Integrated Convergence Services Configuration and Administration Guide for SRX210 and SRX240 Services Gateways.
2-Port 10-Gigabit Ethernet XPIMThe 2-Port 10-Gigabit Ethernet XPIM is supported on SRX650 devices. The 2-Port 10-Gigabit Ethernet XPIM provides a connection to high-speed Ethernet networks through branch WAN service and allows carriers to provide multiple levels of Ethernet service with a single connection option for all service ranges. The 2-Port 10-Gigabit Ethernet XPIM is a single-slot XPIM that can be installed only in the 20-gigabit GPIM slots (slot 2 or 6) on the front panel of the SRX650 Services Gateway. The 2-Port 10-Gigabit Ethernet XPIM contains two 10-Gigabit Ethernet interfaces with both copper and small form-factor pluggable transceiver (SFP) terminations, to support redundancy and enable the SRX650 Services Gateway to be used as a pure security service device. The following key features are supported on the 2-Port 10-Gigabit Ethernet XPIM:

Online Insertion and Removal (OIR) capable. Contains a total of four ports (two SFP+ and two 10GBASE-T). Only two of the four ports can be active at any time; mix and match between the copper and fiber types is supported. Receives SFP+ optics, and, at a minimum, supports these SFP+ transceivers:

SFPP-10GE-SR SFPP-10GE-LR SFPP-10GE-ER SFPP-10GE-LRM Copper Twin-AX 1m Copper Twin-AX 3m
Anti-counterfeit capabilities. EEE feature on copper mode to reduce power consumption. Quad speed support for copper mode: 10GBASE-T IEEE 820.3an, 1000BASE-T IEEE 802.3ab, 100BASE-T IEEE 802.3u, and 10BASE-T IEEE 802.3. Standard quality-of-service (QoS) features. User-configuration of fiber and copper ports:
When the interface is configured as a copper port, a typical Ethernet configuration such as Autoneg is supported. Forced rate and link mode are allowed. Four forced and Autoneg rates are provided: 10 gigabits, 1 gigabit, 100 Mbps, and 10 Mbps.
172
Advertising Bandwidth for Neighbors on a Broadcast Link Support
When the interface is configured as a fiber port, typical configurations similar to 1-Gbps fiber (SFP) ports in the 24-port Gigabit Ethernet XPIM are supported.
Diagnostics for debugging and problem isolation. SNMP support. J-Web support.
[JUNOS Software Interfaces Configuration Guide for Security Devices, SRX650 Services Gateway Hardware Guide]
Hardware FeaturesSRX3400 and SRX3600 Services Gateways

SRX Clustering Module for SRX3400 and SRX3600 Services Gateways The SRX Clustering Module (SCM) is a card that you can install in an SRX3400 or SRX3600 Services Gateway to enable the dual control link feature for chassis clustering supported in JUNOS Release 10.2. You install the SCM in the RE1 slot on the rear panel of the services gateway. Related Documentation

Unsupported CLI Statements and Commands on page 188 Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 197 Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211 Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 239
Advertising Bandwidth for Neighbors on a Broadcast Link Support

This feature is supported on all SRX Series and J Series devices. You can now advertise bandwidth for neighbors on a broadcast link. The network link is a point-to-multipoint (P2MP) link in the OSPFv3 link state database. This feature uses existing OSPF neighbor discovery to provide automatic discovery without configuration. It allows each node to advertise a different metric to every other node in the network to accurately represent the cost of communication. To support this feature, a new interface-type under the OSPFv3 interface configuration has been added to configure the interface as p2mp-over-lan. OSPFv3 then uses LAN procedures for neighbor discovery and flooding, but represents the interface as P2MP in the link state database. The interface type and router LSA are available under the following hierarchies:

[protocols ospf3 area area-id interface interface-name] [routing-instances routing-instances-name protocols ospf3 area area-id interface interface-name]
[LN1000 Mobile Secure Router User Guide]
173
Group VPN Interoperability with Ciscos GET VPN

Ciscos implementation of GDOI is called Group Encryption Transport (GET) VPN. While group VPN in JUNOS Software and Cisco's GET VPN are both based on RFC 3547, The Group Domain of Interpretation, there are some implementation differences that you need to be aware of when deploying GDOI in a networking environment that includes both Juniper Networks security devices and Cisco routers. This topic discusses important items to note when using Cisco routers with GET VPN and Juniper Networks security devices with group VPN. Cisco GET VPN members and Juniper Group VPN members can interoperate as long as the server role is played by a Cisco GET VPN server, Juniper Networks security devices are group members, and with the following caveats: The group VPN in Release 10.2 of JUNOS Software has been tested with Cisco GET VPN servers running Version 12.4(22)T and Version 12.4(24)T. To avoid traffic disruption, do not enable rekey on a Cisco server when the VPN group includes a Juniper Networks security device. The Cisco GET VPN server implements a proprietary ACK for unicast rekey messages. If a group member does not respond to the unicast rekey messages, the group member is removed from the group and is not able to receive rekeys. An out-of-date key causes the remote peer to treat IPsec packets as bad SPIs. The Juniper Networks security device can recover from this situation by reregistering with the server to download the new key. Antireplay must be disabled on the Cisco server when a VPN group of more than two members includes a Juniper security device. The Cisco server supports time-based antireplay by default. A Juniper Networks security device will not be able to interoperate with a Cisco group member if time-based antireplay is used since the timestamp in the IPsec packet is proprietary. Juniper Networks security devices are not able to synchronize time with the Cisco GET VPN server and Cisco GET VPN members as the sync payload is also proprietary. Counter-based antireplay can be enabled if there are only two group members. According to Cisco documentation, the Cisco GET VPN server triggers rekeys 90 seconds before a key expires and the Cisco GET VPN member triggers rekeys 60 seconds before a key expires. When interacting with a Cisco GET VPN server, a Juniper Networks security device member would match Cisco behavior. A Cisco GET VPN member accepts all keys downloaded from the GET VPN server. Policies associated with the keys are dynamically installed. A policy does not have to be configured on a Cisco GET VPN member locally, but a deny policy can optionally be configured to prevent certain traffic from passing through the security policies set by the server. For example, the server can set a policy to have traffic between subnet A and subnet B be encrypted by key 1. The member can set a deny policy to allow OSPF traffic between subnet A and subnet B not be encrypted by key 1. However, the member cannot set a permit policy to allow more traffic to be protected by the key. The centralized security policy configuration does not apply to the Juniper Networks security device.
174
Changes in Default Behavior and Syntax in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
On a Juniper Networks security device, the ipsec-group-vpn configuration statement in the permit tunnel rule in a scope policy references the group VPN. This allows multiple policies referencing a VPN to share an SA. This configuration is required to interoperate with Cisco GET VPN servers. Logical key hierarchy (LKH), a method for adding and removing group members, is not supported with group VPN on Juniper Networks security devices. GET VPN members can be configured for cooperative key servers (COOP KSs), an ordered list of servers with which the member can register or reregister. Multiple group servers cannot be configured on group VPN members.
The following current system behavior, configuration statement usage, and operational mode command usage might not yet be documented in the JUNOS Software documentation.
Application Identification
The following options have been added to the request services application-identification uninstall command to uninstall the predefined application definition package, all custom application definitions, or both at one time. This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.
allUninstall from your configuration both the predefined application definition package
and all custom application definitions that you have created.

customer-definedUninstall from your configuration all custom application definitions
that you have created, but maintain the predefined application definition package.
predefined(Default) Uninstall from your configuration the predefined application
definition package, but maintain all custom application definitions that you have created.
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
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>.
175
AppSecure
When creating custom application or nested application signatures for JUNOS Software application identification, the order value must be unique among all predefined and custom application signatures. The order value determines the application matching priority of the application signature.
NOTE: The order value range for predefined signatures is 1 through 32,767. We recommend that you use an order range higher than 32,767 for custom signatures.
The order value is set with the set services application-identification application application-name signature order command. You can also view all signature order values by entering the show services application-identification | display set | match order command. You will need to change the order number of the custom signature if it conflicts with another application signature.
The output of the show services application-identification application-system-cache command has been changed. The new output includes the cache statuses and the timeout value for maintaining mapping details for each application as shown in the following sample:
user@host> show services application-identification application-system-cache Application System Cache Configurations: application-cache: on nested-application-cache: on cache-entry-timeout: 3600 seconds pic: 2/0 Vsys-ID IP address Port Protocol 0 5.0.0.1 80 TCP 0 7.0.0.1 80 TCP
Application HTTP HTTP:FACEBOOK
Chassis Cluster
In a chassis cluster configuration on an SRX100, SRX210, SRX240, or SRX650 device, the default values of the heartbeat-threshold and heartbeat-interval options in the [edit chassis cluster] hierarchy are 8 beats and 2000 ms respectively. These values cannot be changed on these devices. Removing Control VLAN 4094 in Chassis ClusterFor SRX Series branch devices (SRX100, SRX210, SRX240, and SRX650), the existing virtual LAN (VLAN) tag used for control-link traffic will be replaced with the use of experimental Ether type 0x88b5. However, backward compatibility is also supported for devices that have already deployed chassis cluster with VLAN tagging in place.
To toggle between VLAN and Ether type modes, use the following command:
set chassis cluster control-link-vlan enable/disable
176
NOTE: You must perform a reboot to initialize this configuration change.
To show whether control port tagging is enabled or disabled, and to view the chassis cluster information, use the following command:
show chassis cluster information
user@host > show chassis cluster information
Control tagging will be disabled whenever you execute set chassis cluster cluster-id 5 node 0 or 1 command The following is sample output of the command:
node0 ----------------------------------------------------Control link statistics: Control link 0: Fabric link statistics: Probes sent: 1248 Sequence number of last probe received: 0 Chassis cluster LED information: Current LED color: Green Control port tagging: Disabled Cold Synchronization:
For users deploying chassis cluster for the first time: VLAN tagging will be disabled by default. If you want to use VLAN 4094, use the following command:
set chassis cluster control-link-vlan enable
SRX Series devices support FPC configuration in chassis cluster mode. In this mode, all FPC-related configuration is performed under the edit chassis node node-id fpc hierarchy. In non-cluster mode, FPC configuration remains under the edit chassis fpc hierarchy. For users with existing chassis cluster configurations: If you upgrade to newer releases, VLAN restriction remains enabled to make it backward compatible. If you do not want to use VLAN, use the following command:
set chassis cluster control-link-vlan disable
NOTE: You must perform a reboot to initialize this configuration change.
Table 12 on page 178 shows the action that existing users need to take if they want to upgrade to newer releases.
177
Table 12: Action For Existing Users

Existing Scenario
Deployed in chassis cluster
Action To Be Taken If VLAN Mode Is Required

No action is required.
Action To Be Taken If VLAN Mode Is Not Required

Use the following command:
set chassis cluster control-link-vlan disable reboot
Not deployed in chassis cluster
Use the following commands:
No action is required.
set chassis cluster cluster-id node ... set chassis cluster control-link-vlan enable reboot
Command-Line Interface (CLI)
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
178
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 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? have changed from previous implementations. Now this CLI command displays the following possible completions:
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
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)
179
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)

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)

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
The feature enhancement command download status is added to the request services application-identifications to check the download status of the application identification signature package. The download status is provided as shown in the following sample output: user@host>request services application-identifications download status Application package 1608 installation is in progress. Application package 1608 installed successfully.
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.
180
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 onboard 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).
The default values for IKE and IPsec security association (SA) lifetimes for standard VPNs have been changed in JUNOS Release 10.2:
The default value for the lifetime-seconds configuration statement at the [edit security ike proposal proposal-name] hierarchy level has been changed from 3600 seconds to 28,800 seconds. The default value for the lifetime-seconds configuration statement at the [edit security ipsec proposal proposal-name] hierarchy level has been changed from 28,800 seconds to 3600 seconds.
Dynamic VPN
Working with Pulse Client Junos Pulse enables secure authenticated network connections to protected resources and services over LANs and WANs. Junos Pulses is a remote access client developed to replace Access Manager, the earlier access client called Juniper Networks Access Manager. You must uninstall Access Manager before you install the Junos Pulse client. For SRX100, SRX210, SRX220, SRX240, and SRX650 devices running Junos OS Release 10.2 and later, Junos Pulse is supported but must be deployed separately. Users can download and install the pulse client manually from Juniper support site. From Junos OS Release 11.1 and later, if the Pulse client does not exist on the client machine, the Pulse client is automatically downloadable and installable when you connect into a Branch SRX Series device. If the Pulse client exists on the client machine, you must launch the Pulse client.
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:
181
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.2 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.2, then

Add interleave-fragments under [ls-0/0/0 unit 0] Adjust classifier configured for LFI on lsq-0/0/0 under [class-of-service] to classify packets to Q2
If the aforementioned instructions are not followed, the bundle will be incorrectly processed.
On SRX Series devices, as per the new behavior, on configuring identical IPs on a single interface we would no longer be getting a warning message, instead a syslog message will be created. On SRX210 Low Memory devices, ICMP messages generated in flow mode are now rate-limited to 20 messages every 10 seconds. This rate limit is calculated on a per-CPU basis.
On T1/E1 Mini-Physical Interface Module installed on SRX210 and SRX240 devices, the Loopback LED is turned ON based on the Loopback configuration as well as when the FDL loopback commands are executed from the remote-end. The Loopback LED remains OFF when no FDL Loopback commands are executed from the remote-end, even though remote-loopback-respond is configured on the HOST.
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.
182
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 SRX3000 and SRX5000 line devices, the maximum number of traffic-shaping simple filter rules and policing rules has been changed. For SRX3000 line devices, the number of simple filter and policing rules is 2000 per I/O card (IOC) for each rule type. For SRX5000 line devices, the number of simple filter and policing rules is 2000 for each rule type per PIM on flex I/O cards (FIOCs). This change does not affect ordinary IOCs on SRX5000 line devices. The previous maximum of 4000 for each rule type is not achievable because of a hardware limitation. On SRX100, SRX210, SRX240, and SRX650 devices, L3 LAG support is available in standalone mode and not supported in chassis cluster limitation. On J4350 devices, the ping operation is not successful even if the ISDN call is connected and the dialer watch is configured. This issue occurs only when media MTU value on Cisco devices is larger than the MTU value configured on J Series devices. As a workaround, configure the MTU value on J Series devices to be equal to or larger than the value set for Cisco devices. On SRX and J Series devices, the help description for the set <int> interface arp-resp command incorrectly state the default value is 'unrestricted'. The default is actually 'restricted'.
On SRX3400 devices, FTP traffic is not going through expedited-forwarding queue class for FTP control connections. All other traffic like http, telnet and ping go through the expedited-forwarding queue class as expected. On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the application identification CLI commands have been moved from the [security idp sensor-configuration application-identification] hierarchy to the [edit services application-identification] hierarchy. For details about this change, see the section AppSecure on page 138. 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.
183
J-Web

The J-Web login page has been updated with the new Juniper Logo and Trademark. URL Separation for J-Web and Dynamic VPNThis feature prevents the dynamic VPN users from accessing J-Web accidentally or intentionally. Unique URLs for J-Web and dynamic VPN add support to the webserver for parsing all the HTTP requests it receives. The webserver also provides access permission based on the interfaces enabled for J-Web and dynamic VPN.
CLI changes: A new configuration attribute management-url is introduced at the [edit system services web-management] hierarchy level to control J-Web access when both J-Web and dynamic VPN are enabled on the same interface. The following example describes the configuration of the new attribute:
web-management { traceoptions { level all; flag dynamic-vpn; flag all; } management-url my-jweb; http; https { system-generated-certificate; } limits { debug-level 9; } session { session-limit 7; } }
Disabling J-Web: Dynamic VPN must have the configured HTTPS certificate and the webserver to communicate with the client. Therefore, the configuration at the [edit system services web-management] hierarchy level required to start the appweb webserver cannot be deleted or deactivated. To disable J-Web, the administrator must configure a loopback interface of lo0 for HTTP or HTTPS. This ensures that the webserver rejects all J-Web access requests.
web-management { traceoptions { level all; flag dynamic-vpn; flag all; } management-url my-jweb; http { interface lo0.0; } https { system-generated-certificate; } limits {
184
debug-level 9; } session { session-limit 7; } }
Changes in the web access behavior The following cases show the changes in the web access behavior when J-Web and dynamic VPN do not share and do share the same interface. Case 1: J-Web and dynamic VPN do not share the same interface.
Scenario
http(s)://server host
http(s)://server host//configured attribute

Navigates to the J-Web login page if the attribute is configured, else to the Page Not Found page
http(s)://server host//dynamic-vpn
Navigates to the dynamic VPN login page
J-Web is enabled, and dynamic VPN is configured.
Navigates to the J-Web login page on the J-Web enabled interface or to the dynamic VPN login page on the dynamic VPN enabled interface depending on the server host chosen. Navigates to the Page Not Found page
J-Web is not enabled, and dynamic VPN is not configured. J-Web is enabled, and dynamic VPN is not configured.
Navigates to the Page Not Found page
Navigates to the J-Web login page
Navigates to the J-Web login page if the J-Web attribute is configured, else to the to the Page Not Found page Navigates to the Page Not Found page
Navigates to the Page Not Found page.
J-Web is not enabled, and dynamic VPN is configured.
Case 2: J-Web and dynamic VPN do share the same interface.

Scenario
http(s)://server host
http(s)://server host//configured attribute

Navigates to the J-Web login page if the attribute is configured, or to the Page Not Found page Navigates to the Page Not Found page
http(s)://server host//dynamic-vpn
J-Web is enabled, and dynamic VPN is configured.
J-Web is not enabled, and dynamic VPN is not configured. J-Web is enabled, and dynamic VPN is not configured. J-Web is not enabled, and dynamic VPN is configured.
Navigates to the J-Web login page
Navigates to the J-Web login page if the J-Web attribute is configured, else to the Page Not Found page Navigates to the Page Not Found page
Navigates to the Page Not Found page.
185
On SRX Series devices, the BIOS version is displayed on system identification on the J-Web dashboard.
NOTE: Delete your browser cookies to view these changes.
The options to configure the Custom Attacks, Custom Attack Groups, and Dynamic Attack Groups are disabled because they cannot be configured from 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.
186
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.
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.2, 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.
Multilink
On SRX and J Series devices, to avoid Out-of-range sequence number drop on reassembly side, changes are made to send all ML data traffic on queue 0 of member link and LFI traffic on queue 2 of member link. When LFI is configured, the following configuration is recommended for member links: /* Configure the following schedulers */
set class-of-service schedulers S0 buffer-size temporal 20k set class-of-service schedulers S0 priority low set class-of-service schedulers S2 priority high set class-of-service schedulers S3 priority high
/* Configure the following scheduler map */

set class-of-service scheduler-maps lsqlink_map forwarding-class best-effort scheduler S0 set class-of-service scheduler-maps lsqlink_map forwarding-class assured-forwarding scheduler S2 set class-of-service scheduler-maps lsqlink_map forwarding-class network-control scheduler S3
/* Attach scheduler map to all member links */

set class-of-service interfaces t1-2/0/0 unit 0 scheduler-map lsqlink_map
After this configuration, if Out-of-range sequence number drops are still observed, increase drop-timeout of the bundle to 200ms.
187
WLAN
While configuring the AX411 Access Point on your SRX Series devices, you must enter the WLAN admin password using the set wlan admin-authentication password command. This command prompts for the password and the password entered is stored in encrypted form.
NOTE: Without wlan config option enabled, the AX411 Access Points will be managed with the default password.
Changing the wlan admin-authentication password when the wlan subsystem option is disabled might result in mismanagement of Access Points . You might have to power cycle the Access Points manually to avoid this issue. The SRX Series devices that are not using the AX411 Access Point can optionally delete the wlan config option.
Accessing the AX411 Access Point through SSH is disabled by default. You can enable the SSH access using the set wlan access-point <name> external system services enable-ssh command.
Unsupported CLI Statements and Commands

This section lists unsupported CLI statements and commands.
Accounting-Options Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the accounting, source-class, and destination-class statements in the [accounting-options] hierarchy level are not supported.
AX411 Access Point Hierarchy
On SRX100 devices, there are CLI commands 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 Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following chassis hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set chassis craft-lockout set chassis routing-engine on-disk-failure
188
Class-of-Service Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following class-of-service hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set class-of-service classifiers ieee-802.1ad set class-of-service interfaces interface-name unit 0 adaptive-shaper
Ethernet-Switching Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following ethernet-switching hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set ethernet-switching-options bpdu-block disable-timeout set ethernet-switching-options bpdu-block interface set ethernet-switching-options mac-notification set ethernet-switching-options voip interface access-ports set ethernet-switching-options voip interface ge-0/0/0.0 forwarding-class
Firewall Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following Firewall hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set firewall family vpls filter set firewall family mpls dialer-filter d1 term
Interfaces CLI Hierarchy

On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following interface hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.

Aggregated Interface CLI on page 190 ATM Interface CLI on page 190 Ethernet Interfaces on page 191 GRE Interface CLI on page 191 IP Interface CLI on page 192
189
LSQ Interface CLI on page 192 PT Interface CLI on page 192 T1 Interface CLI on page 192 VLAN Interface CLI on page 193
Aggregated Interface CLI
The following CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
request lacp link-switchover ae0 set interfaces ae0 aggregated-ether-options lacp link-protection set interfaces ae0 aggregated-ether-options link-protection
ATM Interface CLI
set interfaces at-1/0/0 container-options set interfaces at-1/0/0 atm-options ilmi set interfaces at-1/0/0 atm-options linear-red-profiles set interfaces at-1/0/0 atm-options no-payload-scrambler set interfaces at-1/0/0 atm-options payload-scrambler set interfaces at-1/0/0 atm-options plp-to-clp set interfaces at-1/0/0 atm-options scheduler-maps set interfaces at-1/0/0 unit 0 atm-l2circuit-mode set interfaces at-1/0/0 unit 0 atm-scheduler-map set interfaces at-1/0/0 unit 0 cell-bundle-size set interfaces at-1/0/0 unit 0 compression-device set interfaces at-1/0/0 unit 0 epd-threshold set interfaces at-1/0/0 unit 0 inverse-arp set interfaces at-1/0/0 unit 0 layer2-policer set interfaces at-1/0/0 unit 0 multicast-vci
190
set interfaces at-1/0/0 unit 0 multipoint set interfaces at-1/0/0 unit 0 plp-to-clp set interfaces at-1/0/0 unit 0 point-to-point set interfaces at-1/0/0 unit 0 radio-router set interfaces at-1/0/0 unit 0 transmit-weight set interfaces at-1/0/0 unit 0 trunk-bandwidth
Ethernet Interfaces
set interfaces ge-0/0/1 gigether-options ignore-l3-incompletes set interfaces ge-0/0/1 gigether-options mpls set interfaces ge-0/0/0 stacked-vlan-tagging set interfaces ge-0/0/0 native-vlan-id set interfaces ge-0/0/0 radio-router set interfaces ge-0/0/0 unit 0 interface-shared-with set interfaces ge-0/0/0 unit 0 input-vlan-map set interfaces ge-0/0/0 unit 0 output-vlan-map set interfaces ge-0/0/0 unit 0 layer2-policer set interfaces ge-0/0/0 unit 0 accept-source-mac set interfaces fe-0/0/2 fastether-options source-address-filter set interfaces fe-0/0/2 fastether-options source-filtering set interfaces ge-0/0/1 passive-monitor-mode
GRE Interface CLI
set interfaces gr-0/0/0 unit 0 ppp-options set interfaces gr-0/0/0 unit 0 layer2-policer
191
IP Interface CLI
set interfaces ip-0/0/0 unit 0 layer2-policer set interfaces ip-0/0/0 unit 0 ppp-options set interfaces ip-0/0/0 unit 0 radio-router
LSQ Interface CLI
set interfaces lsq-0/0/0 unit 0 layer2-policer set interfaces lsq-0/0/0 unit 0 family ccc set interfaces lsq-0/0/0 unit 0 family tcc set interfaces lsq-0/0/0 unit 0 family vpls set interfaces lsq-0/0/0 unit 0 multipoint set interfaces lsq-0/0/0 unit 0 point-to-point set interfaces lsq-0/0/0 unit 0 radio-router
PT Interface CLI
set interfaces pt-1/0/0 gratuitous-arp-reply set interfaces pt-1/0/0 link-mode set interfaces pt-1/0/0 no-gratuitous-arp-reply set interfaces pt-1/0/0 no-gratuitous-arp-request set interfaces pt-1/0/0 vlan-tagging set interfaces pt-1/0/0 unit 0 radio-router set interfaces pt-1/0/0 unit 0 vlan-id
T1 Interface CLI
192
set interfaces t1-1/0/0 receive-bucket set interfaces t1-1/0/0 transmit-bucket set interfaces t1-1/0/0 encapsulation ether-vpls-ppp set interfaces t1-1/0/0 encapsulation extended-frame-relay set interfaces t1-1/0/0 encapsulation extended-frame-relay-tcc set interfaces t1-1/0/0 encapsulation frame-relay-port-ccc set interfaces t1-1/0/0 encapsulation satop set interfaces t1-1/0/0 unit 0 encapsulation ether-vpls-fr set interfaces t1-1/0/0 unit 0 encapsulation frame-relay-ppp set interfaces t1-1/0/0 unit 0 layer2-policer set interfaces t1-1/0/0 unit 0 radio-router set interfaces t1-1/0/0 unit 0 family inet dhcp set interfaces t1-1/0/0 unit 0 inverse-arp set interfaces t1-1/0/0 unit 0 multicast-dlci
VLAN Interface CLI
set interfaces vlan unit 0 family tcc set interfaces vlan unit 0 family vpls set interfaces vlan unit 0 accounting-profile set interfaces vlan unit 0 layer2-policer set interfaces vlan unit 0 ppp-options set interfaces vlan unit 0 radio-router
Protocols Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following 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.
set protocols bfd no-issu-timer-negotiation
193
set protocols bgp idle-after-switch-over set protocols l2iw set protocols bgp family inet flow set protocols bgp family inet-vpn flow set protocols igmp-snooping vlan all proxy
Routing Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following routing hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set routing-instances p1 services set routing-instances p1 multicast-snooping-options set routing-instances p1 protocols amt set routing-options bmp set routing-options flow
Services Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following services hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set services service-interface-pools
Security Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following security hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set security utm feature-profile anti-virus engine profile name notification-options fallback-block display-host
set security utm feature-profile anti-virus engine profile name notification-options fallback-block allow-email set security utm feature-profile anti-virus engine profile name notification-options fallback-block administrator-email
194
SNMP Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following SNMP hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set snmp community 90 logical-system set snmp logical-system-trap-filter set snmp trap-options logical-system set snmp trap-group d1 logical-system
System Hierarchy
On SRX100, SRX210, SRX240, SRX650, and all J Series devices, the following system hierarchy CLI commands are not supported. However, if you enter these commands in the CLI editor, they appear to succeed and do not display an error message.
set system diag-port-authentication
IPv6 and MVPN CLI
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the following multicast IPv6 and MVPN CLI commands are not supported. However, if you enter these commands in the CLI editor, they will appear to succeed and will not display an error message.

show pim interfaces inet6 show pim neighbors inet6 show pim source inet6 show pim rps inet6 show pim join inet6 show pim mvpn show multicast next-hops inet6 show multicast rpf inet6 show multicast route inet6 show multicast scope inet6 show multicast pim-to-mld-proxy show multicast statistics inet6 show multicast usage inet6
195
show msdp sa group group set protocols pim interface interface family inet6 set protocols pim disable interface interface family inet6 set protocols pim family inet6 set protocols pim disable family inet6 set protocols pim apply-groups group disable family inet6 set protocols pim apply-groups group family inet6 set protocols pim apply-groups-except group disable family inet6 set protocols pim apply-groups group interface interface family inet6 set protocols pim apply-groups group apply-groups-except group family inet6 set protocols pim apply-groups group apply-groups-except group disable family inet6 set protocols pim assert-timeout timeout-value family inet6 set protocols pim disable apply-groups group family inet6 set protocols pim disable apply-groups-except group family inet6 set protocols pim disable export export-join-policy family inet6 set protocols pim disable dr-election-on-p2p family inet6 set protocols pim dr-election-on-p2p family inet6 set protocols pim export export-join-policy family inet6 set protocols pim import export-join-policy family inet6 set protocols pim disable import export-join-policy family inet6
New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 136 Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211 Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 239
196
Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
AppSecure
JUNOS Software Application IdentificationWhen creating custom application or nested application signatures for JUNOS Software application identification, the order value must be unique among all pre-defined and custom application signatures. The order value determines the application matching priority of the application signature. The order value is set with the set services application-identification application application-name signature order command. You can also view all signature order values by entering the show services application-identification | display set | match order command. You will need to change the order number of the custom signature if it conflicts with another application signature.
Chassis Cluster
On SRX Series and J Series devices, the following features are not supported when chassis clustering is enabled on the device:
On SRX3400, SRX3600, SRX5600 and SRX5800 devices, only redundant Ethernet interfaces (reth) are supported for IKE external interface configuration in IPsec VPN. Other interface types can be configured but IPsec VPN will not work. Packet-based forwarding for MPLS and International Organization for Standardization (ISO) protocol families.
NOTE: Chassis cluster features depend on flow-based forwarding. Flow-based forwarding for IP version 6 (IPv6) is supported, whereas flow-based processing for MPLS and ISO protocol families is not supported.
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 lt-0/0/0Real-time performance monitoring (RPM) pp0PPPoE, PPPoEoA
WXC Integrated Services Module (WXC ISM 200) ISDN BRI Layer 2 Ethernet switching
197
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.
On SRX Series and J Series devices in chassis cluster, packet capture is not supported on the reth interface.
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. 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. In large chassis cluster configurations on SRX3400 or SRX3600 devices, you need to increase the wait time before triggering failover. In a full-capacity implementation, we recommend increasing the wait to 8 seconds by modifying heartbeat-threshold and heartbeat-interval values in the [edit chassis cluster] hierarchy.
198
The product of the heartbeat-threshold and heartbeat-interval values defines the time before failover. The default values (heartbeat-threshold of 3 beats and heartbeat-interval of 1000 milliseconds) produce a wait time of 3 seconds. To change the wait time, modify the option values so that the product equals the desired setting. For example, setting the heartbeat-threshold to 8 and maintaining the default value for the heartbeat-interval (1000 milliseconds) yields a wait time of 8 seconds. Similarly, setting the heartbeat-threshold to 4 and the heartbeat-interval to 2000 milliseconds also yields a wait time of 8 seconds.
SRX100, SRX210, SRX220, SRX240, and SRX650 devices have the following chassis cluster limitations:

Virtual Router Redundancy Protocol (VRRP) is not supported. In Service Software Upgrade (ISSU) is not supported. 3G dialer interface is not supported. On SRX Series device failover, access points on the layer 2 switch reboot and all wireless clients lose connectivity for 4 to 6 minutes. On VDSL mini-PIM, cluster is not supported in either VDSL mode or DSL mode. Queuing on aggregated Ethernet (RETH) is not supported. PoE is not supported in HA mode. Group VPN is not supported. JFlow features such as packet capture, port mirror, and sampling on RETH interface are not supported. IDP is not supported for active-active and it is supported for active-backup from 10.2R2 releases and higher. Switching is not supported in HA mode.
On SRX100, SRX210, SRX240, and SRX650 devices, UTM is supported only for active/backup chassis cluster configuration with both RG0 and RG1+ active on the same node. It is not supported for active/active chassis cluster configuration.
J Series devices have the following limitation:
On J Series devices, a Fast Ethernet port from a 4-port Ethernet PIM cannot be used as a fabric link port in a chassis cluster.

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 SRX100 devices: four CLI users and three J-Web users For SRX210 devices: four CLI users and three J-Web users
199
For SRX240 devices: six CLI users and five J-Web users On SRX210 devices with Integrated Convergence Services, TDM configuration change might interrupt existing TDM calls. The voice calls do not work. Run the CLI restart rtmd command after making a configuration change.
DOCSIS Mini-PIM
On SRX210 Services Gateway, the DOCSIS Mini-PIM delivers speeds up to a maximum of 100 Mbps throughput in each direction.
Dynamic VPN
On SRX650 devices, the dynamic VPN client IPsec does not support "user-at-hostname" configuration option under gateway.
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
On SRX Series and J Series devices, high CPU utilization triggered due to various reasons such as CPU intensive commands and SNMP walks causes the BFD to flap while processing large BGP updates. Equal-cost multipath (ECMP) does not work with NAT/tunnelling when transit traffic is passed. 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. GPRS tunneling protocol (GTP) application is supported on well-known ports only. Customized application on other ports is not supported. On SRX3400, SRX3600, SRX5600, and SRX5800 devices, downgrading is not supported in low-impact in-service software upgrade (ISSU) chassis cluster upgrades (LICU). On SRX5800 devices, network processing bundling is not supported in Layer 2 transparent mode.
200
On SRX210, SRX240, and J Series devices, broadcast TFTP is not supported when flow is enabled on the device. Maximum concurrent SSH, Telnet, and Web sessionsOn SRX210, SRX240, and SRX650 devices, the maximum number of concurrent sessions is as follows:
SRX210
3 3 3
Sessions
ssh telnet Web
SRX240
5 5 5
SRX650
5 5 5
NOTE: These defaults are provided for performance reasons.
On SRX210 and SRX240 devices, for optimized efficiency, we recommend that you limit use of CLI and J-Web to the following numbers of sessions:
CLI
3 5
Device
SRX210 SRX240
J-Web
3 5
Console
1 1
On SRX100, SRX110, and SRX120 Series devices, multicast data traffic is not supported on IRB interfaces
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 a 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
201
Packet loss priority as action of a policer Packet loss priority as action of a three-color-policer
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the following features are not supported by a firewall filter:

Policer action Egress FBF FTF
SRX3400 and SRX3600 devices have the following limitations of a simple filter:
In the packet processor on an IOC, up to 100 logical interfaces can be applied with simple filters. In the packet processor on an IOC, the maximum number of terms of all simple filters is 4000. In the packet processor on an IOC, the maximum number of policers is 4000. In the packet processor on an IOC, the maximum number of three-color-policers is 2000. The maximum burst size of a policer or three-color-policer is 16 MB.
On SRX650 devices, the T1/E1 GPIMs (2 or 4 port version) do not work in 9.6R1. This issue is resolved in JUNOS Release 9.6R2 and later releases, but if you roll back to the 9.6R1 image, this issue is still seen. 1G half-duplex mode of operation is not supported in the autonegotiation mode for the following devices:

SRX650 Services Gateway 16-port GPIM 24-port GPIMs
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the Link Aggregation Control Protocol (LACP) is not supported on Layer 2 interfaces. 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 SRX100, SRX210, SRX240, and SRX650 devices, on the Level 3 ae interface, the following features are not supported:
202
Encapsulations (Ether CCC, VLAN CCC, VPLS, PPPOE, and so on) on Level 3 ae interfaces J-Web Level 3 ae interfaces for 10 Gigabit Ethernet XPIM ports
On the Layer 3 link aggregation group (LAG) interface, the class-of-service features are not supported. On SRX650 devices, the last 4 ports of a 24-Gigabit Ethernet switch GPIM can be used either as RJ-45 or SFP ports. If both are present and providing power, the SFP media is preferred. If the SFP media is removed or the link is brought down, then the interface will switch to the RJ-45 medium. This can take up to 15 seconds, during which the LED for the RJ-45 port might go up and down intermittently. Similarly when the RJ-45 medium is active and an SFP link is brought up, the interface will transition to the SFP medium, and this transition could also take a few seconds. On SRX Series and J Series devices, you can configure the st0 interface for IPsec VPN in any routing instance, but you must configure the gateway external interface in inet.0. The system allows you to assign an external interface that is placed in a routing instance other than inet.0, but that configuration is not supported. On 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. On SRX650 devices, BGP based VPLS over Aggregated Ethernet interfaces does not work as it is not supported in JUNOS Release 10.2. It works on child-ports and physical interfaces. On J Series devices routed-ports, Link Layer Discovery Protocol (LLDP) is not supported. On SRX240 High Memory devices, DOCSIS Mini-PIM is only supported with Comcast Cable modem.
On J2320, J2350, and J4350 devices, because of heap memory fragmentation Client to Server-Server to Client (CSSC) IDP policy load fails when you try to load the CSSC policy after loading the recommended policy. On SRX100, SRX210, SRX240, and SRX650 devices, the maximum supported entries in ASC table for is 100,000 entries. However, since the user land buffer has fix size of 1MB as a limitation, therefore it displays maximum 38837 cache entries. 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
203
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:
Application Server
1.1.1.1:80 1.1.1.1:80
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
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.
The maximum number of IDP sessions supported is 16000 on SRX210 devices, 32000 on SRX240 devices, and 128000 on SRX650 devices. On SRX100 and SRX210 devices, policy compilation takes a long time because:

Software DFA is now used for attack signature compilation IDPD daemon gets lesser CPU time slice during compilation
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. On SRX Series devices, the following IDP policies are supported:

DMZ_Services DNS_Service File_Server Getting_Started IDP_Default
204
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 action table is not synchronized across nodes. The Routing Engine 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.
IPv6 Support
ALGWe do not support Application Layer Gateway (ALG) features for IPv6 sessions in JUNOS Release 10.2. Chassis clusterThe following features are not supported for IPv6 traffic in JUNOS Release 10.2:

Active-active deployments for IPv6 sessions IP address monitoring for IPv6 destinations
Class of serviceWe do not support policers or simple filters for IPv6 traffic in JUNOS Release 10.2. Flow-based processingIf you change the forwarding option mode for IPv6, you must perform a reboot to initialize the configuration change. Table 13 on page 205 summarizes device status upon configuration change.
Table 13: Device Status Upon Configuration Change

Commit Warning
Yes No
Configuration Change
Drop to flow-based Drop to packet-based
Reboot Required
Yes No
Impact on Existing Traffic Before Reboot

Dropped Packet-based
Impact on New Traffic Before Reboot

Dropped Packet-based
205
Table 13: Device Status Upon Configuration Change (continued)

Commit Warning
Yes
Configuration Change
Flow-based to packet-based
Reboot Required
Yes
Impact on Existing Traffic Before Reboot

None
Impact on New Traffic Before Reboot

Flow sessions created Flow sessions created Packet-based Dropped
Flow-based to drop
Yes
Yes
None
Packet-based to flow Packet-based to drop
Yes No
Yes No
Packet-based Dropped
IPv6 transition mechanismsWe do not support transition mechanisms, such as NAT, NAT-PT, DS-lite, or tunneling in JUNOS Release 10.2. J-WebWe do not support configuration of IPv6-related settings with J-Web in JUNOS Release 10.2. You must use the CLI to configure these settings. MulticastWe do not support IPv6 multicast in JUNOS Release 10.2. NSMWe do not support configuration of IPv6-related settings with NSM in JUNOS Release 10.2. You must use the CLI to configure these settings. Routing protocolsWe do not support equal cost multipath (ECMP) or Intermediate System-to-Intermediate System (IS-IS) protocols in JUNOS Release 10.2. ScreensThe following screens are not supported for IPv6 sessions in JUNOS Release 10.2: syn-flood/syn-proxy/syn-cookie, syn-ack-ack-proxy, ip-spoofing. Security policyWe do not support IDP and UTM for IPv6 sessions in JUNOS Release 10.2. If your current security policy uses rules with the IP address wildcard any, and IDP and UTM features enabled, you will encounter configuration commit errors because IDP and UTM features do not yet support IPv6 addresses. To resolve the errors, modify the rule returning the error so that it uses the any-ipv4 wildcard; and create separate rules for IPv6 traffic that do not include IDP or UTM features. Stateless firewall filtersThe following features are not supported for IPv6 traffic in JUNOS Release 10.2:

Matching: IPv6 prefix list Actions: counter, log, reject, syslog
System operationsWe do not support DHCPv6 in JUNOS Release 10.2. User authenticationWe do not support firewall authentication or Web authentication over IPv6 in JUNOS Release 10.2. VPNWe do not support IPsec or SSL VPN for IPv6 traffic in JUNOS Release 10.2. VRRPOn SRX100, SRX210, SRX220, SRX240, and SRX650 devices, we do not support VRRP on IPv6 interfaces.
206
J-Web
On J Series devices, some J-Web pages for new features (for example, the Quick Configuration page for the switching features on J Series devices) display content in one or more modal pop-up windows. In the modal pop-up windows, you can interact only with the content in the window and not with the rest of the J-Web page. As a result, online Help is not available when modal pop-up windows are displayed. You can access the online Help for a feature only by clicking the Help button on a J-Web page. On SRX Series devices, you cannot use J-Web to configure a VLAN interface for an IKE gateway. VLAN interfaces are not currently supported to be used as IKE external-interfaces. On SRX3400, SRX3600, SRX5600, and SRX5800 devices, in J-Web, the Point and Click CLI configuration page shows an error when the configuration is committed with a candidate configuration in the CLI. On all J Series and SRX Series devices, you cannot use J-Web to configure custom attacks and attack groups in the Redesign IDP page. You must use the CLI to configure these settings. On all J Series and SRX Series devices, you can not use J-Web to delete the policies and the rules loaded through template. You must use the CLI to configure these settings.
NetScreen-Remote
On SRX Series devices, NetScreen-Remote is not supported in JUNOS Release 10.2.
NAT rule capacity changeTo support the use of large-scale NAT (LSN) at the edge of the carrier network, the device-wide NAT rule capacity has been changed. The number of destination and static NAT rules has been incremented as shown in Table 14 on page 207. The limitation on the number of destination-rule-set and static-rule-set has been increased. Table 14 on page 207 provides the requirements per device to increase the configuration limitation as well as scale the capacity for each device.
Table 14: Number of Rules on SRX Series and J Series Devices

NAT Rule Type
Source NAT rule Destination NAT rule Static NAT rule
SRX100
512
SRX210
512
SRX2 40
1024
SRX650
1024
SRX3400 SRX3600
8192
SRX5600 SRX5800
8192
J Series
512
512
512
1024
1024
8192
8192
512
512
512
1024
1024
8192
8192
512
207
The restriction on the number of rules per rule set has been increased so that there is only a device-wide limitation on how many rules a device can support. This restriction is provided to help you better plan and configure the NAT rules for the device.
IKE negotiations involving NAT-TOn SRX3400, SRX3600, SRX5600, and SRX5800 devices, IKE negotiations involving NAT-Traversal (NAT-T) 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.
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.
Point-to-Point Protocol over Ethernet (PPPoE)
On SRX240 devices in a chassis cluster, the reth interface cannot be used as the underlying interface for Point-to-Point Protocol over Ethernet (PPPoE).
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 order radius password or ldap password. On SRX Series and J Series devices, the limitation on the number of addresses in address-set has been increased. The number of addresses in address-set now depends on the device and is equal to the number of addresses supported by the policy. Table 15 on page 208 provides the address-set details per device to increase the configuration limitation.
Table 15: Number of Addresses in address-set on SRX Series and J Series Devices
Device
Default SRX100 High Memory SRX100 Low Memory SRX210 High Memory SRX210 Low Memory SRX240 High Memory SRX240 Low Memory
address-set
1024 1024 512 1024 512 1024 512
208
Table 15: Number of Addresses in address-set on SRX Series and J Series Devices (continued)
Device
SRX650 SRX3400 SRX3600 SRX5600 SRX5800 J Series
address-set
1024 1024 1024 1024 1024 1024
SNMP
On J Series devices, the SNMP NAT-related MIB is not supported in JUNOS Release 10.2.
Switching

On SRX100, SRX210, SRX240 and SRX650 devices, CoA is not supported with 802.1x. On SRX100, SRX210, SRX240 and SRX650 devices, on the routed VLAN interface, the following features are not supported:

IPv6 (family inet6) ISIS (family ISO) Class-of-service Encapsulations (Ether CCC, VLAN CCC, VPLS, PPPOE etc) on VLAN interfaces CLNS PIM DVMRP VLAN interface MAC change Gratuitous ARP Change VLAN-Id for VLAN interface
209
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.
VLAN
On SRX100, SRX210, SRX240, SRX650, and J Series devices, the IRB (VLAN) interface cannot be used as the underlying interface for Point-to-Point Protocol over Ethernet (PPPoE).
VPNs
On SRX100, SRX210, SRX240, and SRX650 devices, while configuring dynamic VPN using PULSE client, when you select the authentication-algorithm as sha-256 in the IKE proposal, the IPsec session might not get established. 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 the same public IP address. The total number of tunnels from a given public translated IP cannot exceed 1000 tunnels.
WLAN
The following are the maximum numbers of access points that can be configured and managed from SRX Series devices:

SRX2104 access points SRX24016 access points SRX65064 access points
NOTE: The number of licensed access points can exceed the maximum number of supported access points. However, you can configure and manage only the maximum number of access points.
New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 136
210
Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211 Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 239
Outstanding Issues In JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211 Resolved Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 232
Outstanding Issues In JUNOS Release 10.2 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. Application Layer Gateways (ALGs)
On some SRX650 devices, the maximum SCCP concurrent calls cannot be made under stress conditions as some calls get dropped. [PR/490839] On SRX3400, RX3600, SRX5600, and SRX5800 devices with two SPUs, the passing rate of SIP scaling test will decrease on 10.2 builds. [PR/540554]
AppSecure
When downloading the predefined application identification signature database on SRX3400, SRX3600, SRX5600, and SRX5800 devices, the new database will merge with the existing database instead of replacing it. If duplicate entries in the order and port-mapping signature fields exist, there might be issues in detecting applications defined by those signatures. If a duplicate port-mapping value exists, new signature database downloads will fail with the status output: AI installation failed! Attack DB update failed. The /var/log/appidd log will show: port xxx is specified more than once (xxx will equal the port-mapping value that is duplicated). If this occurs, use the following procedure to remove and reinstall the latest application identification signature database. To uninstall the predefined application identification signature database for JUNOS Software application identification and IDP application identification:
user@host> request services application-identification uninstall
NOTE: The uninstall command will only remove the application identification portion of the IDP signature database.
To download and install the latest predefined application identification signature database for JUNOS Software application identification:
user@host> request services application-identification download
211
To download the application identification and IDP signature database for IDP:
user@host> request security idp security-package download
To install the application identification and IDP signature database for IDP:
user@host> request security idp security-package install
[PR 521482/518183] 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]
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 SRX650 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 SRX650 devices, the Ax411 clustering feature is not recommended because it is unstable in certain instances. [PR/ 538994] [PR/ 554551]
Chassis Cluster
On J Series devices in a chassis cluster, the show interface terse command on the secondary Routing Engine does not display the same details as that of the primary Routing Engine. [PR/237982] On J4350 Services Routers, because the clear security alg sip call command triggers a SIP RTO to synchronize sessions in a chassis cluster, use of the command on one node with the node-id, local, or primary option might result in a SIP call being removed from both nodes. [PR/263976] On J Series devices, when a new redundancy group is added to a chassis cluster, the node with lower priority might be elected as primary when the preempt option is not enabled for the nodes in the redundancy group. [PR/265340] On J Series devices, when you commit a configuration for a node belonging to a chassis cluster, all the redundancy groups might fail over to node 0. If graceful protocol restart is not configured, the failover can destabilize routing protocol adjacencies and disrupt traffic forwarding. To allow the commit operation to take place without causing a failover, we recommend that you use the set chassis cluster heartbeat-threshold 5 command on the cluster. [PR/265801]
212
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, sometimes the reth interface MAC address might not make it to the switch filter table. This results in the dropping of traffic sent to the reth interface. As a workaround, restart the Packet Forwarding Engine. [PR/401139] On an SRX210 device in a chassis cluster, the fabric monitoring option is enabled by default. This can cause one of the nodes to move to a disabled state. You can disable fabric monitoring by using the following CLI command:
set chassis cluster fabric-monitoring disable
[PR/404866]
On an SRX210 Low Memory device in a chassis cluster, the firewall filter does not work on the reth interfaces. [PR/407336] On an SRX210 device in a chassis cluster, the restart forwarding method is not recommended because when the control link goes through forwarding, the restart forwarding process causes disruption in the control traffic. [PR/408436] On 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]
213
On SRX3400, SRX3600, SRX5600, SRX5800, and J Series 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 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 an 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 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 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 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.2. [PR/471235] 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.2R1. [PR/482566] On SRX3400 and SRX3600 devices, chassis cluster upgrades (LICUs) with no-old-master-upgrade from JUNOS Release 9.6R2.11 to 10.0R1.x and from JUNOS Release 10.0R1.8 to 10.2 do not work. [PR/483485] On SRX3600 devices, after you disable and enable the secondary node track, the IP status remains unreachable. [PR/488890] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, although there is no limit by software, the maximum number of bundles that include aggregated Ethernet ae and redundant Ethernet reth interface bundles is 128. [PR/497994] 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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, LACP does not work in Layer 2 transparent mode. [PR/503171]
214
During a manual failover, a system crash might occur if the nodes have not completely recovered from a previous failover. To determine if a device is ready for repeated failovers, perform these recommended best-practice steps before doing a manual failover. The best-practice steps we recommend to ensure a proper failover are as follows:
1.
Use the show chassis cluster status command to verify the following for all redundancy groups:

One node is primary; the other node is secondary. Both nodes have nonzero priority values unless a monitored interface is down.
2. Use the show chassis fpc pic-status command to verify that the PIC status is Online. 3. Use the show pfe terse command to verify that the Packet Forwarding Engine status
is Ready and to verify following:

All slots on the RG0 primary node have the status Online All slots on the RG0 secondary node, except the Routing Engine slots, have the status Valid.
[PR/503389 and PR/520093]
On SRX5600 and SRX5800 devices, kernel crashes occur during LICU from JUNOS Release 9.6R3 to JUNOS Release 10.2B2 along with vmcore and ksyncd core files, which interrupts the traffic. [PR/511973] On SRX3400, SRX3600, SRX5600, and SRX5800 devices in L2 chassis cluster, when there is too much DNS traffic through the device, , a core file is generated. [PR/512888] On SRX650 devices in chassis cluster, ping packets sent from the forward node to the active node are dropped intermittently. [PR/520669] On SRX240 PoE devices, chassis cluster for VDSL2 Mini-PIM is not supported in JUNOS Release 10.2R2 . [PR/523721]
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]
215
Dynamic Host Configuration Protocol (DHCP)
On SRX210 and SRX240 devices, when autoinstallation is configured to run on a particular interface and the default static route is set with the options discard, retain, and no-advertise, the DHCP client running on the interface tries fetching the configuration files from the TFTP server. During this process, the UDP data port on the TFTP server might be unreachable. Because of the TFTP server being unreachable, the autoinstallation process might remain in the configuration acquisition state. When autoinstallation is disabled, the TFTP might fail. In this case, you should manually fetch the file from the server or the client through the relay. As a workaround, remove the static route options: discard, retain, and no-advertise, from the configuration. [PR/454189]
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 SRX5800 devices, when you remove the SPC containing the control link, or during power failure, both nodes of the cluster assume primary. [PR/417369] On SRX240 devices, traffic flooding occurs when multiple multicast IP group addresses are mapped to the same MAC address because multicast switching is based on the Layer 2 address. [PR/418519]
216
On SRX650 devices, the input DA errors are not updated when packets are dropped because of MAC filtering on the following:

SRX240 device SRX210 device 16-port and 24-port GPIMs SRX650 front-end port
This is because of MAC filtering implemented in hardware. [PR/423777]
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 onboard Ethernet port, an IPv6 multicast packet received gets duplicated at the ingress. This happens only for IPv6 multicast traffic in ingress. [PR/432834] On SRX3400 and SRX3600 devices, the ramp rate of session creation is slow at times for fragmented UDP traffic. [PR/434508] On SRX5800 devices, when there are nonexistent PICs in the network processing bundle, the traffic is sent out to the PICs and is lost. [PR/434976] The SRX5600 and SRX5800 devices create more than the expected number of flow sessions with NAT traffic. [PR/437481] On J Series devices, NAT traffic that goes to the WXC ISM 200 and returns 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] 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 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 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]
217
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] 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 time slots) should not be bundled under one ML bundle. [PR/464410] On SRX650 devices, after the primary reboot, transit traffic takes many seconds to resume because GARP does not get through. [PR/474953] 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, the input packets and bytes counter shows random value both in traffic statistics and IPv6 transit statistics, when VLAN tagging is added or removed from the IPv6 address configured interface. [PR/489171] On J2350 devices, one or two packets are dropped on the first ping after reboot or after clearing IPv6 neighbors on the transit HA primary device. The packets are also dropped when the IPv6 neighbors list is removed after the time expires. [PR/479603] On SRX Series and J Series devices, system log messages about interactive commands to the system log server do not work. [PR/511110] On SRX Series devices, the software upload and install package will not show a warning message when there are pending changes to be committed. [PR/514853] On SRX650 devices, the reth child interface MAC statistics do not change. For monitoring, you must use the reth interface statistics. [PR/521921] On SRX240 Low Memory devices, the LSQ interface transmitting both LLQ and non-LLQ traffic drops out-of-profile packets of the LLQ traffic faster than it dropped them out earlier. [PR/536588]
218
Hardware
On SRX210 devices, the MTU size is limited to 1518 bytes for the 1-port SFP Mini-PIM. [PR/296498] On SRX240 devices, the Mini-PIM LEDs glow red for a short duration (1 second) when the device is powered on. [PR/429942] On SRX240 devices, the file installation fails on the right USB slot when both of the USB slots have USB storage devices attached. [PR/437563] On SRX240 devices, the combinations of Mini-PIMs cause SFP-Copper links to go down in some instances during bootup, restarting fwdd, and restarting chassisd. As a workaround, reboot the device and the link will be up. [PR/437788]
Infrastructure
On J Series devices, you cannot use a USB device that provides U3 features (such as the U3 Titanium device from SanDisk Corporation) as the media device during system boot. You must remove the U3 support before using the device as a boot medium. For the U3 Titanium device, you can use the U3 Launchpad Removal Tool on a Windows-based system to remove the U3 features. The tool is available for download at http://www.sandisk.com/Retail/Default.aspx?CatID=1415 . (To restore the U3 features, use the U3 Launchpad Installer Tool accessible at http://www.sandisk.com/Retail/Default.aspx?CatID=1411). [PR/102645] On J Series devices, if the device does not have an ARP entry for an IP address, it drops the first packet from itself to that IP address. [PR/233867] On J Series devices, when you press the F10 key to save and exit from BIOS configuration mode, the operation might not work as expected. As a workaround, use the Save and Exit option from the Exit menu. This issue can be seen on the J4350 and J6350 devices with BIOS Version 080011 and on the J2320 and J2350 devices 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]
219
Installation
On SRX100, SRX210, SRX240, or SRX650 devices with 1-GB storage flash, on use of the file copy command to copy the JUNOS package from ftp://<path> to a local directory, you can get a message saying that the file system is full. Please do not use the file copy command to get the JUNOS package for software upgrade. The file copy command copies the JUNOS package as a temporary file in/cf/var/tmp and then copies the file with a package name in a local directory under the /cf/var partition. This means that a JUNOS package of size X needs 2X space in the /cf/var partition. For example, a JUNOS package of 197 MB will need 394 MB, whereas the /cf/var partition is less than 350 MB on a 1-GB storage flash. Thus, the file copy command will fail. [PR/526030]
Integrated Convergence Services The following issues currently exist in SRX210 and SRX240 devices with Integrated Convergence Services:
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] On SRX210 devices with voice capability, SIP trunking or FXS trunking calls does not work when the called party supports only the G729AB/G711-Mu-law codec. [PR/504135] On SRX210 and SRX240 devices with voice capability, the T1PRI calls does not work when multiple trunk-groups or trunks are created. [PR/514784] On SRX210 and SRX240 devices with voice capability, the caller ID of the calling party is displayed as a four digit local extension number instead of a 7- or 10-digit local or international number for outgoing calls from PRI. [PR/516021] On SRX210 and SRX240 devices with Integrated Convergence Services, if you have the accounting feature configured (Services>Convergence services>Features), you cannot configure the account code on a per-station basis. [PR/516681] On SRX240 devices with voice capability, SIP over TCP is not supported when ALG is enabled. [PR/523440] On SRX240 devices with voice capability and Avaya ASM set up, DTMF tone is not heard when last added party in 3-way conference call hangs. [PR/529115] On SRX240 devices with voice capability, restart RTMD command is required after changing the max-concurrent-value from x to 0, to allow unlimited calls through SIP Trunk or PCS. [PR/536849] On SRX240 devices with voice capability, the restart rtmdcommand is required to make PRI calls successful when both PRI and T1CAS lines are active. [PR/537551] On SRX210 and SRX240 devices with voice capability, E911 preemption does not happen when the PSTN line is busy in the ringing state. [PR/538277]
220
On J4350 and J6350 devices, the link status of the onboard Gigabit Ethernet interfaces (ge-0/0/0 through ge-0/0/3) or the 1-port Gigabit Ethernet ePIM interface fails when you configure these interfaces in loopback mode. [PR/72381] On J Series Routers, asymmetric routing, such as tracing a route to a destination behind J Series devices with Virtual Router Redundancy Protocol (VRRP), does not work. [PR/237589] On SRX5600 and SRX5800 devices, ping to far-end reth interfaces does not work for different routing instances. [PR/408500] On SRX240 and SRX650 devices, when you are configuring the link options on an interface, only the following scenarios are supported:

Autonegotiation is enabled on both sides. Autonegotiation is disabled on both sides (forced speed), and both sides are set to the same speed and duplex. If one side is set to autonegotiation mode and the other side is set to forced speed, the behavior is indeterminate and not supported. [PR/423632]
On SRX Series and J Series devices, the RPM operation will not work for the probe-type tcp-ping when the probe is configured with the option destination-interface. [PR/424925] On SRX650 devices, the following loopback features are not implemented for T1/E1 GPIMs:

Line FDL payload Inband line Inband payload [PR/425040]
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]
221
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 SRX Series devices, incorrect Layer 2 circuit replication on the backup Routing Engine might occur when you:
Configure nonstop active routing (NSR) and Layer 2 circuit standby simultaneously and commit them Delete the NSR configuration and then add the configuration back when both the NSR and Layer 2 circuits are up
As a workaround:
1.
Configure the Layer 2 circuit for a nonstandby connection.
2. Change the configuration to a standby connection. 3. Add the NSR configuration.
[PR/440743]
On SRX210 Low Memory devices, the E1 interface will flap and traffic will not pass through the interface if you restart forwarding while traffic is passing through the interface. [PR/441312] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you configure the SAP listen option using the protocol sap listen command in the CLI, listening fails in both sparse and sparse-dense modes. [PR/441833] On J Series devices, one member link goes down in a Multilink (ML) bundle during bidirectional traffic with Multilink Frame Relay (MFR). [PR/445679] On SRX240 Low Memory devices and SRX240 High Memory devices, the RPM Server operation does not work when the probe is configured with the option destination-interface. [PR/450266] 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 SRX100, SRX210, and J Series devices, out-of-band dial-in access using a serial modem does not work. [PR/458114] 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 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]
222
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 SRX210 devices with VDLS2, ATM COS VBR-related functionality cannot be tested because of lack of support from the vendor. [PR/474297] 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, when you change the multicast scoping to a different multicast address, traffic other than which is configured for multicast scoping will not be received. [PR/482957] 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 IRB interfaces. [PR/492564] On SRX210 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 because of no ATM connection. [PR/493099] On SRX Series devices, 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 SRX210 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 SRX100, SRX210, SRX240, and SRX650 devices, whenever radius-server is configured under profile option radius server is marked as dead permanently if RADIUS times out. As a workaround, configure radius-server outside the profile option under access option. [PR/503717] On SRX5600 and SRX5800 devices, load balance does not happen within the aggregated Ethernet (ae) interface when you prefix the length with /24 while incrementing the dst ip. [PR/505840] On SRX100, SRX210, SRX240, and SRX650 devices, egress queues are not supported on VLAN or IRB interfaces.[PR/510568]
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 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 maximize-idp-sessions mode, the configuration of the security forwarding-process
223
application-services maximize-idp-sessions command should be done right before
rebooting the device. This should be done to avoid recompiling IDP policies during every commit. [PR/426575]
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, 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, 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.2 (Layer 2 access-regular mode) is rolled back to the JUNOS Release 9.6 image, the DUT comes up in JUNOS Release 9.6 with Layer 2 access-regular mode, which was not supported in JUNOS Release 9.6. [PR/469069] NSM IDP policy update fails while pushing the small policy to the Branch platforms. As a workaround, selecting Preferences>Device Update>Netconf>use confirmed commit in J-Web and disabling confirmed commit makes the update success. [PR/516151] On SRX100 and SRX210 devices, depending on configuration, peak performance level drops up to 30 percent have been observed for IDP and UTM features. This issue impacts only customers who deploy these devices with peak performance level requirements for IDP and UTM services. [PR/503446, PR/506500, PR/518737] On SRX Series devices, the maximum supported sessions count is not displayed when you run the show security flow session idp summary command. [PR/503721] On SRX3600 devices, packet logging with time binding attacks does not work. [PR/511992] On SRX5600 devices, when using the 4096-bit SSL private key for IDP HTTPS traffic processing, the watchdog aborts the flowd process and reboots the SPC. This is primarily because of the watchdog timer expiration. The IDP function takes a long time to decrypt the session when you use a 4096-bit key. The SSL function is known to take exponentially large amount of time when the key size is increased. While key sizes of 1024 bits and 2096 bits are acceptable to process, because these take processing times which are below the watchdog threshold, the key size of 4096 bits should not be used when sending stress traffic. Also IDP uses SSL hardware for <= 1024 bit keys. The throughput is much higher for the traffic using <= 1024 bit SSL private keys. [PR/524452 ]
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when packet-logging functionality is configured with higher value of pre-attack configuration parameter, the resource utilization increases proportionally and might impact the performance. [PR/526155]
224
On SRX5800 devices, when the IDP policy is large and there are many policy load attempts, the IDP policy fails to load due to memory fragmentation. As a workaround, restart all the PICs using restart chassis-control. [PR/539318] On SRX240 High Memory devices, IDP policies greater than 17 MB do not get loaded. [PR/540856]
ISSU
In-service software upgrade (ISSU) is not supported for upgrading VPN, NAT, IPv6, FTP ALG, TFTP ALG, or IDP functionality. If ISSU is used while the noted functionality is enabled, SRX Series devices might be left in an invalid state. The upgrade options are either to disable unsupported ISSU features prior to the upgrade or to use a standard upgrade procedure with a reboot. [PR/558566, PR/530035].
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]
J-Web
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the LEDs on the Routing Engine and PICs are not shown as green when they are up and online on the J-Web Chassis View. [PR/297693] On SRX Series devices, when the user adds LACP interface details, a pop-up window appears in which there are two buttons to move the interface left and right. The LACP page currently does not have images incorporated with these two buttons. [PR/305885] On SRX210 devices, there is no maximum length limit when the user commits the hostname in CLI mode; however, only a maximum of 58 characters are displayed in the J-Web System Identification panel. [PR/390887] On SRX210, SRX240, and SRX650 devices, the complete contents of the ToolTips are not displayed in the J-Web Chassis View. As a workaround, drag the Chassis View image down to see the complete ToolTip. [PR/396016] On SRX100, SRX210, SRX240, and SRX650 devices, the LED status in the Chassis View is not in sync with the LED status on the device. [PR/397392] On SRX Series devices, when you right-click Configure Interface on an interface in the J-Web Chassis View, the Configure>Interfaces page for all interfaces is displayed instead of the configuration page for the selected interface. [PR/405392]
225
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] 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, 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, 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
226
new query returns very few results, the Route Information table continues to display page 3 with no results. To view the results, navigate to page 1 manually. [PR/476338]
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the entry registered into RIB is not shown in J-Web. [PR/483885] 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 SRX100 (low memory and high memory), SRX210 (low memory, high memory, and PoE), SRX240 (low memory and high memory), SRX650, J2350, J4350, and J6350 devices, CoS feature commits occur without validation messages, even if you have not made any changes. [PR/495603] On SRX Series devices, in the J-Web interface, there is no support to change the T1 to E1 interface and vice versa. As a workaround, use the CLI to convert from T1 to E1 and vice versa. [PR/504944] On SRX High Memory devices, the J-Web configuration does not work when the CLI session is in configure mode. As a workaround, the CLI session must be in operational mode. [PR/523058]
Link Aggregation (LAG)
On SRX650 devices, in the J-Web interfaces, you cannot configure L3-VLAN/VLAN-tagging on a single AE interface. You can configure it on a physical interface. [PR/529640] On SRX650 devices, encapsulation "ethernet-ccc" is not supported on Aggregated Ethernet. [PR/529938]
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]
227
On SRX240 devices, the Scheduler Oinker messages are seen on the console at various instances with various Mini-PIM combinations. These messages are seen during bootup, restarting fwdd, restarting chassisd, and configuration commits. [PR/437553] On 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, data path debug trace messages are 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 J4350 devices, when you place internal calls, interface-based persistent NAT displays only one active hairpinning session instead of two, even after the call is established. [PR/504932] On SRX210 Low Memory devices, you cannot generate IPv4 and IPv6 ICMP redirect message from the HA cluster. [PR/516739] On J4350, SRX100 Low Memory devices, SRX210 Low Memory devices, SRX240 Low Memory devices, and SRX650 devices, the JSRPD logs shows failed to get iff for reth1.0 family:AF_INET6 error:No such file or directory, when an IPv6 address is configured. However, GARP works for IPv4. [PR/520983]
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 devices, the fourth access point connected to the services gateway fails to boot with the default 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 AX411 Access Point. This might be due to the DHCP default gateway not being set. [PR/468090] On SRX210 PoE devices managing AX411 Access Points, traffic of 64 bytes at a speed more than 45 megabits per second (Mbps), might result in loss of keepalives and reboot of the AX411 Access Point. [PR/471357]
228
On SRX210 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 SRX240 PoE devices, during failover, the ADSL Mini-PIM on the secondary node restarts and it takes about 3 to 4 minutes to come up. [PR/528949]
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 be 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]
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, and J Series 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
229
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 (>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 when using a UTM command:
the utmd subsystem is not responding to management requests.
As a workaround, restart the utmd process. [PR/436029]
On SRX100 High Memory, SRX210 High Memory, SRX240 High Memory, and SRX650 devices, the antispam requests of more than 1500 are not supported due to system limitations. [PR/451329] On SRX240 High Memory devices, when you test UTM for an extended duration of 5 days, leakage of fewer than 100 buffers is observed. [PR/537314] On SRX240 High Memory devices, during UTM Web traffic stress test, some leakage of AV scanner contexts is observed in some error pages. [PR/538470]
Upgrade
Low-impact ISSU chassis cluster upgrades are not supported in JUNOS Release 10.2R1. ISSU upgrade to 10.2R1 might cause loss of configuration. In order to upgrade to 10.2R1, use the normal upgrade procedure described in JUNOS Software Installation and Upgrade Guide (http://www.juniper.net/techpubs/en_US/junos10.1/informationproducts/topic-collections/software-installation-and-upgrade-guide/topic44670.html#jd0e3432) . [PR/526599 and PR/526829]
USB Modem
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 higher 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 dial-in or dial-out
230
interface goes down because no keepalive packets are exchanged. As a workaround, increase the ATS0 value to 4 or greater. [PR/492970]
On SRX210 High Memory devices and J6350 devices, the D10 link flaps during long-duration traffic of 15 Kbps and also when the packet size is 256 Kbps or more. [PR/493943]
Virtual LANs (VLANs)
On SRX650 devices, when VLAN tagging is configured and traffic is sent, the output of show interfaces ge-0/0/1 media detail VLAN tagged frame count is not shown. [PR/397849] On SRX240, SRX650, J4350, and J6350 devices, tagged frames on an access port with the same VLAN tag are not dropped. [PR/414856] 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] 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 J Series and SRX Series devices, IPv6 is not supported on VLAN interfaces. [PR/490494] On J Series and SRX Series devices, family ISO configuration is not supported on VLAN interfaces. [PR/500082]
VPNs
On SRX5600 devices, the shared IKE limit for IKE users is not currently enforced. More users than are specified in the shared IKE limit are able to establish IKE/IPsec tunnels. [PR/288551] On SRX210 and SRX240 devices, concurrent login to the device from a different management systems (for example, laptop or computers) is 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 scenario of 3 or more zones 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]
231
On SRX100, SRX210, SRX240, and SRX650 devices, Routing Engine level redundancy for dynamic VPN fails because the tunnels need to renegotiate after RG0 failover. [PR/513884] On SRX100, SRX210, SRX240, and SRX650 devices, the dynamic VPN server always pushes the last configured dynamic client configuration to the client. If the VPN configuration bound to this dynamic VPN client is not bound to a policy, IKE negotiation will fail when you try to connect to the server. [PR/514033] On SRX100, SRX210, SRX240, and SRX650 devices, the dynamic VPN client does not get downloaded if there is not enough space in the /jail/var directory in the dynamic VPN server. [PR/515261] On SRX3400 and SRX3600 devices, the VPN monitor status in the DEP server side stays down for some time after RG0 and RG1 failover because there is no active state sync up for VPN monitoring. [PR/532952] On SRX650 devices with plain IKE enabled, when you connect the same user with multiple clients, the device displays incorrect Remote IP address with 10.3R2. [PR/560523]
WLAN
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.2 for SRX Series Services Gateways and J Series Services Routers
The following issues from JUNOS Release 10.2R1 have been resolved with this release. The identifier following the description is the tracking number in our bug database. Application Layer Gateways (ALGs)
On SRX240 High Memory devices, with an IDP policy template, policy load failed when users changed the active policy from the recommended option to the IDP_Default option. [PR/539486: This issue has been resolved.] On SRX5800 devices, some sessions with FTP ALG stopped at a timeout value of 2 seconds, which caused an inability to form new sessions or a reduced session capacity. [PR/550815: This issue has been resolved.] On SRX5800 devices, core files were generated due to IKE IPsec passthrough traffic. [PR/551631: This issue has been resolved.]
232
On SRX5800 devices, flowd on the secondary node restarted when some ALG statistics were viewed. [PR/552808: This issue has been resolved.] On SRX5800 devices, when RTSP ALG was enabled, because RTSP opened many gates, a core dump was seen. [PR/555363: This issue has been resolved.] On SRX5800 devices, PPTP between an iPhone and a Calvister server did not work when PPTP ALG was used. [PR/556198: This issue has been resolved.] On SRX3400 devices, when you used FTP ALG, ACK packet of 3 ways handshake had MSS value being inserted into packet as it passed SRX Series devices. [PR/561404: This issue has been resolved.] On SRX3400 devices, ALG converter was erroneously printing messages "alg c enter" to flow traceoptions making it difficult to analyze flow traceoption output. [PR/571167: This issue has been resolved.]
Chassis Cluster
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the chassis cluster IP-Monitoring feature was not working for the secondary interface and generated a core file of the JSRP process. [PR/548779: This issue has been resolved.] On SRX650 devices, the device was slow, taking more than 60 seconds to respond to configuration mode commands issued in the CLI. [PR/552124: This issue has been resolved.] On SRX5800 devices when configured in a cluster, an incorrect calculation of slot numbers ledlog messages to display the wrong value for the slot affected . [PR/553330: This issue has been resolved.] On SRX5600 and SRX5800 devices, the IOC card reset unexpectedly when monitored IP addresses under the chassis cluster IP-monitoring configuration were deleted. In addition, the monitored IP was not deleted from the data plane when it was specified without a secondary interface. [PR/557687: This issue has been resolved.]
On SRX3600 devices, unsupported command show pfe statistics notification triggered error message PFED_NOTIFICATION_STATS_FAILED: Unable to retrieve notification statistics. [PR/549304: This issue has been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the show chassis fabric plane command was not showing any output. [PR/550700: This issue has been resolved.] On SRX3400 devices, the show security policy detail command output displayed incorrect values for the Active Session field. [PR/573600: This issue has been resolved.]
233
Flow and Processing
On SRX650 devices, the uplinks to the CPU were exhausted, and the system was limited to 2.5 GB throughput traffic when the device was using similar kinds of source MAC addresses. [PR/428526: This issue has been resolved.] On SRX5800 devices, the message log file became full due to the message /kernel: pfestat_req_expect: ipc type 20 subtype 7 uniquifier 0 overwriting sendmask mask. [PR/509556: This issue has been resolved.] On SRX3600 devices, transit traffic that came to the VRRP MAC address never got policed by simple filter policing on the IOC. [PR/528402: This issue has been resolved.] On SRX3600 devices, ping through VPN intermittently dropped when primary device was a different node on RG0 and RG1. [PR/533469: This issue has been resolved.] On SRX5800 devices, under certain circumstances, flow sessions were rerouted to a local interface and were unable to be rerouted back to the physical interface. [PR/535536: This issue has been resolved.] On SRX210 High Memory devices, the continuous error message "JMDX: Thread timed out waiting for smi write was displayed. [PR/ 536586: This issue has been resolved.] On SRX240 devices, unexpected power failure caused configuration corruption and license loss. [PR/539146: This issue has been resolved.] On SRX210 Low Memory devices, policy compilation took a long time when there was traffic. [PR/539422: This issue has been resolved.] On SRX100, SRX210, SRX240, and SRX650 devices, when trying to authenticate using TACACS+, J-Web expected the password prompt to be "Password" and the authenticating failed if prompt sent was "password". [PR/540217: This issue has been resolved.] On SRX240 High Memory devices, when committing a configuration change that added a security policy with a DNS address object, the device generated a core file if the DNS address object was unresolved to an IP address. [PR/542175: This issue has been resolved.] On SRX Series devices, the output firewall filters work with translated IP addresses and port numbers after NAT rules were applied. [PR/543129: This issue has been resolved.] On SRX Series devices, changing firewall filter policer configuration resulted in the SNMP MIBs not being updated correctly and therefore the counters were not accessible. [PR/555719: This issue has been resolved.] On SRX5800 devices, when you queried SPCs for session data from command shell, coredump wass generated on SPC. [PR/557570: This issue has been resolved.] On SRX210 devices, even without traffic, the round trip jitter for RPM probes was very high. [PR/558744: This issue has been resolved.] On SRX5800 devices acting as a GRE pass through device, TCP out of order packets occurred. [PR 558923: This issue has been resolved.]
234
On SRX5800 devices, some RTSP clients could not view video portion of the RTSP stream while receiving audio. [PR/ 558924: This issue has been resolved.] On SRX5600 devices, the following log message appeared in log files in Junos OS Release 10.2 : No child found for aggregate nexthop 1769 on ifl 78. Ignoring. This message appeared due to arp entries being deleted from the system or in association with some traffic loss. [PR/563105: This issue has been resolved.]
On SRX3400 devices, during deletion of multicast routes, a Flowd coredump was seen on SPC. [PR/567563: This issue has been resolved.] On SRX210 devices, after upgrading JUNOS, the card failed to initialize and flowd core dump was seen. [PR/568131: This issue has been resolved.] On SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, packets got dropped due to a memory leak in the SPU. [PR/574089: This issue has been resolved.] On SRX650 devices, the license never got released due to a sudden loss of connection such as clientpc reboot [PR/576138: This issue has been resolved.] On SRX3600 devices, high CPU utilization was observed with network security process (NSD) when dns-name entries were used in security policies. [PR/585154: This issue has been resolved.]
Hardware
On SRX650 devices, fan and power supply alarms did not work correctly. [PR/543117: This issue has been resolved.] On SRX3600 devices, a small fraction of the incoming packets had an incorrect VLAN tag. For TCP sessions this caused TCP RESET to be sent from SRX to the host. The host responded with TCP RESET which cleared the session. [PR/521721: This issue has been resolved.] On J6350 devices, SNMP MIB for the chassis fan was missing. [PR/567795: This issue has been resolved.]
On SRX210 devices with media gateway capability, chassis cluster functionally was impaired. The device that was configured as node1 crashed repeatedly. [PR/535512: This issue has been resolved.] On SRX210, SRX220, and SRX240 devices with voice capability, when a call came to an SRX Foreign Exchange Office (FXO) and was forwarded to a PCS, the caller ID was not preserved. [PR/535540: This issue has been resolved.]
On SRX210 devices, the modem moved to the dial-out pending state while connecting or disconnecting the call. [PR/454996: This issue has been resolved.] On J Series and SRX Series devices, PPPoE, family tcc, and VPLS were not supported on the VLAN interface. The Layer 2 policer, configurable under IFLs, was not supported
235
for either physical or VLAN interfaces. The options for configuring these features are disabled. [PR/537041: This issue has been resolved.]
On SRX210 Low Memory devices, traffic stopped passing from pp0 interface when using sampling upon PPPoE re-negotiation. [PR/543937: This issue has been resolved.] On SRX240 and SRX650 devices, IGMP reports were flooded on all ports that were part of the same multicast group instead of being sent on only the router interface. [PR/546444: This issue has been resolved.] On J4350 devices, T1/E1 interface counters were inaccurate. [PR/548224: This issue has been resolved.] On SRX3600 devices, RG failover to Node 0 failed because the FPCs went offline during the failover. [PR/563391: This issue has been resolved.] On SRX3600 devices, Redundancy Group 0 failovers caused interface flapping when LACP was used on reth interfaces. [PR/565617: This issue has been resolved.]
On SRX210 High Memory and SRX240 High Memory devices, IDP scaling drop was observed on all SRX Series platforms. [PR/525732: This issue has been resolved.] On SRX3400 devices, the packet-logging functionality was not supported in dedicated-equal mode in JUNOS Release 10.2R1; all other modes of operation were supported. [PR/526252: This issue has been resolved.] On SRX650 devices, when pre-defined attack groups were used in IDP policy, commit lasted for more than 10 minutes. [PR/546467: This issue has been resolved.] On SRX3600 devices, under high IDP usage, the traffic loss was observed during flow processing and the error message "failed to allocate fto" was displayed. [PR/582725: This issue has been resolved.]
J-Web
On SRX100 devices, in J-Web, users could configure the scheduler without entering any stop date. The device submitted the scheduler successfully, but the submitted value was not displayed on the screen or saved in the device. [PR/439636: This issue has been resolved.] On J2350 and SRX210 High Memory devices, you could not use the Move down button for moving the IPS rule in the IDP Policy page. You had to use the Move down button in the landing page. [PR/499499: This issue has been resolved.] On SRX Series and J Series devices, in the J-Web interface, the move/edit button was not working for the exempt rule base on the IDP Policy configuration page. [PR/503451: This issue has been resolved.] On SRX100, SRX210, SRX220, SRX240, SRX650 and J Series devices, in J-Web, policies and rules loaded through policy template could not be deleted. [PR/514845: This issue has been resolved.]
236
On all J Series and SRX Series devices, you could not use J-Web to configure the IPS-Exempt rule, selecting only attacks; you had to select addresses and zones. [PR/522197: This issue has been resolved.] On SRX240 Low Memory devices, J-Web allowed the negotiation of SSL ciphers that offered weak encryption, which caused some PCI compliance scans to fail. [PR/ 539477: This issue has been resolved.] On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, J-Web login and page navigation was slow. [PR/546502: This issue has been resolved.] On SRX100, SRX210, and SRX240 devices, in J-Web the resource utilization did not load any data in the dashboard page using Firefox 3.0. [PR/564165: This issue has been resolved.] On SRX100 devices, the max MTU allowed to be configured on a FE interface is 1624. MTU configuration from J-Web was not recommended for Junos 10.1 and 10.2 releases. [PR/566592: This issue has been resolved.]
On SRX240 High Memory devices in a chassis cluster, the secondary node could go to DB> mode when there were many policies configured and TCP, UDP, and ICMP traffic matched the policies. [PR/493095: This issue has been resolved.] On SRX5600 devices, when you defined an application set without having a defined application, the commit error displayed was not descriptive. [PR/536774: This issue has been resolved.] On SRX Series devices, the output firewall filters worked with translated IP addresses and port numbers after NAT rules were applied. [PR/543129: This issue has been resolved.] On SRX210 PoE devices, a change in the IP address of the interface did not refresh the corresponding sessions and NAT incoming table. [PR/554946: This issue has been resolved.] On SRX650 devices, when modifying Static NAT configurations traffic may fail to match modified static nat rule. [PR/576647: This issue has been resolved. ] On SRX5800, passive FTP through static NAT was failed because the server IP address in the 227 message was not translated by the FTP ALG when a custom routing instance was used. This problem occurred after a reboot or after adding an interface into a routing instance. [PR/578808: This issue has been resolved.] On SRX5800 devices, when a PPTP server used Call ID 0 and SRX did not use NAT, then the Call ID for the GRE packets did not get translated correctly and was ignored by the server. [PR/586702: this issue has been resolved.]
237
Screen
On SRX5800 devices, under certain circumstances, zone screening setting was not applied properly. [PR/569678: This issue has been resolved.]
Security
On SRX Series devices, FTP commands that ended in \n instead of \r\n (carriage return, followed by line feed) were dropped by the FTP ALG. [PR/582714: This issue has been resolved.]
On SRX210 High Memory devices, the forwarding daemon ran out of memory with a large UTM configuration, such as 30,000 objects configured, including 15000 URLs in the blacklist. This caused the forwarding daemon to generate a core file and to stop forwarding. [PR/518490: This issue has been resolved.] On SRX100 High Memory devices, when antispam and antivirus were used in the same UTM policy, spam e-mails were not tagged correctly. [PR/575296: This issue has been resolved.] On SRX650 devices, when express AV is enabled, traffic from the server and client are buffered at the device. Sometimes, the buffer resource ran out because the traffic arrived faster than the buffer resource was released, which resulted in the device detecting an out-of-resource state and taking fallback action. This occurred only if a burst of traffic exceeding 20 MB arrived at the device within a very short duration. [PR/556309]
VPNs
On J2350, J4350, SRX100 Low Memory, and SRX 210 Low Memory devices, the L2 VPN did not come up between provider edge (PE) devices when the devices had different endianness. [PR/547769: This issue has been resolved.] On SRX3600 devices, when using VPN monitor for route-based VPNs, the ST0.x tunnel was not disabled when VPN was down. [PR/ 552369: This issue has been resolved.] On SRX3600 devices, KMD core files were generated after users deleted and readded the VPN configuration. [PR/560932: This issue has been resolved.] On SRX5800 devices, SCEP enrollments incorrectly carried same transaction ID that caused some CA servers to reject SCEP enrollment requests. [PR/565230: This issue has been resolved.] On SRX5800 devices, Layer 2 transparent mode did not allow IPsec passthrough VPN to build. [PR/566160: This issue has been resolved.] New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 136 Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 197
238
Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 239
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. ALG configuration examples in the JUNOS Software Security Configuration Guide incorrectly show policy-based NAT configurations. NAT configurations are now rule-based. In the section "Example: Using NAT and the H.323 ALG to Enable Incoming Calls (CLI)" in the Junos OS Security Configuration Guide, the following text is incorrect: user@host# set security policy from-zone zone1 to-zone zone2 policy zone1_to_zone2 then permit source-nat pool p1 The correct text is as follows: user@host# set security policy from-zone zone1 to-zone zone2 policy zone1_to_zone2 then permit The Feature Support Reference for SRX Series and J Series Devices on page 12, Table 10 for Chassis Cluster Support erroneously states that only SRX100 and SRX210 support the Application Layer Gateways (ALGs) feature. The correct information for this section is: SRX100, SRX210, SRX240, and SRX650 support the Application Layer Gateways (ALGs) feature. In Chapter 9, "Understanding ALG Types," of the Junos OS Security Configuration Guide, an incorrect statement for configuring FTP_NO_GET and FTP_NO_PUT in the FTP ALG has been removed.
Chassis Cluster
The Disabling Switching on SRX100, SRX210, SRX220, and SRX240 Devices Before Enabling Chassis Clustering section of the Junos OS Security Configuration Guide incorrectly states the command to set the root user password. The following set of commands must be used to set the password:
1.
Enter configuration mode.
2. Enter the following commands:
user@host# set system root-authentication plain-text-password
239
This setting is required if a root user password was not set.

user@host# delete vlans user@host# delete interfaces user@host# delete security zones security-zone trust interfaces user@host# delete security zones security-zone untrust interfaces user@host# commit

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
The Services Configuration Statement Hierarchy section in the JUNOS Software CLI Reference refers to the JUNOS Services Interfaces Configuration Guide, which has the following error in the sections Data Size and Configuring the Probe:
The minimum data size required by the UDP timestamp probe is identified as 44 bytes.
The minimum data size required by the UDP timestamp probe is 52 bytes.
In the Example: Configuring an IPsec Phase 2 Proposal (CLI) section of the Junos OS Security Configuration Guide, the second paragraph of the first example states that the SA, . . . terminates after 1800 KB of data pass through it. It should instead say, . . . after 1800 seconds. In the Example: Accommodating End-to-End TCP Communication for J Series Services Routers section of the Junos OS Security Configuration Guide, one CLI command given in the example in both the CLI Quick Configuration and Step-by-Step Procedure is incomplete. The set security flow tcp-mss all-tcp command must be followed by the keyword mss value. Therefore, the CLI example in both cases should read set security flow tcp-mss all-tcp mss 1400. The same error is present in the Example: Setting the Maximum Segment Size for All TCP Sessions for SRX Series Services Gateways (CLI) section. In the Example: Adding and Modifying Custom Policy Applications section of the Junos OS Security Configuration Guide, the following note is incorrect: The timeout value is in minutes. If you do not set it, the timeout value of a custom application is 180 minutes. If you do not want an application to time out, type never. The correct information is as follows: The timeout value is in seconds. If you do not set it, the timeout value of a custom application is 1800 seconds. If you do not want an application to time out, type never.
240
Class of Service
In the Junos OS Interfaces and Routing Configuration Guide and Class of Service Configuration Guide, the Transmit Rate section of the Class of Service Overview chapter incorrectly states that the SRX3600, SRX3800, SRX5600, and SRX5800 Series devices do not support an exact value transmit rate. The correct statement is: The SRX3400, SRX3600, SRX5600, and SRX5800 Series devices do not support an exact value transmit rate.
Flow and Processing

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
Information about secure context and router context has been removed from the JUNOS Software Administration Guide for Security Devices 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 for Security Devices. In the Junos OS Interfaces and Routing Configuration Guide, Table 19: Gigabit Ethernet Quick Configuration Page Summary, contains an error under the Gigabit Ethernet/Fast Ethernet option. The source MAC address filtering is not supported on SRX Series and J Series devices. This is not specified in the table.
In Chapter 13, Performing Software Upgrades and Reboots for the SRX Series Services Gateways, of the Junos OS Administration Guide for Security Devices, the word "install" was duplicated. It has been corrected. In Chapter 38, "Reconnaissance Deterrence," of the Junos OS Security Configuration Guide, the graphics showed the sync check as being done after policy checking, which is incorrect. The graphics have been corrected.
241
Hardware Documentation
The output for the show chassis hardware and show chassis hardware detail commands is incorrectly documented for the Routing Engine field. The following table provides details of the guide, section, incorrect output, and corrected output for these commands.
Correct Value Displayed in the Command Output
Section
SRX100 Hardware Guide Monitoring the SRX100 Services Gateway Chassis Using the CLI Locating the SRX100 Services Gateway Component Serial Number and Agency Labels SRX210 Hardware Guide Monitoring the SRX210 Services Gateway Chassis Using the CLI
Incorrect Value in the Hardware Guide
RE-SRX100-HM
RE-SRX100H
RE-SRX100-HIGHMEM
RE-SRX100H
RE-SRX210-LOWMEM RE-SRX210-VOICE
RE-SRX210B RE-SRX210H-P-M RE-SRX210B
Locating the SRX210 Services Gateway Component Serial Number and Agency Labels SRX240 Hardware Guide Monitoring the SRX240 Services Gateway Chassis Using the CLI Locating the SRX240 Services Gateway Component Serial Number and Agency Labels
RE-SRX210-LOWMEM
RE-SRX240-LM
RE-SRX240B
RE-SRX240-POE
RE-SRX240H-POE
The DOCSIS Mini-Physical Interface Module chapter in the SRX Series Services Gateways for the Branch Physical Interface Modules Hardware Guide erroneously states that the EuroDOCSIS 3.0 and DOCSIS J (Japan) models of the DOCSIS Mini-PIM are supported. The guide should state that only the DOCSIS 3.0 US model of the DOCSIS Mini-PIM is supported.
The SRX Series Services Gateways for the Branch Physical Interface Modules Hardware Guide erroneously lists the maximum MTU (bytes) for the Serial Mini-PIM as 1504. The correct value for this section is 2000. The Understanding Built-In Ethernet Ports section in the SRX100, SRX210, and SRX240 Hardware Guides erroneously states the following:
242
The services gateway acts as a DHCP client out of the built-in Ethernet ports. If the services gateway does not find a DHCP server within a few seconds, the device acts as a DHCP server and assigns an IP address as 192.168.1.1/24. With the device temporarily acting as a DHCP server, you can manually configure it with the J-Web interface. The correct information for this section is:
For the SRX100 Services Gateway Hardware Guide: The services gateway acts as a DHCP client on port fe-0/0/0, and ports fe-0/0/1 to fe-0/0/7 act as DHCP server. For the SRX210 Services Gateway Hardware Guide: The services gateway acts as a DHCP client on port ge-0/0/0, and ports ge-0/0/1 and fe-0/0/2 to fe-0/0/7 act as DHCP server. For the SRX240 Services Gateway Hardware Guide: The services gateway acts as a DHCP client on port ge-0/0/0, and ports ge-0/0/1 to ge-0/0/15 act as DHCP server.
The Upgrading the SRX100 Services Gateway Low Memory Version to a High Memory section in the SRX100 Services Gateway Hardware Guide should also state the following information:
The SRX100 Services Gateway High Memory model is shipped with the license key.
The SRX240 Services Gateway (High Memory with DC Power Supply Model) Compliance Statements for Network Equipment Building System (NEBS) topic in the SRX240 Services Gateway Hardware Guide incorrectly states that the battery return connection is to be treated as a Common DC return (DC-C), as defined in GR-1089-CORE. The guide should state that the battery return connection is to be treated as an Isolated DC return (DC-I), as defined in GR-1089-CORE.
The following SRX Series Quick Start Guides erroneously provide an IP address of 192.168.1/24 in the Part 4: Ensure That the Management Device Acquires an IP Address section:

SRX100 Services Gateway Quick Start Guide SRX210 Services Gateway Quick Start Guide SRX240 Services Gateway Quick Start Guide
The correct IP address in this section is 192.168.1.0/24.
Chapter 2, SRX650 Services Gateway Hardware Components and Specifications, in the SRX650 Services Gateway Hardware Guide has the following errors:
The CompactFlash card supported by the services gateway is identified as STEC 1 GB. This is incorrect: both STEC 1 GB and STEC 2 GB cards are supported.
243
The USB device supported by the services gateway is identified as Sandisk Micro Cruzer 1 GB. This is incorrect: both Sandisk Micro Cruzer 1 GB and Micro Cruzer 2 GB devices are supported.
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 SRX240 Hardware Guide is missing information about the following statements/data:
The SRX240 Services Gateway Site Electrical Wiring Guidelines topic should include the following statement: For devices with AC power supplies, an external surge protective device (SPD) must be used at the AC power source.
The General Electrical Safety Guidelines and Warnings topic should include the following statements:
WARNING: Use copper conductors only.

Waarschuwing Gebruik alleen koperen geleiders. Varoitus Kyt vain kuparijohtimia. Attention Utilisez uniquement des conducteurs en cuivre. Warnung Verwenden Sie ausschlielich Kupferleiter. Avvertenza Usate unicamente dei conduttori di rame. Advarsel Bruk bare kobberledninger. Aviso Utilize apenas fios condutores de cobre. Atencin! Emplee slo conductores de cobre. Varning! Anvnd endast ledare av koppar.
The Grounding the SRX240 Services Gateway section should list the following as tools and parts required for grounding the SRX240 device:
Grounding cable for your deviceThe grounding cable must be minimum 14 AWG (2 mm), minimum 90C wire, or as permitted by the local code. Grounding lugRing-type, vinyl-insulated TV14-6R lug or equivalent for your grounding cable. Washers and 10-32x.25-in. screws to secure the grounding lug to the protective earthing terminal Phillips (+) screwdrivers, number 1 and number 2
The Grounding the SRX240 Services Gateway section should include the following information in the grounding instructions step:
244
Step 6 - Secure the grounding cable lug to the grounding point with the screw. Apply between 6 lb-in. (0.67 Nm) and 8 lb-in. (0.9 Nm) of torque to the screws.
The SRX240 Services Gateway Installation Safety Guidelines and Warnings section should specify that the SRX240 Services Gateway can be installed as customer premises equipment (CPE) only. The SRX240 Services Gateway (High Memory with DC Power Supply Model) Compliance Statements for Network Equipment Building System (NEBS) section should specify the following statement: The battery return connection is to be treated as an Isolated DC return (DC-I), as defined in GR-1089-CORE.
The SRX240 Services Gateway Installation Instructions Warning section in Appendix SRX240 Services Gateway Installation Safety Guidelines and Warnings should specify the following statements:
Before you make any crimp connections, coat all conductors (frame ground, battery, and battery return) with an appropriate antioxidant compound. Before you connect unplated connectors, braided strap, and bus bars, bring them to a bright finish and coat them with an antioxidant compound. You do not have to prepare tinned, solder-plated, or silver-plated connectors or other plated connection surfaces before connecting them, but make sure such surfaces remain clean and free of contaminants. To provide a permanent low-impedance path, tighten all raceway fittings. An electrical conducting path shall exist between the device chassis and the grounding conductor, or between the chassis and the metal surface of the enclosure or rack in which the device is mounted. Electrical continuity shall be provided by the use of thread-forming-type, unit-mounting screws that remove any paint or nonconductive coatings and establish metal-to-metal contact. Any paint or other nonconductive coatings shall be removed on the surfaces between the mounting hardware and the enclosure or rack. The surfaces shall be cleaned and an antioxidant applied before installation.
The following tables list the changes in the factory default settings on the SRX210 Services Gateway with Integrated Convergence Services and the SRX240 Services Gateway with Integrated Convergence Services.
Table 16: Factory Default Settings for the Voice Ports

Port Label Interface Extension Station/Trunk Name
SRX210 Services Gateway with Integrated Convergence Services FXS1 FXS2 FXO1 FXO2 fxs-0/0/10 fxs-0/0/11 fxs-0/0/12 fxs-0/0/13 3001 3002 3001 3002 fxo1 fxo2
245
Table 16: Factory Default Settings for the Voice Ports (continued)
Port Label Interface Extension Station/Trunk Name
SRX240 Services Gateway with Integrated Convergence Services FXS1 FXS2 FXO1 FXO2 fxs-0/0/17 fxs-0/0/18 fxs-0/0/19 fxs-0/0/20 3001 3002 3001 3002 fxo1 fxo2
Table 17: Factory Default Settings for the Dial Plan on the Services Gateways
Call Pattern
911 1XXXXXXXXXX XXXXXXX 011. 1900.
Call Type
Emergency Long distance Local International 900 number
Call Type Name

emergency-call long-distance-call local-call international-call 900-number
Table 18: Factory Default Settings for the Class of Restriction on the Services Gateways
Call Pattern
Allow
Call Type
Intrabranch Local Long distance Emergency
Deny
International 900 number
246
Table 19: Factory Default Settings for SIP and Analog Stations on the Services Gateways
By default, templates are available for both SIP and analog stations. For SIP stations, the extension range is 5001 through 5016.
Table 20: Factory Default Settings for Trunk Groups

By default, the branch trunk group includes both the FXO ports. The trunks, fxo1 and fxo2, are part of the Branch_Trunk_Group.
In the SRX210 Services Gateway Quick Start Guide and the SRX240 Services Gateway Quick Start Guide, in the Configure the Class of Restriction section, the document erroneously states that only intrabranch calls and emergency calls are allowed by default. From Junos OS Release 10.1 onward, by default, the device allows intrabranch, local, emergency, and long distance calls. International and 900 calls are denied by default. In the SRX210 Services Gateway Quick Start Guide and the SRX240 Services Gateway Quick Start Guide, the Configure the Analog Station section mentions that you can select the already defined analog template. In addition, from Junos OS Release 10.1 onward, default extensions are also configured for the two onboard FXS ports. In the SRX210 Services Gateway Quick Start Guide and the SRX240 Services Gateway Quick Start Guide, the Configure a Trunk section mentions that you can select the trunk type as FXO, FXS, or T1. In addition, in Junos OS Release 10.1, the two onboard FXO ports are configured as part of a default group called the branch trunk group, which will enable you to make calls using the FXO trunk ports.
Installing Software Packages
The current SRX210 documentation does not include the following information: On SRX210 devices, the /var hierarchy is hosted in a separate partition (instead of the root partition). If JUNOS Software installation fails as a result of insufficient space:
1.
Use the request system storage cleanup command to delete temporary files.
2. Delete any user-created files in both the root partition and under the /var hierarchy.
The JUNOS Software Integrated Convergence Services Configuration and Administration Guide does not include show commands for JUNOS Release 10.2. 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.2. However, it is documented in the Integrated Convergence Services entries of the JUNOS Software CLI Reference.
247
The JUNOS Software CLI Reference contains Integrated Convergence Services statement entries for the music-on-hold feature, which is not supported for JUNOS Release 10.2. On SRX210 devices with Integrated Convergence Services, users cannot clone the existing configuration for Integrated Convergence Services. The clone option has been removed from all Convergence Services pages on J-Web.
The ADSL2+ and ADSL2+ Annex M upstream values given in the JUNOS Software Interfaces Configuration Guide for Security Devices are displayed incorrectly. The correct values are as follows:
Table 21: Standard Bandwidths of DSL Operating Modes

Operating Modes
ADSL2+ ADSL2+ Annex M
Upstream Values
11.5 Mbps 2.53 Mbps
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 and the JUNOS Software Security Configuration Guide state that the maximum acceptable range for the timeout (IDP Policy) is 0 to 65,535 seconds, whereas the ip-action timeout range has been modified to 0 to 64,800 seconds. The JUNOS Software CLI Reference and the JUNOS Software Security Configuration Guide are 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, the signature is automatically updated after the download. If the download takes longer than download timeout, the auto signature update is aborted.
user@host# set security idp security-package automatic download-timeout ? Possible completions: < download-timeout > Maximum time for download to complete (1 - 60 minutes) [edit] user@host# set security idp security-package automatic download-timeout Range: 1 60 seconds Default: 1 second
The JUNOS Software CLI Reference incorrectly states the show security idp status and clear security idp status logs. The logs should be as follows:
Correct show security idp status log

user@host> show security idp status
248
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.
JUNOS Software Interfaces and Routing Guide

The JUNOS Software Interfaces and Routing Guide has been divided into five smaller guides in order to make it easier to find information:

JUNOS Software Class of Service Configuration Guide for Security Devices JUNOS Software Interfaces Configuration Guide for Security Devices JUNOS Software Layer 2 Bridging and Switching Configuration Guide for Security Devices JUNOS Software MPLS Configuration Guide for Security Devices JUNOS Software Routing Protocols and Policies Configuration Guide for Security Devices
For the convenience of users who are familiar with the previous guides format, the original JUNOS Software Interface and Routing Guide, which contains all of the same information as the five new guides listed above, is also still available.
249
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, and select IPv4 Firewall Filters or IPv6 Firewall Filters. After configuring filters, select Assign to Interfaces to assign your configured filters to interfaces. There is no documentation describing the J-Web pages for media gateways. To find these pages in J-Web, go to Monitor>Media Gateway.
The following information pertains to SRX Series devices:
Single Commit on J-Web For all J-Web procedures, follow these instructions to commit a configuration:

If Commit Preference is Validate and commit configuration changes, click OK. If Commit Preference is Validate configuration changes, click OK to check your configuration and save it as a candidate configuration, and then click Commit Options>Commit.
Management Information Base (MIB)
The MIBs guide currently states the following: Network Address Translation (NAT) Objects MIB provides support for monitoring network address translation (NAT). This MIB is currently supported only by JUNOS Software for J Series and SRX Series devices. For a downloadable version of this MIB, see http://www.juniper.net/techpubs/en_US/junos9.6/information-products/ topic-collections/config-guide-network-mgm/mib-jnx-js-nat.txt. This is applicable only from Junos Release 10.2 and later and not earlier releases.
In the Junos OS Security Configuration Guide, the Using NAT and the H.323 ALG to Enable Incoming Calls example uses the old NAT version. The example has been revised to use the new NAT version in Junos OS Release 10.4. In the Junos OS Security Configuration Guide, the Configuring Static NAT for Incoming SIP Calls example is incorrect. The example has been corrected in Junos OS Release 10.4.
250
Hardware Requirements for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
Point-to-Point Protocol
The Junos OS Interfaces Configuration Guide for Security Devices incorrectly states that the following protocols are supported in Point-to-Point Protocol(PPP) Network Control Protocols (NCPs). These protocols are not supported:

BCP151: Bridging Control Protocol BVCP151: Banyan Vines Control Protocol DNCP151: DECnet Phase IV Control Protocol IPXCP151: Novell IPX Control Protocol LECP151: LAN Extension Control Protocol NBFCP151: NetBIOS Frames Control Protocol SDTP151: Serial Data Transport Protocol SNACP151: Systems Network Architecture (SNA) Control Protocol XNSCP151: Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) Control Protocol
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.
New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 136 Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 197 Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211

Transceiver Compatibility for SRX Series and J Series Devices on page 252 Power and Heat Dissipation Requirements for J Series PIMs on page 252
251
Supported Third-Party Hardware on page 252 J Series CompactFlash and Memory Requirements on page 253
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 others) can be used together on multiport SFP interface modules as long as they are provided by Juniper Networks. We cannot guarantee that the interface module will operate correctly if third-party transceivers are used. Please contact Juniper Networks for the correct transceiver part number for your device.
Power and Heat Dissipation Requirements for J Series PIMs

On J Series Services Routers, the system monitors the PIMs and verifies that the PIMs fall within the power and heat dissipation capacity of the chassis. If power management is enabled and the capacity is exceeded, the system prevents one or more of the PIMs from becoming active.
CAUTION: Disabling the 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 for troubleshooting procedures, see the J Series Services Routers Hardware Guide.
Supported Third-Party Hardware

The following third-party hardware is supported for use with J Series Services Routers running Junos OS.
USB Modem We recommend using a U.S. Robotics USB 56K V.92 Modem, model number USR 5637.
Storage Devices The USB slots on J Series Services Routers accept a USB storage device or USB storage device adapter with a CompactFlash card installed, as defined in the CompactFlash Specification published by the CompactFlash Association. When the USB device is installed and configured, it automatically acts as a secondary boot device if the 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 22 on page 253 lists the USB and CompactFlash card devices supported for use with the J Series Services Routers.
252
Table 22: 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 SanDisk CompactFlash SanDisk CompactFlash
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
512 MB 1 GB
SDCFB-512-455 SDCFB-1000.A10
J Series CompactFlash and Memory Requirements

Table 23 on page 253 lists the CompactFlash card and DRAM requirements for J Series Services Routers.
Table 23: J Series CompactFlash Card and DRAM Requirements

Model
J2320 J2350 J4350 J6350
Minimum CompactFlash Card Required

1 GB 1 GB 1 GB 1 GB
Minimum DRAM Required

1 GB 1 GB 1 GB 1 GB
Maximum DRAM Supported

1 GB 1 GB 2 GB 2 GB
New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 136 Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 197 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 175 Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 211
253
Upgrade and Downgrade Instructions for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 256 Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers on page 239
Stream Control Transmission Protocol Overview

Stream Control Transmission Protocol (SCTP) is an IP Transport Layer protocol. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP and supports data transfer across the network in single-IP or multi-IP cases. SCTP provides the following services:

Aggregate Server Access Protocol (ASAP) Bearer Independent Call Control (BICC) Direct Data Placement Segment chunk (DDP-segment) Direct Data Placement Stream session control (DDP-stream) DPNSS/DASS 2 extensions to IUA Protocol (DUA) Endpoint Handleescape Redundancy Protocol (ENRP) H.248 Protocol (H248) H.323 Protocol (H323) ISDN User Adaptation Layer (IUA) MTP2 User Peer-to-Peer Adaptation Layer (M2PA) MTP2 User Adaptation Layer (M2UA) MTP3 User Adaptation Layer (M3UA) Q.IPC Reserved Simple Middlebox Configuration (SIMCO) SCCP User Adaptation Layer (SUA) Transport Adapter Layer Interface (TALI) v5.2 User Adaptation Layer (V5UA)
SCTP can transport signaling messages to and from Signaling System 7 (SS7) for 3G mobile network through M3UA, M2UA or SUA. SCTP is a packet-based transport protocol. SCTP provides reliable and secure transport, minimized end-to-end delay, short failover time in case of network failures, and both sequence and no-sequence transport.
Configuration Overview
You should configure at least one SCTP profile to enable the security device to perform stateful inspection on all SCTP traffic. The stateful inspection of SCTP traffic will drop some anomalous SCTP packets. The SCTP firewall supports deeper inspection:
254
Maximizing ALG Sessions
Packet filteringThe profile configuration of drop packets for special SCTP payload protocol and M3UA service enables packet filtering. Limit-rateControls the packets rate of SCCP in M3UA service.
The SCTP deeper inspection requires the following:

Creating an SCTP profile Configuring the filtering and limit parameters Binding the SCTP profile to a policy
NOTE: The policy should permit SCTP traffic.
For detailed information about the configuration commands, see the JUNOS Software CLI Reference.
Maximizing ALG Sessions

On SRX3400, SRX3600, SRX5600, and SRX5800 devices, by default, the session capacity number for RTSP, FTP, and TFTP ALG sessions is 10,000 per flow SPU. The maximize-alg-sessions option enables you to increase defaults as follows:

RTSP, FTP, and TFTP ALG session capacity: 25,000 sessions per flow SPU TCP Proxy connection capacity: 40,000 sessions per flow SPU
NOTE: Flow session capacity will be reduced to half per flow SPU, and the above capacity numbers will not change on the central point SPU.
255
You can configure maximum ALG sessions as follows:

security { forwarding-process { application-services { maximize-alg-sessions; } } }
You must reboot the device (and its peer in the chassis cluster) for the configuration to take effect.
Upgrade and Downgrade Instructions for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
In order to upgrade to JUNOS Release 10.2 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.2 release. For example, to upgrade from Release 9.2R1, first upgrade to Release 9.2R4 and then upgrade to Release 10.2. For additional upgrade and download information, see the JUNOS Software Administration Guide for Security Devices and the JUNOS Software Migration Guide.
Upgrade Policy for JUNOS Software Extended End Of Life Releases on page 256
Upgrade Policy for JUNOS Software Extended End Of Life Releases

A direct upgrade and downgrade path is now available for JUNOS Software Extended End of Life (EEOL) releases. You can upgrade directly from one EEOL release to the next release even though EEOL releases frequently occur in increments beyond three releases. The current upgrade and downgrade policy for a non-EEOL release is that you can only upgrade and downgrade by up to three releases at a time. The +3 policy remains unchanged for non-EEOL releases but includes a direct upgrade and downgrade path for EEOL to next EEOL releases It is important to note that you can only upgrade or downgrade to the EEOL release that occurs directly before or after the currently installed EEOL release. For example, JUNOS Software Releases 8.5, 9.3, and 10.0 are EEOL releases. You can only upgrade from JUNOS Software release 8.5 to JUNOS Software Release 10.0 by first upgrading to JUNOS Software Release 9.3. This policy also applies to downgrades where you cannot skip an EEOL release but must target the EEOL release occurring directly before the currently installed EEOL release.
256
JUNOS Software Release Notes for EX Series Switches
For more information on EEOL releases and to review a list of EEOL releases, see
http://www.juniper.net/support/eol/junos.html
JUNOS Software Release Notes for EX Series Switches

New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278
New Features in JUNOS Release 10.2 for EX Series Switches

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

Hardware on page 257 Access Control and Port Security on page 258 Bridging, VLANs, and Spanning Trees on page 259 Class of Service (CoS) on page 259 Infrastructure on page 259 Layer 2 and Layer 3 Protocols on page 260 Management and RMON on page 260 Packet Filters on page 260
Hardware
EX4500 switchesEX4500 switches provide high performance, scalable connectivity, and carrier-class reliability for high-density environments such as campus aggregation, branch offices, and data-center networks. EX4500 switches support the following optical transceivers:

EX-SFP-1GE-T (1000Base-T, 100 m) EX-SFP-1GE-LX (1000Base-LX, 10 km) EX-SFP-10GE-USR (10GBase-SR, 10 m, 30 m, 100 m)
257
EX-SFP-10GE-SR (10GBase-SR, 26 m, 33 m, 66 m, 82 m, 300m) EX-SFP-10GE-LR (10GBase-LR, 10 km )
Support for a new optical transceiver on EX3200 and EX4200 switchesThe SFP+ uplink module in EX3200 and EX4200 switches now supports one new optical transceiver: EX-SFP-10GE-USR (10GBase-SR, 10 m, 30 m, and 100 m). Support for new optical transceivers on EX8200 switchesEX8200 switches now support the following new optical transceivers:
The 8-port SFP+ line cards for EX8200 switches now support one new optical transceiver: EX-SFP-10GE-USR (10GBase-SR, 10 m, 30 m, and 100 m). The 48-port SFP line cards for EX8200 switches now support three new optical transceivers: EX-SFP-1FE-LX (100Base-LX, 10 km), EX-SFP-1FE-LX40K (100Base-LX40K, 40 km), and EX-SFP-1FE-LH (100Base-LH, 80 km).
Access Control and Port Security
Support for 802.1X authentication on EX8200 switches802.1X authentication provides network edge security by blocking access of devices attempting to connect to the LAN until their credentials are presented and matched on the authentication server (a RADIUS server). Support for 802.1X is the same on EX8200 switches as on other EX Series switches, with the exception of interfaces configured in multiple-supplicant or single-secure mode. The following configurations are not supported on EX8200 switches on interfaces in multiple-supplicant or single-secure mode:
Guest VLANSProvides secure access to the LAN for corporate guests and for devices that fail the 802.1X authentication process. Server-reject VLANsSpecifies that when the switch receives an Extensible Authentication Protocol Over LAN (EAPOL) Access-Reject message from the RADIUS authentication server, then devices attempting to access the LAN are moved to a specific VLAN and granted access.
258
New Features in JUNOS Release 10.2 for EX Series Switches
Server fail fallbackAllows you to specify how 802.1X supplicants (hosts) connected to the switch are supported if the RADIUS authentication server becomes unavailable or sends an EAPOL Access-Reject message.
Bridging, VLANs, and Spanning Trees
RSTP configuration with VSTPVSTP and RSTP can now be configured concurrently. When VSTP and RSTP are configured concurrently, the first 253 VLANs are configured with VSTP and the remaining VLANs are configured using RSTP. This feature allows users to overcome a previous restriction that only allowed VSTP to run on up to 253 VLANs while no other spanning-tree protocols could run on the additional VLANs. RSTP and VSTP are the only spanning-tree protocols that can be configured concurrently on an EX Series switch.
Class of Service (CoS)
Enhancements to CoS rewrite rules on EX8200 switchesThe following enhancements have been made to CoS rewrite rules on EX8200 switches:

Rewrite rules based on multifield (MF) classifiers are now supported. Rewrite rules can now be assigned to Layer 2 interfaces, in addition to the previously supported Layer 3 interfaces and routed VLAN interfaces (RVIs). Rewrite rules are now supported for switched packets. Each interface can have different rewrite rules. You are no longer limited to a single global rewrite rule for all interfaces on the switch.
Interface-specific IPv6 classifiers and rewrite rulesEX3200 and EX4200 switches now allow you to configure and apply IPv6 classifiers and rewrite rules for each interface.
Infrastructure
Enhancements to power management on EX8200 switchesPower management on EX8200 switches now allows you to configure certain aspects of its power budget policy, which determines how it manages the power supplies and allocates power to various components. You can:
Configure power management to manage the power supplies for N+N power redundancy instead of N+1 redundancy. Assign a power priority to line cards. This allows higher priority cards to receive power when power is insufficient to power all line cards. Previously, when power was insufficient, all line cards were powered off. Now line cards receive power in priority order until available power is exhausted.
Distributed Periodic Packet Management (PPM) Link Aggregation Control Protocol (LACP) supportThe responsibility for PPM processing of LACP traffic on an EX Series switch is now distributed between the Routing Engine and either the access interfaces (on EX3200 and EX4200 switches) or the line cards (on EX8200 switches) by default. PPM previously ran solely on the Routing Engine. We recommend that you disable
259
distributed PPM and run PPM just on the Routing Engine only if there is a compelling reason to disable distributed PPM.
Enhancements to LCD menusUsing CLI commands, administrators can disable the Status menu, the Maintenance menu, and the options in these menus to prevent users from viewing certain details about the switch and from configuring and troubleshooting the switch from the LCD menu. IPv6 path maximum transmission unit discoveryThe IPv6 path maximum transmission unit (MTU) discovery feature is now available on EX8200 switches.
Layer 2 and Layer 3 Protocols
IPv6 Layer 3 multicast routing and forwardingEX8200 switches now support IPv6 Layer 3 multicast routing and forwarding (PIM, MLDv1/v2). IPv6 virtual routing and forwarding (VRF) multicastIPv6 multicast traffic is now supported for VRF on EX3200, EX4200, and EX8200 switches.
Management and RMON
802.1ag OAM support on EX3200 and EX4200 switches802.1ag is an IEEE standard for connectivity fault management (CFM). The following features are supported: continuity check protocol, linktrace protocol, and loopback protocols. sFlow enhancements on EX Series switchesYou can configure the IP address to be assigned to the sFlow agent and the IP address to be used in sFlow datagrams. By configuring the IP addresses, you can ensure that the IP addresses are not dynamic and do not change when the switch restarts.
Packet Filters
Enhancements to firewall filter actions supported on EX8200 switchesThe log, reject, and syslog actions are now supported for ingress firewall filters on EX8200 switches. The reject action is supported on Layer 3 interfaces (router firewall filters) only. Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278
260
Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches
Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches
The following changes in 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.
The following enhancements have been made to the show lldp commands:
The show lldp local-information command now includes information about the local management address and type. The show lldp neighbors command now includes the ageout count, which is the number of times the neighbor information has been deleted from the LLDP information maintained by the local system because the information timeliness interval has expired. The show lldp, show lldp local-information, show lldp neighbors, and show lldp statistics commands now display the parent aggregated Ethernet interface, if any, to which a local interface belongs.
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. As a result of the enhancements to power management in JUNOS Release 10.2, a line card that has been taken offline is not automatically brought online when you commit a configuration, as was true in previous releases. When a line card is taken offline, power management no longer allocates power to the line card. To bring a line card online, you must explicitly bring the line card online with the request chassis fpc slot slot-number online command or with the set chassis fpc slot-number power on command.
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.
User Interfaces and Configuration
On EX3200 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 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.
261
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 to explicitly disable PIM on the management interfaces. Previously, enabling PIM on all interfaces caused it to be enabled on these management interfaces. New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278
Limitations in JUNOS Release 10.2 for EX Series Switches

This section lists the limitations in JUNOS Release 10.2R4 for EX Series switches.
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. The RADIUS request sent by an EX Series switch contains both Extensible Authentication Protocol (EAP) Identity Response and State attributes. 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. On EX2200, EX3200, and EX4200 switches, deleting a static MAC address entry from the Ethernet switching table does not change the authentication status for the interface in the 802.1X table with MAC RADIUS, and the interface remains authenticated. On EX Series switches, configuring 802.1X (dot1x) might generate a core file when VLANs are being configured.
There might be traffic loss on VLANs learned through MVRP during a graceful Routing Engine switchover (GRES) operation. After the GRES operation, there will be no traffic loss. On EX Series switches, configuring more than 64,000 MAC address clone routes in a single VLAN causes the Routing Engine to create core files and reboot. If you modify MSTP configuration and VLAN membership for an interface, that modification could result in inconsistent MSTP membership for that interface. As a
262
workaround, restart the Ethernet switching process (eswd) after making these configuration changes.
If you configure BPDU block functionality on all interfaces and then disable the spanning-tree protocol, the BPDU block functionality might not work.
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 Kbps, even when the shaping rate configured is less than 500 Kbps. The minimum shaping rate is 500 Kbps. 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.
Firewall Filters
On EX3200 and EX4200 switches, when interface ranges or VLAN ranges are used in configuring firewall filters, egress firewall filter rules take more than 5 minutes to install. On EX3200 and EX4200 switches, IGMP packets are not matched by user-configured firewall filters.
Hardware
On EX4500 switches, when you hot-remove an SFP+ transceiver and hot-insert an SFP-T transceiver in the same port, the following messages are logged in the system log at 30-second intervals:
link 1 SFP receive power low warning cleared warning setlink 1 SFP receive power low
These messages are harmless.
After you have disabled an interface on an EX2200 switch, the LED is still lit on that interface.
263
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. 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. 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. 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). 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. On EX Series switches, the JUNOS CLI does not auto-complete the options for allow-commands in the system login class configuration, when some regular expressions are used in the allow-commands configuration. 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. On EX8200 switches, when a firewall filter is applied on the loopback (lo0) interface, the switch stops generating local ARP requests for transit traffic. As a workaround, you can do the following:
Create firewall filters to block known unwanted traffic to the Routing Engine, and then accept all other traffic. Create firewall filters for specific hosts and all local subnets, and then discard all other traffic.
On EX2200 switches, the Routing Engine shows 16,000 active routes, but only half of them are installed in the Packet Forwarding Engine. On EX8200 switches, after enabling graceful Routing Engine switchover (GRES), you might not be able to connect to the management interface on the backup Routing Engine using Telnet, and an existing Telnet session with the management interface on the backup Routing Engine might become inactive. [PR/520966] On EX4500 switches, the following message appears in the system log whenever the uplink modules are taken offline:
264
fpc0 539:Port-STG-Set failed(Invalid Params:-2)
When you issue a traceroute command for a nonexistent IP address, an EX Series switch that is the first hop from the source address might not respond. On EX4500 switches, the show chassis environment power-supply-unit command does not display values for the input voltage, the output voltage, and the output current. On EX8200 switches, packets with unregistered Layer 2 multicast MAC addresses are not dropped on interfaces that are in the STP blocked state, resulting in some traffic loops that might impact network performance. When you include wildcards in a routing policy filter that also includes Classless Interdomain Routing (CIDR) addresses or that maps IPv4 addresses to IPv6 addresses, the forwarding process (pfem) might stop operating. If a Routing Engine fails over to the backup Routing Engine, not all multicast groups that were active on the switch recover. On EX4200 switches, autonegotiation bypass, which allows a link in a Gigabit Ethernet SFP uplink port to begin operation even if autonegotiation on the link partner is disabled, fails to bring up the link.
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 an 802.1Q (dot1q) 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 (RVIs): 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 interfaces interface-name detail | extensive command might display double counting of packets or bytes for the transit statistics and traffic statistics counters.
265
You can use the counter information displayed under the Physical interface section of the output.
On EX8200 switches, the following message is logged frequently in the /var/log/mastership file:
mcontrol_refresh_mastership: time 6
These messages are harmless.
On EX4500 switches, the show chassis lcd and show chassis led command outputs do not display the details of the uplink module ports and show all network ports as ge- interfaces even though some ports are 10-Gigabit Ethernet interfaces.
J-Web Interface
In the J-Web interface, the autocompletion feature might not be disabled in the password field. As a workaround, disable the autocompletion feature in the browser. In the J-Web interface, when you use the point-and-click configuration editor to change the configuration and if you have made configuration changes simultaneously using the CLI, committing the configuration from the J-Web interface might fail. When you open a J-Web session using HTTPS, then enter a username and password and click on the Login button, the J-Web interface takes 20 seconds longer to launch and load the Dashboard page than it does if you use HTTP.
On EX3200 and EX4200 switches, IPv6 ping is not supported for more than 64 virtual routing and forwarding (VRF) addresses. On EX Series switches, an OSPF bfd-liveness-detection timer must not be set to less than 1 second. On EX4200 switches, if you have configured a maximum transmission unit (MTU) value on a logical interface and the route information for an inactive route on the interface changes, traffic loss might occur for a few seconds. IGMP snooping is not supported on a VLAN that includes a routed VLAN interface (RVI) that is configured as part of a virtual routing instance.
Management and RMON
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. sFlow technology might not work when you apply a firewall filter to the loopback (lo0) interface.
266
Outstanding Issues in JUNOS Release 10.2 for EX Series Switches
Virtual Chassis
On EX4200 switches, the factory default configuration does not set the configuration required for preprovisioning for a Virtual Chassis, making the set system commit factory-settings reset-virtual-chassis-configuration command unavailable after the switch is reset to the factory default configuration. As a workaround, delete the junos.conf* files from the config directory and reset the switch to the factory default configuration. On an EX4200 Virtual Chassis, an automatic software update fails if you have configured preprovisioning or mastership priority. New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278

The following are outstanding issues in JUNOS Release 10.2R4 for EX Series switches. The identifier following the description is the tracking number in our bug database.
NOTE: Other software issues that are common to both EX Series switches and M, MX, and T Series routers are listed in Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63.
On EX Series switches, when you enable and disable IPv6 on the management interface (me0), the management information is not displayed in the show lldp local-information command output. [PR/503955] When DHCP snooping is enabled, after an IP address is dynamically assigned to a device, when the device sends DHCPINFORM packets to obtain other DHCP parameters, the switch blocks these packets. [PR/580068] When the username for 802.1X (dot1x) authentication is longer than 50 characters, the Junos Software truncates the username field. [PR/588063]
267
If you change the VLAN ID on the switch using VSTP, the show spanning-tree bridge command lists an incorrect root bridge. [PR/512715] The word switching is misspelled in the CLI help for the interfaces statement at the [edit ethernet-switching-options] hierarchy level. [PR/525185] On EX8200 switches, STP rate limiting might cause traffic and STP BPDUs to be dropped during a traffic burst. [PR/529563] The output of the show ethernet-switching interfaces command might display a negative value, and this value might continue to increase. [PR/531416] IGMP reports might not be processed by the switch if a multicast group is also sourced on the same port as the IGMP reports. To have the switch process these reports, configure IGMP snooping. [PR/546223] When the Virtual Chassis backup switch is rebooted, a redundant trunk group (RTG) failover might occur incorrectly, with the RTG from the Virtual Chassis master primary link erroneously switching to the secondary link of the Virtual Chassis backup. [PR/562398]
Class of Service
On EX3200 and EX4200 switches, the show interface queue command output displays the count of transmitted packets and queued packets together under the field Queued instead of displaying the values under Queued and Transmitted fields. [PR/259525]
Firewall Filters
On EX4200 switches, if you configure a firewall filter with the match condition tcp-established, the error message not supported is displayed although the match condition is actually supported. [PR/543316]
Hardware
EX8200 switches might not detect the front-panel LCD display. [PR/553144]
Infrastructure
On EX4200 switches on which GRES is enabled, when a backup member switch has a route to a destination whose egress member is on the backup member itself, packets generated on the backup member egress out of the switch. [PR/506119] The request system zeroize command does not erase the log files and delete the existing configuration. [PR/511216] On EX Series switches, the dot1qPvid object is populated only when STP or RSTP is configured. [PR/530603] The show chassis routing-engine command erroneously shows an uptime of 14,700 days. [PR/537224]
268
On EX Series switches, if you configure the interface hold time to be more than 65,535 ms, the hold time does not work. [PR/537477] On EX Series switches, the Ethernet switching process (eswd) might restart, placing the following message in the syslog file "%AUTH-3: ethernet-switching (PID 7550) terminated by signal number 11. Core dumped!" [PR/538052] If no intraconnect module or Virtual Chassis module is installed in an EX4500 switch, the switch boots but is not fully functional. Traffic loss might occur during packet forwarding. [PR/544628] On EX4200 switches, spurious packets (packets with unsupported fields) arriving at the backup Routing Engine while a GRES operation is in progress can cause a kernel crash (vmcore). [PR/546314] On EX4500 switches, the LCD panels maintenance menu is not disabled even if you include the lcd maintenance-menu disable statement in the [edit chassis] hierarchy of the configuration. [PR/551546] When you are configuring the switch in private mode and delete an interface from an interface-range configuration and then reconfigure the interface, the configuration commit fails. [PR/565620] On EX Series switches, an IS-IS link configured with a point-to-point interface type does not work. [PR/566759] During the TFTP transfer portion of an automatic software download procedure, the software package might be truncated or corrupted. [PR/570901] On EX Series switches on which the last term in a loopback firewall filter is either an implicit deny-all or explicit deny-all, received packets whose TTL is exceeded are dropped instead of being processed by the CPU. Thus, for example, traceroute packets received with a TTL of 0 are dropped, and ICMP unreachable packets are not sent back. [PR/573170] When you upgrade an EX Series switch whose configuration contains a firewall filter that includes only non-contiguous masks in the term's match condition, the switch might fail to start and you might see a Packet Forwarding Engine (pfem) core file. As a workaround, do not configure only non-contiguous masks. [PR/598333] When a backup router is configured and you initiate a graceful Routing Engine switchover (GRES) operation from the master router, the master router reboots and a vmcore file is created. [PR/599351]
Interfaces
On EX8200 switches, the routing protocol process (rpd) creates core files when the memory used by the rpd exceeds 524,288 KB. [PR/511416] On EX4200 switches, SFP-T (1-gigabit copper) transceivers installed on port 0 or port 2 of an SFP+ uplink module might not work correctly even though the interface link status is up. As a workaround, install the SFP-T transceivers on port 1 or port 3 of the uplink module. [PR/569307]
269
J-Web Interface
In the J-Web interface, you cannot commit some configuration changes in the Ports Configuration page and the VLAN Configuration page because of the following limitations for port-mirroring ports and port-mirroring VLANs:
A port configured as the output port for an analyzer cannot be a member of any VLAN other than the default VLAN. A VLAN configured to receive analyzer output can be associated with only one port.
[PR/400814]
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] 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 or uplink module ports when transceivers are not plugged into the ports. [PR/477549] The J-Web interface Static Routing page (Configure > Routing > Static Routing) might not display details on entries registered in the routing table. [PR/483885] In the J-Web interface, if you click OK on the configuration pages for class of service (CoS) (for example, Classifier and Drop Profiles) without making any changes to the configuration, the J-Web interface commits the configuration again and does not display validation messages or error messages. [PR/495603] In the J-Web interface, the Upload Package and Install Package options (Maintain > Software) might not display a warning message when there are pending changes to be committed. [PR/514853] In the J-Web interface for EX4500 switches, the Port Configuration page (Configure > Interfaces > Ports), the Port Security Configuration page (Configure > Security > Port Security), and the Filters Configuration page (Configure > Security > Filters) display features that are not supported on EX4500 switches. [PR/525671]
270
Resolved Issues in JUNOS Release 10.2 for EX Series Switches
When you use an HTTPS connection in the Microsoft Internet Explorer browser to save a report from the View Events page (Monitor > Events and Alarms > View events) in the J-Web interface, the following error message is displayed:
Internet Explorer was not able to open the Internet site
[PR/542887]
On EX Series switches, when access port security (secure-access-port) is configured on a VLAN or an ingress interface, unknown unicast packets do not flood all the interfaces in the VLAN until the switch learns the source MAC address of the packet. [PR/520592]
Multicast
On EX8200 switches, if you take a line card offline when GRES and IGMP snooping are enabled, existing multicast traffic might be affected because indexes are not updated correctly. [PR/569637]
Virtual Chassis
On an EX4200 Virtual Chassis, traffic loss might be high on XFP or SFP Virtual Chassis ports (VCPs). [PR/507079] When you halt a member of an EX4200 Virtual Chassis, the link on an uplink module port configured as a Virtual Chassis port (VCP) might not be brought down. [PR/582996] New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278

The following are the issues that have been resolved since JUNOS Release 10.2R1 for EX Series switches. The identifier following the descriptions is the tracking number in our bug database.
271
NOTE: Other software issues that are common to both EX Series switches and M, MX, and T Series routers are listed in Issues in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers on page 63.
On EX4200 switches, the LLDP-MED Location ID contains a Type, Length, and Value (TLV) whose length is incorrect. [PR/521658: This issue has been resolved.] On EX Series switches, packets might be dropped under certain network conditions, even though the user is authenticated. As a workaround, restart the dot1x protocol. [PR/524675: This issue has been resolved.] On EX Series switches, if static MAC address bypass is configured for a client on an interface configured for 802.1X authentication, the client becomes unreachable every time the MAC address expires. [PR/536316: This issue has been resolved.] If you connect a computer to a phone that is connected to an interface supporting multiple supplicants on an EX2200 switch, the Telecommunications Industry Association (TIA) network policy in the LLDP-MED packets from the EX2200 switch reports an incorrect VLAN and the phone might lose connectivity. [PR/542810: This issue has been resolved.] On EX Series switches, if you change the LLDP management address before configuring the logical (inet) interface, the SNMP MIB is not updated correctly on the remote switch (lldpRemManAddr). As a workaround, set the logical (inet) interface before setting the LLDP management address, or bounce the interface. [PR/534138: This issue has been resolved.]
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: This issue has been resolved.]
Firewall Filters
On EX3200 and EX4200 switches, firewall filters configured with the dscp match condition do not filter traffic on the egress interfaces. [PR/538403: This issue has been resolved.] On EX4500 switches, if you activate or deactivate a firewall filter configuration, VSTP convergence might not occur properly. As a workaround, restart the Ethernet switching process (eswd). [PR/548446: This issue has been resolved.]
272
Hardware
An EX2200 switch might not be able to recognize an SFP transceivers EEPROM information. [PR/540609: This issue has been resolved.]
Infrastructure
On EX Series switches, the static Neighbor Discovery Protocol (NDP) entries for IPv6 addresses are cleared automatically after some time. [PR/453710: This issue has been resolved.] On EX Series switches, the clear interface statistics all command takes a long time to execute. [PR/509303: This issue has been resolved.] On EX4200 switches, the headers in ARP requests sent from a virtual IP address contain the virtual IP address as the source address instead of the virtual MAC address. [PR/512488: This issue has been resolved.] On an EX8208 switch, the master Routing Engine might create a core file and reboot when there are more than 64,000 MAC clone routes in a single VLAN. [PR/513321: This issue has been resolved.] On EX8200 switches, the output of an SNMP walk on jnxOperatingTemp and jnxFruTemp does not show the temperature for line cards. [PR/524112: This issue has been resolved.] On EX4500 switches, the interface shutdown action for a storm control configuration does not have any effect. [PR/526077: This issue has been resolved.] In a Q-in-Q tunneling configuration that includes aggregated Ethernet interfaces (LAGs), after a forwarding (pfem) process restart, the member interfaces in the VLAN might be incorrectly set. [PR/527117: This issue has been resolved.] A memory leak might occur when the software forwarding process (sfid) attempts to reconnect to other JUNOS Software processes, eventually resulting in an sfid core file. [PR/534824: This issue has been resolved.] On the EX3200 and EX4200 switches after a hardware reboot and initialization, when the switch is rebooting the following message might appear: "Firewall rows could not be redirected on device 0". This message is a false positive and is generated intermittently due to a timing issue. If you see this message during consecutive reboots, contact the Juniper Technical Assistance Center (JTAC). [PR/537400: This issue has been resolved.] On EX2200 and EX4200 switches, if you have configured the system ports console log-out-on-disconnect statement, the switch does not log out when the console is disconnected. [PR/538263: This issue has been resolved.] If you configure a large number of VLANs and aggregated Ethernet interfaces and commit the configuration, the forwarding process (pfem) utilization stays at 80 percent for more than 60 minutes. As a result, the aggregated Ethernet interfaces cannot be used until the pfem usage reduces to normal limits. [PR/544433: This issue has been resolved.
273
If no intraconnect module or Virtual Chassis module is installed in an EX4500 switch, the switch boots but is not fully functional. Traffic loss might occur during packet forwarding. [PR/544628: This issue has been resolved.] A Packet Forwarding Engine (PFE) core file might be created if the unicast next hops are not present on the network. PR/546674: This issue has been resolved.] After you reboot an EX Series switch, a kernel panic might occur on the backup Routing Engine. [PR/550880: This issue has been resolved.] On EX2200 switches, the software forwarding process (sfid) displays the following message frequently:
TASK_OS_MEMHIGH: Using 55005 KB of memory, 109 percent of available
When the DNS server configured is not reachable, the name resolution for localhost takes a long time and the output of the show ntp association command takes a long time to appear. [PR/551739: This issue has been resolved.] On EX8200 switches, after routing and traffic recover from a graceful Routing Engine switchover (GRES) operation, a core file might be created after the Ethernet switching process (eswd) is restarted or after a line card is taken offline. [PR/570645: This issue has been resolved.] During the TFTP transfer portion of an automatic software download procedure, the software package might be truncated or corrupted. [PR/570901: This issue has been resolved.] On EX4200 switches, autonegotiation bypass, which allows a link in a Gigabit Ethernet SFP uplink port to begin operation even if autonegotiation on the link partner is disabled, fails to bring up the link. [PR/571198: This issue has been resolved.] The Ethernet switching process (eswd) might crash and then recover when the following change is made in the CLI (either in a single commit or in separate commits):

First, you remove an interface from the interface range on which VoIP is configured. Then, you either delete the removed interface or change its address family to a family other than ethernet-switching.
On an EX4200 Virtual Chassis, a forwarding process (pfem) core file might be created if all 802.1X-enabled interfaces are in the held state or the connecting state. [PR/571865: This issue has been resolved.] On EX Series switches on which the last term in a loopback firewall filter is either an implicit deny-all or explicit deny-all, received packets whose TTL is exceeded are dropped instead of being processed by the CPU. Thus, for example, traceroute packets received with a TTL of 0 are dropped, and ICMP unreachable packets are not sent back. [PR/573170: This issue has been resolved.] On EX4200 switches, when the mode on an SFP+ uplink module is changed from 10g to 1g, or from 1g to 10g, the switch does not learn MAC addresses until it is rebooted. [PR/573857: This issue has been resolved.]
274
On a switch on which nonstop routing (NSR) is enabled and on which transit unicast and multicast traffic is flowing, after multiple graceful Routing Engine switchover (GRES) operations, the routing protocol process (rpd) can continue to utilize large amounts of memory. [PR/574442: This issue has been resolved.] On EX2200 switches, the software forwarding process (sfid) might deadlock, with the result that traffic is blocked and MAC addresses cannot be learned. As a workaround, reboot the switch. [PR/579725: This issue has been resolved.] A large number of MAC pause frames might stall a Virtual Chassis member's IPC connection, causing the member to lose its connection to the Virtual Chassis. [PR/581804: This issue has been resolved.]
Interfaces
On EX8200 switches, if you deactivate the chassis configuration and upgrade the Routing Engine software, the backup Routing Engine might go down and come back up and create a core file when you enable and commit the chassis configuration. This might also result in slower response in the CLI. To stop the backup Routing Engine restarting continuously, deactivate the chassis on the backup Routing Engine. [PR/489029: This issue has been resolved.] In a Virtual Chassis setup, on consecutive reboots of the master switch, the peer device connected to the EX4200 switch over Link Aggregation Control Protocol (LACP) does not recognize the LACP messages sent by the EX4200 switch and the links become standalone links. [PR/505069: This issue has been resolved.] On EX4500 switches, when traffic congestion occurs on the ingress side of a Gigabit Ethernet interface with flow control enabled, the interface might generate pause frames. As a workaround, disable flow control on the ingress interface. [PR/528326: This issue has been resolved.] EX8200 switches might not detect the front-panel LCD display. [PR/553144: This issue has been resolved.]
J-Web Interface
In the J-Web interface, uploading a software package to the switch might not work properly if you are using Microsoft Internet Explorer version 7. [PR/424859: This issue has been resolved.] In the J-Web interface, interfaces configured with no-flow-control might be displayed in the LACP (Link Aggregation Control Protocol) Configuration page (Configure > Interfaces > Link Aggregation). [PR/437410: This issue has been resolved.] 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: This issue has been resolved.] The J-Web interface for EX4200 switches in a Virtual Chassis setup might display the following message when you request support information: The configuration on the
275
Switch is too large for JWEB to handle. Please use the CLI to manipulate the configuration. [PR/511185: This issue has been resolved.]
In the J-Web interface, if RIP, BGP, OSPF, and DHCP are not configured, you cannot click the links Commit, Help, and Logout in the monitoring pages for RIP, BGP, OSPF, and DHCP because the message Not configured that appears on these pages masks the Commit, Help, and Logout links in the J-Web interface. [PR/528346: This issue has been resolved.] In the J-Web interface, the MAC Learning Log table in the Ethernet Switching Monitor page (Monitor > Switching > Ethernet Switching) does not display any entries even though the show ethernet-switching mac-learning-log command output displays correct log entries. [PR/535200: This issue has been resolved.] In the J-Web interface, if you attempt to configure TACACS+ server authentication (Configure > System Properties > User Management), you cannot use the password prompt "password"--you must use the prompt "Password". The CLI allows use of either prompt. [PR/540217: This issue has been resolved.] On EX4500 switches and on EX4200-24F switches, the total number of ports displayed in the dashboard (Dashboard > Capacity Utilization > Total number of ports) in the J-Web interface increases every 2 seconds, each time an automatic refresh occurs. [PR/543913: This issue has been resolved.] When you configure port mirroring in the J-Web interface, the aggregated Ethernet (ae) interface is not included in the selection list. [PR/546740: This issue has been resolved.] In the J-Web interface, when you use an HTTPS connection in the Microsoft Internet Explorer browser, you cannot upload (Maintain > Config Management > Upload) or download (Maintain > Config Management > History > Configuration History) a configuration file. As a workaround, use an HTTP connection. [PR/551200: This issue has been resolved.] Committing configurations when an SSL certificate is added to the switch from the CLI editor (Configure > CLI tools > CLI Editor) fails if you are using the Microsoft Internet Explorer browser . As a workaround, use the Mozilla Firefox browser to commit configurations. [PR/552629: This issue has been resolved.]
When an EX Series switch configured to strip private AS numbers from the AS path receives an advertisement with private AS prefixes, the switch removes the private AS and advertises back to the BGP peer from which it received the advertisement, thus creating a loop. [PR/501286: This issue has been resolved.] If an EX8200 switch receives an IGMP packet of unknown type, the switch might flood the packet on all interfaces, including the ingress interface from which the packet was received. [PR/502248: This issue has been resolved.]
276
Errata in Documentation for JUNOS Release 10.2 for EX Series Switches
Management and RMON
On EX4200 switches, the LACP process (lacpd) creates core files when an SNMP MIB lookup is performed. [PR/533226: This issue has been resolved.]
Multicast
When multicast packets are transmitted from interfaces on which PIM is not enabled, VRRP might flap. [PR/520194: This issue has been resolved.] PIM register messages might be received and sent with incorrect checksums. [PR/532928: This issue has been resolved.] PIM join messages sent from an EX8208 switch to a Cisco RP using Auto-RP show the upstream neighbor as being the EX8208 switch itself and not the Cisco RP. [PR/557130: This issue has been resolved.] Some multicast groups stop forwarding packets after an unused 8-port 10-Gigabit Ethernet line card is taken offline and removed from an EX8208 switch. [PR/560463: This issue has been resolved.]
Virtual Chassis
On an EX4200 Virtual Chassis, a large number of awk processes and defunct processes might be running. [PR/576621: This issue has been resolved.] EX4200 Virtual Chassis members might not reboot and might create a Virtual Chassis control process (vccpd) core file. [PR/588466: This issue has been resolved.] New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278
Errata in Documentation for JUNOS Release 10.2 for EX Series Switches

This section lists outstanding issues with the documentation in this release.
277
The document titled Understanding Server Fail Fallback and Authentication on EX Series Switches incorrectly states that the RADIUS authentication server sends an EAPoL access-reject message. It should say that the RADIUS authentication server sends a RADIUS access-reject message. This mistake also appears in the example and CLI procedure documents about configuring server fail fallback.
Firewall Filters
Support for match conditions for firewall filters on EX4500 switches for IPv4 traffic on VLANs and Layer 3 interfaces is incorrectly stated. These switches support match conditions for firewall filters only on ports for IPv4 traffic.
Interfaces
The Protocol Families and Supported Interface Types table in the topic "family (for EX Series switches)" incorrectly shows the circuit cross-connect (ccc) protocol family as being supported on aggregated Ethernet interfaces. This protocol family is not supported on aggregated Ethernet interfaces. New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches on page 278
Upgrade and Downgrade Issues for JUNOS Release 10.2 for EX Series Switches
The following pages list the issues in JUNOS Release 10.2R4 for EX Series switches regarding software upgrade or downgrade:

Upgrade Policy for JUNOS Software Extended End-Of-Life Releases on page 278 Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series Switches on page 279 Upgrading from JUNOS Release 9.3R1 to Release 10.2 for EX Series Switches on page 279 Upgrading from JUNOS Release 9.2 to Release 10.2 for EX Series Switches on page 279 Downgrading from JUNOS Release 10.2 to Release 9.2 for EX4200 Switches on page 281
Upgrade Policy for JUNOS Software Extended End-Of-Life Releases

An expanded upgrade and downgrade path is now available for the JUNOS Software Extended End-of-Life (EEOL) releases. You can upgrade directly from one EEOL release
278
to one of two adjacent later EEOL releases. You can also downgrade directly from one EEOL release to one of two adjacent earlier EEOL releases. For example, JUNOS Software Releases 8.5, 9.3, 10.0, and 10.4 are all EEOL releases. You can upgrade from JUNOS Software Release 8.5 directly to either 9.3 or 10.0. To upgrade from Release 8.5 to 10.4, you first need to upgrade to JUNOS Software release 9.3 or 10.0, and then upgrade a second time to 10.4. Similarly, you can downgrade directly from JUNOS Software Release 10.4 to either 10.0 or 9.3. To downgrade from release 10.4 to 8.5, you first need to downgrade to 10.0 or 9.3, and then perform a second downgrade to Release 8.5. For upgrades and downgrades to or from a non-EEOL release, the current policy is that you can upgrade and downgrade by no more than three releases at a time. This policy remains unchanged. For more information on EEOL releases and to review a list of EEOL releases, see http://www.juniper.net/support/eol/junos.html.
Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series Switches

The ARP aging time configuration in the system configuration stanza in JUNOS Release 9.4R1 is incompatible with the ARP aging time configuration in JUNOS Release 9.3R1 or earlier and JUNOS Release 9.4R2 or later. If you have configured system arp aging-timer aging-time on EX Series switches running JUNOS Release 9.4R1 and upgrade to JUNOS Release 9.4R2 or later or downgrade to JUNOS Release 9.3R1 or earlier, the switch will display configuration errors on booting up after the upgrade or downgrade. As a workaround, delete the arp aging-timer aging-time configuration in the system configuration stanza and reapply the configuration after you complete the upgrade or downgrade. The format of the file in which the Virtual Chassis topology information is stored was changed in JUNOS Release 9.4. When you downgrade JUNOS Release 9.4 or later running on EX4200 switches in a Virtual Chassis to JUNOS Release 9.3 or earlier, 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.2 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.2 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.
279
CAUTION: If your Release 9.2 configuration includes any of the following conditions, revise the configuration before upgrading to Release 10.2. 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. 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
280
for the MAC address limit before upgrading from Release 9.2 to Release 10.2.
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.2. 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.
Downgrading from JUNOS Release 10.2 to Release 9.2 for EX4200 Switches
When you downgrade a Virtual Chassis configuration from JUNOS Release 10.2 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 Documentation

New Features in JUNOS Release 10.2 for EX Series Switches on page 257 Changes in Default Behavior and Syntax in JUNOS Release 10.2 for EX Series Switches on page 261 Limitations in JUNOS Release 10.2 for EX Series Switches on page 262 Outstanding Issues in JUNOS Release 10.2 for EX Series Switches on page 267 Resolved Issues in JUNOS Release 10.2 for EX Series Switches on page 271 Errata in Documentation for JUNOS Release 10.2 for EX Series Switches on page 277
281
JUNOS Documentation and Release Notes

For a list of related JUNOS documentation, see
http://www.juniper.net/techpubs/software/junos/ .
If the information in the latest release notes differs from the information in the documentation, follow the JUNOS Release Notes. To obtain the most current version of all Juniper Networks technical documentation, see the product documentation page on the Juniper Networks website at http://www.juniper.net/techpubs/ . Juniper Networks supports a technical book program to publish books by Juniper Networks engineers and subject matter experts with book publishers around the world. These books go beyond the technical documentation to explore the nuances of network architecture, deployment, and administration using the Junos operating system (Junos OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library, published in conjunction with O'Reilly Media, explores improving network security, reliability, and availability using Junos OS configuration techniques. All the books are for sale at technical bookstores and book outlets around the world. The current list can be viewed at http://www.juniper.net/books .
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can send your comments to techpubs-comments@juniper.net, or fill out the documentation feedback form at https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include the following information with your comments:

Document name Document part number Page number Software release version
Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract, or are covered under warranty, and need postsales technical support, you can access our tools and resources online or open a case with JTAC.
JTAC 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/.
282
Requesting Technical Support
JTAC Hours of Operation The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year.
Self-Help Online Tools and Resources For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features:

Find CSC offerings: http://www.juniper.net/customers/support/ Search for known bugs: http://www2.juniper.net/kb/ Find product documentation: http://www.juniper.net/techpubs/ Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/ Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
Search technical bulletins for relevant hardware and software notifications:

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

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

Use the Case Management tool in the CSC at http://www.juniper.net/cm/ . Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit us at http://www.juniper.net/support/requesting-support.html. If you are reporting a hardware or software problem, issue the following command from the CLI before contacting support:
user@host> request support information | save filename
To provide a core file to Juniper Networks for analysis, compress the file with the gzip utility, rename the file to include your company name, and copy it to ftp.juniper.net:pub/incoming. Then send the filename, along with software version information (the output of the show version command) and the configuration, to support@juniper.net. For documentation issues, fill out the bug report form located at https://www.juniper.net/cgi-bin/docbugreport/.
283
Revision History
28 May 2010Revision 1, JUNOS Release 10.2R1 08 June 2010Revision 2, JUNOS Release 10.2R1 10 August 2010Revision 3, JUNOS Release 10.2R2 28 September 2010Revision 4, JUNOS Release 10.2R2 19 October 2010Revision 5, JUNOS Release 10.2R3 29 October 2010Revision 6, JUNOS Release 10.2R3 03 December 2010Revision 7, JUNOS Release 10.2R3 17 May 2011Revision 8, JUNOS Release 10.2R4 18 May 2011Revision 9, JUNOS Release 10.2R4 10 June 2011Revision 10, JUNOS Release 10.2R4
Copyright 2012, Juniper Networks, Inc. All rights reserved. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
284

Junos Release Notes 10.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Junos Release Notes 10.2

Uploaded by

Copyright:

Available Formats

Juniper Networks JUNOS 10.

2 Software Release Notes

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Copyright 2012, Juniper Networks, Inc.

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Copyright 2012, Juniper Networks, Inc.

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Copyright 2012, Juniper Networks, Inc.

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Interfaces and Chassis

Copyright 2012, Juniper Networks, Inc.

GRE keys GRE Clear-dont-fragment

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Copyright 2012, Juniper Networks, Inc.

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

show chassis hardware show chassis pic show interfaces

Copyright 2012, Juniper Networks, Inc.

The following features are supported:

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Copyright 2012, Juniper Networks, Inc.

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

JUNOS XML API and Scripting

Copyright 2012, Juniper Networks, Inc.

Response Tag Element

ping mpls rsvp dynamic-bypass

ping mpls rsvp manual-bypass

request system logout

show chassis environment power-supply-unit

show chassis fabric map show chassis fabric plane-location

show chassis power sequence

show chassis power-budget-statistics

show chassis tfeb

show chassis vcpu

show class-of-service service-session

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Response Tag Element

show pppoe sessions

show r2cp interfaces

show r2cp radio

show r2cp sessions

show r2cp statistics

show services accounting errors inline-jflow

show services accounting flow inline-jflow

show services accounting status inline-jflow

show services border-signaling-gateway address-of-record

Copyright 2012, Juniper Networks, Inc.

Response Tag Element

show services border-signaling-gateway calls by-server

show services border-signaling-gateway calls by-service-point

show services border-signaling-gateway calls-duration by-server

show services border-signaling-gateway calls-duration by-service-point

show services border-signaling-gateway calls-failed by-server

Copyright 2012, Juniper Networks, Inc.

JUNOS 10.2 Software Release Notes

Response Tag Element