Troubleshooting Dial-In Service | Troubleshooting Remote Access Networks (CCIE Professional Development)

In this section, detail is provided on what you can do to determine the cause of the dial-in connection problems. The troubleshooting techniques include commands for use on a modem, outputs from debug commands, and some common recommendations. This section does not include debugs from Cisco AS5x00 series routers because this is covered in a subsequent section later in this chapter.

When troubleshooting a connection problem, try to piece together everything that is expected to occur throughout the process. Use a step-by-step approach to outline all activities from start to finish, and in the correct sequence.

You might be required to make some assumptions as part of the process. First, assume that the analog lines connected to the modems are working, their phone numbers are correct, and a call placed from one end to the other occurs successfully (the switched services work correctly). Obviously, if a problem exists with an analog line, it's a switched service problem, and your telephone provider must correct the issue. This section covers the following steps that are used to troubleshoot a problem with the NAS:

Step One: Verify that the modem is ready to accept incoming calls.
Step Two: Verify the type of connection.
Step Three: Verify Point-to-Point Protocol (PPP) negotiation.

Step One: Verify that the Modem Is Ready to Accept Calls

The first event to occur is that the modem must pick up the call. If it is an external modem, increase the volume so that you can hear it. Place a call from a telephone to the modem to make sure it answers. If it does not, check the cabling between the modem and the router. The type of cable can differ between modems, so the easiest way to check is through the show line line-number command. The line you must check is the following:

 Modem state: Idle

If the modem is ready to take an incoming call, but there is no call on the line, the state should be idle. If the state is anything other than idle, the modem will not answer the call. Several different signals (modem states) have to interact properly for the modem to be ready to accept a call. The Modem Hardware State are

CTS (Clear To Send) Provided by the data communications equipment (DCE). The DCE signals to the data terminal equipment (DTE) that the DCE accepts data.
DSR (Data Set Ready) Provided by the DCE.
DTR (Data Terminal Ready) Provided by the DTE. The DTE indicates to the DCE that it accept calls.
RTS (Request To Send) Provided by the DTE. The DTE signals that the DTE accepts data.

Modem Hardware State: CTS noDSR DTR RTS

In this example, the Modem Hardware State is correct, but the modem is in a ready state instead of an idle state, as indicated by noDSR.

If an active session is on the line, the modem cannot answer a new call. It displays a ready state. The show users command shows you if there is an active session. You can then clear the active session with the privileged command clear line .

The second reason for noDSR can be because modem control is not configured on the line. Configure the line with either modem Dialin or modem InOut .

Lastly, DSR might be high, which results from a cabling problem or if the modem is configured where Data Carrier Detect-Provided (DCD) is always high. Fix the cabling problem or reconfigure the modem so that DCD is only high when carrier detection (CD) is successful, which should clear the problem.

Modem Hardware State: noCTS noDSR DTR RTS

In cases where noCTS replaces CTS in the correct state, three different possibilities exist: the modem is turned off, a cabling problem exists, or hardware flow control on the modem is turned off. The line configuration command no flowcontrol hardware fixes the last of these three problems.

Modem Hardware State: CTS DSR DTR RTS

In cases where DSR replaces noDSR in the correct state, there can be a cable problem. Also, DCD can always be configured on the modem as high. Reconfigure the modem to correct this and ensure that either the line configuration command modem Dialin or modem InOut exists.

Now that the cable connection from router to modem is operational, you must also ensure that the modem is set to auto answer. Consult the modems owner's manual to set this up. This concludes the troubleshooting required if a modem does not answer.

Step Two: Verify Type of Incoming Connection

After step one, where the connection is a fact, perform the second step from the core router (NAS). The Cisco IOS features give you much more insight about the type of the connection than any other approach. Start the incoming type verification by using the debug modem command. The first debug reflects the configuration from a basic PPP dial-in service in Chapter 6, "Dial Design and Configuration Solutions."

When dialing into an external modem, one that does not have out-of- band signaling, the first line should read as follows :

 17:11:38: TTY1: DSR came up

This signifies that the modem has trained up successfully. If this does not take place, there was a problem with the modem train-up. Line issues or modem incompatibilities can cause a train-up failure. To cure any modem incompatibility problem, ensure that the modems on both ends have the latest firmware and drivers.

The following line indicates a change in modem state:

 17:11:38: tty1: Modem: IDLE->(unknown)

The modem in this example happens to be external, so the router does not know which state the modem changed to. If it had been an internal modem with out-of-band functionality, you would have seen the following:

 17:11:38: tty1: Modem: IDLE->READY

At this point, if you have the interface configured with async mode dedicated , the connection immediately jumps into PPP. The PPP debugs are covered later in this section. If the line was configured for text authentication and no PPP, such as a modem in an AUX port, the debug output in Example 7-6 would be displayed.

Example 7-6. Debug Output for Exec Creation

 ! The router starts an exec session: 17:11:43: TTY1: EXEC creation  ! The following two lines are used when prompting for authentication:  17:11:43: TTY1: set timer type 10, 30 seconds 17:11:56: TTY1: set timer type 10, 30 seconds 17:11:67: TTY1: create timer type 1, 600 seconds

The type 10 timer is used for username and password prompts. The fourth line in the output sets a 30-second timer for the username prompt and the fifth line places another 30-second timer for the password prompt. The last line in the output is an exec timer. The default exec-timeout set on a line is 10 minutes, or 600 seconds.

In the preceding example, the modem changed state from idle to unknown. If the async interface was configured with async mode interactive and the line was configured with autoselect ppp and autoselect during-login , the debug is different, as shown in Example 7-7.

Example 7-7. Debug Output of Modem Autoselect for PPP

 22:52:59: TTY1: EXEC creation 22:52:59: TTY1: set timer type 10, 30 seconds 22:53:01: TTY1: Autoselect(2) sample 7E 22:53:01: TTY1: Autoselect(2) sample 7EFF 22:53:01: TTY1: Autoselect(2) sample 7EFF7D 22:53:01: TTY1: Autoselect(2) sample 7EFF7D23 22:53:01: TTY1 Autoselect cmd:  ppp negotiate

During the username prompt, the router checks incoming characters to see if they are PPP or if they are part of a username. The autoselect samples shown in Example 7-7 are in hexadecimal format. If translated to ASCII, they show the text received over a line. There is an autoselect sample for each character that arrives. The router displays up to four characters in each new autoselect sample line and includes the three previous characters , followed by the last character entered as shown.

The four autoselect characters in Example 7-7, if translated into ASCII, are ~}#, which is the typical representation of a PPP link control protocol (LCP) packet. For this reason, the last line in the debug shows that autoselect executed the command ppp negotiate , which instructs the router to negotiate PPP.

The sample output in Example 7-8 uses the same configuration as before, except that the login was done through text. This can either be from typing it manually or from running a login script.

Example 7-8. Debug Output of Modem Autoselect for Text

 23:15:22: TTY1: EXEC creation 23:15:22: TTY1: set timer type 10, 30 seconds  ! Username entry of six characters, followed by carriage return  23:15:23: TTY1: Autoselect(2) sample 6A 23:15:24: TTY1: Autoselect(2) sample 6A68 23:15:24: TTY1: Autoselect(2) sample 6A6875 23:15:24: TTY1: Autoselect(2) sample 6A687565 23:15:24: TTY1: Autoselect(2) sample 68756567 23:15:24: TTY1: Autoselect(2) sample 75656765 23:15:24: TTY1: Autoselect(2) sample 6567656E 23:15:25: TTY1: Autoselect(2) sample 67656E0D 23:15:25: TTY1: set timer type 10, 30 seconds  ! The following lines state [suppressed--line is not echoing], because   ! the password prompt never echoed the characters entered.  23:15:26: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:26: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:27: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:27: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:27: TTY1: Autoselect(2) sample [suppressed--line is not echoing]

In this case, the username entered is six characters followed by a carriage return. You can decode the incoming text for usernames by converting the hexadecimal characters in the sample to ASCII. The hexadecimal string can be pieced together to form 6A 68 75 65 67 65 6E 0D. When changed to ASCII, it spells jhuegen followed by 0D, which is a carriage return. The following lines states "[suppressed--line is not echoing]" because the password prompt never echoes the characters entered; however, you can make the assumption that the password entered was four characters followed by a carriage return (to make up the five lines).

Step Three: Verify PPP Negotiation

After the call connects, PPP negotiation starts. The following output is from debug PPP negotiation . It is split into the major steps, which are explained:

 Mar  2 13:32:45.354: %LINK-3-UPDOWN: Interface Async1, changed state to up Mar  2 13:32:45.354: As1 PPP: Treating connection as a dedicated line Mar  2 13:32:45.354: As1 PPP: Phase is ESTABLISHING, Active Open

NOTE

The Link Dead (physical layer not ready) transition state changes to the Link Establishment phase only if an external event, such as a carrier detect (CD), is up.

LCP Phase of PPP

The following explanations are based on the output you see if you type the debug ppp negotiation command to troubleshoot LCP issues. The first part of the output identifies how PPP treats the connection. For every dial case, it is treated as a dedicated line. The first step in LCP takes place when the dial server sends an outgoing configuration request (O CONFREQ), as shown in Example 7-9.

Example 7-9. Debug Output of PPP Outgoing Configuration Request

 Mar  2 13:32:45.354: As1 LCP: O CONFREQ [Closed] id 33 len 24 Mar  2 13:32:45.354: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) Mar  2 13:32:45.358: As1 LCP:    AuthProto PAP (0x0304C023) Mar  2 13:32:45.358: As1 LCP:    MagicNumber 0xE82CFF9C (0x0506E82CFF9C) Mar  2 13:32:45.358: As1 LCP:    PFC (0x0702) Mar  2 13:32:45.358: As1 LCP:    ACFC (0x0802)

The server expects a reply and the reply should be similar to the Example 7-10, which is an incoming configuration acknowledgment (I CONFACK).

Example 7-10. Debug Output of PPP Incoming Configuration Acknowledgment

 Mar  2 13:32:45.546: As1 LCP: I CONFACK [REQsent] id 33 len 24 Mar  2 13:32:45.546: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000) Mar  2 13:32:45.546: As1 LCP:    AuthProto PAP (0x0304C023) Mar  2 13:32:45.546: As1 LCP:    MagicNumber 0xE82CFF9C (0x0506E82CFF9C) Mar  2 13:32:45.546: As1 LCP:    PFC (0x0702) Mar  2 13:32:45.546: As1 LCP:    ACFC (0x0802)

Next , the incoming configuration request (I CONFREQ) from the connecting client is received. At this point, the client tries to negotiate the callback protocol, as shown in Example 7-11.

Example 7-11. Debug Output of PPP Request for Callback

 Mar  2 13:32:46.402: As1 LCP: I CONFREQ [ACKrcvd] id 2 len 50 Mar  2 13:32:46.402: As1 LCP:    ACCM 0x00000000 (0x020600000000) Mar  2 13:32:46.406: As1 LCP:    MagicNumber 0x588D5503 (0x0506588D5503) Mar  2 13:32:46.406: As1 LCP:    PFC (0x0702) Mar  2 13:32:46.406: As1 LCP:    ACFC (0x0802) Mar  2 13:32:46.406: As1 LCP:    Callback 6  (0x0D0306) Mar  2 13:32:46.406: As1 LCP:    MRRU 1614 (0x1104064E) Mar  2 13:32:46.406: As1 LCP:    EndpointDisc 1 Local Mar  2 13:32:46.406: As1 LCP:     (0x131701F9358C5F03D643118C9B7AC7F0) Mar  2 13:32:46.406: As1 LCP:     (0x70629C00000000)

The dial server then sends an outgoing rejection (O CONFREJ) because callback authentication is not turned on, as shown in Example 7-12.

Example 7-12. Debug Output of PPP Rejection for Callback

 Mar  2 13:32:46.406: As1 LCP: O CONFREJ [ACKrcvd] id 2 len 11 Mar  2 13:32:46.406: As1 LCP:    Callback 6  (0x0D0306) Mar  2 13:32:46.406: As1 LCP:    MRRU 1614 (0x1104064E)

The client then requests a new set of options. This is an incoming configuration request (I CONFREQ), as shown in Example 7-13.

Example 7-13. Debug Output of PPP Incoming Configuration Request

 Mar  2 13:32:46.594: As1 LCP: I CONFREQ [ACKrcvd] id 3 len 43 Mar  2 13:32:46.594: As1 LCP:    ACCM 0x00000000 (0x020600000000) Mar  2 13:32:46.594: As1 LCP:    MagicNumber 0x588D5503 (0x0506588D5503) Mar  2 13:32:46.594: As1 LCP:    PFC (0x0702) Mar  2 13:32:46.594: As1 LCP:    ACFC (0x0802) Mar  2 13:32:46.594: As1 LCP:    EndpointDisc 1 Local Mar  2 13:32:46.594: As1 LCP:     (0x131701F9358C5F03D643118C9B7AC7F0) Mar  2 13:32:46.594: As1 LCP:     (0x70629C00000000)

The server then acknowledges this by sending an outgoing configuration acknowledgement (O CONFACK), as shown in Example 7-14.

Example 7-14. Debug of PPP Outgoing Configuration Acknowledgment

 Mar  2 13:32:46.598: As1 LCP: O CONFACK [ACKrcvd] id 3 len 43 Mar  2 13:32:46.598: As1 LCP:    ACCM 0x00000000 (0x020600000000) Mar  2 13:32:46.598: As1 LCP:    MagicNumber 0x588D5503 (0x0506588D5503) Mar  2 13:32:46.598: As1 LCP:    PFC (0x0702) Mar  2 13:32:46.598: As1 LCP:    ACFC (0x0802) Mar  2 13:32:46.598: As1 LCP:    EndpointDisc 1 Local Mar  2 13:32:46.598: As1 LCP:     (0x131701F9358C5F03D643118C9B7AC7F0) Mar  2 13:32:46.598: As1 LCP:     (0x70629C00000000)

Next, LCP changes state to open. At this point, both sides agree that the server will provide a configuration for the client. LCP is then complete.

 ! The LCP is Open: Mar  2 13:32:46.598: As1 LCP: State is Open

IF LCP never completes and does not change state to open, a few problems can possibly exist:

First, LCP timeouts can be caused by a speed problem between the router and modem. A symptom of this problem is that either one or both of the peers do not see any incoming LCP packets. This occurs only if there is a speed issue between the router and an external modem.
The second type of LCP problem is caused when both peers are not able to agree on authentication. The client and server must agree on authentication type, which is Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), or Microsoft CHAP (MS CHAP). For example, if the server side is set to authenticate through CHAP and the client is configured for PAP authentication, LCP times out while trying to negotiate.
LCP can also fail because of a maximum transmission unit (MTU) mismatch. Make sure that MTU is defined as the same on both peers. If necessary, reduce the MTU on both sides until LCP succeeds.

The Authentication Phase of PPP

After LCP finishes and its state is open, the next step in the process is authentication. During this phase, you can see the authenticating party and whether or not authentication has passed. Example 7-15 shows the output of a successful PPP PAP authentication. This output is a result of the debug ppp authentication command.

Example 7-15. Debug Output of a Successful PPP PAP Authentication

 Mar  2 13:32:46.598: As1 PPP: Phase is AUTHENTICATING, by this end Mar  2 13:32:46.842: As1 PAP: I AUTH-REQ id 7 len 17 from "jhuegen" Mar  2 13:32:46.846: As1 PAP: Authenticating peer jhuegen Mar  2 13:32:46.846: As1 PPP: Phase is FORWARDING, Attempting Forward Mar  2 13:32:46.846: As1 PPP: Phase is AUTHENTICATING, Unauthenticated User Mar  2 13:32:46.850: As1 PPP: Phase is FORWARDING, Attempting Forward Mar  2 13:32:46.850: As1 PPP: Phase is AUTHENTICATING, Authenticated User Mar  2 13:32:46.850: As1 PAP: O AUTH-ACK id 7 len 5 Mar  2 13:32:46.850: As1 PPP: Phase is UP

Network Control Protocol Phase of PPP

When the PPP phase is up, authentication has completed successfully. Then, Network Control Protocol (NCP) negotiates Layer 3 protocols, including IP Control Protocol (IPCP). In the case of dial, IPCP negotiates IP addresses for the peer IP address, the Domain Name System (DNS) servers, and the Windows Internet Naming Service (WINS) servers. The following explanations are based on the output from the command debug ppp negotiation . Remember that the output can be long and you see these lines only if the previous (authentication) phase is successful. First, an outgoing configuration request is sent to the peer that contains its own IP address:

 Mar  2 13:32:46.854: As1 IPCP: O CONFREQ [Closed] id 7 len 10 Mar  2 13:32:46.854: As1 IPCP:    Address 192.168.0.249 (0x0306C0A800F9)

The peer then sends a request to the NAS to do Compression Control Protocol (CCP):

 Mar  2 13:32:47.010: As1 CCP: I CONFREQ [Not negotiated] id 6 len 10 Mar  2 13:32:47.014: As1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)

CCP is then rejected by an outgoing protocol rejection (O PROTREJ) packet. The peer should not attempt to renegotiate CCP:

[View full width]

  [View full width] 
 Mar  2 13:32:47.014: As1 LCP: O PROTREJ [Open] id 34 len 16 protocol CCP  (0x80FD0106000A120600000001)

An incoming configuration request is received, and the peer requests VJ 15 header compression and IP addresses for the peer, including the Primary DNS, Primary WINS, Secondary DNS, and Secondary WINS servers, as shown in Example 7-16.

Example 7-16. Debug Output of IPCP Incoming Configuration Request

 Mar  2 13:32:47.058: As1 IPCP: I CONFREQ [REQsent] id 7 len 40 Mar  2 13:32:47.058: As1 IPCP:    CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) Mar  2 13:32:47.058: As1 IPCP:    Address 0.0.0.0 (0x030600000000) Mar  2 13:32:47.058: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000) Mar  2 13:32:47.058: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000) Mar  2 13:32:47.058: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000) Mar  2 13:32:47.058: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

NOTE

VJ compression is Van Jacobsen TCP header compression, which is a widely accepted compression method. See Part IV, "Frame Relay" for more information.

An outgoing configuration reject (O CONFREJ) is sent to reject VJ 15 header compression:

 Mar  2 13:32:47.058: As1 IPCP: O CONFREJ [REQsent] id 7 len 10 Mar  2 13:32:47.058: As1 IPCP:    CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)

An incoming configuration acknowledgment (I CONFACK) is received and the peer acknowledges the IP address of the NAS:

 Mar  2 13:32:47.062: As1 IPCP: I CONFACK [REQsent] id 7 len 10 Mar  2 13:32:47.062: As1 IPCP:    Address 192.168.0.249 (0x0306C0A800F9)

Because VJ 15 header compression was rejected, so was the request for IP addresses for the peer and those of the DNS and WINS servers. The peer then sends another configuration request packet because the first was rejected, only this time, it asks for addressing without asking for header compression, as shown in Example 7-17.

Example 7-17. Debug Output of IPCP Incoming Configuration Request Without Compression

 Mar  2 13:32:47.246: As1 IPCP: I CONFREQ [ACKrcvd] id 8 len 34 Mar  2 13:32:47.246: As1 IPCP:    Address 0.0.0.0 (0x030600000000) Mar  2 13:32:47.246: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000) Mar  2 13:32:47.246: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000) Mar  2 13:32:47.246: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000) Mar  2 13:32:47.246: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

Confusion occurs when the router sends a configuration non-acknowledgment, which actually refuses the request for the peer to use 0.0.0.0 as every address. Along with this non-acknowledgment (NAK), the NAS sends the peer the IP address and those of the DNS and WINS servers that it wants the peer to use, as shown in Example 7-18.

Example 7-18. Debug Output of Outgoing Non-Acknowledgment with Server Assigned Addressing

 Mar  2 13:32:47.250: As1 IPCP: O CONFNAK [ACKrcvd] id 8 len 34 Mar  2 13:32:47.250: As1 IPCP:    Address 192.168.0.251 (0x0306C0A800FB) Mar  2 13:32:47.250: As1 IPCP:    PrimaryDNS 192.168.100.3 (0x8106C0A86403) Mar  2 13:32:47.250: As1 IPCP:    PrimaryWINS 192.168.100.5 (0x8206C0A86405) Mar  2 13:32:47.250: As1 IPCP:    SecondaryDNS 192.168.100.4 (0x8306C0A86404) Mar  2 13:32:47.250: As1 IPCP:    SecondaryWINS 192.168.100.6 (0x8406C0A86406)

The peer responds to the NAK with yet another configuration request to use the IP addresses provided with the previous NAK. Example 7-19 shows the expected output for this exchange.

Example 7-19. Debug Output of Incoming Request with Server Assigned Addressing

 Mar  2 13:32:47.446: As1 IPCP: I CONFREQ [ACKrcvd] id 9 len 34 Mar  2 13:32:47.446: As1 IPCP:    Address 192.168.0.251 (0x0306C0A800FB) Mar  2 13:32:47.446: As1 IPCP:    PrimaryDNS 192.168.100.3 (0x8106C0A86403) Mar  2 13:32:47.446: As1 IPCP:    PrimaryWINS 192.168.100.5 (0x8206C0A86405) Mar  2 13:32:47.446: As1 IPCP:    SecondaryDNS 192.168.100.4 (0x8306C0A86404) Mar  2 13:32:47.450: As1 IPCP:    SecondaryWINS 192.168.100.6 (0x8406C0A86406)

The NAS then acknowledges the peer as configured correctly by sending an outgoing configuration acknowledgment packet, as shown in Example 7-20.

Example 7-20. Debug Output of Outgoing Acknowledgment with Server Assigned Addressing

 Mar  2 13:32:47.450: As1 IPCP: O CONFACK [ACKrcvd] id 9 len 34 Mar  2 13:32:47.450: As1 IPCP:    Address 192.168.0.251 (0x0306C0A800FB) Mar  2 13:32:47.450: As1 IPCP:    PrimaryDNS 192.168.100.3 (0x8106C0A86403) Mar  2 13:32:47.450: As1 IPCP:    PrimaryWINS 192.168.100.5 (0x8206C0A86405) Mar  2 13:32:47.450: As1 IPCP:    SecondaryDNS 192.168.100.4 (0x8306C0A86404) Mar  2 13:32:47.450: As1 IPCP:    SecondaryWINS 192.168.100.6 (0x8406C0A86406)

When both sides agree on the addressing, IPCP changes state to open and installs the directly connected route to the dialup peer:

[View full width]

  [View full width] 
 Mar  2 13:32:47.450: As1 IPCP: State is Open Mar  2 13:32:47.454: As1 IPCP: Install route to 192.168.0.251 Mar  2 13:32:47.454: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state  to up

NOTE

To troubleshoot a problem during NCP negotiation, ensure that all required IP addresses and protocols are configured.

Two of the most common issues that occur during the NCP stage of PPP negotiation are the following:

The IP address is not configured on the group -async interface on the NAS. In most cases, you are not able to configure an IP address directly on the interface; therefore, you need to configure a loopback interface with an IP address. Use the command ip unnumbered interface on your group-async interface, where interface refers to your loopback interface. This instructs the group-async interface to use the IP address of the loopback.
Verify the availability of pool IP addressing for the client. If all addresses in the pool are already allocated, NCP fails by not providing the peer with an IP address.

NOTE

The typical dial oversubscription ratio for Internet service providers (ISPs) is about ten users to one DS0, and scaling beyond this number is not recommended. In the case of an enterprise environment, remote users tend to dial up more often, and this ratio can be as low as 5 to 1. Oversubscription ratios for enterprises that provide a wide variety of remote access services might find it easier to base their oversubscription rate on percentages. For example, an enterprise might try to keep an average of 40 percent of DS0s available throughout a typical day. This 40 percent is there to handle the spikes in daily usage and holidays, when dial usage is normally much higher than on average.
Verify that DNS and WINS server IP addresses are configured to respond to BOOTP requests. Use the global configuration commands async-bootp dns-server address(es) and async-bootp nbns-server address(es ) to configure this feature.

After PPP negotiation is complete, the dial connection is complete and traffic is able to pass, unless of course routing problems exist in the network.