Merge pull request #48331 from jldohmann/OSDOCS-3867

OSDOCS-3867: add references to throughput issues doc

Author: michaelryanpeter

modules/nw-throughput-troubleshoot.adoc

@@ -1,50 +1,39 @@
 // Module filename: nw-throughput-troubleshoot.adoc
 // Module included in the following assemblies:
-// * networking/configuring-routing.adoc
+// * networking/routes/route-configuration.adoc
 
+:_content-type: CONCEPT
 [id="nw-throughput-troubleshoot_{context}"]
-= Troubleshooting throughput issues
-Sometimes applications deployed through {product-title} can cause
-network throughput issues such as unusually high latency between
-specific services.
+= Throughput issue troubleshooting methods
 
-Use the following methods to analyze performance issues if pod logs do not
-reveal any cause of the problem:
+Sometimes applications deployed by using {product-title} can cause network throughput issues, such as unusually high latency between specific services.
 
-* Use a packet analyzer, such as ping or link:http://www.tcpdump.org/[tcpdump]
-to analyze traffic between a pod and its node.
+If pod logs do not reveal any cause of the problem, use the following methods to analyze performance issues:
+
+* Use a packet analyzer, such as `ping` or `tcpdump` to analyze traffic between a pod and its node.
 +
-For example, run the tcpdump tool on each pod while reproducing the behavior
-that led to the issue.
-Review the captures on both sides to compare send and receive timestamps to
-analyze the latency of traffic to and from a pod.
-Latency can occur in {product-title} if a node interface is overloaded with
-traffic from other pods, storage devices, or the data plane.
+For example, link:https://access.redhat.com/solutions/4569211[run the `tcpdump` tool on each pod] while reproducing the behavior that led to the issue. Review the captures on both sides to compare send and receive timestamps to analyze the latency of traffic to and from a pod. Latency can occur in {product-title} if a node interface is overloaded with traffic from other pods, storage devices, or the data plane.
 +
 [source,terminal]
 ----
 $ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> <1>
 ----
 +
-<1> `podip` is the IP address for the pod. Run the `oc get pod <pod_name> -o wide` command to get
-the IP address of a pod.
+<1> `podip` is the IP address for the pod. Run the `oc get pod <pod_name> -o wide` command to get the IP address of a pod.
 +
-tcpdump generates a file at `/tmp/dump.pcap` containing all traffic between
-these two pods. Ideally, run the analyzer shortly
-before the issue is reproduced and stop the analyzer shortly after the issue
-is finished reproducing to minimize the size of the file.
-You can also run a packet analyzer between the nodes (eliminating the SDN from
-  the equation) with:
+The `tcpdump` command generates a file at `/tmp/dump.pcap` containing all traffic between these two pods. You can run the analyzer shortly before the issue is reproduced and stop the analyzer shortly after the issue is finished reproducing to minimize the size of the file. You can also link:https://access.redhat.com/solutions/5074041[run a packet analyzer between the nodes] (eliminating the SDN from the equation) with:
 +
 [source,terminal]
 ----
 $ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
 ----
 
-* Use a bandwidth measuring tool, such as iperf, to measure streaming throughput
-and UDP throughput. Run the tool from the pods first, then from the nodes,
-to locate any bottlenecks.
+* Use a bandwidth measuring tool, such as link:https://access.redhat.com/solutions/6129701[`iperf`], to measure streaming throughput and UDP throughput. Locate any bottlenecks by running the tool from the pods first, and then running it from the nodes.
 
 ifdef::openshift-enterprise,openshift-webscale[]
-** For information on installing and using iperf, see this link:https://access.redhat.com/solutions/33103[Red Hat Solution].
+** For information on installing and using `iperf`, see this link:https://access.redhat.com/solutions/33103[Red Hat Solution].
 endif::openshift-enterprise,openshift-webscale[]
+
+* In some cases, the cluster may mark the node with the router pod as unhealthy due to latency issues. Use worker latency profiles to adjust the frequency that the cluster waits for a status update from the node before taking action.
+
+* If your cluster has designated lower-latency and higher-latency nodes, configure the `spec.nodePlacement` field in the Ingress Controller to control the placement of the router pod.

networking/routes/route-configuration.adoc

@@ -33,6 +33,13 @@ include::modules/nw-enforcing-hsts-per-domain.adoc[leveloffset=+2]
 //Troubleshooting Throughput Issues
 include::modules/nw-throughput-troubleshoot.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../nodes/edge/nodes-edge-remote-workers.html#nodes-edge-remote-workers-latency[Latency spikes or temporary reduction in throughput to remote workers]
+
+* xref:../ingress-operator.html#nw-ingress-controller-configuration-parameters_configuring-ingress[Ingress Controller configuration parameters]
+
 //Using cookies to keep route statefulness
 include::modules/nw-using-cookies-keep-route-statefulness.adoc[leveloffset=+1]