TCPIP stack layer use cases

The TCPIP Stack Layers workspaces were created to facilitate investigation of the following types of issues.

Many systems programmers use stack layer information to get a high-level view of the health and status of the networking stack. TCP/IP stack layer information can be very useful in diagnosing and debugging network problems. These use cases address the navigation paths shown in Figure 1.
Figure 1. TCPIP stack layer use cases

TCPIP stack layer use cases

Determining stack help through connections

A network systems programmer joins a conference call. There is a problem on a few LPARs and the others on the conference call are blaming the mainframe network. This is a high profile issue on production LPARs. The networking expert needs to isolate the problem quickly, or at least exclude the network as the source of the problem.
  1. The network expert is notified of connection problems with one or more systems. These problems do not appear to be associated with any particular application.
  2. He navigates to the Enterprise TCPIP Stack Performance Overview workspace. The information in this workspace is displayed by protocol: IP, TCP and UDP.
  3. He reviews the IP Layer Metrics and TCP Layer Metrics subpanels and determines that the level of activity on the LPAR is normal, that is, the values for the normal traffic and minimal datagrams discarded, and the Total Retransmission Percentage and Total Out-of-Order Segments attributes are in normal range.
  4. He navigates to the TCPIP Stack TCP Performance Details workspace and reviews the Connection Statistics subpanel, finding normal values.
  5. He reports on the conference call that he has verified that the network is functioning correctly.

Determining stack health using throughput

A systems programmer needs to identify issues with the throughput of network traffic through the z/OS® TCP/IP stacks in the enterprise.
  1. She is notified of slow network performance on one or more systems. These problems do not appear to be associated with any particular application
  2. She navigates to the Enterprise TCPIP Stack Performance Overview workspace. The information in this workspace is displayed by protocol: IP, TCP and UDP.
  3. She reviews the IP Layer Metrics and TCP Layer Metrics subpanels and determines that there are no discards, but there are a number of retransmissions and out-of-order segments for one of the TCPIP stacks.
  4. From the TCP Layer Metrics subpanel, she navigates to the TCPIP Stack IP Performance Details workspace and views the IPv4 Layer Reassemblies and Fragmentations and IPv6 Layer Reassemblies and Fragmentations subpanels.
  5. She determines that a configuration error exists that is causing the high number of reassemblies in the IPv4 layer.

Determining stack health through memory usage

A systems programmer is investigating a problem and needs to exclude the use of memory by the TCPIP stacks in the enterprise
  1. The systems programmer is notified of network performance issues. These problems do not appear to be associated with any particular application.
  2. After he does some initial investigation into network performance and throughput, he suspects that the problem might be related to stack memory use.
  3. He navigates to the Enterprise TCPIP Stack Memory and CSM Overview workspace.
  4. He reviews the ECSA, authorized private, and 64-bit common storage metrics but doesn’t find any out of the ordinary values.
  5. He navigates to the CSM Storage Details workspace.
  6. He reviews the CSM Allocated by Pool subpanel and again finds only expected values.

Determining the source of a sudden increase in CSM storage usage

A systems programmer is investigating a sudden increase in CSM storage usage. After re-IPL of the sysplex, the ECSA in use on one LPAR grew very quickly, from 247MB to 385MB; the other LPARs did not show an increase in ECSA usage.
  1. She navigates to the Enterprise TCPIP Stack Memory and CSM Overview workspace.
  2. She observes that the Percent ECSA In Use Storage attribute is much higher than normal.
  3. She navigates to the CSM by Owner Summary workspace to determine if a single address space is responsible for the high ECSA storage in use value.
  4. She reviews the CSM Storage by Owner subpanel to identify any applications with a high value for Percent ECSA In Use Storage. One address space has a significantly higher value than the other address spaces.
  5. She navigates to the Application Details for Application_Name workspace to view the Idle Time Since Last Accept and Time Since Last Activity attributes and confirms that the application is accepting connection requests and transferring data.
  6. She contacts the application owner to resolve the problem.