Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 5. Assigning a secondary network to a VRF


As a cluster administrator, you can configure a secondary network for a virtual routing and forwarding (VRF) domain by using the CNI VRF plugin. The virtual network that this plugin creates is associated with the physical interface that you specify.

Using a secondary network with a VRF instance has the following advantages:

Workload isolation
Isolate workload traffic by configuring a VRF instance for the secondary network.
Improved security
Enable improved security through isolated network paths in the VRF domain.
Multi-tenancy support
Support multi-tenancy through network segmentation with a unique routing table in the VRF domain for each tenant.
Note

Applications that use VRFs must bind to a specific device. The common usage is to use the SO_BINDTODEVICE option for a socket. The SO_BINDTODEVICE option binds the socket to the device that is specified in the passed interface name, for example, eth1. To use the SO_BINDTODEVICE option, the application must have CAP_NET_RAW capabilities.

Using a VRF through the ip vrf exec command is not supported in OpenShift Container Platform pods. To use VRF, bind applications directly to the VRF interface.

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.

Note

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

  1. 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
            }]
          }'
    Copy to Clipboard Toggle word wrap

    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.

    Note

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

  2. Create the Network resource:

    $ oc create -f additional-network-attachment.yaml
    Copy to Clipboard Toggle word wrap
  3. 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>
    Copy to Clipboard Toggle word wrap
    Note

    A delay might exist before the CNO creates the CR.

Verification

  1. 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" 
      1
      
             }
       ]'
      spec:
       containers:
       - name: example-pod-1
         command: ["/bin/bash", "-c", "sleep 9000000"]
         image: centos:8
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap
  3. Confirm that the VRF interface is the controller for the secondary interface by entering the following command:

    $ ip link
    Copy to Clipboard Toggle word wrap
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat