| [ LiB ] |   |
Scenarios
This section presents three scenarios. The first teaches you how to configure dialer profiles with a BRI interface. The second describes dialer profile configuration on a PRI interface. The third offers a dialer rotary group configuration example.
Scenario 7-1: Configuring Dialer Profiles
In this scenario, you enable DDR between R1 and R2, as shown in Figure 7-1.
Figure 7-1. Dialer Profile Configuration Topology
R2 has been preconfigured for legacy DDR, as shown in Example 7-1. Every command shown should already be familiar to you from Chapter 6, "Using ISDN and DDR Technologies to Enhance Remote Connectivity."
Example 7-1. Configuration of R2
R2#show running-config hostname R2 ! !Output omitted for brevity ! interface BRI0 ip address 192.168.1.2 255.255.255.0 encapsulation ppp dialer idle-timeout 120 dialer map ip 192.168.1.1 name R1 broadcast 5550001 dialer-group 1 ppp authentication chap ! dialer-list 1 protocol ip permit
Your assignment is to configure R1 with dialer profiles. As you know, to configure dialer profiles, you need to do the following:
Configure one or more dialer interfaces.
Configure an optional dialer map class to define different characteristics on a per-call basis.
Configure the physical interfaces, and add them to a dialer pool.
Configuring the Dialer Interface
You can now begin the dialer profile configuration on R1. Before you can configure any commands for the dialer interface, you need to create it using the following command:
R1(config)#interface dialer number
The interface dialer command puts you in dialer interface configuration mode. You can choose a number from 1 to 1000. After the dialer interface is created, you can set up the entire configuration for a destination inside it.
Under the dialer interface configuration, you need to specify the IP address of the dialer interface that the physical interface will later assume when the binding occurs. To assign an IP address to the dialer interface, use the following command:
R1(config-if)#ip address address mask
The dialer remote-name command identifies the name of the remote router, R2. This name is checked by CHAP authentication.
R1(config-if)#dialer remote-name name
The next command defines the destination router's phone number. You also have the option to define map classes.
R1(config-if)#dialer string number class map-class-name
You can use multiple phone numbers with the dialer string command. Before Cisco IOS Release 12.2(8)T, the first telephone number in the dial string list was always the one used for a specific outgoing call. However, Release 12.2(8)T introduced the Rotating Through Dial Strings feature, which lets you customize the dial string usage order. By using this feature, you can specify the dialing order of multiple dial strings.
The syntax to configure the Rotating Through Dial Strings feature is as follows:
R1(config-if)#dialer order {sequential | round-robin | last-successful}
The options are as follows:
sequential The call uses the first dial string in the multiple strings list.
round-robin The call uses the next dial string in the list after the most recently successful string.
last-successful The call uses the most recently successful string.
The dialer load-threshold command specifies the traffic load, which causes additional links to be brought up for Multilink PPP:
R1(config-if)#dialer load-threshold load [outbound | inbound | either]
Valid load values are between 1 and 255, with 255 being 100% load. You also can choose to specify the direction of traffic for which the load is calculated.
The dialer wait-for-line-protocol command forces the dialer to wait a specified amount of time for a line protocol after establishing a physical connection. If a call is dropped before the timer has expired, the call is considered unsuccessful, which creates conditions for a redial (if this is configured). This command is used only for the PPP encapsulation, because Cisco HDLC encapsulation is the default line protocol and always comes up. To set up the line protocol timer, use the following syntax:
R1(config-if)#dialer wait-for-line-protocol seconds
The seconds value can range from 1 to 2147483.
Use the dialer hold-queue command to set the number of packets in queue while the line is coming up:
R1(config-if)#dialer hold-queue number
The number argument is a value between 1 and 100.
The dialer pool command is used to associate a dialer interface with a dialer pool:
R1(config-if)#dialer pool number
Substitute the number argument with a value between 1 and 255.
To tell the dialer interface which dialer list to use to determine the interesting traffic parameters, use the following command:
R1(config-if)#dialer-group dialer-list-number
The group numbers should be in the range of 1 to 10.
You specify that Multilink PPP is to be used on the dialer interface with the following command:
R1(config-if)#ppp multilink
When the ppp multilink command is placed on the logical interface, it deals with outgoing calls; when placed on the physical interface, it is applied to incoming calls. For both incoming and outgoing calls, place this command on both physical and dialer interfaces.
Example 7-2 shows the dialer interface configuration portion of R1. Notice the following elements in the output:
The phone number of the destination is 0002, with the map class DEPT.
The dialer interface is assigned to pool 5.
The IP address and mask are specified under the dialer interface configuration.
The remote router name is set for CHAP authentication.
List number 1 is specified for interesting traffic definition.
Example 7-2. Dialer Interface Configuration of R1
R1#show running-config ! interface dialer1 ip address 192.168.1.1 255.255.255.0 encapsulation ppp dialer remote-name R2 dialer string 0002 class DEPT dialer string 0012 class DEPT dialer wait-for-line-protocol 10 dialer load-threshold 60 either dialer hold-queue 12 dialer pool 5 dialer-group 1 dialer order round-robin no cdp enable ppp authentication chap ppp multilink ! dialer-list 1 protocol ip permit
Configuring the Map Class
Now you can configure an optional map class. The map-class dialer command is used to define a map class and subsequently enter map class configuration mode:
R1(config)#map-class dialer class-name
In the preceding step, you specified DEPT as the class name. This means that the dialer1 interface on R1 is associated with map class DEPT, created by the map-class dialer command. Class names are case-sensitive.
As soon as you enter map class configuration mode, you can define parameters for the map class. Such commands may vary from one environment to the next. The commands used in this scenario are only examples, not requirements.
For instance, use the dialer isdn speed command to set an ISDN bit rate to 56 kbps for use in the map class:
R1(config-map-class)#dialer isdn speed speed
The dialer idle-timeout command causes the call to be disconnected if there is no activity on the link for the time specified. This helps you avoid unnecessary charges.
R1(config-map-class)#dialer idle-timeout seconds
The idle-timeout default is 20 seconds.
The dialer fast-idle command is used when a call is waiting for the interface but the idle timeout hasn't yet expired. If the fast-idle command is specified, the current call is disconnected much faster so that the waiting call can get through. The syntax for this command is as follows:
R1(config-map-class)#dialer fast-idle seconds
The default fast idle time is 20 seconds.
The dialer wait-for-carrier-time command causes the call to be dropped if no carrier is detected within the specified amount of time. Use the following syntax to issue the command:
R1(config-map-class)#dialer wait-for-carrier-time seconds
The default value is 30 seconds. However, for asynchronous lines, the value should be at least 60 seconds to allow for delays in the telephone network.
Example 7-3 shows the configuration of map class DEPT. This is the same map class that is associated with the dialer1 interface. One of the set parameters is for the call to disconnect after 2 minutes of no data traffic.
Example 7-3. Map Class DEPT on R1
R1#show running-config ! interface dialer1 dialer string 0002 class DEPT ! ! Output omitted for brevity ! map-class dialer DEPT dialer isdn speed 56 dialer idle-timeout 120 dialer fast-idle 20 dialer wait-for-carrier-time 30 !
Configuring the Physical Interface
The final of the three dialer profile configuration tasks is configuring the physical interface and applying it to a dialer pool.
The first part of the physical interface configuration is to assign the interface in question to a dialer pool. Dialer pools can use a combination of synchronous, serial, BRI, or PRI interfaces. To include an interface in a dialer pool, issue the following command:
R1(config-if)#dialer pool-member number [priority number] [min-link number] [max-link number]
The dialer pool-member command can be used several times to assign the interface to more than one dialer pool. If you use the optional priority keyword, you can assign a priority to this interface within a particular pool. The valid priority numbers range between 1 and 255. The higher the number, the higher the likelihood that the interface will be chosen over other interfaces. The prioritization of interfaces within a pool applies only to dialing out. The min-link and max-link options reserve the minimum and maximum number of ISDN B channels for an interface. The lowest number requirement is 1, and the highest is 255.
As mentioned, it's important to set PPP encapsulation, authentication, and multilink options on a physical interface for LCP negotiations to be successful and for subsequent profile binding to take place. When configuring the physical interface, don't forget to include these settings.
Example 7-4 shows R1's physical interface configuration. Here a physical interface is assigned to pool number 5. Notice that the Layer 2 protocol parameters have been configured as well.
Example 7-4. Physical Interface Configuration of R1
R1#show running-config ! interface BRI0 no ip address encapsulation ppp dialer pool-member 5 ppp authentication chap ppp multilink ! interface dialer1 dialer pool 5 ! ! Output omitted for brevity !
Scenario 7-2: Configuring Dialer Rotary Groups
In this scenario you will learn all five stages of rotary group configuration. You will do so by reconfiguring R2, previously used in Scenario 7-1. Figure 7-2 illustrates the current topology.
Figure 7-2. Rotary Group Configuration Topology
Defining Interesting Traffic
The first step in the rotary group configuration is to define interesting traffic. You learned how to do so in Chapters 5 and 6. This section is a brief reminder. Packets that are considered interesting trigger a DDR call. Interesting traffic criteria can vary. The choices include protocol type, source address, destination address, and port number. To create an interesting traffic definition, you use the following command:
R2(config)#dialer-list dialer-group-number protocol name [permit | deny | list access-list-number]
Key components of this command are described in Table 7-2.
Argument | Description |
|---|---|
dialer-group-number | References this dialer list using the same number as in the dialer-group command. |
protocol name | Specifies which protocol packets are considered interesting for DDR, including IP, IPX, AppleTalk, DECnet, and VINES. |
permit | deny | Permits or forbids the named protocol to initiate DDR. Can also optionally specify an access list. |
list | References an access list created for greater precision in interesting traffic definition. |
R2's interesting traffic definition, shown in Example 7-5, allows IP traffic to initiate DDR but not IPX.
Example 7-5. Defining Interesting Traffic on R2
R2#show running-config ! hostname R2 ! dialer-list 1 protocol ip permit dialer-list 1 protocol ipx deny !
NOTE
In this scenario, IPX traffic would be denied with or without the list statement, because interesting traffic must be explicitly permitted.
Creating the Dialer Interface for Dialer Rotary Groups
The dialer interface created for rotary groups should include all configuration parameters that will later be applied to a physical interface when a call is made. Therefore, configuring a dialer interface has several stages of its own:
- Step 1. Create a dialer interface with the following command:
R2(config)#interface dialer number
The number element is used to produce a dialer interface. It also is used as a reference number for a rotary group. All subsequent configuration steps in this section take place in dialer interface configuration mode. - Step 2. Configure a local network address and mask. This address will be applied to the physical interface at the time of the call.
- Step 3. Configure the encapsulation type, such as PPP.
- Step 4. When PPP is used, configure PPP authentication.
- Step 5. When using internal or external modems, use the following command:
R2(config-if)#dialer in-band [no parity | odd parity]
This command does not apply to ISDN interfaces, because they use out-of-band dialing on the D channel. - Step 6. Connect the dialer-list interesting traffic definition with the dialer-group command.
- Step 7. Map the destination parameters with the dialer map command:
R2(config-if)#dialer map protocol next-hop-address name hostname [broadcast] dialer-string
- Step 8. Force a dialer interface to be connected at all times with the new dialer persistent command. For all intents and purposes, it achieves the same effect as the dialer idle-timeout 0 command. The dialer idle-timeout command should not be configured when the dialer persistent command is present.
R2(config-if)#dialer persistent [delay [initial] seconds | max-attempts number]
The optional delay keyword sets the delay in seconds before a persistent connection attempts to reestablish after a network error. The initial keyword delays a persistent connection establishment after configuration or bootup and without interesting traffic. max-attempts is the maximum number of reconnecting attempts after a network error. - Step 9. Configure the number of redial attempts, the interval between redial attempts, and how long the interface is disabled if all redial attempts fail:
R2(config-if)#dialer redial interval seconds attempts redials [re-enable disable-time-seconds]
Example 7-6 shows the dialer interface configuration on R2. If you compare this output with Example 7-1, you'll notice that the network address, encapsulation-related commands, interesting traffic, and destination coordinates have all moved from the physical interface into the dialer interface.
Example 7-6. Configuring the Dialer Interface on R2
R2#show running-config ! interface dialer1 ip address 192.168.1.2 255.255.255.0 encapsulation ppp dialer remote-name R1 dialer map ip 192.168.1.1 name R1 broadcast 5550001 dialer-group 1 dialer persistent delay initial 60 dialer persistent delay 10 dialer persistent max-attempts 5 dialer redial interval 20 attempts 5 re-enable 3600 ppp authentication chap !
Configuring Physical Interfaces as a Rotary Group
This portion of the configuration includes the physical interface in a rotary group. First, select an interface, BRI0 in this case, to comprise a rotary group. After you enter the configuration mode of that interface, create a dialer rotary group:
R2(config-if)#dialer rotary-group number
The number argument should match the dialer interface number that you want your rotary group configuration to come from. No further configuration of the physical interface is required. All other parameters come from the dialer interface.
Configuring Static Routes
The last two steps in the dialer rotary group setup are not rotary group-specific and are needed for general DDR deployment. The first step is to configure a static route for each DDR calling destination:
R2(config)#ip route network mask {address | interface} [distance]
Defining Passive Interfaces
The final step is to stop routing updates from triggering a DDR call by making your dialer interface passive:
R2(config-router)#passive-interface dialer number
NOTE
You can also create certain conditions with an access list that prevent updates of a particular routing protocol from passing. You can then add the access list to the dialer-list statement.
Scenario 7-3: Configuring the PRI Interface to Receive Asynchronous Calls and ISDN Calls
In this scenario you will learn how to configure a PRI interface on R3 to receive asynchronous calls and existing ISDN calls from R4, as shown in Figure 7-3. R3 is a Cisco 3640 with a Fast Ethernet network module, a T1/ISDN PRI network module, and a 30-modem network module with five modems installed. This study combines some configuration tasks learned in this chapter and those learned in previous chapters.
Figure 7-3. PRI Interface Configuration Topology
Assume that you have previously connected to R3 and configured the serial interface ISDN PRI channel with certain parameters. You can also assume that a PC has already been configured for asynchronous calls and R4 for BRI calls. While working on the R3 configuration, you will have to remove some of the existing statements as well as configure some new parameters.
As mentioned, R3 has been preconfigured to receive ISDN calls. Therefore, you should start by removing some of the old configuration. Example 7-7 shows the statements in need of removal.
Example 7-7. Removing the Old Configuration from R3
R3(config)#interface serial 1/0:23 R3(config-if)#no dialer idle-timeout 180 R3(config-if)#no dialer map ip 10.1.1.4 name R4 5551134 R3(config-if)#no dialer-group 1 R3(config-if)#no ppp authentication chap R3(config-if)#no ip address R3(config-if)#router eigrp 100 R3(config-router)#no passive-interface serial 1/0:23 R3(config-router)#no redistribute static R3(config-rotuer)#no ip route 10.44.0.0 255.255.255.0 10.1.1.4
Now that the old configuration has been erased, you are ready to configure a PRI interface to receive ISDN and asynchronous calls. This process involves the following steps:
- Reconfiguring the PRI interface and adding it to dialer pool 4
- Creating an asynchronous group interface for use with internal modems
- Creating a dialer interface
- Configuring modem line characteristics
- Disallowing routing protocol updates to trigger DDR calls
- Verifying static routes
Configuring the PRI Interface
Enter serial 1/0:23 configuration mode, and configure the D channel to switch incoming analog calls to the internal modems:
R3(config-if)#isdn incoming-voice modem
Next you can assign the PRI interface to dialer pool 4:
R3(config-if)#dialer pool-member 4
Configuring an Asynchronous Group Interface
Here you need to configure an asynchronous group interface for R4's internal modems. Table 7-3 describes the commands needed to configure an asynchronous group interface.
Command | Description |
|---|---|
interface group-async 1 | Creates an asynchronous group interface. |
ip unnumbered ethernet 0/0 | Forces the group interface to use the IP address of the Ethernet port. |
encapsulation ppp | Enables the use of PPP encapsulation on the interface. |
ppp authentication chap | Specifies the PPP authentication type. |
dialer in-band | Enables DDR on the interface and sends the data and the DDR control information over the same line. |
dialer idle-timeout 180 | Specifies a timeout of 3 minutes if no data is detected on the line. |
dialer-group 1 | Refers the interface to dialer list 1 for interesting traffic definition. |
async mode interactive | Lets the dial-in user run Serial Line Internet Protocol (SLIP) and PPP at EXEC level on the line. |
peer default ip address pool bigpool | Specifies that the interface allocates an IP address to any incoming call from the address pool bigpool. |
no cdp enable | Disables the Cisco Discovery Protocol. |
group-range 6065 | Identifies the modem lines in this group interface. |
Creating a Dialer Interface
At this stage you create the dialer interface to allow R4 to connect using its BRI interface. Table 7-4 describes the usual configuration tasks.
Command | Description |
|---|---|
interface dialer 1 | Creates the dialer interface. |
ip address 10.1.1.3 255.255.255.0 | Configures the dialer interface's IP address and mask. |
dialer idle-timeout 180 | Sets an idle timer. |
dialer-group 1 | Recalls the dialer list that defines interesting traffic. |
encapsulation ppp | Sets the encapsulation to PPP. |
ppp authentication chap | Sets the PPP authentication to CHAP. |
no peer default ip address | Stops the dialer interface from trying to assign an IP address to incoming calls. |
ppp multilink | Enables Multilink PPP. |
dialer remote-name R4 | Identifies the remote router. |
dialer string 5551134 | Supplies R4's phone number. |
dialer pool 4 | Sets the dialer interface to use pool 4. |
Configuring Modem Line Features
Now you need to configure the internal modem lines and their physical characteristics. Table 7-5 shows the list of commands needed to accomplish this.
Command | Description |
|---|---|
line 60 65 | Enters modem line configuration mode, which is used for asynchronous calls coming into the PRI interface. |
autoselect during-login | Lets the router automatically select the correct protocol during login. |
autoselect ppp | Specifies PPP as the autoselect protocol. |
login local | Tells the router to check a local login username and password. |
modem inout | Sets the modem lines to accept both incoming and outgoing calls. |
modem autoconfigure discovery | Tells the router that the modem type is to be automatically discovered and configured for operation. |
transport input all | Specifies that the lines will accept all protocols. |
stopbits 1 | Sets the number of stop bits for the data. |
flowcontrol hardware | Configures the router to control flow by using RTS CTS signal lines. |
Preventing Routing Updates from Triggering DDR Calls
The last stage of this scenario's configuration is preventing routing updates from making a DDR call. You must ensure that such updates will not be sent over the dialer interface. Table 7-6 lists the needed commands.
Command | Description |
|---|---|
router eigrp 100 | Enters routing protocol configuration mode. |
passive-interface dialer 1 | Specifies the dialer 1 interface as passive. |
ip route 10.44.0.0 255.255.255.0 dialer 1 | Assigns a static route to R4's Ethernet network address over the dialer 1 interface. |
Verification
You know that to see the commands you've entered, you can enter show running-config. However, you can use other methods to verify the success of your configuration. Here are some additional testing techniques:
You can dial into R3's ISDN PRI interface from the PC modem. The PRI interface should pass the call from the PC to the internal modems to be answered. If this action results in the "User access verification" message and a login prompt, the connection has been correctly established.
You can dial in over the ISDN line from R4 by pinging R3's Ethernet port. To reach the Ethernet network, R4 dials into R3's ISDN PRI interface for connection establishment. You can watch the call setup activity and the ping response on R4 to verify whether the call was successful.
You can use the debug command you learned in Chapter 6.
| [ LiB ] | |