Chapter 12 - AppleTalk Protocol Family Statistics
This chapter tells you how to access and interpret statistics on AppleTalk communication protocol activity on the VINES server. These protocols define the rules and procedures that users, application programs, and AppleTalk network nodes, such as servers that run AppleTalk and Macintosh workstations, must follow in order to communicate in AppleTalk networks.
Overview of the AppleTalk Protocol Family
VNSM provides statistics on the following protocols in the AppleTalk protocol family:
AppleTalk Address Resolution Protocol (AARP) - Enables a server to learn LAN addresses of nodes. Using AARP packets, a server requests the LAN address from the nodes on the LAN for a particular network address and the nodes respond.
Datagram Delivery Protocol (DDP) - Like VINES IP, DDP 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.
Name Binding Protocol (NBP) - NBP is responsible for resolving AppleTalk names of network entities, such as servers, file volumes and printers, and their network addresses.
AppleTalk Transaction Protocol (ATP) - ATP is a transport layer protocol that is responsible for handling the exchange of packets between source sockets and destination sockets. A socket identifies communicating clients and services, such as AppleTalk file clients and print clients and their associated services.
Zone Information Protocol (ZIP) - ZIP is responsible for mapping network numbers and zones in the network and for servicing requests from AppleTalk nodes for obtaining and changing the mapping.
A zone is a grouping of AppleTalk networks. For example, suppose that an AppleTalk internetwork consists of 4 networks, with each network consisting of an Ethernet LAN segment. The network administrator could decide to put two networks in ZONE1 and two networks in ZONE2.
The zone names make up part of an AppleTalk name. For example, the AppleTalk file server
SERVER1:AFPServer@ZONE1
resides on one of the nodes in ZONE1.
The rules for mapping zones to networks differ between AppleTalk Phase 1 and AppleTalk Phase 2. Phase 1 allows only one zone per network. Phase 2 allows many zones per network.
Routing Table Maintenance Protocol (RTMP) - RTMP is responsible for building and updating routing tables on AppleTalk routers.
AppleTalk Session Protocol (ASP) - ASP is a session layer protocol that is responsible for handling a session between a client and a service. Clients and services that are in session with each other are called session partners.
ASP uses the services of the AppleTalk Transaction Protocol (ATP) to move data packets between sessions partners. At this time, ASP is used for AppleTalk Filing Protocol (AFP) communication only.
AppleTalk Echo Protocol (AEP) - AppleTalk nodes use AEP to determine if other nodes can be reached over the network and to calculate the time it takes for packets to travel to other nodes and back.
Like VINES protocols, AppleTalk protocols work together within the framework of an OSI-like architectural model. Figure 12-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, ASP relies on ATP and DDP to move ASP messages through the network.
In some cases, protocols within the same layer rely on each other to perform their functions. DDP relies on AARP to send routing update packets through the network, but AARP may make improper routing decisions unless routes created by DDP packets are correct.
When application programs, such as the VINES AFP service, send data in a AppleTalk 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 AFP service uses ASP to send file data to a Macintosh workstation, the file is encapsulated as follows:
When the file data is received at the destination AppleTalk node, each protocol removes its header and passes the remaining headers and the encapsulated file data to the layer above. Eventually, just the original file data message remains.
Keep in mind that applications such as the VINES AFP service or VINES print services are not the only sources of and destinations for AppleTalk data. For example, the protocols RTMP, AEP, ZIP, and NBP use DDP to perform their respective functions. Figure 12-3 shows the format of DDP packets that encapsulate the headers associated with these protocols.
It is important to note that AppleTalk AARP packets do not have a DDP header and therefore are not counted as part of the DDP statistics. The AARP header immediately follows the data link header, as shown in Figure 12-4.
The exact format of the protocol headers depends on the protocols used to communicate. If you need more information on AppleTalk protocols, refer to Inside AppleTalk.
Accessing AppleTalk Protocol Statistics
To access statistics on the activity of AppleTalk 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 AppleTalk statistics from the Protocol Families menu. The Protocol Family Summary menu for AppleTalk appears, as follows.
The Protocol Family Summary Menu for AppleTalk displays all of the protocols in the AppleTalk protocol family on which statistics are available. The menu displays summary statistics for each protocol.
The Errs summary total is the sum of the Dropped counts (also called "Drops") for all the protocols. The following DDP statistics are also included in the Errs count:
Short Dropped (not dest) Wrong Length Bad Socket Number Checksum Error
The menu also tells you which AppleTalk phase (Phase 1 or Phase 2) is running on the server, and whether the server can tunnel AppleTalk traffic to other servers. If the server can tunnel AppleTalk traffic to any requesting server, routing is Unrestricted. If the server can tunnel AppleTalk traffic to designated servers only, routing is Restricted. See Managing AppleTalk for more information on AppleTalk phases and routing restrictions.
Detailed statistics are available for all of the protocols. To access detailed statistics for an AppleTalk protocol, select that protocol from the Protocol Family Summary Menu for AppleTalk.
Remember that you can press F10 to request an immediate update while viewing a detailed statistics screen.
From the Protocol Summary Menu for AppleTalk, you can view the total number of AARP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs).
There are three types of AARP packets:
AARP Request - An AppleTalk node, such as servers that have AppleTalk configured and Macintosh workstations, broadcasts these packets when it needs to know the data link address of another node, and the broadcasting node knows only the AppleTalk internet address of the other node.
Servers typically issue this broadcast when they come on the network, such as when they reboot, when an AppleTalk port is enabled through the AppleTalk configuration program, when AppleTalk is started through the configuration program or when a Macintosh first issues a file or print request to the server, such as when a user logs in to the AFP service or submits a print job.
AARP Response - AppleTalk nodes reply to AARP request packets with AARP response packets, which contain the requested data link address.
AARP Probe - AppleTalk nodes send probe packets on ports that are initializing to determine if a dynamically selected node ID is already in use. In most cases, a port initializes when the server reboots, when the node ID is obtained for a port, or when AppleTalk is started through the configuration program.
The node ID is the part of an AppleTalk internet address that uniquely identifies a node in an AppleTalk network. The other part of the address is a network number, which identifies the network. When an AppleTalk node comes on the network, it selects a tentative node ID and broadcasts probe packets on its LAN to determine if another node has already assigned itself that ID. If another node has already assigned itself the node ID, it responds to the probing node with an AARP response packet. The probing node must try a new node ID, and repeats the probe broadcast using a new node ID.
If the probing node does not receive an AARP response to its probe, it re-broadcasts the same probe several times. If the probing node does not receive an AARP response to the repeated probes, it accepts the node ID.
The Totin count will be the total number of AARP request, response, and probe packets received, and the Totout count will be the total number of these packets sent.
The Totin and Totout counts are influenced by the total number of AppleTalk nodes to which the server is directly connected, and the frequency with which these nodes broadcast AARP packets. Keep in mind that high periods of AARP broadcast activity may occur during times of the day when large numbers of users start their Macintosh workstations, such as in the morning.
When you select ARP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed AARP statistics, which are described in the sections that follow.
Total in
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Dropped
The number of received AARP packets that could not be processed. Typical reasons why an AARP packet cannot be processed are as follows:
The AARP header is badly formed. For example, the AARP header may be too short. The server lacks sufficient communication buffers to process the packet. Consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size. The AARP hardware or command type is unknown. The server received its own AARP broadcast packet. The server receives the AARP packet on an AppleTalk port that is probing for its node ID.
In (HWM)
The number of AARP packets that were received at the high water mark. This value is the largest number of packets that were received in a one second period. Typically, the high water mark will occur during times of the day when large numbers of Macintosh users start their workstations.
In (last sec)
The number of AARP packets that were received over the last second.
Current Cache Size
The number of AARP entries currently in the AARP cache. The AARP cache has no maximum size. It grows and diminishes in size depending upon use of the AARP entries.
A cache size of 0 indicates that no AARP activity is taking place. This is not a problem if only LocalTalk interfaces are in use as AppleTalk ports. In this case, the cache size should be 0.
However, EtherTalk and TokenTalk® require the use of AARP. If the server has EtherTalk or TokenTalk ports, a cache size of 0 indicates that a problem exists. In many cases, bad cabling causes AARP failures.
You can display the entries in the AARP cache. See the section "AppleTalk ARP Cache" in Appendix A for more information.
From the Protocol Summary Menu for AppleTalk, you can view the total number of DDP 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 AFP or Printer Access Protocol (PAP) data. RTMP, NBP, ZIP, and AEP 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 AppleTalk nodes. |
Totout includes counts for the following packets:
Packets that the server sends, such as packets that contain AFP or PAP data. RTMP, NBP, ZIP, and AEP 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 DDP 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 12-6, 12-7, and 12-8 show DDP on a server sending a packet, receiving a packet, and routing a packet.
The totals for DDP will be considerably larger than the totals for the other protocols on the Protocol Summary Menu for AppleTalk. All the other protocols except AARP use DDP. All other protocols just send and receive packets. Keep in mind that DDP sends, receives, and routes packets.
Factors That Affect DDP Traffic
VNSM summarizes how the server's performance is affected by network traffic that DDP routes. The quantity of DDP traffic depends on:
The quantity of AFP, PAP, and VINES Macintosh Mail that the server sends and receives. The number of Macintosh users of VINES file services and PAP-compatible network printers determines these quantities. If the server is an AppleTalk router, the number of AppleTalk nodes directly connected to the server through LANs affects network traffic. A server is a router when it routes traffic between EtherTalk or TokenTalk LANs, or it routes traffic between EtherTalk or TokenTalk LANs and a VINES network. To route AppleTalk traffic through a VINES network, a routing technique called tunneling is used. See the section, "VINES IP Statistics," in Chapter 10 for a description of tunneling.
When you select DDP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed DDP statistics. The sections that follow describe these statistics.
Total In
The total number of DDP extended packets received. These packets are either destined for this server or need to be routed to another destination.
AppleTalk Phase 2 uses DDP extended packets exclusively. For AppleTalk Phase 1, these packets are exchanged between nodes that do not reside in the same AppleTalk network. For Phase 1, An AppleTalk network maps to a LAN segment.
Total Out
The total number of DDP extended packets that originated from this server. These packets are destined for other AppleTalk nodes.
Total In (short)
The total number of AppleTalk short packets received. AppleTalk Phase 1 nodes that reside on the same network exchange short packets. An AppleTalk network maps to a LAN segment. AppleTalk Phase 2 nodes send short packets only on LocalTalk connections, and extended packets on all others.
Total Out (short)
The total number of AppleTalk short packets that originated from the server. These packets are destined for other AppleTalk nodes on an attached cable. If the server runs AppleTalk Phase 2, this statistic is 0.
Dropped
The number of DDP packets that could not be received for later processing for the following reasons:
Server resources, such as communication buffers, are insufficient. If dropped packets persist, consider increasing the communication buffer size from the server console. See Chapter 15 for information on how to increase communication buffers. The DDP header is too short. The DDP header has an invalid or unknown type. The packet was received through a VINES tunnel, and the AppleTalk tunneling header is not the correct version.
The Short Dropped statistic is not included as part of the Dropped count.
Short Dropped (not dest)
The number of DDP short packets that were dropped because the destination node address did not match the node address of the AppleTalk port on the server through which the packets were received.
Wrong Length
The number of received DDP packets that had a length field that specified an incorrect packet length. For example, a packet was received that contained 390 bytes, and the length field specified 400 bytes. These packets are discarded.
Wrong length errors can also occur if the value of the length field is greater than 586 bytes. A DDP packet cannot be longer than 586 bytes (including the DDP header).
A significant number of wrong length errors can indicate packet corruption problems in the network. These problems can be caused by bad cables or router failures.
Undel (bad dest)
The number of times that the server attempted to route a DDP packet to a destination network that has no entry in the server's AppleTalk routing table. Causes of this error include cable failures and router failures.
Forwarded (last sec)
The number of AppleTalk packets that the server routed over the last second. These packets did not originate from, and are not destined for, the server. The packets originated from, and are destined for, other AppleTalk nodes.
Routed
The total number of packets that the server routed.
Routed (HWM)
The high water mark, in number of packets, of routing activity on the server. The high water mark is a one second period in which the largest number of DDP packets were routed.
Undel (No Dest Sock)
The number of times that a packet could not be delivered because there was no listener for the destination socket.
A listener is a process, such as the AFP service, or low-level protocol, such as RTMP, that is the destination for a packet.
DDP sockets are used by processes, such as the AFP service and the PostScript print queue in a VINES print service, or by low-level network protocols such as RTMP and AEP, as identifiers. The DDP socket number is the part of the AppleTalk internet address that identifies the communicating process or network protocol.
Do not confuse DDP sockets with VINES sockets. DDP sockets are identifiers of communicating entities. VINES sockets are internal control blocks that are used to send and receive user data.
Bad Socket Number
The number of times that a packet containing an invalid socket number was received. Invalid socket numbers are 0 and 255.
Checksum Error
The number of received DDP packets that failed the checksum error checking procedure. This procedure is designed to determine if all the bytes in the packet were received correctly. Packets that fail this check are discarded.
A significant number of checksum errors can indicate packet corruption problems in the network. These problems can be caused by bad cables or router failures.
There is a field in the DDP packet header that indicates if the packet should undergo checksum error checking. Typically, checksum error checking is not used in most AppleTalk implementations unless requested by the socket user.
If the server forwards an AppleTalk packet with a non-zero checksum field, the server verifies the checksum before forwarding the packet.
Hop Count Exceeded
The number of extended packets that the server did not route because they had travelled 15 hops, which is the maximum number of hops that AppleTalk allows. Keep in mind that the hop count field is found in AppleTalk extended packets only.
A hop count exceeded condition results from a poor network design or from a packet looping between routers. If the network is poorly designed, position routers in the network so that no route exceeds 15 hops.
Looping conditions involve packets repeatedly looping between two or more routers. Looping conditions may temporarily occur when AppleTalk networks become unreachable and the entries for them disappear from the routing tables of some routers, and the disappearance is not synchronized with other routers. Eventually, all of the routing table entries will age, ending the looping condition unless there is a failure in a router.
Cable Bcasts In
The number of cable broadcast packets received. Cable broadcasts are transmitted to all nodes on a LAN segment.
Cable broadcast packets may start out as network broadcast packets. See the "Network Bcasts in" description later for more information on network broadcasts.
Cable Bcasts
The number of cable broadcast packets sent.
The number of network broadcast packets received. Network broadcast packets are directed. When an AppleTalk node sends a broadcast packet to a network that is not on an attached LAN segment, the routers along the path to the destination network forward the packet until it reaches the router that is directly connected to the destination network. This router then issues a cable broadcast to all the nodes on the network.
Network Bcasts Out
The number of network broadcast packets sent.
Loopback
The number of loop backs. A loopback occurs when the server sends a DDP packet to itself.
To VINES
Number of DDP packets passed to the VINES Internet Protocol (VINES IP). These packets needed to be tunneled through a VINES network in order to reach their destination.
From VINES
Number of DDP packets received from VINES IP. These DDP packets were received after being tunneled through a VINES network.
Current Dynamic Sockets
The number of open dynamic DDP sockets that are being used to send and receive AppleTalk data. Dynamic sockets are assigned by AppleTalk to the following application programs: the AFP service, a PostScript print queue (which is part of a VINES print service), and applications written with the VINES AppleTalk API.
There is a maximum of 127 dynamic sockets per server. (This number is an AppleTalk DDP limitation.) If this limit is exceeded, some AppleTalk users may not be able to connect to the server. If just AFP and PostScript print queues are on the server, and no AppleTalk API applications are running, you should never run out of dynamic sockets. AFP and the PostScript print queue consume dynamic sockets as follows:
AFP - Uses one dynamic socket for 256 active user sessions and allocates more sockets on demand. Because 127 dynamic sockets are available to AFP, it can theoretically handle up to 32,512 active sessions at once. PostScript Print Queue - Uses one dynamic socket per current print job. Since a single PostScript print queue can handle a maximum of 6 print jobs at once and there can be no more than 20 PostScript print queues per server, PostScript print jobs can consume a maximum of 120 sockets.
Thus, AFP and PostScript print queues can consume up to 127 dynamic sockets on the server.
Current Static Sockets
The number of open static DDP sockets that are being used to send and receive AppleTalk data. In the VINES implementation of AppleTalk, a static DDP socket is reserved for each of the following AppleTalk communication protocols: RTMP, NBP, AEP, and ZIP.
From the Protocol Summary Menu for AppleTalk, you can view the total number of NBP packets that were received (Totin), that were sent (Totout), or that contained errors (Errs). NBP packets are DDP packets that perform the operations required by NBP.
There are four types of NBP packets:
Broadcast Request - These packets are received from clients, such as Macintosh workstations, that are directly connected to the server.
AppleTalk clients transmit broadcast request packets to routers when they need the name of an entity, such as a file volume or printer.
When an AppleTalk Phase 1 server receives a broadcast request packet, the server converts it to a lookup request packet. The lookup request packet is then sent as a DDP network broadcast packet to each network that has a zone list that contains the destination zone.
Lookup Request - A lookup request packet is received as a cable broadcast or zone multicast that is sent by another AppleTalk router on behalf of an original requesting node. If the names that are being looked up exist, a lookup reply is sent to the original requestor.
Lookup Reply - Lookup reply packets are sent or received in response to lookup request packets. Lookup reply packets contain information that resolves names of network entities to their network addresses.
Forward Request - The server receives forward request packets from other AppleTalk routers.
Forward request packets originate as broadcast request packets from clients. AppleTalk clients transmit broadcast request packets to routers when they need the name of an entity, such as a file volume or printer.
When an AppleTalk Phase 2 router receives the broadcast request packet, the router converts it to a forward request packet if the request is for a zone that is one or more hops away. The forward request packet is then sent as a DDP network broadcast packet to each network that has a zone list that contains the destination zone.
Eventually, the forward request packet is converted to lookup request packets by routers connected to the destination networks. The lookup request packet is sent as a zone multicast.
Forward request packets apply to AppleTalk Phase 2 only.
When you select NBP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed NBP statistics. The sections that follow describe these statistics.
Total In
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total Out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Dropped
The total number of NBP packets that could not be received for later processing for the following reasons:
Server resources, such as communication buffers, are insufficient. If dropped packets persist, consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size. The NBP header is too short The packet type is unknown The server received the packet on an AppleTalk port that is not operational or has not fully initialized
If this dropped packets persist, consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size.
The following NBP statistics are included in the Dropped count:
Bcast Requests Dropped Lkup Requests Dropped Lkup Replies Dropped Fwd Requests Dropped
Bcast Requests In
The number of broadcast request packets that have been received.
Bcast Requests Dropped
The number of broadcast request packets that the server dropped because of problems, such as insufficient communication buffer space. If drops persist, consider increasing the size of the communication buffer on the server. See Chapter 15 for more information on increasing the communication buffer size.
Causes of dropped broadcast request packets other than insufficient communication buffer space are as follows:
The destination DDP socket number in the NBP header does not match the names information socket (NIS) number. The object, type, or zone field length is greater than 32. The request is for zone *, the server runs AppleTalk Phase 2, and the packet is not received on a LocalTalk interface. The request is for a zone name that is not in the server's Zone Information Table.
Lkup Requests In
The number of lookup request packets received.
Lkup Requests Dropped
The number of lookup request packets that the server dropped because of problems such as insufficient communication buffer space. If drops persist, consider increasing the size of the communication buffer on the server. See Chapter 15 for more information on increasing the communication buffer size.
Causes of dropped lookup request packets other than insufficient communication buffer space are as follows:
The destination DDP socket number in the NBP header does not match the names information socket (NIS) number. The request is for a zone name that is not in the server's Zone Information Table.
Lkup Requests Out
The number of lookup request packets sent.
Lkup Replies In
The number of lookup reply packets received.
Lkup Replies Dropped
The number of lookup reply packets that the server dropped due to problems, such as insufficient communication buffer space. If drops persist, consider increasing the size of the communication buffer on the server. See Chapter 15 for more information on increasing the communication buffer size.
Lookup reply packets are also dropped if they are received after the lookup request that asked for the reply has timed out.
Lkup Replies Out
The number of lookup reply packets sent.
Fwd Requests In
The number of forward request packets received.
Fwd Requests
The number of forward request packets that the server dropped because of problems such as insufficient communication buffer space. If drops persist, consider increasing the size of the communication buffer on the server. See Chapter 15 for more information on increasing the communication buffer size.
Causes of dropped forward request packets other than insufficient communication buffer space are as follows:
The destination DDP socket number in the NBP header does not match the names information socket (NIS) number. The object, type, or zone field length is greater than 32. The request is for zone *, or no zone name is specified. The request is for a zone name that is not in the server's Zone Information Table.
Fwd Requests Out
The number of forward request packets sent.
Svr Confirm Requests
The number of server confirm request packets that the server sent. An AppleTalk-based service on the server sends these request packets to other AppleTalk nodes to confirm that names that were looked up previously on those nodes (using the same DDP socket and AppleTalk internet address) still exist. These names must be registered on those nodes.
Svr Lookup Requests
The number of times that an AppleTalk-based service on the server looked up an AppleTalk name on the network.
Svr Register Requests
The number of times that an AppleTalk-based service on the server registered a name on the server.
Svr DelOne Requests
The number of times that an AppleTalk-based service on the server attempted to delete a specific name that they had previously registered.
Svr DelAll Requests
The number of times that an AppleTalk-based service attempted to delete all the names that they had previously registered with a particular AppleTalk internet address.
Total Deletions
The total number of times that names were deleted from the server.
Total Additions
The total number of times a name was registered on the server.
Current Table Size
The current number of entries in the server's AppleTalk name table. You can display the entries in the AppleTalk name table. See the section "AppleTalk Names" in Appendix A for more information.
From the Protocol Summary Menu for AppleTalk, you can view the total number of ATP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs). ATP packets are DDP packets that perform the operations required by ATP.
When a client and a service use ATP to communicate, one will send a request and the other will reply to the request by sending a response. This interaction is called a transaction. During this interaction, the requestor sends requests in the form of transaction request packets. The responder sends responses in the form of transaction response packets. There can be up to eight response packets for each request.
The Totin and Totout counts include the number of transaction request packets, transaction response packets and transaction release packets sent and received. A transaction release packet acknowledges the reception of all the transaction response packets for the transaction. For example, suppose that a Macintosh workstation user writes data to a file on a file volume on the server. The write request would be sent in a transaction request packet. When the server performs the write operation, it sends a transaction response packet to the workstation. The workstation then sends a transaction release packet to the server.
ATP Error Recovery Transaction Procedures
ATP provides two error recovery transaction procedures for when request packets or response packets are lost or the client and service cannot reach each other:
At-least-once (ALO) transactions Exactly-once (XO) transactions
In an ALO transaction, the sender of the request retransmits the request until the sender receives a response or until the specified number of retries is done. The receiver of the request may receive the request multiple times.
In an XO transaction, the sender of the request retransmits the request multiple times, just like an ALO transaction. However, the receiver of the request receives the request only once. When the sender of the request receives a response, the sender of the request transmits a transaction release packet, informing the receiver that the XO transaction completed successfully.
When you select ATP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed ATP statistics. The sections that follow describe these statistics.
Total In
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total Out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Dropped
The number of transaction request packets, transaction response packets, and transaction release packets that could not be received for later processing for the following reasons:
Server resources, such as communication buffers, are insufficient. If this problem persists, consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size. The ATP header is too short. The ATP packet type is unknown. The ATP packet is received on an AppleTalk port that is disabled or not fully initialized.
The Requests Dropped, Responses Dropped, and Releases Dropped statistics are not included as part of the Dropped count.
XO In
The number of transaction request packets received during XO transactions.
XO Out
The number of transaction request packets sent during XO transactions.
Dup XO
The number of duplicate transaction request packets received during XO transactions. During an XO transaction, the first transaction request packet received is processed, and all succeeding transaction request packets are treated as duplicates and filtered out. Dup XOs are normal and usually indicate that responses sent back to clients were lost on the network. The responses are retransmitted.
Responses In
The number of transaction response packets received.
Responses Out
The number of transaction response packets sent.
Request Timeout
The number of times that a request timeout occurred. This timeout occurs when the maximum number of retries is exceeded. ATP requests are transmitted every 30 seconds until a response is received or the maximum number number of retries is exceeded. The communicating client or service that initiates the transaction sets the maximum number of retries.
Releases In
The number of transaction release packets received.
Releases Out
The number of transaction release packets sent.
Response Timeout
The number of times that the server did not receive a transaction release packet for an XO transaction within the response timeout period. In most cases, this period is 30 seconds, but it may be longer depending on the timeout period specified in the original transaction request packet received for the ATP transaction. Response timeouts indicate that responses are probably not received in their entirety by requesters.
ALO In
The number of transaction request packets received during ALO transactions.
ALO Out
The number of transaction request packets sent during ALO transactions.
Resent Due to STS
(Send Transaction Status). The number of transaction request packets that the server retransmitted upon request from the receiver. When the server sends a transaction request that requires a multi-packet response, and the responder lacks sufficient buffers to send all of the responses at once, the responder can send part part of the response. Then, the responder can ask for transaction status before sending the rest of the response.
Requests Dropped
The number of received transaction request packets that are dropped for the following reasons:
An ATP listener, such as the AFP service, no longer has the packet's destination DDP socket open. The maximum number of ATP packets that the DDP socket's listener can hold in an input queue for processing has been reached.
Responses Dropped
The number of transaction response packets that the server dropped for the following reasons:
They are duplicates of response packets that have already been received. There is no corresponding request. The request probably timed out. The sequence number in the ATP header is greater than 7. A received response packet was for an ASP tickle packet.
Releases Dropped
The number of transaction release packets that the server dropped because the corresponding transaction response packets are not being held by ATP. ATP holds response packets in communication buffers until it receives corresponding release packets. If it does not receive the release packets within a timeout period, ATP gets rid of the corresponding response packets. If the release packets are received later, they are dropped.
From the Protocol Summary Menu for AppleTalk, you can view the total number of ZIP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs). ZIP packets are DDP packets that perform the operations required by ZIP.
There are 14 types of ZIP packets:
Query - When the server acts as an AppleTalk router, nodes directly connected to it send it query packets. These packets contain a network number, and ask the server to respond with a zone name or a list of names that are in the network. If the server does not have the appropriate network number/zone name mappings in its zone information table, the server does not respond.
For example, let's say that a client resides in an AppleTalk Phase 2 internetwork and needs a list of zone names for AppleTalk network 24. The client places the value 24 in the query packet and sends it to the server. The server then looks in its zone information table, and sees that ZONE1 and ZONE2 reside in the network. The server then responds with these zones by placing their names in an extended reply packet and sending it to the client.
As AppleTalk on the server learns of new AppleTalk networks, the server also sends query packets to acquire zone information for its non-seed AppleTalk ports.
Reply - Servers that act as AppleTalk routers respond to query packets with reply packets when all the requested zone names can fit into one packet.
Extended Reply - Servers that act as AppleTalk routers respond to query packets with extended reply packets when the query packet asks for the zone names in a network that has more than one zone, such as AppleTalk Phase 2 extended networks. The server sends a series of extended reply packets, which contain all the requested names.
Extended reply packets are found in AppleTalk Phase 2 networks only.
Get-zone-list Request - AppleTalk nodes that are directly connected to the server send it get-zone-list request packets to obtain a list of all the zones in the server's zone information table. The server responds with one or more get-zone-list reply packets, which contain the names of the zones.
Get-zone-list Reply - AppleTalk nodes send these packets in response to get-zone-list request packets.
Get-my-zone Request - AppleTalk nodes send a get-my-zone request packet to the server to learn the zone in which they reside. The server responds with a get-my-zone reply packet, which contains the requested zone name.
These packets are sent in AppleTalk non-extended networks only. A non-extended network is characterized by only one network number, such as LocalTalk networks and AppleTalk Phase 1 networks.
Get-my-zone Reply - The server sends these packets in response to get-my-zone request packets.
Get-local-zone Request - These packets are used by AppleTalk nodes in an extended network to ask the server to return a list of all the zones in that network. The list is returned in get-local-zone reply packets.
These packets are supported under AppleTalk Phase 2 only.
Get-local-zone Reply - AppleTalk nodes send these packets in response to get-local-zone request packets.
These packets are supported under AppleTalk Phase 2 only.
Get-net-info Request - AppleTalk Phase 2 nodes broadcast get-net-info request packets when they start up to learn their network number range, default zone, and zone multicast address. The server responds to these broadcasts with netinfo reply packets, which contain the requested multicast addresses.
The server sends get-net-info request packets on AppleTalk Phase 2 non-seed ports as they initialize. The server does this to learn network information for that port.
The multicast address is used by the server to broadcast packets to nodes in a particular zone. Each zone has a different address. This feature prevents AppleTalk nodes from receiving broadcast packets that are intended for zones to which the nodes do not belong.
Netinfo Reply - AppleTalk nodes send these packets in response to get-net-info request packets.
Bringup - A router, such as a server that acts as an AppleTalk router, receives bringup packets when a zone name change occurs in the network. A packet contains the new zone name for a specified network. The server adds the new name to its zone information table.
Only routers receive bringup packets. Note that the bringup packet applies to AppleTalk Phase 1 routers only. This packet is ignored by AppleTalk Phase 2 routers.
Takedown - The server receives a takedown before it receives a bringup packet. An AppleTalk node broadcasts takedown packets to tell all the routers in a network that a zone name change will take place. The routers then remove the zone name from their zone information tables and routing information for the affected network is no longer advertised in RTMP data packets.
Only routers receive takedown packets. Note that this packet applies to AppleTalk Phase 1 nodes only. This packet is ignored by AppleTalk Phase 2 nodes.
Notify - When a zone name changes, an AppleTalk node broadcasts notify packets to all the nodes in the zone. These packets contain the old name of the zone and the new name of the zone. The nodes then update their zone information tables.
Servers receive notify packets only. In AppleTalk Phase 2, if no old zone name appears in the packets, then the new zone name is added to the zone list for the specified network.
When you select ZIP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed ZIP statistics. The sections that follow describe these statistics.
Total In
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total Out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Drops
The number of ZIP packets that could not be received for later processing for the following reasons:
Server resources, such as communication buffers, are insufficient to process the packet or to add a new zone name to the Zone Information Table. If this problem persists, consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size. The length of the zone name in a ZIP reply packet or extended reply packet is greater than 32 characters. The packet was received on an AppleTalk port that is initializing or not operational. A ZIP reply packet had a zone name length greater than 32 characters, indicated that conflicting information was configured for an initializing seed port, contained zone name information that the server already knows, or contained the number of a network for which the server has no route. The server runs AppleTalk Phase 2, and the packet was a ZIP takedown or bringup packet. The server runs AppleTalk Phase 1, and the packet was a ZIP notify packet. A ZIP notify packet was received on a seed port that has an associated zone name identical to the zone name in the packet. A ZIP get-net-info packet was received on a LocalTalk interface. A received ZIP netinfo reply packet contained a zone name that matched the zone name for one of the server's AppleTalk seed ports. A ZIP netinfo reply packet did not have the invalid bit set. Servers always expect the bit to be set because they never fill in a zone name when sending a netinfo request for an initializing AppleTalk Phase 2 port. A ZIP netinfo reply packet had the "use broadcast" bit set, indicating that the data link on which it provides information does not support multicast. The ZIP packet type is unknown.
Queries In
The total number of query packets received.
Queries Out
The total number of query packets sent by the server. If this total increases significantly, then the server has routing table entries, or entries for servers reached via AppleTalk tunnels through VINES for which there is no zone name information. Take the following troubleshooting measures:
1. Examine the server's AppleTalk routing table, checking for routes that have no zone information. Routes that have no zone information have a value of 0 in the number of zones field. Routes that have zone information have a non-zero value.
2. If some of the routes have no zone information, check the router for those routes. The router is not responding to the server's zone information requests.
If all of the routes have zone information, it indicates that the server constantly sends query packets to a server on the other end of an AppleTalk tunnel through VINES. The tunnel cannot be established and is in an abnormal state. Stop and restart AppleTalk on this server and the server on the other end of the tunnel.
Replies In
The total number of reply packets received.
Replies Out
The total number of reply packets sent.
Ext Replies In
The number of extended reply packets received.
Ext Replies Out
The number of extended reply packets sent.
GetZnLst Requests In
The number of get-zone-list request packets received.
GetZnLst Replies Out
The number of get-zone-list reply packets that the server has sent in response to get-zone-list request packets.
GetMyZn Requests In
The number of get-my-zone request packets received.
GetMyZn Replies Out
The number of get-my-zone reply packets that the server sent.
GetLclZn Requests In
The number of get-local-zone request packets received.
GetLclZn Replies Out
The number of get-local-zone reply packets sent.
GetNetInf Requests In
The number of get-net-info request packets received.
GetNetInf Requests Out
The number of get-net-info request packets that the server has sent.
NetInf Replies In
The number of netinfo reply packets that the server has received.
NetInf Replies Out
The number of netinfo reply packets that the server has sent.
Takedown
The number of takedown packets that the server received.
Bringup
The number of bringup packets that the server received.
Notify
The number of notify packets that the server received.
Current Table Size
The current number of zone name entries in the server's zone information table.
You can display the entries in the server's zone information table. See the section "AppleTalk Zones" in Appendix A for more information.
From the Protocol Summary Menu for AppleTalk, you can view the total number of RTMP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs). RTMP packets are DDP packets that perform the operations required by RTMP.
There are six types of RTMP packets:
Data - AppleTalk routers, such as this server, broadcast data packets to neighbors periodically to let them know that the router is still on the network and to modify routing tables of routers on directly connected networks. Each data packet contains information from the router's full routing table.
The server receives these packets regardless of whether it is running AppleTalk Phase 1 or AppleTalk Phase 2. The server sends these packets except when it has only one AppleTalk Phase 1 port configured.
Request - Non-router nodes send request packets to obtain the network number of their network and to learn the identities of routers. Router nodes reply with data packets that contain the router's node ID and the network number of the network on which the router received the request.
When the server runs AppleTalk Phase 1, it can both send and receive these packets. The server will send these packets on non-seed ports to initialize the port for use. The server receives these packets only if it acts as a router.
If the server runs AppleTalk Phase 2, it will receive, and send data packets in response to, request packets received only from AppleTalk Phase 1 servers that it reaches by tunneling through VINES.
Normal Route Data Request (RDR) - An AppleTalk node sends these packets to routers for network management purposes or to obtain information from the router's routing tables. The routers reply with normal RDR response packets, which contain information from their entire routing tables.
The server sends and receives these packets only if it runs AppleTalk Phase 2. Keep in mind that the server can act as an AppleTalk router.
Normal RDR Response - These packets are responses to normal RDR request packets. The server sends and receives these packets only if it runs AppleTalk Phase 2.
RDR Split Horizon Request - An AppleTalk node sends these packets to neighbor nodes to obtain information for its routing tables or for network management purposes. The responding nodes reply with RDR split horizon response packets, which contain all the entries in their routing tables except for the networks reachable through the port on which the original request was received.
RDR Split Horizon Response - Applies to AppleTalk Phase 2 nodes only. These packets are sent in response to RDR split horizon request packets.
When you select RTMP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed RTMP statistics. The sections that follow describe these statistics.
Total In
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total Out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Dropped
The number of RTMP packets that could not be received for the following reasons:
Server resources, such as communication buffers, are insufficient. Consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size. The RTMP packet type is unknown. The RTMP packet header is too short or incorrectly formatted. For example, an AppleTalk Phase 2 RTMP packet received from a non-extended network is dropped if it does not have an ID length of 8 bits, two 0 bytes following the router's node ID, and a 0x82 version. As another example, an RTMP packet from an extended network is dropped if the network range start bytes in the first tuple are 0. The destination socket number in the RTMP header is not 0x01, which is the RTMP listening socket. The destination socket 0x01 is not open. The packet is received on an initializing AppleTalk port, and the source network number in the RTMP header conflicts with the port's seed information. The port ends up in CONFLICT state. An AppleTalk Phase 2 RTMP packet that is received across a VINES tunnel is dropped for the following reasons: - The version number in the packet header is not 0x82.
- The range flag in the packet header is not set.
- The source network number does not match the network number in the first tuple.
- The first tuple contains a network range.
The packet contains a routing entry with a network number range that overlaps an existing network number range.
Data Out
The total number of RTMP data packets sent.
Data In
The total number of data packets received.
Requests Out
The total number of request packets sent.
Requests In
The total number of request packets received.
Responses Out
The total number of data packets that are sent as responses to request packets.
RDR Requests In
The total number of normal RDR request packets received.
RDR Requests Out
The total number of normal RDR request packets sent.
Split Requests In
The total number of RDR split horizon request packets received.
RDR Responses Out
The total number of normal RDR response packets sent.
Current Table Size
The number of entries currently in the server's AppleTalk routing table.
You can display the entries in the server's AppleTalk routing table. See the sections "AppleTalk Route Information" and "AppleTalk Route Fields" in Chapter 13 for more information.
Split Requests Out
The total number of RDR split horizon request packets sent.
Split Responses Out
The total number of RDR split horizon response packets sent.
Bad Tuples
The total number of suspect routing tuples that were received in RTMP packets. A routing tuple provides information for routing table entries and specifies information about extended and non-extended networks. The server's RTMP software considers a tuple suspect under the following conditions:
An AppleTalk Phase 2 tuple contains a range of network numbers that overlap a range of network numbers in the server's AppleTalk routing table. The cause of this problem is an improperly configured seed router somewhere in the network. The network number range in an AppleTalk Phase 2 RTMP packet's first tuple is not the network number range of the AppleTalk port on which the packet was received. An AppleTalk Phase 2 tuple contains a network number range in which the beginning number is greater than the ending number. An AppleTalk Phase 1 or Phase 2 tuple was received in an RTMP packet that had a hop count greater than or equal to 15, and the server does not have a route to the destination network associated with the hop count. With the exception of a hop count of 31 (for AppleTalk Phase 2 packets only), hop counts of 15 or greater are considered invalid. A hop count of 31 is valid and indicates that destination cables specified by tuples in the packet are unreachable. Hop counts of 15 or greater (except for 31) indicate that the AppleTalk network has too many hops between some nodes. The network needs to be redesigned.
An AppleTalk Phase 1 or Phase 2 tuple contained network numbers that are in the startup range for AppleTalk Phase 2. For extended networks, the startup range consists of numbers greater than 65,279. For non-extended networks, the startup range consists of numbers greater than 65,534. When AppleTalk Phase 2 nodes come on the network, they use these numbers temporarily until they learn the real network range for the cable to which they are connected. These numbers should not be included in routing update tuples.
From the Protocol Summary Menu for AppleTalk, you can view the total number of ASP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs). These packets contain various commands, such as requests and responses, that manage ASP sessions.
Applications, such as the AFP service, that use ASP issue requests to open and close sessions, write data, and so on. These applications also return responses to these requests.
The types of ASP commands are as follows:
Attention Request and Reply - During an ASP session, the server sends an attention request to the client to get the client's attention. The client sends an attention reply to the server as a response to an attention request.
For example, suppose that the AFP service on the server was about to go down and needed the attention of the AFP client. The AFP service would send the client an attention request. The client would respond with an attention reply and follow up with another ASP command to get details of the service's status change.
SPCommand Request and Reply - The client sends an SPCommand request to ask the server to perform a given function, such as open a file or read data from an open file. The server responds with an SPCommand reply.
There is no SPCommand request for writing data. The SPWrite request is used for writing data. See the description of SPWrite Request and Reply later on for details.
Open Session Request - These packets control the opening of a session between a client and a server.
Close Session Request and Reply - These packets control the closing of a session between a client and a server. For example, a client can send a server a packet containing a close session request to close a session, and the server replies by sending a close session reply to the client.
One session partner (for example, client or server) sends a close session request to the other if the session times out or one partner wants to close it.
SPWrite Request, SPWrtContinue, and SPWrite Reply - The client sends an SPWrite request to inform the server that it wants to transfer a block of data. The server typically follows by sending an SPWrtContinue to the client to indicate that the block of data may be sent. After the server receives the block of data, the server sends an SPWrite reply, which returns the result of the write operation to the client.
SPGetStatus Request - Clients send SPGetStatus requests to servers to get status information, such as whether the server is reachable, without opening an ASP session.
Tickle - Each session partner sends a tickle packet every 30 seconds when there is no normal traffic to keep the session alive.
When you select ASP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed ASP statistics. The sections that follow describe these statistics.
Total In
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total Out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Drops
The number of packets that could not be received during ASP sessions for the following reasons:
Server resources, such as communication buffers, are insufficient to process incoming SPCommand, SPWrite, and OpenSession packets. If this problem persists, consider increasing the communication buffer size. See Chapter 15 for more information on increasing the communication buffer size. A received CloseSession, OpenSession, SPCommand, or SPWrite packet does not have the ATP XO bit set. A CloseSession, SPCommand, or SPWrite packet is received for a session that does not exist. An SPGetStatus packet is received with the ATP XO bit set. An SPGetStatus packet is received on a session that is being closed. An OpenSession packet is received while the session listening socket is closing. A routing entry does not exist for the network from which an OpenSession packet originated. An OpenSession packet is received while there are 256 open requests pending for the session's listening socket. The version number in the OpenSession packet is incorrect. The ASP packet type is unknown.
Attn Replies In
The total number of attention replies that were received during ASP sessions.
Attn Replies Out
The total number of attention replies that were sent during ASP sessions. This field displays 0 in most cases.
Attn Requests In
The total number of attention requests that were received during ASP sessions.
Attn Requests Out
The total number of attention requests that were sent during ASP sessions.
Commands In
The total number of SPCommand requests that were received during ASP sessions.
Commands Out
The total number of SPCommand requests that were sent during ASP sessions.
Cmd Replies In
The total number of SPCommand replies that were received during ASP sessions.
Cmd Replies Out
The total number of SPCommand replies that were sent during ASP sessions.
Close Sess In
The total number of close session requests that were received during ASP sessions.
Close Sess Out
The total number of close session replies that were sent during ASP sessions.
Wrt Requests In
The total number of SPWrite requests that were received during ASP sessions.
Wrt Requests Out
The total number of SPWrite requests that were sent during ASP sessions. This field displays 0 in most cases.
Wrt Replies In
The total number of SPWrite replies that were received during ASP sessions. This field displays 0 in most cases.
Wrt Replies Out
The total number of SPWrite replies that were sent during ASP sessions.
Wrt Cont Requests In
The total number of SPWrtContinue requests that were received during ASP sessions.
Note that the AFP service does not receive these requests. This field displays 0 in most cases.
Wrt Cont Requests Out
The total number of SPWrtContinue requests that were sent during ASP sessions.
GetStatus Requests In
The total number of SPGetStatus requests that were received.
GetStatus Requests Out
The total number of SPGetStatus requests that were sent.
Tickle Pkts In
The total number of tickle packets received.
Open Session In
The total number of open session requests that were received.
Open Session Out
The total number of open session requests that were sent. This field displays 0 in most cases.
Session Timeouts
The number of sessions that timed out. A session times out when no packets are received for a period of two minutes.
From the Protocol Summary Menu for AppleTalk, you can view the total number of AEP packets that were received (Totin), that were sent (Totout), and that contained errors (Errs). AEP packets are encapsulated by DDP headers.
There are two types of AEP packets:
Echo Request - When an AppleTalk node sends an echo request packet to another node, it expects to receive an echo reply packet from that node. Failure to receive this reply indicates that the node is off the network or unreachable due to router or cable failures.
Echo Reply - These packets are sent in response to echo request packets.
When you select AEP from the Protocol Family Summary Menu for AppleTalk, the screen that appears displays detailed AEP statistics. The sections that follow describe these statistics.
Total In
This field displays the same value as the Totin field on the Protocol Family Summary Menu for AppleTalk.
Total Out
This field displays the same value as the Totout field on the Protocol Family Summary Menu for AppleTalk.
Dropped
The total number of echo request and reply packets that could not be received for the following reasons:
The packet was received on a disabled AppleTalk port. The packet was received on an AppleTalk port that is initializing or did not initialize properly. The packet type is unknown (neither request nor reply).
These reasons apply to both echo request and echo reply packets. The Echo Requests Dropped statistic applies only to echo request packets and is not counted as part of the Dropped count. The Echo Replies Dropped statistic applies only to echo reply packets and is not counted as part of the Dropped count.
Echo Requests In
The total number of echo request packets received.
Echo Requests Out
The total number of echo request packets sent.
Echo Requests Dropped
The total number of echo request packets that were dropped because the server did not have a routing table entry for the network from which the packet originated.
Echo Replies In
The total number of echo reply packets received.
Echo Replies
The total number of echo reply packets sent.
Echo Replies Dropped
The total number of echo reply packets that were dropped because the server received them after it timed out the corresponding request.
