Juniper NETWORK AND SECURITY MANAGER - RELEASE NOTES REV 3, NETWORK AND SECURITY MANAGER Release Note
Network and Security Manager Release
Notes
December 10, 2010
Revision 3
Contents
Version Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
New or Changed Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Before You Install NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Solaris Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Upgrade Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Upgrading NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Deprecated Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Important SSL VPN and Infranet Controller Instructions . . . . . . . . . . . . . . . . . . . . . 4
NSM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Setting Up NSM to Work with Infranet Controller and Infranet Enforcer . . . . . 6
Usage Guidelines for Applying NSM Templates to SA and IC Clusters . . . . . . . 8
Recommended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Not Recommended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Maintaining the NSM GUI Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Creating a Self-Signed TLS Certificate Between the NSM Client and the
NSM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Addressed Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Release 2010.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Release 2010.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Release 2010.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
EX Series Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Devices Running ScreenOS and IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Secure Access SSL VPN SA Series and United Access Control Infranet
Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
SRX Series Services Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1Copyright © 2010, Juniper Networks, Inc.
Network and Security Manager 2010.3 Release Notes
Errata and Changes in Documentation for NSM Release 2010.3 . . . . . . . . . . . . . . 34
Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
NSM Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Copyright © 2010, Juniper Networks, Inc.2
Version Summary
Juniper Networks Network and Security Manager (NSM) is a software application that
centralizescontrol and management of your Juniper Networks devices. With NSM, Juniper
Networks delivers integrated, policy-based security and network management for all
security devices and other Juniper Networks devices in your networks. NSM uses the
technologydeveloped for Juniper NetworksScreenOSto enable and simplify management
support for previous and current versions of ScreenOS and now for Junos operating
system (Junos OS). By integrating management of all Juniper Networks devices, NSM
enhances the overall security and manageability of the Internet gateway.
New Features
The new feature in this release of NSM is support for configuring NAT on devices that
run on the Junos OS.
New or Changed Information
Version Summary
The following provides the new or changed information for this release:
•
NSM supports management of SRX Series devices in packet and mixed mode.
•
The wireless encryption configuration field, Static WEP (config > wlan > access point
> radio > virtual access point > security) has been renamed to Wireless Encryption.
•
The Comment column of the firewall policy has been moved from the last position to
the third position from the last.
Before You Install NSM
Solaris Locales
Before installing NSM on a Solaris server, you must install a specific set of locales, and
make appropriate edits to the /etc/default/init file. For more information, see the Network
and Security Manager Installation Guide.
Upgrade Considerations
This section contains information about upgrading NSM and deprecated operating
systems.
Upgrading NSM
You can upgrade to NSM 2010.3 from the following versions:
•
2008.2RX
•
2009.1RX
•
2010.1
•
2010.2
3Copyright © 2010, Juniper Networks, Inc.
Network and Security Manager 2010.3 Release Notes
NSM 2010.3 supports:
•
3000 low-end devices with 10 user connections
•
300 high-end devices with 25 user connections
Deprecated Operating System
NSM no longer supports ScreenOS version 4.X. You must upgrade your devices to
ScreenOS version 5.0 or later. NSM no longer supports Junos OS Release 9.2 or lower.
Limitations
The following items are known limitations in this version of NSM:
•
NSM does not support Junos OS downgrades. However, if you need to downgrade a
device, follow these steps:
1. From the device, use the CLI command to downgrade the image. For example:
root> request system software add <package-name> reboot
2. After the downgrade, from NSM, delete the device and then add it again.
•
For Junos OS J Series and EX Series devices—NSM Configuration Editor cannot
completely validate the configuration that an NSM user has created before sending it
to the device. The device validates the configuration when the configuration is pushed
to the device as part of the Update Device job and may return validation errors to NSM.
•
For SSL VPN SA and Infranet Controllers—Secure Virtual Workspace (SVW) settings
on the SA device cannot be managed with NSM.
•
For EX Series switches—EX Series switches running Junos OS do not support snapshots.
Therefore, users should not select the “Backup the current filesystem(s) on the device”
check box in the final page of the Install Device Software wizard.
Important SSL VPN and Infranet Controller Instructions
This section contains setup instructions and template usage guidelines for SSL VPN SA
(SA) and Infranet Controller (IC) devices.
NSM Server
•
There is no limit to the number of devices that can be simultaneously updated in NSM,
provided the configuration size on each device being updated is less than 5 MB. NSM
can execute updates in parallel across a maximum of eight devices while the remaining
update jobs are queued up.
•
If the software version of SA/IC configurations exceeds 5 MB, we recommend a
maximum of four devices per job for an appropriately sized Linux or Solaris server
running NSM.
Copyright © 2010, Juniper Networks, Inc.4
Important SSL VPN and Infranet Controller Instructions
•
Due to hardware limitations on NSMXpress, the recommended limit is two devices per
job for SA/ICs running configurations more than 5 MB.
•
The following files on the NSM software server must be edited as described below (no
changes are needed for NSMXpress):
•
In /usr/netscreen/GuiSvr/bin/.guiSvrDirectiveHandler, change Xmx10248000000
to Xmx2048000000:
$LIB_DIR/jre/bin/java -DNSROOT=$NSROOT
-DgproGDM=$DEST_DIR -DNSDIR=$DEST_DIR/var/be
-DSTART_PATH=$DEST_DIR -DBE_CFG=${CFG_FILE}
-DLOG4J_CFG=${LOG4J_CFG_FILE} -XX:PermSize=64M
-XX:MaxPermSize=64M -Xms128000000 - Xmx2048000000
com.netscreen.devicecomm.GUIDirectiveManager -version -repo ${REPO_DEST_DIR}
-conf ${SVC_CFG_FILE}
•
In /usr/netscreen/GuiSvr/var/xdb/data/DB_CONFIG, change the set_cachesize
parameter from 0 256000000 1 to 0 1024000000 4.
•
Set the shared memory to a minimum of 1 GB (kernel.shmmax = 1073741824):
•
In /etc/sysctl.conf, for Linux systems
•
In /etc/system, for Solarix systems
•
In /usr/netscreen/GuiSvr/var/xdb/specs/jax.spec, change Xmx512 to Xmx1024m:
:jvm-options (
: ("-DEMBEDDED_JVM=true")
: ("-Xms128m")
: ("-Xmx1024m")
•
In /usr/netscreen/DevSvr/bin/.devSvrDirectiveHandler, change Xmx1024000000
to Xmx2048000000:
$LIB_DIR/jre/bin/java -DNSROOT=$NSROOT -DgproDDM=$DEST_DIR
-DNSDIR=$DEST_DIR/var/be -DSTART_PATH=$DEST_DIR
-DBE_CFG=${CFG_FILE} -DLOG4J_CFG=${LOG4J_CFG_FILE}
-XX:PermSize=64M -XX:MaxPermSize=64M -Xms128000000 - Xmx2048000000
com.netscreen.devicecomm.DeviceDirectiveManager -version -repo ${REPO_DEST_DIR}
-conf ${SVC_CFG_FILE}
The servers must be restarted after you change these parameters.
5Copyright © 2010, Juniper Networks, Inc.
Network and Security Manager 2010.3 Release Notes
Setting Up NSM to Work with Infranet Controller and Infranet Enforcer
A ScreenOS firewall that is managed by NSM can also be configured as an Infranet
Enforcerin a UACsolution. To prevent conflicts between NSM and the Infranet Controller,
configure these firewall devices:
1. On the Infranet Controller, create the Infranet Enforcer instances:
a. On the Infranet Controller, select UAC > Infranet Enforcer > Connection.
b. Click New Enforcer.
c. Enter the information requested in the display.
d. Enter a password for the NACN password. You will use it again while setting up
the Infranet Enforcer. If you are setting up a cluster instead of a single box, enter
all the serial numbers in the cluster, one per line.
e. Click Save Changes.
f. Repeat Step 1b through Step 1e until all of your Infranet Enforcershave been entered.
2. If you do not have one already, create a CA certificate for each Infranet Enforcer:
a. Create a certificate signing request (CSR) for an Infranet Controller server certificate,
and use the CA certificate to sign the server certificate.
b. Import the server certificate into the Infranet Controller.
c. Import the CA certificate into the Infranet Enforcer.
3. On each Infranet Enforcer, create the Infranet Controller instance:
a. On the Infranet Enforcer, select Configuration > Infranet Auth > Controllers.
b. Click New.
c. Enter the parameters as prompted. The password in the second section must be
the NACN password you entered in Step 1.d.
d. Click OK.
e. Repeat Step 3b through Step 3d for all of the Infranet Enforcers.
f. On the Infranet Controller, select UAC > Infranet Enforcer > Connection and
check that all the Infranet Enforcers have been added.
4. On NSM, delete the Infranet Enforcer firewalls from the global domain:
a. In the global domain, select Device Manager > Devices to list all the devices.
b. Right-click each Infranet Enforcer firewall device and select Delete from the list.
5. On NSM, delete the $infranet instances from the Object Manager:
a. Select Object Manager > Authentication Servers.
Copyright © 2010, Juniper Networks, Inc.6
Important SSL VPN and Infranet Controller Instructions
b. Right-click each $infranet_n object and select Delete from the list.
c. SelectVPN Manager > VPNs, and check that you do not haveany $infranet objects
under VPN Manager. These objects are usually deleted automatically when you
remove the firewall.
6. Create a new subdomain for the Infranet Enforcers:
a. Select Tools > Manage Administrators and Domains.
b. Select the Subdomains tab.
c. Click the Add icon.
d. In the New Subdomain dialog box, enter an appropriate name for the subdomain
so you know what it will be used for, and then click OK.
e. From the drop-down list at the top left side, select your new domain. The new
domain is empty, but it can use objects from the global domain. If you do not
remove the $infranet instances from the main domain, you risk having duplicate
$infranet names. In addition, add a Single Infranet Enforcer or Infranet Enforcer
Cluster.
f. Repeat Step 5 and Step 6 for every Infranet Enforcer or Infranet Enforcer Cluster
you need to add to NSM. When finished, you should see $infranet instead of
$infranet_# in each of the domains except global.
7. In NSM, add the Infranet Enforcer objects to the new domain:
a. Select Device Manager > Devices.
b. Click the Add icon, and then select Device to start the Add Device Wizard.
c. In the New Device window, provide a name for the device, a color for its icon in
NSM, and check Device is Reachable.
d. Follow the instructions in the wizard to add and import the device.
e. Repeat Step 7b through 7d for each Infranet Enforcer device.
You must reimport the configuration each time you use an Infranet Enforcer. Otherwise,
a NACN password mismatch is possible because the Infranet Controller dynamically
changes this password periodically. It is also good practice to do a “Summarize Delta
Config” and ensure that no $infra policies are present. If there are, the Infranet
Controller has changed something on the Infranet Enforcer since you last imported
the device configuration.
NOTE: If you choose not to reimport the configuration, be sure to update the
Infranet Controller and Infranet Enforcer at the same time.
7Copyright © 2010, Juniper Networks, Inc.
Network and Security Manager 2010.3 Release Notes
Usage Guidelines for Applying NSM Templates to SA and IC Clusters
SA/IC cluster configuration data is composed of Cluster Global (CG), Node-Specific
(NS), and Node-Local (NL) data, which are abstracted in NSM as cluster objects and
cluster member objects. The cluster object contains only CG data, while the cluster
member object contains NS and NL data. Templatepromotion and application to clusters
should be compliant with the cluster abstraction.
Recommended
•
Templates that are applied to cluster objects should only include CG data. Templates
that are applied to cluster member objects should only include NS/NL data. These
guidelines apply to templates that are created from scratch or through promotion.
•
To replicate the configuration from one cluster (source) to another cluster (target)
through templates, promote the configuration from the source cluster object to a
cluster template, and then apply that template to the target cluster object.
•
To replicate the configuration from one cluster member (source) to another cluster
member (target), promote the configuration from the source cluster member object
to a member template, and then apply that template to the target cluster member
object.
Not Recommended
•
Do not apply any template that contains NS/NL data to a cluster object. Application
of a template that contains NS/NL data can result in unexpected UI behavior and
update results (such as, NS/NL data from the template being ignored or NS/NL data
in cluster objects is invisible).
•
Do not apply any template promoted from a cluster object or a standalone device to
a cluster member object. Node-specific settings in the template appear in the member
object but do not appear in the delta configuration. As a result, these settings appear
in the template but are not pushed to the back-end cluster node.
The following list shows the NS and NL configuration settings. All other settings are CG.
Node-Specific (NS) Configuration:
<nsm:path>/ive-sa:configuration/system/log/snmp</nsm:path>
<nsm:path>/ive-sa:configuration/system/log/events-log-settin gs/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/log
/user-access-log-settings/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/log
/admin-access-logsettings/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/log/sensors-log-settings/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/network
/network-overview/settings</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/external-port</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/internal-port</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/management-port</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/vlans</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/network-hosts</nsm:path>
Copyright © 2010, Juniper Networks, Inc.8
Best Practices
Best Practices
<nsm:path>/ive-sa:configuration/system/network
/network-connect/network-ip-filter</nsm:path>
<nsm:path>/ive-sa:configuration/system/clustering/properties/
configuration-settings/collection-of-network-settings</nsm:path>
<nsm:path>/ive-sa:configuration/users/resource-policies/network-connect-policies/
network-connect-node-specific-configuration</nsm:path>
<nsm:path>/ive-sa:configuration/authentication/auth-servers/collection-of-auth-server/
union-of-ace/active-directory-winnt/
settings/advanced/computer-names/ive-name</nsm:path>
Node-Local (NL) Configuration:
/ive-sa:configuration/system/configuration/dmi-agent/enabled
/ive-sa:configuration/system/configuration/dmi-agent/deviceid
/ive-sa:configuration/system/configuration/dmi-agent/hmac-key
/ive-sa:configuration/system/maintenance/push-config/acceptpush
This section contains information about recommended practices when using NSM.
Maintaining the NSM GUI Server
For optimal NSM server performance, follow these maintenance procedures every few
months.
On the NSM GUI client:
•
Delete old entries from the Job Manager in each domain.
•
Purge old database versions using Tool > Database Versions.
If the size of the NSM database in /usr/netscreen/GuiSvr/var/xdb continues to increase
considerably despite the recommended practices, you can manually remove all domain
versions using the procedure documented in KB11731. For details, see
http://kb.juniper.net/KB11731.
Creating a Self-Signed TLS Certificate Between the NSM Client and the NSM Server
A self-signed certificate is a certificate that has not been signed by a third party, such as,
a well-known Certificate Authority (CA).
To create a self-signed certificate between an NSM server and an NSM client:
1. Download the file CreateCerts.zip from
http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/BK14949/C
reateCerts.zip
2. Copy the file to the NSM server and unzip it.
#unzip createCerts.zip
9Copyright © 2010, Juniper Networks, Inc.
Network and Security Manager 2010.3 Release Notes
3. Edit the file createCerts.sh and modify the section Default certificate generation
fields to update your current installation and the corresponding contact information
of your organization.
0.organizationName_default - <Name of Customer’s
Organization>stateOrProvinceName_default - <State>localityName_default <City>countryName_default - <Country>emailAddress_default - user@example.com
4. Run the shell script #sh Createcerts.sh
NOTE: The script produces a certificate with a timestamp that is nearly
10 years beyond the current date.
The following is an example of the output when the script is executed:
root@nsm/]# sh createCerts.sh
Enter NSM installation path[/usr/netscreen]>
Generating RSA private key, 1024 bit long modulus
....................++++++
...........++++++
e is 65537 (0x10001)
Using configuration from cfg/openssl.cfg
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'State'
localityName :PRINTABLE:'City'
organizationName :PRINTABLE:'Name of the Organization'
commonName :PRINTABLE:'NSM'
emailAddress :IA5STRING:'user@example.com'
Certificate is to be certified until Aug 3 22:41:04 2019 GMT (3650 days)
Write out database with 1 new entries
Addressed Issues
Data Base Updated
Using configuration from cfg/openssl.cfg
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'State'
localityName :PRINTABLE:'City'
organizationName :PRINTABLE:'Name of the Organization'
commonName :PRINTABLE:'NSM'
emailAddress :IA5STRING:'user@example.com'
Certificate is to be certified until Aug 3 22:41:04 2019 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
Certificate was added to keystore
Copyright © 2010, Juniper Networks, Inc.10
Addressed Issues
Certificate was added to keystore
[root@nsm/]#
This step creates four files: root.pem, server.pem, truststore.ts, and keystore.ts.
NOTE: The files truststore.ts and keystore.ts consist of private keys and
must be protected.
5. On the NSM GUI server, copy the files root.pem and server.pem to
/usr/netscreen/GuiSvr/var/certDB/TrustedCA/
6. On the NSM client, copy the file trustedtore.ts and keystore.ts to
NSM_GUI_INSTALLATION/security directory. (The default directory is C:\Program
Files\Network & Security manager\security.) Note that this must be executed on all
systems where the client is installed.
7. Restart NSM GUI server services for a new certificate to be used:
#/etc/init.d/guiSvr restart
Addressed Issues
Release 2010.3
If using a high availability environment, execute: #/etc/init.d/haSvr restart.
This section includes issues addressed for NSM, ScreenOS, Secure Access SSL VPN SA
Series, Unified Access Control (UAC) Infranet Controllers, and SRX Series Services
Gateways. These release notes contain only NSM-related issues. For a complete list of
addressed issues for each device, see the release notes associated with the device.
This section describes the addressed issues in 2010.3:
•
403809—Policies cannot be edited as NSM displays a lockedby another user message
even though another user is not logged into NSM.
•
407764—With NSM, the logs of a subdomain cannot be saved on the first try. The
workaround is to quit NSM and then try saving the logs again.
•
413166—NSM displays an error when a MIP with an IP from a different subnet as the
interface IP is added on a firewall device.
•
459994—In NSM 2007.3r5, DevServer Manager crasheswhen a PCAP retrieval operation
is performed on logs.
•
465850—Uploading of the IDP 5.0 image fails in NSM after an upgrade from the
2008.2r1 to the 2008.2r2 release.
•
477726—Using templates to activate an SSG5 device results in the creation of tunnel
interfaces with blank names. Because of this, the device cannot be updated.
•
481066—SRX Series IDP severity level log information is displayed incorrectly in the
NSM Log Viewer.
11Copyright © 2010, Juniper Networks, Inc.
Network and Security Manager 2010.3 Release Notes
•
482421—The BGP neighbor configuration in a ScreenOS cluster without VSD is not
accurately synced in NSM.
•
482988—The NSM calculation of the estimated disk space required for DevSvr logs
is inaccurate (Administer > Server Manager > Servers > Disk and Log Management).
•
482995—DevSvr logs are not getting purged after the specified time interval if you set
this interval using the NSM GUI (Server Manager > Servers > Device Server > Disk and
Log Management > Number of days to retain logs).
•
483416—Accessing the policy options of an existing policy causes the NSM GUI client
to lock up, which prevents you from making any further changes.
•
486787—You cannot import or manage SRX Series devices after an upgrade. Also, the
GuiSvr core dumps if any changes were done using the NSM GUI.
•
489258—The DevSvr crashes while viewing the IDP logs in Log Viewer.
•
491015—An inconsistent export of DevSvr log data to csv format occurs when using
the devSvrCli.sh log2action utility.
•
495737—When updating the device software for an imported ScreenOS cluster device,
a warning message appears stating that the configuration in NSM and the actual device
configuration are not in sync, even when they are.
•
503179—Logs are not getting parsed because of file header corruption, resulting in a
devSvrManager crash with core.
•
503231—A sub-interfacecannot be createdon a serial interfaceon the SSG-20 platform
as the interface is not displayed in the NSM GUI.
•
505169—In NSM, the log filter is getting created only for the group and host address
objects and not for the network address object when you create the filter by
right-clicking the source or destination address column within a log.
•
507098—A GuiServer Manager core dump occurs when compiling IDP policies.
•
512215—Whenediting an imported firewall cluster configuration,even if the VR is shared
NSM displays the following error message on the zone: “Shared zone must be in shared
VR” .
•
513335—During an IDP firmware upgrade, if an error occurs, the upgrade process
continues indefinitely and cannot be stopped. With the 2010.3 release and later, a
timeout option is provided to stop this process.
•
513985—During an import for a ScreenOS cluster, the BGP neighbor configuration is
imported to cluster level instead of member level.
•
514579—PIM-SM settings or any dynamic routing protocol cannot be configured on
an imported firewall because the NSM GUI does not display the Protocolsection under
interfaces when SOS devices are added in Cluster mode.
•
516433—NSM displays an out-of-sync message when the primary device in an SRX
Series virtual cluster goes down and the secondary devices takes the primary role. The
workaround is to reconcile inventory.
•
517009—A Global MIP object cannot be created on the subinterface of a cluster as
the subinterface (redundant1) is not being listed in Object Manager.
Copyright © 2010, Juniper Networks, Inc.12
Loading...