You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Consult the following references after you deploy your cluster to improve its performance:
46
46
** xref:../../networking/hardware_networks/using-dpdk-and-rdma.adoc#nw-openstack-ovs-dpdk-testpmd-pod_using-dpdk-and-rdma[A test pod template for clusters that use OVS-DPDK on OpenStack].
47
-
** xref:../../networking/hardware_networks/add-pod.adoc#nw-openstack-sr-iov-testpmd-pod_add-pod[A test pod template for clusters that use SR-IOV on OpenStack].
47
+
** xref:../../networking/hardware_networks/configuring-sriov-device.adoc#nw-openstack-sr-iov-testpmd-pod_configuring-sriov-device[A test pod template for clusters that use SR-IOV on OpenStack].
48
48
** xref:../../scalability_and_performance/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#installation-openstack-ovs-dpdk-performance-profile_cnf-low-latency-perf-profile[A performance profile template for clusters that use OVS-DPDK on OpenStack]
== Creating an additional SR-IOV network attachment with the CNI VRF plugin
22
-
23
-
The SR-IOV Network Operator manages additional network definitions. When you specify an additional SR-IOV network to create, the SR-IOV Network Operator creates the `NetworkAttachmentDefinition` custom resource (CR) automatically.
24
-
25
-
[NOTE]
26
-
====
27
-
Do not edit `NetworkAttachmentDefinition` custom resources that the SR-IOV Network Operator manages. Doing so might disrupt network traffic on your additional network.
28
-
====
29
-
30
-
To create an additional SR-IOV network attachment with the CNI VRF plugin, perform the following procedure.
31
-
32
-
.Prerequisites
33
-
34
-
* Install the {product-title} CLI (oc).
35
-
* Log in to the {product-title} cluster as a user with cluster-admin privileges.
36
-
37
-
.Procedure
38
-
39
-
. Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`.
40
-
+
41
-
[source,yaml]
42
-
----
43
-
apiVersion: sriovnetwork.openshift.io/v1
44
-
kind: SriovNetwork
45
-
metadata:
46
-
name: example-network
47
-
namespace: additional-sriov-network-1
48
-
spec:
49
-
ipam: |
50
-
{
51
-
"type": "host-local",
52
-
"subnet": "10.56.217.0/24",
53
-
"rangeStart": "10.56.217.171",
54
-
"rangeEnd": "10.56.217.181",
55
-
"routes": [{
56
-
"dst": "0.0.0.0/0"
57
-
}],
58
-
"gateway": "10.56.217.1"
59
-
}
60
-
vlan: 0
61
-
resourceName: intelnics
62
-
metaPlugins : |
63
-
{
64
-
"type": "vrf", <1>
65
-
"vrfname": "example-vrf-name" <2>
66
-
}
67
-
----
68
-
<1> `type` must be set to `vrf`.
69
-
<2> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created.
70
-
71
-
. Create the `SriovNetwork` resource:
72
-
+
73
-
[source,terminal]
74
-
----
75
-
$ oc create -f sriov-network-attachment.yaml
76
-
----
77
-
78
-
.Verifying that the `NetworkAttachmentDefinition` CR is successfully created
79
-
80
-
* Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command.
81
-
+
82
-
[source,terminal]
83
-
----
84
-
$ oc get network-attachment-definitions -n <namespace> <1>
85
-
----
86
-
<1> Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`.
87
-
+
88
-
.Example output
89
-
[source,terminal]
90
-
----
91
-
NAME AGE
92
-
additional-sriov-network-1 14m
93
-
----
94
-
+
95
-
[NOTE]
96
-
====
97
-
There might be a delay before the SR-IOV Network Operator creates the CR.
98
-
====
99
-
100
-
.Verifying that the additional SR-IOV network attachment is successful
101
-
102
-
To verify that the VRF CNI is correctly configured and the additional SR-IOV network attachment is attached, do the following:
103
-
104
-
. Create an SR-IOV network that uses the VRF CNI.
105
-
. Assign the network to a pod.
106
-
. Verify that the pod network attachment is connected to the SR-IOV additional network. Remote shell into the pod and run the following command:
107
-
+
108
-
[source,terminal]
109
-
----
110
-
$ ip vrf show
111
-
----
112
-
+
113
-
.Example output
114
-
[source,terminal]
115
-
----
116
-
Name Table
117
-
-----------------------
118
-
red 10
119
-
----
120
-
. Confirm the VRF interface is master of the secondary interface:
121
-
+
122
-
[source,terminal]
123
-
----
124
-
$ ip link
125
-
----
126
-
+
127
-
.Example output
128
-
[source,terminal]
129
-
----
130
-
...
131
-
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
= Creating an additional SR-IOV network attachment with the CNI VRF plugin
8
+
9
+
The SR-IOV Network Operator manages additional network definitions. When you specify an additional SR-IOV network to create, the SR-IOV Network Operator creates the `NetworkAttachmentDefinition` custom resource (CR) automatically.
10
+
11
+
[NOTE]
12
+
====
13
+
Do not edit `NetworkAttachmentDefinition` custom resources that the SR-IOV Network Operator manages. Doing so might disrupt network traffic on your additional network.
14
+
====
15
+
16
+
To create an additional SR-IOV network attachment with the CNI VRF plugin, perform the following procedure.
17
+
18
+
.Prerequisites
19
+
20
+
* Install the {product-title} CLI (oc).
21
+
* Log in to the {product-title} cluster as a user with cluster-admin privileges.
22
+
23
+
.Procedure
24
+
25
+
. Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`.
26
+
+
27
+
.Example `SriovNetwork` custom resource (CR) example
28
+
[source,yaml]
29
+
----
30
+
apiVersion: sriovnetwork.openshift.io/v1
31
+
kind: SriovNetwork
32
+
metadata:
33
+
name: example-network
34
+
namespace: additional-sriov-network-1
35
+
spec:
36
+
ipam: |
37
+
{
38
+
"type": "host-local",
39
+
"subnet": "10.56.217.0/24",
40
+
"rangeStart": "10.56.217.171",
41
+
"rangeEnd": "10.56.217.181",
42
+
"routes": [{
43
+
"dst": "0.0.0.0/0"
44
+
}],
45
+
"gateway": "10.56.217.1"
46
+
}
47
+
vlan: 0
48
+
resourceName: intelnics
49
+
metaPlugins : |
50
+
{
51
+
"type": "vrf", <1>
52
+
"vrfname": "example-vrf-name" <2>
53
+
}
54
+
----
55
+
<1> `type` must be set to `vrf`.
56
+
<2> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created.
57
+
58
+
. Create the `SriovNetwork` resource:
59
+
+
60
+
[source,terminal]
61
+
----
62
+
$ oc create -f sriov-network-attachment.yaml
63
+
----
64
+
65
+
.Verifying that the `NetworkAttachmentDefinition` CR is successfully created
66
+
67
+
* Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command:
68
+
+
69
+
[source,terminal]
70
+
----
71
+
$ oc get network-attachment-definitions -n <namespace> <1>
72
+
----
73
+
<1> Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`.
74
+
+
75
+
.Example output
76
+
[source,terminal]
77
+
----
78
+
NAME AGE
79
+
additional-sriov-network-1 14m
80
+
----
81
+
+
82
+
[NOTE]
83
+
====
84
+
There might be a delay before the SR-IOV Network Operator creates the CR.
85
+
====
86
+
87
+
.Verifying that the additional SR-IOV network attachment is successful
88
+
89
+
To verify that the VRF CNI is correctly configured and that the additional SR-IOV network attachment is attached, do the following:
90
+
91
+
. Create an SR-IOV network that uses the VRF CNI.
92
+
. Assign the network to a pod.
93
+
. Verify that the pod network attachment is connected to the SR-IOV additional network. Remote shell into the pod and run the following command:
94
+
+
95
+
[source,terminal]
96
+
----
97
+
$ ip vrf show
98
+
----
99
+
+
100
+
.Example output
101
+
[source,terminal]
102
+
----
103
+
Name Table
104
+
-----------------------
105
+
red 10
106
+
----
107
+
. Confirm that the VRF interface is `master` of the secondary interface by running the following command:
108
+
+
109
+
[source,terminal]
110
+
----
111
+
$ ip link
112
+
----
113
+
+
114
+
.Example output
115
+
[source,terminal]
116
+
----
117
+
...
118
+
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
= Configuration of IP address assignment for an additional network
14
+
= Configuration of IP address assignment for a network attachment
19
15
20
16
For additional networks, IP addresses can be assigned using an IP Address Management (IPAM) CNI plugin, which supports various assignment methods, including Dynamic Host Configuration Protocol (DHCP) and static assignment.
21
17
@@ -39,8 +35,7 @@ Use the Whereabouts CNI plugin when there is no external DHCP server or where st
39
35
A DHCP lease must be periodically renewed throughout the container's lifetime, so a separate daemon, the DHCP IPAM CNI Daemon, is required. To deploy the DHCP IPAM CNI daemon, modify the Cluster Network Operator (CNO) configuration to trigger the deployment of this daemon as part of the additional network setup.
40
36
41
37
////
42
-
IMPORTANT: If you set the `type` parameter to the `DHCP` value, you cannot set
43
-
any other parameters.
38
+
IMPORTANT: If you set the `type` parameter to the `DHCP` value, you cannot set any other parameters.
44
39
////
45
40
46
41
[id="nw-multus-static_{context}"]
@@ -143,16 +138,12 @@ such as `example-host`, during a DNS lookup query.
143
138
[id="nw-multus-dhcp_{context}"]
144
139
== Dynamic IP address (DHCP) assignment configuration
145
140
146
-
The following JSON describes the configuration for dynamic IP address address assignment with DHCP.
141
+
A pod obtains its original DHCP lease when it is created. The lease must be periodically renewed by a minimal DHCP server deployment running on the cluster.
147
142
148
-
.Renewal of DHCP leases
149
143
[IMPORTANT]
150
144
====
151
-
A pod obtains its original DHCP lease when it is created. The lease must be periodically renewed by a minimal DHCP server deployment running on the cluster.
152
-
153
-
ifdef::sr-iov[]
154
-
The SR-IOV Network Operator does not create a DHCP server deployment; The Cluster Network Operator is responsible for creating the minimal DHCP server deployment.
155
-
endif::sr-iov[]
145
+
For an Ethernet network attachment, the SR-IOV Network Operator does not create a DHCP server deployment; the Cluster Network Operator is responsible for creating the minimal DHCP server deployment.
146
+
====
156
147
157
148
To trigger the deployment of the DHCP server, you must create a shim network attachment by editing the Cluster Network Operator configuration, as in the following example:
158
149
@@ -179,7 +170,8 @@ spec:
179
170
}
180
171
# ...
181
172
----
182
-
====
173
+
174
+
The following table describes the configuration parameters for dynamic IP address address assignment with DHCP.
183
175
184
176
.`ipam` DHCP configuration object
185
177
[cols=".^2,.^2,.^6",options="header"]
@@ -192,6 +184,8 @@ spec:
192
184
193
185
|====
194
186
187
+
The following JSON example describes the configuration p for dynamic IP address address assignment with DHCP.
188
+
195
189
.Dynamic IP address (DHCP) assignment configuration example
196
190
[source,json]
197
191
----
@@ -287,7 +281,3 @@ The following example shows a dynamic IP address assignment that uses overlappin
287
281
}
288
282
----
289
283
<1> Optional. If set, must match the `network_name` of `NetworkAttachmentDefinition 1`.
0 commit comments