Automatic Configuration Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Contents

Overview·· 1

Technical background· 1

Benefits· 1

Implementation of automatic configuration· 1

Text-type configuration files· 1

Python script file· 2

TCL script file· 2

Implementation of automatic configuration· 3

Implementation of USB-based automatic configuration· 3

Use the index file in ini format and the device configuration file for automatic configuration. 4

Automatic configuration using only .cfg configuration files· 7

Implementation of server-based automatic configuration· 8

Typical networking· 8

Operating mechanism·· 8

Fundamentals· 8

Automatic server configuration (in IPv4 environment). 10

Automatic server configuration (in IPv6 environment) 16

Typical network applications· 22

https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718039 (on switches) 22

https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718046 (on switches) 23

‌https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718039 (on routers) 24

https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718039 (on routers) 25

 

Overview

Technical background

After hardware installation of network devices, administrators must go to the installation site to configure the software. This mode is suitable for small-scale installations and allows a certain probability of human error. However, for larger projects with many sites and numerous devices, manual configuration is time-consuming and labor-intensive, leading to high installation and implementation costs. Therefore, a solution that supports automatic configuration of devices after hardware installation is needed.

Benefits

Automatic configuration refers to a function that automatically obtains and executes a configuration file when a device with no configuration is powered on. After the device runs the automatic configuration function, it can obtain the configuration file from a USB disk or a file server and automatically mount the configuration file, enabling remote deployment of access network devices, thus reducing manpower costs and improving deployment efficiency.

Implementation of automatic configuration

Devices with no configuration can achieve automatic configuration by executing text-type configuration files with a .cfg extension, Python scripts, or TCL scripts located on a file server.

Text-type configuration files

Text-type configuration files with the .cfg suffix are used to save configurations.

The text-type configuration files include three types: specific configuration files, partial or complete shared configuration files, and the default configuration file (device.cfg). Details are shown in Table 1.

Table 1 Configuration files of different text types.

Configuration file	Applicable devices	Filename requirements	Supported file servers
Specific configuration files	Devices with specific configuration requirements	Configuration file name: .cfg For ease of file identification, try not to use configuration file names that contain spaces.	·     HTTP server ·     TFTP server
Partially or entirely shared configuration files	Devices with overlapping requirements or with the same requirements	Configuration file name: .cfg The configuration file name can be any filename.	·     HTTP server ·     TFTP server
Default configuration file, containing the common profile for general device startup	Devices without special configuration requirements	Fixed configuration file name: .device.cfg	TFTP server

 

Python script file

The ComwareV7 system offers an expanded Python API, allowing automatic device configuration through executing Python API scripts. These Python script files are created by the administrator and stored on a file server (either HTTP server or TFTP server) for devices to access, with the .py suffix.

The extended Python API supports the execution of Comware configuration commands in two ways:

channel

This method is used to execute Comware system commands and create channel objects. The script format is channel (command = ''). command indicates the command to be executed, with the default being empty. Channel commands start from the user view, and if the view is not specified in the command. Directly inputting the command means it is executed in the user view. To execute commands in other views, first input the command to enter the view, followed by the specific configuration command. Separate multiple commands with a space and a semicolon, such as system-view; display interface brief | include UP.

CLI

The CLI method is used to execute Comware system commands and create a CLI object. The script format is CLI(command='', do_print=True).

·     command: Indicates the command to be deployed, defaulting to empty. Commands are issued starting from the user view. If no view is specified, the command executes in the user view. To execute commands in other views, enter the command to switch views first, then the specific configuration command. Separate multiple commands with a space and a semicolon, e.g., system-view ; local-user test class manage.

·     do_print: Determines whether to output the execution result. True means the result is printed; False means it is not. The default is True.

Administrators can achieve a variety of functions through Python scripts, such as by identifying device models, downloading corresponding configuration files, and automatically saving configuration files to the file server, etc. This white paper only introduces the workflow of automatic configuration and does not include how to edit Python scripts.

TCL script file

The Comware V7 system comes embedded with a Tool Command Language (TCL) parser, allowing the execution of TCL script commands for device configuration via TCL scripts. TCL script files are created by the administrator and stored on the file server (HTTP or TFTP server) for device retrieval, with a .tcl suffix. The TCL script files contain executable Comware (CMW) commands for the device. For example:

system-view

telnet server enable

local-user user

password simple abcabc

service-type telnet

quit

user-interface vty 0 63

authentication-mode scheme

user-role network-admin

quit

 

interface gigabitethernet 1/0/1

port link-mode route

ip address dhcp-alloc

return

Implementation of automatic configuration

When a device enters the automatic configuration process after it starts up with initial settings, it first attempts to load configuration from a USB disk. If the USB-based configuration fails, it then attempts to complete the auto-configuration via the server method.

·     USB-based automatic configuration: The administrator saves the configuration file on a USB disk. The device can automatically retrieve and execute this file from the USB interface upon start-up, thus enabling an automatic configuration function.

·     Server-based automatic configuration: In a network where a file server, DHCP server or DNS server exists, when an empty device is powered on, the device will automatically run the DHCP Client service. It will get the URL address of the configuration file or the TFTP server IP, TFTP server name and filename from the DHCP Server. Then, it will download the configuration file from the file server, mount it, and start automatic configuration.

In different implementation methods, the location for saving the configuration file and its application scenarios are shown as indicated in Table 2.

Table 2 Implementation of automatic configuration

Implementation	Location of the configuration file storage	Application scenario
Server-based automatic configuration	File server	The network scale is large, and the devices are relatively dispersed.
USB-based automatic configuration	USB disk	·     Small-scale network: The devices are relatively concentrated in location, and there is a lack of extra equipment to serve as a file server. ·     Large-scale network: Only a small number of device configurations need to be updated. Only devices that have USB interfaces support USB-based automatic configuration.

 

Implementation of USB-based automatic configuration

After the device starts with the initial configuration and enters the automatic configuration process, it first attempts to carry out the auto-configuration through a USB disk. The USB disk auto-configuration supports the following two methods:

·     Use the configuration file specified by the index file and the index file in ini format for automatic configuration.

·     Only use .cfg format configuration files for automatic configuration.

Use the index file in ini format and the device configuration file for automatic configuration.

Format of the index file

When using an index file in ini format for automatic configuration, the index file must be named smart_config.ini. The administrator needs to save the index file named smart_config.ini and the file that configures the device (such as a configuration file in .cfg format) to the USB disk. The meanings of each field in the index file are as shown in Table 3.

Table 3 Fields in the ini file

Field	Description
BEGIN LSW	Required. This is the start mark, and this field cannot be modified.
GLOBAL CONFIG	Required. This is the global configuration start mark, which cannot be modified.
TIMESN	Required. This is a marking for the time of data change, in string format, with a length ranging from 1 to 16, and cannot include spaces. Suggested format: YearMonthDay.HourMinuteSecond. For example, you can set TIMESN=20110628.080910 to represent 08:09:10 28 June 2011. Each TIMESN corresponds to a device being upgraded. During the USB disk auto-configuration process, the device records this TIMESN before restarting (or after the upgrade is complete if no restart is required). This TIMESN cannot be used for the next upgrade. If the upgrade fails due to certain reasons after the device restarts, you need to modify the TIMESN and then perform USB disk auto-configuration again.
AUTODELFILE	Optional. Indicates whether it allows automatic deletion of original system software after upgrading. ·     AUTODELFILE=YES: Delete. ·     AUTODELFILE=NO: Do not delete. By default, AUTODELFILE is set to NO. If this field is non-existent, empty, or holds an invalid value, it indicates the default state. There are two types of AUTODELFILE fields: global fields and individual device fields. The fields located in the [GLOBAL CONFIG] section are global fields, while those located in the [DEVICE DESCRIPTION] section pertain to individual devices. If a single device has set the value of this field to YES or NO, then the settings for this single device take effect. If a single device has not set this field or if this field is empty, then the global settings take effect.
AUTOOVERWRITEFILE	Optional. It indicates whether to allow the replacement of the same-name configuration file on the device when copying the configuration file from the USB disk to the device. ·     AUTOOVERWRITEFILE =YES: Overwrite ·     AUTOOVERWRITEFILE =NO: Do not overwrite By default, AUTOOVERWRITEFILE is set to YES. If this field doesn't exist, is empty, or has an invalid value, all scenarios indicate the default situation.
ACTIVEMODE	Optional. It indicates the file activation method after the file is copied. ·     DEFAULT: Activate according to the default mode of each file. Specifically, the default activation method for system software is to restart the device. For configuration files and patch files, the default activation method is without restarting the device, but activating online. ·     REBOOT: Activated by restarting the device. By default, the ACTIVEMODE is set to DEFAULT. If this field does not exist, is empty, or contains an invalid value, it is considered as the default setting. There are two types of ACTIVEMODE fields: global fields and individual device fields. The global field is located inside the [GLOBAL CONFIG] field, and the individual device field is inside the [DEVICE DESCRIPTION]. If a single device is set to the value of this field as DEFAULT or REBOOT, the settings of that device take effect. If the field value is not set or is empty on the device, then the global settings take effect.
DEVICE DESCRIPTION	Required.. Start mark for single device file information description. Each field under the DEVICE DESCRIPTION section, representing information of a single device, cannot be duplicated. Otherwise, it will not match this DEVICE. DEVICE matches in the order defined in the file from top to bottom. After matching a group, it will not match any other DEVICE.
OPTION	Optional. This is a validity marking for a single device file information, indicating whether the device file information is valid. ·     Translation: OPTION=OK: Valid ·     Option=NOK: Invalid, the file information of this single device is not required to be judged. By default, the OPTION is set to OK. If this field does not exist, is empty, or contains an invalid value, all are considered as default situations.
SN	Optional. Device serial number. If SN=DEFAULT, it means no match is needed for the ESN serial number, otherwise, it should match the SN with the device. By default, ESN is DEFAULT. If this field does not exist or is empty, it signifies it is the default situation.	The devices due for an upgrade will match top-down in the index file according to DEVICE, with the following priority: MAC > SN > DEVICETYPE > DEFAULT. Once a match is found, the file will be mounted based on the matched DEVICE information. If a mistake occurs during this process, matching won't be attempted again, only an error report will be output.
MAC	Optional. Device MAC address, format: XXXX-XXXX-XXXX, where X is a hexadecimal number. If MAC=DEFAULT, it means no matching MAC address is required; otherwise, the device's MAC address must match. By default, the MAC is DEFAULT. If this field does not exist or is empty, it indicates the default situation.
DEVICETYPE	This is an optional field. It indicates matching with the device type, such as S12700. If DEVICETYPE=DEFAULT, it means there is no match with the device type. Otherwise, it needs to match the device type. By default, the DEVICE TYPE is set to DEFAULT. If this field does not exist OR is empty, it indicates the default setting.
DIRECTORY	Optional. The directory where the file is stored on the USB disk. When this field is empty or does not exist, it indicates that the file is located in the root directory of the USB disk. The source text, "DIRECTORY=/abc, indicates that the file is located under the abc folder on the USB disk," translates to: The file is located under the abc folder on the USB disk, as indicated by "DIRECTORY=/abc". By default, the DIRECTORY field is empty. The format of the file directory in the index file must be consistent with the device's file system, and the file directory in the index file needs to meet the following requirements: ·     The directory depth must be less than or equal to 4 levels. Directories must start with "/", with each level separated by "/" but not ending with "/". For example, /abc/test is a valid directory, while /abc/test/ is an invalid one. ·     The string length range for each level of the directory is 1-15. ·     The characters used in directory names cannot be spaces, "~", "*", "/", "\", ":", "'", """, "<", ">", "|", "?", "[", "]", "%" and so on. Directory names are not case-sensitive.
SYSTEM-IPE=	Optional. The system version name, with a suffix of ".ipe".
SYSTEM-BOOT-BIN=	Optional. The Boot software (S/W) package name, with a ".bin" suffix.
SYSTEM-SYSTEM-BIN=	Optional. The name of the system software package, with a ".bin" suffix.
SYSTEM-FEATURE-BIN=	Optional. The feature software package name, with a suffix of ".bin".
SYSTEM-PATCH-BIN=	Optional. The system software name, with a ".bin" suffix.
SYSTEM-CONFIG	Optional. The configuration file's name, with a suffix of ".cfg".
END LSW	Required. End of file marking.

 

Automatic configuration process.

The process of automatic configuration through an index file in ini format is as follows:

1.     The device detected that the USB flash disk is in place.

2.     The device checks if the "smart_config.ini" index file exists in the USB disk.

¡     If the "smart_config.ini" index file exists, proceed to step 3.

¡     If the "smart_config.ini" index file does not exist, the USB flash disk automatic configuration process ends.

3.     The device checks the legality of the "smart_config.ini" index file format.

¡     If it is legal, proceed to step 4.

¡     If the USB flash disk is illegal, automatic configuration failure occurs, the process terminates, and an error report is generated in the USB disk.

4.     The device compares the data change time marking specified in the "smart_config.ini" index file to the last recorded time marking of USB automatic configuration in the device.

¡     If they are not the same, proceed to step 5.

¡     If identical, the USB disk suffers an automatic configuration failure (CONF), ending the process and generating an error report in the U (U) drive.

5.     The device, following the description information in the "smart_config.ini" index file, retrieves the configuration file from the USB disk, and saves it to the default storage media.

¡     If the configuration file is successfully accessed, proceed to step 6.

¡     If the acquisition of the configuration file fails, the USB disk will automatically have a configuration failure (CONF), ending the process and generating an error report in the USB disk.

6.     The device determines whether a reboot is necessary for activation based on the received configuration file or the specified activation method.

¡     If a reboot is not required, activate the corresponding file online, then proceed to step 7.

¡     If a restart is necessary, the device will set the corresponding file as the next startup file. After the automatic restart is successful, proceed to step 7.

7.     The USB disk has been successfully auto-configured, ending the process. Please remove the USB disk from the device.

Automatic configuration using only .cfg configuration files

When automatically configuring with a .cfg format configuration file, the administrator needs to save the .cfg format configuration file to a USB disk. The process for automatically configuring with a .cfg format configuration file is as follows:

1.     The device has detected the presence of a USB disk and is checking for the existence of a .cfg format configuration file in the USB disk.

¡     If it exists, proceed to step 2.

¡     If it does not exist, the USB (U) drive's automatic configuration stream process comes to an end.

2.     After the device obtains the configuration file from the U (U) disk, it compares whether the contents of this configuration file are the same as the current main configuration file on the device.

¡     If the content of the file is identical, the device will directly use the current primary configuration file, without using the configuration file on the USB disk.

¡     If the content of the file is different, the device will copy the configuration file from the U (U) drive to the local storage, and execute step (3).

When duplicate configuration file names exist in the device's local storage, the following processing method is applied based on the properties of the local configuration file:

-     If the local configuration file with the same name is the current primary configuration file, the device will save this file under a new name, "original name_bak.cfg".

-     If the local configuration file with the same name is not the current primary configuration file, the device will directly use the configuration file from the USB disk to overwrite the local file with the same name.

The device executes the U configuration file from the USB disk.

¡     If the device successfully executes the configuration file from the USB disk, it automatically sets the copied configuration file as the primary configuration file for the next startup.

¡     If a device fails to execute a command in the USB flash disk's configuration file, it will ignore all configurations in that file and use the previously saved configuration file on the device. If the device did not save a configuration file previously, it would start with the initial configuration.

Implementation of server-based automatic configuration

Typical networking

The typical network environment for server automatic configuration is shown in Figure 1. The device needs to implement the server automatic configuration function with the cooperation of the DHCP server, file server (TFTP server or HTTP server), and DNS server.

Figure 1 Network diagram

 

·     DHCP server: When automatic configuration begins to run, the device awaiting configuration acts as a DHCP client, requesting network profile from the DHCP server. On the DHCP server, you need to set up an address pool (for the allocation of interface IP addresses to devices awaiting configuration), gateway address for the device to be configured, and Option parameters (which include the IP address of the file server that the DHCP server needs to allocate to the DHCP client, the filename of the configuration file that needs to be mounted, and other information).

·     DHCP relay: When the device waiting for configuration and the DHCP server are located in different network segments, it is necessary to set up the DHCP relay to enable message exchanges between the device and the server.

·     File server: Saves the configuration files or script files required by the device. It can be a TFTP or HTTP type of server.

·     DNS server: Provides the mapping relationships between domain names and IP addresses. Devices that execute automatic configurations can resolve the file server's domain name into an IP address via the DNS server, making it convenient to access the necessary files from the file server.

Operating mechanism

Fundamentals

As a DHCP client, the device to be configured periodically sends DHCP requests to the DHCP server to obtain configuration information. Then, the DHCP server sends DHCP replies to the device to be configured. According to the configuration information carried in the received DHCP reply messages, the device obtains a configuration file from the specified file server and executes it to complete automatic configuration.

The file types supported by the automatic server configuration include configuration files and script files. As shown in Figure 2, administrators can configure the DHCP server according to different configuration requirements, enabling devices to be configured automatically based on the profile provided by the DHCP server. The details are as follows (issuing script files and configuration files are implemented in a similar way, taking issuing configuration files as an example below):

·     If the administrator assigns a specific configuration file to each device, it is necessary to configure a static binding relationship on the DHCP server, assigning a specific IP address and filename to each device. Since only one configuration file command can be configured in one address pool, you can configure only one static binding relationship in each address pool view on the DHCP server.

·     If an administrator allocates the same configuration file to some devices within a local area network (LAN), a static binding relationship can be set on the DHCP server for devices using the shared configuration file. This includes specifying the file server and shared filename. At this point, these static binding relationships need to be configured in the same DHCP IP address pool. Alternatively, the administrator can use dynamic IP address allocation, divide a suitable dynamic address section, and assign IP addresses for these devices while specifying the file server and shared filename.

·     If the administrator allocates the same configuration file to all devices within the local area network (LAN), a method for dynamically allocating IP addresses needs to be set up on the DHCP server. While dynamically allocating IP addresses to devices, distribute the shared filename of the entire configuration file. If this method is used, the shared configuration file can only contain configurations common to these devices, and configurations unique to each device needs to be completed in other ways (for example, the administrator manually configures on the device after logging in using Telnet).

Figure 2 Configuration of DHCP servers in different scenarios.

 

 

Automatic server configuration (in IPv4 environment).

Workflow

After the device awaiting configuration is powered on and self-check is successful, it checks if a configuration file exists. If not, it enters the automatic configuration process. Then it checks if autocfg.py, autocfg.tcl, or autocfg.cfg configuration files exist in the root directory of the storage media.

·     For the autocfg.py script file, the device executes Comware commands within the Python script file for automatic configuration or downloads the configuration file from the path provided within the Python script file, and then executes the commands within this configuration file for automatic configuration.

·     The device executes Comware commands in the autocfg.tcl script file for automatic configuration.

·     For the autocfg.cfg configuration file, the device automatically configures by executing Comware commands in the file.

If the aforementioned file does not exist, proceed with the server automatic configuration process as shown in Figure 3.

Figure 3 Workflow of server-based automatic configuration

 

Message exchange

If the file server is an HTTP server, during the server-based automatic configuration, the message interaction is as shown in Figure 4.

If the file server is a TFTP server, the message interaction in the server-based automatic configuration is as shown in Figure 5.

Figure 4 Message interaction during server-based automatic configuration (HTTP)

 

Figure 5 Message interaction (TFTP) during server-based automatic configuration

 

Operating process

After the device to be configured enters the automatic configuration process of the server, the running process is as follows:

1.     The device awaiting configuration selects the interface to start the DHCP client function in the following order. Different devices support different interface types; refer to the actual device specifications.

a.     If there is a management Ethernet interface in the UP link state, it should be selected as a priority.

b.     If there is no management Ethernet interface in the UP link state, but there is a layer 2 Ethernet interface in the UP link state, then select the VLAN interface corresponding to the default VLAN.

c.     If there is no secondary Ethernet interface in the UP link state, select the tertiary Ethernet interface in the UP link state in the order of interface type dictionary sequence and interface number from small to large.

d.     If there is no layer 3 Ethernet interface in the UP link state, the process of automatic server interface selection will begin 30 seconds later.

e.     If there is no interface available to initiate the DHCP client function, the device will repeatedly execute the steps a to d until the user terminates the execution of steps a to d using the shortcut key <Ctrl+C> or <Ctrl+D>.

It is suggested that the administrator connects the device's management Ethernet interface to the network, in order to quickly select the interface starting the DHCP client function, thereby accelerating server-based automatic configuration.

2.     After selecting the interface to enable the DHCP client function, this interface sends DHCP request messages in a broadcast method.

3.     Upon receiving a DHCP response packet from the DHCP server, the device awaiting configuration processes various information. This includes the IP address allocated to it by the DHCP server, the IP address of the file server, the default gateway, and other information such as DHCP options. Specific commonly used details within the DHCP response packet are shown as per Table 4.

Table 4 Common information found in DHCP response packets.

The content in the DHCP response message.	Description	Description
Option 66	Option for TFTP server name.	Used to specify the domain name of the TFTP server allocated for the client.
Option 67	Bootfile name, startup filename option.	Specify the boot filename to be allocated for the client. Example 1: boot.cfg Example 2: http://10.1.1.1/boot.cfg, where 10.1.1.1 is the IP address of the HTTP server.
Option 150	TFTP Server Address Option	Used to specify the address of the TFTP server allocated for the client.

 

4.     The device awaiting configuration retrieves the configuration file from the file server.

The file server can provide the configuration file in the manner indicated in Table 5.

Table 5 The file server provides the configuration file.

The method of providing the configuration file.	Example
Configuration file with a .cfg extension.	The configuration file with a .cfg suffix contains the device's profile. For example: # interface Vlan-interface1  ip address 192.168.1.84 255.255.255.0 #
Python script	Provide executable Comware system commands through Python scripts, or provide the downloading of configuration files with the .cfg suffix to the local system. ·     Execute Comware (CMW) system commands through a Python script. For example: #!usr/bin/python   import comware platformtools.CLI(‘system-view ;interface gigabitethernet 1/0/1 ;port link-mode route ;ip address dhcp-alloc ;return’) ·     Provide download of configuration files with a .cfg extension to the local system. In this case, ensure that the Python script includes commands to save the configuration file and restart the device; otherwise, the device will not execute the obtained configuration file. For example: #!usr/bin/python import platformtools   platformtools.Transfer('tftp', '192.168.1.26', 'main.cfg', 'flash:/main.cfg')
Tcl script	The Tcl script includes executable commands for the Comware system. For instance: return system-view telnet server enable local-user user password simple abcabc service-type telnet quit user-interface vty 0 63 authentication-mode scheme user-role network-admin quit   interface gigabitethernet 1/0/1 port link-mode route ip address dhcp-alloc return

 

When the type of file server in the network varies, the method for the device to acquire the configuration file changes accordingly.

When the file server is a TFTP server, the steps for the device waiting to be configured to obtain the configuration file are as follows:

a.     The device awaiting configuration retrieves the filename of the configuration file from the response message transmitted by the DHCP server.

b.     The device waiting to be configured sends a read request message to the TFTP server in unicast mode, asking to obtain the configuration file corresponding to the filename in the steps. The source IP of this message is the IP address that the DHCP server allocated to the device that needs to be configured, and the destination IP is the IP address of the TFTP server. If the device gets the domain name of the TFTP server from the DHCP response message, it will pass the DNS server to resolve the domain name of the TFTP server into its IP address.

c.     If the DHCP server does not transmit a configuration file name in the response package or the filename is invalid (for example, aa.txt), the device awaiting configuration will automatically try to acquire a file named "network.cfg", which is the host name file. This file contains the correlation between the host name (configuration file name) and the device's IP address (for example, ip host host1 101.101.101.101 indicates that the device with the IP address of 101.101.101.101 uses the configuration file named "host1"). The device awaiting configuration obtains the configuration file name based on the correlation between the host name and the IP address and then executes step b. If the device awaiting configuration fails to obtain the configuration file name in this way, it will automatically try to obtain the default configuration file "device.cfg."

When the file server is an HTTP server, the following steps are taken to obtain the configuration file for the device to be configured:

a.     The device awaiting configuration retrieves the filename of the configuration file from the response packet transmitted by the DHCP server.

b.     The device waiting to be configured sends a TCP message to the HTTP server via unicast and establishes a TCP connection. The source IP of this message is the IP address allocated to the device-to-be-configured by the DHCP server, and the destination IP is the IP address of the HTTP server. If the device obtains the domain name of the HTTP server from the DHCP response message, the domain name is resolved to the IP address of the HTTP server through the DNS server.

c.     The device awaiting configuration transmits a get request to the HTTP server via TCP connection. This request includes the filename of the configuration file that the device aims to retrieve.

d.     If the DHCP server does not transmit a configuration filename in the response message, the device waiting for configuration will automatically attempt to obtain the default configuration file "device.cfg".

5.     The device awaiting configuration will execute the configuration file.

¡     After the device waiting to be configured successfully obtains the configuration file, it automatically executes the commands in the configuration file. Once the execution of the configuration file is successful, the entire server's automatic configuration process is concluded.

¡     If the device to be configured fails to obtain the configuration file in step 4, it will automatically attempt to obtain the default configuration file, device.cfg. If it fails to obtain the file, the automatic configuration will fail, and the device will continue to attempt auto-configuration. Users can wait for the number of attempts to reach the upper limit, and the device will automatically end auto-configuration. Alternatively, follow the prompt and use <Ctrl+C> or <Ctrl+D> shortcut keys to manually terminate the auto-configuration. After the auto-configuration fails and ends, the device will start with the initial configuration.

Automatic server configuration (in IPv6 environment)

Workflow

If the device waiting for configuration cannot obtain the IPv4 address, or cannot obtain the configuration file on the file server using the IPv4 address, it enters the automatic IPv6 server configuration process as shown in Figure 6.

Figure 6 Workflow of server-based automatic configuration

 

Message exchange

If the file server is an HTTP server, the message interaction in the server's automatic configuration workflow is shown in Figure 7.

If the file server is a Trivial File Transfer Protocol (TFTP) server, the interaction of messages in the server's automatic configuration workflow is illustrated in Figure 8.

Figure 7 Packet interaction (HTTP) during server-based automatic configuration

 

Figure 8 Packet interaction (TFTP) during server-based automatic configuration

 

Operating process

Once the device awaiting configuration enters the server's automatic configuration process, the operation proceeds as follows:

1.     Configure the device following the sequence below to select the interface that initiates the DHCPv6 client function. Different devices support different types of interfaces, please refer to the actual situation of the device.

a.     If there is a management Ethernet interface in link state UP, prioritize the selection of the management Ethernet interface.

b.     If there is no management Ethernet interface in the UP link state, but there is a Layer 2 Ethernet interface in the UP link state, select the VLAN interface corresponding to the default VLAN.

c.     If there are no second stratum Ethernet interfaces in the link state UP, select the third stratum Ethernet interfaces in the link state UP in order according to the dictionary order of the interface type and the ascending order of the interface number.

d.     If there are no Ethernet interfaces at stratum three with a link state of UP, then the server will begin the next automatic interface selection process 30 seconds later.

e.     If there is no interface available for initiating the DHCP client function, the device will repeatedly execute steps 1.a to 1.d until the user terminates the execution of steps 1.a to 1.d using either the Ctrl+C or Ctrl+D shortcut key.

It is recommended that the administrator connect the device's management Ethernet interface to the network. This enables the device to quickly select the interface for initiating DHCPv6 client function, speeding up server-based automatic configuration.

2.     Once the interface with the DHCPv6 client function is selected, it transmits Solicit messages in a multicast mode.

3.     Upon receiving the DHCPv6 response message transmitted by the DHCPv6 server, the device waiting for configuration contains the Option 59 (Boot File Uniform Resource Locator (URL), for example: http://[2001:DB8::461]/bootup.cfg. The DHCPv6 server delivers the profile information to the device waiting for configuration through Option 59.

4.     The device awaiting configuration retrieves and executes the configuration file from the file server.

The file server can provide configuration files in the manner shown in Table 6.

Table 6 Methods to provide configuration files

Method	Example
Configuration file with suffix.cfg	The configuration file with the suffix .cfg contains the device's profile. For example: # interface Vlan-interface1  ipv6 address 2002::1 64 #
Python script	Provide executable Comware (CMW) system commands through Python script, or offer downloading configuration files with .cfg suffix to the local system. ·     Execute commands of the Comware system using a Python script. For example: #!usr/bin/python   import comware comware.CLI(‘system-view ;interface gigabitethernet 1/0/1 ;port link-mode route ; ipv6 address dhcp-alloc rapid-commit option-group 1 ;return’) ·     Provide the download of the configuration file with the .cfg suffix to the local area. In this case, ensure that the Python script includes commands to save the configuration file and restart the device. Otherwise, the device will not execute the obtained configuration file. For example: #!usr/bin/python import platformtools   platformtools.Transfer('tftp', '2002::100', 'main.cfg', 'flash:/main.cfg')
Tcl script	The Tcl script contains executable Comware (CMW) system commands. For example: return system-view telnet server enable local-user user password simple abcabc service-type telnet quit user-interface vty 0 63 authentication-mode scheme user-role network-admin quit   interface gigabitethernet 1/0/1 port link-mode route ip address dhcp-alloc return

 

When the file server is a TFTP server, the steps to retrieve the configuration file by the device to be configured are as follows:

a.     The device awaiting configuration obtains the filename of the configuration file from the response message transmitted by the DHCPv6 server.

b.     The device awaiting configuration sends a Read request message to the TFTP server in unicast mode, requesting the configuration file corresponding to the filename provided in the steps. The source IPv6 of this message is the IPv6 address assigned to the device awaiting configuration by the DHCPv6 server, and the destination IPv6 is the IPv6 address of the TFTP server. If the device receives the domain name of the TFTP server from the DHCPv6 response message, it resolves the domain name of the TFTP server into the IPv6 address of the TFTP server through the DNS server.

c.     If the DHCPv6 server does not include a configuration file name in the response packet it sends, the device awaiting configuration will automatically try to acquire a file named 'network.cfg', that is, the host name file. This file contains the corresponding relationship between the host name (configuration file name) and the device IP address (for example, ipv6 host host1 1001::1001, which implies that the device with the IPv6 address of 1001::1001 uses a configuration file named "host1"). The device awaiting configuration will obtain the configuration file name based on the equivalent relationship between the host name and the device's IPv6 address, then it will execute step 5. If the device awaiting configuration cannot acquire the configuration file name in this manner, it will automatically attempt to obtain the default configuration file, 'device.cfg'.

When the file server is an HTTP server, the device retrieves the configuration file using the following steps:

a.     The device waiting for configuration obtains the filename of the configuration file from the response message transmitted by the DHCPv6 server.

b.     The device awaiting configuration transmits a TCP message to the HTTP server using unicast and establishes a TCP connection. The source IPv6 of this message is the IPv6 address allocated to the device by the DHCPv6 server, and the destination IPv6 is the HTTP server's IPv6 address. If the device obtains the HTTP server's domain name from the DHCPv6 response message, it passes through the DNS server to resolve the HTTP server's domain name into its IPv6 address.

c.     The device awaiting configuration transmits a Get request to the HTTP server via TCP connection. This request includes the name of the configuration file that the device wants to obtain.

d.     If the DHCP server does not transmit a configuration file name in the response message, the device awaiting configuration will automatically attempt to obtain the default configuration file "device.cfg".

5.     The device awaiting configuration will execute the configuration file.

¡     After the device to be configured successfully obtains the configuration file, it automatically executes the commands in the configuration file. Once the execution of the configuration file is successful, the entire server's automatic configuration process ends.

¡     If the device to be configured fails to obtain the configuration file in step 4, this attempt at automatic configuration will fail and the device will continue to attempt to configure itself automatically. Users can wait for the number of attempts to reach the upper limit at which point the device will automatically end the automatic configuration. Alternatively, based on the prompt information, users can manually terminate the automatic configuration by using the <Ctrl+C> or <Ctrl+D> shortcut keys. After the automatic configuration fails and ends, the device will start with the initial configuration.

Typical network applications

https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718039 (on switches)

As shown in Figure 9, there are two departments in a certain company: the marketing department and the research & development (R&D) department, both of which connect to the network via different gateway (GW) devices. It is required that Switch D, Switch E, Switch F, and Switch G, which are connected to the terminal host, execute the automatic configuration function. Upon startup, these devices will automatically obtain and execute the configuration file to meet the following requirements:

·     The network administrator can log in and control the device via Telnet.

·     When logging into a device, authentication is required, and the username and password used for devices in different departments must not be the same, providing security guarantee.

The specific network setup is as follows:

·     Switch A serves as a DHCP server, allocating IP addresses and other network configuration parameters to hosts in the Marketing and Research & Development (R&D) departments respectively.

·     Gateway Switch B and Switch C act as DHCP relay agents.

·     A configuration file is saved on a TFTP server running TFTP manager software.

Figure 9 Network diagram

 

https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718046 (on switches)

As shown in Figure 10, two new devices with blank configurations, Switch A and Switch B, are added to a network and connected to an existing device, Switch C. Switch A and Switch B communicate with the DHCP server and the HTTP server through Switch C.

The administrator stores the prepared Python script in the working directory of the HTTP server, ensuring that Switch A and Switch B can access the Python script. The device executes the Python script to meet the following requirements:

·     The network administrator can log in and control the device via Telnet.

·     Authentication is required for device login, to provide security assurance.

Figure 10 Network diagram

 

‌https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718039 (on routers)

As shown in Figure 11, a neighborhood needs to redeploy network access devices Router A, Router B, and Router C on each floor. The user hopes to mount the same configuration file on the new devices of each floor. Meanwhile, due to the large number of devices to be configured, to reduce labor costs and save deployment time, the user hopes the devices on each floor can achieve uniform automatic configuration. The administrator stores the configuration file in the working directory of the TFTP server to ensure Router A, Router B, and Router C can retrieve the needed files. Power on Router A, Router B, and Router C to achieve automatic configuration file loading through the server.

Figure 11 Network diagram

 

https://press.h3c.com/MaterialExpoDocumentLibrary/Comware V7 B75%E5%88%86%E6%94%AF/B75%E5%88%86%E6%94%AF%E8%8B%B1%E6%96%87/02-Fundamentals/11-Automatic Configuration/Automatic configuration.htm - _Toc157718039 (on routers)

As shown in Figure 12, a company needs to deploy the unconfigured devices including Router A, Router B, and Router C in branch offices 1, 2, and 3. Router A, Router B, and Router C are connected to device Router D across a transmission network. Router D, as the egress gateway for the company's headquarters, connects to the headquarters device Router E via a Layer 3 device.

The user hopes to mount different configuration files on Router A, Router B, and Router C. Also, to reduce onsite costs, the user wishes to implement remote automatic configuration for these devices. The administrator stores the configuration file in the working directory of the TFTP server, ensuring that Router A, Router B and Router C can access the files they need to mount. A DHCP relay is set up on the egress gateway, Router D, at the company headquarters, and a DHCP server is set up on Router E, a device located at the headquarters. The DHCP server provides network profile information for devices to be configured across network segments. Power on Router A, Router B and Router C to load the configuration file through server-based automatic configuration.

Figure 12 Network diagram