# TCP/IP Transport for DOS ### Configuration Part 2/3

Introduction Utilities

## Configuration

This chapter explains both the required and optional configurations for the TCP/IP Transport software.

### Configuring Application Services

When you configure the Novell® TCP/IP Transport software, you must set up the required configuration and database files. Usually these files require customization to accommodate the specific features of your network.

The following table lists the service configuration files you must set up before you can run your applications.

Required Service Configuration Files

File | Location | Description HOSTS | \NET\TCP | This file is the hostname database file that lists the names, IP addresses, and aliases for the remote hosts on your network.
RESOLV.CFG | \NET\TCP | This file defines the network's DNS domain name and name servers. TCP/IP requires this file only if the network uses a name server.

You can change the locations of these files using the PATH TCP_CFG parameter in the NET.CFG file. For more information on this parameter, see the table "Summary of NET.CFG PROTOCOL TCPIP Miscellaneous Settings".

You must configure either the RESOLV.CFG or HOSTS file to be able to resolve symbolic hostnames.

When you use the TCP/IP Transport software, you can connect to a remote host by specifying its Internet address. If a hostname database exists, you can also connect to a remote host by specifying its name or one of its aliases.

You can set up a hostname database in one of two ways:

You can place a host table file on each workstation.

You can have one or more Domain Name System (DNS) name servers on the network .

Your network is probably a mixed environment where some workstations or hosts running TCP/IP use a DNS name server and other systems use only a host table. You might require that each workstation or host on your network use both methods (use a DNS name server and have a host table on each workstation as a backup for the DNS).

### Setting Up the HOSTS File

A host table is a listing of IP addresses, corresponding hostnames, and aliases. The HOSTS file, located on your workstation, is your TCP/IP Transport host table. This file must contain an entry for every host you access in your network. This file can also contain entries for specific hosts on remote networks.

The following is an example of a HOSTS file.

#### HOSTS File

>      #
>      # IP ADDRESS   HOSTNAME         ALIASES
>      #
>      127.0.0.1      LOOPBACK         LB
>      127.47.5.1     ENGR             ENGINEERING
>      127.47.7.3     MKTG             MARKETING
>      127.47.10.25   MANFG            MANUFACTURING

Each entry in the HOSTS file must have the following format:

>     Internet_address hostname [ alias [...] ]

Each element in an entry must be separated by one or more space characters or a tab character.

Internet_address is a 4-byte address in standard dotted notation. Each byte is a decimal or hexadecimal value and is separated by a period. Hexadecimal numbers must start with the character pair 0x or 0X. Each number in the Internet address must be a value in the range 0 to 255 (decimal) or 0x00 to 0xFF (hexadecimal). Each entry should have a unique IP address.

> Warning: Serious problems can occur if two workstations are assigned the same IP address.

hostname is the name of the system associated with this Internet address. It can contain any printable character other than space, tab, backspace, carriage-return and line-feed characters (CR-LF), end-of-line character, or comment character (#). The hostname is an arbitrary string, preferably long enough for each name to be unique across the network.

alias is another name for the same system. Typically, this is a shorter name and should be unique within your domain (that is, a subset of computers to be used). A single host can have more than one alias. For example, the following entry lists two aliases (SA and SELL) for the SALES host.

>     129.47.9.5 SALES SA SELL

The first item on the line is the host's Internet address. The second item is the host's name (sometimes referred to as the primary name). Any items following the hostname are aliases associated with the host.

A number sign (#) in the HOSTS file, at any position on a line, indicates the beginning of a comment. Characters from the number sign up to the CR-LF or end-of-line character are ignored by functions that search the file.

You can create or modify a HOSTS file using any text editor.

### Setting Up Domain Name System Support

The preferred way for the TCP/IP Transport software to identify remote hosts is to use a DNS name server. This is the only type of name server that the TCP/IP Transport software supports.

To use a DNS name server, your workstation calls the name server on a remote host to get address information. Like a host table, a name server has network addresses for the computers on your network.

Even if you have DNS name servers on your network, you may want to create a HOSTS file on each individual workstation or server in case the DNS name servers fail.

NOTE: If your site does not have a DNS name server, you must have a HOSTS file on each workstation.

By default, the TCP/IP Transport software determines the IP address for a hostname by first accessing a DNS name server. If a valid entry is in the DNS name server, the TCP/IP protocol stack opens a session with the remote host. If the software cannot find a DNS name server or it cannot find the remote hostname in the DNS name server, the software looks for the remote hostname in your workstation's HOSTS file.

You can change the way TCP/IP searches for an IP address by using the SEARCH command in the following format:

>     SEARCH first_source [ second_source ] [SEQUENTIAL]

If you want TCP/IP to search the DNS name servers or the HOSTS file only, specify DNS or HOSTS file as first_source (do not specify a second_source). If you want to search both the DNS name servers and the HOSTS file, specify both sources in the order you want TCP/IP to search them. Include the SEQUENTIAL parameter if you want TCP/IP to search the DNS name servers sequentially.

To access a DNS name server on your network, you must have a resolver configuration file, RESOLV.CFG, on your workstation. This file is located in your \NET\TCP directory. It contains entries that specify the Internet address of the system on which the name server is running.

Two types of entries are available in the resolver file: domain and name server. The following example shows both types of entries.

#### Sample RESOLVE.CFG File

>     ;COMPANY RESOLVER FILE
>     DOMAIN COMPANY.COM
>     ;
>     ;MAXCACHE (FAST CACHING ONLY NAME SERVER FOR COMPANY.COM - INTERNAL ONLY)
>     NAME SERVER 129.47.8.1
>     ;
>     ;SECROOT (SECONDARY ROOT NAME SERVER FOR COMPANY.COM - VISIBLE TO INTERNET)
>     NAME SERVER 129.47.4.2
>     ;
>     ;PRIMROOT (PRIMARY ROOT NAME SERVER FOR COMPANY.COM - VISIBLE TO INTERNET)
>     NAME SERVER 129.47.4.1

The domain entry is a single entry with the following format:

>     DOMAIN domain_name

You must include the domain keyword. If your organization has an Internet domain assigned (for example, NOVELL.COM) and you need to communicate with the Internet, you must also include the domain_name. The domain_name has the extension .COM for a commercial organization, .MIL for a military organization, .EDU for a school, or .GOV for a government organization.

You can include up to three name server entries in the resolver configuration file. Each of these entries has the following format:

>     NAMESERVER Internet_address

You must include the name server keyword with each name server entry. Internet_address is the Internet address of the name server in dotted notation.

The domain entry lets you specify a default domain to apply to all names without a domain. The name server entry lets you specify the IP address of a name server for the resolver functions (for example, name server 129.47.8.1).

You precede comments with a semicolon (;) character. For example:

>     NAMESERVER 129.47.8.1 ; COMPANY RESOLVER FILE

If the file lists more than one Internet address, the resolver tries them in the order listed. In the example Sample RESOLVE.CFG File above, the resolver tries to locate an IP address on the maxcache name server first. If unsuccessful, the resolver checks the secroot name server, followed by the primroot name server.

To disable your domain name server, you can rename the RESOLV.CFG file in the \NET\TCP directory (for example, renaming the file to RESOLV.OFF turns your DNS off).

### Optional Transport Configuration Files

Other optional configuration files customize the operation of the utilities and applications. These files are as follows:

- \NET\TCP\PROTOCOL---associates protocol name and aliases with standard Internet protocol numbers
- \NET\TCP\SERVICES---associates service name and aliases with standard Internet protocol and port numbers
- \NET\TCP\NETWORKS---associates network names and aliases with Internet IP addresses
- \NET\TCP\ETHERS---used only by the RARP server, RARPD.EXE, to associate IP addresses with workstation MAC addresses.

### Setting Up the PROTOCOL File

The PROTOCOL file contains information about the known protocols used on the Internet network. Each protocol is represented by a single line with the following parameters separated by one or more space characters:
protocol_name protocol_number [ alias [ ... ] ]

The protocol_name is the name of the Internet protocol associated with this protocol number. It can contain any printable character other than a field delimiter (space or tab), newline character, or number sign (#).

The protocol_number is the number of the Internet protocol.

The alias is an alternate name for the protocol.

For example, the TCP protocol has the following entry in the PROTOCOL file:

>     TCP 6 TCP # TRANSMISSION CONTROL PROTOCOL

The following example shows a sample PROTOCOL file.

#### Sample PROTOCOL File

>      #
>      # NAME    NUMBER   ALIASES
>      #
>      IP        0        IP       # INTERNET PROTOCOL, PSEUDO PROTOCOL NUMBER
>      ICMP      1        ICMP     # INTERNET CONTROL MESSAGE PROTOCOL
>      IGMP      2        IGMP     # INTERNET GROUP MULTICAST PROTOCOL
>      GGP       3        GGP      # GATEWAY-GATEWAY PROTOCOL
>      TCP       6        TCP      # TRANSMISSION CONTROL PROTOCOL
>      PUP       12       PUP      # PARC UNIVERSAL PACKET PROTOCOL
>      UDP       17       UDP      # USER DATAGRAM PROTOCOL

### Setting Up the SERVICES File

The SERVICES file contains information about the known services used on the Internet network. Each service is represented by a single line with the following parameters, each separated by one or more blanks:

>     service_name port_number/protocol_name [ alias [ ... ] ]

The service_name is the name of the service associated with this port number and protocol name. It can contain any printable character other than a field delimiter (space or tab), newline character, or number sign (#). These services are generally application, presentation, or session-level modules, such as TFTP, FTP, SMTP, and TELNET.

The port_number is the number of the Internet port used by the service. The protocol_name is the protocol with which the service is associated. This protocol is generally a transport-level or network-level module, such as TCP or UDP. Separate the port number and the protocol name with a slash.

The alias is an alternate name for the service.

A number sign (#) in the SERVICES file indicates the beginning of a comment. Characters between the number sign and the newline character are ignored by the functions that search the file.

For example, the following line is the entry for the SMTP mail protocol:

>     SMTP 25/TCP MAIL

The following example shows a sample SERVICES file.

>      #
>      # SERVICE-NAME  PORT/PROTOCOL  ALIASES
>      #
>      ECHO            7/UDP
>      ECHO            7/TCP
>      DISCARD         9/UDP          SINK NULL
>      DISCARD         9/TCP          SINK NULL
>      SYSTAT          11/TCP
>      DAYTIME         13/UDP
>      DAYTIME         13/TCP
>      NETSTAT         15/TCP
>      FTP-DATA        20/TCP
>      TELNET          23/TCP
>      SMTP            25/TCP         MAIL
>      TIME            37/TCP         TIMESERVER
>      TIME            37/UDP         TIMESERVER
>      NAME            42/UDP         NAMESERVER
>      WHOIS           43/TCP         NICNAME         # USUALLY TO SRI-NIC
>      DOMAIN          53/UDP
>      DOMAIN          53/TCP
>      HOSTNAMES       101/TCP        HOSTNAME        # USUALLY TO SRI-NIC
>      SUNRPC          111/UDP
>      SUNRPC          111/TCP
>      #HOST-SPECIFIC FUNCTIONS
>      #
>      TFTP            69/UDP
>      RJE             77/TCP
>      FINGER          79/TCP
>      LINK            87/TCP         TTY LINK
>      SUPDUP          95/TCP
>      ISO-TSAP        102/TCP
>      X400            103/TCP                        # ISO MAIL
>      X400-SND        104/TCP
>      CSNET-NS        105-TCP
>      POP-2           109/TCP                        # POST OFFICE
>      UUCP-PATH       117/TCP
>      NNTP            119/TCP        USENET          # NETWORK NEWS TRANSFER
>      NTP             123/TCP                        # NETWORK TIME PROTOCOL
>      NEWS            144/TCP        NEWS            # WINDOW SYSTEM
>      #
>      # UNIX-SPECIFIC SERVICES
>      #
>      # THESE ARE NOT OFFICIALLY ASSIGNED
>      #
>      EXEC            512/TCP
>      LOGIN           513/TCP
>      SHELL           514/TCP        CMD             # NO PASSWORDS USED
>      PRINTER         515/TCP        SPOOLER         # EXPERIMENTAL
>      COURIER         530/TCP        RPC             # EXPERIMENTAL
>      BIFF            512/UDP        COMSAT
>      WHO             513/UDP        WHOD
>      SYSLOG          514/UDP
>      TALK            517/UDP
>      ROUTE           520/UDP        ROUTER ROUTED
>      NEW-RWHO        550/UDP        NEW-WHO         # EXPERIMENTAL
>      RMONITOR        560/UDP        RMONITORD       # EXPERIMENTAL
>      MONITOR         561/UDP                        # EXPERIMENTAL
>      INGRESLOCK      1524/TCP

### Setting Up the NETWORKS File

The NETWORKS file contains information about the known networks that make up the Internet network. Each network is represented by a single line with the following parameters separated by one or more blank spaces:

>     network_name Internet_number [ alias [...] ]

The network_name is the name of the network associated with this Internet network number. It can contain any printable character other than a field delimiter (space or tab), newline character, or number sign (#). The network name is an arbitrary string, preferably long enough for each name to be unique.

The Internet_number is the number of the Internet network. Hexadecimal numbers start with the character pair 0x or 0X.

The alias is another name for the same network.

For example, the network "cornet" might have the following entry in the NETWORKS file:

>     CORNET   144.61   HORN

The NETWORKS file can be created from the official host database maintained at the Network Information System Center (NISC), although local changes may be required to bring it up to date regarding unofficial aliases and unknown networks. Such a file should be centrally administered for consistency.

The following example shows a sample NETWORKS file:

>      #
>      # NETWORK-NAME    INTERNET-NUMBER    ALIASES
>      #
>      LOOPBACK          127
>      COMPANY-NET       129.47
>      SUBNET-A          129.47.4
>      SUBNET-B          129.47.8

>      # INTERNET NETWORKS
>      ARPANET           10                 ARPA
>      UCB-ETHER         46                 UCBETHER

### Setting Up the ETHERS File

The configuration table read by RARPD when it is loaded is the text file ETHERS in the \NET\TCP directory.

Each line of this file contains one MAC address/IP address pair, separated by tabs or spaces. The MAC address is 6 hexadecimal bytes separated by colons. The IP address can be in dotted notation, or a symbolic hostname can be supplied.

Hostnames are resolved when RARPD is loaded, either through DNS or the HOSTS file.

Lines in the ETHERS file that start with the pound sign (#) are interpreted as comments.

The following is an example ETHERS file:

>      # ETHERNET ADDRESS        IP ADDRESS
>      08:00:14:11:34:2C         LAB1
>      02:60:8C:0D:FA:DF         129.47.5.98

### Modifying NET.CFG

NetWare® and the TCP/IP Transport software use the NET.CFG file to configure other protocols, such as IPX. This file contains protocol sections that each define a separate protocol. For example, the Protocol RFCNBIOS section specifies fixed NetBIOS names for IP address mappings.

The NET.CFG file has three sections that are used by the TCP/IP Transport software:

- LINK SUPPORT --- determines the sizes of the LSL memory pool and buffers. You can change these values to suit your network configuration and application usage.
- LINK DRIVER --- configures ODI drivers. You can set up multiple drivers if you have more than one network board or want to run SLIP/PPP over a COM port (serial link).
- PROTOCOL TCPIP --- contains settings used by the TCPIP.EXE module. You can modify this section to support optional features.

The sections that follow explain the NET.CFG format and discuss NET.CFG settings that you can customize in the LINK SUPPORT, LINK DRIVER, and PROTOCOL TCPIP sections. These discussions are followed by a selection of example configurations.

### Editing the NET.CFG File

You can use any text editor, such as DOS 5.0 EDIT, to update this file. The NET.CFG file uses the following format:

Section headings start at the beginning of a line (first column) and precede the parameter settings that apply to the section:

>     Section_Heading

Parameter settings listed under each section heading are indented with a tab or one or more spaces:

>     Section_Heading   Parameter Value(s)

Type numbers for values in decimal notation unless directed otherwise.

Type section headings and parameters in any combination of uppercase and lowercase letters.

Precede comments with a number sign (#) or semicolon (;).

End each line with a carriage return.

After changing NET.CFG, you might also need to change the AUTOEXEC.BAT file or other workstation batch files to load any new drivers you are configuring. The drivers read the information in NET.CFG when they are loaded into memory. For NET.CFG changes to take effect, you must unload and reload the drivers and TCPIP.EXE so that they read the new NET.CFG information. If you configure these programs to load from AUTOEXEC.BAT, rebooting the workstation has the same effect.

### LINK DRIVER Section

The LINK DRIVER section of the NET.CFG file names the ODI drivers and specifies various hardware and software settings for each driver. The installation program sets up the LINK DRIVER section for your network board using the parameter settings necessary to run the Transport software. This section begins with the following section header:

>     LINK DRIVER drivername

drivername specifies the ODI driver. For example, if the ODI driver file is NE2000.COM, drivername is NE2000TM.

The following table lists the parameters that configure the board and its driver for use by other software.

Summary of NET.CFG LINK DRIVER Settings

Parameter Syntax | Values | Explanation INT [ #1 | #2 ] IRQ_number |  | This parameter specifies the hardware interrupt number, IRQ_number, used by the network board.
| [ #1 | #2 ] | This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type.
| IRQ_number | This value specifies the decimal interrupt request number.
PORT [ #1 | #2 ] address [ ports ] |  | This parameter specifies the starting port address and the number of ports used by the board.
| [ #1 | #2 ] | This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type.
| address | This value specifies the address, in hexadecimal, of the hardware port to use or the first port in a range of ports.
| [ ports ] | This value specifies the number of ports in the range, in hexadecimal.
DMA [ #1 | #2 ] channel |  | This parameter specifies the DMA channel to be used by the network board.
| [ #1 | #2 ] | This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type.
| channel | This value specifies the decimal DMA channel number.
MEM [ #1 | #2 ] address [ length ] |  | This parameter specifies the range of DOS conventional memory to be reserved for use by the board.
| [ #1 | #2 ] | This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type.
| address | This value specifies the starting memory address, in hexadecimal.
| length | This value specifies the length of the memory segment, in hexadecimal.
SLOT number |  | For MCA boards, this parameter specifies the number, in decimal, of the slot into which you inserted the network board. This setting is required only if your workstation has more than one board of the same type.
CONNECTOR DIX |  | For the 3C503.COM driver, this parameter configures the board to use the DIX (thick Ethernet) connector. If this setting is not included, the BNC/TP (thin) connector is used.
FRAME { SLIP | PPP } |  | This parameter specifies the frame type used by the network board. You can include more than one frame setting for boards and drivers that support multiple frame types.
PROTOCOL name protocol_ID frame_type |  | This parameter specifies the network protocol to be supported by the ODI driver.
| name | This value specifies the name of the network protocol to be supported.
| protocol_ID | This value specifies the hexadecimal ID number assigned to this protocol (see Table 2-3Table 2-3 for a list of the ID numbers).
| frame_type | This value specifies the frame type used by this protocol. See the preceding Frame setting.

Additional settings are used by individual ODI drivers and may be required or optional. Refer to the ODI section of the hardware documentation for your network board for information about what LINK DRIVER settings the driver uses and which settings are required. Another source of this information is the .INS file for each driver. These files, which have the same name as the driver .COM file and are stored in the same directory, are ASCII text files that often contain information and comments about driver configuration.

The sections that follow describe the LINK DRIVER section header and its most frequently used parameters.

### LINK DRIVER name

Each ODI driver that you configure has a separate LINK DRIVER section in the NET.CFG file. Replace name with the executable filename of the driver you are using, omitting the extension (for example, NE2000 for NE2000.COM).

The names of the drivers provided with the TCP/IP Transport software can be found in the file MANIFEST.TXT on the distribution diskette.

### INT [ #1 | #2 ] IRQ_number

The INT setting (called IRQ, for interrupt request, by some vendors) specifies which interrupt your network board uses. For example, to specify interrupt 5 on an NE2000 board, place the following lines in your NET.CFG file:

>     LINK DRIVER NE2000
>       INT #1 5

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses Interrupt 5, you can place the following lines in your NET.CFG file:

>     LINK DRIVER 3C505
>       INT 5

If, however, you are using more than one channel or network board, each of which has an INT value, you must include the characters #1 for the first channel's value and #2 for the second channel's value.

### PORT [ #1 | #2 ] address [ ports ]

Use the PORT setting to specify the starting port (address, a hexadecimal number) and the number of ports in the range (ports, also hexadecimal).

For example, suppose you want to specify the starting port for the first communications channel on your board. The port address for the board is 300. Place the following lines in the NET.CFG file:

>     LINK DRIVER NE2000
>       PORT #1 300

The number of ports is optional. The following example specifies port ranges for both of a board's communications channels with 32 ports (20 hexadecimal) in each range:

>     LINK DRIVER 3C505
>       PORT #1 300 20
>       PORT #2 700 20

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses 32 ports starting at address 300, you can place the following lines in your NET.CFG file:

>     LINK DRIVER 3C505
>       PORT 300 20

If, however, you are using more than one channel or network board, each of which has a port address and range, you must include the characters #1 for the first channel's values and #2 for the second channel's values.

### DMA [ #1 | #2 ] channel

The direct memory access (DMA) option specifies the hardware DMA channel setting of the network board. This option lets you configure DMA channels by entering the channel number (channel, a decimal number) to be used. The default value is the first DMA channel (channel = 1).

> Note: Do not confuse your workstation's DMA channels with the communications channels on your network board. Some network boards have more than one network communications channel, each of which can be connected to a separate network communications line. DMA channels, on the other hand, are a feature of your workstation. A set number of DMA channels are allocated among all controller boards in your workstation that make use of this facility.

For example, if the first communications channel on your board uses DMA channel 3 and the second communications channel uses DMA channel 4, place the following lines in your NET.CFG file:

>     LINK DRIVER 3C505
>       DMA #1 3
>       DMA #2 4

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses DMA channel 3, you can place the following lines in your NET.CFG file:

>     LINK DRIVER 3C505
>       DMA 3

If, however, you are using more than one channel or network board, each of which has a DMA value, you must include the characters #1 for the first channel's value and #2 for the second channel's value.

### MEM [ #1 | #2 ] address [ length ]

The MEM option specifies a range of conventional DOS memory to be reserved for use by the network board.

Use the hexadecimal physical (absolute) address of the memory used by the board for the address parameter. This address must match the starting address configured on the board. Enter the optional length parameter in hexadecimal paragraphs (a paragraph is 16 bytes) of the memory segment used by the board.

For example, if your board addresses the memory segment from D0000 to D4000, the starting address is D0000 and the range is 400 hexadecimal paragraphs. You would place the following lines in your NET.CFG file for an EXOSTM board:

>     LINK DRIVER EXOS
>       MEM D0000 400

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses memory address C0000, you can place the following lines in your NET.CFG file:

>     LINK DRIVER EXOS
>       MEM C0000

If, however, you are using more than one channel or network board, each of which has a Mem value, you must include the characters #1 for the first channel's value and #2 for the second channel's value:

>     LINK DRIVER EXOS
>       MEM #1 C0000
>       MEM #2 D0000

Some network boards, such as the 3C503 board, can be configured to use either shared DOS memory (requiring a Mem setting) or their own on-board memory. Refer to the manufacturer's documentation for your network board to determine how best to configure your board.

### SLOT number

In slot-based computers, the driver usually locates the board by scanning through the slots in order from lowest to highest. The SLOT parameter directs the driver to eliminate the scan and locate the board in the specified slot.

Use the number of the slot into which you inserted the board for the number parameter (a decimal value). The slot number is usually found on the back of the workstation.

For example, if you are using two NE/2&TM; boards in the same workstation and you insert one board into slot 1 and the other into slot 2, place the following lines in your NET.CFG file:

>     LINK DRIVER NE2
>       SLOT 1

>     LINK DRIVER NE2
>       SLOT 2

You would then need to load the NE2.COM driver twice. The SLOT option directs the first NE2 driver loaded to use the NE/2 board in slot 1 and directs the second NE2 driver to use the NE/2 board in slot 2.

### CONNECTOR DIX

The CONNECTOR DIX parameter configures the 3C503 LAN driver to use the DIX (thick) connector. BNC/TP (thin) is the default value. To specify the DIX connector, place the following lines in your NET.CFG file:

>     LINK DRIVER 3C503
>       CONNECTOR DIX

DIX can also be selected in the command line that loads the 3C503.COM driver, as in the following example:

>     3C503 /D

### FRAME frame_type

The FRAME parameter enables the frame types used by the network board. You can use this option more than once with network boards that support multiple frame types.

For example, to enable the ETHERNET_II frame type on an NE1000TM board, place the following lines in the NET.CFG file:

>     LINK DRIVER
>     NE1000 FRAME ETHERNET_II

Use the following frame formats for TCP/IP networks:

Ethernet | ETHERNET_II or ETHERNET_SNAP
Token Ring | TOKEN-RING_SNAP
ARCnet | NOVELL_RX-NET
IBM PCN2 | IBM_PCN2_SNAP
FDDI | FDDI_SNAP

For OSI networks, use frame type ETHERNET_802.2. For IPX networks, Ethernet LAN drivers default to the ETHERNET_802.3 frame type; token ring LAN drivers default to the TOKEN-RING frame type.

The following table lists the network types that support each NET.CFG frame type parameter. Additional frame types are supported by the NCOMX driver.

IPX Frame Types and Corresponding Network Types

Frame Type | Hex ID Number | Ethernet | Token Ring | ARCnet | IBM PC-NET | FDDI ETHERNET_II | 8137 | Supported | --- | --- | --- | ---
ETHERNET_SNAP | 8137 | Supported | --- | --- | --- | ---
ETHERNET_802.2 | E0 | Supported | --- | --- | --- | ---
ETHERNET_802.3 | 0 | Supported | --- | --- | --- | ---
TOKEN-RING_SNAP | 8137 | --- | Supported | --- | --- | ---
TOKEN-RING | E0 | --- | Supported | --- | --- | ---
NOVELL_RX-NET | FA | --- | --- | Supported | --- | ---
IBM_PCN2_802.2 | E0 | --- | --- | --- | Supported | ---
IBM_PCN2_SNAP | 8137 | --- | --- | --- | Supported | ---
FDDI802.2 | E0 | --- | --- | --- | --- | Supported
FDDI_SNAP | 8137 | --- | --- | --- | --- | Supported

Note: --- indicates that this frame type is not supported on this network type.

### PROTOCOL name protocol_ID frame_type

The PROTOCOL option lets existing ODI drivers handle new network protocols.

Replace name with the name of the new protocol.

Replace protocol_ID with the hexadecimal protocol ID number that the protocol is assigned (see the table above).

Replace frame_type with the frame type to which the new protocol ID applies. Make sure the LINK DRIVER section for this driver contains a Frame setting enabling support of this frame type.

For example, if you want to use a new protocol XYZ with an NE2-32 network board, include the following lines in the NET.CFG file:

>     LINK DRIVER NE2-32
>       FRAME ETHERNET_SNAP
>       PROTOCOL XYZ 904A ETHERNET_SNAP

### LINK SUPPORT Section

The TCP/IP Transport software uses the buffer management functions provided by the LSL driver. The LINK SUPPORT section of the NET.CFG file includes parameters that determine the number and sizes of buffers available for the TCP/IP protocol. IPX does not use these buffers.

Standard Configuration. The installation program sets up the LINK SUPPORT section for an Ethernet configuration as follows:

>     LINK SUPPORT
>       BUFFERS 8 1500
>       MEMPOOL 4096

The installation program sets up the LINK SUPPORT section for a token ring configuration as follows:

>     LINK SUPPORT
>       BUFFERS 8 4200
>       MEMPOOL 4096

### BUFFERS number [ size ]

The BUFFERS setting controls the number and size of receive packet buffers. The default number of receive buffers is 8, and the default size is 1500 bytes. You can reduce the number of receive buffers if TCP connections are used sequentially. If you make heavy use of multiple TCP connections, you can increase the number of buffers for better performance. The buffer size is dependent on the topology of your configuration.

### MEMPOOL size

The MEMPOOL setting controls the size of an internal send-buffer pool used by TCP/IP. TCP send data is copied into this pool before being sent to the remote system. The default size is 4096 bytes. You might need to increase the MEMPOOL size when communicating with remote TCP hosts that offer large receive windows and delay acknowledgments.

Optional Parameters. If you are configuring more than one network board or plan to use multiple protocol stacks, you can set two additional parameters to configure the required LSL support.

### MAX BOARDS number

This parameter configures the maximum number of logical boards the LSL program can support.

Each driver and frame type supported by the driver uses one LSL logical board resource. For example, if you are configuring NE1000.COM to load all possible Ethernet frame types (ETHERNET_II, ETHERNET_802.3, ETHERNET_802.2, and ETHERNET_SNAP), four board resources are used.

Include the MAX BOARDS setting only if you require more than four logical boards (the default). The range of values for number is from 1 to 16.

### MAX STACKS number

This parameter configures the maximum number of logical protocol stacks LSL can support. Each protocol stack uses one or more stack ID resources.

If a protocol stack fails to load because of an out-of-resource condition, you can solve the problem by increasing this value. Because support for additional stacks increases the amount of memory used by LSL.COM, you can conserve some memory by reducing this value if your system is not using all allocated stack support.

Include the MAX STACKS setting only if you require more than four logical stacks (the default). The range of values for number is from 1 to 16.

### PROTOCOL TCPIP Section

During startup, TCPIP.EXE reads settings saved in the PROTOCOL TCPIP section of the NET.CFG file.

> Note: You can specify a different location for the NET.CFG file by loading TCPIP with the -C drive:path command-line option.

The parameters that can be set in the PROTOCOL TCPIP section of the NET.CFG file to configure TCPIP.EXE are summarized in the following 4 tables.

Summary of NET.CFG PROTOCOL TCPIP Board Settings

Parameter | Values | Explanation BIND driver [ #board frame_type network_name ] |  | This parameter specifies the network interface board for the TCP/IP protocol stack. This parameter is needed only if you are running more than one ODI driver to support TCP/IP (for example, a workstation that uses both an Ethernet connection and a SLIP/PPP serial link, or a network gateway machine with two network boards). If the PROTOCOL TCPIP section does not specify this setting, TCP/IP uses the first driver it finds in memory (the first one loaded). The #board, frame_type, and network_name values are optional. Include them only when configuring TCP/IP to run over multiple network interfaces.
| driver | This value specifies the name of the ODI driver for this board. For example, if the driver is NE1000.COM, the value for the driver parameter is NE1000.
| #board | This value specifies the board number bound to this driver. This is the physical load sequence number of the board (not the same as the logical board number displayed by the driver when it is loaded). When this value is 0, TCP/IP binds to the first board it finds that supports TCP/IP and also supports the specified frame_type.
| frame_type | This value specifies the frame format used for this network connection. This is the same as the frame value in the LINK DRIVER section for this driver.
| network_name | This value specifies the descriptive name for this network connection. The network_name is used with the IP_ADDRESS, IP_ROUTER, and IP_NETMASK parameters to distinguish between the values for each network connection.

#### Summary of NET.CFG PROTOCOL TCPIP Address Settings

Parameter | Values | Explanation IP_ADDRESS address [ network_name ] |  | This parameter specifies your workstation's IP address. The value for this parameter is supplied during installation. The IP_ADDRESSparameter has no default value.
| address | This value specifies the IP address in dotted notation. If this parameter is missing or is 0.0.0.0, the protocol stack uses BOOTP or Reverse ARP to determine the IP address.
| network_name | This value specifies the descriptive network name used in the BIND setting or this network connection. The network_name is required only if you are configuring multiple ODI drivers for TCP/IP.
IP_ROUTER address [ network_name ] |  | This parameter specifies the default router address for an active network. TCP/IP uses the ICMP redirect mechanism to determine all other gateways. This address is supplied during installation. The IP_ROUTERparameter has no default value. You can specify up to three routers for each active network.
| address | This value specifies an IP address in dotted notation.
| network_name | This value specifies the descriptive network name used in the BIND setting for this network connection. The network_name is required only if you are configuring multiple ODI drivers for TCP/IP.
IP_NETMASK mask [ network_name ] |  | This parameter specifies the subnetwork mask if subnetworks are used. This parameter is supplied during installation. The IP_NETMASKparameter has no default value.
| mask | Subnetwork mask in dotted notation.
| network_name | The descriptive network name used in the Bind setting for this network connection. The network_name is required only if you are configuring multiple ODI drivers for TCP/IP.

Summary of NET.CFG PROTOCOL TCPIP Miscellaneous Settings

Parameter | Values | Explanation PATH TCP_CFG [ [ drive: ] path [ ; ... ] ] |  | This parameter specifies the directory or directories that contain the database configuration files HOSTS, NETWORKS, PROTOCOL, SERVICES, and RESOLV.CFG. The syntax is the same as the DOS PATH command. The default value is \NET\TCP.
NO_BOOTP |  | This parameter specifies whether to bypass a BOOTP system, if one is present on the network, and use Reverse ARP to identify a workstation's IP address. The transport uses the address specified by the ip_address parameter first if this parameter is present; if not, it sends out a BOOTP request packet; and if no response is received from a BOOTP server, Reverse ARP is assumed. Including the NO_BOOTP parameter eliminates the BOOTP request packet step.
TCP_WINDOW number |  | This parameter specifies TCPIP's maximum receive window size in bytes. You can specify a maximum value of 32,767 for number.
TCP_MAXSEGSIZE number |  | This parameter specifies the maximum packet segment size you use when communicating with other nodes. You can specify a maximum of 8192 bytes for number.
TCP_MINRXMIT number |  | This parameter specifies the minimum number of time-outs that TCPIP can use. You can specify a value from 1 through 540. Each timeout lasts 55 milliseconds.
TCP_MAXRXMIT number |  | This parameter specifies the maximum number of time-outs that TCPIP can use. You can specify a value from one plus the number of TCP_MINRXMIT time-outs through 1080 time-outs. Each time-out lasts 55 milliseconds.

Summary of NET.CFG PROTOCOL TCPIP Socket Settings

Parameter | Values | Explanation TCP_SOCKETS number |  | This parameter specifies the maximum number of concurrent TCP connections. If you configure multiple ODI drivers for TCP/ IP, the number of TCP sockets you specify is the total shared by all drivers. The default value is 8. The range of values is 0 through 64.
UDP_SOCKETS number |  | This parameter specifies the maximum number of concurrent UDP connections. You should have at least one UDP socket for each concurrently run application if you are planning to use the DNS. NetBIOS requires at least 2 UDP sockets. If you configure multiple ODI drivers for TCP/IP, the number of UDP sockets you specify is the total shared by all drivers. The default value is 8. The range of values is 0 through 32.
RAW_SOCKETS number |  | This parameter specifies the maximum number of raw IP connections. You should have one raw IP socket if you are planning to use the PING command or the applications that use this capability (Serving FTPTM, IP Resolver, LWPCON). If you configure multiple ODI drivers for TCP/IP, the number of raw sockets you specify is the total shared by all drivers. The default value is 1.

### Allocating Sockets

The default NET.CFG file configured by the installation program provides for eight TCP sockets, eight UDP sockets, and one raw socket. These default allocations are intended to be sufficient for most configurations. If you expect to make heavy concurrent use of applications that use sockets, you might want to modify the number of TCP sockets. You need one TCP socket for each TELNET session and two TCP sockets for each FTP session.

UDP sockets are used by LWPCON and by all applications that query DNS name servers. Because UDP sockets are used briefly to send and receive datagrams, then released, you need more than the default eight UDP sockets only if you make very heavy use of DNS.

One raw socket is required for use by PING, LWPCON, and other applications that have ping functions.

### Using a BOOTP Server

If your network has a BOOTP server that is configured to supply your workstation with its IP address, router address, and subnetwork mask, omit the IP_ADDRESS, IP_ROUTER, and IP_NETMASK parameters from your NET.CFG file. If these parameters are missing, the TCP/IP Transport software expects their values to be supplied by a BOOTP server.

### Using a Reverse ARP Server

The Reverse Address Resolution Protocol (RARPD) server program allows you to assign workstation IP addresses from a centrally administered IP address database on a single workstation.

RARPD maintains a table in memory associating IP addresses with physical hardware (MAC) addresses of workstations on the network. A workstation configured as a RARPD client queries the RARPD server on startup, supplying its MAC address. RARPD responds with the corresponding IP address.

If your network has a reverse ARP server, such as RARPD, that provides your workstation IP address when you restart the workstation, you need to configure the following in your NET.CFG file:

- Do not include the IP_ADDRESS parameter.
- If your network also has a BOOTP server, include the no_bootp parameter. If this parameter is present and the ip_address parameter is absent, the TCP/IP Transport software expects to receive the IP address from a Reverse ARP server.

### Setting Up NetBIOS

RFCNBIOS.EXE implements the NetBIOS B-node protocols as defined in RFCs 1001 and 1002. (The B-node protocols use broadcast datagrams for network management and some NetBIOS datagram operations.) With this software, you can run any workstation network application designed for the standard NetBIOS interface.

> IMPORTANT: All directly connected NetBIOS nodes with which you plan to communicate must use an RFC1001/1002-compliant NetBIOS program. Also, all NetBIOS implementations must be B-node configurations.

The NetBIOS software is customized in the PROTOCOL TCPIP and PROTOCOL RFCNBIOS sections of the NET.CFG file. The following 2 tables summarize the NetBIOS settings.

Summary of NetBIOS NET.CFG Protocol TCPIP Section Settings

Parameter | Explanation NB_SESSIONS number | This parameter specifies the maximum number of concurrent NetBIOS sessions. When you specify this setting, you must increase the number of TCP sockets you allocate (TCP_SOCKETS setting) to at least 1 plus the value of this setting. The default value of number is 4. You can specify a setting from 0 through 64.
NB_COMMANDS number | This parameter specifies the maximum number of asynchronous NetBIOS commands. The default value of number is 20. You can specify a setting from 0 through 80.
NB_DOMAIN domain_name | This parameter specifies the name of the logical domain for this NetBIOS station. The value of this setting is an ASCII string. By default the value of domain_name is null.
NB_ADAPTER { 0 | 1 } | This parameter specifies which NetBIOS board to use.
NB_BRDCAST { 0 | 1 | IP_address} | This parameter specifies the format of IP broadcasts used when RFCNBIOS.EXE sends broadcast messages. The value 0 sets the broadcast address to use zeroes for the host portions of the IP address. For example, a Class B network with network address 122.44 would have broadcast address 122.44.0.0. The value 1 sets the broadcast address to use 255 for the host portions of the IP address. For example, a Class B network with network address 122.44 would have broadcast address 122.44.255.255.

Summary of NetBIOS NET.CFG Protocol RFCNBIOS Section Settings

Parameter | Explanation REMOTENAMEn IP_address | This parameter specifies an IP address on a different broadcast network from the workstation. This address is preloaded in the NetBIOS name cache. The value of n can be from 1 through 16.

The following information describes the configuration of the NetBIOS settings in the NET.CFG file.

### NB_ADAPTER { 0 | 1 }

This parameter specifies which NetBIOS adapter number to bind to TCP/IP. This value must be either 0 or 1 (the first network board is 0, the second is 1).

You can specify this setting using NB_ADAPTER in the following format:

>     NB_ADAPTER { 0 | 1 }

For example:

>     PROTOCOL TCPIP
>       IP_ADDRESS 129.47.6.84
>       .
>       .
>       NB_ADAPTER 0

The default value for this setting is 0.

### NB_BRDCAST { 0 | 1 } IP_address

This parameter specifies the format of IP broadcasts used when RFCNBIOS.EXE sends broadcast messages.

The value 0 sets the broadcast address to use zeroes for the host portions of the IP address. Therefore, a Class B network with a network address of 129.47 would have a broadcast address of 129.47.0.0.

The value 1 sets the broadcast address to use 255 for the host portions of the IP address. Therefore, a Class B network with a network address of 129.47 would have a broadcast address of 129.47.255.255.

You can specify this setting using NB_BRDCAST in the following format:

>     NB_BRDCAST { 0 | 1 }

For example:

>     PROTOCOL TCPIP
>       IP_ADDRESS 129.47.6.84
>       .
>       .
>       NB_BRDCAST 0

The default value is 1.

### NB_COMMANDS number

This parameter specifies the maximum number of asynchronous NetBIOS commands. Each pending NetBIOS command requires 32 bytes of memory.

You can specify this setting using NB_COMMANDS in the following format:

>     NB_COMMANDS number

For example:

>     PROTOCOL TCPIP
>       IP_ADDRESS 129.47.6.84
>       .
>       .
>       NB_COMMANDS 16

You can specify a value from 0 through 80 for number. By default, number has the value of 8.

### NB_DOMAIN domain_name

This parameter specifies the name of the logical domain for this NetBIOS station. All stations in the same logical domain must use the same value for NB_DOMAIN.

You can specify this setting using NB_DOMAIN in the following format:

>     NB_DOMAIN domain_name

For example:

>     PROTOCOL TCPIP
>       IP_ADDRESS 129.47.6.84
>       .
>       .
>       NB_DOMAIN BIOSPHERE_2

You can specify a string with up to 80 characters for domain_name. By default, domain_name has a null value.

### NB_SESSIONS number

This parameter specifies the maximum number of concurrent NetBIOS sessions. Your TCP_SOCKETS setting must be at least 1 plus the number of sessions you specify with the NB_SESSIONS setting. You can specify a number from 0 through 64.

You can specify this setting using NB_SESSIONS in the following format:

>     NB_SESSIONS number

For example:

>     PROTOCOL TCPIP
>       BIND NE1000
>       IP_ADDRESS 129.47.6.84
>       .
>       .
>       NB_SESSIONS 8

The default value for number is 4.

### REMOTENAMEn IP_address

This parameter is included in the PROTOCOL RFCNBIOS section of the NET.CFG file. It specifies an IP address that is not on the same broadcast network as your workstation. This address is preloaded in the NetBIOS name cache.

You can specify the IP address with REMOTENAME in the following format:

>     REMOTENAMEn IP_address

where n is the number you assign to an IP address, and IP_address is the IP address in decimal notation.

For example:

>     PROTOCOL RFCNBIOS
>       REMOTENAME1 129.57.52.6
>       REMOTENAME2 129.57.32.8

You can specify up to 16 remote names with this parameter.

### Setting Up Multiple Network Interfaces The TCP/IP Transport software can support up to four simultaneous network connections. You can install up to four network boards in your workstation and communicate simultaneously with networks of the same or different types.

> Note: Configuring multiple network connections is not sufficient to designate a workstation as a router. A workstation connected to more than one network can communicate on each of the networks simultaneously, but it cannot route packets between these connections for other workstations.

You enable support for multiple networks by loading multiple ODI drivers and configuring them in the NET.CFG file. Depending on the network boards you install, you might load different ODI drivers or load the same ODI driver more than once. Each time you load an ODI driver, a separate LINK DRIVER section in the NET.CFG file provides the configuration parameters.

For example, if your workstation has both a token-ring network board and an NE2000 Ethernet network board, you can connect to two different networks. You need to load both TOKEN.COM and NE2000.COM. Your NET.CFG file would have two LINK DRIVER sections similar to the following:

>     LINK DRIVER TOKEN
>       FRAME TOKEN-RING_SNAP

>     LINK DRIVER NE2000
>       INT #1 5
>       PORT #1 320
>       FRAME ETHERNET_II

You need only one LINK SUPPORT section to configure LSL.COM, which automatically supports both ODI drivers.

Each network connection has its own IP address and its own optional router address and subnetwork mask. In the PROTOCOL TCPIP section of NET.CFG, you need to designate which settings apply to each connection. To do this you assign a name to each network for use within NET.CFG. You can then use the name with each TCP/IP setting and use BIND statements to associate the settings with their network connections.

For example, you can assign the name FINANCE-NET to the token-ring connection, and assign MARKETING-NET to the Ethernet connection. You can then set up TCP/IP address settings for the two names:

>     PROTOCOL TCPIP
>       IP_ADDRESS     144.52.6.5     FINANCE-NET
>       IP_ROUTER      144.52.6.6     FINANCE-NET
>       IP_NETMASK     255.255.0.0    FINANCE-NET
>       IP_ADDRESS     122.44.9.7     MARKETING-NET
>       IP_ROUTER      122.44.3.97    MARKETING-NET
>       IP_NETMASK     255.255.0.0    MARKETING-NET

You then use Bind to associate the appropriate driver (board instance) with its setting (network name):

>     BIND TOKEN #1 TOKEN-RING_SNAP FINANCE-NET
>     BIND NE2000 #1 ETHERNET_II MARKETING-NET

The BIND statement specifies the driver, board instance, frame format, and network name for each connection. In this example, two different ODI drivers are used, and each is the first instance of its board type.

The board instance numbers are used by BIND to distinguish different instances of the same ODI driver. They are not the same as the logical board numbers displayed by the ODI drivers when they are loaded. For example, if you have two ARCnet boards in your workstation, you load the TRXNET.COM driver twice, once to support each board. Board instance #1 is the first TRXNET.COM loaded into memory, and instance #2 identifies the second copy of TRXNET.COM in memory.

> Note: When multiple network interfaces are configured and an application tries to reach a destination host that is outside the immediate networks of the interfaces connected, the protocol stack sends the packet through the default interface which is the first network specified in the NET.CFG file. This network is specified in the IP_ROUTER setting of the PROTOCOL TCPIP section.

### Setting Up SLIP and PPP

The TCP/IP Transport software supports asynchronous serial line media by implementing the Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) in an ODI driver. SLIP and PPP operate on a workstation's COM devices. This driver supports the two most popular link layer protocols: SLIP and PPP. This support includes optional Van Jacobson TCP/IP header compression.

The following documents provide background information for the SLIP and PPP protocols.

- RFC 1055, A Nonstandard for Transmission of IP Datagrams over Serial Lines
- RFC 1144, Compressing TCP/IP Headers for Low-Speed Serial Links
- RFC 1331, The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams over Point-to-Point Links
- RFC 1332, The PPP Internet Protocol Control Protocol

The TCP/IP protocol stack receives the same functional support from the NCOMX and NWREMOTE drivers as from other LAN drivers except BOOTP and RARP. TCP/IP disables BOOTP and RARP support when TCP/IP is operating on the NCOMX and NWREMOTE drivers. When you use the SLIP frame type, the TCPIP driver does not load if the NET.CFG file does not specify an IP address. However, when you use the PPP frame type, the TCPIP driver loads in anticipation of IP address assignment from a remote host through PPP options negotiation.

The normal load sequence of the ODI driver should be followed when activating the protocol stack; that is, the NCOMX and NWREMOTE drivers must be loaded after the LSL driver but before the TCPIP driver. You can configure the NCOMX driver using parameter settings in the LINK DRIVER NCOMX section of your NET.CFG file. You can configure the NWREMOTE driver using parameter settings in the PROTOCOL NWREMOTE section of your NET.CFG file.

> Note: For simple communications tasks, such as terminal access or file transfer, using TCP/IP over SLIP or PPP may be inefficient. It may be more effective to use a direct serial connection with terminal emulators and Kermit or Zmodem type protocols for file transfer. However, if you plan to use more sophisticated network services or connect to an internetwork, TCP/IP over SLIP or PPP is very effective.

A workstation-to-LAN or workstation-to-internetwork connection is the most probable configuration for the NCOMX and NWREMOTE drivers. A user with a personal computer at home or in a dormitory or remote office, or with a laptop while traveling, can dial in to the company or university LAN and instantly become the equivalent of a local workstation on the LAN. A remote user can access the same services that are available to the local workstation and gain Internet access if Internet service is available. A dial-up router using either the SLIP or PPP protocol is required on the LAN side.

### Applications Running over the NCOMX Driver

For NCOMX to run reliably in MS Windows 386 enhanced mode, a COM device based on 16550A UART (Universal Asynchronous Receiver/Transmitter) is recommended. The 16550 includes a FIFO (first in, first out) buffer that improves throughput and reduces interrupt overhead. If you experience errors when using COM devices based on the slower 8250 or 16450 UART, try to lower the communication line speed by setting a lower baud rate value. Also, lowering the maximum receive and transmit unit (MAXIMUM FRAME SIZE) size in your NET.CFG file might correct the problem.

### Loading the NCOMX Driver

The NCOMX driver must be loaded after the LSL driver but before the TCPIP driver. You must configure SLIP or PPP by setting parameters in your NET.CFG file. A sample NET.CFG file for the NCOMX driver is shown in the following example.

#### Sample Serial Port Settings in the NET.CFG File

>     LINK DRIVER NCOMX
>           INT 4
>           PORT 3F8
>           BAUD 9600
>           FRAME SLIP

### NET.CFG Settings for the NCOMX Driver

The serial port has several LINK DRIVER NCOMX settings in addition to those illustrated in the previous example. All serial port settings are summarized in Table 2-10 and described in the following section.

NET.CFG Settings for NCOMX Driver

Keyword | Value | Default | Description FRAME | SLIP or PPP | PPP | This setting defines frame type on serial line media. Select SLIP or PPP.
BAUD | 300, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200 | 9600 | This setting specifies the serial line speed in decimal format.
INT | IRQ level | 4 | This setting specifies the interrupt level of the COMn: device.
MAX FRAME SIZE n [ m] |  | 1500 | This setting specifies the maximum receive and transmit unit for SLIP_PPP where n is bytes in decimal; the valid range is 76 through 1500 bytes. The optional parameter m instructs SLIP_PPP to assume the largest receive size character mapping scenario.
PORT | Base I/O address | 3F8 | This setting specifies the default address. By default, PORT is 3F8 and INT is 4 (COM1 settings)

### LINK DRIVER NCOMX Settings

The NCOMX driver is customized in the LINK DRIVER section of the NET.CFG file.

The following NET.CFG settings are common to NCOMX:

- BAUD
- FLOW CONTROL
- FRAME
- INT
- MAX FRAME SIZE
- MODEM NAME
- PORT

The following paragraphs describe these NET.CFG settings.

### BAUD

The BAUD setting lets you select a baud rate for the NCOMX driver to use. For example:

>     LINK DRIVER NCOMX
>       INT 4
>       PORT 3F8
>       BAUD 9600
>       FRAME SLIP

The default value is 9600 baud.

### FRAME

The FRAME setting lets you select either the SLIP or the PPP protocol. SLIP defines a sequence of characters that frame IP packets on a serial line. It provides no addressing, packet type identification, error detection or correction, or compression. PPP conveys multiple protocol packets on the same point-to-point link and provides error detection. For example:

>     LINK DRIVER NCOMX
>       INT 4
>       PORT 3F8
>       BAUD 9600
>       FRAME SLIP

The default valueis PPP.

### MAX FRAME SIZE n [ m ]

The MAX FRAME SIZE setting lets you specify the maximum receive and transmit units for the SLIP or PPP protocol.

The MAX FRAME SIZE value (format of n [ m ]) is a decimal number within the range of 76 through 1500 bytes. The optional parameter m (for mapped) instructs the NCOMX driver to assume the worst case character mapping scenario where every data byte in a packet could be mapped into two bytes as required by the ACCM configuration (for example, a 500-byte packet could double its size to 1000 bytes). NCOMX uses half of the mru as its largest receive size, and the protocol stack uses that as the maximum datagram size it can send. The optional parameter m applies to PPP only. For example:

>     LINK DRIVER NCOMX
>       INT 4
>       PORT 3F8
>       BAUD 9600
>       MAX FRAME SIZE 1500
>       FRAME SLIP

The default value is 1500 for PPP and 1006 bytes for SLIP.

### INT

The int setting lets you specify the interrupt request line of your COMn: device for the NCOMX driver. For example:
LINK DRIVER NCOMX INT 3 PORT 2F8 BAUD 9600 FRAME SLIP

The default value is 4.

### PORT

The PORT setting lets you specify the base I/O address of your COMn: device for the NCOMX driver to use. For example:

>     LINK DRIVER NCOMX
>       INT 4
>       PORT 3F8
>       BAUD 9600
>       FRAME SLIP

The default value is 3F8.

The normal interrupt levels and port I/O addresses for COMn: ports are as follows:

| Int (Interrupt) | Port COM1: | 4 | 3F8
COM2: | 3 | 2F8
COM3: | 4 | 3E8
COM4: | 3 | 2E8

### NET.CFG Settings for the NWREMOTE Driver

The NWREMOTE has several PROTOCOL settings in addition to those illustrated earlier. All NWREMOTE settings are summarized in the table below and are described in the following section.

NET.CFG Settings for NWREMOTE

Keyword | Value | Default | Description ACCM [ REMOTE ] map_number | map_number | ffffffff | The four-byte hexadecimal map number specifies an asynchronous control character map.
ACCOMP [ REMOTE ] { YES | NO } |  | No | This setting enables or disables the PPP frame address and control fields compression.
PCOMP [ REMOTE ] { YES | NO } |  | No | This setting enables or disables the PPP frame protocol field compression.
AUTHEN [ REMOTE ] PAP username password |  | None | This setting enables and defines Password Authentication Protocol (PAP) usernames and passwords.
COUNTER timeout max_config max_term max_nak [ protocol ] |  |  | The values are defined as follows:
| timeout | 3 | timeout - restart timer timeout in seconds
| max_config | 10 | max_config - retry counter for configuration-request
| max_term | 2 | max_term - retry counter for terminate- request PAP does not use max_term.
| max_nak | 10 | max_nak - retry counter for configuration-nak
| protocol |  | protocol can be TCP, IPCP, or PAP.
IPADDR [ REMOTE ] IP_address |  | None | This setting specifies the IP addresses in dotted notation for negotiation.
MAGIC [ REMOTE ] seed_number |  | Not enabled | This setting specifies the initial seed number for process recognition.
TCPIPCOMP [ REMOTE ] { VJ | NO } [ slots ] [ comp_slot ] |  |  | This setting enables or disables the Van Jacobson (VJ) header compression as follows: VJ or No - compress or do not compress
|  | slots = 16 | slot - 1 through 16 conversation slots
|  | comp_slot = 0 | comp_slot - do not compress slot ID (0) or compress slot ID (1)

### Protocol NWREMOTE Settings

The following NET.CFG settings are specific to NWREMOTE:

- ACCM
- ACCOMP
- AUTHEN
- COUNTER
- MAGIC
- IPADDR
- TCPIPCOMP

The ACCM, ACCOMP, IPADDR, MAGIC, PCOMP, and TCPIPCOMP settings use the remote variable. If you do not specify remote, the setting defaults to local. The remote specifier instructs NWREMOTE to use the value entered in response to the remote site configuration requests.

### ACCM [ REMOTE ] map_number

The ACCM [ REMOTE ] setting lets you specify whether the PPP protocol should use the asynchronous control character map (ACCM). ACCM is a configuration option that provides a way to negotiate the use of control characters (0x0 through 0x1F) for mapping on an asynchronous link.

When sending data, each character with a value less than 0x20 that is flagged in the remote ACCM is replaced by a 2-byte sequence consisting of the Control-Escape character (0x7D) and the original character with bit 6 complemented. Conversely, when receiving, the mapped 2-character sequence is converted back to the original character.

The eight hexadecimal bytes in ACCM use bit numbering from 31 to 0 from left to right. Each numbered bit corresponds to a control character with the same number value. When the bit is set to 0, the character does not need to be mapped; when the bit is set to 1, the character needs to be mapped.

The following example asks the remote host to map the escape XON (0x11) and XOFF (0x13) characters. For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 000A0000
>       ACCOMP YES
>       MAGIC 1234FFFF
>       IPADDR 155.55.5.255

XON and XOFF have decimal values of 17 and 19, respectively, and the 17th and 19th bits of ACCM are set to one to request the remote host to send the appropriate 2-character sequences (0x7d, 0x31 and 0x7d, 0x33) when an XON or XOFF is encountered in the data packet. The default value is ffffffff.

### ACCOMP [ REMOTE ] { YES | NO }

The ACCOMP [ REMOTE ] setting lets you instruct the NWREMOTE driver to compress the address and control field of the PPP header. For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 00000000
>       ACCOMP YES
>       MAGIC 1234FFFF
>       IPADDR 155.55.5.255

The default value is No.

### AUTHEN [ REMOTE ] PAP username password

The AUTHEN setting lets you specify whether the PPP protocol should use authentication. If selected, PPP uses the name and password to identify the local system to the peer. This process is based on the Password Authentication Protocol (PAP). If you specify the REMOTE option, PPP uses username and password to authenticate the login username in the NET.CFG file. For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 00000000

>       ACCOMP YES

>       AUTHEN PAP BRIAN BANG

>       MAGIC 1234FFFF

>       IPADDR 155.55.5.255

### COUNTER protocol timeout max_config max_term max_nak

The COUNTER setting lets you specify a timeout value and three retry counters for the PPP protocol. All values are in decimal format.

The protocol parameter can be any of the following:

- LCP---link control protocol
- IPCP---Internet protocol control protocol
- PAP---password authentication protocol

If you do not specify the protocol, changes are applied to all protocols.

For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 00000000
>       ACCOMP YES
>       MAGIC 1234FFFF
>       IPADDR 155.55.5.255

timeout | The timeout value for restarting the transmission of request packets. The default value is 3 seconds.
max_config | The number of retries for sending a configuration request. The default value is 10 times.
max_term | The number of retries for sending a terminate request. The max_term value is not used by PAP. The default value is 2 times.
max_nak | The number of retries for sending a configuration NAK. The default value is 10 times.

### IPADDR [ REMOTE ] IP_address

The IPADDR [ REMOTE ] setting lets you specify the IP addresses for PPP negotiation (in dotted decimal notation). If you specify the REMOTE option, PPP tries to assign the address to the remote host if the remote host did not specify an address to use in its configuration request. For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 00000000
>       ACCOMP YES
>       MAGIC 1234FFFF
>       IPADDR 155.55.5.255

There is no default value for this setting. If you specify 0.0.0.0, PPP determines your IP address from the remote end.

### MAGIC [ remote ] seed_number

The MAGIC [ REMOTE ] setting provides a way to detect looped-back links and other datalink anomalies. The NWREMOTE driver uses the value you specify as a seed number to generate a unique number to identify itself. If you specify REMOTE, PPP tries to get the peer to use the number specified (that is, if the peer does not indicate that it will use the magic number in its initial configuration request). The MAGIC setting is a 4-byte hexadecimal number. For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 00000000
>       ACCOMP YES
>       MAGIC 1234FFFF
>       IPADDR 155.55.5.255

The default value is not to use the magic setting.

### TCPIPCOMP [ REMOTE ] { VJ | NO } [ slots | comp_slot ]

The TCPIPCOMP setting enables or disables the Van Jacobson (VJ) TCP/IP header compression for the SLIP or PPP protocol as follows:

- VJ or NO --- compress or do not compress
- slot --- number of conversation slots (1 through 16)
- comp_slot --- do not compress slot ID (0) or compress slot ID (1)

The format is as follows:

>     tcpipcomp {VJ
>     | NO} [slots comp_slot]

If you specify NO (for no compression), you can omit the slots and comp_slot values. If you specify these values with the NO option, they are ignored. For example:

>     PROTOCOL NWREMOTE
>       TCPIPCOMP VJ 16 1
>       COUNTER LCP 5 10 5 10
>       ACCM 00000000
>       ACCOMP YES
>       MAGIC 1234FFFF
>       IPADDR 155.55.5.255

The default values for TCPIPCOMP are 16 slots and 0 (no compression).

### Setting Up the SNMP Agent

SNMP is a Simple Network Management Protocol (SNMP) agent TSR program. It lets a remote Network Management Station (NMS) monitor the TCP/IP protocol stack running on the workstation. SNMP allows remote and local SNMP clients complete access to the TCP/IP portion of the Management Information Base (MIB). SNMP supports the MIB-II variables.

To use the LWPCON utility to access SNMP, see "Running LWPCON". LWPCON does not require the SNMP agent to be running on the workstation to return local statistics. The SNMP TSR is required if you want remote SNMP client programs to be able to gather statistics from your workstation.

The SNMP protocol is fully described in RFC 1157, Simple Network Management Protocol (SNMP). The MIB-II standard is described in RFC 1213, Management Information Base for Network Management of TCP/IP-Based Internets: MIB-II.

To use the SNMP agent on a workstation, you must first load and bind TCP/IP to the interface it will be using. The typical loading sequence is as follows:

>     LSL
>     NE2000 (or appropriate driver)
>     TCPIP
>     SNMP

The agent is a terminate and stay resident (TSR) program that can be loaded by typing the following command:

>     SNMP <Enter>

To remove the agent from memory, type the following command:

>     SNMP U <Enter>

You configure the SNMP agent by adjusting settings in the NET.CFG file. If NET.CFG is not configured for SNMP, it runs with the MonitorCommunity variable set to public (all clients can read the MIB values) and ControlCommunity set to disabled (client write access to the MIB values is not allowed).

### SNMP NET.CFG Summary

There are five SNMP settings under the Protocol SNMP section of the NET.CFG configuration file. This table summarizes the valid and default values of these settings:

NET.CFG Settings for SNMP

Parameter | Explanation SYSCONTACT | This parameter specifies the name of the person who is responsible for this machine. Normally, this will be the name of the person using the machine.
SYSNAME | This parameter specifies the full domain name.
SYSLOCATION | This parameter specifies the physical location of the machine.
MONITORCOMMUNITY | This parameter sets the community name for read-only access. By default, this community is public.
CONTROLCOMMUNITY | This parameter sets the community name for read and write access. By default, this community is disabled.

### Community Names

Community names are used to authenticate SNMP request messages received at the agent. The community name in a message requesting a given access type must match the name defined for that access type by one of the SNMP community options.

Community names are arbitrary 32-character text strings. You can use the string noAccess to disable the appropriate community. This name is reserved and is not case sensitive.

### SNMP Operations

The SNMP protocol allows four operations:

- Retrieve specific management information
- Retrieve general management information
- Manipulate management information
- Report extraordinary events

The Trap operation has not been implemented in this release.

### Authentication

SNMP defines a community as a relationship between an SNMP agent and one or more SNMP managers. At the present, only trivial authentication mechanisms are available with SNMP. This means that the community name is placed, in clear text, in an SNMP message. If the community name corresponds to a community known to the receiving SNMP entity, the sending SNMP entity is considered to be authenticated as a member of that community.

The SNMP agent lets you specify any community names you require. Two different communities are used by the agent. The monitor community is used for read-only access; the control community is used for read-write access. If the community name is not known to the agent, the request from the SNMP manager station is ignored.

By default, the monitor community is set to public and the control community is disabled. To override these default settings, edit the NET.CFG file.

### Example NET.CFG Configurations

This section contains examples of NET.CFG files set up for different purposes. You can copy the appropriate parts of these examples into your workstation's NET.CFG file if you have a similar configuration.

This section provides the following examples:

- Setting up a token ring configuration
- Setting up an ARCnet configuration
- Configuring a SLIP or PPP asynchronous serial line
- Configuring the SNMP agent
- Setting up multiple network connections
- Running IPX and IP concurrently

### Token Ring Configuration

The following example shows how to configure NET.CFG for a token ring TCP/IP network using the TOKEN.COM driver. IPX support is not configured in this example. The frame type used on token ring TCP/IP networks is always TOKEN-RING_SNAP. The increased buffer size (4202) is recommended only if problems are encountered using the default size (1500).

#### Sample NET.CFG File for Token Ring

>     LINK DRIVER TOKEN
>            FRAME TOKEN-RING_SNAP

>     LINK SUPPORT
>            BUFFERS 8 4202
>            MEMPOOL 4096

>     PROTOCOL TCPIP
>            PATH TCP_CFG        C:\NET\TCP
>            IP_ADDRESS          144.52.6.5
>            IP_ROUTER           144.52.6.6
>            IP_NETMASK          255.255.0.0

### ARCnet Configuration

The following example shows how to configure NET.CFG for an ARCnet network. IPX support is not configured in this example. This example uses a TRXNET board with NOVELL_RX-NET frame format, which is the frame format always used on ARCnet TCP/IP networks.

#### Sample NET.CFG File for ARCnet

>     LINK DRIVER TRXNET
>            FRAME NOVELL_RX-NET

>     LINK SUPPORT
>            BUFFERS 8 1500
>            MEMPOOL 4096

>     PROTOCOL TCPIP
>            PATH TCP_CFG        C:\NET\TCP
>            IP_ADDRESS          144.52.6.5
>            IP_ROUTER           144.52.6.6
>            IP_NETMASK          255.255.0.0

### SLIP and PPP Configurations

This section includes examples of the NET.CFG file for SLIP and PPP frame types.

The following example provides an sample NET.CFG file using SLIP frame type.

#### NET.CFG File Using SLIP Frame Types

>     LINK SUPPORT
>           BUFFERS          8 1500
>           MEMPOOL          4096

>     LINK DRIVER NCOMX
>           INT              4
>           PORT             2F8
>           BAUD             2400
>           FLOW CONTROL     1
>           MAX FRAME SIZE   800
>           FRAME            SLIP

>     PROTOCOL NWREMOTE
>           TCPIPCOMP        VJ 16 1
>           COUNTER          LCP 5 10 5 10
>           ACCM             00000000
>           ACCOMP           YES
>           MAGIC            1234FFFF
>           IPADDR           129.47.236.1

>     PROTOCOL TCPIP  PATH TCP_CFG     C:\NET\TCP
>           IP_ADDRESS       129.47.236.1
>           IP_NETMASK       255.255.255.0
>           IP_ROUTER        129.47.236.11
>           TCP_SOCKETS      8
>           UDP_SOCKETS      8
>           RAW_SOCKETS      1

The configuration in the previous example installs NWREMOTE to run on COM1: at 2400 baud, use a maximum packet size of 800 bytes, and enable Van Jacobson Header Compression.

SLIP is not capable of exchanging configurations, so the configurations have to be set statically and pre-agreed upon among peers. Configuration values such as max frame size and whether VJ compression are used need to be set to match the peer values.

The following example shows the NET.CFG file using the PPP frame type.

#### NET.CFG File Using PPP Frame Type

>     Link Support
>           Buffers             8 1500
>           MemPool             4096

>     LINK DRIVER NCOMX
>           INT                 4
>           PORT                3F8
>           BAUD                9600
>           FLOW CONTROL        1
>           MAX FRAME SIZE      1000
>           FRAME               PPP

>     PROTOCOL NWREMOTE
>           TCPIPCOMP           VJ 16 1
>           COUNTER             LCP 5 10 5 10
>           ACCM                00000000
>           ACCOMP              YES
>           MAGIC               1234FFFF
>           IPADDR              0.0.0.0

>     PROTOCOL TCPIP
>           TCP_SOCKETS         8
>           UDP_SOCKETS         8
>           RAW_SOCKETS         1

The configuration in the previous example installs NCOMX to run on COM2: at 9600 baud, uses a maximum packet size of 1000 bytes, and sends the following information about the local workstation to the remote host.

- None of the ASCII control characters need to be mapped
- Handles compressed PPP frames
- Interprets compressed TCP/IP packets using the Van Jacobson algorithm.

The NCOMX driver will run on directly connected null-modem lines.

PPP negotiates link layer and network layer configurations among peers. The NET.CFG file in the previous example requests that the peer assign an IP address for you to use (no local IP_ADDRESS is specified under PROTOCOL TCPIP). The protocol stack TCP/IP will use the negotiated local and remote IP addresses to set its operating IP address, IP net mask, and router IP address. They are not statically configured in the PROTOCOL TCPIP section of the NET.CFG file.

### SNMP Agent Configuration

The following example shows the NET.CFG file for configuring the SNMP agent.

#### NET.CFG with SNMP Settings

>     LINK SUPPORT
>            BUFFERS                8 1500
>            MEMPOOL                4096

>     PROTOCOL TCPIP
>            BIND                   NE2000

>     PROTOCOL SNMP
>            MONITORCOMMUNITY       PUBLIC
>            CONTROLCOMMUNITY       NOVELLADMIN
>            SYSCONTACT             HORACE FELTON
>            SYSNAME                HORACEF@SUCCESS.COM
>            SYSLOCATION            BUILDING #1 - OFFICE 209

>     LINK DRIVER NE2000
>            FRAME                  ETHERNET_II

### Multiple Network Configuration

The following example shows a NET.CFG file set up to configure two different network connections, one through an NE2000 Ethernet board and one through asynchronous serial ports.

#### Example NET.CFG File for Multiple Network Connections

>     LINK SUPPORT
>           BUFFERS 8 1500
>           MEMPOOL 4096

>     LINK DRIVER NE2000
>           INT              5
>           PORT             300
>           MEM              D0000
>           FRAME            ETHERNET_II
>           PROTOCOL IPX 8137 ETHERNET_II

>     LINK DRIVER NCOMX
>           INT              4
>           PORT             3F8
>           BAUD             19200
>           FLOW CONTROL     1
>           MAX FRAME SIZE   1500
>           FRAME            PPP

>     PROTOCOL NWREMOTE
>           TCPIPCOMP        VJ 16 1
>           COUNTER          LCP 5 10 5 10
>           ACCM             00000000
>           ACCOMP           YES
>           MAGIC            1234FFFF
>           IPADDR           129.47.236.12.3

>     PROTOCOL TCPIP
>           TCP_SOCKETS      8
>           UDP_SOCKETS      8
>           RAW_SOCKETS      1
>           IP_ADDRESS       0.0.0.0           LOCAL-NET
>           IP_ADDRESS       93.57.6.168       ENGINEERING-NET
>           IP_ROUTER        93.57.4.254       ENGINEERING-NET
>           IP_NETMASK       255.255.0.0       ENGINEERING-NET
>           BIND NCOMX #1 PPP LOCAL-NET
>           BIND NE2000 #1 ETHERNET_II ENGINEERING-NET

This NET.CFG file does the following:

- Configures LSL to support all connections (LSL will direct network packets to and from each of the two interfaces).
- Configures the NE2000 driver to support two protocol stacks simultaneously: TCP/IP (Ethernet_II frame type) and IPX (Ethernet_802.3 frame type). This driver becomes NE2000 board instance #1 for the BIND statement later in the NET.CFG file.
- Configures the NCOMX driver to operate on the COM1: port (interrupt 4).
- Allocates eight TCP sockets, eight UDP sockets, and one raw socket for use by both network connections.
- Assigns the name ENGINEERING-NET to the NE2000 connection and assigns the name LOCAL-NET to the first SLIP/PPP connection.

  The network names are arbitrary and are used only within the NET.CFG file. Their only purpose is to identify which parameter settings apply to each network connection.

- Assigns an IP address, router IP address, and subnetwork mask for each network name.
- Specifies that the first NCOMX driver is to use the LOCAL-NET parameters and frame type PPP (BIND statement).
- Specifies that the NE2000 connection is to use the ENGINEERING-NET parameters and frame type ETHERNET_II.

The batch file that loads the drivers configured by this NET.CFG file loads both the NE2000.COM and the NCOMX driver, as in the following example.

#### Example Batch File for Multiple Network Connections

>     C:\YESNO "DO YOU WANT TO LOAD THE NETWORKING SOFTWARE?"
>     IF ERRORLEVEL 1 GOTO NOLOAD
>     PATH C:\NET\BIN;%PATH%
>     C:\LSL.COM
>     C:\NESL.COM
>     C:\NE2000.COM
>     C:\NCOMX.COM
>     C:\NWREMOTE.COM
>     TCPIP.EXE
>     IPXODI.COM
>     VLM.EXE
>     :NOLOAD

When the batch file is executed, sign-on messages similar to the ones shown in the following example are displayed.

#### Example Sign-On Display for Multiple Network Drivers

>     NOVELL TCP/IP TRANSPORT V4.1 (920910)
>     (C) COPYRIGHT 1992 NOVELL, INC. ALL RIGHTS RESERVED
>     NETWORK NAME: ENGINEERING-NET  BIND: NE2000
>     IP ADDRESS:93.57.6.168         BOARD NUMBER: 1
>     SUBNET MASK: 255.255.0.0       BOARD INSTANCE: 1
>     DEFAULT ROUTER: 93.57.4.254    FRAME: ETHERNET_II
>     NETWORK NAME: LOCAL-NET        BIND: NCOMX
>     IP ADDRESS: 122.44.9.7         BOARD NUMBER: 2
>     SUBNET MASK: 255.255.0.0       BOARD INSTANCE: 1
>     DEFAULT ROUTER: 122.44.3.97    FRAME: PPP

### Concurrent TCP/IP and IPX Configurations

ODI supports concurrent TCP/IP and IPX protocol stacks. The LINK DRIVER section of the NET.CFG file must be modified if you plan to run both TCP/IP and IPX.

The following example is a sample NET.CFG file for using TCP/IP and IPX in an Ethernet configuration (ECONFIG) environment. In this example, both IPX and TCP/IP use the ETHERNET_II frame format.

#### Sample NET.CFG File for Concurrent TCP/IP and IPX Over Ethernet

>     LINK DRIVER NE1000
>             INT #1 5
>             PORT #1 320
>             FRAME ETHERNET_II                   # ALLOW ETHERNET II PACKETS

>     LINK SUPPORT
>             BUFFERS 8 1500
>             MEMPOOL 4096

>     PROTOCOL TCPIP
>             PATH TCP_CFG         C:\NET\TCP
>             IP_ADDRESS           129.47.6.129
>             IP_ROUTER            129.47.4.254
>             IP_NETMASK           255.255.0.0

The following example shows a sample NET.CFG file for using TCP/IP and IPX in the default Ethernet 802.3 environment. The following line configures IPX to run over Ethernet 802.3:

>     PROTOCOL IPX
>     0 ETHERNET_802.3

A Protocol IPX setting must be present to run IPX with TCP/IP when IPX is operating in an Ethernet 802.3 environment. In this example, TCP/IP uses the ETHERNET_II frame format, and IPX uses the ETHERNET_802.3 frame format.

#### Sample NET.CFG File for Concurrent TCP/IP and IPX Over Ethernet 802.3

>     LINK DRIVER NE1000
>            INT #1 5
>            PORT #1 320
>            FRAME ETHERNET_II                # ALLOW ETHERNET II PACKETS
>            FRAME ETHERNET_802.3             # ALLOW 802.3 PACKETS
>            PROTOCOL IPX 0 ETHERNET_802.3    # MAKE IPX USE 802.3

>     LINK SUPPORT
>            BUFFERS 8 1500
>            MEMPOOL 4096

>     PROTOCOL TCPIP
>            PATH TCP_CFG           C:\NET\TCP
>            IP_ADDRESS             129.47.6.129
>            IP_ROUTER              129.47.4.254
>            IP_NETMASK             255.255.0.0

The following example shows how to configure NET.CFG for a token ring network running both TCP/IP and IPX. In this example, TCP/IP uses the TOKEN-RING_SNAP frame format and IPX uses the TOKEN-RING frame format.

#### Sample NET.CFG File for Concurrent TCP/IP and IPX Over Token Ring

>     LINK DRIVER TOKEN
>            FRAME TOKEN-RING_SNAP
>            FRAME TOKEN-RING
>            PROTOCOL IPX E0 TOKEN-RING

>     LINK SUPPORT
>            BUFFERS 8 4202
>            MEMPOOL 4096

>     PROTOCOL TCPIP
>            PATH TCP_CFG      C:\NET\TCP
>            IP_ADDRESS        144.52.6.5
>            IP_ROUTER         144.52.6.6
>            IP_NETMASK        255.255.0.0

Top Introduction Utilities