50 Minuteman Rd.
Andover, MA 01810
(978) 684-1000

CUSTOMER RELEASE NOTES

NetSight® Atlas Router Services Manager
Version 2.1.1
January 2004

INTRODUCTION:

  NOTE: When this topic is opened from the CD-ROM, the links from this topic to other help topics will not work (404 - not found). Links within the topic will work and once you've installed Router Services Manager, you can launch the help system and access help for all topics.

NetSight Atlas Router Services Manager provides a suite of tools that you can use to configure ACLs (Access Control Lists) and Firewall features for the Enterasys Networks routers on your network. Two versions of Router Services Manager are available:

Both versions of Router Services Manager let you perform such operations as:

It is recommended that you thoroughly review these release notes prior to the installation or upgrade of this product.

SOFTWARE CHANGES AND ENHANCEMENTS

Software Changes

This update to Router Services Manager (Version 2.1.1) adds support for interfaces created on ADSL NIMs on the XSR.

  NOTE: ADSL interfaces on the XSR differ from the other XSR interface types. Subinterfaces on ADSL NIMs that support firewall can have ACLs applied to them. However, parent interfaces do not participate in the firewall and cannot have ACLs applied to them even if they don't have subinterfaces.
The following restrictions and limitations have been fixed in NetSight Atlas Router Services Manager Version 2.1:

General
The problem of cutting off right-mouse popup menus while the Router Services Manager window maximized has been corrected.
The ArrayIndexOutOfBoundsException, Java Exception that occurred when dragging and dropping a device into a Device Group has been corrected.
Router Services Manager now permits greater flexibility in configuring the monitor logging level in XSR devices. Refer to Configuration Considerations for more information on settings for monitor logging in XSR devices.
(Solaris only) The problem causing a Solaris system to hang when dragging and dropping multiple ACLs from one ACL Folder to another has been resolved.
This version of Router Services Manager does not support opening an ACL Manager, Release 1.1 database. Therefore, the previously reported problems associated with checking the validity of rules from an ACL Manager, Release 1.1 database no longer exist.
Firewall
You can no longer create Policies in Router Services Manager using a Command Filtered Service containing non-alphanumeric CLS commands (e.g., !, ?, $). This fixes the problem of Firewall Enforce failures for these policies.
Router Services Manager will now report an error when attempting to enforce a Command Filtered Service where the destination port has been modified. Previously, the enforce would appear to be successful, but a subsequent verify would fail.

Software Enhancements

The following enhancements have been added in this release of NetSight Atlas Router Services Manager:

SYSTEM REQUIREMENTS

Supported Platforms

The system requirements for operating Router Services Manager are listed here.

UNIX® Operating System Patches

Before installing Router Services Manager on the UNIX platform, be sure to install the latest patches for your operating system. You can download the most recent operating system patches from http://sunsolve.sun.com/.

Devices

SNMP must be enabled on your devices to allow them to be managed by Router Services Manager.

PRODUCT FIRMWARE SUPPORT:

The firmware versions listed here support a variety of hardware modules. Router Services Manager has been qualified against the latest revisions of these firmware versions. It is recommended that you keep your firmware up-to-date. Other revisions of these firmware versions may support Router Services Manager operations, however they were not specifically qualified with this release of NetSight Atlas Router Services Manager.

Status Version No. Revision No. Product Type
Release E9.0.7
E9.0.7
E9.0.8
E9.1.3
E9.1.7 		.7
.8
.0
.0
.0 		X-Pedition
Release 5.0.0
6.0.0 		.xx
.xx 		XSR
Release 02.05.03
02.06.0x
03.00.0x 		-- Matrix E1
Release 03.00.0x -- Matrix N-Series

INSTALLATION:

Router Services Manager can be installed on the Windows NT, Windows 2000, or Windows XP platform, or the UNIX Solaris 2.7 or Solaris 2.8 platform. The Router Services Manager Installer (InstallAnywhere® by Zero G Software, Inc.) leads you through a series of windows that ask you for all the information required in order to install NetSight Atlas Router Services Manager. When you finish with the series of windows, Router Services Manager is installed according to your specification. For complete installation information and instructions, refer to the Installation help topic, and the instructions available on the web site: www.enterasys.com/netsight/.

  NOTE: On Windows 2000 or Windows XP systems, you must be logged on as an Administrative user, or as a user that is a member of the Administrators Group or the Power Users Group.

Evaluation Copy

When you install Router Services Manager, you can select to install a 30-day Evaluation Copy.

To convert from an evaluation copy of Router Services Manager to a purchased copy, contact your Enterasys Networks Representative to purchase the software and receive a License. You do not need to reinstall the software to perform the conversion.

  NOTE: Converting from an evaluation copy to the limited (10-device) version of Router Services Manager imposes a 10-device limit. If you created more than 10 devices while using the evaluation copy (your database contains more than 10 devices), access to the Device Access Wizard will be denied and you will not be able to perform Save to Startup, Refresh Device Data, Enforce, or Verify operations until you delete devices from the database in order to reduce the device count to the 10 device limit.

Upgrading from a prior ACL Manager or Router Services Manager Release

When upgrading to the current Router Services Manager release from ACL Manager 1.2 or a prior Router Services Manager release, the installation automatically copies (and renames) several resource and configuration files from your prior installation into the new Router Services Manager directory or into the common NetSight Atlas area. However, any User-defined Well Known protocols are not automatically ported into the Router Services Manager. If you defined any well-known protocols in the prior release of ACL Manager, Router Services Manager, or one of the other NetSight Atlas applications, you must define your unique protocols again after installing Router Services Manager.

Also, if you have modeled XSR devices in ACL Manager, you must Refresh Device Data following installation to update the existing device information for devices that support Firewall.

When upgrading from ACL Manager 1.1 or earlier, you must handle several files manually as follows:

  1. Copy the .templates folder
        From:
    <install area>\Enterasys Networks\NetSight Atlas ACL Manager
        To:
    <install area>\Enterasys Networks\NetSight Atlas Router Services Manager.

  2. Copy the aclmgr.packetdefs file (if one exists)
        From:
    <install area>\Enterasys Networks\NetSight Atlas ACL Manager
        To:
    <install area>\Enterasys Networks\NetSight Atlas Router Services Manager.

  3. Copy the <user(s)> folder(s)
        From:
    <install area>\Enterasys Networks\NetSight Atlas ACL Manager\Users
        To:
    <install area>\Enterasys Networks\NetSight Atlas Shared\Users.

  4. Open the .amgrrc file in the \Enterasys Networks\NetSight Atlas Shared\Users\<username> folder with a text editor and Save As .rsmrc.

  5. After launching the application, open the database (filename.amd) used with the earlier version of ACL Manager, located in <install area>\Enterasys Networks\NetSight Atlas ACL Manager and Save the database as filename.rsd.

Installing and Running with NetSight Atlas Console

When installed on a system where you are running NetSight Atlas Console, Router Services Manager is automatically added to the Applications menu in Console. When installing in this configuration on Solaris systems, the user installing Router Services Manager must have write access to the NetSight.properties file in the /var/Enterasys_Networks directory.

CONFIGURATION CONSIDERATIONS

Devices

1. It is recommended that you do not use a workstation configured for DHCP (Dynamic Host Configuration Protocol) to manage your Firewall-enabled devices. The workstation where you are running Router Services Manager should have a static IP address. If you do use a workstation that is configured for DHCP, you must modify the MgmtWorkstations Network Object Group to include the subnet that encompasses potential IP addresses that could be assigned to the management workstation.

2. Router Services Manager does not manage ACLs used for Layer 4 bridging on X-Pedition and Matrix E1 routers.

3 (XP Native devices only) Do not set the device console level to fatal or error. Router Services Manager will not be able to communicate with a device. Set console level to warning/info via the CLI.

4. (XSR devices only) This version of Router Services Manager permits greater flexibility in configuring the monitor logging level in XSR devices. When creating a new device or when refreshing device information, Router Services Manager attempts to contact the device through the CLI. After the initial contact, Router Services Manager inserts a 1-second delay to accommodate the interval when logging messages are being presented, preceding a command prompt. You can set the delay to a value between zero and ten seconds. If logging is set to off in your XSR devices, the delay is not needed and you can set the delay in Router Services Manager to zero.

When logging is used, Router Services Manager can contact the device regardless of the logging monitor setting and typically, the default, 1-second delay is sufficient. However, you may need to increase the delay to account for network conditions. If, when you refresh a device and interfaces for the device are removed or, when creating a new device, the device is created without interfaces, you may need to adjust the delay. To adjust the delay:

  1. Shut down Router Services Manager.
  2. Navigate to the Router Services Manager install area:

    Windows - <install area>\Enterasys Networks\NetSight Atlas Router Services Manager

    Unix - <install area>/Enterasys_Networks/NetSight_Atlas_Router_Services_Manager

  3. Using a text editor, open the following file for your system:

    Windows - Router_Services_Manager.lax
    Unix - RouterServicesManager

  4. Add the following information to the file:

    Unix - insert the following string into the line after the last export statement:

         -DxsrTelnet.loggingQueryPause=<delay in milliseconds>

    Use spaces to separate this entry from others on the same line. For Example, the following entry (red text) sets the delay to 5 seconds:

        /disk1/Enterasys_Networks/NetSight_Atlas_Router_Services_Manager/jre/bin/java -Xms32m -DxsrTelnet.loggingQueryPause=5000 -DToolbar.SmallIcons=false ...

    Windows - add the following line at the beginning of the file:

         xsrTelnet.loggingQueryPause=<delay in milliseconds>

    Where delay in milliseconds is the waiting interval required to accommodate logging messages.

    For example, to set the delay to 3 seconds, enter:

    xsrTelnet.loggingQueryPause=3000

    To set the delay to zero, enter:

    xsrTelnet.loggingQueryPause=0

  5. Save the file and restart Router Services Manager.

5. Do not configure a Log-in Banner in the device using the strings, Username:, Password:, %SYS-W-NOPASSWD, or %TELN immediately following a newline character. When these keywords are configured in the device Log-in Banner, Router Services Manager cannot write information to or retrieve information from the device.
6. Matrix N-Series devices must be created using the community name for the device's switch context and an IP address for a routed interface. Router Services Manager reports a no such name error when creating the device if a wrong contexts are used.
7. You cannot create a Matrix N-Series device model for a Matrix N-Series that is running pre-release 03.00.0x firmware. Router Services Manager supports Matrix N-Series devices beginning with firware release 03.00.0x. If you attempt to create the device running an earlier release using the IP address for the switch context, Router Services Manager reports an SNMP error. Using an IP address for a routed interface will report no such name error.

Device CLI

Use care when entering commands through the device CLI. The following circumstances can cause operational problems:

1. (XP Native devices only) Use complete keywords with CLI commands. Router Services Manager will not interpret incomplete keywords. With the cli set command completion off in the active configuration on the device, the CLI accepts the following entries:

acl acl1 pe ip (where pe = permit)

acl acl1 de ip (where de = deny)

acl acl1 deny tc (where tc = tcp)

acl acl1 deny ip-pro (where ip-pro = ip-protocol)

acl acl1 app interface Intf output (where app = apply)

acl acl1 apply int Intf input (where int = interface)

acl acl1 apply serv http (where serv = service)

Router Services Manager ignores the above ACL commands, as well as other lines with incomplete keywords. The entries are not read into Router Services Manager and no event is logged.

2. (XP Native devices only) Blanks are not interpreted the same as ANY when creating an ACL Rule. The CLI does not consider the following to be duplicates:

acl Test permit icmp

acl Test permit icmp any any

Importing this ACL from the device, creates two rule entries in Router Services Manager for the ACL Test.

3. (XP Native devices only) Avoid using quotation marks (") in ACL names. Rename ACLs containing quotation marks via the CLI.
4. (XP Native devices only) Avoid using the keyword all-ip in ACLs created through the device CLI.

ACLs with the keyword all-ip do not get imported into Router Services Manager and if an Enforce is done with the Options set to Remove unused ACLs from the device, ACLs using the keyword all-ip will not be removed from the device.

5. Do not use the device's CLI to apply an EOS ACLs without rules to an interface. If an EOS ACL that has no rules is applied to an interface through a device's Local Management (CLI), a subsequent Enforce operation will not remove this ACL from the interface. Verifying ACLs on the device will fail.

WindowsTM 2000

1. You should disable the Guest account when running Router Services Manager on a WindowsTM 2000 host system. Windows 2000 allows a user without an account on the machine to login using the Guest account. This is a potential security problem.

NETSIGHT ATLAS COMPATABILITY

Router Services Manager's interoperability and concurrent application capabilities are listed below:

NMS Platform Version No. Support
NetSight Atlas Console 1.0 Yes
NetSight Atlas Console 1.1 Yes
NetSight Atlas Console 1.2 Yes

KNOWN RESTRICTIONS AND LIMITATIONS

The known restrictions and limitations for this release of NetSight Atlas Router Services Manager are listed below. Solutions for these restrictions and limitations are noted, if available.

Install/Uninstall

Problem 1: (Windows NT/2000/XP only) An evaluation of your system is not automatically performed during the installation. If system requirements are not met, the install will take place, but results will be unpredictable.
Solution: Verify that all Windows NT/2000/XP system requirements are met prior to installing Router Services Manager.
Problem 2: (Solaris only) In the Select Destination window of the Installer, if you click Browse and then double click to select a directory, the OK button doesn't work.
Solution: You must select the directory using a single click instead of a double click.
Problem 3: (Solaris only) The Installer does not come up, due to path problems.
Solution: Ensure that /usr/usb does not precede /bin in your path. To do this, in a Unix window, type which chown. If the result is /usr/ucb/chown, replace /usr/ucb with /bin in your path. If the result is /bin/chown, the path is not the problem.
Problem 4: The system space requirement stated in the install program is not correct.
Solution: Use the requirements stated in the latest copy of these Release Notes - System Requrements.

Router Services Manager

General

Problem 1: (XP Native devices only) Router Services Manager will be unable to communicate with a device if its console level has been set to fatal or error.
Solution: Set console level to warning/info via the CLI. Refer to Device General Configuration Considerations.
Problem 2: (Solaris only) Dragging and Dropping multiple ACLs from one ACL Folder to another, in the right panel, sometimes causes the paste icon to appear and the Solaris system to hang.
Solution: Close the application and save your work, if desired.
Problem 3: (Solaris only) If you launch Router Services Manager and Policy Manager from the same xterm windows and then Copy and Paste rules in the left panel of one applications, returning to the other application causes a Java Exception:

Exception "java.lang.ClassNotFoundException: com.enterasys.netsight.controls. policy.tree.RuleTreeNode"while constructing DataFlavor for: application/ x-java-serialized-object; class=com.enterasys.netsight.controls.policy.tree. RuleTreeNode

Solution: Launch applications from separate xterm windows.
Problem 4: The Create Device Wizard will hang if a system name for a Matrix E1 device contains a greater than symbol (>).
Solution: Avoid the greater than symbol in these device names.
Problem 5: Router Services Manager does not manage ACLs used for Layer 4 bridging on X-Pedition and Matrix E1 routers.
Problem 6: (Windows NT, XP, and 2000 only) On Windows systems, Router Services Manager treats domain administrators as non-administrative users and limits their access to Read-Write. Therefore, with User Authorization disabled, if you launch Router Services Manager as Administrator for your domain, you will not be granted administrative access in Router Services Manager. Instead, you will be granted only Read-Write access, which denies access to the User Authorization view and prevents you from adding users in the application.
Solution: Login to Router Services Manager as an administrative user on your local Windows system and enable User Authorization by adding a user and applying Administrator privileges. You can now logout of Router Services Manager, then login again as the user just added to the Router Services Manager database and you will be granted administrative access.
Problem 7: Do not configure a Log-in Banner in the device using the strings, Username:, Password:, %SYS-W-NOPASSWD, or %TELN immediately following a newline character. When these keywords are configured in the device Log-in Banner, Router Services Manager cannot write information to or retrieve information from the device.
Problem 8: (Solaris only) On UNIX systems, where Secure Shell (ssh) is used for XSR CLI Access, ssh creates a .ssh directory in the Router Services Manager user's home directory and within it, creates a known_hosts text file ($HOME/.ssh/known_hosts). The known_hosts file contains an encoded ssh fingerprint for each device that Router Services Manager has contacted through ssh. If you are already using a shell version of openssh on your system, then a known_hosts file may already exist.

If a device fingerprint changes (as when encryption keys are changed and the device generates a new ssh fingerprint), when Router Services Manager connects to the device successfully through ssh, a new (encoded) fingerprint will be added to the known_hosts file. Consequently, the size of the known_hosts file can grow.

Solution: You may wish to periodically inspect the known_hosts file and delete old fingerprint entries.
Problem 9: (Windows and XP Native device only) XP Native devices present different fingerprints to PuTTY and openSSH. Using a fingerprint retrieved by openSSH to specify a fingerprint on a Windows system (using PuTTY) will result in an error message: Expected SSH fingerprint did not match device fingerprint.
Solution: Do not use a fingerprint that was retrieved using openSSH to specify a fingerprint in Router Services Manager (CLI Access - Local Authentication - Encrypt session via SSH) on a your Windows system.
Problem 10: The Tools menu and Device right-click popup menu flickers after dragging and dropping a device from the right panel into a user-defined device group. This makes it impossible to reliably select items from these menus.
Solution: Use the Add/Remove Devices option from the Device Group, right-click popup menu, to add devices to a device group.
Problem 11: Matrix N-Series devices must be created using the community name for the device's switch context and an IP address for a routed interface. Router Services Manager reports an error when creating the device if a wrong contexts are used.
Problem 12: (X-Pedition only) The upcoming release of XP firmware version (E9.1.8.0) will provide support the use of the Service Type Attribute on a RADIUS server. However, this feature is not supported with release 2.1 of Router Services Manager. If the Service Type Attribute is configured on your RADIUS server, Router Services Manager cannot successfully authenticate or refresh device information. The application hangs with the telnet session locked up.
Solution: Do not configure your RADIUS server to use the Service Type Attribute or wait for Router Services Manager, Release 2.2, when this feature will be supported.
Problem 13: A mask is required when setting up an IP address for a loopback interface on Matrix N-Series devices. Router Services Manager issues a show int loopback # CLI command to retrieve the IP address and mask that appears in the Summary tab for a Loopback interface. However because of a firmware anomaly, the Matrix N-Series device may not return a mask value. When this happens, the Primary address shows as Not Assigned and the following warning message is displayed in the Event Log on Router Services Manager: WARN - (S170-84\qa) 10.20.79.2: Router 2: Could not parse an IP Address on interface loopback 3.
Solution: This will be fixed in a future release of firmware.
Problem 14: When creating a Matrix E1 or Matrix N-Series device that has an interface that is associated with a Dynamic VLAN, Router Services Manager incorrectly reports that the VLAN does not exist.

For example:

Router 2: An interface has been created using VLAN 4, but the VLAN does not exist on 172.16.39.7

Problem 15: When using the ACL Wizard to create a Common ACL ICMP rule, you can enter an ICMP Message Type and ICMP Message Code. However, these parameters are not relevant for the ICMP rule type in a Common ACL and they are ignored.
Problem 16: (XP Native only) Router Services Manager will not create a device model for an XP Native device, with firmware version 9.0.7.8 or greater, if the router is configured to perform RADIUS authentication for entering enable mode.
Solution: Configure the router to perform RADIUS authentication for logging in to the device and a system password for entering enable mode.
Problem 17: (Solaris only) Router Services Manager will report a Java exception, UnknownHostException when assigning ACLs to a device interface if the workstation where Router Services Manager is running is unable to resolve its own hostname.
Solution: Set the hostname for the Router Services Manager host in your system's configuration files (i.e. /etc/hostname.hme0, hosts, etc.).

Importing ACLs/Device Lists

Problem 1: (XP Native devices only) Router Services Manager will not import ACLs from a device if the ACL name contains one quotation mark ("). For example, an ACL named abc"def will not be imported.
Solution: Rename ACLs containing a single quote via the CLI. Refer to Device CLI Configuration Considerations.
Problem 2: (XP Native devices only) ACLs created through the device CLI and applied using the keyword all-ip to all interfaces do not get imported into Router Services Manager. No error messages are reported/recorded in the Event Log for this error.

If an Enforce is done with the Options set to Remove unused ACLs from the device, ACLs using the keyword all-ip are not removed from the device.

Solution: Avoid using the keyword all-ip. Refer to Device CLI Configuration Considerations.
Problem 3: Import ACLs from File - Router Services Manager will not import a rule that is incomplete or that it does not recognize from a file.

For example:

  1. Create an import (text) file with one ACL (three rules):

    acl Test deny ip any any any any

    acl Test deny ip.8.8.8.8/32
       (typo, is not recognized by Router Services Manager)
    acl xyz ip
       (incomplete rule ignored by Router Services Manager)

  2. Import the ACL from File (File > Import > ACLs From File).

Notice the ACL, Test is created, but contains only one rule. No error message is recorded in the Event Log. As long as there are good rules in the same ACL, Router Services Manager still creates the ACL, but just skips the bad rule(s). This is different from the case where a bad rule has an invalid field (i.e. dest IP=a.b.c.d). When an invalid field is detected, Router Services Manager does not create the ACL, even if there are some good rules in the same ACL.

Solution: Be sure that lines in the file are correct up to and including the rule type keyword.
Problem 4: Import Device List From File operations fail if the device list includes attribute values with space characters (for example, "authpwd=pass word" vs. "authpwd=password").
Solution: Device lists do not support space characters in attribute values. Remove any space characters from your attribute values and then re-import the device list.
Problem 5: When an ACL is imported that is a duplicate of an existing ACL in the Imported ACLs folder, then the duplicate ACL can be edited, but not saved using the ACL wizard. This is because Router Services Manager appends a space and a bracketed number (ACL Name [1]) to the name and this is seen as an illegal ACL name.
Solution: Move (drag) the duplicate ACL to the Cataloged ACLs folder where it can be opened, edited, and saved using the ACL Wizard.
Problem 6: When importing a device list from a file containing any unrecognized device definitions (either incorrect format of a typo in one or more parameters) for one or more devices, the import is reported as successful, even though the devices for the unrecognized lines are not created. The successful completion does not imply that all devices were successfully imported, only that the import file was located and read successfully.
Solution: Always carefully read the import message that reports the number of devices created to be sure that all of the expected devices were created by the import.

Verifying, Applying, and Enforcing ACLs

Problem 1: (XP Native devices only) Router Services Manager will not Verify, Enforce or Apply ACLs on interfaces if the interface name contains any quotation marks ("). For example, interfaces named in"t3, "int3", or "in t3" will not work properly.
Solution: Rename interfaces containing quotes via the CLI. Refer to Device CLI Configuration Considerations.
Problem 2: (XP Native devices only) Router Services Manager will not operate correctly when CLI commands contain incomplete keywords--probably the result of entering a partial keyword while CLI command completion was disabled in the device. For example: If acl MyACL pe ip was entered instead of acl MyACL permit ip.
Solution: Re-enter the ACL related configuration lines with fully completed keywords. Refer to Device CLI Configuration Considerations.
Problem 3: If an Enforce is cancelled using the Cancel button in the Progress window (showing a progress bar), the device can be left in an unspecified state. Likewise, cancelling a Verify using the Cancel button in the Progress window, can leave the Router Services Manager in an unspecified state.
Solution: Whenever possible, avoid cancelling from the Progress window. If either operation is cancelled from this window, you must Refresh Device Data and Verify to determine whether the enforce or verify completed successfully.
Problem 4: If an EOS ACL that has no rules is applied to an interface through a device's Local Management (CLI), a subsequent Enforce operation will not remove this ACL from the interface. Verifying ACLs on the device will fail.
Solution: Do not use the device's CLI to apply an EOS ACLs without rules to an interface.

Firewall

Problem 1: When an active policy (uncommented) is moved up or down in the list in the Policies - Summary tab, Router Services Manager marks all devices associated with that policy as Needs Enforce (Needs Enforce), even though enforcement may not be necessary on some of the marked devices. Moving an inactive (commented) policy does not mark devices as needs enforce.
Solution: Perform a Verify to determine which devices actually need enforce.
Problem 2: If an Enforce is cancelled using the Cancel button in the Progress window (showing a progress bar), the device can be left in an unspecified state. Likewise, cancelling a Verify using the Cancel button in the Progress window, can leave the Router Services Manager in an unspecified state.
Solution: Whenever possible, avoid cancelling from the Progress window. If either operation is cancelled from this window, you must Refresh Device Data and Verify to determine whether the enforce or verify completed successfully.
Problem 3: When a dynamic object is only being used by Java/ActiveX, Yes is displayed in the "Used On Device" column in the Dynamic Objects tab. However since the dynamic object is not used in a policy or filter (only used by Java/ActiveX), it will not appear in the Used In window.
Solution: The Used In window shows only the relationship between network/dynamic objects and policies and filters. If Used on Device doesn't list a network object that is listed as Used on Device in the Dynamic Objects tab, check the Firewall Settings tab for your devices to see where the dynamic object is used.
Problem 4: Router Services Manager does not check for the Gating Rule Limit when enforcing Firewall Policies to an XSR device. As a result, the Enforce reports success, but policies that cause a Gating Rule Limit to be exceeded will not be written to the device. The number of rules allowed by the Gating Rule Limit depends on the memory capacity on the device. To see the limit for a device, refer to the show limits command in the XSR User Reference Manual. This problem will occur more frequently on devices with less memory, such as the XSR1805.
Solution: You should always Verify Firewall after Enforcing Policies to be sure that the Gating Rule Limit has not been exceeded.
Problem 5: When an HTTP Command Filtered Service is defined that filters ONLY commands that are common to both FTP and HTTP (e.g., get), any policies that use that service will be written to the device correctly when enforced. However, verifying the firewall settings on the device will report a failure. This problem does not occur if the HTTP Command Filtered Service also includes a command that is specific to HTTP.
Solution: This problem will be corrected in a future release.
Problem 6: When a policy is created using a Command Filtered Service with CLS commands that contain letters in the first command and numbers in the second command (e.g., aaa   444), the policy does not get written to the XSR device. The Enforce Firewall is reported as successful, however, a subsequent verify reports the failure. The problem occurs for all three Command Filtered Services (SMTP, FTP and HTTP). This is an XSR firmware restriction. Enforcing (ip firewall load) this type of policy through the device CLI reports:

Load: Gating rules compile failed.

Note: The policy is correctly enforced when the first command contains numbers and second contains letters.

Help System

Problem 1: Links to topics selected in the Contents will not work correctly following a search operation. If you use the JavaHelp search to find a term, then return to the Contents and navigate to a topic, the viewer may take you to the wrong place in the topic. If the topic you select contains the term just sought using the search, the viewer will take you to the term instead of the topic you chose from the Contents.
Solution: Return to the Search tab, clear the entry and click Search. Go back to the Contents and the navigation will work correctly.
Problem 2: In the Print window, the Print Range area has a Pages option with the default values of "from 1 to 9999".
Solution: Enter the desired values.

Any other problems than those listed above should be reported to our Technical Support Staff.

IETF MIBs REQUIRED

RFC No. Title Groups Supported
1157 Simple Network Management Protocol (SNMP)  
1213 MIB-II System, Interfaces and IP
1493 Bridge MIB dot1dBase group
     

ENTERASYS NETWORKS PRIVATE ENTERPRISE MIBs REQUIRED

Title Version
CTRON-SSR-CONFIG revision 200002200000Z
IP-MIB  
ENTITY-MIB  
   

The IETF and Private Enterprise MIBs listed above enumerates the minimum set of MIBs that a hardware device must implement for SNMP features to be supported by this application. Implementation of these MIBs does not assure that an unsupported hardware device will function properly with this software.

Enterasys Private Enterprise MIBs are available in ASN.1 format from the Enterasys web site at:

http://www.enterasys.com/support/mibs. Indexed MIB documentation is also available.

IMPORTANT URLS

The following Enterasys URLs provide access to NetSight software products and product information. *Software license keys are version dependent and will only operate with the version of software related to the license key.

GLOBAL SUPPORT

By Phone: (603) 332-9400
By Email: support@enterasys.com
By Web: http://www.enterasys.com/support
By Fax: (603) 337-3075
By Mail: Enterasys Networks, Inc., 35 Industrial Way, Rochester, NH  03867

For information regarding the latest software available, recent release note revisions, or if you require additional assistance, please visit the Enterasys Support web site.

http://www.enterasys.com/support 

1/2004      P/N:  9038133-01   Subject to Change Without Notice    F0615-E