Issues in JUNOS Software Release 9.5 for SRX-series Services Gateways

• Outstanding Issues in JUNOS Software Release 9.5 for SRX-series Services Gateways
• Resolved Issues in JUNOS Software Release 9.5 for SRX-series Services Gateways

Outstanding Issues in JUNOS Software Release 9.5 for SRX-series Services Gateways

Application Layer Gateways (ALGs)

• On SRX 210 devices, an SCCP call cannot be set up after disabling and enabling SCCP ALG. The call does not go through. [PR/409586]

Authentication

• 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 get deleted and will only age out. This behavior will not cause a security breach. [PR/309534]

Chassis Cluster

• Configuring an SRX-series device with set system process jsrp-service disable only on a primary node of the cluster causes the cluster to go into an incorrect state. [PR/292411]
• The SRX-series device will crash if you use the set system processes chassis-control disable command for 4 to 5 minutes and then enable it. Do not use this command on an SRX-series device in a chassis cluster. [PR/296022]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, 8 queue configurations are not reflected on the chassis cluster interface. [PR/389451]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, iflset functionality is not supported for aggregated interfaces like reth. [PR/391377]
• On SRX 210 devices in a chassis cluster, when you upgrade the nodes, sometimes the forwarding daemon might crash and get restarted. [PR/396728]
• On the SRX 210 Low Memory device in a chassis cluster, the firewall filter does not work on the reth interfaces. [PR/407336]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, snmpwalk on jnxJsSPUMonitoringObjectsTable in a cluster from the primary node shows information for only the local SPC installed in that node. Instead, it should show information about all the SPCs in the primary and secondary nodes. [PR/408261]
• On SRX 210 devices in a chassis cluster, the restart forwarding method is not recommended because when the control link goes through forwarding, restart forwarding causes disruption in the control traffic. [PR/408436]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices on failover, both the primary Routing Engine and secondary Routing Engine are sending SNMP traps. Only the primary Routing Engine should send SNMP traps. [PR/417782]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, the queue statistics are not correct after deletion and re-creation of an IFL or creation of a new IFL. IFL statistics are not cleared for 15 minutes after chassis-control is restarted. [PR/417947]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices in an active/active chassis cluster, when the fabric link fails and then recovers, services with a short time-to-live such as FTP ALG stop working. [PR/419095]
• On SRX 5600 devices in a chassis cluster, replay errors are seen on peer devices. [PR/422371]
• On SRX 210 High Memory devices in a chassis cluster, when the stress test is stopped, the primary H323 counters of Number of active calls should be 0, but 128 is incorrectly displayed. [PR/429560]
• On SRX 5800 devices, SNMP traps might not be generated for the ineligible-primary state with the current software design. [PR/434144]

Class of Service

• On an SRX-series device, class-of-service-based forwarding (CBF) is not working. [PR/304830]

Flow and Processing

• On an SRX-series device, 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 an SRX-series device, 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]
• Configuring the flow filter on SRX-series devices 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 SRX 210 and SRX 240 devices, broadcast TFTP is not supported when flow is enabled on the device. [PR/391399]
• On SRX 240 and SRX650 devices, tagged frames on an access port with the same VLAN tag are not getting dropped. [PR/414856]
• If an SRX 210 device receives more traffic than it can handle, Node1 either disappears or gets disabled. [PR/416087]
• On SRX 5600 devices, when the system is in an unstable state (for example, SPU reboot), NFS might generate residual.nfs files under /var/tmp, which can occupy the disk space for very long time. As a workaround, run request sys storage cleanup command to clean up when the system has low disk space. [PR/420553]
• On SRX 210 devices, dynamic VPN does not support the ability to automatically generate the routes when the radius server is used to assign the IP addresses. [PR/421137]

• On SRX650 devices, the input DA errors are not updated when packets are dropped due to MAC filtering on the following:

  • SRX 240
  • SRX 210
  • 16-port and 24-port GPIMs
  • SRX650 front-end port

    This is due to MAC filtering implemented in hardware.

    [PR/423777]

• On SRX 5800 devices, when VPN is not in use, the device will not generate the var/tmp/spu_kmd_init/ file, which is logged by Iked_cfg. This should not happen because it is not an error condition. As a result, disk space may be wasted over time. As a workaround, run the cp /dev/null /var/tmp/spu_kmd_init command from the shell to create this file. Also run request sys storage cleanup to clean up when the system has low disk space. [PR/425380]
• On SRX650 devices, continuous messages are displayed from syslogd when ports are in switching mode. [PR/426815]
• On SRX650 devices, the uplinks to the CPU can be exhausted and the system can be limited to 2.5 GB throughput traffic when the device is using similar kinds of source MAC addresses. [PR/428526]
• On SRX 240 and SRX650 devices, CLI help for the VLAN name under Interface vlan member and protocols xstp is not displayed properly. Instead, this message appears: mgd:unable to execute /usr/bin/vlanconfiginfo: No such file or directory. [PR/429018]
• On SRX650 devices, packet loss is observed when the device interoperates with an SSG20 with AMI line-encoding. [PR/430475]
• On SRX 3400 devices in combo mode, the firewall authentication Age and Access time remaining are displayed incorrectly as 0 and Infinite, respectively. This does not affect aging functionality. The authentication entry is aged out after the configured timeout. [PR/434985]
• On SRX 240 devices, when you configure the syslog hostname as 1 or 2, the device goes to the shell prompt. [PR/435570]
• On SRX650 devices, when you run scaling scripts of the scheduler, an nsd core file is generated. For example, when you are configuring 257 schedulers, the 257th scheduler (counting from 0) is not allocated. The ID 0 is considered invalid, and only 1 through 256 are valid IDs. [PR/437064]
• On SRX platforms running flow-based code, multiple flows with high traffic volumes to unknown destinations can cause the kernel to run out of buffer space. [PR/507137]

Hardware

• On an SRX 210 device, the MTU size is limited to 1518 bytes for the 1-port SFP Mini-PIM. [PR/296498]
• On SRX210 device, chassis Mini-PIMs LED’s do not go to the off state when the FPC is offline. [PR/299434]
• On an SRX 210 device in a chassis cluster, when you upgrade to the 9.5 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 SRX 210 devices 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. As a workaround, restart the Packet Forwarding Engine. [PR/401139]
• On an SRX 210 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 SRX 3400 and SRX 3600 devices, the minor alarm is not triggered when the central point or SPU session table is full. [PR/405990]
• On SRX 210, SRX 240, and SRX650 devices, after the device fragments packets, FTP over a GRE link might not perform properly due to packet serialization. [PR/412055]
• On SRX 240 devices, 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]

Infrastructure

• On an SRX 5600 device, when snmp mib walk is running, the snmpd core file is seen after 4 to 5 hours. [PR/387117]

Interfaces and Routing

• 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 an SRX 3400 device, the IPv6 transit counters on the reth interface show invalid value statistics. [PR/391407]
• 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 SRX 5600 and SRX 5800 devices, ping to far-end reth interfaces does not work for different routing instances. [PR/408500]
• On an SRX 3600 device, there might be VPN sync issues with IPsec SA. This happens when the secondary node reboots during primary node IPsec negotiation. [PR/413727]
• On SRX 5600 devices in a chassis cluster, the IPsec statistics counters display incorrect random numbers on the Routing Engine after a small amount of traffic is sent. [PR/415451]
• The SRX 5600 and SRX 5800 devices might get disabled when you configure more than 1000 reth logical interfaces. [PR/417391]
• On SRX 240 devices, drops in out-of-profile LLQ packets might be seen in the presence of data traffic even when the combined (data+LLQ) traffic does not oversubscribe the multilink bundle. [PR/417474]
• On an SRX 5800 device, running the clear security ike sa command does not delete the IKE SA. This happens when you try to delete the IKE SA by using the clear command after loading and overwriting the configuration. As a workaround, reboot the device. [PR/420162]
• On SRX 240 and SRX650 devices, when you are configuring the link options on an interface, only the following scenarios are supported:
  • 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-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 are not implemented in this release for T1/E1 GPIMs:

  • Line Loopback
  • FDL Payload Loopback
  • Inband Line Loopback
  • Inband Payload Loopback

    [PR/425040]

• On SRX650 devices, the kernel crashes when the link goes down during TFTP installation of the srxsme image. [PR/425419]
• On SRX 3400 and SRX 3600 devices in a chassis cluster, ESP authentication errors are seen while traffic is sent through 4000 site-to-site IPsec tunnels. [PR/426073]
• On SRX 3400 and SRX 3600 devices in a chassis cluster, Routing Engine kmd shows fewer tunnels than spu-kmd after the primary node is rebooted. [PR/426139]
• On SRX650 devices, during CoS tests, a core file is generated at pif_ds1_bert. This causes the CT1/E1-PIM FPC to go offline when the ifinfo core file is seen. The FPC does not recover even after interface-control/chassisd is restarted. [PR/426982]
• On SRX 3400 and SRX 3600 devices in a chassis cluster, tunnels are not evenly distributed to four kmd threads. [PR/427526]
• On SRX650 devices, doing an redundancy group 0 failover with 1000 ifls on the reth interface causes replication errors. As a result, ksyncd generates a core file. [PR/428636]
• On SRX 210 devices, the dialer interface goes down when the call is idle for a short interval because the Sierra ExpressCard is rejecting the redial attempts from the dialer. As a workaround, restart the flowd to restore the connection. [PR/428735]

• On SRX 240 devices, the following issues might be encountered when 1-Port SFP Mini-PIMs are used along with T1/E1 or serial Mini-PIMs:

  • Device timeout messages might be seen on I2C access.
  • T1/E1 or serial cards might not get detected.

    [PR/429906]

• On SRX 240 devices, the Mini-PIM LEDs glow red for a short duration (1 second) when the device is powered on. [PR/429942]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, after you configure rpf-check, a ping to that particular interface fails. [PR/431135]
• On SRX 240 devices, during the TFTP installation, if TFTP timeout occurs, then 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 SRX650 devices, configuring dual and quad T1/E1 framing at the chassis level takes no effect. [PR/432071]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, interface statistics on the st0 interface are not accurate. As a workaround, use the statistics on the security association (SA) to determine input and output bytes and packets. [PR/436857]
• On SRX650 devices, the Q-pic-large-buffer is not active. [PR/437389]
• On SRX 240 devices, the serial interface maximum speed in extensive output is displayed as 16384 Kbps instead of 8.0 Mbps. [PR/437530]
• On SRX 240 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 SRX 240 devices, the file installation fails on the right USB slot when both of the USB slots have USB keys attached. [PR/437563]
• On SRX 240 devices, when users swap the USBs after startup, the chassis-control subsystem might not respond to any chassis-related commands. As a workaround, avoid plug and play for the right USB slot. [PR/437798]
• On SRX 240 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 SRX 210 and SRX 240 devices, when autoinstallation is configured to run on a particular interface, the DHCP client is run on that interface. The device tries to get the configuration file from the TFTP server. During this process, the autoinstallation status might get into the configuration acquisition state because it cannot reach the UDP port through which the device sends read request to the TFTP server. The issue might be seen in packet mode or flow mode. [PR/438181]
• On SRX 210 devices, the E1Mini-PIM interface flaps and traffic does not go through the link after restarting the forwarding during Transit traffic. [PR/441312]

Intrusion Detection and Prevention (IDP)

• On SRX 5600 and SRX 5800 devices, when you downgrade to the 9.2 software image, the IDP policy compilation fails, takes an indefinite time to finish, or becomes slow due to IDP policy cache.

  Workaround:

  1. Stop the idpd daemon by using the set system processes idp-policy disable command and commit the configuration.
  2. Delete all policy cache files in the /var/db/idpd/db folder.
  3. Log on to the SRX-series as root user, and use the following UNIX commands: rm–f /var/db/idpd/db/dfa* /var/db/idpd/db/pcre*.
  4. Reboot the system.
  5. Enable the idpd daemon by using the delete system processes idp-policy command and commit the configuration.
  6. Ensure that the cache files are regenerated and are located in the /var/db/idpd/db folder.

  [PR/300428]

• On SRX 5600 devices, the licensing service currently does not support the different traceoption flags (config, events, all) that are available through the configuration setup. The current default behavior is to trace all. This is the reason that the tracelog file will contain all log information exported by the daemon. [PR/310783]
• On SRX-series devices, the IDP status command show security idp status displays an error message when the device is processing heavy data traffic. [PR/388048]
• On SRX-series devices, the IDP status command show security idp status might fail when processing heavy traffic. As a result, IDP flow, session statistics, and packet statistics do not match firewall statistics. [PR/389501]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, HTTPS sessions with higher data transaction sizes fail due to heavy CPU usage, which results in the failure of new connections. [PR/390308]
• The SRX 210 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 SRX 210, SRX 3400, SRX 3600, SRX 5600, and SRX 5800 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 SRX 210 devices, during attack detection, multiple attacks get detected. This happens when the IDP policy contains rules that have the match criteria for the same attacks. Error/warning messages do not appear during policy compilation. [PR/414416]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, the idp-policy subsystem is not responding to management requests. Sometimes when policy changes are committed, some of the operational commands might not be successful. Until policy changes are effective, users might see errors. [PR/432026]
• On SRX 5800 devices, IDP is not officially supported in an active/active chassis cluster configuration. The user must disable the IDP configuration when the devices are configured in an active/active chassis cluster. [PR/432252]

J-Flow

• SRX 3400, SRX 3600, SRX 5600, and SRX 5800 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 SRX 3400, SRX 3600, SRX 5600, and SRX 5800 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]

J-Web

• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 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 SRX 210 Low Memory 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 System Identification panel. [PR/390887]

• On SRX 210, SRX 240, and SRX650 devices, in J-Web, the complete content of the ToolTipis not displayed in the Chassis View. As a workaround, drag the Chassis Viewer image down to see the complete ToolTip. [PR/396016]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, in J-Web, when you right-click Configure Interface on an interface in Chassis View, the Configuration>Quick Configuration>Interface page is displayed. [PR/405392]
• On SRX-series devices, the CLI Terminal feature is not working in J-Web over IPv6. [PR/409939]
• On SRX-series devices, the Ajax calls need to be optimized and should be in synchronization with the existing configuration screens (STP, GVRP, and IGMP-Snooping). [PR/422523]
• On SRX 210 and SRX 240 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 content. This issue occurs when the computer is set to a low resolution. As a workaround, set the computer resolution at 1280 x 1024. [PR/423555]
• On SRX 240 devices, on the J-Web monitor interface page, it is not possible to generate an interface graph of two interfaces that are on two different pages of the interface summary table. [PR/429572]

Management and Administration

• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 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. Nonavailability of such information without login results in the failure of the snmpwalk on the backup/secondary node. As a workaround, use a master-only IP address across the cluster. This way, you can query a single IP address and that IP address will always be the master for redundancy group 0. [PR/413719]

• On an SRX 210 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

    [PR/414663]

Power over Ethernet (PoE)

• On SRX 210 and SRX 240 devices in a chassis cluster, PoE configuration and operational commands operate on only one chassis. The PoE interfaces of the other chassis are not configurable and not displayed in operational command output even though the data ports are recognized. [PR/415174]
• On SRX 240 and SRX 210 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 SRX 210 and SRX 240 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 SRX 210 and SRX 240 devices, the output for the show poe telemetries command shows the telemetry data in chronological order. This should be changed to reverse-chronological (most recent data first). [PR/429033]
• On SRX 210 and SRX 240 devices, the class-4 powered device does not get powered on when PoE is configured to operate in Class management mode. [PR/437406]
• The SRX 210 and SRX 240 devices, the powered device takes more time than what is specified by the standards to power off when operating under overload conditions. [PR/437416]
• On SRX 240 and SRX 210 devices, the last powered device will not power on if the allocated power becomes equal to the power limit on the device. Power allocated must always be less than the power limit. For example, on the SRX 240 device, the powered devices cannot be configured such that allocated power becomes 150 W, even though it is possible to allocate the power up to 149.8 W. [PR/437792]

Security

• The SRX-series devices do not support egress filter-based forwarding (FBF). [PR/396849]
• On SRX 210, SRX 3400, SRX 3600, SRX 5600, and SRX 5800 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]

System

• On SRX-series devices, when the J-Web session is terminated from the CLI, error and warning messages related to J-Web appear in the logs. [PR/311181]

Unified Threat Management (UTM)

• 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. [PR/303584]
• The express antivirus initial database download fails due to the slow start of the router interface. To get a proper update, you can either wait until the next auto-update or manually update the database by using the CLI. [PR/388535]
• When the content filtering message type is set to protocol-only, customized messages appear in the log file. [PR/403602]
• 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 SRX 240 and SRX650 devices, Outlook Express is sending infected mail (with an EICAR test file) to the mail server (directly, not through DUT). Eudora 7 is using the IMAP protocol to download this mail (through DUT). Mail retrieval is slow, and the EICAR test file is not detected. [PR/424797]
• On SRX 3400, SRX 3600, SRX 5600, and SRX 5800 devices, transparent mode does not support UTM and IDP policy. The UTM and IDP options should be hidden from the policy application-services list. [PR/427921]
• 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 SRX 240 devices, FTP download for large files (larger than 4 MB) does not work in a two-router topology. [PR/435366]
• On SRX 210, SRX 240, 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 SRX 240 devices, if the device is under UTM stress traffic for several hours, users might get the following error while issuing UTM command:

  the utmd subsystem is not responding to management requests.

  As a workaround, restart the utmd process. [PR/436029]

VPN

• On an SRX-series device, the shared IKE limit does not work in remote access. [PR/288551]
• On SRX 210 High Memory devices, certification-based VPN IKE negotiation fails sometimes if the user uses the PKI wildcard as the local ID. As a workaround, reboot the device. [PR/411398]
• On SRX 210 and SRX 240 devices, when you uninstall Juniper Access Manager (JAM), the client prompts for a reboot. Ignore the prompt. It is caused by a reboot flag in some JAM files that have not been removed from your system. All the JAM executables have been removed. [PR/428315]

Resolved Issues in JUNOS Software Release 9.5 for SRX-series Services Gateways

The following issues from JUNOS Release 9.5 R3 have been resolved in this release. The identifier following the description is the tracking number in our bug database.

Chassis Cluster

• On SRX 210 devices, existing FTP data transfer failed because the primary node of the device chassis cluster was rebooted or powered off. [PR/429296: This issue has been resolved.]

Interfaces and Routing

• On SRX650 devices, resource errors were seen in the show interface extensive command output during bidirectional traffic on the CT/E1 GPIMs. [PR/430181: This issue has been resolved.]

J-Web

• On SRX-series devices, on the J-Web spanning-tree configuration page, the Edit interface/msti window did not save the data before committing the configuration. [PR/433506: This issue has been resolved.]

Power over Ethernet (PoE)

• On SRX 240 series devices in a chassis cluster (active-active mode) and policy based IPsec VPN configured together, ftp put (in port mode) command failed after a RG2 (egress RG) manual failover. [PR/438590: This issue has been resolved.]

Related Topics

• New Features in JUNOS Software Release 9.5 for SRX-series Services Gateways
• Known Limitations in JUNOS Software Release 9.5 for SRX-series Services Gateways
• Errata in Documentation for JUNOS Software Release 9.5 for SRX-series Services Gateways
• Unsupported CLI Statements and Commands in JUNOS Software Release 9.5 for SRX-series Services Gateways