Chapter 10 - VINES Protocol Family Statistics
This chapter tells you how to access and interpret statistics on VINES communication protocol activity on the VINES server. VINES communication protocols define the rules and procedures that VINES users, VINES application programs such as services, and VINES network nodes such as workstations and servers must follow in order to communicate in networks.
Overview of the VINES Protocol Family
VNSM provides statistics on the following protocols in the VINES protocol family:
VINES IP - Responsible for moving units of data called packets through the network. This protocol is also responsible for making routing decisions, which involve determining the appropriate paths packets should take to reach their destinations. A path is an interconnected pattern of data links and nodes that connects two nodes in a network.
VINES RTP - Distributes network topology information.
VINES SPP - Supports a data stream between several types of clients and services. A data stream is a controlled flow of data between two processes.
VINES protocols work together within the framework of an OSI-like architectural model. Figure 10-1 shows this model and the protocols within each layer.
The protocols in each layer provide services to the protocols in the layer above it. For example, VINES SPP relies on VINES IP to move SPP messages through the network.
In some cases, protocols within the same layer rely on each other to perform their functions. VINES RTP relies on VINES IP to distribute topology information through the network, but VINES IP cannot make proper routing decisions unless VINES RTP properly builds and updates routing tables, which contain topological information.
When application programs, such as clients and services, send data in a VINES 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 header for delivery to the appropriate destination. By the time the application data is transmitted on the LAN or WAN, it is encapsulated in several headers.
For example, when a VINES redirector in a DOS, Windows, or OS/2 workstation uses VINES SPP to send a file to a VINES file service over an Ethernet LAN and a serial line for storage, the file is encapsulated.
The encapsulated file is shown in Figure 10-2.
Note: FRP applies only if the packet that contains the message requires fragmentation, such as when a 1500-byte Ethernet packet is routed across an HDLC line.
When the file is received at the destination server, each protocol removes its header and passes the remaining headers and the encapsulated file to the layer above. Eventually, just the original file remains, which is then delivered to the file service.
The term message refers to the transport layer header, the presentation/session layer headers and the application data. Messages are encapsulated in packets, which include the network layer header.
Applications such as clients and services are not the only sources of and destinations for data. For example, the network layer protocols VINES RTP, VINES ARP, and VINES ICP use VINES IP to perform their respective functions. Figure 10-3 shows the format of VINES IP packets that encapsulate the headers associated with these protocols.
Note: FRP applies only if the packet that contains the message requires fragmentation, such as when a 1500-byte Ethernet packet is routed across an HDLC line.
The exact format of the protocol headers depends on the protocols used to communicate. For more information on VINES protocols, see the VINES Protocol Definition.
For more information on the VINES architecture, see the VINES Architecture Definition.
Chapter 4 provides information on LAN statistics and Chapter 5 provides information on serial line statistics, with the exception of the VINES Fragmentation Protocol (VINES FRP). VINES FRP statistics are included with VINES IP statistics, and are described later in this chapter.
Accessing VINES Protocol Family Statistics
To access VINES protocol family statistics, perform the following steps:
1. Choose SHOW communications statistics from the VINES Network Summary menu. This action displays the Communications Statistics menu.
2. Choose ACCESS protocol family statistics from the Communications Statistics menu. This action displays the Protocol Families menu, as follows.
The Protocol Families menu lets you access statistics on all of the available protocol families on the server. This menu always displays VINES statistics. The menu displays TCP/IP statistics, and AppleTalk statistics only if those protocol families are running on the server.
3. Select VINES statistics. The Protocol Family Summary menu for VINES appears, as follows.
The Protocol Family Summary Menu for VINES displays all of the protocols in the VINES protocol family on which statistics are available. It displays summary statistics for VINES IP and SPP.
Detailed statistics are available for VINES IP, VINES RTP and VINES SPP. To view detailed statistics for these protocols, select the protocol and press ENTER.
The sections that follow describe the statistics that you can view through the Protocol Family Summary menu for VINES. Remember that you can press F10 to request an immediate update while viewing a detailed VINES protocol family statistics screen.
From the Protocol Summary Menu for VINES, you can view the total number of VINES 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 SPP or IPC messages that are destined for services on the server. RTP, ICP, and ARP packets that the server receives also count as part of Totin. Packets that the server routes. These packets originate from, and are destined for, other servers. Broadcast packets.
Totout includes counts for the following packets:
Packets that the server sends, such as packets containing IPC or SPP messages that services on the server send to clients and services on other servers. RTP, ARP, and ICP packets that the server sends also count as part of Totout. Packets that the server routes. Broadcast packets.
You can see that a single routed packet is counted in both Totin and Totout. When a server routes a packet in most cases, 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.
In some cases, the server receives a packet on one interface and forwards it on the same interface. When this happens, the server sends a routing redirect packet to the server or workstation that forwarded the packet to it. The routing redirect packet tells the server or workstation that it does not need to forward packets by way of the server.
Figures 10-6, 10-7, and 10-8 show VINES IP on a server sending a packet, receiving a packet, and routing a packet.
Factors That Affect VINES IP Traffic
VNSM summarizes how network configuration and other factors affect the server's performance and network traffic that VINES IP routes. The factors are as follows:
Number of services on the server. Number of LANs, HDLC, asynchronous, and X.25 lines connected to the server. Number of nodes directly connected to the server through LANs, HDLC, asynchronous, and X.25 lines. Whether the TCP/IP Routing option or the TCP/IP Server-to-Server option is installed on the server. VINES IP and IP in the TCP/IP protocol family often work together to tunnel TCP/IP traffic through VINES networks or tunnel VINES traffic through TCP/IP networks. Tunneling is a routing technique in which a packet from one protocol family, such as a VINES IP packet, is encapsulated in the protocol headers of another protocol family, such as TCP/IP. Tunneling allows the packet from the source protocol family to move through the other family's network.
When VINES and TCP/IP tunnel traffic through each other, they influence each other's statistics. TCP/IP protocol family statistics are described in Chapter 11.
Whether the server acts as an AppleTalk router. Like the relationship between VINES and TCP/IP, VINES and the AppleTalk Datagram Delivery Protocol (DDP) can work together to tunnel AppleTalk traffic through VINES networks. VINES IP and AppleTalk DDP influence each other's statistics. AppleTalk protocol family statistics are described later in Chapter 12.
Whether the server performs double encapsulation. Double encapsulation occurs when the server attempts to tunnel traffic using more than two protocol families. For example, when the server tunnels VINES traffic through SNA networks using the Server-to-Server over SNA option, the packets contain SNA and VINES protocol headers.
In both of these cases, VINES IP statistics counts are effected.
Figure 10-9 shows an example of VINES traffic being tunneled through a TCP/IP network. Figure 10-10 shows AppleTalk traffic being tunneled from a server through a VINES network.
To view detailed VINES IP statistics, select IP from the Protocol Summary Menu for VINES. The sections that follow describe the detailed VINES IP statistics.
Total in
The total number of VINES IP packets received.
Total out
The total number of VINES IP packets sent.
Bad Checksum
The total number of improperly formed packets that were received. This field increments by one each time an improperly formed packet is received. Software on the server that implements the VINES IP protocol looks at a checksum field in each packet to detect bit corruption in the packet. The Bad Checksum field can also indicate that a faulty board is not properly detecting erroneous frames.
Too Small
The number of packets received that were smaller than the minimum VINES IP packet length, which is the size of the VINES IP header (18 bytes).
Size of Data Link Header (in bytes) + 18 bytes
Too Small errors typically result from media errors.
Bad Length
The number of packets received that had an invalid packet length in the packet length field of the VINES IP header. This error occurs when the value of the packet length field in the VINES IP header does not match the actual length, in bytes, of the packet. Bad length errors typically result from media errors.
No Buffers Avail
The number of packets that could not be sent, received, or routed because of a lack of communication buffers. If these errors start to appear, check the Comm Buffer Use statistic, which is described in Chapter 6. If Comm Buffer Use is greater than 50 percent, consider increasing your communications heap space on the server. See Chapter 15 for information on increasing communication buffer space.
Routed
The total number of packets received that were routed to another node. This statistic includes the number of IP packets encapsulated within routed VINES IP headers. If this value is large in relation to Totin and Totout, the server is routing a lot of traffic for other nodes.
A packet is considered routed if it came in from a local LAN or wide-area network (WAN), but was not destined for the server itself. Each routed packet counts as both an incoming and outgoing packet. To calculate the percentage of packets routed, use this formula:
2 x Routed
------------------------ x 100
(Totin + Totout)
Servers that are heavy routers spend less time providing services to users. Whether this situation is intentional or desirable depends on your network configuration. For example, a communications server that is used for dial-up lines and terminal emulation gateways tends to show up as a heavy router. Servers connected on a backbone LAN will show more routing activity as more servers are added.
Use the following criteria, and the formula given above, to evaluate the impact of packet routing:
Standalone servers should show a value of 0 to 5 percent packets routed. An example of a standalone server is one that communicates over a LAN, but is not directly connected to the LAN backbone. Servers on a backbone LAN should show a value of 5 to 15 percent packets routed. Gateway servers should show a value of 15 to 70 percent packets routed. A gateway server acts as a router between different LANs and HDLC, asynchronous, and X.25 lines. An example of this kind of server is one that is on both an Ethernet and a ProNET-10 LAN, and can also communicate over an X.25 line. It should be considered an error condition if any server in a category above is routing a higher percentage than the maximum for that category.
Use one of the following methods to reduce the routing activity of a server:
Move the services that users most often use to a server on their immediate LAN. Add another LAN to connect the servers for which this server is performing routing. Make the LAN bypass the servers for which this server is performing routing.
Broadcasts
The number of VINES IP broadcast packets sent, both locally generated and routed from other nodes. The server counts each broadcast packet sent, received, or routed on each interface. In general, servers generate broadcasts to perform network maintenance functions such as updating routing information.
A broadcast packet is sent to multiple destinations. A bit map in the packet determines the number and types (server or workstations) of destinations to which the broadcast packet is sent, as well as the types of media over which it travels.
Fragmentations Done
The number of packet fragmentations performed. See the description for the Reassemblies field.
Fragments
The number of packet fragments that the server sent. When the size of a VINES 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 VINES FRP, and does not indicate errors. Fragmentation occurs when the server routes packets between LANs or WANs that support different frame sizes. For example, the maximum frame size that Ethernet supports is around 1500 bytes, and the maximum frame size the HDLC supports is around 150 bytes. When a 1400-byte VINES IP packet has to be routed from an Ethernet LAN to an HDLC serial line, the packet must be split up into 10 fragments - nine 150-byte fragments and one 50-byte fragment. The 10 fragments would be added to the Fragments count.
Fragments will be 0 if all of the server's network interfaces support 1500-byte frames. Otherwise, fragments will be non-zero. The Fragments count will be high on servers that route data between LANs, such as Ethernet and Token-Ring, and wide-area data links, such as HDLC, block asynchronous and X.25 data links.
The number of times packets were reassembled. Reassemblies result from the transmission of packets that must be broken into smaller pieces, then reassembled due to differences among LANs or other transmission media. ARCNET, Omninet, HDLC, and asynchronous dial-in/dial-out are among the media that require this process.
For example, one VINES IP packet that is broken into three message fragments to pass through ARCNET results in three fragments sent, and is counted as one fragmentation. The three fragments can then be reassembled into one VINES IP packet at another point, resulting in one reassembly.
Routed (HWM)
The largest number of packets routed in one second since the server was last booted (high-water mark).
Broadcast (HWM)
The largest number of packets broadcast in one second since the server was last booted (high-water mark). See the description above for an explanation of broadcast packets.
To IP (TCP/IP)
The number of packets that VINES IP passed to the TCP/IP protocol family's IP for encapsulation in IP headers. These packets were initially handled by VINES IP, but were passed to IP for routing through a TCP/IP network to a server. This field displays a non-zero value only if the TCP/IP Server-to-Server option is installed.
From IP (TCP/IP)
The number of packets that VINES IP received from IP to be unencapsulated into VINES packets. These packets originated from a server and traversed one or more TCP/IP networks. This field displays a non-zero value only if the TCP/IP Server-to-Server option is installed.
The VINES 5.50 RTP implementation differs significantly from the VINES 5.00 RTP implementation. In order to understand statistics on RTP packet traffic and other RTP information, you should know the kinds of RTP packets supported under both VINES 5.00 RTP and VINES 5.50 RTP. The next two sections provide an overview of RTP packets for each of these VINES revisions.
VINES 5.00 servers and workstations send and receive four types of RTP packets: routing request, routing response, routing redirect, and routing update packets.
Routing Request Packets
DOS and OS/2 workstations send a routing request packet to their routing server when they communicate with other servers that are not on their own LAN. This packet asks the routing server to reply with a routing response packet, which contains routing information that the workstation needs to communicate off its LAN.
VINES 5.00 workstations on LANs have full knowledge of neighbor servers, in addition to knowledge of their routing server and the servers and workstations with which they currently communicate.
VINES 5.00 workstations that dial in to networks send routing request packets whenever they have to communicate with servers and workstations outside the logical network of their routing server, which is the server that they dial in to. VINES 5.00 workstations that dial in just keep an entry for the routing server in their Table of Neighbors.
Servers also request routing table information from other servers when they establish a communication link across a WAN.
Routing Response Packets
Servers send routing response packets to DOS and OS/2 workstations in response to routing request packets.
Routing Redirect Packets
Servers transmit redirect packets to workstations and other servers to inform them of better routes.
Routing Update Packets
Servers and workstations that are neighbors on LANs broadcast routing update packets to each other every 90 seconds. They perform this action to inform neighbors that they are still on the network and, in the case of servers, to distribute news of changes in the network topology, such as a new server coming on the network. The routing update packets that are broadcast are full update packets, containing the workstation's or server's entire routing table.
Once the connection is established, servers and workstations that are neighbors of each other on wide-area data links (for example, block asynchronous, HDLC, X.25, TCP/IP Server-to-Server) broadcast routing update packets only when changes in the network take place, such as when a new server comes on line or a data link fails.
Note: VINES 5.50 servers and workstations exchange request, response, redirect, and update packets with VINES 5.00 servers and workstations in networks that have a mix of the two VINES revisions. VINES 5.50 servers and workstations implement both VINES 5.50 RTP and VINES 5.00 RTP.
Routing update packets serve two very important purposes:
They inform neighbors that the server or workstation that transmitted the packet is still on the network. If a neighbor on a LAN is not "heard from" for a period of 6 minutes, the remaining servers and workstations on the LAN remove the neighbor from their routing tables. They propagate news of network changes through the network. When neighbors that act as routers receive RTP update packets containing news of network changes, they propagate the news to their neighbors on all of their interfaces (including the interface that they received the news on). This process continues, from router to router, until the news reaches all the servers in the network.
When a new server comes on the network, it broadcasts RTP packets to neighbor servers and workstations to announce its arrival. Once a neighbor server that acts as a router includes the appropriate entries for the new server in its routing tables, it includes an entry for the new server in the next routing update packets that it broadcasts. This broadcast occurs on all interfaces. Other routers in the network propagate the news of the new server's arrival throughout the network in the same manner.
Figure 10-11 shows how news of a new server's (JPTOK002) arrival is propagated through the network. News of other network changes, such as servers going off the network or path changes, is propagated in the same way. Also note that servers propagate news of network changes on all of their network interfaces, including the interface on which they receive the news.
Servers do not perform a network-wide broadcast when network changes occur. Instead, the news of network changes is propagated across the network as a series of controlled data link broadcasts, from router to router.
VINES 5.50 servers and workstations send and receive four types of RTP packets: routing request, routing redirect, routing reinitialization, and routing update packets.
Routing Request Packets
DOS and OS/2 workstations send a routing request packet to their routing server in the following situations:
When they communicate with servers and other workstations that are not in their routing server's logical network. The request packet asks the routing server to reply with a routing update packet, which contains routing metric information that the workstation needs to communicate with the destination. When they communicate with their routing server through a Token-Ring bridge. The request packet asks the routing server for the appropriate routing metric to reach it. Note: VINES 5.50 servers respond differently from VINES 5.00 servers in answering the workstations' routing requests. Whereas 5.00 servers reply with a routing response packet, 5.50 servers reply with a routing update packet. The RTP header indicates that the routing update packet is of the response type.
Servers also request routing table information from other servers in the following situations:
When they establish a WAN connection When they detect the loss of a routing update During the initial routing update exchange with a new VINES 5.50 neighbor
VINES workstations do not keep full routing tables. They know only about their routing server (and its logical network) and the servers and workstations with which they currently communicate. Whenever the workstation needs to communicate with any server or workstation outside its routing server's logical network, the workstation must send a routing request packet to its routing server.
Chapter 13 provides more information on routing metrics, routing tables, routing servers, and logical networks.
Routing Redirect Packets
Servers transmit redirect packets to workstations and other servers to inform them of better routes to destinations. VINES 5.50 RTP uses redirect packets the same way as VINES 5.00 RTP uses them (see "VINES 5.00 RTP Packets" earlier in this chapter).
Routing Reinitialization Packets
A VINES 5.50 server broadcasts routing reinitialization packets on all of its interfaces when it detects that its neighbor servers do not have the most up-to-date routing information about it. These packets force the neighbor servers to remove all of the old routing information about the server that sent the original broadcast. The server that sent the original broadcast then follows up by sending routing update packets that contain the latest routing information.
VINES servers that are neighbors on LANs and WANs broadcast routing update packets to each other every 90 seconds. Servers perform this action to inform neighbors that they are still on the network.
When a new server joins or leaves the network, or when the routing metric for reaching a server changes, other servers distribute news of these changes within 2 seconds of the event. The information about the changes in the network are contained in routing update packets. VINES RTP does not perform a network-wide broadcast when network changes occur. Instead, the news of network changes is propagated across the network as a series of controlled data link broadcasts, from router to router, as illustrated in Figure 10-10.
Workstations send routing update packets to their routing server every 90 seconds on LANs. Workstations perform this action to inform their routing servers that they are still on the network. On PC Dial-in or X.29 Dial-in lines, workstations send routing update packets to their routing server (i.e., the server that they dial in to) only when they initially dial in to the network. They send routing response packets when requested by the routing server.
The routing update packets that servers and workstations transmit to announce their continued presence on the network are null update packets. This means that the packet is small, containing no routing table information. The packet just contains information about the server or workstation.
VINES servers use routing update packets to respond to routing request packets from workstations. The routing update packet header indicates that the packet is of the response type.
From the Protocol Summary Menu for VINES, you can view the total number of VINES RTP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs).
The Totin count is the total number of routing request, routing update, and routing redirect packets received, and the Totout count is the total number of routing update, routing response, and routing redirect packets sent.
The following factors affect the Totin and Totout counts:
The number of LAN and wide-area data link interfaces. The server broadcasts routing update packets every 90 seconds on all LAN interfaces and whenever network changes occur on wide-area data link interfaces. As the number of interfaces on the server increases, Totout will also increase. The number of servers that the server is directly connected to on its LAN and wide-area data link interfaces. As the number of servers increases, Totin will increase. Totout will also increase, but not to the degree that Totin increases. The number of workstations that the server is directly connected to on LAN interfaces. These workstations broadcast routing update packets to all of their neighbors every 90 seconds. If the server is a routing server, and the workstations for which it is the routing server run VINES and frequently communicate outside the routing server's logical network, the number of routing update packets that the server sends increases, influencing the Totout count. The number of routing redirect packets that the server sends may increase as well, especially if the routing server is not the best route to the destination. If the server is a routing server, and the workstations for which it is the routing server frequently communicate off the LAN, the number of routing response packets that the server sends will increase, influencing the Totout count. The number of routing redirect packets that the server sends may increase as well, especially if the routing server is not the best route to the destination. If the network exceeds 200 servers, servers send two packets for every routing update and routing response, thereby greatly influencing both Totin and Totout. Because each RTP packet contains a 6-byte entry for each server in the network, more than one packet is needed to deliver a full routing update or routing response when more than 200 servers are in the network.
Pay close attention to the Errs count for RTP if routing problems, such as destinations suddenly becoming unreachable, start to appear in the network. Routing problems can be caused by media problems, such as noisy serial lines, corrupting routing update packets. This in turn results in bad routes appearing in routing tables.
If you notice a consistent level of RTP errors in conjunction with routing problems, use VNSM to analyze the routing tables in the network. See Chapter 13 for more information on retrieving and interpreting routing table information.
To view detailed RTP statistics, select RTP from the Protocol Summary Menu for VINES. When the next screen appears, you can view the statistics that are described in the sections that follow.
When you view detailed RTP statistics retrieved from VINES 5.50 servers, you see many statistics. Unless otherwise noted, these statistics apply to both sequenced and non-sequenced RTP traffic. Sequenced RTP traffic originates from VINES 5.50 servers. Non-sequenced traffic originates from pre-5.50 servers and also from VINES 5.50 servers, which support non-sequenced RTP in order to be compatible with pre-5.50 servers.
Descriptions of interrelated statistics are combined. For example, Updates sent and Updates rcvd are combined as Updates sent/rcvd.
Total In and Total Out
The total number of RTP packets received (Total In) and sent (Total Out). These statistics are the same as the Totin and Totout counts for RTP on the Protocol Summary Menu for VINES.
Input errors
The total number of received RTP packets that contained one of the following errors:
Invalid RTP packet size, redirect packet or packet type. RTP packets that were received on a WAN interface (for example, HDLC, TCP/IP S-S) before the Security service assigned a security setting (Secure, Restricted, Unrestricted) to the interface. While a WAN connection initializes, the server rejects any RTP traffic received on the connection. Note that only pre-5.50 servers attempt to send RTP packets on an initializing WAN connection.
Pay special attention to the input errors count if routing problems start to occur. If you notice a consistent level of input errors in conjunction with routing problems, use VNSM to analyze the VINES routing tables in the network.
No Buffers Avail in/out
Number of times that no communication buffers were available to process received (in) or sent (out) RTP packets, to create routing table received (in) or sent (out) RTP packets, or to create routing table entries. If you notice a consistent level of these errors, increase the server's communication buffer size.
Updates sent/rcvd
Total updates sent or total update packets received. An update can consist of one or more update packets. For updates sent, just the update itself is counted, not the number of packets sent. For updates received, the total number of update packets received is counted.
Responses sent/rcvd
Total responses sent or total update or response packets received. A response can consist of one or more update packets (for VINES 5.50) or response packets (for VINES 5.00).
For the sent total, just the response itself is counted, not the number of packets sent. Keep in mind that a single response can consist of multiple response packets.
For the received total, the total number of packets received is counted.
Requests in/out
Total request packets sent or received.
Request Lookups sent/rcvd (Sequenced Only)
Total packets sent or received that requested specific routing information, such as information on a network. VINES 5.50 PCs send lookup requests to their routing servers when they need to communicate with a node in a network other than their routing server's network. The lookup request asks the routing server for the appropriate routing metric to reach the destination network.
Request SLR Info rcvd (Sequenced Only)
Total request packets received that requested VINES routing metric information on a source-level route. When a PC communicates with its routing server through a Token-Ring bridge, the PC sends a request for the appropriate routing metric to reach the routing server. The routing server responds with the correct metric based on the source-level route that the client uses.
Reinit sent/rcvd (Sequenced Only)
Total reinitialization packets sent or received. If a VINES 5.50 server detects that its neighbor servers do not have the most up-to-date routing information about it, the server broadcasts these packets on all of its interfaces. These packets force the neighbors to remove all information about the server. The server then follows up with routing update packets that contain the latest information about it.
Resync sent/rcvd (Sequenced Only)
Total number of resynchronization operations sent or update packets received that contained information for synchronizing routing table entries. A single resynchronization operation can consist of one or more update packets. VINES 5.50 servers use a special sequencing algorithm to synchronize entries in routing tables across the network.
These sent and received totals are subsets of updates sent and received.
Redirects sent/rcvd
Total redirect packets sent or received.
Fragments sent/rcvd (Sequenced Only)
Total update or response fragments sent or received. When an update or a response contains entries for more than 100 logical networks, the update or response must be broken into fragments. Each fragment is contained in an update packet. Remember that responses are sent in update packets.
Fragments dropped
This statistic indicates the total number of fragments dropped because they could not be re-assembled in a 1- to 2-minute time period. When the server receives the first fragment in an update or response, it sets a timer for a period of 1 to 2 minutes. Fragments that cannot be reassembled after the timer expires are dropped.
Fragments dropped (no buffers)
This statistic indicates the total number of fragments dropped because the server lacked sufficient communication buffers to format and transmit them. If this error persists, increase the communication buffer size.
Invalid Fragments (Sequenced Only)
Total number of RTP fragments discarded because they had packet Ids that were out of sequence. Each update or response is assigned a packet Id. When an update or response is broken into fragments, each fragment has the same Id. This prevents the intermingling of fragments from different updates or responses. A fragment is considered invalid when its Id does not match those of the other fragments received.
Duplicate Fragments (Sequenced Only)
Total number of RTP fragments that were dropped because they were duplicates of other fragments. Duplicate fragments show up frequently if there are parallel Token-Ring bridges between two servers.
Fragmentations/ Reassemblies Done (Sequenced Only)
Total number of updates and responses that were fragmented or reassembled successfully. An update or response is successfully fragmented when all fragments are formed and transmitted. A successful reassembly occurs when all fragments in the update or response are reassembled within a 1- to 2-minute period after the first fragment is received.
Fragmentations/ Reassemblies Faild (Sequenced Only)
Total number of updates and responses that were not successfully fragmented or reassembled.
Outdated Packets (Sequenced Only)
Total received RTP packets discarded because they are outdated. An RTP packet is considered outdated when the sequence number in its packet header is lower than the sequence number associated with the sending server in the receiving server's routing table.
Sequence numbers allow servers to determine whether the routing table information they receive from neighbor servers is up to date. In their routing tables, neighbor servers associate sequence numbers with each other. Each time one neighbor server sends new topology information to another, the sending server increments its sequence number by 1.
If, for example, the sending server has a major system failure later on and is restored from an old backup, it is possible that the sending server will attempt to distribute routing table information with an outdated sequence number. The receiving server compares the out-of-date sequence number (lower than the sequence number before the failure) in the RTP packets with the sequence number of the sending server prior to the system failure, and thereby determines that the sending server is distributing bad information.
Old Net Info (Sequenced Only)
Total outdated entries for logical networks received. An entry is considered outdated when it is received from a server that has an invalid sequence number for the advertised network.
Invalid Redirects
Total invalid redirect packets discarded because they had a bad length.
Broadcasts outgoing/incoming
Total broadcasted RTP update packets sent or received. RTP packet fragments are also included in these counts.
Routes created/modified by redirects
Total routes created or modified by redirect packets.
Neighbor Anchor/Host Entries
Total entries in the Table of Neighbors (Anchor) or total paths to all neighbors. The Host Entries statistic may not match Neighbor Anchor Entries because there can be more than one path to a neighbor.
Network Entries
Total entries for networks in this server's routing table.
Routing Lookup Calls
Total calls by the server to look up routing table entries.
Failed Routing Lookups
Total lookup calls that failed to find a usable route.
Non-sequenced Total in/out
Total non-sequenced RTP packets sent or received. Note that all non-sequenced totals are subsets of previous totals.
Non-sequenced Total in errs
Total errors while receiving non-sequenced RTP packets.
Non-sequenced Updates sent/rcvd
Total non-sequenced routing update packets sent or received.
Non-sequenced Responses sent/rcvd
Total non-sequenced routing response packets sent or received.
Non-sequenced Requests sent/rcvd
Total non-sequenced routing request packets sent or received.
Non-sequenced Redirects sent/rcvd
Total non-sequenced routing redirect packets sent or received.
Invalid Non-sequenced Redirects rcvd
Total invalid non-sequenced redirect packets sent or received.
Non-sequenced Broadcasts sent/rcvd
Total non-sequenced RTP broadcast packets sent or received.
The SPP is a transport layer protocol that supports the transfer of packets on an SPP or virtual connection. This connection acts as a data pipe between two processes in the network such as two peer services or a service and a client.
SPP connections are temporary. They are established when two processes in the network want to communicate, and are terminated when those processes are finished transferring data. You can view detailed SPP statistics on SPP connection usage.
See the previous section, "Overview of the VINES Protocol Family," for a description of SPP messages.
From the Protocol Summary Menu for VINES, you can view the total number of VINES SPP message packets that were received (Totin), that were sent (Totout), and that contained errors (Errs).
Factors That Affect SPP Connection Usage and SPP Traffic
The factors that affect SPP connection usage and the Total in and Total out counts are the number of services on the server that use SPP to communicate with their respective clients and the number of users of these services. The following services use SPP:
VINES File Services - Each DOS, Windows or OS/2 user of a VINES file service uses an SPP connection to communicate with the service.
3270/SNA - Each active LU session requires an SPP connection to the client.
synchronous Terminal Emulation - Each active host session requires an SPP connection to the client.
STDA - The STDA service uses an SPP connection for a session with the STDA client.
Print - Each invocation of PCPRINT establishes an SPP connection to the specified print service.
Security Service - When a user logs in, the service establishes an SPP connection with the workstation client to deliver profile information. The connection terminates as soon as the delivery is complete.
Third-party - Third-party services can also use SPP connections.
You can view statistics on the number of SPP connections that each service is using through the SHOW service statistics function. See Chapter 7 for more information.
To view detailed SPP statistics, select SPP from the Protocol Summary Menu for VINES. When the next screen appears, you can view the statistics that are described in the sections that follow. Unless otherwise noted in the description of the statistic, assume that the statistic is supported under VINES 5.50 only.
Descriptions of interrelated statistics are combined. For example, Disconnect Packets sent and Disconnect Packets rcvd are combined as Disconnect Packets sent/rcvd.
Total In and Total Out
The total number of SPP messages received (Total In) and sent (Total Out). For some servers, these fields are always filled with dashes. The dashes indicate that the product revision on the server does not support these statistics. These statistics are supported under both VINES 5.00 and VINES 5.50.
Input errors
The total number of received SPP messages that contained errors. For some servers, this field is always filled with dashes. The dashes indicate that the product revision on the server does not support this statistic. This statistic is supported under VINES 5.00 and VINES 5.50.
The maximum allowable number of SPP connections that can be in use by processes on the server at one time. This value is set from the server console. See Chapter 15 for information on setting the number of SPP connections. This statistics is supported under both VINES 5.00 and VINES 5.50.
Max SPP connections (HWM)
The maximum number of SPP connections in use at one time (high-water mark) since the server was rebooted. This statistic is supported under VINES 5.00 and VINES 5.50.
Connections in use
The number of SPP connections that are currently in use. This statistic is supported under VINES 5.00 and VINES 5.50.
Bad Packets
The total number of packets received on SPP connections that had invalid SPP packet types. Valid SPP packet types are data, disconnect, probe, and acknowledgement.
Dropped: no buffer space in
Total number of SPP packets that could not be received because the communication buffer space was insufficient or because the message was larger than 65,535 bytes. If this error persists, increase the communication buffer size and check that applications are not attempting to send messages that exceed 65,535 bytes.
Dropped: no port
Total number of incoming packets that SPP dropped for the following reasons:
No application had opened a port that matched the destination port number in the SPP header. No application had established a connection with an Id that matched the connection Id in the SPP header.
Bad Packets: duplicates
Total number of incoming packets that were duplicates of other packets. SPP drops these packets.
Bad Packets: out of order
Total number of incoming packets that were received out of order. SPP drops these packets and asks the sender to retransmit them in the proper order.
Data packets rcvd
Total number of data packets received on SPP connections. Data packets contain application data.
Acknowledgment packets sent/ rcvd
Total number of acknowledgement packets sent and received. SPP uses these packets to explicitly acknowledge to the sender that the sender's data was received properly.
Disconnect Packets sent/ rcvd
Total number of disconnect packets sent and received. When one end of an SPP connection wants to terminate the connection, it sends a disconnect packet to the other end.
Probe Packets sent/rcvd
Total number of probe packets sent and received. When one end of an sent/rcvd SPP connection misses a packet, it sends a probe packet to the other end of the connection. The other end of the connection then retransmits the missed packet along with all other packets sent after it.
Data Packets sent
Total number of data packets sent on SPP connections.
Abort Packets sent
Total number of data packets that had the abort bit set. When an SPP message contains more than one packet and one of the packets has the abort bit set, SPP aborts the entire message. The abort bit is set when a failure occurs; for example, when a program that uses SPP shuts down.
Local Packets
Total number of packets sent locally using SPP. Two applications on the same server can use SPP to communicate.
