Chapter 11 - TCP/IP Protocol Family Statistics
This chapter tells you how to access and interpret statistics on TCP/IP communication protocol activity on the VINES server. These protocols define the rules and procedures that users, application programs, and TCP/IP network nodes must follow in order to communicate in networks in which the industry-standard TCP/IP suite of protocols are supported.
Overview of the TCP/IP Protocol Family
VNSM provides statistics on the following protocols in the TCP/IP protocol family:
Internet Protocol (IP) - Like VINES IP, IP handles network traffic one level above the actual interfaces. It is responsible for moving packets through the network. This protocol is also responsible for making routing decisions, which involve determining the appropriate paths that packets should take to reach their destinations.
Address Resolution Protocol (ARP) - Enables a server to learn LAN addresses of nodes, without the intervention of an administrator. Using ARP packets, a server requests the LAN address from the nodes on the LAN, and the nodes respond.
Internet Control Message Protocol (ICMP) - Provides nodes that implement IP with information on problems encountered during delivery of data. This information is contained in ICMP packets.
Transmission Control Protocol (TCP) - Provides a reliable data stream service to network application programs. The VINES SMTP gateway uses TCP to communicate with mail programs on other TCP/IP nodes. Third-party applications written with the TCP/UDP programming interface can also use TCP.
User Datagram Protocol (UDP) - Provides an unreliable datagram service to network applications. The VINES SNMP service uses UDP. Third-party applications written with the TCP/UDP programming interface can also use UDP.
Like VINES protocols, TCP/IP protocols work together within the framework of an OSI-like architectural model. Figure 11-1 shows this model and the protocols within each layer.
In the TCP/IP architecture, application protocols such as SMTP and FTP perform session and presentation layer functions. A distinct session layer or presentation layer does not exist.
The protocols in each layer provide services to the protocols in the layer above it. For example, TCP relies on IP to move TCP messages through the network.
In some cases, protocols within the same layer rely on each other to perform their functions. ICMP relies on IP to send routing redirect packets through the network, but IP may make improper routing decisions unless routes created by ICMP redirect packets are correct.
When application programs, such as the VINES SMTP gateway, send data in a TCP/IP network, they deliver the data to the underlying layers. As the data moves downward through each layer, it is encapsulated in that layer's protocol headers for delivery to the appropriate destination. By the time the application data is transmitted on the LAN, it is encapsulated in several headers.
For example, when the VINES SMTP mail gateway uses TCP to send a mail message to a TCP/IP node, such as a minicomputer, the mail message is encapsulated as follows.
When the mail message is received at the destination node, each protocol removes its header and passes the remaining headers and the encapsulated message to the layer above. Eventually, just the original mail message remains, which is then delivered to the mail application on the node, such as a UNIX mail daemon.
Note that the term message refers to the transport layer header, and the application data. Messages are encapsulated in packets, which include the network layer header.
Keep in mind that applications such as the VINES SMTP gateway are not the only sources of and destinations for data. For example, the network layer protocols ARP and ICMP use IP to perform their respective functions. Figure 11-3 shows the format of IP packets that encapsulate the headers associated with these protocols.
The exact format of the protocol headers depends on the protocols used to communicate.
If you need more information on TCP/IP protocols, refer to the following documents:
Comer, Douglas. Internetworking with TCP/IP Volume I: Principles, Protocols, and Architecture. Prentice-Hall. Davidson, John. An Introduction to TCP/IP. Springer-Verlag. TCP/IP protocols such as TCP and IP are described in documents called Requests for Comments (RFCs). Many RFCs and articles on TCP/IP protocols are available on-line from DTIC in Alexandria, Va. Use the following domain name to obtain these documents: NIC.DDN.MIL
Note that the TCP/IP address associated with this name is 192.112.36.5.
The following RFCs may be useful:
[RFC 768] - Postel, J. B., User Datagram Protocol, August, 1980
[RFC 791] - Postel, J. B., Internet Protocol, September, 1981
[RFC 792] - Postel, J. B., Internet Control Message Protocol, September, 1981
[RFC 793] - Postel, J. B., Transmission Control Protocol, September, 1981
[RFC 826] - Plummer, D., An Ethernet Address Resolution Protocol, November, 1982
[RFC 1349] - Almquist, P., Type of Service in the Internet Protocol Suite, July, 1992. This RFC updates RFC 791.
[RFC 950] - Mogul, J. C.; Postel, J. B., Internet Standard Subnetting Procedure, August, 1985. This RFC updates RFC 792.
Accessing TCP/IP Protocol Statistics
To access statistics on the activity of TCP/IP protocols, perform the following steps:
1. Choose SHOW communications statistics from the VINES Network Summary menu.
2. Choose ACCESS protocol family statistics from the Communication Statistics menu.
3. Choose TCP/IP statistics from the Protocol Families menu. The Protocol Family Summary menu for TCP/IP appears, as follows.
The Protocol Family Summary Menu for TCP/IP displays all of the protocols in the TCP/IP protocol family on which statistics are available and summary statistics for each protocol. Summary and detailed statistics are available for ARP, IP, and ICMP only.
Remember that you can press F10 to request an immediate update while viewing a detailed statistics screen.
From the Protocol Summary Menu for TCP/IP, you can view the total number of ARP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs).
The Totin and Totout counts for ARP are influenced by the number of TCP/IP nodes the server is directly connected to by LANs, and the frequency with which they come on and go off the network. TCP/IP nodes issue ARP broadcasts on the LANs to which they are connected whenever they need to learn the LAN address of nodes with which they want to communicate. Nodes on these LANs reply to these broadcasts.
As the number of these nodes increases, and as the frequency with which they come on and go off the network increases, the counts are likely to increase.
To access detailed ARP statistics, select ARP from the Protocol Summary Menu for TCP/IP. The statistics are described in the sections that follow.
Total in
Total ARP packets received.
Requests received
Total ARP request packets received. TCP/IP nodes send ARP request packets to ask other TCP/IP nodes to respond with their LAN and IP addresses.
Replies received
Total ARP reply packets received. TCP/IP nodes use ARP reply packets to respond to ARP request packets from other TCP/IP nodes.
Packets dropped
Total received ARP packets that were dropped for the following reasons:
Insufficient communication buffers on the server. Consider increasing the server's communication buffer size. Bad ARP header contents, such as a wrong length for the physical address (for example, 5 bytes for an Ethernet address) or the use of the source address as the broadcast address.
Unknown Types
Total number of packets received by ARP on the server that were not identified as either request or reply packets.
Packets in last second
Total ARP packets received in the last second.
In (HWM)
The largest number of ARP packets received in one second since the server was last booted (high-water mark).
Total out
Total ARP packets sent.
Requests sent
Total ARP request packets sent. TCP/IP nodes send ARP request packets to ask other TCP/IP nodes to respond with their LAN and IP addresses.
Replies sent
Total ARP reply packets sent. TCP/IP nodes use ARP reply packets to respond to ARP request packets from other TCP/IP nodes.
Proxy replies sent
Total ARP proxy replies sent. These replies are sent in response to ARP requests when the server implements proxy ARP. If your server does not implement proxy ARP, this value is always 0.
Cache Size
The number of complete and incomplete ARP entries cached. If this statistic is 0, it means that either the server has no TCP/IP neighbors on its LAN interfaces, ARP is disabled on all LAN interfaces, or the server is failing to receive or store ARP entries from TCP/IP neighbors. Correlate this statistic with the information on TCP/IP ARP cache entries, which is available through the SHOW protocol information option on the VINES Network Summary Menu. See "TCP/IP ARP Cache" in Appendix A for more information.
From the Protocol Summary Menu for TCP/IP, you can view the total number of IP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs).
Totin includes counts for the following packets:
Packets that the server receives, such as packets that contain TCP or UDP messages that are destined for applications on the server (for example, the SMTP gateway, the SNMP agent, or a third-party application). ICMP and ARP packets that the server receives also count as part of Totin. Packets that the server routes.
Totout includes counts for the following packets:
Packets that the server sends, such as packets containing TCP or UDP messages that applications on the server send to applications on other TCP/IP nodes. ARP and ICMP packets that the server sends also count as part of Totout. Packets that the server routes.
You can see that a single routed packet is counted in both Totin and Totout. When a server routes a packet, it receives the packet on one network interface, such as an Ethernet card, and sends the packet on another. The reception of the packet is counted as part of Totin. The sending of the packet is counted as part of Totout.
Figures 11-5, 11-6, and 11-7 show IP on a server sending a packet, receiving a packet, and routing a packet.
The totals for IP will be considerably larger than the totals for the other protocols on the Protocol Summary Menu for TCP/IP. All the other protocols use IP, and all the other protocols just send and receive packets. Keep in mind that IP sends, receives, and routes packets.
Factors That Affect IP Traffic
VNSM summarizes how network configuration and other factors affect the server's performance and network traffic that IP routes. The factors are as follows:
Number of applications that use the TCP/IP protocol family on the server. These applications include the VINES SMTP gateway, the SNMP proxy agent, and third-party applications developed with the TCP/UDP programming interface. Number of LANs that TCP/IP uses and the number of TCP/IP nodes connected to those LANs. Number of workstations running PC/TCP that use the server to route TCP/IP traffic to destinations, and the type of traffic the workstations send and receive. Typically, file transfers generate more network traffic than Telnet or RLOGIN sessions. Whether the server is equipped with the TCP/IP Server-to-Server option. The Totin and Totout counts will be influenced by the amount of VINES IP traffic that the server tunnels through the TCP/IP network. See the section "VINES IP Statistics" in Chapter 10 for a description of tunneling. Whether the server is equipped with the TCP/IP Routing option. The Totin and Totout counts will be influenced by the amount of TCP/IP traffic that the server tunnels through the VINES network. See the section "VINES IP Statistics" in Chapter 10 for a description of tunneling.
To access detailed IP statistics, select IP from the Protocol Summary Menu for TCP/IP. These statistics are described in the sections that follow.
This section describes IP statistics that can be retrieved from a VINES 5.50 server by a VINES 5.50 VNSM client.
The sections that follow describe ICMP statistics. Descriptions of some interrelated statistics are combined. For example, Pkts with record route option sent and Pkts with record route option recvd are combined as Pkts with record route option sent/received.
Total in
Total number of IP packets received.
Total out
Total number of IP packets sent.
Bytes Received
The total number of bytes received.
Bytes Transmitted
The total number of bytes transmitted.
Dropped: invalid header
Total number of IP packets that could not be received because of errors in their headers. Some of these errors include invalid checksums, inability to process options in the IP header, or an IP header length that is either less than the minimum length allowed (20 bytes) or greater than the actual size of the IP packet.
Dropped: invalid address
The total number of received IP packets that were discarded because they contained a destination IP address that the server did not recognize as valid, such as 0.0.0.0, an invalid broadcast address, or an address of an unsupported class (for example, Class E).
Unknown types
The total number of IP packets received, but discarded because they contained an unknown or unsupported protocol.
Dropped: no buffer space in/out
The total number of IP packets that could not be received or sent because the server had insufficient communication buffer space. If this error persists, increase the communication buffer space on the server. See Chapter 15 for more information on increasing communication buffer space.
Packets to be output
The total number of IP packets that ARP, ICMP, TCP, and UDP delivered to IP for transmission.
Dropped invalid dest addr
The total number of IP packets that could not be transmitted because they had an invalid address, such as 0.0.0.0, or because the address was of an invalid class (for example, Class D or Class E).
Dropped no route
The total number of IP packets that could not be transmitted because the server could not find a route to their destination in its TCP/IP routing table.
IP forwarding packets
This field indicates whether the server acts as a gateway (1) or not. This field always displays 1 if the Routing option is installed. This field displays 2 if just the Server-to-Server option is installed.
Default Time-to-Live value
This field displays the default time-to-live (TTL) value, in number of hops, that the server puts in the IP header of transmitted packets. The TTL value determines the maximum number of hops through which the packet can travel. The default value is always inserted into the IP header unless it is overridden by a transport layer protocol such as TCP or UDP. Both TCP and UDP use a default TTL of 30.
Reassembly timeout period
The maximum number of seconds that received fragments are held while waiting to be reassembled. When an IP packet exceeds the maximum transmission unit (MTU) size of a LAN or WAN that it must be routed across, the packet must be divided into fragments.
Datagrams to be forwarded
The total number of IP packets for which the server was not the final destination, and which the server attempted to route to their final destination.
Delivered to next level prot
The total number of IP packets that were received and passed to ARP, ICMP, TCP, and UDP.
Broadcast packets received
The total number of IP broadcast packets received. An IP broadcast packet has a destination address that matches the IP broadcast address of the physical interface (such as an Ethernet interface) over which the packet was received.
Directed bcast pkts received
Number of directed broadcast packets received. A directed broadcast packet has a destination address that matches the IP broadcast address of one of interfaces of the server that you are monitoring.
The IP broadcast address does not have to match the IP broadcast address of the interface over which the packet arrived. To receive directed broadcasts, the server must have directed broadcasts enabled.
Fragments In
The number of packet fragments that the server received. When the size of an IP packet exceeds the maximum frame size of a LAN or WAN that it has to be routed across, the packet must be divided into fragments. This activity is a normal function of IP, and does not indicate errors.
Fragmentation occurs when TCP/IP nodes route packets between LANs and WANs that support different frame sizes. The Fragments in statistic will be 0 if no fragmentation occurs on the paths between the server and the TCP/IP nodes with which it communicates.
TCP/IP fragmentation is end-to-end fragmentation. If an IP packet is fragmented at any point along a TCP/IP path, the packet remains fragmented until it is reassembled at its destination.
Reassemblies
The number of times the IP software successfully reassembled packet fragments into packets. IP performs a reassembly of a fragmented packet when all the packet fragments are received.
Reassemblies failed
Number of unsuccessful IP packet reassemblies. This problem has the following causes:
The packet could not be reassembled within the allowed time period, resulting in a timeout. A self-contained packet was received while a packet that required reassembly was being reassembled.
Fragments Dropped
The number of fragments that the server could not receive. This problem has the following causes:
The server lacks sufficient communication buffers. Duplicate fragments were received. A self-contained packet was received while a packet was being reassembled.
Fragments Timeout
The number of times a fragmented packet could not be reassembled because the reassembly timer expired. This timer starts when the server receives the initial fragment. If the timer expires before the remaining fragments arrive, a timeout occurs and the server discards the fragments that it received.
Routed
The total number of IP packets that were routed through this server.
Couldn't forward
The number of packets that the server could not route.
Packets Forwarded/sec
The average number of packets that the server forwarded per second.
Routed (HWM)
The largest number of IP packets routed in one second since the server was last booted (high-water mark).
Options routed
The number of routed IP packets that contain option fields.
Redirects sent
The number of ICMP redirect packets that the server sent.
Options in
The number of received IP packets that contain option fields.
Pkts with security option sent received
The number of IP packets containing security options that the server sent and received. RFC 791 describes this option.
Pkts with loose src and record rte sent/received
The number of IP packets containing loose source and record route options that the server sent and received. RFC 791 describes these options.
Pkts with strict src and record rte sent/received
The number of IP packets containing strict source and record route options that the server sent and received. RFC 791 describes these options.
Pkts with record route option sent received
The number of IP packets containing record route options that the server sent and received. RFC 791 describes this option.
Pkts with stream id option sent/received
The number of IP packets containing stream Id options that the server sent and received. RFC 791 describes this option.
Pkts with timestamp option sent/received
The number of IP packets containing timestamp options that the server sent and received. RFC 791 describes this option.
Broadcasts
The number of IP broadcasts sent. When the server makes an IP broadcast, the server sends broadcast packets across a directly connected network on which all hosts share a common medium (for example, Ethernet).
Directed Bcasts
The number of directed broadcasts sent. When the server makes a directed broadcast, it routes an IP broadcast packet destined for all hosts on a remote network. A remote network is one that is not directly connected to the server. If directed broadcasts are disabled for all the IP interfaces on the server, this value is 0.
Fragments Done
The number of packet fragmentations performed. Fragmentation occurs when an IP packet must be broken into smaller pieces because of maximum frame size differences among LANs or other transmission media.
For example, one IP packet that is broken into three fragments to pass over a WAN results in three fragments sent, but is counted as one fragmentation.
Fragmentations failed
The number of unsuccessful IP packet fragmentations. This problem can have the following causes:
An attempt was made to fragment a broadcast packet. IP does not allow fragmentation of broadcast packets. The IP header indicates that the packet should not be fragmented. The maximum transmission unit (MTU) size configured for the interface on which the fragments are to be sent is too small. Communication buffer space is insufficient.
Fragments created
The number of IP packet fragments created during successful fragmentation operations.
Options out
The number of sent IP packets that contain option fields.
To VINES IP
The number of packets that IP passed to VINES IP for encapsulation in VINES IP packets. These packets were initially handled by IP, but were passed to VINES IP for tunneling through a VINES network. See "VINES IP Statistics" in Chapter 10 for information on tunneling TCP/IP traffic through a VINES network.
From VINES IP
The number of packets that IP received from VINES IP to be unencapsulated into IP packets. These packets were tunneled through a VINES network. See "VINES IP Statistics" in Chapter 10 for a description of tunneling.
Routes discarded
The number of valid routing table entries that the server discarded to free up memory for new routing table entries. This value is always 0. Because the server does not support dynamic routing protocols such as RIP, the server never deletes valid routing table entries.
From the Protocol Summary Menu for TCP/IP, you can view the total number of ICMP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs).
To access detailed ICMP statistics, select ICMP from the Protocol Summary Menu for TCP/IP.
The ICMP statistics available from VINES 5.50 servers differ significantly from ICMP statistics available from other product versions. This section describes ICMP statistics that can be retrieved from a VINES 5.50 server by a VINES 5.50 VNSM client.
The sections that follow describe ICMP statistics. Descriptions of interrelated statistics are combined. For example, Unreachables sent and Unreachables rcvd are combined as Unreachables sent/received.
Total in
The total number of ICMP packets received.
Total out
The total number of ICMP packets sent.
Errors
The total number of ICMP packets received that could not be processed because the length of the packet did not match the value of the length field in the IP header.
Dropped: invalid header
The total number of ICMP packets that could not be received because of errors in their headers. Some of these errors include invalid checksums, packet length less than 8 bytes, or IP header length either less than the minimum length allowed (20 bytes) or greater than the actual size of the ICMP packet.
Code out of range
The total number of ICMP packets received that had a code value out of range for the type of ICMP message contained in the packet. For example, for the ICMP redirect packet, the code must be in the range 0 to 3.
Dropped: no buffer space in/out
The number of ICMP packets that could not be received or sent because of a lack of communication buffers. If this error persists, consider increasing communication buffer space at the server console.
Packets to be output
The total number of packets that IP, TCP, and UDP delivered to ICMP to request the transmission of an ICMP error.
Dropped protocol specific error (out)
The total number of packets that ICMP could not send because the packet in error was not the first fragment of a message.
Can't send error for old ICMP rcvd
The number of times that an ICMP error could not be generated because the packet in error was itself an ICMP packet.
Unreachables sent/received
The number of destination unreachable packets sent and received. The server sends destination unreachable packets in response to a packet that cannot be forwarded. The server also receives destination unreachable packets if it chooses an inappropriate gateway, or if the destination host or network is down.
Time Exceeded sent/received
The number of time exceeded packets sent and received. The servers ends time exceeded packets when it cannot forward packets because time-to-live value is less than or equal to 1. The server receives time exceeded packets from IP hosts that discard packets originating from the server. The IP hosts discard packets that have a time-to-live value less than or equal to 1.
Parameter Problems sent/received
The number of ICMP parameter problem packets sent and received. When an IP host, such as the server, detects a parameter problem in an IP packet, the host sends an ICMP parameter problem packet to the packet's source. Parameter problems result from errors in option fields in IP packets. Servers both send and receive parameter problem packets.
Source Quenches sent/received
The number of source quench packets sent and received. IP hosts send ICMP source quench packets to tell servers that the hosts do not have enough buffers to handle IP traffic. The server sends source quench packets when it cannot forward a packet because of a lack of communications buffers.
Redirects sent/received
The number of ICMP redirect packets sent and received. Servers send ICMP redirect packets to notify other IP hosts that they should not use a specific gateway to route IP traffic to certain destinations. The server receives ICMP redirect packets from other IP hosts that detect that the server is sending packets over inappropriate gateways.
Echo requests sent/received
The number of echo requests sent and received. Servers send echo requests to other IP hosts to see if they are operational, and receive echo replies in response. Servers also send echo replies to echo requests that they receive. In best-case scenarios, the number of echo requests received equals the number of replies sent to these requests, and the number of echo replies received equals the number of echo requests sent. If sent and received totals are not equal, one or more hosts have gone off the network.
Echo replies sent/received
The number of echo replies sent and received. See the preceding explanation of echo requests for more information.
Timestamp requests sent/received
The number of timestamp requests sent and received. Servers send timestamp requests to solicit timestamp replies from other IP hosts. In a timestamp reply, a nonstandard timestamp value is returned, which is the time (in milliseconds) since the host last booted. Servers also send timestamp replies in response to timestamp requests. In best-case scenarios, the number of timestamp requests received equals the number of replies sent to these requests, and the number of timestamp requests sent equals the number of timestamp replies received. If sent and received totals are not equal, one or more hosts have gone off the network.
Timestamp replies sent/ received
The number of timestamp replies sent and received. See the preceding explanation of timestamp requests for more information.
Address Mask requests sent/ received
The number of address mask requests sent and received. Servers send mask requests to other IP hosts to solicit their subnet masks. In response, the other IP hosts return their subnet masks in the form of address mask replies. Servers also send address mask replies in response to address mask requests. In best-case scenarios, the number of address mask requests received equals the number of replies sent to these requests, and the number of address mask requests sent equals the number of replies received. If sent and received totals are not equal, one or more hosts have gone off the network.
Address Mask replies sent/received
The number of address mask replies sent and received. See the preceding explanation of address mask requests for more information.
Info requests sent/received
The number of information requests sent and received. Servers send information requests to other IP hosts to solicit their network numbers. In response, the other IP hosts return their network numbers in the form of information replies. In best-case scenarios, the number of information requests received equals the number of replies to these requests, and the number of information requests sent equals the number of information replies received. If sent and received totals are not equal, one or more hosts have gone off the network.
Info replies sent/received
The number of information replies sent and received. See the preceding explanation of information requests for more information.
From the Protocol Summary Menu for TCP/IP, you can view the total number of IP packets containing UDP datagrams that were received (Totin), that were sent (Totout), and that contained errors (Errs).
Totin includes counts for UDP datagrams that the server receives. These datagrams are destined for applications on the server that use UDP, such as third-party applications developed with the TCP/UDP programming interface or the VINES SNMP service. See the VINES SNMP Agent Guide for more information on the SNMP service.
Totout includes counts for UDP datagrams sent by applications on the server.
To access detailed UDP statistics, select UDP from the Protocol Summary Menu for TCP/IP.
The sections that follow describe detailed UDP statistics. Descriptions of some interrelated statistics are combined. For example, Dropped: no buffer space in and Dropped: no buffer space out are combined as Dropped: no buffer space in/out.
Note: Detailed DARPA UDP statistics are available only from VINES 5.50 or later clients monitoring VINES 5.50 or later servers.
Total in
The total number of received datagrams, including datagrams that were either successfully or unsuccessfully delivered to applications such as the SNMP proxy agent.
Bytes Received
The total number of bytes received by UDP.
Dropped: no port
The total number of incoming datagrams that UDP dropped because no application had opened a port matching the destination port number in the UDP header.
Dropped: no port (broadcasts)
The total number of incoming broadcast datagrams that UDP dropped because no application had opened a port matching the destination port number in the UDP header. This statistic is a subset of the Dropped: no port statistic.
Dropped: invalid header
The total number of UDP datagrams that could not be received because of errors in their headers. Some of these errors include a bad checksum or a length field in the IP header specifying a length that does not match the actual length (in bytes) of the UDP datagram.
Dropped: no buffer space in/out
The total number of UDP datagrams that could not be received or sent because of insufficient communication buffer space. If this error persists, increase the communication buffer size.
Delivered to next level prot
The total number of incoming UDP datagrams that were delivered to UDP-based applications, such as the SNMP proxy agent.
Total Out
The total number of UDP datagrams that were transmitted.
Bytes Transmitted
The total number of bytes transmitted by UDP.
Entries in table
The total number of UDP entries, which equals the total number of active UDP sockets. Each time an application issues a sosock call to open a UDP socket, an entry for the application is created. The entry includes the local IP address of the application and the port that the application uses. The local IP address is 0.0.0.0 unless the application specifies a local IP address when it binds the socket. Each time an application issues a so close call to close a UDP socket, UDP deletes the entry.
From the Protocol Summary Menu for TCP/IP, you can view the total number of IP packets containing TCP messages that were received (Totin), that were sent (Totout), and that contained errors (Errs).
Totin includes counts for TCP messages that the server receives. These messages are destined for applications on the server that use TCP, such as the VINES SMTP gateway or a third-party application developed with the TCP/UDP programming interface.
Totout includes counts for TCP messages sent by applications on the server.
To access detailed TCP statistics, select TCP from the Protocol Summary Menu for TCP/IP.
The sections that follow describe detailed TCP statistics. Descriptions of some interrelated statistics are combined. For example, Total data segments sent and Total data segments received are combined as Total data segments sent/received.
Note: Detailed TCP statistics are available only from VINES 5.50 clients monitoring VINES 5.50 servers.
Total in
The total number of received TCP segments. A segment is the TCP transmission unit.
Total out
The total number of transmitted TCP segments.
Total data segments sent/received
The total number of data segments sent and received. The received segments sent/ total includes segments that contained errors and segments received on connections that are currently active.
Dropped: invalid header
The total number of segments that could not be received because of errors in their headers. Some of these errors include a bad checksum, or a length field in the IP header specifying a length that does not match the actual length (in bytes) of the segment.
Dropped: no conn
The total number of incoming segments that TCP dropped because no connection or listening socket exists to receive the packet.
Dropped: no buffer space in/out
The total number of TCP segments that could not be received or sent because of insufficient communication buffer space or because the segment was larger than 65,535 bytes. If this error persists, increase the communication buffer size and check that applications are not attempting to send segments that exceed 65,535 bytes.
Reschedules
The total number of segments that could not be transmitted because of a lack of communication buffers and had to be rescheduled. Since TCP is a reliable protocol, these segments are not discarded. The segments are rescheduled so they can be transmitted when enough communication buffers become available. If this error persists, increase communication buffer space.
ACK, resets sent
The total number of transmitted TCP segments that contained reset commands. TCP sends a reset command when it receives duplicate connection requests, when an acknowledgment with an incorrect acknowledgment number or sequence number is received on a partially established connection, or when an acknowledgment is received on a listening socket.
Retransmitted segments sent
The total number of transmitted TCP segments that were retransmitted. TCP retransmits segments when they are not acknowledged by the receiver.
Segments with options sent/ received
The number of segments sent and received that had TCP protocol options in the TCP header, such as the maximum segment size option or the no delay option.
Window probes sent/received
The number of segments sent and received that contained window probes. TCP sends a segment containing a window probe to tell the node on the other end of the connection the maximum number of bytes that it can transmit.
Entries in table
The number of entries in the TCP connection table. Each time an application opens a TCP socket, TCP creates an entry in this table.
Retransmission Algorithm
A value that identifies the retransmission algorithm in use. This value is always 4 (Van Jacobson's algorithm).
Min/Max retransmission timeout
The minimum and maximum retransmission timeout for connections that an application program can set, in milliseconds. A retransmission timeout determines the amount of time TCP attempts to re-transmit segments when they are not acknowledged. The minimum and maximum retransmission timeouts are always 1000 and 30000, respectively.
Max connections allowed
The maximum number of concurrent TCP connections that TCP can support. This value is always -1, indicating that there is no limit.
Default Time-to-Live value
The default time-to-live value for TCP segments in hops. This value determines the number of hops through which IP packets containing TCP segments are allowed to pass.
The current default is 30 hops. This value is used as the IP time-to-live value when the server transmits IP packets containing TCP segments.
Default Max Segment Size
The default maximum segment size in bytes. The current default is 512 bytes. The default can be changed by a TCP-based application.
Connections initiated
The total number of TCP connections that this server attempted to initiate since the last reboot of the server.
Active conn attempts failed
The total number of times that TCP on this server unsuccessfully attempted to establish a TCP connection with a destination port. This total is cumulative since the last reboot of the server.
Active attempts aborted by user
The total number of times that applications on this server that use TCP, such as the SMTP gateway, aborted an attempt to establish a connection with another application.
Active open discarded - no bufs
The total number of times since the last reboot of the server that TCP discarded attempts to open active connections because of insufficient communication buffers. If these errors persist, increase communication buffers.
Active open timed out
The total number of times since the last reboot of the server that attempts to open active or passive connections timed out. These errors occur for any number of reasons, such as severe network congestion or network failures (for example, bad cables, down routers, etc.).
Active connects established
The total number of active connections that TCP successfully established since the last reboot of the server.
Passive opens received
The total number of attempts that other TCP/IP nodes have made to establish passive connections with this server since its last reboot.
Passive conn attempts failed
The total number of times that TCP on this server unsuccessfully attempted to open passive connections. This total is cumulative since the last reboot of the server. A connection is considered passive when the attempt to establish it is initiated by another TCP/IP node.
Passive open discarded - no bufs
The total number of times since the last reboot of the server that TCP discarded attempts to open passive connections because of insufficient communication buffers. If these errors persist, increase communication buffers.
Passive open timed out
The total number of times since the last reboot of the server that attempts to open passive connections timed out. These errors occur for any number of reasons, such as severe network congestion or network failures (for example, bad cables, down routers, etc.).
Passive connects established
The total number of passive connections that TCP successfully established since the last reboot of the server.
Passive connects accepted
The total number of passive connection attempts that TCP accepted from other nodes since the server's last reboot.
Currently established conns
The total number of connections, both passive and active, that TCP currently maintains.
Estab connects user aborted
The total number of active and passive connections that applications on this server or on destination servers aborted since the last reboot of this server.
Estab connects reset - closed
The total number of connections since the last reboot of this server that TCP closed because TCP on this server or a destination node sent a reset command.
Estab connects closed gracefully
The total number of TCP connections that closed normally since the last reboot of this server.
Estab connects timed out
The total number of times since the last reboot of the server that connections timed out. This error occurs for any number of reasons, such as severe network congestion or network failures (for example, bad cables, down routers, etc.).
Listen sockets
The total number of listen sockets that are currently open. Listen sockets allow TCP-based applications to wait for incoming connection requests. When TCP receives one of these requests, it establishes a passive connection.
