Frame Relay Terminology

The Many Uses of PPP

PPP is a versatile protocol, and you can configure it on a number of different interface types:

• Synchronous

• Asynchronous

• ISDN

• High-Speed Serial Interface (HSSI)

• Digital subscriber line (DSL)

As you can already see, PPP can be deployed in a variety of situations. And, as mentioned previously, most people use PPP as their data link layer protocol to access the Internet. PPP is also commonly used as the data-link layer for Integrated Services Digital Network (ISDN) and when configuring a point-to-point link to a non-Cisco device. Another use of PPP can be on a serial backup link, or to "bundle" multiple Basic Rate Interfaces (BRIs) together to maximize bandwidth and load share, such as in a PPP multilink scenario.

When modeling PPP in the internetwork, you will deploy PPP in a number a ways. First, you look at configuring PPP on serial links. Then, the chapter expands and applies the same theory to asynchronous ports using modems. Finally, the chapter discusses how to implement some of the more advanced features of PPP, including PPP compression, PPP multilink, and other PPP features. PPP over ISDN is covered in Chapter 7, "WAN Protocols and Technologies: Integrated Services Digital Network (ISDN)."

Configuring PPP on Synchronous Serial Links

To configure PPP on a serial interface, you must first enable PPP encapsulation on the interface with the encapsulation ppp command. If you are configuring both ends of the PPP link, you need to configure PPP encapsulation on each side. If you are configuring a PPP link with two routers, using DTE-to-DCE cable connections, you also need to use the clock rate bps command on the DCE side of the connection. Essentially , setting the encapsulation coupled with a network layer address is all that is needed for a basic PPP configuration. As you will see, this is just the basic configuration, and you will be using the more advanced features of PPP in the upcoming sections.

The first example involves configuring PPP on a serial interface between two Cisco routers. Use Figure 4-1 as the network diagram and address map, and begin by defining PPP encapsulation on Serial 1 (S1) of r1 and Serial 0 (S0) of r2. Because this is a V.35 back- to-back connection, one side needs to be configured as DCE. Use the clock rate statement on the Serial 1 interface of r1 to accomplish this.

Figure 4-1. PPP Network Diagram and IP Scheme

Example 4-1 demonstrates the configuration commands used for a simple PPP back-to-back configuration.

Example 4-1 PPP on a Serial Interface

 r1(config)#  interface s1   r1(config-if)#  encapsulation ppp   Set PPP encapsulation   r1(config-if)#  clock rate 56000   Needed for DCE connection  r1(config-if)#  ip address 172.16.128.1 255.255.255.252  r1(config-if)#  no shut  r1(config-if)#  ^Z  r1# 

Example 4-2 lists the relevant portions of the configurations for routers r1 and r2.

Example 4-2 Configuration Listings for PPP Back-to-Back Network on r1 and r2

  hostname r1   !   interface Ethernet0   ip address 172.16.1.1 255.255.255.0   no ip directed-broadcast   !   interface Serial1   ip address 172.16.128.1 255.255.255.252   no ip directed-broadcast   encapsulation ppp   clockrate 56000   !   router ospf 2001   network 172.16.1.1 0.0.0.0 area 0   network 172.16.128.1 0.0.0.0 area 1  _________________________________________________________  hostname r2   !   interface Ethernet0   ip address 172.16.2.1 255.255.255.0   !   interface Serial0   ip address 172.16.128.2 255.255.255.252   encapsulation ppp   !   router ospf 2001   redistribute connected subnets   network 172.16.128.2 0.0.0.0 area 1   default-metric 100  

Configuring PPP on Asynchronous Ports for Analog Dial Links

Configuring PPP on asynchronous interfaces for analog dial connections can be more involved than configuring PPP on serial links. This section briefly lists the steps needed to configure PPP and then goes into greater detail on the more complex steps. The steps to configure PPP for use on an asynchronous dialup connection are as follows :

Step 1. Configure the modem and asynchronous port. Step 1 involves attaching and configuring the modem, and configuring the asynchronous port of the router. This step also includes identifying the absolute line number that corresponds to that asynchronous interface. See Chapter 1, "The Key Components for Modeling an Internetwork," for more information on connecting and configuring modems.

Step 2. Define and configure PPP on the asynchronous interface. Configure the asynchronous interface that corresponds to the absolute line number found in Step 1. Configure PPP encapsulation and PPP authentication for the asynchronous interface.

Step 3. Configure network layer addresses or addressing schemas and routing as they corresponds to the asynchronous interface.

Step 4. Configure the asynchronous interface for dial-on-demand routing (DDR).

Step 1: Modem and Asynchronous Port Configuration

Carefully follow the outlined instructions in Chapter 1 to properly connect a modem to either the AUX port or an asynchronous port on a router. This includes using the modem inout command and the modem autoconfigure command or deploying the use of chat scripts. A chat script is always needed for the remote router to dial into the host. To call the chat script on dial-out use only, use the script dialer script_name command under the absolute line entry. The chat script should be kept simple and clean. For example, the following chat script will reset the modem, load the factory defaults, and then dial the number 5496561 and wait for a connect message.

  chat-script dialhost "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT  

The chat script is where you actually place the number to be called with analog dial communications. The dialer map string also has a telephone number on it, but this is used for authentication and caller identification, not for actually placing the call. When the dialer map is deployed in an ISDN configuration, the dialer map string is used to place the call.

Be sure to perform the show line command and make note of the absolute line number that corresponds to the port to which the modem was attached. Example 4-3 attaches a modem to the AUX port of a Cisco 2500 router.

Example 4-3 show line Command Listing the Absolute Line Number of the AUX Port

 Router#  show line  Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int *  0 CTY              -    -      -    -    -      0       0     0/0       -  1 AUX   9600/9600 -   -     -    -    -    0      1     0/0     -  Aux port  2 VTY              -    -      -    -    -      0       0     0/0       -    3 VTY              -    -      -    -    -      0       0     0/0       -    4 VTY              -    -      -    -    -      0       0     0/0       -    5 VTY              -    -      -    -    -      0       0     0/0       -    6 VTY              -    -      -    -    -      0       0     0/0       - Router# 

You later use the absolute line number (1, in this case) to configure an asynchronous link. The absolute line number can and will change with different router types, so it is important to perform the show line command to verify the absolute line number. For example, Example 4-4 attaches a modem to port 16 of the terminal server, and the AUX port is on line 17, not line 1. This example also shows the line as being inactive and shows that a transmit and receive clock is also set. This indicates that a modem is already configured and attached to the line.

Example 4-4 show line Command Listing the Absolute Line Number of the AUX Port

 access_server#  show line  Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int *  0 CTY              -    -      -    -    -      7       0     0/0       - *  1 TTY   9600/9600  -    -      -    -    -      1       0     0/0       - *  2 TTY   9600/9600  -    -      -    -    -      1    1776     0/0       - *  3 TTY   9600/9600  -    -      -    -    -      1       1     0/0       - *  4 TTY   9600/9600  -    -      -    -    -      1       0     0/0       - *  5 TTY   9600/9600  -    -      -    -    -      1       1     0/0       - *  6 TTY   9600/9600  -    -      -    -    -      1       0     0/0       - *  7 TTY   9600/9600  -    -      -    -    -      1       0     0/0       -    8 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -    9 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -   10 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -   11 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -   12 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -   13 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -   14 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -   15 TTY   9600/9600  -    -      -    -    -      0       0     0/0       -  I 16 TTY 115200/115200- inout     -    -    -      0       0     0/0       -  17 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -   18 VTY              -    -      -    -    -      1       0     0/0       -   19 VTY              -    -      -    -    -      0       0     0/0       -   20 VTY              -    -      -    -    -      0       0     0/0       -   21 VTY              -    -      -    -    -      0       0     0/0       -  Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int   22 VTY              -    -      -    -    -      0       0     0/0       - access_server# 

Step 2: Defining and Configuring PPP on the Asynchronous Interface

Next , configure the asynchronous interface of the router and enable it for PPP. To define the asynchronous interface, simply enter the command interface async interface-number. To enable PPP on the interface, you must first decide how you want to use PPP and DDR. This is mainly because when PPP originated, it was designed to use PPP strings on call establishment. An example of this is the /routing command that can be sent upon PPP establishment, to enable routing protocols to transverse the link. To accommodate this type of flexible session establishment, Cisco offers a variety of commands:

• async mode {dedicated interactive} ” This command is off by default ”that is, no asynchronous mode is configured. The line will not be capable of accepting inbound networking because PPP and SLIP connections are not enabled. To use any PPP or SLIP protocols, you must use one of the two async modes:

  - async mode dedicated means that the router does not wait for any end-user prompts. No end- user commands are required to initiate remote connections, and the interface is automatically configured for SLIP or PPP. The remote end will not be capable of selecting any encapsulation methods , addresses, and other modes.

  - async mode interactive means that the router will accept an EXEC command from the end user before a connection is initiated. The async mode interactive command should be used if the remote end desires any session-establishment parameters and if you want to route over the link.

• async {dynamic default} routing ” When using the async mode interactive command, you must use the async dynamic routing command as well. The async dynamic routing command enables the router to accept the /routing keyword when sent by the remote user. If the host interface is set in interactive mode, the async default routing command causes the ppp and slip EXEC commands to be interpreted as if the /route keyword was included in the command. The async default routing command enables routing protocols on dedicated asynchronous interfaces.

• autoselect {ppp slip during-login arap} ” This command is used on the absolute line number, where the modem commands are applied. The autoselect command enables the router to start a protocol when the appropriate starting character is received. For example, if the router receives a return character, it starts an EXEC session. Table 4-2 lists the frame flags in hex for SLIP, PPP, and ARAP.

Table 4-2. PPP Frame Flags

Protocol	Hexadecimal Frame Flag
Return character	0D
SLIP	C0
PPP	7E
ARAP	10

• The during-login argument is used when end users or clients of different protocol types might be dialing into the same port on the router. For example, this option might be used when the client runs a TTY session with a terminal emulator, such as Hyperterm, while at the same time another client might want to connect to the same port using PPP.

• transport input {all lat map nasi none pad rlogin telnet v120} ” By default, Cisco routers do not accept incoming network connections to asynchronous ports. You must specify an incoming transport protocol or use the transport input all command before the line accepts an incoming connection.

To enable PPP on an asynchronous port, use the following commands:

• encapsulation ppp ” As stated previously, this command configures the interface for PPP encapsulation.

• ppp authentication {chap pap} ” PPP authentication is required on analog dial lines to provide secure and reliable dial connections.

Challenge Handshake Authentication Protocol and Password Authentication Protocol

CHAP and PAP authentication are available on all interfaces running PPP. Both protocols were originally outlined in RFC 1334, and later CHAP was updated in RFC 1994. CHAP and PAP use the concept of each device or router identifying itself with a unique name . The identification process also prevents one router from placing a call to another if the other router port is already connected to the site for which it is configured. PPP operates in the following manner:

Step 1. When a PPP session is established, the router determines the type of authentication required from LCP.

Step 2. The router determines the authentication, either CHAP or PAP, and performs one of the following:

- Checks the local database for the proper username and password pairing . This is the default setting, and no login local is needed.

- Forwards an authentication request on to a TACACS+ or RADIUS server.

Step 3. The router runs its authentication process based on the response that it received from the local database or the security server. If the response is positive, the router starts the PPP process; if it is negative, the router rejects the user immediately.

The CHAP and PAP process starts when LCP negotiates the parameters of the link. The PAP process sends a clear-text password across the link, which is interpreted by the routers at the remote ends of the link. A data scope or line monitor can capture the response and then can spoof the same process later; therefore, it is a less secure method of authentication.

The CHAP process never sends a clear-text password across the link, making it inherently more secure then PAP. The CHAP process uses a Message Digest 5 (MD5) hash generator to form a 128-bit hash during its challenge process. Only the hash and its modifiers are sent out on the link.

When an initiating router first issues a challenge to a remote router, the initiating router responds with four important parts of information:

• A CHAP challenge packet type identifier

• A supplied version of the ID, a sequential number that identifies the challenge

• A random number

• The host name of the router issuing the challenge

When the remote router receives the response, it performs a reverse lookup on the username and retrieves the password associated with it. The ID, a random number, and the password are fed into the MD5 hash generator. The output from this process is called a hash. The MD5- hashed CHAP challenge is the number that is sent back across the link. When the hash is sent, it is sent along with the CHAP response packet type identifier, the ID, and the host name of the router. The initiating router performs the same process with the values received from the remote router. That is, the initiating router looks up the password associated with the host name sent by the remote router. The initiating router then feeds this information, along with the ID and random number, into the MD5 hash generator. The result of the process is a hash that is equal to the hash value sent by the remote router. If any other result is produced, the remote fails authentication and the link is torn down.

To configure PPP CHAP authentication, perform the following tasks :

Step 1. Ensure that PPP encapsulation is configured on the appropriate interface.

Step 2. On the host router, add a username equal to that of the remote router's host name that is dialing into your network. On the remote router, add a username equal to that of the host router's host name. The passwords that you assign to the two usernames must match exactly. Don't forget that all passwords are case-sensitive.

Step 3. Under the PPP interface, add the following command for CHAP:

  ppp authentication chap  

Figure 4-2 and Example 4-5 demonstrate two routers configured for PPP CHAP authentication over an asynchronous interface. Normally, you would enable service password-encryption, and the passwords would be encrypted in the router's listing. For readability and educational purposes, however, the passwords have been left unencrypted.

Figure 4-2. PPP CHAP over Asynchronous Dial Configurations

Example 4-5 CHAP Authentication Configuration for the host_router over an Analog Dial Connection

  hostname host_router   !   !   username remote_router password 0 cisco   ip subnet-zero   !   interface Async1   ip address 172.16.128.1 255.255.255.252   no ip directed-broadcast   encapsulation ppp   dialer in-band   dialer map ip 172.16.128.2 name remote_router broadcast 5496560   async mode interactive   ppp authentication chap   !   ip classless   !   !   !   line con 0   exec-timeout 0 0   transport input none   line aux 0   autoselect ppp   login local   modem InOut   modem autoconfigure discovery   transport input all   speed 38400   line vty 0 4   login   !   end  

To configure PPP PAP authentication, perform the following tasks:

Step 1. Ensure that PPP encapsulation is configured on the appropriate interface.

Step 2. On the host router, add a username equal to that of the remote router's host name that is dialing into your network. On the remote router add a username equal to that of the host router's host name. The passwords that you assign to the two usernames must match exactly. Don't forget that all passwords are case-sensitive.

Step 3. Under the PPP interface, add the following commands for PAP:

  ppp authentication pap   ppp pap sent-username   local_device_name   password   password  

NOTE

Whenever you are running a PPP dial-in client, and during your session establishment, you are prompted for a password, which is a clear indication that the host is issuing you a PAP challenge. Many times, this is the case with Internet service providers (ISPs).

Figure 4-3 illustrates the configuration of PPP PAP in the same network as Figure 4-2.

Figure 4-3. PPP PAP over Asynchronous Dial Configurations

Example 4-6 shows the configurations for the host_router and remote_router for the network in Figure 4-3.

Example 4-6 PAP Authentication Configuration for the host_router and remote_router over an Analog Dial Connection

  hostname host_router   !   username remote_router password 0 cisco1   ip subnet-zero   chat-script dialremote "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT   !   interface Ethernet0   ip address 172.16.1.1 255.255.255.0   no ip directed-broadcast   !   interface Async1   ip address 172.16.128.1 255.255.255.252   no ip directed-broadcast   encapsulation ppp   dialer in-band   dialer idle-timeout 305   dialer map ip 172.16.128.2 name remote_router broadcast 5496560   dialer-group 1   async mode interactive   ppp authentication pap   ppp pap sent-username host_router password cisco1   !   ip classless   ip route 172.16.2.0 255.255.255.0 172.16.128.2   !   dialer-list 1 protocol ip permit   !   !   line con 0   exec-timeout 0 0   transport input none   line aux 0   autoselect ppp   script dialer dialremote   modem InOut   modem autoconfigure type usr_sportster   transport input all   speed 38400   line vty 0 4   login   !   end  host_router# _________________________________________________________  hostname remote_router   !   username host_router password 0 cisco1   chat-script dialhost "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT   !   interface Ethernet0   ip address 172.16.2.1 255.255.255.0   !   interface Async1   ip address 172.16.128.2 255.255.255.252   encapsulation ppp   async mode interactive   dialer in-band   dialer idle-timeout 305   dialer map ip 172.16.128.1 name host_router broadcast 5496870   dialer-group 1   ppp authentication pap   ppp pap sent-username remote_router password cisco1   !   no ip classless   ip route 172.16.1.0 255.255.255.0 172.16.128.1   !   dialer-list 1 protocol ip permit   !   line con 0   line aux 0   autoselect ppp   script dialer dialhost   modem InOut   modem autoconfigure discovery   transport input all   rxspeed 38400   txspeed 38400   line vty 0 4   login   !   end  remote_router# 

NOTE

When assigning host names to routers, it's best to use all lowercase names . If you need more text in the name, you can always use the underscore ( _ ) character. Try to stay consistent in naming conventions throughout the internetwork or model, to avoid possible typos and case-sensitive mismatches . Most often, these occur on map statements or an authentication process of one sort . For example, "Host_router" doesn't equal "host_router" or "host-router," even though they are all called "host router." This might seem confusing at times because some of the router names used are proper nouns and are lowercase throughout the book.

Figure 4-4 is a network diagram and IP address map of an asynchronous PPP dial connection between two routers. To configure this model, begin by attaching and configuring a modem to the AUX port of each router. You might want to reference Chapter 1 for more detailed information on modem configuration.

Figure 4-4. PPP Network Diagram and IP Scheme for an Asynchronous Analog Dial Connection

Example 4-7 shows the configuration for the host_router and remote_router in Figure 4-4.

Example 4-7 PAP Authentication Configuration for host_router and remote_router over an Analog Dial Connection

  hostname host_router   !   username remote_router password 0 cisco1   ip subnet-zero   chat-script dialremote "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT   !   interface Ethernet0   ip address 172.16.1.1 255.255.255.0   no ip directed-broadcast   !   interface Async1   ip address 172.16.128.1 255.255.255.252   no ip directed-broadcast   encapsulation ppp   dialer in-band   dialer idle-timeout 305   dialer map ip 172.16.128.2 name remote_router broadcast 5496560   dialer-group 1   async mode interactive   ppp authentication pap   ppp pap sent-username host_router password cisco   !   ip classless   ip route 172.16.2.0 255.255.255.0 172.16.128.2   !   dialer-list 1 protocol ip permit   !   !   line con 0   exec-timeout 0 0   transport input none   line aux 0   autoselect ppp   script dialer dialremote   modem InOut   modem autoconfigure type usr_sportster   transport input all   speed 38400   line vty 0 4   login   !   end  host_router# _________________________________________________________________________________  hostname remote_router   !   username host_router password 0 cisco1   chat-script dialhost "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT   !   interface Ethernet0   ip address 172.16.2.1 255.255.255.0   !   interface Async1   ip address 172.16.128.2 255.255.255.252   encapsulation ppp   async mode interactive   dialer in-band   dialer idle-timeout 305   dialer map ip 172.16.128.1 name host_router broadcast 5496870   dialer-group 1   ppp authentication pap   ppp pap sent-username remote_router password cisco   !   no ip classless   ip route 172.16.1.0 255.255.255.0 172.16.128.1   !   dialer-list 1 protocol ip permit   !   line con 0   line aux 0   autoselect ppp   script dialer dialhost   modem InOut   modem autoconfigure discovery   transport input all   rxspeed 38400   txspeed 38400   line vty 0 4   login   !   end  remote_router# 

Example 4-8 demonstrates the configuration of an asynchronous port and the corresponding AUX port of a router for dial-in and dial-out PPP connections. This example also includes the configuration of the modem. To configure the AUX port for a modem, first perform the show line command and find the absolute line number to which the modem will be physically attached. Then, configure that port for modem use. Second, configure the asynchronous interface for PPP.

Example 4-8 Configuration of an Asynchronous Port for a Modem and PPP (Steps 1 and 2 Only)

 remote_router#  show line  Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int *  0 CTY              -    -      -    -    -      0       1     0/0       -  1 AUX   9600/9600 -   -    -    -    -     0      1     0/0      -  Modem port  2 VTY              -    -      -    -    -      0       0     0/0       -    3 VTY              -    -      -    -    -      0       0     0/0       -    4 VTY              -    -      -    -    -      0       0     0/0       -    5 VTY              -    -      -    -    -      0       0     0/0       -    6 VTY              -    -      -    -    -      0       0     0/0       - remote_router# remote_router#  conf t  Enter configuration commands, one per line.  End with CNTL/Z. remote_router(config)#  interface async 1  remote_router(config-if)#  async mode interactive  remote_router(config-if)#  encapsulation ppp  remote_router(config-if)#  exit  remote_router(config)# remote_router(config)#  line 1  remote_router(config-line)#  modem inout  remote_router(config-line)#  modem autoconfigure discovery  remote_router(config-line)#  autoselect ppp  remote_router(config-line)#  transport input all  remote_router(config-line)#  ^Z  remote_router# 

Recall from Chapter 1 that you can add a loopback interface to assist in performing a reverse Telnet session to test the modem. Another way to try a quick test is to simply Telnet to the Ethernet interface address with a port of 2001. Example 4-9 exhibits a successful reverse Telnet to the modem on port 1. When in session with the modem, performing a quick ATZ or a more detailed AT command such as AT&V displays the current modem configuration. Be sure that you do not forget to disconnect your modem session after testing it using the disconnect command. To do this, complete the Ctrl-Shift-6 keyboard function, which brings you back to the router. Then, enter the disconnect command.

Example 4-9 Performing a Reverse Telnet Session to the Modem

 remote_router#  telnet 172.16.2.1 2001  Trying 172.16.2.1, 2001 ... Open  atz  OK  at&v  ACTIVE PROFILE: B1 E1 L1 M1 N1 Q0 T V1 W0 X0 Y0 &C1 &D2 &G0 &J0 &K3 &Q5 &R1 &S0 &T5 &X0 &Y0 S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:055 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S36:007 S37:000 S38:020 S46:138  S48:007 S95:000 OK  CTRL/SHIFT/6  remote_router#  disconnect  Closing connection to 172.16.2.1 [confirm]  y  

The last two configuration phases involve configuring network layer addresses and configuring DDR. These steps are tightly related to one another because DDR naturally requires some form of a network layer addressing to be in place.

Step 3: Configuring Network Layer Addresses or Addressing Schemas, and Routing as It Corresponds to the Asynchronous Interface

The next step involved in configuring PPP over asynchronous interfaces is to configure all network layer addresses for the interfaces. Along with configuring standard addressing, protocol-specific issues, such as OSPF, demand circuits should also be configured at this time.

You can configure IP addressing on the dialer interface in multiple ways. You can configure the router to assign an IP address to the client, or the router could assign multiple addresses from a pool or could simply ignore the addressing requirements of the client and reference only how to get to the address with a dialer map statement. The async dynamic address and peer default ip address pool commands are used to assign an IP address to the client from a pool or from the host router. Table 4-3 lists the combinations that should be used when configuring and assigning IP addresses to a dialer interface.

Table 4-3. Recommend Router Address and Addressing for PPP

Host Router Interface Commands	Remote Router or Client PPP Settings
Router static IP: ip address local_ip_address dialer map ip remote_ip_address	Router static IP: ip address remote_ip_address dialer map ip local_ip_address
Router static IP: ip address local_ip_address dialer map ip remote_ip_address	Router dynamic IP: ip address negotiated dialer map ip a.b.c.d
Router static IP ip address local_ip_address dialer map ip remote_ip_address	Windows 95/98/2000 static IP: Specify IP address: remote_ip_address
Router static IP dynamic client: ip address local_ip_address peer default ip address remote_ip_address	Windows 95/98/2000 dynamic IP: IP address obtained automatically: remote_ip_address
Router static IP dynamic client from a pool: async dynamic address ip address local_ip_address peer default ip address pool pool_name From the global interface, enter the pool: ip local pool { default pool_name low_ip_ address [ high_ip_address ]}	Windows 95/98/2000 dynamic IP: IP address obtained automatically

Use the ip address negotiated statement when you don't have control of the assignment of the IP address on the dialer interface. This might be the case with ISPs. Usually, the ISP will assign you an address when you make a PPP connection. Using the ip address negotiated statement enables LCP to properly receive an IP address from the host router. You will use this command for "Easy IP configuration," which is essentially NAT using a dynamic address as its outside address, with TCP overload.

NOTE

The command peer default ip address local_ip_address must be entered before the dialer in-band command is entered. If the dialer in-band is entered first, the router will not accept a specific remote peer IP address.

Figure 4-5 illustrates a Windows 95/98 client dialing into an access server. The Windows workstation has its PPP stack configured to receive the IP address automatically. Windows 95/98 dialup networking uses PPP PAP for authentication.

Figure 4-5. Windows 95 PPP Dial-In

If the workstation wants access to the Internet, a DNS server needs to be configured on the client if DHCP is not used. In Example 4-10, the access_server assigns the address of 172.16.20.2 to the PPP client dialing in. Notice that the access server also has a dialer list on it. This defines interesting traffic so that the link does not terminate while the client is sending data. The dialer idle-timeout terminates the line after 5 minutes and 5 seconds (305 seconds) of inactivity.

Example 4-10 WIN 95 PPP Configuration for an Analog Dial Connection

  hostname access_server   !   username user1 password 0 cisco1   ip subnet-zero   !   interface Ethernet0   ip address 206.191.241.42 255.255.255.248   no ip directed-broadcast   !   interface Async16   ip address 172.16.20.1 255.255.255.0   no ip directed-broadcast   encapsulation ppp   dialer in-band   dialer idle-timeout 305   dialer-group 1   async mode interactive   peer default ip address 172.16.20.2   no cdp enable   ppp authentication pap   !   ip classless   !    dialer-list 1 protocol ip permit    !   line con 0   exec-timeout 0 0   transport input none   line 1 8   transport input all   line 9 15   line 16   autoselect ppp   login local   modem InOut   modem autoconfigure type usr_sportster   transport input all   speed 115200   line aux 0   line vty 0 4   login   !   end  access_server# 

NOTE

By default, the Cisco Discovery Protocol (CDP) is enabled on all interfaces. To disable CDP on an interface, use the no cdp enable command. CDP is used in ODR routing and to help identify other adjacent Cisco devices. CDP messages can keep dialer lines up if it is not disabled on these type of interfaces. CDP can be considered a security risk if it is enabled and you are not using ODR.

Controlling Routing Updates

The second half of Step 3 involves configuring routing for the DDR link. Proper control of routing updates can be one of the most difficult parts of DDR configuration. To prevent routing updates from constantly bringing up the link and dialing, you must have thorough knowledge of the routing protocol in use. You must also understand how the routing protocol sends and receives updates from one network to another, so as not to filter pertinent information. The dilemma for network engineers is how to propagate routing information without needing to constantly keep the link active.

There are several ways to address how to route on a DDR link without keeping the link active all the time. To accommodate spoofing and routing updates for distance vector protocols for IP, as well as IPX RIP and AppleTalk RTMP, Cisco invented snapshot routing. Snapshot routing involves taking a "snapshot" of the routing table and then spoofing the interface that participates in snapshot routing of its routing updates for a certain period. This time, called the snapshot quiet time, eventually expires , forcing the router to make a call to the snapshot server to receive a routing update. Snapshot helped solve some problems of routing over a dynamic link, but it does have a limitation: It doesn't support protocols that support variable-length subnet masking (VLSM). To address dynamic links for OSPF networks, OSPF uses a concept called demand circuits.

Demand circuits are complex and are covered in more detail in Chapter 7 covers snapshot routing and the dialer watch commands in greater detail.

As you can see, when modeling or designing any network with dynamic links, it is important to look at the routing schema of the entire network. You must consider whether you need to advertise networks with different bit boundaries over your backup link. As you will learn in upcoming chapters, protocols such as RIP and IGRP accept and advertise only those networks on the same major bit boundary whose subnet masks match those of the interface sending or receiving the routing update.

Table 4-4 lists some suggested methods of routing over dynamic links based on routing schemas that Cisco supports.

Table 4-4. Dynamic and Static Routing Methods over Dial Links Based on Routing Protocol Type

Routing Protocol	Dynamic Routing Updates Method	Static Method
EIGRP	dialer watch	Floating static routes AD distance > 170
IGRP	Snapshot routing dialer watch	Floating static routes AD distance > 100
OSPF	OSPF demand circuit dialer watch	Floating static routes AD distance > 110
RIP version 1	Snapshot routing	Floating static routes AD distance > 120
IPX RIP/SAP	Snapshot routing	Floating static routes
IPX EIGRP	Snapshot routing	Floating static routes
AppleTalk	Snapshot routing	Floating static routes

A common approach to the routing dilemma, and the approach that this section addresses, is the application of floating static routes or weighted routes. A floating static route is a static route defined as a route that is not permanently entered into the routing table. The route appears only under a special set of circumstances. A floating static route is configured as a static route to a destination network with an administrative distance greater than the routing protocols in use. This allows the route to be advertised through the routing protocol first. If the route learned by the routing protocol is lost, the floating static route will be entered into the routing table. The syntax for configuring a weighted or floating static route is as follows:

  ip route   remote_ip_subnet subnet_mask  {[  ip_next_hop administrative_distance  (  1-255  )]  interface  } 

An administrative distance of 150 to 180 is usually sufficient for weight. Table 4-5 lists the administrative distances for routing protocols and static routes. If no administrative distance is added to the ip route command, the default distance is 1. If you point the static route to an interface instead of the next-hop address, the administrative distance will be 0, as in a connected route. A static route that can reach the next-hop IP address will be placed in the forwarding table. A connected route will always be in the forwarding table, unless the interface is in a down state.

Table 4-5. Default Administrative Distances on Cisco Routers

Route Source/Type	Default Administrative Distance
Connected interface
Static route pointing to an interface
Static route to a next-hop interface	1
EIGRP summary route	5
External BGP	20
EIGRP	90
IGRP	100
OSPF	110
IS-IS	115
RIP-1 and RIP-2	120
EGP	140
External EIGRP	170
Internal BGP	200
Unknown route Unreachable	255

Figure 4-6 illustrates the relevant commands needed for using floating static routes to back up a serial connection. In this example, you also need to be sure to use the IP subnet-zero command because the address 192.168.1.1/30 is being used on the asynchronous link. The natural network for the asynchronous link as assigned is 192.168.1.0/30, which is the zero subnet on a Class C network. Keeping the DDR link on a separate subnet eliminates the worry of the routing protocol (EIGRP, in this case) bleeding routing updates onto the link. This is yet another way to control routing updates on a link.

Figure 4-6. Floating Static Route Configuration for Analog Dial Connection

Step 4: Configuring the Asynchronous Interface for Dial-on-Demand Routing

Dial-on-demand routing (DDR) can be divided into two subgroups:

• Legacy DDR ” Enables a temporary connection only when there is interesting traffic to send to that destination. Legacy DDR is configured when a static relationship exists between the physical dialing interface and the destination.

• Advanced DDR with dialer profiles ” Used when multiple logical connections want to share the same physical interface. This form of DDR exists when one or more logical interfaces share the same physical interface on a per-call basis. An example of this is when one router wants to dial two different remote locations and run separate Layer 3 protocols. At times, the router might want to dial the Internet and run only IP, while at other times, the router might want to dial into a headquarters site while running IP and IPX.

This section covers legacy DDR; advanced DDR topics are covered in Chapter 7.

All DDR, whether legacy or advanced, operates in a similar way:

Step 1. When a router receives traffic, it performs a lookup in the routing table to see whether a route exists to the traffic's destination. If a destination exists, an outbound interface is associated with it. If this interface is configured for DDR, the router performs another lookup to determine whether the traffic is interesting.

Step 2. The router then locates the next-hop address and uses either the dialing instructions in the dialer string command or the dialer map command for ISDN TAs. For modems that support V.25 bis dialing, the dial number is taken off the chat-script command. V.25 bis is an ITU-T standard for in-band signaling to bit synchronous DCE devices.

Step 3. The router checks to see whether the associated interface is in an up state and is connected to the remote destination. If the interface is connected, the traffic is sent and the dialer idle timer is reset if the traffic is interesting. If the interface is not connected, the router sends call setup information to the DCE device on the interface based on the dialer string, dialer map, or chat-script arguments.

Step 4. While the link is connected, the router sends interesting and uninteresting traffic to the destination. When the router finishes sending interesting traffic, it sets an idle timer. When the idle timer expires, as defined by the dialer idle-timeout command, the router disconnects the call.

Configuring DDR is a four-step process:

Step 1. Define interesting traffic ” Defining interesting traffic can be done in one of two ways. The whole protocol suite might be defined as interesting, or an access list can be called to further narrow down significant traffic by type or destination. The syntax needed to define DDR is as follows:

  dialer-list   dialer-group_number   protocol   protocol_name  [  permit   deny   list   access-list_number  ] 

Step 2. Enable DDR and assign a dialer list to an interface ” To enable DDR on an interface, use the dialer in-band command for V. 25bis devices, and use the dialer-group command on the interface. The dialer in-band command specifies for the interface that will be used to perform call setup and teardown between the router and an external dialing device. ISDN devices use the D channel for call setup and teardown , so the dialer in-band command is not needed for ISDN BRIs and PRIs. The dialer-group command assigns the interface to the dialer list, which, in turn , defines which traffic is interesting. The dialer-group must match the dialer list number. The commands to accomplish this are as follows:

- dialer in-band

- dialer-group 1-10

Step 3. Define destination parameters ” This step involves configuring a next-hop address and determining how the router will reach that address. It also involves what name the router will use for authentication and how the router will treat the DDR connection. This is also a good time to define a dialer idle-timeout. To configure a next-hop addresses and determine how the router will reach the next hop, use either the dialer map or the dialer string commands. The dialer string command can be used with the dialer remote-name command for CHAP authentication.

The dialer map statement is the first cousin of the frame-relay map statement. The dialer map statement tells the router how to reach the next-hop address by protocol type. The current protocols supported are AppleTalk, bridging, ISO CLNS, DECnet, HPR, IP, IPX, LLC2, NetBIOS, snapshot routing protocol, Banyan VINES, and XNS.

  dialer map   protocol_name next_hop_address  [  name   remote_device_name  ]   [  class   class_name  ] [  speed 56   64  ] [  broadcast  ] [  dialer_string  ] 

The name parameter should always equal the host name of the remote router connected to the interface. This parameter is used for authentication purposes.

A class can be added, as you will see in PPP callback. The speed and dialer_string arguments are used for ISDN interfaces only. The speed is set at a default of 64 kbps. The dialer_string is for ISDN, where the string is the telephone number that the router will dial when interesting packets to the next-hop address are received. For asynchronous devices, such as modems, you must use a chat script for the router to pass the dial string onto e device. Finally, DDR is nonbroadcast by default; however, if broadcast traffic is to cross the link, the broadcast keyword must also be added.

The dialer map command enables you to express a lot of DDR commands on one line. Some of these commands can be entered individually:

- dialer string dialer_string

- dialer remote-name remote_device_name

- dialer idle-timeout seconds

The dialer idle-timeout is the idle timer that is set to mark when the last interesting traffic was sent. If no further interesting traffic is sent before the idle timer expires, the link is disconnected. The default idle dialer is 120 seconds.

Step 4. Configure optional call parameters ” Additional call parameters can be added to the interface at this time. Some of the more useful ones are as follows:

dialer fast-idle seconds ” This command is primarily used with multiple dialer profiles, such as in a DDR with dialer profiles configuration. When two logical dial interfaces are competing for the same physical line, the timer specifies how long the line can remain idle before the current call is disconnected and another dialer interface can place a call. This command should be used when contention for a link is particularly high. You will see this command used in the Chapter 7.

dialer load-threshold 1-255 [ outbound inbound either ] ” This command specifies the interface load at which the dialer initiates another call to the destination. The value is set at a load between 1 and 255, as in the show interface command; 1 is the lowest load, which makes the dialer call almost immediately. This can be tweaked further by specifying the direction of the traffic. This command is used in conjunction with the ppp multilink command, as discussed in an upcoming section.

Using an earlier example of PPP PAP authentication, you can now focus on the DDR portion of the configuration. Figure 4-7 illustrates two routers connected through modems attached to their AUX ports. When each router detects traffic destined toward the subnet defined in the static routes, it dials the other router. This call stays connected until no IP traffic has crossed the subnet for 305 seconds. This time limit is assigned in the dialer idle-timeout statements.

Figure 4-7. Network Topology for the PPP Analog Dial Configuration

Example 4-11 shows the configurations for the host_router and remote_router in Figure 4-7.

Example 4-11 PPP Analog Dial Configuration

  hostname host_router   !   username remote_router password 0 cisco1   ip subnet-zero   chat-script dialremote "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT   !   interface Ethernet0   ip address 172.16.1.1 255.255.255.0   no ip directed-broadcast   !   interface Async1   ip address 172.16.128.1 255.255.255.252   no ip directed-broadcast   encapsulation ppp   dialer in-band   dialer idle-timeout 305   dialer map ip 172.16.128.2 name remote_router broadcast 5496560   dialer-group 1   async mode interactive   ppp authentication chap   !   ip classless   ip route 172.16.2.0 255.255.255.0 172.16.128.2   !   dialer-list 1 protocol ip permit   !   !   line con 0   exec-timeout 0 0   transport input none   line aux 0   autoselect ppp   script dialer dialremote   modem InOut   modem autoconfigure type usr_sportster   transport input all   speed 38400   line vty 0 4   login   !   end  host_router# _________________________________________________________  hostname remote_router   !   username host_router password 0 cisco1   chat-script dialhost "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT   !   interface Ethernet0   ip address 172.16.2.1 255.255.255.0   !   interface Async1   ip address 172.16.128.2 255.255.255.252   encapsulation ppp   async mode interactive   dialer in-band   dialer idle-timeout 305   dialer map ip 172.16.128.1 name host_router broadcast 5496870   dialer-group 1   ppp authentication chap   !   no ip classless   ip route 172.16.1.0 255.255.255.0 172.16.128.1   !   dialer-list 1 protocol ip permit   !   line con 0   line aux 0   autoselect ppp   script dialer dialhost   modem InOut   modem autoconfigure discovery   transport input all   rxspeed 38400   txspeed 38400   line vty 0 4   login   !   end  remote_router# 

To reiterate, recall the step-by-step list for configuring PPP over asynchronous interfaces. This step-by-step list is a useful tool in configuring PPP over asynchronous interfaces:

Step 1. Modem and asynchronous port configuration: Step 1 involves attaching and configuring the modem, and configuring the asynchronous port of the router. This step also includes identifying the absolute line number that corresponds to that asynchronous interface. See Chapter 1 for more information on connecting and configuring modems.

Step 2. Define and configure PPP on the asynchronous interface. Configure the asynchronous interface that corresponds to the absolute line number found in Step 1. Configure PPP encapsulation and PPP authentication for the asynchronous interface.

Step 3. Configure network layer addresses or addressing schemas, and routing as it corresponds to the asynchronous interface.

Step 4. Configure the asynchronous interface for dial-on-demand routing (DDR).

Configuring PPP Compression

PPP also offers the use of data payload compression to maximize performance across low-bandwidth links. Compression is negotiated by LCP during link initialization. Because LCP negotiates this parameter, it is necessary to have compression configured on both sides of the link. Cisco offers three types of payload compression on PPP links, along with standard TCP header compression :

• Predictor ” Predictor compression is accomplished through a "lossless" predictor algorithm that learns data patterns and can predict the next character in the data stream. The algorithm is called "lossless" because the scheme reproduces the original bit stream exactly, with no degradation or loss. Predictor is more memory-intensive and less CPU- intensive .

• Stacker ” Stacker, as mentioned in Chapter 3, "WAN Protocols and Technologies: High-Level Data Link Control (HDLC)," is a Lempel-Ziv (LZ) “based compression algorithm. This algorithm tries to predict the next sequence of characters in the data stream by using an index to look up a sequence in compression dictionary. The route sends each data type once with information about where the type occurs within the data stream. Stacker is more CPU-intensive and less memory-intensive than Predictor.

• MPPC ” Outlined in RFC 2118, Microsoft Point-to-Point Compression (MPPC) allows Cisco routers to exchange data with Microsoft clients. MPPC uses LZ-based compression. Like Stacker, MPPC is more CPU-intensive and less memory-intensive than Predictor.

The preceding compression techniques are configured with the compress command at the interface level. To enable payload compression, use the following interface command:

  compress  [  predictor   stac   mppc  ] 

When enabling compression, the link should always be restarted or cleared with the clear interface interface_name command. This forces the routers or LCP to renegotiate the link with compression enabled. You cannot use any form of payload compression with TCP header compression.

TCP header compression, as defined in RFC 1144, uses the Van Jacobson algorithm for compressing TCP headers. TCP header compression is most useful when deployed in an environment where there are many small data packets. TCP header compression can significantly cut down on the TCP overhead associated with these packets. To enable TCP header compression, use the following interface command:

  ip tcp header-compression  [  passive  ] 

The passive argument compresses outbound TCP packets only if incoming TCP packets on the same interface are compressed. If the passive argument is not specified, all traffic is compressed.

Compression is most effective if the data that you are transferring is highly compressible , such as a text file or ASCII-based data. Files such as JPEG or MPEG files are already compressed to a great extent, and compression merely slows down the router and the transfer of this type of data. Compression will also increase the number of CPU cycles and the amount of memory used by the router. Therefore, you should apply careful consideration to current memory and processor usage before enabling compression.

Two useful commands for analyzing whether compression is in use, are the show processes and show processes buffers commands. Example 4-12 lists the output of the show processes command. Here we see the average utilization of this router is approximately 30 percent. In this case, the router has enough resources to enable compression. Be careful when implementing compression on routers operating at 65 percent of capacity.

Example 4-12 Output from the show processes Command

 skynet_2#  show processes   CPU utilization for five seconds: 29%/2%; one minute: 30%; five minutes: 32%  PID QTy       PC Runtime (ms)    Invoked   uSecs    Stacks TTY Process    1 Csp    2E68C         1132      67278      16 3760/4096   0 Load Meter    2 ME    122648      8882756    6695839    132610432/12288  0 Exec    3 Lst   17E918       494620      45735   10814 7960/8192   0 Check heaps    4 Cwe   183AE8            0          1       0 7840/8192   0 Pool Manager    5 Mst   11A2E8            4          2    2000 7808/8192   0 Timers    6 Lwe   1D0124       219292     342622     640 7528/8192   0 ARP Input    7 Mwe   23D924          892       1668     534 7144/8192   0 DDR Timers    8 Mwe   24DA90            0          2       011920/12288  0 Dialer event    9 Lwe   260FC0            0          1       0 7856/8192   0 Entity MIB API   10 Mwe   429FE4            0          2       0 7816/8192   0 Serial Background   11 Mwe   42DF08            4          1    4000 7856/8192   0 SERIAL A'detect   12 Cwe   188D94            0          1       0 7848/8192   0 Critical Bkgnd   13 Mwe   1A0690        16212      49282     32810888/12288  0 Net Background   14 Lwe   11090C         6900      19588     35211752/12288  0 Logger   15 Msp   12C25C       274660     335655     818 7472/8192   0 TTY Background   16 Msp   19FD38         6244     335694      18 7800/8192   0 Per-Second Jobs   17 Mwe    F0DB0         8092    1186590       6 7648/8192   0 LED Timers   18 Mwe   4BB398            0         23       0 7976/8192   0 CSM timer process   19 Mwe   4BE740          212        574     369 7736/8192   0 POTS   20 Mwe   2004B8        16908      44367     381 7544/8192   0 CDP Protocol   21 Mrd   2B434C       272492     211068    129110672/12288  0 IP Input 

NOTE

Cisco offers hardware accelerator cards, or compression service adapters (CSAs), to offset the overhead compression that uses valuable router resources. Cisco compression is performed on the CSA boards if present in the router.

Configuring PPP Multilink

PPP multilink is a mechanism for combining, or bundling, multiple physical links into one large logical link. The logical end-to-end connection is called a bundle. This bundle provides increased bandwidth to the destination, along with reduced latency by allowing packets to be disassembled and sent down different links simultaneously to the same destination.

The most common use of PPP multilink is with ISDN, which can use PPP multilink to bind two 64-kbps B channels together to form a single 128-kbps link. ISDN is the most common use of PPP multilink; however, it is also supported on the following interfaces:

• Asynchronous interfaces

• Synchronous interfaces

• ISDN interfaces

  - ISDN BRI

  - ISDN PRI

Figure 4-8 illustrates how a PPP multilink is formed .

Figure 4-8. PPP Multilink Bundles

When a bundle is formed, it can be formed with different physical interface types. For example, an asynchronous interface can be joined with a synchronous interface to form a bundle.

NOTE

PPP multilink is outlined in RFC 1990, which replaces RFC 1717. RFC 1990 specifies multivendor interoperability and resolves some earlier ISDN sequencing issues.

PPP multilink is an option negotiated by LCP during its initial negotiation period. After negotiation, PPP multilink operates by first splitting packets into fragments. The fragments then are sent at the same time over multiple point-to-point links to the same remote address. When the fragments arrive at the other side of the connection, LCP reassembles them into a packet.

To configure PPP multilink, use the following commands on the interface or dialer on which you want to configure PPP multilink:

  ppp multilink   dialer load-threshold   load  [  inbound   outbound   either  ] 

The dialer load-threshold command specifies the interface load at which the dialer initiates another call to the destination. The value is set at a load between 1 and 255, as in the show interface command; 1 is the lowest load, which makes the dialer call almost immediately. This can be tweaked further by specifying the direction of the traffic.

NOTE

Cisco IOS Software Release 11.1 is the first release to support PPP multilink. Cisco IOS Software Release 11.3 includes a feature called the Bandwidth Allocation Control Protocol (BACP). BACP enables two routers to negotiate which peer will add or remove links during a session.

To verify the functionality of PPP multilink, use the debug ppp negotiation script along with a source ping. By turning on the debug for PPP, you can tell when LCP brings up another channel or link. By performing a extended ping, you can easily force a large amount of data quickly across the link to exceed the load threshold and bring up another PPP bundle. The show ppp multilink command can also be useful to show the state of a multilink session. Example 4-13 demonstrates the use of the show ppp multilink command, followed by an extended ping, which brings up the second multilink bundle.

Example 4-13 show ppp multilink Command Output

 skynet_2#  show ppp multilink  Virtual-Access1, bundle name is cns_isdn_callback   Dialer interface is Dialer1   0 lost fragments, 0 reordered, 0 unassigned, sequence 0x0/0x0 rcvd/sent   0 discarded, 0 lost received, 1/255 load   Member links: 1 (max not set, min not set)  BRI0:1  Only one active bundle  skynet_2#  ping  Protocol [ip]:  ip  Target IP address:  172.16.16.2  Repeat count [5]:  1000  Datagram size [100]:  2000  Timeout in seconds [2]:  5  Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 1000, 2000-byte ICMP Echos to 172.16.16.2, timeout is 5 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! <<<text omitted>>> !!!!! Success rate is 100 percent (370/370), round-trip min/avg/max = 152/161/284 ms skynet_2#  show ppp multilink  Virtual-Access1, bundle name is cns_isdn_callback   Dialer interface is Dialer1   0 lost fragments, 0 reordered, 0 unassigned, sequence 0x496/0x2F1 rcvd/sent   0 discarded, 0 lost received, 25/255 load   Member links: 2 (max not set, min not set)  BRI0:1  Both BRIs are in the bundle  BRI0:2 skynet_2# 

Configuring PPP LAPB and LQM

PPP link quality can be enforced or enabled on Cisco routers in two ways. One method is done by enabling LAPB numbered mode negotiation. This is done with the ppp reliable-link command. Another method is by enforcing Link Quality Monitoring (LQM) on the link with the ppp quality command.

LQM monitors the link quality; if the quality drops below a configured percentage, the router shuts down the link. The percentages are calculated for both incoming and outgoing traffic. The LQM out is calculated by comparing the total number of packets and bytes sent with the total number of packets and bytes received by the destination node. The incoming LQM is measured by comparing the total number of packets and bytes received with the total number of packets and bytes sent by the destination peer.

When LQM is enabled, Link Quality Reports (LQRs) are sent in place of keepalives . LQR is further defined in RFC 1989, "PPP Link Quality Monitoring."

NOTE

LAPB numbered mode inserts essentially another error-correction layer with retransmits, if necessary, while LQM monitors link quality.

To enable LQM, use the following command:

  ppp quality   percentage_of_successful_traffic  

The other form of increasing link reliability is to use the ppp reliable-link command. This command causes the router to provide LAPB numbered mode negotiation. LAPB performed on the data-link layer can provide error detection for many upper-layer protocols, such as PPP, in this case.

You must enable PPP reliable link on both ends of the link. Unlike ppp quality, you can use the ppp reliable-link command with compression; however, you cannot use PPP reliable link with PPP multilink. To verify that these commands are functioning, use debug ppp negotiation because LQM will be listed there.

The "Big show" and "Big D" for PPP and DDR

Cisco offers some strong commands for debugging PPP and DDR sessions. Again, this section focuses on the best and most useful show and debug commands. The "big show " and "Big D" for PPP and DDR are as follows:

• show interface interface_name ” The show interface command provides useful information about the physical state of the interface. The interface will always show UP and spoofing mode when configured for DDR.

• show line x ” The show line command provides useful information on the physical state and, to some degree, the logical state of the interface. For more information on the show line command, see Chapter 1.

• show ip route ” Use the show ip route command to verify that the PPP subnet is up and active. The subnet shows "connected" only when the link is actually up and connected on both ends.

• debug ppp negotiation ” This command is probably the most useful command for debugging PPP sessions. Every aspect of LCP negotiation is listed in the output. Example 4-14 demonstrates a PPP session being negotiated between two routers. Look for IPCP to finish in an open state for IP protocols. You will see a CP negotiate for every PPP option and protocol specified.

• debug ppp authentication ” This command instantly points out any PPP authentication errors, such as CHAP and PAP errors. See Example 4-15 for a demonstration of PPP authentication failure.

• debug dialer ” debug dialer commands are used primarily to debug when dialing occurs. As the debug dialer command shows, successful dialing occurs only when DDR and ACLs have been configured correctly.

The following examples show some of the "big Show " and the "big D" commands in action. The debugs should all be used together because they present a clearer picture of what is happening. In Example 4-14, all the debugs from the preceding list, along with debug async state, have been turned on.

Example 4-14 Output of a Successful debug ppp negotiation

  01:01:57: Async1: Dialing cause ip (s=172.16.128.2, d=172.16.1.1)  Dial is   started, Dialer-list is OK  01:01:57: Async1: Attempting to dial 5496561 01:01:57: CHAT1: Attempting async line dialer script 01:01:57: CHAT1: Dialing using Modem script: dialhost & System script: none 01:01:57: TTY1: cleanup pending. Delaying DTR 01:01:57: CHAT1: process started 01:01:57: CHAT1: Asserting DTR 01:01:57: TTY1: Set DTR to 1 01:01:57: CHAT1: Chat script dialhost started.....  01:02:14: CHAT1: Chat script dialhost finished, status = Success  Modem connected  01:02:14: TTY1: destroy timer type 1 01:02:14: TTY1: destroy timer type 0  01:02:14: As1 PPP: Async Protocol Mode started for 172.16.128.1  PPP started  01:02:14: As1 AAA/ACCT: Using PPP accounting list "" 01:02:14: As1 IPCP: Install route to 172.16.128.1 01:02:16: %LINK-3-UPDOWN: Interface Async1, changed state to up 01:02:16: As1 PPP: Treating connection as a callout  01:02:16: As1 PPP: Phase is ESTABLISHING, Active Open  PPP negotiation begins  01:02:16: As1 LCP: O CONFREQ [Closed] id 21 len 20 01:02:16: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) 01:02:16: As1 LCP:    MagicNumber 0x0069B38A (0x05060069B38A) 01:02:16: As1 LCP:    PFC (0x0702) 01:02:16: As1 LCP:    ACFC (0x0802) 01:02:18: As1 LCP: TIMEout: State REQsent 01:02:18: As1 LCP: O CONFREQ [REQsent] id 22 len 20 01:02:18: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) 01:02:18: As1 LCP:    MagicNumber 0x0069B38A (0x05060069B38A) 01:02:18: As1 LCP:    PFC (0x0702) 01:02:18: As1 LCP:    ACFC (0x0802) 01:02:20: As1 LCP: TIMEout: State REQsent 01:02:20: As1 LCP: O CONFREQ [REQsent] id 23 len 20 01:02:20: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) 01:02:20: As1 LCP:    MagicNumber 0x0069B38A (0x05060069B38A) 01:02:20: As1 LCP:    PFC (0x0702) 01:02:20: As1 LCP:    ACFC (0x0802) 01:02:20: As1 LCP: I CONFACK [REQsent] id 23 len 20 01:02:20: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) 01:02:20: As1 LCP:    MagicNumber 0x0069B38A (0x05060069B38A) 01:02:20: As1 LCP:    PFC (0x0702) 01:02:20: As1 LCP:    ACFC (0x0802) 01:02:20: As1 LCP: I CONFREQ [ACKrcvd] id 180 len 25 01:02:20: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) 01:02:20: As1 LCP:    AuthProto CHAP (0x0305C22305) 01:02:20: As1 LCP:    MagicNumber 0x0A548C93 (0x05060A548C93) 01:02:20: As1 LCP:    PFC (0x0702) 01:02:20: As1 LCP:    ACFC (0x0802) 01:02:20: As1 LCP: O CONFACK [ACKrcvd] id 180 len 25 01:02:20: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) 01:02:20: As1 LCP:    AuthProto CHAP (0x0305C22305) 01:02:20: As1 LCP:    MagicNumber 0x0A548C93 (0x05060A548C93) 01:02:20: As1 LCP:    PFC (0x0702) 01:02:20: As1 LCP:    ACFC (0x0802)  01:02:20: As1 LCP: State is Open   01:02:20: As1 PPP: Phase is AUTHENTICATING, by the peer  CHAP begins   01:02:20: As1 CHAP: I CHALLENGE id 39 len 32 from "host_router"  CHAP challenge  01:02:20: As1 CHAP: O RESPONSE id 39 len 34 from "remote_router"  01:02:20: As1 CHAP: I SUCCESS id 39 len 4  CHAP OK  01:02:20: As1 PPP: Phase is UP  01:02:20: As1 IPCP: O CONFREQ [Closed] id 9 len 10  IP Parameters  01:02:20: As1 IPCP:    Address 172.16.128.2 (0x0306AC108002) 01:02:20: As1 CDPCP: O CONFREQ [Closed] id 9 len 4 01:02:20: As1 IPCP: I CONFREQ [REQsent] id 22 len 10 01:02:20: As1 IPCP:    Address 172.16.128.1 (0x0306AC108001) 01:02:20: As1 IPCP: O CONFACK [REQsent] id 22 len 10 01:02:20: As1 IPCP:    Address 172.16.128.1 (0x0306AC108001) 01:02:20: As1 CDPCP: I CONFREQ [REQsent] id 22 len 4 01:02:20: As1 CDPCP: O CONFACK [REQsent] id 22 len 4 01:02:20: As1 IPCP: I CONFACK [ACKsent] id 9 len 10 01:02:20: As1 IPCP:    Address 172.16.128.2 (0x0306AC108002)  01:02:20: As1 IPCP: State is Open  IP OK  01:02:20: dialer Protocol up for As1 01:02:20: As1 CDPCP: I CONFACK [ACKsent] id 9 len 4 01:02:20: As1 CDPCP: State is Open 01:02:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up remote_router# 

Example 4-15 illustrates a PPP CHAP failure on a link with the debug ppp authentication command.

Example 4-15 PPP CHAP Failure

 skynet_lab#  debug ppp authentication  Se0 PPP: Phase is AUTHENTICATING, by the peer Se0 CHAP: I CHALLENGE id 51 len 31 from "skynet_lab" Se0 CHAP: O RESPONSE id 51 len 31 from "isp_router" Se0 CHAP: I FAILURE id 51 len 25 msg is "MD/DES compare failed" Se0 PPP: Phase is AUTHENTICATING, by the peer Se0 CHAP: I CHALLENGE id 52 len 31 from "skynet_lab" Se0 CHAP: O RESPONSE id 52 len 31 from "isp_router" 

The debug ppp negotiation command can be one of the most powerful debugs available for PPP. It's not too data-intensive, and it provides enough information to solve or narrow down a majority of PPP-related problems.

NOTE

Technique, Technique, Technique

It might seem that some of these examples and labs are overcomplicated with routing protocols and by using VLSM, but there is a reason for this. Too often, many texts and examples use standard 24-bit address space and pay little attention to addressing and other techniques. This just puts the engineer into bad habits of IP address design. In most of this text, IP addresses are assigned just like they would be in the field. Constant reinforcement in examples like this improves your technique. Much in the same way that a martial artist pays strict attention to the smallest detail of every move, you must pay strict attention to every command that you make. If you don't know the purpose of a command in a configuration, ask yourself, "Is it a necessary command?"

Configuring PPP Callback

PPP callback is a way for a remote or calling router to place a call to a callback server, terminate the link, and then receive a call from the callback server. This method can be used to enhance security and to control which side of the link gets connection time. Configuring PPP callback is covered in detail in Chapter 7.