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
== Additional configuration details for a UserDefinedNetworks CR
8
+
9
+
The following table explains additional configurations for UDN that are optional. It is not recommended to set these fields without explicit need and understanding of OVN-Kubernetes network topology.
10
+
11
+
.`UserDefinedNetworks` optional configurations
12
+
[cols="1,1,7", options="header"]
13
+
|====
14
+
15
+
|Field|Type|Description
16
+
17
+
|`spec.joinSubnets`
18
+
|object
19
+
|When omitted, the platform sets default values for the `joinSubnets` field of `100.65.0.0/16` for IPv4 and `fd99::/64` for IPv6. If the default address values are used anywhere in the cluster's network you must override it by setting the `joinSubnets` field. If you choose to set this field, ensure it does not conflict with other subnets in the cluster such as the cluster subnet, the `default` network cluster subnet, and the masquerade subnet.
20
+
21
+
The `joinSubnets` field configures the routing between different segments within a user-defined network. Dual-stack clusters can set 2 subnets, one for each IP family; otherwise, only 1 subnet is allowed. This field is only allowed for the `Primary` network.
22
+
23
+
|`spec.IPAMLifecycle`
24
+
|object
25
+
|The `IPAMLifecycle` field configures the IP address management system (IPAM). You might use this field for virtual workloads to ensure persistent IP addresses. This field is allowed when `topology` is `layer2`. The `subnets` field must be specified when this field is specified. Setting a value of `Persistent` ensures that your virtual workloads have persistent IP addresses across reboots and migration. These are assigned by the container network interface (CNI) and used by OVN-Kubernetes to program pod IP addresses. You must not change this for pod annotations.
26
+
27
+
|`spec.layer2.mtu` and `spec.layer3.mtu`
28
+
|integer
29
+
|The maximum transmission units (MTU). The default value is `1400`. The boundary for IPv4 is `574`, and for IPv6 it is `1280`.
Copy file name to clipboardExpand all lines: modules/nw-udn-best-practices.adoc
+8-7Lines changed: 8 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -15,17 +15,18 @@ Before setting up a `UserDefinedNetwork` (UDN) resource, users should consider t
15
15
16
16
* `openshift-*` namespaces should not be used to set up a UDN.
17
17
18
-
* 2 masquerade IPs are required for user defined networks. You must reconfigure your masquerade subnet to be large enough to hold the required number of networks. For {product-title} 4.17 and later versions, clusters use `169.254.0.0/17` for IPv4 and `fd69::/112` for IPv6 as the default masquerade subnet. These ranges should also be avoided by users. For upgraded clusters, there is no change to the default masquerade subnet.
18
+
* 2 masquerade IP addresses are required for user defined networks. You must reconfigure your masquerade subnet to be large enough to hold the required number of networks.
19
+
+
20
+
[IMPORTANT]
21
+
====
22
+
For {product-title} 4.17 and later, clusters use `169.254.0.0/17` for IPv4 and `fd69::/112` for IPv6 as the default masquerade subnet. These ranges should be avoided by users. For updated clusters, there is no change to the default masquerade subnet.
23
+
====
19
24
// May be something that is downstream only.
20
25
//* No active primary UDN managed pod can also be a candidate for `v1.multus-cni.io/default-network`
21
26
22
27
* Ensure tenants are using the `UserDefinedNetwork` resource and not the `NetworkAttachmentDefinition` (NAD) resource. This can create security risks between tenants.
23
28
24
29
* When creating network segmentation, you should only use the NAD resource if user-defined network segmentation cannot be completed using the UDN resource.
25
30
26
-
* The cluster subnet and services CIDR for a UDN cannot overlap with the default cluster subnet CIDR. OVN-Kubernetes network plugin uses `100.64.0.0/16` as the default network's join subnet, you must not use that value to configure a UDN `JoinSubnets` field.
27
-
+
28
-
[IMPORTANT]
29
-
====
30
-
For {product-title} 4.17 and later versions, clusters use `169.254.0.0/17` for IPv4 and `fd69::/112` for IPv6 as the default masquerade subnet. These ranges should also be avoided by users. For upgraded clusters, there is no change to the default masquerade subnet.
31
-
====
31
+
* The cluster subnet and services CIDR for a UDN cannot overlap with the default cluster subnet CIDR. OVN-Kubernetes network plugin uses `100.64.0.0/16` as the default network's join subnet, you must not use that value to configure a UDN `joinSubnets` field. If the default address values are used anywhere in the cluster's network you must override it by setting the `joinSubnets` field. For more information, see "Additional configuration details for a UserDefinedNetworks CR".
Copy file name to clipboardExpand all lines: modules/nw-udn-cr.adoc
+55-22Lines changed: 55 additions & 22 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@
6
6
[id="nw-udn-cr_{context}"]
7
7
= Creating a UserDefinedNetwork custom resource
8
8
9
-
The following procedure sets up a user-defined network that is namespace scoped.
9
+
The following procedure creates a user-defined network that is namespace scoped. Based upon your use case, create your request using either the `my-layer-two-udn.yaml` example for a `Layer2` topology type or the `my-layer-three-udn.yaml` example for a `Layer3` topology type.
10
10
11
11
//We won't have these pieces till GA in 4.18.
12
12
//[NOTE]
@@ -16,9 +16,9 @@ The following procedure sets up a user-defined network that is namespace scoped.
16
16
17
17
.Procedure
18
18
19
-
. Create a request for a user-defined network:
19
+
. Create a request for either a `Layer2` or `Layer3` topology type user-defined network:
20
20
21
-
.. Create a YAML file, such as `my-udn-request.yaml`, to define your request with content as in the following example:
21
+
.. Create a YAML file, such as `my-layer-two-udn.yaml`, to define your request for a `Layer2` topology as in the following example:
22
22
+
23
23
[source, yaml]
24
24
----
@@ -31,37 +31,71 @@ spec:
31
31
topology: Layer2 # <2>
32
32
layer2: <3>
33
33
role: Primary # <4>
34
-
mtu: 9000 # <5>
35
34
subnets:
36
35
- "10.0.0.0/24"
37
-
- "2001:db8::/64" # <6>
38
-
JoinSubnets: [] # <7>
39
-
IPAMLifecycle: Persistent # <8>
36
+
- "2001:db8::/60" # <5>
40
37
----
41
38
<1> Name of your `UserDefinedNetwork` resource. This should not be `default` or duplicate any global namespaces created by the Cluster Network Operator (CNO).
42
-
<2> The `topology` field describes the network configuration, accepted values are `Layer2` and `Layer3`. `Layer3` topology creates a layer 2 segment per node, each with a different subnet. Layer 3 routing is used to interconnect node subnets. `Layer2` topology creates one logical switch shared by all nodes.
43
-
<3> This field specifies the topology configuration, it can be `layer2` or `layer3`.
44
-
<4> Specifies `Primary` or `Secondary`. `Primary` is the only `role` specification supported in {product-version}.
45
-
<5> The maximum transmission units (MTU) is an optional field. The default value is `1400`. The boundary for IPv4 is 574, and for IPv6 it is 1280.
46
-
<6> Specifies the subnet to be used for the network across the cluster. Supports both IPv6 and dual-stack. For example, `192.168.100.0/24`,`2001:DBB::/64`. Dual-stack may set two subnets otherwise only one is allowed. When the `topology` field is set to `Layer3`, the subnet is split into smaller subnets for every node. Accepted format for subnets when `Layer3` is set are: `172.16.0.0/16/24`. For `Layer2` values in `topology` field, standard CIDR ranges are accepted. If omitted the network only provides `Layer2` communication and you must configure IP addresses.
47
-
<7> Specifies the `subnets` used inside the OVN-Kubernetes network topology. If omitted, the OVN-Kubernetes network plugin assigns one, which is subject to change over time.
48
-
<8> Specifies the IP address management system (IPAM). This field is optional and allowed when `topology` is `layer2`. The
49
-
`subnets` field must be specified when this field is specified. The `Persistent` value specifies that workloads have persistent IP addresses. Assigned by the container network interface (CNI) and used by OVN-Kubernetes to program pod IP addresses. You must not change this for pod annotations.
50
-
51
-
.. Apply your request by running the following command:
39
+
<2> The `topology` field describes the network configuration; accepted values are `Layer2` and `Layer3`. Specifying a `Layer2` topology type creates one logical switch that is shared by all nodes.
40
+
<3> This field specifies the topology configuration. It can be `layer2` or `layer3`.
41
+
<4> Specifies `Primary` or `Secondary`. `Primary` is the only `role` specification supported in 4.17.
42
+
<5> For `Layer2` topology types the following specifies config details for the `subnet` field:
43
+
+
44
+
* The subnets field is optional.
45
+
* The subnets field is of type `string` and accepts standard CIDR formats for both IPv4 and IPv6.
46
+
* The subnets field accepts one or two items. For two items, they must be of a different family. For example, subnets values of `10.100.0.0/16` and `2001:db8::/64`.
47
+
* `Layer2` subnets can be omitted. If omitted, users must configure IP addresses for the pods. As a consequence, port security only prevents MAC spoofing.
48
+
* The `Layer2``subnets` field is mandatory when the `ipamLifecycle` field is specified.
49
+
+
50
+
.. Create a YAML file, such as `my-layer-three-udn.yaml`, to define your request for a `Layer3` topology as in the following example:
51
+
+
52
+
[source, yaml]
53
+
----
54
+
apiVersion: k8s.ovn.org/v1
55
+
kind: UserDefinedNetwork
56
+
metadata:
57
+
name: udn-2-primary # <1>
58
+
namespace: <some_custom_namespace>
59
+
spec:
60
+
topology: Layer3 # <2>
61
+
layer3: # <3>
62
+
role: Primary # <4>
63
+
subnets: # <5>
64
+
- cidr: 10.150.0.0/16
65
+
hostSubnet: 24
66
+
- cidr: 2001:db8::/60
67
+
hostSubnet: 64
68
+
----
69
+
<1> Name of your `UserDefinedNetwork` resource. This should not be `default` or duplicate any global namespaces created by the Cluster Network Operator (CNO).
70
+
<2> The `topology` field describes the network configuration; accepted values are `Layer2` and `Layer3`. Specifying a `Layer3` topology type creates a layer 2 segment per node, each with a different subnet. Layer 3 routing is used to interconnect node subnets.
71
+
<3> This field specifies the topology configuration. Valid values are `layer2` or `layer3`.
72
+
<4> Specifies a `Primary` or `Secondary` role. `Primary` is the only `role` specification supported in 4.17 .
73
+
<5> For `Layer3` topology types the following specifies config details for the `subnet` field:
74
+
+
75
+
* The `subnets` field is mandatory.
76
+
* The type for the `subnets` field is `cidr` and `hostSubnet`:
77
+
**`cidr` is the cluster subnet and accepts a string value.
78
+
**`hostSubnet` specifies the nodes subnet prefix that the cluster subnet is split to.
79
+
** For IPv6, only a `/64` length is supported for `hostSubnet`.
80
+
+
81
+
. Apply your request by running the following command:
52
82
+
53
83
[source,terminal]
54
84
----
55
-
$ oc apply -f my-udn-request.yaml
85
+
$ oc apply -f <my_layer_two_udn.yaml>
56
86
----
87
+
+
88
+
Where `<my_layer_two_udn.yaml>` is the name of your `Layer2` or `Layer3` configuration file.
57
89
58
90
. Verify that your request is successful by running the following command:
59
91
+
60
92
[source, terminal]
61
93
----
62
-
$ oc get userdefinednetworks udn-1 -n default -o yaml
94
+
$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
63
95
----
64
96
+
97
+
Where `some_custom_namespace` is the namespace you created for your user-defined network.
0 commit comments