The AppleTalk protocol suite has certain features not manifest in the
TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of
address assignment can cause problems for SNMPv2 entities that wish
to manage AppleTalk networks. TCP/IP nodes have an associated IP
address which distinguishes each from the other. In contrast,
AppleTalk nodes generally have no such characteristic. The network-
level address, while often relatively stable, can change at every
reboot (or more frequently).
Thus, when SNMPv2 is mapped over DDP, nodes are identified by a
"name", rather than by an "address". Hence, all AppleTalk nodes that
implement this mapping are required to respond to NBP lookups and
confirms (e.g., implement the NBP protocol stub), which guarantees
that a mapping from NBP name to DDP address will be possible.
In determining the SNMP identity to register for an SNMPv2 entity, it
is suggested that the SNMP identity be a name which is associated
with other network services offered by the machine.
NBP lookups, which are used to map NBP names into DDP addresses, can
cause large amounts of network traffic as well as consume CPU
resources. It is also the case that the ability to perform an NBP
lookup is sensitive to certain network disruptions (such as zone
table inconsistencies) which would not prevent direct AppleTalk
communications between two SNMPv2 entities.
Thus, it is recommended that NBP lookups be used infrequently,
primarily to create a cache of name-to-address mappings. These
cached mappings should then be used for any further SNMP traffic. It
is recommended that SNMPv2 entities acting in a manager role should
maintain this cache between reboots. This caching can help minimize
network traffic, reduce CPU load on the network, and allow for (some
amount of) network trouble shooting when the basic name-to-address
translation mechanism is broken.
