diff --git a/modules/nw-cluster-mtu-change.adoc b/modules/nw-cluster-mtu-change.adoc index 0f6ce8a245f3..be81fa0a7fca 100644 --- a/modules/nw-cluster-mtu-change.adoc +++ b/modules/nw-cluster-mtu-change.adoc @@ -41,7 +41,7 @@ You cannot roll back an MTU value for nodes during the MTU migration process, bu The migration is disruptive and nodes in your cluster might be temporarily unavailable as the MTU update takes effect. ==== -ifdef::outposts[For more details about the migration process, including important service interruption considerations, see "Changing the MTU for the cluster network" in the additional resources for this procedure.] +ifdef::outposts[For more details about the migration process, including important service interruption considerations, see "Changing the MTU for the cluster network".] ifndef::local-zone,wavelength-zone,post-aws-zones,outposts[] The following procedures describe how to change the cluster network MTU by using machine configs, Dynamic Host Configuration Protocol (DHCP), or an ISO image. If you use either the DHCP or ISO approaches, you must refer to configuration artifacts that you kept after installing your cluster to complete the procedure. diff --git a/modules/nw-ovn-kubernetes-session-affinity.adoc b/modules/nw-ovn-kubernetes-session-affinity.adoc index 90f392b4d714..1c5d329c407f 100644 --- a/modules/nw-ovn-kubernetes-session-affinity.adoc +++ b/modules/nw-ovn-kubernetes-session-affinity.adoc @@ -7,7 +7,7 @@ = Session affinity [role="_abstract"] -You can use _session affinity_ if you want to ensure that each time you connect to a :, the traffic is always load balanced to the same back end. For more information, including how to set session affinity based on a client's IP address, see the Additional resources. +You can use _session affinity_ if you want to ensure that each time you connect to a :, the traffic is always load balanced to the same back end. For more information, including how to set session affinity based on a client's IP address, see "Session affinity in Kubernetes". [id="nw-ovn-kubernetes-session-affinity-stickyness-timeout_{context}"] @@ -17,7 +17,7 @@ The OVN-Kubernetes network plugin for {product-title} calculates the stickiness For example, if you run a `curl` command 10 times, the sticky session timer starts from the tenth packet not the first. -As a result, if the client is continuously contacting the service, then the session never times out. The timeout starts when the service has not received a packet for the amount of time set by the `timeoutSeconds` parameter. For more information about `timeoutSeconds`, see the Additional resources. +As a result, if the client is continuously contacting the service, then the session never times out. The timeout starts when the service has not received a packet for the amount of time set by the `timeoutSeconds` parameter. For more information about `timeoutSeconds`, see "Session stickiness timeout in Kubernetes". [role="_additional-resources"] .Additional resources diff --git a/modules/understanding-multiple-networks-con.adoc b/modules/understanding-multiple-networks-con.adoc index fedd1d708276..0c164d101a89 100644 --- a/modules/understanding-multiple-networks-con.adoc +++ b/modules/understanding-multiple-networks-con.adoc @@ -27,8 +27,8 @@ During cluster installation, {product-title} administrators can configure altern User-defined networks are only supported when OVN-Kubernetes is used as the CNI. UDNs are not supported for use with other CNIs. ==== -You can define an secondary network based on the available CNI plugins and attach one or more of these networks to your pods. You can define more than one secondary network for your cluster depending on your needs. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing. For more information, see the links in the Additional resources: +You can define an secondary network based on the available CNI plugins and attach one or more of these networks to your pods. You can define more than one secondary network for your cluster depending on your needs. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing. For more information: * For a complete list of supported CNI plugins, see "Secondary networks in {product-title}". * For information about user-defined networks, see "About user-defined networks (UDNs)". -* For information about Network Attachment Definitions, "Creating primary networks by using a NetworkAttachmentDefinition". +* For information about Network Attachment Definitions, see "Creating primary networks by using a NetworkAttachmentDefinition". diff --git a/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc b/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc index 55816c3ab7e0..8f4713a902a5 100644 --- a/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc +++ b/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.adoc @@ -16,7 +16,7 @@ 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. For example, the plugin applies OpenFlow rules to direct packet routing through the network infrastructure. For more information, see Additional resources. +OVN-Kubernetes, which arose from the OVS project, uses many of the same constructs. For example, the plugin applies OpenFlow rules to direct packet routing through the network infrastructure. For more information, see the "Open Virtual Network website". 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 monitor the flow of network traffic. diff --git a/networking/ovn_kubernetes_network_provider/ovn-kubernetes-troubleshooting-sources.adoc b/networking/ovn_kubernetes_network_provider/ovn-kubernetes-troubleshooting-sources.adoc index 8198bcb295e4..2b91cbc27e45 100644 --- a/networking/ovn_kubernetes_network_provider/ovn-kubernetes-troubleshooting-sources.adoc +++ b/networking/ovn_kubernetes_network_provider/ovn-kubernetes-troubleshooting-sources.adoc @@ -9,7 +9,7 @@ toc::[] [role="_abstract"] To troubleshoot OVN-Kubernetes in {product-title}, you can use built-in health checks, alerting, logs, and connectivity checks. Follow these sections to examine your cluster before opening a support case. -OVN-Kubernetes has many sources of built-in health checks and logs. Follow the instructions in these sections to examine your cluster. If a support case is necessary, collect additional information through a `must-gather` as described in the Additional resources section. Only use the `-- gather_network_logs` option when instructed by support. +OVN-Kubernetes has many sources of built-in health checks and logs. Follow the instructions in these sections to examine your cluster. If a support case is necessary, collect additional information through a `must-gather` as described in "Gathering data about your cluster for Red Hat Support". Only use the `-- gather_network_logs` option when instructed by support. include::modules/nw-ovn-kubernetes-readiness-probes.adoc[leveloffset=+1]