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

The following features have been added to JUNOS Release 10.2. Following the description is the title of the manual or manuals to consult for further information.

• Software Features
• Hardware Features—SRX210 Services Gateways
• Hardware Features—SRX240 Services Gateways
• Hardware Features—SRX210 and SRX240 Services Gateways with Integrated Convergence Services
• Hardware Features—SRX650 Services Gateways
• Hardware Features—SRX3400 and SRX3600 Services Gateways

Software Features

Application Layer Gateways (ALGs)

• Layer 2 mode with chassis clustering—This feature is now supported on SRX3400 and SRX3600 devices in addition to existing support on SRX5600 and SRX5800 devices.

  The following Application Layer Gateways (ALGs) are supported in Layer 2 mode with chassis clustering:

  • Real-Time Streaming Protocol (RTSP)
  • File Transfer Protocol (FTP)
  • Trivial File Transfer Protocol (TFTP)

  [Junos OS Security Configuration Guide, Junos OS Layer 2 Bridging and Switching Configuration Guide for Security Devices]

• Application Layer Gateway for IKE and ESP—This feature is supported on all SRX Series and J Series devices.

  An SRX Series or a J Series device can be used solely as a NAT device when placed between VPN clients on the private side of the NAT gateway and the VPN gateways on the public side.

  Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) traffic is exchanged between the clients and the server. However, if the clients do not support NAT-T and if the device assigns the same NAT-generated IP address to two or more clients, the device will be unable to distinguish and route return traffic properly.

  Note: If the user wants to support both NAT-T capable and non-NAT-T capable clients, then some additional configurations are required. If there are NAT-Traversal (NAT-T) capable clients, the user must enable the source NAT address persistence.

  ALG for IKE and ESP monitors IKE traffic between the client and the server and permits only one IKE Phase 2 message exchange at the same time between any given client-server pair, not just one exchange between any client and any server.

  This feature allows the device to be configured to return the same NAT-generated IP address for the same IP address without NAT ("address-persistent NAT"). As a result, the device is able to associate a client's outgoing IKE traffic with its return traffic from the server, especially when the IKE session times out and needs to be reestablished.

  The resulting ESP traffic between the client and the server must also be allowed, especially in the direction from the server to the client.

  The return ESP traffic must match the following:

  • The server IP address as source IP
  • The client IP address as destination IP

  To address these issues, ALG for IKE and ESP traffic has been created and NAT has been enhanced to enable the SRX Series and J Series devices to pass IKE and ESP traffic with a source NAT pool. [Junos OS Security Configuration Guide]

AppSecure

• JUNOS Software application identification—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Application identification is used by IDP to allow or deny traffic based on applications running on nonstandard TCP or UDP ports, without prior knowledge of port binding. Application tracking (AppTrack) can also use the information collected by application identification to provide detailed reports on applications passing through the device.

  The following improvements have been made to application identification:

  • Improved granularity for nested application identification allows identification of applications nested in HTTP traffic, such as Facebook.
  • Application definition database contents can now be viewed in the configuration.
  • Custom application and nested application definitions can be created to identify applications that are not be part of the predefined application database.
  • Application tracking (AppTrack) now provides reporting on information collected by application identification.

  When using application identification without IDP enabled, you extract the application definition database from the IDP signature database with the command: request services application-identification download. This command will extract and install the application portion of the IDP signature database to your configuration. If you have IDP enabled and will use application identification, you will continue to run the IDP signature database download: request security idp security-package download and request security idp security-package install.

  If you have modified the default IDP application identification sensor configuration in JUNOS Release 9.6, 10.0, or 10.1, and you upgrade to JUNOS Release 10.2, you will need to reenter your settings by using the CLI commands in the services hierarchy.

  Note: On the SRX100, SRX210, SRX240, and SRX650 devices, the IDP application identification feature does not change and the hierarchy is still in [edit security idp sensor-configuration application-identification].

  Table 3 shows changes to the applications’ CLI, and Table 4 shows changes to nested applications. Items in bold font are new or have changed.

  The new hierarchy for application identification is [edit services application-identification].

  Table 3: Application Identification Application CLI Changes

  Application IDP CLI (existing)	Application CLI (new for Release 10.2)
  	max-checked-bytes
  application-system-cache-timeout max-packet-memory max-sessions max-tcp-session-packet-memory max-udp-session-packet-memory no-application-system-cache disable	application-system-cache-timeout max-sessions no-application-identification no-application-system-cache

  The new hierarchy for nested application identification is [services application-identification nested-application-settings].

  Table 4: Application Identification Nested Applications CLI Change

  Nested Applications IDP CLI (existing)	Nested Applications CLI (new for Release 10.2)
  no-nested-application-system-cache no-nested-application-identification	no-application-system-cache no-nested-application

  [Junos OS CLI Reference, Junos OS Security Configuration Guide]

• AppTrack—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Application tracking (AppTrack) delivers statistical information on application usage.

  AppTrack on high-end SRX Series devices uses application identification to collect byte, packet, and time statistics specific to an application and sends the data to a log server capable of receiving AppTrack-formatted messages. Network management tools generate volumetric reports from the logged statistics. [Junos OS Security Configuration Guide]

Auto BIOS Upgrade

• This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices.

  JUNOS Release 10.2 is shipped with BIOS version 1.7. For the SRX100 device, the minimum compatible BIOS version is 1.6. For the SRX210, SRX240, and SRX650 devices, the minimum compatible BIOS version is 1.5. If the BIOS version of the current device is earlier than the minimum compatible version, then the auto BIOS upgrade feature upgrades the BIOS automatically to the BIOS shipped with the JUNOS package.

  The BIOS is upgraded automatically in the following scenarios:

  • During JUNOS Software upgrading through either the J-Web interface or the CLI—In this case, only the active BIOS is upgraded.
  • During loader installation using TFTP or USB—In this case, only the active BIOS is upgraded.
  • During system boot-up—In this case, both the active BIOS and the backup BIOS are upgraded.

  The auto BIOS upgrade feature is enabled by default. Users can disable this feature by using the set chassis routing-engine bios no-auto-upgrade command on the CLI.

  Note: This command disables the automatic upgrade of BIOS during JUNOS Software upgrade or system boot-up. It does not disable automatic BIOS upgrade during loader installation.

  [JUNOS Software Administration Guide for Security Devices, JUNOS Software CLI Reference]

Manual BIOS Upgrade Using JUNOS CLI

• This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices.

  For branch SRX Series devices, BIOS is made up of U-boot and JUNOS loader. Apart from this SRX240 and SRX650 also have U-shell binary as part of the BIOS.

  On SRX100, SRX210 and SRX240, there is support of Backup BIOS which constitutes a backup copy of U-boot in addition to the active copy from which the system generally boots up.

  Table 5 provides details of BIOS components supported for different platforms.

  Table 5: Manual BIOS Upgrade Components

  BIOS Components		SRX100	SRX210	SRX240	SRX650
  Active	U-boot	Yes	Yes	Yes	Yes
  	Loader	Yes	Yes	Yes	Yes
  	U-shell			Yes	Yes
  Backup	U-boot	Yes	Yes	Yes

  Table 6 provides you the CLI commands used for manual BIOS upgrade.

  Table 6: CLI Commands for Manual BIOS Upgrade

  Active BIOS	Backup BIOS
  request system firmware upgrade re bios	request system firmware upgrade re bios backup

  Procedure for BIOS upgrade

  1. Installing a jloader-srxsme package
     1. Copy the jloader-srxme signed package to the device.

        Note: Note that this package should be of the same version as that of the corresponding JUNOS, example, on a device with a 10.2 JUNOS package installed, the jloader-srxsme package should also be of version 10.2.

     2. Install the package using the request system software add <path to jloader-srxsme package> no-copy no-validate command.
        
        

        root> request system software add /var/tmp/jloader-srxsme-10.2B3-signed.tgz no-copy no-validate

        Installing package '/var/tmp/jloader-srxsme-10.2B3-signed.tgz' ...
        Verified jloader-srxsme-10.2B3.tgz signed by PackageProduction_10_2_0
        Adding jloader-srxsme...
        Available space: 427640 require: 2674
        Mounted jloader-srxsme package on /dev/md5...
        Saving state for rollback ...

        
        

        root> show version

        Model: srx240h
        JUNOS Software Release [10.2B3]
        JUNOS BIOS Software Suite [10.2B3]
        

        Note: Installing the jloader-srxsme package puts the necessary images under directory/boot.

  2. Verifying that images for upgrade are installed
     • The show system firmware command can be used to get version of images available for upgrade. The available version is printed under column Available version. The user needs to verify that the correct version of BIOS images available for upgrade.
       
       

       root> show system firmware

       	Part              Type           Tag  Current   Available  Status
                                               version   version
         Routing Engine 0  RE BIOS        0    1.5       1.7        OK
         Routing Engine 0  RE BIOS Backup 1    1.5       1.7        OK
         Routing Engine 0  RE FPGA        11   12.3.0               OK

  3. BIOS upgrade

     Active BIOS:

     1. Initiate the upgrade using the request system firmware upgade re bios command.
        
        

        root> request system firmware upgrade re bios

        	Part              Type           Tag  Current   Available  Status
                                                version   version
          Routing Engine 0  RE BIOS        0    1.5       1.7        OK
          Routing Engine 0  RE BIOS Backup 1    1.5       1.7        OK
        
          Perform indicated firmware upgrade ? [yes,no] (no) yes

        Firmware upgrade initiated.

     2. Monitor the status of upgrade using the show system firmware command.
        
        

        root> show system firmware

        	Part              Type            Tag  Current   Available   Status
                                               version   version
        Routing Engine 0  RE BIOS         0     1.5       1.7        PROGRAMMING
        Routing Engine 0  RE BIOS Backup  1     1.5       1.7        OK
        Routing Engine 0  RE FPGA         11    12.3.0               OK

        
        

        root> show system firmware

        Part              Type           Tag    Current   Available   Status
                                                version   version
        Routing Engine 0  RE BIOS         0     1.5        1.7      UPGRADED 
                                                                    SUCCESSFULLY    
        Routing Engine 0  RE BIOS Backup  1     1.5        1.7        OK
        Routing Engine 0  RE FPGA         11    12.3.0                OK

        Note: The device must be rebooted for the upgraded active BIOS to take effect.

     Backup BIOS:

     1. Initiate the upgrade using the request system firmware upgade re bios backup command.
        
        

        root> request system firmware upgrade re bios backup

        	Part              Type           Tag  Current   Available  Status
                                                version   version
          Routing Engine 0  RE BIOS        0    1.5       1.7        OK
          Routing Engine 0  RE BIOS Backup 1    1.5       1.7        OK
        
          Perform indicated firmware upgrade ? [yes,no] (no) yes

        Firmware upgrade initiated.

     2. Monitor the status of upgrade using the show system firmware command.
        
        

        root> show system firmware

        	Part              Type           Tag  Current   Available  Status
                                                version   version
          Routing Engine 0  RE BIOS        0    1.5       1.7        OK
          Routing Engine 0  RE BIOS Backup 1    1.5       1.7        PROGRAMMING
          Routing Engine 0  RE FPGA         11   12.3.0                OK

        
        

        root> show system firmware

        Part              Type           Tag    Current   Available   Status
                                                version   version
        Routing Engine 0  RE BIOS         0     1.5        1.7          OK
        Routing Engine 0  RE BIOS Backup  1     1.7        1.7        UPGRADED 
                                                                    SUCCESSFULLY
        Routing Engine 0  RE FPGA         11    12.3.0                OK

Chassis Cluster

• Multicast routing across nodes in a chassis cluster—This feature is supported on all SRX Series and J Series devices.

  Multicast routing support across nodes in a chassis cluster allows multicast protocols, such as Protocol Independent Multicast (PIM) versions 1 and 2, Internet Group Management Protocol (IGMP), Session Announcement Protocol (SAP), and Distance Vector Multicast Routing Protocol (DVMRP), to send traffic across interfaces in the cluster. Note, however, that the multicast protocols should not be enabled on the chassis management interface (fxp0) or on the fabric interfaces (fab0 and fab1). Multicast sessions will be synched across the cluster and will be maintained during redundant group failovers. During failover, as with other types of traffic, there might be some multicast packet loss.

  Multicast data forwarding in a chassis cluster uses the incoming interface to determine whether or not the session remains active. Packets will be forwarded to the peer node if a leaf session’s outgoing interface is on the peer instead of on the incoming interface’s node. Multicast routing on a chassis cluster supports tunnels for both incoming and outgoing interfaces. Multicast configuration on a chassis cluster is the same as multicast configuration on a standalone device. [Junos OS Security Configuration Guide]

• Dual fabric links—This feature is supported on all SRX Series and J Series devices.

  You can connect two fabric links between each device in a cluster, which provides a redundant fabric link between the members of a cluster. When you use dual fabric links, the runtime objects (RTOs) and probes are sent on one link and the fabric-forwarded and flow-forwarded packets are sent on the other link. If one fabric link fails, the other fabric link handles the RTOs and probes, as well as the data forwarding. Having two fabric links helps to avoid a possible single point of failure. [Junos OS Security Configuration Guide]

• Dual control links—This feature is now supported on SRX3400 and SRX3600 devices in addition to existing support on SRX5600 and SRX5800 devices.

  You can connect two control links between each device in a cluster, which provides a redundant control path between the members of a cluster. For the SRX3400 and SRX3600 devices, this functionality requires an SRX Clustering Module (SCM) to be installed on each device in the cluster. Unlike the SRX5600 and SRX5800 devices, a second Routing Engine is not supported on the SRX3400 and SRX3600 devices. The purpose of the SCM is to initialize the second control link. Having two control links helps to avoid a possible single point of failure. [Junos OS Security Configuration Guide]

Flow and Processing

• Flow CLI enhancements—This feature is supported on all SRX Series and J Series devices.

  The show security flow status command displays information on flow processing modes and logging status. The show security flow statistics command displays information on session and packet counters.

  Note: Services Processing Unit (SPU) information is not displayed on SRX100, SRX210, SRX240, and SRX650 devices.

  The central point session command also displays SPU information for the whole system. The security flow session output can be viewed in summary, brief, and extensive mode using the show security flow session command. This command displays information on session detail retrieval. SPU information such as the SPU identifier, FPC, and PIC can be viewed using this command. The SPU identifier displays entries per SPU.

  Gate statistics can be viewed using the show security flow gate summary command. The show security flow gate command displays the total number of gates. The show security flow gate and the show security flow cp-session command support the following:

  • Display of multiple filters
  • Display of output in summary mode using filters
  • Display of SPU information for multiple SPU systems

  [JUNOS Software Security Configuration Guide]

Interfaces and Routing

• DOCSIS firmware secure upgrade procedures—This feature is supported on SRX210 and SRX240 devices.

  Upgrade Data over Cable System Interface Specifications (DOCSIS) ATP MAC-14 firmware on an SRX210 or SRX240 device using either the cable modem configuration file or SNMP. Choose one of the following procedures for upgrading:

  • Cable modem configuration file:
    1. Edit the following fields in the configuration file:
       1. Change test.img to the name of the new signed firmware image file.
          Software Upgrade Filename (9) = “new-signed-firmware-image.img”
       2. Configure the IP address of your TFTP server.
          Software upgrade TFTP Server (21) = “n.n.n.n”
    2. Assign the configuration file to the cable modem.
    3. Reboot or power-cycle the device.
    4. Monitor the progress of the upgrade from the TFTP software server:
       • Use the following command to display the software operation status:
         SNMP GET docsDevSwOperStatus
       • Wait for resumption of operational status.
  • SNMP:
    1. Assign the configuration file to the cable modem.
    2. Reboot or power-cycle the device.
    3. When the device is operational, enter the following commands with the details for your network:
       SNMP SET docsDevSwFilename = new-signed-firmware-image.imgSNMP SET docsDevSwServer = TFTP-server-IP-addressSNMP SET docsDevSwAdminStatus = upgradeFromMgt(1)
    4. Monitor the progress of the upgrade from the TFTP software server:
       • Use the following command to display the software operation status:
         SNMP GET docsDevSwOperStatus
       • Wait for resumption of operational status.
• Link Aggregation Control Protocol—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  JUNOS Release 10.2 supports the Link Aggregation Control Protocol (LACP), which is a subcomponent of IEEE 802.3ad. LACP provides additional functionality for link aggregation groups (LAGs).

  For example, when LACP is not enabled, a local LAG might attempt to transmit packets to a remote single interface, which causes the communication to fail. When LACP is enabled, a local LAG cannot transmit packets unless a LAG with LACP is also configured on the remote end of the link.

  By default, aggregated and redundant Ethernet links do not exchange link aggregation control protocol data units (PDUs), which contain information about the state of the link. You can configure Ethernet links to actively transmit link aggregation control PDUs, or you can configure the links to passively transmit them, sending out link aggregation control PDUs only when they receive them from the remote end of the same link. The local end of a child link is known as the actor and the remote end of the link is known as the partner. That is, the actor sends link aggregation control PDUs to its protocol partner that convey what the actor knows about its own state and that of the partner’s state.

  LACP is supported in standalone deployments, where aggregated Ethernet interfaces are supported, and in chassis cluster deployments, where aggregated Ethernet interfaces and redundant Ethernet interfaces are supported simultaneously. Aggregated Ethernet interfaces can be Layer 3 interfaces (VLAN-tagged or untagged) and Layer 2 interfaces. LACP is supported on Layer 3 only.

  The LACP mode can be off (the default), active, or passive. LACP is enabled by setting the mode to either passive or active. If the actor and partner are both in passive mode, they do not exchange link aggregation control PDUs, which results in the aggregated Ethernet links not coming up. If either the actor or partner is active, they exchange link aggregation control PDUs. To initiate transmission of link aggregation control PDUs and response link aggregation control PDUs, you must enable LACP at both the local and remote ends of the links, and one end must be active. [Junos OS Interfaces Configuration Guide for Security Devices]

• Layer 2 transparent mode active/active chassis clusters—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Devices in Layer 2 transparent mode can now be deployed in active/active chassis cluster configurations, as well as active/backup configurations.

  Active/active chassis cluster configurations support multiple redundancy groups, meaning you are no longer restricted to the creation of only one redundancy group beyond redundancy group 0. Instead, you can configure one or more redundancy groups numbered 1 through 128. Multiple redundancy groups make it possible for traffic to arrive on an interface of one redundancy group and egress on an interface that belongs to another redundancy group. In this situation, the ingress and egress interfaces might not be active on the same node. When this happens, the traffic is forwarded over the fabric link to the appropriate node.

  Intrusion Detection and Prevention (IDP) is not supported in Layer 2 transparent mode active/active chassis clusters. (IDP is supported in Layer 2 transparent mode active/backup chassis clusters). [Junos OS Layer 2 Bridging and Switching Configuration Guide for Security Devices]

• Targeted broadcast of ingress IP packets—This feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  The IP-directed broadcast feature provides an optional method of sending broadcast packets to hosts on a specified subnet without broadcasting those packets to all hosts on the network. Directed broadcast can be used for implementing remote administration tasks, such as backups and wake-on LAN applications, or for automatic data transfers from providers.

  If JUNOS Software has a route for the next-hop gateway, broadcast packets are transited to other gateway routers along the path to the final destination. By default, broadcast packets are not sent to the subnet at the final egress port (where there is no next-hop gateway identified as a route), but are discarded after lookup. With targeted broadcast enabled, directed broadcast packets received on an ingress interface are automatically transited to an egress LAN interface and broadcast to the subnet.

  To enable targeted broadcast on a broadcast interface and send a copy of the packet to the Routing Engine, enter targeted-broadcast forward-and-send-to-re at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level. To broadcast to the egress interface only, enter targeted-broadcast forward-only. If targeted broadcast has been enabled, the show interfaces command output includes a targeted broadcast flag corresponding to the enabled option.

Intrusion Detection and Prevention (IDP)

• Enhancements to application-level DDoS protection—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  The ip-action command for application-level DDoS policies enables you to implicitly block a source address to protect the network from future intrusions while permitting legitimate traffic. With IP connection rate limiting, you can limit the number of connections per second for the matching ip-action target once the ip-action entry is installed on attack detection.

  To identify the thresholds for the application-level DDoS configuration, connection, context data, and rate statistics collection has also been added. With information collected from statistics reports, you can determine trends on connection rates and application requests destined for your protected servers. This data can then be used to configure server thresholds like connection, context and context value thresholds.

  The command to set application-ddos statistics is sensor-configuration application-ddos statistics.

  Note: Statistic reports are saved on the Routing Engine hard disk at /var/log/addos.

  Following are the main features of this enhancement:

  • Statistics collection of connection and context rates on a periodic basis (default is once every 1min)
  • Application-level DDoS reporting
  • Connection rate limiting for ip-action. The command to set connection rate limiting is ip-connection-rate-limit.
  • Automatic file compression of statistical data files when file size reaches 10 MB.

  [Junos OS CLI Reference,Junos OS Security Configuration Guide]

• IDP inline tap mode—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Intrusion Detection and Prevention (IDP) inline tap mode provides best case deep inspection analysis of traffic while maintaining overall device performance and stability. The inline tap feature provides passive, inline detection of Application Layer threats for traffic that matches security policies with the IDP application service enabled. When a device is in inline tap mode, packets pass through the firewall inspection process and are also copied to the independent IDP module. This allows the packets to get to the next service module without waiting for IDP processing results. In this way, the device sustains processing even when incoming traffic exceeds the IDP throughput limit (as long as other module limits, such as the firewall, are not exceeded). Since inline tap mode puts IDP in a passive mode for monitoring, preventive actions such as session close, drop, and mark diffserv are deferred. The action drop packet is ignored.

  Inline tap mode can only be configured if the forwarding process mode is set to maximize IDP sessions, which ensures stability and resiliency for firewall services. You also do not need a separate tap or span port to use inline tap mode.

  Note: When switching to inline tap mode or back to regular mode, you must restart the device.

  The command to enable inline tap mode is at the [security forwarding-process application-services maximize-idp-sessions] hierarchy. [Junos OS CLI Reference,Junos OS Security Configuration Guide]

• IDP packet capture over DMI—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  The packet-capture feature in IDP lets you capture a specified number of packets that precede and follow an attack and transport them through Device Management Interface (DMI) to the host for further offline inspection. By analyzing the captured packets, you can better determine attack behavior, reduce false positive rule matches, and increase confidence in the detection ability of an IDP configuration.

  The notification section of an IDP policy rule configures specifications and limits for a packet capture, which will be triggered by a match of the rule criteria. Such specifications include the number of packets to be captured before and after an attack and a session-specific time limit for post-attack packet capturing.

  A sensor configuration sets general specifications and limits for the capture, storage, and transmission of packets on a particular device. The sensor specification includes the memory allocation for caching and maximum supported sessions on the device for packet capture. The sensor configuration also defines the source and host device addresses for transmitting a packet log and its associated message log to the host.

  Note: Packet capture is a powerful, but resource-intensive feature. We recommend that you configure a packet-capture policy to analyze traffic associated with a single event of particular interest.

  [Junos OS Security Configuration Guide]

• Filter support for IDP—This feature is supported on all SRX Series devices.

  The IDP filter used to view the output of the show security flow session idp summary command has been changed; the new command is show security flow session summary idp. Filters can be used to view the output of the show security flow session summary idp command in summary mode. This command displays the following output:

  • Valid sessions
  • Pending sessions
  • Invalidated sessions
  • Sessions in other states
  • Total sessions

IPsec

• Dynamic VPN—This feature is supported on SRX650 devices in addition to existing support on SRX210 and SRX240 devices.

  The dynamic VPN feature uses Internet Protocol Security (IPsec) technology to create secure VPN tunnels. This feature simplifies remote access by enabling users to establish VPN tunnels without having to manually configure VPN settings on their PCs or laptops. Instead, the client is dynamically delivered to users from the SRX210, SRX240, or SRX650 devices upon successful authentication. This Layer 3 remote access client uses client-side configuration settings that it receives from the server to create and manage a secure VPN tunnel to the server. [Junos OS Security Configuration Guide]

IPv6 Support

• Address books and address sets—Address book entries can include any combination of IPv4 addresses, IPv6 addresses, and Domain Name System (DNS) names.

  To configure IPv6 address entries, specify an IPv6 address when you use the address statement at the [edit security zones security-zone name address-book] hierarchy level.

  The address set configuration takes names of address book entries, not IP addresses, so there are no additional considerations related to IPv6 traffic. [Junos OS Security Configuration Guide]

• Administrative operations—We have verified support for the following system services: ping, traceroute, and DNS lookup (client).
• Chassis cluster—In JUNOS Release 10.2, we support chassis cluster in an active-passive (failover) deployment. [Junos OS Security Configuration Guide]
• Class of service—You can use IPv6 DiffServ code points in class of service (Cos) classifier rules and re-write rules. Other CoS features are not IPv6-aware and so do not require special configuration related to IPv6. [Junos OS Class of Service Configuration Guide for Security Devices]
• Flow-based processing—IPv6 flow support enables processing of IPv6 traffic by the SRX and J Series security features listed in this section. IPv6 flow support is disabled by default, and IPv6 packets are dropped.

  To enable flow-based processing for IPv6 traffic, modify the mode statement at the [edit security forwarding-options family inet6] hierarchy level.

  The [show security flow session source-prefix] and [show security flow session destination-prefix] commands you use to monitor session statistics now take IPv6 address arguments. In addition, we have added the [show security flow session family (inet|inet6)] option to filter session statistics by protocol family.

  [Junos OS CLI Reference, Junos OS Interfaces Configuration Guide for Security Devices, Junos OS Security Configuration Guide]

• Interfaces—A logical interface can be configured with an IPv4 address, IPv6 address, or both.

  To configure an IPv6 address for a logical interface, use the inet6 statement at the [edit interfaces interface-name unit logical-unit family] hierarchy level. [Junos OS Interfaces Configuration Guide for Security Devices]

• Logging—We have verified support for sending syslog logs and SNMP traps over IPv6.

  The set security log commands you use to configure logging now take IPv6 address values.

  Also, note the following flow log messages pertain to IPv6 sessions:

  • RT_FLOW_IPVX_SESSION_DENY–Log written when a packet is denied by policy (when the policy includes logging).
  • RT_FLOW_IPVX_SESSION_CREATE—Log written when a packet matches a policy and a session is created (when the policy includes logging
  • RT_FLOW_IPVX_SESSION_CLOSE—Log written when the previously created session is closed.

  [Juniper Networks Enterprise-Specific MIBs, Junos OS Administration Guide for Security Devices, JUNOS System Log Messages Reference]

• Routing protocols—We have verified support for the following IPv6-related protocols: BFD, BGP, ICMPv6, neighbor discovery (ND), OSPFv3, and RIPng. [JUNOS Routing Protocols Configuration Guide, Junos OS Routing Protocols and Policies Configuration Guide for Security Devices]
• Screens—There are no configuration considerations to use screens on IPv6 traffic. Note that the following screens are applicable only to IPv4 traffic: ip-bad-option, ip-record-route, ip-security-opt, ip-stream-opt, ip-strict-src-route, ip-timestamp-opt. [Junos OS Security Configuration Guide]
• Security policy (firewall)—The matching criteria for security policy rules is based on zones, address objects, and applications. To support security policy rules for IPv6 traffic, you configure zone and address objects with IPv6 values. You can also select IPv6 applications.

  Note that in security policy rules, the meaning of the wildcard any has changed. When flow support is enabled for IPv6 traffic, the wildcard any matches any IPv4 or IPv6 address. In JUNOS Release 10.2, we introduce new wildcards to match any IPv4 or any IPv6 address: any-ipv4 and any-ipv6. When flow support is not enabled for IPv6 traffic, any matches IPv4 addresses.

  IPv6 support for IDP and UTM are not included in JUNOS Release 10.2. If your current security policy uses rules with any IP address wildcards and IDP and UTM features enabled, you will encounter configuration commit errors because IDP and UTM features do not yet support IPv6 addresses. To resolve the errors, modify the rule returning the error so that it uses the any-ipv4 wildcard; and create separate rules for IPv6 traffic that do not include IDP or UTM features. [Junos OS Security Configuration Guide]

• Stateless firewall filters—You can match IPv6 addreses in firewall filter rules. [Junos OS Routing Protocols and Policies Configuration Guide for Security Devices]
• User authentication—We have verified support for administrator access to an IPv6 interface using: Telnet, SSH, or HTTP.
• Zones—The security zone configuration takes names of interfaces, not IP addresses, so there are no additional considerations related to the zone interface configuration.

  You also use the zone configuration to explictly permit inbound traffic from network system services and system protocols. Note that you can now use the host inbound traffic configuration to permit traffic from the following IPv6-related services and protocols: DHCPv6, neighbor discovery (ND) protocol, OSPF3, and RIPng. [Junos OS Security Configuration Guide]

• Check for JUNOS Release 10.2 IPv6 limitations in the sectionKnown Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers.

J-Web

• J-Web IDP configuration pages enhancement—This feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  The following pages have been redesigned to enhance usability:

  • IDP Policies configuration page
  • IDP Signature Update configuration page

  An IDP Sensor configuration page has been added.

• J-Web interface configuration page enhancement—This feature is supported on SRX210, SRX240, and SRX650 devices.

  The J-Web options configuration page now includes a tab for configuring T1/E1 options. To configure CT1 or CE1 interfaces, select Interface type as t1 or e1, respectively. If you change the t1 Interface type to e1, the CT1 configuration is deleted and a CE1 configuration is created and vice versa. The Interface configuration page now includes a new tab to configure encapsulation for logical interfaces. The supported encapsulations are:

  • Cisco HDLC
  • Framerelay
  • PPP
  • Multilink framerelay-unn-nni

  Families supported are:

  • Inet
  • Inet6
  • Mlppp
  • Mlfr-end to end
  • Mlfr-uni-nni

  [Junos OS Interfaces Configuration Guide for Security Devices]

• J-Web pages for NG NAT configuration and monitoring—This feature is supported on all SRX Series and J Series devices.

  The following changes have been made to the J-Web pages for configuring NG NAT:

  • The pages have been redesigned and converted to the new EXTJS framework to improve usability.
  • A Static NAT page and a Proxy ARP Configuration page have been added.
  • A pop-up window with add and edit options has been added.
  • Sorting by grid has been included.

  The following changes have been made to the J-Web pages for monitoring NG NAT:

  • The pages have been redesigned and converted to the new EXTJS framework to improve usability.
  • A bar chart has been added that displays the 10 top hits.
  • Refresh Interval and Manual Refresh buttons have been added.
• J-Web Pages for monitoring IPsec VPN—This feature is supported on all SRX Series and J Series devices.

  To improve their usability, the pages for have been redesigned and converted to the new EXTJS framework.

• J-Web pages for chassis cluster—This feature is supported on all SRX Series and J Series devices.

  The following additional configurations are available:

  • Control port (required)
  • IP monitoring (optional)

  To improve their usability, the following features have been redesigned and converted to the new EXTJS framework:

  • Configure system and interfaces information for individual nodes
  • Configure information for chassis cluster and redundancy groups
• Single commit on J-Web—This feature is supported on all SRX Series devices.

  In the J-Web user interface, you can now commit the complete J-Web configuration with a single commit action instead of committing configuration on each J-Web configuration page. This results in the following improvements:

  • Enhanced user experience
  • Faster J-Web configuration commitment

Management and Administration

• Dual-root partitioning—This feature is supported on the SRX100, SRX210, SRX240, and SRX650 devices.

  JUNOS Release 10.0 and later releases support dual-root partitioning, which allows SRX Series devices to remain functional if there is file system corruption and facilitates easy recovery of the corrupted file system.

  SRX Series devices running JUNOS Release 9.6 and earlier releases support a single-root partitioning scheme. As both the primary and backup JUNOS Software images are located on the same root partition, the system fails to boot if there is corruption in the root file system.

  The dual-root partitioning scheme guards the file system against boot failure by keeping the primary and backup JUNOS Software images in two independent bootable root partitions. If the primary root partition gets corrupted, the system can boot from the backup JUNOS Software image located in another root partition, enabling the system to remain fully functional.

  SRX Series devices that ship with JUNOS Software Release 10.0 and later releases are formatted with dual-root partitions. The SRX Series devices that run JUNOS Release 9.6 or earlier releases can be formatted with dual-root partitions when you upgrade the system to JUNOS Release 10.0 and later releases.

  Note: The dual-root partitioning feature allows SRX Series devices to remain functional if there is file system corruption and facilitates easy recovery of the corrupted file system. Although you can install JUNOS Release 10.0 and later on SRX100, SRX210, SRX240, and SRX650 devices with the single-root partitioning scheme, we strongly recommend the use of the dual-root partitioning scheme.

  While upgrading the SRX Series devices to JUNOS Release 10.0 and later, you can choose to format the storage media with dual-root partitions (strongly recommended) or retain the existing single-root partitioning. [Junos OS Administration Guide for Security Devices]

• Performance monitoring—This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices.

  This feature introduces two new CLI commands for retrieving CPU performance details:

  • show security monitoring performance spu—Displays Services Processing Unit (SPU) statistics for all FPC slots over the last 60 seconds.
  • show security monitoring performance session—Displays the number of sessions added (ramp-up rate) for the last 60 seconds.

    [JUNOS Software CLI Reference Guide]

Network Address Translation (NAT)

• NG NAT SNMP MIB—This feature is supported on SRX Series and J Series devices.

  The enterprise-specific NAT MIB includes support to the following features:

  • New source NAT—These objects represent the source NAT attributes of the translated addresses. When performing source IP address translation, the security device translates the original source IP address, the port number, or both to a different address. The resource address source pool provides the security device with a supply of addresses from which to draw when performing source NAT. The new source NAT contains objects on source IP address translation only.
  • NAT rule hit—This object monitors the NAT rule hits.
  • NAT pool hit—This object monitors the NAT pool hits.

  The new objects extend support to the port address translation (PAT) too. These objects allow users to monitor and debug the NAT functionality of the above mentioned devices.

• Persistent NAT binding for wildcard ports—This feature is supported on all SRX Series devices.

  You can specify the address-mapping option with the persistent-nat configuration statement when creating a source NAT rule using persistent NAT. This option allows requests from a specific internal IP address to be mapped to the same external IP address; internal and external ports can be any ports. An external host using any port can send a packet to the internal host by way of the mapped transport address (with a configured incoming policy from external to internal). If this option is not configured, the persistent NAT binding is for specific internal and external IP addresses and ports.

  You can only specify the address-mapping option when the persistent NAT type is any remote host and the source NAT rule action is one of the following:

  • Source NAT pool with IP address shifting
  • Source NAT pool with no port translation and no overflow pool

    [Junos OS Security Configuration Guide]

Point-to-Point Protocol over Ethernet (PPPoE)

• LN1000 mobile secure router—This feature is supported on SRX650, J2320, and J6350 devices.

  To support the credit-based flow control extensions described in [RFC–4938], PPPoE peers can now grant each other forwarding credits. The grantee can forward traffic to the peer only when it has a sufficient number of credits to do so. When credit-based forwarding is used on both sides of the session, the radio client can control the flow of traffic by limiting the number of credits it grants to the device.

  The interfaces statement includes a new radio-router attribute that replaces the resource-component-variables attribute. The radio-router attribute contains the parameters used for rate-based scheduling and OSPF link cost calculations. It also includes a new credit attribute to indicate that credit-based packet scheduling is supported on the PPPoE interfaces that reference this underlying interface. Interfaces that set the encapsulation attribute support the PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery Credit (PADC) messages in the same way that the attribute provides active support for the PPPoE Active Discovery Quality (PADQ) message.

  The credit interval parameter controls how frequently the device generates credit announcement messages. For PPPoE this corresponds to the interval between PADG credit announcements for each session.

  For example:

  [edit interfaces ge-0/0/1]unit 0 {encapsulation ppp-over-ether;radio-router {credit {interval 10;}bandwidth 80;threshold 5;}}

  Note: The resource-component-variables attribute has been deprecated, but has an alias to the radio-router variable to minimize impact on existing devices that might have been configured previously.

  To display PPPoE credit-flow information:

  user@host> show pppoe interface detail

  pp0.51 Index 73
    State: Session up, Session ID: 3,
    Service name: None,
    Configured AC name: None, Session AC name: None,
    Remote MAC address: 00:22:83:84:2e:81,
    Session uptime: 00:05:48 ago,
    Auto-reconnect timeout: Never, Idle timeout: Never,
    Underlying interface: ge-0/0/4.1 Index 72
    PADG Credits: Local: 12345, Remote: 6789, Scale factor: 128 bytes
    PADQ Current bandwidth: 750 Kbps, Maximum 1000 Kbps
      Quality: 85, Resources 65, Latency 100 msec.
    Dynamic bandwidth: 3 Kbps

  pp0.1000 Index 71
    State: Down, Session ID: 1,
    Service name: None,
    Configured AC name: None, Session AC name: None,
    Remote MAC address: 00:00:00:00:00:00,
    Auto-reconnect timeout: Never, Idle timeout: Never,
    Underlying interface: ge-0/0/1.0 Index 70
    PADG Credits: enabled
    Dynamic bandwidth: enabled

Routing Policy and Firewall Filters

• Firewall filter scaling improvement—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Up to 400 logical input interfaces (in one broadcom packet processor) can be applied with simple filters. In earlier JUNOS Software releases, the number of logical interfaces was limited to 100.

Screens

• Detection of TCP/UDP sweep attacks—This feature is supported on all SRX Series and J Series devices.

  SRX Series and J Series devices can identify and prevent TCP/UDP sweep attacks. By default, the SRX Series or J Series device allows 10 TCP or UDP packets from a single host to pass to multiple destinations within 5000 microseconds. If the number of TCP or UDP packets from a host exceeds this limit, the device logs this as a TCP or UDP sweep.

  Note: The device drops further packets from this host only if the alarm-without-drop option is not enabled. If the alarm-without-drop option is enabled, the packets are allowed to pass.

  Users can reconfigure the default threshold time period by using the following CLI commands:

  set security screen ids–option screen-name tcp tcp–sweep threshold threshold numberset security screen ids–option screen-name udp udp–sweep threshold threshold number

Security

• Captive portal—This feature is supported on all SRX Series and J Series devices.

  In a Unified Access Control (UAC) deployment, users might not be aware that they must first sign into the Infranet Controller for authentication when accessing a protected resource behind the JUNOS Enforcer. To help users sign in to the Infranet Controller, you can now configure the captive portal feature. The captive portal feature allows you to configure a policy in the JUNOS Enforcer that automatically redirects HTTP traffic destined for protected resources to the Infranet Controller or to a URL configured on the JUNOS Enforcer. [Junos OS Security Configuration Guide]

• Domain Name System Security Extensions (DNSSEC) support—This feature is supported on all SRX Series and J Series devices.

  The DNSSEC feature is enabled by default. Users can disable the DNSSEC feature by using the CLI set system services dns dnssec disable command.

  The DNS-enabled devices run a DNS resolver (proxy) that listens on loopback address 127.0.0.1 or ::1. The DNS resolver does a hostname resolution for DNSSEC. Users need to set the server IP address to 127.0.0.1 or ::1 using the set system name-server [127.0.0.1|::1] command so that the DNS resolver forwards all the DNS queries to DNSSEC instead of DNS. If this command is not set, DNS will handle all queries instead of DNSSEC.

  Users can configure secure domains and assign trusted keys to the domains by using CLI commands. Both signed and unsigned responses can be validated when DNSSEC is enabled.

• SCTP stateful support—This feature is supported on all SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Stream Control Transmission Protocol (SCTP) is an IP Transport Layer protocol. SCTP provides a reliable transport service that supports data transfer across the network, in single-IP or multi-IP cases. By configure SCTP profile, the security device can be enabled to perform stateful inspection on all SCTP traffic. The SCTP firewall supports deeper inspection too: packet filtering and limit-rate. [JUNOS Software Security Configuration Guide]

Virtual LANs (VLANs)

• 802.1X dynamic VLAN and MAC bypass—These features are supported on SRX210, SRX240, and SRX650 devices.

  SRX210, SRX240, and SRX650 devices provide for IEEE 802.1X authentication standards in an enterprise network to implement access control on Ethernet ports in switched mode. Supplicants (hosts) are authenticated when they are first connected to your LAN. By authenticating supplicants before they receive an IP address from a DHCP server, JUNOS Software prevents unauthorized supplicants from gaining access to your LAN.

  Compatible SRX Series devices can now provide the following IEEE 802.1X features on Ethernet ports configured in switched mode:

  • 802.1X dynamic VLAN assignment—Provides dynamic VLAN assignment from the RADIUS server.
  • 802.1X Guest Vlan—Allows configurable guest VLAN assignment if authentication fails or if host device does not have supplicant software on it.
  • 802.1X media access control (MAC) bypass—Configures MAC and VLAN assignment on SRX Series devices.
  • 802.1X configurable action at RADIUS timeout—Defines action to be taken in case of a RADIUS server failure or timeout (permit or deny authentication, use a cached value for authentication, or move the supplicant to another VLAN).
  • 802.1X MAC RADIUS authentication—Provides MAC authentication through RADIUS with VLAN assignment option.
  • RADIUS accounting—This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices. This feature gathers statistical data for the RADIUS accounting server for general network monitoring, analyzing and tracking usage patterns, and user billing based on the time or services accessed.
  • VoIP VLAN support—Provides dynamic VoIP VLAN assignment from the RADIUS server. Allows tagged and untagged traffic on an access port with a VLAN tag configured on a phone.
  • SRX100 supports 802.1X MAC RADIUS authentication and 802.1X media access control (MAC) bypass without VLAN assignment option.

[Junos OS Security Configuration Guide]

VPNs

• Group VPNs and dynamic policy support for group VPNs—This feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  A security association (SA) is a unidirectional agreement between VPN participants that defines the rules to use for authentication and encryption algorithms, key exchange mechanisms, and secure communications. With current VPN implementations, the SA is a point-to-point tunnel between two security devices. A group VPN extends IPsec architecture to support SAs that are shared by a group of security devices. Any-to-any connectivity is achieved by preserving the original source and destination IP addresses in the outer header. Secure multicast packets are replicated in the same way as clear-text multicast packets in the core network.

  With group VPNs, a group server manages keys and SA proposals for members of the group. Between group members that share a key, any unicast or multicast traffic that satisfies the SA proposals can be protected by the key. The group server and group members are linked by a group ID, which can be a number between 1 and 65,535. To join a group, a device must provide correct Phase 1 IKE authentication.

  In a group VPN, each key that the group server pushes to a group member is associated with an SA proposal. The SA proposal includes protocol, source address, source port, destination address, destination port, and security attributes, such as authentication method and encryption algorithm.

  On the group member, a group scope policy must be configured that defines the scope of the SA proposal managed by the group server. An SA proposal distributed from the group server is compared against the scope policy on the group member. Any addresses specified in the proposal must be within the range of addresses specified in the scope policy. An SA proposal installed on a group member in this way is called a dynamic policy.

  To configure the group server, use the group-vpn server statement options at the [edit security] hierarchy. To configure group members, use the group-vpn member statement options at the [edit security] hierarchy.

  Configure a scope policy on a group member using the policies configuration statement at the [edit security] hierarchy. Use the ipsec-group-vpn configuration statement in the permit tunnel rule to reference the group VPN configured on the member device; this allows multiple dynamic policies for the same VPN to share a single SA. [Junos OS Security Configuration Guide]

Hardware Features—SRX210 Services Gateways

• Support for 3G wireless functionality on SRX210 Services Gateways—JUNOS Software Release 10.2 supports 3G wireless functionality on SRX210 devices to provide to provide wireless WAN connectivity as backup to primary WAN links. Third-generation (3G) networks are wide area cellular telephone networks that have evolved to include high-data rate services of up to 3 Mbps. The SRX210 device has a 3G ExpressCard slot on the back panel.

  The SRX210 device supports the Juniper Networks wireless modems listed in Table 7.

  Table 7: Juniper Networks Wireless Modems Supported by the SRX210 Device

  Wireless Cards	Release Supported
  EXPCD-3G-CDMA-V: 3G EVDO ExpressCard for Verizon Wireless. Currently available from Juniper Networks.	JUNOS Software Releases 9.6, 10.0, 10.1, and 10.2.
  EXPCD-3G-CDMA-S: 3G EVDO ExpressCard for Sprint. Currently available from Juniper Networks.	JUNOS Software Releases 9.6, 10.0, 10.1, and 10.2.
  Sierra Wireless AirCard 880E/881E supporting Global System for Mobile Communications (GSM) High-Speed Packet Access (HSPA) ExpressCard. Not available from Juniper Networks.	JUNOS Software Releases 9.5, and 9.6.
  Sierra Wireless AirCard AC501/AC502 supporting Global System for Mobile Communications (GSM) High-Speed Packet Access (HSUPA). Not available from Juniper Networks.	JUNOS Software Releases 10.1, and 10.2.

Hardware Features—SRX240 Services Gateways

SRX240 Services Gateway High Memory DC Power Supply Model

This release introduces the SRX240 Services Gateway High Memory with DC Power Supply model (SRX240–DC), which includes an internal, fixed DC power supply. The DC power supply feed available on the back panel of the chassis has dual redundant power feeds that provide full power redundancy in the device.

Table 8 lists the SRX240 Services Gateway High Memory with DC Power Supply model specifications.

Table 9 lists the SRX240 Services Gateway High Memory with DC Power Supply model hardware features.

JUNOS Release 10.2 or later supports NEBS-compliant devices (SRX240 Services Gateway High Memory with AC Power Supply and SRX240 Services Gateway High Memory with DC Power Supply). These NEBS-compliant devices are available from Juniper Networks starting June 30, 2010. Contact your Juniper Networks customer service representative for more information.

Air Filters on the SRX240 Services Gateway High Memory

The following Network Equipment Building System (NEBS)-compliant SRX Series models employ an air filter to protect the device from dust entering into the system:

• SRX240 Services Gateway High Memory with AC Power Supply
• SRX240 Services Gateway High Memory with DC Power Supply

Note: An air filter is not shipped with the SRX240 Services Gateway High Memory with AC Power Supply model. To meet NEBS requirements, you must order the air filter separately. Contact your Juniper Networks customer service representative for more information.

Note: JUNOS Release 10.2 or later supports NEBS-compliant devices (SRX240 Services Gateway High Memory with AC Power Supply and SRX240 Services Gateway High Memory with DC Power Supply). These NEBS-compliant devices are available from Juniper Networks starting June 30, 2010. Contact your Juniper Networks customer service representative for more information.

The air filter available on the SRX240 Services Gateway High Memory with AC Power Supply model and the SRX240 Services Gateway with DC Power Supply model is hot-insertable and hot-removable. The air intake opening is at the right side of the chassis (when the chassis is viewed from the front side). The air filter weighs approximately 0.2 lbs (0.09 kg).

Note: The air filter must be replaced periodically.

Hardware Features—SRX210 and SRX240 Services Gateways with Integrated Convergence Services

4-Port FXS Mini-Physical Interface Module

The 4-Port Foreign Exchange Subscribers (FXS) Mini-Physical Interface Module (Mini-PIM) provides an interface for connecting telephones, fax machines, and other telephony devices to the SRX Series device. This Mini-PIM is supported on the following devices:

• SRX210 Services Gateway with Integrated Convergence Services
• SRX240 Services Gateway with Integrated Convergence Services

The 4-Port FXS Mini-PIM uses a standard RJ-11 cable.

Note: The 4-Port FXS Mini-PIM can be used only with integrated convergence services models of SRX210 and SRX240 Services Gateways and not in standalone mode.

Key Features

The following are the key features of the 4-Port FXS Mini-PIM:

• Highly programmable and globally compliant FXS interface
• International safety standard compliant
• Caller ID support
• FXS trunking

For more information on the 4-Port FXS Mini-PIM, see the SRX Series Services Gateways for the Branch Physical Interface Modules Hardware Guide.

For information on configuring the 4-Port FXS Mini-PIM, see the JUNOS Software Integrated Convergence Services Configuration and Administration Guide for SRX210 and SRX240 Services Gateways.

Hardware Features—SRX650 Services Gateways

• 2-Port 10-Gigabit Ethernet XPIM—The 2-Port 10-Gigabit Ethernet XPIM is supported on SRX650 devices.

  The 2-Port 10-Gigabit Ethernet XPIM provides a connection to high-speed Ethernet networks through branch WAN service and allows carriers to provide multiple levels of Ethernet service with a single connection option for all service ranges. The 2-Port 10-Gigabit Ethernet XPIM is a single-slot XPIM that can be installed only in the 20-gigabit GPIM slots (slot 2 or 6) on the front panel of the SRX650 Services Gateway.

  The 2-Port 10-Gigabit Ethernet XPIM contains two 10-Gigabit Ethernet interfaces with both copper and small form-factor pluggable transceiver (SFP) terminations, to support redundancy and enable the SRX650 Services Gateway to be used as a pure security service device.

  The following key features are supported on the 2-Port 10-Gigabit Ethernet XPIM:

  • Online Insertion and Removal (OIR) capable.
  • Contains a total of four ports (two SFP+ and two 10GBASE-T). Only two of the four ports can be active at any time; mix and match between the copper and fiber types is supported.
  • Receives SFP+ optics, and, at a minimum, supports these SFP+ transceivers:
    • SFPP-10GE-SR
    • SFPP-10GE-LR
    • SFPP-10GE-ER
    • SFPP-10GE-LRM
    • Copper Twin-AX 1m
    • Copper Twin-AX 3m
  • Anti-counterfeit capabilities.
  • EEE feature on copper mode to reduce power consumption.
  • Quad speed support for copper mode: 10GBASE-T IEEE 820.3an, 1000BASE-T IEEE 802.3ab, 100BASE-T IEEE 802.3u, and 10BASE-T IEEE 802.3.
  • Standard quality-of-service (QoS) features.
  • User-configuration of fiber and copper ports:
    • When the interface is configured as a copper port, a typical Ethernet configuration such as Autoneg is supported. Forced rate and link mode are allowed. Four forced and Autoneg rates are provided: 10 gigabits, 1 gigabit, 100 Mbps, and 10 Mbps.
    • When the interface is configured as a fiber port, typical configurations similar to 1-Gbps fiber (SFP) ports in the 24-port Gigabit Ethernet XPIM are supported.
  • Diagnostics for debugging and problem isolation.
  • SNMP support.
  • J-Web support.

  [Junos OS Interfaces Configuration Guide for Security Devices, SRX650 Services Gateway Hardware Guide]

Hardware Features—SRX3400 and SRX3600 Services Gateways

SRX Clustering Module for SRX3400 and SRX3600 Services Gateways

The SRX Clustering Module (SCM) is a card that you can install in an SRX3400 or SRX3600 Services Gateway to enable the dual control link feature for chassis clustering supported in JUNOS Release 10.2. You install the SCM in the RE1 slot on the rear panel of the services gateway.

Related Topics

• Known Limitations in JUNOS Release 10.2 for SRX Series Services Gateways and J Series Services Routers
• Issues 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