Edited by Salman Asad
The Public Switched Telephone Network (PSTN) has been transformed into an Integrated Systems Digital Network (ISDN). Implementation of Signaling System 7 (SS7) in the PSTN backbone has made possible such widespread services as caller ID and dialed-number delivery, 800-Directory number lookup, calling-card services, and digital data services. Using BRI and PRI services, ISDN call switching can be extended to customer premises equipment (CPE), and can provide end-to-end digital paths.
Prior to ISDN availability, data connectivity over the Public Switched Telephone Network (PSTN) was via Plain Old Telephone Service (POTS) using analog modems. Connectivity over ISDN offers the networking designer increased bandwidth, reduced call setup time, reduced latency, and lower signal/noise ratios.
ISDN is now being deployed rapidly in numerous applications, including dial-on-demand routing, dial backup, small office/home office (SOHO) and remote office/branch office (ROBO) connectivity, and modem-pool aggregation. This chapter covers the design of these applications. The purpose of this chapter is to discuss the design issues associated with building ISDN networks. For specific examples, see the relevant case-study chapters.
Figure 11-1 shows ISDN being used to concurrently serve ISDN- and POTS (analog modem)–connected remote sites in a hybrid dial solution.
ISDN has many applications in networking. The Cisco IOS has long been building dial-on-demand routing and dial backup solutions for remote office/branch office connectivity. Recently, ISDN has seen incredible growth in the support of mass small office/home office dialup connectivity. For the purposes of this book, the ISDN calling side will be referred to as SOHO, and the answering side will be referred to as the network access server (NAS) unless otherwise stated. This section addresses the following issues:
Dial-On-Demand Routing
Dial Backup
SOHO Connectivity
Modem Aggregation
Full-time connectivity across the ISDN is spoofed by Cisco IOS routers using DDR. When qualified packets arrive at a dialer interface, connectivity is established over the ISDN. After a configured period of inactivity, the ISDN connection is disconnected. Additional ISDN B channels can be added and removed from the MultiLink PPP bundles using configurable thresholds. Figure 11-2 illustrates the use of DDR for networking between ISDN-connected sites.
ISDN can be used as a backup service for a leased-line connection between the remote and central offices. If the primary connectivity goes down, an ISDN circuit-switched connection is established and traffic is rerouted over ISDN. When the primary link is restored, traffic is redirected to the leased line, and the ISDN call is released.
Dial backup can be accomplished with floating static routes and DDR, or by using the interface backup commands. ISDN dial backup can also be configured based on traffic thresholds as a dedicated primary link. If traffic load exceeds a user-defined value on the primary link, the ISDN link is activated to increase bandwidth between the two sites, as shown in Figure 11-3.
Small office and home office sites can now be economically supported with ISDN BRI services. This offers to the casual or full-time SOHO sites the capability to connect to their corporate site or the Internet at much higher speeds than those available over POTS and modems.
SOHO designs typically involve dialup only (SOHO-initiated connections), and can take advantage of emerging address-translation technology (such as Cisco 700 series PAT and Cisco IOS EZIP) to simplify design and support. Using these features, the SOHO site can support multiple devices, but appears to the Cisco IOS NAS as a single IP address, as shown in Figure 11-4.
Modem racking and cabling have been eliminated by the integration of digital modem cards on Cisco IOS network access servers (NAS). Digital integration of modems makes possible 56-kbps modem technologies. Hybrid dial solutions can be built using a single phone number to provide analog modem and ISDN conductivity, as shown in Figure 11-1.
ISDN itself does not solve networking problems. By using either DDR or user-initiated sessions, ISDN can provide the network designer a clear data path over which to negotiate PPP links. A Public Switched Telephone Network to provide network connectivity requires careful consideration of network security and cost containment.
This section includes overviews of the following ISDN design issues, which are then covered more fully in the following main sections of this chapter:
ISDN Connectivity
Datagram Encapsulation
DDR: Dial-On-Demand Routing
Security Issues
Cost-Containment Issues
Connectivity to ISDN is provided by physical PRI and BRI interfaces. A single PRI or BRI interface provides a multiplexed bundle of B and D channels. The B channel provides bearer services such as high-bandwidth data (up to 64 kbps per B channel) or voice services. The D channel provides the signaling and control channel, and can also be used for low-bandwidth data applications.
BRI service is provided over a groomed local loop, traditionally used for switching to analog phone service. BRI delivers to the subscriber two 64-kbps B channels and one 16-kbps D channel (2B+D).
PRI service is provided on traditional T1 and E1 leased lines between the customer premise equipment (CPE) and the ISDN switch:
T1-based PRI provides 23 B channels and one D channel (23B+D).
E1-based PRI provides 30 64-kbps B channels and one 64-kbps D channel (30B+D).
Provisioning of both PRI and BRI services entails very stringent requirements for the physical equipment and cabling in the path from ISDN switch to ISDN CPE. Typical installations can require additional lead times as well as require working with dedicated support groups within your ISDN service-provider organizations (see Figure 11-5).
When DDR (or a user) creates an end-to-end path over the ISDN, some method of datagram encapsulation is needed to provide data connectivity. Available encapsulations for ISDN designs are PPP, HDLC, X.25, and V.120. X.25 can also be used for datagram delivery over the D channel.
Most networking designs use PPP as the encapsulation. The Point-to-Point Protocol (PPP) is a powerful and modular peer-to-peer mechanism to establish data links, provide security, and encapsulate data traffic. PPP is negotiated between the networking peers each time a connection is established. PPP links can then be used by network protocols such as IP and IPX to establish network connectivity. PPP solutions can support bandwidth aggregation using MultiLink PPP to provide greater throughput for networking applications.
When building networking applications, designers must determine how ISDN connections will be initiated, maintained, and released. DDR is a sophisticated set of Cisco IOS features that intelligently establishes and releases circuit-switched connections, as needed by networking traffic. DDR can spoof network routing and directory services in numerous ways to provide the illusion of full-time connectivity over circuit-switched connections. Refer to Chapter 10, "Designing DDR Networks," for a discussion of DDR design.
Because your network devices can now be connected to over the PSTN, it is imperative to design and confirm a robust security model for protecting your network. Cisco IOS uses the AAA model for implementing security. ISDN offers the use of caller ID and DNIS information to provide additional security-design flexibility.
A primary goal of selecting ISDN for your network is to avoid the cost of full-time data services (such as leased lines or Frame Relay). As such, it is very important to evaluate your data traffic profiles and monitor your ISDN usage patterns to ensure your WAN costs are controlled. Dialer callback can also be implemented to centralize billing.
Each of these building blocks of ISDN (connectivity, data encapsulation, DDR, security, and cost containment) is discussed in further detail in the remaining sections of this chapter.
Based on application need and traffic engineering, BRI or PRI services are selected for ISDN connectivity from each site. Traffic engineering may require multiple BRI services or multiple PRIs at some sites. Once connected to the ISDN fabric by BRI or PRI interfaces, design of ISDN end-to-end services must be implemented. This section covers the following issues related to ISDN connectivity:
Establishing BRI Connectivity
Establishing ISDN Primary Rate Interface (PRI)
ISDN End-to-End Considerations
Datagram-Encapsulation Issues
The BRI local loop is terminated at the customer premise at an NT1. The interface of the local loop at the NT1 is called the U reference point. On the customer premise side of the NT1 is the S/T reference point. The S/T reference point can support a multipoint bus of ISDN devices (terminal adapters). Figure 11-6 shows a typical BRI installation.
Two common types of ISDN CPE are available for BRI services: ISDN routers and PC terminal adapters. Some BRI devices offer integrated NT1s and integrated terminal adapters for analog telephones.
LAN routers—. ISDN routers provide routing between ISDN BRI and the LAN by using dial-on-demand routing (DDR).
DDR automatically establishes and releases circuit-switched calls, providing transparent connectivity to remote sites, based on networking traffic. DDR also controls establishing and releasing secondary B channels, based on load thresholds. MultiLink PPP is used to provide bandwidth aggregation when using multiple B channels. For more information on DDR, see Chapter 10.
Some ISDN applications may require the SOHO user to take direct control over ISDN calls. Emerging Cisco IOS features can bring this control to the user desktop. New Cisco 700 models provide a call button on the front of the router for direct control.
Cisco 700 series and Cisco IOS–based 1000, 1600, 2500 routers provide single BRI interfaces. Multiple-BRI interfaces are available for the Cisco 3600 and Cisco 4x00 series.
PC terminal adapters (PC-TA)—. These devices connect to PC workstations either by the PC bus or externally through the communications ports (such as RS-232), and can be used similar to analog (such as V.34) internal and external modems.
PC terminal adapters can provide a single PC user with direct control over ISDN session initiation and release, similar to using an analog modem. Automated mechanisms must be provided to support the addition and removal of the secondary B channel. Cisco 200 Series PC Cards can provide ISDN services to a PC.
BRI configuration involves configuration of ISDN switch type and ISDN SPIDs, as follows:
ISDN switch types—. ISDN central-office switches (also known as local-exchange equipment) provide two functions at the local exchange: local termination and exchange termination. The local-termination function deals with the transmission facility and termination of the local loop. The exchange-termination function deals with the switching portion of the local exchange. First, the exchange-termination function demultiplexes the bits on the B and D channels. Next, B-channel information is routed to the first stage of the circuit switch, and D-channel packets are routed to D-channel packet-separation circuitry.
For proper ISDN operation, it is imperative that the correct switch type be configured on the ISDN device. For Cisco IOS releases up to 11.2, the configured ISDN switch type is a global command. (Note that this also means you cannot use BRI and PRI cards in the same Cisco IOS chassis.) In Cisco IOS 11.3T or later, multiple switch types in a single Cisco IOS chassis are now supported.
Cisco IOS switch types—The following Cisco IOS command helps illustrate the supported BRI switch types. In North America, the most common types are 5ESS, DMS100, and NI-1.
kdt-3640(config)#isdn switch-type ? basic-1tr6 1TR6 switch type for Germany basic-5ess AT&T 5ESS switch type for the U.S. basic-dms100 Northern DMS-100 switch type basic-net3 NET3 switch type for UK and Europe basic-ni1 National ISDN-1 switch type basic-nwnet3 NET3 switch type for Norway basic-nznet3 NET3 switch type for New Zealand basic-ts013 TS013 switch type for Australia ntt NTT switch type for Japan vn2 VN2 switch type for France vn3 VN3 and VN4 switch types for FranceCisco 700 switch types—On Cisco 700 series routers, use the set switch command, which has the following options when running the U.S. software image:
SEt SWitch 5ESS | DMS | NI-1 | PERM64 | PERM128
Service profile identifiers (SPIDs)—. A service profile identifier (SPID) is a number provided by the ISDN carrier to identify the line configuration of the BRI service. SPIDs allow multiple ISDN devices, such as voice and data, to share the local loop. SPIDs are required by DMS-100 and National ISDN-1 switches. Depending on the software version it runs, an AT&T 5ESS switch might require SPIDs as well.
Each SPID points to line setup and configuration information. When a device attempts to connect to the ISDN network, it performs a D-channel Layer 2 initialization process that causes a TEI to be assigned to the device. The device then attempts D-channel Layer 3 initialization. If SPIDs are necessary, but not configured or configured incorrectly on the device, the Layer 3 initialization fails, and the ISDN services cannot be used.
The AT&T 5ESS switch supports up to eight SPIDs per BRI. Because multiple SPIDs can be applied to a single B channel, multiple services can be supported simultaneously. The first B channel can be configured for data, for example, and the second B channel can be configured for both voice (using an ISDN telephone) and data.
DMS-100 and National ISDN-1 switches support only two SPIDs per BRI: one SPID for each B channel. If both B channels will be used for data only, configure the router for both SPIDs (one for each B channel). You cannot run data and voice over the same B channel simultaneously. The absence or presence of a channel's SPID in the router's configuration dictates whether the second B channel can be used for data or voice.
Note
There is no standard format for SPID numbers. As a result, SPID numbers vary, depending on the switch vendor and the carrier.
A typical Cisco IOS SPID configuration is as follows:
interface BRI0 isdn spid1 0835866201 8358662 isdn spid2 0835866401 8358664These commands also specify the local directory number (LDN), which is the seven-digit number assigned by the service provider and used for call routing. The LDN is not necessary for establishing ISDN-based connections, but it must be specified if you want to receive incoming calls on B channel 2. The LDN is required only when two SPIDs are configured (for example, when connecting to a DMS or NI1 switch). Each SPID is associated with an LDN. Configuring the LDN causes incoming calls to B channel 2 to be answered properly. If the LDN is not configured, incoming calls to B channel 2 may fail.
A typical Cisco 700 Series SPID configuration is as follows:
SET 1 SPID 51255500660101 SET 1 DIRECTORYNUMBER 5550066 SET PHONE1 = 5550066 SET 2 SPID 51255500670101
To confirm BRI operations in Cisco IOS, use the show isdn status command to inspect the status of your BRI interfaces. In the following example, the TEIs have been successfully negotiated and ISDN Layer 3 (end to end) is ready to make or receive calls:
kdt-1600#sh isdn status
The current ISDN Switchtype = basic-ni1
ISDN BRI0 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 109, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 110, State = MULTIPLE_FRAME_ESTABLISHED
Spid Status:
TEI 109, ces = 1, state = 8(established)
spid1 configured, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 1, tid = 1
TEI 110, ces = 2, state = 8(established)
spid2 configured, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 3, tid = 1
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
Total Allocated ISDN CCBs = 0
Troubleshooting SPID problems is done with the debug isdn q921 command. In the example that follows, you can see that isdn spid1 was rejected by the ISDN switch:
kdt-1600#debug isdn q921
ISDN Q921 packets debugging is on
kdt-1600#clear int bri 0
kdt-1600#
*Mar 1 00:09:03.728: ISDN BR0: TX -> SABMEp sapi = 0 tei = 113
*Mar 1 00:09:04.014: ISDN BR0: RX <- IDREM ri = 0 ai = 127
*Mar 1 00:09:04.018: %ISDN-6-LAYER2DOWN:
Layer 2 for Interface BRI0, TEI 113 changed to down
*Mar 1 00:09:04.022: %ISDN-6-LAYER2DOWN:
Layer 2 for Interface BR0, TEI 113 changed to down
*Mar 1 00:09:04.046: ISDN BR0: TX -> IDREQ ri = 44602 ai = 127
*Mar 1 00:09:04.049: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 113
*Mar 1 00:09:05.038: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 113
*Mar 1 00:09:06.030: ISDN BR0: TX -> IDREQ ri = 37339 ai = 127
*Mar 1 00:09:06.149: ISDN BR0: RX <- IDREM ri = 0 ai = 113
*Mar 1 00:09:06.156: ISDN BR0: RX <- IDASSN ri = 37339 ai = 114
*Mar 1 00:09:06.164: ISDN BR0: TX -> SABMEp sapi = 0 tei = 114
*Mar 1 00:09:06.188: ISDN BR0: RX <- UAf sapi = 0 tei = 114
*Mar 1 00:09:06.188: %ISDN-6-LAYER2UP:
Layer 2 for Interface BR0, TEI 114 changed to up
*Mar 1 00:09:06.200: ISDN BR0: TX ->
INFOc sapi = 0 tei = 114 ns = 0 nr = 0 i = 0x08007B3A06383932393833
*Mar 1 00:09:06.276: ISDN BR0: RX <-
INFOc sapi = 0 tei = 114 ns = 0 nr = 1 i = 0x08007B080382E43A
*Mar 1 00:09:06.283: ISDN BR0: TX -> RRr sapi = 0 tei = 114 nr = 1
*Mar 1 00:09:06.287: %ISDN-4-INVALID_SPID: Interface BR0, Spid1 was rejected
Check the status of the Cisco 700 ISDN line with the show status command, as follows:
kdt-776> sh status
Status 01/04/1995 18:15:15
Line Status
Line Activated
Terminal Identifier Assigned SPID Accepted
Terminal Identifier Assigned SPID Accepted
Port Status Interface Connection Link
Ch: 1 Waiting for Call
Ch: 2 Waiting for Call
Note the following issues regarding BRI configuration that must be addressed:
TEI negotiation—. Some switches deactivate Layer 2 of the D channel when no calls are active, so the router must be configured to perform TEI negotiation at the first call rather than at router power up (the default). To enable TEI negotiation at the first call, use the following global configuration command:
isdn tei-negotiation first-call
ISDN subaddressing—. The S/T bus is a point-to-multipoint bus. Multiple ISDN CPE devices can share the same S/T bus. Call routing to individual devices on an S/T bus is achieved by using ISDN subaddressing.
Voice routing—. Cisco 700 Series routers can provide POTS jacks for connecting traditional analog telephone sets. SOHO sites can benefit from the capability to concurrently route data and voice calls over the same ISDN BRI interface. Voice-port phone numbers and voice priority must be configured for the needs of the SOHO site. The example that follows shows the voice-routing setup for a typical Cisco 700:
SET SWITCH NI-1 SET 1 SPID 51255500660101 SET 1 DIRECTORYNUMBER 5550066 SET PHONE1 = 5550066 SET 2 SPID 51255500670101 SET 2 DIRECTORYNUMBER 5550067 SET PHONE2 = 5550067 SET VOICEPRIORITY INCOMING INTERFACE PHONE1 NEVER SET VOICEPRIORITY OUTGOING INTERFACE PHONE1 NEVER SET CALLWAITING INTERFACE PHONE1 OFF SET VOICEPRIORITY INCOMING INTERFACE PHONE2 ALWAYS SET VOICEPRIORITY OUTGOING INTERFACE PHONE2 ALWAYS SET CALLWAITING INTERFACE PHONE2 ON kdt-776> sh voicerouting Interface VoicePriority VoicePriority Call Directory Ring In Out Waiting Number Cadence PHONE1 NEVER NEVER OFF 6720066 PHONE2 ALWAYS ALWAYS ON 6720067 DOV N/A N/A N/A UNSPECIFIED N/A N/A N/A
Cisco IOS routers support PRI interfaces using MultiChannel Interface Processor (MIP) cards. MIP cards can support Channelized T1/E1 or PRI timeslots. MIP cards are available for Cisco 4x000, Cisco 36x0, Cisco 5x00, and Cisco 7x00 Series routers.
To specify that the MIP card is to be used as an ISDN PRI, use the pri-group timeslots controller configuration command.
Cisco IOS routers supporting PRI interfaces become network access servers. Cisco 5x00 and 36x0 Series routers support hybrid dial solutions (POTS and ISDN) by providing access to analog modems over the NAS backplane.
Configure the ISDN switch type for the PRI interface using the isdn switch-type command:
AS5200-2(config)#isdn switch-type ?
primary-4ess AT&T 4ESS switch type for the U.S.
primary-5ess AT&T 5ESS switch type for the U.S.
primary-dms100 Northern Telecom switch type for the U.S.
primary-net5 European switch type for NET5
primary-ntt Japan switch type
primary-ts014 Australia switch type
Normally, this is a global configuration command. Cisco IOS 11.3T or later will provide support for multiple switch types in a single Cisco IOS chassis. Enable PRI services on the Cisco IOS NAS by configuring the T1 (or E1) controllers. The configuration that follows shows a typical T1 controller configuration on a Cisco 5200:
controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! controller T1 1 framing esf clock source line secondary linecode b8zs pri-group timeslots 1-24 !
Note that PRI channels 0–23 map to pri-group timeslots 1-24. The same +1 mapping is used on E1-based PRI.
To configure a T1-based PRI, apply the configuration commands to the PRI D channel— that is, interface Serial0:23. All B channels in an ISDN PRI (or BRI) interface are automatically bundled into a dialer interface. When calls are made or received on the B channels, the configuration is cloned from the dialer interface (Serial0:23). If a NAS contains multiple PRIs, these PRIs can be grouped into a single dialer interface by the dialer rotary-group interface command, as shown in this example:
interface Serial0:23 dialer rotary-group 1 ! interface Serial1:23 dialer rotary-group 1 ! interface Dialer1 ip unnumbered Ethernet0 encapsulation ppp peer default ip address pool default dialer in-band dialer idle-timeout 120 dialer-group 1 no fair-queue no cdp enable ppp authentication pap chap ppp multilink
With this configuration, every B channel configuration or MultiLink PPP bundle is cloned from interface Dialer1.
The state of the T1 controller is inspected with the Cisco IOS exec command show controller t1, as follows:
AS5200-1#sh contr t1
T1 0 is up.
No alarms detected.
Version info of slot 0: HW: 2, Firmware: 14, NEAT PLD: 14, NR Bus PLD: 22
Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary.
Data in current interval (685 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 8 Degraded Mins,
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
T1 1 is up.
No alarms detected.
Version info of slot 0: HW: 2, Firmware: 14, NEAT PLD: 14, NR Bus PLD: 22
Framing is ESF, Line Code is B8ZS, Clock Source is Line Secondary.
Data in current interval (197 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 4 Degraded Mins,
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Excessive line-code violations and other errors will cause significant performance loss. Work with your ISDN PRI service provider to ensure that these counters show a relatively clean operation. Use the Cisco IOS exec command show isdn status to verify that ISDN is operational, as follows:
AS5200-1#sh isdn status
The current ISDN Switchtype = primary-dms100
ISDN Serial0:23 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
ISDN Serial1:23 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 1 CCBs = 0
Total Allocated ISDN CCBs = 0
Inspect B-channel status with the show isdn service exec command, as follows:
AS5200-1#sh isdn service
PRI Channel Statistics:
ISDN Se0:23, Channel (1-31)
Activated dsl 0
State (0=Idle 1=Propose 2=Busy 3=Reserved 4=Restart 5=Maint)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 3 3 3 3 3
Channel (1-31) Service (0=Inservice 1=Maint 2=Outofservice)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ISDN Se1:23, Channel (1-31)
Activated dsl 1
State (0=Idle 1=Propose 2=Busy 3=Reserved 4=Restart 5=Maint)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 3 3 3 3 3
Channel (1-31) Service (0=Inservice 1=Maint 2=Outofservice)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
This section discusses the following ISDN end-to-end considerations:
Signaling System 7 (SS7)
Data-Path Speed
Signaling System 7 (SS7) provides telephone switches with out-of-band signaling capabilities for telephony trunks (switch-to-switch DS0 connections). End-to-end call management (such as setup and teardown) uses ITU specification Q.931 and is extended to PRI/BRI networking devices over the ISDN D channel.
Out-of-band signaling via SS7 provides numerous benefits to networking design, including reduced call setup time, bearer capability and other progress indicators, 64-kbps data paths, caller ID, and dialed number information (DNIS). The output that follows (of Cisco IOS debug isdn q931) shows typical ISDN Q.931 SETUP messages received by an NAS.
The Q.931 SETUP message includes a bearer-capability information element (IE), which indicates to the ISDN fabric and receiving side the type of application carried on the B channel. It is the responsibility of the ISDN to provide an end-to-end channel capable of carrying the bearer service, and to provide to the receiving side progress indication to help it better utilize the ISDN connection.
The Cisco IOS debug isdn q931 output has different bearer capabilities for each incoming call type, as follows:
ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x0470 Bearer Capability i = 0x8890 Channel ID i = 0xA98382 Calling Party Number i = '!', 0x83, '5125558084' Called Party Number i = 0xC9, '52000'ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x05DC Bearer Capability i = 0x8890218F Channel ID i = 0xA98382 Calling Party Number i = '!', 0x83, '5125558084' Called Party Number i = 0xC9, '52000'ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x015C Bearer Capability i = 0x8090A2 Channel ID i = 0xA98383 Progress Ind i = 0x8283 - Origination address is non-ISDN Called Party Number i = 0xC1, '5552000'To support the routing of voice calls to integrated modem cards, use the Cisco IOS interface configuration command isdn incoming-voice modem. In some network designs, data calls can be made with the Q.931 SETUP message, indicating that it is a voice call. In some regions, ISDN tariff structures may make this type of call more cost-effective. (This design is commonly referred to as ISDN data-over-voice.) However, indicating to the ISDN switching fabric that the bearer capability is voice allows the call to be placed through nondigital trunks. Designers, therefore, must carefully consider the potential risk in such a design. To support incoming ISDN data-over-voice calls on the Cisco IOS, use the configuration command isdn incoming-voice data, as follows:
NAS-522(config)#int serial 0:23 NAS-522(config-if)#isdn incoming ? data Incoming voice calls will be handled as data. modem Incoming voice calls will be handled as modems.
Prior to SS7 implementation, end-to-end call-management signaling was provided in-band by robbing bits from the DS0 trunks. Utilizing the occasional eighth and least significant bit of each voice byte was not detrimental to voice quality, but provided switch-to-switch signaling. End-to-end, out-of-band signaling via SS7 and PRI/BRI D channels allows data calls to be placed through ISDN networks utilizing the full DS0 trunk (64 kbps). Some trunks of the PSTN still do not support out -of-band signaling, and can provide only robbed-bit trunking (Channelized T1/E1), limiting the available data channel to 56 kbps.
It is the responsibility of the ISDN switching fabric to provide an end-to-end path matching the requirement of the bearer capability. If a call is made at 64 kbps and there is not a 64-kbps clear, end-to-end path for the call, a busy signal should be received. Network designers must consider the possibility of occasional ISDN call blocking at 64 kbps. Robust design may require that some sites be supported with 56-kbps data calls. Table 11-1 shows outgoing speeds.
When originating calls are made at 64 kbps and improperly delivered to the destination by the ISDN network over a 56-kbps path, the transmitted data will be corrupted. The troubleshooting indication will be that debug isdn q931 shows the call being delivered, but no output is ever seen as being received from debug ppp negotiation on one side. The packets have been corrupted and are being discarded. If calls are being delivered and PPP is not negotiating LCP, it is always a prudent idea to test outgoing calls at 56 kbps.
Outgoing call speed
Cisco IOS speed configuration—Use the speed parameter on the dialer map configuration command to make outgoing calls at 56 kbps, as in the following example:
int dialer 1 dialer map ip 172.20.1.1 name nas speed 56 5558084Cisco IOS dialer profiles speed configuration—The following example illustrates how to configure a Cisco IOS dialer profile to make outgoing calls at 56 kbps:
interface dialer 1 dialer remote-name nas dialer string 5558084 class unameit ! map-class dialer unameit dialer isdn speed 56Cisco 700 speed configuration—Use the Cisco 700 series set speed configuration command to control the speed for outgoing calls.
Incoming call speed
The ISDN Q.931 bearer capability and other IEs are used to determine the speed of the incoming call, and will operate properly in most circumstances. In some country-to-country applications, however, the incoming call SETUP message will be delivered with a bearer capability that does not match the originating call. If an isdn not end-to-end IE is also received, it can be used to override the received bearer capability using the Cisco IOS configuration command isdn not end-to-end.
ISDN can use PPP, HDLC, or X.25 for encapsulation. PPP is used most frequently because it provides an excellent mechanism for authentication and negotiation of compatible link and protocol configuration.
PPP provides a standard method for transporting multiprotocol packets over point-to-point links. PPP is defined in RFC 1661. PPP consists of several components, each of which are of concern to the network designer:
PPP framing
RFC 1662 discusses the implementation of PPP in HDLC-like framing. There are differences in the way PPP is implemented on asynchronous and synchronous links.
When one end of the link uses synchronous PPP (such as an ISDN router) and the other uses asynchronous PPP (such as an ISDN TA connected to a PC serial port), two techniques are available to provide framing compatibility. The preferable method is to enable synchronous-to-asynchronous PPP frame conversion in the ISDN TA. If this is not available, V.120 can be used to encapsulate the asynchronous PPP frames for transport across the ISDN.
The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. Before any network layer datagrams (for example, IP) can be exchanged, LCP must first open the connection and negotiate configuration parameters. This phase is complete when a configuration acknowledgment frame has been both sent and received.
PPP authentication
The PPP authentication protocols (PAP and CHAP) are defined in RFC 1334. After LCP has established the PPP connection, an optional authentication protocol can be implemented before proceeding to the negotiation and establishment of the Network Control Protocols. If authentication is desired, it must be negotiated as an option at the LCP establishment phase. Authentication can be bidirectional (both sides authenticate the other) or unidirectional (one side, typically the called side, authenticates the other).
Most ISDN designs require the called device to authenticate the calling device. Besides the obvious security benefits, authentication also provides a sense of state for DDR and MultiLink PPP bundling.
Network Control Protocols (NCPs)
This is a family of NCPs for establishing and configuring different network layer protocols. PPP is designed to allow the simultaneous use of multiple network layer protocols.
After LCP has been established and authentication has passed, the PPP nodes send NCP frames to negotiate and establish connectivity for one or more network layer protocols. To support IP over a PPP connection, for example, the IPCP is negotiated and established as per RFC 1332. After IPCP is successfully established, IP datagrams can be transmitted over the PPP connection.
MultiLink PPP is a standard for aggregating multiple PPP links that allows for multivendor interoperability, and is defined in RFC 1717. MP defines a way of sequencing and transmitting packets over multiple physical interfaces. To reduce potential latency issues, MP also defines a method of fragmenting and reassembling large packets. Figure 11-7 provides a conceptual view of MP in action.
When an NCP packet arrives at an MLP master interface for transmitting and is larger than 30 bytes, it is fragmented and sent on each physical link in the MLP bundle. When MLP packet fragments arrive on PPP destination, MLP reassembles the original packets and sequences them correctly in the data stream.
Using MP, BRI devices can double their connection bandwidth across the link: from 56/64 kbps to 112/128 kbps. MPPP is supported as long as all devices are part of the same dialer rotary group or pool.
Cisco IOS and Cisco 700 DDR intelligence is used to determine when to add and remove links from the MP master interface. Cisco IOS DDR provides a load-threshold configuration to determine when to add and remove the additional link. The load factor can be calculated on incoming, outgoing, or two-way traffic.
The following partial configuration for NAS places two BRI interfaces into a dialer rotary group, enables MP support, and defines a load threshold for determining when to bring up additional B channels.
interface BRI2/0 encapsulation ppp dialer rotary-group 1 isdn spid1 0835866201 isdn spid2 0835866401 ! interface BRI2/1 encapsulation ppp dialer rotary-group 1 isdn spid1 0835867201 isdn spid2 0835967401 ! interface Dialer1 ip unnumbered Ethernet0/0 encapsulation ppp dialer in-band dialer map ip 172.20.2.1 name kdt-nas 8358661 dialer load-threshold 100 either dialer-group 1 ppp authentication chap callin ppp multilinkMP state and sessions can be investigated using the show user and the show ppp multilink commands:
KDT-5200#sh user Line User Host(s) Idle Location * 51 vty 1 admin idle 00:00:00 Vi1 jack-isdn Virtual PPP (Bundle) 00:00:46 Vi9 cisco776 Virtual PPP (Bundle) 00:00:46 Se0:18 jack-isd Sync PPP 00:09:06 Se0:21 cisco776 Sync PPP 00:18:59 Se0:22 jack-isdn Sync PPP 00:08:49 KDT-AS5200#sh ppp multi Bundle cisco776, 1 member, Master link is Virtual-Access9 Dialer Interface is Dialer1 0 lost fragments, 3 reordered, 0 unassigned, sequence 0x2068/0x1A7C rcvd/ sent 0 discarded, 0 lost received, 1/255 load Member Link: 1 Serial0:21 Bundle jack-isdn, 2 members, Master link is Virtual-Access1 Dialer Interface is Dialer1 0 lost fragments, 8 reordered, 0 unassigned, sequence 0x5DEB/0x1D7E4 rcvd/ sent 0 discarded, 0 lost received, 1/255 load Member Links: 2 Serial0:18 Serial0:22
As seen previously, MP uses the PPP authentication name to build and maintain MP bundles. To enable MP on a Cisco 700, apply the following configuration command:
set ppp multilink on
Compression Control Protocol (CCP)
The Point-to-Point (PPP) Compression Control Protocol (CCP) is an Internet Engineering Task Force (IETF) draft RFC that defines a method for negotiating data compression over PPP links. These links can be either leased lines or circuit-switched WAN links, including ISDN. Compression increases throughput and shortens file transfer times.
Use the compress interface configuration command at both ends of the link to enable compression. Use the stac keyword to enable the Stacker (LZS) compression algorithm or the predictor keyword to enable the RAND algorithm (a predictor algorithm). The Stacker algorithm is appropriate for LAPB and PPP encapsulation, and the RAND algorithm is appropriate for HDLC and PPP encapsulation. The Stacker algorithm is preferred for PPP encapsulation.
On the Cisco IOS, to determine what components have been negotiated (such as LCP, IPCP, CCP, and so on), use the show interface command on the master interface. To troubleshoot PPP negotiation problems, use debug ppp negotiation and debug ppp authentication.
Using SS7, the ISDN can deliver end-to-end information elements such as caller ID and dialed number information service (DNIS). This information can be used to provide additional security when designing ISDN solutions. It is recommended that PPP authentication always be implemented.
PPP authentication is used to provide primary security on ISDN and other PPP-encapsulated links. The authenticated username is also used by MultiLink PPP to maintain bundles and by DDR to determine which dialer sites are currently connected.
PPP authentication is enabled with the ppp authentication interface command. PAP and/or CHAP can be used to authenticate the remote connection. CHAP is considered a superior authentication protocol because it uses a three-way handshake to avoid sending the password in clear text on the PPP link.
Often, it may be necessary to authenticate the remote side only when receiving calls (not when originating).
Caller-ID screening
The isdn caller interface configuration command configures caller-ID screening. For example, the following command configures an ISDN to accept a call with a delivered caller ID having 41555512 and any numbers in the last two positions.
isdn caller 41555512xx
Multiple isdn caller commands can be entered as needed. If a call is received that does not contain a caller ID or does not match a configured isdn caller statement, the call will be rejected.
Dialer callback
Callback allows a router (typically a remote router) to initiate a circuit-switched WAN link to another device and request that device to call back. The device, such as a central-site router, responds to the callback request by calling the device that made the initial call. Callback uses the Point-to-Point Protocol (PPP) and the facilities specified in RFC 1570. Figure 11-8 shows a typical negotiation.
In Figure 11-8, callback is completed in the following sequence of steps:
Router A brings up a circuit-switched connection to Router B.
Routers A and B negotiate PPP Link Control Protocol (LCP). Router A can request a callback, or Router B can initiate a callback.
Router A authenticates itself to Router B using PPP PAP or CHAP. Router B can optionally authenticate itself to Router A.
Both routers drop the circuit-switched connection.
Router B brings up a circuit-switched connection to Router A.
Callback provides centralized billing for synchronous dialup services. It also enables you to take advantage of tariff disparities on both a national and international basis. Because callback requires a circuit-switched connection to be established before the callback request can be passed, however, a small charge (dependent on local tariffing) is always incurred by the router initiating the call that requests a callback.
See Chapter 10 for a further discussion of DDR callback. See Chapter 21, "Using ISDN Effectively in Multiprotocol Networks," for a callback configuration example.
Called-party number verification
When multiple devices and a router share the same ISDN local loop, you can ensure that the correct device answers an incoming call. This is done by configuring the device to verify the called-party number and the subaddress delivered by the switch as part of the SETUP message against the device's configured number and subaddress.
To configure called-party number verification on the router, apply the isdn answer1 or isdn answer2 interface configuration commands to the BRI. These commands enable you to specify the called-party number, the subaddress number, or both. If you do not use either the isdn answer1 command or the isdn answer2 command, the router processes and accepts all incoming calls.
ISDN scaling techniques covered in this section include the following:
Virtual Remote Nodes
Virtual Profiles
MultiChassis MultiLink PPP (MMP)
By using network address translations (NAT) features such as Cisco 700 PAT and Cisco IOS EZIP, remote sites can appear to the ISDN NAS as a single remote node IP address. This alleviates IP address–consumption problems and the routing-design complexity often associated with large-scale ISDN DDR deployment, while still supporting a LAN and DDR-based connectivity from the remote site.
These NAT features use the IP address received from the NAS during IPCP negotiation. All packets routed between the LAN and the PPP link have their individual IP addresses translated to a single IP address. Different UDP/TCP port numbers are used with the single IP address to determine which packets need to be returned to which IP addresses on the LAN. The port number translation is used to determine which packets need to be returned to which IP addresses on the LAN. The following Cisco 700 configuration commands set NAT up for PAT.
The following configuration sets up a Cisco 700 for PAT and DHCP service:
cd internal
set ip address 172.24.4.254
set ip netmask 255.255.255.0
set ip routing on
set ip rip update off
cd
set user access-gw1
set ip routing on
set ip framing none
set number 18005552626
set ip rip update off
set encap ppp
set ip route destination 0.0.0.0 gateway 0.0.0.0
set ip pat on
cd lan
set bridging on
set encaps ppp
set ip routing on
cd
set ip pat porthandler default 172.24.4.1
set ip pat porthandler http 172.24.4.1
set bridging on
set dhcp server
set dhcp domain cisco.com
set dhcp address 172.24.1.1 10
set dhcp netmask 255.255.255.0
set dhcp gateway primary 172.24.4.254
set dhcp dns primary 172.30.1.100
set dhcp dns secondary 172.30.2.100
set dhcp wins primary 172.30.1.101
set dhcp wins secondary 172.30.2.101
set ppp authentication incoming chap
set ppp authentication outgoing chap
set ppp secret client
<insert_secret>
<insert_secret>
set ppp secret host
<insert_secret>
<insert_secret>
If support is required for outbound-initiated network connections to the remote site, port-handler configuration can be added so that the SOHO router knows which IP address to forward packets on to for individual connection types.
kdt-776> sh ip pat
Dropped - icmp 0, udp 0, tcp 0, map 0, frag 0
Timeout - udp 5 minutes, tcp 30 minutes
Port handlers [default 172.24.4.1]:
Port Handler Service
---------------------------------------
0 172.24.4.1 DEFAULT
23 Router TELNET
67 Router DHCP Server
68 Router DHCP Client
69 Router TFTP
80 172.24.4.1 HTTP
161 Router SNMP
162 Router SNMP-TRAP
520 Router RIP
Translation Table - 11 Entries.
Inside Outside Orig. Port/ID Trans. Port/ID Timeout
---------------------------------------------------------------------------
172.24.4.1 172.17.190.5 0x414 0xff7d 1
172.24.4.1 172.17.190.5 0x415 0xff7c 30
172.24.4.1 172.17.190.26 0x40d 0xff88 27
172.24.4.1 172.17.114.11 0x416 0xff7b 4
172.24.4.1 172.17.114.11 0x417 0xff7a 4
172.24.4.1 172.17.114.11 0x40f 0xff82 4
172.24.4.1 172.17.190.19 0x418 0xff79 1
172.24.4.1 172.17.190.5 0x410 0xff81 1
172.24.4.1 172.17.114.11 0x411 0xff80 4
172.24.4.1 172.17.114.11 0x412 0xff7f 4
172.24.4.1 172.17.190.5 0x413 0xff7e 1
Virtual profiles (introduced in Cisco IOS 11.3) are PPP applications that create virtual-access interfaces for each connected user. Virtual profiles allow additional design flexibility when building ISDN networks for SOHO support. Using virtual profiles for dial-in can provide simplified node addressing and address mapping that was previously provided by using DDR on ISDN interfaces. (As of Cisco IOS 11.3, virtual profile–based dial-out is not supported.)
The virtual-access interface configuration can be cloned from a dialer or virtual template. To learn more about virtual-access interfaces, see http://cio.cisco.com/warp/customer/131/4.html. Virtual profiles use virtual templates and can use AAA based on per-user configuration to create virtual-access interfaces. Per-user configuration can be added to meet the specific protocol needs of individual users or groups.
Cisco IOS virtual-access interfaces can simplify remote node support for IPX and AppleTalk by using the same configuration used on traditional group-async interfaces. The following configuration provides peer addressing for IP, IPX, and AppleTalk using a virtual-template interface:
interface Virtual-Template1 ip unnumbered Ethernet0/0 appletalk client-mode ipx ppp-client Loopback0 peer default ip address pool default
When designing MultiLink PPP without MultiChassis support, telco hunt groups cannot span more than a single Cisco IOS NAS; otherwise, there exists a risk that the multiple B channels will not be reassembled. An AS5300 can support up to four PRI interfaces, for example, providing a maximum of 120 B channels (E1 based) in a single dial-in hunt group. Additional NAS capacity would need to be provided by configuring a new hunt group (with a new pilot directory number) for each network access server, as shown in Figure 11-9. This has the negative effect of fragmenting the dialup pool.
Cisco recognized that no matter what size NAS they can develop, there will always be customers needing larger pools of access ports. As such, Cisco IOS 11.2 released MultiChassis MultiLink Point-to-Point Protocol (MMP), which extends MultiLink PPP (MLP) by providing a mechanism to aggregate B channels transparently across multiple NASs.
MMP consists of two primary components to complement MLP, as follows:
The dial StackGroup—. NASs that operate as a group when receiving MLP calls. Every MLP session receiving any NAS is sent out to bid using the Stack Group Bidding Protocol (SGBP). Primarily, this allows secondary MLP links to be bundled to the MLP master interface. Different bidding strategies (such as off load and load sharing) can be used to determine who should win master-interface bidding.
Level 2 Forwarding (L2F) protocol—. A draft IETF standard, L2F provides for tunneling of the MLP fragments between the MLP physical interface and the MLP master interface.
By using MMP, MLP capacity can be easily added and removed from large dial pools as needed. CPU processing capacity can be added to dialup pools through the use of off-load servers. Tasks such as MLP fragmentation and reassembly, PPP compression, and encryption can be intensive and may benefit from execution in off-load servers (see Figure 11-10).
To configure MMP on a Cisco IOS NAS, use the sgbp commands, as follows:
kdt-3640(config)#sgbp ?
group SGBP group name
member SGBP group member configuration
ppp-forward SGBP participation for non-Multilink PPP also
seed-bid mastership query seed bid
source-ip SGBP source ip address
To monitor and troubleshoot MMP, use both SGBP and VPDN (for L2F):
sh sgbp sh vpdn debug sgbp debug vpdn
MMP provides an interoperable multivendor solution because it does not require any special software capabilities at the remote sites. The only remote requirement is support for the industry standard MLP (RFC 1717).
As a circuit-switched connection, ISDN is billed, or tariffed, based on usage. Given this model, the configuration goal is to minimize uptime by controlling the kinds of packets that bring the link up. Minimizing uptime becomes a challenge when routing protocols are used because of their need to send regular broadcasts that contain routing information.
ISDN charges in some installations have easily exceeded $4,000/month for a single site as a result of being poorly designed and managed. When the outrageous phone bill is received, it is too late; the cost has been incurred. Cisco highly recommends the use of proper network management to back up careful design, to ensure that excessive charges are not experienced. Depending on the protocols your network runs, you might want to use a combination of the techniques described in this section, which are as follows:
Traffic Analysis
Tariff Structure
User Education
Using SNMP
Cisco Enterprise Accounting (CEA) for ISDN
AAA Accounting
Most ISDN solutions can remain cost-effective only as long as the ISDN B channels are kept idle most of the day. The general rule-of-thumb is that Frame Relay will make a more cost-effective solution at some application-dependent number of hours per day. (The point at which it is more cost-effective to use a leased-line solution depends on the cost structures for each point-to-point application.)
Each networking application and protocol has its own set of challenges. E-mail clients may be set to periodically poll POP servers. Network Time Protocol might be desired to support clock synchronization. To provide total control over when the DDR connections are made, the network designer must carefully consider the following issues:
Which sites can initiate connections based on traffic?
Is dial-out required to SOHO sites? For network or workstation management?
Which sites can terminate connections based on idle links?
How are directory services and routing tables supported across an idle connection?
What applications need to be supported over DDR connections? For how many users?
What unexpected protocols might cause DDR connections? Can they be filtered?
Are dialer filters performing as expected?
Guidelines should be provided to users about how to avoid and/or eliminate excessive ISDN charges. These guidelines will be the result of first determining what applications are required over these connections. Packet-tracing tools can be used very effectively to determine how to minimize or eliminate unnecessary DDR connections. For example:
Sending and receiving e-mail should be manual, if possible.
Windows Networking may require periodic directory services traffic.
AppleShare servers will need to be disconnected to avoid tickle packets.
DB-accessing applications, such as scheduling software, may require logging out when not in use.
Some ISDN service providers charge a per-connection and per-minute charge, even for local calls. It is important to consider local and long-distance tariff charges when selecting DDR design and parameters. ISDN callback can be used to centralize long-distance charges, which can significantly reduce administrative overhead and provide opportunities for reduced rate structures. ISDN callback can also enhance the security environment.
End users should be trained to keep their ISDN routers visible and monitor the status of their B-channel LEDs on their BRI devices. If B channels are up when they are not using networking applications, they should alert network managers. User education can be very effective in helping to avoid excessive ISDN charges.
The Simple Network Management Protocol (SNMP) uses Management Information Bases (MIBs) to store information about network events. Currently, no industry-standard ISDN MIB is available, but as of Cisco IOS Software Release 10.3(3), two Cisco ISDN MIBs are available. With these MIBs, SNMP-compliant management platforms (for example, HP OpenView or SunNet Manager) can query Cisco routers for ISDN-related statistics.
The Cisco ISDN MIB focuses primarily on ISDN interface and neighbor information. It defines two MIB groups: demandNbrTable and demandNbrEntry. Table 11-2 lists some of the MIB variables available in the ISDN MIB. Cisco Enterprise Accounting for ISDN can provide management access to Call History Data using this MIB.
Table 11-2. Cisco ISDN MIB Variables
| MIB Object | Description |
|---|---|
| demandNbrPhysIf | Index value of the physical interface that the neighbor will be called on; on an ISDN interface, this is the ifIndex value of the D channel. |
| demandNbrMaxduration | Maximum call duration in seconds. |
| demandNbrLastduration | Duration of last call in seconds. |
| demandNbrAcceptCalls | Number of calls accepted from the neighbor. |
| demandNbrRefuseCalls | Number of calls from neighbor that the router has refused. |
The Cisco Call History MIB stores call information for accounting purposes. The goal is to provide an historical view of an ISDN interface, including the number of calls that have been placed and call length. Most Call History MIB variables are in the ciscoCallHistory MIB group. Table 11-3 lists some of the MIB variables.
Table 11-3. Cisco Call History Variables
| MIB Object | Description |
|---|---|
| ciscoCallHistoryStartTime | The value of sysUpTime when this call history entry was created; this variable can be used to retrieve all calls after a specific time. |
| ciscoCallHistoryCalledNumber | The number that was used to place this call. |
| ciscoCallHistoryCallConnection Time | The value of sysUpTime when the call was connected. |
| ciscoCallHistoryCallDisconnect Time | The value of sysUpTime when the call was disconnected. |
The Cisco ISDN MIBs assume SNMP support on the network. If an SNMP-compliant management platform is present, the Cisco ISDN MIBs deliver valuable information about ISDN links. In particular, the Call History MIB provides critical information about ISDN uptime, which is useful for tracking ISDN charges.
Cisco offers a wide range of ISDN-based products in response to a variety of networking needs. The Cisco IOS software provides a number of features that maximize ISDN performance and minimize ISDN usage charges, such as snapshot routing, access lists, NBP filtering (for AppleTalk), and watchdog and keepalive packet control (for IPX).
CEA for ISDN is a software application that runs on Windows NT. CEA for ISDN can be used to monitor the ISDN Call History-MIB and provide network managers with Call Detail Records, including cost estimates.
AAA Accounting can be implemented to provide feedback of PPP session connect times. AAA Accounting is transported to TACACS+ or RADIUS servers, where the data can often be accessed with standard SQL tools for scheduled and immediate reporting. The following command enables AAA Accounting records for PPP sessions:
aaa accounting network stop-only
When troubleshooting ISDN, it is important to keep in mind the ISDN protocol architecture and how it relates to the OSI reference model. ISDN works on the lower three layers of the OSI reference model: the physical, data link, and network layers. On the physical layer, there are protocols, such as I.430 for BRI and I.431 for PRI, which are shared between both the B and D channels. On the data link layer, PPP is used as the B-channel protocol. HDLC could be used too, but there are more advantages to using PPP. LAPD, which is also known as Q.921, is used as the D-channel protocol on the data link layer. On the network layer, there are protocols such as IP, IPX, and so on, which are used on B channels; and Q.931, which is used on the D channel.
When troubleshooting ISDN, this structure is important. It is important to be systematic and go step-by-step. Troubleshoot physical layer issues first, before troubleshooting the data link layer or network layer problems. Always troubleshoot both ends of the ISDN connection; you'll actually clear up a lot of issues (discussed in more detail later) when troubleshooting these links.
Before troubleshooting the ISDN link, you must first ping the remote ISDN interface. If you can ping the remote ISDN interface, your ISDN connection is working fine. If you cannot ping the remote ISDN interface, then at this point do not bother to look at the routing or cost issues. Keep in mind that an ISDN interface is a DDR interface, and in Cisco IOS the DDR interface does not come up unless there are some interesting packets to trigger the ISDN link. To check on the router configuration and see whether there is any interesting traffic, you can use the following debug commands on the router:
Use the preceding debug commands to monitor and see whether there are any packets triggering the ISDN link. In the following debug dialer events command, you can see that there are interesting packets to bring up the ISDN link, and you can also see the source and destination IP address:
Router #debug dialer events
Dialing cause: BRI0: ip (s=20.20.20.20 d20.20.22.22)
Router # debug dialer packets
BRI0: ip (s=20.20.20.20, d=20.20.22.22), 100 bytes, interesting (ip PERMIT)
Always begin your troubleshooting at the physical layer first, before troubleshooting the data link layer or network layer problems. A very handy command in IOS gives a snapshot of the status of all three layers. By looking at the show isdn status command, you can jump to the appropriate layer and troubleshoot that particular layer. The following is the output of the show isdn status command, and it shows the status of all three layers in case of PRI or BRI. Notice that in the following output the Layer 1 status is deactivated and that there is something wrong on the physical layer. Remember that if a layer is not active, none of the upper layers are going to be active.
Router # show isdn status ISDN BRI0 interface Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: No Active Layer 3 Call(s) Activated dsl 0 CCBs are 0, Allocated = 0
Two things could be wrong in this case: an external problem or an internal problem to the router. If the problem is external, it could be a cable problem, telco problem, NT1 problem; or perhaps, the network has never acknowledged the router's request to activate the ISDN interface. An internal problem to the router means that the router never requested the network to activate the ISDN interface.
A very handy debug command in IOS shows whether the problem is internal to the router or external to the router. The command is called debug bri. The debug bri command is a communication between the IOS and ISDN chipset on the ISDN interface. The write_sid commands are sent to the ISDN chipset. Different types of Cisco routers show different wrote values, such as wrote = E, wrote = 1B, and so on. In other words, when you see write_sid, it means that the router is trying to activate the line and is instructing the ISDN chipset to generate the HDLC flags. wrote = 1B means that the ISDN chipset is sending these HDLC flags. If everything is working okay, these write_sid are followed by SID interrupts with a status reg = C. These SID interrupts are sent from the chipset to the IOS indicating status reg = C—where C means that the activation bit (A bit) just turned from 0 to 1, which is received from the network. In the newer IOS versions, you will also see a message-received activation indication, which also means that the activation bit (A bit) just turned from 0 to 1, which is received from the network. In the following debug outputs, the router is doing its job and the network is also doing its job by replying to the router request:
BRI: write_sid: scp = 0, wrote = 1B BRI: write_sid: scp = 0, wrote = 20 BRI: write_sid: scp = 0, wrote = 3 SID interrupt. status reg = C BRI: Received activation indication… BRI: write_sid: scp = 0, wrote = E BRI: write_sid: scp = 0, wrote = E
When things are not working okay, you see something like the following on the same debug bri output. T3 is the descriptor block in the IOS, and you can notice in the following debug output, the router is sending the write_sid, which means that the router is trying to activate the line and instructing the ISDN chipset to generate the HDLC flags. wrote = 3 means that the ISDN chipset is sending these HDLC flags. When the router is tired of sending the HDLC flags, it starts the T3 timer and tries to send some more HDLC flags. Then the T3 timers expire, and the router puts the BRI interface to deactivation state. In the following debug output, the router is doing its job, but the network is not doing its job because the network is not replying by turning the activation bit (A bit) from 0 to 1. Now the problem has been identified as external to the router. In most cases, this problem is related to the cable, NT1, or the telco.
BRI: Starting Power Up timer for unit = 2 BRI: write_sid: wrote 3 for subunit 2, slot 1 BRI: Starting T3 timer after expiry of Power Up timeout for unit = 2, current state is F4 (…) BRI: write_sid: wrote 92 for subunit 2, slot 1 BRI: write_sid: wrote 93 for subunit 2, slot 1 BRI: T3 timer expired for unit = 2, current state is F2 BRI: write_sid: wrote 1 for subunit 2, slot 1 BRI: write_sid: wrote 0 for subunit 2, slot 1 BRI: Forced interrupt for subunit 2, slot 1 is F BRI: write_sid: wrote FF for subunit 2, slot 1 BRI: write_sid: wrote 1 for subunit 2, slot 1 BRI: write_sid: wrote 0 for subunit 2, slot 1 BRI: Deactivation for unit = 2, current state is F2
When the physical layer has no problems and Layer 1 is activated, you would see the following from show isdn status or show controller bri:
Layer 1 Status: ACTIVATED
or
Layer 1 is ACTIVATED
Troubleshooting PRI Layer 1 problems is not specific to ISDN. You would troubleshoot the PRI interface in exactly the same way as you would troubleshoot a T1 connection. When things are okay, it means that no alarms are detected on the T1. Make sure that you see the following under the show controller t1 output:
Router # show controller t1
T1 2/0 is up
Description: Primary Rate Interface to DMS-100
No alarms detected
Framing is ESF, Line Code is B8ZS, Clock Source is Line
Data in current interval (165 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 1 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 12 Unavail Secs
When things are not okay, you would see that the transmitter is sending remote alarms, which is not a good sign. The main items to look at in the preceding output are the status of the line, alarms, line-code and path-code violations, and slip secs. The line status will tell whether the T1 is up, down, or administratively down. The alarms section is very important; it tells what type of problem may be present on the line. The presence of any alarm indicates a major problem on the line. Therefore, whenever you encounter a T1 in an alarm state, you should verify the configuration accuracy of the framing and line-coding parameters. You would see the following when there is something wrong on the physical layer in a PRI environment:
Router # show controller t1 T1 2/1 is down Transmitter is sending remote alarm Receiver has loss of signal Framing is ESF, Line Code is B8ZS, Clock Source is Line Data in current interval (160 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 160 Unavail Secs
Now that you have seen what kind of problems can occur on the physical layer and how to solve them, it is time to consider data link layer (Layer 2) issues. If the show isdn status on the router produces the following output, the Layer 1 status is active (which is good), but now the Layer 2 status is not active:
Router # show isdn status The current ISDN Switchtype = basic-net3 ISDN BRI0 interface Layer 1 Status: Activated Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: No Active Layer 3 Call(s) Activated dsl 0 CCBs are 0, Allocated = 0
If you recall from the previous discussion, two types of protocols run on this layer: PPP (B channel) and LAPD (D channel) protocols. Troubleshoot the Layer 2 problems separately for B and D channels. The ISDN standard does not define a particular Layer 2 protocol for the B channel. In most of the cases, PPP is used because of its versatile nature. On the D channel, LAPD (Link Access Procedure on D channel) should be used according to the ISDN standard. LAPD is also known as Q.921. The Q.921 signaling is used between the local router and the local ISDN switch. Q.921 signaling is not end-to-end.
In the BRI environment, the terminal endpoint identifier (TEI) process takes place on Layer 2. The reason for the TEI assignment in a BRI environment is that on an S/T connection on a single BRI interface you can connect up to eight devices, and each device can have a unique TEI number, which is assigned from the local ISDN switch. By TEI assignment, the switch can differentiate between the multiple devices connected to the S/T bus on the BRI interface. The router sends an identification request (IDREQ) to the switch; and if everything is working okay, the switch acknowledges the IDREQ with an identification assigned (IDASSN).
The IDREQ and IDASSN packets contain two important values: the action indicator (AI) and the reference indicator (RI). Whenever the router sends an IDREQ to the switch, the AI is always set to 127, which is a wildcard and means that router is asking the switch to assign any TEI value. Valid TEI values range from 64 to 126 and are assigned from the switch. TEI values from 0 to 63 are reserved for fixed TEI. In the early days of ISDN, people used to configure TEI values manually; now, however, all the TEI negotiation and assignment are dynamic. Always keep in mind that in a PRI environment, only one device is connected to the ISDN interface, so there is no need for TEI; therefore, you would always notice that the TEI value is 0.
RI in the IDREQ packet always has a random number attached to it. This number should always match in the IDREQ and IDASSN messages. The IDASSN message from the switch must be the response to the same IDREQ message sent to the switch. Enabling debug isdn q921 on the router reveals the assignment process. The following debug output shows that the router is sending the IDREQ with RI = 15454 (which is a random value) and AI = 127 (which is a wildcard). The IDASSN from the switch has RI = 15454 (which is the same random value sent by the router) and AI = 64. TEI 64 is assigned by the switch and is a valid TEI value.
Router # debug isdn q921
TX -> IDREQ ri = 15454 ai = 127
RX <- IDASSN ri = 15454 ai = 64
When something is wrong on Layer 2, the IDREQ is retransmitted with different random RI values and with an AI value of 127 (which is a wildcard); but still there is no IDASSN message from the switch. In such a case, the router is doing its job, but the local switch is not replying with an IDASSN message. Also keep in mind that sometimes the switch does reply with the IDASSN message, but assigns an invalid TEI value to the router, which is also a malfunctioning of the switch.
Router # debug isdn q921
TX -> IDREQ ri = 89898 ai = 127
TX -> IDREQ ri = 90976 ai = 127
TX -> IDREQ ri = 23434 ai = 127
After the local switch assigns the router a valid TEI, the router attempts to set up an HDLC connection with the switch. This is traditional HDLC. The router sends a set asynchronous balance mode extended (SABME) message on the TEI value 64 (which was just assigned by the local switch). SAPI (service access point identifier) behaves like a type field in Ethernet. It identifies the upper-layer protocol. If you see the debug q921 output, you would see that the value of SAPI is 0, which means the Layer 3 D-channel protocol is Q.931. The SABME message is answered by a UA message, which is sent by the local switch. UA means that the SABME ID was accepted by the switch.
Router # debug isdn q921
TX -> SABMEp sapi = 0 tei = 64
RX <- UAf sapi = 0 tei = 64
After the data-link connection is established, information (INFO) frames are exchanged between the router and the local switch. INFO frames get acknowledged by other INFO frames or receive ready (RR) frames. Keep in mind that these INFO frames, which are sent on the D channel, have the Q.931 signaling messages. INFO frames have NS (send sequence number) and NR (next expected sequence number) fields.
Router # debug isdn q921
RX <- INFOc sapi = 0 tei = 64 ns = 0 nr = 0
TX -> RRr sapi = 0 tei = 64 nr = 1
TX -> INFOc sapi = 0 tei = 64 ns = 0 nr = 1
If no INFO frames are exchanged between the router and local switch, you would see the periodic exchange of RR frames. Exchange of RR frames is like a keepalive mechanism between the router and the local switch—that is, the Layer 2 connection is established, but there are no INFO frames to send. You would see something like the following in the debug output:
Router # debug isdn q921
RX <- RRp sapi = 0 tei = 80 nr = 5
TX -> RRf sapi = 0 tei = 80 nr = 4
RX <- RRp sapi = 0 tei = 80 nr = 5
TX -> RRf sapi = 0 tei = 80 nr = 4
RX <- RRp sapi = 0 tei = 80 nr = 5
TX -> RRf sapi = 0 tei = 80 nr = 4
RX <- RRp sapi = 0 tei = 80 nr = 5
TX -> RRf sapi = 0 tei = 80 nr = 4
When everything is working well on Layer 2, you should see something like the following on the debug isdn q921 output. All these fields are explained in the previous discussion.
Router # debug isdn q921
TX -> IDREQ ri = 15454 ai = 127
RX <- IDASSN ri = 15454 ai = 64
TX -> SABMEp sapi = 0 tei = 64
RX <- UAf sapi = 0 tei = 64
RX <- INFOc sapi = 0 tei = 64 ns = 0 nr = 0
TX -> RRr sapi = 0 tei = 64 nr = 1
TX -> INFOc sapi = 0 tei = 64 ns = 0 nr = 1
Now, the show isdn status command will reveal the TEI value and the Layer 2 status shows that state = MULTIPLE_FRAME_ESTABLISHED:
Router # show isdn status Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0
Notice in the preceding output that the TEI = 0, which means it is a PRI link; notice also, however, that state = MULTIPLE_FRAME_ESTABLISHED on Layer 2. If it were a BRI environment, you would see a valid TEI value (as stated earlier, a value between 64 and 126). This output also shows that Layer 3 is not active.
Now it is important to consider Layer 3 D-channel issues. If you recall from the previous discussion, two types of protocols run on this layer: IP, IPX, and such (B-channel) protocols; and Q.931 (D-channel) protocols. Troubleshoot the Layer 2 problems separately for B and D channels. The ISDN standard does not define a particular Layer 2 protocol for the B channel; IP, IPX, and other Layer 3 protocols could be used, depending on the Layer 2 B-channel protocol. On the D channel, Q.931 should be used according to the ISDN standard. The Q.931 signaling is used between the local router and the local ISDN switch. Q.931 enables you to tell the switch that you want to dial a number; the switch then tries to make that call. Q.931 signals get translated to corresponding SS7 signals at the local switch (because inside the ISDN network, SS7 signaling is used). These SS7 signals again get translated to the corresponding Q.931 signals at the remote ISDN switch. Q.931 signaling is not end-to-end.
Q.931 is a Layer 3 signaling protocol for D channels in an ISDN environment. Q.931 comes in different "flavors"; because in the beginning of the ISDN era, Q.931 was not standardized and several major telcos wrote their own versions of it. Although these different versions of Q.931 are similar, you need to make sure that you are configuring exactly the same switch type on the router as is configured on the local ISDN switch (this does, after all, concern data communication). If the switch is configured for ISDN switch type basic-ni1, the router should be configured for the same switch type, of which several are currently available. There are efforts to standardize basic-net3 as the Pan-European standard and basic-ni1 as the North American standard.
Q.931 has 37 different ways for call setup. It is a very flexible and wide protocol. Frame Relay SVC signaling and ATM UNI signaling are based on Q.931 signaling. debug isdn q931 can be activated on the router to see the Q.931 signals and see where there is a failure. To see the whole picture, you need to turn on this debug command on both sides of the connection. All the Layer 3 Q.931 signals get transmitted into Layer 2 INFO frames.
Router # debug isdn q931 TX -> INFOc sapi = 0 tei = 80 ns = 6 nr = 6 SETUP pd = 8 callref = 0x02 Bearer Capability i = 0x8890 Channel ID i = 0x83 Called Party Number i = 0x80, '555555' RX <- INFOc sapi = 0 tei = 80 ns = 6 nr = 7 CALL_PROC pd = 8 callref = 0x82 Channel ID i = 0x89 RX <- INFOc sapi = 0 tei = 80 ns = 7 nr = 7 CONNECT pd = 8 callref = 0x82
Every time the router places a call, it must send a setup packet out. The setup packet always has a protocol descriptor of pd = 8, and it generates a random hex value for the callref. The callref is used to track the call. If two calls are placed, for example, it can tell which call the RX (received) message is for. 0x8890 means a 64-kbps data call. 0x8890218F means it is a 56-kbps data call, and 0x8090A2 means it is a voice call. Channel ID 0x83 means that the router is asking the switch to assign it a B channel. Called-party number is 5555555.
CALL_PROC means that the call is proceeding. The callref uses a different value for the first digit (to differentiate between TX and RX); the second digit is the same (SETUP had a 2 for the last digit and CALL_PROC also has a 2). Channel ID i = 0x89 means B channel one; 0x8A is B channel two. This sequence of events is the same every time a call is placed. The router is completely dependent on the phone company to assign a B channel. If the switch doesn't assign the router a channel, the call won't work. In this case, a CONNECT message with the same reference number as received for CALL_PROC (0x82) is received from the switch.
After Layer 1 and Layer 2 are up, the first thing that happens before any of the Layer 3 SETUP messages are sent is that the router sends the service profile identifier (SPID) to the switch. SPIDs are assigned by the service provider and they should be configured on the router in exactly the same way as they are provided by the service provider. SPIDs are usually 12 to 14 digits long and are comprised of the 10-digit telephone number plus some extra digits. SPIDs are used only in North America, and only a few switch types require SPIDs (for example, dms-100 and ni-1). Not all the switch types require the SPID number. SPIDs are used only in the BRI environment.
SPIDs are used to bind a specific terminal to a specific service profile. SPIDs are validated by the switch with a handshake between the router and the local ISDN switch. A valid SPID is acknowledged by an endpoint ID; if the SPID is rejected by the switch, you get an "Invalid IE contents" message from the switch. This negotiation can be seen by using debug isdn q931. In the following debug output, you can see that the router is sending SPIDs to the switch one by one. Both the SPIDs are acknowledged by the switch because there is an endpoint ID for each SPID sent. These SPID numbers are ASCII-coded, where 36 means 3, 31 means 1, and so on. In the following output, pd means protocol descriptor. Sometimes, you must configure the LDN after the SPIDs. LDN is configured to receive incoming calls on the second B channel.
Router # debug isdn q931
TX -> INFORMATION pd = 8 callref = (null)
SPID Information i = 0x363133373835323631323030
RX <- INFORMATION pd = 8 callref = (null)
ENDPOINT IDent i = 0xF180
TX -> INFORMATION pd = 8 callref = (null)
SPID Information i = 0x363133373835323631333030
RX <- INFORMATION pd = 8 callref = (null)
ENDPOINT IDent i = 0xF080
In the following debug output, you can see that the SPID sent to the switch is rejected and there is an "Invalid IE contents" message from the switch. This indicates that the SPIDs are incorrect; in such a case, you must determine that the router and the switch are configured for the correct SPIDs.
TX -> INFORMATION pd = 8 callref = (null) SPID Information i = 0x31323334353536373736 RX <- INFORMATION pd = 8 callref = (null) Cause i = 0x82E43A–Invalid IE contents
The command sh isdn status at this point will show the status of the SPIDs. In the following output, both SPIDs are rejected because they are invalid:
Router # show isdn status
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 88, State = MULTIPLE_FRAME_ESTABLISHED
Spid Status:
TEI 88, ces = 1, state = 6(not initialized)
spid1 configured, no LDN, spid1 sent, spid1 NOT valid
TEI Not Assigned, ces = 2, state = 1(terminal down)
spid2 configured, no LDN, spid2 NOT sent, spid2 NOT valid
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 1 CCBs = 0
After the switch validates the SPIDs, you can place a call. Call can be refused for several reasons. If the other end is set up for call screening and only allows certain numbers, and you are not one of those, your call might fail. There could also be something wrong inside the network. In the following debug isdn q931 output, the ISDN connection was never made, not even for the one second. If you send the SETUP message, you can get a RELEASE_COMP message right away with a cause ID for the call rejection. As the following debug output shows, this is a Q.931 layer issue. It is important to distinguish between the connection that never came up (which points to the Q.931 issue) and the connection that came up for a couple of seconds but then got disconnected (which means that the Q.931 is okay, but that there are PPP issues).
Router # debug isdn q931 TX -> SETUP pd = 8 callref = 0x01 Bearer Capability i = 0x8890 Channel ID i = 0x83 Called Party Number i = 0x80, '4839625' RX <- RELEASE_COMP pd = 8 callref = 0x81 Cause i = 0x8295 - Call rejected
RELEASE_COMP messages are followed by a cause ID for the call rejection. The cause ID is a hex value, and this value has a meaning. You can find the real cause by decoding the hex value and following up with your provider. If the call is connecting and then disconnecting after a couple of seconds, the Q.931 is okay, but you are running into PPP issues. PPP runs on the B channel of ISDN, and it is transparent to the carrier. PPP is based on RFC 1548 and others. Three main components comprise PPP: multiprotocol encapsulation, Link Control Protocol (LCP), and Network Control Protocols (NCPs). LCP is used to establish and maintain the data link and option negotiation (such as, use CHAP). NCPs are used to establish and configure network layer protocols, including protocol-specific option negotiation (addresses) and different Layer 3 protocols (IPCP, IPXCP, ATCP, and so on). In PPP negotiation, the LCP options are negotiated, and then the NCP options are negotiated.
In LCP negotiation, the Configure-Req proposes certain options; if all options are acceptable, the remote station returns a Configure-ACK. All PPP negotiations are double negotiation, or two-way negotiation. You can see this PPP negotiation by turning on certain debugs on the Cisco routers. The following debug output shows an incoming CONFREQ and an outgoing CONFACK message. I means incoming, and O means outgoing.
Router # debug ppp packet PPP BRI: B-Channel 1: I LCP CONFREQ(1) id 2 (4) PPP BRI: B-Channel 1: O LCP CONFACK(2) id 2 (4)
The following debug output shows the negotiation for the PAP authentication type (value = C023) and the magic number for the loop avoidance in the connection. If it were a CHAP authentication, you would see a hex value = C223.
Router # debug ppp negotiation ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C023/0 ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 8C01B4 ppp: config ACK received, type = 3 (CI_AUTHTYPE), value = C023 ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 8C01B4
show interface bri 0 1 tells whether the state of LCP is open or closed. If the options are negotiated, the state should be open. The following output indicates that the LCP state is open, but that the NCP options have not yet been negotiated:
Router # show interface bri 0 1 BRI0: B-Channel 1 is up, line protocol is up Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) lcp state = OPEN ncp ipcp state = REQSENT ncp osicp state = NOT NEGOTIATED ncp ipxcp state = NOT NEGOTIATED ncp xnscp state = NOT NEGOTIATED ncp vinescp state = NOT NEGOTIATED ncp deccp state = NOT NEGOTIATED ncp bridgecp state = NOT NEGOTIATED ncp atalkcp state = NOT NEGOTIATED Last input 0:00:00, output 0:00:00, output hang never Last clearing of "show interface" counters never Output queue 0/40, 0 drops; input queue 0/75, 0 drops Five minute input rate 0 bits/sec, 0 packets/sec Five minute output rate 0 bits/sec, 1 packets/sec 9099 packets input, 855915 bytes, 0 no buffer
If the LCP state is closed, the PPP options are mismatched on both of the devices (unless it is a 56-kbps link). Most of the long-distance connections in North America and international connections to and from North America force you down to 56 kbps. Sometimes over these connections, the high-order bit of the data you send is overwritten by the signaling information, possibly changing the data and making CRC errors "visible" to the device on the other end. In this case, you would use the V.110 spec for 56 kbps. In V.110, of the eight bit positions for every B channel, only seven bits are used for data transfer; the eighth bit is filled with junk, thus saving data from corruption.
In several cases, the interswitch connections may limit the speed to 56 kbps. There are different types of bearer capabilities, and they specify whether the call is a 56-kbps call and whether it is using V.110 rate adaptation. If the international signaling protocol in the ISDN network is adapted to ISDN, this 56-kbps indication will be carried all the way to the remote subscriber and the remote subscriber will treat the call as 56 kbps. Sometimes, on international links the carrier eats up this 56-kbps indication because the carrier might be using an old version of SS7. The receiving side thinks that the call is 64 kbps. The dialer map statement on the Cisco router enables you to specify the speed of the outgoing call. The default is 64 kbps. On the debug isdn q931, you might see a message that says "Call not end-to-end ISDN." If you see this message, you can configure isdn not-end-to-end 56 on the router; then the router treats the call as a 56-kbps call.
Router # debug isdn q931 TX -> SETUP pd = 8 callref = 0x02 Bearer Capability i = 0x8890 Channel ID i = 0x83 Called Party Number i = 0x80, '5555555' RX <- CALL_PROC pd = 8 callref = 0x82 Channel ID i = 0x89 Locking Shift to Codeset 5 Codeset 5 IE 0x2A i = 0x808E0C, 'OUTSIDE CALL' RX <- PROGRESS pd = 8 callref = 0x82 Progress Ind i = 0x8A81 - Call not end-to-end ISDN RX <- CONNECT pd = 8 callref = 0x82 Progress Ind i = 0x8482 - Destination address is non-ISDN
After LCP and 56 K issues have been dealt with, the next thing to consider is the PPP authentication type. HDLC could be used for Layer 2 B-channel protocol, but it does not support any authentication type. Some do this to get the ISDN up and running first, and then worry about the authentication later, which is the wrong approach because PAP or CHAP resolve the prefix issues. CHAP is always preferred over PAP authentication because CHAP performs MD5 hash function. If you turn on debug ppp chap on the router, you can see the handshaking process:
Router # debug ppp chap ISDN Event: Connected to 5555555 on B1 at 64 kbps BRI0: B-Channel 1: PPP AUTH CHAP input code = 1 id = 10 len = 14 BRI0: B-Channel 1: PPP AUTH CHAP input code = 2 id = 16 len = 26 BRI0: B-Channel 1: remote passed CHAP authentication BRI0: B-Channel 1: PPP AUTH CHAP input code = 3 id = 10 len = 4 BRI0: B-Channel 1: Passed CHAP authentication with remote…
Also, you can use a show dialer command on both sides and see whether the remote router's name is in the output. If you see this name on both sides, CHAP or PAP is passed because it learns this name via PAP or CHAP. If you are failing authentication, make sure that your password for authentication is exactly the same on both sides, and keep in mind that the passwords are case-sensitive. In the following example, you know that the CHAP or PAP is passed because the name is displayed (SANJOSE) via PAP or CHAP:
Router # show dialer BRI0 - dialer type = ISDN Dial String Successes Failures Last called Last status 4085555555 0 0 never 0 incoming call(s) have been screened BRI0: B-Channel 1 - dialer type = ISDN Rotary group 0, priority = 0 Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Time until disconnect 85 secs Connected to 4085555555 (SANJOSE)
PAP or CHAP enables you to know which site is connected. Without PAP or CHAP, this would be based on the ISDN calling number, which is often problematic because the calling number may not have been presented, or the calling number may be presented with or without prefixes. The carriers can change the numbers; sometimes they remove a prefix and sometimes they add a prefix. Sometimes they remove a number and sometimes they add a number, and you do not want to rely on the prefix for an ISDN connection. When you introduce CHAP or PAP, you resolve this prefix issue because you are not relying on a prefix anymore. With PAP or CHAP, you are relying on the host name of the remote router, which is learned by CHAP or PAP.
After the LCP and authentication issues are considered, you run into NCP issues. NCPs negotiate and verify network-level parameters. There is a different NCP for each different network protocol (such as IPCP for IP, IPXCP for IPX, and so on). An NCP configure-request is sent for an NCP to the other side, which is acknowledged by an NCP configure-acknowledge message if that NCP is supported by the other side. If the other side does not support that NCP, the sending side gets a "NCP configure-not-acknowledge" message. Both sides exchange these messages and agree on NCPs that are supported by both ends. The negotiation is shown in the following debug output, in which IPCP is negotiated between both ends, where O means outgoing, and I means incoming:
Router # debug ppp negotiation BRI0: B-Channel 1: O IPCP CONFREQ id D (10) Type3 (6) 147 211 117 40 BRI0: B-Channel 1: I IPCP CONFREQ id C (10) Type3 (6) 147 211 117 1 BRI0: B-Channel 1: O IPCP CONFACK id C (10) Type3 (6) 147 211 117 1 BRI0: B-Channel 1: I IPCP CONFACK id D (10) Type3 (6) 147 211 117 40
The NCP state is also in the following output command. In the following output, the IPCP is negotiated between both ends, and the IPCP state is open. OSICP and XNSCP are not negotiated because they have not been tried. IPXCP is in request state, which means that a negotiation was tried but did not work, maybe because the IPX network number on the remote ISDN interface was not configured.
Router # show interface bri 0 1
BRI0: B-Channel 1 is up, line protocol is up
Hardware is BRI
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation PPP, loopback not set, keepalive set (10 sec)
lcp state = OPEN
ncp ipcp state = OPEN
ncp osicp state = NOT NEGOTIATED
ncp ipxcp state = REQSENT
ncp xnscp state = NOT NEGOTIATED
Because all three layers are up and running, you should now be able to ping the remote IP address of the ISDN interface. Now that you can ping the remote ISDN interface, you can look at the routing issues. At this point, if you cannot ping an IP address somewhere behind the remote side ISDN interface, the problem is not related to ISDN connectivity. Also, make sure that you have the interesting traffic and dialer filters defined correctly and do not wait for the first ISDN bill. Use show dialer, debug dialer, and show isdn history IOS commands to monitor the interesting traffic.
Increasing availability and decreasing costs are making ISDN an excellent choice for many networking applications. Cisco IOS features allow the building of large and flexible ISDN solutions. DDR is used for call initiation and termination. Virtual profiles can be used to easily scale mass ISDN dial-in solutions. Extra care must be taken, however, to ensure that ISDN costs are controlled. Troubleshooting ISDN is also discussed in detail in this chapter.