Performing Loopback Calls to Test BRI Circuits

Introduction

This document provides instructions on how to perform loopbacks in order to test Basic Rate Interface (BRI) circuits.

Prerequisites

Requirements

Readers of this document should have knowledge of these topics:

• The output of the debug isdn q931 and debug ppp negotiation commands.

• General DDR dialer profile configuration concepts. For more information on dialer profiles, see Configuring and Troubleshooting Dialer Profiles.

Before you attempt this procedure, obtain the following information from the Telco:

• Switch-type that is to be configured.

• Service profile identifiers (SPID) and the local directory number (LDN). The SPID and LDN are required in the United States of America.

• Whether both B-channels are in a hunt group. If they are in a hunt-group we only need to dial one number to reach either B-channel.

• Whether the call on the BRI line needs to be made at 56k or 64k

Components Used

The information in this document is based on these software and hardware versions:

• Cisco IOS Software Release 12.0(3)T, and later. This is because the isdn call command was introduced in Cisco IOS Software Release 12.0(3)T.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Background Information

In a loopback call, the router dials the ISDN number of its own Basic Rate Interface (BRI). The call proceeds to the telco cloud, where the telco switches the call to the second BRI channel. This call is now seen by the router as an incoming call on the second channel. Therefore, the router both sends and receives the ISDN call.

A loopback call tests the ability of the router to initiate and terminate an ISDN call. A successful loopback call gives you a strong indication that the ISDN circuit to the telco cloud is functional.

There are two types of Loopback Calls that you can perform to test a BRI circuit:

• An ISDN Layer 3 loopback call ??? for which you can use the isdn call interface command. This loopback call can help you to verify whether ISDN Layers 1, 2, and 3 are functional between the router and the local ISDN switch. This test uses the D-channel, and does not test data across the B-channels. This involves no changes to the configuration of the router. Perform this test first. If it succeeds, attempt the data loopback call test.

• A data loopback call ??? which tests whether the B-channels can actually pass data. This involves a configuration change on the router.

These procedures only allow you to test whether the BRI circuit to the local switch is functional. It does not test end-to-end ISDN connectivity or issues related to dial-on-demand routing (DDR). For more information about troubleshooting BRIs refer to the following documents:

• ISDN BRI Troubleshooting Flowchart

• Troubleshooting ISDN BRI Layer 3 using the debug isdn q931 Command

Perform an ISDN Layer 3 Loopback Call

This section provides an example of a successful ISDN Layer 3 loopback call. The isdn call command enables outgoing ISDN calls without DDR requirements such as interesting traffic and routes. This command can only be used to test the ISDN circuit up to Layer 3, and cannot be used to pass traffic or as a substitution for proper DDR configuration. This command verifies whether the ISDN circuit, especially Layer 3, is functional.

Figure 1 displays the call flow and some of the debug isdn q931 messages:

Figure 1 - The Call Flow, and Some debug isdn q931 messages

maui-soho-04#isdn call interface bri 0 5551111

!--- The router dials 5551111 (the ISDN number of the router's own BRI). !--- If the BRI circuit has two different phone numbers for each B-channel, !--- use the number that belongs to the second B-channel. !--- You can use this command to make calls at 56k, with the speed 56 option
.
maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch.

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch now processes the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call.

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call.

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call.

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call.

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect message for the outgoing call.

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful.

Notes:

• During the loopback call, the router performs as both the Called Router and the Calling Router on different B-channels. It is important that you keep track of these "dual roles" when you interpret the debug isdn q931 output. For example, the router transmits a setup message (TX -> SETUP), and receives one too (RX <- SETUP). The transmitted SETUP must be associated with the outgoing call while the received SETUP message is associated with the incoming call.

• In the above example, the number for the first B-channel is dialled. However, the telco recognizes that the first B-channel is busy (since it makes the call), and switches the call to the second B-channel and the connection is completed successfully. However, an incorrect configuration in the telco switch can result in a failure of the loopback call. This can happen when the switch tries to assign the call to the first channel (which is busy making the call). Ask the telco to add both B-channels in a hunt-group. However, for the purpose of this test, we can specify the second B-channel number in the isdn call interface command to work around this issue.

• Perform the loopback call on the other router.

• If the loopback calls succeed, and the call to the remote end continues to fail, you can try a data loopback call to test B-channel data integrity as described in the next section.

For information on how to troubleshoot any issues, refer to these documents:

• ISDN BRI Troubleshooting Flowchart

• Troubleshooting ISDN BRI Layer 3 using the debug isdn q931 Command

Perform a Data Loopback Call

Data Loopback Calls are useful to test whether the B-channels can properly transmit data. In many situations, debug ppp negotiation can continuously fail. This test can be used to check the data integrity on the B-channel.

Note: This test, unlike the previous test, involves a configuration change to the router.

In a Data Loopback Call, we configure two dialer interfaces on the router. The dialer interface is configured with the necessary addressing, authentication and DDR commands to successfully dial out on the BRI line, receive the incoming call, bind to the other dialer interface, and successfully connect.

Create a dialer profile to dial another dialer profile on the same router.

Configure the Router

To configure the router for the loopback call, complete these steps:

1. Save the running configuration with the help of the copy running-config startup-config command. When you do so, you can reboot and restore the running-configuration to the pre-test version after the test is complete.

2. Configure the physical interface.

   Note: This section assumes that you are aware of the necessary ISDN-related information such as, switch-type, and SPIDs.

   interface BRI0
    no ip address
    
   !--- Do not configure an IP address on the physical interface. !--- The IP address will be configured on the dialer. 
   
    encapsulation ppp
    !--- physical interface uses PPP encapsulation
    dialer pool-member 1
    
   !--- Assign BRI0 as member of dialer pool 1. !--- Dialer pool 1 is specified in interface Dialer 1, and !--- interface Dialer 2.
   
    isdn switch-type basic-ni
    isdn spid1 71355511110101 5551111
    isdn spid2 71355511120101 5551112
    
   !--- switch-type and SPID configuration. !--- Contact the telco for this information. 
   
    ppp authentication chap callin   
    
   !--- The physical interface uses CHAP authentication. !--- Authentication is required on the physical interface to bind the !--- incoming call to the right dialer profile.
   
   

3. Configure the first dialer interface:

   interface Dialer1
    ip address 1.1.1.1 255.255.255.0
    
   !--- Assign an IP address to the dialer interface. !--- In this example, the IP addresses for both dialers !--- are in the same subnet.
   
    encapsulation ppp
    
   !--- The dialer interface uses PPP (same as the physical BRI interface).
   
    dialer pool 1
   
    !--- his defines Dialer pool 1. BRI 0 is a member of this pool.
   
    dialer remote-name dialer2
    
   !--- This name must match the name used by the other dialer interface to !--- authenticate itself. Dialer string 7135551112. !--- Phone number for the other B-channel. !--- If your connection only needs one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
    
   !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
   
    !--- Use one-way CHAP authentication. This is sufficient for this test.
   
    ppp chap hostname dialer1
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer1
   
    !--- CHAP Password to be sent out for authentication.
   
   

4. Configure the second dialer interface:

   interface Dialer2
    ip address 1.1.1.2 255.255.255.0
   
    !--- Assign an IP address to the dialer interface. !--- In this example, IP address for both dialers are in the same subnet.
   
    encapsulation ppp
    dialer pool 1
   
    !--- This defines Dialer pool 1. !--- BRI 0 is a member of this pool.
   
    dialer remote-name dialer1
   
    !--- This name must match the name used by the other dialer interface !--- (dialer1) to authenticate itself. Dialer string 7135551111. !--- Phone number for the other B-channel. !--- If your connection only has one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
   
    !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
    ppp chap hostname dialer2
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer2
   
    !--- CHAP Password to be sent out for authentication.
   
   

5. Configure the username and passwords for authentication:

   username dialer1 password 0 dialer1
   username dialer2 password 0 dialer2
   

   The username and passwords are the same as those you configured with the help of the ppp chap hostname and ppp chap password commands under each dialer interface.

6. Configure static routes for clarity:

   ip route 1.1.1.1 255.255.255.255 Dialer1
   
   !--- Note that the route for 1.1.1.1 points to dialer1.
   
   ip route 1.1.1.2 255.255.255.255 Dialer2
   
   !--- Note that the route for 1.1.1.2 points to dialer2. !--- The routes are used to determine which dialer interface is !--- used for dialout.
   
   

   Tip: If you configure the IP addresses for interface Dialer 1 (Step 3) and interface Dialer 2 (Step 4) in separate subnets, the static routes are not necessary.

7. Configure the interesting traffic definition.

   dialer-list 1 protocol ip permit

   Note: the dialer-list number must be the same as the one configured in dialer-group under the dialer interface. In this example, configure dialer-list 1.

8. When the test is complete, reload the router (do not save the configuration) to return to the original configuration used prior to the test.

Initiate the Data Loopback Call

We will now initiate the data loopback call, and look for the successful completion of PPP negotiation. A successful PPP negotiation indicates that the B-channels can properly pass data.

Figure 2 - Initiate the Data Loopback Call

Activate these debugs:

• debug dialer

• debug isdn q931

• debug ppp negotiation

• debug ppp authentication (optional)

Note: When the loopback call is in progress, the router performs as both the Called Router and the Calling Router on different B-channels. It is important that you keep track of these "dual roles" when you interpret the output of the debug isdn q931 and debug ppp negotiation commands. For example, the router transmits a setup message (TX -> SETUP), and receives one too (RX <- SETUP). The transmitted SETUP must be associated with the outgoing call, while the received SETUP message is associated with the incoming call.

Here are the debugs for the back-to-back ISDN call:

router#show debug
Dial on demand:
  Dial on demand events debugging is on
PPP:
  PPP protocol negotiation debugging is on
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 1
  1 -

router#ping 1.1.1.1

!--- Because of the static route entry shown in step 6 above, !--- the call is made out from dialer 1. 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

03:40:41: BR0 DDR: rotor dialout [priority]
03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1)
03:40:41: BR0 DDR: Attempting to dial 7135551112
03:40:41: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x08

!--- Outgoing SETUP message.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x83
03:40:41:         Keypad Facility i = '7135551112'
03:40:41: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x88
03:40:41:         Channel ID i = 0x89
03:40:41: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x2A

!--- Incoming SETUP message on the other B-channel.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x8A
03:40:41:         Signal i = 0x40 - Alerting on - pattern 0
03:40:41:         Called Party Number i = 0xC1, '5551112', Plan:ISDN,
  Type:Subscriber(local)
03:40:41:         Locking Shift to Codeset 5
03:40:41:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
03:40:42: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s

!--- Note that the call comes in on the second B-channel (BRI0:2). !--- Hence the outgoing call must have been on BRI0:1.

03:40:42: ISDN BR0: Event: Accepting the call id 0xB
03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up.
03:40:42: BR0:2 PPP: Treating connection as a callin
03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load]
03:40:42: BR0:2 LCP: State is Listen

!--- PPP LCP negotiations begin. 

03:40:42: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x2A
03:40:42:         Channel ID i = 0x8A
03:40:42:         Signal i = 0x4F - Alerting off
03:40:42: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x88
03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:40:42: BR0:1: interface must be fifo queue, force fifo
03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
03:40:42: BR0:1 PPP: Treating connection as a callout
03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:40:42: BR0:1 PPP: No remote authentication for call-out

!--- One-way authentication (configured with PPP authentication CHAP callin).

03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x08
03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15
03:40:42: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: State is Open
03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15
03:40:43: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:43: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:43: BR0:2 LCP: State is Open
03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]

!--- Authentication begins.

03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: Using alternate hostname dialer1

!--- Use the alternate hostname specified with PPP CHAP hostname !--- under int Dialer 1.

03:40:43: BR0:1 CHAP: Username router not found
03:40:43: BR0:1 CHAP: Using default password
03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1"

!--- Outgoing CHAP response sent on B-channel 1. 

03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1"

!--- Incoming CHAP response seen on B-channel 2.

03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4

!--- Authentication is successful

03:40:43: BR0:2: interface must be fifo queue, force FIFO
03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2

!--- Call (from Dialer 1) is bound to int Dialer 2. !--- This is because the dialer remote-name dialer1 command is !--- configured under int dialer 2. Binding fails when the dialer remote-name !--- command is omitted, or is incorrect, .

03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load]

!--- IPCP negotiation begins.

03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4
03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load]
03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 IPCP: State is Open

!--- IPCP on B-channel 2 is Open.

03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 IPCP: State is Open

!--- IPCP on B-channel 1 is Open.

03:40:43: BR0:2 DDR: dialer protocol up
03:40:43: BR0:1 DDR: dialer protocol up
03:40:43: Di2 IPCP: Install route to 1.1.1.1
03:40:43: Di1 IPCP: Install route to 1.1.1.2
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, 
changed state to up
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, 
changed state to up

!--- Both B-channels are up.

...
Success rate is 0 percent (0/5)
router#

Note: The pings can fail due to issues related to routing. You can expect this. The successful PPP negotiation is the true test of whether the B-channels can properly pass data on the link. If the call fails, contact the telco for further information on how to troubleshoot the line.

Related Information

• ISDN BRI Troubleshooting Flowchart
• Troubleshooting ISDN BRI Layer 3 using the debug isdn q931 Command
• Configuring and Troubleshooting Dialer Profiles
• PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands
• Dial and Access Technology Support
• Technical Support & Documentation - Cisco Systems