Bootstrap parameters are provided to the VM when the VM is created. They are used by the bootstrap process to configure various settings in the VM’s operating system.

On VMware vSphere, the bootstrap parameters are provided as vApp parameters. On OpenStack, the bootstrap parameters are provided as userdata in YAML format.

Configuration of bootstrap parameters is handled automatically by the SIMPL VM. This page is only relevant if you are deploying VMs manually or using an orchestrator other than the SIMPL VM, in consultation with your Metaswitch Customer Care Representative.

List of bootstrap parameters

Property Description Format and Example

hostname

Required.

The hostname of the server.

A string consisting of letters A-Z, a-z, digits 0-9, and hyphens (-). Maximum length is 27 characters.

Example: telco-mag-01

dns_servers

Required.

List of DNS servers.

For VMware vSphere, a comma-separated list of IPv4 addresses.

For OpenStack, a list of IPv4 addresses.

Example: 8.8.8.8,8.8.4.4

ntp_servers

Required.

List of NTP servers.

For VMware vSphere, a comma-separated list of IPv4 addresses or FQDNs.

For OpenStack, a list of IPv4 addresses or FQDNs.

Example: ntp1.telco.com,ntp2.telco.com

timezone

Optional.

The system time zone in POSIX format. Defaults to UTC.

tz database format (aka Olson format) time zone string. Run the command 'timedatectl list-timezones' on a CentOS system for a list of valid time zones.

Example: Pacific/Auckland

cds_addresses

Required.

The list of signaling addresses of Config Data Store (CDS) servers which will provide configuration for the cluster. CDS is provided by the TSN nodes. Refer to the Configuration section of the documentation for more information.

For VMware vSphere, a comma-separated list of IPv4 addresses.

For OpenStack, a list of IPv4 addresses.

Example: 192.168.10.10,192.168.10.11,192.168.10.12

cds_leader

Required.

This is only for TSN VMs. The IP address of the leader node of the CDS cluster. This should only be set in the "node heal" case, not when doing the initial deployment of a cluster.

A single IPv4 address.

Example: 192.168.10.10

deployment_id

Required.

An identifier for this deployment. A deployment consists of one or more sites, each of which consists of several clusters of nodes.

A string consisting of letters A-Z, a-z, digits 0-9, and hyphens (-). Maximum length is 15 characters.

Example: telco-deployment-01

site_id

Required.

A unique identifier (within the deployment) for this site.

A string of the form DC1 through DC32. The letters DC stand for "datacenter".

node_type_suffix

Required only when there are multiple clusters of the same type in the same site.

A suffix to distinguish between clusters of the same node type within a particular site. For example, when deploying the MaX product, a second TSN cluster may be required.

A string consisting of letters A-Z, a-z, and digits 0-9. Maximum length is 8 characters.

Example: cluster1

ssh_authorized_keys

Optional.

A list of SSH public keys. Machines configured with the corresponding private key will be allowed to access the node over SSH as the sentinel user. Supplying keys is optional and will not restrict password-based access. Supply only the public keys, never the private keys.

For VMware vSphere, a comma-separated list of SSH public key strings, including the ssh-rsa prefix and optional comment suffix.

For OpenStack, a list of SSH public key strings.

Example: ssh-rsa AAAA…​ user@monitoring-server.telco.com

instance_id_for_mdm

Optional.

An identifier for the VM to use when communicating with MDM, provided by the orchestrator. Supply this only for an MDM-managed deployment.

Free form string

Example: telco-deployment-01-mag.dc1-a4c3ad3a

mdm_addresses

Optional.

The list of management addresses of Metaswitch Deployment Manager(MDM) servers which will manage this cluster. Supply this only for an MDM-managed deployment.

For VMware vSphere, a comma-separated list of IPv4 addresses.

For OpenStack, a list of IPv4 addresses.

Example: 192.168.10.10,192.168.10.11,192.168.10.12

mdm_static_certificate

Optional.

The static certificate for connecting to MDM. Supply this only for an MDM-managed deployment.

The static certificate as a string

Example: -----BEGIN CERTIFICATE----- AAAA…​ -----END CERTIFICATE-----

mdm_ca_certificate

Optional.

The CA certificate for connecting to MDM. Supply this only for an MDM-managed deployment.

The static certificate as a string

Example: -----BEGIN CERTIFICATE----- AAAA…​ -----END CERTIFICATE-----

mdm_private_key

Optional.

The private key for connecting to MDM. Supply this only for an MDM-managed deployment.

The static certificate as a string

Example: -----BEGIN RSA PRIVATE KEY----- AAAA…​ -----END RSA PRIVATE KEY-----

secrets_private_key

Required.

The private Fernet key used to encrypt and decrypt secrets used by this deployment. A Fernet key may be generated for the deployment using the rvtconfig generate-private-key command. See the documentation for details.

The private key as a string

Example: EUTmDeliberatelyNotQuiteARealKeyJTcOg=

primary_user_password

Required.

The primary user’s password. The primary user is the sentinel user on RVT VMs, or the user defined in the node-parameters.yaml for custom VMs.

The password as a string. Minimum length is 8 characters. Be sure to quote it if it contains special characters.

Example: Ex4mpl3^Password$

ip_info

Required.

The IP address information for the VM.

An encoded string.

Example: t=management&i=1.2.3.4&s=1.2.3.0/24&g=1.2.3.1;t=sip,diameter,internal&s=…​

The ip_info parameter

For all network interfaces on a VM, the assigned traffic types, MAC address (OpenStack only), IP address, subnet mask, default gateway address, and optional IPv6 parameters (access traffic type only) are encoded in a single parameter called ip_info. Refer to Traffic types and traffic schemes for a list of traffic types found on each VM and how to assign them to network interfaces.

The names of the traffic types as used in the ip_info parameter are:

Traffic type Name used in ip_info

Management

 
management

Cluster

 
cluster

Access

 
access

Diameter signaling

 
diameter

SIP signaling

 
sip

SS7 signaling

 
ss7

Internal signaling

 
internal

Diameter Multihoming

 
diameter_multihoming

SS7 Multihoming

 
ss7_multihoming

Constructing the ip_info parameter

  1. Choose a traffic scheme.

  2. For each interface in the traffic scheme which has traffic types relevant to your VM, note down the values of the parameters for that interface: traffic types, MAC address, IP address, subnet mask, and default gateway address. If the interface is dual-stack, also note down the values of the IPv6 parameters for that interface: IPv6 address, IPv6 subnet mask, and IPv6 default gateway address.

  3. Construct a string for each parameter using these prefixes:

    Parameter Prefix Format

    Traffic types

    		 
    t=

    A comma-separated list (without spaces) of the names given above.
    Example: t=diameter,sip,internal

    MAC address

    		 
    m=

    Six pairs of hexadecimal digits, separated by colons. Case is unimportant.
    Example: m=01:23:45:67:89:AB

    IP address

    		 
    i=

    IPv4 address in dotted-decimal notation.
    Example: i=172.16.0.11

    Subnet mask

    		 
    s=

    CIDR notation.
    Example: s=172.16.0.0/24

    Default gateway address

    		 
    g=

    IPv4 address in dotted-decimal notation.
    Example: g=172.16.0.1

    IPv6 address

    		 
    i6=

    IPv6 address in colon-separated hexadecimal notation.
    Example: i6=12ab:10cd:4000:ef80::1b

    IPv6 subnet mask

    		 
    s6=

    CIDR notation.
    Example: s6=12ab:10cd:4000:ef80::/64

    Default IPv6 gateway address

    		 
    g6=

    IPv6 address in colon-separated hexadecimal notation.
    Example: g6=12ab:10cd:4000:ef80::1

  4. Join all the parameter strings together with an ampersand (&) between each.
    Example: t=diameter,sip,internal&m=01:23:45:67:89:AB&i=172.16.0.11&s=172.16.0.0/24&g=172.16.0.1

  5. Repeat for every other network interface.

  6. Finally, join the resulting strings for each interface together with a semicolon (;) between each.

For example, a full ip_info string that defines four network interfaces might look like this (newlines added for clarity):

t=management&m=01:23:45:67:89:AB&i=172.14.0.11&s=172.14.0.0/24&g=172.14.0.1;
t=cluster&m=01:23:45:67:89:BC&i=172.15.0.11&s=172.15.0.0/24&g=172.15.0.1;
t=diameter,sip,internal&m=01:23:45:67:89:CD&i=172.16.0.11&s=172.16.0.0/24&g=172.16.0.1;
t=access&m=01:23:45:67:89:DE&&i=172.17.0.11&s=172.17.0.0/24&g=172.17.0.1&i6=12ab:10cd:4000:ef80::1b&s6=12ab:10cd:4000:ef80::/64&g6=12ab:10cd:4000:ef80::1
Tip

The individual strings for each network interface must not contain a trailing &. The full ip_info string can, however, optionally include a trailing ;.

When including the string in a YAML userdata document, be sure to quote the string, e.g. ip_info: "t=management&m=…​"

Do not include details of any interfaces which haven’t been assigned any traffic types.
Previous page Next page
Rhino VoLTE TAS VMs Version 4.0.0