•
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the iflset functionality is
not supported for aggregated interfaces like reth. [PR/391377]
•
On an SRX210 device in a chassis cluster, sometimes the reth interface MAC address
might not make it to the switch filter table. This results in the dropping of traffic sent
to the reth interface. As a workaround, restart the Packet Forwarding Engine.
[PR/401139]
•
On an SRX210 device in a chassis cluster, the restart forwarding method is not
recommended because restart forwarding on primary node will cause all RGs failover
to other node. [PR/408436]
•
On SRX5800 devices, SNMP traps might not be generated for the ineligible-primary
state. [PR/434144]
•
On SRX3400, SRX3600, SRX5600, and SRX5800 devices in chassis cluster
active/active mode, the J-Flow samplings do not occur and the records are not exported
to the cflowd server. [PR/436739]
•
On SRX240 Low Memory and High Memory devices, binding the same IKE policy to a
dynamic gateway and a site-to-site gateway is not allowed. [PR/440833]
•
On SRX650 devices, the following message appears on the new primary node after a
reboot or an RG0 failover:
WARNING: cli has been replaced by an updated version:
CLI release 9.6B1.5 built by builder on 2009-04-29 08:24:20 UTC
Restart cli using the new version ? [yes,no] (yes) yes
[PR/444470]
•
On SRX240 devices, the cluster might become 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 SRX3600 devices, track IPs on the secondary node remain unreachable after you
disable and enable the corresponding reth’s primary and secondary child interfaces
[PR/488890
•
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, LACP does not work in
Layer 2 transparent mode. [PR/503171]
•
During a manual failover, a system crash might occur if the nodes have not completely
recovered from a previous failover. To determine if a device is ready for repeated
failovers, perform these recommended best-practice steps before doing a manual
failover.
The best-practice steps we recommend to ensure a proper failover are as follows:
•
Use the show chassis cluster status command to verify the following for all
redundancy groups:
•
One node is primary; the other node is secondary.
•
Both nodes have nonzero priority values unless a monitored interface is down.
Copyright © 2010, Juniper Networks, Inc.144
JUNOS OS 10.4 Release Notes
To Next Page
Loading...