NetMRI's Job Management feature set (Config Management –> Job Management) enables automation of processes for monitoring and analyzing the network, and to perform routine maintenance. Job Management is also the enabling feature in the Automation Change Manager (ACM) system, which leverages support by the NetMRI appliance to automate tasks in the Infoblox NIOS grid network. Job Management and Job Automation operations involve the following NetMRI tools:

• Scripts, used for automation tasks across numerous devices across the network, which execute Command Line Interface commands on network devices. You can write scripts in Infoblox’s proprietary CCS language, Perl, or in Python, using the standard Perl and Python API;
• Jobs, which are scheduled instances of scripts that run against selected devices or device groups. You can also use end-user credentials for specific jobs;
• Custom issues, which scripts can raise to point out conditions discovered during script processing. See the section Creating Custom Issues for more information on custom issues and their use in jobs.

Job automation ensures consistency across related devices in the managed network and saves valuable time. Because NetMRI supports Perl, Python, and its own proprietary CCS scripting language, change automation offers significant benefits:

• Users can define generic configuration templates for large collections of like devices such as Cisco or Juniper routers and switches;
• Users can execute mass change rollouts through the downloading of template files, reducing the need to execute sequences of CLI commands, and enabling larger-scale automated changes across the network;
• Perl and Python support ensures an almost infinite capability for expansion of automation features;
• Apply complex script logic and looping through Perl/Python, with script logic modules and subroutines.
• Scripts can reference external tables and lists to populate variables when executing actions on devices.

Note: When using Perl/Python 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 and Python-based job automation.

NetMRI provides a dedicated guest virtual machine (VM) environment under which Perl/Python 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/Python script.

Job scripting implementation is done through the NetMRI Job Wizard. Substantial planning and preparation may be needed before implementing jobs.

Automation Change Manager (ACM)

The Automation Change Manager (ACM) uses NetMRI scripts and other job automation features to enable the Automation Tasks feature set in the Infoblox NIOS^TM 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 the Infoblox grid master, the ACM automation tasks enable performance of the following tasks with a few mouse clicks:

• Network Provisioning – Define new IPv4 and IPv6 networks;
• Port Activation – Enable interfaces on selected switches and routers;
• VLAN Reassignment – Reassign and reconfigure VLAN port assignments;
• Bare Metal Provisioning – An automatically triggered task to detect and provision new switches and routers on the network. BMP is most useful for bringing up many new deployments of the same device model with very similar configurations;
• Rogue DHCP Server Remediation – An automatically triggered task to detect and remediate devices on the network that are attempting to act as DHCP servers without authorization.

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, support the ACM functionality. The following topics describe the elements used to build the ACM system.

Creating and Scheduling Jobs

A job schedules a script to run against selected devices. You schedule jobs to run once or on a regular basis, at times  you specify. Create and manage scheduled jobs at Config Management –> Job Management –> Scheduled Jobs tab.

To run a script as a job immediately, see the section Running Scripts Immediately later in this topic.

You can import existing scripts using the Import icon on the Scripts tab. When you do so, ensure that your script uses the UTF-8 encoding.

To create and schedule a new Job, do the following:

1. At the top right of the page, click New. The Fill Out Job Details Wizard opens.
2. Enter a Job Name.
   Click the Approved option if your user account allows it. (A job cannot be scheduled until approved. Another admin account may need to approve the scheduled job.)
3. Type a Job Description of the job.

Note: Bulk push mode is supported only on Juniper and Cisco devices. Cisco downloads via TFTP, and Juniper configs download via the HTTP protocol.

4. 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.

5. 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 ired as part of the job. Templates may furnish default values, or you can enter desired values in the defined fields.

6. When finished, click Next.

If custom fields are defined for jobs, you will see the Fill out Custom Information screen. If none are defined, proceed to Step 7 below.

7. Fill in any other data associated with the job.

8. Click Next. The Select Device Groups or Devices page appears.

Click device groups and/or devices and click the –> icon to add the group to the right pane of the page.

9. Click Next. The Schedule when Job should run page appears.

Specify the schedule for the job, including the Recurrence Pattern (Once, Hourly, Daily, Weekly, or Monthly), and the Execution Time (specify in half-hour in crements). The selected Recurrence Pattern determines additional schedule settings based on the selection.

10. 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.

11. Click Next.

In the Review and save screen, review the job specifications. If changes are needed, click the < Previous button to return to an earlier screen.

12. Click Save.

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:

1. In the Actions column, click the icon and choose Copy from the menu.
2. In the Name dialog, enter a name for the copy, then click OK.

To edit an existing job, do the following:

1. In the Actions column, click the icon and choose Edit from the menu. The Job Wizard opens to the Summary of Job screen.
2. Click Edit. The Fill out Job Details screen appears.
3. Edit the job as needed. Use the Next –> and <– Previous buttons to navigate the wizard.
4. Navigate to the Review and Save screen, then click the Save button.

To delete a job: Click the Delete button, then confirm the deletion.

Running Scripts Immediately

To run a script as a job immediately, do the following:

1. Go to Config Management –> Job Management –> Scripts tab.
2. Hover the mouse over the Action menu for your desired script, and choose Run Now from the Action menu.
   The Script Run Now window appears. You can choose to run a script (the default) or a template as a job. Templates support a push mode; scripts do not.
3. 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.)
4. If you have custom fields for data entry, add that information and click Next. If not, simply click Next.
5. 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.
6. 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.

Working with Configuration Templates

If you plan to work with categories of Cisco and Juniper switches and routers that are not part of the Automation Change Manager set, you create a new "canned" IOS or JunOS template in the Configura tion Templates page. This is the foundational tool for adding device types to the Automation Change Manager (ACM).

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, Perl, and Python.
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 on Change Manager. The sample Cisco Catalyst 37xx IOS template reads as follows (edited to remove extra line feeds):

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:

1. At the top right of the page, click New. The Config File Template dialog appears.
2. Enter a Name for the template.
3. Choose the Vendor and Device Type.
4. Enter the Model and Version.
5. Enter any Template Variables required for the new Config File Template. Consult the other Config Templates if you need examples.
6. Paste in or write any configuration file text that is required for the template.
7. Click Save & Close.

Admins may provide templates exported from another NetMRI appliance or from an archive.
To import a template from an existing configuration file (you might wish to do this because you are creating a Config Template for a different type of device in your network), do the following:

1. At the top right of the page, click Import.
2. Enter the path and file name, or click Browse... to locate the file.
3. Click Import.

To export the entire table of templates from the Config Template page, do the following:

1. At the top right of the page, click CSV Export. A dialog box appears, requesting Do you want to open or save this file? If you have Excel or another CSV file-compatible spreadsheet program, you can immediately open the complete table of templates by simply clicking Open.
2. To save the table data as a new CSV-format file, click Save.
3. Click Save in the Save As dialog after browsing folder paths and defining the file name. (Procedures may vary slightly based on the operating system.)

NetMRI does not export the templates — the table listing all the templates is exported to an externally readable file.

To copy a template, do the following:

1. Copy. The Copy Script dialog appears.
2. Enter a name for the new template, then click OK.

To edit a template, do the following:

1. Edit. The Edit Template dialog appears.
2. Edit the template as needed. Note the similarities between the Edit Template window and the Edit Job window.
3. Click Save & Close.

To create a Policy from a template and to test a template as a Policy, do the following:

1. Edit. The Edit Template dialog appears.
2. Delete or replace device specific terms with regular expressions. You will need to have significant understanding of regular expressions and Policy definition. See Policy Design Center for more information.
3. Click Create Policy.
   All variables in a template must be replaced with specific values before the template is saved as a new Policy. We recommend using the Test Policy feature before saving the template out as a new Policy.

To test a template as a policy, do the following:

1. Test Policy. The Policy Selector dialog appears.
2. Select the policy or policies to test against.
3. Click Test.

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.

Creating New Jobs From Config Templates

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.

To create a new Job from an existing config template, do the following:

1. Action Schedule or Run Now from the menu. The Job Wizard appe ars, showing the Fill Out Job Details page.
   The Fill Out Job Details page differs based on whether you wish to immediately run the job (Run Now) or to schedule it for a later occasion.
2. Enter a Name and Job Description for the new job.
3. 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.
   (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.

4. Click the Templates tab, and select the template that will execute as part of the Job. Enter any required input values.

5. 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.

6. At the bottom of the page, click Next.

7. Choose the Devices or Device Groups to be part of the new Job, and click Next.

8. 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.

9. Click Next.

10. (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.

11. 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.

12. (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.

Downloading a Config Template

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:

1. Click the Action icon and choose Run Now from the menu. The Job Wizard appears, showing the Fill Out Job Details page.
   The Fill Out Job Details page differs based on whether you wish to immediately run the job (Run Now) or to schedule it for a later occasion.
2. Choose the Push Mode option: Text File. This tells the job engine that you are downloading a template's configuration file to a text file. No device configuration takes place if you choose this option.
3. Click the Templates tab in the Fill Out Job Details page, and select the template for the Job. Enter any required input values.
4. Click Next. The Select Device Groups or Devices page appears, showing a Devices tab.
5. (Optional step) You may choose one or more devices to map the downloaded configuration text file.
   • If you choose no device, the downloaded template is merged with the input values you defined in Step 3.
     For configuring an undiscovered device using a config template, this is a perfectly acceptable option;
   • Choosing a single device generates and downloads the configuration text file with a name comprised of the device IP and host name;
   • Choosing multiple devices produces a Zip archive file with template files generated for each device using the same inputs.

6. After choosing the device to merge for the text file, if any, click Next.

7. 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.

8. (Text File Push Mode only) To download the template's configuration file to your hard disk, click the Download Configuration button. A configuration text file containing the inserted values or variables for the template is downloaded by your Web browser to your designated Downloads directory. Because the Push Mode is for a Text File, the job is complete at this step.

1. • (Text File Push Mode only) If an input value in the Wizard page remains empty, and you've chosen a device to map and merge against, the Job wizard displays a Merge with Empty Values dialog to verify the operation; in which the existing values are to be rendered 'empty,' (e.g., replaced with no setting), kept as-is in the template, or to Cancel the job.
   • Click Yes if the replacement of variables or data with empty values is intentional. The job executes and the new configuration text file downloads to the Downloads directory specified in your browser.
   • Click No to run the job as it is now defined without empty values (you may have settings in the config template that you want to preserve for an undiscovered device). The job executes and the new configuration text file downloads to the Downloads directory specified in your browser.
   • Click Cancel to return to the job wizard page.

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.

About Template Variables

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 able (the variable name, input type and input format) in the Template Variables field. A simple example is given below:

$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.

Defining Lists for ACM, Perl, Python, and CCS Script Reference

Note:

Lists are a key component in the Automation Change Manager (ACM) feature set. The Lists page (Config Management  –> Job Management –> Lists) allows the creation, editing, importing and exporting of lists to provide external lists of data to Perl/Python script variables, CCS script variables, and configuration template variables. 

Lists are handy for dynamically looking up values to variables in Perl/Python and CCS scripts. CCS and Perl/Python 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:

1. On the Config Management –> Job Management –> Lists page, choose Import.
2. Click Browse and locate the CSV file in the file selector. Click Open after selecting the file.
3. Click Import to import the file into the Lists page.

To create a new list, do the following:

1. On the Config Management –> Job Management –> Lists page, choose Add.
2. Enter a List Name.
3. In the Description field, enter a meaningful description for the new list.
4. Type or copy and paste the list text into the text entry field.
5. Click Save at the bottom of the screen when you are finished.

To edit a list, do the following:

1. On the Config Management –> Job Management –> Lists page, select a list in the left pane. The right pane refreshes to show the contents of the list.
2. Click the down arrow icon on a column header and choose Edit Column. The Column Name dialog box appears. Enter the new column name and click OK.
3. Click Add Row at the bottom right to add a new row to the list table, or click a check box for a row and click Delete Row to modify the set of table rows in the list.
4. Click Save when done.

To delete a list, do the following:

1. On the Config Management –> Job Management –> Lists page, select the list to remove and choose Delete.

To export a list, do the following:

1. On the Config Management –> Job Management –> Lists page, select the list to export and choose Export.
2. The browser prompts to open the data as a new Excel .CSV file or to save the data as a new file.

Pre-Defined Lists for ACM Operation

The Automation Change Manager (ACM) relies on a series of lists in the Config Management –> Job Management –> Lists page for use in automated jobs. You can edit these lists when necessary. The installed ACM lists consist of the following:

• 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 .)
• 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.

Defining Larger Provisioning Configurations

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.

Configuring a New List Entry

In some cases, a switch type may not be defined in the LIsts page. To define a new list entry:

1. Go to Config Management –> Job Management –> Lists.
2. Select the ACM BMP Switch Model Interface Defs list in the left pane.
3. Click Add Row.
4. 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.

1. Enter the slot/port values, including port ranges, separated by commas, in the Interfaces column.
2. Click Save.

Triggering Jobs Through Event s

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 to execute automated tasks from the connected Infoblox NIOS appliance. Triggering sources consist of the following:

• Policy rule violations;
• Custom and standard Issues.

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:

Defining Triggered Jobs

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 h you would like this trigger to be active, and the device and interface groups to whose members the trigger applies.
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:

1. Click the New button at the top right of the page. The Triggered Job Wizard opens.
2. In the Select Trigger screen, specify a policy rule or issue that will trigger the job by selecting a Trigger Source.
3. In the left panel, select the policy rule or issue in the list. Details appear in the right panel, where you verify that you have selected the correct policy rule or issue. Enter all or part of the name at the top of the panel.
4. Click Next.
5. In the Trigger Filters screen, specify the conditions that must be satisfied for the job to run:
   In the Device Groups list, click, CTRL+click or SHIFT+click to select the group(s) that can trigger the job. In the Active Time Window list, select the time period during which the job will respond to triggers.
   In the Severity list (available only if the Trigger Source is Issue), select the level of event to be reported. Issues are raised at one of three severity levels - this filter represents which severity levels will trigger the event for the given issue.
6. Click Next. The Define Job screen appears.
   Specify the action to be taken in response to the trigger:
7. If you don't want the job to run, uncheck the Enabled option. (You might want to prevent a job from running during maintenance or when manually changing settings.)
   In the lower left panel, select the script or job template to be run.
8. Specify a Job Name: Select Use Script Name, or select Use Custom Name and enter a name in the field. To Edit an existing Triggered Job: Enter all or part of the name near the top of the panel.
   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).
9. Click Next. The Schedule Job Execution screen appears.
10. To specify when the job should be run, select either Trigger Action: Run Job Immediately (if selected, then click Next) or Schedule Job.
11. In the To Run At list, select a time to run the job.
12. In the The Following list, select a day where to run the job.
13. 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.
14. Click Next.
15. In the Review and Save screen, review the job specifications.
16. To make changes, click < Previous to return to the page(s) needing to be revised.
17. 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.

Automation Change Manager (ACM) Triggering Sources

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 lly detected by NetMRI and separately developed jobs are built in to the Triggered Jobs page. The three Triggered Jobs you see after installing the Automation Change Manager license include the following:

• Provision Bare Metal Device (Issue-driven)
  The ACM Provision Bare Metal job executes auto-configuration of a new device on the network immediately after detection by NetMRI. This job requires approval by the administrator before execution. Also refers to the Perl script, Provision Bare Metal Device, for applying the config template to the new device.
• Locate Rogue DHCP Server (Issue-driven)
  When NetMRI detects any system running the DHCP protocol that is not on the list of approved DHCP servers or is not considered a sanctioned DHCP server by NIOS, NetMRI executes the job and compiles the information to locate that rogue system on the network. Locate Rogue DHCP Server runs automatically and provides logs when it executes.
• Isolate Rogue DHCP Server (Issue-driven)
  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.

Checklist for Running The Automation Change Manager System

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:

• The user has the proper admin or superuser access to both the Automation Change Manager and to the NIOS system;
• The correct ACM license is installed on both the Automation Change Manager and on the NIOS Grid Master. A separate ACM license must be installed for both the NetMRI appliance, and for the NIOS appliance that will communicate with NetMRI.
• If the NetMRI appliance is based on a virtual machine, you must also set up a second VM as the NetMRI sandbox for job operation. See Using the NetMRI Sandbox and Setting up a Remote Sandbox for complete information on Sandbox setup and operation.

Note: To ensure that the proper license is installed in the NetMRI system, go to Settings icon –>Setup –> Settings Summary and read the Module Settings list. Automation Change Manager should read Enabled.

The administrator can use the Automation Change Manager with a NIOS Grid by meeting the prerequisites below.

• 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.
  You may need to define NetMRI Issue notifications in the Settings icon –> Notifications section –> Subscriptions page. Notifications are sent in three ways: Syslog messages, e-mail and SNMP traps. For information, see Managing Issue Notifications , and Defining a Job Notification for specific configuration.
• 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 .

Creating a Single-Sign-On Admin Account

To define the required ACM admin account on both NIOS and NetMRI, do the following:

1. In NetMRI, go to Settings icon –>General Settings –> Advanced Settings and go to the NIOS Administration section.
2. Under NIOS User Name (on Page 2 of Advanced Settings), click the gear icon and choose Edit.
3. 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.
4. Under NIOS Password (on Page 2 of Advanced Settings), click the gear icon and choose Edit.
5. Enter the password for the admin account you entered in Step 3, re-enter it to confirm; click OK when finished.

Notes on DHCP Configuration for ACM Operation

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 CPACK syslog message, if a network =device or end host is not known to NetMRI, a Discover-Now operation executes.
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 on any NIOS appliance running DHCP, to support Cisco and Juniper DHCP options for ACM bare-metal provisioning.
For Cisco:

• option tftp-server-name code 66 = text (Option 66, uses the IP address of the TFTP server or an FQDN);

For Juniper:

• option mobile-ip-home-agent code 68 = array of ip-address (Option 68)

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.

Notes on TFTP Service for ACM Operation

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 ing a NIOS appliance as a TFTP server, see the Infoblox NIOS Administrator Guide, Chapter 8, File Distribution Services.
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:

• network_confg (Cisco)
• router.conf (Juniper)

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:

• The defined hostname must remain autoconfig;
• You can change the community string, and you should update the global community string guesser list with the desired community string;
• You can change CLI credentials, and you should update the global CLI credentials guesser list with the desired CLI credentials (i.e. username, password and enable password);
• The stub configuration files must be updated to reflect desired changes, and if using NetMRI's TFTP server, redeployed using the admin shell tftpsync command.

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.

ACM Registration and Certificate Usage Between NetMRI and NIOS

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 NetMRI and import it to the NIOS appliance that performs the ACM Registration and runs the Tasks Dashboard.

1. Open the NetMRI Administrative Shell (connect by SSH to the appliance and enter the administrator name and password) and enter:

export cert
The system copies a NetMRI self-s igned certificate suitable for use with the NIOS host, netmri.crt, to the root directory of the NetMRI appliance.

2. Transport the file to a location accessible from your workstation's local file system.

3. Connect to the NIOS appliance as the administrator.

4. On the ACM Dashboard, click the gear icon and choose ACM Registration.

5. 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.

6. 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?

7. Click Yes if you wish to operate ACM without a certificate. Otherwise, do the following:

8. Click the Enable Certificate Validation checkbox.

9. Click the Select button to browse for the certificate file.

10. Select the certificate file and click Open. The certificate Info fields add the information from the imported certificate.

11. Click Register. NetMRI registers with the NIOS appliance and the certificate is added to secure HTTPS communications between the hosts.

Deployment for Bare Metal Provisioning, Pt. 1

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.

1. 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 .
2. 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.
3. Ensure the NIOS appliance is running the NTP protocol:
   1. From the Grid tab, select the Grid Manager tab -> Members tab -> Grid_member check box.
   2. 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.
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 .
5. 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.
6. 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.)
7. Register NetMRI with the NIOS system. This is done in NIOS through the following:
   1. From the Dashboards tab, select the Tasks tab.
   2. In the Automation Tasks pane, click the down arrow gadget and select ACM Registration.
   3. Under ACM Settings, do the following:
   1. 1. 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.

    ii. Enter the ACM Admin Password.

d. Click Register to commit settings.

After registration, the ACM Registration menu item changes to read ACM Deregistration to support disconnection from the Automation Change Manager appliance.

8. To set NetMRI to receive Syslog from the NIOS appliances running DHCP, do the following on the NIOS system:

1. 1. Choose the Grid tab – >Grid Manager –> Members. Any member in the NIOS network running DHCP shows a green box under the DHCP column, indicating the members of the network that act as DHCP servers.
   2. Click the checkbox for at least one of the members running DHCP. (You can select more than one to perform this action.)
   3. Choose Grid Properties, and then choose Monitoring.
   4. Enable the Log to External Syslog Servers checkbox.
   5. To define NetMRI to receive Syslog messages, click the Add icon of the External Syslog Servers table and enter the Address information in the new row. Choose UDP as the transport. (Other table row settings should normally be left at their defaults.)
   6. Click Save and Close.

Individual NIOS appliances may need to be restarted for the changes to take effect.

9. Set up the DHCP protocol in the NIOS appliances. On each NIOS system running DHCP that you expect to participate in auto-configuring network devices, set the DHCP ranges as follows.

For the NIOS Grid, do the following:

1. 1. Choose the Grid tab –> Grid Manager –> Services. Select DHCP. All members in the NIOS network running DHCP show a green box under the DHCP column, indicating members acting as DHCP servers.
   2. Click the link for the member with a DHCP range you want to use for serving DHCP configuration to new devices through ACM. The Members Home page for the select appliance appears, displaying the list of DHCP ranges running on the appliance.
   3. Select the checkbox for the DHCP Range to modify and click Edit.
   4. Click IPv4 DHCP Options and scroll to Custom DHCP Options.

Example: for Cisco devices, choose option 66 and enter the FQDN, or the IP address of the TFTP server (which could be the NetMRI system, a NIOS appliance or another system).

e. Click Save and Close.

f. Follow the same steps for any other DHCP range as necessary.

10. 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

11. 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.

12. 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.

13. 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.

14. Continue to the following topic, Deployment for Bare Metal Provisioning, Pt. 2

Deployment for Bare Metal Provisioning, Pt. 2

NetMRI provides Config Templates to support Bare Metal Provisioning for several standard Cisco and Juniper device types.

1. 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 .
2. 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.

Note: The Vendor Model Key must be named identically to the config template referenced by the system. For example, the Config Template cisco_catalyst295024 matches the corresponding Vendor Model Key field in the list.

The TAE BMP Switch Model Interface Defs list maps the device model to the ports available on that type of device. The Model column is the name of the device model as reported by the device. The same model name is also used to select the configuration template to be used for the device.

3. In the TAE BMP Site Settings list: this list defines default configurations of switch ports. When you have a standard configuration for (example) Sales Branches, you set that configuration once in this list. Define any new list records you need for new site settings. New table rows may be added for this data set.
Among other settings, ports are assigned to VLANs in this list. Other vital settings include the Site Name, domain name, Syslog and NTP server and the site code. You also use the {} brackets for port ranges in this table. Click Save when done with changes.

4. 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.

5. 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.

6. Go to the NIOS appliance and open the Tasks Dashboard.

7. 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.

Activating Rogue DHCP Server Remediation

All 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.
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.

Rogue DHCP Server Checklist and Process

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:

• NetMRI detects a NIOS-generated DHCPACK Syslog message.

If this occurs, and ACM does not know the IP address/MAC address combination of the device from which the DHCP service advertisement originated, NetMRI executes discovery on the new device and executes a DHCP Service Test on the new entity.
If NetMRI discovers the new device on its own, it can happen in one of two ways:

• The admin initiates a Discover Now session;
• Automation Change Manager discovers the new device. In these cases, NetMRI immediately runs a DHCP Service Test.

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):

1. The upstream switch port from which the DHCP messages originated is found, and that upstream port has only a single downstream MAC address connected to it. This downstream MAC address is the culprit.
2. A Rogue DHCP Server Located Issue displays in NetMRI's main Issues table (Network Analysis –> Issues) and in the NIOS Task Viewer. Then, after approval, the Isolate Rogue DHCP Server task activates.
   Click the Issue name in the Title column; the Issue Viewer appears in a separate browser window. Details of the issue are substantial, including the specific Device IP address, the device MAC and type, the identity of the upstream switch and the upstream interface, and the Last Seen timestamp.
   Any previously configured notifications will arrive at the admin's Inbox or through other channels.
3. Go to the NIOS system and open the Tasks Dashboard.
4. 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:

• The device in question stopped advertising its DHCP service;
• The upstream IP/MAC switch port from which the original advertisement appeared could not be located;
• The upstream port originating the DHCP advertisement is a trunk port;
• The upstream switch port, after being 'read' by NetMRI, turns out to have multiple downstream MAC addresses

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.

Rogue DHCP Issues and Notifications

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 .

Viewing the Job Histor y and the Job Viewer

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/Python 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.

Using the Job Viewer

The Job Viewer (opened from a job instance hyperlink in the Job History tab) provides detailed information about a job.

• The Details tab provides detailed information about the selected job, including start and end times for the job, the current Job status, and the IP addresses and names for any devices against which the job runs.
  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).

• The Issues tab lists issues raised by the job.
  To view Issue details, click a hyperlink in the Title column.

• The Files tab lists files created using the ARCHIVE keyword. You can view and download files from within this tab. (If the ARCHIVE keyword is not used in the script, this tab is empty.)
• Click the Cancel icon for that device.
• Turn auto-refresh On or Off from the Refresh dropdown.

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.

You create Views by resizing columns, by dragging column headers into different orders in the Viewer, and by adding or removing individual columns in the window.
Save views by using the Views pull-down menu.
You filter Job Details based on an expected value or multiple that may appear in any Job Viewer column.

To filter job information, do the following:

1. In the Job Viewer, click Filters. The Filters dialog appears.
2. In the Select a New Field dropdown, select the information field (End Time, Start Time, Action, Device Name, IP Address or Status). A new row appears in the requester.
3. Enter a Value.
   You can also change the Operator under which each filter entry operates. The default operator is (=) but can be changed to !=, Contains, Does Not Contain, Starts With and Ends With for precise matching.
4. To add additional fields for matching in the Job, click the Select a New Field dropdown again.
5. Click Apply to activate the filter. Click OK when finished with the new filter. To stop and quit without committing any changes, click the Close gadget on the requester.

To reschedule jobs that yielded errors, do the following:

1. In the Job History, click the Name link for a Job that produced an error. The Job Viewer appears.
2. In the Details tab, click Reschedule Errors.
3. In the Reschedule Errors requester, select a calendar Execution Date and Execution Time.
4. Click Reschedule Errors to reschedule the job. After a moment, the appliance displays a message: Created new job specification from device list. The new job needs to be approved.
5. Click OK to continue.

To re-run a section of a script that yielded an error, do the following:

1. Click the Rerun Errors button. The Run... Script dialog appears.
2. 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.
3. Click Run Now.
4. Click OK to continue.

Viewing Job Detail s

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/Python 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 JobDetailsViewer–>Connections drop-down list.
• The Script tab displays the full script run against the device;
• The StatusLog 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 ProcessLog tab;
• The ProcessLog 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 SessionLog 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.

Using Perl Or Python Libraries

Note: Read/write operations on Perl or Python 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 or Python subroutines in NetMRI's dedicated Libraries page. LIbraries provides standard Copy, Export, Edit and Delete options.
To import a new Perl or Python library file, do the following:

1. On the Config Management –> Job Management –> Library page, click the Import icon on the top right.
2. In the file requester, click Browse to navigate to the location of the file on the local appliance, select the file, and click Import.

To create a new Perl or Python Library file, do the following:

1. On the Config Management –> Job Management –> Library page, click the New icon on the top right.
2. Add a Name for the new script.
3. Enter the desired Category for the new script. (The Category field allows you to define any category you wish; the Library of scripts is sortable by the Category column.)
4. Enter a new Description for the script.
5. Enter the new script in the large text field in the Add Script requester. A script previously written in a text editor can also be copied and pasted.
6. Click Save or Save and Close to save your changes.
7. Click Export to save your changes to n external file.
8. Click Cancel to remove changes.

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.

Sample Juniper router.conf File

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 {

user autoconfig {

uid 2000;
class super-user;

authentication {

encrypted-password "$1$9/yWTmgz$tLG9dq6ptGqkbnPpDwhfz."; ## AutoConfig

}

}

}

services {

ssh {

protocol-version v2;

}

telnet;

}

}

interfaces {

ge-0/0/0 {

unit 0 {

family ethernet-switching;

}

}

ge-0/0/1 {

unit 0 {

family ethernet-switching;

}

}

ge-0/0/2 {

unit 0 {

family ethernet-switching;

}

}

...

ge-0/0/47 {

unit 0 {

family ethernet-switching;

}

}

vlan {

unit 0 {

family inet {

dhcp;

}

}

}

}

snmp {

community autoconfig {

authorization read-only;

}

}

vlans {

default {

l3-interface vlan.0;

}

}