Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Decision Automation

Prerequisites

Before configuring SR-IOV nodes, verify that the Kubernetes NMState Operator and the SR-IOV Network Operator are installed and running in your cluster.

  1. Verify the Kubernetes NMState Operator:

    Here is the expected output:

    All nmstate-handler-* pods must show Running. One handler pod runs on each node.

  2. Verify the SR-IOV Network Operator:

    Here is the expected output:

    The network-resources-injector-* and operator-webhook-* pods must show Running.

    If either operator is not installed, refer to the Required OpenShift Operatorsin this section and install them before continuing.

Configure SR-IOV Nodes

Follow these steps to use NMState to enable LLDP on your SR-IOV nodes:

  1. Identify the SR-IOV interfaces on each worker node (the interfaces connected to Apstra-managed leaf switches). Create and apply a NodeNetworkConfigurationPolicy YAML file with those interface names:
  2. Verify LLDP neighbors are visible. Issue the following command and confirm that the leaf switch neighbors appear under each interface:

    Here is the expected output:

    Note:

    Only interfaces that show LLDP neighbors connected to Apstra-managed leaf switches can be used for SR-IOV virtual networks and connectivity templates. Pods deployed on interfaces without LLDP neighbors will cause the create-connectivity-template automation job to fail. Verify per-node LLDP connectivity before proceeding.

  3. Apply an SR-IOV Network Node Policy.
    1. Create an SR-IOV network node policy to specify the SR-IOV network device configuration. The API object for the policy is part of the sriovnetwork.openshift.io API group.

    2. Create a separate policy YAML file for each SR-IOV physical function (interface) you want to expose as virtual functions. Use the following template:

    3. Replace <interface-name> with the actual interface name (for example: ens801f1). The resourceName will be used when requesting SR-IOV resources in pod/deployment specs (for example: openshift.io/ens801f1_vfs).

    4. Apply the policy:

    5. Apply the policy:

    6. Verify the policy is applied and synced across nodes:

    7. Wait until the syncStatus shows Succeeded for all worker nodes before proceeding.

      See Configuring an SR-IOV Network Device for detailed information on each field in the SR-IOV network node policy.

Mappings of OpenShift Objects with Apstra Objects

Here are the mappimgs of OpenShift with Apstra Objects:

Table 1: Mappings of OpenShift Objects with Apstra Objects
OpenShift Object Apstra Object Description

Project

Routing Zones (VRF)

Creating/Deleting a project will create Routing Zones (VRF) in Apstra.

SriovNetwork

Virtual Networks (VNET)

Creating/Deleting a SriovNetwork will create Virtual Networks( VNET) in Apstra.

Pod

Connectivity Template

Creating of VNET creates connectivity template automatically in Apstra. The pod is mapped to the respective nodes and ports in the connectivity templates dynamically.