Merge pull request #97561 from openshift-cherrypick-robot/cherry-pick-97387-to-enterprise-4.18

[enterprise-4.18] OCPBUGS-36674-re: Adding DAY 2 limitations for configuring the primary interface by using the OVNK plug-in

Author: dfitzmau

modules/nw-ovn-kuberentes-limitations.adoc

@@ -3,22 +3,23 @@
 // * networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc
 // * microshift_networking/microshift-nw-ipv6-config.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="nw-ovn-kubernetes-limitations_{context}"]
 = OVN-Kubernetes IPv6 and dual-stack limitations
 
 The OVN-Kubernetes network plugin has the following limitations:
 
-* If you set the `ipv6.disable` parameter to `1` in the `kernelArgument` section of the `MachineConfig` custom resource (CR) for your cluster, OVN-Kubernetes pods enter a `CrashLoopBackOff` state. Additionally, updating your cluster to a later version of {product-title} fails because the Network Operator is stuck on a `Degraded` state. Red{nbsp}Hat does not support disabling IPv6 adddresses for your cluster so do not set the `ipv6.disable` parameter to `1`.
-
 // The foll limitation is also recorded in the installation section.
 ifndef::microshift[]
 * For clusters configured for dual-stack networking, both IPv4 and IPv6 traffic must use the same network interface as the default gateway.
 endif::microshift[]
 ifdef::microshift[]
 * For a cluster configured for dual-stack networking, both IPv4 and IPv6 traffic must use the same network interface as the default gateway.
 endif::microshift[]
++
 If this requirement is not met, pods on the host in the `ovnkube-node` daemon set enter the `CrashLoopBackOff` state.
-If you display a pod with a command such as `oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml`, the `status` field contains more than one message about the default gateway, as shown in the following output:
++
+If you display a pod with a command such as `oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml`, the `status` field has more than one message about the default gateway, as shown in the following output:
 +
 [source,terminal]
 ----
@@ -34,8 +35,10 @@ endif::microshift[]
 ifdef::microshift[]
 * For a cluster configured for dual-stack networking, both the IPv4 and IPv6 routing tables must contain the default gateway.
 endif::microshift[]
++
 If this requirement is not met, pods on the host in the `ovnkube-node` daemon set enter the `CrashLoopBackOff` state.
-If you display a pod with a command such as `oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml`, the `status` field contains more than one message about the default gateway, as shown in the following output:
++
+If you display a pod with a command such as `oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml`, the `status` field has more than one message about the default gateway, as shown in the following output:
 +
 [source,terminal]
 ----
@@ -44,3 +47,5 @@ F0512 19:07:17.589141  108432 ovnkube.go:133] failed to get default gateway inte
 ----
 +
 The only resolution is to reconfigure the host networking so that both IP families contain the default gateway.
+
+* If you set the `ipv6.disable` parameter to `1` in the `kernelArgument` section of the `MachineConfig` custom resource (CR) for your cluster, OVN-Kubernetes pods enter a `CrashLoopBackOff` state. Additionally, updating your cluster to a later version of {product-title} fails because the Network Operator remains on a `Degraded` state. Red{nbsp}Hat does not support disabling IPv6 adddresses for your cluster so do not set the `ipv6.disable` parameter to `1`.

modules/nw-ovn-kubernetes-features.adoc

@@ -2,6 +2,7 @@
 //
 // * networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="nw-ovn-kubernetes-purpose_{context}"]
 = OVN-Kubernetes purpose
 
@@ -21,3 +22,16 @@ The OVN-Kubernetes network plugin supports the following capabilities:
 * Egress firewall devices and egress IP addresses.
 * Egress router devices that operate in redirect mode.
 * IPsec encryption of intracluster communications.
+
+Red{nbsp}Hat does not support the following postinstallation configurations that use the OVN-Kubernetes network plugin:
+
+* Configuring the primary network interface, including using the NMState Operator to configure bonding for the interface.
+* Configuring a sub-interface or additional network interface on a network device that uses the Open vSwitch (OVS) or an OVN-Kubernetes `br-ex` bridge network.
+* Creating additional virtual local area networks (VLANs) on the primary network interface.
+* Using the primary network interface, such as `eth0` or `bond0`, that you created for a node during cluster installation to create additional secondary networks.
+
+Red{nbsp}Hat does support the following postinstallation configurations that use the OVN-Kubernetes network plugin:
+
+* Creating additional VLANs from the base physical interface, such as `eth0.100`, where you configured the primary network interface as a VLAN for a node during cluster installation. This works because the Open vSwitch (OVS) bridge attaches to the initial VLAN sub-interface, such as `eth0.100`, leaving the base physical interface available for new configurations.
+* Creating an additional OVN secondary network with a `localnet` topology network requires that you define the secondary network in a `NodeNetworkConfigurationPolicy` (NNCP) object. After you create the network, pods or virtual machines (VMs) can then attach to the network. These secondary networks give a dedicated connection to the physical network, which might or might not use VLAN tagging. You cannot access these networks from the host network of a node where the host does not have the required setup, such as the required network settings.
+

networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc

@@ -15,13 +15,23 @@ Part of {openshift-networking}, the OVN-Kubernetes network plugin is the default
 OVN-Kubernetes is the default networking solution for {product-title} and {sno} deployments.
 ====
 
-OVN-Kubernetes, which arose from the OVS project, uses many of the same constructs, such as open flow rules, to determine how packets travel through the network. For more information, see the link:https://www.ovn.org/en/[Open Virtual Network website].
+OVN-Kubernetes, which arose from the OVS project, uses many of the same constructs, such as open flow rules, to decide how packets travel through the network. For more information, see the link:https://www.ovn.org/en/[Open Virtual Network website].
 
-OVN-Kubernetes is a series of daemons for OVS that translate virtual network configurations into `OpenFlow` rules. `OpenFlow` is a protocol for communicating with network switches and routers, providing a means for remotely controlling the flow of network traffic on a network device so that network administrators can configure, manage, and monitor the flow of network traffic.
+OVN-Kubernetes is a series of daemons for OVS that transform virtual network configurations into `OpenFlow` rules. `OpenFlow` is a protocol for communicating with network switches and routers, providing a means for remotely controlling the flow of network traffic on a network device. This means that network administrators can configure, manage, and watch the flow of network traffic.
 
-OVN-Kubernetes provides more of the advanced functionality not available with `OpenFlow`. OVN supports distributed virtual routing, distributed logical switches, access control, Dynamic Host Configuration Protocol (DHCP), and DNS. OVN implements distributed virtual routing within logic flows that equate to open flows. For example, if you have a pod that sends out a DHCP request to the DHCP server on the network, a logic flow rule in the request helps the OVN-Kubernetes handle the packet so that the server can respond with gateway, DNS server, IP address, and other information.
+OVN-Kubernetes provides more of the advanced functionality not available with `OpenFlow`. OVN supports distributed virtual routing, distributed logical switches, access control, Dynamic Host Configuration Protocol (DHCP), and DNS. OVN implements distributed virtual routing within logic flows that equate to open flows. For example, if you have a pod that sends out a DHCP request to the DHCP server on the network, a logic flow rule in the request helps the OVN-Kubernetes handle the packet. This means that the server can respond with gateway, DNS server, IP address, and other information.
 
-OVN-Kubernetes runs a daemon on each node. There are daemon sets for the databases and for the OVN controller that run on every node. The OVN controller programs the Open vSwitch daemon on the nodes to support the network provider features: egress IPs, firewalls, routers, hybrid networking, IPSEC encryption, IPv6, network policy, network policy logs, hardware offloading, and multicast.
+OVN-Kubernetes runs a daemon on each node. There are daemon sets for the databases and for the OVN controller that run on every node. The OVN controller programs the Open vSwitch daemon on the nodes to support the following network provider features: 
+
+* Egress IPs
+* Firewalls
+* Hardware offloading
+* Hybrid networking
+* Internet Protocol Security (IPsec) encryption
+* IPv6
+* Multicast.
+* Network policy and network policy logs
+* Routers
 
 // OVN-Kubernetes purpose
 include::modules/nw-ovn-kubernetes-features.adoc[leveloffset=+1]