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

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

• Software Features
• Hardware Features

Software Features

Application Layer Gateways (ALGs)

• DNS ALG—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, SRX650. JUNOS Software for SRX Series devices provides Domain Name System (DNS) support. The DNS ALG monitors DNS query and reply packets and closes the session if the DNS flag indicates that the packet is a reply message. To configure the DNS ALG, use the edit security alg dns statement at the [edit security alg] hierarchy level.

  [JUNOS Software Security Configuration Guide]

• DNS doctoring support—This feature is supported on all SRX Series and J Series devices.

  Domain Name System (DNS) ALG functionality has been extended to support static NAT. You should configure static NAT for the DNS server first. Then if the DNS ALG is enabled, public-to-private and private-to-public static address translation can occur for A-records in DNS replies.

  The DNS ALG also now includes a maximum-message-length command option with a value range of 512 to 8192 bytes and a default value of 512 bytes. The DNS ALG will now drop traffic if the DNS message length exceeds the configured maximum, if the domain name is more than 255 bytes, or if the label length is more than 63 bytes. The ALG will also decompress domain name compression pointers and retrieve their related full domain names, and check for the existence of compression pointer loops and drop the traffic if one exists.

  Note that the DNS ALG can translate the first 32 A-records in a single DNS reply. A-records after the first 32 will not be handled. Also note that the DNS ALG supports only IPv4 addresses and does not support VPN tunnels.

  [JUNOS Software Security Configuration Guide]

• MS RPC ALG—This feature is now supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  The Microsoft RPC (MS RPC) provides a way for a program running on one host to call procedures in a program running on another host. Because of the large number of RPC services and the need to broadcast, the transport address of an RPC service is dynamically negotiated based on the service program's Universal Unique IDentifier (UUID). The specific UUID is mapped to a transport address.

  JUNOS Software supports MS RPC as a predefined service to allow and deny traffic based on a policy you configure. The MS RPC ALG provides the functionality for all supported devices to handle the dynamic transport address negotiation mechanism of the MS RPC and to ensure UUID-based security policy enforcement. You can define a security policy to permit or deny all RPC requests or to permit or deny by specific UUID number. The ALG also supports route and NAT mode for incoming and outgoing requests.

  [JUNOS Software Security Configuration Guide]

• SQL ALG—This feature is now supported on SRX3400, SRX3600, and SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  Enabling the Structured Query Language (SQL) ALG on an SRX Series or J Series device allows SQL*Net traffic in SQL redirect mode to traverse an SRX Series device by creating a TCP pinhole. If the the SQL*Net traffic is not in redirect mode, it will not be handled by the SQL ALG and will instead be processed by configured firewall policies. SQL*Net is a proprietary protocol used by Oracle databases for data access and sharing over networks. Note that the SQL ALG only supports IPv4 addresses as of JUNOS Release 10.1.

  [JUNOS Software Security Configuration Guide]

• Sun RPC ALG—This feature is now supported on SRX3400, SRX3600, SRX5600, and SRX5800 line devices in addition to existing support on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  Sun Microsystems RPC provides a way for a program running on one host to call procedures in a program running on another host. Because of the large number of RPC services and the need to broadcast, the transport address of an RPC service is dynamically negotiated based on the service's program number and version number. Several binding protocols are defined for mapping the RPC program number and version number to a transport address.

  JUNOS Software supports the Sun RPC as a predefined service to allow and deny traffic based on a security policy you configure. The Sun RPC ALG provides the functionality for all supported devices to handle the dynamic transport address negotiation mechanism of the Sun RPC and to ensure program number-based security policy enforcement. You can define a security policy to permit or deny all RPC requests or to permit or deny by specific program number. The ALG also supports route and NAT mode for incoming and outgoing requests.

  [JUNOS Software Security Configuration Guide]

Chassis Cluster

• Interface link aggregation in redundant Ethernet interfaces—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 device chassis clusters.

  Link aggregation groups (LAGs) can now be established across nodes in a chassis cluster. In JUNOS Release 10.1, support for LAGs based on IEEE 802.3ad made it possible to aggregate physical interface links on a standalone device. LAGs provide increased interface bandwidth and link availability by linking physical ports and load-balancing traffic crossing the combined interface. In JUNOS Release 10.1, link aggregation has been extended to chassis cluster configuration allowing a redundant Ethernet interface (known as a reth interface in CLI commands) to add multiple child interfaces from both nodes and thereby create a redundant Ethernet interface link aggregation group.

  Other than adding more child interfaces (up to a maximum of 16; 8 per node) to a redundant Ethernet interface, no other configuration on an SRX Series device beyond the more general chassis cluster, redundancy group, and redundant Ethernet interface configuration is necessary to use this feature. It is necessary, however, for the switch used to connect the links from both nodes in the cluster to have a LAG link configured and 802.3ad enabled for each redundant Ethernet interface LAG on both nodes so that the aggregate links will be recognized.

  Standalone link aggregation group interfaces (ae) are supported on clustered devices but cannot be added to redundant Ethernet interfaces. Likewise any child interface of an existing LAG cannot be added to a redundant Ethernet interface and vice versa. The maximum number of total combined standalone aggregate interfaces (ae) and redundant Ethernet interfaces (reth) per cluster is 128.

  Redundant Ethernet interface configuration also includes a minimum-links setting that allows you to set a minimum number of physical child links in a redundant Ethernet interface LAG that must be working on the primary node for the interface to be up. The default minimum-links value is 1. When the number of physical links on the primary node in a redundant Ethernet interface falls below the minimum-links value, the interface will be down even if some links are still working.

  Note that management, control, and fabric interfaces do not support standalone LAGs or redundant Ethernet interface LAGs in JUNOS Release 10.1.

  [JUNOS Software Security Configuration Guide]

• Redundancy group IP address monitoring through a secondary interface—This feature is supported on SRX3400, SRX3600, SRX5600 and SRX5800 devices.

  In JUNOS Release 10.1, redundancy group IP address monitoring through a redundant Ethernet (reth) interface has been extended to include monitoring of addresses on secondary links as well as on primary links. Redundancy group failover can thus be tied to the health of both any IP addresses that are currently important to traffic reliability and to any IP addresses that will become important to traffic reliability in the event of a failover.

  Monitoring can be accomplished only if the IP address is reachable on a redundant Ethernet interface, and IP addresses cannot be monitored over a tunnel. IP address monitoring is not supported on redundant Ethernet interface LAGs or the child interfaces bound to a redundant Ethernet interface LAG. The feature also cannot be used on a cluster running in transparent mode. The maximum number of total monitoring IPs that can be configured per cluster remains 32 for SRX3400 and SRX3600 devices, and 64 for SRX5600 and SRX5800 devices.

  [JUNOS Software Security Configuration Guide]

Integrated Convergence Services

• DSCP marking for RTP packets generated by SRX Series Integrated Convergence Services—This feature is supported on SRX210 and SRX240 devices that have high memory, power over Ethernet capability, and media gateway capability.

  Configure DSCP marking to set the desired DSCP bits for RTP packets generated by SRX Series Integrated Convergence Services.

  DSCP bits are the 6-bit bitmap in the IP header used by devices to decide the forwarding priority of packet routing. When the DSCP bits of RTP packets generated by Integrated Convergence Services are configured, the downstream device can then classify the RTP packets and direct them to a higher priority queue in order to achieve better voice quality when packet traffic is congested. Juniper Networks devices provide classification, priority queuing, and other kinds of CoS configuration under the Class-of-Service configuration hierarchy.

  Note that the Integrated Convergence Services DSCP marking feature marks only RTP packets of calls that it terminates, which include calls to peer call servers and to peer proxy servers that provide SIP trunks. If a call is not terminated by Integrated Convergence Services, then DSCP marking does not apply.

  To configure the DSCP marking bitmap for calls terminated by Integrated Convergence Services and the address of the peer call server or peer proxy server to which these calls are routed, use the media-policy statement in the [edit services converged-services] hierarchy level.
  set services convergence-service service-class < name > dscp < bitmap >
  set services convergence-service service-class media-policy < name > term < term-name > from peer-address [< addresses >]
  set services convergence-service service-class media-policy < name > term then service-class < name >

Interfaces and Routing

• DOCSIS Mini-PIM interface—Data over Cable Service Interface Specification (DOCSIS) defines the communications and operation support interface requirements for a data-over-cable system. It is used by cable operators to provide Internet access over their existing cable infrastructure for both residential and business customers. DOCSIS 3.0 is the latest Interface standard allowing channel bonding to deliver speeds higher than 100 Mbps throughput in either direction, far surpassing other WAN technologies such as T1/E1, ADSL2+, ISDN, and DS3.

  DOCSIS network architecture includes a cable modem on SRX Series Services Gateways with a DOCSIS Mini-Physical Interface Module (Mini-PIM) located at customer premises, and a Cable Modem Termination System (CMTS) located at the head-end or data center locations. Standards-based DOCSIS 3.0 Mini-PIM is interoperable with CMTS equipment. The DOCSIS Mini-PIM provides backward compatibility with CMTS equipment based on the following standards:

  • DOCSIS 2.0
  • DOCSIS 1.1
  • DOCSIS 1.0

  The DOCSIS Mini-PIM is supported on the following SRX Series Services Gateways:

  • SRX210
  • SRX240

    The DOCSIS Mini-PIM has the following key features:

    • Provides high data transfer rates of over 150 Mbps downstream
    • Supports four downstream and four upstream channel bonding
    • Supports quality of service (QoS)
    • Provides interoperability with any DOCSIS-compliant cable modem termination system (CMTS)
    • Supports IPv6 and IPv4 for modem management interfaces
    • Supports Baseline Privacy Interface Plus (BPI+)
    • Supports Advanced Encryption Standard (AES)

    [JUNOS Software Security Configuration Guide]

• Very-high-bit-rate digital subscriber line (VDSL)—VDSL technology is part of the xDSL family of modem technologies that provide faster data transmission over a single flat untwisted or twisted pair of copper wires.

  The VDSL lines connect service provider networks and customer sites to provide high bandwidth applications (Triple Play services) such as high-speed Internet access, telephone services like voice over IP (VoIP), high-definition TV (HDTV), and interactive gaming services over a single connection. VDSL2 is an enhancement to VDSL and permits the transmission of asymmetric and symmetric (full-duplex) aggregate data rates up to 100 Mbps on short copper loops using a bandwidth up to 30 MHz. The VDSL2 technology is based on the ITU-T G.993.2 standard.

  The following SRX Series Services Gateways support the VDSL2 Mini-Physical Interface Module (Mini-PIM) (Annex A):

  • SRX210 Services Gateway
  • SRX240 Services Gateway

  The VDSL2 Mini-PIM carries the Ethernet backplane. When the Mini-PIM is plugged into the chassis, the Mini-PIM connects to one of the ports of the baseboard switch.

  The VDSL2 Mini-PIM supports following features:

  • ADSL/ADSL2/ADSL2+ backward compatibility with Annex-A, Annex-M Support
  • PTM or EFM [802.3ah] support
  • Operation, Administration, and Maintenance (OAM) support for ADSL/ADSL/ADSL2+ ATM mode
  • ATM QoS (supported only when the VDSL2 Mini-PIM is operating in ADSL2 mode)
  • MLPPP (supported only when the VDSL2 Mini-PIM is operating in ADSL2 mode)
  • MTU size of 1500 bytes (maximum)
  • Support for maximum of 10 PVCs (only in ADSL/ADSL2/ADSL2+ mode)
  • Dying gasp support (ADSL and VDSL2 mode)
• Online insertion and removal (hot swap) for SRX650 GPIMs—Online insertion and removal (OIR) functionality is supported on CPU-based and CPU-less Gigabit-Backplane Physical Interface Modules (GPIMs). You can remove or insert a GPIM without powering off the device. The following GPIMs are supported on SRX650 devices:
  • 24-port Ethernet GPIM (with and without PoE)
  • 16-port Ethernet GPIM (with and without PoE)
  • 2-port and 4-port CT1/E1 GPIM
• Implement the PPPoE-based radio-to-router protocol—This feature is supported on SRX Series and J Series devices.

  JUNOS Release 10.1 supports PPPoE-based radio-to-router protocols. These protocols include messages that define how an external device provides the router with timely information about the quality of a link's connection. There is also a flow control mechanism to indicate how much data the device can forward. The device can then use the information provided in the PPPoE messages to dynamically adjust the interface speed of the PPP links. Use the radio-router statement from the [set interfaces <unit>] hierarchy to indicate that metrics announcements received on the interface will be processed by the device.

• Class of service (CoS) for devices operating in transparent mode—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  SRX3400, SRX3600, SRX5600, and SRX5800 devices operating in Layer 2 transparent mode support the following CoS functions:

  • IEEE 802.1p behavior aggregate (BA) classifiers to determine the forwarding treatment for packets entering the device

    Note that only IEEE 802.1p BA classifier types are supported on devices operating in transparent mode.

  • Rewrite rules to redefine IEEE 802.1 CoS values in outgoing packets

    Note that rewrite rules that redefine IP precedence CoS values and Differentiated Services Code Point (DSCP) CoS values are not supported on devices operating in transparent mode.

  • Shapers to apply rate limiting to an interface
  • Schedulers that define the properties of an output queue

  You configure BA classifiers and rewrite rules on transparent mode devices in the same way as on devices operating in Layer 3 mode. For transparent mode devices, however, you apply BA classifiers and rewrite rules only to logical interfaces configured with the family bridge configuration statement.

  You configure shapers and schedulers on transparent mode devices in the same way as on devices operating in Layer 3 mode.

  [JUNOS Software Interfaces and Routing Configuration Guide]

• Layer 2 Q-in-Q tunneling—This feature is supported on SRX210, SRX240, SRX650, and J Series devices.

  Q-in-Q tunneling, defined by the IEEE 802.1ad standard, allows service providers on Ethernet access networks to extend a Layer 2 Ethernet connection between two customer sites.

  In Q-in-Q tunneling, as a packet travels from a customer VLAN (C-VLAN) to a service provider's VLAN, a service provider-specific 802.1Q tag is added to the packet. This additional tag is used to segregate traffic into service-provider-defined service VLANs (S-VLANs). The original customer 802.1Q tag of the packet remains and is transmitted transparently, passing through the service provider's network. As the packet leaves the S-VLAN in the downstream direction, the extra 802.1Q tag is removed.

  There are three ways to map C-VLANs to an S-VLAN:

  • All-in-one bundling—Use the dot1q-tunneling statement at the [edit vlans] hierarchy to map without specifying customer VLANs. All packets from a specific access interface are mapped to the S-VLAN.
  • Many-to-one bundling—Use the customer-vlans statement at the [edit vlans] hierarchy to specify which C-VLANs are mapped to the S-VLAN.
  • Mapping C-VLAN on a specific interface—Use the mapping statement at the [edit vlans] hierarchy to map a specific C-VLAN on a specified access interface to the S-VLAN.

  Table 3 lists the C-VLAN to S-VLAN mapping supported on SRX Series and J Series devices.

  Table 3: C-VLAN to S-VLAN Mapping Supported on SRX Series and J Series Devices

  Mapping	SRX210	SRX240	SRX650	J Series (PIM)
  All-in-one bundling	Yes	Yes	Yes	Yes
  Many-to-one bundling	No	No	Yes	No
  Mapping C-VLAN on a specific interface	No	No	Yes	No

  Integrated bridging and routing (IRB) interfaces are supported on Q-in-Q VLANs for SRX210, SRX240, SRX650, and J Series devices. Packets arriving on an IRB interface on a Q-in-Q VLAN are routed regardless of whether the packet is single or double tagged. The outgoing routed packets contain an S-VLAN tag only when exiting a trunk interface; the packets exit the interface untagged when exiting an access interface.

  In a Q-in-Q deployment, customer packets from downstream interfaces are transported without any changes to source and destination MAC addresses. You can disable MAC address learning at both the interface level and the VLAN level. Disabling MAC address learning on an interface disables learning for all the VLANs of which that interface is a member. When you disable MAC address learning on a VLAN, MAC addresses that have already been learned are flushed.

  [JUNOS Software Interfaces and Routing Configuration Guide]

• Layer 2 Link Layer Discovery Protocol (LLDP) and Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED)—This feature is supported on SRX100, SRX210, SRX240, SRX650, and J Series devices.

  Devices use LLDP and LLDP-MED to learn and distribute device information on network links. The information allows the device to quickly identify a variety of systems, resulting in a LAN that interoperates smoothly and efficiently.

  LLDP-capable devices transmit information in Type Length Value (TLV) messages to neighbor devices. Device information can include specifics, such as chassis and port identification and system name and system capabilities. The TLVs leverage this information from parameters that have already been configured in the Juniper Networks JUNOS Software.

  LLDP-MED goes one step further, exchanging IP-telephony messages between the device and the IP telephone. These TLV messages provide detailed information on PoE policy. The PoE Management TLVs let the device ports advertise the power level and power priority needed. For example, the device can compare the power needed by an IP telephone running on a PoE interface with available resources. If the device cannot meet the resources required by the IP telephone, the device could negotiate with the telephone until a compromise on power is reached.

  LLDP and LLDP-MED must be explicitly configured on uPIMs (in enhanced switching mode) on J Series devices, base ports on SRX100, SRX210, and SRX240 devices, and Gigabit-Backplane Physical Interface Modules (GPIMs) on SRX650 devices. To configure LLDP on all interfaces or on a specific interface, use the lldp statement at the [set protocols] hierarchy. To configure LLDP-MED on all interfaces or on a specific interface, use the lldp-med statement at the [set protocols] hierarchy.

  [JUNOS Software Interfaces and Routing Configuration Guide]

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

  When promiscuous mode is enabled on a Layer 3 Ethernet interface, all packets received on the interface are sent to the CP/SPU regardless of the destination MAC address of the packet. You can also enable promiscuous mode on chassis cluster redundant Ethernet interfaces and aggregated Ethernet interfaces. If you enable promiscuous mode on a redundant Ethernet interface, promiscuous mode is then enabled on any child physical interfaces. If you enable promiscuous mode on an aggregated Ethernet interface, promiscuous mode is then enabled on all member interfaces.

  To enable promiscuous mode on an interface, use the promiscuous-mode statement at the [edit interfaces] hierarchy.

  [JUNOS Software Interfaces and Routing Configuration Guide]

Intrusion Detection and Prevention (IDP)

• IDP in an active/active chassis cluster—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  Intrusion Detection and Prevention (IDP) can now monitor traffic on active/active chassis clusters. As in active/passive clusters, sessions already in progress that fail over or fail back are not inspected by IDP in an active/active cluster. New sessions created after a failover will, however, be inspected by IDP. There are no changes to IDP deployment or logging as a result of extending support to active/active high-end device clusters.

  IDP also now supports chassis cluster in-service software upgrades (ISSUs), which means that new sessions will continue to be inspected during the ISSU. However, because ISSU requires the nodes to fail over and fail back as the upgrade proceeds, IDP monitoring of any sessions that fail over will cease. It should not be necessary to restart IDP once the ISSU is completed. Note that IDP ISSU support is available on both active/passive and active/active chassis clusters.

  [JUNOS Software Security Configuration Guide]

• IDP application identification enhancement for extended applications with threat prevention support—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  With the increased use of application protocol encapsulation, the need arises to support the identification of multiple different applications running on the same Layer 7 protocols. In order to do this, the current application identification layer is split into two layers: application and protocol. New extended application signatures have been added to identify these extended applications.

  [JUNOS Software Security Configuration Guide]

• CLI enhancements supported for J-Web—This feature is supported on SRX Series and J Series devices.

  Additional functionality has been added to existing IDP J-Web pages for several new CLI commands that perform tasks such as the following: list detailed security download status information, list subscriber policies, add additional IDP packet counters to differentiate a packet drop that is the result of a policy from a legitimate drop or an error drop. There are several more newly added commands.

  [JUNOS CLI Reference Guide]

• SNMP MIB for IDP Monitoring—This feature is now supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices in addition to existing support on SRX100, SRX210, SRX240, and SRX650 devices.

  [JUNOS Software Security Configuration Guide]

• Application-level DDoS logging—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices with IDP enabled.

  IDP now provides logging for application-level DDoS events. IDP generates three types of application-level DDoS event logs: attack, state transition, and ip-action. These event logs provide visibility into the application-level DDoS state and provide notifications on occurrences of application-level DDoS attacks for each protected application server.

  [JUNOS Software CLI Reference, JUNOS Software Security Configuration Guide]

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 4 provides details of BIOS components supported for different platforms.

  Table 4: 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 5 provides you the CLI commands used for manual BIOS upgrade.

  Table 5: 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

Network Address Translation (NAT)

• Increased maximum number of source NAT rules supported—This feature is supported on SRX Series and J Series devices.

  JUNOS Release 10.1 increases the number of source NAT rules and rule sets that you can configure on a device. In previous releases, the maximum number of source NAT rule sets you could configure on a device was 32 and the maximum number of rules in a source NAT rule set was 8.

  JUNOS Release 10.1, the maximum number of source NAT rules that you can configure on a device are:

  • 512 for J Series, SRX100, and SRX210 devices
  • 1024 for SRX240 and SRX650 devices
  • 8192 for SRX3400, SRX3600, SRX5600, and SRX5800 devices

  These are systemwide maximums for total numbers of source NAT rules. There is no limitation on the number of rules that you can configure in a source NAT rule set as long as the maximum number of source NAT rules allowed on the device is not exceeded.

Note: This features does not change the maximum number of rules and rule sets you can configure on a device for static and destination NAT. For static NAT, you can configure up to 32 rule sets and up to 256 rules per rule set. For destination NAT, you can configure up to 32 rule sets and up to 8 rules per rule set.

Point-to-Point Protocol over Ethernet (PPPoE)

• LN1000 mobile secure router—This feature is supported on J2320, J6350, and SRX650 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 router.

  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 router 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 routers that may 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

Virtual LANs (VLANs)

• Flexible Ethernet services—This feature is supported on SRX210, SRX240, SRX650, and J Series devices.

  Use flexible Ethernet services encapsulation when you want to configure multiple per-unit Ethernet encapsulations. This encapsulation type allows you to configure any combination of route, TCC, CCC, and VPLS encapsulations on a single physical port. Aggregated Ethernet bundles cannot use this encapsulation type.

  For ports configured with flexible Ethernet services encapsulation, VLAN IDs from 1 through 511 are no longer reserved for normal VLANs.

VPNs

• Increased maximum number of VPN tunnels supported—This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

  VPN supports a maximum of 10000 site-to-site VPN tunnels.

WLAN

• AX411 Access Point clustering—The AX411 Access Point is a Layer 2 device that connects wireless communication devices together to create a wireless network. The access point is connected to the wired network and relays data between the wired and the wireless network. Multiple access points form a part of a bigger wireless network and can be clustered together.

  The access point cluster is a dynamic, configuration-aware group of access points in the same subnet of a network. A cluster can have up to sixteen member access points. Clusters can share various configuration information such as virtual access point (VAP) settings and quality-of-service (QoS) queue parameters. Any change in configuration on one access point will propagate to all other access points in the cluster. Similarly, any new access point introduced to the cluster will adopt the configuration of other access points in the cluster.

  Access points are supported on the following SRX Series Services Gateways:

  • SRX210
  • SRX240
  • SRX650

  [JUNOS Software WLAN Configuration and Administration Guide]

Hardware Features

Support for 3G wireless functionality on SRX210 Services Gateways—JUNOS Software Release 10.1 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 6.

For more information on installing 3G ExpressCards, see the SRX210 Services Gateway Hardware Guide. For more information on configuring the 3G interface, see the JUNOS Software Interfaces and Routing Configuration Guide.

Related Topics

• Known Limitations in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
• Issues in JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers
• Errata and Changes in Documentation for JUNOS Release 10.1 for SRX Series Services Gateways and J Series Services Routers