Skip to content

Commit a10f936

Browse files
rohennesrohennes
committed
TELCODOCS-1508: Doc improvements from SME feedback
1 parent c46afd5 commit a10f936

File tree

2 files changed

+87
-49
lines changed

2 files changed

+87
-49
lines changed

‎modules/cnf-assigning-a-secondary-network-to-a-vrf.adoc

Lines changed: 68 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -2,22 +2,9 @@
22
//
33
// networking/multiple_networks/assigning-a-secondary-network-to-a-vrf.adoc
44

5-
65
:_mod-docs-content-type: PROCEDURE
7-
[id="cnf-assigning-a-secondary-network-to-a-vrf_{context}"]
8-
= Assigning a secondary network to a VRF
9-
10-
As a cluster administrator, you can configure an additional network for your VRF domain by using the CNI VRF plugin. The virtual network created by this plugin is associated with a physical interface that you specify.
11-
12-
[NOTE]
13-
====
14-
Applications that use VRFs need to bind to a specific device. The common usage is to use the `SO_BINDTODEVICE` option for a socket. `SO_BINDTODEVICE` binds the socket to a device that is specified in the passed interface name, for example, `eth1`. To use `SO_BINDTODEVICE`, the application must have `CAP_NET_RAW` capabilities.
15-
16-
Using a VRF through the `ip vrf exec` command is not supported in {product-title} pods. To use VRF, bind applications directly to the VRF interface.
17-
====
18-
196
[id="cnf-creating-an-additional-network-attachment-with-the-cni-vrf-plug-in_{context}"]
20-
== Creating an additional network attachment with the CNI VRF plugin
7+
= Creating an additional network attachment with the CNI VRF plugin
218

229
The Cluster Network Operator (CNO) manages additional network definitions. When you specify an additional network to create, the CNO creates the `NetworkAttachmentDefinition` custom resource (CR) automatically.
2310

@@ -43,33 +30,33 @@ apiVersion: operator.openshift.io/v1
4330
kind: Network
4431
metadata:
4532
name: cluster
46-
spec:
33+
spec:
4734
additionalNetworks:
48-
- name: test-network-1
49-
namespace: additional-network-1
50-
type: Raw
51-
rawCNIConfig: '{
52-
"cniVersion": "0.3.1",
53-
"name": "macvlan-vrf",
54-
"plugins": [ <1>
55-
{
56-
"type": "macvlan", <2>
57-
"master": "eth1",
58-
"ipam": {
59-
"type": "static",
60-
"addresses": [
61-
{
62-
"address": "191.168.1.23/24"
63-
}
64-
]
65-
}
66-
},
67-
{
68-
"type": "vrf",
69-
"vrfname": "example-vrf-name", <3>
70-
"table": 1001 <4>
71-
}]
72-
}'
35+
- name: test-network-1
36+
namespace: additional-network-1
37+
type: Raw
38+
rawCNIConfig: '{
39+
"cniVersion": "0.3.1",
40+
"name": "macvlan-vrf",
41+
"plugins": [ <1>
42+
{
43+
"type": "macvlan",
44+
"master": "eth1",
45+
"ipam": {
46+
"type": "static",
47+
"addresses": [
48+
{
49+
"address": "191.168.1.23/24"
50+
}
51+
]
52+
}
53+
},
54+
{
55+
"type": "vrf", <2>
56+
"vrfname": "vrf-1", <3>
57+
"table": 1001 <4>
58+
}]
59+
}'
7360
----
7461
<1> `plugins` must be 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.
7562
<2> `type` must be set to `vrf`.
@@ -107,36 +94,68 @@ additional-network-1 14m
10794
There might be a delay before the CNO creates the CR.
10895
====
10996

110-
.Verifying that the additional VRF network attachment is successful
97+
.Verification
98+
99+
. Create a pod and assign it to the additional network with the VRF instance:
111100

112-
To verify that the VRF CNI is correctly configured and the additional network attachment is attached, do the following:
101+
.. Create a YAML file that defines the `Pod` resource:
102+
+
103+
.Example `pod-additional-net.yaml` file
104+
[source,yaml]
105+
----
106+
apiVersion: v1
107+
kind: Pod
108+
metadata:
109+
name: pod-additional-net
110+
annotations:
111+
k8s.v1.cni.cncf.io/networks: '[
112+
{
113+
"name": "test-network-1" <1>
114+
}
115+
]'
116+
spec:
117+
containers:
118+
- name: example-pod-1
119+
command: ["/bin/bash", "-c", "sleep 9000000"]
120+
image: centos:8
121+
----
122+
<1> Specify the name of the additional network with the VRF instance.
123+
124+
.. Create the `Pod` resource by running the following command:
125+
+
126+
[source,terminal]
127+
----
128+
$ oc create -f pod-additional-net.yaml
129+
----
130+
+
131+
.Example output
132+
[source,terminal]
133+
----
134+
pod/test-pod created
135+
----
113136

114-
. Create a network that uses the VRF CNI.
115-
. Assign the network to a pod.
116-
. Verify that the pod network attachment is connected to the VRF additional network. Remote shell into the pod and run the following command:
137+
. Verify that the pod network attachment is connected to the VRF additional network. Start a remote session with the pod and run the following command:
117138
+
118139
[source,terminal]
119140
----
120141
$ ip vrf show
121142
----
122143
+
123144
.Example output
124-
+
125145
[source,terminal]
126146
----
127147
Name Table
128148
-----------------------
129-
red 10
149+
vrf-1 1001
130150
----
131-
. Confirm the VRF interface is master of the secondary interface:
151+
. Confirm that the VRF interface is the controller for the additional interface:
132152
+
133153
[source,terminal]
134154
----
135155
$ ip link
136156
----
137157
+
138158
.Example output
139-
+
140159
[source,terminal]
141160
----
142161
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

‎networking/multiple_networks/assigning-a-secondary-network-to-a-vrf.adoc

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,4 +6,23 @@ include::_attributes/common-attributes.adoc[]
66

77
toc::[]
88

9+
As a cluster administrator, you can configure an additional 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.
10+
11+
Using a secondary network with a VRF instance has the following advantages:
12+
13+
Workload isolation:: Isolate workload traffic by configuring a VRF instance for the additional network.
14+
Improved security:: Enable improved security through isolated network paths in the VRF domain.
15+
Multi-tenancy support:: Support multi-tenancy through network segmentation with a unique routing table in the VRF domain for each tenant.
16+
17+
[NOTE]
18+
====
19+
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.
20+
21+
Using a VRF through the `ip vrf exec` command is not supported in {product-title} pods. To use VRF, bind applications directly to the VRF interface.
22+
====
23+
24+
[role="_additional-resources"]
25+
.Additional resources
26+
* xref:../../networking/multiple_networks/about-virtual-routing-and-forwarding.adoc#cnf-about-virtual-routing-and-forwarding_about-virtual-routing-and-forwarding[About virtual routing and forwarding]
27+
928
include::modules/cnf-assigning-a-secondary-network-to-a-vrf.adoc[leveloffset=+1]

0 commit comments

Comments
 (0)