Using DDR with Access Lists

You can use access lists to be more specific about what is interesting traffic. In the preceding
examples, we set the dialer list to allow any IP traffic to bring up the line and keep it up.
That’s great if you are testing, but it can defeat the purpose of why you use a DDR line in
the first place. You can use extended access lists to set the restriction, for example, to only
e-mail or Telnet.
Here is an example of how you define the dialer list to use an extended access list:
804A(config)#dialer-list 1 protocol ip list 110
804A(config)#access-list 110 permit tcp any any eq smtp
804A(config)#access-list 110 permit tcp any any eq telnet
804A(config)#int bri0
804A(config-if)#dialer-group 1
In the previous example, you configure the dialer-list command to look at an IP extended
access list. This doesn’t have to be IP; it can be used with any protocol. Create your dialer list and
then apply it to the BRI interface with the dialer-group command.
889

Using Optional Commands

You should configure two other commands on your BRI interface: dialer load-threshold
and dialer idle-timeout. The dialer load-threshold command is used in conjunction
with the ppp multilink command for multilink PPP (MPPP).
The dialer load-threshold command tells the BRI interface when to bring up the second
B channel. The value specified is from 1–255, where 255 tells the BRI to bring up the second B
channel only when the first channel is 100 percent loaded. The second option for that command
Dial-on-Demand Routing (DDR) 847
is in, out, or either. This calculates the actual load on the interface either on outbound traffic,
inbound traffic, or either inbound or outbound traffic. The default is outbound.
The dialer idle-timeout command specifies the number of seconds to wait for interesting
traffic before a call is disconnected. The default is 120 seconds.
RouterA(config-if)#dialer load-threshold 127 either
RouterA(config-if)#dialer idle-timeout 180
The dialer load-threshold 127 command tells the BRI interface to bring up the second B
channel if either the inbound or outbound traffic load is 50 percent. The dialer idle-timeout
180 command changes the default disconnect time from 120 to 180 seconds.
MPPP allows load-balancing between two or more B channels on a BRI or PRI interface. It is
non-vendor-specific and provides packet fragmentation and reassembly, along with sequencing
and load-calculating. Cisco’s MPPP is based on RFC 1990, which is referred to as PPP Multilink
Protocol (MP). The configuration would then look like this:
RouterA(config)#int BRI0
RouterA(config-if)#dialer load-threshold 127 either
RouterA(config-if)#dialer idle-timeout 180
RouterA(config-if)#ppp multilink
Not a tough configuration, but you should use it nonetheless. The ppp multilink command will
fragment packets and send them over both lines, which provides a load-balancing effect on the data
being sent over the link. You can verify that the Multilink Protocol is working by using the show ppp
multilink command.

Configuring the Dialer Information

There are five steps in the configuration of dialer information:
1. Choose the interface.
2. Set the IP address.
Dial-on-Demand Routing (DDR) 845
3. Configure the encapsulation type.
4. Link interesting traffic to the interface.
5. Configure the number or numbers to dial.
Here is an example of how to configure the five steps:
804A#config t
804A(config)#interface bri0
804A(config-if)#ip address 172.16.60.1 255.255.255.0
804A(config-if)#no shutdown
804A(config-if)#encapsulation ppp
804A(config-if)#dialer-group 1
804A(config-if)#dialer string 8358662
Instead of the dialer string command, you can use a dialer map command, which
provides more security:
804A(config-if)#dialer map ip 172.16.60.2 name 804B 8358662
The dialer map command is used to configure the IP address of the next hop router, the
name of the remote router for authentication, and the number to dial to get there. The name is
usually the host name of the remote router, but it must be the name used by the remote router
to identify itself.
Take a look at the following configuration of an 804 router:
804B#show run
Building configuration...
Current configuration:
!
version 12.0
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 804B
!
ip subnet-zero
!
isdn switch-type basic-ni
!
interface Ethernet0
ip address 172.16.50.10 255.255.255.0
846 Chapter 26  Integrated Services Digital Network (ISDN)
no ip directed-broadcast
!
interface BRI0
ip address 172.16.60.2 255.255.255.0
no ip directed-broadcast
encapsulation ppp
dialer idle-timeout 300
dialer string 8358661
dialer load-threshold 2 either
dialer-group 1
isdn switch-type basic-ni
isdn spid1 0835866201 8358662
isdn spid2 0835866401 8358664
dialer hold-queue 75
ppp multilink
!
ip classless
ip route 172.16.30.0 255.255.255.0 172.16.60.1
ip route 172.16.60.1 255.255.255.255 BRI0
!
dialer-list 1 protocol ip permit
!
The BRI interface is running the PPP encapsulation and has a timeout value of 300 seconds,
which is discussed in the next section. The load-threshold command makes both
BRI channels come up immediately (if you are paying for both, you want them both up all
the time) and is used with multilink, which we will discuss later in this section. The one
thing you should really notice is the number in the dialer-group 1 command. That number
must match the number in the dialer-list command, which is used to define what is
interesting traffic. The dialer hold-queue 75 command tells the router that when it
receives an interesting packet, it should queue up to 75 packets while it is waiting for the
BRI to come up. If more than 75 packets are queued before the link comes up, the packets
beyond the 75 will be dropped.

Specifying Interesting Traffic

After setting the route tables in each router, you need to configure the router to determine what
brings up the ISDN line. An administrator uses the dialer-list global configuration command
to define what is interesting traffic.
The command to configure all IP traffic as interesting is as follows:
804A(config)#dialer-list 1 protocol ip permit
804A(config)#interface bri0
804A(config-if)#dialer-group 1
The dialer-group command associates a dialer list to the BRI interface. Extended access
lists can be used with the dialer-list command to define exactly which traffic is interesting.
We’ll cover that in a minute.

Configuring the Static Routes

To forward traffic across the ISDN link, you configure static routes in each of the routers. The suggested
routing method is static routes. Keep the following in mind when creating static routes:
 All participating routers must have static routes defining all routes of known networks.
 Default routing can be used if the network is a stub network.
An example of static routing with ISDN follows:
RouterA(config)#ip route 172.16.50.0 255.255.255.0 172.16.60.2
RouterA(config)#ip route 172.16.60.2 255.255.255.255 bri0
What this does is tell the router how to get to network 172.16.50.0, which is through
172.16.60.2. The second line tells the router how to get to host address 172.16.60.2 and to send
traffic out the BRI0 interface.

Configuring DDR

To configure legacy DDR, you need to perform three tasks:
 Define static routes, which define how to get to the remote networks and which interface
to use to get there.
 Specify the traffic that is considered interesting to the router.
 Configure the dialer information that will be used to dial the interface to get to the remote
network.

Dial-on-Demand Routing (DDR)

Dial-on-demand routing (DDR) enables two Cisco routers to use a dial-up connection on an
as-needed basis and is usually used as a backup solution in case of WAN circuit failure. DDR
is used only for low-volume, periodic network connections using either a PSTN asynchronous
or ISDN link. This was designed to reduce WAN costs if you have to pay on a per-minute or
per-packet basis.
Other terms you will undoubtedly run into are Legacy DDR Spoke configuration and Legacy
DDR Hub configuration. These terms are pretty simple to understand. A spoke interface
is any interface that calls or receives calls from exactly one other router. A hub, on the other
hand, calls or receives calls from more than one other router. Both configurations are similar
in theory, except that the hub is configured to call multiple locations.
DDR works when a packet received on an interface meets the requirements of an administratordefined
access list, which defines interesting traffic. The following seven steps give a basic description
of how DDR works when an interesting packet is received in a router interface:
1. The route to the destination network is determined.
2. Interesting packets dictate a DDR call.
3. Dialer information is looked up.
4. The call is placed.
5. The connection is established.
6. Traffic is transmitted.
7. The call is terminated when no more interesting traffic is being transmitted over a link and
the idle-timeout period ends.

The CHAP Authentication Process

The authentication process between two routers occurs as follows:
1. Challenger sends a Challenge (Type 1) packet to the remote end.
2. The remote end copies the identifier into a new packet and into a Response (Type 2) packet
along with the hashed secret. The secret (the password) isn’t transmitted, only the hashed value.
3. The Challenger receives the Response packet and checks the hashed secret against its
hashed secret. If they match, it sends a Success (Type 3) packet back. Otherwise, it’ll send
a Failure (Type 4) packet back.
Challenge and Response packets have the following fields:
Code Eight bits; value of 1 for Challenge, or 2 for Response.
Identifier Eight bits; must be changed every time a challenge is sent.
Value-Size Eight bits; indicates the length of the Value field.
Value Variable (eight-bit minimum). The field is quite different depending on a Challenge or
Response. The Challenge value contains the challenge and is a variable stream of octets. The
Challenge value must be changed each time a Challenge is sent. The length of the Challenge
value depends on the method used to generate the octets and is independent of the hash algorithm
used.
The Response value is the one-way hashed response calculated over a stream of octets consisting
of the Identifier, followed by (concatenated with) the “secret,” followed by (concatenated with)
the Challenge value. The length of the Response value depends on the hash algorithm used (16
octets for MD5).
Name Variable (eight-bit minimum); identifies the system transmitting the packet.
Success (3) and Failure (4) packets have these fields:
 CodeIdentifier (which is copied from Response)
 Length
 Message
The Message field is one or more octets long and contains information that is readable by
humans. By using the debug ppp authentication command, you can see each step that is
taken with the CHAP Challenge and Response fields:
BR0:1 PPP: Treating connection as a callout
BR0:1 PPP: Phase is AUTHENTICATING, by both
BR0:1 CHAP: O CHALLENGE id 1 len 23 from "r2"
BR0:1 CHAP: I CHALLENGE id 1 len 23 from "r3"
BR0:1 CHAP: O RESPONSE id 1 len 23 from "r2"
BR0:1 CHAP: I SUCCESS id 1 len 4
BR0:1 CHAP: I RESPONSE id 1 len 23 from "r3"
BR0:1 CHAP: O SUCCESS id 1 len 4
Figure 26.9 shows the CHAP authentication process.

CHAP Challenge packet

A CHAP packet consists of an 8-bit Code field, an 8-bit Identifier field, a 16-bit Length field,
and a variable-length Data field. The Code field identifies the type of CHAP packet; there are
four type options:
 Challenge
 Response
 Success
 Failure
The Identifier field contains an incrementally changing identifier, which the remote end copies
into the response packet. Frequently changing the identifier provides protection against a playback
attack. The Length field is 16 bits long and indicates the length of the CHAP packet, including the
Code, Identifier, Length, and Data fields. Octets outside the range will be ignored. The Data field is
zero or more octets and is determined by the Code field.
Configuring CHAP authentication is a pretty straightforward process. Here’s an example:
Router#config t
Router(config)#username todd password cisco
Router(config)#interface bri0
Router(config-if)#encapsulation ppp
Router(config-if)#ppp authentication chap
Router(config-if)#^Z
Router#
The username name password password command is used to configure authentication
between two routers. The username is the host name of the router you want to connect to. The
passwords must be the same on each side for this to work. For example, if you had a corporate
router with a host name of Acmecorporate and a remote router with a host name of Acmeremote,
the configuration of the corporate router would look like this:
Acmecorporate(config)#username Acmeremote password sameone
The remote router’s configuration would be this:
Acmeremote(config)#username Acmecorporate password sameone
Code Identifier Length
Data

Challenge Handshake Authentication Protocol (CHAP)

CHAP is used to periodically verify the identity of the remote peer by using a three-way handshake.
Normally this occurs immediately after the initial link establishment and before proceeding
to the Network layer phase. CHAP can also send a new challenge periodically to verify the
remote node. All PPP authentications are optional. Both ends must be configured with the same
authentication type if you are using authentication.
One CHAP packet is encapsulated in the Information field of a PPP packet, with the Type
field set to 3, the Length field to 5, the Authentication-Protocol field to c223, and the algorithm
to 5 (MD5). A CHAP Challenge packet is illustrated in Figure 26.8.

PAP authentication

Authenticate-Request
Authenticate-Ack or
Authenticate-Nak

Configuring PAP authentication is a pretty straightforward process. Here’s an example:

Router#config t

Router(config)#username todd password cisco
Router(config)#interface bri0
Router(config-if)#encapsulation ppp
Router(config-if)#ppp authentication pap
Router(config-if)#^Z
Router#

Authenticate-Request Packets

An Authenticate-Request packet is sent by the calling party to the called party. The Data field
has four fields:
Peer-ID length Eight bits long; indicates the length of the Peer-ID.
Peer-ID Zero or more octets long; contains the username.
Passwd-length Eight bits long; indicates the length of the password.
Password Zero or more octets long; contains the cleartext password.
The called end will respond with either an Authenticate-Ack (Type 2) or Authenticate-Nak
(Type 3) packet. Both packets have two fields as data. One is Msg-Length (8 bits), and the other
is Message (one or more octets).

The following output is from a debug ppp authentication command on a router that is
authenticating by using PAP with PPP:
BR0/0:1 PPP: Phase is AUTHENTICATING, by the peer
BR0/0:1 PAP: O AUTH-REQ id 3 len 14 from "r3"
BR0/0:1 PAP: I AUTH-ACK id 3 len 5
You can follow this debug PPP authentication router output by referring to Figure 26.7.

PAP Packets

A PAP packet has four fields carried one at a time in the PPP Information field: Code, Identifier,
Length, and Data.
The Code field is 8 bits long and can have one of three values:
 Authenticate-Request
 Authenticate-Ack
 Authenticate-Nak
The Identifier field is also 8 bits long and is used for matching authentication requests and
replies. It changes every time an Authenticate-Request is sent.
Length is a 16-bit field indicating the packet’s length.
The Data field varies in length and format, depending on the packet type: Request, Ack, or Nak.

Password Authentication Protocol (PAP)

PAP uses a two-way handshake to establish the identity of the remote peer. This simple authentication
protocol does not encrypt the username or password, making it somewhat insecure and
subject to a playback attack. Because of this security problem, it is recommended that you use
CHAP authentication instead.
After the PPP link establishment, the optional Authentication-Protocol Configuration
Option packet is sent. An Authentication-Protocol Configuration Option packet for PAP has
three fields: Type, Length, and Authentication-Protocol. The Type field is 8 bits long with a
value of 3, Length is 8 bits long with a value of 4, and Authentication-Protocol is 16 bits long
with a value of c023.

Authentication

If you are using PPP encapsulation, you can also use authentication. Authentication enables you
to verify who is connected to a service. Note that this is optional and not required in any ISDN
configurations.

The two authentication choices are Password Authentication Protocol (PAP) and Challenge
Handshake Authentication Protocol (CHAP). CHAP is preferred over PAP because of its superior
security features. CHAP and PAP are covered in greater detail in Chapter 24, “Point-to-
Point Protocol,” of this book.

Using a Dialer Interface

Using a dialer interface solves the primary IP address/secondary IP address problem because
each interface can be assigned its own primary address. The dialer map command does not
have to be used because each interface has its own IP address and dial number configured by
using the dialer string command.
A virtual interface must be associated with a dialer pool. The dialer pool is a group of one
or more physical interfaces in charge of placing calls. Here’s an example of a configuration
using dialer interfaces:
hostname R1
!
isdn switch-type basic-5ess
!
interface Ethernet0
ip address 192.168.1.1 255.255.255.0
!
interface Serial0/0:23
no ip address
encapsulation ppp
dialer pool-member 1 priority 100
!
interface Dialer1
ip address 192.168.250.1 255.255.255.0
encapsulation ppp
dialer remote-name R2
dialer idle-timeout 300
dialer string 5551212
dialer load-threshold 50 either
dialer pool 1
dialer-group 1
!

interface Dialer2
ip address 192.168.251.1 255.255.255.0
encapsulation ppp
dialer remote-name R3
dialer string 5551234
dialer load-threshold 150 either
dialer pool 1
dialer-group 1
!
router ospf 100
network 192.168.250.1 0.0.0.0 area 0
network 192.168.251.1 0.0.0.0 area 0
!
dialer-list 1 protocol ip permit
!
end
Notice how the interface Dialer1 creates a virtual interface with the correct configuration—
ip address, encapsulation, and dialer string—the same items that were bound to the
physical interface BRI0 in the first example. The interface Dialer carries a 1 as its index. The virtual
Dialer interface is then bound to a dialer string that references the ISDN DN. The dialer
pool 1 is then bound to the virtual Dialer to point to the physical interface that will be carrying
out the dialing. The index of the dialer pool 1 maps to the dialer pool-member 1—the physical
interface of Serial 0/0. The last configuration command worthy of noting is the dialerlist
1 protocol ip permit, which tells the router what traffic is interesting and to bring the
connection up when interesting traffic is identified.
OSPF will work properly because the source address on both sides of the link matches the network
statement. The source address of a packet originating at a router is the primary address on
the outgoing interface. Dialer interfaces are easy to configure. Consider the following example:
router#config t
router(config)#interface dialer 2
router(config-if)#
Now the network administrator can create the configuration as you would under a physical
interface. The physical PRI interface—Serial0/0:23—is designated as a member of a dialer pool
using the dialer pool-member command.

Using a Legacy Interface

To get your feet wet, let’s start with a simple BRI configuration:
hostname R1
isdn switch-type basic-ni
!
interface BRI0
ip address 10.1.1.3 255.255.255.0
encapsulation ppp
isdn spid1 91955512120100 5551212
dialer map ip 10.1.1.1 name R2 555-1212
As you can see, the first statement defines the switch type. The BRI0 interface binds an IP address
and sets up PPP as the encapsulation type. The last two lines identify the SPID and the dialer map
command. These set the protocol with a next-hop address of 10./1.1.1, identify the remote host as
R2, and indicate that the dial string (telephone number) should be sent to the dialing device when
it the device recognizes packets that have specified addresses matching the configured access lists.
Under the old legacy way, you could have a main IP address under the physical interface,
along with several secondary addresses. This worked fine, but you ran into problems if you were
using a routing protocol, because the physical interface always uses its primary address when
sending out packets.

Here’s an example of a configuration using the old way. Notice the dialer map statements.
This enabled an administrator to tell the router which number to dial based on the destination
IP address in packets it received on one of the router’s incoming interfaces. See for yourself:
hostname R1
!
interface Serial 0/0:23
encapsulation ppp
ip address 192.168.250.1 255.255.255.0
ip address 192.168.251.1 255.255.255.0 secondary
dialer map ip 192.168.250.2 name R2 555-1212
dialer map ip 192.168.251.2 name R3 555-1234
router ospf 100
network 192.168.250.1 0.0.0.0 area 0
network 192.168.251.1 0.0.0.0 area 0
!
end
hostname R2
!
interface BRI0
ip address 192.168.250.2 255.255.255.0
encapsulation ppp
isdn spid1 91955512120100 5551212
isdn spid2 91955512130100 5551213
dialer map ip 192.168.250.1 name R1 5551900
router ospf 100
network 192.168.250.2 0.0.0.0 area 0
!
end
hostname R3
!
interface BRI0
ip address 192.168.251.2 255.255.255.0
encapsulation ppp
isdn spid1 91955512230100 5551234
isdn spid2 91955512350100 5551235
dialer map ip 192.168.251.1 name R1 5551900
router ospf 100
network 192.168.251.2 0.0.0.0 area 0
!
end


You need to look at several points in this configuration. Host R1 is using a PRI ISDN interface
on Serial 0/0. The secondary command enables you to have a second route on the same
interface. We cover the Serial 0/0:23 command later in this chapter, but a quick explanation
is that for ISDN, the D channel time slot is equivalent to the :23 channel for channelized T-1.
And finally, we are using the dialer map to bind an IP address to an ISDN DN.
In these router configurations, both routers R2 and R3 will call into R1, but Open Shortest
Path First (OSPF) will work only between R1 and R2, because R2 uses the primary address on
R1, whereas R3 uses the secondary. This source IP address issue can be a real problem, but only
if you’re not aware of it. What is the solution to the primary IP address issue? Dialer interfaces.

ISDN Configuration

To configure ISDN, you need to understand that there are both simple and complex configurations.
Although you certainly can make more money by understanding the complex configurations, the
simple ones are just as important. In this section, you will look at some benefits and drawbacks of
two ISDN configuration types: PRI and BRI. In this section you will learn about the differences
between the PRI and BRI interface configurations. First, though, you need to understand how the
old and new ways differ.


How to Order ISDN
Okay, we know this is a CCNP Study Guide and you are probably getting ready for the test, but
after you are certified (or certifiable), you are the Cisco expert and should know the process of
attaining as well as configuring the lines. Here’s what you do:
Who Do I Call?
The first step to getting your ISDN service up and running is to contact your local telephone
company (service provider). The telephone numbers and web addresses for ordering ISDN service
are provided at http://www.nationalisdncouncil.com.
What Do I Need to Tell the Telephone Company?
Ordering ISDN can be as easy as requesting basic phone service from the telephone company;
most of the questions that the telephone company will ask you are the same in both
cases. For example, because ISDN was designed to work over the existing wire, which supports
your current telephone service, you will probably not have to specify any unique wiring
changes or additions. However, some specialized capabilities of ISDN will require you
to provide additional information related to your ISDN equipment selection. The best
way to provide this additional information is through an ISDN Ordering Code (IOC), or as
Cisco calls them, the capabilities package ordering codes, which should be identified in
your ISDN equipment documentation. This will give you a set of standardized BRI line
features that simplify the process of configuring an ISDN line that is connected to an NI1
switch. An example is the package R, which provides circuit-switched data on both B channels
(no voice capabilities). Data capabilities include calling number identification. Cisco
recommends this NI1 capability package for Cisco 801 and Cisco 802 routers.
What Does the Phone Company Need to Tell Me?
Most ISDN connections in North America require the use of one or more service profile identifiers
(SPIDs), which we discussed earlier in this chapter. SPIDs are numbers assigned only by

North American telephone service providers. SPIDS identify the ISDN B channels. As stated
earlier, the SPID format is generally an ISDN telephone number with several numbers added to
it, for example, 40855512340101. Depending on the switch type that supports your ISDN BRI
line, your ISDN line could be assigned none, one, or two SPIDs.
And that’s it. The configuration of and use of this information is covered in the context of
this chapter.

Some of you might have grown up in a router world, where you used dialer map statements
to configure a dial session. But the times they are a-changin’, and actually for the better. By
using a dialer profile, the basic configuration for a physical interface is entered under the actual
interface, but the detailed configuration is placed under a virtual dialer interface. This is a really
good feature if you have a PRI that receives and makes calls to and from different locations
(with different subnets).

Debug ISDN Q.931 Details

Output Meaning
TX -> The message originating at the router.
RX <- The message received from the network.
SETUP Used to initiate a call. Either the network or the local router
can send it.
pd = 8 Indicates the protocol discriminator. The protocol discriminator
distinguishes messages for call control over the usernetwork
ISDN interface from other ITU-T-defined messages,
including other Q.931 messages.
Callref = 0x05 Indicates the number of calls the router has processed. It
increments every time a call goes out or comes in.
Bearer Capability i = 0x8890 The bearer service requested by the router.
88 = ITU coding standard, unrestricted digital information
90 = Circuit mode, 64Kbps
21 = Layer 1, V.110/X.30
8F = Synchronous, no in-band negotiation, 56Kbps
Channel ID i = 0x83 The channel Identifier. It indicates which B channel to use.
83 = Use any channel.
89 = Use B1.
8A = Use B2.
Keypad facility Also known as called party number.
DISCONNECT pd = 8 callref =
0x05 Cause i = 0x8090 - Normal
call clearing
The router is sending a DISCONNECT message to the network.
The reason for this disconnect is Normal call clearing
0x80. See “ISDN Switch Types, Codes, and Values” on Cisco
Connection Online (CCO) at www.cisco.com.

ISDN Call Setup and Teardown-ISDN call setup and teardown

ISDN uses ITU-T Q.931 to establish and tear down calls. Call control and signaling information
is carried over the D channel. Figure 26.6 shows the Q.931 procedures.

ISDN call setup and teardown


Setup
Call Proceeding
Alerting
Setup
Disconnect Disconnect
Release
Alerting
>Ring<
Connect Connect
Connect Acknowledge Connect Acknowledge
Release Complete
A B
Call Proceeding
>Pickup<
Release
Release Complete

The process for ISDN call setup and teardown is as follows:
1. First, a SETUP message is sent from device A. The SETUP contains information necessary
to make the call.
2. Next, the switch sends a CALL PROCEEDING back to device A.
3. An ALERTING message is sent back when device B is contacted. You might hear the phone
ring at this point.
4. CONNECT and CONNECT ACKNOWLEDGE messages are sent to indicate that the call
has been accepted.
5. Call teardown starts when one of the users hangs up. Here, device A hangs up, and a
DISCONNECT message is sent to device B. The switch now disconnects B and sends a
RELEASE to A. A RELEASE COMPLETE message confirms the process.
Using the debug isdn q931 command, you get the following output.
ISDN BR0: TX -> SETUP pd = 8 callref = 0x05 _
Bearer Capability i = 0x8890 Channel ID i = 0x83
Keypad Facility i = '8358662'
ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x85 _

Channel ID i = 0x89 Locking Shift to Codeset 5
Codeset 5 IE 0x2A i = 0x809402, '`=', 0x8307, _
'8358662', 0x8E0B, ' TELTONE 2 '
ISDN BR0: RX <- CONNECT pd = 8 callref = 0x85
ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x05
ISDN BR0: TX -> DISCONNECT pd = 8 callref = 0x05 _
Cause i = 0x8090 - Normal call clearing
ISDN BR0: RX <- RELEASE pd = 8 callref = 0x85
ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0x05
Table 26.8 describes the output from the Q.931 command.

Debug ISDN Q.921 Details

Output Meaning
ISDN BR0: This is the interface.
TX -> This router is sending this information.
RX <- This router is receiving this information.
SABME Indicates the Set Asynchronous Balanced Mode Extended command.
This command places the recipient into modulo 128 multiple
frame acknowledged operation. This command also indicates
that all exception conditions have been cleared.
sapi Identifies the service access point at which the Data-Link layer
entity provides services to layer 3 or to the management layer. A
SAPI with the value 0 indicates it is a call control procedure.
IDCKRQ ri = 0 ai = 127 Indicates the Identity Check Request message type sent from the
ISDN service provider on the network to the local router during
the TEI check procedure. This message is sent in a UI command
frame. The ri field is always 0. The ai field for this message contains
either a specific TEI value for the local router to check or 127,
which indicates that the local router should check all TEI values.

IDREM This indicates the Identity Remove message type sent from the
network to the user-side layer management entity during the TEI
removal procedure. This message is sent in a UI command frame.
The message includes a reference number that is always 0, because
it is not responding to a request from the local router. It is sent twice
by the network to prevent a lost message.
IDCKRP Indicates the Identity Check Response message type sent from
the local router to the ISDN service provider on the network during
the TEI check procedure. This message is sent in a UI command
frame in response to the IDCKRQ message
IDREQ This indicates an Identity Request message sent from the local
router to the network during the automatic TEI assignment.
UAf This confirms that the network side has accepted the SABME command
previously sent by the local router. The final bit is set to 1.
INFOc This is an information command. It is used to transfer sequentially
numbered frames containing Information Fields cap provided
by layer 3.
IDASSN This indicates an Identity Assigned message type sent from the
network’s ISDN service provider to the local router during the
automatic TEI assignment procedure.
RRx This indicates Receive Ready. If x = r, it is responding to an
INFOc. If x = p, the router is polling the network side. And x = f
means the network side has responded to the poll and the final
bit is set.

Now what does everything in Table 26.7 mean? According to the output, the router attempts
to establish a connection with the switch, using legacy TEI information that it has left over:
ISDN BR0: TX -> SABMEp sapi = 0 tei = 77
The service provider’s switch disapproves of this and orders a check of the router’s current TEIs
with the IDCKRQ message. The ai of 127 (broadcast) simply tells the router that the switch
would like for it to check all TEIs it currently has registered:
ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127

The router promptly returns an IDCKRP message for each TEI it finds within itself. In this case,
these are 77 and 78:
ISDN BR0: TX -> IDCKRP ri = 44602 ai = 77
ISDN BR0: TX -> IDCKRP ri = 37339 ai = 78
The switch does not want the router to continue using these TEIs, so it issues an IDREM message
for each offending TEI. This tells the router to forget about these TEIs:
ISDN BR0: RX <- IDREM ri = 0 ai = 77
The router quickly throws itself at the mercy of the switch by sending the IDREQ message with
an ai of 127. Notice that the router is looking for two TEIs, one for each logical B channel interface
within BRI0, but it has to issue four IDREQs to overcome the timeouts:
ISDN BR0: TX -> IDREQ ri = 43085 ai = 127
ISDN BR0: TX -> IDREQ ri = 11550 ai = 127
As soon as an IDASSN returns that matches the ri of one of the IDREQs, as follows:
ISDN BR0: RX <- IDASSN ri = 11550 ai = 79
the router turns around and establishes service with a new SABME message, using the new TEI:
ISDN BR0: TX -> SABMEp sapi = 0 tei = 79
ISDN BR0: TX -> IDREQ ri = 65279 ai = 127
Because the switch obviously approves of this TEI, it responds with the UA message the router
was originally looking for.
ISDN BR0: RX <- UAf sapi = 0 tei = 79
After the UAs come in, the whole INFO/RR exchange for layer 3 information begins for each
TEI assigned:
ISDN BR0: TX -> INFOc sapi = 0 tei = 79 ns = 0 nr = 0 i =
➥0x08007B3A0A30383335383636313031
ISDN BR0: TX -> RRr sapi = 0 tei = 79 nr = 1
This occurs for both the 79 and 80 TEIs.

Layer 2 Negotiation

You need to have an understanding of the LAPD frame before you understand how layer 2
negotiates. This will help you identify where a potential or existing problem is occurring. One
useful feature of Cisco equipment is that it includes good diagnostic tools for finding ISDN
problems. Knowing which side of the ISDN connection does what will help you identify a problem
and start corrective action.
The first part of the process is TEI assignment, which is accomplished by using this process:
1. The terminal endpoint (TE) and the network initially exchange Receive Ready (RR) frames,
listening for an initiated connection.
2. The TE sends an Unnumbered Information (UI) frame with a SAPI of 63 (management procedure,
query network) and TEI of 127 (broadcast).
3. The network assigns an available TEI (in the range 64–126).
4. The TE sends a Set Asynchronous Balanced Mode Extended (SABME) frame with a SAPI
of 0 (call control, used to initiate a SETUP) and a TEI of the value assigned by the network.
5. The network responds with an Unnumbered Acknowledgment (UA); SAPI = 0, TEI = assigned.
As you examine this partial output from the command debug isdn q921, please refer to
Table 26.7, which explains the meaning of the output.

ISDN BR0: TX -> SABMEp sapi = 0 tei = 77
ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127
ISDN BR0: TX -> IDCKRP ri = 44602 ai = 77
ISDN BR0: TX -> IDCKRP ri = 37339 ai = 78
ISDN BR0: RX <- IDREM ri = 0 ai = 77
ISDN BR0: TX -> IDREQ ri = 44940 ai = 127
ISDN BR0: RX <- IDREM ri = 0 ai = 78

ISDN BR0: TX -> IDREQ ri = 43085 ai = 127
ISDN BR0: TX -> IDREQ ri = 11550 ai = 127
ISDN BR0: RX <- IDASSN ri = 11550 ai = 79
ISDN BR0: TX -> SABMEp sapi = 0 tei = 79
ISDN BR0: TX -> IDREQ ri = 65279 ai = 127
ISDN BR0: RX <- UAf sapi = 0 tei = 79
ISDN BR0: TX -> INFOc sapi = 0 tei = 79 ns = 0
➥nr = 0 i = 0x08007B3A0A30383335383636313031
ISDN BR0: RX <- IDASSN ri = 65279 ai = 80
ISDN BR0: TX -> SABMEp sapi = 0 tei = 80
ISDN BR0: RX <- INFOc sapi = 0 tei = 79 ns = 0 nr = 1 i =
➥0x08007B3B028181
ISDN BR0: TX -> RRr sapi = 0 tei = 79 nr = 1
ISDN BR0: RX <- UAf sapi = 0 tei = 80
ISDN BR0: TX -> INFOc sapi = 0 tei = 80 ns = 0 _
nr = 0 i = 0x08007B3A0A30383335383636333031
ISDN BR0: RX <- INFOc sapi = 0 tei = 80 ns = 0 nr = 1 i =
➥0x08007B3B028381
ISDN BR0: TX -> RRr sapi = 0 tei = 80 nr = 1

Control Field Values

Format Message Type Control/Response
Information Transfer I = Information Control
Supervisory RR = Receive Ready Control/Response
Supervisory RNR = Receive Not Ready Control/Response
Supervisory REJ = Reject Control/Response
Unnumbered SABME = Set Asynchronous Balanced
Mode Extended
Control
Unnumbered DM = Disconnected Mode Response
Unnumbered UI = Unnumbered Information Control
Unnumbered DISC = Disconnect Control
Unnumbered UA = Unnumbered Acknowledgment Response
Unnumbered FRMR = Frame Reject Response
Unnumbered XID = Exchange Identifier Control/Response

Information This field carries the Q.931 protocol data. Figure 26.5 illustrates how it is laid
out. This is where the user data is carried.
The following information describes the field format as shown in Figure 26.5:
Protocol discriminator One octet. Identifies the layer 3 protocol.
Length One octet. Indicates the length of the call reference value (CRV).
Call reference value (CRV) One or two octets. This value is assigned to each call at the beginning,
is used to distinguish between other simultaneous calls, and is released after the call is torn down.
Message type One octet.
Mandatory and optional information elements (variable length) Options based on the message
type.
CRC Contains the cyclic redundancy check derived value from the Address, Control, and
Information fields. This is also known as the frame check sequence (FCS) field.

Q.921/Q.931 Information field format

Information Field
1
Protocol Discriminator
0
Call Reference Value (1 or 2 octets)
0
2 3 4 5
0 0 0 Length of CRV
6 7 8
Message Type (SETUP, CONNECT, etc.)
Mandatory and Optional Information Elements (Variable)

LAPD Frames

While the ISDN protocols define the transfer of information, layer 2 and 3 functions are handled
with LAPD. Understanding the information contained in this frame will help you understand
Q.921 and Q.931 debug outputs. Remember that LAPD is the framing protocol used for D channel
data and that the D channel is used to build connections to an ISDN link.
An LAPD frame has six parts to it: Flag, Address, Control, Information, CRC, and a final
Flag. Figure 26.4 shows the LAPD frame and the fields within the frame.
The following information describes the fields within the LAPD frame:
Flag This one-octet field starts and ends the frame with a value of 7E (0111 1110). The LAPD Flag
and Control fields are identical to those of HDLC.
FIGURE 2 6 . 4 Link Access Procedure, Data frame
Flag Address Control Information CRC Flag

Address This field is two octets long and contains some important information. This field identifies
the TE using this link and has four parts: service access point identifier (SAPI), command/
response (C/R), address extension 0 (AE0), and terminal endpoint identifier (TEI).
Service access point identifier (SAPI) This field is six bits long. Table 26.4 shows the SAPI
values that can be used in an LAPD frame.
Command/response (C/R) This field is one bit long. This bit identifies the frame as either a
command or a response. The user side always sends commands with this bit set to 0 and responds
with it set to 1. The network side is the exact opposite, sending a command with this bit set to 1,
or a 0 if it is responding.
Address extension 0 (AE0 and AE1) These are one bit long. Their value indicates whether the
associated octet is the last in the Address field. Setting the value to 1 in the last bit of an address
octet (the AE field) indicates to the receiving device that this is the last octet in the Address field.
Terminal endpoint identifier (TEI) These values uniquely identify each TE on an ISDN S/T bus.
A TEI can be either dynamically or statically assigned. Table 26.5 lists the values for this field.
TABLE 2 6 . 4 SAPI Values
SAPI Description
0 Call control procedures
1 Packet mode using Q.931 call procedures
16 Packet mode communications procedures
32–47 Reserved for national use
63 Management procedures
Others Reserved for future use
TABLE 2 6 . 5 Terminal Endpoint Identifier (TEI) Values
TEI Description
0–63 Fixed TEI assignments
64–126 Dynamically assigned (assigned by the switch)
127 Broadcast to all devices
Control This field has 11 available values, each one listed in Table 26.6, along with its application.
You will see one of three types of information here: Information Transfer, Supervisory,
or Unnumbered.

ISDN Protocols

ISDN protocols define how information is transferred from one device to another in the network.
The ITU-T has established three types of protocols to handle this information transfer:
 Protocols beginning with the letter E specify ISDN on the existing telephone network.
 Protocols beginning with the letter I specify concepts, terminology, and services.
 Protocols beginning with the letter Q specify switching and signaling. Two Q standards of
interest are Q.921, which handles layer 2, and Q.931, which deals with layer 3 interfacing.
Spending some time reviewing the Q standards will help you use a couple of the IOS debug
commands covered later in this chapter. As just stated, the ITU-T recommendations Q.921 and
Q.931 handle switching and signaling. Q.921 uses Link Access Procedure, Data (LAPD) to communicate
with other ISDN devices across the D channel. LAPD’s primary purpose is to transport
signaling information.

ISDN Reference Points

A
reference point
defines a connection point between two functions; you can also refer to it as
an interface, though it does not represent an actual physical interface. The reference point is
where data is converted between device types. Figure 26.3 shows the reference points defined
in an ISDN network.
The reference points shown in Figure 26.3 are described in detail in the following list:
R reference point
The R reference point defines the point between non-ISDN equipment and a
TA. It enables a non-ISDN device to appear on the network as an ISDN device. Unlike the others,
this is a nonstandardized reference because it is dependent on the TE2 equipment’s interface.
S reference point
The S reference point is the point between the user terminals and NT2 or, in
other words, between a TE1 or a TA and the network termination (which is either an NT1 or NT2).

ISDN reference points
U
U
TA NT1
NT1
ISDN switch
service
Router with
built-in NT1
ISDN
device (TE1)

T reference point
The T reference point defines the point between NT1 and NT2 devices.
S/T interface
As the name implies, the S/T interface combines both the S and T interfaces. This
interface is governed by the ITU I.430 standard, which defines the connection as a 4-wire connection.
The S/T interface is typically an RJ-45, with 8-pin cables using pins 3 and 6 to receive
data and pins 4 and 5 to transmit data. Service providers in Europe use this interface to deliver
ISDN BRI service.

NOTE:The International Telecommunications Union (ITU) is a United Nations–sponsored
organization formed in 1865 to promote worldwide communication systems compatibility.
It has two groups: ITU-T and ITU-R. ITU-T deals with telecommunications,
and ITU-R is responsible for radio communications. You can visit their
website at
www.itu.int
for more information.
U reference point The U reference point is also known as a U (user) interface. This is a 2-wire
connection between the NT1 and the telephone company (LE). Cisco routers are marked with
an X if the interface is a U and with a crossed-out X if the interface is an S/T. This is an ANSI
standard used in the U.S. but not in Europe.
V reference point The V reference point is the interface point in an ISDN environment between
the line termination and the exchange termination.

In practical terms, it may be important for you to remember that in the TE1 is part
of the customer premises equipment (CPE) and is installed inside the route. Thus
an American router presents a U interface to the world, whereas in the rest of the
world, the TE1 is service provider–owned and the router presents an S/T interface.
So you cannot use a U.S.-sourced router elsewhere in the world, but you can use
an elsewhere-sourced router in the U.S. if you buy an external TE1.

ISDN Function Groups

The ISDN function groups represent the devices in an ISDN environment such as terminals, terminal
adapters, network-termination devices and line-termination equipment. It is important to
understand the different function groups when you design and troubleshoot your ISDN network.
Figure 26.2 shows the function groups and their placement in an ISDN network.
FIGURE 2 6 . 2
ISDN function groups
PRIMARY-NET5 NET5 switch type for the U.K. and most of Europe
VN3 VN3 and VN4 switch types for France
PRIMARY-NTT Japanese ISDN PRI switches
PRIMARY-NI AT&T National ISDN switch type for the U.S.
TABLE 2 6 . 3
PRI Switch Types
(continued)
Switch Type Typically Used
S/T
S/T
R
S0
U
bri0
bri0
Native ISDN interface—int bri0
Nonnative ISDN interface—int serial 0
(EIA/TIA-232, V.35, X.21)
The following are definitions and examples of ISDN BRI function groups as they relate to
Figure 26.2:
Terminal equipment 1 (TE1)
A device that understands ISDN digital-signaling techniques.
Examples of TE1 devices are digital telephones, routers with ISDN interfaces, and digital facsimile
equipment. TE1 devices are 4-wire (2 pair) and need to be 2-wire (1 pair) to communicate
with an ISDN network. A TE1 will connect into a network termination type 1 (NT1) to connect
the 4-wire subscriber wiring to the 2-wire local loop facility.
Terminal equipment 2 (TE2)
Equipment that does not understand ISDN signaling standards.
Examples of TE2 devices are analog telephones, X.25 interfaces, and serial interfaces on a router.
A TE2 device needs to be converted to ISDN signaling, which is provided by a terminal adapter
(TA). After that, it still needs to be converted to a 2-wire network with an NT1 device.
Network termination type 1 (NT1)
This device is used to convert a 4-wire ISDN connection
to the 2-wire ISDN used by the local loop facility. This device is primarily used in the United
States, because European service providers retain ownership of this functionality.
Network termination type 2 (NT2)
This device is used to direct traffic from ISDN devices
(TEs) to an NT1. This is probably the most intelligent device in the ISDN network; it provides
switching and concentrating and can sometimes even be a private branch exchange (PBX).
Terminal adapter (TA)
This device enables a TE2 device to communicate with the telco’s network
by providing any necessary protocol and interface conversion. In essence, a TA adapts the
unipolar signal coming from a non-ISDN device into a bipolar signal used by the ISDN network.
Local termination (LT)
This is the same device as an NT1, but located at the provider’s site.
Exchange termination (ET)
The connection to the ISDN switch, typically an ISDN line card.
The ET forms the physical and logical boundary between the digital local loop and the carrier’s
switching office. It performs the same functions at the end office that the NT performs at the
customer’s premises. Both the LT and the ET together are typically referred to as the local
exchange (LE).