Contained WithinFind More DocumentationFeatured Support Resources |  Scarica il manuale in formato PDF (750 KB)
Part II Expanding Your Network With PPPPart 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. Chapter 7 Understanding PPPThis 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. Overview of Solaris PPPPPP 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 SpecificationsSolaris 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:
The major functions of the protocol are:
Transmission Facilities Used by PPPPPP 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. Note - Machines of the x86 architecture require UARTs that run above a certain speed. See the for details. Standards ConformancePPP, and the routing functions in the Solaris software, use industry-standard conventions for performing their tasks. These conventions support:
PPP Network InterfacesPPP 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 PPPThis 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 LinksThe 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 CommunicationsWhen 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 CommunicationsWhen 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 PPPSolaris PPP supports four types of point-to-point configurations:
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 LinkPPP 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 ServerIn 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 LinkThe 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 LinkYou 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 LinksYou 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 PPPTwo types of multipoint links you can configure with PPP are:
The sections below summarize these configurations; Chapter 8, Preparing Your PPP Configuration, explains how to set up the configuration. Multipoint Dial-in ServersFigure 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 NetworksYou 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 SoftwareThe PPP component software includes:
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 ManagerThe /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 ServiceThe /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 FileThe 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
Log FileThe 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 FileThe 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 DatabasesBesides 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 TogetherThis section describes how the components of PPP function for outbound and inbound connections. Outbound Connections ScenarioOutbound 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
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 ScenarioThe host initiating the inbound communication logs in, which invokes the /usr/sbin/aspppls login service. Then the following events occur:
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 SecurityAfter 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 ConfigurationBefore 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:
The chapter concludes with a checklist to help you organize this information before you configure your PPP link. Determining Requirements for Your Configuration TypeSolaris PPP supports many configuration options, including:
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:
Remote Computer-to-Network ConfigurationThe 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.
Remote Host-to-Remote Host ConfigurationUse 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-to-Network ConfigurationUse 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.
Dial-in Server With Dynamic Point-to-Point LinksA 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.
Multipoint Dial-in ServerA 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.
Hosts on a Virtual NetworkUse a virtual network configuration to connect three or more physically separated computers into a virtual network of phone lines, modems, and PPP software.
Determining IP Addressing for Your PPP LinkTo 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 AddressesOn each endpoint machine, you specify addressing information in these places:
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:
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 SchemesYou 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 Address as the Primary Network InterfaceThis 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:
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 NameIn 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:
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 LinkYou create a new network number for the PPP configuration when it involves:
(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
In the sample file, kalahari and negev are two local area networks, and nubian-ppp is the name of the PPP link. Routing ConsiderationsThe 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. Note - 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 RIPYou 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:
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 RequirementsThe 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.
File Space RequirementsYou need sufficient space in the following directories for the PPP software:
PPP occupies approximately 243 Kbytes in /usr and 4 Kbytes in / (root). Checklist for Configuring PPPUse 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.
Chapter 9 Configuring PPPThis 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. Overview of the Configuration ProcessYou have completed the preinstallation activities noted in Chapter 8, Preparing Your PPP Configuration. Now you can begin PPP configuration. PPP requires that you:
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 SoftwareThe 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 InstallationBefore 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:
If PPP is installed, the following package names are displayed:
If PPP is not installed on an endpoint system, install it using either the pkgadd program or admintool software manager. Note - 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 ConfigurationThis 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 FileAfter 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. Note - 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
Multipoint Dial-in Server hosts DatabaseMultipoint 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
Editing UUCP DatabasesBefore a machine can dial out over the PPP link, you must edit these files in its UUCP database:
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 PPPThe /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:
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 PPPThe /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:
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 PPPThe /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:.
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 FileTo 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:
Refer to System Administration Guide for information about the /etc/passwd file. Note - 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 FileThe /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 FileThe 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 Section of the asppp.cf FileThe 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:
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. Note - For more information about ifconfig, see Chapter 10, Troubleshooting PPP, and the ifconfig(1M) man page. path Section of the asppp.cf FileThe 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:
interface KeywordThis keyword defines the PPP interface (either ipdptpn or ipdn). In Example 9-1, the following information appears in the path section:
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 KeywordOn 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. Note - 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 KeywordThe 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 KeywordsYou 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 ServerThe 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 Section for Multipoint Dial-in ServerThe 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. Note - You may have to supply a netmask + parameter on the ifconfig line if you use subnetting. path Section for Multipoint Dial-in ServerThe 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.
You need to define a path section for each nomadic endpoint with which the dial-in server can establish connections. interface KeywordFor 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 KeywordThe 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:
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 KeywordThe 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 KeywordsYou 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
There are no other format requirements for the placement of the keywords in the file. How to Edit the asppp.cf Configuration File
Adding PPP SecurityAfter 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 LinkYou can start PPP either automatically, at boot time, or manually from the command line. How to Manually Start PPPYou can start PPP manually, although this is not normally required. How to Verify That PPP Is Running
See Chapter 10, Troubleshooting PPP, for information on troubleshooting and problem solving. How to Stop PPPChapter 10 Troubleshooting PPPThis 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. In summary, you should do these checks in the following order:
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 HardwareMake 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 StatusAfter 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
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
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 ConnectivityUse the ping command to verify that the connection is up or can be established. For example, consider the following simple round-trip test:
where elvis is the name of the PPP interface on the remote host. If the resulting display is
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 ActivityUse the netstat command as follow, to check that packets are being sent and received correctly:
Refer to "netstat Command" and the netstat(1M) man page. Checking the Local Routing TablesUse the netstat command to display the local routing tables:
The following is sample output:
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:
Checking PermissionsIf 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 FlowCheck 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
The ipdptp0 device name mentioned in the first line of the output Using device ipdptp0 indicates a point-to-point connection. Note - 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 TroubleshootingIf 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.
For complete details about the aspppd.conf file, refer to "Editing the /etc/asppp.cf Configuration File". How to Set Diagnostics for Your MachineSet diagnostics on the host you want to monitor as follows:
Analyzing Diagnostic OutputWhen 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 SetupThis 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.
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".)
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".)
UUCP looks for the entry tb9600 in the /etc/uucp/Dialers file and then sends out these messages.
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.
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.
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.
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.
This line indicates that hardware flow control has started on the link. The host obtains flow control information from the /etc/uucp/Dialers file.
In the next series of messages, the local host waits for the remote host to send it a standard UNIX login prompt.
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.
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.
The following messages indicate that dialing and modem connection completed successfully.
Communications Between the Local and Remote HostsAt 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
Here is a description of the configuration request shown in Example 10-4.
The remaining items are a list of options to be negotiated between hosts.
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.
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.
In this packet, the local host acknowledges the remote request by sending it a configuration acknowledgment (Config-ACK).
The local host receives a configuration request (Config-Req) from the remote host.
In these packets, the local host acknowledges the second packet sent by the remote host and receives the remote host's acknowledgment.
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.
This packet indicates that the local host has received IP configuration from the remote host, including its IP address.
The local host sends this ACK to the remote host and receives an ACK from the remote host.
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.
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.
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.
The local host receives a request to terminate the LCP layer. The second message is an acknowledgment of the request, causing a graceful shutdown.
This message indicates that the link has closed.
Chapter 11 Tailoring Your PPP LinkThis 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. Configuring Dynamically Allocated PPP LinksA 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 LinksYou 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:
Note - 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 LinksYou must update the hosts database on all machines involved in the dynamic-link configuration. How to Update a Remote HostWhen configuring the hosts databases on the remote machines, do the following:
How to Update the Dial-in ServerYou 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:
Considerations for Other FilesThe 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 LinkThe 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 LinkThe 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:
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 LinkWhen 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 Section for Server With Dynamic LinksThe 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.
defaults Section for Server With Dynamic LinksWhen 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:
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 LinksThe 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: .
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 KeywordsYou 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 NetworkVirtual 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 NetworksYou 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:
Updating hosts and networks DatabasesThe 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 NetworkThe /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:
/etc/inet/networks File for the Virtual NetworkSince 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:
Considerations for Other FilesThe 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 NetworkThe 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
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
Editing asppp.cf for PAP/CHAP SecurityYou 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. Table 11-1 Authenticator Keywords and Associated Strings
Table 11-2 Peer Keywords and Associated Strings
How to Install PAP/CHAP
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
PAP/CHAP ExamplesExample 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
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
Example 11-6 shows mojave's remote host nomadb offering to do CHAP authentication. Example 11-6 Code Example for Remote Host nomadb
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 KeywordsThis 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-4 Required Keywords for asppp.cf
Table 11-5 contains optional keywords for asppp.cf that you can use to further define your PPP configuration. Table 11-5 Optional Keywords for asppp.cf
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|