Release Notes - Juniper Networks

Junos ® OS 11.4 Release Notes 

Release 11.4R7 

05 March 2013 

Revision 1 

These release notes accompany Release 11.4R7 of the Junos operating system (Junos 

OS). They describe device documentation and known problems with the software. Junos 

OS runs on all Juniper Networks M Series, MX Series, and T Series routing platforms, SRX 

Series Services Gateways, J Series Services Routers, and the EX Series Ethernet Switches. 

For the latest, most complete information about outstanding and resolved issues with 

the Junos OS software, see the Juniper Networks online software defect search application 

at http://prsearch.juniper.net. 

You can also find these release notes on the Juniper Networks Junos OS Documentation 

Web page, which is located at https://www.juniper.net/techpubs/software/junos/. 

Contents Junos OS Release Notes for EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

New Features in Junos OS Release 11.4 for EX Series Switches . . . . . . . . . . . . 8 

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Ethernet Switching and Spanning Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Layer 2 and Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Management and RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Changes in Default Behavior and Syntax in Junos OS Release 11.4 for EX 

Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

Ethernet Switching and Spanning Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Fibre Channel over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 


Limitations in Junos OS Release 11.4 for EX Series Switches . . . . . . . . . . . . . . 12 

Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 


Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 


High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

J-Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Copyright © 2013, Juniper Networks, Inc. 

1

Junos OS 11.4 Release Notes 


Multicast Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Software Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Outstanding Issues in Junos OS Release 11.4 for EX Series Switches . . . . . . . 18 

Access Control and Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 



J-Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 


Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

Resolved Issues in Junos OS Release 11.4 for EX Series Switches . . . . . . . . . . 23 

Issues Resolved in Release 11.4R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 







Changes to and Errata in Documentation for Junos OS Release 11.4 for EX 

Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

Changes to the Junos OS for EX Series Switches Documentation . . . . . 48 

Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

Upgrade and Downgrade Instructions for Junos OS Release 11.4 for EX Series 

Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . . 49 

Upgrading from Junos OS Release 10.4R3 or Later . . . . . . . . . . . . . . . . . 50 

Upgrading from Junos OS Release 10.4R2 or Earlier . . . . . . . . . . . . . . . . . 51 

Downgrading to Junos OS Release 10.4R2 or Earlier . . . . . . . . . . . . . . . . 69 

Downgrading to an Earlier Junos OS Release . . . . . . . . . . . . . . . . . . . . . . 69 

Upgrading EX Series Switches Using NSSU . . . . . . . . . . . . . . . . . . . . . . . 70 

Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D 

Universal Edge Routers, and T Series Core Routers . . . . . . . . . . . . . . . . . . . . . 73 

New Features in Junos OS Release 11.4 for M Series, MX Series, and T Series 

Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

Junos OS XML API and Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

Layer 2 Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 

Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 

Services Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 

Subscriber Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 

System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

User Interface and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

2 

Copyright © 2013, Juniper Networks, Inc.

VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

Changes in Default Behavior and Syntax, and for Future Releases in Junos 

OS Release 11.4 for M Series, MX Series, and T Series Routers . . . . . . . . 153 

Changes in Default Behavior and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 153 

Issues in Junos OS Release 11.4 for M Series, MX Series, and T Series 

Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 

Current Software Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 

Previous Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 

Errata and Changes in Documentation for Junos OS Release 11.4 for M Series, 

MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 

Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 

Changes to the Junos OS Documentation Set . . . . . . . . . . . . . . . . . . . . 319 

Upgrade and Downgrade Instructions for Junos OS Release 11.4 for M Series, 

MX Series, and T Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 

Basic Procedure for Upgrading to Release 11.4 . . . . . . . . . . . . . . . . . . . . 321 

Upgrade and Downgrade Support Policy for Junos OS Releases . . . . . 324 

Upgrading a Router with Redundant Routing Engines . . . . . . . . . . . . . . 325 

Upgrading Juniper Network Routers Running Draft-Rosen Multicast 

VPN to Junos OS Release 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 

Upgrading the Software for a Routing Matrix . . . . . . . . . . . . . . . . . . . . . 327 

Upgrading Using ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 

Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled 

for Both PIM and NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 

Downgrade from Release 11.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 

Junos OS Release Notes for Branch SRX Series Services Gateways and J Series 

Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 

New Features in Junos OS Release 11.4 for Branch SRX Series Services 

Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . 331 

Release 11.4R5 New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 



Software Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 

Hardware Features—SRX210 Services Gateways . . . . . . . . . . . . . . . . . 346 

Hardware Features—SRX240 Services Gateway . . . . . . . . . . . . . . . . . . 347 

Changes in Default Behavior and Syntax in Junos OS Release 11.4 for Branch 

SRX Series Services Gateways and J Series Services Routers . . . . . . . . 350 

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 

AppSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 

Command-Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 

Deprecated Items for Branch SRX Series Services Gateways . . . . . . . . 353 

Flow and Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 

Interfaces and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 

Internet Protocol Security (IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 

Intrusion Detection and Prevention (IDP) . . . . . . . . . . . . . . . . . . . . . . . 356 

J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 

System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 

Virtual Private Networks (VPNs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 


3


Known Limitations in Junos OS Release 11.4 for Branch SRX Series Services 

Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . 357 

AppSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 

AX411 Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 

Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 


DOCSIS Mini-PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 

Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . . . 359 

Dynamic VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 


Group VPN Interoperability with Cisco’s GET VPN for Juniper Networks 

Security Devices that Support Group VPN . . . . . . . . . . . . . . . . . . . . 361 

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 


Internet Key Exchange Version 2 (IKEv2) . . . . . . . . . . . . . . . . . . . . . . . . 365 


IPv6 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 

IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 

J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 

Layer 2 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 

Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 

Power over Ethernet (PoE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 

Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 

SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 

Stream Control Transmission Protocol (SCTP) . . . . . . . . . . . . . . . . . . . 372 

Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 

Upgrade and Downgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 

Virtual Private Networks (VPNs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 

Unsupported CLI for Branch SRX Series Services Gateways and J Series 

Services Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 

Outstanding Issues in Junos OS Release 11.4R7 for Branch SRX Series 

Services Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . 378 



Interfaces and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 

J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 


Resolved Issues in Junos OS Release 11.4 for Branch SRX Series Services 

Gateways and J Series Services Routers . . . . . . . . . . . . . . . . . . . . . . . . 380 

Resolved Issues in Junos OS Release 11.4R7 for Branch SRX Series 

Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 









4 






Errata and Changes in Documentation for Junos OS Release 11.4 for Branch 

SRX Series Services Gateways and J Series Services Routers . . . . . . . . 401 

Errata for the Junos OS Software Documentation . . . . . . . . . . . . . . . . . 401 

Errata for the Junos OS Hardware Documentation . . . . . . . . . . . . . . . . 407 

Upgrade and Downgrade Instructions for Junos OS Release 11.4 for Branch 

SRX Series Services Gateways and J Series Services Routers . . . . . . . 409 

Upgrading and Downgrading among Junos OS Releases . . . . . . . . . . . 409 

Upgrading an AppSecure Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 

Upgrade and Downgrade Scripts for Address Book Configuration . . . . . 411 

Upgrade Policy for Junos OS Extended End-Of-Life Releases . . . . . . . . 414 

Hardware Requirements for Junos OS Release 11.4 for SRX Series 

Services Gateways and J Series Services Routers . . . . . . . . . . . . . . 414 

Junos OS Release Notes for High-End SRX Series Services Gateways . . . . . . . . . 417 

New Features in Junos OS Release 11.4 for High-End SRX Series Services 

Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 

Release 11.4R5 New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 




Software Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 

Changes in Default Behavior and Syntax in Junos OS Release 11.4 for 

High-End SRX Series Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . 436 

AppSecure Application Package Upgrade Changes . . . . . . . . . . . . . . . 436 

Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 


Deprecated Items for High-End SRX Series Services Gateways . . . . . . 437 


General Packet Radio Service (GPRS) . . . . . . . . . . . . . . . . . . . . . . . . . . 438 

In-Service Software Upgrade (ISSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 


IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

Management Information Base (MIB) . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 


Security Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 

System Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 

Known Limitations in Junos OS Release 11.4 for High-End SRX Series Services 

Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 

AppSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 


Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . . . 445 


General Packet Radio Service (GPRS) . . . . . . . . . . . . . . . . . . . . . . . . . . 447 

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 


5



Internet Key Exchange Version 2 (IKEv2) . . . . . . . . . . . . . . . . . . . . . . . . 448 


Internet Protocol Security (IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 

J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 

Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 

Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 

Simple Network Management Protocol (SNMP) . . . . . . . . . . . . . . . . . 455 

Unsupported CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 

Virtual Private Networks (VPNs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 

Outstanding Issues in Junos OS Release 11.4R7 for High-End SRX Series 

Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 


Command-Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 


IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 

J-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 

Resolved Issues in Junos OS Release 11.4 for High-End SRX Series Services 

Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 

Resolved Issues in Junos OS Release 11.4R7 for High-End SRX Series 














Errata and Changes in Documentation for Junos OS Release 11.4 for High-End 

SRX Series Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 

Errata for the Junos OS Software Documentation . . . . . . . . . . . . . . . . . 482 

Errata for the Junos OS Hardware Documentation . . . . . . . . . . . . . . . . 488 

Upgrade and Downgrade Instructions for Junos OS Release 11.4 for High-End 

SRX Series Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 

Upgrading and Downgrading among Junos OS Releases . . . . . . . . . . . 489 

Upgrading an AppSecure Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 

Upgrade and Downgrade Scripts for Address Book Configuration . . . . 491 

Upgrade Policy for Junos OS Extended End-Of-Life Releases . . . . . . . 494 

Hardware Requirements for Junos OS Release 11.4 for High-End SRX 

Series Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 

Junos OS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 

6 


Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 


7


Junos OS Release Notes for EX Series Switches 

• New Features in Junos OS Release 11.4 for EX Series Switches on page 8 

• Changes in Default Behavior and Syntax in Junos OS Release 11.4 for EX Series 

Switches on page 11 

• Limitations in Junos OS Release 11.4 for EX Series Switches on page 12 

• Outstanding Issues in Junos OS Release 11.4 for EX Series Switches on page 18 

• Resolved Issues in Junos OS Release 11.4 for EX Series Switches on page 23 

• Changes to and Errata in Documentation for Junos OS Release 11.4 for EX Series 


• Upgrade and Downgrade Instructions for Junos OS Release 11.4 for EX Series 


New Features in Junos OS Release 11.4 for EX Series Switches 

This section describes new features in Release 11.4 of the Junos operating system (Junos 

OS) for EX Series switches. 

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 8 

• Access Control and Port Security on page 9 

• Ethernet Switching and Spanning Trees on page 9 

• Infrastructure on page 10 

• Layer 2 and Layer 3 Protocols on page 10 

• Management and RMON on page 10 

Hardware 

• Support for enhanced feature licenses on EX3300 switches—EX3300 switches now 

support enhanced feature licenses (EFLs). [See Understanding Software Licenses for 

EX Series Switches.] 

• EX4500 Virtual Chassis and mixed EX4200 and EX4500 Virtual Chassis 

enhancements—An EX4500 Virtual Chassis or a mixed EX4200 and EX4500 Virtual 

Chassis can now include up to ten EX4500 member switches. An EX4200 switch and 

an EX4500 switch can now be configured in the master and backup roles in the same 

mixed EX4200 and EX4500 Virtual Chassis. These Virtual Chassis now support nonstop 

bridging (NSB) and Link Aggregation Control Protocol (LACP). [See EX3300, EX4200, 

and EX4500 Virtual Chassis, Understanding Nonstop Bridging on EX Series Switches, and 

Understanding Aggregated Ethernet Interfaces and LACP.] 

• New line card support for EX8200 Virtual Chassis—The following line cards can now 

be used in EX8200 switches that are members of an EX8200 Virtual Chassis: 

8 


New Features in Junos OS Release 11.4 for EX Series Switches 

• EX8200-2XS-40P (40-port PoE+ with 4-port SFP and 2-port SFP+ line card) 

• EX8200-2XS-40T (40-port RJ-45 with 4-port SFP and 2-port SFP+ line card) 

• EX8200-48PL (48-port PoE+ 20-Gbps line card) 

• EX8200-48TL (48-port RJ-45 20-Gbps line card) 

• EX8200-2XS-40P (40-port PoE+ with 4-port SFP and 2-port SFP+ line card) 

[See Line Card Model and Version Compatibility in an EX8200 Switch.] 

• New extra-scale EX8200 line card—A new extra-scale line card provides larger route 

table sizes than the corresponding non-extra-scale model to store more IPv4 and IPv6 

unicast routes. This extra-scale model is supported on standalone EX8200 switches 

and on EX8200 Virtual Chassis. 

• 40-port SFP+ line card (EX8200-40XS-ES) 

[See Line Card Model and Version Compatibility in an EX8200 Switch.] 

Access Control and Port Security 

• Persistent MAC learning—Persistent MAC learning, also known as sticky MAC, is a port 

security feature that allows retention of dynamically learned MAC addresses on an 

interface across restarts of the switch and interface-down events. Persistent MAC 

address learning is disabled by default. By enabling persistent MAC learning along with 

MAC limiting, you can enable interfaces to learn MAC addresses of trusted workstations 

and servers during the period from when you connect the interface to your network 

until the limit for MAC addresses is reached, and ensure that after this initial period, 

with the limit reached, new addresses are not allowed even if the switch restarts. The 

alternatives to using persistent MAC learning with MAC limiting are to statically configure 

each MAC address on each port or to allow the port to continuously learn new MAC 

addresses after restarts or interface-down events. [See Understanding Persistent MAC 

Learning (Sticky MAC).] 

Ethernet Switching and Spanning Trees 

• Distributed periodic packet management (PPM) virtual routing and forwarding 

(VRF) support—VRF traffic is now processed on EX Series switches through distributed 

periodic packet management (PPM). Distributed PPM processing is transparent to 

users, and it allows the switches to better manage VRF traffic. [See Understanding 

Distributed Periodic Packet Management on EX Series Switches.] 

• Increasing the maximum number of searchable hash indexes—For all EX Series 

switches except the EX8200 switch, you can use a new feature to mitigate situations 

in which hash index collisions are causing problems with the learning of MAC addresses 

in the forwarding database (FDB). The FDB on those switches is a hash table with 8192 

hash indexes (rows) of MAC addresses and four entries per hash index. When the FDB 

is searched, a configured hash function calculates the hash index at which to start the 

search. By default, after the search starts at the determined hash index, the maximum 

number of hash indexes that can be searched is one hash index, or four entries. If you 

notice a higher incidence of hash index collisions in the FDB, you can now increase the 

maximum number of searchable hash indexes in increments of 4, from 4 to a maximum 


9


of 32 entries. Increasing this number in turn increases the chances of finding an open 

entry in which to add a newly learned MAC address. However, searching more hash 

indexes requires more bandwidth and may impact the FDB performance and line-rate 

traffic. Therefore, you must carefully weigh the benefits of this feature against the 

number of hash index collisions, and if you decide to implement this feature, determine 

how much to increase the search parameters. To increase the maximum number of 

searchable hash indexes, enter the set ethernet-switching-options mac-lookup-length 

number-of-entries command. [See Understanding Bridging and VLANs on EX Series 

Switches.] 

Infrastructure 

• Nonstop active routing for Protocol Independent Multicast (PIM) on EX8200 

switches and EX8200 Virtual Chassis—Nonstop routing (NSR) for PIM is now 

supported on EX8200 switches and on EX8200 Virtual Chassis. You can now configure 

NSR to enable the transparent switchover between the master and backup Routing 

Engines without having to restart PIM. [See Understanding Nonstop Active Routing on 

EX Series Switches.] 

• Enhancement for upgrades of loader software on EX8200 switches from 

Release 10.3R2 or earlier—Loader software can now be upgraded on the backup 

Routing Engine, thus reducing the downtime for the switch when upgrading software 

from Release 10.3R2 or earlier. For Releases 10.4R3 or later, the loader software does 

not need to be upgraded. 

Layer 2 and Layer 3 Protocols 

• OSPFv2 on EX3300 switches—EX3300 switches now support OSPFv2. [See Layer 3 

Protocols Supported on EX Series Switches.] 

• Routed multicast traffic on virtual routing and forwarding (VRF) instances—Routed 

multicast traffic is now supported on all VRF instances, not just the default instance. 

[See Understanding Virtual Routing Instances on EX Series Switches]. 

Management and RMON 

• Erasure of all user-created files on the switch—The media option has been added for 

the request system zeroize command. The request system zeroize media command 

completely erases all user-created files from the switch, including plain-text passwords, 

secrets, and private keys for SSH, local encryption, local authentication, IPsec, RADIUS, 

TACACS+, and Simple Network Management Protocol (SNMP), replacing all 

user-created data with zeros, and then reboots the switch, returning it to the factory 

default configuration. (Without the media option, the request system zeroize command 

simply removes configuration and log files and resets key values; and then reboots the 

switch, returning it to the factory default configuration.) 

CAUTION: Before running the request system zeroize or request system 

zeroize media command, use the request system snapshot command to 

back up the files currently used to run the switch to a secondary device. 

10 


Changes in Default Behavior and Syntax in Junos OS Release 11.4 for EX Series Switches 

[See request system zeroize.] 

• Ethernet frame delay measurement—You can obtain Ethernet frame delay 

measurements (ETH-DM) on an EX Series switch. You can configure Operation, 

Administration, and Maintenance (OAM) statements for connectivity fault management 

(CFM) (IEEE 802.1ag) to provide on-demand measurements of frame delay and frame 

delay variation (jitter). You can configure the frame delay measurements in either a 

one-way mode or a two-way (round-trip) mode to gather frame delay statistics, 

including simultaneous statistics from multiple sessions. [See Understanding Ethernet 

Frame Delay Measurements on Switches.] 

• Support for IEEE 802.1ag Ethernet OAM on EX8200 switches—Support for the IEEE 

802.1ag standard for Operation, Administration, and Maintenance (OAM) is now 

available on EX8200 switches. The IEEE 802.1ag specification provides for Ethernet 

connectivity fault management (CFM), which monitors Ethernet networks that might 

comprise one or more service instances for network-compromising connectivity faults. 

[See Understanding Ethernet OAM Link Fault Management for an EX Series Switch.] 

Related 

Documentation 

• Changes in Default Behavior and Syntax in Junos OS Release 11.4 for EX Series Switches 

on page 11 






• Upgrade and Downgrade Instructions for Junos OS Release 11.4 for EX Series Switches 

on page 49 

Changes in Default Behavior and Syntax in Junos OS Release 11.4 for EX Series Switches 

This section lists the changes in default behavior and syntax in Junos OS Release 11.4 for 

EX Series switches. 


11



• The ingress-counting configuration statement at the [edit vlans] hierarchy level has 

been renamed l3-interfaces-ingress-counting. You use this configuration statement to 

activate a routed VLAN interface (RVI) input counter on a named VLAN on an EX8200 

switch. 

Fibre Channel over Ethernet 

• On EX4500 switches, App-FCoE and ETS values appear in the output for the show 

dcbx neighbors terse command but are not applicable to the switch; ignore these values. 

Hardware 

• If you attempt to configure an SFP uplink module to operate in 1-gigabit mode by 

including the sfpplus statement at the [edit chassis fpc slot pic pic-number] hierarchy 

level of the configuration, the configuration has no effect, and no warning or error 

message is displayed. The sfpplus statement configures the operating mode for SFP+ 

uplink modules only, in Junos OS Release 10.4R2 and later. 


• The following changes have been made to the show system snapshot command: 

• You do not need to specify a media slice number for the location of a snapshot, 

because all information about both slices is displayed by default. 

• The command displays information about the backup of the root file system (/) and 

directories /altroot, /var, and /var/tmp. 

[This issue was being tracked by PR/785373.] 

Related 

Documentation 








on page 49 

Limitations in Junos OS Release 11.4 for EX Series Switches 

This section lists the limitations in Junos OS Release 11.4 for EX Series switches. If the 

limitation is associated with an item in our bug database, the description is followed by 

the bug tracking number. 

12 



For the most complete and latest information about known Junos OS defects, use the 

Juniper online Junos Problem Report Search application at 

http://www.juniper.net/prsearch. 


• On EX Series switches, you cannot configure 802.1X authentication on redundant trunk 

groups (RTGs). [This is a known software limitation.] 


• If the bridge priority of a VSTP root bridge is changed such that this bridge becomes a 

nonroot bridge, the transition might take more than 2 minutes, and you might see a 

loop during the transition. [PR/661691: This is a known software limitation.] 

• On EX4200 switches, a firewall filter that uses the source MAC address to block bridge 

protocol data unit (BPDU) switching frames might not block them. [This is a known 

software limitation.] 

• On EX Series switches, only dynamically learned routes can be imported from one 

routing table group to another. [This is a known software limitation.] 

Firewall Filters 

• On EX3200 and EX4200 switches, when a very large number of firewall filters are 

included in the configuration, it might take a long time, possibly as long as a few minutes, 

for the egress filter rules to be installed. [PR/468806: This is a known software 

limitation.] 

• On EX3300 switches, if you add and delete filters with a large number of terms (on 

the order of 1000 or more) in the same commit operation, not all the filters are installed. 

As a workaround, add filters in one commit operation, and delete filters in a separate 

commit operation. [PR/581982: This is a known software limitation.] 

• On EX8200 switches, if you configure an implicit or explicit discard action as the last 

term in an IPv6 firewall filter on a loopback (lo0) interface, all the control traffic from 

the loopback interface is dropped. To prevent this, you must configure an explicit accept 

action. [This is a known software limitation.] 

Hardware 

• On 40-port SFP+ line cards for EX8200 switches, the LEDs on the left of the network 

ports do not blink to indicate when there is link activity if you set the speed of the 

network ports to 10/100/1000 Mbps. However, if you set the speed to 10 Gbps, the 

LEDs blink. [PR/502178: This is a known limitation.] 

• You cannot connect EX2200-C-12P-2G switches to the pre-standard Cisco IP Phone 

7960 with a straight cable. As a workaround, use a crossover cable. [PR/726929: This 

is a known limitation.] 


13



• On EX Series switches, the show snmp mib walk etherMIB command does not display 

any output, even though the etherMIB is supported. This occurs because the values 

are not populated at the module level—they are populated at the table level only. You 

can issue the show snmp mib walk dot3StatsTable command, the show snmp mib walk 

dot3PauseTable command, or the show snmp mib walk dot3ControlTable command 

to display the output at the table level. [PR/442373: This is a known software limitation.] 

• Momentary loss of an inter-Routing Engine IPC message might trigger the alarm that 

displays the message Loss of communication with Backup RE. However, no functionality 

is affected. [PR/477943: This is a known software limitation.] 

• Routing between virtual routing instances for local direct routes is not supported. 

[PR/490932: This is a known software limitation.] 

• On EX4500 switches, the maintenance menu is not disabled even if you include the 

lcd maintenance-menu disable statement in the configuration. [PR/551546: This is a 

known software limitation.] 

• When you enable the filter-id attribute on the RADIUS server for a particular client, 

none of the required 802.1X authentication rules are installed in the IPv6 database. 

Therefore, IPv6 traffic on the authenticated interface is not filtered; only IPv4 traffic is 

filtered on that interface. [PR/560381: This is a known software limitation.] 

• On EX8200 switches, if OAM link fault management (LFM) is configured on a member 

of a VLAN on which Q-in-Q tunneling is also enabled, OAM PDUs cannot be transmitted 

to the Routing Engine. [PR/583053: This is a known software limitation.] 

• When you reconfigure the maximum transmission unit (MTU) value of a next hop more 

than eight times without restarting the switch, the interface uses the maximum value 

of the eight previously configured values as the next MTU value. [PR/590106: This is 

a known software limitation.] 

• On switches on which a large number of routed VLAN interfaces (RVIs) are configured, 

when the backup Routing Engine is rebooting and a large amount of traffic is being 

sent, OSPF and IS-IS sessions might go down and come back up on the RVIs. [This is 


• On EX8208 and EX8216 switches that have two Routing Engines, one Routing Engine 

cannot be running Junos OS Release 10.4 or later while the other one is running 

Release 10.3 or earlier. Ensure that both Routing Engines in a single switch run either 

Release 10.4 or later or Release 10.3 or earlier. [PR/604378: This is a known software 

limitation.] 

• On EX6210 and EX8200 switches that have two Routing Engines, and on EX8200 

Virtual Chassis that have two XRE200 External Routing Engine modules, you cannot 

issue the commit synchronize command from the J-Web interface. As a workaround, 

issue this command from the CLI. [This is a known software limitation.] 

14 



High Availability 

• You cannot verify that nonstop bridging (NSB) is synchronizing Layer 2 protocol 

information to the backup Routing Engine even when NSB is properly configured. [This 

is a known software limitation.] 

• On EX Series Virtual Chassis using nonstop software upgrade (NSSU) to upgrade from 

a Junos OS Release 11.2 or earlier release to a Junos OS Release 11.3 or later release, 

after the NSSU operation finishes, the same MAC address might be assigned to multiple 

Layer 2 or aggregated Ethernet interfaces on different member switches within the 

Virtual Chassis. To set all Layer 2 and aggregated Ethernet ports to have unique MAC 

addresses, reboot the Virtual Chassis after the upgrade operation. To avoid these MAC 

address assignment issues, upgrade to Junos OS Release 11.3 or later without performing 

an NSSU operation. 

Unique MAC address assignment for Layer 2 and aggregated Ethernet interfaces in a 

Virtual Chassis was introduced in Junos OS Release 11.3. If you are upgrading to Junos 

OS Release 11.2 or earlier, you should expect to see the same MAC address assigned 

to multiple ports on different member switches within the Virtual Chassis. 


Interfaces 

• 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. [PR/480651: This is a known software limitation.] 

• On EX8216 switches, a link might go down momentarily when an interface is added to 

a LAG. [PR/510176: This is a known software limitation.] 

• On EX Series switches, if you clear LAG interface statistics while the LAG is down, then 

bring up the LAG and pass traffic without checking for statistics, and finally bring the 

LAG interface down and check interface statistics again, the statistics might be 

inaccurate. As a workaround, use the show interfaces interface-name command to 

check LAG interface statistics before bringing down the interface. [PR/542018: This is 


• You must connect directly to the master Switch Fabric and Routing Engine (SRE) 

module or Routing Engine (RE) module of the EX8200 member switch to configure 

Power over Ethernet (PoE) or Power over Ethernet Plus (PoE+) on an EX8200 Virtual 

Chassis. You cannot configure PoE or PoE+ through the XRE200 External Routing 

Engine. 

To configure PoE or PoE+ on an EX8200 member switch in an operational EX8200 

Virtual Chassis: 

1. Connect directly to the member switch that contains the ports on which you 

configure PoE or PoE+ using one of the following methods: 

• Log in to the Virtual Chassis and then enter the request session member member-id 

command to redirect the session to the member switch. 


15


• Cable a terminal device to the console port (labeled CON) on the master SRE or 

RE module. See Connecting an EX Series Switch to a Management Console. 

2. Configure PoE or PoE+. See Configuring PoE (CLI Procedure). 

[This is a known software limitation.] 

J-Web Interface 

• EX2200-C, EX3300, and EX6210 switches do not support switch connection and 

configuration through the J-Web interface. [This is a known software limitation.] 

• In the J-Web interface, you cannot commit some configuration changes in the Port 

Configuration page or 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 

interface. 


• In the J-Web interface, the Ethernet Switching Monitor page (Monitor > Switching > 

Ethernet Switching) might not display monitoring details if the switch has more than 

13,000 MAC entries. [PR/425693: This is a known software limitation.] 

• If four or more EX8200-40XS line cards are inserted in an EX8208 or EX8216 switch, 

the Support Information page (Maintain > Customer Support > Support Information) 

in the J-Web interface might fail to load because the configuration might be larger than 

the maximum size of 5 MB. The error message Configuration too large to handle is 

displayed. [PR/552549: This is a known software limitation.] 

• In the J-Web interface, you cannot configure interface ranges and interface groups. 


• The J-Web interface does not support role-based access control; it supports only users 

in the super-user authorization class. Therefore, a user who is not in the super-user 

class, such as a user with view-only permission, is able to launch the J-Web interface 

and is allowed to configure everything, but the configuration fails on the switch, and 

the switch displays access permission errors. [PR/604595: This is a known software 

limitation.] 


• 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. [PR/441789: This is a known software limitation.] 

• When MVRP is configured on a trunk interface, you cannot configure connectivity fault 

management (CFM) on that interface. [PR/540218: This is a known software limitation.] 

• The connectivity fault management (CFM) process (cfmd) might create a core file. 


16 



Multicast Protocols 

• MLD snooping of IPv6 multicast traffic is not supported. Layer 2 multicast traffic is 

always flooded on the VLAN. [This is a known software limitation.] 

Software Installation and Upgrade 

• Do not manually configure the autoinstallation statement at the [edit system] 

configuration hierarchy level. If you configure this statement, the switch loses network 

connectivity and cannot respond to either ping requests or to ARP requests. The initial 

default configuration that is present on the switch does include the autoinstallation 

statement at the [edit system] hierarchy level. The reason is that if the switch cannot 

find any configuration file stored in flash memory, it must try to obtain one from a TFTP 

server. However, the first time you commit a configuration on the switch, a configuration 

file is created in flash memory, and the statement is deleted from the configuration 

because it is no longer needed. [PR/610816:This is a known software limitation.] 

Virtual Chassis 

• When you configure mixed EX4200 and EX4500 Virtual Chassis with the J-Web 

interface, you can configure only the EX4500 switch to assume the master and backup 

roles and only the EX4200 switch to assume the linecard role. [This is a known software 

limitation.] 

• On standalone EX4500 switches, if you set the PIC mode to virtual-chassis, the switch 

has less bandwidth available for network ports than if you set the PIC mode to 

intraconnect. When the PIC mode setting is virtual-chassis, the network ports on a 

standalone EX4500 switch often do not achieve line-rate performance. 

The PIC mode on EX4500 switches can be set to virtual-chassis if the switch was 

ordered with a Virtual Chassis module installed and thus has its PIC mode set to 

virtual-chassis by default, or if you entered the request chassis pic-mode virtual-chassis 

operational mode command to configure the switch as a member of a Virtual Chassis. 

To check the PIC mode on an EX4500 switch on which a Virtual Chassis module is 

installed, use the show chassis pic-mode command. 

We recommend that you always set the PIC mode on a standalone EX4500 switch to 

intraconnect. To do this, use the request chassis pic-mode intraconnect operational 

mode command. [This is a known software limitation.] 

• On an EX4500 Virtual Chassis, if you issue the ping command to the IPv6 address of 

the virtual management Ethernet (VME) interface, the ping attempt fails. [PR/518314: 

This is a known software limitation.] 

• The automatic software update feature is not supported on EX4500 switches that 

are members of a Virtual Chassis. [PR/541084: This is a known software limitation.] 

• When an EX4500 switch becomes a member of a Virtual Chassis, it is assigned a 

member ID. If that member ID is a nonzero value, then if that member switch is 

downgraded to a software image that does not support Virtual Chassis, you cannot 

change the member ID to 0. A standalone EX4500 switch must have a member ID of 

0. The workaround is to convert the EX4500 Virtual Chassis member switch to a 


17


standalone EX4500 switch before downgrading the software to an earlier release, as 

follows: 

1. Disconnect all Virtual Chassis cables from the member to be downgraded. 

2. Convert the member switch to a standalone EX4500 switch by issuing the request 

virtual-chassis reactivate command. 

3. Renumber the member ID of the standalone switch to 0 by issuing the request 

virtual-chassis renumber command. 

4. Downgrade the software to the earlier release. 


• When you add a new member switch to an existing EX4200 Virtual Chassis, EX4500 

Virtual Chassis, or mixed EX4200 and EX4500 Virtual Chassis in a ring topology, a 

member switch that was already part of the Virtual Chassis might become 

nonoperational for several seconds. After the downtime, the member switch returns 

to the operational state with no user intervention. Network traffic to the member switch 

is dropped during the downtime. To avoid this issue, follow this procedure: 

1. Cable one dedicated or user-configured Virtual Chassis port (VCP) on the new 

member switch to the existing Virtual Chassis. 

2. Power on the new member switch. 

3. Wait for the new switch to become operational in the Virtual Chassis. Monitor the 

show virtual-chassis command output to confirm the new switch is recognized by 

the Virtual Chassis and is in the Prsnt state. 

4. Cable the other dedicated or user-configured VCP on the new member switch to 

the Virtual Chassis. 


Related 

Documentation 



on page 11 






on page 49 

Outstanding Issues in Junos OS Release 11.4 for EX Series Switches 

The following are outstanding issues in Junos OS Release 11.4R7 for EX Series switches. 

The identifier following the description is the tracking number in our bug database. 

18 






Other software issues that are common to both EX Series switches and M, MX, and T 

Series routers are listed in “Issues in Junos OS Release 11.4 for M Series, MX Series, and 

T Series Routers” on page 172. 


• On EX Series switches, updates to 802.1X (dot1x) implementation are needed for 

MS-NAP support. [PR/719408] 

Class of Service 

• On EX Series switches, EXP CoS classification will not occur if the EXP CoS classifiers 

are deleted and then added. As a workaround, deactivate and then reactivate 

rewrite-rules using the deactivate class-of-service command and the activate 

class-of-service command. [PR/848273] 


• On EX Series switches and the QFX Series, if you reconfigure a trunk port to access 

mode and if you perform the necessary dependent configurations to delete all but one 

of the VLANs, or if you reconfigure an access port to trunk mode, VLAN Spanning Tree 

Protocol (VSTP) instances might not converge properly, resulting in the formation of 

a loop. As a workaround, delete the VSTP configuration before reconfiguring the ports. 

[PR/668449] 

• When using VSTP, if you try to enable all VLANs on a physical interface that is a member 

of all the VLANs, a configuration error might be displayed. As a workaround, ensure 

that the interface is a member of any VLAN before adding it to the VLAN configuration 

under VSTP. [PR/736488] 


• On EX8208 switches, when a line card that has no interface configurations and is not 

connected to any device is taken offline using the request chassis fpc-slot slot-number 

offline command, the Bidirectional Forwarding Detection process (bfd) starts and 

stops repeatedly. The same bfd process behavior occurs on a line card that is connected 

to a Layer 3 domain when another line card that is on the same switch and is connected 

to a Layer 2 domain is taken offline. [PR/548225] 

• When a large number of ARP entries are learned on routed VLAN interfaces (RVIs), if 

a topology change occurs, the Ethernet switching process (eswd) might consume all 

the CPU. [PR/614262] 

• On EX4500 switches, ICMPv6 packets might transit the Routing Engine even though 

IPv6 is not configured. [PR/682953] 

• When you upgrade Junos OS from a release earlier than Release 10.4R3, in which 

resilient dual-root partitioning was introduced, to a later release that supports resilient 

dual-root partitioning, the time required for the upgrade to complete is longer than 


19


upgrading either between two releases that are earlier than Release 10.4R3 or between 

two releases that are Release 10.4R3 or later. [PR/683337] 

• On EX Series switches, when you are configuring DHCP option 82, the 

use-interface-description statement, which uses the interface description rather than 

the interface name (the default) in the circuit ID or remote ID value in the DHCP option 

82 information, does not work. [PR/695712] 

• When you run the commit check command, the word operation in the command output 

might be misspelled. [PR/704910] 

• If you delete an IPv6 configuration on a routed VLAN interface (RVI), ARP requests 

might not be trapped to the CPU and are not resolved. As a workaround, delete the 

RVI and then reconfigure it, or reboot the switch after you delete the IPv6 configuration. 

[PR/826862] 

• On EX8200 switches, the routing process consumes more CPU when OSPF traceoptions 

are set with the all tracing flag and nonstop active routing (NSR) is enabled. Do not 

enable traceoptions with NSR in the 11.4R7 release. [PR/844018] 


• In the J-Web interface, in the Port Security Configuration page (Configure > Security 

> Port Security), you are required to configure the action option when you configure 

the MAC limit option even though configuring an action value is not mandatory in the 

CLI. [PR/434836] 

• In the J-Web interface, in the OSPF Global Settings table in the OSPF Configuration 

page, the Global Information table in the BGP Configuration page, or the Add Interface 

window in the LACP Configuration page, if you try to change the position of columns 

using the drag-and-drop method, only the column header moves to the new position 

instead of the entire column. [PR/465030] 

• In the J-Web interface, you cannot edit a VLAN configuration after you have configured 

an IPv6 address for the VLAN. As a workaround, refresh the page manually and then 

try to edit the VLAN configuration. [PR/466633] 

• When a large number of static routes are configured and you have navigated to pages 

other than page 1 in the Route Information table on the Static Routing monitoring page 

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 a 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 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] 

• When you use an HTTPS connection in the Microsoft Internet Explorer browser to save 

a report from the following pages in the J-Web interface, the error message Internet 

Explorer was not able to open the Internet site is displayed on the pages: 

20 



• Files page (Maintain > Files) 

• History page (Maintain > Config Management > History) 

• Port Troubleshooting page (Troubleshoot > Troubleshoot > Troubleshoot Port) 

• Static Routing page (Monitor > Routing > Route Information) 

• Support Information page (Maintain > Customer Support > Support Information) 

• View Events page (Monitor > Events and Alarms > View Events) 

[PR/542887] 

• When you open a J-Web session using HTTPS, enter a username and password, and 

then click 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. [PR/549934] 

• In the J-Web interface, you cannot upload a software package using the HTTPS 

protocol. As a workaround, use either the HTTP protocol or the CLI. [PR/562560] 

• If you have accessed the J-Web interface using an HTTPS connection through the 

Microsoft Internet Explorer Web browser, you might not be able to download and save 

reports from some pages on the Monitor, Maintain, and Troubleshoot tabs. Some 

affected pages are at these locations: 

• Maintain > Files > Log Files > Download 

• Maintain > Config Management > History 

• Maintain > Customer Support > Support Information > Generate Report 

• Troubleshoot > Troubleshoot Port > Generate Report 

• Monitor > Events and Alarms > View Events > Generate Report 

• Monitor > Routing > Route Information > Generate Report 

As a workaround, use the Mozilla Firefox Web browser to download and save reports 

using an HTTPS connection. [PR/566581] 

• If you access the J-Web interface using the Microsoft Internet Web browser version 7, 

on the BGP Configuration page (Configure > Routing > BGP), all flags might be shown 

in the Configured Flags list (in the Edit Global Settings window, on the Trace Options 

tab) even though the flags are not configured. As a workaround, use the Mozilla Firefox 

Web browser. [PR/603669] 

• If you have created dynamic VLANs by enabling MVRP from the CLI, then in the J-Web 

interface, the following features do not work with dynamic VLANs and static VLANs: 

• In the Port Configuration page (Configure > Interface > Ports)—Port profile (select 

the interface, click Edit, and select Port Role) or the VLAN option (select the interface, 

click Edit, and select VLAN Options). 

• VLAN option on the Link Aggregation page (Configure > Interface > Link 

Aggregation)—Select the aggregated interface, click Edit, and click VLAN. 

• In the 802.1X Configuration page (Configure > Security > 802.1x)—VLAN assignment 

in the exclusion list (click Exclusion List and select VLAN Assignment) or the move 


21


to guest VLAN option (select the port, click Edit, select 802.1X Configuration, and 

click the Authentication tab). 

• Port security configuration (Configure > Security > Port Security). 

• In the Port Mirroring Configuration page (Configure > Security > Port 

Mirroring)—Analyzer VLAN or ingress or egress VLAN (click Add or Edit and then add 

or edit the VLAN). 

[PR/669188] 

• In the J-Web interface, HTTPS access might work with an invalid certificate. As a 

workaround, after you change the certificate, issue the restart web-management 

command to restart the J-Web interface. [PR/700135] 

• On EX4500 Virtual Chassis, if you use the CLI to switch from virtual-chassis mode to 

intraconnect mode, the J-Web dashboard might not list all the Virtual Chassis hardware 

components, and the images of the master and backup members of the Virtual Chassis 

might not be visible after an autorefresh occurs. The J-Web dashboard also might not 

list the vcp-0 and vcp-1 Virtual Chassis ports (VCPs) in the rear view of an EX4200 

switch (in the linecard role) that is part of a mixed EX4200 and EX4500 Virtual Chassis. 

[PR/702924] 

• After you have disabled the LCD Maintenance Menu and rebooted the switch, the 

EZSetup option might be available. [PR/707279] 

• In some help files, the copyright date is set to 2011 instead of 2012. [PR/735607] 

• If you use EZSetup to configure a root password that contains a comma (,), the 

characters after the comma are not checked during authentication, making it possible 

to log in to the switch with several different passwords. As a workaround, configure 

the root password from the CLI. [PR/738310] 

• When a switch has no routed interfaces, you cannot use the J-Web interface to add 

OSPF areas. As a workaround, use the CLI to add these areas. [PR/746624] 

• In the J-Web interface, you cannot configure the TCP fragment flag for a firewall filter 

in the Filters Configuration page (Configure > Security > Filters). [PR/756241] 

• In the J-Web interface, you cannot delete a term from a filter and simultaneously add 

a new term to that filter in the Filters configuration page (Configure > Security > Filters). 

[PR/769534] 

• Some component names shown by the tooltip on the Temperature bar in the Health 

Status panel of the dashboard might be truncated. As a result, you might see many 

components that have the same name displayed. For example, the components GEPHY 

Front Left, GEPHY Front Middle, and GEPHY Front Right might all be displayed as 

GEPHYFront. As a workaround, to find temperature details of the components, navigate 

to Monitor > System View > Chassis Information and click the Temperature tab in 

Chassis Component Details. [PR/778313] 

• In the J-Web interface, the Help page for the Install package in the Software 

Maintenance page (Maintain > Software) might not appear. [PR/786654] 

22 


Resolved Issues in Junos OS Release 11.4 for EX Series Switches 


• On EX3200 and EX4200 switches, Ethernet OAM connectivity fault management 

(CFM) is not working with continuity check. [PR/835547] 

• On EX Series switches, the sFlow monitoring technology adaptive sampling rate might 

not change when traffic flows through an sFlow-enabled interface. [PR/852149] 


• When the ingress and egress ports are on different member switches and a packet is 

routed from the default routing instance to another forwarding instance type, the VLAN 

ID might be modified in such a way that the traffic is redirected to the default routing 

instance for subsequent routing. [PR/721436] 

• When you remove the hard drive from an XRE200 External Routing Engine, an SNMP 

trap and a system alarm might not be generated. [PR/710213] 

Related 

Documentation 



on page 11 






on page 49 


The following are the issues that have been resolved in Junos OS Release 11.4 for EX 

Series switches. The identifier following the descriptions is the tracking number in our 

bug database. 




• Issues Resolved in Release 11.4R1 on page 24 








23


Issues Resolved in Release 11.4R1 

The following issues have been resolved in Junos OS Release 11.4R1. The identifier following 

the description is the tracking number in our bug database. 


• If storm control is enabled, the Link Aggregation Control Protocol (LACP) might stop 

and then restart when Layer 2 packets are sent at a high speed. As a workaround, 

disable storm control for all multicast traffic on aggregated Ethernet interfaces by 

issuing the command set ethernet-switching-options storm-control interface 

interface-name no-multicast. [PR/575560: This issue has been resolved.] 

• When the username for 802.1X (dot1x) authentication has more than 50 characters, 

Junos OS truncates the username field. [PR/588063: This issue has been resolved.] 

• The show lldp neighbors command displays interface descriptions instead of interface 

names. [PR/602442: This issue has been resolved.] 

• If you configure 802.1X (dot1x) authentication on an interface and then remove the 

802.1X configuration, 802.1X filters configured on that interface are not deleted. 

[PR/662196: This issue has been resolved.] 

• When you reboot or upgrade the software on a switch that has an active client 

connected to an 802.1X interface, a VLAN core file might be created. [PR/686513: This 

issue has been resolved.] 

Device Security 

• If you configure storm control with the action shutdown, after you reboot the switch, 

storm control is not enabled on all the ports on which it was configured. [PR/606054: 

This issue has been resolved.] 


• On EX8200 switches, you might not be able to configure private VLANs across the 

switch. [PR/599729: This issue has been resolved.] 

• An EX Series switch might take more than 20 minutes to learn ARP entries, because 

of which incorrect Layer 2 next hops might be installed on the Packet Forwarding 

Engine. This behavior can lead to inconsistent or intermittent communication issues 

with devices that are connected to the switch. [PR/612605: This issue has been 

resolved.] 

• On EX8200 switches, a Q-in-Q service VLAN might not be removed when a packet 

enters through a trunk port and exits from an access port. [PR/660247: This issue has 

been resolved.] 

• When BPDUs are forwarded to the best-effort queue instead of to the control queue, 

MSTP might not converge. [PR/665376: This issue has been resolved.] 

• On an EX4200 switch, when you disable a Q-in-Q interface on which you have 

configured a large number (more than 500) of VLAN swap rules, control traffic might 

be affected for about 10 minutes. During this time, the forwarding process (pfem) can 

consume up to 98 percent of the CPU. The system resumes its normal state after the 

24 



forwarding process completes its processing. [PR/678792: This issue has been 

resolved.] 

• If you apply a large number of VLAN tags (approximately 1000 tags) and commit the 

configuration after applying each individual tag, an mgd core file might be created. 


• RSTP might process BPDUs that do not comply with the IEEE standard, which might 

lead to unintended spanning-tree convergence behavior. [PR/683829: This issue has 


• When you enable VLANs and Q-in-Q tunneling on a switch, the switch drops packets 

and no MAC address learning occurs. [PR/685481: This issue has been resolved.] 


• When you configure a firewall filter for the ethernet-switching family, a pfem core file 

might be created. [PR/580454: This issue has been resolved.] 

• On EX8200 switches, if you configure a discard term on an egress firewall filter, the 

filter might not block ARP broadcast packets. [PR/672621: This issue has been resolved.] 

• For two-rate three-color policers, the egress traffic might not flow at the configured 

peak information rate (PIR). [PR/687564: This issue has been resolved.] 

• When you configure VLAN ID translation when using Q-in-Q tunneling, if you apply a 

tricolor marking (TCM) policer to the Q-in-Q interface, a Packet Forwarding Engine 

(pfem) core file might be created. [PR/688438: This issue has been resolved.] 

Hardware 

• On an EX8200-40XS line card, if you insert an SFP transceiver into a port and then 

disable autonegotiation on the port, the link does not come up. [PR/609413: This issue 

has been resolved.] 

• When certain SFPs that are not attached to optical cables are inserted into an EX 

Series switch, the switch does not generate low-power warnings or alarms. The 

transceivers that exhibit this behavior have these vendor (Opnext) part numbers: 

TRS2000EN-S201 (10G-SR), TRS2000EN-S211 (10G-SR), and TRS5020EN-S201 

(10G-LR). Use the show chassis pic fpc-slot fpc-number pic-slot pic-number command 

to display the vendor part numbers of the transceivers in your switch. [PR/613153: This 


• When the EX-PFE2 Packet Forwarding Engine temperature exceeds its threshold, an 

alarm might not be raised. The functionality of the switch is not affected. [PR/614354: 


• On EX6210 switches, traffic might not exit the 10-Gigabit Ethernet interfaces on the 

Routing Engines. [PR/669330: This issue has been resolved.] 

• On EX4500 switches, the LCD panel might not list the ADM (administrative status) or 

DPX (duplex) options in the Idle menu. Also, when you press Enter to cycle through 

the status LED modes, you might not be able to cycle through them. [PR/692341: This 



25



• On EX8200 Virtual Chassis, NSSU might get stuck when you upgrade line cards one 

by one. As a workaround, configure upgrade groups for groups of line cards, which you 

can then upgrade simultaneously, with minimal traffic loss. [PR/669764: This issue 


• When you perform a nonstop software upgrade (NSSU) operation on an EX8200 

Virtual Chassis, if you do not include the reboot option when you request the NSSU to 

have the switch perform an automatic reboot, the upgrade might stop responding 

indefinitely after the Junos OS images have been pushed to the master Routing Engine. 



• The number of users reported by the show system users command does not include 

Web users. [PR/572822: This issue has been resolved.] 

• On EX8200 switches, packets might occasionally be dropped with CRC32 errors, which 

are a result of Packet Forwarding Engine corruption. [PR/576934: This issue has been 

resolved.] 

• On EX2200 switches, if you configure the dhcp-option82 statement, the switch might 

stop operating and a software forwarding process (sfid) core file might be created. 


• During the reboot of an EX8200 switch, the links on the interfaces of neighboring 

devices might go up and down repeatedly even though the interfaces on the EX8200 

switch that connect to those interfaces on neighboring devices have not yet been 

initialized. [PR/591800: This issue has been resolved.] 

• When you press Tab during an SFTP session, an sftp core file might be created. 


• On EX8200 switches or on XRE200 External Routing Engines, 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/596013: This issue has been resolved.] 

• If you move a host to a port associated with a different DHCP pool than the one with 

which it was originally associated, the Preboot Execution Environment (PXE) boot 

process might fail. [PR/596152: This issue has been resolved.] 

• The system log (syslog) file might contain the following message /var: filesystem full. 


• On EX Series switches, the request system snapshot command mistakenly includes 

the as-primary option. [PR/603204: This issue has been resolved.] 

• When you commit an IPv6 configuration, the switch might display the db> prompt. 


• On EX4200 switches, if you specify the source-address statement when configuring a 

system log (syslog) file, the switch might not send the correct source IP address to the 

syslog server after the switch reboots. [PR/608724: This issue has been resolved.] 

26 



• In rare instances, a file system inconsistency might exist if you shut down an EX Series 

switch ungracefully. The result is a system panic, and a vmcore file is created. As a 

workaround, use the nand-mediack utility for checking bad blocks in the NAND flash 

memory. Review KB20570 from the Juniper Technical Assistance Center for instructions 

about how to use this utility. [PR/609798: This issue has been resolved.] 

• Packet loss of about 2 to 5 percent might occur for traffic destined to MAC addresses 

that start with 03: or 09:. [PR/658631: This issue has been resolved.] 

• When you upgrade Junos OS, traffic might not flow between two directly connected 

interfaces. [PR/661131: This issue has been resolved.] 

• If you have configured port 1 on the SFP uplink module, the system log files might show 

an error and might get full within a few minutes. [PR/661426: This issue has been 

resolved.] 

• If you remove or change interfaces soon after completing a nonstop software upgrade 

(NSSU) operation, the multicast snooping process (mcsnoopd) might create a core 

file. [PR/662065: This issue has been resolved.] 

• If you delete a VLAN that has no VLAN ID, firewall filters might stop operating properly. 


• When DHCP unicast packets are processed on a server for the first time, the processing 

time might slow down, which might prevent the DHCP lease from getting renewed. 


• Layer 3 next-hop entries might remain queued in the kernel of the backup Routing 

Engine and might never be installed in the forwarding table. [PR/670799: This issue 


• A memory leak might occur, as evidenced by jt_nh_multiple_init() returned error code 

(No memory:3)! system log (syslog) messages. This leak disrupts traffic forwarding. 


• On EX Series switches, issuing the request system zeroize command reboots the switch 

but fails to remove the configuration files in the /config and /var/db/config directories 

and other user-created data. [PR/678403: This issue has been resolved.] 

• The system log (syslog) files might contain messages related to storm control even 

when storm control is not configured. [PR/679231: This issue has been resolved.] 

• The management process (mgd) might create a core file when reading long lines. For 

example, this can happen when the system displays a Junos OS configuration file that 

contains long lines. When mgd crashes, the command that you were executing does 

not succeed, and the following errors appear in the messages file: 

%KERN-3-BAD_PAGE_FAULT: pid 57182 (mgd), uid 0: pc 0x8870ab92 got a write 

fault at 0x8488000, x86 fault flags = 0x6 

%KERN-6: pid 57182 (mgd), uid 0: exited on signal 11 (core dumped) 


• The /var/log/wtmp file might become excessively large, and thus the switch might run 

out of disk space on the /var partition. As a workaround, use the request system storage 


27


cleanup command, or manually delete and re-create the /var/log/wtmp file from the 

shell. [PR/681369: This issue has been resolved.] 

• When the same firewall filter and Layer 3 classifier is applied to two Layer 3 interfaces, 

a Packet Forwarding Engine (pfem) core file might be created. [PR/683747: This issue 


• On EX2200 switches, when you have configured a syslog action on the me0 interface, 

the switch might crash. [PR/694602: This issue has been resolved.] 

• On EX3200 and EX4200 switches, transmit FIFO queue overruns might cause the 

switch to stop working. [PR/695071: This issue has been resolved.] 

Interfaces 

• If you use the restart vrrp command to restart VRRP, a ppmd core file might be created. 


• On EX4200 switches, when an uplink fails or is deactivated, failure detection is not 

propagated to the downlink LAG interfaces. [PR/605468: This issue has been resolved.] 

• The Ethernet interfaces in a link aggregation group (LAG) might all have the same 

current MAC address as the parent aggregated Ethernet (ae) interface. [PR/681385: 


• You might not be able to commit a configuration on an XRE200 External Routing 

Engine, and the switch might display the error could not save to juniper.save+. 


• An EX4200 switch might stop forwarding traffic, and a Packet Forwarding Engine 

(pfem) core file might be created. [PR/691504: This issue has been resolved.] 

• When 10-Gigabit Ethernet interfaces flap frequently, a routing protocol process (rpd) 

core file might be created. [PR/692126: This issue has been resolved.] 

• On EX3200, EX4200, EX4500, EX6200, EX8208, and EX8216 switches, the root user 

is allowed to telnet into the me0 interface, which does not comply with the default 

Junos OS behavior, as documented in Connecting and Configuring an EX Series Switch 

(CLI Procedure). [PR/695346: This issue has been resolved.] 

IPv6 

• On EX Series switches, IPv6 neighbor unreachability detection does not work. As a 

workaround, use the clear ipv6 neighbor command to initiate neighbor detection. 



• In the J-Web interface, the link status might not be displayed correctly in the Port 

Configuration page or the LACP (Link Aggregation Control Protocol) Configuration 

page if the Commit Options preference is set to single commit (the Validate configuration 

changes option). [PR/566462: This issue has been resolved.] 

• If the password has been removed from the authentication-order statement and the 

external authentication server (TACACS+ or RADIUS) is down, you might not be able 

to log in to the J-Web interface. [PR/599613: This issue has been resolved.] 

28 



• In the J-Web interface, when you open the Static Routing Configuration page (Configure 

> Routing > Static Routing) and click Edit to edit an IPv6 static route, the J-Web interface 

displays the page for editing IPv4 addresses. As a workaround, use the CLI to edit the 

IPv6 addresses. [PR/660613: This issue has been resolved.] 

• In the J-Web interface, the report generated from the Events page (Monitor > Events 

and Alarms > View Events) does not show the description for the first four to five 

events. As a workaround, view the description from the Events page or from the Junos 

OS CLI. [PR/661752: This issue has been resolved.] 

• On EX8200 Virtual Chassis that include an EX8216 switch in which an EX8200-40XS 

line card is installed in slot 2, 3, or 4, the J-Web interface does not populate the line 

card’s interfaces images in the expanded view of the dashboard. As a workaround, 

install the line card in a slot other than one of these three. [PR/662231: This issue has 


• In the J-Web interface, in the Static Routing configuration page (Configure > Routing 

> Static Route > Add), you can configure only negative values and boundary values in 

the IP octet, and you cannot configure empty values. As a workaround, fill in all the 

octets before committing the values. [PR/665435: This issue has been resolved.] 

• In the J-Web interface, you cannot associate a filter name that contains spaces to a 

VLAN in the VLAN Configuration page (Configure > Switching > VLAN). As a workaround, 

go to the Filters Configuration page (Configure > Security > Filters), click the filter name 

to be associated, and then click Edit. In the pop-up window, use the Association tab 

to associate a VLAN to the filter. [PR/677145: This issue has been resolved.] 

• In the J-Web interface, in the Redundant Trunk Group (RTG) Configuration page 

(Configure > Switching > RTG), the Commit option is not enabled. As a workaround, 

select the Validate and commit configuration change option before modifying the 

configuration. [PR/677220: This issue has been resolved.] 

• In the J-Web interface, the tooltip for Fan Image might not load in the dashboard. As 

a workaround, view the fan status in the Chassis Information page (Monitor > System 

View > Chassis Information). [PR/677922: This issue has been resolved.] 

• In the J-Web interface, the dashboard is not displayed. [PR/700274: This issue has 



• If a router or switch acting as both an autonomous system boundary router (ASBR) 

and an area border router (ABR) is reachable through both a backbone area and a stub 

area, and if the advertisement through stub area advertising has a higher metric than 

the advertisement through the backbone area, the external routes might be installed 

incorrectly in the routing table. The routing table entry incorrectly shows that the next 

hop is through the stub area. [PR/610813: This issue has been resolved.] 

• When a BGP interface is flapping quickly, BGP might unnecessarily withdraw prefixes 

even when a good route to that prefix still exists. [PR/677191: This issue has been 

resolved.] 

• In the J-Web interface, if you discard any available MIB profile, file, or predefined object 

from accounting-options in the Point and Click CLI Configuration page (Configure > 


29


CLI Tools > Point and Click CLI), the J-Web session times out. As a workaround, perform 

the same operation from the CLI. [PR/689261: This issue has been resolved.] 


• When you configure sFlow monitoring technology, the switch allows you to configure 

separate ingress and egress sample rates on the same interface. As configuring more 

than one sample rate on an interface can lead to inaccurate results, configure just one 

rate per interface. [PR/582521: This issue has been resolved.] 

• The dot1qVlanStaticUntaggedPorts MIB reports incorrect values for voice VLANs. 


• When you configure both sFlow monitoring technology and port-mirroring features, 

parity errors might occur, which might cause the switch to crash and then reboot. 


• sFlow technology does not support IPv6 collectors, source IP addresses, or agent IDs. 

In Junos OS releases previous to this release, configuration of these features was not 

blocked. If your configuration includes any of these features, you must remove them 

before upgrading to this Junos OS release. [PR/659922: This issue has been resolved.] 

• When you create a static ARP entry for an interface and then issue the show snmp mib 

walk command, the static ARP entry is incorrectly identified in the command output 

as a dynamic entry (3) rather than a static entry (4). [PR/662290: This issue has been 

resolved.] 

• When the system is being polled for SNMP statistics, the syslog message Process 

(930,mib2d) attempted to exceed RLIMIT_DATA: attempted 65552 KB Max 65536 KB 

might appear repeatedly in the system log (syslog) file. This is the result of a memory 

leak caused by the MIB2 process (mib2d). [PR/664475: This issue has been resolved.] 

• When you use the snmpwalk application to get information about switch interfaces, 

it returns information about incorrect interfaces. [PR/664940: This issue has been 

resolved.] 

• For EX Series switches, sFlow technology and routing policy have been removed from 

the extended feature license (EFL). An EFL is now required only for the following 

features: Q-in-Q tunneling, BFD liveness detection, connectivity fault management 

(CFM), IGMP, MSDP, OSPFv2, PIM and PIM sparse mode, real-time performance 

monitoring (RPM), service VLANs (S-VLANs), unicast reverse path forwarding (RPF), 

virtual routers, and VRRP. [PR/672346: This issue has been resolved.] 


• You might not be able to delete stale multicast routes even though no corresponding 

(S, G) traffic exists. [PR/674419: This issue has been resolved.] 

• If interfaces go up and down frequently, a memory leak might occur, and cfmd and 

mcsnoopd core files might be created. [PR/688356: This issue has been resolved.] 

• A multicast route entry is deleted and added back again approximately every 300 

seconds, resulting in a traffic loss of about 1 to 3 seconds. [PR/698129: This issue has 


30 



Power over Ethernet 

• On EX2200-C switches, two problems might occur when devices powered by Power 

over Ethernet (PoE) are connected to the switch and the switch reboots. The first 

problem occurs when PoE is enabled on the switch interfaces. The powered devices 

connected to those interfaces draw power while the switch is rebooting, and then after 

the switch stabilizes, the powered devices reboot twice. The second problem occurs 

when PoE is disabled on the switch interfaces. The powered devices connected to 

those interfaces draw power while the switch is rebooting, and then after the switch 

stabilizes, the powered devices reboot twice and then shut down. As a workaround, if 

you do not want the powered devices to reboot, connect them to the interfaces after 

the switch has stabilized after its reboot. [PR/675971: This issue has been resolved.] 


• On an XRE200 External Routing Engine, the rescue configuration might not get 

synchronized with the backup XRE200 External Routing Engine. [PR/687797: This 



• On Virtual Chassis that are configured with a private VLAN (PVLAN) and a link 

aggregation group (LAG), if a Virtual Chassis loses one of its members, traffic flow 

might not resume properly across the remaining LAG members, resulting in traffic loss. 


• On EX8200 Virtual Chassis, the link status of an aggregated Ethernet (ae) interface 

managed by LACP goes down and comes back up when a graceful Routing Engine 

switchover (GRES) operation is performed between the XRE200 External Routing 

Engines. This switchover might have been initiated from the Junos OS CLI or because 

of a failure of the master Routing Engine. [PR/599772: This issue has been resolved.] 

• On EX8200 Virtual Chassis running a Junos OS image with resilient dual-root 

partitioning, when the kernel synchronization process (ksyncd) on the backup Routing 

Engines fails or when the master and backup Routing Engines are out of sync, both 

conditions that create a ksyncd core file, it might take more than 12 minutes for the 

core file to be created. During this time, the Virtual Chassis is highly unstable: the 

Routing Engine CPU usage is at 100 percent; all control protocols, such as BFD, IS-IS, 

and OSPF, are continuously stopping and restarting; and the CLI prompt is not displayed 

after you type a CLI command. This issue does not occur with nonresilient dual-root 

partitioning Junos OS images. [PR/609061: This issue has been resolved.] 

• On EX4200 Virtual Chassis, if you configure an interface’s hold time, when you insert 

or remove a transceiver, the chassis manager process (chassism) might create a core 

file. As a workaround, delete the hold-time statement from the interface configuration 

before you remove or insert a transceiver. [PR/664754: This issue has been resolved.] 

• On EX8200 Virtual Chassis, if the topology is formed such that ingress multicast traffic 

is routed first to the rendezvous point (RP) and then returns to the Virtual Chassis for 

egress via Layer 2 multicast, the multicast traffic is forwarded only to receivers 

connected to the Virtual Chassis member in which the returned multicast traffic is 


31


received. Multicast traffic is not forwarded to other receivers in other Virtual Chassis 

members. [PR/666355: This issue has been resolved.] 

• On EX8200 Virtual Chassis, GRE-tunneled traffic is not transmitted across the chassis. 

For possible workarounds, contact JTAC. [PR/669513: This issue has been resolved.] 

• In Virtual Chassis composed of both EX4200 and EX4500 switches, you cannot 

configure PoE. [PR/671980: This issue has been resolved.] 

• When EX4200 and EX4500 switches are interconnected into the same Virtual Chassis 

to form a mixed EX4200 and EX4500 Virtual Chassis, the switches might fail to form 

a Virtual Chassis. [PR/681072: This issue has been resolved.] 


The following issues have been resolved since Junos OS Release 11.4R1. The identifier 

following the description is the tracking number in our bug database. 


• In the J-Web interface, if you navigate to any of the top panel tabs (such as Configure, 

Monitor, Maintain, and Troubleshoot) and then click Help > Help Contents, you might 

be directed to an undefined page. To display the correct help for a feature, first click 

the menu item corresponding to the feature to load the page, and then click Help > 

Help Contents. [PR/684958: This issue has been resolved.] 

• When you enable LLDP-MED autonegotiation on an EX Series switch, the 

autonegotiation bit in the LLDP-MED packet is set to not-supported, which might cause 

IP phones to discard LLDP-MED packets received from the switch. [PR/708752: This 


• If incoming LLDP packets contain multiple Management Address TLVs, EX Series 

switches discard them. [PR/718781: This issue has been resolved.] 

• When DHCP snooping information is not learned, ARP request packets might add the 

following message to the system log (syslog) file: ESWD_DAI_FAILED: 3 (null) received, 

interface. [PR/719751: This issue has been resolved.] 


• When the same MAC address is learned on two VLANS, an Ethernet switching process 

(eswd) core file might be created. [PR/693942: This issue has been resolved.] 

• When you add a new VLAN on a switch on which you have also configured loopback 

and other IPv4 firewall filters, a Packet Forwarding Engine (pfem) core file might be 

created that contains the message No space available in tcam. [PR/701779: This issue 


• When you configure the same VLAN ID on both interface VLAN tagging and global 

tagging, ARP entries cannot be resolved on the VLAN interface. [PR/722815: This issue 


• Routed VLAN interfaces (RVIs) might use the system MAC address instead of using 

the MAC address one greater than the system MAC address (that is, system MAC 

32 



address + 1), and Layer 3 ports might use their hardware MAC address instead of using 

the system MAC address. [PR/723643: This issue has been resolved] 

Hardware 

• For Opnext SFPs with Juniper part number 740-021308 and types SFP+ 10GE-SR, 

SFP+ 10GE-LR, or SFP+ 10GE-ER, when the low-power threshold is crossed, the 

power-low warning alarm is not set on extra-scale and Power over Ethernet (PoE) line 

cards. [PR/683732: This issue has been resolved.] 

• When you are using only one power supply in a switch, the fan status might remain in 

testing mode, and the LCD panel might not start. [PR/728770: This issue has been 

resolved.] 

• If you abruptly take a power supply offline, a chassimd core file might be created. 



• If you perform a nonstop system software upgrade (NSSU) operation that includes 

the reboot option, some traffic loss might occur. [PR/717662: This issue has been 

resolved.] 

• If you perform a nonstop software upgrade (NSSU) operation, the Packet Forwarding 

Engine process (pfem) might restart. [PR/729095: This issue has been resolved.] 


• The system log (syslog) files might contain the message Juniper syscall not available. 

These messages are harmless, and you can ignore them. [PR/519153: This issue has 


• On EX8200 switches, when you run a failover operation on the Routing Engines, a 

vmcore file might be created. [PR/678465: This issue has been resolved.] 

• During a graceful Routing Engine switchover (GRES) operation between an EX4200 

and an EX4500 switch, a Packet Forwarding Engine (pfem) core file might be created. 


• After you upgrade Junos OS, a software forwarding process (sfid) core file might be 

created. [PR/691958: This issue has been resolved.] 

• EX Series switches might not learn the MAC addresses of directly connected devices. 


• When the switch is performing 802.1X (dot1x) authentication using MAC RADIUS, you 

might see the following message in the system log (syslog) file: kmem type temp using 

57344K, exceeding limit 57344K. [PR/697815: This issue has been resolved.] 

• On EX8200 switches that have IPv6 and IPv4 configured on routing instances, when 

many interfaces go down and come back up repeatedly, the next-hop programming 

for some routes might fail, which can cause disruptions in traffic. [PR/701985: This 


• On EX3200 and EX4200 switches on which a VRF routing instance is configured, the 

default multicast route entry might not be set correctly, which might cause multicast 


33


traffic loss. This occurs because the default PIM route entry is incorrectly shared with 

all VRF routing instances, so a multicast route change in one routing table could impact 

other routing tables. [PR/702600: This issue has been resolved.] 

• In rare cases, EX3300 switches running a Junos OS release earlier than Release 11.3R4 

or Release 11.4R2 might experience some traffic loss or a link failure as a result of 

non-user-configurable settings that are not optimized. To resolve this issue, upgrade 

to one of the following Junos OS releases: 

• Junos OS Release 11.3—R4 or later 




• If the egress interface is a trunk interface, frames that exceed 9216 bytes might not be 

fragmented. [PR/705905: This issue has been resolved.] 

• On EX2200, EX3300, and EX6200 switches, and on EX8200 Virtual Chassis, NetBIOS 

snooping does not work. [PR/706588: This issue has been resolved.] 

• New hosts and routes might not be installed in the Packet Forwarding Engine, and the 

system log (syslog) files contains the following message: Failed to jtm_alloc for 

mrvl_rt_nh_uc_install. [PR/726043: This issue has been resolved.] 

• If the forwarding table contains more than 9000 route entries, issuing the clear arp 

command might not clear the entries in the hold state. [PR/729128: This issue has 


Interfaces 

• When you configure the member interfaces of an aggregated Ethernet interface before 

you configure the aggregated Ethernet (ae) device using set commands from the CLI, 

the aggregated Ethernet interface does not receive MAC updates. As a workaround, 

configure the aggregated Ethernet interface first, and then configure the member 

interfaces. [PR/680913: This issue has been resolved.] 

• EX Series switches do not show the control packet counters in both directions on the 

logical units of aggregated Ethernet (ae) interfaces. [PR/693202: This issue has been 

resolved.] 

• Interfaces might not come up, and the system log (syslog) file might contain the 

message DCD_CONFIG_WRITE_FAILED: configuration write failed for an RT ADD: Cannot 

allocate memory. [PR/697300: This issue has been resolved.] 

• On EX4500 switches with an interface in loopback mode, BPDUs might be processed 

instead of being dropped as expected, generating topology change notifications (TCNs). 

As a workaround, disable the interface that is in loopback mode. [PR/698077: This 


• When you configure the no-preempt and interface-tracking options on a switch that is 

a VRRP master router, if the VRRP mastership is taken over by a switch that is a VRRP 

backup router and the tracking interface on the original master router goes down, then 

if the tracking interface on the original master router comes back up and the master's 

34 



original priority is restored, the new master's mastership might transition to the original 

master router. [PR/699243: This issue has been resolved.] 

• On a link aggregation group (LAG) interface on which Q-in-Q tunneling is enabled on 

a VLAN, packets entering the LAG might be dropped. As a workaround, explicitly 

configure the VLAN to allow the desired traffic. [PR/699940: This issue has been 

resolved.] 


• On EX4500 switches, you cannot configure BGP in the BGP Configuration page 

(Configure > Routing > BGP). [PR/699308: This issue has been resolved.] 

• In the J-Web interface on an EX4500 Virtual Chassis, if you configure four or more 

Virtual Chassis members in the Support Information page (Maintain > Customer 

Support > Support Information), you might see the error Configuration of switch is too 

large. [PR/704992: This issue has been resolved.] 

• In the J-Web interface, if you disable a port whose link status is down, the J-Web 

interface displays the incorrect link status for that interface. [PR/705836: This issue 


• On SRX210 Services Gateways and EX Series switches, if you use the CLI to delete a 

DHCP pool, the J-Web interface Monitor page (Monitor > Services > DHCP > Pools) 

might not display the correct value in the Excluded address field. Instead, it might 

display the text [objec object] in the table. [PR/723555: This issue has been resolved.] 


• EX Series switches might not send jnxMIMst traps. [PR/707141: This issue has been 

resolved.] 


• On EX3300 switches, when you load the factory default settings, the last two ports of 

the uplink ports are configured as Virtual Chassis ports (VCPs). If you convert these 

ports to normal network ports, they might not pass traffic. As a workaround, reboot 

the switch after converting the ports. [PR/685300: This issue has been resolved.] 

• On EX4200 switches, the EZSetup menu is not displayed on the LCD after you perform 

a factory-default configuration. [PR/712322: This issue has been resolved.] 


• On XRE200 External Routing Engines, the output of the show chassis hardware 

command might contain duplicate Routing Engine inventory information for members 8 

and 9. [PR/663272: This issue has been resolved.] 

• In EX4200 Virtual Chassis, if a member other than the master reboots from the backup 

partition, the system alarm Host # Boot from backup root should clear when that 

member is rebooted from the active partition. However, the master retains the alarm 

until it is rebooted or until the mastership switches. [PR/694256: This issue has been 

resolved.] 


35


• On EX8200 Virtual Chassis, LACP and all Layer 3 protocols flap constantly when an 

EX8200 member switch’s backup Routing Engine is rebooted, and the connection 

between the master XRE200 External Routing Engine and the EX8200 member switch 

might be lost. [PR/700295: This issue has been resolved.] 

• In mixed EX4200 and EX4500 Virtual Chassis, when you configure class of service, 

some traffic might be dropped because it is mapped to the incorrect queue. [PR/711071: 


• In a setup in which two XRE200 External Routing Engines (one acting as the master, 

the other as the backup) are connected to a member of an EX8200 Virtual Chassis 

that has two Routing Engines (one acting as the master, the other as the backup), if 

you remove the master Routing Engine or if you reboot this Routing Engine (for example, 

using the request system reboot member 0 re0 command when re0 is the master Routing 

Engine), interfaces on which the Link Aggregation Control Protocol (LACP) is configured 

might flap. This interface flapping does not occur if you remove or reboot the backup 

Routing Engine. [PR/718857: This issue has been resolved.] 

• On EX4500 Virtual Chassis, you cannot configure a mastership priority of 0 from the 

J-Web interface. As a workaround, configure this priority from the CLI. [PR/721426: 






• When an EX Series switch is reauthenticating users using 802.1X (dot1x), if the switch 

loses reachability to the RADIUS server, the dynamic filters that were installed when 

the same user was previously authenticated are not cleared, resulting in traffic issues. 


• On EX Series switches running Junos Release 11.x, LLDP packets might not be generated 

out of interfaces that are part of a LAG, causing LLDP neighbors not to form. As a 

workaround, follow these steps: 

1. Delete the lldp-med configuration. 

2. Commit the configuration. 

3. Delete the lldp configuration. 


5. Configure lldp again. 


7. (Optional) Configure lldp-med again. 

8. (Optional) Depending on Step 7, commit the configuration. 


36 



• You cannot configure the level for storm control. [PR/734307: This issue has been 

resolved.] 

• EX3200 switches might repeatedly create 802.1X core files. As a workaround, if access 

accounting is enabled, disable it by issuing the command deactivate access profile 

profile-name accounting. [PR/739921: This issue has been resolved.] 

• When you configure the Multiple VLAN Registration Protocol (MVRP), the LLDP process 

might create a core file as the result of a memory leak. [PR/740793: This issue has 


• If a VLAN change occurs quickly, the client might not be able to get an IP address. 



• When you change the spanning-tree protocol from RSTP or VSTP to MSTP, the Ethernet 

switching process (eswd) might create a core file. [PR/725436: This issue has been 

resolved.] 


• If you configure a firewall filter on a loopback interface whose last term is deny-all, 

static routes filtered with the reject action reach the CPU, and multicast trap and RPF 

fail packets are implicitly allowed to reach the CPU. [PR/710641: This issue has been 

resolved.] 

• If you configure both a regular analyzer and a firewall filter-based analyzer, the traffic 

from the regular analyzer might exit from the output port you configured for the firewall 

filter-based analyzer. [PR/724795: This issue has been resolved.] 

Hardware 

• If you power off and then restart an EX Series switch, the chassis process (chassisd) 

might not restart. This problem might also occur in switches that have redundant power 

supplies. [PR/708872: This issue has been resolved.] 


• On EX8200 switches and EX8200 Virtual Chassis that have nonstop active routing 

(NSR) for Protocol Independent Multicast (PIM) configured, some multicast data 

might be lost after a graceful Routing Engine switchover (GRES). [PR/690073: This 



• In some cases, broadcast traffic that is received on the management port (me0) is 

broadcast to other subnets on the switch. [PR/705584: This issue has been resolved.] 

• After a MAC address moves, the ARP index might not point to the correct MAC address. 

As a workaround, run the clear ethernet-switching table command. [PR/718698: This 


• A destination with two equal-cost next hops might not be installed in the Packet 

Forwarding Engine when a virtual management Ethernet (VME) interface is configured 


37


and a default route with a reachable next hop is present. As a workaround, remove 

and then re-add one of the two equal-cost next hops. [PR/719745: This issue has been 

resolved.] 

• The allow-configuration-regexps statement at the [edit system login class] hierarchy 

level does not work exactly the same way as the deprecated allow-configuration 

statement at the same hierarchy level. [PR/720013: This issue has been resolved.] 

• When you issue NTP-related show commands, such as show ntp status, incorrect 

output might be displayed. [PR/722528: This issue has been resolved.] 

• On EX4200 switches, after you issue the request system zeroize media command, you 

might not be able to establish a connection with the switch using SSH, and you might 

not be able to issue the commit command on the switch. [PR/723918: This issue has 


• On EX8208 switches, when the SRE module is in the spare state and you configure it 

to go offline and then come back online again, the module’s ST LED does not turn back 

on. [PR/724455: This issue has been resolved.] 

• After a graceful Routing Engine switchover (GRES) operation, clone routes might move 

into the reject state. [PR/724729: This issue has been resolved.] 

• On EX8200 switches, after you issue the request system zeroize media command, the 

line cards might not come online. [PR/728082: This issue has been resolved.] 

• If you include the autoinstallation configuration statement at the [edit system] hierarchy 

level, the switch interfaces might not work correctly. [PR/728344: This issue has been 

resolved.] 

• The Ethernet switching process (eswd) might create a core file. [PR/732263: This issue 


• When you quickly insert and then remove a line card, the chassis manager process 

(chassism) might become unstable. [PR/740730: This issue has been resolved.] 

• On EX8200 switches, a chassism core file might be created. [PR/745964: This issue 


• On all EX Series switches except EX8200 switches, if you have configured several 

policer settings in the same filter, they might all be overwritten when you change one 

of the settings. As a workaround, delete the setting, and then add it back again with 

the desired changes. [PR/750497: This issue has been resolved.] 

Interfaces 

• If you set an interface speed at the [edit interfaces interface-range] hierarchy level, this 

speed might not be applied to the individual interface. If you set different interface 

speeds directly on the interface and at the [edit interfaces interface-range] hierarchy 

level, both settings are applied on the interface. [PR/697478: This issue has been 

resolved.] 

• When you delete the VLAN mapping for an aggregated Ethernet (ae) interface, the 

Ethernet switching process (eswd) might crash and display the error message No vlan 

matches vlan tag 116 for interface ae5.0. [PR/731731: This issue has been resolved.] 

38 




• In the J-Web interface, the dashboard does not display the uplink ports or uplink module 

ports unless transceivers are plugged into the ports. [PR/477549: This issue has been 

resolved.] 

• When a large number of inbound HTTP connections are established over an extended 

period of time, the HTTP process (httpd) might become trapped in a loop, resulting in 

high CPU utilization. The CPU load continues even after the stream of connection 

attempts is terminated. To reduce the CPU load, you must kill the process from the 

shell. Two workarounds are to disable the J-Web interface, or to allow access to the 

J-Web interface only from trusted networks. Alternatively, apply a policer at the edge 

or on the control plane (lo0) to rate-limit inbound connections to TCP port 80. Note 

that the typical side effects of applying rate limiting to services (for example, an 

increased risk of successful DoS attacks) also apply to inbound J-Web interface 

connections, so be careful before making changes to control plane protection firewall 

filters. See RFC 6192 for guidance on protecting the switch’s control plane. [PR/693434: 


• In the Login/Splash screen and the Help mapping file, the copyright date is set to 2011; 

it should be 2012. [PR/731790: This issue has been resolved.] 

• On the J-Web dashboard, the Total number of ports field in the Capacity utilization 

page might show incorrect values for a mixed EX4200 and EX4500 Virtual Chassis. 

As a workaround, use the show chassis hardware | match PIC | except Virtual command 

to display the correct values. [PR/734766: This issue has been resolved.] 

• In the J-Web interface, if you click the EX8200-48T, EX8200-48F, or EX8200-8XS 

line card in the chassis view in the dashboard, the expanded line card might not load 

its interfaces and might not display the interface status for both the EX8208 and 

EX8216 switches. As a workaround, first click the EX8200-40XS in the same chassis 

view and then close that line card. Then click the EX8200-48T, EX8200-48F, or 

EX8200-8XS line card to display the status of all interfaces. [PR/742448: This issue 


• For EX Series switches, when you use the J-Web interface software upload package, 

the unlink option does not work. [PR/746546: This issue has been resolved.] 

• In the J-Web interface on an EX8200 switch that is in virtual-chassis mode, when you 

expand the number of uplink modules, line cards that have no uplink module report 

an error or map ports to nonexistent modules. This problem happens the first time that 

you configure capacity utilization values. [PR/750854: This issue has been resolved.] 


• When you configure a static route that has two multihop paths, BFD might become 

unstable, and the routing protocol process (rpd) might crash. [PR/701966: This issue 


• If PIM remains in the assert state, the routing protocol process (rpd) might create a 

core file. [PR/711150: This issue has been resolved.] 


39



• On EX4200 switches and EX4200 Virtual Chassis, the event process (eventd) process 

might create a core file. [PR/737893: This issue has been resolved.] 

MPLS 

• On EX3200 and EX4200 switches, no counters are incremented in MPLS statistics 

files for label-switched paths (LSPs) that are used for circuit cross-connects (CCCs). 



• When you use NSSU to upgrade from Junos OS Release 11.3R5, all traffic across a link 

aggregation group (LAG) might be dropped. [PR/733050: This issue has been resolved.] 

• The unlink option in the request system software add package unlink command does 

not work on EX Series switches. [PR/739795: This issue has been resolved.] 


• On EX4200 Virtual Chassis, if you delete an uplink interface on which the family mpls 

option is configured, the MPLS functionality on the corresponding symmetric interfaces 

on the other members might be affected. [PR/704480: This issue has been resolved.] 

• In a setup in which two XRE200 External Routing Engines (one acting as the master, 

the other as the backup) are connected to a member of an EX8200 Virtual Chassis 

that has two Routing Engines (one acting as the master, the other as the backup), if 

you remove the master Routing Engine or if you reboot this Routing Engine (for example, 

using the request system reboot member 0 re0 command when re0 is the master Routing 

Engine), interfaces on which the Link Aggregation Control Protocol (LACP) is configured 

might flap. This interface flapping does not occur if you remove or reboot the backup 

Routing Engine. [PR/718857: This issue has been resolved.] 

• On an EX2200 switch used as an intermediary switch in an EX8200 Virtual Chassis 

setup, a link down is not detected after you reboot the partner XRE200 External Routing 

Engine. [PR/726501: This issue has been resolved.] 

• On EX8200 Virtual Chassis, messages in the system log (syslog) file might show that 

a temperature alarm has been set and then cleared clear even though there has been 

no environmental trigger. [PR/730498: This issue has been resolved.] 

• The XRE200 External Routing Engine temperature monitors, which you can view using 

the show chassis environment command, might report temperatures that are twice 

the actual temperature. This temperature-reporting error has no impact on XRE200 

External Routing Engine behavior. Because the fans and the system receive the correct 

temperature internally, unwanted fan speed changes or an XRE200 External Routing 

Engine shutdown cannot occur as a result of this misreported temperature. However, 

the incorrect reported temperatures generate alarms and alarm messages. [PR/734233: 


40 







• If multicast clients are present across virtual routing and forwarding (VRF) instances, 

multicast traffic might not be received when you deactivate and then reactivate one 

of the VRF instances. [PR/769963: This issue has been resolved.] 

Hardware 

• On EX3300 switches, power supply failure errors might occur. To circumvent this 

problem, a software workaround has been provided. The software reads the power 

supply bit multiple times before it declares the power supply module to be down. 


• EX4500 Series switches and EX8200-40XS line cards do not forward IP UDP packets 

when their destination port is 0x013f (PTP) or when the fragmented packet has the 

value 0x013f at the same offset (0x2c). [PR/775329: This issue has been resolved.] 


• On XRE200 External Routing Engines, when you specify the reboot option when 

performing a nonstop software upgrade (NSSU) operation, the physical link might flap 

because the Packet Forwarding Engine process (pfem) restarts on the line cards, 

resulting in traffic loss and protocol flapping. [PR/718472: This issue has been resolved.] 


• The request system zeroize command might not erase all files, such as files in the 

/config, /var/db/config, and /var/db directories. [PR/737916: This issue has been 

resolved.] 

• On EX4200 switches, a Packet Forwarding Engine process (pfem) core file might be 

created while the switch is running the PFE internal support script and saving the output 

to a file. [PR/749974: This issue has been resolved.] 

• You might see the following message in log files: Kernel/ (COMPOSITE NEXT HOP) 

failed, err 6 (No Memory). [PR/751985: This issue has been resolved.] 

• On EX8200 switch line cards, a Packet Forwarding Engine process (PFEM) process 

core file might be created as the result of a memory segmentation fault. [PR/757108: 



• If you used the CLI to create a redundant trunk link (RTG) group whose members are 

not trunk ports, you cannot edit this group from the J-Web interface. As a workaround, 

edit the group from the CLI. [PR/745458: This issue has been resolved.] 

• The J-Web interface is vulnerable to HTML cross-site–scripting attacks, also called 

XST or cross-site tracing. [PR/752398: This issue has been resolved.] 


41



• On XRE200 External Routing Engines, when you change link aggregation groups (LAGs), 

the trunk programming might become incorrect. [PR/733814: This issue has been 

resolved.] 

• On EX8200 Virtual Chassis, after you ungracefully remove the master Routing Engine 

from the EX8200 member switch, traffic might be interrupted for up to 2 minutes. 


• On EX3300 switches, when a Virtual Chassis is formed, the Virtual Chassis backup 

member’s console CLI does not automatically redirect to the Virtual Chassis master’s 

console CLI. As a workaround, manually log out from the Virtual Chassis backup 

member. [PR/744241: This issue has been resolved.] 

• On EX8200 Virtual Chassis, the switch might incorrectly send untagged packets. As a 

result, some hosts in the VLAN might experience connectivity issues. [PR/752021: This 






• If you enable 802.1X with MAC RADIUS authentication, that is, by including the 

mac-radius statement in the configuration, the authentication manager process (authd) 

might reach a memory limit when there are approximately 250 users. As a workaround, 

reset the authd process when it reaches 85 percent of its RLIMIT_DATA value (that is, 

85 percent of 130 MB). To check the amount of memory being used by the authd 

process, use the show system processes extensive operational mode command. 


• When you configure DHCP snooping, DHCP Inform ACK packets might not pass to the 

client. [PR/787161: This issue has been resolved.] 

• If you configure a static MAC bypass for 802.1X (dot1x) authentication and you add a 

new host to the exclusion list, the MAC addresses of existing hosts that have already 

been successfully authenticated using static MAC bypass might move to an incorrect 

VLAN. [PR/787679: This issue has been resolved.] 

• On XRE200 External Routing Engines on which DHCP snooping and dynamic ARP 

inspection are enabled, when packets are transmitting out a different line card type 

from the ingress interface, an SFID core file might be created. [PR/794293: This issue 


42 



Converged Networks (LAN and SAN) 

• On EX4500 switches, the DCBX protocol does not work. [PR795835: This issue has 



• When you add a new virtual routing and forwarding (VRF) instance, existing firewall 

filters might not be applied to the new VRF instance. [PR/786662: This issue has been 

resolved.] 


• In EX8200 Virtual Chassis, after one Virtual Chassis member is rebooted, the line card 

of the corresponding rebooted member switch is not brought down immediately, and 

hence the peer sees that the interfaces remain in the Up state. Additionally, the interface 

state is not cleared immediately in the switch card chassis kernel. The result is that 

the protocol session goes down, and traffic loss occurs even if you have configured 

nonstop active routing (NSR). [PR/754603: This issue has been resolved.] 


• On EX Series switches, during the MAC learning process, you might see an excessive 

number of log messages similar to MRVL-L2:mrvl_fdb_mac_entry_uc_set(). [PR/774675: 


• After you upgrade to Junos OS Release 11.4R3, 11.4R4, or 12.1R2, EX Series switches 

might stop responding to SNMP ifIndex list queries. As a workaround, restart the switch. 

If restarting the switch is not an option, restart the shared-memory daemon 

(shm-rtsdbd). [PR/782231: This issue has been resolved.] 

Interfaces 

• When VRRP is running between two EX8200 switches on a VLAN, after a master 

switchover, both switches might act as masters. [PR/752868: This issue has been 

resolved.] 

• When you issue the show vrrp brief command, a VRRP process (vrrpd) core file might 

be created. [PR/782227: This issue has been resolved.] 

• If you configure IPv6 and VRRP, the IPv6 VRRP MAC address might be used incorrectly 

as the source MAC address when routing traffic across VLANs. [PR/791586: This issue 



43



• On EX8200 switches and XRE200 External Routing Engines, when there is a high 

volume of PIM and IGMP join and leave activity, multicast next-hop tokens might 

become exhausted, leaving the switch unable to install next-hop multicast routes. As 

a result, the delivery of multicast traffic is affected. One symptom that this problem 

has occurred is the presence of the following messages in the system log (syslog) file: 

kernel: rnh_comp_request: RTM_ADD jpf_derived_token_alloc failed: 12; kernel: 

rt_alloc_new_indr_comp: indirect nexthop creation failed; kernel: rt_comp_get_new_fwdnh: 

can't get indirect nexthop. [PR/787302: This issue has been resolved.] 

Network Management and RMON 

• An incorrect ifType value might be displayed for counters on physical interfaces. 


• Using snmpwalk for SNMP polling does not work in logical routers. [PR/791859: This 



• On EX8200 Virtual Chassis, when you swap the members of a link aggregation group 

(LAG), a vmcore or ksyncd core file might be created on the backup Routing Engine. 


• After you change the physical speed on a Virtual Chassis member interface, an 

aggregated Ethernet (ae) interface might flap after you issue the next commit command 

to commit configuration changes. [PR/779404: This issue has been resolved.] 





• When access configuration is not required and the guest VLAN feature is configured, 

supplicants might not be authenticated using the guest VLAN, and they might remain 

in the connecting state. [PR/783606: This issue has been resolved.] 

• An EX6200 switch might send 802.1Q tagged frames out of access ports when DHCP 

snooping is configured. This might cause Apple Macintosh end devices not to properly 

receive an IP address from the DHCP server. [PR/804010: This issue has been resolved.] 

• On EX6200 switches, LLDP stops working if you execute the set 

ethernet-switching-options voip interface access-ports vlan command. [PR/829898: 


44 




• If you apply a policer to an interface, the policer might not work, and messages similar 

to the following are logged: dfw_bind_policer_template_to_filter:205 Binding policer 

fails. [PR/802489: This issue has been resolved.] 

Hardware 

• Non-Juniper Networks DAC cables do not work on EX Series switches. [PR/808139: 



• After you perform a nonstop software upgrade (NSSU), there might be a traffic outage 

for 150 seconds while the line cards are restarting. [PR/800460: This issue has been 

resolved.] 


• After you successfully install Junos OS, if you uninstall AI scripts, an mgd core file might 

be created. [PR/740554: This issue has been resolved.] 

• After an EX8200 switch has been up for several days, the line cards might reach 

100 percent CPU usage and then stay at 100 percent. [PR/752454: This issue has been 

resolved.] 

• On an EX8200 Virtual Chassis or a switch with redundant Routing Engines, when you 

swap the members of a link aggregation group (LAG), a vmcore or ksyncd core file 

might be created on the backup Routing Engine. [PR/793778: This issue has been 

resolved.] 

• On EX8200 switches, when you issue the request system reboot other-routing-engine 

command, a timeout error might be displayed before the Routing Engine initiates its 

reboot operation. [PR/795884: This issue has been resolved.] 

• On EX3300 switches, when you are configuring BGP authentication, after you have 

configured the authentication key, BGP peering is never established. [PR/803929: This 


• On EX8200 Virtual Chassis, if you issue the request system reboot command, the 

request system reboot all-members command, or the request system reboot member 

command, the Routing Engines on the member switch do not reboot even though the 

command display shows that they are rebooting. [PR/808915: This issue has been 

resolved.] 

• On EX4200 switches, high CPU usage might be due to console cable noise. [PR818157: 


• When an uplink module in the switch is operating in the 1-gigabit mode, a chassism 

core file might be created if you remove an SFP transceiver from one of the module's 

interfaces. As the chassism process restarts, all traffic passing through the interface 

is dropped. This problem happens with both copper and fiber SFPs. [PR/828935: This 



45


Interfaces 

• On EX Series switches, if you have configured a link aggregation group (LAG) with link 

protection, an interface on the backup member might drop ingress traffic. [PR/796348: 



• If you have configured nonstop active routing (NSR) for Protocol Independent Multicast 

(PIM), a core file might be created on an upstream router because of high churn in 

unicast routes or a continuous clearing of PIM join-distribution in the downstream 

router. To prevent this possibility, disable NSR for PIM. [PR/707900: This issue has 



• After a Routing Engine switchover, LACP and MIB process (mib2d) core files might be 

created. [PR/790966: This issue has been resolved.] 

• In EX3300 Virtual Chassis, if you perform an SNMP poll of jnxOperatingState for fan 

operation, the information for the last two members in the Virtual Chassis is incorrect. 


• On EX Series switches that have Power over Ethernet (PoE) capability, chassisd (the 

chassis daemon) might crash when running SNMP requests (for example, SNMP get, 

get-next, and walk requests) on pethMainPse objects. This is caused by the system 

trying to free memory that is already freed. As a workaround, do not run SNMP requests 

on pethMainPse objects. [PR/817311: This issue has been resolved.] 





• When you use the dynamic firewall filter allocation feature, if the filter ID string is very 

long and the reauthentication interval is very short, a memory leak might be observed 

with the 802.1x (dot1x) process. [PR/837183: This issue has been resolved.] 


• On EX2200 switches, overheat circuitry may be triggered and display the message, 

Triggering overheat circuitry at a temperature of around 0 degrees Celsius. [PR/609415: 


• The output of the show system users no-resolve command displays the resolved 

hostname. [PR/672599: This issue has been resolved.] 

• When many packets are queued up to have their next hop resolved, some packets 

might become corrupted. [PR/790201: This issue has been resolved.] 

46 



• When access security is configured using dynamic ARP inspection (DAI) or DHCP 

snooping along with VSTP, the VSTP BPDUs are blocked and not processed, which 

can create a looping condition. [PR/807134: This issue has been resolved.] 

• Traffic leaks might occur for unknown unicast and broadcast traffic from multiple 

VLANs when a MAC RADIUS-assigned VLAN is set on a switch interface through a 

server-initiated attribute change. If the 802.1x interface has VLAN100 assigned and 

the RADIUS server sends a different VLAN attribute (for example, 200 rather than 

100), after the interface is assigned in VLAN200, it also sends egress unknown unicast 

and broadcast traffic that belongs to VLAN100. [PR/829436: This issue has resolved.] 

• Multicast packets might be lost when the user switches from one IPTV channel to 

another. [PR/835538: This issue has been resolved.] 

• An SNMP poll might not return clear information for some field-replaceable units 

(FRUs), such as fans and power supplies. The FRU description might not indicate which 

physical switch contains the FRU. [PR/837332: This issue has been resolved.] 

• If you reboot the switch with the routed VLAN interface (RVI) disabled, then even if 

you reenable the RVI, the RVI traffic is not routed in the Packet Forwarding Engine; the 

traffic is trapped to the CPU and is policed by the rate limit in the Packet Forwarding 

Engine. [PR/838531: This issue is resolved.] 

• In a mixed-mode EX4500 and EX4200 Virtual Chassis, link aggregation may create a 

Packet Forwarding Engine (pfem) core file in some member switches. [PR/846498: 



• Creating a routed VLAN interface (RVI) and deleting the Layer 3 interface (making it 

pure Layer 2) leaves a stale entry in the ethernet switching table. This could cause 

communication issues until the stale entries are cleared on the switch. [PR/674739: 


• On an EX4200 switch configured for VLAN translation, Windows NetBios traffic might 

not be translated. [PR791131: This issue has been resolved.] 

• On EX Series switches, Cisco Discovery Protocol (CDP) and VLAN Trunking Protocol 

(VTP) do not work through the Layer 2 Tunneling Protocol (L2TP). [PR/842852: This 



• On EX8200 switches, sFlow monitoring technology packets were being generated 

with an incorrect source MAC address of 20:0b:ca:fe:5f:10. This issue has been fixed 

and EX8200 switches now use the outbound port’s MAC address as the source MAC 

address for the sFlow traffic. [PR/815366: This issue has been resolved.] 

• On EX Series switches, a configured OAM threshold value might get reset when the 

chassis is rebooted. [PR/829649: This issue has been resolved.] 

Related 

Documentation 



47



on page 11 






on page 49 

Changes to and Errata in Documentation for Junos OS Release 11.4 for EX Series Switches 

• Changes to the Junos OS for EX Series Switches Documentation on page 48 

• Errata on page 48 

Changes to the Junos OS for EX Series Switches Documentation 

There are no changes to the documentation for Junos OS Release 11.4 for EX Series 

switches. 

Errata 

This section lists outstanding issues with the documentation for Junos OS Release 11.4 

for EX Series switches. 


• On EX Series switches, you cannot configure a scheduler map on an individual interface 

that is a member of a link aggregation group (LAG). Instead, you must configure the 

scheduler map on the LAG itself (that is, on the aggregated Ethernet [ae] interface). 

[This issue was being tracked by PR/692629.] 

Ethernet Switching 

• In the topic Example: Setting Up Bridging with Multiple VLANs for EX Series Switches, one 

of the interfaces in the VLAN named “support” is incorrectly shown as ge-0/0/0.24. 

The correct interface name is ge-0/0/24.0. 

• The documentation for the vlans configuration statement incorrectly states the required 

privilege levels as routing and routing-control. The correct privilege levels for this 

statement are system and system-control. 

48 


Upgrade and Downgrade Instructions for Junos OS Release 11.4 for EX Series Switches 

Network Management and Monitoring 

• You can configure Ethernet OAM link fault management (LFM) on aggregated 

interfaces. 


• request system software validate—The documentation for the request system software 

validate command incorrectly states that this command is supported on EX Series 

switches. This command is not supported on any EX Series switches. [This issue is 

being tracked by PR/803185.] 

Related 

Documentation 



on page 11 





on page 49 


This section describes how to upgrade to or downgrade from Junos OS Release 11.4. 

NOTE: If you are upgrading from Junos OS Release 10.4R2 or earlier, you must 

install new loader software as part of the upgrade process. This special 

software upgrade takes a little more time to complete than a standard 

upgrade. See “Upgrading from Junos OS Release 10.4R2 or Earlier” on page 51 

for instructions. 

These instructions discuss the following subjects: 

• Upgrade and Downgrade Support Policy for Junos OS Releases on page 49 

• Upgrading from Junos OS Release 10.4R3 or Later on page 50 

• Upgrading from Junos OS Release 10.4R2 or Earlier on page 51 

• Downgrading to Junos OS Release 10.4R2 or Earlier on page 69 

• Downgrading to an Earlier Junos OS Release on page 69 

• Upgrading EX Series Switches Using NSSU on page 70 

Upgrade and Downgrade Support Policy for Junos OS Releases 

Support for upgrades and downgrades that span more than three Junos OS releases at 

a time is not provided, except for releases that are designated as Extended End-of-Life 

(EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can 


49


upgrade directly from one EEOL release to the next EEOL release even though EEOL 

releases generally occur in increments beyond three releases. 

You can upgrade or downgrade to the EEOL release that occurs directly before or after 

the currently installed EEOL release, or to two EEOL releases before or after. For example, 

Junos OS Releases 10.0, 10.4, and 11.4 are EEOL releases. You can upgrade from Junos OS 

Release 10.0 to Junos OS Release 10.4 or even from Junos OS Release 10.0 to Junos OS 

Release 11.4. However, you cannot upgrade directly from a non-EEOL release that is more 

than three releases before or after. For example, you cannot directly upgrade from 

Junos OS Release 10.3 (a non-EEOL release) to Junos OS Release 11.4 or directly 

downgrade from Junos OS Release 11.4 to Junos OS Release 10.3. 

To upgrade or downgrade from a non-EEOL release to a release more than three releases 

before or after, first upgrade to the next EEOL release and then upgrade or downgrade 

from that EEOL release to your target release. 

For more information on EEOL releases and to review a list of EEOL releases, see 

http://www.juniper.net/support/eol/junos.html . 

Upgrading from Junos OS Release 10.4R3 or Later 

This section contains the procedure for upgrading from Junos OS Release 10.4R3 or later 

to Junos OS Release 11.4. You can use this procedure to upgrade Junos OS on a standalone 

EX Series switch with a single Routing Engine and to upgrade all members of a Virtual 

Chassis or a single member of a Virtual Chassis. 

To upgrade Junos OS on a standalone EX6200 switch or EX8200 switch with dual Routing 

Engines, see Installing Software on an EX Series Switch with Redundant Routing Engines 

(CLI Procedure). 

To upgrade Junos OS on a switch with a single Routing Engine or on a Virtual Chassis: 

1. Download the software package as described in Downloading Software Packages from 

Juniper Networks. 

2. (Optional) Back up the current software configuration to a second storage option. 

See the Junos OS Installation and Upgrade Guide for instructions. 

3. (Optional) Copy the software package to the switch. We recommend that you use 

FTP to copy the file to the /var/tmp directory. 

This step is optional because you can also upgrade Junos OS using a software image 

that is stored at a remote location. 

4. Install the new software package on the switch: 

user@switch> request system software add package 

Replace package with one of the following paths: 

• /var/tmp/package.tgz—For a software package in a local directory on the switch 

• ftp://hostname/pathname/package.tgz or 

http://hostname/pathname/package.tgz—For a software package on a remote server 

50 



package.tgz is the name of the package; for example, 

jinstall-ex-4200-11.4R1.8-domestic-signed.tgz. 

To install software packages on all switches in a mixed EX4200 and EX4500 Virtual 

Chassis, use the set option to specify both the EX4200 package and the EX4500 

package: 

user@switch> request system software add set [package package] 

To install the software package on only one member of a Virtual Chassis, include the 

member option: 

user@switch> request system software add package member member-id 

Other members of the Virtual Chassis are not affected. To install the software on all 

members of the Virtual Chassis, do not include the member option. 

NOTE: To abort the installation, do not reboot your device. Instead, finish 

the installation, and then issue the request system software delete 

package.tgz command, where package.tgz is the name of the package; for 

example, jinstall-ex-8200-11.4R1.8-domestic-signed.tgz. This is the last 

chance to stop the installation. 

5. Reboot the switch to start the new software: 

user@switch> request system reboot 

To reboot only a single member in a Virtual Chassis, include the member option: 

user@switch> request system reboot member 

6. After the reboot has finished, log in and verify that the new version of the software is 

properly installed: 

user@switch> show version 

Upgrading from Junos OS Release 10.4R2 or Earlier 

Because of the introduction of resilient dual-root partitions in Junos OS Release 10.4R3, 

upgrading to Junos OS Release 11.4 from Junos OS Release 10.4R2 or earlier requires a 

different procedure than the one for upgrading from Junos OS Release 10.4R3 or later. 

The resilient dual-root partitions feature incorporates enhancements that add additional 

steps when you upgrade from a release that does not support resilient dual-root partitions 

to one that does. Once you are running a release that supports resilient dual-root 

partitions, such as Junos OS Release 11.4, future upgrades do not require these additional 

steps. 


51


The following points summarize the differences between this upgrade and previous 

upgrades: 

• The disk partitions are automatically reformatted to four partitions during the reboot 

of the switch that completes the Junos OS upgrade. The reformat increases the reboot 

time for EX8200 switches by 10 to 25 minutes per Routing Engine. For other switches, 

the increase in boot time is 5 to 10 minutes. 

• The configuration files in the /config directory are saved in volatile memory before the 

reformat and then restored after the reformat. However, the files in the /var directory 

are not saved and are lost after the upgrade. 

NOTE: We recommend that you copy your data files to external media 

using the request system snapshot command before you perform the 

upgrade. Files in the /var directory, such as log files and user /home 

directories, are not saved. In addition, a power failure during the reboot 

could cause the configuration files to be lost. 

• You must upgrade the loader software. You upgrade the loader software by installing 

the loader software package from the CLI. 

NOTE: To obtain the loader software package, see the Download Software 

page at http://www.juniper.net/support/downloads/junos.html . Click the 

version, then the Software tab, and then the name of the software install 

package. In the pop-up Alert box, click the link to the PSN document. 

On switches other than EX8200 switches, upgrading the loader software does not 

significantly increase upgrade time, because you can complete the upgrade of both 

Junos OS and the loader software with a single reboot. 

On EX8200 switches, upgrading the loader software requires an additional reboot per 

Routing Engine because of the way the loader software is stored in flash memory. On 

EX8200 switches only, you can verify that the loader software requires upgrading 

before you perform the upgrade—if the loader software does not need upgrading, the 

additional reboot per Routing Engine is not required. 

NOTE: If you upgrade to Junos OS Release 11.4 and do not upgrade the 

loader software, the switch comes up and functions normally. However, if 

the switch cannot boot from the active root partition, it cannot transparently 

boot from the alternate root partition either. 

Table 1 on page 53 lists the installation packages required to upgrade the loader 

software. 

52 



Table 1: Required Installation Packages for Upgrading the Loader Software 

Platform 

Installation Package 

EX2200 switch 

jloader-ex-2200-11.3build-signed.tgz 

EX3200 switch 


EX4200 switch 


EX4500 switch 


EX8200 switch 


XRE200 External Routing Engine 

The loader software does not need to be upgraded. 

• When you upgrade to a release that supports resilient dual-root partitions from one 

that does not, the upgrade process automatically copies the contents of the primary 

root partition to the alternate root partition at the end of the upgrade process. Because 

the resilient dual-root partitions feature enables the switch to boot transparently from 

the alternate root partition, we recommend that you use the request system snapshot 

command to copy the contents of the primary root partition to the alternate root 

partition after all Junos OS upgrades to releases that include dual-root partitions. 

NOTE: If you upgrade the loader software in a separate step after you upgrade 

Junos OS, users might see the following message when they log in to the 

switch: At least one package installed on this device has limited support 

This message can be safely ignored. 

You can permanently remove this message by deleting the loader software 

package and rebooting the system. For example, on an EX4200 switch: 

user@switch> request system software delete jloader-ex-3242 

Unmounted /packages/mnt/jloader-ex-3242-11.3 ... 


Reboot the system ? [yes,no] (no) yes 

The following sections include more detailed instructions for performing a software 

upgrade from Junos OS Release 10.4R2 or earlier: 

• Determining Whether the Loader Software Needs Upgrading on EX8200 Switches 

and EX8200 Virtual Chassis on page 54 

• Installing the Loader Software and Junos OS on EX2200, EX3200, Standalone EX4200, 

and Standalone EX4500 Switches on page 56 

• Upgrading the Loader Software and Junos OS on EX4200 Virtual Chassis on page 57 

• Upgrading the Loader Software on EX4500 Virtual Chassis and Mixed EX4200 and 

EX4500 Virtual Chassis on page 59 


53


• Upgrading Junos OS and the Loader Software on Standalone EX8200 


• Upgrading Junos OS and the Loader Software on EX8200 Virtual Chassis on page 63 

• Upgrading the Loader Software on the Line Cards in a Standalone EX8200 Switch or 

an EX8200 Virtual Chassis on page 67 

Determining Whether the Loader Software Needs Upgrading on EX8200 Switches and 

EX8200 Virtual Chassis 

Before you begin the software upgrade on an EX8200 switch or an EX8200 Virtual 

Chassis, determine whether the loader software on the Routing Engines and on the line 

cards needs upgrading. 

It is possible that a switch running a Junos OS release earlier than Junos OS Release 10.4R3 

has a version of the loader software installed on the Routing Engines that supports 

resilient dual-root partitions. For example, the switch might have been shipped from the 

factory with a Junos OS release earlier than Junos OS Release 10.4R3 but with a version 

of the loader software for the Routing Engines that supports resilient dual-root partitions. 

Or the switch might have been downgraded from a Junos OS release that supports 

resilient dual-root partitions but still retains a version of the loader software on the Routing 

Engines that supports resilient dual-root partitions. 

The line card loader software is factory installed and varies between line cards. 

NOTE: This procedure is available only on EX8200 switches. On all other 

switches, you must upgrade your Routing Engine loader software. 

NOTE: If you are upgrading the software multiple times, for example, from 

is Junos OS Release 10.3R2 to Junos OS Release 11.1R3 to Junos OS 

Release 11.4R1, we recommend that you complete the Junos OS software 

upgrade to Junos OS Release 11.4 and then upgrade the loader software. This 

reduces system downtime. 

54 



To determine whether the loader software needs upgrading: 

1. Determine the version of the loader software for the Routing Engines and the line 

cards: 

user@switch> show chassis firmware 

Part Type Version 

FPC 6 U-Boot U-Boot 1.1.6 (Jan 13 2009 - 06:55:22) 2.3.0 

loader FreeBSD/PowerPC U-Boot bootstrap loader 2.2 

FPC 7 U-Boot U-Boot 1.1.6 (Jan 13 2009 - 06:55:22) 2.3.0 


Routing Engine 0 U-Boot U-Boot 1.1.6 (Mar 11 2011 - 04:29:01) 3.5.0 




NOTE: On an EX8200 Virtual Chassis, you cannot execute the show chassis 

firmware command on the master external Routing Engine. You must 

execute this command on each member switch: 

1. From the master external Routing Engine, start a shell session on the 

member switch. For example: 

user@external-routing-engine> request session member 0 

2. Enter the CLI and execute the show chassis firmware command. 

3. Repeat these steps for the other member switch. 

The loader software version appears after the timestamp for U-Boot 1.1.6. In the 

preceding example, the version is 3.5.0. (Ignore the U-Boot version number [1.1.6]; it 

has nothing to do with the loader software version that you need to determine.) 

2. If the loader software version is 3.5.0 or later for Routing Engine 0 or Routing Engine 1, 

your loader software does not need upgrading to support resilient dual-root 

partitioning. To upgrade to Junos OS Release 11.4, install Junos OS, by following the 

standard installation procedures; see “Upgrading from Junos OS Release 10.4R3 or 

Later” on page 50. 

3. If the loader software version is earlier than 3.5.0 for Routing Engine 0 or Routing 

Engine 1, you must upgrade the loader software. Follow the instructions in “Upgrading 

Junos OS and the Loader Software on Standalone EX8200 Switches” on page 60 or 

“Upgrading Junos OS and the Loader Software on EX8200 Virtual Chassis” on page 63. 

4. If the loader software version is earlier than 3.5.0 for any FPC, consider upgrading the 

loader software for that line card. 

Upgrading the loader software version for a line card is not a requirement to complete 

any software upgrade. In rare cases, a line card might go offline immediately after a 

software upgrade because the loader software version on the line card requires an 

upgrade to become compatible with the upgraded Junos OS. 

Upgrading the loader software version to version 3.5.0 on the line cards as a best 

practice helps you avoid this problem and other less severe issues. 


55


Follow the instructions in “Upgrading the Loader Software on the Line Cards in a 

Standalone EX8200 Switch or an EX8200 Virtual Chassis” on page 67 to complete 

the line card loader software upgrade procedure. 

Installing the Loader Software and Junos OS on EX2200, EX3200, Standalone EX4200, 

and Standalone EX4500 Switches 

To upgrade the loader software and Junos OS on EX2200, EX3200, standalone EX4200, 

and standalone EX4500 switches: 

1. Download the loader software package and the Junos OS package from the Juniper 

Networks website as described in Downloading Software Packages from Juniper 

Networks. Place the software packages on an internal software distribution site or in 

a local directory on the switch. We recommend using /var/tmp as the local directory 

on the switch. 





2. Install the loader package: 



• For a software package in the /var/tmp directory on the 

switch—/var/tmp/package.tgz 

• For a software package on a remote server: 

• ftp://hostname/pathname/package.tgz 

• http://hostname/pathname/package.tgz 

where package.tgz is, for example, jloader-ex-3242-11.3build-signed.tgz. 

3. Install the Junos OS package, following the same procedure you used to install the 

loader software package. 

4. Reboot the switch: 



If you are monitoring the reboot from the console, you see messages similar to the 

following during the partition reformat: 

Disk needs to be formatted in order to proceed 

Saving the configuration in memory before formatting the disk 

FILE SYSTEM CLEAN; SKIPPING CHECKS 

clean, 31543 free (10 frags, 3953 blocks, 0.0% fragmentation) 

32+0 records in 

32+0 records out 

16384 bytes transferred in 0.033161 secs (494075 bytes/sec) 

******* Working on device /dev/da0 ******* 

56 



. 

. 

. 

Restoring configuration 

5. Verify that the loader software has been upgraded: 



FPC 0 uboot U-Boot 1.1.6 (Mar 28 2011 - 04:09:20) 1.0.0 

2.4 

loader 

FreeBSD/PowerPC U-Boot bootstrap loader 

The U-Boot version that follows the date information must be 1.0.0 or later. 

6. Verify that Junos OS has been upgraded: 


Upgrading the Loader Software and Junos OS on EX4200 Virtual Chassis 

You perform the upgrade of the loader software and Junos OS on an EX4200 Virtual 

Chassis from the Virtual Chassis master switch. The master switch pushes the installation 

packages to all Virtual Chassis members. 

NOTE: A Virtual Chassis is required to have the same version of Junos OS 

installed on all members in the Virtual Chassis. We do not recommend that 

you install different versions of Junos OS on individual members of a Virtual 

Chassis or that you upgrade members individually. Upgrading individual 

members of a Virtual Chassis is not recommended, and could cause Virtual 

Chassis instability if multiple Junos OS versions are running on individual 

members in a Virtual Chassis. See Understanding Automatic Software Update 

on EX4200 and EX4500 Virtual Chassis Member Switches and Replacing a 

Member Switch of an EX4200 or EX4500 Virtual Chassis Configuration (CLI 

Procedure). 

To upgrade the loader software and Junos OS: 




a local directory on the master switch. We recommend using /var/tmp as the local 

directory on the master switch. 





2. Log in to the master switch of the Virtual Chassis. 


57


3. Install the loader software package: 

• To install the package on all members of the Virtual Chassis: 


• To install the package on a single member of the Virtual Chassis: 









4. Install the Junos OS package, following the same procedure you used to install the 

loader software package. 

5. Reboot the Virtual Chassis (to reboot a single member, use the member option): 



If you are monitoring the reboot from the console, you see messages similar to the 

following during the disk reformat: 

Disk needs to be formatted in order to proceed 

Saving the configuration in memory before formatting the disk 

FILE SYSTEM CLEAN; SKIPPING CHECKS 

clean, 31543 free (10 frags, 3953 blocks, 0.0% fragmentation) 

32+0 records in 

32+0 records out 

16384 bytes transferred in 0.033161 secs (494075 bytes/sec) 

******* Working on device /dev/da0 ******* 

. 

. 

. 

Restoring configuration 

6. Verify that the new version of the loader software is on all members of the Virtual 

Chassis: 


fpc0: 

-------------------------------------------------------------------------- 







7. Verify that the new Junos OS release is on all members of the Virtual Chassis: 


58 



Upgrading the Loader Software on EX4500 Virtual Chassis and Mixed EX4200 and 


To create an EX4500 Virtual Chassis or a mixed EX4200 and EX4500 Virtual Chassis, 

you must upgrade Junos OS on the member switches to Junos OS Release 11.1 or later 

before you form the Virtual Chassis. For instructions on how to upgrade Junos OS and 

the loader software on the member switches before they are part of the Virtual Chassis, 

see “Installing the Loader Software and Junos OS on EX2200, EX3200, Standalone 

EX4200, and Standalone EX4500 Switches” on page 56. 

If you did not upgrade the loader software on one or more of the member switches before 

you formed the Virtual Chassis, you can use the following procedure to upgrade the loader 

software on member switches after the Virtual Chassis is formed. 

To upgrade the loader software: 

1. Download the loader software package from the Juniper Networks website as 

described in Downloading Software Packages from Juniper Networks. Place the software 

packages on an internal software distribution site or in a local directory on the master 

switch. We recommend using /var/tmp as the local directory on the master switch. 





For a mixed EX4200 and EX4500 Virtual Chassis, you must download the loader 

packages for both switches. 

2. Log in to the master of the Virtual Chassis. 

3. Install the loader software package: 

• To install the package on all members of an EX4500 Virtual Chassis: 


• To install the package on all members of a mixed EX4200 and EX4500 Virtual 

Chassis: 

user@switch> request system software add set [ex4200-package ex4500-package] 

• To install the package on a single member of the Virtual Chassis: 


4. Reboot the Virtual Chassis (to reboot a single member, use the member option): 



5. Verify that the correct version of the loader software is on all members of the Virtual 

Chassis: 


fpc0: 


59


-------------------------------------------------------------------------- 







Upgrading Junos OS and the Loader Software on Standalone EX8200 Switches 

On EX8200 switches, you must upgrade Junos OS before you can upgrade the loader 

software. 

The loader software for an EX8200 Routing Engine resides in two flash memory banks. 

One bank acts as the primary bank, and the Routing Engine boots from it. The other bank 

is the backup bank—if the Routing Engine cannot boot from the primary bank, it boots 

from the backup bank. When you upgrade the loader software, the upgraded software 

is installed in the backup bank, which then becomes the new primary bank. Thus the 

primary and backup banks alternate each time you upgrade the loader software, with 

the primary bank containing the most recently installed version of the software and the 

backup bank containing the previous version. 

To upgrade the loader software on an EX8200 Routing Engine, you must perform the 

upgrade twice: once for each bank. Each upgrade requires a reboot of the Routing Engine. 

NOTE: If you do not upgrade the loader software in both banks and the 

Routing Engine boots from the previous version of the loader software in the 

backup bank, the Routing Engine cannot boot transparently from the alternate 

root partition if it attempts to do so, because it cannot boot from the primary 

root partition. 

For an EX8200 switch with redundant Routing Engines, you must upgrade the loader 

software on both Routing Engines. 

60 



To upgrade the Junos OS and loader software on an EX8200 switch: 

1. Download and install the Junos OS package on each Routing Engine as described in 

Installing Software on an EX Series Switch with Redundant Routing Engines (CLI 

Procedure) or Installing Software on an EX Series Switch with a Single Routing Engine 

(CLI Procedure). 

NOTE: If you are also upgrading the loader software on one or more line 

cards, we recommend that you perform the loader software upgrade at 

this point of the procedure. See “Upgrading the Loader Software on the 

Line Cards in a Standalone EX8200 Switch or an EX8200 Virtual Chassis” 

on page 67. 

2. Download the loader software package from the Juniper Networks website and place 

the software package on an internal software distribution site or in a local directory 

on the switch. We recommend using /var/tmp as the local directory on the switch. 





3. Log in to the switch and enter the shell. We recommend using a console connection. 

4. (For a switch with a single Routing Engine, skip this step.) Enter the CLI, and determine 

which is the master and which is the backup Routing Engine: 

user@switch> show chassis routing-engine 

NOTE: If you do not have GRES enabled, you cannot use this command 

to determine which is the master and which is the backup Routing Engine. 

You can instead enter the shell and use this command to determine 

mastership: 

% sysctl hw.re.mastership 

A return of the value 1 means the Routing Engine on which you are logged 

in is the master. A return of the value 0 means the Routing Engine on which 

you are logged in is the backup. 

5. Enter the configuration mode and disable graceful Routing Engine switchover (GRES) 

and nonstop active routing (NSR): 

user@switch# deactivate chassis redundancy graceful-switchover 

user@switch# deactivate routing-options nonstop-routing 

6. Log in to the backup Routing Engine: 

user@switch> request routing-engine login other-routing-engine 



61










8. Determine the primary bank and the version of the loader software in the bank: 

% kenv | grep boot.primary.bank 

boot.primary.bank="0" 

% kenv | grep boot.ver 

boot.ver="2.4.0" 

9. Upgrade the firmware: 

user@switch> request system firmware upgrade scb 

Firmware upgrade initiated.... 

Please wait for ~2mins for upgrade to complete.... 

10. After waiting for a couple of minutes, reboot the Routing Engine: 



11. Enter the shell and verify that the previous backup bank is now the primary bank and 

that it contains the upgraded loader software: 

% kenv | grep boot.primary.bank 

boot.primary.bank="1" 

% kenv | grep boot.ver 

boot.ver="3.5.0" 

12. To install the loader software in the current backup bank, repeat Step 7 through Step 11. 

NOTE: If you installed the loader software package from the /var/tmp 

directory, you might need to copy the loader software package to the 

/var/tmp directory again before you can repeat Step 7 through Step 11, 

because it is sometimes removed after each installation. 

13. (Optional) The following message might be displayed when a user logs in to the 

system: 

--- JUNOS 11.4R1.9 built 2011-03-19 22:06:32 UTC 

At least one package installed on this device has limited support. 

Run 'file show /etc/notices/unsupported.txt' for details.. 

This message can be safely ignored. It appears as a result of upgrading the loader 

software after you upgrade Junos OS. 

You can permanently remove this message by removing the loader software package 

and rebooting the system: 

62 



user@switch> request system software delete jloader-ex-8200 

Unmounted /packages/mnt/jloader-ex-8200-11.3 ... 



14. From configuration mode, reenable graceful Routing Engine switchover (GRES) and 

nonstop active routing (NSR): 

user@switch# activate chassis redundancy graceful-switchover 

user@switch# activate routing-options nonstop-routing 

15. After completing the upgrade of the loader software on the backup Routing Engine, 

perform a master switchover so the backup Routing Engine becomes the master: 

user@switch> request chassis routing-engine master switch 

Toggle mastership between routing engines ? [yes,no] (no) yes 

Resolving mastership... 

Complete. The other local routing engine becomes the master. 

{backup} 

user@switch> 

16. Follow the same procedure for upgrading the loader software that you used for the 

original backup Routing Engine (Step 3 through Step 14). 

Upgrading Junos OS and the Loader Software on EX8200 Virtual Chassis 

On EX8200 Virtual Chassis, you must upgrade Junos OS before you can upgrade the 

loader software. If you are upgrading the loader software for the Routing Engines and 

for one or more line cards, we recommend that you upgrade the loader software on the 

line cards before upgrading the loader software on the Routing Engines. 

NOTE: A Virtual Chassis must have the same version of Junos OS installed 

on all members of the Virtual Chassis. We do not recommend installing 

different versions of Junos OS on individual members of a Virtual Chassis or 

upgrading members individually, because the multiple Junos OS versions 

could cause instability. 

As described in “Upgrading Junos OS and the Loader Software on Standalone EX8200 

Switches” on page 60, the loader software for a Routing Engine resides in two flash 

memory banks, and both banks must be upgraded with the new loader software. 


63


To upgrade Junos OS and the loader software: 




a local directory on the master external Routing Engine. We recommend using /var/tmp 

as the local directory. 





2. Log in to the master external Routing Engine. 

3. Install the Junos OS package: 

user@external-routing-engine> request system software add package 







where package.tgz is, for example, jinstall-ex-xre200-11.3R1.8-domestic-signed.tgz. 

4. Reboot the Virtual Chassis: 

user@external-routing-engine> request system reboot 


5. After the reboot finishes, verify that Junos OS has been upgraded on all members: 

user@external-routing-engine> show version 

NOTE: If you are also upgrading the loader software on one or more line 

cards, we recommend that you perform the loader software upgrade at 

this point of the procedure. See “Upgrading the Loader Software on the 

Line Cards in a Standalone EX8200 Switch or an EX8200 Virtual Chassis” 

on page 67. 

6. Disable graceful Routing Engine switchover (GRES) and nonstop active routing (NSR): 

user@switch> deactivate chassis redundancy graceful-switchover 

user@switch> deactivate routing-options nonstop-routing 


user@external-routing-engine> request system software add package 

64 



Replace package with the path to the loader package. 

The package is pushed to each member switch from the master external Routing 

Engine. 

8. Upgrade the loader software in the current backup banks on both Routing Engines on 

a member switch (member 0 is used in the command examples): 

a. Enter the CLI and log in to the member switch: 


b. Upgrade the firmware in the backup bank on the master Routing Engine: 




c. Wait a couple of minutes and then reboot the Routing Engine: 



d. Upgrade the firmware in the current backup bank of the backup Routing Engine 

(now the master) by repeating Step a through Step c. 

Because the loader software has been upgraded in the backup banks, they now 

become the primary banks. 

9. After the reboots of the Routing Engines finish, log in to the member switch again and 

verify that the loader software has been upgraded in the primary banks: 




FPC 1 U-Boot U-Boot 1.1.6 (Mar 25 2009 - 06:13:12) 2.4.0 


FPC 5 U-Boot U-Boot 1.1.6 (Nov 5 2008 - 09:16:00) 

loader FreeBSD/PowerPC U-Boot bootstrap loader 





The U-Boot version that appears after the build date and time must be 3.5.0 or later. 

10. Upgrade the loader software in the new backup banks on both Routing Engines on 

the member switch: 

a. Upgrade the firmware in the backup bank on the master Routing Engine: 




b. Perform a master switchover to make the backup Routing Engine the master 

Routing Engine: 

user@switch> request chassis routing-engine master switch 

Toggle mastership between routing engines ? [yes,no] (no) yes 


65


You are returned to the master external Routing Engine after the master switchover. 

c. Log back in to the member switch: 


d. Upgrade the firmware in the backup bank on the new master Routing Engine: 




e. Verify that the loader software has been upgraded in the new primary banks on 

both Routing Engines: 



FPC 1 U-Boot U-Boot 1.1.6 (Mar 25 2009 - 06:13:12) 2.4.0 


FPC 5 U-Boot U-Boot 1.1.6 (Nov 5 2008 - 09:16:00) 

loader FreeBSD/PowerPC U-Boot bootstrap loader 





f. Exit to the master external Routing Engine. 

11. Reenable graceful Routing Engine switchover (GRES) and nonstop active routing 

(NSR): 

user@switch> activate chassis redundancy graceful-switchover 

user@switch> activate routing-options nonstop-routing 

12. Upgrade the loader software on the other member switch in the Virtual Chassis by 

repeating Step 7 through Step 9. 

66 



Upgrading the Loader Software on the Line Cards in a Standalone EX8200 Switch or an 


The loader software on any line card in an EX8200 switch is updated using the same 

loader software package that upgrades the EX8200 Routing Engine loader software. 

The line card software loader contains two banks, each with a single loader software 

version. This procedure is used to upgrade the loader software for both banks of a line 

card in a standalone EX8200 switch or an EX8200 Virtual Chassis. 

NOTE: If you are upgrading Junos OS, the Routing Engine loader software, 

and the line card loader software, we recommend that you upgrade in this 

order: Junos OS software, line card loader software, Routing Engine loader 

software. 

NOTE: If you have already downloaded and installed the loader software 

package, proceed to Step 3. 

1. Download the loader software package from the Juniper Networks website and place 

the software package on an internal software distribution site or in a local directory 

on the switch. We recommend using /var/tmp as the local directory on the switch. 





2. Disable graceful Routing Engine switchover (GRES) and nonstop active routing (NSR), 

if enabled. Commit the configuration: 

user@switch# deactivate chassis redundancy graceful-switchover 

user@switch# deactivate routing-options nonstop-routing 

user@switch# commit synchronize 




• For a software package in the /var/tmp directory on the switch or external Routing 

Engine—/var/tmp/package.tgz 





4. Upgrade the loader software. 


67


• To upgrade the loader software for a line card on a standalone EX8200 switch: 

user@switch> request system firmware upgrade fpc slot slot-number 



• To upgrade the loader software for a line card on an EX8200 member switch in an 

EX8200 Virtual Chassis: 

user@switch> request system firmware upgrade fpc slot slot-number member member-id 



5. Confirm the loader software upgrade: 

user@switch> show system firmware 

Part Type Tag Current Available Status 

version version 

FPC 6 U-Boot 0 2.3.0 UPGRADED SUCCESSFULLY 

FPC 7 U-Boot 0 2.3.0 OK 

Routing Engine 0 RE BIOS 0 3.1.1 OK 

Routing Engine 1 0 3.1.1 OK 

The status is UPGRADED SUCCESSFULLY if the boot loader version update process 

is complete. 

The status is PROGRAMMING if the boot loader version update process is still in 

progress. 

Do not proceed to the next step until the show system firmware command output 

confirms that the loader software upgrade is complete. 

6. Restart the line card. 

• To restart a line card on a standalone EX8200 switch: 

user@switch> request chassis fpc restart slot slot-number 

• To restart a line card on an EX8200 member switch in an EX8200 Virtual Chassis: 

user@switch> request chassis fpc restart slot slot-number member member-id 

NOTE: You can monitor the status of the line card restart by using the 

show chassis fpc command. 

7. After the line card restart finishes, confirm the loader software version update: 


Part Type Tag Current Available Status 

version version 



Routing Engine 0 RE BIOS 0 3.1.1 OK 

Routing Engine 1 0 3.1.1 OK 

The current version has been updated to 3.5.0. You have upgraded the loader software 

for one bank of the line card. 

8. Repeat Step 4 through Step 7 to upgrade the loader software on the other bank of 

the line card. 

68 



NOTE: A bank switchover occurs automatically as part of the line card 

restart. Repeating Step 3 through Step 6 updates the loader software on 

the other bank. 

9. Repeat Step 4 through Step 8 for all other line cards that require a line card loader 

version upgrade. 

Downgrading to Junos OS Release 10.4R2 or Earlier 

When you downgrade to Junos OS Release 10.4R2 or earlier, which are releases that do 

not support resilient dual-root partitions, the downgrade process automatically: 

• Reformats the disk from four partitions to three partitions during the reboot of the 

switch that completes the Junos OS downgrade. The reformat causes a one-time 

increase in reboot time of 10 to 25 additional minutes per Routing Engine for EX8200 

switches and 5 to 10 additional minutes for other switches. 

• Disables the boot-sequencing function of the loader software. With the boot-sequencing 

function disabled, the loader software behaves as it did before resilient dual-root 

partitions were introduced. The loader software itself is not downgraded—there is no 

need to downgrade it. 

To downgrade to Junos OS Release 10.4R2 or earlier: 

1. Use the request system snapshot command to save your data files to external media 

before you perform the downgrade. 

NOTE: Files in the /config directory are saved and restored during the 

downgrade process. However, files in the /var directory, such as log files 

and user /home directories, are not saved. In addition, a power failure 

during the reboot could cause the configuration files to be lost. 

2. Install Junos OS. 

Downgrading to an Earlier Junos OS Release 

CAUTION: Before you begin the software downgrade on your EX Series switch, 

you must verify the minimum Junos OS release supported on the switch and 

the components installed in the switch. Do not downgrade the software on 

a switch to a release prior to the first Junos OS release that supports the 

switch or a given component. 

To verify the first Junos OS release supported on your switch, see: 

• EX2200 Switch Models 



69





• Line Card Model and Version Compatibility in an EX8200 Switch 

Upgrading EX Series Switches Using NSSU 

You can use nonstop software upgrade (NSSU) to upgrade Junos OS releases on EX8200 

standalone switches and EX8200 Virtual Chassis. For instructions on how to perform an 

upgrade using NSSU, see Upgrading Software on an EX8200 Standalone Switch Using 

Nonstop Software Upgrade (CLI Procedure) or Upgrading Software on an EX8200 Virtual 

Chassis Using Nonstop Software Upgrade (CLI Procedure). 

Table 2 on page 70 details NSSU support per Junos OS release and provides pointers to 

any known issues for particular upgrade scenarios. 

Table 2: Using NSSU to Upgrade Junos OS on EX8200 Switches and EX8200 Virtual Chassis 

Switch 

Platform 

Upgrade 

from 

Junos 

OS 

Release 

x.x 

Upgrade 

to Junos 

OS 


10.4R4 or 

Later 

Upgrade to 

Junos OS 


Upgrade to 

Junos OS 


or Later 

Upgrade to 

Junos OS 


or Later 

Upgrade to 

Junos OS 


or Later 

Upgrade to 

Junos OS 


or Later 

EX8200 

standalone 

switch 

10.4 or 

later 

Not 

supported 

Not supported 

Not supported 

Not supported 

Not supported 

Not supported 

11.1R1 or 

later 

– 

Supported 

Supported 

Supported 

Supported 

Supported 

11.2R1 or 

later 

– 

– 

– 

Supported 

Supported 

Supported 

11.3R1 or 

later 

– 

– 

– 

– 

Supported 

Supported 

11.4R1 

– 

– 

– 

– 

– 

Supported 

70 



Table 2: Using NSSU to Upgrade Junos OS on EX8200 Switches and EX8200 Virtual 

Chassis (continued) 

Switch 

Platform 

Upgrade 

from 

Junos 

OS 


x.x 

Upgrade 

to Junos 

OS 


10.4R4 or 

Later 

Upgrade to 

Junos OS 


Upgrade to 

Junos OS 


or Later 

Upgrade to 

Junos OS 


or Later 

Upgrade to 

Junos OS 


or Later 

Upgrade to 

Junos OS 


or Later 

EX8200 

Virtual 

Chassis 

10.4R1 or 

later 

Not 

supported 

Not supported 

Not supported 

Not supported 

Not supported 

Not supported 

11.1R1, 

11.1R2, or 

11.1R3 

– 

Not 

recommended 

Not 

recommended 

Not 

recommended 

Not 

recommended 

Not 

recommended 

11.1R4 

– 

Not 

recommended 

Supported 

Supported 

Supported 

Supported 

11.1R5 or 

later 

– 

– 

Supported 

Supported 

Supported 

Supported 

11.2R1 or 

later 

– 

– 

– 

Supported 

Supported 

Supported 

11.3R1 or 

later 

– 

– 

– 

– 

Supported 

Supported 

11.4R1 or 

later 

– 

– 

– 

– 

– 

Supported 

On an EX8200 Virtual Chassis, an NSSU operation can be performed only if you have 

configured the XRE200 External Routing Engine member ID to be 8 or 9. 

NOTE: If you are using NSSU to upgrade the software on an EX8200 switch 

from Junos OS Release 11.1 and sFlow technology is enabled, disable sFlow 

technology before you perform the upgrade using NSSU. After the upgrade 

is complete, you can reenable sFlow technology. If you do not disable sFlow 

technology before you perform the upgrade with NSSU, sFlow technology 

does not work properly. This issue does not affect upgrades from Junos OS 

Release 11.2 or later. 


71


NOTE: If you are using NSSU to upgrade the software on an EX8200 switch 

from Junos OS Release 11.1 and NetBIOS snooping is enabled, disable NetBIOS 

snooping before you perform the upgrade using NSSU. After the upgrade is 

complete, you can reenable NetBIOS snooping. If you do not disable NetBIOS 

snooping before you perform the upgrade with NSSU, NetBIOS snooping 

does not work properly. This issue does not affect upgrades from Junos OS 


Related 

Documentation 



on page 11 






72 


Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D Universal Edge Routers, and T Series Core Routers 

Junos OS Release Notes for M Series Multiservice Edge Routers, MX Series 3D Universal 

Edge Routers, and T Series Core Routers 

• New Features in Junos OS Release 11.4 for M Series, MX Series, and T Series 

Routers on page 73 

• Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release 

11.4 for M Series, MX Series, and T Series Routers on page 153 

• Issues in Junos OS Release 11.4 for M Series, MX Series, and T Series Routers on page 172 

• Errata and Changes in Documentation for Junos OS Release 11.4 for M Series, MX Series, 

and T Series Routers on page 293 

• Upgrade and Downgrade Instructions for Junos OS Release 11.4 for M Series, MX Series, 


New Features in Junos OS Release 11.4 for M Series, MX Series, and T Series Routers 

The following features have been added to Junos OS Release 11.4. Following the 

description is the title of the manual or manuals to consult for further information. 

• Class of Service on page 74 

• High Availability on page 78 

• Interfaces and Chassis on page 80 

• Junos OS XML API and Scripting on page 101 

• Layer 2 Ethernet Services on page 103 

• MPLS Applications on page 104 

• Multicast on page 107 

• Network Management on page 108 

• Routing Protocols on page 113 

• Services Applications on page 114 

• Subscriber Access Management on page 117 

• System Logging on page 145 

• User Interface and Configuration on page 151 

• VPNs on page 152 


73



• Support for DSCP classification on customer edge links for CCC, TCC, and VPLS 

(MX Series routers with MPC/MIC interfaces)—Extends support for DSCP-based 

behavior aggregate (BA) classification for circuit cross-connect (CCC), translational 

cross-connect (TCC), and virtual private LAN service (VPLS) on MX Series routers with 

MPC/MIC interfaces. 

DSCP-based services provide support for a uniform end-to-end quality-of-service 

(QoS) model. By using the DSCP classifier, you can apply the QoS configuration for 

the CCC, TCC, and VPLS families at the IP level. Therefore, you do not have to depend 

on the underlying Layer 2 QoS support. 

[Class of Service] 

• Support for Layer 2 features on Channelized SONET/SDH OC3/STM1 (Multi-Rate) 

MICs with SFP (MX Series routers)—The following Layer 2 features are supported on 

the Channelized SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP: 

• Support for configuring interface MTU settings (range: 256–9192 bytes). 

• Support for configuring High-Level Data Link Control (HDLC) payload scrambling. 

• Support for crc-16 and crc-32 HDLC CRC checking modes. 

• Support for configuring HDLC idle cycle flag. The default idle cycle transmit value is 

is 0x7E. 

• Support for the following encapsulations: 

• cisco-hdlc—Cisco-compatible HDLC framing 

• cisco-hdlc-ccc—Cisco-compatible HDLC framing for a circuit cross-connect 

• cisco-hdlc-tcc—Cisco-compatible HDLC framing for a translational cross-connect 

• flexible-frame-relay—Multiple Frame Relay encapsulations 

• frame-relay—Frame Relay encapsulation 

• frame-relay-ccc—Frame Relay for a circuit cross-connect 

• frame-relay-tcc—Frame Relay for a translational cross-connect 

• frame-relay-ppp—Point-to-Point Protocol (PPP) over Frame Relay 

• ppp—Serial Point-to-Point Protocol (PPP) device 

• ppp-ccc—Serial PPP device for a circuit cross-connect 

• ppp-tcc—Serial PPP device for a translational cross-connect 

• MPLS circuit cross-connect 

• MPLS translational cross-connect 

• MPLS fast reroute 


74 



• Support for setting IPv6 DSCP and MPLS EXP independently (M120 routers, M320 

routers with Enhanced III FPCs, and MX Series routers)—On M120 routers, M320 

routers with Enhanced III FPCs, and MX Series 3D Universal Edge Routers, you can set 

the packet DSCP and MPLS EXP bits independently on IPv6 packets. 

To enable this feature, include the protocol mpls statement at the [edit class-of-service 

interfaces interface-name unit logical-unit rewrite-rules dscp-ipv6 rule-name] hierarchy 

level. 

You can set DSCP IPv6 values only at the ingress MPLS node. This feature is not 

supported on MPC/MIC interfaces. 


• Unified command to display all QoS statistics (M Series, MX Series, and T Series 

routers)—Two new options, detail and comprehensive, are added to the show 

class-of-service interface interface-name command. These new options are added to 

provide a unified operational command that combines the output of existing commands 

and displays all quality-of-service (QoS) parameters and statistics for physical or 

logical interfaces. 

The output of the show class-of-service interface interface-name detail command is a 

combination of output of the following commands: 

• show interfaces brief 

• show interfaces filters interface-name 

• show interfaces policers interface-name 

• show class-of-service interface interface-name 

In the show class-of-service interface interface-name detail command, if interface-name 

is a physical interface, the QoS information is displayed for the physical interface as 

well as for the logical interfaces on the physical interface—that is, the commands listed 

above are executed first for the physical interface, and then for each of the logical 

interfaces. If interface-name is a logical interface, the QoS information is displayed 

only for the logical interface. 

The output of the show class-of-service interface interface-name comprehensive 

command is a combination of output of the following commands: 

• show interfaces interface-name extensive 

• show interfaces queue interface-name 

• show interfaces filters interface-name 

• show interfaces policers interface-name 

• show firewall filter filter-name 

• show policer policer-name 

• show class-of-service classifier name classifier-name 

• show class-of-service translation-table name trans-table-name 

• show class-of-service forwarding-class 


75


• show class-of-service traffic-control-profile tcp-name 

• show class-of-service scheduler-map scheduler-map-name 

• show class-of-service drop-profile drop-profile-name 

• show class-of-service rewrite-rule name rewrite-rule-name 

• show class-of-service fragmentation-map fragmap-name 

The show class-of-service interface interface-name comprehensive command displays 

a specific construct only when it is attached to the interface. For example, if a translation 

table is not attached to an interface, it is not displayed. The constructs are listed if they 

are configured on the interface, either explicitly or through default configuration. 

NOTE: 

• The output of the show class-of-service interface interface-name detail 

and show class-of-service interface interface-name comprehensive 

commands are a combination of existing command output and no new 

field or functionality is added in the output. 

• The show class-of-service interface interface-name detail and show 

class-of-service interface interface-name comprehensive commands can 

be used mainly for debugging. If you do not specify interface 

interface-name and want to see the output for many interfaces together 

using these commands, there might be some delay in displaying the 

output. 

• The show class-of-service interface interface-name detail and show 

class-of-service interface interface-name comprehensive commands do 

not display routing instance statistics and information related to interface 

sets, ATM CoS, CoS-based forwarding, and interface range match. 

• While displaying firewall QoS output, only classical, interface-specific, 

and Layer 2 policers–related information is displayed. 

[Class of Service, System Basics, Network Interfaces] 

• Support for rewrite rules and classifiers on Ethernet pseudowires (MX Series 

routers)—Enables you to configure rewrite rules and classifiers on Ethernet pseudowires 

that are configured on logical tunnel interfaces. This feature is supported on MPC/MIC 

modules on MX Series routers. 

You can use logical tunnel interfaces to create pseudowires by connecting two virtual 

routing forwarding (VRF) instances. A pseudowire can be used to represent a single 

subscriber (for example, a business subscriber). 

To configure this feature, create a logical interface by including the lt-fpc/pic/port 

statement at the [edit interfaces] hierarchy level or the [edit logical-systems 

logical-system-name interfaces] hierarchy level. You must specify an Ethernet 

encapsulation type and inet as the family. 

76 



To configure the CoS parameters, include the rewrite-rules and classifier statements 

at the [edit class-of-service] hierarchy level. You can specify inet-precedence or dscp 

as the rewrite rule or the classification type. 

[Class of Service, Subscriber Access] 

• Policer support for aggregated Ethernet and SONET bundles (M120, M10i, and M7i 

routers (CFEB-E only), M320 routers (SFPC only), MX240, MX480, and MX960 

routers (DPC only)) Aggregated interfaces support single-rate policers, three-color 

marking policers, two-rate three-color marking policers, hierarchical policers, and 

percentage-based policers. By default, policer bandwidth and burst size applied on 

aggregated bundles are not matched to the user-configured bandwidth and burst size. 

You can configure interface-specific policers applied on an aggregated Ethernet bundle 

or an aggregated SONET bundle to match the effective bandwidth and burst size to 

user-configured values. The shared-bandwidth-policer statement is required to achieve 

this match behavior. 

This capability applies to all interface-specific policers of the following types: single-rate 

policers, single-rate three-color marking policers, two-rate three-color marking policers, 

and hierarchical policers. Percentage-based policers match the bandwidth to the 

user-configured values by default, and do not require shared-bandwidth-policer 

configuration. The shared-bandwidth-policer statement causes a split in burst size for 

percentage-based policers. 

To configure this feature, include the shared-bandwidth-policer statement at the [edit 

firewall policer policer-name], [edit firewall three-color-policer policer-name], or [edit 

firewall hierarchical-policer policer-name] hierarchy level. 


• Configurable IEEE 802.1p inheritance support for push and swap from hidden tag 

(MX Series routers)—Configurable IEEE 802.1p inheritance of push and swap bits from 

the hidden tag of each incoming packet allows you to classify incoming packets based 

on the IEEE 802.1p bits from the hidden tag. 

You can configure inheritance of IEEE 802.1p bits from the hidden tag by including the 

swap-by-poppush statement at the [edit interfaces interface-name unit 

logical-unit-number] hierarchy level. To configure the classification of incoming packets 

based on the IEEE 802.1p bits from the hidden tag, include the hidden statement at 

the [edit class-of-service interfaces interface-name unit logical-unit-number classifiers 

ieee-802.1 vlan-tag] hierarchy level. 

This feature is supported on MX Series routers with DPCs, Enhanced DPCs, and 

Enhanced Queuing DPCs. 

[Class of Service, Ethernet Interfaces] 

• Queuing support for logical tunnel interfaces (MX Series routers with MPC/MIC 

interfaces)—You can configure CoS scheduling parameters on a logical tunnel interface. 

This configuration can be used to manage traffic entering a pseudowire. You can 

configure the CoS scheduling and queuing parameters at the physical interface or the 

logical interface level. To do this, configure a hierarchical scheduler on the physical 

interface. 


77



• DSCP rewrite enabled on T640 and T1600 routers—DSCP rewrite is supported for 

the 10-Gigabit Ethernet LAN/WAN PIC with SFP+ (PD-5-10XGE-SFPP). 

NOTE: This PIC is referred to as the 10-port 10-Gigabit Oversubscribed 

Ethernet PIC or 10-port 10-Gigabit OSE PIC in some software 

documentation. 

[Class of Service, T640 PIC Guide, T1600 PIC Guide] 

• Extends support for Layer 2 policers on MX Series routers with MPC/MIC 

interfaces—You can now configure Layer 2 policers for the ingress and egress interfaces 

on MX Series routers with MPC/MIC interfaces. Policer types include: single-rate 

two-color, single-rate three-color (color-blind and color-aware), and two-rate 

three-color (color-blind and color-aware). To configure Layer 2 policing, include the 

policer at the [edit firewall] hierarchy level. 

[Class of Service, Policy, Network Interfaces] 


• Nonstop active routing support for RSVP OAM and BFD over RSVP—Starting with 

Release 11.4, Junos OS extends the nonstop active routing support to the RSVP 

Operation, Administration, and Maintenance (OAM) feature. Nonstop active routing 

support for RSVP OAM ensures that the OAM state information is maintained across 

the switchover. Nonstop active routing support for RSVP OAM also enables the BFD 

sessions over RSVP LSPs to preserve the state information across the switchover, and 

to come back online after the switchover. 

However, nonstop active routing support for RSVP OAM does not include 

point-to-multipoint LSPs, logical systems, and bypass and detour LSPs. 

[High Availability] 

• Support for unified in-service software upgrade (T640 and T1600 Routers)—Supports 

unified in-service software upgrade (unified ISSU) on T640 and T1600 routers with 

10-Gigabit Ethernet LAN/WAN PIC with SFP+ (PD-5-10XGE-SFPP). Unified ISSU is a 

process to upgrade the system software with minimal disruption of transit traffic and 

no disruption on the control plane. In this process, the new system software version 

must be higher than the previous system software version. When unified ISSU 

completes, the new system software state is identical to that of the system software 

when the system upgrade is performed by powering off the system and then powering 

it back on. 


• Support for unified in-service software upgrade (MX Series routers with FPC2 and 

FPC3)—Supports unified in-service software upgrade (unified ISSU) on MX Series 

routers with FPC2 and FPC3. 

The following Physical Interface Cards (PICs) on MX-FPC2 and MX-FPC3 support 

unified ISSU: 

78 



MX-FPC2 

• SONET/SDH OC48/STM16 (Multi-Rate) PIC with SFP (PB-1OC48-SON-B-SFP) 

• SONET/SDH OC48c/STM16 with SFP (PB-1OC48-SON-SFP) 

• SONET/SDH OC3c/STM1 (Multi-Rate) PIC with SFP (PB-4OC3-1OC12-SON2-SFP) 

• SONET/SDH OC12/STM4 (Multi-Rate) PIC with SFP (PB-4OC3-4OC12-SON-SFP) 

• Channelized OC48/STM16 Enhanced IQ (IQE) PIC with SFP 

(PB-1CHOC48-STM16-IQE-SFP) 

MX-FPC3 

• SONET/SDH OC192c/STM64 PIC (PC-1OC192-SON-VSR) 

• SONET/SDH OC192c/STM64 PIC with XFP (PC-1OC192-SON-XFP) 

• SONET/SDH OC48/STM16 PIC with SFP (PC-4OC48-SON-SFP) 

Unified ISSU is a process to upgrade the system software with minimal disruption of 

transit traffic and no disruption on the control plane. In this process, the new system 

software version must be higher than the previous system software version. When 

unified ISSU completes, the new system software state is identical to that of the system 

software when the system upgrade is performed by powering off the system and then 

powering it back on. 


• Layer 2 bridging support for MX Series Virtual Chassis (MX240, MX480, and MX960 

routers with MPC/MIC interfaces)—Supports the following Layer 2 bridging features 

and applications in an MX Series Virtual Chassis configuration: 

• Bridged interface configuration 

• Bridge domain configuration 

• Media access control (MAC) flooding and learning 

• Integrated routing and bridging (IRB) 

• Virtual private LAN service (VPLS) 

• Redundant pseudowires for Layer 2 circuits and VPLS 

Configuration of these Layer 2 bridging features works the same way for member 

routers in an MX Series Virtual Chassis as it does for standalone MX Series routers that 

are not part of a Virtual Chassis. 

[High Availability, Layer 2] 

• Support for unified in-service software upgrade (T640 and T1600 Routers with Type 

3 PICs)—Junos OS Release 11.4 supports unified in-service software upgrade (unified 

ISSU) on T640 and T1600 routers with 4-port Channelized SONET/SDH OC48/STM16 

Enhanced IQ (IQE) PIC with SFP (PC-4OC48-STM16-IQE-SFP). 

Unified ISSU is a process to upgrade the system software with minimal disruption of 

transit traffic and no disruption on the control plane. In this process, the new system 


79


software version must be higher than the previous system software version. When 

unified ISSU completes, the new system software state is identical to that of the system 

software when the system upgrade is performed by powering off the system and then 

powering it back on. 


• Unified ISSU support for statistics preservation on MPC/MIC interfaces (MX Series 

3D Universal Edge Routers)—Enables support for the preservation of interface-specific 

and firewall filter statistics across a unified in-service software upgrade (unified ISSU) 

on an MX Series router with MPC/MIC interfaces. This support ensures that the router 

maintains statistics data across the unified ISSU and that statistics counters are 

operational after the unified ISSU completes. 

To preserve statistics across a unified ISSU, the router stores the statistics data as 

binary large objects. The router collects the statistics before the unified ISSU is 

initialized, and restores the statistics after the unified ISSU completes. No statistics 

are collected during the unified ISSU process. 

To verify that statistics are preserved across the unified ISSU, you can issue existing 

CLI operational commands such as show interfaces statistics after the unified ISSU 

completes. 

For a list of the MPCs and MICs that are supported during a unified ISSU on MX Series 

3D Universal Edge Routers, see the Junos OS High Availability Configuration Guide. 

[High Availability, Subscriber Access] 

Interfaces and Chassis 

• Internet Key Exchange version 2 (IKEv2)—Starting with Junos OS Release 11.4, both 

IKEv1 and IKEv2 are supported by default on all M Series, MX Series, and T Series routers. 

The version statement under the [edit services ipsec-vpn ike policy name] hierarchy 

level allows you to configure the specific IKE version to be supported. However, if only 

IKEv1 is supported, Junos OS rejects IKEv2 negotiations. Similarly, if only IKEv2 is 

supported, Junos OS rejects all IKEv1 negotiations. 

The key management process (kmd) determines which version of IKE is used in a 

negotiation. If kmd is the IKE initiator, it uses IKEv1 by default and retains the configured 

version for negotiations. If kmd is the IKE responder, it accepts connections from both 

IKEv1 and IKEv2. 

[Services Interfaces] 

• Support for Frame Relay DE loss priority mapping (M120 routers, M320 routers with 

Enhanced III FPC, M7i and M10i routers with Enhanced Compact Forwarding Engine 

Board, and MX Series routers)—Enables you to define a loss priority map based on 

the Frame Relay discard eligibility (DE) bit. To configure the Frame Relay DE loss priority 

mapping, include the loss-priority and code-point statements at the [edit class-of-service 

loss-priority-maps frame-relay-de] hierarchy level. For each mapping, the loss priority 

can be high, low, medium-high, or low. The value of the code point can be 0 or 1. 

The mapping does not take effect until you apply it to a logical interface. To apply a 

map to a logical interface, include the frame-relay-de map-name statement at the [edit 

80 



class-of-service interfaces interface-name unit logical-unit-number loss-priority-maps] 

hierarchy level: 

[edit class-of-service interfaces interface-name unit logical-unit-number 

loss-priority-maps] 

frame-relay-de map-name; 


• Support for Frame Relay DE bit rewriting on Enhanced IQ PICs (M7i, M10i, M40e, 

M120, M320, MX Series, and T Series routers)—Enables you to rewrite the Frame 

Relay discard eligibility (DE) bit by including the frame-relay-de statement at the [edit 

class-of-service loss-priority-rewrites] hierarchy level. For each mapping, the loss priority 

can be high, low, medium-high, or low. The value of the code point can be 0 or 1. 

The Frame Relay DE bit rewrite does not take effect until you apply it to a logical 

interface. To apply the Frame Relay DE bit rewrite to the logical interface, include the 

frame-relay-de map-name statement at the [edit class-of-service interfaces 

interface-name unit logical-unit-number loss-priority-rewrites] hierarchy level: 

[edit class-of-service interfaces interface-name unit logical-unit-number 

loss-priority-rewrites] 

frame-relay-de map-name; 


• Support for carrying DE, FECN, and BECN bit information in Layer 2 VPN and Layer 

2 circuit control word (M120, M320, MX Series, and T Series routers)—Provides 

additional class-of-service (CoS) support for Frame Relay services over MPLS using 

Layer 2 virtual private networks (VPNs) and Layer 2 circuits. When you perform control 

word classification and rewrite, the discard eligibility (DE) bit, forward explicit congestion 

notification (FECN) bit, and backward explicit congestion notification (BECN) bit in 

the incoming Frame Relay packet for the circuit cross-connect (CCC) family are mapped 

to the Layer 2 circuit control word across the MPLS backbone. To enable this mapping, 

include the translate-discard-eligible and translate-fecn-and-becn statements at the 

[edit interfaces interface-name unit logical-unit-number family ccc] hierarchy level. 

You can classify and rewrite the control word DE bit based on the packet loss priority 

(PLP) by using the translate-plp-control-word-de statement at the [edit interfaces 

interface-name unit logical-unit-number family ccc] hierarchy level. When you configure 

the translate-plp-control-word-de statement on the ingress PE router, the DE bit in the 

control word is rewritten based on the PLP. When you configure the 

translate-plp-control-word-de statement on the egress PE router, the PLP is derived 

based on the control word DE bit, and the DE bit in the outgoing Frame Relay header 

is rewritten based on the PLP. By default, control word classification and rewrite is 

disabled. The mapping of the PLP to the DE bit in the control word and the outgoing 

Frame Relay packet is fixed. For rewriting, the PLP values low and medium-low are 

mapped to the DE bit 0 and the PLP values high and medium-high are mapped to the 

DE bit 1. For classifying, the DE bit 0 is mapped to the PLP value low and the DE bit 1 is 

mapped to the PLP value high. 

To enable control word classification and rewrite, include the following statements at 

the [edit interfaces interface-name unit logical-unit-number family ccc] hierarchy level: 

[edit interfaces interface-name unit logical-unit-number ] 


81


{ 

encapsulation frame-relay-ccc; 

point-to-point; 

dlci dlci-number; 

family ccc { 

translate-discard-eligible; 

translate-fecn-and-becn; 

translate-plp-control-word-de; 

} 

} 

NOTE: The translate-discard-eligible and translate-plp-control-word-de 

statements are mutually exclusive—that is, you can configure only one of 

these statements. 

[Network Interfaces] 

• Extends support for the Two-Way Active Measurement Protocol (TWAMP) on MX 

Series routers with MPC/MIC interfaces—You can now configure TWAMP (RFC 5357) 

on MX Series routers with MPC/MIC interfaces. To configure TWAMP properties, include 

the twamp statement at the [edit services rpm] hierarchy level. In previous Junos OS 

releases, this feature was supported on M Series and T Series routers that support 

Multiservices PICs (running in either Layer 2 or Layer 3 mode), and on MX Series routers. 


• Support for active monitoring on logical systems—A logical system is a partition 

created from a physical router that performs independent routing tasks. Several logical 

systems in a single router with their own interfaces, policies, instances, and routing 

tables can perform functions handled by several different routers. Starting with Junos 

OS Release 11.4, support for active monitoring is extended to logical systems running 

on T Series and MX Series routers. A shared services PIC handles flows from all the 

logical systems. Only version 9 flows, IPv4, and MPLS templates are supported. 


• Connecting the JCS1200 platform to a TX Matrix Plus Router now supported—Both 

RSD (root system domain) and PSD (protected system domain) are now supported 

on TX Matrix Plus routers. 

A Protected System Domain (PSD) system consists of a redundant Routing Engine 

pair (or a single Routing Engine) on the JCS1200 platform, matched with one or more 

Flexible PIC Concentrators (FPCs) on a T Series router. You can now connect a TX 

Matrix Plus router to the JCS1200 platform to function as a PSD. To configure 

multichassis PSD, include the lcc number fpcs number statement at the [edit chassis 

system-domains protected system domains] hierarchy level. Up to 12 FPCs can be 

configured for a PSD. 

show chassis psd is now also supported on TX Matrix Plus routers. 

[Protected System Domain, System Basics, JCS1200 Control System Hardware, TX Matrix 

Plus Hardware Guide ] 

82 



• Support for 40-Gigabit Ethernet PIC with CFP (PD-1XLE-CFP) on T1600 and T640 

routers—The 40-Gigabit Ethernet PIC with CFP (PD-1XLE-CFP) is a 1-port 40-Gigabit 

Ethernet Type 4 PIC with C form-factor pluggable (CFP) optics supported on T1600 

and T640 routers. The 40-Gigabit Ethernet PIC with CFP occupies FPC slot 0 or 1 in 

the Type 4 FPC. It shares certain common features, such as flexible encapsulation and 

MAC accounting, with the 4-port 10-Gigabit Ethernet LAN/WAN PIC with XFP (model 

number PD-4XGE-XFP). 

[Network Interfaces, Interfaces Command Reference, T640 PIC Guide, T1600 PIC Guide] 

• Support for channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP (MX 

Series routers)—Enables support for SONET/SDH and PDH interfaces on MX Series 

routers. There are two types of SONET/SDH OC3/STM1 (Multi-Rate) MICs with 

SFP—the 8-port Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP 

(model number: MIC-3D-8CHOC3-4CHOC12), and the 4-port Channelized SONET/SDH 

OC3/STM1 (Multi-Rate) MIC with SFP (model number: MIC-3D-4CHOC3-2CHOC12). 

These MICs support POS/PDH interfaces on the MX80 3D Universal Edge Routers and 

other MX Series routers using the MX-MPC1-3D-Q, MX-MPC2-3D-Q, and 

MX-MPC2-3D-EQ MPCs to position a single device to meet multiservice edge 

requirements. These MICs provide the following basic functions: 

• SONET/SDH/PDH framing 

• Preclassification 

NOTE: CoS support is not directly available on these MICs. CoS functions 

are completely implemented in the Packet Forwarding Engine. These MICs 

only preclassify the packets. 

The following features are supported on the Channelized SONET/SDH OC3/STM1 

(Multi-Rate) MICs with SFP: 

• Default framing on all ports is SONET. 

• The MIC supports SONET and SDH framing mode on a per-port basis. To enable 

SONET or SDH framing, you need to set the framing statement at the [chassis fpc 

MPC-slot-number pic MIC-slot-number port port-number] hierarchy level. 

• The MIC supports channelized OC3/STM1 and channelized OC12/STM4 configuration 

on a per-port basis. You can set the speed of the port by configuring the speed 

statement at the [chassis fpc MPC-slot-number pic MIC-slot-number port port-number] 

hierarchy level. 

• By default, the speed of a port is set to OC3/STM1. You can use the show interface 

extensive operational mode command to view the speed of an interface. 

• The MIC supports remote and local loopback. Loopbacks can be configured 

independently on each port. 

• Simultaneous T3 and E3 interfaces can exist on the cau4 controller-level interface. 

• Simultaneous T1 and E1 interfaces can exist on the cau4 controller-level interface. 


83


NOTE: 

• The Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP 

does not support aggregate SONET (link bundling). 

• The Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP 

does not support container interfaces. 

• When a port is configured as channelized OC12, only six of the twelve 

OC1 slices can be deep-channelized from T1 through DS0. The remaining 

six OC1 slices can be channelized only to T3 or can be combined to form 

two OC3 slices. They cannot be channelized to T1 or DS0. 

[Channelized Interfaces, SONET/SDH Interfaces, Class of Service, System Basics] 

• Support for DS3/E3 MIC (MX Series routers)—Enables support for PDH interfaces 

on the MX80 3D Universal Edge Router and other MX Series routers using the 

MX-MPC1-3D-Q, MX-MPC2-3D-Q, and MX-MPC2-3D-EQ MPCs to position a single 

device to meet multiservice edge requirements. You can configure the DS3/E3 MIC 

(model number: MIC-3D-8DS3-E3) to function either in clear-channel mode or in 

channelized mode. When functioning in channelized mode, the DS3/E3 MIC supports 

PDH interfaces on the MX80 3D Universal Edge Router and MX Series routers that use 

MX-MPC1-3D-Q, MX-MPC2-3D-Q, or MX-MPC2-3D-EQ. When functioning in 

clear-channel mode, this MIC also supports PDH interfaces on the MX-MPC1-3D and 

MX-MPC2-3D MPCs. 

The DS3/E3 MIC provides the following basic functions: 

• PDH framing 

• Preclassification 

NOTE: CoS support is not directly available on this MIC. CoS functions are 

completely implemented in the Packet Forwarding Engine. The MIC only 

preclassifies the packets. 

By default, the DS3/E3 MIC functions in clear-channel mode. To enable the DS3/E3 

MIC to function in channelized mode, you need to use the software license 

S-MIC-3D-8CHDS3. To enable channelization, set the channelization option at the 

[chassis fpc MPC-slot-number pic MIC-slot-number] hierarchy level. You can use the 

channelization option to channelize individual DS3 interfaces. 

84 



NOTE: 

• You can configure the channelization option to enable channelization for 

the DS3/E3 MICs only. Moreover, you can use the channelization option 

only on MX Series routers with Queuing and Enhanced Queuing MPCs 

(MX-MPC1-3D-Q, MX-MPC2-3D-Q, and MX-MPC2-3D-EQ) or on MX80 

routers. Configuring the channelization option on other MPCs does not 

have any effect. The MIC continues to operate in clear-channel mode. 

• Only clear-channel E3 mode is supported on the DS3/E3 MIC. Therefore, 

configuring the channelization option does not impact the E3 functionality. 

You can enable DS3 or E3 framing mode on individual ports of the DS3/E3 MIC. To do 

this, set the framing statement at the [chassis fpc MPC-slot-number pic MIC-slot-number 

port port-number] hierarchy level. By default, DS3 mode is enabled. 

NOTE: The DS3/E3 MIC does not support E3 subrate and scrambling. 

[Channelized Interfaces, Class of Service, System Basics] 

• Enhanced MX Switch Control Board (MX960, MX480, and MX240 routers)—The 

Enhanced MX SCB uses an XF chip that provides more than 120 Gbps per slot of 

bandwidth with redundancy. This SCB is supported on MX960, MX480, and MX240 

routers, and consists of the following components: 

• XF chip—Facilitates fabric planes 

• 3 Gbps and 6 Gbps HSL2 link speed 

• Front panel clock interface for future clocking support 

• Front panel small form-factor pluggable (SFP) transceivers or SFP+ external Ethernet 

switch interface for future support 

[MX960 3D Universal Edge Router Hardware Guide, MX480 3D Universal Edge Router 

Hardware Guide, MX240 3D Universal Edge Router Hardware Guide] 

• Command output changes for Enhanced MX Switch Control Board (MX960, MX480, 

and MX240 routers)—The Enhanced MX Switch Control Board (SCB) caters to the 

carrier Ethernet services router and carrier Ethernet transport markets that require 

higher-capacity traffic support demanding greater interface density (slot and capacity 

scale), as well as improved services. 

Starting with Release 11.4, Junos OS supports the Enhanced MX SCB, thereby resulting 

in the following command output changes: 


85


• show chassis environment command displays CB N SF A and CB N SF B for the 

temperatures of the existing SF ASICs. For the Enhanced MX SCB, the temperature 

sensor is still present, but it now measures the temperature of the XF ASIC. The 

display output now shows CB N XF A and CB N XF B. 

• show environment cb command now includes information about new Power 

Management BUS (PMBus) devices on the board, including measured voltage, 

measured current, and calculated power. 

• show chassis hardware command shows the new part number 750-031391, and the 

description is Enhanced MX SCB. 

• show chassis hardware models command shows the new model SCBE-MX-S. 

• show chassis hardware extensive command shows the new assembly ID 0x09b0. 

• The output of the following commands shows a maximum of four active planes for 

the Enhanced MX SCB on MX Series routers with MPCs. 

• show chassis fabric summary 

• show chassis fabric fpc 

• show chassis fabric plane 

[System Basics] 

• Physical interface policers on MX Series routers with MPC/MIC interfaces—Physical 

interface policers are now available on the Trio chipset. 

[Policy] 

• Support for FIB localization—In Junos OS Release 11.4 and later, you can configure FIB 

localization for a Packet Forwarding Engine. FIB localization characterizes Packet 

Forwarding Engines in a router as either “FIB-Remote” or “FIB-Local.” FIB-Local Packet 

Forwarding Engines install all routes from the default inet and inet6 route tables into 

the Packet Forwarding Engine forwarding hardware. By default, FIB-Remote Packet 

Forwarding Engines do not install routes for these tables. Instead, FIB-Remote Packet 

Forwarding Engines create a default (0/0) route in the Packet Forwarding Engine 

forwarding hardware for the inet and inet6 tables. The default route references a next 

hop or a unilist of next hops that indicate the FIB-Local Packet Forwarding Engines 

that can perform full IP table lookups for received packets. 

When FIB localization is configured on a router with some FPCs being FIB-Remote and 

some others being FIB-Local, packets arriving on the interface of the FIB-Remote FPC 

are forwarded to one of the FIB-Local FPCs for route lookup and forwarding. 

The advantage of configuring FIB localization is that it enables upgrading the hardware 

forwarding table capacity of FIB-Local Packet Forwarding Engines while not requiring 

upgrades to the FIB-Remote Packet Forwarding Engines. In a typical network 

deployment, FIB-Local Packet Forwarding Engines are core-facing, while FIB-Remote 

Packet Forwarding Engines are edge-facing. The FIB-Remote Packet Forwarding 

Engines also load-balance traffic over the available set of FIB-Local Packet Forwarding 

Engines. 

86 



To configure FIB localization, for IPv4 or IPv6 traffic, include the route-localization 

statement at the [edit chassis] hierarchy level. To configure the Packet Forwarding 

Engine of an FPC as either FIB-Local or FIB-Remote, include the fib-local or fib-remote 

statement at the [edit chassis fpc fpc-number route-localization] hierarchy level. To 

configure a routing policy to enable the forwarding table policy to mark route prefixes 

for installation in the forwarding hardware on the FIB-Remote Packet Forwarding 

Engines, include the no-route-localize statement at the [edit policy-options 

policy-statement policy-name term term-name then] hierarchy level. 

To verify route localization information, issue the show route localization or the show 

route localization detail commands. 

[System Basics, Policy] 

• Junos OS 64-bit migration on the T1600 Router—Unified in-service software upgrade 

(unified ISSU) is not supported when upgrading from 32-bit Junos OS to 64-bit Junos 

OS because GRES and NSR features need to be disabled during the upgrade. Mixing 

32-bit Junos OS and 64-bit Junos OS is not supported except for a small window of 

time during the upgrade process. 

• Support for IGMP snooping over MPCs (MX Series routers with MPCs)—Junos OS 

Release 11.4 supports the configuration of IGMP snooping over MPCs. For information 

about how to configure IGMP snooping, see the Junos OS Multicast Protocols Configuration 

Guide. 

[MX Series 3D Universal Edge Router Line Card Guide] 

• Passive flow monitoring support on ES-FPCs (T640 and T1600 routers)—Passive 

monitoring enables you to perform lawful intercept of packets that traverse an Ethernet 

link between routers or switches. Passive monitoring support is now extended for IPv4 

and IPv6 to the following PICs for the T640 and T1600 routers: 

• Gigabit Ethernet PIC with SFP 

• 10-Gigabit Ethernet PIC with XENPAK (T1600 router) 

• SONET/SDH OC192/STM64 PIC (T1600 router) 

• SONET/SDH OC192/STM64 PICs with XFP (T1600 router) 

• SONET/SDH OC48c/STM16 PIC with SFP (T1600 router) 

• SONET/SDH OC48/STM16 (Multi-Rate) 

• SONET/SDH OC12/STM4 (Multi-Rate) PIC with SFP 

• Type 1 SONET/SDH OC3/STM1 (Multi-Rate) PIC with SFP 

IPv6 passive monitoring is not supported on Monitoring Services PICs. You must 

configure port mirroring to forward the packets from the passive monitored ports to 

other interfaces. To configure port mirroring, include the port-mirroring statement at 

the [edit forwarding-options] hierarchy level. 

Configuring the interface in passive monitoring mode automatically configures it in 

promiscuous mode. To configure passive monitoring, include the passive-monitor-mode 

statement at the [edit interfaces interface-name] hierarchy level. Gigabit Ethernet 


87


interfaces in passive monitoring mode do not support the stacked-vlan-tagging 

statement. 

To remove MPLS labels, include the pop-all-labels statement at the [edit interfaces 

interface-name gigether-options mpls] hierarchy level. 

[Services Interfaces, Network Interfaces] 

• Layer 2 interface statistics enhancement—On Dense Port Concentrators (DPCs) on 

MX Series routers, when a bridge domain is configured with an integrated routing and 

bridging (IRB) interface, packets that are routed by the IRB interface and transmitted 

out through a Layer 2 interface that is part of the bridge domain are now accounted 

for in the corresponding Layer 2 interface statistics. Prior to Junos OS Release 11.4, the 

Layer 2 interface statistics did not account for those packets that were routed by an 

IRB. The show interfaces irb extensive command displays the IRB-related statistics, 

while the show interfaces statistics interface-name command displays the layer 2 

interface level statistics. 

[Interfaces Command Reference] 

• Display pseudowire Layer 2 policing statistics (MX Series routers with MPCs/MICs 

or enhanced DPCs)—The Junos OS Routing Engine, kernel, and Packet Forwarding 

Engine can collect the statistics for a pseudowire policer from all Packet Forwarding 

Engines and display them on the Routing Engine. These statistics are displayed when 

you execute the show interfaces command, if a pseudowire policer is enabled. 

This feature is available for pseudowire logical interfaces at egress. 

[MX Solutions Guide] 

• Support for 64-bit Junos OS on T640 and TX Matrix Plus routers—Enables you to 

run 64-bit Junos OS on T640 and TX Matrix Plus routers. This feature also allows you 

to migrate from the existing 32-bit Junos OS, without any loss of features. However, 

64-bit capable Routing Engines are required for upgrading to 64-bit Junos OS. The 

64-bit version of Junos OS supports: 

• Physical memory of more than 4 GB. 

• Increased virtual address space for applications. 

The following features are not supported by 64-bit Junos OS: 

• Different versions of Junos OS running in separate Routing Engines. Both Routing 

Engines must have either 32-bit or 64-bit Junos OS in a single physical or virtual 

chassis. 

• Upgrade, without downtime, from 32-bit to 64-bit Junos OS using unified in-service 

software upgrade (unified ISSU). 

In Junos OS Release 11.4, no new CLI commands or alarms are introduced for this 

feature. 

[System Basics and Services Command Reference, Interfaces Command Reference, 

Software Installation and Upgrade] 

• Limiting traffic black-hole time by detecting Packet Forwarding Engine destinations 

that are unreachable over the fabric (T640 and T1600 routers)—Enables the T640 

88 



and T1600 routers to limit traffic black-hole time by detecting unreachable destination 

Packet Forwarding Engines. The router signals neighboring routers when it cannot carry 

traffic because of the inability of some or all source Packet Forwarding Engines to 

forward traffic to some or all destination Packet Forwarding Engines on any fabric 

plane, after interfaces have been created. This inability to forward traffic results in a 

traffic black hole. 

Packet Forwarding Engine destinations can become unreachable because of the 

following reasons: 

• The fabric Switch Interface Boards (SIBs) go offline as a result of a CLI command 

or a pressed physical button. 

• The fabric SIBs are turned offline by the Switch Processor Mezzanine Board (SPMB) 

because of high temperature. 

• Voltage or polled I/O errors in the SIBs detected by the SPMB. 

• All Packet Forwarding Engines get destination errors on all planes from remote 

Packet Forwarding Engines, even when the SIBs are online. 

• Complete fabric loss caused by destination timeouts, even when the SIBs are online. 

When the system detects unreachable Packet Forwarding Engine destinations, healing 

from the traffic black hole is attempted. If the healing fails, the system turns off the 

interfaces, thereby stopping the black hole. 

The recovery process consists of the following steps: 

1. Fabric plane restart phase: Healing is attempted by restarting the fabric planes one 

by one. 

2. Fabric plane and FPC restart phase: Healing is attempted by restarting both the 

fabric planes and the FPCs. If there are bad FPCs that are unable to initiate 

high-speed links to the fabric after reboot, traffic black hole is limited because no 

interfaces are created for these FPCs. 

3. FPC offline phase: Traffic black hole is limited by turning the FPCs offline and by 

turning off interfaces because previous attempts at recovery have failed. 

By default, the system limits black-hole time by detecting severely degraded fabric. 

You do not need to configure anything to enable this feature. However, you can limit 

recovery actions to fabric plane restart only. You need to fix the traffic black hole by 

performing steps 2 and 3 manually. 

In Junos OS Release 11.4, new alarms are added to indicate which FPCs are creating a 

traffic black hole in the system and to provide information about FPCs that are turned 

offline to stop the black hole in the recovery process. 

In Junos OS Release 11.4, new error messages are added to indicate whether the traffic 

black hole is detected by unreachable FPCs in the system, or it is due to all planes being 

offline. These messages also indicate the actions taken on FPCs and planes to stop 

the black hole—for example, FPC online, FPC offline , FPC restart, FPC power off, plane 

online, and plane offline. 

In Junos OS Release 11.4, two new CLI commands are introduced for this feature: 


89


• The show chassis fabric unreachable-destinations command shows the list of 

destinations that have changed from reachable to unreachable. 

• The show chassis fabric reachability command shows the current state of fabric 

destination reachability, based on periodic reachability checks. 

[System Basics and Services Command Reference, System Log Messages Reference] 

• Support for four or five input feeds on six-input DC power supply—Enables you to 

provide four or five input feeds to the six-input DC power supply on standalone routers 

and LCC routers in a routing matrix. By default, the power supply is configured to have 

all the six input feeds connected. 

When providing four or five input feeds on standalone routers, you need to configure 

the feeds option at the [edit chassis pem] hierarchy level. When providing four or five 

input feeds on an LCC router in a routing matrix, you need to configure the feeds option 

at the [edit chassis lcc lcc-number pem] hierarchy level. The value assigned to the feeds 

option must be equal to the number of input feeds provided to the power supply. 

NOTE: 

• Before configuring input feeds for your router, see the T640 Core Router 

Hardware Guide or T1600 Core Router Hardware Guide for special 

considerations and for the number of input feeds supported by the router. 

• All power supplies in the router must use the same number of inputs 

feeds. 

When using the six-input 60-A DC power supply, you can monitor the input current, 

input voltage, fan current, and fan voltage by using the show chassis environment pem 

operational mode command. 

• Microcode remap (M320 and M120 routers)—M320 routers with E3 Type-1 FPCs and 

M120 routers with a single Type-1 FPC mapped to an FEB support a new microcode 

map to resolve microcode overflow resulting in bad PIC combinations. 

On M320 routers, the new microcode map is enabled by default and is the only option 

available. 

On M120 routers, you can enable the new microcode map by using the 

ucode-imem-remap statement at the [edit chassis feb slot number] hierarchy level. On 

M120 routers, the default microcode map remains configured if the ucode-imem-remap 

statement is not configured. 

[edit chassis] 

feb { 

slot number{ 

ucode-imem-remap; 

} 

} 

NOTE: On M120 routers, the FEB is automatically restarted after the 

ucode-imem-remap statement is configured and committed. 

90 



[System Basics, Network Interfaces] 

• Support for ESMC or SSM quality-based clock selection mode (MX Series 

routers)—Enables you to decide whether clock source selection should use the 

configured or received Ethernet Synchronization Message Channel (ESMC) or 

Synchronization Status Message (SSM) quality level for a qualifying interface. 

If you configure the selection-mode statement as configured-quality at the [edit chassis 

synchronization] hierarchy level, then the clock source selection algorithm uses the 

ESMC or SSM quality level configured for a qualifying interface. 

If you configure the selection-mode statement as received-quality at the [edit chassis 

synchronization] hierarchy level, then the clock source selection algorithm uses the 

ESMC or SSM quality level received on the qualifying interface. 

In both the selection modes, the interface qualifies for clock source selection only when 

the received ESMC or SSM quality level on the interface is equal to or better than the 

configured ESMC or SSM quality level for the interface. 

For the selection-mode statement configuration to take effect, you must set the 

quality-mode-enable statement at the [edit chassis synchronization] hierarchy level. 

To configure the ESMC or SSM quality-based clock selection mode, include the 

quality-mode-enable and selection-mode statements at the [edit chassis 

synchronization] hierarchy level. 

[System Basics, Junos OS Configuration Statements and Commands] 

• Additional MPC support for SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP 

(MX Series routers)—There are two types of SONET/SDH (Multi-Rate) MICs with 

SFP—the 8-port SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP, which offers high 

port density, and the 4-port SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP, which 

offers low port density. These MICs were introduced in Junos OS Release 11.2. Refer to 

the Junos OS 11.2 release notes for more information. 

In Junos OS Release 11.2, the 8-port and 4-port SONET/SDH OC3/STM1 (Multi-Rate) 

MICs with SFP are supported on the following MPCs: 

• 30-Gigabit Ethernet MPC (MX-MPC1-3D) 

• 30-Gigabit Ethernet Queuing MPC (MX-MPC1-3D-Q) 

In Junos OS Release 11.4, the support for 8-port and 4-port SONET/SDH OC3/STM1 

(Multi-Rate) MICs with SFP has been extended to the following MPCs: 

• 60-Gigabit Ethernet MPC (MX-MPC2-3D) 

• 60-Gigabit Ethernet Queuing MPC (MX-MPC2-3D-Q) 

• 60-Gigabit Ethernet Enhanced Queuing MPC (MX-MPC2-3D-EQ) 


• Consortium Local Management Interface extended to Frame Relay protocol (MX 

Series routers)—Extended Consortium Local Management Interface (C-LMI) support 

for MX Series routers with specified MICs adds support for Consortium LMI based on 

the "Gang of Four" or "Consortium" standard (Section 6). 


91


The following MICs are supported: 

• MIC-8OC3OC12-4OC48-SFP—8-port clear-channel OC3/OC12/STM-1/STM-4, 

4-port clear-channel OC48/STM-16 

• MIC-4OC3OC12-1OC48-SFP—4-port clear-channel OC3/OC12/STM-1/STM-4, 1-port 

clear-channel OC48/STM-16 

• MIC-3D-8CHOC3-4CHOC12-SFP—8-port Channelized OC3/STM-1, 4-port 

Channelized OC12/STM-4 

• MIC-3D-4CHOC3-2CHOC12-SFP—4-port Channelized OC3/STM-1, 2-port 

Channelized OC12/STM-4 

• MIC-3D-8DS3-E3—8-port clear-channel DS3/E3 

The following are also supported: 

• MX80 router 

• MX-MPC1-3D—30 GB, per port queuing, 64 KB logical interfaces 

• MX-MPC2-3D—60 GB, per port queuing, 64 KB logical interfaces 

• MX-MPC1-3D-Q—30 GB, enhanced queuing, 128 KB queues (max 64 KB egress), 32 

KB logical interfaces 

• MX-MPC2-3D-Q—60 GB, enhanced queuing, 256 KB queues (max 128 KB egress), 

64 KB logical interfaces 

To configure C-LMI, you can use the lmi-type statement with its c-lmi option at the 

[edit interfaces interface lmi] hierarchy level. 

The following encapsulation types are not supported: 

• frame-relay-port-ccc 

• extended-frame-relay-ether-type-tcc 

• frame-relay-ether-type 

• frame-relay-ether-type-tcc 

[Channelized Interfaces, SONET/SDH Interfaces, E1/E3/T1/T3 Interfaces, Interfaces 

Fundamentals] 

• IPv6 support for the dynamic flow capture (DFC) application—Starting with Junos 

OS Release 11.4, support for intercepting IPv6 flows through the DFC application is 

extended to M320 and T Series routers. IPv6 support is configured using the family 

intet6 statement at the [edit interfaces dfc-identifier unit 1] hierarchy level. 


• Support for 802.1ag connectivity fault management (CFM) monitoring with service 

protection (MX Series routers with MPC/MIC interfaces)—Extends support for service 

protection functionality for Carrier Ethernet transport networks on MX Series routers 

with MPC/MIC interfaces. Service protection can be achieved by configuring a working 

92 



and protect transport path. These transport paths can be monitored using the 802.1ag 

CFM protocol. 


• Support for chassis Enhanced Network Services modes (MX Series routers with 

MPCs)—You can configure MX Series 3D Universal Edge Routers to run in different 

network services modes. Each network services mode defines how the chassis identifies 

and uses certain modules. Junos OS Release 11.4 supports the addition of Enhanced 

IP Network Services mode and Enhanced Ethernet Network Services mode. 

To configure the chassis for Enhanced Network Services modes, include the 

network-services statement along with either the enhanced-ip or enhanced-ethernet 

service option at the [edit chassis] hierarchy level. 

When the chassis is configured for Enhanced IP Network Services mode, only MPCs 

and Multiservices DPCs are powered on. When the chassis is configured for Enhanced 

Ethernet Network Services mode, only MPCs and Multiservices DPCs are powered on 

and all restrictions for operating in Ethernet Network Services mode apply. For 

information about Ethernet Network Services restrictions, see “Restrictions on Junos 

OS Features for MX Series Routers” in the Junos OS System Basics Configuration Guide. 

NOTE: Only Multiservices DPCs are powered on with the Enhanced Network 

Services mode options. No other DPCs function with the Enhanced Network 

Services mode options. 


• 6rd support for Anycast—Enables hosting of a 6rd domain on multiple service PICs 

by assigning the same softwire rules to two service sets that use different service 

interfaces. Only one PIC actively processes the 6rd traffic at any time. When the 

currently active PIC goes down, the PIC hosting the same 6rd domain becomes active 

and takes over the processing of 6rd traffic. 

[Services Interfaces, Next-Generation Network Addressing] 

• 6rd support for hairpinning—Enables packets exiting one 6rd softwire to be processed 

by another softwire after twice NAT processing. This applies when a host behind a 

softwire initiator tries to communicate with another host behind a softwire initiator. 

[Services Interfaces, Next-Generation Network Addressing] 

• DS-Lite support for Anycast and 6PE (IPv6 Provider Edge)—Anycast enables hosting 

of a DS-Lite domain on multiple service PICs by assigning the same softwire rule to 

two service sets that use different service interfaces. Only one PIC actively processes 

the DS-Lite traffic at any time. When the currently active PIC goes down, the PIC hosting 

the same DS-Lite domain becomes active and takes over the processing of DS-Lite 

traffic. Anycast provides these benefits: 

• Service continuity and load-balancing. 

• Simplified configuration—one interface address can be used by one or more softwire 

initiators. 


93


6PE is available for ISPs with MPLS-enabled networks. These networks now can use 

MP-BGP to provide connectivity between the DS-Lite B4 and AFTR (or any two IPv6 

nodes). DS-Lite properly handles encapsulation and decapsulation despite the presence 

of additional MPLS header information. 

[Services Interfaces, Next-Generation Network Addressing Solutions] 

• Support for interface-level DHCP statistics (MX Series 3D Universal Edge 

Routers)—DHCP local server statistics are now maintained per interface. The show 

dhcp server statistics, show dhcpv6 server statistics, and clear dhcp server statistics 

commands now display information about extended DHCP and DHCPv6 local server 

statistics on the specified interface. 

[System Basics Configuration Guide] 

• Support for connection protection optimization in CFM (MX Series routers)—You 

can now optimize connection protection in Carrier Ethernet networks using existing 

continuity-check message (CCM) functionality to help increase network reliability and 

stability. Ethernet Connectivity Fault Management (CFM) monitors end-to-end services 

by exchanging CCMs at a configurable periodic interval. Starting in Release 11.4, Junos 

OS provides configuration support to trigger faster protection switching and faster 

convergence using the interface-status type, length, and value (TLV) in CCM packets 

when a failure condition is detected. Faster protection switching and convergence can 

be used when customer edge (CE) devices in the Ethernet domain detect faster service 

failures and propagates the information in the interface-status TLV of the CCMs. Upon 

receiving CCMs, the provider edge (PE) devices can configure certain actions to facilitate 

faster protection-switching and convergence. The features supported include: 

• Configuring faster protection-switching and faster convergence using an action 

profile with the action and clear-action statements. 

• Configuring a primary virtual LAN (VLAN) ID using the primary-vid statement. 

• Extending MEP functionality to accept a different maintenance association identifier 

(ID) from a neighbor by using the remote-maintenance-association statement. 


• Synchronous Ethernet support for 10-Gigabit Ethernet MICs in LAN mode (MX Series 

routers)—Junos OS Release 11.4 extends Synchronous Ethernet functionality on the 

10-Gigabit Ethernet MICs by providing support while operating in LAN framing mode. 

In LAN mode, the LAN frequency is directly fed by the MIC's on-board clocking circuitry. 

To enable Synchronous Ethernet on the 10-Gigabit Ethernet MICs, you must enable 

LAN framing mode using the framing statement's lan option at the [edit chassis fpc 

fpc-slot pic pic-slot] hierarchy level. 

The interface must be configured in LAN-PHY mode using the framing-mode 

statement's wan-phy option at the [edit interfaces xe-fpc-slot/pic-slot/port] hierarchy 

level. 

[Ethernet Interfaces] 

• New MX5, MX10, and MX40 3D Universal Edge Routers—Starting in Release 11.2R3, 

Junos OS supports three new routers based on the modular MX80 chassis. Each router 

94 



is a compact Ethernet-optimized edge router that provides switching and carrier class 

Ethernet routing. Each router provides full duplex, high-density Ethernet interfaces and 

high-capacity switching throughput and uses the Trio chipset for increased scalability 

of L2/L3 packet forwarding, buffering, and queuing. 

The ports are restricted based on the router’s associated license as follows: 

• MX5 router comes prepopulated with the Gigabit Ethernet MIC with SFP and allows 

usage of all 20 ports. 

• MX10 router comes prepopulated with the Gigabit Ethernet MIC with SFP and allows 

usage of all 20 ports and installation of an additional MIC in MIC slot 2. 

• MX40 router allows usage of both MIC slots and the first two ports of the fixed 

10-Gigabit Ethernet MIC (labeled 0/MIC 0). 

• MX80 router allows usage of both MIC slots and all four ports of the 10-Gigabit 

Ethernet MIC (labeled 0/MIC 0). 

Licenses allow you to upgrade from one router to another without a hardware upgrade. 

[MX5, MX10, MX40 and MX80 Hardware Guide, Line Card Guide] 

• License support to enhance port capacity of MX5, MX10, and MX40 routers—By 

installing additional licenses, you can enhance the port capacity of your router without 

a hardware upgrade. For example, an MX5 router, an MX10 router, or an MX40 router 

can have the port capacity of an MX80 router, provided the required licenses are 

installed. These routers use feature pack licenses, which provide additional port capacity 

with the same hardware. The soft enforcement policy allows the user to use a port for 

a certain period of time (usually a grace period of 30 days), and reverts if the license 

for that feature is not installed after the grace period. During the grace period, a reminder 

to purchase the license is reported in the system logs. Licenses can be upgraded or 

downgraded. When you downgrade the license, the port associated with the license 

is unusable. The upgrade license model with the feature ID is described in Table 3 on 

page 95. 

Table 3: Upgrade License Model for MX5, MX10, and MX40 Routers 

Feature ID 

Feature Name 

Functionality Allowed 

f1 

MX5T to MX10T upgrade 

Allows usage of ports in MIC slot 2. 

f2 


Allows usage of ports in MIC slot 2, and the first two ports of 

MIC slot 0. 

f3 


Allows usage of ports in MIC slot 2, with all four ports of MIC 

slot 0. 

To upgrade from one router to a higher-capacity router, appropriate licenses must be 

installed. For example, to upgrade an MX5 router to an MX80 router, you must install 

the licenses for all the three features listed in Table 3 on page 95. The three features 

can be provided in a single license key for ease of use. Nonapplicable feature IDs in a 

license key cause rejection of the license. If the user installs the license key for the f1 


95


feature on an MX10 router, the license key gets rejected because the MX10 router 

already has the port capacity associated with the license key for the f1 feature. 

[Line Card Guide, System Basics and Services Command Reference] 

• Support for integrated routing and bridging (IRB) MAC synchronization in 

multichassis link aggregation for aggregated Ethernet (MX Series routers)—MX 

Series routers with MPCs/MICs operating in multichassis link aggregation (MC-LAG) 

with aggregated Ethernet configurations now support integrated routing and bridging 

(IRB) MAC address synchronization. In earlier releases, VRRP was the only solution for 

sharing the same MAC across MC-LAG chassis for IRB interfaces. This feature is 

supported on 32-bit interfaces only and interoperates with earlier MPC/MIC releases.. 


• Inline static source NAT (MX Series routers with MPCs/MICs)—Enables configuration 

of MPCs/MICs to perform static source NAT IPv4 to IPv4 address translation. Use the 

new si (services-inline) interface type to define an interface that can be assigned to 

an interface style or next-hop style service set containing a NAT rule for inline NAT 

using the translation type basic-nat44. 

In order to use the inline interface, you must enable bandwidth for inline services on 

the MPC or MIC by entering the inline-services bandwidth bandwidth statement at the 

[edit chassis fpc fpc-number pic pic-number] hierarchy level. 

NOTE: Stateful firewall functionality still requires a Multiservices DPC or 

Multiservices PIC for stateful firewall–related functionality. 

Use the show services inline nat statistics interface interface-name command to display 

inline NAT statistics for all services-inline interfaces or a particular one. 

[Services Interfaces, Network Interfaces, Systems Basics and Service Command 

Reference] 

• Limiting black-hole time on M320 routers by detecting Packet Forwarding Engine 

destinations that are unreachable over the fabric—Enables M320 routers to limit 

black-hole time by detecting unreachable destination Packet Forwarding Engines. The 

router signals neighboring routers when it cannot carry traffic because of the inability 

of some or all source Packet Forwarding Engines to forward traffic to some or all 

destination Packet Forwarding Engines on any fabric plane, after interfaces have been 

created. This inability to forward traffic results in a traffic black hole by the system. 

When the system detects unreachable Packet Forwarding Engine destinations, it 

attempts to heal the traffic black hole. If the healing fails, the system turns off the 

interfaces, thereby stopping the traffic black hole and initiating the recovery process. 

The recovery process consists of the following steps: 


by one. 

2. Fabric plane and FPC restart phase: Healing is attempted by restarting both the 

fabric planes and the FPCs. If there are bad FPCs that are unable to initiate 

96 



high-speed links to the fabric after reboot, traffic black holes are limited because 

no interfaces are created for these FPCs. 

3. FPC offline phase: Traffic black holes are limited by turning the SIBs offline and by 

turning off interfaces because previous attempts at recovery have failed. 

• DS-Lite support for EIM, EIF, AP-P, and hairpinning—DS-Lite now supports: 

• EIM (Endpoint Independent Mapping)—EIM ensures that the source address and 

port are always mapped to the same address and port, irrespective of destination 

IP address and port. 

• EIF (Endpoint Independent Filtering)—EIF enables incoming traffic if at least one 

outgoing packet was sent and mapping has not timed out. 

• AP-P (Address Pooling Paired)—AP-P guarantees that an IP address is always 

mapped to the same IP address irrespective of port numbers 

• Hairpinning—Packets exiting one softwire can go back on another softwire after 

twice NAT processing. This is usually the case when one host behind the softwire 

initiator (B4) tries to communicate with a host behind another B4. 

No new CLI configuration statements have been created to implement these features. 

The following example shows a configuration that implements EIM, EIF, and AP-P. 

nat { 

rule rule1 { 

match-direction input; 

term t1 { 

then { 

translated { 

source-pool pool1; 

translation-type { 

napt-44; 

} 

mapping-type endpoint-independent; 

filtering-type { 

endpoint-independent; 

} 

address-pooling paired; 

} 

} 

} 

} 

} 


• Ping and traceroute available for DS-Lite softwire tunnels—You can now use ping 

and traceroute to determine the status of DS-Lite softwire tunnels. 

• IPv6 Ping—The softwire address endpoint on the DS-Lite softwire terminator (AFTR) 

is usually configured under softwire and need not be hosted on any interface. When 

it is not configured on any interface or loopback, previous releases of Junos OS did 

not provide replies to pings to the IPv6 softwire address. The new availability of an 

IPv6 ping provides a useful tool for the softwire initiator (B4) to verify AFTR's softwire 

address before creating a tunnel. 


97


• IPv4 Ping—A special IPv4 address, 192.0.0.1, is reserved for AFTR. Previous releases 

of Junos OS did not respond to any pings sent to this address. B4 and other IPv4 

nodes can now ping to this address to see whether the DS-Lite tunnel is working. 

• Traceroute—AFTR now generates and forwards traceroute packets over the DS-Lite 

tunnel. 

No CLI configuration is necessary to use the new functionality. The following lines have 

been added to the output of show services softwire statistics interface interface-name 

ds-lite: 

ICMPv4 Error Packets sent :0 

ICMPv6 Packets sent :0 


• Extends support of single-core Routing Engine for M7i and M10i routers—Single-core 

Routing Engine support is extended to M7i and M10i routers. This Routing Engine is 

based on the single-core Intel Xeon CPU, operating at 1.73 GHz with 2 MB cache and 

has two DDR3 DIMM slots operating at 800 MHz that support 4 GB memory with error 

checking and correction (ECC). The new Routing Engine also supports: 

• 82574 Gigabit Ethernet Controller 

• 4 GB CompactFlash card 

• USB 2.0 

• Front accessible 64 GB solid-state drive (SSD) 

All CLI commands supported on the older Routing Engine are supported on the new 

Routing Engine. 

• Improvements to interface transmit statistics reporting (MX Series routers)—On 

MX Series routers, the logical interface-level statistics show only the offered load, 

which is often different from the actual transmitted load. To address this limitation, 

Junos OS introduces a new configuration statement in Release 11.4 R3 and later. The 

new configuration statement, interface-transmit-statistics at the [edit interface 

interface-name] hierarchy level, enables you to configure Junos OS to accurately capture 

and report the transmitted load on interfaces. 

When the interface-transmit-statistics statement is included at the [edit interface 

interface-name] hierarchy level, the following operational mode commands report the 

actual transmitted load: 

• show interface interface-name 

• monitor interface interface-name 

• show snmp mib get objectID.ifIndex 

NOTE: This configuration is not supported on Enhanced IQ (IQE) and 

Enhanced IQ2 (IQ2E) PICs. 

98 



The show interface interface-name command also shows whether the 

interface-transmit-statistics configuration is enabled or disabled on the interface. 

• Support for redundant fabric made on active control boards of MX Series routers—An 

FPC working with reduced fabric bandwidth can affect the rerouting process and can 

cause partial traffic black holes. You can now enable increased fabric bandwidth of 

active control boards for optimal and efficient performance and traffic handling. On 

an MX960, MX480, or MX240 router, you can configure the active control board to be 

in redundancy mode or in increased fabric bandwidth mode. In increased fabric 

bandwidth mode, the maximum number of available fabric planes are used for MX 

routers with Trio chips and the MPC3E. On MX960 routers with active control boards, 

six active planes are used, and on MX240 and MX480 routers with active control 

boards, eight active planes are used. 

To configure redundancy mode for the active control board, use the redundancy-mode 

redundant statement at the [edit chassis fabric] hierarchy level. When you configure 

this option, all the FPCs use four fabric planes as active planes, regardless of the type 

of the FPC. If you do not configure this option, increased fabric bandwidth mode is 

enabled by default on MX Series routers with a Switch Control Board (SCB). On the 

MX Series routers that contain the enhanced SCB with Trio chips and the MPC3E, the 

control boards operate in redundancy fabric mode (all the FPCs use four fabric planes 

as active planes) by default. 

To configure increased bandwidth mode for the active control board, use the 

increased-bandwidth statement at the [edit chassis fabric] hierarchy level. When you 

configure this option, all the available fabric planes are used. 

Configuring this feature does not affect the system. You can configure this feature 

without restarting the FPC or restarting the system. 

You can use the show chassis fabric redundancy-mode command to verify whether the 

redundancy fabric mode is enabled. 


• Support for disabling an FPC with degraded fabric bandwidth —An FPC working with 

degraded fabric bandwidth can affect the re-routing process and can cause partial 

traffic black holes. On an MX960, MX480, or MX240 router, you can now configure 

the option to bring down an FPC whose fabric bandwidth has degraded because of 

link errors or bad fabric planes. This configuration is particularly useful in partial 

black-hole scenarios where bringing the FPC offline results in faster re-routing. 

To configure this option on an FPC, use the offline-on-fabric-bandwidth-reduction 

statement at the [edit chassis fpc slot-number] hierarchy level. 




• Limiting traffic black-hole time by detecting Packet Forwarding Engine destinations 

that are unreachable over the fabric (MX240, MX480, and MX960 routers)—Enables 

the MX240, MX480, and MX960 routers to limit traffic black-hole time by detecting 

unreachable destination Packet Forwarding Engines. The router signals neighboring 


99


routers when it cannot carry traffic because of the inability of some or all source Packet 

Forwarding Engines to forward traffic to some or all destination Packet Forwarding 

Engines on any fabric plane, after interfaces have been created. This inability to forward 

traffic results in a traffic black hole. 

Packet Forwarding Engine destinations can become unreachable for the following 

reasons: 

• The control boards go offline as a result of a CLI command or a pressed physical 

button. 

• The fabric control boards are turned offline because of high temperature. 


• All Packet Forwarding Engines receive destination errors on all planes from remote 



When the system detects any unreachable Packet Forwarding Engine destinations, 

healing from a traffic black hole is attempted. If the healing fails, the system turns off 

the interfaces, thereby stopping the traffic black hole. 

The recovery process consists of the following phases: 


by one. This phase does not start if the fabric plane is functioning properly and a 

single Flexible PIC Concentrator (FPC) is bad. An error message is generated to 

specify that a black hole is the reason for the fabric plane being turned offline. This 

phase is performed for fabric plane errors only. 

2. Fabric plane and FPC restart phase: The system waits for the first phase to be 

completed before examining the system state again. If the black hole condition still 

persists after the first phase is performed or if the problem occurs again within a 

duration of 10 minutes, healing is attempted by restarting both the fabric planes 

and the FPCs. If you the configured the action-fpc-restart-disable statement at the 

[edit chassis fabric degraded] hierarchy level to disable restart of the FPCs when a 

recovery is attempted, an alarm is triggered to indicate that a traffic black hole has 

occurred. In this second phase, three steps are taken: 

1. All the FPCs that have destination errors on a PFE are turned offline 

2. The fabric planes are turned offline and brought back online, one by one, starting 

with the spare plane. 

3. The FPCs that were turned offline are brought back online. 

3. FPC offline phase: The system waits for the second phase to be completed before 

examining the system state again. Traffic black hole is limited by turning the FPCs 

offline and by turning off interfaces because previous attempts at recovery have 

failed. If the problem is not resolved by restarting the FPCs or if the problem recurs 

within 10 minutes after restarting the FPCs, this phase is performed. 



100 





In Junos OS Release 11.4R2 and later, and Junos OS Release 12.1R1 and later, new alarms 

are added to indicate which FPCs are creating a traffic black hole in the system and 

to provide information about FPCs that are turned offline to stop the black hole in the 

recovery process. 

In Junos OS Release 11.4R2 and later, and Junos OS Release 12.1R1 and later, new error 

messages are added to indicate whether the traffic black hole is detected by 

unreachable FPCs in the system, or it is due to all planes being offline. These messages 

also indicate the actions taken on FPCs and planes to stop the black hole—for example, 

FPC online, FPC offline , FPC restart, FPC power off, plane online, and plane offline. 

Two new CLI commands are introduced for this feature: 






Junos OS XML API and Scripting 

• Junos XML protocol operation supports loading sets of 

configuration mode commands —In Junos XML protocol sessions, the 

tag element supports the value set for the action attribute, which 

allows the client application to provide configuration data as a set of Junos OS 

configuration mode commands. When a set of configuration mode commands is 

provided as a data stream, it is enclosed in the tag element. When 

the set is provided in a previously saved file, the tag element is not 

included in the file. When the action attribute has a value of set, the default and only 

acceptable value for the format attribute is text. 

 

 

 

 

 

/* configuration mode commands to load */ 

 

 

 

[Junos XML Management Protocol Guide] 

• NETCONF Perl client installation supports loading prerequisites from CPAN—Starting 

with Junos OS Release 11.4, when installing the NETCONF Perl client prerequisites, the 

install-prereqs.pl script provides the option to install all Perl modules that are part of 

the prerequisites directly from the Comprehensive Perl Archive Network (CPAN) global 

repository. 


101


[NETCONF XML Management Protocol Guide] 

• Support added for the format attribute in Junos XML API operational request tags 

within a Junos XML protocol or NETCONF session—In Junos XML protocol and 

NETCONF sessions, a client application can include the format="text" or format="ascii" 

attribute in the opening tag of operational requests. The server formats the reply as 

ASCII text instead of the default XML-tagged format. The response, which is enclosed 

in an output tag element within the tag element, is identical to the CLI 

output except in cases where it includes disallowed characters. The Junos XML protocol 

server substitutes these characters with the equivalent predefined entity reference. 

 

[format="(text | ascii)"] 

 

 

 

 

operational-response 

 

 

[NETCONF XML Management Protocol Guide, Junos XML Management Protocol Guide] 

• Support added for NETCONF sessions in the jcs:open() function—The jcs:open() 

function includes the option to create a session either with the Junos XML protocol 

server on devices running Junos OS or with the NETCONF server on devices where 

NETCONF service over SSH is enabled. The additional support for NETCONF sessions 

permits automation scripts to configure and manage devices in a multivendor 

environment. 

When specifying a session protocol, the SLAX syntax is: 

var $connection = jcs:open(remote-hostname, 

session-options); 

where session-options is an XML node-set that specifies the session protocol and 

connection parameters. The structure of the node-set is: 

var $session-options := { 

("junoscript" | "netconf" | "junos-netconf"); 

"username"; 

"passphrase"; 

"password"; 

"port-number"; 

Specifying a value of junoscript establishes a session with the Junos XML 

protocol server on a device running Junos OS, specifying netconf establishes a session 

with a NETCONF server over an SSHv2 connection, and specifying junos-netconf 

establishes a session with the NETCONF server over an SSHv1 connection on a device 

running Junos OS. If you do not specify a protocol, a junoscript session is created by 

default. 

[Junos OS Configuration and Operations Automation Guide] 

• NETCONF Java toolkit for rapid development of Java applications to manage Junos 

devices—The toolkit provides an object-oriented programmatic interface to manage 

102 



and configure Junos routing, switching, and security devices via NETCONF (RFC 4741) 

protocol. The toolkit enables programmers familiar with the Java programming language 

to easily connect to a routing, switching, or security device, open a NETCONF session, 

construct configuration hierarchies in XML, and create and execute operational and 

configuration requests. 

The NETCONF Java toolkit provides classes with methods that implement the 

functionality of the NETCONF protocol operations defined in RFC 4741. All basic protocol 

operations are supported. The NETCONF XML management protocol uses XML-based 

data encoding for configuration data and remote procedure calls. The toolkit provides 

classes and methods that aid in creating, modifying, and parsing XML. 

[NETCONF Java Toolkit Guide] 

• jcs:open() extension function support for routing instances—The jcs:open() extension 

function returns a connection handle that is used to execute RPCs on a local or remote 

device. To redirect the SSH connection to originate from within a specific routing 

instance, include the name of the routing instance in the connection parameters. The 

routing instance must be configured at the [edit routing-instances] hierarchy level, and 

the remote device must be reachable either using the routing table for that routing 

instance or from one of the interfaces configured under that routing instance. 


• Support for commit script access to the pre-inheritance candidate configuration in 

configure private sessions—Commit scripts can now invoke the 

RPC in a private configuration session to retrieve the private, pre-inheritance candidate 

configuration for that session. The RPC now includes the 

database-path attribute, which is used to specify the location of the pre-inheritance 

configuration database. In addition, the global variable, $junos-context contains a new 

commit-context/database-path element , which stores the location of the session’s 

pre-inheritance candidate configuration. 

To construct a commit script that retrieves the pre-inheritance candidate configuration 

specific to that session, include the RPC in the commit script, and 

set the attribute to $junos-context/commit-context/database-path. 

This feature is available in Junos OS Release 11.4R5 and subsequent 11.4 releases. 

Layer 2 Ethernet Services 

• IP multicast over Layer 2 trunk port support—Layer 3 multicast is now supported on 

Layer 2 trunk ports through integrated routing and bridging (IRB) interfaces on the 

MX80 router and on MX Series routers using Modular Port Concentrators 

(MPCs)/Modular Interface Controllers (MICs). 

[Layer 2] 

• Support for RADIUS attribute Local-Loopback-Interface for L2TP—With this release, 

the RADIUS attribute Local-Loopback-Interface [26-3] is now supported for an L2TP 

LAC configured on an MX Series router. 

You can configure the Local-Loopback-Interface attribute on a RADIUS server to 

manage multiple LAC devices. This attribute is used as the LAC source address on an 

LNS tunnel for PPPoE subscribers tunneled over L2TP. 


103


When you use the Tunnel-Client-Endpoint attribute as the LAC source address, you 

must configure the Tunnel-Client-Endpoint attribute for each MX Series router that 

uses the same RADIUS server. Starting with this release, you can use the 

Local-Loopback-Interface attribute, which needs to be configured only once. 

When the LAC initiates an Access-Request message to RADIUS for authentication, 

RADIUS returns the Local-Loopback-Interface attribute in the Access-Accept message. 

This attribute contains the name of the loopback interface, either as a generic interface 

name such as “lo0” or as a specific name like “lo0.0.” The MX Series router then uses 

the configured loopback interface IP address as the source address during tunnel 

negotiation with the LNS. 

MPLS Applications 

• Support for RSVP-signaled point-to-multipoint LSPs extended to logical systems 

(M Series, T Series, and MX Series routers)—Starting with Junos OS Release 11.4, the 

following topologies are supported: 

• A single logical system in a physical router. The logical system is one node in an 

RSVP-signaled point-to-multipoint LSP. 

• Multiple logical systems in a physical router, with each logical system acting as a 

label-switched router (LSR). The multiple logical systems can be unconnected, 

connected to each other internally with logical tunnel (lt) interfaces, or connected 

to each other externally with back-to-back connections. 

• One RSVP-signaled point-to-multipoint LSP, with some nodes being logical systems 

and other nodes being physical routers. 

• Support for shared risk link groups—In MPLS traffic engineering, a shared risk link 

group (SRLG) is a set of links sharing a common resource, which affects all links in the 

set if the common resource fails. These links share the same risk of failure and are 

therefore considered to belong to the same SRLG. For example, links sharing a common 

fiber are said to be in the same SRLG because a fault with the fiber might cause all 

links in the group to fail. 

An SRLG is represented by a 32-bit number unique within an IGP (OSPFv2 and IS-IS) 

domain. A link might belong to multiple SRLGs. The SRLG of a path in an LSP is the 

set of SRLGs for all the links in the path. When computing the secondary path for an 

LSP, it is preferable to find a path such that secondary and primary paths do not have 

any links in common and the SRLGs for the primary and secondary paths are disjoint. 

This ensures that a single point of failure on a particular link does not bring down both 

the primary and the secondary paths in the LSP. 

When SRLG is configured, the device uses the Constrained Shortest Path First (CSPF) 

algorithm and tries to keep the links used for the primary and secondary paths mutually 

exclusive. If the primary path goes down, the CSPF algorithm computes the secondary 

path by trying to avoid links sharing any SRLG with the primary path. In addition, when 

computing the path for a bypass LSP, CSPF tries to avoid links sharing any SRLG with 

the protected links. 

When SRLG is not configured, CSPF only takes into account the costs of the links when 

computing the secondary path. 

104 



Any change in link SRLG information triggers the IGP to send LSP updates for the new 

link SRLG information. CSPF recomputes the paths during the next round of 

reoptimization. 

Junos OS Release 11.4 and later support SRLG based on the following RFCs: 

• RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching 

(GMPLS). 

• RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching 

(GMPLS). 

To configure the SRLG name, cost, and value, include the srlg srlg-name statement at 

the following hierarchy levels: 

• [edit routing-options] 

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

The srlg srlg-name statement has the following options: 

• srlg-cost—Include a cost for the SRLG ranging from 1 through 65535. The cost of 

the SRLG determines the level of impact this SRLG has on the CSPF algorithm for 

path computations. The higher the cost, the less likely it is for a secondary path 

to share the same SRLG as the primary path. By default, the srlg-cost is 1. 

• srlg-value—Include a group ID for the SRLG ranging from 1 through 4294967295. 

• Associate the SRLG with the MPLS interface at the [edit protocols mpls interface 

interface-name] or [edit logical-systems logical-system-name protocols mpls interface 

interface-name] hierarchy level. 

• For critical links where it is imperative to keep the secondary and primary paths 

completely disjoint from any common SRLG, configure the exclude-srlg statement 

at the [edit protocols mpls label-switched-path path-name] or [edit logical-systems 

logical-system-name protocols mpls label-switched-path path-name] hierarchy level. 

If exclude-srlg is configured, the CSPF algorithm excludes any link belonging to the 

set of SRLGs in the primary path. If exclude-srlg is not configured, and if a link belongs 

to the set of SRLGs in the primary path, CSPF adds the SRLG cost to the metric, but 

still accepts the link for computing the path. 

• To make the dynamic bypass LSP and the protected link completely disjoint in any 

SRLG, configure the exclude-srlg statement at the [edit protocols rsvp interface 

interface-name link-protection] or [edit logical-systems logical-system-name protocols 

rsvp interface interface-name link-protection] hierarchy level. 

• To make the manual bypass LSP and the protected link to be completely disjoint in 

any SRLG, configure the exclude-srlg statement at the [edit protocols rsvp interface 

interface-name link-protection bypass destination] hierarchy level or the [edit 

logical-systems logical-system-name protocols rsvp interface interface-name 

link-protection bypass destination] hierarchy level. 

For manual and dynamic bypass LSPs, if exclude-srlg is configured, the CSPF 

algorithm excludes any link belonging to the set of SRLGs of the protected link. If 

exclude-srlg is not configured, and if a link belongs to the set of SRLGs of the 


105


protected link, CSPF adds the SRLG cost to the link metric, but still accepts the link 

for computing the path. 

Use the following operational mode commands to verify the SRLG configuration: 

• show mpls srlg—Verify SRLG-to-value mappings and SRLG cost. 

• show mpls lsp—Verify that when the primary or secondary path is up, the appropriate 

SRLG values are shown. 

• show mpls interface—Verify that the correct SRLG is associated with the appropriate 

interface. 

• show isis database extensive and show ospf database extensive—Verify the SRLG 

values in the type length values (TLV). 

• show ted database extensive and show ted link detail—Verify that the output shows 

the correct SRLG on the TE link. 

• show mpls admin-groups-extended—View MPLS extended administrative groups. 

[MPLS] 

• Support for MPLS feature interoperability (MX Series routers with MPC/MIC 

interfaces)—Extends support for MPLS feature interoperability with Junos OS Releases 

9.5 through 10.0 on MX Series routers with MPC/MIC interfaces. MPLS features can 

now interoperate between MPCs and DPCs on MX Series routers. 

The following features are supported on MPC/MIC interfaces: 

• Configuring up to 64 equal-cost multipaths (ECMP) next hops to load-balance the 

traffic on various routes such as OSPF, BGP, and IS-IS. 

• Configuring a network of RSVP-signaled MPLS routers to automatically update the 

full mesh of label-switched paths (LSPs) between the provider edge (PE) routers 

whenever a new PE router is added. 

[System Basics Configuration Guide, MPLS Configuration Guide] 

• Enhanced support for Junos Trio chipsets—Starting with Junos OS Release 11.4, the 

Junos Trio chipset supports the following features: 

• Multicast load balancing of point-to-multipoint label-switched-paths (LSPs) over 

aggregated Ethernet child links. 

• Automatic policers for MPLS point-to-multipoint LSPs. 

• Display of packet and byte statistics for sub-LSPs of a point-to-multipoint LSP. 

• GRES and graceful restart for MPLS point-to-multipoint LSPs. 

• Multicast virtual private network (MVPN) extranet or overlapping functionality. 

[MPLS, VPNs] 

• Host fast reroute (HFRR)—This feature adds a precomputed protection path into the 

Packet Forwarding Engine, such that if a link between a provider edge device and a 

server farm becomes unusable for forwarding, the Packet Forwarding Engine can use 

another path without having to wait for the router or the protocols to provide updated 

106 



forwarding information. HFRR is a technology that protects IP endpoints on multipoint 

interfaces, such as Ethernet. This technology is important in data centers where fast 

service restoration for server endpoints is critical. After an interface or a link goes down, 

HFRR enables the local repair time to be approximately 50 milliseconds. You can 

configure HFRR by adding the link-protection statement to the interface configuration 

in the routing instance. We recommend that you include this statement on all provider 

edge (PE) devices that are connected to server farms through multipoint interfaces. 

• LSP setup protection using facility backup fast reroute—The facility-backup fast 

reroute mechanism has been extended to provide setup protection for LSPs that are 

in the process of being signaled. This feature is applicable in the following scenario: 

1. A failed link or node is present on the strict explicit path of an LSP before the LSP 

is signaled. 

2. There is also a bypass LSP protecting the link or node. 

3. RSVP signals the LSP through the bypass LSP. The LSP appears as if it was originally 

set up along its primary path and then failed over to the bypass LSP because of the 

link or node failure. 

4. When the link or node has recovered, the LSP can be automatically reverted to the 

primary path. 

Both point-to-point LSPs and point-to-multipoint LSPs are supported. To enable LSP 

setup protection, configure the setup-protection statement at the [edit protocols rsvp] 

hierarchy level. You should configure the setup-protection statement on each of the 

routers along the LSP path on which you want to enable LSP setup protection. You 

should also configure IGP traffic engineering on all of the routers on the LSP path. You 

can issue a show rsvp session command to determine whether or not the LSP has setup 

protection enabled on a router acting as a point of local repair (PLR) or a merge point. 

[MPLS Applications] 

Multicast 

• Source-specific multicast (SSM)-map definition for different groups to different 

sources—You can configure multiple source-specific multicast (SSM) maps so that 

different groups map to different sources, which enables a single multicast group to 

map to different sources for different interfaces. 

You do not need to separately define the SSM map and specify the sources to be used 

for mapping when the policy matches. That is, you do not need to include the ssm-map 

statement at the [edit routing-options multicast] hierarchy level: 

ssm-map ssm-map-name { 

policy (SSM Maps) [ policy-names ]; 

source [ addresses ]; 

} 

Instead, you can specify the SSM map in the then statement of the routing policy term 

by specifying the new ssm-source [ ip-addresses ] action that manipulates route 

characteristics: 

ssm-source [ addresses ]; 


107


policy-options { 

policy-statement ssm-policy-name { 

term term-name { 

from { 

route-filter match-condition { 

} 

then { 

ssm-source [ ip-addresses ]; 

accept; 

} 

} 

} 

} 

In the ssm-source action, you use the list of ip-addresses to specify one or more IPv4 

or IPv6 source addresses for the SSM policy. 

[Multicast Routing Protocols] 

Network Management 

• New enterprise-specific MIBs to view PPP and PPPoE information (M Series and 

MX Series routers)—Junos OS Release 11.4 introduces three new enterprise-specific 

MIBs to extend SNMP support for PPP over PPPoE interfaces and PPPoE over Ethernet 

interfaces: JNX-PPP-MIB (RFC 1661), PPP-LCP-MIB (RFC 1471), and JNX-PPPOE-MIB 

(RFC 2516). PPP MIBs are supported on the Common Edge PPP process, jpppd. The 

PPPoE MIB is supported on the Common Edge PPPoE process, jpppoed. These MIBs 

contain PPP- and PPPoE-related information such as the type of authentication used, 

interface characteristics, status, and statistics. 

You can access this information using SNMP get and get-next requests. If an attribute 

is not supported, the attribute returns either zero or the default value. 

[SNMP MIBs and Traps Reference] 

• Support for P2MP MPLS-TE MIB—Starting with Release 11.3, Junos OS supports the 

standard P2MP MPLS-TE MIB as defined in draft-ietf-mpls-p2mp-te-mib-09.txt. Support 

for P2MP MPLS-TE MIB augments the standard P2P MPLS-TE MIB defined in RFC 3812 

and extends SNMP support to point-to-multipoint tunnel-related data. However, Junos 

OS implementation of the standard P2MP MPLS-TE MIB does not support 

mplsTeP2mpTunnelBranchPerfTable because Junos OS does not support the 

corresponding table in MPLS-TE MIB. 


• SNMP support for LAC and LNS (MX Series routers with MPC/MIC interfaces)—SNMP 

extends support for MX Series routers with MPC/MIC interfaces acting as the L2TP 

network server (LNS) and L2TP access concentrator (LAC) in Junos OS Release 11.4 

and later. In earlier releases, SNMP support for LAC and LNS was provided only for M 

Series routers. 

The existing enterprise-specific MIB, JNX-L2TP-MIB, now maintains tunnel and session 

information for both M Series and MX Series routers. The MX Series routers use the 

Common Edge L2TP process, jl2tpd. 

108 



The following objects are not supported on the jl2tpd LAC in jnxL2TPTunnelStatsTable 

and jnxL2TPSessionStatsTable: 

• jnxL2tpTunnelStatsServiceInterface (applicable to LNS only) 

• jnxL2tpTunnelStatsTunnelGroup (applicable to LNS only) 

• jnxL2tpSessionStatsServiceInterface (applicable to LNS only) 

• jnxL2tpSessionStatsTunnelGroup (applicable to LNS only) 

• jnxL2tpSessionStatsInterfaceID (Applicable to LNS only) 

The following objects are not supported on jl2tpd: 

• jnxL2tpSessionStatsUserName 

• jnxL2tpSessionAssignedIpAddrType 

• jnxL2tpSessionAssignedIpAddress 

• jnxL2tpSessionLocalMRU 

• jnxL2tpSessionRemoteMRU 

• jnxL2tpSessionStatsAuthMethod 

• jnxL2tpSessionStatsNasIpAddrType 

• jnxL2tpSessionStatsNasIpAddress 

• jnxL2tpSessionStatsNasIpPort 

• jnxL2tpSessionStatsFramedProtocol 

• jnxL2tpSessionStatsFramedIpAddrType 

• jnxL2tpSessionStatsFramedIpAddress 

• jnxL2tpSessionStatsAcctDelayTime 

• jnxL2tpSessionStatsAcctSessionID 

• jnxL2tpSessionStatsAcctMethod 

• jnxL2tpSessionStatsAcctSessionTime 

• jnxL2tpSessionStatsAcctNasPortType 

• jnxL2tpSessionStatsAcctTnlClientAuthID 

• jnxL2tpSessionStatsAcctTnlServerAuthID 

• jnxL2tpSessionStatsUserProfileName 

The following objects in jnxL2tpTunnelStatsTable are not available on MPC/MICs: 

• jnxL2tpTunnelStatsErrorTxPkts 

• jnxL2tpTunnelStatsErrorRxPkts 

These objects continue to be supported by the M Series routers. You can access the 

tunnel- and session-related information for both the processes using SNMP get and 


109


get-next requests. If an object is not supported, the object returns either zero or the 

default value. 


• Enhancements to the jnxOperatingCPU Object—Junos OS Release 11.3 introduces the 

following three MIB objects to enhance the CPU utilization reporting over SNMP: 

• jnxOperating1MinAvgCPU—Indicates the average utilization of CPU during the last 

minute. 


5-minute period. 


15-minute period. 

All these objects return a zero value if the data is not available or is not applicable. 


• Support for the pimNeighborLoss trap—Starting with Release 11.4, Junos OS supports 

the pimNeighborLoss trap as defined in RFC 2934. The Junos OS implementation of 

RFC 2934 is based on a draft version of the PIM MIB as defined in the pimmib.mib in 

the Junos OS Standard MIBs package. 

The pimNeighborLoss trap is generated when the device loses the adjacency with its 

only neighbor that has an IP address lower than that of the interface to which the 

neighbor is connected. 


• MIB Support for VRF Route Entries—Starting with Release 11.4, Junos OS extends the 

SNMP support to Layer 3 Virtual Private Network (VPN) Routing and Forwarding Table 

(VRF) entries as defined in RFC 4382, MPLS/BGP Layer 3 Virtual Private Network (VPN) 

MIB. 

The Junos OS support for RFC 4382 includes the following scalar objects and tables: 

• mplsL3VpnConfiguredVrfs 

• mplsL3VpnActiveVrfs 

• mplsL3VpnConnectedInterfaces 

• mplsL3VpnNotificationEnable 

• mplsL3VpnVrfConfMaxPossRts 

• mplsL3VpnVrfConfRteMxThrshTime 

• mplsL3VpnIllLblRcvThrsh 

• mplsL3VpnVrfTable 

• mplsL3VpnIfConfTable 

• mplsL3VpnVrfPerfTable 

110 



• mplsL3VpnVrfRteTable 

• mplsVpnVrfRTTable 

[ SNMP MIBs and Traps Reference ] 

• Junos OS MIB support for VPLS—Starting with Release 11.4, Junos OS extends SNMP 

support to virtual private LAN services (VPLS) networks so that users can access 

VPLS-related data over SNMP. The Junos OS SNMP support for VPLS covers both 

BGP-based and LDP-based VPLS networks. 

The Junos OS SNMP support for VPLS is based on the IETF standard MIB 

draft-ietf-l2vpn-vpls-mib-05.txt. Juniper Networks extension of the following MIBs 

defined in draft-ietf-l2vpn-vpls-mib-05.txt are implemented as part of the jnxExperiment 

branch: 

• VPLS-Generic-Draft-01-MIB implemented as mib-jnx-vpls-generic.txt. 

• VPLS-BGP-Draft-01-MIB implemented as mib-jnx-vpls-bgp.txt. 

• VPLS-LDP-Draft-01-MIB implemented as mib-jnx-vpls-ldp.txt. 

In the Junos OS implementation of these MIBs, all MIB objects are prefixed with jnx. 


• Extended support for the enterprise-specific License MIB—Starting with Junos OS 

Release 11.3, the enterprise-specific License MIB is supported on all devices running 

Junos OS. The enterprise-specific License MIB was supported only on SRX devices 

when the License MIB was introduced in Junos OS Release 11.2. 


• SNMP poll and trap support for DHCP leases (MX Series 3D Universal Edge 

Routers)—The Juniper Networks enterprise-specific DHCP and DHCPv6 MIB objects, 

jnxJdhcpMIB and jnxJdhcpv6MIB, have been modified to contain a new table for 

interface statistics and additional notifications. This feature includes support for gets 

and traps and support for DHCP local server and relay and DHCPv6 local server. 


• SNMP support for address counters (MX Series 3D Universal Edge Routers)—This 

feature provides the ability to track the usage of address resources off-chassis. 


• Junos OS support for proxy SNMP agent—Junos OS enables you to assign one of the 

devices in the network as a proxy SNMP agent through which the network management 

system (NMS) can query other devices in the network. When you configure a proxy, 

you can specify the names of devices to be managed through the proxy SNMP agent. 

When the NMS queries the proxy SNMP agent, the NMS specifies the community name 

(for SNMPv1 and SNMPv2) or the context and security name (for SNMPv3) associated 

with the device from which it requires the information. 


111


NOTE: If you have configured authentication and privacy methods and 

passwords for SNMPv3, those parameters are also specified in the query 

for SNMPv3 information. 

To configure a proxy SNMP agent and specify devices to be managed by the proxy 

SNMP agent, you can include the following configuration statements at the [edit snmp] 

hierarchy level: 

proxy proxy-name{ 

device-name device-name; 

{ 

snmp-community community-name; 

no-default-comm-to-v3-config; 

} 

version-v3 { 

security-name security-name; 

context context-name; 

} 

logical-system logical-system { 

routing-instance routing-instance; 

} 

routing-instance routing-instance; 

} 

• The proxy statement enables you to specify a unique name for the proxy configuration. 

• The version-v1, version-v2, and version-v3 statements enable you to specify the SNMP 

version. 

• The no-default-comm-to-v3-config statement is an optional statement at the [edit 

snmp proxy proxy-name ] hierarchy level that when included 

in the configuration requires you to manually configure the statements at the [edit 

snmp v3 snmp-community community-name] and [edit snmp v3 vacm] hierarchy 

levels. 

If the no-default-comm-to-v3-config statement is not included at the [edit snmp 

proxy proxy-name ] hierarchy level, the [edit snmp v3 

snmp-community community-name] and [edit snmp v3 vacm] hierarchy level 

configurations are automatically initialized. 

• The logical-system and routing-instance statements are optional statements that 

enable you to specify logical system and routing instance names if you want to create 

proxies for logical systems or routing instances on the device. 

NOTE: The community and security configuration for the proxy should 

match the corresponding configuration on the device that is to be managed. 

112 



NOTE: Because the proxy SNMP agent does not have trap forwarding 

capabilities, the devices that are managed by the proxy SNMP agent send 

the traps directly to the network management system. 

You can use the show snmp proxy operational mode command to view proxy details 

on a device. The show snmp proxy command returns the proxy names, device names, 

SNMP version, community/security, and context information. [Network Management] 

Routing Protocols 

• IPv6 tunneling capability on MX Series routers with MPCs now supported—Starting 

in Junos OS Release 11.4R6, MX Series routers with MPCs support IPv6 tunnel 

functionality. IPv6 encapsulation will be supported for both IPv4 and IPv6 packets. 

The following matrix summarizes the IP-IP tunnel functionality in MX Series routers 

with MPCs. 

• 

Inner Header 

IPv4 

Outer Header IPv4 

Yes (existing) 

Outer header IPv6 

Yes (with this PR) 

IPv6 

Yes (existing) 

YES (with this PR) 

See PR/574342 for more details. 

• For internal BGP (IBGP), advertise multiple paths to a destination (M Series, MX 

Series, and T Series routers)—For IPv4 unicast (family inet unicast) routes only, enables 

an IBGP peer to advertise multiple exit points to reach a destination. This provides fault 

tolerance, load balancing, and graceful maintenance operations. 

To set the number of paths to send to a neighbor, include the add-path send path-count 

number statement at the [edit protocols bgp group group-name neighbor address family 

inet unicast] hierarchy level. 

To enable a peer to receive multiple paths, include the add-path receive statement at 

the [edit protocols bgp group group-name family inet unicast] hierarchy level. 

To apply a policy that allows a BGP peer to send multiple paths for only specific routes, 

include the add-path send prefix-policy policy-name statement at the [edit protocols 

bgp group group-name neighbor address family inet unicast] hierarchy level. 

To configure the policy, use the policy-options hierarchy level, as you normally would. 

For example: 

user@host# set policy-options policy-statement allow_199 from route-filter 

199.1.1.1/32 exact 

user@host# set policy-options policy-statement allow_199 then accept 

[Routing Policy] 

• Frequent BGP keepalive messages and short BGP hold time—Enables BGP sessions 

to send frequent keepalive messages with a hold time as short as 10 seconds. Note 

that the hold time is three times the interval at which keepalive messages are sent, 


113


and the hold time is the maximum number of seconds allowed to elapse between 

successive keepalive messages that BGP receives from a peer. When establishing a 

BGP connection with the local routing device, a peer sends an open message, which 

contains a hold-time value. BGP on the local routing device uses the smaller of either 

the local hold-time value or the peer’s hold-time value as the hold time for the BGP 

connection between the two peers. The default hold time is 90 seconds, meaning that 

the default frequency for keepalive messages is 30 seconds. More frequent keepalive 

messages and shorter hold times might be desirable in large-scale deployments with 

many active sessions (such as edge or large VPN deployments). 

To configure the hold time and the frequency of keepalive messages, include the 

hold-time statement at the [edit protocols bgp] hierarchy level. You can configure the 

hold time at a logical-system, routing-instance, global, group, or neighbor level. When 

you set a hold-time value to less than 20 seconds, we recommend that you also 

configure the BGP precision-timers statement. The precision-timers statement ensures 

that if scheduler slip messages occur, the routing device continues to send keepalive 

messages. When the precision-timers statement is included, keepalive message 

generation is performed in a dedicated kernel thread, which helps to prevent BGP 

session flaps. 

[Routing Protocols] 

Services Applications 

• Subscriber profiles for service activation—Enables you to specify which service plug-ins 

become activated on a per-subscriber basis. Previously, the only control mechanism 

for specifying service activation was to attach a service-set configuration to a selected 

interface or route. The new utility allows you to enable or disable services based on 

the subscriber associated with every data flow. As a result, you can apply differentiated 

services to different sets of subscribers. 

You can exercise the control mechanism in one of two ways, by using a CLI operational 

command or a RADIUS attribute. This feature applies only to MP-SDK services and 

does not depend on the specific services enabled or disabled, except that PTSP must 

be included in the chain. 

The general procedure consists of three steps: 

1. Configure a service set that includes all the services to be applied to flows. You can 

include a default subscriber profile that controls which services are and are not 

active by default. The default profile applies to all subscribers until overridden for 

a specific subscriber. In the absence of a default subscriber profile, all services 

specified in the service set are applied by default. You can also include one or more 

alternative subscriber profiles that can be implemented to override the default 

profile. The following sample configuration illustrates these components: 

services { 

service-set ss1 { 

application-identification-profile appidr1; 

idp-profile idpr1; 

aacl-rules aaclr1; 

hcm_rules hcmr1; 

sfw_rules sfwr1; 

114 



subscriber-profile { 

sp1; 

} 

interface-service { 

service-interface ms-3/0/0.0; 

} 

} 

subscriber-profile sp1 { 

disable HCM; 

enable IDP { 

concurrent-data-sessions 10; 

} 

disable AACL; 

max-data-sessions-per-subscriber { 

limit 10; 

exceed-action [ syslog drop ]; 

} 

} 

subscriber-profile sp2 { 

enable HCM; 

disable IDP; 

enable AACL, 

max-data-sessions-per-subscriber { 

limit 100; 

exceed-action [ syslog ]; 

} 

} 

} 

Initially, all traffic reaching the service plane under service set ss1 receives all the 

services configured in service set ss1 that are enabled by the default subscriber 

profile sp1 applied to it. In the example, APPID, stateful firewall, and IDP are enabled, 

while HCM and AACL are disabled. However, IDP is enabled for only at most 10 

sessions concurrently. Beyond that threshold, IDP is also disabled. Also, because 

of the max-data-sessions-per-subscriber setting, any subscriber will be allowed a 

maximum of 10 concurrent data sessions. Beyond that threshold, data sessions will 

be logged and dropped. 

2. Dynamically override the default subscriber profile associated with a particular 

PTSP subscriber by using one of the following: 

• CLI operational command 

• RADIUS attribute setting in the access-accept message 

From the previous example, assume that the subscriber profile for subscriber X is 

dynamically set to sp2. After that, any new data session associated with subscriber 

X will have a different set of services applied to it. In the example, it would be APPID, 

stateful firewall, HCM, and AACL. Also, because the 

max-data-sessions-per-subscriber setting changes to 100, subscriber X will now 

have no upper limit on the number of concurrent data sessions, although if that 

number crosses the 100 threshold, the threshold-crossing event will be logged. 

The following examples illustrate the dynamic override settings: 


115


Operational command: 

user@router> request services subscriber clear subscriber-profile client-id client-id 

user@router> request services subscriber set subscriber-profile 

subscriber-profile-name client-id client-id 

RADIUS configuration: 

user@router# set system services packet-triggered-subscribers partition-radius foo 

subscriber-service-profile attribute-26.4874.31 

3. Process a new data session at the service plane. This takes place as follows, with 

respect to subscriber profiles: 

1. A new flow starts. MP-SDK sends a SESSION-INTEREST event to the service 

plug-ins. The first plug-in in the chain is the subscriber’s (PTSP) plug-in. 

2. The subscriber’s plug-in matches the flow to its subscriber by searching its 

database. It sets the subscriber-id in the session metadata. 

3. The subscriber plug-in checks for the corresponding subscriber profile and which 

services are enabled. It then sets the services mask of enabled and disabled 

services in the session metadata. 

4. MP-SDK or JSF invokes only the services that are enabled per the services mask. 

The other services are skipped, even if configured in the service set. 

NOTE: Subscriber-profile changes affect only the upcoming flows. 

Existing flows remain unaffected. 

[Services Interfaces (Junos OS Release 12.1)] 

• NAT with deterministic port block allocation—You can configure NAT algorithm-based 

allocation of blocks of destination ports. By specifying this method, you ensure that 

an IP address and port are always mapped to the same IP address in a pool and the 

same block of ports, thus eliminating the need for the logging of address translations. 

Other benefits include: 

• Configuration of source IP address prefix matching in the from clause of a NAT rule 

provides a high degree of scalability. 

• All Junos OS-supported ALGs are supported. 

To configure deterministic port block allocation, include the 

deterministic-port-block-allocation block-size block-size statement at the [edit services 

nat pool pool-name port] hierarchy level and include the translation-type 

deterministic-napt44 statement at the [edit services nat rule rule-name term term-name 

then translated] hierarchy level. 

You can use the following new commands to display information: 

• show services nat deterministic-nat nat-port-block internal-host ip-address 

• show services nat deterministic-nat internal-host nat-address ip-address nat-port 

port-number 

116 



[Next-Generation Network Addressing Solutions] 

Subscriber Access Management 

• Junos OS subscriber management scaling values (M120, M320, and MX Series 

routers)—A spreadsheet is available online that lists scaling values supported for Junos 

OS subscriber management beginning with Junos OS Release 10.1. Access the Subscriber 

Management Scaling Values (XLS) spreadsheet from the Downloads box at 

http://www.juniper.net/techpubs/en_US/junosrelease-number/information-products 

/pathway-pages/subscriber-access/index.html. Substitute the number of the latest 

Junos OS release for the release-number. For example, ...en_us/junos11.1/.... 

[Subscriber Management Scaling] 

• Junos OS subscriber management scaling values (MX5, MX10, MX40, and MX80 

routers)—This release of Junos OS includes limited support for subscriber management 

on the MX5, MX10, MX40,and MX80 3D Universal Edge routers. For more information 

about this support, see http://www.juniper.net/techpubs/en_US/release-independent/ 

junos/topics/reference/general/mx80-features.html. 

• Configuring retransmission of L2TP control messages (MX Series 3D Universal Edge 

Routers)—L2TP peers maintain a queue of control messages that must be sent to the 

peer device. After a message is sent, the local peer waits for a response from the remote 

peer. If a response is not received, the local peer retransmits the message. You can 

configure how many times an unacknowledged message is retransmitted by the LAC 

or the LNS. For tunnels that have been established, include the 

retransmission-count-established statement at the [edit services l2tp tunnel] hierarchy 

level. For tunnels that are not yet established, include the 

retransmission-count-not-established statement. 

You can specify a maximum count in the range 0 through 30. The default count for 

established tunnels is 7; for tunnels that are not established, the default is 5. The local 

peer waits 1 second for the first response to a control message. The retransmit timer 

then doubles the interval between each successive retransmission, up to a maximum 

interval of 16 seconds. This behavior allows the remote peer more time to respond. If 

the maximum retransmission count is reached and no response has been received, the 

tunnel and all its sessions are cleared. 

BEST PRACTICE: Before you downgrade to a Junos OS release that does 

not support these statements, we recommend that you explicitly 

unconfigure the feature by including the no retransmission-count-established 

statement and the no retransmission-count-non-established statement at 

the [edit services l2tp tunnel] hierarchy level. 

BEST PRACTICE: During a unified in-service software upgrade (ISSU) on 

an MX Series router configured as the LAC, the LAC might not respond to 

control messages from the LNS. This can result in dropping LAC L2TP 

sessions. You can avoid this situation by ensuring that the maximum 

retransmission count on the LNS is set to 16 or higher. 


117


[Subscriber Access] 

• Configuring the idle timeout for L2TP tunnels without sessions (MX Series 3D 

Universal Edge Routers)—You can configure the LAC or the LNS to specify how long 

a tunnel without any sessions remains active. The idle timer starts when the last session 

on the tunnel is terminated. When the timer expires the tunnel is disconnected. This 

idle timeout frees up resources otherwise consumed by inactive tunnels. 

To configure how long the tunnel remains active, include the idle-timeout statement 

at the [edit services l2tp tunnel] hierarchy level. You can set the timer in the range 0 

through 86,400 seconds; the default value is 80 seconds. If you set the idle-timeout 

value to 0, the tunnel is forced to remain active indefinitely after the last session is 

terminated until one of the following occurs: 

• You issue the clear services l2tp tunnel command. 

• The remote peer disconnects the tunnel. 


not support this statement, we recommend that you explicitly unconfigure 

the feature by including the no idle-timeout statement at the [edit services 

l2tp tunnel] hierarchy level. 


• Configuring how long L2TP maintains dynamic information (MX Series 3D Universal 

Edge Routers)—You can configure the LAC or the LNS to specify how long the router 

attempts to maintain dynamic destinations, tunnels, and sessions after they have been 

torn down. This destruct timeout aids debugging and other analysis by saving underlying 

memory structures of those destinations, tunnels, or sessions. Any specific dynamic 

destination, tunnel, or session might not be maintained for this entire time period if the 

resources must be reclaimed early to allow new tunnels to be established. To set the 

destruct timeout, include the destruct-timeout statement at the [edit services l2tp] 

hierarchy level. You can set the timer in the range 10 through 3600 seconds; the default 

value is 300 seconds. 


not support this statement, we recommend that you explicitly unconfigure 

the feature by including the no destruct-timeout statement at the [edit 

services l2tp] hierarchy level. 


• Configuring connection speeds on the LAC (MX Series 3D Universal Edge 

Routers)—You can configure the resource used by the LAC to determine the setting 

for the speed of the connection from the LAC to the LNS (transmit speed) and of the 

connection from the LNS to the LAC (receive speed). The LAC sends the speeds to the 

LNS in Incoming-Call-Connected (ICCN) messages; the transmit speed is conveyed 

by AVP 24 and the receive speed by AVP 38. 

118 



To use the recommended downstream traffic shaping rate for AVP 24 and the 

recommended upstream shaping rate for AVP 38, include the tx-connect-speed-method 

advisory statement at the [edit services l2tp] hierarchy level. You configure the advisory 

rates under the PPPoE logical interface underlying the subscriber interface with the 

advisory-options statement at the [edit interfaces interface-name unit 

logical-unit-number] hierarchy level. If the advisory speed is not configured on the 

underlying interface, then the tx-connect-speed-method advisory statement 

automatically sets the speed to 1 Gbps and sends this value in both AVP 24 and AVP 

38. 

Alternatively, to derive the speeds from the PPPoE IA tags, use the 

tx-connect-speed-method dsl-forum statement. In this case, AVP 24 is the value of 

Actual-Data-Rate-Downstream (VSA 26-129). AVP 38 is the value of 

Actual-Data-Rate-Upstream (26-130), and is sent only when the VSA values differ. 


• Setting the tunnel name format (MX Series 3D Universal Edge Routers)—MX960, 

MX480, and MX240 routers with MPCs now support the configuration of the format 

for L2TP tunnel names. By default, the name of a tunnel corresponds to the 

Tunnel-Assignment-Id [82] returned by the AAA server. You can optionally configure 

the LAC to use more elements in the construction of a tunnel name by including the 

assignment-id-format client-server-id statement at the [edit services l2tp tunnel] 

hierarchy level. This format uses three attributes: Tunnel-Client-Auth-Id [90], 

Tunnel-Server-Endpoint [67], and Tunnel-Assignment-Id [82]. These attributes 

correspond, respectively, to the values configured in the tunnel profile for the LAC 

(source gateway) name, the tunnel endpoint (remote gateway) address on the LNS, 

and the tunnel ID. 

A consequence of the client-server-id format is that the LAC automatically creates a 

new tunnel when the AAA server returns a different Tunnel-Client-Auth-Id than 

previously returned. Before you downgrade to a Junos OS release that does not support 

this statement, we recommend that you explicitly unconfigure the feature by including 

the no assignment-id-format assignment-id statement at the [edit services l2tp tunnel] 



• Support for hierarchical policer as filter action (MX Series routers)—This feature 

enables you to have hierarchical policers as one type of filter action. Hierarchical policers 

rate-limit premium traffic separately from the aggregate traffic on an interface as 

determined by different configured rates. This feature is useful in provider edge 

applications using aggregate policing for general traffic and to apply a separate policer 

for premium traffic on a logical or physical interface. To enable all hierarchical policers 

of the same name in one filter to share the same policer instance in the Packet 

Forwarding Engine, use the filter-specific statement at the [edit firewall] hierarchy 

level. 


• Unified ISSU support for subscriber management PPPoE access model (M120, M320, 

and MX Series routers)—Extends support for the unified in-service software upgrade 

(unified ISSU) feature to the PPPoE access model used by subscriber management. 


119


This support ensures that the router preserves all active PPPoE subscriber sessions 

and session services after completion of a unified ISSU. 

Unified ISSU for static and dynamic PPPoE access in subscriber management supports 

the following features: 

• Terminated, non-tunneled PPPoE connections configured with static or dynamic 

PPP logical interfaces and static or dynamic PPPoE underlying interfaces 

• Subscriber services on single-link PPP interfaces 

• Preservation of statistics for accounting, filter, and class of service (CoS) on MPC/MIC 

interfaces 

NOTE: Accounting statistics are not preserved after a unified ISSU on 

M120 and M320 routers with Enhanced Intelligent Queuing 2 (IQ2E) PICs. 

Unified ISSU for static and dynamic PPPoE access in subscriber management does 

not support Multilink Point-to-Point Protocol (MLPPP) bundle interfaces. (MLPPP 

bundle interfaces require the use of an Adaptive Services PIC or Multiservices PIC to 

provide PPP subscriber services. These PICs do not support unified ISSU.) 

You use the existing CLI statements and procedure to configure and initiate unified 

ISSU for subscriber management. To display information about the state of unified 

ISSU for subscriber management features, you can use the existing show system 

subscriber-management summary operational command. 

[Subscriber Access, High Availability] 

• PPPoE encapsulation type lockout support (M120, M320, and MX Series 

routers)—Enables you to configure the router to prevent (lock out) a failed or short-lived 

PPPoE subscriber session from reconnecting for a temporary period of time known as 

the lockout period. The lockout period is derived from a formula and increases 

exponentially based on the number of successive reconnection failures. 

Configuring PPPoE encapsulation type lockout protects the router and any external 

authentication, authorization, and accounting (AAA) servers, such as RADIUS or 

Diameter, from excessive loading as a result of failed or short-lived PPPoE subscriber 

sessions that occur repeatedly for the same subscriber. Subscriber sessions are 

identified by their unique media access control (MAC) source address. 

When you configure PPPoE encapsulation type lockout, the router detects a short-lived 

(also referred to as a short-cycle) subscriber session, determines the time between 

repeated short-cycle events, and applies a time penalty for each short-cycle event 

based on a default or configured lockout period. This action temporarily locks out the 

specified PPPoE subscriber by preventing connection to the router. When the lockout 

period expires, negotiation of the PPPoE subscriber session and associated MAC source 

address resumes. 

120 



Configuration of PPPoE encapsulation type lockout is supported on Intelligent Queuing 

2 (IQ2) PICs on M120 and M320 routers, and on MPC/MIC interfaces on MX Series 

routers. You can configure PPPoE encapsulation type lockout for all of the following 

static and dynamic PPPoE underlying interface types: 

• Static VLAN logical interface 

• Static VLAN demultiplexing (demux) logical interface 

• Dynamic VLAN logical interface 

• Dynamic VLAN demultiplexing (demux) logical interface 

PPPoE encapsulation type lockout is disabled by default. To configure PPPoE 

encapsulation type lockout and an optional lockout period, in seconds, you must include 

the new short-cycle-protection statement at any of the following hierarchy levels: 

• [edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number family 

pppoe] 

• [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number 

family pppoe] 


pppoe-underlying-options] 

• [edit interfaces demux0 unit logical-unit-number family pppoe] 

• [edit interfaces interface-name unit logical-unit-number family pppoe] 

• [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options] 

• [edit logical-systems logical-system-name interfaces interface-name unit 

logical-unit-number family pppoe] 


logical-unit-number pppoe-underlying-options] 

If you include the short-cycle-protection statement without specifying the lockout 

period, the router uses the default lockout period of 1 through 300 seconds (5 minutes). 

To display information about the PPPoE encapsulation type lockout configuration on 

the PPPoE underlying interface, use the show pppoe lockout operational command, 

new in Junos OS Release 11.4, or the show pppoe underlying-interfaces operational 

command, enhanced in Junos OS Release 11.4. You can also use the new clear pppoe 

lockout operational command to clear the lockout condition for a specific MAC source 

address on a specific underlying interface, for all MAC source addresses on a specific 

underlying interface, or for all MAC source addresses on all underlying interfaces. 

[Subscriber Access, Interfaces Command Reference, Ethernet Interfaces] 

• Expression support for dynamic profiles (MX Series routers)—Junos OS Release 11.4 

supports the use of expressions for dynamic profile variables. Expressions are groups 

of arithmetic operators, string operators, and operands that you can create for use as 

variables within dynamic profiles. 


121


To configure expressions, include the expression operators and operands at the [edit 

dynamic-profiles profile-name variables] hierarchy level. 

Table 4 on page 122 lists supported operators and functions you can use to create 

expressions. 

NOTE: Precedence 1 is the lowest level. 

Table 4: Operators and Functions 

Operation 

Operator 

Associativity 

Precedence 

Action 

Arithmetic 

Addition 

+ 

Left 

1 

Adds the elements to the right and left of the 

operator together. 

Arithmetic 

Subtraction 

- 

Left 

1 

Subtracts the element to the right of the 

operator from the element to the left of the 

operator. 

Arithmetic 

Multiplication 

* 

Left 

2 

Multiplies the element to the left of the operator 

by the element to the right of the operator. 

Arithmetic 

Division 

/ 

Left 

2 

Divides the element to the left of the operator 

by the element to the right of the operator. 

Arithmetic 

Modulo 

% 

Left 

2 

Divides the element to the left of the operator 

by the element to the right of the operator and 

returns the integer remainder. If the element to 

the left of the operator is less than the element 

to the right of the operator, the result is the 

element to the left of the operator. 

Concatenation 

## 

Left 

3 

Creates a new string by joining the string values 

to the left of the operator and the values to the 

right of the operator together. 

Maximum 

max(param1,param2) 

Left 

4 

Takes the maximum of the two values passed 

as parameters. 

Minimum 

min(param1,param2) 

Left 

4 

Takes the minimum of the two values passed 

as parameters. 

Round 

round(param1) 

- 

4 

Rounds the value to the nearest integer. 

Truncate 

trunc(param1) 

- 

4 

Truncates a non-integer value to the value left 

of the decimal point. 

Convert to String 

toStr(param1) 

- 

4 

Converts the variable inside the parentheses to 

a null terminated string. 

Convert to Integer 

toInt(param1) 

- 

4 

Converts the parameter to an integer. A single 

string or variable is allowed as a parameter. 

122 



Table 4: Operators and Functions (continued) 

Operation 

Operator 

Associativity 

Precedence 

Action 

Random 

rand() 

- 

4 

Generates a random numerical value. 

Parentheses 

( ) 

- 

5 

Groups operands and operators to achieve 

results different from simple precedence; 

effectively has the highest precedence. 


• L2TP LAC support for unified ISSU (MX Series 3D Universal Edge Routers)—Unified 

ISSU for tunneled PPP clients over PPPoE is now fully supported on L2TP LACs on MX 

Series routers. When a unified ISSU is initiated, the LAC completes any L2TP 

negotiations that are in progress but rejects any new negotiations until the upgrade 

has completed. No new tunnels or sessions are established during the upgrade. 

Subscriber logouts are recorded during the upgrade and are completed after the 

upgrade has completed. 

L2TP LNS on MX Series routers supports only unified ISSU challenged behavior. The 

upgrade is gracefully rejected and does not proceed when any LNS destination exists, 

regardless of whether tunnels or sessions have been established. 

Unified ISSU is not supported by L2TP on M Series routers. 

[Subscriber Access, High Availability] 

• DHCPv6 support (MX Series routers)—Subscriber management now supports DHCPv6 

relay. DHCPv6 relay passes messages between a DHCPv6 client and a DHCPv6 server, 

and provides the type of support within an IPv6 network that the previously supported 

DHCP relay provides in an IPv4 network. DHCPv6 relay interacts with the AAA service 

framework to manage subscriber access and accounting. This interaction enables the 

relay to use an external authority, such as RADIUS, to provide IPv6 prefixes, client 

authentication, and configuration options. 

To configure DHCPv6 relay, you use the dhcpv6 statement at the [edit 

forwarding-options dhcp-relay] hierarchy level. Subscriber management also supports 

new operational commands that you can use to query the system and display 

information about DHCPv6 relay bindings and statistics. 

Table 5 on page 123 lists the DHCPv6 relay statements and operational commands 

that are introduced at the indicated hierarchy levels in Junos OS Release 11.4. 

Table 5: DHCPv6 Relay Support for New Statements and Operational 

Commands 

Statement or Command 

Supported Hierarchy Level 

dhcpv6 

[edit forwarding-options dhcp-relay] 

relay-agent-interface-id 

[edit forwarding-options dhcp-relay dhcpv6] 


123


Table 5: DHCPv6 Relay Support for New Statements and Operational 

Commands (continued) 

Statement or Command 


• relay-agent-interface-id 

• relay-agent-remote-id 

• relay-agent-subscriber-id 

[edit forwarding-options dhcp-relay dhcpv6 authentication 

username-include] 

and 

[edit forwarding-options dhcp-relay dhcpv6 group group-name 

authentication username-include] 

• clear dhcpv6 relay binding 

• clear dhcpv6 relay statistics 

CLI operational mode 

• show dhcpv6 relay binding 

• show dhcpv6 relay statistics 

Table 6 on page 124 lists the existing statements that are now supported for DHCPv6 

relay at the indicated hierarchy levels. 

Table 6: DHCPv6 Relay Support for Existing Statements 

Statement 


• active-server-group 

• authentication 

[edit forwarding-options dhcp-relay dhcpv6] 

• dynamic-profile 

• group 

• overrides 

• server-group 

• password 

• username-include 

[edit forwarding-options dhcp-relay dhcpv6 authentication] 

and 


authentication] 

• circuit-type 

• delimiter 

• domain-name 

• logical-system-name 

• routing-instance-name 

• user-prefix 

• aggregate-clients 

• use-primary 

[edit forwarding-options dhcp-relay dhcpv6 authentication 

username-include] 

and 


authentication username-include] 

[edit forwarding-options dhcp-relay dhcpv6 dynamic-profile] 

and 


dynamic-profile] 

124 



Table 6: DHCPv6 Relay Support for Existing Statements (continued) 

Statement 


• overrides 

[edit forwarding-options dhcp-relay dhcpv6], 

[edit forwarding-options dhcp-relay dhcpv6 group group-name], 

and 


interface interface-name] 

• prefix 

• use-interface-description 

[edit forwarding-options dhcp-relay dhcpv6 

relay-agent-interface-id] 

and 


relay-agent-interface-id] 

• interface-client-limit 

• no-bind-on-request 

• send-release-on-delete 

[edit forwarding-options dhcp-relay dhcpv6 overrides], 


overrides], 

and 


interface interface-name overrides] 

interface 

[edit forwarding-options dhcp-relay dhcpv6 group group-name] 

trace 


interface interface-name] 


• Support for hierarchical CoS on interface sets of aggregated Ethernet interfaces 

(MX Series routers)—Enables you to apply hierarchical CoS to demux and PPPoE 

subscribers configured in interface sets of aggregated Ethernet interfaces. This feature 

is supported on MPC/MIC modules on MX Series routers. You must apply static CoS 

parameters to interface sets. 

You can configure the aggregated Ethernet interface with or without link protection. 

In addition, you can set the distribution model of the logical interfaces within the 

interface set to hash-based distribution or targeted distribution. 

The link membership list and scheduler mode of the interface set is inherited from the 

underlying aggregated Ethernet interface over which the interface set is configured. 

When an aggregated Ethernet interface operates in link protection mode, or if the 

scheduler mode is set to member-link-scheduler replicate, the scheduling parameters 

of the interface set are copied to each of the member links. If the scheduler mode of 

the aggregated Ethernet interface is set to member-link-scheduler scale, the scheduling 

parameters are scaled based on the number of active member links and applied to 

each of the aggregated interface member links. 


125


To create an interface set, include the interface-set interface-set-name statement at 

the [edit interfaces] hierarchy level or the [edit dynamic-profiles profile-name interfaces] 

hierarchy level. You can add demux or PPPoE interfaces to the set by including the 

interface interface-name unit logical-unit-number statement at the [edit interfaces 

interface-set interface-set-name] or the [edit dynamic-profiles profile-name interfaces 

interface-set interface-set-name] hierarchy level. 

To apply scheduling and queuing parameters to the interface set, include the 

output-traffic-control-profile profile-name statement at the [edit class-of-service 

interfaces interface-set interface-set-name] hierarchy level. 


• Support for dynamic profile versions (MX Series routers)—Junos OS Release 11.4 

provides the ability to create new versions of dynamic profiles that are currently in use 

by subscribers. Any subscriber that logs in following a dynamic profile modification 

uses the latest version of the dynamic profile. Subscribers that are already active 

continue to use the older version of the dynamic profile until they log out or their session 

terminates. 

To enable the configuration of dynamic profile versions, include the versioning statement 

at the [edit system dynamic-profile-options] hierarchy level. 

When creating versions of dynamic profiles, keep the following in mind: 

• You can enable or disable dynamic profile versioning regardless of whether dynamic 

profiles are configured or not. 

• Each version of a dynamic profile is stored in the profile database as a new profile. 

• The name of the new profile version is derived by appending a four-character tag 

string to the original base dynamic profile name. This tag string contains two dollar 

sign ($) characters to identify the version field of the profile name. These two 

characters are followed by two numerical characters that represent the version 

number of the dynamic profile (for example, 01). 

• The dynamic profile that you modify is always stored as the latest version. You cannot 

create a modified dynamic profile and save it as an earlier version. For example, if 

you modify version three of a dynamic profile, it is saved as version four. 

• You can modify only the latest version of a dynamic profile. 

• If the dynamic profile version that you modify is not in use by any subscriber, the 

profile is overwritten with committed changes without creating a new version. 

• You can create a maximum of 10 versions of each dynamic profile. 

• If all 10 versions of a dynamic profile already exist, any modification to the dynamic 

profile results in modifying the latest version of that profile (that is, version $$10). If 

this version is in use, any modification attempt fails upon commit. 

• You can delete a dynamic profile only when it is not in use. 

• The dynamic profile version feature supports graceful restart and unified ISSU. 

126 



The show subscriber command has been enhanced to display the dynamic profile 

name and current version (when appropriate) in the Dynamic Profile Name field for 

each subscriber. 


• Subscriber secure policy support for IPv6 traffic (MX Series routers)—Subscriber 

secure policy now mirrors IPv6 traffic as well as IPv4 traffic. IPv6 mirroring uses the 

existing statements and configuration procedures and requires no additional steps. 

As in the case of IPv4 mirroring, the IPv6 traffic is encapsulated in a UDP packet and 

sent to the mediation device. IPv6 mirroring can be based on information provided by 

either RADIUS or Dynamic Tasking Control Protocol (DTCP). 


• Duplicate RADIUS accounting reports (MX Series routers)—By default, subscriber 

management sends RADIUS accounting reports to the accounting servers in the context 

in which the subscriber was last authenticated. However, in a Layer 3 wholesale network 

solution, the wholesaler and retailer might use different RADIUS accounting servers, 

and both might want to receive the accounting reports. You can now configure duplicate 

account reporting, and specify that subscriber management send the same RADIUS 

accounting report to both the wholesaler and the retailer accounting servers. 

To configure duplicate RADIUS accounting, you include the duplication statement at 

the [edit access profile profile-name accounting] hierarchy level. 


• Centrally configured per-subscriber DHCP options (VSA 26-55) (MX Series 

routers)—Subscriber management enables you to centrally configure DHCP options 

on a RADIUS server and distribute the options on a per-subscriber basis. You use Juniper 

Networks VSA 26-55 to include the DHCP options information in the Access-Accept 

message sent from the RADIUS server to the RADIUS client, and on to DHCP local 

server for return to the DHCP subscriber. 

The centrally configured DHCP options feature is supported for DHCP local server. 

DHCP local server provides a passthrough operation, performing minimal processing 

and error checking of the DHCP options string that the RADIUS server sends in VSA 

26-55. The new feature does not affect the previously supported functionality, in which 

VSA 26-55 is configured by DHCP local server or DHCP relay agent. Subscriber 

management supports the previous and new functionality for both DHCPv4 and 

DHCPv6. 


• Support for concurrent IPoE DHCP and PPPoE logical interfaces on the same VLAN 

(MX Series routers with MPC/MIC interfaces)—Junos OS Release 11.4 supports the 

configuration of VLAN interfaces with multiple protocol interface stacks at the same 

time. This means that you can now configure both IPoE DHCP logical interfaces and 

PPPoE logical interfaces concurrently over the same VLAN interface. 

Configuring PPPoE concurrently with IPoE DHCP on the same VLAN interface requires 

that you use the family pppoe statement at the [edit interfaces interface-name unit 

logical-unit-number], [edit logical-systems logical-system-name interfaces interface-name 

unit logical-unit-number], [edit dynamic-profiles profile-name interfaces demux0 unit 


127


logical-unit-number], or [edit dynamic-profiles profile-name interfaces interface-name 

unit logical-unit-number] hierarchy level. This statement is supported only on MX Series 

routers with MPCs. However, all features specific to DHCP and PPPoE interfaces are 

supported with concurrent configuration on this platform. 


• Support for processing DHCP information request messages (M120 and M320 

Multiservice Edge Routers, MX Series 3D Universal Edge Routers)—By default, DHCP 

local server and DHCPv6 local server ignore any DHCP information request messages 

that they receive. You can now override this default behavior to enable processing of 

these messages. Include the process-inform statement at any of the [edit ... system 

services dhcp-local-server ... overrides] or [edit ... system services dhcp-local-server 

dhcpv6 ... overrides] hierarchy levels. Overriding the default behavior is appropriate 

when the servers have DHCP clients with externally provided addresses; these clients 

might send DHCP information request messages to the server to request further 

configuration information from the server. 

By default, DHCP relay and DHCP relay proxy now automatically forward DHCP 

information request messages without modification as long as the messages are 

received on an interface configured for a DHCP server group. DHCP relay drops 

information request messages that it receives on any other interfaces. You cannot 

disable this default DHCP relay and relay proxy behavior. 

The information requested by these clients has typically been configured with the 

dhcp-attributes statement for an address pool defined by the address-assignment pool 

pool-name statement at the [edit access] hierarchy level. 

When you enable processing of DHCP information request messages, include the pool 

pool-name statement at the [edit system services dhcp-local-server overrides 

process-inform] or [edit system services dhcp-local-server dhcpv6 overrides 

process-inform] hierarchy level to optionally specify a pool name from which the local 

server retrieves the requested configuration information for the client. If you do not 

specify a local pool, then the local server requests that AAA select and return only the 

name of the relevant pool. 

When DHCPv6 is configured over PPP interfaces, the PPP RADIUS authentication data 

can be used to select the pool from which the response information is taken. 

Additionally, other RADIUS attributes can also be inserted into the DHCPv6 reply 

message. If an overlap exists between RADIUS attributes and local pool attributes, 

the RADIUS values are used instead of the local configuration data. If no RADIUS 

information is received from the underlying PPP interface, then the behavior is the 

same as described above for non-PPP interfaces. 

DHCP local server responds to the client with a DHCP ack message that includes the 

requested information—if it is available. DHCPv6 local server responds in the same 

manner but uses a DHCP reply message. No subscriber management is applied as a 

result of the DHCP inform message. 


• Support for VLAN ID as a selector for IP demux interfaces (MX Series routers)—Junos 

OS Release 11.4 supports the configuration of IP demux interfaces using VLAN IDs as 

128 



the selector. You can now configure dynamic IP demux interfaces over either static or 

dynamic VLAN demux interfaces. This feature provides the following support: 

• Only single and dual VLAN tag options are supported as VLAN selectors. 

• Both inet and inet6 families are supported. 

• All firewall and CoS features are supported. 

• Both static and dynamic demux interface creation is supported, including autosense 

VLAN creation. 

• Both DPC and MPC modules are supported. 

For details about how to configure dynamic IP demux interfaces over static or dynamic 

VLAN demux interfaces, see the Junos OS Special Document for Release 11.4 M Series, 

MX Series, and T Series Routers and the Junos OS Subscriber Access Configuration Guide. 


• Support for session and idle timeouts for L2TP tunneled subscriber sessions (MX 

Series 3D Universal Edge Routers)—You can now manage the length of L2TP tunneled 

subscriber sessions by including the client-idle-timeout statement, the 

client-session-timeout statement, or both, at the [edit access profile profile-name 

session-options] hierarchy level. This functionality was previously supported only for 

PPP-terminated subscriber sessions. 

The session timeout defines how long the subscriber session is allowed to be up before 

it is terminated, regardless of user activity. The idle timeout monitors the session for 

upstream and downstream traffic, and terminates the session when there has been 

no traffic for the specified period. These timeouts apply on a per-routing-instance 

basis. 

You can also configure these limits on a per-subscriber basis with RADIUS attributes 

Session-Timeout [27] and Idle-Timeout [28]. The RADIUS attributes returned for a 

particular subscriber override any value set by the access profile applied when the user 

logs in. 

Issue the show subscribers detail command to display the session and idle timeouts 

applied to the subscribers’ sessions. 


• Testing L2TP tunnel configurations on an L2TP LAC (MX Series 3D Universal Edge 

Routers)—You can now test L2TP tunnel configurations on an MX Series router 

configured as an L2TP LAC. In earlier releases, you had to bring up a tunneled PPP 

subscriber to test configurations. Now you can issue the test services l2tp tunnel 

command from CLI operation mode to map a subscriber to an L2TP tunnel, verify the 

L2TP tunnel configuration (both locally on the LAC and on a back-end server such as 

a RADIUS server), and verify that L2TP tunnels from the LAC can be established with 

the remote LNS. 

The Junos OS LAC implementation enables you to configure multiple tunnels from 

which one tunnel is chosen for tunneling a PPP subscriber. You can use the test services 

l2tp tunnel command to test all possible tunnel configurations to verify that each can 

be established. Alternatively, you can test only a specific tunnel for the subscriber. 


129


You must specify a configured subscriber username when you issue the command. 

The test generates a dummy password for the subscriber, or you can optionally specify 

the password. The test verifies whether the subscriber identified by that username can 

be tunneled according to the tunnel configuration. If the subscriber can be tunneled, 

then the test verifies whether the L2TP tunnel can be established with the LNS according 

to the L2TP configuration. 

You can optionally specify a tunnel ID, in which case only that tunnel is tested; the 

tunnel must be already configured for that username. If you omit this option, the test 

is applied to the full set of tunnel configurations that are returned for the username. 

The tunnel ID you specify is the same as that used by Tunnel-Assignment-Id (RADIUS 

attribute 82) and specified by the identification statement in the tunnel profile. 

[Subscriber Access, System Basics and Services Command Reference] 

• Parameterized filters and policers (MX Series routers)—This feature adds the ability 

to configure firewall filters and policers under a dynamic profile. The filter and policer 

definition can now utilize dynamic-profile variables, which allows you to customize 

your configuration at session creation time. You can configure a general filter or policer 

under a dynamic profile and then provide policing rates, destination addresses, ports, 

and so forth when a dynamic session is activated. To support this feature, the 

service-filter-hit-except match condition has been added to the [edit firewall] hierarchy 

level. In addition, the [edit dynamic-profile profile-name] hierarchy level is now supported 

for the [edit firewall] hierarchy. 

[Subscriber Access, Policy Framework] 

• DTCP trigger attributes and SNMP objects for subscriber secure policy traffic 

mirroring (MX Series routers)—A subscriber secure policy traffic mirroring session 

starts when the router, functioning as the intercept access point, receives a DTCP ADD 

message that contains a trigger attribute. In earlier releases, DTCP used the Interface 

ID attribute to trigger traffic mirroring. Junos OS Release 11.4 introduces support for 

additional DTCP attributes that trigger DTCP-initiated subscriber secure policy traffic 

mirroring. 

Junos OS Release 11.4 also provides additional SNMP trap support for subscriber secure 

policy, including SNMP objects to identify the subscriber and to track traffic statistics. 

Table 7 on page 130 shows the DTCP trigger attributes, including the previously supported 

Interface ID attribute. The attributes are listed in order of preference, from high to low. 

If an ADD message contains multiple trigger attributes, the subscriber secure policy 

uses the attribute with the highest preference and initiates the traffic mirroring 

associated with that trigger attribute. 

Table 7: DTCP Trigger Attributes 

Attribute 

Name 

DTCP Message 

Semantic 

Description of Mirroring Trigger 

Accounting 

Session ID 

X-Act-Sess-Id 

The text string of the accounting session ID 

associated with the subscriber. 

Calling Station 

ID 

X-Call-Sta-Id 

The text string of the calling station ID associated 

with the subscriber. 

130 



Table 7: DTCP Trigger Attributes (continued) 

Attribute 

Name 

DTCP Message 

Semantic 

Description of Mirroring Trigger 

IP Address 

X-IP-Addr-Unit 

X-Logical-System 

(optional) 

X-Routing-Instance 

(optional) 

The IPV4 address associated with the interface for 

the subscriber. 

You can optionally include the X-Logical-System 

and X-Routing-Instance attributes with this attribute. 

If neither is specified, the default logical system and 

routing instance are used. 

Interface ID 

X-Interface-Id 

The interface description string on which traffic 

mirroring is performed (for example, ge-0/0/0.1 or 

demux0.107472834). 

NAS Port ID 

X-NAS-Port-Id 

The text string of the NAS port ID associated with 


DHCP Option 

82 

X-RM-Circuit-Id 

X-RM-Agent-Id 

The combination of the remote circuit ID and the 

remote agent ID attributes, which specifies the DHCP 

Option 82 associated with the session. 

Remote Agent 

ID 

X-RM-Agent-Id 

The text string of Agent Remote ID suboption for 


User Name 

X-UserName 

X-Logical-System 

(optional) 

X-Routing-Instance 

(optional) 

• Can be a trigger when used by itself. 

• Can be used together with the Remote Circuit ID 

attribute to specify the DHCP Option 82 trigger. 

The user name for this subscriber. 

You can optionally include the X-Logical-System 

and X-Routing-Instance attributes with this attribute. 

If neither is specified, the default logical system and 

routing instance are used. 

Table 8: SNMP Trap Definitions 

Table 8 on page 131 shows the new subscriber secure policy SNMP objects and the trap 

definitions for Junos OS Release 11.4. 

New SNMP Object 

Description 

SNMP Trap Definition 

jnxJsPacketMirrorCallingStationIdentifier 

Calling station ID of subscriber 

whose traffic is being monitored. 

jnxJsPacketMirrorLiSubscriberLoggedIn 

jnxJsPacketMirrorLiSubscriberServiceActivated 

jnxJsPacketMirrorLiSubscriberLogInFailed 

jnxJsPacketMirrorLiSubscriberServiceActivationFailed 

jnxJsPacketMirrorNasIdentifier 

NAS ID of the router on which the 

traffic is being monitored. 




131


Table 8: SNMP Trap Definitions (continued) 


Description 


jnxJsPacketMirrorOctetsReceived 

Number of octets of combined 

IPv4 and IPv6 subscriber traffic 

received. 

jnxJsPacketMirrorLiSubscriberLoggedOut 

jnxJsPacketMirrorOctetsTransmitted 

Number of octets of combined 

IPv4 and IPv6 subscriber traffic 

transmitted. 



• Service accounting with JSRC (M120 and M320 Multiservice Edge Routers, MX Series 

3D Universal Edge Routers)—When JSRC provisions subscriber services, you can now 

also use JSRC to report accounting data for those services. You can choose service 

activation/deactivation accounting to report cumulative service session statistics when 

a service is terminated, or interim accounting to report service session statistics at 

specified intervals for the duration of the session. 

When the SAE sends the Juniper-Policy-Install AVP (AVP code 2020) to specify a 

service for JSRC to activate, JSRC initiates service activation/deactivation accounting 

if that AVP also includes the Juniper-Acct-Collect AVP (AVP code 2054). 

JSRC initiates interim accounting when the Juniper-Policy-Install AVP includes the 

Acct-Interim-Interval AVP (AVP code 85). In this case, JSRC updates the accounting 

values at the interval specified in the AVP— in the range 600 through 86,400 seconds. 

JSRC and the SAE exchange Diameter Accounting-Request (ACR) and 

Accounting-Answer (ACA) messages to communicate accounting data. Both messages 

include the Juniper-Acct-Record AVP (AVP code 2053) to identify and confirm the 

service for which accounting information is requested. 

JSRC can provide an accounting only of volume statistics. You must employ either 

classic firewall filters or fast update firewall filters to collect the accounting data. To 

specify JSRC accounting, include the accounting-order activation-protocol statement 

at the [edit access profile] hierarchy level; this is the same access profile that configures 

JSRC service provisioning. Alternatively, you can configure the accounting reports to 

be sent by RADIUS by including instead the accounting-order radius statement at the 

[edit access profile] hierarchy level. 


• Support for controlling the rate of flow of RADIUS messages (M120, M320, MX Series 

routers)—Junos OS Release 11.4 supports limiting the flow of RADIUS requests between 

the router and configured RADIUS servers. To specify the number of RADIUS requests 

per second that the router can send, collectively, to all configured RADIUS servers, 

include the request-rate configuration statement at the [access profile profile-name 

radius options] hierarchy level. By default, the router can send up to 500 requests per 

second to the RADIUS servers. You can specify a value from 500 through 4000 requests 

per second. 

132 



Junos OS Release 11.4 also enables you to limit the maximum number of outstanding 

requests from the router to a RADIUS server. To specify the maximum number of 

outstanding requests from the router to a RADIUS server, include the 

max-outstanding-requests configuration statement at the [access profile profile-name 

radius server] or [profile profile-name radius server] hierarchy level. By default, a 

RADIUS server can have up to 1000 outstanding RADIUS requests. You can specify a 

value from 0 through 2000 outstanding requests. 

To view the current RADIUS settings, as well as the effect of the new settings on 

performance, use the show network-access aaa statistics radius operational mode 

command. 

user@host> show network-access aaa statistics radius 

Outstanding Requests 

RADIUS Server Profile Configured Current Peak Exceeded 

12.1.11.254 pppoe-auth 111 0 1 0 

12.1.12.254 pppoe-auth-2 0 0 0 1 

12.1.13.254 pppoe-auth-3 64 0 10 0 

To clear the RADIUS statistics for the Peak and Exceeded columns, use the clear 

network-access aaa statistics radius operational mode command. 


• Triggering ANCP OAM loopback tests (MX Series 3D Universal Edge Routers)—You 

can trigger ANCP OAM to perform a loopback test on the local loop (between the 

access node and the CPE), which can aid in simple fault isolation. When using an 

ATM-based local loop, the ANCP operation can trigger the access node to generate 

ATM (F4/F5) loopback cells on the local loop. For an Ethernet-based local loop, ANCP 

operation can trigger the access node to generate an Ethernet loopback message on 

the local loop. When the test is completed, the access node sends a message to the 

router with the results. 

To initiate local loop testing, you must identify a particular loop for the test. You can 

issue the request ancp oam neighbor command from CLI operation mode and identify 

the access loop by specifying an ANCP neighbor by IP address or system name; in either 

case you must also specify the access identifier for a subscriber on that access node. 

Alternatively, you can issue the request ancp oam interface command from CLI operation 

mode and identify the loop by specifying an ANCP interface or set of interfaces. With 

either command, you can also specify how many times the test must be run and how 

long the router waits for a response to the OAM request. 


• Mapping ANCP attributes to vendor-specific attributes (MX Series 3D Universal 

Edge Routers)—You can now configure AAA to add the 

Downstream-Calculated-QoS-Rate VSA (IANA 4874, 26-141) and the 

Upstream-Calculated-QoS-Rate VSA (IANA 4874, 26-142) to the RADIUS 

authentication and accounting request messages for subscribers. By default, these 

VSAs are not present in any RADIUS messages. To add the VSAs, include the 

juniper-dsl-attributes statement at the [edit access profile profile-name radius options] 


AAA provides the default recommended transmit and receive speeds in these RADIUS 

messages. The default values are configured with the advisory-options statement at 


133


the [edit protocols ancp interfaces interface-name] hierarchy level. The transmit speed 

is the recommended traffic value in bits per second used for downstream traffic for 

an ANCP interface, and is conveyed in the Downstream-Calculated-QoS-Rate VSA 

(IANA 4874, 26–141). The receive speed is the recommended traffic value in bits per 

second used for upstream traffic for an ANCP interface, and is conveyed in the 

Upstream-Calculated-QoS-Rate VSA (IANA 4874, 26-142). 

In contrast to the Juniper Networks DSL VSAs, the DSL Forum (RFC 4679) VSA is added 

to RADIUS messages by default. You can use the exclude dsl-forum-attributes 

statement at the [edit access profile profile-name radius attributes] hierarchy level to 

prevent the DSL Forum VSA from being included in a specified type of RADIUS message. 

Similarly, you can use the exclude downstream-calculated-qos-rate and the exclude 

upstream-calculated-qos-rate statements to prevent these Juniper Networks VSAs 

from being included in a specified type of RADIUS message. 


• Setting a recommended shaping rate for traffic on ANCP interfaces (MX Series 3D 

Universal Edge Routers)—When the access node sends information about the 

downstream and upstream calculated traffic rates for an interface, those values are 

used to shape the traffic sent to the interface so that it matches the subscriber local 

loop speed. You can now specify recommended values to be used in the event the 

router does not receive this information from the access node. The configured 

recommended values are used as the default values for two Juniper VSAs, 

Downstream-Calculated-QoS-Rate (IANA 4874, 26-141) and 

Upstream-Calculated-QoS-Rate (IANA 4874, 26-142). To set the recommended 

shaping rate, include the advisory-options statement at the [edit protocols ancp 

interfaces interface-name] hierarchy level and specify the downstream (transmit) or 

upstream (receive) traffic rate in bits per second. 


• Improving the accuracy of the data rate reported by ANCP (MX Series 3D Universal 

Edge Routers)—When a DSLAM calculates the data rate on the subscriber local loop, 

it ignores the additional headers on the DSL line that are associated with the overhead 

of the access mode (ATM or Ethernet). However, when ANCP subsequently reports 

the upstream data rate or the downstream data rate, it includes the headers in its 

calculation and therefore reports a slightly higher value than that calculated by the 

DSLAM. This discrepancy causes the CoS shaping rate to be slightly higher than the 

actual rate. 

You can configure an adjustment factor that applies a percentage value to the total 

downstream and upstream data rates reported by ANCP. The adjustment factor applies 

globally for all subscribers of a particular DSL line type. The adjusted data rate results 

in a more accurate CoS shaping rate that is reported to CoS and to AAA whenever AAA 

requests the data rate from ANCP. To configure the adjustment factor, include the 

adjustment-factor statement at the [edit protocols ancp] hierarchy level. 


• HTTP redirect service plugin (MX Series 3D Universal Edge Routers)—This feature 

adds IPv6 support for HTTP redirect. When you use a remote IPv6 HTTP redirect server, 

134 



you can now configure an HTTP service rule to rewrite the IPv6-DA of incoming HTTP 

requests on the service router. This ensures that the requests reach the remote HTTP 

redirect server before being redirected to a captive portal. When you use a local HTTP 

redirect server, you can configure an HTTP service rule to redirect HTTP requests to a 

captive portal within a walled garden. 


• AVP service bundle and definition (MX Series 3D Universal Edge Routers)—This 

feature adds the Juniper-Service-Bundle AVP (AVP code 2004), which is of type 

OctetString, and defines a name of the service bundle. 


• Support for configurable RADIUS account termination reasons—Junos OS Release 

11.4 supports configurable mapping of protocol-specific terminate reasons to the 

RADIUS Acct-Terminate-Cause attribute. 

NOTE: For a list of default termination reasons, see the Junos OS Special 

Document for Release 11.4 M Series, MX Series, and T Series Routers. 

When a AAA, DHCP, L2TP, or PPP session is terminated, protocol-specific terminate 

reasons (if determined) are converted to a specific termination cause, as defined by 

standard RADIUS attribute 49 (Acct-Terminate-Cause). This attribute is included in 

RADIUS Acct-Stop messages and is used to monitor and troubleshoot terminated user 

sessions. 

Terminate reason usage statistics are accumulated on the router. You can use the 

show network-access aaa terminate-code [reverse] [(aaa | dhcp | l2tp | ppp)] [(detail | 

summary | brief)] command to display information about mappings between application 

terminate reasons and RADIUS Acct-Terminate-Cause attributes. You can also use 

the clear network-access aaa statistics terminate-code command to clear all terminate 

mapping statistics. 

Junos OS Release 11.4 also supports the option to customize mappings between a 

terminate reason and a RADIUS Acct-Terminate-Cause attribute, enabling you to 

provide different information about the cause of a termination. To configure customized 

mappings between a terminate reason and a RADIUS Acct-Terminate-Cause attribute, 

include the terminate-code (aaa | dchp | l2tp | ppp) term-reason radius term-cause 

statement at the [edit access] hierarchy level. 


• RADIUS support for limiting maximum number of concurrent PPPoE sessions (M120, 

M320, and MX Series routers)—Enables you to override the PPPoE maximum session 

value (configured with the max-sessions statement) with the PPPoE maximum session 

value returned by the RADIUS server in the Max-Clients-Per-Interface Juniper Networks 

vendor-specific attribute (VSA) [26-143]. This feature is useful if you want to determine 

the PPPoE session limit on a per-subscriber basis. 

The PPPoE maximum session value specifies the maximum number of concurrent 

static or dynamic PPPoE logical interfaces (sessions) that the router can activate on 


135


the PPPoE underlying interface, or the maximum number of active static or dynamic 

PPPoE sessions that the router can establish with a particular service entry in a PPPoE 

service name table. 

In earlier releases, the PPPoE maximum session value was determined on a 

per-interface basis by the number of active PPPoE sessions configured in the CLI with 

the max-sessions statement. In the current release, the PPPoE maximum session value 

is determined on a per-subscriber basis by the maximum session value returned by 

RADIUS in the Max-Clients-Per-Interface VSA [26-143] during the subscriber 

authentication process. The Max-Clients-Per-Interface VSA returns the PPPoE 

maximum session value in Access-Accept messages, but not in Change of Authorization 

Request (CoA-Request) messages. 

The Max-Clients-Per-Interface VSA uses Juniper Networks vendor ID 4874, and is 

defined as follows: 

Attribute 

Number 

Attribute Name 

Description 

Value 

Dynamic CoA 

Support 

26-143 

Max-Clients-Per-Interface 

Maximum allowable client 

sessions per interface. For DHCP 

clients, this value is the 

maximum sessions per logical 

interface. For PPPoE clients, this 

value is the maximum sessions 

(PPPoE interfaces) per PPPoE 

underlying interface. 

integer: 4-octet 

No 

By default, the maximum session value returned by RADIUS in the 

Max-Clients-Per-Interface VSA takes precedence over the configured PPPoE maximum 

session value; no special configuration is required on the router to use this feature. 

To clear (ignore) the value returned by RADIUS in the Max-Clients-Per-Interface VSA 

and restore the PPPoE maximum session value on the underlying interface to the value 

configured in the CLI with the max-sessions statement, you must include the new 

max-sessions-vsa-ignore statement at any of the following hierarchy levels: 

• [edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number family 

pppoe] 


family pppoe] 

• [edit interfaces interface-name unit logical-unit-number family pppoe] 

• [edit interfaces interface-name unit logical-unit-number pppoe-underlying-options] 


logical-unit-number family pppoe] 


logical-unit-number pppoe-underlying-options] 

To display information about the maximum sessions configured on the PPPoE 

underlying interface, use the show pppoe underlying-interfaces operational command. 

136 



[Junos OS Subscriber Access Configuration Guide, Junos OS Interfaces Command Reference, 

Junos OS Ethernet Interfaces Configuration Guide] 

• Inline L2TP LNS support (MX Series 3D Universal Edge Routers)—MX960, MX480, 

and MX240 routers with MPCs now support L2TP LNS functionality in addition to the 

L2TP LAC functionality previously supported. In earlier releases, L2TP LNS support 

was available only on certain M Series Multiservice Edge Routers and required a separate 

services PIC. The new MX Series support means that the MPCs you are already using 

for other applications can now be used to provide inline L2TP LNS services. 

To enable inline services on an MPC, include the inline-services statement at the [edit 

chassis fpc slot-number pic number] hierarchy level. You can configure the amount of 

bandwidth reserved on each Packet Forwarding Engine for tunnel traffic using inline 

services with the bandwidth statement at any of the [edit chassis fpc slot-number pic 

number inline-services] hierarchy levels. 

Inline services require that you configure a service interface—si—at the [edit interfaces] 

hierarchy level, either statically or with a dynamic profile. 

When you configure the properties of the L2TP tunnel on the LNS with the tunnel-group 

statement at the [edit services l2tp] hierarchy level, you can include the new 

aaa-access-profile statement to specify a local access profile that overrides the default 

AAA profile configured for the routing instance where the tunnel is terminated. You 

can also include the tos-reflect statement, which causes the LNS to reflect the IP ToS 

value in the inner IP header to the outer IP header. 

To monitor LNS operations and configuration, you can issue the following existing 

commands on the LNS: show services l2tp summary, show services l2tp destination, 

show services l2tp session, show services l2tp tunnel, and show subscribers. 


• Unique identifiers for firewall variables in dynamic profiles (MX Series 

routers)—Enables the system to generate unique identifiers (UIDs) for parameterized 

filters in dynamic profiles created for services. The generated UIDs enable you to identify 

and configure separate parameter values for filters with the same variable name. In 

addition, assigning a UID improves performance of the router. 

For service profiles, you can request the generation of a UID for a user-defined variable 

by including the uid statement at the [edit dynamic-profiles profile-name variable 

variable-name] hierarchy level. You then reference the variable name in the filter. 

To enable selection of a particular filter in a dynamic profile that contains multiple 

variables of the same parameter and criteria type, you must indicate that the variable 

refers to a UID. To configure, include the uid-reference statement at the [edit 

dynamic-profiles profile-name variable variable-name] hierarchy level. 

For example, if the variable $in-filter receives the value of “filter1” from RADIUS, the 

filter definition named $filter is used. 


• SNMP support for dual-stack subscriber secure policy traffic mirroring (MX Series 

routers)—Subscriber secure policy traffic mirroring now provides dual-stack support 

for DHCP and PPP subscribers. Dual-stack support enables the router to activate both 


137


IPv4 and IPv6 traffic mirroring at different times. As part of the dual-stack 

enhancements, Junos OS Release 11.4 also includes a new SNMP object to identify the 

mirrored IPv6 traffic, and two existing SNMP objects that are modified to track IPv6 

traffic statistics. 

Table 9 on page 138 shows the new and modified SNMP objects. 

Table 9: SNMP Trap Definitions 


Description 


jnxJsPacketMirrorTargetIpv6Address 

IPv6 address of the mirrored 

interface. 



jnxJsPacketMirrorLiSubscriberServiceDeactivated 

jnxJsPacketMirrorLiSubscriberLogInFailed 


jnxJsPacketMirrorLiSubscriberServiceActivationFailed 

jnxJsPacketMirrorOctetsReceived 

Number of octets of 

combined IPv4 and IPv6 

subscriber traffic received. 


jnxJsPacketMirrorOctetsTransmitted 

Number of octets of 

combined IPv4 and IPv6 

subscriber traffic 

transmitted. 



• Support for static and dynamic CoS and firewall filters on L2TP inline LNS service 

interfaces (MX Series routers)—Enables you to configure static and dynamic CoS 

parameters for PPP sessions terminated over L2TP network server (LNS) tunnels. This 

feature is supported on MX Series routers with MPC/MIC modules. 

Inline services at the LNS require that you configure a service interface (si) at the [edit 

interfaces] hierarchy level. 

When a service interface is configured for an L2TP LNS session, it has an inner IP header 

and an outer IP header. You can configure CoS for an LNS session that corresponds 

to the inner IP header because the outer IP header is used for the L2TP tunnel 

processing. However, we recommend that you configure the LNS to reflect the IP ToS 

value in the inner IP header to the outer IP header by including the tos-reflect statement 

at the [edit services l2tp] hierarchy level. 

To apply per-session CoS on egress traffic from the LAC, you can configure fixed and 

behavior aggregate (BA) classifiers by including the classifiers statement at the [edit 

class-of-service] hierarchy level. You can then apply the classifiers at the [edit 

class-of-service interfaces si-fpc/port/pic unit logical-unit-number] hierarchy level or 

at the [edit dynamic-profiles profile-name class-of-service interfaces 

138 



$junos-interface-ifd-name unit $junos-interface-unit] hierarchy level. The following BA 

classifier types are supported: inet-precedence, dscp, and dscp-ipv6. 

To apply per-session CoS on ingress traffic to the LAC, you can configure rewrite rules, 

hierarchical scheduling, and shaping adjustments. To define rewrite rules, include the 

rewrite-rules statement at the [edit class-of-service] hierarchy level. You can then apply 

the rewrite rules at the [edit class-of-service interfaces si-fpc/port/pic unit 

logical-unit-number] hierarchy level or at the [edit dynamic-profiles profile-name 

class-of-service interfaces $junos-interface-ifd-name unit $junos-interface-unit] hierarchy 

level. 

By default, the shaping calculation on the service interface includes the L2TP 

encapsulation. If necessary, you can configure additional adjustments for downstream 

ATM traffic from the LAC or differences in Layer 2 protocols. To enable hierarchical 

scheduling for the service interface, include the hierarchical-scheduler statement at 

the [edit interfaces si-fpc/port/pic ] hierarchy level. To enable Level 3 nodes in the LNS 

scheduler hierarchy and provide better scaling, we recommend that you specify two 

hierarchy levels by including the maximum-hierarchy-levels statement at the [edit 

interfaces si-fpc/port/pic hierarchical-scheduler] hierarchy level. 

To apply additional shaping adjustments for static LNS sessions, you can configure 

the overhead-accounting statement for the service interface at the [edit class-of-service 

traffic-control-profiles profile-name] hierarchy level. For dynamic CoS, apply the 

overhead-accounting statement for the service interface at the [edit dynamic-profiles 

profile-name class-of-service traffic-control-profiles profile-name] hierarchy level. 

You can then apply the traffic control profile to the service interface by including the 

output-traffic-control-profile statement at the [edit class-of-service interfaces 

si-fpc/port/pic unit logical-unit-number] hierarchy level or at the [edit dynamic-profiles 

profile-name class-of-service interfaces $junos-interface-ifd-name unit 

$junos-interface-unit] hierarchy level. To limit bandwidth for tunneled sessions with 

default CoS configurations, we recommend that you also configure CoS for remaining 

traffic by including the output-traffic-control-profile-remaining statement for the static 

interface. 

[Subscriber Access, Class of Service] 

• DHCPv6 multiple address support (MX Series routers)—Subscriber management 

now supports the assignment of multiple addresses to a DHCPv6 client. DHCPv6 

clients can request both IA_NA and IA_PD addresses in a single DHCPv6 Solicit message. 

This feature provides support for networking environments in which a customer 

premises equipment (CPE) device requires a host address and a delegated prefix. 

DHCPv6 multiple address support is enabled by default, and is activated when the 

client DHCPv6 Solicit message contains both the IA_NA and IA_PD options. The 

following list describes subscriber management enhancements to support multiple 

address assignment: 

• For dynamic profile support, you use the new Junos OS predefined variable, 

$junos-subscriber-ipv6-multi-address. The variable is applied as a demux source 

address array, and is expanded to include both the host and prefix addresses. You 

include the $junos-subscriber-ipv6-multi-address variable at the [edit dynamic-profile 

profile-name interfaces interface-name unit logical-unit-number family inet6 


139


demux-source] hierarchy level. You can use this variable in place of the existing 

$junos-subscriber-ipv6-address variable, which only supports a single IPv6 address 

or prefix. 

• You can explicitly specify which address pool the router uses to assign the IA_PD 

address. This enables you to identify the address pool without using RADIUS or a 

network match. To specify which address pool you want to use to assign the IA_PD 

address, include the delegated-pool statement at the [edit system services 

dhcp-local-server dhcpv6 ... overrides] hierarchy levels. You can configure the 

delegated pool at the DHCPv6 local server global, group, or interface hierarchy levels. 

• The show dhcpv6 server binding and show subscriber commands now display 

information related to the DHCPv6 IA_NA and IA_PD multiple address assignments. 


• Support for interface name in the authentication username—You can now include 

the interface name as part of the DHCPv4 and DHCPv6 authentication username for 

DHCP local server and DHCP relay agent. You can include the interface name globally 

or for a specific group. 

To configure the authentication interface name, include the interface-name statement 

at the appropriate [edit ... authentication username-include] hierarchy levels for DHCP 

and DHCPv6 local server, and DHCP and DHCPv6 relay agent. 


• Support for the calling station ID field in RADIUS packets—Starting with Release 11.4, 

Junos OS supports the calling station ID field in RADIUS authentication and accounting 

packets for sessions originating from SSH, Telnet, and FTP-based clients. The calling 

station ID field contains the IP address of the host from which a user connects to the 

router. 

Addition of the calling station ID information in the RADIUS authentication packets 

enables you to configure the RADIUS server to authorize, track, and account users 

based on the calling station ID information. The calling station ID field also enables 

you to identify the geographical locations of the host from which the connection request 

originates. 


• Enhancements to tracing DHCP operations (M120 and M320 Multiservice Edge 

Routers, MX Series 3D Universal Edge Routers)—In earlier releases you configured 

DHCP trace logging in only the default:default LS:RI combination; the configuration 

was applied globally to all LS:RI instances. To apply DHCP trace operations to a 

nondefault LS:RI combination, you were required to configure a DHCP application in 

the default:default LS:RI combination. 

Trace logging is now configured by default outside the scope of the DHCP applications 

(DHCP relay or DHCP local server). To apply a DHCP trace configuration across all 

LS:RI combinations and all DHCP applications, include the traceoptions or 

interface-traceoptions statement at the [edit system processes dhcp-service] hierarchy 

level. 

140 



NOTE: Configuration of event tracing on a per-LS:RI basis is not supported. 

The existing statements at the [edit system services dhcp-local-server] and [edit 

forwarding-options dhcp-relay] hierarchy levels have been deprecated and hidden in 

favor of the statements at the new level in the CLI hierarchy. The deprecated statements 

might be removed from a future release; we recommend that you transition to the new 

statements. 

Because a trace configuration can be configured in more than one scope (two old and 

deprecated, one new and recommended), the following rules apply to manage the 

interaction: 

• When you configure a filename or any other options for the trace log file, the 

configuration at the [edit system processes dhcp-service] hierarchy level has the 

highest precedence, followed by the configuration at the [edit system services 

dhcp-local-server] hierarchy level, and finally with the lowest precedence, the 

configuration at the [edit forwarding-options dhcp-relay] hierarchy level. 

• The flag configuration for multiple scopes is merged and applied to all trace log 

events. 

• You can now filter the generation of DHCP trace log events by severity level: error, 

warning, notice, info, verbose, and all. The default setting is error. However, if you 

configure the old statements, trace logging operates with an implicit severity of all, 

regardless of the severity level configured at the [edit system processes dhcp-service] 



141


The following table lists previously available traceoptions flags that have been 

deprecated and the corresponding flags that now provide the same functionality. 

Deprecated Flag 

Replacement Flag 

dhcpv6-general 

general 

dhcpv6-io 

io 

dhcpv6-packet 

packet 

dhcpv6-packet-option 

packet 

dhcpv6-rpd 

rpd 

dhcpv6-session-db 

session-db 

dhcpv6-state 

state 

packet-option 

packet 

Finally, the layout of trace log content has been enhanced to improve readability. 


• Support for filter enhanced network services mode (MX Series routers with 

MPCs)—Junos OS Release 11.4 supports the limiting of static service filters or API-client 

filters to term-based filter format only for inet or inet6 families when Enhanced Network 

Services mode is configured at the [edit chassis network-services] hierarchy level. When 

used with one of the chassis Enhanced Network Services modes, firewall filters are 

generated only in term-based format for use with MPCs. 

To configure a firewall filter for use with Enhanced Network Services mode, include 

the enhanced-mode statement at the [edit firewall family inet filter filter-name] or [edit 

firewall family inet6 filter filter-name] hierarchy level. 


• CoS enhancements for managing bandwidth for subscriber services (MX Series 

routers with MPC/MIC interfaces)—Enables you to prioritize and manage bandwidth 

for services more effectively at different levels of the broadband edge network. These 

enhancements are supported on MPC/MIC modules on MX Series routers. 

By default, MPC/MIC interfaces support scheduling of excess bandwidth for both lowand 

high-priority traffic. You can now specify the specific priority of the excess 

bandwidth by including the excess-rate-high [proportional value | percent value] 

statement or the excess-rate-low [ proportional value | percent value ] statement at 

the [edit class-of-service traffic-class-profile profile-name] hierarchy level or the [edit 

dynamic-profiles profile-name class-of-service traffic-class-profile profile-name] hierarchy 

level. Note that when you configure the excess-rate statement for an interface, you 

cannot also configure the excess-rate-low and excess-rate-high statements. We 

recommend that you configure either a percentage or a proportion of the excess 

142 



bandwidth for all schedulers with the same parent in the hierarchy. For example, if you 

configure interface 1.1 with 20% of the excess bandwidth, configure interface 1.2 with 

80% of the excess bandwidth. 

On MPC/MIC interfaces, you can configure shaping of aggregate traffic at a given 

priority. By default, when traffic exceeds the shaping or guaranteed rates, the system 

demotes traffic with guaranteed priority. You can disable priority demotion by including 

the none option with the excess-priority statement at the [edit class-of-service 

schedulers scheduler-name] hierarchy level or the [edit dynamic-profiles profile-name 

class-of-service schedulers scheduler-name] hierarchy level. Traffic that exceeds the 

shaping rate is dropped. 

You can now configure a burst size for the shaping rate and guaranteed rate at the 

traffic control profile level, as well as for the shaping rate at the scheduler level. The 

burst value determines the number of rate credits that can accrue when the queue or 

scheduler node is held in the inactive round robin. This feature is useful to prevent 

excessive buffering at downstream DSLAMs, which typically have limited QoS and 

buffering capabilities. Include the burst-size option with the shaping-rate or 

guaranteed-rate statement at the [edit class-of-service traffic-control-profile 

profile-name] hierarchy level or the [edit dynamic-profiles profile-name class-of-service 

traffic-control-profile profile-name] hierarchy level. You can also include the burst-size 

option with the shaping rate at the [edit class-of-service schedulers scheduler-name] 

hierarchy level or the [edit dynamic-profiles profile-name class-of-service schedulers 

scheduler-name] hierarchy level. 

In addition, you can now configure an excess rate when no guaranteed rate is specified 

for a scheduler hierarchy without receiving a commit error. 


• Support for automatic removal of subscriber VLANs—Junos OS Release 11.4 supports 

the automatic removal of subscriber VLANs when no client sessions (for example, 

DHCP or PPPoE) exist on the VLAN. Before Junos OS Release 11.4, you were only able 

to clear or delete subscriber VLANs manually. 

To automatically remove unused dynamic subscriber VLANS, include the 

remove-when-no-subscribers statement at the [edit interfaces interface-name 

auto-configure] hierarchy level. 

NOTE: The maintain-subscriber statement and remove-when-no-subscribers 

statement are mutually exclusive. You cannot specify that dynamically 

configured VLAN interfaces are removed when no subscribers exist when 

the router is also configured to maintain subscribers. 

When configuring automatic removal of dynamic subscriber VLANs, keep the following 

in mind: 

• You can configure automatic VLAN removal only on individual physical interfaces. 

You cannot configure the feature globally. 

• Automatic VLAN removal is not supported for use on Layer 2 Wholesale interfaces. 


143


• PPPoE subscriber interfaces require the use of dynamic profiles when configured 

over dynamic VLANS. However, dynamic profiles are not required for use with DHCP 

subscriber interfaces that use underlying dynamic VLANs. Because the 

remove-when-no-subscribers functionality triggers when no dynamic client sessions 

exist on a dynamic VLAN, automatic removal of underlying dynamic VLANs is not 

supported when DHCP subscriber interfaces are not created using dynamic profiles. 

[Subscriber Access, Network Interfaces] 

• Support for address pool threshold traps (MX Series 3D Universal Edge Routers)—You 

can now set usage threshold traps to give advanced warning that an address pool is 

running short on available addresses. To configure address pool usage threshold traps, 

include the abatedUtilization utilization-value, abatedUtilization-v6 utilization-value, 

highUtilization percentage, and highUtilization-v6 percentage statements at the [edit 

access address-assignment] hierarchy level. 


• Using access profiles to manage NAS port information (MX Series 

routers)—Subscriber management uses default settings and values specified in RADIUS 

to identify the NAS port used for subscriber authentication. The NAS-Port-Id (RADIUS 

attribute 87) and NAS-Port-Type (RADIUS attribute 61) provide the NAS port 

identification and type information. 

You can optionally configure access profiles to provide alternate values for the RADIUS 

NAS-Port-Id and NAS-Port-Type attributes. This enables you to use access profiles 

to specify the NAS port that is used for a given connection. For example, you might 

configure an access profile that specifies that a NAS port type of wireless is used for 

all Ethernet connections that are managed by that access profile. 

To configure an optional NAS-Port-Id, use the nas-port-id-format statement at the 

[edit access profile profile-name radius options] hierarchy level. The optional NAS-Port-Id 

can include any combination of the NAS identifier, the Agent Circuit ID (ACI), the Agent 

Remote ID (ARI), and the interface description. 

To configure an optional NAS-Port-Type, use the nas-port-type statement at the [edit 

access profile profile-name radius options] hierarchy level. The optional port type values 

are specified in RFC 2865 and are also described in the Junos OS Subscriber Access 

Configuration Guide. 


• Support for enhanced policer statistics (MX Series Routers)—With this feature, you 

can query for additional statistics for policers as follows: 

• Offered–Packet statistics for traffic subjected to policing. 

• OutofSpec–Packet statistics for the packets that are marked out-of-specification 

(out-of-spec) by the policer. Changes to all packets that have out-of-spec actions, 

such as discard, color marking, or forwarding-class, are included in this counter. 

• Transmitted–Packet statistics for the traffic that is not discarded by the policer. 

When the policer action is discard, the statistics are the same as the in-spec statistics; 

when the policer action is non-discard (loss-priority or forwarding-class), the statistics 

are included in this counter. 

144 



This feature is supported on MPC/MIC interfaces on MX Series routers. 

The new detail option has been added to the show firewall, show firewall filter 

filter-name, and show policer commands. 

To enable this feature, include the enhanced-policer statement at the [edit chassis] 



System Logging 

• New and deprecated system log tags—The following set of system log messages are 

new in this release: 

• ANALYZER—This chapter describes messages with the ANALYZER prefix on the 

Juniper Networks EX Series switches. They are generated by the sample process 

(sampled), which gathers information on mirrored traffic analysis for EX Series 

switches. 

• FABOAMD—This chapter describes messages with the FABOAMD prefix on the 

Juniper Networks QFabric QFX3000 switch. They are generated by the QFabric 

switch Operations, Administration, and Maintenance (OAM) process (faboamd), 

which enables OAM operations (such as a fabric ping) across different devices in 

the QFabric switch. 

The following system log messages are new in this release: 

• ANALYZER_INPUT_INTERFACES_LIMIT 

• APPIDD_APPPACK_INSTALL_RESULT 

• APPIDD_INTERNAL_ERROR 

• APPTRACK_SESSION_APP_UPDATE_LS 

• APPTRACK_SESSION_CLOSE_LS 

• APPTRACK_SESSION_CREATE_LS 

• APPTRACK_SESSION_VOL_UPDATE_LS 

• ASP_NAT_PORT_BLOCK_ALLOC 

• ASP_NAT_PORT_BLOCK_RELEASE 

• CHASSISD_ACQUIRE_MASTERSHIP 

• CHASSISD_FM_ACTION_FPC_OFFLINE 

• CHASSISD_FM_ACTION_FPC_ONLINE 

• CHASSISD_FM_ACTION_FPC_POWER_OFF 

• CHASSISD_FM_ACTION_FPC_RESTART 

• CHASSISD_FM_ACTION_PLANE_OFFLINE 

• CHASSISD_FM_ACTION_PLANE_ONLINE 


145


• CHASSISD_FM_DETECT_PLANES_DOWN 

• CHASSISD_FM_DETECT_UNREACHABLE 

• CHASSISD_VCHASSIS_LICENSE_ERROR 

• DCBX_PFC_DISABLED 

• DCBX_PFC_ENABLED 

• DCD_PARSE_WARN_INCOMPATIBLE_CFG 

• ESWD_LEARNT_FDB_MEMORY_ERROR 

• ESWD_OUT_OF_LOW_MEMORY 

• ESWD_STATIC_FDB_MEMORY_WARNING 

• ESWD_VLAN_MAC_LIMIT_EXCEEDED 

• EVENTD_SECURITY_LOG_CLEAR 

• FABOAMD_DEBUGGING 

• FABOAMD_TASK_SOCK_ERR 

• FLOW_HIGH_WATERMARK_TRIGGERED_LS 

• FLOW_IP_ACTION_LS 

• FLOW_LOW_WATERMARK_TRIGGERED_LS 

• FWAUTH_FTP_LONG_PASSWORD_LS 

• FWAUTH_FTP_LONG_USERNAME_LS 

• FWAUTH_FTP_USER_AUTH_ACCEPTED_LS 

• FWAUTH_FTP_USER_AUTH_FAIL_LS 

• FWAUTH_HTTP_USER_AUTH_FAIL_LS 

• FWAUTH_HTTP_USER_AUTH_OK_LS 

• FWAUTH_TELNET_LONG_PASSWORD_LS 

• FWAUTH_TELNET_LONG_USERNAME_LS 

• FWAUTH_TELNET_USER_AUTH_FAIL_LS 

• FWAUTH_TELNET_USER_AUTH_OK_LS 

• FWAUTH_WEBAUTH_FAIL_LS 

• FWAUTH_WEBAUTH_SUCCESS_LS 

• IDP_APPDDOS_APP_ATTACK_EVENT_LS 

• IDP_APPDDOS_APP_STATE_EVENT_LS 

• IDP_ATTACK_LOG_EVENT_LS 

• IDP_SESSION_LOG_EVENT_LS 

• JSRPD_SET_HW_MON_FAILURE 

146 



• JSRPD_SET_LOOPBACK_MON_FAILURE 

• JSRPD_SET_MBUF_MON_FAILURE 

• JSRPD_SET_NEXTHOP_MON_FAILURE 

• JSRPD_UNSET_HW_MON_FAILURE 

• JSRPD_UNSET_LOOPBACK_MON_FAILURE 

• JSRPD_UNSET_MBUF_MON_FAILURE 

• JSRPD_UNSET_NEXTHOP_MON_FAILURE 

• L2ALD_FREE_MAC_FAILED 

• LACPD_TIMEOUT 

• LICENSE_SHM_ATTACH_FAILURE 

• LICENSE_SHM_CREATE_FAILURE 

• LICENSE_SHM_DETACH_FAILURE 

• LICENSE_SHM_FILE_OPEN_FAILURE 

• LICENSE_SHM_KEY_CREATE_FAILURE 

• LICENSE_SHM_SCALE_READ_FAILURE 

• LICENSE_SHM_SCALE_UPDATE_FAILURE 

• LSYSD_CFG_RD_FAILED 

• LSYSD_INIT_FAILED 

• LSYSD_SEC_NODE_COMP_SYNC_FAILED 

• PKID_AFTER_KEY_GEN_SELF_TEST 

• PKID_CORRUPT_CERT 

• PKID_FIPS_KAT_SUCCESS 

• PKID_PV_OBJECT_READ 

• RPD_MPLS_REQ_BW_NOT_AVAILABLE 

• RPD_PTHREAD_CREATE 

• RPD_RSVP_INCORRECT_FLOWSPEC 

• RPD_RT_CFG_EIBGP_VTL_CONFLICT 

• RT_FLOW_SESSION_CLOSE_LS 

• RT_FLOW_SESSION_CREATE_LS 

• RT_FLOW_SESSION_DENY_LS 

• RT_SCREEN_ICMP_LS 

• RT_SCREEN_IP_LS 

• RT_SCREEN_SESSION_LIMIT_LS 


147


• RT_SCREEN_TCP_DST_IP_LS 

• RT_SCREEN_TCP_LS 

• RT_SCREEN_TCP_SRC_IP_LS 

• RT_SCREEN_UDP_LS 

• RTLOG_UTP_TCP_SYN_FLOOD_LS 

• SYSTEM_ABNORMAL_SHUTDOWN 

• UI_AUTH_BAD_LOCATION 

• UI_AUTH_BAD_TIME 

• UI_CLASS_MODIFIED_USERS 

• UI_CLI_IDLE_TIMEOUT 

• UI_COND_GROUPS 

• UI_COND_GROUPS_COMMIT 

• UI_COND_GROUPS_COMMIT_ABORT 

• UTMD_MAILNOTIFIER_FAILURE 

• WEBFILTER_URL_REDIRECTED 

The following system log messages are no longer documented, either because they 

indicate internal software errors that are not caused by configuration problems or 

because they are no longer generated. If these messages appear in your log, contact 

your technical support representative for assistance: 

• AV_HUGE_FILE_DROPPED_MT 

• AV_HUGE_FILE_NOT_SCANNED_MT 

• AV_MANY_MSGS_DROPPED_MT 

• AV_MANY_MSGS_NOT_SCANNED_MT 

• AV_SCANNER_DROP_FILE_MT 

• AV_SCANNER_ERROR_SKIPPED_MT 

• AV_VIRUS_DETECTED_MT 

• CHASSISD_FM_FABRIC_DOWN 

• CHASSISD_FPC_FABRIC_DOWN_REBOOT 

• DCD_PARSE_ERR_INCOMPATIBLE_CFG 

• JSRPD_SET_IP_MON_FAILURE 

• JSRPD_UNSET_IP_MON_FAILURE 

• KMD_DPD_IKE_SERVER_NOT_FOUND 

• KMD_DPD_INVALID_ADDRESS 

• KMD_DPD_INVALID_SEQUENCE_NUMBER 

148 



• KMD_DPD_NO_LOCAL_ADDRESS 

• KMD_DPD_REMOTE_PEER_NOT_FOUND 

• KMD_DPD_UNEXPECTED_IKE_STATUS 

• KMD_PM_AUTH_ALGORITHM_INVALID 

• KMD_PM_DYNAMIC_SA_INSTALL_FAILED 

• KMD_PM_ENCRYPTION_INVALID 

• KMD_PM_IKE_SRV_NOT_FOUND_CREATE 

• KMD_PM_KEY_NOT_SUPPORTED 

• KMD_PM_LIFETIME_DUPLICATE 

• KMD_PM_LIFETIME_LENGTH_UNEQUA 

• KMD_PM_LIFETIME_NO_DURATION 

• KMD_PM_LIFETIME_TYPE_UNDEFINED 

• KMD_PM_LIFETIME_UNITS_INVALID 

• KMD_PM_NEW_GROUP_UNSUPPORTED 

• KMD_PM_PHASE1_GROUP_UNREADABLE 

• KMD_PM_PHASE1_IKE_SRV_NOT_FOUND 

• KMD_PM_PHASE1_NO_IDENTITIES 

• KMD_PM_PHASE1_NO_SPD_HANDLER 

• KMD_PM_PHASE1_POLICY_LOOKUP_FAIL 

• KMD_PM_PHASE1_POLICY_NOT_FOUND 

• KMD_PM_PHASE1_PROTO_INVALID 

• KMD_PM_PHASE1_PROTO_NOT_ISAKMP 

• KMD_PM_PHASE1_PROTO_TWICE 

• KMD_PM_PHASE1_TXFORM_INCOMPLETE 

• KMD_PM_PHASE1_TXFORM_INVALID 

• KMD_PM_PHASE2_IDENTITY_MISMATCH 

• KMD_PM_PHASE2_NOTIF_UNKNOWN 

• KMD_PM_PHASE2_SELECTOR_UNDEFINED 

• KMD_PM_PROPOSAL_NO_AUTH 

• KMD_PM_PROPOSAL_NO_ENCRYPTION 

• KMD_PM_PROPOSAL_NO_KEY_LENGTH 

• KMD_PM_PROPOSAL_NULL_ESP 

• KMD_PM_PROPOSAL_PROTOCOL_INVALID 


149


• KMD_PM_PROTO_NOT_NEGOTIATED 

• KMD_PM_REMOTE_PEER_INVALID 

• KMD_PM_SA_DELETE_REJECT 

• KMD_SNMP_IKE_SERVER_NOT_FOUND 

• KMD_VPN_PV_KEY_EXCHG 

• RT_GTP_BAD_LICENSE 

• RT_GTP_DEL_TUNNEL_V0 

• RT_GTP_DEL_TUNNEL_V1 

• RT_GTP_SANITY_EXTENSION_HEADER 

• RT_SIP_MEM_ALLOC_FAILED 

• SSH_FIPS_SELFTEST_EXECUTED 

• SSH_KEYGEN_SELFTEST_DSA 

• SSH_KEYGEN_SELFTEST_RSA 

• SSH_MSG_REPLAY_DETECT 

• SSHD_FIPS_SELFTEST_EXECUTED 

• VSYSD_INIT_FAILED 

• Support for forwarding structured system log messages to remote system log 

server—The structured-data configuration statement is added at the [edit system 

syslog host] hierarchy level to enable the forwarding of system log messages in a 

structured format to a remote system log server. This statement configures the eventd 

process to forward system log messages in the IETF format, which allows 

vendor-specific extensions to be included in the message in a structured way. The 

system log messages can be received on a centralized server that is capable of 

accepting structured messages. 

By default, the eventd process forwards the entire message to the remote system log 

server, when message forwarding is enabled. The eventd process can be enabled to 

send only part of the message (strip the free-form text message). This configuration 

can be set by using the brief option provided for the structured-data statement. 


• Support for configuring system log file rotation frequency—The log-rotate-frequency 

configuration statement is added at the [edit system syslog] hierarchy to configure the 

system log file rotation frequency. The log rotation frequency is altered by configuring 

the time interval at which the log file size is checked. When the log file size has exceeded 

the configured limit, the old log file is archived and a new log file is created. The default 

log rotation frequency is 15 minutes and it can be configured for any value from 1 minute 

through 59 minutes. 

Currently, the cron process schedules the newsyslog process every 15 minutes and this 

value cannot be changed by administrators. If logging to log files takes place at a very 

rapid rate, log files can grow in size much beyond their actual configured limit before 

150 



the newsyslog process can be scheduled to rotate the files. The log-rotate-frequency 

configuration statement helps to overcome this limitation. 


User Interface and Configuration 

• Support for the confirmed option with the commit command in the edit private 

mode—In Junos OS Release 11.4 and later, you can use the commit confirmed command 

in the [edit private] configuration mode. 

[CLI User Guide] 

• Support for configuring a proxy server for downloading licenses—In Junos OS Release 

11.4 and later, you can download Juniper Networks license updates using a proxy server. 

In earlier releases, downloading license updates was only possible by directly connecting 

to the Juniper Networks License Management System. In an enterprise, there might be 

devices in a private network that might be restricted from connecting to the Internet 

directly for security reasons. 

In such scenarios, you can configure a proxy server in the private network to connect 

to the LMS and download the license updates and have the routers or devices in the 

private network connect to the proxy server to download the licenses or license updates. 

To enable this feature, configure the device with details of the proxy server at the [edit 

system proxy] hierarchy level. 


• Using conditions to apply configuration groups—In Junos OS Release 11.3 and later, 

you can use the when statement at the [edit groups group-name] hierarchy to define 

conditions under which a configuration group should be applied. You can configure a 

group to be applied based on the type of chassis, model, or Routing Engine, member 

of virtual chassis, node of cluster, and start and optional end time of day or date. If you 

specify multiple conditions in a single configuration group, all conditions must be met 

before the configuration group is applied. You can specify the start time or time duration 

for the configuration group to be applied. If only the start time is specified, the 

configuration group will be applied at the specified time and remain in effect until the 

time is changed. If the end time is specified, then on each day, the applied configuration 

group will be started and stopped at the specified times. 


• Enhancements to scheduler configuration on FRF.16 physical interfaces—Junos OS 

Release 11.4R5 extends the class-of-service scheduler support on FRF.16 physical 

interfaces to the excess-rate, excess-priority, and drop-profile-map configurations. The 

excess-rate, excess-priority, and drop-profile-map statements are configured at the 

[edit class-of-service schedulers scheduler-name] hierarchy level. 

• Support for the drop-profile-map configuration enables you to configure random 

early detection (RED) on FRF.16 bundle physical interfaces. 

• Support for the excess-rate configuration enables you to specify the percentage of 

the excess bandwidth traffic to share. 


151


• Support for the excess-priority configuration enables you to specify the priority for 

excess bandwidth traffic on a scheduler. 

These enhancements are supported only on Multiservices PICs installed on MX Series 

routers. [Services Interfaces] 

• Accurate reporting of output counters for MLFR UNI NNI bundles—Starting with 

Release 11.4R5, Junos OS reports the actual output counters in the Multilink Frame 

Relay UNI NNI bundle statistics section of the show interfaces lsq-interface statistics 

command output. From this release on, Junos OS also provides output counters for 

each data link connection identifier (DLCI) in Multilink Frame Relay (MLFR) 

user-to-network interface (UNI) network-to-network interface (NNI) bundles. In earlier 

releases, there was a discrepancy between the actual output counters and the reported 

value because of errors in calculating the output counters at the logical interface level. 

That is, at the logical interface level, the output counter was reported as the sum of 

exiting frames at the member links instead of the number of exiting frames per DLCI. 


VPNs 

• NTP support for IPv6 VRF—In Junos OS Release 11.4 and later, NTP also supports IPv6 

VPN routing and forwarding (VRF) requests in addition to IPv4 VRF requests. This 

enables an NTP server running on a provider edge (PE) router to respond to NTP 

requests from a customer edge (CE) router. As a result, a PE router can process any 

NTP request packet coming from different routing instances. 


• Extended Y.1731 functionality on VPLS for frame-delay and delay-variation (MX 

Series routers with MPC interfaces)—MX Series routers with Modular Port 

Concentrators (MPCs) support Y.1731 functionality on VPLS for frame delay and delay 

variation. 

[VPNs, Line Card Guide] 

• Extends egress protection LSP support and interoperability between MX Series 

DPCs and MPC/MIC interfaces (MX240, MX480, and MX960 routers)—An egress 

protection LSP addresses the problem when a link failure occurs at the edge of the 

network (for example, a link failure between a PE router and a CE device). An egress 

protection LSP is an RSVP-signaled ultimate-hop popping LSP. Egress protection LSPs 

do not address the problem of a node failure at the edge of the network (for example, 

a failure of a PE router). Starting with Release 11.4, Junos OS extends support for egress 

protection LSP to MPC/MIC interfaces. Egress protection LSP can now interoperate 

between MX Series DPCs and MPC/MIC interfaces when both types are present on 

the same MX Series router. In previous Junos OS releases, this feature was supported 

only on DPCs in MX Series routers. 

[VPNs] 

Related 

Documentation 




152 


Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release 11.4 for M Series, MX Series, and T Series Routers 





Changes in Default Behavior and Syntax, and for Future Releases in Junos OS Release 11.4 for 

M Series, MX Series, and T Series Routers 

• Changes in Default Behavior and Syntax on page 153 

Changes in Default Behavior and Syntax 

The following are changes made to Junos OS default behavior and syntax. 

• Class-of-Service on page 153 

• High Availability on page 155 

• Interfaces and Chassis on page 155 

• Junos OS XML API and Scripting on page 158 

• J-Web Interface on page 158 

• Multicast on page 158 

• Network Management on page 160 

• Routing Protocols on page 160 

• Services Applications on page 166 

• Security on page 167 

• System Services on page 167 

• Subscriber Access Management on page 168 

• User Interface and Configuration on page 171 

• VPNs on page 171 

Class-of-Service 

• Improvement to output of show services nat mappings summary—The output of the 

show services nat mappings summary command is now grouped by service interface, 

as shown. 

Service Interface: 

sp-1/0/0 

Total number of address mappings: 790 

Total number of endpoint independent port mappings: 1580 

Total number of endpoint independent filters: 1580 


sp-1/1/0 





sp-4/0/0 





153


Service Interface: sp-4/1/0 




[System Basics and Services Command Reference] 

• Protection of routers from denial of service (DOS) attacks—New CLI options provide 

improved protection against DOS attacks. 

• NAT mapping refresh behavior—Prior to this release, a conversation was kept alive 

when either inbound or outbound flows were active. This remains the default behavior. 

As of this release, you can also specify mapping refresh for only inbound flows or 

only outbound flows. To configure mapping refresh behavior, include the 

mapping-refresh (inbound | outbound | inbound-outbound) statement at the [edit 

services nat rule rule-name term term-name then translated secure-nat-mapping] 

hierearchy level. 

• EIF inbound flow limit—Previously. the number of inbound connections on an EIF 

mapping was limited only by the maximum flows allowed on the system. You can 

now configure the number of inbound flows allowed for an EIF. To limit the number 

of inbound connections on an EIF mapping, include the eif-flow-limit number-of-flows 

statement at the [edit services nat rule rule-name term term-name then translated 

secure-nat-mapping] hierarchy level. 

The show services nat pool detail command now shows the current number of EIF 

flows and the flow limit. 

Current EIF Inbound flows count: 0 

EIF flow limit exceeded drops: 0 

• Maximum dropped flows—There is a default maximum of 2000 drop flows allowed 

per PIC at a given instance of time. You can now configure the maximum number of 

drop flows allowed per direction (ingress and egress) at any given instance of time. 

This enables you to limit the creation of drop flows during a denial-of-service (DOS) 

attack. When the maximum number of drop flows exceeds the configured or default 

limit, drop flows are not created and packets are dropped silently, meaning that no 

syslog message is generated for the dropped packets. If maximum dropped flows 

is configured, the appropriate error counters are incremented for packets dropped 

due to exceeded limits. 

To limit the number of drop flows, include the max-drop-flows ingress ingress-flows 

egress egress-flows statement at the [edit services service-set service-set-name] 


The show services stateful-firewall statistics extensive commands now shows the 

maximum flow drop counters when max-drop-flows is configured. 

Drop Flows: 

Maximum Ingress Drop flows allowed: 20 

Maximum Egress Drop flows allowed: 20 

Current Ingress Drop flows: 0 

Current Egress Drop flows: 0 

Ingress Drop Flow limit drops count: 0 

Egress Drop Flow limit drops count: 0 

154 




• Updates to command forwarding support for MX Series Virtual Chassis (MX240, 

MX480, and MX960 routers with MPC/MIC interfaces)—The following operational 

commands now support command forwarding in an MX Series Virtual Chassis 

configuration: 

• show chassis craft-interface 

• show chassis fan 

• show chassis pic 

• show chassis power 

Command forwarding enables you to monitor and manage an MX Series Virtual Chassis 

as a single network element by running operational commands on a specific member 

router in the Virtual Chassis, on both member routers, or on the local member router 

from which you issue the command. With command forwarding, the router sends the 

command to the specified member router or routers and displays the results as though 

the command were processed on the local router. 

To forward operational commands to one or both member routers in an MX Series 

Virtual Chassis, use one of the following options when you issue these commands: 

• To forward the command to a specified member router, use the member member-id 

option, where member-id can be 0 or 1. 

• To run the command on the local member router on which the command was issued, 

use the local option. 

• To forward the command to both member routers, use the all-members option. This 

is the default command forwarding option for the show chassis craft-interface, show 

chassis fan, show chassis pic, and show chassis power commands. 

[Junos OS System Basics and Services Command Reference, Junos OS High Availability 

Configuration Guide] 


• MRU display in LCP Negotiated Options (MX Series 3D Universal Edge Routers)—The 

show ppp interface extensive statement can now display Local MRU and Peer MRU in 

the LCP Negotiated Options section. For LNS inline-service (si) interfaces, however, 

the local MRU is not displayed because the default value of 1500 is always used and 

never advertised, and therefore not negotiated. The Peer MRU value is also now shown 

for PPPoE (pp0.0) interfaces. 


• Enable holdover mode on system restart (MX Series 3D Universal Edge Routers)—The 

synchronous Ethernet Equipment Clock (EEC) is in free-run mode when the chassis is 

switched on or restarted. When a synchronous EEC locks on to an upstream reference 

clock source at least once for a continuous period of 60 seconds, the EEC will have 

stored sufficient Synchronous Ethernet data in a replay holdover buffer. In case of 

failure of a reference clock source, the system goes to holdover mode and uses the 


155


replay data in the holdover buffer to service the downstream Synchronous Ethernet 

clients. 

When a Modular Port Concentrator (MPC) with an EEC restarts (because of either a 

system crash or a manual restart), the holdover buffer data gets erased. Therefore, 

downstream Synchronous Ethernet clients cannot be serviced. This is also applicable 

when a new MPC containing an EEC is inserted into the system. 

In a practical deployment scenario, the status display of holdover mode is invalid only 

when the chassis is switched on or restarted. 

When an MPC containing an EEC is restarted or a new MPC containing an EEC is inserted 

into a system that is (already) in holdover mode, the EEC on this MPC cannot be 

considered to be in holdover mode because it does not have any Synchronous Ethernet 

replay information in its holdover data buffer. Therefore, you must first fix the system 

holdover issue before attempting to service the downstream Synchronous Ethernet 

clients on this MPC. To accomplish this, you must find a suitable upstream reference 

clock source and let the synchronous EEC lock on to this upstream reference clock 

source, and then service the downstream Synchronous Ethernet clients on this MPC. 

• Support of inverse-arp for frame-relay-ether-type—The inverse-arp checking supports 

frame-relay, atm-snap, and frame-relay-ether-type with the condition that when 

configuration includes inverse-arp on the logical interface, the router correctly passes 

the configuration check and the configuration is committed. 


• Number of keepalive messages can be configured for greater control of inactivity 

timeouts for services interfaces—By default, a maximum of 4 consecutive keepalive 

messages are sent to prevent timeout when the TCP timeout limit configured in 

inactivity-tcp-timeout is exceeded. You can now configure a different maximum number 

of keepalive messages (from 0 through 30) by entering the tcp-tickles tcp-tickles 

statement at the [edit services interfaces interace-name service-options] hierarchy level. 

[ Services Interfaces ] 

• New command to monitor PPP recovery after a GRES or restart (MX Series 3D 

Universal Edge Routers)—The new show ppp statistics recovery command monitors 

the progress of PPP recovery after a GRES or restart. When the PPP subscriber sessions 

have been recovered, the command output displays Recovery state: recovery done to 

indicate that it is safe to force another GRES or restart. When you issue this command 

during the recovery process, the command might time out or fail silently rather than 

display output. Recovery is not complete until the command displays recovery done. 


• Multichassis link aggregation (MC-LAG)—When you configure the 

prefer-status-control-active statement at the [edit interfaces aex 

aggregated-ether-options mc-ae events iccp-peer-down] hierarchy level, you must also 

configure the status-control active statement at the [edit interfaces aex 

aggregated-ether-options mc-ae] hierarchy level. If you configure the status-control 

standby statement with the prefer-status-control-active statement, the system issues 

a warning. [JUNOS OS Ethernet Interfaces Configuration Guide] 

156 



• Enhancement to Link Layer Discovery Protocol (LLDP) (MX Series and T Series 

routers)-–You can now configure LLDP to generate the interface name as the port ID 

Type TLV. To generate the interface name as the port ID Type, Length,and Value, 

include the interface-name statement at the [edit protocols lldp port-id-subtype] 

hierarchy level. The default behavior is to generate the SNMP Index of the interface as 

the port ID TLV. If you have changed the default behavior, include the locally-assigned 

statement at the [edit protocols lldp port-id-subtype] hierarchy level to reenable the 

default behavior of generating the SNMP Index of the interface as the port ID TLV. 

When you configure LLDP to generate the interface name as the port ID TLV on the 

remote neighbor, the show lldp neighbors command displays the interface name in the 

Port ID field. The default behavior is for the command to display the SNMP index of 

the interface of the remote neighbor in the Port ID field. [Ethernet Interfaces Configuration 

Guide, Interfaces Command Reference] 

• New options for multichassis link aggregation (MC-LAG)—For MC-LAG, you can now 

specify one of two actions to take if the Inter-Chassis Communication Protocol (ICCP) 

peer of the switch or router goes down. To bring down the interchassis link logical 

interface if the peer goes down, include the force-icl-down statement at the [edit 

interfaces aeX aggregated-ether-options events iccp-peer-down] hierarchy level. To 

have the router or switch become the active node when a peer goes down, include the 

prefer-status-control-active statement at the [edit interfaces aeX 

aggregated-ether-options mc-ae events iccp-peer-down] hierarchy level. When you 

configure the prefer-status-control-active statement, you must also configure the 

status-control active statement at the [edit interfaces aeX 

aggregated-ether-options-mc-ae] hierarchy level. If you do not configure the 

status-control as active with the prefer-status-control-active statement, the router or 

switch does not become the active node if a peer goes down. [Junos OS Ethernet 

Interfaces Configuration Guide] 

• Enhancement to show interfaces queue command—The output for the show interfaces 

queue command now displays rate-limit statistics for class-of-service schedulers for 

all IQ and Enhanced IQ (IQ2E) PICs when rate limiting is configured, even when no 

traffic is dropped. When rate limiting is configured but no traffic is dropped, the output 

for the RL-dropped packets and RL-dropped-bytes fields display the value zero (0). 

Previously, these fields were not displayed when no traffic was dropped and rate 

limiting was configured. To configure rate limiting for queues before packets are queued 

for output, you include the rate-limit statement at the [edit class-of-service schedulers 

transmit-rate rate] hierarchy level. [Interfaces Command Reference] 

• Enhancement to output for show chassis fabric plane extensive command (TX Matrix 

Plus routers)—The output for the show chassis fabric plane extensive command now 

includes more detailed information about link errors caused by CRC saturation. The 

output now displays whether a CRC-related link error occurred under the following 

two conditions: 

• CRC exceeded the rate threshold and reached saturation without optical errors—that 

is, no cable has been cut or removed, or has otherwise experienced an error. In this 

situation, the output now displays the following: Link error crc saturated. 

• CRC exceeded the rate threshold and reached saturation with optical errors—that 

is, a cable has been cut or removed, or has otherwise experienced an error. In this 


157


situation, the output now displays the following: Link error crc saturated with optical 

errors. 

If a link error is caused when the CRC exceeds the rate threshold but does not reach 

saturation, the output for the command continues to display the following: Link error. 


• Configuring the flow-tap service for IPv6 traffic: The family inet | inet6 statement at 

the [edit services flow-tap] hierarchy enables you to specify the type of traffic for which 

you want to apply the flow-tap service. If the family statement is not included, the 

flow-tap service is, by default, applied to the IPv4 traffic. To apply flow-tap service to 

IPv6 traffic, you must include the family inet6 statement in the configuration. To enable 

the flow-tap service for IPv4 and IPv6 traffic, you must explicitly configure the family 

statement for both inet and inet6 families. 

However, you cannot configure the flow-tap service for IPv6 along with port mirroring 

or sampling of IPv6 traffic on routers that support LMNR-based FPCs. This restriction 

holds good even if the router does not have any LMNR-based FPC installed on it. There 

is no restriction on configuring the flow-tap service on routers that are configured for 

port mirroring or sampling of IPv4 traffic. 

• On MX80 routers, the FPC Slot output field has been changed to TFEB Slot for the 

show services accounting flow inline-jflow, show services accounting errors inline-jflow, 

and show services accounting status inline-jflow commands. 


• RPC with inherit="inherit" attribute returns correct time 

attributes for committed configuration—In Junos OS Release 11.4R6 and earlier 

releases, when you configured some interfaces using the interface-range configuration 

statement, if you later requested the committed configuration using the 

RPC with the inherit="inherit" and database="committed" 

attributes, the device returned junos:changed-localtime and junos:changed-seconds in 

the RPC reply instead of junos:commit-localtime and junos:commit-seconds. This issue 

is fixed in Junos OS Release 11.4R7 and later releases so that the device returns the 

expected attributes in the RPC reply. 


• On all M Series, MX Series, and T Series Series platforms, the username field does not 

accept HTML tags or the < and >characters. The following error message appears: A 

username cannot include certain characters, including < and >. 

Multicast 

• Configuration consistency for multicast VPNs—Starting with Junos OS Release 11.4, 

the provider tunnels for draft-rosen 6 anysource multicast VPNs are configured at the 

[edit routing-instances instance-name provider-tunnel] hierarchy level. This change 

provides consistency with draft-rosen 7 and next-generation BGP-based multicast 

VPNs. Specifically, the mdt, vpn-group-address, and vpn-tunnel-source statements at 

the [edit routing-instances instance-name protocols pim] hierarchy level are deprecated. 

158 



The deprecated statements continue to be supported in earlier releases. The following 

example compares the deprecated configuration and the new configuration. 

Deprecated draft-rosen 6 provider tunnel configuration: 

[edit routing-instances VPN-A] 

user@host# show 

protocols { 

pim { 

vpn-tunnel-source 192.68.1.1; 

vpn-group-address 239.1.1.1; 

mdt { 

threshold { 

group 225.2.2.0/24 { 

source 10.1.0.0/16 { 

rate 10; 

} 

} 

} 

tunnel-limit 20; 

group-range 239.5.5.0/24; 

} 

} 

} 

New draft-rosen 6 provider tunnel configuration: 

[edit routing-instances VPN-A] 

user@host# show 

provider-tunnel { 

pim-asm { 

family { 

inet { 

group-address 239.1.1.1; 

tunnel-source 192.68.1.1; 

} 

} 

} 

mdt { 

threshold { 

group 225.2.2.0/24 { 

source 21.1.0.0/16 { 

rate 10; 

} 

} 

} 

tunnel-limit 20; 

group-range 239.5.5.0/24; 

} 

} 

[Multicast] 

• Output show pim join command updated—The output for the show pim join command 

(both detail and extensive) has been modified. When you configure the 

accept-remote-source statement on the router, the Upstream interface output field 


159


now displays the interface name and the Upstream neighbor output field now displays 

the nexthop IP address. Previously, both output fields just displayed unknown (no 

nexthop) and unknown, respectively. 

[Routing Protocols Command Reference] 


• Change in the Junos OS support for IS-IS MIB—In Junos OS Release 11.3 and later, the 

currently supported version of IS-IS MIB, as defined in Internet draft 

draft-ietf-isis-wg-mib-07.txt, is replaced with the latest version of IS-IS MIB, as defined 

in RFC 4444. Junos OS can support only one of these versions of IS-IS MIB in a release. 

Therefore, Junos OS Release 11.2 and earlier continue to support IS-IS MIB as defined 

in Internet draft draft-ietf-isis-wg-mib-07.txt, whereas Junos OS Release 11.3 and later 

support only the updated RFC 4444–based version of IS-IS MIB. 

[Network Management, SNMP MIBs and Traps Reference] 


• Starting in Junos OS Release 10.4, you cannot deactivate a routing instance that 

contains a disabled loopback interface. The loopback interface must first be enabled, 

deleted, or deactivated in the configuration before you can deactivate a routing-instance 

containing that loopback interface. [Routing Protocols] 

• CLI output changes for operational mode commands related to multicast VPN—The 

output of some of the operational mode commands related to multicast VPN has been 

modified to display more meaningful information. The show mvpn... commands display 

text names for ingress tunnels. The neighbor display header field for the show mvpn... 

commands now use Inclusive Provider. For IR provider tunnels, the show mvpn... 

commands also include the label in the output. Ingress tunnel names now have tunnel 

type appended in the name. The show pim source and show pim join commands display 

PE address for upstream neighbors. The show multicast route command displays the 

provider tunnel's text name instead of displaying multiple interfaces for the provider 

tunnel branches. 

• show mvpn c-multicast 

user@host> show mvpn c-multicast 

MVPN instance: 

Legend for provider tunnel 

S- Selective provider tunnel 

Legend for c-multicast routes properties (Pr) 

DS -- derived from (*, c-g) 

RM -- remote VPN route 

Family : INET 

Instance : v1 

MVPN Mode : RPT-SPT 

C-mcast IPv4 (S:G) Provider Tunnel St 

0.0.0.0/0:224.1.1.1/32 INGRESS-REPLICATION:MPLS Label 299776:10.0.0.40 

RM 


RM 


RM 

160 









Family : INET6 

Instance : v1 



::/0:ff35:2001::1/128 INGRESS-REPLICATION:MPLS Label 299776:10.0.0.40 



user@host> show mvpn c-multicast extensive 







Family : INET 

Instance : v1 




RM 


RM 


RM 








Instance : v1 






• show mvpn neighbor 

user@host> show mvpn neighbor 






161



Family : INET 


Instance : v1 


Neighbor 

Inclusive Provider Tunnel 

10.0.0.20 INGRESS-REPLICATION:MPLS Label 

299776:10.0.0.20 


299776:10.0.0.60 


299776:10.0.0.80 








Instance : v1 


Neighbor 



299776:10.0.0.20 


299776:10.0.0.60 


299776:10.0.0.80 

• show mvpn instance 

user@host> show mvpn instance 







Family : INET 

Instance : v1 


Provider tunnel: I-P-tnl:INGRESS-REPLICATION:MPLS Label 299776:10.0.0.40 

Neighbor 



299776:10.0.0.20 


299776:10.0.0.60 


299776:10.0.0.80 



RM 


RM 


RM 



162 








Instance : v1 



Neighbor 



299776:10.0.0.20 


299776:10.0.0.60 


299776:10.0.0.80 





user@host> show mvpn instance summary 

MVPN Summary: 

Family: INET 

Instance: v1 

Neighbor count: 3 

C-multicast IPv4 route count: 3 

Family: INET6 

Instance: v1 

Neighbor count: 3 

C-multicast IPv6 route count: 3 

user@host> show mvpn instance extensive 







Family : INET 

Instance : v1 



Neighbor 



299776:10.0.0.20 


299776:10.0.0.60 


299776:10.0.0.80 



RM 


RM 


RM 


163









Instance : v1 



Neighbor 



299776:10.0.0.20 


299776:10.0.0.60 


299776:10.0.0.80 





• show multicast route 

user@host> show multicast route instance v1 extensive 

Instance: v1 Family: INET 

Group: 224.1.1.1 

Source: (null)/0 

Upstream interface: fe-1/3/0.111 

Downstream interface list: 

lt-0/3/0.42 lt-0/3/0.46 lt-0/3/0.43 

Group: 224.1.1.2 




lt-0/3/0.42 lt-0/3/0.46 lt-0/3/0.43 

Group: 224.1.1.3 




lt-0/3/0.42 lt-0/3/0.46 lt-0/3/0.43 

Instance: v1 Family: INET6 

• show pim join 

user@host> show pim join instance v1 

Instance: PIM.v1 Family: INET 

R = Rendezvous Point Tree, S = Sparse, W = Wildcard 

Group: 224.1.1.1 

Source: * 

RP: 10.0.111.1 

Flags: sparse,rptree,wildcard 

164 



Upstream interface: fe-1/3/0.111 (administratively scoped) 

Group: 224.1.1.2 

Source: * 

RP: 10.0.111.1 



Group: 224.1.1.3 

Source: * 

RP: 10.0.111.1 



Instance: PIM.v1 Family: INET6 

R = Rendezvous Point Tree, S = Sparse, W = Wildcard 

Group: ff35:2001::1 

Source: * 

RP: ::ffff:10.0.0.41 


Upstream interface: Local 

Group: ff35:2001::2 

Source: * 

RP: ::ffff:10.0.0.41 



Group: ff35:2001::3 

Source: * 

RP: ::ffff:10.0.0.41 



• show pim source 

user@host> show pim source instance v1 

Instance: PIM.v1 Family: INET 

Source 10.0.111.1 

Prefix 10.0.111.1/32 

Upstream interface fe-1/3/0.111 

Upstream neighbor Direct 

Instance: PIM.v1 Family: INET6 

Source ::ffff:10.0.0.41 

Prefix ::ffff:10.0.0.41/128 

Upstream interface Local 

• If you configure the route-distinguisher statement in addition to the route-distinguisher-id 

statement, the value configured for route-distinguisher supersedes the value generated 

from route-distinguisher-id. To avoid a conflict in the two route distinguisher values, 

we recommend ensuring that the first half of the route distinguisher obtained by 

configuring the route-distinguisher statement is different from the first half of the route 

distinguisher obtained by configuring the route-distinguisher-id statement. 


165



• Option available to clear the DF (don't fragment) flag in packet headers under NAT 

64—You can specify clearing of the DF flag in IPv4 headers when performing NAT64 

translation. The flag is cleared when packets are less than 1280 bytes but might need 

to be fragmented when the IPv4-path-mtu size is less than 1280. When the flag is not 

cleared, a packet-too-big error message is generated and sent to the IPv6 host, which 

replies with a fragment header added. RFC 6145, IP/ICMP Translation Algorithm, provides 

a full discussion of the use of the DF flag to control fragmentation. 

To clear the DF flag, include the stateful-nat64 clear-dont-fragment-bit statement at 

the [edit services service-set service-set-name nat-options] hierarchy level. 

• Changes to softwire and firewall show commands—New softwire statistical counters 

are available in Junos OS Release 11.4R2 and later for the show services softwire 

statistics, show services stateful-firewall statistics detail, and show services 

stateful-firewall statistics extensive commands. 

Counters added for show services softwire statistics (DS-Lite or v6rd): 

• Softwires Created for EIF/HP—(DS-Lite only) Number of softwires created for 

endpoint-independent filtering (EIF) or hairpinning (HP). 

• Slow Path Packets Processed for EIF/HP—DS-Lite only. Number of slow path EIF/HP 

packets processed. These slow path packets initiate the creation of the softwire 

flow. 

• Softwire EIF Accept—(DS-Lite only) The number of packets which matched an EIF 

entry that initiated the creation of a DS-Lite tunnel. The EIF entry was previously 

triggered by a DS-Lite packet. 

• ICMPv4 Packets sent—(DS-Lite only) The number of ICMPv4 packets sent to ping 

the address 192.0.0.1, which is a unique IPv4 address reserved for the Address Family 

Transition Router (AFTR). 

• ICMPv4 Error Packets sent—(DS-Lite only) Number of non-ping echo requests received 

by the AFTR. 

• ICMPv6 Packets sent—(DS-Lite only) Number of ping requests sent to the AFTR 

softwire address. 

• Dropped ICMPv6 packets destined to AFTR—(DS-Lite only) Number of ICMPv6 error 

messages discarded whose destination was the AFTR address. 

• Flow Creation Failed - Retry for EIF/HP—(DS-Lite only) Number of failed flow creations 

for EIF/HP to be retried. 

• Softwire Creation Failed for EIF/HP—(DS-Lite only) Number of softwire creation 

failures for EIF/HP. 

• Flow Creation Failed For EIF/HP—(DS-Lite only) Number of flow creation failures for 

EIF/HP. 

• Slow Path Packets Processed (Gratuitous)—(v6rd only) Number of gratuitous packets 

received by the 6rd branch relay (BR). 

166 



Counters added for show services stateful-firewall statistics (detail and extensive): 

• Slow Path Hairpinned Packets—Number of slow path packets for hairpinned flows. 

Slow path packets are the packets that triggered initiation of the hairpinned flow. 

• Fast Path Hairpinned Packets—Number of packets received that matched an existing 

hairpinned flow. 

Security 

• Enhancements to DDoS Protection (MX Series Routers)—The configuration of DDoS 

Protection has changed slightly. You can now include the disable-fpc statement at the 

[edit system ddos-protection protocols protocol-group (aggregate | packet-type)] 

hierarchy level to disable policers on all line cards for a particular packet type or 

aggregate within a protocol group. The ability to configure this statement globally or 

for a particular line card remains unchanged. 

You can also now include the disable-logging statement at the [edit system 

ddos-protection protocols protocol-group (aggregate | packet-type)] hierarchy level to 

disable router-wide logging of DDoS violation events for a particular packet type or 

aggregate within a protocol group. The disable-logging statement has been moved 

from the [edit system ddos-protection violation] hierarchy level, and that hierarchy 

level has been removed from the CLI. 

The show ddos-protection protocols command now displays Partial in the Enabled field 

to indicate when some of the instances of the policer are disabled. The Routing Engine 

Information section of the output now includes fields for bandwidth, burst, and state. 

The show ddos-protection protocols parameters command and the show ddos-protection 

protocols statistics command now include a terse option to display information only 

for active protocol groups—that is, groups that show traffic in the Received (packets) 

column. The show ddos-protection protocols parameters command also displays part. 

for policers that have some disabled instances. 

[DDoS Protection] 

System Services 

• Enhancements to SSH—Additional statements have been added to [system services 

ssh], providing more capabilities to manage tunneled sessions and connection timeouts, 

and to configure additional key algorithms. SSH version 2 is now the default, and you 

can configure SSH version 1 if needed. 

The [system services ssh] statements now include the following: 

ssh { 

ciphers [ cipher-1 cipher-2 cipher-3 ...]; 

client-alive-count-max seconds; 

client-alive-interval seconds; 

connection-limit limit; 

hostkey-algorithm ; 

key-exchange ; 

macs ; 

max-sessions-per-connection ; 

no-tcp-forwarding; 


167


protocol-version [v1 v2]; 

rate-limit limit; 

root-login (allow | deny | deny-password); 

} 

The new or updated ssh statements were introduced starting with Junos OS Release 11.2 

and include: 

• ciphers—Specify the set of ciphers the SSH server can use to perform encryption and 

decryption functions. 

• client-alive-count-max—Configure the number of client alive messages that can be 

sent without sshd receiving any messages back from the client. 

• client-alive-interval—Configure a timeout interval in seconds, after which if no data 

has been received from the client, sshd will send a message through the encrypted 

channel to request a response from the client. This option applies to SSH protocol 

version 2 only. Statement introduced in Junos OS Release 12.1. 

• hostkey-algorithm—Allow or disallow a host-key signature algorithm for the SSH host 

to use to authenticate another host. 

• key-exchange—Specify the set of Diffie-Hellman key exchange methods that the SSH 

server can use. 

• macs—Specify the set of message authentication code (MAC) algorithms that the 

SSH server can use to authenticate messages. Additionally, SHA-2 options are available 

as of Release 12.1 of Junos OS. 

• max-sessions-per-connection—Specify the maximum number of ssh sessions allowed 

per single SSH connection. Statement introduced in Release 11.4 of Junos OS. 

• no-tcp-forwarding—Configure this to prevent a user from creating an SSH tunnel over 

a CLI session to a Junos router. Statement introduced in Release 11.4 of Junos OS. 

• protocol-version—Specify the SSH protocol version. The default is changed from version 

1 to version 2 beginning with Junos OS Release 11.4. 

[edit system services ssh] 


• Enhanced subscriber service accounting information—Subscriber access accounting 

has been enhanced in Junos OS Release 11.4R2 and later, and Release 12.1R1 and later. 

RADIUS VSA 26-83 (Service-Session), which is included in RADIUS service accounting 

start and stop packets, now includes the parameter values used to activate a subscriber 

service, in addition to the service name. In earlier releases, only the service name was 

included. When VSA 26-83 is not available from the RADIUS server, subscriber 

management sends the service name in the accounting message (as was the case in 

earlier releases). 

[Subscriber Acess] 

• Delay in removing subscriber routes after graceful Routing Engine switchover (M120, 

M320, and MX Series routers)—For a subscriber network in which either nonstop active 

routing (NSR) or graceful restart has been configured, you can configure the router to 

168 



wait for 180 seconds (3 minutes) before removing access routes and access-internal 

routes after a graceful Routing Engine switchover (GRES) takes place. 

This 3-minute delay provides sufficient time for the appropriate client process (jpppd 

or jdhcpd) or routing protocol process (rpd) to reinstall the access routes and 

access-internal routes before the router removes the stale routes from the forwarding 

table. As a result, the risk of traffic loss is minimized because the router always has 

available subscriber routes. 

To configure the router to wait for 180 seconds before removing (flushing) access 

routes and access-internal routes after a graceful Routing Engine switchover, include 

the gres-route-flush-delay statement at the [edit system services 

subscriber-management] hierarchy level. 

Using the gres-route-flush-delay statement in your subscriber management 

configuration offers the following benefits: 

• Provides sufficient time to reinstall subscriber routes from the previously active 

Routing Engine 

In subscriber networks with graceful restart and routing protocols such as BGP and 

OSPF configured, the router purges any remaining stale routes as soon as the graceful 

restart operation completes, which can occur very soon after completion of the 

graceful Routing Engine switchover. Using the gres-route-flush-delay statement 

causes the router to retain the stale routes for a full 180 seconds, which provides 

sufficient time for the jpppd or jdhcpd client process to reinstall all of the subscriber 

routes. 

• Prevents loss of subscriber traffic due to unavailable routes 

In subscriber networks with nonstop active routing and routing protocols such as 

BGP and OSPF configured, the routing protocol process immediately purges the 

stale routes that correspond to subscriber routes. This removal results in a loss of 

subscriber traffic. Using the gres-route-flush-delay statement causes the router to 

retain the stale routes for a full 180 seconds, which prevents potential traffic loss 

due to unavailable routes. 

[Junos OS Subscriber Access Configuration Guide] 

• Strict enforcement of subscriber scaling license (MX Series routers)—You can 

configure the router to strictly enforce the subscriber scaling license feature, which is 

part of the Junos Subscriber Access Feature Pack license. 

When you enable strict scaling license enforcement, the router takes the following 

actions: 

• Strictly enforces the subscriber scaling license and does not allow any grace period. 

When the number of logged-in subscribers reaches the maximum allowed by the 

scaling license, no additional subscribers are allowed. 

• Creates the informational log message, “90% of installed subscriber scale licenses 

in use", to inform you when you have 10% of the total allowed licenses remaining. 

The router clears this condition when license usage falls below 90%. The log message 

is created again if the 90% usage is reached. 


169


To configure strict scaling license enforcement, you include the 

enforce-strict-scale-limit-license statement at the [edit system services 

subscriber-management] hierarchy level. 


• Managing RADIUS Class attribute (attribute 25) information in service accounting 

reports—Subscriber management includes the Class attribute (RADIUS attribute 25) 

in all accounting packets for a subscriber session and the subscriber’s service sessions. 

By default, when the subscriber’s Class attribute is changed by a CoA action, the new 

Class attribute value is then used in subsequent accounting reports for both the 

subscriber session and the subscriber’s service sessions. 

You can override the default behavior and specify that, after a CoA action, the new 

Class attribute value is used in accounting reports for the subscriber sessions only. The 

accounting reports for the subscriber’s service sessions continue to use the original 

Class attribute that was assigned when the service sessions were created. 

To configure the router to override the default action, include the coa-no-override 

service-class-attribute statement at the [edit access profile profile-name accounting] 



• Triggering subscriber secure policy for subscribers on VLANs—Interface-based 

subscriber secure policy is now supported on dynamic, authenticated VLAN interfaces 

and VLAN demux interfaces. When you enable subscriber secure policy for these 

interfaces, traffic for all configured families (inet, inet6) including Layer 2 and Layer 3 

control traffic is mirrored. The mirrored packets include Layer 2 encapsulations. 

When you have DHCPv4/DHCPv6 subscribers over VLANs, two sessions are created 

for each subscriber—one for the Layer 2 VLAN, and one for DHCP. In this case do not 

use a trigger, such as Remote Circuit ID (ACI), that applies to both the VLAN and the 

DHCP sessions. If the DHCP and VLAN sessions match the same trigger, the DHCP 

subscriber login fails and subscriber secure policy is not triggered. You need to select 

a traffic mirroring trigger that matches only one of these sessions. 

• Session-ID added to output of show network-access aaa subscribers username 

command (MX Series routers)—The output of the show network-access aaa subscribers 

username username command now includes a column showing the Session-ID for the 

specified username. 


• Archiving configuration files for a passive FTP server—Junos OS documentation for 

the archive-sites configuration statement at the [edit system archival configuration] 

hierarchy level is being updated to include information that the pasvftp prefix option 

can be used when archiving configuration files for a passive FTP server. This is in addition 

to prefix options for file//:, ftp://, and scp://. The pasvftp configuration statement 

option is of the form: pasvftp://username@host:url-path password password; 


170 



• GRE tunnels—Configuring more than 4K GRE tunnels in the devices with multiple 

tunnel PICs or Modular Port Concentrators (MPCs) / Dense Port Concentrators (DPCs) 

will now be rejected by the device. 

[Subscriber Management] 

• Interface support—An aggregated Ethernet (ae) interface is now supported in JSSCD 

groups. 

[Subscriber Management] 


• Enhancement to test configuration operational statement—The new option syntax-only 

allows a user to check a partial configuration without checking for commit errors. 


• Starting in Junos OS Release 11.2, the set protocols mpls label-switched-path 

install command now also accepts IPv6 prefixes. In previous releases, only 

IPv4 prefixes were supported. 

VPNs 

• VPLS interface encapsulation—When you configure an interface for a VPLS routing 

instance, the physical interface encapsulation must be configured with a VPLS 

encapsulation (ethernet-vpls, extended-vlan-vpls, flexible-ethernet-services, or 

vlan-vpls); otherwise the commit will fail. [VPNs] 

• Starting in Junos OS Release 11.4, vrf-import policies must reference a target community 

in the from clause. If the import policy does not reference a specific community target 

or if the referenced community is a wildcard, the commit operation fails. As an exception, 

the policy does not need to reference a community target in the from clause when the 

policy action in the then clause is "reject." Prior to Junos OS Release 11.4, when the 

vrf-import policy did not reference a specific community target in the from clause, the 

commit operation succeeded, but the import policy had a nondeterministic effect. 

Related 

Documentation 

• New Features in Junos OS Release 11.4 for M Series, MX Series, and T Series Routers 

on page 73 







171


Issues in Junos OS Release 11.4 for M Series, MX Series, and T Series Routers 

The current software release is Release 11.4. For information about obtaining the software 

packages, see “Upgrade and Downgrade Instructions for Junos OS Release 11.4 for M 

Series, MX Series, and T Series Routers” on page 321. 

• Current Software Release on page 172 

• Previous Releases on page 202 

Current Software Release 

Outstanding Issues 

Class of Service (CoS) 

• When GRES is configured, a live core file might be seen on the backup Routing Engine. 

This happens if VRRP priority changes continuously and the following configurations 

are changed on the distribution routers: 

• IRB interfaces 

• Routing and spanning-tree protocols 

• Multicast 

• VPLS routing instance 

• Bidirectional Forwarding Detection (BFD) 

The live core file does not affect traffic or functionality. [PR668695] 

• When the show interfaces extensive [interface] | display xml command is executed, 

there might appear issues in the XML output display of COS red/dropped packets. The 

"Dropped packets" is total of red-drop + tail-drop (+ rate-limit-drops in case of IQE) 

so the XML should also say “queue-counters-total-drop-packets.” It used to say 

“queue-counters-red-packets,” which was incorrect. [PR683410] 

• M7i and M10i routers with non-enhanced CFEB support only four forwarding classes. 

[PR786081] 

• If you set the following commands, Cosd crash after executing show class-of-service 

scheduler-map. 

set class-of-service interfaces ge-2/0/* scheduler-map-chassis derived 

set class-of-service interfaces ge-2/0/1 scheduler-map-chassis p0 

set class-of-service interfaces ge-2/1/* scheduler-map-chassis derived 

set class-of-service interfaces ge-2/1/1 scheduler-map-chassis p0 

The scheduler-map-chassis command for ge-2/0/1 and ge-2/1/1 has to be overridden 

because of the more specific configuration. This is happening correctly, but the 'derived' 

scheduler-map previously allocated for these interfaces is not getting freed. Cosd 

crashes when trying to display these scheduler maps since they are not fully populated. 

[PR807593] 

• Commit throws an error "Invalid rewrite rule rule-name for ifl . Ifd 

is not capable to rewrite inner vlan tag 802.1p bits" even though there is no rewrite 

configuration related to inner-vlan tag. [PR849710] 

172 



Forwarding and Sampling 

• When burst-size-limit is configured to a value more than 100,000,000 bytes on M7i or 

M10i routers with CFEB-E, the correct burst size is not reflected by CFEB-E on the router. 

[PR706272] 

• Firewall logs does not record rejected or accepted packets on the loopback filter though 

packets are rejected or accepted. [PR724059] 

• In Junos OS Release 10.2 and later, FBF does not disable uRPF when setting the 

uRPF(rpf-check) and FBF on an interface, which is in a routing instance. [PR735697] 

• When master Routing Engine switchover is performed because the backup Routing 

Engine is out of synchronization with the master and if GRES(Graceful Routing Engine 

Switchover)/NSR(nonstop active routing)/NSB(nonstop bridging) is enabled, the 

L2ald (Layer 2 address learning daemon) might generate a core file. [PR735913] 

• The Junos OS firewall process (dfwd) may generate core files and restart during a 

unified in-service software upgrade when the configuration includes Ascend-Data-filters. 

[PR746128] 

• PFED crashes while processing a corrupted message sent from the Packet Forwarding 

Engine. To fix this issue, changes are being made to PFED. However, the scope of this 

issue is limited due to the unknown nature of the corruption. A separate PR771108 is 

created to make some changes to the Packet Forwarding Engine. [PR750143] 

• When the accounting-options interface-profile command is executed to a large number 

of logical interfaces (approximately more than 2000), the accounting-options 

interface-profile rate control towards the Packet Forwarding Engine is broken. This 

issue is caused when attempting to gather interface statistics simultaneously on too 

many interfaces in a short interval. Intervals of less than 5 minutes are not 

recommended. In addition, gathering statistics on more than 500 interfaces using 

accounting-options interface-profile might lead to inaccurate statistics output. 

[PR753960] 

• Under some circumstances, PFED process might crash when fetching accounting 

statistics. [PR782281] 

• When set client-idle-timeout is over, VLAN is removed even though there is 

ingress/egress traffic on PPPoE clients. [PR784529] 

General Routing 

• The auto-complete feature is not working for the show policy command. [PR471332] 

• In the list of allowed options under the set access radius-options request-rate command 

on the CLI, the request-rate in seconds is displayed. [PR745252] 

• When service is added to the subscriber through radius COA, the service records are 

not full released to the DB. It causes sdb.db size to grow. PR 746587 fix this issue by 

releasing the record completely. [PR746587] 

• On an MX Series router with GRES enabled, when the system reboots after 

"dynamic-profile-options versioning" is committed, the DHCP/PPPoE subscriber fails 

to log in. [PR770140] 


173


• When dynamic-profile versioning is enabled, CoA requests are not processed if authd 

restarts. [PR796416] 

• In a subscriber management environment, with GRES enabled, the subscriber 

management infrastructure process (smid) maintains a directory /mfs/var/sdb, which 

contains several logs/stats and databases that must be cleaned up and compacted 

every couple of hours. If the subscriber management infrastructure process compacts 

databases during berkeley database replication process (bdbrepd) hasn't finished the 

initial replication between Routing Engines, smid may get stuck in a loop cause it does 

not checkpoint or archive the log files anymore, so the /mfs directory eventually fills 

up. Then the router locks up with no telnet/console access, and no subscribers logging 

into the router. When issue happens, the following errors could be seen: 

/kernel: Process (1977,bdbrepd) has exceeded 85% of RLIMIT_DATA: used 114692 KB 

Max 131072 KB 

/kernel: Process (1977,bdbrepd) attempted to exceed RLIMIT_DATA: attempted 131076 

KB Max 131072 KB 

/kernel: pid 1977 (bdbrepd), uid 0 inumber 636230 on /mfs: filesystem full 

The storage usage of bdbrepd process could be observed by following command (the 

'SIZE' field means Total size of the process (text, data, and stack), in kilobytes): 

user@router> show system processes extensive | match bdbrepd 

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 

1568 root 1 96 0 55068K 37940K select 28:32 0.00% bdbrepd 

[PR796430] 

• If Hagiwara CompactFlash does not support APM, don't try to initiate it. [PR593219] 

• In case of private commit, you can skip generating or applying a patch if no commit 

happened in other sessions between the time you entered the private session and 

committed. There is no need to update the private database to the last committed 

database because no commits happened from other private or shared session. 

juniper.db (shared database) should be updated with the private database commit 

changes. Simple file copy is enough. But you need to take care of database header 

(restoring the user_info, lr_info and exlocker information of juniper.db). [PR607942] 

• On certain M-series routers (M20, M40, M40e, and M7i/M10i without Enhanced CFEB), 

the following error message is displayed on the Packet Forwarding Engine console 

periodically: "pfe_get_ifl_stats failed" This error is seen only if aggregate interfaces 

(like AE or AS) is configured on the router. There is no functional impact because of 

this error message. [PR692081] 

• Provided that an MX Series router has only one interface that uses auto-configure to 

set up a VLAN interface for PPPoE/IPoE subscriber sessions, the system's 

auto-configure process is killed when you delete the auto-configure command under 

that interface. But the MX Series router does not clear the corresponding VLAN interface. 

Thus the subscribers can still dial in. [PR709911] 

• For SONET/SDH OC48/STM16 Enhanced IQ (IQE) PIC with SFP with fixed IPv6 

classification, IPv6 filter counting all non-BE FC/queue packets to the BE FC/Queue 

counter. [PR732893] 

174 



• An Layer 2 control read error is seen sometimes on a MIC bootup, causing the MIC to 

fail to boot up. [PR733067] 

• A PCI read error can sometimes cause the 8xOC3-2xOC12 MIC bootup to fail and the 

MIC to stay offline with "Hardware Error" status. [PR733520] 

• Under certain timing conditions, the Packet Forwarding Engine might install an 

uninitialized firewall filter next hop in the forwarding hardware memory. When a 

forwarding chipset encounters the uninitialized next hop during packet processing, it 

triggers an exception error condition. [PR751088] 

• When a large number of subscribers log in and log out simultaneously in a scaled 

configuration, errors might occur when logical interfaces are created. The errors occur 

because the rpd process fails to read ifstate notifications related to logical interface 

deletions. As a workaround, restart the rpd. [PR775033] 

• If RPF and/or SCU is enabled then any change to an ingress firewall table filter will 

trigger RPF/SCU reconfiguration for every prefix in the routing table. This may cause 

transient high CPU utilization on the fpc which may result in SNMP stats request being 

time out. [PR777082] 

• AE member link is rejecting packets due to bad unicast MAC. [PR783332] 

• The rms interface option is hidden for the following show commands and is not 

auto-completed on the CLI: 

-show interfaces redundancy -request interface revert -request interface switchover 

[PR784678] 

• With l3vpn composite next-hops configured and 3 or more odd number of core uplinks 

every l3vpn route deletion will syslog the following error messages. [LOG: Err] JTREE: 

(jt_mem_free) size 0 for addr 1595452, seg 1, inst 0 [LOG: Emergency] Multiple Free 

:jt_mem_free There is no operational impact. An even number of core-uplinks will not 

trigger such error logs. [PR786993] 

• MPLS LDP traceroute does not work if you have a default route 0/0 pointing to discard 

on the Egress router with DPC cards. [PR790935] 

• This PR provides fix for a Packet Forwarding Engine micro-kernel memory leak, 

applicable only to certain types of firewall filter configurations on Trio-based MPCs 

and DPCs. The concerned leak can occur with dynamic-profiles configuration with 

firewall filters (typical for subscriber services), or when protocols like Ethernet OAM 

are configured. The leak occurs only under a certain timing condition (so far observed 

for about 2-5% of interface delete operations), and only on interface delete operations. 

Leaked memory is of order of 1KB per incidence of the memory leak. Hence the issue 

will be of material impact in and only in deployment scenarios which involve many 

thousands of interface delete operations with either dynamic profiles configuration or 

Ethernet OAM configuration. [PR797790] 

• In a subscriber management environment with knob versioning enabled for 

dynamic-profile, during subscriber flapping or login/logout, the authd (authentication 

daemon) process may leak memory. [PR800028] 

• Dynamic VLAN may remain stuck in "termianting" state after line card reboot. 

[PR800533] 


175


• In a BRAS environment with PPPoE subscribers and parameterized firewalls and 

policers, the FPC memory usage will go high after a CoA change for the services' 

parameters. [PR805922] 

• In subscriber management scenario, during DHCP or PPPoE subscribers login, cosd 

process might leak memory when cosd is initializing cos related parameters for 

subscribers. It happens only if the subscriber has one cos service session. [PR815777] 

• In subscriber management environment, after scale DHCP/PPPoE subscribers (about 

16k) login/logout multiple times, some of them fail to login again due to system can 

not allocate memory for them. When issue happens, following errors could be seen: 

[LOG: Err] IFRT: 'IFL demux enable' (opcode 175) failed [LOG: Err] rt_table_index_alloc: 

failed to allocate index with error: memory allocation failure !!! [LOG: Err] 

ifdemux_create_table(): ifl 17716:IPv4 => failed to allocate index for demux rt table 

with error: memory allocation failure !!! [LOG: Err] IFRT: 'IFL demux enable' (opcode 

175) failed [LOG: Err] ifl 17716:IPv4; demux create table failed with error=8 [PR819614] 

• PPPoE sessions cannot be established as rpd is unable to read or access profile 

database during access-internal route creation via 

"dynamic-profile->routing-instances->routing-options->access-internal" stanza 

[PR830779] 

• An FPC may reboot when a live-core is requested and the /var partition does not have 

sufficient space to store the live-core. [PR835047] 

• In the low memory condition with NSR enable, the replication of the route from the 

master routing-engine to the backup routing engine might stucked into inconsistent 

state preventing the correct operation of the NSR. [PR840331] 

High Availability (HA) and Resiliency 

• On TX routing systems with GRES enabled, if a mastership switch is being requested 

on an LCC who's Backup Routing Engine’s em0 interface has physically failed, this will 

cause all FPCs on that LCC to disconnect from the old master Routing Engine, but NOT 

reconnect to the new Master Routing Engine. [PR799628] 


• On J Series devices, the top utility with "ores" options was not sorting the output based 

on resident memory size. [PR507675] 

• With IPv6 and PPPoE, DHCP, or other demux configured, an assertion panic can occur 

in in6_ether_iffconfig(). [PR686350] 

• On the M120 router , when the no-vrf-propagate-ttl statement is set or deleted, the 

FEB might reboot and dump a core. There is no known workaround. [PR691466] 

• IPv6 access and access-internal routes for IP demux interfaces are not installed 

successfully when the dynamic profile that creates the IP demux interface is configured 

with the router's unnumbered loopback address. This results in the failure of IPv6 

egress traffic forwarding. This problem does not affect IPv4 egress traffic on IP demux 

interfaces. As a workaround, configure the dynamic profile that creates the IP demux 

interface to use a numbered address rather than the router's unnumbered loopback 

address. [PR747029] 

176 



• Filter Based Forwarding is not working for IPv6 traffic. [PR795730] 

• In a L3VPN environment, when PE enabled with composite-nexthop receives a ICMP 

packet from local CE having TTL=1 and "route-record" option destined towards remote 

VPN end, then below messages are seen in syslog of PE router. /kernel: %KERN-3: 

tag_send_nh_chain(): no mbuf after tag_nh_chain_comp_label_output() This syslog 

message doesn't indicate real mbuf issue. Hence this can be treated as non-intrusive. 

[PR811406] 

• A kernel crash may occur on routers running 10.4 or higher (which does not have fix for 

this PR), with "targeted-broadcast" knob configured on a broadcast interface. If this 

knob is configured, MAC address will be learnt for subnet broadcast IP (configured on 

that interface). When this ARP table entry gets timed out, it corrupts an internal data 

structure, leading to kernel crash. This MAC learning will happen with one of the 

following : 1. Mismatched IP subnet is configured on one of the connected devices 2. 

A malformed packet (ARP request to subnet broadcast IP) is received on that interface 

NOTE: - MAC address learnt for the subnet broadcast IP can't be seen using "show 

arp" command. - This issue is platform independent. [PR814507] 

• The Kernel crashes when a DHCP client is connected with a DHCP-relay configuration. 

[PR824470] 


• On logical tunnel (lt) interfaces, you might not be able to use the 'family vpls' option 

at the [edit interfaces lt-fpc/pic/port unit logical-unit-number] hierarchy level. 

[PR44358] 

• 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. [PR65800] 

• On the Juniper Control System (JCS) platform, the control and management traffic 

for all Routing Engines share 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. [PR293126] 

• In a SAToP pseudowire on a 4-port COC3/CSTM1 or 12-port T1/E1/J1 CE PIC, when 

there is data loss from the pseudowire or due to an alarm condition (LOS/LOF/AIS) 

at the peer end of the SAToP pseudowire, the local PIC does not transmit AIS. This PR 

addresses that issue. [PR602563] 

• An interface not defined in the logical system is participating in a VPLS instance 

configured under the logical system. [PR603130] 

• A panic occurs in rnh_index_alloc on the backup Routing Engine because the index is 

already allocated. In the system log or kernel message buffer, a message similar to the 

following may be seen: "rnh_cont_request: demux0.14 (3353) Got nhid=120882 

but already have child nhid=118652 for cifl ge-0/1/5.32767 (3349)." [PR682967] 

• When multiple vendor specific tags are included in PPPoE control packets, only the 

last of these tags are parsed by the PPPoE server for ACI/ARI and DSL Forum 

information. [PR689222] 


177


• In scaled configuration having 1000 vrrp groups, user can see messages like 

ppman_vrrpman_change_xmit_status on the backup vrrp router with the repeated 

Routing Engine switchover. [PR719560] 

• If packets are dropped due to high scaling rates, some protocol buffers might be leaked, 

causing an increase in the memory utilization of the PPP subscriber services daemon, 

which might eventually lead to the inability to log in additional PPPoE clients. 

[PR731963] 

• When child lsq interface comes before parent rlsq ifl interfaces, the cosd is indirectly 

adding parent ifls to cosd ifl database. In this flow of code the parent ifl is not added 

to the snmpif database in the cos module. This causes failures when pooling for parent 

interface queue counters. The same thing is true for AE ifls. [PR733411] 

• With a large number of PPPoE subscribers, a queue overflow occurs when a burst of 

PPP control packets are received. As a consequence, the PPPoE session cannot be 

established while bringing up subscribers because the system drops control packets 

during PPP negotiation. Also, when the subscriber sessions are up, the system loses 

LCP echo replies from the client and over time this might cause keepalive failures. This 

is caused by the improper PPP packet queue size set in the kernel. [PR735769] 

• IP header compression (VJ compression) is not rejected by PPP LCP. [PR737981] 

• PPPoE access-internal routes not cleaned up correctly. [PR739869] 

• Some error situation may create a scenario where peer backup router wrongly moving 

to master and sending a lower priority packet. We won't create the adjacency for Inherit 

groups any more. We will drop these packet in the Packet Forwarding Engine using this 

PR 742082. So you won't see these messages again. [Feb 18 13:12:54.568 LOG: Err] 

vrrpman_process_new_pkt_msg: Recv new priority pkt for inherit group. Ignore it. Group 

2, IP-Ver 0, If_index 141074, priority 100 [PR742082] 

• In a scenario where all PPPoE sessions attempt to reconnect simultaneously at a high 

rate, typically following a reboot or maintenance, it has been observed that the PPPoE 

daemon might get into a situation where it runs out of memory and fails to create new 

sessions. The system would be under a lot of stress due to reconnect attempts leading 

to this problem. A message similar to "allocateSession: no memory for dynamic 

allocation UIFL xe-5/0/1.1073806881" shows up in the log when PPPoE traceoptions 

are enabled. [PR747586] 

• This issue is specific to the M120 hardware since there are two independent FRU's from 

where the PIC needs to be detached/attached. This IPC messages goes out-of-order 

due to the additional control-plane messages related to routing-change as a result of 

PIC restart which happens in this case due to the buffer configuration change. When 

PIC needs to be detached and at the same time there are still a lot of protocol 

information which should be process as well, the ?detached? messages will NOT be 

able to be delivered in time. After PIC restarts it request to be attached again but 

obviously this action failed because from other FRU?s perspective the PIC has NOT 

been detached at all. [PR773081] 

• Occasionally, an MX Series router that is connected to a customer premises equipment 

(CPE) using PPP fails to send an LCP configure-ack/IPCP configure-ack for the first 

LCP configure-request/IPCP configure-request received from the CPE. For LCP, this 

178 



occurs when the MX Series router receives the LCP configure-request from the CPE 

soon after sending PADS to the CPE. In the case of IPCP, this occurs when the router 

receives IPCP configure-request from the CPE while PPP connection is transitioning 

to the next step for configuring Layer 3 protocols using NCP. [PR773950] 

• With multiple nondefault routing instance configuration, jpppd seems to bring up the 

subscribers fine to ACTIVE state but the access-internal routes are not added to all 

subscribers. It appears as if only the first nondefault RI subscribers might have the 

routes installed and the rest of them have no routes. [PR775715] 

• LCP is terminated after LCP negotiation is finished successfully when you use static 

PPP interfaces, and the intention is to use static IP addressing on the subscriber CPE. 

To make this work, a configuration like below is needed: 

interfaces { 

pp0 { 

unit 14 { 

pppoe-options { 

underlying-interface ge-5/2/0.612; 

server; 

} 

keepalives interval 10 up-count 3 down-count 3; 

family inet { 

address 1.1.9.1/32 { 

destination 0.0.0.0 ### Gives a hint for static addressing on subscriber side 

} 

} 

} 

} 

[PR777042] 

• PPPoE sessions remain stuck in "init" state. [PR779047] 

• Junos OS Release 11.4X27 does not support unified in-service software upgrades (unified 

ISSU) for configurations that include interface sets. [PR-779377] 

• In a DHCPv6oPPPoE environment, DHCPv6 bindings are terminated if the IPv6 address 

is removed or added on a static IPv6 interface, not related to the PPPoE configuration. 

[PR780607] 

• In MLPPP scenario, in rare conditions (such as FPC crash), kernel may try to delete a 

MLPPP bundle with an invalid (although within the max bundle limit) bundle ID. This 

will casue vmcore and Routing Engine switchover. [PR780784] 

• In a PPPoE environment, the router might not be able to process any PADI (PPPoE 

Active Discovery Initiation) packets. This is caused by PPPoED memory leak issue. 

[PR781985] 

• On the fxp0 interface, when speed is configured at 10m for a full-duplex network, the 

following log message is generated: 

fxp0: Full duplex link mode is not supported with speed 10M, Hence Speed will default 

to 100M 

[PR791777] 


179


• When you configure the untagged GE interface or untagged aggregate ethernet with 

link member on IQ PIC with per-unit-scheduler, this might cause the failure of interface 

statistics on this interface. As a result the following error will be reported in the log 

message and on "show interface extensive" outputs. [PR794975] 

• Continuously walking SNMP MIBs while PPP subscribers log in and out of the router 

causes the PPPoE daemon to go unresponsive due to synchronous retrieval of SNMP 

MIBs take larger time and blocking signals to be serviced by PPPoE daemon. Subscribers 

can no longer log into the router. The daemon will remain unresponsive as follows until 

it is restarted. 

user@router> show pppoe statistics 

error: the pppoe subsystem is not responding to management requests 

The SNMP MIBs being walked are as follows: 

1.3.6.1.4.1.2636.3.68.1.1 (jnxPPPObjects) 1.3.6.1.4.1.2636.3.67.1 (jnxPPPoEMIB) 

1.3.6.1.4.1.2636.3.64.1.1 (jnxSubscriberObjects) 

1.3.6.1.4.1.2636.3.12.1.1.1 (jnxIpv4AddrEntry) 

1.3.6.1.4.1.2636.3.51.1.1 (jnxUserAAAObjects) 

[PR795556] 

• jpppoed memory utilization spikes after GRES or jpppoed restart event. [PR800650] 

• In PPPoE subscriber management environment, during subscribers logging in, PPP 

daemon (jpppd) might leak memory due to following software issues: 

• During PPPoE subscribers logging in who use CHAP authentication method, if the 

CHAP protocol taking longer than 30 seconds to negotiate, PPPoE daemon (pppoed) 

will try to delete the underlying logical interface (IFL) through which the subscribers 

log in. Then pppd process try to remove the subscriber entry (which involves ensuring 

the IFL is correctly deleted). But sometimes jpppd will not remove some of the 

memory associated with the subscriber and cause jpppd memory leak. 

• Because software defect in PPP protocol NCP negotiation stage, jpppd process may 

leak pending buffers during subscribers logging in. 

The memory leak of jpppd process could be observed by following command (The 

RES field means "Current amount of resident memory, in kilobytes"): user@router> 

show system processes extensive | match "PID | jppp" PID USERNAME THR PRI NICE 

SIZE RES STATE TIME WCPU COMMAND 1460 root 3 20 0 66912K 37420K sigwai 

20:17 0.00% jpppd [PR802915] 

• With LSQ interface, the MLPPP fragments cannot use the egress queue 4 to 7 on the 

MLPPP member links. There is no workaround. [PR805307] 

• In subscriber management environment, with either 'pppoe-underlying-options' or 

'advisory-options' or both of them configured for Ethernet interface, after each login 

and logout of a DHCP/PPPOE subscriber, it has some memory leak in kernel. After 

some time, BRAS starts to reject new sessions and needs to be restarted to restore its 

operation. The memory leak occurs in the Routing Engine kernel can be observed by 

following commands: 

Or 

user@router> show system virtual-memory | match iflog 

iflogical 1471864 281335K - 17671778 16,32,64,256,4096,16384,32768,262144,524288 

180 



user@router> show chassis routing-engine 

Routing Engine status: 

Slot 0: 

Current state Master 

Election priority Backup 

Temperature 36 degrees C / 96 degrees F 

CPU temperature 42 degrees C / 107 degrees F 

DRAM 3584 MB 

Memory utilization 81 percent < ----------------------------- 

[PR807838] 

• VC powerdown of VCMm leaves Ip demux interfaces in a "hardware-down" state 

[PR813902] 

• Warning message added is syslog when external sync is not supported. [PR817049] 

• If per-unit-schedular is configured under a physical interface(ifd), and trying to delete 

this ifd and its sub-interfaces (ifl) in one single commmit, ksyncd may core in the backup 

Routing Engine which will cause GRES malfunction. [PR827772] 

• Currently, no SNMP trap sent when backup SPMB failure happened. This PR is meant 

to enable the SNMP trap for such failure. [PR835167] 

• ERA events are not credited back by jpppoed. ERA has a purge timer of 10 minutes 

which reclaims stale events so new connections are allowed after the purge timer fires. 

In a high scaled scenario this can lead to slow PPPoE connections. [PR842935] 

• When packet has to be forwarded over NH topology unilist->indirect-indexed and 

when the packet size is greater than egress interface MTU w/ DF set, then we may log 

the following message and not send the message back to source indicating "frag 

needed and DF set". fpc0 NH: Can not find ifl for nh 1048590 fpc0 NH(nh_get_mtu_iff) 

: get unilist mtu failed [PR844987] 

• The device configuration daemon (dcd) may crash when a partial demux subinterface 

configuration is attempted to be committed. There is no impact to traffic forwarding 

but before the configuration can be committed, it must provide a valid 

'underlying-interface' for the demux subinterface. [PR852162] 

• On T Series routers the kmd process gets started on the backup Routing Engine and 

fails to connect to PIC and add manual security association to kernel giving a kmd logs 

error message to syslog/kmd logs as follows: “KMD_INTERNAL_ERROR.” This will not 

affect any ipsec functionality. [PR854975] 


• For the following functionality, the J-Web interface is not launching up at workspace 

( Configure >Point >Protocols >Configure >Ospf3) . 

As a workaround, configure ospf3 (for example: set protocols ospf3 area 0.0.0.0 

interface fe-1/3/0) as follows on the CLI: 

• On the J-Web interface click on Configure >Point 

• Select Configuration Tree View >Protocol and click on expand button. 

• It display the configured CLI osfp3 parameters. 


181


• Click on area/prefix/interface option on the Tree View tab. 

• At work space it display the selected options required parameters. 

• At work space it display the selected options required parameters. 

• At workspace can perform add,edit,delete,commit operations 

[PR857540] 

Layer 2 Features 

• In L2vpn scenario, if there is no mpls route to neighbor and there is a static route with 

discard nexthop in inet.3 table as follows: 

user@router# show routing-options 

rib inet.3 { 

static { 

route 0.0.0.0/0 discard; 

} 

} 

Then the L2vpn connection will use the above static route in inet.3 table to connect 

its neighbor as follows: 

user@router# run show route table mpls 

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = 

Last Active, * = Both 

0 *[MPLS/0] 00:01:42, metric 1 

Receive 

1 *[MPLS/0] 00:01:42, metric 1 

Receive 

2 *[MPLS/0] 00:01:42, metric 1 

Receive 1 

3 *[MPLS/0] 00:01:42, metric 1 

Receive 

ge-0/0/1.601 *[L2VPN/7] 00:01:38, metric2 0 

Discard 

In this situation, routing protocol daemon (rpd) generates a core file while walking 

snmp mib 'jnxVpnPwEntry'.[PR816821] 


• DHCP Server Identifier (option 54) in a Request changes from server ip address to 

Giaddr address. [PR729833] 

• The DHCPv6 server application may not properly process DHCPv6 packets when 

Option 18 (DHCPv6 Interface-ID) and Option 37 (DHCPv6 Relay Agent Remote-ID) 

are received in the same packet. [PR774631] 

• DHCP server in a vrf responds with incorrect server identification address option 54 in 

DHCPOFFER. [PR776222] 

• Extracting option-37 (remote id) might cause an overflow that corrupts other data. 

The result is a failure of RADIUS account message. [PR777157] 

182 



• The AFTR information from RADIUS is advertised by MX Series router to the client via 

DHCPv6. [PR779679] 

• The old dhcp session still can be renewed by client after client move to another vlan. 

[PR784951] 

• In an MX Series Virtual Chassis environment, a traffic outage longer than 2 minutes 

occurs when a member of the VC-M LAG fails while LACP is in active mode with link 

protection on the VC-M router. The outage occurs while the LACP process restarts on 

the new VC-M router. To avoid this situation, make sure that LACP is running in active 

link protection mode on the device in front of the VC-M router. This device cannot be 

an EX Series Ethernet Switch, because the switch does not support LACP in link 

protection mode. [PR784965] 

• DHCP may fail to delete both routes for a DHCPv6 client, leaving the client stuck in the 

RELEASING state. When a client binds successfully after requesting both an address 

(IA_NA option) and a prefix (IA_PD option), two routes are added for the client. If only 

one of the routes is deleted and DHCP fails to properly retry the failed route deletion, 

the client remains in the RELEASING state. [PR784977] 

• DHCP relay does not forward ACK to client from the backup DHCP server after primary 

DHCP server failure. [PR799090] 

• To free the socket used by jdhcpd for bootp helper deactivate dhcp-service traceoptions. 

[PR817515] 

• In scenario where DHCP stray request is recieved on MX acting as DHCP relay and 

authenticaiton for this request fails, MX is generating DHCP NACK back to DHCP client 

[PR835794] 

Multiprotocol Label Switching (MPLS) 

• For point-to-multipoint LSPs configured for VPLS, the "ping mpls" command reports 

100 percent packet loss even though the VPLS connection is active. [PR287990] 

• The malformed packet is due to inconsistent handling of internal flag of the MX 3D 

platform when performing L2VPN switching of packets that have MPLS with 2 or more 

labels as layer3 inside ethernet (e.g. switching L3VPN over L2VPN). In this situation 

EOS bit is erroneously not getting set on the imposed label, resulting in the receiver 

interpreting the start of payload as one more label. [PR684256] 

• The RPD process may crash when executing the command clear mpls lsp name 

or monitor label-switched-path [PR756551] 

• If ldp-tunneling is configured on an LSP, and the router receives thousands of LDP 

routes through this LSP, and additionally the router has a large number of FPCs 

(especially in multi-chassis platform), during MPLS statistics collection, it is possible 

to see packets drop or delay on the link connect the Routing Engine with the Packet 

Forwarding Engine. If auto-bandwidth is enabled for the LSP, then auto-bandwidth 

will work incorrectly. Below kernel message type could be seen when issue happens: 

/kernel: rpd pid 16252 tid 100130 syscall 133 ran for 568 ms And also too much kernel 

resource was occupied once the issue happened, the Routing Engine based keep-alive 

processing could be impacted over the syscall period. bfdd[4325]: 


183


BFDD_TRAP_MHOP_STATE_DOWN: local discriminator: 1715, new state: down, peer 

addr: x.x.x.x [PR785360] 


• SNMP selects the first valid configured IP address on the loopback interfaces for the 

source address of SNMP Trap. It should select the lowest valid IP address configured 

on the loopback address [PR729699] 

• Junos OS Releases later than 10.0 reserves separate index pool for private and public 

interfaces. After an upgrade from version prior to 10.0 to version later than 10.0, some 

of the public interfaces may be included within the private index pool. There is no 

operational risk caused by this issue. [PR815028] 

• On MX 960 router after committing the load merge command, commit logs gets flooded 

with "/var/log/interfaces-log.0: No such file or directory." This issue happens when a 

burst of traces is triggered by an event (commit in this case). If the max tracefile size 

is configured to a low value, then this leads to a race condition during log rotation. This 

issue can be prevented by increasing the max size of the traceoptions file. [PR820322] 

• The default maximum log file size depends on the platform type for TX-Matrix or 

TX-Matrix Plus routers it is expected to be 10 MB. However, due to a software defect 

this file size was only 1 MB. [PR823143] 

Platform and Infrastructure 

• Junos OS 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 ] 

hierarchy level. [PR237107] 

• Following a large output with jcs:get-input() will truncate the output after the 

---(more)--- prompt and cause all following user input to be hidden. As a workaround, 

add the | no-more option when executing op scripts. [PR473816] 

• Commit time warning is changed to trace message. [PR480082] 

• Enabling MAC Learning on interfaces for MPC cards throws errors. The error message 

has been found to be harmless. It has been reduced to the level of debug. No 

functionality change is required. [PR569800] 

• With 'chassis route-memory-enhanced' knob (or 'chassis memory-enhanced') is 

enabled, when there is a route change, the route may not be changed accordingly on 

the forwarding table. This may cause traffic black holes. This is caused by memory 

corruption issue on the Packet Forwarding Engine due to an incorrect jtree memory 

free. [PR683024] 

• You might see zombie processes increment while doing commit each time [PR692382] 

• mgd core at gram_make_object upon load config [PR708306] 

• When Graceful Routing Engine Switchover (GRES) is enabled, the firewall configuration 

might not synchronize properly, and this might cause traffic drop and even FPC crash 

184 



after GRES switchover. A reboot of the line card is needed to clear this state and restore 

the issue. [PR708411] 

• When cscript data memory limit is exceeded when executing op, event or commit 

script, the cscript process could reset and leave a core file when failing to allocate 

memory past its limits. The script would not succeed to run, in the case of a commit 

script the commit would not succeed. [PR722161] 

• When tagged traffic is sent on an untagged interface, which is part of a bridge-domain 

or vpls instance with shared vlan learning (vlan-id all), traffic is learned on VLAN-ID 

4096 instead of the incoming vlan-id. [PR733877] 

• The output of the "file list detail" command can display a capital 'S' instead of a lower 

case 's' for the file or directory permission. The system shell output, however, displays 

the correct values. [PR736474] 

• The "request system zeroize" command deletes the /var/db/scripts directory and all 

subdirectories but does not re-create them. The directories and subdirectories need 

to be manually re-created via the root shell and the correct permission set. [PR736478] 

• Ifmon process might restart creating a coredump if the "monitor interface" command 

is issued multiple times within a short interval. [PR789262] 

• In 11.2 L3 services over MC-LAG are supported through IRB only and thus family inet is 

not supported directly on MC-LAG interface. However, appropriate commit check is 

missing in 11.2R3 and later maintenance releases of 11.2 [PR802938] 

• If set and delete configuration is done repeatedly on the management session for a 

long time, cli process will keep consuming memory during operation and could reach 

to the upper limit of it's available memory. [PR813673] 

• Commit may fail, when a config object is deleted and re-added as transient change 

from a commit script. [PR814796] 

• Tunnel services (MT-x/x) using MPC on PE installs (S,G) route on receiving IGMP report. 

[PR821893] 

• IPv6 traceroute is not setting traffic class with TOS command. Traceroute packets 

may not get to the correct queue and the COS bits may not be reflected properly in 

the traceroute outputs. [PR835359] 

• This applies to all Juniper M/MX and T-Series routers. In certain GRES scenarios, the 

backup Routing Engine may not have the complete state of the NH database from the 

active Routing Engine and may send duplicate NH add messages to the Packet 

Forwarding Engine with same NH Ids when it becomes active. This could potentially 

cause undesirable behavior in forwarding resulting in broken forwarding state and/or 

FPC cores. To limit the affect of these duplicate NH add messages, only certain 

duplicate NH adds messages which can be handled gracefully are allowed and all 

other duplicate add messages are rejected. The following table lists the NH types that 

support duplicate NH adds. 

+--------------+---------+--------+--------+---------+-----------+--------+ 

|New --> | RNH_ | RNH_ | RNH_ | RNH_ | RNH_ | Rest | 

|Old | UNICAST | REJECT | HOLD | DISCARD | AGGREGATE | of RNH | 


185


| | | | | | | | | 

| \|/ | | | | | | | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

| | | | | | Reject if | | |RNH_UNICAST | Allow | Allow | Allow | Allow | child; | Reject | 

| | | | | | otherwise | | 

| | | | | | Accept | | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

|RNH_REJECT | Allow | Allow | Reject | Allow | Allow | Reject | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

|RNH_HOLD | Allow | Reject | Allow | Allow | Allow | Reject | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

|RNH_DISCARD | Allow | Allow | Allow | Allow | Allow | Allow | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

| |Allow if | | | | | | 

|RNH_AGGREGATE |DELETE_ | Allow | Allow | Allow | Allow | Reject | 

| |CHILD; | | | | | | 

| |Otherwise| | | | | | 

| |Reject | | | | | | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

|Rest of RNH | Reject | Reject | Reject | Allow | Reject | Reject | 

+--------------+---------+--------+--------+---------+-----------+--------+ 

There is no workaround for this problem. [PR843907] 


• When you configure damping globally and use the import policy to prevent damping 

for specific routes, and a peer sends a new route that has 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 nondefault setting. As a result, damping 

settings do not change appropriately when the route attributes change. [PR51975] 

• In some scenarios MVPN-routes with same RD:Prefix may get generated from 

multiple-VRFs on a PE-router. When such a PE-router is not a MVPN-RR and has no 

MVPN-EBGP peers, it is possible that the core-network may lose the MVPN-route 

because of an erroneous MVPN-withdrawal sent by the PE because of the MVPN-route 

getting deleted from one of the PE VRFs; even if there are other-VRFs on the PE still 

advertising the route. [PR698493] 

• BGP family configuration expects that if any more specific configuration--for example 

neighbor vs. group, group vs. global--is present that no family configuration from less 

186 



specific configuration is used. When family route-target advertise-default is configured 

at BGP peer group scope and BGP neighbor scope configuration contained family 

statements, advertise-default should not be propagated. [PR706925] 

• After upgrade to 10.4R9 following messages are seen "Cancelling deferral pp0 index 

131" These messages are not indicative of any problem and only cosmetic [PR742534] 

• The rpd process is reinitialized when you commit a configuration change. When multiple 

reinitializations occur while OSPF is running on the router, the periodic refresh of OSPF 

router LSAs may stop. If the LSAs are not refreshed, the router no longer participates 

in the OSPF routing domain. You can issue the "show ospf database router 

advertising-router router-id extensive | match timer" command to see evidence of the 

issue. In the error state, the output does not include the Gen timer field. [PR/744280: 

This issue has been resolved.] [PR744280] 

• When a subscriber dynamic profile is configured to add access routes, some route 

additions might fail intermittently, preventing those subscribers from forwarding traffic. 

This issue occurs more frequently when the CPU utilization is high. As a workaround, 

do not specify access-internal routes in the dynamic profile. Omitting this configuration 

enables the route additions to occur correctly by means of a different internal 

mechanism. [PR747631] 

• In scaled RIP topology (about 50 RIP neighbors and route injection), with Non-Stop 

Routing (NSR) enabled, after graceful-switchover (GRES), RIP packets will not be sent 

out for few seconds to few minutes. The blackout duration would be vary by number 

of ifls or routes the router has. The following errors could be seen when issue happens: 

Cannot send request for whole table to neighbor ae1.2460: Socket is not connected 

send msg failed: Socket is not connected [PR754140] 

• BFD flaps with AE bundle and 10 ms timer. [PR773101] 

• Routes are not deleted from routing table when interface is deleted. SPF calculation 

was not triggered in one particular code flow after the LSAs are deleted from database. 

SPF calculation is triggered when the LSA is being deleted due to zero links. [PR782029] 

• The routing protocol process (rpd) might crash when doing multiple GRES in 

combination with bgp peer flapping with large number of dampened routes. This is 

observed only when certain sequence criteria are met, but may not be exposed under 

all switchover conditions. [PR793875] 

• In some specific cases spf calculation may be incomplete because of the specific order 

the IS-IS LSP fragments are received. [PR797278] 

• Setting OSPF overload via the configuration sets both the metric field in router LSAs 

as well as te-metric field in opaque LSAs to 65535 or 2^16-1. Since te-metric is a 32-bit 

field, it should be set to 2^32-1. [PR797293] 

• The rdp generates a core file after the Routing Engine switchover. This occurs because 

*G, and S,G asserts created due to duplication of traffic are not handled properly after 

the Routing Engine switchover. 

HW type of chassis/linecard/RE. "ALL" 

Suspected software feature combination. Multicast feature 


187


Describe if any behavior/ change to existing function - Handle the *,G and S,G assert 

properly. 

[PR809338] 

• The autoexported secondary BGP routes that are advertised using "advertise-inactive" 

can miss the flash event; if so, this leaves the deleted secondary route in the stuck 

state. [PR818552] 

• The OSPF route will not be deleted from routing/forwarding table if configuration 

satisfies below simultaneously. 1. Router ID is not specified and it can be changed due 

to interface down. 2. There is an interface where OSPF is not running. Suppose OSPF 

is running on interface A and it is not running on interface B. IP address of interface A 

is selected as router ID. When interface A goes down and router ID is changed to the 

IP address of interface B, OSPF on interface A will lose adjacency to the remote OSPF 

router but router will keep routes learnt via OSPF. [PR820909] 

• Multiple route nexthops will not be returned via SNMP for ipCidrRouteTable object 

[PR831553] 

• It is possible that RPD's higher priority tasks (HPTs) are scheduled to run such that 

lower priority tasks (LPTs) may not be able to complete until HPTs are completed. 

[PR836197] 

• IS-IS reports prefix-export-limit exceeded even though the number of exported routes 

is smaller than the configured value of prefix-export-limit. [PR844224] 

• In scenarios that use BGP to distribute traffic flow specifications, if the recieved 

flow-spec Network Layer Reachability Information (NLRI) contains invalid argument 

(such as dscp is larger that 63), routing protocol daemon (rpd) will generate flow-spec 

routes and install them in the routing table for these NLRIs but these flow routes with 

invalid match conditions are rejected by dynamic firewall daemon (dfwd) from being 

added to the flowspec filters. When issue happens, the following errors could be seen: 

krt_flow_trans_match_config: Failed defining match conditions 

10.0.1.1,1.0.0.1,proto=6,dscp=81 

krt_flow_trans_term_add: Failed adding term 10.0.1.1,1.0.0.1,proto=6,dscp=81 to filter 

0x9504000 - Unknown error: 0 

krt_flow_trans_filter_add: Failed sending transaction (ADD FILTER SINGLE TERM) for 

filter 0x9504000 __flowspec_default_inet__ to add term 

10.0.1.1,1.0.0.1,proto=6,dscp=81 - Invalid argument 

When the BGP peer withdraws these flow routes, they will only be deleted but not 

freed, hence cause memory leak. [PR845039] 

188 




• When you specify a standard application at the [edit security idp idp-policy 

rulebase-ips rule match application] hierarchy level, IDP 

does not detect the attack on the nonstandard port (for example, junos:ftp on port 

85). Whether it is a custom or predefined application, the application name does not 

matter. IDP simply looks at the protocol and port from the application definition. Only 

when traffic matches the protocol and port does IDP try to match or detect against 

the associated attack. [PR477748] 

• When the unit 0 for the multi-services PIC interface is not specified, the "monitor 

interface traffic" command doesn't display input packets number properly for that 

particular ms-I/F. e.g) user@lab# show interfaces ms-1/2/0 unit 1 { family inet; } 

[PR544318] 

• Support for displaying logical system and routing instance for L2TP tunnels (MX Series 

3D Universal Edge Routers)--When you issue the show services l2tp tunnel command 

with the detail or extensive option on either the LAC or LNS, the output now displays 

both the logical system and the routing instance in which the L2TP tunnel is brought 

up. [PR581182] 

• On M Series with L2TP multilink PPP sessions established, the l2tpd (l2tp daemon) 

might dump a core file when 'show services l2tp multilink' command is executed. 

[PR710538] 

• Extensive CLI requests associated with l2tp (show services l2tp ) may result 

in l2tpd process crash [PR755948] 

• The router may experience a dynamic flow capture process (dfcd) core dump when 

a Routing Engine switchover occurs in a highly scaled (100,000 or more subscribers) 

configuration that also has subscriber secure policies enabled. The switchover can 

result from either GRES or unified ISSU. [PR776698] 

• VC-Power up of VCMb chassis/line cards will cause L2tp LAC clients to terminate 

[PR777538] 

• The show services l2tp session 'interface' extension might not work at devices acting 

as L2TP LACs. [PR780651] 

• In L2TP setup with MX series router acting as LAC, if the value used passed from RADIUS 

in VSA "Tunnel-Client-Endpoint" does not exist on the router, Junos OS will send 

SCCRQ message to LNS with random source addresses. [PR788081] 

• When an MX Series router configured as an LNS sends an Access-Request message 

to RADIUS for an LNS subscriber, the LNS now includes the Called-Station-ID-Attribute 

when it receives AVP 21 in the ICRQ message from the LAC. [PR790035] 

• MX LNS does not support CLI command services l2tp session user filter option. 

[PR792239] 

• The clear services l2tp session user command accepts any arbitrary alphanumeric 

characters in place of a user name and the CLI command will drop all l2tp subscribers. 

[PR792631] 


189


• MX CLI allows you to configure "*" for client name in the l2tp access profile leading to 

failure of establishing the l2tp connection. [PR799232] 

• In scenario where MX is acting as LAC and radius server is returning 

tunnel-server-endpoint attribute but NOT returning tunnel-client-endpoing memory 

leak in jl2tpd process can occur. Additionally same memory leak can occur if 

unnumbered loopback attribute is returned from radius for tunneled subscribers. 

[PR800107] 

• Called-station-id always sent by LNS irrespective of configuration on LNS. The knob 

of "excluding" this attribute didnt work. The fix was tested working in 11.4X27.38 

[PR818899] 

• An LNS configuration on MX boxes can be reported as invalid even if it has been 

successfully committed previously. [PR823709] 

• jl2tpd crash _thr_send_sig (thread=0x8a5e000, sig=6) at 

../../../../src/bsd/lib/libthr/thread/thr_kern.c:91 jl2tpd crash exhibited in an enviroment 

where MX480 router was configured as LAC and terminating 500 l2tp subscribers. 

[PR824760] 

• The "hot-standby" CLI knob under [edit interfaces 

redundancy-options] is made hidden for the Redundant Service PIC (RSP) [PR838762] 

• If flow-tap or radius-flow-tap is configured and logging, dfcd may be leaking file 

descriptors. RPD may crash and write a core with a signature like "kern.maxfiles limit 

exceeded by uid 0" due to this issue. [PR842124] 


• The nas-port-extended-format now has an additional value ae-width, listed first. All 

doc references to nas-port-extended-format should include ae-width which can hold 

the ae number. regress@grafton# help apropos ae-width set access profile 

radius options nas-port-extended-format ae-width 

Number of bits for the aggregated ethernet identifier field [edit] regress@grafton# 

...adius radius options nas-port-extended-format ? Possible completions: adapter-width 

Number of bits for the adapter field (0..32 bits) ae-width Number of bits for the 

aggregated ethernet identifier field + apply-groups Groups from which to inherit 

configuration data + apply-groups-except Don't inherit configuration data from these 

groups port-width Number of bits for the port field (0..32 bits) slot-width Number of 

bits for the slot field (0..32 bits) stacked-vlan-width Number of bits for the S-VLAN 

subinterface field (bits) vlan-width Number of bits for the VLAN subinterface field 

(bits) [edit] [PR565353] 

• A Change-of-Authorization request is being NAK-ed on MX80 when a PPP subscriber 

is terminated in a non-default routing-instance. It works as expected if the subscriber 

is terminated in the default routing-instance. [PR704560] 

• In subscriber management environment with Juniper Networks Session and Resource 

Control (SRC) used, if BRAS (MX platforms) recieves an authentication message with 

null AAA message or null attributes in AAA message from SRC while subscribers login, 

the generic authentication service process (authd) may crash and core dump due to 

memory corruption and the subscriber will be stuck in "Terminating" state until the 

190 



system is rebooted. If JSRC provisioning is deactivated, the subscriber will connect 

without any problem. [PR737308] 

• After a large number of concurrent PPP session logouts and GRES operation some 

sessions may not complete logout (services activated from SRC). Sessions eventually 

will time out and clear. [PR742900] 

• If Juniper Networks Session and Resource Control (JSRC) is used to manage subscribers 

policies, when subscribers log out, AAA messages may not be freed by the generic 

authentication service process (authd). So this may result in a memory leak in authd 

daemon. When the max memory is reached, new subscribers will not be able to log in. 

[PR753101] 

• Subscriber management supports three methods for assigning addresses to DHCP 

clients. When multiple methods are configured, the router uses the following precedence 

to determine which address to assign to the client. 1. Address defined on the RADIUS 

server by Internet Assigned Numbers Authority (IANA) vendor ID 4874 attributes 26-4 

(Primary-DNS) and 26-5 (Secondary-DNS). 2. Address defined on the RADIUS server 

by IANA vendor ID 2636 attributes 26-31 (Primary-DNS) and 26-33 (Secondary-DNS). 

3. Address defined in the local address pool on the router. [PR772408] 

• When adding new static DHCP binding where the newly added host address are already 

active in the dynamic DHCP pool, system will continue to use the dynamic mapping 

until it is available. If that subscriber release and reinitiate the DHCP request, the new 

static mapping would not take effect. [PR777257] 

• In scenario where multiple address ranges are used in address assignment pool for 

pppoe subscribers. Problem is exhibited after 1st range address space is exhausted. 

The MX BNG accepts new subscirbers at very low rate (few per minute) while "authd" 

process is running ~90% or Routing Engine CPU [PR778179] 

• Authd attempts to remove VLAN when subscribers are idle but connected [PR789009] 

• The captive portal content delivery service applied on PPPoE subscriber to rewrite 

IPDA is not working. The subscriber traffic is altered but is dropped on MSDPC. 

[PR789368] 

• In subscriber management scenario, if the subscribers (such as PPPoE, DHCP, IPOE) 

login through authenticated dynamic VLAN, after them logout, the authenticated 

dynamic VLAN will be removed, but the corresponding libstats iflstats entry will be left 

which should not be. Finally the memory leak will cause filesystem /mfs full and prevent 

subscribers from login. If issue happens, the following logs could be seen: /kernel: 

ifl(pp0.1073859148): ifl_config not found !!! smid: /mfs capacity 83% smid: /mfs 

capacity 85% authd[13198]: ===== Idle Timeout Exceeded Rid the subscriber ===== 

last message repeated 2409 times smid: /mfs capacity 108% /kernel: pid 13197 

(jdhcpd), uid 0 inumber 24280 on /mfs: filesystem full jdhcpd: 

DH_SVC_LOGIN_FAILURE: DHCP pre-authentication failure for DHCPv4 client SDB 

session 8659554 on incoming interface demux0.1073841747 [PR796299] 

• MX-VC:Authd keeps retrying the attempts to fetch final stats for the logical interfaces 

that are already removed. [PR806104] 

• MX-VC:Authd sends duplicate requests to enable interim accounting in PFED for idle 

timeout configured on VLAN subscriber. [PR806112] 


191


• In subscriber management environment, while recieving a Change of Authorization 

(COA) packet with session ID that is ID of service session and the COA packet doesn't 

contain username, the lookup for the session id finds the service session rather than 

the subscriber session which isn't handled gracefully, then causing authd process crash 

and core dumped. The core files could be seen by executing CLI command "show 

system core-dumps". When issue happens, the following behaviors could be observed: 

user@router> show network-access aaa statistics authentication detail error: the 

general-authentication-service subsystem is not running user@router> show log 

messages %AUTH-3: general-authentication-service (PID 14502) terminated by signal 

number 11. Core dumped! [PR811607] 

• Stale addresses in local address pool. [PR815331] 

• Snmpwalk requests sent to MX returns multiple duplicate records for 

jnxUserAAAAccessPool. [PR840640] 


• The logical router 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. [PR238991] 

• Selecting the Monitor port for any port in the Chassis Viewer page takes the user to 

the common Port Monitoring page instead of the corresponding Monitoring page of 

the selected port. [PR446890] 

• Replace pattern does not work with variables names. [PR477753] 

• Add IPv4/IPV6 Filters does not work as expected with IE. As a workaround, use IE after 

configuring the filters and click APPLY on the summary page. As this action does not 

take you back to the configuration page, navigate back to the IPV4/V6 firewall page 

by clicking the Security > IPv4/v6 firewall pages. [PR543607] 

• User needs to wait until the page is completely loaded before navigating away from 

the current page. [PR567756] 

• The J-Web interface allows the creation of duplicate term names in the Configure > 

Security > Filters > IPV4 Firewall Filters page. But the duplicate entry is not shown in 

the grid. There is no functionality impact on the J-Web interface. [PR574525] 

• Using the IE7 browser, while deleting a user from the Configure > System Properties > 

User Management > Users page on the J-Web interface, the system is not showing 

warning message, whereas in the Firefox browser error messages are shown. 

[PR595932] 

• If you access the J-Web interface using the Microsoft Internet Web browser version 7, 

on the BGP Configuration page (Configure > Routing > BGP), all flags might be shown 

in the Configured Flags list (in the Edit Global Settings window, on the Trace Options 

tab) even though the flags are not configured. As a workaround, use the Mozilla Firefox 

Web browser. [PR603669] 

• On the J-Web interface, next hop column in Monitor > Routing > Route Information 

displays only the interface address and the corresponding IP address is missing. The 

192 



title of the first column displays "static route address" instead of "Destination Address." 

[PR684552] 

• The show routing-instance | display set | display inheritance command does not show 

the correct output with interface configured within routing-instance within group. 

[PR704529] 

• Protected sections of the group hierarchy do not have their protection status displayed 

correctly and are not prevented from adding new elements into existing groups. 

[PR717527] 

• The annotate command was not valid under firewall filter then hierarchy level and 

displayed "No valid completions" , and lead to the configuration could not be committed 

under edit private mode . 

[edit] 

liutao@mx480-a-re1# show | compare 

[edit firewall family inet filter LOOPBACK-OUTBOUND term allow-ipv6 then] 

+ /* Don't process the packet here; it's IPv6, not IPv4. 

+ * Accept it and have it be processed by the IPv6 ACL. */ 

accept; 

syntax error. 

liutao@mx480-a-re1# commit full 

[edit firewall family inet filter LOOPBACK-OUTBOUND term allow-ipv6 then] 

'accept' 

outgoing comment does not match patch: 

[PR812111] 

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. [PR32763] 

• Junos Os Release 11.4x26.1 upgrade may fail if PIM MVPN instance does not have the 

vpn-group-address configured. [PR753863] 

• UMH selection should select the highest IP address as the Upstream PE. However, in 

the code the highest IP address is selected by comparing lowest order byte of the IP 

address first. In this case between IP address 10.233.38.34 and IP address 10.233.32.46 

- 10.233.32.46 gets chosen as upstream PE because its lowest order byte (46) is more 

than the lowest order bye of 10.233.38.34. This is because code does not account for 

the endian-ness of the machine it is run on. Fix - convert the IP address to network 

order before comparing. [PR754114] 

• Deleted logical interfaces might not be freed due to references in MVPN. [PR851265] 


193


Resolved Issues 


• After changing cos configuration and restarting cosd, cosd can get into a state where 

a traffic-control-profile is freed but its configuration database is still holding a reference 

to it. This results in staled pointer reference and causes cosd to crash. Restarting cosd 

will result in another crash. [PR738983: This issue has been resolved.] 


• If both Routing Engines (REs) have same Junos OS and Graceful Routing Engine 

Switchover (GRES) is enabled, filters attached to the Interface Logicals (IFLs) will get 

jumbled upon the Routing Engine switchover. This issue is fixed via this PR. If both REs 

have different Junos OS, and GRES is enabled, then we could still see similar problem. 

This behavior is not fixed via this PR as it is a non recommended way of Junos OS 

upgrade. In such upgrades, GRES needs to be disabled. [PR749463: This issue has been 

resolved.] 


• cgatool should not be part of jkernel-common.manifest.in Whoever product that 

requires cgatool would need to package jcrypto.manifest Currently, 

jkernel-common.manifest.in is used by both jkernel-qfx and jkernel-ppc. jkernel-qfx 

doesn't require cgatool to be in jkernel-common.manifest.in. Need same confirmation 

from jkernel-ppc.manifest. [PR549623: This issue has been resolved.] 

• When an MS-DPC PIC reboots due to a crash or manual intervention, it might get stuck 

in a booting loop if the MS-DPC up-time is more than 49 days and 17 hours. After 5 

consecutive boot failures, the MS-DPC PIC will go offline automatically and gives the 

following error message: [ 15:21:22.344 LOG: Err] ICHIP(0): SPI4 Training failed while 

waiting for PLL to get locked, ichip_sra_spi4_rx_snk_init_status_clk [ 15:21:22.344 LOG: 

Err] CMSPC: I-Chip(0) SPI4 Rx Sink init status clock failed, cmsdpc_spi4_init [ 

15:21:22.344 LOG: Err] CMX: I(0) ASIC SPI4 init failed [ 15:21:22.379 LOG: Err] Node for 

service control ifl 68, is already present [ 15:21:23.207 LOG: Err] ASER0 SPI-4 XLR 

source core OOF did not go low in 20ms. [ 15:21:23.208 LOG: Err] ASER/XLR0 spi4 stop 

src train failed! [ 15:21:23.208 LOG: Err] ASER0 XLR SPI-4 sink core DPA incomplete 

in 20ms. [ 15:21:23.208 LOG: Err] ASER/XLR0 spi4 sink core init failed! [ 15:21:24.465 

LOG: Err] ICHIP(0): SPI4 Stats Unexpected 2'b 11 Error, isra_spi4_parse_panic_errors [ 

15:21:24.465 LOG: Err] ICHIP(0): SPI4 Tx Lost Sync Error, isra_spi4_parse_panic_errors 

In order to recover from this state the whole MS-DPC needs to be rebooted. [PR828649: 


• When the transit traceroute packets with ttl=1 are received on the LSI interface, you 

may retrieve the Source Address from the LSI interface to reply ICMP. As LSI does not 

have any IFA, it will use first the IFA in routing-instance to reply. So Source Address 

used was the first IFA added in VPN routing-instance. As a workaround, if the incoming 

interface is LSI, then retrieve Source Address from the logical interface which is having 

the Destination IP Address. This will make sure we reply with Source Address from 

CE-facing the logical interface. [PR839920: This issue has been resolved.] 

194 



• VC-Subscriber license change not updated to all the Routing Engine's in back up 

members. [PR835039: This issue has been resolved.] 

• After the Routing Engine switchover or a reboot, MLFR interfaces may not send MVPN 

data to all downstream receivers. [PR787168: This issue has been resolved.] 

• When an FPC gone bad due to hardware failure is stuck in a boot mode, it might affect 

the communication between the routing engine and the Packet Forwarding Engine on 

for other FPCs. [PR831233: This issue has been resolved.] 

• A feature to supportOSI/CLNS type frames on Trinity platform was added in 11.2R1, 

and this feature is not supported on ichip based DPC. Despite DPC not supporting CLNS 

type next-hops, the following log message is seen: > $ zcat messages.log.gz | grep 

50556 > Sep 20 02:27:52 r2 fpc0 Table nexthop for unsupported proto. NH(50556) 

CLNP:2617 > Sep 20 02:27:52 r2 fpc1 Table nexthop for unsupported proto. 

NH(50556) CLNP:2617 > Sep 20 02:27:52 r2 fpc3 Table nexthop for unsupported 

proto. NH(50556) CLNP:2617 > Sep 20 02:53:20 r2 fpc0 NH: Failed to find nh 

(50556) for deletion > Sep 20 02:53:20 r2 fpc1 NH: Failed to find nh (50556) for 

deletion > Sep 20 02:53:20 r2 fpc3 NH: Failed to find nh (50556) for deletion This fix 

masks this log message for DPC. [PR680782: This issue has been resolved.] 

• After a software upgrade to Junos OS Release 11.4R3 or later, a "xe" interface may 

report "L2 channel errors" when issue show interface extensive. We have seen this issue 

when the xe interface is part of an "ae" bundle. [PR800634: This issue has been 

resolved.] 

• On TX Series system platforms, under very special corner case condition, non-enhanced 

FPCs might drop most of the traffic send into the fabric. TXP Platforms are not exposed 

to this symptom. You will see lots of fabric drops reported via the show pfe statistics 

traffic or show class-of-service fabric statistics command. FPC affected needs to be 

restarted to recover from this condition. Sometimes you might also see the following 

error log reported in the syslog. LOG: Err] NFAB(1/1): RODR offset overflow count 

incremented (65) LOG: Err] CMALARM: Error (code: 542, type:Minor) encountered, 

cmalarm_passive_alarm_signal LOG: Err] NFAB(1/1): PKTR ICELL signature error counter 

incremented [PR805682: This issue has been resolved.] 

• L2ald process may crash, during issue with core-dump and will fail to start the process. 

[PR731147: This issue has been resolved.] 


• On T640 router the in-service software upgrade process fails and generates an error 

message. This is because there was a failure in configuration synchronization. 



• Multicast traffic drops can occur if one of child links of Aggregated Ethernet (AE) bundle 

failed. [PR779238: This issue has been resolved.] 

• If a router is configured with a POSIX compliant time-zone string it does not update 

the time zone correctly. Problem can be observed in system logs and CLI commands 


195


when date/time zone is referenced. set groups re0 system time-zone 

EST5EDT,M10.3.0/2,M2.3.0/2 The router will incorrectly reference the previously 

configured time zone. After time zone configuration modifications run commit full. 


• Over time when routing-table instances is added and removed, when the global index 

allocated to a route-table reaches around 36730, the default route-table (inet.0), 

having index 0 always, could be wrongly allocated to a newly added instance. After 

this corruption to the default routing-instance whenever this default route-table (inet.0) 

is accessed or modified this could result in kernel panic. The fix addresses this corruption 

by adding the default route-table inet.0 (index 0) to the structure tracking all default 

tables in the system, thereby ensuring that this index never gets re-allocated and not 

resulting in this kernel core. The possibility of running into this issue depends solely on 

the rate of adding and removing routing-instances. [PR829412: This issue has been 

resolved.] 


• Under certain circumstances,MX80 may crash when using the command "request 

system snapshot". [PR603468: This issue has been resolved.] 

• On E1 interface, when interface flaps on CE side of connection interface will flap a 

second time on the PE side [PR690403: This issue has been resolved.] 

• The message "NH: nonexistant forwarding nexthop for flood nexthop" occurs when 

the nexthop of member link in aggregate ethernet is deleted before the nexthop of 

aggregate is deleted. There is no operation impact. [PR695659: This issue has been 

resolved.] 

• There can be a mismatch between the ifIndex value on IF-MIB-ifName and the ifIndex 

value on SONET-APS-MIB-apsMapGroupName and apsMapEntry. [PR771877: This 


• Kernel can cache a high incorrect value for stats and is rejecting the correct subsequently 

stats coming from the PIC. The fix consists in checking if the difference of what is 

cached in kernel and what is reported by the PIC is less than an acceptable value. If 

the answer is not kernel does not gets stuck permanently and recovers while fetching 

stats next time. [PR806015: This issue has been resolved.] 

• The hold-time down 300 configuration does not work when alarms appear below 

200ms in 1xOC192/STM64 PICs. [PR815464] 

• The show interfaces redundancy might display secondary as down upon following 

sequence: deactivate R.I.(that contains entire mfr ifls)-->restart fpc(that holds 

secondary MS pic)--> activate the R.I. back [PR816595: This issue has been resolved.] 

• MX's chassis-control interrupt storm falsely reported when a Field Replaceable Unit 

(FRU) is removed, inserted, or FPM button pushed. A FRU may not be recognized/boot, 

resulting in chassis operational failure. [PR823969: This issue has been resolved.] 

• In Junos OS Release 11.4R6 a check of max active planes prevents more than 4 planes 

to become active, therefore, increase-bandwidth, i.e. 6 active planes, can not be 

achieved. This bug exists in 11.4R6 only and will be fixed in 11.4R7. Please advise 

196 



customers who require fabric to operate in increased bandwidth mode skip 11.4R6 from 

their upgrade. [PR833074: This issue has been resolved.] 

• Although physical interface is disabled, reseating 1GbE SFP on MPC/MIC restores its 

output optical power, hence the opposite router interface turns Up(Near-end interface 

is still down). Only 1g-SFP on MPC/MIC has the problem, but 1g-SFP on DPC/MX, EX 

series and 10G-XFP on DPC/MX don't have the problem. When the sfp is reseated, 

then the sfp periodic is going ahead and enabling the laser irrespective of the fact that 

interface has been enabled or disabled. Driver needs to store the state for each sfp link 

and enable laser based on that. This software problem is fixed in 11.4R7, 12.1R6, 12.2R4, 

12.3R2 and later release. [PR836604: This issue has been resolved.] 

• It is possible that when a DPC boots up and link-training fails for all the links between 

fabric planes and the FPC, the interface is still brought up online and traffic blackholing 

will occur. [PR839076: This issue has been resolved.] 

• The logical interfaces are marked with 0 (null) after deactivate system commit 

synchronize and deactivate chassis redundancy which result backup the Routing Engine 

to core [PR840167: This issue has been resolved.] 


• The issue is due to another PR686399, where the DA mac entries on AE are getting 

aged out though the traffic is ingressing on different the Packet Forwarding Engine 's 

of same AE. [PR802924: This issue has been resolved.] 


• It can happen that when changing an interface framing from lan-phy (default) to 

wan-phy and back a few times, the interface doesn't show up any more in "show 

interfaces terse". [PR836382: This issue has been resolved.] 


• Configuration changes to some attributes of the standby secondary path of an MPLS 

label-switched path (LSP) might cause the LSP to flap, which might result in packet 

loss. [PR394184: This issue has been resolved.] 

• For the same P2MP LSP, if the same node is acting as Egress as well as Transit, then 

sometimes traffic can get duplicated at CCC p2mp-receive-switch. This issue is not 

present in Junos OS Release 12.1 onwards. [PR843134: This issue has been resolved.] 


• Incorrect query can cause the Routing Engine CPU to go high. [PR771867: This issue 


• The timestamp year msec command in syslog (not using structured data) is intended 

to include year and msec details in local syslog messages stored in rotating files, but 

not to be included in messages sent to a remote syslog collector. This fix corrects a 

wrong behavior introduced in 11.3R1 where such details were also included in syslog 

messages sent to a remote host. [PR820436: This issue has been resolved.] 


197


• Expand the buffer size and set break point to allow sending out large snmp messages 

due to ospf down event. [PR827660: This issue has been resolved.] 

• On a router with interfaces with Frame Relay encapsulation a SNMP WALK operation 

will cause a MIB daemon (mib2d) crash and will generate a mib2d core-dump. The 

crash itself does not cause any impact on the router as the MIB daemon is restarted 

automatically. The only effect is that a SNMP WALK will never complete successfully. 

user@router-re1> show snmp mib walk 1 | no-more 

sysDescr.0 = Juniper Networks, Inc. mx480 internet router, kernel Junos OS Release 

11.4R6.5 #0: 2012-11-28 21:57:12 UTC 

builder@evenath.juniper.net:/volume/build/junos/11.4/release/11.4R6.5/obj-i 

386/bsd/kernels/JUNIPER/kernel Build date: 2012-11-28 21:39:15 UTC Copyright (c 

sysObjectID.0 = jnxProductNameMX480 

sysUpTime.0 = 339594 sysContact.0 

< .................................... > 

dot3OutPauseFrames.942 = 0 




frDlcmiIfIndex.153 = 153 



frDlcmiState.153 = 6 

Request failed: General error 

user@router-re1> show log messages 

Dec 20 09:23:20 router-re1 clear-log[8240]: logfile cleared 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3-BAD_PAGE_FAULT: pid 7382 (mib2d), 

uid 0: pc 0x810fe09 got a read fault at 0x7c, x86 fault flags = 0x4 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: Trapframe Register Dump: 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: eax: 00000000 ecx: bfbeda88 edx: 

00000000 ebx: bfbeda7c 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: esp: bfbeda60 ebp: bfbeda98 esi: 

089de834 edi: 089fb680 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: eip: 0810fe09 eflags: 00010297 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: cs: 0033 ss: 003b ds: bfbe003b es: 

003b 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: fs: 003b trapno: 0000000c err: 

00000004 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: Page table info for PC address 

0x810fe09: PDE = 0x42e60067, PTE = 5290c425 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: Dumping 16 bytes starting at PC 

address 0x810fe09: 

Dec 20 09:23:38.683 router-re1 /kernel: %KERN-3: 8b 40 7c 89 04 24 e8 5a 3f 2f 00 89 

45 ec 8b 55 

Dec 20 09:23:40.787 router-re1 init: %AUTH-3: mib-process (PID 7382) terminated by 

signal number 11. Core dumped! 

Dec 20 09:23:40.787 router-re1 init: %AUTH-6: mib-process (PID 8247) started 

Dec 20 09:23:40.809 router-re1 mib2d[8247]: 

%DAEMON-5-LIBJSNMP_SA_IPC_REG_ROWS: ns_subagent_register_mibs: registering 

88 rows 

Dec 20 09:23:41.595 router-re1 mib2d[8247]: %DAEMON-6-LIBJSNMP_NS_LOG_INFO: 

INFO: ns_subagent_open_session: NET-SNMP version 5.3.1 AgentX subagent connected 

Dec 20 09:23:43.533 router-re1 dumpd: %USER-5: Core and context for mib2d saved in 

/var/tmp/mib2d.core-tarball.0.tgz 

198 



Dec 20 09:23:43.793 router-re1 mib2d[8247]: %DAEMON-6-SNMP_TRAP_LINK_UP: 

ifIndex 5, ifAdminStatus up(1), ifOperStatus up(1), ifName dsc 

< .................................... > 

user@router-re1> show system core-dumps 

/var/crash/*core*: No such file or directory 

-rw------- 1 root field 680417 Dec 20 09:23 /var/tmp/mib2d.core-tarball.0.tgz 

/var/tmp/pics/*core*: No such file or directory 

/var/crash/kernel.*: No such file or directory 

/tftpboot/corefiles/*core*: No such file or directory 

total 1 



• \n (\ and n as two separate characters) if present in the database, get displayed as 

\\n to the user. [PR705067: This issue has been resolved.] 

• MPC cards may become unresponsive after In Service Software Upgrade (ISSU) is 

completed. This is intermittent and not observed every time ISSU is performed. This 

issue was reported after upgrading Junos OS Release to 11.2R4 release through ISSU. 


• The output of the following commands might show up negative values for Ipkts and 

Opkts counters due to invalid format of output for the variables.: 

• show route forwarding-table vpn interface-name 

• rtinfo 

For example: 

user@test> show route forwarding-table vpn test-vpn interface-name ge-1/0/8 

Name Mtu Network Address Ipkts Ierr Opkts Oerr Coll 

ge-1/0/8 1522 00.1d.b5.27.48.ad -891806008 0 -1176087381 0 0 

The fix also corrects the output format for input and output bytes fields. [PR798999: 


• On TX/TXP multi-chassis systems, time synchronization between SCC/SFC chassis 

and the T640 router chassis, is not maintained. [PR811480: This issue has been 

resolved.] 

• HTTP-get probes fail when routing-instance is used for the probes. Removing 

routing-instance should work. [PR814357: This issue has been resolved.] 

• When two irb interfaces with the same layer 2 trunk interface within the bridge domain, 

multicast replication might be handled incorrect. [PR823435: This issue has been 

resolved.] 

• In CGNAT environment, Source-Address only hash might be getting broken on MPC 

after Service PIC restart. [PR827587: This issue has been resolved.] 

• When using configure private with large group definition and high number of groups 

the commit process can spend a lot of time to merge the configuration change with 

the global configuration. [PR828005: This issue has been resolved.] 


199


• The timestamp in the DDOS_VIOLATION report is not correct. The time the violation 

occured is the time when the message appeared in the log. [PR828085: This issue has 


• When a Trio based card is receiving an IPv6 packet encapsulated in a MPLS stack 

formed by two explicit-null labels (0 ? Ipv4 transport label, 2 ? ipv6 explicit-null label) 

is corrupting it. [PR830209: This issue has been resolved.] 

• With DHCP/BOOTP relay agent configured under [forwarding-options helpers] 

hierarchy, interface flapping will cause forwarding UDP daemon (fud) memory leak. 

The memory usage of fud process could be seen by following command: 

(SIZE: Total memory size of the process (text, data, and stack), in kilobytes) 

user@router> show system processes extensive | match "pid | fud" 

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 

8436 root 2 0 2668K 1708K select 0:03 0.00% 0.00% fud 

user@router> show system processes extensive | match "pid | fud" 

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 

8436 root 2 0 2676K 1716K select 0:03 0.00% 0.00% fud 


• The Junos kernel may crash when a specifically crafted TCP packet is received by the 

Routing Engine on a listening TCP port. TCP traffic traversing the router will not trigger 

this crash. Only TCP packets destined to the router itself, successfully reaching the 

Routing Engine through existing edge and control plane filtering, will be able to cause 

the crash. This issue can be triggered by both IPv4 and IPv6 TCP packets destined to 

the Routing Engine. This issue was found during internal product security testing. The 

Juniper SIRT is not aware of any malicious exploitation of this vulnerability. This issue 

only affects devices running Junos OS 7.6R1 and later. No other Juniper Networks 

products or platforms are affected by this issue. Refer to PSN-2013-01-823 or KB26826 

for more information. [PR839412: This issue has been resolved.] 


• In a scaled setup, with many routing-instances, if the FPCs are restarted, some pim 

encapsulation interfaces (pe) will be marked as down. [PR770213: This issue has been 

resolved.] 

• In an l3vpn configuration, if no-vrf-propagate-ttl is configured under the vrf, rpd can 

core when deactivating or deleting the routing instance vrf with no-vrf-propagate-ttl. 


• Enabling advertise-external knob towards the Route-Reflectors or remote PEs can 

trigger RPD to core if: - "multipath vpn-unequal-cost equal-external-internal" enabled 

in a VRF - a multipath route exists with contributors from iBGP - an external path with 

lower preference (local-preference, as-path, etc) exists in the same VRF [PR823844: 


• During unified ISSU, LACP timeout may occur when time between fpc-upgrade and 

the Routing Engine switchover takes more than 90sec due to large scale config. 


• Any protocol (MVPN,PIM,etc) which does install multicast nexthops and goes through 

a forwarding-table export policy with an install-nexthop policy action will fail to install 

200 



forwarding nexthop and multicast traffic is not forwarded. [PR830448: This issue has 



• SIP ALG was not allowing SIP 603 decline message [PR822679: This issue has been 

resolved.] 

• On an MX 480 router, the TCP ALGs such as FTP/PPTP operations fail on a Services 

PIC/DPC. This caused by the Services PIC/DPC fails to discard expired TCP flows 

causing resources exhaustion which causing failures to create addition NAT flows. 


• Service PIC might crash in routing loops scenarios because of SIP ALG [PR830070: 


• In the case of a stateful proxy, two SIP users behind the NAT device (so-called SIP 

hairpinning) will be unable to signal the call. [PR832364] 

• With RTSP ALG enabled, RTSP keep-alive packets might be dropped if it's already 

Ack'ed by the receiver. [PR834198: This issue has been resolved.] 

• Under some conditions ,MS-DPC may crash when encountered unknown flow-type , 

after the fix , the CRASH behavior at this stage has been removed ,as simply dropping 

the packet will not do any harm. A counter is added to track all such instances when 

unknown flow-type is encountered. [PR834899: This issue has been resolved.] 

• In the case of a transparent proxy, two SIP users behind the NAT device (so-called SIP 

hairpinning) will be able to signal the call, but the RTP voice flow *may* be 

unidirectional if one side started to send his RTP traffic before the port was opened 

on the other end, causing an ICMP unreachable which confuses the NAT device. 


• In scenarios which use sp interface, such as IPSec VPN, multiservice process (mspd) 

will memory leak during sp interface flapping. The memory usage of mspd process 

can be checked by following CLI command: 

user@router> show system processes extensive | match "PID | mspd" (Note: The "RES" 

field means "Current amount of resident memory, in kilobytes") 

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 

2048 root 1 96 0 36216K 34820K select 0:10 0.00% mspd 

When the memory usage of mspd process increases to system limit(about 131072KB), 

the following logs could be seen: 

/kernel: %KERN-5: Process (2048,mspd) attempted to exceed RLIMIT_DATA: attempted 

131076 KB Max 131072 KB 


• Service PIC might crash in corner cases when EIM is enabled for SIP ALG [PR847124: 


• When allocate the memory from shared memory for bitmaps used in port blocks , junos 

request as many bytes as the size of the block. If customers assign like 10K block size 

for deterministic nat or PBA then junos allocate 10K bytes for that bitmap. However, 

it only need 10K/8 bytes as one byte can represent 8 ports. This huge allocations are 


201


leading to memory depletion when many source addresses are behind the NAT, and 

port blocks are big. [PR851724: This issue has been resolved.] 


• The output of the show system users no-resolve command displays the resolved 

hostname. [PR672599: This issue has been resolved.] 

VPNs 

• In a scaled Multicast VPN setup, where many selective provider tunnels are used, and 

the MVPN instance is deleted, RPD can sometimes crash. [PR801667: This issue has 


• For Static PW if user configures "static send-oam", PW will go down (state: Vc-Down) 


Previous Releases 

• Release 11.4R6 on page 202 






• Release 11.3 on page 288 


• Class of Service (CoS) 

• Forwarding and Sampling 

• General Routing 

• Infrastructure 

• Interfaces and Chassis 

• Layer 2 Features 

• Layer 2 Ethernet Services 

• Multiprotocol Label Switching (MPLS) 

• Network Management and Monitoring 

• Platform and Infrastructure 

• Routing Protocols 

• Services Applications 

• User Interface and Configuration 

• VPNs 

202 




• A memory leak in cosd can occur because of one of the cosd 8011p rewrite function 

not releasing memory after use. This results in COSD memory running out of memory 

space thereby resulting in COSD cores continuously. [PR782728: This issue has been 

resolved.] 

• The 802.1Q P-Bits for host generated packets changed from 0 to 6 after upgrading 

from 10.4S6.6 to 11.2R7.4 for DHCPv4 and IPv6. RLI 17837 provided a cos knob for 

setting the 802.1Q bits for host generated packets. This RLI is committed in the branches 

12.2 throttle. This PR will add a subset of the RLI 17837 functionality in 11.2 S7 so that 

Routing Engine can set the 802.1Q bits of host generated packets from the Routing 

Engine. The cli command set class-of-service host-outbound-traffic ieee-802.1 default 

is added by the PR. The class-of-service daemon services this command and 

passes the ieee-802.1 value to the kernel. When this value is set the kernel sets the 

802.1Q P-Bits to this value for all host generated packets. The code changes added 

as part of this PR are a subset of those in 12.2 throttle. These changes only allow for 

setting the 802.1Q in the kernel for host generated packets. This PR does not address 

Packet Forwarding Engine generated host packets [PR795165: This issue has been 

resolved.] 

• During addition/deletion or just deletion of interface configured for shared scheduler, 

some portion of memory is not reclaimed back.Continuous addition/deletion of these 

interfaces results in memory depletion causing packet loss and other issues. [PR803939: 


• On IQ2E PIC, if the logical interfaces under two different interface-sets have their own 

scheduler-map configured, when the same iflset shaping parameters are applied on 

these two interface-sets, the iflset shaping profile is not shared between the 

interface-sets, hence, the number of iflset supported is reduced. There is no workaround. 


• When configured scheduler-map-chassis derived and auto bandwidth computation is 

not success, sosd might crash after the show class-of-service scheduler-map command. 



203



• DCU statistics can be broken on a sub-interface under certain circumstances when 

another sub-interface having DCU enabled gets modified(add/delete/change). By 

DCU statsistics broken it could mean the value gets corrupted, and continue to count 

from there properly or always remain in broken. The circumstances when this issue 

could be triggerd are: - when 2 sub-interfaces have DCU enabled - when the last 16 

bits of the 20 bit sub-interface index are the same - configuration change is made on 

one of these sub-interfaces - other sub-interface could have DCU statistics broken. 

keyword: sub-interface = logical interface = IFL When this happens we can see 

messages like the following being logged on the FPC syslog or messages log file. Aug 

6 11:12:32.649 faraday-re1 fpc4 RT(rt_dest_class_stats_read): unable to read stats (ifl 

196619, IPv4) - Not found Aug 6 11:12:32.723 faraday-re1 fpc1 

RT(rt_dest_class_stats_read): unable to read stats (ifl 196619, IPv4) - Not found Aug 

6 11:12:32.768 faraday-re1 fpc4 RT(rt_dest_class_stats_read): unable to read stats (ifl 

196619, IPv4) - Not found Aug 6 11:12:32.843 faraday-re1 fpc1 

RT(rt_dest_class_stats_read): unable to read stats (ifl 196619, IPv4) - Not found 


• When there are more than 6 members in an aggregate Ethernet, it was observed that 

the traffic for individual member links are not updated with the right statistics, when 

show interface ae Statistics was executed. [PR798334: This issue has been 

resolved.] 

• The message 'ifmon: Failed to find shmlog_dolog8' is logged when monitor interface 

command is executed. [PR799849: This issue has been resolved.] 

• On an MX480 router, after performing GRES on the old master Routing Engine, the 

Packet Forwarding Engine process (pfed) generates the following core file: 0x08121989 

in pfed_conn_event_handler (ls_ipc_session=0x85e6f00, 

event=LIBSTATS_IPC_EVENT_SHUTDOWN. [PR801636: This issue has been resolved.] 

• On MPC sometimes the policer configuration does not get correctly programmed in 

Packet Forwarding Engine. The issue can affect Trio-based platforms with Junos OS 

Release 11.1 and above. It can be triggered by the following steps: 1) An interface-specific 

filter that contains at least a policer is already applied on an interface. 2) The 

parameters of the policer that is included by this filter are changed. Note that the policer 

type change will not trigger this issue, e.g., from term-specific policer to filter-specific 

policer. 3) In the instances of the interface-specific filter created after policer parameter 

change, the policer might not work as expected. Workaround: after 2) and before 3), 

make any change on the interface-specific filters that contain the changed policer. 


• It is possible for the CLI command show pfe statistics traffic to not display any output 

and time out. root@router > show pfe statistics traffic error: the mib-process subsystem 

is not responding to management requests This is because of MIB2D process unable 

to query the statistics information maintained by the Packet Forwarding Engine process 

(pfed) process because of transient errors on the socket between the 2 processes 

204 



used for communication, despite both processes running on the system. This fix 

addresses this issue. [PR826086: This issue has been resolved.] 

• show interface aeXXX detail" may not have correct link information and some statistics 

shown as 0 when there is traffic. [PR828155: This issue has been resolved.] 


• The output of the command show lldp neighbors displays contents of Port-Description 

TLV instead of displaying contents of mandatory PortId TLV. Also the Port Description 

TLV gets generated using Port Name instead of using configured Port Description. 


• ifinfo or show interfaces extensive or show interface ae extensive could fail to complete 

depending on the scale of sub-interfaces. On failing to complete, the following error 

is displayed: rtslib: ERROR Failed to allocate new block of size 16384 and Cannot 

allocate memory This is because of a memory leak in ifinfo process which has been 

addressed. [PR696832: This issue has been resolved.] 

• FPC crashes with show route ip table index # hardware statistics command [PR710756: 


• When large CLI output is displayed the CLI CPU may go high and remain high. The issue 

has been fixed in latest releases. [PR731647: This issue has been resolved.] 

• The crash is triggered by an aggregate Ethernet link flap. The pre-requisite for the crash 

is a forwarding topology with composite nexthop pointing to unilist pointing to an 

aggregated interface(e.g VPLS pseudowire configured on MPLS LSP with node-link 

protection enabled). [PR746509: This issue has been resolved.] 

• In l3vpn setup, customer facing interface fails to forward traffic, If RPF and localization 

is enabled in sequence. [PR752540: This issue has been resolved.] 

• In rare circumstances, events ranging from noise chatter on the XAUI interface to 

unwanted electrical signal transition on the PHY interface might cause the ports on 

the PD-5-10XGE-SFPP PIC to get stuck in the down or up state, effectively dropping 

all the traffic on that port. [PR754344: This issue has been resolved.] 

• DPC might randomly crash during ISSU. It will be kept offline after the ISSU period. 


• Routing protocol daemon (rpd) may crash with core-dump after executing command 

show route community-name with an empty string: show route community-name "" 


• In scenario with indirect nexthop used (such as BGP, L3VPN), under high memory 

usage, in some conditions (such as interface or protocol flapping), the target nexthop 

of indirect nexthop changes between unilist (for example, over aggregate Ethernet 

interface, or need to load balance) and unicast or just between 2 unilist which have 

different nexthop count, Packet Forwarding Engine may dump multiple core files 

because of memory leak or memory corruption. [PR787570: This issue has been 

resolved.] 

• Junos OS Release 11.4 introduced PTP feature and this in turn introduced Periodic 

reading of clocking chip registers over SPI interface. This is a known thing since day 1 


205


of 11.4. With newer chassis (MX80/midRangius) program (MX80-T, MX40-T, MX10-T, 

MX5-T) H/w is reworked to implement SPI reads in h/w and it has significantly reduces 

clksyncd CPU usage to around 1-2% of CPU. [PR789804: This issue has been resolved.] 

• In Junos OS Release 11.4R4, ETH-DM packets greater than 994 bytes fail DMM test. 

The size of default ETH-DM packets is much smaller and bigger ETH-DM packets are 

used only with optional data payload size. For packets sizes less than 994, the 

functionality works fine. [PR790040: This issue has been resolved.] 

• On an EX8200 Virtual Chassis or a switch with redundant Routing Engines, when you 

swap the members of a link aggregation group (LAG), a vmcore or ksyncd core file 

might be created on the backup Routing Engine. [PR793778: This issue has been 

resolved.] 

• It has been observed in the test lab that when there is a prefix and pointing to a 

multipath BGP nexthop (8 in number), and in turn each of this next-hops are pointing 

to multiple MPLS LSPs,the convergence number for 450k routes were in the order of 

15 to 20 minutes. It is also observed that any change in nexthjop, such as the interface 

flapping or neighbor flapping had a significant impact on convergence time computing 

the convergence for this 450 k prefix routes * 64 nexthop (8 paths for each of nexthop). 


• On M/T series platforms, in L3VPN scenario with l3vpn-composite-nexthop enabled, 

while PE recieving packet with DF bit set and packet size is larger than the core-facing 

interface's MTU, FPC/FEB may crash and core dump because of software defect of 

handling composite nexthop which need packet fragment. [PR800155: This issue has 


• When there are multiple recursive routes are available for a prefix such as BGP route 

pointing to a indirect (8) and in turn pointing to a unilist (32) and when this is going 

over an aggregate Ethernet of 8 links, we saw the software going through a large 

computation for each prefix and this makes it worse proportional to number of prefixes. 

At this instance, the system crashes because of the large computation. [PR800157: 


• Forwarding inconsistencies can occur on MX series routers, after a certain specific 

sequence of deleting and adding interfaces. This forwarding inconsistency can be silent, 

or can manifest as an ICMP destination unreachable message being sent to the 

originator of the traffic. [PR800305: This issue has been resolved.] 

• After a software upgrade to Junos OS Release 11.4R3 or later, a "xe" interface may 

report "L2 channel errors" when issue "show interface extensive". We have seen this 

issue when the xe interface is part of an "ae" bundle. [PR800634: This issue has been 

resolved.] 

[MPC] Non-QX cards doesn't tx PPP hellos on wire. [PR801565: This issue has been 

resolved.] 

• jddosd core-dump may be observed because of inefficient code while updating existing 

configuration. This problem has resolved in 11.4R6. [PR810754: This issue has been 

resolved.] 

• The KSYNCD core followed by kernel live core is observed very rarely after Routing 

Engine switchover. This issue can be detected when ksyncd core is observed along 

206 



with below mentioned log message in /var/log/messages. "Aug 27 01:28:03 indiranagar1 

ksyncd[2506]: KSYNCD: resync error, issu_state[0], type Generic config subtype 8 : 

File exists." Reboot the backup Routing Engine. [PR810787: This issue has been 

resolved.] 

• You might encounter transient SLchip error when link flap event occurs. [PR812092: 



• When the delete command is issued on an unnumbered Ethernet user route (static 

route with a qualified next hop ), the destination route created as a part of this user 

route does not get deleted. This results in duplicate ARP entries for the same address. 


• If we flap the interface used as next hop in the forwarding table for the IPv6 remote 

router loopback address used for IPv6 BGP sessions, the session flaps although there 

is another valid route over the other interface. [PR791881: This issue has been resolved.] 

• Router might reboot while running show system core-dump core-file-info command. 

This command uses /tmp and while uncompressing the core file, /tmp file system 

might be exhausted. /tmp in turn uses swap device only. MFS (Memory File System) 

and the rest of OS share the same swap space. Consuming more swap spaces might 

lead to out of memory and swap situation, which could eventually bring down the 

system. [PR808243: This issue has been resolved.] 

• If Routing Engine running in low memory environment, while recieving IP fragmented 

packets which destined to Routing Engine, system may fails to defragment the packets 

and will free the memory of these fragmented packets. But the routine will try to free 

the already freed memory again which is incorrect, and in rare conditions, the freed 

memory may be allocated before the double free process occurs. Then an access to 

the freed memory will cause memory corruption and kernel crash. [PR810434: This 



• After a MX series Routing Engine reboot, the internal em interface may be "link down". 

The fix for this is to monitor the link state of the em interfaces. When a em link is 

discovered to be harddown, re-init the em interface. This fix has been limited to address 

only MX series platforms. [PR611081: This issue has been resolved.] 

• On E1 interface, when interface flaps on CE side of connection interface will flap a 

second time on the PE side [PR690403: This issue has been resolved.] 

• The message "NH: nonexistant forwarding nexthop for flood nexthop" occurs when 

the nexthop of member link in aggregate Ethernet is deleted before the nexthop of 

aggregate is deleted. There is no operation impact. [PR695659: This issue has been 

resolved.] 

• Multiple inbound/outbound IPSEC tunnels seen for a single security association upon 

certain conditions such as router reboot. [PR730174: This issue has been resolved.] 


207


• After a MS-DPC core-dump, it might result in ICHIP "stream blocked detected". Traffic 

flow will be dropped and can only be restored by restarting the DPC. This is because 

of SG FPGA soft reset issue. [PR743262: This issue has been resolved.] 

• You can find MPC/DPC goes to offline state with "Unresponsive" when you rebooted 

all the Routing Engines. *condition MX with Enhanced MX SCB *configration set chassis 

redundancy graceful-switchover [PR744661: This issue has been resolved.] 

• Load average values collected via SNMP do not show the correct values of the other 

Routing Engine. This can be verified by using the following commands: show snmp 

mib walk jnxOperatingEntry | match LoadAvg.9.1.0.0 show snmp mib walk 

jnxOperatingEntry | match LoadAvg.9.2.0.0 [PR782817: This issue has been resolved.] 

• In the environment of composite-next-hop with FMBB (fast make-before-break) 

function (e.g. VPLS, multicast, P2MP LSP), if system is configured with feature which 

contains interface having active/standby links (e.g. RLSQ/AMS/RMS), the Packet 

Forwarding Engine having standby interface might be incorrectly involved when building 

Packet Forwarding Engine flooding tree. This results in traffic blackhole. [PR786007: 


• "show chassis hardware" output for some optics is not correct sometimes. [PR792704: 


• On MX Series routers and PTX Series packet transport switches, a change to the 'oam 

lfm pdu holdtime' on an interface is not updated correctly. This results in an incorrect 

LFM state, which should be reported as Adjacency Lost. As a workaround, issue the 

clear oam ethernet link-fault-management state command from CLI to correctly update 

the 'pdu holdtimer.' [PR792763: This issue has been resolved.] 

• Issue is seen only when the following steps are followed: 1. Enable IRB MAC Sync 

feature. 2. Deactivate BD/MAC Sync/Service ID on the higher MAC node. 3. Activate 

virtual switch that configues MCAE under the virtual switch. The result: IRB MAC Sync 

happens even though the feature is not enabled. [PR793889: This issue has been 

resolved.] 

• An operation in order of PIC offline then deactivate ci member interface will have the 

deactivated member interface join to the ci upon PIC online. And it will cause 

unexpected forwarding issue. [PR803817: This issue has been resolved.] 

• When a hold-time is configured for xe interfaces, before the timer is started, the XFP 

alarm is checked before declaring the link status. As a result, it is possible for the link 

to remain down if there are XFP alarms/warnings as reported by the show interfaces 

diagnostics optics command. [PR804315: This issue has been resolved.] 

• When a PEM module is inserted into a chassis, no message is currently logged in 

/var/log/inventory file. This PR addresses this requirement. On inserting a PEM module 

into a chassis a message in the following format will be logged in file /var/log/inventory 

: PEM - part number , serial 

number eg. Oct 22 14:44:21 PEM 0 - part number 740-123456, serial 

number VK11111 [PR808450: This issue has been resolved.] 

• In Junos OS Releases 11.4R4, and later, the option of routing-engine under request 

system snapshot" was mistakenly removed. [PR809321: This issue has been resolved.] 

208 



• Once a GRES Mastership switch is performed and at some pointer later the FPC is 

rebooted the aggregate interface flag is set to 'down' once FPC comes back online. 

Any traffic which enters this FPC and is send to the aggregate interface via an ECMP 

path will get dropped. ECMP paths without aggregate members are not affected. This 

symptom is applicable on PTX platforms, T4000 systems with T4000-FPC5-3D and 

on MX platforms with TRIO FPCs from Junos OS Release 11.4R3 or higher. To clear the 

condition, flapping the aggregate Ethernet interface in 'Harddown' state such as 

'deactivate' and 'activate interface ae' [PR809383: This issue has been resolved.] 

• Interface damping is not working properly on MPC Type 2 3D [PR810159: This issue has 


• On a MX80, a broadcast storm on fxp0 will cause the process "irq32: tsec2" to consume 

enough CPU that the TFEB restarts. With the fix, the CPU this process is allowed to 

consume is limited to prevent impact to transit traffic. [PR816253: This issue has been 

resolved.] 

• Issue has been analyzed and fix would be available in upcoming releases. [PR817177: 


• When downgrading a Junos OS version, if a particular feature is not supported in the 

target Junos OS Version, then those unsupported features must be deactivated before 

downgrading the Junos OS version. [PR836448: This issue has been resolved] 


• With VPLS using IRB, line card may crash when large changes to interfaces and 

next-hops are processed. It is not deterministic which conditions will trigger the crash. 


• If an vpls interface is moved to an vpls aggregate bundle or changed to any other 

interface family different then vpls,on the next GRES/NSR Mastership switch, this 

interface will have the CCC-Down flag set and will not process any traffic. The interface 

needs to be deactivated and activated via configuration change to continue forwarding 

traffic. [PR788631: This issue has been resolved.] 

• After a physical interface that is configured for CoS on a logical tunnel interface flaps, 

the MAC address of the peering logical interface goes missing from the kernel. To 

resolve this issue, deactivate/activate the peering logical interface after the flap. 


• With many bridge domains or vpls routing instances, MPC may show forwarding 

congestion when clear bridge/vpls mac-table command is issued. [PR799606: This 


• The monitor traffic interface irb operational command fails to capture outgoing packets. 


• Routing engine CPU utilization may increase faster than expected when LDP neighbors 

are configured under a mesh group of a local BGP-VPLS routing instance when the 

LDP neighbors themselves are not provisioned for VPLS service on the remote side. 



209



• LACP status disagreement after Routing Engine switchover. [PR751745: This issue has 


• In Junos OS Releases 11.4R2, and later, there might be a false alarm of a hardware 

problem from a DPC such as, "fpc0 EZ: %PFE-3: 

ezchip_periodic_check_free_rfd_buffer[4245] XETH(0/3) : Rx RFD buffers exhausted" 

This can be ignored, unless traffic impact is seen. [PR796824: This issue has been 

resolved.] 


• If the same route is received from both BGP and IGP (where BGP routes redistributed 

into IGP) and if BGP has a better route preference and then BGP route is flapped at 

least once the IGP route might get marked by LDP and never flushed once the BGP 

route is reinstalled. This leads to stale inactive routes in RIB. There is no harm in having 

inactive route and simply shows an additional route entry in the RIB database. 


• In GRES (graceful Routing Engine switchover) mode and because of a quick status 

change of MPLS CCC nexthop, a mismatch of index value between master and backup 

Routing Engines might happen, causing Backup Routing Engine to panic, generate a 

core file, and trigger a live core dump from master Routing Engine. [PR755473: This 


• The issue appears to happen when MVPN tries to add a vt-interface for an egress 

tunnel. RSVP would try to find the flood nexthop for the route installed for the label 

for the branch LSPs in the P2MP LSP to add the vt-interface. When RSVP does not 

find the flood nexthop for the label route for a branch LSP, it triggers an assertion 

failure. [PR770538: This issue has been resolved.] 

• With the fix of this PR, at the end of the adjust-interval operation, the max_average 

counter does not reset to zero and maintains the old value until it receives a new sample. 

When the new sample is received, the max_average counter is updated to the new 

sample value. This is a just display counter fix and there is no operational impact. The 

auto-bandwidth functionality works as it is. [PR799155: This issue has been resolved.] 

• Some implementations of cSPF allow zero-bw LSPs (LSPs, which are requesting 

bandwidth of 0bps) to be calculated via links which have 0 bps of available bandwidth. 

In some cases implementation of RSVP in Junos OS allows AvailBW on link to become 

negative. This might happen, for example, in case of failure of one of links in ae bundle. 

As it's impossible to include negative values in OpaqLSA, in this case Junos OS 

announces 0 bps of AvailableBW on such links. Zero-bw LSPs will not be established 

via such link, because transit node with negative AvailBW fails check for bandwidth 

availability on egress interface. HeadEnd will constantly try to signal LSP and every 

time it will receive PathErr: BW Unavailable from node which has link with negative 

AvailBW. cSPF calculation will not resolve this, because according to TED on HEnd we 

have 0 bps of AvailBW on this link, not negative. [PR802995: This issue has been 

resolved.] 

210 



• When an aggregate Ethernet link along a path becomes oversubscribed because of 

failure of one or more member links of the aggregate Ethernet link, the ingress of a LSP 

may continue to use the same path although there may be alternate path available 

with sufficient bandwidth. This is so because CSPF algorithm during optimization of 

an existing LSP will continue to see such an over-subscribed link acceptable with 

sufficient available bandwidth. However, if a new LSP with a bandwidth requirement 

is signaled over such a link, the LSP will not get signaled successfully. [PR807670: This 


• With RSVP disabled, when a SNMP get/get-next is received for RSVP MIB, a Path State 

Block (PSB) search request is enqueued, this enqueue operation returns nothing but, 

the memory allocated for the search request is not freed and this results in a memory 

leak of routing protocols daemon (rpd). The memory leak could be observed by the 

following commands: user@router> show task memory detail | match "rsvp psb lookup 

req" ------------------------ Allocator Memory Report ------------------------ Name 

Size Alloc DTP Alloc Alloc MaxAlloc MaxAlloc Size Blocks Bytes Blocks Bytes RSVP 

PSB lookup req 176 180 T 110 19800 110 19800 user@router> show system processes 

extensive | match rpd PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU 

COMMAND 1311 root 1 4 0 1529M 1479M kqread 75:25 0.44% rpd When the memory 

usage of rpd process increases to around 85% of system limit, the following logs could 

be seen: re0: /kernel: %KER-5:Process (1859,rpd) has exceeded 85% of RLIMIT_DATA: 

used 1835088 KB Max 2097152 KB [PR811951: This issue has been resolved.] 


• After a Routing Engine switchover, LACP and MIB process (mib2d) core files might be 

created. [PR790966: This issue has been resolved.] 


• PTSP and AACL services do not work with AMS interfaces. [PR727588: This issue has 


• In scenario where telnet session is disconnected ungracefully while accessing "load 

merge terminal" prompt problem can be exhibited with other CLI users unable to access 

configuration mode. [PR745280: This issue has been resolved.] 

• Memory exhaustion on the Packet Forwarding Engine ukern heap causing FPC core. 


• Need to add 'start-time', 'stop-time' and 'timezone' attributes in TACACS+ accounting 

packets. Solution: -------- Added a configuration knob to allow enabling these attributes 

to be framed into the accounting packets. Default behavior is to not include these 

attributes in the packet to maintain backward compatibility. The new knob is [ system 

tacplus-options timestamp-and-timezone ]. You will have to enable this knob and 

then check for the 'start-time', 'stop-time' and 'timezone' attributes in the accounting 

packets. [PR780484: This issue has been resolved.] 

• When Trio inline NAT translates a UDP pkt with UDP checksum 0x0000, it rewrites 

checksum to nonzero value. [PR782927: This issue has been resolved.] 


211


• Flow records obtained by using "inline-jflow" may contain incorrect AS value. Issue 

has been fixed in the Junos OS Release 11.4R6, and onwards. [PR788879: This issue 


• MPC might crash during ISSU. [PR792909: This issue has been resolved.] 

• On MX Series platforms with Trio chipsets (in Junos OS releases 11.4R4 and later), 

when the first large sized(>1500) transit packet hits a resolve route on Packet 

Forwarding Engine it might cause memory to leak on Packet Forwarding Engine micro 

kernel. [PR802051: This issue has been resolved.] 

• With inline sampling, when there are multiple flow servers being configured or multiple 

equal cost paths exist for a single collector, the flow record packet might trigger the 

following trap message from the Packet Forwarding Engine which causes a drop for 

the flow record packet. PPE Sync XTXN Err Trap: Count 1659, PC 45f, 0x045f: 

balanced_multi_nh_use_cp_index [PR805061: This issue has been resolved.] 

• When two irb interfaces with the same layer 2 trunk interface within the bridge domain, 

multicast replication might be handled incorrect. [PR823435: This issue has been 

resolved.] 


• The output of show route summary command might get delayed or timed out when 

the system is busy populating ~1M routes. [PR433419: This issue has been resolved.] 

• In a BGP peer group, if it is the case that either peers have only previously sent the 

default route-target filter (0:0:0/0) or family route-target was not negotiated, when 

a peer comes up that does send non-default route-target filter routes the router will 

not send its matching VPN routes to that peer. [PR703054: This issue has been 

resolved.] 

• If you have configured PIM nonstop active routing (NSR), a core file might be created 

on an upstream router because of high churn in unicast routes or a continuous clearing 

of PIM join-distribution in the downstream router. To prevent this possibility, disable 

NSR for PIM. [PR707900: This issue has been resolved.] 

• If there are more than one peers in a BGP group, and have NSR configured, in a rare 

condition, BGP session init job fails on the last established peer in the group, while at 

the same time, there is another peer in establish-ack-wait state. Then after that, the 

peer in establish-ack-wait state becomes established after getting an establish-ack 

from the remote peer which will cause routing protocol daemon (rpd) crash and 

generates a core file. [PR736198: This issue has been resolved.] 

• RPD can crash soon after OSPF switches from primary path to secondary path when 

LFA (loop free alternates) is enabled, along with LDP-SYNC: /kernel: BAD_PAGE_FAULT: 

pid 1472 (rpd), uid 0: pc 0x86ff81c got a read fault at 0x15, x86 fault flags = 0x4 The 

corruption happens because of race condition, when OSPF doesn't completely free a 

memory location which is later reused by LDP. [PR737141: This issue has been resolved.] 

• If a routing instance is configured to add static routes to it's instance specific routing 

table using both the routing-options static route stanza and the routing-options rib 

static route stanza and a configuration event changes 

something else in the routing-options rib stanza such 

212 



as modifying the maximum-paths value, the static routes in the instance table specific 

section can be deleted. A commit full can be used to recover or only use one of the 2 

mechanisms for defining the static routes for that instance. [PR755558: This issue has 


• rpd generates core file at "rip_dc_retrans_callback_p2mp" while unconfiguring p2mp 

configuration. [PR769487: This issue has been resolved.] 

• The current implementation of the random number generator grand() is not thread 

safe, as it utilizes a number of global variables and arrays. When bgp precision timers 

are enabled, this can cause crashes, for example, when we jitter timers. The changes 

herein give each thread its own random number generator. [PR777802: This issue has 


• The routing protocol daemon (rpd) core might be generated in multicast environment. 

Issue was caused by an internal logic error. When a PIM (S,G) state was deleted, the 

code should have stopped processing the (S,G) but it did not. [PR785073: This issue 


• On Junos OS platforms with 64 bit Kernel (Routing Engines), a bug in the Routing 

Protocol Daemon (RPD) memory allocator might cause corruption in the RPD memory 

which may finally lead to RPD crash. [PR792238: This issue has been resolved.] 

• A MX router which has only some bridge-domains configured for igmp-snooping may 

discard traffic in bridge-domains without igmp-snooping enabled. [PR795781: This 


• When using precision-timers, it is possible that BGP does not send all its advertisements 

from its buffer, until the BGP session needs to send another non-keepalive message. 


• RPD core after making changes to policy-statement related to VPN [PR807357: This 


• Unicast RPF check not working properly after bouncing the RPF interface , when there 

are 2 BGP routes for same destination via 2 different next-hop RPF interfaces. 


• RPD in backup cored@rt_nexthops_free multiple times [PR816754: This issue has been 

resolved.] 


• With large NAT rules configuration, installation of service-sets, on PIC level, is not 

happening [PR751858: This issue has been resolved.] 

• MSDPC pic sending DPD triggers for tunnels that does not have IPSEC SAs. This result 

in kmd daemon on Routing Engine on is continuously trying to send initiate IPSEC phase 

1 negotiation since there are no active IKE/IPsec SAs. [PR754461: This issue has been 

resolved.] 

• This crash was observed during a mixed traffic test for 7 hours on below traffic profile. 

Traffic profile used HTTP 0.8m HTTPS 0.15m FTP 0.1m RTSP 0.08m UDP 8.87m (IMIX 

traffic) [PR769322: This issue has been resolved.] 


213


• Memory leak on FPC/FEB when service next-hops are deleted on LNS for l2tp sessions 

on non-MX platforms. For each l2tp session teardown, there are 240 bytes of memory 

leakes. After some time this leak will lead to FPC/FEB memory exhaustion leading to 

unpredictable FPC/FEB reset. [PR770903: This issue has been resolved.] 

• RTSP streaming is not working in a laptop when moving or fast forward the video 


• IDP daemon may go down temporarity if multiple IDP detector is installed [PR794335: 


• KMD process running high with key chain configuration, need to modify the ncessary 

changes so that KMD does not run wherever is it not required. [PR798030: This issue 


• deNAT:wrong mapping between nat-port-block and internal-host [PR799947: This 


• In a carrier-grade NAT (CGN) configuration that includes the "address-pooling paired" 

statement(APP feature) the service PIC might reset unexpectedly. This behavior occurs 

only in certain cornercase scenarios (with low probability to be seen in production) in 

which the service PIC software times out in an APP mapping but a new flow is created 

within the same mapping. There is no workaround. [PR800241: This issue has been 

resolved.] 

• NAPT:port range start from 512,should start from 1024,this PR fixed this issue. 


• CGNAT - The multiservice Dense Port Concentrator (MS-DPC) crashes when timing 

out an endpoint-independent mapping (fwnat_eim4_mapping_timeout). [PR805801: 


• MS-DPC PIC crash in fwnat_natpool_release_port_from_pblock. [PR809139: This issue 


• When adding/deleting/changing the address ranges configured under NAT pool the 

Service PIC may run into an inconsistent state and restart [PR810994: This issue has 


• Please refer the AT, for the list of new commit constraint checks imposed. [PR815053: 


• Internally, each term is treated as a rule. Multiple copies of NAT pool is created one for 

each rule(or term). When address-allocation round-robin is configured, the NAT ip is 

read from separate copy of the NAT pool thus we see only 10 NAT IPs allocated for 20 

different hosts matching two different terms. After the fix , all terms now can share 

same NAT pool. [PR815147: This issue has been resolved.] 

• On MX240 Routers, the multiservices PIC generates core files in 

fwnat_eim4_mapping_timeout. [PR818448: This issue has been resolved.] 

• In common NAPT44 translation scenario, without Address-Pooling Paired (APP) and 

Endpoint-Independent Mapping (EIM) configured, if NAT pool mapping for a private 

address is being deleted (e.g. mapping-timeout and inactivity-timeout expire), and at 

the same time there is a flow being created for the same private address, then service 

214 



PIC or MS-DPC might crash and core dumped in rare cases. [PR821037: This issue has 


• On MX Series Routers with the Carrier-Grade NAT configuration, the Packet Forwarding 

Engine process (pfed) might generate a core file. [PR825013: This issue has been 

resolved.] 

• On an MX 480 router, the FTP operations fail on a multiservices DPC. [PR825355: This 



• Invalid path element 'dialer-options' error seen for inet6 rpf-check under logical systems. 


VPNs 

• The issue is seen when multicast traffic is stopped and PIM states are allowed to clear. 

It was seen that some of (S, G) states on the PE did not clear. As a result data streams 

for the affected groups do not reach the intended receivers. However it was seen that 

the fix for this issue caused another issue to appear as documented in PR# 823884 

[In NG-MVPN RPT-SPT mode, failure and then recovery of the primary path to the RP, 

causes the PE routers to forward traffic on (*, G) even though the (S, G) join is pruned] 


• In L2VPN scenario with at least one L2VPN connection in up state, during SNMP walk 

on jnxVpnPwAssociatedInterface.bgpL2Vpn (OID: .1.3.6.1.4.1.2636.3.26.1.4.1.6.3.9), an 

infinite loop occurs because of software defect and causes routing protocol daemon 

(rpd) to stuck at 97% indefinitely until the rpd process is restarted. While in this state 

all protocol adjacency will expire and the router will stop forwarding traffic. [PR782654: 


• This issue was experienced in Junos OS Release 11.4R4 code with NG-MVPN RPT-SPT 

mode. When a link failure causes the route to the source and RP via the backup path, 

the PE in the backup path fails to forward multicast traffic to the receiver. This is 

documented in PR 794222 and upgrading to Junos OS Release 11.4R4-S2 fixes the 

above mentioned issue. [PR794222: This issue has been resolved.] 

• When the egress PE receives type 4 route before discovering the ingress PE, it queues 

all the type 4 routes for later processing. Due to a defect in the corresponding code, 

the replaying of type-4 was not happening always, thereby causing the ingress PE to 

not send the corresponding stream to the egress PE. [PR801437: This issue has been 

resolved.] 

• With "vpn-apply-export", per-nexthop label and a "bgp policy overridden nexthop 

rather than the bgp local-address", labeled route for L3VPN didn't install in standby 

Routing Engine even with NSR configured. BGP on standby Routing Engine thinks it is 

not nexthop self and does not create labeled route on standby Routing Engine. This 

will cause label/nexthop change after switchover, therefore traffic loss. [PR807285: 



215






• The customer might see the following firewall logs while running VRRPv3 over VPLS: 

04:39:14 pfe A irb.111 VRRP fe80::2 ff02::e42a:1:e:a0c 04:39:13 pfe A irb.111 ICMPv6 

fe80::2 ff02::1 04:39:13 pfe A irb.111 ICMPv6 fe80::1 ff02::8:0:1d:44f2 [PR748826: This 


• Any change to the last member of a service-filter chain, can lead to the loss of layer 3 

connectivity over the interface. [PR750957: This issue has been resolved.] 

• The system archival feature configured that configuration is backup at an archival site 

periodically. This may leave behind files in /var/tmp when the connection to remote 

site fails. [PR778962: This issue has been resolved.] 

• When IPv4 and IPv6 classifiers are configured on a logical interface that already has 

a Layer 2 hierarchical policer configured on its physical interface, the rate of the policer 

deviates by more than 5 percentage. To prevent this issue, attach the Layer2 policer 

and the classifiers in a single commit. If the physical interface already has a policer 

configured, deactivate it first. Then in a single commit, attach the classifiers and 

reactivate the policer. [PR779357: This issue has been resolved.] 

• Sampled process might be cored when both Origin AS and Peer AS is configured for 

Routing Engine based sampling and when there is a commit command issued to apply 

the configuration changes done. [PR779620: This issue has been resolved.] 

• When we have a configuration with the [edit chassis enhanced-policer] knob configured, 

and Firewall filter with many terms having their own policer, then 

jnxFWCounterByteCount might not include values corresponding to .2 and .3 terms of 

a policer. The fix addresses the issue introduced when committing enhanced-policer 

functionality got misaligned during code integration. [PR783226: This issue has been 

resolved.] 

• IPFIX issue in Junos OS Release 11.4R2 on MP4C-3D-16XGE-SFPP- Unable to see IPFIX 

(IPv4) statistics while issuing the show command show services accounting flow 

inline-jflow fpc-slot 0. [PR787487: This issue has been resolved.] 

• show firewall detailcommand will not display all the firewall policer counters if the 

"enhanced-policer" chassis knob is set and if the configured filters contains more than 

10 policer counters. [PR789889: This issue has been resolved.] 


• Upon Major version ISSU on EQ-DPC with scaling configuration, longer packet loss 

duration will be seen. [PR780657: This issue has been resolved.] 

• On an FPC offline event, mcdiagd logs all the correlated sub-LSPs in the system log. 

This behaviour is independent of having traceoptions enabled or disabled. However, 

with traceoptions disabled, the logging was happening only in some of the correlated 

sub-LSPs. In this case, mcdiagd was providing the log messages to syslogd at a faster 

216 



rate than that could be consumed and displayed by syslogd. The fix throttles the rate 

of mcdiagd sending messages to syslogd, and also adds an additional event timestamp 

to the log message to help identify the sub-LSPs that got correlated because of the 

FPC offline event. [PR754834: This issue has been resolved.] 

• With GRES enabled, ksyncd core is observed during switchover when one member of 

aggregated Ethernet uplink is flapped when router is in steady state. [PR735437: This 


• When there are at least three routers to a specific destination (that is, two destination 

routes and one clone route), deleting and re-adding one of the logical interfaces (that 

is, board replacement) might trigger a kernel crash because of a timing issue with route 

deletion. This is triggered in the specific topologies such as an OSPFv3 next hop, which 

is connected to a different vendor device: lab@shark-re0> show route forwarding-table 

destination fe80::21f:9eff:fea9:c140 Routing table: default.inet6 Internet6: Destination 

Type RtRef Next hop Type Index NhRef Netif fe80::21f:9eff:fea9:c140/128 dest 0 

0:1f:9e:a9:c1:40 ucst 966 2 ae2.70 fe80::21f:9eff:fea9:c140/128 dest 0 0:1f:9e:a9:c1:40 

ucst 968 2 ae4.90 This type of next-hop topology was not seen when a Juniper device 

established an OSPFv3 adjacency to another Juniper device. [PR753849: This issue 


• Memory leak on a router crashes the ADPC card and generates a core file. [PR768772: 


• During bulkget application, the Packet Forwarding Engine might generate some 

corrupted packet. pfed crashes and cores as a result. Fix: Added defensive mechanism 

to protect Routing Engine and avoid pfed to crash. [PR771108: This issue has been 

resolved.] 

• On a VPLS circuit with no-tunnel-services configured, when a provider edge(PE) device 

receives the MPLS frame from the core, it might be dropped by the PE as "L2 mismatch 

timeout" interface error. [PR781782: This issue has been resolved.] 

• On T Series core routers and on TX Matrix and TX Matrix Plus routers, packets marked 

with the error flag, example because of DA(Destination Address) reject, are also counted 

as L3 incomplete, which is not correct and is misleading. Packets marked as error from 

the PIC are now counted via the show pfe statistics error command. [PR782070: This 


• On LMNR and Stoli FPCs, when a transit packet?s (300 Bytes or more packet size) 

ingress and egress interfaces are in the same Packet Forwarding Engine (with scaled 

egress NHs) and if a notification is sent to Routing Engine for that packet, FPC might 

reset. Following list provides some scenarios, where a notification is sent to Routing 

Engine: 

1. IP options packet is received 

2. TTL expired packet is received 

3. Sampling is configured and a packet is sampled 



217



• When you downgrade Junos OS from Release 11.4R4 to 11.3, a core file is created. This 

occurs because the interface information on the Gigabit Ethernet IQ PIC gets deleted 

when the FPC on which the PIC is installed on goes offline during the downgrade. To 

prevent this error, deactivate the physical interface configuration on the IQ PIC before 

the downgrade. You can reactivate the configuration after the downgrade. [PR784291: 



• Ethernet driver for the internal Ethernet interface on the Routing Engine causes the 

kernel to crash and Routing Engine reboot. This problem only could happen on Routing 

Engine models that use "bcm" type of Ethernet interfaces for internal communication. 

To identify if the Routing Engine is using this type of interface, use the following 

command: 

user@router-re1> show interfaces terse 

Interface Admin Link Proto Local Remote 

[..........] 

bcm0 up up



• "HS Link FIFO underflow" errors may occur as traffic egresses a PIC when the ingress 

interface is on another PIC in the same MX-FPC. The speed of the interfaces and the 

traffic pattern are relevant to this problem. [PR687905: This issue has been resolved.] 

• Due to an incorrect calculation, memory heap utilization of a service PIC can go over 

100% under the show chassis pic CLI command. There is no service impact. [PR737676: 


• The failure of the BFD sessions is caused by a CPU hog in the kernel that is addressed 

as part of 11.4R3 ... there was insufficient time to get this patch into 11.4R2. The problem 

can be circumvented by increasing the BFD session timeout in scaled aggregate Ethernet 

configurations. [PR744882: This issue has been resolved.] 

• When "restart routing", "restart chassis-control" and "restart fpc" is done, sometimes 

DCD is not able to clear the pd-/pe- interfaces as a result fpc is struck in ready state 

and doesn't come up. [PR768928: This issue has been resolved.] 

• When an F13 SIB is removed, multiple events are handled by chassisd/fabric 

management. They include marking the plane faulty and recording the SIB's removal. 

SIB absence is checked at low frequency (every 10 seconds) so it is usually processed 

later than other events. However, if the SIB removal event wins the race, then we need 

to mark a SIB faulty when it is already absent and this situation is not handled correctly. 


• For IGMP snooping over A/A MC-LAG, with Integrated routing and bridging enabled or 

with singly homed receivers, it is required to configure the ICL port as a multicast router 

interface. However, currently there is no way to configure a trunk port in the default 

routing instance as a multicast router interface. Hence when an MC-LAG is configured 

in the default routing instance and the ICL is over a trunk port, IGMP snooping over the 

MC-LAG might not work correctly with IRB or singly homed receivers. As a workaround, 

the configuration in the default routing instance can be moved to a named routing 

instance. A trunk port in a named routing instance can be configured as router facing 

by using the set routing-instance routing-instance-name protocols igmp-snooping 

interface interface-name multicast-router-interfacecommand. Note that this command 

will enable igmp-snooping on all bridge-domains in the routing-instance and also apply 

the multicast router interface configuration to the trunk port associated with each of 

them. [PR774556: This issue has been resolved.] 

• Configuring Multicast address (Inet6) on an interface results in RPD core (mc_ssm_add). 


• Local SNMP walk for VRRP MIBs might loop continuously when the IRB interface is 

deleted. [PR785582: This issue has been resolved.] 

• The prefer-status-control-active configuration knob at [edit interfaces aeX 

aggregated-ether-options mc-ae events iccp-peer-down] hierarchy requires 

configuration knob to be active at the [edit interfaces aeX aggregated-ether-options 

mc-ae status-control] hierarchy. When this is not present prefer-status-control-active 

has no impact and its presence in the configuration knob wrongly implies that the 

current node is preferred active. [PR785930: This issue has been resolved.] 


219


• monitor ethernet delay-measurement command does not timeout when CFM adjacency 

is down and/or all DMM frames are sent. As a result, ethdm binary does not close 

normally leading to an increase in resource consumption. [PR787985: This issue has 


• T640 frame relay interface status is shown as up/up with mismatched lmi-type. 


• The PPP daemon (pppd) may dump core file which is because of a counter overflow 

issue during memory allocation. [PR792261: This issue has been resolved.] 

• When upgrading to 11.4R4, links that are using tuneable DWDM XFP are not working 

anymore and are reporting a different wavelength than the configured one. [PR796330: 



• With VPLS configuration present, When chassis daemon is restarted or if an FPC is 

rebooted, There is a chance that the dynamic logical interfaces created by RPD are 

not deleted from the VT interface as a result of which the VT interface will be down 

along with the VPLS instances [PR786263: This issue has been resolved.] 


• MPLS forwarding broken when labeled BGP routes are distributed to LDP [PR724658: 


• If bfd packets are blocked and mpls ping is succeeding then BFD will not come up after 

bfd packets are unblocked. [PR770203: This issue has been resolved.] 

• Non Juniper routers may send RESV messages with the peak rate value different than 

the one received in the PATH message. Even though this doesn't have any functional 

impact the JunOS will still log a warning message. With this PR the 

"RPD_RSVP_INCORRECT_FLOWSPEC: Bandwidth in PATH Tspec greater than RESV 

flowspec for Session" messages are not logged anymore on peak rate mismatch. 


• A-----------B------------C X(primary) X(protector) Y(protector) Y(primary) Given a 

topology with primary and protector context IDs like above, B seems to have a problem 

installing LDP label routes in mpls.0 and the forwarding table. [PR782499: This issue 


• RPD coredumps are generated on backup Routing Engine when RSVP+NSR+GRES 

and "routing-instance provider-tunnel rsvp-te" is configured. [PR782969: This issue 


220 




• There may be an issue where multiple SNMP queries for large volumes of information 

may cause Mib2d to grow in size and eventually create a core file. Mib2d will restart, 

possibly multiple times, but should recover by itself. [PR742186: This issue has been 

resolved.] 


• Under very special race conditions the MPC CPU might stop processing and will be 

reset because of Level3/Level 2 watchdog expiration timer. Potential exposure are 

high load of traffic send to the Host. The following syslog message will be reported in 

the syslog once MPC reboots. "fpc[x] MPC: Reset reason (0xc): Level3 watchdog, 

Level2 watchdog" [PR717899: This issue has been resolved.] 

• In case of trio cards, for incoming vlan tagged packets, when some vlan tags are pushed 

or popped on the ingress Packet Forwarding Engine and the packet is sent to the host 

from the egress Packet Forwarding Engine, the packets received will not be correct. 

This can typically happen for CFM/OAM packets and cause some CFM/OAM 

functionality to break. [PR731639: This issue has been resolved.] 

• When queue rate-limit is configured for interfaces on MPCs, the rate of rate-limit drops 

reported in show interfaces queuemay not be accurate. The value fluctuates between 

0 and the actual rate. However the total count of dropped packets and bytes is 

displayed correctly. [PR740750: This issue has been resolved.] 

• By default, Junos OS will load configured scripts files from /var/db/scripts. If the 

load-scripts-from-flash is configured as below, the Junos OS will load the scripts file 

from /config/scripts. However, with such configuration, when Junos OS software 

upgrading is performed, the new Junos OS will fail on the configuration validation with 

messages "mgd error: could not open commit script" etc. Even scripts files are located 

under both flash and harddisk. 

router# show system scripts 

commit { 

file test-commit-script.xsl; 

} 

load-scripts-from-flash; 


• When an event policy, such as those use in AI Scripts, is configured for so-called 

unstructured syslog messages and also implements a dampening policy, only the first 

unstructured syslog messages will be processed by the system during the dampening 

interval. Other unstructured messages, regardless of difference, are also suppressed 

from being expressed via syslog. This reduces the effectiveness of AI Scripts, but also, 

because of PR612498 suppresses unstructured events from any other logging process. 


• There is known issue with ICMPv6 packet header. This issue is seen only if service-set 

is enabled on interface. ICMPv6 message generated by FPC will have IPv4 source 

address instead of IPv6 address of underlying interface on which service-set is enabled. 



221


• On Trio based platforms, LU chip might get into wedge condition which is caused by 

global Packet Processor Engine (PPE) timeout unrestored after ttrace (Trinity Trace). 


• When reconfiguring an interface from a native VLAN to another tagged VLAN, the 

logical interface mapping on the Packet Forwarding Engine might get corrupted. In 

case traffic is being received on this interface, it can lead to LU congestion and wedge. 


• Committing a Q-in-Q configuration results in an FPC crash in these conditions: 

• Core facing interface is configured this way: 

flexible-vlan-tagging; 

encapsulation flexible-ethernet-services; 

unit xxx { 

encapsulation vlan-bridge; 

vlan-tags outer xxx inner-range 1-4094; 

} 

• Core-facing interface is an aggregate interface. 

• Core-facing interface is on MPC card. 


• On MX Series platforms with the Trio chipset (in Junos OS Releases 11.4R4 and later), 

when the first large sized(>1500) transit packet hits a resolve route on Packet 

Forwarding Engine it might cause memory to leak on Packet Forwarding Engine micro 

kernel. [PR802051: This issue has been resolved.] 


• OSPF routes flap only when commit full is performed, this has been fixed in latest 

releases [PR672838: This issue has been resolved.] 

• In rosen MVPN environment, while there is any data-MDT message updated because 

of some rare case (Like the assert loser becomes assert winner or a PIM router recovery 

from the reboot status) which in turn causes routes update, Routing Protocol Daemon 

(RPD) may core and reboot. [PR690188: This issue has been resolved.] 

• RPD may core after deleting or renaming a non-forwarding instance. Specifically, issue 

occurs when: 

1. the interface is configured in a non-forwarding instances (that is, routing instances 

xxx with no instance-type). 

2. and any one of the following: 

a. IGMP is configured with all interfaces (For example: protocols IGMP interface 

all) 

b. IGMP is configured on the specific interface (For example: protocols IGMP 

interface ge-0/0/0.1) 

c. MLD is configured with all interfaces (For example: protocols mld interface all) 

222 



d. MLD is configured on the specific interface (For example: protocols mld interface 

ge-0/0/0.1) 

e. PIM is configured in the master instance with all interfaces (For example: 

protocols pim interface all) 

f. PIM is configured in the master instance on the specific interface (For example: 

protocols pim interface ge-0/0/0.1) 

3. and any one of the following actions are subsequently committed: 

a. delete the non-forwarding instance (For example: delete routing-instances xxx) 

b. rename the non-forwarding instance (For example: replace pattern xxx with yyy) 


• There is a race condition when family route-target is configured on a scaled system. 

During an IGP change that makes BGP VPN routes inactive, and those routes are 

monitored by family route-target, is is possible that RPD may core at a later time. 


• When GRES is done for around 10 times, the backup Routing Engine access freed 

multicast route and core generated. [PR751702: This issue has been resolved.] 

• If BFD authentication configured for IGP and use the meticulous-keyed-sha-1 algorithm, 

the sequence numbers will not get update every packet. There is no workaround once 

meticulous-keyed-sha1 is configure and hit the issue where BFD is stuck in INIT state. 

meticulous-keyed-md5 works as expected and can be used. [PR755303: This issue 


• Advertise-external knob not working in C-EBGP scenario. [PR775175: This issue has 


• In scaled scenarios where BFD is created with transmit intervals of less than 100msec 

it is possible to end up in a state where we have duplicate stale entries left behind in 

the FPC for BFD sessions which do not exist any longer. This causes unnecessary BFD 

hello packet to be generated and transmitted for each of those entries to the BFD 

peering router despite not having a valid bfd session. This might result in PPMD and 

BFD processes on the remote peer routing-engine to report a constantly high CPU 

utilization. This issue is because of a race condition in PPMD which ends up duplicating 

transmission entries in FPC instead of cleaning up properly. The fix addresses this race 

condition. [PR778813: This issue has been resolved.] 

• The rpd crashes when the customer specific BGP configuration is unconfigured. 


• Routers can RPD core in task_timer_delete with an assert "!BIT_ISSET(flags, 

TIMERF_PROCESSING)" when a rare timing issue occurs while a thread is trying to free 

a BGP keepalive timer. If this keepalive timer is currently being processed by the 

keepalive thread in RPD the core will occur. [PR786842: This issue has been resolved.] 

• On a dual-Routing Engine system with NSR enabled we could run into an issue with 

the following symptoms: - RPD on backup Routing Engine showing high CPU utilization 

- master Routing Engine reporting BGP spooling messages - OSPF neighborship possibly 


223


flapping This is because of a bug in RPD NSR infra on the backup-Routing Engine which 

leads to an increase in the collisions and ultimately the size of the hash-table structure. 

This results in RPD on backup Routing Engine spending a lot CPU cycles leading to the 

above symptoms. [PR788394: This issue has been resolved.] 


• When a TX router is configured with a manual OSPF ipsec-sa for authentication, 

something like the following cosmetic messages will be logged: Feb 16 16:27:40 

flame-sfc-re1 lcc0-master kmd[17194]: KMD_RTSOCK_ERROR: Error adding inbound 

SA OSPF3_AH_SHA1_96 spi=1024 proto=AH to kernel: No such file or directory Feb 16 

16:27:40 flame-sfc-re1 lcc0-master kmd[17194]: KMD_RTSOCK_ERROR: Error adding 

outbound SA OSPF3_AH_SHA1_96 spi=1024 proto=AH to kernel: No such file or directory 

If there's a service PIC, there will be these additional cosmetic log entries: Feb 16 16:27:46 

flame-sfc-re1 lcc1-master kmd[16853]: KMD_INTERNAL_ERROR: Failed to connect 

PIC, ERR: Failed to connect PIC, ERR: F Feb 16 16:27:46 flame-sfc-re1 lcc1-master 

kmd[16853]: KMD_INTERNAL_ERROR: Unable to connect PIC sp-8/3/0; Feb 16 16:27:46 

flame-sfc-re1 lcc1-master kmd[16853]: KMD_INTERNAL_ERROR: Couldn't request 

PIC: sp-8/3/0 to send sa state [PR738736: This issue has been resolved.] 

• When using Junos OS maintenance releases 11.2R6, 11.4R2 or 12.1R1 (or any Junos OS 

service releases based on the mentioned maintenance releases) SNMP traps are not 

generated when the service PIC cpu usage exceeds 85% and/or the memory usage 

changes from one zone to another. The SNMP traps are not generated because of an 

internal Junos OS mis-programming. According to the Juniper SP-MIB definitions the 

following traps should be generated: a) jnxSpSvcSetCpuExceeded (OID 

1.3.6.1.4.1.2636.4.10.0.3) - when service PIC CPU usage becomes bigger than 85% b) 

jnxSpSvcSetCpuOk (OID 1.3.6.1.4.1.2636.4.10.0.4) - when service PIC CPU usage 

becomes smaller than 85% c) jnxSpSvcSetZoneEntered (OID 1.3.6.1.4.1.2636.4.10.0.1) 

- when service PIC memory usage enters a specific zone (Yellow, Orange or Red) d) 

jnxSpSvcSetZoneExited (OID 1.3.6.1.4.1.2636.4.10.0.1) - when service PIC memory usage 

leaves a specific zone (Yellow, Orange or Red) In Junos OS releases 11.2R7, 11.4R3 or 

12.1R2 and all later versions this specific Junos OS feature has been modified to send 

the SNMP traps correctly. [PR745190: This issue has been resolved.] 

• In some conditions EIM entries are not valid. EIF entries are used when a user tries to 

create a connection from internet to internal side. As the EIM entries are invalid MSDPC 

cores, code is fixed in the fixed versions of this PR. [PR750284: This issue has been 

resolved.] 

• MS-PIC might crash when releasing port block for a flow with SIP ALG enabled. SIP 

flows that can trigger this are the ones that have SDP media address as 127.0.0.1. 


224 



VPNs 

• An optimization has been implemented with BGP-MVPN nexthop infrastructure which 

will improve scalability in some multi-dimensional scaling scenarios with aggregate 

interfaces. [PR690690: This issue has been resolved.] 

• When you disable protocols in a Layer 2 circuit with egress protection, rpd generates 

a core file if no routes are found in context routing table. [PR735789: This issue has 


• In 11.4, PE discards IPV6 BSR messages that come in with a HopLimit != 1. This is causing 

problems with working with Junos OS Release 10.4 which sometimes sends a BSR 

message with the default Hop Limit of 64. The fix is to relax this requirement of a Hop 

Limit of 1. A hidden command is added to enable this strict Hop Limt/TTL checking in 

case somebody really wants it. [PR779966: This issue has been resolved.] 

• In scaling scenarios, buffer overwrites might occur when there are multiple sources for 

the same group. This might lead rpd to generate a core file when MVPN traceoptions 

are enabled. [PR783615: This issue has been resolved.] 

• A direct route which is primary in another instance and imported into a VRF using 

rib-groups is not advertised when vrf-table-label is configured. The error message 

"BGP label allocation failure: Need a nexthop address on LAN" can be seen in "> show 

route advertising-protocol bgp". [PR789054: This issue has been resolved.] 

• The rpd incorrectly sets the PWE3 Control Word flag for local switching circuits. PWE3 

Control Word is needed for Layer 2 VPN OAM packets to get pushed to the Routing 

Engine. On MX Series routers with MPCs/MICs, the traffic payload is examined and if 

it matches the first nibble being 0001, it sends the traffic to Routing Engine for further 

processing. Once Layer 2 VPN traffic is set to IPv4, it would test against the IPV4 ID 

field. [PR793751: This issue has been resolved.] 

• This change would allow customers to use the less restrictive CLI knob 

'vrf-advertise-selective', which now accepts a null list. If no family is configured under 

vrf-advertise-selective, then no MVPN routes are advertised to the neighbor. [PR795108: 






225




• When the configuration archiving FTP process stalls during file transfer, it can result 

in the The Packet Forwarding Engine process (pfed) process stalling as well. Once the 

master The Packet Forwarding Engine process (pfed) process is restarted, it results in 

the inability to commit certain new configuration changes. Ensuring that the 

configuration archiving and FTP server are correctly configured and working will avoid 

this problem. [PR528653: This issue has been resolved.] 

• Sampled memory increases when interfaces bounce and BGP is running. [PR594509: 


• On ADPC cards Output Layer-2 policer drops the packets when configured on a interface 

with vpls encapsulation. [PR749141: This issue has been resolved.] 

• Any change to the last member of a service-filter chain, can lead to the loss of layer 3 

connectivity over the interface. [PR750957: This issue has been resolved.] 

• This issue can occur for daemons that connect to pfed for statistics information. If the 

daemon starts before pfed or has problems making a connection to pfed then that 

daemon could experience a crash. This can also occur using cli commands like "show 

interface statistics" that invoke ifinfo. This problem was introduced by the fix for 

PR743135 and only exists in the specific releases that were fixed by that PR. There is 

no known work around to this problem except to use a release of Junos OS with the 

fix. [PR770766: This issue has been resolved.] 

• This PR eliminates an erroneous error message which would appear in syslog while 

pfed was checking the syntax of a configuration containing firewall filters that reference 

accounting counters. This problem only affected the syntax check prior to the commit, 

the actual configuration on the router was correctly committed. [PR772463: This issue 



• RPD may core when a community named in the policy options configuration is changed 

and that community-name is used in the show route command before the changes 

effectively take place. [PR740427: This issue has been resolved.] 

• Once a child interface of an aggregate bundle is in down state (for example: CCC-Down 

of the logical member link interfaces), the next-hop of the control channel is not 

correctly programmed. LACP packets received are not dropped but processed and 

pointing to invalid NH entries, which might yield to such errors as follows or a 

combination of all: 

• fpc5 LUCHIP(0) IDMEM[0x000433ba] Read Uninitialized Memory Error 

• fpc5 LUCHIP(0) PLCT INT_STAT 0x00000001 Illegal PL Uninitialized EDMEM Read 

0x6db6db6d6db6db6d @ 0x1cf30001 XTXN 0xa8cd87 BULK 0x005c0094 FN 0 

sync PPE 14 CNTX 1 

• fpc5 LUCHIP(0) RMC 2 Uninitialized EDMEM[0x1001c0] Read 

(0x6db6db6d6db6db6d) 

226 



• fpc5 LUCHIP(0) PPE_6 Errors sync xtxn error thread timeout error 

• fpc5 PPE Sync DMEM WP Trap: Count 103, PC 620b, 0x620b: nat46_loop 0x620b: 

nat44_loop 

• fpc5 PPE Sync XTXN Err Trap: Count 980053, PC 2f9, 0x02f9: nh_ret_simple_last 

• fpc5 PPE Thread Timeout Trap: Count 2840, PC 4c6, 0x04c6: set_iif_inc_ifl_cnt fpc5 

PPE PPE Stack Err Trap: Count 20347, PC 310, 0x0310: add_default_layer1_overhead 

• fpc5 PPE PPE HW Fault Trap: Count 529, PC 373, 0x0373: inner_rewrite 

There is no operational impact other than the filling up of error messages in the system 

log. [PR703245: This issue has been resolved.] 

• When there are at least three routers to a specific destination (i.e. 2 destination routes 

and 1 clone route), deleting and re-adding one of the logical interfaces (i.e. board 

replacement), might trigger a kernel crash because of a timing issue with route deletion. 

This is triggered in the specific topologies such as an OSPF3 next hop, which is 

connected to a different vendor device: 

lab@shark-re0> show route forwarding-table destination 

fe80::21f:9eff:fea9:c140 

Routing table: default.inet6 

Internet6: 

Destination Type RtRef Next hop Type Index NhRef Netif 

fe80::21f:9eff:fea9:c140/128 dest 0 0:1f:9e:a9:c1:40 ucst 966 2 ae2.70 

fe80::21f:9eff:fea9:c140/128 dest 0 0:1f:9e:a9:c1:40 ucst 968 2 ae4.90 

This type of next-hop topology was not seen when Juniper established an OSPF3 

adjacency to another Juniper. [PR753849: This issue has been resolved.] 

• When an FPC restart is performed some of the PICs and physical interfaces were unable 

to be created by chassisd because of EBUSY error returned by kernel. Kernel was unable 

to process the new requests until the previous states of the same object (PIC, IFD in 

our case) was consumed by all peers interested in this. The enhancement addresses 

the design which makes sure new state changes which could have been processed by 

the faster peers are not blocked because of these slower peers. [PR769632: This issue 


• There is an issue with the interworking of 'chassis route-memory-enhanced' knob and 

'protocols rsvp interface x/y/z.l link-protection' or 'protocols mpls label-switched-path 

node-link-protection'. This will cause failure of the installation of routes 

that are destined to go to segment 1 (because of the route-memory-enhanced) 


• On Systems platforms M320 E3FPC/M120/M7i(10i) CFEB-E with l2vpn or l2circuit, 

using a control-word and the mpls payload is corrupted in a certain way, the interface 

might stop forwarding traffic. To recovery from this condition a FPC reboot is needed. 

Only Junos OS Release 10.0 or later is exposed with non-cookie based PICs. Mx Series 

platforms with DPC are not exposed. [PR720523: This issue has been resolved.] 

• When receiving large bytes of PIM Join/Prune refreshes at a very rapid rate, it might 

exhaust ukernel buffer memory on Packet Forwarding Engine, and the PIM Join/Prune 

packets will be lost. [PR720966: This issue has been resolved.] 


227


• When "delete", or "deactivate" "interface :family inet:accounting" configuration; 

FPCs which have the configuration removed may be reset unexpectedly. [PR743442: 


• In Junos OS Release 11.2R3 or lower if IPv6 traffic needs to trigger ICMPv6 MTU exceeded 

message to the source and the source is resolved via next-table next-hop it might leak 

packet memory on the FPC. [PR745988: This issue has been resolved.] 

• Jtree memory leak occurs on I-chip based platforms when 'route-memory-enhanced' 

or 'memory-enhanced' is enabled, after there is route flapping which is using indirect 

nexthop. [PR751567: This issue has been resolved.] 

• Issue: Certain hardware data structure used for replicating packets on a single Packet 

Forwarding Engine stream (SSM list) is not getting updated when the corresponding 

nexthops get modified, resulting in use of stale data for multicast replication. 

Impact: All applications that depend on packet replication (IP multicast, P2MP, VPLS 

BUM traffic) can get impacted. Packets will either be sent out on wrong ifls or can get 

dropped. However this will happen only if the nexthops used for packet replication get 

modified. 

This can affect line cards using the I/J Chipset in MX, TX and M Series chassis. 


• *IF* you have DCU statistics configured in conjunction with the copy-plp class of servce 

knob & a output firewall filter you may encounter a situation where DCU stats are no 

longer working. Check first that both ingress & egress ports for the flows you are counting 

are *NOT* on different Packet Forwarding Engines the same fpc. *IF* this is the case 

then removing the copy-plp knob will restart the DCU statistics collection. [PR707834: 


• Summary: This PR fixes JTREE corruption seen with per-prefix load balancing when 

the route-memory-enhanced knob is enabled. 

Affected hardware: Stoli FPCs (FPCs that show up with a 'ES' suffix in the Description 

column of the 'show chassis hardware' output) and I-chip FPCs (ADPCs and Sahara 

FPCs) are exposed to this. 

Description: As soon as the forwarding table starts building up on the FPCs, all the 

affected FPCs will start reporting the following JTREE errors which is an indication of 

this issue. 

Apr 29 13:45:54 lab-router fpc5 JTREE(jt_nh_get_reachable_nh32): Not reachable 

0x00000000:0x082d1782 for seg 1 (rt_jtree_build_nh) 

Apr 29 13:45:54 lab-router fpc5 RT: Failed prefix add IPv4 - 1.0.0/24 (jtree nh build 

failed) on FE 0 

Apr 29 13:45:54 lab-router fpc5 RT: IPv4:0 - 1.0.0/24 (add rt entry into jtree failed) 

These messages will be seen as soon as the forwarding table starts building up, even 

if there is no traffic. When traffic starts flowing, the FPCs may crash as a result of this 

corrupted JTREE. 

Necessary conditions: 

228 



1. route-memory-enhanced knob configured 

2. Per-prefix load balancing (which is the default unless per-packet is explicitly 

enabled) for some or all of the prefixes 

3. Routing table with either or both of the following: 

a. IPv4 prefixes with the first octet in the 0 to 127 range 

b. IPv6 prefixes beginning with 7fff:: or lower 

4. Above routes being resolved over an indirect next-hop (like above routes being 

received over BGP) 

5. The above next-hop is reachable through a load balanced path over Aggregated 

Ethernets (AEs) or MPLS (LDP / RSVP) LSPs. In case of load balancing over 

Aggregated Ethernets, at least one of the Aggregated Ethernet links being used in 

the load-balance must have link IP address 

a. Equal to or greater than 128.X.X.X - if IPv4 

b. Equal to or greater than 8000:: - if IPv6 

This issue is not seen if per-packet load balancing is configured on the router for all 

prefixes. [PR756464: This issue has been resolved.] 


• During high routing churn, a flapping interface can in some rare circumstances result 

in the replicated (backup) kernel to panic with reason ": bitstring 

index 14 not empty for .” [PR698608: This issue has been resolved.] 

• Determining readiness for graceful Routing Engine switchover in an MX Series Virtual 

Chassis (MX240, MX480, and MX960 routers with MPC/MIC interfaces)--You can use 

the new check option for the request virtual-chassis routing-engine master switch 

command to determine whether the member routers in an MX Series Virtual Chassis 

configuration are ready for a global graceful Routing Engine switchover (GRES) 

operation from a database synchronization perspective. A global GRES changes the 

mastership in an MX Series Virtual Chassis by switching the global roles of the master 

router and backup router in the Virtual Chassis configuration. Depending on the router 

configuration, a variable amount of time is required before a router is ready to perform 

a GRES. Attempting a GRES operation before the router is ready can cause system 

errors and unexpected behavior. Using the request virtual-chassis routing-engine master 

switch check command before you initiate the GRES operation ensures that the 

subscriber management and kernel databases on both member routers in an MX Series 

Virtual Chassis are synchronized and ready for the GRES operation. The request 

virtual-chassis routing-engine master switch check command, which you must issue 

from the Virtual Chassis master router (VC-Mm), checks various system and database 

components to determine whether they are ready for GRES, but does not initiate the 

global GRES operation itself. The readiness check includes ensuring that a system 

timer, which expires after 300 seconds, has completed before the global GRES 

operation can begin. If the member routers in an MX Series Virtual Chassis are ready 

for GRES from a database perspective, the request virtual-chassis routing-engine master 

switch check command returns the command prompt and displays no output. If the 


229


member routers are not ready for GRES, the command displays information about the 

readiness of the system. [Junos OS High Availability Configuration Guide] [PR722016: 


• If one or more Packet Forwarding Engine peers are slow in consuming ifstates, that 

results in slave Routing Engine not sending CP ACK to the master Routing Engine within 

prescribed time. As a result of this, as of today, slave Routing Engine is assumed to be 

having a problem and hence the connection for slave Routing Engine peer is reset, so 

that ksyncd can cleanup the ifstates on the slave Routing Engine and resync with 

master Routing Engine again. With this fix, if slave CP ACK does not arrive in prescribed 

time, if there is any Packet Forwarding Engine which is causing this delay, the same is 

logged and the CP ACK timer is reset. If no peers are found to be causing the delay of 

slave CP ACK, the behavior is retained to reset the slave Routing Engine connection. 


• The MPC can core during ISSU. This issue is intermittent. [PR744992: This issue has 


• When performing ISSU on 10GE DPC, peer device will see link flap. [PR777798: This 


• -Problem Summary On MX platforms with ADPC line cards, performing an ISSU upgrade 

to 11.4R3.7 might cause the ADPC line cards to reset, thus impacting router operation 

and defeating the purpose of ISSU. Customers with ADPC line cards on MX platforms 

should upgrade only in a maintenance window during which the resets can be tolerated. 

Other platforms are not affected by this bug, and ISSU works as expected. -Impact: 

ADPC line cards might reset, causing a traffic outage of approximately 150 seconds 

duration. -Workarounds: None [PR779348: This issue has been resolved.] 


• Certain system resources may become exhausted during Routing Engine switchover 

under heavy load, causing the system to restart. After restart, the router will operate 

as expected. [PR733555: This issue has been resolved.] 

• This problem is that there is a socket hole in the received sequence space on backup 

Routing Engine and that backup Routing Engine cannot handle the TCP SACK from 

master Routing Engine properly. When backup Routing Engine becomes new master 

Routing Engine by switchover, this potential sequence mismatch in the previous backup 

Routing Engine comes out on the new master Routing Engine, therefore, this message 

is generated on syslog. Once after the new master Routing Engine starts handling TCP 

SACK properly, this mismatch will be cleared and sooner or later this message stops. 

This is just a cosmetic issue. [PR743382: This issue has been resolved.] 

• Fetching ppX interface statistics leaks in pfestat_table leading to "pfestat_req_add: 

pfestat table out of ids" error logs. When we're in this state then it is NOT possible to 

fetch any interface statistics. To recover from this issue we need to reload the Routing 

Engine. Products affected by this are non-MX products which offer pppoe services. 


230 



• Arp entries are not flushed out after diabling interface with purging,aging-timer 

configured on local router [PR753268: This issue has been resolved.] 

• In scenario where "family inet" is configured in pppoe dynamic profile, if ARP request 

is recieved on pppoe interface kernel crash is exhibited. [PR769646: This issue has 



• Error message seen on MX80 "fru_is_present: out of range slot -1 for CB" continuously. 


• "HS Link FIFO underflow" errors may occur as traffic egresses a PIC when the ingress 

interface is on another PIC in the same MX-FPC. The speed of the interfaces and the 

traffic pattern are relevant to this problem. [PR687905: This issue has been resolved.] 

• The issue will be seen if the following conditions are satisfied. 1. VPLS routing instance 

is created with configuration "protocol vpls connectivity-type permanane" 2. LSI 

interace for the vpls routing-instance has a Primary/secondary MPLS LSP present on 

the ADPC IFD which is the DUT. Now on just rebooting the ADPC, these logs are seen 

on the DPC console. [PR693066: This issue has been resolved.] 

• MPC2 may reboot when swapping MIC cards in the same MPC [PR728095: This issue 


• On T Series ES type of FPC, BFD sessions might get flapped when other PIC on the 

same FPC is brought online. This is caused by the fact that the PIC drivers take long 

time to do initialization when being brought up which might cause the BFD thread to 

lose chances of processing the keepalive packets and hence drop the sessions. 


• The issue is present in Mx series platform MIPs must place their own MAC address in 

the Egress Identifier TLV in CFM Linktrace Messages that they process. They are 

incorrectly leaving this value unchanged. [PR735419: This issue has been resolved.] 

• Due to an incorrect calculation, memory heap utilization of a service PIC can go over 

100% under the show chassis pic command. There is no service impact. [PR737676: 


• In an Active/Active MC-LAG scenario, traffic might get dropped if: 

a. Upstream and downstream interfaces are MC-AE interfaces 

b. You have routing protocols running over the IRB 

c. Traffic crosses the ICL 


• Workaround : Deactivate and activate the interface solves the issue [PR747522: This 


• On Junos OS Release earlier to 11.2, the BERT test results would report Error Bit/LOS 

sec for a newly confirmed E1 link in unframed mode. The issue would be seen on 

CHSTM1-IQ and CHE1T1-IQE pic. Due to known hardware limitation on CHSTM1-IQ pic, 


231


this issue persists on this pic type. However for CHE1T1-IQE pic it has been fixed on 

Junos OS Releases 11.2R7 and later. [PR748175: This issue has been resolved.] 

• If rlsq interfaces are part of a routing instance, upon deactivation and activation of 

routing instance, all rlsq interfaces were not brought up. This issue is fixed as part of 

this PR. [PR749760: This issue has been resolved.] 

• a GE port with optic SFP-FX which has auto-negotiation disabled, it may claim up even 

though no cable connected and have issue with traffic forwarding on the interface. 


• This issue is specific to a i-chip-based DPCs/FPCs and impacts all type of multicast 

traffic such as IP multicast packets, or L2 multicast/broadcast packets going through 

L2VPN/VPLS. An i-chip-based DPC/FPC will only forward multicast traffic to the first 

1024 receivers of a multicast group if the total number of receivers on a particular PIC 

of the DPCE, for that group, is between 1025 and 1088 (1024+64). [PR752662: This 



• In a router running a VPLS configuration, an administrator configuration change or a 

network event that causes the removal of an IFF from a VPLS instance could lead to 

a panic on the backup Routing Engine. [PR750036: This issue has been resolved.] 

• Routing-engine kernel crash was caused by a suspicious packet in the wrong system 

queue. Packet was classified as a TNP packet (ethertype: 0x8850). TNP is a L3 protocol 

used for inter process communication between the Routing Engine and the packet 

forwarding engine. [PR779079: This issue has been resolved.] 


• With the configuration of STP/aggregate Ethernet under IRB interface, you might see 

kernel panic on both master/backup Routing Engines after a multiple GRES switchover 

is done. [PR742940: This issue has been resolved.] 

• There is a limitation in the support of IRB interfaces used with DHCP such that: 

• If an LT interface is configured as the underlying interface for an IRB interface and a 

DHCP client requests a unicast response, then instead of rejecting the send operation 

a corrupt packet is sent. 

• If the underlying interface of an IRB interface has a different number of tags configured 

than the bridge domain of the IRB interface and a DHCP client requests a unicast 

response a malformed packet is sent. 

• Regardless of tag configuration on the bridge domain, if the packet needs to be 

relayed out a VPLS tunnel (an LSI or VT interface as underlying) a malformed packet 

is sent. 


232 




• By design, family MPLS under virtual-router type routing-instance does not get created 

without a corresponding "protocols:ldp". Hence, without MPLS family, MPLS filter is 

not working on an interface configured under virtual-router type routing-instance. As 

a workaround, configure ldp in the instance, and disable it on all interfaces if not used. 


• Routing protocol daemon may redundantly try to save the RSVP ERO object in the 

graceful restart database. This is applicable only for non-traffic engineered LSPs when 

graceful restart is configured. [PR741694: This issue has been resolved.] 

• l3vpn-composite-nexthop with MPC and MSDPC doing stateful-firewall with interface 

service-set will drop packets on service input direction. The interface where service 

input/output is configured has to be inside a VRF, and the destination for which service 

input should intercept the traffic and send it to service PIC in MSDPC should be 

reachable through MPLS backbone, so resolved through composite next-hop, in orded 

to see this issue. [PR747914: This issue has been resolved.] 

• Traffic fails to go through service output when it comes from MPLS core and is routed 

inside VRF without vrf-table-label configured. This should NOT work on all types of 

FPCs except MPCs on MX. This PR fixes the problem on MPCs. [PR749661: This issue 


• When LSP configured with auto-bandwidth switches from primary path to secondary 

path, bandwidth estimation on the secondary path may be under-estimated. Due to 

under-estimation, overflow sample count may get reset. [PR752777: This issue has 


• The kernel may crash at tag_mtu_calc when the Routing Engine attempts to send a 

packet larger than the configured MPLS MTU, warranting fragmentation (over a LSP) 

using a l3vpn-composite-nexthop. For the issue to occur both must be true: 1) 

l3-composite-nexthop knob must be turned on. 2) MPLS MTU must be manually 

configured by the user. [PR755950: This issue has been resolved.] 

• On TRIO platforms, when switch L2 MPLS packets on egress PE routers, the inner MPLS 

label TTL value is checked and if valid decreased by 1. During the egress process, the 

TTL value is rechecked. If the value is 1 at this point, the packet is sent to the Routing 

Engine instead of being forwarded out the interface. [PR776203: This issue has been 

resolved.] 


• Packets exchanged b/w logical routers within the same physical router over logical 

tunnel (LT) interfaces will not have their TTL decremented. [PR685639: This issue has 


• Under very special race conditions the MPC CPU might stop processing and will be 

reset because of Level3/Level 2 watchdog expiration timer. Potential exposure are 

high load of traffic send to the Host. The following syslog message will be reported in 

the syslog once MPC reboots. "fpc[x] MPC: Reset reason (0xc): Level3 watchdog, 

Level2 watchdog" [PR717899: This issue has been resolved.] 


233


• enabling of Dynamic Profile versioning is not supported if dynamic profiles have been 

already configured on the router. If you deactivate existing dynamic profiles in order to 

enable and commit dynamic profile versioning, profile version numbers are not 

subsequently incremented. As a workaround, you must delete all existing dynamic 

profiles before you enable profile versioning, and then reconfigure the dynamic profiles. 


• This is an issue during the passing of timestamp message from kernel to rmopd for 64 

bit JunOS.Fix will be checked in soon. [PR746428: This issue has been resolved.] 

• If a filter contains multiple prefix actions and the filter is applied, changing one prefix 

action referenced by this filter might crash NPCs. The change on a prefix action could 

be direct or indirect (For example:, changing the policer reference by this prefix action). 

The workaround is detaching all such filters before changing a prefix action and then 

applying the filters back after the change. [PR750370: This issue has been resolved.] 

• When CoS rewrite is configured for an IRB interface, and the IRB interface participates 

in L2 multicast, the copies sent over the physical interface will not have the CoS rewrite 

applied. This issue is applicable only when the chassis is configured in the "enhanced-ip" 

mode. [PR754720: This issue has been resolved.] 

• A MPC-* FPC installed in a MX240/480/960 router or the integrated TFEB of a 

MX5/10/40/80 router may crash and reboot when the unsupported command show 

route hw nhs is executed from the FPC cli. This command is unsupported and should 

not be used without the explicit instructions of JTAC. It is not needed for the normal 

operation of a Juniper router. [PR772413: This issue has been resolved.] 

• If "source-filtering" is turned on under an interface, packets with multicast destination 

mac address will get dropped. Such packets are used by applications like CFM. The 

multicast mac addresses cannot be explicitly added to be accepted using the CLI. 


• Traffic-control-profile applied on LT logical interface used to terminate a vpls instance 

has no effect and the logical interface is not shaped. [PR773764: This issue has been 

resolved.] 

• Customers using Junos OS Release 11.4R3.6 code on MX routers with MPC 3D 16x 10GE 

(Agent Smith) line cards may experience issues with interfaces on these line cards. 

Some interfaces on the MPC 3D 16x 10GE (Agent Smith) line cards may be reported 

as UP ("Enabled" and "Physical Link UP")in the show interfaces command. 

However, show interfaces terse? command for the same interface reports 

that interface as DOWN (Admin - UP and Link Protocol - DOWN). The link lights at 

both ends of the link will be GREEN ? thereby indicating connectivity. However, no 

traffic passes through the affected interfaces. This issue was seen on interfaces that 

were part of Aggregated Ethernet (AE) bundle as well as on interfaces that were NOT 

part of the aggregate Ethernet bundle. In addition, "Wedge Detected" messages may 

be seen in the syslogs and in the telnet/ssh session to the router. This behavior was 

NOT seen with DPC hardware. This is documented in PR 776727 and upgrading to Junos 

OS Release 11.4R3.7 fixes the above mentioned issues. [PR776727: This issue has been 

resolved.] 

234 




• The show bgp group output is updated to new multiline format in order to display the 

full name of table bgp.rtarget.0. [PR696476: This issue has been resolved.] 

• ISO/CLNS prefixes with more than /152 VPN prefix length when advertised by BGP 

across VPN core causes BGP adjacecny flap since the remote BGP rejects the same 

prefix as invalidate address. This is because the ISOVPN draft allows only up to /152 

prefixes. [PR742491: This issue has been resolved.] 

• Pruned multicast traffic continues to flow from the source even when receiver leaves 

the multicast group for Junos OS Releases 10.4R8.5 ,10.4R9,10.4R9.2. [PR746474: This 


• Route advertisement stops for RT family enabled BGP peers after VRF is deactivated 

and activated. This issue is only seen with RT enabled peers and non-stop routing 

enabled. [PR749288: This issue has been resolved.] 

• If there are some link micro flapping, it may bring the BFD into a problematic state. As 

a result, for next event of BFD state down, it will not bring down the client sessions like 

OSPF, ISIS, BGP, etc. [PR749388: This issue has been resolved.] 

• The routing protocol daemon (rpd) crashes and dump a core file after executing show 

ospf context-identifier area command which is given for an area that has not 

been configured. The issue is caused by insufficient check code. [PR750914: This issue 


• The multipath flash mechanism runs unnecessarily when BGP multipath is configured 

for inet-vpn routes. When large amounts of inet-vpn routes change, there is a noticable 

delay in convergence for the inet-vpn routes. [PR751469: This issue has been resolved.] 

• If BGP receives an ISO-VPN prefix of length 248, i.e. ISO part of prefix contains 

NSEL-byte, BGP session will be reset. This is according to standards, but it would be 

good if BGP can handle this gracefully w/o resetting BGP-session. This PR makes BGP 

handle it gracefully, by ignoring the NSEL byte received in the ISO-VPN prefix. [PR771835: 


• Customer needs these debug logs to be changed to severity LOG_DEBUG. "mcsn[91713]: 

krt_decode_nexthop: Try freeing: nh-handle: 0x0 nh-index: 1049040 fwdtype: 2" This 

was introduced as part 11.4 with severity set to "LOG_INFO" (will not be seen with 

earlier releases). This is used as a debug log and is harmless. "mcsn[91713]: Received 

MC_AE_OPTIONS TLV for intf device ae1; mc_ae_id 0, status 2" This was introduced 

as part of RLI 8857 in 10.0 (reference from PR-411614). This also has a severity of 

"LOG_INFO" and is part of the rpd-infra that is used by mcsnoopd. [PR772063: This 


• Routing protocol daemon (rpd) might dump a core file while processing malformed 

RIP or RIPng message from neighbor during adjacency establishment. [PR772601: This 


• Limited Support for multiple area TLVs in a single ISIS Hello message: When many 

area TLVs are found in a single IS-IS Hello packet, L1 adjacencies may not be formed 

correctly and can be stuck in the initializing state. Currently, there are no identified 


235


workarounds; however, this does not impact L2 adjacencies. [PR775852: This issue has 



• When you pump in more than 2.1 Million passive monitoring flows into Monitor-II PIC, 

the router might not send memory overload SNMP trap. [PR677162: This issue has been 

resolved.] 

• When sending traffic through IPSec tunnels for above 2.5Gbps on an MS-400 PIC, the 

Service-PIC might bounce because of prolonged flow control. [PR705201: This issue 


• If the Service PIC processing DS-Lite packets receives packets from overlapping IPv4 

addresses present behind different B4s at the same time then there is a possibility that 

the PIC will crash with a similar coredump. [PR711307: This issue has been resolved.] 

• "linerate-mode" may not be applied correctly to interfaces when first configured on a 

PIC which does not support "linerate-mode" and later on replace the first PIC with a 

second PIC which supports "linerate-mode" [PR734887: This issue has been resolved.] 

• In Junos OS Releases 10.4 and later, the number of outstanding IPSec tunnels has 

changed to be 50 tunnels instead of 200 outstanding tunnels in previous releases. 


• * Issue here is observing DCD_CONFIG_WRITE_FAILED with "Device not configured" 

error when system is rebooted with rlsq configuration. * Reason why we are seeing this 

error, service-pic is unable to create control logical interface hence sp interface is down. 

Since device is not there and while trying to add lsq ifls, observing the error. After some 

retries of booting sp pic (say 1 or 2 tries and came up), not seeing these errors and the 

bundles are UP. * Workaround here we can try deactivate interfaces -> request system 

reboot -> activate interfaces , instead of only request system reboot. [PR741121: This 


• This PR enables visibility of Address Pool Paired out of port errors via the cli command 

show services nat pool detail: 

user@router-re0> show services nat pool detail 

Interface: sp-7/0/0, Service set: nat44 NAT pool: public-pool, Translation 

type: dynamic 

Address range: 100.100.0.1-100.100.0.254 

Port range: 512-65535, Ports in use: 64512, Out of port errors: 0, Max ports 

used: 64512 

AP-P out of port errors: 440601


seen in the following output: user@router> show services stateful-firewall flow-analysis 

| display xml 

 

sp-0/0/0 

.... output omitted .... 

sp-0/1/0 

.... output omitted 

.... ... output omitted .... The Junos OS software has 

been modified to include a new tag which is the parent 

of both the tag and the 

tag thus tying the pic name with existing flow 

analysis details: user@router> show services stateful-firewall flow-analysis | display 

xml 

 


VPNs 

• An optimization has been implemented with BGP-MVPN nexthop infrastructure which 

will improve scalability in some multi-dimensional scaling scenarios with aggregate 


• Under certain circumstances a vrf-import policy's term with the "accept" action that 

matches the BGP VPN route based on the criteria different than the target community 

can reject the matching route. [PR706064: This issue has been resolved.] 

• Currently, MVPN Leaf-AD routes with IR provider tunnels are sent without the PMSI 

attributes. These routes should be sent with the PMSI attributes. The label will be the 

same label as advertised in the Type 1 route. [PR717451: This issue has been resolved.] 

• With BGP MVPNs when there are many interfaces in the vrf, it is possible that RPD may 

core. If a forwarding entry has a large number of outgoing interfaces, this memory error 

will occur. The exact number of oifs needed to trigger this issue is not known. [PR749379: 


• In NG-MVPN with a multihomed source attached to ingress PE, when original-DR goes 

down and then comes back to claim its role as DR, the other node will loose its 

intermediate DR-role and withdraw its type 5 AD-route. However the new DR which 

comes back will not advertise a type 5 AD route. As result of this misbehaviour, neither 

the non-DR nor the DR will advertise a type 5 AD route in the re-convergence case and 

hence no egress-PE could join the source. [PR754222: This issue has been resolved.] 

• The issue happens when the ingress PE receives the type-4 leaf AD route before 

discovering the egress PE as a neighbor using a type-1 route. PE ignores the type-4 leaf 

AD route as there is no nbr. When the ingress PE receives the type-1 route, it only 

processes inclusive p-tnl and since it did not add the unicast IR tunnel as a leaf to the 

spmsi tunnel, the egress PE doesn't receive the traffic. [PR755209: This issue has been 

resolved.] 

• When the label for intra-AS AD route changes, it is not reflected in the intra-as AD route 

generated to the MVPN PE peers as a result the peers still use the old label information 

and results traffic drop. [PR771059: This issue has been resolved.] 





• The IQ2E rate limit fails to function on PPPoE subscribers. [PR674857: This issue has 


• The configuration, set class-of-service interfaces all unit * classifiers exp , causes 

the exp classifier exp-default to be attached to every label switched interface (LSI) of 

the router. This is regardless of the specified, and the configuration at the 

[edit class-of-service routing-instances] level. [PR710427: This issue has been resolved.] 

• cosd crash is triggered by the ae* interface configuration under the class-of-service 

stanza. [PR724638: This issue has been resolved.] 

238 



• Sometimes, the aggregated Ethernet bundle or some member links of the aggregated 

Ethernet bundle are missing in the Packet Forwarding Engine cos classifier binding 

command output. This causes the egress cos/dscp value to change to unexpected 

values. Hence CoS does not work as expected. [PR727949 This issue has been resolved.] 

• Deactivating the interface that has chassis-derived scheduler with wild cards configured 

causes Cosd write-failed error messages. [PR729249: This issue has been resolved.] 

• The issue is seen on IQ2, and IQ2E PIC on the M Series platform. When a port and a 

logical interface on the port is configured with the same shaping rate in the egress 

direction, and the scheduling mode is changed, the transmit rate in ingress direction 

may go down. [PR730428: This issue has been resolved.] 

• Changes related to Class of Service settings might affect interface byte counter 

accuracy. [PR731948: This issue has been resolved.] 

• This issue is specific to traffic-control profile and scheduler-map constructs in the 

class-of-service hierarchy. It is a Trio specific issue. When you have a traffic control 

profile or scheduler-map that is bound to a physical interface hosted on one FPC and 

the same traffic-control profile is bound to a logical interface hosted on a different 

FPC, after you move the traffic control profile from the physical interface to its own 

logical interface, scheduling on this logical interface may not work as expected. You 

need to have a logical interface on another Packet Forwarding Engine complex referring 

to the same traffic-control profile for this issue to happen. Then moving the traffic 

control profile from logical interface to the physical interface and then back again may 

cause this issue. As a workaround, instead of having only one traffic control profile and 

moving it from the physical interface to the logical interface, you can define two 

separate traffic control profiles - one exclusively for the physical interface and other 

for the logical interface. These two traffic-control profiles instead of pointing to one 

scheduler-map would have two different scheduler-maps. The contents of traffic 

control profiles as well as scheduler maps would be the same. [PR735870: This issue 


• Junos OS Releases 11.4R1 and 11.4R2 support hierarchical policers on all Trio platforms 

except MX80 platforms. Junos OS Release 11.4R3 supports hierarchical policers in 

MX80 platforms as well. [PR737500: This issue has been resolved.] 


• When you configure output sampling in a routing instance, the commit fails, throwing 

up an error message indicating that the output rate was not specified. However, when 

you configure output sampling in a global routing instance, the commit succeeds. A 

fix was made to accept the configuration without the rate command so that when you 

configure output sampling in a routing instance, the commit succeeds. [PR710741: This 


• On MX Series routers with DPC/FPC, M320 with E3-FPC, M120, and M7i/M10i with 

E-CFEB, in larger scale environments or negative conditions, core files might be 

generated on the Packet Forwarding Engine caused by memory corruption. [PR710853: 


• You cannot convert certain VPLS filters from the Ichip format to the ABC format on 

an ABC-based FPC on M10i and M7i routers. Therefore, these VPLS filters cannot be 


239


applied correctly on the ABC-based FPC, thereby causing packet drops. The loss in 

traffic is recorded as a firewall drop on the FPC. This problem is specific to certain VPLS 

filters on an ABC-based FPC in M10i and M7i routers. [PR718066: This issue has been 

resolved.] 

• On MX Series routers , the “Transit Statistics Input bytes” counter is randomly modified 

by mistake and does not increment from that moment on. [PR721445: This issue has 


• When you configure VRF on a router and the routing instance corresponding to the 

VRF is changed, the following message is seen on the FPC: "Multiple Free :jt_mem_free." 

This might result in Jtree memory corruption and thereby affect forwarding 

non-deterministically. [PR730686: This issue has been resolved.] 

• When you upgrade to Junos OS Release 11.4R1, you will experience an important increase 

in the response time to snmpbulkwalk queries retrieving statistics from the Packet 

Forwarding Engine. [PR731833: This issue has been resolved.] 

• When bringing up a large scaled of subscribers, the subscriber management 

infrastructure daemon (smid) might keep restarting. [PR733712: This issue has been 

resolved.] 

• When sampling is enabled under forwarding-options, the churn of PPPoE subscribers 

causes the number of sample memory allocations to continuously increase. [PR741218: 


• When the number of MAC addresses is specified by the interface-mac-limit command, 

but not reflected on the screen, the number of MAC addresses remains at the default 

value. [PR743934: This issue has been resolved.] 

• When "interface:accounting-profile" is configured on MX Series platforms running 

Junos OS Releases 10.4S8,10.4R9.2, and 11.2R1 or later, there are memory leaks, the 

rate of which depends on the number of interfaces with "accounting-profiles". During 

testing with 1000 logical interfaces, we noticed up to 50 MB of memory leaks every 

five minutes. [PR744537: This issue has been resolved.] 


• MX Series routers incorrectly display DHCP subscribers in the output of the show 

subscribers output when some DHCP clients are in the "init" state. [PR710594: This 


• PR 710339 has changes to NACK COA with invalid parameters. However it requires a 

dummy $junos-cos-scheduler in the hierarchical CoS definition. This fix eliminates that 

requirement. [PR728756: This issue has been resolved.] 

• Under certain circumstances while performing MIB walks you can get a mib2dcore. 

The core situation will recover and normal operation will continue without any 

intervention. All other router functionality will continue as usual. [PR740692: This issue 


240 




• During ISSU on MX Series platform, if an MPC has any non-Ethernet MICs plugged in 

slot 0, the ISSU procedure will not request offline confirmation for mics in slot-0. 


• This issue is triggered when you commit sync the following two operations together: 

• Set mpls max-labels to 4: set interfaces unit family mpls 

maximum-labels 4 

• Enable graceful Routing Engine switchover: set chassis redundancy 

graceful-switchover 

If graceful Routing Engine switchover had been enabled first and then mpls max-labels 

was set to 4 in different commits, this issue would have not been exposed. It is always 

safe not to merge any other operations with enabling graceful Routing Engine 

switchover. As a workaround, avoid merging any operations with the enabling of graceful 

Routing Engine switchover operation, in the same commit. Once the issue is seen, on 

the backup Routing Engine, run the following command on the cli, to restart the 

kernel-replication process, to make sure that all the states are resynced to the backup 

Routing Engine from the master Routing Engine: restart kernel-replication gracefully. 


• The MPC can generate core files during ISSU. This issue is intermittent. [PR744992: 


• This issue is seen only where there are tunnel physical interfaces in a configuration on 

MPC1/2 (QX based) neo MPCs and an ISSU is attempted from a Junos OS Release 

11.2-based build. If attempted, the tunnel physical interfaces will stop forwarding after 

the ISSU. To fix this issue, deactivate and activate the tunnel physical interfaces. This 

can be done by deactivating and activating chassis fpc pic tunnel-services. 



• Because of certain changes to the Junos OS multicast infrastructure in Junos OS Release 

11.1 and later, Unified ISSU is not supported when upgrading from Junos OS Release 

10.x to 11.1 or 11.2 on M Series, T Series, and TX Series devices with multicast 

configuration. 

Attempting a unified ISSU might cause undesirable results such as a kernel or routing 

protocol process crash in such scenarios. Prior to the fix for this PR, the backup Routing 

Engine crashes when performing ISSU . After the fix to this PR, backup Routing Engine 

won't crash, but it displays error messages. ISSU fails regardless of the fix for PR in 

above given scenario. [PR675582: This issue has been resolved.] 

• Under certain rare conditions Kernel "devfs" might become locked. This lock might 

cause other processes that use /dev/filesystem to wait. Eventually some processes 

start spawning until reaching the maximum limit, as a consequence the Kernel crashes. 

The following message logged by the kernel is an indication that the system is 

approaching the maximum number of active processes: 


241


/kernel: %KERN-2: nearing maxproc limit by uid 0, please see tuning(7) and 

login.conf(5). /kernel: %KERN-2: Process with Most Children- 1:init - Children 

- 365 


• Specially crafted kernel routes that are generated based on directly connected networks 

(clone routes) might introduce reference count inconsistencies upon link flap if the 

clone routes can be rewired to a different interface. This can happen if the longest 

prefix match finds another destination for the IP address of the flapping interface. If 

the parent reference count is wrongly reduced to zero, the kernel will panic when it 

tries to delete one of the remaining child routes. [PR685941: This issue has been 

resolved.] 

• /mfs partition has only 64 MB when only compact flash is available as storage media 

and for large configuration file is possible to not be able to hold it. So, when HDD is 

broken and the /mfs partition is not large enough to store the configuration files, the 

Routing Engine does not boot. [PR720540: This issue has been resolved.] 

• When Nonstop active routing (NSR) is enabled and we shutting down bgp on the 

secondary Routing Engine or we are switching over from secondary Routing Engine to 

primary Routing Engine , we may hit the issue in case there are some packets to be 

processed in the PRL layer. This is a race condition between the socket close and fewer 

packets that come late and are queued up in the PRL layer to be processed. This 

happens because during socket close SA association is flipped from socket to 

timed-wait socket and TCP layer does not know about this flip. TCP layer, blindly 

accesses SA field which is now NULL and crashes. [PR726671: This issue has been 

resolved.] 

• The ether type is set to IP when it should be set to MPLS. [PR731925: This issue has 


• Routing Engine generates core files because of loss of soft watchdog after configuration 

change. [PR736927: This issue has been resolved.] 

Interfaces 

• Under rare circumstances, PPPoE subscribers over dynamic VLANs can be left stranded 

in INIT state without an underlying demux0 interface. This does not prevent a PPPoE 

subscriber from creating new sessions and successfully logging in. [PR697488: This 


• When you issue NTP-related show commands, such as show ntp status, incorrect 

output might be displayed. [PR722528: This issue has been resolved.] 

• Primary/Secondary DNS VSA values are not passed to PPP clients through IPCP before 

Junos OS Release 11.4R3. [PR724418: This issue has been resolved.] 

• When the length of the received packet exceeds the available buffer length, jpppd 

might crash. [PR726254: This issue has been resolved.] 

• With autosensed VLAN configured, under certain conditions, autoconfd (the VLAN 

autosensing daemon) dumps core files because of memory corruption. [PR728020: 


242 




• The password recovery process does not work on some MX80 routers. [PR585092: 


• In some scenarios when VRRP is enabled on an aggregated interface and the interface 

is a VRRP backup, pinging the private IP address of the aggregated interface fails. 


• The following message might be displayed during bootstartup on MX5, MX10, MX40, 

and MX/80 platforms. 

Chassis control process: WARNING: Chassis configuration for network services 

has been changed. A system reboot is mandatory. Please reboot the system NOW. 

Continuing without a reboot might result in unexpected system behavior. 


• The backup Routing Engine crashes with the following panic: “rnh_index_alloc: nhindex” 

when the LSQ bundle with ATM member links flaps randomly because of reset/reboot 

of the remote end device. [PR675650: This issue has been resolved.] 

• On an MLFR uni-nni RLSQ interface, Multilink input statistics do not work after 8 logical 

units (dlci's). This does not have any impact on the Multilink traffic. [PR688197: This 


• When certificate key size is 2048 bytes and total combined certificate request size is 

greater than 4096 bytes, the PKID service might crash on certificate enrollment. 


• When both IPv6 multicast and unicast traffic is input, changing the MTU for the output 

interface causes incorrect counter for "Output packets". [PR700018: This issue has 


• Standby SCG keeps staying Deviation as "unknown" and Status as "present" after 

Routing Engine master switch. [PR701800: This issue has been resolved.] 

• When a multiservices PIC is switched over and one link in the RLSQ bundle is down, 

and the other side is set to remote-loopback, all BGP and Bidirectional Forwarding 

Detection (BFD) sessions go down [PR701915: This issue has been resolved.] 

• While using VRRP with logical systems, sometimes the show vrrp command for logical 

systems does not display information for all groups. You can retry the show command 

in such a case.[PR704068: This issue has been resolved.] 

• Regarding the K2-Routing Engine (64-bit Routing Engine) when speed/link mode are 

statically configured on the router for the fxp0 interface, the driver for fxp0 accepts 

the configuration from DCD process, but does not propagate the setting to the hardware 

driver. Instead, the driver setting is forced to auto-negotiate. Thus, as the fxp0 interface 

is auto-negotiating, and the far end device is forced to 100/full, the auto-negotiation 

on fxp0 will detect the speed but not the duplex and defaults that duplex to half-duplex. 


• On IQE PICs, in case of PPP encapsulation, if an interface's admin status is changed 

from disabled to enabled, it may result in the interface on the peer end flapping 


243


(operstatus changing from DOWN to UP to DOWN and back UP again) occasionally. 


• In a Multi-Chassis Link Aggregation Group (MC-LAG) Active/Active environment with 

Aggregate Ethernet (AE) interface as Multi-Chassis Link (MC-Link), after graceful 

Routing Engine switchover, the Inter-Chassis Data Link (ICL-link) interface might be 

accepted as the MAC destination interface in the ARP Cache table and ignoring ARP 

request from client from MC-Link interface. As a consequence, traffic might be lost. 

Only after ARP aging timeout in the Routing Engine, the Routing Engine will send the 

ARP request and traffic will be restored. [PR706091: This issue has been resolved.] 

• Router might crash while trying to bring up 52k PPPoEv4 subscribers with 

service-accounting at login time. [PR706495: This issue has been resolved.] 

• This issue can be seen after RSVP LSP are reestablished because of optimization or 

bandwidth adjustment. [PR706635: This issue has been resolved.] 

• Interface optics-options do not work as expected on MX-MPC2-3D and 

MX-MPC2-3D-EQ. [PR706824: This issue has been resolved.] 

• In Active/Active MC-LAG if we power off both PEs and start only PE, MC-Links will not 

come up (we need an initial TCP connection for MC-LAG finite state). [PR707494: This 


• Port(s) in PIC DPCE-R-4XGE-XFP might get stuck in down status after power-up 

sequence such as for example upon a reboot of the router or FPC. If encountered, 

recovery mechanism is to toggle the LAN/WAN phy mode. This issue does not occur 

upon a link flap event. The configuration below shows how to toggle the LAN/WAN 

phy mode. Under the edit interface hierarchy execute the following 

commands: 

set framing wan-phy 

lab@LABROUTER# show 

framing { 

wan-phy; 

} 

commit 

Now delete the interface framing configuration: 

delete framing 

show 

commit 


• If we have a RLSQ interface configured under a routing instance and after we perform 

deactivate or activate on the routing in certain scenarios the ingress traffic from the 

member media links are not sent to the correct LSQ PIC and hence we see a traffic 

black hole. [PR708720: This issue has been resolved.] 

• instance-import under routing-options hierarchy might lead to commit error on TX 

Series and TXP Series routers. [PR709337: This issue has been resolved.] 

• On MX Series routers using DPCE-R-Q-20GE-SFP (DPCE 20x 1GE R EQ) cards broadcast 

and multicast frames are not forwarded correctly to the IRB interface. 

244 



If a bridge domain or VPLS routing instance contains CE-facing interfaces located on 

built-in PIC 1 of a DPCE-R-Q-20GE-SFP (DPCE 20x 1GE R EQ) card then broadcast 

and multicast frames received on those specific interfaces are not forwarded correctly 

to the IRB interface associated with the bridge domain or VPLS routing instance. 

The fact that broadcast and multicast frames are not forwarded correctly to the IRB 

interface can cause different behaviors for protocols that rely on this kind of traffic. 

For example, the IRB interface will not receive ARP requests from the CE attached to 

that interface or routing protocols running between the CE and the IRB interface will 

fail to build adjacencies. 

This problem is restricted to DPCE-R-Q-20GE-SFP (DPCE 20x 1GE R EQ) cards for MX 

Series routers and is restricted to interfaces in the second half of the card (situated on 

built-in PIC 1). 

If the DPCE-R-Q-20GE-SFP is installed in an MX Series router in slot 1 as in the following 

example: 

user@router-re1> show chassis hardware 

Hardware inventory: 

Item Version Part number Serial number Description 

Chassis 

JN11BD460AFB MX480 

 

FPC 1 REV 25 750-017679 ZB7257 DPCE 20x 1GE R EQ 

CPU REV 04 710-022351 YX4734 DPC PMB 

PIC 0 BUILTIN BUILTIN 10x 1GE(LAN) EQ 

Xcvr 7 REV 01 740-014132 72152014 SFP-T 

PIC 1 BUILTIN BUILTIN 10x 1GE(LAN) EQ 

Xcvr 7 REV 01 740-013111 70731026 SFP-T 

 

Only interfaces named ge-1/1/* will be affected by this problem. Interfaces named 

ge-1/0/* although situated on the same DPC will forward broadcast and multicast 

frames correctly. 

Other types of DPC or MPC cards for MX Series routers are not affected by this problem. 


• FPCs might reboot in a scaled environment, or log messages complaining that PFEMAN 

thread is hogging the CPU. [PR718774: This issue has been resolved.] 

• No NTP Time sync among Routing Engines in Virtual Chassis. The fix is available in 

Junos OS Release 11.4R3 and later releases. [PR719901: This issue has been resolved.] 

• Configuration write fails for an logical interface prior to reaching the max logical interface 

limit for a 4x CHDS3 IQ PIC. [PR711654: This issue has been resolved.] 

• Because of a bug in the Junos OS kernel code, various types of interfaces show up as 

member links of an aggregated Ethernet interface, though these same interfaces are 

not configured to become part of a given aggregated Ethernet bundle. For example, 

the interface extensive for an aggregated Ethernet bundle configuration with xe-8/1/0 

and xe-4/3/3 as member links: 

LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx 

xe-8/1/0.0 223171 223707 0 0 

xe-4/3/3.0 223171 223716 0 0 

lc-3/1/0.32769 0 0 0 0 


lc-3/1/0 is incorrectly added. 

[or] 

xe-7/1/3 and xe-7/2/0 are not configured to be member links of ae1 

Physical interface: ae1, Enabled, Physical link is Up 

 

LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx 

xe-7/1/3.0 0 0 0 0


from the [edit system ddos-protection violation] hierarchy level, and that hierarchy 

level has been removed from the CLI. 

The show ddos-protection protocols command now displays Partial in the Enabled 

field to indicate when some of the instances of the policer are disabled. The Routing 

Engine Information section of the output now includes fields for bandwidth, burst, and 

state. The show ddos-protection protocols parameters command and the show 

ddos-protection protocols statistics command now include a terse option to display 

information only for active protocol groups-that is, groups that show traffic in the 

Received (packets) column. The show ddos-protection protocols parameters command 

also displays part. for policers that have some disabled instances. [PR722873: This 


• KRT Q might get stuck in a system with a dual Routing Engine running NSR and per 

packet load balancing: 

• The master Routing Engine and RPD installs a unicast next hop for a route. 

• The master Routing Engine and RPD then installs another next hop for the same 

route effectively changing the next hop for the route from unicast to a unilist. 

• The backup RPD does not get a next-hop delete for the old unicast next-hop. Instead, 

the backup RPD only achieves a route change to point to the new unilist. 

• NSR switch over occurs and the master ship is toggled. 

• The new master RPD changes route to point to unilist. This will release reference on 

the single path route. Since RPD has next-hop ID cached for it, RPD tries to delete 

the unicast next-hop in the kernel. 

• KRT Q gets stuck in 'EPERM –Jtree walk in progress' in the new master Routing 

Engine. 


• Two new configuration statements are provided for [system services ssh] for configuring 

a client-alive mechanism. The client-alive mechanism is valuable when the client or 

server depends on knowing when a connection has become inactive. It differs from 

the standard keepalive mechanism because the client-alive messages are sent through 

the encrypted channel. The client-alive mechanism is not enabled by default. To enable 

it, configure the client-alive-count-max and the client-alive-interval. This option applies 

to SSH protocol version 2 only. [PR722932: This issue has been resolved.] 

• If LSQ PIC is flow controlled for a period of five seconds or longer, the kernel does close 

the PFEMAN socket to the LSQ PIC. Once the back-pressure is cleared, the PFEMAN 

socket gets not reconnected and the PIC does not close the PFEMAN socket to the 

Routing Engine as the TCP Reset frame is dropped already. From this time onwards, 

any bundle state changes are not propagated from the Routing Engine to the LSQ PIC. 

The following sequence of message log entries illustrates the symptom: 

Dec 12 01:53:21 router fpc2 Transient flow-control asserted by MAC0 on sp-2/1 

for 1 seconds 

Dec 12 01:53:22 router fpc2 Transient flow-control asserted by MAC0 on sp-2/1 

for 2 seconds 

Dec 12 01:53:23 router fpc2 Prolonged flow-control asserted by MAC0 on sp-2/1 


247


Dec 12 01:53:25 router /kernel: pfe_send_failed(index 9, type 20), err=32 

Dec 12 01:53:25 router /kernel: pfe_listener_disconnect: conn dropped: listener 

idx=7, tnpaddr=0x12020080, reason: none 

Dec 12 01:54:33 router fpc2 MAC flow-control cleared on sp-2/1 

A manual LSQ PIC restart is needed to recover from this condition. [PR723663: This 


• Now the clear oam ethernet link-fault-management state intf command resets local 

OAM loopback (if enabled) along with the existing behavior of resetting discovery state 

machine. [PR723739: This issue has been resolved.] 

• Both Routing Engines might crash and dump VMcore, when PIC receives FRF.15 packets 

as payload of FRF.16 encapsulation. This issue occurs only in the environment in which 

RLSQ is configured with hot-standby option. [PR725162: This issue has been resolved.] 

• Run time change in ’no-accept-data/accept-data’ fails to take effect in few cases for 

Inherit group. If ping to VIP is not required then don't configure ’no-accept-data’. It is 

disabled by default. By default, ping to VIP will fail. restart vrrp will resolve the issue. 

Software upgrade from other releases to Junos OS Release 11.4R2 with an existing 

'accept-data/no-accept-data' configuration is not impacted. 

'accept-data/no-accept-data' configuration will work as designed after software 

upgrade. This issue is not applicable for Active group. [PR725556: This issue has been 

resolved.] 

• COC12 interface stays in the ’down’ state for extended periods of time when deleting 

the local loopback configuration. [PR726762: This issue has been resolved.] 

• The PPP daemon generates core files when there are invalid (or unexpected) packets 

received at the local router during LCP state change. A warning message is supposed 

to be generated and return a ?junk? value to the previous function. The ?junk? value 

was incorrectly returning causing the core files. The fix for this issue is to add additional 

an error check in the function which generates the ?junk? value. PPP will recover after 

the core. [PR728833: This issue has been resolved.] 

• If the Inter Chassis Link (ICL) between MCAE nodes is down to begin with when Inter 

Chassis Control Protocol (ICCP) restarts, the MCAE interfaces continue to stay in 

standby state and do not become active. [PR729043: This issue has been resolved.] 

• In MX Virtual Chassis environment, Virtual Chassis Control Protocol Daemon (VCCPD) 

might get starved out under heavy load. This will result in breaking the Virtual Chassis. 


• When Graceful Routing Engine Switchover is enabled on a system, during graceful 

Routing Engine switchover or re-synchronization activities between the Routing Engines, 

the Kernel might dump core files which is because of incorrect code handling of a 

background clean-up thread. [PR729325: This issue has been resolved.] 

• Traffic for certain l2circuits might stop working after Routing Engine switchover. The 

same issue was also noticed after adding an logical interface/VLAN to the interface 

that has vlan-ccc ifls associated to l2circuits. The workaround is delete or add 

encapsulation on the vlan-ccc unit interface associated with the affected l2circuits. 

This issue is related only to 4x10GE(LAN/WAN) XFP PIC (see PR718495) and 100GE 

CFP PIC. [PR730249: This issue has been resolved.] 

248 



• Local Loopback on a SONET interface seems to be intermittent with hold-timers 

configured. [PR730844: This issue has been resolved.] 

• Configuration changes resulting in an indirect to change from a unilist to a unicast could 

result in an ADPC/SDPC crash. [PR731727: This issue has been resolved.] 

• An SNMP trap is not generated when Fan or Blower is not spinning. [PR732363: This 


• The software information about Ethernet MICs and non-Ethernet mics are stored in 

Junos OS in different structures. The crash occurs because of memory corruption 

caused by the FRR-marking feature in the non-Ethernet-mic structures. The PR has 

been fixed in Junos OS Release 11.4R2 and later. [PR733566: This issue has been 

resolved.] 

• While doing traceroute Hard Coded Address "10.0.0.1" can be seen as one of the Hop 

Address when there is no valid Address for the Incoming Interface. [PR734058: This 


• FPC crashes is because of a port conversion corner case that was seen when deleting 

2 VCPs that resided on the same pic. The problem is not easy to reproduce. The problem 

might be reproduced by deleting VCPs that reside on the same pic while the kernel is 

under load. As a workaround, delete subsequent ports only after verifying a network 

port was created for a deleted VCP. When deleting VCPs that coexist on the same pic, 

ensure the network port for the previously deleted VCP exists before deleting the next 

VCP. This ensures conversion for the first deleted port has been completed and a 

network port for the 'to-be-deleted' port is not yet created. [PR735122: This issue has 


• When Ethernet OAM is enabled on member links of a lag group the peer address 

reported in the output of the show oam ethernet link-fault-management command 

displays the peer address as the lag group's MAC address. [PR735436: This issue has 


• Messages such as “Dispatching Synchronous Ethernet Capability TLV” are informational 

or debug messages and can be safely ignored. [PR735516: This issue has been resolved.] 

• When PPPoE subscribers dial in and dial out, then kernel task devbuf will have a memory 

leak. [PR735637: This issue has been resolved.] 

• When Active/Active (A/A) mode is enabled and the aggregated Ethernet interface 

name and ICL link start with the same digit, the aggregated Ethernet bundle, that is 

going to the MC-LAG device providing connectivity to the Core network, does not come 

up. This issue is seen in MX Series platforms.[PR736012: This issue has been resolved.] 

• Whenever there is any alarm (RDI-L, RDI-P or AIS-L) on the interface, on switchover 

in transmission, 10g port configured in WAN-PHY mode on DPC 4x 10GE R, with 

hold-time down time of less than 1 second, flaps even before the down hold time is 

expired. Code has been modified now to address this issue and the fix is available in 

Junos OS Releases 11.4R3, 11.2R7, 12.1R2, 10.0R5, and 10.4R10. [PR736477: This issue 



249


• Chassisd core might be generated while performing Routing Engine switchover. It is 

caused by interrupt storm when master Routing Engine transition to backup and 

chassisd can be stalled. [PR738084: This issue has been resolved.] 

• When VPLS neighbor is configured under the user-configured mesh group, the flood 

route for LSI logical interface is deleted. This issue is observed in M Series routers as 

flood routes are maintained per logical interface. The problem could occur in any 

dynamic logical interface. [PR736993: This issue has been resolved.] 

• Jtree Memory full condition can lead to junk value being stored in the composite next 

hop structure. A change operation on the composite next hop can lead to crash because 

of junk value stored in its structure. [PR739631: This issue has been resolved.] 

• CB intake temperature shows as empty for backup CB for a few seconds when backup 

Routing Engine is rebooted or halted. [PR740453: This issue has been resolved.] 

• If the configuration has routing instances with the character "/" in its name and the 

routing instance has VPLS family configured under it, a configuration change at the 

top level causes IFFs to get deleted and added back, which results in flapping of the 

respective VPLS connections. [PR740950: This issue has been resolved.] 

• On Ichip platforms, when there are more than 16 ECMP routes exist, after some of the 

routes flapping (but the available ECMP routes still more than 16), the memory on FPC 

might be corrupted and error messages such as "jtree memory free using incorrect 

value" might be displayed. [PR743323: This issue has been resolved.] 

• On VRRP backup router for a given IRB unit, following a non-graceful Routing Engine 

switchover, ARP entries for this IRB may be not learnt over MC-LAG. [PR743385: This 


• With the "delete" or "deactivate" "interface :family inet:accounting" configuration; 

FPCs that have the configuration removed might be reset unexpectedly. [PR743442: 


• VPLS interface sometimes stops flooding multicast or broadcast or unknown unicast 

routes when following operations are performed: 

• Deactivate/activate VPLS interface at a global level (deactivate interface interface 

name) 

• Disable/enable VPLS interface at a global level (deactivate interface interface name) 

• Graceful Routing Engine switchover without NSR setup 

• Restart routing 

This issue can be avoided if you deactivate/activate (or disable/enable) the VPLS 

interface or make the PIC offline or online. [PR744361: This issue has been resolved.] 

• 'fru_is_present: out of range slot 0 for' logs are displayed in chassisd logs for all the 

routers where CIP FRU is not present. This log is cosmetic in nature. [PR746923: This 


• With 'epd-threshold' configured in the scheduler map for ATM2 interface, the EPD 

threshold (early packet discard) value applied to the interface might not be correct. 

As a consequence, packets might be unexpectedly tail dropped. This is caused by the 

250 



defect code of edp-threshold value calculation. [PR748864: This issue has been 

resolved.] 

• FPC crashes because of excessive interrupt services from Agave PICS. The fix for the 

PR is enabling the throttling on the IQ2pics to handle the interrupt storm on Agave 

PICS. [PR722812: This issue has been resolved.] 


• When the front panel of a MX Series Routing Engine is brushed against, the Routing 

Engine powers down resulting in outages of customer networks. [PR703076: This issue 


• IPv6 DHCP relay agent and IPv4 bootp mode do not interoperate. This functionality is 

currently being evaluated. [PR710545: This issue has been resolved.] 

• A defect (PR-716885) was introduced causing incoming DHCP packets to be tagged 

with the wrong Layer 3 interface number when those packets were received on an IRB 

interface. This resulted in failure to transmit the DHCP responses back out the 

appropriate interface, leaving the protocol handshake incomplete. This problem is 

resolved in Junos OS Release 11.4R2. [PR716885: This issue has been resolved.] 

• LACP packets might be dropped during the period of congestion on the interface 

between the forwarding and the control plane because of inadequate LACP 

prioritization. [PR719484: This issue has been resolved.] 

• Jdhcpd (DHCP daemon) might dump core files in DHCP or DHCPv6 environment, and 

the subscriber client state “RELEASE” is observed. [PR735945: This issue has been 

resolved.] 

• With STP/aggregate Ethernet configured under IRB interface, you might see kernel 

panic on both master and backup Routing Engines after a multiple graceful Routing 

Engine switchover is done. [PR742940: This issue has been resolved.] 


• By design, the MPLS family under virtual-router type routing-instance is not created 

without a corresponding "protocols:ldp". Hence, without MPLS family, MPLS filter does 

not work on an interface configured under virtual-router type routing-instance. As a 

workaround, configure LDP in the instance, and disable it on all interfaces if not used. 


• RPD might consume more CPU cycles when doing an snmpwalk on mplsLspState. 


• The counter values reported by SNMP mibs mplsLspInfoAggrPackets and 

mplsLspInfoAggrOctets are incorrect. If the LSP has a secondary standby path, the 

counter value will increase by the total value transmitted every MPLS statistics interval. 

If the LSP has no secondary standby path, the counter increments correctly until the 

LSP reverts from the primary to the secondary path. When this occurs, the counter 

value will increase by the total value transmitted every MPLS statistics interval. 


• MPLS statistics are not updated for auto-bandwidth for CCC circuits [PR722744: This 



251


• Graceful restart of MPLS protocol might trigger this problem when adaptive LSPs are 

present in the system. RPD generates core files because of this issue. [PR725579: This 


• On Junos OS Release 9.6, the no-decrement-ttl command hides the internal network 

when trace route is done on an MPLS core running RSVP LSP. but the same fails when 

running Junos OS Release 10.4 code. This bug was introduced because of new feature 

of no-propagate-ttl command which was introduced under VRF. [PR725779: This issue 


• If l3vpn-composite-nexthops were configured under [edit routing-options] and at the 

same time an output filter was applied to lo0 unit 0, the router might have malformed 

the L3 part of locally generated MPLS packets (one or more labels). This is limited to 

only those packets that are originated from within a routing-instance and hence that 

have their lookup done in the .inet.0 (for example: ping 

routing-instance .) Packets generated for the main instance (inet.0) 

are not affected. Transit packets are unaffected in any case. [PR734580: This issue 


• RPD_MPLS_INTF_MAX_LABELS_ERROR is seen in log messages even if the 

maximum-labels option is configured under "family mpls". [PR734680: This issue has 


• With nonstop routing (NSR) enabled, under very rare case, the routing protocol daemon 

(rpd) might crash and dump core files. It is caused when RPD is very busy and there 

are many background jobs waiting to run. One of them is LDP resync write job. There 

is a window in which LDP is waiting for LDP resync write job to run to flush the data on 

session(a). Before the job runs, LDP on standby Routing Engine learns that session(a) 

is not operational anymore and it moves on to request session sync for session(b). 

LDP on master starts session sync for session(b) and creates a job LDP sync session. 

Then the old job LDP resync write runs and re-starts session sync for session(b) by 

creating a job LDP sync session but finds out that it has already created (It should not 

have been created) and RPD cores. This window increases with busy RPD and there 

is more likelihood of this core happening. [PR735337: This issue has been resolved.] 

• Performing "monitor label-switched-path" might cause routing process hog CPU 

resources and will not release except restart routing process. [PR735994: This issue 


• RPD sometimes cores when running snmp walk to mplsXCLspId. RPD core seems to 

happen more in case, when the number of LSP (ingress/egress/transit) is increased. 


• Sometimes the MPLS Autobandwidth value "Max AvgBW util" displays an incorrect 

value. This is because of an error in the way that the value is calculated. [PR737922: 


• If member links of an aggregate bundles or ECMP paths are located on MPC in slot 8 

or higher l3vpn traffic using l3vpn-composite-nexthops might get dropped. [PR740719: 


• l3vpn-composite-nexthop with MPC and MSDPC doing stateful-firewall with interface 

service-set drops packets on service input direction. The interface where service 

252 



input/output is configured has to be inside a VRF, and the destination for which service 

input should intercept the traffic and send it to service PIC in MSDPC should be 

reachable through MPLS backbone, so resolved through composite next-hop, in order 

to see this issue. [PR747914: This issue has been resolved.] 

Multicast 

• In multicast VPN setup with one or more MLFR interface(s) in routing instance, and 

two MS PICs configured in redundant mode, multicast packets with some DSCP value 

are lost on making the primary MS PIC offline or online, followed by deactivating or 

activating the routing instance. [PR696475: This issue has been resolved.] 

• PIM join messages is fragmented on the IPv6 PIM sparse (PIM-SM) mode, if the join 

message exceeds the configured MTU. The multicast traffic should take the interface 

MTU and not the path MTU to avoid the fragmentation of PIM join messages. [PR718212: 


• In NG-MVPN environment, local receiver where the multicast receiver and source are 

connected with the same PE, multicast traffic might be dropped when Provider Tunnel 

flaps. [PR724131: This issue has been resolved.] 

• In a VPLS multihoming environment where two PE routers are connected to two 

interconnected CE routers and STP root protection is enabled on the PE routers, only 

one PE router's interface is in forwarding state while the other PE router's interface is 

in blocking state. IGMP snooping membership will be learnt only on the forwarding PE 

router. When the link interconnecting the two CE routers fails, the PE router interface 

in blocking state transitions to the forwarding state. On this transition, the IGMP 

snooping process on that PE sends a general query message toward the CE router in 

order to immediately reconstruct the group membership state and minimize data loss 

for the IGMP hosts. When the link interconnecting the two CE routers is restored, the 

original spanning-tree state on both PE routers is restored. The forwarding PE receives 

a spanning-tree topology change message. IGMP snooping process on the PE however, 

does not send a general query message toward the CE router to immediately reconstruct 

the group membership state, resulting in data loss till the next periodic query is received 

from the router and the hosts respond to it. [PR724313: This issue has been resolved.] 


• When firewall filter counter names are changed, MIB2D assumes all changes are 

implemented immediately at commit. MIB2D queries the Packet Forwarding Engine 

before it is updated and therefore gets the incorrect list of counter names. Queries 

done through SNMP therefore reflect the old firewall counter names. [PR703606: This 


• With a large scale of subscribers that are configured over VLAN demux interface, high 

CPU utilization of Mib2d (Management information database of SNMP) might be 

observed after flapping subscribers. [PR710573: This issue has been resolved.] 


253



• Random VLAN Id's associated with MAC-address learning from untagged frames on 

trinity cards. [PR594605: This issue has been resolved.] 

• When disable em0 interface is performed , em1 interface is also disabled. This causes 

loss of communication via em1 interface. [PR596113: This issue has been resolved.] 

• As a precautionary measure, a periodic sanity check is added to FPC. It checks FPC 

error conditions and performs the appropriate actions in case of an error. [PR660761: 


• The time stamp of the messages in the firewall log is showing incorrect values. The 

system time and time stamp in log messages are not affected. If NTP server is 

configured, the issue does not happen. [PR661768: This issue has been resolved.] 

• On an MX chassis with enhanced-ip network services configured; multicast traffic may 

be temporarily impacted on all hosts listening to a group if at least one host is going 

through an IRB (that has an aggregated Ethernet as an L2 interface) and the aggregated 

Ethernet or the IRB interface is removed. [PR696417: This issue has been resolved.] 

• At times when RPD/Kernel doesn't have correct index values for the LSI/VT 

sub-interface which is part of a VPLS routing-instance can lead to the forwarding to 

stop. This can be seen on either Enabling VPLS routing-instance or moving between 

LSI and VT sub-interface associated with a VPLS routing-instance. When this issue 

occurs we can notice that forwarding stops on this VPLS routing-instance and the 

following log messages: 

Jan 11 15:38:14.405 2012 testlab-ARA03 tfeb0 

HALP-trinity_nh_indirect_get_vpls_oif_entry vpls interface ifl=424 does not 

have indirect_nh! 

Jan 11 15:38:16.356 2012 testlab-ARA03 tfeb0 

HALP-trinity_nh_indirect_update_fabcallIndirect NH(1048600), ifl is neither 

LSI/VT ifl,.local.,ifl=(0) 


• An MX MPC type card or the MX80 TFEB can crash when a L2 interface is added to a 

bridge-domain or a VPLS routing-instance. This kind of crash will only occur if previous 

events left stale entries in the forwarding table of the MX MPC or MX80 TFEB. After 

the crash the MX MPC or the MX80 TFEB will restart automatically. [PR711182: This 


• In MVPN scenarios with extranets or hub and spoke NG-MVPNs, it is possible to have 

more than one customer site using the same provider tunnel on one PE. In such 

deployments, at the receiver PE with multiple customer sites, if IPv6 multicast traffic 

is carried over the IPv4 provider tunnel, all customer sites may not receive the IPv6 

multicast traffic; only the first site will receive IPv6 traffic. This issue is only for IPv6 

over IPv4 tunneled traffic; IPv4 over IPv4 will work correctly. [PR711891: This issue has 


• FPC type 4.1-ES and type 1/2/3-ES sends out bogus cells which sometimes affects to 

the other FPCs and cause RKME error on the other FPCs. The FPC detecting RKME 

error sometimes stops sending out traffic. To have the FPC send traffic, user need to 

restart the FPC. [PR717384: This issue has been resolved.] 

254 



• During certain configuration corner cases when the source-address or destination 

address associated with one of the listed Packet Forwarding Engine firewall filter logs 

is of a certain length, it causes the syslog module in the Packet Forwarding Engine to 

crash. SYSLOG_IP6_GEN SYSLOG_IP6_ICMP SYSLOG_IP6_TCP_UDP [PR718485: This 


• The allow-configuration-regexps statement at the [edit system login class] hierarchy 

level does not work exactly the same way as the deprecated allow-configuration 

statement at the same hierarchy level. [PR720013: This issue has been resolved.] 

• A 3D chipset which is operating at Layer 2 will look at the IP length and discard trailer 

bytes before forwarding the frame. The TPID must be 0x8100, the Ethertype must be 

0x8000, and this only happens for frames 322 bytes or less, including CRC. [PR720576: 


• On M-series platform (except M320, M120 and M10i/M7i with enhanced CFEB), when 

a link within an Aggregate Ethernet bundle flaps, a MAC frame might be incorrectly 

forwarded to another VPLS instance. There is no workaround. [PR721131: This issue has 


• When l3vpn-composite-nexthop knob is enabled, the VPN label is pushed in the ingress 

Packet Forwarding Engine. The Egress Packet Forwarding Engine pushes the LSP label. 

When EXP rewrite is configured on the outgoing interface, the egress Packet Forwarding 

Engine was performing the rewrite only on the LSP label. [PR723816: This issue has 


• Injecting an excessively long packet for debug (the packet in invalid) results in a buffer 

being overrun leading to a crash. Care must be exercised when using packet inject to 

debug TRIO. The nominal packet length (within the LU) is only 320 bytes, the crash 

resulted when a 971 byte parcel was injected -- overrunning the display buffer. 


• MX acting as bootp helper does not add padding when option82 is included in the 

bootp messages. [PR724391: This issue has been resolved.] 

• MPC might crash when "shaping-rate 106g" is configured under traffic-control-profile. 


• After a MPC restart unexpectedly, the following messages can be seen in the 

/var/log/messages file: 

Jan 10 16:52:01 myrouter fpc0 MPC: Reset reason (0xc): Level3 watchdog, Level2 

watchdog 


• Ping with a size that exceeds MTU does not work, because ICMPv6 Path MTU packets 

to the originator are sent with an incorrect MTU value. [PR725695: This issue has been 

resolved.] 

• Protecting an OSPF Hello with IPSEC AH may cause a cosmetic log entry like the 

following when "forwarding-options helpers bootp" is configured: 

Jan 12 13:17:29.946 SomeRouter /kernel: ipsec_is_inbound_pkt_valid(2004): 

Socket option not set with the addr=130.215.0.129, ifl=331, rtbl_idx=0, 

so=0xa53c31a0 


255



• The DTLS implementation in OpenSSL before 0.9.8s and 1.x before 1.0.0f performs a 

MAC check only if certain padding is valid, which makes it easier for remote attackers 

to recover plaintext via a padding oracle attack. [PR730229: This issue has been 

resolved.] 

• The nh entry in the fabric table for self ping application was getting deleted when the 

lo0 inet family was getting removed. [PR730714: This issue has been resolved.] 

• When queue rate-limit is configured for interfaces on MPC Type 1 3D or MPC Type 2 

3D (i.e. non-Q/EQ MPCs), the output of 'show interfaces queue' for such interfaces 

does not display the count of packets and bytes dropped because of rate-limit. 


• A core dump is generated when a time conditional is applied to a configuration group 

in a configuration that includes a commit script. [PR732402: This issue has been 

resolved.] 

• VRRP transit Traffic(DA MAC address of VRRP group mac-addresses) flowing on a 

node, specifically through an IFD, which has VRRP configured locally, will dropped 

those pacekts, if the locally configured VRRP group is different from transit VRRP 

group. This is only on Trio platforms. [PR732516: This issue has been resolved.] 

• When a tagged interface is part of a bridge domain or vpls routing instance with shared 

vlan learning enabled using "vlan-id all" configuration, and the interface has an explicit 

input vlan-map which pops all the incoming vlan-ids, the mac-addresses in the bridge 

domain/vpls routing instance is learnt on an incorrect vlan-id. [PR733864: This issue 


• MPC might crash and generate core file after executing Packet Forwarding Engine base 

command to show luchip information. [PR733873: This issue has been resolved.] 

• If MIC offline is issued after MPC platform performs ISSU, it will potentially cause 

system crash because of PCIe accessing to IXCHIP being power down. This only happens 

with MICs having IXCHIP. [PR735932: This issue has been resolved.] 

• With output-vlan-map configured with vlan push action, the CFI bit of the outer vlan 

tag on the outgoing frame might have the CFI bit set incorrectly. [PR735935: This issue 


• Port mirroring feature is not working when the ingress and egress(port mirror port) is 

on different Packet Forwarding Engine for Layer 2 traffic with PPPOE traffic underneath 

it in a MPC card. [PR736145: This issue has been resolved.] 

• In L3VPN scenario, transit packets which require fragmentation, traversing over the 

mpls core, might get dropped at the egress PE, if the egress PE?s, CE facing interface 

is on trio chipset cards. [PR736749: This issue has been resolved.] 

• The route record fields of certain flows can be incorrect, if these flows are received in 

an interface, while IIF lookup terminates in a non-leaf node. [PR737472: This issue has 


• If a graceful Routing Engine switchover is performed before an NPC has finished its 

fabric training, its attempts to reconnect will not be recognized by the master Routing 

256 



Engine. In this reconnect period if the FPC crashes chassisd will mark it for removal 

and cleanup. If the NPC comes on again before the cleanup is done chassisd will accept 

the connection but 6 minutes later will assert the nmi for this FPC. It will restart again 

normally. [PR737774: This issue has been resolved.] 

• LU wedges under (1) scaled flow (> 1M flows), and (2) high export rate (> 1kpps). The 

workaround is to limit the flow-export-rate to 1kpps. [PR744230: This issue has been 

resolved.] 

• If interface is disabled and enabled cyclically, interface stop forwarding traffic. 


• Customers using Junos OS Release 11.4R3.6 code on MX routers with MPC 3D 16x 10GE 

(Agent Smith) line cards might experience issues with interfaces on these line cards. 

Some interfaces on the MPC 3D 16x 10GE (Agent Smith) line cards might be reported 

as UP ("Enabled" and "Physical Link UP")in the show interfaces command. 

However, show interfaces terse? command for the same interface reports 

that interface as DOWN (Admin - UP and Link Protocol - DOWN). The link lights at 

both ends of the link is GREEN ? thereby indicating connectivity. However, no traffic 

passes through the affected interfaces. This issue is seen on interfaces that are part 

of the Aggregated Ethernet bundle as well as on interfaces that were not part of the 

Aggregated Ethernet bundle. 

In addition, "Wedge Detected" messages might be seen in the system logs and in the 

telnet or ssh session to the router. This behavior was not seen with DPC hardware. This 

is documented in PR 776727 and upgrading to Junos OS Release 11.4R3.7 fixes the 

above mentioned issues. [PR776727: This issue has been resolved.] 

Routing Policy and Firewall Filters 

• NSD core files are generated. [PR725908: This issue has been resolved.] 


• Prior to Junos OS Release 12.2, filtering BGP routes by community value does not work 

properly when issuing the following CLI command: show route receive-protocol bgp 

. For example: 

{master} 

juniper@PR01.sjc1> show route receive-protocol bgp 128.241.219.125 1.0.4.0/22 

community 2914:420 detail 

inet.0: 378385 destinations, 2919636 routes (377586 active, 2 holddown, 1440 

hidden) 

Restart Complete 

However, this works properly when filtering based-on the name of the community: 

{master} 

juniper@PR01.sjc1> show route receive-protocol bgp 128.241.219.125 1.0.4.0/22 

community-name ALL detail 

inet.0: 378385 destinations, 2919632 routes (377586 active, 2 holddown, 1440 

hidden) 

Restart Complete 

1.0.4.0/22 (6 entries, 1 announced) 

Accepted 


257


Nexthop: 128.241.219.125 

MED: 5 

AS path: 2914 4323 7545 7545 7545 7545 56203 I 

Communities: 2914:420 2914:1008 2914:2000 2914:3000 

This issue is resolved in Junos OS Release 12.2. [PR677777: This issue has been resolved.] 

• When PIM neighbors on logical-routers or routing-instances go down because of missing 

hello packet exceeding dead interval and when it it happens without link down, PIM 

neighbors will not come back even if neighbors start receiving hello packets again. 


• When the traceoptions under the [edit routing-options] configuration hierarchy are 

deactivated, the "ipv6_ra_receive_advertisement" debug message (and others) may 

continue to be logged well after deactivating the configuration. [PR699797: This issue 


• After the second power failure of VC-M, BGP flaps resulting in a 2-5 minute traffic loss 

with 60,000 scaled subscriber's scenario with NSR. After the first VC-M power failure, 

the VC-B takes over VC mastership and there is a 2-3 second traffic loss as expected. 

When the original VC-M is powered back up, it takes the VC-B role. When VC-B comes 

up, it synchronizes system state with the VC-M. Non Stop Routing (NSR) synchronization 

involves sockets with replication enabled. This replicates the routing protocol sockets 

and their state between master and backup. The state of these replicated routing 

sockets are kept in sync with the master so that on a role transition the backup can 

continue to communicate with the routing peers without interruption. The problem is 

that approximately ten minutes after the VC-B is powered up, the VC-B replicated BGP 

protocol TCP sequence numbers stops being in sync with the VC-M BGP socket. Hence, 

the TCP functionality in NSR is not in the correct state on VC-B and does not recover 

from this automatically. If there is a second power failure of the VC-M, the BGP 

connection flaps. This is because the BGP remote peer receives TCP packets with the 

wrong sequence number. This causes it to respond with TCP duplicate 

acknowledgements. After the BGP hold time expires, the remote peer tears down the 

connection and a new one is formed. During this time there is traffic loss from 2-5 

minutes while BGP connection is reestablished. As a workaround, after the first failure 

of VC-M, as part of recovery of the chassis, after the VC has settled and is in a steady 

state, disable and re-enable NSR. To disable and re-enable NSR: 

1. After VC-B power up, wait until VC has settled and is in steady state. 

2. Disable NSR: deactivate routing-options nonstop-routing commit 

3. Wait until VC has settled and is in steady state 

4. Enable NSR: activate routing-options nonstop-routing commit Disable/Enable NSR 

has no adverse impact on the system and the network. Specifically BGP connections 

remain up and there is no packet loss. 

[PR706856] 

• When composite-nexthop is used, for instance, VPLS, FRR or L3VPN with 

l3vpn-composite- nexthop enabled, after routing protocol process (RPD) was restarted, 

if there is any interface, which is associated to the composite-nexthop, flapping, the 

RPD will crash and dump a core. [PR706995: This issue has been resolved.] 

258 



• If PIM remains in the assert state, the routing protocol process (rpd) might create a 

core file. [PR711150: This issue has been resolved.] 

• When MSDP SA message received from MSDP peer is rejected by MSDP import policy, 

that reject action does not prevent MSDP from passing that SA to MVPN and/or PIM 

modules. This PR fixes that behavior -- a rejected SA no longer gets imported to 

bgp.mvpn.0 table. [PR711333: This issue has been resolved.] 

• In the NG-MVN scenario the "maximum-prefixes" knob configured under 

.mvpn.0 rib does not take effect. Configuration example: 

user@router# show routing-instances vrf routing-options 

rib vrf.mvpn.0 { 

maximum-prefixes 5 threshold 3; 

} 

Fix is available in the Junos OS Releases 10.4R9, 11.4R3, 11.2R6, and later releases. 


• When there are more then one tunnel PICs on the system and after bringing down one 

active tunnel PIC, the pe/pd interfaces may fail to switch to another active one in scaled 

environment. [PR717158: This issue has been resolved.] 

• Errror "Error: OID not increasing" is reported while doing snmpwalk on 

IPMROUTE-STD-MIB::ipMRouteNextHopState. [PR717893: This issue has been 

resolved.] 

• RPD core is observed at rt_nh_cmp on the back up while trying to sync the selected gw 

with the master. For this issue to trigger, NSR needs to be enabled, 

per-packet-load-balance needs to be disabled and there should be multiple paths in 

the BGP. [PR718759: This issue has been resolved.] 

• If route record is enabled in a logical system (either explicitly or implicitly via sampling) 

and the logical system is restarted (via 'restart routing') or by deactivation or removal 

of its configuration, the logical system may hang for several minutes and then abort. 


• Next hop ack are handled incorrectly. [PR722452: This issue has been resolved.] 

• With Rosen MVPNs, an egress PE may not correctly be updating the forwarding state 

of the multicast routes. This can happen when both (*,G) and (S,G) PIM states exist, 

and the SPT bit is not set on the S,G route. In this case, the egress PE may not correctly 

add oifs to the multicast forwarding route [PR722508: This issue has been resolved.] 

• Bidirectional Forwarding Detection (BFD) session may flap after it came back from 

graceful Routing Engine switchovers. [PR722522: This issue has been resolved.] 

• When BGP is configured with Bidirectional Forwarding Detection (BFD) enabled, if 

there is a BGP peer established with direct connection, after interface is 

disabled/deactivated, Bidirectional Forwarding Detection (BFD) will send a Admin 

Down state notification to the remote peer. This might cause the BGP session not to 

be teared down until BGP hold timer expires resulting in a short temporary traffic 

blackhole. [PR722798: This issue has been resolved.] 

• If BGP export policies are ran for the routes coming from restarting BGP router (graceful 

restarting router) during graceful restart then helper router may end up advertising less 


259


routes to remote BGP peers. One possible scenario is IGP graceful restart failure during 

BGP graceful restart. [PR723809: This issue has been resolved.] 

• If Multichassis Link Aggregation (MC-LAG) is configured in Active/Standby mode, with 

IGMP-snooping and state replication for MC-LAG enabled, the backup router will 

mistakenly obtain the vlan id value using the whole 16 bits of 802.1Q tag rather than 

the 12 bits of vlan id value, when the IGMP report is received from active router. Since 

the vlan id obtained is not equal to the bridge-domain vlan, the packet will be ignored 

and the IGMP-snooping state replication will not complete. [PR723962: This issue has 


• In a scaled Layer 3 MPLS VPN network with the "l3vpn-composite-nexthop" knob 

enabled, if BGP multipath is configured, the routing protocol daemon (RPD) may crash 

when topology changes. [PR724615: This issue has been resolved.] 

• When L3VPN composite nexthop and BGP multipath are enabled, routing protocol 

daemon (rpd) might dump a core file which is because of multipath composite nexthop 

unresolved. When downloading such a nexthop to kernel, the issue occurs. [PR724777: 


• In a situation where "prefix-export-limit", and NSR is configured together, when there 

is a Routing Engine mastership switches, ISIS overload bit may be set after the NSR 

switchover. This issue is triggered because of inconsistent state between the master 

Routing Engine, and the back-up Routing Engine. [PR725478: This issue has been 

resolved.] 

• RPD crashes when a route is resolved through indirect next-hop which points to service 

next-hop, i.e. l2tp session (LNS setup with service PIC). The indirect next-hop in this 

case is created when having a bgp route that points to a multihop bgp peer reachable 

through L2TP session, or configuring resolve static route which resolves via l2tp session. 


• When Auto-RP is receiving a negative prefix from RP mapping agent (The group range 

which is declared as "negative prefix" is denied from RP mapping and should be treated 

as dense group), if there is (S,G) entry present matching the received negative prefix, 

the Routing Protocol Daemon (RPD) might dump core files during dense mode 

processing. [PR725993: This issue has been resolved.] 

• RPD CPU and memory increasing constantly after passing invalid framed route from 

radius [PR727195: This issue has been resolved.] 

• When user deactivates BGP in a scaled topology* using the deactivate protocol bgp 

command while SNMP polling being ON for BGP related OIDs; the "Routing Protocol" 

Process - rpd - would spike CPU usage along with below syslog messages. 

rpd[2223]: RPD_SCHED_SLIP: 5 sec scheduler slip, user: 5 sec 335518 usec, system: 

0 sec, 0 usec While in this state, the router can be unresponsive and any 

rpd related commands would result in a timeout with below syslog message: 

mgd[51686]: UI_READ_TIMEOUT: Timeout on read of peer 'routing' 


• In inter-AS option B scenario, unreachable NLRIs can be sent via MP-eBGP session for 

some prefixes after IGP topology changes. The issue can affect prefixes with multiple 

paths. [PR730950: This issue has been resolved.] 

260 



• On broadcast networks running ISIS, a RPD restart event on one ISIS router could result 

in the loss of ISIS routes on another router, which will remain in this state until the 

adjacency is cleared. This issue will not occur on ISIS point-to-point networks. 


• In NSR mode for multicast enabled, backup RPD might dump core at rt_iflist_kref(). 

This has been fixed in 12.1R2. [PR734769: This issue has been resolved.] 

• An error in the logic for nonstop routing switchover when family "inet6 labeled-unicast" 

is configured causes RPD to crash after a nonstop routing switchover. [PR736669: This 


• In the MVPN setup, downstream interface change or move could cause multcast traffic 

outage in the MVPN instance. And the problem will be seen in case one of logical 

interface for multicast shares the same ifd with VPLS logical interface. [PR737144: This 


• If route generate statement is configured to install the next-hop from prefixes learned 

from multiple BGP peers and the contributing routes have a different preference2 

value. When the BGP neighbor that advertises the primary contributing prefix for the 

generate route goes down, then the next hop for the route generated by the route 

generate statement, might get stuck pointing to the BGP peer that is down. [PR738206: 


• Two Mx960 connected via two aggregated Ethernet links and these are distribution 

routers. aggregated Ethernet flap test was executed on one of the Mx960, where all 

the aggregated Ethernet links were flapped twice randomly.Core occured on other 

Mx960 during this test execution. [PR740116: This issue has been resolved.] 

• When enable the use of None-stop-Routing (NSR), auto-rd, or "route target filtering"; 

BGP's peer group creation will be deferred. During this window, if the command 'show 

bgp group' is executed it might trigger a rpd core dump. This can only happen during 

unstable bgp peer groups. [PR741719: This issue has been resolved.] 

• With ISO-VPN setup, CLNS traffic outage might occur because of ISIS route loss. Issue 

might occur when sending a set of prefix via BGP the size of which is higher than the 

maximum IS-IS fragment size. It could also be seen by redistributing the same set of 

prefixes from static routes into IS-IS database. [PR745969: This issue has been 

resolved.] 

• Pruned multicast traffic continues to flow from the source even when receiver leaves 

the multicast group for Junos OS Releases 10.4R8.5 ,10.4R9,10.4R9.2. [PR746474: This 


• The eBGP default behavior, ie the no-advertise-peer-as knob, which is to not send an 

update back to the same AS, did not properly filter the advertised update in some 

cases. [PR748197: This issue has been resolved.] 

• If PIM is configured with Dense or Dense Sparse mode, and there are more than 1500 

sources for a group we will experience RPD_SCHED_SLIP, with IGMP running high on 

CPU Cycles. [PR748420: This issue has been resolved.] 

• if there are some link micro flapping, it may bring the Bidirectional Forwarding Detection 

(BFD) into a problematic state. as a result, for next event of BFD state down, it will not 


261


bring down the client sessions like OSPF, ISIS, BGP. [PR749388: This issue has been 

resolved.] 


• IP fragments that reach the MS-PIC or MS-DPC, are not getting filtered out by a 

stateful-firewall rule configured to explicitly block them and hence might hog the 

compute CPUs in the Service PIC/DPC. [PR689364: This issue has been resolved.] 

• SNMP polling fails on the Mx960 router running 10.4R7 when the stateful-firewall rule 

has a match condition for the default snmp application. [PR690830: This issue has 


• In some circumstances after power off/on Routing-Engine some MS-DPC core can be 

seen in system because of Packet Forwarding Engine trying to connect to 

Routing-Engine after disconnection. [PR698226: This issue has been resolved.] 

• Flows are not getting created in cases as restarting PIC, doing graceful Routing Engine 

switchover twice, high number of VRFs configured. This issue will be hit quickly with 

large number of ifls. The other symptom of this PR is wrong values seen in source AS 

, destination AS values. [PR706803: This issue has been resolved.] 

• When enabling the PPTP Application Layer Gateway module in presence of Statefull 

Firewall NAT service-set configurations, the "Set-Link-Info Peer Call Id" and "Echo-Reply 

Id" PPTP parameters might be incorrectly translated when crossing the ALG. [PR721810: 


• While bringing up tunnels with single source address and multiple destination address, 

L2TP tunnel comes up with single destination address only. [PR722354: This issue has 


• Default Junos OS configuration contains an application definition for matching UDP 

based traceroute. It does not include port 33434 which is also used by unix traceroute 

implementation. [PR727825: This issue has been resolved.] 

• On MX routers with subscriber management feature enabled, a small amount of 

memory leak occurs in jl2tpd process when subscriber sessions are logged out and 

l2tpd tunnel is brought down. Additionally in situations where in because of 

misconfiguration tunnel records that don't have both source address and 

Tunnel-Client-Endpoint configured on the tunnel-profile and radius server a small 

memory leaks occurs. [PR728467: This issue has been resolved.] 

• Even without traffic, if there is more than one service-set, Packet Forwarding Engine 

Kernel connectivity can be lost because of memory leak on Packet Forwarding Engine 

level [PR728677: This issue has been resolved.] 

• On MX routers with subscriber management feature enabled, upon very frequent 

execution of -show services l2tp - commands, child processes of jl2tpd daemon 

do not exit cleanly resulting in defunct process to be left behind. If these said commands 

are executed repeatedly over time, ultimately the maxproc limit of jl2tpd is reached 

and the daemon would core and in situations with graceful Routing Engine switchover 

enabled it can finally lead to kernel crash because of Process Table overflow. Typical 

error messages in this case are: 

Upon jl2tpd nearing the limit of maxproc: 

262 



/kernel: nearing maxproc limit by uid 0, please see tuning(7) and login.conf(5). 

/kernel: Process with Most Children- 2231:jl2tpd - Children - 399 

Upon jl2tpd exceeding the maxproc limit: 

/kernel: maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). 

/kernel: Process with Most Children- 2231:jl2tpd - Children - 400 

... 

/kernel: pid 1437 (jl2tpd), uid 0: exited on signal 10 (core dumped) 

From bsd shell, ps -aux command would show defunct processes upon this issue 

occurrence: 

root 40840 0.0 0.0 0 0 ?? Z 2:13AM 0:00.01 

root 40843 0.0 0.0 0 0 ?? Z 2:13AM 0:00.01 


• If running services IDS, a memory leak can occur. [PR738019: This issue has been 

resolved.] 

• In MX80 routers, Option refresh, and template refresh packets are not reaching collector. 

Because of a software defect, these packets were not reaching the collector devices. 

This issue is fixed in later Junos OS releases. [PR738164: This issue has been resolved.] 

• It is not possible to have 4000 stable mlppp bundles over l2tp sessions through MSPIC 

setup if the release used has the fix for 574756. [PR739338: This issue has been 

resolved.] 

• L2TP peer using non default port is unable to connect to MX LNS. [PR739488: This 


• Total ALG errors counter does NOT include SIP ALG errors.The total ALG errors counter 

is only 1080 whereas SIP ALG error counter is 71M. This issue is fixed now. [PR739601: 


• In Junos OS Releases 10.4 and later, the number of outstanding IPSec tunnels has 

changed to be 50 tunnels instead of 200 outstanding tunnels in previous releases. 


• When using Junos OS maintenance releases such as Junos OS Releases 11.2R6, 11.4R2, 

or 12.1R1 (or any Junos OS service releases based on the mentioned maintenance 

releases), SNMP traps are not generated when the service PIC cpu usage exceeds 85% 

and/or the memory usage changes from one zone to another. The SNMP traps are not 

generated because of an internal Junos OS mis-programming. According to the Juniper 

SP-MIB definitions the following traps should be generated: 

• jnxSpSvcSetCpuExceeded (OID 1.3.6.1.4.1.2636.4.10.0.3) - when service PIC CPU 

usage becomes bigger than 85% 

• jnxSpSvcSetCpuOk (OID 1.3.6.1.4.1.2636.4.10.0.4) - when service PIC CPU usage 

becomes smaller than 85% 

• jnxSpSvcSetZoneEntered (OID 1.3.6.1.4.1.2636.4.10.0.1) - when service PIC memory 

usage enters a specific zone (Yellow, Orange or Red) 

• jnxSpSvcSetZoneExited (OID 1.3.6.1.4.1.2636.4.10.0.1) - when service PIC memory 

usage leaves a specific zone (Yellow, Orange or Red) 


263


In Junos OS Releases 11.2R7, 11.4R3 or 12.1R2 and later, this specific Junos OS feature 

has been modified to send the SNMP traps correctly. [PR745190: This issue has been 

resolved.] 

Software Installation 

• The request system snapshot partition command does not create a swap partition that 

leads into various problems related to mounting memory-based files ystems and usage 

of the swap itself. [PR746678: This issue has been resolved.] 


• MX-Series routers ignore the "framed-ip-netmask" of 255.255.255.255 returned from 

RADIUS during access-accept and passes the mask length of local address-pool in 

"framed-ip-netmask" value within the accounting messages. [PR722345: This issue 


• On MX-series working as DHCP-LS with linked pools, adding a new linked pool will fail 

if static hosts are also configured in any of the pools on the same box, and at least one 

subscriber having a static host configuration is connected at the time of adding the 

new pool. [PR726255: This issue has been resolved.] 

• Authd (authentication daemon) memory leak occurs, while the subscribers continuously 

login and logout at the same rate. This is caused by insufficient code of memory 

clean-up. [PR726669: This issue has been resolved.] 

• NAS-Port-Type and NAS-Port-Format configuration per access profile is not used in 

RADIUS request messages. [PR727431: This issue has been resolved.] 

• PPPoE sessions stuck after invalid parameters from SRC. Fixed in 11.4R3. [PR728969: 



• Help syslog may not work on Mx80 devices. [PR561512: This issue has been resolved.] 

• From 2011 daylight saving is not being used for Africa/Cairo timezone, but Junos OS is 

using daylight saving so if we set timezone to Africa/Cairo, we will see time difference 

between router and actual Cairo time. [PR670234: This issue has been resolved.] 

• With large configuration, MGD may crash after issuing show | compare command. 


• Rollback incorrectly removes the protection from configuration statements. As a 

workaround, apply protect on hierarchies rather than leaf statements. [PR716780: This 


• When we modify the device configuration using Jweb CLI editor (Configure->CLI 

Tools->CLI Editor, the already installed certificate in the device may become invalid. 


• While performing ISSU from/to Junos OS release 11.4R2, we could see the following 

error message on the console: 

264 



"Layer 2 address flooding and learning process: rtslib: ERROR kernel does not 

support all messages: expected 101 got 96,a reboot or software upgrade may be 

required" 

Such an error message is not a functional failure and is simply a warning message.ISSU 

should still function correctly. [PR727146: This issue has been resolved.] 

VPLS 

• In Junos OS releases 10.0 and 10.1, the bridge-domain mac learn limit on Packet 

Forwarding Engine can sometimes become negative if the bridge-domain is deleted 

and re-added immediately as part of a configuration change. If that happens, mac 

learning on that bridge-domain can get affected. As a workaround, the bridge-domain 

or VPLS routing instance configuration need to be deactivated and activated to get 

out of this situation. [PR467549: This issue has been resolved.] 

• The problem was because of re-using the logical interface index. In case of ccc routes, 

the logical interface index is used as the route prefix. RPD changes introduced as a 

part of 572780 fixes this issue. [PR570168: This issue has been resolved.] 

• Ethernet II packets with ethertype less than 0x0600 are dropped by 3D Packet 

Forwarding Engine (MPC/Trio chip-set) when working at layer 2. For exampke, Extreme 

Network's EAPS packets meet this criteria and will be dropped when use with affected 

releases. [PR573730: This issue has been resolved.] 

• Forwarding stops on this VPLS routing-instance because of incorrect handling of 

indirect nexthop. [PR694304: This issue has been resolved.] 

• On MX platforms, the logic to recreate a VPLS instance if the 'no-tunnel-services' knob 

was changed since the last commit was faulty, causing RPD to crash in certain race 

conditions. Nonstop Routing is required to trigger the issue, as is the 'no-tunnel-services' 

knob on one or more VPLS instances. [PR725204: This issue has been resolved.] 

VPNs 

• RPD is high to ~94% when upgrading from Junos OS Releases earlier than 10.2 to 10.2R1 

or later. The CPU utilization for the user is high as well ~95%. From the takes accounting 

it looks like L2VC is stuck on something as the user time for this task keeps increasing 

over time. The high CPU sticks with the master Routing Engine on a master switchover. 

[11:01]user@router> show task accounting | no-more 

[11:01]Task accounting is enabled. 

[11:01] 

[11:01]Task Started User Time System Time Longest 

Run 

[11:01]Scheduler 3148 0.029 0.000 0.000 

[11:01]RSVP 

 

[11:01]L3_BANCO_SUDAMER_D-OSPF 42 0.000 0.000 0.000 

[11:01]Common L2 VC 292 27.325 0.132 0.099 

From the rtsockmon it looks like prefixes are added and deleted continuously. However 

another router on same code with and similar prefix flap does not show high RPD CPU. 

[10:42]% rtsockmon -t 

[10:42] sender flag type op 

[10:42][10:42:43] kernel P route add inet 10.247.134.10 tid=46 


265


plen=32 type=dest flags=0x0 nh=hold nhflags=0x1 nhidx=8208 altfwdnhidx=0 

filtidx=0 

[10:42][10:42:43] kernel P nexthop add inet 10.247.134.10 nh=hold 

flags=0x1 idx=8208 ifidx=1138 filteridx=0 

[10:42][10:42:47] kernel P route delete inet 10.247.134.10 tid=46 


filtidx=0 

[10:42][10:42:47] kernel P nexthop delete inet 10.247.134.10 nh=hold 


[10:42][10:42:53] kernel P route add inet 10.247.134.10 tid=46 


filtidx=0 

[10:42][10:42:53] kernel P nexthop add inet 10.247.134.10 nh=hold 


[10:42][10:42:57] kernel P route delete inet 10.247.134.10 tid=46 


filtidx=0 

[10:42][10:42:57] kernel P nexthop delete inet 10.247.134.10 nh=hold 


Problem is a consequence of the routing-instance's length mismatch between mib2d 

(35 characters) and rpd (longer). Customer is currently making use of instances whose 

names are longer than 35 characters: [PR689502: This issue has been resolved.] 

• In MVPN environment, when P-tunnels are built using PIM supporting multiple families, 

after Routing Engine switchover, Kernel Routing Table (KRT) stuck might occur. 


• In a NG-MVPN setup a receiver PE will get the multicast traffic for a particular (C-S,C-G) 

even if it does not have any local C-Join for that particular group. This can happen if 

the following conditions are met: - a selective (S-PMSI) tunnel is used for that particular 

(C-S,C-G) - the provider tunnel signaling protocol is mLDP - the receiver PE is running 

Junos OS 11.4R1.14 - another receiver PE (running any Junos OS Release) in the same 

MVPN instance has a C-Join for that (C-S,C-G) [PR725027: This issue has been 

resolved.] 

• The different endianness of an MX80's PowerPC was not considered in 

mpls-internet-multicast functions, causing routing failures. [PR732563: This issue has 


• In Junos OS Release 12.1R2, continuous rpd restart can lead to rpd crash. Problem is 

seen one in 5 or 6 successive rpd restarts. [PR734276: This issue has been resolved.] 

• In Rosen6 MVPN environment, with nonstop routing (NSR) enabled but PIM NSR 

disabled, after Routing Engine switchover, it may cause the mt- interface not to be 

added in the VRF of the new master Routing Engine. [PR737819: This issue has been 

resolved.] 

• If both the custom VRF import and VRF export policies modify the as_path, 

auto-exported routes may not have the right as_path, or RPD might core. This is minor 

because this configuration is rare. [PR737851: This issue has been resolved.] 

• In M320 routers, the E3 FPCs could crash when L3VPN CNH, 

vpn-label-memory-enhanced, route-memory-enhanced knobs are used in conjunction. 


266 



• MTU value corresponding to the AC interface configured in L2VPN instances, is being 

advertised with an inappropriate format. This could prevent L2VPN VC's from being 

able to get established, should an MTU mismatch is detected between remote ends. 


• When a configuration change (not related to rosen6 mvpn) is committed, it can still 

result in brief multicast traffic disruption because of errorneous deletion of mt interface 






• show class-of-service classifier name "classifier name with spaces" does not work for 

classifiers which has spaces in their name [PR535967: This issue has been resolved.] 

• Service PIC reboots because Service PIC keepalives use the same HNQ as certain Host 

inbound traffic causing the queue to starve and drop packets randomly. [PR690653: 


• If a traffic control profile is applied to non EQ DPC interfaces using wild-card via apply 

?group which is not supported, commit will go through successfully along with 

generating a syslog message similar to the one pasted below 

UI_CONFIGURATION_ERROR: Process: cosd, path: [edit class-of-service interfaces 

ge-*/*/*], statement: output-traffic-control-profile, traffic control profile not allowed 

on interface ge-5/0/0 This will cause cosd to misbehave on other DPC?s which support 

this configuration because of configuration not being applied as intended. Work-around 

for this issue is to deactivate/delete the wild-card configuration and apply the 

configuration specifically on the required interfaces and restart COSD to recover from 

this state. [PR693650: This issue has been resolved.] 

• On MX platforms, under class-of-service configuration, if an interface-set is configured 

on an interface that does not support hierarchical scheduling, then this will cause a 

configuration error to be logged: cosd[21730]: 

%DAEMON-3-UI_CONFIGURATION_ERROR: Process: cosd, path: [edit class-f-service 

interfaces interface-set], statement: ge-0/0/1-10, cos configuration of interface-set 

is supported only on QDPC Because of this configuration error, the COS daemon dumps 

a core and exits. [PR699980: This issue has been resolved.] 

• Update once analyzed [PR711510: This issue has been resolved.] 

• A software defect is introduced in Junos OS Release 10.4R8 which: a) when having the 

following configuration stanza: set class-of-service interfaces 

-//* scheduler-map-chassis derived b) when a command 

in the show class-of-service family is issued, "cosd" restarts unexpectedly. Subsequent 

output of "show class-of-service" does not display correctly. [PR717331: This issue has 


• cosd crash triggered by ae* interface configuration under class of service stanza 



267



• Any sampling related configuration changes, once committed when sampled is running, 

would result in deleting the old sampling instance tree and creates a new tree and as 

a part of deleting the old instance tree the core is encountered [PR688417: This issue 


• authd_aaa_acc.cc:1282Failed to create AAA msg, session-id:803 seen in message logs 

and accounting volume stats are not sent in accounting stops. Accounting interim 

packets are NOT sent at all. [PR700153: This issue has been resolved.] 

• Output of "show interface ge-x/x/x extensive" is taking 20 sec to complete [PR700679: 


• The dfwd (firewall daemon) will NAK when receiving a session delete before which 

session add is never received from pppd (ppp daemon), this might cause some 

undesirable behavior in PPPoE. [PR704491: This issue has been resolved.] 

• Packet Forwarding Engine may crash after "clear auto-configuration interfaces demux0" 

in a scaled PPPoE subscriber setup. [PR705977: This issue has been resolved.] 

• When committing a configurations, where a firewall filter contains multiple 'next term' 

actions, the firewall compiler process (dfwc) could crash and dump core. [PR706863: 


• The issue is seen when FPCs that are part of an aggregate Ethernet logical interface 

are rebooted or restarted and this issue is not readily reproducible. The issue is seen 

because of the bug in the logic that was calculating the bps/pps for an aggregate 

Ethernet logical interface. For an aggregate Ethernet logical interface the stats are 

preserved on Routing Engine for all the child links including bps/pps. We are not 

supposed to use the preserved bps/pps for the stale child links of an aggregate Ethernet 

logical interface while calculating the bundle bps/pps for an aggregate Ethernet logical 

interface. Under certain scenarios we could not tell the stale child links of an aggregate 

Ethernet logical interface from its active child links and this led to incorrect aggregate 

Ethernet bundle bps/pps. We have fixed the bug in the logic. The issue has been fixed 

in 10.4R10, 11.2R6, 11.4X29 and 11.4R2 and all future releases. [PR710277: This issue has 


• On MX routers using DPCE-R-Q-20GE-SFP (DPCE 20x 1GE R EQ) cards broadcast and 

multicast frames are not forwarded correctly to the IRB interface. If a bridge-domain 

or VPLS routing-instance contains CE facing interfaces located on built-in PIC 1 of a 

DPCE-R-Q-20GE-SFP (DPCE 20x 1GE R EQ) card then broadcast and multicast frames 

received on those specific interfaces are not forwarded correctly to the IRB interface 

associated with the bridge-domain or VPLS routing-instance. The fact that broadcast 

and mutlicast frames are not forwarded correctly to the IRB interface can cause 

different behaviors for protocols that rely on this kind of traffic. For example the IRB 

interface will not receive ARP requests from the CE attached to that interface or routing 

protocols running between the CE and the IRB interface will fail to build adjacencies. 

This problem is restricted to DPCE-R-Q-20GE-SFP (DPCE 20x 1GE R EQ) cards for MX 

routers and is restricted to interfaces in the second half of the card (situated on built-in 

PIC 1). If the DPCE-R-Q-20GE-SFP is installed in an MX router in slot 1 as in the following 

example: user@router-re1> show chassis hardware Hardware inventory: Item Version 

268 



Part number Serial number Description Chassis JN11BD460AFB MX480 

FPC 1 REV 25 750-017679 ZB7257 DPCE 20x 1GE R EQ CPU REV 04 710-022351 YX4734 

DPC PMB PIC 0 BUILTIN BUILTIN 10x 1GE(LAN) EQ Xcvr 7 REV 01 740-014132 72152014 

SFP-T PIC 1 BUILTIN BUILTIN 10x 1GE(LAN) EQ Xcvr 7 REV 01 740-013111 70731026 

SFP-T Only interfaces named ge-1/1/* will be affected by this problem. 

Interfaces named ge-1/0/* although situated on the same DPC will forward broadcast 

and multicast frames correctly. Other types of DPC or MPC cards for MX routers are 

not affected by this problem. [PR712414: This issue has been resolved.] 

• On T Series FPC4 or Enhanced Scaling Type of FPC with 'route-memory-enhanced' 

knob enabled, a lot of FPC errors might be observed and FPC will crash. It is caused by 

insufficient nexthop handling in JTREE which is the forwarding data structure on Packet 


• In scenario where sampling is enabled under forwarding-options, PPPoE subscribers 

churn will cause sampled memory allocations to continuesly increase. [PR741218: This 



• Kernel core during upgrade. [PR687671: This issue has been resolved.] 

• During init error the live core has been generated too early, in this case the error got 

recovered after few retries. [PR701294: This issue has been resolved.] 

• The protocol convergence time (such as BGP) will significantly increase when flapping 

the routing protocol neighbor, which is because of ifstraced daemon (ifstate trace 

daemon) competing with Routing Protocol Daemon (RPD) for CPU cycles. [PR705947: 


• After ISSU is done with option "no-old-master-upgrade", SIB state becomes Check 

and BFD state becomes state Init. [PR707215: This issue has been resolved.] 

• Interface on PC-10GE-SFP does not report link flap however remote end interface 

reports a flap during ISSU upgrade [PR718585: This issue has been resolved.] 


• in FIPS mode, there is an IPSec tunnel between master and backup Routing Engine. 

Config sync etc has to happen over this tunnel, so the concerned daemons mark their 

sockets as IPSec enabled. If the traffic to that socket is not encrypted, then it may get 

dropped with the following error message. /kernel: ipsec_is_inbound_pkt_valid(1957): 

Packets are sent in clear to a socket with ipsec enabled; addr=128.0.0.4, ifl=3, rtbl_idx=1, 

tcp flags=0x10 [PR603942: This issue has been resolved.] 

• Scope 1 closed - as not relevant [PR664354: This issue has been resolved.] 

• Under certain rare conditions Kernel "devfs" may become locked, this may cause other 

processes that use /dev/filesystem to wait, eventually some processes start spawning 

until reaching the maximum limit, as a consequence the Kernel will crash. The following 

message logged by the kernel is an indication that the system is approaching the 

maximum number of active processes: /kernel: %KERN-2: nearing maxproc limit by 

uid 0, please see tuning(7) and login.conf(5). /kernel: %KERN-2: Process with Most 

Children- 1:init - Children - 365 [PR678971: This issue has been resolved.] 


269


• If a labeled IPv4 or IPv6 route is entered into the forwarding table when no MPLS family 

is configured in the interface. This may cause KRT to get stuck. [PR679270: This issue 


• The bug currently has only manifested itself in the compat32 layer (i.e. 32-bit 

applications, 64-bit kernel) in relation to umtx_op system calls to perform 

UMTX_OP_LOCK operations, and even then is subject to timing dependencies for it to 

occur. Since 64-bit kernel started shipping in 10.4, customers from 10.4 onwards running 

in this hybrid/compat mode may hit this problem. [PR682294: This issue has been 

resolved.] 

• Failure to handle transient low memory conditions in the kernel. Fix involves retry the 

operation rather than asserting [PR687618: This issue has been resolved.] 

• System goes to DB> when a tcpdump is initiated on LT interface on MX series routers 


• Under scaling environment with more than 1024 BGP peers, after the operation 

'deactivate protocol bgp' and then 'activate protocol bgp', the Routing Protocol Daemon 

(RPD) might crash. [PR707678: This issue has been resolved.] 

• Improper handling of error code during the send failure can result in state mismatch 

between the master Routing Engine and the backup Routing Engine, resulting in a logic 

error culminating in a panic. The problem is likely to be seen on highly loaded systems 

that are running low on Routing Engine kernel memory. [PR710325: This issue has been 

resolved.] 

• icmpv6 error codes are not handled correctly and displayed on the source router even 

when destination router send back correct reply to the source. [PR718122: This issue 


• When NSR is enabled and we shutting down bgp on the secondary OR we are switching 

over from secondary to primary, we may hit the issue. [PR726671: This issue has been 

resolved.] 

• Config changes resulting in an indirect to change from a unilist to a unicast could result 

in ADPC/SDPC crash. [PR731727: This issue has been resolved.] 

• the ether type was set to IP when it should have been set to MPLS [PR731925: This 


Interfaces 

• When committing and invalid configuration using and invalid interface with GRE 

keepalives, the commit error was too general of an error. The fix for this issue provides 

an explanation to the error and allows the user to locate the configuration error very 

quickly. [PR701058: This issue has been resolved.] 

• Under rare circumstances, jpppd can experience a core in a PPPoE/LAC (L2TP) over 

dynamic vlan setup. The affected subscriber will retry to login and succeed. [PR717320: 


• KRT Q might get stuck in a system with Dual Routing Engine running NSR and per 

packet load balancing - Master Routing Engine/RPD installs a unicast next hop for a 

route - Master Routing Engine/RPD then installs another next hop for the same route 

270 



effectively changing the next hop for the route from unicast to a unilist - The backup 

rpd does NOT get a next-hop delete for the old unicast next-hop. Instead, the backup 

rpd only gets a route change to point to the new unilist. - NSR switch over happens 

and the master ship is toggled - New master rpd changes route to point to unilist. This 

will release reference on the single path route. Since rpd has next-hop id cached for it, 

rpd tries to delete the unicast next-hop in the kernel. - KRT Q might gets stuck in 'EPERM 

-- Jtree walk in progress' in the new master Routing Engine [PR722890: This issue has 



• Latency during the initialization of the xge-pic driver may cause BFD to flap. [PR503403: 


• on MPC with MICs, the GE port failed to claim down if auto-negotiation fall into 

incomplete state. 10.4R8, 11.1R7, 11.2R4, 11.4R2, 12.1R1 and later releases will have the 

fix. [PR575163: This issue has been resolved.] 

• In some scenarios when VRRP is enabled on an aggregated interface and the interface 

is a VRRP backup, ping to the private IP address of the aggregated interface will fail. 


• We might see alarm set for fxp0 of backup Routing Engine even if management-ethernet 

link-down ignore is configured under "chassis alarm" hierarchy. [PR610124: This issue 


• In complex service configurations, there may be instances where the MS-DPC receives 

fragments that it reassembles, services, then re-fragments. Under such conditions, the 

MS-DPC may stop forwarding all traffic and require a reboot. [PR661035: This issue 


• When an admin interface (em0/fxp0) has the same address as a routing interface, 

Routing Engine may restarts unexpectedly. [PR668053: This issue has been resolved.] 

• On a MLFR uni-nni RLSQ interface Multilink input statistics doesn't work after 8 logical 

units (dlci's). This doesn't have any impact on the Multilink traffic. [PR688197: This 


• When logical unit of ci is disabled, it returns incorrect ifOutOctets value to MIB get or 

walk. But when it is enabled again, it will get to return the correct value. [PR672633: 


• This problem is happening only on 4X10g PIC and only when we set HCOS on more 

than one interface at a time followed by commit. If you set HCOS on each interface 

one after the other with commit on each interface, then there is no problem. [PR690383: 


• MX with enhanced fan tray wrongly reports 6 fan's per tray via SNMP's jnxFruTable 

while each enhanced fan tray reports speeds for 12 fan's per tray. Correct value is 12. 


• On the MX-Series routers, the output of 'show snmp mib walk jnxContentsSerialNo' 

is incorrectly displaying a serial number for the pic on a built-in MIC. The correct output 

for the serial number should be 'BUILTIN'. [PR694336: This issue has been resolved.] 


271


• On multilink interfaces(mlppp/mfr/mlfr) pps/bps counters fluctuate around the actual 

value beyond permissible limits. The total packets/bytes counts are accurately 

accounted. There is no forwarding impact because of this issue. There is no workaround 

to this problem. [PR694340: This issue has been resolved.] 

• Classification of Routing Engine outbound traffic using host-outbound-traffic keyword 

under [edit class-of-service] hierarchy does not work for IPsec packets. On Junos OS 

Releases without the fix of this PR all host generated outbound traffic that needs to 

go through the IPSEC tunnel will get classified to the default best effort queue only. 


• If an aggregate bundle goes down because of minimum-links 2 or higher configured, 

bundle member links might not attach to the bundle once the aggregate bundle comes 

back up. Outbound traffic will not use this member link (no blackholing) and inbound 

traffic for this member link is properly processed and forwarded. The same symptom 

might also be visible right after system reboot without the need of member link flaps. 

To recover from this condition disable/enable the affected member link with 

configuration changes. The following Junos OS Releases are affected: 10.4R6, 10.4R7, 

11.1R6, and 11.2R3 [PR695895: This issue has been resolved.] 

• The IPSec throughput was dropped suddenly and hard to recover when the throughput 

was more than ~6,7Gbps. [PR697529: This issue has been resolved.] 

• An issue was discovered where a non-Juniper, non-standard SFP conflicted with the 

hardware addressing of the MIC causing it to fail to load. Remember while non-Juniper 

SFP's should function, they are not supported. [PR697577: This issue has been resolved.] 

• This MS-DPC core happens because of a race condition between setting IPSEC SA 

bundle ptr to NULL from control thread as a result of SA delete msg from kmd-re, while 

a data thread(s) is trying to access the same SA ptr after it checked that the ptr is not 

NULL. The fix is to always save a copy of the non NULL SA bundle ptr in a local param 

and access only the local param. That way the data thread will avoid running into such 

race condition. It is also safe to access that local param given that the bundle SA ptr 

will be valid for 1sec after setting it to NULL in its parent policy array. [PR698788: This 


• Traffic will get tail dropped under below condition. - When we have more than 4 

forwarding-classes configured. - Egress interface is on IQ PIC, and is only configured 

for 4 queues (default). - When we classify traffic on ingress interface in a particular 

FC and map that FC to either queue 4, 5, 6, or 7. This PR fixes this problem, 

"forwarding-class-map" must be configured to reclassify the on egress VPLS interface. 

Below is sample configuration, here ge-3/3/0 is customer facing VPLS interface. 

{master}[edit class-of-service] lab@dia-m120-re0# show forwarding-class-map | 

display set set class-of-service forwarding-class-map one class standard-high 

queue-num 4 set class-of-service forwarding-class-map one class standard-high 

restricted-queue 0 set class-of-service forwarding-class-map one class premiumnrt 

queue-num 7 set class-of-service forwarding-class-map one class premiumnrt 

restricted-queue 2 set class-of-service forwarding-class-map one class business-critical 

queue-num 5 set class-of-service forwarding-class-map one class business-critical 

restricted-queue 1 set class-of-service forwarding-class-map one class standard 

queue-num 0 set class-of-service forwarding-class-map one class standard 

restricted-queue 0 set class-of-service forwarding-class-map one class business 

272 



queue-num 1 set class-of-service forwarding-class-map one class business 

restricted-queue 1 set class-of-service forwarding-class-map one class premiumrt 

queue-num 2 set class-of-service forwarding-class-map one class premiumrt 

restricted-queue 2 set class-of-service forwarding-class-map one class nc_premiumnrt 

queue-num 3 set class-of-service forwarding-class-map one class nc_premiumnrt 

restricted-queue 3 {master}[edit class-of-service] lab@dia-m120-re0# show interfaces 

ge-3/3/0 | display set set class-of-service interfaces ge-3/3/0 unit 512 

output-forwarding-class-map one [PR699538: This issue has been resolved.] 

• outer vlan header of arp packet missing after Routing Engine switchover in DHCP 

subscriber scenario [PR699931: This issue has been resolved.] 

• The issues happens only when the Fan Tray are replaced with the Enhanced Fan tray 

and while doing so the enhanced fan tray was added/removed/added in a short period 

of time causing the counter value to set incorrectly. The alarm is a warning alarm to 

check if proper Fan Trays are installed. If the required fan trays are installed and they 

are working fine then this should not affect the functionality of the cards. [PR700112: 


• MXVC members may not reconnect after MXVC reboot causing virtual chassis 

segmentation [PR700592: This issue has been resolved.] 

• Interfaces on MPC's using STP-T transceivers may bounce upon ISSU upgrade. 


• Standby SCG keeps staying Deviation as "unknown" and Status as "present" after 

Routing Engine master switch. [PR701800: This issue has been resolved.] 

• After flap one of the members of aggregate Ethernet link Juniper can start sending 

wrong "Oampdu max size" in OAMPDU (5 reserved bits are not set to zero) as result 

Huawei does not accept the OAMPDUs. [PR701853: This issue has been resolved.] 

• Introduced in Junos OS Release 10.4R8, a MX-FPC, a MS-DPC, or a DPC may restart 

unexpectedly with the following error messages: [Oct 25 04:21:08.749 LOG: Err] 

ia_wpkt_next : pkt_ring[937] has a packet 0x421fea20 [PR701928: This issue has been 

resolved.] 

• While using vrrp with logical systems, sometime it can happen that show vrrp command 

for logical systems does not display information for all groups. The show command 

can be retried in such a case. [PR704068: This issue has been resolved.] 

• When some mlppp t1 interfaces kept flapping very quickly, the MS-pic memory usage 

keeps increasing and at last the memory usage may be up to 99%. [PR705577: This 


• In Multi-Chassis Link Aggregation Group (MC-LAG) Active/Active environment with 

Aggregate Ethernet (AE) interface as Multi-Chassis Link (MC-Link), after graceful 

Routing Engine switchover, Inter-Chassis Data Link (ICL-link) interface might be 

accepted as MAC destination interface in ARP Cache table and ignoring ARP request 

from client from MC-Link interface. As a consequence, traffic might be lost. Only after 

ARP aging timeout in Routing Engine, the Routing Engine will send the ARP request 

and traffic will be restored. [PR706091: This issue has been resolved.] 


273


• Cprod tool does not work with MS-DPC. This is fixed in 10.4R9 and newer Junos OS 

Releases [PR706395: This issue has been resolved.] 

• A defect introduced by a change in the processing of HDLC keepalives impacted the 

default HDLC keepalive timer. With this issue, HDLC keepalives are no longer sent at 

the default timer of 10 seconds. But rather at a timer greater than 30 seconds and this 

was triggering a temporary loss of keepalives on the peer routers. This issue effects 

Junos OS Release 10.4R7.5, and its service releases. [PR707244: This issue has been 

resolved.] 

• In Active/Active MC-LAG if we power off both PEs and start only PE, MC-Links will not 

come up (we need an initial TCP connection for MC-LAG finite state). [PR707494: This 


• l2ald process might experience a software exception if service-id is not configured 


• When IQ2 interface is administratively disabled and configured no-auto-negotiation, 

the inteface will keep flapping and accompany with below similar messages: (FPC 

Slot 0, PIC Slot 0) IQ2(0/0): disabled Link 7 [PR709800: This issue has been resolved.] 

• This crash will be seen on a heavily loaded fpc(when it runs out of SRAM memory) 

hosting the lsq/rlsq link or bundle interfaces. Symptoms before hitting this issue is 

LWM messages similar to "esource Category:jtree Instance:jtree0-seg0 

Type:free-dwords Available:104832 is less than LWM limit:104857, 

rsmon_syslog_limit()". There is no workaround to this problem. [PR710702: This issue 


• Due to a bug in the Junos OS kernel code, various types of interfaces show up as member 

links of an Aggregated Ethernet (AE) interface, though these same interfaces aren't 

configured to become part of a given aggregate Ethernet bundle. For example: The 

interface extensive for a ae bundle configuration with xe-8/1/0 and xe-4/3/3 as member 

links LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx xe-8/1/0.0 223171 223707 

0 0 xe-4/3/3.0 223171 223716 0 0 lc-3/1/0.32769 0 0 0 0


onwards any bundle state changes are not propagated form the Routing Engine to the 

LSQ PIC. The following sequence of message log entries does illustrate the symptom: 

Dec 12 01:53:21 router fpc2 Transient flow-control asserted by MAC0 on sp-2/1 for 1 

seconds Dec 12 01:53:22 router fpc2 Transient flow-control asserted by MAC0 on sp-2/1 

for 2 seconds Dec 12 01:53:23 router fpc2 Prolonged flow-control asserted by MAC0 

on sp-2/1 Dec 12 01:53:25 router /kernel: pfe_send_failed(index 9, type 20), err=32 Dec 

12 01:53:25 router /kernel: pfe_listener_disconnect: conn dropped: listener idx=7, 

tnpaddr=0x12020080, reason: none Dec 12 01:54:33 router fpc2 MAC flow-control 

cleared on sp-2/1 A manual LSQ PIC restart is needed to recover from this condition 


• Now clear oam ethernet link-fault-management state command will reset local 

oam loopback(if enabled) also along with existing behavior of resetting discovery state 

machine. [PR723739: This issue has been resolved.] 

• Run time change in no-accept-data/accept-data failed to take effect in few cases for 

Inherit group. If ping to VIP is not require then don't configure no-accept-data. It is 

disable by default. By default - ping to VIP will fail. 'restart vrrp' will resolve the issue. 

SW upgrade from other release to 11.4R2 release with an existing 

'accept-data/no-accept-data' configuration is not impacted. 

'accept-data/no-accept-data' configuration will work as design after SW upgrade. 

This issue is not applicable for Active group. [PR725556: This issue has been resolved.] 

• When Graceful Routing Engine Switchover is enabled on system, during graceful Routing 

Engine switchover or re-synchronization activities are happening between the Routing 

Engines, the Kernel might dump core file which is because of incorrect code handling 

of a background clean-up thread. [PR729325: This issue has been resolved.] 

• During Routing Engine switchover or connectivity-fault management (CFM) process 

(cfmd) restart, Connectivity Check Messages (CCM) received from remote Maintenance 

End Points (MEP) are not processed properly. All action profile events are ignored 

during the period, after CFMD restart, the events are not cleared. This might cause 

cfmd to function incorrectly. [PR729490: This issue has been resolved.] 

• The software information about Ethernet MICs and non-Ethernet mics are stored in 

Junos OS in different structures. The crash occurs because of memory corruption 

caused by the FRR marking feature in the non-Ethernet-mic structures. The PR has 

been fixed in 11.4R2 and onward. [PR733566: This issue has been resolved.] 


• Kernel messages of the following sort might be seen after upgrade to some 10.X versions 

/kernel: PCF8584(WR): target ack failure on byte 0 /kernel: PCF8584(WR): 

(i2c_s1=0x08, group=0xe, device=0x54) These messages are cosmetic and indicate 

that the Host Subsystem could not communicate with the Fan Tray to gather 

environment related information. It has been fixed with this PR. [PR606130: This issue 


• When the IPv6 neighbor is behind LT (which is terminated to a BD) the IRB interface 

cannot communicate with the neighbor as the LT cookie is not taken care of while 

constructing the IPv6 packet. [PR670636: This issue has been resolved.] 


275


• The possible range of values to configure LACP system priority is 0 through 65,535. 

The command line help does not prompt the possible values to configure LACP system 

priority. [PR680484: This issue has been resolved.] 

• The jnxLacpAggregateInterfaceName.0 field contains a hex value but no ascii value 

for the XE interfaces. [PR702518: This issue has been resolved.] 

• A defect (PR-716885) was introduced causing incoming DHCP packets to be tagged 

with the wrong layer 3 interface number when those packets were received on an IRB 

interface. This resulted in failure to transmit the DHCP responses back out the 

appropriate interface, leaving the protocol handshake incomplete. This problem is 

resolved in Release 11.4 R2. [PR716885: This issue has been resolved.] 

• The domain name for DHCPv6 usernames was incorrectly placed before DHCPv6 

specific attributes, for example client-id. With this change the domain name is placed 

at the end of the username and is preceded by '@'. [PR719639: This issue has been 

resolved.] 

• The system can't handle the dhcp packets after graceful Routing Engine switchover, 

when dynamic subscriber interfaces configured using IP demux interfaces. [PR721669: 



• With Junos OS Version 10.4R7 MPLS packets received on L2 Circuit via LT tunnel 

interfaces doe not perform label swap operations but only strip the L2 Circuit Tunnel 

label. The nexthop node will drop the mpls packets because of unknown label 

information. With Junos OS Version 11.1R6 explicit NULL packets with IPv4/IPv6 payload 

that go though a path that pushes MPLS labels (LSP stitching) will come out corrupted, 

with the top 4 bytes of the IP portion missing. At the same time, explicit NULL packets 

with MPLS payload (For example: L2VPN packets with the outer label replaced by 

explicit NULL on the PHP node) will fail label lookup on the inner (VPN) label and will 

get punted to the CPU (based on lookup done for the outer (NULL) label), instead of 

forwarded. [PR692838: This issue has been resolved.] 

• show mpls path | resolve command is showing IP addresses instead of resolving them 

in FQDN. [PR694620: This issue has been resolved.] 

• When LSP switches from primary->secondary-primary path, the Max Avg counter 

might show up incorrect higher value when compared to actual LSP bandwidth. As 

the result of this, on the next adjust interval, LSP would be signalled with incorrect high 

last Max avg counter value. This issue will be seen only with secondary LSP configured. 


• When family mpls is removed but family inet remains on an interface, the nexthop may 

go into discard state on the Packet Forwarding Engine. The nexthop in discard state 

will cause packet loss for any routes associated with that nexthop. Here are the two 

ways to remove family mpls but not family inet from an interface: - deactivate interfaces 

unit family mpls - set interfaces unit family 

mpls maximum-labels [PR698169: This issue has been resolved.] 

• When nonstop-routing is used with adaptive LSPs, deleting an adaptive LSP can result 

in RPD core on the backup routing-engine. [PR698232: This issue has been resolved.] 

276 



• Topology: P2mp branch LSR R1-----------DUT --------- R2 | | | R3 DUT is the P2MP 

branch LSR with R1 being the source and R2 & R3 being two branches. On receiving 

P2mp traffic from R1, DUT duplicates the traffic and sends to R2 and R3. It was observed 

in 11.4 image that the clone route doesn't have reference to the second branch 

regress@frontnine# run show route forwarding-table label 299840 extensive Routing 

table: default.mpls [Index 0] MPLS: Destination: 299840 Route type: user Route 

reference: 0 Route interface-index: 0 Flags: accounting, sent to PFE Next-hop type: 

indirect Index: 2097150 Reference: 2 Nexthop: Next-hop type: composite Index: 572 

Reference: 1 Nexthop: Next-hop type: composite Index: 548 Reference: 2 Nexthop: 

20.1.0.1 Next-hop type: unicast Index: 513 Reference: 10 Next-hop interface: et-3/1/9.0 

Nexthop: Next-hop type: composite Index: 571 Reference: 2 Nexthop: 30.1.0.1 Next-hop 

type: unicast Index: 547 Reference: 8 Next-hop interface: et-3/1/1.0 Destination: 

299840(S=0) Route type: user Route reference: 0 Route interface-index: 0 Flags: 

accounting, sent to PFE Next-hop type: indirect Index: 2097151 Reference: 2 Nexthop: 

Next-hop type: composite Index: 551 Reference: 1 Nexthop: Next-hop type: composite 

Index: 550 Reference: 1 Nexthop: 20.1.0.1 Next-hop type: unicast Index: 513 Reference: 

10 Next-hop interface: et-3/1/9.0 >>>>>>>>> only reference to one branch [PR699098: 


• After 9.3R3, customer may see unwanted mpls lsp convergence even there is no 

optimize-timer configured. Seems to be fast-reroute related issue. [PR699273: This 


• - show mpls lsp statistics and monitor label-switched-path commands are not working 

for TE tunnels carrying CCC traffic. - only monitor label-switched-path is not working 

for TE tunnels carrying L2circuits traffic. [PR705019: This issue has been resolved.] 

• If the LSP path is cleared after the first reoptimization, the LSP path never comes up. 


• Graceful restart of MPLS protocol may trigger this problem when adaptive LSPs are 

present in the system. RPD will core because of the issue. [PR725579: This issue has 


Multicast 

• With Junos OS Release 10.0 or higher performing ISSU software upgrade, multicast 

resolve routes for ipv6 or ipv6 routes might not be installed properly in all FPCs. 

Multicast traffic will not be forwarded anymore. The following syslog message will 

indicate the problem. RT: Failed prefix change IPv4:0 - 224/4 (unknown prefix) RT: 

Failed prefix change IPv6:0 - ff00::/8 (change failed) To recover from this condition 

FPC reporting the above syslog messages needs to get restarted. [PR559108: This 


• PIM join messages is fragmented on the IPv6 PIM sparse (PIM-SM) mode, if the join 

message exceeds the configured MTU. The multicast traffic should take the interface 

MTU and not the path MTU to avoid the fragmentation of PIM join messages. [PR718212: 



277



• When firewall filter counter names are changes, MIB2D assumes all changes are 

implemented immidiately at commit. MIB2D queries the Packet Forwarding Engine 

before it is updated and therefore gets the incorrect list of counter names. Queries 

done via SNMP therefore reflect the old firewall counter names. [PR703606: This issue 



• Random VLAN Id's associated to MAC-address learning from untagged frames on 

trinity cards. [PR594605: This issue has been resolved.] 

• When there are large configuration, or next-hop, it is possible for a DPC to fail to come 

online after being inserted or restarted. The logs will then show the message: "PFEMAN 

resync in progress" every 10 seconds. This is caused by a race condition on the 

routing-engine when it initially tries to download the configuration and routes to the 

DPC, and eventually causes the DPC to stay in dormant state. [PR609644: This issue 


• On TRIO based platforms, if the ingress Layer 2 size of a frame is larger than the egress 

MTU of an interface, the Packet Forwarding Engine will attempt to fragment the packet. 

If however the resulting Layer 3 packet with egress encapsulation is still smaller than 

the egress MTU size, the Packet Forwarding Engine makes an incorrect calculation 

resulting in the MQCHIP wedge condition. The affected Packet Forwarding Engine will 

need to be restarted in order to recover [PR661698: This issue has been resolved.] 

• The time stamp of the messages in firewall log is showing incorrect values. The system 

time and time stamp in log messages are not affected. If NTP server is configured, the 

issue does not happen. [PR661768: This issue has been resolved.] 

• For a situation where the number of IPSec tunnel is more than 1000, memory leaks 

may happen which cause the error message to be printed out: 

(FPC Slot , PIC Slot ) Cannot allocate spd handle for dynamic rule for 

tunnel: __SDM08-SET._junos_.tunnel11__. See PSN-2011-12-450 for more information. 


• On 10.4R8 code base egress PIC sampling will not work as expected when packet is 

transitioning from IP to MPLS. [PR679654: This issue has been resolved.] 

• After deactivate family mpls under ae, you might see "Could not decrement reroute 

counters for logical interface" log [PR684158: This issue has been resolved.] 

• While processing Packet Forwarding Engine routing updates, the Packet Forwarding 

Engine tries to access an uninitialized memory pointer and the following log messages 

can be seen: [Sep 20 13:29:14.272 LOG: Err] routing_chip_sram_write(0): SRAM write 

error, offset 0x1000001 [Sep 20 13:29:15.261 LOG: Err] ICHIP: Ir SRAM offset 

0x04000004 out of range, i_r_sram_wr There is no other adverse affect to the system 

and the message can be ignored [PR691503: This issue has been resolved.] 

• If you have an ingress interface with larger MTU than an egress interfaces, fragmenting 

packets on a Trio-based MPC may lead to interfaces on the egress MPC to stop 

transmitting. The necessary conditions which have to be met are: 1. An ingress interface 

with MTU value larger than that of an egress interface 2. The egress interface is a 

278 



TRIO-based MPC 3. An ingress packet is larger than the MTU of the egress interface A 

system which has all of the above conditions is susceptible to egress interface being 

locked up. [PR692417: This issue has been resolved.] 

• Customer would see packet drop if downstream router has policing enabled because 

we don't clear the DEI bit on the SVLAN tag. [PR692482: This issue has been resolved.] 

• MPC Core was seen on router running 10.2S6.4. Issue was observed when the irb 

interface called under the routing instance vpls was deleted [PR693470: This issue 


• MPC might crash when aggregate interface configured because of invalid child members 

installed at Packet Forwarding Engine side. [PR695225: This issue has been resolved.] 

• On an MX chassis with enhanced-ip network services configured; multicast traffic may 

be temporarily impacted on all hosts listening to a group if at least one host is going 

through an IRB (that has an aggregate Ethernet as an L2 interface) and the aggregate 

Ethernet or the IRB interface is removed. [PR696417: This issue has been resolved.] 

• Under some condition, we will report "HALP-trinity_nh_indirect_get_irb_fwd_nhIndirect 

NH(xxxxxxx), IRB egress set to discard:0xyy...yy" in certain circumstance of VPLS, IRB, 

VT/LSI over MPC environment. The error occurs because we didn't get the IRB 

forwarding NH when installing an IRB entry. This can occur when the target logical 

interface is either zero or the target logical interface not a LSI/VT interface. Even if this 

appears to be traffic affecting, not side impact has been reported in the customer 

where this message has appeared. [PR698776: This issue has been resolved.] 

• The Packet Forwarding Engine may core if a block of memory is freed while it is still in 

use on the Packet Forwarding Engine. [PR699176: This issue has been resolved.] 

• Trio cards may experience a crash and generate a core file because of a bug in PCIe 

handling. When this issue happens you might see the following messages followed by 

a core file: [LOG]MQ(x): pio_handle(0x414f6e00); pio_read_u64() failed: 1(generic 

failure)! addr=0000000002245ca8 [LOG] SCHED: Thread 26 (PIC Periodic) aborted, 

hogged 2505 ms [LOG] syslog called with interrupts off (caller pc:0x4094cfc4) [LOG] 

Dumping core-NPC [PR699679: This issue has been resolved.] 

• In scenarios where LDP traffic is tunneled over ECMP, MPLS LSPs that are single-hop, 

or share a common egress interface, the LSP traffic statistics may be reported 

incorrectly. [PR700154: This issue has been resolved.] 

• When two users are in configuration mode at the same time and one runs a show 

command, the other user might get locked. He cannot run any command unless the 

first user exits the configuration mode. [PR701250: This issue has been resolved.] 

• Configuring Routing Engine based input sampling and port-mirroring on the same 

interface of MPC card results in wrong flow records sent to netflow server [PR701549: 


• On T-series or M-320 FPC (except Enhanced Type 3 FPC), after deleting a VRF instance 

having interfaces which are not local on core facing FPC, and then adding VRF instance 

back having the same interfaces, L3VPN traffic interruption might occur. [PR701700: 



279


• At times when RPD/Kernel doesn't have correct index values for the LSI/VT 

sub-interface which is part of a VPLS routing-instance can lead to the forwarding to 

stop. This can be seen on either Enabling VPLS routing-instance or moving between 

LSI and VT sub-interface associated with a VPLS routing-instance. When this issue 

occurs we can notice that forwarding stops on this VPLS routing-instance and the 

following log messages: Jan 11 15:38:14.405 2012 testlab-ARA03 tfeb0 

HALP-trinity_nh_indirect_get_vpls_oif_entry vpls interface ifl=424 does not have 

indirect_nh! Jan 11 15:38:16.356 2012 testlab-ARA03 tfeb0 

HALP-trinity_nh_indirect_update_fabcallIndirect NH(1048600), ifl is neither LSI/VT 

ifl,.local.,ifl=(0) [PR704283: This issue has been resolved.] 

• This PR applies to MX routers running PPPoE subscriber management software in 

Junos OS Release 11.1 and earlier releases. It is not an issue in 11.2 and later releases. 

When the IP MTU for a PPPoE session requires that the MX PPPoE server fragments 

an IP packet, the PPPoE header length in the outgoing fragment is not set to the 

fragmented length. As a result, the PPPoE client receiver drops these fragments causing 

packet loss. [PR705578: This issue has been resolved.] 

• In 11.1 and above, using interface-mode trunk to configure VLAN's may fail to actually 

program the VLAN's in the Packet Forwarding Engine. This happens when interface is 

also configured with "speed auto". JTAC can check the programming of the Packet 

Forwarding Engine to verify this issue is being hit. [PR706134: This issue has been 

resolved.] 

• On T-Series or M320 (with none E3 FPC) platform, when there is more than 16 ECMP 

routes exist, after some of the routes flapping (but the available ECMP routes still more 

than 16), the Memory on FPC may be corrupted and error messages like "jtree memory 

free using incorrect value" may be prompted. [PR707453: This issue has been resolved.] 

• An MX MPC type card or the MX80 TFEB can crash when a L2 interface is added to a 

bridge-domain or a VPLS routing-instance. This kind of crash will only occur if previous 

events left stale entries in the forwarding table of the MX MPC or MX80 TFEB. After 

the crash the MX MPC or the MX80 TFEB will restart automatically. [PR711182: This 


• If $junos-input-filter and/or $junos-output-filter variables configured on PPPoE 

subscriber interface without default value configured , when the PPPoE authentication 

fails or authentication does pass but the ERX-input-policy and/or ERX-output-policy 

VSAs are not returned by the radius server, DFWD process will have memory leak and 

crash eventually. [PR711426: This issue has been resolved.] 

• MPLS LSP traceroute will not display right information for intermediate (transit) LSRs 

of an MPLS LSP, when the ingress interface of the LSP is on a Trio based Packet 

Forwarding Engine, and the Egress interface of the LSP is on an IChip based Packet 

Forwarding Engine (ADPC). [PR716881: This issue has been resolved.] 

• VSTP may not work on dual tagged Trio interfaces that are part of a bridge domain / 

VPLS instance. [PR717046: This issue has been resolved.] 

• During certain configuration corner cases when the source-address or destination 

address associated with one of the listed Packet Forwarding Engine firewall filter logs 

is of a certain length, it causes the syslog module in the Packet Forwarding Engine to 

280 



crash. SYSLOG_IP6_GEN SYSLOG_IP6_ICMP SYSLOG_IP6_TCP_UDP [PR718485: This 


• When ipv6 address goes more than 96 bits while commit it throws an commit script 

error root# commit error: string is not in UTF-8 warning: 126 126 warning: 126 126 

warning: 126 126 error: 1 error reported by commit scripts error: commit script failure 


• On M-series platform (except M320, M120 and M10i/M7i with enhanced CFEB), when 

a link within an Aggregate Ethernet bundle flaps, a MAC frame might be incorrectly 

forwarded to another VPLS instance. There is no workaround. [PR721131: This issue has 


• After a MPC restart unexpectedly, the following messages can be seen in 

/var/log/messages: Jan 10 16:52:01 myrouter fpc0 MPC: Reset reason (0xc): Level3 

watchdog, Level2 watchdog [PR724924: This issue has been resolved.] 

• With output-vlan-map configured with vlan push action, the CFI bit of the outer vlan 

tag on the outgoing frame might have the CFI bit set incorrectly. [PR735935: This issue 



• 'show bgp summary' can show incorrect active route count at receiving updates of 

inactive routes from RR Client [PR685850: This issue has been resolved.] 

• If "forwarding-options sampling" or "routing-options route-record" is configured, stale 

routes may appear and persist in the routing table in holddown state. Those routes are 

not active and do not affect forwarding, but they do consume memory and if left will 

lead to the memory footprint of RPD increasing over time. For mpls routes it will also 

effect Packet Forwarding Engine and Kernel memory since the next-hops are not 

deleted till the route is deleted within RPD. Junos OS Releases 10.4R7 and 11.2R3 are 

effected. [PR688820: This issue has been resolved.] 

• In dense networks and time race condition, unnecessary OSPF LS retransmission for 

implicit Ack may happen (opposite of RFC2328). [PR691201: This issue has been 

resolved.] 

• After deactivating and reactivating a VRF routing instance with vrf-table-label knob 

configured, the label switch interface (LSI) interface for this instance ends up with only 

GF_INET family, instead of the expected three families: GF_INET, GF_INET6 and GF_ISO. 

This would cause IPv6 packets loss when they are travering the LSI interface. 


• After a nsr ospf sham links may go down. Restart routing to reactivate. [PR693719: This 


• When activate pim on a routing-instance vrf, The vrf.inet6.1 table should be created, 

but in rare cases the table fails to be created. If this happens, IPv6 multicast routes are 

NOT able to flash into krt to install in kernel. [PR695113: This issue has been resolved.] 

• Changes to martian addresses (RFC5735 that obsoletes RFC3330), that are not present 

in Junos OS martians default settings. PSN-2011-10-393 [PR698121: This issue has 



281


• In certain scaled next-generation multicast VPN configurations, deleted route entries 

may get stuck in the KRT queue, as displayed by the show krt queue command. This 

condition does not appear to affect traffic flow. [PR698172: This issue has been 

resolved.] 

• get-next for pimRPSetHoldTime or pimRPSetExpiryTime may list output of same OID 

mentioned in the get-next command. Instead it should list the output for next OID. 


• Scheduler slips can occur when FPC's containing physical interfaces with thousands 

of logical interfaces are taken offline or online. [PR701021: This issue has been resolved.] 

• Under rare circumstances, backup might core when backup discards a route. [PR703854: 


• When having VRF multipath enabled, and mixed direct and multihop bgp peering inside 

the VRF, rpd will crash if it tries to install a multipath bgp route. [PR705086: This issue 


• PE router puts a wrong value in OSPF Route Type Extended Community Attribute when 

advertises BGP route to remote PE. The issue can be seen in L3VPN setup when OSPF 

running between PE and CE with "route-type-community vendor" configured under 

the routing-instance. [PR705915: This issue has been resolved.] 

• For a BGP session with bgp damping enabled after a flap the received prefixes are not 

reported correctly in show bgp summary and show bgp neighbour commands. 


• When an igmp-only interface is configured and we have static/dynamic groups, PIM 

XIF code could modify the corresponding route table entry inline without waiting for 

pim to install the route. During this time, the entry could point to non-multicast nexthop, 

such as FLOOD NH. This problem is rare and not easily reproducible. [PR712137: This 


• The Routing Protocol Daemon (RPD) may leave a soft core if there are multiple paths 

for the same L2VPN connections. [PR717541: This issue has been resolved.] 

• rpd core observed at rt_nh_cmp on the back up while trying to sync the selected gw 

with the master. For this issue to trigger, NSR needs to be enabled, 

per-packet-load-balance needs to be disabled and there should be multiple paths in 

the BGP. [PR718759: This issue has been resolved.] 

• When trying to send BGP packets with message size more than 4092 bytes (the 

maximum length of BGP message is 4096 bytes), the RPD daemon will crash. 


• When BGP is configured with BFD enabled, if there is a BGP peer established with direct 

connection, after interface is disabled/deactivated, BFD will send a Admin Down state 

notification to the remote peer. This might cause the BGP session not to be teared 

down until BGP hold timer expires resulting in a short temporary traffic blackhole. 


• The configuration of DDoS Protection has changed slightly. You can now include the 

disable-fpc statement at the [edit system ddos-protection protocols protocol-group 

(aggregate | packet-type)] hierarchy level to disable policers on all line cards for a 

282 



particular packet type or aggregate within a protocol group. The ability to configure 

this statement globally or for a particular line card remains unchanged. You can also 

now include the disable-logging statement at the [edit system ddos-protection protocols 

protocol-group (aggregate | packet-type)] hierarchy level to disable router-wide logging 

of DDoS violation events for a particular packet type or aggregate within a protocol 

group. The disable-logging statement has been moved from the [edit system 

ddos-protection violation] hierarchy level, and that hierarchy level has been removed 

from the CLI. The show ddos-protection protocols command now displays Partial in 

the Enabled field to indicate when some of the instances of the policer are disabled. 

The Routing Engine Information section of the output now includes fields for bandwidth, 

burst, and state. The show ddos-protection protocols parameters command and the 

show ddos-protection protocols statistics command now include a terse option to 

display information only for active protocol groups--that is, groups that show traffic 

in the Received (packets) column. The show ddos-protection protocols parameters 

command also displays part. for policers that have some disabled instances. [PR722873: 


• If BGP export policies are ran for the routes coming from restarting BGP router (graceful 

restarting router) during graceful restart then helper router may end up advertising less 

routes to remote BGP peers. One possible scenario is IGP graceful restart failure during 

BGP graceful restart. [PR723809: This issue has been resolved.] 

• In NG-MVPN environment, local receiver (the multicast receiver and source are 

connected with the same PE) multicast traffic might be dropped when Provider Tunnel 

flaps. [PR724131: This issue has been resolved.] 

• In a scaled Layer 3 MPLS VPN network with the "l3vpn-composite-nexthop" knob 

enabled, if BGP multipath is configured, the routing protocol daemon (RPD) may crash 

when topology changes. [PR724615: This issue has been resolved.] 

• When L3VPN composite nexthop and BGP multipath are enabled, Routing Engine 

Daemon (RPD) might dump core files which is because of multipath composite nexthop 

unresolved and when downloading such a nexthop to kernel, the issue occurs. 


• An error in the logic for nonstop routing switchover when family "inet6 labeled-unicast" 

is configured causes RPD to crash after a nonstop routing switchover. [PR736669: This 


• Conditions : - If route generate statement is configured to install the next-hop from 

prefixes learned from multiple BGP peers and the contributing routes have a different 

preference2 value. Trigger : When the BGP neighbor that advertises the primary 

contributing prefix for the generate route goes down, then the next hop for the route 

generated by the route generate statement, might get stuck pointing to the BGP peer 

that is down. [PR738206: This issue has been resolved.] 

• Two Mx960 connected via two aggregate Ethernet links and these are distribution 

routers. aggregate Ethernet flap test was executed on one of the Mx960, where all the 

ae links were flapped twice randomly.Core occured on other Mx960 during this test 

execution. [PR740116: This issue has been resolved.] 


283



• This PR is because of misconfiguration. Hence it is better to avoid misconfiguration. 

Due to misconfiguration if the Local Address of Dynamic L2TP SI is same as tunnel 

Destination , it results in to recursion because NH of tunnel Destination itself is the 

same tunnel Destination. For example: set dynamic-profiles dyn-lns-profile0 interfaces 

$junos-interface-ifd-name unit $junos-interface-unit family inet address 60.0.0.1/24 

set interfaces ge-1/3/0 unit 11 family inet address 60.0.0.1/24 set services l2tp 

tunnel-group ce-l2tp-tunnel-group3 service-interface si-1/3/0 Workaround would be 

to have different network addresses given in si interface ( dynamic configuration ) than 

that of access interface. [PR677189: This issue has been resolved.] 

• IDP Policy failed to get installed on deleting nat rules and adding it [PR679178: This 


• Certain COS configuration on IRB interface that has MS-DPC results in such errors 

which has no functionality issues. [PR680944: This issue has been resolved.] 

• There was SNMP data collection problem and it is fixed. [PR689249: This issue has 


• When you send a DTCP version 0.7 ADD message with X-JTAP-IP-VERSION field set 

to Ipv6, you would see Junos OS router returning '400, Bad Request'. As a workaround, 

you can use DTCP version 0.8. [PR692005: This issue has been resolved.] 

• In production networks there can be cases where we can have temporary double user 

login because of ungraceful ppp session termination from client side, and there is an 

immediate login from the same user. These cases are not being handled properly on 

l2tp code for m7i/m10i/m120 with service PIC which is leading to routes for 

Framed-IP-Address and Framed-Route to be deleted completely from routing table 

when the old l2tp session is teared down because of lcp keepalive timeouts. [PR695585: 


• When toggling between source-prefix and source-pool values for inline NAT, behavior 

of the NAT feature was inconsistent. The fix to the PR resolved the issue and the proper 

pool or prefix is always used. [PR696700: This issue has been resolved.] 

• When running MS-PIC or MS-DPC configured for Stateful-Firewall NAT service with 

Address-Pooling Paired (APP) and Endpoint-Independent Mapping (EIM) enabled, if 

the pattern of the traffic causes the PIC to report "AP port allocation errors", upon 

expiring of some flows the PIC might dump a core and restart. [PR699662: This issue 


• When the bypass-traffic-on-pic-failure configuration knob is used, and following a 

crash of the MSPMAND daemon on the MS400 pic, on which the IDP package is 

installed, the bypass is not triggered immediately because there is generation of a core 

file. This causes black-holing of traffic. The fix for this issue is to let the traffic bypass 

start immediately when MSPMAND cores, and the PIC is considered in a failure state. 


• When running a service-set with stateful-NAT configured that includes address-pooling 

paired and endpoint-independent mapping, NAT ports and/or NAT address/port 

284 



mappings might not get released when corresponding flows are removed and mapping 

timeout timers are expired. [PR702934: This issue has been resolved.] 

• Flows are not getting created in cases as restarting pic, doing graceful Routing Engine 

switchover twice, high number of VRFs configured. This issue will be hit quickly with 

large number of ifls. The other symptom of this PR is wrong values seen in source AS 

, destination AS values. [PR706803: This issue has been resolved.] 

• The issue is seen only with l2tp data traffic with tunnel-id/session-id 0/0 is exceptioned 

to the Routing Engine. [PR707253: This issue has been resolved.] 

• When running a Stateful-Firewall NAT service-set with EIM (Endpoint Independent 

Mapping) the MS-PIC or MS-DPC might dump a core file upon mapping expiration 


• When running IDP service traffic inspection on MS-PIC or MS-DPC, the inspection of 

MS-RPC and other application traffic might lead the mspmand daemon to restart and 

dump a core file. [PR709412: This issue has been resolved.] 

• If you have traceoptions configured under the sampling stanza and make configuration 

changes which requires sampled daemon to re-read the configuration again via SIGHUP, 

we do leak file descriptors. Once you run out of file descriptors the following syslog 

message will be reported /kernel: %KERN-2: kern.maxfiles limit exceeded by uid 2018, 

please see tuning(7). If you restart sample daemon with the CLI command restart 

sampling gracefully" all open file descriptors will be released. [PR709889: This issue 


• The time when flow record packet is sent out becomes inaccurate after MS-PIC (or 

MSDPC)runs over 49.7 days. As a result, flow record packet will be delivered to the 

flow collector at unexpected time and the time lag will be seen with the traffic trend 

based on SNMP data. [PR718209: This issue has been resolved.] 

• The Service PIC will crash when traceroute is run over Ds-Lite softwire. [PR720935: 


• When enabling the PPTP Application Layer Gateway module in presence of Statefull 

Firewall NAT service-set configurations, the "Set-Link-Info Peer Call Id" and "Echo-Reply 

Id" PPTP parameters might be incorrectly translated when crossing the ALG. [PR721810: 


• Even without traffic, if there is more than one service-set, Packet Forwarding Engine 

kernel connectivity can be lost because of memory leak on Packet Forwarding Engine 

level [PR728677: This issue has been resolved.] 

• If running services IDS, a memory leak can occur. [PR738019: This issue has been 

resolved.] 


• When a CoA, sent to a service session of a subscriber, contains more than one change 

request, then it can happen, that some of the changes are executed while others aren't 

and 'Invalid-Request' response is returned. The Fix to this PR addresses the case when 

a service deactivation and activation using non-existant filters is sent in one CoA. The 


285


correct behavior is to return 'Invalid-Request' and keep the active service session 

untouched. [PR692331: This issue has been resolved.] 

• "client-idle-timeout" under access profile stanza does not work when RADIUS 

accounting is not configured [PR717870: This issue has been resolved.] 


• A deactivate; commit; activate on "set forwarding-options ip-options-protocol-queue" 

may cause RSVP Hello packets to be dropped. [PR690827: This issue has been 

resolved.] 


• With the addition of "allow-configuration-regexps" and "deny-configuration-regexps" 

to control router configuration access for users in Junos OS Release 11.2, the configured 

settings were not properly displayed in the output of "show cli authorization". The fix 

for this PR addresses this issue. [PR696738: This issue has been resolved.] 

• "show system users" command will not work when Jweb is not installed in the device. 


• With large configuration, MGD may crash after issuing show | compare command. 


VPLS 

• VPLS routing table reference count have to be decremented on removal. [PR674009: 


• The message is harmless and the severity of the log message was changed from ERROR 

to DEBUG [PR694138: This issue has been resolved.] 

• Forwarding stops on this VPLS routing-instance because of incorrect handling of 

indirect nexthop. [PR694304: This issue has been resolved.] 

• When multiple VPLS instances are configured using manually-defined mesh-groups 

and some without defining mesh-groups, show vpls connections may not display some 

of them. [PR709061: This issue has been resolved.] 

VPNs 

• Under NG-MVPN scenario, if the provider tunnels are shared by multiple routing 

instances. When a "clear bgp neighbor" is issued on the PE that is the egress for the 

provider tunnel, not all provider-tunnels recover. Some LSPs stay is down state (state 

is UP on the egress but down on the ingress of the LSP). [PR687998: This issue has 


• Under NG-MVPN scenario with ingress replication, some of the traffic will be lost after 

ingress router reboot because of the binding of the customer multicast routes to the 

inclusive ingress-replication tunnel is missing. [PR690210: This issue has been resolved.] 

• Due to implementation flaws,Downstream interface list(OIL)for MVPN with multicast 

receivers directly connected to the PE was not getting created properly.After the fix of 

286 



this defect,OIL is listing all the interfaces appropriately. [PR690237: This issue has been 

resolved.] 

• bootstrap-import filters BSR packets from lsi/vt intf wrongly. [PR702198: This issue 


• In Rosen MVPN scenario, the Routing Protocol Daemon (RPD) might dump core files 

after PIM mdt group-range configuration is changed. [PR704648: This issue has been 

resolved.] 

• Under NG-MVPN scenario, when there are multiple router reflectors in the core or there 

are fast routes flapping on source PE, after issue clear pim join command on source 

PE, multicast traffic from the source to the receivers will be stopped. [PR706855: This 


• After a routing engine switchover, l2vpn address family routes may not be advertised 

by BGP. [PR707743: This issue has been resolved.] 

• In Multicast Tunnels environment, KRT queue (between RPD and Kernel) gets stuck 

with error 'ENOENT -- Item not found' after restarting the FPC containing the tunnel 

PIC in the box and sometimes there's a RPD (Routing Protocol Daemon) core on backup 

Routing Engine . [PR708189: This issue has been resolved.] 

• In a NG-MVPN setup a receiver PE will get the multicast traffic for a particular (C-S,C-G) 

even if it does not have any local C-Join for that particular group. This can happen if 

the following conditions are met: - a selective (S-PMSI) tunnel is used for that particular 

(C-S,C-G) - the provider tunnel signaling protocol is mLDP - the receiver PE is running 

Junos OS 11.4R1.14 - another receiver PE (running any Junos OS Release) in the same 

MVPN instance has a C-Join for that (C-S,C-G) [PR725027: This issue has been 

resolved.] 

• The different endianness of an MX80's PowerPC was not considered in 

mpls-internet-multicast functions, causing routing failures. [PR732563: This issue has 






287



• Any sampling related configuration changes are committed when the sampled process 

is running, the old sampling instance tree is deleted and a new tree is created. With 

this issue, when the old sampling instance tree is deleted, the system dumps core files. 



• On an MX480 router the Multiservices DPC crashes because of a race condition when 

the IPsec SA bundle ptr is set to NULL from the control thread as a result of SA delete 

msg from the kmd-re, while a data thread(s) tries to access the same SA ptr after 

verifying that the ptr is not NULL. [PR698788: This issue has been resolved.] 


• In certain scenarios, the DHCP relay packets might be rejected. [PR695083: This issue 



• On M120, M7i/M10i with enhanced CFEB, M320 with E3 FPCs, and MX Series routers 

with DPCs, when three or more MPLS labels are being pushed, the TTL of the innermost 

label might incorrectly be set to zero. [PR694163: This issue has been resolved.] 

Release 11.3 




• Certain mis-configuration causes check-out fail w/o proper reason. [PR597801: This 



• Kernel core during upgrade. [PR687671: This issue has been resolved] 

• On MX Series routers, the error message “/kernel: Unlist request: unilist(nh index = 

1048575) found on the rnhlist_deleted_root patnode” appears continuously. [PR667046: 

This issue has been resolved] 

• After a unified ISSU from Junos OS Releases 10.0 to 10.4, the sampling feature does 

not function. The sampled process responsible for sampling no longer receives the 

data from the Packet Forwarding Engine. [PR681271: This issue has been resolved] 


• On the ATM PIC cbr shaping rate configuration, specify a value in cells per second by 

entering a decimal number followed by the abbreviation c; values expressed in cells 

per second are converted to bits per second by means of the formula 1 cps = 384 bps. 

The cell rate configuration was removed from Junos OS releases from 10.1R1 and later 

which built between 23-Jan-2010 and 15-Sep-2011. As workaround, use bits per second 

288 



(bps) configuration to specify the ATM cbr shaping rate. The cell rate configuration 

has been added back from below Junos OS Releases and later: 10.4R8, 10.4S7, 11.1R6, 

11.2R3, 11.3R3 and 11.4R1. [PR685558: This issue has been resolved] 

• On the M120 router, when the no-vrf-propagate-ttl statement is set or deleted, the 

Forwarding Engine Board (FEB) might reboot and dump a core. [PR691466: This issue 

has been resolved] 

• When an interface enabled for OAM goes down, the message "first cells dropped at 

cif" is added to the system log file. [PR559492: This issue has been resolved] 


• When LFA link Protection is configured for IGP with LDP-IGP Synchronization enabled, 

if LSP(LDP) routes are installed in inet.0, after LDP session is cleared, the LDP session 

is not able to bring up. [PR600181: This issue has been resolved] 

• In a Next Generation MVPN scenario, a kernel memory buffer may get corrupted when 

the router receives a bootstrap or auto-RP message whose packet size exceeds 204 

bytes. The memory corruption will cause the Junos OS kernel to crash every time such 

a packet is received. This problem will only be encountered in a Next-Gen MVPN 

scenarios that use Ingress Replication as the P-tunnel type and has Auto-RP or 

Bootstrap as the group-to-RP mapping mechanism. [PR681963: This issue has been 

resolved] 

• When an IP route directly resolves over an LSP or the LSP route is also installed in 

inet.0 table, then the LSP statistics may incorrectly contribute to the bypass LSP 

statistics, even when packets are not being forwarded on the bypass LSP. [PR682966: 


• Under certain circumstances, the automatic bandwidth timer smearing function does 

not space out the timer interval evenly. Also, the interval between the timers are not 

equal. [PR606051: This issue has been resolved] 

Multicast 

• With Junos OS Release 10.0 or later performing ISSU software upgrade, multicast 

resolve routes for IPv6 or IPv6 routes might not be installed properly in all FPCs. 

Multicast traffic will not be forwarded anymore. The following syslog message will 

indicate the problem. RT: Failed prefix change IPv4:0 - 224/4 (unknown prefix) RT: 

Failed prefix change IPv6:0 - ff00::/8 (change failed) To recover from this condition 

FPC reporting the above syslog messages needs to get restarted. [PR559108: This 

issue has been resolved] 


• Mib2d may core when interfaces are created and deleted at very fast rate on scaled 

setup. [PR602812: This issue has been resolved] 

• The cause of the snmpd core in this PR is a result of the fix that went into PR607704. 

Junos OS Release 10.4R6 only is exposed to this issue at this time. [PR674874: This 

issue has been resolved] 


289


• When an SNMP MIB walk is performed for ipv6IfNetToMediaState without any IPv6 

configuration on the router, the error message "MIB2D_SYSCTL_FAILURE: 

ipv6_n2m_update_sysctl_info: sysctl getting kernel MD6 data failed: Bad address" 

appears. [PR612585: This issue has been resolved] 


• "commit at" with commit scripts sometimes may lockup CLI. [PR537074: This issue 


• The time stamp of the messages in firewall log is showing incorrect values. The system 

time and time stamp in log messages are not affected. If NTP server is configured, the 

issue does not happen. [PR661768: This issue has been resolved] 

• Under some rare scenario, it is possible for a DPC to fail to come online after being 

inserted or restarted. The logs will then show the message: "PFEMAN resync in progress" 

every 10 seconds. This is caused by a race condition on the routing-engine when it 

initially tries to download the configuration and routes to the DPC, and eventually 

causes the DPC to stay in dormant state. [PR609644: This issue has been resolved] 

• MPC might crash when aggregate interface configured because of invalid child members 

installed at Packet Forwarding Engine side. [PR695225: This issue has been resolved] 

• Failure to handle transient low memory conditions in the kernel. Fix involves retry the 

operation rather than asserting. [PR687618: This issue has been resolved] 


• When deleting a static route from a VRF instance the operator should avoid issuing a 

show route next-hop detail command for the newly deleted route 

for a period of 3 minutes. This ensures adequate time for even a highly scaled system 

to completely free all data structures associated with the deleted route and avoids 

the RPD crash documented in PR 605798. [PR605798: This issue has been resolved] 

• Issue happens with NSR switchover or ISSU update because of different indirect nh is 

allocetd on new master. The cnh code needs to handle refcount of cnh properly when 

change from old cnh to new cnh if new cnh already exists on patricia tree. [PR612182: 


• fbf route with qualified-next-hop and nexthop interface will installed route table 

wrongly. [PR670339: This issue has been resolved] 

• The show bgp summary command displays the wrong data regarding the active routes. 

A route can be active but not reported by the above command. [PR680080: This issue 


• When sham-link is activated the exported static route is erroneously treated as vpn 

route received via BGP. It resulted in that exported static route shows up in the database 

with DN bit set. [PR686947: This issue has been resolved] 

• It was not releasing the link for file , so code changes has been done for the same. 

[PR687959: This issue has been resolved] 

290 



• RPD may crash with BGP multipath configured if the route list includes BGP multipath 

routes along with non BGP routes for same destinations. [PR688763: This issue has 

been resolved] 

• If "forwarding-options sampling" or "routing-options route-record" is configured, stale 

routes may appear and persist in the routing table in holddown state. Those routes are 

not active and do not affect forwarding, but they do consume memory and if left will 

lead to the memory footprint of RPD increasing over time. For mpls routes it will also 

effect Packet Forwarding Engine and Kernel memory since the next-hops are not 

deleted till the route is deleted within RPD. Junos OS Releases 10.4R7 and 11.2R3 are 

effected. [PR688820: This issue has been resolved] 

• If bgp "keep all" is configured, and "multipath" is enabled under "routing-options" of 

a vrf, and there exists multiple equal cost bgp vpn routes for the same destination in 

bgp.l3vpn table, when this new vrf is added to the configuration, rpd may core because 

of a delayed bgp reconfig job in a scaled configuration. [PR691170: This issue has been 

resolved] 

• When 10-Gigabit Ethernet interfaces flap frequently, a routing protocol process (rpd) 

core file might be created. [PR691170: This issue has been resolved] 

• RPD might take long time to bring up an OSPF neighbor to FULL state when there are 

large number of OSPF neighbors with large size of OSPF LSA database. [PR692239: 


• Under some circumstances where a BGP router that has been configured with family 

route-target the router may fail to send some VPN routes. This will most typically 

happen for a PE router in a scaled configured that has received the default RT-Constrain 

route, 0:0:0/0. [PR692940: This issue has been resolved] 

• When family route-target is used on a PE and one or more peers that it is configured 

on do not negotiate RT-Constrain (RFC 4684), the PE will generate a default RTC 

route of 0:0:0/96. This default route is not appropriate for non-transit BGP hosts. By 

default, a BGP non-transit PE will discard VPN routes that do not have matching local 

route-target communities. If at a later time a VRF is configured with a route-target that 

it had previously discarded VPN routes for, the attached BGP neighbors will not re-send 

the appropriate VPN routes. This is because of the fact that the attached BGP neighbor 

had a matching default RTC route and thinks it has already sent the associated VPN 

routes. [PR695918: This issue has been resolved] 

• Changes to martian addresses (RFC5735 that obsoletes RFC3330), that are not present 

in Junos OS martians default settings. PSN-2011-10-393. [PR698121: This issue has 

been resolved] 

• The routing protocol process crashes when the default-lsa option is configured in an 

NSSA under a routing instance, which also receives a default route from another VPN 

instance. [PR606075: This issue has been resolved] 

• The routing protocol process might crash after a graceful Routing Engine switchover 

in a Layer 3 VPN with external or internal BGP multipath that contains a composite 

next hop as a component next hop. [PR665996: This issue has been resolved] 


291


• After a BGP session flap, the output of the show bgp summary command might not 

display the correct number of "Active routes" for VPN routing instances. [PR673830: 


• The ipMRouteInterfaceTable MIB walk does not display PIM SM interfaces. [PR678051: 


• The output of the show pim statistics inet6 command includes fields that are not 

necessary for IPv6 multicast. [PR682938: This issue has been resolved] 

• When a PIM is used between downstream PEs in an MVPN environment, the 

nondesignated PE router receives multicast traffic from a designated router on a 

downstream port. When reverse path forwarding occurs, faulty results are returned 

and the router always attempts to build the local multicast route table causing memory 

leaks in the routing protocol process. When the memory leak is large enough, the routing 

protocol process might crash and dump core files. [PR685111: This issue has been 

resolved] 


• The Routing Engine(s) will crash with a trap with the backtrace 

bcopy/if_pfe_ttp_output/if_pfe_ae_ttp_output. if_pfe_ttp_output may not appear in 

the backtrace. The configuration includes dhcp, PPPoE/VLAN, or demux/ae. [PR682735: 


• A panic occurs in rnh_index_alloc on the backup Routing Engine because the index is 

already allocated. In the syslog or kernel message buffer, a message similar to the 

following may be seen: "rnh_cont_request: demux0.14 (3353) Got nhid=120882 

but already have child nhid=118652 for cifl ge-0/1/5.32767 (3349)". [PR682967: This 


• CLI "show interface as0 extensive " does not show the sonet child member links stats 

part of aggregated bundle. This effects the monitoring & management of bandwidth 

concerns on the as bundle links. [PR677553: This issue has been resolved.] 

• With IPv6 and PPPoE, DHCP, or other demux configured, an assertion panic can occur 

in in6_ether_iffconfig(). [PR686350: This issue has been resolved.] 

• Adding configuration from "load set terminal" for restricted user may not allowed even 

for authorized configuration hierarchies. "load merge terminal" on the other hand does 

not have this issue. [PR678664: This issue has been resolved.] 

• Add constraint to [ system login user full-name ] to not allow newline (\n) 

characters. [PR690013: This issue has been resolved.] 

• Jweb does not work on the multi-core Routing Engines which have 64-bit Junos OS. 


• Right click option to Navigate to Chassis info or System info in Chassis view is not 

working properly. Instead operator is expected to navigate to respective page by clicking 

on that page itself from Monitor page instead of using right click option. [PR684849: 


292 


Errata and Changes in Documentation for Junos OS Release 11.4 for M Series, MX Series, and T Series Routers 

VPLS 

• With non-stop routing and a large number of LDP-based virtual-private LAN service 

configured, the routing process might crash during a routing-engine switchover event. 


• On certain topology, a core link flap might result in VPLS in RD state w/ 

pseudowire-status-tlv configuration. This is a timing issue and may not occur every 

time on every topology. [PR687375: This issue has been resolved.] 

VPNs 

• The routing protocol process dumps core files during a P-PIM process after the default 

MDT switches to a data MDT. [PR669365: This issue has been resolved.] 

Related 

Documentation 


on page 73 







Errata and Changes in Documentation for Junos OS Release 11.4 for M Series, MX Series, and T 

Series Routers 

Errata 


• The Junos OS Class of Service Configuration Guide contains errors in the following topics 

related to IEEE 802.1p inheritance: 

• The topic titled Understanding IEEE 802.1p Inheritance push and swap from a 

Transparent or Hidden Tag should be titled Understanding IEEE 802.1p Inheritance 

push and swap from a Transparent Tag, as in previous and subsequent versions. This 

section also incorrectly references a hidden tag and hidden statement, which are 

invalid. This topic should also include the following sentence: 

• MX Series routers with Modular Port Concentrators (MPCs) and Modular Interface 

Cards (MICs) support configurable IEEE 802.1p inheritance of push and swap bits 

from the transparent tag of each incoming packet, which allows you to classify 

incoming packets based on the IEEE 802.1p bits from the transparent tag. 

• The "hidden" configuration statement is not supported. Including the “hidden” 

statement was a documentation error, and the statement is therefore removed from 

subsequent versions. 


293


• The topic Configuring IEEE 802.1p Inheritance push and swap from the Hidden Tag 

was incorrectly included and is therefore removed from subsequent versions. 

• References to the "hidden" configuration statement and the topic "Configuring IEEE 

802.1p Inheritance push and swap from the Hidden Tag" are also incorrect. 

[Junos OS Class of Service Configuration Guide] 


• If you configure the icmp-code match condition in an IPv6 firewall filter, we recommend 

that you also configure the next-header icmpv6 or next-header icmp6 match condition 

in the same term. The next-header icmp6 and next-header icmpv6 match conditions 

perform the same function. next-header icmp6 is the preferred option. next-header 

icmpv6 is hidden in the Junos OS CLI. 


• TX Matrix Plus routers and T1600 routers that are configured as part of a routing matrix 

do not currently support nonstop active routing. 


• The Virtual Chassis Components Overview topic and the Guidelines for Configuring Virtual 

Chassis Ports topic in the Junos OS High Availability Configuration Guide incorrectly 

state that an MX Series Virtual Chassis configuration supports up to 24 Virtual Chassis 

ports per trunk. An MX Series Virtual Chassis configuration actually supports up to 16 

Virtual Chassis ports per trunk. 

[Junos OS High Availability Configuration Guide] 

• The MX Series Virtual Chassis documentation in the Junos OS High Availability 

Configuration Guide failed to include the following information about how slot numbering 

in the Virtual Chassis affects your use of SNMP. 

Junos OS supports the use of SNMP to monitor the routers and other devices in your 

network. For example, the Juniper Networks jnxBoxAnatomy enterprise-specific Chassis 

MIB contains the jnxFruTable object, which shows the status of field-replaceable units 

(FRUs) in the chassis. Within the jnxFruTable object, the jnxFruSlot object displays the 

slot number where the FRU is installed. 

If you are using the jnxFruSlot object in jnxFruTable to display the slot numbers of line 

cards installed in a member router of an MX Series Virtual Chassis, keep in mind that 

the offset used for slot numbering in an MX Series Virtual Chassis affects the value 

that appears for the jnxFruSlot object. 

Table 10 on page 295 lists the jnxFruSlot number that appears in the jnxFruTable of the 

jnxBoxAnatomy MIB, and the corresponding line card physical slot number in each 

member router of a two-member MX Series Virtual Chassis. For example, a jnxFruSlot 

value of 15 corresponds to physical slot 3 in member 0 of an MX Series Virtual Chassis. 

A jnxFruSlot value of 30 corresponds to physical slot 6 in member 1 of an MX Series 

Virtual Chassis. 

294 



Table 10: jnxFruSlot Numbers and Corresponding Slot Numbers in an MX 

Series Virtual Chassis 

jnxFruSlot Number 

Line Card Slot Number 

MX Series Virtual Chassis Member ID 

Line Cards in MX Series Virtual Chassis Member ID 0 (offset = 12): 

12 

0 

0 

13 

1 

0 

14 

2 

0 

15 

3 

0 

16 

4 

0 

17 

5 

0 

18 

6 

0 

19 

7 

0 

20 

8 

0 

21 

9 

0 

22 

10 

0 

23 

11 

0 

Line Cards in MX Series Virtual Chassis Member ID 1 (offset = 24) 

24 

0 

1 

25 

1 

1 

26 

2 

1 

27 

3 

1 

28 

4 

1 

29 

5 

1 

30 

6 

1 

31 

7 

1 

32 

8 

1 


295


Table 10: jnxFruSlot Numbers and Corresponding Slot Numbers in an MX 

Series Virtual Chassis (continued) 

jnxFruSlot Number 

Line Card Slot Number 

MX Series Virtual Chassis Member ID 

33 

9 

1 

34 

10 

1 

35 

11 

1 

[Junos OS High Availability Configuration Guide, Junos OS SNMP MIBs and Traps 

Reference] 


• The description of PR 675582 in the Previous Releases subsection under the Issues in 

Junos OS Release for M Series, MX Series, and T Series Routers main section, which lists 

the resolved issues, ambiguously mentions that unified ISSU is not supported when 

upgrading from Junos OS Release 10.x to 11.1 or 11.2 on M Series, T Series, and TX Series 

devices with multicast configuration. The correct statement regarding this limitation 

on unified ISSU is as follows: 

Because of certain changes to the Junos OS multicast infrastructure in Junos OS Release 

11.1 and later, unified ISSU is not supported when upgrading from Junos OS Release 

10.x to 11.1 or 11.2 and later on M Series, T Series, and TX Series devices with multicast 


[Release Notes] 


• 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 OS 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 interoperates with routers running all versions 

of Junos OS. 

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 this configuration, keep the following 

points in mind: 

• This configuration interoperates between Juniper Networks routers running Junos 

OS Release 8.2 or earlier. 

• This configuration does not interoperate with other network equipment, including a 

Juniper Networks router running Junos OS Release 8.3 or later. 

296 



• For a Juniper Networks router running Junos OS Release 8.3 or later to interoperate 

with another Juniper Networks router running Junos OS Release 8.2 or earlier, on the 

router running Junos OS Release 8.3 or later, 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 OS Release 

8.2 or earlier. 

[ATM Interfaces] 

• With Junos OS Release 10.1 and later, you need not include the tunnel option or the 

clear-dont-fragment-bit statement when configuring allow-fragmentation on a tunnel. 


• The 10.3 through 11.1 Network Interfaces Configuration Guides and the 11.2 Ethernet 

Interfaces Configuration Guide require the following corrections: 

• A new fifth bullet was added to the "802.3 link aggregation" bullet list, as follows: 

Multiple Juniper Networks Type 4, 100-Gigabit Ethernet PICs on a T1600 router can 

be combined into a static aggregated Ethernet bundle to connect to a different type 

of 100 gigabit Ethernet PIC on a remote router, from Juniper Networks or other 

vendors. LACP is not supported in this configuration. 

• The "Ingress traffic performance" bullet was revised and now reads as follows: 

Ingress traffic performance—Maximum ingress throughput is 100 gigabits per second 

on the physical interface, with 50 gigabits per second on the two assigned logical 

interfaces. To achieve 100 gigabits per second ingress traffic performance, use one 

of the interoperability modes described below. For example, if VLAN steering mode 

is not used when connecting to a remote 100 gigabits per second interface (that is 

on a different 100 gigabits per second PIC on a Juniper Networks router or a different 

vendor’s equipment), then all ingress traffic will try to use one of the 50 gigabits per 

second Packet Forwarding Engines, rather than be distributed among the two 50 

gigabits per second Packet Forwarding Engines, resulting in a total of 50 gigabits 

per second ingress performance. 

[Network Interfaces, Ethernet Interfaces] 

• The 20-port Gigabit Ethernet MIC (MIC-3D-20GE-SFP) does not have hardware 

counters for VLAN frames. Therefore, the VLAN tagged frames field displays 0 when 

the show interfaces command is executed on a 20-port Gigabit Ethernet MIC. In other 

words, the number of VLAN tagged frames cannot be determined for the 20-port 

Gigabit Ethernet MIC. This information is documented in Junos OS Documentation, 

Release 12.2 and later only. 

• Single-core Routing Engine support for M7i and M10i routers—The information about 

the single-core Routing Engine support on M7i and M10i routers is not updated as part 

of Junos OS Documentation, Release 11.4R4. More information about this feature will 

be added to the Junos OS Interfaces Fundamentals Configuration Guide and Junos OS 

Software Installation and Upgrade Guide in Junos OS Release 12.2R1. 


297


• The show chassis network-services command displays the network services mode that 

is currently active and running on the router, instead of the configured network services 

mode. 


• The lmi-type statement incorrectly states that Consortium LMI is supported only on 

M320 routers with Enhanced III FPCs and specific IQE PICs and on MX80, MX240, 

MX480, and MX960 routers with MICs specified in the Configuring Tunable Keepalives 

for Frame Relay LMI section. The following is the correct compatibility statement: 

Consortium LMI is supported on all MPCs and I-chip based FPCs. 

[Frame Relay Interfaces] 

• The interface-mode configuration statement topic incorrectly states that you cannot 

use the accept option with the interface-mode statement at the [edit interfaces 

interface-name unit logical-unit-number family bridge] and [edit logical-systems 

logical-system-name interfaces interface-name unit logical-unit-number family bridge] 

hierarchy levels to configure a logical interface to accept untagged packets on MPCs 

or MICs. You can configure the access option with the interface-mode statement to 

accept untagged packets on MPCs or MICs on MX Series routers. 


• The show chassis fabric reachability and the show chassis fabric unreachable-destinations 

command topics fail to state that these commands are also supported on MX240, 

MX480, and MX960 routers from Junos OS Release 11.4R2 and Junos OS Release 12.1. 

The Supported Platforms section of this topic fails to mention MX240, MX480, and 

MX960 routers on which these commands are supported. 


• The Interfaces and Chassis subsection in the New Features in Junos OS Release for M 

Series, MX Series, and T Series Routers section of the Junos OS 12.1R1 and Junos OS 

11.4R3 Release Notes fails to describe the following information regarding support for 

disabling FPCs with degraded fabric bandwidth. This feature is available in Junos OS 

Release 12.1R1 and later, and Junos OS Release 11.4R3 and later. 

Support for disabling an FPC with degraded fabric bandwidth —An FPC working with 

degraded fabric bandwidth can affect the re-routing process and can cause partial 

traffic black holes. On an MX960, MX480, or MX240 router, you can now configure 

the option to bring down an FPC whose fabric bandwidth has degraded because of 

link errors or bad fabric planes. This configuration is particularly useful in partial black 

hole scenarios where bringing the FPC offline results in faster re-routing. 

To configure this option on an FPC, use the offline-on-fabric-bandwidth-reduction 

statement at the [edit chassis fpc slot-number] hierarchy level. 




• The Interfaces and Chassis subsection in the New Features in Junos OS Release for M 

Series, MX Series, and T Series Routers section of the Junos OS 12.2R1 and Junos OS 

298 




redundancy fabric mode for active control boards on MX Series routers. This feature 

is available in Junos OS Release 11.4R3 and later, and Junos OS Release 12.2 and later. 

Support for redundant fabric made on active control boards of MX Series routers—An 

FPC working with reduced fabric bandwidth can affect the re-routing process and can 

cause partial traffic black holes. You can now enable increased fabric bandwidth of 

active control boards for optimal and efficient performance and traffic handling. On 

an MX960, MX480, or MX240 router, you can configure the active control board to be 

in redundancy mode or in increased fabric bandwidth mode. In increased fabric 

bandwidth mode, the maximum number of available fabric planes are used for MX 

routers with Trio chips and the MPC3E. On MX960 routers with active control boards, 

6 active planes are used, and on MX240 and MX480 routers with active control boards, 

8 active planes are used. 

To configure redundancy mode for the active control board, use the redundancy-mode 

redundant statement at the [edit chassis fabric] hierarchy level. When you configure 

this option, all the FPCs use 4 fabric planes as active planes, regardless of the type of 

the FPC. If you do not configure this option, increased fabric bandwidth mode is enabled 

by default on MX routers with Switch Control Board (SCB). The MX Series routers that 

contain the enhanced Switch Control Board (SCB) with Trio chips and the MPC3E, the 

control boards operate in redundancy fabric mode (all the FPCs use 4 fabric planes 

as active planes) by default. 

To configure increased bandwidth mode for the active control board, use the 

increased-bandwidth statement at the [edit chassis fabric] hierarchy level. When you 

configure this option, all the available fabric planes are used. 



You can use the show chassis fabric redundancy-mode command to verify whether the 

redundancy fabric mode is enabled. 


• The Interfaces and Chassis subsection in the New Features in Junos OS Release 12.2 for 

M Series, MX Series, and T Series Routers section of the Junos OS 12.1R1 and Junos OS 


limiting black hole-time by detecting unreachable destinations. This feature is available 

in Junos OS Release 11.4R2 and later, and Junos OS Release 12.1R1 and later. 

Limiting traffic black-hole time by detecting Packet Forwarding Engine destinations 

that are unreachable over the fabric (MX240, MX480, and MX960 routers)—Enables 

the MX240, MX480, and MX960 routers to limit traffic black-hole time by detecting 

unreachable destination Packet Forwarding Engines. The router signals neighboring 

routers when it cannot carry traffic because of the inability of some or all source Packet 

Forwarding Engines to forward traffic to some or all destination Packet Forwarding 

Engines on any fabric plane, after interfaces have been created. This inability to forward 

traffic results in a traffic black hole. 

Packet Forwarding Engine destinations can become unreachable for the following 

reasons: 


299


• The control boards go offline as a result of a CLI command or a pressed physical 

button. 

• The fabric control boards are turned offline because of high temperature. 


• All Packet Forwarding Engines receive destination errors on all planes from remote 



When the system detects any unreachable Packet Forwarding Engine destinations, 

healing from a traffic black hole is attempted. If the healing fails, the system turns off 

the interfaces, thereby stopping the traffic black hole. 

The recovery process consists of the following phases: 


by one. This phase does not start if the fabric plane is functioning properly and a 

single Flexible PIC Concentrator (FPC) is bad. An error message is generated to 

specify that a black hole is the reason for the fabric plane being turned offline. This 

phase is performed for fabric plane errors only. 

2. Fabric plane and FPC restart phase: The system waits for the first phase to be 

completed before examining the system state again. If the black hole condition still 

persists after the first phase is performed or if the problem occurs again within a 

duration of 10 minutes, healing is attempted by restarting both the fabric planes 

and the FPCs. If you the configured the action-fpc-restart-disable statement at the 

[edit chassis fabric degraded] hierarchy level to disable restart of the FPCs when a 

recovery is attempted, an alarm is triggered to indicate that a traffic black hole has 

occurred. In this second phase, three steps are taken: 

1. All the FPCs that have destination errors on a PFE are turned offline 

2. The fabric planes are turned offline and brought back online, one by one, starting 

with the spare plane. 

3. The FPCs that were turned offline are brought back online. 

3. FPC offline phase: The system waits for the second phase to be completed before 

examining the system state again. Traffic black hole is limited by turning the FPCs 

offline and by turning off interfaces because previous attempts at recovery have 

failed. If the problem is not resolved by restarting the FPCs or if the problem recurs 

within 10 minutes after restarting the FPCs, this phase is performed. 





In Junos OS Release 11.4R2 and later, and Junos OS Release 12.1R1 and later, new alarms 

are added to indicate which FPCs are creating a traffic black hole in the system and 

to provide information about FPCs that are turned offline to stop the black hole in the 

recovery process. 

300 



In Junos OS Release 11.4R2 and later, and Junos OS Release 12.1R1 and later, new error 

messages are added to indicate whether the traffic black hole is detected by 

unreachable FPCs in the system, or it is due to all planes being offline. These messages 

also indicate the actions taken on FPCs and planes to stop the black hole—for example, 

FPC online, FPC offline , FPC restart, FPC power off, plane online, and plane offline. 

Two new CLI commands are introduced for this feature: 






• The tunnel-services configuration statement topic incorrectly states that you can use 

the tunnel-services statement to specify that the IQ2 or IQ2E PIC will work both as a 

regular PIC and as a tunnel PIC. The correct functionality of the tunnel-services 

statement is as follows: 

You can specify the IQ2 and IQ2E PICs to work exclusively in tunnel mode or as a regular 

PIC. To configure exclusive tunnel mode, use the tunnel-only statement at the [edit 

chassis fpc slot-number pic slot-number tunnel-services] hierarchy level. The default 

setting uses IQ2 and IQ2E PICs as a regular PIC. If you do not configure the tunnel-only 

option, the IQ2 and IQ2 PICs operate as regular PICs. 

[System Basics, Chassis-Level Features] 

• The frame-error configuration statement topic incorrectly states that the default 

window during which frame errors are counted until they reach the configured threshold 

is 100 milliseconds. The correct description of the default window is as follows: 

The window or period during which frame errors are counted is 5 seconds or multiples 

of it (with a maximum value of 1 minute). This window denotes the duration as intervals 

of 100 milliseconds, encoded as a 16-bit unsigned integer. This window is not 

configurable in Junos OS. According to the IEEE 802.3ah standard, the default value 

of the frame-errors window is 1 second. This window has a lower bound of 1 second 

and an upper bound of 1 minute. 


• In the Chassis Conditions That Trigger Alarms section, the introductory paragraph 

contains an incorrect link for Table 9. Instead of specifying Table 9 as a link, the "Chassis 

Component Alarm Conditions on M5 and M10 Routers" heading that points to Table 

1 is presented. The correct description is as follows: 

Table 1 through Table 9 list the alarms that the chassis components can generate. 

Also, the following additional information regarding the generation of alarms when 

the management interface is down in routers with a single Routing Engine or the master 

Routing Engine applies to Table 1 through Table 8. 


301


Table 11: Chassis Component Alarm Conditions 

Chassis 

Component 

Alarm Condition 

Remedy 

Alarm 

Severity 

Routing Engine 

The Ethernet management 

interface (fxp0 or em0) on 

the Routing Engine is down. 

• Check the interface 

cable connection. 

• Reboot the system. 

Red 

• If the alarm recurs, open 

a support case using the 

Case Manager link at 

http://www.juniper.net/support/ 

or call 1-888-314-JTAC 

(within the United 

States) or 

1-408-745-9500 (from 

outside the United 

States) 

[System Basics, Chassis-Level Features] 

• The Support for redundant fabric made on active control boards of MX Series routers 

topic in the Interfaces and Chassis subsection in the New Features in Junos OS Release 

12.2 for M Series, MX Series, and T Series Routers section of the Junos OS 12.2R2 Release 

Notes and Junos OS 11.4R6 Release Notes erroneously states that If you do not configure 

the redundancy-mode redundant statement at the [edit chassis fabric] hierarchy level, 

increased fabric bandwidth mode is enabled by default on MX routers. 

The correct default behavior of redundant fabric mode on MX routers is as follows: 

Increased fabric bandwidth mode is enabled by default on MX routers with Switch 

Control Board (SCB). On MX routers that contain the enhanced SCB with Trio chips 

and the MPC3E, redundancy mode is enabled by default. 



• To access the J-Web interface, your management device requires the following 

software: 

• Supported browsers—Microsoft Internet Explorer version 7.0 or Mozilla Firefox version 

3.0 

• Language support—English-version browsers 

302 



• Supported OS—Microsoft Windows XP Service Pack 3 


• In the Junos OS Configuration and Operations Automation Guide, the archive-sites 

configuration statement incorrectly states that you can configure an HTTP URL at the 

[edit event-options destinations dest-name archive-sites url] hierarchy level. HTTP URLs 

are not supported under this configuration hierarchy level. 



• In the Layer 2 Configuration Guide, the examples provided in the sections Configuring 

Layer 2 Protocol Tunneling, Configuring BPDU Protection on Individual Interfaces, and 

Configuring BPDU Protection on All Edge Ports are incorrect for configuring Layer 2 

tunneling with routing instances. 

• In the MX Series Ethernet Services Routers Solutions Guide, the configuration commands 

in the Example: Configuring One VPLS Instance for Several VLANs section incorrectly 

describe the usage of the vlan-id all statement for normalizing VLANs in VPLS instances. 

The following information replaces the configuration commands and supplements 

the description in that section for the sample topology: 

Alternatively, instead of configuring a VPLS instance, you can define a virtual switch 

with a bridge domain and associate the logical interfaces as trunk ports with the bridge 

domain. This configuration is necessary if you want to configure a list or range of VLAN 

IDs on the logical interfaces and use the vlan-id all statement to normalize VLANs. 

A Layer 2 virtual switch, which isolates a LAN segment with its spanning-tree protocol 

instance and separates its VLAN ID space, filters and forwards traffic only at the data 

link layer. Each bridge domain consists of a set of logical ports that participate in Layer 

2 learning and forwarding. 

You can configure VPLS ports in a virtual switch so that the logical interfaces of the 

Layer 2 bridge domains in the virtual switch can handle VPLS routing instance traffic. 

VPLS configuration no longer requires a dedicated routing instance of type vpls. Packets 

received on a Layer 2 trunk interface are forwarded within a bridge domain that has 

the same VLAN identifier. A trunk interface is implicitly associated with bridge domains 

based on VLAN membership. 

You can use either of the following two mechanisms to normalize VLAN identifiers and 

process them in a bridge domain or a VPLS routing instance: 

• By using the input-vlan-map and the output-vlan-map statements at the [edit 

interfaces interface-name] hierarchy level to configure VLAN mapping. 

• By using either the vlan-id statement or the vlan-tags statement to configure a 

normalizing VLAN identifier. 

The vlan-id and vlan-tags statements are used to specify the normalizing VLAN identifier 

under the bridge domain or VPLS routing instance. The normalizing VLAN identifier is 

used to perform the following functions: 


303


• Translate, or normalize, the VLAN tags of received packets received into a learn 

VLAN identifier. 

• • Create multiple learning domains that each contain a learn VLAN identifier. A 

learning domain is a MAC address database to which MAC addresses are added 

based on the learn VLAN identifier. 

If 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. You cannot use 

the native vlan- id statement when the vlan-id all statement is included in the 


For the same network topology illustrated in Figure 1, if VLANs 1 through 1000 for 

customer C1 span the same sites, you can normalize the VLANs by doing one of the 

following. Using either of these optimal methods, you can switch and normalize all of 

these VLANs in an effective, streamlined manner without configuring separately for 

each VLAN ID. 

• By configuring a VPLS routing instance if the logical interfaces are specified with a 

range of consecutive VLANs or a list of non-contiguous VLAN IDs and using VLAN 

maps to rewrite the VLAN tags on all of the incoming and outgoing packets on the 

logical interfaces with a normalized VLAN ID 

• By configuring a virtual-switch instance consisting of a set of bridge domains that 

are associated with one or more logical interfaces configured as a trunk port 

You cannot use the vlan-id statement to enable VLAN normalization in VPLS instances, 

if the logical interfaces in the VPLS instance are configured with the vlan-id-list or 

vlan-id-range statement. In such a scenario, you can use the input-vlan-map or the 

output-vlan-map option to achieve VLAN normalization. 

The following example illustrates the use of the VLAN mapping functionality in VPLS 

routing instances to normalize VLANs. This method is beneficial in scenarios with 

flexible VLAN tagging (asymmetric tag depth). In such an environment, the VLAN 

configuration data that you specified applies the appropriate VLAN tags to the input 

and output VLAN maps for the ingress and egress logical interfaces respectively. For 

example, if certain packets are received as single- tagged packets and if the remaining 

packets are received as double-tagged packets, using VLAN mapping enables 

normalization. 

Using the VLAN mapping capability is effective only if packets of unequal VLAN tags 

are received or transmitted from logical interfaces to achieve normalization. We 

recommend that you do not use VLAN mapping in environments in which the VLAN 

tags are of equal tag depths for optimal configuration. In such cases, you can use the 

vlan-id all statement to enable normalization of VLANs. 

[edit] 

interfaces ge-1/0/0 { 



unit 1 { 

encapsulation vlan-vpls; 

vlan-id-range 1-1000; 

304 



input-vlan-map { 

push; /* Push the service vlan on input */ 

vlan-id 1200; # This VLAN ID is the normalized VLAN for incoming packets 

} 

output-vlan-map pop; /* Pop the service vlan on output */ 

} 

unit 11 { 


vlan-id 1500; 

} 

} 




unit 1 { 


vlan-id-range 1-1000; # Note the use of the VLAN id range statement. 




} 


} 

} 

} 




unit 1 { 


vlan-id 1-1000; 




} 


} 

} 

} 




unit 11 { 


vlan-id 1500; 

} 

} 

routing-instances { 

customer-c1-v1-to-v1000 { 

instance-type vpls; 

interface ge-1/0/0.1; 



} # End of customer-c1-v1-to-v1000 

customer-c1-v1500 { 

instance-type vpls; 


305




} # End of customer-c1-v1500 

} # End of routing-instances 

The following operations are performed when you use the VLAN mapping configuration: 

• Packets received on logical interfaces ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, with 

a single VLAN tag in the range from 1 through 1000 in the frame are accepted. 

• The VLAN tags of a received packet are compared with the normalized VLAN tags 

specified with the vlan-id statement in the input VLAN map. If the VLAN tags of the 

received packet are different from the normalized VLAN tags, then the received VLAN 

tag is converted to the normalized VLAN tag of 1200 for packets received on the 

logical interface ge-1/0/0.1. Similarly, for logical interface ge-2/0/0.1, the normalized 

VLAN tag is 1300 for received packets and for logical interface ge-3/0/0.1, the 

normalized VLAN tag is 1400. Then, the source MAC address of a received packet is 

learned based on the normalized VLAN configuration. 

For output packets, based on the output vlan-map pop statement configured on the 

logical interfaces ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, if the VLAN tags associated 

with an egress logical interface do not match the normalized VLAN tags within the 

packet, then the VLAN tags in the packets that are being transmitted from the egress 

logical interface are removed. 

• Unknown source MAC addresses and unknown destination MAC addresses are 

learned based on their normalized VLAN values of 1 through 1000. 

• All packets sent on the VPLS pseudowire have a normalized VLAN tag after the 

source MAC address field in the encapsulated Ethernet packet. 

• The input-vlan-map pop and output-vlan-map push statements on the logical interface 

cause the service VLAN ID to be popped on input and the service VLAN ID to be 

pushed on output and in this way, the impact of doubly-tagged frames on scaling is 

limited. 

The following example illustrates the use of the vlan-id all statement in logical interfaces 

when a virtual switch instance with a bridge domain is associated with the logical 

interfaces. You can normalize VLANs and create learning domains for each VLAN. A 

routing instance uses a trunk bridge to connect different departments in an organization, 

each with their own VLANs, at two different sites. You must configure a bridge domain 

and VLAN identifier for each VLAN associated with the trunk interface. 

[edit] 




unit 1 { 


family-bridge { 

interface-mode trunk; 


} 

} 

unit 11 { 

306 




family-bridge { 


vlan-id 1500; 

} 

} 

} 




unit 1 { 




} 

} 

} 




unit 1 { 




} 

} 

} 




unit 11 { 



vlan-id 1500; 

} 

} 

} 

routing-instances { 

customer-c1-virtual-switch { 

instance-type virutal-switch; 




bridge-domains { 

c1-vlan-v1-to-v1000 { 

vlan-id all; # Note the use of the VLAN id all statement 

} 

} 

} # End of customer-c1-v1-to-v1000 

customer-c2-virtual-switch { 

instance-type virtual-switch; 



bridge-domains { 

c1-vlan-v1500 { 

vlan-id all; # Note the use of the VLAN id all statement 


307


} 

} 

} # End of customer-c1-v1500 

} # End of routing-instances 

Note the use of the vlan-id all and vlan-id-range statements in the virtual-switch 

instance called customer-c1-v1-to-v1000. The vlan-id all statement implicitly creates 

multiple learning domains, each with its own normalized VLAN. 

The following operations are performed when you use the vlan-id all configuration: 

• The logical interfaces are configured as a trunk port that multiplexes traffic from 

multiple VLANs and usually interconnects switches. 

• All the VLAN identifiers are associated with a Layer 2 trunk port. Each of the logical 

interfaces, ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, accepts packets tagged with any 

VLAN ID specified in the respective vlan-id-range statements. 

• The association of the received packet to a logical interface is done by matching the 

VLAN tags of the received packet with the VLAN tags configured on one of the logical 

interfaces on that physical port. The vlan-id all configuration within the bridge domain 

c1-vlan-v1-to-v1000 for customer-c1-virtual-switch sets the normalized VLAN value. 

For a logical interface with a single VLAN tag, a learning domain implicitly created 

for each normalized VLAN of the interface. 

• Bridge domain c1-vlan-v1-to-v1000 for customer-c1-virtual-switch has three logical 

interfaces: 

• Logical interface ge-1/0/0.1 configured on physical port ge-1/0/0. 

• Logical interface ge-2/0/0.1configured on physical port ge-2/0/0. 

• Logical interface ge-3/0/0.1configured on physical port ge-3/0/0. 

• Packets received on logical interfaces ge-1/0/0.11 or ge-6/0/0.11 with a single VLAN 

tag of 1500 in the frame are accepted. 

• Unknown source MAC addresses and unknown destination MAC addresses are 

learned based on their normalized VLAN values of 1 through 1000. 

• All packets sent on the VPLS pseudowire have a normalized VLAN tag after the 

source MAC address field in the encapsulated Ethernet packet. 

• Although there are only three logical interfaces in the VPLS instance called 

customer-c1-virtual-switch, the same MAC address (for example, M1) can be learned 

on different logical interfaces for different VLANs. For example, MAC address M1 

could be learned on logical interface ge-1/0/0.1 for VLAN 500 and also on logical 

interface ge-2/0/0.1 for VLAN 600. 

[MX Series Ethernet Services Routers SolutionsGuide] 

308 



Multicast 

• The listings for the following RFCs incorrectly state that 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 Policy and Firewall Filters 

• The conditions under which enhanced network services mode must be configured for 

use with firewall filters were documented incorrectly in the Firewall Filters and Enhanced 

Network Services Mode Overview topic. Use the following guidelines when configuring 

enhanced network services mode with firewall filters: 

• In configurations where interfaces are created either statically or dynamically and 

firewall filters are applied dynamically, you must configure the chassis network 

services to run in enhanced mode by including the network-services statement at 

the [edit chassis] hierarchy level. 

• In configurations where interfaces are created statically and firewall filters are applied 

statically, you must do both of the following: 

• Configure chassis network services to run in enhanced mode by including the 

network-services statement at the [edit chassis] hierarchy level, 

• Configure each firewall filter for enhanced mode by including the enhanced-mode 

statement at the [edit firewall filter filter-name], [edit firewall family family-name 

filter filter-name], [edit logical-system logical-system-name firewall filter filter-name], 

or [edit logical-system logical-system-name firewall family family-name filter 

filter-name] hierarchy level. 

• When you configure an IPv6 firewall filter, the next-header icmp6 and next-header 

icmpv6 match conditions perform the same function. next-header icmp6 is the preferred 

option. next-header icmpv6 is hidden in the Junos OS CLI. 

• The description of the filter-name option in the documentation for the filter and 

simple-filter configuration statements is incorrect. The correct description is: 

filter-name—Name that identifies the filter. This must be a non-reserved string of not 

more than 64 characters. No special characters are restricted. However, to include 

spaces in the name, enclose it in quotation marks (“ ”). 

[Firewall Filter and Policer Configuration Guide] 

• The description of the routing-instance-name option in the documentation for the 

routing-instances configuration statement is incorrect. The correct description is: 

routing-instance-name—Name of the routing instance. This must be a non-reserved 

string of not more than 128 characters. 


309


[Routing Protocols Configuration Guide] 

• In routing instances, when a BGP neighbor sends BGP messages to the local routing 

device, the incoming interface on which these messages are received must be configured 

in the same routing instance that the BGP neighbor configuration exists in. This is true 

for neighbors that are a single hop away or multiple hops away. 

[Routing Protocols] 


• The clear services l2tp session statistics and clear services l2tp tunnel statistics topics 

in the System Basics and Services Command Reference Guide for Junos OS Release 

10.4 through 11.4 erroneously state that these commands are supported on MX Series 

routers. This support will be added in a future release. 


• The rate statement for packet sampling is now configured at the [edit forwarding 

options sampling input family family] hierarchy level. 


• The documentation for the secured-port-block-allocation that appears at the [edit 

services nat pool poolname port secured-port-block-allocation] shows incorrect ranges 

of values for the block-size block-size and max-blocks-per-address max-blocks options. 

The correct range of values for block-size is 1 through 60,000; the correct range of 

values for max-blocks is 1 through 512. 

[Services Interface, Next-Generation Network Solutions] 

• The aes-128-cbc, aes-192-cbc, and aes-256-cb options that you can configure with the 

encryption-algorithm statement at the [edit services ipsec-vpn ipsec proposal 

proposal-name] hierarchy level are incorrectly specified as ase-128-cbc, ase-192-cbc, 

and ase-256-cb options in the following topics in the Security Services section of the 

System Basics Configuration Guide: 

• Security Services Configuration Statements 

• Configuring Minimum IKE Requirements for IPsec on an ES PIC 

• Configuring an IKE Proposal for Dynamic SAs 

• encryption-algorithm 

[System Basics, Security Services] 

• Certain changes to NAT (network address translation) PBA (port block allocation) 

configuration require a reboot of the services PIC in order for the changes order to take 

effect. A warning should be issued during the commit, informing you of the need to 

reboot. Because the warning is not currently being issued, the documentation should 

include the following warnings: 

• For secured port block allocation, you must reboot when you change block-size, 

port-range, add or delete prefixes, or modify the from hierarchy in the NAT rule. 

310 



• For deterministic PBA, you must reboot when you change block-size or 

max-blocks-per-address. 


• The Subscriber Access Configuration Guide fails to state that L2TP on MX Series routers 

is supported only on MX240, MX480, and MX960 routers. It is not supported on MX80 

routers. 


• The Configuring Per-Subscriber Session Accounting topic in the Subscriber Access 

Configuration Guide incorrectly states that the update-interval statement rounds up 

an interval of 10 through 15 minutes to 15. The actual behavior is that all configured 

values are rounded up to the next higher multiple of 10. For example, the values 811 

through 819 are all accepted by the CLI, but are all rounded up to 820. 


• The DHCP topics in the Junos OS Subscriber Access Configuration Guide for Junos OS 

release 11.4 neglect to describe port requirements for DHCP firewall filters. Accurate 

filtering of DHCP packets at the Routing Engine is different when the DHCP services 

are managed by the jdhcpd process (MX Series routers, M120 routers, and M320 routers) 

rather than the dhcpd and fud processes (other router series). For the MX Series routers, 

you must specify both port 67 (bootps) and port 68 (bootpc) for both the source port 

and destination port in the match conditions for the filter term that acts on packets 

from the DHCP server. 

In the following sample filter, the dhcp-server-accept term matches on UDP (DHCP) 

packets with a source port of 67 or 68 and a destination port of 67 or 68. 

firewall { 

family inet { 

filter RE-protect { 

term dhcp-client-accept { 

from { 

source-address { 

0.0.0.0/32; 

} 

destination-address { 

255.255.255.255/32; 

} 

protocol udp; 

source-port 68; 

destination-port 67; 

} 

then { 

count dhcp-client-accept; 

accept; 

} 

} 

term dhcp-server-accept { 

from { 

protocol udp; 

source-port [ 67 68 ]; 


311


destination-port [ 67 68 ]; 

} 

then { 

count dhcp-server-accept; 

accept; 

} 

} 

} 

} 

} 

• The Configuring an L2TP Tunnel Group for LNS Sessions with Inline Services Interfaces 

topic in the Subscriber Access Configuration Guide for Junos OS Release 11.4 incorrectly 

mentions support for the tunnel-timeout statement at the [edit services l2tp 

tunnel-group name] hierarchy level. This statement is not supported on MX Series 

routers. The syslog statement at the same hierarchy level is also not supported for MX 

Series routers. 


• The Junos OS Subscriber Management Scaling Values (XLS) spreadsheet for Release 

11.4 neglected to include the following note: 

To scale beyond 64,000 logical interfaces in an aggregated Ethernet configuration, 

you must have an RE-S-1800 and you must enable Enhanced IP Network Services 

mode on the router. To enable this mode, include the chassis network-services 

enhanced-ip statement at the [edit chassis] hierarchy level and reboot the router. When 

the router reboots, only MPCs and Multiservices DPCs come online. For more information 

about network services modes, see 

http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/network-services-mode-overview.html. 

• In the Software Feature Licenses topic of the Software Installation and Upgrade Guide, 

the Junos OS Feature Licenses table states that the L2TP Base license for L2TP scaling 

is not supported. In fact, the correct license is the LNS Feature Pack license and it does 

support L2TP LNS scaling. For details about L2TP scaling values, see the Junos OS 

Subscriber Management Scaling Values (XLS) spreadsheet from the Downloads box 

at http://www.juniper.net/techpubs/en_US/junosrelease-number/information-products 

/pathway-pages/subscriber-access/index.html. Substitute the number of the latest 

Junos OS release for the release-number. For example, ...en_us/junos11.4/.... 

• The PPP MIB overview topic in the SNMP MIBs and Traps Reference Guide fails to state 

that the PPP MIB is supported on the Common Edge PPP process, jpppd. SNMP support 

for PPP over PPPoE interfaces is active only if the jpppd process is enabled. 

The PPPoE MIB overview topic in the SNMP MIBs and Traps Reference Guide fails to 

state that the PPPoE MIB is supported on the Common Edge PPPoE process, jpppoed. 

SNMP support for PPPoE over Ethernet interfaces is active only if the jpppoed process 

is enabled. 

[SNMP MIBS and Traps Reference] 

• In the Junos OS Subscriber Access Configuration Guide, the Dedicated Queue Scaling 

for CoS Configurations on Trio MPC/MIC Interfaces Overview topic incorrectly describes 

the number of subscribers that can be supported per MPC port on a 60-Gigabit Ethernet 

Enhanced Queuing MPC. Because this MPC is limited to 16,000 subscribers per PIC, 

312 



you can accommodate a maximum of 16,000 subscribers per port whether you dedicate 

4 or 8 queues per subscriber. 

[Subscriber Access ] 

• The DHCP in Broadband Networks topic erroneously states that the Junos OS subscriber 

management solution currently supports only DHCP as a multiple-client configuration 

protocol. However, subscriber management solutions support DHCP and PPPoE as 

multiple-client configuration protocols. 

[Broadband Subscriber Management Solutions] 

• The Configuring Service Packet Counting topic in the Junos OS Subscriber Access 

Configuration Guide does not include the following configuration guideline. When you 

specify the service-accounting action for the term, you cannot additionally configure 

the count action in the same term. 


• The table titled Supported Juniper Networks VSAs in the Juniper Networks VSAs 

Supported by the AAA Service Framework topic lists RADIUS VSA 26-157 

(IPv6-NdRa-Pool-Name). This VSA is not supported and should not appear in the 

table. 


• The Configuring a Dynamic Profile for Client Access topic erroneously uses the 

$junos-underlying-interface variable when an 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 

• 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, Junos OS accepts invalid configurations. For example, if you specify 

a transmit rate that exceeds the allowed 100 percent, the system does not reject the 

configuration and returns unexpected shaping behavior. 


• Juniper Networks does not support multicast RIF mapping and ANCP when configured 

simultaneously on the same logical interface. For example, configuring a multicast 

VLAN and ANCP on the same logical interface is not supported, and the subscriber 

VLANs are the same for both ANCP and multicast. 


• The Guidelines for Configuring Dynamic CoS for Subscriber Access topic in the Subscriber 

Access Configuration Guide erroneously states that dynamic CoS is supported for 


313


dynamic VLANs on the Trio MPC/MIC family of products. In Junos OS Release 11.1, 

dynamic CoS is supported only on static VLANs on Trio MPC/MIC interfaces. 


• 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. 


• In the Subscriber Access Configuration Guide, the Juniper Networks VSAs Supported by 

the AAA Service Framework table and the RADIUS-Based Mirroring Attributes table 

incorrectly describe VSA 26-59. The correct description is as follows: 

Attribute Number 

Attribute Name 

Description 

26-59 

Med-Dev-Handle 

Identifier that associates mirrored traffic to a specific 

subscriber. 


• In the Subscriber Access Configuration Guide, the table titled "Supported Juniper 

Networks VSAs" in the "Juniper Networks VSAs Supported by the AAA Service 

Framework" topic lists RADIUS VSA 26-42 (Input-Gigapackets) and VSA 26-43 

(Output-Gigapackets). These two VSAs are not supported. 


• In the Junos OS Subscriber Access Configuration Guide, the "Qualifications for Change of 

Authorization" section in the topic titled “RADIUS-initiated Change of Authorization 

(CoA) Overview”, has been rewritten as follows to clarify how CoA uses the RADIUS 

attributes and VSAs. 

314 



Qualifications for Change of Authorization 

To complete the change of authorization for a user, you specify identification 

attributes and session attributes. The identification attributes identify the subscriber. 

Session attributes specify the operation (activation or deactivation) to perform on 

the subscriber’s session and also include any client attributes for the session (for 

example, QoS attributes). The AAA Service Framework handles the actual request. 

Table 12 on page 315 shows the identification attributes for CoA operations. 

NOTE: Using the Acct-Session-ID attribute to identify the subscriber 

session is more explicit than using the User-Name attribute. When you 

use the Acct-Session-ID, the attribute identifies the specific subscriber 

and session. When you use the User-Name as the identifier, the CoA 

operation is applied to the first session that was logged in with the 

specified username. However, because a subscriber might have multiple 

sessions associated with the same username, the first session might 

not be the correct session for the CoA operation. 

Table 12: Identification Attributes 

Attribute 

Description 

User-Name [RADIUS attribute 1] 

Subscriber username. 

Acct-Session-ID [RADIUS attribute 44] 

Specific subscriber and session. 

Table 13 on page 315 shows the session attributes for CoA operations. Any additional 

client attributes that you include depend on your particular session requirements. 

Table 13: Session Attributes 

Attribute 

Description 

Activate-Service [Juniper Networks VSA 26–65] 

Service to activate for the subscriber. 

Deactivate-Service [Juniper Networks VSA 

26–66] 

Service to deactivate for the subscriber. 


• The table on the MX5, MX10, MX40, and MX80 3D Universal Edge Router index page 

(http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products 

/pathway-pages/mx-series/mx5-mx10-mx40-mx80/index.html) is unclear regarding 

subscriber management support on the MX80 router. The MX80 router supports only 

those subscriber management features that were qualified on MX Series routers up 

through Junos OS Release 10.1. Features first available in Release 10.2 and later releases 

have not yet been qualified on the MX80 router. 



315


• In the Junos OS Subscriber Access Configuration Guide, the DHCPv6 Local Server Overview 

topic includes a note stating that the DHCPv6 local server does not support dynamic 

profiles or the local address-assignment pools feature. That note is incorrect—DHCPv6 

local server supports address-assignment pool starting in Junos OS Release 10.0, and 

supports dynamic profiles starting in Junos OS Release 10.1. 

[Subscriber Access 

• The show subscribers topic in the Junos OS System Basics and Services Command 

Reference omits the following information about using the address option for the show 

subscribers command. 

When you issue the show subscribers address command, you must specify the IPv4 or 

IPv6 address prefix without a netmask, as shown in the following example: 

user@host> show subscribers address 192.168.17.1 detail 

If you specify the IP address as a prefix with a netmask, as shown in the following 

example, the router displays a message that the IP address is invalid, and rejects the 

command. 

user@host> show subscribers address 192.168.17.1/32 detail 

Invalid argument: invalid ip_address 192.168.17.1/32 

[Junos OS System Basics and Services Command Reference] 

• The Example: HTTP Service Attached to a Static Interface topic in the Junos OS Subscriber 

Access Configuration Guide provides an incorrect example for configuring a service filter 

as a walled garden. The correct example is as follows: 

The following example uses a service filter as a walled garden by defining a rule named 

redirect, referencing the rule in a profile named http-redirect, configuring a service set 

named http-redirect that references the http-redirect captive portal content delivery 

profile, and attaching the http-redirect service set to static interface ge-1/0/1.0. 

[edit services] 

captive-portal-content-delivery { 

rule redirect { 

match-direction input; 

term t1 { 

from { 

destination-address { 

100.0.1.1/32; 

} 

} 

then { 

redirect http://www.google.com; 

} 

} 

} 

profile http-redirect { 

cpcd-rules redirect; 

} 

} 

service-set http-redirect { 

captive-portal-content-delivery-profile http-redirect; 

interface-service { 

service-interface ms-1/0/0; 

316 



} 

} 

[edit interfaces ge-1/0/1] 

unit 0 { 

family inet { 

service { 

input { 

service-set http-redirect service-filter walled; 

} 

output { 

service-set http-redirect; 

} 

} 

address 10.1.3.2/24; 

} 

} 


• The Junos OS Subscriber Management Scaling Values (XLS) spreadsheet erroneously 

states that the maximum number of PPPoE interfaces per MPC1 is 15,996. The correct 

value is 31,998. 

[Subscriber Management Scaling] 

• The documentation for the subscriber management domain mapping feature in the 

Subscriber Access Configuration Guide describes using the aaa-logical-system and 

target-logical-system statements to configure mapping to a non-default logical system. 

Subscriber management is supported in the default logical system only. Configuring 

a non-default logical system is a future extension of subscriber management and is 

not supported in current Junos OS releases. 


• 

The Dedicated Queue Scaling for CoS Configurations on Trio MPC/MIC Interfaces Overview 

topic in the Junos OS Subscriber Access Configuration Guide does not explain the queuing 

behavior on 30-Gigabit Ethernet Queuing MPCs with only one MIC. See Dedicated 

Queue Scaling for CoS Configurations on MIC and MPC Interfaces Overview for a more 

complete explanation of dedicated queue scaling. 


317



• The Junos OS Release 11.2 System Log Error Messages Reference Guide does not list 

the following new message that is now recorded in the system log, when the RSVP 

fails to reserve the requested bandwidth for a label-switched path (LSP): 

RPD_MPLS_REQ_BW_NOT_AVAILABLE 

System Log Message: RSVP failed to set up path with the requested bandwidth on 

LSP lsp-name 

Description: After a successful CSPF computation, network conditions changed and 

RSVP failed to set up path with the requested bandwidth and resulted in a path error. 

The LSP did not come up if it happened during initial LSP establishment. Otherwise, 

during an optimization or automatic bandwidth adjustment, the LSP continued to stay 

up on the old path and used the previous amount of bandwidth. 

Type: Event: This message reports an event, not an error 

Severity: warning 

Facility: LOG_DAEMON 

Action: This condition arises when the requested bandwidth is not available. No action 

required in general, but if the LSP does not get established at the first place, you may 

want to re-optimize the LSP, change the LSP bandwidth configuration, or add additional 

hardware to increase the available bandwidth. 

[System Log Error Messages Reference] 


• The show system statistics bridge command displays system statistics on MX Series 

routers. 

[System Basics Command Reference] 

• In the Configuring ECMP Next Hops for RSVP and LDP LSPs for Load Balancing and 

maximum-ecmp documents, the following note was omitted: 

NOTE: MX Series routers with one or more Modular Port Concentrator 

(MPC) cards and with Junos OS 11.4 or earlier installed, support the 

configuration of the maximum-ecmp statement with only 16 next hops. You 

should not configure the maximum-ecmp statement with 32 or 64 next 

hops. When you commit the configuration with 32 or 64 next hops, the 

following warning message appears: 

Error: Number of members in Unilist NH exceeds the maximum supported 16 

on Trio. 

[MPLS Configuration Guide] 

318 



VPNs 

• Junos OS Release 11.2 and earlier do not support point-to-multipoint LSPs with 

next-generation multicast VPNs on MX80 routers. 

[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] 

Changes to the Junos OS Documentation Set 

The following are the changes made to the Junos OS documentation set: 

• A new solutions guide, Junos OSNext-Generation Network Addressing CGN and IPv6 

Solutions, is now available at 

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/ 

solutions-guide-next-generation-network-addressing/ngna-solutions-guide.pdf. The 

guide provides consolidated and updated information about how to use Carrier-Grade 

NAT (CGN) and related IPv6 transition technologies, including Dual-Stack Lite (DS-Lite), 

6rd, and 6to4 Provider-Managed Tunnels (PMT). 

• The Junos OS DDoS Protection Configuration Guide is now available at the following 

URL: 

http://www.juniper.net/techpubs/en_US/junos11.2/information-products/pathway-pages/ 

config-guide-ddos/ddos-protection.html. 

• Stateless firewall filter and traffic policer documentation is no longer included in the 

Junos OS Policy Framework Configuration Guide. This material is now available in the 

Junos OS Firewall Filter and Policer Configuration Guide only. 

• Routing policy, traffic sampling, forwarding, and monitoring documentation is no longer 

included in the Junos OS Policy Framework Configuration Guide. This material is now 

available in the Junos OS Routing Policy Configuration Guide. 

• The material that was formerly covered in the Junos OS Policy Framework Configuration 

Guide Web pages is now available as three subject-based Web pages. You can locate 

the links to the new Web pages at the following URLs: 

• Routing Policy, Traffic Sampling, Forwarding, and Monitoring 

Configuration—http://www.juniper.net/techpubs/en_US/junos11.2/information-products 

/pathway-pages/config-guide-policy/config-guide-policy.html 

• Stateless Firewall Filter 


/pathway-pages/config-guide-firewall-filter/config-guide-firewall-filter.html 

• Traffic Policer 


/pathway-pages/config-guide-firewall-filter/config-guide-policer.html 


319


• The Junos OS Hierarchy and Standards Reference is now available as three subject-based 

Web pages. You can locate the links to the new Web pages for the guides at the 

following URLs: 

• Junos OS Configuration Statements and 

Commands—http://www.juniper.net/techpubs/en_US/junos11.1/information-products 

/pathway-pages/reference-hierarchy/junos-configuration-hierarchies.html 

• Junos OS Product and Feature 

Descriptions—http://www.juniper.net/techpubs/en_US/junos11.1/information-products 

/pathway-pages/reference-hierarchy/junos-product-features.html 

• Standards Supported by the Junos 

OS—http://www.juniper.net/techpubs/en_US/junos11.1/information-products/pathway-pages 

/reference-hierarchy/junos-supported-standards.html 

• In Junos OS Release 10.3R1 and later, PDF files are not available for individual HTML 

pages in the Junos OS documentation set. PDF files are available for the complete 

Junos OS Release 10.3 configuration guides at 

http://www.juniper.net/techpubs/software/junos/junos103/index.html. PDF files for the 

complete hardware guides are accessible at the following URLs: 

• For M Series routers: 

http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products 

/pathway-pages/m-series/ 

• For MX Series routers: 


/pathway-pages/mx-series/ 

• For T Series and TX Matrix routers: 


/pathway-pages/t-series/ 

In addition, individual HTML pages have a Print link in the upper left corner of the text 

area on the page. 

Related 

Documentation 


on page 73 






320 


Upgrade and Downgrade Instructions for Junos OS Release 11.4 for M Series, MX Series, and T Series Routers 

Upgrade and Downgrade Instructions for Junos OS Release 11.4 for M Series, MX Series, and T 

Series Routers 

This section discusses the following topics: 

• Basic Procedure for Upgrading to Release 11.4 on page 321 


• Upgrading a Router with Redundant Routing Engines on page 325 

• Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS 

Release 10.1 on page 325 

• Upgrading the Software for a Routing Matrix on page 327 

• Upgrading Using ISSU on page 328 

• Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and 

NSR on page 328 

• Downgrade from Release 11.4 on page 329 

Basic Procedure for Upgrading to Release 11.4 

In order to upgrade to Junos OS 10.0 or later, you must be running Junos OS 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 Junos OS, always use the jinstall package. Use other 

packages (such as the jbundle package) only when so instructed by a Juniper Networks 

support representative. For information about the contents of the jinstall package and 

details of the installation process, see the Junos OS Installation and Upgrade Guide. 

NOTE: With Junos OS Release 9.0 and later, the compact flash disk memory 

requirement for Junos OS 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. 


321


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 

Junos OS. 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 OS 

System Basics Configuration Guide. 

322 



The download and installation process for Junos OS Release 11.4 is different from earlier 

Junos OS releases. 

Perform the following steps to download and install Junos OS: 

1. Using a Web browser, navigate to the All Junos Platforms software download URL on 

the Juniper Networks web page: 

http://www.juniper.net/support/downloads/ 

2. Select the name of the Junos OS platform for the software that you want to download. 

3. Select the release number (the number of the software version that you want to 

download) from the Release drop-down list to the right of the Download Software 

page. 

4. Select the Software tab. 

5. In the Install Package section of the Software tab, select the software package for the 

release. 

6. Log in to the Juniper Networks authentication system using the username (generally 

your e-mail address) and password supplied by Juniper Networks representatives. 

7. Review and accept the End User License Agreement. 

8. Download the software to a local host. 

9. Copy the software to the routing platform or to your internal software distribution 

site. 

10. 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-11.4R71-domestic-signed.tgz 

All other customers use the following command: 

user@host> request system software add validate reboot 

source/jinstall-11.4R71-export-signed.tgz 

Replace source with one of the following values: 

• /pathname—For a software package that is installed from a local directory on the 

router. 

• For software packages that are downloaded and installed from a remote location: 

• ftp://hostname/pathname 

• http://hostname/pathname 

• scp://hostname/pathname (available only for Canada and U.S. version) 


323


The validate option validates the software package against the current configuration 

as a prerequisite to adding the software package to ensure that the router reboots 

successfully. This is the default behavior when the software package being added is 

a different release. 

Adding the reboot command reboots the router after the upgrade is validated and 

installed. When the reboot is complete, the router displays the login prompt. The 

loading process can take 5 to 10 minutes. 

Rebooting occurs only if the upgrade is successful. 

NOTE: After you install a Junos OS Release 11.4 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 OS Multiplay 

Solutions Guide. 








the currently installed EEOL release, or to two EEOL releases before or after the currently 

installed release. For example, Junos OS Releases 10.0, 10.4, and 11.4 are EEOL releases. 

You can upgrade from Junos OS Release 10.0 to Release 10.4 or even from Junos OS 

Release 10.0 to Release 11.4. However, you cannot upgrade or downgrade directly from 

a non-EEOL release that is more than three releases ahead or behind. For example, you 

cannot directly upgrade from Junos OS Release 10.3 (a non-EEOL release) to Junos OS 

Release 11.4 or directly downgrade from Junos OS Release 11.4 to Junos OS Release 10.3. 


before or after the currenlty installed release, first upgrade to the next EEOL release and 

then upgrade or downgrade from that EEOL release to your target release. 

For more information about EEOL releases and to review a list of EEOL releases, see 


324 



Upgrading a Router with Redundant Routing Engines 

If the router has two Routing Engines, perform a Junos OS installation on each Routing 

Engine separately to avoid disrupting network operation as follows: 

1. Disable graceful Routing Engine switchover (GRES) on the master Routing Engine 

and save the configuration change to both Routing Engines. 

2. Install the new Junos OS release on the backup Routing Engine while keeping the 

currently running software version on the master Routing Engine. 

3. After making sure that the new software version is running correctly on the backup 

Routing Engine, switch over to the backup Routing Engine to activate the new software. 

4. Install the new software on the original master Routing Engine that is now active as 

the backup Routing Engine. 

For the detailed procedure, see the Junos OS Installation and Upgrade Guide. 

Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos 

OS Release 10.1 

In releases prior to Junos OS 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 OS Release 10.1 and later, you can use the router’s 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 OS 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. 


325


Because Junos OS Release 10.1 supports using the router’s 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 OS Release 10.1 if you want to configure the routers’s main instance 

loopback address for draft-rosen multicast VPN: 

1. Upgrade all M7i and M10i routers to Junos OS Release 10.1 before you configure the 

loopback address for draft-rosen Multicast VPN. 

NOTE: Do not configure the new feature until all the M7i and M10i routers 

in the network have been upgraded to Junos OS Release 10.1. 

2. After you have upgraded all routers, configure each router’s 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] 


3. After you have configured the router’s 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 OS 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 OS 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 OS Multicast Configuration Guide. 

326 



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 OS 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 OS CLI by using the lcc option). To avoid network disruption during 

the upgrade, ensure the following conditions before beginning the upgrade process: 

• A minimum of free disk space and DRAM on each Routing Engine. The software upgrade 

will fail on any Routing Engine without the required amount of free disk space and 

DRAM. To determine the amount of disk space currently available on all Routing Engines 

of the routing matrix, use the CLI show system storage command. To determine the 

amount of DRAM currently available on all the Routing Engines in the routing matrix, 

use the CLI show chassis routing-engine command. 

• The master Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC) 

and T640 routers or T1600 routers (LCC) are all re0 or are all re1. 

• The backup Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC) 

and T640 routers or T1600 routers (LCC) are all re1 or are all re0. 

• All master Routing Engines in all routers run the same version of software. This is 

necessary for the routing matrix to operate. 

• All master and backup Routing Engines run the same version of software before 

beginning the upgrade procedure. Different versions of the Junos OS 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. 


327


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 OS 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 OS 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 OS releases with no disruption on the control plane and with minimal disruption 

of traffic. Unified in-service software upgrade is only supported by dual Routing Engine 

platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active 

routing (NSR) must be enabled. For additional information about using unified in-service 

software upgrade, see the Junos High Availability Configuration Guide. 

Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM 

and NSR 

Junos OS 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 OS 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 

328 



the standard reboot or ISSU procedures described in the other sections of these 

instructions. 

Because the nonstop-routing disable statement was not available in Junos OS Release 

9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to 

be upgraded from Junos OS 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 

OS and you have entered the nonstop-routing disable statement. If your router is running 

Junos OS Release 9.3 or later, you can upgrade to a later release without disabling NSR 

or PIM–simply use the standard reboot or ISSU procedures described in the other sections 

of these instructions. 

To disable and reenable PIM: 

1. On the router running Junos OS Release 9.2 or earlier, enter configuration mode and 

disable PIM: 

[edit] 

user@host# deactivate protocols pim 

user@host# commit 

2. Upgrade to Junos OS Release 9.3 or later software using the instructions appropriate 

for the router type. You can either use the standard procedure with reboot or use ISSU. 

3. After the router reboots and is running the upgraded Junos OS, 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 


Downgrade from Release 11.4 

To downgrade from Release 11.4 to another supported release, follow the procedure for 

upgrading, but replace the 11.4 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 OS Release 11.4, you can downgrade the 

software to Release 10.4 directly, but not to Release 10.3 or earlier; as a 

workaround, you can first downgrade to Release 10.4 and then downgrade 

to Release 10.3. 

For more information, see the Junos OS Installation and Upgrade Guide. 

Related 

Documentation 


on page 73 




329





330 


Junos OS Release Notes for Branch SRX Series Services Gateways and J Series Services Routers 

Junos OS Release Notes for Branch SRX Series Services Gateways and J Series Services 

Routers 

Powered by Junos OS, Juniper Networks Branch SRX Series Services Gateways provide 

robust networking and security services. Branch SRX Series Services Gateways are 

designed to secure enterprise infrastructure, data centers, and server farms. The Branch 

SRX Series Services Gateways include the SRX100, SRX210, SRX220, SRX240, and 

SRX650 devices. 

Juniper Networks J Series Services Routers running Junos OS 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 OS Release 11.4 for Branch SRX Series Services Gateways and 

J Series Services Routers on page 331 

• Changes in Default Behavior and Syntax in Junos OS Release 11.4 for Branch SRX Series 

Services Gateways and J Series Services Routers on page 350 

• Known Limitations in Junos OS Release 11.4 for Branch SRX Series Services Gateways 

and J Series Services Routers on page 357 

• Outstanding Issues in Junos OS Release 11.4R7 for Branch SRX Series Services Gateways 


• Resolved Issues in Junos OS Release 11.4 for Branch SRX Series Services Gateways 


• Errata and Changes in Documentation for Junos OS Release 11.4 for Branch SRX Series 


• Upgrade and Downgrade Instructions for Junos OS Release 11.4 for Branch SRX Series 


New Features in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series 

Services Routers 



NOTE: For the latest updates about support and issues on Junos Pulse, see 

the Junos Pulse Release Notes at 

http://www.juniper.net/techpubs/en_US/junos-pulse1.0/information-products/ 

pathway-pages/junos-pulse/index.html 

• Release 11.4R5 New Features on page 332 




331


• Software Features on page 338 

• Hardware Features—SRX210 Services Gateways on page 346 

• Hardware Features—SRX240 Services Gateway on page 347 

Release 11.4R5 New Features 

Network Address Translation (NAT) 

• Network Address Translation support for port mapping—This feature is supported 

on all branch SRX Series and J Series devices 

Network Address Translation (NAT) now provides destination-port low to high and 

mapped-port low to high statements to allow static NAT to map ports as follows: 

• To map multiple IP addresses to the same IP addresses on a specified range of ports 

• To map a specific IP address and port to a different IP address and port 

Examples of configuring static NAT with port mapping: 

set security nat static rule-set rs from zone trust rule r1 match destination-address 1.1.1.1/32 

set security nat static rule-set rs from zone trust rule r1 destination-port 100 to 200 

set security nat static rule-set rs from zone trust rule r1 then static-nat prefix 10.1.1.1/32 

set security nat static rule-set rs from zone trust rule r1 then static-nat prefix mapped-port 300 

to 400 





to 400 


set security nat static rule-set rs from zone trust rule r3 destination-port 300 



New IPSec Phase 2 Authentication Algorithm 

• Prior to Junos OS Release 11.2R6, 11.4R3, and 12.1R1, if you configure set security ipsec 

proposal authentication-algorithm hmac-sha-256-128 , HMAC calculation on 

Branch SRX devices 96-bit of ESP authentication data length was used instead of 

128-bit. In order to address interoperability issue between the Junos OS Release 11.4R3 

and 11.4R3 onwards, a new authentication-algorithm hmac-sha-256-96 (non-RFC 

compliant) is used in 11.4R5. 

Syntax: set security ipsec proposal authentication-algorithm 

hmac-sha-256-96 

user@host>set security ipsec proposal my-proposal authentication-algorithm ? 

Possible completions: 

hmac-md5-96 

HMAC-MD5-96 authentication algorithm 

hmac-sha-256-128 HMAC-SHA-256-128 authentication algorithm 

hmac-sha-256-96 HMAC-SHA-256-96 authentication algorithm (non-RFC 

compliant) 

hmac-sha1-96 

HMAC-SHA1-96 authentication algorithm 

check the authentication by running show security ipsec security-associations detail. 

user@host>show security ipsec security-associations index 1 detail 

332 


New Features in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series Services Routers 

D: 1 Virtual-system: root, VPN Name: my-tunnel 

Local Gateway: 10.10.10.1, Remote Gateway: 10.10.10.2 

Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) 

Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) 

Version: IKEv1 

DF-bit: clear 

Policy-name: my-policy 

Direction: inbound, SPI: 6ee39796, AUX-SPI: 0 

, VPN Monitoring: - 

Hard lifetime: Expires in 3175 seconds 

Lifesize Remaining: Unlimited 

Soft lifetime: Expires in 2551 seconds 

Mode: Tunnel(0 0), Type: dynamic, State: installed 

Protocol: ESP, Authentication: hmac-sha256-96, Encryption: aes-cbc (256 

bits) 

Anti-replay service: disabled 

Direction: outbound, SPI: 8ae3ae5e, AUX-SPI: 0 

, VPN Monitoring: - 

Hard lifetime: Expires in 3175 seconds 

Lifesize Remaining: Unlimited 

Soft lifetime: Expires in 2551 seconds 

Mode: Tunnel(0 0), Type: dynamic, State: installed 

Protocol: ESP, Authentication: hmac-sha256-96, Encryption: aes-cbc (256 

bits) 

Anti-replay service: disabled 

• Compatibility matrix of Phase 2 authentication method: VPN makes truncation 

method work as hmac-sha-256-128 on Junos OS Release 11.4R3. After the proposal is 

chosen in phase 2 negotiations, the SA uses 96 bit length truncation. So, if a remote 

gateway running Junos OS Release 11.4R3 and later releases which uses 

hmac-sha-256-128, the SRX device fails to decrypt from the gateway. In this case refer 

to the compatibility matrix table of each method and release given as follows: 

Table 14: Compatibility matrix of Phase 2 authentication method: 


Remote 

Prior to 11.4R3 

11.4R3 onwards 

Local 

Authentication 

Method 


VPN knob 

(hmac-sha-256-96) 


Prior to 

11.4R3 


Same method 

Compatible 

Not compatible 

11.4R3 

onwards 

VPN knob 

(hmac-sha-256-96) 

Compatible 

Same method 



Not Compatible 


Same method 

Control Plane and Data Plane Memory Adjustment 

Advanced security software memory usage is growing from release to release due to 

increased functionality. With Junos OS Release 11.4 you cannot load large policy on Branch 

SRX 1G devices (SRX100H, SRX110H, SRX210H/HE, SRX220H and SRX240H). 

When you load a large IDP policy, the device runs out of memory on the control plane, 

which triggers a system reboot or freeze. In order to address this issue, a new CLI command 


333


is introduced to re-distribute memory between control plane and data plane. This CLI 

command is referred to as Memory optionand will be available from 11.4R5 onwards. 

Syntax: set security advanced-services data-plane memory low 

This CLI command can be committed if one of the following Advanced Security License 

is installed on the device. 

• IDP Signature (idp-sig) 

• Kaspersky Anti Virus (av_key_kaspersky_engine) 

• Sophos Anti Virus (av_key_sophos_engine) 

The following error message is displayed during commit if the required licenses are not 

installed on the device. 

user@host>set security advanced-services data-plane memory low 

user@host>commit 

'low' 

Please reduce data plane memory, only when advanced services (UTM & IDP) 

licenses present 

error: configuration check-out failed 

NOTE: After commit complete you must reboot the system to take effect of 

the change. If you have deployed a cluster, make sure to reboot all nodes. If 

you rollback to the previous memory allocation by using delete security 

advanced-services data-plane memory low, you need to reboot the system 

after commit. 

user@host>commit 

warning: You have changed the system's data plane memory size. 

You must reboot the system for your change to take effect. 

If you have deployed a cluster, be sure to reboot all nodes. 

commit complete 

• To check the control or data plane memory allocation and memory status 

• The default memory allocation can be checked by running the show chassis 

routing-engine command. 

user @host>show chassis routing-engine | match memory 

Total memory 1024 MB Max 666 MB used ( 65 percent) 

Control plane memory 560 MB Max 448 MB used ( 80 percent) 

Data plane memory 464 MB Max 218 MB used ( 47 percent) 

• The current memory status can be checked by running the show security flow status 

command. The Advanced services data-plane memory mode: Default means the 

data-plane memory allocation remains unchanged. 

user @host>show security flow status 

Flow forwarding mode: 

Inet forwarding mode: flow based 

Inet6 forwarding mode: drop 

MPLS forwarding mode: drop 

ISO forwarding mode: drop 

334 



Advanced services data-plane memory mode: Default 

Flow trace status 

Flow tracing status: off 

• After you configure set security advanced-services data-plane memory lowand commit, 

the status is changed to Default (config changed, reboot needed). 







Advanced services data-plane memory mode: Default (config changed, reboot 

needed) 



• After system reboot (for example: request system reboot), the data-plane mode is 

changed to Low, and the additional control plane memory is allocated compared to 

default mode by reducing data-plane memory accordingly. 







Advanced services data-plane memory mode: Low 



user @host>show chassis routing-engine | match memory 

Total memory 1024 MB Max 625 MB used ( 61 percent) 

Control plane memory 624 MB Max 399 MB used ( 64 percent)



CX111 3G Adapter CLI Management 

• CX111 3G Adapter CLI Management—This feature is supported on SRX100, SRX210, 

SRX220, SRX240, and SRX650 devices. 

The CX111 3G adapter is primarily used as a backup for the WAN connection on SRX 

Series for the branch devices. The CX111 adapter is the only available 3G solution that 

has a built-in 3G LED signal indicator and that can be installed anywhere for optimal 

3G performance. The CX111 adapter acts as a transparent Layer 2 bridge to provide 

quick and simple 3G access. The 3G adapter integrates smoothly with an existing SRX 

Series for the branch device. The CX111 adapter maintains the wireless modem (or 

modems, if more than one modem is used) in a disconnected state, then triggers a 

new connection whenever an SRX Series device requests a new session. 

This feature enhances the management of the CX111 3G adapter to include the usage 

of the CLI. Users can now use CLI command to monitor the 3G modem and manage 

the CX111 adapter. 

To differentiate between multiple adapters connected to SRX Series devices, use the 

set services wireless-wan adapter command. The adapter's management IP address 

is used to communicate between SRX Series devices and the adapter. In Junos OS, 

the entire configuration for the adapter is used to maintain the adapter data. 

To manage the CX111 3G adapter, use the show wireless-wan adapter command. 

For CX111 adapter firmware upgrade, use the request wireless-wan adapter firmware 

upgrade command. 

For CX111 adapter firmware upgrade status, use the show wireless-wan adapter firmware 

upgrade command. 

Intrusion Detection and Prevention (IDP) 

• IDP policy compilation improvements—This feature is supported on all branch SRX 

Series devices with IDP enabled. 

The IDP policy compilation process has been optimized to use less memory and compile 

faster. Policies that were too large to compile on smaller platforms running earlier 

Junos OS releases may compile successfully on this release. 

J-Web 

• Application Tracking—This feature is supported on SRX100, SRX210, SRX220, SRX240, 

and SRX650 devices. 

The Application tracking feature is used to monitor sessions and bytes of a particular 

application or application group. The following page has been added to the J-Web 

user interface: 

• Application Tracking 

• Security Logging—This feature is supported on SRX100, SRX210, SRX220, SRX240, 


336 



The following page has been added to the J-Web user interface: 

• Security Logging 

IP Monitoring 

• IP Monitoring—This feature is supported on SRX100, SRX210, SRX220, SRX240, and 


Enhanced the IP Monitoring feature to support the following actions: 

• Specifying the no-preempt option. If the no-preempt option is specified, the policy 

does not perform preemptive failback when it is in a failover state or when the RPM 

probe test recovers from a failure. 

• Setting preferred metric values. If the preferred metric value is set, during failover, 

the route is injected with the set preferred metric value. 

• Enabling and disabling interfaces. 

• Interface-Enable – On a physical or logical interface, when the interface-enable 

action is configured, the initial state of the interface is disable after startup, and it 

continues to remain in the disable state as long as the associated RPM probe is 

in the pass state. When the associated RPM probe fails, the configured physical 

and logical interfaces are enabled. 

• Interface-Disable – On a physical or logical interface, when the interface-disable 

action is configured, the interface state remains unchanged. When the associated 

RPM probe fails, the physical and logical interfaces are disabled. 

MAC Limiting 

• MAC Limiting on Layer 3 Routing Interfaces—This feature is supported on SRX100, 

SRX210, SRX220, SRX240, and SRX650 devices. 

The MAC limiting feature provides a mechanism for limiting MAC addresses on devices 

that are connected to a Layer 3 routed Gigabit Ethernet (GE), Fast Ethernet (FE), or 

10 Gigabit Ethernet (XE) interface. With MAC filters, you can allow traffic with specific 

source MAC. Software-based MAC limiting is supported. MAC limiting is applicable 

only on interfaces with plain Ethernet or VLAN tagged encapsulation. 

Interfaces and Routing 

USB Enable/Disable Feature—This feature is supported on SRX100, SRX210, SRX220, 

SRX240, and SRX650 Services Gateways and on J Series Services Routers. 

This feature allows the administrator to disable all USB ports on the services gateway 

or services router to block users from connecting a USB mass storage device to the 

gateway or router. If a USB device is already mounted and connected, this feature 

unmounts and disables the device. Any transactions in progress on the USB device are 

aborted. 

Table 15 on page 338 lists the supported CLI commands: 


337


Table 15: CLI Commands and Description 

CLI Command 

Description 

show chassis usb storage 

Displays the current status of any USB mass storage device and whether 

they are enabled or disabled. 

set chassis usb storage disable 

Disables mass storage devices that are connected on the USB ports. 

delete chassis usb storage disable 

Enables the use of USB mass storage devices on USB ports. 

NOTE: 

• The USB ports on a services gateway or services router are functional by 

default. 

• Even if the USB ports are disabled, the USB LEDs still light up when the 

device is plugged in. 

• This feature is supported only in Junos OS and is not supported in the 

uboot/loader phase. 

• When Junos OS is booted from a USB storage device, this feature is 

unavailable. 

• If a USB port is disabled, the request system reboot media usb command is 

unsupported and will fail. 

• If the kernel is configured to boot from USB, the kernel will check if USB is 

disabled early in the boot process. If USB is disabled, the kernel will reboot. 

Software Features 

AppSecure 

• Applications Groups—This feature is supported on SRX100, SRX210, SRX220, SRX240, 


Application grouping is an enhancement to the AppSecure feature. It allows users to 

group applications in policies. 

Application grouping is mainly used to support: 

• Customer-defined and predefined application groups in the application identification 

module 

• Multiple applications or groups in the application groups 

• Application group support for application firewall (AppFW)—This feature is supported 

on SRX100, SRX210, SRX220, SRX240, and SRX650 devices. 

The SRX Series devices allow configuring application firewall policies based on 

individual applications. This new feature allows you to group applications and 

338 



application groups under a single name for simplified, consistent reuse when defining 

application firewall policies. 

[Junos OS Security Configuration Guide] 

• Application signature management and usability enhancements—This feature is 

supported on SRX100, SRX210, SRX220, SRX240, and SRX650 devices. 

Juniper Networks provides improvements in the usability and management of predefined 

application signatures available through the Junos OS application signature package 

subscription service. Previously, predefined application signature updates were 

downloaded to the Junos OS configuration file, resulting in an unnecessarily large file. 

To improve usability, application signature updates are now downloaded and installed 

in a separate application signature database on the SRX Series device. 

Using CLI commands, users can manage predefined and custom application signatures 

and application signature groups, as follows: 

• View detailed and summary information. 

• Copy, disable, and enable predefined application signatures for maximum flexibility 

in the use and reuse of predefined application signatures and custom application 

signatures. 

• Create custom signatures by copying a predefined signature and using it as a 

template. 

In addition, the CLI services application-identification commands provide more options 

for the display and configuration of custom application signatures and application 

signature groups 

[Junos OS Feature Support Reference for SRX Series and J Series Devices, Junos OS 

Security Configuration Guide] 

• Heuristic detection of encrypted P2P applications—This feature is supported on 

SRX100, SRX210, SRX220, SRX240, and SRX650 devices. 

Peer-to-peer applications such as Skype contain encrypted data packets. The SRX 

Series devices cannot identify the encrypted data packets with the current application 

signatures, which are based on regular expression patterns. Heuristics are used to 

improve the detection rate. Junos OS detects encrypted peer-to-peer traffic on TCP 

and UDP. 

If a session cannot be identified as known encrypted peer-to-peer traffic, you can 

assign it to a special application called junos:unspecified-encrypted. Application 

firewall can configure a policy on this application similar to other dynamic 

applications. 

The edit services application-identification command has a new option, 

enable-heuristics, which you use to enable detection of encrypted peer-to-peer 

applications. The enable-heuristics command is off by default. 

The show services application-identification counter command has two new per-SPU 

counters, Unspecified encrypted sessions and Encrypted P2P sessions. 

root>show services application-identification counter 

pic: 1/0 


339


Counter type 

Value 

Unspecified encrypted sessions 10 

Encrypted P2P sessions 5 

pic: 1/1 

... 

[Junos OS CLI Reference Guide, Junos OS Security Configuration Guide] 

• IPv6 application firewall support—This feature is supported on SRX100, SRX210, 

SRX220, SRX240, and SRX650 devices. Application firewall now supports IPv6 

addressing on these SRX Series Services Gateways. 

Application firewall was previously supported in the IPv4 environment. Beginning 

with Junos OS Release 11.4, it is also supported on IPv6. 

Juniper Networks devices provide additional security protection against known 

dynamic applications that can send traffic that might not be adequately controlled 

by standard network firewall policies. The application firewall functionality enforces 

polices based on the results of the application identification process. The application 

identification process identifies applications using pattern matching, protocol 

decoding, and heuristics. 

To implement application firewall support: 

• Network security policy–Modify the policy configuration to support the application 

firewall rule set within the existing configuration. 

• Application firewall rule set–Define an application firewall rule set to be referenced 

by the network security policy. 


• Nested application identification enhancement—This feature is supported on 


New application identification contexts have been added for more extensive nested 

application matching. Several new HTTP contexts have been added for application 

detection: 

• http-get-url-parsed-param-parsed 

• http-post-url-parsed-param-parsed 

• http-post-variable-parsed 

• http-header-user-agent 

• http-header-cookie 

For encrypted HTTP sessions, the new ssl-server-name context extracts the server 

name from an SSL SERVER HELLO message and an SSL CLIENT HELLO message 

if they exist. 

[Junos OS Security Configuration Guide ] 

• Onbox application tracking statistics—This feature is supported on SRX100, SRX210, 


340 



This feature adds application-level statistics to the AppSecure suite. Application 

statistics allow an administrator to access cumulative statistics as well as statistics 

accumulated over user-defined intervals. The administrator can clear the statistics 

and configure the interval values. 

Bytes and session count statistics are maintained. Because the statistics count 

occurs at AppTrack session close event time, the byte and session counts are not 

updated until the session closes. 

SRX Series devices support a history of 8 intervals that an administrator can use to 

display the application session and byte counts. 


Global Policy 

• Global policy —This feature is supported on SRX100, SRX210, SRX220, SRX240, and 


Unlike other security policies, global policies do not reference specific source and 

destination zones (from-zone and to-zone). Global policies allow you to regulate traffic 

with addresses and applications, regardless of their security zones. Global policies 

reference user-defined addresses or the predefined address “any.” These addresses 

can span multiple security zones. 


• Web authentication—This feature is supported on SRX100, SRX210, SRX220, SRX240, 

and SRX650 devices. Web authentication now supports IPv6 addresses. 

• Firewall Authentication—This feature is supported on SRX100, SRX210, SRX220, 

SRX240, and SRX650 devices. Firewall authentication now supports IPv6 addresses. 


• IDP content decompression on HTTP —This feature is supported on SRX100, SRX210, 


To avoid IDP detection evasion on the HTTP compressed content, an IDP submodule 

has been added that decompresses the protocol content. The signature pattern 

matching is performed on the decompressed content. The decompression feature is 

disabled by default. 


• IDP attack description—This feature is supported on SRX100, SRX210, SRX220, 

SRX240, and SRX650 for both J-Web and the CLI. 

The IDP attack description feature enables users to use the CLI to learn more about 

IDP attack objects. Currently, users view IDP attack objects in the 

/var/db/idpd/sec-download/SignatureUpdate.xml file, which makes it difficult for 

users to investigate and manage IDP attack objects. Users can quickly and easily 

administer IDP attack objects when the details are displayed through the CLI. 

You can use the show security idp attack description and the show security idp attack 

detail operational mode commands to display details about IDP attack objects. 


341


[Junos OS CLI Reference Guide] 

J-Web 

• Customer branding of firewall authentication webpage— This feature is supported 

on SRX100, SRX210, SRX220, SRX240,and SRX650 devices. 

Juniper Networks enables the administrator to replace the embedded Juniper Networks 

logo present on the firewall authentication webpage with a customer graphic. It also 

provides the ability to create a different logo for different logical systems. 

• IDP monitoring—This feature is supported on SRX100, SRX210, SRX220, SRX240, 

SRX650, and J Series devices. 

The following pages have been added to the J-Web user interface: 

• Attacks Monitoring page 

• Applications Monitoring page 

• IDP performance in J-Web—IDP performance in J-Web has been improved for SRX100, 

SRX210, SRX220, SRX240, SRX650, and all J Series devices. 

• J-Web for Layer 2 transparency—This feature is supported on SRX100, SRX210, 



• Configuring bridge domains 

• Configuring static MAC address to Layer 2 interfaces under bridge domains 

• Monitoring bridge domains 

• Configuring interface as family bridge 

• MAC learning and limiting global MAC learning count 

• Security flow bridge configurations 

• J-Web DVPN pages enhancement—This feature is supported on SRX100, SRX210, 


The following J-Web pages have been created for dynamic VPN (DVPN) configuration 

and converted to the EXTJS framework to enhance usability: 

• Dynamic VPN Global Settings 

• Dynamic VPN Client Edit 

For configuration, you can now configure IKE and IPsec autokey for DVPN through the 

Auto Tunnel > Phase I and Phase II pages. 

342 



Security 

• Enhanced Web Filtering—This feature is supported on SRX100, SRX110, SRX210, 


Enhanced Web Filtering with Websense is an integrated URL filtering solution. When 

you enable Enhanced Web Filtering on the device, the device intercepts HTTP and 

HTTPS requests and then sends the HTTP URL or the HTTPS destination IP to the 

Websense ThreatSeeker Cloud (TSC). The TSC categorizes the URL into one of over 

95 categories and also provides a site reputation. The TSC returns the URL category 

and the site reputation information to the device. The device then determines whether 

it can permit or block the request based on the information provided by the TSC. 

You can consider Enhanced Web Filtering as an alternative to the existing integrated 

URL filtering Surf Control Content Portal Authority (SC-CPA) solution on the SRX 

Series devices. J Series devices, however, support only the existing SC-CPA functionality. 

NOTE: You need to install a new license on the device to upgrade to the 

Enhanced Web Filtering solution. 


• GTP IE removal—This feature is supported on all branch SRX Series and J Series devices. 

The multiple versions of the Third-Generation Partnership Project (3GPP) create 

interoperability problems in the mobile network. Junos OS Release 11.4 supports removal 

of R7, R8, and R9 information elements (IEs) of the GTPv1 messages, which allows 

you to retain interoperability. 


• Security policies for self-traffic—This feature is supported on all branch SRX Series 

and J Series devices. 

Users can now configure security policies for the self-traffic (the host inbound traffic 

or the host outbound traffic) of the device. The user can further apply relevant services 

to the new self-traffic policy. 

The security policies for the self-traffic are configured under the new default security 

zone called junos-host zone. 

[Junos OS CLI Reference, Junos OS Security Configuration Guide] 

• Internet Key Exchange version 2 (IKEv2)—This feature is supported on all branch SRX 

Series devices. 

IKEv2 is the next-generation standard for secure key exchange between peer devices, 

defined in RFC 4306. IKEv2 is available in Junos OS Release 11.4 for securing IPsec 

traffic. The initial release does not support all the capabilities described in the RFCs. 

The advantages of using version 2 over version 1 are as follows; 

• Simplifies the existing IKEv1 

• Single RFC, including NAT-T, EAP, and remote address acquisition 


343


• Replaces the 8 initial exchanges with a single 4-message exchange 

• Reduces the latency for the IPsec SA setup and increases connection establishment 

speed 

• Increases robustness against DoS attack 

• Improves reliability through the use of sequence numbers, acknowledgements, and 

error correction 

• Offers forward compatibility 

• Provides simple cryptographic mechanisms 

IKEv2 includes support for: 

• Route-based VPN 

• Site-to-site VPN 

• Dead peer detection (liveness check) 

• Chassis cluster 

• Certificate-based authentication 

• Hardware offloading of the ModExp operations in a Diffie-Hellman (DH) exchange 

• IKE and child SA rekeying—In IKEv2, a child security association (SA) cannot exist 

without the underlying IKE SA. If a child SA is required, it will be rekeyed; however, if 

the child SAs are currently active, the corresponding IKE SA will be rekeyed. 

• Version 1 and version 2 


SNMP 

• Juniper Networks enterprise-specific License MIB—This feature is supported on 

SRX100, SRX210, SRX220, SRX240, SRX650, and J Series devices. It extends SNMP 

support for licensing information. 

The enterprise-specific License MIB: 

• Contains information about license features and the expiration details to reduce the 

burden involved in managing licenses. 

• Generates traps to alert users. For example, an alert is generated when a license 

expires or when the total number of users exceeds the maximum number specified 

in the license. 

• Provides access to license-related information through the SNMP get and get-next 

operations. 

344 



[Junos OS SNMP MIBs and Traps Reference, MIB Reference for Branch SRX Series Services 

Gateways.] 

UTM 

• UTM support in chassis cluster active/active configuration—This feature is supported 


Previously, only UTM support for the Packet Forwarding Engine in active/backup chassis 

cluster configurations existed. Also, both the Packet Forwarding Engine and the Routing 

Engine had to be active in the same node for UTM functionality to work. 

This feature introduces UTM support for active/active chassis cluster configurations 

where the Packet Forwarding Engine can be active on both the cluster nodes. With 

active/active chassis cluster support, Routing Engine and Packet Forwarding Engine 

can be active in different nodes. 

NOTE: Sophos AV is not supported as part of active/active chassis cluster 

implementation. 

UTM supports stateless (no state regarding UTM is synced between the cluster nodes) 

Packet Forwarding Engine active/active chassis cluster configurations. 

With Junos OS Release 11.4, the UTM functionality is supported in both active/active 

and active/backup chassis cluster configurations. 

UTM with chassis cluster supports the following failover types: 

• Manual failover 

• RG0 automatic failover 

• RG1+ automatic failover 

• Failover through flowd restart 

• Failover through reboot 

Chassis cluster support is enabled for the following UTM features: 

• Content filtering 

• URL (Web) filtering 

• Antispam 

• Express antivirus scanning 

• Full file-based antivirus scanning 


345


[Junos OS Security Configuration Guide, Junos OS Feature Support Reference for SRX 

Series and J Series Devices] 

Virtual Private LAN Service (VPLS) 

• Filtering and policing support (packet based)—This feature is supported on SRX100, 

SRX210, SRX220, SRX240, SRX650, and all J Series devices. 

This feature permits users to configure both firewall filters and policers for virtual 

private LAN service (VPLS). Firewall filters enable you to filter packets based on their 

components and perform an action on packets that match the filter. Policers enable 

you to limit the amount of traffic that passes into or out of an interface. 

This feature can be enabled by configuring VPLS filters, policers, and accounting through 

various CLI commands. VPLS filters and policers act on a Layer 2 frame that includes 

the media access control (MAC) header (after any VLAN rewrite or other rules are 

applied), but that does not include the cyclical redundancy check (CRC) field. 

NOTE: You can apply VPLS filters and policers on the PE routers, only to 

customer-facing (PE-CE) interfaces. 

[Junos OS MPLS Configuration Guide for Security Devices] 

Virtual Private Networks (VPN) 

• Site-to-site VPN support for NAT-T—This feature is supported on all branch SRX 

Series devices and J Series devices. 

Site-to-site IKE gateway configuration for Network Address Translation-Traversal 

(NAT-T) is now supported on the server side (IKE responder). This is in addition to the 

current implementation of NAT-T support for dynamic IKE gateway configuration. A 

remote-identity value is used to validate a peer’s ike-id or id during Phase 1 of IKE tunnel 

negotiation. 


Hardware Features—SRX210 Services Gateways 

AX411 Access Point 

• AX411 Access Point management is now supported on SRX100 and SRX110 Series 

devices in addition to existing support on SRX210, SRX220, SRX240, and SRX650 

devices. 

The AX411 Access Point provides network access for wireless clients such as laptop or 

desktop computers, personal digital assistants (PDAs), and any other device equipped 

with a Wi-Fi adapter. The AX411 Access Point supports the new IEEE 802.11n wireless 

networking standard with backward compatibility for IEEE 802.11a/b/g standards. 

You can manage and configure access points from the SRX Series device through the 

Junos operating system (Junos OS) command-line interface (CLI), J-Web interface, 

and Network and Security Manager (NSM). 

346 



3G ExpressCard Support on the SRX210 Services Gateway 

• Junos OS Release 11.4 supports the Sierra Wireless AirCard 503 (AC503) ExpressCard 

for GSM, HSPA, and UMTS networks on SRX210 devices, to provide wireless WAN 

connectivity as backup to primary WAN links. The AC503 ExpressCard is not available 

from Juniper Networks. 

3G USB Modem Support on the SRX210 Services Gateway 

• Junos OS Release 11.4 supports the Sierra Wireless USB modem (U319, HSPA+ 

quad-band) on the SRX210 device (on USB port 1). 

To use the 3G USB modem on the SRX210 device: 

1. Upgrade the BIOS software packaged inside the Junos OS image. For detailed 

information about BIOS upgrade procedures, see the Junos OS Initial Configuration 

Guide for Security Devices. 

NOTE: You need the BIOS version of 2.1 or later to use the 3G USB 

modems on the SRX210 device. 

2. Configure the WAN port using the CLI command set chassis routing-engine usb-wwan 

port 1 to enable the USB port to use the U319 USB modem. See the Junos OS CLI 

Reference Guide. 

3. Plug the 3G USB modem in to the appropriate USB slot (USB port 1) on the device. 

NOTE: You can use the USB modem with a standard USB extension 

cable of 1.8288 meters (6 ft) or longer. 

4. Reboot the device to start using the 3G USB modem. 

Hardware Features—SRX240 Services Gateway 

This topic includes the following sections: 

• Introduction on page 347 

• Hardware Features on page 348 

• SRX240 Services Gateway Models on page 349 

Introduction 

The Juniper Networks SRX240 Services Gateway offers complete functionality and 

flexibility for delivering secure, reliable data over IP, and provides multiple interfaces that 

support WAN and LAN connectivity and Power over Ethernet (PoE). 

The SRX240 Services Gateway provides IP Security (IPsec), virtual private network (VPN), 

and firewall services for small and medium-sized companies and enterprise branch and 


347


remote offices. Additional security features include Unified Threat Management (UTM), 

which consists of IPS antispam, antivirus, and Web filtering. 

Hardware Features 

Table 16 on page 348 lists the hardware features supported on various models of the 

SRX240 Services Gateway 

Table 16: SRX240 Services Gateway Hardware Features 

Features 

SRX240 Services 

Gateway with AC 

Power Supply and No 

PoE Support 



Power Supply and 

PoE Support 


Gateway with DC 

Power Supply 

DDR memory 

• For SRX240B: 

512 MB 

• For SRX240B2: 

1 GB 

• For SRX240H: 

1 GB 

• For SRX240H2: 

2 GB 

• For SRX240H-TAA: 

1 GB 

• For SRX240H-POE: 

1 GB 

• For SRX240H2-POE: 

2 GB 

• For 

SRX240H-POE-TAA: 

1 GB 

• For 

SRX240H2-POE-TAA: 

2 GB 

• For 

SRX240H-DC: 

1 GB 

• For 

SRX240H2-DC: 

2 GB 

• For SRX240H2-TAA: 

2 GB 

PoE support 

No 

Yes 

No 

Power supply 

rating 

150 watts 

360 watts 

190 watts 

Input voltage 

100 to 240 VAC 

100 to 240 VAC 

–48 VDC 

Operating range: 

–40.5 V to –72 V 

Gigabit Ethernet 

ports 

16 

16 

16 

Console ports 

1 

1 

1 

Universal Serial 

Bus (USB) ports 

2 

2 

2 

Mini-PIM slots 

4 

4 

4 

LEDs 

Status, Alarm, HA, Power, 

Mini-PIMs, and Port 

(TX/RX/Link and PoE) 

Status, Alarm, HA, 

Power, Mini-PIMs, and 

Port (TX/RX/Link and 

PoE) 

Status, Alarm, HA, 

Power, Mini-PIMs, 

Port (TX/RX/Link 

and PoE), DC power 

feed LEDs. 

NOTE: The PoE LED is enabled only on the PoE variant of the SRX240 Services Gateway. 

348 



Table 16: SRX240 Services Gateway Hardware Features (continued) 

Features 



Power Supply and No 

PoE Support 



Power Supply and 

PoE Support 


Gateway with DC 

Power Supply 

Internal flash 

memory 

• For SRX240B: 

1 GB 

• For SRX240B2: 

2 GB 

• For SRX240H: 

1 GB 

• For SRX240H2: 

2 GB 

• For SRX240H-TAA: 

1 GB 

• For SRX240H-POE: 

1 GB 

• For SRX240H2-POE: 

2 GB 

• For 

SRX240H-POE-TAA: 

1 GB 

• For 

SRX240H2-POE-TAA: 

2 GB 

• For 

SRX240H-DC: 

1 GB 

• For 

SRX240H2-DC: 

2 GB 

• For SRX240H2-TAA: 

2 GB 

Fans 

6 

6 

6 

Air filters 

One 

None 

One 

(Separately orderable) 

NEBS-compliance 

No 

No 

Yes 

NOTE: An air filter is not shipped with the SRX240 Services Gateway with 

AC power supply models. To meet NEBS requirements, you must order the 

air filter separately and install it. Contact your Juniper Networks customer 

service representative for more information. 

SRX240 Services Gateway Models 

Table 17 on page 349 lists the SRX240 Services Gateway models. 

Table 17: SRX240 Services Gateway Models 

Model Name 

Device Description 

SRX240B 

512 MB RAM, 1 GB flash memory with AC 

power supply 

SRX240B2 

1 GB RAM, 2 GB flash memory with AC power 

supply 

SRX240H 


supply 

SRX240H2 


supply 


349


Table 17: SRX240 Services Gateway Models (continued) 

Model Name 

Device Description 

SRX240H-TAA 


supply (TAA compliant) 

SRX240H2-TAA 


supply (TAA compliant) 

SRX240H-DC 

1 GB RAM, 1 GB flash memory with DC power 

supply 

SRX240H2-DC 

2 GB RAM, 2 GB flash memory with DC power 

supply 

SRX240H-POE 

1 GB RAM, 1 GB flash memory and Power 

over Ethernet (PoE) with AC power supply 

SRX240H2-POE 



SRX240H-POE-TAA 



(TAA compliant) 

SRX240H2-POE-TAA 



(TAA compliant) 

All models run Junos OS. 

Changes in Default Behavior and Syntax in Junos OS Release 11.4 for Branch SRX Series Services 

Gateways and J Series Services Routers 

The following current system behavior, configuration statement usage, and operational 

mode command usage might not yet be documented in the Junos OS documentation: 

350 


Changes in Default Behavior and Syntax in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series Services Routers 


• The client-match match-name option under security hierarchy edit security policies 

from-zone zone-name to-zone zone-name policy policy-name then permit 

firewall-authentication now supports a maximum of 64 users or user groups in the 

policy. 

AppSecure 

• On SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices, application 

tracking is enabled by default. You can disable application tracking with the set security 

application-tracking disable command. This command allows you to disable and 

reenable application tracking without modifying your existing zone selections. 


351


Command-Line Interface (CLI) 

• On all branch SRX Series devices, when the device is in low-memory condition and IDP 

is processing operations such as security package install or policy compilation, IDP 

aborts the operation. 

To disable this functionality, a new command, disable-low-memory-handling, has been 

introduced to continue IDP operations in low-memory condition. 

NOTE: The device might reboot suddenly if you enable the device to 

continue IDP operations in low-memory condition. 

• On all branch SRX Series devices, any device running Junos OS Release 11.4 and earlier 

and configured with SHA-256 authentication must be upgraded immediately. Earlier 

releases truncated the SHA-256 message digest to 96 bits from the correct size of 128 

bits. The hmac-sha-256-96 parameter fixes this compatibility issue. 

• On all branch SRX Series and J Series devices, the following commands are now 

supported: 

CLI Command 

Description 

show pppoe interfaces 

List all Point-to-Point Protocol over Ethernet 

(PPPoE) sessions. 

request pppoe connect 

Connect to all sessions that are down. 

request pppoe connect pppoe interface name 

Connect only to the specified session. 

request pppoe disconnect 

Disconnect all sessions that are up. 

request pppoe disconnect session id or pppoe 

interface name 

Disconnect only the specified session, identified 

by either a session ID or a PPPoE interface name. 

• In Junos OS Release 11.2 and 11.4 the set security zone security-zones tcp-rst 

command in the CLI Help displays an incorrect description as: 

tcp-rst—Send RST for TCP SYN packet not matching session 

The correct description is: 

tcp-rst—Send RST for NON-SYN packet not matching TCP session 

• On all branch SRX Series devices, in Junos OS Release 11.4 and earlier releases, if an 

invalid value of reboot_reason was detected, the show chassis routing-engine command 

would indicate a normal shutdown. Because of this, a flash memory corruption would 

go undetected. This issue is now fixed in Junos OS Release 12.1. The behavior is changed, 

and the reboot reason displays "Unknown reboot_reason", with the invalid value of 

reboot_reason, in hexadecimal format. 

352 



Deprecated Items for Branch SRX Series Services Gateways 

Table 18 on page 353 lists deprecated items (such as CLI statements, commands, options, 

and interfaces). 

CLI statements and commands are deprecated—rather than immediately removed—to 

provide backward compatibility and a chance to bring your configuration into compliance 

with the new configuration. We strongly recommend that you phase out deprecated 

items and replace them with supported alternatives. 

Table 18: Items Deprecated in Release 11.4 

Deprecated Item 

Replacement 

Hierarchy Level or 

Command Syntax 

Additional Information 

clear services flow 

- 

- 

On all branch SRX Series 

devices the clear services flow 

command is not supported. 

download-timeout 

- 

download-timeout timeout 

On all branch SRX Series 

devices, the 

download-timeout command 

is deprecated. If the 

configuration is present it will 

be ignored. The idpd daemon 

internally triggers 

security-package to install 

when an automatic download 

is completed. There is no 

need to configure any 

download-timeout. 


353


Flow and Processing 

• Max content-size-limit changes from 20MB to 15MB 

The maximum number of content size refers to the maximum size of the file that the 

system can buffer for scanning. Beyond that the system does either “block” or 

“log-and-permit” based on configuration (e.g., fallback-options content-size). As part 

of memory adjustment by the memory option, the maximum number of 

content-size-limit will be decreased from 20000 Kbytes to 15000 Kbytes after applying 

set security advanced-services data-plane memory low memory option. Therefore if 

you configured the content-size-limit as 15001 or above, this configuration statement 

will be removed along with all subsequent scan-options statement under 

“content-size-limit”. As a workaround, please re configure the content-size-limit as 

15000 or below prior to configuring the memory option. 

Before applying memory option, the maximum content-size-limit can be configured 

up to 20000 Kbytes 

user@host#set security utm feature-profile anti-virus kaspersky-lab-engine 

profile scan-options content-size-limit ? 


Content size limit (20..20000) 

user@host#set security utm feature-profile anti-virus sophos-engine profile 

scan-options content-size-limit ? 



show security utm 

feature-profile { 

anti-virus { 

kaspersky-lab-engine { 

profile 1 { 

scan-options { 

intelligent-prescreening; 

scan-mode all; 

scan-extension junos-default-extension; 

content-size-limit 20000;


Value 20000 is not within range (20..15000) 

mgd: commit complete 

After system rebooting, see the removed statements. 

edit 

user@host>show security utm 

feature-profile { 

anti-virus { 

kaspersky-lab-engine { 

profile 1 { 

scan-options { 

intelligent-prescreening; 

scan-mode all; 

scan-extension junos-default-extension; 

} 

} 

} 

} 

} 

The maximum content-size-limit can be configured up to 15000 Kbytes 

user@host#set security utm feature-profile anti-virus kaspersky-lab-engine 

profile scan-options content-size-limit ? 



user@host#set security utm feature-profile anti-virus sophos-engine profile 

scan-options content-size-limit ? 



• On all branch SRX Series and J Series devices, if the maximum number of leaves on a 

multicast distribution tree is exceeded, multicast sessions are created up to the 

maximum number of leaves, and any multicast sessions that exceed the maximum 

number of leaves are ignored. In previous releases, no multicast traffic was forwarded 

if the maximum number of leaves on the multicast distribution tree was exceeded. 

The maximum number of leaves on a multicast distribution tree is device specific. 

• On SRX100, SRX110, and SRX210 devices, when you power on or reboot the device, 

the Subscriber Identity Module (SIM) will be locked. If the SIM Personal Identification 

Number (PIN) or the unlock code is configured in the set interfaces cl-0/0/8 

cellular-options gsm-options sim-unlock-code configuration command, then Junos OS 

attempts to unlock the SIM only once. This is to keep the SIM from being blocked. If 

the SIM is blocked, you must provide a PIN Unblocking Key (PUK) obtained from the 

service provider. If the wrong SIM PIN is configured, the SIM will remain locked, and the 

administrator can unlock it by using the remaining two attempts. 

• The minimum value you can configure for TCP session initialization is 4 seconds. The 

default value is 20 seconds; if required you can set the TCP session initialization value 

to less than 20 seconds. 


355


• On all branch SRX Series devices, TCP session configuration has been enhanced. In 

earlier releases, the TCP session was only invalidated after 2 seconds of receiving a 

FIN or ACK packet. As a result, if there were new incoming SYN packets (with the same 

five tuples) within this 2 seconds, the packets would use the same TCP session, which 

would be terminated within 2 seconds. Therefore a new session could not be 

established. 

A new configuration attribute, fin-invalidate-session, has been introduced at the edit 

security flow tcp-session hierarchy level. This command invalidates a TCP session 

immediately on reception of a FIN or ACK packet. New incoming SYN packets will need 

to establish a new session. 

To end a session immediately on reception of a FIN or ACK packet, use the set security 

flow tcp-session fin-invalidate-session command. 


• On SRX240 and SRX650 devices, for the Layer 2 link aggregation group (LAG) interface, 

the hash algorithm for load balancing is now based on source IP address and destination 

IP address instead of source MAC address and destination MAC address. 

Internet Protocol Security (IPsec) 

• On Octeon-based branch SRX Series devices, for Path Maximum Transmission Unit 

(PMTU) calculations, the IPsec authentication data length is fixed at 16 bytes. However, 

the authentication data length for packets going through the IPsec tunnel is in 

accordance with the authentication algorithm negotiated for that tunnel. 

The authentication data lengths for the different algorithms are: 

• hmac-md5-96 (12 bytes) 

• hmac-sha-256-128 (16 bytes) 

• hmac-sha1-96 (12 bytes) 


• On all branch SRX Series devices, for a dynamic attack group using the direction filter, 

the expression AND should be used in the exclude values. As is the case with all filters, 

the default expression is OR. However, there is a choice of AND in the case of the 

direction filter. 

For example, if you want to choose all attacks with the direction client-to-server, 

configure the direction filter using the set security idp dynamic-attack-group dyn1 filters 

direction values client-to-server command. 

In the case of chain attacks, each of the multiple members has its own direction. If a 

policy includes chain attacks, a client-to-server filter selects all chain attacks that have 

any member with client-to-server as the direction. This means chain attacks that 

include members with server-to-client or ANY as the direction are selected if the chain 

has at least one member with client-to-server as the direction. 

356 


Known Limitations in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series Services Routers 

To prevent these chain attacks from being added to the policy, configure the dynamic 

group as follows: 

• set security idp dynamic-attack-group dyn1 filters direction expression and 

• set security idp dynamic-attack-group dyn1 filters direction values client-to-server 

• set security idp dynamic-attack-group dyn1 filters direction values 

exclude-server-to-client 

• set security idp dynamic-attack-group dyn1 filters direction values exclude-any 

J-Web 

• On all branch SRX Series devices, you can use J-Web to enable and disable logical 

interfaces. 


The following system log messages have been introduced in Junos OS Release 11.4R7. 

• When sensor-configuration disable-low-memory-handling is not set and IPD receives 

a low-memory signal, the following message appears: Processing low memory signal 

• When sensor-configuration disable-low-memory-handling is set and IPD receives a 

low-memory signal, the following message appears: Ignoring low memory signal 

Virtual Private Networks (VPNs) 

• On SRX650 devices, the perfect forward secrecy setting in an IPsec policy overrides 

the settings in proposal-sets in Junos OS Release 10.4 and later. 

Known Limitations in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J 

Series Services Routers 

AppSecure 

• J-Web pages for AppSecure are preliminary. 

• Custom application signatures and custom nested application signatures are not 

currently supported by J-Web. 

• AppFW does not operate on ALG data sessions. As a result, the AppFW rules are not 

applicable to these sessions. Therefore, ALG data sessions are excluded from AppFW 

counters. 

AX411 Access Points 

• On SRX210, SRX240, and SRX650 devices, you can configure and manage maximum 

of four access points. 

• On all branch SRX Series devices, managing AX411 WLAN Access Points through a 

Layer 3 aggregated Ethernet (ae) interface is not supported. 


357


Chassis Cluster 

• SRX100, SRX210, SRX220 SRX240, and SRX650 devices have the following chassis 

cluster limitations: 

• Virtual Router Redundancy Protocol (VRRP) is not supported. 

• Unified in-service software upgrade (ISSU) is not supported. 

• The 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 very-high-bit-rate digital subscriber line (VDSL) Mini-PIMs, chassis cluster is not 

supported for VDSL mode. 

• Queuing on the aggregated Ethernet (ae) interface is not supported. 

• Group VPN is not supported. 

• Sampling features such as flow monitoring, packet capture, and port mirror on the 

redundant Ethernet (reth) interfaces are not supported. 

• Switching is not supported in chassis cluster mode for SRX100 and SRX210. 

• The Chassis Cluster MIB is not supported. 

• Any packet-based services like MPLS and CLNS are not supported. 

• On lsq-0/0/0 interface, Link services Multilink Point-to-Point Protocol (MLPPP), 

Multilink Frame Relay (MLFR), and Compressed Real-Time Transport Protocol 

(CRTP) are not supported. 

• On lt-0/0/0 interface, CoS for real-time performance monitoring (RPM) is not 

supported. 

• Packet-based forwarding for MPLS and International Organization for Standardization 

(ISO) protocol families is not supported. 

• The factory default configuration for SRX100 devices automatically enables Layer 2 

Ethernet switching. Layer 2 Ethernet switching is not supported in chassis cluster mode 

for SRX100 devices. If you use the factory default configuration, you must delete the 

Ethernet switching before you enable chassis clustering. 

CAUTION: Enabling chassis clustering while Ethernet switching is enabled 

is not a supported configuration and 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 automatically enable Ethernet switching. However, if you have enabled Ethernet 

switching, be sure to disable it before enabling clustering on these devices too. 

• On all 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. 

358 



• On all branch SRX Series devices, redundant Ethernet (reth) interfaces and lo0 interface 

are supported for IKE external interface configuration in IPsec VPN. Other interface 

types can be configured, but IPsec VPN might not work. 

• On all J Series devices, the ISDN feature on chassis cluster is not supported. 

• On all branch SRX Series devices, frequent plug and play of USB keys is not supported. 

You must wait for the device node creation before removing the USB Key. 


• On all J Series devices, RADIUS accounting is not supported. 

• On SRX210 and SRX240 devices, J-Web crashes if more than nine users log in to the 

device by using the CLI. The number of users allowed to access the device is limited 

as follows: 

• For SRX210 devices: four CLI users and three J-Web users 

• For SRX240 devices: six CLI users and five J-Web users 

• On J6350 devices, there is a difference in the power ratings provided by user 

documentation (J Series Services Routers Hardware Guide and PIM, uPIM, and ePIM 

Power and Thermal Calculator) and the power ratings displayed by CLI (by a unit of 

1). The CLI display rounds off the value to a lower integer and the ratings provided in 

user documentation rounds off the value to the higher integer. As a workaround, follow 

the user documentation for accurate ratings. 

DOCSIS Mini-PIM 

• On SRX210 devices, the DOCSIS Mini-PIM delivers speeds up to a maximum of 100 

Mbps throughput in each direction. 

Dynamic Host Configuration Protocol (DHCP) 

• On all branch SRX and J Series devices DHCP is not supported in a chassis cluster. 

• On all branch SRX Series and J Series devices, DHCPv6 client authentication is not 

supported. 

Dynamic VPN 

SRX100, SRX210, and SRX240 devices have the following limitations: 

• The IKE configuration for the Junos Pulse client does not support the hexadecimal 

preshared key. 

• The Junos Pulse 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 Junos 

Pulse 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 Junos Pulse 


359


client with the force-upgrade option configured, the client upgrade occurs automatically 

(without a prompt). 

• On all branch SRX Series devices, DH-group 14 is not supported for dynamic VPN. 

• On all branch SRX Series devices, when you download pulse client through Mozilla 

browser, you get “Launching the VPN client” page when pulse is still downloading but 

when you download the pulse client through Internet Explore “Launching the VPN 

Client” page comes after pulse has been download and installed. 


• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, due to a limit on the 

number of large packet buffers, Routing Engine based sampling might run out of buffers 

for packet sizes greater than or equal to 1500 bytes and hence those packets will not 

be sampled. The Routing Engine could run out of buffers when the rate of the traffic 

stream is high. 

• On SRX100 and SRX240 devices, the data file transfer rate for more than 20 Mbps is 

reduced by 60 percent with the introduction of Junos Pulse 1.0 client as compared to 

the Acadia client that was used before Junos OS Release 11.1. 

• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the default authentication 

table capacity is 10,000; the administrator can increase the capacity to a maximum 

of 15,000. 

• On all branch SRX Series and J Series devices, when devices are operating in flow mode, 

the Routing Engine side cannot detect the path maximum transmission unit (PMTU) 

of an IPv6 multicast address (with a large size packet). 

• On all branch SRX Series devices, you cannot configure route policies and route patterns 

in the same dial plan. 

• On all branch SRX Series devices, you can configure no more than four members in a 

station group. Station groups are used for hunt groups and ring groups. 

• On all 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. 

• On all branch SRX Series and J Series devices, high CPU utilization triggered for reasons 

such as CPU intensive commands and SNMP walks causes the Bidirectional Forwarding 

Detection (BFD) protocol to flap while processing large BGP updates. 

• On SRX210, SRX240, and J Series devices, broadcast TFTP is not supported when flow 

is enabled on the device. 

• On SRX210, SRX240, and SRX650 devices, the maximum number of concurrent 

sessions for SSH, Telnet, and Web is as follows: 

Sessions 

SRX210 

SRX240 

SRX650 

SSH 

3 

5 

5 

360 



Sessions 

SRX210 

SRX240 

SRX650 

Telnet 

3 

5 

5 

Web 

3 

5 

5 

NOTE: These defaults are provided for performance reasons. 

• On SRX210 and SRX240 devices, for optimized efficiency, we recommend that you 

limit use of CLI and J-Web to the numbers of sessions listed in the following table: 

Device 

CLI 

J-Web 

Console 

SRX210 

3 

3 

1 

SRX240 

5 

5 

1 

• On SRX100 devices, Layer 3 control protocols (OSPF, using multicast destination MAC 

address) on the VLAN Layer 3 interface work only with access switch ports. 

• On all branch SRX Series and J Series devices, a mismatch between the Firewall Counter 

Packet and Byte Statistics values, and between the Interface Packet and Byte Statistics 

values, might occur when the rate of traffic increases above certain rates of traffic. 

• On all branch SRX Series devices, sessions going through GRE over IPsec are not marked 

as backup on backup node, instead, they are marked as active on backup node. This 

behavior causes the real active session to be deleted. Nesting tunnel, like GRE over 

IPsec, is not supported on chassis cluster. 

Group VPN Interoperability with Cisco’s GET VPN for Juniper Networks Security 

Devices that Support Group VPN 

Cisco’s implementation of the Group Domain of Interpretation (GDOI) is called Group 

Encryption Transport (GET) VPN. While group VPN in Junos OS 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. 

The group VPN in Release 12.1 of Junos OS 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 


361


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 security parameter indexes (SPIs). The Juniper Networks security device can recover 

from this situation by reregistering with the server and download the new key. 

Antireplay must be disabled on the Cisco server when a VPN group of more than two 

members includes a Juniper Networks security device. The Cisco server supports 

time-based antireplay by default. A Juniper Networks security device will not interoperate 

with a Cisco group member if time-based antireplay is used because 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 because 

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 needs to 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 to 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. 

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. 

362 



Hardware 

• On SRX650 devices, the T1/E1 GPIMs (2-port or 4-port version) do not work in Junos 

OS Release 9.6R1. This issue is resolved in Junos OS Release 9.6R2 and later releases, 

but if you roll back to the 9.6R1 image, this issue is still seen. 


• On all branch SRX Series devices, the subnet directed broadcast feature is not 

supported. 

• On SRX100, SRX110, SRX210, SRX220, SRX240, and SRX550 devices, Link Aggregation 

Control Protocol (LACP) is not supported on the 1-Port Gigabit Ethernet Small 

Form-Factor Pluggable (SFP) Mini-PIM. 

• On SRX100 and J Series devices, dynamic VLAN assignments and guest VLANs are 

not supported. 

• On SRX650 devices, Ethernet switching is not supported on Gigabit Ethernet interfaces 

(ge-0/0/0 through ge-0/0/3 ports). 

• On SRX210, SRX220, SRX240, and SRX650 devices, logs cannot be sent to NSM when 

logging is configured in the stream mode. Logs cannot be sent because the security 

log does not support configuration of the source IP address for the fxp0 interface and 

the security log destination in stream mode cannot be routed through the fxp0 interface. 

This implies that you cannot configure the security log server in the same subnet as 

the fxp0 interface and route the log server through the fxp0 interface. 

• On all branch SRX Series devices, the number of child interfaces per node is restricted 

to 4 on the redundant Ethernet (reth) interface and the number of child interfaces per 

reth interface is restricted to 8. 

• On SRX240 High Memory devices, traffic might stop between the SRX240 device and 

the Cisco switch due to link mode mismatch. We recommend setting same value to 

the autonegotiation parameters on both ends. 

• On SRX100 devices, the link goes down when you upgrade FPGA on 1xGE SFP. As a 

workaround, run the restart fpc command and restart the FPC. 

• On SRX210 devices with VDLS2, ATM COS VBR-related functionality cannot be tested. 

• On SRX210 devices, Internet Group Management Protocol version 2 (IGMPv2) JOINS 

messages are dropped on an integrated routing and bridging (IRB) interface. As a 

workaround, enable IGMP snooping to use IGMP over IRB interfaces. 

• On all J Series devices, the DS3 interface does not have an option to configure 

multilink-frame-relay-uni-nni (MFR). 

• On SRX210, SRX220, and SRX240 devices, every time the VDSL2 Mini-PIM is restarted 

in the asymmetric digital subscriber line (ADSL) mode, the first packet passing through 

the Mini-PIM is dropped. 

• 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. 


363


• On all J Series devices, Link Layer Discovery Protocol (LLDP) is not supported on routed 

ports. 

• 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 the ATM CoS rate must be configured to avoid congestion drops in 

segmentation and reassembly (SAR) as shown in following examples: 

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 

• On SRX210, SRX220, and SRX240 devices, 1-Port Gigabit Ethernet SFP Mini-PIM does 

not support switching. 

• On SRX650 devices, MAC pause frame and frame check sequence (FCS) error frame 

counters are not supported for the interfaces ge-0/0/0 through ge-0/0/3. 

• On SRX240 and SRX650 devices, the VLAN range from 3967 to 4094 falls under the 

reserved VLAN address range, and the user is not allowed any configured VLANs from 

this range. 

• On SRX650 devices, the last four ports of a 24-Gigabit Ethernet switch GPIM can be 

used either as RJ-45 or small form-factor pluggable transceiver (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 on and off 

intermittently. Similarly, when the RJ-45 medium is active and a SFP link is brought 

up, the interface will transition to the SFP medium, and this transition could also take 

a few seconds. 

• On SRX210 devices, the USB modem interface can handle bidirectional traffic of up 

to 19 Kbps. On oversubscription of this amount (that is, bidirectional traffic of 20 Kbps 

or above), keepalives do not get exchanged, and the interface goes down. 

• On SRX100, SRX210, SRX240, and SRX650 devices, on the Layer 3 aggregated Ethernet 

(ae) interface, the following features are not supported: 

• Encapsulations (such as CCC, VLAN CCC, VPLS, and PPPoE) 

• J-Web 

• 10-Gigabit Ethernet 

• On SRX100 devices, the multicast data traffic is not supported on IRB interfaces. 

• On SRX240 High Memory devices, when the system login deny-sources statement is 

used to restrict the access, it blocks a remote copy (rcp) between nodes, which is used 

to copy the configuration during the commit routine. Use a firewall filter on the lo0.0 

interface to restrict the Routing Engine access, However if you choose to use the system 

364 



login deny-sources statement, check the private addresses that were automatically 

on lo0.x and sp-0/0/0.x and exclude them from the denied list. 

• On SRX100, SRX210, SRX220, SRX240, SRX650, and all J Series devices, on 

VLAN-tagged routed interfaces, LLDP is not supported. 

Internet Key Exchange Version 2 (IKEv2) 

On all branch SRX Series devices, IKEv2 does not include support for: 

• Policy-based tunnels 

• Dial-up tunnels 

• Network Address Translation-Traversal (NAT-T) 

• VPN monitoring 

• Next-Hop Tunnel Binding (NHTB) for st0—Reusing the same tunnel interface for 

multiple tunnels 

• Extensible Authentication Protocol (EAP) 

• IPv6 

• Multiple child SAs for the same traffic selectors for each QoS value 

• Proposal enhancement features 

• Reuse of Diffie-Hellman (DH) exponentials 

• Configuration payloads 

• IP Payload Compression Protocol (IPComp) 

• Dynamic Endpoint (DEP) 


• On SRX100, SRX210, SRX220, SRX240 devices, configuration changes under [edit 

security utm] or [edit security alg] may trigger unnecessary IDP configuration check 

When any of the following security configuration statements are changed and 

committed, a child idpd process is invoked to check the change on active IDP policy. 

• edit security policies (regardless of idp enabled on a policy) 

• edit security idp 

• edit security address-book 

• edit security zone 

• edit security alg 

• edit security utm 

If the change has an impact on active IDP policy, IDP compiles IDP policy and push it 

to dataplane. If not, IDP only checks and does nothing. However, IDP may push compiled 

IDP policy to datapalne even if there is no change on active IDP policy. 


365


NOTE: "utm" and "alg" are not directly related to IDP configuration, but 

by default they have a relationship to a security zone internally. 

As a work around, In order to avoid IDP commit check for "utm" or "alg" 

configuration change, you can explicitly configure internal "junos-host" 

security zone (e.g., “set security zones security-zone junos-host” and 

“commit”), then the "junos-host" security zone will not be loaded from the 

default configuration file. This new security zone has been introduced in 

Junos OS Relesae 11.4R1 and defined in "jsrxsme-series-defaults.conf" file 

to manage host-inbound and host-outbound self traffic by using security 

policy. 

• On all branch SRX Series devices, from Junos OS Release 11.2 and later, the IDP security 

package is based on the Berkeley database. Hence, when the Junos OS image is 

upgraded from Junos OS Release 11.1 or earlier to Junos OS 11.2 or later, a migration of 

IDP security package files needs to be performed. This is done automatically on upgrade 

when the IDP daemon comes up. Similarly, when the image is downgraded, a migration 

(secDb install) is automatically performed when the IDP daemon comes up, and 

previously installed database files are deleted. 

However, migration is dependent on the XML files for the installed database present 

on the device. For first-time installation, completely updated XML files are required. If 

the last update on the device was an incremental update, migration might fail. In such 

a case, you have to manually download and install the IDP security package using the 

download or install CLI command before using the IDP configuration with predefined 

attacks or groups. 

As a workaround, use the following CLI commands to manually download the individual 

components of the security package from the Juniper Security Engineering portal and 

install the full update: 

• request security idp security-package download full-update 

• request security idp security-package install 

• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the request services 

application-identification uninstall command will uninstall all predefined signatures. 

• On all branch SRX Series devices, IDP does not allow header checks for nonpacket 

contexts. 

• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the maximum supported 

number of entries in the ASC table is 100,000 entries. Because the user land buffer 

has a fixed size of 1 MB as a limitation, the table displays a maximum of 38,837 cache 

entries. 

• On SRX650 device, the maximum number of IDP sessions supported is 16,384 on 

SRX210 devices, 32,768 on SRX240 devices, and 131,072. 

• On all branch SRX Series devices, IDP deployed in both active/active and active/passive 

chassis clusters has the following limitations: 

366 



• 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. 

• 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. 

• On all branch SRX Series devices, IDP deployed in active/active chassis clusters has 

a limitation that for time-binding scope source traffic, if attacks from a source (with 

more than one destination) have active sessions distributed across nodes, then 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. 

NOTE: On SRX100 devices, IDP chassis cluster is supported in 

active/backup mode. 

• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the IDP policies for each 

user logical system are compiled together and stored on the data plane memory. To 

estimate adequate data plane memory for a configuration, consider these two factors: 

• IDP policies applied to each user logical system are considered unique instances 

because the ID and zones for each user logical system are different. Estimates need 

to take into account the combined memory requirements for all user logical systems. 

• As the application database increases, compiled policies will require more memory. 

Memory usage should be kept below the available data plane memory to 

accommodate increase in database size. 

IPv6 IPsec 

The IPv6 IPsec implementation has the following limitations: 

• IPv6 routers do not perform fragmentation. IPv6 hosts should either perform path 

maximum transmission unit (PMTU) discovery or send packets smaller than the IPv6 

minimum MTU size of 1280 bytes. 

• Because IPv6 addresses are 128 bits long compared to IPv4 addresses, which are 

32-bits long, IPv6 IPsec packet processing requires more resources. Therefore, a small 

performance degradation is observed. 

• IPv6 uses more memory to set up the IPsec tunnel. Therefore, the IPsec IPv4 tunnel 

scalability numbers might drop. 

• The addition of IPv6 capability might cause a drop in the IPsec IPv4-in-IPv4 tunnel 

throughput performance. 

• The IPv6 IPsec VPN does not support the following functions: 


367


• 4in6 and 6in4 policy-based site-to-site VPN, IKE 

• 4in6 and 6in4 route-based site-to-site VPN, IKE 

• 4in6 and 6in4 policy-based site-to-site VPN, Manual Key 

• 4in6 and 6in4 route-based site-to-site VPN, Manual Key 

• 4in4, 6in6, 4in6, and 6in4 policy-based dial-up VPN, IKE 

• 4in4, 6in6, 4in6, and 6in4 policy-based dial-up VPN, Manual Key 

• Remote Access—XAuth, config mode, and shared IKE identity with mandatory XAuth 

• IKE authentication—public key infrastructure/digital signature algorithm (PKI/DSA) 

• IKE peer type—Dynamic IP 

• Chassis cluster for basic VPN features 

• IKE authentication—PKI/RSA 



• Hub-and-spoke VPNs 

• Next Hop Tunnel Binding Table (NHTB) 

• Dead Peer Detection (DPD) 

• Simple Network Management Protocol (SNMP) for IPsec VPN MIBs 

• Chassis cluster for advanced VPN features 

• IPv6 link-local address 

IPv6 Support 

• NSM—Consult the Network and Security Manager (NSM) release notes for version 

compatibility, required schema updates, platform limitations, and other specific details 

regarding NSM support for IPv6 addressing on SRX Series and J Series devices. 

• Tunnel traffic—IPv6 advanced flow does not support the following tunnel types: 

• IPv4 IPIP 

• IPv4 GRE 

• IPv4 IPsec 

• Dual-stack lite 

J-Web 

• J-Web browser support for Dell PowerConnect and SRX Series devices—To access 

J-Web for all platforms, your device requires the following supported browsers and 

OS: 

368 



• Browser: Microsoft Internet Explorer version 7.0, and Mozilla Firefox version above 

3.0 and below 3.5. 

NOTE: Other browser versions might not provide access to J-Web and 

only English-version browsers are supported. 

• OS: Microsoft Windows XP Service Pack 3 

• SRX Series and J Series browser compatibility 

• To access the J-Web interface, your management device requires the following 

software: 

• Supported browsers—Microsoft Internet Explorer version 7.0 or Mozilla Firefox 

version (3.0 or later) 

• Language support—English-version browsers 

• Supported OS—Microsoft Windows XP Service Pack 3 

• If the device is running the worldwide version of the Junos OS and you are using the 

Microsoft Internet Explorer Web browser, you must disable the Use SSL 3.0 option 

in the Web browser to access the device. 

• To use the Chassis View, a recent version of Adobe Flash that supports ActionScript 

and AJAX (Version 9) must be installed. Also note that the Chassis View is displayed 

by default on the Dashboard page. You can enable or disable it using options in the 

Dashboard Preference dialog box, but clearing cookies in Internet Explorer also 

causes the Chassis View to be displayed. 

• On all branch SRX Series devices, in the J-Web interface, there is no support for changing 

the T1 interface to an E1 interface or vice versa. As a workaround, use the CLI to convert 

from T1 to E1 and vice versa. 

• On all branch 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. 

• On SRX210 devices, there is no maximum length when the user commits the hostname 

in CLI mode; however, only 58 characters, maximum, are displayed in the J-Web System 

Identification panel. 

• On all 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. 


369


• On all branch SRX Series devices, you cannot use J-Web to configure a VLAN interface 

for an IKE gateway. VLAN interfaces are not currently supported for use as IKE external 

interfaces. 

• On all branch SRX Series devices, in the J-Web Configure > Security > Address Book 

interface, a maximum of only 26 global address book entries are displayed even if the 

entry list is more than 26. 

Layer 2 Transparent Mode 

• DHCP server propagation is not supported in Layer 2 transparent mode. 


• Maximum capacities for source pools and IP addresses have been extended on SRX650 

devices, as follows: 

Devices 

Source NAT 

Pools 

PAT 

Maximum 

Address 

Capacity 

Pat Port Number 

Source NAT 

rules number 

SRX650 

1024 

1024 

64M 

1024 

Increasing the capacity of source NAT pools consumes memory needed for port 

allocation. When source NAT pool and IP address limits are reached, port ranges should 

be reassigned. That is, the number of ports for each IP address should be decreased 

when the number of IP addresses and source NAT pools is increased. This ensures NAT 

does not consume too much memory. Use the port-range statement in configuration 

mode in the CLI to assign a new port range or the pool-default-port-range statement 

to override the specified default. 

Configuring port overloading should also be done carefully when source NAT pools 

are increased. 

For source pool with port address translation (PAT) in range (64,510 through 65,533), 

two ports are allocated at one time for RTP/RTCP applications, such as SIP, H.323, 

and RTSP. In these scenarios, each IP address supports PAT, occupying 2048 ports 

(64,512 through 65,535) for Application Layer Gateway (ALG) module use. 

• NAT rule capacity change—To 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 19 on page 371. The limitation on the number of destination-rule-set and 

static-rule-set has been increased. 

Table 19 on page 371 provides the requirements per device to increase the configuration 

limitation as well as to scale the capacity for each device. 

370 



Table 19: Number of Rules on SRX Series and J Series Devices 

NAT Rule Type 

SRX100 

SRX210 

SRX240 

SRX650 

J Series 

Source NAT rule 

512 

512 

1024 

1024 

512 

Destination NAT 

rule 

512 

512 

1024 

1024 

512 

Static NAT rule 

512 

512 

1024 

6144 

512 

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. 

Power over Ethernet (PoE) 

• On SRX210-PoE devices, SDK packages might not work. 

Security Policies 

• 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 all branch SRX Series and J Series devices, the limitation on the number of addresses 

in an address-set has been increased. The number of addresses in an address-set now 

depends on the device and is equal to the number of addresses supported by the policy. 

Table 20: Number of Addresses in an address-set on SRX Series and J 

Series Devices 

Device 

address-set 

Default 

1024 

SRX100 High Memory 

1024 

SRX100 Low Memory 

512 


1024 


512 


1024 


512 

SRX650 

1024 

J Series 

1024 


371


SNMP 

• On all J Series devices, the SNMP NAT related MIB is not supported. 

Stream Control Transmission Protocol (SCTP) 

• SCTP is not supported on IPv6. It is supported only on IPv4. 

Switching 

• Layer 2 transparent mode support—On SRX100, SRX110, SRX210, SRX220, SRX240, 

and SRX650 devices, the following features are not supported for Layer 2 transparent 

mode: 

• Gateway-Address Resolution Protocol (G-ARP) on the Layer 2 interface 

• Spanning Tree Protocol (STP) 

• IP address monitoring on any interface 

• Transit traffic through integrated routing and bridging (IRB) 

• On SRX100, SRX110, SRX210, SRX240, and SRX650 devices, change of authorization 

is not supported with 802.1x. 

• On SRX100, SRX110, SRX210, SRX240, and SRX650 devices, on the routed VLAN 

interface, the following features are not supported: 

• ISIS (family ISO) 

• Class of service 

• Encapsulations (Ether circuit cross-connect [CCC], VLAN CCC, VPLS, PPPoE, and 

so on) on VLAN interfaces 

• Connectionless network Service (CLNS) 

• Distance Vector Multicast Routing Protocol (DVMRP) 

• Gateway-Address Resolution Protocol (G-ARP)) 

• Change VLAN-Id for VLAN interface 

Upgrade and Downgrade 

• On all J Series devices, the Junos OS upgrade might fail due to insufficient disk space 

if the CompactFlash is smaller than 1 GB in size. We recommend using a 1GB compact 

flash for Junos OS Release 10.0 and later. 

• On SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices, when you connect 

a client running Junos Pulse 1.0 to an SRX Series device that is a running a later version 

of Junos Pulse, the client will not be upgraded automatically to the later version. You 

must uninstall Junos Pulse 1.0 from the client and then download the later version of 

Junos Pulse from the SRX Series device. 

372 




• On SRX100, SRX110, SRX210, SRX240, and SRX650 devices, while configuring dynamic 

VPN using the Junos Pulse client, when you select the authentication-algorithm as 

sha-256 in the IKE proposal, the IPsec session might not get established. 

Unsupported CLI for Branch SRX Series Services Gateways and J Series Services 

Routers 

Accounting-Options Hierarchy 

• On SRX100, SRX110, SRX210, SRX220, SRX240, SRX650, and all J Series devices, the 

accounting, source-class, and destination-class statements in the [accounting-options] 

hierarchy level are not supported. 

Chassis Hierarchy 

• On SRX100, SRX210, SRX220, 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 

Class-of-Service Hierarchy 

• On SRX100, SRX210, SRX220, SRX240, SRX650, and 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 


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, SRX220, SRX240 SRX650, and all J Series devices, the following 

Firewall hierarchy CLI commands are not supported. However, if you enter these 


373



message. 

set firewall family vpls filter 

set firewall family mpls dialer-filter d1 term 

Interfaces CLI Hierarchy 

On SRX100, SRX210, SRX220, 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 374 

• ATM Interface CLI on page 374 

• Ethernet Interfaces on page 375 

• GRE Interface CLI on page 375 

• IP Interface CLI on page 375 

• LSQ Interface CLI on page 376 

• PT Interface CLI on page 376 

• T1 Interface CLI on page 376 

• VLAN Interface CLI on page 377 

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 

374 



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 

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 

IP Interface CLI 



set interfaces ip-0/0/0 unit 0 layer2-policer 

set interfaces ip-0/0/0 unit 0 ppp-options 


375


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 



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 

376 



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, SRX220, SRX240, and SRX650 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 

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 


routing hierarchy CLI commands are not supported. However, if you enter these 


message. 

set routing-instances < instance_name > services 

set routing-instances < instance_name > multicast-snooping-options 

set routing-instances < instance_name > protocols amt 

set routing-options bmp 

set routing-options flow 

Services Hierarchy 


services hierarchy CLI commands are not supported. However, if you enter these 


message. 

set services service-interface-pools 


377


SNMP Hierarchy 


SNMP hierarchy CLI commands are not supported. However, if you enter these 


message. 

set snmp community < community_name > logical-system 

set snmp logical-system-trap-filter 

set snmp trap-options logical-system 

set snmp trap-group d1 logical-system 

System Hierarchy 

• On all SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the following system 

hierarchy CLI commands are not supported. However, if you enter these commands 


set system diag-port-authentication 

Related 

Documentation 





Outstanding Issues in Junos OS Release 11.4R7 for Branch SRX Series Services Gateways and 

J Series Services Routers 

The following problems currently exist in Juniper Networks branch SRX Series Services 

Gateways and J Series Services Routers. The identifier following the description is the 

tracking number in the Juniper Networks Problem Report (PR) tracking system. 

NOTE: For the latest, most complete information about outstanding and 

resolved issues with the Junos OS software, see the Juniper Networks online 

software defect search application at http://www.juniper.net/prsearch. 


• When you upgrade an SRX Series device to Junos OS Release 11.4, NSM shows an error 

that a space in the full-name parameter of the set system login user test-name full-name 

test name command statement is not accepted. [PR806750] 


• When a hardware timestamp is enabled, RPM probes go over the network control 

queue instead of the configured forwarding class. [PR487948] 

• Reduced flow and packet performance, and a drop in gre and gre_ipsec are observed. 

[PR682501] 

378 


Outstanding Issues in Junos OS Release 11.4R7 for Branch SRX Series Services Gateways and J Series Services Routers 

• The collector-bound exported data record might show random source port or 

destination port numbers. [PR853567] 

• Customer edge (CE)-to-CE Connectionless Network Service (CLNS) ping does not 

work even when the routing table lists the destination as the IS-IS (family iso) route. 

[PR859735] 


• Updates to firmware from version 6.02.00.12 to 7.03.01.00 on asymmetric digital 

subscriber line (ADSL) Mini-PIM and on Operation, Administration, and Management 

(OAM) do not function correctly. The Asynchronous Transfer Mode OAM feature is not 

supported. [PR835677] 

• When there is high CPU utilization, Link Aggregation Control Protocol (LACP) might 

flap and consequently aggregated Ethernet (ae) interface link might sometimes go 

down. [PR860129] 

J-Web 

• In J-Web, an incorrect confirmation message is displayed for the download and install 

application on the package in Appsecure Settings configuration page. [PR728992] 

• The Global options > Proxy screen is blank for the first time when you access it using 

Internet Explorer version 7.0. [PR737675] 

• The Layer 2 Transparent Mode feature does not work with the group configuration. 

[PR815225] 

• In J-Web, custom-defined applications are presented as predefined. [PR837820] 

• In J-Web, when you configure using the CLI or J-Web, you cannot to see the value of 

POL0. [PR839749] 

• In J-Web, when you add or delete the Junos-self zone and check the configuration 

using the CLI, you cannot delete the policy. [PR839950] 


• A security policy with antivirus shows incorrect count of bytes and packets the in policy 

statistics. [PR841923] 

Related 

Documentation 








379


Resolved Issues in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series 

Services Routers 

The following are the issues that have been resolved since Junos OS Release 11.4 for 

Juniper Networks branch SRX Series Services Gateways and J Series Services Routers. 

The identifier following the description is the tracking number in the Juniper Networks 

Problem Report (PR) tracking system. 




Resolved Issues in Junos OS Release 11.4R7 for Branch SRX Series Services 

Gateways 


• On devices in a chassis cluster, the child link of the link aggregation group (LAG) 

redundant Ethernet (reth) interface flapped frequently which caused memory corruption 

on the next hop pointer and caused the Routing Engine to generate a vmcore file. 


• On devices in a chassis cluster, the timeout value within which the request system 

snapshot media internal slice alternate command was expected to complete was 

increased from 10 minutes to 15 minutes. [PR822975: This issue has been resolved.] 

• On devices in a chassis cluster, when you accessed J-Web using Internet Explorer the 

following message was displayed: 

Configuring chassis cluster in non-cluster mode is not allowed 

PR825952: [This issue has been resolved.] 


• When you executed the request system zeroize the rescue command, the configuration 

was not deleted. As a result, the rescue configuration was loaded instead of the factory 

default configuration. [PR835687: This issue has been resolved.] 


• When you attempted to create a dial backup interface, * and # symbols were not 

accepted. [PR834042: This issue has been resolved.] 


• A new filter was added in dynamic attack groups in the CLI. The two flags under filters 

are recommended (which means true) and not-recommended (which means false). 

Only the recommended=true flag was supported. [PR828494: This issue has been 

resolved.] 

380 


Resolved Issues in Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series Services Routers 

• On J Series devices, IDP initialization failed and the policy did not load. As a result, IDP 

inspection did not work. [PR833071: This issue has been resolved.] 

J-Web 

• Sometime the firewall policy wizard did not run. [PR816393: This issue has been 

resolved.] 

• The dashboard refresh rate changed. Refresh rates of 15, 30, and 60 seconds were 

removed. The minimum refresh rate available was 2 minutes. [PR826053: This issue 


• In J-Web, the session expired when the idle-timeout value was set too low. [PR830644: 


Virtual Private Network (VPN) 

• IKE SA failed to install the responder during Phase 2 rekey. [PR809219: This issue has 



Gateways 

Application Layer Gateways (ALGs) 

• On all branch SRX Series devices, when the TNS RESEND (type 11) was 8 bytes long, 

the SQL ALG did not work properly. [PR806893: This issue has been resolved.] 


• On SRX240 High Memory devices, the services ip-monitoring CLI command was not 

working. [PR771344: This issue has been resolved.] 


• On SRX240 High Memory devices, when the DHCP client was configured with VLAN, 

the DHCP leases were not acquired by the client and unicast messages were dropped. 



• On branch SRX Series devices, the httpd task was high. [PR768952: This issue has 


• On SRX650 devices, the nas-ip-address might not be set correctly using the system 

radius-options attributes nas-ip-address command followed by a commit. [PR786467: 


• On SRX220 PoE devices, the smtp-profile junos-as-defaults command was not loaded. 


• On SRX240 devices, when the ingress and egress interfaces are located on different 

nodes of a chassis cluster (or are active, in the case of redundant Ethernet interfaces), 

filter-based forwarding (FBF) might not work correctly. [PR793057: This issue has been 

resolved.] 


381


• On SRX210 High Memory devices, flowd core files are generated during the IDP 

security-package update. [PR793417: This issue has been resolved.] 

• On all branch SRX Series devices, when multicast sessions were closed, an 

RT_FLOW_SESSION_CLOSE entry were not entered into the syslog file. [PR804569: 


• On all branch SRX Series devices, generation of a flowd core file was triggered by cache 

errors. [PR805975: This issue has been resolved.] 

• On SRX650 devices, routing engine failover occurred due to possible out-of-sync 

information about already allocated SNMP interface index values, and duplicate SNMP 

interface index values might be allocated. As a result, the mib2d process might crash 

or the SNMP interface index value of zero might be allocated for newly created 


• On all branch SRX Series devices, while upgrading cluster nodes and RG1 failover, one 

reth member was struck in STP learn state, and the link remains in a hard down state 

and do not recover. [PR811002: This issue has been resolved.] 

• On all branch SRX Series devices, the MSRPC ALG dropped some big packets under 

the Kerberos authentication environment, because the Kerberos ticket token size and 

the MS-RPC bind packet were too large for ALG to handle. [PR817453: This issue has 


• On SRX210 and SRX240 devices, reboot due to a kernel issue occurred. [PR818905: 


• On all branch SRX Series devices, after upgrading to Junos OS Release 11.4R5, if OSPF 

was enabled for any of the st0 interfaces, an internal processing error prevented the 

default route from being advertised out. [PR822352: This issue has been resolved.] 

• On all branch SRX Series devices, there used to be a requirement for the support of 

both “STARTTLS” and “X-ANONYMOUSTLS” cases for the SMTP parser. [PR824027: 


• On all branch SRX Series devices, erroneous messages were printed from liblicense 

during commit. [PR826158: This issue has been resolved.] 

382 




• On all branch SRX Series devices, A new filter was added in dynamic attack groups in 

the CLI. The two flags under filters are recommended (which means true) and 

no-recommended (which means false). Only the recommended=true flag was supported. 



• On SRX210 devices, there was an unexpectedly lower bandwidth through a scheduler 

queue that was configured with a small buffer size on an interface faster than 2 Mbps. 


J-Web 

• On SRX210 devices, the error “Failed to connect to server” was displayed when multiple 

clients were connected to the device through dynamic VPN and when some 

configurations related to IKE negotiation changed on the device. [PR737787: This issue 


• On all branch SRX Series devices, the Help page was not available for the Configure 

>Interface> Ports page. [PR792544: This issue has been resolved]. 

• On SRX650 devices, you were unable to view the application set in J-Web if you had 

added it using the CLI. [PR804176: This issue has been resolved.] 

• On SRX110 devices, the J-Web security logging tab was not working. [PR806442: This 


• On SRX240 High Memory devices, the httpd task was high. [PR809061: This issue has 


• On all branch SRX Series devices, in J-Web, the dashboard refresh rate changed. Refresh 

rates of 15, 30, and 60 seconds were removed. The minimum refresh rate available 

was 2 minutes. [PR826053: This issue has been resolved.] 

Logging 

• On SRX650 devices, destination port information was missing for IPv6 packets when 

the firewall was in packet mode. [PR805986: This issue has been resolved.] 

Aug 9 19:39:17 SRX100-1 SRX100-1 PFE_FW_SYSLOG_IP6_TCP_UDP: FW: fe-0/0/3.0 

A tcp SA 2002:0:0:0:0:0:1414:1402 DA 2002:0:0:0:0:0:1414:1401 sport:58962 dport: 






383


SNMP MIBs 

• On all branch SRX Series devices in a chassis cluster, long pauses and timeout were 

seen during SNMP walk or query of the device. A delay occurred in the kernel’s query 

of the gr-0/0/0 (GRE) interface. [PR800735: This issue has been resolved.] 

Unified Threat Management (UTM) 

• On SRX220 High Memory devices, the help and system logs on the terminal did not 

match. [PR794743: This issue has been resolved.] 


• On all branch SRX Series devices, the IPsec Phase 2 negotiation failed when you used 

authentication-algorithm hmac-sha-256-128 command. [PR793760: This issue has 


• On SRX650 devices, when you used hmac-sha-256-128 at the group VPN server for 

the IPsec authentication-algorithm, a gkmd core file was generated for the group VPN 

member. [PR800719: This issue has been resolved.] 


Gateways 


• On SRX240 devices, the Web authentication page was not displayed properly when 

you tried to reauthenticate after an idle time [PR741973: This issue has been resolved.] 

• On SRX220 devices, when the local or radius user password contained a percent 

character (%), firewall authentication through the Web portal failed due to an issue 

in processing the percent sign. [PR778891: This issue has been resolved.] 


• On all branch SRX Series and J Series devices, the set chassis usb storage disable 

command did not work. [PR793844: This issue has been resolved.] 


• On SRX devices, when the syn-cookie feature was enabled along with the syn-flood 

screen with a low timeout value, high-latency TCP sessions failed to establish 

successfully. The client sessions received unresponsive connections because the SRX 

Series device timed out the flow for the session. The device also dropped subsequent 

packets from the client due to the state not being found [PR692484: This issue has 


• On all branch SRX Series devices, the commands after STARTTLS were encrypted 

and could not be understood by the SMTP parser. These commands caused the session 

to hang until the TCP session was closed and no packets were forwarded. [PR750047: 


384 



• On SRX220 devices, when the device sent a broadcast ARP to a Layer 3 VLAN interface 

that was restarting, it caused the forwarding to restart, resulting in traffic loss and 

generation of a flowd_octeon_hm core file. [PR755204: This issue has been resolved.] 

• On SRX650 devices in a chassis cluster, the forwarding module became unresponsive 

when the redundant Ethernet (reth) interface was deleted while traffic was flowing 

through the device. Sometimes flowd generated a core file. [PR771273: This issue has 


• On SRX650 devices, the dot1x:mode:Multiple:Supplicants are authenticated even after 

sending the disconnect message from the radius server. [PR786731: This issue has been 

resolved.] 

• On SRX240 devices, when the DHCP client was configured on a routing instance in 

JSRP setup, after failover, device remained in secondary hold indefinitely. [PR790872: 


• On SRX210 High Memory devices, the flowd core files were generated during the IDP 

security-package update. [PR793417: This issue has been resolved.] 


• On SRX210 devices, changes made to the VPI and VCI values of ADSL interfaces did 

not take effect until the chassis was rebooted. [PR783992: This issue has been resolved.] 

• On SRX210HE devices, after reboot, sometimes the VLAN interface was down while 

its physical interface member was up. [PR791610: This issue has been resolved.] 

• On SRX240H devices, after reboot, sometimes the interface VLAN was down when 

the member physical interface was up. [PR795363: This issue has been resolved.] 


• On all branch SRX Series devices, IDP had the listed issues: 

• The detector was not updated in the control plane when the 

update-attack-database-only flag was used during security package installation. 

• IDP memory leak during IDP policy load, which causes ukernel heap fragmentation 

issue. 


• On SRX210 High Memory devices, during IDP policy compile, the failure message “idp 

policy parser compile failed” was displayed due to a memory leak in the application 

identification configuration load. [PR787970: This issue has been resolved.] 

• On SRX240 High Memory devices, IDP policy load failed though there was sufficient 

memory (heap) available. This issue occurred when there was not enough contiguous 

memory block available in kernel heap memory. [PR789146: This issue has been 

resolved.] 


385


• On SRX240 High Memory devices, when you changed the configuration, the show 

security idp policy-commit-status command showed the message “Failed to add 

connection for dataplane”. [PR789542: This issue has been resolved.] 

• On SRX210 High Memory devices, when the device was in low-memory condition on 

the control plane, it rebooted suddenly during the IDP security-package update. 


J-Web 

• On SRX210 devices, Junos OS failed to import node configurations when chassis cluster 

setup was configured using J-Web. [PR753533: This issue has been resolved.] 

• On all branch SRX Series devices, using J-Web, when you clicked Enable Log on the 

Monitor > Security > IDP > Attacks page, the page was disabled and not accessible. 


• On SRX210 HE, BE, and HE-PoE devices, logging in to J-Web resulted in the following 

error message: “JWEB is not supported on this platform”. [PR781659: This issue has 


• On all branch SRX Series devices in J-Web, when the device was in cluster mode after 

RG failover the primary node was displayed as a secondary hold in the Dashboard > 

System-identification > Cluster details. This was due to an RPC get data error. 


• On all branch SRX devices, the default radio buttons did not work after you configured 

the Configure > Security > UTM > Web Filtering > Add profile > Fallback options. 



• On SRX240 devices, Static NAT rules were not being enforced when Ethernet switching 

family was used. [PR785106: This issue has been resolved.] 

Unified Threat Management (UTM) 

• On SRX240 High Memory devices, The SMTP session was suspended, and the AV 

counters showed incorrect increments when a 20-MB file was transferred. [PR792518: 


• On SRX240 High Memory devices, UTM mbuf leaks were observed after several hours 

of traffic load. [PR795681: This issue has been resolved.] 


• On SRX650 devices, when there were many IKE SAs, the SNMP MIB 

“jnxIpSecFlowMonPhaseOne” returned only the first IKE SA. [PR734797: This issue has 


• On SRX650 devices, IKE Phase 1 and Phase 2 logs erroneously reported that the 

renegotiation retry limit had been reached, even though the VPN build succeeded. 


386 



• On All branch SRX Series devices, When using IPsec VPN, the “IKE Phase-2 Failure: IKE 

Phase-2 negotiation retry limit reached?” message was logged even though no failure 

had actually occurred. [PR768466: This issue has been resolved.] 

• On all branch SRX devices, when using SIP on a dynamic VPN client, the voice stream 

did not reach the client. [PR776883: This issue has been resolved.] 

• On SRX210 High Memory devices, the IPsec Phase 2 negotiation failed when you used 

authentication-algorithm hmac-sha-256-128. [PR793760: This issue has been resolved.] 


Gateways 

Application Layer Gateway (ALG) 

• On J2350 devices, the ALG module did not initialize properly due to a last-minute 

regression, preventing protocols such as FTP, RTSP, SIP, and RPC from working properly. 

This caused traffic drop and affected all the ALG related features. [PR749366: This 


• On all branch SRC Series devices, multiple TFTP requests with same source Ip and 

port may fail because only one gate will be opened. [PR750834: This issue has been 

resolved.] 

• On SRX240 devices, the EPRT command did not work with FTP ALGs on port 0, which 

were not valid. [PR769444: This issue has been resolved.] 

• On SRX240 devices, during ALG traffic processing, the device generated a core file. 



• On SRX210 devices, the show interface at extensive command did not display the 

correct value when the at interface was up on the SHDSL Mini-PIM. [PR738322: This 



• On SRX210 and SRX240 devices, when the devices acted as DHCP servers and the 

DHCP requests were forwarded to the SRX Series devices by a DHCP relay, the devices 

sent responses to DHCP requests to an incorrect UDP destination port. [PR774541: This 



• On SRX240 devices, Changes to CoS drop-profiles don't get applied with commit. 


• On SRX240, and SRX650 devices, when the device processed a large amount of traffic, 

performing an AppID security package update caused the flowd process to generate 

a core file. [PR769832: This issue has been resolved. ] 

• On SRX650 devices in a chassis cluster,the forwarding module became unresponsive 

when the redundant Ethernet (reth) interface was deleted while traffic was flowing 


387


through the device. Sometimes flowd generated a core file. [PR771273: This issue has 


• On SRX100, SRX210, SRX240, and SRX650 devices, for IKEv2, when the device 

attempted a dpd exchange during an existing exchange, a core file was generated. 

[PR771234 : This issue has been resolved.] 

• On SRX240 devices, when passing GVPN multicast traffic, flowd core files were 

generated when the GVPN packet was encapsulated in the PIM register message. 


J-Web 

• On J Series devices, the EZ-Setup (J-Web Initialization setup) failed with the following 

error: “Fetching setup configuration....Please wait”. [PR748173: This issue has been 

resolved.] 

• On SRX210 HE, BE, and HE-PoE devices, logging in to J-Web resulted in the following 

error message: “JWEB is not supported on this platform”. [PR781659: This issue has 


Interface and routing 

• On SRX240, and SRX650 devices in a chassis cluster, the Track IP (ipmon) feature 

was not working for VLAN tagged redundant Ethernet interfaces. [PR575754: This issue 


• On J2320 devices, when you used ISDN connections, an error appeared stating that a 

BAD_PAGE_FAULT had occurred and the ISDN connection had stopped working. 


• On SRX240 devices, the routing protocol daemon (rpd) generated a core file while 

processing a malformed RIP or RIP message from a neighbor during adjacency 

establishment. [PR772601: This issue has been resolved.] 


• On all branch SRX and J Series devices, the Commit of static NAT rules might fail when 

you committed interfaces, security zone, and NAT at same time in the root or logical 

system. In addition, the commit of static NAT rules might fail when you committed for 

security zone and NAT at the same time. [PR756240: This issue has been resolved.] 


Gateways 


• On SRX240 devices, In certain circumstances, memory objects used by H323 ALG does 

not release properly once its is used. It is fixed by enforcing the releasing logic when 

memory object is not needed. [PR746367: This issue has been resolved.] 

• On J2350 devices, the ALG module did not initialize properly due to a last-minute 

regression, preventing protocols such as FTP, RTSP, SIP, and RPC from working properly. 

388 



This caused traffic drop and affected all the ALG related features. [PR749366: This 



• On all branch SRX Series devices, the chassis cluster setup, primary node does not 

show security resource details on Dashboard page due to which the following message 

log is generated: "Security Resources:error: invalid value: firewall-policies". [PR720435: 


• On SRX210, SRX220, and SRX240 devices, the system crashed while changing the 

MTU of the redundant Ethernet interface. [PR720927: This issue has been resolved.] 

• On SRX650 devices, upgrade validation fails on SRX Clusters when using 'validate' 

option when attempting to upgrade from 10.3 or earlier versions to 10.4 or higher version. 


DHCP 

• On SRX220 devices, Only the first three options present in the Options Request of a 

DHCPv6 Solicit/Request will be correctly populated from the dhcp-attributes specified 

within a local inet6 pool. [PR741823: This issue has been resolved.] 

• On SRX210 devices, after adding or deleting some vlan configurations, if an interface 

is made a member of vlan 1 and that interface also serves as a DHCP server, it is 

sometimes observed that the interface fails to respond to incoming DHCP requests. 


Flow and processing 

• On SRX100 devices, when there is no static route configured in the routing-option, the 

inline-jflow v9 OutputInt and Src/DstMask information are displayed incorrectly. 


• On J4350, SRX550, and SRX650 devices, when the peers are connected directly 

through the t1 link and the ge link, pinging to the peer link local address of the t1 link 

interface does not go through the t1 link, but through the ge link instead. [PR684159: 


• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, activating and 

deactivating logical interfaces a number of times resulted in flowd core files. [PR691907: 


• On SRX110 devices, When certificate key size was 2048 bytes and total combined 

certificate request size was greater than 4096 bytes, the PKID service might crash on 

certificate enrollment. [PR698846: This issue has been resolved.] 

• On all branch SRX Series devices, in Internet Explorer, the dashboard panels did not 

show any data until they were refreshed. [PR703958: This issue has been resolved.] 

• On SRX220 devices, GRE and GRE-IPsec performance drop was seen. [PR70642: This 


• On SRX650 devices, "kern.maxfiles limit exceeded by uid 0" messages is displayed. 



389


• On all branch SRX Series devices, the spoofing screen was dropping IPv6 packets 

sourced from the unspecified source address (example: 0:0:0:0:0:0:0:0/128 or ::/128). 


• On all branch SRX Series devices, the following message is displayed when the 

ntp-related show commands are not working: 

ntpq: socket: Protocol not supported 


• On SRX100 devices, UTM/Av was not working with only 1 PC search from yahoo.co.jp, 

it failed to load when content size setting is set to 20. [PR722652: This issue has been 

resolved.] 

• On all branch SRX Series devices, changes to URL category value caused value deletion 

in the Web-filtering profile. [PR723884: This issue has been resolved.] 

• On SRX240 devices, Flowd core occurred after upgrading to 11.2R5 due to mbuf not 

being cleaned up. [PR734885: This issue has been resolved.] 

• On SRX220, SRX550, SRX650, J2320, and J4350 devices, NSD core files were 

generated. [PR735152: This issue has been resolved.] 

• On all branch SRX Series devices, the application groups statistics were shown as 

“unassigned” and “unknown” for the show services application-identification statistics 

application-groups command output without displaying the details. [PR740014: This 


• On SRX240 devices, when "Change password every time the user logs out" is enabled 

on the active directory, and user tries to change the password on SRX series platforms, 

it did not work. [PR740869: This issue has been resolved.] 

• On SRX220 devices, Enhanced Web Filtering requests to Websense TSC may go to 

connectivity/timeout fallback due to TSC only serving 10,000 requests per connection. 

A new method of juggling multiple connections are introduced in 12.1R1 and 11.4R3 and 

later releases. [PR741697: This issue has been resolved.] 

• On SRX220 devices, IKE SA fails to establish occasionally when there are two VPN 

destined to same IKE gateway. [PR743897: This issue has been resolved.] 

• On all branch SRX and J Series devices, the TCP initial timeout minimal limitation in 

CLI 'set security flow tcp-session tcp-initial-timeout' was changed from 20 seconds 

to 4 seconds. The new range is 4..300 seconds. Setting this timeout to a small value 

may increase the possibility of failing to create TCP sessions. [PR747769: This issue 



• On all branch SRX Series devices, additional neighbor solicitation packets sent were 

corrupted. The packet had zeroed destination MAC address and the entire packet was 

prefixed by two random bytes. [PR671658: This issue has been resolved.] 

• On SRX650 devices, BGP flaps intermittently and takes 1 hour to re-establish over vpn. 


390 



IPv6 

• On all branch SRX Series devices, the flow bytes counters tracked on a per-interface 

basis were incorrect for IPv6 flows, and flow output bytes statistics were reversed to 

the source or destination interfaces. [PR740911: This issue has been resolved.] 

J-Web 

• On all branch SRX Series devices, after performing any configuration change in the CLI 

, the pending commit pop-up window does not appear in J-Web interface. [PR670459: 


• On all branch SRX Series devices, in J-Web, Configure tab > Interface page, edit SHDSL 

interface pop-up is blank. [PR671487: This issue has been resolved.] 

• On SRX210 devices, when you enter the destination port range as 1112 to some invalid 

value, it displays the following error message: Please enter valid ending port 0-65535. 

This error message conflicts with the available range (1024 through 64387). [PR673840: 


• On all branch SRX devices, you cannot view the access point details of an active access 

point from the J-Web Monitor > Wireless LAN page. [PR700513: This issue is resolved.] 

• On SRX210 and SRX240 devices in J-Web, the commit operation failed when the proxy 

server value was cleared in AV global options tab. [PR721248: This issue has been 

resolved.] 

• On all branch SRX Series devices, after you configured the interface speed and duplex 

on the J-Web interface, the page showed the speed and duplex values as following: 

• Speed:10Mbps/100Mbps/1Gbps 

• Duplex:Full Duplex/Half Duplex 

When you went to another page and then returned back to this page, the display 

changed as following: 

• Speed:10m/100m/1g 

• Duplex:full duplex/half duplex 


• On all branch SRX Series devices, the Application Tracking monitor page does not 

display the warning "no data to display", when there is no data to display in the table. 


• On SRX650 devices, in J-Web IDP Active policy page was displaying "none" instead 

of "Recommended" on IDP monitor page in longevity or stress setup in Internet Explorer 

browser. [PR725929: This issue is resolved.] 

• On SRX650 devices, in J-Web Add, Edit, Delete, Clone, and Deactivate tags are grayed 

out for some of the security policies. [PR729153: This issue has been resolved.] 

• On all branch SRX Series devices in J-Web, the configuration page lists the surf control 

categories in the enhanced Web filter category. [PR729643: This issue has been 

resolved.] 


391


• On all branch SRX Series devices, on the Configure > Security > Logging page, the 

Apply button remained disabled even after changing the configuration. [PR730861: 


• On SRX210 devices, in the Login or Splash screen and the Help mapping file, the 

copyright date is set to 2011. [PR731790: This issue has been resolved.] 

• On SRX100 devices, in J-Web, when SRX is configured in 'Transparent' mode, the 

'Reports' tab is not present in Monitor section. Now it is fixed latest release for 11.4,12.1 

and 12.2. [PR734365: This issue has been resolved.] 

• On all branch SRX Series devices, J-Web user cannot configure Proxy server port range 

from 0-1023 due to incorrect port range error message. [PR736789: This issue has been 

resolved.] 

• On all branch SRX Series devices, The "security screen ids-options" that checks tcp 

flags may drop IPv6 TCP flows, when the IPv6 fragmentation extension header is 

present. [PR740840: This issue has been resolved.] 

• On SRX550 and SRX650 devices, reboot did not work. [PR741014: This issue has been 

resolved.] 

• On all branch SRX Series devices, the Application Tracking monitor page does not work 

fine for non default intervals with cumulative statistics. [PR747271: This issue has been 

resolved.] 


• On SRX240 devices, when an IP or Port pair in message payload is matched to a known 

NAT entry, it will ship the NAT process that caused the payload not to be rewritten. 


Switching 

• On SRX650 devices, though the MTU value is configured to 9192 bytes, the packets 

of payload size ranging between 9147 to 9150 were dropped. [PR742310: This issue 


UTM 

• On SRX 650 devices, with AV enabled, an FTP connection would hang when trying to 

access a folder with "quit" in the name. [PR739635: This issue is resolved.] 


• On all branch SRX Series devices, occasionally, when keys are generated incorrectly 

for IPsec, VPN to go down due to encapsulation security payload (ESP) failures. 


• On all branch SRX Series devices, Occasionally, policy-based IPSec VPN that has been 

established successfully does not allow traffic to the protected resources. [PR718057: 


392 




Gateways 

Application Layer Gateway(ALG) 

• On SRX650 devices, when MGCP ALG is enabled and the MGCP traffic traverses the 

device, the device crashes and generates core files. [PR602694: This issue has been 

resolved.] 


• On SRX240 devices in a chassis cluster, switching did not work. [PR701539: This issue 



• On SRX 210 devices, an issue of IKE renegotiation when an RG0 failover is initiated on 

chassis cluster setup. [PR513884: This issue has been resolved.] 

• On all branch SRX Series devices, changes in policer, filter, or sampling configuration 

caused a core file to be generated during receipt of multicast traffic [PR613782: This 


• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, when the LDP based 

signalling was used for VPLS neighbor discovery, a restart of routing was required for 

the LDP based signalling to work properly (after configuration is committed). 

[PR668555 : This issue has been resolved.] 

• On J4350, SRX550, and SRX650 devices, when the peers are connected directly 

through the t1 link and the ge link, pinging to the peer link local address of the t1 link 

interface does not go through the t1 link, but through the ge link instead. [PR684159: 


• On SRX650 devices, built in ports did not count the FCS error statistics. [PR690726: 


• On SRX210 devices, UTM EAV status shows Engine not ready (Database Loading) 

even after successfully loading the database. This issue occurs occasionally after the 

image upgrade or downgrade, and on a system reboot. [PR693530: This issue has been 

resolved.] 

• On all branch SRX series devices, If an aggregate bundle goes down due to 

minimum-links 2 or higher configured, bundle member links might not attach to the 

bundle once the aggregate bundle comes back up. Outbound traffic does not use this 

member link (no blackholing) and inbound traffic for this member link was properly 

processed and forwarded. The same symptom might also be visible after system reboot 

without the need of member link flaps. [PR695895: This issue has been resolved.] 

• On SRX210 devices, core files for pfe daemons were observed. [PR697032: This issue 


• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, a memory leak occurred 

during the audit event processing. [PR698907: This issue has been resolved.] 


393


• On SRX240 and SRX650 devices, policer was not policing configured rates at high 

bandwidths. [PR703003: This issue has been resolved.] 

• On SRX240 devices, when heavy traffic was sent through GRE interface during RG-0 

(Redundancy Group 0) switch over, there was a chance that flowd daemon might core 

on node that became primary (after switchover). [PR703295: This issue has been 

resolved.] 

• On SRX210, SRX220, and SRX240 devices, the DSL line started re-negotiation with 

DSLAM after configuring MTU on VDSL interface in VDSL mode. After configuring MTU 

on VDSL interface, the line might take some time to train with DSLAM and to come up. 


• On all branch SRX Series devices, when you add or change policy configuration within 

groups, the policies may not get applied correctly. The applied configuration might be 

valid and therefore will pass the configuration check but the process uses that policy 

(depending on configuration) might terminate and restart. [PR707817: This issue has 


• On all branch SRX Series devices, the chassis cluster setup, primary node does not 

show security resource details on Dashboard page due to which the following message 

log is generated: "Security Resources:error: invalid value: firewall-policies". [PR720435: 



• On all branch SRX devices, the In-band Cluster Upgrade (ICU) with mount method 

will not function properly in release 12.1B2. You can use ICU with local copy of the image 

or use FTP URL method. [PR708412: This issue has been resolved.] 

Installation 

• On all branch SRX Series devices, while downgrading from Junos Release 11.4 or a later 

image to Junos Release 11.1 or an earlier image, the security package was deleted. 

Although it was automatically installed when the IDP daemon came up, this automatic 

installation sometimes failed due to application identification (AI) installation error. 



• On SRX210 High Memory devices, a remote end ping will not check for the presence 

of a packet size of more than 1480 because the packets are dropped for the default 

MTU, which is 1496 at the interface and the default MTU of the remote host Ethernet 

intf is 1514. [PR469651: This issue has been resolved.] 

• On J4350 devices, the routed interface (inet family) is not supported on the UPIMs 

when PIC mode is configured as “switching”. Only the switching functionality is 

supported in this mode. [PR590771: This issue has been resolved.] 

• On SRX210, SRX220, and SRX240 devices, with an at-x/x/x interface (ADSL, VDSL 

operating in at mode, and SHDSL), the difference between the MTU values on the 

logical interface and the MTU values on the physical interface have to be exactly 40 

bytes. If this is not the case, the IP information will not be displayed by the show 

interfaces command output. [PR591585: This issue has been resolved.] 

394 



• On SRX220 devices, the throughput dropped to 20 Mbps on a 100 Mbps interface (only 

in Gigabit Ethernet-to-100 Mbps direction) when a bi-directional traffic was sent 

between Gigabit Ethernet interface and 100 Mbps interface. [PR671248: This issue has 


• On all branch SRX and J Series devices, when the peers are connected directly through 

T1 link and Ge link, pinging to the peer link local address of T1 link interface is not going 

through T1 link, instead it was going through Ge link. [PR684159: This issue has been 

resolved.] 

• On SRX Series devices, a memory leak occurred during the audit event processing. 


• On SRX220 devices, when using IP monitoring when more than one route location was 

added upon RPM probe failure that upon recovery not all routes are removed. Even if 

the ip-monitoring observe the default static route was failed, system still had the 

routing entry in the routing-table. [PR699072: This issue has been resolved.] 


• On SRX210 devices, the IDPD daemon caused core files to be generated, if PFE went 

offline during policy load operation. [PR702321: This issue has been resolved.] 

• On all branch SRX devices, the custom attacks are not getting detected on branch 

devices even if there was no IDP signature database license, the expected behavior 

which was broken earlier. [PR710147: This issue has been resolved.] 

J-Web 

• On SRX100 devices, if node 0 is down, you must use the CLI to see chassis information. 


• On all branch SRX Series devices, J-Web shows invalid page while editing ppd0 and 

ppe0 interfaces. [PR660575: This issue has been resolved.] 

• On SRX650 devices, in J-Web, the configuration change cannot pass the commit check; 

therefore, you cannot delete the domain name of an address book. [PR662618: This 


• On SRX110 devices, the J-Web interface did not work on the SRX110H-VB models. 


• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the Layer 2 Transparent 

mode is working through J-Web. [PR691530: This issue has been resolved.] 

• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, while editing an 

uncommitted PPPoE connection, which had a zone without firewall policy, the J-Web 

page gets blocked in zone page of PPPoE wizard, and warning dialog box was displayed 

to convey the message. [PR697891: This issue has been resolved.] 

• On all branch SRX devices, you cannot view the access point details of an active access 

point from the J-Web Monitor > Wireless LAN page. [PR700513: This issue has been 

resolved.] 

• On all branch SRX devices, CPU data graph was not reflecting cli data on Dashboard 

> Resource Utilization. [PR719042: This issue has been resolved.] 


395


• On SRX210 and SRX240 devices, commit failed when proxy server value was cleared 

from J-Web in AV global options tab. [PR721248: This issue has been resolved.] 

• On SRX210 devices, when the CLI option to delete a DHCP pool was used, the J-Web 

interface Monitor page (Monitor > Services > DHCP > Pools) did not display the correct 

value in the "Excluded address" field. It displayed the text "[objec object]" in the table. 


License 

• On SRX210, SRX220, SRX240, and SRX650 devices, at times after a software upgrade 

of the device, while committing the configuration changes through J-Web interface in 

Configure > Wireless Lan > Settings page, the following message is displayed: warning: 

requires 'ax411-wlan-ap' license. [PR697531: This issue has been resolved.] 

Switching 

• On SRX650 devices, when layer 2 link aggregation (4 x 1 Gbps) was configured, traffic 

was limited to 1 Gbps. [PR677656: This issue has been resolved.] 

UTM 

• On SRX100, SRX210, SRX220, SRX240 and SRX650 devices, the throughput 

performance of Surf Control Web Filter dropped for Junos OS 11.4R1 release. [PR671777: 


• On SRX210 devices, UTM EAV status shows Engine not ready (Database Loading) 

even after successfully loading the database. This issue occured at times even after 

the image upgrade or downgrade, and on a system reboot. [PR693530: This issue has 


• On all branch SRX devices, in a chassis cluster, the status of the UTM Surf Control CPA 

web filtering server in the primary node was down when the server is reachable. 


• In UTM, sometimes anti-virus pattern database update notification mail might not go 

to the administrator if configured due to a bug in mail message parsing. [PR703403: 


• On J Series devices, do not upgrade UTM feature to Release 11.4R1. [PR707622: This 


• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, when using an UTM 

antivirus for SMTP email and if the email is using X-ANONYMOUS option, the email 

might get blocked. [PR717066: This issue has been resolved.] 


• On SRX240 devices, on reboot “mgd commit” fails when you configure Static Next hop 

tunnel bundling. [PR695671: This issue has been resolved.] 

• On SRX240 devices, an access to the Dynamic-VPN portal was denied with a following 

error in httpd.log: Error: "Unauthorized", code 401 for URI "/dynamic-vpn", file 

"/html/dynamic-vpn": Interface is not authorized for HTTP access. [PR712179: This 


396 




Gateways 


• On SRX210 devices, when you used OpenPhone in fast start/slow start tunnel mode 

and another phone in normal mode, the call failed. [PR684951: This issue has been 

resolved.] 


• On SRX650 devices, when a new user was added the authentication failed. [PR661720: 



• On SRX240 and SRX650 devices in a chassis cluster, telnet/ssh to RVI traffic through 

secondary node ports timed out within 20 seconds. [PR567805: This issue has been 

resolved.] 

• On SRX650 devices in a chassis cluster, some interfaces on node0 showed unspecified 

speed and half-duplex. [PR597575: This issue has been resolved.] 

• On SRX650 devices, the antivirus feature caused forwarding slowness at traffic peaks 

due to a memory issue related to scanning of SMTP traffic. [PR610336: This issue has 


• On SRX650 devices in a chassis cluster, failover took more than 5 seconds when the 

monitored interface flapped. [PR664851: This issue has been resolved.] 

• On SRX210, SRX220, SRX240, and SRX650 devices, when the ISSU failed and only 

one device in the cluster was upgraded, rollback to the previous configuration on that 

device was achieved only by using the following commands on the upgraded device: 

• request chassis cluster in-service-upgrade abort 

• request system software rollback 

• request system reboot 


• On SRX650 devices, when a second node was not present in a chassis cluster 

configuration, any new provision of redundancy group got stuck in secondary state. 


• On SRX650 devices, for switching deployment in chassis cluster, multicast traffic was 

duplicated. [PR689153: This issue has been resolved.] 


397


DHCP 

• On J4350 devices, the DHCP client lease did not have the correct attributes during 

static lease renewal by the DHCP server to the client. [PR665084: This issue has been 

resolved.] 


• On SRX210, SRX220, SRX240, SRX650, and J Series devices, the TCP connections per 

second drop was anticipated. [PR550444: This issue has been resolved.] 

• On SRX210, SRX240, and SRX650 devices, handling traffic required fragmentation of 

packets that were not passing or had large latency. [PR590480: This issue has been 

released.] 

• On SRX100 devices, when the device was switched from Layer 3 to Layer 2 mode, the 

user was prompted to reboot the device. If the device was not rebooted and was 

switched back to Layer 3 mode, a core file was generated. [PR605293: This issue has 


• On SRX210 High Memory devices, when the anchor interface of GRE tunnel interface 

was configured to get IP by CX111, the GRE tunnel was not created and the CX111 was 

restarted. [PR605529: This issue has been resolved.] 

• On J6350 devices in a chassis cluster, when the restart forwarding gracefully command 

was executed, the FPC remained offline. [PR605657: This issue has been resolved.] 

• On SRX220 devices, the show security policy command inconsistently 

showed the possible objects (security policy names) in the operation and configuration 

modes. [PR608664: This issue has been resolved.] 

• On J2320 devices, the E1 connection interface dropped traffic and a core file was 

generated. [PR609720: The issue has been resolved.] 

• On SRX210, SRX220, and J6350 devices, when the interface configuration changed 

continuously, the OSPF got stuck at the init state over the E1/T1 link. [PR660264: This 


• On SRX100, SRX210, SRX220, and SRX240 Low Memory devices, due to memory 

allocations, traffic stopped passing when ALG-based traffic was used. [PR664378: 


• On SRX240 devices, packet mode reordering of packets failed in multithreaded 

platforms for multicast flows that had to go out on a single egress interface. [PR669046: 


• On SRX210 devices, the 80th, 160th, 240th, and so on characters of the message were 

lost while sending messages using the request message command. [PR670106: This 


• On J2350 devices, the vrf-table-label could not be used when you used the 

encapsulation type flexible-ethernet-services. [PR671286: This issue has been resolved.] 

398 



• On SRX240 devices, when host-originated packets were sent out through the 

gr-interface, both local and transit counters did not increment for this interface. 


• On SRX100, SRX210, SRX220, SRX240, SRX650 and J Series devices, Remote MAC 

Learning for VPLS did not work. [PR687956: This issue has been resolved.] 


• On SRX650 devices, when you rebooted the secondary node, the multicast session 

was rebuilt, and there were extra leaves sessions with local0 as the outgoing interface 

setup. [PR604084: This issue has been resolved.] 

• On SRX650 and J4350 devices, when OSPF was used over IPsec, a core file was 

generated when the routing process was restarted. [PR606272: This issue has been 

resolved.] 

• On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, VLAN to interface 

disassociation did not work properly. [PR662942: This issue has been resolved.] 

• On SRX240 devices, no optical diagnostics were available for the Gigabit Ethernet 

interface on the 1x GE High-Performance SFP Mini-PIM PIC. [PR666315: This issue has 


• On SRX210 devices, monitor traffic disabled the VPLS service. [PR670230: This issue 


• On SRX210 devices, when processing traffic from SRX devices or to the SRX devices 

(host-bound traffic), GRE interface counters showed incorrect values and decremented 

occasionally. This was a display issue, as traffic was still being processed normally and 

no packets were lost. [PR672302: This issue has been resolved.] 

• On SRX240 devices, an error message was displayed when committing a DNAT pool 

configuration with an IP address of 0.0.0.0/0 even though the commit executed 

successfully. [PR682915: This issue has been resolved.] 


• On SRX650 devices, VRRP hello packets were lost during IDP pattern update. 


J-Web 

• On the Security >Filters >IPv4 page and IPv6 firewall filters page, when users added 

a new IPv4 filter name and clicked the Add button, the change was not reflected on 

the pages. In addition, the configure firewall filter page did not appear. [PR576194: This 


• On SRX210 devices in the J-Web interface, when you discard any available MIB profile, 

file, or predefined object from accounting-options on the Point and Click CLI 

Configuration page (Configure > CLI Tools > Point and Click CLI), the J-Web session 

timed out. [PR689261: This issue has been resolved.] 


399


• On all branch SRX Series devices, when you configure the wireless LAN access point 

on the Configure >Wireless LAN > Setting page, you could not set Bolivia as a country. 


License 

• The SRX210, SRX220, SRX240, and SRX650 devices had two free dynamic VPN user 

licenses, but the LICENSE_EXPIRED alarm was generated if less than two users 

connected to the VPN. [PR661417: This issue has been resolved.] 

• On SRX210 and SRX240 devices with DC Power Supply, the default licenses did not 

work. [PR667526: This issue has been resolved.] 

NAT 

• On SRX240 devices, when you configure IP addresses for proxy-ARP under the “Security 

NAT” configuration, the device failed to respond to ARP-probe packets. [PR663507: 


Switching 

• On SRX210, SRX220, and J Series devices, the Dot1x-enabled port flooded traffic 

without authentication. [PR687053: This issue has been resolved.] 

UTM 

• On SRX650 devices, a commit error occurred when the policy used UTM: 

“application-services' warning: license not installed for”. [PR600941: This issue has 


• On all branch SRX Series devices, when you added a date-based license, the device 

accepted the license. but the output for the show system license command did not 

display this information in the licenses installed field. [PR665111: This issue has been 

resolved.] 

• On SRX210 devices, the http downloading connection for UTM antivirus was dropped 

when the file exceeded 2 GB. [PR668818: This issue has been resolved.] 

• On all branch SRX Series devices, you could enable the Enhanced Web Filtering feature 

of UTM with a license for the Surf Control Web Filtering feature. [PR686290: This issue 



• On SRX210 devices, when the "@" sign was included in the dynamic hostname, the 

clear security dynamic-vpn user returned an error: 

"Invalid username or ike id for user xxxx. No entry was cleared." [PR608342: This issue 


• On SRX650 devices, the DSCP tagged packets coming in from a VPN tunnel were not 

classified and were placed in the default best-effort queue on the egress interface. 


400 


Errata and Changes in Documentation for Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series Services Routers 

Related 

Documentation 







Errata and Changes in Documentation for Junos OS Release 11.4 for Branch SRX Series Services 


Errata for the Junos OS Software Documentation 

This section lists outstanding issues with the software documentation. 

Junos OS CLI Reference 

• The Junos OS CLI Reference incorrectly specifies the IPsec proposal options in 

proposal-set (IPsec) section. The IPsec proposals should be as follows: 

• basic—nopfs-esp-des-sha and nopfs-esp-des-md5 

• compatible—nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha, and 

nopfs-esp-des-md5 

• standard—g2-esp-3des-sha and g2-esp-aes128-sha 

• The Junos OS CLI Reference is missing information about the operational CLI command 

show pppoe interfaces, which is used to display session-specific information about 

PPPoE interfaces. 

user@host>show pppoe interfaces 

pp0.0 Index 71 

State: Session up, Session ID: 4, 

Service name: None, 

Session AC name: srx-pppoe-ac, Configured AC name: None, 

Remote MAC address: b0:c6:9a:74:5e:c1, 

Session uptime: 5d 15:21 ago, 

Auto-reconnect timeout: Never, Idle timeout: Never, 

Underlying interface: ge-0/0/1.0 Index 70 

• The Junos OS CLI Reference is missing information about the operational CLI command 

show pppoe statistics, which is used to display statistics information about PPPoE 

interfaces. 

user@host>show pppoe statistics 

Active PPPoE sessions: 0 

PacketType Sent Received 

PADI 0 0 

PADO 0 0 

PADR 0 0 

PADS 0 0 

PADT 0 0 

Service name error 0 0 

AC system error 0 0 

Generic error 0 0 


401


Malformed packets 0 0 

Unknown packets 0 0 

Timeout 

PADI 0 

PADO 0 

PADR 0 

Receive Error Counters 

PADI 0 

PADO 0 

PADR 0 

PADS 0 

• The Junos OS CLI Reference is missing information about the value for the messages 

received field in too-many-requests (Security Antivirus Fallback Options) command 

the following statement is updated with a value for the limit as: 

If the total number of messages received concurrently exceeds 4000. 

J Series Services Router Advanced WAN Access Configuration Guide 

• The example given in the “Configuring Full-Cone NAT” section in the J Series Services 

Router Advanced WAN Access Configuration Guide available at 

http://www.juniper.net/techpubs/software/jseries/junos85/index.html is incorrect. The 

correct and updated example is given in the J Series Services Router Advanced WAN 

Access Configuration Guide available at 

http://www.juniper.net/techpubs/software/jseries/junos90/) . 

J2320, J2350, J4350, and J6350 Services Router Getting Started Guide 

• The “Connecting to the CLI Locally” section in the J2320, J2350, J4350, and J6350 

Services Router Getting Started Guide states that the required adapter type is DB-9 

female to DB-25 male. This is incorrect; the correct adapter type is DB-9 male to DB-25 

male. 

Junos OS Feature Support Reference for SRX Series and J Series Devices 

• Junos OS Feature Support Reference for SRX Series and J Series Devices chapter 2 

’Feature Support Tables’, row 1 of Table 50: Transparent Mode Support, incorrectly 

states that bridge domain and transparent mode feature is not supported on SRX100, 

SRX210, SRX220, SRX240, and SRX650 devices. Bridge domain and transparent mode 

feature is supported on all the listed devices from Junos OS Release 11.1. 

• In Junos OS Feature Support Reference for SRX Series and J Series Devices, the DHCPv6 

support listed in Chapter 2, Table 14 is incorrect. The DHCPv6 client is not supported 

on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 devices. The DHCPv6 

server is supported on SRX100, SRX110, SRX210, SRX220, SRX240, and SRX650 

devices. 

• In Junos OS Feature Support Reference for SRX Series and J Series Devices, the Chassis 

Cluster table incorrectly indicates that Layer 2 Ethernet switching capability in chassis 

cluster mode is supported on SRX100 devices. Layer 2 Ethernet switching capability 

in chassis cluster mode is not supported on SRX100 devices. 

402 



Junos OS Interfaces Configuration Guide for Security Devices 

• In this guide, Table 11, "MTU Values for the SRX Series Services Gateways PIMs," does 

not specify the maximum MTU and default IPMTU values for the following PIMs: 

• 2-Port 10 Gigabit Ethernet XPIM 

• 16-Port Gigabit Ethernet XPIM 


The following table lists these values: 

Table 21: MTU Values for the SRX Series Services Gateways PIMs 

PIM 

DefaultMediaMTU(Bytes) 

MaximumMTU (Bytes) 

DefaultIPMTU (Bytes) 

2-Port 10 Gigabit Ethernet XPIM 

1514 

9192 

1500 

16-PortGigabitEthernetXPIM 

1514 

9192 

1500 

24-Port Gigabit Ethernet XPIM 

1514 

9192 

1500 

J-Web 

• J-Web security package update Help page—The J-Web Security Package Update 

Help page does not contain information about the download status. 

• J-Web pages for stateless firewall filters—There is no documentation describing the 

J-Web pages for stateless firewall filters. To find these pages in J-Web, go to 

Configure>Security>Firewall Filters, and then select IPv4 Firewall Filters or IPv6 

Firewall Filters. After configuring the filters, select Assign to Interfaces to assign your 

configured filters to interfaces. 

• J-Web Configuration Instructions— Because of ongoing J-Web interface enhancements, 

some of the J-Web configuration example instructions in the Junos administration and 

configuration guides became obsolete and thus were removed. For examples that are 

missing J-Web instructions, use the provided CLI instructions. 


403


Junos OS Monitoring and Troubleshooting Guide for Security Devices 

• In the “Example: Enabling Packet Capture on a Device” section, the CLI quick 

configuration shows an incorrect set command. The correct set command is set 

forwarding-options packet-capture file filename pcap-file files 100 size 1024 

world-readable. 

Junos OS Security Configuration Guide 

• In “Example: Configuring IP Monitoring” of the IP Monitoring section, the CLI Quick 

Configuration incorrectly lists the set services rpm probe Probe-Payment-Server test 

paysvr thresholds total-loss configuration command. The command has been removed. 

The set services ip-monitoring Payment-Server-Tracking then preferred-route route 

1.1.1.0/24 next-hop 1.1.1.99 configuration command listed in the CLI Quick Configuration 

and in Step 8 of the step-by-step procedure is incorrect. The correct command is set 

services ip-monitoring policy Payment-Server-Tracking then preferred-route route 

1.1.1.0/24 next-hop 1.1.1.99. 

• In this guide, the “Understanding Chassis Cluster Redundancy Group Interface 

Monitoring” section includes a note that states interface monitoring is not supported 

on Redundancy Group 0 (RG0) for branch SRX Series devices. This note should also 

state that it is not supported for J Series devices. 

• In this guide, the section “Understanding Chassis Cluster Redundancy Group Interface 

Monitoring” has a misleading statement in the steps describing the “Policy Lookup for 

a User” figure. It states that the device forwards the packet from its buffer to its 

destination IP address 1.2.2.2. However, this is true only for HTTP and Telnet traffic. 

For FTP traffic, after successful authentication the device closes the session and the 

user must reconnect to the FTP server at IP address 1.2.2.2. 

• In Chapter 48, “AppTrack Application Tracking,” of the Junos OS Security Configuration 

Guide for Security Devices, the operational command show security application-tracking 

statistics applications is incorrect. The operational command to display all application 

identification statistics, including application tracking statistics, is show services 

application-identification statistics applications. 

The operational command show application-tracking counters is incorrect. The 

command should be show security application-tracking counters. 

• In Chapter 1, “Understanding Flow-Based Processing,” of the Junos OS Security 

Configuration Guide a figure showed incorrect placement of static, destination, and 

source NAT. The figure has been corrected in Junos OS Release 11.4. 

• The Junos OS Security Configuration Guide incorrectly states that the release supports 

security chains, which validate a certificate path upward through eight levels of CA 

authorities in the PKI hierarchy. The release does not support security chains. 

• The Junos OS Security Configuration Guide incorrectly states that “For SRX Series chassis 

clusters made up of SRX100,SRX210,SRX220,SRX240, or SRX650 devices, SFP 

interfaces on Mini-PIMs cannot be used as the fabric link”. However, the SFP interfaces 

on Mini-PIMs can be used as the fabric link with the following limitation: 

404 



“During node failover, sometimes primary node goes to disabled state and fabric probes 

are not received”. 

• In the “Internet Protocol Security” chapter of theJunos OS Security Configuration Guide, 

“Understanding Virtual Router Limitations" incorrectly lists “Internet Key Exchange 

(IKE) inside VR” as not being supported. Support for IKE in multiple virtual routers 

(VRs) was added in the Junos OS 11.1R1 release for all SRX Series and J Series devices. 

Also, “Virtual Router Support for Route-Based VPNs” incorrectly includes a note that 

for VPN traffic to work in a nondefault VR, the IKE listener must be placed in the default 

VR. 

• In chapter 4, “Understanding Selective Stateless Packet Based Services,”Junos OS 

Security Configuration Guide previously contained the following incorrect statement: 

A defined set of stateless services is available with selective stateless packet based 

services: 

• IPv4 and IPv6 routing (unicast and multicast protocols) 

• Class of service (CoS) 

• Link fragmentation and interleaving (LFI) 

• Generic routing encapsulation (GRE) 

• Layer 2 switching 


• Stateless firewall filters 

• Compressed Real Time Transport Protocol (CRTP) 

The list includes “IPv6” which is not available with selective stateless packet based 

services. The guide has been updated with the correct statement, as follows: 

A defined set of stateless services is available with selective stateless packet based 

services: 

• IPv4 routing (unicast and multicast protocols) 

• Class of service (CoS) 

• Link fragmentation and interleaving (LFI) 

• Generic routing encapsulation (GRE) 

• Layer 2 switching 


• Stateless firewall filters 

• Compressed Real Time Transport Protocol (CRTP) 

• The “Understanding Enhanced Web Filtering Functionality,” section of Junos OS Security 

Configuration Guide has the following incorrect statement: 


405


The license key for the Surf Control integrated solution is not valid for the Enhanced 

Web Filtering solution. You need to install a new license to upgrade to the Enhanced 

Web Filtering solution. 

The correct information is as follows: 

The license key for the Surf Control integrated solution is also valid for the Enhanced 

Web Filtering as long as it is not expired. You need not install a new license to upgrade 

to the Enhanced Web Filtering solution. 

NOTE: You can ignore the warning message "requires 

'wf_key_websense_ewf' license” because it is generated by routine EWF 

license validation check. 

• The “Understanding DNS Doctoring” section incorrectly states that the DNS ALG will 

not drop traffic if the DNS message length exceeds the configured maximum, if the 

domain name is more than 255 bytes, or if the label length is more than 63 bytes. 

This section has been corrected as follows: The DNS ALG will not drop traffic if the 

DNS message length exceeds the configured maximum. However, the DNS ALG will 

check the length of the domain name and label, and it will drop packets if either the 

domain name is more than 255 bytes or the label length is more than 63 bytes. 

• The following sections were removed from the guide as they were causing confusion: 

“H.323 ALG Endpoint Registration Timeouts,” “Understanding H.323 ALG Endpoint 

Registration Timeouts,” and “Example: Setting H.323 ALG Endpoint Registration 

Timeouts.” 

• The “Understanding Internet-Related Predefined Policy Applications” section of Junos 

OS Security Configuration guide incorrectly specifies the HTTP port value as 80 in 

Predefined Applications table. The correct port value for HTTP is 8080. 

Junos OS System Log Messages Reference 

• The Junos 11.4 System Log Messages Reference is missing the following AV system log 

messages: 

This list below are messages with the AV prefix They are generated by the antivirus 

scanning process (avd): 








• The AV System Log Messages topic lists incorrect facilities for the systems logs. 

406 



On all SRX Series devices, antivirus (AV) system logs are generated with the facility 

LOG_USER or LOG_DAEMON. 

Table 22 on page 407 shows the correct facilities for the system logs. 

Table 22: Antivirus System Logs 

System Logs 

Incorrect Facility 

Correct Facility 

AV_PATTERN_GET_FAILED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_KEY_EXPIRED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_KL_CHECK_FAILED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_TOO_BIG 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_UPDATED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_WRITE_FS_FAILED 

LOG_FIREWALL 

LOG_DAEMON 

AV_SCANNER_READY 

LOG_FIREWALL 

LOG_DAEMON 

AV_VIRUS_DETECTED_MT 

LOG_PFE 

LOG_USER 

Junos OS WLAN Configuration and Administration Guide 

• This guide is missing information that on all branch SRX Series devices, managing 

AX411 access points through aggregated Ethernet (ae) interface is not supported. 

Various Guides 

• Some Junos OS user, reference, and configuration guides—for example the Junos 

Software Routing Protocols Configuration Guide, Junos OS CLI User Guide, and Junos OS 

System Basics Configuration Guide—mistakenly do not indicate SRX Series device 

support in the “Supported Platforms” list and other related support information; 

however, many of those documented Junos OS features are supported on SRX Series 

devices. For full, confirmed support information about SRX Series devices, please refer 

to the Junos OS Feature Support Reference for SRX Series and J Series Devices. 

Errata for the Junos OS Hardware Documentation 

This section lists outstanding issues with the hardware documentation. 

AX411 Access Point Hardware Guide 

• This guide is missing information that the AX411 Access Point can be managed from 

SRX100 and SRX110 devices. 

J Series Services Routers Hardware Guide 

• In the J Series Services Routers Hardware Guide, the procedure “Installing a DRAM 

Module” omits the following condition: 


407


All DRAM modules installed in the router must be the same size (in megabytes), type, 

and manufacturer. The router might not work properly when DRAM modules of different 

sizes, types, or manufacturer are installed. 

• The J Series Services Routers Hardware Guide incorrectly states that only the J2350 

Services Router complies with Network Equipment Building System (NEBS) criteria. 

The document should state that the J2350, J4350, and J6350 routers comply with 

NEBS criteria. 

• The J Series Services Routers Hardware Guide is missing adding information about 

100Base-LX connector support for 1-port and 6-port Gigabit Ethernet uPIMs. 

Quick Start Guides 

• In the SRX210 Services Gateway 3G ExpressCard Quick Start, several tasks are listed in 

the wrong order. “Task 6: Connect the External Antenna” should appear before “Task 

3: Check the 3G ExpressCard Status,” because the user needs to connect the antenna 

before checking the status of the 3G ExpressCard. The correct order of the tasks is as 

follows: 

1. Install the 3G ExpressCard 

2. Connect the External Antenna 

3. Check the 3G ExpressCard Status 

4. Configure the 3G ExpressCard 

5. Activate the 3G ExpressCard Options 

• In the SRX210 Services Gateway 3G ExpressCard Quick Start, in “Task 6: Connect the 

External Antenna,” the following sentence is incorrect and redundant: “The antenna 

has a magnetic mount, so it must be placed far away from radio frequency noise sources 

including network components.” 

• In the SRX210 3G Quick Start Guide, in the “Frequently Asked Questions” section, the 

answer to the following question contains an inaccurate and redundant statement: 

Q: Is an antenna required? How much does it cost? 

A: The required antenna is packaged with the ExpressCard in the SRX210 Services 

Gateway 3G ExpressCard kit at no additional charge. The antenna will have a magnetic 

mount with ceiling and wall mount kits within the package. 

In the answer, the sentence “The antenna will have a magnetic mount with ceiling and 

wall mount kits within the package” is incorrect and redundant. 

408 


Upgrade and Downgrade Instructions for Junos OS Release 11.4 for Branch SRX Series Services Gateways and J Series Services Routers 

SRX210 Services Gateway Quick Start Guide 

• Installing Software Packages—The SRX210 Services Gateway Quick Start Guide is 

missing the following information: 

On SRX210 devices, the /var hierarchy is hosted in a separate partition (instead of the 

root partition). If Junos OS 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 both in the root partition and under the /var hierarchy. 

Related 

Documentation 





Upgrade and Downgrade Instructions for Junos OS Release 11.4 for Branch SRX Series Services 


• Upgrading and Downgrading among Junos OS Releases on page 409 

• Upgrading an AppSecure Device on page 411 

• Upgrade and Downgrade Scripts for Address Book Configuration on page 411 

• Upgrade Policy for Junos OS Extended End-Of-Life Releases on page 414 

• Hardware Requirements for Junos OS Release 11.4 for SRX Series Services Gateways 


Upgrading and Downgrading among Junos OS Releases 

All Junos OS releases are listed in sequence on the JUNOS Software Dates & Milestones 

webpage: 

http://www.juniper.net/support/eol/junos.html 

To help in understanding the examples that are presented in this section, a portion of 

that table is replicated here. Note that releases footnoted with a 1 are Extended 

End-of-Life (EEOL) releases. 


409


You can directly upgrade or downgrade between any two Junos OS releases that are 

within three releases of each other. 

• Example: Direct release upgrade 

Release 10.3 → (bypassing Releases 10.4 and 11.1) Release 11.2 

To upgrade or downgrade between Junos OS releases that are more than three releases 

apart, you can upgrade or downgrade first to an intermediate release that is within three 

releases of the desired release, and then upgrade or downgrade from that release to the 

desired release. 

• Example: Multistep release downgrade 

Release 11.3 → (bypassing Releases 11.2 and 11.1) Release 10.4 → Release 10.3 

Juniper Networks has also provided an even more efficient method of upgrading and 

downgrading using the Junos OS EEOL releases. EEOL releases generally occur once a 

calendar year and can be more than three releases apart. For a list of, EEOL releases, go 

to http://www.juniper.net/support/eol/junos.html 

410 



You can directly upgrade or downgrade between any two Junos OS EEOL releases that 

are within three EEOL releases of each other. 

• Example: Direct EEOL release upgrade 

Release 9.3 (EEOL) → (bypassing Releases 10.0 [EEOL] and 10.4 [EEOL]) Release 11.4 

(EEOL) 

To upgrade or downgrade between Junos OS EEOL releases that are more than three 

EEOL releases apart, you can upgrade first to an intermediate EEOL release that is within 

three EEOL releases of the desired EEOL release, and then upgrade from that EEOL 

release to the desired EEOL release. 

• Example: Multistep release upgrade using intermediate EEOL release 


(EEOL) → Release 11.4 (EEOL) 

You can even use a Junos OS EEOL release as an intermediate upgrade or downgrade 

step if your desired release is several releases later than your current release. 


Release 9.6 → Release 10.0 (EEOL) → Release 10.2 

For additional information about how to upgrade and downgrade, see the Junos OS 

Installation and Upgrade Guide. 

Upgrading an AppSecure Device 

Use the no-validate Option for AppSecure Devices. 

For devices implementing AppSecure services, use the no-validate option when upgrading 

from Junos OS Release 11.2 or earlier to Junos OS 11.4R1 or later. The application signature 

package used with AppSecure services in previous releases has been moved from the 

configuration file to a signature database. This change in location can trigger an error 

during the validation step and interrupt the Junos OS upgrade. The no-validate option 

bypasses this step. 

Upgrade and Downgrade Scripts for Address Book Configuration 

Beginning with Junos OS Release 11.4, you can configure address books under the [security] 

hierarchy and attach security zones to them (zone-attached configuration). In Junos OS 

Release 11.1 and earlier, address books were defined under the [security zones] hierarchy 

(zone-defined configuration). 

You can either define all address books under the [security] hierarchy in a zone-attached 

configuration format or under the [security zones] hierarchy in a zone-defined configuration 

format; the CLI displays an error and fails to commit the configuration if you configure 

both configuration formats on one system. 


411


Juniper Networks provides Junos operation scripts that allow you to work in either of the 

address book configuration formats (see Figure 1 on page 413). 

• About Upgrade and Downgrade Scripts on page 412 

• Running Upgrade and Downgrade Scripts on page 413 


About Upgrade and Downgrade Scripts 

After downloading Junos OS Release 11.4, you have the following options for configuring 

the address book feature: 

• Use the default address book configuration—You can configure address books using 

the zone-defined configuration format, which is available by default. For information 

on how to configure zone-defined address books, see the Junos OS Release 11.1 


• Use the upgrade script—You can run the upgrade script available on the Juniper Networks 

support site to configure address books using the new zone-attached configuration 

format. When upgrading, the system uses the zone names to create address books. 

For example, addresses in the trust zone are created in an address book named 

trust-address-book and are attached to the trust zone. IP prefixes used in NAT rules 

remain unaffected. 

After upgrading to the zone-attached address book configuration: 

• You cannot configure address books using the zone-defined address book 

configuration format; the CLI displays an error and fails to commit. 

• You cannot configure address books using the J-Web interface. 

For information on how to configure zone-attached address books, see the Junos OS 

Release 11.4 documentation. 

• Use the downgrade script—After upgrading to the zone-attached configuration, if you 

want to revert to the zone-defined configuration, use the downgrade script available 

on the Juniper Networks support site. For information on how to configure zone-defined 

address books, see the Junos OS Release 11.1 documentation. 

NOTE: Before running the downgrade script, make sure to revert any 

configuration that uses addresses from the global address book. 

412 



Figure 1: Upgrade and Downgrade Scripts for Address Books 

Download Junos OS 


zone-defined 

address book 

Run the upgrade script. 

zone-attached 

address book 

configuration 

- Global address book is 

available by default. 

- Address book is defined under 

the security hierarchy. 

- Zones need to be attached 

to address books. 

Run the downgrade script. 

Note: Make sure to revert any 

configuration that uses addresses 

from the global address book. 

g030699 

Running Upgrade and Downgrade Scripts 

The following restrictions apply to the address book upgrade and downgrade scripts: 

• The scripts cannot run unless the configuration on your system has been committed. 

Thus, if the zone-defined address book and zone-attached address book configurations 

are present on your system at the same time, the scripts will not run. 

• The scripts cannot run when the global address book exists on your system. 

• If you upgrade your device to Junos OS Release 11.4 and configure logical systems, the 

master logical system retains any previously-configured zone-defined address book 

configuration. The master administrator can run the address book upgrade script to 

convert the existing zone-defined configuration to the zone-attached configuration. 

The upgrade script converts all zone-defined configurations in the master logical system 

and user logical systems. 

NOTE: You cannot run the downgrade script on logical systems. 

For information about implementing and executing Junos operation scripts, see the Junos 

OS Configuration and Operations Automation Guide. 


413









the currently installed EEOL release, or to two EEOL releases before or after. For example, 

Junos OS Releases 10.0, 10.4, and 11.4 are EEOL releases. You can upgrade from Junos OS 

Release 10.0 to Release 10.4 or even from Junos OS Release 10.0 to Release 11.4. However, 

you cannot upgrade directly from a non-EEOL release that is more than three releases 

ahead or behind. For example, you cannot directly upgrade from Junos OS Release 10.3 

(a non-EEOL release) to Junos OS Release 11.4 or directly downgrade from Junos OS 

Release 11.4 to Junos OS Release 10.3. 


before or after, first upgrade to the next EEOL release and then upgrade or downgrade 

from that EEOL release to your target release. 

For more information about EEOL releases and to review a list of EEOL releases, see 


Upgrade Policy for Junos OS Extended End-Of-Life Releases 

An expanded upgrade and downgrade path is now available for the Junos OS 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 OS Releases 9.3, 10.0, and 10.4 are all EEOL releases. You can upgrade 

from Junos OS 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 OS Release 9.3 or 10.0, and then upgrade a second 

time to 10.4. Similarly, you can downgrade directly from Junos OS 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. 



Hardware Requirements for Junos OS Release 11.4 for SRX Series Services 


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 

414 



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 23 on page 415 lists the USB and CompactFlash card devices supported for use 

with the J Series Services Routers. 

Table 23: Supported Storage Devices on the J Series Services Routers 

Manufacturer 

Storage Capacity 

Third-Party Part Number 

SanDisk—Cruzer Mini 2.0 

256 MB 

SDCZ2-256-A10 

SanDisk 

512 MB 

SDCZ3-512-A10 

SanDisk 

1024 MB 

SDCZ7-1024-A10 

Kingston 

512 MB 

DTI/512KR 


415


Table 23: Supported Storage Devices on the J Series Services 

Routers (continued) 

Manufacturer 

Storage Capacity 

Third-Party Part Number 

Kingston 

1024 MB 

DTI/1GBKR 

SanDisk—ImageMate USB 2.0 

Reader/Writer for CompactFlash Type I 

and II 

N/A 

SDDR-91-A15 

SanDisk CompactFlash 

512 MB 

SDCFB-512-455 

SanDisk CompactFlash 

1 GB 

SDCFB-1000.A10 

J Series CompactFlash and Memory Requirements 

Table 24 on page 416 lists the CompactFlash card and DRAM requirements for J Series 

Services Routers. 

Table 24: J Series CompactFlash Card and DRAM Requirements 

Model 

Minimum CompactFlash 

Card Required 

Minimum DRAM 

Required 

Maximum DRAM 

Supported 

J2320 

1 GB 

1 GB 

1 GB 

J2350 

1 GB 

1 GB 

1 GB 

J4350 

1 GB 

1 GB 

2 GB 

J6350 

1 GB 

1 GB 

2 GB 

Related 

Documentation 







416 


Junos OS Release Notes for High-End SRX Series Services Gateways 

Junos OS Release Notes for High-End SRX Series Services Gateways 

Powered by Junos OS, Juniper Networks high-end SRX Series Services Gateways provide 

robust networking and security services. They are designed to secure enterprise 

infrastructure, data centers, and server farms. The high-end SRX Series Services Gateways 

include the SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices. 

• New Features in Junos OS Release 11.4 for High-End SRX Series Services 

Gateways on page 417 

• Changes in Default Behavior and Syntax in Junos OS Release 11.4 for High-End SRX 

Series Services Gateways on page 436 

• Known Limitations in Junos OS Release 11.4 for High-End SRX Series Services 


• Outstanding Issues in Junos OS Release 11.4R7 for High-End SRX Series Services 


• Resolved Issues in Junos OS Release 11.4 for High-End SRX Series Services 


• Errata and Changes in Documentation for Junos OS Release 11.4 for High-End SRX 


• Upgrade and Downgrade Instructions for Junos OS Release 11.4 for High-End SRX Series 

Services Gateways on page 489 

New Features in Junos OS Release 11.4 for High-End SRX Series Services Gateways 



NOTE: For the latest updates about support and issues on Junos Pulse, see 

the Junos Pulse Release Notes at 

http://www.juniper.net/techpubs/en_US/junos-pulse1.0/information-products/ 

pathway-pages/junos-pulse/index.html . 





• Software Features on page 424 



• Network Address Translation support port mapping for static NAT—This feature is 

supported on all high-end SRX Series devices. 


417


Network Address Translation (NAT) now provides destination-port low to high and 

mapped-port low to high statements to allow static NAT to map ports as follows: 

• To map multiple IP addresses to the same IP addresses on a specified range of ports 

• To map a specific IP address and port to a different IP address and port 

Examples of configuring static NAT with port mapping: 





to 400 





to 400 


set security nat static rule-set rs from zone trust rule r3 destination-port 300 




• VPN session affinity—This feature is supported on SRX3400, SRX3600, SRX5600, 


VPN session affinity occurs when a clear-text session is located in a Services Processing 

Unit (SPU) that is different from the SPU where the IPsec tunnel session is located. 

The goal of VPN session affinity is to locate the clear-text and IPsec tunnel session in 

the same SPU. 

Without VPN session affinity, a clear-text session created by a flow might be located 

in one SPU and the tunnel session created by IPsec might be located in another SPU. 

An SPU to SPU forward or hop is needed to route clear-text packets to the IPsec tunnel. 

By default, VPN session affinity is disabled on SRX Series devices. Enabling VPN session 

affinity causes a clear-text session to be placed on the same SPU as the IPsec tunnel 

session. 

Enabling VPN session affinity can improve VPN throughput under the following traffic 

conditions: 

• A number of IPsec tunnels are needed and they are distributed evenly among SPUs. 

If IPsec tunnels are already concentrated on several SPUs, then enabling VPN session 

affinity allows all clear-text SPUs to also use those SPUs. This can cause those SPUs 

to be overutilized while other SPUs might be underutilized. 

To display active tunnel sessions on SPUs, use the show security ipsec 

security-association command and specify the Flexible PIC Concentrator (FPC) and 

Physical Interface Card (PIC) slots that contain the SPU. For example: 

user@host> show security ipsec security-association fpc 3 pic 0 

Total active tunnels: 1 

ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway 

418 



131073 ESP:aes-128/sha1 188c0750 491/ 128000 - root 500 23.0.21.11 

• Clear-text sessions passing through the tunnels should be at the highest volume for 

the longest periods of time as possible. Applying VPN session affinity to clear-text 

sessions of small volumes and short periods (for example, DNS sessions) will not 

improve VPN throughput. 

NOTE: You need to evaluate the tunnel distribution and traffic patterns in 

your network to determine if VPN session affinity should be enabled. 

The VPN session affinity limitations are as follows: 

• Multicast traffic is not supported. 

• Traffic across logical systems is not supported. 

• VPN session affinity does not operate on a hub in a hub-and-spoke topology. 

• If there is a route change, established clear-text sessions remain on an SPU and 

traffic is rerouted if possible. Sessions created after the route change may be set up 

on a different SPU. 

• VPN session affinity only affects self traffic that terminates on the device (also 

known as host-inbound traffic); self traffic that originates from the device (also 

known as host-outbound traffic) is not affected. 

• VPN session affinity can be enabled on an SRX1400 device; however, because the 

device only has one SPU there is no affect on VPN throughput. 

Enabling VPN Session Affinity—By default, VPN session affinity is disabled on SRX 

Series devices. Enabling VPN session affinity can improve VPN throughput under certain 

conditions. This section describes how to use the CLI to enable VPN session affinity. 

Determine if clear-text sessions are being forwarded to IPsec tunnel sessions on a 

different SPU. Use the show security flow session command to display session 

information about clear-text sessions. 

user@host> show security flow session 

Flow Sessions on FPC3 PIC0: 

Session ID: 60000001, Policy name: N/A, Timeout: N/A, Valid 

In: 23.0.21.11/6204 --> 23.0.21.6/41264;esp, If: ge-0/0/2.0, Pkts: 0, Bytes: 0 



Session ID: 60000003, Policy name: self-traffic-policy/1, Timeout: 58, Valid 

In: 23.0.21.6/500 --> 23.0.21.11/500;udp, If: .local..0, Pkts: 105386, Bytes: 12026528 

Out: 23.0.21.11/500 --> 23.0.21.6/500;udp, If: ge-0/0/2.0, Pkts: 106462, Bytes: 12105912 

Session ID: 60017354, Policy name: N/A, Timeout: 1784, Valid 

In: 0.0.0.0/0 --> 0.0.0.0/0;0, If: N/A, Pkts: 0, Bytes: 0 

Out: 26.0.20.156/23 --> 22.0.20.155/53051;tcp, If: N/A, Pkts: 0, Bytes: 0 


419


Total sessions: 4 






Session ID: 120031730, Policy name: default-policy-00/2, Timeout: 1764, Valid 

In: 22.0.20.155/53051 --> 26.0.20.156/23;tcp, If: ge-0/0/1.0, Pkts: 44, Bytes: 2399 

Out: 26.0.20.156/23 --> 22.0.20.155/53051;tcp, If: st0.0, Pkts: 35, Bytes: 2449 


In the example, there is a tunnel session on FPC 3, PIC 0 and a clear-text session on 

FPC 6, PIC 0. A forwarding session (session ID 60017354) is set up on FPC 3, PIC 0. 

To enable VPN session affinity: 

1. In configuration mode, use the set command to enable VPN session affinity. 

[edit] 

user@host# set security flow load-distribution session-affinity ipsec 

2. Check your changes to the configuration before committing. 

[edit] 

user@host# commit check 


[edit] 


After enabling VPN session affinity, use the show security flow session command to 

display session information about clear-text sessions. 

user@host> show security flow session 






Session ID: 60000003, Policy name: self-traffic-policy/1, Timeout: 56, Valid 

In: 23.0.21.6/500 --> 23.0.21.11/500;udp, If: .local..0, Pkts: 105425, Bytes: 12031144 

Out: 23.0.21.11/500 --> 23.0.21.6/500;udp, If: ge-0/0/2.0, Pkts: 106503, Bytes: 

12110680 

Session ID: 60017387, Policy name: default-policy-00/2, Timeout: 1796, Valid 

In: 22.0.20.155/53053 --> 26.0.20.156/23;tcp, If: ge-0/0/1.0, Pkts: 10, Bytes: 610 

Out: 26.0.20.156/23 --> 22.0.20.155/53053;tcp, If: st0.0, Pkts: 9, Bytes: 602 



420 








After VPN session affinity is enabled, the clear-text session is always located on FPC 

3, PIC 0. 

CLI Reference Information 

load-distribution 

• Syntax 

session-affinity ipsec 

• Hierarchy Level 

[edit security flow load-distribution] 

• Release Information 

Statement introduced in Junos OS Release 11.4R5. 

• Description 

Enable VPN session affinity. 

• Required Privilege Level 

security—To view this statement in the configuration. 

security-control—To add this statement to the configuration. 

session-affinity 

• Syntax 

session-affinity ipsec 

• Hierarchy Level 

[edit security flow load-distribution] 

• Release Information 

Statement introduced in Junos OS Release 11.4R5. 

• Description 

Enable VPN session affinity. 

• Required Privilege Level 

security—To view this statement in the configuration. 

security-control—To add this statement to the configuration. 


421



For the 11.4R4 release, images for high-end SRX Series services gateways will not be 

available on the public download site. 


For information about the following 11.4R3 new features, please see New Features in Junos 

OS 11.4R3: 

• IMSI Filter Length Extension—This feature is supported on all high-end SRX Series 

devices. 

• IPv6 Flows in Transparent Mode—This feature is supported on SRX3400, SRX3600, 

SRX5600, and SRX5800 devices. 

• Increase In the Maximum Sessions Allowed For a Persistent NAT Binding Overview—This 

feature is supported on all SRX Series devices. 

• SRX Series Chassis Cluster SPC Insert—This feature is supported on SRX3400, 


• VPN Support for Inserting Services Processing Cards—This feature is supported on 


• VPN Debugging Improvements—This feature is supported on all SRX Series devices. 

• VPN module hardening and stability improvements – These enhancements are 

applicable on all SRX Series devices. 

422 





• High-priority queue on SPC—This feature is supported on all high-end SRX Series 

devices. 

Release 11.4R2 provides a configuration option to enable packets with specific 

Differentiated Services (DiffServ) code points (DSCP) precedence bits to enter a 

high-priority queue on the Services Processing Card (SPC) on high-end SRX Series 

devices. The Services Processing Unit (SPU) draws packets from the high-priority 

queue and only draws packets from the low-priority queue when the high-priority queue 

is empty. This feature can reduce overall latency for real-time traffic, such as voice 

traffic. 

To designate packets for the high-priority or low-priority queues, use the spu-priority 

configuration statement at the [edit class-of-service forwarding-classes class] hierarchy 

level. A value of high places packets into the high-priority queue, and a value of low 

places packets into the low-priority queue. 


• IDP policy compilation improvements—This feature is supported on all high-end SRX 

Series devices with IDP enabled. 

The IDP policy compilation process has been optimized to use less memory and compile 

faster. Policies that were too large to compile on smaller platforms running earlier 

Junos OS releases may compile successfully on this release. 

J-Web 

• Application Tracking—This feature is supported on all high-end SRX Series devices. 

The Application tracking feature is used to monitor sessions and bytes of a particular 

application or application group. The following page has been added to the J-Web 

user interface: 

• Application Tracking 

• Security Logging—This feature is supported on all high-end SRX Series devices. 

The following page has been added to the J-Web user interface: 


423


• Security Logging 

Software Features 

AppSecure 

• Application-aware quality of service (AppQoS )—This feature is supported on 


AppQoS, the application-aware quality-of-service module in AppSecure, provides a 

mechanism for prioritizing traffic utilizing the results of the Application Identification 

Engine. AppQoS provides application-level traffic control for administrators needing 

to ensure that business critical applications get preferential treatment. 

AppQoS enables the network administrator to meter, mark, and honor traffic priority 

based on application policies. It provides application-aware DSCP marking by 

implementing Layer-7 application-based DSCP rewriters. To apply different loss priority 

levels to different traffic groups, Layer 2- to Layer 4-based honoring has been expanded 

to Layer 7. AppQoS accomplishes application-aware rate limiting by setting the 

bandwidth limit and burst size limit for different applications. 


• Application groups—This feature is supported on SRX1400, SRX3400, SRX3600, 


SRX Series devices allow consolidation of applications under a single group name. 

Predefined application groups are downloaded as part of the application signature 

database. User-defined groups can be created and deleted. 


• Application group support for application firewall (AppFW)—This feature is supported 


SRX Series devices allow you to configure application firewall policies using application 

group names. Application group names provide simplified, consistent reuse when 

defining application firewall policies. 


• Application signature management and usability enhancements—This feature is 

supported on SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices. 

Juniper Networks provides improvements in the usability and management of predefined 

application signatures available through the Junos OS application signature package 

subscription service. 

• Previously, predefined application signature updates were downloaded to the Junos 

OS configuration file, resulting in an unnecessarily large file. To improve usability, 

application signature updates are now downloaded and installed in a separate 

application signature database on SRX1400, SRX3400, SRX3600, SRX5600, and 


• Using CLI commands, users can manage predefined and custom application 

signatures and application signature groups, as follows: 

424 



• View detailed and summary information. 

• Copy, disable, and enable predefined application signatures for maximum flexibility 

in the use and reuse of predefined application signatures and custom application 

signatures. 

• Create custom application signatures by copying a predefined application signature 

and using it as a template. 

• CLI services application-identification commands provide more options for the display 

and configuration of custom application signatures and application signature groups. 

• A new option insert-before customer-signature-name has been added to allow you 

to move a custom application signature before a specific predefined application 

signature or another custom application signature. 



• Nested application identification enhancement—This feature is supported on 


New application identification contexts have been added for more extensive nested 

application matching. 

Several new HTTP contexts have been added for application detection: 

• http-get-url-parsed-param-parsed 

• http-post-url-parsed-param-parsed 

• http-post-variable-parsed 

• http-header-user-agent 

• http-header-cookie 

An SSL context is now supported that identifies a server name in a client or server hello 

message. 

• ssl-server-name 


• Onbox application tracking statistics for AppTrack—This feature is supported on 


This feature adds application-level statistics to the AppSecure suite. Application 

statistics allow an administrator to access cumulative statistics as well as statistics 

accumulated over user-defined intervals. The administrator can clear the statistics 

and configure the interval values. 

Bytes and session count statistics are maintained. Because the statistics count occurs 

at AppTrack session close event time, the byte and session counts are not updated 

until the session closes. 

SRX Series devices support a history of 8 intervals that an administrator can use to 

display the application session and byte counts. 


425




• Central point session scaling—This feature is supported on SRX5800 devices only. 

The central point was optimized to increase the total number of central point sessions 

to 20 million IPv4 sessions or 10 million IPv6 sessions. This optimization trades 

maximum attainable connections per second (CPS) for maximum number of central 

point sessions. 


• Global policy—This feature is supported on SRX1400, SRX3400, SRX3600, SRX5600, 


Unlike other security policies, global policies do not reference specific source and 

destination zones (from-zone and to-zone). Global policies allow you to regulate traffic 

with addresses and applications, regardless of their security zones. Global policies 

reference user-defined addresses or the predefined address “any.” These addresses 

can span multiple security zones. 


• Services offloading—This feature is supported on SRX1400, SRX3400, SRX3600, 


Services offloading is a mechanism for processing fast-path packets in the network 

processor instead of in the Services Processing Unit (SPU). This method reduces the 

long packet processing latency that arises when packets are forwarded from network 

processors to SPUs for processing and back to I/O cards (IOCs) for transmission. 

Services offloading considerably reduces packet processing latency by 500–600 

percent. 

When the first packet arrives at the interface, the network processor forwards it to the 

SPU. If the SPU verifies that the traffic is qualified for services offloading, a 

services-offload session is created on the network processor. If the traffic does not 

qualify for services offloading, a normal session is created on the network processor. 

If a services-offload session is created, the subsequent fast-path packets are processed 

in the network processor itself. 

NOTE: A normal session forwards packets from the network processor to 

the SPU for fast-path processing, while a services-offload session processes 

fast-path packets in the network processor and the packets exit out of the 

network processor itself. 

When a services-offload session is created on the network processor, subsequent 

packets are matched with the session. The network processor then processes and 

forwards the packets based on the session information, such as TCP sequence check, 

time to live (TTL) processing, Network Address Translation (NAT), and Layer 2 header 

translation. 


426 



General Packet Radio Service (GPRS) 

• GPRS tunneling protocol version 2 (GTPv2)—This feature is supported on SRX1400, 


GPRS tunneling protocol (GTP) establishes a GTP tunnel between a Serving GPRS 

Support Node (SGSN) and a Gateway GPRS Support Node (GGSN) for individual 

Mobile Stations (MS). Both GTP version 0 (GTPv0) and GTP version 1 (GTPv1) are 

implemented using SGSNs and GGSNs only. However, in GTPv2 the traditional SGSNs 

and GGSNs are replaced by three logical nodes—a serving gateway (SGW), a packet 

data network gateway (PGW), and a mobility management entity (MME). 

You can enable GTPv2 by using the following CLI configuration statement: 

set security gprs gtp enable 

After configuring the above statement, you must reboot the device for GTPv2 inspection 

to take effect. To disable GTPv2, delete the security gprs gtp enable configuration 

statement from the device. 

NOTE: All GTPv2 features are supported on the device only if the security 

gprs gtp enable command is configured on the device. 

You can use the show security gprs gtp tunnels operational mode command to display 

details about the existing GTPv2 tunnels configured on the device. 

NOTE: IPv6 GTPv2 and GTPv2 for logical systems are not supported in 

Junos OS Release 11.4. 


Intrusion Detection and Prevention (IDP) and AppSecure 

• IDP and application identification support for jumbo frames—This feature is supported 


The Intrusion Detection and Prevention (IDP) and application identification security 

features support the larger jumbo frame size of 9192 bytes. Although jumbo frames 

are enabled by default, you can adjust the maximum transmission unit (MTU) size by 

using the set interfaces command. 

For logging purposes, the total number of packets captured relative to an IDP attack 

will decrease due to the larger packet size in a jumbo frame. The default value is five 

packets before and five packets after the packet on which an IDP attack is identified. 


427


NOTE: Although CPU overhead can be reduced while processing jumbo 

frames, the IDP feature itself requires a minimum of 5 MB of memory for 

session inspection. If the required memory is not available, IDP will not 

inspect the applicable sessions. You can view IDP data plane memory by 

using the show security idp memory command. 



• IDP attack description—This feature is supported on SRX1400, SRX3400, SRX3600, 

SRX5600, and SRX5800 devices for both J-Web and the CLI. 

The IDP attack description feature enables users to use the CLI to learn more about 

IDP attack objects. Currently, users view IDP attack objects in the 

/var/db/idpd/sec-download/SignatureUpdate.xml file, which makes it difficult for 

users to investigate and manage IDP attack objects. Users can quickly and easily 

administer IDP attack objects when the details are displayed through the CLI. 

You can use the show security idp attack description and the show security idp attack 

detail operational mode commands to display details about IDP attack objects. 

[Junos OS CLI Reference] 

IPv6 Support 

• Junos OS application identifiction—This feature is supported on SRX1400, SRX3400, 


Application firewall was previously supported in the IPv4 environment. Beginning with 

Junos OS Release 11.4, it is also supported on IPv6. 

SRX Series devices provide additional security protection against known dynamic 

applications that can send traffic that might not be adequately controlled by standard 

network firewall policies. The application firewall functionality enforces policies based 

on the results of the application identification process. The application identification 

process identifies applications using pattern matching, protocol decoding, and heuristics. 

To implement application firewall support: 

• Network security policy–Modify the policy configuration to support the application 

firewall rule set within the existing configuration. 

• Application firewall rule set–Define an application firewall rule set to be referenced 

by the network security policy. 


• Web authentication—This feature is supported on SRX1400, SRX3400, SRX3600, 


Web authentication now supports IPv6 addresses. 


428 



• Firewall authentication—This feature is supported on SRX1400, SRX3400, SRX3600, 


Firewall authentication now supports IPv6 addresses. 


J-Web 

• Customer branding of firewall authentication webpage —This feature is supported 


Juniper Networks enables the administrator to replace the embedded Juniper Networks 

logo present on the firewall authentication webpage with a customer graphic. It also 

provides the ability to create a different logo for different logical systems. 

• AppQoS monitoring—This feature is supported on SRX1400, SRX3400, SRX3600, 

SRX5600, and SRX5800 devices 

A new Application QoS Monitoring J-Web page allows you to view counters and 

statistics for AppQoS activity. The rate limiters statistics pane displays transfer rate 

information for recent traffic per PIC. The rules statistics pane displays the amount of 

traffic on each PIC broken down by the rule set and rule applied to each session. 

Counters for selected rule-sets display AppQoS session activity per PIC. 

• IDP monitoring—This feature is supported on SRX1400, SRX3400, SRX3600, SRX5600, 

and SRX5800 Services Gateways. 


• Attacks Monitoring page 

• Applications Monitoring page 

• IDP performance in J-Web—IDP performance in J-Web has been improved for SRX1400, 


Logical Systems 

• The logical systems feature is now supported on SRX1400 devices in addition to existing 

support on SRX3400, SRX3600, SRX5600, and SRX5800 devices. 

[Junos OS Logical Systems Configuration Guide for Security Devices] 

• J-Web user and interconnect logical systems configuration—This feature is supported 


When you are logged in to the device as the master administrator, you can configure 

logical systems on the Logical System Configuration page. The Logical System 

Information page displays information about the logical systems configured on the 

device. 

When you are logged in to the device as a user logical system administrator, the 

following tabs are available to you: 

• Dashboard tab—Displays the resources allocated to the logical system. 


429


• Configure tab—Allows you to configure interfaces, NAT, and security features for 

the user logical system. 

• Monitor tab—Allows you to monitor the configured features of the user logical system. 

• CPU usage allocation and control—This feature is supported on SRX1400, SRX3400, 


In Junos OS Release 11.4, the master administrator can configure and control CPU 

utilization by logical systems. The master administrator enables CPU utilization control 

with the cpu-control configuration statement at the [edit system security-profile 

resources] hierarchy level. 

When CPU utilization control is enabled, the master administrator can configure the 

following CPU utilization parameters: 

• Reserved quota of CPU utilization, in percent, is specified for each logical system. 

The reserved quota guarantees that a specified percentage of the CPU is always 

available to the logical system. The master administrator specifies the reserved CPU 

quota in a logical system security profile with the cpu reserved configuration 

statement at the [edit system security-profiles profile-name] hierarchy level. The 

security profile is applied to one or more logical systems. 

If CPU control is enabled and reserved CPU quotas are not configured, the default 

reserved quota for the master logical system is 1 percent and the default reserved 

quota for user logical systems is 0 percent. 

• CPU control target is the upper limit, in percent, for CPU utilization under normal 

operating conditions. If the overall CPU utilization surpasses the configured target 

value, the Junos OS software initiates controls to bring CPU utilization between the 

target value and 90 percent of the target value. During runtime, CPU utilization by 

each logical system is measured every two seconds. Dropping packets is used to 

reduce the CPU usage for a particular logical system. If the CPU usage of a logical 

system exceeds its quota, CPU utilization control drops the packets received on that 

logical system. The packet rate is calculated every two seconds based on CPU 

utilization of all logical systems. 

The master administrator configures the CPU control target with the 

cpu-control-target configuration statement at the [edit system security-profile 

resources] hierarchy level. The default CPU control target is 80 percent. 

The sum of the reserved CPU quotas for all logical systems on the device must be less 

than 90 percent of the CPU control target; the difference is a shared CPU resource 

that can be allocated among the logical systems that need additional CPU allocation. 

The actual CPU quota that a single logical system can use is the sum of its reserved 

CPU quota and its portion of the shared CPU resource. 


• VPN tunnel—This feature is supported on SRX1400, SRX3400, SRX3600, SRX5600, 


This feature allows the master logical system and a user logical system to share a VPN 

tunnel in a route-based VPN. The master administrator must assign the security tunnel 

430 



(st0) interface to a user logical system. The master administrator configures IKE and 

IPsec SA parameters at the root level. The user logical system administrator can change 

the attributes of the st0 interface. To send traffic into the tunnel, the user logical system 

administrator configures a security policy to permit traffic to a remote destination and 

a route with the st0 as the next hop. 

NOTE: Only route-based VPNs are supported for logical systems. 

Policy-based VPNs are not supported. 

The master administrator assigns an st0 interface to a user logical system with the 

st0 unit number configuration statement at the [edit logical-systems name interfaces] 

hierarchy level. The master administrator configures IKE and IPsec in the master logical 

system with the VPN configuration at the [edit security ipsec] hierarchy level. VPN 

monitoring can be configured by the master administrator at the root level. For the 

VPN monitor source interface, the master administrator must specify the st0 interface; 

a physical interface for a user logical system cannot be specified. 

The user logical system administrator can set attributes for the st0 interface, such as 

an IP address, at the [edit interfaces st0 unit number] hierarchy level. The user logical 

system administrator configures security policies with the policy configuration statement 

at the [edit security policies from-zone zone to-zone zone] hierarchy level and static 

routes with the static route configuration statement at the [edit routing-options] 



• IDP—This feature is supported on SRX1400, SRX3400, SRX3600, SRX5600, and 


This feature allows the master administrator to configure IDP policies for user logical 

systems. The master administrator can create one or more IDP policies at the root 

level using intrusion prevention system (IPS) or application-level distributed 

denial-of-service (DDoS) rulebases. The master administrator specifies the IDP policy 

in a logical system security profile that is bound to one or more user logical systems. 

NOTE: In Junos OS Release 11.4, user logical system administrators cannot 

create or modify IDP policies for their user logical systems. Only the master 

administrator can create IDP policies. 

A single IDP security package is installed on the device for all logical systems. An idp-sig 

license must be installed at the root level. 

The master administrator configures an IDP policy at the root level using the idp-policy 

configuration statement at the [edit security idp] hierarchy level. To specify the IDP 

policy in a logical system security profile, the master administrator uses the idp-policy 

configuration statement at the [edit system security-profile profile-name] hierarchy 

level. 



431


• IPv6 addresses in logical systems—This feature is supported on SRX1400, SRX3400, 


In Junos OS Release 11.4, IPv6 addresses can be configured in logical systems for the 

following features: 

• Interfaces 

• Flows 

• Zones and security policies 

• Screen options 

• Network address translation (except for interface NAT) 

• Administrative operations with telnet, ssh, https, and other utilities 

• Chassis clusters 


• Logical system name in security logs—This feature is supported on SRX1400, 


Security logs are system log messages that include security events. If a device is 

configured for logical systems, security logs generated within the context of a logical 

system use the name logname_LS (for example, IDP_ATTACK_LOG_EVENT_LS). The 

logical system version of a log has the same set of attributes as the log for devices that 

are not configured for logical systems, but it also includes logical-system-name as the 

first attribute. If a device is configured for logical systems, log parsing scripts might 

need to be modified because the log name includes the _LS suffix and the 

logical-system-name attribute can be used to segregate logs by logical system. 

If a device is not configured for logical systems, the security logs remain unchanged 

and scripts built to parse logs do not need any modification. 

NOTE: Only the master administrator can configure logging at the [edit 

security log] hierarchy level. User logical system administrators cannot 

configure logging for their logical systems. 


• Data path debugging for traffic between logical systems—This feature is supported 


Data path debugging provides tracing and debugging at multiple processing units along 

the packet-processing path. Data path debugging can also be performed on traffic 

between logical systems. Only the master administrator can configure data path 

debugging for logical systems at the [edit security datapath-debug] hierarchy level. 

User logical system administrators cannot configure data path debugging for their 

logical systems. 

When tracing is configured for the jexec event type, the trace output contains logical 

system information. The master administrator can also configure tracing for traffic 

432 



between logical systems by specifying the lt-enter and lt-leave event types. The trace 

output shows traffic entering and leaving the logical tunnel between logical systems. 

The preserve-trace-order option can be configured to sort the output chronologically. 

In addition to the trace action, other actions such as packet-dump and packet-summary 

can be configured for the lt-enter and lt-leave events. 


• Multicast traffic—This feature is supported on SRX1400, SRX3400, SRX3600, 


Multicast is a “one source, many destinations” method of traffic distribution, meaning 

that the destinations needing to receive the information from a particular source receive 

the traffic stream. In Junos OS Release 11.4, the master and user logical system 

administrators can configure a logical system to support multicast applications. The 

same multicast configurations to configure a device as a node in a multicast network 

can be used in a logical system. 

[Junos OS Routing Protocols and Policies Configuration Guide for Security Devices] 

• Application firewall support on logical systems—This feature is supported on 


The Juniper Networks application firewall enables administrators of logical systems 

to create security policies for traffic based on the results of the application identification 

engine. The application firewall policy provides additional security protection against 

dynamic application traffic that might not be adequately controlled by standard 

network firewall policies. 

Configuring an application firewall policy on a logical system is the same process as 

configuring an application firewall policy on a device that is not configured with logical 

systems. However, the application firewall policy applies only to the logical system for 

which it is configured. The master administrator can configure, enable, and monitor 

application firewall policies on the master logical system and all user logical systems 

on a device. The user logical system administrators can configure, enable, and monitor 

an application firewall policy only on the user logical systems for which they have 

access. 

To implement this feature: 

• Network security policy—The master administrator defines a security profile and 

allocates a number of system resources for use by logical systems on the device. In 

this case, the application firewall resources (appfw-rule-set and appfw-rule) are 

added to the security profile, and the security profile is bound to a logical system. 

The master administrator and user logical system administrators add the application 

firewall configuration to the security policy for their respective logical systems. 

• Application firewall—The master administrator and user logical system administrators 

configure and manage application firewall rule sets and rules for their respective 

logical systems. 



433



• Configurable capacity for source NAT pools with PAT—On SRX1400, SRX3400, 

SRX3600, SRX5600, and SRX5800 devices, the capacity of source NAT pools and IP 

addresses has been increased to support more users. When Port Address Translations 

(PAT) are set for each IP address, automatic checks ensure memory limits are not 

exceeded. 

[Junos OS Security Configuration Guide, Junos OS CLI Reference] 

Security 

• GTP IE removal—This feature is supported on SRX1400, SRX3400, SRX3600, 


The multiple versions of the Third-Generation Partnership Project (3GPP) create 

interoperability problems in the mobile network. Junos OS Release 11.4 supports removal 

of R7, R8, and R9 information elements (IEs) of the GTPv1 messages, which allows 

you to retain interoperability. 


• Aggressive session aging—This feature is supported on SRX1400, SRX3400, SRX3600, 


The aggressive session aging mechanism accelerates the session timeout process 

when the number of sessions in the session table exceeds a specified high-watermark 

threshold. This minimizes the likelihood of the SRX Series devices rejecting new sessions 

when the session table is full. 


• EZchip low latency—This feature is supported on SRX1400, SRX3400, SRX3600, 


The high-end SRX Series devices currently have long packet-processing latency because 

of packet processing through the Services Processing Unit (SPU) and through several 

stages of buffers in the data path. 

This feature introduces a local forwarding solution where the fast-path packets are 

processed by the EZchip on the I/O Card (IOC), without going through the switch fabric 

or the SPU. This solution reduces latency. The user needs to have a permanent 

low-latency firewall license to enable this feature on the chassis. 


• Security policies for self-traffic—This feature is supported on SRX1400, SRX3400, 


Users can now configure security policies for the self-traffic (the host inbound traffic 

or the host outbound traffic) of the device. The user can further apply relevant services 

to the new self-traffic policy. 

The security policies for the self-traffic are configured under the new default security 

zone called junos-host zone. 


434 



SNMP 

• Juniper Networks enterprise-specific License MIB—This feature is supported on 

SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices. This feature extends 

SNMP support for licensing information. 

The enterprise-specific License MIB: 

• Contains information about license features and the expiration details to reduce the 

burden involved in managing licenses. 

• Generates traps to alert users. For example, an alert is generated when a license 

expires or when the total number of users exceeds the maximum number specified 

in the license. 

• Provides access to license-related information through the SNMP get and get-next 

operations. 

[Junos OS SNMP MIBs and Traps Reference; MIB Reference for SRX1400, SRX3400, and 

SRX3600 Services Gateways; MIB Reference for SRX5600 and SRX5800 Services 

Gateways] 


• Internet Key Exchange version 2(IKEv2)—This feature is supported on SRX1400, 


IKEv2 is the next-generation standard for secure key exchange between peer devices, 

defined in RFC 4306. IKEv2 is available in Junos OS Release 11.4, for securing IPsec 

traffic. The initial release does not support all the capabilities described in the RFCs. 

The advantages of using version 2 over version 1 are as follows; 

• Simplifies the existing IKEv1 

• Single RFC, including NAT-T, EAP and remote address acquisition 

• Replaces the 8 initial exchanges with a single 4-message exchange 

• Reduces the latency for the IPsec SA setup and increases connection establishment 

speed 

• Increases robustness against DoS attack 

• Improves reliability through the use of sequence numbers, acknowledgements, and 

error correction 

• Provides forward compatibility 

• Provides simple cryptographic mechanisms 

IKEv2 includes support for: 

• Route-based VPN 

• Site-to-site VPN 

• Dead peer detection (liveness check) 


435


• Chassis cluster 

• Certificate-based authentication 

• Hardware offloading of the ModExp operations in a Diffie-Hellman (DH) exchange 

• IKE and child SA rekeying—In IKEv2, a child security association (SA) cannot exist 

without the underlying IKE SA. If a child SA is required, it will be rekeyed; however, if 

the child SAs are currently active, the corresponding IKE SA will be rekeyed. 

• IKE version 1 and IKE version 2 


• Site-to-site VPN support for NAT-T—This feature is supported on SRX1400, SRX3400, 


Site-to-site IKE gateway configuration for Network Address Translation-Traversal 

(NAT-T) is now supported on the server side (IKE responder). This is in addition to the 

current implementation of NAT-T support for dynamic IKE gateway configuration. A 

remote-identity value is used to validate a peer’s ike-id or id during Phase 1 of IKE tunnel 

negotiation. 


Related 

Documentation 



• Resolved Issues in Junos OS Release 11.4 for High-End SRX Series Services Gateways 

on page 459 





• Known Limitations in Junos OS Release 11.4 for High-End SRX Series Services Gateways 

on page 443 

Changes in Default Behavior and Syntax in Junos OS Release 11.4 for High-End SRX Series 

Services Gateways 

The following current system behavior, configuration statement usage, and operational 

mode command usage might not yet be documented in the Junos OS documentation: 

AppSecure Application Package Upgrade Changes 

• On all high-end SRX Series devices, application tracking is enabled by default. You can 

disable application tracking with the set security application-tracking disable command. 

This command disables application tracking without deleting the zone configuration. 

• Application signatures removed after upgrading to Junos OS Release 11.4—This 

change applies to all high-end SRX Series devices that use the application identification 

signature package. 

436 


Changes in Default Behavior and Syntax in Junos OS Release 11.4 for High-End SRX Series Services Gateways 

In Junos OS Release 11.4, the application signature package is downloaded and installed 

in a separate database, not in the Junos OS configuration file as in previous Junos OS 

releases. 

When you upgrade an SRX Series device from Junos OS Release 11.2 to Junos OS 

Release 11.4, any predefined application signatures and signature groups from the 

Junos OS Release 11.2 configuration will be removed when you install the latest 

predefined signatures and signature groups by using the request services 

application-identification install command. However, the upgrade will not remove 

custom signatures and signature groups from the Junos OS configuration. 

For information about using the request services application-identification download 

and request services application-identification install commands, see the Junos OS 

CLI Reference. 


• On all high-end SRX Series devices, the set chassis fpc pic 

services-offload command is not available for configuration and, as a consequence, 

the devices cannot be used in services-offload mode. 


• In Junos OS Release 11.2 and 11.4 the set security zone security-zones tcp-rst 

command in the CLI Help displays an incorrect description as: 

tcp-rst—Send RST for TCP SYN packet not matching session 

The correct description is: 

tcp-rst—Send RST for NON-SYN packet not matching TCP session 

Deprecated Items for High-End SRX Series Services Gateways 

Table 25 on page 437 lists deprecated items (such as CLI statements, commands, options, 

and interfaces). 

CLI statements and commands are deprecated—rather than immediately removed—to 

provide backward compatibility and a chance to bring your configuration into compliance 

with the new configuration. We strongly recommend that you phase out deprecated 

items and replace them with supported alternatives. 

Table 25: Items Deprecated in Release 11.4R2 

Deprecated 

Item 

Replacement 




mcc-mnc 

imsi-prefix 

edit security gprs gtp profile 

profile-name apn 

pattern-string 

On all high-end SRX Series 

devices, the following 

mcc-mnc command is not 

supported. 


437


Table 25: Items Deprecated in Release 11.4R2 (continued) 

Deprecated 

Item 

Replacement 




download-timeout 

- 

download-timeout timeout 

On all high-end SRX Series 

devices, download-timeout 

command is deprecated 

and if the configuration is 

present, it will be ignored. 

The idpd daemon 

internally triggers 

security-package to install 

when an automatic 

download completes. 

There is no need to 

configure any 

download-timeout. 


• The minimum value you can configure for TCP session initialization is 4 seconds. The 

default value is 20 seconds; if required you can set the TCP session initialization value 

to less than 20 seconds. 

• On all high-end SRX Series devices, TCP session configuration has been enhanced. In 

earlier releases, the TCP session was only invalidated after 2 seconds of receiving a 

FIN or ACK packet. As a result, if there were new incoming SYN packets (with the same 

five tuples) within this 2 seconds, the packets would use the same TCP session, which 

would be terminated within 2 seconds. Therefore a new session could not be 

established. 

A new configuration attribute, fin-invalidate-session, has been introduced at the edit 

security flow tcp-session hierarchy level. This command invalidates a TCP session 

immediately on reception of a FIN or ACK packet. New incoming SYN packets will need 

to establish a new session. 

To end a session immediately on reception of a FIN or ACK packet, use the set security 

flow tcp-session fin-invalidate-session command. 


• When GTP inspection is enabled, all UDP packets that use GTP port numbers (3386, 

2123, or 2152), but are not actually GTP packets, will be dropped. 

• When you receive a create request and a response request on a Services Processing 

Unit (SPU), the tunnel might be established on a different SPU. For example, suppose 

you have SPU x, y, and z. You create a packet data protocol (PDP) context 

request/response that is processed individually by SPU x and y. The tunnel, however, 

is created on SPU z. 

• When a tunnel reaches full capacity (250,000 tunnels) on an SPU, the clear tunnel all 

command takes approximately 25 seconds to process. The clear tunnel all command 

takes much less time to process on SPUs without tunnels. For example, suppose you 

438 



have SPU x and y. The traffic distributed to SPU x is blocked by the clear tunnel all 

command. However, it has no impact on the traffic on SPU y. 

• The Create-PDP-Response packet must reach the devices within 5 seconds after the 

corresponding Create-PDP-Request was seen by the device; otherwise the request 

times out and the tunnel cannot be established. 

• When the restart counter value changes from its previous value, the tunnels that belong 

to the GSN device clear immediately. However, there is a 2-second delay to clear 

tunnels that belong to a security device. 

• On all high-end SRX Series devices in an active/active chassis cluster mode with GPRS 

enabled, the seq-number-validated command is disabled in GTP profile and no more 

available for configuration. 

In-Service Software Upgrade (ISSU) 

• On all high-end SRX Series devices, when an ISSU encounters an unexpected situation 

that necessitates an abort, the system message provides you with detailed information 

about when and why the upgrade stopped and recommendations for the next steps 

to take. 

The recommended steps that are displayed in the output have been modified. For the 

correct steps, see “Junos OS Security Configuration Guide” in “Errata and Changes in 

Documentation for Junos OS Release 11.4 for High-End SRX Series Services Gateways” 

on page 482. 


• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, for a dynamic attack group 

using the direction filter, the expression AND should be used in the exclude values. As 

is the case with all filters, the default expression is OR. However, there is a choice of 

AND in the case of the direction filter. 

For example, if you want to choose all attacks with the direction client-to-server, 

configure the direction filter using the set security idp dynamic-attack-group dyn1 filters 

direction values client-to-server command. 

In the case of chain attacks, each of the multiple members has its own direction. If a 

policy includes chain attacks, a client-to-server filter selects all chain attacks that have 

any member with client-to-server as the direction. This means chain attacks that 

include members with server-to-client or ANY as the direction are selected if the chain 

has at least one member with client-to-server as the direction. 

To prevent these chain attacks from being added to the policy, configure the dynamic 

group as follows: 

• set security idp dynamic-attack-group dyn1 filters direction expression and 

• set security idp dynamic-attack-group dyn1 filters direction values client-to-server 


439


• set security idp dynamic-attack-group dyn1 filters direction values 

exclude-server-to-client 

• set security idp dynamic-attack-group dyn1 filters direction values exclude-any 

IPv6 

• On all SRX Series devices, a new configuration option for IPv6 Neighbor Discovery 

Protocol (NDP) is added. This option will prevent the device from responding to a 

Neighbor Solicitation (NS) from a prefix which was not included as one of the device 

interface prefixes. 

The new command is: 

set protocol neighbor-discovery onlink-subnet-only 

NOTE: The Routing Engine needs to be rebooted after setting this option 

to remove any possibility of a previous IPv6 entry from remaining in the 

forwarding-table. 


• The logical-systems all option can now be specified for the show security screen statistics 

operational command. 

Management Information Base (MIB) 

• On all high-end SRX Series devices in a chassis cluster environment, the calculation 

of the primary and secondary node sessions in the JnxJsSPUMonitoringObjectsTable 

object of the SPU monitoring MIB is incorrect. The MIB 

jnxJsSPUMonitoringCurrentTotalSession incorrectly displays total sessions. 

A doubled session count is displayed because the active and backup nodes are treated 

as separate sessions, although these nodes are not separate sessions. 

Count only the session numbers on the local node, thereby avoiding a double count, 

and local total sessions are displayed. 

The SPUMonitoringCurrentTotalSession object of the MIB adds information per each 

SPU from the local node. 

[MIB Reference for SRX1400, SRX3400, and SRX3600 Services Gateways; MIB Reference 

for SRX5600 and SRX5800 Services Gateways] 

440 



Multicast 

• On all high-end SRX Series devices, if the maximum number of leaves on a multicast 

distribution tree is exceeded, multicast sessions are created up to the maximum number 

of leaves, and any multicast sessions that exceed the maximum number of leaves are 

ignored. In previous releases, no multicast traffic was forwarded if the maximum number 

of leaves on the multicast distribution tree was exceeded. The maximum number of 

leaves on a multicast distribution tree is device specific. 


• Public key infrastructure (PKI) objects include certificates, key pairs, and certificate 

revocation lists (CRLs). PKI objects are read from the PKI database when the PKI 

daemon (PKID) starts. The PKID database loads all certificates into memory at boot 

time. 

When an object is read into memory from the PKI database, the following new log 

message is created: 

PKID_PV_OBJECT_READ: A PKI object was read into memory from 

Security Policy Rules 

• If a policy is configured with multiple applications, and more than one of the applications 

match the traffic, then the application that best meets the match criteria is selected. 

System Log 

• The following system log messages have been introduced in Junos OS Release 11.4R6. 

• When sensor-configuration disable-low-memory-handling is not set and IPD receives 

a low-memory signal, the following message appears: Processing low memory signal 

• When sensor-configuration disable-low-memory-handling is set and IPD receives a 

low-memory signal, the following message appears: Ignoring low memory signal 

• IPsec System Log Enhancement 

IPsec system logs (sylogs) are generated for certain VPN scenarios. Junos OS Release 

11.2R4 introduces IPsec sylogs enhancement. These system logs are supported on all 

SRX Series devices. 

NOTE: You need to use the set system syslog file vpn_syslog daemon any 

CLI command to capture these IPsec system logs. 


441


The newly introduced IPsec system logs are: 

• IKE Phase-1: Responder starts Main mode negotiations—The remote peer at the 

specified IP address has initiated Phase 1 negotiations in either Main or Aggressive 

mode, and the local security device (the Responder) has begun its response. No 

recommended action. 

• IKE Phase-1: (Initiator) symmetric crypto key has been generated successfully—The 

P1 or manual key used for encryption has been generated successfully. No 


• IKE Phase-1: Negotiation completed—The local security device has sent the initial 

message for IKE Phase 2 negotiations to the specified peer. No recommended action. 

• IKE Phase-1 Failure: Main mode - no proposal chosen—There were no acceptable 

Phase 1 proposals. The specified negotiations to the identified IKE failed. Examine 

the local log and VPN configuration, and request the remote IKE user to examine 

the configuration on their VPN client for possible causes. 

• IKE Phase-1 Failure: ISAKMP negotiation retry limit reached—ISAKMP negotiation retry 

limit reached. No recommended action. 

• IKE Phase-1 Failure: Received delete notification—Received delete notification. No 


• IKE Phase-2: (Responder) Quick mode - negotiation initiated—The local security device 

has sent the initial message for IKE Phase 2 negotiations to the specified peer. No 


• IKE Phase-2: (Initiator) The symmetric crypto key has been generated successfully—The 

P2 or manual key used for encryption has been generated successfully. No 


• IKE Phase-2: (Responder) Quick mode - Responded to the first peer message—The 

local security device has responded to the specified peer, which sent the first message 

for Phase 2 IKE negotiations. No recommended action. 

• IKE Phase-2: Completed negotiations—The local security device has successfully 

negotiated a Phase 2 session with the specified peer. The Phase 2 session consists 

of the specified attributes. No recommended action. 

• IKE Phase-2 Failure: Quick mode - no proposal chosen—There were no acceptable 

Phase 2 proposals. The specified negotiations to the identified IKE failed. Examine 

the local log and VPN configuration, and request the remote IKE user to examine 

the configuration on the VPN client for possible causes. 

• IKE Phase-2: (Responder) Policy lookup for Phase-2 failed—Received a message but 

did not check a policy because ID mode was set to IP or policy checking was disabled. 

When the local security device received an IKE Phase 2 message from the specified 

peer, it could not check for a policy because the ID mode was set to IP or policy 

checking was disabled. If the ID mode is set to IP, the remote peer does not send the 

proxy ID payload when initiating a Phase 2 session. The proxy ID consists of the local 

end entity's IP address and netmask, protocol, and port number, as well as those 

items for the remote end entity. Consequently, the local peer cannot use the 

442 


Known Limitations in Junos OS Release 11.4 for High-End SRX Series Services Gateways 

information in the proxy ID to match the information in a local policy. If policy checking 

is disabled for IKE traffic with the specified peer, the IKE module builds security 

association (SA) without verifying the policy configuration. 

Verify if this behavior is intended. If not, set the ID mode to subnet (set IKE ID mode 

subnet) and enable policy checking ( set IKE policy checking ). 

• IKE Phase-2: Failed to match the peer proxy IDs—The peer sent a proxy ID that did not 

match the one in the SA configuration. An IKE Phase 2 quick mode message was 

received and a corresponding Phase 1 SA was found, but the proxy ID (local and 

remote subnets protected by this tunnel) within the message was not consistent 

with the proxy ID setting for this tunnel's configuration. 

Verify the proxy ID (local and remote subnets) setting for this tunnel and try again. 

• IKE Phase-2 Failure: IKE Phase-2 negotiation retry limit reached—The local security 

device has reached the retransmission limit (10 failed attempts) during Phase 2 

negotiations with the specified remote peer because the local device has not received 

a response. 

NOTE: If the local device continues receiving outbound traffic for the 

remote peer after the first 10 failed attempts, it makes another 10 

attempts, and continues to do so until it either succeeds at contacting 

the remote gateway or it no longer receives traffic bound for that gateway. 

Verify network connectivity to the peer gateway. Request the remote gateway admin 

to consult the log to determine if the connection requests reached it and, if so, why 

the device did not respond. 

Related 

Documentation 

• New Features in Junos OS Release 11.4 for High-End SRX Series Services Gateways on 

page 417 




on page 459 




on page 443 


AppSecure 

• J-Web pages for AppSecure are preliminary. 

• Custom application signatures and custom nested application signatures are not 

currently supported by J-Web. 


443


• AppFW does not operate on ALG data sessions. As a result, the AppFW rules are not 

applicable to these sessions. Therefore, ALG data sessions are excluded from AppFW 

counters. 


• On all high-end SRX Series devices, IPSec VPN is not supported in active/active chassis 

cluster configuration (that is, when there are multiple RG1+ redundancy-groups). 

• On SRX5800 and SRX5600 devices in chassis cluster, IP Monitoring is not supported 

on redundant Ethernet interface if bundle (LAG) redundant Ethernet is configured. 

• On all high-end SRX Series devices, the first recommended ISSU from release is Junos 

OS Release 10.4R4. If you intend to upgrade from a release earlier than Release 10.4R4, 

see the release notes for the release that you are upgrading from for information about 

limitations and issues related to upgrading. 

On all high-end SRX Series devices, ISSUs do not support the following features: 

• ALGs (MGCP and SCCP) 

• AppSecure 

• DHCP 

• GPRS, GTP, and SCTP 

• GRE or IP-IP 

• IDP 

• J-Flow 

• Logging 

• Multicast routing 

• PCAP 

• Port mirroring 

• VPN 

For the latest ISSU support status, go to the Juniper Networks Knowledge Base (KB): 

http://kb.juniper.net/ and search for KB17946. 

• On all high-end SRX Series devices in a chassis cluster, only four QoS queues are 

supported per ae interface. 

• In large chassis cluster configurations on SRX3400 or SRX3600 devices, you need to 

increase the wait time before triggering failover. In a full-capacity implementation, we 

recommend increasing the wait to 8 seconds by modifying heartbeat-threshold and 

heartbeat-interval values in the [edit chassis cluster] hierarchy. 

The product of the heartbeat-threshold and heartbeat-interval values defines the time 

before failover. The default values (heartbeat-threshold of 3 beats and 

heartbeat-interval of 1000 milliseconds) produce a wait time of 3 seconds. 

444 



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. Likewise, setting the heartbeat-threshold to 4 and the heartbeat-interval to 

2000 milliseconds also yields a wait time of 8 seconds. 

• Packet-based forwarding for MPLS and International Organization for Standardization 

(ISO) protocol families is not supported. 

• On SRX Series devices, 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. 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, IP address monitoring is 

not supported on redundant Ethernet interface link aggregation groups (LAGs) or on 

child interfaces of redundant Ethernet interface LAGs. 

• On SRX1400, SRX3000 and SRX5000 line chassis clusters, screen statistics data can 

be gathered on the primary device only. 

• On all high-end SRX Series devices, ISSU does not support version downgrading. 

• On all high-end SRX Series 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 might not work. 


• On all high-end SRX Series devices DHCP is not supported in a chassis cluster. 

• On all high-end SRX Series devices, DHCPv6 client authentication is not supported. 


• On all high-end SRX Series devices, sessions going through GRE over IPsec are not 

marked as backup on backup node, instead, they are marked as active on backup node. 

This behavior causes the real active session to be deleted. Nesting tunnel, like GRE 

over IPsec, is not supported on chassis cluster. 

• On all high-end SRX Series, a mismatch between the Firewall Counter Packet and Byte 

Statistics values, and between the Interface Packet and Byte Statistics values, might 

occur when the rate of traffic increases above certain rates of traffic. 

• On all high-end SRX Series devices, when packet-logging functionality is configured 

with an improved pre-attack configuration parameter value, the resource usage 

increases proportionally and might affect the performance. 

• Services offloading has the following limitations on all high-end SRX Series devices: 


445


• Transparent mode is not supported. If transparent mode is configured, a normal 

session is installed. 

• Link aggregation group (LAG) is not supported. If a LAG is configured, a normal 

session is installed. 

• Only multicast sessions with one fan-out are supported. If a multicast session with 

more than one fan-out exists, a normal session is installed. 

• Only active/passive chassis cluster (HA) configuration is supported. Active/active 

chassis cluster configuration is not supported. 

• Fragmented packets are not supported. If fragmented packets exist, a normal session 

is installed. 

• Ingress and egress interfaces on different network processors are not supported. If 

an ingress interface and the related egress interface do not belong to the same 

network processor, a normal session is installed on the network processor. 

• IP version 6 (IPv6) is not supported. If IPv6 is configured, a normal session is installed. 

NOTE: A normal session forwards packets from the network processor to 

the Services Processing Unit (SPU) for fast-path processing, while a 

services-offload session processes fast-path packets in the network 

processor and the packets exit out of the network processor itself. 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the default authentication 

table capacity is 45,000; the administrator can increase the capacity to a maximum 

of 50,000. 

• On SRX1400 devices, the default authentication table capacity is 10,000; the 

administrator can increase the capacity to a maximum of 15,000. 

• On all high-end SRX Series devices, when devices are operating in flow mode, the 

Routing Engine side cannot detect the path maximum transmission unit (PMTU) of 

an IPv6 multicast address (with a large size packet). 

• On all high-end SRX Series devices, you cannot configure route policies and route 

patterns in the same dial plan. 

• On all high-end SRX Series devices, high CPU utilization triggered for reasons such as 

CPU intensive commands and SNMP walks causes the Bidirectional Forwarding 

Detection protocol (BFD) to flap while processing large BGP updates. 

• On all high-end SRX Series devices, downgrading is not supported in low-impact ISSU 

chassis cluster upgrades (LICU). 

• On SRX5800 devices, network processing bundling is not supported in Layer 2 

transparent mode. 

446 




• In an chassis cluster scenario, the number of APN or IMSI filters must be limited to 600 

for each GTP profile. The number of filters is directly proportional to the number of 

IMSI prefix entries. For example, if one APN is configured with two IMSI prefix entries, 

then the number of filters is two. 

Hardware 

This section covers filter and policing limitations. 

• On SRX1400, SRX3400 and SRX3600 devices, the following feature is not supported 

by a simple filter: 

• Forwarding class as match condition 

• On SRX1400, SRX3400 and SRX3600 devices, the following features are not supported 

by a policer or a three-color-policer: 

• Color-aware mode of a three-color-policer 

• Filter-specific policer 

• Forwarding class as action of a policer 

• Logical interface policer 

• Logical interface three-color policer 

• Logical interface bandwidth policer 

• Packet loss priority as action of a policer 

• Packet loss priority as action of a three-color-policer 

• On all high-end SRX Series devices, the following features are not supported by a 

firewall filter: 

• Policer action 

• Egress filter-based forwarding (FBF) 

• Forwarding table filter (FTF) 

• SRX3400 and SRX3600 devices have the following limitations of a simple filter: 

• Forwarding class as match condition 

• In the packet processor on an IOC, up to 400 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 2000. 

• In the packet processor on an IOC, the maximum number of policers is 2000. 


447


• 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 SRX3400 and SRX3600 devices, when you enable the monitor traffic option using 

the monitor traffic command to monitor the FXP interface traffic, interface bounce 

occurs. You must use the monitor traffic interface fxp0 no-promiscuous command to 

avoid the issue. 


• On all high-end SRX Series devices,interfaces of redundant Ethernet interface it takes 

more than 5 minutes for ATM interface to show up when CPE is configured in ANSI-DMT 

mode and CO is configured in auto mode. This occurs only with ALU 7300 DSLAM, due 

to limitation in current firmware version running on ADSL Mini – PIM. 

• On SRX3000 and SRX5000 line devices, the set protocols bgp family inet flow and set 

routing-options flow CLI statements are no longer available, because BGP flow spec 

functionality is not supported on these devices. 

• On all high-end SRX Series devices, the Link Aggregation Control Protocol (LACP) is 

not supported on Layer 2 interfaces. 

• On all high-end SRX Series devices, BGP-based virtual private LAN service (VPLS) 

over aggregated Ethernet (ae) interfaces is not supported. It works on child ports and 

physical interfaces. 

Internet Key Exchange Version 2 (IKEv2) 

On all high-end SRX Series devices, IKEv2 does not include support for: 

• Policy-based tunnels 

• Dial-up tunnels 



• Next-Hop Tunnel Binding (NHTB) for st0—Reusing the same tunnel interface for 

multiple tunnels 

• Extensible Authentication Protocol (EAP) 

• IPv6 

• Multiple child SAs for the same traffic selectors for each QoS value 

• Proposal enhancement features 

• Reuse of Diffie-Hellman (DH) exponentials 

• Configuration payloads 

• IP Payload Compression Protocol (IPComp) 

• Dynamic Endpoint (DEP) 

448 




• On all high-end SRX Series devices, from Junos OS Release 11.2 and later, the IDP 

security package is based on the Berkeley database. Hence, when the Junos OS image 

is upgraded from Junos OS Release 11.1 or earlier to Junos OS 11.2 or later, a migration 

of IDP security package files needs to be performed. This is done automatically on 

upgrade when the IDP daemon comes up. Similarly, when the image is downgraded, 

a migration (secDb install) is automatically performed when the IDP daemon comes 

up, and previously installed database files get deleted. 

However, migration is dependent on the XML files for the installed database to be 

present on the device. For first-time installation, full update files are required. If the 

last update on the device was an incremental update, migration might fail. In such a 

case, you have to manually download and install the IDP security package using the 

download or install CLI command before using the IDP configuration with predefined 

attacks or groups. 

Workaround: Use the following CLI commands to manually download the individual 

components of the security package from the Juniper Security Engineering portal and 

install the full update: 

• request security idp security-package download full-update 

• request security idp security-package install 

• On all high-end SRX Series devices, the IDP policies for each user logical system are 

compiled together and stored on the data plane memory. To estimate adequate data 

plane memory for a configuration, consider these two factors: 

• IDP policies applied to each user logical system are considered unique instances 

because the ID and zones for each user logical system are different. Estimates need 

to take into account the combined memory requirements for all user logical systems. 

• As the application database increases, compiled policies will require more memory. 

Memory usage should be kept below the available data plane memory to allow for 

database increases. 

• On all high-end SRX Series devices, ingress as ge-0/0/2 and egress as ge-0/0/2.100 

works with flow showing both source and destination interface as ge-0/0/2.100. 

• IDP does not allow header checks for nonpacket contexts. 

• On all high-end SRX Series 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 that you 

do not configure rulebase-ddos rules that have two different application-ddos objects 

when the traffic destined to one application server can process more than one rule. 

Essentially, for each protected application server, you have to configure the 

application-level DDoS rules so that traffic destined for one protected server processes 

only one application-level DDoS rule. 


449


NOTE: Application-level DDoS rules are terminal, which means that once 

traffic is processed by one rule, it will not be processed by other rules. 

The following configuration options can be committed, but they will not work properly: 

source-zone 

destination-zone 

destination-ip 

service 

application-ddos 

Application 

Server 

source-zone-1 

dst-1 

any 

http 

http-appddos1 

1.1.1.1:80 

source-zone-2 

dst-1 

any 

http 

http-appddos2 

1.1.1.1:80 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, application-level DDoS 

rule base (rulebase-ddos) does not support port mapping. If you configure an 

application other than default, and if the application is from either predefined Junos 

OS 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, intrusion detection and 

prevention (IDP) uses application identification to detect applications running on 

standard and nonstandard ports; thus, the application-level DDoS detection would 

work properly. 

• 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. 

• 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 a limitation that for time-binding 

scope source traffic, if attacks from a source (with more than one destination) have 

active sessions distributed across nodes, then 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. 


• On SRX Series devices, when you enable VPN, overlapping of the IP addresses across 

virtual routers (VRs) is supported partially with following limitations: 

• An IKE external interface address cannot overlap with any other VR. 

• An internal/trust interface address can overlap across VRs. 

450 



• An st0 interface address cannot overlap in route-based VPN in point-to-multipoint 

tunnel such as NHTB. 

• An st0 interface address can overlap in route-based VPN in point-to-point tunnel. 

IPv6 

• SCTP - SCTP is not supported on IPv6. It is supported only on IPv4. 

• NSM—Consult the Network and Security Manager (NSM) release notes for version 

compatibility, required schema updates, platform limitations, and other specific details 

regarding NSM support for IPv6 addressing on SRX3400, SRX3600, SRX5600, and 


• Security policy—IDP for IPv6 sessions is supported only for all high-end SRX Series 

devices. UTM for IPv6 sessions is not supported. If your current security policy uses 

rules with the IP address wildcard any, and UTM features are enabled, you will encounter 

configuration commit errors because 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 UTM features. 

J-Web 

• On all high-end SRX Series devices, to use the Chassis View, a recent version of Adobe 

Flash that supports ActionScript and AJAX (Version 9) must be installed. Also note 

that the Chassis View is displayed by default on the Dashboard page. You can enable 

or disable it using options in the Dashboard Preference dialog box, but clearing cookies 

in Internet Explorer also causes the Chassis View to be displayed. 

• 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, users cannot differentiate 

between Active and Inactive configurations on the System Identity, Management 

Access, User Management, and Date & Time pages. 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, you cannot use J-Web to 

configure a VLAN interface for an IKE gateway. VLAN interfaces are not currently 

supported for use as IKE external interfaces. 


• On all high-end SRX Series devices, when more than one IDP policy is configured on 

the device, and if root logical systems and custom logical systems are referring to 

different policies, the referenced policies may not compile properly after a security 

package update. As a workaround, deactivate and activate the active policy of IDP and 

commit the configuration after installing the security package. 

• The master logical system must not be bound to a security profile that is configured 

with a 0 percent reserved CPU quota as traffic loss could occur. When upgrading an 

a high-end SRX Series devices from Junos OS Release 11.2, make sure that the reserved 

CPU quota in the security profile that is bound to the master logical system is configured 

for 1 percent or more. After upgrading from Junos OS Release 11.2, the reserved CPU 

quota is added to the default security profile with a value of 1 percent. 


451


• Starting with Junos OS Release 11.2, address books can be defined under the [security] 

hierarchy level instead of the [security zones] hierarchy level. This enhancement makes 

configuring your network simpler by allowing you to share IP addresses in address 

books when configuring features such as security policies and NAT. You can attach 

zones to address books—this is known as zone-attached configuration. 

Junos OS Release 11.4 continues to support address book configuration under the 

[security zones] hierarchy level—this is known as zone-defined configuration. However, 

we recommend that zone-attached address book configuration be used in the master 

logical system and user logical systems. 

If you upgraded your SRX1400, SRX3400, SRX3600, SRX5600, or SRX5800 device 

to this Junos OS Release 11.4, and are configuring logical systems on the device, the 

master logical system retains any previously-configured zone-defined address book 


convert zone-defined configuration to zone-attached configuration. The upgrade script 

converts all zone-defined configurations in the master logical system and user logical 

systems. See section, “Upgrade and Downgrade Scripts for Address Book Configuration” 

of “Upgrade and Downgrade Instructions for Junos OS Release 11.4 for High-End SRX 

Series Services Gateways” on page 489. 

• On all high-end SRX Series devices, the logical systems feature does not support ALGs 

for user logical systems because ALGs are configured globally. If you enable ALGs at 

the root master logical system level, they are also enabled for user logical systems in 

this Junos OS Release 11.4. In this case, user logical system traffic is processed by the 

ALGs, and corresponding ALG flow sessions are initiated under the user logical system. 

You can only enable and disable ALGs at the root master logical system level. 

• On all high-end SRX Series devices, quality-of-service (QoS) classification across 

interconnected logical systems does not work. 

• On all high-end SRX Series devices, the number of logical system security profiles you 

can create is constrained by an internal limit on security profile IDs. The security profile 

ID range is from 1 through 32 with ID 0 reserved for the internally configured default 

security profile. When the maximum number of security profiles is reached, if you want 

to add a new security profile, you must first delete one or more existing security profiles, 

commit the configuration, and then create the new security profile and commit it. You 

cannot add a new security profile and remove an existing one within a single 

configuration commit. 

If you want to add more than one new security profile, the same rule is true. You must 

first delete the equivalent number of existing security profiles, commit the configuration, 

and then create the new security profiles and commit them. 

• User and administrator configuration for logical systems—Configuration for users 

for all logical systems and all user logical systems administrators must be done at the 

root level by the master administrator. A user logical system administrator cannot 

create other user logical system administrators or user accounts for their logical 

systems. 

• Name-space separation—The same name cannot be used in two logical systems. For 

example, if logical-system1 includes the username “Bob” then other logical systems 

on the device cannot include the username “Bob”. 

452 



• Commit rollback—Commit rollback is supported at the root level only. 

• Trace and debug—Trace and debug are supported at the root level only. 

• Class of service—You cannot configure class of service on logical tunnel (lt-0/0/0) 

interfaces. 

• ALGs—The master administrator can configure ALGs at the root level. The configuration 

is inherited by all user logical systems. It cannot be configured discretely for user logical 

systems. 


• Maximum capacities for source pools and IP addresses have been extended on all 

high-end SRX Series devices, as follows: 

Pool/PAT Maximum 

Address Capacity 

SRX1400 

SRX3400 

SRX3600 

SRX5600 

SRX5800 

Source NAT pools 

8192 

8192 

12288 

IP addresses supporting 

port translation 

8192 

8192 

12288 

PAT port number 

256M 

256M 

384M 

Increasing the capacity of source NAT pools consumes memory needed for port 

allocation. When source NAT pool and IP address limits are reached, port ranges should 

be reassigned. That is, the number of ports for each IP address should be decreased 

when the number of IP addresses and source NAT pools is increased. This ensures NAT 

does not consume too much memory. Use the port-range statement in configuration 

mode in the CLI to assign a new port range or the pool-default-port-range statement 

to override the specified default. 

Configuring port overloading should also be done carefully when source NAT pools 

are increased. 

For source pool with port address translation (PAT) in range (64,510 through 65,533), 

two ports are allocated at one time for RTP/RTCP applications, such as SIP, H.323, 

and RTSP. In these scenarios, each IP address supports PAT, occupying 2048 ports 

(64,512 through 65,535) for Application Layer Gateway (ALG) module use. On SRX5600 

and SRX5800 devices, if all of the 4096 source pool is configured, a port allocation 

of 8,388,608 is reserved for twin port use. 

• NAT rule capacity change—To 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 26 on page 454. The limitation on the number of destination-rule-set and 

static-rule-set has been increased. 

Table 26 on page 454 provides the requirements per device to increase the configuration 

limitation as well as to scale the capacity for each device. 


453


Table 26: Number of Rules on SRX3400, SRX3600, SRX5600, and 

SRX5800 Devices 

NAT Rule Type 

SRX3400 

SRX3600 

SRX5600 

SRX5800 

Source NAT rule 

8192 

8192 

Destination NAT rule 

8192 

8192 

Static NAT rule 

20480 

20480 

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-T—On SRX1400, 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. 

454 



Security 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the limitation on the number 

of addresses in an address-set has been increased. The number of addresses in an 

address-set now depends on the device and is equal to the number of addresses 

supported by the policy. 

Table 27: Number of Addresses in an address-set on SRX3400, SRX3600, 

SRX5600, and SRX5800 Devices 

Device 

address-set 

Default 

1024 

SRX3400 

1024 

SRX3600 

1024 

SRX5600 

1024 

SRX5800 

1024 

Simple Network Management Protocol (SNMP) 

• On all high-end SRX Series devices, the show snmp mib CLI command will not display 

the output for security related MIBs. We recommend that you use an SNMP client and 

prefix logical-system-name@ to the community name. For example, if the community 

is public, use default@public for default root logical system. 

Unsupported CLI 

• On all high-end SRX Series devices, the mvrp CLI option under set protocols CLI 

command is not supported but it is visible. However, if you enter these commands in 

the CLI editor, they will appear to succeed and will not display an error message. 

• On all high-end SRX Series devices, the command restart ipsec-key-management is 

not supported. 

• On all high-end SRX Series 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 multicast scope inet6 

• show msdp sa group group 

• show pim mvpn 


455



IPv6 IPsec implementation has the following limitations: 

• IPv6 routers do not perform fragmentation. IPv6 hosts should either perform path 

maximum transmission unit (PMTU) discovery or send packets smaller than the IPv6 

minimum MTU size of 1280 bytes. 

• Because IPv6 addresses are 128 bits long compared to IPv4 addresses, which are 

32-bits long, IPv6 IPsec packet processing requires more resources. Therefore, a small 

performance degradation is observed. 

• IPv6 uses more memory to set up the IPsec tunnel. Therefore, the IPsec IPv4 tunnel 

scalability numbers might drop. 

• The addition of IPv6 capability might cause a drop in the IPsec IPv4-in-IPv4 tunnel 

throughput performance. 

• The IPv6 IPsec VPN does not support the following functions: 

• 4in6 and 6in4 policy-based site-to-site VPN, IKE 

• 4in6 and 6in4 route-based site-to-site VPN, IKE 

• 4in6 and 6in4 policy-based site-to-site VPN, Manual Key 

• 4in6 and 6in4 route-based site-to-site VPN, Manual Key 

• 4in4, 6in6, 4in6, and 6in4 policy-based dial-up VPN, IKE 

• 4in4, 6in6, 4in6, and 6in4 policy-based dial-up VPN, Manual Key 

• Remote Access—XAuth, config mode, and shared IKE identity with mandatory XAuth 

• IKE authentication—public key infrastructure/digital signature algorithm (PKI/DSA) 

• IKE peer type—Dynamic IP 

• Chassis cluster for basic VPN features 

• IKE authentication—PKI/RSA 

• NAT—Traversal 


• Hub-and-spoke VPNs 

• Next Hop Tunnel Binding Table (NHTB) 

• Dead Peer Detection (DPD) 

• Simple Network Management Protocol (SNMP) for IPsec VPN MIBs 

• Chassis cluster for advanced VPN features 

• IPv6 link-local address 

• SRX Series high-end devices (for example, SRX3000 and SRX5000 lines) 

dependency 

• On all high-end SRX Series devices, DH-group 14 is not supported for dynamic VPN. 

456 



• ST0 interface configuration change may result in permanent traffic loss. As a 

workaround: 

• Deactivate or delete security IPSec configuration before changing st0 interface 


• Adding new apply group causes VPN from existing apply group to go down. 

• The following list describes the limitations for inserting an SPC on a device in chassis 

cluster mode: 

• While inserting an SPC, the node must be powered off. 

• The chassis cluster must be in active/passive mode before and during the SPC insert 

procedure, that is, all redundancy groups are primary on one node. 

• A different number of SPCs cannot be inserted into two different nodes. 

• A new SPC must be inserted in a slot that is higher than the central point slot. 

NOTE: The existing Combo central point cannot be changed to Full 

central point after the new SPC is inserted. For SRX5000 and SRX3000 

devices with a Capacity Licence, two SPC cards per node must be already 

present before this feature can be used. For SRX3000 without Capacity 

Licence, this limitation does not apply, because the CP will always remain 

in combo-mode. 

• During an SPC insert procedure, the IKE and IPsec configurations cannot be modified. 

• Users cannot specify the SPU and the IKE instance to anchor a tunnel. 

• After a new SPC is inserted, the existing tunnels cannot use the processing power 

of the new SPC and redistribute it to the new SPC. 

• Dynamic tunnels cannot load-balance across different SPCs. 

• The manual VPN name and the site-to-site gateway name cannot be the same. 

• In an chassis cluster scaling environment, the heartbeat-threshold must always be 

set to 8. 

• Manual (static) NHTB with DEP is not supported. 

• The local-IP feature is not supported on the following: 

• On all high-end SRX Series devices. 

• On all high-end SRX Series devices in chassis cluster configuration. 

• On all high-end SRX Series devices, the IPsec NAT-T tunnel 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. 


457


Related 

Documentation 


page 417 


on page 459 







Outstanding Issues in Junos OS Release 11.4R7 for High-End SRX Series Services Gateways 

The following problems currently exist in Juniper Networks high-end SRX Series Services 

Gateways. The identifier following the descriptions is the tracking number in the Juniper 

Networks Problem Report (PR) tracking system. 





• On devices in a chassis cluster, IP monitoring is not supported on the redundant Ethernet 

(reth) interface when link aggregation group (LAG) redundant Ethernet is configured. 

[PR609266] 

• On devices in a chassis cluster, the secondary node might crash when there is multicast 

traffic flow in active/active mode. [PR745428] 


• When you upgrade a device to Junos OS Release 11.4, NSM shows an error that a space 

in the full-name parameter of the set system login user test-name full-name test name 

command statement is not accepted. [PR806750] 


• When a hardware timestamp is enabled, RPM probes go over the network control 

queue instead of the configured forwarding class. [PR487948] 

• Diagnostic test fails for the following functions: 

• mp_i2c_security_chip 

• fpga_configure_mode_bpi 

• fpga_configure_mode_spi 

458 


Resolved Issues in Junos OS Release 11.4 for High-End SRX Series Services Gateways 

[PR601296] 

• Data packets with errors that are dropped by the configured IDP policy will not increment 

the drop by error counter value. [PR769504] 

IPv6 

• After you reboot the device, the interface counters on the secondary node are not 

accurate. [PR790807] 

J-Web 

• In J-Web, the chassis view cannot be dragged under the Dashboard tab. [PR842034] 

Related 

Documentation 


page 417 


on page 443 




The following are the issues that have been resolved in Junos OS Release 11.4 for Juniper 

Networks high-end SRX Series Services Gateways. The identifier following the descriptions 

is the tracking number in the Juniper Networks Problem Report (PR) tracking system. 




• Resolved Issues in Junos OS Release 11.4R7 for High-End SRX Series Services 















459


Resolved Issues in Junos OS Release 11.4R7 for High-End SRX Series Services 

Gateways 


• On devices in a chassis cluster, the child link of the link aggregation group (LAG) 

redundant Ethernet (reth) interface flapped frequently which caused memory corruption 

on the next hop pointer and caused the Routing Engine to generate a vmcore file. 


• On devices in a chassis cluster, the timeout value within which the request system 

snapshot media internal slice alternate command was expected to complete was 

increased from 10 minutes to 15 minutes. [PR822975: This issue has been resolved.] 


• On all high-end SRX Series devices, the XLR ingress paused condition caused traffic 

drop and latency to process traffic. [PR829714: This issue has been resolved.] 


• In Junos OS Release 11.4, the Physical Interface Module (PIM) auto-rendezvous point 

feature did not work. [PR789943: This issue has been resolved.] 

• When the data size was smaller than 128 bytes, the certificate revocation list (CRL) 

failed to install using the Lightweight Directory Access Protocol (LDAP) server. 


Intrusion Detection Prevention (IDP) 

• In a high connections per second (CPS) traffic scenario, when some specific applications 

that required serialized packets were processed in IDP, attack leakage occurred. 

[PR823468]. 

• A new filter was added in dynamic attack groups in the CLI. The two flags under filters 

are recommended (which means true) and not-recommended (which means false). 

Only the recommended=true flag was supported. [PR828494: This issue has been 

resolved.] 

J-Web 

• The dashboard refresh rate changed. Refresh rates of 15, 30, and 60 seconds were 

removed. The minimum refresh rate available was 2 minutes. [PR826053: This issue 


• In J-Web, the session expired when the idle-timeout value was set too low. [PR830644: 


460 




• When you configured a wildcard address and used it in more than seven security policies, 

the Services Processing Unit (SPU) crashed. [PR847632: This issue has been resolved.] 


Gateways 


• On all SRX Series devices, the SQL ALG did not work properly when TNS RESEND (type 

11) was 8 bytes long. [PR806893: This issue has been resolved.] 

• On all high-end SRX Series devices, the MSRPC ALG dropped some large packets 

under the Kerberos authentication environment because the Kerberos ticket token size 

was too large and the MSRPC bind packet was too large for the ALG to handle. 



• On all high-end SRX Series devices in a chassis cluster, long pauses and timeout were 

seen during SNMP walk/query of the device. A delay occurred in the kernel’s query of 

the gr-0/0/0 (GRE) interface. [PR800735: This issue has been resolved.] 

• On SRX5600 and SRX5800 devices in a chassis cluster, when the cluster was up and 

if an SPC with control link was pulled out (either one in dual control link), the node on 

which the SPC was pulled out would cause all the cards to go offline. The other node 

would become the primary node for both RG0 and RG1+ , and traffic loss was expected 

for 18 to 20 seconds. [PR819124: This issue has been resolved.] 


• On SRX3600 devices, dhcp-option82 did not work. [PR794522: This issue has been 

resolved.] 

Dynamic Virtual Private Network (VPN) 

• On all high-end SRX Series devices, when multiple clients were connected to SRX 

Series devices through dynamic VPN, some configurations related to IKE negotiation 

changed. [PR737787: This issue has been resolved.] 


• On all high-end SRX Series devices, an SPU message “Nexthop XXXX on ifl XXX. 

Ignoring…” was logged in some occasions. This message did not indicate the real issue 

and could be ignored. [PR726580: This issue has been resolved.] 

• On all high-end SRX Series devices, the HTTPD task went high approximately once a 

month. [PR768952: This issue has been resolved.] 

• On SRX1400 devices, the number of GSN entries was expanded from 6,000 entries 

to 18,000 entries on each SPU. [PR787028: This issue has been resolved.] 


461


• On all high-end SRX Series devices, when the ingress and egress interfaces were located 

(or active, in case of reth interfaces) on different nodes of a chassis cluster, filter-based 

forwarding (FBF) did not work correctly. [PR793057: This issue has been resolved.] 

• On SRX3600 devices, if a large number of tunnel routes were added, memory utilization 

could become very high. [PR797845: This issue has been resolved.] 

• On SRX5800 devices, in certain configurations, the following message was printed in 

the logs: "PFEMAN: Sent Resync request to Master." This message was not an indication 

of a problem, and did not require any action from the user. This message has been 

removed. [PR802355: This issue has been resolved.] 

• On SRX5800 devices, the following IKE traceoption messages might be printed while 

debugging VPN tunnels: 

Aug 2 09:27:03 srx-5800-1 (FPC Slot 0, PIC Slot 1) SPC0_PIC1 kmd[213]: IKE Phase-1 

Failure: (null) spi=75ffd1a8, src_ip=, dst_ip=A.A.A.A 

Aug 2 09:27:06 srx-5800-1 (FPC Slot 0, PIC Slot 1) SPC0_PIC1 kmd[214]: IKE Phase-1 

Failure: (null) spi=75ffd1a8, src_ip=, dst_ip=B.B>B>B> 

NOTE: The same SPI value was printed for two different peer IP addresses 

and a memory address of SPI was printed instead of the SPI address itself. 

Also, an invalid cookie reason was not printed because of this message; 

instead, the text "null" was printed as shown in the preceding message. 


• On all high-end SRX Series devices, generation of a flowd core file was triggered by 

cache errors. [PR805975: This issue has been resolved.] 

• On all high-end SRX Series devices, Routing Engine failover occurred due to possible 

out-of-sync information about already allocated SNMP interface index values and 

duplicate SNMP interface index values might be allocated. As a result, the mib2d 

process might crash or the SNMP interface index value of zero might be allocated for 

newly created interfaces. [PR806098: This issue has been resolved.] 

• On all high-end SRX Series devices, the performance monitor message format changed, 

beginning with Junos OS Release 11.1. In earlier releases, the message format caused 

rtlogd to generate a core file and rtlogd restarted automatically after 1 or 2 seconds. 


• On SRX3600 devices, if any changes were committed under logical systems 

configuration, the security policy might fail to resolve DNS objects that were in the 

security address book. As a result, your traffic might hit other unexpected security 

policies, or if the traffic does not match any configured security policy, by default the 

traffic would be denied causing a traffic outage. [PR810723: This issue has been 

resolved.] 

• On SRX3400 devices, SCTP ALG dropped SCTP abort packets on half-open SCTP 

associations. [PR822829: This issue has been resolved.] 

462 



• On all high-end SRX Series devices, STARTTLS and X-ANONYMOUSTLS cases were 

not supported by the SMTP parser. [PR824027: This issue has been resolved.] 

• On all high-end SRX Series devices, a new filter was added in the dynamic attack 

groups, but recommended=flag was not supported. [PR828494: This issue has been 

resolved.] 


• On all high-end SRX Series devices, the interface did not respond due to heavy traffic 

on the FIOC interface. [PR776179: This issue has been resolved.] 

• On all high-end SRX Series devices, when the ge interface was down, it did not show 

linkup until the configuration had been removed and readded. [PR813616: This issue 


• On all high-end SRX Series devices, after you upgraded to Junos OS Release to 11.4R5, 

if OSPF was enabled for any of the st0 interfaces, an internal processing error prevented 

the default route from being advertised. [PR822352: This issue has been resolved.] 


463


Intrusion Detection and Prevention 

• On all high-end SRX Series devices, when IDP was enabled application traffic was 

blocked due to a memory leak issue with IDP. [PR808202: This issue has been resolved.] 


• On SRX3600 devices, logical systems with the policy count option displayed the 

statistics after a show command, or the counter stopped incrementing if both redundant 

groups were not on the same node as a result of failover. [PR782546: This issue has 



• On all high-end SRX Series devices, after a Routing Engine switchover, LACP and MIB 

process core files might be generated. [PR790966: This issue has been resolved.] 

Qulaity of Service (QoS) 

• On SRX3600 devices, when Application QoS was configured and if traffic did not 

match the configured appqos rules, a flowd core was generated.. [PR805562: This 



• On all high-end SRX Series devices, gkmd core files were generated on the Group VPN 

member if hmac-sha-256-128 was used at the group VPN server for the IPsec 

authentication algorithm. [PR800735: This issue has been resolved.] 


Gateways 


• On SRX3600 devices, SIP ALG dropped SIP ACK messages if the messages used the 

folding format. [PR787879: This issue has been resolved.] 


• On SRX5600 devices, when you swapped the members of a link aggregation group 

(LAG), a vmcore or ksyncd core file might be created on the backup Routing Engine. 


• On SRX3600 devices, high CPU utilization due to the mgd process could result if run 

show config was specified during configuration mode. Also, the HTTPD process went 

high. [PR729617: This issue has been resolved.] 

• On SRX Series devices, commands after STARTTLS were encrypted, and could not 

be understood by the SMTP parser, causing the session to hang until the TCP session 

was closed, and no packets were forwarded. [PR750047: This issue has been resolved.] 

• On SRX3600 devices, the graceful restart mechanism was not aborted even if the link 

to the upstream neighbor was detected as down. This lead to higher routing protocol 

464 



convergence times because the device would not fail over to an alternate path until 

the graceful restart timer expired. [PR751640: This issue has been resolved.] 

• On SRX3400 devices, the message log is too granular, indicating blower speed changes 

frequently from normal to intermediate speed which is filling up logs and causing 

inability to troubleshoot using logs. [PR776254: This issue has been resolved.] 

• On SRX5800 devices, when multiple interfaces are bound to the same security zone, 

if the first fragmented packet and the second fragmented packet arrive in different 

interfaces, the second fragmented packet is dropped. [PR777343: This issue has been 

resolved.] 

• On SRX3400, SRX3600, SRX5600 and SRX5800 devices, detector does not get 

updated in control plane when update-attack-database-only flag is used during 

security-package install. [PR778816: This issue has been resolved.] 

• On SRX5800 devices, eventd core is triggered by an illegal pointer address. [PR784037: 


• On SRX3400 devices, set chassis fpc pic services-offload command doe not work. Due 

to this SRX cannot be used in LLFW mode. [PR787526: This issue has been resolved.] 

• On SRX3400 devices, if security policies are configured with a large number of 

applications using the same source/destination port, then policy configuration updates 

may not work as expected. [PR793151: This issue has been resolved.] 

• On SRX3600 devices, with a large number of tunnel routes added, memory utilization 

can become very high. [PR797845: This issue has been resolved.] 


465



• On all high-end SRX Series devices, an RG-0 failover after ISSU completes (both nodes 

have been upgraded and have joined the cluster with priorities restored) caused the 

new RG-0 secondary node to restart all FPCs. This lead to an RG-1+ failover. [PR770710: 



• On SRX Series devices, when the syn-cookie feature is enabled along with syn-flood 

screen with a low timeout value, high latency TCP sessions may fail to establish 

successfully. The clients sessions receive unresponsive connections because the SRX 

device has timed out the flow for this session. The device will also drop subsequent 

packets from the client due to no state found. The workaround is to increase the timeout 

value to at least 6 seconds or more. [PR692484: This issue has been resolved.] 


• On all high-end SRX Series devices, when two or more IDP policies are configured in 

the root LSYS and one policy is active in the root LSYS and a different policy is active 

in the custom LSYS, the referenced LSYS policy may not get compiled properly after 

a signature update. [PR749126: This issue has been resolved.] 

J-Web 

• On all high-end SRX Series devices with more than one SPCs installed J-Web can only 

view the flow sessions from one SPC. Flow sessions on other SPCs can not be displayed. 


• On all high-end SRX Series devices, when you login to J-web it displays 'JWEB is not 

supported on this platforms' message. [PR781659: This issue has been resolved.] 


• On SRX5800 devices, when using IKE-ESP-NAT ALG for pass through for Cisco EZ-VPN 

client, the IKE handshake might not be successful because IKE packet coming from 

VPN server gets dropped. [PR791549: This issue has been resolved.] 


Gateways 


• On SRX5800 devices, fragmented packets with the DF bit set (do not fragment) were 

dropped by the device when processed by the DNS ALG. [PR754504: This issue has 



• On all high-end SRX Series devices, when devices operate in chassis cluster, a maximum 

8 queues per interface configuration is not getting reflected on interface part of the 

cluster setup. [PR389451: This issue has been resolved.] 

466 



• On all high-end SRX Series devices, when the secondary node reboots or shutdown, 

there could be a transient traffic drop on the primary node. The amount of drop depends 

on the number of active sessions. The drop is caused by route change and RTO cold 

synchronization during secondary reboot. After route change and RTO cold 

synchronization is complete, the traffic would be normal, the drop time window may 

be a few seconds. [PR734966: This issue has been resolved.] 

• On SRX3600 devices, when configuration is saved on a remote file server, absolute or 

relative path needs to be used where the file have to be stored. If the path is not used 

in a cluster, it fails to save. It works fine on standalone devices. [PR752363: This issue 



• On SRX3400 devices, flow sessions on backup node could not be cleared previously. 


• On SRX1400 devices, show security pki *-certificate command was showing time 

without time-zone. [PR746785: This issue has been resolved.] 

• On all high-end SRX Series devices, updating application-identification signatures 

might trigger a kernel heap memory corruption and generate flowd core dump while 

processing application traffic. [PR769832: This issue has been resolved.] 

• On all high-end SRX Series devices, for IKEv2, when SRX tries to do a dpd exchange 

when an existing exchange is in progress, a core may be seen. Please note that this is 

applicable to only IKEv2. [PR771234 : This issue has been resolved.] 


• On SRX5600 devices, ISSU from 11.4R3.6 to 12.1R1.9 will not proceed on the 1k/3k and 

5k clusters. The upgrade will not occur due to the following error: 'ISSU not supported 

due to rt request TLV for target table address family'. [PR770478: This issue has been 

resolved.] 

• On all high-end SRX Series devices, an RG-0 failover after ISSU completes (both nodes 

have been upgraded and have joined the cluster with priorities restored) caused the 

new RG-0 secondary node to restart all FPCs. This lead to an RG-1+ failover. [PR770710: 



• On all high-end SRX Series devices, track IP (ipmon) feature was not working for VLAN 

tagged reth interface. [PR575754: This issue has been resolved.] 

J-Web 

• On SRX3400 devices, if multiple J-Web clients are connected to a single device, it 

caused high CPU usage on the routing engine. [PR741432 : This issue has been resolved.] 

• On SRX3400 devices, the J-Web interface is vulnerable to HTML cross-site-scripting 

attacks, also called XST, or Cross-Site-Tracing. [PR752398: This issue has been 

resolved.] 


467


• On all high-end SRX Series devices, when you login to J-web it displays 'JWEB is not 

supported on this platforms' message. [PR781659: This issue has been resolved.] 


• On SRX5600 and SRX5800 devices, using the same source NAT pool by both NAT 

and NAT-PT traffic causes core dump. [PR736374: This issue has been resolved.] 

• On all high-end SRX Series devices, the commit of static nat rules may fail when commit 

LSYS interfaces, security zone, and NAT are committed at the same time. Issue also 

occurs during the commit of static nat rules if you commit security zone and NAT at 

the same time. [PR756240: This issue has been resolved.] 


Gateways 


• On SRX3400 devices, for the application tracking services, the application statistics 

were not incremental when there was an already existing application cache entry for 

that specific application. [PR743449: This issue has been resolved.] 


• On all high-end SRX Series devices, in chassis cluster mode, when LACP is configured 

on a remote switch which is connected to a reth interface, and the control link between 

nodes is lost, it causes both nodes to become primary. [PR733335: This issue has been 

resolved.] 

• On all high-end SRX Series devices, when the secondary node reboots or shutdown, 

there could be a transient traffic drop on the primary node. The amount of drop depends 

on the number of active sessions. The drop is caused by route change and RTO cold 

synchronization during secondary reboot. After route change and RTO cold 

synchronization is complete, the traffic would be normal, the drop time window may 

be a few seconds. [PR734966: This issue has been resolved.] 


• On SRX3400 devices, if BOOTP/DHCP relay is configured with the receiving or 

forwarding interfaces in an LSYS, the DHCP request packets are not forwarded to the 

DHCP server. [PR731723: This issue has been resolved.] 


• On SRX5600 devices, some CP binding entries cannot age out in chassis cluster z 

mode after stress test. [PR611827: This issue has been resolved.] 

• On all high-end SRX Series devices, the additional neighbor solicitation packets that 

are sent are corrupted in the form of zeroed destination MAC address and the entire 

packet is prefixed by two random bytes. [PR671658: This issue has been resolved.] 

• On all high-end SRX Series devices, when a large number of inbound HTTP connections 

are established over an extended period of time, the HTTP process (httpd) might get 

trapped in a spinlock, resulting in high CPU utilization. The CPU load continues even 

468 



after a stream of connection attempts is terminated. To reduce the CPU load, you 

must stop the process from the shell. [PR693434: This issue has been resolved.] 

• On SRX5600 devices, the Key Management Daemon (KMD) may restart when you 

change the configuration from Dynamic End Point (DEP) to shared IKE. [PR702222: 


• On SRX1400 devices in a chassis cluster, the primary control link heartbeats are not 

seen and are causing inconsistent system behavior. This happens when a 16-Port SFP 

Gigabit Ethernet I/O card or a 16-Port Copper Ethernet/Fast Ethernet/Gigabit Ethernet 

I/O card is installed on the device. [PR718054: This issue has been resolved.] 

• On all high-end SRX Series devices, when you run NTP-related show commands, such 

as show ntp status, incorrect output might be displayed. [PR722528: This issue has 


• On all high-end SRX Series devices, on rare occasions, the CP session counter got an 

incorrect value, which triggered the CP/Flow session table full alarm. This was because, 

the flow table was not full and the alarm was incorrectly set due to the wrong session 

counter value. [PR725099: This issue has been resolved.] 

• On SRX5600 devices, NSD core file may be generated. [PR725908: This issue has been 

resolved.] 

• On SRX5600 devices, after commit involving re-ordering of security policies, it may be 

observed that a core dump is created in FWDD. [PR726791: This issue has been 

resolved.] 

• On SRX3600 devices, where large volume of firewall-authentication requests and 

changes of security policy happen at exactly same time, device may crash due to race 


• On SRX3400 devices, when RTSP ALG is enabled, RTSP traffic might cause the flowd 

process to crash and generate core dump. [PR729296: This issue has been resolved.] 

• On SRX3400 devices, flow sessions on backup node could not be cleared previously. 


• On all high-end SRX Series devices, in certain circumstances when anti-spoofing screen 

is enabled, neighbor discovery messages may be dropped after a neighbor becomes 

unreachable and then reachable again. [PR734423: This issue has been resolved.] 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, sometimes, traffic sent 

by authenticated users (authenticated by web authentication) will not pass through 

the firewall. This is because, authentication entry created in CP was not getting passed 

along to SPU. [PR734869: This issue has been resolved.] 

• On all high-end SRX Series devices, flowd core occurred after upgrading to 11.2R5 as 

the mbuf was not cleaned up. [PR734885: This issue has been resolved.] 

• On SRX3600 devices, abnormal SQL traffic might cause the flowd process to crash 

when SQL ALG is enabled. [PR737468: This issue has been resolved.] 

• On all high-end SRX Series devices, the application-groups statistics were displayed 

as unassigned and unknown for the show services application-identification statistics 


469


application-groups command outputs without displaying the details. [PR740014: This 


• On all high-end SRX Series devices, after 24 hours of slt4 stress run, with a huge number 

of sessions generated, IDP sessions were not increasing along with the flow sessions. 


• On all high-end SRX Series devices, the TCP initial timeout minimal limitation in CLI 

set security flow tcp-session tcp-initial-timeout is changed from 20 seconds to 4 seconds. 

The new range is 4-300 seconds. Setting this timeout to a small value may increase 

the possibility of failing to create TCP sessions. [PR747769: This issue has been 

resolved.] 

• On all high-end SRX Series devices, with syn-flood and session limitation screen feature 

enabled, when there are 16k or more source/destination IP, the CPS data may drop 

50%. [PR773162: This issue has been resolved.] 

• On SRX5800 devices, with syn-flood and session limitation screen feature enabled, 

when there are 16k or more source or destination IP, the CPS data may drop 80%. 


Installation and Upgrade 

• On SRX3400 devices, if 11.4R2 is upgraded on a router which has a base image lower 

than 11.4R2 and a base image other than 10.4R10, then the validation fails and upgrade 

will be aborted. [PR698724: This issue has been resolved.] 

• On SRX3400 devices, inserting a defective SFP causes all SFPs to be unrecognized. 


• On SRX3600 devices, SFP-T port was not correctly detected when unplugged and 

reinserted [PR723844: This issue has been resolved.] 

• On SRX3600 and SRX5600 devices, the Network Security Daemon (NSD) core was 

resolved. [PR735152: This issue has been resolved.] 


• On all high-end SRX Series devices, track IP (ipmon) feature does not work for VLAN 

tagged reth interface. [PR575754: This issue has been resolved.]] 

• On SRX5800 devices, when RPF-check is enabled on reth interfaces, the data packets 

might get dropped. [PR697812: This issue has been resolved.] 

• On SRX5600 and SRX5800 devices, regarding the K2-RE (64-bit Routing Engine) 

when speed or link mode is statically configured on the router for the fxp0 interface, 

the driver for fxp0 accepts the configuration from DCD process, but does not propagate 

the setting to the hardware driver. Instead, the driver setting is forced to auto-negotiate. 

Thus, as the fxp0 interface is auto-negotiating, and the far end device is forced to 

100/full, the auto-negotiation on fxp0 will detect the speed but not the duplex and 

defaults that duplex to half-duplex. [PR704740: This issue has been resolved.] 

470 




• On SRX5800 devices, when the device is processing several thousands of transit IPsec 

sessions through ike-esp-nat ALG, after sometime, new sessions might fail. [PR671074: 


• On all high-end SRX Series devices, occasionally, policy-based IPsec VPN, that has 

been established successfully does not allow traffic to the protected resources. 


• On SRX5800 devices, in some IPsec VPN scenarios where RG1+ failover happens 

consecutively and in short periods of time (less than 5 minutes), there is a chance that 

ESP sequence number will not be synchronized on the other cluster node. As a 

consequence, after the fail over traffic is sent inside the IPsec tunnel but with a wrong 

ESP sequence number. This can cause traffic blocking on the remote VPN , if the remote 

peer has anti-replay functionality enabled. [PR753683: This issue has been resolved.] 


• On SRX3600 devices, IDP configured on Junos OS release 11.4R1, the output of the 

command show security idp policy-commit-status incorrectly displays “Active policy 

not configured” even when active policy is configured. [PR741736: This issue has been 

resolved.] 

IPv6 

• On all high-end SRX Series devices, the spoofing screen was dropping IPv6 packets 

sourced from unspecified addresses (0:0:0:0:0:0:0:0/128 or ::/128). [PR721913: This 


• On SRX5800 devices, IPv6 packets are getting dropped when source or destination 

session limit screening is configured [screen ids-option XXX limit-session 

(source-ip-based | destination-ip-based)] and applied to the security zone. [PR728802: 


• On SRX5800 devices, the NP hash feature may not work with IPv6 for the cross virtual 

router (VR) traffic. [PR738812: This issue has been resolved.] 

• On all high-end SRX Series devices, the flow bytes counters tracked on a per-interface 

basis are incorrect for IPv6 flows. The flow input bytes statistics are correct, but flow 

output bytes statistics are reversed to the source/destination interfaces. [PR740911: 


J-Web 

• On all high-end SRX Series devices, the Application Tracking monitor page does not 

display the warning no data to display, when there is no data to display in the table. 


• On SRX1400 devices, authentication through J-Web fails if the password contains any 

of the following special characters: ' " + \ . [PR725901: This issue has been resolved.] 


471


• On SRX1400 devices, on the Configure>Security>Policy Elements>Address 

Book>Address Sets page in the J-Web interface, the nested address-sets are not 

displayed and cannot be configured. [PR726227: This issue has been resolved.] 

• On all high-end SRX Series devices, on the Configure>Security>Logging page in the 

J-Web interface, the Apply button will remain disabled even after changing the 


• On SRX3600 devices, an error is displayed when modifying an address object in the 

address book from IP prefix to domain name and domain name to IP prefix. [PR732799: 


• On SRX1400 devices, when you access J-Web -> Dashboard -> Chassis view, the 

SYSIO slot is blacked out or grayed out. [PR738772: This issue has been resolved.] 


• On SRX3600 devices, all keyword was not available in few logical systems related 

CLIs. [PR598032: This issue has been resolved.] 


• On all high-end SRX Series devices, flowd core files are generated when persistent 

NAT binding entries are cleared. [PR697856: This issue has been resolved.] 

• On SRX5600 and SRX5800 devices, using the same source NAT pool by both NAT 

and NAT-PT traffic causes core dump. [PR736374: This issue has been resolved.] 

• On SRX3600 devices, the SCTP packets are dropped when NAT is configured on the 

device. Use the srx-cprod.sh -s spu -c sh usp jsf counter gprs-sctp command to verify 

the packet drops. [PR738759: This issue has been resolved.] 

• On SRX3600 devices, under certain circumstance, reverse static NAT might not work 

correctly. Fix ported in 10.4R10, 11.2R7, 11.4R3, 12.1R2 and onwards. [PR739142: This issue 



• On SRX3400 devices, if the certificate key size is 2048 bytes and the total combined 

certificate request size is greater than 4096 bytes, then the PKID service might crash 

on certificate enrollment. [PR698846: This issue has been resolved.] 


Gateways 


• On SRX3400 devices, when the SCTP ALG receives an initial acknowledgment 

(INIT-ACK), we record the cookie_length in association. If the cookie length is not a 

multiple of four, the device pads it to a multiple of 4. For example, the length in the 

INIT-ACK is 183, but you save 184 in association. When the cookie echo comes, the 

device compares the cookie length in the packet with the recorded cookie length in 

association. However, it is a not padded value; that is, it is still 183 in the cookie length 

472 



field of the cookie echo. Therefore, the comparison fails, and the log shows the cookie 

as invalid. [PR671238: This issue has been resolved.] 

• On SRX5600 devices in chassis cluster, if the ALG traffic is too high and twin ports are 

used up, some single ports on backup node might leak. [PR705799: This issue has been 

resolved.] 


• On all high-end SRX Series devices, firewall authentication supported a maximum of 

64 users or groups in policy “client-match”. [PR661587: This issue has been resolved.] 


• On SRX3400 devices in a chassis cluster, while monitoring the device through J-Web, 

the dashboard incorrectly displayed the session utilization value. The displayed value 

was above 100 percent and activated or maximum sessions were displayed as 3M or 

2.5M. The dashboard incorrectly displayed the combined values of both primary and 

secondary nodes. [PR666489: This issue has been resolved.] 

• On SRX1400 devices, a timing error is observed at the system I/O (sysio) interface, 

which connects to IOC in slot 2. You can enable chassis cluster on the sysio ports, but 

do not use the IOC card in slot 2 for Junos OS Release 11.4. [PR680832: This issue has 


• On SRX3400 devices, when chassis cluster failover route change is triggered and 

service-offload session will be reinstalled, if one service-offload session is multicast 

session in the master node, then that session will be synched and installed as normal 

session in backup node because the services-offload flag not being correctly sync to 

backup. [PR696819: This issue has been resolved.] 

• On SRX5800 devices in a chassis cluster, if ALG traffic was too high and both the ports 

were used, some single ports on backup caused traffic outflow. [PR705799: This issue 



• On SRX3600 devices, the DHCP relay server was required to have DNS configuration 

for DHCP clients. The DHCP daemon read the DNS configuration and the daemon was 

stopped when there was an invalid dns-server value (for example, 0.0.0.0). [PR706615: 


J-Web 

• On all high-end SRX Series devices, on the Configure>Security>Policy>Define AppFW 

Policy> Add Rule Set page in the J-Web interface , the Default Rule was getting 

displayed, leading to incorrect configurations. [PR593551: This issue has been resolved.] 

• On SRX3600 devices, policy validating pop-up window cannot be cleared after you 

drag on it. [PR675554: This issue has been resolved.] 

• On all high-end SRX Series devices, using CLI you can configure only an AppQoS rule 

set without configuring any other diff-services. However, in J-Web, you should configure 


473


at least one diff-service for a new AppQoS rule set configuration. [PR686462: This 


Flow and processing 

• On SRX3600 devices, preempt can occur to the designated primary node with priority 

0 on RG1+ if the designated secondary node is currently working as the primary node. 


• On all high-end SRX Series devices, changes in policer, filter, or sampling configuration 

results in generation of core files when receiving the multicast traffic. [PR613782: This 


• On SRX5800 devices, memory usage on SPU by the KMD process might raise 

unexpectedly, causing VPN tunnel setup problems. 

Once the process reaches the memory usage limit, the following message will be 

logged: 

Jun 20 09:19:46 HOSTNAME (FPC Slot N, PIC Slot M) kernel: Process (176,kmd) 

attempted to exceed RLIMIT_DATA: attempted 262164 KB Max 262144 KB 


• On SRX3400 devices, failover with the RG0 and RG1 is resulting in vmcore file. 


• On SRX5600 devices, when GPRS tunneling protocol (GTP) is enabled and when there 

are GTP-wide conflicts hashed in the same buckets, a core file is generated. [PR680822: 


• On all high-end SRX Series devices, the Link failure happened for DPC%d PFE%d log 

message displayed an incorrect FPC number. [PR683371: This issue has been resolved.] 

• On all high-end SRX Series devices, a data plane failover resulted in a traffic loss for 

a short period when the device was active with a large number of routes. [PR690004: 


• On all high-end SRX Series devices, the show class-of-service application-traffic-control 

statistics rule command currently displays the number of packets that arrive in a session. 

The command should actually display the number of sessions. [PR690691: This issue 


• On all high-end SRX Series devices, the option to manually recover policy mismatch 

between RE and SPU is not available. [PR691815: This issue has been resolved.] 

• On all high-end SRX Series devices, under some environments, the DIP4 errors are 

reported for SPCs, resulting in occasional packet drop. [PR695905: This issue has been 

resolved.] 

• On SRX3400 devices, when chassis cluster failover route change is triggered and 

service-offload session will be reinstalled, if one service-offload session is multicast 

session in the master node, then that session will be synched and installed as normal 

session in backup node because the services-offload flag not being correctly sync to 

backup. [PR696819: This issue has been resolved.] 

474 



• On SRX5600 devices, when IKE and IPsec configuration or security configuration is 

removed and added back frequently, KMD core files might be generated. [PR698718, 

PR698666: This issue has been resolved.] 

• On all high-end SRX Series devices, a memory leak occurs during the audit event 

processing. [PR698907: This issue has been resolved.] 

• On all high-end SRX Series devices, the PIM register messages were dropped on the 

physical interfaces that hosted multiple unnumbered interfaces. [PR698943: This issue 


• On SRX5600 devices, the message vector create_pdp_rsp changes tunnel state from 

half to active and inserts it into active timer wheel. These actions result in no tunnel 

lock protection. When del_pdp_rsp deletes the user tunnel or clear path, this leads to 

a change in both the aging flag and the timer wheel entry pointer. [PR699147: This 


• On SRX3600 devices, when a client started a new TCP session using the same 5 tuples 

as the existing TCP session (which was terminated within 2 seconds) and FIN/ACK, 

the new TCP session was allowed for a short time and then the device dropped all 

subsequent packets from client or server. When this issue occurred, the device allowed 

only the new TCP handshake packets and then dropped all the subsequent traffic that 

belonged to newly created session. [PR700301: This issue has been resolved.] 

• On SRX3600 devices, when you configured services-offload and when IOC cards were 

plugged in slot 4 or above, the following warning message was not displayed: 

In services offload mode, IOC cards must be in the first four slots (slot0 

- slot3). 


• On SRX1400 devices in a chassis cluster, unwanted timed out data path trace messages 

were seen. [PR703272: This issue has been resolved.] 

• On SRX5600 devices, the JSRPD used the IIC device to set chassis cluster LED. The 

JSRPD, whose function is jsrpd_a2a10_set_led_color() function, was trigged when the 

ge-0/0/2 interface was down. The jsrpd_a2a10_set_led_color() function did not close 

when the LED color set function was done. This behavior caused the FD leak and 

eventually resulted in the generation of the JSRPD core file. [PR703799: This issue has 


• On all high-end SRX Series devices, flowd core files were generated during stress test. 


• On all high-end SRX Series devices, the following warning messages were not displayed: 

• When heap and/or arena memory utilization reached a certain critical level: 

• Warning: Heap utilization reaches critical level! 

• Warning: Arena utilization reaches critical level! 

• When the memory utilization fell back below the critical level: 

• Heap utilization falls back to normal level 

• Arena utilization falls back to normal level 


475



• On SRX5600 devices, packets of packet-length 500 bytes get corrupted when only 

packet capture of data path debug is present without record-pic-history and event 

np-egress. [PR706858: This issue has been resolved.] 

• On all high-end SRX Series devices, when you add or change policy configuration within 

groups, the policies may not get applied correctly. The applied configuration might be 

valid and therefore will pass the configuration check but the process uses that policy 

(depending on configuration) might terminate and restart. [PR707817: This issue has 


• On SRX1400 devices in a chassis cluster, the primary control link heartbeats are not 

seen and are causing inconsistent system behavior. This happens when a 16-Port SFP 

Gigabit Ethernet I/O card or a 16-Port Copper Ethernet/Fast Ethernet/Gigabit Ethernet 

I/O card is installed on the device. [PR718054: This issue has been resolved.] 

• On all high-end SRX Series devices, on rare occasions, the CP session counter got an 

incorrect value, which triggered the CP/Flow session table full alarm. This was because, 

the flow table was not full and the alarm was incorrectly set due to the wrong session 

counter value. [PR725099: This issue has been resolved.] 

• On SRX3600 devices, where large volume of firewall-authentication requests and 

changes of security policy happen at exactly same time, device may crash due to race 


• On SRX3400, SRX3600, SRX5600, SRX5800 devices, sometimes, traffic sent by 

authenticated users (authenticated by web authentication) was not passing through 

the firewall. This is because, authentication entry created in CP was not passed along 

to SPU. [PR734869: This issue has been resolved.] 

Installation 

• On all high-end SRX Series devices, while downgrading from Junos Release 11.4 or a 

later image to Junos Release 11.1 or an earlier image, the security package was deleted. 

Although it was automatically installed when the IDP daemon came up, this automatic 

installation failed sometimes due to application identification (AI) installation error. 



• On SRX3600 devices, when a firewall filter is configured on the lo0 interface, the 

firewall log might show incorrect address or port information for the IKE packets. 


• On SRX5800 devices, under certain conditions, deleting an fxp0 configuration and 

rolling it back, set the fxp0 forcefully to nonnegotiated, 100M/full duplex mode. 


• On SRX3400 devices, during failover, there is a small window of time in which the SPU 

does not detect whether an NP is in services-offload mode or not. This might cause a 

small number of the services-offload sessions to change to normal sessions. [PR697426: 


476 



• On SRX3400 and SRX3600 devices, the reth interface did not work properly when you 

changed the reth member interfaces to other interfaces using different speeds and the 

link speeds were mismatched. [PR698837: This issue has been resolved.] 

• On SRX3600 devices, a session drop due to not being authenticated was logged as 

RT_FLOW_SESSION_CLOSE and had the wrong close reason other than unset. 


• On SRX5600 devices, during GTP-in-GTP detection, the spare bytes in the GTPv0's 

packet header are 10, 11, and 12. These three bytes need to be set with 0xff, but it is not 

a mandatory requirement in 3GPP TS. You can set the GTP-in-GTP denied feature, 

and check these bytes as a mandatory field. If the value of all three bytes is not equal 

to 0xff, then the packet is not GTPv0 and is allowed to pass the firewall. As a result, 

some malform attack packets might get through the firewall. [PR703267: This issue 


• On SRX1400 devices, RTSP interleave data packets cannot be passed when the RTP 

length is above 3K Bytes. [PR703663: This issue has been resolved.] 

• On SRX5600 and SRX5800 devices, using ftp to st0 interface for data transfer fails 

occasionally. [PR706827: This issue has been resolved.] 


• On SRX3400 and SRX3600 devices, initial contact notification sent from peer for the 

IKEv1 protocol was not getting processed. Because of this, stale IKE and IPsec security 

association were displayed. However, functionality was not affected. [PR705123: This 


• On all high-end SRX Series devices, occasionally, when keys are generated incorrectly 

for IPsec, VPN to go down due to encapsulation security payload (ESP) failures. 



• On SRX5600 devices, loading the IDP detector might cause a flowd crash, showing 

memcpy as the top of the stack. [PR570361: This issue has been resolved.] 

J-Web 

• On SRX1400 devices, when modifying an existed policy or creating a new policy with 

junos-host zone in J-Web, there is no junos-host zone available in the from-zone or 

to-zone list. [PR697863: This issue has been resolved.] 


• On all high-end SRX Series devices, after a logical systems high availability ISSU, the 

application firewall rule matched session counter was set to an incorrect value (-1) 

when a new session triggered an application firewall rule lookup. [PR704979: This issue 


• On SRX1400 devices, the LSYS capacity number for nat-rule-referenced-prefix lsys 

profile was displayed incorrectly. [PR707108: This issue has been resolved.] 


477



• On SRX3600 devices, when there is heavy SIP traffic and share gate is involved, NAT 

translation-context might leak. [PR675869: This issue has been resolved.] 

• On all high-end SRX Series devices, static NAT with default routing instance does not 

work. [PR706183: This issue has been resolved.] 

• On all high-end SRX Series devices, when you configure two static NAT rules in default 

routing-instance with same prefix, one rule is configured without static-nat prefix 

routing-instance default, and the other rule is configured with static-nat prefix 

routing-instance default, the configuration is committed successfully without 

overlapped prompt information. [PR708433: This issue has been resolved.] 

• On SRX5600 devices, during high-rate NAT session creation, high CPU usage might 

be seen on the central point on the backup node. [PR720010: This issue has been 

resolved.] 

SNMP 

• On SRX3400, SRX3600, SRX5400, SRX5600 devices, health monitor feature under 

SNMP might send out false alarm of high CPU utilization. [PR610450: This issue has 


Upgrade and Downgrade 

• On all high-end SRX Series devices, upgrade failed for Junos OS Release 11.1R6.4 to 

11.4R2.3 build due to AI installation failure without xcommit result. [PR729625: This 



• On SRX3600 devices, after RG0 failover, packet loss is seen through VPNs. [PR604640: 


• On SRX5600 devices in a large configuration with heavy traffic, after reboot failover 

in chassis cluster, the Routing Engine on the new primary node becomes very busy. As 

a result, the FPC might detach, causing traffic to fail when passing through the firewall 

device. [PR698150: This issue has been resolved.] 

478 




Gateways 


• On SRX5600 devices in a chassis cluster, when 12-KB traffic was sent, RG1 and RG2 

failover occurred with a resource manage error. [PR601784: This issue has been 

resolved.] 


• On SRX5600 devices, ISSU took additional time when network traffic was heavy. If 

the ISSU process duration was longer than 1 hour, it aborted automatically without 

completing the upgrade. [PR585873: This issue has been resolved.] 

• On SRX3600 devices in a chassis cluster, some interfaces on node 0 showed 

unspecified speed and half-duplex. [PR597575: This issue has been resolved.] 

• On SRX5800 devices, chassis cluster was not failing over redundancy groups 

automatically when one node experienced certain hardware errors (HSL2 link CRC 

errors). [PR606594: This issue has been resolved.] 

• On SRX1400 devices, a timing error is observed at the system I/O (sysio) interface, 

which connects to IOC in slot 2. You can enable chassis cluster on the sysio ports, but 

do not use the IOC card in slot 2 for Junos OS Release 11.4. [PR680832: This issue has 



• On all high-end SRX Series devices, predefined applications and application groups 

are editable. However, changes made to them were not persistent across application 

identification signature or IDP signature database upgrades, and commit failed. 


• On SRX5800 devices in NAT mode, flowd crashed due to kernel memory corruption 

that was triggered by a race condition when the IDP module was maintaining the ASC 

(application system cache) pool. [PR579242: This issue has been resolved.] 

• On SRX3400, SRX3600, and SRX5600 devices, hostbound traffic BFD session state 

did not change from the init state. [PR601310: This issue has been resolved.] 

• On SRX1400, SRX3400, and SRX3600 devices, when the receiver for a multicast group 

was in dense mode, no multicast traffic was observed. [PR601850: This issue has been 

resolved.] 

• On SRX5800 devices, data plane security logs sent in security log mode stream were 

emitted with the facility encoded to UUCP. The PRI value has been changed to correctly 

show the USER facility in the system logs sent directly from the data plane. This change 

does not effect logs sent from the Routing Engine. [PR663022: This issue has been 

resolved.] 

• On SRX3400 devices, the SIP datagrams were being reordered, resulting in a rejection 

of the INVITE message from the X-Lite client to the other user. [PR667420: This issue 



479


• On SRX3400 devices, small packets were dropped when preserve-trace-order or 

record-packet-history was enabled during data path debugging. [PR671900: This issue 


• On SRX3400 devices, in transparent mode EBGP session timeout was not updated, 

causing sessions to close after 20 seconds. [PR671942: This issue has been resolved.] 

Installation and Upgrade 

• On SRX1400 devices, when you upgraded or downgraded to an earlier or later Junos 

OS version and upgraded or downgraded the data path FPGA images, the traffic did 

not flow through the device immediately after the upgrade or downgrade was complete. 

The fabric (HSL2) links of the SPC and NPC cards were prematurely reported as being 

in fault, reset, or error state following an automatic upgrade or downgrade of the FPGAs. 



• On SRX5800 devices, removing the ip-block action statement from the IDP 

configuration blocked the applicable traffic. [PR599245: This issue has been resolved.] 


• On SRX5800 devices, when more than 10 member links were added to an aggregate 

bundle and then to a class-of-service process, sometimes core files were generated 

and devices restarted due to memory corruption and the process. [PR613422: This 



• On SRX5600 devices, there were issues with support for GTPv2 and GTP ISSU failure 

between Junos OS Release 11.2 and later releases. [PR664202: This issue has been 

resolved.] 

IPv6 

• On SRX3600 devices, the IPv6 self-traffic caused flowd_xlr files to be generated. 


• On SRX3400 devices, in some cases IPv6 flow sessions were overwriting other memory, 

causing incorrect statistics or memory corruption. The memory corruption triggered 

generation of a flowd core file. [PR672794: This issue has been resolved.] 

J-Web 

• On all high-end SRX Series devices, you were unable to make custom column alignment 

on the UTM policy and Zone configuration pages. [PR667207: This issue has been 

resolved.] 

• On SRX3400 devices, sometimes J-Web did not populate content properly. [PR671805: 


480 




• On SRX3400 devices, when NAT64 was used in logical system (LSYS), the binding 

did not age out and the reversed binding did not match successfully. The NAT64 in 

LSYS function did not work. [PR675052: This issue has been resolved.] 

• On SRX3400 devices, when you configure LSYS and then load override configuration 

with different LSYS (both having the old and new LSYS) configuration, the proxy-ndp 

route might fail to push to the Packet Forwarding Engine. If you delete old LSYS and 

add new LSYS in one commit, the proxy-ndp route might also fail to push to the Packet 


• On SRX5600 devices in a chassis cluster, some NAT sessions might keep invalidated 

status after multiple failovers. [PR676385: This issue has been resolved.]] 


• On SRX3400 devices, when DUT was configured with the maximum reference number 

of address-books in source NAT or destination NAT, the Routing Engine and Packet 

Forwarding Engine were different. [PR580201: This issue has been resolved.] 

• SRX1400 devices supported only 256 destination NAT pools; this number did not 

match the specification sheet of 4096. [PR598474: This issue has been resolved.] 

• On SRX3600 devices, under certain specific circumstances, interface-based source 

NAT resources leaked. [PR613300: This issue has been resolved.] 

Management Information Base (MIB) 

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when polling the device 

with 5 SPC's and 3 SPC's, the device reports wrong number of sessions for the object 

ID jnxJsSPUMonitoringMaxTotalSession (1.3.6.1.4.1.2636.3.39.1.12.1.3.0). [PR488653 


• On SRX5800 devices, the NAT SNMP MIB snmp mib jnxJsNatSrcNumSessions counter 

was not refreshed until the walk command was issued. [PR663788: This issue has 



• On SRX3600 devices, KMD core files were generated after users deleted and re-added 

VPN configurations. [PR560932: This issue has been resolved.] 

• On SRX3600 devices, the secondary node of the dynamic endpoint tunnel IP did not 

update correctly during cold synchronization. [PR604640: This issue has been resolved.] 

Related 

Documentation 


page 417 


on page 443 




481


Errata and Changes in Documentation for Junos OS Release 11.4 for High-End SRX Series 


Errata for the Junos OS Software Documentation 

This section lists outstanding issues with the software documentation. 

Feature Support Reference 

• Table 42: PKI Support in this guide incorrectly states that IKE Diffie-Hellman Group 14 

support and digital signature generation are not supported on the SRX1400 device. 

IKE Diffie-Hellman Group 14 support and digital signature generation are supported 

on all SRX Series devices. 

Junos OS CLI Reference 

• The Description for the limit (Security SCTP) option under the hierarchy edit security 

gprs sctp profile profile-name, incorrectly states you can set the global messages rate 

limit per session. The description should say that you can set the rate limit for local 

Services Processing Unit (SPU) packets. 

• In this guide, the apply-groups (Chassis Cluster) statement has been added to the 

“Chassis Hierarchy and Statements” section. 

• In the Security Hierarchy and Statements section, the edit security forwarding-options 

statements are missing the following: 

• A note indicating that packet-based processing is not supported on the following 

SRX Series devices: SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800. 

• A link in the Related Topics section to the Junos OS Feature Support Reference for 

SRX Series and J Series Devices. 

• The Junos OS CLI Reference is missing information about the value for the messages 

received field in too-many-requests (Security Antivirus Fallback Options) command 

the following statement is updated with a value for the limit as: 

If the total number of messages received concurrently exceeds 4000. 

• The Junos OS CLI Reference is missing information about the operational CLI command, 

show configuration chassis cluster traceoptions, which is used to display chassis cluster 

redundancy process trace options. 

user@host>show configuration chassis cluster traceoptions 

file chassis size 10k files 300; 

level all; 

• The Junos OS CLI Reference incorrectly specifies the IPsec proposal options in 

proposal-set (IPsec) section. The IPsec proposals should be as follows: 

• basic—nopfs-esp-des-sha and nopfs-esp-des-md5 

• compatible—nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha, and 

nopfs-esp-des-md5 

• standard—g2-esp-3des-sha and g2-esp-aes128-sha 

482 


Errata and Changes in Documentation for Junos OS Release 11.4 for High-End SRX Series Services Gateways 

Junos OS Interfaces Configuration Guide for Security Devices 

• In this guide, Table 11, "MTU Values for the SRX Series Services Gateways PIMs," does 

not specify the maximum MTU and default IPMTU values for the following PIMs: 

• 2-Port 10 Gigabit Ethernet XPIM 



The following table lists these values: 

Table 28: MTU Values for the SRX Series Services Gateways PIMs 

PIM 

DefaultMediaMTU(Bytes) 

MaximumMTU(Bytes) 

DefaultIPMTU (Bytes) 

2-Port 10 Gigabit Ethernet XPIM 

1514 

9192 

1500 

16-PortGigabitEthernetXPIM 

1514 

9192 

1500 

24-Port Gigabit Ethernet XPIM 

1514 

9192 

1500 

Junos OS Layer 2 Bridging and Switching Configuration Guide for Security Devices 

• In this guide, the section “Configuring Layer 2 Bridging and Transparent Mode” includes 

an incorrect example, "Example: Configuring Layer 2 Trunk Interfaces with Multiple 

Units." The example is in error because the SRX Series devices do not support multiple 

units. 

Junos OS Logical Systems Configuration Guide for Security Devices 

• The Junos OS Logical Systems Configuration Guide for Security Devices does not list the 

SRX1400 as a device that supports the logical systems feature. Starting with Junos 

OS Release 11.4R1, SRX1400 devices support the logical systems feature. This support 

is in addition to existing support on SRX3400, SRX3600, SRX5600, and SRX5800 

devices. 

Junos OS Monitoring and Troubleshooting Guide for Security Devices 

• In the “Example: Enabling Packet Capture on a Device” section, the CLI quick 

configuration shows an incorrect set command. The correct set command is set 

forwarding-options packet-capture file filename pcap-file files 100 size 1024 

world-readable. 

Junos OS Security Configuration Guide 

• In Junos OS Release 11.1 of this guide, “Figure 1: Traffic Flow for Flow-Based Processing” 

is incorrect. The correct flow diagram is available in Junos OS Release 12.1 of this guide. 

• In this guide, the section “Understanding Chassis Cluster Redundancy Group Interface 

Monitoring” has a misleading statement in the steps describing the “Policy Lookup for 

a User” figure. It states that the device forwards the packet from its buffer to its 

destination IP address 1.2.2.2. However, this is true only for HTTP and Telnet traffic. 


483


For FTP traffic, after successful authentication the device closes the session and the 

user must reconnect to the FTP server at IP address 1.2.2.2. 

• In Chapter 48, “AppTrack Application Tracking,” of the Junos OS Security Configuration 

Guide for Security Devices, the operational command show security application-tracking 

statistics applications is incorrect. The operational command to display all application 

identification statistics, including application tracking statistics, is show services 

application-identification statistics applications. 

The operational command show application-tracking counters is incorrect. The 

command should be show security application-tracking counters. 

• The “Understanding DNS Doctoring” section incorrectly states that the DNS ALG will 

not drop traffic if the DNS message length exceeds the configured maximum, if the 

domain name is more than 255 bytes, or if the label length is more than 63 bytes. 

This section has been corrected as follows: The DNS ALG will not drop traffic if the 

DNS message length exceeds the configured maximum. However, the DNS ALG will 

check the length of the domain name and label, and it will drop packets if either the 

domain name is more than 255 bytes or the label length is more than 63 bytes. 

• The following sections were removed from the guide as they were causing confusion: 

“H.323 ALG Endpoint Registration Timeouts,” “Understanding H.323 ALG Endpoint 

Registration Timeouts,” and “Example: Setting H.323 ALG Endpoint Registration 

Timeouts.” 

• The “Understanding Internet-Related Predefined Policy Applications” section of Junos 

OS Security Configuration guide incorrectly specifies the HTTP port value as 80 in 

Predefined Applications table. The correct port value for HTTP is 8080. 

• The following examples in this guide include erroneous information as explained below: 

• The “Example: Configuring an SRX Series Services Gateway for the High-End as a 

Chassis Cluster” section in this guide erroneously shows the backup router as being 

configured with a destination address of 0.0.0/0. Instead, you must use a nonzero 

prefix. Configuring the backup router destination address as x.x.x.0/0 is not allowed. 

• The “Example: Configuring an SRX Series Services Gateway for the High-End as a 

Chassis Cluster” section and several related chassis cluster sections in this guide 

contain incorrect information about how and when you configure control ports and 

assign cluster IDs and node IDs to both nodes of a cluster. 

The correct information is as follows: 

NOTE: Control port configuration is required for SRX5600 and SRX5800 

devices. No control port configuration is needed for SRX1400, SRX3400, 

or SRX3600 devices. 

• Before the cluster is formed, you must configure control ports for each device, as 

well as assign a cluster ID and node ID to each device, and then reboot. When the 

system boots, both the nodes come up as a cluster. 

484 



• Now the devices are a pair. From this point forward, configuration of the cluster is 

synchronized between the node members, and the two separate devices function 

as one device. 

• In cluster mode, the cluster is synchronized between the nodes when you execute 

a commit command. All commands are applied to both nodes regardless of the 

device from which the command is configured. 

• The “Troubleshooting Chassis Cluster ISSU Failures” section of the Junos OS Security 

Configuration Guide contains incorrect information in the message that is issued when 

an ISSU encounters an unexpected situation that necessitates an abort. The message 

that shows the correct next steps for you to take is as follows: 

Rebooting Secondary Node 

Shutdown NOW! 

[pid 2120] 

ISSU: Backup RE Prepare Done 

Waiting for node1 to reboot. 

node1 booted up. 

Waiting for node1 to become secondary 

error: wait for node1 to become secondary failed (error-code: 5.1) 

ISSU aborted. But, both nodes are in ISSU window. 

Please do the following: 

1. Log on to the upgraded node. 

2. Rollback the image using rollback command with node option 

Note: Not using the 'node' option might cause 

the images on both nodes to be rolled back 

3. Make sure that both nodes (will) have the same image 

4. Ensure the node with older image is primary for all RGs 

5. Abort ISSU on both nodes 

6. Reboot the rolled back node 

{primary:node0} 

• In the “Internet Protocol Security” chapter of the Junos OS Security Configuration Guide, 

“Understanding Virtual Router Limitations” incorrectly lists “Internet Key Exchange 

(IKE) inside VR” as not being supported. Support for IKE in multiple virtual routers 

(VRs) was added in the Junos OS 11.1R1 release for all SRX Series and J Series devices. 

Also, “Virtual Router Support for Route-Based VPNs” incorrectly includes a note that 

for VPN traffic to work in a nondefault VR, the IKE listener must be placed in the default 

VR. 

• The Junos OS Security Configuration Guide incorrectly states that the release supports 

security chains, which validate a certificate path upward through eight levels of CA 

authorities in the PKI hierarchy. The release does not support security chains. 

J-Web 

• J-Web security package update Help page—The J-Web Security Package Update 

Help page does not contain information about the download status. 

• J-Web pages for stateless firewall filters—There is no documentation describing the 

J-Web pages for stateless firewall filters. To find these pages in J-Web, go to 

Configure>Security>Firewall Filters, and then select IPv4 Firewall Filters or IPv6 Firewall 

Filters. After configuring the filters, select Assign to Interfaces to assign your configured 

filters to interfaces. 


485


• J-Web Configuration Instructions— Because of ongoing J-Web interface enhancements, 

some of the J-Web configuration example instructions in the Junos administration and 

configuration guides became obsolete and thus were removed. For examples that are 

missing J-Web instructions, use the provided CLI instructions. 

Junos OS System Log Messages Reference 

• The AV System Log Messages topic lists incorrect facilities for the systems logs. 

On all SRX Series devices, antivirus (AV) system logs are generated with the facility 

LOG_USER or LOG_DAEMON. 

Table 29 on page 486 shows the correct facilities for the system logs. 

Table 29: Antivirus System Logs 

System Logs 

Incorrect Facility 

Correct Facility 

AV_PATTERN_GET_FAILED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_KEY_EXPIRED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_KL_CHECK_FAILED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_TOO_BIG 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_UPDATED 

LOG_FIREWALL 

LOG_DAEMON 

AV_PATTERN_WRITE_FS_FAILED 

LOG_FIREWALL 

LOG_DAEMON 

AV_SCANNER_READY 

LOG_FIREWALL 

LOG_DAEMON 

AV_VIRUS_DETECTED_MT 

LOG_PFE 

LOG_USER 

• The Junos 11.4 System Log Messages Reference is missing the following AV system log 

messages. The list below are messages with the AV prefix They are generated by the 

antivirus scanning process (avd). 








• The Junos 11.4 System Log Messages Reference is missing the following RT system log 

messages: 

486 



This list below describes messages with the RT prefix. They are generated on routers 

running the Junos OS with enhanced services by the Packet Forwarding Engine as it 

processes packets for security control in real time. 

• RT_GTP_DEL_TUNNEL_V0— A GPRS tunneling protocol (GTP) version 0 tunnel 

was deleted. This message reports an event, not an error. 

• RT_GTP_DEL_TUNNEL_V1—A GPRS tunneling protocol (GTP) version 1 tunnel was 

deleted. This message reports an event, not an error. 

• RT_GTP_PKT_APN_IE—Displays the contents of the Access Point Name (APN) 

information element carried in the GPRS tunneling protocol (GTP) message. This 

message reports an event, not an error. 

• RT_GTP_PKT_DESCRIPTION_CHARGING—Displays the GPRS tunneling protocol 

(GTP) packet description for a GTP charging message. The description includes the 

source and destination address and version. This message reports an event, not an 

error. 

• RT_GTP_PKT_DESCRIPTION_V0—Displays the GPRS tunneling protocol (GTP) 

packet description for a GTP version 0 message. The description includes the source 

and destination address, 64-bit tunnel ID, and index. This message reports an event, 

not an error. 

• RT_GTP_PKT_DESCRIPTION_V1—Displays the GPRS tunneling protocol (GTP) 

packet description for a GTP version 1 message. The description includes the source 

and destination address, tunnel endpoint ID, and index. This message reports an 

event, not an error. 

• RT_GTP_PKT_ENDUSER_ADDR_IE_IPV4—Displays the contents of the IPv4 End 

User Address information element carried in the GPRS tunneling protocol (GTP) 

message. The content includes the end user IP address. This message reports an 


• RT_GTP_PKT_GSNADDR_IE—Displays the contents of the GPRS Support Node 

(GSN) Address information element carried in the GPRS tunneling protocol (GTP) 

message. The content includes the GSN IP address. This message reports an event, 

not an error. 

• RT_GTP_PKT_IMSI_IE—Displays the contents of the International Mobile Subscriber 

Identity (IMSI) information element carried in the GPRS tunneling protocol (GTP) 

message. The content includes the lower and higher halves of the GTP mobile ID. 

This message reports an event, not an error. 

• RT_GTP_PKT_MSISDN_IE—Displays the contents of the MS International PSTN/ISDN 

Number (MSISDN) information element carried in the GPRS tunneling protocol 

(GTP) message. The content includes the ISDN number. This message reports an 


• RT_GTP_PKT_RESULT—Displays the GPRS tunneling protocol (GTP) packet process 

result, providing information about whether the packet is passed or dropped. This 

message reports an event, not an error. 


487


• RT_GTP_SANITY_EXTENSION_HEADER—The GPRS tunneling protocol (GTP) 

packet has an incorrect extension header and the packet will be dropped. This is an 

error message. 

• RT_GTP_SYSTEM_ERROR—The GPRS tunneling protocol (GTP) packet was dropped 

due to a firewall system error, as indicated by the error code. 

Various Guides 

• Some Junos OS user, reference, and configuration guides—for example the Junos 

Software Routing Protocols Configuration Guide, Junos OS CLI User Guide, and Junos 

OS System Basics Configuration Guide—mistakenly do not indicate SRX Series device 

support in the “Supported Platforms” list and other related support information; 

however, many of those documented Junos OS features are supported on SRX Series 

devices. For full, confirmed support information about SRX Series devices, please refer 

to the Junos OS Feature Support Reference for SRX Series and J Series Devices. 

Errata for the Junos OS Hardware Documentation 

This section lists outstanding issues with the hardware documentation. 

SRX1400 Services Gateway Hardware Guide 

• Some of the graphics in the SRX1400 Services Gateway Hardware Guide show the 

grounding lug attached to the front panel of the device. However, the SRX1400 Services 

Gateway is not shipped with the grounding lug attached to it. 

• The SRX1400 Services Hardware Guide and the SRX1400 Services Getting Started Guide 

are missing the following note: 

NOTE: AC and DC Power Supply Units are not interoperable between the 

SRX1400 Services Gateway and the SRX3000 and SRX5000 lines. 

SRX1400 Services Gateway Getting Started Guide 

• In the SRX1400 Services Gateway Getting Started Guide, some of the graphics are shown 

with the grounding lug attached on the front panel of the device. However, the SRX1400 

Services Gateway is not shipped with the grounding lug attached to it. 

• Some of the graphics in the SRX1400 Services Gateway Getting Started Guide show 

graphics with the grounding lug attached to the device front panel. The grounding lug 

is not attached to the device at the time of shipment. 

• The SRX1400 Services Gateway Getting Started Guide should document the following 

statement: 

You can replace the Network and Services Processing Card (NSPC) with the SRX3000 

line Services Gateway Network Processing Card (NPC) and Services Processing Card 

(SPC). To install the NPC and SPC on the SRX1400 Services Gateway, you must order 

the Twin CFM holder tray (SRX1K3K-2CFM-TRAY) to hold two single-wide CFMs (NPC 

and SPC) separately. Contact your Juniper Networks customer service representative 

for more information. 

488 


Upgrade and Downgrade Instructions for Junos OS Release 11.4 for High-End SRX Series Services Gateways 

Related 

Documentation 


page 417 


on page 443 




on page 459 

Upgrade and Downgrade Instructions for Junos OS Release 11.4 for High-End SRX Series Services 

Gateways 

This section includes the following topics: 

• Upgrading and Downgrading among Junos OS Releases on page 489 

• Upgrading an AppSecure Device on page 491 

• Upgrade and Downgrade Scripts for Address Book Configuration on page 491 

• Upgrade Policy for Junos OS Extended End-Of-Life Releases on page 494 

• Hardware Requirements for Junos OS Release 11.4 for High-End SRX Series Services 


Upgrading and Downgrading among Junos OS Releases 

All Junos OS releases are listed in sequence on the JUNOS Software Dates & Milestones 

webpage: 

http://www.juniper.net/support/eol/junos.html 

To help in understanding the examples that are presented in this section, a portion of 

that table is replicated here. Note that releases footnoted with a 1 are Extended 

End-of-Life (EEOL) releases. 


489


You can directly upgrade or downgrade between any two Junos OS releases that are 

within three releases of each other. 

• Example: Direct release upgrade 

Release 10.3 → (bypassing Releases 10.4 and 11.1) Release 11.2 

To upgrade or downgrade between Junos OS releases that are more than three releases 

apart, you can upgrade or downgrade first to an intermediate release that is within three 

releases of the desired release, and then upgrade or downgrade from that release to the 

desired release. 

• Example: Multistep release downgrade 

Release 11.3 → (bypassing Releases 11.2 and 11.1) Release 10.4 → Release 10.3 

Juniper Networks has also provided an even more efficient method of upgrading and 

downgrading using the Junos OS EEOL releases. EEOL releases generally occur once a 

calendar year and can be more than three releases apart. For a list of, EEOL releases, go 

to http://www.juniper.net/support/eol/junos.html 

490 



You can directly upgrade or downgrade between any two Junos OS EEOL releases that 

are within three EEOL releases of each other. 

• Example: Direct EEOL release upgrade 


(EEOL) 

To upgrade or downgrade between Junos OS EEOL releases that are more than three 

EEOL releases apart, you can upgrade first to an intermediate EEOL release that is within 

three EEOL releases of the desired EEOL release, and then upgrade from that EEOL 

release to the desired EEOL release. 



(EEOL) → Release 11.4 (EEOL) 

You can even use a Junos OS EEOL release as an intermediate upgrade or downgrade 

step if your desired release is several releases later than your current release. 


Release 9.6 → Release 10.0 (EEOL) → Release 10.2 

For additional information about how to upgrade and downgrade, see the Junos OS 

Installation and Upgrade Guide. 

Upgrading an AppSecure Device 

Use the no-validate Option for AppSecure Devices. 

For devices implementing AppSecure services, use the no-validate option when upgrading 

from Junos OS Release 11.2 or earlier to Junos OS 11.4R1 or later. The application signature 

package used with AppSecure services in previous releases has been moved from the 

configuration file to a signature database. This change in location can trigger an error 

during the validation step and interrupt the Junos OS upgrade. The no-validate option 

bypasses this step. 

Upgrade and Downgrade Scripts for Address Book Configuration 

Beginning with Junos OS Release 11.4, you can configure address books under the [security] 

hierarchy and attach security zones to them (zone-attached configuration). In Junos OS 

Release 11.1 and earlier, address books were defined under the [security zones] hierarchy 

(zone-defined configuration). 

You can either define all address books under the [security] hierarchy in a zone-attached 

configuration format or under the [security zones] hierarchy in a zone-defined configuration 

format; the CLI displays an error and fails to commit the configuration if you configure 

both configuration formats on one system. 


491


Juniper Networks provides Junos operation scripts that allow you to work in either of the 

address book configuration formats (see Figure 2 on page 493). 

• About Upgrade and Downgrade Scripts on page 492 

• Running Upgrade and Downgrade Scripts on page 493 

About Upgrade and Downgrade Scripts 

After downloading the Junos OS Release 11.4, you have the following options for 

configuring the address book feature: 

• Use the default address book configuration—You can configure address books using 

the zone-defined configuration format, which is available by default. For information 

on how to configure zone-defined address books, see the Junos OS Release 11.1 


• Use the upgrade script—You can run the upgrade script available on the Juniper Networks 

support site to configure address books using the new zone-attached configuration 

format. When upgrading, the system uses the zone names to create address books. 

For example, addresses in the trust zone are created in an address book named 

trust-address-book and are attached to the trust zone. IP prefixes used in NAT rules 

remain unaffected. 

After upgrading to the zone-attached address book configuration: 

• You cannot configure address books using the zone-defined address book 

configuration format; the CLI displays an error and fails to commit. 

• You cannot configure address books using the J-Web interface. 

For information on how to configure zone-attached address books, see the Junos OS 

Release 11.4 documentation. 

• Use the downgrade script—After upgrading to the zone-attached configuration, if you 

want to revert to the zone-defined configuration, use the downgrade script available 

on the Juniper Networks support site. For information on how to configure zone-defined 

address books, see the Junos OS Release 11.1 documentation. 

NOTE: Before running the downgrade script, make sure to revert any 

configuration that uses addresses from the global address book. 

492 



Figure 2: Upgrade and Downgrade Scripts for Address Books 

Download Junos OS 


zone-defined 

address book 

Run the upgrade script. 

zone-attached 

address book 

configuration 

- Global address book is 

available by default. 

- Address book is defined under 

the security hierarchy. 

- Zones need to be attached 

to address books. 

Run the downgrade script. 

Note: Make sure to revert any 

configuration that uses addresses 

from the global address book. 

g030699 

Running Upgrade and Downgrade Scripts 

The following restrictions apply to the address book upgrade and downgrade scripts: 

• The scripts cannot run unless the configuration on your system has been committed. 

Thus, if the zone-defined address book and zone-attached address book configurations 

are present on your system at the same time, the scripts will not run. 

• The scripts cannot run when the global address book exists on your system. 

• If you upgrade your device to Junos OS Release 11.4 and configure logical systems, the 

master logical system retains any previously configured zone-defined address book 


convert the existing zone-defined configuration to the zone-attached configuration. 

The upgrade script converts all zone-defined configurations in the master logical system 

and user logical systems. 

NOTE: You cannot run the downgrade script on logical systems. 

For information about implementing and executing Junos operation scripts, see the Junos 

OS Configuration and Operations Automation Guide. 


493


Upgrade Policy for Junos OS Extended End-Of-Life Releases 

An expanded upgrade and downgrade path is now available for the Junos OS 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 OS Releases 9.3, 10.0, and 10.4 are all EEOL releases. You can upgrade 

from Junos OS 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 OS Release 9.3 or 10.0, and then upgrade a second 

time to 10.4. Similarly, you can downgrade directly from Junos OS 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. 



Hardware Requirements for Junos OS Release 11.4 for High-End SRX Series 


Transceiver Compatibility for SRX Series Devices 

We strongly recommend that only transceivers provided by Juniper Networks be used 

on high-end SRX Series Services Gateways 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. 

Related 

Documentation 


page 417 





494 


Junos OS Documentation and Release Notes 

Junos OS Documentation and Release Notes 

Documentation Feedback 

For a list of related Junos OS 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 OS 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. 

We encourage you to provide feedback, comments, and suggestions so that we can 

improve the documentation. You can send your comments to 

techpubs-comments@juniper.net, or fill out the documentation feedback form at 

https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include 

the following information with your comments: 

• Document name 

• Document part number 

• Page number 

• Software release version 

Requesting Technical Support 

Technical product support is available through the Juniper Networks Technical Assistance 

Center (JTAC). If you are a customer with an active J-Care or JNASC support contract, 

or are covered under warranty, and need postsales technical support, you can access 

our tools and resources online or open a case with JTAC. 

• JTAC policies—For a complete understanding of our JTAC procedures and policies, 

review the JTAC User Guide located at 

http://www.juniper.net/customers/support/downloads/710059.pdf. 

• Product warranties—For product warranty information, visit 

http://www.juniper.net/support/warranty/. 


495


• 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/. 

496 


Requesting Technical Support 

Revision History 

05 March 2013—Revision 1, Junos OS 11.4.R7 

31 January 2013—Revision 4, Junos OS 11.4.R6 

08 January 2013—Revision 3, Junos OS 11.4.R6 

13 December 2012—Revision 2, Junos OS 11.4.R6 

04 December 2012—Revision 1, Junos OS 11.4.R6 

23 October 2012—Revision 23, Junos OS 11.4.R5 

27 September 2012—Revision 22, Junos OS 11.4.R5 

18 September 2012—Revision 21, Junos OS 11.4.R5 

31 August 2012—Revision 20, Junos OS 11.4.R5 

02 August 2012—Revision 19, Junos OS 11.4.R4 

26 July 2012—Revision 18, Junos OS 11.4.R4 



29 May 2012—Revision 15, Junos OS 11.4.R3 

18 May 2012—Revision 14, Junos OS 11.4.R3 

05 April 2012—Revision 13, Junos OS 11.4.R2 




10 January 2012—Revision 9, Junos OS 11.4.R1 Phase 2 

27 December 2011—Revision 8, Junos OS 11.4.R1 Phase 2 






21 November 2011—Revision 2, Junos OS 11.4.R1 Phase 1 


497


17 November 2011—Revision 1, Junos OS 11.4.R1 Phase 1 

Copyright © 2013, 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. 

498

Release Notes - Juniper Networks

Create successful ePaper yourself

Delete template?

Save as template?