■
On SRX Series devices in a chassis cluster, configuring the
set system process
jsrp-service disable
command only on the primary node causes the cluster to go
into an incorrect state. [PR/292411]
■
On SRX Series devices in a chassis cluster, using the
set system processes
chassis-control disable
command for 4 to 5 minutes and then enabling it causes
the device to crash. Do not use this command on an SRX Series device in a
chassis cluster. [PR/296022]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, 8-queue configurations
are not reflected on the chassis cluster interface. [PR/389451]
■
On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the
iflset
functionality
is not supported for aggregated interfaces like
reth
. [PR/391377]
■
On an SRX210 device in a chassis cluster, when you upgrade the nodes,
sometimes the forwarding process might crash and get 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:
■
Back-to-back redundancy group 0 failover
■
Back-to-back primary node reboot
144
■
Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
JUNOS 10.1 Software Release Notes
