You can specify the LOAD and BIND command lines described in this section at the console prompt, but you should include them in AUTOEXEC.NCF to make sure the system executes them in the proper order.

The NetWare file server's AUTOEXEC.NCF file is a batch file containing commands executed each time you reboot the file server.

Loading the AppleTalk Module

When you load the AppleTalk module (APPLETLK.NLM), you specify flag options and parameters as follows:

load appletlk [-z] [-t] [-c] net=number [zone={"name"}]

Table 28. LOAD APPLETLK Parameters and Flag Options

Loading LAN Drivers with AppleTalk Frame Types

In NetWare v3.12, a LAN driver is a loadable module that communicates between the network board and a protocol stack, in this case, AppleTalk. When you load a LAN driver, you specify parameters that allocate a specific interrupt and port (I/O address) to the network board. These parameters uniquely identify the board to the system. For example, if there are two boards of the same type, each board must have a unique interrupt and port, as shown in these command lines:

load ne2000 int=3 port=200

load ne2000 int=5 port=320

The interrupt and port values indicate hardware settings on the actual board. See the documentation accompanying the network board for hardware settings, and NetWare v3.12 System Administration for more information about the driver parameters that you can specify on the LAN driver LOAD command line.

AppleTalkPacket Frames

To allow an Ethernet or Token Ring LAN driver to handle AppleTalk packets, you must specify a packet frame type when you load the LAN driver. When loading the LAN driver, you must add one of these phrases to the LOAD command line:

frame=token-ring_snapframe=ethernet_snapframe=ethernet_ii

For example, the LOAD command lines for two extended networks might look like one of these:

load token int=2 ls=32 frame=token-ring_snap

load ne2000 int=5 port=320 frame=ethernet_snap

Figure 72
SNAP Frames for Extended Networks

For nonextended AppleTalk networks, EtherTalk 1.0 requires a packet frame specification. LocalTalk cable (designed to support AppleTalk) uses the Link Access Protocol (LLAP) to transmit AppleTalk packets. ARCnet uses the default frame type used by IPX, so if you have loaded IPX on a LAN driver, you do not need to reload the driver for AppleTalk on ARCnet.

Figure 73
Frames for Nonextended Networks

If you are using both EtherTalk 1.0 and EtherTalk 2.0 on a single Ethernet cable, you must load the LAN driver with both types of frame; for example, the command lines might look like this:

load ne2000 int=3 port=200 frame=ethernet_ii

load ne2000 int=3 port=200 frame=ethernet_snap

In this case, you are binding a LAN driver with two different frames to the same NE2000 Ethernet board, because the interrupt and port values are the same. When you load a LAN driver more than once, the driver loads "re-entrantly." Later, when you use the MODULES command, you will see only one NE2000 LAN driver loaded; however, both frame types are associated with it. Please see NetWare v3.12 Installationfor details.

Binding AppleTalk to a LAN Driver

As described in NetWare v3.12 System Administration, the syntax for the BIND command is:

bind protocol [ to] LAN_driver [driver_parameters] [protocol_parameters]

Table 29. BIND Command Line Parameters

Driver Parameters on the BIND Command Line

The driver parameters enclosed in square brackets following the LAN_driver name on the BIND command line uniquely identify the board and/or network interface. These parameters must match one or more of the parameters supplied on the LAN driver LOAD command line.

For example, an interrupt value can uniquely identify a network board, as shown in the following partial BIND command lines:

bind appletlk to ne2000 int=3...

bind ipx to ne2000 int=5...

Because the interrupt values are different, these command lines identify two separate Ethernet boards, one supporting an AppleTalk network interface and the other supporting an IPX network interface.

In the case where a single network board supports more than one network interface, an additional parameter must be supplied to identify each interface uniquely. The frame type, as a rule, uniquely identifies an interface, as shown in the following partial BIND command lines:

bind appletlk to ne2000 int=3 frame=ethernet_snap ...

bind appletlk to ne2000 int=3 frame=ethernet_ii ...

Using a Driver Name Instead of Specifying Parameters

NetWare v3.12 supports the NAME option that allows you to assign a name on the LAN driver LOAD command line, such as this one:

load dl2000 int=2 port=320 name=ltalk

After assigning a name with the NAME option, you can refer to the driver on the BIND command line by name, rather than by interrupt value and/or frame type, such as in this example:

bind appletlk ltalk net=100 zone={"printers"}

Please see NetWare v3.12 System Administration for a more complete discussion of the NAME option.

AppleTalk Protocol Parameters on the BIND Command Line

The protocol parameters required at the end of each BIND command line define the AppleTalk network configuration on that interface. This syntax is used at the end of the BIND command line:

net=n1[-n2] [zone={"name1" [,"name2"] [,...,"nameN"]}]

NetWare imposes an 82-character limit on BIND command lines. If a zones list causes the BIND command line to exceed 82 characters, you must use the -zflag when loading the AppleTalk module, and provide all zone names for the current file server in the SYS:SYSTEM\ATZONES.CFG configuration file.

NOTE:  If you specify the -z option on the LOAD APPLETLK command line, and ATZONES.CFG does not reside in SYS:SYSTEM, the AppleTalk module fails to load. If you specify the -z flag, and you supply the ZONE parameter on the LOAD APPLETLK or on a BIND command line, the name you specify on the command line is used. (However, the ATZONES.CFG file must still exist in SYS:SYSTEM.)

Entries in the ATZONES.CFG file provide a correspondence between network numbers (or ranges) and zone names. If you load the AppleTalk module with the -z flag and you do not specify zone names on the LOAD APPLETLK or BIND command lines, the installation procedure supplies the missing zone names from the ATZONES.CFG file. If the LOAD APPLETLK and/or a BIND command line does specify one or more zone names, the installation procedure does not access ATZONES.CFG for that network and uses any names specified on the command line.

Creating or Modifying ATZONES.CFG

You can create or modify the ATZONES.CFG file while using the INSTALL program. To do so, load INSTALL and select Product Options, then press <Enter> on the line specifying NetWare for Macintosh. To create or modify ATZONES.CFG, select it in the "Editable Configuration Files" window and then press <Enter>.

Figure 74
Sample ATZONES.CFG file

ATZONES.CFG ignores blank spaces and blank lines, so you can use white space to organize the file by network. The network numbers or ranges you enter in this file must match those on the LOAD and BIND command lines in AUTOEXEC.NCF.

When you have configured the zones you need in ATZONES.CFG, press <Esc> and then <Enter> to save your changes and then press <Esc> as necessary to exist INSTALL.

The ATZONES.CFG file uses the same syntax for specifying networks and zones as that used on the LOAD APPLETLK and BIND command lines:

net=n1[-n2] [zone={"name1" [,"name2"] [,...,"nameN"]}]

There are two keywords, NET and ZONE. Any amount of blank space and blank lines are acceptable in ATZONES.CFG. Therefore, you can organize the file as you wish, provided that the syntax arguments occur in the proper order.

This sample ATZONES.CFG file contains zone configuration lines for three extended networks and two nonextended networks:

net=1-10 zone={"A zone", "B zone", "C zone"}

net=11-20 zone={

"X zone",

"Y zone",

"Z zone"

}

net=21-21 zone={"X zone"}

net=22 zone={"A zone"}

net=23 zone={"B zone"}

The syntax rules are listed below:

• The first non-blank (non-white-space) character following the keyword NET must be an equal-sign (=), followed by a valid AppleTalk network number or a valid network range (a number followed by a hyphen and another number).
• If the keyword NET precedes any other characters, the system ignores the line.
• If the keyword NET is absent, the AppleTalk module does not load.
• The first non-blank (non-white-space) character following the keyword ZONE must be an equal-sign (=), followed by a left brace ({), followed by a double-quote (").
• The double-quote character must be followed by a string (up to 32 characters, which can include spaces) that represents the zone name. The zone name must be followed by a closing double-quote ("). If the zone name is longer than 32 characters, the system truncates it and generates an error message.
• After the enclosing double-quote, the syntax allows either a comma (,) or a right brace (}). If the next character is a comma, it must be followed by a double-quote, another zone name, a closing double-quote, and so forth.
• If the keyword ZONE precedes any other sequence of characters, the system ignores the line.
• If the keyword ZONE is absent, the AppleTalk module does not load.

When the NetWare v3.12 operating system is loading the AppleTalk module and encounters the -z option, it looks for ATZONES.CFG in SYS:SYSTEM. If it does not find the file, it does not load the AppleTalk module. If it finds the file, it scans the file looking for the keywords NET and ZONE, and checks the syntax as specified above.

NOTE:  If you specify the -z option and specify a zone name on the LOAD APPLETLK and/or BIND command lines, the system uses the zone name specified on the command line and not the configuration specified in ATZONES.CFG for that network.

When it has checked the entire ATZONES.CFG file, NetWare v3.12 reads the file contents into memory and begins executing the LOAD APPLETLK command line. When it encounters the keyword NET on the LOAD APPLETLK command line, the operating system first checks for the keyword ZONE and a zone name on the current line. If it finds one, it uses that zone name and proceeds to the BIND command lines. If it does not find a zone name on the current command line, it checks its memory for a matching network number and reads the corresponding zone name (the internal zone) into the AppleTalk zones list maintained by the router.

After loading the AppleTalk module, the operating system continues executing the commands in the AUTOEXEC.NCF file. When NetWare begins to execute the BIND command lines, it reads the network configuration beginning with the keyword NET, and checks for the keyword ZONE and a zone name on the current command line. If it finds one, it uses that zone name. If it doesn't find one, it compares the network number or range with the data in memory obtained from ATZONES.CFG. When NetWare finds a matching network number or range, it reads the corresponding zones list into the zones list maintained by the router.

Using DDP Checksum Verification in the Router

When you load the AppleTalk module, you can specify the -c (checksums) flag option:

load appletlk -c net=number zone={"name"}

When you specify the -c option while loading the AppleTalk module, all AppleTalk packets that the router generates contain a DDP checksum, and all packets that the router receives containing a checksum have that checksum verified. (Examples of packets that the router generates are Echo responses and NBP responses.) This option is primarily intended for use on existing AppleTalk networks where DDP checksums are already in use by most nodes and routers.

When checksums are enabled, the router fills or verifies the checksum field in all RTMP data packets, NBP LkUp and FwdReq packets, ZIP query and response packets, Echo responses, and so forth, that are sent out or received by the router as an end-point. That is, if the router is simply passing the AppleTalk packets to another node or router, the router performs no verification. For this reason, nodes (such as Macintosh workstations) must also support checksums for checksum verification to be useful.

NOTE:  A checksum field of zero (0) indicates "no checksum."

The AppleTalk stack/router requires 200 Kbytes of memory to load, and has a varying requirement for short-term memory and Event Control Blocks (ECBs, also called packet-receive buffers) during normal operation. The exact requirement for short-term memory and ECBs depends on the server load, the number of NLMs loaded, and the performance needs at your site. If there is insufficient short-term memory or installed memory, or if the number of ECBs available for the stack/router is too low, the router eventually starts dropping packets and closing user connections.

Short-Term Memory Allocation

If the server is in a low-memory condition, you usually see these console messages:

short term allocator failed, out of memory

cache buffers getting low

Out of cache buffers

If you see these messages, use the MONITOR console utility to get more information about the server's memory condition. If MONITOR indicates that the Cache Buffers are near zero, then you should install more memory in the server. If it indicates that the Alloc Memory Pool is near its maximum, you should increase the short-term memory allocation; for example, you might enter this command line:

set maximum alloc short term memory=2500000

Because short-term memory is not dynamically de-allocated, the maximum allocation is specified, with a default of 2 Mbytes. The command shown above increases the allocation from the default 2 Mbytes to 2.5 Mbytes.

Of course, the server must have enough memory installed for this command to have the desired effect.

Packet-Receive Buffers (ECBs)

You must allocate a minimum of 100 packet-receive buffers before the stack/router loads. Add this configuration line to the file server's STARTUP.NCF file:

set minimum packet receive buffers=100

To test that the router has sufficient ECBs allocated, use the MONITOR command to check the number of ECBs used after letting the router run for an hour or more. (The ECB number is in the upper right-hand corner of the screen in the MONITOR program.) If you see it incrementing rapidly, you should probably set the number of packet-receive buffers higher.

Like short-term memory, ECBs are not dynamically de-allocated, and the maximum allocation is usually specified, for example,

set maximum packet receive buffers=500

Servers that run for several days under variable load conditions in which "peaks" in server load occur may often encounter situations where they will want to break the 500 ECB maximum. In these instances of unusually high demand, the error message

Unable to allocate ECBs

may be generated in the system log. This is not a fatal condition, and it corrects itself when the "peak" has subsided. However, if the server consistently has a very high load with many IPX and AppleTalk connections, you can improve performance by increasing the maximum ECB allocation (provided, of course, that the server has sufficient memory installed).