Add_workflow_for_techpubs | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
In this section:
|
...
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:
This section lists the steps required to edit the template file to associate additional IP for a port and to assign floating IP.
Info |
---|
The template file also lists the steps to edit for multiple IP support. |
To associate an additional IP to a network port (PKT0 or PKT1):
...
EDIT - VIP PORT CREATION
section in the fixed_ips
property.Un-comment the parameter - ip_address:
Note |
---|
The number of - IP address parameters depends on the number of IP address. For example, to add four IP address to PKT0 you must have four - IP address parameters such as: - ip_address: {get_param: [pkt0_vips,0]} |
...
EDIT - PRIVATE PORT CREATION - ACTIVE
section.Un-comment the - ip_address:
parameter in the allowed_address_pairs
property.
Note |
---|
The number of - IP address parameters depends on the number of IP address. For example, to add four IP address for PKT0 you must have four - IP address parameters such as: - ip_address: {get_param: [pkt0_vips,0]} |
EDIT - PRIVATE PORT CREATION - STANDBY
section....
ADD - ADDITIONAL FLOATING IP CREATION
section.Create floating IP as:
Code Block |
---|
pktX_floating_ip_A:
type: OS::Neutron::FloatingIP
properties:
floating_network: { get_param: pktX_ext_network }
port_id: { get_resource: pktX_vip_port }
fixed_ip_address: {get_param: [pktX_vips,Y]}
floating_ip_address: {get_param: [additional_Fips_pktX,Z]} |
where X
is set to 0 for PKT0 and 1 for PKT1Y
is set to 0 to (n-1) where, n is the number of PKT IP addressZ
is set to 0 to (m-1) where, m is the number of floating IP address
Note |
---|
To automatically assign floating IP, comment |
Info |
---|
Ignore Step 4 for IPv6 configuration. |
...
Code Block |
---|
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]}} |
Note |
---|
"With Floating IP Format" is not applicable for IPv6. |
where X
is set to 0 or 1 for PKTALT_PKTX_01
is the alternate IP name or meta key nameYYY
is IF name of PKT ports for example, IF2 for PKT0pktX_floating_ip_A
is the IP names created earlier
SBC SWe Cloud deployments can be instantiated in an OpenStack environment using standard Heat templates. A Heat template is a .yaml
file that provides essential information to OpenStack that enables creating the VM resources the SBC requires during the orchestration process. An SBC template also includes parameters needed to customize the deployment and to configure essential networking. Parameters can be populated with default values directly in the template or parameter values can be specified when an instance is deployed through user input or in an environment file. Refer to OpenStack documentation, or documentation from your OpenStack provider, for information on using Heat templates.
Spacevars | ||
---|---|---|
|
Comment statements within the examples 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.
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 SBC templates:
Refer to the template file examples for more details on the parameters that can be included in a template file.
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 and descriptions of the parameters. 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.
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 by the template and override defaults specified within the template file. If you want to reuse a template file to deploy multiple instances, an environment file can provide some specific parameter values for the specific instance while the template remains generic. An environment file cannot be used to provide metadata or userdata. Refer to OpenStack documentation for more information on using environment files.
Info | ||
---|---|---|
| ||
In an HA Heat template, there are sections to download the Confd CLI config file from a local/remote location. By default, this section is commented out. If the Confd CLI config file needs to be downloaded and automatically loaded on the SBC, this section must be uncommented, and a proper file path must be provided in the Heat template. Heat template section:
|
...
Repeat step 5 (a and b) for Standby instance.
Note |
---|
The maximum length of the alternate IP name or meta key name is 23 characters. |
To enable SR-IOV on packet ports:
Search for PKT0 and PKT1 interface ports. Edit the ports information section:
Code Block |
---|
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 } |
Caption | ||||
---|---|---|---|---|
| ||||
|
Parameter | Type | Mandatory (Yes/No) | Description |
---|---|---|---|
network | string | No | The network ID. |
subnet | string | No | The subnet Id on the "network". |
security_group | List of string | No | The IDs of the security group. |
allowed_address_pairs | List<Map<String,String>> | No | A set of zero or more allowed address pairs, map keys are "ip_address" and "mac_address". Example: allowed_address_pairs: [{ip_address: "10.2.0.1"}] |
vnic_type | string | No | Indicates the vNIC type to be bound on the neutron port. Values:
If you are using SR-IOV and PCI-Passthrough, select Direct. Change the |
...
Pagebreak |
---|