Generate Configuration Script

Accedian Networks has implemented a new feature on its network interface devices (NID) that provides the ability to create CLI scripts based on the unit’s configuration. This feature, called Generate Configuration Script, is available on all MetroNID and MetroNODE platforms, as of firmware version 6.2.

This article presents a technical overview of Generate Configuration Script and a description of its capabilities, followed by several examples to illustrate the concepts.

Generate Configuration Script

The configuration file that is normally exported from an Accedian unit is not editable. Furthermore, it is difficult to interpret, as it is not written in command-line interface (CLI) format. Its main purpose is to back up and restore a configuration.

The Generate Configuration Script feature is designed to export an editable configuration that is formatted to CLI commands. It can be edited (scripted) as needed, and the commands reloaded into a unit via the CLI.

Important considerations:

• Users are expected to be proficient with the CLI commands before using this feature for scripting.
• An exported CLI script should not be blindly reloaded into a different unit. User validation and sanitization of the CLI script is required.
• Before loading a script into a unit, you must ensure the hardware and firmware versions are compatible.

Feature Description

Generate Configuration Script is used to convert the unit’s configuration into CLI command format. The output can be displayed on the terminal or sent to a remote server.

Highlights:

• The command can be executed for the entire configuration, or for parts thereof.
• The file transfer option supports the following protocols: FTP, FTPS, HTTP, HTTPS, SFTP and TFTP.
• All parameters, even default values, are captured and exported.
• The exported commands can be edited and reloaded into a unit via the CLI.

What the feature does NOT do:

• It does not replace configuration export/import.
• It cannot be used to “clone” a device. Use CLI commands configuration export
• and configuration import for that purpose.
• It does not support importing a configuration script file. The script must be entered as CLI commands through the user interface.

New CLI Command

Overview

The CLI command and options associated with this functionality are under the “configuration” command group:

Two optional parameters are available:

export-to-server: This parameter is used to export the generated script to a remote server. If omitted, the script is displayed on the terminal.
module: The name of a specific module for which a configuration script will be generated. It is possible to specify multiple modules in a comma-separated list. Alternately, if no modules are specified, the script will be generated for the entire configuration.

Detailed Description

configuration generate-script
Syntax
configuration generate-script {module } {export-to-server [{ftp|ftps|http|https|sftp|tftp}://[:@]]}

Parameters

CLI Changes

“port” Command
A new parameter has been added to the “port” command: inst_idx=#
“inst_id” is used to associate an absolute index number to each physical port, rather than a name (port names are not absolute as they can be modified).

“monitor” Command
A new parameter has been added to the “monitor” command: inst_idx=#
“inst_id” is used to associate an absolute index number to each monitor, rather than a name (monitor names are not absolute as they can be modified).

Pound Character (#)

• The “#” character is used at the beginning of a line in the generated output script to mark comments in the script. These lines are not executable by the CLI and will be ignored by the system.
• The “#” character can also be used when scripting to add comment lines. However, it cannot be used to insert comments in the middle of a line. It must always be first character on a comments line.
• The “#” character is NOT supported in releases prior to 6.2.

Passwords Encryption
Any password that needs to appear in the generated CLI script is presented in a hashed format rather than clear text. This preserves that confidentiality of the credentials. In the script, passwords are marked as follows:

ENCRYPTED =< hashed key >

The system encrypts the following passwords

• User passwords
• EchoAgent password
• RADIUS secret
• TACACS+ secret
• SCP password (used in SAT reporting and history file transfer configuration)

Output Script Format

Script Header

The output script begins with a header section that identifies the source unit, as described below:

Example:

Configuration Modules
The output script is broken down into configuration modules. Each module starts with a comment line in the following format:
#< module-name >

Examples:
#port
#interface
#bandwidth-regulator
#y1564

Scripting Rules and Customization

Below is a list of items, listed by module, that require careful scrutiny when using the Generate Configuration Script. These modules should be closely examined with these items in mind, as they may require customization. Modules that do not appear here can generally be used as-is, but should be examined prior to being used.

“interface” Module

In the generated script, all interfaces are presented with the command interface add.

If an interface already exists in the target unit (e.g., default interfaces: Auto, Management), the user should change the command to interface edit.

“dns” Module

In the generated script, the parameter dhcp-hostname may have to be edited. In the default configuration, this parameter is set to the unit’s serial number.

In the target unit, if dhcp-hostname also uses the serial number as its value, this parameter should be deleted in the script. Alternatively, you can define a custom value.

“cos-profile” Module
In the generated script, the default pre-configured CoS profiles (8P0D-8P0D, 8P0D- 7P1D, 8P0D-6P2D and 8P0D-5P3D) are presented with the command cos-profile add.

If any of these default profiles exist in the target unit, the user should change the command to cos-profile edit or simply delete them from the script if no changes have been made to the default profiles.

“filter” Module
In the generated script, all filters, including the default pre-configured Layer-2 and IPv4 filters, are presented with the command filter add.

If any of the default filters exist in the target unit, the user should change the command to filter edit or simply delete them from the script if no changes have been made to the default configuration.

“l2pt” Module
In the generated script, all L2PT rules, including the default pre-configured rules, are presented with the command l2pt add.

If any of the default rules exist in the target unit, the user should change the command to l2pt edit or simply delete them from the script if no changes have been made to the default configuration.

“vcagent” Module
The vcagent (Vision Collect Agent) configuration command is captured in the generated script. However, this is just for your information.

These commands are to be used by Vision EMS only, and should NOT be scripted and entered manually by a user.

Configuration Examples

This section covers the following examples:

• Example 1: Generate a script for the entire configuration.
• Example 2: Generate a script for the NTP and SNMP modules (i.e., for part of a configuration).
• Example 3: Migrate the services configuration to another unit (i.e., generate a script for the service configuration module, edit it, and apply it to a new unit).

Example 1: Generate a Script for the Entire Configuration

The most elementary application is to generate a script for the entire configuration and display it on the terminal.

1. Open a CLI session and type the following command
   G274-0010: configuration generate-script

After typing the command, the screen may be idle for a few seconds while the system is generating the configuration script. The larger the configuration, the longer it takes to generate the script.

Once the script is ready, it is dumped on the terminal.

2. Scroll back in the terminal windows to view the beginning of any part of the output script:

When the script is large – which is generally the case when it is generated for the entire configuration – it is more convenient to send it to a remote server. The system supports several file transfer protocols.

3. For example, use a command similar to the following to send the configuration script to an FTP server:

G274-0010: configuration generate-script export-to-server ftp://test_user:test_password@192.168.201.2/my_config.txt Export done.

G274-0010:

Example 2: Generate a Script for the NTP and SNMP Modules

In this example, we will generate a script for two configuration modules: NTP and SNMP. This is a typical application where a portion of the configuration is extracted from a source unit and is loaded into another unit with minimum changes.

Requirements:

• A source unit.
• A target unit (same hardware and firmware version as the source).

Configuration Steps:

1. Generate the configuration script from the source unit.

2. Edit the script as needed.

3. Apply the revised script to the target unit.

Step 1: Generate the configuration script from the source unit

1. Open a CLI session and type the following command:
   G274-0010: configuration generate-script module ntp,snmp

The script that is generated on this specific test unit is as follows:

Step 2: Edit the script
Most of the script can be used as-is, and loaded into another unit. The only exception is the system-name parameter in the snmp module. The system name is unique to the specific unit (by default, its serial number). Therefore, it must be deleted from the script so that the source unit system name value does not overwrite the target unit system name when the script is loaded into the target unit.

2. Delete the system-name parameter and its value. The final script, after editing, will be as follows:
   

Step 3: Apply the revised script to a target unit

3. Open a CLI session in the target unit.

4. Copy and paste the script into the terminal emulator.

5. Use the generate-script command to validate that the operation has been successful:

The output is identical to what was extracted from the source unit, except for the SNMP system name (as expected).

Example 3: Migrate the Services Configuration to Another Unit

In this example, we will generate a script to capture the configuration of client services (traffic policies) and apply the configuration to another unit.

Requirements:

• A source unit.
• A target unit (same hardware and firmware version as the source).

Assumptions:

• The objective is to capture the configuration of the traffic policies.
• Only Layer-2 filters and Bandwidth Regulators are used in the policies.
• Other modules (CoS profiles, traffic shaping, etc.) are not used in this example.

In brief, the following needs to be captured in the script:

Configuration Steps:

1. Generate the configuration script from the source unit.
2. Edit the script as needed.

Step 1: Generate the configuration script from the source unit

1. Open a CLI session and type the following command:

G274-0010: configuration generate-script module policy,filter,bandwidth-regulator

The script will include three modules: policy, filter and bandwidth-regulator. However, they will not be presented in that order. The system always presents the modules in a logical order to respect the input precedence, if any. In this example, bandwidth-regulator and filter are presented before policy because that is the order in which the instances have to be created.

Below is the output script generated by this command:

(Note that the lines have been truncated on the right in this document for ease of reading.)

Step 2: Edit the script
The command used in Step 1 generates about 75 lines of script. The script can now be edited to modify any commands as needed or to delete any unnecessary commands.

“bandwidth-regulator” Module
This module can be retained as-is. All the information it contains is relevant.

“filter” Module
This module contains all Layer-2 and IPv4 filters, including the default filters that are pre-configured in the unit.

The only ones that are used in this configuration are Layer-2 filters CVLAN100, CVLAN200, SVLAN1000 and * default. Therefore, all other Layer-2 and IPv4 filters can be deleted.

Take note that * default is a pre-configured filter. It exists in the target unit configuration. Since it has not been modified, it can also be deleted.

“policy” Module
This module contains all the traffic policies. However, as stated above, only policies Traffic-A 1, Traffic-A 2, Traffic-A 7, Traffic-B 1, Traffic-B 7 are needed in this case. All the other policies can be deleted from the script.

The final script, after editing, will be as follows:

Terminal Emulator Settings

PuTTY
Increase Scrollback Buffer
By default, PuTTY buffers 200 lines of output, which is sometimes not enough. To increase this number:

• Open the PuTTY configuration menu.
• Go to Category: Window and increase Lines of scrollback to 20000.
• To make this change permanent, go to Category: Session and save the settings to your profile.

Scrollback Behavior
If you are scrolling back while the system is still producing output, the terminal jumps back to the bottom. This is the default behavior in PuTTY. To allow scrolling back while output is sent to the screen, change the configuration as follows:
• Go to Category: Window and disable the Reset scrollback on display activity option and enable Reset scrollback on keypress.
• To make this change permanent, go to Category: Session and save the settings to your profile.

Tera Term
Increase Scrollback Buffer
By default, Tera Term buffers 10000 lines of output, which should be sufficient in most circumstances. If this number needs to be increased, follow these steps:

• Open the Tera Term Setup > Windows menu.
• Next to Scroll buffer, increase the number of lines as needed.
• To make this change permanent, open the Setup > Save setup... menu and save the changes to the TERATERM.INI profile.