Day Zero Configuration
The initial or day 0 configuration of a VNF is based on the VM type. A VNF administrator configures the initial template for each VM type at the time of VNF deployment. The same configuration template is applied to all deployed and new VMs of that VM type. The template is processed at the time of individual VM deployment. The day 0 configuration continues to persists, so that all initial deployment, healing and scaling of VMs have the same day 0 template.
Some of the day 0 configuration tasks include bringing up the interface, managing the network, support for static or dynamic IP (DHCP, IPAM), SSH keys, and NetConf enabled configuration support on VNF.
Note |
ESC does not support day 0 configuration of interfaces added during service update. In case of recovery for day 0 configuration, all the interfaces with Network Interface Card IDs will be configured. |
Day Zero in the configuration data model
The day 0 configuration file can be specified in different ways in the data model, but you can use only one of the options at a time.
-
<file> url </file>—The url specifies a file on the ESC VM file system or file hosted on report http server. ESC downloads the file specified by the URL. This file is used as a template to replace the tokens specified in this template with the values specified in the variables section. This template is used to generate the day 0 configuration.
-
<data> inline config content </data>—Specifies URL for the template. This allows the use of inline text as the template.
-
<encrypted_data> inline config content</encrypted_data>—The inline configuration content will be encrypted based on the data.
-
<file_locators> list of file locators </file_locators>—Similar to file, a file_locator defines file to download from a remote server with basic authentication (if required).
Note
The <file_locators> is deprecated in ESC Release 4.0.
-
<file_locator_name> deployment defined file_locator </file_locator_name>—Similar to file, the file_locator_name is used to download the file from a remote server with basic authentication (if required).
Day 0 configuration is defined in the datamodel under the config_data tag. Each user data and the configuration drive file is defined under the configuration tag. The contents are in the form of a template. ESC processes the template through the Apache Velocity Template Engine before passing to the VM.
The config_data tag is defined for each vm_group. The same configuration template is applied to all VMs in the vm_group. The template file is retrieved and stored at deployment initialization. Template processing is applied at time of VM deployment. The content of the config file can be retrieved from the file or data .
<file> url </file>
<data> inline config content </data>
A destination name is assigned to the config by <dst>. User Data is a treated as a special case with <dst>--user-data</dst>.
A sample config data model,
<config_data>
<configuration>
<file>file://cisco/userdata_file.txt</file>
<dst>--user-data</dst>
<variable>
<name>CUSTOM_VARIABLE_FOR_USERDATA</name>
<val>SOME_VALUE_XXX</val>
</variable>
</configuration>
<configuration>
<file>file://cisco/config.sh</file>
<dst>config.sh</dst>
<variable>
<name>CUSTOM_VARIABLE_FOR_CONFIG</name>
<val>SOME_VALUE_XXX</val>
</variable>
</configuration>
</config_data>
Custom variable can be specified in the variables tag within the configuration. Zero or more variables can be included in each configuration. Each variable can have multiple values. Multiple values are only useful when creating more than one VM per vm_group. Also, when performing scale-in and scale-out, additional VMs can be added and removed from the VM group.
Note |
Note the following while providing multiple values for the variable tag.
|
The contents of <file> are a template that is processed by the Velocity Template Engine. ESC populates a set of variables for each interface before processing the configuration template:
NICID_n_IP_ALLOCATION_TYPE |
string containing FIXED | DHCP |
NICID_n_NETWORK_ID |
string containing neutron network uuid |
NICID_n_IP_ADDRESS |
ipv4 or ipv6 address |
NICID_n_MAC_ADDRESS |
string |
NICID_n_GATEWAY |
ipv4 or ipv6 gateway address |
NICID_n_CIDR_ADDRESS |
ipv4 or ipv6 cidr prefix address |
NICID_n_CIDR_PREFIX |
integer with prefix-length |
NICID_n_NETMASK |
If an ipv4 CIDR address and prefix are present, ESC will automatically calculate and populate the netmask variable. This is not substituted in the case of an IPv6 address and should not be used. |
NICID_n_ANYCAST_ADDRESS |
string with ipv4 or ipv6 |
NICID_n_IPV4_OCTETS |
string with last 2 octets of ip address, such as 16.66, specific to CloudVPN |
Where n is the interface number from the data model, for example, 0, 1, 2, 3
Note |
The interface number, n starts with 0 for OpenStack, and 1 for VMware. |
Example
NICID_0_IP_ALLOCATION_TYPE: FIXED
NICID_0_NETWORK_ID: 9f8d9a97-d873-4a1c-8e95-1a123686f038
NICID_0_IP_ADDRESS: 2a00:c31:7fe2:1d:0:0:1:1000
NICID_0_MAC_ADDRESS: null
NICID_0_GATEWAY: 2a00:c31:7fe2:1d::1
NICID_0_CIDR_ADDRESS: 2a00:c31:7fe2:1d::
NICID_0_CIDR_PREFIX: 64
NICID_0_ANYCAST_ADDRESS: null
NICID_0_IPV4_OCTETS: 16.0
NICID_1_IP_ALLOCATION_TYPE: DHCP
NICID_1_NETWORK_ID: 0c468d8e-2385-4641-b1db-9080c170cb1a
NICID_1_IP_ADDRESS: 6.0.0.2
NICID_1_MAC_ADDRESS: null
NICID_1_GATEWAY: 6.0.0.1
NICID_1_CIDR_ADDRESS: 6.0.0.0
NICID_1_CIDR_PREFIX: 24
NICID_1_ANYCAST_ADDRESS: null
NICID_1_NETMASK: 255.255.255.0
By default, ESC substitutes the $ variable in the day 0 configuration file with the actual value during deployment. You can enable or disable the $ variable substitution for each configuration file.
Add the following field to the configuration data model:
<template_engine>VELOCITY | NONE</template_engine> field to configuration
where,
-
VELOCITY enables variable substitution.
-
NONE disables variable substitution.
If no value is set the default option is VELOCITY, and the $ variable substitution takes place. When set to NONE, the $ variable substitution does not take place.
You must follow these tips while processing the template through the velocity template engine.
-
To escape dollar sign in the template insert,
then replace the variable with#set ( $DS = "$" )
passwd: ${DS}1${DS}h1VxC40U${DS}uf2qLUwGTjHgZplkP78xA
-
To escape a block in the template, insert #[[ and #]]. For example,
#[[ passwd: $1$h1VxC40U$uf2qLUwGTjHgZplkP78xA ]]#
To fetch external configuration files, a file locator is added to the day 0 configuration. The file locator contains a reference to the file server, and the relative path to the file to be downloaded.
Note |
The file locator attribute is defined at the deployment level, that is, directly under the deployment container instead of policy actions and day 0 configuration sections. For updated data model see Fetching Files From Remote Server. |
Example of day 0 configuration with a file locator:
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant>
<name>sample-tenant</name>
<deployments>
<deployment>
<name>sample-deployment</name>
<vm_group>
<name>sample-vm-group</name>
<config_data>
<!-- exisiting configuration example - remains valid -->
<configuration>
<file>file:///cisco/config.sh</file>
<dst>config.sh</dst>
</configuration>
<!-- new configuration including use of file locators -->
<configuration>
<dst>ASA_config_0</dst>
<file_locators>
<file_locator>
<name>configlocator-1</name>
<!-- unique name -->
<remote_file>
<file_server_id>server-1</file_server_id>
<remote_path>/share/users/configureScript.sh</remote_path>
<!-- optional user specified local silo directory -->
<local_target>day0/configureScript.sh</local_target>
<!-- persistence is an optional parameter -->
<persistence>FETCH_ALWAYS</persistence>
<!-- properties in the file_locator are only used for
fetching the file not for running scripts -->
<properties>
<property>
<!-- the property name "configuration_file" with value "true" indictates this is the
script to be used just as using the <file> member case of the configuration -->
<name>configuration_file</name>
<value>true</value>
</property>
<property>
<name>server_timeout</name>
<value>120</value>
<!-- timeout value in seconds, overrides the file_server property -->
</property>
</properties>
</remote_file>
<!-- checksum is an optional parameter.
The following algorithms are supported: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 -->
<checksum>SHA256 (configureScript.sh) = dd526bb2c0711238ec2649c4b91598fb9a6cf1d2cb8559c337c5f3dd5ea1769e</checksum>
</file_locator>
<file_locator>
<name>configlocator-2</name>
<remote_file>
<file_server_id>server-2</file_server_id>
<remote_path>/secure/requiredData.txt</remote_path>
<local_target>day0/requiredData.txt</local_target>
<persistence>FETCH_ALWAYS</persistence>
<properties />
</remote_file>
</file_locator>
</file_locators>
</configuration>
</config_data>
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>
</esc_datamodel>
The file locator parameters include:
-
name—used as the key and identifier for a file locator.
-
local_file or remote_file—choice of file location. Local file is used to specify a file existing on the ESC VM file system already. The remote_file is used to specify a file to fetch from a remote server.
-
file_server_id—id of the File Server object to fetch the file from.
-
remote_path—path of the file from the base_url defined in the file server object.
-
local_target—optional local relative directory to save the file.
-
properties—name-value pairs of of information that may be required.
-
persistence—options for file storage. Values include CACHE, FETCH_ALWAYS and FETCH_MISSING (default).
-
-
checksum—optional BSD style checksum value to use to validate the transferred file's validity.
For more information, see Fetching Files From Remote Server.
To encrypt the files see, "Encrypting Configuration Data".