Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers

• Outstanding Issues In JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
• Resolved Issues in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers

Outstanding Issues In JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers

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.

Application Layer Gateways (ALGs)

• On some SRX650 devices, maximum SCCP concurrent calls cannot be made under stress conditions as some calls get dropped. [PR/490839]
• On SRX Series devices, SIP server protection does not work. The set security alg sip application-screen protect deny command does not work. [PR/512202]
• On SRX240 Low Memory and SRX650 devices, after deactivating xSTP over LAG, ports get into blocked state and stop switching traffic. As a workaround, reboot the device. [PR/515559]
• On SRX5600 devices in chassis cluster, sometimes RTSP connection might break during failover when the chassis cluster probe is sent successfully. [PR/516023]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the SIP ALG is not supported in JUNOS Release 10.2. By default, all ALGs are disabled in JUNOS Release 10.2. [PR/527446]

AppSecure

• When downloading the predefined application identification signature database on SRX3400, SRX3600, SRX5600, and SRX5800 devices, the new database will merge with the existing database instead of replacing it. If duplicate entries in the order and port-mapping signature fields exist, there might be issues in detecting applications defined by those signatures. If a duplicate port-mapping value exists, new signature database downloads will fail with the status output: AI installation failed! Attack DB update failed. The /var/log/appidd log will show: port xxx is specified more than once (xxx will equal the port-mapping value that is duplicated). If this occurs, use the following procedure to remove and re-install the latest application identification signature database.

  To uninstall the predefined application identification signature database for JUNOS Software application identification and IDP application identification:

  user@host> request services application-identification uninstall

  Note: The uninstall command will only remove the application identification portion of the IDP signature database.

  To download and install the latest predefined application identification signature database for JUNOS Software application identification:

  user@host> request services application-identification download

  To download the application identification and IDP signature database for IDP:

  user@host> request security idp security-package download

  To install the application identification and IDP signature database for IDP:

  user@host> request security idp security-package install

[PR 521482/518183]

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

AX411 Access Point

• 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 SRX 650 devices, when an access point is part of 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 AX411 Access Points, an access point might not synchronize with the newly associated configuration (by changing or swapping the MAC address) and also might not join the changed cluster when it is associated to a new config block in the WLAN access point configuration. As a workaround, deactivate and activate the access point using the following CLI commands:
  #deactivate wlan access-point <ap-name>
  #commit
  #activate wlan access-point <ap-name>
  #commit

  [PR/504581]

Chassis Cluster

• 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]
• 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 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 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

    [PR/414663]

• If an SRX210 device receives more traffic than it can handle, node 1 either disappears or gets 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 SRX3400 and SRX3600 devices in a chassis cluster, ESP authentication errors occur while traffic is sent through 4000 site-to-site IPsec tunnels. [PR/426073]
• On SRX650 and J Series devices, doing a redundancy group 0 failover with 1000 logical interfaces on the reth interface causes replication errors. As a result, the ksyncd process generates a core file. [PR/428636]
• 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 and SRX650 devices in chassis cluster active/active preempt mode, the RTSP session breaks after a primary node reboot and preempt failover. The following common ALGs will be broken: RSH, TALK, PPTP, MSRPC, RTSP, SUNRPC, and SQL. [PR/448870]
• On SRX240 devices, the cluster might get 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 SRX5600 and SRX5800 devices in a chassis cluster whenever the reth interface with static MAC address is configured, the ping operation fails from the directly connected device to the chassis cluster. [PR/455051]
• 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 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.2. [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.2R1. [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.2 do not work. [PR/483485]
• On SRX5600 devices with an active/active chassis cluster configuration, under stress conditions, memory pointers of the appid module could be inappropriately assigned. This might cause memory corruption. [PR/483522]
• On SRX3600 devices, after you disable and enable the secondary node track, the IP status remains unreachable. [PR/488890]
• On SRX5600 and 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.2R1. [PR/491834]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, although there is no limit by software, the maximum number of bundles that include aggregated Ethernet ae and redundant Ethernet reth interface bundles is 128. [PR/497994]
• 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]
• 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 we recommend to ensure a proper failover is 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 non-zero priority values unless a monitored interface is down.
  • Use the show chassis fpc pic-status command to verify that the PIC status is Online.

  • Use the show pfe terse command to verify that the Packet Forwarding Engine status is Ready and to verify following:

    • All slots on the RG0 primary node have the status Online.
    • All slots on the RG0 secondary node, except the Routing Engine slots, have the status Valid.

  [PR/503389 and PR/520093]

• On SRX100 High Memory devices, on sending 200 plain RTSP connections, cluster will enter into split-brain mode and traffic redundancy will be affected. [PR/508084]
• On SRX5600 and SRX5800 devices, kernel crashes occur during LICU from JUNOS Release 9.6R3 to JUNOS Release 10.2B2 along with vmcore and ksyncd core files, which interrupts the traffic. [PR/511973]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices in L2 chassis cluster, when there is too much DNS traffic through the device core dump occurs. [PR/512888]
• J4350 devices reboot continually when working under heavy src-pat NAT traffic. [PR/518085]
• On SRX650 devices in chassis cluster, a binding is created both on the forward node and the active node. When all the sessions of this binding are over, the binding is freed on the active node, but the same binding still exists on the forward node. [PR/520660]
• On SRX650 devices in chassis cluster, ping packets sent from the forward node to the active node are dropped intermittently. [PR/520669]
• On J4350 devices in chassis cluster, statistics are not incremented on the IP sweep screen. [PR/527354]
• On SRX5600 devices in an active/active chassis cluster, RG1 and RG2 on preempt mode, reboot node 0, and RPC traffic are blocked. [PR/527771]

Class of Service (CoS)

• 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-sized (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]

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]

Flow and Processing

• 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 SRX240 devices, traffic flooding occurs when multiple multicast IP group addresses are mapped to the same 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 because of MAC filtering implemented in hardware.

  [PR/423777]

• 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 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 an SRX5800 device with a 1-Gbps IOC, when more than 10 ports per port module are used, intermittent packet loss occurs because of oversubscription. As a workaround, reboot the SRX5800 device. [PR/433209 ]
• 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 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 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 bytes packet size T3 link 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 SRX240 PoE and J Series devices, packet drops are seen on the lsq interface when transit traffic with a frame length of 128 bytes is sent. [PR/455714]
• 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]
• 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 time slots) should not be bundled under one ML bundle. [PR/464410]
• On SRX650 devices, after the primary reboot, transit traffic takes many seconds to resume as GARP does not get through. [PR/474953]
• 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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, input packets and bytes counter shows random value both in traffic statistics and IPv6 transit statistics, when VLAN tagging is added or removed from the IPv6 address configured interface. [PR/489171]
• On SRX5600 devices, to guarantee the MAC filter number is 1024, configure the reth or ae link speed to 1G by using the set interfaces reth2 redundant-ether-options link-speed 1g command. [PR/498998]
• On SRX5600 and SRX5800 devices, LICU takes nearly 50 minutes because of a read-only file system error. Initially the secondary node will not come out of issu window. You need to manually abort LICU on initial primary node by running the request chassis cluster in-service-upgrade abort command. [PR/508704]
• On SRX100, SRX210, SRX240 and SRX650 devices, 802.1x accounting statistics are not sent properly to the accounting server. [PR/509035]
• On SRX Series and J Series devices, system log messages about interactive commands to the system log server do not work. [PR/511110]
• On SRX5600 devices, objcache memory leaks at the Xlate ctx pool after a long stress test. [PR/513112]
• On SRX Series devices, the software upload and install package will not show a warning message when there are pending changes to be committed. [PR/514853]
• On SRX100 Low Memory devices, if the device is running in transparent mode and flow trace is enabled, IPv6 packets will cause a system crash. [PR/525326]

Hardware

• On SRX210 devices, the MTU size is limited to 1518 bytes for the 1-port SFP Mini-PIM. [PR/296498]
• On SRX210 devices, the system takes between 2 and 5 minutes to initialize. [PR/298635]
• 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]
• 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 SRX650 devices, the 16-port Gigabit Ethernet switch GPIM is incorrectly labeled as XGPIM. This switch is a double-high XPIM that will operate only in slots 2 to 4 or 6 to 8, connecting to the 20-gigabit connector in slots 2 or 6, respectively. [PR/444511]
• On SRX210 Low Memory devices, 3G AC402 Live Network Card activation gets timed out. [PR/451493]
• On SRX650 devices, when both fiber and copper cables are plugged into the 2-port 10-Gigabit Ethernet XPIM, the interface will not come up according to the configured media type. As a workaround, plug the cable corresponding to the configured media type into the 2-Port 10-Gigabit Ethernet XPIM to make the interface come up. [PR/492750]
• On SRX650 devices, when the 2-Port 10-Gigabit Ethernet XPIM is operating in fiber mode and the link speed is set to 1000 megabits (Mb), the data transmission is not taking place properly. [PR/498016]
• On the SRX650 devices, the interfaces links on the 2-port 10-Gigabit Ethernet XPIM configured with media type copper do not come up properly. As a workaround, restart the 2-Port 10-Gigabit Ethernet XPIM for links. [PR/501421]
• On SRX650 devices, when 10-Gigabit Ethernet traffic is transmitted through a port on the 2-Port 10 Gigabit Ethernet XPIM, the throughput received on the other port is only 1.4 Gbps. [PR/503613]

Infrastructure

• 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 devices with BIOS Version 080011 and on the J2320 and J2350 devices 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]

Installation

• On SRX100, SRX210, SRX240 or SRX650 devices with 1GB storage flash, on usage of the file copy command to copy the JUNOS package from ftp://<path> to a local directory you can get a message saying the file system is full. Please do not use the file copy command to get JUNOS package for software upgrade.

  The file copy command copies the JUNOS package as a temporary file in/cf/var/tmp and then copies the file with package name in local directory under /cf/var partition. This means a JUNOS package of size X needs 2X space in /cf/var partition. For example, a JUNOS package of size 197MB will need 394MB whereas /cf/var partition is less than 350MB on a 1G storage flash. Hence,file copy command will fail. [PR/526030]

Integrated Convergence Services

The following issues currently exist in SRX210 and SRX240 devices with Integrated Convergence Services:

• 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]

Interfaces and Routing

• 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 J2320 devices, when you enable the DHCP client, the default route is not added to the route table. [PR/296469]
• 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:
  • 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]

• On J4350 devices, multicast traffic is not received when the source and the receiver are connected to same PE routers. [PR/429130]
• 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 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]

• 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 (ML) bundle during bidirectional traffic with Multilink Frame Relay (MFR). [PR/445679]
• On SRX Series devices, If you configure attributes of an interface unit under both the [interfaces] and the [logical-router logical-router-name interface] hierarchies, only the configuration at the interfaces level will take effect. [PR/447986]
• On SRX Series and J Series devices, PIM and DVMRP does not work on IRB. [PR/448208]
• On SRX240 Low Memory devices and SRX240 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 (MFR). [PR/453289]
• On SRX210 PoE devices, the ATM interface on G.SHDSL interface will not go down when the interface is disabled through the disable command. [PR/453896]
• 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 DSLAM. [PR/459554]
• On J Series devices, tail drops are seen on a bundle for traffic with a bigger packet size and smaller fragmentation threshold. [PR/461417]
• On SRX100 and SRX200 devices with 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 IRB interface. As a workaround, enable IGMP snooping to use IGMP over IRB interfaces. [PR/492564]
• On SRX210 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 because of no ATM connection. [PR/493099]
• On SRX Series devices, 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 SRX210 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 SRX210 High Memory devices, the GRE tunnel session is not created properly if the tunnel outgoing interface takes a long time to come up. On T1/E1 interfaces of SRX100, SRX210, SRX240, and SRX650 devices, traffic through the GRE tunnel might not work. As a workaround, first create the physical interface and commit the configuration and then create a GRE tunnel configuration. [PR/497864]
• On SRX100, SRX210, SRX240, and SRX650 devices, whenever radius-server is configured under profile option radius server is marked as dead permanently if radius times out. As a workaround, configure radius-server outside the profile option under access option. [PR/503717]
• On SRX210 and SRX240 devices, when you activate or deactivate the ATM interface for the VDSL PIM inserted on slots two, three, or four, it might result in a flowd crash due to a bug in the VDSL driver. This problem might not be noticed on SRX210 devices. [PR/505347]
• On SRX5600 and SRX5800 devices, load balance does not happen within the aggregated Ethernet (ae) interface when you prefix the length with /24 while incrementing the dst ip. [PR/505840]

Intrusion Detection and Prevention (IDP)

• 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 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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, if you want to change to maximize-idp-sessions 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, 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 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.2 (Layer 2 access-regular mode) is rolled back to the JUNOS Release 9.6 image, the DUT comes up in JUNOS Release 9.6 with Layer 2 access-regular mode, which was not supported in JUNOS Release 9.6. [PR/469069]
• On SRX Series devices, the maximum supported sessions count is not displayed when you run the show security flow session idp summary command. [PR/503721]
• On SRX3600 devices, packet logging with time binding attacks does not work. [PR/511992]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when the number of attacks are more, the show security idp attack table displays the following error:

  “error: Failed to fetch data from data plane"

  "error: Reason: Message too long"

  [PR/521200]

• On SRX5600 devices, when using 4096 bit SSL private key for IDP HTTPS traffic processing, the watchdog aborts the flowd process and reboots the SPC. This is primarily because of the watchdog timer expiration. The IDP function takes a long time to decrypt the session when you use a 4096 bit key.

  The SSL function is known to take exponentially large amount of time when the key size is increased. While key size of 1024 bits and 2096 bits are ok to process, as these take processing time which are below the watchdog threshold; the key size of 4096 bits should not be used when sending stress traffic. Also IDP uses SSL hardware for <= 1024 bit keys. The throughput is much higher for the traffic using <= 1024 bit SSL private keys. [PR/524452 ]

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when packet-logging functionality is configured with higher value of pre-attack configuration parameter, the resource utilization increases proportionally and might impact the performance. [PR/526155]
• On SRX3400 devices, the packet-logging functionality is not supported in dedicated-equal mode in JUNOS Release 10.2R1, all other modes of operation are supported. Support in dedicated-equal mode will be available in a subsequent maintenance releases. [PR/526252]
• On SRX3400 devices, if you have your application identification configuration under config-groups (for example, set groups global/re0/re1 service application-identification <*>), then committing the configuration might cause the application identification RE daemon to core at /var/tmp/appidd.core.*. While the commit process will not be affected by this core, we strongly suggest that you do not have your application identification configuration under config-groups. [PR/527887]

J-Flow

• 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]

J-Web

• 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 SRX Series devices, when the user tries to associate an interface to GVRP, a new window appears. This new window shows multiple move-left and move-right buttons. [PR/305919]
• 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]
• 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 an SRX5600 device, when you click OK or Cancel from the IPS/Exempt rule configuration page, it takes a long time to go to the next page when the Internet Explorer IE browser is used. The slow response is due to predefined attacks, attack group XML data fetching, and the way Internet Explorer IE refreshes the page. As a workaround, use Firefox 3.5 or later. [PR/449017]
• 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 SRX Series devices, in J-Web the left-side menu items and page content might disappear when Troubleshoot is clicked twice. As a workaround, click the Configure or Monitor menu to get back the relevant content. [PR/459936]
• 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 SRX100, SRX210, SRX240, SRX650, and J Series devices, in J-Web configuration for the routing feature, if you enter double quotation marks in the text boxes that accept characters (for example, protocol name, filename, and description), then you cannot delete the data with double quotation marks through J-Web. As a workaround, you can use the CLI to introduce another backslash, which removes the double quotation marks from the data. [PR/464030]
• 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) does not display the available flags (tracing parameters). As a workaround, use the CLI to view the available flags. [PR/475313]
• 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. To view the results, navigate to page 1 manually. [PR/476338]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the entry registered into RIB is not shown in J-Web. [PR/483885]
• On SRX210, SRX240, SRX650 and J Series devices, in the J-Web interface, Monitor>Switching>Spanning Tree shows a null page when Spanning Tree Protocol is not running on the device. [PR/484202]
• 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 SRX3400 devices in a chassis cluster, the predefined attacks list will also be loaded. [PR/488607]
• 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 SRX and J Series devices, in the J-Web interface, move/edit button is not working for exempt rulebase on IDP Policy configuration page. As a workaround, use theedit/move button on Configuration>Security>Policy>IDP Policies page for edit or prioritize the rules configured. [PR/503451]
• On SRX Series devices, in the J-Web interface, there is no support to change the T1 to E1 interface and vice versa. As a workaround, use the CLI to convert from T1 to E1 and vice versa. [PR/504944]
• On SRX Series devices, in the J-Web interface, show or compare JUNOScript RPC are emitting some unnecessary debug messages because of some commit options that have been disabled. [PR/514540]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, in the J-Web interface, the NAT incoming table submenu is missing from the NAT Menu of Monitor page. [PR/522255]

Management and Administration

• On SRX3400 and SRX3600 devices, a minor alarm is not triggered when the central point or SPU session table is full. [PR/405990]
• 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 SRX Series and J Series devices with session-init and session-close enabled, you should not clear sessions manually when too many sessions are in status "used". [PR/445730]
• On SRX5600 and SRX5800 devices, data path debug trace messages are 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]

Network Address Translation (NAT)

• On SRX240 High Memory devices in a chassis cluster, the secondary node can go to DB> mode when there are many policies configured and TCP, UDP, and ICMP traffic matches the policies. [PR/493095]
• On SRX650 devices, NAT trap is not supported in JUNOS Release 10.2 because of a newly introduced SNMP trap mechanism. [PR/493446]
• 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.2. 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]

• On SRX650 devices, persistent NAT binding for wildcard ports is not supported in chassis cluster Z-mode because the backup session cannot be synchronized from active node. [PR/513765]
• On SRX Series devices, Remote Procedure Call (RPC) does not work with source NAT configuration. [PR/515455]
• On SRX5600 devices, interface NAT port allocation or release fails in overflow mode. [PR/516146 ]
• On SRX3400 and SRX3600 devices, if you change the configuration from source pool NAT to static NAT when there are entries in the incoming table, those entries will contain unrecognized characters. [PR/517500]
• On SRX3600 devices, when there is source pool overflow NAT, the phone might have multiple entries in the incoming-table. [PR/519137]
• On SRX5600 and SRX5800 devices, the incoming table does not appear when you run the show security nat incoming-table command. [PR/520417]
• On SRX3400 devices, when you configure and delete destination, source, and static NAT, the nsd module has a memory leak. If you configure and delete the 8192 destination, 8192 source, and 8192 static NAT rule sets each with 1 rule more than about 20 times, it will cause different configurations on the Routing Engine and Packet Forwarding Engine. As a workaround, do not configure and delete the major configurations many times. If you need to configure and delete the major configuration, wait about 1 minute after every commit operation. [PR/521599]
• On SRX3400, and SRX3600 devices, if SIP proxy with a nonstandard SIP source port (5060) is located outside the firewall, the inbound call might experience a delay of several seconds in all source NAT modes. [PR/526808]

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 PoE devices managing AX411 Access Points, the device’s 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 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 Access Point. This might be due to the DHCP default gateway not being set. [PR/468090]
• On SRX210 PoE devices managing AX411 Access Points, traffic of 64 bytes at speed more than 45 megabits per second (Mbps), might result in loss of keepalives and reboot of the AX411 Access Point. [PR/471357]
• 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]

Security

• 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]

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]

Unified Threat Management (UTM)

• 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 large files (>4 MB) 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 when using a UTM command:

  the utmd subsystem is not responding to management requests.

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

Upgrade

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if you are running a previous JUNOS release and are already using more than 70 percent of the memory on your device, do not upgrade to JUNOS Release 10.2 without first adding more memory to your device. New functionality in JUNOS Release 10.2 might use more memory, meaning that you might run out of memory with a configuration that worked on a previous release. [PR/526181]
• Low-impact ISSU chassis cluster upgrades are not supported in JUNOS Release 10.2R1. ISSU upgrade to 10.2R1 might cause loss of configuration. In order to upgrade to 10.2R1, use the normal upgrade procedure described in JUNOS Software Installation and Upgrade Guide (http://www.juniper.net/techpubs/en_US/junos10.1/information- products/topic-collections/software-installation-and-upgrade-guide/topic- 44670.html#jd0e3432) . [PR/526599 and PR/526829]

USB Modem

• On SRX100, SRX210, SRX240, and SRX650 devices, when you restart fwdd at the dial-out side, the umd interface goes down and the call never gets connected. As a workaround, disable the dialer interface and restart the forwarding daemon. Enable the dialer interface when the forwarding daemon is up and running. As a result, the dial-out side reconnects with the dial-in side successfully.

  Perform the following steps:

  1. Disable the dialer interface:

     root@noky# set interfaces dl0 disable

     root@noky# commit

  2. Restart the forwarding daemon:

     root@noky# run restart forwarding Forwarding Daemon started, pid 1407

     root@noky# delete interfaces dl0 disable

     root@noky# commit

  3. Enable the dialer interface:

     root@noky# delete interfaces dl0 disable

     root@noky# commit

  [PR/480206]

• 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 Services Gateways with Integrated Convergence Services, when you have USB modem configurations and you remove the USB modem from USB port 1, the device reboots. [PR/491777]
• On SRX100, SRX210, SRX240, and SRX650 devices, the call terminates if you remove and insert a USB modem. [PR/491820]
• 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]

Virtual LANs (VLANs)

• 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]
• 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 SRX210, SRX240, and SRX650 devices, you cannot configure VLAN ID 4093 on 1-Port SFP Mini-PIM interfaces because it is an internal reserved VLAN ID. [PR/515741]

VPNs

• 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 SRX100, SRX210, SRX240, and SRX650 devices, Remote Procedure Call (RPC) does not work with policy VPN. The root cause of the problem is that VPN tunnel information is not set when resources are created and when uuid is not in the uuid_2_oid table, the ALG should not open a pinhole. [PR/504576]
• On SRX100, SRX210, SRX240, and SRX650 devices, Routing Engine level redundancy for dynamic VPN fails because the tunnels need to renegotiate after RG0 failover. [PR/513884]
• On SRX100, SRX210, SRX240, and SRX650 devices, the dynamic VPN server always pushes the last configured dynamic client configuration to the client. If the VPN configuration bound to this dynamic VPN client is not bound to a policy, IKE negotiation will fail when you try to connect to the server. [PR/514033]
• On SRX100, SRX210, SRX240, and SRX650 devices, the dynamic VPN client does not get downloaded if there is not enough space in the /jail/var directory in the dynamic VPN server. [PR/515261]
• On SRX100, SRX210, SRX240, and SRX650 devices, IKE negotiation fails when an IKE ID longer than 31 bytes is configured for dynamic VPN. [PR/523796]

WLAN

• On SRX Series devices, when WLAN configuration is committed, it takes a while before the configuration is reflected on the access point, depending on the number of virtual access points and the number of access points connected. [PR/450230]
• 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]

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.2 for SRX Series Services Gateways and J Series Services Routers

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

Chassis Cluster

• On SRX210 device in a chassis cluster, when you upgraded to the latest software image, the interface links did not come up and were not seen in the Packet Forwarding Engine. [PR/399564: This issue has been resolved.]
• On SRX100 devices, after primary node reboot and cold synchronization were finished, the chassis cluster auth session timeout age and application name could not be synchronized with the chassis cluster peers. [PR/460181: This issue has been resolved.]
• On J Series devices in chassis cluster, after the PPTP connection was created, the DUT crashed when you rebooted the primary node and when the primary node was in standby status. [PR/509608: This issue has been resolved.]

Flow and Processing

• On SRX5600 devices, equal-cost multipath (ECMP) did not work at Layer 4 when transit traffic was passed. [PR/444054: This issue has been resolved.]

Hardware

• On SRX5600 devices, during a Routing Engine reboot when processes were being shut down, a rare race condition occurred that could lead to a Routing Engine kernel crash. [PR/488484: This issue has been resolved.]

Integrated Convergence Services

• On SRX210 devices with Integrated Convergence Services, at least one time slot had to be configured for data for voice channels on T1 lines to work. [PR/442932: This issue has been resolved.]
• On SRX240 devices with Integrated Convergence Services, T1 configuration did not support all the 24 time slots for voice calls. It was limited to 5 time slots or line channels. [PR/442934: This issue has been resolved.]
• On SRX210 devices with Integrated Convergence Services, the peer call server configuration for the media gateway page in J-Web did not correctly display the port number field when TCP was used as the transport. [PR/445734: This issue has been resolved.]
• On SRX210 devices with Integrated Convergence Services, when you clicked the trunk-group field in J-Web, the configured trunk values were not displayed. [PR/445765: This issue has been resolved.]
• On SRX210 devices with Integrated Convergence Services, you could not edit the extension number on the J-Web call features page. [PR/447523: This issue has been resolved.]
• On SRX210 devices with Integrated Convergence Services, in J-Web, if you did not configure the class of restriction and a station template, you could not configure a station. [PR/452439: This issue has been resolved.]
• On SRX210 devices with Integrated Convergence Services, you had to restart the flow daemon to commit runtime T1 configuration changes. [PR/468594: This issue has been resolved.]
• On SRX210 devices with Integrated Convergence Services, the SIP-to-SIP simultaneous call capacity was limited to 10 calls. [PR/478485: This issue has been resolved.]

Interfaces and Routing

• On SRX240 devices, drops in out-of-profile LLQ packets were seen in the presence of data traffic, even when the combined (data+LLQ) traffic did not oversubscribe the multilink bundle. [PR/417474: This issue has been resolved.]
• On SRX240 devices, the serial interface maximum speed in extensive output was displayed as 16384 Kbps instead of 8.0 Mbps. [PR/437530: This issue has been resolved.]
• On SRX210 High Memory devices, only six logical interfaces came up on the G.SHDSL ATM interface (including OAM channel). The other two logical interfaces were down. [PR/466296: This issue has been resolved.]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, link speeds of 100 Mbps and 1 Gbps could not be configured on the ae0 interface with child interfaces configured. When you committed the configuration, the system displayed an error about the mismatch between the ae0 and child interfaces. [PR/482649: This issue has been resolved.]

Intrusion Detection and Prevention (IDP)

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices under stress, the output of show security idp attack table was empty at times. [PR/508976: This issue has been resolved.]

Power over Ethernet (PoE)

• On SRX210 and SRX240 devices, reset of the PoE controller failed when the restart chassis-control command was issued and also after system reboot. PoE functionality was not negatively impacted by this failure. [PR/441798: This issue has been resolved.]

Related Topics

• New Features in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
• Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
• Errata and Changes in Documentation for JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers