Cisco ISDN Cost-Effective Solutions


ISDN is offered by most local exchange carriers (LECs). It's used for data, voice, and video exchange. Recently, the use of ISDN for offnet video-conferencing has increased. However, ISDN became less attractive as a cost-effective solution when compared to other emerging technologies, such as digital subscriber line (DSL), cable, wireless, and satellite. The cost of ISDN service is usually composed of an initial installation charge plus usage-based charges. In some cases, a LEC might differentiate pricing of the first minute in comparison to the following minutes. However, all LECs base the per-usage charge on the number and duration of calls. Using special equipment, such as a Centrex, makes it possible to map the calls to other numbers with the same prefix, which reduces the number of digits to dial (for example, five instead of ten), and reduces the cost to a flat-rate service. In some areas, ISDN is still the only alternative providing Basic Rate Interface (BRI) service with two data/voice channels for remote users. The following alternatives are cost-effective solutions that need to be considered.

Spoofing

One of the most popular ISDN techniques is called spoofing, which is where the router responds to keepalive packets instead of sending them to the remote party. If the spoofing is "up," the protocol layer is reporting up, as shown in Example 11-1. In order for any interface to report the protocol layer up, the other party must respond to keepalives, but in spoofing, the router itself responds to keepalives. Spoofing is also part of the troubleshooting technique to check the status of the dialer interface. Even when the router does not make a call, the dialer shows a spoofing state.

Example 11-1. show interfaces dialer 1 Command Output Reveals Dialer1 is up (spoofing), line protocol is up (spoofing)
 804-isdn# show interfaces dialer 1 Dialer1 is up (spoofing), line protocol is up (spoofing)   Hardware is Unknown   Interface is unnumbered. Using address of Ethernet0 (151.70.209.81)   MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation PPP, loopback not set   Keepalive set (10 sec)   DTR is pulsed for 1 seconds on reset   Last input never, output never, output hang never   Last clearing of "show interface" counters never   Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0   Queueing strategy: weighted fair   Output queue: 0/1000/64/0 (size/max total/threshold/drops)   Conversations  0/0/16 (active/max active/max total)   Reserved Conversations 0/0 (allocated/max allocated)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec   112555 packets input, 102607119 bytes   77225 packets output, 9186472 bytes 

If you monitor the 5 minute input rate and 5 minute output rate counters in Example 11-1, you don't see any activity. The spoofing only imitates an active state of the dialer, but this does not mean that the router is connected, or makes a call. This is the cost-saving effect of the spoofing because the router is not connected and there is no charge from the local provider. To clarify, the router makes a call only if the DDR conditions are met.

Snapshot Routing and OSPF Demand Circuits

Another innovative cost-effective ISDN configuration technique is called snapshot routing. Before snapshot routing became available in Cisco IOS Software Release 10.2, ISDN interfaces were configured using static routes, which prevent bandwidth from being consumed by routing updates. But, they are difficult to maintain as the network grows. Snapshot routing supports dynamic routes by allowing routing updates to occur during an active period. It also reduces connection cost by suppressing routing updates during a quiet period; thus, snapshot routing is a way to reduce connection time in ISDN networks by suppressing the transfer of routing updates for a configurable period of time. In ISDN, snapshot routing is applicable for distance vector routing protocols, such as Routing Information Protocol (RIP) and Interior Gateway Routing Protocol (IGRP) for IP, RTMP for AppleTalk, RIP and SAP for IPX, and RTP for Vines. Here's why: As you know, the concept of distance vector protocols is based on triggered updates. The goal of snapshot routing is to allow distance vector routing protocols to exchange updates as they normally would.

The nature of snapshot routing is based on the notion that the router learns of routing updates without periodic updates, thus reducing the number and duration of unnecessary calls and reducing cost. Snapshot routing defines active periods and quiet periods. The active period is a time slot that enables the routing updates to be sent over the DDR interface for a short duration of time. After the active period's expiration, the router alternates with a quiet period when the routing tables at both ends of the link are frozen. Snapshot is, therefore, a triggering mechanism that controls routing updates through a DDR exchange. Both periods can be configured based on the traffic, time of day, and cost-effective considerations.

As soon as a call is triggered for any reason, such as interesting traffic in DDR or a DNS lookup, it triggers the active period timer, as shown in Figure 11-1. During that session, both parties update their routing tables. After the active period's expiration, which can be between 5 and 100 minutes, the update is frozen and both parties enter the quiet period. After the expiration of this time slot and if no calls were made, the router triggers another call, sets the timer, and starts another active period exchange. The quiet period can be configured in a large range, which can be between 5 minutes and 65 days. Because of this possible delay, the technique offers another configurable time slot called a retry period, where more updates can be exchanged if no other activity is on the link.

Figure 11-1. The Active, Quiet, and Retry Period Interaction in Snapshot Routing


Example 11-2 shows the configuration options for snapshot routing for the dialer 1 interface.

Example 11-2. Snapshot Routing Options of Cisco IOS Software
 804-isdn(config-if)#dialer map snapshot 1 ?   WORD           Dialer string   broadcast      Broadcasts should be forwarded to this address   class          Dialer map class   modem-script   Specify regular expression to select modem dialing script   name           Map to a host   spc            Semi-permanent connections   speed          Set dialer speed   system-script  Specify regular expression to select system dialing script 

Another application for the same command line redefines the default speed and then applies the map class to the dialer interface:

 804-isdn(config-if)#dialer map snapshot 1 class class-name speed [56 | 64] 

It is almost mandatory to configure the next line under the BRI or dialer interface:

[View full width]

804-isdn(config-if)#snapshot [client | server] active-time quiet-time [suppress-statechange-updates][dialer]

The [client | server] option must be defined as client on the spoke side and server on the hub side of the connection.

The active-time variable specifies the amount of time, in minutes, that routing updates are regularly exchanged between the client and server routers. This can be an integer in the range 5 to 100. There is no default value. A typical value is 5 minutes.

The quiet-time variable specifies the amount of time, in minutes, that routing entries are frozen and remain unchanged between active periods. Routes are not aged during the quiet period, so they remain in the routing table as if they were static entries. This argument can be an integer from 8 to 100,000. There is no default value. The minimum quiet time is generally the active time plus 3.

The snapshot command ensures that, if any other event triggers the call out, the snapshot algorithm starts the active period timer and the routing updates will take place.

NOTE

Always start the monitoring of snapshot connections and routing by clearing the appropriate interfaces. clear dialer or clear counters [bri | dialer] clears the interface or the previous diagnostic statistics.


Use the following commands to monitor snapshot connections and routing:

  • show dialer [interface type number] Displays general diagnostics about the interface

  • show interfaces bri 0 Displays information about the ISDN D-channel

  • clear snapshot quiet-time interface Terminates the snapshot routing quiet period on the client router within two minutes

  • show snapshot [type number] Displays information about snapshot routing parameters

Information about snapshot routing is relatively new. You can find more information about periodic updates at Cisco.com. The key advantages of the snapshot technique are easy evolution, scalability, and manageability.

Snapshot routing is applicable, but not limited, only to ISDN networks. The leased lines can benefit from the reduction of periodic updates that snapshot routing provides.

Snapshot routing is applicable for hub-and-spoke topologies; it's not recommended for meshed topologies. In meshed topologies, configuring static routes is more efficient than configuring snapshot routing.

The link-state protocols, such as Novell Link Services Protocol (NLSP), Open Shortest Path First (OSPF), and Intermediate System-to-Intermediate System (IS-IS) depend on the frequent sending of Hello messages in a short period of time (five or ten seconds) to neighboring routers in order to discover and maintain routes. This fact makes them not suitable for this technique.

For OSPF, which belongs to the family of link-state routing protocols, the "ospf demand circuit" can be thought of as the equivalent to snapshot routing, but with a link-state protocol. The demand circuit options were introduced for OSPF in Cisco IOS Software Release 11.2 in response to the OSPF (RFC 1793). OSPF sends Hellos every 10 seconds and refreshes its link-state advertisements (LSAs) every 30 minutes. These functions, which maintain neighbor relationships and ensure that the link-state databases are accurate, use far less bandwidth than similar functions in RIP and IGRP. However, even this amount of traffic is unwanted on demand circuits. By using the OSPF demand circuit options, which suppresses Hello and LSA refresh functions, OSPF can establish a demand link to form an adjacency and perform initial database synchronization. The adjacency remains active even after Layer 2 of the demand circuit goes down. The two main features of OSPF over demand circuits are

  • Suppressed periodic Hellos

  • Suppressed periodic LSA refresh

You can find more information about this topic at www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cospf.htm.

DDR

DDR is the most common cost-effective technique used in ISDN router configurations. With DDR, all traffic is classified as either interesting or uninteresting. Regardless of the advantages of using dynamic versus static routing, static routing is still a viable solution for a remote access environment and it is commonly used in DDR. One of the reasons is that the dynamic routing updates can trigger the router to call out every time the routing update is necessary.

There are two main options for implementing DDR for routers with ISDN BRIs:

  • Dialer maps (sometimes referred to as legacy DDR), which are available for Cisco IOS Software Releases prior to 11.2.

  • Dialer profiles, which are available in Cisco IOS Software Release 11.2 and all subsequent versions.

The DDR features discussed in this chapter can be used over ISDN or other dial-up media, as well as over any asynchronous lines.

NOTE

The existence of the dialer interface in the configuration does not necessarily classify it as a dialer profile configuration. The key difference is the mapping and rotary group elements for the legacy DDR versus dialer profiles and pools.


The general concept and function of DDR can be narrowed to the following steps:

1.

When the router receives some traffic, it performs a table lookup to determine whether there is a route to the desired destination. Based on the configuration, the outbound interface is identified.

2.

If the identified outbound interface is configured for DDR, the router does a lookup to determine whether the traffic is interesting based on the dialer list statement of the configuration.

3.

The router then identifies the next hop router and locates the dialing information based on dialer map or dialer profiles configuration.

4.

In the case of dialer profiles, the router checks if the dialer is currently connected to the desired remote destination. If so, the traffic is sent and the idle timer is reset to the maximum configured value every time the interesting packet crosses that dialer.

5.

In the case of dialer profiles, if the dialer is not currently connected to the desired remote destination, the router determines which physical interfaces are in its dialer pool, "borrows" an interface, makes a call out, applies the map class (if it exists) and dialer interface configuration, establishes a connection, and sets the idle timer to its maximum configured value.

6.

After the link is established, the router transmits both interesting and uninteresting traffic. Uninteresting traffic can include data and routing updates.

7.

When the time duration between any two consecutive interesting events is greater than the idle timer value, or the idle timer expires, the call is disconnected. In the case of dialer profiles, the physical interface is released and goes back to the dialer pool.

NOTE

DDR is not a traffic filter solution, but a mechanism to force a call setup and call teardown. The moment the interesting traffic triggers a call, the router resets the idle timer to the maximum configured value each time the interesting traffic crosses the interface. As long as the interface is up, however, all traffic is forwarded over that interface. Remember that only the interesting traffic can set or reset the idle timer; otherwise, the idle timer, ticking down by default, expires.


For troubleshooting purposes, refer to one simple procedure, provided in Chapter 7 of Building Cisco Remote Access Networks by Catherine Paquet (Cisco Press, 1999).

Obviously, if all traffic is interesting, the router constantly keeps the line up 24 hours a day. This raises questions about how to define interesting traffic and what are the techniques to distinguish it from non-interesting traffic in order to make DDR a cost-effective solution, reducing the up time and, as a result, the duration of the calls.

Both legacy DDR and dialer profiles solutions work simultaneously in existing Cisco production environments. For CPE significance, they are local. As a result, you might have a dialer profiles on the spoke side and legacy DDR on the hub side, or any other combination.

In general, the legacy DDR requires the following steps:

1.

Specify interesting traffic. What traffic type should enable the link?

2.

Define static routes. What route do you take to get to the destination?

3.

Configure the dialer information. What number do you call to get to the next hop router? What service parameters do you use for the call? The key for this configuration is mapping the protocol, address, the remote address name and the phone number with the following command:

 dialer map ip 161.30.253.254 name gateway broadcast 14085265555 

These steps can be performed when configuring the dialer profiles, but the content of the dialer information differs.

You can find additional information about legacy DDR at Cisco.com, but for the sake of a complete explanation, here are some of the specifics and limitations of legacy DDR:

  • There is one configured interface per ISDN interface. Before dialer profiles, all ISDN B channels inherited the physical interface's configuration.

  • Before dialer profiles, one dialer map was required per dialer per protocol, making multiprotocol configurations very complex.

  • When a PRI is used to back up an interface, all B channels are down and the entire interface is idle.

  • In a packet-switched environment in which many virtual circuits might need to be backed up individually and floating static routes are not desirable, the one-to-one relationship between interfaces and backup interfaces does not scale well.

  • Using the concept of rotary groups makes the configuration inflexible and restrictive because the physical interface participates in only one rotary group.

NOTE

The following section focuses on dialer profiles, which conceptually are based on creating virtual interfaces and allow the physical interfaces to belong to many different pools.


When reviewing router hardware, you will not find a physical interface called a dialer. The dialer profile feature enables you to configure dial-on-demand capabilities (in a dialer interface) separate from the physical interface. Because of this separation, the BRI and PRI interfaces can be shared by multiple dialer profile configurations, and the number of dialer profiles can be significantup to 300 for Cisco 4500 and more than 2800 for Cisco 7206VXR. (See more about this topic in the section, "Virtual Profiles," in Chapter 10, "ISDN Design Solutions.") Dialer profiles enable logical and physical configurations to be bound together dynamically on a per-call requirements basis. Dialer profiles can define encapsulation, access control lists (ACLs), minimum or maximum calls, and turn on and off a variety of features.

With dialer profiles, the physical interfaces become members of a dialer pool, which is configurable and represents a set of interfaces that can be used on an on-demand basis. When a call must be made, the dialer pool borrows a physical interface for the duration of the call, based on the dialer interface configuration. After the call is complete, the physical interface is returned to the dialer pool. Dialer profiles enable BRIs to belong to multiple dialer pools. This eliminates wasting ISDN B channels. Multiple destinations can be bridged to avoid split horizon problems. Remote routers or users' access can be controlled or customized through independent dialer profiles.

The list of features can be extended. The dialer profiles perform the same cost-effective feature of DDR, achieving more flexibility and scalability of the configuration.

The main elements of the dialer profile include the following:

  • Dialer interfaces Logical entities used for a per-destination dialer profile. Any number of dialer interfaces can be created in a router. All configuration settings specific to the destination are configurable in the dialer interface configuration.

  • Dialer pool Represents a group of physical interfaces associated with a dialer profile. A physical interface can belong to multiple dialer pools. Contention for a specific physical interface is resolved by configuring the optional priority command.

  • Physical interfaces Configured for encapsulation parameters. The interfaces are configured to identify the dialer pools to which the interfaces belong.

  • Dialer map class (optional) The dialer map-class command defines specific parameters, such as speed, timers, and so on, and can be applied to different dialer interfaces.

Typically, dialer profiles support PPP and high-level data link control (HDLC) encapsulation.

To configure the dialer profiles for DDR, perform the following steps:

Step 1.

Configure the dialer interface.

Step 2.

Make every physical interface a member of a dialer pool.

Step 3.

Specify the interesting traffic.

Step 4.

Define the static route.

Step 5.

Optionally, you can define the map class.

The following sections cover each step in detail.

Step 1Configuring the Dialer Interface

As previously mentioned, the dialer interface is a non-physical interface. It defines the call destination. As is usual for every interface configuration, you have to first configure the interface, its type, and its number. Figure 11-2 shows the network setup and configuration information.

Figure 11-2. Configuring the Dialer Interface for Cisco IOS-Based ISDN Router on the Remote User's Side and on the Core Router's Side


The following text examines some of the more significant aspects of the dialer interface configuration.

For the encapsulation type command, type is typically ppp.

For the ppp authentication type command, type can be pap, chap, or both in specific order. The chap type involves configuration of the host name of the other party. Generally speaking, PPP does not need authentication to connect. It requires two conditions to connect:

  • A host name

  • PPP configuration

As soon as two-way CHAP authentication is defined, however, you must configure the remote host's CHAP name. There are two different options (keep in mind that the remote name is case sensitive):

  • Case 1

     804-isdn(config-if)#dialer remote-name username 

    username, which is the CHAP name of the hub side, is defined as "gateway" in Figure 11-2.

    The remote user's side is configured under the dialer 1 interface with the following:

     804-isdn(config-if)#ppp chap hostname 804-isdn 804-isdn(config-if)#ppp chap password ENS 

    where 804-isdn is the spoke CHAP name and ENS is the spoke password.

  • Case 2

    The remote name can be defined in the global configuration mode with the following commands:

     804-isdn(config)#hostname 804-isdn 804-isdn(config)#username gateway password ENS 

    The parameter gateway matches the CHAP name or the host name of the remote party.

Enable the multilink feature of the PPP protocol with PPP multilink. The string in the following command represents a phone number:

 dialer-string string class DialClass 

In the case of Figure 11-2, the phone number is 526-5555, because the user is calling from the same area. In general, the string includes 1 + area code + 7-digit number of the remote party. In this command, class represents the name of the map class, which will apply (map) to this dialer interface.

In the dialer pool number command, the number parameter represents with which pool the dialer interface is associated.

In the dialer pool-member number priority number command, which must be configured for each physical interface, number refers to which pool member this physical interface belongs and the second number parameter specifies the priority that can fall in the range of 1255.

The dialer-group number command assigns the interesting traffic definition to the dialer interface. When applying this line to the dialer interface, ensure that the number matches that of the dialer-list command.

Step 2Defining a Physical Interface as a Member of the Dialer Pool

The dialer pool is a set of physical interfaces used when a dialer interface needs to make a call. As previously mentioned, for the physical interface making a call, you can never expect the B channel to make a call. Call establishment, call clearance, and other signaling functions are the prerogative of the D channel in the 2B+D or 23B+D configuration.

NOTE

In general, you must enable in-band dialing to ensure the specified channel makes the call. However, this line is not necessary for the BRI interface because BRI uses out-of-band dialing through the D channel.


The D channel can be assigned to more than one pool, and can be prioritized within each pool to avoid contention. It is more common to assign the D channel of the BRIs (if there are more than one) to different pools, when considering capacity issues or other traffic-dependant issues.

In the case of an 804 ISDN router, there is only one BRI interface. For routers with more than one BRI interface, you must define each of them as a member of any pool with the following command:

 804-isdn(config-if)# dialer pool-member 4 priority 255 

The number 4 (from the range of 1255) is the number of the dialer pool to which the physical interface is assigned. The priority (0255) is also assigned, where 255 is the highest priority and indicates the dialer interface will choose this physical interface first.

The priority parameter is optional. If it is not used and several physical interfaces are members of the same pool, the interface with the lowest port number will be selected first. If that interface is busy, the next lowest port number is selected.

The next important step in Cisco IOS Software-based ISDN BRI0 configuration is to define the encapsulation and authentication under the physical interface, as follows:

  • encapsulation ppp

  • ppp authentication chap [pap callin]

  • enable ppp multilink

As you can see, this step differs from the legacy DDR, where only the command

 804-isdn(config-if)#encapsulation ppp 

is required under the physical interface. The reason for configuring the authentication and PPP multilink for dialer profiles DDR is because, based on the authentication information, that is how the router knows which dialer profile to switch the call to. As a result, the authentication must be set on the physical interface as well. If the dialer interface is configured for PPP multilink, it is recommended under the physical interface as well.

If the remote user's CPE is a Cisco 77x router, the role of the interface is performed by a configuration term called user. The user gateway is configured, as shown in Example 11-3.

Example 11-3. The User Gateway in 77x ISDN Router Performs the Role of Dialer Interface
 776-isdn>upload cd set user gateway set ip routing on set ip framing none set speed 64 set number 5265555 set ip rip update off set encapsulation ppp set ip route destination 0.0.0.0 gateway 0.0.0.0 cd set ppp authentication incoming chap set ppp authentication outgoing chap set ppp secret client <password> <password> set ppp secret host <password> <password> <output omitted> 

There is a partial analogy to the legacy DDR because all the elements of the DDR are available. The ACL option is discussed in the section, "Step 3Specifying the Interesting Traffic."

Example 11-4 shows the distribution of dialer pools for a Cisco 3640 router (core side), where interfaces Serial1/0:23 and Serial1/1:23 are members of dialer group 1, while Serial2/0:23 and Serial3/0:23 are members of dialer pools 2 and 3, respectively.

Example 11-4. The Dialer Pool Member Configuration in the Core Router
 3600-isdn#show running-config interface Serial1/0:23  description PRI Slot 1:Serial0: D-channel configuration; 408-526-5555  no ip address  encapsulation ppp  ip tcp header-compression passive  dialer pool-member 1 priority 1  isdn switch-type primary-5ess <output omitted> ! interface Serial1/1:23 description PRI Slot 1:Serial1: D-channel configuration; 408-526-5555  no ip address  encapsulation ppp  ip tcp header-compression passive  dialer pool-member 1 priority 255  isdn switch-type primary-5ess <output omitted> ! interface Serial2/0:23 description PRI Slot 2:Serial0: D-channel configuration; 408-526-6666  no ip address  encapsulation ppp  ip tcp header-compression passive  dialer pool-member 2  isdn switch-type primary-5ess <Output omitted> ! interface Serial3/0:23 description PRI Slot 3:Serial0: D-channel configuration; 408-526-7777  no ip address  encapsulation ppp  ip tcp header-compression passive  dialer pool-member 3  isdn switch-type primary-5ess <Output omitted> 

In this configuration, the Serial1/0:23 and Serial1/1:23 are members of pool 1, but Serial1/1:23 has the highest, whereas Serial1/0:23 has the lowest priority.

Step 3Specifying the Interesting Traffic

As you already know, the dialer-list command and its definition distinguish the interesting from the non-interesting traffic. The dialer list can use ACLs and the associated security mechanisms and techniques for this purposes as well. ACLs can be referred to as standard, extended, named, and temporary. You can find a multitude of resources about ACLs at Cisco.com. Example 11-5 shows a sample ACL for the remote user's side of the connection, based on Cisco IOS ISDN 804 router, where dialer-list 1 uses ACL 101 to define the interesting traffic.

Example 11-5. dialer-list 1 Uses ACL 101 to Define the Interesting Traffic in DDR
 access-list 101 deny     icmp any any echo-reply access-list 101 deny     icmp any any host-unreachable access-list 101 deny     udp any any eq ntp access-list 101 deny     igmp any any access-list 101 deny     ip any host 230.0.0.13 access-list 101 deny     ip any host 230.0.1.39 access-list 101 deny     ip any host 230.0.1.40 access-list 101 deny     ip any host 230.2.127.253 access-list 101 deny     ip any host 230.2.127.254 access-list 101 deny     ip any host 230.2.127.255 access-list 101 deny     ip any host  10.68.235.228 access-list 101 deny     ip any host  11.68.235.229 access-list 101 permit ip any any dialer-list 1 protocol   ip list 101 

In Example 11-5, the ACL denies the following:

  • Some of the ICMP messages (lines 1 and 2).

  • UDP messages exchanging Network Time Protocol (line 3).

  • Internet Group Management Protocol (line 4).

  • A group of multicast source addresses (lines 510).

  • Two WINS servers (lines 11 and 12).

  • Line 13 permits everything else.

  • Line 14 is the dialer-list 1 definition, using ACL 101.

Step 4Defining the Static Route

The static route can be configured using the following command syntax:

 804-isdn(config)#ip route prefix mask {address | interface}[distance] [permanent] 

The following is an example for setting the default route:

 804-isdn(config)# ip route 0.0.0.0 0.0.0.0 161.68.26.1 

If the router needs to redistribute IP addresses in the defined range, on the hub side, they need to be redistributed with the appropriate set of commands.

You can find additional discussions related to routing protocols at Cisco.com.

Step 5 (Optional)Defining the Map Class

Defining the map class is optional, but it is recommended because it creates scalable configurations. Assume the map class is called DialClass and defines the following parameters:

  • A class name with a name parameter

  • The time to wait before terminating the link when another call must be made

  • The amount of time to wait after there is no interesting traffic to send, before terminating the link

  • The amount of time to wait for a carrier to pick up the call after dialing the dial string

  • The dialer speed that assigns the desired speed to the ISDN line. A short configuration of map class, defining the desired speed, could be the following:

     804-isdn(config)#map-class dialer DialClass 804-isdn(config-map-cla)#dialer isdn speed 56 

    Then, this map class has to be associated with the dialer-string command, discussed in Step 1.

For more detailed configuration rules and explanations, visit Cisco.com.

PPP Callback for ISDN

The PPP LCP Extensions in FRC 1570 defines a callback function, which is negotiated during the LCP phase of PPP.

The callback function of PPP for ISDN interfaces allows a Cisco router using a DDR mechanism and PPP encapsulation to initiate a link to another device and request a callback. A Cisco ISDN router responds to a callback request from a remote device. The process uses the Point-to-Point Protocol (PPP) and the LCP extension specifications in RFC 1570. The callback feature of PPP (introduced in Cisco IOS 11.0) enables the remote user to place a call to the NAS and request the core router to call the remote user back. A typical negotiation would proceed as follows:

  1. The remote user's router establishes a connection to the core router.

  2. The remote user's router and the core router negotiate PPP Link Control Protocol (LCP) with the remote user's router requesting callback.

  3. Both routers authenticate each other using PPP, PAP, or CHAP protocols. It is typical that the initiator of the call to be requested to authenticate itself. In this scenario, this is the remote user's router. The core router's authentication is optional.

  4. After authentication, the core router disconnects the call.

  5. The core router calls out and establishes a connection with the remote user's router.

The cost-saving effects of an ISDN Cisco IOS Software callback occurs when a difference exists between the usage-based costs associated with the remote user's service and the core router's service. Usually, the corporate site obtains higher discounts from providers because of the expected call volume.

The next example shows how to configure the dialer interfaces of both sites to perform the callback function of PPP for ISDN.

Remote User Router Configuration

Example 11-6 shows a remote user's router configuration.

Example 11-6. PPP Callback for ISDN: Remote User Router Configuration
 804-isdn(config)#interface dialer 1 804-isdn(config-if)#ppp callback request ! If the following line  does not exist, configure: 804-isdn(config-if)#dialer hold-queue 100 timeout 20 

The ppp callback request line specifies that when the interface places a call, it requests a callback. The dialer hold-queue 100 timeout 20 specifies that up to 100 packets can be held in a queue until the core router returns the call. If the core router does not return the call within 20 seconds, plus the length of the enable timeout (configured on the central site router), the packets are dropped.

Core Router Configuration

Configuring the core router for PPP callback for ISDN involves two separate configurations:

  • Defining and naming the map class

  • Defining PPP callback for ISDN under the dialer interface

Example 11-7 and Example 11-8 demonstrate these two steps.

Example 11-7. PPP Callback for ISDN: Core Router ConfigurationDefining and Naming the Map Class
 7206-isdn(config)#map-class dialer CALLBACK 7206-isdn(config-map-class)#dialer callback-server username 

Example 11-8. PPP Callback for ISDN: Core Router ConfigurationDefining PPP Callback for ISDN Under the Dialer Interface
 7206-isdn(config)#interface dialer 1 7206-isdn(config-if)#ppp callback accept 7206-isdn(config-if)#dialer callback-secure 7206-isdn(config-if)#dialer enable-timeout 5 ! If the following line does not exist already, configure: 7206-isdn(config-if)#dialer hold-queue 100 ! This is the phone number of the remote user: 7206-isdn(config-if)# dialer map ip 10.19.241.1 name 804-isdn     speed 56 class CALLBACK 14085764740 

TIP

The dialer re-enable time must be greater than the serial pulse time.


The map-class dialer establishes a quality of service (QoS) parameter that is associated with a static map. The dialer keyword specifies that the map is a dialer map. The CALLBACK parameter is a user-defined value (you can name it something other than CALLBACK) that creates a map class to which subsequent encapsulation-specific commands apply.

The dialer callback-server username enables the interface to return calls when callback is successfully negotiated. The keyword username specifies that the interface is to locate the dial string for making the return call. This is done by looking up the authenticated host name in a dialer map command. All phases of PPP must complete successfully.

In ppp callback accept, the keyword accept enables the interface to accept the callback requests that come into the interface. The request is considered complete if all phases of PPP are successful.

The dialer callback-secure command specifies the router will disconnect the initial call and callback only if the dialer map is properly defined for callback with a defined class for the remote router.

If the dialer callback-secure command is not present, the core router will not drop the connection.

The dialer enable-timeout 5 specifies the interface is to wait five seconds after disconnecting the initial call before making the return call.

The dialer map ip 10.19.241.1 name 804-isdn speed 56 class CALLBACK 14085764740 was modified to include the class keyword and the name of the class, as specified in the map-class command. The keyword name is required so that when the remote user dials in, the interface can locate this dialer map statement in the core router configuration and obtain the dial string for calling back the remote user's router. You can find an example of checking the functionality of the callback feature in Chapter 12, "ISDN BRI Troubleshooting."




Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net