Red Hat OpenShift Container Platform

Creating a secondary network attachment with the CNI VRF plugin

The Cluster Network Operator (CNO) manages secondary network definitions. When you specify a secondary network in the cluster-scoped Network custom resource (CR), the CNO automatically creates the NetworkAttachmentDefinition CR.

Do not edit the NetworkAttachmentDefinition CRs that the Cluster Network Operator manages. Doing so might disrupt network traffic on your secondary network.

Prerequisites

Install the OpenShift CLI (oc).
Log in to the cluster as a user with cluster-admin privileges.

Procedure

Create the Network CR for the additional network attachment and insert the rawCNIConfig configuration for the secondary network. Save as the additional-network-attachment.yaml file.
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
    - name: test-network-1
      namespace: additional-network-1
      type: Raw
      rawCNIConfig: '{
        "cniVersion": "0.3.1",
        "name": "macvlan-vrf",
        "plugins": [
        {
          "type": "macvlan",
          "master": "eth1",
          "ipam": {
              "type": "static",
              "addresses": [
              {
                  "address": "191.168.1.23/24"
              }
              ]
          }
        },
        {
          "type": "vrf",
          "vrfname": "vrf-1",
          "table": 1001
        }]
      }'
```
where:

plugins

You must specify a list. The first item in the list must be the secondary network underpinning the VRF network. The second item in the list is the VRF plugin configuration.

type

You must set this parameter to vrf.

vrfname

The name of the VRF that the interface is assigned to. If the VRF does not exist in the pod, the CNI creates the VRF.

table

Optional parameter. Specify the routing table ID. By default, the tableid parameter is used. If you do not specify a table ID, the CNI assigns a free routing table ID to the VRF.

VRF functions correctly only when the resource is of type netdevice.

Create the Network resource:

$ oc create -f additional-network-attachment.yaml

Confirm that the CNO created the NetworkAttachmentDefinition CR by running the following command. Replace <namespace> with the namespace that you specified when configuring the network attachment, for example, additional-network-1. The expected output shows the name of the NAD CR and the creation age in minutes.
```
$ oc get network-attachment-definitions -n <namespace>
```
A delay might exist before the CNO creates the CR.

Verification

Create a pod and assign the pod to the secondary network that includes the VRF plugin configuration.
1. Create a YAML file that defines the Pod resource, as demonstrated in the following pod-additional-net.yaml file:
  apiVersion: v1 kind: Pod metadata: name: pod-additional-net annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "test-network-1" } ]' spec: containers: - name: example-pod-1 command: ["/bin/bash", "-c", "sleep 9000000"] image: centos:8
  where:
  
  name
  
  Specify the name of the secondary network that includes the VRF plugin configuration.
2. Create the Pod resource by running the following command. The expected output shows the name of the Pod resource and the creation age in minutes.
  $ oc create -f pod-additional-net.yaml
Verify that the pod network attachment connects to the VRF secondary network. Start a remote session with the pod and run the following command. The expected output shows the name of the VRF interface and its unique ID in the routing table.
```
$ ip vrf show
```
Confirm that the VRF interface is the controller for the secondary interface by entering the following command:
```
$ ip link
```
```
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
```