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 (including the ERX310, ERX705, ERX710, ERX1410, ERX1440, M5, M7i, M10, M10i, M20, M40, M40e, M160,
M320, and T320 routers, T640 routing node, and the Junos, JunosE, and SDX-300 software) 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.
JunosE™ Software for E Series™ Broadband Services Routers Release Notes, Release 10.3.2
Writing: Subash Babu Asokan, Krupa Chandrashekar, Megha Shaseendran, Pallavi Madhusudhan, Namrata Mehta, Diane Florio, Brian Wesley Simmons,
Fran Singer, Sairam V
Editing: Ben Mann, Alana Calapai
Cover Design: Edmonds Design
Revision History
September 2010—FRS JunosE 10.3.2
The information in this document is current as of the date listed in the revision history.
Software License
The terms and conditions for using this software are described in the software license contained in the acknowledgment to your purchase order or, to the
extent applicable, to any reseller agreement or end-user purchase agreement executed between you and Juniper Networks. By using this software, you
indicate that you understand and agree to be bound by those terms and conditions.
Generally speaking, the software license restricts the manner in which you are permitted to use the software and may contain prohibitions against certain
uses. The software license may state conditions under which the license is automatically terminated. You should consult the license for further details.
For complete product documentation, please see the Juniper Networks Web site at www.juniper.net/techpubs.
END USER LICENSE AGREEMENT
READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE. BY DOWNLOADING,
INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU (AS CUSTOMER OR
IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS
AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE
SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS.
1.The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or Juniper
Networks (Cayman) Limited (if the Customer’s principal office is located outside the Americas) (such applicable entity being referred to herein as
“Juniper”), and (ii) the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use
of the Software (“Customer”) (collectively, the “Parties”).
2.The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for which
Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by Juniper in equipment
which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades and new releases of such
software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper equipment and any updates, upgrades,
additions or replacements which are subsequently embedded in or loaded onto the equipment.
3.License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer a
non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use
restrictions:
a.Customer shall use Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer
from Juniper or an authorized Juniper reseller.
b.Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which
Customer has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access Client software
only, Customer shall use such Software on a single computer containing a single physical random access memory space and containing any
number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines (e.g., Solaris zones)
requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single chassis.
c.Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may specify limits
to Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, concurrent users,
sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of separate
licenses to use particular features, functionalities, services, applications, operations, or capabilities, or provide throughput, performance,
configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use of the Software to
managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software. Customer’s use of the
Software shall be subject to all such limitations and purchase of all applicable licenses.
d.For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the Software.
Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not extend or
create an additional trial period by re-installing the Software after the 30-day trial period.
e.The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s enterprise
network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the Steel-Belted Radius
software to support any commercial network access services.
The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the
applicable license(s) for the Software from Juniper or an authorized Juniper reseller.
4.Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall
not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as
necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d)
remove any proprietary notices, labels, or marks on or in any copy of the Software or any product in which the Software is embedded; (e) distribute
any copy of the Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any ‘locked’
or key-restricted feature, function, service, application, operation, or capability without first purchasing the applicable license(s) and obtaining a valid
key from Juniper, even if such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the
Software provided by Juniper to any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer
from Juniper or an authorized Juniper reseller; (i) use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available
for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of
testing or benchmarking of the Software to any third party without the prior written consent of Juniper; or (l) use the Software in any manner other
than as expressly provided herein.
5.Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall
furnish such records to Juniper and certify its compliance with this Agreement.
6.Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such,
Customer shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum
includes restricting access to the Software to Customer employees and contractors having a need to use the Software for Customer’s internal business
purposes.
7.Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software,
associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or
interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software.
8.Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty statement
that accompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support the Software.
Support services may be purchased separately. Any such support shall be governed by a separate, written support services agree
MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS OR PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, THE
SOFTWARE, OR ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM
UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY
STATEMENT TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER
EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK
RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR
ATTACK. In no event shall Juniper’s or its suppliers’ or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of
warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim, or if the Software is embedded in another
Juniper product, the price paid by Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered
into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of
risk between the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same
form an essential basis of the bargain between the Parties.
9.Termi natio n. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the license
granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in
Customer’s possession or control.
10. Taxes. All license fees payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from the purchase
of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction shall be provided to
Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All payments made by Customer
shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in connection with such withholding taxes by
promptly: providing Juniper with valid tax receipts and other required documentation showing Customer’s payment of any withholding taxes;
completing appropriate applications that would reduce the amount of withholding tax to be paid; and notifying and assisting Juniper in any audit or
tax proceeding related to transactions hereunder. Customer shall comply with all applicable tax laws and regulations, and Customer will promptly pay
or reimburse Juniper for all costs and damages related to any liability incurred by Juniper as a result of Customer’s non-compliance or delay with its
responsibilities herein. Customer’s obligations under this Section shall survive termination or expiration of this Agreement.
11 .Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign
agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations,
or without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to Customer may contain
encryption or other capabilities restricting Customer’s ability to export the Software without an export license.
12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or
disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS 227.7201 through
227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.
13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer with the interface
information needed to achieve interoperability between the Software and another independently created program, on payment of applicable fee, if
any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use such information in compliance with
any applicable terms and conditions upon which Juniper makes such information available.
14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products or technology
are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or
vendor shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party software may be provided
with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are
distributed under and subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU
General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper
ment. TO THE
modifications, as appropriate) available upon request for a period of up to three years from the date of distribution. Such request can be made in
writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at
http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL at http://www.gnu.org/licenses/lgpl.html.
15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The
provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this
Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara
County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and
supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in
a purchase order), except that the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern
to the extent such terms are inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights
hereunder shall be effective unless expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the
Parties agree that such invalidity shall not affect the validity of the remainder of this Agreement. This Agreement and associated documentation has
been written in the English language, and the Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur
volonté que cette convention de même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation:
The parties confirm that this Agreement and all related documentation is and will be in the English language)).
Complete procedures for installing the system software are available in JunosE
System Basics Configuration Guide, Chapter 3, Installing JunosE Software.
New software releases are available for download from the Juniper Networks
website at http://www.juniper.net/customers/support. You can use the downloaded
image bundle to create your own software CDs.
Before upgrading to a new version of software, save your router’s running
configuration to a .cnf file or .scr file. If you subsequently need to downgrade for
any reason, you can restore the earlier software version.
NOTE: When you upgrade the software on a router that has a large number of
interfaces configured, the router might appear to be unresponsive for several
minutes. This condition is normal; allow the process to continue uninterrupted.
Upgrading to Release 5.3.0 or a Higher-Numbered Release
When you upgrade from a lower-numbered release to Release 5.3.0 or a
higher-numbered release, the higher release might not load if you issue the boot system command from Boot mode while the lower-numbered software is running
on the router or if you insert a flash card running a higher-numbered release into a
system running a lower numbered release. However, if you issue the boot system
command from Global Configuration mode, the new software loads properly.
Release Installation 1
JunosE 10.3.2 Release Notes
Upgrading from Release 5.1.1 or Lower-Numbered Releases to
Release 6.x.x or Higher-Numbered Releases
Release 5.1.1 or lower-numbered releases support application images only up to
172 MB. Your software upgrades or application images may be available remotely
through Telnet or FTP, or may be delivered on a new NVS card. If you upgrade the
JunosE Software using a new NVS card, we recommend you perform the upgrade in
two stages: first to an intermediate release and then to the higher-numbered release
you want to run. This restriction is not applicable if you upgrade your software
remotely through Telnet or FTP.
To install larger application images for Release 6.0.0 and higher-numbered releases,
you must first install Release 5.1.2 (or a higher-numbered 5.x.x release). This
enables the system to support application images greater than 172 MB. For
example, if you are upgrading the software using a new NVS card, you cannot go
from Release 5.1.1 to Release 7.2.0 without first upgrading to Release 5.1.2.
See the following table for compatibility of releases.
JunosE Release
5.1.1 or lower-numbered
release
5.1.2 or
higher-numbered release
7.2.0 or
higher-numbered release
For more detailed information on installing software, and about NVS cards and SRP
modules, see the following documents:
JunosE System Basics Configuration Guide, Chapter 6, Managing Modules
Upgrading NVS Cards on SRP Modules in ERX Hardware Guide, Chapter 8,
Maintaining ERX Routers
Upgrading NVS Cards on SRP Modules in E120 and E320 Hardware Guide, Chapter
8, Maintaining the Router
Moving Line Modules Between Releases
The Juniper Networks ERX1440 Broadband Services Router employs a 40-Gbps SRP
module and a new midplane. Release 3.3.2 was the first software release to support
the 40-Gbps SRP module and midplane. Before you can transfer a compatible line
module from a Juniper Networks ERX705, ERX710, or ERX1410 Broadband
Services Router to an ERX1440 router, you must first load Release 3.3.2 or a higher
release onto the current router, and then reboot the router to load the release onto
the line modules. If you then move any of those line modules to an ERX1440 router,
that router is able to recognize the line module.
Highest Release Able
to Load
5.3.5p0-2 or the
highest-numbered 5.x.x
release
No limitationNot applicable~234 MB
No limitationNot applicable~256 MB
Cannot Load
6.x.x or
higher-numbered
release
Maximum
Application Image
~172 MB
If you move a compatible line module from an ERX1440 router to an ERX705,
ERX710, or ERX1410 router, the module loads properly in the new router regardless
of the release.
2 Release Installation
SRP Module Memory Requirements
For Release 5.3.0 and higher-numbered software releases on ERX14xx models,
ERX7xx models, and the Juniper Networks ERX310 Broadband Services Router, see
ERX Module Guide, Table 1, ERX Module Combinations, for detailed information about
memory requirements.
For Release 8.2.0 and higher-numbered software releases on Juniper Networks
E120 and E320 Broadband Services Routers, see E120 and E320 Module Guide, Table 1, Modules and IOAs, for detailed information about memory requirements.
Hardware and Software Compatibility
For important information about hardware and software, see the document set as
follows:
Combinations of line modules to achieve line rate performance are in JunosE
System Basics Configuration Guide, Chapter 6, Managing Modules.
Release 10.3.2
Compatibility of ERX router modules with software releases is in ERX Module
Guide, Table 1, ERX Module Combinations.
Layer 2 and layer 3 protocols and applications supported by ERX router
modules are in ERX Module Guide, Appendix A, Module Protocol Support.
Compatibility of E120 router and E320 router modules with software releases is
in E120 and E320 Module Guide, Table 1, Modules and IOAs.
Layer 2 and layer 3 protocols and applications supported by IOAs on the E120
router and the E320 router are in E120 and E320 Module Guide, Appendix A, IOA
Protocol Support.
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 post-sales 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
JTAC Hours of Operation—The JTAC centers have resources available 24 hours
a day, 7 days a week, 365 days a year.
Requesting Technical Support 3
JunosE 10.3.2 Release Notes
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 Manager:
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.
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
http://www.juniper.net/support/requesting-support.html
4 Requesting Technical Support
Release Overview
Release 10.3.2
These Release Notes cover Release 10.3.2 of the system software for the Juniper
Networks E Series Broadband Services Routers and contain the following sections:
Release Highlights on page 7
Early Field Trial Features on page 7
Unsupported Features on page 9
Release Software Protocols on page 10
SRC Software and SDX Software Compatibility Matrix on page 12
Known Behavior on page 12
Known Problems and Limitations on page 35
Before You Start
Resolved Known Problems on page 54
Errata on page 58
Appendix A, System Maximums, on page 69
If the information in these Release Notes differs from the information found in the
published documentation set, follow these Release Notes.
These Release Notes include information about the changes between Releases
10.3.1 and 10.3.2. Before you use your new software, read these Release Notes in
their entirety, especially the section Known Problems and Limitations. You need the
following documentation to fully understand all the features available in Release
10.3.2:
These 10.3.2 Release Notes, which describe changes between Release 10.3.1
and Release 10.3.2
The 10.3.1 Release Notes, which describe the features available in Release
10.3.1
The 10.3.x documentation set, which provides detailed information about
features available in Release 10.3.0
Release Overview 5
JunosE 10.3.2 Release Notes
The 10.3.x documentation set consists of several manuals and is available only in
electronic format. You can print your own documentation using the PDF and HTML
formats available at the Juniper Networks Technical Documentation Web site at
www.juniper.net/techpubs. Refer to the following table to help you decide which
document to use.
TaskDocument
Install the routerERX Hardware Guide
E120 and E320 Hardware Guide
Learn about modulesERX Module Guide
ERX End-of-Life Module Guide
E120 and E320 Module Guide
Get up and running quicklyE Series Installation Quick Start poster or ERX Quick Start
Guide
E120 and E320 Quick Start Guide
Configure the routerJunosE System Basics Configuration Guide
Monitor system eventsJunosE System Event Logging Reference Guide
Look up definitions of terms used in
JunosE technical documentation
JunosE Service Availability Configuration Guide
JunosE IP, IPv6, and IGP Configuration Guide
JunosE IP Services Configuration Guide
JunosE Multicast Routing Configuration Guide
JunosE BGP and MPLS Configuration Guide
JunosE Command Reference Guide A to M
JunosE Command Reference Guide N to Z
JunosE Glossary
6 Release Overview
Release Highlights
IPv6
Release 10.3.2
Release 10.3.2 is a maintenance release and includes the feature described in this
section.
CategoryFeature
IPv6 Support for IPv6 Neighbor Discovery Router
Advertisements with Service Modules on ERX Routers
Support for IPv6 Neighbor Discovery Router Advertisements with Service
Modules on ERX Routers
Service line modules and IPSec service modules (collectively referred to as
Service Modules) on ERX14xx models, ERX7xx models, and the ERX310 router
now support IPv6 Neighbor Discovery router advertisements for dynamically
configured interfaces. When a router is configured for IPv6, it uses router
advertisements to announce its presence to other nodes connected to it. Hosts
discover the addresses of their neighboring routers by listening for these
advertisements.
In addition to configuring Neighbor Discovery through the CLI, you can also use
IPv6 profiles and RADIUS to configure Neighbor Discovery route
advertisements for dynamically configured interfaces. If both an IPv6 profile
and RADIUS are configured for Neighbor Discovery router advertisement, the
prefix value returned in RADIUS VSA 26-129 takes precedence over the prefix
specified in the IPv6 profile configuration.
Change in existing behavior: Existing feature extended as described here. In
lower-numbered releases, IPv6 Neighbor Discovery was supported only on Fast
Ethernet, Gigabit Ethernet, OCx/STMx GE/FE, and OCx/STMx ATM line modules
on ERX routers. In this release, ERX routers that contain SMs support IPv6
Neighbor Discovery router advertisements on dynamic interfaces.
Early Field Trial Features
The features described in this section are present in the code but have not yet been
fully qualified by Juniper Networks. These features are available only for field test
purposes in this release. If you use any of these features before they have been fully
qualified, it is your responsibility to ensure that the feature operates correctly in
your targeted configuration.
Release Highlights 7
JunosE 10.3.2 Release Notes
DHCP
Support for DHCP External Server, DHCP Local Server, DHCP Relay, and DHCP
Relay Proxy on POS Access Interfaces
The following packet over SONET (POS) module combinations on E Series
routers now support configuration of the DHCP external server, DHCP local
server, DHCP relay, and DHCP relay proxy applications, alone or in
combination, when the POS module is the access interface:
POS module combinations on the E120 router and the E320 router:
ES2 4G LM with ES2-S1 OC12-2 STM4 POS IOA
ES2 4G LM with ES2-S1 OC48 STM16 POS IOA
POS module combinations on ERX14xx models, ERX7xx models, and the
ERX310 router:
OCx/STMx POS line module with OC3-4 I/O module
OCx/STMx POS line modules with OC12/STM4 I/O module
OC48 line module with OC48 FRAME APS I/O module
In the current release, this feature is available for early field test purposes only.
You can configure DHCP external server, DHCP local server, DHCP relay, and
DHCP relay proxy on these POS modules in either a virtual router (VR) or a VPN
routing and forwarding instance (VRF).
As part of this feature, the pos keyword has been added to the existing ip dhcp-local limit command. To specify the maximum number of IP addresses
that the DHCP local server application can supply to all POS access interfaces or
to a specific POS access interface, in the range 0–96000, use the ip dhcp-local limit command with the new pos keyword. For example:
! Set the IP address limit for all POS access interfaces to 1000
host1(config)#ip dhcp-local limit pos 1000
! Set the IP address limit for the specified POS access interface to 2000
host1(config)#ip dhcp-local limit interface pos 5/0/0 2000
! Restore the IP address limit for all POS access interfaces to the default value,
! 48000
host1(config)#no ip dhcp-local limit pos
To display the maximum number of IP address leases available for POS access
interfaces, use the existing show ip dhcp-local limits command. For example:
The JunosE Release 10.3.x documentation set describes some features that are
present in the code but that have not yet been fully qualified by Juniper Networks. If
you use any of these features before they have been fully qualified, it is your
responsibility to ensure that the feature operates correctly in your targeted
configuration.
The following features are present but unsupported in this release.
Release 10.3.2
Service Manager support for unified ISSU is limited in this release to early field
trial purposes only.
E120 Router and E320 Router
The ES2 10G LM and ES2 10G Uplink LM do not support layer 2 statistics for
VLANs.
Subscriber Interfaces on the ES2 10G Uplink LM
You can configure dynamic subscriber interfaces and static subscriber
interfaces on the ES2 10G Uplink LM using the CLI. However, configuring
subscriber interfaces on the ES2 10G Uplink LM provides no benefit because
access features such as per-subscriber QoS are unavailable on the module.
Multicast
Unsupported IPv6 Data MDT Commands in CLI
The ipv6 pim data-mdt command and the show ipv6 pim data-mdt
command are unsupported in the current release.
The IPv6 PIM Data MDT Configuration mode is unsupported in this release. The
following commands appear in IPv6 PIM Data MDT Configuration mode but are
unsupported in the current release:
ipv6 pim join-filter mdt-data-timeout
ipv6 pim query-interval route map
mdt-data-delay tunnel group-address-pool
mdt-data-holdown tunnel source
Policy Management
External Parent Groups Unsupported on ES2 10G, ES2 10G Uplink, and ES2
10G ADV LMs
External parent groups are not supported on the ES2 10G, ES2 10G Uplink, and
ES2 10G ADV LMs. If you create a policy that references an external parent
group on these LMs, the system prevents you from attaching it to the LM
interface and you receive an error message.
Unsupported Features 9
JunosE 10.3.2 Release Notes
Stateful SRP Switchover (High Availability)
Stateful SRP Switchover for Certain Applications
The stateful SRP switchover feature has not been qualified for the following
applications:
Remote Access
DHCP proxy client
L2TP dialout
Release Software Protocols
The following list identifies the major software protocols supported in this release.
For detailed information about any protocol, see the configuration guides.
Intermediate System–to–Intermediate System (IS-IS)
Layer 2 Virtual Private Networks (L2VPNs)
Mobile IP
Open Shortest Path First (OSPF) version 2 and version 3
Protocol Independent Multicast Protocol (PIM), including PIM dense mode, PIM
sparse mode, PIM dense-sparse mode, and PIM source-specific multicast
Routing Information Protocol (RIP) version 2
Virtual Private LAN Service (VPLS)
Virtual Router Redundancy Protocol (VRRP)
Internet Key Exchange (IKE)
Internet Security Association and Key Management Protocol (ISAKMP)
IP Authentication Header (AH)
IP Encapsulating Security Payload (ESP)
Network Address Translation (NAT)
Release Software Protocols 11
JunosE 10.3.2 Release Notes
SRC Software and SDX Software Compatibility Matrix
The SRC software offers the features of the SDX software on the C Series
Controllers, a range of hardware platforms that use the Linux operating system. In
contrast, the SDX software runs on Solaris workstations. The SRC software contains
the features found in the associated SDX release plus additional features described
in the SRC Release Notes.
The following table shows which versions of the SRC software and SDX software
are compatible with specified versions of the JunosE Software.
SRC Software ReleaseSDX Software ReleaseTested with JunosE Release
2.0.07.1.08.1.2, 8.2.2
2.1.0Not applicable9.1.0p0-1
3.0.0Not applicable9.0.0, 9.0.1, 9.1.1
3.1.0Not applicable9.2.0, 9.3.0, 10.0.0
3.2.0Not applicable10.1.0, 10.2.0, 10.3.0
Known Behavior
AAA
ATM
For more detailed information about SRC software and SDX software compatibility
with JunosE releases, see the SRC Release Notes.
This section briefly describes E Series router behavior and related issues. In some
cases the behavior differs from non–E Series implementations; in others the
behavior is included to emphasize how the router works.
Although you can use the max-sessions command to configure a maximum of
32,000 outstanding authentication/authorization requests to a RADIUS server,
AAA internal limits prevent the actual number of outstanding
authentication/authorization requests from exceeding 9600. These internal
AAA limits apply only to authentication/authorization requests and not to
accounting requests.
The JunosE Software does not support accounting for ATM 1483 subscribers.
The atm1483 keyword for the aaa accounting default command is present in
the CLI, but it is not supported.
You cannot configure connection admission control (CAC) on an ATM interface
on which you have created a bulk-configured virtual circuit (VC) range for use
by a dynamic ATM 1483 subinterface. Conversely, you cannot create a
bulk-configured VC range on an ATM interface on which you have configured
CAC. The router rejects these configurations, which causes them to fail.
12 SRC Software and SDX Software Compatibility Matrix
BGP
Release 10.3.2
Configuring CAC and bulk-configured VCs on the same ATM interface was
supported in previous JunosE Software releases. As a result, If you are
upgrading to the current JunosE release from a lower-numbered release,
configurations that use CAC and bulk configuration on the same ATM interface
continue to work. However, we recommend that you disable CAC on these
ATM interfaces to ensure continued compatibility with future JunosE releases.
The E Series router does not include the link-local IPv6 address in the next-hop
field of an MP-BGP update message carrying IPv6 routing information over
IPv4 transport. This behavior is compliant with RFC 2545 but might have
interoperability issues with other implementations that depend on a link-local
IPv6 address in the next-hop field on a directly connected external BGP
peering.
Work-aro u n d: Enable EBGP multihop configuration on the remote
(non–Juniper Networks) peer.
BGP/MPLS VPNs
B-RAS
The following message might be displayed under certain conditions:
bgpConnections (default,0.0.0.0): TCP error code xx (...) occurred while accepting
inbound TCP connection
The message is generated when an unconfigured peer attempts to establish a
TCP session with an E Series router and a valid route to the source address of
the peer is absent from the router’s routing table.
If a valid route exists in the routing table, the following message is displayed
when an unconfigured peer attempts to establish a TCP session with an E
Series router; X.X.X.X is the source address of the unconfigured peer:
NOTICE 08/29/2001 16:50:11 bgpConnections (default,X.X.X.X): Inbound
connection refused - no peer X.X.X.X configured in core
NAT does not function properly with secondary routing table lookup (fallback
global) or global export mapping on the VRF.
Pool groups are not supported; although the ip local pool group command
appears in the CLI, it is not supported.
If the router is under a heavy load, the show profile command might take
longer than usual to execute.
Work-aro u n d: You can either delay examination of profiles until the router is
less busy, or save a copy of the profile to a text file off the router.
Known Behavior 13
JunosE 10.3.2 Release Notes
CLI
In Interface Configuration mode for a major interface, the CLI displays options
for protocols that are not supported by that interface type.
When you issue the reload command on an ERX310 router, the command
might display a warning message that erroneously indicates that a
synchronizing operation will be performed. Any references to synchronization
that appear in command output or system messages do not apply to the
ERX310 router, which does not support SRP module redundancy.
The following commands have been deprecated in the JunosE Software and
might be removed completely in a future release. If a command has been
deprecated for only a particular command mode, the table specifies any modes
for which it is still available.
Deprecated CommandCommand ModePreferred Command
aaa accounting interval Global Configurationaaa service accounting
colorPolicy List Configurationcolor in Classifier Group
Configuration mode
controller e1Global Configuration
controller t1Global Configuration
descriptionInterface Configuration
Still available in Controller
Configuration and VRF
Configuration modes
fdlController Configuration
fdl carrierController Configuration
fdl stringController Configuration
fdl transmitController Configuration
filterPolicy List Configurationfilter in Classifier Group
forward next-hopPolicy List Configurationforward next-hop in
forward next-interfacePolicy List Configurationforward interface in
ip description
Configuration mode
Classifier Group
Configuration mode
Classifier Group
Configuration mode
14 Known Behavior
Release 10.3.2
Deprecated CommandCommand ModePreferred Command
hostnameDomain Map Tunnel
client-name
Configuration
Still available in Global
Configuration mode
hssi descriptionInterface Configuration
hssi force dte acknowledgeInterface Configuration
hssi internal-clockInterface Configuration
ignore dcdInterface Configuration
ignore link-state-signalsInterface Configuration
[ no ] ike cr
lGlobal Configuration[ no ] ipsec crl
interface hssiGlobal Configuration
invert tx clockGlobal Configuration
ip dhcp-local cable-modemGlobal Configurationset dhcp-relay with the
strings docsis and pktc in
the server-string mapping
specification
ip mirrorGlobal Configurationip policy secure-input and
ip policy secure-output; for
E120 and E320 routers, you
must use these commands
because the ip mirror
command has been
removed from the CLI for
those routers.
ip policy local-inputInterface Configuration,
None
Profile Configuration
[ no ] ipsec isakmp-policy ruleGlobal Configuration[ no ] ipsec ike-policy-rule
ipv6 policy local-inputInterface Configuration,
None
Profile Configuration
j1Controller Configuration
license l2tp-sessionGlobal ConfigurationNone
lineCodingController Configuration
logPolicy List Configurationlog in Classifier Group
Configuration mode
log severity debug
dhcpLocalProtocolDecode
loopbackDomain Map Configuration
Global Configurationlog severity debug
dhcpCapture
local-interface
Still available in Controller
Configuration and Interface
Configuration modes
markPolicy List Configurationmark in Classifier Group
Configuration mode
Known Behavior 15
JunosE 10.3.2 Release Notes
Deprecated CommandCommand ModePreferred Command
mark-dePolicy List Configurationmark-de in Classifier Group
Configuration mode
mark-expPolicy List Configurationmark-exp in Classifier Group
Configuration mode
mark-user-priorityPolicy List Configurationmark-user-priority in
Classifier Group
Configuration mode
mpls ldp discovery
transport-address
mpls topology-driven-lsp
ip-interfaces
[ no ] next-hopPolicy List Configurationforward next-hop in
[ no ] next-interfacePolicy List Configurationforward interface in
nrzi-encodingInterface Configuration
no ospf enableRouter Configurationospf shutdown
policy-listGlobal Configurationip policy-list
radius disconnect clientGlobal Configuration
rate-limit-profilePolicy List Configurationrate-limit-profile in Classifier
remote-loopbackController Configuration
show controllers t1/e1User Exec, Privileged Exec
show controllers t1 remoteUser Exec, Privileged Exec
show ike certificatesUser Exec, Privileged Execshow ipsec certificates
show ike configurationUser Exec, Privileged Execshow ipsec ike-configuration
show ike identityUser Exec, Privileged Execshow ipsec identity
show ike policy-ruleUser Exec, Privileged Execshow ipsec ike-policy-rule
show ike saUser Exec, Privileged Execshow ipsec ike-sa
show ip dhcp-external bindingPrivileged Execshow dhcp binding
show ip dhcp-external binding-idPrivileged Execshow dhcp binding
show ip dhcp-local bindingPrivileged Execshow dhcp binding
show ip dynamic-interface-prefixPrivileged Exec, User ExecNone
show ip mirror interfacePrivileged Execshow secure policy-list
show license l2tp-sessionUser Exec, Privileged ExecNone
t1 lineCodingController ConfigurationNone. This command never
Interface ConfigurationThis command has no effect
in Interface Configuration
mode. Now available in
Global Configuration mode.
Global Configurationldp ip-forwarding
Classifier Group
Configuration mode
Classifier Group
Configuration mode
subscriber disconnect
The RADIUS Disconnect
Configuration mode has
been removed from the CLI.
Group Configuration mode
had any effect.
16 Known Behavior
Release 10.3.2
Deprecated CommandCommand ModePreferred Command
traffic-classPolicy List Configurationtraffic-class in Classifier
Group Configuration mode
tunnel mpls autoroute announce
bgp
tunnel mpls label-distInterface Configuration,
unframedController Configuration
user-packet-classPolicy List Configurationuser-packet-class in
virtual-routerDomain Map Configuration
yellowController Configuration
Interface Configuration,
Tunnel Profile Configuration
Tunnel Profile Configuration
Still available in Privileged
Exec and Global
Configuration modes
None
None
Classifier Group
Configuration mode
router-name
DHCP
The router displays a notice when you issue the command manually. If the
command is in a script, the router automatically maps the deprecated
command to the preferred command. If the deprecated command no longer
has a function, then that command has no effect when you run a script
containing the command.
The show configuration command normally takes a long time to finish for
extremely large configurations. If you specify a search string (with the begin,
exclude, or include options) with the command for a string that is not present
in the configuration, then the CLI session appears to be busy for a prolonged
period. The CLI filtering feature for show commands does not speed up
execution of the command.
Configuring authentication on the DHCP local server requires that you first
disable the DHCP local server for standalone mode. Doing so removes your
entire DHCP local server configuration. Therefore, if you want to configure
authentication, do so before you have otherwise configured the DHCP local
server.
When you upgrade from a release numbered lower than Release 7.1.0, all
DHCP host routes previously stored in NVS are deleted. After the upgrade,
DHCP clients must reacquire their IP addresses, which results in the new host
routes being correctly stored in NVS.
DHCP External Server
If you are using DHCP external server and a burst of client releases occurs
during a unified ISSU, some of the client releases might not be processed.
[Defect ID 180178]
Known Behavior 17
JunosE 10.3.2 Release Notes
When the DHCP relay agent application and the DHCP external server
application are configured in the same virtual router, using the ip
dhcp-external server-sync command on an unnumbered IP interface does not
function as expected. When you issue the ip dhcp-external server-sync
command in this configuration to create subscriber state information based on
lease renewals when the external DHCP server and the router are
unsynchronized, the router does not forward the ACK request from the DHCP
server to the client because there is no route. [Defect ID 88562]
When a bound DHCP client on a dynamic subscriber interface extends its IP
address lease by restarting the DHCP discovery process on its primary IP
interface instead of by initiating the DHCP renewal process on its dynamic
subscriber interface, the default behavior of the DHCP external server
application to preserve the client’s dynamic subscriber interface was changed
in the following JunosE releases to delete and re-create the client’s dynamic
subscriber interface:
Release 7.2.4p0-4 and all higher-numbered 7.2.x releases and patch
releases
Release 7.3.4 and all higher-numbered 7.3.x releases and patch releases
Release 8.0.4 and all higher-numbered 8.0.x releases and patch releases
Release 8.1.2 and all higher-numbered 8.1.x releases and patch releases
Release 8.2.3 and all 8.2.3 patch releases
Release 9.0.0 and all 9.0.0 patch releases
Release 9.0.1 and all 9.0.1 patch releases
Release 9.1.0 and all 9.1.0 patch releases
If you are upgrading the JunosE Software on the router from any of these
releases, you must explicitly issue the ip dhcp-external recreate-subscriber-interface command to configure the router to continue to
delete and re-create the DHCP client’s dynamic subscriber interface.
NOTE: The DHCP external server application is unsupported in JunosE Release
8.2.1 and JunosE Release 8.2.2.
DHCP external server may not be able to bind all DHCP clients when all of the
following conditions exist:
DHCP external server and either DHCP relay or relay proxy are configured
The client-facing and server-facing interfaces for DHCP external server and
DHCP external server is configured to create dynamic subscriber interfaces.
18 Known Behavior
in separate virtual routers on an E320 router.
either DHCP relay or relay proxy are configured on the same ES2 4G LM.
Release 10.3.2
When these three conditions exist simultaneously, the ES2 4G LM may not be
able to successfully process all DHCP packets. Although all clients may get
bounded in DHCP relay or relay proxy, some clients may not get bounded in
DHCP external server. (In a production environment it is highly unlikely for
conditions 1 and 2 to exist because stand-alone DHCP external server is
normally configured for a DHCP relay in a different chassis.)
Work-aro u n d: You can eliminate this issue by modifying any one of these
conditions. For example, this issue does not exist with any of the following
configuration modifications:
Configure DHCP external server and either DHCP relay or relay proxy in
the same virtual router.
Configure the client-facing and server-facing interfaces for DHCP external
server and either DHCP relay or relay proxy on the same ES2 10G LM
instead of the same ES2 4G LM.
Dynamic Interfaces
Ethernet
Configure the client-facing and server-facing interfaces for DHCP external
server and either DHCP relay or relay proxy on separate ES2 4G LMs.
Dynamic IPv6 interfaces over static PPP interfaces are not supported.
The hashing algorithm that selects the LAG member link is associated with the
IP address of the subscriber client to support QoS. Consequently, a particular
flow is always hashed to the same link. When a member link is removed from a
LAG bundle, traffic rate is disrupted and traffic flow is reduced. When the link
goes down and then comes back up, the traffic flow is automatically
redistributed.
When counting bits per second on a Fast Ethernet or Gigabit Ethernet interface,
an E Series router includes 12 bytes for interpacket gap, 7 bytes for preamble,
and 1 byte for start frame delimiter, for a total of 20 bytes (160 bits) per packet
more than some non–E Series routers. This value therefore shows the total
bandwidth utilization on the interface, including both data and overhead.
To bridge unicast known-DA packets at line rate on both 2-Gbps ports of the
GE-2 line module or the GE-HDE module when paired with the GE-2 SFP I/O
module, the minimum packet size must be at least 144 bytes.
When installed in the ERX1440 router, the GE-2 module delivers full bandwidth
of 4 GB per line module (2 GB at the ingress and 2 GB at the egress) only when
installed in slot 2 or slot 4, and when the SRP-40G+ module is used in the
router. When installed in any other ERX1440 slot, the GE-2 module delivers a
maximum bandwidth of 2 GB per line module (1 GB maximum at the ingress
and 1 GB maximum at the egress). Therefore, of the maximum 24 possible
ports for the module in an ERX1440 chassis (that is, two ports in each of 12
slots), full bandwidth is delivered only on a maximum of four ports (those in
slots 2 and 4).
Known Behavior 19
JunosE 10.3.2 Release Notes
When installed in the ERX1440 router, the GE-HDE line module delivers full
bandwidth of 4 GB per line module (2 GB at the ingress and 2 GB at the egress)
only when installed in slot 2 or slot 4, and when the SRP-40G+ module is used
in the router. When installed in any other ERX1440 slot, the GE-HDE module
delivers a maximum bandwidth of 2 GB per line module (1 GB maximum at the
ingress and 1 GB maximum at the egress). Therefore, of the maximum 96
possible ports for the module in an ERX1440 chassis (that is, 8 ports in each of
12 slots), full bandwidth is delivered only on a maximum of 16 ports (those in
slots 2 and 4).
When the GE-2 line module or the GE-HDE line module is installed in either the
ERX1440 router or the ERX310 router and both ports are active, line rate
performance is achieved only with packets that are 174 bytes or larger. The line
module might not achieve line rate with packets that are smaller than
174 bytes.
Support for the 0x9200 S-VLAN Ethertype has been removed. You can no
longer specify the 9200 option with the svlan ethertype command.
Flash
Forwarding
When you upgrade to Release 7.1.0 or higher-numbered release, the software
automatically transfers existing configurations that use the 0x9200 Ethertype to
the 0x88a8 Ethertype.
The show interface gigabitEthernet command output does not display the
following line of output for Gigabit Ethernet modules that do not support SFPs,
such as the GE Single Mode I/O module and GE I/O Multi Mode I/O modules:
Primary/Secondary link signal detected
Primary/Secondary link signal not detected
Flash cards manufactured by Wintec are present on some currently deployed
routers. When you upgrade the JunosE Software on such routers, the firmware
on the flash card controller is automatically updated during diagnostics. During
this reboot, the software runs an integrity check on the file system to verify that
the firmware update did not corrupt the contents of the flash card. This
integrity check is an expected side effect of the enhanced firmware available in
this release. The integrity check does not indicate a problem with the flash card
or its contents.
The hashing algorithm that selects the LAG member link is associated with the
IP address of the subscriber client to support QoS. Consequently, a particular
flow is always hashed to the same link. When a member link is removed from a
LAG bundle, traffic rate is disrupted and traffic flow is reduced. When the link
goes down and then comes back up, the traffic flow is automatically
redistributed. [Defect ID 180570]
20 Known Behavior
GRE
Hardware
Release 10.3.2
When you shut down the only outgoing IP interface to the IP destinations of
GRE/IP tunnels, the tunnels remain in the up state rather than transitioning to
down. As a consequence, all IP routes that use these tunnels as next hops also
remain in the routing table.
SRP modules with only 1 GB of memory do not work reliably in ERX7xx and
ERX14xx routers running JunosE Release 8.1.0 or higher, and may experience
system resets due to an out of memory condition. However, the ERX310 router
still supports 1 GB of memory in the SRP-SE10 module.
Work-aro u n d: Upgrade your SRP module memory to 2 GB for all ERX7xx and
ERX14xx routers running JunosE Release 8.1.0 or higher.
Do not include a not protocol clause in any classifier control list for policies
attached to an interface on an ES2 10G Uplink LM. The not protocol
functionality is not available for this module.
The ES2 10G LM and the ES2 10G Uplink LM do not support VLAN statistics in
the current release.
PCMCIA NVS Card Caution
CAUTION: Before you insert or remove PCMCIA NVS (flash) cards from a running
router, we strongly recommend that you halt the SRP module or shut down the
router. Failure to do this can result in file corruption in one or both cards.
The 4XOC3 APS MULTIMODE and 4XOC3 APS SINGLE MODE I/O modules are
incompatible with the following versions of the OCx/STMx ATM and OCx/STMx
POS line modules:
OCx/STMx ATM line modules with assembly numbers 350-00039-xx,
350-80039-xx, and 350-90039-xx
OCx/STMx POS line modules with assembly number 350-10039-xx
When you configure 1:5 line module redundancy by using either the 4XOC3
APS MULTIMODE or 4XOC3 APS SINGLE MODE I/O module, the spare R-Mid
OCX I/O module you install must have assembly number 350-00094-01 Rev.
A01 or later. Spare R-Mid OCX I/O modules with an earlier assembly number
are not supported for 1:5 redundancy configurations that use either the 4XOC3
APS MULTIMODE or 4XOC3 APS SINGLE MODE I/O module.
There is a very small chance that some line modules can have an improperly
modified keying block that prevents the module from proper seating in the top
slot of an older ERX7xx chassis or a preproduction ERX310 chassis. For
example, this problem has been observed for an OCx/STMx module in slot 2 of
an early-test ERX310 chassis.
Work-aro u n d: Remove the keying block to insert the module into the top slot,
or insert the module into a different slot.
Known Behavior 21
JunosE 10.3.2 Release Notes
HDLC
IP
By design, on the cOC12/STM4 module you cannot delete a serial interface
while data for the interface is still enqueued. The enqueued data can drain only
when the interface is operationally up. Therefore you must ensure that the
interface is operationally up before you delete it. For example, if you have
issued the shutdown command for the interface before you try to delete the
interface, issue the no shutdown command, then delete the interface.
When you upgrade from certain releases to JunosE Release 9.2.0p1-0 or
higher-numbered releases, descriptions configured for IP interfaces or IP
subinterfaces are not retained across the upgrade when the descriptions are
shorter than 9 characters in length. Additionally, VRF descriptions are not
retained across the upgrade when the combined length of the VRF description
and the VRF name is shorter than 9 characters. This behavior is seen during
upgrades using a reload, stateful SRP switchover, or unified ISSU. Upgrades
from the following releases are affected by this behavior:
7.x.x
8.0.x
8.1.x, 8.2.x, and 9.x.x builds created before July 23, 2008
Examples of descriptions that are not retained across the upgrade:
Work-aro u n d: Before you upgrade from an affected release to JunosE Release
9.2.0p1-0 or higher-numbered releases, ensure that you do the following:
Change IP interface and subinterface descriptions to 9 or more characters.
Change VRF descriptions, VRF names, or both so that the combination of
The ip tcp adjust-mss command, which modifies the maximum segment size
for TCP SYN packets traveling through the interface, is not supported on the
ES2 10G LM or ES2 10G Uplink LM.
22 Known Behavior
associated VRF names and descriptions consists of 9 or more characters.
Release 10.3.2
If you have enabled ipInterface logging at a priority of debug, the
acknowledgment that an interface has been deleted from the line modules can
return to the SRP module after the layers beneath IP have deleted their
interfaces. Consequently, the original name of the interface cannot be resolved
or displayed in the log, and the system instead displays the ifIndex of the IP
interface. This behavior has no functional effect other than that the log is
misleading. However, previous log events indicate that the interface deletion
was beginning.
When you want to use a configuration script to configure IP shared interfaces
that reference a physical interface, you must issue the service show
configuration format 2 command before you generate the script. If the default
show configuration format (format 1) is enabled instead, the generated script
cannot properly configure the IP shared interfaces because they are created
before the physical interfaces. To properly configure the shared interfaces in
this event, run the generated format 1 script twice.
When you issue the show ip forwarding-table command for a particular slot, it
is normal and appropriate behavior when the Status field indicates Valid while
the Load Errors field is increasing daily for that VR. The Load Errors field
records any failed routing table distribution attempt as an error. Attempts can
fail for many reasons during normal operation; a failed attempt does not
necessarily indicate a problem. It is normal to see many load errors per day. If
the Status field indicates Invalid, then the routing table distribution has failed
constantly for that VR and a real problem exists. You might occasionally see a
status of Updating. However, if the Status field always indicates Updating, then
again the routing table distribution has failed constantly for that VR, and a real
problem exists.
The enhancement to the CLI to support unnumbered reference to any kind of
interface rather than just loopback interfaces has consequences such as the
following: [Defect ID 47743]
If the references to shared interfaces appear in the show configuration
output before the configuration for the interfaces they refer to, trying to
restore such a configuration with a script generated from show configuration generates errors like the following:
% Error, line 3929:
host1(config-if)#ip share-interface FastEthernet 3/0.2
% No such interface
Unnumbered interfaces that refer to nonloopback interfaces (for example,
ip unnumbered fastEthernet 3/0.2) and that appear in the show
configuration output before the interface referred to might generate
similar no such interface errors.
Work-aro u n d: Run the script twice.
Known Behavior 23
JunosE 10.3.2 Release Notes
IPSec
When you shut down the only outgoing IP interface to the IP destinations of
IPSec tunnels, the tunnels remain in the up state rather than transitioning to
down. As a consequence, all IP routes that use these tunnels as next hops also
remain in the routing table. You can use dead keepalive detection (DPD) to
avoid this situation. DPD must be active, which requires both IPSec tunnel
endpoints to support DPD.
During a warm restart after a system failover, the SRP module can take several
minutes to resume the normal exchange of UDP/IP packets to applications.
During this restart time, the E Series router does not send or receive dead peer
detection (DPD) keepalives, which are used to verify connectivity between the
router and its peers. The length of the restart time depends on the number of
interfaces—if the restart time is too long, remote peers might determine that
the connection from them to the E Series router is broken and then shut down
an IPSec tunnel that has DPD enabled. In the worst case, all IPSec tunnels
might be shut down. [Defect ID 65132]
IS-IS
When IS-IS is configured on a static PPP interface, the IS-IS neighbor does not
come up if you remove the IP address from the interface and then add the IP
address back to the interface.
Work-aro u n d: When you remove and add back the IP address, you must also
remove the IS-IS configuration from the interface and then add the
configuration back to the interface by issuing the no router isis and router isis
commands.
When you run IS-IS on back-to-back virtual routers (VRs) in an
IS-IS-over-bridged-Ethernet configuration and do not configure different IS-IS
priority levels on each VR, a situation can occur in which both VRs elect
themselves as the designated intermediate system (DIS) for the same network
segment.
This situation occurs because the router uses the same MAC address on all
bridged Ethernet interfaces by default. When both VRs have the same (that is,
the default) IS-IS priority level, the router must use the MAC address assigned to
each interface to determine which router becomes the DIS. Because each
interface in an IS-IS-over-bridged-Ethernet configuration uses the same MAC
address, however, the router cannot properly designate the DIS for the network
segment. As a result, both VRs elect themselves as the DIS for the same
network segment, and the configuration fails. [Defect ID 72367]
Work-aro u n d: To ensure proper election of the DIS when you configure IS-IS
over bridged Ethernet for back-to-back VRs, we recommend that you use the
isis network point-to-point command in Interface Configuration mode to
configure IS-IS to operate using point-to-point (P2P) connections on a broadcast
circuit when only two routers (or, in this case, two VRs) are on the circuit.
Issuing this command tears down the current existing IS-IS adjacency in that
link and reestablishes a new adjacency.
24 Known Behavior
L2TP
Release 10.3.2
L2TP peer resynchronization enables an L2TP failed endpoint to resynchronize
with its peer non-failed endpoint. The JunosE Software supports failover
protocol and silent failover peer resynchronization methods. If you configure
the silent failover method, you must keep the following considerations in mind:
PPP keepalives—To ensure resynchronization of the session database, PPP
keepalives must be enabled on the L2TP data path. Without PPP
keepalives, silent failover might disconnect an established session if there is
no user traffic during failover recovery.
Asymmetric routes on different line modules—Asymmetric routes whose
receive and transmit paths use I/O paths on different line modules can
result in improperly handled line module control packets. If your network
does include this type of asymmetric route, tunnels using these routes
might fail to recover properly.
NAT dynamic translation generation affects the LNS session creation time.
If you create an L2TP destination profile profileName, establish tunnels with the
Line Module Redundancy
On E120 routers and E320 routers, redundant IOAs have a temperature sensor,
When NAT dynamic translations and LNS sessions are created simultaneously,
NAT dominates the CPU cycles of the tunnel-service module, resulting in a delay
in the LNS session creation rate. The LNS session creation rate returns to its
normal rate when NAT dynamic translations are no longer being generated.
[Defect ID 53191]
Work-aro u n d: When signaling performance must be optimal, avoid the
simultaneous configuration of NAT and LNS.
profile, and then remove the profile, you cannot subsequently create another
destination profile using that same profileName until all the tunnels drain from
the previous instance of this destination profile. If you do not wait, the E Series
router displays a message similar to the following:
If you do not want to wait for the tunnels to drain, use a different name for the
destination profile. [Defect ID 32973]
and the show environment all command lists the temperature of IOAs in their
associated slots.
On ERX routers, redundant I/O modules do not have a temperature sensor.
Therefore, the show environment all command output lists the primary I/O
module temperature in the slot of the line module that is responsible for the I/O
module.
Known Behavior 25
JunosE 10.3.2 Release Notes
MLPPP
When you install an ES2-S1 Redundancy IOA with a hardware revision number
of -02 or less in slot 0 or slot 11 of the E320 router or in slot 0 or the E120
router, do not install an OCx/STMx ATM IOA or an OCx/STMx POS IOA in the
lower (E320) or left (E120) adapter bay of slot 1 or slot 12. When the spare line
module is controlling another slot and you revert back to the primary line
module, the ATM or POS IOAs can become unusable or cause the line module to
reset. [Defect ID 69760]
Work-aro u n d: This problem is not present for ES2-S1 Redundancy IOAs with a
hardware revision number of -03 or higher.
Do not configure both MLPPP fragmentation (with the ppp fragmentation
command) and IP fragmentation of L2TP packets (with the ip mtu command)
on the same interface. Instead, you must choose only one of the fragmentation
configurations by setting it to the necessary value and set the other
fragmentation configuration to the maximum allowable value.
MPLS
Multicast
Martini circuits configured on the ES2 10G LM act as true layer 2 tunnels,
without modifying the layer 2 headers. For this reason, Martini VLAN retagging
is not currently supported.
If you are upgrading to Release 7.1.0 or a higher-numbered release from a
release numbered lower than Release 7.1.0, and have inter-AS option B or C
configurations, you must explicitly configure MPLS on all inter-AS links, as in
the following example:
If you do not explicitly configure MPLS on the links, the inter-AS feature will not
work properly.
The ip dipe sg-cache-miss and ipv6 dipe commands are not intended or
supported for customer use, although they are visible in the User Exec and
Privileged Exec modes respectively. These commands are intended to be used
in a Juniper Networks internal lab environment for testing without a traffic
generator.
Do not configure a multicast group with more than 10,219 outgoing interfaces
(OIFS) on the same ES2 10G LM. The configuration of the multicast group’s OIF
membership from the SRP module to the line module exceeds the size of a
single message and is sent in fragments. Because of this fragmentation, the ES2
10G LM generates the following error message: [Defect ID 81768]
pc: 0x9e5c88: -> fatalPanic(void) offset: 0x8
26 Known Behavior
Packet Mirroring
Release 10.3.2
The ES2 10G LM supports the packet mirroring feature when the module is
paired with the ES2-S2 10GE PR IOA, the ES2-S1 GE-8 IOA, or the ES2-S3 GE-20
IOA. When you use the ES2 10G LM with these IOAs, CLI-based
interface-specific mirroring is not supported.
When both interface-specific mirroring and user-specific mirroring are
configured on the same interface, the interface-specific secure policies take
precedence. The interface-specific secure policies, which you manually attach
using the CLI, override and remove any existing secure polices that were
attached by a trigger action. If the interface-specific secure polices are
subsequently deleted, the original trigger-based secure policies are not restored.
Typically, when configuring packet mirroring, you configure a static route to
reach the analyzer device through the analyzer port. If the analyzer port is an
IP-over-Ethernet interface, you must also configure a static Address Resolution
Protocol (ARP) entry to reach the analyzer device. However, because only a
single static ARP entry can be installed for a given address at any given time,
when you are using equal-cost multipath (ECMP) links to connect to the
analyzer device, the static ARP configuration does not provide failover if the link
being selected fails or is disconnected. Therefore, to provide continued
connectivity if the link fails when using ECMP, enable the ip proxy-arp unrestricted command on the next-hop router for each ECMP interface. As a
result, when the link fails, the router sends an ARP request to identify the MAC
address of the analyzer device and gets a response over the new link.
Policy Management
The ES2 10G LM does not support the deprecated next-hop command.
You cannot configure classifier lists that reference multiple fields for a VLAN
policy list on the ES2 10G Uplink LM or the ES2 10G LM, with the exception of
traffic-class and color. The system incorrectly classifies VLAN policies that
classify using multiple fields. For example, an invalid policy list that references
multiple fields uses both color and user-packet-class, or one classifier list using
color and another using user-packet-class.
In rare cases, some policy configurations that use CAM hardware classifiers
from releases earlier than Release 7.1.0 can fail because they exceed the total
hardware classifier entry size of 128 bits that was introduced in Release 7.1.0.
For more information and examples of previous configurations, see JunosE
Multiple Forwarding Solution Rules for a Single Classifier List in a Policy
Before Release 5.2.0, it was possible to configure a policy with multiple rules
that specified forwarding solutions where all of these rules were associated with
a single classifier list. This typically was a configuration error, but the CLI
accepted it. Beginning with Release 5.2.0, the CLI no longer accepts this
configuration.
Multiple forwarding rules behavior for releases numbered lower than
Release 5.2.0:
If multiple forward or filter rules were configured to reference the same
classifier list in a single policy, then all rules except the first rule
configured were marked as eclipsed in the show policy command
display. Next-interface and next-hop rules were treated in the same
manner. The eclipsed rules were not applied.
If a policy were configured with one rule from the [forward, filter] pair
and one rule from the [next-hop, next-interface] pair, and if both rules
referenced the same classifier list, then no visible eclipsed marking
occurred. However, these two rules were mutually exclusive, and only
one of them defined the forwarding behavior. The rule action that was
applied was in the order (from highest to lowest preference): next
interface, filter, next hop, forward. The applied rule was the rule whose
behavior was seen by forwarded packets.
For example, if a policy had both a next-interface and a filter rule, then
the next interface was applied. If a policy had a next-hop and a filter
rule, then the filter rule was applied.
Multiple forwarding rules behavior for Release 5.2.0 and higher-numbered
releases:
Beginning with Release 5.2.0, the multiple rules behavior is designed so
that when a forwarding solution conflict occurs within a policy, such as
those described earlier, the second forwarding solution overwrites the
preceding solution. That is, the last forwarding rule configured for the given
classifier list within a policy is the forwarding behavior that is used. Also, a
warning message is now displayed when this type of conflict occurs.
Example 1—In this example, the filter rule action overwrites the forward
rule, and is therefore applied.
host1(config)#policy-list wstPolicyList
host1(config-policy-list)#forward classifier-group svaleClacl1
host1(config-policy-list)#filter classifier-group svaleClacl1
WARNING: This rule has replaced a previously configured rule.
host1(config-policy-list)#exit
host1(config)#
28 Known Behavior
Release 10.3.2
Example 2—In this example, three forwarding solution conflicts result in
rules being overwritten. The filter rule is the last rule configured, and is
therefore applied.
host1(config)#policy-list bostTwo
host1(config-policy-list)#forward classifier-group clacl5
host1(config-policy-list)#next-hop 1.1.1.1 classifier-group clacl5
WARNING: This rule has replaced a previously configured rule.
host1(config-policy-list)#next-interface atm 1/0.0 classifier-group clacl5
WARNING: This rule has replaced a previously configured rule.
host1(config-policy-list)#filter classifier-group clacl5
WARNING: This rule has replaced a previously configured rule.
host1(config-policy-list)#exit
host1(config)#
NOTE: When you upgrade the nonvolatile memory to Release 5.2.0 or later, the
upgrade removes eclipsed rules and rules whose behavior was not applied in the
previous release. This removal ensures that the postupgrade forwarding behavior
is the same as the preupgrade behavior.
PPP
PPPoE
QoS
NOTE: If you upgrade to Release 5.2.0 or later and then configure your router
using a script generated before Release 5.2.0, the postupgrade and preupgrade
forwarding behaviors might not be the same. The new Release 5.2.0 configuration
behavior is applied—the last policy rule configured for a given classifier list that
specifies a forwarding behavior is the only rule remaining.
The GE-2 line module does not support dynamic IP interfaces over static PPP
interfaces when the PPPoE subinterface is also static. The OC3/STM1 GE/FE line
module does not support dynamic IP interfaces over static PPP interfaces when
the ATM interface column is also static.
On the ES2 4G LM, ES2 10G LM, and ES2 10G Uplink LM, data packets for
PPPoE are not counted at the PPPoE interface. Instead, PPPoE data packets are
counted at the PPP interface that sits on the PPPoE interface. Use the show ppp interface command to display the data packets. Control packets for PPPoE are
counted at the PPPoE interface; use the show pppoe interface command to
display the control packets.
When you are configuring compound shared shaping using explicit constituents
and you explicitly specify both a scheduler node and a queue stacked above the
node as constituents of the shared shaper, the system selects the scheduler
node (but not the queue) as the constituent.
Known Behavior 29
JunosE 10.3.2 Release Notes
In JunosE Releases 7.1.x, 7.2.x, and 7.3.x, you can attach a QoS profile to
Ethernet interfaces that are configured in a link aggregation group (LAG)
interface. However, beginning with JunosE Release 8.0.1, you can attach a QoS
profile directly to the LAG interface. As of JunosE Release 8.0.1, the software
restricts you from attaching a QoS profile to any Ethernet interfaces that are
members of a LAG. [Defect ID 84632]
Work-aro u n d: Prior to upgrading from JunosE Releases 7.1.x, 7.2.x, or 7.3.x to
JunosE Release 8.0.x or higher-numbered releases, remove the QoS profile
from the Ethernet interface. When you have successfully upgraded to JunosE
Release 8.0.x or higher-numbered releases, reattach the QoS profile to the LAG
interface.
In Release 7.2.0 and higher-numbered releases, you can configure the simple
shared shaper to select scheduler nodes in a named traffic-class group as active
constituents.
By default, simple implicit shared shapers activate scheduler nodes in named
traffic-class groups. The implicit constituent selection process is now the same
for both simple and compound shared shapers.
RADIUS
This is a change in default behavior. For releases before Release 7.2.0, you
could not configure scheduler nodes as active constituents of the simple shared
shaper, except for the best-effort node.
To recover the default behavior available before Release 7.2.0, or to select
active constituents that are different, use simple explicit shared shapers to
select best-effort nodes only.
JunosE Software provides extended commands for configuring the formats of
the RADIUS NAS-Port attribute (attribute 5) and the RADIUS Calling-Station-ID
attribute (attribute 31) when the physical port value is greater than 7.
When the physical port value is greater than 7:
An incorrectly configured NAS-Port attribute format results if you use either
the radius nas-port-format 0ssssppp or radius nas-port-format ssss0ppp
command.
An incorrectly configured Calling-Station-ID attribute results if you use
either the radius calling-station-format fixed-format command or the
radius calling-station-format fixed-format-adapter-embedded
command.
Work-aro u n d: Use the following commands on routers that have line modules
with more than 7 physical ports:
To configure the NAS-Port attribute format, use the radius nas-port-format
To configure the Calling-Station-ID attribute format, use the radius
Information about all the SNMP MIBs (both standard and proprietary) that the
router supports in this release is available in the MIB directory in the
SW_Image_CD-2 folder of the JunosE Software image bundle, which you
downloaded from the Juniper Networks website, that contains the release file
for E120 and E320 routers. .
Some Juniper Networks SNMPv1-formatted traps contain an incorrect object
identifier (OID) in the SNMPv1-Trap-PDU enterprise field. An SNMPv2 trap is
typically identified by an OID that ends in the form ...x.y.z.0.n. This OID
appears, in full, as the value of the snmpTrapOID.0 object in the varbind list of
an SNMPv2-formatted trap. In the corresponding SNMPv1-formatted trap, this
OID is broken down into subcomponents that fill the SNMPv1-Trap-PDU
enterprise field (...x.y.z) and specific trap number field (n); the zero is unused.
The SNMPv1-formatted versions of the following Juniper Networks traps
incorrectly contain ...x.y.z.0 in the SNMPv1-Trap-PDU enterprise field. That is, a
zero is mistakenly appended to the correct enterprise OID value
Trap NameExpected Enterprise OIDEnterprise OID Sent by SNMP Agent
Work-aro u n d: Use the OIDs that the SNMP agent sends.
SSH
If the SRP module restarts when SSH is configured in a VR other than default,
SSH can sometimes become disabled. This happens if SSH attempts to bind
with a VR before the VR comes back up after the restart. In this event, a
warning message is generated to alert you to the fact that SSH is disabled in
that VR. You must manually re-enable SSH either by accessing the console VTY
or creating a Telnet session to the router.
Known Behavior 31
JunosE 10.3.2 Release Notes
Stateful SRP Switchover (High Availability)
Additional processing is required to maintain and mirror the necessary state
information that enables subscriber sessions to stay up across an SRP failover.
As a result, the performance of other control plane functions is reduced.
Specifically, call setup rates are lower than in previous releases.
NOTE: Rapid call setup rates are most important following an outage that causes all
subscribers to drop, because many of the dropped subscribers will immediately
attempt to reconnect. This type of outage occurs far less frequently with stateful
SRP switchover.
We have ongoing development activities to characterize and improve call setup
rates in future releases.
Stateful SRP switchover remains inactive for 20 minutes after an initial
cold-start or cold-restart of the router. This delay enables the system to reach a
stable configuration before starting stateful SRP switchover.
If you want to override the 20-minute timer, turn high availability off by using
the mode file-system-synchronization command, and then on again by using
the mode high-availability command.
After a stateful SRP switchover, each layer of the interface columns must
reconstruct its interfaces from the mirrored information. While the interfaces
are being reconstructed the SRP module cannot send or receive frames,
including the protocol frames that signal graceful restart behavior with OSPF
and IS-IS peers. If the configured hold time is too short, peers might mistakenly
declare the adjacency down during the time in which the graceful restart is
taking place. [Defect ID 65132]
Work-aro u n d: Increase the hold time to provide sufficient time for interface
synchronization before the peers declare the adjacency down.
For OSPF, use the ip ospf dead-interval command to set the hold time. We
recommend that you use Bidirectional Forwarding Detection (BFD) with a
longer OSPF dead interval to achieve fast failure detection.
For IS-IS, use the isis hello-interval and isis hello-multiplier commands to
set the hold time.
We recommend the following hold times for each protocol, based on the
number of interfaces.
Recommended Hold Time
Interface Count
16000 or less80 seconds50 seconds
16001 to 3200087 seconds55 seconds
32001 to 4800090 seconds70 seconds
for OSPF
Recommended Hold Time
for IS-IS
32 Known Behavior
Subscriber Interfaces
Release 10.3.2
When IP tunnels are configured on a router enabled for stateful SRP switchover,
and the Service Module (SM) carrying these tunnels is reloaded, stateful SRP
switchover transitions to the pending state. Stateful SRP switchover remains in
the pending state for 10 minutes following the successful reloading of the SM.
This amount of time allows for IP tunnel relocation and for the tunnels to
become operational again on the SM. If an SRP switchover occurs while in the
pending state, the router performs a cold restart.
Work-aro u n d: None.
MAC address validation is not supported on either of the following:
Packet-triggered subscriber interfaces that are created dynamically
Packet-triggered subscriber interfaces that are managed on the primary IP
interface
System
A packet-triggered subscriber interface is created when the router receives a
packet with an IP source address that does not match any entries in the
demultiplexer table. When the router detects an unmatched packet, it generates
a trigger event that determines whether to create a dynamic subscriber
interface or configure an existing interface. To configure packet detection on
the router, use the ip auto-detect ip-subscriber command.
ERX routers display different behavior from E120 routers and E320 routers
when reporting modules as inactive.
ERX routers report a module as inactive when either:
The I/O module is not present
The primary line module is fully booted and ready to resume operation. In
this case, the standby is currently providing services.
E120 routers and E320 routers report a module as inactive when either:
The primary line module has no IOAs.
The primary line module has IOAs, but they have failed diagnostics.
The standby line module has taken over for the primary line module, and
has control of the IOAs.
Because E120 and E320 routers can accommodate up to two IOAs per slot, at
least one IOA must be online. If the second IOA fails, the line module is still
online, but does not use both IOAs. You can ensure that every module is up and
active in the system and not in a failed state by issuing the show version all
command.
Known Behavior 33
JunosE 10.3.2 Release Notes
In a router with a redundancy group that does not span quadrants (for example,
a three-slot redundancy group that spans slots 0, 1, and 2 in an ERX1410
chassis), the potential bandwidth of the redundant module is erroneously
included in the quadrant bandwidth calculation. The show utilization
command might indicate that the bandwidth is exceeded for modules in that
group. [Defect ID 31034]
When you copy the running configuration to NVS, the E Series router verifies
whether it has available space equal to at least twice the size of the .cnf file. If
the space is insufficient, you cannot complete the copy. [Defect ID 40655]
Work-aro u n d: Make sufficient space on the NVS by deleting .rel or .cnf files.
You cannot delete the ipInterface log after you delete the corresponding IP
interface. This does not prevent you from adding filters to other interfaces, nor
does it prevent you from adding a filter to the same interface if you re-create it
after deletion. [Defect ID 34842/45063]
System Logging
Tunneling
Work-aro u n d: Remove the filter before you remove the interface. Alternatively,
if you remove the interface first, then you must remove all filters associated
with all IP interfaces.
If you enable engineering logs and set the control network logs to a level of
notice or lower (down from the default of error), you might see erroneous
controlNetwork log messages like the following that are generated because
SNMP polling on line modules (correctly) detects no fabric: [Defect ID 43168]
NOTICE 09/01/2002 18:47:52 CEST controlNetwork (slot 11): Control Bus
Master slave error 0x5 while accessing slot
When you configure the GE-2 line module, the GE-HDE line module, or the
ES2-S1 GE-4 IOA to operate as a shared tunnel-server module, the available
bandwidth for tunnel services is limited to 0.5 Gbps per module.
In releases numbered lower than Release 7.3.0, a dynamic tunnel-server port
was located on port 8 of the GE-HDE line module and GE-8 I/O module.
In Release 7.3.0 and higher-numbered releases, the dynamic tunnel-server port
is located on port 9. When you upgrade to Release 7.3.0, any existing
tunnel-server port configurations move from port 8 to port 9.
34 Known Behavior
Known Problems and Limitations
This section identifies the known problems and limitations in this release. For more
information about known problems that were discovered at customer sites, you can
log in to the JunosE Knowledge Base at https://www2.juniper.net/kb/, enter the
defect ID number in the Search by Keyword field, and click Search.
ANCP
On an E320 router that has established 3000 ANCP adjacencies with a client
and traffic is initiated, the following behavior occurs sporadically: All existing
Telnet sessions are disconnected and no new Telnet sessions can be established
for several minutes. [Defect ID 83872]
ATM
When 16,000 PPPoA interfaces are configured on an OCx/STMx ATM line
module paired with an OC3-4 I/O module in an ERX14xx model, ERX7xx
model, or ERX310 router, Ping traffic passing through the line module on the
restarting router experiences an outage of 103 seconds, which is beyond the
maximum limit, after a unified ISSU from JunosE Release 9.2.0p1-0 to
9.3.0b0-12. This outage does not occur when the same configuration is applied
on a Gigabit Ethernet interface. [Defect ID 179794]
Release 10.3.2
When you reload an ATM line module that is configured with NBMA circuits as
passive OSPF interfaces and that has established OSPF adjacencies and IBGP
peers (configured on Gigabit Ethernet interfaces), the transmission of OSPF
hello packets might be affected until all the NBMA interfaces have initialized.
[Defect ID 46157]
Work-aro u n d: Either remove the passive OSPF interface statements on the
NBMA interfaces, or statically configure the OSPF cost on the NBMA interfaces.
When a mirror rule that triggers on username is employed for packet mirroring
of dynamic IP subscribers over ATM, removal of the rule does not disable
packet mirroring. [Defect ID 175356]
Work-aro u n d: Use a mirror rule that triggers on account session ID rather than
on username.
The ATM peak cell rate (PCR) does not appear in the L2TP Calling Number AVP
for the first PPP session when the ATM shaping parameters were configured by
RADIUS return attributes. [Defect ID 60933]
When you issue the no atm atm1483 auto-configure upperInterfaceType
lockout-time command in Profile Configuration mode, the lockout time range
does not revert to the default values. [Defect ID 66544]
When one or more ATM1483 attributes appears in a profile, the show
configuration include-defaults command fails to display the default values for
all possible ATM1483 attributes. [Defect ID 67157]
The output of the show atm arp command displays only 4096 entries when the
line module is configured with more than 4096 NBMA ARP entries. [Defect ID
68849]
Known Problems and Limitations 35
JunosE 10.3.2 Release Notes
When you use the no-authenticate keyword with the subscriber command to
prevent subscriber authentication so that the subscriber information can be
used for DHCP option 82, suboption 2, the SRP module can reset. This issue
does not occur when you use the no-authenticate keyword with the subscriber
command as a way to perform a RADIUS configuration. [Defect ID 69865]
When you perform an snmpWalk on the juniAtmSubIfVccTable, a response is
received for only a few of the total configured ATM subinterfaces when both of
the following are true: the router has a line module that has some ATM-related
configuration and the line module is in the disabled state. [Defect ID 80020]
The baseline interface atm command fails for a VCD assigned by the router to
F4 OAM circuits. [Defect ID 174482]
Unified ISSU is not supported when ILMI is configured on ATM interfaces.
[Defect ID 176007/177297/177122]
ATM line modules reset after unified ISSU completes at the LAC when an
MLPPP bundle with three links are tunneled to the LNS. [Defect ID 178821]
For PPPoE, the AAL5 inPacket Discards counter might increment erroneously
during call setup when a packet is passed directly to PPPoE for negotiation
rather than being discarded. [Defect ID 51757]
Work-aro u n d: Incremental InPacketDiscards during call setup do not
necessarily indicate a problem. However, we recommend you investigate an
excessive count because that might indicate a connection that cannot be
successfully brought up for some reason, such as RADIUS denials or improper
configuration.
The inPacketOctetDiscards counter in the output of the show atm vc atm
interfacevcd command includes both inBytesDropped and
inBytesUnknownProtocol statistics. The inBytesUnknownProtocol statistics
should be displayed by a separate counter.
At the major interface level, the inPacketDiscards counter includes both
inPacketsDropped and inPacketUnknownProtocol statistics. The
inPacketUnknownProtocol statistics should be displayed by a separate counter.
[Defect ID 44286]
When you configure an ATM PVC where PCR = SCR and maximum burst size
is zero, the CLI returns an error indicating the burst size is invalid and it does
not create the VC. [Defect ID 58357]
Work-aro u n d: Configure a CBR or a UBR plus PCR to create the circuit with the
same parameters, depending on the desired priority for the traffic. CBR has a
high priority and UBR plus PCR has a medium priority.
The line module resets when you issue the show nbma arp command after you
have configured NBMA interfaces on an ATM line module. [Defect ID
178031/88491]
36 Known Problems and Limitations
BFD
Bridged Ethernet
CLI
Release 10.3.2
After you have shut down the interface to the next hop (for the route that is
used to establish the BFD session), output for the show bfd session command
erroneously indicates the shutdown interface as Management Interface
(FastEthernet 6/0). [Defect ID 174271]
The CLI erroneously permits you to configure bridge1483 encapsulation over
AAL5MUX IP even though that configuration is not supported. [Defect ID
35013]
When you issue a run show ppp command, the CLI changes the configuration
level of the command line to Global Configuration mode rather than remaining
at the level from which you issued the command. [Defect ID 52165]
DHCP
Work-aro u n d: Reissue the commands necessary to reenter the desired mode.
The logout subscribers all command may not log out all of the DHCP
subscribers. Although the bindings and DHCP addresses are cleared, the show
subscribers summary command may display some of the DHCP subscribers.
[Defect ID 180176]
Work-aro u n d: Try using the dhcp delete-binding all command. If this does
not clear the subscribers, you may want to reload the line module to avoid
further issues.
DHCP packets are not forwarded to the DHCP server over dynamically created
interfaces when all of the following are true: [Defect ID 180343]
DHCP relay or DHCP relay proxy is configured on the router.
The client-facing interfaces are created dynamically using bridged Ethernet
over static ATM PVCs.
The ip auto-detect ip-subscriber command is configured to enable packet
detection (packet triggering) and to trigger creation of dynamic subscriber
interfaces.
Work-aro u n d: To avoid this defect, do all of the following:
Do not use the ip auto-detect ip-subscriber command to enable packet
Ensure that DHCP external server is configured in the virtual router.
Ensure that the set dhcp relay inhibit-access-route-creation command is
triggering and to create dynamic subscriber interfaces
configured in the virtual router to prevent DHCP relay from installing host
routes by default.
Known Problems and Limitations 37
JunosE 10.3.2 Release Notes
DHCP External Server
With the unique client ID option enabled, when two clients with the same MAC
address or client ID are on an interface (where one client is connected over a
router and relay and the other client is connected directly), sending a release
request from one of the clients might terminate another client. [Defect ID
179759]
The DHCP renew counter and release counter (displayed with the show ip
dhcp-external statistics command) are doubled rather than incremented for
each renew and release sent. [Defect ID 78802]
When DHCP clients on an S-VLAN over bridged Ethernet stack configuration
send a decline message to a router that has DHCP relay and DHCP external
server configured in the same VR, the clients bindings are not removed from
the DHCP external server. [Defect ID 87086]
When DHCP relay and DHCP external server are configured in the same VR
with server-sync enabled, bindings are not created in the DHCP external server
when DHCP clients on an ATM bulk configuration interface stack and dynamic
VLAN over Ethernet stack sends a renew message. [Defect ID 87087]
DoS Protection
Ethernet
DHCP NAK packets are sent from a different VLAN than the one on which the
renew request is received on a router that is configured with dynamic VLANs,
DHCP local server, and automatically created dynamic subscriber interfaces.
This behavior occurs only after a link flap has taken place. [Defect ID 87062]
A Telnet session closes when sending ipLocalBGP protocol traffic at a rate in the
range 4096–4200 packets per second (pps) with suspicious control flow
detection enabled. [Defect ID 81974]
Work-aro u n d: When the traffic drops below 4096 pps, open a new Telnet
session.
When autonegotiation is enabled on Gigabit Ethernet interfaces with the speed
automatically negotiate command, issuing the link selection command logs
out subscribers. [Defect ID 87185]
Work-aro u n d: Use the following commands to enable auto link selection (GE
port redundancy) and to switch from one port to the other port:
(config-if)#no link selection
(config-if)#link failover force
File System
When the primary SRP module is running JunosE Release 7.2.0 or
higher-numbered release and the standby SRP module is running a release
numbered lower than Release 7.2.0 (as in a downgrade situation), you cannot
display the files for the standby SRP module. [Defect ID 74104]
38 Known Problems and Limitations
Forwarding
Release 10.3.2
The DoS protection egress rate is not accurate for the ES2 10G LM or the ES2
10G Uplink LM. [Defect ID 86925]
When performing MAC validation to match subscriber demux entries with ARP
host entries, the ES2 10G LM does an exact match, rather than a longest prefix
match. The subscriber demux entry source address must be a /32 value
matching the IP address of an ARP entry in order to validate the MAC address
against that ARP entry. [Defect ID 79641]
When PPPoE over LAG is configured on an interface, and you re-execute the
PPPoE-over-LAG configuration before you delete the previous configuration, the
ES2 10G LM line module resets. [Defect ID 179639]
Work-aro u n d: Before you can re-execute the PPPoE-over-LAG configuration,
delete the existing PPPoE-over-LAG configuration.
VPLS forwarding does not function properly when any of the following
conditions occur: [Defect ID 79856]
MLPPP interfaces are used
L2TP is used with sequence numbers enabled
GRE is used with sequence numbers enabled
Specifying S-VLAN ranges that partially overlap does not work. [Defect ID
81886/81918]
For example, the following configuration fails because S-VLAN 22 falls within
the previously specified S-VLAN range of 21–23.
When you attach certain hierarchical policies to subinterfaces as input policies,
secondary input policies, and output policies, incoming traffic loss can occur
when the number of subinterfaces to which the policies are attached exceeds
4600. [Defect ID 86741]
Ethernet statistics are incorrectly displayed for virtual port 8 of the ES2-S1 GE-8
IOA when that module is paired with the ES2 10G LM or the ES2 10G Uplink
LM. [Defect ID 174784]
The ES2 10G LM does not support framed routes configured for dynamic
subscriber interfaces. [Defect ID 83154]
A memory leak of about two percent can occur on the ES2 10G LM and result in
a module reset when a large number of successive SRP switchovers take place
with active DHCP clients. [Defect ID 86245]
On the ES2 10G LM, a VLAN ID of 0 assigned to an interface can prevent
packets from being properly forwarded. [Defect ID 176125]
ICR
When you configure ICR settings using a CLI macro, ICR commands are run in
quick succession. Sometimes, in such a scenario, the active SRP module resets
if the event that causes the change of state of the VRRP instance reaches the
ICR application before the ICR partition has been created. [Defect ID 184095]
Work-aro u n d: To avoid this problem, add an additional delay of one second
using the sleep command in the macro, before the ip vrrpvridenable
command that is written in the macro to enable VRRP instance.
For example, consider a macro that contains the following commands:
ip vrrp vrid enable
ip vrrp vrid icr-partition partitionId
Modify the macro, as follows, to add a delay of one second before the VRRP
instance ID is enabled on the router and a delay of another second before the
ICR partition that corresponds to the VRRP instance is created:
sleep 1
ip vrrp vrid enable
sleep 1
ip vrrp vrid icr-partition partitionId
40 Known Problems and Limitations
IGMP
Release 10.3.2
If you saved the running configuration of the router as a script file (.scr) and
execute the script to apply the settings on the router, ICR partition configuration
commands in the .scr file might fail to add group members to the partition. This
problem happens when the subscriber configuration in the .scr file is placed
before the ICR partition configuration. However, this problem does not occur if
you used a system configuration (.cnf) file to set up the router. [Defect ID
183913]
Work-aro u n d: To correct this problem and enable ICR partitions to be created
correctly, make sure that you add the ICR partition configuration before the
subscriber interface configuration in the .scr file. You can perform this
reordering by modifying the .scr file to place the commands that configure
subinterfaces for ICR partitions before the commands used for VLAN-based or
S-VLAN-based grouping of subscribers.
IGMPv3 proxy is not supported. [Defect ID 46038]
IP
The E Series router IGMPv3 proxy does not operate correctly in the presence of
IGMPv2 queriers. [Defect ID 46039/46045]
Work-aro u n d: If an IGMPv2 router is present on the network, do not configure
version 3 with the ip igmp-proxy version command on that network interface.
(Version 2 is the default.)
The default value for the IGMPv3 proxy unsolicited report interval timer should
be 1 second rather than 10 seconds (the value for v2). [Defect ID 46040]
When more than about 100,000 mapped OIF entries are configured on a virtual
router, issuing the no virtual router command for this and other virtual routers
does not delete all the virtual routers within the deletion timeout interval (3
minutes). The virtual routers do eventually delete after this timeout. [Defect ID
63882]
The E Series router does not log a warning when it receives an IGMPv2 query
but is not configured to use IGMPv2 on the interface. [Defect ID 46046]
The ES2 4G LM can reset during a unified ISSU after you issue the issu start
command on a router configured with 8000 dynamic VCs and 8000
packet-triggered dynamic subscriber interfaces. [Defect ID 86761]
If you have a large configuration on a hybrid module combination (OC3/STM-1
GE/FE line module with the OC3-2 GE APS I/O module), boot from NVS, and
issue the slot erase command before booting has completed, the line module
resets. [Defect ID 64104]
Work-aro u n d: To recover from the error, issue the slot reload command
anytime after the module begins to reset.
Known Problems and Limitations 41
JunosE 10.3.2 Release Notes
Deleting a VRF with 32,000 static subscriber interfaces fails to complete.
[Defect ID 82670]
Work-aro u n d: Use a macro to delete all static subscriber interfaces before you
delete a VRF.
IP interface statistics become inconsistent when a slot is reset, because some
traffic (such as control traffic) might be destined for the SRP module and is
therefore counted elsewhere. [Defect ID 26697]
The ip route permanent command does not work properly. [Defect ID 34303]
Work-aro u n d: Issue the ip alwaysup command to prevent the route from being
removed from the IP routing table after the interface is shut down.
Traffic statistics for dynamic subscriber interfaces associated with Mobile IP
subscribers are not maintained as the subscribers move between Mobile IP
nodes. Consequently the reported interface statistics are only the values
accumulated since the last time a mobile node moved. [Defect ID 174509]
IPSec
When a router configured with PIM on a virtual router undergoes multiple
warm restarts, the router subsequently hangs when an IP profile is configured.
[Defect ID 176470]
Logical port 20 on the ES2-S3 GE-20 IOA is reserved for the hardware multicast
packet replication feature. Logical port 20 and the hardware multicast
replication feature are not supported on the ES2-S3 GE-20 IOA in this release.
[Defect ID 84727]
When you change the demultiplexer type on a primary interface that has 1024
demultiplexer table entries, the ICC ping threshold times out due to the removal
of the old entries and the addition of the new ones. [Defect ID 182218]
After an SRP stateful switchover completes on an ERX1410 router configured
with a single VPN routing and forwarding instance (VRF) and Network Address
Translation (NAT), the SRP module that becomes active after the switchover
resets. [Defect ID 180058]
In a network where you use the tunnel signalling command to specify that the
security parameters and keys are configured manually for IPSec tunnels
between VRs, the line modules reset when you delete and then re-create the
IPSec tunnels. If you attempt to configure the tunnels again after the modules
come back up, the line modules reset again.
Work-aro u n d: Configure the IPSec tunnels to use ISASKMP/IKE to negotiate SA
and establish keys. [Defect ID 178304]
When the LAC–to–LNS data path runs over an MPLS tunnel and the MPLS
tunnel originates or terminates at the LAC on an ES2 10G LM or an ES2 10G
Uplink LM, the L2TP data traffic that originated or terminated at the LAC is
discarded. [Defect ID 87260]
42 Known Problems and Limitations
IS-IS
Release 10.3.2
IPSec tunnels created over Fast Ethernet interfaces fail to come up. [Defect ID
179256]
Work-aro u n d: After you create the tunnel, bounce the tunnel interface by
issuing the shutdown/no shutdown command sequence. The tunnel comes up
successfully.
On a router configured with IS-IS and BFD, using the redundancy force srp
command to force an SRP switchover sometimes brings down IS-IS and BFD.
[Defect ID 179287]
IS-IS graceful restart (nonstop forwarding) does not work on the broadcast
interface when the restarting router is the designated intermediate system
(DIS). Graceful restart works properly when the restarting router is not the DIS.
[Defect ID 61496]
L2TP
MLD
MLPPP
After a unified ISSU completes on a router functioning as an L2TP access
concentrator (LAC), traffic outages occur on the L2TP network server
(LNS)-facing interface at the LAC in a configuration with 16,000 or 32,000 L2TP
sessions over 500 tunnels. [Defect ID 180147]
MLDv2 proxy is not supported. [Defect ID 46038]
The E Series router MLDv2 proxy does not operate correctly in the presence of
MLDv1 queriers. [Defect ID 46039/46045]
Work-aro u n d: If an MLDv1 router is present on the network, configure version
1 with the ipv6 mld-proxy version command on that network interface.
(Version 2 is the default.)
The default value for the MLDv2 proxy unsolicited report interval timer should
be 1 second rather than 10 seconds (the value for v1). [Defect ID 46040]
The E Series router does not log a warning when it receives an MLDv1 query
but is not configured to use MLDv1 on the interface. [Defect ID 46046]
Failure to meet all of the following conditions for fragmented packets can result
in an incorrect operation during packet classification of the resulting
reassembled packet: [Defect ID 50111]
The initial fragment of a packet must either contain the entire MLPPP
The fragment size of the peer must not be lower than 128 bytes.
The initial fragment of a packet must be larger than subsequent fragments
packet or be greater than 128 bytes.
of that packet.
Known Problems and Limitations 43
JunosE 10.3.2 Release Notes
Mobile IP
The @realm variable and the @ keyword alone do not work for the show ip
mobile binding command. [Defect ID 178653]
Work-aro u n d: You can use the user@realm syntax instead to display the
binding for a specific user, as in this example:
host1#show ip mobile binding nai xyz@example.com
Alternatively, you can display the entire Mobile IP binding table by issuing the
show ip mobile binding command without additional options.
The clear ip mobile binding nai @realm command does not work. [Defect ID
178652]
Work-aro u n d: Use the following version of the command instead:
MPLS
clear ip mobile binding nai
The setup rate for Mobile IP client sessions decreases when you repeatedly
user@realm
bring a large number of sessions down and back up. [Defect ID 178760]
When mobility bindings are present and you delete the Mobile IP home agent
with the no virtual router command, Mobile IP sends a RADIUS Acct-Stop
message with no accounting statistics for the subscribers. [Defect ID 179081]
Work-aro u n d: Issue the clear ip mobile binding all command before you
issue the no virtual router command. The clear command clears all the MIP
subscribers and sends a RADIUS Acct-Stop message with the appropriate
accounting statistics for the subscribers.
When MPLS and IS-IS are configured on Ethernet interfaces, you cannot delete
the interface after the IP address is removed. This issue is not a problem on
Ethernet VLAN interfaces. [Defect ID 66813]
Work-aro u n d: Issue the no mpls command to disable MPLS, then delete the
interface.
You cannot use an underscore character (_) in an MPLS tunnel name. [Defect ID
31291]
If LSPs are announced into IS-IS, then the IS-IS routes cannot be used for
multicast RPF checks, because LSPs are unidirectional. [Defect ID 28526]
Work-aro u n d: Configure static RPF routes with native hops when LSPs are
autoroute announced to IGPs.
When the IPv4 explicit null label appears anywhere other than at the bottom of
the label stack, TTL expiration for this label is not handled correctly. As a result,
the traceroute command does not work correctly for LSPs that have the IPv4
explicit null label anywhere other than at the bottom of the label stack. [Defect
ID 76037]
44 Known Problems and Limitations
Multicast
Release 10.3.2
When you issue a traceroute or trace mpls command to trace the paths of
router packets over MPLS interfaces on an ES2 10G LM or ES2 10G Uplink LM,
the results include an extra unknown host. [Defect ID 174537]
When you upgrade the router to JunosE Release 7.1.0 or a higher-numbered
release from a release numbered lower than Release 7.1.0, remote ATM layer 2
over MPLS circuits (also known as MPLS shim interfaces) that use Martini
encapsulation are erroneously signaled with the control word attribute setting
“Control word is not preferred by default”. Because control words are required
for these MPLS shim interfaces, these circuits should instead be signaled with
the setting “Control word is preferred by default”. [Defect ID 87048]
Work-aro u n d: To reinstate the proper setting (“Control word is preferred by
default”), remove the MPLS shim interface from the ATM subinterface and then
reconfigure it.
When you configure more than 10,219 outgoing interfaces (OIFs) on the same
ES2 10G LM in a single multicast group, the configuration of the multicast
group’s OIF membership from the SRP module to the line module exceeds the
size of a single message and is sent in fragments. Because of this
fragmentation, the ES2 10G LM generates the following error message: [Defect
ID 81768]
Netflow
Policy Management
pc: 0x9e5c88: -> fatalPanic(void) offset: 0x8
Flow sampling stops after a cold switchover on a router that is configured with
16 VRs and 32 interfaces per VR, when all flows are passing through the
configuration (32 flows per VR). [Defect ID 74477]
Work-aro u n d: After the cold switchover is completed, reissue the ip
flow-sampling-mode packet-interval 10 command on each VR, even though
the command is present in the configuration.
The OC3/STM1 GE/FE line module might reset after sending Ethernet traffic
into a VPLS network in a test environment when Ethernet packets are flooded
to remote VPLS bridges. [Defect ID 74540]
On the E320 router, redirecting a large configuration with thousands of
interfaces to a script file can take a long time, perhaps exceeding a half-hour
depending on the configuration. [Defect ID 80429]
When you modify a rate-limit profile in Global Configuration mode after the
system is in a scaled state, changes to the rate-limit profile fail owing to lack of
adequate policy resources. However, the changed value of the rate-limit profile
is displayed in the output of the show rate-limit profile command. [Defect ID
79342/184107]
Work-aro u n d: To avoid this problem, do not update the rate-limit profile in
Global Configuration mode in a scaled environment.
Known Problems and Limitations 45
JunosE 10.3.2 Release Notes
When you attach a policy to an interface and the policy contains a classifier rule
that is unsupported for that interface, the CLI generates a message and the
policy is applied. However, if an existing policy is already attached to that
interface, then support for the new policy is not checked and the invalid policy
is applied to the interface without warning. The results of this attachment are
not predictable. [Defect ID 83562]
If you have removed the last rule in a policy list, the router generates a warning
only after you exit Policy List Configuration mode. If you have removed the last
policy rule and then added a classifier group before you exit Policy List
Configuration mode, the router does not generate a warning about removing
the last rule. [Defect ID 83834]
When an MD-Port-Number value greater than 65,535 is sent to an E120 or
E320 router by means of a COA request, the value that is displayed in the UDP
header of mirrored packets is the actual value minus 65,536. For example, an
MD-Port-Number of 65,540 is displayed in the mirrored packet as 4. [Defect ID
84712]
On the E120 and E320 routers, when a mirror rule is deleted after a CoA
request is sent with Juniper-LI-Action set to No-Action, the existing mirroring
session is not disabled. [Defect ID 84826]
No logs are created if you use the policy-list option with the log severity
severityValuepolicyMgrPacketLog policy-list policyListName command when
logging policyMgrPacketLog events. [Defect ID 87203]
When you reload the slot holding a GE-2 or GE-HDE line module and you have
configured more than about 2000 policies with rate limiting on that module,
the drop count becomes more than expected. This unexpected drop count does
not occur when you create the same configuration after you reload the router to
the factory-default configuration. [Defect ID 175696]
Unified in-service software upgrade (unified ISSU) is not supported on an E120
or E320 router if a hierarchical policy is attached to an external parent group.
[Defect ID 177478]
On E320 line modules that support secure policies, the SRP module enables
you to configure more than 1022 secure policies per module. [Defect ID
175756/180360]
Work-aro u n d: To avoid potential performance issues, we recommend that you
do not configure more than 1022 secure policies per module.
When you enter the no ip policy-parameter hierarchical parameterName
command or no ipv6 policy-parameter hierarchical parameterName
command for a hierarchical policy-parameter type in Interface Configuration
mode, the explicit reference of the parameter is removed successfully from the
interface. However, the Referenced by interfaces field in the output of the show policy-parameter command does not change from the previously configured
value to implicit. [Defect ID 183957]
Work-aro u n d: To correct this problem, remove the entire interface
configuration.
46 Known Problems and Limitations
PPPoE
QoS
Release 10.3.2
The E Series router erroneously accepts a PADI with a payload length of 0
instead of rejecting it and incrementing the PPPoE Invalid PAD packet length
counter. [Defect ID 48356]
You cannot paste a load-rebalance command string that uses the percent
option into a console or Telnet session from show configuration output
because the output displays the % sign rather than the percent keyword that
was submitted with the command and the percent sign is not recognized by the
CLI. [Defect ID 81705]
The router cannot resolve inconsistent requests caused by two QoS profiles that
modify the same scheduler property inconsistently. [Defect ID 61485]
Work-aro u n d: Avoid using two QoS profiles that modify the same scheduler
property inconsistently, such as setting different values for the shaping rate for
the same S-VLAN node.
Simple shared shaping does not function correctly when it is used for 32,000
subscribers on an ES2 10G ADV LM. However, when you change the shaper to
compound shared shaping, it works properly. Also, simple shared shaping does
not function correctly for 16,000 subscribers on an ES2 10G ADV LM. [Defect
ID 183512]
When you perform an SNMP walk of the juniQosQueueStatistics MIB, a timeout
of up to 5 minutes ensues, during which the SRP module CPU utilization goes to
100 percent. [Defect ID 62252]
The compound shared shaping feature does not work properly on egress
forwarding ASIC 2 (EFA2)-based ATM line modules when the shared shaper is
queue-controlled as opposed to node-controlled. In a node-controlled
configuration, in which you configure the shared-shaping rate on the best-effort
scheduler node for the logical interface, integration of the EFA2 and ATM
segmentation and reassembly (SAR) schedulers functions properly. However, in
a queue-controlled configuration, in which you configure the shared-shaping
rate on the best-effort queue for the logical interface, integration of the EFA2
and ATM SAR schedulers does not function properly. [Defect ID 69167]
Work-aro u n d: Use node-controlled compound shared shaping configured on
the best-effort scheduler node with EFA2-based ATM line modules.
Egress strict-priority packets may experience high latency on OC3/STM1 ATM
interfaces associated with the LM if you have shaped the port rate to more than
148.5 Mbps. [Defect ID 80378]
Work-aro u n d: To ensure low strict-priority latency, shape the port rate to no
more than 148.5 Mbps.
An error message regarding the qos-parameter instance
QosParameterDefinition is erroneously generated on an ERX1440 router when
it is configured for L2C and QoS RAM and receives TLV 144 (DSL Type). The
parameter instantiation actually functions properly. [Defect ID 80620]
Known Problems and Limitations 47
JunosE 10.3.2 Release Notes
The CLI erroneously enables you to configure a QoS profile with the ethernet
node group command. [Defect ID 80861]
The dynamic shaping rate calculated by the simple shared shaper can vary
because of the variation in the enqueue rate of the constituent queues. Even
when the offered load is constant, the mechanism that calculates the enqueue
rate introduces a slight variation, introducing a slight variation in the calculated
dynamic shaping rate. [Defect ID 80938]
On a router that has both an ES2 10G LM and an ES2 4G LM installed, the byte
count reported by the show fabric-queue egress-slot command is incorrect.
The reported packet count is correct. [Defect ID 80965]
On the E120 and E320 routers, you cannot attach QoS profiles to L2TP tunnels
by means of the CLI because the CLI does not pass the router ID to QoS. [Defect
ID 81516]
PPP sessions may be dropped if you change the shaping rate in a QoS profile
that affects thousands of circuits while QoS traffic affected by the profile is
being forwarded. [Defect ID 82950]
Work-aro u n d: Do not change the shaping rate in a QoS profile that affects
thousands of circuits while QoS traffic is using the profile.
Egress traffic may be dropped on OC12/STM4 ATM interfaces if you have
shaped the port rate to more than 542 Mbps. [Defect ID 83785]
Work-aro u n d: Do not exceed a shaped port rate of 542 Mbps.
Incorrect output is sent to the CLI the first time you enter Global Configuration
mode or issue the show subscribers command after viewing the VLAN
subinterface over which a subscriber is connected. [Defect ID 84507]
When QoS resources such as failure nodes and statistics bins are exhausted
because of insufficient memory available on the line module, the failures are
properly logged, but additional log messages are generated every 10 minutes
that report zero failures. [Defect ID 85105]
The no qos-parameter-define definition command does not delete the
specified QoS parameter definition. [Defect ID 176844]
Work-aro u n d: Remove the interface and add the desired QoS parameters when
you re-create the interface instead of deleting the definition.
When you configure an E120 or E320 router with an ES2 10G ADV LM as a LAC
on one side of an L2TP tunnel and as a LNS to receive packets from the LAC on
the other side of the tunnel, use RADIUS servers for authentication of
subscribers on both sides of the tunnel, and attempt to bring up 16,000
subscribers on the L2TP tunnel, the LM that has subscribers on the LAC side of
the tunnel resets when approximately 8000 logged-in subscribers are logged
out and try to reestablish the connection. [Defect ID 184118]
48 Known Problems and Limitations
RSVP-TE
Service Manager
Release 10.3.2
When 32,000 subscribers with 128,000 QoS queues are brought up on an ES2
10G or ES2 10G ADV LM, the LM resets if you modify the QoS profile that
contains the best-effort IP or VLAN node rule, which references a scheduler
profile configured with shared shaping rate, to a scheduler profile configured
with legacy shaping rate. [Defect ID 183291]
Work-aro u n d: To avoid this problem, apply shared shaping on the best-effort
queue, instead of on the best-effort node.
After a stateful SRP switchover, forwarding of VPN traffic might not resume if
the core interface that carries an MPLS base tunnel with LDP over RSVP-TE
flaps (constantly goes up and down). [Defect ID 182019]
After you activate an independent IPv6 service and issue either of the following
commands on the default virtual router or any other virtual router, except the
one on which the subscriber session is active, no output is displayed in the CLI
interface: [Defect ID 181929]
This problem also occurs when a subscriber is authenticated using a RADIUS
server for a combined IPv4 and IPv6 service in a dual stack.
Work-aro u n d: To avoid this problem, use the show service-management
owner-session ownerName ownerId command to display subscriber session information based on the session owner, instead of the show
service-management subscriber-session subscriberName interface
interfaceType command to display details on subscriber sessions.
When you configure the router with an address pool that has two IP address
ranges, only the range that you configured first is available via the MIB. [Defect
ID 61232]
After an SRP switchover in a dynamic PPPoA configuration, the following error
message is displayed: [Defect ID 69733]
ERROR 08/19/2005 20:17:32 ipProfileMgr: doDcmIpIntfCreate : Creation of IP
interface/address failed with status: Reference to Unnumbered Interface
ERROR 08/19/2005 20:17:32 ipProfileMgr: doDcmIpIntfCreate : Creation of IP
interface/address failed with status: Reference to Unnumbered Interface
Known Problems and Limitations 49
JunosE 10.3.2 Release Notes
You cannot use the highest sensitivity bit-error rate setting (a value of 9)
SRC Software and SDX Software
The SRC client does not prevent you from changing the name of the router
associated with APS/MSP alarm when you issue the threshold sd-ber
command to configure a cOCx/STMx line module with cOC12-APS-capable
IOAs. [Defect ID 72861]
Work-aro u n d: Use only a value in the range 5–8 when you issue the threshold
sd-ber command for this module combination, as in the following example:
host1(config)#controller sonet 2/1
host1(config-controll)#aps group boston
host1(config-controll)#aps protect
host1(config-controller)#threshold sd-ber 6
while the client is connected to the SAE, resulting in SAE issues such as lost IP
addresses and stale users. [Defect ID 77102]
Work-aro u n d: To change the router name while the SRC client is connected to
the SAE, shut down the SRC client, change the name, then re-enable the SRC
client.
When multiple IPv6 interfaces are configured with policies attached from SRC,
only some of the IPv6 interfaces have the policies attached. [Defect ID 179498]
Changing the SSCC status (enable/disable) while IPv6 interfaces are configured
might cause the SRP to reset. [Defect ID 179537]
Stateful SRP Switchover (High Availability) and IP Tunnels
When you issue show commands as soon as the CLI is available after a stateful
SRP switchover, the commands can hang until the warm restart is completed.
[Defect ID 85306]
A packet loss sometimes occurs during stateful SRP switchover when you use
the ping command on a router that is configured for OSPF graceful restart, and
is connected to a helper router in the OSPF IPv6 broadcast network and
another helper router in the OSPF IPv6 backbone area. [Defect ID 181470]
ERX7xx model, ERX14xx model, or ERX310 router:
When you use the ping command with the IPv6 address of the helper
router in the multicast area as the destination address and the
loopback address of the helper router in the backbone area as the
source address, a packet loss of 2 seconds occurs for the first stateful
SRP switchover. However, no packet loss occurs for successive stateful
SRP switchovers.
50 Known Problems and Limitations
When you use the ping command with the IPv6 address of the helper
router in the broadcast network as the destination address and no
source address when stateful SRP switchover is performed the first
time, an identical packet loss occurs. In this case too, no packet loss
occurs during subsequent switchovers.
Subscriber Management
When a dynamic GRE tunnel interface for Mobile IP relocates between SM
Release 10.3.2
E120 router or E320 router
When you use the ping command with the IPv6 address of the helper
router in the broadcast network as the destination address and the
loopback address of the helper router in the backbone area as the
source address, no packet loss occurs.
When you use the ping command with the IPv6 address of the helper
router in the multicast area as the destination address and no source
address, a packet loss of 1–2 seconds sometimes occurs during stateful
SRP switchovers.
modules because the original SM reloads, Mobile IP deletes the relocated tunnel
interface. [Defect ID 178399]
When a subscriber has subscribed for a service, service session accounting
records always contains a default Acct-Terminate-Cause value of 10. This value
remains unchanged even after you use the terminate-code command to
configure a custom mapping between application terminate reasons and
RADIUS Acct-Terminate-Cause attributes. [Defect ID 181043]
MAC address validation not working for IP auto-detect sessions. [Defect ID
86446]
Dynamic subscriber interfaces continue to remain in the down or not present
operational state in either of the following scenarios: [Defect ID 81269]
If you configured a dynamic interface column, such as a dynamic bridged
Ethernet interface, dynamic VLAN interface, or an ATM interface, and when
any one of the following conditions is satisfied:
The major interface is bounced (shut down and reenabled)
The major interface is shut down, which cause the dynamic VLAN
interfaces to be removed
The physical link goes down and comes back up
The line module is removed and reinserted
If you configured a static interface column and removed the major interface
These scenarios might occur if you administratively issue the shutdown and no
shutdown commands on the major interface in which the dynamic interface
column is configured.
Work-aro u n d: Use the no interface ip ipAddress command to remove the
dynamic subscriber interfaces. Although you can use the dhcp delete-binding
command to remove the DHCP binding and the dynamic subscriber interfaces,
the DHCP client does not detect the binding removal and retains the lease.
Known Problems and Limitations 51
JunosE 10.3.2 Release Notes
System
You cannot use a configuration script to boot the E320 router. [Defect ID
80304]
If you hot swap an IOA and then remove it again before that IOA’s OK or FAIL
LED is illuminated, the associated line module can reset. [Defect ID
177313/177267]
Work-aro u n d: Ensure that you firmly insert the IOA into the chassis when you
hot swap IOAs. Do not attempt a second hot swap of an IOA that has not
indicated that it completed the first hot swap cycle. You can remove the IOA
when either its OK or FAIL LED is illuminated.
If your router is in Manual Commit mode, then you must issue the write
memory command before you perform an SRP module switch or a manual
reload. You must do this even when you have made no changes to the system
configuration and the file systems are synchronized. [Defect ID 44469]
System Logging
TCP
Unified ISSU
The show configuration category management syslog virtual-router default
command incorrectly displays logs for multiple syslog destinations when you
add a log to only one syslog destination. The show log configuration
command shows the correct configuration. [Defect ID 84082]
The SRP module resets in any of the following circumstances on an E320 router
that has a line module configured with 5000 ANCP adjacencies: [Defect ID
176916]
When you issue the issu initialization command from the console and
then reload the line module from a Telnet session.
When the client that has the 5000 ANCP clients resets or an intermediate
switch resets.
When you reload the line module.
ATM line modules might reset after a unified ISSU when you attempt to add
memory to a VLAN subinterface in a large bridged Ethernet configuration.
[Defect ID 178798]
Under certain conditions, a unified ISSU from JunosE Release 9.2.0p1-0 to the
current release fails, and causes the SRP module and the ES2 4G LM to reset.
[Defect ID 179975]
Unified ISSU is not supported with 8000 bridged Ethernet interfaces on an
OC3/STM1 GE/FE ATM line module. [Defect ID 178809/178811/178797/
179547]
52 Known Problems and Limitations
Release 10.3.2
When any of the subsystems is excluded for a JunosE release, a unified ISSU to
that release fails to apply conversion code to all of the line modules. As a result,
the line modules reset when they come up with that release. [Defect ID
179595]
Work-aro u n d: To prevent the exclusion of a subsystem file from the release, do
the following before you upgrade to a new JunosE release that supports unified
ISSU:
1. Issue the show subsystems file fileName.rel command, where fileName is
the name of the software release file, to determine whether any of the
subsystem files are excluded from the release.
2. For each subsystem file that is excluded, issue the no exclude-subsystem subsystemName command to remove the exclusion for the specified
subsystem file.
If you copied the software release to the router before removing the subsystem
file from the exclusion list, you must copy the release to the router again to
ensure that all subsystem files are included in the release.
During the unified ISSU operation, if you modify the router configuration after
the initialization phase of the process is completed and before you issue the
issu start command to commence the upgrade phase of the unified ISSU
process, the unified ISSU procedure completes successfully and the stateful SRP
switchover process begins to synchronize between the active and standby SRP
modules. When the synchronization process is in progress, the standby SRP
module reloads for the second time. After the second reload of the standby SRP
module ends, the synchronization process also ends properly.
Although the standby SRP module reloads for the second time when it is
synchronized with the upgraded release, normal router operations, such as
handling of subscriber sessions and forwarding of traffic, remain unaffected.
[Defect ID 185517]
Known Problems and Limitations 53
JunosE 10.3.2 Release Notes
Resolved Known Problems
ATM
BGP
The following problems were reported open in Release 10.3.1 and have been
resolved in this release, or have been resolved since the 10.3.1p0-3 patch release.
For more information about particular resolved problems, you can log in to the
JunosE Knowledge Base at https://www2.juniper.net/kb/, enter the defect ID
number in the Search by Keyword field, and click Search.
While doing HA switchover after ISSU with NBMA configuration, the OC3-4A
line card crashes. [Defect ID 184745]
Performance issues after upgrading ATM cards to EFA2 architecture. [Defect ID
This section identifies errors found in the JunosE documentation. These errors are
corrected in subsequent releases of the affected documentation.
The JunosE documentation for Release 6.0.5 and higher-numbered releases
states that when you upgrade the JunosE Software from Release 5.1.1 or
lower-numbered releases, you must perform the upgrade in two stages: first to
an intermediate release and then to the higher-numbered release that you want
to run. This statement is only partially correct; you must perform a two-stage
upgrade only when you upgrade from a new NVS card. This restriction is not
applicable if you upgrade your software remotely through Telnet or FTP.
The imprecise information appears in the following JunosE documents:
The Upgrading to JunosE Software Release 6.x.x or Higher-Numbered Releases
from Release 5.1.1 or Lower-Numbered Releases special hardware notice
dated 31 March 2006
The Upgrading to JunosE Software Release 6.x.x or Higher-Numbered Releases
from Release 5.1.1 or Lower-Numbered Releases section in the JunosE Release
Notes for the following releases:
Releases 6.0.5, 6.1.4, and 6.1.5
Releases 7.1.2, 7.1.3, 7.1.4, 7.2.x, 7.3.x
Releases 8.x, 9.x, 10.x, 11.0.x, and 11.1.x
The Upgrading to JunosE Software Release 6.x.x or Higher-Numbered Releases
from Release 5.1.1 or Lower-Numbered Releases section in ERX Hardware
Guide, Chapter 8, Maintaining ERX Routers for the following releases:
Release 7.3.x
Releases 8.x, 9.x, 10.x, 11.0.x, and 11.1.x
The Upgrading to JunosE Software Release 6.x.x or Higher-Numbered Releases
from Release 5.1.1 or Lower-Numbered Releases section in the JunosE System
Basics Configuration Guide, Chapter 3, Installing JunosE Software for the
following releases:
Release 7.3.x
Releases 8.x, 9.x, 10.x, 11.0.x, and 11.1.x
The ResolvedKnown Problems section of the JunosE 10.2.2 Release Notes failed
to mention in the IP section that defect ID 90081, High CPU utilization, was
fixed in that release.
58 Errata
Release 10.3.2
The Link Layer Maximums table (for the E120 and E320 routers) in Appendix A,
System Maximums, of the JunosE Release Notes, for the following releases
incorrectly stated that the maximum number of Ethernet S-VLANs per ES2-S2
10GE PR IOA with an ES2 10G LM or ES2 10G Uplink LM was 32,768:
Releases 10.2.0 and 10.2.1
Release 10.3.0
The correct limit for Ethernet S-VLANs per ES2-S2 10GE PR IOA on these LMs in
these releases is only 16,384. The increased scaling maximum of 32,768
Ethernet S-VLANs per ES2-S2 10GE PR IOA, in these releases, applies only to
the ES2 10G ADV LM.
The SRC Software and SDC Software section in the Subscriber Management
Maximums table (for the ERX310, ERX7xx, and ERX14xx routers) in Appendix
A, System Maximums, of the JunosE Release Notes, for the following releases
incorrectly mentioned that the maximum number of SRC interfaces supported
on all the ERX routers was 48,000.
Release 9.0.3
Release 9.1.3
Releases 9.2.2 and 9.2.3
Releases 9.3.1 and 9.3.2
Releases 10.0.1 and 10.0.2
Releases 10.1.0, 10.1.1, and 10.1.2
Releases 10.2.0 and 10.2.1
Release 10.3.0
The correct maximum number of SRC interfaces supported on the different
ERX routers is as follows:
16,000 interfaces on the ERX310 router
32,000 interfaces on the ERX705 and ERX710 router
32,000 interfaces on the ERX1410 router
48,000 interfaces on the ERX1440 router
Errata 59
JunosE 10.3.2 Release Notes
ERX Module Guide, Appendix A, Module Protocol Support incorrectly states that
IPv6 multicast is supported on the following line modules:
cOCx FO line module with cOC3/STM1 modules
cOCx FO line module with cOC12/STM4 FO I/O modules
COCx-F3 line modules with CT3/T3 12 I/O modules
OCx/STMx ATM line modules with 4xDS3 ATM I/O modules
CT3/T3-FO line modules with CT3/T3 12 I/O modules
The ERX Module Guide fails to include a Module Name Cross-Reference
Information appendix. See Appendix B, Module Name Cross-Reference
Information, in the 10.3.1 Release Notesfor a single table that lists the module
label name, software display name, and the model number for each module for
ERX routers.
E120 and E320 Module Guide, Appendix A, IOA Protocol Support incorrectly states
that IPv6 multicast is supported on the ES2-S1 Service IOA module. IPv6
multicast is not supported on this module.
The Environmental Requirements and Cabling Recommendations sections in
Appendix B, Installation Guidelines and Requirements, of the E120 and E320
Hardware Guide fail to mention that, based on the optical fiber cables used, you
may need to increase the physical space provided for the chassis. The strain
relief and bend radius requirements of the optical fiber cables may exceed the
specified depth of the chassis and the cable-management bracket.
In JunosE System Basics Configuration Guide, Chapter 4, Configuring SNMP, the
Monitoring Interface Tables section contains a topic whose heading is incorrect.
Although the title of that section is show snmp group, the information described
in it relates to the show snmp interfaces command.
The correct heading for that section is show snmp interfaces. The field
descriptions and usage guidelines for the show snmp group command are
available in a separate section under the Viewing SNMP Status main section of
the same chapter.
The Monitoring Suspicious Control Flow section in JunosE System Basics
Configuration Guide, Chapter 7, Passwords and Security, incorrectly contains a
section titled show snmp interfaces. The discussion in this section is only about
commands to monitor suspicious control flows, while the show snmp interfaces command is used to view SNMP status.
The show snmp interfaces command is described in detail in the Monitoring Interface Tables section in Chapter 4, Configuring SNMP. However, the heading of
the subtopic in that section incorrectly reads show snmp group, while the
description is about the usage of the show snmp interfaces command.
60 Errata
Release 10.3.2
The Configuring VRRP section in JunosE System Basics Configuration Guide,
Chapter 1, Planning Your Network and the Before You Configure IP section in
JunosE IP, IPv6, and IGP Configuration Guide, Chapter 1, Configuring IP
erroneously refer to the JunosE IP Services Configuration Guide. These references
are corrected to refer to the JunosE Service Availability Configuration Guide.
The Detecting Corrupt File Configurations section in JunosE System Basics
Configuration Guide, Chapter 5, Managing the System fails to mention that if you
check the running configuration for corruption manually when auto mode is
enabled, a warning message appears:
host1(config)#service check-config running-configuration
WARNING: This command will cause config monitor to switch into manual mode.
Proceed with current command? [confirm]
If you confirm you want to check the running configuration in manual mode or
ignore the warning message, then manual mode is enabled.
In JunosE IP, IPv6, and IGP Configuration Guide, Chapter 2, Configuring IPv6, the
Before You Configure IPv6 section fails to list all the modules that support IPv6.
You can find complete lists of modules that support IPv6 in the following
appendixes:
E120 and E320 Module Guide, Appendix A, IOA Protocol Support
ERX Module Guide, Appendix A, Module Protocol Support
In the Monitoring IGMP section in JunosE Multicast Routing Configuration Guide,
Chapter 2, Configuring IGMP, the bulleted list of field descriptions and output
example for the show ip igmp interface command incorrectly display the field
name for the number of multicast groups that the interface has discovered as
"Groups learned". The correct label for this field is "Groups learnt".
In the Configuring Graceful Restart section in JunosE IP, IPv6, and IGP
Configuration Guide, Chapter 6, Configuring IS-IS, the default time for the
restarting router to wait for the LSP database to synchronize and to reset the
overload bit is incorrectly mentioned as 30 seconds. The correct value is 100
seconds for both the instances.
In the JunosE Service Availability Configuration Guide for Releases 10.3.0, 11.0.0,
and 11.1.0, the Notes column for the Multicast Routing rows under IPv4
Multicast Routing and under IPv6 Multicast Routing in the Application Support for Stateful SRP Switchover table of Chapter 3, Managing Stateful SRP Switchover,
stated incorrectly that only static recovery is supported. The correct
information is as follows:
Stateful SRP switchover. During switchover, the system mirrors the multicast
queue so that IP can use the same queue without needing to recreate a different
connection. The multicast queues are also preserved during the switchover and
graceful restart period to ensure that multicast data continues to be forwarded
using the previously learned multicast forwarding state.
NOTE: Before JunosE Release 10.3.0, the Application Support for Stateful SRP
Switchover table was located in the JunosE System Basics Configuration Guide.
Errata 61
JunosE 10.3.2 Release Notes
The ICR Overview section in JunosE 10.3.x Service Availability Configuration
Guide, Chapter 6, Managing Interchassis Redundancy, does not accurately
describe how the ICR master partition functions. The following paragraph
accurately describes how the ICR master partition functions:
The subscriber broadcasts a PPPoE Active Discovery Initiation (PADI) packet to
both the master and backup router. Only the master router processes the
packet and creates the subscriber session. When the master router fails, VRRP
switchover occurs and the backup router becomes the new master router.
PPPoE data that now shows up on the new master is dropped because a session
was not created for the subscriber on the new master. Eventually, the PPP
session on the client expires and the client session is re-created with the new
master.
The ICR Overview section in JunosE 10.3.x Service Availability Configuration
Guide, Chapter 6, Managing Interchassis Redundancy, does not accurately define
an ICR partition. The following sentence accurately defines the ICR partition:
An ICR partition is a set of S-VLANs (and CVLANs) associated with a unique
VRRP instance.
The note in the ICR Overview section in JunosE 10.3.x Service Availability
Configuration Guide, Chapter 6, Managing Interchassis Redundancy does not
accurately describe what service providers must do to enable subscriber traffic
to reach all interfaces. The following note accurately describes what to do:
NOTE: While deploying ICR, service providers must ensure that the aggregation
layer between the E Series router and access node (DSLAM) provides a broadcast
domain per VLAN or per S-VLAN between active and backup routers. In the case of
a direct connect model the access node must provide the broadcast domain per
VLAN or per S-VLAN between the active and backup routers or instead provide an
Ethernet switch such as EX Series Ethernet Switch between the access node and E
Series router.
The ICR Scaling Considerations section in JunosE 10.3.x Service Availability
states that ICR supports 1:3 or 1:N subscriber redundancy.
ICR supports 1:1 subscriber redundancy only.
The Example: Configuring ICR Partitions That Group Subscribers by S-VLAN ID
section in JunosE 10.3.x Service Availability Configuration Guide, Chapter 6,
Managing Interchassis Redundancy incorrectly uses the control-subinterface
keyword in Step 4 of the procedures that describe how a master and backup
ICR partition can be configured. The correct keyword is control-interface,
which controls traffic on the range of subinterfaces of the master and backup
partitions. The following example of the command used to control traffic on
subinterface ranges of the master and backup partitions is correct:
In JunosE Service Availability Configuration Guide, Chapter 4, Configuring a
Unified In-Service Software Upgrade, the DHCP Relay Server row in the
Application Support for Unified In-Service Software Upgrades table is
incorrectly marked as unsupported for the unified ISSU operation. DHCP relay
has supported unified ISSU since JunosE Release 9.2.0.
The DHCP Affected Behaviors section in JunosE Service Availability Configuration
Guide, Chapter 4, Configuring a Unified In-Service Software Upgrade, incorrectly
contains the DHCP Relay and DHCP Relay Proxy Prevent Unified ISSU section,
which indicates that the DHCP relay and DHCP relay proxy applications do not
support unified ISSU.
Both the DHCP relay and relay proxy applications began supporting unified
ISSU in JunosE Release 9.2.0. Therefore, you need not unconfigure these
applications from all virtual routers to perform a unified ISSU operation for
JunosE Release 9.2.0 and higher-numbered releases. DHCP relay proxy
continues processing of DHCP release requests during the unified ISSU to
maintain server-client synchronization.
In the Graceful Restarts section in JunosE BGP and MPLS Configuration Guide,
Chapter 1, Configuring BGP Routing, the following corrections and additions
apply to the working of the BGP graceful restart feature:
The bgp graceful-restart and neighbor graceful-restart command sections
incorrectly state that advertisement of the graceful restart capability is
enabled by default. The correct default behavior of these commands is that
BGP graceful restart is disabled, and advertisement of the graceful restart
capability is also disabled, both globally and for specified peers or peer
groups.
The bgp graceful-restart command section incorrectly mentions that you
can use the default keyword to restore the default condition, which causes
the sending of advertisements of the graceful restart capability to be sent.
However, the correct command behavior is that if you use the default
keyword with the bgp graceful-restart command, advertisements of the
graceful restart capability are not sent.
The neighbor graceful-restart command section fails to state that using
the no version of this command disables advertisement of the graceful
restart capability for specified peers or peer groups only. The no form of
this command does not affect global advertisement of the graceful restart
capability.
In the Aggregating Routes section in JunosE BGP and MPLS Configuration Guide,
Chapter 1, Configuring BGP Routing, the references to the router, “Snakes”, in
the description that precedes the “Configuring Aggregate Addresses” figure are
incorrect. The correct references for this router are “SanJose”, which is the label
used for this router in the figure.
Errata 63
JunosE 10.3.2 Release Notes
In the Detecting Peer Reachability with BFD section in JunosE BGP and MPLS
Configuration Guide, Chapter 1, Configuring BGP Routing, the
neighbor-bfd-liveness-detection command subsection incorrectly states the
following:
If you remove the BFD configuration while the BGP sessions and the BFD
protocol session are up, then the BGP session may flap because the remote BGP
speaker cannot detect why the BFD session went down.
The correct behavior of BGP sessions, when you remove the BFD configuration
for the last client tied to a BFD session, is as follows:
If you remove the BFD configuration while the BGP sessions and the BFD
protocol session are up, BFD moves to the Admin Down state and
communicates the change to the peer to enable the client protocols to handle
this transition in a seamless manner without going down. For the Admin Down
state to work, the peer, which receives the Admin Down state notification, must
have the capability to distinguish between administratively down state and real
link down.
NOTE: The BFD Admin Down state is used to bring down a BFD session
administratively, to protect client applications from BFD configuration removal,
license issues, and clearing of BFD sessions.
The Number of CAM Entries Per Allocation and Free Entries section in Chapter 8,
Policy Resources of the JunosE Policy Management Configuration Guide
inadvertently omitted the following paragraph:
The block that is common to the variable-sized entries is not available for
144-bit CAM entries when you configure any 288-bit or 576-bit entries, even
though you remove them later. It is also not available for any 288-bit or 576-bit
entries when the 144-bit entries spill into this block, even though you remove
the 144-bit entries later.
In the JunosE documentation for Release 9.3.x, 10.x.x, and 11.0.x, the
descriptions about support for DSL line rate information retrieval from access
nodes for transmission to the SRC software, and the sscc update-policy-request enable command introduced by this feature are
erroneously omitted. This feature was introduced in JunosE Release 9.3.0.
The information on this functionality and associated command is missing from
the following guides in the JunosE documentation set:
JunosE Broadband Access Configuration Guide—Configuring the SRC Client
section in Chapter 1, Configuring Remote Access, and Monitoring SRC Client
Conection Status section in Chapter 2, Monitoring and Troubleshooting
Remote Access
JunosE Command Reference Guide N to Z
See Appendix C, Transferring DSL Line Rate Information from an Access Node to
SRC Software in the JunosE 10.3.1 Release Notes for detailed information.
64 Errata
The Note in the timeout command section in JunosE Broadband Access
Configuration Guide, Chapter 1, Configuring Remote Access fails to mention that
the router uses the backoff algorithm only for subscriber AAA accounting
messages except Acct-On messages.
In the Creating Multicast VPNs Using Default MDT section in Chapter 3,
Configuring PIM for IPv4 Multicast of the JunosE Multicast Routing Configuration
Guide, the command line configuration examples in Step 8, Step 9, and Step 10
are incorrect. The following steps present the correct information:
Step 8: Configure the IP interface (Tv) in PE2:CE1 as a numbered or
unnumbered PIM sparse-mode interface. Use the same address as the
loopback interface, Lp in the parent router, PE2.
The term "Tunnel-Service Module" used in the JunosE Broadband Access
Configuration Guide and the JunosE Physical Layer Configuration Guide is no
longer valid. Juniper Networks support for the Tunnel Service Module (TSM)
ended on December 31, 2009. The term "Service Module" replaces any
references to the TSM.
Errata 65
JunosE 10.3.2 Release Notes
In the Monitoring MLD section in JunosE Multicast Routing Configuration Guide,
Chapter 6, Configuring Multicast Listener Discovery, the following corrections
apply to the commands used to monitor MLD configuration:
The description of the bgp graceful-restart command in the JunosE Command
Reference A to M incorrectly states that graceful restart is enabled by default. It
also erroneously states that using the default keyword with the bgp
graceful-restart command restores the default condition, wherein graceful
restart is enabled. The correct default behavior of BGP graceful restart is that it
is disabled, which prevents the advertisement of all BGP graceful restart
capabilities. This default behavior has been applicable since the time this
command was introduced.
In addition, the Note in this command section inaccurately states that the E
Series router supports graceful restart only as a receiving peer and not as a
restarting peer. However, E Series routers have supported graceful restart as
restarting peers, in addition to functioning as receiving peers, since JunosE
Release 5.1.0.
In the JunosE Command Reference Guide A to M, the description of the mpls ldp
graceful-restart reconnect-time command incorrectly states that the no
version restores the default value of 120 seconds. The correct default value is
140 seconds.
The description of the neighbor graceful-restart command in the JunosE
Command Reference N to Z incorrectly states that graceful restart is enabled by
default. The correct default behavior is that graceful restart is disabled. This
default behavior has been applicable since the time this command was
introduced in JunosE Release 7.1.0.
The syntax of the show icr-partitions command in the JunosE Command
Reference Guide N to Z incorrectly states the following:
show icr-partitions [ brief ] [ filter ]
The correct syntax for this command is as follows:
backup—Displays the total number of backup ICR partitions configured on
the router
dormant—Displays the total number of dormant ICR partitions configured
on the router
master—Displays the total number of master ICR partitions configured on
summary—Displays a summary of all ICR partitions configured on the
filter—See Filtering show Commands in the Command Reference Guide
66 Errata
the router
router
Release 10.3.2
The tables in the Interface Types and Specifiers section of Chapter 1, Command
Reference Topics, in the JunosE Command Reference Guide erroneously state that
the maximum number of PPPoE subinterfaces per Ethernet (GE/FE) line
module is 4094. The correct number for an ERX router is 8000 and for an E120
or E320 router, it is 16,000.
The JunosE Command Reference Guide N to Z omits the description of the show
memory-management protection command, beginning with JunosE Release
7.1.0 in which it was introduced.
The show memory-management protection command is available in
Privileged Exec mode. You can use this command to display the information
about memory management protection of the router.
The syntax for this command is:
show memory-management protection [detail] [filter]
The command can be used only in the support mode and is not user
configurable.
In the JunosE System Event Logging Reference Guide, for the radiusClient event
category, the Error field incorrectly includes the following errors:
Internal allocation error of base RADIUS server table
Invalid virtual router for user's context
These errors were never implemented in any version of JunosE Software.
Errata 67
JunosE 10.3.2 Release Notes
68 Errata
Appendix A
System Maximums
This appendix presents current system maximums for various E Series hardware
configurations. An E Series router does not simultaneously support all maximum
configurations.
For some entries, early field trial (EFT) values are presented in addition to supported
values. These values have not been fully qualified by Juniper Networks and are
mentioned only for field test purposes in this release. EFT values are enclosed
within parentheses with an EFT designation; for example, (96,000 EFT).
Modules referred to in the tables are identified by their physical label. For module
specifications, including their identifying labels, see ERX Module Guide, Table 1, Module Combinations and E120 and E320 Module Guide, Table 1, Modules and IOAs.
System Maximums for ERX310,
ERX7xx, and ERX14xx
General router valuesGeneral System Maximums on page 70
Physical layer valuesPhysical and Logical Density Maximums on page 71
Link layer valuesLink Layer Maximums on page 74
Routing protocol and performance values Routing Protocol Maximums on page 79
Policy and QoS valuesPolicy and QoS Maximums on page 83
Tunneling valuesTunneling Maximums on page 86
Subscriber management valuesSubscriber Management Maximums on page 88
Section
System Maximums for E120 and E320
Routers
General router valuesGeneral System Maximums on page 91
Physical layer valuesPhysical and Logical Density Maximums on page 92
Link layer valuesLink Layer Maximums on page 94
Routing protocol and performance values Routing Protocol Maximums on page 100
Policy and QoS valuesPolicy and QoS Maximums on page 103
Tunneling valuesTunneling Maximums on page 107
Subscriber management valuesSubscriber Management Maximums on page 109
Section
69
JunosE 10.3.2 Release Notes
ERX310, ERX7xx, and ERX14xx System Maximums
The following tables provide system maximums for the ERX310, ERX7xx, and
ERX14xx routers.
General System Maximums
Table 1 lists some general system maximums for the ERX routers.
Table 1: General System Maximums
ERX705 and
FeatureERX310
Fabric size10 Gbps5 or 10 Gbps10 Gbps40 Gbps
Chassis per 7-foot rack14633
NTP clients1000100010001000
NTP servers300300300300
Sessions per chassis (simultaneous Telnet + FTP +
SSH, in any combination)
Virtual routers per chassis1000100010001000
Virtual routers per line module ASIC 1000100010001000
ICR Partitions per chassis640640640640
ICR Partitions per line module64646464
30303030
ERX710
ERX1410ERX1440
70 ERX310, ERX7xx, and ERX14xx System Maximums
Physical and Logical Density Maximums
Table 2 lists physical and logical density maximums for the ERX routers. The
following notes are referred to in Table 2:
1. Wire rate indicates the port density that supports maximum (wire-rate)
performance. Oversubscribed indicates the port density possible when you are
willing to accept less than wire-rate performance by oversubscribing the
available fabric bandwidth. The ERX310 and ERX1440 routers do not support
oversubscription; port densities for these models indicate wire-rate
performance.
2. When you pair the GE-2 or GE-HDE line module with the GE-2 SFP I/O module
on the ERX1440 router, you can terminate up to 24 Gigabit Ethernet interfaces.
Slots 2 and 4 on the ERX1440 router support two Gigabit Ethernet interfaces at
wire rate; the remaining 10 slots support one Gigabit Ethernet interface at wire
rate. On the ERX310 router, all four ports (active and redundant) are at wire
rate.
Appendix A: System Maximums
For more information about bandwidth and line-rate considerations for the
GE-2 line module or the GE-HDE line module and their corresponding I/O
modules on E Series routers, see JunosE Physical Layer Configuration Guide, Chapter 5, Configuring Ethernet Interfaces.
3. When you pair the GE-HDE line module with the GE-8 I/O module on the
ERX1440 router, you can terminate up to 96 Gigabit Ethernet interfaces. Slots 2
and 4 on the ERX1440 router support two Gigabit Ethernet interfaces at wire
rate; the remaining 10 slots support one Gigabit Ethernet interface at wire rate.
On the ERX310 router, only two Gigabit Ethernet interfaces per slot are at wire
rate; therefore, only four Gigabit Ethernet interfaces are at wire rate for the
entire router.
For more information about bandwidth and line-rate considerations for the
GE-HDE line module and the GE-8 I/O module on E Series routers, see JunosE Physical Layer Configuration Guide, Chapter 5, Configuring Ethernet Interfaces.
4. The OC3/STM-1 GE/FE line module and OC3-2 GE APS I/O module combination
does not support line rate for Gigabit Ethernet interfaces.
Table 2: Physical and Logical Density Maximums
FeatureERX310
Physical density wire rate/oversubscribed
(See Note 1 on page 71.)
Channelized OC3 ports per chassis
(cOC3 STM1 FO I/O modules)
Channelized OC12 ports per chassis
(cOC12 STM4 FO I/O modules)
Channelized T3 ports per chassis
(CT3/T3 12 I/O modules)
E3 (unchannelized) ports per chassis
(CT3/T3 12 I/O modules)
816/2032/4848
24/54/1212
2448/6096/144144
2448/6096/144144
ERX705 and
ERX710
ERX1410ERX1440
ERX310, ERX7xx, and ERX14xx System Maximums 71
JunosE 10.3.2 Release Notes
Table 2: Physical and Logical Density Maximums (continued)
FeatureERX310
Fast Ethernet (10/100) ports per chassis
(FE-8 I/O and FE-8 SFP I/O modules)
Gigabit Ethernet ports per chassis
(GE I/O modules)
Gigabit Ethernet ports per chassis
(GE-2 SFP I/O modules)
(See Note 2 on page 71.)
Gigabit Ethernet ports per chassis
(GE-8 I/O modules)
(See Note 3 on page 71.)
Gigabit Ethernet ports per chassis
(OC3-2 GE APS I/O module)
(See Note 4 on page 71.)
OC3/STM-1 ATM ports per chassis
(OC3-4 I/O modules)
OC3/STM-1 ATM ports per chassis
(OC3-2 GE APS I/O module)
OC3/STM-1 POS ports per chassis
(OC3-4 I/O modules)
OC12/STM-4 ATM ports per chassis
(OC12 STM4 I/O modules)
OC12/STM-4 POS ports per chassis
(OC12 STM4 I/O modules)
OC48/STM16 POS ports per chassis
(OC48 FRAME I/O modules); ERX1440 router only
T3 (unchannelized) ports per chassis
(4xDS3 ATM I/O modules)
T3 (unchannelized) ports per chassis
(CT3/T3 12 I/O modules)
ERX705 and
ERX710ERX1410ERX1440
1632/4032/9696
24/54/1212
4––14/24
4/16––14/96
24/54/1212
816/2032/4848
410 24 24
816/2016/4848
24/58/1212
24/54/1212
–––2
816/2032/4848
2448/6096/144144
Logical density per chassis
Logical E1s per chassis504126030243024
Logical E3s per chassis2460144144
Logical fractional E1s (DS0) per chassis 400010,00024,00024,000
Logical fractional T1s (DS0) per chassis 400010,00024,00024,000
Logical OC3/STM1 per chassis8204848
Logical OC12/STM4 per chassis251212
Logical OC48/STM16 per chassis
(ERX1440 router only)
Logical T1s per chassis672168040324032
Logical T3s per chassis2460144144
72 ERX310, ERX7xx, and ERX14xx System Maximums
–––2
Appendix A: System Maximums
Table 2: Physical and Logical Density Maximums (continued)
ERX705 and
FeatureERX310
Logical density per module combination
(specified line module and all supported I/O modules)
Logical E1s per cOCx/STMx F0 line module252
63 per
OC3/STM1
Logical E3s per COCX-F3 line module12121212
Logical fractional E1s (DS0) per cOCx/STMx F0 line
module
Logical fractional T1s (DS0) per cOCx/STMx F0 line
module
Logical fractional T1s (DS0) per CT3/T3-F0 line module1992
Logical fractional T3s (DS3) per COCX-F3 line module12121212
Logical T1s per cOCx/STMx F0 line module336
Logical T1s per CT3/T3-F0 line module336
Logical T3s per COCX-F3 line module12121212
Logical T3s per cOCx/STMx F0 line module12
Logical T3s per CT3/T3-F012121212
Logical T3s per OCx/STMx/DS3-ATM line module with
4xDS3 ATM I/O module
2000
500 per
OC3/STM1
2000
500 per
OC3/STM1
166 per T3
84 per
OC3/STM1
28 per T3
3 per
OC3/STM1
4444
ERX710ERX1410ERX1440
252
63 per
OC3/STM1
2000
500 per
OC3/STM1
2000
500 per
OC3/STM1
1992
166 per T3
336
84 per
OC3/STM1
336
28 per T3
12
3 per
OC3/STM1
252
63 per
OC3/STM1
2000
500 per
OC3/STM1
2000
500 per
OC3/STM1
1992
166 per T3
336
84 per
OC3/STM1
336
28 per T3
12
3 per
OC3/STM1
252
63 per
OC3/STM1
2000
500 per
OC3/STM1
2000
500 per
OC3/STM1
1992
166 per T3
336
84 per
OC3/STM1
336
28 per T3
12
3 per
OC3/STM1
ERX310, ERX7xx, and ERX14xx System Maximums 73
JunosE 10.3.2 Release Notes
Link Layer Maximums
Table 3 lists link layer maximums for the ERX routers. The following notes are
referred to in Table 3:
1. The ERX1440 router supports a maximum of 48,000 interface columns of all
types combined. You can use either all dynamic interfaces or a combination of
dynamic and static interfaces to achieve this maximum. For bridged Ethernet,
IP network, and PPP interfaces, the ERX1440 router supports a maximum of
32,000 static major interfaces. Although the ERX1440 router supports a
maximum of 48,000 static major interfaces for PPPoE, the PPPoE static limit is
enforced at the subinterface level, which has a limit of 32,000.
The ERX705, ERX710, and ERX1410 routers support a maximum of 32,000
interfaces of all types combined; the ERX310 router supports a maximum of
16,000 interfaces of all types combined. For these routers, the interfaces can
be any combination of dynamic or static.
The JunosE Software supports up to 10,000 PPP interfaces with EAP
authentication negotiation configured. Performance and scalability is
unchanged when EAP is not configured.
2. The total maximum number of Ethernet subinterfaces that can be active at any
one time on an ERX310 router, an ERX7xx router, or an ERX14xx router is
limited by the number of slots per chassis. Of this total, you can configure all
single-tagged VLAN subinterfaces, all double-tagged S-VLAN subinterfaces, or a
combination of both VLAN subinterfaces and S-VLAN subinterfaces to achieve
this maximum.
Table 3: Link Layer Maximums
ERX705 and
FeatureERX310
ARP entries per line module
Dynamic ARP entries32,76832,76832,76832,768
Static ARP entries32,76832,76832,76832,768
Total ARP entries32,76832,76832,76832,768
ATM bulk configuration VC ranges per chassis300300300300
ATM bulk configuration VC ranges per line module300300300300
ERX710ERX1410ERX1440
ATM bulk configuration total VCs per chassis64,000160,000384,000384,000
ATM bulk configuration total VCs per line module
OCx/STMx/DS3-ATM 32,00032,00032,00032,000
OC3/STM1 GE/FE32,00032,00032,00032,000
74 ERX310, ERX7xx, and ERX14xx System Maximums
Appendix A: System Maximums
Table 3: Link Layer Maximums (continued)
ERX705 and
FeatureERX310
ATM bulk configuration overriding profile assignments
per chassis
ATM VCs per chassis (active/configured)16,000/32,000 32,000/64,000 32,000/64,000 48,000/96,000
ATM VP tunnels per port, all supported modules256256256256
Bridged Ethernet interfaces per chassis
(See Note 1 on page 74.)
Bridged Ethernet interfaces per line module
OCx/STMx/DS3-ATM8192819281928192
OC3/STM-1 GE/FE8192819281928192
Dynamic interfaces
Active autosensed dynamic interface columns per
chassis over static or dynamic (bulk) ATM1483
subinterfaces
16,00032,00032,00048,000
16,00032,00032,00048,000
Ethernet 802.3ad Link Aggregation
Links per LAG (bundle)8888
LAGs (bundles) per chassis64646464
Ethernet S-VLANs per chassis
(See Note 2 on page 74.)
32,76881,92096,00096,000
ERX310, ERX7xx, and ERX14xx System Maximums 75
JunosE 10.3.2 Release Notes
Table 3: Link Layer Maximums (continued)
ERX705 and
FeatureERX310
Ethernet S-VLANs per I/O module
FE-8 I/O and FE-8 SFP I/O16,38416,38416,38416,384
GE I/O16,38416,38416,38416,384
GE-2 SFP I/O16,384––16,384
GE-8 I/O16,384––16,384
OC3-2 GE APS I/O16,38416,38416,38416,384
ERX710ERX1410ERX1440
Ethernet VLANs per chassis
(See Note 2 on page 74.)
Ethernet VLANs per I/O module (no more than 4096 VLANs per por t)
FE-8 I/O and FE-8 SFP I/O8192819281928192
GE I/O4096409640964096
GE-2 SFP I/O8192––8192
GE-8 I/O16,384––16,384
OC3-2 GE APS I/O4096409640964096
Ethernet VLAN bulk configuration VLAN ranges per
chassis
Ethernet VLAN bulk configuration VLAN ranges per
line module
Ethernet VLAN overriding profile assignments per
chassis
Ethernet VRRP VRIDs per line module ASIC800800800800
32,76881,92096,00096,000
300300300300
300300300300
200200200200
Frame Relay virtual circuits per chassis2000500012,00012,000
Frame Relay virtual circuits per line module
COCX-F31000100010001000
cOCx/STMx F01000100010001000
OC48 (ERX1440 router only)–––1000
Frame Relay virtual circuits per port
COCX-F31000100010001000
cOCx/STMx F01000100010001000
OC48 (ERX1440 router only)–––1000
76 ERX310, ERX7xx, and ERX14xx System Maximums
Appendix A: System Maximums
Table 3: Link Layer Maximums (continued)
ERX705 and
FeatureERX310
HDLC interfaces per chassis400010,00024,00024,000
HDLC interfaces per line module
COCX-F312121212
cOCx/STMx F02000200020002000
CT3/T3 F01992199219921992
OCx/STMx/DS-3 ATM8000800080008000
OCx/STMx POS4444
OC48 (ERX1440 router only)–––1
ERX710ERX1410ERX1440
MLFR bundles per chassis5000500050005000
MLFR bundles per line moduleBundles per line module are limited only by the
availability of interface columns on the module.
Because a bundle requires at least one interface
column, the number of bundles cannot exceed the
number of interface columns.
MLPPP bundles per chassis12,00012,00012,00012,000
MLPPP bundles per line moduleThe maximum number of MLPPP bundles supported per line
module is the lesser of the maximum number of MLPPP bundles
supported per chassis or of the maximum number of interfaces
supported on the line module. For more information, see the JunosE Link Layer Configuration Guide.
PPP interfaces per chassis
(See Note 1 on page 74.)
PPP interfaces per line module
COCX-F312121212
cOCx/STMx FO2000200020002000
GE/FE8000800080008000
GE-28000––8000
GE-HDE8000––8000
OCx/STMx/DS-3 ATM8000800080008000
OC3/STM-1 GE/FE8000800080008000
OCx/STMx POS4444
OC48 (ERX1440 router only)–––1
16,00032,00032,00048,000
ERX310, ERX7xx, and ERX14xx System Maximums 77
JunosE 10.3.2 Release Notes
Table 3: Link Layer Maximums (continued)
ERX705 and
FeatureERX310
PPP packet logging
Aggregate dynamic and static PPP interfaces for which
you can log PPP packets per chassis
PPPoE service name tables
PPPoE service name tables per chassis16161616
Service name tags per PPPoE service name table
(including one empty service name tag)
PPPoE subinterfaces
Subinterfaces per chassis
(See Note 1 on page 74.)
Subinterfaces per GE/FE line module8000800080008000
Subinterfaces per GE-2 line module8000––8000
Subinterfaces per GE-HDE line module8000––8000
Subinterfaces per OCx/STMx/DS-3 ATM line module8000800080008000
Subinterfaces per OC3/STM-1 GE/FE line module8000800080008000
32323232
17171717
16,00032,00032,00048,000
ERX710ERX1410ERX1440
Transparent bridging and VPLS
Bridge groups or VPLS instances per chassis1024102410241024
Bridge interfaces per line module in bridge groups or
VPLS instances
Bridge interfaces per chassis in bridge groups or
VPLS instances
Learned MAC address entries combined for all bridge
groups and VPLS instances on a chassis
8000800080008000
16,00032,00032,00032,000
64,00064,00064,00064,000
78 ERX310, ERX7xx, and ERX14xx System Maximums
Routing Protocol Maximums
Table 4 lists routing protocol maximums for the ERX routers. The following notes
are referred to in Table 4:
1. The total set of FTEs can be shared by interfaces, next hops, ECMP sets, VRs,
and VRFs. Next-hop FTEs identify the next hop on multiaccess media, such as
ATM multipoint, Ethernet, or bridged Ethernet. Each VR or VRF consumes
three entries. Each interface, next hop, and ECMP set consumes a single entry.
One FTE is reserved for internal use, and the system software limits the
number of FTEs used by interfaces to a maximum of 32,000. The remaining
FTEs can be shared across the other types.
2. The ERX1440 router supports a maximum of 48,000 interfaces of all types
combined. You can use either all dynamic interfaces or a combination of
dynamic and static interfaces to achieve this maximum. The ERX1440 router
supports a maximum of 32,000 static PPP/PPPoE interfaces and a maximum of
36,500 static IP network interfaces. Bridged Ethernet does not enforce a limit
so IP interfaces created on Bridged Ethernet can scale to the IP maximum of
36,500.
Appendix A: System Maximums
The ERX705, ERX710, and ERX1410 routers support a maximum of 32,000 IP
network interfaces; the ERX310 router supports a maximum of 16,000 IP
network interfaces. For all these models, the interfaces can be any combination
of dynamic or static.
3. These values are subject to limitations on available SRP module memory,
which varies according to your router configuration.
4. Depending on your configuration, the router may support more routing table
entries or fewer routing table entries than this value. In any case, you can
choose to limit the number of routes that can be added to the routing table on a
per-VR or per-VRF basis by means of the maximum routes command.
5. The maximum number of ANCP adjacencies can be scaled over a maximum of
100 virtual routers. Fewer ANCP adjacencies can be scaled in configurations
with more than 100 virtual routers.
6. This maximum is not valid for Frame Relay. The Frame Relay maximum is
1000 circuits over MPLS per line module, because only 1000 Frame Relay
DLCIs are permitted per line module.
7. On the ERX1440 router, you can achieve 32,767 total Martini circuits over ATM
or Ethernet interfaces. For all routers, the total Martini can be any combination
of external inter-router circuits and internal circuits (local cross-connects).
8. There is no per-VR limit; all multicast routes can be on a single VR or present
across multiple VRs.
9. The maximum number of interfaces can be achieved by any combination; for
example, two streams each being replicated to 32,768 interfaces; 16,384
streams each being replicated four times; or any other combination.
ERX310, ERX7xx, and ERX14xx System Maximums 79
JunosE 10.3.2 Release Notes
10. Dynamic values represent typical limits that vary depending on configuration
details and actual dynamic behavior. For dynamic values only, multiple server
modules (SMs) in a chassis can improve the values as long as the multiple
server modules are online and the number of virtual routers configured with
NAT is greater than or equal to the number of server modules. If a server
module fails, the load is redistributed to the remaining server modules, with a
consequent reduction in aggregate capacity.
11. Static and dynamic translations occupy the same table; therefore, the number
of static translation entries present in the table reduces the room for dynamic
entries.
Table 4: Routing Protocol Maximums
ERX705 and
FeatureERX310
BFD
Sessions per line module50505050
ERX710ERX1410ERX1440
ECMP maximum paths to a destination
BGP, IS-IS, MPLS, OSPF, RIP16161616
IPv4 forwarding table entries
(See Note 1 on page 79.)
Chassis with only ASIC modules1,048,5761,048,5761,048,5761,048,576
IP network interfaces (IPv4 and IPv6)
Per chassis
(See Note 2 on page 79.)
Per line module ASIC 8000800080008000
IPv4 routing protocol scaling and peering densities
IP next hops (egress FECs) on router with ASIC modules
(used to represent the IP addresses of next-hop routers
on Ethernet interfaces)
MPLS next hops (egress FECs) on router with ASIC
modules only
MPLS forwarding entries 64,00064,00064,00064,000
16,00032,00032,00048,000
500,000500,000500,000500,000
5000500050005000
1,000,0001,000,0001,000,0001,000,000
500,000500,000500,000500,000
80 ERX310, ERX7xx, and ERX14xx System Maximums
Appendix A: System Maximums
Table 4: Routing Protocol Maximums (continued)
ERX705 and
FeatureERX310
IS-IS adjacencies150150150150
IS-IS routes20,00020,00020,00020,000
MPLS LDP LSPs10,00010,00010,00010,000
MPLS RSVP-TE LSPs10,00010,00010,00010,000
OSPF adjacencies1000100010001000
OSPF routes25,00025,00025,00025,000
ERX710ERX1410ERX1440
IPv6 routing table entries
(See Note 3 on page 79.)
J-Flow statistics
J-Flow–enabled VRs and VRFs, in any combination16161616
Sampled interfaces per VR or VRF32323232
Total sampled Interfaces per chassis512512512512
Martini circuits for layer 2 services over MPLS
Total Martini circuits per line module
(See Note 6 on page 79.)
Total Martini circuits per chassis
(See Note 7 on page 79.)
External Martini circuits per chassis16,00016,00016,00032,767
Internal Martini circuits (local cross-connects) per chassis 16,00016,00016,00032,767
Mobile IP bindings per chassis –––48,000
Multicast routes (IPv4 and IPv6)
Forwarding entries [(S,G) pairs] per chassis
(See Note 8 on page 79.)
Outgoing interfaces per chassis
(See Note 9 on page 79.)
50,00050,00050,00050,000
8000800080008000
16,00016,00016,00032,767
16,38416,38416,38416,384
65,53665,53665,53665,536
Network Address Translation (NAT)
Static translations (simple or extended) per chassis96,00096,00096,00096,000
Dynamic simple translations (NAT) per SM
(See Notes 10 and 11 on page 80.)
Dynamic extended translations (NAPT) per SM
(See Notes 10 and 11 on page 80.)
400,000400,000400,000400,000
200,000200,000200,000200,000
ERX310, ERX7xx, and ERX14xx System Maximums 81
JunosE 10.3.2 Release Notes
Table 4: Routing Protocol Maximums (continued)
ERX705 and
FeatureERX310
Response Time Reporter simultaneous operations
per VR
VRRP VRIDs per line module ASICSee Ethernet VRRP VRIDs per line module ASIC on page 76.
500500500500
ERX710ERX1410ERX1440
82 ERX310, ERX7xx, and ERX14xx System Maximums
Policy and QoS Maximums
Table 5 lists policy and QoS maximums for the ERX routers. The following notes
are referred to in Table 5:
1. The OC48 line module supports only 131,071 entries. The GE-2 and GE-HDE
line modules support only 65,535 entries.
2. For line modules other than the GE-2, GE-HDE, and OC48/STM16 line modules,
the router supports two sizes of policies: 8127 policies, each with a maximum
of 32 classifiers, and 16,255 policies, each with a maximum of 16 classifiers. A
combination of the two sizes of policies is also supported, in which case the
total number of policies is between 8127 and 16,255, depending on the actual
configuration.
3. The GE-2, GE-HDE, and OC48/STM16 line modules support CAM classifiers
instead of hardware policy assignments. For most configurations, each
classifier entry in a policy consumes one CAM entry. However, a policy that has
only the default classifier consumes no CAM resources. Policies that use CAM
hardware classifiers consume one interface attachment resource, regardless of
the number of classifier entries in a policy.
Appendix A: System Maximums
Table 5: Policy and QoS Maximums
ERX705 and
FeatureERX310
QoS queues per ASIC line module49,00049,00049,00049,000
QoS profiles configurable per chassis1000100010001000
QoS profile attachments per chassis96,00096,00096,00096,000
QoS profile attachments per ASIC line module16,00016,00016,00016,000
QoS shapers per line module64,00064,00064,00064,000
Classification rules per policy512512512512
Policy classification (CLACL) entries per line module
(See Note 1 on page 83.)
Unique hardware policy assignments per line module
for modules other than the GE-2, GE-HDE, and
OC48/STM16
(See Note 2 on page 83.)
256,000256,000256,000256,000
8127/16,2558127/16,2558127/16,2558127/16,255
ERX710ERX1410ERX1440
ERX310, ERX7xx, and ERX14xx System Maximums 83
JunosE 10.3.2 Release Notes
Table 5: Policy and QoS Maximums (continued)
ERX705 and
FeatureERX310
CAM entries
(See Note 3 on page 83.)
GE-264,000––64,000
GE-HDE64,000––64,000
OC48/STM16–––128,000
Policy egress interface attachments
per ASIC line module
Combined IP and IPv6 interface attachments8191819181918191
Egress per ASIC line module24,57524,57524,57524,575
Ingress per ASIC line module24,57524,57524,57524,575
Policy statistics blocks
Egress per ASIC line module256,000256,000256,000256,000
Ingress per ASIC line module256,000256,000256,000256,000
Parent groups per ASIC line module
GE-2, GE-HDE, and OC3/OC12 ATM line modules
(Egress and Ingress)
All other ASIC line modules (Egress and Ingress)8191819181918191
16,383––16,383
16,00016,00016,00016,000
8191819181918191
24,57524,57524,57524,575
Software lookup blocks
Per ASIC line module16,38316,38316,38316,383
84 ERX310, ERX7xx, and ERX14xx System Maximums
Appendix A: System Maximums
Table 5: Policy and QoS Maximums (continued)
ERX705 and
FeatureERX310
Secure policies (for packet mirroring)
Per ASIC line module1022102210221022
Per chassis2400240024002400
ERX710ERX1410ERX1440
ERX310, ERX7xx, and ERX14xx System Maximums 85
JunosE 10.3.2 Release Notes
Tunneling Maximums
Table 6: Tunneling Maximums
Table 6 lists tunneling maximums for the ERX routers. The following notes are
referred to in Table 6:
1. The SM supports any combination of DVMRP, GRE, and L2TP tunnels up to a
maximum of 8000 tunnels; however, no more than 4000 tunnels can be
DVMRP or GRE tunnels in any combination. The ISM supports any combination
of DVMRP, GRE, and L2TP tunnels over IPSec, up to a maximum of 5000
tunnels; however, no more than 4000 tunnels can be DVMRP or GRE tunnels.
2. You can have no more than 8000 L2TP/IPSec sessions per chassis.
3. For more information about supported L2TP sessions and tunnels, see JunosE Broadband Access Configuration Guide, Chapter 11, L2TP Overview.
ERX705 and
FeatureERX310
DVMRP (IP-in-IP) tunnels per chassis4000400040004000
DVMRP (IP-in-IP) tunnels per line module
(See Note 1 on page 86.)
GE-2 with shared tunnel-server ports provisioned4000––4000
GE-HDE with shared tunnel-server ports provisioned4000––4000
IPSec Service Module (DVMRP/IPSec tunnels)4000400040004000
Service Module (SM)4000400040004000
GRE tunnels per chassis4000400040004000
GRE tunnels per line module
(See Note 1 on page 86.)
GE-2 with shared tunnel-server ports provisioned4000––4000
GE-HDE with shared tunnel-server ports provisioned4000––4000
IPSec Service Module (GRE/IPSec tunnels)4000400040004000
Service Module (SM)4000400040004000
ERX710ERX1410ERX1440
IPSec manual secure tunnels per chassis256256256256
IPSec transform sets per chassis1000100010001000
IPSec transforms per transform set6666
IPSec tunnels per chassis10,00010,00010,00020,000
86 ERX310, ERX7xx, and ERX14xx System Maximums
Appendix A: System Maximums
Table 6: Tunneling Maximums (continued)
ERX705 and
FeatureERX310
IPSec tunnels per IPSec Ser vice Module5000500050005000
ERX710ERX1410ERX1440
L2TP sessions per chassis
(See Notes 2 and 3 on page 86.)
L2TP sessions per line module
(See Notes 1 and 3 on page 86.)
GE-2 with shared tunnel-server ports provisioned8000––8000
GE-HDE with shared tunnel-server ports provisioned8000––8000
IPSec Service Module (ISM; L2TP/IPSec sessions)5000500050005000
Service Module (SM)16,00016,00016,00016,000
L2TP tunnels per chassis8000800080008000
L2TP tunnels per line module
(See Notes 1 and 3 on page 86.)
GE-2 with shared tunnel-server ports provisioned8000––8000
GE-HDE with shared tunnel-server ports provisioned8000––8000
IPSec Service Module (L2TP/IPSec tunnels)5000500050005000
Service Module8000800080008000
16,00016,00016,00032,000
ERX310, ERX7xx, and ERX14xx System Maximums 87
JunosE 10.3.2 Release Notes
Subscriber Management Maximums
Table 7 lists subscriber management maximums for the ERX routers. The following
notes are referred to in Table 7:
1. DHCP relay proxy maintains a list of active DHCP clients up to a maximum of
100,000 clients per chassis for all virtual routers. DHCP relay does not maintain
a list of DHCP clients.
DHCP relay proxy is notified of DHCP client deletions and subsequently deletes
the client’s host routes. In contrast, DHCP relay is not notified of DHCP client
deletions, so the host routes for deleted clients remain in DHCP relay until you
permanently delete them with the set dhcp relay discard-access-routes
command. A maximum of 100,000 host routes for DHCP clients can be stored
for all DHCP relay and DHCP relay proxy instances (that is, for all virtual
routers).
2. The ERX1440 router supports a maximum of 48,000 interface columns of all
types combined. You can use either all dynamic interfaces or a combination of
dynamic and static interfaces to achieve this maximum. For bridged Ethernet,
IP network, and PPP interfaces, the ERX1440 router supports a maximum of
32,000 static major interfaces. Although the ERX1440 router supports a
maximum of 48,000 static major interfaces for PPPoE, the PPPoE static limit is
enforced at the subinterface level, which has a limit of 32,000.
The ERX705, ERX710, and ERX1410 routers support a maximum of 32,000
interfaces of all types combined; the ERX310 router supports a maximum of
16,000 interfaces of all types combined. For these routers, the interfaces can
be any combination of dynamic or static.
The JunosE Software supports up to 10,000 PPP interfaces with EAP
authentication negotiation configured. Performance and scalability is
unchanged when EAP is not configured.
3. For DHCPv6 local server, up to 32,000 subscribers and clients are supported on
PPP/ATM and PPPoE/ATM with dynamic interfaces. Interface flapping tests
have been qualified for 8000 subscribers and interfaces.
Table 7: Subscriber Management Maximums
ERX705 and
FeatureERX310
DHCP external ser ver clients (per chassis for all
virtual routers; and per virtual router)
(See Note 1 on page 88.)
DHCP local server
(See Note 2 on page 88.)
Client bindings per chassis96,00096,00096,00096,000
Client interfaces per chassis16,00032,00032,00048,000
Local address pools per virtual router 4000400040004000
IP addresses per local address pool32,00032,00032,00032,000
Dynamic subscriber interfaces per chassis16,00032,00032,00048,000
Dynamic subscriber interfaces per line module8000800080008000
Static subscriber interfaces per chassis16,00032,00032,00048,000
Static subscriber interfaces per line module8000800080008000
ERX710ERX1410ERX1440
90 ERX310, ERX7xx, and ERX14xx System Maximums
E120 and E320 System Maximums
The following tables provide system maximums for the E120 router and the E320
router.
General System Maximums
Table 8 lists some general system maximums for the E120 router and the E320
router. The following notes are referred to in Table 8:
1. The maximum number applies to any combination of VRs and VRFs. The
number of VRs and VRFs that you can configure depends on your
configuration. You cannot achieve the maximum number if each VR and VRF
instance is running a routing protocol.
2. The maximum of 3000 VRs and VRFs can be achieved only with the SRP-120
and SRP-320 modules, which have 4 GB of memory. The limits cannot be
achieved with the SRP-100 module, which has 2 GB of memory.
Appendix A: System Maximums
Table 8: General System Maximums
FeatureE120E320
Fabric size120 Gbps100 Gbps/320 Gbps
Chassis per 7-foot rack63
NTP clients10001000
NTP servers300300
Sessions per chassis (simultaneous Telnet + FTP +
SSH, in any combination)
Virtual routers and VRFs per chassis, combined
(See Notes 1 and 2 on page 91.)
Virtual routers and VRFs per line module, combined
(See Notes 1 and 2 on page 91.)
ICR Partitions per chassis640640
ICR Partitions per line module6464
3030
30003000
30003000
E120 and E320 System Maximums 91
JunosE 10.3.2 Release Notes
Physical and Logical Density Maximums
Table 9 lists physical and logical density maximums for the E120 router and the
E320 router. The following notes are referred to in Table 9:
1. Wire rate indicates the port density that supports maximum (wire-rate)
performance. Oversubscribed indicates the port density possible if you are
willing to accept less than wire-rate performance by oversubscribing the
available fabric bandwidth.
2. With a 120 Gbps configuration on the E120 router, you can install up to 6
combinations of ES2 10G Uplink LMs, ES2 10G LMs, or ES2 10G ADV LMs in
slots numbered 0-5. You can install a maximum of 6 active ports and 6
redundant ports at any time.
With a 100 Gbps fabric configuration on the E320 router, you must install the
ES2 10G Uplink LM, the ES2 10G LM, or the ES2 10G ADV LM in either of the
E320 router turbo slots (2 and 4). When the ES2 10G Uplink LM, the ES2 10G
LM, or the ES2 10G ADV LM is installed in slot 2 or slot 4, you cannot install
another line module in slot 3 or slot 5. In this case, you can only install the ES2
4G LM in slots 0–1 and 6–11; therefore, the maximum number of ports and the
forwarding performance per chassis is reduced for the IOAs that pair with the
ES2 4G LM.
With a 320 Gbps fabric configuration on the E320 router, you can install up to
12 combinations of ES2 10G Uplink LMs, ES2 10G LMs, or ES2 10G ADV LMs in
slots numbered 0-5 and 11-16. You can install a maximum of 12 active ports
and 12 redundant ports at any time.
Table 9: Physical and Logical Density Maximums
FeatureE120E320
Physical density wire rate/oversubscribed
(See Note 1 on page 92.)
10-Gigabit Ethernet ports per chassis
(ES2-S1 10GE IOA)
10-Gigabit Ethernet ports per chassis
(ES2-S2 10GE PR IOA)
(See Note 2 on page 92.)
Gigabit Ethernet ports per chassis
(ES2-S1 GE-4 IOAs)
Gigabit Ethernet ports per chassis
(ES2-S1 GE-8 IOAs)
(See Note 2 on page 92.)
Gigabit Ethernet ports per chassis
(ES2-S3 GE-20 IOA)
(See Note 2 on page 92.)
OC3/STM-1 ATM ports per chassis
(ES2-S1 OC3-8 STM1 ATM IOAs)
OC12/STM-4 ATM ports per chassis
(ES2-S1 OC12-2 STM4 ATM IOAs)
612
6 + 612 + 12
2448
96192
120240
96 192
24 48
92 E120 and E320 System Maximums
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.