Troubleshooting PPP


PPP provides a standard method for transporting multiprotocol packets over point-to-point links. Regardless of the PPP definition as a first- and second-layer protocol, for practical purposes, it is more convenient to consider PPP as a third-layer protocol, because the Q.931 negotiation must happen before PPP starts. It is easy to think about ISDN and PPP protocols as a pyramid. For troubleshooting purposes, it's easier to consider the PPP protocol as having four phases: LCP negotiation, authentication, NCP, and termination.

As discussed in Chapter 5, "Dial Technology Background," PPP encapsulates the data over the B channels. Most of the information about PPP settings can be seen in the PPP negotiation process, where the protocol field indicates the upper-layer protocols carried in the information field. Some of the examples of protocol field values are

  • 0x0021 IP

  • 0x0029 AT

  • 0x002B IPX

  • 0x003D Multilink

  • 0x0201 802.1d hellos

  • 0x8021 IPCP

  • 0x8029 ATCP

  • 0x802B IPXCP

  • 0xC021 LCP

  • 0xC023 PAP

  • 0xC025 LQR (link quality report)

  • 0xC223 CHAP

After assessing that the line is active, the next phase of PPP is the Link Establishment Phase, which is controlled by link control protocol (LCP).

Troubleshooting PPP LCP

PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connections. LCP goes through four distinct phases:

  • Link establishment and configuration negotiation

  • Link-quality determination

  • Network-layer protocol configuration negotiation

  • Link termination

First, link establishment and configuration negotiation occurs before any network layer datagrams (IP, AT, and IPX) are exchanged. LCP first opens the connection and negotiates configuration parameters. At this point, the Layer 2 framing is Layer 2 Generic HDLC. This phase is complete when a configuration-acknowledgment frame is both sent and received. The following parameters and options can be negotiated:

  • Maximum Receive/Transmit Unit (MRU/MTU) The default is 1500 bytes.

  • Async Control Character Map The control and escape characters on async links.

  • Authentication protocol PAP (0xC023) or CHAP (0xC223).

  • Quality protocol The process for data-link monitoring.

  • Magic-Number The technique to detect loopbacks.

  • MRRU The maximum received reconstructed unit.

  • Reserved It is reserved for future use.

  • Protocol Field Compression Compression of the PPP protocol field.

  • Address and Control Field Compression Compression of the PPP address and control field.

The link-establishment and configuration-negotiation phase is followed by link-quality determination, which is an optional phase. In this phase, the link is tested to determine whether the quality is sufficient to bring up the network-layer protocols. LCP can delay transmission of network-layer protocol information until this phase is complete.

Next, network layer protocol configuration negotiation occurs. After LCP finishes the link-quality determination, network-layer protocols can be configured separately by the appropriate NCP and can be brought up and taken down any time. If LCP closes the link, it informs the network-layer protocols so they can take appropriate action. At this point, PPP framing is being used.

Finally, link termination occurs. LCP can terminate the link at any time and it usually is done at the request of a user, but can happen because of a physical event, such as the loss of the carrier or the expiration of the idle-period timer. Three classes of LCP frames exist: link-establishment frames are used to establish and configure the link; link-termination frames are used to terminate a link; and link-maintenance frames are used to manage and debug a link.

For practical purposes, it is better to know the order of the phases. For the Cisco remote access environment, the right procedure is as follows:

1.

Q.931 places a data call.

2.

The connection is successful.

3.

LCP PPP starts and establishes the connection parameters.

4.

One- or two-way authentication occurs.

5.

The virtual interface is created.

6.

The number of the virtual interface (Vix) is assigned.

7.

The bundles for IP, CP, and CDP are built.

8.

Data transfer occurs.

The sequence is reversed to terminate the call.

During the LCP negotiations, the O CONFREQ proposes certain options. If all options are acceptable, the remote party returns I CONFACK. You should see this procedure twice because all handshaking procedures are two-way negotiations. Turning on some Cisco IOS debug commands displays the real-time negotiation. The O represents outgoing, and I signifies an incoming message.

A detailed description of the first phase is described next. In order to display both Q.931 and PPP negotiation processes together, it is recommended to use the following:

 804-isdn#debug isdn q931 804-isdn#debug ppp negotiation 

In Example 12-25, you can see the BR0:1 LCP: State is Open message.

Example 12-25. LCP Negotiation Process
 ! Initiation of the call - Q931 Mar 2  04:03:47.900: ISDN BR0: Outgoing call id = 0x8060, dsl 0 Mar 2  04:03:47.904: ISDN BR0: Event: Call to 18007735555 at 64 Kb/s Mar 2  04:03:47.904: ISDN BR0: process_bri_call(): call id 0x8060,     called_number  18007735555, speed 64, call type DATA Mar 2  04:03:47.908: CC_CHAN_GetIdleChanbri: dsl 0 Mar 2 04:03:47.908:     Found idle channel B1 Mar 2 04:03:48.884: ISDN BR0: received HOST_PROCEEDING call_id 0x8060 Mar 2 04:03:50.152: ISDN BR0: received HOST_CONNECT call_id 0x8060 Mar 2 04:03:50.156: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up Mar 2  04:03:50.172: %ISDN-6-CONNECT: Interface BRI0:2 is now     connected to 18007735555 ! Starting PPP protocol Mar 2 04:03:50.180: BR0:1 PPP: Treating connection as a callout Mar 2 04:03:50.180: BR0:1 PPP: Phase is ESTABLISHING, Active Open Mar 2 04:03:51.139: BR0:2 LCP: O CONFREQ [Closed] id 16 len 33 Mar 2  04:03:51.143: BR0:2 LCP:    AuthProto CHAP (0x0305C22305) Mar  2 04:03:51.143: BR0:2 LCP:    MagicNumber 0x081C8F7E (0x0506081C8F7E) Mar  2 04:03:51.143: BR0:2 LCP:    MRRU 1524 (0x110405F4) Mar  2 04:03:51.147: BR0:2 LCP:    EndpointDisc 1 Local     (0x130E01706D6172656B2D6973646E) Mar  2 04:03:51.227: BR0:2 LCP: I CONFREQ [REQsent] id 93 len 32 Mar  2 04:03:51.231: BR0:2 LCP:    AuthProto CHAP (0x0305C22305) Mar  2 04:03:51.231: BR0:2 LCP:    MagicNumber 0xB699FF25 (0x0506B699FF25) Mar  2 04:03:51.231: BR0:2 LCP:    MRRU 1524 (0x110405F4) Mar  2 04:03:51.235: BR0:2 LCP:    EndpointDisc 1 Local     (0x130D016163636573732D677731) Mar  2 04:03:51.239: BR0:2 LCP: O CONFACK [REQsent] id 93 len 32 Mar  2 04:03:51.239: BR0:2 LCP:    AuthProto CHAP (0x0305C22305) Mar  2 04:03:51.239: BR0:2 LCP:    MagicNumber 0xB699FF25 (0x0506B699FF25) Mar  2 04:03:51.243: BR0:2 LCP:    MRRU 1524 (0x110405F4) Mar  2 04:03:51.243: BR0:2 LCP:    EndpointDisc 1 Local     (0x130D016163636573732D677731) Mar  2 04:03:51.243: BR0:2 LCP: I CONFACK [ACKsent] id 16 len 33! Mar  2 04:03:51.247: BR0:2 LCP:    AuthProto CHAP (0x0305C22305) Mar  2 04:03:51.247: BR0:2 LCP:    MagicNumber 0x081C8F7E (0x0506081C8F7E) Mar  2 04:03:51.247: BR0:2 LCP:    MRRU 1524 (0x110405F4) Mar  2 04:03:51.251: BR0:2 LCP:    EndpointDisc 1 Local     (0x130E01706D6172656B2D6973646E) Mar  2 04:03:51.251: BR0:2 LCP: State is Open 

The information about LCP state is available in the output shown in Example 12-26.

Example 12-26. Information About LCP State
 804-isdn#show interface bri 0 1 BRI0:2 is up, line protocol is up   Hardware is BRI with U interface and POTS   MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation PPP, loopback not set   Keepalive set (10 sec)   Interface is bound to Dialer1 (Encapsulation PPP)   LCP Open, multilink Open   Last input 00:00:00, output 00:00:00, output hang never   Last clearing of "show interface" counters never   Queuing strategy: fifo <output omitted> 

If LCP is closed, the PPP options are mismatched on both sides. For any negotiation, the LCP can fail, but there are different configuration commands in a 77x series router that reduce the chance of failure:

  • 776-isdn>set ppp nego count 20 Number of negotiation attempts (default = 10).

  • 776-isdn>set ppp nego integrity 5 Time between two integrity packets in seconds (default = 10).

  • 776-isdn>set ppp nego retry Time between negotiation attempts in milliseconds (default = 5000).

Usually for long-distance connections, the calls are 56 Kbps and the high-order bit of the data is overwritten by the signaling information, causing the called party to possibly report errors. In some solutions, due to the lack of information that the call is 56 Kbps (an old version of SS7), the receiving site treats the call as 64 Kbps, resulting in a common symptom of CRC errors, or probably even "runts" or aborts. The dialer map or map-class dialer statement enables you to specify the speed of the outgoing call. If the connection is successful and if #debug isdn q931 is turned on, you can see a message similar to called_number 18007735555, speed 64, call type DATA. In some cases, you need to define the call as not-end-to-end ISDN, as shown in Example 12-27.

Example 12-27. This Call Is Not End-to-End ISDN
 Mar  1 04:50:50.316: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x3B Mar  1 04:50:50.320:         Bearer Capability i = 0x8890 Mar  1 04:50:50.320:         Channel ID i = 0x83 Mar  1 04:50:50.324:         Keypad Facility i = '18007735555' Mar  1 04:50:51.448: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xBB Mar  1 04:50:51.452:         Channel ID i = 0x89 Mar  1 04:50:55.220: ISDN BR0: RX <-  PROGRESS pd = 8  callref = 0xBB Mar  1 04:50:55.220:         Progress Ind i = 0x8A81 - Call not end-to-end ISDN Mar  1 04:50:55.224:         Signal i = 0x01 - Ring back tone on Mar  1 04:51:05.704: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0xBB Mar  1 04:51:05.708:         Cause i = 0x839F08 - Normal, unspecified or Speci Mar  1 04:51:05.720: ISDN BR0: TX ->  RELEASE pd = 8  callref = 0x3B 

If the call hits voice trunks, the output displays "Destination address is not_ISDN", which indicates that you must add the following statement under your BRI interface:

 804-isdn(config-if)#isdn not-end-to-end 

NOTE

How do you use the magic numbers for troubleshooting? Part of the LCP negotiation defines the so-called magic numbers. The configuration option of PPP provides a method to detect looped-back links and other Layer 2 anomalies. By default, the magic number is not negotiated. Zero is inserted where a magic number might otherwise be used.

Before the configuration option is requested, the calling party must choose its magic number based on an algorithm for random numbers. When a Configure-Request is received with a magic number, the received magic number is compared with the magic number from the last Configure-Request sent to the peer. If the two magic numbers are different, the link is not looped back and the magic number needs to be acknowledged. If the two magic numbers are equal, it's possible that the link is looped back and the Configure-Request is actually the one last sent. To confirm this, a Configure-Nak must be sent with a different magic number value. Reception of a Configure-Nak with a magic number different from the last Configure-Nak proves the link is not looped back. If the magic number is equal to the one sent in the last Configure-Nak, the probability of a looped-back link is increased, and a new magic number must be chosen. If the link is indeed looped back, the same sequence (transmit Configure-Request, receive Configure-Request, transmit Configure-Nak, receive Configure-Nak) will repeat continually. If the link is not looped back, the sequence might occur a few times, but it is extremely unlikely to repeatedly occur.


Troubleshooting PPP Authentication

The next phase of PPP protocol is the authentication phase. By default, PPP authentication is optional and should only be configured after the circuit is known good and IP connectivity has been established. This reduces the number of variables that have to be dealt with in case of a problem. Usually, the protocol number C023- Password Authentication Protocol (PAP) or C223-Challenge Handshake Authentication Protocol (CHAP) is used. If you enter the debug ppp authentication command, you can see the next phase of the PPP negotiation, as shown in Example 12-28. (The authentication command is a subset of ppp negotiation command.)

Example 12-28. debug ppp authentication Output
 804-isdn#debug ppp authentication Oct 106 06:33:50.248: BR0:1 PPP: Phase is AUTHENTICATING, by both Oct 106 06:33:50.248: BR0:1 CHAP: O CHALLENGE id 42 len 33 from "804-isdn" Oct 106 06:33:50.272: BR0:1 CHAP: I CHALLENGE id 218 len 31 from "gateway" Oct 106 06:33:50.276: BR0:1 CHAP: O RESPONSE id 218 len 33 from "804-isdn" Oct 106 06:33:50.308: BR0:1 CHAP: I SUCCESS id 218 len 4 Oct 106 06:33:50.312: BR0:1 CHAP: I RESPONSE id 42 len 31 from "gateway" Oct 106 06:33:50.316: BR0:1 CHAP: O SUCCESS id 42 len 4 

It's important to make sure the type of the authenticationeither PAP or CHAPis the same on both sides of the connection. It is also important that authentication be configured under the physical interface, even when using dialer profiles, because it is the authentication phase that ultimately determines which dialer profile will be used.

NOTE

If you receive config-nack during the authentication negotiation, it means that one side is configured for PAP and the other is configured for CHAP password authentication.


Most ISPs will use PAP authentication. Also, it is probably going to be one-way PAP using the callin option of Cisco IOS routers, which can be seen in Chapter 11. The preferred PPP authentication choice is CHAP because all parts of the password are encrypted, and it supports the MD5 hash function. CHAP also uses three-way handshaking (as shown in the earlier example with three pairs of I and O messages) and avoids sending the password in clear text on the PPP link. You can see encrypted passwords in the configuration of both routers and in the exchange frame. For these reasons, consider CHAP as the superior authentication protocol. To connect using PPP, both parties do not necessarily require authentication, but if it is required, confirm the following:

  • The passwords configured on both the local and remote routers are identical.

  • The local and remote router names are configured correctly.

Don't forget that the passwords are case sensitive. If, after authentication, you see the following: BR0:1 CHAP: O SUCCESS, the authentication was successful. If you enter 804-isdn#sh dialer, you will see the name of the calling party at the end of the screen.

The PPP authentication operates with names instead of numbers and makes ISDN troubleshooting much easier. As previously mentioned, when you try to trace the call working with your provider, your preferred option is to use calling_party_number, provided by Q.931. Tracing calls with a LEC isn't easy because you don't always know how the line is provisioned. Sometimes, in the router output, you cannot see the calling party number because the LEC might either use prefixes, remove prefixes, or replace the number with dialed number identification service (DNIS) information. Another option is to match the parameter call_ref, which requires your timing to be precisely synchronized with the LEC equipment. The PPP authentication allows you to operate with names, such as gateway or 804-isdn, instead of a numbers. This allows you to trace the call from the core router by using IOS-based search and find features.

Troubleshooting PPP Network Control Protocols

NCPs are a set of protocols that negotiate the upper-layer protocols. Every negotiation is a series of requests and acknowledgmentsVi1 IPCP: I CONFREQ and Vi1 IPCP: I CONFACK [REQsent]. During the negotiation process, you can see IPCP, IPXCP (these are not included in Example 12-29), CDPCP, and CCP negotiating IP, IPX, CDP, and COMPRESSION, respectively. The negotiation depends on the configuration and the process starts by establishing the virtual connection, which is a bundle of channels called Multilink PPP (MLP). Next, LCP negotiates the parameters for the virtual connection. In the next example, you see the building of the bundle for IPCP, the negotiation of CCP, the setting of the LZSDCP history, and the CDPCP rejection.

Example 12-29. After PPP Is Up, You Can See Part of NCP with IPCP and CCP Negotiation
 Oct 106 06:33:50.316: BR0:1 PPP: Phase is VIRTUALIZED Oct 106 06:33:50.328: %LINK-3-UPDOWN: Interface Virtual-Access1,     changed state to  up Oct 106 06:33:50.344: Vi1 PPP: Treating connection as a callout Oct 106 06:33:50.344: Vi1 PPP: Phase is ESTABLISHING, Active Open Oct 106 06:33:50.348: Vi1 LCP: O CONFREQ [Closed] id 1 len 34 Oct 106 06:33:50.348: Vi1 LCP:    AuthProto CHAP (0x0305C22305) Oct 106 06:33:50.352: Vi1 LCP:    MagicNumber 0xCEC4C1DA (0x0506CEC4C1DA) Oct 106 06:33:50.352: Vi1 LCP:    MRRU 1524 (0x110405F4) Oct 106 06:33:50.352: Vi1 LCP:    EndpointDisc 1 Local      (0x130F01727363686966662D6973646E) Oct 106 06:33:50.356: Vi1 PPP: Phase is UP Oct 106 06:33:50.360: Vi1 CDPCP: O CONFREQ [Closed] id 1 len 4 Oct 106 06:33:50.360: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 Oct 106 06:33:50.364: Vi1 IPCP:    Address 10.19.230.89 (0x03060A13E659) ! Building the multilink PPP bundle for IP Oct 106 06:33:50.368: BR0:1 IPCP: MLP bundle interface is built,     process packets now Oct 106 06:33:50.368: BR0:1 IPCP: Redirect packet to Vi1 Oct 106 06:33:50.368: Vi1 IPCP: I CONFREQ [REQsent BR0:2 PPP:     Phase is VIRTUALIZED!!!] id 1 len 10 Oct 106 06:33:50.372: Vi1 IPCP:    Address 151.70.196.1 (0x0306AB46C401) Oct 106 06:33:50.372: Vi1 IPCP: O CONFNAK [REQsent] id 1 len 10 Oct 106 06:33:50.372: Vi1 IPCP:    Address 151.68.26.1 (0x0306AB441A01) ! Building the multilink bundle for stac compress Oct 106 06:33:50.376: BR0:1 CCP: MLP bundle interface is built,     process packets now Oct 106 06:33:50.376: BR0:1 CCP: Redirect packet to Vi1 Oct 106 06:33:50.380: Vi1 CCP: I CONFREQ [Not negotiated] id 1 len 10 Oct 106 06:33:50.380: Vi1 CCP:    LZSDCP history 1 check mode SEQ process     UNCOMPRESSSED (0x170600010201) Oct 106 06:33:50.384: Vi1 LCP: O PROTREJ [Open] id 2 len 16 protocol CCP     (0x80FD0101000A170600010201) Oct 106 06:33:50.400: BR0:1 LCP: I PROTREJ [Open] id 1 len 10 protocol     CDPCP (0x820701010004) ! CDPCP rejected Oct 106 06:33:50.404: Vi1 CDPCP: State is Closed Oct 106 06:33:50.404: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10 Oct 106 06:33:50.408: Vi1 IPCP:    Address 10.19.230.89 (0x03060A13E659) Oct 106 06:33:50.408: Vi1 IPCP: I CONFREQ [ACKrcvd] id 2 len 4 Oct 106 06:33:50.412: Vi1 IPCP: O CONFACK [ACKrcvd] id 2 len 4 Oct 106 06:33:50.412: Vi1 IPCP: State is Open Oct 106 06:33:50.420: Di1 IPCP: Install route to 151.68.26.1 Oct 106 06:33:51.316: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,     changed state to up 

When troubleshooting the higher-layer protocols, it is important to know which protocol and which port or application is open in the router. One important feature that enables you to find this out is the command #show tcp brief all, which shows you what TCP sessions are open to a router.

Sometimes, you need to find out if the utilization of the router's processor is high. Some processes are not running and some use most of the router resources. A fast tool to find this out is

 804 -isdn#show processes cpu | exclude 0.00 

This command excludes the processes with utilization 0.00 from the output.

Another important question to answer is which protocol and which port or application is consuming most of the bandwidth. You can find out relatively quickly by using the Cisco IP NetFlow Accounting feature, which makes it possible to quickly identify traffic flows and applications by source and destination port number(s). To do this, you need version 12.2+ of Cisco IOS Software. Follow this procedure:

1.

Type #ip route-cache flow under the dialer interface.

2.

Wait a few minutes and execute the #show ip cache flow command.

The detailed output provides you with the following information:

  • IP packet size distribution and the total number of packets.

  • IP flow switching cache, total number in bytes.

  • Protocol, type (UDP/TCP) distribution.

  • Source and destination IP address of the traffic.

As discussed in Chapter 10, "Cisco ISDN Configuration Solutions," the MLP is a feature providing multivendor interoperability and packet fragmentation, improving the latency of each packet and load calculation. The MLP issues are discussed in the following paragraph.

Troubleshooting MLP

MLP defines a method for sequencing and transmitting packets over multiple physical interfaces. To reduce potential latency issues, MLP defines a method of fragmenting and reassembling large packets. When a packet arrives at an MLP master interface, it is fragmented and transmitted on each physical link in the MLP bundle. Reassembly of the packets occurs on the other side of the connection. MLP is supported, as long as all devices are members of the same rotary group or pool. Usually, designers use load thresholds to define when and for how long MLP will add or remove additional links to the connection. (See Chapters 10 and 11 for more information.)

The easiest way for IOS-based ISDN routers to verify the threshold values of the router is to check the configuration of the IOS ISDN router and look for the value under the command dialer load-threshold, or type #show dialer and look for "load threshold for dialing additional calls is x." A fragment of the output from the second command is shown in Example 12-30.

Example 12-30. show dialer Output
 804-isdn#show dialer BRI0 - dialer type = ISDN Rotary group 1, priority = 0 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. <output omitted> Di1 - dialer type = IN-BAND SYNC NO-PARITY Load threshold for dialing additional calls is 20 Idle timer (60 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Number of active calls = 0 

For a 77x router, the output is displayed in Example 12-31.

Example 12-31. show timeout Output
 776-isdn> show timeout Demand Calling Parameters         Link 1        Link 2   Connection Type                Auto ON        Auto ON   Permanent                          OFF            OFF   Threshold                        5 kbs         48 kbs   Duration                         1 sec          1 sec   Source                             LAN           BOTH Timeout (call tear down) Parameters   Threshold                        5 kbs         48 kbs   Duration                        60 sec         60 sec   Source                             LAN           BOTH 

These commands provide the necessary information on how MLP and the thresholds are set. Keep in mind that, for an 800 series router, the threshold value is a fraction of 255, while for a 700 series router, the value is measured in Kbps.

It is important to define not only the conditions of the threshold (level and duration), but also the destination. There are three major options of IN, OUT, or EITHER for IOS-based routers, and LAN, WAN, or BOTH, for 77x series routers.

To set MLP, enter the following:

  • 804-isdn(config-if)#ppp multilink For IOS-based routers

  • 776-isdn> set ppp multilink on | off For 700 series routers

To check your MLP, you can use one of the following commands:

  • 804-isdn#show ppp multilink

  • 7206-isdn#show ppp multilink | incl name

  • 776-isdn>show negotiationFor 77x routers

Troubleshooting PPP Callback for ISDN

As described in Chapter 11, this PPP feature provides a method for an implementation to request a dial-up peer to call back. When callback is successfully negotiated at the LCP phase and the authentication phase of PPP is complete, instead of going to the NCP phase, PPP disconnects the link.

A sample of checking the functionality of the callback feature is shown in Example 12-32.

Example 12-32. ISDN Callback Output From the debug isdn 931 Command
 804-isdn#debug isdn q931 ! The remote user requests a connection: *Oct 10 04:03:00.914: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x0A *Oct 10 04:03:00.918:         Bearer Capability i = 0x8890 *Oct 10 04:03:00.918:         Channel ID i = 0x83 *Oct 10 04:03:00.922:         Keypad Facility i = '5261783' *Oct 10 04:03:01.250: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x8A *Oct 10 04:03:01.250:         Channel ID i = 0x89 *Oct 10 04:03:01.270: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x8A *Oct 10 04:03:01.278: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x0A ! Incoming and outgoing CONNECT messages  the BRI0:1 is up. *Oct 10 04:03:01.282: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up *Oct 10 04:03:01.302: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to     5261783 *Oct 10 04:03:01.798: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state     to up ! The fact the virtual-access1 interface is up shows that the authentication ! phase was successful. Now the core disconnects the connection: *Oct 10 04:03:01.838: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x8A *Oct 10 04:03:01.842:         Cause i = 0x8090 - Normal call clearing *Oct 10 04:03:01.854: ISDN BR0: TX ->  RELEASE pd = 8  callref = 0x0A *Oct 10 04:03:01.858: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Oct 10 04:03:01.886: %LINK-3-UPDOWN: Interface Virtual-Access1,     changed state to down *Oct 10 04:03:01.998: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x8A ! Now the core router initiates a call to the remote user: *Oct 10 04:03:16.970: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x10 *Oct 10 04:03:16.974:         Bearer Capability i = 0x8890 *Oct 10 04:03:16.974:         Channel ID i = 0x89 *Oct 10 04:03:16.974:         Signal i = 0x40 - Alerting on - pattern 0 *Oct 10 04:03:16.978:         Called Party Number i = 0xC1, '5764740' *Oct 10 04:03:16.982:         Locking Shift to Codeset 5 *Oct 10 04:03:16.982:         Codeset 5 IE 0x2A  i = 0x808001039E05,     'From', 0x208B03, '408', 0x8001098001, '<' *Oct 10 04:03:16.990: ISDN BR0: Event: Received a DATA call from 408 on B1     at 64 Kb/s *Oct 10 04:03:16.998: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x90 *Oct 10 04:03:16.998:         Channel ID i = 0x89 ! The remote user's BRI0:1 comes up: *Oct 10 04:03:17.002: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up *Oct 10 04:03:17.018: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 408 *Oct 10 04:03:17.030: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x90 *Oct 10 04:03:17.034:         Channel ID i = 0x89 *Oct 10 04:03:17.074: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x10 *Oct 10 04:03:17.074:         Channel ID i = 0x89 *Oct 10 04:03:17.078:         Signal i = 0x4F - Alerting off *Oct 10 04:03:17.622: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state     to up *Oct 10 04:03:18.610: %LINEPROTO-5-UPDOWN: Line protocol on Interface     BRI0:1, changed state to up *Oct 10 04:03:18.642: %LINEPROTO-5-UPDOWN: Line protocol on Interface     Virtual-Access1, changed state to up *Oct 10 04:03:23.022: %ISDN-6-CONNECT: Interface BRI0:1 is now connected     to 14085265555 access-gw1 804-isdn# 

As mentioned in Chapter 11, there is a way to set up the configuration so that both channels come up when a call from the core router is received using the #dialer load-threshold 2 inbound command. It is interesting to check the functionality of PPP callback feature using the IOS.

One possible solution is to debug the PPP negotiation and ISDN Q931 with the following commands:

 804-isdn#debug isdn q931 804-isdn#debug ppp negotiation 

Remember: If you are connected through a telnet session to the remote user's router, make sure that the debug commands are turned on with 804-isdn#show debug. Because you will have connects and disconnects during the process, and you will lose the telnet connection, it's recommended that you create a log in the remote user's router configuration to be able to see the entire process afterwards. The output from the log file looks like Example 12-32 (with added PPP negotiation information).

The number 2 in the dialer load-threshold 2 inbound command defines that only the incoming traffic will be compared with the threshold, and it is set to 2 (which is ~1% of the bandwidth = 2 / 255 x 100 x bandwidth).

When both channels are up, how do you check that this is due to incoming calls and not outgoing calls? One of the ways is to read the log file for RX<- and TX-> messages to see who is initiating the call. But because this output can be chatty, you might want to try a simpler way, as shown in Example 12-33.

Example 12-33. Output from the sh isdn st Used to Check the Reason for the Calls
 804-isdn#sh isdn st Global ISDN Switchtype = basic-5ess ISDN BRI0 interface         dsl 0, interface ISDN Switchtype = basic-ni     Layer 1 Status:         ACTIVE     Layer 2 Status:         TEI = 104, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED         TEI = 113, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED     Spid Status:         TEI 113, ces = 1, state = 5(init)             spid1 configured, spid1 sent, spid1 valid             Endpoint ID Info: epsf = 0, usid = 0, tid = 1         TEI 104, ces = 2, state = 5(init)             spid2 configured, spid2 sent, spid2 valid             Endpoint ID Info: epsf = 0, usid = 1, tid = 1     Layer 3 Status:         2 Active Layer 3 Call(s)     Activated dsl 0 CCBs = 2 ! Callid with leading 0:         CCB:callid=C, sapi=0, ces=1, B-chan=1, calltype=DATA ! Callid with leading 0:         CCB:callid=D, sapi=0, ces=1, B-chan=2, calltype=DATA     The Free Channel Mask:  0x80000000     Total Allocated ISDN CCBs = 2 804-isdn# 

An explanation for callid can be found in Chapter 9, "ISDN Technology Background." The most significant bit of Q931 is a bit called Flag. When the Flag is 0, the call is initiated from the core router; when Flag is 1, the call is initiated from the remote user's site. The numbers in the output are callid=C and callid=D. Written in binary codes, they have leading 0s, which means that the calls are originated from the core router, thus the callback is working.

Maybe the simplest way to check the callback function is to use the following command:

 804-isdn#show isdn active 

With this command, check the call's attribute to see if it is IN or OUT, as shown in Example 12-34.

Example 12-34. Checking the Call's Attribute
 --------------------------------------------------------------------------------                                 ISDN ACTIVE CALLS -------------------------------------------------------------------------------- Call    Calling      Called       Remote   Seconds Seconds Seconds Charges Type    Number       Number       Name     Used    Left    Idle   Units/Currency -------------------------------------------------------------------------------- In    ---N/A---     5764740       gateway  17      -       -___________0__ In    ---N/A---     5764740       gateway  44      -       -___________0__ 

The example shows that both calls are incoming, thus the callback works.

As discussed in Chapter 11, another enhancement of MLP is the Multichasis Multilink PPP (MMP), which enables different MLP links to terminate on different NASs.

Troubleshooting MMP

For troubleshooting MMP, it is always recommended that you start with debug sgbp error:

 7200-isdn-a#debug sgbp error ! SGBP errors debugging is on 7200-isdn-b# Aug  9 22:20:03 PDT: %SGBP-7-NORESP: Failed to respond to 7200-isdn-a     group isdnservers, may not have password 

The previous message indicates problems answering the challenges sent by a peer. This should be enough to indicate that the username and password are left out of the stack group, as shown in Example 12-35.

Example 12-35. debug sgbp hellos Output
 7200-isdn-a#debug sgbp hellos ! SGBP hellos debugging is on for both routers 7200-isdn-a# Aug  9 22:29:37 PDT: %SGBP-7-CHALLENGED: Rcv Hello Challenge message from     member 7200-isdn-b using 152.30.253.253 ! Received a hello challenge from 7200-isdn-b from IP address 152.30.253.253 Aug  9 22:29:37 PDT: %SGBP-7-RESPONSE: Send Hello Response to     7200-isdn-b group isdnservers Aug  9 22:29:37 PDT: %SGBP-7-NORESP: Failed to respond to 7200-isdn-b     group isdnservers, may not have password ! You cannot respond because you do not have a password Aug  9 22:29:42 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b     group isdnservers ! You send a challenge to 7200-isdn-b 7200-isdn-b# Aug  9 22:29:37 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-a     group isdnservers Aug  9 22:29:42 PDT: %SGBP-7-CHALLENGED: Rcv Hello Challenge message from member     7200-isdn-a using 152.30.253.254 Aug  9 22:29:42 PDT: %SGBP-7-RESPONSE: Send Hello Response to 7200-isdn-a     group isdnservers Aug  9 22:29:43 PDT: %SGBP-7-NORESP: Failed to respond to 7200-isdn-a     group isdnservers, may not have password ! The password is mismatched or is missing 

! Respond to the challengeFrom the output, each router receives the other's challenge; therefore, you configured the correct host names and IP address for the sgbp peers. Adding the username of isdnservers and the password of cisco to the configuration of both routers fixes the problem indicated in the last line of the previous output stating that the password is mismatched or is missing.

Another possible issue with MMP could be a host name and IP address mismatch. The following message is displayed after entering debug sgbp hello on 7200-isdn-b. It usually means that the router has a host name and IP address mismatch, as shown in the following output:

 Aug 10 01:08:15 PDT: %SGBP-1-MISSCONF: Possible misconfigured member     7200-isdn-a using 152.30.253.254 

Correcting the SGBP peer line with the correct IP address fixes this issue.

An incorrect SGBP password prevents peers from authenticating into the SGBP group. The following message means that either the peer's password for the stack group is incorrect or yours is incorrect:

 Aug 10 01:48:53 PDT: %SGBP-1-AUTHFAILED: Member 7200-isdn-b     failed authentication 

The obvious fix is to verify that you have the correct SGBP username and password entered in both routers keeping in mind that they are case sensitive.

As an example, router 7200-isdn-a is receiving hellos from an unknown peer. As a result, both routers are not establishing a peer relationship. Start by using the debug sgbp error command again on both routers:

 SGBP errors debugging is on 7200-isdn-b# Aug  9 22:59:02 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-a's addr 152.30.253.253     is different from the hello's addr 152.30.253.254 ! Received a hello from 7200-isdn-a, but from 152.30.253.254 instead of what ! was configured in the sgbp member statement Aug  9 22:59:02 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-a's addr 152.30.253.253     is different from the hello's addr 152.30.253.254 7200-isdn-a# 

However, on 7200-isdn-a, there's no output after entering debug sgbp error. So you should take a look at the debug sgbp hello output.

debug sgbp hello on both routers provides the output in Example 12-36.

Example 12-36. debug sgbp hello Output
 SGBP hellos debugging is on 7200-isdn-b# Aug  9 23:00:52 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-a's addr 152.30.253.253     is different from the hello's addr 152.30.253.254 Aug  9 23:00:52 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-a's addr 152.30.253.253     is different from the hello's addr 152.30.253.254 Aug  9 23:00:52 PDT: %SGBP-7-CHALLENGED: Rcv Hello Challenge message from     member 7200-isdn-a using 152.30.253.254 Aug  9 23:00:52 PDT: %SGBP-7-RESPONSE: Send Hello Response to     7200-isdn-a group isdnservers Aug  9 23:00:54 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-a group isdnservers 7200-isdn-a# Aug  9 23:00:08 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-b group isdnservers Aug  9 23:00:30 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-b group isdnservers 

In Example 12-36's output, 7200-isdn-b's configured peer IP address is different than the one the actual hellos are coming from. In addition to the debug command, the command show sgbp tells you that there is another active address for 7200-isdn-a, as shown in Example 12-37.

Example 12-37. show sgbp Output
 7200-isdn-b#show sgbp Group Name: isdnservers Ref: 0xC973B000 Seed bid: default, 50, default seed bid setting   Member Name: 7200-isdn-a State: idle Id: 3   Ref: 0x0   Address: 152.30.253.253   Other Active Address: 152.30.253.254 

In this case, the problem is that a mistake was made on 7200-isdn-b in the IP address of 7200-isdn-a entered in the sgbp member statement. From 7200-isdn-a's perspective, only challenges were sent and nothing was received because 7200-isdn-b was sending the replies to the wrong IP address. From 7200-isdn-b's perspective, challenges were sent, but no responses were received. Instead, 7200-isdn-b was getting challenges from 7200-isdn-a with a different IP address than was configured. After the IP address was fixed, debug sgbp hello on both routers would just show the keepalives sent every two seconds:

 Aug 10 00:28:21 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to     7200-isdn-b, retry=0 Aug 10 00:28:21 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b Aug 10 00:28:23 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to     7200-isdn-b, retry=0 Aug 10 00:28:23 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b Aug 10 00:28:25 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to     7200-isdn-b, retry=0 Aug 10 00:28:25 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b 

NOTE

Some versions of IOS displays these debugs differently.


Mismatched IP addresses are especially easy to encounter if the routers have multiple interfaces. If the sgbp source-ip command is not used, the hellos would use the outgoing interface's IP address as the source IP address. Therefore, it's good to use the IP addresses of loopback interfaces in the sgbp source-ip command to avoid these situations.

The following is not usually something you will see, but it illustrates that missing three keepalives will time out the peer and, in order to re-establish the peer relationship, they must be authenticated again as shown in Example 12-38.

Example 12-38. Missing Three Keepalives
 Aug 10 00:30:37 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 Aug 10 00:30:37 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b Aug 10 00:30:39 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 Aug 10 00:30:39 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b Aug 10 00:30:41 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 Aug 10 00:30:43 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=1 Aug 10 00:30:45 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=2 ! Just missed the third keepalive in a row Aug 10 00:30:47 PDT: %SGBP-7-KEEPALIVE_TIMEOUT: Keepalive timeout on 7200-isdn-b ! 7200-isdn-b has just timed out and is no longer a functional SGBP peer Aug 10 00:30:48 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-b group isdnservers ! Starting hello challenges to try to re-establish 7200-isdn-b as a SGBP peer Aug 10 00:30:49 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-b group isdnservers Aug 10 00:30:50 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-b group isdnservers Aug 10 00:30:51 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to     7200-isdn-b group isdnservers 

As mentioned in Chapter 10, the bidding process of SGBP is when the SGBP stack group routers decide who will be the call master for any given MLP bundle. To view the bidding process, you need to debug SGBP queries, as shown in Example 12-39.

Example 12-39. Debugging SGBP Queries
 7200-isdn-a#debug sgbp queries ! Displays the bidding process Aug 10 14:26:21 PDT: %SGBP-7-NEWP: Peer query #22667 for user1-isdn,     count 1, peerbid 11, ourbid 10000 ! Your peer received a call from user1-isdn and is bidding. ! Your bid is 10000, so you must already be the call master for this user. Aug 10 14:26:21 PDT: %SGBP-7-DONE: Query #32436 for bundle user1-isdn,     count 0, master is local ! The call master is local Aug 10 14:26:21 PDT: %SGBP-7-MQB: Bundle: user1-isdn   State: Done     OurBid: 10000 Aug 10 14:26:21 PDT: %SGBP-7-PB:  152.30.253.254  State: Closed   Bid: 011     Retry: 1 

In this case, the master bundle is on the peer, as shown in Example 12-40.

Example 12-40. The Master Bundle Is on the Peer
 Aug 10 14:27:14 PDT: %SGBP-7-NEWL: Local query #32444 for user2-isdn,     count 1, ourbid 0 ! You received a call from user2-isdn and are starting the bidding process Aug 10 14:27:14 PDT: %SGBP-7-DONE: Query #32444 for bundle user2-isdn,     count 1, master is 152.30.253.254 ! The call master is 152.30.253.254 Aug 10 14:27:14 PDT: %SGBP-7-MQB:       Bundle: user2-isdn   State: Done     OurBid: 000 Aug 10 14:27:14 PDT: %SGBP-7-PB:        152.30.253.254  State: Closed     Bid: 10000  Retry: 0 

Troubleshooting PPP Compression Control Protocol

Compression Control Protocol (CCP) is a member of the NCP suite and provides a compression session that increases the ISDN throughput. Keep in mind that all compression methods are traffic dependant, so you cannot expect the same compression ratio for different types of traffic. The protocol is referred to as PPP CCP and defines a method for negotiating compression on PPP links over leased lines, and WAN circuit-switched-lines including ISDN. To configure compression, use the following:

  • 804-isdn(config-if)#compress {stac | predictor} Under the BRI0 interface

  • 776-isdn>set compression stac | off

Stac compression defines the LZS Stacker compression algorithm and predictorthe RAND or predictor algorithm. The theory behind these algorithms is extremely complex. More information is available in IETF, Calgary Text Compression Corpus, and the Canterbury Corpus files (http://corpus.canterbury.ac.nz/). It is helpful to know that you can see the compression ratio by entering the following:

  • 804-isdn# show compression For IOS 12.1 and higher

  • 776-isdn:gateway>show packets For images 4.2 and higher

Example 12-41 displays the output for a 776 router.

Example 12-41. show packets Output
 776-isdn:gateway> show packets Packet Statistics for Connection 2 Filtered: 0  Forwarded: 2081  Received: 5581 Dropped: 0  Lost: 0   Corrupted: 1  Misordered: 0 Compression Ratio: 1.99:1 776-isdn:gateway> 

Here, the router is reporting compression ratio 1.99:1 for connection 2, calculated on the base of 2081 forwarded and 5581 received packets.

The last phase of PPP protocol is the teardown, or determination of the connection, which, in turn, should result in releasing the LEC's facilities.

PPP: Termination of the Connection

Consider this example: After a connection is established and there is no further demand for a network connection, the end user's router sends a request for disconnect -BR0:1 LCP: O TERMREQ [Open], which is referred to as a termination request. After the expected acknowledgment - I TERMACK [TERMsent], you can see LCP Closed, PPP down. Example 12-42 shows the PPP termination sequence if the debug ppp negotiation command is turned on.

Example 12-42. PPP Termination Sequence
 *Mar  2 04:06:13.755: BR0:1 LCP: O TERMREQ [Open] id 201 len 4 *Mar  2 04:06:13.827: BR0:1 LCP: I TERMACK [TERMsent] id 201 len 4 *Mar  2 04:06:13.827: BR0:1 LCP: State is Closed *Mar  2 04:06:13.827: BR0:1 PPP: Phase is DOWN *Mar  2 04:06:13.831: BR0:1 PPP: Treating connection as a callin *Mar  2 04:06:13.831: BR0:1 PPP: Phase is ESTABLISHING, Passive Open *Mar  2 04:06:13.831: BR0:1 LCP: State is Listen *Mar  2 04:06:13.835: %DIALER-6-UNBIND: Interface BRI0:1     unbound from profile Dialer1 *Mar  2 04:06:13.835: BR0:1 PPP: Phase is ESTABLISHING, Passive Open *Mar  2 04:06:13.839: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to     18007735555 gateway *Mar  2 04:06:13.843: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected from     18007735555 gateway, call lasted 243s. *Mar  2 04:06:14.783: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to     18007735555  gateway *Mar  2 04:06:14.787: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Mar  2 04:06:14.803: BR0:1 LCP: State is Closed *Mar  2 04:06:14.803: BR0:1 PPP: Phase is DOWN *Mar  2 04:06:14.831: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,     changed state to down 

The analogous commands for 77x routers to debug (or not) the PPP phases are

 776-isdn>diag ppp on | off 776-isdn>diag chap on | off 

These commands turn the debug of PPP on and off.

If the ISDN service is provisioned for data and voice, the voice portion will work as every other regular phone. Now you will see how to approach the possible problems if your regular phone is connected to the voice ports of the router.




Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net