Part II Expanding Your Network With PPP

Part 2 explains how to set up and administer asynchronous PPP communications links on the network. The text assumes that you are an experienced network administrator who is familiar with TCP/IP.

• "PPP Network Interfaces"

• "Point-to-Point Communications Links"

• "Multipoint Communications Links"

• "Determining IP Addressing for Your PPP Link"

• "Routing Considerations"

• "Checklist for Configuring PPP"

• "Installing the PPP Software"

• "Editing the /etc/asppp.cf Configuration File"

• "How to Manually Start PPP"

• "Checking Interface Status"

• "Checking Connectivity"

• "Configuring Dynamically Allocated PPP Links"

• "Configuring a Virtual Network"

• "Configuration Keywords"

Chapter 7 Understanding PPP

This chapter presents an overview of Solaris PPP, a data-link protocol included in the TCP/IP protocol suite. The text includes product specifications, introductions to the most typical PPP configurations, and definitions of the terms related to PPP.

• "Solaris PPP Specifications"

• "PPP Network Interfaces"

• "Point-to-Point Communications Links"

• "Dial-in Server With Dynamic Point-to-Point Link"

• "Multipoint Communications Links"

• "Introducing the PPP Software"

Overview of Solaris PPP

PPP enables you to connect computers and networks at separate physical locations by using modems and telephone lines. With PPP, users with computers at home or in remote offices can connect to your site's network. You can also use the combination of PPP software, a modem, and telephone lines as a router connecting networks in different places. PPP offers strategies for configuring these machines and networks, which are introduced in this chapter.

Solaris PPP Specifications

Solaris PPP is an asynchronous implementation of the standard data-link level Point-to-Point Protocol (PPP) included in the TCP/IP protocol suite and provided by a number of router system vendors and terminal concentrators. It includes a standard encapsulation protocol, making datagram transmission transparent to network layer protocols.

The major characteristics of the Solaris PPP protocol are:

• Implements the Internet Point-to-Point Protocol, as defined in RFC 1331

• Provides error detection through CRC

• Supports full duplex transmission

The major functions of the protocol are:

• Interface for IP to forward packets over asynchronous serial lines

• Connection establishment on demand

• Configurable options negotiation

• Connection termination (automatic hang-up)

Transmission Facilities Used by PPP

PPP supports interfaces to RS-232-C (V.24) facilities through the CPU serial ports included on most machines running the Solaris software. In addition, PPP runs over optional asynchronous serial ports supplied or supported by many manufacturers of machines that run the Solaris software. PPP supports the maximum data rates that your machine's serial ports can achieve. Consult the manufacturer of your computer system for more details on the speeds supported by your machine's serial hardware.

Machines of the x86 architecture require UARTs that run above a certain speed. See the for details.

Standards Conformance

PPP, and the routing functions in the Solaris software, use industry-standard conventions for performing their tasks. These conventions support:

• Forwarding of IP datagrams

• Reception of packets for forwarding from any IP-compatible networked system

• Delivery of packets to any IP-compatible networked system on local-area network media, such as Ethernet, Token Ring, and FDDI

• Use of standard routing protocols, enabling users to exchange packets with equipment that supports the PPP protocol from many manufacturers

PPP Network Interfaces

PPP enables asynchronous devices, such as modems, to become network interfaces. Solaris PPP enables you to configure two types of virtual network interfaces, ipdptpn and ipdn. (The letter n represents the device number you assign to the interface.)

PPP network interfaces are considered virtual network interfaces because they do not involve network hardware, as does, for example, an Ethernet interface. Moreover, they are not associated with any particular serial port. The PPP network interfaces reside in the /devices directories along with the physical network interfaces. (For information on physical network interfaces, see "Network Interfaces".)

The type of network interface you use depends on the PPP communications link you want to set up. The ipdptp interface supports point-to-point PPP links; the ipd interface supports point-to-multipoint links (called "multipoint links").

Extending Your Network With PPP

This section introduces PPP-related communications concepts used. It also explains the most typical PPP configurations that you are likely to set up.

Point-to-Point Communications Links

The most common use of Solaris PPP is to set up a point-to-point communications link. A generic point-to-point communications configuration consists of two endpoints connected by a communications link. In a generic configuration, an endpoint system could be a computer or terminal, either in an isolated location or physically connected to a network. The term communications link refers to the hardware and software connecting these endpoint systems. Figure 7-1 illustrates these concepts.

Figure 7-1 Basic Point-to-Point Link

Dial-out Operations and Outbound Communications

When an endpoint system wants to communicate with the end point on the other side of the communications link, it begins a dial-out operation. For example, to communicate with endpoint B, a user at its peer host, endpoint A, types rlogin end-point-B. This causes endpoint A to dial out over the communications link. In this instance, endpoint A functions as a dial-out machine. The rlogin command causes its modem to dial the phone number of endpoint B. The action it starts and information it passes are considered outbound communications.

Dial-ins and Inbound Communications

When the data travels over the link to endpoint B, this system receives incoming data and sends an acknowledgment signal to endpoint A to establish communications. In this instance, endpoint B functions as a dial-in machine, since it permits other systems to dial in to it. The information passed to the communications recipient and the actions the recipient takes are considered inbound communications.

Point-to-Point Configurations Supported by Solaris PPP

Solaris PPP supports four types of point-to-point configurations:

• Host in one location connected to a host at another physical location, as shown in Figure 7-1

• Dial-in servers with dynamic point-to-point links to remote hosts, as shown in Figure 7-2

• Network connected to another physically distant network, as shown in Figure 7-3

• Computers connected to a multipoint dial-in server physically attached to a distant network, as shown in Figure 7-4

These PPP links provide essentially the same type of connectivity provided by a local area network but without broadcast capability. The sections below summarize the configuration types; Chapter 8, Preparing Your PPP Configuration, gives information for setting up each configuration type.

Two Isolated Hosts Connected by a Point-to-Point Link

PPP enables you to set up a point-to-point link to connect two standalone machines in separate locations, effectively creating a network consisting solely of these two machines. This is the simplest point-to-point configuration because it involves only the two endpoints. The generic configuration shown in Figure 7-1 also uses the host-to-host configuration.

Nomadic Machines Connected to a Dial-in Server

In the past, standard dial-up or temporary connections permitted only ASCII terminals to connect to a network. With Solaris PPP, an individual machine can become part of a physically distant network by configuring it as one endpoint of the PPP link. The advantage of this nomadic connection is particularly apparent if your network includes users who travel frequently or work from home.

Figure 7-2 shows nomadic computers, each with a point-to-point link to an endpoint system on the network. The endpoint on the network is a dial-in server.

Figure 7-2 Nomadic Computers and Dynamic Link Dial-in Server

Dial-in Server With Dynamic Point-to-Point Link

The endpoint machine on the network shown in Figure 7-2 functions as a dial-in server with dynamic point-to-point links. It is called a dial-in server because remote machines can dial in to it to reach the network. When the server receives a request to dial in from a machine, the server allocates the PPP link to the machine on an as-needed basis.

A dial-in server can communicate with the remote hosts through a dynamic point-to-point link or through a multipoint link, as explained in "Multipoint Communications Links". The dynamic point-to-point link has the advantages of point-to-point communications: RIP can run over the link, and broadcasting is enabled. Perhaps most importantly, more than one machine on the physical network can function as the dial-in server. This allows you to configure backup servers, thus enabling redundancy and easier administration. Although the machines in Figure 7-2 can directly communicate with the network endpoint, they cannot directly communicate with each other. They must pass information to each other through the dial-in server endpoint.

Two Networks Connected by Point-to-Point Link

You can use PPP to connect two separate networks through a point-to-point link, with one system on each network serving as an endpoint. These endpoints communicate through modems and phone lines, essentially in the same fashion as shown in Figure 7-1. But in this setup, the endpoints, modems, and PPP software become routers for their physical networks. Using this type of configuration scheme, you can create an internetwork with wide geographic reach.

Figure 7-3 shows two networks in different locations connected by a point-to-point link.

Figure 7-3 Two Networks Connected by a PPP Link

In this example, endpoints A and B, their modems, public telephone lines, and the PPP software act as a router between the networks. These networks may have other hosts serving as routers between physical networks. Sometimes, the host functioning as the PPP router may have an additional network interface board, thus also serving as a router for a physical network.

Figure 7-4 Nomadic Computers and Multipoint Dial-in Server

Multipoint Communications Links

You can use Solaris PPP to set up a multipoint communications link. In this type of configuration, an individual machine functions as one endpoint on the communications link. At the other end of the link may be several endpoint machines. This differs from point-to-point configurations, with a single endpoint system at either side of the communications link.

Multipoint Configurations Supported by PPP

Two types of multipoint links you can configure with PPP are:

• Dial-in server with multipoint connections to remote machines, as shown in Figure 7-4

• Logical, or virtual, network consisting of three or more nomadic computers, as shown in Figure 7-5

The sections below summarize these configurations; Chapter 8, Preparing Your PPP Configuration, explains how to set up the configuration.

Multipoint Dial-in Servers

Figure 7-4 shows three geographically isolated computers communicating through a point-to-point link to an endpoint machine on a network. However, the network endpoint machine can communicate with the nomadic computers through a multipoint link, thus making it a multipoint dial-in server. (You can also set up a dial-in server with dynamic point-to-point connections, as explained in "Dial-in Server With Dynamic Point-to-Point Link".)

The dial-in server can communicate with all the machines on the other end of its multipoint PPP link. Though the machines in Figure 7-4 can directly communicate with the multipoint dial-in server, they cannot communicate directly with each other. They must pass information to each other through the dial-in server.

Virtual Networks

You can use PPP to set up a virtual network wherein the modems, PPP software, and telephone wires become the "virtual" network media. In a physical network, such as Ethernet or Token Ring, computers are directly cabled to the network media. In a virtual network, no true network media exist.

Machines become peer hosts on the virtual network when you configure each with a multipoint communications link. Then each host can dial out through its modem over phone lines to reach another endpoint machine. Each computer also functions as a dial-in machine, permitting its peer hosts on the virtual network to dial in to it.

Figure 7-5 depicts a virtual network consisting of nomadic computers connected to each other through modems and telephone lines.

Figure 7-5 Virtual Network of Nomadic Computers

Each machine exists in a different office, perhaps in a different town from other members of the virtual network. However, each machine can establish communications with its peer hosts over its multipoint communications links.

Introducing the PPP Software

The PPP component software includes:

• Link manager (/usr/sbin/aspppd)

• Log in service (/usr/sbin/aspppls)

• Configuration file (/etc/asppp.cf)

• Log file (/var/adm/log/asppp.log)

• FIFO file (/tmp/.asppp.fifo)

After you install the PPP software, you will find the /etc/init.d/asppp file, which is the run-control script for PPP. It is linked to several other files in the run-control directories.

Figure 7-6 shows the software components of PPP and how they interact.

Figure 7-6 PPP Component Software

Link Manager

The /usr/sbin/aspppd link manager is a user-level daemon that automates the process of connecting to a remote host when PPP service is required. This automated process starts whenever any activity that generates IP traffic takes place (for example, a user logs in to a remote machine, accesses an NFS-mounted file, and so on). If a remote host tries to establish a connection, the link manager on the local host will complete the connection.

Refer to the aspppd(1M) man page for specific information about the link manager.

Login Service

The /usr/sbin/aspppls login service is invoked as a login shell that starts PPP after you dial up and log in. Its function is similar to the /usr/lib/uucp/uucico command described in "Software Comprising UUCP". When configuring a machine as a dial-in server, you must specify aspppls as the login shell in the /etc/passwd file in the entries for every nomadic computer allowed to dial in to the local host.

Configuration File

The asppp.cf file provides the link manager with information about each remote endpoint with which the local host will communicate. You define this information in a section of the configuration file called a path. The path section also defines the PPP interface to be used and, optionally, other attributes determining how communications will take place, including security issues. "Parts of Basic Configuration File" explains the sections of the asppp.cf file in detail. Example 7-1 shows an unmodified asppp.cf file.

Example 7-1 An Unmodified asppp.cf File

#ident	"@(#)asppp.cf	10	93/07/07 SMI"
#
# Copyright (c) 1993 by Sun Microsystems, Inc.
#
# Sample asynchronous PPP /etc/asppp.cf file
#
#
 
ifconfig ipdptp0 plumb mojave gobi private up
 
path
   inactivity_timeout 120    # Approx. 2 minutes
   interface ipdptp0	  
   peer_system_name Pgobi    # The name this system logs in with when
                             # it dials this server
                             # *OR* the entry we look up in
                             # /etc/uucp/Systems when we dial out.

Log File

The link manager produces messages and logs them in the log file /var/adm/log/asppp.log. The level of detail reported into the file is controlled by the -d option of aspppd or the debug_level keyword in the configuration file. See "Configuration Keywords" and the aspppd(1M) man page for more information.

FIFO File

The PPP FIFO file /tmp/.asppp.fifo is a named pipe used to communicate between aspppd and aspppls. This file must be present in /tmp for the PPP login service to connect to the link manager. The /tmp/.asppp.fifo file is created, managed, and deleted by the link manager.

UUCP Databases

Besides its component software, Solaris PPP uses information in three UUCP files, /etc/uucp/Systems, /etc/uucp/Dialers, and /etc/uucp/Devices, to help it establish the communications link. You must modify these files to enable a host to dial out over the PPP link. Alternatively, you can use the file /etc/uucp/Sysfiles to specify different names for the Systems, Devices, and Dialers files.

Refer to Chapter 12, UUCP Databases and Programs, for full descriptions of these UUCP files.

How the Components Work Together

This section describes how the components of PPP function for outbound and inbound connections.

Outbound Connections Scenario

Outbound communications begin when a user on one endpoint host initiates an activity involving the peer host on the other end of the PPP link. The following activities take place when a user types an rcp command to copy a file from a host on the other side of the link

1. rcp sends the data through the levels of the TCP/IP protocol stack.

2. A virtual network interface (ipdn or ipdptpn) receives the data in the form of IP packets.

3. The interface sends the aspppd link manager a connection request that initiates an outbound connection.

4. The link manager then:

   1. Verifies that the connection request corresponds to a configured path in the /etc/asppp.cf configuration file.

   2. Consults the UUCP database files (/etc/uucp/Systems, /etc/uucp/Devices, and /etc/uucp/Dialers) for specific information about the modem and destination system.

   3. Places a phone call to the destination host or attaches to the appropriate hardwired serial line.

5. The physical link to the peer host is established.

6. The link manager configures and initiates PPP.

7. The data-link layer is established, and the PPP modules on the peer hosts start communicating.

8. The link manager enables IP over the link.

The link manager then monitors the connection until an even, such as an idle time out, line disconnect, or error condition, occurs. When any of these events occur, the link manager disconnects from the peer host and returns to the idle state.

Inbound Connections Scenario

The host initiating the inbound communication logs in, which invokes the /usr/sbin/aspppls login service. Then the following events occur:

1. The login service connects to the link manager through the /tmp/.asppp.fifo file.

2. The login service provides the link manager with information such as the login name used by the endpoint at the other end of the link.

3. The link manager uses this login name to find a corresponding configured path in the configuration file.

4. The link manager then configures and initiates PPP.

5. The data-link layer is established, and the PPP modules on the peer hosts start communicating.

6. The link manager enables IP over the link.

The link manager then monitors the connection until an event occurs such as an idle time out, line disconnect, or error condition. When any of these events occur, the link manager disconnects from the peer and returns to the idle state.

PPP Security

After you have completed installing PPP on every machine involved in your configuration, you can add either one or two levels of security for the PPP link.

The first level, Password Authentication Protocol (PAP), is the least secure. A password is sent over the circuit "in the clear" until authentication is acknowledged or the connection terminated.

The second level of security, Challenge-Handshake Authentication Protocol (CHAP), periodically verifies the identity of the peer--the other end of the point-to-point link. A challenge message is sent to the peer by the authenticator--the system starting the link or challenge. The response is checked against a "secret" not sent over the link, and if the values match, authentication is acknowledged. Otherwise, the link is terminated. The process of adding PPP security is described in "Editing asppp.cf for PAP/CHAP Security".

Chapter 8 Preparing Your PPP Configuration

Before configuring the PPP software, you need to prepare the hardware and software involved and gather some information that is needed during the configuration process. This chapter explains the tasks you have to perform prior to configuration, such as:

• Determining your network addressing scheme

• Ensuring that your hardware meets the requirements for PPP

• Preparing your software to meet the requirements for PPP

The chapter concludes with a checklist to help you organize this information before you configure your PPP link.

• "Remote Computer-to-Network Configuration"

• "Remote Host-to-Remote Host Configuration"

• "Network-to-Network Configuration"

• "Dial-in Server With Dynamic Point-to-Point Links"

• "Multipoint Dial-in Server"

• "Hosts on a Virtual Network"

• "Determining IP Addressing for Your PPP Link"

• "Assigning a Network Number to the PPP Link"

• "Turning Off RIP"

• "PPP Hardware Requirements"

Determining Requirements for Your Configuration Type

Solaris PPP supports many configuration options, including:

• Remote computer-to-network over a point-to-point link

• Remote computer-to-remote computer over a point-to-point link

• Network-to-network over a point-to-point link

• Dial-in server-to-multiple remote computers through one or more dynamic point-to-point links

• Dial-in server-to-multiple remote computers through a multipoint link

• Multiple remote computers comprising a virtual network, all communicating through multipoint links

These configurations are introduced in "Extending Your Network With PPP" in Chapter 7, Understanding PPP.

This section describes the information you need to gather and tasks you have to perform for each configuration type before beginning the configuration process. Read the section that describes the configuration you want to set up.

Areas you need to consider are:

• Network interface

• Addressing method

• Name service used, if any

• Dial-in as well as dial-out support

• Routing requirements

Remote Computer-to-Network Configuration

The remote computer-to-network is the most common asynchronous PPP configuration. Use it to configure machines in remote offices or user's homes that dial out over a point-to-point PPP link to a dial-in server on a network.

• Network interface - This point-to-point link uses the ipdptpn virtual network interface. You need to specify it in the configuration files of all remote machines that dial out to a network.

• Addressing method - The configuration file must include the host names or IP addresses of the machines that communicates over the link. For remote hosts, you should use existing host names and IP addresses. Refer to "Determining IP Addressing for Your PPP Link" for complete details.

• Name service - NIS and NIS+ name services are not recommended for remote hosts. These services generate a great deal of network traffic, often at unexpected times. The DNS name service is more efficient for this type of configuration. You might want to set up DNS, as described in Solaris Naming Administration Guide, on each remote host. If you don't use DNS, PPP accesses /etc/inet/hosts file on the remote machine.

• Dial-in and dial-out support - Remote hosts usually implement dial-out communications only. They do not allow other machines to dial in to them directly. Therefore, you must update the UUCP files on each to support dial-out communications, as explained in "Editing UUCP Databases".

• Routing requirements - Because RIP is part of the Solaris TCP/IP protocol stack, it runs by default on remote hosts. Turn off RIP to improve performance, if necessary, and instead use static routing. See "To Select Static Routing on a Host" and "Turning Off RIP" for details.

Remote Host-to-Remote Host Configuration

Use the host-to-host configuration to establish point-to-point communications between two remote hosts in different physical locations. This configuration is useful for two standalone machines in remote offices that need to exchange information. No physical network is involved.

• Network interface - This basic point-to-point link uses the ipdptpn virtual network interface. You must specify the interface in the configuration files of both endpoints.

• Addressing method - The configuration file must include the host names or IP addresses of the machines that can communicate over the link. Use the existing host names and the IP addresses assigned to the primary network interface, if they already exist. Otherwise, create IP addresses for the endpoints. Refer to "Determining IP Addressing for Your PPP Link" for complete details.

• Name service - Because only two peer hosts are involved, you don't need a true name service. The /etc/inet/hosts files on both peer hosts are used for address resolution.

• Dial-in and Dial-out support - Both machines need to perform dial-in and dial-out operations. You must modify the UUCP databases and /etc/passwd on both endpoints.

• Routing requirements - Because RIP is part of the Solaris TCP/IP protocol stack, it runs by default on remote hosts. Turn off RIP to improve performance, if necessary, and instead use static routing. See "To Select Static Routing on a Host" and "Turning Off RIP" for details.

Network-to-Network Configuration

Use the network-to-network PPP configuration to create an internetwork joining two networks in physically separate locations. In this case, modems and PPP software function as the router connecting the networks.

• Network interface - The point-to-point link uses the ipdptpn virtual network interface. You must specify ipdptpn in the configuration files for both endpoint machines joining the two networks.

• Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Two possible addressing scenarios exist for this type of configuration; they are explained in "Determining IP Addressing for Your PPP Link".

• Name service - NIS and NIS+ name services can function over this type of PPP link; however, each network should be a separate domain. If you use DNS, both networks can be part of a single domain. Refer to Solaris Naming Administration Guide for details. If you use local files for name service, the /etc/inet/hosts files on both endpoint machines are used for address resolution. They must contain the host names and IP addresses of every host on each network that can communicate over the link.

• Dial-in and Dial-out support - Both network endpoint machines need to perform dial-in and dial-out operations, so you should update their UUCP and /etc/passwd files.

• Routing requirements - The endpoints in a network-to-network link usually run RIP in order to exchange routing information. Do not disable RIP for this configuration.

Dial-in Server With Dynamic Point-to-Point Links

A dynamic point-to-point link is one of two types of configurations that you can use for a dial-in server functioning as the network endpoint that remote hosts access. In this configuration scheme, the server connects to its remote hosts over a dynamically allocated point-to-point link. The dial-in server uses its dynamic links on an as-needed basis to establish communications with the remote hosts it serves.

• Network interface - The dynamic point-to-point link uses the ipdptp* virtual network interface with an asterisk wildcard character. The asterisk enables the link to be allocated dynamically. You must specify this interface in the configuration file.

• Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Refer to "Determining IP Addressing for Your PPP Link" for complete details.

• Name service - Although NIS and NIS+ are not recommended for remote hosts, the dial-in server in a remote host-to-network configuration can be an NIS client on the network to which it is physically connected. If NIS is on the server's physical network, make sure that the NIS maps are updated with the host names and IP addresses of the remote hosts. You can use DNS on the dial-in server and its remote hosts. For more information regarding DNS and name services in general, refer to Solaris Naming Administration Guide. If you use local files for name service, PPP access the /etc/inet/hosts file on the dial-in server for address resolution.

• Dial-in support - You must update the /etc/passwd file on the dynamic point-to-point dial-in server. The dynamic link server does not directly dial out to the remote hosts.

• Routing requirements - Because RIP is part of the Solaris TCP/IP protocol stack, it runs by default on remote hosts. Turn off RIP to improve performance, if necessary, and instead use static routing. See "To Select Static Routing on a Host" and "Turning Off RIP" for details.

Multipoint Dial-in Server

A multipoint link is one of two types of configurations that you can use for a dial-in server functioning as the network endpoint that remote machines can access. In this configuration scheme, the dial-in server connects to multiple remote hosts over the same multipoint link. The remote hosts always connect to the dial-in server over a point-to-point link, as explained in "Remote Computer-to-Network Configuration".

Use this configuration when you want to define a separate network of remote hosts and their dial-in server.

• Network interface - The multipoint link uses the ipdn virtual network interface. You must specify this interface in the configuration file for the dial-in server.

• Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Refer to "Determining IP Addressing for Your PPP Link" for complete details. You must create a separate network for the machines on the multipoint link. See "Assigning a Network Number to the PPP Link" for more information.

• Name service - Although NIS and NIS+ are not recommended for remote hosts, the dial-in server in a remote host-to-network configuration can be an NIS client on the physical network to which it is connected. If NIS is on the server's physical network, make sure that the NIS maps are updated with the host names and IP addresses of the remote hosts. You can use DNS on the dial-in server and its remote hosts. For more information regarding DNS and name services in general, refer to Solaris Naming Administration Guide. If you use local files for name service, PPP uses the /etc/inet/hosts file on the dial-in server for address resolution.

• Dial-in and dial-out support - The multipoint dial-in server functions as a network router between its PPP virtual network and the physical network to which it is connected. It dials out to its remote hosts whenever it receives IP traffic from the physical network destined for its PPP network. Therefore, you must configure the multipoint dial-in server for both dial-in and dial-out support, and update its UUCP and /etc/passwd files.

• Routing requirements - The ipdn interface does not support RIP; there is no need to disable it.

Hosts on a Virtual Network

Use a virtual network configuration to connect three or more physically separated computers into a virtual network of phone lines, modems, and PPP software.

• Network interface - This type of configuration requires a multipoint link, which uses the ipdn virtual network interface. This interface connects each endpoint system with the other endpoints on the virtual network.

• Addressing method - The configuration file must include the host names or IP addresses of the machines that communicate over the link. Refer to "Determining IP Addressing for Your PPP Link" for more information. You must assign a network number to the virtual network. Refer to "Creating a Unique IP Address and Host Name" for complete details.

• Name Service - You can run NIS and NIS+ for the virtual network; however, this can affect the performance of the link. DNS is a better alternative. Refer to Solaris Naming Administration Guide for instructions on setting up these name services. If you use files for name service, be sure to update /etc/inet/hosts on each machine with the host names and IP addresses of all machines on the virtual network.

• Dial-in and dial-out support - All machines in the virtual network must be configured for both dial-in and dial-out operations, so you should update their UUCP and /etc/passwd files.

• Routing requirements - The ipdn interface does not support RIP; you do not need to disable it.

Determining IP Addressing for Your PPP Link

To enable communications over the PPP link, the machine at one end of the link must know the host name and IP address of the peer host on the other end of the link. The PPP configurations often require a particular addressing scheme. This section explains the addressing schemes and where each should be used.

Specifying IP Addresses

On each endpoint machine, you specify addressing information in these places:

• /etc/asppp.cf configuration file

• /etc/inet/hosts file

• NIS+, NIS, or DNS databases, if applicable

When you edit the local machine's asppp.cf file, you must provide the host names and, in certain cases, the IP addresses for each endpoint machine to be on the link. For example, you must type either the IP addresses or host names for each endpoint as arguments in the ifconfig section in the configuration file:

ifconfig ipdptp0 plumb 192.99.44.01 192.99.44.02 up

See Chapter 9, Configuring PPP, for information regarding the format of /etc/asppp.cf.

Additionally, to enable communications, you must add the IP address and host name of the remote endpoints to the hosts database on the local end point by editing /etc/inet/hosts. This process is explained in "Configuring Network Clients".

Types of Addressing Schemes

You have a choice of several addressing schemes for PPP, depending on your configuration type. Before you edit the asppp.cf file and hosts database, you must decide on the appropriate addressing scheme for your configuration. These schemes include:

• Using the same IP addresses for the PPP endpoints as is assigned to their primary network interface in their local /etc/inet/hosts files

• Assigning a unique IP address for each PPP endpoint

• Assigning a new network number for the network created by the PPP link

Using the Same IP Address as the Primary Network Interface

This addressing scheme is appropriate for point-to-point links only. In this scheme, you specify the addresses of the primary network interface for each endpoint. (See Chapter 1, Overview of Network Administration, for more information about the primary network interface.) These endpoints might be:

• Two standalone machines communicating over the PPP link (if they have existing IP addresses)

• Two network endpoints communicating over the PPP link

• Remote host connecting to a network dial-in server through a point-to-point link

• Dial-in server connecting to remote hosts through a dynamically allocated point-to-point link

When you edit the /etc/inet/hosts file on a local endpoint, supply the IP address of its primary network interface and host name and the IP address of the peer host on the other end of the link.

Creating a Unique IP Address and Host Name

In this method, you assign a unique host name and IP address to the PPP network interface. (You might want to call the interface hostname-ppp.) Use this addressing scheme fo:

• Endpoint machines on a network used as a multipoint dial-in server

• Machines on a virtual network

• Remote host that uses a dedicated IP address for communicating with a dial-in server over a dynamically allocated PPP link. (Note that this is not a requirement for the dynamic link configuration.)

• Machine that is also configured as a router for a physical network, such as Ethernet or Token Ring

• Machine in a standalone-to-standalone configuration that does not have an existing IP address. (The PPP interface becomes the primary network interface.)

You must specify the unique address and host name for the PPP network interface in the asppp.cf configuration file.

To create the new host name and IP address, add it to the /etc/inet/hosts file on the endpoint machines, as described in "hosts Database".

Assigning a Network Number to the PPP Link

You create a new network number for the PPP configuration when it involves:

• Virtual networks of computers communicating through PPP multipoint links (required)

• A multipoint dial-in server and its remote hosts (required)

• The PPP link between two networks, particularly when one or both of the network endpoint machines are also routers for a physical network (optional)

(See Chapter 3, Planning Your Network, for information on network numbers.)

The PPP link becomes a virtual network, since it does not involve any physical network media. You need to type its network number in the networks database on all endpoint machines, along with the network numbers of the networks being linked.

Example 8-1 shows a sample /etc/inet/networks file for an internetwork with PPP:

Example 8-1 /etc/inet/networks File for an Internetwork With PPP

kalahari      192.9.253
negev         192.9.201
nubian-ppp    192.29.15

In the sample file, kalahari and negev are two local area networks, and nubian-ppp is the name of the PPP link.

Routing Considerations

The RIP routing protocol runs on Solaris TCP/IP networks by default. In most cases, you should leave RIP running on point-to-point links. However, if you are having performance problems with the link, you might want to disable RIP on the point-to-point link.

RIP is not started on multipoint links. Therefore, you must set up static routing for the multipoint link. Refer to "To Select Static Routing on a Host" for instructions.

Turning Off RIP

You can disable RIP on a point-to-point link through the file /etc/gateways. This file does not come with your operating system: you must create it with a text editor.

To turn off RIP, /etc/gateways must have the following entry:

norip ipdptpn

where ipdptpn represents the device name of the point-to-point PPP interface used.

For more information, refer to the in.routed(1M) man page.

PPP Hardware Requirements

The basic PPP configuration involves a computer, a modem, and RS-232 telephone lines. However, before you configure, you need to verify whether the hardware you selected can support PPP. This section describes the hardware requirements for PPP.

• Modem requirements - To run PPP, each endpoint machine must have a modem that supports at least 9600 bps or faster bidirectional connections. Such a modem implements the V.32 or V.32bis specification.

• Serial port selection (for dial-in servers only) - You can configure either serial port A or serial port B on most CPUs for PPP usage. Use the Solaris Serial Port Manager to initialize the ports on the dial-in server. System Administration Guide contains instructions for selecting the appropriate port. If you have additional serial cards installed, you can also use their serial ports for PPP connections.

• Disk space - You must have 300 Kbytes of free space in /usr to install PPP.

File Space Requirements

You need sufficient space in the following directories for the PPP software:

• /usr

• /usr/kernel/drv

• /usr/kernel/strmod

• /usr/sbin

PPP occupies approximately 243 Kbytes in /usr and 4 Kbytes in / (root).

Checklist for Configuring PPP

Use this checklist to prepare for configuring PPP. It lists the information you need to gather and the tasks you need to do before starting the configuration process.

1. Do you have 300 Kbytes of free space available in /usr? ___________

2. Do you have 4 Kbytes of free space available in / (root)? ___________

3. Do the modems for each endpoint support V.32 or V.32bis or higher? ___________

4. Have you used the Serial Port Manager on the dial-in server to designate the serial port for the modem? ___________

5. Have you ensured that Solaris PPP is installed on each endpoint machine? (If PPP hasn't been installed, you can use the pkgadd program or admintool software manager to install it. Refer to Solaris Advanced Installation Guide for instructions.) ___________

6. Have you ensured that there are no other versions of PPP running on each endpoint. (If there are, disable them, as explained in their documentation.) ___________

7. Have you determined which IP addresses to use for all computers involved in the PPP link? __________

8. List the host names and IP addresses of these machines here. ___________ ___________ ___________ ___________

9. Write the name and IP address of the dial-in server (if applicable). ___________

10. Write the name of the network interface that you need to use. ___________

Chapter 9 Configuring PPP

This chapter contains procedures and information for configuring PPP. The example used in the text is for the configuration with both types of PPP links-- remote hosts and their multipoint dial-in server. Chapter 11, Tailoring Your PPP Link, contains information for setting up other PPP configuration types.

• "Installing the PPP Software"

• "Sample PPP Configuration"

• "Editing UUCP Databases"

• "Modifying the /etc/passwd File"

• "Parts of Basic Configuration File"

• "Configuration File for Multipoint Dial-in Server"

• "Starting up and Stopping Your New PPP Link"

Overview of the Configuration Process

You have completed the preinstallation activities noted in Chapter 8, Preparing Your PPP Configuration. Now you can begin PPP configuration.

PPP requires that you:

1. Install the PPP software, if it isn't already installed.

2. Edit the /etc/inet/hosts files on all machines involved.

3. Edit the UUCP database files for all dial-out machines.

4. Edit the /etc/passwd and /etc/shadow files for the dial-in machine.

5. Edit the /etc/asppp.cf file on each machine on the link.

6. Start the link manager aspppd on each machine on a link.

7. Verify that PPP is running successfully.

Although you don't have to perform Tasks 1-4 in order, you must complete them before you can edit the PPP-configuration file.

The sections in this chapter explain the procedures for configuring PPP.

Installing the PPP Software

The PPP software is automatically included when you run the Solaris installation program and select the entire distribution. If you did not select the entire distribution, you need to install PPP as a separate package.

Verifying Installation

Before proceeding further, you must check that the Solaris version of PPP is installed on all machines to be involved in the PPP link. On each endpoint involved in the link, type:

# pkginfo | grep ppp

If PPP is installed, the following package names are displayed:

SUNWpppk       # Contains kernel modules
SUNWapppu      # Contains the link manager and login service
SUNWappp       # Contains configuration files

If PPP is not installed on an endpoint system, install it using either the pkgadd program or admintool software manager.

When using pkgadd to install PPP, you must install the packages in the order listed in the preceding screen box.

Refer to System Administration Guide for more information about pkgadd and admintool software manager.

Sample PPP Configuration

This and the following sections show you how to edit the appropriate files to support the most common PPP configuration: remote hosts and their dial-in server. Figure 9-1 illustrates the configuration used as the example for this chapter. It depicts three remote machines (nomada, nomadb, nomadc) and their dial-in server nubian, which compose the network 192.41.43. This is a separate network from the local area network 192.41.40, to which dial-in server nubian is directly attached. Network 192.41.40 runs NIS as its name service.

The IP number shown for each remote host is the address of its PPP network interface. However, the dial-in server has a specially created IP address for the PPP interface, 192.41.43.10, in addition to the IP address for its primary network interface, 192.41.40.45.

Figure 9-1 Sample Network of Remote Hosts and Multipoint Dial-in Server

Editing the /etc/inet/hosts File

After ensuring that PPP is installed on every machine involved in your configuration, your next task is to edit the /etc/inet/hosts files on each machine. You must add host information to the hosts database for every machine on the other end of the PPP link that the local machine needs to communicate with.

You must update /etc/inet/hosts regardless of the name service in use on the physical network. This is necessary because PPP starts before the name service daemons during the booting process.

How to Configure the Remote Machine's hosts Database

1. Become superuser and prepare to edit the /etc/inet/hosts file.

2. Add an entry with the IP address and host name of the PPP network interface for the dial-in server on the other end of the link.

   In Figure 9-1, nomada must have in its /etc/inet/hosts file an entry with the IP address for dial-in server nubian's PPP network interface. This is true also for the /etc/inet/hosts files for nomadb and nomadc.

3. Add entries with the IP addresses of any machines on the dial-in server`s physical network that the remote host can remotely log in to.

   The /etc/inet/hosts file on nomadc would look like:

   # Internet host table # 127.0.0.1 localhost loghost 192.41.43.3 nomadc 192.41.43.10 nubian-ppp 192.41.40.20 nismaster

4. Update the databases on the name server (if the network has one) with the host names and IP addresses of the remote hosts.

Multipoint Dial-in Server hosts Database

Multipoint dial-in servers must have a unique IP address for the PPP interface, besides the local IP address for the primary network interface. When configuring the hosts database for the dial-in server, you need to perform the following procedure.

How to Configure the Dial-In Server's hosts Database

1. Add an entry with the IP address for the PPP interface to the /etc/inet/hosts file for the dial-in server.

   For example, the /etc/hosts file on dial-in server nubian in Figure 9-1 would have the following entries.

   # Internet host table # 127.0.0.1 localhost loghost 192.41.43.10 nubian-ppp 192.41.40.45 nubian

2. For configurations where the server's physical network does not use a name service:

   1. Add entries to the server's /etc/inet/hosts files for each remote host served.

   2. Add entries for the remote hosts to the /etc/inet/hosts files of every machine on the physical network permitted to communicate with the remote machines.

3. Add a new network number to the dial-in server's /etc/inet/networks file for the network that consists of the server and its remote hosts.

   Refer to "Assigning a Network Number to the PPP Link" for more information.

Editing UUCP Databases

Before a machine can dial out over the PPP link, you must edit these files in its UUCP database:

• /etc/uucp/Devices

• /etc/uucp/Dialers

• /etc/uucp/Systems

You must edit these files for remote hosts serving as PPP dial-out machines. Additionally, you must edit these files on the dial-in server if it is to dial out to the remote hosts (a requirement for multipoint dial-in servers). Chapter 12, UUCP Databases and Programs, describes these files in detail.

Updating /etc/uucp/Devices for PPP

The /etc/uucp/Devices file must contain entries for every communications device that a particular host uses or must know about. For example, if a machine uses a US Robotics V.32bis modem as part of the PPP link, you should ensure that /etc/uucp/Devices has an entry similar to the following:

# Use these if you have a USrobotics V.32bis modem on Port B.
ACUEC   cua/b - 9600 usrv32bis-ec
ACUEC   cua/b - 19200 usrv32bis-ec
ACUEC   cua/b - 38400 usrv32bis-ec

Be sure that the Devices file on each PPP endpoint machine has an entry describing its modem. For more information about /etc/uucp/Devices, refer to "/etc/uucp/Devices File".

Updating /etc/uucp/Dialers for PPP

The /etc/uucp/Dialers file must have an entry describing the conversation with the modem attached to your PPP endpoint machine. Here is a sample entry for a US Robotics V.32bis modem that is part of a PPP link:

usrv32bis-ec =,-,  "" \dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2\r\c OK\r 
\EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtscts

The first parameter in the entry, usrv32bis, corresponds to the last parameter in the /etc/uucp/Devices file, linking them together. The remainder of the entry describes the characters that the modem sends, those that it expects to receive, and so on. Table 12-6 defines the control codes used in the Dialers file.

Be sure that an entry is in the Dialers file for the modem attached to each dial-out endpoint on your link. If you are unsure of the correct conversation for a particular modem, refer to the System Administration Guide and the operating manual for the modem.

Updating /etc/uucp/Systems for PPP

The /etc/uucp/Systems file contains entries for every machine to which the local host can dial out. Information in an entry might include the remote host's phone number, the line speed, and so on. Here is an example that host nomadb in Figure 9-1 might have for its dial-in server:.

nubian-ppp  Any ACUEC 38400 5551212 "" P_ZERO "" 
\r\n\c login:-\r\n\c-login:-\r\n\c-login:-
EOT-login: bnomad password: Secret-Password

The first field gives the server's host name, nubian-ppp, a value used by the asppp.cf file keyword peer_system_name. ACUEC and 38400 refer to the device and speed, and are used to select an entry from the /etc/uucp/Devices file. The remaining information includes the phone number of the machine that nomadb wants to dial in to, the login name that nomadb is using to log in, and so on. "/etc/uucp/Systems File" fully defines the parameters you need to supply to the Systems file.

On each remote host in your configuration, you must add an entry for its dial-in server. You can have additional entries in the /etc/uucp/Systems file for other machines to which the host can dial out for UUCP communications and for other PPP dial-in servers.

If the dial-in server also directly dials out to remote hosts, you must add entries to its Systems file describing each of these remote hosts.

Modifying the /etc/passwd File

To configure a dial-in server, you must also edit the /etc/passwd and /etc/shadow files.

You must add entries to the /etc/passwd file on the dial-in server for each user on a remote host authorized to log in to the server. When a remote host calls the dial-in server, it reads its UUCP databases and passes the server a user name or user ID for the host initiating the call. The server then verifies this user information in its /etc/passwd file.

If the user's password is authenticated, the server then logs the user in to a special shell for PPP hosts, /usr/sbin/aspppls. The server gets this information from the login shell entry in its /etc/passwd file. Using the example in Figure 9-1, dial-in server nubian might have the following entries in its /etc/passwd file:

bin:x:2:2::/bin:
sys:x:3:3::/bin:
uucp:x:5:5::/usr/lib/uucp:
nuucp:x:9:9::/var/spool/uucppublic:/usr/lib/uucp/uucico
news:x:6:6::/var/spool/news:/bin/csh
sundiag:x:0:1:System Diagnostic:/usr/diag/sundiag:/usr/diag/sundiag/sundiag
lily:x:20:99:Dial-in Operator:/home/nubian/lily:/bin/csh
nomada:x:21:99:R. Burton:/:/usr/sbin/aspppls
nomadb:x:22:99:T. Sherpa:/:/usr/sbin/aspppls
nomadc:x:23:99:S. Scarlett:/:/usr/sbin/aspppls

Refer to System Administration Guide for information about the /etc/passwd file.

In addition to the information in the /etc/passwd file, you update the /etc/shadow file with the passwords for the login names used by each endpoint machine permitted to dial in to the server. For more information, refer to System Administration Guide.

Editing the /etc/asppp.cf Configuration File

The /etc/asppp.cf configuration file provides the PPP link manager on one endpoint machine with information about the machine on the other end of the link--or the machines on the other end of a multipoint (or dynamic point-to-point) link. When the machine boots, the link manager uses this information to establish and maintain communication with a remote endpoint.

Parts of Basic Configuration File

The basic asppp.cf configuration file must contain at least two main sections: an ifconfig line and at least one path section. It can also contain a defaults section, which you use when you want to set the default values for an endpoint. (Refer to Chapter 11, Tailoring Your PPP Link, for a description of keywords used in the defaults section.)

Example 9-1 shows a basic configuration file such as you would create for a remote host to establish a point-to-point link with a dial-in server.

Example 9-1 Basic Configuration File

ifconfig ipdptp0 plumb nomada nubian-ppp up
   path
      interface ipdptp0
      peer_system_name nubian-ppp      # The name in the /etc/uucp/Systems file
      inactivity_timeout 300           # Allow five minutes before timing out

ifconfig Section of the asppp.cf File

The asppp.cf file must contain an ifconfig section with this syntax:

ifconfig interface-number plumb local-machine remote-machine up

Here is a description of the fields:

• ifconfig - Tells the link manager to run the ifconfig command and begin configuring the PPP interface.

• interface-number - Identifies the PPP interface ipdptpn for a point-to-point link or ipdn for a multipoint link. (Replace the n with the number of the interface.)

• plumb - Option of ifconfig that enables IP to recognize the interface.

• local-machine - Gives the name of the local endpoint, which can be the local host name or IP address.

• remote-machine - Gives the name of the remote endpoint, which can be the remote host name or IP address.

• up - Option of ifconfig that marks the interface just described as "up".

The link manager first runs the ifconfig command on the local machine to configure the ipdptp0 point-to-point interface. The zero in ipdptp0 gives the device number of the interface. The plumb option performs various activities necessary for IP to recognize the ipdptp0 interface. nomada is the name of the local host. nubian-ppp is the name of the dial-in server to which nomada connects through the point-to-point link. The ifconfig option up marks the ipdptp0 interface as up.

For more information about ifconfig, see Chapter 10, Troubleshooting PPP, and the ifconfig(1M) man page.

path Section of the asppp.cf File

The path section of the configuration file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. At a minimum the path section should contain the following lines:

path
   interface interface-number
   peer_system_name endpoint-name

interface Keyword

This keyword defines the PPP interface (either ipdptpn or ipdn). In Example 9-1, the following information appears in the path section:

interface ipdptp0	  
peer_system_name nubian-ppp

The interface keyword identifies ipdptp0 as the point-to-point interface that local endpoint nomada uses to communicate with the remote endpoint in the manner described in this path section. It associates the peer_system_name with the interface.

peer_system_name Keyword

On a dial-out machine such as a remote host, the peer_system_name keyword takes the host name of the remote endpoint as its argument. This is the name of the remote endpoint given in /etc/uucp/Systems. The name need not be the same as the host name on the corresponding ifconfig line.

The argument to the peer_system_name keyword for a dial-in server has a different value. See "Configuration File for Multipoint Dial-in Server" for details.

In Example 9-1, peer_system_name identifies dial-in server nubian-ppp as the remote endpoint at the other end of this link. When the link manager reads the asppp.cf file, it then looks for the entry for nubian-ppp in the /etc/uucp/Systems file. (Recall that the Systems file contains information about how to set up communications with the remote endpoint, including that machine's telephone number. Refer to "Updating /etc/uucp/Systems for PPP".)

inactivity_timeout Keyword

The inactivity_timeout keyword is optional. It tells the link manager that the link can remain inactive for the interval designated. When that interval is passed, the link manager knows to automatically disconnect the link. The default interval is two minutes; you do not have to use inactivity_timeout unless you require a different inactivity interval.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. Chapter 11, Tailoring Your PPP Link, has complete information about these keywords.

Configuration File for Multipoint Dial-in Server

The asppp.cf configuration file for a multipoint dial-in server contains the same basic sections as that for a point-to-point link: an ifconfig section, at least one path section, and, if desired, a defaults section.

Example 9-2 shows a configuration file for the dial-in server nubian introduced in Figure 9-1.

Example 9-2 Configuration File for a Multipoint Dial-in Server

ifconfig ipd0 plumb nubian-ppp up

path
   interface ipd0
   peer_system_name tamerlane  # The user name this remote
                               # machine logs in with when it
                               # dials this server
   	peer_ip_address nomada
                               # nomada is a remote machine that
                               # dials in to this server

# nomadb is another remote machine that dials in to nubian

path
   interface ipd0
   peer_system_name lawrence
   peer_ip_address nomadb

# nomadc is another remote machine that dials in to nubian

path
   interface ipd0
   peer_system_name azziz
   peer_ip_address nomadc

ifconfig Section for Multipoint Dial-in Server

The ifconfig section for a multipoint dial-in server has a slightly different syntax than that for a point-to-point link. This syntax is:

ifconfig ipdn plumb server-name up

The major difference is that no destination end points are listed as arguments to ifconfig. Instead, the link manager picks up this information from the path section of the asppp.cf file.

In Example 9-2, the link manager first runs the ifconfig command on the dial-in server to configure multipoint interface ipd0. The zero in ipd0 gives the device number of the interface. The option plumb performs various activities necessary for IP to recognize the ipd0 interface. The ifconfig option up marks interface ipd0 as up.

You may have to supply a netmask + parameter on the ifconfig line if you use subnetting.

path Section for Multipoint Dial-in Server

The path section of the asppp.cf file tells the link manager the name of the remote endpoint and the name of the interface linking the endpoint machines. However, on a multipoint dial-in server, you can include more than one path section. Additionally, some of the arguments to the keywords are used differently with multipoint links.

path
    interface interface-number
    peer_system_name endpoint-username
    peer_ip_address endpoint-hostname

You need to define a path section for each nomadic endpoint with which the dial-in server can establish connections.

interface Keyword

For a multipoint dial-in server, the interface keyword defines the PPP interface ipdn. You must specify the same PPP interface in the path section for every endpoint that communicates with the server through this interface.

peer_system_name Keyword

The peer_system_name keyword takes a slightly different argument for a dial-in machine than a dial-out machine. For a dial-in server, this argument is the login name used by the remote host when it tries to establish communications with the server. This user name must already be present in the server's /etc/passwd file. When the login service reads this name, it verifies the user name in the /etc/passwd and /etc/shadow files enabling communications.

In this excerpt from Example 9-2:

path
    interface ipd0
    peer_system_name scarlett
    peer_ip_address nomadc

the argument to peer_system_name is scarlett, indicating that when nomadc logs in to nubian-ppp, it uses the login name scarlett.

peer_ip_address Keyword

The peer_ip_address keyword is required for multipoint links. It takes the host name or IP address of the remote endpoint as its argument. The example above uses the host name nomads as the argument to keyword peer_ip_address.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate. Refer to Chapter 11, Tailoring Your PPP Link, for a complete list of keywords.

Editing the Configuration File

When editing asppp.cf:

• Separate keywords in the configuration file by white space (blanks, tabs, and new lines).

• Use a # sign before all character strings meant as comments. All characters placed between a # sign and the next new line are considered comments and ignored.

There are no other format requirements for the placement of the keywords in the file.

How to Edit the asppp.cf Configuration File

1. Become superuser on one endpoint machine and change to the /etc directory.

2. Edit the generic asppp.cf file to add the information defining the PPP link for this machine.

3. Save the file, making sure the permissions are set to 600.

4. Change to the /etc directories on the remaining endpoints and repeat Steps 2 and 3.

Adding PPP Security

After you have completed installing PPP on every machine involved in your configuration, you can add either PAP or CHAP levels of security for the PPP link by modifying the asppp.cf file. Refer to "Editing asppp.cf for PAP/CHAP Security".

Starting up and Stopping Your New PPP Link

You can start PPP either automatically, at boot time, or manually from the command line.

How to Manually Start PPP

You can start PPP manually, although this is not normally required.

1. Become superuser and type:

   # /etc/init.d/asppp start

How to Verify That PPP Is Running

1. Run the ps command:

   # ps -e | grep asppp

   The resulting output from grep should list the aspppd daemon, indicating that PPP is running.

2. If you do get results, verify that you can reach the remote PPP link by typing:

   # ping remote-host 300

   This version of ping sets a timeout value of 5 minutes (300 seconds). You should receive output similar to remote-host is alive. If you receive a different notice, such as remote-host unreachable, route configuration has failed.

3. Check for errors in the configuration process by examining the log file.

   # tail /var/adm/log/asppp.log

   The asppp.log contains error messages if any errors were encountered during configuration.

See Chapter 10, Troubleshooting PPP, for information on troubleshooting and problem solving.

How to Stop PPP

1. To stop PPP operations on your network, type:

   # /etc/init.d/asppp stop

Chapter 10 Troubleshooting PPP

This chapter is organized as a series of checks to make after you have configured PPP on your network. Thereafter, whenever you have trouble communicating over the PPP link, you can use PPP diagnostics to help troubleshoot problems.

• "Checking Hardware"

• "Checking Interface Status"

• "Checking Connectivity"

• "Checking Interface Activity"

• "Checking the Local Routing Tables"

• "Checking Permissions"

• "Checking Packet Flow"

• "Using PPP Diagnostics for Troubleshooting"

In summary, you should do these checks in the following order:

1. Hardware

2. Interface status

3. Connectivity

4. Network interface activity

5. Local routing tables

6. Permissions

7. Packet flow

If PPP passes all the tests, you should be able to use TCP and UDP services such as rlogin, telnet, and ftp over the link. If the link still fails, turn on PPP diagnostics for assistance in troubleshooting.

The next sections describe these checks in detail.

Checking Hardware

Make sure that all modem and power cables are tightly seated. If you are having problems with PPP, always check the modems, cables, serial card, and phone lines first.

Checking Interface Status

After PPP is started, you can use ifconfig to monitor the current state of the line, using only the PPP interface name as an argument. Example 10-1 shows sample output from ifconfig for PPP links that are running.

Example 10-1 ifconfig Output for Point-to-Point Link

nomadb# ifconfig ipdptp0

ipdptp0: flags=28d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED> mtu 1500
        inet 129.144.111.26 --> 129.144.116.157 netmask ffff0000
        ether 0:0:0:0:0:0 

You receive output similar to that in Example 10-1 for both standard and dynamic point-to-point links.

Example 10-2 ifconfig Output for Multipoint Link

nubian# ifconfig ipd0

ipd0: flags=c1<UP,RUNNING,NOARP> mtu 1500
        inet 129.144.201.191 netmask ffffff00
        ether 0:0:0:0:0:0

If ifconfig does not display UP and RUNNING, you did not configure PPP correctly. For more information on ifconfig, see "ifconfig Command" and the ifconfig(1M) man page.

Checking Connectivity

Use the ping command to verify that the connection is up or can be established. For example, consider the following simple round-trip test:

# ping elvis

where elvis is the name of the PPP interface on the remote host. If the resulting display is

elvis is alive

then packets can be sent to and received from elvis. If not, a routing problem exists at some point between the local and remote hosts. For more information on ping, refer to "ping Command" and the ping(1M) man page.

Checking Interface Activity

Use the netstat command as follow, to check that packets are being sent and received correctly:

# netstat -i

Refer to "netstat Command" and the netstat(1M) man page.

Checking the Local Routing Tables

Use the netstat command to display the local routing tables:

# netstat -r

The following is sample output:

Routing tables
Destination   Gateway    Flags  Refcnt  Use    Interface
sahara        deserted   UGH    0       0       ie1
karakum       labia      UGH    0       0       ie1
frodo         bilbo      UGH    1       12897   ipdptp0
route7        route7     UGH    0       0       ie0
eastgate      route71    UGH    0       158     ie0
backbone      pitstopbb  U      1       16087   ie1
dresdenpc     route1     UG     0       0       ie1
loopback      localhost  U      2       113436  lo0
swan-bb       pitstop    U      406     146044  ie0
dallas2       route7     UG     0       0       ie0
trainingpc    route62    UG     0       0       ie1

Make sure there is a routing table entry for each possible destination network. In particular, PPP devices, listed under Interface, should be matched with the appropriate host names listed under Gateway. The Gateway entry should, in turn, be matched with the correct entry under Destination.

Otherwise, if you are using static routing, add the appropriate static routes. If you are using dynamic routing with in.routed:

1. Verify that in.routed is running by typing:

   # ps -e | grep route

   If the routing tables still don't look correct, become superuser and continue with the next steps.

2. Kill in.routed by typing the process ID you got from ps -e as the argument to kill. For example, if 1384 was the process ID, you would type:

   # kill 1384

3. Flush the routing tables as follows:

   # /usr/sbin/route -f

4. Restart in.routed:

   # /usr/sbin/in.routed

Checking Permissions

If you attempt to use rsh and receive the message Permission denied, the remote system's /etc/hosts.equiv or /.rhosts file does not contain the sending system's host name or does not contain the line +.

Checking Packet Flow

Check the packet flow next. Use the snoop command to observe packets from the network and observe their contents. Example 10-3 shows some sample output from snoop.

Example 10-3 Sample Output from snoop

# snoop -d ipdptp0
Using device ipdptp0 (promiscuous mode)
corey -> pacifica7    RLOGIN C port=1019
       hugo -> ponc3         RPC R XID=22456455 Success
       ponc3 -> hugo         NFS C WRITE FH=1B29 at 32768

    commlab3 -> commlab4     TELNET R port=34148
    commlab4 -> commlab3     IP  D=129.144.88.3 S=129.144.88.4 LEN=46, ID=41925
    commlab3 -> commlab4     TELNET R port=34148
    commlab4 -> commlab3     ICMP Echo request
    commlab3 -> commlab4     ICMP Echo reply
    commlab4 -> commlab3     FTP C port=34149
    commlab4 -> commlab3     FTP C port=34149
    commlab3 -> commlab4     FTP R port=34149
    commlab4 -> commlab3     FTP C port=34149

The ipdptp0 device name mentioned in the first line of the output Using device ipdptp0 indicates a point-to-point connection.

You need to have the link up and some traffic generated in order to use snoop to check the line status.

snoop captures packets from the network and displays their contents. It uses both the network packet filter and streams buffer modules to provide efficient capture of packets from the network. Captured packets can be displayed as they are received or saved to a file for later viewing.

snoop can display packets in a single-line summary form or in verbose multiline forms. In summary form, only the data pertaining to the highest-level protocol is displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if either of the verbose options is chosen.

For more information about the snoop command, refer to the snoop(1M) man page.

Using PPP Diagnostics for Troubleshooting

If you have problems with a link after successfully establishing modem connections, you can use PPP-level diagnostics for troubleshooting. PPP-level diagnostics report detailed information about the activities of a link to help you determine where it is failing.

To obtain diagnostic information, add the line debug_level 8 to the path section of the asppp.cf file. (If you are very knowledgeable about data communications, you might want to use debug level 9, which provides very detailed information.) Here is a sample configuration file that invokes PPP diagnostics.

ifconfig ipdptp0 plumb nomada nubian-ppp up
path
   interface ipdptp0
   peer_system_name nubian-ppp   #The name in the /etc/uucp/Systems file
   inactivity_timeout 300        #Allow five minutes before timing out
   debug_level 8                 #Start up PPP diagnostics for this link

For complete details about the aspppd.conf file, refer to "Editing the /etc/asppp.cf Configuration File".

How to Set Diagnostics for Your Machine

Set diagnostics on the host you want to monitor as follows:

1. Become superuser and change to the /etc directory.

2. Edit the current asppp.cf file and add the following to the path section: debug_level 8.

3. Save the file, making sure the permissions are set to 600.

4. Kill the current aspppd daemon and restart it.

   #kill PID #aspppd

   where PID is the process ID for aspppd.

   PPP reports diagnostic information in /var/adm/log/asppp.log.

Analyzing Diagnostic Output

When a PPP link runs correctly, the asppp.log file includes diagnostic information in addition to its normal output. This section explains what the diagnostic messages mean. If your output is different, refer to RFC 1331.

Host and Modem Setup

This section contains messages that occur as the local host sends configuration information to the modem, and then as the modem tries to dial the remote host. These initial activities are actually handled by the UUCP daemon. You might think of them as the UUCP portion of asynchronous PPP communications. (Refer to Chapter 12, UUCP Databases and Programs, for complete details on UUCP.)

The two messages below should always appear at the beginning of the session. They indicate that the aspppd daemon has started successfully.

11:53:33 Link manager (1057) started 04/14/94
11:53:33 parse_config_file: Successful configuration

The next line indicates that a packet was routed to the ipdptp0 interface on the local host. It helps you to determine if a dial-out is occurring correctly. For example, if you tried to ping the remote machine and this message isn't in asppp.log, the packet was lost, probably due to a routing problem.

Next, UUCP looks for an entry that matches Ppac7 in a chat script in the /etc/uucp/Systems file. It then reports that it found an entry that had a device type ACUTEC. (For more information on the Systems file, refer to "/etc/uucp/Systems File".)

11:53:46 process_ipd_msg: ipdptp0 needs connection
conn(Ppac7)
Trying entry from '/etc/uucp/Systems' - device type ACUTEC.

UUCP then finds the dialing information for an ACUTEC dialer in the /etc/uucp/Devices file. When it finds the information, it opens the appropriate serial port on the local host and sets it with a speed of 9600. (For more information on /etc/uucp/Devices, see "/etc/uucp/Devices File".)

Device Type ACUTEC wanted
Trying device entry 'cua/a' from '/etc/uucp/Devices'.
processdev: calling setdevcfg(ppp, ACUTEC)
fd_mklock: ok
fixline(8, 9600)
gdial(tb9600-ec) calle

UUCP looks for the entry tb9600 in the /etc/uucp/Dialers file and then sends out these messages.

Trying caller script 'tb9600-ec' from '/etc/uucp/Dialers'
expect: ("")

The host waits a couple of seconds and then sets the registers on the modem. The information shown in the log below is modem-specific. It comes from the /etc/uucp/Dialers file.

got it
sendthem (DELAY)
APAUSE
APAUSE
APAUSE
T&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M<NO CR>)

The next lines are the dialog between the modem and the host machine. expect (OK^M) means that the host expects the modem to send an "okay." The words got it at the end of the second line indicate that the host got the "okay" message from the modem.

expect: (OK^M)
AAAT&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M^M^JOK^Mgot it

Next, the host sends the string below to the modem, which does the actual dialing. The phone number in the second line is retrieved from the entry for the remote host in the /etc/uucp/Systems file.

sendthem (ECHO CHECK ON
A^JATTDDTT99003300887744^M^M<NO CR>)

The line beginning with expect indicates that the local host expects to get a response from the modem at a speed of 9600 bps. The next line indicates that the modem responded.

expect: (CONNECT 9600)
^M^JCONNECT 9600got it

This line indicates that hardware flow control has started on the link. The host obtains flow control information from the /etc/uucp/Dialers file.

STTY crtscts

In the next series of messages, the local host waits for the remote host to send it a standard UNIX login prompt.

getty ret 8
expect: ("")
got it
sandiest (^J^M)
expect: (login:)

The next messages indicate that the local host has received the login prompt from the remote. It then retrieves the appropriate login sequence from the chat script in the /etc/uucp/Systems entry for the remote host. This sequence is Ppong^M, which is required for login by the remote host.

^M^J^M^Jlogin:got it
sendthem (Ppong^M)

In these messages, the local host waits for the ssword prompt from the remote host. Upon receipt of the prompt, the local host sends the password retrieved from the chat script in the /etc/uucp/Systems entry for the remote host.

expect: (ssword:)
login: Ppong^M^JPassword:got it

The following messages indicate that dialing and modem connection completed successfully.

sendthem (ppptest1^M)
call cleanup(0)^M

Communications Between the Local and Remote Hosts

At this point, PPP communications start, as the link between local and remote hosts is now established.

The first lines in this part of the session constitute a configuration request (Config-Req). This is the first PPP packet sent to the remote host. The configuration request is one example of a Link Control Protocol (LCP) packet. It requests that configuration be set up and then sets up the PPP link between endpoint machines. Example 10-4 shows a sample configuration request.

Example 10-4 Configuration Request

11:54:20 004298 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req 
ID=4c LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP
AddrCCOMP

Here is a description of the configuration request shown in Example 10-4.

• 11:54:20 - Time stamp field, indicating the time when the packet was sent

• 004298 - Number of the packet

• ipdptp0 - Network interface used

• SEND PPP ASYNC - Indicates that the modem is sending asynchronous PPP

• 29 Octets - Amount of data the host sent

• LCP - Packet type to send

• ID=4c - Identifier associated with the packet; it is actually part of the packet

• LEN=24 - Length of the LCP part of the packet

The remaining items are a list of options to be negotiated between hosts.

• MRU=1500 - Maximum Receive Unit (MRU), the largest packet size the calling host can receive from the remote host

• ACCM=00000000 - Asynchronous Character Map (ACCM), the mask sent to the remote host that tells what control characters to escape on transmission

• MAG#=69f4f5b2 - Magic number field; used for loopback detection mechanism

• ProtFCOMP AddrCCOMP - Asks for the remote host to compress certain parts of the frame header (protocol field, address field).

The next lines are reporting invalid PPP packets. They come from the remote host, which is sending out UNIX text. This does not indicate a problem with PPP.

11:54:20 004299 ipdptp0 RECEIVE {Invalid ppp packet}PPP ASYNC 7
Octets [BAD FCS] {Unrecognized protocol:    1}

11:54:20 004299 ipdptp0 RECEIVE PPP ASYNC 73 Octets [BAD FCS]
{Unrecognized protocol:    880a}

In these packets, the local host receives the remote host's request for configuration, then sends out another configuration request. The packets are identical except for their ID fields. The ID field helps to distinguish between the two packets.

11:54:21 004301 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config-
Req  ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

11:54:21 004302 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req 
ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP
AddrCCOMP

In this packet, the local host acknowledges the remote request by sending it a configuration acknowledgment (Config-ACK).

11:54:21 004303 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK 
ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

The local host receives a configuration request (Config-Req) from the remote host.

11:54:21 004304 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config-
Req  ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

In these packets, the local host acknowledges the second packet sent by the remote host and receives the remote host's acknowledgment.

11:54:21 004305 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK 
ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP
AddrCCOMP

11:54:21 004306 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config-
ACK  ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP
AddrCCOMP

Here the local host negotiates parameters about IP transmission. LEN=16 gives the packet size. VJCOMP indicates Van Jacobsen header compression. IPADDR is followed by the calling host's IP address.

11:54:21 004307 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config-
Req  ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70

This packet indicates that the local host has received IP configuration from the remote host, including its IP address.

11:54:22 004308 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP
Config-Req  ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK
IPADDR=192.9.68.71

The local host sends this ACK to the remote host and receives an ACK from the remote host.

11:54:22 004309 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config-
ACK  ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71

11:54:22 004310 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP
Config-ACK  ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK
IPADDR=192.9.68.70

The first message below indicates that IP has started on the link. The next message indicates that the local host is sending IP traffic over the link.

11:54:22 start_ip: IP up on interface ipdptp0, timeout set for
120 seconds

11:54:24 004311 ipdptp0 SEND PPP ASYNC 89 Octets IP_PROTO

In the first message below the local host receives IP traffic from the remote host. The subsequent messages indicate that the interface was disconnected because of an idle time-out.

11:54:25 004312 ipdptp0 RECEIVE PPP ASYNC 89 Octets IP_PROTO
11:56:25 process_ipd_msg: interface ipdptp0 has disconnected
11:56:25 disconnect: disconnected connection from  ipdptp0

The next messages begin the termination sequence. The first message indicates that the remote host has sent a packet to terminate the IP layer. The second is the local host's acknowledgment of the request to terminate.

11:56:25 004313 ipdptp0 RECEIVE PPP ASYNC 9 Octets IP_NCP Term-
REQ  ID=38 LEN=4

11:56:25 004314 ipdptp0 SEND PPP ASYNC 9 Octets IP_NCP Term-ACK 
ID=38 LEN=4

The local host receives a request to terminate the LCP layer. The second message is an acknowledgment of the request, causing a graceful shutdown.

11:56:25 004315 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ 
ID=39 LEN=4

11:56:25 004316 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK 
ID=39 LEN=4

This message indicates that the link has closed.

11:56:29 004317 ipdptp0 PPP DIAG CLOSE

Chapter 11 Tailoring Your PPP Link

This chapter contains information you need to configure PPP links less commonly used than the basic links described in Chapter 9, Configuring PPP. The text includes instructions for configuring two types of PPP links: the dial-in server with dynamic point-to-point links and the virtual network, which uses multipoint links. The chapter concludes with tables listing all available keywords for the asppp.cf configuration file.

• "Addressing Issues for Dynamically Allocated Links"

• "Editing asppp.cf for Dynamic Link"

• "Addressing Issues for Virtual Networks"

• "asppp.cf Configuration File for a Virtual Network"

• "Editing asppp.cf for PAP/CHAP Security"

• "Configuration Keywords"

Configuring Dynamically Allocated PPP Links

A dial-in server with a dynamic point-to-point link gives your site all the advantages of point-to-point communications. Chapter 7, Understanding PPP, introduces this configuration type. It consists of remote hosts communicating with at least one dial-in server that dynamically allocates point-to-point links on an as-needed basis. The sample configuration shown in Figure 11-1 is used throughout this section.

Figure 11-1 Network of Remote Hosts and Dynamic Link Dial-in Servers

Each remote host communicates with the dial-in server using a standard point-to-point link. However, unlike the multipoint dial-in server in Figure 9-1, dial-in server mojave connects to a calling host over a dynamic point-to-point link. The server allocates an available link whenever a remote host attempts to establish a connection.

The idea behind a dynamic link is that the server provides the client with an IP address each time a connection is established. When the connection is established, the server allocates an available IP interface to the client. The remote IP address of the interface then becomes the client's IP address for the duration of the connection. When the connection is terminated, the IP interface is returned to the pool of available interfaces, ready to be used for another connection.

You use the same generic procedures for configuring dynamic links as you do for the remote host-to-multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the dynamic point-to-point link has its own set of issues and requires slightly different modifications to the files involved in configuration.

Addressing Issues for Dynamically Allocated Links

You must add host information to the /etc/inet/hosts file for each machine that use the dynamically allocated PPP link. The IP addresses for the PPP endpoints should follow these conventions:

• For the dial-in server, you must use the IP address of the server's primary network interface (for example le0 or smc0) as the address of the dynamic link.

• For a dynamic link, you don't need to assign an IP address to each remote host (as you would for a static link), but you do need to assign a remote IP address to each point-to-point IP interface on the server. The number of IP interfaces you can use is equal to the number of modems your server is connected to. For example, if you have three modems, you need three point-to-point IP interfaces and three IP addresses

• You must include a dummy IP address for the ifconfig command to work properly on the client. This address acts as a placeholder for the local IP address assigned to the client IP interface when PPP is started.

There are no restrictions on the remote IP addresses that can be assigned to the IP interfaces, but, for clarity, it is probably best to include only IP addresses belonging to the same subnet.

Updating the hosts Database for Dynamic Links

You must update the hosts database on all machines involved in the dynamic-link configuration.

How to Update a Remote Host

When configuring the hosts databases on the remote machines, do the following:

1. Add to the /etc/inet/hosts file the IP address and host name of the primary network interface for each dial-in server on the other end of the link.

   For example, in Figure 11-1, the /etc/inet/hosts file for nomada, nomadb, and nomadc should each include the IP address of the primary network interface of the dial-in server mojave.

2. Add the dummy IP address.

   This IP address is used only when PPP is started.

   The /etc/inet/hosts file on nomadc might look like:

   # Internet host table # 127.0.0.1 localhost loghost 192.41.40.55 mojave 1.2.3.4 dummy

3. Add to the /etc/inet/hosts file the IP addresses of all machines on the dial-in server`s physical network that the remote host can remotely log in to.

4. Update the databases on any name server on the physical network with the host names and IP addresses of the remote hosts.

How to Update the Dial-in Server

You do not have to add any PPP-specific address to the hosts database for the dial-in server. The dynamically allocated link must use the server's primary network interface. Therefore, when configuring the hosts database for the dial-in server, do the following:

1. Add entries to the server's /etc/inet/hosts files for each remote host served.

2. Add to the /etc/inet/hosts files of every machine on the physical network entries for any remote hosts they are permitted to communicate with.

Considerations for Other Files

The next steps in the configuration process involve editing the /etc/passwd file and the /etc/shadow file. Edit these files for the dynamic-link configurations just as you would for the remote host-to-multipoint dial-in server configuration. Refer to "Modifying the /etc/passwd File" for information regarding the /etc/passwd and /etc/shadow files.

Editing asppp.cf for Dynamic Link

The asppp.cf configuration file for a dynamic-link configuration must contain information about remote hosts and the interfaces to use for the PPP link. After the dial-in server boots, its link manager uses this information to establish communications whenever the server is called by a remote endpoint.

Remote Host with Dynamic Link

The asppp.cf configuration file for a remote host is the same as the one described in "Parts of Basic Configuration File", except for the addition of the parameter negotiate_address:

ifconfig ipdptp0 plumb dummy mojave up
path
    interface ipdptp0
    peer_system_name mojave-ppp
    connectivity_timeout 300
    negotiate_address on

The negotiate_address parameter indicates whether or not local IP address assignment is obtained through negotiation and assigned dynamically. If set to on, the IP address supplied by the server is used as the client's local address for the duration of the connection.

Dial-in Server With Dynamic Link

When the dial-in server receives an incoming packet, the link manager reads the path sections of its configuration file to identify the remote endpoint and determine the interface to use. The configuration file shown in Example 11-1 does not contain an interface keyword. Instead, the link manager uses interface information established in the defaults section.

The asppp.cf configuration file for a dial-in server with dynamically allocated links might resemble Example 11-1:

Example 11-1 Configuration File for Server With Dynamically Allocated Link

ifconfig ipdptp0 plumb mojave clienta down
ifconfig ipdptp1 plumb mojave clientb down
ifconfig ipdptp2 plumb mojave clientc down

# This means grab whatever interface is available (not in use)
defaults
	    interface ipdptp*

# Each path specifies a machine that might dial up / log
# in to this server

path
    peer_system_name tamerlane   # nomada uses the login name
                                 # tamerlane
	   
path
    peer_system_name lawrence    # nomadb uses the name lawrence
                                 # for login
    
path
    peer_system_name nomadc   

ifconfig Section for Server With Dynamic Links

The ifconfig section for a dial-in server with a dynamically allocated link has the syntax:

ifconfig ipdptpn plumb server-name client-address down

Example 11-1 contains three ifconfig lines, each initializing a point-to-point interface.

ifconfig  ipdptp0  plumb  mojave  clienta  down
ifconfig  ipdptp1  plumb  mojave  clientb  down
ifconfig  ipdptp2  plumb  mojave  clientc  down

defaults Section for Server With Dynamic Links

When you configure a dynamically allocated link, you might want to include a defaults section in the asppp.cf file. This section sets the defaults for the value replacing keyword, wherever keyword subsequently appears in the asppp.cf file. The syntax for the defaults section is:

default 
     keyword

Example 11-1 uses the keyword interface to define the interface as ipdptp*, indicating a dynamic link. The asterisk wildcard tells the link manager to use any available ipdptp interface defined in the ifconfig section. Thus the link manager on server mojave uses either ipdptp0, ipdptp1, or ipdptp2--whichever is the first interface configured "down" that it finds.

path Section for Server With Dynamic Links

The configuration file for the server with dynamic links must contain path sections for every remote host permitted to establish connections with the server. The path section has the following syntax: .

path
    peer_system_name endpoint-username    

No interface keyword has been defined in the path section because this value is defined in the defaults section.The peer_system_name keyword has the same meaning here as it does in the configuration file for the multipoint server. See "path Section for Multipoint Dial-in Server" for more information.

Additional Keywords

You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate, including the use of security keywords as explained in "Configuration Keywords".

Configuring a Virtual Network

Virtual networks consist of a group of standalone computers, each in an isolated location, that can connect to each other through PPP multipoint links. "Virtual Networks" introduces virtual network concepts. This section explains how to configure a virtual network.

Figure 11-2 Sample Virtual Network

The network shown in Figure 11-2 consists of three isolated computers. Each member of the network connects to the other members of the network through a multipoint PPP link. Therefore, to create such a network, you (and perhaps other network administrators at the remote location) have to configure a multipoint PPP link on each participating host.

You use the same generic process for configuring multipoint links as you do for configuring a multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the virtual network has its own set of issues and requires you to configure each host in the network accordingly.

Addressing Issues for Virtual Networks

You must add host information to the /etc/hosts file for each machine in the virtual network. When typing the IP addresses used for the PPP endpoints:

• Designate a PPP-specific IP address for its point-to-point link. Note that if the machine was not previously configured in a physical network, you must create an IP address for the PPP link. This address becomes the host's primary network interface.

• Create a network number for the virtual network. See "Assigning a Network Number to the PPP Link" for more information.

Updating hosts and networks Databases

The first step in the configuration process involves updating the hosts and networks databases with information about your virtual network.

/etc/inet/hosts File for the Virtual Network

The /etc/inet/hosts file on each machine must contain the addressing information for every member of the network that this host has permission to access. For example, each host in the network in Figure 11-2 would have this information:

# Internet host table
#
127.0.0.1           localhost	loghost
192.41.47.15        nomada
192.41.47.20        nomadb
192.41.47.12        nomadc

/etc/inet/networks File for the Virtual Network

Since the virtual network requires a unique IP address, you must type this address in the networks database. For example, the network shown in Figure 11-2 has the number 192.41.47. Moreover, if the hosts on the network need to communicate with other networks, you should register the network with the InterNIC addressing authority. See Chapter 4, Configuring TCP/IP on the Network, for information on editing the networks database.

Each host on the virtual network must have an entry with the network's address in the /etc/inet/networks file. For example, each host on network 192.41.47 might have the following in /etc/inet/networks:

# Internet networks
#
# arpanet   10          arpa
# ucb-ether 46          ucbether
#
# local networks
loopback    127
ppp         192.41.47   #remote sales offices

Considerations for Other Files

The next steps in the configuration process involve editing the UUCP databases, the /etc/passwd file, and the /etc/shadow file. You edit these files for the machines in the virtual network just as you would for the multipoint dial-in server configuration. Refer to "Editing UUCP Databases" for UUCP-related information and "Modifying the /etc/passwd File" for information regarding the passwd file.

asppp.cf Configuration File for a Virtual Network

The configuration file for a local machine on a virtual network must contain information about all remote hosts on the network that the local host can access. Moreover, each machine on the virtual network must be configured for both dial-in and dial-out functions. After the local machine boots, its link manager reads the asppp.cf file to establish communications.

Example 11-2 shows a configuration file such as you would set up for nomada on a virtual network 192.41.47.

Example 11-2 Configuration File for nomada

# /etc/asppp.cf for hosta

ifconfig ipd0 plumb nomada netmask + up
defaults
   interface ipd0
path
   peer_ip_address  nomadb
   peer_system_name lawrence	   	# name machine logs in with
path
   peer_ip_address nomadc
   peer_system_name azziz

Example 11-3 shows a configuration file such as you would set up for nomadb on virtual network 192.41.47.

Example 11-3 Configuration File for nomadb

# /etc/asppp.cf for nomadb

ifconfig ipd0 plumb nomadb netmask + up
defaults
   interface ipd0
path
   peer_ip_address   nomada
   peer_system_name  tamerlane  # name the machine logs in with
path
   peer_ip_address   nomadc
   peer_system_name  azziz

Editing asppp.cf for PAP/CHAP Security

You can edit the asppp.cf file to establish security and to specify whether parts of the link will respond to Password Authentication Protocol (PAP), or Challenge-Handshake Authentication Protocol (CHAP),as described in "PPP Security". The asppp.cf file is edited by adding a series of keywords. In this section, authenticator is the system starting the link or challenge, and is frequently the server. Peer is the other end of the link, and is often the client.

The keywords to be added are require_authentication and will_do_authentication. The authenticator or server generally require authentication and the peer or client generally do authentication.

How to Install PAP/CHAP

1. On the server, become superuser and prepare to edit the /etc/asppp.cf file.

2. Add the require_authentication keyword for each machine on the link to use either CHAP or PAP security.

   1. For each pap keyword add an associated pap_peer_id and pap_peer_password string.

   2. For each chap keyword add an associated chap_peer_secret and chap_peer_name string.

      You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found in Example 11-4.

3. On each remote host on the link to use either PAP or CHAP security, add an entry in the remote host's /etc/asppp.cf file with the will_do_authentication keyword.

   1. For each pap keyword entry add an associated pap_id and pap_password string.

   2. For each chap keyword entry add an associated chap_secret and chap_name string.

You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found starting with Example 11-4.

Rules for PAP/CHAP Keywords

• Either server or client can require authentication or offer to do authentication.

• If PAP and CHAP are both present, the authenticator first tries CHAP. If that fails, the link is terminated. The authenticator will not try PAP.

• The default value for PAP and CHAP authentication keywords is off. The syntax for keywords is:

  require_authentication off | pap[chap] | chap[pap] will_do_authentication off | pap[chap] | chap[pap]

• If you fail to specify pap_id and pap_password or pap_peer_id and pap_peer_password keywords and values for the associated path, the corresponding values are set to the NULL string.

• You must specify chap_name,chap_secret, chap_peer_secret and chap_peer_name keywords and values for that path.

PAP/CHAP Examples

Example 11-4 shows the asppp.cf file for the server mojave with PAP and CHAP authentication required. The peers are nomada (PAP) and nomadb (CHAP).

Example 11-4 Code Example for Server mojave

ifconfig ipdptp0 plumb mojave nomada up
ifconfig ipdptp1 plumb mojave nomanb up
path
      peer_system_name tamerlane
      require_authentication pap  #tells nomada that mojave
                                  #requires pap authentication
      pap_peer_id desert
      pap_peer_password oasis
path
      peer_system_name lawrence
      require_authentication chap  #tells nomadb that mojave
                                   #requires chap authentication
      chap_peer_name another\sdesert
      chap_peer_secret secret\soasis\swith\007bell

Example 11-5 sample shows mojave's remote host nomada offering to do both PAP and CHAP authentication.

Example 11-5 Code Example for Remote Host nomada

ifconfig ipdptp0 plumb tamerlane mojave up
path
      interface ipdptp0
      peer_system_name mojave
      will_do_authentication chap pap #nomada tells mojave
                                      #that it will do chap and
                                      #pap authentication
      pap_id desert
      pap_password oasis
      chap_name desert\srain
      chap_secret %$#@7&*(+|`P'12

Example 11-6 shows mojave's remote host nomadb offering to do CHAP authentication.

Example 11-6 Code Example for Remote Host nomadb

ifconfig ipdptp0 plumb nomadb mojave private up
path
     interface ipdptp0
     peer_system_name mojave
     will_do_authentication chap   #nomadb tells mojave that it
                                   #will do chap authentication
     chap_name another\sdesert
     chap_secret secret\soasis\swith\007bell

Ideally, both CHAP and PAP are included in the configuration file, with the server requiring authentication and the remote host willing to do authentication. However this is reversible so that either side can require authentication. CHAP secrets need to be delivered by secure means. This generally involves handing them over in person.

Configuration Keywords

This section describes the configuration keywords available for the asppp.cf configuration file and the values you must define for them. Most of these keywords are optional. The required ones are indicated. For further explanations of the keywords, refer to RFCs 1331, 1332, 1333, and 1334.

Table 11-4 lists required keywords that must appear in all asppp.cf configuration files.

Table 11-5 contains optional keywords for asppp.cf that you can use to further define your PPP configuration.