Deploying SteelHead-v in OpenStack
This chapter describes how to download, create, and deploy a new SteelHead (virtual edition) (SteelHead-v) appliance in an OpenStack environment and includes the following sections:
What you need
Knowledge requirements
You must be familiar with the deployment options described in the SteelHead (Virtual Edition) Installation Guide.
Software requirements
You must use a next-generation virtual SteelHead VCX software image in KVM format. CX series SteelHead-v images are not supported.
Deployment guidelines
Do not use Layer 2 redirection mechanisms in your OpenStack deployment. As with many public clouds, OpenStack is a Layer 3 environment, and there are no Layer 2 redirections available. Devices can only receive traffic if traffic is directly forwarded to their IP addresses.
If you use a Heat template to deploy the VCX, see
Heat template deployment guidelines for additional configuration recommendations.
Deploying SteelHead-v appliances in OpenStack
To deploy SteelHead-v appliances in an OpenStack environment
1. Go to the
support.riverbed.com site and download the image named Next Generation Virtual SteelHead VCX Software Image (KVM). Do not download an image for a CX model.
2. Extract the files in the image by entering the tar CLI command.
In this CLI example, the .tar file image name is image_rbt_sh_9_7_0_n6_ng_x86_64.tgz.
$ tar -zxvf image_rbt_sh_9_7_0_n6_ng_x86_64.tgz
mgmt.qcow2
install.sh
riverbed_model_tmp
all_bypass_pci
3. Using Secure Copy (SCP) or another secure copy utility, upload the extracted mgmt.qcow2 image to the OpenStack client workstation.
4. Import the mgmt.qcow2 image into the image service using the glance image-create CLI command.
This example shows how to create an image named NextGen Virtual Steelhead 9.7.
$ glance image-create --name "NextGen Virtual SteelHead 9.7" --container-format bare --disk-format qcow2 < mgmt.qcow2
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | b192306c2d7b459e57063d9b93cba4e9 |
| container_format | bare |
| created_at | 2017-06-12T20:36:02Z |
| disk_format | qcow2 |
| id | 304c7ee3-62fb-4881-995d-8a4d8f960bbc |
| min_disk | 0 |
| min_ram | 0 |
| name | NextGen Virtual Steelhead 9.7 |
| owner | 2091e12a67f844bf86a0fa22965d393d |
| protected | False |
| size | 2680881152 |
+------------------+--------------------------------------+
5. Determine the memory requirements for the VCX model by opening and viewing the riverbed_model_tmp file using the cat CLI command.
The riverbed_model_tmp file shows the following information in this order:
– Model
– Model description
– Number of vCPUs
– RAM
– Management HDD size
– DataStore1 HDD Size
– DataStore2 HDD Size
This example shows the output of the riverbed_model_tmp file.
$ cat riverbed_model_tmp
.
.
.
VCX10 = New-Model 1 2048MB 20GB 50GB 50GB;
VCX20 = New-Model 1 2048MB 20GB 80GB 80GB;
VCX30 = New-Model 1 2048MB 20GB 100GB 100GB;
VCX40 = New-Model 2 4096MB 26GB 150GB 150GB;
VCX50 = New-Model 4 8192MB 38GB 400GB 400GB;
VCX60 = New-Model 4 8192MB 38GB 400GB 400GB;
VCX70 = New-Model 6 24576MB 70GB 800GB 80GB;
VCX80 = New-Model 12 32768MB 86GB 1600GB 160GB;
VCX90 = New-Model 24 49152MB 118GB 2240GB 160GB;
VCX100 = New-Model 32 65536MB 160GB 3600GB 300GB;
VCX110 = New-Model 44 131072MB 300GB 4800GB 300GB;
6. Create an OpenStack flavor based on the requirements of the license. Virtual hardware templates are called flavors in OpenStack.
If you have already created a flavor, skip to
Step 7.
• To create an OpenStack flavor using the GUI, select the System tab, select the Flavors category, click Create Flavor, and enter values for the VCX appliance in the Flavor Information tab.
Enter the RAM, Root Disk, Ephemeral Disk, and Swap Disk values based on the requirements for the VCX model. This figure shows a flavor being created for a VCX10.
Creating an OpenStack flavor using the GUI
7. Create networks for the appliance. Create one network for each network interface.
• To create networks using the OpenStack GUI, choose System > Networks, click Create Network, and enter the IP address and subnet values for each network.
This figure shows four networks being created: one network each for the primary, WAN, LAN, and auxiliary (aux) network interfaces.
Creating networks for SteelHead-v network interfaces
• To create networks using the CLI, continue to
Step 8. You create networks at the same time as you create the instance when using the CLI.
8. Create an OpenStack instance using either the Horizon dashboard or OpenStack CLI.
• To create an OpenStack instance from the Horizon dashboard, complete these steps:
– Expand Compute under the Project topic and click Image.
– Select the SteelHead-v KVM image.
– Click Launch Instance in the Actions column.
Launching an OpenStack instance using Horizon GUI
– Select the Details tab in the Launch Instance window and enter the VCX flavor and image name in the Flavor and Instance Boot Source fields.
Specifying parameters for the instance using the Horizon GUI
– Select the Networking tab and associate the network interfaces with the networks you created.
This example shows how to associate networks for the Primary (NIC 1), Aux (NIC 2), LAN (NIC 3), and WAN (NIC 4) interfaces.
Associating the networks with the network interfaces
– Select the Post-Creation tab, and then create a script to add a primary and auxiliary IP address, network mask, default gateway, DNS server address, domain name, and administrative password.
This example shows how to create a SteelHead-v with an IP address of 192.168.1.2/24, an auxiliary address of 10.0.0.2/16, a default gateway of 10.0.0.1, a DNS server address of 10.16.32.48, and a domain name of nbttech.com.
Creating a post-creation script for the instance
– Click Launch.
Entering the CLI in this example creates a single network interface and limits your SteelHead-v deployment type to out-of-path only. With out-of-path deployments, the primary interface is used to receive and optimize traffic. Use the autodiscovery process or fixed-target in-path rules for this configuration.
This example shows how to create a network interface for a VCX10; change the flavor if you are configuring another VCX model.
$ openstack server create --image "NextGen Virtual Steelhead 9.7" --flavor vcx10 --nic net-id=d23be009-7340-41a3-83e0-734775b81407 ngVCX-A
+--------------------------------------+---------------------------------------------------+
| Field | Value --------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | |
| OS-EXT-SRV-ATTR:host | None |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name | |
| OS-EXT-STS:power_state | NOSTATE |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| OS-SRV-USG:launched_at | None |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | |
| adminPass | ZGF84SuKbTgp |
| config_drive | |
| created | 2017-06-13T18:13:13Z |
| flavor | vcx10 (ffba79ff-2715-4bd1-a081-0bfc304dde7a) |
| hostId | |
| id | 855f0253-c502-46c0-8ae0-c08547446c95 |
| image | NextGen Virtual Steelhead 9.7 (304c7ee3-62fb-4881-995d-8a4d8f960bbc)|
| key_name | None |
| name | ngVCX-A |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| project_id | 53ad8fb1ddd1457aa68d14f531f07616 |
| properties | |
| security_groups | [{u'name': u'default'}] |
| status | BUILD |
| updated | 2017-06-13T18:13:13Z |
| user_id | 70bcd75fd6bf4553a15fc84b2f5454b2 |
+-----------+-------------------------------------------------------------------------+
9. Create a datastore volume by entering the openstack volume create command.
This example shows how to create a datastore called vcx_1 with a size of 50 gigabytes (GB), which is sufficient for a VCX10.
$ openstack volume create --size 50 vcx_1
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2017-06-12T21:00:41.038935 |
| description | None |
| encrypted | False |
| id | 6c82f307-7489-43d5-98fc-00353c6ff479 |
| migration_status | None |
| multiattach | False |
| name | vcx_1 |
| properties | |
| replication_status | disabled |
| size | 50 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| type | None |
| updated_at | None |
| user_id | 70bcd75fd6bf4553a15fc84b2f5454b2 |
+---------------------+--------------------------------------+
10. Attach the datastore volume to the running instance by entering the openstack server add volume command.
This example shows how to add the datastore volume vcx_1 to the instance name ngVCX-A.
$ openstack server add volume ngVCX-A vcx_1
11. Restart the virtual machine.
12. Deploy the SteelHead-v appliance into the network.
See the “Deployment Options” section in the “Overview of SteelHead-v” chapter of the SteelHead (Virtual Edition) Installation Guide for more information.
Deleting an OpenStack instance
To delete an OpenStack instance, enter this command:
openstack server delete <instance-name>
For example, to delete the ngVCX-A instance created for the examples in this chapter, enter the openstack server delete ngVCX-A command.
Using a Heat template to deploy SteelHead-v appliances
OpenStack lets you create network interfaces between devices using the Neutron networking service. You use a Heat Orchestration Template (HOT) to create the required Neutron interfaces for devices in your network, including but not limited to the SteelHead-v appliances.
The Heat template is a YAML (YAML Ain’t Markup Language) file and has a file type of .yaml or .yml.
Heat template deployment guidelines
• SteelHead-v cabling guidelines - Cable your network so that all traffic passes through the SteelHead-v appliances for end-to-end connectivity. Cabling an alternative route might cause traffic to bypass the SteelHead-v appliances.
• Port security guidelines - Disable port security on all SteelHead LAN and WAN ports, all firewall or other security appliance ports, and the ports of any device that performs routing functions in your network. Alternatively, configure allowed IP pairs for the ports of all SteelHead, firewall, and routing devices. This configuration is required for any traffic that passes through an OpenStack virtual machine (VM) to a destination that is not on the VM.
By default, OpenStack enables port security and security groups. OpenStack’s port security is based on a Layer 2 MAC address, and security groups filter traffic based on a Layer 3 IP address and Layer 4 port number. When traffic passes through a device (such as a ping packet through a SteelHead), Layer 2 and Layer 3 packet headers are not modified, which could trigger port security and security group alerts.
Disabling port security at a port level allows the VM to send and receive traffic to and from any destination, which is the standard configuration for optimization or firewall devices.
• Routing guidelines - If you have any routes between trusted and untrusted sites that use Layer 2 addresses, delete those routes; otherwise, the network can have connectivity issues. Instead, allow OpenStack to use Address Resolution Protocol (ARP) to find Layer 2 destinations.
Heat template example
This example provides a networking environment for the LAN and WAN deployment shown in this figure.
Network diagram for sample Heat template
Sample Heat template .yaml file
heat_template_version: '2015-04-30'
description: |
Basic inpath setup.
branch_01 branch_02
lan wan WAN wan lan
10.0.1.0/24 10.0.99.0/24 10.0.2.0/24
client --- SteelHead --- Router ----- Router --- SteelHead --- client
10.0.1.10 10.0.1.250 10.0.1.1 10.0.2.1 10.0.2.250 10.0.2.10
10.0.99.11 10.0.99.12
All devices have their first interface on a mgmt network (10.0.0.0/24) with
an IP assigned by Neutron. Floating IPs are also allocated as a convenience.
SteelHeads also have an interface on an aux network (10.0.10.0/24)
parameters:
external_network:
type: string
description: External network for public IP.
constraints:
- custom_constraint: neutron.network
default: "public"
key_name:
type: string
description: An existing key pair to use for authentication to Client VMs
constraints:
- custom_constraint: nova.keypair
client_image:
type: string
description: >
Image to use for clients. This template assumes the image uses
predictable network naming (ens3, ens4, etc) and has cloud-init installed.
constraints:
- custom_constraint: glance.image
client_flavor:
type: string
description: Flavor to use for clients
constraints:
- custom_constraint: nova.flavor
default: "m1.small"
sh_image:
type: string
description: Image to use for SteelHeads
constraints:
- custom_constraint: glance.image
sh_flavor:
type: string
description: Flavor to use for SteelHeads
constraints:
- custom_constraint: nova.flavor
sh_datastore_size:
type: number
description: Datastore size of SteelHead
default: 50
resources:
#### Utility Networks
# mgmt: All devices get mgmt for remote access and configuration
mgmt_net:
type: OS::Neutron::Net
mgmt_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: mgmt_net }
cidr: 10.0.0.0/24
dns_nameservers:
- 8.8.8.8
# SteelHeads have aux interface
aux_net:
type: OS::Neutron::Net
aux_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: aux_net }
cidr: 10.0.10.0/24
# A WAN network between several provider edge routers.
wan:
type: OS::Neutron::Net
wan_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: wan }
cidr: 10.0.99.0/24
### Management router (for Internet and Floating IP access)
router_mgmt:
type: OS::Neutron::Router
properties:
external_gateway_info:
network: { get_param: external_network }
router_mgmt_interface:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: router_mgmt }
subnet: { get_resource: mgmt_subnet }
#### Branch 01
### LAN L3 segment is split into two L2 segments bridged by the SteelHead inpath:
# _lan for client instances
# _wan for the uplink to wan via a router
#
# In this topology's test networks, DHCP and gateway addresses are
# disabled; every device must be configured with static addresses and
# routes.
# The mgmt interfaces do use DHCP however.
#
branch_01_lan:
type: OS::Neutron::Net
branch_01_lan_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: branch_01_lan }
cidr: 10.0.1.0/24
gateway_ip: null
enable_dhcp: False
branch_01_wan:
type: OS::Neutron::Net
branch_01_wan_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: branch_01_wan }
cidr: { get_attr: [ branch_01_lan_subnet, cidr ] }
gateway_ip: null
enable_dhcp: False
### Client VM
client_branch_01_ens3:
type: OS::Neutron::Port
properties:
network_id: { get_resource: mgmt_net }
client_branch_01_ens4:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_01_lan }
fixed_ips:
- ip_address: 10.0.1.10
client_branch_01:
type: OS::Nova::Server
properties:
image: { get_param: client_image }
flavor: { get_param: client_flavor }
key_name: { get_param: key_name }
networks:
- port: { get_resource: client_branch_01_ens3 }
- port: { get_resource: client_branch_01_ens4 }
user_data_format: RAW
# Use cloud config to bring up ens4 with the correct IP and route.
# NB: This is not persistent across reboots; it will only apply
# on first boot.
user_data: |
#cloud-config
runcmd:
- ip link set ens4 up
- ip addr add 10.0.1.10/24 dev ens4
- ip route add 10.0.2.0/24 via 10.0.1.1
- ip route add 10.0.99.0/24 via 10.0.1.1
### SteelHead
steelhead_branch_01_primary:
type: OS::Neutron::Port
properties:
network_id: { get_resource: mgmt_net }
steelhead_branch_01_aux:
type: OS::Neutron::Port
properties:
network_id: { get_resource: aux_net }
steelhead_branch_01_lan0_0:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_01_lan }
fixed_ips:
- ip_address: 10.0.1.250
# The inpath interfaces pass through traffic from client VMs
# without modifying the src/dst MAC address. OpenStack Neutron
# port security always enables rules to prevent MAC address
# spoofing, so port security must be disabled for inpath
# interfaces.
port_security_enabled: False
steelhead_branch_01_wan0_0:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_01_wan }
fixed_ips:
- ip_address: { get_attr: [steelhead_branch_01_lan0_0, fixed_ips, 0, ip_address] }
# The inpath interfaces pass through traffic from client VMs
# without modifying the src/dst MAC address. OpenStack Neutron
# port security always enables rules to prevent MAC address
# spoofing, so port security must be disabled for inpath
# interfaces.
port_security_enabled: False
steelhead_branch_01:
type: OS::Nova::Server
properties:
image: { get_param: sh_image }
flavor: { get_param: sh_flavor }
# Steelhead networks must be primary, aux, lan, wan [, lan, wan, ...]
networks:
- port: { get_resource: steelhead_branch_01_primary }
- port: { get_resource: steelhead_branch_01_aux }
- port: { get_resource: steelhead_branch_01_lan0_0 }
- port: { get_resource: steelhead_branch_01_wan0_0 }
sh_branch_01_cinder_volume:
properties:
availability_zone: nova
size: {get_param: sh_datastore_size}
type: OS::Cinder::Volume
sh_branch_01_volume_attachment:
properties:
instance_uuid: {get_resource: steelhead_branch_01}
mountpoint: /dev/vdb
volume_id: {get_resource: sh_branch_01_cinder_volume}
type: OS::Cinder::VolumeAttachment
### Provider Edge Branch 01 Router
pe_branch_01_mgmt:
type: OS::Neutron::Port
properties:
network_id: { get_resource: mgmt_net }
pe_branch_01_branch:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_01_wan }
fixed_ips:
- ip_address: 10.0.1.1
# ARP packets may be sent on behalf of other addresses, which may get
# filtered by the implicit MAC + IP security rule. To avoid this,
# disable port security entirely. An alternative that would allow
# other security groups to be used on the routers that might work:
# allowed_address_pairs:
# - ip_address: 0.0.0.0/0
# NB. This isn't required for neutron routers, but setting it if the
# router is replaced by a VM based software router.
port_security_enabled: False
pe_branch_01_wan:
type: OS::Neutron::Port
properties:
network_id: { get_resource: wan }
fixed_ips:
- ip_address: 10.0.99.11
# ARP packets may be sent on behalf of other addresses, which may get
# filtered by the implicit MAC + IP security rule. To avoid this,
# disable port security entirely. An alternative that would allow
# other security groups to be used on the routers that might work:
# allowed_address_pairs:
# - ip_address: 0.0.0.0/0
# NB. This isn't required for neutron routers, but setting it if the
# router is replaced by a VM based software router.
port_security_enabled: False
# Note: This router is using the default Neutron implementation,
# but the template explicitly creates the ports so it can easily be
# switched out with a VM-based software router from another vendor.
# The below resources would be replaced with a OS::Nova::Server.
# For example:
# pe_branch_01:
# type: OS::Nova::Server
# properties:
# image: { get_param: router_image }
# flavor: { get_param: router_flavor }
# networks:
# - port: { get_resource: pe_branch_01_mgmt }
# - port: { get_resource: pe_branch_01_branch }
# - port: { get_resource: pe_branch_01_wan }
pe_branch_01:
type: OS::Neutron::Router
pe_branch_01_mgmt_int:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: pe_branch_01 }
port: { get_resource: pe_branch_01_mgmt }
pe_branch_01_branch_int:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: pe_branch_01 }
port: { get_resource: pe_branch_01_branch }
pe_branch_01_wan_int:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: pe_branch_01 }
port: { get_resource: pe_branch_01_wan }
# Next hop to Branch 02 is the wan side of pe_branch_02.
pe_branch_01_route_branch_02:
type: OS::Neutron::ExtraRoute
depends_on: pe_branch_01_wan_int
properties:
router_id: { get_resource: pe_branch_01 }
destination: { get_attr: [branch_02_lan_subnet, cidr] }
nexthop: { get_attr: [pe_branch_02_wan, fixed_ips, 0, ip_address] }
#### Branch 02
### LAN L3 segement is split into two L2 segments bridged by the SteelHead inpath:
# _lan for client instances
# _wan for the uplink to wan via a router
#
# In this topology's test networks, DHCP and gateway addresses are
# disabled, every device must be configured with static addresses and
# routes.
#
branch_02_lan:
type: OS::Neutron::Net
branch_02_lan_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: branch_02_lan }
cidr: 10.0.2.0/24
gateway_ip: null
enable_dhcp: False
branch_02_wan:
type: OS::Neutron::Net
branch_02_wan_subnet:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: branch_02_wan }
cidr: { get_attr: [ branch_02_lan_subnet, cidr ]}
gateway_ip: null
enable_dhcp: False
### Client VM
client_branch_02_ens3:
type: OS::Neutron::Port
properties:
network_id: { get_resource: mgmt_net }
client_branch_02_ens4:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_02_lan }
fixed_ips:
- ip_address: 10.0.2.10
client_branch_02:
type: OS::Nova::Server
properties:
image: { get_param: client_image }
flavor: { get_param: client_flavor }
key_name: { get_param: key_name }
networks:
- port: { get_resource: client_branch_02_ens3 }
- port: { get_resource: client_branch_02_ens4 }
user_data_format: RAW
# Use cloud config to bring up ens4 with the correct IP and route.
# NB: This is not persistent across reboots, will only apply on first boot.
user_data: |
#cloud-config
runcmd:
- ip link set ens4 up
- ip addr add 10.0.2.10/24 dev ens4
- ip route add 10.0.1.0/24 via 10.0.2.1
- ip route add 10.0.99.0/24 via 10.0.2.1
### SteelHead
steelhead_branch_02_primary:
type: OS::Neutron::Port
properties:
network_id: { get_resource: mgmt_net }
steelhead_branch_02_aux:
type: OS::Neutron::Port
properties:
network_id: { get_resource: aux_net }
steelhead_branch_02_lan0_0:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_02_lan }
fixed_ips:
- ip_address: 10.0.2.250
# The inpath interfaces pass through traffic from client VMs
# without modifying the src/dst MAC address. OpenStack Neutron
# port security always enables rules to prevent MAC address
# spoofing, so port security must be disabled for inpath
# interfaces.
port_security_enabled: False
steelhead_branch_02_wan0_0:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_02_wan }
fixed_ips:
- ip_address: { get_attr: [steelhead_branch_02_lan0_0, fixed_ips, 0, ip_address] }
# The inpath interfaces pass through traffic from client VMs
# without modifying the src/dst MAC address. OpenStack Neutron
# port security always enables rules to prevent MAC address
# spoofing, so port security must be disabled for inpath
# interfaces.
port_security_enabled: False
steelhead_branch_02:
type: OS::Nova::Server
properties:
image: { get_param: sh_image }
flavor: { get_param: sh_flavor }
# Steelhead networks must be primary, aux, lan, wan.
networks:
- port: { get_resource: steelhead_branch_02_primary }
- port: { get_resource: steelhead_branch_02_aux }
- port: { get_resource: steelhead_branch_02_lan0_0 }
- port: { get_resource: steelhead_branch_02_wan0_0 }
sh_branch_02_cinder_volume:
properties:
availability_zone: nova
size: {get_param: sh_datastore_size}
type: OS::Cinder::Volume
sh_branch_02_volume_attachment:
properties:
instance_uuid: {get_resource: steelhead_branch_02}
mountpoint: /dev/vdb
volume_id: {get_resource: sh_branch_02_cinder_volume}
type: OS::Cinder::VolumeAttachment
#### Provider Edge Branch 02 Router
pe_branch_02_mgmt:
type: OS::Neutron::Port
properties:
network_id: { get_resource: mgmt_net }
pe_branch_02_branch:
type: OS::Neutron::Port
properties:
network_id: { get_resource: branch_02_wan }
fixed_ips:
- ip_address: 10.0.2.1
# ARP packets may be sent on behalf of other addresses, which may get
# filtered by the implicit MAC + IP security rule. To avoid this,
# disable port security entirely. An alternative that would allow
# other security groups to be used on the routers that might work:
# allowed_address_pairs:
# - ip_address: 0.0.0.0/0
# NB. This isn't required for neutron routers, but setting it if the
# router is replaced by a VM based software router.
port_security_enabled: False
pe_branch_02_wan:
type: OS::Neutron::Port
properties:
network_id: { get_resource: wan }
fixed_ips:
- ip_address: 10.0.99.12
# ARP packets may be sent on behalf of other addresses, which may get
# filtered by the implicit MAC + IP security rule. To avoid this,
# disable port security entirely. An alternative that would allow
# other security groups to be used on the routers that might work:
# allowed_address_pairs:
# - ip_address: 0.0.0.0/0
# NB. This isn't required for neutron routers, but setting it if the
# router is replaced by a VM based software router.
port_security_enabled: False
pe_branch_02:
type: OS::Neutron::Router
pe_branch_02_mgmt_int:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: pe_branch_02 }
port: { get_resource: pe_branch_02_mgmt }
pe_branch_02_branch_int:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: pe_branch_02 }
port: { get_resource: pe_branch_02_branch }
pe_branch_02_wan_int:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: pe_branch_02 }
port: { get_resource: pe_branch_02_wan }
pe_branch_02_route_branch_01:
type: OS::Neutron::ExtraRoute
depends_on: pe_branch_02_wan_int
properties:
router_id: { get_resource: pe_branch_02 }
destination: { get_attr: [branch_01_lan_subnet, cidr] }
nexthop: { get_attr: [pe_branch_01_wan, fixed_ips, 0, ip_address] }
#### Floating IPs
client_branch_01_ip:
type: OS::Neutron::FloatingIP
depends_on:
- router_mgmt_interface
properties:
floating_network: { get_param: external_network }
port_id: { get_resource: client_branch_01_ens3 }
client_branch_02_ip:
type: OS::Neutron::FloatingIP
depends_on:
- router_mgmt_interface
properties:
floating_network: { get_param: external_network }
port_id: { get_resource: client_branch_02_ens3 }
steelhead_branch_01_ip:
type: OS::Neutron::FloatingIP
depends_on:
- router_mgmt_interface
properties:
floating_network: { get_param: external_network }
port_id: { get_resource: steelhead_branch_01_primary }
steelhead_branch_02_ip:
type: OS::Neutron::FloatingIP
depends_on:
- router_mgmt_interface
properties:
floating_network: { get_param: external_network }
port_id: { get_resource: steelhead_branch_02_primary }
Creating an OpenStack stack from a Heat template
To create an OpenStack stack from a Heat template, enter this command, where <heat_template.yaml> is the name of Heat template and <stack_name> is the name of the stack to create.
openstack stack create -t <heat_template.yaml> <stack_name>
Deleting an OpenStack stack created by a Heat template
To delete an OpenStack stack created by a Heat template, first delete the VMs (servers) associated with the SteelHead-v appliances in the Heat template.
Use these commands to delete an OpenStack stack created by a Heat template, where <steelhead_name> is the name of the SteelHead (virtual edition) appliance and <stack_name> is the name of the stack to delete.
openstack server delete <steelhead_name>
openstack stack delete <stack_name>
If there are multiple SteelHead (virtual edition) appliances in the Heat template, delete them all before deleting the stack.
Creating OpenStack flavors: CLI examples
This example shows how to create OpenStack flavors for VCX10 through VCX90 models.
$ openstack flavor create --public vcx10 --id auto --ram 2048 --disk 20 --vcpus 1 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 20 |
| id | f763d2db-cf11-40f9-9b57-002801e79621 |
| name | vcx10 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 2048 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 1 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx20 --id auto --ram 2048 --disk 20 --vcpus 1 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 20 |
| id | ab0de064-3c42-497f-9e1f-921d210e29cc |
| name | vcx20 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 2048 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 1 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx30 --id auto --ram 2048 --disk 20 --vcpus 1 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 20 |
| id | a25f7ff7-3055-49c7-b2b2-6c1f6bf763b6 |
| name | vcx30 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 2048 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 1 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx40 --id auto --ram 4096 --disk 20 --vcpus 2 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 20 |
| id | e38834a0-b424-4dcc-a9ea-70c7d6167af8 |
| name | vcx40 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 4096 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 2 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx50 --id auto --ram 8192 --disk 38 --vcpus 4 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 38 |
| id | 2674952a-84d0-4942-9e80-08b51b5a8342 |
| name | vcx50 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 8192 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 4 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx60 --id auto --ram 8192 --disk 38 --vcpus 4 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 38 |
| id | 8a73bd53-d52c-4788-845e-80b72019816a |
| name | vcx60 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 8192 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 4 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx70 --id auto --ram 24576 --disk 70 --vcpus 6 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 70 |
| id | 7e583004-0914-481c-971f-4e0dc59fb9e7 |
| name | vcx70 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 24576 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 6 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx80 --id auto --ram 32768 --disk 86 --vcpus 12 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 86 |
| id | f58a60d4-42d5-4b6d-bd0e-3f7f4cefcdcd |
| name | vcx80 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 32768 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 12 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx90 --id auto --ram 49152 --disk 118 --vcpus 24 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 118 |
| id | 80d3ee37-c13c-40e3-8ca1-972bd70f0ba6 |
| name | vcx90 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 49152 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 24 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx90 --id auto --ram 65536 --disk 160 --vcpus 32 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 118 |
| id | 80d3ee37-c13c-40e3-8ca1-972bd70f0ba6 |
| name | vcx90 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 49152 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 24 |
+----------------------------+--------------------------------------+
$ openstack flavor create --public vcx90 --id auto --ram 131072 --disk 300 --vcpus 44 --rxtx-factor 1
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 118 |
| id | 80d3ee37-c13c-40e3-8ca1-972bd70f0ba6 |
| name | vcx90 |
| os-flavor-access:is_public | True |
| properties | |
| ram | 49152 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 24 |
+----------------------------+--------------------------------------+