Workflow user guide¶
Workflows are automation process algorithms. They describe the flow of the automation by determining which tasks to run and when to run these tasks. A task is an operation (implemented by a plugin), or other actions including running arbitrary code. Workflows are written in Python, using a dedicated framework and APIs.
In this guide you will learn:
- How to execute workflows and for what workflows are used.
- Which workflows you can run for which deployment types.
- Which workflows to run for specific scenarios such as:
- Move service layers
- Upgrade BIG-IP VEs for a VNF group
- Post auto-heal process
- Manually trigger Heal or Scale workflow from Nagios
- Promote the secondary BIG-IQ during an HA-pair failover
- Update CGNAT address pool with more IP space
- Attach additional BIG-IP VE syslog configuration file to a deployment
- Add tmsh/bash commands to existing deployments
Execute workflows¶
For the main solution blueprint you deployed, you must run the Install workflow first. Once your blueprint installs, you will see multiple deployments created automatically. The list of workflows will change and display only applicable workflows that you can run for each deployment/blueprint type.
Click Deployments, and next to the main Gilan deployment (for example), click
.
Expand the Gilan option (where applicable), select the Install workflow, and optionally, you can select the following options:
- Force - enable this option to force the workflow execution even if other workflows are executing simultaneously. You cannot run this options with Queue.
- Queue - enable this option to run this workflow automatically at the next possible opportunity.
- Schedule - enable this option to run this workflow at a defined date and time (required format, YYY:MM:DD:HH:mm). You cannot run this options with Queue.
- - enable this option to run this workflow without actually running any operations. The operations will be logged without side effects. You cannot use this option with Queue.
Tip
For some workflows, like Uninstall, you can click Load Value to upload a YAML file with execution parameters and complete the form automatically.
Click Execute. Once your install workflow completes, you will see a list of auto-created deployments which have workflows applicable to those deployments. The following table describes ALL the available VNFM workflows; however, this list will change depending upon the deployment node for which you are executing the workflow:
Workflow | Run on deployment types | Used for |
---|---|---|
Generate report | Gi-LAN, Gi-Firewall, DNS, and DNS Security VNF Service | Creating a resource-throughput usage report to send to F5 for billing purposes. Parameter includes full_historical_report a boolean value that when set to true will generate a full report (generating data beyond the default of the previous 180 days). |
Heal | DAG, DNS, worker, layer instances, and vnfd_cgnat_offering_ve | Healing failing DAG instances, worker (follower) instances, main instances, and entire layers, by creating a new copy of the reported, dysfunctional instance or layer
without dropping existing traffic (or packets). If you enabled CGNAT, the heal layer workflow will also check the address list of the previous (failing) device,
merge with the AS3 configuration, and then send the configuration to the new device in the layer. This workflow will create a new copy of the reported,
dysfunctional instance on CGNAT layer. NOTE: The new copy of CGNAT instance will have the same cgnat_ip_list as the corrupted instance.
To recover resources from the dysfunctional DAG layer, run the post auto-heal process, which will release the original resources (for example, CPUs, memory, and disk space). |
Install | ALL deployment types | Installing the target deployment, and lifecycle operations on instances (for example, create and configure start). |
Uninstall | ALL deployment types | Uninstalling the target deployment, freeing allocated resources, and performing uninstall lifecycle operations (for example, stop and delete). This workflow also removes deployments and blueprints created during the Install workflow. Parameter includes ignore_failure, which when enabled (set to true) will continue the workflow upon a failed lifecycle operation. |
Purge | VNF_layer, DNS_layer, dns_security_layer, VNF, vnfd_dag instances, and CGNAT_layer | Uninstalling and removing dysfunctional worker (follower) and main VNF, CGNAT layer instances, VNF VE instances, and DNS DAG instances. Start this workflow manually, after the heal layer workflow runs and the problem investigation is finished. Parameter includes ignore failure passed to lifecycle uninstall process (see the following Uninstall workflow). IMPORTANT: For vSphere ONLY, when running the Purge workflow on a main node or a worker (follower) node you MUST enable the ignore_failure flag (set to true). If this ignore_failure flag is NOT enabled for main or worker nodes, then the Purge workflow will fail. For VNFM 2.0.2 and later the default value for this ignore_failure flag is set to enable (true). |
Scale In | vnf_layer, vnf_group, dag_group, CGNAT-Offering, dns_group, dns_layer dns_security_layer, dns_security_group | Removing and uninstalling DAG group, adding VEs and the VNF group, adding layers. This workflow finds instances to remove (based on parameters) and uninstalls and removes all specified instances and all related instances. Parameters include:
Failed execution can already have partially removed some resources from external systems and removed instances. In this case, execute the workflow again with ignore_failure flag set to true. You must check the VIM and other external systems for leftover, reserved resources. |
Scale Out | vnf_layer, vnf_group dag_group, dns_group, dns_security_group, vnf_layer, vnf_ve_slave, dns_layer, dns_security_layer, CGNAT_layer, and cgnat_offering_layer | Adding DAG group VE instances, VNF group, and CGNAT layer instances. Parameter includes add instances, which is the number of new instance VEs to create. When scaling out VNF_groups and the dns_security_group deployment types, the add_instances value is the number of new layers you want to add to the group. If failure occurs due to scaling limits, this does not affect the service. Other failed executions can be a result of resources already reserved to create instances. In this case, remove the failed instance by running the Gilan scale in group workflow [gilan_scale_in_group] and providing the failed (instance id)[instances]. Creating and installing worker (follower) nodes to new VNF layer. Parameter includes add instances, which is the number of managed, VNF worker (follower) VEs to add to the target deployment. If failure occurs due to scaling limits, this does not affect the service. Other failed executions can be a result of resources already reserved to create instances. In this case, remove the failed instance by running the Gilan scale in layer workflow and providing the failed (instance id)[instances]. For the cgnat_offering_layer type, this workflow will add instances to the CGNAT layer. If run manually, you can define how many machines to add to the layer. All machines are installed simultaneously, and instances are not waiting for each other. The number of CGNAT machines on the layer appears in the cgnat_instance_count parameter. |
Update declaration | VNF_NSD, NSD_DNS, and NSD_SEC_DNS | Updating the new JSON encoded AS 3 declaration, Telemetry declaration, or syslog configuration pushed to the VE as a part of NSD definition. Run this workflow after editing any of those declarations in your NSD definition and uploading your changed, main-solution, blueprint inputs file. |
Upgrade | All dag_groups, dns_groups, dns_security_groups, CGNAT_group, and all vnf_groups | Enabling the roll-out of a new version of BIG IP in the DNS group, DAG group, CGNAT group, and VNF group. Creating new DNS/DAG/VNF/CGNAT groups of VEs using new software reference data. Workflow selects older VEs with lesser revision value and disables them. Parameter includes instance count, which is the number of instances (DNS VEs) to upgrade. |
Upgrade Start | vnf_group, dns_dag_group, dns_group, dag_group, CGNAT_group, and dns_security_group | Starting the upgrade process and setting new software reference data for both DAG group, CGNAT group, and VNF group. You must provide the revision number and software reference details (image id, flavor) for the hypervisor. The revision number is used during the VNF Layer upgrade process. Parameters include JSON encoded dictionary containing definition of new software:
Example: |
Upgrade Finish | vnf_group, dns_dag_group, dns_group, dag_group, dns_security_group, and CGNAT_group | Finishing the upgrade process for DAG group, CGNAT group, and VNF group, using the new software reference data to install scaled and healed VEs, as well as other normal operations. Parameter includes ignore_revision_check a boolean value that when set to true, will ignore the revision values assigned to running instances. |
Configuration update | DO NOT RUN this workflow on any deployment type. | You DO NOT RUN this workflow manually. This workflow is part of the install, upgrade, scale, and heal workflow automation that updates the DAG pool membership with a worker (follower) node. Use the Update declaration workflow for VNF_NSD, NSD_DNS, and NSD_SEC_DNS deployment types to change the configuration. |
Admin state disable | VNF_layer, dns_layer, and dns_security_layer | Executing this manually on a VNF layer you want to eventually deprecate. This workflow stops new traffic connections (bleeds traffic) on a layer and diverts that traffic to other layers in the data center. For example, you run this workflow in conjunction with the Scale Out and Scale workflows when moving service layers from one data center to another. |
Update member | VNFD_VNF, DNS, and DNS_Security | Updating the DAG pool membership of a worker (follower) during a heal workflow. Parameters include:
For example, to disable a member, set adminState to disable, enable to false, and servicePort to 0. |
Deregister | VNF_slave, DNS_slave, DNS_security_slave, and vnfd_cgnat_offering_ve | Executing on a worker node to remove it from the DAG group and manually fail over the traffic to another DAG group. Deregister workflow causes the CGNAT VE to stop listening on 0.0.0.0; however, the machine is NOT turned off, but rather will not process traffic. The Deregistered status will appear in the Deployment Outputs and logs. If you run this workflow repeatedly, you will get a message stating the VE is already deregistered. This workflow is an automated process in the Heal and Upgrade workflows. |
Register | vnfd_cgnat_offering_ve | Executing the register workflow causes CGNAT VE to start listening on 0.0.0.0. However it will not start this machine, but it will enable the machine to process traffic. The Registered status will appear in Deployment Outputs and logs. If you run this workflow repeatedly, you will get a message stating the VE is already registered. |
Promote | BIG-IQ only | Executing on the BIG-IQ configuration deployment to promote the secondary BIG-IQ in an HA pair, when the primary BIG-IQ fails. Currently, if your VNFM fails to license a BIG-IP, VNFM will display a failure. You must run this workflow manually to promote the secondary BIG-IQ to take over for the failed, primary BIG-IQ. |
Increment IPs (proxy) | VNFD, DNS, DNS_Security, NSD deployments vnfd_cgnat_offering_ve, and nsd_cgnat_offering | Loading more IP addresses on the appropriate VNF/DNS/NSD VE, or execute Increment IPs Proxy. The workflow will add more IP addresses on the appropriate CGNAT VE. This workflow requires no defined parameters. Execute this workflow to increment the IP addresses in the allotment you defined in the inputs file (increment_ip_number). After this workflow, cgnat_ip_list will update in Deployment Outputs, which stores the currently used list by CGNAT VE. You cannot start this workflow for nsd_cgnat_offering nodes manually, it only runs automatically, as manual startup is blocked. |
Enable cgnat | Gi-LAN, Gi-Firewall, NSD_VNF | Executing on the main deployment or executing the Enable cgnat on a single nsd deployment when you have NOT enabled CGNAT prior to installing your blueprint solution. IMPORTANT: You must first edit your AS3 declaration (policyNAT) for enabling CGNAT, execute the Update as 3 workflow, before executing the Enable CGNAT workflow, and defining the following parameters:
|
Update cgnat IPs | Gi-LAN, Gi-Firewall, and CGNAT-Offering | Adding more free IP addresses to the CGNAT. Parameters include the list of IP ranges using JSON format; for example, ‘192.168.1.100-192.168.1.150’ If IP addresses are already in use, the workflow will fail with a duplicate key value error message. If the IP addresses are entered incorrectly, the workflow will fail with an invalid range format error message. In the ip_range_list text box, click Switch to Text View, and then enter the IP range using the required format. |
Syslog Configuration | Gi-LAN, Gi-Firewall, DNS, DNS_Security, and CGNAT-Offering | Running this workflow after editing the syslog_config input for a deployment, will attach an additional BIG-IP VE syslog configuration file to that deployment. Caution: ONLY use this workflow with assistance from F5 Technical Support.
Parameters include defining whether to include syslog configuration information for your DAG layer and/or VNFM. Valid entries include true or false . |
Update | Gi-LAN, Gi-Firewall, DNS, DNS_Security, and CGNAT-Offering | Run this workflow to update the deployment input values for an existing blueprint deployment. You must uninstall and reinstall the blueprint deployment after changing inputs for that deployment. You can set Actions to take upon this updated deployment automatically, like enabling/disabling the auto-running of Install/Uninstall workflows on this specific node instance. You can set to auto-run the Install workflow first. You can enable/disable ignoring failures during the Uninstall workflow, and enable/disable the auto-running of Reinstall workflow. |
- You can cancel deployments at anytime by clicking the X in the
popup workflow notification.
- Learn more about which workflows you can run for which deployment types and for specific use case scenarios.
Workflow scenarios¶
The following scenarios are examples of manually running specific workflows:
Move a layer to a new data center¶
In this example, a telco has two service areas (SA-1 and SA-2). Service demand has dictated that SA-2 requires more capacity than SA-1. The telco has purchased two 10GB-layers in each SA (layers 1 and layers 2) for a total of four layers. Therefore, in order to increase capacity in one SA-2, first stand up a new (temporary) layer in SA-2, and then bring down a service layer in SA-1. F5 VNFM enables customers to have more layers than originally purchased for a 48-hour grace period. Therefore, this capacity move to a new SA must occur within 48 hours to avoid being charged for the fifth (in this example), additional (temporary) layer in SA-2.
To move a layer from SA-1 to SA-2, manually run the following workflows:
- Scale Out (SA-2)
- Admin state disable (SA-1)
- Scale In (SA-1)
In VNF Manager for the SA-2 where capacity requirements increase, click the Deployments blade, click the VNF Group deployment (for example, vnf_group), at the top of the window click Execute workflow, and then select Scale Out from the list.
On the Execute workflow scale_out popup window, in the add_instances text box, enter the number of new instances you want to add to this group. Default value is 1.
The scale out workflow stands up a new (fifth) layer in SA-2 where capacity demand has increased.
Currently, you have five layers. 48 hours before bringing down a layer in SA-1, click the Deployments blade, click the VNF_layer deployment to bring down (layer 2), at the top of the window click Execute workflow, and then select Admin state disable from the list.
This workflow bleeds new traffic from the VNF layer 2, preventing all new traffic connections, and diverts all new traffic to layer 1 in SA-1. Keep this layer in Admin state disable for approximately 40 hours, allowing all existing connections on layer 2 to finish before bringing down that layer.
Near the 48-hour threshold, in SA-1, click the Deployments blade, click the VNF_layer deployment to bring down (layer 2), at the top of the window click Execute workflow, and then select Scale In from the list.
On the Execute workflow scale_in popup window, to assign a specific layer or worker (follower), in the deployment_id text box, enter the deployment ID for the VNF layer/worker (follower) you are scaling-in, and leave all other default values. You can find this deployment ID at the top of the VNF layer/worker (follower) deployment page:
This workflow destroys layer 2 in data center-1 where the capacity need has decreased. Now you have one layer in data center-1 and three layers in data center-2, returning to your originally purchased, four-layer capacity.
Important
To avoid purchasing more capacity than your original purchase, coordinate the timing of your layer deprecation, so your additional (fifth) layer in SA-2 (in step 1) does NOT exceed the 48-hour grace period.
Upgrade BIG-IP VEs in a VNF group¶
Consult the following video to help you upgrade your BIG-IP VEs. Be aware that the version of VNFM used in this video may not match the version you are currently using; however, the steps are the same.
You can upgrade both VNF and DAG groups. In this example, you will upgrade your BIG-IPs in your VNF group from version BIGIP-13.1.0.5 to version BIGIP-13.1.0.7. Manually upgrading involves executing the following workflows:
- Upgrade Start
- Upgrade
- Admin state disable
- Scale in
- Upgrade Finish

Important
PREREQUISITES:
In your VIM project (for example, OpenStack), you must upload the new BIG-IP image (for example, BIGIP-13.1.0.5 or 14.1.4.6) to which you are upgrading PRIOR to performing this workflow scenario. For supported versions of BIG-IP VE, point your browser to BIG-IP 13.1.0.X or BIG-IP 14.1.X F5 downloads site.
This upgrade process makes a copy of the VNF group being upgraded (including all layers); therefore, you must have sufficient vCPU and storage capacity to temporarily sustain two VNF groups. Otherwise, your upgrade workflow will fail.
Tip
If you lack the required resources in the service area being upgraded, you can utilize the 48-hour grace period for deploying extra layers and avoid failure by temporarily scaling out layers in another service area, and then scaling in layers in the VNF group being upgraded. After the upgrade completes, you can redistribute the VNF layers amongst the service areas, accordingly. See the previous workflow scenario for complete steps.
In VNF Manager, click the Deployments blade, click the VNF_group deployment you want to upgrade, at the top of the window click Execute workflow, and then click Upgrade Start.
On the Execute workflow upgrade_start popup window, in the data text box, enter the dictionary parameters (in JSON format) for the VNF group you want to upgrade using the image ID for the new image to which you want to upgrade (for example, BIGIP-13.1.0.7-0.0.1.ALL_1SLOT). The image value is case-sensitive and must match the image name as entered in your VIM project.
You can find this dictionary in YAML format in your inputs file, for example in OpenStack:
sw_ref_vnf: data: image: BIGIP-13.1.0.7-0.0.1.ALL_1SLOT flavor: m1.xlarge availability_zone: nova
Convert the previous YAML dictionary to JSON format, for example:
{ "image": "BIGIP-13.1.0.7-0.0.1.ALL_1SLOT", "flavor":"m1.xlarge", "availability_zone":"nova" }
In the revision text box, increment that value by at least 1, leave all other default values, and then click Execute.
This workflow defines the image which to upgrade the selected group. To verify the status of this workflow, click the VNF_group deployment, and scroll down to the Deployment Executions pane and in the Upgrade Start workflow row, the status column should display, Complete.
In VNF Manager, click the Deployments blade, click the VNF_group deployment you want to upgrade, at the top of the window click Execute workflow, and then click Upgrade.
On the Execute workflow upgrade popup window, in the deployment_id text box enter the deployment ID of the layer you want to upgrade. To find the layer ID, on the Deployments blade, click the VNF_layer being upgraded and at the top of the page, copy the ID.
This workflow creates a copy of the group and all layers within that group, running the new version of the BIG-IP image defined in step 2. To verify the status of this workflow, click the VNF_group deployment, and scroll down to the Deployment Executions pane and in the Upgrade workflow row, the status column should display, Complete.
Important
At this point you will want to leave both VNF layers running, to verify that the upgraded copy is running successfully. The duration will vary depending upon your organization’s standard operating procedures. If you experience problems with the upgraded layer, you can rollback the upgrade by running the Admin state disable workflow (see next step) on the new, upgraded copy of the VNF layer.
In VNF Manager, click the Deployments blade, click the VNF_layer you are upgrading, at the top of the window click Execute workflow, and then click Admin state disable.
Tip
To find the layer ID of the old layer you are scaling in, click the Deployments blade, click the VNF_group being upgraded, scroll down to the Nodes pane, click the layer_id row, and the old layer will appear first in the list. Using the first layer ID in the list, on the Deployments blade search for the layer ID. Click that layer and at the top of the window, copy that ID.
This workflow bleeds new traffic off the older VNF group being upgraded and moves new traffic to the newly upgraded copy of the VNF group. Allow enough time for existing transactions to complete, before executing the Scale In workflow (step 7). To verify the status of this workflow, click the VNF_layer deployment, and scroll down to the Deployment Executions pane and in the Admin state disabled workflow row, the status column should display, Complete.
To scale in the old VNF layer, on the Deployments blade, click the old VNF group (running the old version of BIG-IP), at the top of the window click Execute workflow, select Scale In, enter the deployment_id for the old layer using the following format, and then click Scale In.
["gilanTestUG_vnf_group_f00jl8_vnf_layer_90ew6m_layer_id_q5dm8i"]
Tip
To find the layer ID of the old layer you are scaling in, click the Deployments blade, click the VNF_group being upgraded, scroll down to the Nodes pane, click the layer_id row, and the old layer will appear first in the list. Using the first layer ID in the list, on the Deployments blade search for the layer ID. Click that layer and at the top of the window, copy that ID.
This workflow destroys the old layer running the old version of BIG-IP. Now you have one upgraded layer, running the new version of BIG-IP. To verify the status of this workflow, click the VNF_layer deployment, and scroll down to the Deployment Executions pane and in the Scale In workflow row, the status column should display, Complete.
In VNF Manager, click the Deployments blade, click the VNF_group deployment you are upgrading, at the top of the window click Execute workflow, and then click Upgrade Finish.
On the Execute workflow upgrade_finish popup window, leave all other default values, and then click Execute.
This workflow clears the upgrade definition form you completed in Step 1, the Upgrade Start workflow. To verify the status of this workflow, click the VNF_group deployment, and scroll down to the Deployment Executions pane and in the Upgrade Finish workflow row, the status column should display, Complete.
Post auto-heal process¶
If deploying the Gi LAN or Gi-Firewall blueprint, the Heal workflow will run automatically on a VNF layer, DAG layer, or worker (follower) deployment, when nodes become non-responsive or lose connectivity with the VNF main node.
When a heal workflow runs automatically, the heal started indicator will appear on the Deployments blade, in the VNF_layer/slave_ID deployment type row:
You can also see when the heal workflow runs automatically on the
pane:On the Deployments blade, find the worker (follower) or the layer deployment that was healed, click the healed deployment to open it, and then scroll down to the Nodes pane.
In the Nodes pane, click the ve row, and if the heal ran successfully, you will see two worker/layer instances listed; the old and the new instance.
To purge the old instance, scroll to the top of the Deployment page, click Execute workflow, and then select Purge from the list.
Important
For vSphere ONLY, when running the Purge workflow on a main node or a worker (follower) node you MUST enable the ignore_failure flag (set to true). If this flag is NOT enabled for main or worker nodes, then the Purge workflow will fail. For VNFM 2.0.2 and later, the default value for this ignore_failure flag is set to enable (true).
On the popup menu, leave all default values, and click Execute. This workflow will bleed (like Admin State Disable) traffic off the old instance, removing it from the layer, leaving you with only the new instance.
Manually trigger Heal or Scale workflow from Nagios¶
F5 VNF Manager uses the Nagios component to monitor the various other components of the F5 NFV Solutions. Nagios determines if a component has failed, or if the current resources have breached their configured thresholds, and requires scaling out of more resources. Nagios exercises the Heal and or Scale workflows whenever its monitors are triggered, by sending REST calls to the F5 VNF Manager API that manages the solution. The F5 VNF Manager responds by running the required workflows and either heals or scales the appropriate components.
Use this procedure in the event that the F5 VNF Manager fails, and is restored using a clone or snapshot. These steps will clear any alarms or error conditions in the Nagios component of the F5 NFV solutions you have deployed, after you have fully recovered and restored the F5 VNF Manager. This process will re-trigger any Heal or Scale workflow on the VNF Manager that may have been triggered by Nagios, while the VNF Manager was offline.
Important
You MUST successfully restore the F5 VNF Manager from the latest snapshot BEFORE executing this procedure!
Connect to the Nagios Component
- Login to the F5 VNF Manager UI.
- Click the Deployments blade.
- In the Deployments list, click the Nagios component deployment that was created for the deployed F5 NFV solution blueprint.
- Scroll to the Deployment OutputsCapabilities pane, and then for the
http_endpoint
key, copy the URL value. - Paste this URL into a browser window.
- When prompted for the Nagios login credentials, use the values defined in the following secrets:
- nagiosrest_user
- nagiosrest_pass
Determine if there are any failures
- After logging into the Nagios component, in the left-hand menu under the Current Status section, click the Hosts link. This page displays alerts or alarms you must address at this time.
- If all alerts/alarms appear Green, then you can log out of the Nagios component. If you need to re-trigger a workflow, do the following procedure.
Manually re-trigger the REST Call
- In the Hosts column, click the Host name.
- In the Host Commands menu, select the Send custom host notification link.
- On the right-side of the custom host notification form, enter a comment in the text box to record your reason for sending this event REST call.
- Click Commit to send the event REST Call and initiate the F5 VNF Manager workflow.
- Return to the F5 VNF Manager UI and monitor the logs to make sure the proper workflow starts and finishes, successfully.
Promote the secondary BIG-IQ during an HA-pair failover¶
If you deploy the BIG-IQ blueprint in an HA pair and your primary BIG-IQ falters, then you can promote the secondary BIG-IQ to manage the BIG-IP devices. Do the following to promote and fail over the management of resources and service layers:
On the Deployments blade, click the BIG-IQ deployment, at the top of the window click Execute Workflow, and then select Promote.
Once the promote workflow completes, click the BIG-IQ deployment, click Execute workflow, and then select Update from the list.
This workflow updates the mgmt IP address assigned to the BIG-IQ deployments. If the primary BIG-IQ fails, then both the primary and secondary deployments become standalone deployments, destroying the HA-pair. The secondary BIG-IQ takes the mgmt IP address of the failed primary BIG-IQ.
Update CGNAT address pool with more IP space¶
When you enabled CGNAT, you defined an address pool with ranges of IP addresses your system will use during orchestration. When you approach the exhaustion threshold of those defined address ranges, you can update the address pool with additional IP space using the Update cgnat IP workflow.
Tip
To set up an alert to notify you when your system approaches the exhaustion threshold value (for example, 80% of addresses used), then use the REST API to poll the VNFM input value for this threshold value.
- On the Deployments blade, click the main Gi-LAN, Firewall, or CGNT-Offering deployment, scroll to the top of the Deployment page, click Execute workflow, and then select Update cgnat IP from the list.
- On the popup menu, enter the CGNAT IP range using JSON format; for example, ‘192.168.1.100-192.168.1.150’ and ‘192.168.1.155-192.168.1.160’.
- Click Execute.
Attach additional BIG-IP VE syslog configuration file to a deployment¶
You can run this workflow for attaching an additional BIG-IP VE syslog configuration file to any of the blueprint solutions EXCEPT the VNF Base solution.
Caution: ONLY use this workflow with assistance from F5 Technical Support.
On the Deployments blade, click any main blueprint (EXCEPT VNF Base), scroll to the top of the Deployment page, click Execute workflow, and then select Syslog configuration from the list.
On the popup menu, complete the following parameters, and then click Execute:
- In the include_dags textbox, define whether to include syslog configuration information for your DAG layers. Valid entries include
true
orfalse
. - In the syslog_config textbox, enter a valid BIG-IP VE syslog configuration; for example,
destination remote_server {tcp("10.10.10.13" port (514));}; filter f_alllogs {level (debug...emerg);}; log {source(local);filter(f_alllogs); destination(remote_server);};
. - In the include_vnfms textbox, define whether to include syslog configuration information for your VNF Manager. Valid entries include,
true
orfalse
.
- In the include_dags textbox, define whether to include syslog configuration information for your DAG layers. Valid entries include
Click Execute.
Add tmsh/bash commands to existing deployments¶
Execute the Update Declaration workflow, if you need to add configuration commands to existing blueprint deployments
beyond AS3 or REST. You can add tmsh/bash commands to any NSD deployment type. For a complete list of acceptable values, consult
the additional_commands
input definition in the Inputs reference guide.
On the Deployments blade, click any NSD deployment type, scroll to the top of the Deployment page, click Execute workflow, and then select Update Declaration from the list.
In the Parameters dialog box, click Load Values, browse for a
.YAML
file with your execution parameters to automatically complete the form, or manually define the following:Tip
Values are casted to types; for example, [1, 2] is casted to an array and 524 is casted to a number. Surround values with ” quotes to explicitly declare it as a string; for example,
"{"a":"b"}"
is sent as string, NOT an object, and “true” is sent as string, NOT a boolean value. Use “” for an empty string.In the payload text box, enter the tmsh/bash commands that you want to execute on the blueprint solution using JSON format; for example:
["self_ip_control_net=$(tmsh list net self control_net_self address | grep address | awk -F' ' '{print $2}'|awk -F'/' '{print $1}') && echo Self ip of control_net interface is $self_ip_control_net"]
In the type text box, enter CLI.
Click Execute.
These commands will execute AFTER the AS3 declaration, during deployment installation on an NSD node. Find the command results in the deployment logs, labeled with update_declaration workflow type.
Tip
You can update your AS3 declaration using this same procedure, substituting your updated AS3 configuration in the payload text box and entering AS3 in the type text box.
What’s Next?