How to Create Devices

	NOTE:	If you have installed the limited (10-device) version of Router Services Manager, you will not be able to create more than 10 devices.

Devices can be added to the database by:

• Using the Create Device Wizard
• How to Import Devices from a File

Using the Create Device Wizard

Open the Create Device Wizard

1. Select the Device tab in the left panel.
2. If you are adding this device to a Device Group, select the group from the left panel.
3. Select Device Management > Create Device Wizard from the Tools menu (or the right click on the Devices folder or Device Group and select Create Device Wizard from the popup menu). The Create Device Wizard opens with the Device Contact window.

Device Contact

4. Name the device and establish Device Contact. The wizard uses this step to query the device type and determine the accessibility of this device.
   1. Enter a Hostname or IP Address for the device.
   2. Select the SNMP Version for this device and enter the parameters for your selection below.

      SNMPv1 Access

      • Enter a Community Name. The Community Name is used by Router Services Manager to communicate with the device. The SNMP Community Name should be set to the Read Only community name for the devices on your network. The wizard uses the community name to query the device type and determine the accessibility of this device. If the device type is not supported by Router Services Manager or, if the query times out, the wizard reports the discrepancy. This is a required field.

        For Matrix N-Series devices, you must enter the community name for the device's switch context. Refer to the Matrix N-Series User's Guide or more information about device contexts.

      SNMPv3 Access

      • Enter a User (no spaces) for the SNMPv3 credentials that will be used to communicate with the device.
      • Select the Security Level for this device. The appropriate security parameters are activated below for the specific security level that you select.
        • AuthPriv - Highest security level requiring authentication and privacy (encrypted information) This selection requires an Authentication Type/Authentication Password and Privacy Type/Privacy Password.
        • AuthNoPriv - Requires authentication, but unencrypted information. This selection requires an Authentication Type and Authentication Password.
        • NoAuthNoPriv - Neither Authentication Type/Authentication Password nor Privacy Type/Privacy Password are required.
      • Select an Authentication Type - MD5 or SHA1 selected from this drop-down list. This field is disabled for Security Level NoAuthNoPriv.
      • Enter a Authentication Password. This is the password (1 to 64 characters - no spaces, see Note) that will be used to determine Authentication. This field is disabled for Security Level NoAuthNoPriv.
      • Select a Privacy Type - DES is currently the only option that can be selected from this drop-down list. This field is disabled for Security Level, AuthNoPriv and NoAuthNoPriv.
      • Enter a Privacy Password. This is the password (1 to 64 characters - no spaces, see Note) that will be used to determine Privacy. This field is disabled for Security Level, AuthNoPriv and NoAuthNoPriv.

        	NOTE:	Although the device firmware will allow configuring a password fewer than 8 characters, shorter passwords are significantly less secure. We recommend a password consisting of at least 8 random characters.

   3. Click OK.

      If the device type is supported by Router Services Manager, the Telnet Authentication window is opened.

      If the device type is not supported by Router Services Manager or, if the query times out, the wizard reports the problem and does not proceed to the Telnet Authentication window. Fix the problem and try again.

Telnet Authentication

5. Define Telnet Authentication parameters for the device. Router Services Manager uses these credentials to perform certain functions (Verify, Enforce, etc.) on the device. There are differences in the settings depending on the device type being created:

   Matrix E1 Routers

   1. Select Encrypt session via SSH if the communication between the device and Router Services Manager uses Secure Shell (SSH) to encrypt information. Matrix E1 routers provide an electronic fingerprint that can be used to verify that the device being managed is not an imposter. The following settings determine how the fingerprint will be handled for device models being created.

      	NOTES:	Solaris - On UNIX (Solaris) systems, where Secure Shell (ssh) is used for Matrix E1 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. You may wish to periodically inspect the known_hosts file and delete old fingerprint entries. Windows - The fingerprint specified in Router Services Manager will not be compared against the one received from a device if the fingerprint for the device is stored in the Windows Registry. This can occur on Windows systems where a version of PuTTY (Telnet and SSH utility for Win32 platforms) is installed. This is because PuTTY prompts users to confirm fingerprints prior to establishing a connection to a device and, when the fingerprint is confirmed, it is stored in the Windows Registry. There is no adverse effect from this situation. The fingerprint from the device is validated by the one stored in the Registry and if the device fingerprint does change, it will be checked against the one specified in Router Services Manager.

   2. Select Accept Any Fingerprint if the device being created will accept any fingerprint as valid.

             or

      select Specify Fingerprint to enter a fingerprint for the device into the associated field. This fingerprint will be compared against the fingerprint returned from the device. Mismatches are treated as a security violation.

   3. Check Use RADIUS, TACACS, TACACS Plus if the device is configured to use an Authentication Server. Router Services Manager will prompt for authentication credentials prior to allowing Telnet Login access to the device(s) being created. Passwords used with Authentication Servers are not stored by Router Services Manager.
   4. Check RADIUS password is a dynamic token. if the RADIUS password is automatically changed at intervals as an added security measure. When the password is configured as a dynamic token, Router Services Manager cannot store a valid password and must prompt the user for authentication credentials whenever Router Services Manager attempts to access a device created using this feature.
   5. Enter a Login Username that will be used to access this device. This level of access lets you retrieve basic information, and execute functions that enforce ACLs in the device.
   6. Enter a Login Password. The password entered here will be used to access to access this device.
   7. Router Services Manager sets default options for the device being created. The default options for this device are listed under the Options heading in the left panel. If you want to change these options, click the Options heading. Otherwise, click Create to add the device to the Router Services Manager database.

   Matrix N-Series Routers

   1. Select Encrypt session via SSH if the communication between the device and Router Services Manager uses Secure Shell (SSH) to encrypt information. Matrix N-Series routers provide an electronic fingerprint that can be used to verify that the device being managed is not an imposter. The following settings determine how the fingerprint will be handled for device models being created.

      	NOTES:	Solaris - On UNIX (Solaris) systems, where Secure Shell (ssh) is used for Matrix N-Series 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. You may wish to periodically inspect the known_hosts file and delete old fingerprint entries. Windows - The fingerprint specified in Router Services Manager will not be compared against the one received from a device if the fingerprint for the device is stored in the Windows Registry. This can occur on Windows systems where a version of PuTTY (Telnet and SSH utility for Win32 platforms) is installed. This is because PuTTY prompts users to confirm fingerprints prior to establishing a connection to a device and, when the fingerprint is confirmed, it is stored in the Windows Registry. There is no adverse effect from this situation. The fingerprint from the device is validated by the one stored in the Registry and if the device fingerprint does change, it will be checked against the one specified in Router Services Manager.

   2. Select Accept Any Fingerprint if the device being created will accept any fingerprint as valid.

             or

      select Specify Fingerprint to enter a fingerprint for the device into the associated field. This fingerprint will be compared against the fingerprint returned from the device. Mismatches are treated as a security violation.

   3. Check Use RADIUS, TACACS, TACACS Plus if the device is configured to use an Authentication Server. Router Services Manager will prompt for authentication credentials prior to allowing Telnet Login access to the device(s) being created. Passwords used with Authentication Servers are not stored by Router Services Manager.
   4. Check RADIUS password is a dynamic token. if the RADIUS password is automatically changed at intervals as an added security measure. When the password is configured as a dynamic token, Router Services Manager cannot store a valid password and must prompt the user for authentication credentials whenever Router Services Manager attempts to access a device created using this feature.
   5. Check Use Local User and enter a username into the Login Username field and a password into the Login Password field that will be used to access an Matrix N-Series device. This level of access lets you retrieve basic information, and execute functions that enforce ACLs and policies in the device.
   6. Router Services Manager sets default options for the device being created. The default options for this device are listed under the Options heading in the left panel. If you want to change these options, click the Options heading. Otherwise, click Create to add the device to the Router Services Manager database.

   XP-Native Router

   This step lets you define password information and authentication settings that will be applied to XP Native device models when they are created. User credentials can be defined for Local or External Authentication.

   1. Select Use local device authentication to define local authentication parameters.
      1. Select Encrypt session via SSH if the communication between the device and Router Services Manager uses Secure Shell (SSH) to encrypt information. Matrix N-Series routers provide an electronic fingerprint that can be used to verify that the device being managed is not an imposter. The following settings determine how the fingerprint will be handled for device models being created.

         	NOTES:	Solaris - On UNIX (Solaris) systems, where Secure Shell (ssh) is used for Matrix N-Series 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. You may wish to periodically inspect the known_hosts file and delete old fingerprint entries. Windows - The fingerprint specified in Router Services Manager will not be compared against the one received from a device if the fingerprint for the device is stored in the Windows Registry. This can occur on Windows systems where a version of PuTTY (Telnet and SSH utility for Win32 platforms) is installed. This is because PuTTY prompts users to confirm fingerprints prior to establishing a connection to a device and, when the fingerprint is confirmed, it is stored in the Windows Registry. There is no adverse effect from this situation. The fingerprint from the device is validated by the one stored in the Registry and if the device fingerprint does change, it will be checked against the one specified in Router Services Manager.

      2. Select Accept Any Fingerprint if the device being created will accept any fingerprint as valid.

                or

         select Specify Fingerprint to enter a fingerprint for the device into the associated field. This fingerprint will be compared against the fingerprint returned from the device. Mismatches are treated as a security violation.

      3. Select System Passwords to configure the device for a single user and specify one or more of the following passwords for the access levels (Telnet Login, Enable Mode, and Config Mode) in the device:
         • Login Password - This password allows access to User mode in a device. This level of access lets you retrieve basic information, but does not let you execute functions that enforce ACLs in the device.
         • Enable Mode Password - This password allows access to Enable mode in a device.
         • Config Mode Password - This password allows access to Config Mode in a device.
      4. Select Multi-User Account to configure a device to recognize several users, each with a specific level of access (Telnet Login, Enable Mode, and Config Mode) and specify access credentials. The user credentials specified here should have a level of access that allows executing functions such as enforcing ACLs in the device.
         • Username - This is the username that will be used to access an XP Native device.
         • Password - This is the username that will be used to access an XP Native device.

   2. Select Use external device authentication option to define external authentication parameters for the device being created. When set to use external authentication, Router Services Manager will prompt the user for authentication credentials when Router Services Manager attempts to establish access to the device. Router Services Manager will use that password for duration of the current session, but does not retain the password when the Router Services Manager session is terminated.
      1. Select Login to use an authentication server for Login (User Mode) access.
      2. Select Enable Mode to use an authentication server for both Login and Enable Mode access.
      3. Select Login and Enable Mode to use the authentication server for Enable Mode access.
      4. Check RADIUS password is a dynamic token if the RADIUS password for this device is automatically changed at intervals as an added security measure. When the password is a dynamic token, Router Services Manager cannot store a valid password and must prompt the user for authentication credentials whenever Router Services Manager attempts to access a device created using this feature.
      5. Check Last Resort Credentials to use the following local passwords when the authentication server cannot be contacted. Router Services Manager will attempt to use Local Device Authentication (System Passwords or Multi-User Account) settings to access the device. However, if the device is not configured to accept a Last Resort password, then access will be denied.
         • System Passwords - Use this option configure a device for a single user and specify one or more of the passwords for the access levels (Telnet Login, Enable Mode, and Config Mode) in the device.
           • Login Password - This password allows access to User mode in a device. This level of access lets you retrieve basic information, but does not let you execute functions such as enforcing ACLs in the device.
           • Change Enable Mode Password - This password allows access to Enable mode in a device.
           • Change Config Mode Password - This password allows access to Config Mode in a device.
         • Multi-User Account - Use this option to configure a device to recognize several users, each with a specific level of access (Telnet Login, Enable Mode, and Config Mode) and specify access credentials. The user credentials specified here should have a level of access that allows executing functions that enforce ACLs in the device.
           • Username - This is the username that will be used to access an XP Native device.
           • Password - This is the username that will be used to access an XP Native device.
   3. Router Services Manager sets default options for the device being created. The default options for this device are listed under the Options heading in the left panel. If you want to change these options, click the Options heading. Otherwise, click Create to add the device to the Router Services Manager database.

   XSR Routers

   1. Select Encrypt session via SSH if the communication between the device and Router Services Manager uses Secure Shell (SSH) to encrypt information. XSR routers provide an electronic fingerprint that can be used to verify that the device being managed is not an imposter. The following settings determine how the fingerprint will be handled for device models being created.

      	NOTES:	Solaris - On UNIX (Solaris) 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. You may wish to periodically inspect the known_hosts file and delete old fingerprint entries. Windows - The fingerprint specified in Router Services Manager will not be compared against the one received from a device if the fingerprint for the device is stored in the Windows Registry. This can occur on Windows systems where a version of PuTTY (Telnet and SSH utility for Win32 platforms) is installed. This is because PuTTY prompts users to confirm fingerprints prior to establishing a connection to a device and, when the fingerprint is confirmed, it is stored in the Windows Registry. There is no adverse effect from this situation. The fingerprint from the device is validated by the one stored in the Registry and if the device fingerprint does change, it will be checked against the one specified in Router Services Manager.

   2. Select Accept Any Fingerprint if the device being created will accept any fingerprint as valid.

             or

      select Specify Fingerprint to enter a fingerprint for the device into the associated field. This fingerprint will be compared against the fingerprint returned from the device. Mismatches are treated as a security violation.

   3. Check Use RADIUS, TACACS, TACACS Plus if the device is configured to use an Authentication Server. Router Services Manager will prompt for authentication credentials prior to allowing Telnet Login access to the device(s) being created. Passwords used with Authentication Servers are not stored by Router Services Manager.
   4. Check RADIUS password is a dynamic token. if the RADIUS password is automatically changed at intervals as an added security measure. When the password is configured as a dynamic token, Router Services Manager cannot store a valid password and must prompt the user for authentication credentials whenever Router Services Manager attempts to access a device created using this feature.
   5. Check Use Local User and enter a username into the Login Username field and a password into the Login Password field that will be used to access an XSR device. This level of access lets you retrieve basic information, and execute functions that enforce ACLs and policies in the device.
   6. Router Services Manager sets default options for the device being created. The default options for this device are listed under the Options heading in the left panel. If you want to change these options, click the Options heading. Otherwise, click Create to add the device to the Router Services Manager database. If the XSR device being created supports Firewall features, the Wizard shows the results of importing Firewall definitions in the Results window.

Results

This step shows a summary of the ACLs that were imported from the newly created XSR device and lets you review the Firewall Definitions from the device before saving them to the database.

1. Review the Firewall Import Summary and Conflicts tables. The Summary table shows an overview of the policies and filters that are available to be imported from the device. The Import Conflicts table shows where differences were detected between the Firewall Definitions in the Router Services Manager database and the device.
2. Click Keep results of Firewall Import if you decide to import the Firewall definitions from the device. This saves the imported Firewall Definitions for the device in the Router Services Manager database.

         or

   click Reject results of Firewall Import to cancel the import operation.

3. Click Continue from this view to return to the Device Contact window to allow creating another device. Otherwise, click Close to dismiss the Create Device Wizard.


Device Options

6. Select Device Optionsfor the device. These settings let you automatically initiate several activities when a new device model is created. The settings that are available from the Device Options window depend on the type of device being created.

   Matrix E1 and Matrix N-Series Device Options

   1. Check Import ACLs From Device to automatically read all the ACLs, except ACLs that are used by other facilities (i.e., Web-Cache, rate limiting, etc.) from the newly created device when it is created.
   2. Check Do Not Resolve IP Address to Hostname to suppress hostname resolution for this device, through your network's name server. Check this option if you have not defined a hostname for this device. Attempting to resolve hostnames where none exist causes delays when creating a device.
   3. Select a Nickname option from the drop down list. This option lets you choose how devices will be identified in Router Services Manager views:
      • IP Address - by IP address.
      • Hostname - by a hostname, which is defined in your networks name server.
      • System Name - by a system name, configured through the device's CLI.
      • User Defined - by a user-defined name entered into the associated text field.

   XP Native Device Options

   1. Check Import ACLs From Device to automatically read all the ACLs, except ACLs that are used by other facilities (i.e., Web-Cache, rate limiting, etc.) from the newly created device when it is created.
   2. Check Syslog to causes Router Services Manager to automatically enable Syslog for ACL logging on a newly created device.
   3. Check Do Not Resolve IP Address to Hostname to suppress hostname resolution for this device, through your network's name server. Check this option if you have not defined a hostname for this device. Attempting to resolve hostnames where none exist causes delays when creating a device.
   4. Select a Nickname option from the drop down list. This option lets you choose how devices will be identified in Router Services Manager views:
      • IP Address - by IP address.
      • Hostname - by a hostname, which is defined in your networks name server.
      • System Name - by a system name, configured through the device's CLI.
      • User Defined - by a user-defined name entered into the associated text field.

   XSR Device Options

   1. Check Import ACLs From Device to automatically read all the ACLs, except ACLs that are used by other facilities (i.e., Web-Cache, rate limiting, etc.) from the newly created device when it is created.
   2. Check Import Firewall Definitions to import Firewall Definitions from the device being created according to the following selections:
      • Check All Policies, Filters, Network Objects, Service Objects, and Groups to automatically read all Policies, Filters, Network Objects, Service Objects, and Groups from the newly created device when it is created.
      • Check Only Network Objects and Groups for Java and ActiveX settings to automatically read Network Objects and Groups used with Java and ActiveX from the newly created device when it is created.
      • When None is checked, Router Services Manager will not read any Firewall information from a newly created device when it is created.
   3. Check Do Not Resolve IP Address to Hostname to suppress hostname resolution for this device, through your network's name server. Check this option if you have not defined a hostname for this device. Attempting to resolve hostnames where none exist causes delays when creating a device.
   4. Select a Nickname option from the drop down list. This option lets you choose how devices will be identified in Router Services Manager views:
      • IP Address - by IP address.
      • Hostname - by a hostname, which is defined in your networks name server.
      • System Name - by a system name, configured through the device's CLI.
      • User Defined - by a user-defined name entered into the associated text field.

7. If you checked the Import ACLs from Device option, click OK to go on to the Import ACLs window.
8. Click Create to add the device to the Router Services Manager database.
9. You can now click Device Contact in the left panel to create another device or click Close to dismiss the window.



Import ACLs

10. Set the Destination Folder.
    • Select Imported ACLs to have the imported ACLs are placed in the Imported ACLs folder in the ACL Definitions tab. This is the default setting.
    • Select Imported ACLs >> Device Specific Folder to have Router Services Manager place the imported ACLs into device-specific folders in the Imported ACLs folder. When a device specific folder does not exist for a device, Router Services Manager will create the folder using the current Display Device By option setting to name the folder.
    • Select Imported ACLs >> User-Defined Folder Name and enter a folder name in the associated field, or use the Select button to select a folder within the Imported ACLs folder where the imported ACLs will be placed.
11. Set ACL Creation to determine how ACLs will be imported into Router Services Manager. You can choose to always create ACLs that are imported from devices or filter duplicate ACLs as they are being imported. The test for duplicate ACLs can be further defined to compare imported ACLs to the ACLs in specific folders and sub-folders in the ACL Definitions tab.
    • Select Do not create ACL if it already exists: if you do not want to import ACLs when a duplicate ACL exists in any of the selected folders. (Duplicate ACLs are ACLs that have the same name and the same rules.)

      You can select one or more folders. The imported ACLs will be compared with ACLs in the selected folder(s) and all of its sub-folders. When In Imported ACLs is selected, the imported ACLs are compared with ACLs in the Imported ACLs folder and also in any more specific Destination Folders within the Imported ACLs folder. Do not create ACL if it already exists: and the In Cataloged ACLs and In Imported ACLs are selected as the default settings.

    • Select Always Create ACL to import all of the ACLs from the selected device(s) into the specified destination without filtering duplicate ACLs.
12. Click Create to add the device to the Router Services Manager database.
13. You can now click Device Contact in the left panel to create another device or click Close to dismiss the window.



---




Related Information

For information on related windows:
• Create Device Wizard
• Add Devices From An Import File Window
• Options Window
• Create Device Template Window
For information on related tasks:
• How to Manage Device Groups
• How to Import Devices From a File
• How to Add or Remove Devices in a Device Group
• How to Set Options
• How to Create a Device Template