Additional resource sweep: Networking

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.

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 <service_VIP>:<Port>, 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 <service_VIP>:<Port>, 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

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".

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.
 

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]