Versions Compared

Old Version 2

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: grammar

Add_workflow_for_techpubs
AUTH1
JIRAIDAUTHSBX-75414
REV5
REV6
REV3
REV1

 

...

Panel

In this section:

Table of Contents
maxLevel4

...

The Heat template queries additional private IPs and floating IPs 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 sections lists the steps required to edit the template file to associate additional IPs for a port and to assign floating IPs to it.

Info

The template file also lists the steps to edit for multiple IP support.

Associating Additional IPs to Network Port

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

...

  1. Search for EDIT - VIP PORT CREATION section in the fixed_ips property.

  2. 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]}
    - ip_address: {get_param: [pkt0_vips,1]}
    - ip_address: {get_param: [pkt0_vips,2]}
    - ip_address: {get_param: [pkt0_vips,3]}

...

  1. Search for EDIT - PRIVATE PORT CREATION - ACTIVE section.

  2. 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]}
    - ip_address: {get_param: [pkt0_vips,1]}
    - ip_address: {get_param: [pkt0_vips,2]}
    - ip_address: {get_param: [pkt0_vips,3]}

  3. Search for EDIT - PRIVATE PORT CREATION - STANDBY section.
  4. Repeat step 3 (b).

...

  1. Search for ADD - ADDITIONAL FLOATING IP CREATION section.

  2. Create floating IPs 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 PKT1
    Y is set to 0 to (n-1)  where, n is the number of PKT IP address
    Z is set to 0 to (m-1) where, m is the number of floating IP address

    Note

    To automatically assign floating IPs, comment floating_ip_address.

    Info

    This step is not applicable for IPv6.

...

  1. Search for METADATA_APPEND_ABOVE section.

  2. Append the following about the METADATA_APPEND_ABOVE section:

    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 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 resurnce names created earlier

  3. 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:

...

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
0Table
1Input Parameter Details for createPorts Function
ParameterTypeMandatory (Yes/No)Description

network

stringNoThe network ID.

subnet

stringNoThe subnet Id on the "network".

security_group

List of stringNo The IDs of the security group.

allowed_address_pairs

List<Map<String,String>>NoA 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_typestringNoIndicates the vNIC type to be bound on the neutron port. By default, it is a normal virtual port. The available options are normal or direct. If you are using SR-IOV and PCI-Passthrough, you can request the neutron port to be direct, by changing the virtualNICType to direct. It only works for Neutron deployments that support the bindings extension.

Panel

Related articles:

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
0company
provides a variety of example Heat templates for different types of SBC deployments. Use these example templates as reference to identify parameter input that is required for different SBC deployment characteristics. For example, different examples determine whether the SBC deployment is HA or standalone, whether the deployment uses DHCP, whether the deployment supports dual stack (IPv4 and IPv6), and other deployment variations. One approach is to select the example template that is most similar to your intended deployment and then customize it as needed. It could be necessary to combine sections from more than one example template to develop a template that instantiates the specific deployment you want.

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.

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 SBC templates:

  • 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), role (ceRole), and cluster configuration mode (ceMode).
  • 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.  
  • OAM settings – if an SBC node is going to be part of a cluster that will use OAM node configuration mode, these parameters identify the IP addresses of the OAM nodes. Refer to SBC SWe Configuration Management.
  • Node 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 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. 

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 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
titleNote

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:

      #personality:

        #"baseConfig.cli": {get_file: "RIBBON_BASE_CONFIG.cli"}

        #"baseConfig.cli": {get_file: "http://10.11.12.13/sbcCliFiles/RIBBON_BASE_CONFIG.cli"}

  • If the Confd CLI config file is locally present, use the first option of "get_file" and provide the absolute or relative file path.
    For example, "baseConfig.cli": {get_file: "RIBBON_BASE_CONFIG.cli"}
  • If the file is remotely located, use the second option of "get_file" and provide the URL.
    For example, "baseConfig.cli": {get_file: "http://10.11.12.13/sbcCliFiles/RIBBON_BASE_CONFIG.cli"}

...


Pagebreak