This section describes basic interface configurations, such as:

• Network

• Subnet

• IP address

• MAC address

• VIM interface name, and so on for Elastic Services Controller (ESC).

To configure VIM interface name, specify attribute <vim_interface_name> for an interface in the Deployment XML file. Use <vim_interface_name> to use a specific name when generating an interface name. If these attribute is not specified, ESC will auto-generate an interface name, which is a combination of the deployment_name, group_name, and a random UUID string. For example: my-deployment-na_my-gro_0_8053d7gf-hyt33-4676-h9d4-9j4a5599472t.

Note	This feature is currently supported only on OpenStack.

If the VM group is elastic and a vim_interface_name has been specified, a numeric index is added after the interface name for the second interface name onwards (the first one remains unchanged). For example, if the specified interface name is set as <vim_interface_name>interface_1</vim_interface_name> and scaling is set to 3, three VMs are created with three different interface name, interface_1, interface_1_1, and interface_1_2. If a VM group only has a single VM, then there is no "_<index>" appended to the custom interface name. A single deployment can contain multiple VM groups, and each individual VM group can specify a different vim_interface_name value, if required. For example, a deployment could have two VM groups: the first group specifies a vim_interface_name and all VMs have their names generated as described above. The second VM group does not specify a vim_interface_name, therefore all VM names created from this group are auto generated. The same interface name can be used in separate interface sections within the same VM group, or in separate VM groups within a deployment, or in different deployments if required.

If attributes <vim_interface_name> or <port> are used for the same interface, the vim_interface_name value will be ignored and the value in the port attribute will be used.

<esc_datamodel xmlns="https://www.cisco.com/esc/esc"> <tenants><tenant>
<name>Admin</name>
<deployments>
<deployment>
<deployment_name>NwDepModel_nosvc</deployment_name>
<interface>
<nicid>0</nicid>
<vim_interface_name>interface_1</vim_interface_name>    
<network>my-network</network>
</interface>

Note

You can use a maximum of 61 characters for an interface name should not contain special characters and can only contain alphanumeric characters and "_" and "-". The following are some output samples with the custom port name. If the vim_interface_name was set during the deployment, the same value will be shown in the output. If this value was not set during the deployment, ESC will auto-generate the port name.

• Below is an example of the output operational data fetched using the esc_nc_cli script after adding a custom interface name. A new element called vim_interface_name will be shown under the interface element.

  
  [admin@esc-3-1-xxx]$ esc_nc_cli --user <username> --password <password> get esc_datamodel/opdata
  <?xml version="1.0" encoding="UTF-8"?>
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  . . .
      <interface>
          <nicid>0</nicid>
          <type>virtual</type>
          <port_id>e4111069-5d00-493b-8ea9-1a2ca134b5c8</port_id>
          <vim_interface_name>interface_1</vim_interface_name>      <!-- NEW IN OUTPUT -->
          <network>c7fafeca-aa53-4349-9b60-1f4b92605420</network>
          <subnet>255.255.255.0</subnet>
          <ip_address>192.168.2.1</ip_address>
          <mac_address>fa:16:3e:d7:5e:da</mac_address>
          <netmask>255.255.240.0</netmask>
          <gateway>192.168.2.255</gateway>
      </interface>
  

• Below is an example output operational data fetched using a REST API.

  
  GET http://localhost:8080/ESCManager/v0/deployments/example-deployment-123 
  | xmllint --format -
  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <deployments>
  . . .
      <interface>
          <network_uuid>c7fafeca-aa53-4349-9b60-1f4b92605420</network_uuid>
          <gateway>172.16.0.1</gateway>
          <ip_address>172.16.12.251</ip_address>
          <mac_address>fa:16:3e:30:0c:99</mac_address>
          <netmask>255.255.240.0</netmask>
          <nic_id>0</nic_id>
          <port_forwarding/>
          <port_uuid>1773cdbf-fe5f-4af1-adff-3a9c1dd1c47d</port_uuid>
          <vim_interface_name>interface_1</vim_interface_name>         <!-- NEW IN OUTPUT -->
          <security_groups/>
          <subnet_uuid>7b2ce63b-eb20-4ff8-8d49-e46ee8dde0f5</subnet_uuid>
          <type>virtual</type>
      </interface>
  
  

  In all the above scenarios, if vim_interface_name is not specified in the deployment.xml, the output will still contain this element, however with an internally generated interface name. For example: <vim_interface_name>vm-name-deployme_Grp1_1_0f24cd7e-cae7-402e-819a-5c84087103ba</vim_interface_name>

ESC deployment on VMware vCenter supports assigning MAC address using the MAC address range, or MAC address list from the MAC address pool to deploy VMs to the network.

You can assign MAC address in the following ways:

Using the Interface

<interfaces>
    <interface>
	<nicid>1</nicid>
	<network>MANAGEMENT_NETWORK</network>
	<ip_address>172.16.0.11</ip_address>
	<mac_address>fa:16:3e:73:19:a0</mac_address>
    </interface>
</interfaces>

During scaling, you can assign the MAC address list or MAC address range from the MAC address pool.

<scaling>
	<min_active>2</min_active>
	<max_active>2</max_active>
	<elastic>true</elastic>
	<static_ip_address_pool>
		<network>MANAGEMENT_NETWORK</network>
		<ip_address>172.16.0.11</ip_address>
		<ip_address>172.16.0.12</ip_address>
		<ip_address>172.16.0.13</ip_address>
	</static_ip_address_pool>
	<static_mac_address_pool>
		<network>MANAGEMENT_NETWORK</network>
		<mac_address>fa:16:3e:73:19:a0</mac_address>
		<mac_address>fa:16:3e:73:19:a1</mac_address>
		<mac_address>fa:16:3e:73:19:a2</mac_address>
	</static_mac_address_pool>
</scaling>

Assign MAC address using MAC address range.

<scaling>
	<min_active>2</min_active>
	<max_active>2</max_active>
	<elastic>true</elastic>
	<static_ip_address_pool>
		<network>MANAGEMENT_NETWORK</network>
		<ip_address_range>
			<start>172.16.0.25</start>
			<end>172.16.0.27</end>
		</ip_address_range>
	</static_ip_address_pool>
	<static_mac_address_pool>
		<network>MANAGEMENT_NETWORK</network>
		<mac_address_range>
			<start>fa:16:3e:73:19:b0</start>
			<end>fa:16:3e:73:19:b2</end>
		</mac_address_range>
	</static_mac_address_pool>
</scaling>

Note

You cannot change the MAC or IP pool in an existing deployment, or during scaling (when min and max value are greater than 1) of VM instances in a service update. In VMware vCenter, while assigning the MAC address, the server might override the specified value for "Generated" or "Assigned" if it does not fall in the right ranges or is determined to be a duplicate. Because of this, if ESC is unable to assign the MAC address the deployment fails.

ESC also allows you to attach an out-of-band port to a VNF. To do this, pass the UUID or the name of the port in the deployment request file while initiating a service request. For more information, see, Out-of-band Volumes section in the Cisco Elastic Services Controller User Guide.

Note

While undeploying or restoring a VNF, the ports attached to that VNF will only be detached and not deleted. ESC does not allow scaling while using out-of-band port for a VM group. You can configure only one instance of VM for the VM group.Updating the scaling value for a VM group, while using the out-of-band port is not allowd during a deployment update.

<esc_datamodel xmlns="https://www.cisco.com/esc/esc">
    <name>tenant</name>
    <deployments>
        <deployment>
            <name>depz</name>
            <vm_group>
                <name>g1</name>
                <image>Automation-Cirros-Image</image>
                <flavor>Automation-Cirros-Flavor</flavor>
                <bootup_time>100</bootup_time>
                <reboot_time>30</reboot_time>
                <recovery_wait_time>10</recovery_wait_time>
                <interfaces>
                    <interface>
                        <nicid>0</nicid>
                        <port>057a1c22-722e-44da-845b-a193e02807f7</port>
                        <network>my-network</network>
                    </interface>
                </interfaces>
            </vm_group>
        </deployment>
    </deployments>
</esc_datamodel>

A dual stack network allows you to assign multiple IP addresses. These multiple IP addresses can be assigned on different subnets to a given interface within a VNF deployment using ESC.

ESC supports the following for dual stack:

• Configuring the network and list of subnet

• Configuring the network and list of subnet and ip address

• Configuring the network and list of ip address ( no subnet)

• Specifying the network and list of subnet/ip ( same subnet but different ip)

Note	Currently, ESC supports dual stack only on OpenStack. ESC supports end-to-end IPv6 for OpenStack deployments.

A new container element named addresses is added to the Interface. This container holds a list of address elements. An address element must have an address_id (key). The subnet and fixed-ip address fields are optional, but you must specify either one.

The container address is as follows:

container addresses {
  list address {
    key "address_id";
    leaf address_id {
      description "Id for the address in address list.";
      type uint16;
      mandatory true;
    }
    leaf subnet {
      description "Subnet name or uuid for allocating IP to this port";
      type types:escnetname;
    }
leaf ip_address {
description "Static IP address for this specific subnet";
type types:escipaddr;
must "../../../../../scaling/max_active = 1 or count(../../../../../scaling/static_ip_address_pool) > 0"
{
error-message "Static ip address pools must be configured when static ip addresses are configured.";
}
}

Dual stack now supports KPI monitoring. A new child element address_id has been added to the metric_collector element. This accepts a value which points to an address within the specified nicid to be used for KPI monitoring. That is, it allows one of the addresses defined beneath an interface to be used for KPI monitoring.

…
    <interface>
        <nicid>1</nicid>
        <network>demo-net</network>
        <addresses>
            <address>
                <address_id>0</address_id>
                <subnet>demo-subnet</subnet>
            </address>
        </addresses>
    </interface>

           <kpi_data>
              <kpi>
                <event_name>VM_ALIVE</event_name>
                <metric_value>1</metric_value>
                <metric_cond>GT</metric_cond>
                <metric_type>UINT32</metric_type>
                <metric_occurrences_true>5</metric_occurrences_true>
               <metric_occurrences_false>5</metric_occurrences_false>
              <metric_collector>
                  <type>ICMPPing</type>
                  <nicid>1</nicid>
                  <address_id>0</address_id>
                  <poll_frequency>10</poll_frequency>
                  <polling_unit>seconds</polling_unit>
                 <continuous_alarm>false</continuous_alarm>
                </metric_collector>
              </kpi>
            </kpi_data>
...

Note	The address_id under the metric_collector element must be the same as one of the address_id beneath the interface.

Dual stack interfaces can now be used in day-0 variable substitution. This means the ability to substitute the values from the multiple addresses defined under a single interface. Day 0 configuration is defined in the datamodel under the config_data tag.

In case of dual stack with multiple IP addresses, the variables are in the form NICID_<n>_<a>_<PROPERTY> where:

• <n> is the nicid for the interface.

• <a> is the address_id of an address within that interface.

The list of possible day-0 substitution variables from dual stack is:

For information on day-0 confirguration for single IP address, see Day Zero Configuration chapter in the Cisco Elastic Services Controller User Guide.

NICID_0_NETWORK_ID=${NICID_0_NETWORK_ID}
NICID_0_MAC_ADDRESS=${NICID_0_MAC_ADDRESS}

NICID_0_0_IP_ALLOCATION_TYPE=${NICID_0_0_IP_ALLOCATION_TYPE}
NICID_0_0_IP_ADDRESS=${NICID_0_0_IP_ADDRESS}
NICID_0_0_GATEWAY=${NICID_0_0_GATEWAY}
NICID_0_0_CIDR_ADDRESS=${NICID_0_0_CIDR_ADDRESS}
NICID_0_0_CIDR_PREFIX=${NICID_0_0_CIDR_PREFIX}
NICID_0_0_NETMASK=${NICID_0_0_NETMASK}

NICID_0_1_IP_ALLOCATION_TYPE=${NICID_0_1_IP_ALLOCATION_TYPE}
NICID_0_1_IP_ADDRESS=${NICID_0_1_IP_ADDRESS}
NICID_0_1_GATEWAY=${NICID_0_1_GATEWAY}
NICID_0_1_CIDR_ADDRESS=${NICID_0_1_CIDR_ADDRESS}
NICID_0_1_CIDR_PREFIX=${NICID_0_1_CIDR_PREFIX}

The datamodel is as follows:

<?xml version="1.0" encoding="ASCII"?>
<esc_datamodel xmlns="https://www.cisco.com/esc/esc">
  <tenants>
    <tenant>
      <name>dep-tenant</name>
      <deployments>
        <deployment>
          <name>cirros-dep</name>
          <vm_group>
            <name>Grp1</name>
            <bootup_time>600</bootup_time>
            <recovery_wait_time>30</recovery_wait_time>
            <flavor>Automation-Cirros-Flavor</flavor>
            <image>Automation-Cirros-Image</image>
           <interfaces>
              <interface>
                <!-- No dual stack support on mgmt interface in ESC 4.1 -->
                <nicid>0</nicid>  
                <network>my-network</network>  
              </interface>
              <interface>
                <nicid>1</nicid>  
                <network>ent-network1</network>  
                <addresses>
                  <address>
                    <!-- IPv4 Dynamic -->
                    <address_id>0</address_id>    
                    <subnet>v4-subnet_A</subnet>
                  </address>
                  <address>
                    <!-- IPv6 Dynamic -->
                    <address_id>1</address_id>     
                    <subnet>v6-subnet_B</subnet>
                  </address>
                </addresses>
              </interface>
              <interface>
                <nicid>2</nicid>  
                <network>ent-network2</network>  
                <addresses>
                  <address>
                    <!-- IPv4 Static -->
                    <address_id>0</address_id>     
                    <subnet>v4-subnet_C</subnet>
                    <ip_address>172.16.87.8</ip_address>
                  </address>
                  <address>
                    <!-- IPv6 Static -->
                    <address_id>1</address_id>      
                    <subnet>v6-subnet_D</subnet>
                    <ip_address>fd07::110</ip_address>
                  </address>
                </addresses>
              </interface>
              <interface>
                <nicid>3</nicid>  
                <network>ent-network3</network>  
                <addresses>
                  <address>
                    <!--  Only ip config -  ipv6 but no subnet  -->
                    <address_id>0</address_id>      
                    <ip_address>fd07::110</ip_address>
                  </address>
                  <address>
                    <!--  Only ip config - ipv4 but no subnet  -->
                    <address_id>1</address_id>      
                    <ip_address>172.16.88.9</ip_address>
                  </address>
                </addresses>
              </interface>
              <interface>
                <nicid>4</nicid>  
                <network>ent-network4</network>  
                <addresses>
                  <address>
                    <!-- ipv4 same subnet as address_id 6 -->
                    <address_id>0</address_id>      //
                    <subnet>v4-subnet_F</subnet>
                    <ip_address>172.16.86.10</ip_address>
                  </address>
                  <address>
                    <!-- ipv4 same subnet as id 5 -->
                    <address_id>1</address_id>   
                    <subnet>v4-subnet_F</subnet>
                    <ip_address>172.16.86.11</ip_address>
                  </address>
                </addresses>
              </interface>
            </interfaces>
            <kpi_data>
...

After successful deployment using multiple IPs, ESC provides a list of addresses as notification, or opdata.

A list of multiple <address> elements under the parent <interface> element containing the following:

• address_id—the address id specified in the input XML

• subnet element—subnet name or uuid

• ip_address element—the port's assigned IP on that subnet

• prefix—the subnet CIDR prefix

• gateway—the subnet gateway address

• ESC Static IP support

Notification:

                  <vm_id>1834124d-b70b-41b9-9e53-fb55d7c901f0</vm_id>
                  <name>jenkins-gr_g1_0_e8bc9a81-4b9a-437a-807a-f1a9bbc2ea3e</name>
                  <generated_name>custom_vim_name
                  <host_id>dc380f1721255e2a7ea15932c1a7abc681816642f75276c166b4fe50</host_id>
                  <hostname>my-server</hostname>
                  <interfaces>
                    <interface>
                      <nicid>0</nicid>
                      <type>virtual</type>
                      <vim_interface_name>custom_vim_name
                      <port_id>4d57d4a5-3150-455a-ad39-c32fffbb10b1</port_id>
                      <mac_address>fa:16:3e:d2:50:a5</mac_address>
                      <network>45638651-2e92-45fb-96ce-9efdd9ea343e</network>
                      <address>
                        <address_id>0<address_id>
                        <subnet>6ac36430-4f58-454b-9dc1-82f7a796e2ff</subnet>
                        <ip_address>172.16.0.22</ip_address>
                        <prefix>24</prefix>
                        <gateway>172.16.0.1</gateway>
                      </address>
                      <address>
                        <address_id>1<address_id>
                        <subnet>8dd9f501-19d4-4782-8335-9aa9fbd4dab9</subnet>
                        <ip_address>2002:dc7::4</ip_address>
                        <prefix>48</prefix>
                        <gateway>2002:dc7::1</gateway>
                      </address>
                      <address>
                        <address_id>2<address_id>
                        <subnet>a234501-19d4-4782-8335-9aa9fbd4caf6</subnet>
                        <ip_address>172.16.87.8</ip_address>
                        <prefix>20</prefix>
                        <gateway>172.16.87.1</gateway>
                      </address>
                    </interface>         
 

Sample opdata:

  <interfaces>
   <interface>
      <nicid>0</nicid>
      <type>virtual</type>
      <vim_interface_name>custom_vim_name
      <port_id>4d57d4a5-3150-455a-ad39-c32fffbb10b1</port_id>
      <mac_address>fa:16:3e:d2:50:a5</mac_address>
      <network>45638651-2e92-45fb-96ce-9efdd9ea343e</network>
      <address>
         <address_id>0</address_id>
         <subnet>6ac36430-4f58-454b-9dc1-82f7a796e2ff</subnet>
         <ip_address>172.16.0.22</ip_address>
         <prefix>24</prefix>
         <gateway>172.16.0.1</gateway>
      </address>
      <address>
         <address_id>1</address_id>
         <subnet>8dd9f501-19d4-4782-8335-9aa9fbd4dab9</subnet>
         <ip_address>2002:dc7::4</ip_address>
         <prefix>48</prefix>
         <gateway>2002:dc7::1</gateway>
      </address>
   </interface>
</interfaces>

You can also see that the day-0 substitution values are replaced in the output data. Sample output data with the values populated in the day-0 configuration is as follows:

NICID_0_NETWORK_ID=45638651-2e92-45fb-96ce-9efdd9ea343e
NICID_0_MAC_ADDRESS=fa:16:3e:d2:50:a5

NICID_0_0_IP_ALLOCATION_TYPE=DHCP
NICID_0_0_IP_ADDRESS=172.16.0.22
NICID_0_0_GATEWAY=172.16.0.1
NICID_0_0_CIDR_ADDRESS=172.16.0.0
NICID_0_0_CIDR_PREFIX=24
NICID_0_0_NETMASK=255.255.255.0

NICID_0_1_IP_ALLOCATION_TYPE=DHCP
NICID_0_1_IP_ADDRESS=2002:dc7::4
NICID_0_1_GATEWAY=2002:dc7::1
NICID_0_1_CIDR_ADDRESS=2002:dc7::/48
NICID_0_1_CIDR_PREFIX=48

Dual Stack with Static IP Support

ESC supports dual stack with static IP support. As part of the initial configuration the user can provide the subnet and IP to be configured.

Note	ESC supports static IP only when the scaling is false or minimum /maximum =1.

When you create a VM with out-of-band network, and specify a list of subnets with static IP (the network has multiple subnets), then ESC applies both subnet and the corresponding static IP.

In the example below, two subnets (ipv4 and ipv6 ) are added to a single interface.

<?xml version="1.0" encoding="ASCII"?>
<esc_datamodel xmlns="https://www.cisco.com/esc/esc">
  <tenants>
    <tenant>
      <name>dep-tenant</name>
      <deployments>
        <deployment>
          <name>cirros-dep</name>
          <vm_group>
            <name>Grp1</name>
            <bootup_time>600</bootup_time>
            <recovery_wait_time>30</recovery_wait_time>
            <flavor>Automation-Cirros-Flavor</flavor>
            <image>Automation-Cirros-Image</image>
            <interfaces>
              <interface>
                <nicid>0</nicid> 
                <network>ent-network2</network> 
                <addresses>
                  <address>
                    <!-- IPv4 Static -->
                    <address_id>0</address_id>    
                    <subnet>v4-subnet_C</subnet>
                    <ip_address>172.16.87.8</ip_address>
                  </address>
                  <address>
                    <!-- IPv6 Static -->
                    <address_id>1</address_id>     
                    <subnet>v6-subnet_D</subnet>
                    <ip_address>fd07::110</ip_address>
                  </address>
                </addresses>
              </interface>
            </interfaces>
          <kpi_data>

For information on deploying VNFs, see Deploying Virtual Network Functions on OpenStack.

Cisco Elastic Services Controller allows you to specify the address pairs in the deployment datamodel to pass through a specified port regardless of the subnet associated with the network.

The address pair is configured in the following ways:

ESC needs one or more PCI or PCIe passthrough devices to be attached to each deployment without a particular PCI ID. ESC first selects a host. ESC selects the next available PCI or PCIe passthrough enabled device and attaches it during the deployment. If there is no PCI or PCIe passthrough enabled device available, ESC fails the deployment. The vSphere administrator has to ensure all computing-host within the target computing-cluster have enough number of PCI or PCIe passthrough enabled devices.

Note

PCI or PCIe passthrough is not considered by ESC placement algorithm. For example, ESC does not select a host because it has available resources to complete the PCI or PCIe passthrough requests. ESC selects the PCI or PCIe passthrough device randomly. ESC does not consider the type or specification of the device. It selects the next available PCI or PCIe device from the list. Recovery fails if the VNF is recovered to a computing-host that ESC has selected based on the ESC placement algorithm, and if that computing-host does not have any PCI or PCIe passthrough enabled devices available. DRS must be turned off for the passthrough to work.