On-Demand Connections
NetWare Link/PPP takes advantage of switched-circuit networks to provide a cost-effective alternative to dedicated data networks that permanently connect remote LANs. To understand the advantages provided by on-demand links created by NetWare Link/PPP, you must understand WAN connectivity with PPP.
This section discusses the following NetWare Link/PPP connectivity concepts that impact Novell Internet Access Server 4.1 network protocol configuration:
Permanent WAN connections connect geographically separated LANs. The WAN connection typically uses leased lines for the physical connection between the separated LANs, and typically uses a router to establish and maintain the connection across the line, as long as the router is operational. There is no cost savings for disconnecting the link because the service provider of a leased line charges a fixed cost.
Network protocols use a permanent WAN connection in a manner similar to the way they use a LAN connection. The protocols exchange both user data and maintenance data, including dynamic route and service updates, across the connection. The bandwidth of a leased line usually ranges from about 56 Kbps to 2.048 Mbps, which is much less than that of a LAN. However, this bandwidth is usually sufficient because not all the traffic that occurs on a LAN needs to be routed across a WAN.
For example, when a user at a branch office needs to access a file on the local branch office server, the data traffic generated by the user accessing the file is not routed across the WAN. Data is routed across the WAN only when requests are made for services accessible through the WAN connection.
Dedicated network connections have the following disadvantages:
NetWare Link/PPP on-demand WAN connections are established at the request of network protocols, based on the presence of user data that must be routed to a destination across the connection. If no data is flowing across an on-demand WAN connection for a preset configurable period of time, then the connection is terminated.
On-demand WAN connections are similar to the way a telephone is used. An outbound call to a remote party is placed by dialing the phone number, and a connection is made when the remote party picks up the phone. A conversation takes place and terminates when one of the parties hangs up the receiver. When a telephone is not in use, it is available to place other outbound calls or accept inbound calls from remote parties. The costs for using the telephone are based on the duration and distance of each call.
Figure 5-1 illustrates on-demand WAN connections between offices. When Branch 1 has data to send to the Main Office, it uses on-demand call 1, named Call_Main_Office. After the router transfers the data and the link reaches the idle link timeout, the call is disconnected. When Branch 2 has data to send to Branch 1, it uses on-demand call 2, named Call_Branch_1.
Figure 5-1.
On-Demand Connections
The analogy between NetWare Link/PPP on-demand connections and telephone calls is not superficial. Voice-grade telephone lines can be used to establish low-bandwidth (typically 2,400 bps to 28,800 bps) on-demand connections. ISDN lines can be used to establish medium-bandwidth (56/64 Kbps to 112/128 Kbps) on-demand connections. Depending on bandwidth requirements, on-demand connections placed over PSTNs (Public Switched Telephone Networks) can be a simple and quick way to establish temporary connectivity between remote LANs.
If low-bandwidth connections do not suffice, you can consider a switched data service, such as switched/56 or switched/256. Switched services can offer significant cost savings over dedicated circuits with the same bandwidth.
Synchronous interfaces operating over ISDN lines are excellent for on-demand connections because they provide 5 to 10 times the bandwidth of analog connections at significantly lower error rates.
On-demand connections have the following advantages:
As described earlier, NetWare Link/PPP on-demand connections are initiated at the request of network protocols when data is present that must be routed to a remote LAN, and they are terminated when the NetWare Link/PPP WAN connection is determined to be idle. Standard network protocols generally expect each WAN circuit to provide permanent connections to all remote systems. The reason is that the network protocols rely on periodic communication with remote systems to dynamically exchange routing updates and, in the case of IPX, service advertising updates. These periodic exchanges identify the network routes and services that are known on each remote LAN accessed over the WAN connections.
Depending on the size of each remote LAN and the speed of the WAN connection, periodic maintenance exchanges can result in a constant stream of data across the NetWare Link/PPP connection, which prevents on-demand connections from terminating using idle-link detection. However, without the maintenance exchanges, Network-layer protocols do not have the information required to route data to the proper remote systems, and on-demand connections are never established because the local network protocols are not aware of the accessible WAN routes and services.
To provide the required route and service information without tying up the on-demand connection, the Novell Internet Access Server 4.1 routing software offers two alternatives:
A single static route is also useful as a default route for IPX or TCP/IP hosts. In this way, the only routing information crossing the link is that required by users to access a specific set of services.
Static routes and services are configured using NIASCFG. In the case of IPX, the Static Routing Configuration utility (STATICON) provides a simplified method to configure static routes and services. STATICON accesses information from the router across the WAN link if the router supports the IPX Management Information Base (MIB) provided with the Novell Internet Access Server 4.1 routing software and Simple Network Management Protocol (SNMP) over IPX. Documentation for the IPX MIB is provided in the IPXMIB.TXT file on the product CD-ROM.
Routed on-demand calls are well-suited for large corporate networks that have many branch offices. For more information on routed on-demand calls, refer to Chapter 1, "IPX,” and Chapter 2, "TCP/IP.”
Using public-switched data or telephone networks provides a high level of communication flexibility that is not possible with dedicated circuit data networks. You can quickly reconfigure WAN connections to support changes in network topology requirements without incurring the delays often experienced when working with external service providers.
However, along with this flexibility there is the potential for unauthorized access. Dedicated circuits implicitly ensure the identity of the connection peers because of the fixed circuit between local and remote systems. However, switched circuits introduce the possibility of call attempts by unauthorized remote systems. Anyone with a modem, phone number, and knowledge of the PPP data-link protocol can potentially establish a rogue connection to a router, and thereby gain access to the attached networks.
To provide protection against unauthorized router access over public-switched data or telephone networks, PPP uses the optional authentication protocols described in the next section.
The PPP protocol specification defines two authentication protocols to protect against unauthorized access: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). During the link establishment phase, a PPP node can request that its data-link peer provide authentication information using one of these authentication protocols. If the remote peer does not agree to provide the requested authentication information, the PPP link is not established. If the peer does agree, the link establishment phase is completed and the authentication phase is entered.
Using the previously negotiated authentication protocol, information is exchanged between the two peers, allowing the local system to authenticate the remote peer. Successful authentication allows the peers to proceed to the NCP negotiation phase. Authentication failure results in termination of the link and the physical circuit.
PAP was the initial mechanism specified by PPP for peer identification. It defines exchange of peer ID/password pairs that are validated by the node requesting authentication of the remote peer. Upon receipt by the requesting node, the ID/password pair is compared against a local list of authorized ID/password pairs. A match results in successful authentication and allows the node to proceed with NCP negotiation. A nonmatch results in termination of the link and the physical circuit.
CHAP was developed to overcome a deficiency in PAP: that is, the password is sent over the link in clear text. CHAP addresses this problem by maintaining a common secret at both peer systems. One system issues a challenge sequence that must be modified using the secret and returned to the challenging peer. The challenging system must validate the response sequence by applying its secret to the original challenge and comparing the result to the response sequence. Authentication successes and failures are processed similar to PAP.
With NetWare Link/PPP, you can configure either PAP or CHAP as the inbound call authentication protocol type for each interface. The system maintains one or more user-configured authentication databases. The database contains entries for each authorized peer represented as ID/password pairs for PAP and ID/secret pairs for CHAP. In both cases, the ID portion, which is exchanged by the over-the-wire protocol, specifies the remote system ID. The remote system ID is used as a database key to access the associated password or secret.
By default, one inbound authentication database is maintained for all NetWare Link/PPP ports; however, you have the ability to specify alternative authentication databases on a per-port basis. This permits any number of ports to share a single database.
The NetWare Link/PPP port configuration allows the configuration of the authentication protocol type (None, PAP, CHAP, Either PAP or CHAP), the name of the authentication database (the default is PPP-AUTH), and the contents of the specified database.
With NetWare Link/PPP, you can also configure PAP or CHAP as the outbound call authentication protocol type for each interface. Support for PAP and CHAP is provided by the Call Support Layer (CSL) WAN call destination entries, which allow specification of authentication information for outbound calls. This information includes the authentication type (None, PAP, CHAP, Either PAP or CHAP) and password or encrypted password, as appropriate.
For on-demand connections, you must configure outbound calls to specify an authentication protocol type, an ID, and a password. To accept inbound on-demand connections, you must configure the PPP interface to validate the authentication information supplied by the calling system. Using PAP or CHAP authentication is recommended for all permanent switched-circuit connections and is required for on-demand connections.
Using PAP or CHAP authentication also provides a method of remote system authentication. When the local system accepts an inbound on-demand connection, the remote system must be identifiable so the local system can reestablish the connection if it is terminated before the data transfer is complete. This is similar to asking telephone callers for their phone numbers, in case you need to call them back.
On-demand connections work reliably only if the called system can establish a return connection. This requires proper configuration of static routes and services, WAN call destinations, and network interface authentication at both ends of the connection. Therefore, if a called Novell Internet Access Server 4.1 system does not have the required configuration information necessary to reestablish a connection to the calling system, it does not accept the initial connection attempt.
For example, your router initiates an on-demand connection to a remote server on behalf of a local client workstation. After the connection is established, the client initiates a database search on the remote server. Before the database search is completed, the on-demand connection is terminated because an idle data-link timeout occurs. Later, when the response to the database search is eventually available, the remote server no longer has a connection to your router. The client operation fails unless the static routing database at the remote server contains the information needed to reestablish the connection. The remote server uses the router's system ID and static route information to reestablish the connection.
Because the ID strings used by PAP and CHAP authentication provide a peer system identification mechanism that solves this problem, PAP or CHAP authentication is required for on-demand connections. The local and remote system ID strings associated with PAP and CHAP authentication typically represent the NetWare server names of the local and remote NetWare Link/PPP connection peers.
Each permanent outbound call configuration identifies a specific NetWare Link/PPP interface that is used to place the call to a remote system. However, when supporting on-demand connections, you might want to have a group of interfaces that can be shared between outbound connections. If each interface in the group provides the same capabilities, any available interface can be used to establish an on-demand outbound connection to a remote system. Furthermore, if all the interfaces are attached to switched circuits that represent the same telephone number, inbound calls placed to that telephone number can be accepted over any available interface in the interface group. This is similar to a multiple-line business telephone. To place an outbound call, you select any available line. Multiple inbound calls placed to the main office number are directed to any available line.
NetWare Link/PPP lets you assign a symbolic name to a group of interfaces that can be used interchangeably. All interfaces in a group must have similar framing characteristics. NetWare Link/PPP outbound call configuration lets you select an interface group name rather than a specific interface name for making outbound calls. Selecting an interface group name directs NetWare Link/PPP to use any available interface within the group to establish the connection.
Defining an interface group (with the Interface Group parameter) lets you make an on-demand call on any of several network interfaces without creating an individual WAN call destination for each interface. All you need to do is specify the interface group name in place of the interface name in the WAN call destination. When the call is made, the specific interface is selected from the group. Because an interface is selected automatically when the call is made, you do not need to dedicate interfaces to specific destinations. This flexibility in selecting interfaces lets you use your WAN hardware more efficiently.
NetWare Link/PPP supports connections over ISDN lines. ISDN is a digital network technology being deployed by international and domestic service providers to replace outdated analog technology. ISDN service is already widely available in Europe and the Pacific Rim, and is becoming widely available in the United States.
Collectively, ISDN is a set of digital transmission protocols defined by the ITU. ISDN provides both voice and data services over two types of lines: a Basic Rate Interface (BRI) and a Primary Rate Interface (PRI). Each type of line consists of a number of 64-Kbps bearer channels (or B channels) and one 16-Kbps or 64-Kbps delta channel (or D channel). B channels are clear-channel connections that can be used for voice and data communication. The D channel is used for signaling and X.25 packet networking.
A BRI line contains two 64-Kbps B channels and one 16-Kbps D channel. In some telco networks, inbound signaling is done by a technique known as bit robbing, and the B channel rate adapts down to 56 Kbps for interoffice traffic. Figure 5-2 illustrates a BRI line.
Figure 5-2.
ISDN BRI Line
A PRI line in North America and Japan contains 23 64-Kbps B channels and one 64-Kbps D channel. It has a total bandwidth of 1.544 Mbps and is designed for transmission through a standard North American T-1 trunk. (In other locations, the PRI line contains either thirty or thirty-one 64-Kbps B channels and one 64-Kbps D channel.)
PPP over ISDN offers inexpensive and reliable WAN connectivity. Dial-up ISDN connectivity is significantly less expensive than leased synchronous lines. In addition, communication over ISDN lines is faster and more accurate than that attainable over analog telephone lines using modems for digital-analog conversion.
A variety of choices of modems or other externally attached devices can be used to provide physical connectivity between link peers. Control of these devices is typically achieved by using the interface port to exchange character-based command/response sequences between the external device and the local node. These command/response exchanges allow configuration of the device, as well as control of operations such as dialing, answering, and terminating PSTN circuits.
The Customer Premises Equipment Configuration utility (CPECFG) provides a terminal interface to a serial port on the router or server to the DSU/CSU or modem. For more information about CPECFG, refer to Novell Internet Access Server 4.1 Routing Configuration.
Command set support differs based on device type; therefore, identification of the attached external device is necessary to the local device management logic that is responsible for physical connection control. For best results, you might want to use the same brand of modem on the local and remote ends.
The WAN device management provided is script-driven and supports multiple modem types. Modem description (MDC) files define modems used by the router. The MDC files reside in the SYS:SYSTEM directory on the router or server.