Release Notes

Transcription

Release Notes

®
®
Juniper Networks JUNOS 10.1 Software
Release Notes
Release 10.1R4
17 November 2010
Revision 5
These release notes accompany Release 10.1R4 of the JUNOS Software. They describe
device documentation and known problems with the software. JUNOS Software runs
on all Juniper Networks M Series, MX Series, and T Series routing platforms, SRX
Series Services Gateways, J Series Services Routers, and EX Series Ethernet Switches.
You can also find these release notes on the Juniper Networks JUNOS Software
Documentation Web page, which is located at
http://www.juniper.net/techpubs/software/junos.
Contents
JUNOS Software Release Notes for Juniper Networks M Series Multiservice
Edge Routers, MX Series Ethernet Service Routers, and T Series Core
Routers .....................................................................................................6
New Features in JUNOS Release 10.1 for M Series, MX Series, and T
Series Routers ....................................................................................6
Class of Service ..................................................................................6
High Availability ...............................................................................12
Interfaces and Chassis ......................................................................12
JUNOS XML API and Scripting ..........................................................18
MPLS Applications ............................................................................21
Multiplay ..........................................................................................22
Routing Policy and Firewall Filters ....................................................23
Routing Protocols .............................................................................24
Services Applications ........................................................................27
Subscriber Access Management .......................................................27
System Logging ................................................................................36
■
1
JUNOS 10.1 Software Release Notes
User Interface and Configuration ......................................................38
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M
Series, MX Series, and T Series Routers ............................................42
Class of Service ................................................................................42
Forwarding and Sampling ................................................................42
Interfaces and Chassis ......................................................................42
Layer 2 Ethernet Services .................................................................46
MPLS Applications ............................................................................46
Multiplay ..........................................................................................47
Platform and Infrastructure ..............................................................47
Routing Policy and Firewall Filters ....................................................47
Routing Protocols .............................................................................48
Services Applications ........................................................................48
Subscriber Access Management .......................................................51
User Interface and Configuration ......................................................52
VPNs ................................................................................................52
Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series
Routers .............................................................................................55
Current Software Release .................................................................55
Previous Releases .............................................................................79
Errata and Changes in Documentation for JUNOS Software Release 10.1
for M Series, MX Series, and T Series Routers ................................107
Changes to the JUNOS Documentation Set .....................................107
Errata .............................................................................................108
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M
Series, MX Series, and T Series Routers ..........................................113
Basic Procedure for Upgrading to Release 10.1 ..............................113
Upgrading a Router with Redundant Routing Engines ....................116
Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to
JUNOS Release 10.1 .................................................................116
Upgrading the Software for a Routing Matrix .................................118
Upgrading Using ISSU .....................................................................119
Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled
for Both PIM and NSR ..............................................................119
Downgrade from Release 10.1 .......................................................120
JUNOS Software Release Notes for Juniper Networks SRX Series Services
Gateways and J Series Services Routers ................................................122
New Features in JUNOS Release 10.1 for SRX Series Services Gateways
and J Series Services Routers ..........................................................122
Software Features ...........................................................................123
Hardware Features .........................................................................138
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX
Series Services Gateways and J Series Services Routers ..................139
Application Layer Gateways (ALGs) ................................................139
Chassis Cluster ...............................................................................139
Command-Line Interface (CLI) ........................................................140
Configuration .................................................................................142
Flow and Processing .......................................................................143
Interfaces and Routing ...................................................................144
Intrusion Detection and Prevention (IDP) .......................................144
J-Web .............................................................................................145
2
■
Management and Administration ...................................................145
Security ..........................................................................................146
WLAN .............................................................................................146
Known Limitations in JUNOS Release 10.1 for SRX Series Services
Gateways and J Series Services Routers ..........................................147
[accounting-options] Hierarchy ......................................................147
AX411 Access Point .......................................................................147
Chassis Cluster ...............................................................................147
Dynamic VPN .................................................................................149
Hardware .......................................................................................150
J-Web .............................................................................................154
NetScreen-Remote ..........................................................................155
Network Address Translation (NAT) ................................................155
Performance ..................................................................................156
SNMP .............................................................................................156
System ...........................................................................................156
Unified Threat Management (UTM) ................................................156
VLAN ..............................................................................................156
VPNs ..............................................................................................156
WLAN .............................................................................................156
Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J
Series Services Routers ...................................................................157
Outstanding Issues In JUNOS Release 10.1 for SRX Series Services
Gateways and J Series Services Routers ...................................157
Resolved Issues in JUNOS Release 10.1 for SRX Series Services
Gateways and J Series Services Routers ...................................176
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX
Application Layer Gateways (ALGs) ................................................182
Attack Detection and Prevention ....................................................182
CLI Reference .................................................................................183
CompactFlash Card Support ...........................................................183
Hardware Documentation ..............................................................184
Installing Software Packages ..........................................................185
Integrated Convergence Services ....................................................186
J-Web .............................................................................................189
Screens ...........................................................................................189
Hardware Requirements for JUNOS Release 10.1 for SRX Series Services
Gateways and J Series Services Routers ..........................................190
Transceiver Compatibility for SRX Series and J Series Devices .......190
Power and Heat Dissipation Requirements for J Series PIMs ..........190
Supported Third-Party Hardware ....................................................190
J Series CompactFlash and Memory Requirements ........................191
■
3
Dual-Root Partitioning Scheme Documentation for SRX Series Services
Gateways ........................................................................................192
Dual-Root Partitioning Scheme .......................................................192
Maximizing ALG Sessions .....................................................................201
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the
Second Routing Engine ..................................................................201
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX
JUNOS Software Release Notes for EX Series Switches ................................203
New Features in JUNOS Release 10.1 for EX Series Switches ................203
Hardware .......................................................................................204
Access Control and Port Security ....................................................205
Bridging, VLANs, and Spanning Trees ............................................205
Class of Service (CoS) .....................................................................205
Infrastructure .................................................................................205
Interfaces .......................................................................................206
Layer 2 and Layer 3 Protocols ........................................................206
Management and RMON ................................................................206
MPLS ..............................................................................................206
Packet Filters ..................................................................................206
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX
Series Switches ...............................................................................207
Layer 2 and Layer 3 Protocols ........................................................207
Infrastructure .................................................................................207
User Interface and Configuration ....................................................207
Limitations in JUNOS Release 10.1 for EX Series Switches ....................208
Access Control and Security ...........................................................208
Class of Service ..............................................................................208
Firewall Filters ................................................................................208
Infrastructure .................................................................................209
Interfaces .......................................................................................210
Outstanding Issues in JUNOS Release 10.1 for EX Series Switches ........211
Class of Service ..............................................................................211
Infrastructure .................................................................................211
J-Web Interface ...............................................................................212
Resolved Issues in JUNOS Release 10.1 for EX Series Switches .............213
Class of Service ..............................................................................214
Firewall Filters ................................................................................214
Hardware .......................................................................................215
Infrastructure .................................................................................215
J-Web Interface ...............................................................................216
Errata in Documentation for JUNOS Release 10.1 for EX Series
Switches .........................................................................................217
4
■
Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series
Switches .........................................................................................218
Upgrading or Downgrading from JUNOS Release 9.4R1 for EX Series
Switches ..................................................................................218
Upgrading from JUNOS Release 9.3R1 to Release 10.1 for EX Series
Switches ..................................................................................218
Upgrading from JUNOS Release 9.2 to Release 10.1 for EX Series
Switches ..................................................................................218
Downgrading from JUNOS Release 10.1 to Release 9.2 for EX4200
Switches ..................................................................................220
JUNOS Documentation and Release Notes ..................................................221
Documentation Feedback ............................................................................221
Requesting Technical Support .....................................................................221
Revision History ..........................................................................................223
■
5
JUNOS Software Release Notes for Juniper Networks M Series Multiservice Edge
Routers, MX Series Ethernet Service Routers, and T Series Core Routers
■
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series
Routers on page 6
■
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series,
MX Series, and T Series Routers on page 42
■
Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series
Routers on page 55
■
Errata and Changes in Documentation for JUNOS Software Release 10.1 for M
Series, MX Series, and T Series Routers on page 107
■
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX
Series, and T Series Routers on page 113
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
The following features have been added to JUNOS Release 10.1. Following the
description is the title of the manual or manuals to consult for further information.
Class of Service
■
Intelligent oversubscription service support (MX Series routers with Trio
MPC/MIC interfaces)—Arriving packets are assigned to one of two traffic classes
(control and best-effort) based on their header types and destination MAC address.
This allows for lower priority packets to be dropped more intelligently when
oversubscription occurs. Only packets mapped to queue 3 are marked as control
packets. Protocols such as telnet, FTP, and SSH that are mapped to queue 0 are
classified as best-effort. No configuration is necessary, but the queue assignments
can be altered with a multifield classifier.
[Class of Service]
■
CoS aspects of the MPC/MIC (MX Series routers with Trio MPC/MIC
interfaces)—Cover all aspects of CoS configuration for this hardware combination.
Support includes shaping rates at the queue level, configurable bandwidth profiles
with percentages, dynamic bandwidth allocation among different services,
scheduler node scaling, and delay buffer allocation. To configure, include the
relevant statements at the [edit class-of-service] hierarchy level and apply them
if necessary at other hierarchy levels such as the [edit interfaces] hierarchy level.
[Class of Service, Network Interfaces]
■
Per-priority shaping (MX Series platforms with Trio MPC/MIC
interfaces)—Enables you to configure a separate shaping rate for each of the
five priority levels so that higher priority services such as voice and video do not
starve lower priority services such as data. To configure, include the
shaping-rate-(excess | priority)-level rate [ burst-size burst ] statement at the [edit
class-of-service traffic-control-profiles tcp-name] hierarchy level and apply the traffic
control profile at the [edit interfaces] hierarchy level.
[Class of Service]
6
■
JUNOS Software Release Notes for Juniper Networks M Series Multiservice Edge Routers, MX Series Ethernet Service Routers,
and T Series Core Routers
■
Distribute excess bandwidth among different services for a subscriber (MX
Series routers with Trio MPC/MIC interfaces)—Service providers often use
tiered services that must carry excess bandwidth as traffic patterns vary. By
default, excess bandwidth between a configured guaranteed rate and shaping
rate is shared equally among all queues, which might not be optimal for all
subscribers to a service. You can control the distribution of this excess bandwidth
with the excess-rate statement. To configure the excess rate for a traffic control
profile, include the excess-rate statement at the [edit class-of-service
traffic-control-profiles tcp-name] hierarchy level and apply the traffic control profile
at the [edit interfaces] hierarchy level. To configure the excess rate for a queue,
include the excess-rate and excess-priority statements at the [edit class-of-service
scheduler scheduler-name] hierarchy level.
[Class of Service]
■
Scheduler node scaling (MX Series routers with Trio MPC/MIC interfaces)—The
hardware supports multiple levels of scheduler nodes. In per-unit-scheduling
mode, each logical interface (unit) can have four or eight queues and has a
dedicated level 3 scheduler node. The logical interfaces share a common level
2 node (one per port). In hierarchical-scheduling mode, a set of logical interfaces,
each with four or eight queues, has a level 2 CoS profile and one of its logical
interface children has a level 3 CoS profile. To better control system resources
in hierarchical-scheduling mode, you can limit the number of hierarchical levels
in the scheduling hierarchy to two. In this case, all logical interfaces and interface
sets with CoS profiles share a single (dummy) level 2 node, thereby increasing
the maximum number of logical interfaces with CoS profiles (the interface sets
must be at level 3). To configure scheduler node scaling, include the
maximum-hierarchy-levels statement at the [edit interfaces xe-fpc/pic/port
hierarchical-scheduler] hierarchy level. The only supported value is 2.
■
Forwarding-class aliases (M320 and T Series routers)—Enable you to configure
up to 16 forwarding classes and 8 queues, with multiple forwarding classes
assigned to single queues. To configure, include the class and queue-num
statements at the [edit class-of-service forwarding-classes] hierarchy level.
[Class of Service]
■
VLAN shaping on aggregate devices (MX Series routers with Trio MPC/MIC
interfaces)—VLAN shaping (per-unit scheduling) is supported on aggregated
Ethernet interfaces when link protection is enabled on the aggregated Ethernet
interface. When VLAN shaping is configured on aggregate Ethernet interfaces
with link protection enabled, the shaping is applied to the active child link. To
configure link protection on aggregated Ethernet interfaces, include the
link-protection statement at the [edit interfaces aex aggregated-ether-options]
hierarchy level. Traffic passes only through the designated primary link. This
includes transit traffic and locally generated traffic on the router. When the
primary link fails, traffic is routed through the backup link. You also can reverse
traffic, from the designated backup link to the designated primary link. To revert
back to sending traffic to the primary designated link when traffic is passing
through the designated backup link, use the revert command; for example, request
interfaces revert ae0. To configure a primary and a backup link, include the
primary and backup statements at the [edit interfaces ge-fpc/pic/port
gigether-options 802.3ad aex] hierarchy level or the [edit interfaces xe-fpc/pic/port
fastether-options 802.3ad aex] hierarchy level. To disable link protection, delete
■
7
the link-protection statement at the [edit interfaces aex aggregated-ether-options
link-protection] hierarchy level. To display the active, primary, and backup link
for an aggregated Ethernet interface, use the operational mode command show
interfaces redundancy aex.
■
Re-marking of MVPN GRE encapsulation DCSP at ASBR (MX Series routers
with Trio MPC/MIC interfaces)—Enables you to configure DSCP marking for
GRE encapsulated packets that aligns with the service provider core CoS policy
for an MVPN. To configure, include the DSCP rewrite-rule dscp dscp-rule-name
with the values at the [edit class-of-service] hierarchy level and then apply the
rewrite rule to the core-facing multicast interface at the [edit class-of-service
interfaces] hierarchy level.
[Class of Service]
■
PD-5-10XGE-SFPP, 10-port 10-Gigabit Ethernet (Type 4) PIC (T640, T1600,
and TX Matrix routers with G-FPC4, ST-FPC4, and ST-FPC4.1)—Supports a
WAN bandwidth of 100 Gbps in addition to the following features:
■
Intelligent handling of oversubscribed traffic
■
Line rate operation on up to five 10-Gigabit Ethernet ports
■
Tap features, such as flexible encapsulation, source address (SA) MAC
learning, MAC accounting, and MAC policing
■
Stacked virtual LAN (VLAN) tag and VLAN rewrite functionalities
[Network Interfaces, Class of Service, PIC Guide]
■
Intelligent oversubscription services (MX Series with 16-port 10-Gigabit
Ethernet MPC with SFP+)—The 16-port 10-Gigabit Ethernet Modular Port
Concentrator (MPC) is an oversubscribed configuration. Consequently, it is
necessary to protect control traffic over best-effort traffic as soon as packets
enter the line card. To do this, packets entering the line card are assigned a
preclassifier control traffic class according to the header types (such as destination
MAC addresses, and Layer 4 ports) in the packet. The preclassifier provides a
good way to classify and queue important control traffic in a different high-priority
queue from that used for best-effort traffic.
The preclassifier (control or best effort) is assigned prior to packets being accepted
into the initial stream and is used by the line card as an early designation (before
any class-of-service configuration is applied). When oversubscription occurs,
control traffic will be queued separately and should not be subject to any dropped
packets.
The Layer 2 protocols supporting the preclassifier are:
8
■
■
802.1ah
■
802.1g
■
802.1x
■
802.3ad
■
ARP
■
GMRP
■
GVRP
■
LACP
■
PVST
■
xSTP
■
IGMP
■
IPv4/IPv6 ICMP
■
IPv4/IPv6 ISIS
■
IPv4/IPv6 OSPF
■
IPv4/IPv6 PIM
■
IPv4 Router Alert
■
IPv4/IPv6 RSVP
■
IPv4/IPv6 VRRP
■
IIPv4/ IPv6 BGP
■
IPv4/ IPv6 LDP
■
IPv4 UDP/L2TP
■
RIP (UDP port checks)
The preclassifier is also supported on label-switching encapsulation PPP.
[Class of Service]
■
Feature support on 16-port 10-Gigabit Ethernet MPC with SFP+ (MX Series
routers)—The following features are supported on the 16-port 10-Gigabit Ethernet
MPC with SFP+:
■
Accepts traffic destined for GRE tunnels or DVMRP (IP-in-IP) tunnels (JUNOS
Release 10.0R2)
■
Bidirectional Forwarding Detection (BFD) protocol (JUNOS Release 10.0R2)
■
Border Gateway Protocol (BGP) (JUNOS Release 10.0R2)
■
BGP/Multiprotocol Label Switching (MPLS) virtual private networks (VPNs)
(JUNOS Release 10.0R2)
■
Distance Vector Multicast Routing Protocol (DVMRP) and generic routing
encapsulation (GRE) support, access side and server side (JUNOS Release
10.0R2)
■
Firewall filters (JUNOS Release 10.0R2)
■
9
10
■
■
Flexible Ethernet encapsulation (JUNOS Release 10.0R2)
■
Graceful Routing Engine switchover (GRES) (JUNOS Release 10.0R2)
■
Ingress differentiated (JUNOS Release 10.0R2)
■
Differentiated Services code point rewrite (DSCP) (JUNOS Release 10.0R2)
■
Intelligent oversubscription (JUNOS Release 10.0R2)
■
Integrated routing and bridging (IRB) (JUNOS Release 10.1R1)
■
Intermediate System-to-Intermediate System (IS-IS) (JUNOS Release 10.0R2)
■
Internet Group Management Protocol (IGMP) (excludes snooping) (JUNOS
Release 10.0R2)
■
IPv4 (JUNOS Release 10.0R2)
■
IP multicast (JUNOS Release 10.0R2)
■
Label Distribution Protocol (LDP) (JUNOS Release 10.0R2)
■
Labeled-switched path (LSP) accounting, policers, and filtering (JUNOS Release
10.0R2)
■
LAN-PHY mode (JUNOS Release 10.0R2)
■
Layer 2 frame filtering (JUNOS Release 10.0R2)
■
IEEE 802.3ad link aggregation (JUNOS Release 10.0R2)
■
Link Aggregation Control Protocol (LACP) (JUNOS Release 10.0R2)
■
Local loopback (JUNOS Release 10.0R2)
■
MAC learning, policing (JUNOS Release 10.0R2)
■
Multiple tag protocol identifiers (TPIDs), accounting, and filtering (JUNOS
Release 10.0R2)
■
Multiprotocol Label Switching (MPLS) (JUNOS Release 10.0R2)
■
Nonstop active routing (NSR) (JUNOS Release 10.0R2)
■
Multitopology routing (MTR) (JUNOS Release 10.0R2)
■
Open Shortest Path First (OSPF) (JUNOS Release 10.0R2)
■
Packet mirroring (JUNOS Release 10.0R2)
■
Quality of service (QoS) per port: (JUNOS Release 10.0R2)
■
Eight queues per port
■
Excess-rate configuration at the traffic-control-profile level
■
Excess-rate and excess-priority configuration at the queue level
■
Shaping at the port level
■
■
Shaping at the queue level
■
Scheduling of queues based on weighted round-robin (WRR) per priority
class
■
Tricolor marking
■
Weighted random early detection (WRED)
QoS per virtual LAN (VLAN): (JUNOS Release 10.0R2)
■
Accounting, filtering, and policing
■
IEEE 802.1p rewrite
■
Classification
■
Excess-rate configuration at the traffic-control-profile level
■
Tricolor marking
■
Resource Reservation Protocol (RSVP) (JUNOS Release 10.0R2)
■
Routing Information Protocol (RIP) (JUNOS Release 10.0R2)
■
Simple Network Management Protocol (SNMP) (JUNOS Release 10.0R2)
■
IEEE 802.1Q VLANs: (JUNOS Release 10.0R2)
■
VLAN stacking and rewriting
■
Channels defined by two stacked VLAN tags
■
Flexible VLAN tagging
■
IP service for nonstandard TPID and stacked VLAN tags
■
Virtual private LAN service (VPLS) (JUNOS Release 10.0R2)
■
Virtual private network (VPN) (JUNOS Release 10.0R2)
■
Virtual Router Redundancy Protocol (VRRP) for IPv4 (JUNOS Release 10.0R2)
To support these features, some modifications have been made to the following
configuration statements:
■
The ability to configure the DSCP as the action of a filter rule is already
present in the JUNOS Software. However, with this line card, the value range
permitted is modified from 0, to 0 through 63. To include DSCP as the action
of a filter rule, include the dscp value parameter at the [edit firewall filter
filter-name] hierarchy level.
■
To fully leverage the features offered through the new chipset on the line
card, include the enhanced-hash-key option at the [edit forwarding-options]
hierarchy level.
[Class of Service]
■
11
■
IEEE 802.1ak-2007 MVRP (MX Series routers)—The Multiple VLAN Registration
Protocol (MVRP) is a standards-based Layer 2 network protocol used among
switches to dynamically share and update VLAN information with other bridges.
VLAN information exchanged includes:
■
The set of VLANs that currently have active members
■
The ports through which the active members can be reached
To operate MVRP, edge ports should have the static VLAN configuration. The
edge ports will not be configured for MVRP. MVRP is only enabled on the
core-facing trunk ports where no static VLANs are configured.
To configure MVRP, include the mvrp statement and desired options at the [edit
protocols] hierarchy level.
[Class of Service]
■
Elevated packet drops during oversubscription (MX Series routers with Trio
MPC/MIC interfaces)—During periods of oversubscription, the WRED process
drops more packets than expected from relatively full queues. There is no
configuration for this feature, which transparently applies scaling to
oversubscribed queues.
[Class of Service]
High Availability
■
Enhancements to unified ISSU support on PICs (T Series)—JUNOS Release 10.1
extends unified ISSU support for the following PICs to T Series routers:
■
PB-1CHOC12-STM4-IQE-SFP, 1-port channelized OC12/STM4 enhanced IQ
PIC
■
PB-1OC12-STM4-IQE-SFP, 1-port non-channelized OC12/STM4 enhanced IQ
PIC
■
PB-4CHDS3-E3-IQE-BNC, 4-port channelized DS3/E3 enhanced IQ PIC
■
PB-4DS3-E3-IQE-BNC, 4-port non-channelized DS3/E3 enhanced IQ PIC
[High Availability]
Interfaces and Chassis
12
■
■
New 60-Gigabit Ethernet Queuing MPC (model number
MX-MPC2-3D-Q)—Supported on MX Series routers. For a list of supported MPCs,
see the MX Series Line Card Guide.
■
New 60-Gigabit Ethernet MPC (model number MX-MPC2-3D)—Supported on
MX Series routers. For a list of supported MPCs, see the MX Series Line Card
Guide.
■
New 60-Gigabit Ethernet Enhanced Queuing MPC (model number
MX-MPC2-3D-EQ)—Supported on MX Series routers. For a list of supported
MPCs, see the MX Series Line Card Guide.
■
New 20-port Gigabit Ethernet MIC with SFP (model number
MIC-3D-20GE-SFP)—Supported on MX Series routers. For a list of supported
■
New Modular Port Concentrators (MPCs) and Modular Interface Cards
(MICs)—Supported on MX Series platforms. Up to two MICs plug into the MPC
to provide the physical interface for the MPC line card. The MPCs provide
increased capacity on Gigabit Ethernet and 10-Gigabit Ethernet hardware. For a
list of supported MPCs and MICs, see the MX Series Line Card Guide.
[Network Interfaces]
■
New 4-port 10-Gigabit Ethernet MIC with XFP (model number
MIC-3D-4XGE-XFP)—Supported on MX Series routers. For a list of supported
■
Layer 2 VPLS, IRB, and mesh group feature parity (MX Series routers with
Trio MPC/MIC interfaces)—Support for Layer 2 feature parity with JUNOS Release
9.1 on MX Series routers that include Trio Modular Port Concentrators (MPCs)
and Modular Interface Cards (MICs).
Layer 2 feature parity includes:
■
Layer 2 bridging
■
VPLS forwarding
■
MAC address learning, aging, and MAC address limit
■
Mesh group support
■
Implicit VLAN mapping
■
Integrated routing and bridging (IRB)
■
Multicast over IRB
■
MAC statistics
Layer 2 features that are not supported in this release include:
■
■
Spanning Tree Protocols (xSTP)
■
VLAN Spanning Tree Protocol (VSTP)
■
Multiple Spanning Tree Protocol (MSTP)
■
Rapid Spanning Tree Protocol (RSTP)
■
Layer 2 Tunneling Protocol (L2TP)
Upgrading a T1600 router to be the LCC0 of the TX Matrix Plus router—You
can now upgrade an operational T1600 router to be the lcc0 in a newly configured
TX Matrix plus router. The procedures require JUNOS Release 10.1 on the TX
Matrix Plus router and the T1600 router. Reboot is required to transfer control
of the T1600 router to the routing matrix. You can also downgrade the lcc0 to
a standalone T1600 router by rolling back to the former configuration. Upgrade
and integration of subsequent operational T1600 routers to form lcc1 and lcc2
■
13
(and so on) is not supported. Use the offline procedures to upgrade and integrate
the remaining T1600 routers into the routing matrix.
[TX Matrix Plus Hardware, System Basics and Services Command Reference]
■
Per-unit scheduling for GRE tunnels using IQ2 PICs (M7i, M10i, M120, and
M320 routers with E3–FPC)—Supports enhanced IQ2 PIC and IQ2E PIC
performance, adding all functionality of tunnel PICs. The QoS for the GRE tunnel
traffic will be applied as the traffic is looped through the IQ2/IQ2E PIC.
Shaping is performed on full packets that pass through the GRE tunnel.
IQ2 and IQ2E PICs support all interfaces that are supported on tunnel PICs, as
follows:
■
gr-fpc/pic/port
■
vt-fpc/pic/port
■
lt-fpc/pic/port
■
ip-fpc/pic/port
■
pe-fpc/pic/port
■
pd-fpc/pic/port
■
mt-fpc/pic/port
The port variable is always zero.
The provided tunnel functionality is the same as that of regular tunnel PICs.
When tunnel services are enabled on IQ2 and IQ2E PICs, they work exclusively
as tunnel PICs. The physical ports on the PICs cannot be used in tunnel mode.
To configure exclusive tunnel mode, use the tunnel-only statement at the [chassis
fpc number pic number] hierarchy level.
You can use the show interfaces queue gr-fpc/pic/port command to display
statistics for the specified tunnel.
[Network Interfaces, Class of Service, PIC Guide]
■
Root System Domain (RSD) configuration of logical interface filters on shared
interfaces (JCS1200 platform)—Enables Root System Domain (RSD) configuration
support for logical interface filters on shared interfaces. In previous releases,
logical interface filters were configured on each Protected System Domain (PSD).
This release supports configuration on the RSD.
To configure a logical interface filter on the RSD, apply the firewall filter to the
logical interface on the shared interface by including the filter output filter-name
statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy
level on the RSD.
Filtering is performed on the PSD, but logical interface filters configured on the
RSD are applied automatically by the PSD. Filters configured on the RSD can
co-exist with filters configured on the PSD. Counter statistics related to PSD
filtering are available on the RSD.
[Protected System Domain]
14
■
■
Two new AC power supply modules (AC Power Entry Module 10kW US and
AC Power Entry Module 10kW EMEA) in chassis—The JUNOS Software now
supports two new AC power supply modules on T640 and T1600 routers: AC
Power Entry Module 10kW US and AC Power Entry Module 10kW EMEA (for
U.S. and EMEA markets, respectively). The two Power Entry Modules (PEMs)
cannot interoperate and the JUNOS Software reports an alarm when they do.
The show chassis environment pem command output will show AC Input: status
instead of DC Input: status and the Temperature will show the actual temperature
reading. Two new power supply descriptions, US and EMEA, are added to
distinguish the new modules from existing ones in the output of the show chassis
hardware command output.
[System Basics and Service Command Reference]
■
Next-hop cloning and permutations disabled in T Series enhanced scaling
FPCs (FPC Type 1-ES, FPC Type 2-ES, FPC Type 3-ES, and FPC Type 4-ES)—The
next-hop cloning and permutations are now disabled in these FPCs with enhanced
load-balancing capability. As a result, the memory utilization is reduced for a
highly scaled system with a high number of next hops on ECMP or aggregated
interfaces.
[System Basics]
■
Fragmentation support for GRE-encapsulated packets (Multiservices DPC)
(M120, M7i/M10i with enhanced CFEB, M320 with E3 FPC, and MX Series
routers only)—Enables the Packet Forwarding Engine to update the IP
identification field in the outer IP header of packets encapsulated with generic
routing encapsulation (GRE), so that reassembly of the packets is possible after
fragmentation. The previous CLI constraint check that requires you to configure
either the clear-dont-fragment-bit statement or a tunnel key with the
allow-fragmentation statement is no longer enforced. There are no associated
changes to the CLI statements or operational mode commands.
NOTE: For other routers, the earlier configuration constraint check still holds.
[Services Interfaces, MPLS Applications, MX Series Layer 2 Configuration Guide]
■
NAT compliance enhancements—Add modifications to the existing NAT
functionality on the services PICs to achieve compliance with RFCs UDP 4787,
TCP 5382, and ICMP 5508. These enhancements apply to IPv4–IPv4, IPv6–IPv6,
and IPv4–IPv6 source NAT and are not supported with destination NAT. New
CLI configuration settings associated with RFC 4787 include the mapping-timeout
statement at the [edit services nat pool pool-name] hierarchy level and the
address-pooling, filtering-type, and mapping-type statements at the [edit services
nat rule rule-name term term-name then translated] hierarchy level. There are no
associated changes to the operational mode commands.
[Services Interfaces]
■
Support for VRF in Routing Engine-based sampling on M Series, M320, MX
Series, M120, and T Series routers—For VRF Routing Engine-based sampling,
the kernel queries the correct VRF route table based on the ingress interface
index for the received packet. For interfaces configured in VRF, the sampled
■
15
packets contain the correct input and output interface SNMP index, the source
and destination AS numbers, and the source and destination mask.
There are two ways to verify the sampled packets. The first is to include the file
sampled statement at the [edit forwarding-options sampling traceoptions] hierarchy
level and the local dump statement at the [edit forwarding-options family inet output
flow-server server] hierarchy level, and check the sampled file using the tail –f
/var/tmp/sampled command from the router shell. The second is to export and
verify the sampled packets to the flow-server.
[Services Interfaces, Feature Guide]
■
New 4-port Channelized OC12 Enhanced Intelligent Queuing (IQE) type 3
PIC (M Series and T Series routers)—Provides increased channelization and an
improved QoS model; with channelization capabilities and scaling that make it
ideal for edge aggregation.
Improved QoS functionality supports policing based on DSCP/IPPREC/EXP, five
priority levels, two shaping rates (CIR and PIR), option to use shared scheduling
on set of logical interfaces, DSCP rewrite on ingress, and configurable delay
buffers for queueing. The QoS capabilities provide service differentiation for
service providers.
The interface configuration syntax of existing IQ PICs is retained, but
configuration limits are changed to match the augmented capabilities of IQE
PICs.
All functionality available on the 4-port Channelized OC12 IQ Type 2 PIC is
supported by this PIC.
■
Enhanced Intelligent Queuing (IQE) PICs add support for T3 and T1
channelization under SDH framing (M40e, M120, and M320 with Sahara-FPC,
and T Series routers)—The following IQE PICs are supported:
■
1-port COC48 IQE
■
4-port COC12 IQE
■
1-port COC12 IQE
■
2-port COC3 IQE
The JUNOS Software supports T1 and CT1 interface types under CAU4. To
configure T1 and CT1 interfaces under CAU4, use the t1 and ct1 statements at
the [edit interfaces cau4-fpc/pic/port:unit partition number interface-type] hierarchy
level.
With T1 and CT1 interface configurations under CAU4 interfaces, you can
configure a maximum of 84 T1 or CT1 inerfaces. However, the partition range
under CAU4 interfaces was previously restricted to from 1 to 63. This range has
increased to from 1 to 84 for T1 and CT1 interfaces.
The JUNOS Software supports T1, CT1, T3, and CT3 interfaces under Channelized
AU4 partitions. To configure T1, CT1, T3, and CT3 interfaces under Channelized
AU4, use the ct1 and t1 statements at the [edit interfaces cau4-fpc/pic/port:unit
partition partition-number] hierarchy level or the ct3 and t3 statements at the [edit
interfaces cau4-fpc/pic/port:unit partition number interface-type] hierarchy level.
16
■
The JUNOS Software also supports M13 mapped T1 interfaces under CAU4. To
configure a T1 interface under CAU4, use the t1 statement at the [edit interfaces
cau4-fpc/pic/port:unit partition partition-number interface-type t1] or [edit interfaces
cau4-fpc/pic/port:unit partition partition-number interface-type ct1] hierarchy level.
The JUNOS Software does not allow combined configurations of E1 and E3
interfaces together under a CAU4 interface.
Similarly, you cannot mix T1, E1, T3, and E3 interfaces directly under CAU4.
NOTE: The TUG-3 partition is not supported.
ITU-T VT-mapping in combination with TUG3 partition is not supported.
[Network Interfaces, PIC Guide]
■
Stateful firewall chaining for FTP, TFTP, and RTSP data sessions (MX Series
routers with Multiservices DPCs, and M120 or M320 routers with Multiservices
400 PICs)—Adds support for stateful firewall rule sets in Dynamic Application
Awareness for JUNOS Software service chains. New application-level gateways
(ALGs) are available for FTP (junos-ftp), TFTP (junos-tftp), and RTSP (junos-rtsp);
you can include them as values for the applications statement at the [edit services
stateful-firewall rule rule-name term term-name from] hierarchy level. In addition,
you can include new statement options at the [edit interfaces ms-fpc/pic/port
services-options ignore-errors] hierarchy level to enable stateful firewall sessions
to operate in a no-drop mode and ignore various traffic errors that would normally
result in dropped packets. There are no CLI changes in the APPID, IDP, AACL,
or L-PDF configurations. The associated operational mode commands should
report the new applications when identified.
■
17
JUNOS XML API and Scripting
18
■
■
New JUNOS XML API operational request tag elements—Table 1 on page 19
lists the JUNOS Extensible Markup Language (XML) operational request tag
elements that are new in JUNOS Release 10.1, along with the corresponding CLI
command and response tag element for each one.
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.1
Request Tag Element
CLI Command
Response Tag Element
<clear-dhcpv6-server-binding-information>
clear_dhcpv6_server_binding_information
clear dhcpv6 server binding
NONE
<clear-dhcpv6-server-statistics-information>
clear_dhcpv6_server_statistics_information
clear dhcpv6 server statistics
NONE
<clear-mpls-static-lsp-information>
clear_mpls_static_lsp_information
clear mpls static-lsp
NONE
<clear-mvrp-interface-statistics>
clear_mvrp_interface_statistics
clear mvrp statistics
NONE
<clear-idp-appddos-cache>
clear_idp_appddos_cache
clear security idp application-ddos cache
NONE
<clear-idp-status-information>
clear_idp_status_information
clear security idp status
<clear-idp-status-information>
<clear-vrrp-information>
clear_vrrp_information
clear vrrp
<vrrp-message>
<clear-vrrp-interface-statistics>
clear_vrrp_interface_statistics
clear vrrp interface
<vrrp-message>
<request-script-refresh-from>
request_script_refresh_from
request system scripts refresh-from
NONE
<get-dhcpv6-server-binding-information>
get_dhcpv6_server_binding_information
show dhcpv6 server binding
<dhcpv6-server-binding-information>
<get-dhcpv6-server-statistics-information>
get_dhcpv6_server_statistics_information
show dhcpv6 server statistics
<dhcpv6-server-statistics-information>
<get-mpls-static-lsp-information>
get_mpls_static_lsp_information
show mpls static-lsp
<mpls-static-lsp-information>
<get-mvrp-information>
get_mvrp_information
show mvrp
<mvrp-information>
<get-mvrp-applicant-information>
get_mvrp_applicant_information
show mvrp applicant-state
<mvrp-applicant-state>
<get-mvrp-dynamic-vlan-memberships>
get_mvrp_dynamic_vlan_memberships
show mvrp dynamic-vlan-memberships
<mvrp-vlan-information>
<get-mvrp-interface-information>
get_mvrp_interface_information
show mvrp interface
<mvrp-interface-information>
■
19
Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.1 (continued)
Request Tag Element
CLI Command
Response Tag Element
<get-mvrp-registration-state>
get_mvrp_registration_state
show mvrp registration-state
<mvrp-registration-information>
<get-mvrp-interface-statistics>
get_mvrp_interface_statistics
show mvrp statistics
<mvrp-interface-statistics>
<get-idp-subscriber-policy-list>
get_idp_subscriber_policy_list
show security idp policies
<idp-subscriber-policy-list>
<get-idp-policy-template-information>
get_idp_policy_template_information
show security idp policy-templates-list
<idp-policy-template-information>
<get-idp-detail-status-information>
get_idp_detail_status_information
show security idp status detail
<idp-detail-status-information>
<get-service-nat-mapping-information>
get_service_nat_mapping_information
show services nat mappings
<service-nat-mapping-information>
<get-task-memory-information>
get_task_memory_information
show task memory
<task-memory-information>
<get-vrrp-information>
get_vrrp_information
show vrrp
<vrrp-information>
<get-vrrp-interface-information>
get_vrrp_interface_information
show vrrp interface
<vrrp-information>
<get-vrrp-track-interfaces>
get_vrrp_track_interfaces
show vrrp track
<vrrp-information>
20
■
[JUNOS XML API Operational Reference]
MPLS Applications
■
Static LSPs at the ingress router—You can now configure a named static LSP
at the ingress router. This feature allows you to configure multiple static LSPs
between two specific routers. It is not necessary to configure unique names for
static versus dynamic LSPs (a static LSP could have the same name as a dynamic
LSP configured on the same router). This feature also allows you to configure a
single-hop static LSP by specifying either an explicit null label or no label.
To configure a static LSP on an ingress router, include the ingress statement at
the [edit protocols mpls static-label-switched-path static-lsp-name] hierarchy level.
You must also configure the to and next-hop statements at the [edit protocols mpls
static-label-switched-path static-lsp-name] hierarchy level. You can optionally
configure the push statement. If you configure the push statement, you must
specify a non-reserved label in the range of 0 through 1,048,575.
To display information about ingress static LSPs, issue the show mpls lsp static
ingress command. To display routing table entries corresponding to ingress static
LSPs, issue the show route table inet.3 command or the show route next-hop
next-hop-ip-address static-label-switched-path static-lsp-name command.
[MPLS, Routing Protocols and Policies Command Reference]
■
Static LSPs at the transit router—You can now configure a named static LSP
on a transit router. To configure a transit static LSP, include the transit statement
at the [edit protocols mpls static-label-switched-path path-name] hierarchy level
and include the next-hop statement at the [edit protocols mpls
static-label-switched-path static-lsp-name] hierarchy level. You must also configure
either the pop or the swap statement at the [edit protocols mpls
static-label-switched-path static-lsp-name transit] hierarchy level. If you configure
the swap statement, you must specify a non-reserved label in the range of 0
through 1,048,575.
The transit static LSP is added to the mpls.0 routing table. You should configure
each static LSP using a unique name and at least a unique incoming label on the
router. Each transit static LSP can have one or more incoming labels configured.
If a transit LSP has more than one incoming label, each would effectively operate
as an independent LSP, meaning you could configure all of the related LSP
attributes for each incoming label. The range of incoming labels available is
limited to the standard static LSP range of labels (1,000,000 through 1,048,575).
To verify that a static LSP has been added to the routing table, issue the show
route table mpls.0 command.
[MPLS]
■
Bypass static LSPs—You can now configure a named bypass static LSP for ingress
and transit static LSPs, to be used if the primary LSP fails. To configure a bypass
static LSP, include the bypass statement at the [edit protocols mpls
static-label-switched-path path-name] hierarchy level. You must also configure the
to and next-hop statements at the [edit protocols mpls static-label-switched-path
static-lsp-name bypass] hierarchy level. You can also configure link and node
protection for static LSPs. If you configure both link and node protection for the
static LSP and the primary link fails, the node protection feature is preferred.
■
21
[MPLS]
■
Static LSP revert timer—You can now configure a revert timer for ingress and
transit static LSPs. After traffic has been switched to a bypass static LSP, it is
typically switched back to the primary static LSP when it comes back up. There
is a configurable delay in the time (called the revert timer) between when the
primary static LSP comes up and when traffic is reverted back to it from the
bypass static LSP. This delay is needed because when the primary LSP comes
back up, it is not certain whether all of the interfaces on the downstream node
of the primary path have come up yet. The delay range is from 0 through 65,535
seconds and is configurable at each interface. If you configure a value of 0, traffic
is never automatically reverted to the primary LSP, even if it does come back
up. The only exception is if the bypass LSP goes down. The default value is 5
seconds. To configure the revert timer for an interface, include the
protection-revert-time statement at the [edit protocols mpls interface interface-name
static] hierarchy level. You can display the revert timer value for an interface
using the show mpls interface detail command.
[MPLS]
■
Static LSP traceoptions—You can now configure the traceoptions statement to
trace messages related to ingress and transit static LSPs by including the static
flag at the [edit protocols mpls traceoptions flag] hierarchy level.
[MPLS]
■
Static LSP statistics—You can now display statistics related to MPLS static LSPs
by issuing the show mpls static-lsp statistics command and the monitor static-lsp
lsp-name command. The show mpls static-lsp statistics command includes the
following options: ingress, transit, bypass, and name static-lsp-name. This command
displays the packet count and byte count for the static LSP. You can clear the
statistics for static LSPs by issuing the clear mpls static-lsp statistics command.
You can also log the static LSP statistics to a file by specifying a file for the MPLS
statistics statement. You can configure this file using the set protocols mpls
statistics interval interval file filename command.
[MPLS, Routing Protocols and Policies Command Reference]
Multiplay
■
Border Gateway Function (BGF) RTCP XR reporting—Provides support for the
H.248 RECRTCPXR (Received RTCP Extended Reporting) and RECRTCPXRBM
(Received RTCP XR Burst Mode) reporting packages. The RECRTCPXR package
defines properties and statistics that provide extended quality-of-service metrics
received from the gateway controller. The RECRTCPXRBM package defines
properties and statistics that provide burst metrics received from the gateway
controller. Report data is available to the BGF when the gateway controller sends
the relevant XR reporting packets and RTCP monitoring is active. Not all gateway
controllers send the extended reporting packets. When XR packets are not
received, all XR fields are displayed as 0s (zeroes).
You can use the following existing command to display the RECRTCPXR and
RECRTCPXRBM report fields for a given gate-id: show services pgcp gate
gateway-name statistics gate-id gate-id.
[Multiplay Solutions, System Basics Command Reference]
22
■
■
Integrated Multi-Services Gateway (IMSG) failed call reporting—Provides more
extensive statistics on failed calls through improved show command output.
You can use the following existing command to display statistics on failed calls:
show services border-signaling-gateway calls-failed gateway gateway-name.
[Multiplay Solutions, System Basics Command Reference]
■
Integrated Multi-Services Gateway (IMSG) media release—Enables the IMSG
SIP function to release media resources when handling calls between two entities
in the same media realm (the virtual interface specified in the PGCP
configuration). When the new call usage policies for both entities allow media
release, media resources are shared instead of being reserved for both entities.
This improves the utilization of media resources and prevents latency.
To configure media release, enter the media-release statement at the [edit services
border-signaling-gateway gateway-name sip new-call-usage-policy policy-name term
term-name then media-policy] hierarchy level.
[Multiplay Solutions, Services Interfaces]
Routing Policy and Firewall Filters
■
New MPLS firewall filter match conditions (T Series routers)—The JUNOS
Software now supports filtering MPLS-tagged IPv4 packets based on IP parameters
for up to five MPLS stacked labels.
To configure the filter match conditions for an MPLS family based on IP
parameters, include the from statement at the [edit firewall family family-name
filter filter-name term term-name] hierarchy level:
from {
match-conditions;
}
NOTE: New filter match conditions are applicable only for MPLS-tagged IPv4 packets.
MPLS-tagged IPv6 packets are not supported by this filter.
[Policy Framework, Routing Protocols and Policies Command Reference]
■
23
Routing Protocols
■
BGP support for MDT-SAFI updates without a route target—By default, the
JUNOS Software requires MDT-SAFI updates to have a route target attached.
Some vendors do not support attaching route targets to the MDT-SAFI updates.
For interoperability with these vendors, the JUNOS Software allows importing
MDT-SAFI updates without a route target being attached. The MDT-SAFI is
imported if the MDT default address in the MDT-SAFI prefix matches the MDT
default address configured within the routing instance.
To configure the MDT default address, include the group-address group-address
statement at the [edit routing-instances routing-instance-name provider-tunnel
pim-ssm] hierarchy level.
[Multicast, Policy Framework]
■
Distributed periodic packet management support for aggregate
interfaces—Extends support for the Bidirectional Forwarding Detection (BFD)
protocol to use the periodic packet management daemon (PPMD) to distribute
IPv4 sessions over aggregate interfaces. PPMD automatically runs on the Routing
Engine and the Packet Forwarding Engine. To disable PPMD on the Packet
Forwarding Engine only, include the no-delegate-processing statement at the [edit
routing-options ppm] hierarchy level. Only IPv4 BFD sessions over aggregate
interfaces are supported. PPMD does not support IPv6 BFD sessions over an
aggregate interface or MPLS BFD sessions over an aggregate interface.
[Routing Protocols]
■
PIM join suppression support—Enables a router to defer sending join messages
to an upstream router when identical join messages are sent on the same
multiaccess network. This improves scalability and efficiency by reducing the
number of identical messages sent to the same router.
This feature is useful when there are a large number of routers on a multiaccess
network that will be receiving traffic for a particular multicast group. Suppressing
joins at each router saves bandwidth and reduces heavy processing at upstream
routers.
PIM join suppression can be implemented per multiaccess interface and per
multicast group. It is only needed on downstream routers, and does not need to
be implemented on upstream routers in order for it to work.
A tracking bit field on the LAN prune delay hello option is used in the CLI to
enable join suppression for downstream routers. By default, the tracking bit is
set to 1 and PIM join suppression is disabled. This is the default behavior for
JUNOS Release 10.0 and earlier for Juniper Networks routers. With join
suppression disabled (T-bit=1), a downstream receiving router will send join
messages even if it receives identical joins for the same upstream router, as long
as no other router in the network has join suppression enabled. When the tracking
bit is set to 0 for at least one neighbor on this interface, join suppression is
enabled, and the receiving router will defer sending identical joins. Use
reset-tracking-bit in the CLI to enable join suppression.
When an upstream router receives a join message, its behavior is independent
of the value of the T-bit in the hello option. When join suppression is triggered,
a timer is activated and all sending of joins is deferred for the length of time
24
■
specified by the timer. This is a random timer with value ranges between 0 to
Max Override Interval. The timer is reset each time join suppression is triggered,
and the defer period is dependent on other settings in the LAN prune delay,
including propagation-delay and override-interval.
Use the show protocols PIM command to see if the reset-tracking-bit is present,
indicating that the T-bit has been changed to 0 and PIM join suppression is
enabled.
[Multicast, Routing Protocols and Policies Command Reference]
■
Improve IGMPv3 snooping performance using bulk updates 1a3,14—Whenever
an individual interface joins or leaves a multicast group, a new next-hop entry
is installed in the routing table and the forwarding table. This can require a lot
of processing time when the frequency and number of IGMP join and leave
messages are high.
A new configuration statement can be used to accumulate outgoing interface
changes and perform bulk updates to the routing table and forwarding table.
This reduces the processing time and memory overhead required when processing
join and leave messages, thus improving scalability.This is useful for applications
such as Internet Protocol television (IPTV), in which users changing channels
can create thousands of interfaces joining or leaving a group in a short period
of time.
To enable bulk updates of join and leave messages, include the next-hop-hold-time
statement and specify the number of milliseconds to wait before processing the
messages. The next-hop-hold-time statement can be configured at the [edit
routing-instances routing-instance-name] hierarchy level. The hold time can be
configured from 1 to 1000 milliseconds. The routing instance must be of type
VPLS or virtual-switch.
If the next-hop-hold-time statement is deleted from the router configuration, IGMP
bulk updates are disabled. The configuration of the next-hop-hold-time statement
can be verified using the show multicast snooping route command.
[Multicast, Routing Protocols and Policies Command Reference]
■
Hub-and-spoke support for multiprotocol BGP-based multicast VPNs with
PIM-SSM GRE S-PMSI transport—Multiprotocol BGP-based (MBGP) multicast
VPNs (also referred to as next-generation Layer 3 VPN multicast) can be
configured using protocol-independent multicast source-specific multicast
(PIM-SSM) selective provider multicast service interface (S-PMSI) tunnels in a
hub-and-spoke topology.
This feature is useful in the following scenarios:
■
Customer sources and rendezvous points (RPs) are located only in the hub
sites and customer receivers are located in spoke sites or other hub sites.
■
Customer sources are located only in spoke sites and customer receivers are
located only in hub sites.
To configure MBGP MVPNs to use PIM-SSM S-PMSI tunnels in a hub-and-spoke
topology:
■
Include the group-range statement and specify the group address range at
the [edit routing-instances routing-instance-name provider-tunnel selective group
■
25
group-address source source-address pim-ssm] hierarchy level on all PE routers
participating in the MVPN.
■
Include the threshold-rate statement and specify zero as the threshold value
at the [edit routing-instances routing-instance-name provider-tunnel selective
group group-address source source-address] hierarchy level on all PE routers
participating in the MVPN.
■
Include the family inet-mvpn statement and family inet6-mvpn statement at
the [edit routing-instances routing-instance-name vrf-advertise-selective] hierarchy
level to selectively advertise routes on PE routers that use one VRF for unicast
routing and a separate VRF for MVPN routing.
[VPNs, Routing Protocols, Routing Protocols and Policies Command Reference]
26
■
Services Applications
■
FlowTapLite enhancements—Extend support for interception of IPv6 packets
on MX Series, M120, and M320 routers. For IPv6, the global filter taps packets
from the default IPv6 routing table and does not tap packets from other VRFs.
To tap packets from other VRFs, you can install separate VRF filters. For IPv4,
the global filter intercepts all IPv4 packets irrespective of the VRF. The limit for
filters remains 3000, which is now shared between IPv4 and IPv6. For example,
you can install 3000 IPv4 filters or 3000 IPv6 filters, or a combination of both
that totals 3000. You cannot install 3000 IPv4 filters and 3000 IPv6 filters.
No new statements are required to configure these enhancements. However,
whether you use IPv6 flow tapping or not, you must include the family inet6
statement at the [edit interfaces vt-fpc/pic/port unit logical-unit-number] hierarchy
level.
Subscriber Access Management
■
27
■
JUNOS subscriber access scaling values (M120, M320, and MX Series
routers)—Table 2 on page 28 lists the DHCP, PPP, and PPPoE scaling values
supported for subscriber access in this release of M120, M320, and MX Series
routers. In this table, DPC means only MX Series Enhanced Queuing IP Services
DPCs (DPCE-R-Q-40GE-SFP and DPCE-R-Q-4XGE-XFP). These DPCs support only
DHCP subscribers; they do not support PPP subscribers.
Table 2: Subscriber Access Scaling Values for M120, M320, and MX Series Routers
Subscriber Access Feature
M120/M320
MX240
MX480/960
DHCP client bindings per chassis
–
120,000
120,000
Per DPC
–
16,000
16,000
Per chassis with DPCs
–
32,000
64,000
Per Trio MPC/MIC
–
64,000
64,000
Per chassis with Trio MPC/MIC
–
64,000
64,000
Dynamic PPPoE interfaces per chassis
15,999
63,999
63,999
Dynamic PPPoE interfaces per IQ2/IQ2E PIC
4000
–
–
Dynamic PPPoE interfaces per Trio MPC/MIC
–
32,000
32,000
Static interfaces per chassis
15,999
15,999
15,999
Per IQ2/IQ2E PIC
2000
–
–
Per chassis with IQ2/IQ2E PIC
8000
–
–
Per Trio MPC/MIC
–
32,000
32,000
Per chassis with Trio MPC/MIC
–
32,000
32,000
DHCP subscriber VLANs
PPP logical interfaces
PPPoE subscriber VLANs
PPP connections (logical interfaces) are supported in a range of configurations.
For example, 63,999 PPP connections per chassis are supported when all
subscribers are configured on the same VLAN. In this case, 63,999 pp0 interfaces
are configured under the same VLAN logical interface and the one remaining
logical interface is consumed for the single VLAN.
At the other extreme, when you configure each subscriber on a separate VLAN
(using stacked VLANs), up to 32,000 PPP connections per chassis are supported.
28
■
In this case, each subscriber connection consumes two logical interfaces: one
for the VLAN logical interface and one for the pp0 logical interface.
The M120, M320, and MX Series routers support a maximum of 2000 different
dynamic profiles per chassis. [Subscriber Access]
■
Support for dynamic CoS for subscriber interfaces on Trio MPC/MIC interfaces
(MX Series routers)—Enables you to configure dynamic CoS for subscriber
interfaces on Trio MPC/MIC interfaces that are now available on MX Series routers.
In earlier releases, dynamic CoS was supported on EQ DPCs only.
To configure dynamic CoS on Trio MPC/MIC interfaces, you must enable the
hierarchical scheduler for an interface at the [edit interfaces] hierarchy level. You
can then configure dynamic CoS parameters at the [edit dynamic-profiles
profile-name class-of-service] hierarchy level. The CoS parameters are dynamically
applied to subscriber’s services when they log in or change services.
Trio MPC/MIC interfaces support CoS for the following interface types: static
VLAN, demux, static and dynamic PPPoE, and aggregated Ethernet subscriber
interfaces.
In this release, hierarchical CoS for aggregated Ethernet interfaces is supported
on the Trio MPC/MIC product when a static VLAN configured over the aggregated
Ethernet interface. It is not supported for static or dynamic demux subscriber
interfaces configured over aggregated Ethernet.
[Subscriber Access]
■
Support for CoS on dynamic PPPoE subscriber interfaces (MX Series
routers)—Enables you to configure CoS for dynamic PPPoE subscriber interfaces
on Trio MPC/MIC interfaces available on MX Series routers and the Intelligent
Queuing 2 (IQ2) PIC on M120 and M320 Series routers.
In earlier releases, only static CoS was supported for static PPPoE subscriber
interfaces configured on IQ2 PICs on M120 and M320 Series routers.
To configure CoS for a dynamic PPPoE interface, configure the shaping and
scheduling parameters at the [edit dynamic-profiles profile-name class-of-service]
hierarchy level. You then attach the traffic control profile to the dynamic PPPoE
interface by including the output-traffic-control-profile profile-name statement at
the [edit dynamic-profiles profile-name class-of-service interfaces
$junos-interface-ifd-name unit $junos-underlying-interface-unit] hierarchy level.
When the subscriber logs in, PPP supplies pp0 as the $junos-interface-ifd-name
variable, and supplies the PPPoE logical interface number for the
$junos-underlying-interface-unit variable.
[Subscriber Access]
■
Support for IPv6 for dynamic subscriber services (MX Series routers)—Enables
you to configure IPv6 addressing and prefixes for dynamic subscriber services.
In earlier releases, dynamic subscriber services supported IPv4 addressing only.
You can now configure both IPv4 and IPv6 addressing in the same dynamic
profile to grant access and services to IPv4 and IPv6 subscribers.
In this release, IPv6 addressing is supported for static and dynamic VLAN
subscriber interfaces and dynamic demux subscriber interfaces.
■
29
To enable IPv6 addressing for a static VLAN subscriber interface, include the
family inet6 statement at the [edit dynamic profiles profile-name interfaces
interface-name unit logical-unit-number] hierarchy level.
To enable IPv6 addressing for a demux subscriber interface, include the family
inet6 statement at the [edit dynamic profiles profile-name interfaces demux0]
hierarchy level. To enable an IPv6 source address for the interface, specify the
new $junos-subscriber-ipv6–address predefined variable with the demux-source
statement at the [edit dynamic profiles profile-name interfaces demux0 unit
$junos-interface-unit family inet6] hierarchy level. The values for this variable are
supplied to the interface by DHCP when the subscriber logs in.
This feature enables you to configure dynamic, classic, and fast update firewall
filters for IPv6 families. In addition, you can configure aggregate CoS when IPv4
and IPv6 families share a logical interface, and per-family CoS when IPv4 and
IPv6 families do not share a logical interface (such as a demux interface).
The following new predefined variables have been added to implement IPv6
addressing for subscriber services:
Dynamic Profile Variable
Definition
$junos-framed-route-ipv6-address-prefix
Route prefix of an IPv6 access route.
$junos-framed-route-ipv6-nexthop
Next-hop address of an IPv6 access route.
$junos-input-ipv6-filter
Attaches a filter based on RADIUS VSA 26-106 (IPv6-Ingress-Policy-Name)
to the interface.
$junos-ipv6-ndra-prefix
IPv6 prefix value used when configuring the Router Advertisement
protocol.
$junos-output-ipv6-filter
Attaches a filter based on RADIUS VSA 26-107 (IPv6-Egress-Policy-Name)
to the interface.
$junos-preferred-source-ipv6-address
Selects the preferred IPv6 source address associated with the loopback
address used for the subscriber.
$junos-subscriber-ipv6-address
IPv6 address of the subscriber.
RADIUS supports activation, deactivation, and change of authorization (CoA) for
IPv6 services. The following new RADIUS attributes and VSAs have been added
to implement IPv6 addressing for subscriber services:
Attribute Number
Attribute Name
97
Framed-IPv6-Prefix
99
Framed-IPv6-Route
26-106
IPv6-Ingress-Policy-Name
26-107
IPv6-Egress-Policy-Name
30
■
Attribute Number
Attribute Name
26-129
IPv6-NdRa-Prefix
26-151
IPv6-Acct-Input-Octets
26-152
IPv6-Acct-Output-Octets
26-153
IPv6-Acct-Input-Packets
26-154
IPv6-Acct-Output-Packets
26-155
IPv6-Acct-Input-Gigawords
26-156
IPv6-Acct-Output-Gigawords
26-157
IPv6-NdRa-Pool-Name
You can monitor IPv6 statistics by issuing the show subscribers and show
network-access aaa subscriber commands.
[Subscriber Access]
■
Support for dynamic PPPoE interfaces (M120, M320, and MX Series
routers)—Enables you to configure dynamically created PPPoE logical interfaces
over statically created underlying interfaces. For subscriber access purposes, the
dynamic PPPoE logical interface represents a dynamic PPPoE subscriber interface.
The router automatically and transparently creates the dynamic interface in
response to an external event, such as the receipt of traffic on an underlying
interface. For example, the router creates a dynamic PPPoE logical interface
when it receives a PPPoE Active Discovery Request (PADR) control packet from
the client on an underlying interface to which a PPPoE dynamic profile is
assigned. The router uses the information configured in the dynamic profile to
determine the properties of the dynamic PPPoE logical interface.
The use of dynamically created PPPoE interfaces gives you the flexibility of
having the router create the dynamic PPPoE logical interface only when the
subscriber logs in on the associated underlying interface. By contrast, statically
created interfaces always allocate and consume system resources upon interface
creation, even when no traffic is flowing on the interface. Configuring and using
dynamically created interfaces helps you effectively and conveniently manage
subscriber access networks that provide services to large numbers of subscribers.
Configuration of dynamic PPPoE logical interfaces is supported on Intelligent
Queuing 2 (IQ2) PICs on M120 and M320 Series routers, and on Trio MPC/MIC
interfaces on MX Series routers.
To configure a dynamic PPPoE logical interface:
1.
Configure a dynamic profile to define the attributes of the dynamic PPPoE
logical interface. To do so, include the following statements at the [edit
dynamic-profiles profile-name] hierarchy level:
dynamic-profiles {
profile-name {
■
31
interfaces pp0 {
unit $junos-interface-unit {
keepalives interval seconds;
no-keepalives;
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
ppp-options {
chap;
pap;
}
family inet {
unnumbered-address interface-name;
address address;
service {
input {
service-set service-set-name <service-filter filter-name>;
}
output {
service-set service-set-name <service-filter filter-name>;
}
}
filter {
input filter-name;
output filter-name;
}
}
}
}
}
}
You can use most of these same statements to configure statically created
PPPoE interfaces, with the following important differences. When you
configure a profile to dynamically create a PPPoE interface, you must specify
the $junos-interface-unit predefined dynamic variable instead of the actual
logical unit number for the unit statement, and the $junos-underlying-interface
predefined dynamic variable instead of the actual name of the underlying
interface for the underlying-interface statement.
2.
Assign the dynamic profile to the underlying interface on which the router
creates the dynamic PPPoE interface. To do so, include the
pppoe-underlying-options statement at the [edit interfaces interface-name unit
logical-unit-number] hierarchy level, as follows:
interfaces {
interface-name {
unit logical-unit-number {
encapsulation ppp-over-ethernet;
pppoe-underlying-options {
access-concentrator name;
dynamic-profile profile-name;
duplicate-protection;
max-sessions number;
}
32
■
}
}
}
The statements at the [edit interfaces interface-name unit logical-unit-number
pppoe-underlying-options] hierarchy level define the following PPPoE-specific
attributes for the underlying interface:
■
To provide an alternative access concentrator (AC) name in the AC-NAME
tag in a PPPoE control packet, include the access-concentrator statement.
■
To assign a previously configured dynamic profile to the underlying
interface, include the dynamic-profile statement. This is the only required
statement for configuring dynamic PPPoE interfaces at the [edit interfaces
interface-name unit logical-unit-number pppoe-underlying-options] hierarchy
level.
■
To prevent the activation of another dynamic PPPoE logical interface
on the same underlying interface on which a dynamic PPPoE logical
interface is already active for the same client, include the
duplicate-protection statement.
■
To configure the maximum number of dynamic PPPoE logical interfaces
(sessions) that the router can activate on the underlying interface, include
the max-sessions statement.
To display information about the dynamic PPPoE interface configuration, use
the show pppoe underlying-interfaces, show pppoe statistics, and show pppoe
interfaces operational commands. You can also use the clear pppoe statistics
command to clear packet statistics on the underlying interface.
[Subscriber Access]
■
Support for PPPoE Layer 3 wholesale configuration in a subscriber access
network—Enables you to configure PPPoE Layer 3 wholesaling within a
subscriber access network. Wholesale access is the process by which an access
network provider partitions the access network into separately manageable and
accountable subscriber segments for resale to other network providers. An access
network provider may elect to wholesale all or part of its network to one or more
service providers (retailers).
In a Juniper Networks subscriber access network, you accomplish Layer 3
partitioning through the use of logical systems (LSs) and routing instances. Logical
systems enable you to divide a physical router into separate, distinct, logical
administrative domains. This method of division enables multiple providers to
administer the router simultaneously and each have access to only the portions
of the configuration that are relevant to their specific logical system. The JUNOS
Software supports up to 15 named logical systems in addition to the default
logical system (inet.0).
Routing instances are typically used in Layer 3 VPN scenarios. A routing instance
does not have the same level of administrative separation as does a logical
system. The routing instance defines a distinct routing table, set of routing
policies, and set of interfaces, but it does not provide administrative isolation.
■
33
When configuring PPPoE Layer 3 wholesale for a subscriber access network,
keep the following in mind:
■
PPPoE Layer 3 wholesaling supports the use of only the default logical system
using multiple routing instances.
■
Each routing instance must contain a loopback with one or more addresses
to be used for the unnumbered interface. However, unlike configuring Layer
3 wholesale for DHCP, the loopback interface address does not have to be
within the same subnetwork as the client IP address.
■
The system ignores the preferred-source-address option for the
unnumbered-address statement when it is configured. To avoid confusion,
we recommend that you do not configure the preferred-source-address option
for the unnumbered-address statement when configuring an unnumbered
interface. However, the system will function appropriately, regardless of
whether or not you have configured the preferred-source-address option.
To configure PPPoE Layer 3 wholesale for a subscriber access network:
■
Include the routing-instances statement along with the $junos-routing-instance
dynamic variable at the [edit dynamic-profiles profile-name] hierarchy level.
■
Include the interface statement along with the $junos-interface-name dynamic
variable at the [edit dynamic-profiles profile-name routing-instances
“$junos-routing-instance”] hierarchy level.
■
Include the unnumbered-address statement along with $junos-loopback-interface
dynamic variable at the [edit dynamic-profiles profile-name interfaces pp0 unit
“$junos-interface-unit” family inet] hierarchy level.
To view the logical system and routing instance for each subscriber, use the show
subscriber operational command.
[Subscriber Access, Broadband Subscriber Management]
■
PPP PAP and CHAP enhancements for subscriber management (M120 and
M320 routers)—Subscriber management supports both bidirectional and
unidirectional PPP PAP and CHAP authentication.
In subscriber management, the router's PPP interface typically authenticates the
remote client (the subscriber). Bidirectional authentication is not usually used in
a subscriber management environment, even though it is supported for static
interfaces. Also, subscriber management uses AAA to authenticate subscribers,
which removes the need to specify an access profile or a default password for
PAP or CHAP authentication.
34
■
■
For static interfaces, the router supports bidirectional authentication. If you
do not include the passive statement in the configuration, the router functions
as the authenticator for remote clients. If you include the passive statement,
the router is authenticated by the remote client. Also, when you specify the
passive statement for static interfaces, you must specify other attributes, as
described in the JUNOS Network Interfaces Guide.
■
For dynamic interfaces, the router supports unidirectional authentication
only—the router always functions as the authenticator. When you configure
PPP authentication in a dynamic profile (at the [edit dynamic-profiles] hierarchy
level), the pap and chap statements do not support any additional
configuration options, including the passive statement. PPP dynamic
interfaces are supported only on PPPoE interfaces (interface pp0) for this
release.
To configure CHAP or PAP authentication for static interfaces, use the following
stanza:
[edit interfaces interface-name unit logical-unit-number]
ppp-options {
chap {
access-profile name;
default-chap-secret name;
local-name name;
passive;
}
pap {
access-profile name
default-pap-password password;
local-name name;
local-password password;
passive;
}
}
To configure CHAP or PAP authentication for dynamic interfaces, use the following
stanza:
[edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit]
ppp-options {
chap;
pap;
}
[Subscriber Access, Network Interfaces]
■
Support for input and output filters on the Trio MPC/MIC interfaces on MX
Series routers—Enables you to apply input and output filters to logical interfaces
that are running over the Trio MPC/MIC interfaces on MX Series routers.
To apply input and output filters for logical interfaces, include the input
input-filter-name and output output-filter-name statements. To apply these filters
statically, include the statements at the [edit interfaces interface-name unit
logical-unit-number filter] hierarchy level. To apply these filters dynamically, include
the statements at the [edit dynamic-profiles profile-name interfaces interface-name
unit “$junos-interface-unit” filter] hierarchy level. For information about how to
create filters, see the Policy Framework Configuration Guide.
[Subscriber Access, Network Interfaces, Policy Framework]
■
PPPoE interface support for subscriber secure policy traffic mirroring on Trio
MPC/MIC interfaces on MX Series routers—Enables you to configure subscriber
secure policy traffic mirroring to provide RADIUS-initiated mirroring for
subscribers on PPPoE interfaces that are running over Trio MPC/MIC interfaces
on MX Series routers.
■
35
For information about how to configure subscriber secure policy traffic mirroring,
see the Subscriber Access Configuration Guide.
[Subscriber Access]
■
Support for PPP/PPPoE subscriber interfaces on the Trio MPC/MIC family of
products (MX Series routers)—Enables you to configure PPP/PPPoE subscriber
interfaces that are running over the Trio MPC/MIC family of products when used
on MX Series routers. To configure PPP/PPPoE subscriber interfaces, you use
the statements and procedures that are described in the JUNOS Network Interfaces
Guide.
[Subscriber Access, Network Interfaces]
■
Support for demux VLAN interface configuration on Ethernet and aggregate
Ethernet Trio MPC/MIC interfaces—Enables the static or dynamic creation of
demux VLAN interfaces with an underlying interface of aggregate Ethernet or
Gigabit/10–Gigabit Ethernet.
When configuring static VLAN demux interfaces, specify a VLAN ID for the vlan-id
statement at the [edit dynamic-profiles profile-name interfaces demux0 unit
unit-number] hierarchy level. You must also specify the underlying device name
for the underlying-interface statement at the [edit dynamic-profiles profile-name
interfaces demux0 unit unit-number demux-options] hierarchy level.
When configuring dynamic VLAN demux interfaces, specify the VLAN ID variable
($junos-vlan-id) for the vlan-id statement at the [edit dynamic-profiles profile-name
interfaces demux0 unit unit-number] hierarchy level. You must also specify the
underlying device name variable ($junos-interface-ifd-name) for the
underlying-interface statement at the [edit dynamic-profiles profile-name interfaces
demux0 unit unit-number demux-options] hierarchy level.
In addition, keep the following in mind while configuring dynamic VLANs over
IP demux interfaces:
■
Only single VLAN and stacked VLAN tag options are supported as VLAN
selectors.
■
IP demux over IP demux stacking is not supported.
■
This support is limited to Trio MPC/MIC interfaces on MX Series routers.
[Subscriber Access]
System Logging
■
36
■
New and deprecated system log families and tags—The following system log
families are new in this release:
■
ALARMD—Describes messages with the ALARMD prefix. They are generated
by the alarm process (alarmd).
■
CONNECTION—Describes messages with the CONNECTION prefix. They
are generated whenever the alarm process is unable to connect to another
process.
■
FCD—Describes messages with the FCD prefix. They are generated by the
Fibre Channel process (fcd) which connects servers to disks and tape devices
in a storage area network.
■
GPRSD—Describes messages with the GPRSD prefix. They are generated by
the general packet radio service process (gprsd) that integrates with existing
GSM networks and offers mobile subscribers with packet-switched data
services access to corporate networks and the Internet.
■
LIBJSNMP—Describes messages with the LIBJSNMP prefix. They are generated
by the libjsnmp process.
■
UTMD—Describes messages with the UTMD prefix. They are generated by
the unified threat management process (utmd), which protects the network
from all types of attack.
■
WEBFILTER—Describes messages with the WEBFILTER prefix. They are
generated by the Web filtering process (webfilter), which allows you to
manage Internet usage by preventing access to inappropriate Web content.
The following system log messages are new in this release:
■
COSD_NULL_INPUT_ARGUMENT
■
DCD_GRE_CONFIG_INVALID
■
DCD_PARSE_ERROR_MAX_HIER_LEVELS
■
DCD_PARSE_ERR_INCOMPATIBLE_CFG
■
EVENTD_ALARM_CLEAR
■
EVENTD_TEST_ALARM
■
PFE_ANALYZER_CFG_FAILED
■
PFE_ANALYZER_SHIM_CFG_FAILED
■
PFE_ANALYZER_TABLE_WRITE_FAILED
■
PFE_ANALYZER_TASK_FAILED
■
PFE_COS_B2_ONE_CLASS
■
PFE_COS_B2_UNSUPPORTED
■
RPD_RA_CFG_CREATE_ENTRY_FAILED
■
RPD_RA_CFG_INVALID_VALUE
■
RPD_RA_DYN_CFG_ALREADY_BOUND
■
RPD_RA_DYN_CFG_INVALID_STMT
■
RPD_RA_DYN_CFG_SES_ID_ADD_FAIL
■
37
■
RPD_RA_DYN_CFG_SES_ID_MISMATCH
■
RPD_RT_CFG_BR_CONFLICT
The following system log messages are no longer documented:
■
DFWD_CONFIG_FW_UNSUPPORTED
■
LLDPD_PARSE_ARGS
■
LLDPD_PARSE_BAD_SWITCH
■
LLDPD_PARSE_CMD_ARG
■
LLDPD_PARSE_CMD_EXTRA
■
LLDPD_PARSE_USAGE
■
LPDFD_DYN_SDB_OPEN_FAILED
User Interface and Configuration
■
Enhanced support for up to 64 ECMP next hops for load balancing on M10i
routers with Enhanced CFEB, M320, M120, MX Series, and T Series Core
routers—The JUNOS Software supports configurations of 16, 32, or 64 equal-cost
multipath (ECMP) next hops for RSVP and LDP LSPs on M10i routers with an
Enhanced CFEB, and M320, M120, MX Series, and T Series routers. For networks
with high-volume traffic, this provides more flexibility to load-balance the traffic
over as many as 64 LSPs.
To configure the maximum limit for ECMP next hops, include the maximum-ecmp
next-hops statement at the [edit chassis] hierarchy level:
[edit chassis]
maximum-ecmp next-hops;
You can configure a maximum ECMP next-hop limit of 16, 32, or 64 using this
statement. The default limit is 16.
The following types of routes support the ECMP maximum next-hop configuration
for as many as 64 ECMP gateways:
38
■
■
Static IPv4 and IPv6 routes with direct and indirect next-hop ECMPs
■
LDP ingress and transit routes learned through associated IGP routes
■
RSVP ECMP next hops created for LSPs
■
OSPF IPv4 and IPv6 route ECMPs
■
ISIS IPv4 and IPv6 route ECMPs
■
EBGP IPv4 and IPv6 route ECMPs
■
IBGP (resolving over IGP routes) IPv4 and IPv6 route ECMPs
The enhanced ECMP limit of up to 64 ECMP next hops is also applicable for
Layer 3 VPNs, Layer 2 VPNs, Layer 2 circuits, and VPLS services that resolve
over an MPLS route, because the available ECMP paths in the MPLS route can
also be used by such traffic.
NOTE:
The following FPCs on M320, T640, and T1600 routers only support 16 ECMP next
hops:
■
(M320, T640, and T1600 routers only) Enhanced II FPC1
■
(M320, T640, and T1600 routers only) Enhanced II FPC2
■
(M320 and T640 routers only) Enhanced II FPC3
■
(T640 and T1600 routers only) FPC2
■
(T640 and T1600 routers only) FPC3
If a maximum ECMP next-hop limit of 32 or 64 is configured on an M320, T640, or
T1600 router with any of these FPCs installed, the Packet Forwarding Engines on
these FPCs use only the first 16 ECMP next hops. For Packet Forwarding Engines on
FPCs that support only 16 ECMP next hops, the JUNOS Software generates a system
log message if a maximum ECMP next-hop limit of 32 or 64 is configured. However,
for Packet Forwarding Engines on other FPCs installed on the router, a maximum
configured ECMP limit of 32 or 64 ECMP next hops is applicable.
To view the details of the ECMP next hops, issue the show route command. The
show route summary command also shows the current configuration for the
maximum ECMP limit. To view details of the ECMP LDP paths, issue the traceroute
mpls ldp command.
[System Basics, Policy Framework, Routing Protocols Command Reference]
■
Support for configuring time-based user access—The JUNOS Software enables
you to configure time-based restrictions for user access to log in to a device. This
is useful for restricting the time and duration of user logins for all users belonging
to a login class. You can specify the days of the week when users can log in, the
access start time, and the access end time.
■
To configure user access on specific days of the week, without any restrictions
on the duration of login, include the allowed-days statement only.
[edit system]
login {
class class-name {
allowed-days days-of-the-week;
}
■
To configure user access on all the days of the week for a specific duration,
include the access-start and access-end statements only.
[edit system]
■
39
login {
class class-name {
access-start HHMM;
access-end HHMM;
}
}
■
To configure user access on specific days of the week for a specified duration,
include the allowed-days, access-start, and access-end statements.
[edit system]
login {
class class-name {
allowed-days days-of-the-week;
access-start HHMM;
access-end HHMM;
}
}
[System Basics]
■
Dynamic IPv6 filters (MX Series routers)—Subscriber management now supports
dynamic IPv6 filters. The dynamic filter feature supports both classic and fast
update filters, and both IPv4 and IPv6.
You specify the filters in a dynamic profile, which associates the filter to an
interface. When the dynamic profile is triggered, the profile applies the filter to
an interface.
You use the filter statement at the [edit dynamic-profiles profile-name interfaces
interface-name unit logical-unit-number family (inet | inet6)] hierarchy level to
associate a dynamic profile to an interface.
[Subscriber Access, Policy Framework]
■
Support for classifiers and rewrite rules in dynamic subscriber-based CoS
(MX Series routers)—You can now associate classifiers and rewrite rules with a
subscriber interface in a dynamic profile. You must statically configure the
classifiers and rewrite rules at the static [edit class-of-service] hierarchy level.
To associate a classifier configuration with a subscriber interface in a dynamic
profile, include the classifiers statement at the [edit dynamic profiles profile-name
class-of-service interfaces interface-name unit logical-unit-number] hierarchy level.
The supported classifier types for subscriber interfaces are dscp, dscp-ipv6,
ieee-802.1, and inet-precedence.
To associate a rewrite-rule configuration with a subscriber interface in a dynamic
profile, include the rewrite-rules statement at the [edit dynamic profiles profile-name
class-of-service interfaces interface-name unit logical-unit-number] hierarchy level.
The supported rewrite rules for subscriber interfaces are dscp, dscp-ipv6,
ieee-802.1, and inet-precedence.
[Subscriber Access]
■
40
■
Dynamic configuration of the router advertisement protocol—In a network
deployment where router interfaces are configured statically, you might need
to configure the router advertisement protocol on only a small number of
interfaces on which it might run. However, in a subscriber access network, static
configuration of the router advertisement protocol becomes impractical because
the number of interfaces that potentially need the router advertisement protocol
increases substantially. In addition, deploying services in a dynamic environment
requires dynamic modifications to interfaces as they are created. To ensure that
dynamic interfaces are created with the ability to use the router advertisement
protocol, this release supports their configuration dynamically at the [edit
dynamic-profiles profile-name protocols] hierarchy level. The dynamic profile applies
router advertisement protocol configuration to dynamic interfaces as they are
created.
To minimally configure the router advertisement protocol, include the
router-advertisement statement at the [edit dynamic-profiles profile-name protocols]
hierarchy level, and the interface statement along with the $junos-interface-name
dynamic variable. All other statements are optional.
Optional router advertisement protocol statements include current-hop-limit,
default-lifetime, managed-configuration, max-advertisement-interval,
min-advertisement-interval, no-managed-configuration, no-other-stateful-configuration,
other-stateful-configuration, prefix, reachable-time, and retransmit-timer. All of these
statements appear at the [edit dynamic-profiles profile-name protocols
router-advertisement] hierarchy level.
NOTE: Statements used for router advertisement protocol configuration at the [edit
dynamic-profiles profile-name protocols] hierarchy level are identical in function to the
same statements used for static router advertisement protocol configuration, with
the exception of the interface and prefix statements which use dynamic variables.
[Subscriber Access]
Related Topics
■
■
Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers on
page 55
■
■
■
41
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series,
and T Series Routers
Class of Service
■
Forwarding class to queue number maps not supported on Multiservices link
services intelligent queuing (LSQ) interfaces—If you configure a forwarding
class map associating a forwarding class with a queue number, these maps are
not supported on Multiservices link services intelligent queuing (lsq-) interfaces.
[Class of Service]
Forwarding and Sampling
■
Enhancement to the show firewall command—The show firewall command now
supports a terse option that enables you to display only the names of firewall
filters. This option displays no other information about the firewall filters
configured on your system. Use the show firewall terse command to verify that
all the correct filters are installed.
[Routing Protocols and Policies Command Reference]
■
Disabling MAC address learning of neighbors through ARP or neighbor
discovery for IPv4 and IPv6 traffic for logical interfaces—The JUNOS Software
provides the no-neighbor-learn configuration statement at the [edit interfaces
interface-name unit interface-unit-number family inet] and [edit interfaces
interface-name unit interface-unit-number family inet6] hierarchy levels.
To disable ARP address learning for IPv4 traffic for a logical interface, include
the no-neighbor-learn statement at the [edit interfaces interface-name unit
interface-unit-number family inet] hierarchy level:
[edit interfaces interface-name unit interface-unit-number family inet]
no-neighbor-learn;
To disable neighbor discovery for IPv6 traffic for a logical interface, include the
no-neighbor-learn statement at the [edit interface interface-name unit
logical-unit-number family inet6] hierarchy level:
[edit interfaces interface-name unit interface-unit-number family inet6]
no-neighbor-learn;
[System Basics]
■
42
■
Enhancement to show oam ethernet link-fault-management detail command—The
output of the show oam ethernet link-fault-management detail command now
includes the following two new fields: OAM total symbol error event information
and OAM total frame error event information. These fields display the total number
of errored symbols and errored frames, respectively, and are updated at every
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
interval regardless of whether the threshold for sending event TLVs has been
crossed. Previously, the show oam ethernet link-fault management detail command
displayed only the number of errored symbols reported in TLV events transmitted
since the OAM layer was reset and the number of errored frames detected since
the OAM layer was reset.
[Interfaces Command Reference]
■
Enhancement to show oam ethernet connectivity-fault-management
commands—The output of the show oam ethernet connectivity-fault-management
mep-statistics, show oam ethernet connectivity-fault-management interfaces, and
show oam ethernet connectivity-fault-management mep-database commands
includes the following three new fields: Out of sync 1DMs received, which displays
the number of out of sync one-way delay measurement packets received; Valid
DMMs received, which displays the number of valid two-way delay measurement
request packets received, and Invalid DMMs received, which displays the number
of invalid two-way delay measurement request packets received.
■
Logical and physical Ethernet interface bandwidth—If you configure a
bandwidth on a logical Ethernet interface greater than the bandwidth configured
for the corresponding physical Ethernet interface, the commit fails. The bandwidth
of the logical interface should always be less than the bandwidth of the physical
interface. If you do not configure a bandwidth for the logical interface, it is
automatically set to the bandwidth configured for the physical interface.
■
Support for line-rate mode on 10-port 10-Gigabit Oversubscribed Ethernet
(OSE) PIC (T640, T1600, TX Matrix Plus routers)— Enables you to configure
the T640, T1600, and TX Matrix Plus routers to operate the 10-port 10-Gigabit
OSE PIC in line-rate mode, in which the OSE PIC disables oversubscription and
operates in line-rate mode. By default, the 10-port 10-Gigabit OSE PIC operates
in 2:1 oversubscription mode.
[System Basics]
■
New CoS information field added to the show interfaces extensive command
output—The output of the show interfaces extensive command now displays the
class-of-service queue allocation information of the physical interfaces (intelligent
queueing PICs such as IQ2 and so on) under the new class-of-service information
category. In the previous releases, the class-of-service queue allocation
information for physical interfaces was listed within the Packet Forwarding Engine
configuration category:
host@user# show interfaces extensive ge-7/1/3
Packet Forwarding Engine configuration:
Destination slot: 7
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Limit
0 best-effort
low
none
3 network-control
Buffer
Priority
%
95
bps
950000000
%
95
usec
0
5
50000000
5
0
■
43
low
none
Direction : Input
CoS transmit queue
Limit
0 best-effort
low
none
3 network-control
low
none
Bandwidth
Buffer
Priority
%
95
bps
950000000
%
95
usec
0
5
50000000
5
0
■
Restriction on compatibility-mode adtran and verilink—On 2-port and 4-port
channelized DS3 (T3) IQ interfaces, you cannot configure compatibility-mode
adtran, or verilink at the [edit interfaces interface-name t3-options] hierarchy level.
If configured, the default mode is applied on both the interfaces, that is, no
subrating.
■
Support for internal clocking mode on OSE PICs—The 10-port 10-Gigabit
Oversubscribed Ethernet (OSE) PIC supports only internal clocking mode on its
ports.
■
Commit-time warning messages at the [edit interfaces] hierarchy level are
now system logged—CLI commit-time warnings displayed for configuration at
the [edit interfaces] hierarchy level have been removed and are now logged as
system log messages. This change is applicable to JUNOS Release 10.1R1 and
later, 10.0R2, and 9.3R4. [CLI User Guide]
■
Invalid count of queues—The PD-5-10XGE-SFPP PICs in T Series routers do not
display ingress control queue statistics as output from the show interfaces queue
xe-fpc/pic/port forwarding-class command. However, you can use the following
commands to display the ingress control queue statistics:
■
show interfaces queue both-ingress-egress xe-fpc/pic/port
■
show interfaces queue xe-fpc/pic/port
■
show interfaces queue xe-fpc/pic/port ingress
■
Support for configuration of a range of interfaces through the interface-range
statement—Enables you to group a range of identical interfaces and apply a
common configuration for the interfaces using a reduced number of configuration
statements. To configure an interface-range group, include the interface-range
statement and substatements at the [edit interfaces] hierarchy level. To view an
interface range group in expanded configuration, use the show | display inheritance
command.
[Network Interfaces, Interfaces Command Reference]
■
44
■
Enhancement to the show chassis fabric fpcs command—In JUNOS Release
10.1 and later, the show chassis fabric fpcs command issued on a T640 or T1600
router displays destination errors in addition to link errors. The command output
displays a list of Packet Forwarding Engines that have destination errors, for
those SIBs that are in the Check state. This enhancement is also applicable to
JUNOS Release 9.6 and 10.0. The following sample shows the enhanced output
for this command:
user@host> show chassis fabric fpcs
Fabric management FPC state:
FPC #3
PFE #1
SIB #2
Plane enabled
SIB #3
Link error
Destination error on PFEs
6
8
20
0
1
2
3
4
5
14
15
16
17
18
19
0
1
2
3
4
5
14
15
16
17
18
19
7
9
10
11
12
13
21
SIB #4
Destination error on PFEs
6
7
20
21
8
9
10
11
12
13
[System Basics Command Reference]
■
Modification to the output of the show interfaces extensive command
output—For IQ2E interfaces, the show interfaces extensive command output no
longer displays the schedulers field, because there is no static scheduler
partitioning of schedulers among different ports in IQ2E.
■
Enhancement to the show chassis sibs command—The show chassis sibs
command now displays destination errors for SIBS in the Check state. In JUNOS
Release 10.1 and later and JUNOS Release 9.6 and 10.0, the command displays
the number of destination errors for SIBS in the Check state:
user@host> show chassis sibs
Slot State
0
Empty
1
Empty
2
Check (21 destination errors)
55 seconds
3
Check (0 destination errors)
45 seconds
4
Empty
Uptime
1 day, 1 hour, 32 minutes,
use "show chassis fabric fpcs" to determine which PFEs have destination
errors
■
45
However, for JUNOS Release 9.3 and 9.5, the command only displays the message
destination errors or no destination errors for a SIB that is in the Check state, but
does not display the number of destination errors:
user@host> show chassis sibs
Slot State
0
Empty
1
Empty
2
Check (destination errors)
55 seconds
3
Check (no destination errors)
45 seconds
4
Empty
Uptime
use "show chassis fabric fpcs" for more details
In addition, the command also displays a message to use the show chassis fabric
fpcs command for more information about the destination errors.
If there are no SIBs in the Check state, there is no change in the output of this
command.
Layer 2 Ethernet Services
■
Modification to the output of the show dhcp (relay or server) binding
commands—The output of the show dhcp server binding summary command,
the show dhcp relay binding summary command, and the show dhcpv6 server
binding command has been modified to include the number of clients in the init
state and the requesting state.
[Subscriber Access]
MPLS Applications
■
MPLS statistics file now optional—The file statement configured at the [edit
protocols mpls statistics] hierarchy level is now optional. You still must configure
the MPLS statistics statement to collect LSP statistics for the MPLS MIBs. Rather
than accessing the LSP statistics in the MPLS statistics file, you can view the
statistics using SNMP instead. This change helps to reduce disk space usage on
the routing engine, especially on routers on which numerous LSPs have been
configured.
[MPLS]
■
46
■
NSR tracing flags for MPLS—You can now configure MPLS tracing flags for
nonstop active routing (NSR) synchronization events. This enables you to track
the progress of NSR synchronization between Routing Engines and record these
operations to a log file. To configure, include the flag nsr-synchronization or flag
nsr-synchronization-detail statement at the [edit protocols mpls traceoptions]
hierarchy level. The two statements are not mutually exclusive; you can track
the events at a high level and in detail.
[High Availability, MPLS, Routing Protocols]
Multiplay
■
Border gateway function (BGF) improved efficiency and scalability through
use of service interface pools—You can now use service interface pools to
improve the maintainability and scalability of your service set configurations.
When your service sets handle VPN traffic, you must specify a service interface
pool for the next next-hop-service for the service sets. The interfaces that are
members of the pool can serve as either inside or outside interfaces.
You should also specify service interface pools as the next-hop service for service
sets that do not currently handle VPN traffic. You gain the immediate benefit of
more efficient resource utilization and you can add VPNs to the service set in
the future without reconfiguring your service sets.
[Multiplay Solutions]
Platform and Infrastructure
■
Enhancement to show interfaces command—The show interfaces command
includes a new field, INET6 Address flags, that displays a flag for any IPv6 address
that is in a state other than “permanent” or “ready-to-use.”
■
The ipsec-sa sa-name firewall filter action is no longer supported on the MX Series
routers. To configure one or more actions for a firewall filter, include the actions
statement at the [edit firewall family family-name filter filter-name term term-name
then] hierarchy level.
[Policy]
■
Enhanced match-conditions support for VPLS and bridge firewall filters (MX
Series routers and routers with Enhanced IQ2 [IQ2E] PICs only)—The protocol
families vpls and bridge now support the interface-set match condition for firewall
filters. To configure, include the interface-set interface-set-name statement at the
[edit firewall family bridge filter filter-name term term-name from] or the [edit firewall
family vpls filter filter-name term term-name from] hierarchy level. The protocol
family bridge is supported only on MX Series routers.
An interface set is a set of logical interfaces used to configure hierarchical class-ofservice schedulers. Previously only the following protocol families supported the
interface-set match condition: ipv4, ipv6, any, and mpls.
[Policy]
■
47
Routing Protocols
■
OSPF sham link—An OSPF sham link is now installed in the routing table as a
hidden route. Previously, an OSPF sham link was not installed in the routing
table. In addition, a BGP route is no longer exported to OSPF if a corresponding
OSPF sham link is available. To configure a sham link, include the sham-link local
ip-address statement at the [edit routing-instances routing-instance-name protocols
ospf] hierarchy level.
[Routing Protocols]
■
Removal of BGP warning message—If a BGP group is created without any
defined peers, the warning message no longer appears when the configuration
is committed.
[Routing Protocols]
■
Increase in limit to external paths accepted for BGP route target filtering—You
can now specify for BGP to accept up to 256 external paths for route target
filtering. Previously, the maximum number that you could configure was 16.
The default value remains one (1). To specify the maximum number of external
paths for BGP to accept for route target filtering, include the external-paths number
statement at the [edit protocols bgp family route-target] hierarchy level. This
statement is also supported for BGP groups and neighbors.
[Routing Protocols]
■
Support for having the algorithm that determines the single best path evaluate
AS numbers in AS paths for VPN routes—By default, the third step of the
algorithm that determines the active route evaluates the length of the AS path
but not the contents of the AS path. In some VPN scenarios with BGP multiple
path routes, it can also be useful to compare the AS numbers of the AS paths
and to have the algorithm select the route whose AS numbers match. Include
the as-path-compare statement at the [edit routing-instances routing-instance-name
routing-options multipath] hierarchy level.
[Routing Protocols]
■
Option to view APPID counters—Use the option under show services
application-identification counter to view the APPID counters for the specified
interface.
[System Basics and Services Command Reference]
■
Session offloading on Multiservices PICs—To enable session offloading on a
per-PIC basis for Multiservices PICs, include the session-offload statement at the
[edit chassis fpc] hierarchy level.
[System Basics]
■
Option to clear the “do not fragment” bit—To clear the “do not fragment” bit
for IPsec with dynamic endpoints, include the clear-dont-fragment-bit statement
at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.
48
■
■
Option to clear tunnel MTU—To clear the tunnel MTU, include the tunnel-mtu
statement at the [edit services ipsec-vpn rule rule-name term term-name then]
hierarchy level.
■
New configuration to avoid IDP traffic loss (M120, M320, and MX Series
routers)—When the Multiservices PIC or DPC configured for a service set is either
administratively taken offline or undergoes a failure, all the traffic entering the
configured interface with an IDP service set would be dropped without
notification. To avoid this traffic loss, include the bypass-traffic-on-pic-failure
statement at the [edit services service-set service-set-name service-set-options]
hierarchy level and (for TCP traffic only) the ignore-errors tcp statement at the
[edit interfaces interface-name services-options] hierarchy level. When you configure
these statements, the affected packets are forwarded in the event of a
Multiservices PIC or DPC failure or going offline, as though interface-style services
were not configured. This issue applies only to M120, M320, and MX Series
routers.
■
M120 router performance with IDP—For M120 routers, the performance number
is 4500 connections per second when IDP is enabled.
■
Enhancement to the output of the show services accounting commands—The
output for the show services accounting usage, show services accounting status,
show services accounting memory, and show services accounting errors operational
mode commands has been updated to include new fields for use in querying
service PICs.
■
Default idle timeout value for UDP- and TCP-based applications—Upon
identification by AppID, the default idle timeout value is set to 30 seconds for
UDP-based applications and 1 hour for TCP-based applications. These settings
can be overridden by including the idle timeout statement at the [edit services
application-identification application application] hierarchy level.
■
New statement to bypass traffic on exceeding flow limit—If the flow in the
service-set crosses the maximum limit set by the max-flow statement, the
bypass-traffic-on-exceeding-flow-limits allows the packets to bypass without
creating a new session. Following are the required privilege levels:
■
interface—To view the statement in the configuration
■
interface-control—To add the statement to the configuration
■
Diffie-Hellman group5 added to group1 and group2—The group5 designation
specifies that IKE should use the 1536-bit Diffie-Hellman prime modulus group
when performing the new Diffie-Hellman exchange. To configure the
Diffie-Hellman group for an IKE proposal, include the dh-group statement at the
[edit services ipsec-vpn ike proposal proposal-name] hierarchy level:
■
49
[edit services ipsec-vpn ike proposal proposal-name]
dh-group (group1 | group2| group5);
■
Permanent limitation for session-timeout on APPID—If session-timeout is
configured for an APPID application, a session for that application will be cleared
once the session-timeout expires. Once the same session is re-created as a new
session, it will not be identified by APPID.
■
Integrated Multi-Services Gateway (IMSG)—The clear services
border-signaling-gateway gateway-name statistics command no longer clears the
active calls counter.
■
New configuration statements for assigning policies—The following
configuration statements at the [edit services border-signaling-gateway gateway-name
service-point service-point-name service-policies] hierarchy level have been
deprecated and replaced by new statements:
■
new-call-usage-policies [policy-and-policy-set-names]
■
new-transaction-policies [policy-and-policy-set-names]
Each statement applied policies to calls or transactions entering at the service
point. Each is replaced by statements that explicitly apply policies to transactions
or policies entering the service point or exiting from the service point. The new
statements are:
■
new-call-usage-input-policies [policy-and-policy-set-names]
■
new-call-usage-output-policies [policy-and-policy-set-names]
■
new-transaction-input-policies [policy-and-policy-set-names]
■
new-transaction-output-policies [policy-and-policy-set-names]
[Services Interfaces, System Basics and Services Command Reference]
■
Requirement for client-to-servicer and server-to-client signatures—For certain
applications that have signatures for both client-to-server and server-to-client
directions, APPID (DAA) needs to see the data packets in both directions on the
same session to finish the identification process. For example, for SIP proxy
calls, the server may not send the response on the same session (different
destination port) and that session will not be identified as application junos:sip.
■
Integrated Multi-Services Gateway (IMSG) maximum number of policies and
policy-related entities per Border Signaling Gateway (BSG)—The following
table shows the maximum number of policies and related entities.
Entity
Maximum
Policies (total of new call usage and new transaction policies) per BSG
750
50
■
Entity
Maximum
New call usage policies per BSG
500
New transaction policies per BSG
500
Policies per service point
10
Service points per BSG
100
Terms per policy
20
Terms per BSG
10,000
Total of AND and OR operators in a policy term
4
[Session Border Control Solutions]
■
Enabling and disabling DHCP snooping support—You can now explicitly enable
or disable DHCP snooping support on the router. If you disable DHCP snooping
support, the router drops snooped DHCP discover and request messages.
To enable DHCP snooping support, include the allow-snooped-clients statement
at the [edit forwarding-options dhcp-relay overrides] hierarchy level. To disable
DHCP snooping support, include the no-allow-snooped-clients statement at the
[edit forwarding-options dhcp-relay overrides] hierarchy level. Both statements are
also supported at the named group level and per-interface level.
In JUNOS Release 10.0 and earlier, DHCP snooping is enabled by default. In
release 10.1 and later, DHCP snooping is disabled by default.
[Subscriber Access]
■
RADIUS interim accounting—When subscriber management receives the
RADIUS Acct-Interim-Interval attribute (attribute 85), RADIUS interim accounting
is performed based on the value in the attribute. The router uses the following
guidelines:
■
Attribute value is within the acceptable range (10 to 1440
minutes)—Accounting is updated at the specified interval.
■
Attribute value of 0—No RADIUS accounting is performed.
■
Attribute value is less than the minimum acceptable value (10
minutes)—Accounting is updated at the minimum interval.
■
Attribute value is greater than the maximum acceptable value (1440
minutes)—Accounting is updated at the maximum interval.
In previous releases, a RADIUS attribute set to zero (0) prevented subscribers
from connecting.
[Subscriber Access]
■
51
■
Restriction on the usage of the annotate command in the configuration
hierarchy—The JUNOS Software supports annotation of the configuration using
the annotate command up to the last level in the configuration hierarchy.
However, annotation of the configuration options or statements within the last
level in the hierarchy is not supported. For example, in the following sample
configuration hierarchy, annotation is supported up to the level 1 parent hierarchy,
but is not supported for the metric child statement:
[edit protocols]
isis {
interface ge-0/0/0.0 {
level 1 metric 10;
}
}
}
[CLI User Guide]
■
Support for accounting is restricted to events and operations on a master
Routing Engine—Starting with JUNOS Release 9.3, accounting for backup Routing
Engine events or operations is not supported on accounting servers such as
TACACS+ or RADIUS. Accounting is only supported for events or operations on
a master Routing Engine.
[CLI User Guide]
■
Options added to the show arp command—The vpn and logical-system options
have been added to the show arp command.
■
Change in range of the saved-core-files configuration statement—The range
of the saved-core-files configuration statement at the [edit system] hierarchy level
has been revised from 1 through 64, to 1 through 10.
[System Basics]
VPNs
■
SCU support for VRF routing instances with vrf-table-label configured—You
can now configure source class usage (SCU) to count packets on Layer 3 VPNs
configured with the vrf-table-label statement. Include the source-class-usage
statement at the [edit routing-instances routing-instance-name vrf-table-label]
hierarchy level. The source-class-usage statement at this hierarchy level is
supported only for the virtual routing and forward (VRF) instance type. Previously,
you could not enable SCU when the vrf-table-label statement was configured.
Destination class usage (DCU) is not supported when the vrf-table-label is
configured.
[VPNs, Network Interfaces]
■
52
■
Mirroring IRB packets as Layer 2 packets (MX Series router)—If you associate
an IRB with the bridge domain (or VPLS routing instance), and also configure
within the bridge domain (or VPLS routing instance) a forwarding table filter with
the port-mirror or port-mirror-instance action, then the IRB packet is mirrored as
a Layer 2 packet. You can disable this behavior by configuring the
no-irb-layer-2-copy statement in the bridge domain (or VPLS routing instance).
[MX Series Layer 2 Configuration]
■
Layer 2 circuits, call admission control (CAC), and bypass LSPs—You can now
configure CAC on Layer 2 circuit-based LSPs with bandwidth constraints and
also enable link and node protection. However, if the primary LSP fails, CAC
might not be applied to the bypass LSP, meaning that the bypass LSP might not
meet the bandwidth constraint for the Layer 2 circuit. To minimize the risk of
losing traffic, the Layer 2 circuit continues to use the non-CAC bypass LSP while
an attempt is made to establish a new Layer 2 circuit route over an LSP that does
support CAC. Previously, the Layer 2 circuit route was deleted if the bypass LSP
did not have sufficient bandwidth.
[VPNs]
■
Service VLANs and the use of vlan-id all statement in a VPLS routing
instance—If you configure the vlan-id all statement in a VPLS routing instance,
we recommend using the input-vlan-map pop and output-vlan-map push statements
on the logical interface to pop the service VLAN ID on input and push the service
VLAN ID on output and in this way limit the impact of doubly-tagged frames on
scaling.
[MX Series Layer 2 Configuration]
■
Layer 2.5 VPNs support ISO family and MPLS family over TCC (MX Series
routers)—JUNOS Release 8.3 introduced support for M320 and T Series routers.
JUNOS Release 10.1 extends support to MX Series routers.
Interfaces supporting TCC (Ethernet, extended VLANs, PPP, HDLC, ATM, and
Frame Relay) support ISO traffic and MPLS traffic on Layer 2.5 VPNs. Previously,
Layer 2.5 VPNs configured on MX Series routers supported only inet traffic. For
a protocol to be supported on a Layer 2.5 VPN, you must configure both ends
of the VPN with the protocol configuration. IPv6 is not supported.
To enable ISO or MPLS traffic over TCC, include the mpls or iso statement at the
[edit interfaces interface-name unit logical-unit-number family tcc protocol] hierarchy
level. To display which protocol is supported for an interface, issue the show
interfaces interface-name extensive operational mode command. The protocol is
displayed in the Flags field.
To enable ISO over TCC in cases in which the Ethernet interface is on a
customer-edge (CE) router, include the point-to-point statement at the [edit
protocols isis interface interface-name] hierarchy level on the CE router. When
you include this statement, the IS-IS protocol treats the Ethernet interface as
point to point, even though the actual interface is a LAN interface.
The M Series routing platforms continue to support only inet traffic for Layer 2.5
VPNs.
[Network Interfaces, Translational Cross-Connect and Layer 2.5 VPNs Feature Guide,
VPNs]
■
New configuration statement for removing dynamically learned MAC
addresses from the MAC address database—Media access control (MAC) flush
processing removes MAC addresses from the MAC address database that have
■
53
been learned dynamically. With the dynamically learned MAC addresses removed,
MAC address convergence requires less time to complete.
In this release, you enable MAC flush processing for the virtual private LAN
service (VPLS) routing instance or for the mesh group under a VPLS routing
instance by using the mac-flush statement instead of the mac-tlv-receive and
mac-tlv-send statements.
mac-flush [ explicit-mac-flush-message-options ];
To clear dynamically learned MAC addresses globally across all devices
participating in the routing instance, you can include the statement at the
following hierarchy levels:
■
[edit logical-systems logical-system-name routing-instances routing-instance-name
protocols vpls]
■
[edit routing-instances routing-instance-name protocols vpls]
To clear the MAC addresses on the routers in a specific mesh group, you can
include the statement at the following hierarchy levels:
■
[edit logical-systems logical-system-name routing-instances routing-instance-name
protocols vpls mesh-group mesh-group-name]
■
[edit routing-instances routing-instance-name protocols vpls
mesh-group mesh-group-name]
NOTE: The mac-tlv-receive and mac-tlv-send statements were removed from
Release 10.0 of the JUNOS Software and are no longer visible in the [edit
logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]
and [edit routing-instances routing-instance-name protocols vpls] hierarchy levels.
Although the mac-tlv-receive and mac-tlv-send statements are recognized in the current
release, they will be removed in a future release. We recommend that you update
your configurations and use the mac-flush statement.
To also configure the router to send explicit MAC flush messages, you can include
explicit-mac-flush-message-options with the statement:
■
any-interface—(Optional) Send a MAC flush message when any
customer-facing attachment circuit interface goes down.
■
any-spoke—(Optional) Send a MAC FLUSH-FROM-ME flush message to all
provider edge (PE) routers in the core when one of the spoke pseudowires
between the multitenant unit switch and the other network-facing provider
edge (NPE) router goes down, causing the multitenant unit switch to switch
to the this NPE router.
54
■
Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
NOTE: This option has a similar effect in a VPLS multihoming environment with
multiple multitenant unit switches connected to NPE routers, where both multitenant
unit switches have pseudowires that terminate in a mesh group with local-switching
configured. If the any-spoke option is enabled, then both PE routers send MAC
FLUSH-FROM-ME flush messages to all PEs in the core.
■
propagate—(Optional) Propagate MAC flush to the core.
[VPNs]
Related Topics
■
on page 6
■
page 55
■
■
The current software release is Release 10.1R4. For information about obtaining the
software packages, see “Upgrade and Downgrade Instructions for JUNOS Release
10.1 for M Series, MX Series, and T Series Routers” on page 113.
■
Current Software Release on page 55
■
Previous Releases on page 79
Current Software Release
Outstanding Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series
Routers
Class of Service
■
On MX Series routers with Enhanced DPCs, bandwidth sharing between two
schedulers, one with high and the other with strict-high priority, might not be
as expected when the schedulers are oversubscribed. That is, only one queue
can use all of the excess bandwidth. This issue occurs when the schedulers are
configured on logical interfaces. [PR/265603]
■
Under certain conditions, the class-ofservice configuration might not take effect
on an Intelligent Queuing 2 (IQ2) PIC. [PR/541814]
■
55
■
A high CPU utilization by the DFWD process might occur if the interface lo0 is
configured as part of interface group 0. [PR/497242]
■
The numerical values configured for the ip-options match criteria on a firewall
filter matches any ip-options no matter what is specified. [PR/516778]
■
The BGP process changes in a committed import policy using a background job.
If the BGP is already in the process of updating its routes from a change in the
import policy, and the import policy is subsequently changed in another commit,
the second commit's policy might not complete correctly. As a workaround,
ensure that there are no outstanding BGP reconfiguration jobs in progress prior
to committing a new import policy. This can be verified using the show task jobs
command and searching for BGP Reconfig. [PR/550902]
■
The routing protocol process crashes and does not start if the policy condition
is enabled for IPv6. As a workaround, remove the policy condition for IPv6 from
the configuration and restart the routing protocol process. [PR/553158]
■
The SSH keys are not in sync between the master and backup Routing Engine
when SSH is enabled after a graceful Routing Engine switchover (GRES).
[PR/455062]
■
When an ISSU upgrade is performed to or from JUNOS Releases 9.6R3 or 10.0R2,
the logical interface and logical interface sets that have traffic control profiles
configured on them will be affected. [PR/491834]
■
For Automatic Protection Switching (APS) on SONET/SDH interfaces, there are
no operational mode commands that display the presence of APS mode
mismatches. An APS mode mismatch occurs when one side is configured to use
bidirectional mode, and the other side is configured to use unidirectional mode.
[PR/65800]
■
The output of the show interfaces diagnostics optics command includes the "Laser
rx power low alarm" field even if the transceiver is a type (such as 1x10-Gigabit
Ethernet) that does not support this alarm. [PR/103444]
■
When the Rx power level is a negative value, the SFP diagnostics output displays
an invalid receiver power level reading. [PR/235771]
■
When an ATM II interface is configured as a Layer 2 circuit with cell transport
mode on a router running JUNOS Release 8.2 or earlier, interoperability issues
with other network equipment and other Juniper Networks routers running
JUNOS Release 8.3 or later might occur. [PR/255622]
General Routing
High Availability
56
■
■
On the M120 router, hot swapping the fan tray might cause the Check CB alarm
to activate. [PR/268735]
■
On the JCS1200 platform, when you issue the clear -config -T switch[1] command
using the management module, the switch module returns to its factory default
setting instead of the Juniper Networks default setting. As a workaround, do not
issue the command. [PR/274399]
■
On the Juniper Control System (JCS) platform, the control and management
traffic for all Routing Engines shares the same physical link on the same switch
module. In rare cases, the physical link might become oversubscribed, causing
the management connection to Protected System Domains (PSDs) to be dropped.
[PR/293126]
■
The bridge-domain MAC learn limit on the Packet Forwarding Engine can
sometimes become negative if the bridge domain is deleted and added
immediately as part of a configuration change. If that happens, the MAC learning
on that bridge domain can be affected. As a workaround, deactivate and activate
the bridge domain or VPLS routing instance configuration. [PR/467549]
■
Due to a larger number of components on the MX480 board, it takes more time
to boot up than a comparable MX Series boards. [PR/468665]
■
If a firewall show command is followed by the clear command in a very quick
succession, there is a possibility that the show command will time out. If the
show command is issued after a few seconds (5 seconds ideally), this issue will
not be seen. [PR/479497]
■
With JUNOS Releases 10.0 and 10.1, Trio DPCs do not support more than 31
remote PEs in a VPLS instance. Also, they do not support more than 31 AE
bridging logical interfaces in a bridge domain. [PR/488139]
■
When trigger hold timer UP/DOWN values for a defect condition is configured
or changed from the CLI, the up or down timer for the defect is started, based
on the current defect condition in the hardware. If the timer value is large enough
and the defect condition is changed in the hardware when the timer is still
running, a new defect will be reflected in the alarms only after the timer has
expired. [PR/509890]
■
Under certain conditions, some Packet Forwarding Engines may fail to install
VPN multicast routes when downstream interfaces are RLSQ bundles.
[PR/515878]
■
When a SIB is taken offline via a CLI command, the output of the show chassis
sibs command does not display the message “Offlined by cli command.”
However, this message is correctly displayed for the FPCs. [PR/519842]
■
The output of the show chassis environment pem command displays the voltage
used in FPC slots 0 through 3, even after the FPC is taken offline. [PR/528821]
■
If no dot1p classifier is explicitly configured for the logical interface of vid=0,
to accept priority tagged packets, packets without an IP header such as STP will
determine the forwarding class based on the priority tag value. [PR/529207]
■
The output of the show chassis hardware detail | display xml command does not
list the SSRAM modules as direct chassis-sub-modules of the SFM x SPR.
[PR/529277]
■
57
■
A CFM ping command fails when the maintenance domain or maintenance
association is longer than 32 characters. [PR/550014]
■
A destination error occurs when an active SCB plane is unplugged. [PR/555250]
■
In previous Ethernet OAM 802.1ag implementation, an extra 8 bytes (0019 0008
0000 0000) is found in the CFM delay measurement reply (DMR) and loopback
reply (LBR) messages when compared with the original delay measurement
message (DMM) and loopback message (LBM). The extra bytes do not impact
the normal DMM and DMR, or LBM and LBR processing. [PR/557513]
■
DHCP packets may not be processed on an auto-sensed VLAN interface if the
DHCP configuration for the interface is performed after the auto-sensed VLAN
interface is instantiated. As a workaround, clear the auto-sensed VLAN interface(s)
after the DHCP configuration is made for the interface(s). [PR/417958]
■
Configuring passive clients to run on demultiplexer interfaces does not result in
the access-internal route pointing to the client demultiplexer interface as expected.
When configuring passive clients on demultiplexer interfaces, keep the following
in mind:
■
Configuring passive clients on demultiplexer interfaces requires specific
static route additions to function properly.
■
Only unnumbered demultiplexer is supported. However, the underlying
interface can be either numbered or unnumbered.
When configuring passive clients over demultiplexer interfaces by using
unnumbered underlying interfaces, you must add static routes for both the
client-facing and DHCP server-facing interfaces on the router as follows:
■
The configuration for the server-facing interface must contain the route IP
address of the DHCP relay agent and the qualified next-hop interface value
to the server.
■
The configuration for the client-facing interface must contain the link address
for the next-hop IP address of the server-facing interface and be configured
to resolve that IP address.
When configuring passive clients over demultiplexer interfaces by using numbered
underlying interfaces, you must add a static route such that the client-facing
interface configuration contains a next-hop address that points to the DHCP
server-facing interface on the router. [PR/511676]
■
58
■
On a TX Matrix router, an aggregate bundle composed of member links from
different LCCs has the same slot/PIC/port, and results in duplication of Link
Aggregation Control Protocol (LACP) port numbers. For example, a bundle with
actor and partner shown below will result in a duplicate LACP port number since
ge-0/3/0 and ge-8/3/0 (and similarly ge-1/3/0 and ge-9/3/0) are the same
slot/PIC/port but from different LCCs.
Actor
ge-0/3/0
ge-8/3/0
Partner
ge-1/3/0
ge-9/3/0
On MX960 routers, duplicate LACP port numbers will result in aggregate bundles
composed of member links for the same PIC and port on slots (0, 8), (1,9), (2,10),
and (3,11). Also, the following sets of ports on any slot will have duplicate LACP
port numbers:
■
PIC 0 port 8 and PIC 1 port (0,8)
■
■
■
NOTE: The duplicate LACP port number described above does not affect the
aggregation, but affects the SNMP extracting port information and shows an identical
pair of SNMP dot3adAggPortPartnerOperPort and dot3adAggPortActorPort for the
above mentioned links of the aggregate bundle.
[PR/526749]
■
The PIM neighborship does not come up over the irb interface after the DPC is
restarted. [PR/559101]
■
The SNMP process might restart when a core dump is generated. [PR/517230]
■
The use-mac-address option that is used to generate the SNMP engine-id does not
work. [PR/557569]
■
The SNMP process dumps core when snmpget or snmpget-next is used for SNMPv3
with security parameters that have variables that might result in a large error
response. As a workaround, use a smaller PDU and fewer variables in SNMPv3
with authentication. [PR/559166]
■
The rt column in the output of the show mpls lsp command and the active route
counter in the output of the show mpls lsp extensive command are incorrect
when the per-packet load balancing is configured. [PR/22376]
■
For point-to-multipoint label-switched paths (LSPs) configured for VPLS, the ping
mpls command reports a 100 percent packet loss even though the VPLS
connection is active. [PR/287990]
■
When a Layer 2 circuit uses a static LSP as the tunnel between the PE routers,
and traffic is switched to an ingress bypass LSP, the statistics for both the primary
LSP and the bypass LSP should be updated. However, the statistics are now
updated only for the primary LSP. As a workaround, use the set protocols mpls
Network Management
MPLS Applications
■
59
traffic-engineering mpls-forwarding command to update the statistics for both the
primary and bypass LSPs. [PR/495002]
■
During an RSVP local repair process, when a link flaps or the IGP metric changes
along the LSP path, the routing protocol process scheduler slips. [PR/513312]
■
When a commit is performed, the RSVP path messages are clustered together
for a link- or node-protected interface from the current RSVP implementation.
This might result in dropped RSVP path messages on the neighboring Juniper
Networks routers as the queue for these packets becomes overwhelmed.
[PR/536190]
■
When a large number of point-to-multipoint LSPs exist during periods of high
network instability with many links flapping, and MBB rerouting of a
point-to-multipoint LSP occurs, an MPLS route can become stale. This can cause
a routing protocol process assertion failure on a transit router. [PR/555219]
■
On T Series routers, a Layer 2 maximum transmission unit (MTU) check is not
supported for MPLS packets exiting the routing platform. [PR/46238]
■
When you configure a source class usage (SCU) name with an integer (for
example, 100) and use this source class as a firewall filter match condition, the
class identifier might be misinterpreted as an integer, which might cause the
filter to disregard the match. [PR/50247]
■
If you configure 11 or more logical interfaces in a single VPLS instance, VPLS
statistics might not be reported correctly. [PR/65496]
■
When a large number of kernel system log messages are generated, the log
information might become garbled and the severity level could change. This
behavior has no operational impact. [PR/71427]
■
In the situation where a Link Services (LS) interface to a CE router appears in
the VPN routing and forwarding table (VRF table) and a fragmentation is required,
Internet Control Message Protocol (ICMP) cannot be forwarded out of the LS
interface from a remote PE router that is in the VRF table. As a workaround,
include the vrf-table-label statement at the [edit routing-instances
routing-instance-name] hierarchy level. [PR/75361]
■
Traceroute does not work when ICMP tunneling is configured. [PR/94310]
■
If you ping a nonexistent IPv6 address that belongs to the same subnet as an
existing point-to-point link, the packet loops between the two point-to-point
interfaces until the time-to-live expires. [PR/94954]
■
On T Series and M320 routers, multicast traffic with the "do not fragment" bit
is being dropped due to configuring a low MTU value. The router might stop
forwarding all traffic transiting this interface if the clear pim join command is
executed. [PR/95272]
■
A firewall filter that matches the forwarding class of incoming packets (that is,
includes the forwarding-class statement at the [edit firewall filter filter-name term
term-name from] hierarchy level) might incorrectly discard traffic destined for the
Routing Engine. Transit traffic is handled correctly. [PR/97722]
60
■
■
The JUNOS Software does not support dynamic ARP resolution on Ethernet
interfaces that are designated for port mirroring. This causes the Packet
Forwarding Engine to drop mirrored packets. As a workaround, configure the
next-hop address as a static ARP entry by including the arp ip-address statement
at the [edit interfaces interface-name] hierarchy level. [PR/237107]
■
When you perform an in-service software upgrade (ISSU) on a routing platform
with an FPC3 or an Enhanced FPC3 with 256 MB of memory and the number
of routes in the routing table exceeds 750,000, route loss might occur. If route
loss occurs, as a workaround, perform either of the following tasks:
■
Replace the FPC3 or Enhanced FPC3 with another FPC that has more
memory, or
■
After the ISSU is complete, reboot only the FPC3 or Enhanced FPC3.
[PR/282146]
■
For Routing Engines rated at 850 MHz (which appear as RE-850 in the output of
the show chassis hardware command), messages like the following might be
written to the system log when you insert a PC Card: “bad Vcc request” and
“Device does not support APM.” Despite the messages, operations that involve
the PC card work properly. [PR/293301]
■
On a Protected System Domain, an FPC might generate a core file and stop
operating under the following conditions:
■
A firewall policer with a large number of counters (for example, 20,000) is
applied to a shared uplink interface, and
■
The FPC that houses the interface does not have a sufficiently powerful CPU.
As a workaround, reduce the number of counters or install a more powerful FPC.
[PR/311906]
■
When a CFEB failover occurs on an M10i or M7i router that has had 4000 or
more IFLs, the following message appears:
IFRT: 'IFD ioctl' (opcode 10) failed
ifd 153; does not exist
IFRT: 'IFD Ether autonegotiation config' (opcode 163) failed
The message has no operational impact. When the backup CFEB becomes the
active CFEB, the message will not display. [PR/400774]
■
When the show route forwarding-table family vpls vpn vpls-name command is used,
the following message is logged in the log file: “/kernel: rtsock: received msg 0
with version 0, expected 96, a reboot or upgrade may be required (proc =
rtinfo).” This is because the rtinfo utility does not fill the message version in the
message buffer that is sent to the kernel. [PR/443413]
■
In some cases, the alarms displayed in FPM and the alarms shown using the
show chassis alarms sfc 0 command mismatch. [PR/445895]
■
The SFC management interface em0 is often displayed as fxp0 in several warning
messages. [PR/454074]
■
On M Series and T Series routers, the kernel crashes when graceful Routing
Engine switchover (GRES) is turned on. [PR/463099]
■
61
■
The VPN label does not get pushed on the label stack for Routing
Engine–generated traffic with l3vpn-composite-next-hop activated. As a
workaround, configure per-packet load balancing to push the VPN/tunnel labels
correctly. [PR/472707]
■
On restarting with a large-scale configuration (16,000 logical interfaces per MPC),
the MPC-3D-16XGE-SFPP card may take up to 15 minutes to come up.
[PR/478548]
■
Swapping out eight FPC cards and replacing them with a different FPC type
causes the kernel to crash when the last FPC is powered on. [PR/502075]
■
The tty sessions to a router can cause a null pointer de-reference. [PR/502816]
■
The TTL for a GRE-encapsulated IPv6 packet malfunctions as the TTL on the wire
is one less than the CLI-configured tunnel TTL. [PR/506454]
■
In an MPLS environment, the source Network Address Translation (NAT) or Port
Address Translation (PAT) for traffic between two remote VPNs does not work
when the vrf-table-label option is removed from the VRF where the inside-service
interfaces are located. [PR/524294]
■
After the Multiservices PIC’s homing PE interfaces used for multicast VPN (MVPN)
are taken offline and brought back online, the following message might be logged:
“flip-re0 fpc3 SLCHIP(0): %PFE-3: Channel 8189 (iif=701) on stream 32 already
exists.” [PR/527813]
62
■
■
If a routing protocol running an MSDP receives an SA that is filtered via the MSDP
import policy, it will still create a forwarding entry if it subsequently receives a
(*,G) join for that group. [PR/63053]
■
The following features are not supported in a 12-16x10G DPC:
■
Known unicast and unknown unicast types in the input match condition
'Traffic-type' in a family bridge/VPLS
■
The following match conditions do not work:
■
learn-vlan-1p-priority
■
learn-vlan-1p-priority-except
■
learn-vlan-id
■
learn-vlan-id-except
■
user-vlan-1p-priority
■
user-vlan-1p-priority-except
■
user-vlan-id
■
user-vlan-id-except
■
VPLS flood FTF and input FTF
■
Simple filters
■
Filter action 'then ipsec-sa'
■
Filter action 'then next-hop-group'
■
Mac-filter output accounting and output policing
[PR/466990]
Routing Protocols
■
When you configure damping globally and use the import policy to prevent
damping for specific routes, and a new route is received from a peer with the
local interface address as the next hop, the route is added to the routing table
with default damping parameters, even though the import policy has a non-default
setting. As a result, damping settings do not change appropriately when the route
attributes change. [PR/51975]
■
When you issue the show ldp traffic-statistics command, the following system
log message might be generated for all forwarding equivalence classes (FECs)
with an ingress counter set to zero: "send rnhstats GET: error: ENOENT — Item
not found." [PR/67647]
■
If ICMP tunneling is enabled on the router and you configure a new logical system
that does not have ICMP tunneling enabled, the feature is globally disabled.
[PR/81884]
■
The keepalive timeout counter for multicast sessions may not display after you
deactivate and activate the pim protocol. This is a cosmetic issue and there is no
interruption to the multicast traffic flow. [PR/419509]
■
Setting the advertise-high-metric option while using IS-IS overload also suppresses
route leaking. [PR/419624]
■
On JUNOS OSPF, all locally generated Type 5 LSAs are purged and regenerated
while deleting an NSSA area from the area border router (ABR). [PR/457579]
■
Under rare situations, a software validation failure might cause the routing
protocol process to restart. This might otherwise have caused route drops.
[PR/476143]
■
When aggregate interfaces are used for VPN applications, load balancing may
not occur with a Layer 2 circuit configuration. [PR/471935]
■
During transient periods where both a secondary and primary LSP exist in a
routing table, and the number of LSP NHs is greater than 16 in a multigateway
scenario, IS-IS may remove the preferred LSP NH. For example, IS-IS could
remove an HIPRI LSP. [PR/485748]
■
The Juniper Networks rendezvous point (RP) does not process PIM Register
messages from a first-hop router in an IPv6 embedded RP group when the
Register message does not have the null-bit set. [PR/486902]
■
When a PPMD delegation of BFD sessions is configured over AE interfaces,
graceful Routing Engine switchover and NSR do not work. [PR/505058]
■
The BGP BMP message for IPv6 withdraw encoding does not follow the BMP-draft.
[PR/512780]
■
63
■
When an interface comes up after a down event, and LDP-IGP sync is configured
for that interface, OSPF does not include the interface in its LFA calculations
while the interface is in LDP Sync hold-down state. [PR/515482]
■
When the received next hop for a route has the same address of the EBGP peer
to which the route is readvertised, the next hop is errorneously set to the peer's
address instead of the next hop to self. [PR/533647]
■
When a certain combination of route damp parameters is configured for BGP,
the resulting internal calculations result in an attempt to allocate 0 bytes of
memory, causing the routing protocol process to crash and restart. As a
workaround, avoid the exact combination of these values in the configuration.
[PR/534780]
■
When an interface is added to a routing instance with rpf-check enabled, the
routing protocol process might crash if a route distinguisher is also changed at
the same time. [PR/539321]
■
When a policy matching an extended community using a 4-byte AS and a
wildcard is configured, the match condition might fail to match the relevant
communities. As a workaround, configure exact matches. [PR/550539]
■
In JUNOS Release 10.0 and later, a direct route to a VRF with a rib-group is not
advertised as an inet-vpn route to the IBGP neighbor because of the error "BGP
label allocation failure: Need a nexthop address on LAN." [PR/552377]
■
If a new VPN is added when advertise-default is used with the route-target family,
the necessary route refresh is not sent. [PR/561211]
■
Packets might not be correctly evaluated by a filter in an MPC that contains
non-contiguous prefixes. As a workaround, replace the non-contiguous prefixes
with equivalent sets of contiguous prefixes. [PR/564286]
■
The show services accounting flow-detail extensive command sometimes displays
incorrect information about input and output interfaces. [PR/40446]
■
When a routing platform is configured for graceful Routing Engine switchover
(GRES) and Adaptive Services (AS) PIC redundancy, and a switchover to the
backup Routing Engine occurs, the redundant services interface (rsp-) always
activates the primary services interface (sp-), even if the secondary interface was
active before the switchover. [PR/59070]
■
Detection of failure of remote PPP clients on the LNS through LCP echo requests
will take longer due to an increase in the number of echo request retries.
[PR/250640]
■
When the Border Signaling Gateway (BSG) configuration contains a policy that
has a term with regular expressions, configuration changes might not take effect
immediately after the commit process is complete. In most cases, the new policy
takes effect immediately. However, complex policies may take longer to take
effect depending on how many regular expressions they contain.
For example, if you have a term with four regular expressions, configuration
changes do not take effect until 50 seconds after you receive the message that
the commit process is complete. This behavior occurs whether you have a list
or regular expressions (for example, regular-expression [sip:88824.* sip:88821.*
64
■
sip:88822.sip:88823.*]), or you group regular expressions using the | symbol
(for example, "sip:88821.*|sip:88822.*|sip:88823.*|sip:88824.*").
The time taken for the software to apply the configuration changes increases
exponentially with the number of regular expressions in your configuration.
[PR/448474]
■
When a standard application is specified under the [edit security idp idp-policy
policy-name rulebase-ips rule rule-name match application] hierarchy level, the IDP
does not detect the attack on the non-standard port (for example, junos:ftp on
port 85). [PR/477748]
■
The Multiservices PIC or Multiservices DPC might restart when SIP traffic is
processed on the corresponding Application Layer Gateway. [PR/478331]
■
The output of the show services ids destination-table command might not display
any flow and related statistics in the IDS anomaly table for a certain period of
time after the flows are activated. [PR/490584]
■
In the export version of the JUNOS Software, the signature download does not
work for AppID and IDP features in the Dynamic Application Awareness (DAA)
suite. In order to resolve this, install the Crypto software suite. [PR/499395]
■
After a user establishes an SSH connection, the sshd process is spawned on the
server and services the user. After the connection is established, the sshd process
listens on a socket, and keeps polling in the select(), and sleeps until there is
something to be processed on the socket. When the client closes the connection,
a message is sent on the socket to the server, which reads and processes the
tear-down of the connection. However, when a blocking TCP is sent to the client
to detect the client's presence, the time-out never expires. [PR/538342]
■
When unit 0 of the Multiservices-PIC interface is not specified, the monitor
interface traffic command does not display the input packet number properly for
that particular MS-I/F interface. [PR/544318]
■
The revert-interval value configured in the [edit access profile] hierarchy level is
ignored. [PR/454040]
■
The RADIUS accounting stop messages do not include the Acct-Terminate-Cause
attribute (type 49). [PR/458034]
■
For a dynamic PPPoE interface in which the subscriber is assigned to a
non-default routing-instance (via the LSRI-Name or redirect-LSRI-Name RADIUS
VSAs), the IP address assigned to the subscriber must be specified via the
framed-ip-address RADIUS attribute. An IP address can not be allocated from a
local pool defined in the assigned routing-instance, either when RADIUS returns
no address attributes or when the RADIUS framed-pool attribute is returned.
[PR/471677]
■
On an MX Series router configured for PPP subscriber access, configuring a large
number of PPP subscribers on a single MPC may result in a long boot time for
■
65
the MPC. Distributing subscribers over multiple MPCs will improve boot times.
[PR/490987]
■
The destination and destination-profile options for address and
unnumbered-address within the family inet and inet6 are allowed to be specified
within a dynamic profile, but are not supported. [PR/493279]
■
When the allow-command show interfaces $ is set in the class definition (specified
inside a user configuration), the user is unable to access any commands that
begin with show. [PR/55413]
■
Deletion of configuration groups cannot be prevented with the allow-configuration
and deny-configuration statements. [PR/59187]
■
The JUNOScript perl module for NETCONF does not support configuration-text.
[PR/82004]
■
"Local Password:" is prompted even though the authentication order has the
password configured. [PR/94671]
■
When the CLI screen length is set to zero and the show log command is used,
the “more” prompt ignores the CLI screen length of zero, and only a fraction of
the number of lines is displayed. [PR/103595]
■
The logical system administrator can modify and delete master administrator-only
configurations by performing local operations such as issuing the load override,
load replace, and load update commands. [PR/238991]
■
The “replace:” tag is missing from the output of the save terminal command from
inside a configuration object.
Example:
edit system
save terminal
system {
host-name blue;
}
[PR/269736]
66
■
■
The user can still commit an invalid configuration successfully, even when DDL
checks exist. [PR/282896]
■
After AI scripts are added, the existing management sessions (including the one
used to add the AI scripts) must exit the edit mode and reenter it for any
subsequent configuration changes to take effect. Changes made in these existing
edit sessions are not written to the candidate configuration. [PR/297475]
■
A user class configuration with a deny command ".*" returns a .noop error when
the Return key is pressed on the router’s CLI. As a workaround, replace "^$"
with "^.noop-command$" in allow regex, i.e., allow-commands "(show
interfaces)|(show route)|(exit)|(^.noop-command$)";. [PR/311426]
■
On M Series, MX Series, and T Series routers, the user cannot differentiate
between active and inactive configurations for system identity, management
access, user management, and date and time pages. [PR/433353]
■
In the J-Web interface , the “Generate Report” option under Monitor Event and
Alarms opens the report in the same web page. [PR/433883]
■
Selecting the monitor port for any port in the Chassis Viewer page displays the
common Port Monitoring page instead of the corresponding Monitoring page of
the selected port. [PR/446890]
■
On MX Series routers, J-Web does not display the USB related information under
Monitor>SystemView>System Information>Storage. [PR/465147]
■
On M7i and M10i routers with Enhanced CFEB installed, the chassis viewer
plug-in does not display the Routing Engine in the front view and the E-CFEB in
the rear view. However, the chassis contents from the system (left side tab)
display the list of components correctly. [PR/483375]
■
Using the new-line character \n within op script argument descriptions will cause
the help output to be displayed incorrectly and could result in extra output being
displayed when the op script runs. [PR/485253]
■
In the J-Web interface, the options Access Concentrator, Idle Timeout, and Service
Name for PPPoE logical interfaces are not supported on MX Series routers.
[PR/493451]
■
On J-Web, the error message: “Fatal error: Allowed memory size..." displays
when the Interfaces tab is selected. This message also displays when the
Interfaces tab under Class-of-Service is selected. [PR/495825]
■
J-Web does not display the drop-profile-map, excess-priority, excess-rate, and
rate-limit (transmit rate) parameters under the scheduler configuration for M
Series and MX Series routers. [PR/495947]
■
The licenses are not synced between the master and backup Routing Engine
unless the system license traceoptions file file-name statement is configured.
[PR/501443]
■
Invalid XML characters such as &#x11 (0x11) or &#20 (0x14) are allowed to be
loaded into the router. As a result, the XML parsers break as the characters are
not XML compliant. [PR/502994]
■
In JUNOS Release 10.2, the upload and install package does not show warning
messages when there are pending changes to be commited. As a workaround,
commit all pending commits before performing the upload, install package, or
reboot operations. [PR/514853]
■
The show log xxx | last x command behaves as if the screen length is set to 0,
and the --more xx%-- prompt does not appear. [PR/517023]
■
The annotate option does not appear when it is used under the edit private
command for class of service. [PR/535574]
■
The J-Web pages loads inconsistently when Add IPv4 or IPv6 filters are used in
the Internet Explorer and Firefox Web browsers. [PR/543607]
■
After the delete action is performed, the replace actions do not take effect in the
“load replace terminal” operation. [PR/556971]
■
67
VPNs
■
When you modify the frame-relay-tcc statement at the [edit interfaces
interface-name unit logical-unit-number] hierarchy level of a Layer 2 VPN, the
connection for the second logical interface might not come up. As a workaround,
restart the chassis process (chassisd) or reboot the router. [PR/32763]
■
On a router configured for nonstop active routing (NSR) (the nonstop-routing
statement is included at the [edit routing-options] hierarchy level), if a nonstop
active routing switchover occurs after the configuration for routing instances
changes in certain ways, the BGP sessions between PE and CE routers might not
be established after the switchover. [PR/399275]
■
On MX Series, M120, and new EIII FPCs on M320 routers, the ISO/Connectionless
Network Service (CLNS) packets over the translational cross-connect (TCC) are
dropped in the case of Frame Relay, even though the family TCC has been
configured to switch family iso on the Frame Relay interface. [PR/462052]
■
In vlan-tagging, stacked-vlan-tagging, and flexible-vlan-tagging modes, untagged
packets or mismatching Tag Protocol ID (TPID) packets may be dropped. These
dropped packets are not accounted for and are not visible in the CLI. This issue
is specific to the 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PICs.
[PR/496190]
■
If a VRF routing instance contains a static route that is resolved via a route that
was auto-exported from another routing instance, the static route may not be
removed when the physical interface goes down. [PR/531540]
Resolved Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series
Routers
Class of Service
68
■
■
When a VLAN ID is changed, the following message appears in the messages
log: "COSD_GENCFG_WRITE_FAILED: GENCFG write failed for Classifier to IFL
74. Reason: File exists.” This log message appears when the configuration is
committed with VPLS configured on the Gigabit Ethernet interface, and a
class-of-service classifier or rewrite rules that contain IEEE 802.1P on the interface
are used. [PR/408552: This issue has been resolved.]
■
On M Series and T Series routers, the forwarding class information is lost when
the packet enters the GRE tunnel with clear-dont-fragment-bit enabled. Additionally,
on an Enhanced FPC or M120 FEB, the packet is also likely to be dropped if it
is classified to a packet loss priority (PLP) value other than low. [PR/514162: This
issue has been resolved.]
■
Under certain race condition scenarios on an Enhanced Queuing DPC, configuring
rate limit might result in rate limit drops in that queue. [PR/519181: This issue
has been resolved.]
■
When a logical interface set has a shaping-rate less than the sum of the
transmit-rates of its queues and when the configuration is corrected so that the
logical interface set gets the right shaping-rate, ADPC might crash. [PR/523507:
This issue has been resolved.]
■
On an MX FPC, traffic drops occur on a high-speed interface (OC12 and OC3).
Traffic drops might also occr in contract traffic on a rate-limited or shaped queue,
when the interface is congested. As a workaround, use a policer instead of a rate
limit and configure all the interfaces to the same speed on the MX FPC.
[PR/526339: This issue has been resolved.]
■
When class of service is configured for a routing instance using a wild card, the
classifier type might not populate correctly when a new routing instance is added.
■
When the rate-limit option is configured on a physical interface on IQ2 PICs, the
show interface queue command might not display the RL-dropped counters.
■
The egress rate limit over a logical interface might drop large packets. [PR/547506:
■
If a configuration for a wildcard interface exists in a class-of-service hierarchy,
the cosd process might crash. [PR/555648: This issue has been resolved.]
■
When only the inet or MPLS family is configured on an interface, the logical
interface does not consider the default classifier slot for the ipprec-compatibility.
■
Port mirroring does not work under the bridge-domain forwarding-option filter.
■
When logical systems are configured, the show bridge-domains command might
time out and return the following error message: “error: timeout communicating
with l2-learning daemon.” [PR/536604: This issue has been resolved.]
■
A scheduler is associated with a forwarding class. When a forwarding class is
mapped to a different queue, the associated scheduler is not applied to the new
queue. [PR/540568: This issue has been resolved.]
■
On a sampled traffic on a Multiservices PIC, the multicast convergence slows
down with the message "RPD_KRT_Q_RETRIES: Indirect Next Hop Update: No
buffer space available." [PR/554363: This issue has been resolved.]
■
On M120 routers, the message: "stream blocked detected message" is displayed
when a Forwarding Engine Board (FEB) is switched from the backup to the
primary. [PR/540644: This issue has been resolved.]
■
The MX DPC might reboot with the error message: "EZ:
ezchip_get_srh_msg_from_srhq". [PR/310223: This issue has been resolved.]
■
When lockout is configured and the router is rebooted, the working router is
stuck in the wait-to-restore state while the protect router still shows channel state
working and no requests, but no longer shows the lockout flag. [PR/474482: This
High Availability
■
69
70
■
■
The chassisd process fails to create an interface when a PIC is brought online.
However, the state of both the PIC and FPC is online. [PR/479426: This issue
has been resolved.]
■
When an IQ2 PIC is brought online with a class-of-service configuration that
includes a scheduler using the rate-limit options, the system incorrectly reports
that rate limiting is not supported on the PIC. [PR/482199: This issue has been
resolved.]
■
An OAM trace displays an incorrect next-hop MAC value. [PR/494588: This issue
has been resolved.]
■
If a T640-FPC4-ES is installed in a T1600 router and an SIB statistics collection
is performed, the message log might report "JBUS: U32 read error, client .." only
if one of the SIBs is faulted or in the offline state. This system log message will
also appear if the T640-FPC4-ES FPC is removed from the chassis. There is no
operational impact. [PR/504363: This issue has been resolved.]
■
On an M20 router with AC PEMS, the alarm message “Power Supply x not
providing power” is generated when the power cord is removed. The alarm is
not cleared when the power cord is reconnected. [PR/506413: This issue has
been resolved.]
■
On M120 routers, all traffic is duplicated when the request chassis redundancy
feb switch-to-backup command is used, or the FEB is offline. This issue occurs
only when the status of the Automatic Protection Switching (APS) is protect.
■
On M7i routers with JUNOS Release 8.5 or later, the output of the show interfaces
fxp0 command shows the fxp0 interface to be in the “link up” state even when
the interface is disabled with no cables connected. [PR/508261: This issue has
been resolved.]
■
When the 1x10GE PIC is brought online, related error messages are seen in the
logs but without any functional impact. [PR/512094: This issue has been resolved.]
■
When the VRRP6 master changes, there is no log output for VRRP IPv6.
■
If a child T1 or E1 link of an MLPPP bundle with two or more children connected
to a Cisco router flaps, the T1/E1 link fails to rejoin the bundle due to an
inconsistent LCP state. As a workaround, bounce the whole bundle to clear the
issue. [PR/525489: This issue has been resolved.]
■
The queue counter of the aggregated Ethernet is counted up after the statistics
is cleared and the FPC is restarted. [PR/528027: This issue has been resolved.]
■
When M120 Type 1 FPCs are configured for 2:1 FPC:FEB mapping, and one of
the FPCs restarts, the restarting FPC might not initialize properly and might result
in a small percentage of packet loss for all interfaces on that FPC. As a
workaround, restart the FPC until the problem stops. [PR/529994: This issue has
been resolved.]
■
When the clear interfaces statistics command is used, if a member link is
deactivated from an aggregate (AE or AS on any platform) and if the show
interfaces extensive command is used immediately, incorrect values (very high
values) might be seen for the counters such as “Transmitted and Queued” packets
under the queue counters. If the clear interface statistics command is not issued
before deactivating the member link, this issue is not seen. [PR/530297: This
■
When any subscriber interface (PPPoE or DHCP) is used, the VPLS connections
go down. [PR/530435: This issue has been resolved.]
■
When Automatic Protection Switching (APS) is configured on a 4x STM-1 SDH,
SMIR PIC, the transmitted value of the K2 byte shows 0x00 for both unidirectional
and bidirectional instead of 0x04 and 0x05, respectively. [PR/531030: This issue
has been resolved.]
■
In JUNOS Release 10.0 and later, a significantly large number of the following
messages appear on the MX960 and SRX5800 routers:
MX960
MX960
MX960
MX960
MX960
/kernel:
/kernel:
/kernel:
/kernel:
/kernel:
PCF8584(WR): transmit failure on byte 1
PCF8584(WR): (i2c_s1=0x80, group=0xe, device=0x54)
PCF8584(WR): busy at start, attempting to clear
PCF8584(WR): (i2c_s1=0x00, group=0xe, device=0x54)
PCF8584(RD): ack failure on 2nd last byte
These messages are not an indication of a fan failure. They are cosmetic and
can be ignored. [PR/531253: This issue has been resolved.]
■
After a PIC restart, a statistics query on the AE interfaces might produce wrong
results. As a workaround, clear the statistics after a PIC restarts. [PR/531485:
■
On Trio MPCs, multiple changes to a single term in quick succession results in
an incorrect filter state in the Packet Forwarding Engine. This causes the MPC
to crash. [PR/532791: This issue has been resolved.]
■
The kernel might crash when bundled messages are sent to the Packet Forwarding
Engine when the physical interface is deleted. [PR/532926: This issue has been
resolved.]
■
An XE circuit on MPC-3D-16XGE-SFPP might cause a high CPU utilization on the
MPC. [PR/535057: This issue has been resolved.]
■
On MX960 routers, the link status stays in the "Link ok" state when the SCB is
removed without taking it offline through the CLI or switch. [PR/536860: This
■
The SCB displays an incorrect state when it is removed without taking it offline
through the CLI or buttons. This is not a cosmetic error and might have an impact
on the traffic. [PR/536866: This issue has been resolved.]
■
The "frame-relay-ether-type" encapsulation is not programmed to the hardware
properly. As a result, the incoming packet parsing fails and the packets are
discarded. [PR/539484: This issue has been resolved.]
■
On MX Series routers with 10.x Power Budget, after a “Power Budget: Chassis
experiencing power shortage” alarm occurs, the alarm does not clear even after
the power budget problem is cleared. [PR/540522: This issue has been resolved.]
■
The MX-MPC1-3D-Q accepts VLAN-tagged packets even when the interface is
not configured with VLAN tagging. [PR/540620: This issue has been resolved.]
■
The link-up time on a 16x10-Gigabit Ethernet MPC is not as less as on other
platforms (ADPC and other MPCs) because of the emission dispersion
compensation (EDC) functionality of the PHY device on the MPC. This causes a
■
71
delay of 50 mS to 150mS and cannot be changed. [PR/540694: This issue has
been resolved.]
■
The sonet-options raise-rdi-on-rei and trigger options do not work well together.
Turning the raise-rdi-on-rei option on and back off requires the trigger option to
flap in order to assert or clear the RDI-L alarm. As a workaround, when both
sonet-options raise-rdi-on-rei and trigger options are configured, flap the
sonet-options trigger too. [PR/540745: This issue has been resolved.]
■
The space SCB stays in the same status when the SCB that is online is removed
without taking it offline. [PR/542615: This issue has been resolved.]
■
When a GE/XE interface on IQ2 PICs is disabled, and the link status is up, the
traffic received from the interface might still be forwarded. [PR/543388: This
■
When one of the units of an aggregated Ethernet is deactivated, all other units
■
On a 10x10-Gigabit Ethernet PIC, the chassis scheduler maps for a wildcard
configuration does not work when the PIC is taken offline and brought back
online, due to an incorrect stream value. [PR/551161: This issue has been
resolved.]
■
When logical interfaces are created, the NPC crashes and the FPC goes down.
■
On a 10-Gigabit Ethernet PIC, a log is generated when the SFP is plugged in.
However, no log is generated when the SFP is not plugged in. [PR/548251: This
■
VRRP between IRB interfaces on a VPLS network shows a master-master status
after the existing master goes down and comes back up. [PR/552699: This issue
has been resolved.]
■
The EOA family configurations over a container ATM interface might be deleted
and added again upon every commit (including unrelated commits). [PR/553077:
■
A Spanning Tree Protocol triggered MAC flush might fail if there are frequent
topology changes with a significant number of MAC addresses learned. For
multiple Spanning Tree Protocols, restart l2cpd-services to come out of the state,
and for the Rapid Spanning Tree Protocol, reboot the corresponding DPC.
■
On MX Series routers, when both the top and bottom fan trays are enhanced
and a mastership switch is performed, the alarm "craftd[1337]: Minor alarm set,
Mix of FAN-TRAYS" is displayed. This occurs only after a switchover or an
upgrade. This alarm is temporary, is cleared within a few seconds, and does not
cause any routing or forwarding issues on the chassis. [PR/541617: This issue
has been resolved.]
■
The AE interface does not show the system identifier for the attached interfaces
in actor role. Because of this, the AE interface gets stuck in the detached state
after it is rebooted from both ends. Additionally, the AE interface flaps when the
72
■
backup Routing Engine is rebooted and a graceful Routing Engine switchover
(GRES) is performed. [PR/547739: This issue has been resolved.]
MPLS Applications
■
The routing protocol process may sometimes crash at rsvp_find_lp_tag_route.
■
With BFD enabled over IGP and an RSVP session built across it, when the RSVP
peer does not support RSVP Hello (or is disabled), the BFD session down event
triggers only the IGP neighbor to go down. The RSVP session remains up until
a session timeout occurs. [PR/302921: This issue has been resolved.]
■
The routing protocol process might crash with an assert in rsvp_PSB_set_selfID
while a graceful Routing Engine restart is performed when P2MP LSPs are present.
■
The rlist entry corresponding to the previously existing rlist is not removed, which
causes the routing protocol process to crash. [PR/513160: This issue has been
resolved.]
■
An invalid SNMP get-next request for an LDP OID might cause the routing protocol
process to crash. This issue occurs only when LDP is enabled. [PR/530348: This
■
When a protected link flaps, certain RSVP routes do not lose association with
the p2mp_nh. [PR/530750: This issue has been resolved.]
■
The maximum average bandwidth utilization computed by MPLS for
auto-bandwidth may sometimes be higher than the actual traffic rate (twice the
traffic rate). This occurs when the MPLS statistics response from the Packet
Forwarding Engine comes in late, and two statistic entries for the same LSP fall
in the same MPLS auto-bandwidth averaging timer interval. [PR/536759: This
■
In a next generation MVPN with vrf-table-label configured on the provider edge,
the provider router connecting to that provider edge might keep an old
point-to-multipoint MPLS label entry upon label-switched path optimization or
reroute. There is no workaround. [PR/538144: This issue has been resolved.]
■
A label-switched path (LSP) with auto-bw might stay down for approximately 30
minutes after a Routing Engine switchover or a Routing Engine restart when
graceful restart fails. As a workaround, disable and reenable the MPLS or OSPF
stanza. [PR/539524: This issue has been resolved.]
■
When the RSVP path-mtu allow-fragmentation is configured, traffic failure might
occur. [PR/544365: This issue has been resolved.]
■
On a point-to-multipoint LSP setup, the routing protocol process of the transit
router might crash when the topology changes with respect to the ingress sub-LSP
router. There is no workaround. [PR/549778: This issue has been resolved.]
■
On MX80 routers, the MPLS LSP statistics do not record the transit traffic on a
single-hop LSP with an implicit NULL label. [PR/551124: This issue has been
resolved.]
■
73
Network Management
■
SNMP may stop working after a router reboot, DPC/FPC/MPC restart, or a graceful
Routing Engine switchover. [PR/525002: This issue has been resolved.]
■
In JUNOS Release 9.2 and later, a memory leak occurs in the subagent in a
scenario where the snmpd process is not running, or there are issues in
communication with a subagent and traps are being generated by the subagent.
■
Redirect drops that are not real errors are taken into account for "Iwo HDRF"
error statistics that are reported in the output of the show pfe statistics errors
command on I-chip based routers. Because redirect drops are expected in a VPLS
(and Ethernet in general) environment, this behavior could be misleading.
■
After an 8216 Routing Engine upgrade to JUNOS Release 9.6 with "chassis"
deactivated, the backup Routing Engine starts to reboot with the panic message
"panic: filter_idx_alloc: invalid filter index" and crashes when the chassis
configuration is enabled and committed. After the Routing Engine finally comes
online, the CLI response is slow and the Routing Engine reboots again after three
minutes approximately. To stop these reboots, deactivate the chassis on the
backup Routing Engine. [PR/489029: This issue has been resolved.]
■
On T Series routers, the FPC might continuously reboot upon installation.
■
In a setup with two VPN routing and forwarding tables (VRFs) of a provider edge
connected to different customer edges and auto-export configured, when a ping
is executed from a customer edge to a provider edge interface in the other VRF
, the Internet Control Message Protocol reply returns the source interface IP of
the provider edge that is connected directly instead of the interface IP of the
other VRF provider edge. [PR/510834: This issue has been resolved.]
■
Under certain conditions, traffic flow through an RLSQ bundle can be dropped
after it is removed and added back to a VPN routing and forwarding table (VRF).
■
When the system default-router a.b.c.d command is used, the default route is not
installed in the Packet Forwarding Engine. [PR/523663: This issue has been
resolved.]
■
On MX Series routers, repeated graceful Routing Engine switchover (GRES) under
certain configurations might result in kernel panic. Three kernel cores are
observed: with a soft update files system trace, with a TCP packet processing
stack trace, and with a trace of IFF configuration write. [PR/525583: This issue
has been resolved.]
■
A neighbor solicitation request does not return any neighbor-advertised packets
when static neighbors are configured. [PR/527779: This issue has been resolved.]
■
The Packet Forwarding Engine incorrectly imposes a rate-limit function for the
host-bound virtual LAN tagged packets with an IEEE 802.1p value of 1. There is
no workaround. [PR/529862: This issue has been resolved.]
74
■
■
Asp_ifl_update messages may be seen on routers running JUNOS Release 10.0
and above. Ignore these messages as they do not impact functionality.
■
A router might send raw IPv6 host-generated packets over the Ethernet toward
its BGP IPv6 peers. [PR/536336: This issue has been resolved.]
■
When a SIB is taken offline without using the CLI or the offline button and brought
back online, the link error alarm does not clear. [PR/536673: This issue has been
resolved.]
■
The backup Routing Engine might cause the kernel to crash when a configuration
change occurs on the AE bundle during a next-hop index allocation. [PR/544092:
■
On TX Series routers with T640-FPC3 FPCs and a large number of routes, when
an AE interface in an ECMP path goes down, small packet drops might occur in
the traffic on the other ECMP link. This issue does not occur when an indirect
next hop is used. [PR/545166: This issue has been resolved.]
■
In JUNOS Release 10.0 and later, the FPCs in M320 and T Series routers might
crash when the error “PFE: Detected error next-hop” (corrupted next-hop) is
encountered. [PR/546606: This issue has been resolved.]
■
On M120 routers, multicast packet drops occur when both the Fast Ethernet and
the SFP Gigabit Ethernet PICs are located on the same Packet Forwarding Engine.
■
In JUNOS Release 9.3 and later, when routers using Enhanced FPCs
(T640-FPCx-ES or T1600-FPC4-ES FPCs) have a configuration involving CBF LSPs
and aggregate interfaces, a jtree corruption might occur when a flap from a
member link in the aggregate occurs on the remote end, or the FPC of the remote
router is rebooted. To avoid this issue, use indirect-next-hop (routing-options
forwarding-table indirect-next-hop). The error message “PFE: Detected error
nexthop:" indicates a jtree corruption. [PR/548436: This issue has been resolved.]
■
In a multicast VPN scenario, if the default-vpn-source is configured under protocol
PIM, and then the FPC holding is configured, the Multiservices PIC might crash
when it is taken offline. [PR/550061: This issue has been resolved.]
■
The NTP server might not respond to clients whose source address is explicitly
configured. [PR/556024: This issue has been resolved.]
■
75
■
When a firewall loopback filter exists and the default term is discard, the multicast
forwarding cache entries will be created since the resolve request is dropped at
the Packet Forwarding Engine level. As a workaround, add an additional term
to accept the multicast destination address 224/4. [PR/531787: This issue has
been resolved.]
■
The output of the show ospf statistics command does not display hello packet
statistics. [PR/427725: This issue has been resolved.]
■
Packet drops occur during a GRE/NSR switchover, when class of service and
scheduler-map are enabled on the aggregated interface. [PR/502365: This issue
has been resolved.]
■
When a family inet6 addressing is added to a router configured with multicast
VPN, the routing protocol process might crash and restart. [PR/503296: This
■
The mirror receive task variable may not be cleared when the routing protocol
process is heavily scaled. Hence, the NSR replication for RIP status stays in the
"InProgress" state forever. [PR/516003: This issue has been resolved.]
■
Under rare circumstances, multiple commits might crash both Routing Engines.
The routing protocol process dumps core and restarts only on the master Routing
Engine. This issue occurs when commits are executed within one minute.
■
An ISSU upgrade to JUNOS Release 10.2 with PIM NSR configured fails whenever
an incompatble FRU (PIC) is required to be taken offline during a Routing Engine
switchover. As a workaround, disable NSR for PIM using the set protocols pim
nonstop-routing disable command for the ISSU uppgrade to be successful.
■
On MX80 routers, non IS-IS fragmented GRE packets are filtered before they are
forwarded to the Routing Engine. [PR/529727: This issue has been resolved.]
■
For JUNOS Release 9.5 and later, the BGP parse community begins with “0” as
the octal value. This behavior is different in earlier releases. [PR/530086: This
■
When the bridge MAC table is cleared on a router that has bridge interfaces on
MPC cards, the MAC learning process might be broken for some time (10 seconds
to a few minutes). This results in traffic being looped between the two routers.
■
The master routing protocol process crashes three minutes after a graceful Routing
Engine switchover. [PR/533363: This issue has been resolved.]
■
The Overload bit in the IS-IS LSP MT-TLV may trigger the IS-IS to install a default
route to the overload bit advertiser and the show isis database extensive
command may report an unknown TLV. [PR/533680: This issue has been
resolved.]
Routing Protocols
76
■
■
When the labeled-unicast inet6 route is reflected by route reflectors, the label
might be set to explicit-null. [PR/534150: This issue has been resolved.]
■
The routing protocol process might crash due to an invalid prefix-length value
in one of the flow-spec routes. [PR/534757: This issue has been resolved.]
■
If enough join state is associated with a neighbor and that neighbor goes down
and comes back up quickly, then that join state may be stranded in an unresolved
state until the clear pim join command is issued. [PR/539962: This issue has been
resolved.]
■
On Type 2 Trio MPCs, multiple changes to a single term in quick succession can
cause an incorrect filter state in the Packet Forwarding Engine. This causes the
MPC to crash. [PR/540674: This issue has been resolved.]
■
The routing protocol process might crash when a BGP connection attempt is met
with an RST from the peer. This is due to an unlikely race condition. [PR/540895:
■
Under certain timing conditions, an interior gateway protocol topology change
can result in the BGP routes referencing an incorrect egress interface. This
problem can occur when active and inactive BGP routes are learned from the
same peer and the inactive BGP routes are deleted at the time of the topology
change. [PR/543911: This issue has been resolved.]
■
In instances with scaled LACP configurations, the periodic packet management
process (ppmd) might experience memory leaks. [PR/547484: This issue has
been resolved.]
■
When two identical local interface addresses are shared between two VRFs
through auto-export, the routing protocol process might cause a high CPU
utilization. [PR/547897: This issue has been resolved.]
■
An incoming BGP route with a long AS path that is a contributor to an aggregate
route might cause the routing protocol process to restart. [PR/548322: This issue
has been resolved.]
■
The GetRequest operation might fail for certain OIDs located in the multicast
routing MIB. [PR/549928: This issue has been resolved.]
■
If a PIM <S, G> join arrives when there is no route to the source, PIM RPF
checking is disabled, and a matching multicast route is present, the output
interfaces associated with the PIM <S, G> join are not added to the multicast
route. [PR/550703: This issue has been resolved.]
■
The IPv6 entries are removed from the output of the show pim interfaces
command when the corresponding interface is in the down state. This is a
cosmetic issue. [PR/550799: This issue has been resolved.]
■
When an interface-based IPv6 BGP session with a 2-byte AS format is used, the
system might crash. [553772: This issue has been resolved.]
■
An IS-IS adjacency flap at a precise interval can cause the routing protocol process
to restart on a neighbor, as it is in the process of purging the LSAs of the
previously down node from the local database. [PR/554233: This issue has been
resolved.]
■
The Juniper Networks PIM-SM ASM implementation might not set the SPTbit
when RPT and SPT are both preferred over the same interface. [PR/555650: This
■
77
■
For Adaptive Services II PICs, a temporary file might be created every 15 minutes
in the /var/log/flowc/ directory even if flow collector services is not configured.
The file is deleted if there are no clients, and re-created only when a client
connects and attempts to write to the file. [PR/75515: This issue has been
resolved.]
■
The IPv6 gateway may have a NULL value when the destination address points
to an aggregated next hop. [PR/516058: This issue has been resolved.]
■
L2tpd asserts when short length frames are sent. This causes the l2tpd to crash.
As per RFC 1661 and 1662, such packets should be treated as invalid and
discarded. [PR/533057: This issue has been resolved.]
■
In JUNOS Release 10.0 and later, the routing instance name is restricted to 63
characters. [PR/533882: This issue has been resolved.]
■
The BGP_IPV4_NEXT_HOP field on the jflow v9 record matches the originator
ID instead of the BGP next hop. [PR/534598: This issue has been resolved.]
■
When traffic is forwarded in an L2TP session and a teardown request is received,
the AS PIC crashes with a memory access violation in mlppp_output. [PR/537225:
■
On M Series routers configured for L2TP tunneling with several thousands of
PPP connections, when all the PPP sessions expire at the same time, the
Multiservices PIC might hang and become unusable. To recover the service,
restart the PIC. [PR/541793: This issue has been resolved.]
■
On SG3 PICs (Multiservices 500) with graceful Routing Engine switchover (GRES),
wrong record values are seen for the IPv4 netflow export packets. This error
occurs when the route records are not installed. [PR/545422: This issue has been
resolved.]
■
The IPv6 and MPLS route counts are not reflected in the output of the show
service accounting status command. [PR/550793: This issue has been resolved.]
78
■
■
J-Web does not display the USB option under Maintain>Reboot>Reboot from
the media. [PR/464774: This issue has been resolved.]
■
On TX Matrix and TX Matrix Plus routers, the syslog messages might not be sent
from the LCC to the SCC after a Routing Engine switchover. [PR/493138: This
■
On a router configured with a large number of interfaces, when a few interfaces
are constantly added and deleted, a minor memory leak may occur in the "pfed"
process. [PR/522346: This issue has been resolved.]
■
When a configuration with a long AS-path is displayed in XML format using the
show configuration | display xml | no-more command, the closing tag for the as-path
<path> is wrongly displayed as </path instead of </path>. [PR/525772: This
■
The xnm service currently does not support logging of remote-host addresses in
system accounting. [PR/535534: This issue has been resolved.]
■
Navigation from the Monitor RIP Information page to the Route Information
page fails with errors. [PR/536255: This issue has been resolved.]
■
The system continues to use the TACACS server configuration even after it is
removed. As a workaround, deactivate and reactivate the accounting
configuration. [PR/544770: This issue has been resolved.]
■
When the load set command is used to refresh a script file, the script does not
refresh, and exits from the CLI after displaying the RPC-related errors.
■
When two MVPN routing instances and at least one L2VPN routing instance are
configured, the commit fails with the following message:
“RPD_RT_DUPLICATE_RD: routing-instance xxx has duplicate
route-distinguisher." As a workaround, configure the route-distinguisher-id for
each instance manually. [PR/511514: This issue has been resolved.]
■
When a CE-facing interface in a VPLS instance is deactivated, the routing protocol
process may get into a loop leading to a high CPU utilization. [PR/531987: This
■
Under certain circumstances, the container interfaces might not send the proper
martini modes to the routing protocol process. This results in incorrect
control-word-related information sent to the Packet Forwarding Engine.
■
In a VPLS multihoming scenario, the routing protocol process crashes when a
VPLS instance is deleted from the configuration. [PR/546177: This issue has been
resolved.]
■
The next generation MVPN traffic might be dropped at an egress PE router when
a Routing Engine restart event occurs on the point-to-multipoint ingress PE router.
This issue occurs when multiple route reflectors reflect the MVPN routes in the
core. [PR/556148: This issue has been resolved.]
VPNs
Previous Releases
Release 10.1R3
Class of Service
■
When you set the port speed of a multirate SONET Type 2 PIC to OC3, the
class-of-service (CoS) speed value is not changed correctly within the Packet
Forwarding Engine. The speed value remains OC12, which results in unexpected
CoS behavior. There is no workaround. [PR/279617: This issue has been resolved.]
■
If a logical interface is configured or added to an interface set for which an
existing traffic control profile is applied, any rate-limit functionality will not be
applied to the new logical interface. To resolve this problem, deactivate and
■
79
activate the interface portion of the class-of-service configuration. [PR/485872:
■
On an Ichip-based platform for strict high priority queue (SHQ), the buffer size
allocated by the Packet Forwarding Engine is capped by the tx-rate. If the tx-rate
is configured to a very small value or is not configured, and is automatically
allotted a zero or a very small remaining value; the queue is also allotted a
proportionately small delay buffer. This can sometimes lead to Red and Tail
drops on the SHQ when there is a burst of traffic (with a certain traffic pattern)
on it. As a workaround, configure a nominal tx-rate value (5 percent) for the
SHQ. [PR/509513: This issue has been resolved.]
■
the packet enters the GRE tunnel with clear-dont-fragment-bit enabled.
Additionally, on an Enhanced FPC or M120 FEB, the packet is also likely to be
dropped if it is classified to a packet loss priority (PLP) other than low.
■
In a scaled configuration, the class-of-service classifier does not work properly.
■
Policers cannot be modified after a system upgrade due to a flaw in the parser
routine. This error occurs when the current item is deleted and the parser cannot
proceed to the next item. With the fix, the routine in the forwarding process
(dwfd) has been modified so that the next item in the object tree is fetched before
the current object is parsed. [PR/433418: This issue has been resolved.]
■
When an unified ISSU is performed for JUNOS Release 10.0 through 10.2, the
T640-FPC4-ES crashes continuously. [PR/518301: This issue has been resolved.]
■
When a filter with an ip-options "any" firewall match is applied on an interface
on the MX-MPC, the filter is not applied. If the hardware is present at the time
of the configuration commit, a commit warning is issued. However, the commit
does not fail and the rest of the configuration is applied. [PR/524519: This issue
has been resolved.]
■
On T640 and T1600 routers with ST chipset FPCs, in some cases when the IPv6
firewall filters with match conditions configured on address prefixes is longer
than 64 bits, the filter may not be evaluated correctly. This might lead to loss of
packets. [PR/524809: This issue has been resolved.]
■
When forwarding-options is configured without route-accounting, commit goes
through with the message, "Could not retrieve the route-accounting." However,
no functionality is affected. [PR/312933: This issue has been resolved.]
■
The backup Routing Engine can fail to obtain mastership in the following cases:
80
■
■
re0 gets stuck and doesn't reboot.
■
Due to a hardware problem, re0 looses its connectivity with both the Control
Board and the Packet Forwarding Engine.
■
On MX Series routers, traffic is forwarded over the backup link even after the
primary link is disabled and enabled again. [PR/493861: This issue has been
resolved.]
■
When link trace entries are added in the path database, there is no check to
determine if the current number of entries have reached the path database size.
Because of this, the entries may grow to be greater than the path database size
(configured or default). [PR/494584: This issue has been resolved.]
■
Under certain circumstances a backup Routing Engine reboot followed by a
Routing Engine failover can cause the LACP to flap, which causes AE bundles to
flap. [PR/502937: This issue has been resolved.]
■
On MX Series routers with JUNOS Release 10.0R2 or higher, the backup Routing
Engine might report the following warning message upon commit once network
service is configured under the chassis stanza: "WARNING: network services flag
has been changed, please reboot system." [PR/505690: This issue has been
resolved.]
■
The Routing Engine on slot 1 takes mastership regardless of the user-configured
Routing Engine mastership priority. [PR/507724: This issue has been resolved.]
■
When the show chassis hardware models command or the show chassis hardware
| display xml command is used, the FRU part-number 710-013035 displays the
model number T1600-FPC3-ES instead of T640-FPC3-ES. [PR/514072: This issue
has been resolved.]
■
When the show chassis hardware models or show chassis hardware | display xml
command is issued for M320-FPC*-E3 with part-numbers 710-025464,
710-025853, and 710-025855, the model number does not display correctly.
■
When traffic flows across IQE SDH/SONET interfaces, instantaneous inaccurate
traffic rate values with smaller packet sizes occur when the show interface
command is issued. [PR/514330: This issue has been resolved.]
■
The output of the show chassis hardware command may not display the SIB
details when the SIB is inserted in the slot. [PR/515789: This issue has been
resolved.]
■
On some XENPAK modules, the output of the show chassis hardware command
shows the message "NON-JNPR UNKNOWN" when the FPC is booted. There is
no impact on the traffic. To solve this issue, take the PIC offline and bring it back
online. [PR/516411: This issue has been resolved.]
■
On an M120, M7i, or M10i router with Enhanced CFEB running JUNOS Release
10.0 and a VRF routing instance configured with vrf-table-label, the VPN traffic
might not flow when an ATM II IQ PIC is used for a core-facing link. [PR/516485:
■
When a Frame Relay interface goes down, the interface statistics might still
indicate that the data-link connection identifier (DLCI) is active. [PR/516497:
■
When the configuration of shaping and scheduling is added or removed from
the CLI, the traffic from the other PE routers is lost. [PR/517320: This issue has
been resolved.]
■
81
■
On IQ2 and IQ2E 10GE PICs operating in WAN-PHY mode, the path trace
information does not get transmitted to the remote end. [PR/518331: This issue
has been resolved.]
■
When the centralized configuration management (CCM) interval is set to 1m or
above, the CCM flaps for an incorrect hold_time adjacency entry. [PR/520064:
■
The CE_SUPPORT-DCD crashes when a commit is performed. [PR/521380: This
■
When one of two Ethernet connections to another Routing Engine is not present,
the mastership is not switched. [PR/521833: This issue has been resolved.]
■
When multiple routed IPsec tunnels are configured, and the tunnel with the
inside-service-interface defined in the service-set goes down, the other tunnels
with the ipsec-inside-interface configured only in the IPsec rules can stop
forwarding traffic until the main tunnel comes back up. [PR/524935: This issue
has been resolved.]
■
the FPCs restarts, the restarting FPC might not initialize properly and result in a
small percentage of packet loss for all interfaces on that FPC. As a workaround,
restart the FPC until the problem stops. [PR/529994: This issue has been
resolved.]
■
The bpdu-block-on-edge configuration may not work properly when the interface
is configured as 'edge' under the [edit protocols vstp vlan vlan-id interface
interface-name] hierarchy level. [PR/522198: This issue has been resolved.]
■
After an LCC switchover, the SNMP process fails to send traps with resource
temporarily unavailable errors. [PR/493385: This issue has been resolved.]
■
Memory leaks might occur on the mib2d. [PR/517565: This issue has been
resolved.]
■
The SNMP MIB OID tree under dot3adAggPort fails. This issue may occur when
virtual LAN tagging is not configured on the AE interface, and if the mib2d process
is restarted using the restart mibprocess command. [PR/528555: This issue has
been resolved.]
■
A targeted LDP neighbor may remain up with an old IP address that was
previously in use with the loopback address on the remote neighbor. This may
happen when either of the following is performed on the remote neighbor:
Network Management
MPLS Applications
82
■
■
A secondary loopback (lower than the current primary) address is added
and no primary keyword is associated with either of these addresses.
■
A second loopback address is added with the primary keyword.
This results in the targeted LDP neighbor being up with both IP addresses. The
neighbor with the old address may continue to remain up even after the old
loopback address is deleted on the remote neighbor. This neighborship with the
old address eventually times out when the router-id is changed to reflect the new
loopback address on the remote neighbor. [PR/518102: This issue has been
resolved.]
■
At adjust intervals, the maximum average bandwidth utilization for the LSP
should be reset to zero. MPLS sometimes fails to reset the maximum average
bandwidth utilization for the LSP to zero while performing a periodic
auto-bandwidth adjustment at the adjust interval. This prevents periodic
auto-bandwidth adjustment from adjusting to a lower bandwidth when the traffic
rate drops. [PR/528619: This issue has been resolved.]
■
On M7i routers, kernel panic may occur during route changes. [PR/439420: This
■
The configured static NDP entry is cleared automatically after a certain interval.
■
An invalid IP protocol version is served as a valid version. The JUNOS router
forwards IP packets with version field set to values other than 4 and 6, for
example, 11 or any (unassigned). [PR/481071: This issue has been resolved.]
■
Memory leaks might occur on the mib2d rtslib. [PR/510902: This issue has been
resolved.]
■
The VPN PIM neighborship over the mt- interfaces may not recover after a
graceful Routing Engine switchover. [PR/511366: This issue has been resolved.]
■
When an AE interface on an ECMP path is taken down, packet drops may occur
on the traffic that is on another link in the ECMP path. [PR/513102: This issue
has been resolved.]
■
Under rare conditions, the compressed system-generated routing protocol process
core files might be corrupted. As a workaround, disable the compression using
sysctl kern.compress_user_cores. [PR/513193: This issue has been resolved.]
■
Setting the TCP maximum segment size (MSS) may not change the actual MSS
value. [PR/514196: This issue has been resolved.]
■
On M120 and MX Series routers, when an AE interface (with LACP enabled) is
used as a core-facing interface for L3VPN, non-MPLS traffic received on the AE
interface can sometimes get black-holed. To recover from this state, deactivate
and activate the AE interface in the configuration. [PR/514278: This issue has
been resolved.]
■
When IGMP snooping is enabled, a multicast traffic drop might occur if an IGMP
join or leave occurs on other interfaces. [PR/515420: This issue has been
resolved.]
■
When the primary link flaps with the route-memory-enhanced statement enabled,
jtree might get corrupted and traffic forwarding is affected. As a workaround,
deactivate the route-memory-enhanced statement under the chassis stanza.
Changes to the route-memory-enhanced statement take effect only when Packet
Forwarding Engine is rebooted. [PR/517919: This issue has been resolved.]
■
83
■
On some M, MX, and T Series routers, when a firewall filter is applied on the
egress of an aggregate interface, packet loss may occur after adding, removing,
or changing the service configuration on the egress side of the aggregate interface.
As a workaround, deactivate and activate the output firewall filter on the aggregate
interface. [PR/517992: This issue has been resolved.]
■
When container AE interfaces are enabled on JUNOS Release 10.0 or 10.1, the
following message displays when one of the member links flap: “CHPJAR1-re0
fpc3 SCHED: %PFE-0: Thread 40 (PFE Manager) ran for 2015 ms without
yielding.” [PR/518714: This issue has been resolved.]
■
When the destination class usage (DCU) is configured with unicast reverse path
filter (uRPF) and egress forwarding-table filter within the VRF, a VPN route flap
might trigger a jtree memory leak. [PR/521609: This issue has been resolved.]
■
No NA packets are returned for NS requests with a static NDP, due to an issue
with the neighbor advertisement implementation for statically configured
neighbors. [PR/527779: This issue has been resolved.]
■
On some routers, enabling IP-payload-based load balancing for MPLS packets
can cause some pseudowire packets to be reordered. [PR/528657: This issue
has been resolved.]
■
On some M, MX, and T Series routers, when a family CCC filter is applied on
multiple interfaces that belong to different L2VPN routing instances, packet loss
may occur after the routing instances are deactivated and activated. As a
workaround, deactivate and activate the CCC filter on the interfaces. [PR/521357:
■
The backup Routing Engine may generate routing protocol process and kernel
cores if the BGP damping is configured along with nonstop active routing (NSR).
■
When l3vpn-composite-next-hop is configured, it should only be used by L3VPN
routes. However, non-L3VPN routes are also able to use it. [PR/496028: This
■
Upon a graceful Routing Engine switchover with NSR, the routing protocol process
will crash due to a wrong process for the PIM instance. [PR/503921: This issue
has been resolved.]
■
Nonstop routing (NSR) does not work correctly if an automatic route distinguisher
is used with an L2VPN routing-instance. [PR/513949: This issue has been
resolved.]
■
The output of the show igmp snooping interface command does not display
"-snooping," erroneously stating that IGMP itself is not running instead of
IGMP-snooping not running. [PR/516355: This issue has been resolved.]
■
The configured robust count value is not applied on the non-querier router when
it receives a robust count value of 0. It uses the default value (2) instead of the
configured value. [PR/520252: This issue has been resolved.]
Routing Protocols
84
■
■
The new NSR master may not send the OSPF hello messages immediately after
a switchover. [PR/522036: This issue has been resolved.]
■
After a graceful restart, the forwarding state of both provider edge routers might
get stuck at the pruned state. However, traffic flow is not affected. [PR/522179:
■
When an l2circuit ID greater than 2,147,483,647 is configured, and l2circuit
tracing is enabled using the set protocols l2circuit traceoptions command, some
of the trace messages provide the wrong value (a negative number) for the virtual
circuit ID. [PR/523492: This issue has been resolved.]
■
The tag_encoder is unable to handle attempts to stack EXPLICIT_V6_ NULL (label
2) over an existing stack with label 2 on top. Additionally, the BGP module does
not send label 2 when readvertising a prefix from an inet6 unicast session to a
inet6 labeled-unicast session. [PR/523824: This issue has been resolved.]
■
On TX Matrix routers, the router can drop the PIM hello messages before a join
is triggered by the neighbor. This can cause multicast traffic to be dropped before
the next periodic join. [PR/529408: This issue has been resolved.]
■
■
A performance-related issue may occur when the IDP plug-in is enabled. The
connection per second for HTTP (64 bytes) with AACL, AI, and IDP (with
Recommended Attacks group) plug-ins has been downgraded to 7.6K through
7.9K per second. [PR/476162: This issue has been resolved.]
■
The IPv6 gateway may have a NULL value when the destination address points
to an aggregated next hop. [PR/516058: This issue has been resolved.]
■
NAT over FTP fails when it receives a SERVER 227 code string "Entering passive
mode" in lowercase. [PR/522029: This issue has been resolved.]
■
BFD sessions and other protocol adjacencies configured with low hello or dead
timers over an aggregate or IRB interfaces might flap upon configuration commit
when the dhcp-local-server or dhcp-relay is used. [PR/507428: This issue has
been resolved.]
■
Users who have superuser privileges will sometimes have their access restricted
to view permission only when they log in through TACACS. [PR/388053: This
■
If the time zone is set to “Europe/Berlin,” the command commit at "time-string"
will fail. [PR/483273: This issue has been resolved.]
■
85
■
The group inherited configuration under the interface-range hierarchy level does
not take effect. [PR/522872: This issue has been resolved.]
■
Navigation from Monitor RIP Information page to the Route Information page
fails with errors. [PR/536255: This issue has been resolved.]
■
While upgrading JUNOS Software with l2circuit configuration underthe logical
systems, the validation might fail with an "interface version mismatch" error.
You can ignore this error and upgrade the JUNOS Software using the no-validate
option. [PR/497190: This issue has been resolved.]
■
The routing protocol process crashes repeatedly on the new master, a few minutes
after a graceful Routing Engine switchover (GRES). [PR/527465: This issue has
been resolved.]
VPNs
Release 10.1R2
Class of Service
■
The following operations may result in large incorrect queue statistics on IQ2
interfaces:
■
When the IQ2 PIC is restarted, or the interface is deactivated and reactivated,
while traffic is on and the configuration defines a high priority queue on the
interface.
■
When the high priority queue number is changed under the class-of-service
configuration while traffic is on.
■
The type-of-service (ToS) bits get truncated for IPv6 packets on a service PIC.
■
While the JUNOS Software adopts random as its sampling algorithm, the
SAMPLING_ALGORITHM in the jflowv9 template shows 0x01 (deterministic)
instead of 0x02 (random). [PR/438621: This issue has been resolved.]
■
A JUNOS Software compiler bug in the match combination optimization could
cause an incorrect firewall filter evaluation. [PR/493356: This issue has been
resolved.]
■
When the MS PIC used for an RLSQ interface resides on an E3 FPC (M320), traffic
might stop flowing across the RLSQ interface after the policer on the interface
is deactivated. [PR/498069: This issue has been resolved.]
■
When a Layer 2 policer is configured under a logical interface having multiple
families configured under it, and the policer is changed to another, the newly
configured policer might not take effect unless the policer configuration is
deactivated and reactivated. [PR/501726]
86
■
■
When a filter group is configured on an interface residing on an ES FPC, the
rpf-check configured on that interface will not function correctly. As a
workaround, deactivate the configured filter group. [PR/503609: This issue has
been resolved.]
■
On configuring a three-color-policer, a dfwc core file is generated. [PR/509742:
■
The following messages are displayed on both the primary and secondary RLSQ
MS 500 PICs: “SCHED: %PFE-0: Thread 7 ran for x ms without yielding,"
"Scheduler Oinker." [PR/286357: This issue has been resolved.]
■
CFMD might crash when the following are configured and commited at once on
a VPLS setup:
■
Encapsulation VLAN-VPLS on a physical and logical interface
■
Family VPLS on a logical unit
■
Interface is added in the VPLS routing instance
As a workaround, add the above configurations one at a time and commit.
■
If virtual tunnel PICs and ingress traffic manager is enabled on the same Packet
Forwarding Engine/PIC on an EQ DPC, then the SNMP walk of the interface may
time out. [PR/458565: This issue has been resolved.]
■
In some cases during the periodic error status monitoring, error messages such
as “Wi seg ucode discards in fabric stream” may be displayed on adjacent
streams. These messages are cosmetic and can be ignored. [PR/481344: This
■
When loopback is configured on t3 under ct3, t1 under ct1, or e1 under ce1, no
error syslog message is logged. Additionally, the show interface extensive
command on the t3/t1/e1 displays "loopback" even though it is not actually
applied. [PR/486424: This issue has been resolved.]
■
The DPC remains in the ready state and the demux0 interface remains in a down
state after a chassisd restart without graceful Routing Engine switchover (GRES)
enabled. [PR/492961: This issue has been resolved.]
■
The AE logical interface flaps when the PIC that has the active link-protection
member link is taken offline. [PR/493492: This issue has been resolved.]
■
The No Redundant Config alarm that occurs in JUNOS Release 10.0 and above
after a PEM is shut down is invalid and is a non-impacting alarm message.
■
The one port OC12-3 PIC cannot support eight queues when the no-concatenate
option is configured. [PR/499452: This issue has been resolved.]
■
On a 4-port ChOC3/STM1 and 12–port T1/E1 circuit emulation PICs, the ATM
logical interface packets counter does not increment if the PIC is configured in
the ATM IMA mode. [PR/500153: This issue has been resolved.]
■
87
88
■
■
When t1-options are configured at the [edit interfaces ct1-x/y/z] hierarchy level,
some ct1 interfaces of a 10xCHT1 IQ PIC might flap when the configuration
changes are committed. As a workaround, remove the t1-options. [PR/500820:
■
Polling ifInOctets on Gigabit Ethernet IQ PIC VLANs might momentarily return a
higher value. [PR/500852: This issue has been resolved.]
■
On 40x1 Gigabit Ethernet PICs, very short fragments of fragmented TCP, UDP,
and ICMP packets may be incorrectly dropped with the diagnostic L4 length too
short. [501526: This issue has been resolved.]
■
The configured TTL set for GRE traffic is set properly for locally generated Routing
Engine packets, but is not set properly for transit packets. There is no
workaround. [PR/502087: This issue has been resolved.]
■
During a link UP/DOWN transition, jsscd may crash as a result of a NULL message
dereferencing by jsscd. [PR/502745: This issue has been resolved.]
■
In JUNOS Release 10.1, if the MPCs power up while the A-DPCs are offline, and
if ISSU is performed, the MPCs will crash. [PR/502837: This issue has been
resolved.]
■
When an ATM AIS cell is received from the virtual channel under vlan-vci-ccc
encapsulation, the logical interface will be incorrectly marked down. There is no
■
When the show lacp interface aex command is used for a nonexistent AE interface,
no error is returned. [PR/503806: This issue has been resolved.]
■
The yellow marking for the three-color-policers is incorrect. Even after the excess
burst buffer is full, the yellow counters continue to increment at the same rate
as the green buffers. [PR/504192: This issue has been resolved.]
■
As a result of an incorrect configuration for the DDR memory controller, errors
might be reported when a Trio-based MPC or MX80 boots. There is no
■
Under certain circumstances, the E3 IQ PIC might report bogus CCV, CES, and
CSES alarms. [PR/505921: This issue has been resolved.]
■
The JUNOS Software may accept duplicate data-link connection identifiers (DLCIs)
configured on the same physical interface. [PR/506908: This issue has been
resolved.]
■
When native-vlan-id is configured for aggregated interface with the child links on
an IQ2 PIC, the LACP are dropped and the links go down. [PR/507040: This issue
has been resolved.]
■
The show interfaces diagnostics optics interface command does not display the
unit of measurement when the received power is in a very low range (power <
5e-10). It shows the value of 0.00 without any unit of measurement. [PR/507653:
■
On MX Series routers, the chassisd crashes when the SCB is taken offline and
removed. [PR/510950: This issue has been resolved.]
■
On M7i and M10i routers, the syncer process writes to the file
/var/rundb/chassisd.dynamic.db every 30 seconds. [PR/511901: This issue has
been resolved.]
■
Under certain circumstances, the chassisd process might crash on a backup
Routing Engine while a configuration is commited. [PR/512044: This issue has
been resolved.]
■
Due to a flaw in implementation, the execution of the show interfaces
mac-database command causes the IQ2 PIC to reboot with the core. [PR/513407:
■
The local protocol MTU on an interface with PPP encapsulation might become
higher than the configured media MTU after the PPP negotiation when the remote
end has a higher media MTU configured. [PR/514079: This issue has been
resolved.]
■
The monitor traffic interface (tcpdump) does not produce an outbound output
with matching option when used with the encapsulation
flexibile-ethernet-services. [PR/514247: This issue has been resolved.]
■
The DHCPv6 clients do not bind when routing-options access-internal is
configured. [PR/495358: This issue has been resolved.]
■
On MX960 routers, i2c messages related to the fan such as the following are
displayed:
Jan 26 13:32:22 rocky-re0 /kernel: PCF8584(WR): target ack failure on byte 0
Jan 26 13:32:22 rocky-re0 /kernel: PCF8584(WR): (i2c_s1=0x08, group=0xe,
device=0x54)
This is a cosmetic issue and has no impact on the router. [PR/500824: This issue
has been resolved.]
■
The SIP domain names encoded in the DHCPv6 attributes do not conform to
RFC 3319. [PR/512073: This issue has been resolved.]
■
The JUNOS Software drops SOLICIT messages, including the rapid commit option,
instead of ignoring that option and processing the remainder of the message.
■
When an RSVP LSP is configured with the no-install-to-address option and is not
associated with CCC connection flaps, the routing protocol process will crash
when the LSP comes up again. To avoid the problem, make sure that the LSP is
either a transmit LSP for a CCC connection or that the install option is also
configured on the LSP. [PR/471339: This issue has been resolved.]
■
A rare condition between the MVPN and RSVP P2MP signaling leads to the
creation of stale flood next hops. [PR/491586: This issue has been resolved.]
■
An incorrectly changed LDP session authentication key causes the LDP session
to fail, which results in the LDP/IGP syncronization feature not working. The IGP
continues to advertise the link at normal metric values. [PR/499226: This issue
has been resolved.]
MPLS Applications
■
89
■
In cases where the secondary Routing Engines contain no label-switched paths
in the up state due to the lack of NSR support, such label-switched paths might
not come up even after a switchover. [PR/501969: This issue has been resolved.]
■
LDP might not handle certain error conditions gracefully when NSR is enabled.
This might cause the LDP replication state to be stuck in the "In Progress" state
forever. [PR/505043: This issue has been resolved.]
■
The name of the bypass label-switched path supports only 32 characters instead
of 64. [PR/515244: This issue has been resolved.]
■
Under certain SNMP conditions, the following log message is displayed:
Network Management
M10i-RE0 pfed: PFED_NOTIF_GLOBAL_STAT_UNKNOWN: Unknown global
notification stat: transit options/ttl-exceeded (re-injected)
M10i-RE0 pfed: PFED_NOTIF_STAT_UNKNOWN: Unknown notification type stat:
Unknown
This log message might also be displayed during the installation of AI Scripts
(version 2.1R2 or above) on the router. AI Scripts versions prior to 2.1R2 do not
cause these messages. This is a cosmetic message, and does not have any impact.
■
Under certain conditions, the SNMPD crashes due to a BAD_PAGE_FAULT.
■
When certain FPCs (T1600-FPC4-ES, T640-FPC4-1P-ES, T640-FPC1-ES,
T640-FPC2-ES, and T640-FPC3-ES) receive corrupted cells via high-speed links,
they might unnecessarily reboot and report the following system log error
message: "Unrecoverable Error: Flist gtop bit toggled !." No reset is needed to
recover from this condition. [PR/441844: This issue has been resolved.]
■
The configured static NDP entry is cleared automatically after a certain interval.
■
When the flow monitoring version 9 feature is enabled on an MS PIC (or service
PIC that supports flow monitoring version 9), the MS PIC might crash upon
receiving certain corrupted IPv6 packets. [PR/458361: This issue has been
resolved.]
■
When an aggregated SONET with a Cisco High-Level Data Link Control (HDLC)
encapsulation is configured, a member link might not be marked as link-down
in the Packet Forwarding Engine if the remote end of the link is disabled.
■
The output of the show arp command does not display the entire demux interface
identifier, making it impossible to determine which specific demux sub-interface
a given ARP entry is associated with. [PR/482008: This issue has been resolved.]
■
A problem occurs on an M120 router with an FEB redundancy configuration
when the backup FEB is protecting a non-primary FEB. In this case, the Routing
90
■
Engine will prompt the incorrect Packet Forwarding Engine for status, causing
delays in the SNMP responses. [PR/490172: This issue has been resolved.]
■
If you configure an IP address with a larger subnet, for example, /19, on a
different interface first, the router begins to negotiate for the ARP of a specific
host on that interface and gets stuck in a hold state. If you later configure a more
specific subnet of /29 on another interface from where the host can be reached,
the forwarding table will still prefer the route with the hold entry via /19 instead
of the route with the ucst entry via /29. [PR/491468: This issue has been resolved.]
■
The syslog usually logs data only when the per-fabric-stream counter increases.
However, the syslog starts logging even though the counter value was not
increasing. [PR/493384: This issue has been resolved.]
■
The Source Class Usage (SCU) statistics counter value may drop occasionally
when it is used with the accounting profile. [PR/493662: This issue has been
resolved.]
■
The AE VLAN session classifier instantiation in a dynamic profile fails as the L2
classifier fails to install in the Packet Forwarding Engine. [PR/494488: This issue
has been resolved.]
■
In certain cases, a configuration change can cause the backup Routing Engine
to reboot. [PR/497290: This issue has been resolved.]
■
When a next-hop chain has multiple types of next-hop dependencies, including
indirect next-hop, aggregate next-hop, and multiple unicast next-hops, during
an aggregate link flap (down/up), a certain sequence of events from the kernel
is expected by the Packet Forwarding Engine for the next-hop change and delete
updates. However, during a quick link flap (down/up), in an extreme corner case,
the Packet Forwarding Engine does not receive the expected sequence, and the
FPC will crash. [PR/499315: This issue has been resolved.]
■
On IQ2 PICs, when copy-plp is enabled under class of service, the DCU provides
the wrong statistics. [PR/499378: This issue has been resolved.]
■
The MAC address of a configured static NDP entry is overwritten upon receiving
NA from a connected device. [PR/499418: This issue has been resolved.]
■
The static NDP entry remains permanent if the refcount is more than 1, even
after deleting the static configuration. [PR/499441: This issue has been resolved.]
■
The L2RW does not report an error when the required L2_pgm length is longer
than what the hardware can support. [PR/501318: This issue has been resolved.]
■
On an ichip platform, when the downstream multicast member link flaps, the
Packet Forwarding Engine rarely has a chance to fail multicast next-hop handling.
This can cause multicast traffic drops. [PR/501852: This issue has been resolved.]
■
On an MX Series router configured for PPP subscriber access, subscribers will
experience slow login times as the number of subscriber sessions increases.
■
RED drops occur in the SMQCHIP when the 10x10GE OSE and 4x10GE PICs are
swapped multiple times. [PR/506174: This issue has been resolved.]
■
91
■
On a TX Matrix Plus router, if one of the two external RJ45 links between a
TXP-CIP and an LCC Control Board is broken, the router does not generate an
alarm. [PR/508219: This issue has been resolved.]
■
On tcpdump or when the monitor traffic interface command is used for an lo0
interface with the IP address having its last octet is greater than or equal to 224
(x.x.x.224 or higher), following message is received: "inet class for 0xe1e11955
unknown." [PR/511911: This issue has been resolved.]
■
If a static route points to a discard configuration, a failure might occur when the
router attempts to collect the multicast statistic data. [PR/434298: This issue has
been resolved.]
■
Deleting a logical system causes the routing protocol process to be stuck in an
infinite loop. [PR/439000: This issue has been resolved.]
■
The routing protocol process dumps core due to a soft assertion failed:
"rt_notbest_sanity: Path selection failure" in rt_table.c. As a workaround, use
the bgp path-selection external-router-id statement or the bgp path-selection
always-compare-med statement. [PR/451021: This issue has been resolved.]
■
When a PIC with a PIM-enabled interface is brought online, the router may send
the first PIM hello slightly before the interface comes up. This causes the router
to drop the first PIM hello message towards its neighbor. [PR/482903: This issue
has been resolved.]
■
After a graceful Routing Engine switchover (GRES) event with NSR enabled and
a scaled L3VPN eBGP test, some BGP sessions fail due to an expired hold down
timer if the hold-down timer is lower than the default 30 seconds. To avoid this
issue, set the hold-down timer to the default value of 30 seconds. [PR/501796:
■
In an NSR configuration, the backup Routing Engine can lose the connection to
the active Routing Engine during a configuration commit. The problem occurs
more often when the configuration includes a large number of routing instances.
This is caused by the routing protocol process on the backup Routing Engine
leaking file descriptors during commit synchronization. To recover, restart the
routing protocol process on the backup Routing Engine. [PR/506883: This issue
has been resolved.]
■
When the routing-instances routing-instances-name routing-options multipath
vpn-unequal-cost equal-external-internal statement is configured, some VPN routes
learned from different route reflectors can be shown as multipath. [PR/507236:
■
The routing protocol process might crash if the router receives a flow route with
a rate-limit bandwidth less than 1000 bps. [PR/508715: This issue has been
resolved.]
■
When more than 200 IGMP/MLD source-specific multicast groups (232.0.0.0/8)
are configured statically on an interface, and when an unrelated configuration
is committed, some groups are removed and added immediately after. This
causes packet drops on those groups. [PR/509013: This issue has been resolved.]
Routing Protocols
92
■
■
is used with a L2VPN routing-instance. [PR/513949: This issue has been resolved.]
■
In route reflector and ASBR VPN scenarios, the routing protocol process might
crash as changes occur to a prefix in the primary table at the same time as BGP
tries to send out updates via the secondary table. [PR/515626: This issue has
been resolved.]
■
If the Juniper-Firewall-Attribute attribute in a RADIUS server configuration file
names a policer that sets a bandwidth limit for Layer 2 Tunneling Protocol (L2TP)
sessions but not an exclude-bandwidth limit, the bandwidth limit might not be
set correctly. [PR/254503: This issue has been resolved.]
■
On M Series routers (M120 and M320) with many service sets configured with
IDP policies, kernel messages are seen in the messages file once traffic passes
through these service sets. These messages stop when the traffic is stopped.
■
A static route pointing to a destination is incorrectly added for a source NAT
when a next-hop type service set is used. [PR/476165: This issue has been
resolved.]
■
Flow monitoring records are not generated as fragmented IPv6 packets are not
getting sampled. [PR/478571: This issue has been resolved.]
■
MSDPC might crash while running a combination of SIP and other ALGs due to
a possible double freeing of memory. [PR/491218: This issue has been resolved.]
■
The SIP ALG on the services PIC might cause NAT port leaks in some call
scenarios. [PR/491220: This issue has been resolved.]
■
The l2tp on an M7i LNS crashes following an upgrade from JUNOS Release 9.3R1
to 9.6R2. [PR/498423: This issue has been resolved.]
■
When using a NAT DCE RPC ALG on a services PIC, the PIC might crash while
processing the binding request. [PR/510997: This issue has been resolved.]
■
Route changes might not be updated in the PIC meta-db in cases where the route
messages that the PIC receives signify a change in the next-hop index.
[PR/512229]
■
The wildcard apply groups do not work properly in JUNOS Release 9.1 and above.
■
If a user in the Backup Routing Engine on a config-private mode activates graceful
Routing Engine switchover (GRES) and performs a commit synchronize, a
synchronization error might occur during the switchover. [PR/486637: This issue
has been resolved.]
■
Commit fails when the commit scripts are used and the configuration contains
a policy which uses an apply-group with a then action of 'then community +
export.' [PR/501876: This issue has been resolved.]
■
93
■
The load replace command does not consider the allow-configuration
configuration. [PR/501992: This issue has been resolved.]
■
In configure private mode, activating and deactivating two consecutive nested
objects can cause a syntax error during commit. [PR/506677: This issue has
been resolved.]
■
On M10i, M120, M320, and MX Series routers with dual Routing Engines running
JUNOS Release 9.4 or later, the dfwd process running on the backup Routing
Engine might access the /var/pdb/rdm.taf file every 30 seconds, causing excessive
writes to the hard disk drive. This problem does not occur when GRES is enabled.
■
When different prefixes are advertised to the same source by different PE routers,
an egress PE router is prevented from picking the lower prefix route for RPF
when the PR advertising the higher prefix loses its route to the source.
■
When multipath is enabled in a routing instance with NG MVPN, the traffic might
get dropped on the receiver PE. [PR/508090: This issue has been resolved.]
VPNs
Release 10.1R1
The following issues have been resolved since JUNOS Release 10.0R4. The identifier
following the description is the tracking number in our bug database.
Class of Service
94
■
■
When you set the port speed of a multirate SONET Type 2 PIC to OC3, the CoS
speed value is not changed correctly within the Packet Forwarding Engine. The
speed value remains OC12, which results in unexpected CoS behavior. There is
no workaround. [PR/279617: This issue has been resolved.]
■
When a VLAN ID is changed, the following message appears in the messages
log: "COSD_GENCFG_WRITE_FAILED: GENCFG write failed for Classifier to IFL
74. Reason: File exists.” This log message appears when the configuration is
committed with VPLS configured on the Gigabit Ethernet interface, and the
class-of-service classifier or rewrite rules that contain IEEE 802.1P on the interface
are used. [PR/408552: This issue has been resolved.]
■
If a logical interface is configured or added to an interface-set for which an
existing traffic control profile is applied, any rate-limit functionality will not be
applied to the new logical interface. To correct this problem, deactivate and
activate the interface portion of the class-of-service configuration. [PR/485872:
■
On an I-chip-based platform for strict high priority queue (SHQ), the buffer size
allocated by the Packet Forwarding Engine is capped by the tx-rate. If the tx-rate
is configured to a very small value or is not configured, and is automatically
allotted a zero or a very small remaining value; the queue is also allotted a
proportionately small delay buffer. This can sometimes lead to red and tail drops
on the SHQ when there is a burst of traffic (with a certain traffic pattern) on it.
As a workaround, configure a nominal tx-rate value (5 percent) for the SHQ.
■
the packet enters the GRE tunnel with a clear-dont-fragment bit enabled.
Additionally, on an Enhanced FPC or M120 FEB, the packet is also likely to be
dropped if it is classified to a packet loss priority (PLP) other than low.
■
In a scaled configuration, the class-of-service classifier does not work properly.
■
When a logical interface set has a shaping-rate less than the sum of transmit-rates
of its queues and when the configuration is corrected so that the logical interface
set gets the correct shaping-rate, ADPC might crash. [PR/523507: This issue has
been resolved.]
■
On an MX-FPC Ichip physical interface queueing with rate-limit or exact
configuration enabled, the in-contract traffic is dropped when other queues are
over-subscribed. [PR/526339: This issue has been resolved.]
■
Policers cannot be modified after a system upgrade due to a flaw in the parser
routine. This error occurs when the current item is deleted and the parser cannot
proceed to the next item. With the fix, the routine in the forwarding process
(dwfd) has been modified so that the next item in the object tree is fetched before
the current object is parsed. [PR/433418: This issue has been resolved.]
■
While the JUNOS Software adopts random as its sampling algorithm, the
SAMPLING_ALGORITHM in the flow monitoring version 9 template shows 0x01
(deterministic) instead of 0x02 (random). [PR/438621: This issue has been
resolved.]
■
A JUNOS Software compiler bug in the match combination optimization can
cause an incorrect firewall filter evaluation. [PR/493356: This issue has been
resolved.]
■
When a Layer 2 policer is configured under a logical interface that has multiple
families configured under it, and the policer is changed to another, the newly
configured policer might not take effect unless the policer configuration is
deactivated and reactivated. [PR/501726: This issue has been resolved.]
■
When a filter with an ip-options "any" firewall match is applied on an interface
on the MX-MPC, the filter is not applied. If the hardware is present at the time
of the configuration commit, a commit warning is issued. However, the commit
does not fail and the rest of the configuration is applied. [PR/524519: This issue
has been resolved.]
■
On T640 and T1600 routers with ST chipset FPCs, in some cases where the IPv6
firewall filters with match conditions configured on address prefixes are longer
than 64 bits, the filter may not be evaluated correctly. This might lead to loss of
packets. [PR/524809: This issue has been resolved.]
■
When logical systems are configured, the show bridge-domains operational
command might timeout and return the following error message: “error: time
■
95
out communicating with l2-learning daemon.” [PR/536604: This issue has been
resolved.]
■
The MX DPC might reboot with the error message: "EZ:
ezchip_get_srh_msg_from_srhq". [PR/310223: This issue has been resolved.]
■
The backup Routing Engine can fail to obtain mastership in the following cases:
■
re0 gets stuck and doesn't reboot.
■
Due to a hardware problem, re0 looses its connectivity with both the Control
Board and the Packet Forwarding Engine.
■
When a backup Routing Engine is replaced after a graceful Routing Engine
switchover (GRES), the device control process (dcd) generates a new link local
address on non-MAC interfaces such as SONET. [PR/429078: This issue has been
resolved.]
■
CFMD might crash when the following is configured and commited at once on
a VPLS setup:
■
Encapsulation VLAN-VPLS on a physical and logical interface
■
Family VPLS on a logical unit
■
Interface is added in the VPLS routing instance
As a workaround, add the above configurations one at a time and commit.
96
■
■
When lockout is configured and the router is rebooted, the working router is
stuck in the wait-to-restore state while the protect router still shows channel state
working and no requests, but no longer shows the lockout flag. [PR/474482: This
■
When an IQ2 PIC is brought online with a class-of-service configuration that
includes a scheduler using the rate-limit options, the system incorrectly reports
that rate limiting is not supported on the PIC. [PR/482199: This issue has been
resolved.]
■
The AE logical interface flaps when the PIC that has the active link-protection
member link is taken offline. [PR/493492: This issue has been resolved.]
■
On MX Series routers, traffic is forwarded over the backup link even after the
primary link is disabled and enabled again. [PR/493861: This issue has been
resolved.]
■
When link trace entries are added in the path database, there is no check to see
if the current number of entries have reached the path database size. Due to
this, the entries were get learnt beyond the path database size (configured or
default). [PR/494584: This issue has been resolved.]
■
Polling ifInOctets on Gigabit Ethernet IQ PIC VLANs might momentarily return a
higher value. [PR/500852: This issue has been resolved.]
■
Under certain circumstances, a backup Routing Engine reboot followed by a
Routing Engine failover can cause the LACP to flap, which causes AE bundles to
flap. [PR/502937: This issue has been resolved.]
■
When the show lacp interface aex command is used for a nonexistent AE interface,
no error is returned. [PR/503806: This issue has been resolved.]
■
If a T640-FPC4-ES is installed in a T1600 router and an SIB statistics collection
is performed, the message log might report "JBUS: U32 read error, client .." only
if one of the SIBs is faulted or in the offline state. This system log message will
also appear if the T640-FPC4-ES FPC is removed from the chassis. There is no
operational impact. [PR/504363: This issue has been resolved.]
■
On MX Series routers with JUNOS Release 10.0R2 or higher, the backup Routing
Engine might report the following warning message upon commit once network
service is configured under the chassis stanza: "WARNING: network services flag
has been changed, please reboot system." [PR/505690: This issue has been
resolved.]
■
On an M20 router with AC PEMS, the alarm message “Power Supply x not
providing power” is generated when the power cord is removed. The alarm is
not cleared when the power cord is reconnected. [PR/506413: This issue has
been resolved.]
■
When an FEB switchover occurs on an Ichip with APS protect status enabled,
the traffic is duplicated. [PR/506747: This issue has been resolved.]
■
The JUNOS Software may accept duplicate data-link connection identifiers (DLCIs)
configured on the same physical interface. [PR/506908: This issue has been
resolved.]
■
The Routing Engine on slot 1 takes mastership regardless of the user-configured
Routing Engine mastership priority. [PR/507724: This issue has been resolved.]
■
On M7i routers with JUNOS Release 8.5 or later, the output of the show interfaces
fxp0 command shows the fxp0 interface to be in the link up state even when
the interface is disabled with no cables connected. [PR/508261: This issue has
been resolved.]
■
The AE interface does not generate ICMP redirect messages. [PR/508691: This
■
On M7i and M10i routers, the syncer process writes to the file
/var/rundb/chassisd.dynamic.db every 30 seconds. [PR/511901: This issue has
been resolved.]
■
Under certain circumstances, the chassisd process might crash on a backup
Routing Engine while a configuration is commited. [PR/512044: This issue has
been resolved.]
■
When the 1x10GE PIC is taken online, 1x10GE PIC related error messages displays
in the logs. However, these messages do not have any functional impact.
■
When a container logical interface unit is added or deleted, an APS channel
mismatch trap is raised from all the protect container interfaces. [PR/512825:
■
97
■
Due to a flaw in implementation, the execution of the show interfaces
mac-database command causes the IQ2 PIC to reboot with the core. [PR/513407:
■
APSD does not perform a switchover to the primary circuit, and both the primary
and secondary circuits remain disabled when the following steps are performed:
■
Force traffic from the primary circuit to the secondary circuit.
■
Remove the Tx on the secondary circuit at the local end, or insert LOS on
the secondary circuit from the near end to the far end.
98
■
■
When the show chassis hardware models command or the show chassis hardware
| display xml command is used, the FRU part-number 710-013035 displays the
model number T1600-FPC3-ES instead of T640-FPC3-ES. [PR/514072: This issue
has been resolved.]
■
When the show chassis hardware models or show chassis hardware | display xml
command is issued for M320-FPC*-E3 with part-numbers 710-025464,
710-025853, and 710-025855, the model number does not display correctly.
■
A local protocol MTU on an interface with PPP encapsulation might be higher
than the configured media MTU after a PPP negotiation when the remote end
has a higher media MTU configured. [PR/514079: This issue has been resolved.]
■
The monitor traffic interface (tcpdump) does not produce an outbound output
with matching option when used with the encapsulation
flexibile-ethernet-services. [PR/514247: This issue has been resolved.]
■
Due to a 32 bit timer overflow, the SPC BCM register does not read properly.
This is a cosmetic issue. [PR/514325: This issue has been resolved.]
■
When traffic flows across IQE SDH/SONET interfaces, instantaneous inaccurate
traffic rate values with smaller packet sizes occur when the show interface
command is issued. [PR/514330: This issue has been resolved.]
■
The SIB details might not display in the output of the show chassis hardware
command after the SIB is inserted in the slot. [PR/515789: This issue has been
resolved.]
■
Under certain conditions, some Packet Forwarding Engines may fail to install
VPN multicast routes when downstream interfaces are RLSQ bundles. [PR/515878:
■
The T1600-FPC4-ES might experience HSL2 CRC errors at the fabric portion
leading to "destination errors," "Check SIB," and other fabric plane errors. It is
recommended to upgrade the JUNOS Software to a version that contains the fix.
■
On some XENPAK modules, the output of the show chassis hardware command
shows the message "NON-JNPR UNKNOWN" when the FPC is booted. There is
no impact on the traffic. To solve this issue, take the PIC offline and bring it back
online. [PR/516411: This issue has been resolved.]
■
On an M120, M7i, or M10i router with Enhanced CFEB running JUNOS Release
10.0 and a VRF routing instance configured with vrf-table-label, the VPN traffic
might not flow when an ATM II IQ PIC is used for a core-facing link. [PR/516485:
■
When a Frame Relay interface goes down, the interface statistics might still
indicate that the data-link connection identifier (DLCI) is active. [PR/516497:
■
When the configuration of shaping and scheduling is added or removed from
the CLI, the traffic from the other PE routers is lost. [PR/517320: This issue has
been resolved.]
■
On IQ2 and IQ2E 10GE PICs operating in WAN-PHY mode, the path trace
information is not transmitted to the remote end. [PR/518331: This issue has
been resolved.]
■
In JUNOS Release 10.0 and later, the MIB value for OID ifSpeed and ifHighSpeed
on the aggregated Ethernet logical interface is shown incorrectly as 0. This occurs
when the bandwidth of the logical interface is not configured for the aggregated
Ethernet interface. [PR/519855: This issue has been resolved.]
■
When the centralized configuration management (CCM) interval is set to 1m or
above, the CCM flaps for an incorrect hold_time adjacency entry. [PR/520064:
■
The CE_SUPPORT-DCD crashes when a commit is performed. [PR/521380: This
■
When multiple routed IPsec tunnels are configured, and the tunnel with the
inside-service-interface defined in the service-set goes down, the other tunnels
with the ipsec-inside-interface configured only in the IPsec rules might stop
forwarding traffic until the main tunnel comes back up. [PR/524935: This issue
has been resolved.]
■
the FPCs restarts, the restarting FPC might not initialize properly and might result
in a small percentage of packet loss for all interfaces on that FPC. As a
workaround, restart the FPC. [PR/529994: This issue has been resolved.]
■
When the clear interfaces statistics command is used, if a member link is
deactivated from an aggregate (AE or AS on any platform) and if the show
interfaces extensive command is used immediately, incorrect values (very high
values) might be seen for the counters such as Transmitted and Queued packets
under the Queue counters. If the clear interface statistics command is not issued
prior to deactivating the member link, this will not occur. [PR/530297: This issue
has been resolved.]
■
When any subscriber interface (PPPoE or DHCP) is used, the VPLS connections
■
When Automatic Protection Switching (APS) is configured on a 4x STM-1 SDH,
SMIR PIC, the transmitted value of the K2 byte shows 0x00 for both unidirectional
and bidirectional instead of 0x04 and 0x05, respectively. [PR/531030: This issue
has been resolved.]
■
99
■
On MX960 routers, the link status stays in the "Link ok" state when the SCB is
removed without taking it offline through the CLI or switch. [PR/536860: This
■
On MX Series routers with 10.x Power Budget, after a “Power Budget: Chassis
experiencing power shortage” alarm occurs, the alarm does not clear even after
the power budget problem is cleared. [PR/540522: This issue has been resolved.]
■
When an ATM II interface is configured as a Layer 2 circuit with cell transport
mode on a router running JUNOS Release 8.2 or lower, interoperability issues
with other network equipment and another Juniper router running JUNOS Release
8.3 or higher may occur. [PR/255622: This issue has been resolved.]
■
The bpdu-block-on-edge configuration may not work properly when the interface
is configured as 'edge' at the [edit protocols vstp vlan vlan-id interface
interface-name] hierarchy level. [PR/522198: This issue has been resolved.]
■
A Spanning Tree Protocol triggered MAC flush might fail if there are frequent
topology changes with a significant number of MAC addresses learned. For
multiple Spanning Tree Protocols, restart l2cpd-services to come out of the state,
and for the Rapid Spanning Tree Protocol, reboot the corresponding DPC.
■
With BFD enabled over IGP and an RSVP session built across it, when the RSVP
peer does not support RSVP Hello (or is disabled), the BFD session down event
triggers only the IGP neighbor to go down. The RSVP session remains up until
a session timeout occurs. [PR/302921: This issue has been resolved.]
■
When a direct link between two PEs is disabled, the P2MP MPLS LSP may go
down with the CSPF error "bad strict route." [PR/500146: This issue has been
resolved.]
■
In cases where the secondary Routing Engine contains no label-switched path
up states due to lack of NSR support, such label-switched paths may not go to
the up state even after a switchover. [PR/501969: This issue has been resolved.]
■
The routing protocol process might crash with an assert in rsvp_PSB_set_selfID
while a graceful Routing Engine restart is performed when P2MP LSPs are present.
■
The name of the bypass label-switched path supports only 32 characters instead
of 64. [PR/515244: This issue has been resolved.]
■
A targeted LDP neighbor may remain up with an old IP address that was
previously in use with the loopback address on the remote neighbor. This may
occur when either of the following is performed on the remote neighbor:
MPLS Applications
100
■
■
A secondary loopback (lower than the current primary) address is added
and no primary keyword is associated with either of these addresses.
■
A second loopback address is added with the primary keyword.
This results in the targeted LDP neighbor being up with both IP addresses. The
neighbor with the old address may continue to remain up even after the old
loopback address is deleted on the remote neighbor. This neighborship with the
old address eventually times out when the router-id is changed to reflect the new
loopback address on the remote neighbor. [PR/518102: This issue has been
resolved.]
■
At adjust intervals, the maximum average bandwidth utilization for the LSP
should be reset to zero. MPLS sometimes fails to reset the maximum average
bandwidth utilization for the LSP to zero while performing a periodic
auto-bandwidth adjustment at the adjust interval. This prevents periodic
auto-bandwidth adjustment from adjusting to a lower bandwidth when the traffic
rate drops. [PR/528619: This issue has been resolved.]
■
The maximum average bandwidth utilization computed by MPLS for
auto-bandwidth might sometimes be higher than the actual traffic rate (twice
the traffic rate). This occurs when the MPLS statistics response from the Packet
Forwarding Engine comes in late, and two statistic entries for the same LSP fall
in the same MPLS auto-bandwidth averaging timer interval. [PR/536759: This
■
After an LCC switchover, the SNMP process fails to send traps with resource
temporarily unavailable errors. [PR/493385: This issue has been resolved.]
■
Memory leaks might occur on the mib2d. [PR/517565: This issue has been
resolved.]
■
The SNMPD might crash when the filter-duplicate statement is used. [PR/519389:
■
SNMP might stop working after a router reboot, DPC/FPC/MPC restart, or a
■
The SNMP MIB OID tree under dot3adAggPort fails. This issue might occur when
virtual LAN tagging is not configured on the AE interface, and if the mib2d process
is restarted using the restart mibprocess command. [PR/528555: This issue has
been resolved.]
■
The telnetd core file can be seen on routers enabled with telnet service.
■
On M7i routers, kernel panic might occur during route changes. [PR/439420:
■
If you configure an IP address with a larger subnet, for example, /19, on a
different interface first and the router begins to negotiate for the ARP of a specific
host on that interface and gets stuck in a hold state. If you later configure a more
specific subnet of /29 on another interface from where the host can be reached,
the forwarding table will still prefer the route with the hold entry via /19 instead
of the route with the ucst entry via /29. [PR/491468: This issue has been resolved.]
Network Management
■
101
102
■
■
The Source Class Usage (SCU) statistics counter value might drop occasionally
when used with the accounting profile. [PR/493662: This issue has been resolved.]
■
The AE VLAN session classifier instantiation in a dynamic profile fails as the L2
classifier fails to install in the Packet Forwarding Engine. [PR/494488: This issue
has been resolved.]
■
On an MX Series router , an uRPF with more than 16 route paths can trigger a
jtree error and might cause the DPC to crash. [PR/509091: This issue has been
resolved.]
■
In a setup with two VPN routing and forwarding tables (VRFs) of a provider edge
connected to different customer edges and auto-export configured, when a ping
is executed from a customer edge to a provider edge interface in the other VRF
, the Internet Control Message Protocol reply returns the source interface IP of
the provider edge that is connected directly, instead of the interface IP of the
other VRF provider edge. [PR/510834: This issue has been resolved.]
■
Memory leaks might occur on the mib2d rtslib. [PR/510902: This issue has been
resolved.]
■
The VPN PIM neighborship over the mt- interfaces might not recover after a
■
On tcpdump or monitor traffic interface for a lo0 interface with an IP address
having the last octet >= 224 (x.x.x.224 or higher) , the following message
displays: "inet class for 0xe1e11955 unknown." [PR/511911: This issue has been
resolved.]
■
Under rare conditions, the compressed system-generated routing protocol process
core files might be corrupted. As a workaround, disable the compression using
sysctl kern.compress_user_cores. [PR/513193: This issue has been resolved.]
■
Setting the TCP maximum segment size (MSS) might not change the actual MSS
value. [PR/514196: This issue has been resolved.]
■
On M120 and MX Series routers, when an AE interface (with LACP enabled) is
used as a core-facing interface for L3VPN, non-MPLS traffic received on the AE
interface can sometimes get black-holed. To recover from this state, deactivate
and reactivate the AE interface in the configuration. [PR/514278: This issue has
been resolved.]
■
When IGMP snooping is enabled, a multicast traffic drop might be seen if an
IGMP join or leave occurs on other interfaces. [PR/515420: This issue has been
resolved.]
■
When the primary link flaps with the route-memory-enhanced statement enabled,
jtree might get corrupted and traffic forwarding is affected. As a workaround,
deactivate the route-memory-enhanced statement under the chassis stanza.
Changes to the route-memory-enhanced statement take effect only when Packet
Forwarding Engine is rebooted. [PR/517919: This issue has been resolved.]
■
On some M Series, MX Series, and T Series routers, when a firewall filter is
applied on the egress of an aggregate interface, packet loss might occur after
adding, removing, or changing the service configuration on the egress side of
the aggregate interface. As a workaround, deactivate and reactivate the output
firewall filter on the aggregate interface. [PR/517992: This issue has been
resolved.]
■
Under certain conditions, traffic flow through an RLSQ bundle can be dropped
after it is removed and added back to a VPN routing and forwarding table (VRF).
■
When container AE interfaces are enabled on JUNOS Release 10.0 or 10.1, the
following message displays when one of the member links flap: “CHPJAR1-re0
fpc3 SCHED: %PFE-0: Thread 40 (PFE Manager) ran for 2015 ms without
yielding.” [PR/518714: This issue has been resolved.]
■
When the destination class usage (DCU) is configured with a unicast reverse-path
filter (uRPF) and egress forwarding-table filter within the VRF, a VPN route flap
might trigger a jtree memory leak. [PR/521609: This issue has been resolved.]
■
When a socket connection between the Routing Engine and the FPC is
reestablished, the FPC might run into a software crash because of an invalid
counter being referenced. There is no workaround. [PR/525357: This issue has
been resolved.]
■
On MX Series routers, repeated graceful Routing Engine switchover (GRES) under
certain configurations might result in kernel panics. Three kernel cores are
observed: with a soft update files system trace, with a TCP packet processing
stack trace, and with a trace of IFF configuration write. [PR/525583: This issue
has been resolved.]
■
On some routers, enabling IP-payload-based load balancing for MPLS packets
can cause some pseudowire packets to be reordered. [PR/528657: This issue
has been resolved.]
■
Asp_ifl_update messages might be seen on routers running JUNOS Release 10.0
and higher. Ignore these messages as they do not impact functionality.
■
A router might send raw IPv6 host-generated packets over the Ethernet towards
its BGP IPv6 peers. [PR/536336: This issue has been resolved.]
■
On some M Series, MX Series, and T Series routers, when a family CCC filter is
applied on multiple interfaces that belong to different L2VPN routing instances,
packet loss might occur after the routing instances are deactivated and
reactivated. As a workaround, deactivate and reactivate the CCC filter on the
interfaces. [PR/521357: This issue has been resolved.]
■
The backup Routing Engine might generate routing protocol process and kernel
cores if the BGP damping is configured along with nonstop active routing (NSR).
■
PIM asserts in dense groups can lead to a routing protocol process memory leak.
■
When a PIC with a PIM-enabled interface is brought online, the router might
send the first PIM hello slightly before the interface comes up. This causes the
router to drop the first PIM hello message towards its neighbor. [PR/482903:
Routing Protocols
■
103
104
■
■
The Juniper Networks rendezvous point (RP) does not process PIM Register
messages from a first-hop router in an IPv6 embedded RP group when the
Register message does not have the null-bit set. [PR/486902: This issue has been
resolved.]
■
When nonstop active routing (NSR) is running and BGP groups are added (eg a
VRF with a BGP in it), the routing protocol process might crash. As a workaround,
configure the new BGP groups after disabling the NSR. Then. reenable the NSR.
■
When l3vpn-composite-next-hop is configured, it should only be used by Layer
3 VPN routes. However, non-Layer 3 VPN routes are also able to use it.
■
After a graceful Routing Engine switchover (GRES) event with NSR enabled and
a scaled Layer 3 VPN eBGP test, some BGP sessions fail due to an expired
hold-down timer if the hold-down timer is lower than the default 30 seconds.
To avoid this issue, set the hold-down timer to the default value of 30 seconds.
■
When a family inet6 addressing is added to a router configured with multicast
VPN, the routing protocol process might crash and restart. [PR/503296: This
■
Upon a graceful Routing Engine switchover with NSR, the routing protocol process
will crash due to a wrong process for the PIM instance. [PR/503921: This issue
has been resolved.]
■
is used with a Layer 2 VPN routing-instance. [PR/513949: This issue has been
resolved.]
■
When multiple sham-links are configured with the same remote endpoint IP
address, a commit error occurs and configuration checkout fails. [PR/515343:
■
In route reflector and ASBR VPN scenarios, the routing protocol process might
crash as changes occur to a prefix in the primary table at the same time as BGP
tries to send out updates via the secondary table. [PR/515626: This issue has
been resolved.]
■
The mirror receive task variable might not be cleared when the routing protocol
process is heavily scaled. Hence, the NSR replication for RIP status stays in the
"InProgress" state forever. [PR/516003: This issue has been resolved.]
■
A warning message displays when the show igmp snooping interface command
is used with no IGMP snooping configured. [PR/516355: This issue has been
resolved.]
■
The configured robust count value is not applied on the non-querier router when
it receives a robust count value of 0. It uses the default value (2) instead of the
configured value. [PR/520252: This issue has been resolved.]
■
The new NSR master might not send the OSPF hello messages immediately after
a switchover. [PR/522036: This issue has been resolved.]
■
After a graceful restart, the forwarding state of both provider edge routers might
get stuck at the pruned state. However, traffic flow is not affected. [PR/522179:
■
Upon an NSR mastership switch or ISSU upgrade, the multicast resolve route for
IPv4 224/4 or inet6 ff00::/8 might be missing within the forwarding table. To
recover from this condition, deactivate and reactivate the protocol pim stanza,
or restart the routing protocol process. [PR/522605: This issue has been resolved.]
■
When an l2circuit ID greater than 2,147,483,647 is configured, and l2circuit
tracing is enabled using the set protocols l2circuit traceoptions command, some
of the trace messages provide the wrong value (a negative number) for the virtual
circuit ID. [PR/523492: This issue has been resolved.]
■
The tag_encoder is unable to handle attempts to stack EXPLICIT_V6_ NULL (label
2) over an existing stack with label 2 on top. Additionally, the BGP module does
not send label 2 when readvertising a prefix from an inet6 unicast session to a
inet6 labeled-unicast session. [PR/523824: This issue has been resolved.]
■
On MX80 routers, non IS-IS fragmented GRE packets are filtered before they are
forwarded to the Routing Engine. [PR/529727: This issue has been resolved.]
■
For JUNOS Release 9.5 and higher, the BGP parse community begins with “0”
as the octal value. This behavior is different in earlier releases. [PR/530086: This
■
The master routing protocol process crashes three minutes after a graceful Routing
Engine switchover. [PR/533363: This issue has been resolved.]
■
The Overload bit in the ISIS LSP MT-TLV might trigger IS-IS to install a default
route to the overload bit advertiser and the show isis database extensive
command might report an unknown TLV. [PR/533680: This issue has been
resolved.]
■
■
The routing protocol process might crash when a BGP connection attempt is met
with an RST from the peer. This is due to an unlikely race condition. [PR/540895:
■
For Adaptive Services II PICs, a temporary file might be created every 15 minutes
in the /var/log/flowc/ directory even if flow collector services is not configured.
The file is deleted if there are no clients, and re-created only when a client
connects and attempts to write to the file. [PR/75515: This issue has been
resolved.]
■
If the Juniper-Firewall-Attribute attribute in a RADIUS server configuration file
names a policer that sets a bandwidth limit for Layer 2 Tunneling Protocol (L2TP)
sessions but not an exclude-bandwidth limit, the bandwidth limit might not be
set correctly. [PR/254503: This issue has been resolved.]
■
On M Series routers (M120 and M320) with many service sets configured with
IDP policies, kernel messages are seen in the messages file once traffic passes
through these service sets. These messages stop when the traffic is stopped.
■
In JUNOS Release 10.0R2, a performance related issue is seen when the IDP
plug-in is enabled. The connection per second value for HTTP (64 bytes) with
AACL, AI, and IDP (with Recommended Attacks group) plug-ins have been
■
105
downgraded to 7,600 through 7,900 per second. [PR/476162: This issue has
been resolved.]
■
On an MS-PIC or MS-DPC running NAT functionality, the show services nat pool
detail command might erroneously display positive and negative number of ports
in use. [PR/506880: This issue has been resolved.]
■
On an MS-PIC or MS-DPC running NAT functionality, the NAT ports might not
be released correctly, resulting in the resources being permanently allocated
until a PIC or DPC restart is triggered. [PR/509847: This issue has been resolved.]
■
When a backup gateway is configured in any term under an IPsec stanza, for
any subsequent terms where this backup gateway is now configured as the
primary, IPsec tunnel establishment will fail. [PR/510608: This issue has been
resolved.]
■
The MS-PIC or MS-DPC might restart if a high rate of SIP and RTSP traffic is
processed within the Application Layer Gateways (ALGs). [PR/512909: This issue
has been resolved.]
■
NAT over FTP fails when it receives a SERVER 227 code string "Entering passive
mode" in lowercase. [PR/522029: This issue has been resolved.]
■
L2tpd asserts when short frames are sent. This causes the l2tpd to crash. As per
RFC 1661 and 1662, such packets should be treated as invalid and discarded.
■
When traffic is forwarded in an L2TP session and a teardown request is received,
the ASPIC crashes with a memory access violation in mlppp_output. [PR/537225:
■
BFD sessions and other protocol adjacencies configured with low hello or dead
timers over aggregate or IRB interfaces might flap upon configuration commit,
when the dhcp-local-server or dhcp-relay is used. [PR/507428: This issue has
been resolved.]
106
■
■
J-Web does not display the USB option under Maintain> Reboot> Reboot from
the media. [PR/464774: This issue has been resolved.]
■
If the time zone is set to “Europe/Berlin,” the command commit at "time-string"
will fail. [PR/483273: This issue has been resolved.]
■
If the user in the Backup Routing Engine with config-private mode activates
graceful Routing Engine switchover (GRES) and uses commit synchronize, a
synchronization error may occur during GRES switchover. [PR/486637: This
■
In configure private mode, activating or deactivating two consecutive nested
objects can cause a syntax error during commit. [PR/506677: This issue has
been resolved.]
Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers
■
The show log xxx | last x command behaves as if the screen length is set to 0,
and the --more xx%-- prompt does not appear. [PR/517023: This issue has been
resolved.]
■
On a router configured with a large number of interfaces, when a few interfaces
are constantly added and deleted, a minor memory leak may occur in the "pfed"
process. [PR/522346: This issue has been resolved.]
■
The group-inherited configuration under the [interface-range] hierarchy level does
not take effect. [PR/522872: This issue has been resolved.]
■
When | last is used with show commands, only the last line is displayed.
■
While upgrading JUNOS Software with l2circuit configuration underthe logical
systems, the validation might fail with an "interface version mismatch" error.
You can ignore this error and upgrade the JUNOS Software using the no-validate
option. [PR/497190: This issue has been resolved.]
■
On an egress PE acting as the leaf of a spmsi p-tunnel, if the ingress PE withdraws
the unicast route towards the source, the routing protocol process crashes when
the c-mcast route is withdrawn. [PR/517183: This issue has been resolved.]
■
The routing protocol process crashes repeatedly on the new master, a few minutes
after a graceful Routing Engine switchover (GRES). [PR/527465: This issue has
been resolved.]
■
When a CE-facing interface in a VPLS instance is deactivated, the routing protocol
process might get stuck in a loop, leading to a high CPU utilization. [PR/531987:
■
on page 6
■
■
■
VPNs
Related Topics
Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX
Series, and T Series Routers
Changes to the JUNOS Documentation Set
The title of the JUNOS Hierarchy and RFC Reference is now JUNOS Hierarchy and
Standards Reference.
■
107
Documentation for the extended DHCP relay agent feature is no longer included in
the Policy Framework Configuration Guide. For DHCP relay agent documentation, see
the Subscriber Access Configuration Guide or the documentation for subscriber access
management.
The new JUNOS Technical Documentation index page
(http://www.juniper.net/techpubs/software/junos/index.html ) consolidates documentation
for JUNOS Software features that are common to all platforms that run JUNOS
Software. The new index page provides direct access to core JUNOS information and
links to information for JUNOS features that run on particular platforms.
Errata
This section lists outstanding issues with the documentation.
Class of Service
■
In JUNOS Release 10.1 and 10.2, the topic Example: Configuring Large Delay
Buffers for Slower Interfaces states “Assuming that the sched-best scheduler is
assigned to a T1 interface…” This is an error. The topic should state “Assuming
that the sched-exped scheduler is assigned to a T1 interface…”
[Class of Service]
High Availability
■
TX Matrix Plus routers and T1600 routers that are configured as part of a routing
matrix do not currently support nonstop active routing. [High Availability]
Integrated Multi-Services Gateway (IMSG)
■
Chapter 15, Maintenance and Failover in the IMSG, describes the IMSG high
availability feature. This feature is not supported in this release of the software.
[Multiplay Solutions]
■
The new-transaction-output-policies configuration statement was introduced in
JUNOS Release 10.1R1. The document did not mention the following restriction:
New transaction policies that include route or message-manipulation options
cannot be configured as new-transaction-output-policies.
[Integrated Multi-Service Gateway (IMSG), Multiplay Solutions, Services Interfaces
Configuration]
■
The Configuring ECMP Next Hops for RSVP and LDP LSPs for Load Balancing topic
in the System Basics Configuration Guide does not mention the following caveat
for configuring ECMP next hops for RSVP LSPs:
If RSVP LSPs are configured with bandwidth allocation, for ECMP next hops with
more than 16 LSPs, traffic is not distributed optimally based on bandwidths
configured. Some LSPs with smaller allocated bandwidths receive more traffic
108
■
than the ones configured with higher bandwidths. Traffic distribution does not
strictly comply with the configured bandwidth allocation. This caveat is applicable
to the following routers:
■
T1600 and T640 routers with Enhanced Scaling FPC1, Enhanced Scaling
FPC2, Enhanced Scaling FPC3, Enhanced Scaling FPC 4, and all Type 4 FPCs
■
M320 routers with Enhanced III FPC1, Enhanced III FPC2, and Enhanced III
FPC3
■
MX Series routers with all types of FPCs and DPCs, excluding MPCs
NOTE: This caveat is not applicable to MX Series routers with line cards based on
the Junos Trio chipset.
■
M120 routers with Type 1, Type 2, and Type 3 FPCs
■
M10i routers with Enhanced CFEB
[System Basics]
■
On M Series, MX Series, and T Series routing platforms, the targeted-broadcast
statement that is used to forward direct broadcast packets to the targeted subnet
in a network is available in the CLI , but it is not functional for the three platforms
mentioned above in JUNOS Release 9.5 through 10.1.
■
In the Network Interfaces Configuration Guide, Chapter 61, Configuring SONET/SDH
Interfaces, a subsection titled Configuring APS Using a Container Interface with
ATM Encapsulation was included. This information was accidentally included
and should not have been published until JUNOS Release 10.4.
■
The Configuring Layer 2 Circuit Transport Mode chapter in the Network Interfaces
Configuration Guide states that one way to configure an ATM II interface to enable
a Layer 2 circuit connection across all versions of JUNOS Software is the following:
■
For Layer 2 circuit cell relay and Layer 2 trunk modes, the atm-l2circuit-mode
cell statement at the [edit chassis fpc slot pic slot] hierarchy level and the
encapsulation atm-ccc-cell-relay statement at the [edit interface interface-name]
hierarchy level.
The configuration above is correct and will interoperate with routers running all
versions of JUNOS Software.
However, the chapter does not mention that you can also include the
encapsulation atm-ccc-cell-relay statement at the [edit interface interface-name unit
logical-unit-number] hierarchy level. When you use this configuration, keep the
following points in mind:
■
This configuration interoperates between Juniper Networks routers running
JUNOS Release 8.2 or earlier.
■
This configuration does NOT interoperate with other network equipment,
including a Juniper Networks router running JUNOS Release 8.3 or later.
■
109
■
For a Juniper Networks router running JUNOS Release 8.3 or later to
interoperate with another Juniper Networks router running JUNOS Release
8.2 or earlier, on the router running JUNOS Release 8.3 or later, include the
use-null-cw statement at the [edit interfaces interface-name atm-options]
hierarchy level.
■
The use-null-cw statement inserts (for sending traffic) or strips (for receiving
traffic) an extra null control word in the MPLS packet.
■
The use-null-cw statement is not supported on a router running JUNOS Release
8.2 or earlier.
JUNOS XML API and Scripting
■
The Junos Configuration and Diagnostic Automation Guide erroneously states that
persistent changes work like the load merge command and transient changes
work like the load update command. Both persistent and transient changes
behave like the load replace command.
In the chapter Summary of JUNOS XML and XSLT Tag Elements Used in Commit
Scripts, the <change> and <transient-change> tag element summaries include
attributes for both tags. Neither the <change> tag nor the <transient-change> tag
have attributes. All references to the attributes in the Description section are not
applicable to these tags.
[Junos Configuration and Diagnostic Automation Guide]
The Subscriber Access Configuration Guide contains the following dynamic variable
errors:
■
The Configuring a Dynamic Profile for Client Access topic erroneously uses the
$junos-underlying-interface variable when a IGMP interface is configured in the
client access dynamic profile. The following example provides the appropriate
use of the $junos-interface-name variable:
[edit dynamic-profiles access-profile]
user@host# set protocols igmp interface $junos-interface-name
■
Table 25 in the Dynamic Variables Overview topic neglects to define the
$junos-igmp-version predefined dynamic variable. This variable is defined as
follows:
$junos-igmp-version—IGMP version configured in a client access profile. The
JUNOS Software obtains this information from the RADIUS server when a
subscriber accesses the router. The version is applied to the accessing subscriber
when the profile is instantiated. You specify this variable at the [dynamic-profiles
profile-name protocols igmp] hierarchy level for the interface statement.
In addition, the Subscriber Access Configuration Guide erroneously specifies the
use of a colon (:) when you configure the dynamic profile to define the IGMP
110
■
version for client interfaces. The following example provides the appropriate
syntax for setting the IGMP interface to obtain the IGMP version from RADIUS:
[edit dynamic-profiles access-profile protocols igmp interface $junos-interface-name]
user@host# set version $junos-igmp-version
■
The Subscriber Access Configuration Guide and the System Basics Configuration
Guide contain information about the override-nas-information statement. This
statement does not appear in the CLI and is not supported.
[Subscriber Access, System Basics]
■
When you modify dynamic CoS parameters with a RADIUS change of
authorization (CoA) message, the JUNOS Software accepts invalid configurations.
For example, if you specify that a transmit rate that exceeds the allowed 100
percent, the system does not reject the configuration and returns unexpected
shaping behavior.
[Subscriber Access]
■
We do not support multicast RIF mapping and ANCP when configured
simultaneously on the same logical interface. For example, we do not support
when a multicast VLAN and ANCP are configured on the same logical interface,
and the subscriber VLANs are the same for both ANCP and multicast.
[Subscriber Access]
■
The Guidelines for Configuring Dynamic CoS for Subscriber Access topic in the
Subscriber Access Configuration Guide erroneously states that dynamic CoS is
supported for dynamic VLANs on the Trio MPC/MIC family of products. In the
current release, dynamic CoS is supported only on static VLANs on Trio MPC/MIC
interfaces.
[Subscriber Access]
■
The Subscriber Access Configuration Guide incorrectly describes the
authentication-order statement as it is used for subscriber access management.
When configuring the authentication-order statement for subscriber access
management, you must always specify the radius method. Subscriber access
management does not support the password keyword (the default), and
authentication fails when you do not specify an authentication method.
[Subscriber Access]
■
In the JUNOS Subscriber Access Configuration Guide, Table 26, “RADIUS-Based
Mirroring Attributes” incorrectly indicates that RADIUS VSA 26-10,
Juniper-User-Permissions, is required for subscriber secure policy mirroring. In
fact, this VSA is not used.
[Subscriber Access]
■
111
■
The show system statistics bridge command displays system statistics on MX
Series routers. [System Basics Command Reference]
■
The mac-tlv-receive and mac-tlv-send statements were removed from Release 10.0
of the JUNOS Software and are no longer visible in the [edit logical-systems
logical-system-name routing-instances routing-instance-name protocols vpls] and
[edit routing-instances routing-instance-name protocols vpls] hierarchy levels.
Although the mac-tlv-receive and mac-tlv-send statements are recognized in the
current release, they will be removed in a future release. We recommend that
you update your configurations and use the mac-flush statement described in
the Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series,
MX Series, and T Series Routers section of the release notes.
VPNs
[VPNs]
■
The JUNOS Software substantially supports the following RFCs for Layer 2 circuits,
as well as the Internet drafts listed in the published documentation:
■
RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
The JUNOS Software does not support Section 5.3, “The Generalized PWid
FEC Element.”
■
RFC 4448, Encapsulation Methods for Transport of Ethernet over MPLS
Networks
[Hierarchy and Standards Reference]
■
In Chapter 19 Configuring VPLS of the VPNs Configuration Guide, an incorrect
statement that caused contradictory information about which platforms support
LDP BGP interworking has been removed. The M7i router was also omitted from
the list of supported platforms. The M7i router does support LDP BGP
interworking.
[VPNs]
Related Topics
112
■
■
on page 6
■
■
page 55
■
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series,
and T Series Routers
This section discusses the following topics:
■
Basic Procedure for Upgrading to Release 10.1 on page 113
■
Upgrading a Router with Redundant Routing Engines on page 116
■
Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS Release
10.1 on page 116
■
Upgrading the Software for a Routing Matrix on page 118
■
Upgrading Using ISSU on page 119
■
Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both PIM
and NSR on page 119
■
Downgrade from Release 10.1 on page 120
Basic Procedure for Upgrading to Release 10.1
In order to upgrade to JUNOS 10.0 or later, you must be running JUNOS 9.0S2, 9.1S1,
9.2R4, 9.3R3, 9.4R3, 9.5R1, or later minor versions, or you must specify the
no-validate option on the request system software install command.
When upgrading or downgrading the JUNOS Software, always use the jinstall package.
Use other packages (such as the jbundle package) only when so instructed by a Juniper
Networks support representative. For information about the contents of the jinstall
package and details of the installation process, see the Junos OS Installation and
Upgrade Guide.
NOTE: You cannot upgrade by more than three releases at a time. For example, if
your routing platform is running JUNOS Release 9.4 you can upgrade to JUNOS
Release 10.0 but not to JUNOS Release 10.1 As a workaround, first upgrade to JUNOS
Release 10.0 and then upgrade to JUNOS Release 10.1.
NOTE: With JUNOS Release 9.0 and later, the compact flash disk memory requirement
for JUNOS Software is 1 GB. For M7i and M10i routers with only 256 MB memory,
see the Customer Support Center JTAC Technical Bulletin PSN-2007-10-001 at
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001&actionBtn=Search.
■
113
NOTE: Before upgrading, back up the file system and the currently active JUNOS
configuration so that you can recover to a known, stable environment in case the
upgrade is unsuccessful. Issue the following command:
user@host> request system snapshot
The installation process rebuilds the file system and completely reinstalls the JUNOS
Software. Configuration information from the previous software installation is retained,
but the contents of log files might be erased. Stored files on the routing platform,
such as configuration templates and shell scripts (the only exceptions are the
juniper.conf and ssh files) may be removed. To preserve the stored files, copy them
to another system before upgrading or downgrading the routing platform. For more
information, see the Junos OS System Basics Configuration Guide.
114
■
The download and installation process for JUNOS Release 10.1 is the same as for
previous JUNOS releases.
If you are not familiar with the download and installation process, follow these steps:
1.
Using a Web browser, follow the links to the download URL on the Juniper
Networks Web page. Choose either Canada and U.S. Version or Worldwide
Version:
■
https://www.juniper.net/support/csc/swdist-domestic/ (customers in the United
States and Canada)
■
https://www.juniper.net/support/csc/swdist-ww/ (all other customers)
2.
Log in to the Juniper Networks authentication system using the username
(generally your e-mail address) and password supplied by Juniper Networks
representatives.
3.
Download the software to a local host.
4.
Copy the software to the routing platform or to your internal software distribution
site.
5.
Install the new jinstall package on the routing platform.
NOTE: We recommend that you upgrade all software packages out of band using
the console because in-band connections are lost during the upgrade process.
Customers in the United States and Canada use the following command:
user@host> request system software add validate reboot
source/jinstall-10.1SR4.4-domestic-signed.tgz
All other customers use the following command:
user@host> request system software add validate reboot
source/jinstall-10.1SR4.4-export-signed.tgz
Replace source with one of the following values:
■
/pathname—For a software package that is installed from a local directory
on the router.
■
For software packages that are downloaded and installed from a remote
location:
■
ftp://hostname/pathname
■
http://hostname/pathname
■
scp://hostname/pathname (available only for Canada and U.S. version)
The validate option validates the software package against the current
configuration as a prerequisite to adding the software package to ensure that
the router reboots successfully. This is the default behavior when the software
package being added is a different release.
■
115
Adding the reboot command reboots the router after the upgrade is validated
and installed. When the reboot is complete, the router displays the login prompt.
The loading process can take 5 to 10 minutes.
Rebooting occurs only if the upgrade is successful.
NOTE: After you install a JUNOS 10.1 Release jinstall package, you cannot issue the
request system software rollback command to return to the previously installed
software. Instead you must issue the request system software add validate command
and specify the jinstall package that corresponds to the previously installed software.
NOTE: Before you upgrade a router that you are using for voice traffic, you should
monitor call traffic on each virtual BGF. Confirm that no emergency calls are active.
When you have determined that no emergency calls are active, you can wait for
nonemergency call traffic to drain as a result of graceful shutdown, or you can force
a shutdown. For detailed information on how to monitor call traffic before upgrading,
see the JUNOS Multiplay Solutions Guide.
Upgrading a Router with Redundant Routing Engines
If the router has two Routing Engines, perform a JUNOS Software installation on each
Routing Engine separately to avoid disrupting network operation as follows:
1.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine
and save the configuration change to both Routing Engines.
2.
Install the new JUNOS Software release on the backup Routing Engine while
keeping the currently running software version on the master Routing Engine.
3.
After making sure that the new software version is running correctly on the
backup Routing Engine, switch over to the backup Routing Engine to activate
the new software.
4.
Install the new software on the original master Routing Engine that is now active
as the backup Routing Engine.
For the detailed procedure, see the Junos OS Installation and Upgrade Guide.
Upgrading Juniper Routers Running Draft-Rosen Multicast VPN to JUNOS
Release 10.1
In releases prior to JUNOS Release 10.1, the draft-rosen multicast VPN feature
implements the unicast lo0.x address configured within that instance as the source
address used to establish PIM neighbors and create the multicast tunnel. In this mode,
the multicast VPN loopback address is used for reverse path forwarding (RPF) route
resolution to create the reverse path tree (RPT), or multicast tunnel. The multicast
VPN loopback address is also used as the source address in outgoing PIM control
messages.
116
■
In JUNOS Release 10.1 and later, you can use the router’s main instance loopback
(lo0.0) address (rather than the multicast VPN loopback address) to establish the PIM
state for the multicast VPN. We strongly recommend that you perform the following
procedure when upgrading to JUNOS Release 10.1 if your draft-rosen multicast VPN
network includes both Juniper Network routers and other vendors’ routers functioning
as provider edge (PE) routers. Doing so preserves multicast VPN connectivity
throughout the upgrade process.
Because JUNOS Release 10.1 supports using the router’s main instance loopback
(lo0.0) address, it is no longer necessary for the multicast VPN loopback address to
match the main instance loopback adddress lo0.0 to maintain interoperability.
NOTE: You might want to maintain a multicast VPN instance lo0.x address to use
for protocol peering (such as IBGP sessions), or as a stable router identifier, or to
support the PIM bootstrap server function within the VPN instance.
Complete the following steps when upgrading routers in your draft-rosen multicast
VPN network to JUNOS Release 10.1 if you want to configure the routers’s main
instance loopback address for draft-rosen multicast VPN:
1.
Upgrade all PE routers to JUNOS Release 10.1 before you configure the loopback
address for draft-rosen Multicast VPN.
NOTE: Do not configure the new feature until all the PE routers in the network have
been upgraded to JUNOS Release 10.1.
2.
After you have upgraded all routers, configure each router’s main instance
loopback address as the source address for multicast interfaces. Include the
default-vpn-source interface-name loopback-interface-name] statement at the [edit
protocols pim] hierarchy level.
3.
After you have configured the router’s main loopback address on each PE router,
delete the multicast VPN loopback address (lo0.x) from all routers.
We also recommend that you remove the multicast VPN loopback address from
all PE routers from other vendors. In JUNOS releases prior to 10.1, to ensure
interoperability with other vendors’ routers in a draft-rosen multicast VPN
network, you had to perform additional configuration. Remove that configuration
from both the Juniper Networks routers and the other vendors’ routers. This
configuration should be on Juniper Networks routers and on the other vendors’
routers where you configured the lo0.mvpn address in each VRF instance as the
same address as the main loopback (lo0.0) address.
This configuration is not required when you upgrade to JUNOS Release 10.1 and
use the main loopback address as the source address for multicast interfaces.
NOTE: To maintain a loopback address for a specific instance, configure a loopback
address value that does not match the main instance address (lo0.0).
■
117
For more information about configuring the draft-rosen Multicast VPN feature, see
the JUNOS Multicast Configuration Guide.
Upgrading the Software for a Routing Matrix
A routing matrix can use either a TX Matrix router as the switch-card chassis (SCC)
or a TX Matrix Plus router as the switch-fabric chassis (SFC). By default, when you
upgrade software for a TX Matrix router or a TX Matrix Plus router, the new image
is loaded onto the TX Matrix or TX Matrix Plus router (specified in the JUNOS CLI by
using the scc or sfc option) and distributed to all T640 routers or T1600 routers in
the routing matrix (specified in the JUNOS CLI by using the lcc option). To avoid
network disruption during the upgrade, ensure the following conditions before
beginning the upgrade process:
■
A minimum of free disk space and DRAM on each Routing Engine. The software
upgrade will fail on any Routing Engine without the required amount of free disk
space and DRAM. To determine the amount of disk space currently available on
all Routing Engines of the routing matrix, use the CLI show system storage
command. To determine the amount of DRAM currently available on all the
Routing Engines in the routing matrix, use the CLI show chassis routing-engine
command.
■
The master Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or
SFC) and T640 routers or T1600 routers (LCC) are all re0 or are all re1.
■
The backup Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or
SFC) and T640 routers or T1600 routers (LCC) are all re1 or are all re0.
■
All master Routing Engines in all routers run the same version of software. This
is necessary for the routing matrix to operate.
■
All master and backup Routing Engines run the same version of software before
beginning the upgrade procedure. Different versions of the JUNOS Software can
have incompatible message formats especially if you turn on GRES. Because the
steps in the process include changing mastership, running the same version of
software is recommended.
■
For a routing matrix with a TX Matrix router, the same Routing Engine model is
used within a TX Matrix router (SCC) and within a T640 router (LCC) of a routing
matrix. For example, a routing matrix with an SCC using two RE-A-2000s and
an LCC using two RE-1600s is supported. However, an SCC or an LCC with two
different Routing Engine models is not supported. We suggest that all Routing
Engines be the same model throughout all routers in the routing matrix. To
determine the Routing Engine type, use the CLI show chassis hardware | match
routing command.
■
For a routing matrix with a TX Matrix Plus router, the SFC contains two model
RE-DUO-C2600-16G Routing Engines, and each LCC contains two model
RE-DUO-C1800-8G Routing Engines.
NOTE: It is considered best practice to make sure that all master Routing Engines
are re0 and all backup Routing Engines are re1 (or vice versa). For the purposes of
this document, the master Routing Engine is re0 and the backup Routing Engine is
re1.
118
■
To upgrade the software for a routing matrix, perform the following steps:
1.
Disable graceful Routing Engine switchover (GRES) on the master Routing Engine
(re0) and save the configuration change to both Routing Engines.
2.
Install the new JUNOS Software release on the backup Routing Engine (re1) while
keeping the currently running software version on the master Routing Engine
(re0).
3.
Load the new JUNOS Software on the backup Routing Engine. After making sure
that the new software version is running correctly on the backup Routing Engine
(re1), switch mastership back to the original master Routing Engine (re0) to
activate the new software.
4.
Install the new software on the new backup Routing Engine (re0).
For the detailed procedure, see the Routing Matrix with a TX Matrix Feature Guide or the
Routing Matrix with a TX Matrix Plus Feature Guide.
Upgrading Using ISSU
Unified in-service software upgrade (ISSU) enables you to upgrade between two
different JUNOS Software releases with no disruption on the control plane and with
minimal disruption of traffic. Unified in-service software upgrade is only supported
by dual Routing Engine platforms. In addition, graceful Routing Engine switchover
(GRES) and nonstop active routing (NSR) must be enabled. For additional information
about using unified in-service software upgrade, see the Junos OS High Availability
Configuration Guide.
Upgrading from JUNOS Release 9.2 or Earlier on a Router Enabled for Both
PIM and NSR
JUNOS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the
following PIM features are not currently supported with NSR. The commit operation
fails if the configuration includes both NSR and one or more of these features:
■
Anycast RP
■
Draft-Rosen multicast VPNs (MVPNs)
■
Local RP
■
Next-generation MVPNs with PIM provider tunnels
■
PIM join load balancing
JUNOS 9.3 Release introduced a new configuration statement that disables NSR for
PIM only, so that you can activate incompatible PIM features and continue to use
NSR for the other protocols on the router: the nonstop-routing disable statement at
the [edit protocols pim] hierarchy level. (Note that this statement disables NSR for all
PIM features, not only incompatible features.)
If neither NSR nor PIM is enabled on the router to be upgraded or if one of the
unsupported PIM features is enabled but NSR is not enabled, no additional steps are
necessary and you can use the standard upgrade procedure described in other sections
of these instructions. If NSR is enabled and no NSR-incompatible PIM features are
■
119
enabled, use the standard reboot or ISSU procedures described in the other sections
of these instructions.
Because the nonstop-routing disable statement was not available in JUNOS Release
9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router
to be upgraded from JUNOS Release 9.2 or earlier to a later release, you must disable
PIM before the upgrade and reenable it after the router is running the upgraded
JUNOS Software and you have entered the nonstop-routing disable statement. If your
router is running JUNOS Release 9.3 or later, you can upgrade to a later release
without disabling NSR or PIM–simply use the standard reboot or ISSU procedures
described in the other sections of these instructions.
To disable and reenable PIM:
1.
On the router running JUNOS Release 9.2 or earlier, enter configuration mode
and disable PIM:
[edit]
user@host# deactivate protocols pim
user@host# commit
2.
Upgrade to JUNOS Release 9.3 or later software using the instructions appropriate
for the router type. You can either use the standard procedure with reboot or
use ISSU.
3.
After the router reboots and is running the upgraded JUNOS Software, enter
configuration mode, disable PIM NSR with the nonstop-routing disable statement,
and then reenable PIM:
[edit]
user@host# set protocols pim nonstop-routing disable
user@host# activate protocols pim
user@host# commit
Downgrade from Release 10.1
To downgrade from Release 10.1 to another supported release, follow the procedure
for upgrading, but replace the 10.1 jinstall package with one that corresponds to the
appropriate release.
NOTE: You cannot downgrade more than three releases. For example, if your routing
platform is running JUNOS Release 9.3, you can downgrade the software to
Release 9.0 directly, but not to Release 8.5 or earlier; as a workaround, you can first
downgrade to Release 9.0 and then downgrade to Release 8.5.
For more information, see the Junos OS Installation and Upgrade Guide.
120
■
Related Topics
■
on page 6
■
■
page 55
■
■
121
JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways
and J Series Services Routers
Powered by JUNOS Software, Juniper Networks SRX Series Services Gateways provide
robust networking and security services. SRX Series Services Gateways range from
lower-end devices designed to secure small distributed enterprise locations to high-end
devices designed to secure enterprise infrastructure, data centers, and server farms.
The SRX Series Services Gateways include the SRX100, SRX210, SRX240, SRX650,
SRX3400, SRX3600, SRX5600, and SRX5800 devices.
Juniper Networks J Series Services Routers running JUNOS Software provide stable,
reliable, and efficient IP routing, WAN and LAN connectivity, and management
services for small to medium-sized enterprise networks. These routers also provide
network security features, including a stateful firewall with access control policies
and screens to protect against attacks and intrusions, and IPsec VPNs. The J Series
Services Routers include the J2320, J2350, J4350, and J6350 devices.
■
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J
Series Services Routers on page 122
■
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series
Services Gateways and J Series Services Routers on page 139
■
Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and
J Series Services Routers on page 147
■
Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series
Services Routers on page 157
■
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series
■
Hardware Requirements for JUNOS Release 10.1 for SRX Series Services Gateways
and J Series Services Routers on page 190
■
Dual-Root Partitioning Scheme Documentation for SRX Series Services
Gateways on page 192
■
Maximizing ALG Sessions on page 201
■
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second
Routing Engine on page 201
■
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series
Services Routers
The following features have been added to JUNOS Release 10.1. Following the
description is the title of the manual or manuals to consult for further information.
122
■
■
Software Features on page 123
■
Hardware Features on page 138
JUNOS Software Release Notes for Juniper Networks SRX Series Services Gateways and J Series Services Routers
New Features in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
Software Features
Application Layer Gateways (ALGs)
■
DNS ALG—This feature is supported on SRX3400, SRX3600, SRX5600, and
SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240,
and SRX650 devices. JUNOS Software for SRX Series devices provides Domain
Name System (DNS) support. The DNS ALG monitors DNS query and reply packets
and closes the session if the DNS flag indicates that the packet is a reply message.
To configure the DNS ALG, use the edit security alg dns statement at the [edit
security alg] hierarchy level.
[Junos OS Security Configuration Guide]
■
DNS doctoring support—This feature is supported on all SRX Series and J Series
devices.
Domain Name System (DNS) ALG functionality has been extended to support
static NAT. You should configure static NAT for the DNS server first. Then if the
DNS ALG is enabled, public-to-private and private-to-public static address
translation can occur for A-records in DNS replies.
The DNS ALG also now includes a maximum-message-length command option
with a value range of 512 to 8192 bytes and a default value of 512 bytes. The
DNS ALG will now drop traffic if the DNS message length exceeds the configured
maximum, if the domain name is more than 255 bytes, or if the label length is
more than 63 bytes. The ALG will also decompress domain name compression
pointers and retrieve their related full domain names, and check for the existence
of compression pointer loops and drop the traffic if a loop exists.
Note that the DNS ALG can translate the first 32 A-records in a single DNS reply.
A-records after the first 32 will not be handled. Also note that the DNS ALG
supports only IPv4 addresses and does not support VPN tunnels.
■
MS RPC ALG—This feature is now supported on SRX3400, SRX3600, SRX5600,
and SRX5800 devices in addition to existing support on SRX100, SRX210,
SRX240, SRX650, and J Series devices.
The Microsoft remote procedure call (RPC) provides a way for a program running
on one host to call procedures in a program running on another host. Because
of the large number of RPC services and the need to broadcast, the transport
address of an RPC service is dynamically negotiated based on the service
program’s Universal unique iDentifier (UUID). The specific UUID is mapped to
a transport address.
JUNOS Software supports MS RPC as a predefined service to allow and deny
traffic based on a policy you configure. The MS RPC ALG provides the functionality
for all supported devices to handle the dynamic transport address negotiation
mechanism of the MS RPC and to ensure UUID-based security policy enforcement.
You can define a security policy to permit or deny all RPC requests or to permit
or deny by specific UUID number. The ALG also supports route and Network
Address Translation (NAT) mode for incoming and outgoing requests.
■
123
■
SQL ALG—This feature is now supported on SRX3400, SRX3600, and SRX5600,
and SRX5800 devices in addition to existing support on SRX100, SRX210,
Enabling the Structured Query Language (SQL) ALG on an SRX Series device or
a J Series device allows SQL*Net traffic in SQL redirect mode to traverse an SRX
Series device by creating a TCP pinhole. If the the SQL*Net traffic is not in redirect
mode, it will not be handled by the SQL ALG and will instead be processed by
configured firewall policies. SQL*Net is a proprietary protocol used by Oracle
databases for data access and sharing over networks. Note that the SQL ALG
supports only IPv4 addresses as of JUNOS Release 10.1.
■
Sun RPC ALG—This feature is now supported on SRX3400, SRX3600, SRX5600,
and SRX5800 line devices in addition to existing support on SRX100, SRX210,
Sun Microsystems RPC provides a way for a program running on one host to
call procedures in a program running on another host. Because of the large
number of RPC services and the need to broadcast, the transport address of an
RPC service is dynamically negotiated based on the service’s program number
and version number. Several binding protocols are defined for mapping the RPC
program number and version number to a transport address.
JUNOS Software supports the Sun RPC as a predefined service to allow and deny
traffic, based on a security policy you configure. The Sun RPC ALG provides the
functionality for all supported devices to handle the dynamic transport address
negotiation mechanism of the Sun RPC and to ensure program number-based
security policy enforcement. You can define a security policy to permit or deny
all RPC requests or to permit or deny by specific program number. The ALG also
supports route and NAT mode for incoming and outgoing requests.
Chassis Cluster
■
Interface link aggregation in redundant Ethernet interfaces—This feature is
supported on SRX3400, SRX3600, SRX5600, and SRX5800 device chassis clusters.
Link aggregation groups (LAGs) can now be established across nodes in a chassis
cluster. In JUNOS Release 10.1, support for LAGs based on IEEE 802.3ad made
it possible to aggregate physical interface links on a standalone device. LAGs
provide increased interface bandwidth and link availability by linking physical
ports and load-balancing traffic crossing the combined interface. In JUNOS Release
10.1, link aggregation has been extended to chassis cluster configuration, allowing
a redundant Ethernet interface (known as a reth interface in CLI commands) to
add multiple child interfaces from both nodes and thereby create a redundant
Ethernet interface link aggregation group.
Other than adding more child interfaces (up to a maximum of 16, with 8 per
node) to a redundant Ethernet interface, no other configuration on an SRX Series
device beyond the more general chassis cluster, redundancy group, and redundant
Ethernet interface configuration is necessary to use this feature. It is necessary,
however, for the switch used to connect the links from both nodes in the cluster
124
■
to have a LAG link configured and 802.3ad enabled for each redundant Ethernet
interface LAG on both nodes so that the aggregate links will be recognized.
Standalone link aggregation group interfaces (ae) are supported on clustered
devices but cannot be added to redundant Ethernet interfaces. Likewise, any
child interface of an existing LAG cannot be added to a redundant Ethernet
interface, and vice versa. The maximum number of total combined standalone
aggregate interfaces (ae) and redundant Ethernet interfaces (reth) per cluster is
128.
Redundant Ethernet interface configuration also includes a minimum-links setting
that allows you to set a minimum number of physical child links in a redundant
Ethernet interface LAG that must be working on the primary node for the interface
to be up. The default minimum-links value is 1. When the number of physical
links on the primary node in a redundant Ethernet interface falls below the
minimum-links value, the interface will be down even if some links are still
working.
Note that management, control, and fabric interfaces do not support standalone
LAGs or redundant Ethernet interface LAGs in JUNOS Release 10.1.
■
Redundancy group IP address monitoring through a secondary interface—This
feature is supported on SRX3400, SRX3600, SRX5600 and SRX5800 devices.
In JUNOS Release 10.1, redundancy group IP address monitoring through a
redundant Ethernet (reth) interface has been extended to include monitoring of
addresses on secondary links as well as on primary links. Redundancy group
failover can thus be tied to the health of both any IP addresses that are currently
important to traffic reliability and to any IP addresses that will become important
to traffic reliability in the event of a failover.
Monitoring can be accomplished only if the IP address is reachable on a redundant
Ethernet interface, and IP addresses cannot be monitored over a tunnel. IP
address monitoring is not supported on redundant Ethernet interface LAGs or
on the child interfaces bound to a redundant Ethernet interface LAG. The feature
also cannot be used on a cluster running in transparent mode. The maximum
number of total monitoring IPs that can be configured per cluster remains 32
for SRX3400 and SRX3600 devices, and 64 for SRX5600 and SRX5800 devices.
■
125
Integrated Convergence Services
■
DSCP marking for RTP packets generated by SRX Series Integrated
Convergence Services—This feature is supported on SRX210 and SRX240 devices
that have high memory, power over Ethernet capability, and media gateway
capability.
Configure Differentiated Services (DiffServ) code point (DSCP) marking to set
the desired DSCP bits for Real-Time Transport Protocol (RTP) packets generated
by SRX Series Integrated Convergence Services.
DSCP bits are the 6-bit bit map in the IP header used by devices to determine
the forwarding priority of packet routing. When the DSCP bits of RTP packets
generated by Integrated Convergence Services are configured, the downstream
device can then classify the RTP packets and direct them to a higher priority
queue in order to achieve better voice quality when packet traffic is congested.
Juniper Networks devices provide classification, priority queuing, and other kinds
of class-of-service (CoS) configuration under the Class-of-Service configuration
hierarchy.
Note that the Integrated Convergence Services DSCP marking feature marks only
RTP packets of calls that it terminates, which include calls to peer call servers
and to peer proxy servers that provide SIP trunks. If a call is not terminated by
Integrated Convergence Services, then DSCP marking does not apply.
To configure the DSCP marking bitmap for calls terminated by Integrated
Convergence Services and the address of the peer call server or peer proxy server
to which these calls are routed, use the media-policy statement in the [edit services
converged-services] hierarchy level.
set services convergence-service service-class < name > dscp < bitmap >
set services convergence-service service-class media-policy < name > term
< term-name > from peer-address [< addresses >]
set services convergence-service service-class media-policy < name > term then
service-class < name >
Interfaces and Routing
■
DOCSIS Mini-PIM interface—DOCSIS Mini-PIM is currently supported with
Comcast ISP service.
The Data over Cable Service Interface Specification (DOCSIS) defines the
communications and operation support interface requirements for a
data-over-cable system. It is used by cable operators to provide Internet access
over their existing cable infrastructure for both residential and business
customers. DOCSIS 3.0 is the latest interface standard, allowing channel bonding
to deliver speeds higher than 100 Mbps throughput in either direction, far
surpassing other WAN technologies such as T1/E1, ADSL2+, ISDN, and DS3.
DOCSIS network architecture includes a cable modem on SRX Series Services
Gateways with a DOCSIS Mini-Physical Interface Module (Mini-PIM) located at
customer premises, and a cable modem termination system (CMTS) located at
the head-end or data center locations. The standards-based DOCSIS 3.0 Mini-PIM
is interoperable with CMTS equipment. The DOCSIS Mini-PIM provides backward
compatibility with CMTS equipment based on the following standards:
126
■
■
DOCSIS 2.0
■
DOCSIS 1.1
■
DOCSIS 1.0
The DOCSIS Mini-PIM is supported on the following SRX Series Services Gateways:
■
SRX210
■
SRX240
The DOCSIS Mini-PIM has the following key features:
■
Provides high data transfer rates of over 150 Mbps downstream
■
Supports 4-downstream and 4-upstream channel bonding
■
Supports quality of service (QoS)
■
Provides interoperability with any DOCSIS-compliant cable modem
termination system CMTS
■
Supports IPv6 and IPv4 for modem management interfaces
■
Supports Baseline Privacy Interface Plus (BPI+)
■
Supports Advanced Encryption Standard (AES)
■
Very-high-bit-rate digital subscriber line (VDSL)—VDSL technology is part of
the xDSL family of modem technologies that provide faster data transmission
over a single flat untwisted or twisted pair of copper wires.
The VDSL lines connect service provider networks and customer sites to provide
high bandwidth applications (Triple Play services) such as high-speed Internet
access, telephone services like voice over IP (VoIP), high-definition TV (HDTV),
and interactive gaming services over a single connection. VDSL2 is an
enhancement to VDSL and permits the transmission of asymmetric and
symmetric (full-duplex) aggregate data rates up to 100 Mbps on short copper
loops using a bandwidth of up to 30 MHz. The VDSL2 technology is based on
the ITU-T G.993.2 standard.
The following SRX Series Services Gateways support the VDSL2 Mini-Physical
Interface Module (Mini-PIM) (Annex A):
■
SRX210 Services Gateway
■
SRX240 Services Gateway
The VDSL2 Mini-PIM carries the Ethernet backplane. When the Mini-PIM is
plugged into the chassis, the Mini-PIM connects to one of the ports of the
baseboard switch.
■
127
The VDSL2 Mini-PIM supports the following features:
■
■
■
Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ backward
compatibility with Annex-A, Annex-M Support
■
PTM or EFM [802.3ah] support
■
Operation, Administration, and Maintenance (OAM) support for
ADSL/ADSL/ADSL2+ Asynchronous Transfer Mode (ATM)
■
ATM quality of service (QoS) (supported only when the VDSL2 Mini-PIM is
operating in ADSL2 mode)
■
Multilink Point-to-Point Protocol (MLPPP) (supported only when the VDSL2
Mini-PIM is operating in ADSL2 mode)
■
Maximum Transmission Unit (MTU) size of 1500 bytes
■
Support for maximum of 10 permanent virtual circuits (PVCs) (only in
ADSL/ADSL2/ADSL2+ mode)
■
Dying gasp support (ADSL and VDSL2 mode)
Online insertion and removal (hot swap) for SRX650 GPIMs—Online insertion
and removal (OIR) functionality is supported on CPU-based and CPU-less
Gigabit-Backplane Physical Interface Modules (GPIMs). You can remove or insert
a GPIM without powering off the device. The following GPIMs are supported on
SRX650 devices:
■
24-port Ethernet GPIM (with and without Power over Ethernet [PoE])
■
16-port Ethernet GPIM (with and without PoE)
■
2-port and 4-port CT1/E1 GPIM
Implement the Point-to-Point Protocol over Ethernet (PPPoE)-based
radio-to-router protocol—This feature is supported on SRX Series and J Series
devices.
JUNOS Release 10.1 supports PPPoE-based radio-to-router protocols. These
protocols include messages that define how an external device provides the
router with timely information about the quality of a link’s connection. There is
also a flow control mechanism to indicate how much data the device can forward.
The device can then use the information provided in the PPPoE messages to
dynamically adjust the interface speed of the PPP links. Use the radio-router
statement from the [set interfaces <unit>] hierarchy to indicate that metrics
announcements received on the interface will be processed by the device.
■
Class of service (CoS) for devices operating in transparent mode—This feature
is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.
SRX3400, SRX3600, SRX5600, and SRX5800 devices operating in Layer 2
transparent mode support the following CoS functions:
128
■
■
IEEE 802.1p behavior aggregate (BA) classifiers to determine the forwarding
treatment for packets entering the device
Note that only IEEE 802.1p BA classifier types are supported on devices
operating in transparent mode.
■
Rewrite rules to redefine IEEE 802.1 CoS values in outgoing packets
Note that rewrite rules that redefine IP precedence CoS values and DSCP
CoS values are not supported on devices operating in transparent mode.
■
Shapers to apply rate limiting to an interface
■
Schedulers that define the properties of an output queue
You configure BA classifiers and rewrite rules on transparent mode devices in
the same way as on devices operating in Layer 3 mode. For transparent mode
devices, however, you apply BA classifiers and rewrite rules only to logical
interfaces configured with the family bridge configuration statement.
You configure shapers and schedulers on transparent mode devices in the same
way as on devices operating in Layer 3 mode.
[Junos OS Interfaces and Routing Configuration Guide]
■
Layer 2 Q-in-Q tunneling—This feature is supported on SRX210, SRX240,
SRX650, and J Series devices.
Q-in-Q tunneling, defined by the IEEE 802.1ad standard, allows service providers
on Ethernet access networks to extend a Layer 2 Ethernet connection between
two customer sites.
In Q-in-Q tunneling, as a packet travels from a customer virtual LAN (C-VLAN)
to a service provider's VLAN, a service provider-specific 802.1Q tag is added to
the packet. This additional tag is used to segregate traffic into
service-provider-defined service VLANs (S-VLANs). The original customer 802.1Q
tag of the packet remains and is transmitted transparently, passing through the
service provider's network. As the packet leaves the S-VLAN in the downstream
direction, the extra 802.1Q tag is removed.
There are three ways to map C-VLANs to an S-VLAN:
■
All-in-one bundling—Use the dot1q-tunneling statement at the [edit vlans]
hierarchy to map without specifying customer VLANs. All packets from a
specific access interface are mapped to the S-VLAN.
■
Many-to-one bundling—Use the customer-vlans statement at the [edit vlans]
hierarchy to specify which C-VLANs are mapped to the S-VLAN.
■
Mapping C-VLAN on a specific interface—Use the mapping statement at the
[edit vlans] hierarchy to map a specific C-VLAN on a specified access interface
to the S-VLAN.
Table 3 on page 130 lists the C-VLAN-to-S-VLAN mapping supported on identified
SRX Series and J Series devices.
■
129
Table 3: C-VLAN to S-VLAN Mapping Supported on SRX Series and J Series Devices
Mapping
SRX210
SRX240
SRX650
J Series (PIM)
All-in-one bundling
Yes
Yes
Yes
Yes
Many-to-one bundling
No
No
Yes
No
Mapping C-VLAN on a
specific interface
No
No
Yes
No
Integrated bridging and routing (IRB) interfaces are supported on Q-in-Q VLANs
for SRX210, SRX240, SRX650, and J Series devices. Packets arriving on an IRB
interface on a Q-in-Q virtual LAN (VLAN) are routed regardless of whether the
packet is single or double tagged. The outgoing routed packets contain an S-VLAN
tag only when exiting a trunk interface; the packets exit the interface untagged
when exiting an access interface.
In a Q-in-Q deployment, customer packets from downstream interfaces are
transported without any changes to the source and destination media access
control (MAC) addresses. You can disable MAC address learning at both the
interface level and the VLAN level. Disabling MAC address learning on an interface
disables learning for all the VLANs of which that interface is a member. When
you disable MAC address learning on a VLAN, MAC addresses that have already
been learned are flushed.
■
Layer 2 Link Layer Discovery Protocol (LLDP) and Link Layer Discovery
Protocol–Media Endpoint Discovery (LLDP-MED)—This feature is supported
on SRX100, SRX210, SRX240, SRX650, and J Series devices.
Devices use LLDP and LLDP-MED to learn and distribute device information on
network links. The information allows the device to quickly identify a variety of
systems, resulting in a LAN that interoperates smoothly and efficiently.
LLDP-capable devices transmit information in type length and value (TLV)
messages to neighbor devices. Device information can include specifics such as
chassis and port identification and system name and system capabilities. The
TLVs leverage this information from parameters that have already been configured
in the Juniper Networks JUNOS Software.
LLDP-MED goes one step further, exchanging IP-telephony messages between
the device and the IP telephone. These TLV messages provide detailed information
on PoE policy. The PoE management TLVs let the device ports advertise the
power level and power priority needed. For example, the device can compare
the power needed by an IP telephone running on a PoE interface with available
resources. If the device cannot meet the resources required by the IP telephone,
the device could negotiate with the telephone until a compromise on power is
reached.
LLDP and LLDP-MED must be explicitly configured on universal Physical Interface
Modules (uPIMs) (in enhanced switching mode) on J Series devices, base ports
on SRX100, SRX210, and SRX240 devices, and Gigabit-Backplane Physical
Interface Modules (GPIMs) on SRX650 devices. To configure LLDP on all interfaces
or on a specific interface, use the lldp statement at the [set protocols] hierarchy.
130
■
To configure LLDP-MED on all interfaces or on a specific interface, use the lldp-med
statement at the [set protocols] hierarchy.
■
Promiscuous mode—This feature is supported on SRX3400, SRX3600, SRX5600,
and SRX5800 devices.
When promiscuous mode is enabled on a Layer 3 Ethernet interface, all packets
received on the interface are sent to the CP/Services Processing Unit (SPU)
regardless of the destination MAC address of the packet. You can also enable
promiscuous mode on chassis cluster redundant Ethernet interfaces and
aggregated Ethernet interfaces. If you enable promiscuous mode on a redundant
Ethernet interface, promiscuous mode is then enabled on any child physical
interfaces. If you enable promiscuous mode on an aggregated Ethernet interface,
promiscuous mode is then enabled on all member interfaces.
To enable promiscuous mode on an interface, use the promiscuous-mode
statement at the [edit interfaces] hierarchy.
Intrusion Detection and Prevention (IDP)
■
IDP in an active/active chassis cluster—This feature is supported on SRX3400,
SRX3600, SRX5600, and SRX5800 devices.
Intrusion Detection and Prevention (IDP) can now monitor traffic on active/active
chassis clusters. As in active/passive clusters, sessions already in progress that
fail over or fail back are not inspected by IDP in an active/active cluster. New
sessions created after a failover will, however, be inspected by IDP. There are
no changes to IDP deployment or logging as a result of extending support to
active/active high-end device clusters.
IDP also now supports chassis cluster in-service software upgrades (ISSUs), which
means that new sessions will continue to be inspected during the ISSU. However,
because ISSU requires the nodes to fail over and fail back as the upgrade
proceeds, IDP monitoring of any sessions that fail over will cease. It should not
be necessary to restart IDP once the ISSU is completed. Note that IDP ISSU
support is available on both active/passive and active/active chassis clusters.
■
IDP application identification enhancement for extended applications with
threat prevention support—This feature is supported on SRX3400, SRX3600,
SRX5600, and SRX5800 devices.
With the increased use of application protocol encapsulation, the need arises to
support the identification of multiple different applications running on the same
Layer 7 protocols. In order to do this, the current application identification layer
is split into two layers: application and protocol. New extended application
signatures have been added to identify these extended applications.
■
Command-line interface (CLI) enhancements supported for J-Web—This
feature is supported on SRX Series and J Series devices.
■
131
Additional functionality has been added to existing IDP J-Web pages for several
new CLI commands that perform tasks such as the following: list detailed security
download status information, list subscriber policies, and add additional IDP
packet counters to differentiate a packet drop that is the result of a policy from
a legitimate drop or an error drop. There are several more newly added
commands.
[JUNOS CLI Reference Guide]
■
SNMP MIB for IDP Monitoring—This feature is now supported on SRX3400,
SRX3600, SRX5600, and SRX5800 devices in addition to existing support on
SRX100, SRX210, SRX240, and SRX650 devices.
■
Application-level DDoS logging—This feature is supported on SRX3400,
SRX3600, SRX5600, and SRX5800 devices with IDP enabled.
IDP now provides logging for application-level DDoS events. IDP generates three
types of application-level DDoS event logs: attack, state transition, and ip-action.
These event logs provide visibility into the application-level DDoS state and
provide notifications on occurrences of application-level DDoS attacks for each
protected application server.
[Junos OS CLI Reference, Junos OS Security Configuration Guide]
Manual BIOS Upgrade Using JUNOS CLI
■
This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices.
■
For branch SRX Series devices, BIOS is made up of U-boot and JUNOS loader.
Apart from this SRX240 and SRX650 also have U-shell binary as part of the
BIOS.
■
On SRX100, SRX210 and SRX240, there is support of Backup BIOS which
constitutes a backup copy of U-boot in addition to the active copy from which
the system generally boots up.
Table 4 on page 132 provides details of BIOS components supported for different
platforms.
Table 4: Manual BIOS Upgrade Components
BIOS Components
SRX100
SRX210
SRX240
SRX650
Active
U-boot
Yes
Yes
Yes
Yes
Loader
Yes
Yes
Yes
Yes
Yes
Yes
U-shell
Backup
U-boot
Yes
Yes
Yes
Table 5 on page 133 provides you the CLI commands used for manual BIOS upgrade.
132
■
Table 5: CLI Commands for Manual BIOS Upgrade
Active BIOS
Backup BIOS
request system firmware upgrade re bios
request system firmware upgrade re bios backup
Procedure for BIOS upgrade
1.
Installing a jloader-srxsme package
1.
Copy the jloader-srxme signed package to the device.
NOTE: Note that this package should be of the same version as that of the
corresponding JUNOS, example, on a device with a 10.2 JUNOS package installed,
the jloader-srxsme package should also be of version 10.2.
2.
Install the package using the request system software add <path to
jloader-srxsme package> no-copy no-validate command.
root> request system software add /var/tmp/jloader-srxsme-10.2B3-signed.tgz
no-copy no-validate
Installing package '/var/tmp/jloader-srxsme-10.2B3-signed.tgz' ...
Verified jloader-srxsme-10.2B3.tgz signed by PackageProduction_10_2_0
Adding jloader-srxsme...
Available space: 427640 require: 2674
Mounted jloader-srxsme package on /dev/md5...
Saving state for rollback ...
root> show version
Model: srx240h
JUNOS Software Release [10.2B3]
JUNOS BIOS Software Suite [10.2B3]
NOTE: Installing the jloader-srxsme package puts the necessary images under
directory/boot.
2.
Verifying that images for upgrade are installed
■
133
■
The show system firmware command can be used to get version of images
available for upgrade. The available version is printed under column Available
version. The user needs to verify that the correct version of BIOS images
available for upgrade.
root> show system firmware
Part
Routing Engine 0
Routing Engine 0
Routing Engine 0
Type
3.
Tag
RE BIOS
0
RE BIOS Backup 1
RE FPGA
11
Current
version
1.5
1.5
12.3.0
Available
version
1.7
1.7
Status
OK
OK
OK
BIOS upgrade
Active BIOS:
1.
Initiate the upgrade using the request system firmware upgade re bios
command.
root> request system firmware upgrade re bios
Part
Type
Tag
Current
Available
version
version
Routing Engine 0 RE BIOS
0
1.5
1.7
Routing Engine 0 RE BIOS Backup 1
1.5
1.7
Perform indicated firmware upgrade ? [yes,no] (no) yes
Status
OK
OK
Firmware upgrade initiated.
2.
Monitor the status of upgrade using the show system firmware command.
Part
Routing Engine 0
Routing Engine 0
Routing Engine 0
Type
RE BIOS
RE BIOS Backup
RE FPGA
Tag
0
1
11
Current
version
1.5
1.5
12.3.0
Available
version
1.7
1.7
Status
PROGRAMMING
OK
OK
Part
Type
Tag
Routing Engine 0
RE BIOS
0
Current
version
1.5
Routing Engine 0
Routing Engine 0
RE BIOS Backup
RE FPGA
1
11
1.5
12.3.0
Available
Status
version
1.7
UPGRADED
SUCCESSFULLY
1.7
OK
OK
NOTE: The device must be rebooted for the upgraded active BIOS to take effect.
134
■
Backup BIOS:
1.
Initiate the upgrade using the request system firmware upgade re bios backup
command.
root> request system firmware upgrade re bios backup
Part
Type
Tag
Current
Available
version
version
Routing Engine 0 RE BIOS
0
1.5
1.7
Routing Engine 0 RE BIOS Backup 1
1.5
1.7
Perform indicated firmware upgrade ? [yes,no] (no) yes
Status
OK
OK
Firmware upgrade initiated.
2.
Monitor the status of upgrade using the show system firmware command.
Part
Current
version
RE BIOS
0
1.5
RE BIOS Backup 1
1.5
RE FPGA
11
12.3.0
Routing Engine 0
Routing Engine 0
Routing Engine 0
Type
Tag
Available
version
1.7
1.7
Status
OK
PROGRAMMING
OK
Part
Type
Tag
Routing Engine 0
Routing Engine 0
RE BIOS
RE BIOS Backup
0
1
Current
version
1.5
1.7
Routing Engine 0
RE FPGA
11
12.3.0
Available
version
1.7
1.7
Status
OK
UPGRADED
SUCCESSFULLY
OK
Network Address Translation (NAT)
■
Increased maximum number of source NAT rules supported—This feature is
supported on SRX Series and J Series devices.
JUNOS Release 10.1 increases the number of source NAT rules and rule sets that
you can configure on a device. In previous releases, the maximum number of
source NAT rule sets you could configure on a device was 32 and the maximum
number of rules in a source NAT rule set was 8.
JUNOS Release 10.1, the maximum number of source NAT rules that you can
configure on a device are:
■
512 for J Series, SRX100, and SRX210 devices
■
1024 for SRX240 and SRX650 devices
■
8192 for SRX3400, SRX3600, SRX5600, and SRX5800 devices
These are systemwide maximums for total numbers of source NAT rules. There
is no limitation on the number of rules that you can configure in a source NAT
■
135
rule set as long as the maximum number of source NAT rules allowed on the
device is not exceeded.
NOTE: This features does not change the maximum number of rules and rule sets
you can configure on a device for static and destination NAT. For static NAT, you
can configure up to 32 rule sets and up to 256 rules per rule set. For destination NAT,
you can configure up to 32 rule sets and up to 8 rules per rule set.
Point-to-Point Protocol over Ethernet (PPPoE)
■
LN1000 mobile secure router—This feature is supported on J2320, J6350, and
SRX650 devices.
To support the credit-based flow control extensions described in [RFC–4938],
PPPoE peers can now grant each other forwarding credits. The grantee can
forward traffic to the peer only when it has a sufficient number of credits to do
so. When credit-based forwarding is used on both sides of the session, the radio
client can control the flow of traffic by limiting the number of credits it grants
to the router.
The interfaces statement includes a new radio-router attribute that replaces the
resource-component-variables attribute. The radio-router attribute contains the
parameters used for rate-based scheduling and OSPF link cost calculations. It
also includes a new credit attribute to indicate that credit-based packet scheduling
is supported on the PPPoE interfaces that reference this underlying interface.
Interfaces that set the encapsulation attribute support the PPPoE Active Discovery
Grant (PADG) and PPPoE Active Discovery Credit (PADC) messages in the same
way that the attribute provides active support for the PPPoE Active Discovery
Quality (PADQ) message.
The credit interval parameter controls how frequently the router generates credit
announcement messages. For PPPoE this corresponds to the interval between
PADG credit announcements for each session.
For example:
[edit interfaces ge-0/0/1]
unit 0 {
encapsulation ppp-over-ether;
radio-router {
credit {
interval 10;
}
bandwidth 80;
threshold 5;
}
}
NOTE: The resource-component-variables attribute has been deprecated, but has an
alias to the radio-router variable to minimize impact on existing routers that might
have been configured previously.
136
■
To display PPPoE credit-flow information:
user@host> show pppoe interface detail
pp0.51 Index 73
State: Session up, Session ID: 3,
Service name: None,
Configured AC name: None, Session AC name: None,
Remote MAC address: 00:22:83:84:2e:81,
Session uptime: 00:05:48 ago,
Auto-reconnect timeout: Never, Idle timeout: Never,
Underlying interface: ge-0/0/4.1 Index 72
PADG Credits: Local: 12345, Remote: 6789, Scale factor: 128 bytes
PADQ Current bandwidth: 750 Kbps, Maximum 1000 Kbps
Quality: 85, Resources 65, Latency 100 msec.
Dynamic bandwidth: 3 Kbps
pp0.1000 Index 71
State: Down, Session ID: 1,
Service name: None,
Configured AC name: None, Session AC name: None,
Remote MAC address: 00:00:00:00:00:00,
Auto-reconnect timeout: Never, Idle timeout: Never,
Underlying interface: ge-0/0/1.0 Index 70
PADG Credits: enabled
Dynamic bandwidth: enabled
Virtual LANs (VLANs)
■
Flexible Ethernet services—This feature is supported on SRX210, SRX240,
SRX650, and J Series devices.
Use flexible Ethernet services encapsulation when you want to configure multiple
per-unit Ethernet encapsulations. This encapsulation type allows you to configure
any combination of route, TCC, CCC, and VPLS encapsulations on a single physical
port. Aggregated Ethernet bundles cannot use this encapsulation type.
For ports configured with flexible Ethernet services encapsulation, VLAN IDs
from 1 through 511 are no longer reserved for normal VLANs.
VPNs
■
Increased maximum number of VPN tunnels supported—This feature is
supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.
VPN supports a maximum of 10000 site-to-site VPN tunnels.
WLAN
■
AX411 Access Point clustering—The AX411 Access Point is a Layer 2 device
that connects wireless communication devices together to create a wireless
network. The access point is connected to the wired network and relays data
between the wired and the wireless network. Multiple access points form a part
of a bigger wireless network and can be clustered together.
■
137
The access point cluster is a dynamic, configuration-aware group of access points
in the same subnet of a network. A cluster can have up to sixteen member access
points. Clusters can share various configuration information such as virtual access
point (VAP) settings and quality-of-service (QoS) queue parameters. Any change
in configuration on one access point will propagate to all other access points in
the cluster. Similarly, any new access point introduced to the cluster will adopt
the configuration of other access points in the cluster.
Access points are supported on the following SRX Series Services Gateways:
■
SRX210
■
SRX240
■
SRX650
[JUNOS Software WLAN Configuration and Administration Guide]
Hardware Features
Support for 3G wireless functionality on SRX210 Services Gateways—JUNOS
Software Release 10.1 supports 3G wireless functionality on SRX210 devices to
provide to provide wireless WAN connectivity as backup to primary WAN links.
Third-generation (3G) networks are wide area cellular telephone networks that have
evolved to include high-data rate services of up to 3 Mbps. The SRX210 device has
a 3G ExpressCard slot on the back panel. The SRX210 device supports the Juniper
Networks wireless modems listed in Table 6 on page 138.
Table 6: Juniper Networks Wireless Modems Supported by the SRX210 Device
Wireless Cards
Release Supported
EXPCD-3G-HSPA-T- 3G UMTS ExpressCard Sierra Wireless AC503 ExpressCard
for GSM and UMTS Networks, worldwide.
JUNOS Release 10.1. JUNOS Software Release
10.1 provides untested support for this
modem for LAB testing purposes only.
■
EXPCD-3G-CDMA-V: 3G EVDO ExpressCard for Verizon Wireless.
Currently available from Juniper Networks.
■
EXPCD-3G-CDMA-S: 3G EVDO ExpressCard for Sprint. Currently available
from Juniper Networks.
■
Sierra Wireless AirCard Global System for Mobile Communications (GSM)
High-Speed Downlink Packet Access (HSDPA) ExpressCard - Sierra
Wireless AirCard 880E.
JUNOS Release 9.5 and JUNOS Release 9.6.
For more information on installing 3G ExpressCards, see the SRX210 Services Gateway
Hardware Guide. For more information on configuring the 3G interface, see the JUNOS
Software Interfaces and Routing Configuration Guide.
Related Topics
138
■
■
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
■
■
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services
Gateways and J Series Services Routers
The following current system behavior, configuration statement usage, and operational
mode command usage might not yet be documented in the JUNOS Software
documentation:
■
The following CLI commands have been removed as part of RPC ALG data
structure cleanup:
■
clear security alg msrpc portmap
■
clear security alg sunrpc portmap
■
show security alg msrpc portmap
■
show security alg sunrpc portmap
■
The show security alg msrpc object-id-map CLI command has a chassis cluster
node option to permit the output to be restricted to a particular node or to query
the entire cluster. The show security alg msrpc object-id-map node CLI command
options are <node-id | all | local | primary>.
■
On SRX650 devices in chassis cluster mode, the T1/E1 PIC goes offline and does
not come online.
■
The automatic pause timer functionality related to IP address monitoring for
redundancy groups has been removed. Instead, a configurable hold-down-interval
timer for all redundancy groups has been instituted. See the “Configuring a
Dampening Time Between Back-to-Back Redundancy Group Failovers” section
of the JUNOS Software Security Configuration Guide.
■
IP address monitoring on redundancy group 0 is now supported.
■
The chassis cluster redundancy-group group-number ip-monitoring threshold CLI
command has been removed. Instead, use the chassis cluster redundancy-group
group-number ip-monitoring global-threshold command.
■
IP address monitoring on virtual routers is now supported.
■
In a chassis cluster configuration on an SRX100, SRX210, SRX240, or SRX650
device, the default values of the heartbeat-threshold and heartbeat-interval options
in the [edit chassis cluster] hierarchy are 8 beats and 2000 ms respectively. These
values cannot be changed on these devices.
Chassis Cluster
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
Routers
■
139
Command-Line Interface (CLI)
■
On SRX Series devices, the show security monitoring fpc 0 command is now
available.
The output of this CLI command on SRX Series devices differs from previous
implementations on other devices. Note the following sample output:
show security monitoring fpc 0
FPC 0
PIC 0
CPU utilization : 0 %
Memory utilization : 65 %
Current flow session : 0
Max flow session : 131072
NOTE: When SRX Series devices operate in packet mode, flow sessions will not be
created and current flow session will remain zero as shown in the sample output
above. The maximum number of sessions will differ from one device to another. On
SRX3400, SRX3600, SRX5600, AND SRX5800 devices, the output will include two
more lines: SPU current cp session and SPU max cp session.
■
On SRX210 devices with Integrated Convergence Services, TDM configuration
change might interrupt existing TDM calls if any MPIMs are configured. The voice
calls through the MPIM do not work. Run the CLI restart rtmd command after
making a configuration change to the MPIM ports.
■
On SRX210 devices with Integrated Convergence Services, registrations do not
work when PCS is configured and removed thorough the CLI. The dial tone
dissappears when the analog station calls the SIP station. As a workaround, either
run the rtmd restart command or restart the device.
■
On SRX5600 and SRX5800 devices, the set security end-to-end-debug CLI hierarchy
command has been changed to set security datapath-debug.
■
On AX411 Access Points, the possible completions available for the CLI command
set wlan access-point mav0 radio 1 radio-options mode? are changed from previous
implementations.
Now this CLI command displays the possible completions as shown below:
■
Example 1:
user@host# set wlan access-point mav0 radio 1 radio-options mode ?
Possible completions:
5GHz Radio Frequency -5GHz-n
a Radio Frequency -a
an Radio Frequency -an
[edit]
■
140
Routers
■
Example 2:
user@host# set wlan access-point mav0 radio 2 radio-options mode ?
2.4GHz Radio Frequency --2.4GHz-n
bg Radio Frequency -bg
bgn Radio Frequency -bgn
■
On SRX Series devices, the show system storage partitions command now displays
the partitioning scheme details on SRX Series devices.
■
Example 1:
show system storage partitions (dual root partitioning)
user@host# show system storage partitions
Boot Media: internal (da0)
Active Partition: da0s2a
Backup Partition: da0s1a
Currently booted from: active (da0s2a)
Partitions Information:
Partition Size Mountpoint
s1a 293M altroot
s2a 293M /
s3e 24M /config
s3f 342M /var
s4a 30M recovery
■
Example 2:
show system storage partitions (single root partitioning)
Boot Media: internal (da0)
s1a 898M /
s1e 24M /config
s1f 61M /var
show system storage
partitions (USB)
■
Example 3:
show system storage partitions (usb)
Boot Media: usb (da1)
Active Partition: da1s1a
Backup Partition: da1s2a
Currently booted from: active (da1s1a)
s1a 293M /
s2a 293M altroot
s3e 24M /config
s3f 342M /var
s4a 30M recovery
■
On AX411 Access Points, the possible completions available for the CLI command
set wlan access-point < ap_name > radio < radio_num > radio-options channel
number ? have changed from previous Implementations.
Routers
■
141
Now this CLI command displays the following possible completions:
Example 1:
user@host# set wlan access-point ap6 radio 1 radio-options channel number ?
36 Channel 36
40 Channel 40
44 Channel 44
48 Channel 48
52 Channel 52
56 Channel 56
60 Channel 60
64 Channel 64
100 Channel 100
108 Channel 108
112 Channel 112
116 Channel 116
120 Channel 120
124 Channel 124
128 Channel 128
132 Channel 132
136 Channel 136
140 Channel 140
149 Channel 149
153 Channel 153
157 Channel 157
161 Channel 161
165 Channel 165
auto Automatically selected
Example 2:
user@host# set wlan access-point ap6 radio 2 radio-options channel number ?
1 Channel 1
2 Channel 2
3 Channel 3
4 Channel 4
5 Channel 5
6 Channel 6
7 Channel 7
8 Channel 8
9 Channel 9
10 Channel 10
11 Channel 11
12 Channel 12
13 Channel 13
14 Channel 14
auto Automatically selected
Configuration
■
142
Routers
■
J Series devices no longer allow a configuration in which a tunnel's source or
destination address falls under the subnet of the same logical interface’s address.
■
■
On SRX100, SRX210, SRX240 and, SRX650 devices, the current JUNOS Software
default configuration is inconsistent with the one in Secure Services Gateways,
thus causing problems when users migrate to SRX Series devices. As a
workaround, users should ensure the following steps are taken:
■
The ge-0/0/0 interface should be configured as the Untrust port (with the
DHCP client enabled).
■
The rest of the on-board ports should be bridged together, with a VLAN IFL
and DHCP server enabled (where applicable).
■
Default policies should allow trust->untrust traffic.
■
Default NAT rules should apply interface-nat for all trust->untrust traffic.
■
DNS/Wins parameters should be passed from server to client and, if not
available, users should preconfigure a DNS server (required for download of
security packages).
The default values for IKE and IPsec security association (SA) lifetimes for standard
VPNs have been changed in this release:
■
The default value for the lifetime-seconds configuration statement at the [edit
security ike proposal proposal-name] hierarchy level has been changed from
3600 seconds to 28,800 seconds.
■
The default value for the lifetime-seconds configuration statement at the [edit
security ipsec proposal proposal-name] hierarchy level has been changed from
28,800 seconds to 3600 seconds.
Flow and Processing
■
On SRX Series devices, the factory default for the maximum number of backup
configurations allowed is five. Therefore, you can have one active configuration
and a maximum of five rollback configurations. Increasing this backup
configuration number will result in increased memory usage on disk and
increased commit time.
To modify the factory defaults, use the following commands:
root@host# set system max-configurations-on-flash number
root@host# set system max-configuration-rollbacks number
where max-configurations-on-flash indicates backup configurations to be stored
in the configuration partition and max-configuration-rollbacks indicates the
maximum number of backup configurations.
■
On J Series devices, the following configuration changes must be done after
rollback or upgrade from JUNOS Release 10.1 to 9.6 and earlier releases.
■
Rename lsq-0/0/0 to ls-0/0/0 in all its occurrences.
■
Remove fragmentation-map from the [class-of-service] hierarchy level and
from [class-of-service interfaces lsq-0/0/0], if configured.
■
Remove multilink-max-classes from [ls-0/0/0 unit 0], if configured.
Routers
■
143
■
Remove link-layer-overhead from [ls-0/0/0 unit 0], if configured.
■
If the LFI forwarding class is mapped to no-fragmentation in fragmentation-map
and the configuration hierarchy is enabled on lsq-0/0/0 in JUNOS Release
10.1, then
■
Add interleave-fragments under [ls-0/0/0 unit 0]
■
Adjust classifier configured for LFI on lsq-0/0/0 under [class-of-service]
to classify packets to Q2
If the aforementioned instructions are not followed, the bundle will be incorrectly
processed.
■
On SRX Series devices, to minimize the size of system logs, the default logging
level in the factory configuration has been changed from any any to any critical.
■
On SRX3000 and SRX5000 line devices, the set protocols bgp family inet flow and
set routing-options flow CLI statements are no longer available, because BGP flow
spec functionality is not supported on these devices.
■
On SRX100, SRX210, SRX240, and SRX650 devices, the autoinstallation
functionality on an interface enables a DHCP client on the interface and remains
in the DHCP client mode. In previous releases, after a certain period, the interface
changed from being a DHCP client to a DHCP server.
■
On SRX5600 and SRX5800 devices, while running commands in IDP, ensure
that you provide the service field values for custom attack definitions in lowercase.
In the following example, the protocol service field value udp is specified in
lowercase:
set security idp custom-attack temp severity info attack-type signature context packet
direction any pattern .* protocol udp destination-port match equal value 1333
144
Routers
■
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, for brute force and
time-binding-related attacks, the logging is to be done only when the match count
is equal to the threshold. That is, only one log is generated within the 60-second
period in which the threshold is measured. This process prevents repetitive logs
from being generated and ensures consistency with other IDP platforms like
IDP-standalone.
■
On SRX Series and J Series devices, the IDP ip-action statement is now supported
on TCP, UDP, and ICMP flows. When the ip-action target is service, the ip-action
flow is applied if the traffic matches the values specified for protocol, destination
port, source address, and destination address. However, for ICMP flows, the
destination port is 0, so that any ICMP flow matching protocol, source address,
and destination address is blocked. For more information, see the Junos OS CLI
Reference.
■
On SRX3400 and SRX3600 devices in Layer 2 and Layer 3 integrated mode,
mode, 30 percent to 40 percent of the logs created in IDP are not exited from
IDP. In Layer 2 and Layer 3 dedicated mode, the logs are exited properly.
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, to add the Predefined
Attacks and Predefined Attack Groups, users do not need to type the attack
names. Instead, users can select attacks from the Predefined Attacks and
Predefined Attack Group lists and click the left arrow to add them.
■
On SRX100, SRX210, SRX240, and SRX650 devices, the LED status (Alarm, HA,
ExpressCard, Power Status, and Power) shown in the front panel for Chassis
View does not replicate the exact status of the device.
J-Web
Management and Administration
■
On SRX5600 and SRX5800 devices running a previous release of JUNOS Software,
security logs were always timestamped using the UTC time zone. In JUNOS
Release 10.1, you can use the set system time-zone CLI command to specify the
local time zone that the system should use when timestamping the security logs.
If you want to timestamp logs using the UTC time zone, use the set system
time-zone utc and set security log utc-timestamp CLI statements.
■
Configuring the External CompactFlash card on SRX650 Services Gateways:
The SRX650 Services Gateway includes 2-GB CompactFlash storage devices:
■
The Services and Routing Engine (SRE) contains a hot-pluggable
CompactFlash (external CompactFlash) storage device used to upload and
download files.
■
The chassis contains an internal compact flash used to store the operating
system.
By default, only the internal CompactFlash is enabled, and an option to take a
snapshot of the configuration from the internal CompactFlash to the external
compact flash is not supported. This can be done only by using a USB storage
device.
To take a snapshot on the external CompactFlash:
1.
Take a snapshot from the internal CompactFlash to the USB storage device
using the request system snapshot media usb CLI command.
2.
Reboot the device from the USB storage device by using the request system
reboot media usb command.
3.
Go to the U-boot prompt. For more information, see the "Accessing the
U-Boot Prompt" section in the JUNOS Software Administration Guide.
4.
At the U-boot prompt, set the following variables:
set ext.cf.pref 1
Routers
■
145
save
reset
5.
Once the system is booted from the USB storage device, take a snapshot on
the external CompactFlash using the request system snapshot media external
command.
NOTE: Once the snapshot has been taken on the external CompactFlash, we
recommend you to set the ext.cf.pref to 0 at the U-boot prompt.
Security
■
J Series devices do not support the authentication order password radius or
password ldap in the edit access profile profile-name authentication-order command.
Instead, use order radius password or ldap password.
■
While configuring the AX411 Access Point on your SRX Series devices, make
sure to enter the WLAN admin password using the set wlan admin-authentication
password command. This command prompts for the password and the password
entered is stored in encrypted form.
WLAN
NOTE:
■
Without wlan config option enabled, the AX411 Access Points will be managed
with the default password.
146
Routers
■
■
Changing the wlan admin-authentication password when the wlan subsystem option
is disabled might result in mismanagement of Access Points . You might have
to power cycle the Access Points manually to avoid this issue.
■
The SRX Series devices that are not using the AX411 Access Point can optionally
delete the wlan config option.
■
Accessing the AX411 Access Point through SSH is disabled by default. You can
enable the SSH access using the set wlan access-point <name> external system
services enable-ssh command.
Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series
Services Routers
[accounting-options] Hierarchy
■
On SRX210 and SRX240 devices, the accounting, source-class, and
destination-class statements in the [accounting-options] hierarchy level are not
supported.
■
On SRX100 devices, there are command-line interface (CLI) commands and
J-Web tabs for wireless LAN configurations related to the AX411 Access Point.
However, at this time the SRX100 devices do not support the AX411 Access
Point.
AX411 Access Point
Chassis Cluster
On SRX Series and J Series devices, the following features are not supported when
chassis clustering is enabled on the device:
■
All packet-based protocols, such as MPLS, Connectionless Network Service (CLNS),
and IP version 6 (IPv6)
■
Any function that depends on the configurable interfaces:
■
lsq-0/0/0—Link services Multilink Point-to-Point Protocol (MLPPP), Multilink
Frame Relay (MLFR), and Compressed Real-Time Transport Protocol (CRTP)
■
gr-0/0/0—Generic routing encapsulation (GRE) and tunneling
■
ip-0/0/0—IP-over-IP (IP-IP) encapsulation
■
pd-0/0/0, pe/0/0/0, and mt-0/0/0—All multicast protocols
■
lt-0/0/0—Real-time performance monitoring (RPM)
■
WXC Integrated Services Module (WXC ISM 200)
■
ISDN BRI
■
Layer 2 Ethernet switching
The factory default configuration for SRX100, SRX210, and SRX240 devices
automatically enables Layer 2 Ethernet switching. Because Layer 2 Ethernet
switching is not supported in chassis cluster mode, for these devices, if you
use the factory default configuration, you must delete the Ethernet switching
configuration before you enable chassis clustering.
CAUTION: Enabling chassis clustering while Ethernet switching is enabled is not a
supported configuration. Doing so might result in undesirable behavior from the
devices, leading to possible network instability.
■
147
The default configuration for other SRX Series devices and all J Series devices
does not enable Ethernet switching. However, if you have enabled Ethernet
switching, be sure to disable it before enabling clustering on these devices
too.
For more information, see the “Disabling Switching on SRX100, SRX210,
and SRX240 Devices Before Enabling Chassis Clustering” section in the
JUNOS Software Security Configuration Guide.
SRX Series devices have the following limitations:
■
Only two of the 10 ports on each PIC of 40-port 1-Gigabit Ethernet I/O cards
(IOCs) for SRX5600 and SRX5800 devices can simultaneously enable IP address
monitoring. Because there are four PICs per IOC, this permits a total of eight
ports per IOC to be monitored. If more than two ports per PIC on 40-port 1-Gigabit
Ethernet IOCs are configured for IP address monitoring, the commit will succeed
but a log entry will be generated, and the accuracy and stability of IP address
monitoring cannot be ensured. This limitation does not apply to any other IOCs
or devices.
■
SRX3400, SRX3600, SRX5600, and SRX5800 devices have the following
limitations:
■
■
IP address monitoring is not permitted on redundant Ethernet interface LAGs
or on child interfaces of redundant Ethernet interface LAGs.
■
In-service software upgrade (ISSU) does not support version downgrading.
That is, ISSU does not support running an ISSU install of a software release
package earlier or with a smaller release number than the currently installed
version.
■
Only redundant Ethernet interfaces (reth) are supported for IKE external
interface configuration in IPsec VPN. Other interface types can be configured
but IPsec VPN might not work
On SRX3000 and SRX5000 line chassis clusters, screen statistics data can be
gathered on the primary device only.
J Series devices have the following limitations:
■
A Fast Ethernet port from a 4-port Ethernet PIM cannot be used as a fabric link
port in a chassis cluster.
On SRX210 and SRX240 devices, J-Web crashes if more than nine users log in to the
device by using the CLI.
The number of users allowed to access the device is limited as follows:
148
■
■
For SRX210 devices: four CLI users and three J-Web users
■
For SRX240 devices: six CLI users and five J-Web users
Dynamic VPN
SRX100, SRX210, and SRX240 devices have the following limitations:
■
The IKE configuration for the dynamic VPN client does not support the
hexadecimal preshared key.
■
The dynamic VPN client IPsec does not support the Authentication Header (AH)
protocol and the Encapsulating Security Payload (ESP) protocol with NULL
authentication.
■
When you log in through the Web browser (instead of logging in through the
dynamic VPN client) and a new client is available, you are prompted for a client
upgrade even if the force-upgrade option is configured. Conversely, if you log in
using the dynamic VPN client with the force-upgrade option configured, the client
upgrade occurs automatically (without a prompt).
■
On SRX Series devices, data plane logs generated in event mode or in
configurations using set system syslog can increase CPU utilization dramatically,
impacting the system stability, especially in chassis cluster mode.
■
Maximum concurrent SSH, Telnet, and Web sessions—On SRX210, SRX240,
and SRX650 devices, the maximum number of concurrent sessions is as follows:
Flow and Processing
Sessions
SRX210
SRX240
SRX650
ssh
3
5
5
telnet
3
5
5
Web
3
5
5
NOTE: These defaults are provided for performance reasons.
■
On SRX210 and SRX240 devices, for optimized efficiency, we recommend that
you limit use of CLI and J-Web to the following numbers of sessions:
Device
CLI
J-Web
Console
SRX210
3
3
1
SRX240
5
5
1
■
149
■
On SRX100 devices, Layer 3 control protocols (OSPF, using multicast destination
MAC address) on the VLAN Layer 3 interface work only with access ports.
■
On SRX210, SRX240, and J Series devices, broadcast TFTP is not supported
when flow is enabled on the device.
■
On SRX5800 devices, network processing bundling is not supported in Layer 2
transparent mode.
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, downgrading is not
supported in low-impact in-service software upgrade (ISSU) chassis cluster
upgrades (LICU).
Hardware
This section covers filter and policing limitations.
■
On SRX3400 and SRX3600 devices, the following feature is not supported by a
simple filter:
■
■
■
■
150
■
Forwarding class as match condition
On SRX3400 and SRX3600 devices, the following features are not supported by
a policer or a three-color-policer:
■
Color-aware mode of a three-color-policer
■
Filter-specific policer
■
Forwarding class as action of a policer
■
Logical interface policer
■
Logical interface three-color policer
■
Logical interface bandwidth policer
■
Packet loss priority as action of a policer
■
Packet loss priority as action of a three-color-policer
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the following features
are not supported by a firewall filter:
■
Policer action
■
Egress FBF
■
FTF
SRX3400 and SRX3600 devices have the following limitations of a simple filter:
■
In the packet processor on an IOC, up to 100 logical interfaces can be applied
with simple filters.
■
In the packet processor on an IOC, the maximum number of terms of all
simple filters is 4000.
■
In the packet processor on an IOC, the maximum number of policers is
4000.
■
In the packet processor on an IOC, the maximum number of
three-color-policers is 2000.
■
The maximum burst size of a policer or three-color-policer is 16 MB.
■
On SRX650 devices, the T1/E1 GPIMs (2 or 4 port version) do not work in 9.6R1.
This issue is resolved in JUNOS Release 9.6R2 and JUNOS Release 10.1, but if
you roll back to the 9.6R1 image, this issue is still seen.
■
On SRX650 devices, MAC pause frame and FCS error frame counters are not
supported for the interfaces ge-0/0/0 through ge-0/0/3.
■
On SRX240 and SRX650 devices, the VLAN range from 3967 to 4094 falls under
the reserved VLAN address range, and the user is not allowed any configured
VLANs from this range.
■
On SRX650 devices, the last 4 ports of a 24-Gigabit Ethernet switch GPIM can
be used either as RJ-45 or SFP ports. If both are present and providing power,
the SFP media is preferred. If the SFP media is removed or the link is brought
down, then the interface will switch to the RJ-45 medium. This can take up to
15 seconds, during which the LED for the RJ-45 port might go up and down
intermittently. Similarly when the RJ-45 medium is active and an SFP link is
brought up, the interface will transition to the SFP medium, and this transition
could also take a few seconds.
■
On SRX Series and J Series devices, the user can use IPsec only on an interface
that resides in the routing instance inet 0. The user will not be able to assign an
internal or external interface to the IKE policy if that interface is placed in a
routing instance other than inet 0.
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the following multicast
IPv6 and MVPN CLI commands are not supported. However, if you enter these
commands in the CLI editor, they will appear to succeed and will not display an
error message.
■
show pim interfaces inet6
■
show pim neighbors inet6
■
show pim source inet6
■
show pim rps inet6
■
show pim join inet6
■
show pim mvpn
■
show multicast next-hops inet6
■
show multicast rpf inet6
■
show multicast route inet6
■
show multicast scope inet6
■
151
■
152
■
■
show multicast pim-to-mld-proxy
■
show multicast statistics inet6
■
show multicast usage inet6
■
show msdp sa group group
■
set protocols pim interface interface family inet6
■
set protocols pim disable interface interface family inet6
■
set protocols pim family inet6
■
set protocols pim disable family inet6
■
set protocols pim apply-groups group disable family inet6
■
set protocols pim apply-groups group family inet6
■
set protocols pim apply-groups-except group disable family inet6
■
set protocols pim apply-groups group interface interface family inet6
■
set protocols pim apply-groups group apply-groups-except group family inet6
■
set protocols pim apply-groups group apply-groups-except group disable family
inet6
■
set protocols pim assert-timeout timeout-value family inet6
■
set protocols pim disable apply-groups group family inet6
■
set protocols pim disable apply-groups-except group family inet6
■
set protocols pim disable export export-join-policy family inet6
■
set protocols pim disable dr-election-on-p2p family inet6
■
set protocols pim dr-election-on-p2p family inet6
■
set protocols pim export export-join-policy family inet6
■
set protocols pim import export-join-policy family inet6
■
set protocols pim disable import export-join-policy family inet6
On SRX210 devices, the USB modem interface can handle bidirectional traffic
of up to 19 kbps. On oversubscription of this amount (that is, bidirection traffic
of 20 kbps or above), keepalives not get exchanged, and the interface goes down.
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, application-level
distributed denial-of-service (application-level DDoS) detection does not work if
two rules with different application-level DDoS applications process traffic going
to a single destination application server. When setting up application-level DDoS
rules, make sure you do not configure rulebase-ddos rules that have two different
application-ddos objects while the traffic destined to one application server can
process more than one rule. Essentially, for each protected application server,
you have to configure the (application-level DDoS rules so that traffic destined
for one protected server only processes one application-level DDoS rule.
NOTE: Application-level DDoS rules are terminal, which means that once traffic is
processed by one rule, it will not be processed by other rules.
The following configuration options can be committed, but they will not work
properly:
source-zone
destination-zone
destination-ip
service
application-ddos
Application Server
source–zone-1
dst-1
any
http
http-appddos1
1.1.1.1:80
source-zone-2
dst-1
any
http
http-appddos2
1.1.1.1:80
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the application-level
denial-of-service (application-level DDoS) rulebase (rulebase-ddos) does not
support port mapping. If you configure an application other than default, and if
the application is from either predefined JUNOS Software applications or a custom
application that maps an application service to a nonstandard port,
application-level DDoS detection will not work.
When you configure the application setting as default, IDP uses application
identification to detect applications running on standard and nonstandard ports,
hence the application-level DDoS detection would work properly.
■
On SRX210, SRX240, and SRX650 devices, the maximum number of IDP sessions
supported is 16,000.
■
On SRX Series devices, all IDP policy templates are supported except All Attacks.
There is a 100-MB policy size limit for integrated mode and a 150-MB policy size
limit for dedicated mode, and the current IDP policy templates supported are
dynamic, based on the attack signatures being added. Therefore, be aware that
supported templates might eventually grow past the policy-size limit.
On SRX Series devices, the following IDP policies are supported:
■
DMZ_Services
■
DNS_Service
■
File_Server
■
153
■
■
■
Getting_Started
■
IDP_Default
■
Recommended
■
Web_Server
IDP deployed in both active/active and active/passive chassis clusters has the
following limitations:
■
No inspection of sessions that fail over or fail back.
■
The IP address action table is not synchronized across nodes.
■
The Routing Engine (RE) on the secondary node might not be able to reach
networks that are reachable only through a Packet Forwarding Engine (PFE).
■
The SSL session-ID cache is not synchronized across nodes. If an SSL session
reuses a session-ID and it happens to be processed on a node other than the
one on which the session-ID is cached, the SSL session cannot be decrypted
and will be bypassed for IDP inspection.
IDP deployed in active/active chassis clusters has the following limitation:
■
For time-binding scope source traffic, if attacks from a source with more
than one destination have active sessions distributed across nodes, the attack
might not be detected because time-binding counting has a local-node-only
view. Detecting this sort of attack requires an RTO synchronization of the
time-binding state that is not currently supported.
■
On SRX100, SRX210, SRX240, and SRX650 devices, maximum supported entries
in ACS table for is 100,000 entries. However, since the user land buffer has fix
size of 1MB as a limitation, therefore it displays maximum 38837 cache entries.
■
IDP does not allow header checks for nonpacket contexts.
■
On J Series devices, some J-Web pages for new features (for example, the Quick
Configuration page for the switching features on J Series devices) display content
in one or more modal pop-up windows. In the modal pop-up windows, you can
interact only with the content in the window and not with the rest of the J-Web
page. As a result, online Help is not available when modal pop-up windows are
displayed. You can access the online Help for a feature only by clicking the Help
button on a J-Web page.
■
On SRX Series devices, you cannot use J-Web to configure a VLAN interface for
an IKE gateway. VLAN interfaces are not currently supported to be used as IKE
external-interfaces.
J-Web
154
■
NetScreen-Remote
■
On SRX Series devices, NetScreen-Remote is not supported in JUNOS Release
10.1.
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, IKE negotiations
involving NAT traversal do not work if the IKE peer is behind a NAT device that
will change the source IP address of the IKE packets during the negotiation. For
example, if the NAT device is configured with DIP, it changes the source IP
because the IKE protocol switches the UDP port from 500 to 4500.
■
The following describes the maximum numbers of NAT rules and rule sets
supported:
■
For static NAT, up to 32 rule sets and up to 256 rules per rule set can be
configured on a device.
■
For destination NAT, up to 32 rule sets and up to 8 rules per rule set can be
configured on a device.
■
For source NAT, the following are the maximum numbers of source NAT
rules that can be configured on a device:
■
512 for J Series, SRX100, and SRX210 devices
■
1024 for SRX240 and SRX650 devices
■
8192 for SRX3400, SRX3600, SRX5600, and SRX5800 devices
These are systemwide maximums for total numbers of source NAT rules.
There is no limitation on the number of rules that you can configure in a
source NAT rule set as long as the maximum number of source NAT rules
allowed on the device is not exceeded.
■
155
Performance
■
J Series devices now support IDP and UTM functionality. Under heavy network
traffic in a few areas of functionality, such as NAT and IPsec VPN, performance
is still being improved to reach the high levels to which Juniper Networks is
consistently committed.
■
On J Series devices, the SNMP NAT-related MIB is not supported in JUNOS Release
10.1.
■
On SRX650 devices, if one of the four Gigabit Ethernet ports (ge-0/0/0 through
ge-0/0/3) is linked up at 10 or 100 Mbps, it will not support jumbo frames.
Frames greater than 1500 bytes are dropped.
SNMP
System
Unified Threat Management (UTM)
■
UTM requires 1 GB of memory. If your J2320, J2350, or J4350 device has only
512 MB of memory, you must upgrade the memory to 1 GB to run UTM.
■
On SRX100, SRX210, SRX240, SRX650, and J Series devices, the IRB (VLAN)
interface cannot be used as the underlying interface for Point-to-Point Protocol
over Ethernet (PPPoE).
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the IPsec NAT-T tunnels
scaling and sustaining issues are as follows:
VLAN
VPNs
■
For a given private IP address, the NAT device should translate both 500
and 4500 private ports to same public IP address.
■
The total number of tunnels from a given public translated IP cannot exceed
1000 tunnels.
WLAN
■
156
■
The following are the maximum numbers of access points that can be configured
and managed from SRX Series devices:
■
SRX210—4 access points
■
Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
■
NOTE: The number of licensed access points can exceed the maximum number of
supported access points. However, you can only configure and manage the maximum
number of access points.
Related Topics
■
■
■
Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
Routers
■
Outstanding Issues In JUNOS Release 10.1 for SRX Series Services Gateways and
■
Resolved Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J
Outstanding Issues In JUNOS Release 10.1 for SRX Series Services
The following problems currently exist in SRX Series and J Series devices. The
identifier following the description is the tracking number in our bug database.
■
On SRX5600 devices, if you run the show security alg sip counters command
while doing a bulk call generation, it might bring down the SPU with a flowd
core file error. [PR/292956]
■
On SRX210 devices, the Skinny Client Control Protocol (SCCP)call cannot be set
up after disabling and enabling the SCCP ALG. The call does not go through.
[PR/409586]
■
On SRX3400 and SRX3600 devices, Real-Time Streaming Protocol (RTSP),, TFTP,
and FTP ALG at scale in Layer 2 mode with A/P is not supported in JUNOS Release
10.1. [PR/474140]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, ALGs are enabled by
default. When security policies are configured with IDP service, there might be
packet drops. When IDP service is enabled through security policy configuration,
we recommend that you disable some or all the ALGs through configuration to
avoid packet drops. For example: set security alg rtsp disable. [PR/474629]
■
157
NOTE: Disabling ALGs will prevent auxiliary or pinhole session creation, and those
sessions might not be permitted based on security policy. The choice depends on
the customer network and what services are being run, whether ALGs need to be
enabled, and whether IDP inspection is required for all or a subset of the traffic.
Authentication
■
On J Series devices, your attempt to log in to the router from a management
device through FTP or Telnet might fail if you type your username and password
in quick succession before the prompt is displayed, in some operating systems.
As a workaround, type your username and password after you see the prompts.
[PR/255024]
■
On J Series devices, after the user is authenticated, if the webauth-policy is deleted
or changed and an entry exists in the firewall authentication table, then an
authentication entry created as a result of webauth will be deleted only if a traffic
flow session exists for that entry. Otherwise, the webauth entry will not be deleted
and will only age out. This behavior will not cause a security breach. [PR/309534]
■
On SRX210 PoE devices, the access point reboots when 100 clients are associated
simultaneously and each one is transmitting 512 bytes packets at 100 pps.
[PR/469418]
■
On SRX650 devices, when an access point is part of a default cluster and you
change the default cluster after the access point is connected to it, the changes
might not be reflected. As a workaround, restart the wireless LAN service.
[PR/497752]
■
On J Series devices in a chassis cluster, the show interface terse command on
the secondary Routing Engine does not display the same details as that of the
primary Routing Engine. [PR/237982]
■
On J4350 Services Routers, because the clear security alg sip call command
triggers a SIP RTO to synchronize sessions in a chassis cluster, use of the
command on one node with the node-id, local, or primary option might result in
a SIP call being removed from both nodes. [PR/263976]
■
On J Series devices, when a new redundancy group is added to a chassis cluster,
the node with lower priority might be elected as primary when the preempt
option is not enabled for the nodes in the redundancy group. [PR/265340]
■
On J Series devices, when you commit a configuration for a node belonging to
a chassis cluster, all the redundancy groups might fail over to node 0. If graceful
protocol restart is not configured, the failover can destabilize routing protocol
adjacencies and disrupt traffic forwarding. To allow the commit operation to
take place without causing a failover, we recommend that you use the set chassis
cluster heartbeat-threshold 5 command on the cluster. [PR/265801]
AX411 Access Point
Chassis Cluster
158
■
■
On J Series devices in a chassis cluster, a high load of SIP ALG traffic might result
in some call leaks in active resource manager groups and gates on the backup
router. [PR/268613]
■
On SRX Series devices in a chassis cluster, configuring the set system process
jsrp-service disable command only on the primary node causes the cluster to go
into an incorrect state. [PR/292411]
■
On SRX Series devices in a chassis cluster, using the set system processes
chassis-control disable command for 4 to 5 minutes and then enabling it causes
the device to crash. Do not use this command on an SRX Series device in a
chassis cluster. [PR/296022]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, 8-queue configurations
are not reflected on the chassis cluster interface. [PR/389451]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the iflset functionality
is not supported for aggregated interfaces such as reth. [PR/391377]
■
On an SRX210 device in a chassis cluster, when you upgrade the nodes,
sometimes the forwarding process might crash and be restarted. [PR/396728]
■
On an SRX210 device in a chassis cluster, when you upgrade to the latest software
image, the interface links do not come up and are not seen in the Packet
Forwarding Engine. As a workaround, you can reboot the device to bring up the
interface. [PR/399564]
■
On an SRX210 device in a chassis cluster, sometimes the reth interface MAC
address might not make it to the switch filter table. This results in the dropping
of traffic sent to the reth interface. As a workaround, restart the Packet
Forwarding Engine. [PR/401139]
■
On an SRX210 device in a chassis cluster, the fabric-monitoring option is enabled
by default. This can cause one of the nodes to move to a disabled state. You can
disable fabric monitoring by using the following CLI command:
set chassis cluster fabric-monitoring disable
[PR/404866]
■
On an SRX210 Low Memory device in a chassis cluster, the firewall filter does
not work on the reth interfaces. [PR/407336]
■
On an SRX210 device in a chassis cluster, the restart forwarding method is not
recommended because when the control link goes through forwarding, the restart
forwarding process causes disruption in the control traffic. [PR/408436]
■
On an SRX210 device in a chassis cluster, there might be a loss of about 5 packets
with 20 Mbps of UDP traffic on an RG0 failover. [PR/413642]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, no trap is generated
for redundancy group 0 failover. You can check on the redundancy group 0 state
only when you log in to the device. The nonavailability of this information is
caused by a failure of the SNMP walk on the backup (secondary) node. As a
workaround, use a master-only IP address across the cluster so that you can
query a single IP address and that IP address will always be the master for
redundancy group 0. [PR/413719]
■
On an SRX210 device with an FTP session ramp-up rate of 70, either of the
following might disable the secondary node:
■
159
■
Back-to-back redundancy group 0 failover
■
Back-to-back primary node reboot
[PR/414663]
■
If an SRX210 device receives more traffic than it can handle, node 1 either
disappears or is disabled. [PR/416087]
■
On SRX3400, SRX3600, SRX5600, SRX5800, and J Series devices in an
active/active chassis cluster, when the fabric link fails and then recovers, services
with a short time-to-live (such as ALG FTP) stop working. [PR/419095]
■
On SRX5800 devices, SNMP traps might not be generated for the
ineligible-primary state. [PR/434144]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices in chassis cluster
active/active mode, the J-Flow samplings do not occur and the records are not
exported to the cflowd server. [PR/436739]
■
On SRX240 Low Memory and High Memory devices, binding the same IKE policy
to a dynamic gateway and a site-to-site gateway is not allowed. [PR/440833]
■
On SRX650 devices, the following message appears on the new primary node
after a reboot or an RG0 failover:
WARNING: cli has been replaced by an updated version:
CLI release 9.6B1.5 built by builder on 2009-04-29 08:24:20 UTC
Restart cli using the new version ? [yes,no] (yes) yes
[PR/444470]
160
■
■
On SRX240 devices, the cluster might be destabilized when the file system is
full and logging is configured on JSRPD and chassisd. The log file size for the
various modules should be appropriately set to prevent the file system from
getting full. [PR/454926]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices in a chassis cluster,
the ping operation to the redundant Ethernet interface (reth) fails when the cluster
ID changes. [PR/458729]
■
On SRX100 devices, after primary node reboot and cold synchronization are
finished, the chassis cluster auth session timeout age and application name
cannot synchronize with the chassis cluster peers. [PR/460181]
■
On SRX5600 devices, low-impact in-service software upgrade (ISSU) chassis
cluster upgrade does not succeed with the no-old-master-upgrade option when
you upgrade from JUNOS Release 9.6R2 to JUNOS Release 10.1. [PR/471235]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the secondary node
displays incorrect interface status after a low-impact in-service software upgrade
(ISSU) from JUNOS Release 9.6R2 to JUNOS Release 10.1R1. [PR/482566]
■
On SRX3400 and SRX3600 devices, chassis cluster upgrades (LICU) with
no-old-master-upgrade from JUNOS Release 9.6R2.11 to 10.0R1.x and from
JUNOS Release 10.0R1.8 to 10.1x.x do not work. [PR/483485]
■
On SRX3600 devices, after you disable and enable the secondary node track,
the IP status remains unreachable. [PR/488890]
■
On SRX5600, SRX5800 devices, the shaping rate doubles during LICU upgrades
after the secondary node becomes the primary node and continues to be the
same doubled value after LICU, when the LICU upgrade is performed for JUNOS
Release 10.0R2 to 10.1R2. [PR/491834]
■
On SRX5600 and SRX5800 devices, the shaping rate is not honored during LICU
upgrades. During LICU upgrades, when the secondary node is upgraded to the
primary node, the shaping rate is doubled and continues to be the same doubled
value after the LICU upgrade is finished. [PR/499481]
■
J4350 and J6350 devices might not have the requisite data buffers needed to
meet expected delay-bandwidth requirements. Lack of data buffers might degrade
CoS performance with smaller (500 bytes or less) packets. [PR/73054]
■
On J Series devices, with a CoS configuration, when you try to delete all the flow
sessions using the clear security flow session command, the WXC application
acceleration platform might fail over with heavy traffic. [PR/273843]
■
On SRX Series devices, class-of-service-based forwarding (CBF) does not work.
[PR/304830]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you change the
scheduler type on the Layer 2 aggregated Ethernet interface, the clear interface
statistics command does not work for the aggregated Ethernet bundle.
[PR/485904]
Class of Service (CoS)
■
161
Dynamic Host Configuration Protocol (DHCP)
■
On SRX210 and SRX240 devices, when autoinstallation is configured to run on
a particular interface and the default static route is set with options discard,
retain and no-advertise, then the DHCP client running on the interface tries
fetching the configuration files from the TFTP server. During this process, the
UDP data port on the TFTP server might be unreachable. Because of the TFTP
server being unreachable, the autoinstallation process might remain in the
configuration acquisition state. When autoinstallation is disabled, the TFTP might
fail. In this case, you should manually fetch the file from the server or the client
through the relay.
As a workaround, remove the static route options: Discard, Retain, and
no-advertise from the configuration. [PR/454189]
Enhanced Switching
■
On J Series devices, if the access port is tagged with the same VLAN that is
configured at the port, the access port accepts tagged packets and determines
the MAC. [PR/302635]
■
On J Series devices, even when forwarding options are set to drop packets for
the ISO protocol family, the device forms End System-to-Intermediate System
(ES-IS) adjacencies and transmits packets because ES-IS packets are Layer 2
terminating packets. [PR/252957]
■
On SRX Series devices, the show security flow session command currently does
not display aggregate session information. Instead, it displays sessions on a
per-SPU basis. [PR/264439]
■
On J Series devices, OSPF over a multipoint interface connected as a
hub-and-spoke network does not restart when a new path is found to the same
destination. [PR/280771]
■
On SRX Series devices, when traffic matches a deny policy, sessions will not be
created successfully. However, sessions are still consumed, and the
unicast-sessions and sessions-in-use fields shown by the show security flow session
summary command will reflect this. [PR/284299] [PR/397300]
■
On J Series devices, outbound filters will be applied twice for host-generated
IPv4 traffic. [PR/301199]
■
On SRX Series devices, configuring the flow filter with the all flag might result
in traces that are not related to the configured filter. As a workaround, use the
flow trace flag basic with the command set security flow traceoptions flag.
[PR/304083]
■
On SRX210, SRX240, and SRX650 devices, after the device fragments packets,
the FTP over a GRE link might not perform properly because of packet
serialization. [PR/412055]
Flow and Processing
162
■
■
On SRX240 devices, traffic flooding occurs when multiple multicast IP group
addresses are mapped to the same multicast MAC address because multicast
switching is based on the Layer 2 address. [PR/418519]
■
On SRX650 devices, the input DA errors are not updated when packets are
dropped because of MAC filtering on the following:
■
SRX240 device
■
SRX210 device
■
16-port and 24-port GPIMs
■
SRX650 front-end port
This is due to MAC filtering implemented in hardware.
[PR/423777]
■
On SRX5600 and SRX5800 devices, the network processing bundle configuration
CLI does not check if PICs in the bundle are valid. [PR/429780]
■
On SRX650 devices, packet loss is observed when the device interoperates with
an SSG20 with AMI line encoding. [PR/430475]
■
On an SRX210 on-board Ethernet port, an IPv6 multicast packet received gets
duplicated at the ingress. This happens only for IPv6 multicast traffic in ingress.
[PR/432834]
■
On SRX3400 and SRX3600 devices, the ramp rate of session creation is slow at
times for fragmented UDP traffic. [PR/434508]
■
On SRX5800 devices, when there are nonexistent PICs in the network processing
bundle, the traffic is sent out to the PICs and is lost. [PR/434976]
■
The SRX5600 and SRX5800 devices create more than the expected number of
flow sessions with NAT traffic. [PR/437481]
■
On J Series devices, NAT traffic that goes to the WXC ISM 200 and return back
clear (that is, not accelerated by the WXC ISM 200) does not work. [PR/438152]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, there is missing
information in the jnxJsFwAuthMultipleFailure trap message. The trap message is
required to contain the username, IP address, application, and trap name, but
the username is missing. [PR/439314]
■
On SRX5800 devices, for any network processing bundle configuration change
to take effect, a reboot is needed. Currently there is no message displayed after
a bundle configuration change. [PR/441546]
■
On SRX5800 devices, the IOC hot swap is not supported with network processing
bundling. If an IOC that has network processing bundling configured gets
unplugged, all traffic to that network processor bundle will be lost. [PR/441961]
■
On SRX5800 devices with interfaces in a network processing bundle, the ICMP
flood or UDP flood cannot be detected at the threshold rate. However, it can be
detected at a higher rate when the per-network processor rate reaches the
threshold. [PR/442376]
■
On SRX5600 devices, equal-cost multipath (ECMP) does not work at Layer 4
when transit traffic is passed. [PR/444054]
■
163
■
On an SRX3400 device in combo mode with two SPCs and one NPC, not all
sessions are created under the stress test. [PR/450482]
■
On J Series devices, there is a drop in throughput on 64-byte packet size T3 links
when bidirectional traffic is directed. [PR/452652]
■
On SRX240 PoE and J4350 devices, the first packet on each multilink class gets
dropped on reassembly. [PR/455023]
■
On SRX5600 and SRX5800 devices, system log messages are not generated
when CPU utilization returns to normal. [PR/456304]
■
On SRX210, SRX240, and J6350 devices, the serial interface goes down for long
duration traffic when FPGA 2.3 version is loaded in the device. As a result, the
multilink goes down. This issue is not seen when downgrading the FPGA version
from 2.3 to 1.14. [PR/461471]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, in end-to-end
debugging, the cp-lbt event actions are not working. There is no change in
behavior with or without the cp-lbt event. [PR/462288]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, during end-to-end
debugging with the jexec event, packet summary trace messages have unknown
IP addresses in the packet summary field. [PR/463534]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, data path-debug rate-limit
does not work properly.When users configure a low rate limit for a large number
of trace messages, the system should suspend the trace messages after the
configured maximum is reached. The system is not suspending the trace
messages. [PR/464151]
■
GPRS tunneling protocol (GTP) application is supported on well-known ports
only. Customized application on other ports is not supported. [PR/464357]
■
On J Series devices, interfaces with different bandwidths (even if they are of
same interface type, for example, serial interfaces with different clock rates or
channelized T1/E1 interfaces with different timeslots) should not be bundled
under one ML bundle. [PR/464410]
■
SRX3400 and SRX3600 devices with one Services Processing Card and two
Network Processing Cards operating under heavy traffic produce fewer flow
sessions. [PR/478939]
■
On SRX210 devices, the MTU size is limited to 1518 bytes for the 1-port SFP
Mini-PIM. [PR/296498]
■
On SRX240 and SRX650 devices and 16-port or 24-port GPIMs, the 1G half-duplex
mode of operation is not supported in the autonegotiation mode. [PR/424008]
■
On SRX240 devices, the Mini-PIM LEDs glow red for a short duration (1 second)
when the device is powered on. [PR/429942]
■
On SRX240 devices, the file installation fails on the right USB slot when both of
the USB slots have USB storage devices attached. [PR/437563]
Hardware
164
■
■
On SRX240 devices, the combinations of Mini-PIMs cause SFP-Copper links to
go down in some instances during bootup, restarting fwdd, and restarting
chassisd. As a workaround, reboot the device and the link will be up. [PR/437788]
■
On SRX5600 devices, during a Routing Engine reboot when processes are being
shut down, a rare race condition occurs that can lead to a Routing Engine kernel
crash. [PR/488484]
■
On J Series devices, you cannot use a USB device that provides U3 features (such
as the U3 Titanium device from SanDisk Corporation) as the media device during
system boot. You must remove the U3 support before using the device as a boot
medium. For the U3 Titanium device, you can use the U3 Launchpad Removal
Tool on a Windows-based system to remove the U3 features. The tool is available
for download at http://www.sandisk.com/Retail/Default.aspx?CatID=1415. (To restore
the U3 features, use the U3 Launchpad Installer Tool accessible at
http://www.sandisk.com/Retail/Default.aspx?CatID=1411). [PR/102645]
■
On J Series devices, if the device does not have an ARP entry for an IP address,
it drops the first packet from itself to that IP address. [PR/233867]
■
On J Series devices, when you press the F10 key to save and exit from BIOS
configuration mode, the operation might not work as expected. As a workaround,
use the Save and Exit option from the Exit menu. This issue can be seen on the
J4350 and J6350 routers with BIOS Version 080011 and on the J2320 and J2350
routers with BIOS Version 080012. [PR/237721]
■
On J Series devices, the Clear NVRAM option in the BIOS configuration mode
does not work as expected. This issue can be seen on the J4350 and J6350 routers
with BIOS Version 080011 and on the J2320 and J2350 routers with BIOS Version
080012. To help mitigate this issue, note any changes you make to the BIOS
configuration so that you can revert to the default BIOS configuration as needed.
[PR/237722]
■
On J Series devices, If you enable security trace options, the log file might not
be created in the default location at /var/log/security-trace. As a workaround,
manually set the log file to the directory /var/log/security-trace. [PR/254563]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the SNMP set for the
MIB object usmUserPrivKeyChange does not work. [PR/482475]
■
On J4350 devices, SSH keys do not get regenerated when switching between an
export edition of Junos and a domestic edition of Junos, in either direction. As
a workaround, the user should regenerate their SSH keys (e.g., 'rm
/var/etc/ssh/ssh_host_*key*' and reboot) when switching between an export
edition of Junos and a domestic edition of Junos in either direction. [PR/445688]
Infrastructure
The following issues currently exist in SRX210 and SRX240 devices with Integrated
Convergence Services:
■
165
■
On SRX210 devices with Integrated Convergence Services, the call hold feature
does not work for Xlite softphones. [PR/432725]
■
At least one time slot must be configured for data for voice channels on T1 lines
to work. [PR/442932]
■
On SRX240 devices with Integrated Convergence Services, T1 configuration does
not support all the 24 time slots for voice calls. It is limited to 5 time slots or line
channels currently. [PR/442934]
■
The music-on-hold feature is not supported for SIP phones. [PR/443681]
■
The peer call server configuration for the media gateway page in J-Web does not
correctly display the port number field when TCP is used as the transport.
[PR/445734]
■
When you click the trunk-group field in J-Web, the configured trunk values are
not displayed. [PR/445765]
■
Comfort noise packets are not generated when both voice activity detection
(VAD) and comfort noise generation are enabled for an FXS station. [PR/448191]
■
In J-Web, if you do not configure the class of restriction and a station template,
you cannot configure a station. [PR/452439]
■
J-Web does not provide support for the SIP template extension inheritance feature.
[PR/455787]
■
SNMP does not provide support for survivable call server (SRX Series SCS)
statistics. [PR/456454]
■
When T1 lines for stations or trunks are configured, you might hear a momentary
burst of noise on the phone. [PR/467334]
■
You must restart the flow daemon to commit runtime T1 configuration changes.
[PR/468594]
■
The SIP-to-SIP simultaneous call capacity is limited to 10 calls. [PR/478485]
■
On J4350 and J6350 devices, the link status of the onboard Gigabit Ethernet
interfaces (ge-0/0/0 through ge-0/0/3) or the 1-port Gigabit Ethernet ePIM
interface fails when you configure these interfaces in loopback mode. [PR/72381]
■
On J Series Routers, asymmetric routing, such as tracing a route to a destination
behind J Series devices with Virtual Router Redundancy Protocol (VRRP), does
not work. [PR/237589]
■
On SRX5600 and SRX5800 devices, ping to far-end reth interfaces does not work
for different routing instances. [PR/408500]
■
On SRX240 and SRX650 devices, when you are configuring the link options on
an interface, only the following scenarios are supported:
166
■
■
Autonegotiation is enabled on both sides.
■
Autonegotiation is disabled on both sides (forced speed), and both sides are
set to the same speed and duplex.
If one side is set to autonegotiation mode and the other side is set to forced
speed, the behavior is indeterminate and not supported. [PR/423632]
■
On SRX and J Series devices, the RPM operation will not work for the probe-type
tcp-ping when the probe is configured with the option destination-interface.
[PR/424925]
■
On SRX650 devices, the following loopback features are not implemented for
T1/E1 GPIMs:
■
Line
■
FDL payload
■
Inband line
■
Inband payload
[PR/425040]
■
In J Series xDSL PIMs, mapping between IP CoS and ATM CoS is not supported.
If the user configures IP CoS in conjunction with ATM CoS, the logical interface
level shaper matching ATM CoS rate must be configured to avoid congestion
drops in SAR.
Example:
set interfaces at-5/0/0 unit 0 vci 1.110
set interfaces at-5/0/0 unit 0 shaping cbr 62400 ATM COS
set class-of-service interfaces at-5/0/0 unit 0 scheduler-map sche_map IP COS
set class-of-service interfaces at-5/0/0 unit 0 shaping-rate 62400 ADD IFL SHAPER
[PR/430756]
■
On SRX650 devices, configuring dual and quad T1/E1 framing at the chassis
level has no effect. [PR/432071]
■
On SRX240 devices, the serial interface maximum speed in extensive output is
displayed as 16384 Kbps instead of 8.0 Mbps. [PR/437530]
■
On SRX Series devices, incorrect Layer 2 circuit replication on the backup Routing
Engine might occur when you:
■
Configure nonstop active routing (NSR) and Layer 2 circuit standby
simultaneously and commit them
■
Delete the NSR configuration and then add the configuration back when
both the NSR and Layer 2 circuits are up
As a workaround:
1.
Configure the Layer 2 circuit for a nonstandby connection.
2.
Change the configuration to a standby connection.
3.
Add the NSR configuration.
[PR/440743]
■
167
168
■
■
On SRX210 Low Memory devices, the E1 interface will flap and traffic will not
pass through the interface if you restart forwarding while traffic is passing through
the interface. [PR/441312]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you configure
the SAP listen option using the protocol sap listen command in the CLI, listening
fails in both sparse and sparse-dense modes. [PR/441833]
■
On J Series devices, one member link goes down in a multilink bundle during
bidirectional traffic with Multilink Frame Relay (MLFR). [PR/445679]
■
On SRX 240 Low Memory devices and SRX 240 High Memory devices, the RPM
Server operation does not work when the probe is configured with the option
destination-interface.[PR/450266]
■
On J Series devices, the DS3 interface does not have an option to configure
multilink-frame-relay-uni-nni (MLFR). [PR/453289]
■
On SRX210 devices, the modem moves to the dial-out pending state while
connecting or disconnecting the call. [PR/454996]
■
On SRX100, SRX210, and J Series devices, out-of-band dial-in access using a
serial modem does not work. [PR/458114]
■
On SRX210 PoE devices, the G.SHDSL link does not come up with an octal port
line card of total access 1000 ADTRAN digital subscriber line access multiplexer
(DSLAM). [PR/459554]
■
On SRX100 and SRX200 devices with the VDLS2, multiple carrier transitions
(three to four) are seen during long duration traffic testing with ALU 7302 DSLAM.
There is no impact on traffic except for the packet loss after long duration traffic
testing, which is also seen in the vendor CPE. [PR/467912]
■
On SRX210 devices with VDLS2, remote end ping fails to go above the packet
size of 1480 as the packets are get dropped for the default MTU which is 1496
on an interface and the default MTU of the remote host ethernet intf is 1514.
[PR/469651]
■
On SRX210 devices, the G.SHDSL ATM logical interface goes down when ATM
CoS is enabled on the interface with OAM. As a workaround, restart the FPC to
bring up the logical interface. [PR/472198]
■
On SRX210 devices with VDLS2, ATM COS VBR related functionality cannot be
tested because of lack of support from the vendor. [PR/474297]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the show datapath-debug
counter command gives error messages from the secondary node. [PR/477017]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you change the
multicast scoping to a different multicast address, traffic other than which is
configured for multicast scoping will not be received. [PR/482957]
■
On SRX210 High Memory devices, IGMP v2 JOINS messages are dropped on an
integrated routing and bridging (IRB) interface. As a workaround, enable IGMP
snooping to use IGMP over IRB interfaces. [PR/492564]
■
On SRX100 and SRX210 devices, every time the VDSL2 PIM is restarted in the
ADSL mode, the first packet passing through the PIM will be dropped. This occurs
because there is a bug in the SAR engine, which will not set the ATM connection
until the first packet has been dropped due to no ATM connection. [PR/493099]
■
The destination and destination-profile options for address and
unnumbered-address within family inet and inet6 are allowed to be specified
within a dynamic profile but not supported. [PR/493279]
■
On SRX 210 High Memory devices, the physical interface module (PIM) shows
time in ADSL2+ ANNEX-M, even though it is configured for ANNEX-M ADSL2.
[PR/497129]
■
On SRX5600 and SRX5800 devices, load balance does not happen within the
aggregated Ethernet (ae) interface when you prefix length with /24 while
incrementing the dst ip. [PR/505840]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when the firewall and
IDP policy both enable diffServ marking with a different DSCP value for the same
traffic, the firewall DSCP value takes precedence and the traffic is marked using
the firewall DSCP value. [PR/297437]
■
On SRX5600 and SRX5800 devices, when the device is processing heavy traffic,
the show security idp status operational command might fail. As a result, IDP
flow, session, and packet statistics do not match firewall statistics. [PR/389501]
[PR/388048]
■
The SRX210 device supports only one IDP policy at any given time. When you
make changes to the IDP policy and commit, the current policy is completely
removed before the new policy becomes effective. During the update, IDP will
not inspect the traffic that is passing through the device for attacks. As a result,
there is no IDP policy enforcement. [PR/392421]
■
On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices, in J-Web
selecting Configuration>Quick Configuration>Security Policies>IDP
Policies>Security Package Update>Help brings up the IDP policy Help page
instead of the Signature update Help page. To access the corresponding Help
page, select Configuration>Quick Configuration>IDP
Policies>Signature/Policies Update and then click Help. [PR/409127]
■
On SRX3400, SRX3600, SRX5600 and SRX5800 devices, if you want to change
to dedicated mode, the configuration of the security forwarding-process
application-services maximize-idp-sessions command should be done right before
rebooting the device. This should be done to avoid recompiling IDP policies
during every commit. [PR/426575]
■
On SRX3400, SRX3600, and SRX5600 devices, when you configure IDP to run
in decoupled mode using the set security forwarding-process application-services
maximize-idp-sessions command, network address translation (NAT) information
will not be shown in the event log. [PR/445908]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if you configure a
policy containing more than 200 rules, with each rule containing the predefined
attack groups (Critical, Major, and Minor), the memory constraint of the Routing
Engine (500 MB) is reached. [PR/449731]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices in
maximize-idp-sessions mode, there is an IPC channel between two data plane
processes. The channel is responsible for transferring the "close session" message
(and other messages) from the firewall process to the IDP process. Under stress
■
169
conditions, the channel becomes full and extra messages might get lost. This
causes IDP sessions in the IDP process to hang for longer than necessary, and
they will time out eventually. [PR/458900]
■
When an SRX Series device running JUNOS Release 10.1 (Layer 2
access-integrated mode) is rolled back to the JUNOS Release 9.6 image, the DUT
comes up in JUNOS Release 9.6 with Layer 2 access-integrated mode, which was
not supported in JUNOS Release 9.6. [PR/469069]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the application-level
distributed denial-of-service (application-level DDoS) rulebase (rulebase-ddos)
does not support port mapping. If you configure an application other than default,
and if the application is from either predefined JUNOS Software applications or
a custom application that maps an application service to a nonstandard port,
application-level DDoS detection will not work. When you configure the
application setting as default, IDP uses application identification to detect
applications running on standard and nonstandard ports, hence the
application-level DDoS detection works properly. [PR/472522]
■
SRX3400, SRX3600, SRX5600, and SRX5800 devices support 4-byte autonomous
system (AS) for BGP configuration. However, the J-Flow template versions 5 and
8 do not support 4-byte AS, because these J-Flow templates have 2 bytes for the
SRC/DST AS field. [PR/416497]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, J-Flow sampling on
the virtual router interface does not show the values of autonomous system (AS)
and mask length values. The AS and mask length values of cflowd packets show
0 while sampling the packet on the virtual router interface. [PR/419563]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the LEDs on the Routing
Engine and PICs are not shown as green when they are up and online on the
J-Web Chassis View. [PR/297693]
■
On SRX Series devices, when the user adds LACP interface details, a pop-up
window appears in which there are two buttons to move the interface left and
right. The LACP page currently does not have images incorporated with these
two buttons. [PR/305885]
■
On SRX210 devices, there is no maximum length limit when the user commits
the hostname in CLI mode; however, only a maximum of 58 characters are
displayed in the J-Web System Identification panel. [PR/390887]
■
On SRX210, SRX240, and SRX650 devices, the complete contents of the ToolTips
are not displayed in the J-Web Chassis View. As a workaround, drag the Chassis
View image down to see the complete ToolTip. [PR/396016]
■
On SRX100, SRX210, SRX240, and SRX650 devices, the LED status in the Chassis
View is not in sync with the LED status on the device. [PR/397392]
■
On SRX Series devices, when you right-click Configure Interface on an interface
in the J-Web Chassis View, the Configure>Interfaces page for all interfaces is
displayed instead of the configuration page for the selected interface. [PR/405392]
J-Flow
J-Web
170
■
■
On SRX210 Low Memory devices, in the rear view of the Chassis viewer image,
the image of ExpressCard remains the same whether a 3G card is present or
not. [PR/407916]
■
On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices, selecting
Configure>Security>Policy>IDP Policies>Security Package Update>Help
in the J-Web user interface brings up the IDP policy Help page instead of the
Signature update Help page. To access the corresponding Help page, select
Configure>IDP>Signature Update and then click Help. [PR/409127]
■
On SRX Series devices, the CLI Terminal feature does not work in J-Web over
IPv6. [PR/409939]
■
On SRX210 High Memory, SRX240 PoE, and J Series devices, IDP custom attacks
and dynamic attack groups cannot be configured using J-Web. [PR/416885]
■
On J2350, J4350, and J6350 devices, users cannot configure firewall filters using
J-Web. The Firewall Filters menu was removed because it was not functioning
properly. [PR/422898]
■
On SRX210, SRX240, J2350, J4350, and J6350 devices, when J-Web users select
the tabs on the bottom-left menu, the corresponding screen is not displayed
fully, so users must scroll the page to see all the content. This issue occurs when
the computer is set to a low resolution. As a workaround, set the computer
resolution to 1280 x 1024. [PR/423555]
■
On SRX Series and J Series devices, users cannot differentiate between Active
and Inactive configurations on the System Identity, Management Access, User
Management, and Date & Time pages. [PR/433353]
■
On SRX210 device, in Chassis View, right-clicking any port and then clicking
Configure Port takes the user to the Link aggregation page. [PR/433623]
■
On SRX100 devices, in J-Web users can configure the scheduler without entering
any stop date. The device submits the scheduler successfully, but the submitted
value is not displayed on the screen or saved in the device. [PR/439636]
■
On SRX100, SRX210, SRX240, and SRX650 devices, in J-Web the associated
dscp and dscpv6 classifiers for a logical interface might not be mapped properly
when the user edits the classifiers of a logical interface. This can affect the Delete
functionality as well. [PR/455670]
■
On SRX Series and J Series devices, when J-Web is used to configure a VLAN,
the option to add an IPv6 address appears. Only IPv4 addresses are supported.
[PR/459530]
■
On SRX100, SRX210, SRX240, SRX650, and J Series devices, in J-Web, the
options Input filter and Output Filter are displayed in VLAN configuration page.
This feature is not supported, and the user cannot obtain or configure any value
under these filter options. [PR/460244]
■
On J2350, J4350, J6350, SRX100 Low Memory and High Memory, SRX210 Low
Memory and High Memory, SRX210 PoE, SRX240 Low Memory and High
Memory, and SRX 650 devices, in the J-Web interface, in the OSPF Global Settings
table in the OSPF Configuration page, the Global Information table in the BGP
Configuration page, or the Add Interface window in the LACP Configuration page,
if you try to change the position of columns using the drag-and-drop method,
only the column header moves to the new position instead of the entire column.
[PR/465030]
■
171
■
On SRX100, SRX210, SRX240, SRX650, and J Series devices, when you have a
large number of static routes configured, and if you have navigated to pages
other than to page 1 in the Route Information table in the J-Web interface
(Monitor>Routing>Route Information), changing the Route Table to query other
routes refreshes the page but does not return you to page 1. For example, if you
run the query from page 3 and the new query returns very few results, the Route
Information table continues to display page 3 with no results. As a workaround,
navigate to page 1 manually to view the results. [PR/476338]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the J-Web interface
Static Routing page might not display details on entries registered in the routing
table. [PR/483885]
■
On SRX210 Low Memory, SRX210 High Memory, and SRX210 PoE devices, in
the J-Web interface, Configuration>Routing>Static Routing does not display
the IPv4 static route configured in rib inet.0. [PR/487597]
■
On SRX100 (low memory and high memory), SRX210 (low memory, high
memory, and PoE), SRX240 (low memory and high memory), SRX650, J2350,
J4350, and J6350 devices, CoS feature commits occur without validation
messages, even if you have not made any changes. [PR/495603]
■
On SRX100, SRX210, SRX240, and SRX650 devices, J-web shows switching
pages in HA mode but switching is not supported in HA mode.
172
■
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the queue statistics
are not correct after deletion and re-creation of a logical interface (IFL) or creation
of a new IFL. IFL statistics are not cleared for 15 minutes after chassis-control is
restarted. [PR/417947]
■
On SRX5600 devices, when the system is in an unstable state (for example SPU
reboot), NFS might generate residual.nfs files under the /var/tmp directory,
which can occupy the disk space for a very long time. As a workaround, run the
request sys storage cleanup command to clean up when the system has low disk
space. [PR/420553]
■
On SRX650 devices, the kernel crashes when the link goes down during TFTP
installation of the srxsme image. [PR/425419]
■
On SRX650 devices, continuous messages are displayed from syslogd when ports
are in switching mode. [PR/426815]
■
On SRX240 devices, if a timeout occurs during the TFTP installation, booting the
existing kernel using the boot command might crash the kernel. As a workaround,
use the reboot command from the loader prompt. [PR/431955]
■
On SRX240 devices, when you configure the system log hostname as 1 or 2, the
device goes to the shell prompt. [PR/435570]
■
On SRX240 devices, the Scheduler Oinker messages are seen on the console at
various instances with various Mini-PIM combinations. These messages are seen
during bootup, restarting fwdd, restarting chassisd, and configuration commits.
[PR/437553]
■
On SRX5800 devices, rebooting is required for any NP bundle configuration
change to take effect. Currently there is no notification displayed after the bundle
configuration change to notify that a reboot is required for the change to take
effect. [PR/441546]
■
On SRX5600 and SRX5800 devices, data path debug trace messages are getting
dropped at above 1000 packets per second (pps). [PR/446098]
■
On J2350, J4350, and J6350 devices, extended bit error rate test (BERT) takes
an additional 3 hours to complete even though a BERT-period of 24 hours is set.
[PR/447636]
■
On J4350 devices, when you place internal calls, interface-based persistent NAT
displays only one active hairpinning session instead of two, even after the call
is established. [PR/504932]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, NAT behavior in event
logs is incorrect for JUNOS Release 10.1. Because of a bug, the log output shows
both source and destination IP from the client/server instead of only the IP
address with NAT. The output incorrectly shows 4.0.0.0->5.0.0.1.
The correct output should be as follows:
■
For destination NAT, the IP address in the log should be 0.0.0.0->5.0.0.1.
■
For source NAT, the ip address displayed in log should be 4.0.0.0->0.0.0.0.
[PR:505454 / PR:562620]
Power over Ethernet (PoE)
■
On SRX240 and SRX210 devices, the output of the PoE operational commands
takes roughly 20 seconds to reflect a new configuration or a change in status of
the ports. [PR/419920]
■
On SRX210 and SRX240 devices, the deactivate poe interface all command does
not deactivate the PoE ports. Instead, the PoE feature can be turned off by using
the disable configuration option. Otherwise, the device must be rebooted for the
deactivate setting to take effect. [PR/426772]
■
On SRX210 and SRX240 devices, reset of the PoE controller fails when the restart
chassis-control command is issued and also after system reboot. PoE functionality
is not negatively impacted by this failure. [PR/441798]
■
On SRX210 PoE devices managing AX411 Access Points, the devices might not
be able to synchronize time with the configured NTP Server. [PR/460111]
■
On SRX210 devices, the fourth access point connected to the services gateway
fails to boot with the default Power over Ethernet (PoE) configuration. As a
workaround, configure all the PoE ports to a maximum power of 12.4 watts.
Use the following command to configure the ports:
root#set poe interface all maximum-power 12.4
[PR/465307]
■
On SRX100, SRX210, SRX240, and SRX650 devices, with factory default
configurations the device is not able to manage the AX411 Acess Point. This
might be due to the DHCP default gateway not being set. [PR/468090]
■
173
■
On SRX210 PoE devices, high latencies might be observed for the Internet Control
Message Protocol (ICMP) pings between two wireless clients when 32 virtual
access points (VAPs) are configured. [PR/472131]
■
On SRX210 PoE devices, when AX411 Access Points managed by the SRX Series
devices reboot, the configuration might not be reflected onto the AX411 Access
Points. As a result, the Ax411 Access Points retain the factory default
configuration. [PR/476850]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the egress filter-based
forwarding (FBF) feature is not supported. [PR/396849]
■
On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices in a chassis
cluster, if the Infranet Controller auth table mapping action is configured as
provision auth table as needed, UAC terminates the existing sessions after Routing
Engine failover. You might have to initiate new sessions. Existing sessions will
not get affected after Routing Engine failover if the Infranet Controller auth table
mapping action is configured as always provision auth table. [PR/416843]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, you should not
configure rulebase-DDoS rules that have two different application-DDoS objects
to run on one destination service because the traffic destined to one application
server can encounter more than one rule. Essentially, for each protected
application server, you have to configure a single application-level DDoS rule.
[PR/467326]
Security
Unified Access Control (UAC)
■
On J Series devices, MAC address-based authentication does not work when the
router is configured as a UAC Layer 2 Enforcer. [PR/431595]
174
■
■
On SRX210 High Memory devices, content filtering provides the ability to block
protocol commands. In some cases, blocking these commands interferes with
protocol continuity, causing the session to hang. For instance, blocking the FETCH
command for the IMAP protocol causes the client to hang without receiving any
response. [PR/303584]
■
On SRX210 High Memory devices, when the content filtering message type is
set to protocol-only, customized messages appear in the log file. [PR/403602]
■
On SRX210 High Memory devices, the express antivirus feature does not send
a replacement block message for HTTP upload (POST) transactions if the current
antivirus status is engine-not-ready and the fallback setting for this state is block.
An empty file is generated on the HTTP server without any block message
contained within it. [PR/412632]
■
On SRX240, SRX650, and J Series devices, Outlook Express is sending infected
mail (with an EICAR test file) to the mail server (directly, not through DUT).
Eudora 7 uses the IMAP protocol to download this mail (through DUT). Mail
retrieval is slow, and the EICAR test file is not detected. [PR/424797]
■
On SRX650 devices operating under stress conditions, the UTM subsystem file
partition might fill up faster than UTM can process and clean up existing
temporary files. In that case, the user might see error messages. As a workaround,
reboot the system [PR/435124]
■
On SRX240 High Memory devices, FTP download for>4 MB files does not work
in a two-device topology. [PR/435366]
■
On SRX210, SRX240, and SRX650 devices, the Websense server stops taking
new connections after HTTP stress. All new sessions get blocked. As a
workaround, reboot the Websense server. [PR/435425]
■
On SRX240 devices, if the device is under UTM stress traffic for several hours,
users might get the following error while using a UTM command:
the utmd subsystem is not responding to management requests.
As a workaround, restart the utmd process. [PR/436029]
USB Modem
■
On SRX210 High Memory devices and J6350 devices, packet loss is seen during
rapid ping operations between the dialer interfaces when packet size is more
than 512 Kbps. [PR/484507]
■
On SRX210 High Memory devices, the modem interface can handle bidirectional
traffic of up to 19 Kbps. During oversubscription of 20-Kbps or more traffic, the
keepalive packets are not exchanged and the interface goes down. [PR/487258]
■
On SRX210 High Memory devices, IPv6 is not supported on dialer interfaces
with a USB modem. [PR/489960]
■
On SRX210 High Memory devices, http traffic is very slow through the umd0
interface. [PR/489961]
■
On SRX210 High Memory devices, on multiple resets of the umd0 interface, the
umd0 interface keeps flapping if the d10 (dialer) interface on either the dial-in
or dial-out interface goes down because no keepalive packets are exchanged. As
a workaround, increase the ATS0 value to 4 or greater. [PR/492970]
■
On SRX210 High Memory devices and J6350 devices, the D10 link flaps during
long-duration traffic of 15 Kbps and also when packet size is 256 Kbps or more.
[PR/493943]
■
On SRX650 devices, when VLAN tagging is configured and traffic is sent, the
output of show interfaces ge-0/0/1 media detail VLAN tagged frame count is not
shown. [PR/397849]
■
On SRX240, SRX650, J4350, and J6350 devices, tagged frames on an access
port with the same VLAN tag are not dropped. [PR/414856]
■
On SRX100, SRX210, and SRX240 devices, the packets are not being sent out
of the physical interface when the VLAN ID associated with the VLAN interface
is changed. As a workaround, you need to clear the ARP. [PR/438151]
■
175
■
On SRX100 Low Memory, SRX100 High Memory, SRX210 Low Memory, SRX210
High Memory, SRX240 High Memory, and SRX650 devices, the Link Layer
Discovery Protocol (LLDP) organization-specific Type Length Value (TLV), medium
attachment unit (MAU) information always propagates as "Unknown".
[PR/480361]
■
On SRX100 High Memory devices and SRX210 Low Memory devices, dot1x
unauthenticated ports accept Link Layer Discovery Protocol (LLDP) protocol data
units (PDUs) from neighbors. [PR/485845]
■
For SRX210 High Memory devices, during configuration of access and trunk
ports, the individual VLANs from the vlan-range are not listed. [PR/489872]
■
On SRX5600 devices, the shared IKE limit for IKE users is not currently enforced.
More users than are specified in the shared IKE limit are able to establish
IKE/IPsec tunnels. [PR/288551]
■
On SRX210 and SRX240 devices, concurrent login to the device from a different
management systems (for example, laptop or computers) are not supported.
The first user session will get disconnected when a second user session is started
from a different management system. Also, the status in the first user system is
displayed incorrectly as “Connected”. [PR/434447]
■
On SRX Series and J Series devices, the site-to-site policy-based VPNs in a three
or more zone scenario will not work if the policies match the address “any”,
instead of specific addresses, and all cross-zone traffic policies are pointing to
the single site-to-site VPN tunnel. As a workaround, configure address books in
different zones to match the source and destination, and use the address book
name in the policy to match the source and destination. [PR/441967]
■
On SRX210, SRX240 and SRX650 devices, J-Web online Help displays the list
of all the countries and is not based on the regulatory domain within which the
access point is deployed. [PR/469941]
VPNs
WLAN
WXC Integrated Services Module
■
When two J Series devices with WXC Integrated Services Modules (WXC ISM
200s) installed are configured as peers, traceroute fails if redirect-wx is configured
on both peers. [PR/227958]
■
On J6350 devices, JUNOS Software does not support policy-based VPN with WXC
Integrated Services Modules (WXC ISM 200s). [PR/281822]
Resolved Issues in JUNOS Release 10.1 for SRX Series Services Gateways
and J Series Services Routers
The following are the issues that have been resolved since Junos OS Release 10.1 R3
for Juniper Networks SRX Series Services Gateways and J Series Services Routers.
The identifier following the descriptions is the tracking number in our bug database.
176
■
Application Identification (AI)
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when doing Application
Identification signature database upgrade/downgrade, either through CLI
command request service application-identification download or request security
idp security-package install, the system was merging the new database with the
old one, potentially causing problems with port-mapping fields that were required
to be unique. [PR/521482: This issue has been resolved.]
■
On SRX3400 devices, the FTP ALG crashed when the
flow_tcp_proxy_stack_send_data2 command was used. [PR/ 525607: This issue
has been resolved.]
■
On SRX650 devices, the SQL ALG did not function when data was transmitted
over the control session. [PR/524444 This issue has been resolved.]
■
On SRX650 devices, Dot1p bits of Layer 2 packet traffic across XPIMs changed.
■
On SRX5800 devices, incorrect high jitter messages were displayed. [PR/526975:
■
On SRX650 devices, SNMP walk to the device would randomly timeout.
■
On J6350 devices in chassis cluster mode, self traffic such as OSPF did not work
correctly when a node of the cluster was rebooted. [PR/528812: This issue has
been resolved.]
■
On SRX650 devices, SNMP MIB OID (.1.3.6.1.4.1.2636.1.1.1.2.40) showed fan
instead of fan-tray. [PR/533112: This issue has been resolved.]
■
On SRX3400 and SRX3600 devices, when you did RG0 failover, the CPP status
LED was set to blinking green and failed to remain steadily on. [PR/539921: This
Chassis Cluster
■
177
Class of Service
■
On SRX650 devices, show class-of-service virtual-channel-group did not show the
configured shaping rate. [PR/536778: This issue has been resolved.]
■
On SRX650 devices, the uplinks to the CPU could be exhausted and the system
could be limited to 2.5 GB throughput traffic when the device was using similar
kinds of source MAC addresses. [PR/428526: This issue has been resolved.]
■
On SRX240 PoE and J Series devices, packet drops were seen on the lsq interface
when transit traffic with a frame length of 128 bytes was sent. [PR/455714: This
■
On SRX3600 devices, when you enabled source-ip-based session limiting, the
destination-ip-based session limiting was also enabled by default. [PR/501666:
■
On SRX650 devices, because of a memory corruption issue, the flow daemon
generated a core file, and the device stopped passing traffic. [PR/534887: This
■
On SRX3400 devices, IPsec proxy ID reverted to 0.0.0.0 when IKE or IPSec
proposals were changed. [PR/536354: This issue has been resolved.]
■
On SRX240 High Memory devices, under continuous high HTTP traffic load, the
forwarding daemon generated a core. This core file was seen after more than
24 hours of continuous high load. [PR/538383: This issue has been resolved.]
■
On SRX5800 devices, when multiple fragment packets were processed at the
same time, the processing threads locked each other, triggering restart of
forwarding. [PR/539296: This issue has been resolved.]
■
On SRX650 devices, packets traveling over the HA fabric link contained an invalid
IP header checksum, and some switches dropped these packets. [PR/541245:
■
On SRX3600 devices, a crash occurred there was a crash when very high rates
of GTP packets were handled. [PR/544448: This issue has been resolved.]
■
On SRX3600 devices, when GPRS inspection was enabled, it failed to create a
GTP tunnel. [PR/545354: This issue has been resolved.]
■
On SRX5800 devices, under certain conditions, the session ager got stuck causing
momentary traffic outage. [PR/545948: This issue has been resolved.]
■
On J4350 devices, multicast traffic was not received when the source and the
receiver were connected to the same PE routers. [PR/429130: This issue has
been resolved.]
■
On J Series devices, tail drops were seen on a bundle for traffic with a bigger
packet size and smaller fragmentation threshold. [PR/461417: This issue has
been resolved.]
Flow and Processing
178
■
■
On J2350 devices, the T1 interface dropped after 49 days and never recovered.
■
On SRX5800 devices, the clock on SPCs drifted a few seconds from the clock
on the routing engine, even when NTP was used. When this deviation was
detected, it was corrected and a “time reset” message was logged. [PR/537543:
■
On SRX3400 and SRX3600 devices, the logging rate was slightly less in SPUs
operating in combo mode as compared to SPUs operating in non-combo mode.
■
On SRX650 devices, IDP detector and IDP attack database update caused chassis
cluster instability, and the secondary node went to a disabled state. [PR/523494:
■
On SRX650 devices, the source-address option for J-Flow did not remain
persistent. [PR/ 530620: This issue has been resolved.]
■
On SRX100, SRX210, SRX240, SRX650, and J Series devices, in the J-Web
interface, the Traceoptions tab in the Edit Global Settings window of the OSPF
Configuration page (Configuration>Routing>OSPF Configuration) did not display
the available flags (tracing parameters). [PR/475313: This issue has been
resolved.]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, CPU utilization on the
J-Web dashboard did not match CPU utilization of the routing engine. [PR/527344:
■
On SRX5600 and SRX5800 devices, in certain ISIS configurations, rpd crashed
when ISIS inserted routes into the routing table. [PR/531292: This issue has been
resolved.]
■
On SRX Series devices, when you authenticated using TACACS+ through J-Web,
J-Web waited for the password prompt to be ’Password’ and failed to authenticate
if prompt sent was ’password’. [PR/540217: This issue has been resolved.]
J-Flow
J-Web
■
On SRX Series and J Series devices with session-init and session-close enabled,
you should not clear sessions manually when too many sessions were in status
"used". [PR/445730: This issue has been resolved.]
■
On SRX5800 devices, when the local-identity hostname configuration was
changed, these changes were not propagated to KMD, and the proxy IDs also
were mismatched. [PR/540667: This issue has been resolved.]
■
179
■
On SRX240 High Memory devices in a chassis cluster, the secondary node could
go to DB> mode when there were many policies configured and TCP, UDP, and
ICMP traffic matched the policies. [PR/493095: This issue has been resolved.]
■
On SRX240 High Memory devices, the device stopped sending logs to NSM after
a few days. [PR/517969: This issue has been resolved.]
■
On SRX5600 and SRX5800 devices, the NAT hit counter was not increased for
overflow NAT pools. [PR/534578: This issue has been resolved.]
■
On SRX100 and SRX210 High Memory devices, h323/h245 OLC could not pass
whether src nat or dst nat was used. [PR/538764: This issue has been resolved.]
■
On SRX100 High Memory devices, for nat source with port no-translation the
configured source-pool IP addresses were divided into half and they were
exclusively used on each node. However, when multiple groups of source-pool
IP addresses were configured, the half-divided logic did not work properly, and
it resulted in an unexpectedly insufficient IP address (from source-pool) for a
node. [PR/538769: This issue has been resolved.]
■
On SRX210 PoE devices managing AX411 Access Points, traffic of 64 bytes at
speeds more than 45 megabits per second (Mbps) resulted in loss of keepalives
and reboot of the AX411 Access Point. [PR/471357: This issue has been resolved.]
■
On SRX3600 devices, screen names with 24 characters did not function properly.
Power over Ethernet (PoE)
Screens
180
■
■
On SRX210 High Memory devices, the forwarding daemon ran out of memory
with large UTM configurations such as 30,000 objects configured including 15,000
URLs in the blacklist. As a result, the forwarding daemon generated a core file
and stopped forwarding. [PR/518490: This issue has been resolved.]
■
On SRX210 High Memory devices, problems occurred because of an invalid
assert on the sizes of two data structures. [PR/518511: This issue has been
resolved]
USB Modem
■
On SRX210, SRX100, SRX240, and SRX650 devices, when you restarted fwdd
at the dial-out side, the umd interface went down and the call never got
connected. [PR/480206: This issue has been resolved.]
■
On SRX240 Low Memory and High Memory devices, and SRX650 devices,
sometimes the VLAN entry was not created while MSTP regression was running.
■
On SRX5800 devices, when a large number of zones used the same screen,
some zones were not able to pass traffic. [PR/526082: This issue has been
resolved.]
■
On SRX100, SRX210, SRX220, SRX240, SRX650 and all J Series devices, in a
VPLS environment, CE learnt same MAC from multiple CEs that caused traffic
disruption. [[PR/531846: This issue has been resolved.]
■
On SRX210 High Memory devices, native-vlan-id was configured only when either
flexible-vlan-tagging mode or interface-mode trunk was configured. [PR/536585:
■
On SRX240 devices with voice capability, Layer 3 traffic with VLAN ID 4093 was
not allowed. [PR/539580: This issue has been resolved.]
■
On SRX210 Low Memory devices, IKE negotiation failed when an IKE-ID longer
than 31 bytes was configured. [PR/523796: This issue has been resolved.]
■
On SRX3000 and SRX5000 line devices, in a route-based VPN, VPN traffic failed
to pass when the remote peer IP address changed. [PR/529018: This issue has
been resolved.]
■
On SRX3600 devices, when you used vpn-monitor for route-based VPNs, the
ST0.x tunnel was not disabled when the VPN was down. [PR/552369: This issue
has been resolved.]
■
On SRX210 PoE devices, when you swapped an already managed AP with a new
one and changed the WLAN access-point configuration to reflect the MAC address
of the new access point, it resulted in the new access point not being managed.
■
■
VPNs
WLAN
Related Topics
■
181
■
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services
This section lists outstanding issues with the documentation.
■
The following section has been removed from the JUNOS Software Security
Configuration Guide to reflect RPC ALG data structure cleanup: “Display the Sun
RPC Port Mapping Table.”
■
The “Verifying the RPC ALG Tables” section of the JUNOS Software Security
Configuration Guide has been renamed to “Verifying the Microsoft RPC ALG
Tables” to reflect RPC ALG data structure cleanup.
■
ALG configuration examples in the JUNOS Software Security Configuration Guide
incorrectly show policy-based NAT configurations. NAT configurations are now
rule-based.
■
The JUNOS Software Security Configuration Guide incorrectly states that ALGs are
not supported in transparent mode on SRX3400, SRX3600, SRX5600, and
SRX5800 devices. The FTP, TFTP, RTSP, and DNS ALGs are supported in
transparent mode on those devices. Other ALGs are not.
■
In the section "Example: Using NAT and the H.323 ALG to Enable Incoming Calls
(CLI)" in the Junos OS Security Configuration Guide, the following text is incorrect:
user@host# set security policy from-zone zone1 to-zone zone2 policy
zone1_to_zone2 then permit source-nat pool p1
The correct text is as follows:
user@host# set security policy from-zone zone1 to-zone zone2 policy
zone1_to_zone2 then permit
Attack Detection and Prevention
The default parameters documented in the firewall/NAT screen configuration options
table in the JUNOS Software Security Configuration Guide and the J-Web online Help
do not match the default parameters in the CLI. The correct default parameters are:
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
}
[edit security screen ids-option untrust-screen]
182
Routers
■
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
CLI Reference
The “Services Configuration Statement Hierarchy” section in the JUNOS® Software
CLI Reference refers to the JUNOS Services Interfaces Configuration Guide, which has
the following error in the sections “Data Size” and “Configuring the Probe”:
■
The minimum data size required by the UDP timestamp probe is identified as 44
bytes. This is incorrect: the minimum data size required by the UDP timestamp probe
is 52 bytes.
■
The following sections have been removed from the JUNOS Software CLI Reference
to reflect RPC ALG data structure cleanup:
■
show security alg sunrpc portmap
■
clear security alg sunrpc portmap
■
In the “Example: Configuring an IPsec Phase 2 Proposal (CLI)” section of the
Junos OS Security Configuration Guide, the second paragraph of the first example
states that the SA, “. . . terminates after 1800 KB of data pass through it.” It
should instead say, “. . . after 1800 seconds.” The same error is present in the
“Example: Configuring an IPsec Phase 2 Proposal (J-Web Point and Click CLI)”
section.
■
In the “Example: Accommodating End-to-End TCP Communication for J Series
Services Routers” section of the Junos OS Security Configuration Guide, one CLI
command given in the example in both the CLI Quick Configuration and
Step-by-Step Procedure is incomplete. The set security flow tcp-mss all-tcp
command must be followed by the keyword mss value. Therefore, the CLI
example in both cases should read set security flow tcp-mss all-tcp mss 1400.
The same error is present in the “Example: Setting the Maximum Segment Size
for All TCP Sessions for SRX Series Services Gateways (CLI)” section.
■
The JUNOS Software Administration Guide incorrectly states that JUNOS Software
supports a 256-MB CompactFlash card size. JUNOS Software supports only
512-MB and 1024-MB CompactFlash card sizes.
■
The Junos OS CLI Reference and Junos OS Security Configuration Guide state that
the following aggressive aging statements are supported on all SRX Series devices
when in fact they are not supported on SRX3400, SRX3600, SRX5600, and
SRX5800 devices:
CompactFlash Card Support
Flow and Processing
■
[edit security flow aging early-ageout]
■
[edit security flow aging high-watermark]
■
[edit security flow aging low-watermark
Routers
■
183
■
The “Understanding Selective Stateless Packet-Based Services” section in the
JUNOS Software Administration Guide states: “The following security features are
not supported with selective stateless packet-based services—stateful firewall
NAT, IPsec VPN, DOS screens, J-flow traffic analysis, WXC integrated security
module, security policies, zones, attack detection and prevention, PKI, ALGs,
and chassis cluster.” This statement is not correct. With selective packet-mode,
traffic that is sent through flow is able to use all of those services, even in a single
VR scenario.
■
Information about secure context and router context has been removed from
the JUNOS Software Administration Guide and the JUNOS Software Security
Configuration Guide. If you want to use both flow-based and packet-based
forwarding simultaneously on a system, use the selective stateless packet-based
services feature instead. For more information, see “Configuring Selective
Stateless Packet-Based Services” in the JUNOS Software Administration Guide.
■
For a J Series Services Router, if the buffer size percentage is set to zero for T1
interfaces, traffic does not pass.
■
On SRX100 devices, the Alarm LED is off, indicating that the device is starting
up.
Hardware Documentation
Note that when the device is on, if the Alarm LED is off, it indicates that no
alarms are present on the device.
■
The “Configuring Basic Settings for the SRX100 Services Gateway with a
Configuration Editor” section in the SRX100 Services Gateway Hardware Guide
contains the following inaccuracies:
■
The documentation incorrectly implies that the management port and
loopback address must be defined for the device.
■
The documentation should indicate that the SSH remote access can be
enabled.
■
The documentation indicates the CLI command set services ssh, which is
incorrect. The correct command is set system services ssh.
■
The J-Web Initial Set Up screenshot shown in the SRX210 Services Gateway Getting
Started Guide and the SRX240 Services Gateway Getting Started Guide contains
the following inaccuracies: The J-Web screenshot incorrectly shows the “Enable
DHCP on ge-0/0/0.0” check box as disabled in factory default settings. The J-Web
screenshot should indicate the “Enable DHCP on ge-0/0/0.0” check box as enabled
in factory default settings.
■
The show chassis environment cb 0 command mentioned in the SRX5600 Services
Gateway Hardware Guide is modified to show chassis environment cb node 0.
■
The Power over Ethernet section in the SRX210 Services Gateway Hardware Guide
incorrectly states that PoE+ support (IEEE 802.3at standard) is available on all
models of SRX210 devices.
The guide should state that
184
Routers
■
■
■
PoE (IEEE 802.3 af) support is enabled only on the SRX210 Services Gateway
PoE model.
■
PoE+ (IEEE802.3 at) support is enabled only on the SRX210 Services
Gateway with Integrated Convergence Services model.
The DOCSIS Mini-Physical Interface Module chapter in the SRX Series Services
Gateways for the Branch Physical Interface Modules Hardware Guide erroneously
states that EuroDOCSIS 3.0 and DOCSIS J (Japan) models of the DOCSIS Mini-PIM
are supported. The guide should state that only DOCSIS 3.0 US model of DOCSIS
Mini-PIM is supported.
Installing Software Packages
■
The current SRX210 documentation does not include the following information:
On SRX210 devices, the /var hierarchy is hosted in a separate partition (instead
of the root partition). If JUNOS Software installation fails as a result of insufficient
space:
■
1.
Use the request system storage cleanup command to delete temporary files.
2.
Delete any user-created files in both the root partition and under the /var
hierarchy.
The “Installing Software using the TFTPBOOT Method on the SRX100, SRX210,
and SRX650 Services Gateway” section in the JUNOS Software Administration
Guide contains the following inaccuracies:
■
The documentation incorrectly implies that the TFTPBOOT method requires
a separate secondary device to retrieve software from the TFTP server.
■
The documentation should indicate that the TFTPBOOT method does not
work reliably over slow speeds or large latency networks.
■
The documentation indicates that before starting the installation, you only
need to configure the gateway IP, device IP address, and device IP netmask
manually in some cases, when actually you need to configure them manually
in all cases.
■
The documentation should indicate that on the SRX100, SRX210, and SRX240
devices, only the ge-0/0/0 port supports TFTP in uboot, and on the SRX650
device, all front-end ports support TFTP in uboot.
■
Step 2 of the “Installing JUNOS Software Using TFTPBOOT” instructions
should mention that the URL path is relative to the TFTP server’s TFTP root
directory. The instructions should also mention that you should store the
JUNOS Software image file in the TFTP server’s TFTP root directory.
■
The documentation should indicate that the TFTPBOOT method installs
software on the internal flash on SRX100, SRX210, and SRX240 devices,
whereas on SRX650 devices, the TFTP method can install software on the
internal or external CompactFlash card.
Routers
■
185
■
The JUNOS Software Administration Guide is missing the following information
about installing software using USB on SRX100, SRX210, SRX240, and SRX650
devices:
You can install or recover the JUNOS Software using USB on SRX100, SRX210,
SRX240, and SRX650 devices. During the installation process, the installation
package from the USB is installed on the specified boot media.
Before you begin the installation, ensure the following prerequisites are met:
■
U-boot and Loader are up and running on the device.
■
USB is available with the JUNOS Software package to be installed on the
device.
To install the software image on the specified boot media:
1.
Go to the Loader prompt. For more information on accessing the Loader
prompt, see “Accessing the Loader Prompt” on page 260 of the JUNOS
Software Administration Guide.
2.
Enter the following command at the Loader prompt:
Loader>install URL
Where URL is file:///package
Example:
Loader>install file:///junos-srxsme-9.4-200811.0-domestic.tgz
When you are done, the file reads the package from the USB and installs the
software package. After the software installation is complete, the device boots
from the specified boot media.
NOTE: USB to USB installation is not supported. Also, on SRX100, SRX210, and
SRX240 devices, the software image will always be installed on NAND flash, but on
SRX650 devices, the software image can be installed either on the internal or external
CompactFlash card based on the boot media specified.
186
Routers
■
■
The JUNOS Software Integrated Convergence Services Configuration and
Administration Guide does not include show commands for JUNOS Release 10.1.
■
On SRX210 and SRX240 devices with Integrated Convergence Services, the
Transport Layer Security (TLS) option for the SIP protocol transport is not
supported in JUNOS Release 10.1. However, it is documented in the Integrated
Convergence Services entries of the JUNOS Software CLI Reference.
■
The JUNOS Software CLI Reference contains Integrated Convergence Services
statement entries for the music-on-hold feature, which is not supported for JUNOS
release 10.1.
■
In the JUNOS Interfaces and Routing Configuration Guide, the “Configuring VDSL2
Interface” chapter incorrectly states that J-Web support for configuring the VDSL2
interface is not available in JUNOS Release 10.1. The J-Web support is available
for VDSL2 interfaces in JUNOS Release 10.1.
■
In the JUNOS Interfaces and Routing Configuration Guide, the “Configuring G.SHDSL
Interface” chapter incorrectly states that J-Web support for configuring the
G.SHDSL Interface is not available in JUNOS Release 10.1. The J-Web support is
available for G.SHDSL interfaces in JUNOS Release 10.1.
■
The JUNOS Interfaces and Routing Configuration Guide is missing the following
information about Q-in-Q VLAN tagging:
When Q-in-Q tunneling is configured for a service provider’s VLAN, all routing
engine packets, including packets from the routed VLAN interface, that are
transmitted from the customer-facing access port of that VLAN will always be
untagged
■
The “Transmit Rate” section of the Class of Service Overview chapter incorrectly
states that SRX Series devices do not support an exact value transmit rate. Only
the SRX3400, SRX3600, SRX5600, and SRX5800 Series devices do not support
an exact value transmit rate.
■
The JUNOS Software Security Configuration Guide does not state that custom
attacks and custom attack groups in IDP policies can now be configured and
installed even when a valid license and signature database are not installed on
the device.
■
The JUNOS Software CLI Reference is missing information about the following
IDP policy template commands:
■
Use this command to display the download status of a policy template:
user@host>request security idp security-package download status
Done; Successfully downloaded from
(https://devdb.secteam.juniper.net/xmlexport.cgi).
■
Use this command to display the installation status of a policy template:
user@host>request security idp security-package install status
Done;policy-templates has been successfully updated into internal
repository
(=>/var/db/scripts/commit/templates.xsl)!
■
The ip-action definition on SRX3400, SRX3600, SRX5600, and SRX5800 in the
JUNOS Software Security Configuration Guide on page 504 Table 73 is incorrect.
The correct definition should be as follows: Enables you to implicitly block a
source address to protect the network from future intrusions while permitting
legitimate traffic. You can configure one of the following IP action options in
application-level DDoS: ip-block, ip-close, and ip-notify.
Routers
■
187
■
The exclude-context-values option in the JUNOS Software Security Configuration
Guide on page 810 Table 101 is missing. The definition for exclude-context-values
should be as follows: Configure a list of common context value patterns that
should be excluded from application-level DDoS detection. For example, if you
have a Web server that receives a high number of HTTP requests on home/landing
page, you can exclude it from application-level DDoS detection.
■
The JUNOS Software CLI Reference and the JUNOS Security Configuration Guide
states that the maximum acceptable range for the timeout (IDP Policy) is 65,535
seconds, whereas the ip-action timeout range has been modified to 0-64800
seconds.
■
The JUNOS Software CLI Reference and the JUNOS Security Configuration Guide
are missing information about the new CLI option download-timeout, which has
been introduced to set security idp security-package automatic download-timeout
< value >, to configure the download timeout in minutes. The default value for
download-timeout is one minute. If download is completed before the
download-timeout, signature is automatically updated after the download. If the
download takes longer than download-timeout, auto signature update is aborted.
Syntax:
user@host# set security idp security-package automatic download-timeout ?
Possible completions: < download-timeout >
Maximum time for download to complete (1 - 60 minutes)
[edit]
user@host# set security idp security-package automatic download-timeout
Range: 1 – 60 minutes
Default: 1 minute
■
The JUNOS Software CLI Reference incorrectly states the show security idp status
and clear security idp status logs, whereas the logs should be as follows:
■
Correct show security idp status log
user@host> show security idp status
State of IDP: 2-default, Up since: 2010-02-04 13:37:16 UTC (17:15:02 ago)
Packets/second: 5 Peak: 11 @ 2010-02-05 06:51:58 UTC
KBits/second : 2 Peak: 5 @ 2010-02-05 06:52:06 UTC
Latency (microseconds): [min: 0] [max: 0] [avg: 0]
Packet Statistics:
[ICMP: 0] [TCP: 82] [UDP: 0] [Other: 0]
Flow Statistics: ICMP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
TCP: [Current: 2] [Max: 6 @ 2010-02-05 06:52:08 UTC]
UDP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
Other: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
Session Statistics: [ICMP: 0] [TCP: 1] [UDP: 0] [Other: 0]
Policy Name : sample
Running Detector Version : 10.2.160091104
■
Correct clear security idp status log
user@host> clear security idp status
State of IDP: 2-default, Up since: 2010-02-04 13:37:16 UTC (17:13:45 ago)
Packets/second: 0 Peak: 0 @ 2010-02-05 06:49:51 UTC
KBits/second: 0 Peak: 0 @ 2010-02-05 06:49:51 UTC
Latency (microseconds): [min: 0] [max: 0] [avg: 0]
Packet Statistics: [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
188
Routers
■
Flow Statistics: ICMP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
TCP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
UDP: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
Other: [Current: 0] [Max: 0 @ 2010-02-05 06:49:51 UTC]
Session Statistics: [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
Policy Name: sample
Running Detector Version: 10.2.160091104
■
■
The Verifying the Policy Compilation and Load Status section of the JUNOS
Software Security Configuration Guide has a missing empty/new line before
the IDPD Trace file heading, in the second sample output.
■
The JUNOS Software Security Configuration Guide incorrectly states that IDP
is not supported in transparent mode on SRX3400, SRX3600, SRX5600, and
SRX5800 devices. IDP is supported in transparent mode on those devices.
The IDP rule notification options listed in the JUNOS Software Security
Configuration Guide incorrectly include the Send Emails and Run Scripts options,
which are not supported in JUNOS Release 10.1.
J-Web
The following information pertains to SRX Series and J Series devices:
■
J-Web security package update Help page—The J-Web Security Package Update
Help page does not contain information about download status.
■
J-Web pages for stateless firewall filters—There is no documentation describing
the J-Web pages for stateless firewall filters. To find these pages in J-Web, go to
Configure>Security>Firewall Filters, then select IPv4 Firewall Filters or IPv6
Firewall Filters. After configuring filters, select Assign to Interfaces to assign
your configured filters to interfaces.
■
There is no documentation describing the J-Web pages for media gateways. To
find these pages in J-Web, go to Monitor>Media Gateway.
Screens
The following information pertains to SRX Series and J Series devices:
■
In the JUNOS Software Design and Implementation Guide, the “Implementing
Firewall Deployments for Branch Offices” chapter contains incorrect screen
configuration instructions.
Examples throughout this guide describe how to configure screen options using
the set security screen screen-name CLI statements. Instead, you should use the
set security screen ids-option screen-name CLI statements. All screen configuration
options are located at the [set security screen ids-option screen-name] level of the
configuration hierarchy.
Related Topics
■
Routers
■
189
■
■
Hardware Requirements for JUNOS Release 10.1 for SRX Series Services Gateways and J
Series Services Routers
■
Transceiver Compatibility for SRX Series and J Series Devices on page 190
■
Power and Heat Dissipation Requirements for J Series PIMs on page 190
■
Supported Third-Party Hardware on page 190
■
J Series CompactFlash and Memory Requirements on page 191
Transceiver Compatibility for SRX Series and J Series Devices
We strongly recommend that only transceivers provided by Juniper Networks be
used on SRX Series and J Series interface modules. Different transceiver types
(long-range, short-range, copper, and others) can be used together on multiport SFP
interface modules as long as they are provided by Juniper Networks. We cannot
guarantee that the interface module will operate correctly if third-party transceivers
are used.
Please contact Juniper Networks for the correct transceiver part number for your
device.
Power and Heat Dissipation Requirements for J Series PIMs
On J Series Services Routers, the system monitors the PIMs and verifies that the PIMs
fall within the power and heat dissipation capacity of the chassis. If power
management is enabled and the capacity is exceeded, the system prevents one or
more of the PIMs from becoming active.
CAUTION: Disabling power management can result in hardware damage if you
overload the chassis capacities.
You can also use CLI commands to choose which PIMs are disabled. For details about
calculating the power and heat dissipation capacity of each PIM and troubleshooting
procedures, see the J Series Services Routers Hardware Guide.
Supported Third-Party Hardware
The following third-party hardware is supported for use with J Series Services Routers
running Junos OS.
USB Modem
190
■
We recommend using a U.S. Robotics USB 56K V.92 Modem, model number USR
5637.
Hardware Requirements for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
Storage Devices
The USB slots on J Series Services Routers accept a USB storage device or USB storage
device adapter with a CompactFlash card installed, as defined in the CompactFlash
Specification published by the CompactFlash Association. When the USB device is
installed and configured, it automatically acts as a secondary boot device if the
primary CompactFlash card fails on startup. Depending on the size of the USB storage
device, you can also configure it to receive any core files generated during a router
failure. The USB device must have a storage capacity of at least 256 MB.
Table 7 on page 191 lists the USB and CompactFlash card devices supported for use
with the J Series Services Routers.
Table 7: Supported Storage Devices on the J Series Services Routers
Manufacturer
Storage Capacity
Third-Party Part Number
SanDisk—Cruzer Mini 2.0
256 MB
SDCZ2-256-A10
SanDisk
512 MB
SDCZ3-512-A10
SanDisk
1024 MB
SDCZ7-1024-A10
Kingston
512 MB
DTI/512KR
Kingston
1024 MB
DTI/1GBKR
SanDisk—ImageMate USB 2.0
Reader/Writer for CompactFlash Type I
and II
N/A
SDDR-91-A15
SanDisk CompactFlash
512 MB
SDCFB-512-455
SanDisk CompactFlash
1 GB
SDCFB-1000.A10
J Series CompactFlash and Memory Requirements
Table 8 on page 191 lists the CompactFlash card and DRAM requirements for J Series
Services Routers.
Table 8: J Series CompactFlash Card and DRAM Requirements
Model
Minimum CompactFlash
Card Required
Minimum DRAM
Required
Maximum DRAM
Supported
J2320
512 MB
512 MB
1 GB
J2350
512 MB
512 MB
1 GB
J4350
512 MB
512 MB
2 GB
J6350
512 MB
1 GB
2 GB
■
191
Related Topics
■
■
■
Changes In Default Behavior and Syntax in JUNOS Release 10.1 for SRX Series
■
■
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series
■
Dual-Root Partitioning Scheme Documentation for SRX Series Services Gateways
Dual-Root Partitioning Scheme
JUNOS Release 10.1 supports dual-root partitions on SRX100, SRX210, SRX240, and
SRX650 devices. Dual-root partition allow the SRX Series devices to remain functional
if there is file system corruption and facilitate easy recovery of the corrupted file
system.
SRX Series devices running JUNOS Release 9.6 or earlier support a single-root
partitioning scheme where there is only one root partition. Because both the primary
and backup JUNOS Software images are located on the same root partition, the
system fails to boot if there is corruption in the root file system. The dual-root
partitioning scheme guards against this scenario by keeping the primary and backup
JUNOS Software images in two independently bootable root partitions. If the primary
root partition becomes corrupted, the system will be able to boot from the backup
JUNOS Software image located in the other root partition and remain fully functional.
SRX Series devices that ship with JUNOS Release 10.1 are formatted with dual-root
partitions from the factory. SRX Series devices that are running JUNOS Release 9.6
or earlier can be formatted with dual-root partitions when upgrading to JUNOS Release
10.1.
NOTE: The dual-root partitioning scheme allows the SRX Series devices to remain
functional if there is file system corruption and facilitates easy recovery of the
corrupted file system. Although you can install JUNOS Release 10.1 on SRX100,
SRX210, SRX240, and SRX650 devices with the single-root partitioning scheme, we
strongly recommend the use of the dual-root partitioning scheme.
192
■
Selection of Boot Media and Boot Partition
When the SRX Series device powers on, it tries to boot the JUNOS Software from the
default storage media. If the device fails to boot from the default storage media, it
tries to boot from the alternate storage media.
SRX100, SRX210, SRX240 devices boot from the following storage media (in order
of priority):
1.
Internal NAND flash (default; always present)
2.
USB storage device (alternate)
SRX650 devices boot from the following storage media (in order of priority):
1.
Internal CompactFlash card (default; always present)
2.
External CompactFlash card (alternate)
3.
USB storage device (alternate)
With the dual-root partitioning scheme, the SRX Series device first tries to boot the
JUNOS Software from the primary root partition and then from the backup root
partition on the default storage media. If both primary and backup root partitions of
a media fail to boot, then the SRX Series device tries to boot from the next available
type of storage media. The SRX Series device remains fully functional even if it boots
the JUNOS Software from the backup root partition of storage media.
Important Differences Between Single-Root and Dual-Root Partitioning Schemes
Note the following important differences in how SRX Series devices use the two types
of partitioning systems.
■
With the single-root partitioning scheme, there is one root partition that contains
both the primary and backup JUNOS Software images. With the dual-root
partitioning scheme, the primary and backup copies of JUNOS Software are in
different partitions. The partition containing the backup copy is mounted only
when required.
■
With the dual-root partitioning scheme, when the request system software add
command is performed for a JUNOS Software package, the contents of the other
root partition are erased. The contents of the other root partition will not be valid
unless the installation is completed successfully.
■
With the dual-root partitioning scheme, after a new JUNOS Software image is
installed, add-on packages like jais or jfirmware should be reinstalled as required.
■
With the dual-root partitioning scheme, the request system software rollback CLI
command does not delete the current JUNOS Software image. It is possible to
switch back to the image by using the rollback command again.
■
With the dual-root partitioning scheme, the request system software delete-backup
CLI command does not take any action. The JUNOS Software image in the other
root partition will not be deleted.
■
193
Upgrade Methods
SRX Series devices that ship from the factory with JUNOS Release 10.1 are formatted
with the dual-root partitioning scheme.
Existing SRX Series devices that are running JUNOS Release 9.6 or earlier use the
single-root partitioning scheme. While upgrading these routers to JUNOS Release
10.1, you can choose to format the storage media with dual-root partitions (strongly
recommended) or retain the existing single-root partitioning.
Certain JUNOS Software upgrade methods format the internal media before
installation, whereas other methods do not. To install JUNOS Release 10.1 with the
dual-root partitioning scheme, you must use an upgrade method that formats the
internal media before installation.
The following upgrade methods format the internal media before installation:
■
Installation from the boot loader using a TFTP server
■
Installation from the boot loader using a USB storage device
■
Installation from the CLI using the special partition option (available in JUNOS
Release 10.1)
The following upgrade methods retain the existing partitioning scheme:
■
Installation using the CLI
■
Installation using J-Web
WARNING: Upgrade methods that format the internal media before installation wipe
out the existing contents of the media. Only the current configuration will be
preserved. Any important data should be backed up before starting the process.
NOTE: Once the media has been formatted with the dual-root partitioning scheme,
you can use conventional CLI or J-Web installation methods, which retain the existing
partitioning and contents of the media, for subsequent upgrades.
Upgrading to JUNOS Release 10.1 Without Transitioning to Dual-Root Partitioning
If dual-root partitioning is not desired, use the conventional CLI and J-Web installation
methods, as described in the Junos OS Administration Guide for Security Devices.
Upgrading to JUNOS Release 10.1 with Dual-Root Partitioning
To format the media with dual-root partitioning while upgrading to JUNOS Release
10.1, use one of the following installation methods:
194
■
■
Installation from the boot loader using a TFTP server. This method is preferable
if console access to the system is available and a TFTP server is available in the
network.
■
Installation from the boot loader using a USB storage device. This method is
preferable if console access to the system is available and the system can be
physically accessed to plug in a USB storage device.
■
Installation from CLI using the special partition option. This method is
recommended only when console access is not available. This installation can
be performed remotely.
NOTE: After upgrading to JUNOS Release 10.1, the U-boot and boot loader must be
upgraded for the dual-root partitioning scheme to work properly.
Each of the aforementioned methods of installing JUNOS 10.1 with dual-root
partitioning is described in detail in the following sections:
■
Installing from the Boot Loader Using a TFTP Server on page 195
■
Installing from the Boot Loader Using a USB Storage Device on page 196
■
Installing from the CLI Using the partition Option on page 196
■
Upgrading the Boot Loader on page 197
Installing from the Boot Loader Using a TFTP Server
See the Junos OS Administration Guide for Security Devices for detailed information
on installing JUNOS Software using a TFTP server.
To install JUNOS Release 10.1 from the boot loader using a TFTP server:
1.
Upload the JUNOS Software image to a TFTP server.
2.
Stop the device at the loader prompt and set the following variables:
■
ipaddr
loader> set ipaddr=<IP-address-of-the-device>
■
netmask
loader> set netmask=<netmask>
■
gatewayip
loader> set gatewayip=<gateway-IP-address>
■
serverip
loader> set severip=<TFTP-server-IP-address>
3.
Install the image using the following command at the loader prompt:
■
195
loader> install tftp://<server-ip>/<image-path-on-server>
For example:
loader> install tftp://10.77.25.12/junos-srxsme-10.1R1-domestic.tgz
This will format the internal media and install the new JUNOS Software image
on the media with dual-root partitioning.
4.
Once the system boots up with JUNOS Release 10.1, upgrade the U-boot and
boot loader immediately. See “Upgrading the Boot Loader” on page 197.
Installing from the Boot Loader Using a USB Storage Device
To install JUNOS Release 10.1 from the boot loader using a USB storage device:
1.
Format a USB storage device in MS-DOS format.
2.
Copy the JUNOS Software image onto the USB storage device.
3.
Plug the USB storage device into the SRX Series device.
4.
Stop the device at the loader prompt and use the following command:
loader> install file:///<image-path-on-usb>
For example:
loader> install file:///junos-srxsme-10.1R1-domestic.tgz
This will format the internal media and install the new JUNOS Software image
on the media with dual-root partitioning.
5.
Once the system boots up with JUNOS Release 10.1, upgrade the U-boot and
boot loader immediately. See “Upgrading the Boot Loader” on page 197.
Installing from the CLI Using the partition Option
To install JUNOS Release 10.1 with the partition option:
1.
Upgrade the device to JUNOS Release 10.1 or later using the CLI or J-Web. This
will install the new image with the older single-root partitioning scheme.
2.
After the device reboots with JUNOS Release 10.1, upgrade the boot loader to
version 1.5. See “Upgrading the Boot Loader” on page 197.
3.
Reinstall the 10.1 image from JUNOS CLI using the request system software add
command with the partition option. This will copy the image to the device, then
reboot the device for installation. The device will boot up with the 10.1 image
installed with the dual-root partitioning scheme.
NOTE: This process might take 15–20 minutes. The system will not be accessible
over the network during this time.
196
■
Upgrading the Boot Loader
To upgrade the boot loader to version 1.5:
1.
Upgrade to JUNOS Release 10.1 (with or without dual-root support enabled).
The JUNOS 10.1 image contains the latest boot loader binaries in the following
path: /boot/uboot, /boot/loader.
2.
Enter the shell prompt.
3.
Run the following command from the shell prompt:
bootupgrade –u /boot/uboot –l /boot/loader
Installing JUNOS Release 9.6 or Earlier Release on Systems with Dual-Root
Partitioning
JUNOS Release 9.6 and earlier is not compatible with the dual-root partitioning
scheme. These releases can only be installed if the media is reformatted with
single-root partitioning. Any attempt to install JUNOS Release 9.6 or earlier on a
device with dual-root partitioning without reformatting the media will fail with an
error. You must install the JUNOS Release 9.6 or earlier image from the boot loader
using a TFTP server, USB storage device or CLI partition.
NOTE: You do not need to reinstall the earlier version of the boot loader.
Reinstalling the Single-Root Partition Release Over TFTP
To reinstall JUNOS Software from the boot loader using a TFTP server:
1.
Upload the JUNOS Software image to a TFTP server.
2.
Stop the device at the loader prompt and set the following variables:
■
ipaddr
loader> set ipaddr=<IP-address-of-the-device>
■
netmask
loader> set netmask=<netmask>
■
gatewayip
loader> set gatewayip=<gateway-IP-address>
■
serverip
loader> set severip=<TFTP-server-IP-address>
■
197
3.
Install the image using the following command at the loader prompt:
user@host> install tftp://<server-ip>/<image-path-on-server>
For example:
loader> install tftp://10.77.25.12/junos-srxsme-9.6R1-domestic.tgz
This will format the internal media and install the JUNOS Software image on the
media with single-root partitioning.
Reinstalling the Single-Root Partition Release Using USB
To reinstall JUNOS Software from the boot loader using a USB storage device:
1.
Format a USB storage device in MS-DOS format.
2.
Copy the JUNOS Software image onto the USB storage device.
3.
Plug the USB storage device into the SRX Series device.
4.
Stop the device at the loader prompt and use the following command:
user@host> install file://<image-path-on-usb>
For example:
loader> install file:///junos-srxsme-9.6R1-domestic.tgz
This will format the internal media and install the JUNOS Software image on the
media with single-root partitioning.
Installing from the CLI Using the partition Option
To reinstall JUNOS Release 9.6 with the partition option:
1.
Upgrade the boot loader to version 1.5 if your boot loader is older than it. See
“Upgrading the Boot Loader” on page 197
2.
Reinstall the 9.6 image from JUNOS CLI using the request system software add
command with the partition option. This will copy the image to the device, then
reboot the device for installation. The device will boot up with the 9.6 image
installed with the single-root partitioning scheme.
NOTE: This process might take 15–20 minutes. The system will not be accessible
over the network during this time.
Recovery of the Primary JUNOS Software Image with Dual-Root Partitioning Scheme
If the SRX Series Services Gateway is unable to boot from the primary JUNOS Software
image, and boots up from the backup JUNOS Software image in the backup root
198
■
partition, a message is displayed on the console at the time of login indicating that
the device has booted from the backup JUNOS Software image:
login: user
Password:
***********************************************************************
**
**
**
WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE
**
**
**
**
It is possible that the active copy of JUNOS failed to boot up
**
**
properly, and so this device has booted from the backup copy.
**
**
**
**
Please re-install JUNOS to recover the active copy in case
**
**
it has been corrupted.
**
**
**
***********************************************************************
Because the system is left with only one functional root partition, you should
immediately restore the primary JUNOS Software image. This can be done by installing
a new image using the CLI or J-Web. The newly installed image will become the
primary image, and the device will boot from it on the next reboot.
CLI Changes
This section describes CLI changes when the SRX Series device runs JUNOS Release
10.1 with the dual-root partitioning scheme.
■
Changes to the Snapshot CLI on page 199
■
partition Option with the request system software add Command on page 200
Changes to the Snapshot CLI
On an SRX Series device, you can configure the primary or secondary boot device
with a “snapshot” of the current configuration, default factory configuration, or rescue
configuration. The snapshot feature is modified to support dual-root partitioning.
The options as-primary, swap-size, config-size, root-size, var-size, and data-size are not
supported on SRX Series devices.
With the dual-root partitioning scheme, performing a snapshot to a USB storage
device that is less than 1 GB is not supported.
■
199
With the dual-root partitioning scheme, you must use the partition option when
performing a snapshot. If the partition option is not specified, the snapshot operation
fails with a message that the media needs to be partitioned for snapshot.
The output for the show system snapshot CLI command is changed in devices with
dual-root partitions to show the snapshot information for both root partitions:
user@host> show system snapshot media usb
Information for snapshot on
usb (/dev/da1s1a) (primary)
Creation date: Jul 24 16:16:01 2009
JUNOS version on snapshot:
junos
: 10.1I20090723_1017-domestic
Information for snapshot on
usb (/dev/da1s2a) (backup)
Creation date: Jul 24 16:17:13 2009
JUNOS version on snapshot:
junos
: 10.1I20090724_0719-domestic
NOTE: You can use the show system snapshot media internal command to determine
the partitioning scheme present on the internal media. Information for only one root
is displayed for single-root partitioning, whereas information for both roots is
displayed for dual-root partitioning.
NOTE: Any removable media that has been formatted with dual-root partitioning
will not be recognized correctly by the show system snapshot CLI command on
systems that have single-root partitioning. Intermixing dual-root and single-root
formatted media on the same system is strongly discouraged.
partition Option with the request system software add Command
A new partition option is available with the request system software add CLI command.
Using this option will cause the media to be formatted and repartitioned before the
software is installed.
When the partition option is used, the format and install process is scheduled to run
on the next reboot. Therefore, it is recommended that this option be used together
with the reboot option.
For example:
user@host>request system software add junos-srxsme-10.1R1-domestic.tgz no-copy
no-validate partition reboot
Copying package junos-srxsme-10.01R1-domestic.tgz to var/tmp/install
200
■
Maximizing ALG Sessions
Rebooting ...
The system will reboot and complete the installation.
WARNING: Using the partition option with the request system software add CLI
command erases the existing contents of the media. Only the current configuration
is preserved. Any important data should be backed up before starting the process.
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, by default, the session
capacity number for RTSP, FTP, and TFTP ALG sessions is 10,000 per flow SPU. The
maximize-alg-sessions option enables you to increase defaults as follows:
■
RTSP, FTP, and TFTP ALG session capacity: 25,000 sessions per flow SPU
■
TCP Proxy connection capacity: 40,000 sessions per flow SPU
NOTE: Flow session capacity will be reduced to half per flow SPU and the above
capacity numbers will not change on the central point SPU.
You can configure maximum ALG sessions as follows:
security {
forwarding-process {
application-services {
maximize-alg-sessions;
}
}
}
You must reboot the device (and its peer in the chassis cluster) for the configuration
to take effect.
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing
Engine
A second Routing Engine is required for each device in a cluster if you are using the
dual control links feature (SRX5000 line only). The second Routing Engine does not
provide backup functionality; its purpose is only to initialize the switch on the Switch
Control Board (SCB). The second Routing Engine must be running JUNOS Release
10.1 or later.
Because you cannot run the CLI or enter configuration mode on the second Routing
Engine, you cannot upgrade the JUNOS Software image with the usual upgrade
commands. Instead, use the master Routing Engine (RE0) to create a bootable USB
storage device, which you can then use to install a software image on the second
Routing Engine (RE1).
■
201
To upgrade the software image on the second Routing Engine (RE1):
1.
Use FTP to copy the installation media into the /var/tmp directory of the master
Routing Engine (RE0).
2.
Insert a USB storage device into the USB port on the master Routing Engine
(RE0).
3.
In the UNIX shell, navigate to the /var/tmp directory:
start shell
cd /var/tmp
4.
Log in as root or superuser:
su [enter]
password: [enter SU password]
5.
Use the following command;
dd if=installMedia of=/dev/externalDrive bs=64k
where
■
externalDrive—Refers to the removable media name. For example, the
removable media name on an SRX5000 line device is da0 for both Routing
Engines.
■
installMedia—Refers to the installation media downloaded into the /var/tmp
directory. For example, install-media-srx5000-10.1R1-domestic.tgz.
The following code example can be used to write the image that you copied to
the master Routing Engine (RE0) in step 1 onto the USB storage device:
dd if=install-media-srx5000-10.1R1-domestic.tgz of=/dev/da0 bs=64k
6.
Log out as root or superuser:
exit
7.
After the software image is written to the USB storage device, remove the device
and insert it into the USB port on the second Routing Engine (RE1).
8.
Move the console connection from the master Routing Engine (RE0) to the second
Routing Engine (RE1), if you do not already have a connection.
9.
Reboot the second Routing Engine (RE1). Use the following command:
# reboot
■
When the following system output appears, press y:
WARNING: The installation will erase the contents of your disks.
Do you wish to continue (y/n)?
■
202
■
When the following system output appears, remove the USB storage device
and press Enter:
Using Dual Chassis Cluster Control Links: Upgrade Instructions for the Second Routing Engine
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
Eject the installation media and hit [Enter] to reboot?
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services
To upgrade to JUNOS Release 10.1 or later, your device must be running one of the
following JUNOS Software releases:
■
9.1S1
■
9.2R4
■
9.3R3
■
9.4R3
■
9.5R1 or later
If your device is running an earlier release, upgrade to one of these releases and then
to the 10.1 release. For example, to upgrade from Release 9.2R1, first upgrade to
Release 9.2R4 and then to Release 10.1R2.
For additional upgrade and download information, see the JUNOS Software
Administration Guide and the JUNOS Software Migration Guide.
JUNOS Software Release Notes for EX Series Switches
■
New Features in JUNOS Release 10.1 for EX Series Switches on page 203
■
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series
Switches on page 207
■
Limitations in JUNOS Release 10.1 for EX Series Switches on page 208
■
Outstanding Issues in JUNOS Release 10.1 for EX Series Switches on page 211
■
Resolved Issues in JUNOS Release 10.1 for EX Series Switches on page 213
■
Errata in Documentation for JUNOS Release 10.1 for EX Series
■
Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series
New Features in JUNOS Release 10.1 for EX Series Switches
New features in Release 10.1 of JUNOS Software for EX Series switches are described
in this section.
Not all EX Series software features are supported on all EX Series platforms in the
current release. For a list of all EX Series software features and their platform support,
see EX Series Switch Software Features Overview.
Upgrade and Downgrade Instructions for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services
Routers
■
203
New features are described on the following pages:
■
Hardware on page 204
■
Access Control and Port Security on page 205
■
Bridging, VLANs, and Spanning Trees on page 205
■
Class of Service (CoS) on page 205
■
Infrastructure on page 205
■
Interfaces on page 206
■
Layer 2 and Layer 3 Protocols on page 206
■
Management and RMON on page 206
■
MPLS on page 206
■
Packet Filters on page 206
Hardware
■
EX2200 switch—The EX2200 switch is a fixed-configuration switch that is
available in four models—24-port or 48-port models with either all ports equipped
for Power over Ethernet (PoE) or none of the ports equipped for PoE.
All EX2200 models provide network ports that have 10/100/1000BASE-T Gigabit
Ethernet connectors and uplink ports that support 1-gigabit small form-factor
pluggable (SFP) transceivers for use with fiber connections and copper
connections. For information about software features supported on the EX2200
switch, see EX Series Switch Software Features Overview.
The following optical interfaces are supported on the EX2200 switch:
■
204
■
■
EX-SFP-1GE-T (1000BASE-T, 100 m)
■
EX-SFP-1GE-SX (1000BASE-SX, 220 m, 275 m, 500 m, or 550 m)
■
EX-SFP-1GE-LX (1000BASE-LX, 10 km)
■
EX-SFP-1GE-LH (1000BASE-LH or 1000Base-LH, 70 km)
■
EX-SFP-1FE-FX (100BASE-FX, 2 km)
■
EX-SFP-FE20KT13R15 (100BASE-BX-U, 20 km)
■
EX-SFP-FE20KT15R13 (100BASE-BX-D, 20 km)
New optical transceiver support—The 8-port 10-Gigabit Ethernet SFP+ line
card in EX8200 switches now supports one new optical transceiver:
EX-SFP-10GE-ER (10GBase-ER, 40 km).
Access Control and Port Security
■
Captive portal authentication—Captive portal authentication allows you to
authenticate users on EX Series switches by redirecting Web browser requests
to a login page that requires users to input a username and password before
they are allowed access to the network. In addition to using the feature to control
network access by requiring users to provide information that is authenticated
against a RADIUS server database, you can use it to display an acceptable-use
policy to users before they access your network. An authentication whitelist
allows you to specify MAC addresses that are allowed to bypass authentication.
Bridging, VLANs, and Spanning Trees
■
Proxy ARP—Proxy ARP can be configured on a per-VLAN basis, in either
restricted or unrestricted mode.
■
IPv6 unicast VRF support—EX Series switches now support IPv6 unicast virtual
routing and forwarding (VRF) traffic.
■
Private VLANs—Private VLANs (PVLANs) are now supported on EX8200 switches.
Class of Service (CoS)
■
Port shaping and queue shaping—Port shaping and queue shaping (the
shaping-rate configuration statement) is now available on EX8200 switches.
Infrastructure
■
IPv6 support on EX8200 switches—EX8200 switches now support configuration
of IPv6 addresses.
■
Automatic refreshing of scripts—You can refresh commit, event, and op scripts
automatically using operational mode commands such as request system scripts
refresh-from commit, request system scripts refresh-from event, or request system
scripts refresh-from op.
■
Source gateway IP address selection for relayed DHCP packets—The source
gateway IP address selection for relayed DHCP packets feature allows you to use
the gateway IP address (giaddr) as the source IP address of the switch for relayed
DHCP packets when an EX Series switch is used as the DHCP relay agent.
■
205
Interfaces
■
Unicast reverse-path forwarding support—Unicast reverse-path forwarding
(RPF) is available on EX8200 switches. The unicast RPF feature can be enabled
on specific interfaces on EX8200 switches and supports ECMP traffic.
Layer 2 and Layer 3 Protocols
■
IPv6 Layer 3 multicast routing and forwarding—EX3200 and EX4200 switches
now support IPv6 Layer 3 multicast routing and forwarding, which includes
Multicast Listener Discovery (MLD) version 1 and version 2 to manage multicast
group membership; reverse-path forwarding (RPF) to enable multicast routers
to correctly forward multicast traffic to other multicast routers; Protocol
Independent Multicast sparse mode (PIM SM) and PIM source-specific multicast
(PIM SSM) protocols; and static rendezvous point (RP), bootstrap RP, and
embedded RP to manage RP information for multicast groups.
Management and RMON
■
Real-time performance monitoring (RPM) support on EX8200 switches—RPM
is supported on EX8208 and EX8216 switches.
■
SNMP MIB enhancements—On EX2200 switches, the SNMP agent polls and
gets details of all MIBs.
MPLS
■
MPLS enhancements—On EX3200 and EX4200 switches, MPLS supports class
of service (CoS), IP over MPLS, and fast reroute to reroute the label-switched
path in cases of link failure.
Packet Filters
■
IPv6 support for firewall filters on EX3200 and EX4200 switches—On EX3200
and EX4200 switches, you can apply match conditions to IPv6 traffic on Layer
3 interfaces, aggregated Ethernet interfaces, and loopback interfaces.
The following are the match conditions applicable to IPv6 traffic:
destination-address, destination-port, destination-prefix-list, icmp-code, icmp-type,
interface, next-header, packet-length, source-address, source-port, source-prefix-list,
tcp-established, tcp-flags, tcp-initial, and traffic-class.
The following are the actions and action modifiers applicable to IPv6 traffic:
accept, discard, routing-instance, analyzer, count, forwarding-class, loss-priority, and
policer.
■
206
■
Enhancement to the interface match condition on EX8200 switches—On
EX8200 switches, you can now specify aggregated Ethernet interfaces as match
conditions using the interface match condition. You can configure an ingress or
Changes in Default Behavior and Syntax in JUNOS Release 10.1 for EX Series Switches
egress firewall filter with an aggregated Ethernet interface as a match condition
and apply the firewall filter to ports, VLANs, and Layer 3 interfaces.
Related Topics
■
■
■
■
■
Errata in Documentation for JUNOS Release 10.1 for EX Series Switches on
page 217
■
Upgrade and Downgrade Issues for JUNOS Release 10.1 for EX Series Switches
on page 218
The following changes in system behavior, configuration statement usage, or
operational mode command usage have occurred since the previous release and
might not yet be documented in the JUNOS Software for EX Series switches
documentation:
Layer 2 and Layer 3 Protocols
■
EX Series switches now support the show multicast rpf instance instance-name
command.
■
The iso option is not available in the show pfe route command because it is not
supported on EX Series switches.
■
On EX Series switches, the sip-server statement in the [edit system services dhcp]
hierarchy is now supported, allowing explicit configuration of SIP server addresses
for DHCP servers.
Infrastructure
■
On EX3200 switches and EX4200 switches, the request system power-off
other-routing-engine and the request system power-off both-routing-engines
commands are disabled.
■
The output of the show chassis hardware command for EX3200 switches and
EX4200 switches has been changed. The Description field in the output now
displays SFP-100-LX40 for the 100Base-LH interface and SFP-100-LH for the
100Base-ZX interface.
■
If you enable PIM on all interfaces using the interface all command, it is not
enabled on the me0 and vme interfaces by default. Therefore you do not need
■
207
to explicitly disable PIM on these management interfaces. Previously, enabling
PIM on all interfaces caused it to be enabled on these management interfaces.
Related Topics
■
■
■
■
■
page 217
■
on page 218
Limitations in JUNOS Release 10.1 for EX Series Switches
This section lists the limitations in JUNOS Release 10.1R4 for EX Series switches.
Access Control and Security
■
When you have configured more than 1024 supplicants on a single interface,
802.1X authentication might not work as expected and the 802.1X process
(dot1xd) might fail.
■
On EX8200 switches, classification of packets using ingress firewall filter rules
with forwarding-class and loss-priority configurations does not rewrite the DSCP
or 802.1p bits. Rewriting of packets is determined by the forwarding-class and
loss-priority values set in the DSCP classifier applied on the interface.
■
On EX4200 switches, the traffic is shaped at rates above 500 kbps, even when
the shaping rate configured is less than 500 kbps.
■
When the scheduler map bound to an interface is changed, there might be packet
drops temporarily on all the interfaces bound to the scheduler map while the
configuration change is being implemented.
■
On EX Series switches, when interface ranges or VLAN ranges are used in
configuring firewall filters, egress firewall filter rules take more than 5 minutes
to take effect.
■
IGMP packets are not matched by user-configured firewall filters.
Class of Service
Firewall Filters
208
■
Infrastructure
■
If you configure interface parameters on an EX3200 or EX4200 switch running
JUNOS Release 9.2 or Release 9.3 for EX Series switches and then attempt to
upgrade to a later release or a later version of Release 9.3 than the one that is
currently installed, the switch might display the following error message: init:
interface-control is thrashing , not restarted. As a workaround, on the interfaces
you had previously configured, configure no-auto-negotiation and set the link
mode to full-duplex, then commit the revised configuration.
■
The RADIUS request sent by an EX Series switch contains both Extensible
Authentication Protocol (EAP) Identity Response and State attributes.
■
On EX Series switches, an SNMP query fails when the SNMP index size of a table
is greater than 128 bytes, because the Net SNMP tool does not support SNMP
index sizes greater than 128 bytes.
■
Spanning-tree, GVRP, or IGMP snooping configuration windows might load slowly
in the J-Web interface. Wait till the windows load completely before entering
information, or some information might get lost.
■
On EX Series switches, the show snmp mib walk etherMIB does not display any
output, even though the etherMIB is supported. This occurs because the values
are not populated at the module level—they are populated at the table level only.
You can issue show snmp mib walk dot3StatsTable, show snmp mib walk
dot3PauseTable, and show snmp mib walk dot3ControlTable commands to display
the output at the table level.
■
When you issue the request system power-off command, the switch halts instead
of turning off power.
■
In the J-Web interface, the Ethernet Switching monitoring page might not display
monitoring details if there are more than 13,000 MAC entries on the switch.
■
In the J-Web interface, changing the port role from Desktop, Desktop and Phone,
or Layer 2 Uplink to another port role might not remove the configurations for
enabling dynamic ARP inspection and DHCP snooping.
■
On EX8200 switches, if IS-IS is enabled on routed VLAN interfaces (RVIs), IS-IS
adjacency states go down and come up after a graceful Routing Engine switchover
(GRES).
■
When an external RADIUS server goes offline and comes back online after some
time, subsequent captive portal authentication requests might fail until the authd
daemon is restarted. As a workaround, configure the revert interval—the time
after which to revert to the primary server—and restart the authd daemon.
■
Momentary loss of an inter-Routing Engine IPC message might trigger the alarm
that displays the message Loss of communication with Backup RE. There is no
functionality affected.
■
209
Interfaces
■
EX Series switches do not support queued packet counters. Therefore, the queued
packet counter in the output of the show interfaces interface-name extensive
command always displays a count of 0 and is never updated.
■
The following message might appear in the system log:
Resolve request came for an address matching on Wrong nh nh:355,
type:Unicast...?
You can ignore this message.
Related Topics
210
■
■
On EX3200 and EX4200 switches, when port mirroring is configured on any
interface, the mirrored packets leaving a tagged interface might contain an
incorrect VLAN ID.
■
On EX8200 switches, port mirroring configuration on a Layer 3 interface with
the output configured to a VLAN is not supported.
■
On EX8200 switches, when an egress VLAN that belongs to a routed VLAN
interface (RVI) is configured as the input for a port mirroring analyzer, the
analyzer incorrectly appends a dot1q (802.1Q) header to the mirrored packets
or does not mirror any packets at all. As a workaround, configure a port mirroring
analyzer with each port of the VLAN as egress input.
■
The following interface counters are not supported on routed VLAN interfaces
(RVIs): local statistics, traffic statistics, and transit statistics.
■
EX Series switches do not support IPv6 interface statistics. Therefore, all values
in the output of the show snmp mib walk ipv6IfStatsTable command always display
a count of 0.
■
The show interface detail | extensive command might display double counting of
packets or bytes for the transit statistics and traffic statistics counters. You can
use the counter information displayed under the Physical interface section of the
output.
■
When a virtual management Ethernet (VME) interface is used as a default gateway
and the VME interface is the indirect next hop for any route, the route might not
change dynamically and could always point to the VME interface.
■
■
■
■
■
page 217
■
on page 218
Outstanding Issues in JUNOS Release 10.1 for EX Series Switches
The following are outstanding issues in JUNOS Release 10.1R3 for EX Series switches.
The identifier following the description is the tracking number in our bug database.
NOTE: PRs 300576, 403842, 409934, 415569, 415748, 416976, 429589, 440611,
455670, 488318, and 490542 which were included in the earlier release notes as
outstanding issues, have been removed, because these issues are not applicable to
JUNOS Release 10.1R4 for EX Series switches.
■
If you configure the RADIUS server revert-interval interval option, the switch does
not attempt to reconnect to the unreachable server after the revert interval has
elapsed. [PR/304637]
■
If you change the value of lldp management-address before configuring the IP
address on the physical interface, the SNMP MIB might not be updated correctly
on the remote station (lldpRemManAddr). As a workaround, either configure the
new address on the interface before setting lldp management-address, or bounce
the interface. [PR/534138]
■
There might be traffic loss on VLANs learned through MVRP during GRES. After
the GRES, there will not be any traffic loss. [PR/458303]
■
On EX2200 switches, CoS might yield different shaping results on uplink ports
than on built-in network ports when the same shaping rate is used. [PR/453660]
■
On EX8200 switches, when IGMP snooping is enabled on an interface, the IPv6
multicast Layer 2 control frame is not forwarded to other interfaces in the same
VLAN. [PR/456700]
■
The jnxFirewallMIB might not be populated in a firewall filter configuration. As a
workaround, set up the following configuration to skip the firewall MIB:
Class of Service
Infrastructure
user@switch# show snmp
view firewall_exclude {
oid .1.3.6.1.4.1.2636.3.5 exclude;
oid .1;
}
community public {
view firewall_exclude;
authorization read-only;
}
■
211
[PR/464061]
■
If you try to commit a configuration that has 4000 VLANs and a few aggregated
Ethernet interfaces at the same time, the forwarding process (PFEM) usage might
be high, and might remain high for more than 60 minutes. [PR/544433]
■
In the J-Web interface, you cannot commit some configuration changes in the
Ports Configuration page and VLAN Configuration page because of the following
limitations for port mirroring ports and port mirroring VLANs:
J-Web Interface
■
A port configured as the output port for an analyzer cannot be a member of
any VLAN other than the default VLAN.
■
A VLAN configured to receive analyzer output can be associated with only
one port.
[PR/400814]
212
■
■
If an SRE module, RE module, SF module, line card, or Virtual Chassis member
is in offline mode, the J-Web interface might not update the dashboard image
accordingly. [PR/431441]
■
In the J-Web interface, in the Port Security Configuration page, you are required
to configure action when you configure MAC limit even though configuring an
action value is not mandatory in the CLI. [PR/434836]
■
In the J-Web interface, in the OSPF Global Settings table in the OSPF Configuration
page, the Global Information table in the BGP Configuration page, or the Add
Interface window in the LACP Configuration page, if you try to change the position
of columns using the drag-and-drop method, only the column header moves to
the new position instead of the entire column. [PR/465030]
■
When you have a large number of static routes configured and if you have
navigated to pages other than page 1 in the Route Information table in the J-Web
interface (Monitor > Routing > Route Information), changing the Route Table
to query other routes refreshes the page but does not return to page 1. For
example, if you run the query from page 3 and the new query returns very few
results, the Results table continues to display page 3 and shows no results. To
view the results, navigate to page 1 manually. [PR/476338]
■
In the J-Web interface, the dashboard does not display the uplink ports when
transceivers are not plugged into the ports. [PR/477549]
■
The J-Web interface Static Routing page might not display details on entries
registered in the routing table. [PR/483885]
■
An IPv4 static route configured using the CLI might not be displayed when you
select Configure > Routing > Static Routing in the J-Web interface. [PR/487597]
■
In the J-Web interface, the auto-complete feature might not be disabled in the
password field. As a workaround, you can disable the auto-complete feature in
the browser. [PR/508425]
■
In the J-Web interface, warning messages related to pending commits might not
be triggered while uploading a software package, installing a software package,
Resolved Issues in JUNOS Release 10.1 for EX Series Switches
or rebooting the switch. As a workaround, commit all pending configuration
changes before performing these operations. [PR/514853]
Related Topics
■
When you use an HTTPS connection in the Microsoft Internet Explorer Web
browser to save a report from the View Events page (Monitor > Events and Alarms
> View events) in the J-Web interface, the following error message is displayed:
Internet Explorer was not able to open the Internet site. [PR/542887]
■
When you use an HTTPS connection to access the J-Web interface, uploading or
downloading a configuration file using the Config Management Upload page
(Maintain > Config Management > Upload) might not succeed. As a workaround,
use an HTTP connection to access the J-Web interface to upload or download a
configuration file. [PR/551200]
■
If you have accessed the J-Web interface using Microsoft Internet Explorer, you
might not be able to commit a configuration when an SSL certificate has been
added to the switch using the CLI editor (Configure >CLI tools > CLI Editor).
As a workaround, you can use Firefox to commit configurations. [PR/552629]
■
■
■
■
■
page 217
■
on page 218
The following are the issues that have been resolved since JUNOS Release 10.1R1
for EX Series switches. The identifier following the descriptions is the tracking number
in our bug database.
■
When both DHCP relay and DHCP snooping are configured on an EX2200 switch,
the DHCP snooping database might not be built on the switch. [PR/480682: This
■
When Multiple VLAN Registration Protocol (MVRP) and MSTP are enabled together
on EX Series switches, convergence does not occur between MVRP and MSTP.
■
On EX4200 switches, with the access interface through which traffic enters the
switch configured as trusted (secure-access-port interface interface-name
■
213
dhcp-trusted), VLAN Spanning Tree Protocol (VSTP) bridge protocol data units
(BPDUs) are sent to the Routing Engine with the learning CPU code 37 instead
of the reserved learning CPU code 306. [PR/468095: This issue has been resolved.]
■
On EX3200 and EX4200 switches with large VLAN configurations (more than
1024 VLANs), stale dynamic VLAN entries might be found in the Ethernet
switching process (eswd) after you delete VLANs or deactivate the Multiple VLAN
Registration Protocol (MVRP). [PR/471647: This issue has been resolved.]
■
On an EX2200 switch, when there is no spanning-tree protocol or redundant
trunk group configured in the network and there is traffic looping, after the
network loop is broken, sometimes MAC learning might not occur. As a
workaround, restart the forwarding (pfem) process. [PR/473454: This issue has
been resolved.]
■
On EX Series switches, in a scaled environment with more than 4000 VLANs,
MVRP advertisements might not be sent intermittently when the VLAN
membership is modified. [PR/475701: This issue has been resolved.]
■
When MVRP and VSTP are enabled together on EX Series switches, convergence
does not occur between MVRP and VSTP. [PR/477019: This issue has been
resolved.]
■
On EX3200 and EX4200 switches, when MVRP dynamic VLAN creation is
disabled, deregistration of VLANs on trunk interfaces does not occur even after
the tag associated with the VLAN has been modified. [PR/479636: This issue has
been resolved.]
■
On EX3200 and EX4200 switches, stale MVRP VLAN membership entries might
be found on blocked interfaces even after MVRP has been deactivated on the
peer switch. [PR/482126: This issue has been resolved.]
■
On an EX2200 switch, when a queue is oversubscribed and you modify a
scheduler with the buffer-size exact option on it such that it reduces the allocated
buffers on the queue, the queue can stop dequeueing packets. As a workaround,
stop traffic going out on the port, and deactivate and reactivate class of service
(CoS). You can also reboot the switch. [PR/481401: This issue has been resolved.]
■
The accept action and the log and syslog action modifiers in the firewall filter
configuration might not work as expected for packets destined for the switch.
■
If an ingress firewall has been configured with a LAG interface match condition
and you delete this firewall configuration, the forwarding (pfem) process might
create a core file. When the pfem process is restarted, it works as expected.
■
On EX3200 and EX4200 switches, if you configure an egress firewall filter with
the match condition source-address or destination-address on a VLAN and its
Class of Service
Firewall Filters
214
■
routed VLAN interface (RVI), the firewall filter might not work properly.
■
On an EX2200 switch, when you add a syslog action modifier to the firewall
filter, the forwarding (pfem) process might create a core file when the filter
binding is changed from an egress VLAN to an ingress VLAN. [PR/495572: This
■
On 48-port SFP line cards used in EX8200 switches, do not install a transceiver
in the first or last port on the bottom row (ports 1 and 47). Transceivers installed
in these ports are difficult to remove. As a workaround, remove the transceiver
by using a small flathead screwdriver or other tool to lift the lock on the
transceiver. [PR/423694: This issue has been resolved.]
■
On an EX2200 switch, if the following message is displayed when the switch is
booting, the installed package might be corrupted:
Hardware
Infrastructure
mount_check: SHA1 (/packages/jkernel-ex-10.1-20090925.0) =
f45dd191b053b608dafecc0ef3ea329c9f85693b
!=5fe72546eed0c0cb83e6addc6709720f56e8b6da
As a workaround, reinstall the image from the loader prompt with the -- format
option set. [PR/433663: This issue has been resolved.]
■
On EX Series switches, MAC addresses not present in the forwarding database
(FDB) because of hash collision are not removed from the Ethernet switching
process (eswd). These MAC addresses do not age out of the Ethernet switching
table even if traffic is stopped completely and are never relearned when traffic
is sent to these MAC addresses, even when there is no hash collision. As a
workaround, clear those MAC addresses from the Ethernet switching table.
■
Though the interface-range configuration statement is not supported under the
[edit groups] hierarchy, an error message might not be displayed when you use
the interface-range statement. [PR/453538: This issue has been resolved.]
■
The DHCP snooping database is not built after graceful Routing Engine switchover
(GRES) is performed twice. Even though packets are coming from the DHCP
server, they are not inserted in the DHCP relay. [PR/461318: This issue has been
resolved.]
■
If an interface is assigned to a VLAN before the interface's stg state is set, loops
might form in the network if a VLAN ID is assigned to the VLAN while the
interface is active in a redundant topology. [PR/472617: This issue has been
resolved.]
■
On EX2200 switches, the MIB OID ipv6Forwarding indicates that IPv6 is supported
even though IPv6 is not supported. The value of the ipv6Forwarding.0 MIB object
is 1. [PR/473128: This issue has been resolved.]
■
On EX8200 switches, after a graceful Routing Engine switchover (GRES), you
can navigate through the Maintenance menu in the LCD even after the
■
215
Maintenance menu in the LCD has been disabled using the set chassis lcd
maintenance-menu disable command. As a workaround, delete the LCD
Maintenance menu configuration using the CLI on the new master switch, and
then disable the LCD Maintenance menu using the set chassis lcd
maintenance-menu disable command. [PR/473597: This issue has been resolved.]
■
In some rare cases, switch bootup fails when the JUNOS Software is loading. The
message Device not ready displays because the NAND flash is not responding.
Workaround: Power cycle the switch. [PR/482026: This issue has been resolved.]
■
If you attempt to set the time zone to Europe/Berlin on a switch with dual Routing
Engines, the commit command might fail. [PR/483273: This issue has been
resolved.]
■
The name of the ethernet-switching-options authentication-whitelist statement will
be changed. The new name is correct in the documentation but is shown in the
CLI as ethernet-switching-options white-list. [PR/487167: This issue has been
resolved.]
■
A memory leak might be present in the pfem SPF database. As a workaround,
you can restart the forwarding (pfem) process. [PR/493197: This issue has been
resolved.]
■
In the J-Web interface, uploading a software package to the switch might not
work properly if you are using Microsoft Internet Explorer Web browser version
7. [PR/424859: This issue has been resolved.]
■
In the J-Web interface, the Edit MSTI window in the Spanning Tree Configuration
page might not display details of an uncommitted interface configuration.
■
In the J-Web interface, the menu on the left side of the J-Web pages and contents
of the J-Web pages might disappear when you double-click the Troubleshoot tab.
As a workaround, click the Dashboard tab or the Configure tab, and then click
the Troubleshoot tab to display the menu and contents of the page. [PR/459936:
This issue has been resolved]
■
In the J-Web interface, in the OSPF Configuration page, no flags are displayed
for the Traceoptions tab in OSPF Global Settings. [PR/461558: This issue has
been resolved.]
■
In the J-Web interface, in the BGP Configuration page (Configuration > Routing
> BGP), if the values entered in the text boxes (for protocols, filename, and
description) contain double quotation marks, the J-Web interface does not allow
you to delete those values. If the value in the Group Name field contains double
quotation marks, the J-Web interface allows you to delete the BGP group name,
but the deleted value reappears when you refresh the BGP Configuration page.
As a workaround, delete the values that contain double quotation marks using
the CLI. [PR/464030: This issue has been resolved.]
■
When you access the J-Web interface using the Mozilla Firefox Web browser and
move a J-Web window (for example, the Add Interface window) over the browser
toolbars, the window appears behind the browser toolbars. After this problem
occurs, the window cannot be moved, because the title bar of the window is not
J-Web Interface
216
■
Errata in Documentation for JUNOS Release 10.1 for EX Series Switches
visible. If you cancel and reopen the window, the window continues to appear
behind the browser toolbars. [PR/473238: This issue has been resolved.]
Related Topics
■
In the J-Web interface, in the OSPF Configuration page (Configuration > Routing
> OSPF), the Traceoptions tab in the Edit Global Settings window does not
display the available flags (tracing parameters). As a workaround, use the CLI to
view the available flags. [PR/475313: This issue has been resolved.]
■
In the J-Web interface Static Routing Configuration page, you might not be able
to delete a configured next-hop address because the Delete button is disabled.
■
In the J-Web interface, the OSPF Monitoring page might display an error message
if there are multiple interfaces or neighbors detected in an autonomous system.
■
When you navigate from the Monitor RIP Information page to the Monitor Route
Information page, the J-Web interface might display an error. [PR/536255: This
■
■
■
■
■
page 217
■
on page 218
There are no outstanding documentation issues in this release.
Related Topics
■
■
■
■
■
■
on page 218
■
217
The following pages list the issues in JUNOS Release 10.1R4 for EX Series switches
regarding software upgrade or downgrade:
■
■
■
Upgrading from JUNOS Release 9.2 to Release 10.1 for EX Series
■
Switches
The ARP aging time configuration in the system configuration stanza in JUNOS Release
9.4R1 is incompatible with the ARP aging time configuration in JUNOS Release 9.3R1
or earlier and JUNOS Release 9.4R2 or later. If you have configured system arp
aging-timer aging-time on EX Series switches running JUNOS Release 9.4R1 and upgrade
to JUNOS Release 9.4R2 or later or downgrade to JUNOS Release 9.3R1 or earlier,
the switch will display configuration errors on booting up after the upgrade or
downgrade. As a workaround, delete the arp aging-timer aging-time configuration in
the system configuration stanza and reapply the configuration after you complete
the upgrade or downgrade.
The format of the file in which the Virtual Chassis topology information is stored was
changed in JUNOS Release 9.4. When you downgrade JUNOS Release 9.4 or later
running on EX4200 switches in a Virtual Chassis to JUNOS Release 9.3 or earlier,
make topology changes, and then upgrade to JUNOS Release 9.4 or later, the topology
changes you have made using JUNOS Release 9.3 or earlier are not retained. The
switch restores the last topology change you have made using JUNOS Release 9.4.
Switches
If you are upgrading from JUNOS Release 9.3R1 and have voice over IP (VoIP) enabled
on a private VLAN (PVLAN), you must remove this configuration before upgrading,
to prevent upgrade problems. VoIP on PVLAN interfaces is not supported in releases
later than JUNOS Release 9.3R1.
Upgrading from JUNOS Release 9.2 to Release 10.1 for EX Series Switches
For JUNOS Release 9.3 and later for EX Series switches, during the upgrade process,
the switch performs reference checks on VLANs and interfaces in the 802.1X
configuration stanza. If there are references in the 802.1X stanza to names or tags
of VLANs that are not currently configured on the switch or to interfaces that are not
218
■
configured or do not belong to the ethernet-switching family, the upgrade will fail. In
addition, static MAC addresses on single-supplicant mode interfaces are not supported.
CAUTION: If your Release 9.2 configuration includes any of the following conditions,
revise the configuration before upgrading to Release 10.1. If you do not take these
actions, the upgrade will fail:
■
Ensure that all VLAN names and tags in the 802.1X configuration stanza are
configured on the switch and that all interfaces are configured on the switch and
assigned to the ethernet-switching family. If the VLAN or the interface is not
configured and you try to commit the configuration, the commit will fail.
■
Remove static MAC addresses on single-supplicant mode interfaces. If they exist
and you try to commit the configuration, the commit will fail.
■
In an 802.1X configuration stanza, if authentication-profile-name does not exist
and you try to commit the configuration, the commit will fail.
■
In an 802.1X configuration stanza, broadcast and multicast MAC addresses are
not supported in a static MAC configuration. If they exist and you try to commit
the configuration, the commit will fail.
■
Support for static MAC bypass in single or single-secure mode has been removed.
If static MAC bypass exists and you try to commit the configuration, the commit
will fail.
■
In an 802.1X configuration stanza, the switch will not accept the option vrange
as an assigned VLAN name. If it exists and you try to commit the configuration,
the commit will fail.
■
Enabling 802.1X and the port mirroring feature on the same interface is not
supported. If you enable 802.1X and port mirroring on the same interface and
then attempt to commit the configuration, the commit will fail.
■
In an 802.1X configuration stanza, if the VLAN name or tag specified under dot1x
authenticator static does not exist and you try to commit the configuration, the
commit will fail.
■
If the MSTP configuration contains a VLAN (under protocols mstp msti msti-id)
that does not exist on the switch and you try to commit the configuration, the
commit will fail. Remove the VLAN from the MSTP configuration before you
perform an upgrade.
■
In the interfaces configuration stanza, if no-auto-negotiation is configured but
speed and link duplex settings are not configured under ether-options and you
try to commit the configuration, the commit will fail. If no-auto-negotiation is
configured under ether-options, you must configure speed and link duplex settings.
■
In the ethernet-switching-options configuration, if action is not configured for the
number of MAC addresses allowed on the interface (under secure-access-port
interface interface-name mac-limit in the CLI or in the Port Security Configuration
page in the J-Web interface), and you try to commit the configuration, the commit
will fail. You must configure an action for the MAC address limit before upgrading
from Release 9.2 to Release 10.1.
■
If you have configured a tagged interface on logical interface 0 (unit 0), configure
a tagged interface on a logical interface other than unit 0 before upgrading from
■
219
Release 9.2 to Release 10.1. If you have not done this and you try to commit
the configuration, the commit will fail. Beginning with JUNOS Release 9.3 for EX
Series switches, untagged packets, BPDUs (such as in LACP and STP), and
priority-tagged packets are processed on logical interface 0 and not on logical
interface 32767. In addition, if you have not configured any untagged interfaces,
the switch creates a default logical interface 0.
■
On EX4200 switches, if you have installed advanced licenses for features such
as BGP, rename the /config/license directory to /config/.license_priv before
upgrading from Release 9.2 to Release 9.3 or later. If the switch does not have
a /config/license directory, create the /config/.license_priv directory manually
before you upgrade. If you do not rename the /config/license directory or create
the /config/.license_priv directory manually, the licenses installed will be deleted
after you upgrade from Release 9.2 to Release 9.3 or later.
Switches
When you downgrade a Virtual Chassis configuration from JUNOS Release 10.1 to
Release 9.2 for EX Series switches, member switches might not retain the mastership
priorities that had been configured previously. To restore the previously configured
mastership priorities, commit the configuration by issuing the commit command.
Related Topics
220
■
■
■
■
■
■
■
page 217
JUNOS Documentation and Release Notes
For a list of related JUNOS documentation, see
http://www.juniper.net/techpubs/software/junos/ .
If the information in the latest release notes differs from the information in the
documentation, follow the JUNOS Release Notes.
To obtain the most current version of all Juniper Networks® technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
Juniper Networks supports a technical book program to publish books by Juniper
Networks engineers and subject matter experts with book publishers around the
world. These books go beyond the technical documentation to explore the nuances
of network architecture, deployment, and administration using the Junos operating
system (Junos OS) and Juniper Networks devices. In addition, the Juniper Networks
Technical Library, published in conjunction with O'Reilly Media, explores improving
network security, reliability, and availability using Junos OS configuration techniques.
All the books are for sale at technical bookstores and book outlets around the world.
The current list can be viewed at http://www.juniper.net/books .
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
[email protected], or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include
the following information with your comments:
■
Document name
■
Document part number
■
Page number
■
Software release version
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support
contract, or are covered under warranty, and need postsales technical support, you
can access our tools and resources online or open a case with JTAC.
■
JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.
■
Product warranties—For product warranty information, visit
http://www.juniper.net/support/warranty/.
■
221
■
JTAC Hours of Operation —The JTAC centers have resources available 24 hours
a day, 7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:
■
Find CSC offerings: http://www.juniper.net/customers/support/
■
Search for known bugs: http://www2.juniper.net/kb/
■
Find product documentation: http://www.juniper.net/techpubs/
■
Find solutions and answer questions using our Knowledge Base:
http://kb.juniper.net/
■
Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
■
Search technical bulletins for relevant hardware and software notifications:
https://www.juniper.net/alerts/
■
Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
■
Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool located at https://tools.juniper.net/SerialNumberEntitlementSearch/.
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
■
Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
■
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit
us at http://www.juniper.net/support/requesting-support.html.
If you are reporting a hardware or software problem, issue the following command
from the CLI before contacting support:
user@host> request support information | save filename
To provide a core file to Juniper Networks for analysis, compress the file with the
gzip utility, rename the file to include your company name, and copy it to
ftp.juniper.net:pub/incoming. Then send the filename, along with software version
information (the output of the show version command) and the configuration, to
[email protected]. For documentation issues, fill out the bug report form located at
https://www.juniper.net/cgi-bin/docbugreport/.
222
■
Revision History
15 February 2010—Revision 1, JUNOS Release 10.1R1
17 February 2010—Revision 2, JUNOS Release 10.1R1
13 May 2010—Revision 3, JUNOS Release 10.1R2
13 July 2010—Revision 4, JUNOS Release 10.1R3
17 November 2010—Revision 5, JUNOS Release 10.1R4
Copyright © 2010, Juniper Networks, Inc. All rights reserved.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or
otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed
to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347,
6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
■
223

Release Notes

Transcription

Similar documents

February 2016 Growth Spurts

Every Sport Needs A Star

OMNI-WiFi Recent Installation – Bayley`s Camping Resort

Juniper Networks M-series : Product Overview

www.posalux.com

Go to www.jiminypeak.com and click on Employee Login

Anaphylaxis to the Citrus Fruit Yuzu

Lead Manager Sell Sheet