...
Note: When using Perl scripting for automation, isolate NetMRI appliance performance from errant or excessive consumption of resources by the script. Job Scripting describes many aspects of Perl-based job automation.
NetMRI provides a dedicated guest virtual machine (VM) environment under which Perl scripts execute in isolation. The guest VM's disk and memory resource allocations are strictly limited and cannot be adjusted from within the VM. Process scheduling functions in the appliance such as nice and ulimit also apply, because the guest VM is subject to standard scheduling rules.
The guest VM provides limited communication with the host NetMRI appliance and with other systems on the network. Network services that operate within the VM include OpenSSH and Samba (SMB) for communications and file sharing between the NetMRI host and the guest VM running the Perl script.
Job scripting implementation is done through the NetMRI Job Wizard. Substantial planning and preparation may be needed before implementing jobs.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Automation Change Manager (ACM) uses NetMRI scripts and other job automation features to enable the Automation Tasks feature set in the Infoblox NIOSTM Dashboard. You add a NetMRI appliance into an Infoblox Grid network to enable the Automation Change Manager functionality. With the proper licensing installed on both the NetMRI appliance and
Anchor | ||||
---|---|---|---|---|
|
...
Automation Change Manager leverages NetMRI's job automation scripts to expand the functionality of the Infoblox NIOS Tasks Dashboard. Numerous NetMRI job features, including lists and job triggers,
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: To run a script as a job immediately, see the sectionRunning Scripts Immediately later in this topic.
A job schedules a script to run against selected devices. You schedule jobs to run once or on a regular basis, at time
Anchor | ||||
---|---|---|---|---|
|
To create and schedule a new Job, do the following:
...
Note: Bulk push mode is supported only on Juniper and Cisco devices. Cisco downloads via TFTP, and Juniper configs download via the HTTP protocol.
- Choose a job script or template from Scripts or Templates (selectable by tabs). If required by the script or template, enter data and/or select options. Any variables defined in the script will appear in a list to the right.
- Choose the Push Mode option: Line by Line, Bulk or Text File. This determines the method by which the config file is written to devices that are part of the job.
For Push Mode, choosing LIne by Line sets the template config sequence to be pushed to the device involved in the Job, one line at a time; pushed in Bulk, the entire configuration is staged in NetMRI and then downloaded to the device.
If any non-Cisco/Juniper device is part of the device group selected for the job, the job will revert to Line by Line mode.
After choosing a script or template from their respective lists, you may see one or more input values that are requ
Anchor | ||||
---|---|---|---|---|
|
- When finished, click Next.
...
- Click Next. The Enter User CLI Credentials page appears, for cases when user account CLI credentials are required for the job. If not, proceed to Step 10.
Choose Use the requester's stored CLI credentials, or Use the approver's stored CLI credentials;
–or–
Choose Use these CLI credentials and enter and verify the Username and Password values and the equipment-associated Enable Password required for the account.
...
Once a job is listed in the table, you can check its Status, Last Run and Result in the Job History tab.
Note: Creating a job produces a new instance of the specified script or template, and inserts into that instance a Script-Schedule line containing schedule details.
- To create a copy of the scheduled job: In the Actions column, click the icon and choose Copy from the menu.
- In the Name dialog, enter a name for the copy, then click OK. To edit an existing job, do the following:
- In the Actions column, click the icon and choose Edit from the menu. The Job Wizard opens to the Summary of Job screen.
- Click Edit. The Fill out Job Details screen appears.
- Edit the job as needed. Use the Next –> and <– Previous buttons to navigate the wizard.
- Navigate to the Review and Save screen, then click the Save
button. To delete a job: Click the Delete button, then confirm the deletion.Anchor bookmark572 bookmark572
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
To run a script as a job immediately, do the following:
Go to Config Management –> Job Management –> Scripts tab.
- Hover the mouse over the Action menu for your desired script, and choose Run Now from the Action menu.
...
- If any input is required by the selected script, enter it in the right panel and click Next. (Note that in this step, the selected script is highlighted in the left pane of the window, listed with all other scripts in the library.)
- If you have custom fields for data entry, add that information and click Next. If not, simply click Next.
- Select the Device Groups or Devices to run the job against from their respective tabs and click the (–>) button to add them to the job; and click Next.
Click the > and < buttons to navigate pages of the Device Groups and Devices lists.
In the Devices list, use the Device Groups dropdown menu to choose the device group for device selection.
In the Devices list, use the Search box and type in a string of any length to search for a device name or an IP address. You can also search by the values shown in the Network View field.- In the Review and Run page, review your settings. If necessary, use the <Previous button to return to previous steps to make changes; when finished, click Run Now to begin script or template execution.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
If you plan to work with categories of Cisco and Juniper switches and
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: A new variable is available for use in script templates: the $NetMRI_ipaddress variable, whose data is formatted in standard dotted quad format. It sets a variable for the IP address of the device.
The Config Templates tab (Config Management –> Job Management tab –> Config Templates) provides an editing environment to develop standard configuration files. This feature is required for provisioning network devices using the Automation Change Manager's Bare Metal Provisioning (BMP) task, specifically for Cisco and Juniper routers and switches.
For all config templates, NetMRI provides an Action icon with several important editing functions: Copy (to copy a template into a new file); Edit (opening an editor window to make changes to an existing config template; Schedule (to schedule the config template job to run at a later time); Run Now (to run the Config Template job through the Job Wizard); Test Policy (test the template as a device-specific Policy; this requires all variables within the saved template file to be configured with specific values); Export (to immediately open the selected config file template in a text editor or save it out on your disk); and Delete (to delete the template from the table).
NetMRI does not validate templates; you can experiment within the limits of common sense and best practices for device configuration. Templates are a different job type, similar to scripts. The ACM Bare Metal Provisioning task operates using Config Templates as one of its core building blocks.
Note: The ACM Bare Metal Provisioning task is designed to execute on numerous instances of the exact same device type (50 Cisco 2821 routers, for example). You cannot execute a single BMP job on different device types. thus, you use only a single Config template for any BMP job.
You can access templates from CCS and Perl.
You can use templates to define variables and configuration file text (variable definitions are optional, while configuration text is required as part of the template).
Note: Templates are a support feature of jobs in the NetMRI appliance. You apply them to jobs just as you would a script; ACM's Bare Metal Provisioning is an example of this principle. The same rules and restrictions that apply to scheduling, running and approving script jobs apply to running template jobs.
Use completed templates to create a new policy or test against a policy, schedule as a Job, create new templates, respond to a trigger event such as Bare Metal Provisioning, and other tasks. When scheduling a template as part of a Job, it is combined with a script as part of a new Job definition.
Should a Configuration Template be used to provision a Bare Metal Device, the name of the Config Template in NetMRI must be the same as for a corresponding List in Job Management. For example, a cisco_catalyst37xxstack configuration template appears in the Config Template page when the NetMRI appliance is enabled for the Automati
Anchor | ||||
---|---|---|---|---|
|
version 12.2 no service pad
service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption
!
hostname $hostname enable password infoblox
!
boot-start-marker boot-end-marker
username admin privilege 15 password 0 infoblox no aaa new-model
switch 1 provision ws-c3750-48p system mtu routing 1500
vtp domain cisco vtp mode transparent ip subnet-zero
ip domain-name $domain_name no ip domain-lookup spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
$config_vlans
$config_interfaces
!
no ip classless
ip default-gateway $gateway no ip http server
no ip http secure-server
!
logging $syslog
snmp-server community infoblox RW
!
control-plane
!
line con 0
line vty 0 4
exec-timeout 300 0 logging synchronous login local
transport input telnet ssh line vty 5 15
exec-timeout 300 0 logging synchronous login local
transport input telnet ssh
!
end
The template also provides a standard set of template variables for use by the BMP provisioning script:
$hostname string""
$config_vlans string""
$domain_name string""
$gatewaystring""
$syslog string""
$config_interfaces string""
Note the use of variables in the template. For example, consider the following command string in the Config Template:
ip domain-name $domain_name
And the corresponding statement in the Template Variables:
$domain_name string""
Note that the set of variables defined in the config templates are fixed. The values themselves are defined during job execution by the values in the columns in the TAE BMP Device Provisioning list or from the TAE BMP Site Settings list.
To create a new template, do the following:
...
The test results will open in a new window.
If any template variables do not have values declared against them, the appliance responds with an "All variables in the template must be replaced with values before testing as a policy" message.
To export a template: Export, then save the file.
To delete a template: Delete, then confirm the deletion.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: Config templates also offer the ability to generate a text-based configuration file to enable configuration of an undiscovered device or devices of the same type. This feature provides an alternative path to configuring bare metal devices instead of using NetMRI's Bare Metal Provisioning feature. See the subsection Downloading a Config Template for more information.
Anchor | ||||
---|---|---|---|---|
|
...
For Push Mode, choosing LIne by Line sets the template config sequence to be pushed to the device involved in the Job, one line at a time; pushed in Bulk, the entire configuration is staged in NetMRI and then downloaded to the device.
(Available only when you choose the Run Now menu option.) Choosing the Text File option runs the template job and sends its output to a text file, which is uploaded to the management computer. See the subsection Downloading a Config Template for more information.
Note: If any non-Cisco/Juniper device is part of the device group selected for the job, the job will revert to Line by Line mode.
- Click the Templates tab, and select the template that will execute as part of the Job. Enter any required input values.
- If this job requires approval and you have the permissions to do so, click the Approved check box. Otherwise, leave it blank for admin account approval.
- At the bottom of the page, click Next.
- Choose the Devices or Device Groups to be part of the new Job, and click Next.
- Choose the Recurrence Pattern (Once, Hourly, Daily, Weekly, or Monthly) and the Execution Time (which is specified in half-hour increments). The chosen Recurrence Pattern determines additional schedule settings based on the selection.
- Click Next.
- (Optional) Enter the admin account's CLI credentials, or choose the options for Use the requester's stored CLI credentials or Use the approver's stored CLI credentials as needed. Click Next.
- In the Review and Run page of the Template Run Now wizard, review the steps taken for the Job.
- Review the Inputs field to ensure that all necessary input values have variables or data entries assigned to them through the template.
- Check the Devices field to make sure the correct devices are listed for the job.
- (Line by Line or Bulk Mode only) Click Run Now if all settings are correct.
Once the new Job is ready and your changes are saved, you click Run Now to execute the template Job.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
To download a device configuration file from a config template for use in configuration of an undiscovered network device, for editing, or for other purposes, do the following:
...
When the Push Mode is for a text file, the Job does not execute against a device itself; instead, the configuration is downloaded from the template with the variables or value modifications added. You can then use the template to hand-configure the intended device.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Config File Template window (Config Management –> Job Management –> Config Templates –> click New) provides a Template Variables field as part of creating a template. As previously noted, variables are optional in template definition, but knowing their format is useful.
Defining variables for config templates uses the same format as for script variables, in which three entries are provided for each vari
Anchor | ||||
---|---|---|---|---|
|
$usernamestring "User Name"
$passwordstring "New Password"
You can use as many variables as needed in any template.
Note: Scripts use a standard variable called eval_type. This variable is not used in configuration templates.
Otherwise, template variables are treated in the same fashion as defined in the CCS Supplement PDF, provided under the Additional Documentation section of the online Help.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: Individual NetMRI appliances are limited to 100 lists in the Lists page.
Lists are a key component in the Automation Change Manager (ACM) feature
Anchor | ||||
---|---|---|---|---|
|
–> Job Management –> Lists) allows the creation, editing, importing and exporting of lists to provide external lists of data to Perl script variables, CCS script variables and configuration template variables.
Lists are handy for dynamically looking up values to variables in Perl and CCS scripts. CCS and Perl can refer to/ look up values from lists during script execution. The lookup call enables a simple pass/fail test to detect the presence or absence of a value in a list. The call accepts the parameter list name, key column, key value, value column and a default. All values may be static or variable-based.
Lists are named CSV files imported into NetMRI. The most efficient way to use Lists is through importing of a CSV file. You can add new records to any list or create a new list entirely within NetMRI.) An advantage of using external lists, and of importing lists from .CSV files, is that NetMRI imports the column headers from .CSV files. These column headers then appear in the list table in NetMRI. Users can edit the headers inside the Lists page by right-clicking any column header and choosing Edit Column.
To import a list into the NetMRI Lists page, do the following:
...
- On the Config Management –> Job Management –> Lists page, select the list to export and choose Export.
- The browser prompts to open the data as a new Excel .CSV file or to save the data as a new file.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Automation Change Manager (ACM) relies on a series of lists in the Config Management –> Job Management –> Lists
Anchor | ||||
---|---|---|---|---|
|
- ACM Allowed DHCP Servers–List of any DHCP servers in the enterprise network, that are not to be included in any Rogue DHCP server reports. Defines to NetMRI and to the NIOS system that "these are the established DHCP servers in the network; do not report against these devices." Any router or other device that is not on this list, which offers DHCP-based IP configuration to clients connecting to the network will cause an issue to be fired by the Automation Change Manager.
- ACM BMP Device Provisioning–Bare Metal Provisioning list, to identify each switch to be provisioned. New switches are identified by their MAC address, the management IP address and site settings, including a Site Settings Name which corresponds to a name in the ACM BMP Site Settings list. The MAC address is the hardware MAC address assigned to the device coming out of the factory, and which is usually stamped on the rear of the chassis or on the shipping
box for the device. (This list is used in the topic Checklist for Running The Automation Change Manager System.)Anchor bookmark590 bookmark590 - ACM BMP Site Settings–Bare Metal Provisioning list to define the default switch port configuration. Consider it a branch office list–to contain the standardized configuration templates for any new devices installed in a given branch office network. This list defines values such as the Management VLAN ID and its VLAN name, the port designated for management VLAN traffic, the domain name, Syslog and Network Time Protocol server information, and VLANs on the provisioned device to be configured on individual access ports or ranges of access ports (VLAN1 Ports and VLAN2 Ports). (This list is used in the topic Checklist for Running The Automation Change Manager System.)
- ACM BMP Switch Model Interface Defs–Bare Metal Provisioning list defining the interfaces for the device types expected to be provisioned through the job. If the switch model to be provisioned is already in this table, no further information is needed here. The entries follow the standard slot/port designator formats for Cisco and Juniper devices such as Cisco 2950 and 3750 switches and Juniper EX2200 switches. You may need to create your own definitions within this list (or even new lists) to match switch port designators for provisioning other device types. (This list is used in the topic Checklist for Running The Automation Change Manager System.)
- ACM Script Settings–Defines the VLAN to which any rogue DHCP server, detected and isolated on the network, is placed for remedial action. By default, when this task executes, the isolation VLAN is defined as VLAN 99.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Switch model interface definitions for the ACM BMP Switch Model Interface Defs list merit further description. A column titled Interfaces provides the location for specifying the ranges of ports for initial bare-metal configuration. A simple Cisco 2950 port configuration shows a port range for a single "slot:"
fa0/{1-24}
Use the curly brackets symbols to define the port range for a slot, as in {1-24}. The only other requirement is to know the basic syntax for specifying different port types on the devices. You can apply this syntax to serial ports, PVCs and other interfaces.
To support switch models with larger configurations, such as a Catalyst 6500, you add multiple entries to the definition, separated by commas with no spaces:
fa1/0/{1-24},fa2/0/{1-24},fa3/0/{1-24},gi4/0{1-9},gi5/0{1-9}...
The list entry can contain as many values as required.
Similar entries may be required in the ACM BMP Site Settings list for VLAN port assignments (the example below shows data fields for a defined VLAN1 ID, the VLAN1 Name, and the assigned VLAN1 Ports, which are not for the management VLAN but the first VLAN to be assigned to user traffic):
100 VLAN100 fa1/0/{1-4},fa1/0/{6-10}
In this case, for example, VLAN 100 on the switch to be provisioned is assigned to Fast Ethernet ports 1 through 4, and to a second port range 6 through 10.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
In some cases, a switch type may not be defined in the LIsts page. To define a new list entry:
Go to Config Management –> Job Management –> Lists.
- Select the ACM BMP Switch Model Interface Defs list in the left pane.
- Click Add Row.
- Under Vendor Model, enter the desired model name (Cisco or Juniper). Example: cisco_catalyst6500.
Note: The name cited here must match that for a Config Template.
- Enter the slot/port values, including port ranges, separated by commas, in the Interfaces column.
- Click Save.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
NetMRI triggered jobs allow a script or template with predefined or custom variables to execute against a device when a "triggering source event" occurs. The Automation Change Manager triggered jobs
Anchor | ||||
---|---|---|---|---|
|
...
You create and manage triggered jobs in the Config Management –> Job Management –> Triggered Jobs tab. You define triggered jobs using a Triggered Jobs Wizard. The table of jobs includes the following columns of information:
Actions | Actions are View/Edit and Delete. Choosing View/Edit displays the Triggered Job Wizard showing the current job's Job Summary. Click the Edit button to make changes to the job. |
Name | The defined name for the triggered job. |
Level | The importance level of the job. |
Enabled | Define whether the job is enabled for execution. |
Active Window | The execution time period during which the job will run if executed. |
Trigger Type | The event that causes the job to execute: Issue, or Policy Rule violation. |
Trigger Event | A description of the trigger event, such as Rogue DHCP Server Detected. |
Device Groups | Jobs can also run against All device groups. |
Action | One of two possible actions can occur when the trigger event takes place: Run Job Immediately/Auto-Run or Schedule Job. The Run Job Immediately option also offers an Auto-approval checkbox, which is available only for the NetMRI admin user. |
Created On and Updated On | Date and time where the job was created, and the date and time where the job was last updated. |
Last Run | The last date and time where the job executed. |
Job Type | The type of job, defined as Script or Template based on the selection. |
Created By and Updated By | The NetMRI user account that created the job and that last edited the job. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: An example of a triggering event is: NetMRI discovers a new Cisco switch on the network. This event is embodied in a bit of data called a Trigger Source, which defines the nature of the event. Also see the following topic, Automation Change Manager (ACM) Triggering Sources, for more detail.
As part of triggered job definition, you specify the triggering event, the time periods over whic
Anchor | ||||
---|---|---|---|---|
|
For triggering events, a job's settings, such as script and variable input, define a template for new jobs to perform remedial actions, gather further information from the device, and other actions. The triggered job runs once per affected device, when NetMRI detects an issue or policy rule violation on that device. If the condition clears, and subsequently occurs again, the triggered job runs again.
You can run a job immediately, automatically pre-approved, or schedule the job for up to a week in the future, in a pending-approval or pre-approved state.
To create a triggered job, do the following:
...
In the lower right panel, review the script details. If the script provides user-definable variables, fill in or set them as needed (be sure to scroll down to see all variables).
- Click Next. The Schedule Job Execution screen appears.
- To specify when the job should be run, select either Trigger Action: Run Job Immediately (if selected, then click Next) or Schedule Job.
- In the To Run At list, select a time to run the job.
- In the The Following list, select a day where to run the job.
- Click Pre-Approved if the job will run based on your approval. Uncheck Pre-Approved if the job must be approved by another user before execution.
- Click Next.
- In the Review and Save screen, review the job specifications.
- To make changes, click < Previous to return to the page(s) needing to be revised.
- If the job specifications are correct, click Save. The job is listed in the Triggered Jobs tab.
Once a job is listed in the table, check its Status, Last Run and Result in the Scheduled Jobs tab.
To view job details: Click Edit. The Triggered Job Wizard appears, listing a summary of the job. From this point, click Edit if you wish to edit the job by choosing new trigger sources and other settings.
To delete the job from execution: Click Delete, then confirm the deletion.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
One category of triggering sources involves the Automation Change Manager. When the ACM license is installed into the NetMRI appliance, specific trigger source types are automatica
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
After NetMRI detects and locates a rogue DHCP server, the discovered device is consigned to a designated isolation VLAN to be dealt with. This job requires approval by the administrator.
Two triggering sources support a single ACM task. The Locate Rogue DHCP Server and Isolate Rogue DHCP Server jobs support the NIOS Dashboard Rogue DHCP Server Remediation task. Locate Rogue DHCP Server executes automatically in response to Automation Change Manager detection of a NIOS DHCPACK Syslog messages on the network. Isolate Rogue DHCP Server jobs require authorization by the administrator to execute.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: The NT-1400, NT-2200 and NT-4000 appliances, NetMRI 1102-A, and Virtual appliances with sufficient CPU and memory support the Automation Change Manager.
This procedure encompasses configurations from both NetMRI and Infoblox NIOS systems. A number of assumptions are made for purposes of brevity:
...
- Set the NIOS DHCP appliances to serve DHCP Options 66 for Cisco devices and DHCP Option 68 for Juniper devices. Each setting, if used, also requires entry of the IP address for NetMRI. This is further described in the topic Notes on DHCP Configuration for ACM Operation;
- Set the NetMRI inactivity timeout (60 minutes by default; In NetMRI, go to Settings icon –>Setup –> Advanced Settings –> User Interface category –> Inactivity Timer), and set this value to a higher time duration than for any NIOS system (in NIOS, go to Grid –> Grid Properties);
- Register the NetMRI appliance with NIOS, with or without a certificate for secure HTTPS communication (for information, see ACM Registration and Certificate Usage Between NetMRI and NIOS);
- Obtain the factory MAC address for each of the new devices to be installed into the network, plus the initial IP address to be assigned to the devices;
- The admin account running ACM jobs on NIOS, and performing ACM setup on the NetMRI system, must be properly defined on both systems. The user name must be the same on both systems. Access privileges must be equivalent on both sides of the configuration; the account Roles/Privileges defined in NetMRI determine the ACM features to which the user has access in NIOS;
Note: The ACM system supports single sign-on between the NIOS and NetMRI appliances When you sign on to one appliance in ACM, the other appliance automatically recognizes the login. For information, see Creating a Single-Sign-On Admin Account.
- Set the admin accounts to be notified when ACM Issues and events pop up. The best location to view event information is the Task Viewer in NIOS' Automation Tasks Dashboard. Triggering issues and events are reported on NetMRI's main Issues page in Network Analysis –> Issues. Additional configuration may be needed to ensure notifications are sent to the right people.
...
- All NIOS appliances running DHCP services must be configured to forward Syslog messages to NetMRI. This ensures the Automation Change Manager detects the correct events for triggering jobs (you perform this task in the topic Deployment for Bare Metal Provisioning, Pt. 1;
- Activate a TFTP server with configuration stub files and full configuration files for the device types to be supported. NetMRI has a built-in TFTP server that is always running by default and is accessible by the same methods as any TFTP server. For information, see Notes on TFTP Service for ACM Operation.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
To define the required ACM admin account on both NIOS and NetMRI, do the following:
- In NetMRI, go to Settings icon –>General Settings –> Advanced Settings and go to the NIOS Administration section.
- Under NIOS User Name (on Page 2 of Advanced Settings), click the gear icon and choose Edit.
- Enter the user name of a NIOS admin account with privileges to validate DHCP servers located on the network by NetMRI. Click OK when finished.
- Under NIOS Password (on Page 2 of Advanced Settings), click the gear icon and choose Edit.
- Enter the password for the admin account you entered in Step 3, re-enter it to confirm; click OK when finished.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: Under some circumstances, the Rogue DHCP Server Detected issue may not trigger. NetMRI sends DHCP packets that will obtain responses from DHCP servers that can traverse networks through DHCP relays. Not all DHCP server will respond to DHCP packets sent by NetMRI for detection purposes. Also, some DHCP servers may be undetectable by NetMRI based on their position in the network; for example, DHCP servers that are connected to WAN interfaces and only send DHCP responses downstream will not respond to probes by NetMRI.
The Automation Change Manager acts on NIOS-generated DHCPACK syslog messages for triggering task execution. Part of NIOS configuration to support ACM consists of forwarding the syslog stream to NetMRI. This is typically done on a per-Grid-Member basis. DHCPACK syslog messages are sent whenever a DHCP lease is granted or renewed and contain the IP and MAC address of the end host. Upon receipt of a DH
Anchor | ||||
---|---|---|---|---|
|
If the discovered device/end host is found to be running a DHCP server, NetMRI raises a Rogue DHCP Server Detected issue and a series of events takes place, further described in the topic Activating Rogue DHCP Server Remediation.
NIOS DHCP configuration intuitively supports custom DHCP options, which follow the RFC 2132 guidelines. DHCP configuration settings can quickly apply across the entire NIOS grid (in NIOS, Grid Manager –> DHCP –> Grid DHCP Properties), or to a specific DHCP range on a specific member. The same guideline applies if NetMRI operates with a standalone NIOS appliance running the DHCP service in the network. You can also create new DHCP ranges
Anchor | ||||
---|---|---|---|---|
|
For Cisco:
...
All NIOS appliances running DHCP service must also forward Syslog messages to NetMRI.
The Automation Change Manager also detects DHCPACK messages automatically through its own Syslog service, and uses them as the triggers for ACM tasks.
Note: For more details on configuring the DHCP service on NIOS systems, see the Infoblox NIOS Administrator Guide, Chapter 19, Infoblox DHCP Services and Chapter 20, Configuring DHCP Properties.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
A NIOS appliance can also operate as a TFTP server. The enterprise network may also have an existing public TFTP server. For more information on us
Anchor | ||||
---|---|---|---|---|
|
For initial bring-up of the bare-metal device, NetMRI's TFTP server directory contains a small Cisco or Juniper configuration file. The two files are called:
...
Other files may also be present. You can also create your own.
Each file contains the organization's assigned device IP address and assigned credentials for the Enable and Telnet/SSH passwords and secret settings. A sample network_confg file includes the basic credentials for the Enable password and for telnet and SSH access, and enables SNMP:
username autoconfig privilege 15 password 0 autoconfig snmp-server community autoconfig RO
line vty 0 4
exec-timeout 60 0 logging synchronous login local
transport input telnet ssh end
A sample Juniper file is in the topic Sample Juniper router.conf File.
If the administrator wants to deviate from the autoconfig string (i.e. for hostname, community string and/or CLI credentials), the following holds true:
...
You can edit the configuration files to contain your own credentials and settings. Access configuration files by using the NetMRI administrative shell and entering an ls tftp command. When finished, run the NetMRI tftpsync command to move these files into the public TFTP server file system.
Note: NetMRI also runs a TFTP service by default and may be used for serving configuration files.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Note: The ACM system supports single sign-on between the NIOS and NetMRI appliance. When you sign on to one appliance in ACM, the other appliance automatically recognizes the login.
You can install a CA certificate to secure communications between the NetMRI appliance and the NIOS appliance. The best method is to export a certificate in
Anchor | ||||
---|---|---|---|---|
|
...
export cert
The system copies a NetMRI self-s
Anchor | ||||
---|---|---|---|---|
|
- Transport the file to a location accessible from your workstation's local file system.
- Connect to the NIOS appliance as the administrator.
- On the ACM Dashboard, click the gear icon and choose ACM Registration.
- Enter the NetMRI appliance's IP address, and the admin account and password. If you are installing a certificate from NetMRI, proceed to Step 8.
- If you do not wish to install a certificate, click Register. An ACM Registration message appears:
Connection cannot be validated without a certificate. This may lead to security issues unless connection to NetMRI is physically secured. Would you like to continue?
- Click Yes if you wish to operate ACM without a certificate. Otherwise, do the following:
- Click the Enable Certificate Validation checkbox.
- Click the Select button to browse for the certificate file.
- Select the certificate file and click Open. The certificate Info fields add the information from the imported certificate.
- Click Register. NetMRI registers with the NIOS appliance and the certificate is added to secure HTTPS communications between the hosts.
Anchor | ||||
---|---|---|---|---|
|
The Provision Bare Metal Device automated task enables automated installation of new switches and routers into the network.
Provision Bare Metal Device (which we will refer to as BMP, for Bare Metal Provisioning) is used in initial deployments of many instances of the exact same device model, that will all use very similar configurations. For example, a company named Genuine Parts has 5500 storefront locations that will each use a new Cisco 2812 router as their gateway. Each device uses the exact same configuration, excepting the IP address, interface description and VLAN ID. Bare Metal Provisioning is defined for specific cases of this type.
BMP jobs cannot be executed across multiple types of devices in the same Job (e.g. a few 2812 routers, several 3750 switches, a dozen 2960 switches in the same job) because the Lists for BMP are written for a single device type for each job execution, to account for different numbers, interface types and other parameters. The job script must be modified to support the changes to the List for each job execution.
The BMP process is quite different from simply plugging a new Cisco appliance, giving it an IP address through a terminal program, allowing NetMRI to discover it and then pushing a configuration to it. BMP automates the process for deployments of the same device across many individual locations.
The Automation task enables cost and convenience savings by detecting the default behavior of new devices on the network, pointing them to TFTP servers from which the new devices download and install standardized bare-metal configuration files.
Configuration for the Provision Bare Metal Device automated task is primarily done in the NetMRI user interface. The automated task is automatically triggered by detection of a network device requiring configuration.
- Ensure the DHCP Options configuration is defined for all NIOS DHCP servers/DHCP ranges that will inter-operate with the Automation Change Manager. For more information, See Notes on DHCP Configuration for ACM Operation.
- Configure the NIOS appliance to forward Syslog notifications to NetMRI; on the NIOS appliance, choose Grid –> Grid Manager –> Members –> Grid Properties. Choose UDP as the transport protocol.
- Ensure the NIOS appliance is running the NTP protocol:
- From the Grid tab, select the Grid Manager tab -> Members tab -> Grid_member check box.
- Expand the Toolbar and click NTP -> NTP Member Config. If the Enable this Member as an NTP Server checkbox is enabled, nothing else needs to be done and you continue to Step 4.
- Ensure the TFTP server is up and running with the desired initial configuration files ready for download, and reachable within the network. For more information, see Notes on TFTP Service for ACM Operation.
- The required admin user accounts should receive the appropriate notifications when Bare Metal Provisioning jobs occur. Consult the topic Defining a Job Notification for more information.
- Ensure that the proper license is installed in the NetMRI appliance by going to Settings icon –>Setup –> Settings Summary; check the Module Settings list. Automation Change Manager should read Enabled. (If necessary, also ensure the proper license is already installed in the NIOS system.)
- Register NetMRI with the NIOS system. This is done in NIOS through the following:
- From the Dashboards tab, select the Tasks tab.
- In the Automation Tasks pane, click the down arrow gadget and select ACM Registration.
- Under ACM Settings, do the following:
- Enter the IP address or resolved host name of the Automation Change Manager system supporting the Automation task pack.
Note: Optionally, you can load a CA certificate from NetMRI to NIOS to secure communications between the two systems.
- Enter the ACM Admin Password.
...
- Click Save and Close.
- Follow the same steps for any other DHCP range as necessary.
- In the NetMRI appliance, choose Settings icon –> General Settings –> Advanced Settings and make sure the following two settings are turned On:
Discovery Ignore Duplicate MACs
- Discovery Truncate IP History
- Choose Settings icon –> Setup –> Credentials –> CLI and add a new USER credential of admin/infoblox, with an ENABLE password of infoblox. These credentials are pushed to the bare metal device after it boots with its TFTP configuration.
- Choose Settings icon –> Setup –> Credentials –> SNMPv1/2c and click the autoconfig community string (it defaults to Priority 16). Click Edit and change its Priority value to 1.
- Also in the SNMPv1/2c page, click New and create a new community string infoblox. Assign it a Priority value of 2 and click Add.
- Continue to the following topic, Deployment for Bare Metal Provisioning, Pt. 2
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
NetMRI provides Config Templates to support Bare Metal Provisioning for several standard Cisco and Juniper device types.
- If you plan to create any new config templates for different device models beyond the models built in to the Automation Change Manager release, do so now. Note that the set of variables defined in the config templates are fixed. They are set by the values in the columns in the TAE BMP Device Provisioning list or from the TAE BMP Site Settings list. For more information, see Working with Configuration Templates.
- In the TAE BMP Switch Model Interface Defs list: If the switch model to be provisioned is already in the table, no information needs to be entered about interface configuration. If you have new model information, add the Vendor Model Key value and interfaces values for the new device types from Juniper or Cisco. Click Save when done.
...
- In the ACM BMP Device Provisioning list: Identify the device(s) to be provisioned, and enter the Factory MAC addresses, site-assigned management IP addresses, mask and gateway information, and the cross-reference to a BMP Site Settings list record (in the Site Settings Name field). If you have a significant number of values to enter, you can import them into the list. Click Save when done.
- Using a terminal program, open a CLI session on the NetMRI appliance using the admin account, and enter the tftpsync command. The default device config files are copied to the tftpboot directory on the NetMRI appliance.
- Go to the NIOS appliance and open the Tasks Dashboard.
- Click the Settings icon for the Bare Metal Provisioning task. The NetMRI instance appears in a new browser tab, displaying the Job History page. You track job execution here or in the NIOS Task Dashboard's Task Viewer. For information, see Viewing the Job History and the Job Viewer.
Perl Scripts for Bare Metal Provisioning
A number of read-only scripts are included in the licensed Automation Change Manager package. The Provision Bare Metal Device script is referenced by the Provision Bare Metal Device triggered job (For information, see Triggering Jobs Through Events). This script runs whenever the template job is invoked by NetMRI's detection of a new network device. Explore this NetMRI page for more script examples that can provide ideas for development.Anchor Activating Rogue DHCP Server Remediation Activating Rogue DHCP Server Remediation
Activating Rogue DHCP Server RemediationAll DHCP servers on the network should be under administrative control. If any device offering DHCP leases to clients on the network is not properly administered, it violates many security guidelines and may cause configuration problems throughout the network. Some events may be unwitting or innocuous (an office worker installing a wireless access point in their cube to share a resource), or may be an attempt to hijack clients and steal information. To prevent such issues, the Rogue DHCP Server Remediation task performs detection, location and isolation of such devices.Anchor bookmark614 bookmark614
The Rogue DHCP Server Remediation automated task does not provide NIOS-based settings; configuration for this task is done in the NetMRI user interface. The task is triggered by detection of a network device requiring remediation.
As noted in the Triggering Jobs Through Events topic, two Triggered Jobs are associated with rogue DHCP remediation:Locate Rogue DHCP Server
When NetMRI detects any system running the DHCP protocol that is not on the list of approved DHCP servers and is not a NIOS-approved DHCP server, NetMRI executes this job and locates the rogue system on the network. The job runs automatically and provides logs when it executes.
Isolate Rogue DHCP Server
After any rogue DHCP server is detected and located by the Automation Change Manager, the device is isolated to a designated isolation VLAN for remediation. This job requires approval by the administrator to execute.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Configuration for the ACM Rogue DHCP Server Remediation task is straightforward.
- Rogue DHCP remediation begins with preventing established, legitimate DHCP servers, such as NIOS appliances supporting the DHCP service, from being identified as a rogue server. You compile all legitimate DHCP servers on the network into the ACM Allowed DHCP Servers list (Config Management –> Job Management
–> Lists);
- Because the Rogue DHCP jobs are issue-driven, a suspected rogue device may first need to be detected by NetMRI. Ensure fingerprinting is enabled in the NetMRI system (Settings – Setup –> Network Polling –> Fingerprinting checkbox);
- Also ensure that the required user accounts get the appropriate notifications when Rogue DHCP events occur. Consult the topic Defining a Job Notification for specific information.
- NetMRI also scans the standard DHCP TCP and UDP ports (check settings in (Settings – Setup –> Network Polling and enter "bootp" as the search string in the Port Scan List).
- The NIOS administrator account username and password should be added to Advanced Settings (Settings icon
–>General Settings –> Advanced Settings –> page to the NIOS Administrator category).
To enable the NetMRI-to-NIOS communication, you also define the NIOS administrator User ID and password that NetMRI will use to check the configuration in NIOS. If this is not yet in place, see Creating a Single-Sign-On Admin Account.
Rogue DHCP Triggering Events
The following event causes the initial Rogue DHCP discovery process to start:
...
If the DHCP service exists on the new device, and it is not in the ACM Allowed DHCP Servers list or a NIOS-sanctioned DHCP server, the new device is deemed rogue.
A new Rogue DHCP Server Detected Issue is fired by the Automation Change Manager.
Once this issue appears, the first of the two ACM Rogue DHCP Server jobs, Locate Rogue DHCP Server executes with no intervention by the admin.
In The Event of a Positive Match
Several possible outcomes ensue when the Locate Rogue DHCP Server job completes. The first outcome, described in this section, is a positive match (the rogue server is found):
...
- Go to the NIOS system and open the Tasks Dashboard.
- Click the Settings icon for the Rogue DHCP Server Remediation task. The NetMRI instance appears in a new browser tab, displaying the Job History page. This is where you track job execution in NetMRI. (For information, see Viewing the Job History and the Job Viewer). The page lists the Locate and Isolate jobs and their results. You can also open the Task Viewer in the NIOS Task Dashboard.
In The Event of a Negative Match (DHCP Server Cannot be Isolated)
In some cases, the Locate Rogue DHCP Server job executes but isolation cannot be performed (effectively, the rogue server cannot be found). This can happen for one of four distinct reasons:
...
Should any of these four results take place, the Automation Change Manager sends a new Issue, Rogue DHCP Server Cannot be Isolated. The Issue report also provides the specific reason that the device wasn't isolated.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Whether the match is positive or negative, triggering issues are reported on NetMRI's main Issues page in Network Analysis –> Issues and in the NIOS Task Viewer. NetMRI Issue notifications are created, in the Settings icon –> Notifications section –> Subscriptions page. The system sends notifications in one of three ways: Syslog messages, e-mail and SNMP traps. For more information, see Managing Issue Notifications.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Job History tab (Config Management –> Job Management –> Job History tab) lists all running jobs, scheduled jobs, and jobs that finish with errors. Information displayed in the table includes job status, start and end times, and run count.
The Job History works with both CCS and Perl scripts and displays information resulting from Automation Change Manager job runs.
Click the hyperlink in the Name column. The Job Viewer window opens for the selected job.
Click the hyperlink in the Script column. A browser pop-up window appears displaying the script text.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Job Viewer (opened from
Anchor | ||||
---|---|---|---|---|
|
...
To view job details for a device: Click the hyperlink in the Status column. The Job Details Viewers opens for the chosen job, automatically displaying the Process Log for the selected job (see Viewing Job Details for more information).
Click the hyperlink in the IP Address column. The Device Viewer appears for the device associated with the chosen IP address (see Inspecting Devices in the Network for more details).
...
Note: The Cancel icon will only appear in the Actions column for a device if the job is currently pending or running on that device. The Actions column is empty if the job has been completed for all devices.
- Click Cancel All to cancel all running Jobs in the page.
...
- Click the Rerun Errors button. The Run... Script dialog appears.
- In the Run... Script dialog, double-click items in the Hosts lists to add them to the Selected list. The Selected list represents the devices against which the job should be re-run.
- Click Run Now.
- Click OK to continue.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The Job Details Viewer opens from any hyperlink in the Status column in the Job Viewer. A Connections dropdown appears in the top of the Job Details Viewer. For Perl jobs that open simultaneous connections with multiple devices, each device in the job is listed here. Toggling through the devices shows the corresponding job details for the given device in the Job Details Viewer.
- If a script includes the ability to run multiple sessions, you can see the sessions running under the Job Details Viewer –> Connections drop-down list.
- The Script tab displays the full script run against the device;
- The Status Log tab shows the results of various internal script operations. Some of the information here may be useful in troubleshooting a failure. A color-coded view of the information in this tab is available in the Process Log tab;
- The Process Log tab shows individual steps or actions in the job on the device, including which matches occurred and whether an issue was generated (if the script generates an issue). This analysis is limited to 500 lines of output; if more than 500 lines of output were created, you can view the entire analysis in the process.pdf file available in the Files tab;
- The Session Log tab lists the session details, indicating all CLI events that occurred during the job;
- The Files tab provides links to download any files related to the job for this device. The all.zip file contains copies of all associated files for convenience in downloading.
Anchor Using Perl Libraries Using Perl Libraries Anchor bookmark624 bookmark624
Using Perl LibrariesAnchor bookmark625 bookmark625
Note: Read/write operations on Perl scripts in the Libraries page are limited to user accounts with the Scripts:Level 3 privilege. All other users are limited to read-only operations. Libraries also do not have an associated run level.
You store Perl subroutines in NetMRI's dedicated Libraries page. LIbraries provides standard Copy, Export, Edit and Delete options.
To import a new Perl library file, do the following:
...
To copy an existing script: In the Actions column, click the icon and choose Copy from the menu. To edit an existing script: In the Actions column, click the icon and choose Edit from the menu.
To export an existing script: In the Actions column, click the icon and choose Export from the menu. The appliance exports a text file.
To delete an existing script: In the Actions column, click the icon and choose Delete from the menu.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The example below is a Juniper autoconfiguration file for a 48-port EX-class Ethernet switch. This example is edited for brevity. Juniper autoconfig files require the definition of all interfaces of the device, unlike Cisco. Any undeclared interfaces will otherwise be non-functional in the system.
Juniper devices do not retain their DHCP-leased address obtained during the initial bootup, after the initial configuration is applied. The DHCP configuration must also be included in the autoconfiguration file or the device will drop off the network.
system {
host-name autoconfig; root-authentication {
encrypted-password "$1$0.3byxFX$2DXqXFT9alWJXHYgSjXqg."; ## SECRET-DATA
}
login {
...
community autoconfig {
authorization read-only;
}
vlans {
}
default {
l3-interface vlan.0;
}
}