Previous PageNext Page

Chapter 12 - AppleTalk Protocol Family Statistics

Introduction

Overview of 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.

Figure 12-1. AppleTalk Protocols and OSI Layers

Figure 12-2. Sample AppleTalk Packet Containing File Data

Figure 12-3. AppleTalk DDP Packet Containing AEP, RTMP, ZIP or NBP Headers

Figure 12-4. AARP Packet Format

Accessing AppleTalk Protocol Statistics

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.

Figure 12-5. Family Summary Screen

Short Dropped (not dest)
Wrong Length
Bad Socket Number
Checksum Error

AARP Statistics

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.

Detailed AARP Statistics

Total in

Total out

Dropped

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)

In (last sec)

Current Cache Size

DDP Statistics

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.

Figure 12-6. DDP Sending Packets

Figure 12-7. DDP Receiving Packets

Figure 12-8. DDP Routing Packets

Factors That Affect DDP Traffic

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.

Detailed DDP Statistics

Total In

Total Out

Total In (short)

Total Out (short)

Dropped

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.

Short Dropped (not dest)

Wrong Length

Undel (bad dest)

Forwarded (last sec)

Routed

Routed (HWM)

Undel (No Dest Sock)

Bad Socket Number

Checksum Error

Hop Count Exceeded

Cable Bcasts In

Cable Bcasts

Network Bcasts In

Network Bcasts Out

Loopback

To VINES

From VINES

Current Dynamic Sockets

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.

Current Static Sockets

NBP Statistics

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.

Detailed NBP Statistics

Total In

Total Out

Dropped

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

Bcast Requests Dropped
Lkup Requests Dropped
Lkup Replies Dropped
Fwd Requests Dropped

Bcast Requests In

Bcast Requests Dropped

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

Lkup Requests Dropped

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

Lkup Replies In

Lkup Replies Dropped

Lkup Replies Out

Fwd Requests In

Fwd Requests

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

Svr Confirm Requests

Svr Lookup Requests

Svr Register Requests

Svr DelOne Requests

Svr DelAll Requests

Total Deletions

Total Additions

Current Table Size

ATP Statistics

ATP Error Recovery Transaction Procedures

At-least-once (ALO) transactions
Exactly-once (XO) transactions

Detailed ATP Statistics

Total In

Total Out

Dropped

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.

XO In

XO Out

Dup XO

Responses In

Responses Out

Request Timeout

Releases In

Releases Out

Response Timeout

ALO In

ALO Out

Resent Due to STS

Requests Dropped

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

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

ZIP Statistics

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.

Detailed ZIP Statistics

Total In

Total Out

Drops

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

Queries Out

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

Replies Out

Ext Replies In

Ext Replies Out

GetZnLst Requests In

GetZnLst Replies Out

GetMyZn Requests In

GetMyZn Replies Out

GetLclZn Requests In

GetLclZn Replies Out

GetNetInf Requests In

GetNetInf Requests Out

NetInf Replies In

NetInf Replies Out

Takedown

Bringup

Notify

Current Table Size

RTMP Statistics

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.

Detailed RTMP Statistics

Total In

Total Out

Dropped

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

Data In

Requests Out

Requests In

Responses Out

RDR Requests In

RDR Requests Out

Split Requests In

RDR Responses Out

Current Table Size

Split Requests Out

Split Responses Out

Bad Tuples

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.

ASP Statistics

ASP Commands

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.

Detailed ASP Statistics

Total In

Total Out

Drops

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

Attn Replies Out

Attn Requests In

Attn Requests Out

Commands In

Commands Out

Cmd Replies In

Cmd Replies Out

Close Sess In

Close Sess Out

Wrt Requests In

Wrt Requests Out

Wrt Replies In

Wrt Replies Out

Wrt Cont Requests In

Wrt Cont Requests Out

GetStatus Requests In

GetStatus Requests Out

Tickle Pkts In

Open Session In

Open Session Out

Session Timeouts

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.

AEP Detailed Statistics

Total In

Total Out

Dropped

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).

Echo Requests In

Echo Requests Out

Echo Requests Dropped

Echo Replies In

Echo Replies

Echo Replies Dropped

Previous PageTop Of PageNext Page