|
|
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 11-1 shows ISDN being used to concurrently serve ISDN and POTS (analog modem) connected remote sites in a hybrid dial solution.
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 internetworking between ISDN connected sites.
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 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 11-4.
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 11-1.
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:
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:
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 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 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.
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.
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.
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.
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.
BRI configuration involves configuration of ISDN switch-type, and ISDN SPIDs, as follows:
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
SEt SWitch 5ESS | DMS | NI-1 | PERM64 | PERM128
interface BRI0 isdn spid1 0835866201 8358662 isdn spid2 0835866401 8358664
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 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: %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:
isdn tei-negotiation first-call
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 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.
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
The following ISDN end-to-end considerations are covered in this section:
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:
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 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.
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 11-1 for outgoing speeds.
| Outgoing Speed | Cisco IOS Dialer Maps | Cisco IOS Dialer Profile | Cisco 700 |
|---|---|---|---|
64 Kbps | dialer map ... speed 64 (default) | ?? | set speed 64 |
56 Kbps | dialer map ... speed 56 | ?? | set speed 56 |
Auto | Multiple Dialer Maps | ?? | set speed auto (default) |
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.
int dialer 1 dialer map ip 172.20.1.1 name nas speed 56 5558084
interface dialer 1 dialer remote-name nas dialer string 5558084 class unameit ! map-class dialer unameit dialer isdn speed 56
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.
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:
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
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
set ppp multilink on
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.
isdn caller 41555512xx
In Figure 11-8, callback is completed in the following sequence of steps, as follows:
Step 2 Routers A and B negotiate PPP Link Control Protocol (LCP). Router A can request a callback, or Router B can initiate a callback.
Step 3 Router A authenticates itself to Router B using PPP PAP or CHAP. Router B can optionally authenticate itself to Router A.
Step 4 Both routers drop the circuit-switched connection.
Step 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."
ISDN scaling techniques covered in this section include the following:
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.
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 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 11-9. This has the negative effect of fragmenting the dial-up 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:
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).
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:
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:
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,
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 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 that are available in the ISDN MIB. Cisco Enterprise Accounting for ISDN can provide management access to Call History Data using this MIB.
| 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 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 11-3 lists some of the MIB variables.
| MIB Object | Description |
|---|---|
ciscoCallHistoryStartTime | The value of |
ciscoCallHistoryCalledNumber | The number that was used to place this call. |
ciscoCallHistoryCallConnectionTime | The value of |
ciscoCallHistoryCallDisconnectTime | The value of |
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).
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 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
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.
Posted: Wed Apr 10 10:53:20 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
