Verification and Testing
Ensure the EDA rulebook activation is running in the aap namespace, the
Automation Controller is accessible, and the Apstra blueprint is deployed with the correct
name matching apstra_blueprint_name in vars/main.yml
file.
Sample YAML files are available at https://github.com/Juniper/eda-apstra-project/tree/main/tests.
Expected AAP Job Sequence
See Table 1 for information on the expected AAP job sequence.
Table 1: Expected AAP Job Sequence Step OpenShift Object Applied AAP Job Template Triggered Expected Result 1 SR-IOV Node Policies (none — no EDA trigger) Policies synced across nodes 2 Project (with type=edalabel)create-vrfRouting Zone created in Apstra 3 SriovNetwork (with type=edalabel)create-vnetVirtual Network created in Apstra 4 Deployment/Pod (on SR-IOV network) create-connectivity-templateConnectivity Template created and node port mapped
Create a Project (Routing Zone/VRF)
The Project object must carry the type=eda label and an
apstra.juniper.net/vrf annotation listing the VRF name(s) to create in
Apstra.
# project.yaml
apiVersion: project.openshift.io/v1
kind: Project
metadata:
name: <namespace>
labels:
type: eda
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/audit: privileged
pod-security.kubernetes.io/warn: privileged
security.openshift.io/scc.podSecurityLabelSync: "false"
annotations:
apstra.juniper.net/vrf: '[
{
"vrfName": "<vrf-name>"
}
]'oc apply -f project.yaml
Verify that the create-vrf job is triggered and succeeds in Automation
Controller, and that the Routing Zone appears in Apstra under the configured blueprint.
Create SR-IOV Networks (Virtual Networks/VNETS)
Each SR-IOV Network must carry the type=eda label, the
pfname label (physical function interface name), and an
apstra.juniper.net/vnet annotation.
# sriov-vn1.yaml
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: sriovnet-<vnet-name>
namespace: openshift-sriov-network-operator
labels:
type: eda
pfname: <interface-name>
annotations:
apstra.juniper.net/vnet: '[
{
"vnetName": "<vnet-name>",
"vrfName": "<vrf-name>"
}
]'
spec:
ipam: |
{
"type": "host-local",
"subnet": "<subnet-cidr>",
"rangeStart": "<ip-range-start>",
"rangeEnd": "<ip-range-end>",
"gateway": "<gateway-ip>",
"routes": [
{
"dst": "<other-subnet-cidr>",
"gw": "<gateway-ip>"
}
]
}
networkNamespace: <namespace>
resourceName: <interface-name>_vfs
vlan: <vlan-id>oc apply -f sriov-vn1.yaml oc apply -f sriov-vn2.yaml
Deploy SR-IOV Workloads (Connectivity Templates)
Deploy pods or deployments that request SR-IOV resources. The deployment must:
- Carry
type=edalabel andapstra.juniper.net/epannotation - Request the correct SR-IOV resource via
openshift.io/<resourceName> - Use
nodeSelectorto pin pods to a node where the interface has an LLDP neighbor on an Apstra-managed leaf switch
Important: Before you deploy, verify that the target node's SR-IOV interface has LLDP neighbors:
oc get NodeNetworkState <node-name> -o yaml | grep -A5 "neighbors"
If the interface shows no LLDP neighbors, select a different node or interface. Deploying
on an interface with no LLDP neighbors will cause the
create-connectivity-template job to fail.
# deployment-vn1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: vn1-deployment
namespace: <namespace>
labels:
type: eda
vnet: <vnet-name>
spec:
replicas: 1
selector:
matchLabels:
type: eda
vnet: <vnet-name>
template:
metadata:
name: vn1-deployment
labels:
type: eda
vnet: <vnet-name>
annotations:
apstra.juniper.net/ep: '[{"vnetName": "<vnet-name>"}]'
k8s.v1.cni.cncf.io/networks: '[
{
"name": "sriovnet-<vnet-name>",
"namespace": "<namespace>",
"interface": "ext0"
}
]'
spec:
containers:
- name: iperf3
image: centos/tools
command: ["/bin/bash", "-c", "--"]
args: ["while true; do sleep 300000; done;"]Tip: If your cluster has some worker nodes without LLDP neighbors on Apstra-managed leaf
switches, add a nodeSelector under spec to pin the pod to
a known-good node:
spec:
nodeSelector:
kubernetes.io/hostname: <worker-node-name>Test cross-network connectivity (VNET1 pod to VNET2 pod):
# Get the ext0 IP of the vn2 pod oc exec -n <namespace> <vn2-pod-name> -- ip addr show ext0 # Ping from vn1 pod to vn2 pod's ext0 IP oc exec -n <namespace> <vn1-pod-name> -- ping -c 4 <vn2-ext0-ip>
Successful pings confirm that:
- SR-IOV virtual functions are correctly allocated
- VLANs and VNETs are configured in the Apstra fabric
- Connectivity templates are routing traffic between the virtual networks