Issues in Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers

• Outstanding Issues In Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers
• Resolved Issues in Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers

Outstanding Issues In Junos OS Release 10.3 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 SRX5600 devices, if you run the show security alg sip counters command while doing a bulk call generation, it might bring down the SPU with a flowd core file error. [PR/292956]
• On SRX210 devices, the SCCP call cannot be set up after disabling and enabling the SCCP ALG. The call does not go through. [PR/409586]
• On SRX3400 and SRX3600 devices, RTSP, TFTP, and FTP ALG at scale in Layer 2 mode with A/P is not supported in Junos OS Release 10.3. [PR/474140]
• On SRX240 and SRX650 devices, maximum SCCP concurrent calls cannot be made under stress conditions. [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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, the SIP ALG is not supported in Junos Release 10.3 (the SIP ALG is not supported in previous versions either and, by default, is disabled). If enabled, the configuration is accepted, but it will not work properly. [PR/527446]

AppSecure

• When you download the predefined application identification signature database on SRX3400, SRX3600, SRX5600, and SRX5800 devices, the new database merges 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 OS 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 OS 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 and PR/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 SRX650 devices, when an access point is part of the 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 SRX650 devices, the AX411 Access Point licenses added might not be equal to the number of licenses installed. [PR/538786]

• On SRX650 devices, AX411 access points might not work under the following scenarios:

  • Multiple access points upgraded all at once
  • Reboot of multiple access points managed by SRX devices in cluster mode.
  As a workaround, bring up one access point at a time and confirm config push has happened on one access point before adding the next access point to the cluster. [PR/538994]
• On SRX240-High Memory devices, with IDP policy template, policy load fails while changing the active policy from the recommended option to the IDP_Default option. [PR/539486]

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, when you upgrade the nodes, sometimes the forwarding process might crash and get restarted. [PR/396728]
• 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 OS Release 9.6R2 to Junos OS Release 10.3. [PR/471235]
• On SRX3400 and SRX3600 devices, chassis cluster upgrades (LICU) with no-old-master-upgrade from Junos OS Release 9.6R2.11 to 10.0R1.x and from Junos OS Release 10.0R1.8 to 10.3 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 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 nonzero 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 SRX5600 and SRX5800 devices, kernel crashes occur during LICU from Junos OS Release 9.6R3 to Junos OS Release 10.3 along with vmcore and ksyncd core files, which interrupts the traffic. [PR/511973]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices configured for Layer 2 and chassis cluster, when there is too much DNS traffic through the device, it generates a core file. [PR/512888]
• On SRX650 devices in chassis cluster, ping packets sent from the forward node to the active node are dropped intermittently. [PR/520669]
• 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]
• On SRX3600 devices, when you do in-service software upgrade (ISSU) with IPv6 configuration and traffic upgrade from Junos OS release 10.2R1.8 to the 10.3 build, there might be some error messages. [PR/530035]

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]

Command-Line Interface (CLI)

• On SRX650 devices, the show commands do not show rules position content for show security NAT source rule all and show security NAT destination rule all commands. However, the destination and source NAT rules function well. [PR/514470]
• On J6350 devices, a reduced throughput over an ML bundle might be observed due to drops by the reassembly logic although the multilink fragments have been received at the member links. The symptom is that the member link ingress PPS matches the egress PPS of the transmitting side and the SHOW command for ML bundle show interface lsq-0/0/0 extensive shows drops such as fragment timeout, missing sequence number, out-of-order sequence number or out-of-range sequence number. As a work-around, configure a larger drop timeout (default being 100ms) on the bundle at the receiving device. [PR/523154]
• On SRX650 devices, tail drops and keep alive losses are seen at high load on multilink bundle when queue 3 (out of queue 0 to queue 7) is oversubscribed. As a workaround, use only queue 3 for keep alive packets and use other queues for data or voice transmission.[PR/539353]
• On SRX210 devices, packet drop might be seen while prioritizing multiple data streams configured with same multilink class on single member link ML bundle that are configured between J Series and SRX devices, and non J Series and SRX devices. As a workaround, ensure that each forwarding class is configured with one multilink class on ML bundle on J Series/SRX router. This will avoid out of order transmission of ML fragments for a given multilink class. This is not applicable to LFI traffic and when Q is marked for LFI then do not change that Q configuration.[PR/539449]

Dynamic Host Configuration Protocol (DHCP)

• On SRX210 and SRX240 devices, when autoinstallation is configured to run on a particular interface and the default static route is set with the options discard, retain, and no-advertise, the DHCP client running on the interface tries fetching the configuration files from the TFTP server. During this process, the UDP data port on the TFTP server might be unreachable. Because of the TFTP server being unreachable, the autoinstallation process might remain in the configuration acquisition state. When autoinstallation is disabled, the TFTP might fail. In this case, you should manually fetch the file from the server or the client through the relay.

  As a workaround, remove the static route options discard, retain, and no-advertise from the configuration.[PR/454189]

Enhanced Switching

• On J Series devices, if the access port is tagged with the same VLAN that is configured at the port, the access port accepts tagged packets and determines the MAC. [PR/302635]

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 and PR/397300]
• On J Series devices, outbound filters will be applied twice for host-generated IPv4 traffic. [PR/301199]
• On SRX Series devices, configuring the flow filter with the all flag might result in traces that are not related to the configured filter. As a workaround, use the flow trace flag basic with the command set security flow traceoptions flag. [PR/304083]
• On SRX210, SRX240, and SRX650 devices, after the device fragments packets, the FTP over a GRE link might not perform properly because of packet serialization. [PR/412055]
• On SRX240 devices, traffic flooding occurs when multiple multicast (MC) 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, the IOC hot swap is not supported with network processing bundling. If an IOC that has network processing bundling configured gets unplugged, all traffic to that network processor bundle will be lost. [PR/441961]
• On SRX5800 devices with interfaces in a network processing bundle, the ICMP flood or UDP flood cannot be detected at the threshold rate. However, it can be detected at a higher rate when the per-network processor rate reaches the threshold. [PR/442376]
• On 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 SRX5800 devices, the GPRS tunneling protocol (GTP) application is supported on well-known ports only. Customized application on other ports is not supported. [PR/464357]
• On J Series devices, interfaces with different bandwidths (even if they are of same interface type, for example, serial interfaces with different clock rates or channelized T1/E1 interfaces with different 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 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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, AppTrack messages report an extra packet. An extra TCP synchronization packet is counted, and reported bytes from the client are also increased. [PR/515854]
• On SRX240 Low Memory devices, LSQ interface transmitting both LLQ and non-LLQ traffic drops out of profile packets of the LLQ traffic faster than it was dropping out earlier. [PR/536588]
• On SRX240 High-Memory devices, under continuous high HTTP traffic load, it is possible that the forwarding daemon might generate a core file. This core file is seen sometimes after 24+ hours of continuous high load. Forwarding restarts when forwarding core file is generated and the device functions normally. [PR/538383]

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 and SRX650 devices with 16-port or 24-port GPIMs, the 1G half-duplex mode of operation is not supported in the autonegotiation mode. [PR/424008]
• On SRX240 devices, the Mini-PIM LEDs glow red for a short duration (1 second) when the device is powered on. [PR/429942]
• On SRX240 devices, the file installation fails on the right USB slot when both of the USB slots have USB storage devices attached. [PR/437563]
• 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 SRX240 devices, when users swap the USBs after startup, the chassis-control subsystem might not respond to any chassis-related commands. As a workaround, avoid swapping plug and play components in the right USB slot. [PR/437798]
• 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 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]

Integrated Convergence Services

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

• The music-on-hold feature is not supported for SIP phones. [PR/443681]
• 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]
• On SRX240 devices with Integrated Convergence Services, when you call the Sip2 phone from the Sip1 phone and then press the transfer button on the Sip2 phone and call the e911 number, the calls get sent successfully. When you press the complete button on the Sip2 phone, the Sip2-e911 call gets disconnected, but the Sip1 phone call remains active. [PR/489227]
• On SRX210 devices with voice capability, SIP trunking or FXS trunking calls do not work if called party supports only G729AB/G711-Mu-law codec. [PR/504135]
• On SRX210 devices with Integrated Convergence Services, if you have a call established between two SIP stations and you make a call transfer from either of the SIP stations to an analog FXS station,the call goes through but there might not be any voice. [PR/504269]
• On SRX240 devices with Integrated Convergence Services, the call-pickup feature does not work in survivable mode. If an analog station in a station group rings, another analog phone belonging to the same station group cannot pick up the call. As a workaround, configure three SIP phones (S1, S2, and S3), and add them to the pickup group (use a station group with S1, S2, and S3) because the pickup group works for SIP phones, but it does not work for analog phones. [PR/505237]
• On SRX240 devices with Integrated Convergence Services running in survivable mode, if two SIP stations are in a call and if either of the SIP stations attempts to park the call by dialing the parking number 7000, the call does not get parked. [PR/505240]
• On SRX210 and SRX240 devices with Integrated Convergence Services, if the transport method for the peer call server is TCP, the SRX Series devices do not support SIP messages of size more than 2048 bytes. [PR/510291]
• On SRX210 and SRX240 devices with voice capability, the T1PRI calls do not work when multiple trunk-groups or trunks are created. [PR/514784]
• On SRX210 and SRX240 devices with voice capability, the caller id of the calling party is displayed as a four digit local extension number instead of a seven or ten digit local or international number for outgoing calls from PRI. [PR/516021]
• On SRX210 and SRX240 devices with Integrated Convergence Services, if you have the accounting feature configured (Services>Convergence services>Features), you cannot configure the account code on a per-station basis. [PR/516681]
• On SRX240 devices with Integrated Convergence Services, when all lines are busy in a hunt group, you might receive a busy signal and the call might not get forwarded to a voice mail server. [PR/516691]
• On SRX240 devices with voice capability and Avaya ASM set up, DTMF tone is not heard when last added party in 3-Way conference call hangs. [PR/529115]
• On SRX210, SRX220, and SRX240 devices with voice capability, when a call comes to an SRX Foreign Exchange Office (FXO) and forwarded to a PCS, the caller id is not preserved. [PR/535540]
• On SRX240 devices with voice capability, restart RTMD command is required after changing the Max-concurrent-value from x to 0, to allow unlimited calls through SIP Trunk or PCS. [PR/536849]
• On SRX240 devices with voice capability, the restart rtmd command is required to make PRI calls successful when both PRI and T1CAS lines are active. [PR/537551]
• On SRX240 devices with voice capability, the voice prompts does not play for all E911 pre-emption calls. [PR/537554]
• On SRX210 and SRX240 devices with voice capability, E911 pre-emption does not happen when PSTN line is busy in the ringing state.[PR/538277]
• The SRX210 devices with media gateway capability, the users cannot cluster the chassis. The device that is configured as node1 crashes repeatedly.[PR/535512]
• On SRX210 and SRX240 devices with voice capability, if the devices are configured with a SIP trunk and if the auth-id field is not configured, the SIP calls might not work. As a workaround, configure the DID number as the auth-id field for the calls to go through. [PR/543350]

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 Series 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 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 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 all 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, SRX220, 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]
• On SRX100, SRX210, SRX240, and SRX650 devices, egress queues are not supported on VLAN or IRB interfaces.[PR/510568]
• On SRX650 devices, in the 2-port 10G XPIM, when the interface is linked with fiber, the activity LED does not blink when traffic enters the interface. However, the activity LED blinks properly when traffic goes out of the interface. [PR/513961]
• On J4350 and SRX240 devices, MAC address changes for VLAN interface are not supported. [PR/518934]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if stress FTP traffic sustains for several minutes, the device might might begin to accept only limited new FTP connections. This situation might continue for one minute and then the the device will return to normal functioning. [PR/530142]

Intrusion Detection and Prevention (IDP)

• The SRX Series and J Series devices support 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 all SRX Series and J Series 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 OS Release 10.3 (Layer 2 access-regular mode) is rolled back to the Junos OS Release 9.6 image, the DUT comes up in Junos OS Release 9.6 with Layer 2 access-regular mode, which was not supported in Junos OS 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 SRX100 and SRX210 devices, depending on configuration, peak performance level drops up to 30 percent have been observed for IDP and UTM features. This issue impacts only customers who deploy these devices with peak performance level requirements for IDP and UTM services. [PR/503446, PR/506500, PR/518737]
• On SRX5600 devices, when using a 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 an exponentially large amount of time when the key size is increased. Although key sizes of 1024 bits and 2096 bits are OK to process, because their processing time is 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 SRX210 High Memory and SRX240 High Memory devices, IDP scaling drop is observed on all SRX platforms. [PR/525732]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when packet-logging functionality is configured with a higher pre-attack configuration parameter value, 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 OS Release 10.3. All other modes of operation are supported. [PR/526252]
• IDP policies greater than 17MB do not get loaded.[PR/540856]

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]
• On SRX650 devices, source-address option for J-Flow does not stay persistent. [PR/530620]

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 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 SRX Series devices, the CLI Terminal feature does not work in J-Web over IPv6. [PR/409939]
• 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 SRX3400, SRX3600, SRX5600, and SRX5800 devices, in J-Web, the Generate Report option under Monitor Event and Alarms opens the report in the same web page. [PR/433883]
• 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 browser is used. The slow response is due to predefined attacks, attack group XML data fetching, and the way Internet Explorer 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 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, 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 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 J2350 and SRX210 High Memory devices, you can not use the Move down button for moving the IPS rule in IDP policy page. You must use the Move down button in landing page. [PR/499499]
• On SRX Series 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 vise 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 Junos XML protocol RPC are emitting some unnecessary debug messages because of some commit options that have been disabled. [PR/514540]
• On SRX220 High Memory devices, you cannot edit the physical properties of a LAN interface in J-Web without entering the MAC address. As a workaround, edit the properties in the CLI. [PR/519818]

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 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 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 OS Release 10.3. 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 displayed in the log should be 0.0.0.0->5.0.0.1.
  • For source NAT, the IP address displayed in the log should be 4.0.0.0->0.0.0.0.

  [PR/505454]

• 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 SRX5600 and SRX5800 devices, the incoming-table does not show up 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 a 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 PoE devices managing AX411 Access Points, the device 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]
• On SRX240 PoE devices, during failover, on the secondary node ADSL Mini-PIM restarts and takes about 3-4 minutes to come up. [PR/528949]

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 while using a UTM command:

  the utmd subsystem is not responding to management requests.

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

• On SRX100 High Memory, SRX210 High Memory, SRX240 High Memory, and SRX650 devices, the antispam requests more than 1500 are not supported due to system limitation. [PR/451329]

Upgrade

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if you are running a previous Junos OS Release and are already using more than 70 percent of the memory on your device, do not upgrade to Junos OS Release 10.3 without first adding more memory to your device. New functionality in Junos OS Release 10.3 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 OS Release 10.3. ISSU upgrade to 10.3 might cause loss of configuration. In order to upgrade to 10.3, use the normal upgrade procedure described in the Junos OS 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 SRX210 High Memory devices and J6350 devices, packet loss is seen during rapid ping operations between the dialer interfaces when packet size is more than 512 Kbps. [PR/484507]
• On SRX210 High Memory devices, the modem interface can handle bidirectional traffic of up to 19 Kbps. During oversubscription of 20 Kbps or more traffic, the keepalive packets are not exchanged and the interface goes down. [PR/487258]
• On SRX210 High Memory devices, IPv6 is not supported on dialer interfaces with a USB modem. [PR/489960]
• On SRX210 High Memory devices, http traffic is very slow through the umd0 interface. [PR/489961]
• On SRX210 High Memory devices, on multiple resets of the umd0 interface, the umd0 interface keeps flapping if the d10 (dialer) interface on either the dialin or dialout 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]

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 SRX Series 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 SRX3400 and SRX3600 devices, VPN monitor status in the DEP server side stays down for some time after RG0 and RG1 failover because there is no active state sync up for VPN monitoring. [PR/532952]

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 OS does not support policy-based VPN with WXC Integrated Services Modules (WXC ISM 200s). [PR/281822]

Resolved Issues in Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers

The following issues from Junos OS Release 10.2 have been resolved in this release. The identifier following the description is the tracking number in our bug database.

ALG

• On SRX240 Low Memory devices and SRX650 devices, when xSTP over LAG was deactivated, ports were in a blocked state and stopped switching traffic. [PR/515559: This issue has been resolved.]

AX411 Access Point

• On AX411 Access Points, an access point did not synchronize with the newly associated configuration (by changing or swapping the MAC address) and also did not join the changed cluster when it was associated to a new config block in the WLAN access point configuration. [PR/504581: This issue has been resolved.]

Chassis Cluster

• J4350 devices rebooted continually when worked under heavy src-pat NAT traffic. [PR/518085: This issue has been resolved.]
• On SRX650 devices in a chassis cluster, a binding was created both on the forward node and the active node. When all the sessions of this binding were over, the binding was freed on the active node, but the same binding still existed on the forward node. [PR/520660: This issue has been resolved.]
• On J4350 devices in a chassis cluster, statistics were not incremented on the IP sweep screen. [PR/527354: This issue has been resolved.]

Command—Line Interface (CLI)

• On SRX Series devices, show security flow cp-session summary command did not provide necessary information. [PR/513644: This issue has been resolved.]

Flow and Processing

• On SRX5600 and SRX5800 devices, LICU took nearly 50 minutes because of a read-only file system error. Initially the secondary node did not come out of the ISSU window. [PR/508704: This issue has been resolved.]
• On SRX100 Low Memory devices, if the device was running in transparent mode and flow trace was enabled, IPv6 packets caused a system crash. [PR/525326: This issue has been resolved.]
• On SRX650 devices, Dot1p bits of L2 packet traffic across Xpims changed. [PR/534064: This issue has been resolved.]

Hardware

• On SRX100, SRX210, SRX240, and SRX650 devices, 802.1x accounting statistics were not sent properly to the accounting server. [PR/509035: This issue has been resolved.]

Integrated Convergence Services

• On SRX210 Voice devices, FXS-FXS calls with Avaya SES+CM as peer call server worked only if media was sent through Avaya. [PR/488184: This issue has been resolved.]

Interfaces and Routing

• On SRX Series and J Series devices, PIM and DVMRP did not work on IRB. [PR/448208: This issue has been resolved.]
• On SRX210 PoE devices, the G.SHDSL link did not come up with an octal port line card of total access 1000 ADTRAN DSLAM. [PR/459554: This issue has been resolved.]
• On J Series devices, tail drops were seen on a bundle for traffic with a bigger packet size and similar fragmentation threshold. [PR/461417: This issue has been resolved.]

Intrusion Detection and Prevention (IDP)

• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when the number of attacks were too high, the show security idp attack table displayed the following error:

  “error: Failed to fetch data from data plane"

  "error: Reason: Message too long"

  [PR/521200: This issue has been resolved.]

• On SRX3400 devices, if you had your application identification configuration under config-groups (for example, set groups global/re0/re1 service application-identification <*>), committing the configuration might have caused the application identification Routing Engine daemon to generate a core file at /var/tmp/appidd.core*. [PR/527887: This issue has been resolved.]

J-Web

• On SRX Series devices, when the user added the LACP interface details, a pop-up window appeared in which there were two buttons to move the interface left and right. The LACP page did not have images incorporated with the two buttons. [PR/305885: This issue has been resolved.]
• On SRX210, SRX3400, SRX3600, SRX5600, and SRX5800 devices, selecting Configure>Security>Policy>IDP Policies>Security Package Update>Help in the J-Web user interface brought up the IDP policy Help page instead of the Signature update Help page. [PR/409127: This issue has been resolved.]
• On SRX210 High Memory, SRX240 PoE, and J Series devices, you were not able to configure IDP custom attacks and dynamic attack groups using J-Web. [PR/416885: This issue has been resolved.]
• On SRX Series and J Series devices, when J-Web is used to configure a VLAN, the option to add an IPv6 address appeared, whereas only IPv4 addresses were supported. [PR/459530: This issue has been resolved.]
• On SRX Series devices in J-Web the left-side menu items and page content might have disappeared when Troubleshoot was clicked twice. [PR/459936: This issue has been resolved.]
• On SRX100, SRX210, SRX240, SRX650, and J Series devices, in the J-Web interface, the Traceoptions tab in the Edit Global Settings window of the OSPF Configuration page (Configuration>Routing>OSPF Configuration) did not display the available flags (tracing parameters). [PR/475313: This issue has been resolved.]
• On SRX210, SRX240, SRX650 and J Series devices, in the J-Web interface, Monitor>Switching>Spanning Tree showed a null page when Spanning Tree Protocol was not running on the device. [PR/484202: This issue has been resolved.]
• On SRX220 PoE devices, the dashboard in J-Web did not display Chassis View. [PR/496538: This issue has been resolved.]
• On SRX3400, SRX3600, SRX5600, and SRX5800 devices, in the J-Web interface, the NAT incoming table submenu was missing from the NAT Menu of the Monitor page. [PR/522255: This issue has been resolved.]

Network Address Translation (NAT)

• On SRX3600 devices, when there was source pool overflow NAT, the phone had multiple entries in the incoming-table. [PR/519137: This issue has been resolved.]

Power over Ethernet (PoE)

• On SRX210 and SRX240 devices, the deactivate poe interface all command did not deactivate the PoE ports. [PR/426772: This issue has been resolved]

Security

• On SRX650 devices, the show commands did not show rules position content for show security NAT source rule all and show security NAT destination rule all. However, the destination and source NAT rules functioned well. [PR/514470: This issue has been resolved.]

USB Modem

• On SRX210, SRX100, SRX240, and SRX650 devices, when you restarted forwarding daemon at the dial-out side, the umd interface went down and the call never got connected. [PR/480206: This issue has been resolved.]
• On SRX100, SRX210, SRX240, and SRX650 devices, the call terminated if you removed and inserted a USB modem. [PR/491820: This issue has been resolved.]

Virtual LANs (VLANs)

• On SRX210, SRX220, SRX240, and SRX650 devices, you were not able to configure VLAN ID 4093 on 1-Port SFP Mini-PIM interfaces because it was an internal reserved VLAN ID. [PR/515741: This issue has been resolved.]
• On SRX100, SRX210, SRX240, and SRX650 devices, IKE negotiation failed when an IKE ID longer than 31 bytes was configured for dynamic VPN. [PR/523796: This issue has been resolved.]

Related Topics

• New Features in Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers
• Known Limitations in Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers
• Errata and Changes in Documentation for Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers