Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Appendix - Service Chaining 1.0 alternate API instructions

Use alternate API-based steps to deploy Nutanix Service Chaining 1.0 when UI-based steps cannot complete every task.

Please Note:

It is highly recommended to do these steps via the Prism Central UI. These instructions are shared as an appendix and were the original required method. Since Nutanix now allows this to be done in the PC UI, it is much simpler to just do it there unless you want to fully automate deployment processes programmatically in your environment.

vSensor Deployment Step 3 Alternate API Instructions

This is an alternative API based approach to 3. Create network function provider category and value.

In this section we will create the network function provider category, assign a value to the category, and then verify that assignment. This is done using v3 API calls against your Prism Central server. Some things to note:

Step 3.1 - Create the network_function_provider category

PUT - https://{{pc_ip}}:9440/api/nutanix/v3/categories/network_function_provider

Body:

{ 
    "name": "network_function_provider" 
}

Response Example:

Description is an optional value that can be added similarly to how name was done in the above body):

{
     "system_defined": false,
     "name": "network_function_provider",
     "description": null
 }

Step 3.2 - Assign a value to the category we just created

Body:

Response Example:

In the above example, vectra_vsensor was chosen but this can be any name you desire. It is suggested that the name be the vendor’s name or application name of the network function VM.

Step 3.3 - Verify the category and value for the network_function_provider

Body:

Response Example:

In this response example there are two network_function_provider categories, firewall and vectra_vsensor. Your environment may have multiple categories in use already or none, in our example we are using vectra_vsensor .

vSensor Deployment Step 4 Alternate API Instructions

In order to create a network function chain in the next step, we first need to retrieve the name and UUID of the AHV cluster where you will deploy the vSensor and network function chain. This is NOT your Prism Central server.

Body:

Abbreviated response example:

vSensor Deployment Step 6 Alternate API Instructions

This is an alternative API based approach to the later parts of 6. Update the Powered off VM Using Both the ACLI and Prism Central UI.

Step 6.2 - Get the UUID of the network function VM (vSensor)

Step 6.3 - GET all values for all parameters of the network function VM (vSensor)

Any REST API call that updates an existing entity requires that you perform a GET on the value before updating it to retrieve the most current value of the spec. Failure to get the most recent spec before an update will lead to failed tasks in Prism Central.

In our demo example, the vSensor we are using is vSensor-Demo so we will make the API call for that VM UUID with an empty body. The response example is an abbreviated response and only includes the spec portion of the response. This spec portion of the response will need to be modified to be used as the body of the PUT API call in the next step. See step 6.4 below for more details.

Abbreviated response example (already modified to be the body of the PUT in the next step):

Please Note:

The initial get is not expected to return a value under categories.

Step 6.4 - Add the network function provider category and value to the vSensor VM specifications.

Only the spec and metadata portions of the response from step 6.3 are shown below. The metadata section needs to be modified to add the network function provider category and value to the VM specification near the bottom of the response.

Please Note:

Copy both the spec and metadata and modify only the metadata portion of the repsonse from step 6.3. Do not copy any of the other response sections. If the format is not set correctly then the API call will fail to execute, and you may get a 422 “Additional properties are not allowed…” error message.

We modified the metadata portion of the response above by adding the following category and value that we created earlier:

Then we use the PUT below with the PC API to add this to the VM specification of the network function VM (vSensor).

Body:

Use the spec and modified metadata portions of the response from step 6.3 as the body.

Abbreviated response example (we are only showing that it is PENDING and you can check the task status):

vSensor Deployment Step 7 Alternate API Instructions

This is an alternative API based approach to 7. Direct Traffic to the Configured Network Function Chain. These instructions were the original required method but remain if you want to fully automate deployment processes programmatically in your environment.

Step 7.1 - List Available Networks (Subnets)

In this step we will obtain the UUID of a subnet that should be directed through the network function chain.

Please Note:

The Prism Central v3 api defaults to returning a maximum of 20 results unless the body or the request is modified to include length and offset parameters which can also be used to paginate results. Our example below does not include these parameters and just uses a default query.

  • Up to 500 subnet entities (0-499 for example) can be retrieved by a single query by using a length of 500 and an offset of 0.

  • total_matches will also return the total number of subnets available.

  • The Prism Central UI can also show the total number of subnets:

  • Nutanix provides more detail about how these parameters work, along with examples in this KB article.

Body:

Response Example:

Our example contains only one default-subnet entity, but customer deployments will typically have many subnets. Find the UUIDs for all subnets that you wish to have mapped to the network function chain. Each node in the cluster will forward traffic they see on these subnets to the vSensor VMs.

Step 7.2 - Get the Subnet Details Using the Retrieved UUID

Use an empty body in your request.

Response Example:

Step 7.3 - Update the Subnet to Reference the Network Function Chain

The spec and metadata portions (highlighted above) of the response from step 7.2 need to be copied, modified, and then used as the body of the PUT in this step to update the subnet to point to the network function chain. It is suggested to use an API client that enforces proper json formatting to make the modifications. Some options were given Guidance for using the Nutanix Prism Central REST API. Note that an extra brace needed to be added to the body at the bottom after copying from above.

The spec portion of the response you copied must be modified to include the NFC reference. This should be done within the resources section of the spec portion of the body.

Body:

Response example:

PreviousTraffic capture and validationNextVMware Brain

Last updated

Was this helpful?