Adding a device
This topic describes how to manually define a new device for asset and configuration management by BMC Network Automation.
After you add a new device, BMC Network Automation automatically performs a snapshot span action for this new device. The initial Running and Startup configurations are marked as Trusted.
Large numbers of devices can be imported manually or on a scheduled basis from a variety of formats, including standards such as CSV seed file, WhatsUp Professional, Entuity EYE, CiscoWorks XML and HP Network Node Manager. See Managing device import tasks. Mass edits can be performed to modify values across multiple devices simultaneously. See Editing devices.
To manually define a new device
- Select Network > Spans > Devices. The Devices page is displayed.
- Click the Add menu option above the list of devices to open the Add Device page.
Alternatively, if you want to define a new device by duplicating an existing device and editing its attributes, click Copy beside the relevant device.
To find a device with the appropriate attributes, you can click View and display a summary of the device's attributes.
On the Details tab, define device attributes through the displayed fields:
If you are creating a quick start configuration, only enter information for the required fields. The required fields are indicated with a red asterisk (*) .
Specify a unique name for the device. Up to 40 characters in length.
Select the realm to which this device belongs. This field is available when the administrator has created two or more realms.
Select the device type based on the vendor. For example, for a Cisco IOS router, you would select Cisco and Cisco IOS Switch/Router.
Select the device category, defining the general type of equipment.
(Optional) Select the manager for this device. To browse for the manager, click the button. This field is displayed only when the device type supports a manager. For example, a Cisco Nexus device that represents a VSG firewall can declare a VNMC device to act as its manager. When this is the case, Deploy to Active operations performed on the VSG worker device actually result in the template in question being pushed out to the VNMC manager device. The template must therefore containunderstood by the VNMC, not Nexus commands. The VNMC automatically propagates the changes from those commands down to the VSG it controls. BMC Network Automation performs a trailing snapshot of the worker device afterwards if possible, however in the case of the VSG it does not because you cannot predict exactly how long it will take the VNMC to flush changes to it. Instead the VSG must be configured to send syslog messages back to BMC Network Automation to trigger the trailing snapshot.
(Optional) Places a device in online or offline mode. When a device is offline, the following operations are suspended:
- Offline devices are not included in span actions (for example, Snapshot, Deploy to Active).
- Offline devices are excluded from many reports
- Offline devices are not present in device pop-up lists for span actions.
- Offline devices are not included in configuration exports.
During a Device Import, you can select whether new devices should be placed in online or offline status.
Remote Image File Server
(Optional) Specify which remote file server stores OS image files for this device, if you want to copy OS image files from a service located physically closer to this device on your network. This field is displayed only when you have remote file servers defined under Admin > Remote File Servers.
(Required for firewalls and load balancers) Specifies the security context information for your device. Choose from the following options:
- Not a Security Context
Note: If you select User-Defined, you must identify your security context in the Name field that is displayed below this field.
The following Virtual Data Center (VDC) fields on the Details tab are read-only. They are populated only when VDC is enabled, the Device Category field is set to Load Balancer, Content Cache, Switch, or Firewall, and the device is associated with a pod and is part of a container. Their values come from the number of virtual devices or containers configured on the device.
- Number of VLBs: The number of Virtual Load Balancers configured on this host.
- Number of VFWs: The number of Virtual Firewalls configured on this host.
- Number of VRFs: The number of Virtual Routing and Forwarding tables configured on this host.
- Under User Assigned Dynamic Fields, enter values based on the fields defined by the administrator through Admin > Dynamic Fields.
Only those dynamic fields that are applicable to the selected Device Type are available under User Assigned Dynamic Fields. For example, if you select Cisco Nexus as the Device Type, only those dynamic fields that are applicable to the Cisco Nexus device type are visible.
Define the primary interface through the following fields:
Host Name/IP Address/URL
Specify the host name, IPv4 or IPv6 address, or URL of the device's primary interface. When the access mode is web service, this field must contain the URL for accessing the host or server that is providing the web services interface. For a VMware vSwitch, the URL must be in one of the following formats:
The URL can include http or https, depending on what the server supports. The URL can include a port number, if the server is configured to accept connections on a non-standard port. The URL can include a path, if the server is configured to support web services on a non-standard path. BMC Network Automation fills in the port and path with defaults. For example, a fully-qualified URL for a vSwitch might be:
For a device that is accessed via its serial console port connected to a terminal server, include the port number and terminal server host name or IP address in this field, using the following format:
Select the device agent that manages this device. If you do not have any remotely installed Device Agents, select Local (default).
Protocol used by the device agent to log on to the device. SSH2 refers to secure shell protocols. When Auto is selected, the device agent tries all supported modes (for example, SSH2, Telnet) for the device starting with the most secure. It also remembers the successful access setting for subsequent device interaction.
If the device agent fails to log on by using the assigned access mode, the device agent can revert to Auto to attempt to find a working access mode. You can enable this functionality on the Edit System Parameters page (Admin > System Admin > System Parameters), by enabling the Retry Using Auto on Login Failure system parameter in the Device section. This system parameter is disabled by default.
When Access Mode is set to an option other than Auto, the Port option becomes available. You can enter the TCP port number for connecting to the device. If this field is blank, BMC Network Automation uses the default well-known port associated with the access mode (22 for SSH, 23 for Telnet, 80 for HTTP, and 443 for HTTPS).
When the access mode is Auto, BMC Network Automation discovers the port and automatically enters the port number that was used to make a connection.
File Transfer Mode
Protocol used by the device agent to transfer configuration files and OS images to or from the device. When Auto is selected, the device agent tries all supported modes for the device starting with the most secure, and then remembers the successful transfer setting for subsequent device interaction. Examples of supported protocols are Session Control Protocol (SCP), File Transfer Protocol (FTP), Trivial File Transfer Protocol (TFTP), and Tunneled protocol.
- To support tunneling, ensure that the device security profile contains definitions for access through a serial terminal server, as described in Understanding tunneling support. . For more information about tunneling, see
- Devices that are intended as Pod hosts should use file transfer mode instead of tunneled mode. File transfer mode is faster for firewall updates.
Device Security Profile
Specify the device security profile (DSP) used for device login. For example, IOS-account.
When Auto is selected, BMC Network Automation tries each DSP in order of the DSP Priority until one works, after which it uses the working DSP unless reassigned. This solves the issue when you are unsure of the device credentials assigned to each device (for example, use multiple RADIUS/TACACS+ servers). BMC Network Automation uses the DSP when performing policy-based span actions (for example, Deploy to Active for Auto-Remediation), all Snapshot span actions, and other user initiated span actions where prompting for the user's device credentials is disabled. See Managing device security profiles for more information about defining DSPs.
If BMC Network Automation fails to log on by using the assigned DSP, BMC Network Automation can revert to Auto to attempt to find a working DSP. You must enable this functionality on the Edit System Parameters page (Admin > System Admin > System Parameters), by enabling the Retry Using Auto on Login Failure system parameter in the Device section. This system parameter is disabled by default.
(Optional) This parameter is applicable when network address translation (NAT) is used by devices to access the device agent or proxy file server by using TFTP/FTP/SCP to transfer configuration and OS image files.
The NAT Address is necessary when there is a network-address-translation mechanism (typically a router or firewall) in place between the device agent or proxy file server and the device. A translated IP address must be used so the device can communicate back to the device agent or proxy file server to complete a TFTP/FTP/SCP configuration and OS image file transfer.
If the device and router are capable of resolving the names, then specify the host name of the device agent (which is the application server for the local device agent) or proxy file server in this field. The host name would be resolved to the translated IP address automatically at runtime by the device.
If the device and NAT router cannot resolve names, specify the translated IP address of the device agent or proxy file server.
- If the device can be reached through an alternate path, select the Auxiliary Interface option.
For example, a device might normally be managed over the management LAN; but, for emergencies, its console port might also be physically cabled to a terminal server. You could also use the auxiliary interface to connect via a backup device agent, or to use a backup device security profile (such as a factory-default user account).
Most day-to-day span actions uses the main or primary interface, but you can choose to use the auxiliary interface for any action that connects to the device.
If you selected the Auxiliary Interface option, define parameters for the secondary path:
Host Name/IP Address/URL
Specify the host name, IPv4 or IPv6 address, or URL of the device's secondary interface.
Select the device agent that can reach the device over the alternate path.
Select the protocol used by the device agent to log on to the alternate host name or IP address.
When Access Mode is set to an option other than Auto, the Port option becomes available. You can enter the TCP port number to use to connect to the device.
File Transfer Mode
Select the protocol used by the device agent to transfer files over the alternate path. Devices that are intended as Pod hosts should use file transfer mode instead of tunneled mode. File transfer mode is faster for firewall updates.
Device Security Profile
Specify the login credentials for the alternate path.
(Optional) Specify IP address of any agent or proxy file server necessary to route back to it over the alternate path.
On the Groups tab, select static groups to associate with the device by moving groups from the list of available groups (that is, groups defined in the database) to the list of selected groups.
A device cannot be added or removed from an auto group, as this is performed by BMC Network Automation based on the device's attributes (for example Model or Location).
- Click Save to add the new device to the database.