Page History

Overview

The Heat template queries additional private IP and floating IP when launched as a comma-separated input. The comma-separated IP address list must not have any spaces between the IP addresses as it leads to template-load error.

Associating an additional IP to a network port includes:

1. Virtual port creation
2. Private port creation
3. Floating IP creation (Optional)
4. Updating Meta data
5. Enabling SR-IOV on Packet Ports (Pkt0 and Pkt1)

This section lists the steps required to edit the template file to associate additional IP for a port and to assign floating IP.

Associating Additional IP to Network Port

To associate an additional IP to a network port (PKT0 or PKT1):

With Floating IP Format:
ALT_PKTX_01: { "IFName": "YYY", "IP": {get_param: [pktX_vips,0]}, "FIPV4": { get_attr: [pktX_floating_ip_A, floating_ip_address] } }
 
Without Floating IP Format:
ALT_PKTX_01: { "IFName": "YYY", "IP": {get_param: [pktX_vips,0]}}

"With Floating IP Format" is not applicable for IPv6.

SBC SWe Cloud deployments can be instantiated in an OpenStack environment using standard Heat templates. Refer to OpenStack documentation or documentation from your OpenStack provider for information on deployment using Heat and Heat templates. During instantiation, a Heat template provides essential information to OpenStack that enable it to create the VM resources required by the SBC. It also provides specific parameter values needed to customize the SBC deployment and to configure essential networking.

Comment statements within the examples also explain how to implement customizations for optional features such as adding additional IP addresses to ports, enabling SR-IOV on an interface, adding a second management port, or implementing packet port redundancy. Refer to the SBC Core release notes for information on how to download the example template files.

Template Parameters

The exact contents required in a template file differs based on the specific characteristics of the intended deployment, but the following parameter categories appear in any SBC template:

• System Settings – these parameters include general system setting such as the flavor, image, SBC personality type, SBC system name, and a security_group name.
• Instance-specific Settings – these parameters are specific to the instance being instantiated such as the node name (ceName) and role (ceRole).
• External and Private Network Settings – these parameters provide information on the external and private networks the SBC will use, such as the names of the networks and settings for the private network subnets.
• EMS settings – these parameters identify the IP address and login credentials for accessing the EMS system that will be used to manage the SBC.  
• SBC login credentials – These parameters specify login details such as the public key for the admin and linuxadmin users and optional passwords for these accounts.

Refer to the template file examples for more details on the parameters that can be included in a template file.  

Metadata and Userdata

The user data and metadata sections of the template contain essential configuration information that the SBC VM requires to initialize. Metadata consists primarily of information related to the SBC interfaces such as IP addresses and gateways. Userdata is comprised of user-specified data such as the system name, instance name, and whether the instance should take the active or standby role.The data is stored by the metadata service and retrieved when the instance boots up.

The values in these sections must be provided in a specific format and syntax. Formatting or syntax errors in the template can prevent the VM from booting properly. Refer to Metadata and Userdata Format for the required metadata and userdata formats. If necessary after instantiation, metadata and userdata can be updated using nova APIs. However any such changes do not take effect until the instance is rebooted. 

Environment Files

OpenStack allows you to specify an environment file along with a template when launching an instance. When included, an environment file provides parameter values that are called for in the template, overriding what is specified within the template file. If you want to reuse a template file to deploy multiple instances, an environment file can specify some specific parameter values while the template remains generic. An environment file cannot be used to provide metadata or userdata. Refer toOpenStack documentation for more information on using environment files.     

where X is set to 0 or 1 for PKT
ALT_PKTX_01 is the alternate IP name or meta key name
YYY is IF name of PKT ports for example, IF2 for PKT0
pktX_floating_ip_A is the IP names created earlier

To enable SR-IOV on packet ports:

Search for PKT0 and PKT1 interface ports. Edit the ports information section:

pkt0_port1:
    type: OS::Neutron::Port
    properties:
      network: { get_param : private_network_pkt0 }
      fixed_ips:
        # pkt0 EDIT: uncomment below line to DISABLE DHCP or comment to ENABLE DHCP
        - ip_address: { get_param: PKT0IPv4}
        #- ip_address: { get_param: PKT1IPv4}        
        #- ip_address: {get_param: [pkt0_alt_ips,0]}
        #- ip_address: {get_param: [pkt0_alt_ips,1]}
 
        # pkt1 EDIT: uncomment below line to ENABLE DHCP or comment to DISABLE DHCP
        #- subnet: { get_param: private_subnet_pkt0}
 
      #binding:vnic_type: direct
 
      security_groups:
        - { get_param: security_group }