Internetwork Design Guide -- Designing ISDN Internetworks

From DocWiki

Latest revision as of 21:26, 16 October 2012

The Public Switched Telephone Network (PSTN) has been transformed into an Integrated Systems Digital Network (ISDN). Implementation of Signalling 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 provide end-to-end digital paths.

Previous 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 internetworking 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, SOHO and 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 internetworks.

Figure: ISDN can support hybrid (analog and digital) dial solutions shows ISDN being used to concurrently serve ISDN and POTS (analog modem) connected remote sites in a hybrid dial solution.

Figure: ISDN can support hybrid (analog and digital) dial solutions

Applications of ISDN in Internetworking

ISDN has many applications in internetworking. 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 (SOHO) dial-up 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 NAS (Network Access Server) unless otherwise stated. In this section, the following issues are addressed:

• Dial-On-Demand Routing
• Dial Backup
• SOHO Connectivity
• Modem Aggregation

Dial-On-Demand Routing

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: DDR creates connectivity between ISDN sites illustrates the use of DDR for internetworking between ISDN connected sites.

Figure: DDR creates connectivity between ISDN sites

Dial Backup

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: ISDN can back up primary connectivity between sites.

Figure: ISDN can back up primary connectivity between sites

SOHO Connectivity

Small Office and Home Office sites can be 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 available over POTS and modems.

SOHO designs typically involve dial-up 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: SOHO sites can appear to the Cisco IOS NAS as a single IP node.

Figure: SOHO sites can appear to the Cisco IOS NAS as a single IP node

Modem Aggregation

Modem racking and cabling has been eliminated by 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: ISDN can support hybrid (analog and digital) dial solutions.

Building Blocks of ISDN Solutions

ISDN itself does not solve internetworking problems. By using either DDR or user-initiated sessions, ISDN can provide the internetwork designer a clear data path over which to negotiate PPP links. A Public Switched Telephone Network to provide internetwork 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

ISDN Connectivity

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 signalling and control channel and can also be used for low-bandwidth data applications.

BRI service is provided over a groomed local loop that is traditionally used for switch to analog phone service. BRI delivers to the subscriber 2 64 Kbps B channels and 1 16 Kbps D channel (2B+D).

PRI service is provided on traditional T1 & E1 leased lines between the customer premise equipment (CPE) and the ISDN switch:

• T1-based PRI provides 23 B channels and 1 D channel (23B+D).
• E1-based PRI provides 30 64 Kbps B channels and 1 64 Kbps D channel (30B+D).

Provisioning of both PRI and BRI services have very stringent requirements on 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: Connectivity to ISDN using BRI and PRI.

Figure: Connectivity to ISDN using BRI and PRI

Datagram Encapsulation

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 internetworking 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 internetworking peers each time a connection is established. PPP links can then be used by network protocols such as IP and IPX to establish internetwork connectivity. PPP solutions can support bandwidth aggregation using MultiLink PPP to provide greater throughput for internetworking applications.

DDR: Dial-On-Demand Routing

When building internetworking 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 internetworking traffic. DDR can spoof internetwork routing and directory services in numerous ways to provide the illusion of full-time connectivity over circuit switched connections. Refer to Designing DDR Internetworks, for a discussion of DDR design.

Security Issues

Because your internetwork 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.

Cost Containment Issues

A primary goal of selecting ISDN for your internetwork 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.

ISDN Connectivity Issues

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

Establishing BRI Connectivity

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: The BRI local loop connected to ISDN shows a typical BRI installation.

Figure: The BRI local loop connected to ISDN

BRI Hardware

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 internetworking 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 Designing DDR Internetworks.
  • 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 Cisco3600 and Cisco4x00 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. Cisco200 Series PC Cards can provide ISDN services to a PC.

BRI Configuration

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 de-multiplexes 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 is configured on the ISDN device. For Cisco IOS releases up to 11.2, the configured ISDN switch-type is a global command (note 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 France 

• Cisco 700 switch types.
  On Cisco 700 Series routers, use the set switch command, which has the following options when running the US 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. For example, the first B channel can be configured for data, 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 8358664  

• • These 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 

Confirming BRI Operations

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 Layer3 (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: 

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 

BRI Notes

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 instead of 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 Sub-Addressing-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 Sub-Addressing.
• 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  

Establishing ISDN Primary Rate Interface (PRI)

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.

PRI Configuration

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 Cisco5200.

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.

Confirming PRI Operations

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 relatively clean operation. Use the Cisco IOS exec command show isdn status to verify 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 

ISDN End-to-End Considerations

The following ISDN end-to-end considerations are covered in this section:

• Signaling System 7 (SS7)
• Data Path Speed

Signaling System 7

Signaling System 7 (SS7) provides telephone switches with out-of-band signalling capabilities for telephony trunks (switch to switch DS0 connections). End-to-End call management (such as setup and tear-down) uses ITU specification Q.931 and is extended to PRI/BRI internetworking devices over the ISDN D channel.

Out-of-Band signalling via SS7 provides numerous benefits to internetworking 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:

• Incoming 64 Kbps data call

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'  

• Incoming 56 Kbps data call

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' 

• Incoming voice call

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 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 may 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 non-digital 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. 

Data Path Speed

Prior to SS7 implementation, end-to-end call management signalling 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 signalling. End-to-end out-of-band signalling 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 signalling, 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. Internetwork 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. See Table: Outgoing Speeds and the Cisco IOS Dialer Maps and Profiles for outgoing speeds.

Table: Outgoing Speeds and the Cisco IOS Dialer Maps and Profiles

When originating calls are made at 64 Kbps improperly delivered to the destination by the ISDN network over at 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 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 5558084 

• • Cisco 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 56 

• • Cisco 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 in most circumstances will operate properly. However, in some country-to-country applications, 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 Information Element is also received, it can be used to override the received bearer capability using the Cisco IOS configuration command isdn not end-to-end.

Datagram Encapsulation Issues

ISDN can use PPP, HDLC, or X.25 for encapsulation. PPP is used most frequently as it provides an excellent mechanism for authentication and negotiation of compatible link and protocol configuration.

Point-to-Point Protocol (PPP)

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 internetwork 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.

• Link Control Protocol (LCP)

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 (NCP)

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 sends NCP frames to negotiate and establish connectivity for one or more network-layer protocols. For example, to support IP over a PPP connection, the IPCP is negotiated and established as per RFC 1332. Once IPCP is successfully established, IP datagrams can be transmitted over the PPP connection.

• MultiLink PPP (MP)

Multilink PPP (MP) 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: MultiLink PPP in action provides a conceptual view of MP in action.

Figure: MultiLink PPP in action

When an NCP packet arrives at an MLP master-interface for transmitting and is over 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 multilink 

MP 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.

ISDN Security

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

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 since 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: ISDN callback shows a typical negotiation.

Figure: ISDN callback

In Figure: ISDN callback, callback is completed in the following sequence of steps, as follows:

1. Router A brings up a circuit-switched connection to Router B.
2. Routers A and B negotiate PPP Link Control Protocol (LCP). Router A can request a callback, or Router B can initiate a callback.
3. Router A authenticates itself to Router B using PPP PAP or CHAP. Router B can optionally authenticate itself to Router A.
4. Both routers drop the circuit-switched connection.
5. Router B brings up a circuit-switched connection to Router A.

Callback provides centralized billing for synchronous dial-up services. It also allows you to take advantage of tariff disparities on both a national and international basis. However, because callback requires a circuit-switched connection to be established before the callback request can be passed, a small charge (dependent on local tariffing) is always incurred by the router initiating the call that requests a callback.

See Designing DDR Internetworks, for a further discussion of DDR callback. For a callback configuration example, refer to the Cisco Internetworking Case Studies guide, Chapter 21, "Using ISDN Effectively in Multiprotocol Networks."

• 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 allow 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

ISDN scaling techniques covered in this section include the following:

• Virtual Remote Nodes
• Virtual Profiles
• Multichassis MultiLink PPP (MMP)

Virtual Remote Nodes

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 IP address and UDP/TCP port addresses translated to appear as a single IP address. 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.

Cisco 700 PAT and DHCP

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

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 

Multichassis MultiLink PPP (MMP)

When designing MultiLink PPP without Multichassis support, telco hunt-groups cannot span more than a single Cisco IOS NAS or there exists a risk that the multiple B channels will not be reassembled. For example, an AS5300 can support up to four PRI interfaces 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: MMP allows a telco hunt-group to span more than a single NAS. This has the negative effect of fragmenting the dial-up pool.

Figure: MMP allows a telco hunt-group to span more than a single NAS

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: Active MMP sessions).

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 

Figure: Active MMP sessions

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).

ISDN Cost Containment Issues

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 occurred. Cisco highly recommends the use of proper network management to back up careful design to ensure 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

Traffic Analysis

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 internetworking 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 as to 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 effectivity 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.

Tariff Structure

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.

User Education

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.

Using SNMP

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: Cisco ISDN MIB Variables lists some of the MIB variables that are available in the ISDN MIB. Cisco Enterprise Accounting for ISDN can provide management access to Call History Data using this MIB.

Table: Cisco ISDN MIB Variables

The Cisco Call History MIB stores call information for accounting purposes. The goal is to provide a 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: Cisco Call History Variables lists some of the MIB variables.

Table: Cisco Call History Variables

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 internetworking 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).

Cisco Enterprise Accounting (CEA) for ISDN

CEA for ISDN is a software application that runs on Windows NT. CEA for ISDN can be utilized to monitor the ISDN Call-History-MIB and provide network managers with Call Detail Records, including cost estimates.

AAA Accounting

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 

Summary

Increasing availability and decreasing costs are making ISDN an excellent choice for many internetworking 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. However, extra care must be taken to ensure ISDN costs are controlled.